Re: [PATCH, ARM] Enable shrink-wrap for apcs frame
On 13 May 2014 20:56, Richard Earnshaw wrote:
> On 25/03/14 08:13, Zhenqiang Chen wrote:
>> Hi
>>
>> The patch enables shrink-wrap for apcs frame.
>>
>> Bootstrap and no make check regression in ARM, THUMB1 and THUMB2 modes.
>> No make check regression with "-g/-mapcs/-marm".
>> Build linux-3.14-rc7 without error.
>>
>> Is it OK for next stage1?
>>
>> Thanks!
>> -Zhenqiang
>>
>> ChangeLog:
>> 2014-03-25 Zhenqiang Chen
>>
>> * config/arm/arm.c (arm_option_override): Enable shrink-wrap for
>> TARGET_APCS_FRAME.
>> (arm_emit_multi_reg_pop): Set correct dwarf info.
>> (arm_expand_epilogue_apcs_frame): Add more dwarf info.
>>
>> testsuite/ChangeLog:
>> 2014-03-25 Zhenqiang Chen
>>
>> * gcc.target/arm/shrink-wrap-alloca.c: New test case.
>> * gcc.target/arm/shrink-wrap-sibcall.c: New test case.
>>
>> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
>> index 0240cc7..fa86942 100644
>> --- a/gcc/config/arm/arm.c
>> +++ b/gcc/config/arm/arm.c
>> @@ -2811,9 +2811,6 @@ arm_option_override (void)
>> generate additional returns. */
>>if (optimize_function_for_size_p (cfun) && TARGET_THUMB2)
>> flag_shrink_wrap = false;
>> - /* TBD: Dwarf info for apcs frame is not handled yet. */
>> - if (TARGET_APCS_FRAME)
>> -flag_shrink_wrap = false;
>>
>>/* We only support -mslow-flash-data on armv7-m targets. */
>>if (target_slow_flash_data
>> @@ -19840,7 +19837,14 @@ arm_emit_multi_reg_pop (unsigned long
>> saved_regs_mask)
>> par = emit_insn (par);
>>
>>REG_NOTES (par) = dwarf;
>> - if (!return_in_pc)
>> +
>> + if (!emit_update)
>> +{
>> + /* SP is restored from stack. So reset the frame info. */
>> + RTX_FRAME_RELATED_P (par) = 1;
>> + add_reg_note (par, REG_CFA_DEF_CFA, stack_pointer_rtx);
>> +}
>> + else if (!return_in_pc)
>> arm_add_cfa_adjust_cfa_note (par, UNITS_PER_WORD * num_regs,
>> stack_pointer_rtx, stack_pointer_rtx);
>> }
>> @@ -27226,6 +27230,9 @@ arm_expand_epilogue_apcs_frame (bool really_return)
>>REG_NOTES (insn) = alloc_reg_note (REG_CFA_RESTORE,
>> gen_rtx_REG (SImode, IP_REGNUM),
>> NULL_RTX);
>> + arm_add_cfa_adjust_cfa_note (insn, UNITS_PER_WORD,
>> + stack_pointer_rtx,
>> + stack_pointer_rtx);
>
> This can't be related to $SUBJECT, surely? Shrink-wrapping an interrupt
> routine?
>From middle-end view, shrink-wrapping does not distinguish an
interrupt routine from general routines. But I am not quite sure there
is dwarf info issue for interrupt route or not.
I am running regression test. If it does not impact on the result, I
will remove the code segment.
Thanks!
-Zhenqiang
> If this is as I think, please resubmit that part as a separate patch.
>
> The other changes look ok.
>
> R.
>
>> }
>>
>>if (!really_return || (saved_regs_mask & (1 << PC_REGNUM)))
>> diff --git a/gcc/testsuite/gcc.target/arm/shrink-wrap-alloca.c
>> b/gcc/testsuite/gcc.target/arm/shrink-wrap-alloca.c
>> new file mode 100644
>> index 000..318240b
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/arm/shrink-wrap-alloca.c
>> @@ -0,0 +1,11 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -g -mapcs " } */
>> +
>> +int *p;
>> +
>> +void
>> +test (int a)
>> +{
>> + if (a > 0)
>> +p = __builtin_alloca (4);
>> +}
>> diff --git a/gcc/testsuite/gcc.target/arm/shrink-wrap-sibcall.c
>> b/gcc/testsuite/gcc.target/arm/shrink-wrap-sibcall.c
>> new file mode 100644
>> index 000..2efe5d0
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/arm/shrink-wrap-sibcall.c
>> @@ -0,0 +1,26 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -g -mapcs " } */
>> +
>> +unsigned char a, b, d, f, g;
>> +
>> +int test (void);
>> +
>> +int
>> +baz (int c)
>> +{
>> + if (c == 0) return test ();
>> + if (b & 1)
>> +{
>> + g = 0;
>> + int e = (a & 0x0f) - (g & 0x0f);
>> +
>> + if (!a) b |= 0x80;
>> + a = e + test ();
>> + f = g/5 + a*3879 + b *2985;
>> +}
>> + else
>> + {
>> + f = g + a*39879 + b *25;
>> + }
>> + return test ();
>> +}
>>
>
>
Re: [PATCH] Remove "keep_aligning" from get_inner_reference
> > So does this remove the last concern around Bernd's patch? > > And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used > by obj-c/c++ as well, but I can't find such use) Probably but, as previously indicated, I need to do some testing first. -- Eric Botcazou
Re: [PATCH] Install sanitizer public headers (fix for PR sanitizer/61100)
On 05/14/2014 10:29 AM, Konstantin Serebryany wrote: Well, I'd say we should only install headers for components that are supported by target platform. maybe yes. It just complicates the patch somewhat. True... But this seems to be the preferred way in GCC (other runtimes also list headers explicitly). -Y
Re: RFA: Fix calculation of size of builtin setjmp buffer
> 2014-05-06 Nick Clifton > > * except.c (init_eh): Fix computation of builtin setjmp buffer > size. That's the same patch as https://gcc.gnu.org/ml/gcc-patches/2011-11/msg00272.html and is still incorrect. -- Eric Botcazou
Re: [RFC] Using function clones for Pointer Bounds Checker
2014-05-13 23:21 GMT+04:00 Jeff Law : > On 05/13/14 02:38, Ilya Enkovich wrote: propagate constant bounds value and remove checks in called function). >>> >>> >>> So from a linking standpoint, presumably you have to mangle the >>> instrumented >>> caller/callee in some manner. Right? Or are you dynamically dispatching >>> somehow? >> >> >> Originally the idea was o have instrumented clone to have the same >> assembler name as the original function. Since instrumented code is >> fully compatible with not instrumented code, we always emit only one >> version. Usage of the same assembler name allows instrumented and not >> instrumented calls to look similar in assembler. It worked fine until >> I tried it with LTO where assembler name is used as a unique >> identifier. With linker resolutions files it became even more harder >> to use such approach. To resolve these issues I started to use new >> assembler name with postfix, but linked with the original name using >> IDENTIFIER_TRANSPARENT_ALIAS. It gives different assembler names for >> clones and originals during compilation, but both clone and original >> functions have similar name in output assembler. > > OK. So if I read that correctly, it implies that the existence of bounds > information does not change the signature of the callee. This is obviously > important for C++. > > Sounds like I need to sit down with the branch and see how this works in the > new scheme. Both mpx branch and Wiki (http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler) page are up-to-date now and may be tried out either in NOP mode or with simulator. Let me know if you have any troubles with using it. Ilya > > jeff
Re: RFA: Fix calculation of size of builtin setjmp buffer
> Now we just need a __builtin_setjmp style of maintainer to review… Let's just do what I suggested in https://gcc.gnu.org/ml/gcc-patches/2011-11/msg00286.html -- Eric Botcazou
Re: [PATCH] Install sanitizer public headers (fix for PR sanitizer/61100)
On Wed, May 14, 2014 at 11:47 AM, Yury Gribov wrote: > On 05/14/2014 10:29 AM, Konstantin Serebryany wrote: >>> >>> Well, I'd say we should only install headers for components that are >>> supported by target platform. >> >> maybe yes. It just complicates the patch somewhat. > > > True... But this seems to be the preferred way in GCC (other runtimes also > list headers explicitly). Ok, thanks! > > -Y
[build, lto-plugin] Check for -static-libgcc before use (PR lto/60981)
As reported in the PR, the lto-plugin may fail to link if the host
compiler defines __GNUC__, but doesn't accept -static-libgcc (like
recent versions of clang do).
The following patch fixes this by explicitly checking for -static-libgcc
instead of relying on __GNUC__/$GNUC.
Tested by configuring lto-plugin with Studio cc (which doesn't define
__GNUC__) and gcc. The submitter also verified that the patch fixes his
problem.
Ok for mainline and the 4.9 branch?
Rainer
2014-05-13 Rainer Orth
PR lto/60981
* configure.ac: Check for -static-libgcc.
* configure: Regenerate.
# HG changeset patch
# Parent bde9dfb664a2e0b4b142432eb8f79f82660e7ab2
Check for -static-libgcc before use (PR lto/60981)
diff --git a/lto-plugin/configure.ac b/lto-plugin/configure.ac
--- a/lto-plugin/configure.ac
+++ b/lto-plugin/configure.ac
@@ -7,9 +7,21 @@ AM_MAINTAINER_MODE
AC_PROG_CC
AC_SYS_LARGEFILE
ACX_PROG_CC_WARNING_OPTS([-Wall], [ac_lto_plugin_warn_cflags])
+
+# Check whether -static-libgcc is supported.
+saved_LDFLAGS="$LDFLAGS"
+LDFLAGS="$LDFLAGS -static-libgcc"
+AC_MSG_CHECKING([for -static-libgcc])
+AC_LINK_IFELSE([
+ int main() {}], [have_static_libgcc=yes], [have_static_libgcc=no])
+AC_MSG_RESULT($have_static_libgcc);
+LDFLAGS="$saved_LDFLAGS"
# Need -Wc to get it through libtool.
-if test "x$GCC" = xyes; then ac_lto_plugin_ldflags="-Wc,-static-libgcc"; fi
+if test "x$have_static_libgcc" = xyes; then
+ ac_lto_plugin_ldflags="-Wc,-static-libgcc"
+fi
AC_SUBST(ac_lto_plugin_ldflags)
+
AM_PROG_LIBTOOL
ACX_LT_HOST_FLAGS
AC_SUBST(target_noncanonical)
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Install sanitizer public headers (fix for PR sanitizer/61100)
On 05/14/2014 10:46 AM, Jakub Jelinek wrote: Ok. Thanks, submitted in r210413. -Y
Re: PR 61084: SPARC fallout from wide-int merge
> PR target/61084 > * config/sparc/sparc.md: Fix types of low and high in DI constant > splitter. Use gen_int_mode in some other splitters. OK, thanks. -- Eric Botcazou
[PATCH] Fix PR 60901
Hello,
This ICE comes from the ix86_dependencies_evaluation_hook code assumption
that any scheduling region will be connected. This assumption is not
correct in case of the outer loops pipelining of the selective scheduler as
explained in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901#c3.
Trying to add dependencies between insns from the different scheduling
regions results in a segfault within the dependency analyzer code.
The fix is to adjust the code to account for the situation when basic
block's predecessors do not belong to the same scheduling region.
Bootstrapped and tested on x86-64, OK for trunk? Branches? The fix is low
risk as the additional test should always be true for the regular scheduler.
Yours,
Andrey
gcc/
2014-05-14 Andrey Belevantsev
PR rtl-optimization/60901
* config/i386/i386.c (ix86_dependencies_evaluation_hook): Check that bb
predecessor belongs to the same scheduling region. Adjust comment.
testsuite/
2014-05-14 Andrey Belevantsev
PR rtl-optimization/60901
* gcc.dg/pr60901.c: New test.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 99f0657..0274288 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -26254,13 +26254,17 @@ ix86_dependencies_evaluation_hook (rtx head, rtx tail)
{
edge e;
edge_iterator ei;
- /* Assume that region is SCC, i.e. all immediate predecessors
- of non-head block are in the same region. */
+
+ /* Regions are SCCs with the exception of selective
+ scheduling with pipelining of outer blocks enabled.
+ So also check that immediate predecessors of a non-head
+ block are in the same region. */
FOR_EACH_EDGE (e, ei, bb->preds)
{
/* Avoid creating of loop-carried dependencies through
- using topological odering in region. */
- if (BLOCK_TO_BB (bb->index) > BLOCK_TO_BB (e->src->index))
+ using topological ordering in the region. */
+ if (rgn == CONTAINING_RGN (e->src->index)
+ && BLOCK_TO_BB (bb->index) > BLOCK_TO_BB (e->src->index))
add_dependee_for_func_arg (first_arg, e->src);
}
}
diff --git a/gcc/testsuite/gcc.dg/pr60901.c b/gcc/testsuite/gcc.dg/pr60901.c
new file mode 100644
index 000..1350f16
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr60901.c
@@ -0,0 +1,18 @@
+/* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
+/* { dg-options "-O -fselective-scheduling -fschedule-insns -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -fno-tree-dominator-opts" } */
+
+extern int n;
+extern void bar (void);
+extern int baz (int);
+
+void
+foo (void)
+{
+ int i, j;
+ for (j = 0; j < n; j++)
+{
+ for (i = 1; i < j; i++)
+ bar ();
+ baz (0);
+}
+}
Re: [PATCH] cplus-demangler, free resource after a failed call to gnu_special.
Ian Lance Taylor wrote:
> Andrew Burgess wrote:
> > On 09/05/2014 9:53 PM, Ian Lance Taylor wrote:
> > > Andrew Burgess wrote:
> > > >if ((AUTO_DEMANGLING || GNU_DEMANGLING))
> > > > {
> > > > success = gnu_special (work, &mangled, &decl);
> > > > + if (!success)
> > > > +{
> > > > + delete_work_stuff (work);
> > > > + string_delete (&decl);
> > > > +}
> > >
> > > As far as I can see, decl may be uninitialized at this point. I
> > > don't think you can call string_delete. You need to ensure that
> > > decl is initialized somehow.
> >
> > There's a call to string_init on decl about 10 lines above the
> > above diff, just outside of context, but it's unconditional, so
> > I figured that would be enough.
> >
> > Also, if gnu_special returns false, and the call to
> > demangle_prefix returns false then we call (near the bottom of
> > internal_cplus_demangle) mop_up, which calls string_delete.
> >
> > Given that decl is initialised once, assuming that the string is
> > only released using delete_string then the internal state will
> > have been reset back to NULL, so calling delete_string should be
> > safe again.
>
> Right, sorry for the noise.
>
> This patch is OK.
Andrew, would you like me to commit this?
Thanks,
Gary
--
http://gbenson.net/
RE: [PATCH] Remove "keep_aligning" from get_inner_reference
Hi Eric,
On Wed, 14 May 2014 09:28:55, Eric Botcazou wrote:
>
>>> So does this remove the last concern around Bernd's patch?
>>
>> And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used
>> by obj-c/c++ as well, but I can't find such use)
>
> Probably but, as previously indicated, I need to do some testing first.
>
> --
> Eric Botcazou
Ok sure, I'll be patient...
If I remove this line, the build fails:
gcc-interface/decl.c:gnat_to_gnu_entity:
/* Tell the middle-end that objects of tagged types are guaranteed to
be properly aligned. This is necessary because conversions to the
class-wide type are translated into conversions to the root type,
which can be less aligned than some of its derived types. */
if (Is_Tagged_Type (gnat_entity)
|| Is_Class_Wide_Equivalent_Type (gnat_entity))
TYPE_ALIGN_OK (gnu_type) = 1;
but only because this bit is read back in the ada/gcc-interface.
If I apply my patch, and additionally remove this line in expr.c,
which is one of the last references to TYPE_ALIGN_OK in the middle-end:
if (TYPE_ALIGN_OK (type))
{
/* ??? Copying the MEM without substantially changing it might
run afoul of the code handling volatile memory references in
store_expr, which assumes that TARGET is returned unmodified
if it has been used. */
op0 = copy_rtx (op0);
set_mem_align (op0, MAX (MEM_ALIGN (op0), TYPE_ALIGN (type)));
}
nothing changes. All test cases pass, and again I can not see any difference in
the
generated code (I compare gcc/ada/*.o with and without patch).
So, currently I am under the impression that TYPE_ALIGN_OK has some relevance
to the Ada front-end, but it should not be used in the middle-end and certainly
not
in the back-end.
Bernd.
[PATCH][C-family] Fix PR61184
The following fixes pre/post-inc/dec gimplification of promoted
integer types. There is the issue with the way TYPE_OVERFLOW_UNDEFINED
is related to TYPE_OVERFLOW_WRAPS and the (non-)semantics of
-fno-strict-overflow.
In this case, with -On -fno-strict-overflow for a variable of
type short we have !TYPE_OVERFLOW_WRAPS _and_ !TYPE_OVERFLOW_UNDEFINED
(so we're in an "undefined" area). Which means that
!TYPE_OVERFLOW_UNDEFINED doesn't imply that overflow wraps.
Thus the gimplification has to play on the safe side and
always use an unsigned type unless the user specifies -fwrapv
(the flag with a proper semantic meaning).
That is, it seems to be the case that what predicate to use
(TYPE_OVERFLOW_WRAPS or TYPE_OVERFLOW_UNDEFINED, independent
on whether you invert it), depends on the use-case in a very
awkward (and error-prone) way.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu, ok
if that succeeds (I expect to have to adjust some testcases)?
Thanks,
Richard.
2014-05-14 Richard Biener
c-family/
* c-gimplify.c (c_gimplify_expr): Gimplify self-modify expressions
using unsigned arithmetic if overflow does not wrap instead of
if overflow is undefined.
* c-c++-common/torture/pr61184.c: New testcase.
Index: gcc/c-family/c-gimplify.c
===
*** gcc/c-family/c-gimplify.c (revision 210354)
--- gcc/c-family/c-gimplify.c (working copy)
*** c_gimplify_expr (tree *expr_p, gimple_se
*** 199,207
tree type = TREE_TYPE (TREE_OPERAND (*expr_p, 0));
if (INTEGRAL_TYPE_P (type) && c_promoting_integer_type_p (type))
{
! if (TYPE_OVERFLOW_UNDEFINED (type)
! || ((flag_sanitize & SANITIZE_SI_OVERFLOW)
! && !TYPE_OVERFLOW_WRAPS (type)))
type = unsigned_type_for (type);
return gimplify_self_mod_expr (expr_p, pre_p, post_p, 1, type);
}
--- 199,205
tree type = TREE_TYPE (TREE_OPERAND (*expr_p, 0));
if (INTEGRAL_TYPE_P (type) && c_promoting_integer_type_p (type))
{
! if (!TYPE_OVERFLOW_WRAPS (type))
type = unsigned_type_for (type);
return gimplify_self_mod_expr (expr_p, pre_p, post_p, 1, type);
}
Index: gcc/testsuite/c-c++-common/torture/pr61184.c
===
*** gcc/testsuite/c-c++-common/torture/pr61184.c(revision 0)
--- gcc/testsuite/c-c++-common/torture/pr61184.c(working copy)
***
*** 0
--- 1,18
+ /* { dg-do run } */
+ /* { dg-additional-options "-fno-strict-overflow" } */
+
+ short a;
+
+ void
+ foo (void)
+ {
+ for (a = 0; a >= 0; a++)
+ ;
+ }
+
+ int
+ main ()
+ {
+ foo ();
+ return 0;
+ }
Re: [PATCH] Fix PR 60901
On Wed, May 14, 2014 at 10:57 AM, Andrey Belevantsev wrote:
> This ICE comes from the ix86_dependencies_evaluation_hook code assumption
> that any scheduling region will be connected. This assumption is not
> correct in case of the outer loops pipelining of the selective scheduler as
> explained in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901#c3.
> Trying to add dependencies between insns from the different scheduling
> regions results in a segfault within the dependency analyzer code.
>
> The fix is to adjust the code to account for the situation when basic
> block's predecessors do not belong to the same scheduling region.
>
> Bootstrapped and tested on x86-64, OK for trunk? Branches? The fix is low
> risk as the additional test should always be true for the regular scheduler.
I don't know all scheduler details, so your opinion counts there.
Let's put this fix to mainline first and after a week without
problems, backport it to all release branches.
> gcc/
> 2014-05-14 Andrey Belevantsev
>
> PR rtl-optimization/60901
>
> * config/i386/i386.c (ix86_dependencies_evaluation_hook): Check that
> bb predecessor belongs to the same scheduling region. Adjust comment.
>
> testsuite/
> 2014-05-14 Andrey Belevantsev
>
> PR rtl-optimization/60901
> * gcc.dg/pr60901.c: New test.
+/* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
+/* { dg-options "-O -fselective-scheduling -fschedule-insns
-fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
-fno-tree-dominator-opts" } */
+
As this is clearly a target bug, let's put the test in gcc.target/i386
directory. You can remove target selector, and the test will run for
64bit and 32bit targets automatically.
Thanks,
Uros.
[PATCH] Fix PR 60866
Hello,
As described in the PR in more details, this ICE is about the scheduler not
being able to initialize its data structures for the new unconditional jump
created when redirecting an edge and simplifying control flow. It so
happens that the new jump is the only unscheduled instruction being left so
we need to pass some of its data from the old jump. The difficulty is to
support only this particular situation to retain the existing checking code
and to pass down the required information to the point where it is needed.
I assume that we are able to use default parameters as I haven't heard
otherwise.
Bootstrapped and tested on x86-64, OK for trunk and branches? Branches
should also be safe as we're fixing only very specific corner case (hey, we
regressed four releases and nobody noticed until now).
Yours,
Andrey
gcc/
2014-05-14 Andrey Belevantsev
PR rtl-optimization/60866
* sel-sched-ir (sel_init_new_insn): New parameter old_seqno.
Default it to -1. Pass it down to init_simplejump_data.
(init_simplejump_data): New parameter old_seqno. Pass it down
to get_seqno_for_a_jump.
(get_seqno_for_a_jump): New parameter old_seqno. Use it for
initializing new jump seqno as a last resort. Add comment.
(sel_redirect_edge_and_branch): Save old seqno of the conditional
jump and pass it down to sel_init_new_insn.
(sel_redirect_edge_and_branch_force): Likewise.
testsuite/
2014-05-14 Andrey Belevantsev
PR rtl-optimization/60866
* gcc.dg/pr60866.c: New test.
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 868083b..3cba326 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -162,7 +162,7 @@ static void create_initial_data_sets (basic_block);
static void free_av_set (basic_block);
static void invalidate_av_set (basic_block);
static void extend_insn_data (void);
-static void sel_init_new_insn (insn_t, int);
+static void sel_init_new_insn (insn_t, int, int = -1);
static void finish_insns (void);
/* Various list functions. */
@@ -4007,9 +4007,10 @@ get_seqno_by_succs (rtx insn)
return seqno;
}
-/* Compute seqno for INSN by its preds or succs. */
+/* Compute seqno for INSN by its preds or succs. Use OLD_SEQNO to compute
+ seqno in corner cases. */
static int
-get_seqno_for_a_jump (insn_t insn)
+get_seqno_for_a_jump (insn_t insn, int old_seqno)
{
int seqno;
@@ -4065,8 +4066,16 @@ get_seqno_for_a_jump (insn_t insn)
if (seqno < 0)
seqno = get_seqno_by_succs (insn);
- gcc_assert (seqno >= 0);
+ if (seqno < 0)
+{
+ /* The only case where this could be here legally is that the only
+ unscheduled insn was a conditional jump that got removed and turned
+ into this unconditional one. Initialize from the old seqno
+ of that jump passed down to here. */
+ seqno = old_seqno;
+}
+ gcc_assert (seqno >= 0);
return seqno;
}
@@ -4246,22 +4255,24 @@ init_insn_data (insn_t insn)
}
/* This is used to initialize spurious jumps generated by
- sel_redirect_edge (). */
+ sel_redirect_edge (). OLD_SEQNO is used for initializing seqnos
+ in corner cases within get_seqno_for_a_jump. */
static void
-init_simplejump_data (insn_t insn)
+init_simplejump_data (insn_t insn, int old_seqno)
{
init_expr (INSN_EXPR (insn), vinsn_create (insn, false), 0,
REG_BR_PROB_BASE, 0, 0, 0, 0, 0, 0,
vNULL, true, false, false,
false, true);
- INSN_SEQNO (insn) = get_seqno_for_a_jump (insn);
+ INSN_SEQNO (insn) = get_seqno_for_a_jump (insn, old_seqno);
init_first_time_insn_data (insn);
}
/* Perform deferred initialization of insns. This is used to process
- a new jump that may be created by redirect_edge. */
-void
-sel_init_new_insn (insn_t insn, int flags)
+ a new jump that may be created by redirect_edge. OLD_SEQNO is used
+ for initializing simplejumps in init_simplejump_data. */
+static void
+sel_init_new_insn (insn_t insn, int flags, int old_seqno)
{
/* We create data structures for bb when the first insn is emitted in it. */
if (INSN_P (insn)
@@ -4288,7 +4299,7 @@ sel_init_new_insn (insn_t insn, int flags)
if (flags & INSN_INIT_TODO_SIMPLEJUMP)
{
extend_insn_data ();
- init_simplejump_data (insn);
+ init_simplejump_data (insn, old_seqno);
}
gcc_assert (CONTAINING_RGN (BLOCK_NUM (insn))
@@ -5575,14 +5586,14 @@ sel_merge_blocks (basic_block a, basic_block b)
}
/* A wrapper for redirect_edge_and_branch_force, which also initializes
- data structures for possibly created bb and insns. Returns the newly
- added bb or NULL, when a bb was not needed. */
+ data structures for possibly created bb and insns. */
void
sel_redirect_edge_and_branch_force (edge e, basic_block to)
{
basic_block jump_bb, src, orig_dest = e->dest;
int prev_max_uid;
rtx jump;
+ int old_seqno = -1;
/* This function is now used only for bookkeeping code creation, w
Re: [build, lto-plugin] Check for -static-libgcc before use (PR lto/60981)
On Wed, May 14, 2014 at 10:31 AM, Rainer Orth wrote: > As reported in the PR, the lto-plugin may fail to link if the host > compiler defines __GNUC__, but doesn't accept -static-libgcc (like > recent versions of clang do). > > The following patch fixes this by explicitly checking for -static-libgcc > instead of relying on __GNUC__/$GNUC. > > Tested by configuring lto-plugin with Studio cc (which doesn't define > __GNUC__) and gcc. The submitter also verified that the patch fixes his > problem. > > Ok for mainline and the 4.9 branch? Ok if nobody else objects within 24h. Thanks, Richard. > Rainer > > > 2014-05-13 Rainer Orth > > PR lto/60981 > * configure.ac: Check for -static-libgcc. > * configure: Regenerate. > > > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University >
RE: [Patch,Microblaze]: Added Break Handler Support
Based on the Feedback, Resubmitting the Updated Patch.
[Patch, MicroBlaze] Add break Handler Support
Added Break Handler support to incorporate the hardware and software break. The
Break Handler routine
will be generating the rtbd instruction. At the call point where the software
breaks are generated with
the instruction brki with register operand as r16.
ChangeLog:
2014-05-14 Ajit Agarwal
* config/microblaze/microblaze.c
(break_handler): New Declaration.
(microblaze_break_function_p,microblaze_is_break_handler) : New functions.
(compute_frame_size): use of microblaze_break_function_p. Add the test of
break_handler.
(microblaze_function_prologue) : Add the test of variable
break_handler. Check the fnname by BREAK_HANDLER_NAME.
(microblaze_function_epilogue) : Add the test of break_handler.
(microblaze_globalize_label) : Add the test of break_handler. Check the
name by BREAK_HANDLER_NAME.
* config/microblaze/microblaze.h (BREAK_HANDLER_NAME) : New macro
* config/microblaze/microblaze.md :
(*,_internal): Add microblaze_is_break_handler () test.
(call_internal1,call_value_intern) : Use of microblaze_break_function_p.
Use of SYMBOL_REF_DECL.
* config/microblaze/microblaze-protos.h
(microblaze_break_function_p,microblaze_is_break_handler) : New Declaration.
* testsuite/gcc.target/microblaze/others/break_handler.c : New.
* doc/extend.texi( MicroBlaze break_handler Functions): Document new
MicroBlaze break_handler functions.
Signed-off-by:Ajit Agarwal
---
gcc/config/microblaze/microblaze-protos.h |4 +-
gcc/config/microblaze/microblaze.c | 45 +---
gcc/config/microblaze/microblaze.h |5 ++-
gcc/config/microblaze/microblaze.md| 34 ++
gcc/doc/extend.texi| 12 +
.../gcc.target/microblaze/others/break_handler.c | 15 +++
6 files changed, 97 insertions(+), 18 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/microblaze/others/break_handler.c
diff --git a/gcc/config/microblaze/microblaze-protos.h
b/gcc/config/microblaze/microblaze-protos.h
index b03e9e1..f3cc099 100644
--- a/gcc/config/microblaze/microblaze-protos.h
+++ b/gcc/config/microblaze/microblaze-protos.h
@@ -40,10 +40,12 @@ extern void print_operand_address (FILE *, rtx);
extern void init_cumulative_args (CUMULATIVE_ARGS *,tree, rtx);
extern bool microblaze_legitimate_address_p (enum machine_mode, rtx, bool);
extern int microblaze_is_interrupt_variant (void);
+extern int microblaze_is_break_handler (void);
+extern int microblaze_break_function_p (tree func);
extern rtx microblaze_return_addr (int, rtx);
extern int simple_memory_operand (rtx, enum machine_mode);
extern int double_memory_operand (rtx, enum machine_mode);
-
+extern void microblaze_order_regs_for_local_alloc (void);
extern int microblaze_regno_ok_for_base_p (int, int);
extern HOST_WIDE_INT microblaze_initial_elimination_offset (int, int);
extern void microblaze_declare_object (FILE *, const char *, const char *,
diff --git a/gcc/config/microblaze/microblaze.c
b/gcc/config/microblaze/microblaze.c
index ba8109b..b7e9675 100644
--- a/gcc/config/microblaze/microblaze.c
+++ b/gcc/config/microblaze/microblaze.c
@@ -209,6 +209,7 @@ enum reg_class microblaze_regno_to_class[] =
and epilogue and use appropriate interrupt return.
save_volatiles- Similar to interrupt handler, but use normal return. */
int interrupt_handler;
+int break_handler;
int fast_interrupt;
int save_volatiles;
@@ -217,6 +218,8 @@ const struct attribute_spec microblaze_attribute_table[] = {
affects_type_identity */
{"interrupt_handler", 0, 0, true,false, false,NULL,
false },
+ {"break_handler", 0, 0, true,false, false,NULL,
+false },
{"fast_interrupt",0, 0, true,false, false,NULL,
false },
{"save_volatiles" , 0, 0, true,false, false,NULL,
@@ -1866,7 +1869,18 @@ microblaze_fast_interrupt_function_p (tree func)
a = lookup_attribute ("fast_interrupt", DECL_ATTRIBUTES (func));
return a != NULL_TREE;
}
+int
+microblaze_break_function_p (tree func)
+{
+ tree a;
+ if (!func)
+return 0;
+ if (TREE_CODE (func) != FUNCTION_DECL)
+return 0;
+ a = lookup_attribute ("break_handler", DECL_ATTRIBUTES (func));
+ return a != NULL_TREE;
+}
/* Return true if FUNC is an interrupt function which uses
normal return, indicated by the "save_volatiles" attribute. */
@@ -1891,6 +1905,13 @@ microblaze_is_interrupt_variant (void)
{
return (interrupt_handler || fast_interrupt);
}
+int
+microblaze_is_break_handler (void)
+{
+ return break_handler;
+}
+
+
/* Determine of register must be saved/restored in call. */
static int
@@ -1994,9 +2015,14 @@ compute_frame_size (HOST_WIDE_INT size)
interrupt_handler =
microblaze_
Re: [PATCH] cplus-demangler, free resource after a failed call to gnu_special.
On 14/05/2014 10:01 AM, Gary Benson wrote:
> Ian Lance Taylor wrote:
>> Andrew Burgess wrote:
>>> On 09/05/2014 9:53 PM, Ian Lance Taylor wrote:
Andrew Burgess wrote:
>if ((AUTO_DEMANGLING || GNU_DEMANGLING))
> {
> success = gnu_special (work, &mangled, &decl);
> + if (!success)
> +{
> + delete_work_stuff (work);
> + string_delete (&decl);
> +}
>>
>> This patch is OK.
>
> Andrew, would you like me to commit this?
Yes please.
Thanks,
Andrew
Re: [PATCH] Provide inlining context in strict-overflow warnings
On Tue, May 13, 2014 at 9:27 PM, Florian Weimer wrote: > Patterns that trigger the optimization and warning can form after inlining, > and it can be rather difficult to figure out what exactly is causing the > warning. The inlining context at least provides additional hints, enabling > developers to substitute the arguments and discover what, precisely, is > happening. > > More context is provided with -g than without, but I think this is > acceptable. > > I bootstrapped and tested the attached patch on x86_64-redhat-linux-gnu, > with no new regressions. I think that your block walking code is bogus in that it looks at only BLOCK_SOURCE_LOCATION, exposing an implementation detail that should be hidden by using inlined_function_outer_scope_p. It also will print an unlimited call stack - isn't that too verbose? Thanks, Richard. > -- > Florian Weimer / Red Hat Product Security Team
Re: [PATCH] Fix PR 60901
On 14.05.2014 13:09, Uros Bizjak wrote:
On Wed, May 14, 2014 at 10:57 AM, Andrey Belevantsev wrote:
This ICE comes from the ix86_dependencies_evaluation_hook code assumption
that any scheduling region will be connected. This assumption is not
correct in case of the outer loops pipelining of the selective scheduler as
explained in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901#c3.
Trying to add dependencies between insns from the different scheduling
regions results in a segfault within the dependency analyzer code.
The fix is to adjust the code to account for the situation when basic
block's predecessors do not belong to the same scheduling region.
Bootstrapped and tested on x86-64, OK for trunk? Branches? The fix is low
risk as the additional test should always be true for the regular scheduler.
I don't know all scheduler details, so your opinion counts there.
Let's put this fix to mainline first and after a week without
problems, backport it to all release branches.
gcc/
2014-05-14 Andrey Belevantsev
PR rtl-optimization/60901
* config/i386/i386.c (ix86_dependencies_evaluation_hook): Check that
bb predecessor belongs to the same scheduling region. Adjust comment.
testsuite/
2014-05-14 Andrey Belevantsev
PR rtl-optimization/60901
* gcc.dg/pr60901.c: New test.
+/* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
+/* { dg-options "-O -fselective-scheduling -fschedule-insns
-fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
-fno-tree-dominator-opts" } */
+
As this is clearly a target bug, let's put the test in gcc.target/i386
directory. You can remove target selector, and the test will run for
64bit and 32bit targets automatically.
Thanks for noticing, I forgot about this. Updated the test and committed
in 210414.
Andrey
Re: [PATCH] Fix PR 60866
On Wed, 14 May 2014, Andrey Belevantsev wrote: > Hello, > > As described in the PR in more details, this ICE is about the scheduler not > being able to initialize its data structures for the new unconditional jump > created when redirecting an edge and simplifying control flow. It so happens > that the new jump is the only unscheduled instruction being left so we need to > pass some of its data from the old jump. The difficulty is to support only > this particular situation to retain the existing checking code and to pass > down the required information to the point where it is needed. > > I assume that we are able to use default parameters as I haven't heard > otherwise. Default parameters are used now in several functions such as 'build_assign', 'c_build_vec_perm_expr', so that should be fine. > Bootstrapped and tested on x86-64, OK for trunk and branches? Branches should > also be safe as we're fixing only very specific corner case (hey, we regressed > four releases and nobody noticed until now). OK for trunk and 4.8, but not applicable for 4.7 since that branch does not use C++ as implementation language. Alexander
Re: [PATCH] Provide inlining context in strict-overflow warnings
On Tue, May 13, 2014 at 09:27:08PM +0200, Florian Weimer wrote: > Patterns that trigger the optimization and warning can form after > inlining, and it can be rather difficult to figure out what exactly > is causing the warning. The inlining context at least provides > additional hints, enabling developers to substitute the arguments > and discover what, precisely, is happening. > > More context is provided with -g than without, but I think this is > acceptable. > > I bootstrapped and tested the attached patch on > x86_64-redhat-linux-gnu, with no new regressions. This looks wrong. If you want to print inline context, you just should use %K%s and pass a tree with the right EXPR_LOCATION and TREE_BLOCK. So perhaps: if (stmt == NULL) warning_at (input_location, OPT_Wstrict_overflow, "%s", warnmsg); else warning_at (gimple_location (stmt), OPT_Wstrict_overflow, "%K%s", build_empty_stmt (gimple_location (stmt)), warnmsg); (or add something similar to %K that will take location_t or change %K to take location_t instead of tree now that we have both a block and locus in location_t. Note, your patch would happily crash if stmt is NULL. Jakub
Re: [RS6000] Fix PR61098, Poor code setting count register
Hi David, On Tue, May 13, 2014 at 11:46:20PM -0400, David Edelsohn wrote: > Danny may have re-organized the code, but I thought that it originally > came from Tom Rixx, if not earlier. OK, I'm not trying to apportion blame. My name is on plenty of dodgy code in the rs6000 backend too. :) > I seem to remember problems in the past with late creation of TOC > entries for constants causing problems, so it was easier to fall back > to materializing all integer constants inline. I don't remember the > PRs, but I think there were issues with creating a TOC if the late > constant were the only TOC reference, or maybe the issue was buying a > stack frame to materialize the TOC/GOT for a late constant. And > maximum 5 instruction sequence is not really bad relative to a load > from the TOC (even with medium model / data in TOC). There are a lot > of trade-offs with respect to I$ expansion versus the load hitting in > the L1 D$. Sure, but Steve will tell you that the 5 instruction sequence is both slower due to all the dependent ops, and results in larger code+data size. We definitely want to avoid it if possible, and pr67836 shows a case taken from glibc math library code where there should be no problem in using the TOC. > Alpha emit_set_const does limit the number of instructions, but that > is a search for a more efficient sequence than the naive sequence. The > Alpha splitters use alpha_split_const_mov(), which tries > alpha_emit_set_const() for an efficient sequence and then falls back > to alpha_emit_set_long_const() for a naive sequence. Alpha uses PLUS > instead of IOR because of the way its ISA works. > alpha_emit_set_long_const() always will materialize the constant and > does not check for a maximum number of instructions. This is why it's > comment says "fall back to straight forward decomposition". > > However, alpha_emit_set_long_const() and alpha_split_const_mov() can > fail, presumably because emit_move_insn() fails, not because of > reaching a maximum number of instructions. > > alpha_legitimate_constant_p() rejecs expensive constants early. Once > the splitter is invoked, it always tries to materialize the constant, > but the splitter apparently can fail for other reasons. No, that is wrong. alpha_emit_set_const does *not* always try to materialize the constant inline. It does so for constants that need more than three instructions only when TARGET_BUILD_CONSTANTS. > I don't mind exploring the benefits of tighening up > rs6000_legitimate_const(), but I'm not sure it's an obvious win, > especially with the potential failure corner cases. Yes, those potential corner cases have me worried too.. > However, I want to have a better understanding about the part of the > patch that removes the FAIL path from the splitters. That part was really quite simple. I was removing dead code. rs6000_emit_set_const has never returned anything but DEST, right from the initial commit. It can't be called with DEST == NULL, so "dest = gen_reg_rtx (mode)" is also dead code. However, I retracted that patch because I now think rs6000_emit_set_const should in fact sometimes result in the splitter failing, exactly as is done in the alpha port. -- Alan Modra Australia Development Lab, IBM
Re: [PATCH, ADA] Fix current build problems under cygwin
> OK for trunk and 4.9.1 branch? OK if Pascal has no objections to the patch: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00671.html -- Eric Botcazou
Re: [Ada] RFA: Add some "missing" integer_one_node conversions
> * gcc-interface/decl.c (gnat_to_gnu_entity): Convert > integer_one_node to the appropriate type. > * gcc-interface/trans.c (gnat_to_gnu): Likewise. > (pos_to_constructor): Likewise. OK for the sake of consistency, thanks. -- Eric Botcazou
Re: [PATCH, ADA] Fix current build problems under cygwin
Eric, > OK if Pascal has no objections to the patch: > https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00671.html Looks fine to me and should have no effect for our non Cygwin builds. -- Pascal Obry gpg --keyserver keys.gnupg.net --recv-key F949BD3B
Re: [PATCH] Provide inlining context in strict-overflow warnings
On 05/14/2014 11:34 AM, Richard Biener wrote: On Tue, May 13, 2014 at 9:27 PM, Florian Weimer wrote: Patterns that trigger the optimization and warning can form after inlining, and it can be rather difficult to figure out what exactly is causing the warning. The inlining context at least provides additional hints, enabling developers to substitute the arguments and discover what, precisely, is happening. More context is provided with -g than without, but I think this is acceptable. I bootstrapped and tested the attached patch on x86_64-redhat-linux-gnu, with no new regressions. I think that your block walking code is bogus in that it looks at only BLOCK_SOURCE_LOCATION, exposing an implementation detail that should be hidden by using inlined_function_outer_scope_p. Do you mean that I should replace the condition with inlined_function_outer_scope_p (block)? I've made this change. It also will print an unlimited call stack - isn't that too verbose? Isn't the call stack limited by inlining parameters? I don't see a good way to prune it. When investigating instances of this warning, you might need all frames. I could add a parameter and set it to some arbitrary default, like 5, and print a warning if the call stack is longer. But I don't know if this is really worth the effort, considering that the warning is somewhat rare to begin with. -- Florian Weimer / Red Hat Product Security Team
[PATCH][match-and-simplify] Fix call handling
This fixes call handling.
Committed to the branch.
Richard.
2014-05-14 Richard Biener
* gimple-match-head.c (maybe_push_res_to_seq): Fix res
!= NULL case and add a comment.
(gimple_match_and_simplify): Properly handle virtual
operands when we replace the stmt on the gsi interface.
Index: gcc/gimple-match-head.c
===
--- gcc/gimple-match-head.c (revision 210353)
+++ gcc/gimple-match-head.c (working copy)
@@ -218,13 +218,20 @@ gimple_resimplify3 (gimple_seq *seq,
}
+/* Push the exploded expression described by RCODE, TYPE and OPS
+ as a statement to SEQ if necessary and return a gimple value
+ denoting the value of the expression. If RES is not NULL
+ then the result will be always RES and even gimple values are
+ pushed to SEQ. */
+
static tree
maybe_push_res_to_seq (code_helper rcode, tree type, tree *ops,
gimple_seq *seq, tree res = NULL_TREE)
{
if (rcode.is_tree_code ())
{
- if (TREE_CODE_LENGTH ((tree_code) rcode) == 0
+ if (!res
+ && TREE_CODE_LENGTH ((tree_code) rcode) == 0
&& is_gimple_val (ops[0]))
return ops[0];
if (!seq)
@@ -544,7 +551,10 @@ gimple_match_and_simplify (gimple_stmt_i
maybe_push_res_to_seq (rcode, TREE_TYPE (lhs),
ops, &tail, lhs);
gcc_assert (gimple_seq_singleton_p (tail));
- gsi_replace (gsi, gimple_seq_first_stmt (tail), false);
+ gimple with = gimple_seq_first_stmt (tail);
+ gimple_set_vdef (with, gimple_vdef (stmt));
+ gimple_set_vuse (with, gimple_vuse (stmt));
+ gsi_replace (gsi, with, false);
}
else
/* Handle for example GIMPLE_COND, etc. */
Minor tweaks
This removes a useless local variable in emit_to_new_bb_before coming from a
patch that was later reverted, thus restoring the original code, changes the
type of locations in try_forward_edges to location_t and fixes inconsistent
comments I added to rtl_merge_blocks and cfg_layout_merge_blocks.
Tested on x86_64-suse-linux, applied on the mainline as obvious.
2014-05-14 Eric Botcazou
* cfgcleanup.c (try_forward_edges): Use location_t for locations.
* cfgrtl.c (rtl_merge_blocks): Fix comment.
(cfg_layout_merge_blocks): Likewise.
* except.c (emit_to_new_bb_before): Remove prev_bb local variable.
--
Eric BotcazouIndex: except.c
===
--- except.c (revision 210410)
+++ except.c (working copy)
@@ -949,7 +949,7 @@ static basic_block
emit_to_new_bb_before (rtx seq, rtx insn)
{
rtx last;
- basic_block bb, prev_bb;
+ basic_block bb;
edge e;
edge_iterator ei;
@@ -964,8 +964,7 @@ emit_to_new_bb_before (rtx seq, rtx insn
last = emit_insn_before (seq, insn);
if (BARRIER_P (last))
last = PREV_INSN (last);
- prev_bb = BLOCK_FOR_INSN (insn)->prev_bb;
- bb = create_basic_block (seq, last, prev_bb);
+ bb = create_basic_block (seq, last, BLOCK_FOR_INSN (insn)->prev_bb);
update_bb_for_insn (bb);
bb->flags |= BB_SUPERBLOCK;
return bb;
Index: cfgcleanup.c
===
--- cfgcleanup.c (revision 210410)
+++ cfgcleanup.c (working copy)
@@ -425,7 +425,8 @@ try_forward_edges (int mode, basic_block
for (ei = ei_start (b->succs); (e = ei_safe_edge (ei)); )
{
basic_block target, first;
- int counter, goto_locus;
+ location_t goto_locus;
+ int counter;
bool threaded = false;
int nthreaded_edges = 0;
bool may_thread = first_pass || (b->flags & BB_MODIFIED) != 0;
@@ -477,8 +478,8 @@ try_forward_edges (int mode, basic_block
{
/* When not optimizing, ensure that edges or forwarder
blocks with different locus are not optimized out. */
- int new_locus = single_succ_edge (target)->goto_locus;
- int locus = goto_locus;
+ location_t new_locus = single_succ_edge (target)->goto_locus;
+ location_t locus = goto_locus;
if (new_locus != UNKNOWN_LOCATION
&& locus != UNKNOWN_LOCATION
Index: cfgrtl.c
===
--- cfgrtl.c (revision 210410)
+++ cfgrtl.c (working copy)
@@ -889,7 +889,7 @@ rtl_merge_blocks (basic_block a, basic_b
BB_HEAD (b) = b_empty ? NULL_RTX : b_head;
delete_insn_chain (del_first, del_last, true);
- /* When not optimizing CFG and the edge is the only place in RTL which holds
+ /* When not optimizing and the edge is the only place in RTL which holds
some unique locus, emit a nop with that locus in between. */
if (!optimize)
{
@@ -4564,7 +4564,7 @@ cfg_layout_merge_blocks (basic_block a,
try_redirect_by_replacing_jump (EDGE_SUCC (a, 0), b, true);
gcc_assert (!JUMP_P (BB_END (a)));
- /* When not optimizing CFG and the edge is the only place in RTL which holds
+ /* When not optimizing and the edge is the only place in RTL which holds
some unique locus, emit a nop with that locus in between. */
if (!optimize)
emit_nop_for_unique_locus_between (a, b);
[patch] Minor improvement to fold_unary_loc
Hi, this makes fold_unary_loc fold NON_LVALUE_EXPR if the argument cannot be a lvalue (this happens when you're re-fold-building an existing tree) and changes the first call to fold_convert_const to use arg0 instead of op0, like the other 2 calls just below (this should not change anything if the argument is correctly folded, but is more forgiving if it is not). Tested on x86_64-suse-linux, OK for the mainline? 2014-05-14 Eric Botcazou * fold-const (fold_unary_loc) : New case. : Pass arg0 instead of op0 to fold_convert_const. -- Eric BotcazouIndex: fold-const.c === --- fold-const.c (revision 210410) +++ fold-const.c (working copy) @@ -7850,6 +7850,11 @@ fold_unary_loc (location_t loc, enum tre return fold_convert_loc (loc, type, op0); return NULL_TREE; +case NON_LVALUE_EXPR: + if (!maybe_lvalue_p (op0)) + return fold_convert_loc (loc, type, op0); + return NULL_TREE; + CASE_CONVERT: case FLOAT_EXPR: case FIX_TRUNC_EXPR: @@ -8113,7 +8118,7 @@ fold_unary_loc (location_t loc, enum tre } } - tem = fold_convert_const (code, type, op0); + tem = fold_convert_const (code, type, arg0); return tem ? tem : NULL_TREE; case ADDR_SPACE_CONVERT_EXPR:
Re: [Patch, avr] Propagate -mrelax gcc driver flag to assembler
Am 05/13/2014 02:48 PM, schrieb Senthil Kumar Selvaraj:
On Mon, May 12, 2014 at 01:19:37PM +0200, Georg-Johann Lay wrote:
Am 04/18/2014 11:52 AM, schrieb Senthil Kumar Selvaraj:
On Sat, Apr 12, 2014 at 06:36:01PM +0200, Georg-Johann Lay wrote:
Senthil Kumar Selvaraj schrieb:
[...]
2014-04-18 Senthil Kumar Selvaraj
* config/avr/avr.h: Pass on mlink-relax to assembler.
* configure.ac: Test for mlink-relax support in assembler.
* configure: Regenerate.
diff --git gcc/config/avr/avr.h gcc/config/avr/avr.h
index 78434ec..b4e3eb1 100644
--- gcc/config/avr/avr.h
+++ gcc/config/avr/avr.h
@@ -512,7 +512,28 @@ extern const char *avr_device_to_sp8 (int argc, const char
**argv);
%{!fenforce-eh-specs:-fno-enforce-eh-specs} \
%{!fexceptions:-fno-exceptions}"
-#define ASM_SPEC "%:device_to_as(%{mmcu=*:%*}) "
+#ifdef HAVE_AS_RELAX_OPTION
+#define ASM_RELAX_SPEC "%{mrelax:-mlink-relax}"
+#else
+#define ASM_RELAX_SPEC ""
+#endif
+
+#define ASM_SPEC "%:device_to_as(%{mmcu=*:%*})\
+%(asm_relax)"
+
+/* This macro defines names of additional specifications to put in the specs
+ that can be used in various specifications like CC1_SPEC. Its definition
+ is an initializer with a subgrouping for each command option.
+
+ Each subgrouping contains a string constant, that defines the
+ specification name, and a string constant that used by the GCC driver
+ program.
+
+ Do not define this macro if it does not need to do anything. */
+
+#define EXTRA_SPECS \
+ { "asm_relax", ASM_RELAX_SPEC }
+
Hi, wouldn't it be easier to add just a line to driver-avr.c:avr_device_to_as ?
Well, I couldn't figure out how to do it without passing in the nested spec and
then do argument checking inside avr_device_to_as. Something like
#define ASM_SPEC "%:device_to_as(%{mmcu=*:%*} %{mrelax:-mlink-relax})"
and then handle argc==0, 1 and 2 cases by strcmp'ing against
-mlink-relax if HAVE_AVR_AS_LINK_RELAX_OPTION.
Did I miss something?
Or what about simply that, which works for me:
Index: config/avr/avr.h
===
--- config/avr/avr.h(revision 210276)
+++ config/avr/avr.h(working copy)
@@ -512,7 +512,11 @@ extern const char *avr_device_to_sp8 (in
%{!fenforce-eh-specs:-fno-enforce-eh-specs} \
%{!fexceptions:-fno-exceptions}"
+#ifdef HAVE_AS_AVR_LINK_RELAX_OPTION
+#define ASM_SPEC "%:device_to_as(%{mmcu=*:%*}) %{mrelax:-mlink-relax} "
+#else
#define ASM_SPEC "%:device_to_as(%{mmcu=*:%*}) "
+#endif
#define LINK_SPEC "\
%{mrelax:--relax\
Johann
Re: [PATCH] Add support for GNU/Hurd in gnat-4.9
> Attached is a patch for support of GNU/Hurd in gnat-4.9. This patch has > been used and updated in Debian since gnat-4.6, and is currently used to > build gnat-4.9. Now when the body file s-osinte-posix.adb in gcc-4.9 > defines tv_nsec in timespec POSIX-correctly as long again, we think it > is time that it goes upstream. The patch contains two parts: > > src/gcc/ada/gcc-interface/Makefile.in: > Defines LIBGNAT_TARGET_PAIRS for GNU/Hurd > > src/gcc/ada/s-osinte-gnu.ads: > A new file giving the OS interface specification for GNU/Hurd. This file > is a modification of the already existing s-osinte-*.ads files. It's quite nice that you need only one specific file for GNU/Hurd. This is mostly OK, but your LIBGNAT_TARGET_PAIRS looks a bit outdated, specifically for the atomic support, see the other *BSD for reference. -- Eric Botcazou
Re: [Patch, avr] Propagate -mrelax gcc driver flag to assembler
Georg-Johann Lay writes:
> Or what about simply that, which works for me:
>
>
> Index: config/avr/avr.h
> ===
> --- config/avr/avr.h(revision 210276)
> +++ config/avr/avr.h(working copy)
> @@ -512,7 +512,11 @@ extern const char *avr_device_to_sp8 (in
> %{!fenforce-eh-specs:-fno-enforce-eh-specs} \
> %{!fexceptions:-fno-exceptions}"
>
> +#ifdef HAVE_AS_AVR_LINK_RELAX_OPTION
> +#define ASM_SPEC "%:device_to_as(%{mmcu=*:%*}) %{mrelax:-mlink-relax} "
> +#else
> #define ASM_SPEC "%:device_to_as(%{mmcu=*:%*}) "
> +#endif
>
> #define LINK_SPEC "\
> %{mrelax:--relax\
Better yet something like
#ifdef HAVE_AS_AVR_LINK_RELAX_OPTION
#define LINK_RELAX_SPEC "%{mrelax:-mlink-relax} "
#else
#define LINK_RELAX_SPEC ""
#endif
#define ASM_SPEC "%:device_to_as(%{mmcu=*:%*}) " LINK_RELAX_SPEC
to avoid unnecessary duplication.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH][match-and-simplify] Support re-simplification of two-arg builtins
This handles $subject which allows us to simplify the return expression
all the way to w for the following testcase (going via
pow (x, -0.5) * x -> pow (x, 0.5) -> sqrt (w * w) -> w)
double test4 (double w)
{
double x = w * w;
double y = __builtin_pow (x, -0.5);
return y * x;
}
Committed to the branch.
Richard.
2014-05-14 Richard Biener
* gimple-match-head.c (REAL_CST_P): New predicate.
(gimple_match_and_simplify): Support re-simplification of
two-argument builtin functions.
* match.pd: Add pattern simplifying pow (x, 0.5) to sqrt (x).
testsuite/
* gcc.dg/tree-ssa/match-1.c: Add testcase involving two-argument
function re-simplification.
Index: gcc/gimple-match-head.c
===
--- gcc/gimple-match-head.c (revision 210415)
+++ gcc/gimple-match-head.c (working copy)
@@ -38,6 +38,7 @@ along with GCC; see the file COPYING3.
#define INTEGER_CST_P(node) (TREE_CODE(node) == INTEGER_CST)
#define integral_op_p(node) INTEGRAL_TYPE_P(TREE_TYPE(node))
+#define REAL_CST_P(node) (TREE_CODE(node) == REAL_CST)
/* Helper to transparently allow tree codes and builtin function codes
@@ -495,6 +496,27 @@ gimple_match_and_simplify (gimple stmt,
rcode, ops,
seq, valueize);
}
+ case 2:
+ {
+ tree arg1 = gimple_call_arg (stmt, 0);
+ if (valueize && TREE_CODE (arg1) == SSA_NAME)
+ {
+ arg1 = valueize (arg1);
+ if (!arg1)
+ return false;
+ }
+ tree arg2 = gimple_call_arg (stmt, 0);
+ if (valueize && TREE_CODE (arg2) == SSA_NAME)
+ {
+ arg2 = valueize (arg2);
+ if (!arg2)
+ return false;
+ }
+ return gimple_match_and_simplify (DECL_FUNCTION_CODE (decl),
+ type, arg1, arg2,
+ rcode, ops,
+ seq, valueize);
+ }
default:
return false;
}
Index: gcc/match.pd
===
--- gcc/match.pd(revision 210414)
+++ gcc/match.pd(working copy)
@@ -163,6 +163,10 @@ to (minus @1 @0)
(match_and_simplify
(mult (BUILT_IN_POW @0 @1) @0)
(BUILT_IN_POW @0 (PLUS_EXPR @1 { build_one_cst (TREE_TYPE (@1)); })))
+(match_and_simplify
+ (BUILT_IN_POW @0 REAL_CST_P@1)
+ if (REAL_VALUES_EQUAL (TREE_REAL_CST (@1), dconsthalf))
+ (BUILT_IN_SQRT @0))
/* s
Index: gcc/testsuite/gcc.dg/tree-ssa/match-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/match-1.c (revision 210414)
+++ gcc/testsuite/gcc.dg/tree-ssa/match-1.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O -fdump-tree-forwprop" } */
+/* { dg-options "-O -fdump-tree-forwprop1-details" } */
double test1 (_Complex double z)
{
@@ -7,6 +7,8 @@ double test1 (_Complex double z)
return __builtin_cabs (z);
}
+/* { dg-final { scan-tree-dump "gimple_match_and_simplified to \[^\n\r\]*fabs"
"forwprop1" } } */
+
double test2 (double x)
{
_Complex z = x;
@@ -14,12 +16,23 @@ double test2 (double x)
return __builtin_cabs (z);
}
+/* { dg-final { scan-tree-dump "gimple_match_and_simplified to \[^\n\r\]*=
_\\d\+ \\* 1.41" "forwprop1" } } */
+
double test3 (double x)
{
double y = __builtin_pow (x, 5.);
return y * x;
}
-/* { dg-final { scan-tree-dump-not "cabs" "forwprop1" } } */
-/* { dg-final { scan-tree-dump "pow \\\(\[^,\]*, 6" "forwprop1" } } */
-/* { dg-final { cleanup-tree-dump "forwprop2" } } */
+/* { dg-final { scan-tree-dump "gimple_match_and_simplified to \[^\n\r\]*pow
\\(x_\\d\+\\(D\\), 6" "forwprop1" } } */
+
+double test4 (double w)
+{
+ double x = w * w;
+ double y = __builtin_pow (x, -0.5);
+ return y * x;
+}
+
+/* { dg-final { scan-tree-dump "gimple_match_and_simplified to \[^\n\r\]*=
w_\\d\+\\(D\\)" "forwprop1" } } */
+
+/* { dg-final { cleanup-tree-dump "forwprop1" } } */
[patch,avr,committed] Fix build warnings caused by REG_CLASS_CONTENTS
https://gcc.gnu.org/r210418
Applied this patch in order to fixed build warnings like these
gcc/reginfo.c:115:5: warning: narrowing conversion of ‘-1073741824’ from ‘int’
to ‘const unsigned int’ inside { } is ill-formed in C++11 [-Wnarrowing]
gcc/reginfo.c:115:5: warning: narrowing conversion of ‘-268435456’ from ‘int’
to ‘const unsigned int’ inside { } is ill-formed in C++11 [-Wnarrowing]
gcc/reginfo.c:115:5: warning: narrowing conversion of ‘-67108864’ from ‘int’ to
‘const unsigned int’ inside { } is ill-formed in C++11 [-Wnarrowing]
gcc/reginfo.c:115:5: warning: narrowing conversion of ‘-16777216’ from ‘int’ to
‘const unsigned int’ inside { } is ill-formed in C++11 [-Wnarrowing]
gcc/reginfo.c:115:5: warning: narrowing conversion of ‘-65536’ from ‘int’ to
‘const unsigned int’ inside { } is ill-formed in C++11 [-Wnarrowing]
on I32 hosts that are caused by expressions like 3 << 30 in REG_CLASS_CONTENTS
initializer.
Johann
* config/avr/avr.h (REG_CLASS_CONTENTS): Use unsigned suffix for
shifted values to avoid build warning.
Index: config/avr/avr.h
===
--- config/avr/avr.h (revision 210276)
+++ config/avr/avr.h (working copy)
@@ -251,18 +251,18 @@ enum reg_class {
#define REG_CLASS_CONTENTS { \
{0x,0x}, /* NO_REGS */\
{0x0001,0x}, /* R0_REG */\
- {3 << REG_X,0x}, /* POINTER_X_REGS, r26 - r27 */ \
- {3 << REG_Y,0x}, /* POINTER_Y_REGS, r28 - r29 */ \
- {3 << REG_Z,0x}, /* POINTER_Z_REGS, r30 - r31 */ \
+ {3u << REG_X,0x}, /* POINTER_X_REGS, r26 - r27 */ \
+ {3u << REG_Y,0x}, /* POINTER_Y_REGS, r28 - r29 */ \
+ {3u << REG_Z,0x}, /* POINTER_Z_REGS, r30 - r31 */ \
{0x,0x0003}, /* STACK_REG, STACK */ \
- {(3 << REG_Y) | (3 << REG_Z), \
+ {(3u << REG_Y) | (3u << REG_Z), \
0x}, /* BASE_POINTER_REGS, r28 - r31 */ \
- {(3 << REG_X) | (3 << REG_Y) | (3 << REG_Z),\
+ {(3u << REG_X) | (3u << REG_Y) | (3u << REG_Z), \
0x}, /* POINTER_REGS, r26 - r31 */ \
- {(3 << REG_X) | (3 << REG_Y) | (3 << REG_Z) | (3 << REG_W), \
+ {(3u << REG_X) | (3u << REG_Y) | (3u << REG_Z) | (3u << REG_W), \
0x}, /* ADDW_REGS, r24 - r31 */ \
{0x00ff,0x}, /* SIMPLE_LD_REGS r16 - r23 */ \
- {(3 << REG_X)|(3 << REG_Y)|(3 << REG_Z)|(3 << REG_W)|(0xff << 16), \
+ {(3u << REG_X)|(3u << REG_Y)|(3u << REG_Z)|(3u << REG_W)|(0xffu << 16),\
0x}, /* LD_REGS, r16 - r31 */ \
{0x,0x}, /* NO_LD_REGS r0 - r15 */ \
{0x,0x}, /* GENERAL_REGS, r0 - r31 */ \
RE: [Patch: RL78] Add support for 64-bit doubles
Hi DJ,
>> "long double" should always be 64 bits, which means that libgcc must
>> always have DFmode helpers.
Please find below a modified patch which sets the long double to 64 bits.
This will use default settings for DFmode and libgcc long double types.
I have also posted the binutils part of my patch,
https://sourceware.org/ml/binutils/2014-05/msg00117.html
I have also posted the newlib part of thei patch,
https://sourceware.org/ml/newlib/2014/msg00150.html
I have also attached the following patch, to avoid issue with whitespaces being
dropped.
Let me know if the below version is OK to commit.
Thanks,
Kaushik
2014-05-14 Kaushik Phatak
* config/rl78/rl78.h (TARGET_CPU_CPP_BUILTINS): Define
__RL78_64BIT_DOUBLES__ or __RL78_32BIT_DOUBLES__.
(ASM_SPEC): Pass -m64bit-doubles or -m32bit-doubles on
to the assembler.
(DOUBLE_TYPE_SIZE): Use 64 bit if TARGET_64BIT_DOUBLES
is true.
* gcc/config/rl78/rl78.opt (m64bit-doubles): New option.
(m32bit-doubles) Likewise.
* gcc/config/rl78/t-rl78: Add 64-bit-double multilib.
Index: gcc/config/rl78/rl78.h
===
--- gcc/config/rl78/rl78.h (revision 210319)
+++ gcc/config/rl78/rl78.h (working copy)
@@ -23,18 +23,22 @@
#define RL78_MUL_RL78 (rl78_mul_type == MUL_RL78)
#define RL78_MUL_G13 (rl78_mul_type == MUL_G13)
-#define TARGET_CPU_CPP_BUILTINS() \
- do\
-{ \
- builtin_define ("__RL78__"); \
- builtin_assert ("cpu=RL78"); \
- if (RL78_MUL_RL78) \
- builtin_define ("__RL78_MUL_RL78__"); \
- if (RL78_MUL_G13)\
- builtin_define ("__RL78_MUL_G13__");\
- if (TARGET_G10) \
- builtin_define ("__RL78_G10__");\
-} \
+#define TARGET_CPU_CPP_BUILTINS() \
+ do\
+{ \
+ builtin_define ("__RL78__"); \
+ builtin_assert ("cpu=RL78"); \
+ if (RL78_MUL_RL78) \
+ builtin_define ("__RL78_MUL_RL78__"); \
+ if (RL78_MUL_G13)\
+ builtin_define ("__RL78_MUL_G13__");\
+ if (TARGET_G10) \
+ builtin_define ("__RL78_G10__");\
+ if (TARGET_64BIT_DOUBLES)\
+builtin_define ("__RL78_64BIT_DOUBLES__"); \
+ else \
+builtin_define ("__RL78_32BIT_DOUBLES__"); \
+} \
while (0)
#undef STARTFILE_SPEC
@@ -47,6 +51,8 @@
#define ASM_SPEC "\
%{mrelax:-relax} \
%{mg10} \
+%{m64bit-doubles:-m64bit-doubles} \
+%{!m64bit-doubles:-m32bit-doubles} \
"
#undef LINK_SPEC
@@ -95,7 +101,7 @@
#define LONG_LONG_TYPE_SIZE64
#define FLOAT_TYPE_SIZE32
-#define DOUBLE_TYPE_SIZE 32 /*64*/
+#define DOUBLE_TYPE_SIZE (TARGET_64BIT_DOUBLES ? 64 : 32)
#define LONG_DOUBLE_TYPE_SIZE 64 /*DOUBLE_TYPE_SIZE*/
#define LIBGCC2_HAS_DF_MODE1
Index: gcc/config/rl78/rl78.opt
===
--- gcc/config/rl78/rl78.opt(revision 210319)
+++ gcc/config/rl78/rl78.opt(working copy)
@@ -30,6 +30,14 @@
Target RejectNegative Joined Var(rl78_mul_type) Report Tolower
Enum(rl78_mul_types) Init(MUL_NONE)
Select hardware or software multiplication support.
+m64bit-doubles
+Target RejectNegative Mask(64BIT_DOUBLES) Report
+Store doubles in 64 bits.
+
+m32bit-doubles
+Target RejectNegative InverseMask(64BIT_DOUBLES) Report
+Stores doubles in 32 bits. This is the default
+
Enum
Name(rl78_mul_types) Type(enum rl78_mul_types)
Index: gcc/config/rl78/t-rl78
===
--- gcc/config/rl78/t-rl78 (revision 210319)
+++ gcc/config/rl78/t-rl78 (working copy)
@@ -23,5 +23,5 @@
# Enable multilibs:
-MULTILIB_OPTIONS= mg10
-MULTILIB_DIRNAMES = g10
+MULTILIB_OPTIONS= mg10 m64bit-doubles
+MULTILIB_DIRNAMES = g10 64-bit-double
rl78_64bit .diff
Description: rl78_64bit .diff
Re: [PATCH] Implement -fsanitize=float-cast-overflow
On Tue, May 13, 2014 at 06:11:15PM +, Joseph S. Myers wrote: > > + tree min = TYPE_MIN_VALUE (type); > > + tree max = TYPE_MAX_VALUE (type); > > + /* Add/subtract 1.0 so we can avoid truncating the value of EXPR. */ > > + min = fold_build2 (MINUS_EXPR, expr_type, > > +build_real_from_int_cst (expr_type, min), > > +build_one_cst (expr_type)); > > + max = fold_build2 (PLUS_EXPR, expr_type, > > +build_real_from_int_cst (expr_type, max), > > +build_one_cst (expr_type)); > > It looks to me like this will first round the max value to the > floating-point type, then add 1 to the rounded value and round again. > Which I think is in fact safe at least for IEEE binary floating-point > types, but that isn't immediately obvious. > > Possible issues: > > * Does the folding of the addition occur in all cases for IBM long double? > > * Is this correct for decimal floating point? There, the overflow > condition (value >= max+1) should be using a value of (max+1) rounded > upward rather than to-nearest, if max+1 isn't exactly representable (and > in general it isn't - powers of two 0x1p24 and above aren't representable > in decimal32, 0x1p54 and above in decimal64, 0x1p113 and above in > decimal128, so you just need to find a case where the double-rounding > computation you have produces the wrong value). > > * Likewise, (value <= min-1) for both binary and decimal floating point - > you need to round once, away from 0. For float converted to signed int, > the relevant condition is values < -0x1p31 - 1, i.e. <= 0x1.02p31f > once you allow for which values are representable as float, which is not > min-1 (min-1 rounds to -0x1p31, but a conversion of that to signed int is > fully defined with no exceptions). So what do you see as the way to handle this properly? I mean, for REAL_MODE_FORMAT (TYPE_MODE (expr_type))->b == 2 supposedly to avoid issues with rounding of the max we could just REAL_VALUE_TYPE maxval = dconst1; SET_REAL_EXP (&maxval, REAL_EXP (&maxval) + TYPE_PRECISION (type) - !TYPE_UNSIGNED (type)); real_convert (&maxval, TYPE_MODE (expr_type), &maxval); max = build_real (expr_type, maxval); or so, then supposedly max is always the smallest representable binary floating point value above or equal to TYPE_MAX_VALUE + 1.0. For the min value, if it is unsigned, then -1.0 is ok for all binary or decimal floats, if it is signed, then supposedly we could do the above with s/max/min/;s/dconst1/dconstm1/; and, after the real_convert do inexact = real_arithmetic (&newminval, MINUS_EXPR, &minval, &dconst1); if !inexact just min = build_real (expr_type, newminval); and be done with it (the question is if for IBM double double this will DTRT for LONG_LONG_MIN, which I think should be that the high double will contain (double) LONG_LONG_MIN and the low double -1.0). For inexact (which should be the same thing as if result of real_arithmetic + real_convert is the same as original minval) we need to subtract more than one, dunno if we should just compute it from the REAL_EXP and precision, or just keep subtracing powers of two until after real_convert it is no longer bitwise identical to original minval. We don't have anything close to real_nextafter nor real_convert variant that can round for arbitrary rounding modes. Any preferences how to implement this? For _Decimal*, no idea unfortunately, perhaps for the first iteration ubsan should ignore decimal to int conversions. Jakub
Re: [PATCH] Provide inlining context in strict-overflow warnings
On 05/14/2014 11:56 AM, Jakub Jelinek wrote:
On Tue, May 13, 2014 at 09:27:08PM +0200, Florian Weimer wrote:
Patterns that trigger the optimization and warning can form after
inlining, and it can be rather difficult to figure out what exactly
is causing the warning. The inlining context at least provides
additional hints, enabling developers to substitute the arguments
and discover what, precisely, is happening.
More context is provided with -g than without, but I think this is
acceptable.
I bootstrapped and tested the attached patch on
x86_64-redhat-linux-gnu, with no new regressions.
This looks wrong. If you want to print inline context, you just should
use %K%s and pass a tree with the right EXPR_LOCATION and TREE_BLOCK.
Oh, I didn't realize that %K prints the context recursively. Nice.
So perhaps:
if (stmt == NULL)
warning_at (input_location, OPT_Wstrict_overflow, "%s", warnmsg);
else
warning_at (gimple_location (stmt), OPT_Wstrict_overflow, "%K%s",
build_empty_stmt (gimple_location (stmt)), warnmsg);
(or add something similar to %K that will take location_t or change
%K to take location_t instead of tree now that we have both a block and
locus in location_t.
I looked at the existing %K users and all but one use expressions, so
the build_empty_stmt route seems to be most reasonable approach. Thanks
for the suggestion, new patch attached.
--
Florian Weimer / Red Hat Product Security Team
gcc/
2014-05-13 Florian Weimer
* fold-const.c (fold_undefer_overflow_warnings): Print inlining
information.
gcc/testsuite/
2014-05-13 Florian Weimer
* c-c++-common/Wstrict-overflow-1.c: New test.
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 0fcb87f..33fb629 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -233,7 +233,6 @@ void
fold_undefer_overflow_warnings (bool issue, const_gimple stmt, int code)
{
const char *warnmsg;
- location_t locus;
gcc_assert (fold_deferring_overflow_warnings > 0);
--fold_deferring_overflow_warnings;
@@ -264,10 +263,10 @@ fold_undefer_overflow_warnings (bool issue, const_gimple stmt, int code)
return;
if (stmt == NULL)
-locus = input_location;
+warning_at (input_location, OPT_Wstrict_overflow, "%s", warnmsg);
else
-locus = gimple_location (stmt);
- warning_at (locus, OPT_Wstrict_overflow, "%s", warnmsg);
+warning_at (gimple_location (stmt), OPT_Wstrict_overflow, "%K%s",
+ build_empty_stmt (gimple_location (stmt)), warnmsg);
}
/* Stop deferring overflow warnings, ignoring any deferred
diff --git a/gcc/testsuite/c-c++-common/Wstrict-overflow-1.c b/gcc/testsuite/c-c++-common/Wstrict-overflow-1.c
new file mode 100644
index 000..1624a33
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Wstrict-overflow-1.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -g -Wstrict-overflow" } */
+
+int f (void);
+
+static int g (int a, int b, int c)
+{
+ if (a + b < c) /* { dg-warning "assuming signed overflow" } */
+return -1;
+ return f ();
+}
+
+static int h (int a, int b)
+{
+ return g(a, 1, b);
+}
+
+int k (int a)
+{
+ return h(a, a);
+}
+
+/* { dg-message "inlined from.*:15:" "inlined 15" { target *-*-* } 0 } */
+/* { dg-message "inlined from.*:20:" "inlined 20" { target *-*-* } 0 } */
Re: [PATCH, PR52252] Vectorization for load/store groups of size 3.
It seems like "shuffle of 3 loads is not supported by target" is the root cause. The permutation like 0, 3, 6, 9, c, is not supported by the target.
RE: [RFC][PATCH][MIPS] Patch to enable LRA for MIPS backend
Hi Richard,
Are you working on the solution to fix the breakage? I'm about
to look into this and wanted to find out how far we got with this.
Regards,
Robert
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: 10 May 2014 19:44
> To: Matthew Fortune
> Cc: Vladimir Makarov; Robert Suchanek; gcc-patches@gcc.gnu.org; Kyrill
> Tkachov
> Subject: Re: [RFC][PATCH][MIPS] Patch to enable LRA for MIPS backend
>
> Thanks for looking at this.
>
> Matthew Fortune writes:
> >> > Hi all,
> >> > This caused some testsuite failures on arm:
> >> > FAIL: gcc.target/arm/vfp-ldmdbd.c scan-assembler fldmdbd
> >> > FAIL: gcc.target/arm/vfp-ldmdbs.c scan-assembler fldmdbs
> >> > FAIL: gcc.target/arm/vfp-ldmiad.c scan-assembler fldmiad
> >> > FAIL: gcc.target/arm/vfp-ldmias.c scan-assembler fldmias
> >> >
> >> > From the vfp-ldmdbd.c test this patch changed the codegen from:
> >> > fldmdbdr5!, {d7}
> >> >
> >> > into
> >> > subr5, r5, #8
> >> > flddd7, [r5]
> >> >
> >> > Which broke the test.
> >>
> >> Sorry for the breakage. I've reverted the patch for now and will send a
> >> fixed version when I have time.
> >
> > The problem appears to lie with the new satisfies_memory_constraint_p
> > which is passing just the address to valid_address_p but the constraint
> > is a memory constraint (which wants the mem to be retained).
>
> Yeah.
>
> > One option is to re-construct the MEM using the address_info provided
> > to valid_address_p. This has mode, address space and whether it was
> > actually a MEM to start with so there is enough information.
>
> We don't want to create garbage rtl though. The substitution happens
> in-place, so the routine does temporarily turn the original MEM into the
> eliminated form.
>
> My first reaction after seeing the bug was to pass the operand in as
> another parameter to valid_address_p. That made the interface a bit
> ridiculous though, so I didn't post it and reverted the original patch
> instead.
>
> I think a cleaner way of doing it would be to have helper functions
> that switch in and out of the eliminated form, storing the old form
> in fields of a new structure (either separate from address_info,
> or a local inheritance of it). We probably also want to have arrays
> of address_infos, one for each operand, so that we don't analyse the
> same address too many times during the same insn.
>
> > Another issue noticed while looking at this:
> > process_address does not seem to make an attempt to check for
> > EXTRA_MEMORY_CONSTRAINT even though it does decompose memory addresses.
> > For the lea address case then the address is checked with valid_address_p.
> > This seems inconsistent, is it intentional?
>
> Yeah, I think so. Memory constraints are different in two main ways:
>
> (a) it's obvious from the MEM what the mode and address space of the
> access actually are. legitimate_address_p is all about the most
> general address, so in practice no memory constraint should rely
> on accepting more than legitimate_address_p does.
>
> (b) it's useful for one pattern to have several alternatives with
> different memory constraints (e.g. "ZS", "ZT" and "m" in the 32-bit
> MIPS move patterns). There isn't really anything special about the
> first alternative.
>
> IMO it'd be good to get rid of this special handling for extra address
> constraints, but I've no idea how easy that would be.
>
> Thanks,
> Richard
Re: RFA: Fix calculation of size of builtin setjmp buffer
Hi Eric, 2014-05-06 Nick Clifton * except.c (init_eh): Fix computation of builtin setjmp buffer size. That's the same patch as https://gcc.gnu.org/ml/gcc-patches/2011-11/msg00272.html and is still incorrect. Ah - you are worried about the case where STACK_SAVEAREA_MODE() is smaller than Pmode, yes ? OK then, how about this revised version of the patch where the size computation is now: tmp = size_int (MAX (GET_MODE_SIZE (STACK_SAVEAREA_MODE (SAVE_NONLOCAL)) / GET_MODE_SIZE (Pmode), 1) + 2 /* Stack pointer and frame pointer. */ + 1 /* Slop for mips. */ - 1); OK to apply ? Cheers Nick except.c.patch.4 Description: Unix manual page
Pushed with obvious fix: Re: [AArch64/ARM 3/3] Add execution tests of ARM TRN Intrinsics
In final testing I noticed that vtrnf32_1.c, vtrns32_1.c and vtrnu32_1.c were
failing the scan-assembler-times test: in such two-element cases, TRN, UZP and
ZIP are all equivalent and equally valid, and the ARM backend
(arm_expand_vec_perm_const_1) outputs UZP. Hence, I've pushed the attached
patch, which differs from the original (only) in that I've changed
"scan-assembler-timestrn" to "scan-assembler-timesuzp..." in those
three cases, as revision 210422.
I had not previously been testing bigendian, but as for ZIP and UZP, the
execution tests here fail on such (armeb) targets. As for UZP and ZIP, this is a
case of correct tests exposing a previously-undetected bug in the implementation
(the shuffle masks in arm_neon.h are correct only for little-endian, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61062). I have a fix for this and
shall post shortly.
Cheers, Alan
Ramana Radhakrishnan wrote:
On Fri, Mar 28, 2014 at 3:50 PM, Alan Lawrence wrote:
Final patch in series, adds new tests of the ARM TRN Intrinsics, that also
check
the execution results, reusing the test bodies introduced into AArch64 in
the
first patch. (These tests subsume the autogenerated ones in
testsuite/gcc.target/arm/neon/ that only check assembler output.)
Tests use gcc.target/arm/simd/simd.exp from corresponding patch for ZIP
Intrinsics, will commit that first.
All tests passing on arm-none-eabi.
The ARM bits are ok.
testsuite/ChangeLog:
2012-03-28 Alan Lawrence
* gcc.target/arm/simd/vtrnqf32_1.c: New file.
* gcc.target/arm/simd/vtrnqp16_1.c: New file.
* gcc.target/arm/simd/vtrnqp8_1.c: New file.
* gcc.target/arm/simd/vtrnqs16_1.c: New file.
* gcc.target/arm/simd/vtrnqs32_1.c: New file.
* gcc.target/arm/simd/vtrnqs8_1.c: New file.
* gcc.target/arm/simd/vtrnqu16_1.c: New file.
* gcc.target/arm/simd/vtrnqu32_1.c: New file.
* gcc.target/arm/simd/vtrnqu8_1.c: New file.
* gcc.target/arm/simd/vtrnf32_1.c: New file.
* gcc.target/arm/simd/vtrnp16_1.c: New file.
* gcc.target/arm/simd/vtrnp8_1.c: New file.
* gcc.target/arm/simd/vtrns16_1.c: New file.
* gcc.target/arm/simd/vtrns32_1.c: New file.
* gcc.target/arm/simd/vtrns8_1.c: New file.
* gcc.target/arm/simd/vtrnu16_1.c: New file.
* gcc.target/arm/simd/vtrnu32_1.c: New file.
* gcc.target/arm/simd/vtrnu8_1.c: New file.
diff --git a/gcc/testsuite/gcc.target/arm/simd/vtrnf32_1.c
b/gcc/testsuite/gcc.target/arm/simd/vtrnf32_1.c
new file mode 100644
index 000..c9620fb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/vtrnf32_1.c
@@ -0,0 +1,12 @@
+/* Test the `vtrnf32' ARM Neon intrinsic. */
+
+/* { dg-do run } */
+/* { dg-require-effective-target arm_neon_ok } */
+/* { dg-options "-save-temps -O1 -fno-inline" } */
+/* { dg-add-options arm_neon } */
+
+#include "arm_neon.h"
+#include "../../aarch64/simd/vtrnf32.x"
+
+/* { dg-final { scan-assembler-times "vtrn\.32\[ \t\]+\[dD\]\[0-9\]+,
?\[dD\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n" 1 } } */
+/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/arm/simd/vtrnp16_1.c
b/gcc/testsuite/gcc.target/arm/simd/vtrnp16_1.c
new file mode 100644
index 000..0ff4319
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/vtrnp16_1.c
@@ -0,0 +1,12 @@
+/* Test the `vtrnp16' ARM Neon intrinsic. */
+
+/* { dg-do run } */
+/* { dg-require-effective-target arm_neon_ok } */
+/* { dg-options "-save-temps -O1 -fno-inline" } */
+/* { dg-add-options arm_neon } */
+
+#include "arm_neon.h"
+#include "../../aarch64/simd/vtrnp16.x"
+
+/* { dg-final { scan-assembler-times "vtrn\.16\[ \t\]+\[dD\]\[0-9\]+,
?\[dD\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n" 1 } } */
+/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/arm/simd/vtrnp8_1.c
b/gcc/testsuite/gcc.target/arm/simd/vtrnp8_1.c
new file mode 100644
index 000..2b047e4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/vtrnp8_1.c
@@ -0,0 +1,12 @@
+/* Test the `vtrnp8' ARM Neon intrinsic. */
+
+/* { dg-do run } */
+/* { dg-require-effective-target arm_neon_ok } */
+/* { dg-options "-save-temps -O1 -fno-inline" } */
+/* { dg-add-options arm_neon } */
+
+#include "arm_neon.h"
+#include "../../aarch64/simd/vtrnp8.x"
+
+/* { dg-final { scan-assembler-times "vtrn\.8\[ \t\]+\[dD\]\[0-9\]+,
?\[dD\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n" 1 } } */
+/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/arm/simd/vtrnqf32_1.c
b/gcc/testsuite/gcc.target/arm/simd/vtrnqf32_1.c
new file mode 100644
index 000..dd4e883
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/vtrnqf32_1.c
@@ -0,0 +1,12 @@
+/* Test the `vtrnQf32' ARM Neon intrinsic. */
+
+/* { dg-do run } */
+/* { dg-require-effective-target arm_neon_ok } */
+/* { dg-options "-save-temps -O1 -fno-inline" } */
+/* { dg-add-options arm_neon } */
+
+#include "arm_neon.h"
+#include "../../aa
[PATCH, libstdc++/61166] overflow when parse number in std::duration operator""
Make the machinery in bits/parse_number.h unsigned long long.
I had actually noticed this a while back but we were in stage 4. Then I
forgot.. :-/
Built and tested on x84_64-linux.
OK?
2014-05-14 Ed Smith-Rowland <3dw...@verizon.net>
libstdc++/61166 overflow when parse number in std::duration operator""
* include/bits/parse_numbers.h: Make the machinery unsigned long long.
* testsuite/20_util/duration/literals/pr61166.cc: New.
Index: include/bits/parse_numbers.h
===
--- include/bits/parse_numbers.h(revision 210315)
+++ include/bits/parse_numbers.h(working copy)
@@ -27,8 +27,8 @@
* Do not attempt to use it directly. @headername{chrono}
*/
-#ifndef _PARSE_NUMBERS_H
-#define _PARSE_NUMBERS_H 1
+#ifndef _GLIBCXX_PARSE_NUMBERS_H
+#define _GLIBCXX_PARSE_NUMBERS_H 1
#pragma GCC system_header
@@ -36,262 +36,278 @@
#if __cplusplus > 201103L
+#include
+
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
-namespace __parse_int {
+namespace __parse_int
+{
- template
+ template
struct _Digit;
- template
+ template
struct _Digit<_Base, '0'>
{
static constexpr bool valid{true};
- static constexpr unsigned value{0};
+ static constexpr unsigned long long value{0};
};
- template
+ template
struct _Digit<_Base, '1'>
{
static constexpr bool valid{true};
- static constexpr unsigned value{1};
+ static constexpr unsigned long long value{1};
};
- template
+ template
struct _Digit<_Base, '2'>
{
static_assert(_Base > 2, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{2};
+ static constexpr unsigned long long value{2};
};
- template
+ template
struct _Digit<_Base, '3'>
{
static_assert(_Base > 3, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{3};
+ static constexpr unsigned long long value{3};
};
- template
+ template
struct _Digit<_Base, '4'>
{
static_assert(_Base > 4, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{4};
+ static constexpr unsigned long long value{4};
};
- template
+ template
struct _Digit<_Base, '5'>
{
static_assert(_Base > 5, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{5};
+ static constexpr unsigned long long value{5};
};
- template
+ template
struct _Digit<_Base, '6'>
{
static_assert(_Base > 6, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{6};
+ static constexpr unsigned long long value{6};
};
- template
+ template
struct _Digit<_Base, '7'>
{
static_assert(_Base > 7, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{7};
+ static constexpr unsigned long long value{7};
};
- template
+ template
struct _Digit<_Base, '8'>
{
static_assert(_Base > 8, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{8};
+ static constexpr unsigned long long value{8};
};
- template
+ template
struct _Digit<_Base, '9'>
{
static_assert(_Base > 9, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{9};
+ static constexpr unsigned long long value{9};
};
- template
+ template
struct _Digit<_Base, 'a'>
{
static_assert(_Base > 0xa, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{0xa};
+ static constexpr unsigned long long value{0xa};
};
- template
+ template
struct _Digit<_Base, 'A'>
{
static_assert(_Base > 0xa, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{0xa};
+ static constexpr unsigned long long value{0xa};
};
- template
+ template
struct _Digit<_Base, 'b'>
{
static_assert(_Base > 0xb, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{0xb};
+ static constexpr unsigned long long value{0xb};
};
- template
+ template
struct _Digit<_Base, 'B'>
{
static_assert(_Base > 0xb, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{0xb};
+ static constexpr unsigned long long value{0xb};
};
- template
+ template
struct _Digit<_Base, 'c'>
{
static_assert(_Base > 0xc, "invalid digit");
static constexpr bool valid{true};
- static constexpr unsigned value{0xc};
+ static constexpr unsigned long long value{0xc};
};
[PATCH ARM] PR/61062 Fix arm_neon.h ZIP/UZP/TRN for bigendian
Hi,
Due to differences in how the ARM C Language Extensions and gcc's vector
extensions deal with indices within vectors, the __builtin_shuffle masks used to
implement the ZIP, UZP and TRN Neon Intrinsics in arm_neon.h are correct only
for little-endian. (The problem on bigendian has recently been revealed by new
tests in gcc.target/arm/simd/.)
This patch corrects the indices using "#ifdef __ARM_BIG_ENDIAN" through
arm_neon.h. I've tested all the arm-specific tests (arm.exp acle.exp aapcs.exp
simd.exp neon.exp) on both arm-none-eabi and armeb-none-eabi and there are no
regressions, and on armeb-none-eabi this patch fixes FAIL -> PASS for
simd/v{uzp,zip,trn}*_1.c.
Note the patch also modifies gcc.target/arm/pr48252.c. A bit of diving into the
history of this test reveals
*the test was first written in the days when the arm_neon.h implementation
used builtins such as __builtin_neon_vzipv8qi (which were thus correct for
bigendian).
*In SVN rev 189294, ZIP intrinsics were rewritten to use __builtin_shuffle
(with little-endian masks); this broke pr48252.c on bigendian, but this was not
detected until...
*In SVN rev 191200, in which pr48252.c was modified to expect different
results according to endianness - that is, "fixing" the test to match the broken
implementation. (I have verified that this updated test failed on the original
__builtin_neon_vzipv8qi implementation.)
The fix to pr48252.c here largely reverts to the original form although keeps
the (correct, proper) use of vld1.
gcc/ChangeLog:
* config/arm/arm_neon.h (vtrn_s8, vtrn_s16, vtrn_u8, vtrn_u16, vtrn_p8,
vtrn_p16, vtrn_s32, vtrn_f32, vtrn_u32, vtrnq_s8, vtrnq_s16, vtrnq_s32,
vtrnq_f32, vtrnq_u8, vtrnq_u16, vtrnq_u32, vtrnq_p8, vtrnq_p16, vzip_s8,
vzip_s16, vzip_u8, vzip_u16, vzip_p8, vzip_p16, vzip_s32, vzip_f32,
vzip_u32, vzipq_s8, vzipq_s16, vzipq_s32, vzipq_f32, vzipq_u8,
vzipq_u16, vzipq_u32, vzipq_p8, vzipq_p16, vuzp_s8, vuzp_s16, vuzp_s32,
vuzp_f32, vuzp_u8, vuzp_u16, vuzp_u32, vuzp_p8, vuzp_p16, vuzpq_s8,
vuzpq_s16, vuzpq_s32, vuzpq_f32, vuzpq_u8, vuzpq_u16, vuzpq_u32,
vuzpq_p8, vuzpq_p16): Correct mask for bigendian.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr48252.c (main): Expect same result as endian-neutral.
Cheers, Alandiff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 37a6e611b48fd42ddd6284a56d28080884a0bcec..f86f0d4ced16894920a57343b1b42c46b2a941c2 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -7707,12 +7707,32 @@ vbslq_p16 (uint16x8_t __a, poly16x8_t __b, poly16x8_t __c)
return (poly16x8_t)__builtin_neon_vbslv8hi ((int16x8_t) __a, (int16x8_t) __b, (int16x8_t) __c);
}
+/* For big-endian, the shuffle masks for ZIP, UZP and TRN must be changed as
+ follows. (nelt = the number of elements within a vector.)
+
+ Firstly, a value of N within a mask, becomes (N ^ (nelt - 1)), as gcc vector
+ extension's indexing scheme is reversed *within each vector* (relative to the
+ neon intrinsics view), but without changing which of the two vectors.
+
+ Secondly, the elements within each mask are reversed, as the mask is itself a
+ vector, and will itself be loaded in reverse order (again, relative to the
+ neon intrinsics view, i.e. that would result from a "vld1" instruction). */
+
__extension__ static __inline int8x8x2_t __attribute__ ((__always_inline__))
vtrn_s8 (int8x8_t __a, int8x8_t __b)
{
int8x8x2_t __rv;
- __rv.val[0] = (int8x8_t) __builtin_shuffle (__a, __b, (uint8x8_t) { 0, 8, 2, 10, 4, 12, 6, 14 });
- __rv.val[1] = (int8x8_t) __builtin_shuffle (__a, __b, (uint8x8_t) { 1, 9, 3, 11, 5, 13, 7, 15 });
+#ifdef __ARM_BIG_ENDIAN
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 9, 1, 11, 3, 13, 5, 15, 7 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 8, 0, 10, 2, 12, 4, 14, 6 });
+#else
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 0, 8, 2, 10, 4, 12, 6, 14 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 1, 9, 3, 11, 5, 13, 7, 15 });
+#endif
return __rv;
}
@@ -7720,8 +7740,13 @@ __extension__ static __inline int16x4x2_t __attribute__ ((__always_inline__))
vtrn_s16 (int16x4_t __a, int16x4_t __b)
{
int16x4x2_t __rv;
- __rv.val[0] = (int16x4_t) __builtin_shuffle (__a, __b, (uint16x4_t) { 0, 4, 2, 6 });
- __rv.val[1] = (int16x4_t) __builtin_shuffle (__a, __b, (uint16x4_t) { 1, 5, 3, 7 });
+#ifdef __ARM_BIG_ENDIAN
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint16x4_t) { 5, 1, 7, 3 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint16x4_t) { 4, 0, 6, 2 });
+#else
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint16x4_t) { 0, 4, 2, 6 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint16x4_t) { 1, 5, 3, 7 });
+#endif
return __rv;
}
@@ -7729,8 +7754,17 @@ __extension__ static __inline uint8x8x2_t __attribute__ ((__always_inline__))
vtrn_u8 (ui
Re: [PATCH, libstdc++/61166] overflow when parse number in std::duration operator""
2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland <3dw...@verizon.net>: > Make the machinery in bits/parse_number.h unsigned long long. > I had actually noticed this a while back but we were in stage 4. Then I > forgot.. :-/ > > Built and tested on x84_64-linux. > > OK? I understand the reason why the corresponding static members value got type unsigned long long, but why did the template parameter _Base also require the same update? Another question: Presumably "value" indded requires no uglification, but what about the member "valid"? I would expect that this is no name reserved by the library. - Daniel -- SavedURI :Show URLShow URLSavedURI : SavedURI :Hide URLHide URLSavedURI : https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154
[PATCH][RFC] Make FRE/PRE apply copy/constant propagation
This makes FRE/PRE substitute values into all uses instead of leaving
copies and initializations from constants in the IL which requires
a copyprop pass to clean up things (which we usually place directly
after FRE/PRE).
This should open the possibility to remove some of the passes,
respectively the two copy-prop passes right after the two FREs
and the copyprop pass we do early in loop opts.
The patch exposes a weakness in invariant motion cost computation
and thus gfortran.dg/vect/fast-math-vect-8.f90 fails for me
on i?86 (but not on x86_64).
I want to revisit some of the ???s and uglinesses in the patch,
but this is a state that passes bootstrap and regtest otherwise
and thus ready.
Any comments?
Thanks,
Richard.
2014-05-14 Richard Biener
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
Rewrite to propagate the VN result into all uses where
possible and to remove stmts becoming dead because of that.
(eliminate): Generalize stmt removal handling, remove in
reverse dominator order to support proper debug stmt
generation. Update stmts before removing stmts.
* tree-ssa-propagate.c (propagate_tree_value): Remove
bogus assert.
* c-c++-common/pr46562-2.c: Adjust.
* gcc.dg/tree-ssa/ssa-fre-24.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-25.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-32.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-16.c: Likewise.
Index: trunk/gcc/tree-ssa-pre.c
===
*** trunk.orig/gcc/tree-ssa-pre.c 2014-05-14 14:06:26.860907895 +0200
--- trunk/gcc/tree-ssa-pre.c2014-05-14 14:20:29.068849910 +0200
*** eliminate_dom_walker::before_dom_childre
*** 4012,4120
for (gsi = gsi_start_phis (b); !gsi_end_p (gsi);)
{
! gimple stmt, phi = gsi_stmt (gsi);
! tree sprime = NULL_TREE, res = PHI_RESULT (phi);
! gimple_stmt_iterator gsi2;
!
! /* We want to perform redundant PHI elimination. Do so by
!replacing the PHI with a single copy if possible.
!Do not touch inserted, single-argument or virtual PHIs. */
! if (gimple_phi_num_args (phi) == 1
! || virtual_operand_p (res))
{
gsi_next (&gsi);
continue;
}
! sprime = eliminate_avail (res);
! if (!sprime
! || sprime == res)
{
! eliminate_push_avail (res);
! gsi_next (&gsi);
continue;
}
! else if (is_gimple_min_invariant (sprime))
{
! if (!useless_type_conversion_p (TREE_TYPE (res),
! TREE_TYPE (sprime)))
! sprime = fold_convert (TREE_TYPE (res), sprime);
}
! if (dump_file && (dump_flags & TDF_DETAILS))
{
! fprintf (dump_file, "Replaced redundant PHI node defining ");
! print_generic_expr (dump_file, res, 0);
! fprintf (dump_file, " with ");
! print_generic_expr (dump_file, sprime, 0);
! fprintf (dump_file, "\n");
}
-
- remove_phi_node (&gsi, false);
-
- if (inserted_exprs
- && !bitmap_bit_p (inserted_exprs, SSA_NAME_VERSION (res))
- && TREE_CODE (sprime) == SSA_NAME)
- gimple_set_plf (SSA_NAME_DEF_STMT (sprime), NECESSARY, true);
-
- if (!useless_type_conversion_p (TREE_TYPE (res), TREE_TYPE (sprime)))
- sprime = fold_convert (TREE_TYPE (res), sprime);
- stmt = gimple_build_assign (res, sprime);
- gimple_set_plf (stmt, NECESSARY, gimple_plf (phi, NECESSARY));
-
- gsi2 = gsi_after_labels (b);
- gsi_insert_before (&gsi2, stmt, GSI_NEW_STMT);
- /* Queue the copy for eventual removal. */
- el_to_remove.safe_push (stmt);
- /* If we inserted this PHI node ourself, it's not an elimination. */
- if (inserted_exprs
- && bitmap_bit_p (inserted_exprs, SSA_NAME_VERSION (res)))
- pre_stats.phis--;
else
! pre_stats.eliminations++;
}
for (gsi = gsi_start_bb (b); !gsi_end_p (gsi); gsi_next (&gsi))
{
! tree lhs = NULL_TREE;
! tree rhs = NULL_TREE;
!
stmt = gsi_stmt (gsi);
!
! if (gimple_has_lhs (stmt))
! lhs = gimple_get_lhs (stmt);
!
! if (gimple_assign_single_p (stmt))
! rhs = gimple_assign_rhs1 (stmt);
!
! /* Lookup the RHS of the expression, see if we have an
!available computation for it. If so, replace the RHS with
!the available computation. */
! if (gimple_has_lhs (stmt)
! && TREE_CODE (lhs) == SSA_NAME
! && !gimple_has_volatile_ops (stmt))
! {
! tree sprime;
! gimple orig_stmt = stmt;
!
! sprime = eliminate_avail (lhs);
! /* If there is no usable leader mark lhs as leader for its value. */
! if (!sprime)
! eliminate_push_avail (lhs);
!
/* See PR43491. Do not
Re: [PATCH, libstdc++/61166] overflow when parse number in std::duration operator""
On 14 May 2014 14:59, Daniel Krügler wrote: > 2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland <3dw...@verizon.net>: >> Make the machinery in bits/parse_number.h unsigned long long. >> I had actually noticed this a while back but we were in stage 4. Then I >> forgot.. :-/ >> >> Built and tested on x84_64-linux. >> >> OK? > > I understand the reason why the corresponding static members value got > type unsigned long long, but why did the template parameter _Base also > require the same update? > > Another question: Presumably "value" indded requires no uglification, > but what about the member "valid"? I would expect that this is no name > reserved by the library. Good point. (It's a member function in at least , but we shouldn't be reserving it elsewhere). Any time I see a static const member of integral type called value I wonder if the type should derive from a specialization of std::integral_constant. You could probably also do: using __valid = true_type;
Re: [patch] fix impliedness of -Wunused-parameter depending on -Wexta option ordering
On 12 May 2014 22:24, Joseph S. Myers wrote:
> On Mon, 12 May 2014, Manuel López-Ibáñez wrote:
>
>> I will be very surprised if the common defaults are overriding a FE
>> default and it is not a bug in the FE.
>
> Well, I think that needs justification, not just "very surprised".
> Identify (presumably in an automated way) all the cases where an option is
> handled by more than one of the handlers and, for each one, describe what
> cases would be affected by a change of order and why the proposed new
> order gives the desired effects.
common_handle_option_auto handles just OPT_Wextra,
OPT_Wuninitialized: and OPT_Wunused.
Fortran is the only one that handles OPT_Wextra in the FE, and the
current order prevents Fortran to override the current default, while
the new order will allow it.
These are the options handled in gcc/opts.c
OPT_auxbase_strip
OPT_aux_info
OPT_d
OPT_fcall_saved_
OPT_fcall_used_
OPT_fdbg_cnt_
OPT_fdbg_cnt_list
OPT_fdebug_prefix_map_
OPT_fdiagnostics_color_
OPT_fdiagnostics_show_caret
OPT_fdiagnostics_show_location_
OPT_fdiagnostics_show_option
OPT_fdump_
OPT_ffast_math
OPT_ffixed_
OPT_finline_limit_
OPT_finstrument_functions_exclude_file_list_
OPT_finstrument_functions_exclude_function_list_
OPT_flto
OPT_fmax_errors_
OPT_fmessage_length_
OPT_fopt_info
OPT_fopt_info_
OPT_fpack_struct_
OPT_fplugin_
OPT_fplugin_arg_
OPT_fprofile_generate
OPT_fprofile_generate_
OPT_fprofile_use
OPT_fprofile_use_
OPT_frandom_seed
OPT_frandom_seed_
OPT_fsanitize_
OPT_fsched_stalled_insns_
OPT_fsched_stalled_insns_dep_
OPT_fsched_verbose_
OPT_fshow_column
OPT_fstack_check_
OPT_fstack_limit
OPT_fstack_limit_register_
OPT_fstack_limit_symbol_
OPT_fstack_usage
OPT_ftrapv
OPT_ftree_vectorize
OPT_funsafe_math_optimizations
OPT_fuse_ld_bfd
OPT_fuse_ld_gold
OPT_fuse_linker_plugin
OPT_fwrapv
OPT_g
OPT_gcoff
OPT_gdwarf
OPT_gdwarf_
OPT_ggdb
OPT_gsplit_dwarf
OPT_gstabs
OPT_gstabs_
OPT_gvms
OPT_gxcoff
OPT_gxcoff_
OPT__help
OPT__help_
OPT_O
OPT_Ofast
OPT_Og
OPT_Os
OPT__param
OPT_pedantic_errors
OPT__target_help
OPT__version
OPT_w
OPT_Werror
OPT_Werror_
OPT_Wfatal_errors
OPT_Wframe_larger_than_
OPT_Wlarger_than_
OPT_Wstack_usage_
OPT_Wstrict_aliasing
OPT_Wstrict_overflow
OPT_Wsystem_headers
I found the ones handled in the FEs by using:
$ for o in $(grep 'case OPT_' gcc/opts.c | sed 's/^\s\+case \+//g' |
sort -u); do grep $o gcc/ada/gcc-interface/misc.c
gcc/fortran/options.c gcc/fortran/cpp.c gcc/java/lang.c
gcc/lto/lto-lang.c gcc/c-family/c-opts.c; done
gcc/fortran/options.c:case OPT_d:
gcc/fortran/options.c:case OPT_d:
gcc/fortran/cpp.c:case OPT_d:
gcc/c-family/c-opts.c:case OPT_d:
gcc/java/lang.c:case OPT_fdump_:
Of these, OPT_fdump_ is deferred in gcc/opts.c, so the order does not matter.
For OPT_d, the common handler does:
case 'D': /* These are handled by the preprocessor. */
case 'I':
case 'M':
case 'N':
case 'U':
break;
While Fortran does:
case OPT_d:
for ( ; *arg; ++arg)
switch (*arg)
{
case 'D':
case 'M':
case 'N':
case 'U':
gfc_cpp_option.dump_macros = *arg;
break;
case 'I':
gfc_cpp_option.dump_includes = 1;
break;
}
break;
and C/C++ does:
while ((c = *arg++) != '\0')
switch (c)
{
case 'M': /* Dump macros only. */
case 'N': /* Dump names. */
case 'D': /* Dump definitions. */
case 'U': /* Dump used macros. */
flag_dump_macros = c;
break;
case 'I':
flag_dump_includes = 1;
break;
}
Am I missing something?
Cheers,
Manuel.
Re: [PATCH, testsuite] Fix rs6000 test case pack03.c to use new dg-require-effective-target dfp_hw
Hi Peter, > I'll note that the patch includes documentation for the new keyword > along with a few others I noticed that were missing, which I've > included below for posterity. fine, thanks for doing this. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] cplus-demangler, free resource after a failed call to gnu_special.
Andrew Burgess wrote:
> On 14/05/2014 10:01 AM, Gary Benson wrote:
> > Ian Lance Taylor wrote:
> > > Andrew Burgess wrote:
> > > > On 09/05/2014 9:53 PM, Ian Lance Taylor wrote:
> > > > > Andrew Burgess wrote:
> > > > > >if ((AUTO_DEMANGLING || GNU_DEMANGLING))
> > > > > > {
> > > > > > success = gnu_special (work, &mangled, &decl);
> > > > > > + if (!success)
> > > > > > +{
> > > > > > + delete_work_stuff (work);
> > > > > > + string_delete (&decl);
> > > > > > +}
> > > > >
> > >
> > > This patch is OK.
> >
> > Andrew, would you like me to commit this?
>
> Yes please.
Done:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=210425
Thanks,
Gary
--
http://gbenson.net/
Re: [PATCH, libstdc++/61166] overflow when parse number in std::duration operator""
On 05/14/2014 09:59 AM, Daniel Krügler wrote: 2014-05-14 15:38 GMT+02:00 Ed Smith-Rowland <3dw...@verizon.net>: Make the machinery in bits/parse_number.h unsigned long long. I had actually noticed this a while back but we were in stage 4. Then I forgot.. :-/ Built and tested on x84_64-linux. OK? I understand the reason why the corresponding static members value got type unsigned long long, but why did the template parameter _Base also require the same update? Another question: Presumably "value" indded requires no uglification, but what about the member "valid"? I would expect that this is no name reserved by the library. - Daniel You're right, _Base doesn't need that - only 2, 8, 10, 16 allowed (could do base64 someday, but still). Change all got me. I should uglify the valid members. But in keeping with, say, our extension type traits and such maybe i should uglify value as well.
[PATCH] libcpp: Replace some macro usage with C++ constructs
libcpp makes extensive use of the C preprocessor. Whilst this has a
pleasingly self-referential quality, I find the code hard-to-read;
implementing source location support in my JIT branch was much harder than
I hoped it would be.
In an attempt at making the code easier to follow, the following patch
converts some of these macros to C++ equivalents: using "const" for
compile-time constants, and inline functions where macros aren't used as
lvalues.
This effectively documents the expected types of the params, and makes
them available from the debugger e.g.:
(gdb) p LINEMAP_FILE ($3)
$4 = 0x13b8b37 ""
Successfully bootstrapped®rtested on x86_64-unknown-linux-gnu
(Fedora 20).
Caveats:
* I didn't mark the inline functions as "static"; should they be?
* I didn't run performance testing on the parser; is there
a recommended way to do this for this kind of change?
OK for trunk?
libcpp/
* include/line-map.h (MAX_SOURCE_LOCATION): Convert from a macro
to a const source_location.
(RESERVED_LOCATION_COUNT): Convert from a macro to a const int.
(LINEMAPS_MAP_INFO): Convert from a macro to a pair of inline
functions, for const/non-const arguments.
(linemap_check_ordinary): Likewise.
(IS_ADHOC_LOC): Convert from a macro to an inline function.
(COMBINE_LOCATION_DATA): Likewise.
(SOURCE_LINE): Likewise.
(SOURCE_COLUMN): Likewise.
(LAST_SOURCE_LINE_LOCATION): Likewise.
(LAST_SOURCE_LINE): Likewise.
(LAST_SOURCE_COLUMN): Likewise.
(INCLUDED_FROM): Likewise.
(MAIN_FILE_P): Likewise.
(source_location): Likewise.
(LINEMAP_FILE): Likewise.
(LINEMAP_LINE): Likewise.
(LINEMAP_SYSP): Likewise.
(linemap_location_before_p): Likewise.
* line-map.c (linemap_check_files_exited): Make local "map" const.
---
libcpp/include/line-map.h | 177 ++
libcpp/line-map.c | 2 +-
2 files changed, 118 insertions(+), 61 deletions(-)
diff --git a/libcpp/include/line-map.h b/libcpp/include/line-map.h
index 9886314..4dfb0ae 100644
--- a/libcpp/include/line-map.h
+++ b/libcpp/include/line-map.h
@@ -88,7 +88,7 @@ struct GTY(()) line_map_ordinary {
/* This is the highest possible source location encoded within an
ordinary or macro map. */
-#define MAX_SOURCE_LOCATION 0x7FFF
+const source_location MAX_SOURCE_LOCATION = 0x7FFF;
struct cpp_hashnode;
@@ -320,10 +320,21 @@ struct GTY(()) line_maps {
/* Returns the pointer to the memory region where information about
maps are stored in the line table SET. MACRO_MAP_P is a flag
telling if we want macro or ordinary maps. */
-#define LINEMAPS_MAP_INFO(SET, MACRO_MAP_P)\
- ((MACRO_MAP_P) \
- ? &((SET)->info_macro) \
- : &((SET)->info_ordinary))
+inline struct maps_info *
+LINEMAPS_MAP_INFO (line_maps *set, bool macro_map_p)
+{
+ return (macro_map_p
+ ? &(set->info_macro)
+ : &(set->info_ordinary));
+}
+
+inline const struct maps_info *
+LINEMAPS_MAP_INFO (const line_maps *set, bool macro_map_p)
+{
+ return (macro_map_p
+ ? &(set->info_macro)
+ : &(set->info_ordinary));
+}
/* Returns the pointer to the memory region where maps are stored in
the line table SET. MAP_KIND shall be TRUE if we are interested in
@@ -441,9 +452,18 @@ extern void *get_data_from_adhoc_loc (struct line_maps *,
source_location);
extern source_location get_location_from_adhoc_loc (struct line_maps *,
source_location);
-#define IS_ADHOC_LOC(LOC) (((LOC) & MAX_SOURCE_LOCATION) != (LOC))
-#define COMBINE_LOCATION_DATA(SET, LOC, BLOCK) \
- get_combined_adhoc_loc ((SET), (LOC), (BLOCK))
+inline bool IS_ADHOC_LOC (source_location loc)
+{
+ return (loc & MAX_SOURCE_LOCATION) != loc;
+}
+
+inline source_location
+COMBINE_LOCATION_DATA (struct line_maps *set,
+ source_location loc,
+ void *block)
+{
+ return get_combined_adhoc_loc (set, loc, block);
+}
extern void rebuild_location_adhoc_htab (struct line_maps *);
@@ -521,66 +541,93 @@ bool linemap_location_from_macro_expansion_p (struct
line_maps *,
/* source_location values from 0 to RESERVED_LOCATION_COUNT-1 will
be reserved for libcpp user as special values, no token from libcpp
will contain any of those locations. */
-#define RESERVED_LOCATION_COUNT2
+const int RESERVED_LOCATION_COUNT = 2;
+
+#if defined ENABLE_CHECKING && (GCC_VERSION >= 2007)
+
+/* Assertion macro to be used in line-map code. */
+#define linemap_assert(EXPR) \
+ do { \
+if (! (EXPR)) \
+ abort ();\
+ } while (0)
+#else
+#define li
Re: [PATCH, libstdc++/61166] overflow when parse number in std::duration operator""
On 14 May 2014 15:25, Ed Smith-Rowland wrote: > But in keeping with, say, our extension type traits and such maybe i should > uglify value as well. No, just derive from std::integral_constant and you get value "for free". You already use integral_constant in that file, so the name "value" is already used.
Re: [PATCH, libstdc++/61166] overflow when parse number in std::duration operator""
On 14 May 2014 15:36, Jonathan Wakely wrote: > On 14 May 2014 15:25, Ed Smith-Rowland wrote: >> But in keeping with, say, our extension type traits and such maybe i should >> uglify value as well. > > No, just derive from std::integral_constant and you get value "for free". > > You already use integral_constant in that file, so the name "value" is > already used. That also has the advantage that _Digit and _Digit share the same base class, so you don't end up with two different static members with the same value (and if you make __valid a typedef as I suggested you don't have any static members for that either). Do we really need _Digit::value to be unsigned long long, or is it only the results in _Power_help and _Number_help that need to be 64-bit?
Ping x 5: [PATCH] [libgomp] make it possible to use OMP on both sides of a fork
Hi all,
Pinging again about the patch below. The lack of this patch is
essentially a blocker to using gcc+python+openmp together, which is a
shame, since python is increasingly important in numerical computing,
openmp is pretty useful, and gcc is the only openmp implementation
that does not support this functionality.
-n
On Tue, Apr 15, 2014 at 1:19 PM, Nathaniel Smith wrote:
> On Tue, Mar 4, 2014 at 11:37 PM, Nathaniel Smith wrote:
>> On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson wrote:
>>> On 02/16/2014 03:59 PM, Nathaniel Smith wrote:
Yes, but the problem is that depending on what the user intends to do
after forking, our pthread_atfork handler might help or it might hurt,
and we don't know which. Consider these two cases:
- fork+exec
- fork+continue to use OMP in child
The former case is totally POSIX-legal, even when performed at
arbitrary places, even when another thread is, say, in the middle of
calling malloc().
>>>
>>> Point well taken.
>>
>> Hi all,
>>
>> I guess this patch has gotten all the feedback that it's getting. Any
>> interest in committing it? :-) I don't have commit access.
>>
>> 2014-02-12 Nathaniel J. Smith
>>
>> * team.c (gomp_free_pool_helper): Move per-thread cleanup to main
>> thread.
>> (gomp_free_thread): Delegate implementation to...
>> (gomp_free_thread_pool): ...this new function. Like old
>> gomp_free_thread, but does per-thread cleanup, and has option to
>> skip everything that involves interacting with actual threads,
>> which is useful when called after fork.
>> (gomp_after_fork_callback): New function.
>> (gomp_team_start): Register atfork handler, and check for fork on
>> entry.
>
> Pinging this again now that trunk has re-opened. For compliant code
> this patch has essentially no impact (OMP-using code acquires a
> single-line post-fork callback which sets a flag; everything else
> works the same as now). For technically non-compliant "mostly serial"
> code that uses OMP in some places, and forks children in other places,
> it makes a best effort attempt to clean up the thread pool detritus
> left by a fork, instead of simply deadlocking as currently, so as to
> allow children to use OMP as well. This makes GOMP match the behaviour
> of all other OMP implementations I'm aware of.
>
> Previous discussion:
> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00813.html
> Bug:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035
>
> I don't have a commit bit -- please commit if acceptable.
>
> Cheers,
> -n
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
Index: team.c
===
--- team.c (revision 207398)
+++ team.c (working copy)
@@ -28,6 +28,7 @@
#include "libgomp.h"
#include
#include
+#include
/* This attribute contains PTHREAD_CREATE_DETACHED. */
pthread_attr_t gomp_thread_attr;
@@ -43,6 +44,8 @@ __thread struct gomp_thread gomp_tls_data;
pthread_key_t gomp_tls_key;
#endif
+/* This is to enable best-effort cleanup after fork. */
+static bool gomp_we_are_forked;
/* This structure is used to communicate across pthread_create. */
@@ -204,42 +207,41 @@ static struct gomp_thread_pool *gomp_new_thread_po
return pool;
}
+/* Free a thread pool and release its threads. */
+
static void
gomp_free_pool_helper (void *thread_pool)
{
- struct gomp_thread *thr = gomp_thread ();
struct gomp_thread_pool *pool
= (struct gomp_thread_pool *) thread_pool;
gomp_barrier_wait_last (&pool->threads_dock);
- gomp_sem_destroy (&thr->release);
- thr->thread_pool = NULL;
- thr->task = NULL;
pthread_exit (NULL);
}
-/* Free a thread pool and release its threads. */
-
-void
-gomp_free_thread (void *arg __attribute__((unused)))
+static void
+gomp_free_thread_pool (bool threads_are_running)
{
struct gomp_thread *thr = gomp_thread ();
struct gomp_thread_pool *pool = thr->thread_pool;
if (pool)
{
+ int i;
if (pool->threads_used > 0)
{
- int i;
- for (i = 1; i < pool->threads_used; i++)
+ if (threads_are_running)
{
- struct gomp_thread *nthr = pool->threads[i];
- nthr->fn = gomp_free_pool_helper;
- nthr->data = pool;
+ for (i = 1; i < pool->threads_used; i++)
+ {
+ struct gomp_thread *nthr = pool->threads[i];
+ nthr->fn = gomp_free_pool_helper;
+ nthr->data = pool;
+ }
+ /* This barrier undocks threads docked on pool->threads_dock. */
+ gomp_barrier_wait (&pool->threads_dock);
+ /* And this waits till all threads have called
+gomp_barrier_wa
Re: [RFC] Using function clones for Pointer Bounds Checker
On Wed, May 14, 2014 at 1:18 AM, Ilya Enkovich wrote: > 2014-05-13 23:21 GMT+04:00 Jeff Law : >> On 05/13/14 02:38, Ilya Enkovich wrote: > > propagate constant bounds value and remove checks in called function). So from a linking standpoint, presumably you have to mangle the instrumented caller/callee in some manner. Right? Or are you dynamically dispatching somehow? >>> >>> >>> Originally the idea was o have instrumented clone to have the same >>> assembler name as the original function. Since instrumented code is >>> fully compatible with not instrumented code, we always emit only one >>> version. Usage of the same assembler name allows instrumented and not >>> instrumented calls to look similar in assembler. It worked fine until >>> I tried it with LTO where assembler name is used as a unique >>> identifier. With linker resolutions files it became even more harder >>> to use such approach. To resolve these issues I started to use new >>> assembler name with postfix, but linked with the original name using >>> IDENTIFIER_TRANSPARENT_ALIAS. It gives different assembler names for >>> clones and originals during compilation, but both clone and original >>> functions have similar name in output assembler. >> >> OK. So if I read that correctly, it implies that the existence of bounds >> information does not change the signature of the callee. This is obviously >> important for C++. >> >> Sounds like I need to sit down with the branch and see how this works in the >> new scheme. > > Both mpx branch and Wiki > (http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler) > page are up-to-date now and may be tried out either in NOP mode or > with simulator. Let me know if you have any troubles with using it. > I built it. But "-fcheck-pointer-bounds -mmpx" doesn't generate MPX enabled executable which runs on both MPX-enabled and non MPX-enabled hardwares. I didn't see any MPX run-time library. -- H.J.
Re: [PATCH, libstdc++/61166] overflow when parse number in std::duration operator""
On 14/05/14 15:41 +0100, Jonathan Wakely wrote:
On 14 May 2014 15:36, Jonathan Wakely wrote:
On 14 May 2014 15:25, Ed Smith-Rowland wrote:
But in keeping with, say, our extension type traits and such maybe i should
uglify value as well.
No, just derive from std::integral_constant and you get value "for free".
You already use integral_constant in that file, so the name "value" is
already used.
That also has the advantage that _Digit and _Digit
share the same base class, so you don't end up with two different
static members with the same value (and if you make __valid a typedef
as I suggested you don't have any static members for that either).
I've attached a first pass at doing it that way, using
integral_constant base classes and working with types not values as
much as possible. This gets rid of all static const members except in
_Digits<> (where is that used?)
Do we really need _Digit::value to be unsigned long long, or is it
only the results in _Power_help and _Number_help that need to be
64-bit?
Because I made _Digit derive from integral_constant that
means the partial specialization of _Number_help for single digits has
_Number_help::type as integral_constant, where the other
specializations have integral_constant. That's
inconsistent, but works. Maybe we'd want to be consistent though, and
use this instead of typename _Digit::type:
using type = integral_constant::value>;
(Also, I wonder if we could use std::ratio for the power/base
arithmetic, but it might not help.)
diff --git a/libstdc++-v3/include/bits/parse_numbers.h b/libstdc++-v3/include/bits/parse_numbers.h
index 91a127c..055058e 100644
--- a/libstdc++-v3/include/bits/parse_numbers.h
+++ b/libstdc++-v3/include/bits/parse_numbers.h
@@ -46,185 +46,109 @@ namespace __parse_int {
struct _Digit;
template
-struct _Digit<_Base, '0'>
+struct _Digit<_Base, '0'> : integral_constant
{
- static constexpr bool valid{true};
- static constexpr unsigned value{0};
+ using __valid = true_type;
};
template
-struct _Digit<_Base, '1'>
+struct _Digit<_Base, '1'> : integral_constant
{
- static constexpr bool valid{true};
- static constexpr unsigned value{1};
+ using __valid = true_type;
};
- template
-struct _Digit<_Base, '2'>
+ template
+struct _Digit_impl : integral_constant
{
- static_assert(_Base > 2, "invalid digit");
- static constexpr bool valid{true};
- static constexpr unsigned value{2};
+ static_assert(_Base > _Val, "invalid digit");
+ using __valid = true_type;
};
template
-struct _Digit<_Base, '3'>
-{
- static_assert(_Base > 3, "invalid digit");
- static constexpr bool valid{true};
- static constexpr unsigned value{3};
-};
+struct _Digit<_Base, '2'> : _Digit_impl<_Base, 2>
+{ };
template
-struct _Digit<_Base, '4'>
-{
- static_assert(_Base > 4, "invalid digit");
- static constexpr bool valid{true};
- static constexpr unsigned value{4};
-};
+struct _Digit<_Base, '3'> : _Digit_impl<_Base, 3>
+{ };
template
-struct _Digit<_Base, '5'>
-{
- static_assert(_Base > 5, "invalid digit");
- static constexpr bool valid{true};
- static constexpr unsigned value{5};
-};
+struct _Digit<_Base, '4'> : _Digit_impl<_Base, 4>
+{ };
template
-struct _Digit<_Base, '6'>
-{
- static_assert(_Base > 6, "invalid digit");
- static constexpr bool valid{true};
- static constexpr unsigned value{6};
-};
+struct _Digit<_Base, '5'> : _Digit_impl<_Base, 5>
+{ };
template
-struct _Digit<_Base, '7'>
-{
- static_assert(_Base > 7, "invalid digit");
- static constexpr bool valid{true};
- static constexpr unsigned value{7};
-};
+struct _Digit<_Base, '6'> : _Digit_impl<_Base, 6>
+{ };
template
-struct _Digit<_Base, '8'>
-{
- static_assert(_Base > 8, "invalid digit");
- static constexpr bool valid{true};
- static constexpr unsigned value{8};
-};
+struct _Digit<_Base, '7'> : _Digit_impl<_Base, 7>
+{ };
template
-struct _Digit<_Base, '9'>
-{
- static_assert(_Base > 9, "invalid digit");
- static constexpr bool valid{true};
- static constexpr unsigned value{9};
-};
+struct _Digit<_Base, '8'> : _Digit_impl<_Base, 8>
+{ };
template
-struct _Digit<_Base, 'a'>
-{
- static_assert(_Base > 0xa, "invalid digit");
- static constexpr bool valid{true};
- static constexpr unsigned value{0xa};
-};
+struct _Digit<_Base, '9'> : _Digit_impl<_Base, 9>
+{ };
template
-struct _Digit<_Base, 'A'>
-{
- static_assert(_Base > 0xa, "invalid digit");
- static constexpr bool valid{true};
- static constexpr unsigned value{0xa};
-};
+struct _Digit<_Base, 'a'> : _Digit_impl<_Base, 0xa>
+{ };
template
-struct _Digit<_Base, 'b'>
[committed] Suppress INSN_UIDs if flag_dump_unnumbered
Moving the location of INSN_UID broke the handling of -fdump-unnumbered.
I tested that it fixes the sparc-sun-solaris2.11 failures reported
by Rainer. Applied as obvious.
Thanks,
Richard
gcc/
PR debug/61188
* print-rtl.c (print_rtx): Suppress uids if flag_dump_unnumbered.
Index: gcc/print-rtl.c
===
--- gcc/print-rtl.c 2014-05-14 16:51:39.687377980 +0100
+++ gcc/print-rtl.c 2014-05-14 16:51:39.911379968 +0100
@@ -188,7 +188,12 @@ print_rtx (const_rtx in_rtx)
#endif
if (INSN_CHAIN_CODE_P (GET_CODE (in_rtx)))
-fprintf (outfile, " %d", INSN_UID (in_rtx));
+{
+ if (flag_dump_unnumbered)
+ fprintf (outfile, " #");
+ else
+ fprintf (outfile, " %d", INSN_UID (in_rtx));
+}
/* Get the format string and skip the first elements if we have handled
them already. */
gphi_iterator? (was Re: [PATCH 09/89] Introduce gimple_phi_iterator)
On Fri, 2014-05-09 at 12:51 -0600, Jeff Law wrote: > On 04/21/14 10:56, David Malcolm wrote: > > gcc/ > > * gimple-iterator.h (struct gimple_phi_iterator): New subclass of > > gimple_stmt_iterator with identical layout, but adding... > > (gimple_phi_iterator::phi): ...new method, equivalent to > > gsi_stmt (), but casting the underlying gimple to gimple_phi, > > checking that code == GIMPLE_PHI in a checked build. > > (gsi_start_phis): Return a gimple_phi_iterator, rather than just a > > gimple_stmt_iterator. > > > > * tree-if-conv.c (bb_with_exit_edge_p): Require a gimple_phi rather > > than just a gimple. > > (if_convertible_phi_p): Likewise. > > * tree-phinodes.h (add_phi_node_to_bb): Likewise. > > * tree-ssa-phiprop.c (propagate_with_phi): Likewise. > > > > * tree-ssa-uninit.c (warn_uninitialized_phi): Require a gimple_phi > > and a vec *, rather than just a gimple and vec *. > > (find_uninit_use): Likewise; add checked cast to gimple_phi when > > adding to worklist. > > (execute_late_warn_uninitialized): Strengthen types of various locals, > > "worklist" from vec to vec, "gsi" to a > > gimple_phi_iterator, and "phi" and "cur_phi" to a gimple_phi. > > > > * tree-ssa-loop-manip.c (rewrite_phi_with_iv): Require a > > gimple_phi_iterator * rather than a gimple_stmt_iterator *; > > use it to strengthen local from a gimple to a gimple_phi. > > > > * cfgloop.c (find_subloop_latch_edge_by_ivs): Convert local from a > > gimple_stmt_iterator to a gimple_phi_iterator. Use the iterator's > > "phi" method rather than gsi_stmt. Use this checked cast to convert > > the type of related local from a plain gimple to a gimple_phi. > > * gimple-pretty-print.c (dump_phi_nodes): Likewise. > > * gimple-ssa-isolate-paths.c (find_implicit_erroneous_behaviour): > > Likewise. > > * sese.c (sese_add_exit_phis_edge): Likewise. > > * tree-cfg.c (reinstall_phi_args): Likewise. > > (gimple_make_forwarder_block): Likewise. > > (add_phi_args_after_copy_edge): Likewise. > > (gimple_lv_adjust_loop_header_phi): Likewise. > > * tree-cfgcleanup.c (phi_alternatives_equal): Likewise. > > (remove_forwarder_block_with_phi): Likewise. > > (merge_phi_nodes): Likewise. > > * tree-complex.c (update_phi_components): Likewise. > > * tree-if-conv.c (if_convertible_loop_p_1): Likewise. > > * tree-inline.c (update_ssa_across_abnormal_edges): Likewise. > > (copy_phis_for_bb): Likewise. > > * tree-into-ssa.c (rewrite_add_phi_arguments): Likewise. > > * tree-outof-ssa.c (eliminate_build): Likewise. > > (eliminate_useless_phis): Likewise. > > (rewrite_trees): Likewise. > > (insert_backedge_copies): Likewise. > > * tree-phinodes.c (reserve_phi_args_for_new_edge): Likewise. > > (remove_phi_args): Likewise. > > (remove_phi_nodes): Likewise. > > * tree-predcom.c (find_looparound_phi): Likewise. > > (eliminate_temp_copies): Likewise. > > * tree-scalar-evolution.c (loop_closed_phi_def): Likewise. > > (scev_const_prop): Likewise; also, add checked cast to phi. > > * tree-ssa-coalesce.c (coalesce_partitions): Likewise. > > * tree-ssa-dce.c (remove_dead_phis): Likewise. > > (forward_edge_to_pdom): Likewise. > > * tree-ssa-dom.c (record_equivalences_from_phis): Likewise. > > (cprop_into_successor_phis): Likewise. > > (propagate_rhs_into_lhs): Likewise. > > (eliminate_degenerate_phis_1): Likewise. > > * tree-ssa-ifcombine.c (same_phi_args_p): Likewise. > > * tree-ssa-live.c (calculate_live_on_exit): Likewise. > > (verify_live_on_entry): Likewise. > > * tree-ssa-loop-im.c > > (move_computations_dom_walker::before_dom_children): Likewise. > > * tree-ssa-loop-ivopts.c (find_bivs): Likewise. > > (mark_bivs): Likewise. > > (find_interesting_uses_outside): Likewise. > > (determine_set_costs): Likewise. > > * tree-ssa-loop-manip.c (split_loop_exit_edge): Likewise. > > (tree_transform_and_unroll_loop): Likewise. > > (rewrite_all_phi_nodes_with_iv): Likewise. > > (canonicalize_loop_ivs): Likewise. > > * tree-ssa-loop-niter.c (determine_value_range): Likewise. > > * tree-ssa-phiopt.c (hoist_adjacent_loads): Likewise. > > * tree-ssa-phiprop.c (tree_ssa_phiprop): Likewise. > > * tree-ssa-reassoc.c (suitable_cond_bb): Likewise. > > * tree-ssa-tail-merge.c (same_phi_alternatives_1): Likewise. > > (vop_phi): Likewise. > > * tree-ssa-threadedge.c (record_temporary_equivalences_from_phis): > > Likewise. > > * tree-ssa-threadupdate.c (copy_phi_arg_into_existing_phi): Likewise. > > (copy_phi_args): Likewise. > > (phi_args_equal_on_edges): Likewise. > > * tree-ssa.c (ssa_redirect_edge): Likewise. > > (flush_pending_stmts): Likewise. > > * tree-switch-conversion.c (check_final_bb): Likewise. > > (gather_default_values): Likewise. > > (b
Re: gphi_iterator? (was Re: [PATCH 09/89] Introduce gimple_phi_iterator)
On 05/14/14 09:28, David Malcolm wrote: Thanks. I'm working my way through the patches, converting them to the latest approach, where "gimple_phi" becomes "gphi *". Given that renaming, it occurred to me that the new class "gimple_phi_iterator" would be better named as "gphi_iterator" (consistency, and less typing). Is this renaming OK? (I wasn't planning to rename the pre-existing gimple_stmt_iterator) Yea, that's fine. jeff
Re: [patch] fix impliedness of -Wunused-parameter depending on -Wexta option ordering
Am 12.05.2014 19:30, schrieb Joseph S. Myers: > On Mon, 12 May 2014, Matthias Klose wrote: > >> I didn't look close enough to the gfortran test results. PR driver/61126 is >> a >> fix for the regression introduced with the fix for the above issue. With >> this >> patch proposed by Manuel, gfortran.dg/wextra_1.f now passes, and no new >> regressions seen on the trunk and the branches. > > I think changing the order of the handlers has far too high a risk of > introducing further nonobvious regressions to consider it for the > branches. You need a clear and careful analysis of the circumstances > under which the order of the handlers can affect observable compiler > behavior in order to justify such a change as safe. But I think a better > principle is that if the order matters, there is a bug in those handlers > and they should be fixed so that the order doesn't matter (absent a clear > design showing why it is desirable for the order to matter). reverted the fix for PR driver/61106 on the branches, keeping the unused-8b.c test case. Matthias
Re: [patch] Minor improvement to fold_unary_loc
On 05/14/14 04:40, Eric Botcazou wrote: Hi, this makes fold_unary_loc fold NON_LVALUE_EXPR if the argument cannot be a lvalue (this happens when you're re-fold-building an existing tree) and changes the first call to fold_convert_const to use arg0 instead of op0, like the other 2 calls just below (this should not change anything if the argument is correctly folded, but is more forgiving if it is not). Tested on x86_64-suse-linux, OK for the mainline? 2014-05-14 Eric Botcazou * fold-const (fold_unary_loc) : New case. : Pass arg0 instead of op0 to fold_convert_const. Seems reasonable. Do you happen to have a testcase where you can see the effects in one of the dumps? Jeff
[C++ Patch] Add IS_DIRECT_INITIALIZER?
Hi, I was having a look to a couple of issues in this area, and wondered if we want to do something like the below? In case, I would also go with the first init.c hunk and the mangle.c hunk, I don't think the additional check can hurt?!? Thanks, Paolo. /
Re: [C++ Patch] Add IS_DIRECT_INITIALIZER?
... the draft ;)
///
Index: call.c
===
--- call.c (revision 210424)
+++ call.c (working copy)
@@ -6071,8 +6071,7 @@ convert_like_real (conversion *convs, tree expr, t
constructors, but actually trying to call one is an error. */
if (DECL_NONCONVERTING_P (convfn) && DECL_CONSTRUCTOR_P (convfn)
/* Unless this is for direct-list-initialization. */
- && !(BRACE_ENCLOSED_INITIALIZER_P (expr)
-&& CONSTRUCTOR_IS_DIRECT_INIT (expr)))
+ && !IS_DIRECT_INITIALIZER (expr))
{
if (!(complain & tf_error))
return error_mark_node;
@@ -7803,8 +7802,7 @@ build_new_method_call_1 (tree instance, tree fns,
/* If CONSTRUCTOR_IS_DIRECT_INIT is set, this was a T{ } form
initializer, not T({ }). */
if (DECL_CONSTRUCTOR_P (fn) && args != NULL && !vec_safe_is_empty (*args)
- && BRACE_ENCLOSED_INITIALIZER_P ((**args)[0])
- && CONSTRUCTOR_IS_DIRECT_INIT ((**args)[0]))
+ && IS_DIRECT_INITIALIZER ((**args)[0]))
{
tree init_list = (**args)[0];
tree init = NULL_TREE;
Index: cp-tree.h
===
--- cp-tree.h (revision 210424)
+++ cp-tree.h (working copy)
@@ -3437,6 +3437,9 @@ more_aggr_init_expr_args_p (const aggr_init_expr_a
B b{1,2}, not B b({1,2}) or B b = {1,2}. */
#define CONSTRUCTOR_IS_DIRECT_INIT(NODE) (TREE_LANG_FLAG_0 (CONSTRUCTOR_CHECK
(NODE)))
+#define IS_DIRECT_INITIALIZER(NODE) \
+ (BRACE_ENCLOSED_INITIALIZER_P (NODE) && CONSTRUCTOR_IS_DIRECT_INIT (NODE))
+
/* True if NODE represents a conversion for direct-initialization in a
template. Set by perform_implicit_conversion_flags. */
#define IMPLICIT_CONV_EXPR_DIRECT_INIT(NODE) \
Index: decl2.c
===
--- decl2.c (revision 210424)
+++ decl2.c (working copy)
@@ -983,8 +983,7 @@ grokfield (const cp_declarator *declarator,
if (attrlist)
cplus_decl_attributes (&value, attrlist, 0);
- if (init && BRACE_ENCLOSED_INITIALIZER_P (init)
- && CONSTRUCTOR_IS_DIRECT_INIT (init))
+ if (init && IS_DIRECT_INITIALIZER (init))
flags = LOOKUP_NORMAL;
else
flags = LOOKUP_IMPLICIT;
Index: init.c
===
--- init.c (revision 210424)
+++ init.c (working copy)
@@ -642,8 +642,7 @@ perform_member_init (tree member, tree init)
&& TREE_TYPE (init) == type)
/* { } mem-initializer. */
|| (TREE_CODE (init) == TREE_LIST
- && TREE_CODE (TREE_VALUE (init)) == CONSTRUCTOR
- && CONSTRUCTOR_IS_DIRECT_INIT (TREE_VALUE (init
+ && IS_DIRECT_INITIALIZER (TREE_VALUE (init
&& (CP_AGGREGATE_TYPE_P (type)
|| is_std_init_list (type)
{
@@ -1515,8 +1514,7 @@ build_aggr_init (tree exp, tree init, int flags, t
&& TREE_CODE (init) != TREE_LIST
&& !(TREE_CODE (init) == TARGET_EXPR
&& TARGET_EXPR_DIRECT_INIT_P (init))
- && !(BRACE_ENCLOSED_INITIALIZER_P (init)
- && CONSTRUCTOR_IS_DIRECT_INIT (init)))
+ && !IS_DIRECT_INITIALIZER (init))
flags |= LOOKUP_ONLYCONVERTING;
if (TREE_CODE (type) == ARRAY_TYPE)
@@ -1589,8 +1587,7 @@ expand_default_init (tree binfo, tree true_exp, tr
/* If we have direct-initialization from an initializer list, pull
it out of the TREE_LIST so the code below can see it. */
if (init && TREE_CODE (init) == TREE_LIST
- && BRACE_ENCLOSED_INITIALIZER_P (TREE_VALUE (init))
- && CONSTRUCTOR_IS_DIRECT_INIT (TREE_VALUE (init)))
+ && IS_DIRECT_INITIALIZER (TREE_VALUE (init)))
{
gcc_checking_assert ((flags & LOOKUP_ONLYCONVERTING) == 0
&& TREE_CHAIN (init) == NULL_TREE);
@@ -2791,8 +2788,7 @@ build_new_1 (vec **placement, tree ty
{
tree vecinit = NULL_TREE;
if (vec_safe_length (*init) == 1
- && BRACE_ENCLOSED_INITIALIZER_P ((**init)[0])
- && CONSTRUCTOR_IS_DIRECT_INIT ((**init)[0]))
+ && IS_DIRECT_INITIALIZER ((**init)[0]))
{
vecinit = (**init)[0];
if (CONSTRUCTOR_NELTS (vecinit) == 0)
Index: mangle.c
===
--- mangle.c(revision 210424)
+++ mangle.c(working copy)
@@ -2806,8 +2806,7 @@ write_expression (tree expr)
write_type (type);
if (init && TREE_CODE (init) == TREE_LIST
- && TREE_CODE (TREE_VALUE (init)) == CONSTRUCTOR
- && CONSTRUCTOR_IS_DIRECT_INIT (TREE_VALUE (init)))
+ && IS_DIRECT_INITIALIZER (TREE_VALUE (init)))
write_expression (TREE_VALUE (init));
else
{
Index: parser.c
=
Re: [PATCH] Implement -fsanitize=float-cast-overflow
On Wed, 14 May 2014, Jakub Jelinek wrote: > So what do you see as the way to handle this properly? > I mean, for REAL_MODE_FORMAT (TYPE_MODE (expr_type))->b == 2 supposedly to > avoid issues with > rounding of the max we could just > REAL_VALUE_TYPE maxval = dconst1; > SET_REAL_EXP (&maxval, REAL_EXP (&maxval) + TYPE_PRECISION (type) - > !TYPE_UNSIGNED (type)); > real_convert (&maxval, TYPE_MODE (expr_type), &maxval); > max = build_real (expr_type, maxval); > or so, then supposedly max is always the smallest representable binary > floating point value above or equal to TYPE_MAX_VALUE + 1.0. Yes. Either the power of 2 is exactly representable, or it rounds up to +Inf, and in either case >= (or unordered) is the right test. > For the min value, if it is unsigned, then -1.0 is ok for all binary or > decimal floats, if it is signed, then supposedly we could do the above Yes. > with s/max/min/;s/dconst1/dconstm1/; and, after the real_convert > do inexact = real_arithmetic (&newminval, MINUS_EXPR, &minval, &dconst1); > if !inexact just min = build_real (expr_type, newminval); and be done with > it (the question is if for IBM double double this will DTRT for > LONG_LONG_MIN, which I think should be that the high double will contain > (double) LONG_LONG_MIN and the low double -1.0). For inexact > (which should be the same thing as if result of real_arithmetic + real_convert > is the same as original minval) we need to subtract more than one, dunno if > we should just compute it from the REAL_EXP and precision, or just keep > subtracing powers of two until after real_convert it is no longer bitwise > identical to original minval. We don't have anything close to > real_nextafter nor real_convert variant that can round for arbitrary > rounding modes. > Any preferences how to implement this? In the inexact case but where the power of 2 is representable, you could always handle it as < min rather than <= min-1 - although computing the actual nextafter value based on the precision of the floating-point type shouldn't be hard and would allow <= to be used everywhere. (If min overflows to -Inf, then <= -Inf is correct, use of < would be an incorrect test.) > For _Decimal*, no idea unfortunately, perhaps for the first iteration > ubsan should ignore decimal to int conversions. Yes, that seems reasonable. (Computing the exact max+1 or min-1 as an MPFR value and then using mpfr_snprintf (then decimal_real_from_string) would be one way of converting to decimal with a controlled rounding direction.) -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Clean up shrink-wrapping codes
On 05/13/14 02:13, Marek Polacek wrote: On Tue, May 13, 2014 at 04:08:21PM +0800, Zhenqiang Chen wrote: On 13 May 2014 15:55, Marek Polacek wrote: On Tue, May 13, 2014 at 03:14:34PM +0800, Zhenqiang Chen wrote: Thanks. Committed the patch @r210351 with changes: (1) Create shrink-wrap.h. (2) Move all shrink-wrapping related interfaces from function.h to shrink-wrap.h. (3) shrink-wrap.h is included in function.c, shrink-wrap.c and config/i386/i386.c. Could you please update the comment at the beginning of shrink-wrap.c? It certainly shouldn't say the same what function.c says. There are two /*..*/ blocks at the beginning. As I understand the first /*...*/ is the copyright/license, which should be same for all files. And I had changed the second /*...*/ as /* This file handles shrink-wrapping related optimizations. */ Which comment do you mean? I meant the very first line that says "Expands front end tree to back end RTL for GCC.". I guess best would be just to replace it with the "This file handles shrink-wrapping related optimizations." line. I think that's fixed in a follow-up patch from Zhenqiang. jeff
Re: [PATCH, 2/2] shrink wrap a function with a single loop: split live_edge
On 05/13/14 03:49, Zhenqiang Chen wrote: On 9 May 2014 14:08, Jeff Law wrote: On 05/08/14 02:07, Zhenqiang Chen wrote: Hi, The patch splits the live_edge for move_insn_for_shrink_wrap to sink the copy out of the entry block. Bootstrap and no make check regression on X86-64 and ARM. OK for trunk? Thanks! -Zhenqiang ChangeLog: 2014-05-08 Zhenqiang Chen * function.c (next_block_for_reg): Allow live_edge->dest has two predecessors. (move_insn_for_shrink_wrap): Split live_edge. (prepre_shrink_wrap): One more parameter for move_insn_for_shrink_wrap. OK. jeff
Re: [PATCH 1/3] Handwritten part of conversion of "gimple" to "gimple *"
On 05/12/14 15:36, David Malcolm wrote: [ ... Big Snip ... ] This series of 3 patches is approved. Jeff
Re: [PATCH, 1/2] shrink wrap a function with a single loop: copy propagation
On 05/13/14 04:04, Zhenqiang Chen wrote: After reading the code in regcprop.c, I think I should reuse the copyprop_hardreg_forward_1. So rewrite the patch, which is much simple and should handle HAVE_cc0. But not sure we'd handle DEBUG_INSN or not. 2014-05-13 Zhenqiang Chen * regcprop.c (skip_debug_insn_p): New decl. (replace_oldest_value_reg): Check skip_debug_insn_p. (copyprop_hardreg_forward_bb_without_debug_insn.): New function. * shrink-wrap.c (prepare_shrink_wrap): Call copyprop_hardreg_forward_bb_without_debug_insn. * function.h (copyprop_hardreg_forward_bb_without_debug_insn): New prototype. testsuite/ChangeLog: 2014-05-13 Zhenqiang Chen * shrink-wrap-loop.c: New test case. Basically OK. Can you create regcprop.h and put the prototype for copyprop_hardreg_forward_bb_without_debug_insn in there? Then include regcprop.h in shrink-wrap.c. With that change, approved. Please post the final version for archival purposes. jeff
Re: [patch, mips] delete bit-rotten ADJUST_REG_ALLOC_ORDER definition
On 05/13/14 14:11, Sandra Loosemore wrote:
This patch is a follow-up to this thread from a few years ago:
https://gcc.gnu.org/ml/gcc/2011-01/msg00093.html
https://gcc.gnu.org/ml/gcc/2011-01/msg00158.html
As noted there, the current definition of ADJUST_REG_ALLOC_ORDER is
obsolete:
(1) This hook is a holdover from the old pre-IRA register allocator and
it's not clear it does anything useful with IRA.
(2) It's inconsistent with the current REG_ALLOC_ORDER definition which
is not just {0, 1, 2, ...} any more.
I considered re-working the hook to jiggle the $24 ordering for MIPS16
relative to the current REG_ALLOC_ORDER definition, but it wasn't clear
to me either where in the ordering it should go, or that it would be
worthwhile to try to tune this. Indeed, the CSiBE results for removing
it entirely are pretty much in the noise range, except that removing the
hack that is supposed to benefit MIPS16 resulted in more improvement for
that case than any of the others tested! Here are some numbers
comparing geomean for old and new with -Os for various combinations:
default: 1062.3,1062.28
-EL -mips16 -msoft-float: 758.624,758.551
-EL -mips16: 763.398,763.321
-EL -msoft-float: 1115.11,1115.09
-EL: 1062.22,1062.2
-EL -mabi=64: 1181.8,1181.81
-mabi=64: 1181.93,1181.94
-mips16 -msoft-float: 758.337,758.236
-mips16: 763.11,763.011
-EL -mabi=64 -msoft-float: 1218.11,1218.11
-mabi=64 -msoft-float: 1218.24,1218.25
-msoft-float: 1115.73,1115.71
-EL -mmicromips -msoft-float: 792.314,792.32
-EL -mnan=2008: 1062.22,1062.2
-mnan=2008: 1062.3,1062.28
As for the invalid JALR patch I posted just now
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01015.html
I had trouble regression-testing this patch on trunk due to various
other breakage in the past week, and ended up doing it on a 4.9.0
checkout modified to support Mentor's extended set of mips-sde-elf
multilibs instead. That's also the source of the CSiBE numbers above.
Also, those numbers do include the JALR patch in the baseline.
This patch did fix some of the dspr2-MULT.c and dspr2-MULTU.c test
failures that were reported in the original discussion, but I believe
the current XFAILs for those tests are still valid for the same reasons
listed in PR target/51729.
So, this patch should be considered more of a code cleanup thing, than
either an optimization improvement or a test regression fix. OK to commit?
-Sandra
2014-05-13 Catherine Moore
Sandra Loosemore
gcc/
* config/mips/mips.c (mips_order_regs_for_local_alloc): Delete.
* config/mips/mips.h (ADJUST_REG_ALLOC_ORDER): Delete.
* config/mips/mips-protos.h (mips_order_regs_for_local_alloc): Delete.
OK for the trunk.
jeff
Re: [PATCH 0/2] Make option-lookup macros explicit
On 05/09/14 15:14, David Malcolm wrote:
GCC's code is full of references to options like:
static bool
gate_vrp (void)
{
return flag_tree_vrp != 0;
}
where "flag_tree_vrp" is actually an autogenerated macro to:
global_options.x_flag_tree_vrp
This is deeply confusing to a newbie (and indeed still to me after ~two
years of working with GCC's internals) e.g. when stepping through code and
trying to query the value in gdb - what is an actual variable, and what is
an option? Why isn't tab-completion working? etc
The idea of the following patch series is to replace the above with:
static bool
gate_vrp (void)
{
return GCC_OPTION (flag_tree_vrp) != 0;
}
thus making it obvious when macro magic is occurring.
Conceptually this patch seems fine to me. I think the macro magic
around flag_xxx is annoying, so this is definitely an improvement.
From a global-state-removal perspective, it might be nice to associate
options with a gcc::context, rather than have a single instance of options,
though that isn't addressed in these patches.
(e.g. perhaps explicitly adding a gcc::context arg to the macro???)
Should be done as a follow-up IMHO.
The patches were successfully bootstrapped®rtested on top
of r208714 (rather old, 2014-03-20) albeit just on x86_64-unknown-linux-gnu
(Fedora 20), with
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto
(i.e. every frontend, I think).
OK for trunk, after 4.9.1 is released? (clearly I need to test on
more targets first, given how much config/* code this touches, but I
wanted to sound the idea out on this list).
Yea, definitely test out some other targets and wait for the 4.9.1
release. But I'm inclined to approve the patch as it stands plus any
trivial changes that have to be made due to 4.9.0->4.9.1 changes in
nearby code.
jeff
Re: [C++ Patch] Add IS_DIRECT_INITIALIZER?
The name suggests that it would be true for any direct initialization, which is wrong; see TARGET_EXPR_DIRECT_INIT_P (and the similarly wrongly named DIRECT_INIT_EXPR_P). Call your macro DIRECT_LIST_INIT_P and it's OK. Jason
Re: Optimize n?rotate(x,n):x
On 05/01/14 15:52, Marc Glisse wrote: Hello, here is the latest version. Reviewers seemed happy with different versions, so I went for the simplest one. We only give up on the transformation if we are optimizing for speed, the short-cut has probability >50% and the operation the branch is avoiding is expensive (i.e. only divisions, with the current estimate_num_insns). The optab checks are gone, they should eventually be added to estimate_num_insns instead. I believe this is covered by the previous "ok", but I won't commit anything before Tuesday. It would have been more general (and shorter) to call fold after substituting the tested value and see if the result matches the other phi argument (it might handle (a!=b)?a|b:a for instance), instead of the *_element_p tests. I may try that later, but I guess the current patch is good enough for now. 2014-05-06 Marc Glisse PR tree-optimization/59100 gcc/ * tree-ssa-phiopt.c: Include tree-inline.h. (neutral_element_p, absorbing_element_p): New functions. (value_replacement): Handle conditional binary operations with a neutral or absorbing element. gcc/testsuite/ * gcc.dg/tree-ssa/phi-opt-12.c: New file. * gcc.dg/tree-ssa/phi-opt-13.c: Likewise. Going with the simpler one is a good default IMHO. As you note, you can always follow-up with refinements if the additional cases turn out to be important. OK for the trunk. jeff
Re: [C++ Patch] Add IS_DIRECT_INITIALIZER?
Hi, On 05/14/2014 08:34 PM, Jason Merrill wrote: The name suggests that it would be true for any direct initialization, which is wrong; see TARGET_EXPR_DIRECT_INIT_P (and the similarly wrongly named DIRECT_INIT_EXPR_P). Call your macro DIRECT_LIST_INIT_P and it's OK. A good, thanks. I was a bit unsure myself. Paolo.
Re: [patch, mips] delete bit-rotten ADJUST_REG_ALLOC_ORDER definition
Jeff Law writes:
> On 05/13/14 14:11, Sandra Loosemore wrote:
>> This patch is a follow-up to this thread from a few years ago:
>>
>> https://gcc.gnu.org/ml/gcc/2011-01/msg00093.html
>> https://gcc.gnu.org/ml/gcc/2011-01/msg00158.html
>>
>> As noted there, the current definition of ADJUST_REG_ALLOC_ORDER is
>> obsolete:
>>
>> (1) This hook is a holdover from the old pre-IRA register allocator and
>> it's not clear it does anything useful with IRA.
>>
>> (2) It's inconsistent with the current REG_ALLOC_ORDER definition which
>> is not just {0, 1, 2, ...} any more.
>>
>> I considered re-working the hook to jiggle the $24 ordering for MIPS16
>> relative to the current REG_ALLOC_ORDER definition, but it wasn't clear
>> to me either where in the ordering it should go, or that it would be
>> worthwhile to try to tune this. Indeed, the CSiBE results for removing
>> it entirely are pretty much in the noise range, except that removing the
>> hack that is supposed to benefit MIPS16 resulted in more improvement for
>> that case than any of the others tested! Here are some numbers
>> comparing geomean for old and new with -Os for various combinations:
>>
>> default: 1062.3,1062.28
>> -EL -mips16 -msoft-float: 758.624,758.551
>> -EL -mips16: 763.398,763.321
>> -EL -msoft-float: 1115.11,1115.09
>> -EL: 1062.22,1062.2
>> -EL -mabi=64: 1181.8,1181.81
>> -mabi=64: 1181.93,1181.94
>> -mips16 -msoft-float: 758.337,758.236
>> -mips16: 763.11,763.011
>> -EL -mabi=64 -msoft-float: 1218.11,1218.11
>> -mabi=64 -msoft-float: 1218.24,1218.25
>> -msoft-float: 1115.73,1115.71
>> -EL -mmicromips -msoft-float: 792.314,792.32
>> -EL -mnan=2008: 1062.22,1062.2
>> -mnan=2008: 1062.3,1062.28
>>
>> As for the invalid JALR patch I posted just now
>> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01015.html
>> I had trouble regression-testing this patch on trunk due to various
>> other breakage in the past week, and ended up doing it on a 4.9.0
>> checkout modified to support Mentor's extended set of mips-sde-elf
>> multilibs instead. That's also the source of the CSiBE numbers above.
>> Also, those numbers do include the JALR patch in the baseline.
>>
>> This patch did fix some of the dspr2-MULT.c and dspr2-MULTU.c test
>> failures that were reported in the original discussion, but I believe
>> the current XFAILs for those tests are still valid for the same reasons
>> listed in PR target/51729.
>>
>> So, this patch should be considered more of a code cleanup thing, than
>> either an optimization improvement or a test regression fix. OK to commit?
>>
>> -Sandra
>>
>>
>> 2014-05-13 Catherine Moore
>> Sandra Loosemore
>>
>> gcc/
>> * config/mips/mips.c (mips_order_regs_for_local_alloc): Delete.
>> * config/mips/mips.h (ADJUST_REG_ALLOC_ORDER): Delete.
>> * config/mips/mips-protos.h (mips_order_regs_for_local_alloc): Delete.
> OK for the trunk.
Would it be OK to hold off until after the switch to LRA? That patch
has been written and the MIPS parts approved, but we're waiting for
some legal things to be sorted out and for a fixed version of the LRA
EXTRA_MEMORY_CONSTRAINT patch. I just think it'd be better to tune this
sort of thing once that's done, rather than tune it against reload.
I realise this is old code (goes back to the initial MIPS16 commit),
but the reasoning behind promoting $24 still seems sound. So I was
hoping to see whether the bad performance is from promoting $24 itself
or whether it's from the damage that:
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
reg_alloc_order[i] = i;
does to the other registers.
FWIW here's an old patch I had lying around. I wasn't happy with
the results for CSiBE at the time but maybe it'd be worth looking
at it again after LRA. E.g., we might want to put the non-MIPS16
call-clobbered GPRs ahead of the MIPS16 ones, so that when we're
looking for any old GPR, we only pick a MIPS16 register if no
others are free.
Thanks,
Richard
Index: gcc/config/mips/mips-protos.h
===
--- gcc/config/mips/mips-protos.h 2011-09-17 10:18:14.0 +0100
+++ gcc/config/mips/mips-protos.h 2011-09-17 19:22:49.0 +0100
@@ -248,7 +248,6 @@ extern bool mips_expand_ext_as_unaligned
extern bool mips_expand_ins_as_unaligned_store (rtx, rtx, HOST_WIDE_INT,
HOST_WIDE_INT);
extern bool mips_mem_fits_mode_p (enum machine_mode mode, rtx x);
-extern void mips_order_regs_for_local_alloc (void);
extern HOST_WIDE_INT mips_debugger_offset (rtx, HOST_WIDE_INT);
extern void mips_push_asm_switch (struct mips_asm_switch *);
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c 2011-09-17 08:59:21.0 +0100
+++ gcc/config/mips/mips.c 2011-09-17 19:22:49.0 +0100
@@ -15900,28 +15900,6 @@ mips_expand_vector_init (rtx target, rtx
emit_move_insn (target, mem);
}
Re: [PATCH, Pointer Bounds Checker 1/x] Pointer bounds type and mode
On 04/16/14 05:00, Ilya Enkovich wrote: Hi, This patch restarts the series for introducing Pointer Bounds Checker instrumentation and supporting Intel Memory Protection Extension (MPX) technology. Detailed description is on GCC Wiki page: http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler. The first patch introduces pointer bounds type and mode. It was approved earlier for 4.9 and had no significant changes since then. I'll assume patch is OK if no objections arise. Patch was bootstrapped and tested for linux-x86_64. Thanks, Ilya -- gcc/ 2014-04-16 Ilya Enkovich * mode-classes.def (MODE_POINTER_BOUNDS): New. * tree.def (POINTER_BOUNDS_TYPE): New. * genmodes.c (complete_mode): Support MODE_POINTER_BOUNDS. (POINTER_BOUNDS_MODE): New. (make_pointer_bounds_mode): New. * machmode.h (POINTER_BOUNDS_MODE_P): New. * stor-layout.c (int_mode_for_mode): Support MODE_POINTER_BOUNDS. (layout_type): Support POINTER_BOUNDS_TYPE. * tree-pretty-print.c (dump_generic_node): Support POINTER_BOUNDS_TYPE. * tree.c (build_int_cst_wide): Support POINTER_BOUNDS_TYPE. (type_contains_placeholder_1): Likewise. * tree.h (POINTER_BOUNDS_TYPE_P): New. * varasm.c (output_constant): Support POINTER_BOUNDS_TYPE. * doc/rtl.texi (MODE_POINTER_BOUNDS): New. OK. But please hold off installing until the entire set is approved per Richi's request. jeff
[patch] Update catch(...) handlers to deal with __forced_unwind
Failing to rethrow a __forced_unwind exception is very bad.
This patch ensures we rethrow them in async tasks, and makes the
shared state ready with a broken_promise so that waiting threads
don't block forever. That seems reasonable to me, does anyone have any
better ideas?
Tested x86_64-linux, will wait for feedback before committing.
commit 8d4a49e0391269380b160bd277339f740716de0c
Author: Jonathan Wakely
Date: Tue May 13 15:35:29 2014 +0100
* include/std/condition_variable (condition_variable_any::_Unlock): Do
not swallow __forced_unwind.
* include/std/future (__future_base::_Task_setter): Likewise.
(__future_base::_Async_state_impl): Turn __forced_unwind into broken
promise and rethrow.
* include/std/mutex (try_lock): Likewise.
* testsuite/30_threads/async/forced_unwind.cc: New.
* testsuite/30_threads/packaged_task/forced_unwind.cc: New.
diff --git a/libstdc++-v3/include/std/condition_variable b/libstdc++-v3/include/std/condition_variable
index fc111dd..921cb83 100644
--- a/libstdc++-v3/include/std/condition_variable
+++ b/libstdc++-v3/include/std/condition_variable
@@ -189,7 +189,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
~_Unlock() noexcept(false)
{
if (uncaught_exception())
- __try { _M_lock.lock(); } __catch(...) { }
+ {
+ __try
+ { _M_lock.lock(); }
+ __catch(const __cxxabiv1::__forced_unwind&)
+ { __throw_exception_again; }
+ __catch(...)
+ { }
+ }
else
_M_lock.lock();
}
diff --git a/libstdc++-v3/include/std/future b/libstdc++-v3/include/std/future
index 717ce71..8972ecf 100644
--- a/libstdc++-v3/include/std/future
+++ b/libstdc++-v3/include/std/future
@@ -1231,6 +1231,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
_M_result->_M_set(_M_fn());
}
+ __catch(const __cxxabiv1::__forced_unwind&)
+ {
+ __throw_exception_again; // will cause broken_promise
+ }
__catch(...)
{
_M_result->_M_error = current_exception();
@@ -1250,6 +1254,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
_M_fn();
}
+ __catch(const __cxxabiv1::__forced_unwind&)
+ {
+ __throw_exception_again; // will cause broken_promise
+ }
__catch(...)
{
_M_result->_M_error = current_exception();
@@ -1510,7 +1518,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
: _M_result(new _Result<_Res>()), _M_fn(std::move(__fn))
{
_M_thread = std::thread{ [this] {
- _M_set_result(_S_task_setter(_M_result, _M_fn));
+ __try
+ {
+ _M_set_result(_S_task_setter(_M_result, _M_fn));
+ }
+ __catch (const __cxxabiv1::__forced_unwind&)
+ {
+ // make the shared state ready on thread cancellation
+ if (static_cast(_M_result))
+ this->_M_break_promise(std::move(_M_result));
+ __throw_exception_again;
+ }
} };
}
diff --git a/libstdc++-v3/include/std/mutex b/libstdc++-v3/include/std/mutex
index 3d70754..f6b851c 100644
--- a/libstdc++-v3/include/std/mutex
+++ b/libstdc++-v3/include/std/mutex
@@ -44,6 +44,7 @@
#include
#include
#include // for std::swap
+#include
#ifdef _GLIBCXX_USE_C99_STDINT_TR1
@@ -631,6 +632,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
auto __locks = std::tie(__l1, __l2, __l3...);
__try
{ __try_lock_impl<0>::__do_try_lock(__locks, __idx); }
+ __catch(const __cxxabiv1::__forced_unwind&)
+ { __throw_exception_again; }
__catch(...)
{ }
return __idx;
diff --git a/libstdc++-v3/testsuite/30_threads/async/forced_unwind.cc b/libstdc++-v3/testsuite/30_threads/async/forced_unwind.cc
new file mode 100644
index 000..7b0a492
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/async/forced_unwind.cc
@@ -0,0 +1,45 @@
+// { dg-do run { target *-*-linux* *-*-gnu* } }
+// { dg-options " -std=gnu++11 -pthread" { target *-*-linux* *-*-gnu* } }
+// { dg-require-cstdint "" }
+// { dg-require-gthreads "" }
+// { dg-require-atomic-builtins "" }
+
+// Copyright (C) 2014 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
+//
Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call
Can I checkin this testcase fix? Thanks, Wei. On Tue, May 13, 2014 at 1:39 AM, Rainer Orth wrote: > Wei Mi writes: > >> Thanks for trying the testcase. rtl scanning will be slightly better >> than assembly scanning. So how about this one? > > This one works fine for me. > > Thanks. > Rainer > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch, mips] delete bit-rotten ADJUST_REG_ALLOC_ORDER definition
On 05/14/2014 12:49 PM, Richard Sandiford wrote: Jeff Law writes: On 05/13/14 14:11, Sandra Loosemore wrote: 2014-05-13 Catherine Moore Sandra Loosemore gcc/ * config/mips/mips.c (mips_order_regs_for_local_alloc): Delete. * config/mips/mips.h (ADJUST_REG_ALLOC_ORDER): Delete. * config/mips/mips-protos.h (mips_order_regs_for_local_alloc): Delete. OK for the trunk. Would it be OK to hold off until after the switch to LRA? That patch has been written and the MIPS parts approved, but we're waiting for some legal things to be sorted out and for a fixed version of the LRA EXTRA_MEMORY_CONSTRAINT patch. I just think it'd be better to tune this sort of thing once that's done, rather than tune it against reload. Yeah, sure -- I think we're all in agreement that the current code needs to go, but re-benchmarking would be a good thing. FWIW here's an old patch I had lying around. I wasn't happy with the results for CSiBE at the time but maybe it'd be worth looking at it again after LRA. E.g., we might want to put the non-MIPS16 call-clobbered GPRs ahead of the MIPS16 ones, so that when we're looking for any old GPR, we only pick a MIPS16 register if no others are free. FWIW, I think that just messing with REG_ALLOC_ORDER directly, as this patch does, is a better approach for tuning anyway than the ADJUST_REG_ALLOC_ORDER hook. -Sandra
Re: [RS6000] Fix PR61098, Poor code setting count register
On Wed, May 14, 2014 at 5:56 AM, Alan Modra wrote: >> I seem to remember problems in the past with late creation of TOC >> entries for constants causing problems, so it was easier to fall back >> to materializing all integer constants inline. I don't remember the >> PRs, but I think there were issues with creating a TOC if the late >> constant were the only TOC reference, or maybe the issue was buying a >> stack frame to materialize the TOC/GOT for a late constant. And >> maximum 5 instruction sequence is not really bad relative to a load >> from the TOC (even with medium model / data in TOC). There are a lot >> of trade-offs with respect to I$ expansion versus the load hitting in >> the L1 D$. > > Sure, but Steve will tell you that the 5 instruction sequence is both > slower due to all the dependent ops, and results in larger code+data > size. We definitely want to avoid it if possible, and pr67836 shows a > case taken from glibc math library code where there should be no > problem in using the TOC. I don't necessarily believe this is a win overall. If the constant reliably is in the L1 D$ (or maybe L2 D$) and accessed with a direct load (data in TOC or medium model), then yes. If it's farther away in the memory hierarchy, then it's not a win. I agree about the code expansion concern, which has its own secondary effects. If this is a constant in a tight loop, okay, but if it's a unique constant, it may not occur elsewhere in the code to be shared and may not be placed in the same cache line as other, recently accessed constants. This would push the load to L3 or farther. Also, remember that this same heuristic is used by AIX, which still defaults to small TOC model. So either the constant is in the TOC anchor constant pool, which hopefully will pre-load the anchor, or will be a constant in the TOC, possibly putting more pressure on TOC size and causing overflow. I am certain that there are anecdotal examples where it is a win for PPC64 Linux, but I would want more evidence that it's a general win. >> alpha_emit_set_long_const() always will materialize the constant and >> does not check for a maximum number of instructions. This is why it's >> comment says "fall back to straight forward decomposition". > No, that is wrong. alpha_emit_set_const does *not* always try to > materialize the constant inline. It does so for constants that need > more than three instructions only when TARGET_BUILD_CONSTANTS. I said that alpha_emit_set_long_const() always materializes the constant, but, as you say, it is not always called. alpha_emit_set_const() may fail if it requires too many instructions or the search depth is too deep. You seem to be referring to some of the logic in alpha_split_const_mov() as well. Again, this definitely is worth exploring. And I am confident that there are cases where loading the constant from memory is a win. I just don't have a good instinct if it is a win most of the time for a broad range of real-world applications. One optimization opportunity in GLIBC is not a general heuristic. I don't think that we know a lot about the context of the use of the constant to apply a finer-grained policy. I think the original code tried to put the constant in memory if it appeared before reload, when everything could be calculated correctly for prologue and materializing the TOC, but tried to materialze any constants that appeared during reload using splitters. That can avoid some of the problem corner cases. The code needs to handle PPC32 PPC64 eABI AIX Thanks, David
Re: [patch] fix impliedness of -Wunused-parameter depending on -Wexta option ordering
On Wed, 14 May 2014, Manuel López-Ibáñez wrote: > Am I missing something? No, that seems sufficient (together with the observation that the target handlers remain called after the others, so while there may be such bugs involving them those bugs are irrelevant to this patch). The patch is OK for mainline. -- Joseph S. Myers jos...@codesourcery.com
[patch, nios2] unbreak nios2 build
I've committed this patch to trunk to fix a cut-and-paste error in the Nios II backend that we've known about for a while, but we lost track of getting it fixed. Now mainline nios2 builds have started to fail because recent changes to rtl innards have added some extra error-checking that was not there before; previously the failure mode was to quietly generate long conditional branches everywhere instead of an ICE. -Sandra 2014-05-14 Sandra Loosemore gcc/ * config/nios2/nios2.md (nios2_cbranch): Fix paste-o in length attribute computation. Index: gcc/config/nios2/nios2.md === --- gcc/config/nios2/nios2.md (revision 210403) +++ gcc/config/nios2/nios2.md (working copy) @@ -877,8 +877,8 @@ [(set_attr "type" "control") (set (attr "length") (if_then_else - (and (ge (minus (match_dup 1) (pc)) (const_int -32768)) - (le (minus (match_dup 1) (pc)) (const_int 32764))) + (and (ge (minus (match_dup 3) (pc)) (const_int -32768)) + (le (minus (match_dup 3) (pc)) (const_int 32764))) (const_int 4) (const_int 8)))]) ;; Floating point comparisons
[patch] PR debug/61013: Change -g so that it will override -g1 but not -g3
This patch partially reverts a change in how a bare -g option was parsed
in a previous commit. Originally, -g would set the debug level to 2
only if debug was off. The previous commit changed that so that -g
would set the debug level to 2 unconditionally. This patch changes
it so that -g sets the debug level to 2 if it was either off or at
level 1 before.
OK to commit?
-cary
2014-05-14 Cary Coutant
gcc/
PR debug/61013
* opts.c (common_handle_option): Don't special-case "-g".
(set_debug_level): Default to at least level 2 with "-g".
Index: gcc/opts.c
===
--- gcc/opts.c (revision 210437)
+++ gcc/opts.c (working copy)
@@ -1814,13 +1814,8 @@ common_handle_option (struct gcc_options
break;
case OPT_g:
- /* -g by itself should force -g2. */
- if (*arg == '\0')
- set_debug_level (NO_DEBUG, DEFAULT_GDB_EXTENSIONS, "2", opts, opts_set,
-loc);
- else
- set_debug_level (NO_DEBUG, DEFAULT_GDB_EXTENSIONS, arg, opts, opts_set,
-loc);
+ set_debug_level (NO_DEBUG, DEFAULT_GDB_EXTENSIONS, arg, opts, opts_set,
+ loc);
break;
case OPT_gcoff:
@@ -2070,10 +2065,12 @@ set_debug_level (enum debug_info_type ty
opts_set->x_write_symbols = type;
}
- /* A debug flag without a level defaults to level 2. */
+ /* A debug flag without a level defaults to level 2.
+ If off or at level 1, set it to level 2, but if already
+ at level 3, don't lower it. */
if (*arg == '\0')
{
- if (!opts->x_debug_info_level)
+ if (opts->x_debug_info_level < DINFO_LEVEL_NORMAL)
opts->x_debug_info_level = DINFO_LEVEL_NORMAL;
}
else
New Chinese (simplified) PO file for 'gcc' (version 4.9-b20140202)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Chinese (simplified) team of translators. The file is available at: http://translationproject.org/latest/gcc/zh_CN.po (This file, 'gcc-4.9-b20140202.zh_CN.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [patch] PR debug/61013: Change -g so that it will override -g1 but not -g3
On 05/14/2014 02:36 PM, Cary Coutant wrote: > PR debug/61013 > * opts.c (common_handle_option): Don't special-case "-g". > (set_debug_level): Default to at least level 2 with "-g". Ok. Thanks, r~
Re: [patch] PR debug/61013: Change -g so that it will override -g1 but not -g3
>> PR debug/61013 >> * opts.c (common_handle_option): Don't special-case "-g". >> (set_debug_level): Default to at least level 2 with "-g". > > Ok. Thanks, Forgot to ask -- OK to backport to the 4.9 branch? -cary
Re: [patch] PR debug/61013: Change -g so that it will override -g1 but not -g3
On 05/14/2014 02:47 PM, Cary Coutant wrote: >>> PR debug/61013 >>> * opts.c (common_handle_option): Don't special-case "-g". >>> (set_debug_level): Default to at least level 2 with "-g". >> >> Ok. Thanks, > > Forgot to ask -- OK to backport to the 4.9 branch? Yes please. r~
[PATCH, libgfortran] Add overflow check to xmalloc
Hi, a common malloc() pattern is "malloc(num_foo * sizeof(foo_t)", that is, create space for an array of type foo_t with num_foo elements. There is a slight danger here in that the multiplication can overflow and wrap around, and then the caller thinks it has a larger array than what malloc has actually created. The attached patch changes the libgfortran xmalloc() function to have an API similar to calloc() with two arguments, and the implementation checks for wraparound. (There are cases in libgfortran where space is allocated for temporary multidimensional arrays. It might be useful to check for overflow when multiplying the extent of each dimension, similar to how is done inline for the ALLOCATE statement in addition to checking the final multiplication with the size of each element as this patch accomplishes.) Tested on x86_64-unknown-linux-gnu, Ok for trunk? 2014-05-15 Janne Blomqvist * libgfortran.h (xmalloc): Add size argument similar to calloc. * runtime/memory.c (xmalloc): Check for overflow. (xcalloc): Check for nonzero separately instead of multiplying. * generated/*.c: Regenerated. * intrinsics/cshift0.c (cshift0): Call updated xmalloc. * intrinsics/ctime.c (fdate): Likewise. (fdate_sub): Likewise. (ctime): Likewise. (ctime_sub): Likewise. * intrinsics/date_and_time.c (secnds): Likewise. * intrinsics/eoshift0.c (eoshift0): Likewise. * intrinsics/eoshift2.c (eoshift2): Likewise. * intrinsics/getcwd.c (getcwd): Likewise. * intrinsics/getlog.c (getlog): Likewise. * intrinsics/pack_generic.c (pack_internal): Likewise. (pack_s_internal): Likewise. * intrinsics/reshape_generic.c (reshape_internal): Likewise. * intrinsics/spread_generic.c (spread_internal): Likewise. (spread_internal_scalar): Likewise. * intrinsics/string_intrinsics_inc.c (string_trim): Likewise. (string_minmax): Likewise. * intrinsics/transpose_generic.c (transpose_internal): Likewise. * intrinsics/unpack_generic.c (unpack_internal): Likewise. * io/fbuf.c (fbuf_init): Likewise. * io/format.c (get_fnode): Likewise. (parse_format): Likewise. * io/intrinsics.c (ttynam): Likewise. * io/list_read.c (nml_touch_nodes): Likewise. (nml_read_obj): Likewise. * io/open.c (new_unit): Likewise. * io/transfer.c (st_set_nml_var): Likewise. * io/unit.c (get_internal_unit): Likewise. (init_units): Likewise. (filename_from_unit): Likewise. * io/unix.c (buf_init): Likewise. (tempfile_open): Likewise. * io/write.c (nml_write_obj): Likewise. * m4/bessel.m4 (bessel_jn_r'rtype_kind`): Likewise. (besse_yn_r'rtype_kind`): Likewise. * m4/cshift1.m4 (cshift1): Likewise. * m4/eoshift1.m4 (eoshift1): Likewise. * m4/eoshift3.m4 (eoshift3): Likewise. * m4/iforeach.m4: Likewise. * m4/ifunction.m4: Likewise. * m4/ifunction_logical.m4 (name`'rtype_qual`_'atype_code): Likewise. * m4/in_pack.m4 (internal_pack_'rtype_ccode`): Likewise. * m4/matmul.m4 (matmul_'rtype_code`): Likewise. * m4/matmull.m4 (matmul_'rtype_code`): Likewise. * m4/pack.m4 (pack_'rtype_code`): Likewise. * m4/reshape.m4 (reshape_'rtype_ccode`): Likewise. * m4/shape.m4 (shape_'rtype_kind`): Likewise. * m4/spread.m4 (spread_'rtype_code`): Likewise. (spread_scalar_'rtype_code`): Likewise. * m4/transpose.m4 (transpose_'rtype_code`): Likewise. * m4/unpack.m4 (unpack0_'rtype_code`): Likewise. (unpack1_'rtype_code`): Likewise. * runtime/convert_char.c (convert_char1_to_char4): Likewise. (convert_char4_to_char1): Likewise. * runtime/environ.c (init_unformatted): Likewise. * runtime/in_pack_generic.c (internal_pack): Likewise. -- Janne Blomqvist xmalloc.diff.gz Description: GNU Zip compressed data
Re: [SPARC] Implement workaround for new FPU erratum on LEON3
> 2014-03-20 Eric Botcazou > > * config/sparc/sparc.c (sparc_do_work_around_errata): Implement work > around for store forwarding issue in the FPU on the UT699. > * config/sparc/sparc.md (in_branch_delay): Return false for single FP > loads and operations if -mfix-ut699 is specified. > (divtf3_hq): Tweak attribute. > (sqrttf2_hq): Likewise. Daniel privately pointed out that there are a few holes in the implementation because of the irregularity of the instruction classification in the back-end. The attached patch is aimed at addressing them: it changes the fptype of floatsisf2 and fix_truncsfsi2 to "single" (this was an old bug), adds a new fptype_ut699 attribute for truncdfsf2 and fix_truncdfsi2 and rewrites the splitters of negtf2/negdf2 and abstf2/absdf2 to make them always split. Tested on LEON & SPARC/Solaris, applied on the mainline, 4.9 and 4.8 branches. 2014-05-14 Eric Botcazou * config/sparc/sparc-protos.h (sparc_absnegfloat_split_legitimate): Delete. * config/sparc/sparc.c (sparc_absnegfloat_split_legitimate): Likewise. * config/sparc/sparc.md (fptype_ut699): New attribute. (in_branch_delay): Return false if -mfix-ut699 is specified and fptype_ut699 is set to single. (truncdfsf2): Add fptype_ut699 attribute. (fix_truncdfsi2): Likewise. (floatsisf2): Change fptype attribute. (fix_truncsfsi2): Likewise. (negtf2_notv9): Delete. (negtf2_v9): Likewise. (negtf2_hq): New instruction. (negtf2): New instruction and splitter. (negdf2_notv9): Rewrite. (abstf2_notv9): Delete. (abstf2_hq_v9): Likewise. (abstf2_v9): Likewise. (abstf2_hq): New instruction. (abstf2): New instruction and splitter. (absdf2_notv9): Rewrite. -- Eric BotcazouIndex: config/sparc/sparc.md === --- config/sparc/sparc.md (revision 210410) +++ config/sparc/sparc.md (working copy) @@ -424,6 +424,10 @@ (define_attr "length" "" (define_attr "fptype" "single,double" (const_string "single")) +;; FP precision specific to the UT699. +(define_attr "fptype_ut699" "none,single" + (const_string "none")) + ;; UltraSPARC-III integer load type. (define_attr "us3load_type" "2cycle,3cycle" (const_string "2cycle")) @@ -464,7 +468,8 @@ (define_attr "in_branch_delay" "false,tr (const_string "false") (and (eq_attr "fix_ut699" "true") (and (eq_attr "type" "fpload,fp,fpmove,fpmul,fpdivs,fpsqrts") - (eq_attr "fptype" "single"))) + (ior (eq_attr "fptype" "single") + (eq_attr "fptype_ut699" "single" (const_string "false") (eq_attr "length" "1") (const_string "true") @@ -3455,7 +3460,8 @@ (define_insn "truncdfsf2" "TARGET_FPU" "fdtos\t%1, %0" [(set_attr "type" "fp") - (set_attr "fptype" "double")]) + (set_attr "fptype" "double") + (set_attr "fptype_ut699" "single")]) (define_expand "trunctfsf2" [(set (match_operand:SF 0 "register_operand" "") @@ -3496,7 +3502,7 @@ (define_insn "floatsisf2" "TARGET_FPU" "fitos\t%1, %0" [(set_attr "type" "fp") - (set_attr "fptype" "double")]) + (set_attr "fptype" "single")]) (define_insn "floatsidf2" [(set (match_operand:DF 0 "register_operand" "=e") @@ -3583,7 +3589,7 @@ (define_insn "fix_truncsfsi2" "TARGET_FPU" "fstoi\t%1, %0" [(set_attr "type" "fp") - (set_attr "fptype" "double")]) + (set_attr "fptype" "single")]) (define_insn "fix_truncdfsi2" [(set (match_operand:SI 0 "register_operand" "=f") @@ -3591,7 +3597,8 @@ (define_insn "fix_truncdfsi2" "TARGET_FPU" "fdtoi\t%1, %0" [(set_attr "type" "fp") - (set_attr "fptype" "double")]) + (set_attr "fptype" "double") + (set_attr "fptype_ut699" "single")]) (define_expand "fix_trunctfsi2" [(set (match_operand:SI 0 "register_operand" "") @@ -5554,53 +5561,52 @@ (define_insn "divsf3" [(set_attr "type" "fpdivs")]) (define_expand "negtf2" - [(set (match_operand:TF 0 "register_operand" "=e,e") - (neg:TF (match_operand:TF 1 "register_operand" "0,e")))] + [(set (match_operand:TF 0 "register_operand" "") + (neg:TF (match_operand:TF 1 "register_operand" "")))] "TARGET_FPU" "") -(define_insn_and_split "*negtf2_notv9" - [(set (match_operand:TF 0 "register_operand" "=e,e") - (neg:TF (match_operand:TF 1 "register_operand" "0,e")))] - ; We don't use quad float insns here so we don't need TARGET_HARD_QUAD. - "TARGET_FPU - && ! TARGET_V9" - "@ - fnegs\t%0, %0 - #" - "&& reload_completed - && sparc_absnegfloat_split_legitimate (operands[0], operands[1])" - [(set (match_dup 2) (neg:SF (match_dup 3))) - (set (match_dup 4) (match_dup 5)) - (set (match_dup 6) (match_dup 7))] - "operands[2] = gen_rtx_raw_REG (SFmode, REGNO (operands[0])); - operands[3] = gen_rtx_raw_REG (SFmode, REGNO (operands[1])); - operands[4] = gen_rtx_raw_REG (SFmode, REGNO (oper
[PATCH aarch64] aarch64-linux: output .note.GNU-stack
The toolchain would like PT_GNU_STACK in our objects for all architectures to make it explicit whether we are requesting an executable stack or not. 2014-05-14 Kyle McMartin * config/aarch64/aarch64-linux.h (TARGET_ASM_FILE_END): define to file_end_indicate_exec_stack for .note.GNU-stack emission. --- a/gcc/config/aarch64/aarch64-linux.h +++ b/gcc/config/aarch64/aarch64-linux.h @@ -44,4 +44,6 @@ } \ while (0) +#define TARGET_ASM_FILE_END file_end_indicate_exec_stack + #endif /* GCC_AARCH64_LINUX_H */
[patch] Simplify std::tuple helpers and fix C++14 bug.
I found a bug in the new std::get(tuple&&) function
where it didn't compile when trying to access reference member.
The rest of this patch simplifies the code in by:
- removing the redundant __add_ref etc. helpers.
- defining a __tuple_element_t alias template.
- removing duplication in the tuple_size traits.
- using static_assert in the relational operators.
Tested x86_64-linux, committed to trunk.
commit 61f1eec0e42041d550f3eee1626950f7861255e6
Author: Jonathan Wakely
Date: Tue May 13 13:53:23 2014 +0100
* include/std/tuple (__add_c_ref, __add_ref, __add_r_ref): Remove.
(__tuple_element_t): Define.
(tuple_element): Use __tuple_element_t.
(__cv_tuple_size): Define.
(tuple_size): Use __cv_tuple_size.
(get, __get_helper, __get_helper2): Remove uses of __add_ref etc.
(get<_Tp>(tuple<_Types...>&&)): Use forward instead of move.
(__tuple_compare): Remove size check, re-order parameters.
(operator==, operator<): Use static_assert to check requirements.
* include/std/functional (__volget): use __tuple_element_t.
* testsuite/20_util/tuple/element_access/get_by_type.cc: Test rvalues.
* testsuite/20_util/uses_allocator/cons_neg.cc: Adjust dg-error.
diff --git a/libstdc++-v3/include/std/functional b/libstdc++-v3/include/std/functional
index 2bc3d8d..e677c24 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -1230,14 +1230,14 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
template
inline auto
__volget(volatile tuple<_Tp...>& __tuple)
--> typename tuple_element<_Ind, tuple<_Tp...>>::type volatile&
+-> __tuple_element_t<_Ind, tuple<_Tp...>> volatile&
{ return std::get<_Ind>(const_cast&>(__tuple)); }
// std::get for const-volatile-qualified tuples
template
inline auto
__volget(const volatile tuple<_Tp...>& __tuple)
--> typename tuple_element<_Ind, tuple<_Tp...>>::type const volatile&
+-> __tuple_element_t<_Ind, tuple<_Tp...>> const volatile&
{ return std::get<_Ind>(const_cast&>(__tuple)); }
/// Type of the function object returned from bind().
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 5e8766c..95c197d 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -48,33 +48,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @{
*/
- // Adds a const reference to a non-reference type.
- template
-struct __add_c_ref
-{ typedef const _Tp& type; };
-
- template
-struct __add_c_ref<_Tp&>
-{ typedef _Tp& type; };
-
- // Adds a reference to a non-reference type.
- template
-struct __add_ref
-{ typedef _Tp& type; };
-
- template
-struct __add_ref<_Tp&>
-{ typedef _Tp& type; };
-
- // Adds an rvalue reference to a non-reference type.
- template
-struct __add_r_ref
-{ typedef _Tp&& type; };
-
- template
-struct __add_r_ref<_Tp&>
-{ typedef _Tp& type; };
-
template
struct _Head_base;
@@ -689,25 +662,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
typedef _Head type;
};
+ // Duplicate of C++14's tuple_element_t for internal use in C++11 mode
+ template
+using __tuple_element_t = typename tuple_element<__i, _Tp>::type;
+
template
struct tuple_element<__i, const _Tp>
{
- typedef typename
- add_const::type>::type type;
+ typedef typename add_const<__tuple_element_t<__i, _Tp>>::type type;
};
template
struct tuple_element<__i, volatile _Tp>
{
- typedef typename
- add_volatile::type>::type type;
+ typedef typename add_volatile<__tuple_element_t<__i, _Tp>>::type type;
};
template
struct tuple_element<__i, const volatile _Tp>
{
- typedef typename
- add_cv::type>::type type;
+ typedef typename add_cv<__tuple_element_t<__i, _Tp>>::type type;
};
#if __cplusplus > 201103L
@@ -719,23 +693,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
struct tuple_size;
+ template>
+using __cv_tuple_size = integral_constant<
+ typename remove_cv::type, _Ts::value>;
+
template
-struct tuple_size
-: public integral_constant<
- typename remove_cv::value)>::type,
- tuple_size<_Tp>::value> { };
+struct tuple_size : __cv_tuple_size<_Tp> { };
template
-struct tuple_size
-: public integral_constant<
- typename remove_cv::value)>::type,
- tuple_size<_Tp>::value> { };
+struct tuple_size : __cv_tuple_size<_Tp> { };
template
-struct tuple_size
-: public integral_constant<
- typename remove_cv::value)>::type,
- tuple_size<_Tp>::value> { };
+struct tuple_size : __cv_tuple_size<_Tp> { };
/// class tuple_size
template
@@ -743,98 +712,93 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
: public integral_constant { };
template
-constexpr typename __add_ref<_Head>::type
+constexpr _Head&
__get_helper(_Tuple_im
[msp430] add __delay_cycles() builtin
Adds a new __delay_cycles() builtin to the msp430 backend. Committed.
* config/msp430/msp430.c (msp430_builtin): Add
MSP430_BUILTIN_DELAY_CYCLES.
(msp430_init_builtins): Register void __delay_cycles(long long).
(msp430_builtin_decl): Add it.
(cg_magic_constant): New.
(msp430_expand_delay_cycles): New.
(msp430_expand_builtin): Call it.
(msp430_print_operand_raw): Change integer printing from "int" to
HOST_WIDE_INT.
* config/msp430/msp430.md (define_constants): Add delay_cycles tags.
(delay_cycles_start): New.
(delay_cycles_end): New.
(delay_cycles_32): New.
(delay_cycles_32x): New.
(delay_cycles_16): New.
(delay_cycles_16x): New.
(delay_cycles_2): New.
(delay_cycles_1): New.
* doc/extend.texi: Document __delay_cycles().
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 210437)
+++ gcc/doc/extend.texi (working copy)
@@ -13191,12 +13191,21 @@ once the handler returns.
@item __bis_SR_register_on_exit (int @var{mask})
This sets the indicated bits in the saved copy of the status register
currently residing on the stack. This only works inside interrupt
handlers and the changes to the status register will only take affect
once the handler returns.
+
+@item __delay_cycles (long long @var{cycles})
+This inserts an instruction sequence that takes exactly @var{cycles}
+cycles (between 0 and about 17E9) to complete. The inserted sequence
+may use jumps, loops, or no-ops, and does not interfere with any other
+instructions. Note that @var{cycles} must be a compile-time constant
+integer - that is, you must pass a number, not a variable that may be
+optimized to a constant later. The number of cycles delayed by this
+builtin is exact.
@end table
@node NDS32 Built-in Functions
@subsection NDS32 Built-in Functions
These built-in functions are available for the NDS32 target:
Index: gcc/config/msp430/msp430.md
===
--- gcc/config/msp430/msp430.md (revision 210437)
+++ gcc/config/msp430/msp430.md (working copy)
@@ -44,12 +44,21 @@
UNS_PUSH_INTR
UNS_POP_INTR
UNS_BIC_SR
UNS_BIS_SR
UNS_REFSYM_NEED_EXIT
+
+ UNS_DELAY_32
+ UNS_DELAY_32X
+ UNS_DELAY_16
+ UNS_DELAY_16X
+ UNS_DELAY_2
+ UNS_DELAY_1
+ UNS_DELAY_START
+ UNS_DELAY_END
])
(include "predicates.md")
(include "constraints.md")
(define_mode_iterator QHI [QI HI PSI])
@@ -1314,12 +1323,96 @@
return \"MOV.W\t%1, %0 { SUB.W\t#0, %0 { AND.W\t%2, %0\";
else
return \"SUB.W\t#0, %0 { AND.W\t%2, %0\";
"
)
+(define_insn "delay_cycles_start"
+ [(unspec_volatile [(match_operand 0 "immediate_operand" "i")]
+ UNS_DELAY_START)]
+ ""
+ "; Begin %J0 cycle delay"
+ )
+
+(define_insn "delay_cycles_end"
+ [(unspec_volatile [(match_operand 0 "immediate_operand" "i")]
+ UNS_DELAY_END)]
+ ""
+ "; End %J0 cycle delay"
+ )
+
+(define_insn "delay_cycles_32"
+ [(unspec_volatile [(match_operand 0 "immediate_operand" "i")
+(match_operand 1 "immediate_operand" "i")
+] UNS_DELAY_32)]
+ ""
+ "PUSHr13
+ PUSHr14
+ MOV.W %A0, r13
+ MOV.W %B0, r14
+1: SUB.W #1, r13
+ SUBC.W #0, r14
+ JNE 1b
+ TST.W r13
+ JNE 1b
+ POP r14
+ POP r13"
+ )
+
+(define_insn "delay_cycles_32x"
+ [(unspec_volatile [(match_operand 0 "immediate_operand" "i")
+(match_operand 1 "immediate_operand" "i")
+] UNS_DELAY_32X)]
+ ""
+ "PUSHM.A #2,r13
+ MOV.W %A0, r13
+ MOV.W %B0, r14
+1: SUB.W #1, r13
+ SUBC.W #0, r14
+ JNE 1b
+ TST.W r13
+ JNE 1b
+ POPM.A #2,r13"
+ )
+
+(define_insn "delay_cycles_16"
+ [(unspec_volatile [(match_operand 0 "immediate_operand" "i")
+(match_operand 1 "immediate_operand" "i")
+] UNS_DELAY_16)]
+ ""
+ "PUSHr13
+ MOV.W %0, r13
+1: SUB.W #1, r13
+ JNE 1b
+ POP r13"
+ )
+
+(define_insn "delay_cycles_16x"
+ [(unspec_volatile [(match_operand 0 "immediate_operand" "i")
+(match_operand 1 "immediate_operand" "i")
+] UNS_DELAY_16X)]
+ ""
+ "PUSHM.A #1,r13
+ MOV.W %0, r13
+1: SUB.W #1, r13
+ JNE 1b
+ POPM.A #1,r13"
+ )
+
+(define_insn "delay_cycles_2"
+ [(unspec_volatile [(const_int 0) ] UNS_DELAY_2)]
+ ""
+ "JMP .+2"
+ )
+
+(define_insn "delay_cycles_1"
+ [(unspec_volatile [(const_int 0) ] UNS_DELAY_1)]
+ ""
+ "NOP"
+ )
+
(define_insn "mulhisi3"
[(set (match_operand:SI 0 "register_operand" "=r")
(mult:SI (sign_extend:SI (match_operand:HI 1 "regis
[COMMITTED] Add myself as maintainer for libitm.
On Mon, 2014-03-03 at 09:24 -0800, Richard Henderson wrote: > On 03/03/2014 04:48 AM, Torvald Riegel wrote: > > Should I add myself as maintainer for libitm? > > Yes. Committed as r210448. commit 4da9024845f11053b56aa1318469029b044ff6d1 Author: Torvald Riegel Date: Thu May 15 00:31:03 2014 +0200 Add myself as maintainer for libitm. diff --git a/MAINTAINERS b/MAINTAINERS index ae3d330..8d094be 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -174,6 +174,7 @@ libgomp Richard Henderson r...@redhat.com libgomp Jakub Jelinek ja...@redhat.com libiberty DJ Delorie d...@redhat.com libiberty Ian Lance Taylor i...@airs.com +libitm Torvald Riegel trie...@redhat.com libffi testsuite Andreas Tobler andre...@gcc.gnu.org libobjc Nicola Pero nicola.p...@meta-innovation.com libobjc Andrew Pinski pins...@gmail.com
Re: [Google/4-8] Support for user-guided feedback-directed library optimization
Hi Andi, I'll work on putting together some good documentation before sending this and follow-on support to trunk. As David mentions, the plan for the subsequent patch to add the hooks that enable users to trigger gcc's value profiling on particular variables. This first patch simply allows users to define their own profiling routines, that automatically only get compiled in on the profile-gen build and have the results automatically applied to the profile-use compile via the gcda file. Thanks, Teresa On Sat, May 10, 2014 at 3:44 PM, Xinliang David Li wrote: > User directed value profiling will also be supported but not in this patch. > > David > > On May 10, 2014 2:59 PM, "Andi Kleen" wrote: >> >> On Fri, May 09, 2014 at 08:11:40PM -0700, Teresa Johnson wrote: >> > Thanks for catching that, I will fix it. >> >> BTW I first misunderstood the goal of you patch. >> >> (probably because there is no documentation ... something that should >> also be fixed) >> >> I originally thought it was a way to let user code use the value profiling >> libgcov functions to profile arbitary values, and then later use the >> most common value for some optimization. >> >> But instead it seems to be only an (somewhat over complicated) IO >> mechanism to let user programs write arbitrary values to the gcov file and >> pass it back. >> >> I think I would find the first more useful. >> >> -Andi >> > -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
[PATCH, libgfortran] PR 61187 Handle closed std{in,out,err}
Hello,
libgfortran was happily assuming that STD{IN,OUT,ERR}_FILENO were open
and no error checking was performed on the fstat() call when building
the unit structure for those units. This caused valgrind to complain
when running under MPICH2, which closes stdin for all ranks but rank 0
before launching the executable.
The attached patch fixes this by checking the return value of fstat()
and sets the stored file descriptor to -1 if it was invalid when
creating a new unit. This will generate an error when trying to do IO
from that unit, and fixes the valgrind errors.
Tested on x86_64-unknown-linux-gnu, Ok for trunk/4.9/4.8/4.7?
2014-05-15 Janne Blomqvist
PR libfortran/61187
* io/unix.c (raw_close): Check if s->fd is -1.
(fd_to_stream): Check return value of fstat(), handle error.
--
Janne Blomqvist
diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c
index 34c2d0c..76ed84e 100644
--- a/libgfortran/io/unix.c
+++ b/libgfortran/io/unix.c
@@ -412,7 +412,9 @@ raw_close (unix_stream * s)
{
int retval;
- if (s->fd != STDOUT_FILENO
+ if (s->fd == -1)
+retval = -1;
+ else if (s->fd != STDOUT_FILENO
&& s->fd != STDERR_FILENO
&& s->fd != STDIN_FILENO)
retval = close (s->fd);
@@ -1003,7 +1005,15 @@ fd_to_stream (int fd, bool unformatted)
/* Get the current length of the file. */
- fstat (fd, &statbuf);
+ if (fstat (fd, &statbuf) == -1)
+{
+ s->st_dev = s->st_ino = -1;
+ s->file_length = 0;
+ if (errno == EBADF)
+ s->fd = -1;
+ raw_init (s);
+ return (stream *) s;
+}
s->st_dev = statbuf.st_dev;
s->st_ino = statbuf.st_ino;
[RFC][AArch64] Remove CORE_REGS form reg_class
Hi All,
AAarch64 back-end defines GENERAL_REGS and CORE_REGS with the same set
of register. Is there any reason why we need this?
target hooks like aarch64_register_move_cost doesnt handle CORE_REGS.
In addition, IRA cost calculation also has logics like make common class
biggest of best and alternate; this might get confused with this.
Attached RFC patch removes it. regression tested for
aarch64-none-linux-gnu on qemu-aarch64 with now new regression. Is this OK ?
Thanks,
Kugan
gcc/
2014-05-14 Kugan Vivekanandarajah
* config/aarch64/aarch64.c (aarch64_regno_regclass) : Change CORE_REGS
to GENERAL_REGS.
(aarch64_secondary_reload) : LikeWise.
(aarch64_class_max_nregs) : Remove CORE_REGS.
* config/aarch64/aarch64.h (enum reg_class) : Remove CORE_REGS.
(REG_CLASS_NAMES) : Likewise.
(REG_CLASS_CONTENTS) : LikeWise.
(INDEX_REG_CLASS) : Change CORE_REGS to GENERAL_REGS.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index a3147ee..eee36ba 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -3951,7 +3951,7 @@ enum reg_class
aarch64_regno_regclass (unsigned regno)
{
if (GP_REGNUM_P (regno))
-return CORE_REGS;
+return GENERAL_REGS;
if (regno == SP_REGNUM)
return STACK_REG;
@@ -4102,12 +4102,12 @@ aarch64_secondary_reload (bool in_p ATTRIBUTE_UNUSED,
rtx x,
/* A TFmode or TImode memory access should be handled via an FP_REGS
because AArch64 has richer addressing modes for LDR/STR instructions
than LDP/STP instructions. */
- if (!TARGET_GENERAL_REGS_ONLY && rclass == CORE_REGS
+ if (!TARGET_GENERAL_REGS_ONLY && rclass == GENERAL_REGS
&& GET_MODE_SIZE (mode) == 16 && MEM_P (x))
return FP_REGS;
if (rclass == FP_REGS && (mode == TImode || mode == TFmode) && CONSTANT_P(x))
- return CORE_REGS;
+ return GENERAL_REGS;
return NO_REGS;
}
@@ -4239,7 +4239,6 @@ aarch64_class_max_nregs (reg_class_t regclass, enum
machine_mode mode)
{
switch (regclass)
{
-case CORE_REGS:
case POINTER_REGS:
case GENERAL_REGS:
case ALL_REGS:
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 7962aa4..3455ecc 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -409,7 +409,6 @@ extern unsigned long aarch64_tune_flags;
enum reg_class
{
NO_REGS,
- CORE_REGS,
GENERAL_REGS,
STACK_REG,
POINTER_REGS,
@@ -424,7 +423,6 @@ enum reg_class
#define REG_CLASS_NAMES\
{ \
"NO_REGS", \
- "CORE_REGS", \
"GENERAL_REGS", \
"STACK_REG", \
"POINTER_REGS", \
@@ -436,7 +434,6 @@ enum reg_class
#define REG_CLASS_CONTENTS \
{ \
{ 0x, 0x, 0x }, /* NO_REGS */ \
- { 0x7fff, 0x, 0x0003 }, /* CORE_REGS */ \
{ 0x7fff, 0x, 0x0003 }, /* GENERAL_REGS */ \
{ 0x8000, 0x, 0x }, /* STACK_REG */ \
{ 0x, 0x, 0x0003 }, /* POINTER_REGS */ \
@@ -447,7 +444,7 @@ enum reg_class
#define REGNO_REG_CLASS(REGNO) aarch64_regno_regclass (REGNO)
-#define INDEX_REG_CLASSCORE_REGS
+#define INDEX_REG_CLASSGENERAL_REGS
#define BASE_REG_CLASS POINTER_REGS
/* Register pairs used to eliminate unneeded registers that point into
[PATCH 1/1][ira-costs] grammar fix of comments
Fix grammar error for comments above process_bb_node_for_hard_reg_moves Signed-off-by: Zhouyi Zhou --- gcc/ira-costs.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gcc/ira-costs.c b/gcc/ira-costs.c index 648806b..fbfb070 100644 --- a/gcc/ira-costs.c +++ b/gcc/ira-costs.c @@ -1855,7 +1855,7 @@ find_costs_and_classes (FILE *dump_file) /* Process moves involving hard regs to modify allocno hard register costs. We can do this only after determining allocno class. If a - hard register forms a register class, than moves with the hard + hard register forms a register class, then moves with the hard register are already taken into account in class costs for the allocno. */ static void -- 1.7.1
Re: SYMBOL_REF_FLAGS
Richard, Your SYMBOL_REF_FLAGS RTX patches broke bootstrap on AIX. - David /nasfarm/edelsohn/src/src/libgcc/libgcc2.c: In function '__eprintf': /nasfarm/edelsohn/src/src/libgcc/libgcc2.c:2126:1: internal compiler error: RTL flag check: SYMBOL_REF_FLAGS used with unexpected rtx code 'const' in rs6000_delegitimize_address, at config/rs6000/rs6000.c:6863
[DOC Patch] Incorrect @xref in #pragma visibility
I have a release on file with the FSF, but don't have SVN write access.
Problem description:
The existing docs have an @xref in the middle of a sentence, resulting
in weird capitalization and sentence structure:
"This pragma allows the user to set the visibility for multiple
declarations without having to give each a visibility attribute See
Function Attributes, for more information about visibility and the
attribute syntax."
ChangeLog:
2014-05-14 David Wohlferd
* doc/extend.texi: (Visibility Pragmas) Fix misplaced @xref
dw
Index: extend.texi
===
--- extend.texi (revision 210349)
+++ extend.texi (working copy)
@@ -17075,8 +17075,7 @@
This pragma allows the user to set the visibility for multiple
declarations without having to give each a visibility attribute
-@xref{Function Attributes}, for more information about visibility and
-the attribute syntax.
+(@pxref{Function Attributes}).
In C++, @samp{#pragma GCC visibility} affects only namespace-scope
declarations. Class members and template specializations are not
