Re: [PATCH] Handle OPTIMIZATION_NODE in LTO
On Thu, 5 Jan 2012, Steven Bosscher wrote:
> On Thu, Jan 5, 2012 at 4:01 PM, Richard Guenther wrote:
> > Index: gcc/tree-streamer-out.c
> > ===
> > --- gcc/tree-streamer-out.c (revision 182908)
> > +++ gcc/tree-streamer-out.c (working copy)
> > @@ -767,6 +767,27 @@ write_ts_target_option (struct output_bl
> > streamer_write_bitpack (&bp);
> > }
> >
> > +/* Write a TS_OPTIMIZATION tree in EXPR to OB. */
> > +
> > +static void
> > +write_ts_optimization (struct output_block *ob, tree expr)
> > +{
> > + struct cl_optimization *t = TREE_OPTIMIZATION (expr);
> > + struct bitpack_d bp;
> > + unsigned i, len;
> > +
> > + /* The cl_optimizaation is generated by the options
>
> s/cl_optimizaation/cl_optimization/ ;-)
Fixed.
Thanks,
Richard.
[patch] should not define bool, true or false as macros for C++
GCC's implementation of is not valid for C++11 because
[support.runtime] p8 says "The header and the header
shall not define macros named bool, true, or false."
This patch adds a libstdc++ test for that requirement and adjusts
stdbool.h to meet it. I've left _Bool defined in C++ as a GNU
extension.
It's conceivable someone is relying on these macros being defined in
C++, in which case we could only define them when __cplusplus <
201103L, but IMHO it's better to not define them at all.
Tested x86_64-linux, OK for trunk?
gcc/
* ginclude/stdbool.h (true, false, bool): Do not define for C++.
libstdc++/
* testsuite/18_support/headers/cstdbool/macros.cc: New.
--- a/gcc/ginclude/stdbool.h
+++ b/gcc/ginclude/stdbool.h
@@ -1,4 +1,4 @@
-/* Copyright (C) 1998, 1999, 2000, 2009 Free Software Foundation, Inc.
+/* Copyright (C) 1998, 1999, 2000, 2009, 2012 Free Software Foundation, Inc.
This file is part of GCC.
@@ -36,11 +36,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#else /* __cplusplus */
-/* Supporting in C++ is a GCC extension. */
+/* Supporting _Bool in C++ is a GCC extension. */
#define _Bool bool
-#define bool bool
-#define false false
-#define true true
#endif /* __cplusplus */
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/headers/cstdbool/macros.cc
@@ -0,0 +1,38 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++11" }
+
+// Copyright (C) 2012 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, ARM] Fix stack red zone bug (PR38644) for GCC 4.6
What is missing to get this ported back to the GCC 4.6 branch? Btw. what is this ARM/embedded-4_6-branch for a branch? It seems to be more actively maintained. On 12/21/2011 09:10 AM, Sebastian Huber wrote: Would someone mind committing this to the 4.6 branch. Thanks. The test suite results are only missing for the 4.4 and 4.5 branch. -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [PATCH]: Add static branch predict heuristic of comparing IV to loop_bound variable
Hello,
Attached is the updated version of the patch.
Passed the bootstrap and gcc testsuite.
Thanks,
Dehao
Index: gcc/testsuite/gcc.dg/predict-3.c
===
--- gcc/testsuite/gcc.dg/predict-3.c(revision 0)
+++ gcc/testsuite/gcc.dg/predict-3.c(revision 0)
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-profile_estimate" } */
+
+extern int global;
+
+int bar(int);
+
+void foo (int bound)
+{
+ int i, ret = 0;
+ for (i = 0; i <= bound; i++)
+{
+ if (i != bound)
+ global += bar (i);
+}
+}
+
+/* { dg-final { scan-tree-dump "loop iv compare heuristics"
"profile_estimate"} } */
+/* { dg-final { cleanup-tree-dump "profile_estimate" } } */
Index: gcc/testsuite/gcc.dg/predict-4.c
===
--- gcc/testsuite/gcc.dg/predict-4.c(revision 0)
+++ gcc/testsuite/gcc.dg/predict-4.c(revision 0)
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-profile_estimate" } */
+
+extern int global;
+
+int bar(int);
+
+void foo (int bound)
+{
+ int i, ret = 0;
+ for (i = 0; i < 10; i++)
+{
+ if (i < 5)
+ global += bar (i);
+}
+}
+
+/* { dg-final { scan-tree-dump "loop iv compare heuristics"
"profile_estimate"} } */
+/* { dg-final { cleanup-tree-dump "profile_estimate" } } */
Index: gcc/testsuite/gcc.dg/predict-1.c
===
--- gcc/testsuite/gcc.dg/predict-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/predict-1.c(revision 0)
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-profile_estimate" } */
+
+extern int global;
+
+int bar(int);
+
+void foo (int bound)
+{
+ int i, ret = 0;
+ for (i = 0; i < bound; i++)
+{
+ if (i > bound - 2)
+ global += bar (i);
+}
+}
+
+/* { dg-final { scan-tree-dump "loop iv compare heuristics"
"profile_estimate"} } */
+/* { dg-final { cleanup-tree-dump "profile_estimate" } } */
Index: gcc/testsuite/gcc.dg/predict-2.c
===
--- gcc/testsuite/gcc.dg/predict-2.c(revision 0)
+++ gcc/testsuite/gcc.dg/predict-2.c(revision 0)
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-profile_estimate" } */
+
+extern int global;
+
+int bar(int);
+
+void foo (int bound)
+{
+ int i, ret = 0;
+ for (i = 0; i < bound; i++)
+{
+ if (i > bound * bound )
+ global += bar (i);
+}
+}
+
+/* { dg-final { scan-tree-dump-not "loop iv compare heuristics"
"profile_estimate"} } */
+/* { dg-final { cleanup-tree-dump "profile_estimate" } } */
Index: gcc/predict.c
===
--- gcc/predict.c (revision 182738)
+++ gcc/predict.c (working copy)
@@ -946,6 +946,332 @@
}
}
+/* Check if T1 and T2 satisfy the IV_COMPARE condition.
+ Return the SSA_NAME if the condition satisfies, NULL otherwise.
+
+ T1 and T2 should be one of the following cases:
+ 1. T1 is SSA_NAME, T2 is NULL
+ 2. T1 is SSA_NAME, T2 is INTEGER_CST between [-4, 4]
+ 3. T2 is SSA_NAME, T1 is INTEGER_CST between [-4, 4] */
+
+static tree
+find_qualified_ssa_name (tree t1, tree t2)
+{
+ tree ret = NULL;
+ int value = 0;
+
+ if (!t1)
+return NULL;
+ else if (TREE_CODE (t1) == SSA_NAME)
+ret = t1;
+ else if (TREE_CODE (t1) == INTEGER_CST && host_integerp (t1, 0))
+value = tree_low_cst (t1, 0);
+ else
+return NULL;
+
+ if (!t2)
+return ret;
+ else if (TREE_CODE (t2) == INTEGER_CST && host_integerp (t2, 0))
+value = tree_low_cst (t2, 0);
+ else if (TREE_CODE (t2) == SSA_NAME)
+{
+ if (ret)
+return NULL;
+ else
+ret = t2;
+}
+
+ if (value <= 4 && value >= -4)
+return ret;
+ else
+return NULL;
+}
+
+/* Return the SSA_NAME in T or T's operands.
+ Return NULL if T does not satisfy IV_COMPARE condition. */
+
+static tree
+find_ssa_name_in_expr (tree t)
+{
+ if (TREE_CODE (t) == SSA_NAME)
+return t;
+
+ if (!BINARY_CLASS_P (t))
+return NULL;
+
+ switch (TREE_OPERAND_LENGTH (t))
+{
+case 1:
+ return find_qualified_ssa_name (TREE_OPERAND (t, 0), NULL);
+case 2:
+ return find_qualified_ssa_name (TREE_OPERAND (t, 0),
+ TREE_OPERAND (t, 1));
+default:
+ return NULL;
+}
+}
+
+/* Check the compare STMT in LOOP. If it compares an induction
+ variable to a loop invariant, return true, and save
+ LOOP_INVARIANT, COMPARE_CODE and LOOP_STEP.
+ Otherwise return false and set LOOP_INVAIANT to NULL. */
+
+static bool
+is_comparison_with_loop_invariant_p (gimple stmt, struct loop *loop,
+tree *loop_invariant,
+enum tree_code *compare_code,
+int *loop_step,
+tree *loop_
Re: [PING] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
On 01/06/12 08:34:52, Tom Tromey wrote: > The patch is ok with either that change or with those 2 lines removed. Applied as svn version 183003.
[PATCH] Adjust 'malloc' attribute documentation to match implementation
Since GCC 4.4 applying the malloc attribute to realloc-like
functions does not work under the documented constraints because
the contents of the memory pointed to are not properly transfered
from the realloc argument (or treated as pointing to anything,
like 4.3 behaved).
The following adjusts documentation to reflect implementation
reality (we do have an implementation detail that treats the
memory blob returned for non-builtins as pointing to any global
variable, but that is neither documented nor do I plan to do
so - I presume it is to allow allocation + initialization
routines to be marked with malloc, but even that area looks
susceptible to misinterpretation to me).
Any comments?
Thanks,
Richard.
2012-01-09 Richard Guenther
* doc/extend.texi (malloc attribute): Adjust according to
implementation.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 183001)
+++ gcc/doc/extend.texi (working copy)
@@ -2771,13 +2771,12 @@ efficient @code{jal} instruction.
@cindex @code{malloc} attribute
The @code{malloc} attribute is used to tell the compiler that a function
may be treated as if any non-@code{NULL} pointer it returns cannot
-alias any other pointer valid when the function returns.
+alias any other pointer valid when the function returns and that the memory
+has undefined content.
This will often improve optimization.
Standard functions with this property include @code{malloc} and
-@code{calloc}. @code{realloc}-like functions have this property as
-long as the old pointer is never referred to (including comparing it
-to the new pointer) after the function returns a non-@code{NULL}
-value.
+@code{calloc}. @code{realloc}-like functions do not have this
+property as the memory pointed to does not have undefined content.
@item mips16/nomips16
@cindex @code{mips16} attribute
GCC 4.7.0 Status Report (2012-01-09), Stage 3 ends now
Status == Stage 3 is now officially over, after a bit more than two months. The GCC trunk is now in regression and documentation fixes only state (so-called stage4). The trunk will remain in this state until it is sufficiently stable for release. At this point we will create the 4.7 branch and do a first release candidate. The overall status is improving nicely since the last report. Quality Data Priority # Change from Last Report --- --- P1 13 - 13 P2 84 - 13 P3 16 - 33 --- --- Total 113 - 59 We currently also have 128 P4 or P5 regression bugs open, those include regressions for non-primary languages and targets that are not included in the list of primary and secondary targets. Previous Report === http://gcc.gnu.org/ml/gcc/2011-12/msg00069.html The next report will be sent by Jakub.
Re: patch: remove is_gimple_non_addressable
On Fri, Jan 6, 2012 at 6:05 PM, Aldy Hernandez wrote: > On 01/05/12 09:36, Richard Guenther wrote: >> >> On Thu, Jan 5, 2012 at 3:48 PM, Aldy Hernandez wrote: >>> >>> As you suggested here: >>> >>> http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00232.html >>> >>> Bootregged on x86-64 Linux. >>> >>> OK? >> >> >> No, this pessimizes things too much at gimplification time, please simply >> inline the predicate instead. >> >> Richard. > > > It wasn't clear from your other message whether you want me to replace the > call with: > > !is_gimple_reg () && !TREE_ADDRESSABLE () > > or outright inline the exact function call as we have now. > > I have done the later. Let me know if you want the former. > > Tested on x86-64 Linux. > > OK? Ok with simply excluding SSA_NAMEs like @@ -4411,16 +4411,27 @@ gimplify_modify_expr_rhs (tree *expr_p, /* It's OK to use the target directly if it's being initialized. */ use_target = true; - else if (TREE_CODE (*to_p) != SSA_NAME && ) - /* Don't use the original target if it's already addressable; - if its address escapes, and the called function uses the - NRV optimization, a conforming program could see *to_p - change before the called function returns; see c++/19317. - When optimizing, the return_slot pass marks more functions - as safe after we have escape info. */ - use_target = false; - else - use_target = true; as SSA_NAMEs can never become addressable during gimplification. Thanks, Richard.
Re: [patch] Fix PR tree-optimization/51624
On Fri, Jan 6, 2012 at 7:17 PM, Eric Botcazou wrote: >> > OK, I see. Then the only way out I can think of is to stop going up the >> > chain of COMPONENT_REFs as soon as the offset becomes negative. >> >> Yeah, that sounds like a better solution. > > PR ada/51775 shows that this pessimizes though because if you have an > enclosing > sub-component at offset 0 on the LHS and not on the RHS, and you're using the > model of the LHS for the RHS, you'll build a convoluted (but correct) MEM on > the RHS, and this is apparently enough to thwart FRE/PRE and the likes in some > simple cases: > > t$F$i2_9 = MEM[(struct pack9__r2 *)y_1(D)].F.i2; > D.2233_3 = y_1(D)->i2; > > The compiler doesn't see that D.2233_3 == t$F$i2_9. Additionally using the > type trick would help, at least for PR ada/51775 and I guess in most cases. > > Thoughts? Can you get me a testcase that I can compile? This should be fixed in FRE. Thanks, Richard. > -- > Eric Botcazou
Re: Support Solaris 11/SPARC in MD_FALLBACK_FRAME_STATE_FOR (PR ada/41929)
> All EH-related tests fail with a recent upgrade on Solaris 10. Interestingly,
> the old implementation keeps working with the upgrade.
I've applied the attached patch to mainline and 4.6 branch. It reverts back to
the old pattern matching code in the Solaris 8+ multi-threaded case, which is
clearly more robust. The rest is left unchanged. Tested on 5 different OS
versions (Solaris 8, Solaris 8 Containers, Solaris 9, old Solaris 10, recent
Solaris 10).
2012-01-09 Eric Botcazou
PR ada/41929
* config/sparc/sol2-unwind.h (sparc64_is_sighandler): Remove SAVPC and
add CFA. Revert back to old code for Solaris 8+ multi-threaded.
(sparc_is_sighandler): Likewise.
(MD_FALLBACK_FRAME_STATE_FOR): Adjust call to IS_SIGHANDLER.
--
Eric Botcazou
Index: config/sparc/sol2-unwind.h
===
--- config/sparc/sol2-unwind.h (revision 183001)
+++ config/sparc/sol2-unwind.h (working copy)
@@ -1,5 +1,5 @@
/* DWARF2 EH unwinding support for SPARC Solaris.
- Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc.
+ Copyright (C) 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
This file is part of GCC.
@@ -34,7 +34,7 @@ see the files COPYING3 and COPYING.RUNTI
#define IS_SIGHANDLER sparc64_is_sighandler
static int
-sparc64_is_sighandler (unsigned int *pc, unsigned int *savpc, int *nframes)
+sparc64_is_sighandler (unsigned int *pc, void *cfa, int *nframes)
{
if (/* Solaris 8 - single-threaded
@@ -110,38 +110,59 @@ sparc64_is_sighandler (unsigned int *pc,
&& pc[ 0] == 0x81c7e008
&& pc[ 1] == 0x81e8)
{
- if (/* Solaris 8 /usr/lib/sparcv9/libthread.so.1
- --
- Before patch 108827-08:
- : st %g4, [ %i1 + 0x1c ]
-
- Since patch 108827-08:
- : st %l0, [ %i4 + 0x10 ] */
- savpc[-1] == 0xc826601c
- || savpc[-1] == 0xe0272010)
+ /* We have observed different calling frames among different
+ versions of the operating system, so that we need to
+ discriminate using the upper frame. We look for the return
+ address of the caller frame (there is an offset of 15 double
+ words between the frame address and the place where this return
+ address is stored) in order to do some more pattern matching. */
+ unsigned int cuh_pattern
+ = *(unsigned int *)(*(unsigned long *)(cfa + 15*8) - 4);
+
+ if (cuh_pattern == 0xd25fa7ef)
{
- /* We need to move up three frames:
+ /* This matches the call_user_handler pattern for Solaris 10.
+ There are 2 cases so we look for the return address of the
+ caller's caller frame in order to do more pattern matching. */
+ unsigned int sah_pattern
+ = *(unsigned int *)(*(unsigned long *)(cfa + 176 + 15*8) - 4);
+
+ if (sah_pattern == 0x92100019)
+ /* This is the same setup as for Solaris 9, see below. */
+ *nframes = 3;
+ else
+ /* The sigacthandler frame isn't present in the chain.
+ We need to move up two frames:
<-- context->cfa
__sighndlr
- sigacthandler
+ call_user_handler frame
- */
- *nframes = 2;
+ */
+ *nframes = 2;
}
- else /* Solaris 8 /usr/lib/lwp/sparcv9/libthread.so.1, Solaris 9+
- -- */
- {
- /* We need to move up three frames:
+ else if (cuh_pattern == 0x9410001a || cuh_pattern == 0x94100013)
+ /* This matches the call_user_handler pattern for Solaris 9 and
+ for Solaris 8 running inside Solaris Containers respectively
+ We need to move up three frames:
<-- context->cfa
__sighndlr
call_user_handler
sigacthandler
- */
- *nframes = 3;
- }
+ */
+ *nframes = 3;
+ else
+ /* This is the default Solaris 8 case.
+ We need to move up two frames:
+
+ <-- context->cfa
+ __sighndlr
+ sigacthandler
+
+ */
+ *nframes = 2;
return 1;
}
@@ -181,7 +202,7 @@ sparc64_frob_update_context (struct _Unw
#define IS_SIGHANDLER sparc_is_sighandler
static int
-sparc_is_sighandler (unsigned int *pc, unsigned int * savpc, int *nframes)
+sparc_is_sighandler (unsigned int *pc, void *cfa, int *nframes)
{
if (/* Solaris 8, 9 - single-threaded
---
@@ -209,7 +230,7 @@ sparc_is_sighandler (unsigned int *pc, u
&& pc[-1] == 0x9410001a
&& pc[ 0] == 0x80a62008)
{
- /* Need to move up one frame:
+ /* We need to move up one frame:
<-- context->cfa
sigacthandler
@@ -240,7 +261,7 @@ sparc_is_sighandler (unsigned int *pc, u
&& pc[ 1] == 0x81e8
&& pc[ 2] == 0x80a26000)
{
- /* Need to move up one frame:
+ /* We need to move up one frame:
<-- context->cfa
__libthread_segvhdlr
@@ -267,33 +288,59 @@ sparc_is_sighandler (unsigned int *pc, u
&& pc[ 0] == 0x81c7e008
&& pc[ 1] == 0x81e8)
{
- if (/*
Re: PR tree-optimization/51680 (not inlining comdats)
On Sun, Jan 8, 2012 at 12:38 AM, Jan Hubicka wrote:
> Hi,
> this patch fixes first half of the PR. The PR is about a function that is
> supposed
> to be inlined at -O2. The function contains two calls, one indirect and
> inlining
> the indirect call makes things a lot better. GCC however things that
> replacing call
> by two calls at -O2 is a bad idea.
>
> This patch solves first part of it. The function in question is COMDAT. We
> already
> know that C++ coding style makes COMDATs quite rarely to be shared and at -Os
> we
> already handle them sort of similarly to static ufnctions. We however don't
> do that
> at -O2. This patch makes it happen in both cases.
>
> Bootstrapped/regtested x86_64-linux, comitted.
> Will commit the testcase with the followup fix.
Err ...
> PR tree-optimization/51680
> * ipa-inline.c (want_inline_small_function_p): Be more lax on functions
> whose inlining reduce unit size.
>
> Index: ipa-inline.c
> ===
> --- ipa-inline.c (revision 182949)
> +++ ipa-inline.c (working copy)
> @@ -482,21 +482,13 @@ want_inline_small_function_p (struct cgr
> e->inline_failed = CIF_MAX_INLINE_INSNS_SINGLE_LIMIT;
> want_inline = false;
> }
> - else if (!DECL_DECLARED_INLINE_P (callee->decl)
> - && !flag_inline_functions)
> - {
> - e->inline_failed = CIF_NOT_DECLARED_INLINED;
> - want_inline = false;
> - }
> - else if (!DECL_DECLARED_INLINE_P (callee->decl)
> - && growth >= MAX_INLINE_INSNS_AUTO)
> - {
> - e->inline_failed = CIF_MAX_INLINE_INSNS_AUTO_LIMIT;
> - want_inline = false;
> - }
> - /* If call is cold, do not inline when function body would grow.
> - Still inline when the overall unit size will shrink because the
> offline
> - copy of function being eliminated.
> + /* Before giving up based on fact that caller size will grow, allow
> + functions that are called few times and eliminating the offline
> + copy will lead to overall code size reduction.
> + Not all of these will be handled by subsequent inlining of functions
> + called once: in particular weak functions are not handled or
> funcitons
> + that inline to multiple calls but a lot of bodies is optimized out.
> + Finally we want to inline earlier to allow inlining of callbacks.
>
> This is slightly wrong on aggressive side: it is entirely possible
> that function is called many times with a context where inlining
> @@ -509,24 +501,39 @@ want_inline_small_function_p (struct cgr
> first, this situation is not a problem at all: after inlining all
> "good" calls, we will realize that keeping the function around is
> better. */
> - else if (!cgraph_maybe_hot_edge_p (e)
> - && (DECL_EXTERNAL (callee->decl)
> + else if (growth <= MAX_INLINE_INSNS_SINGLE
That surely should be MAX_INLINE_INSNS_AUTO instead. At _least_.
You are triggering very much more inlining during early inlining now -
I don't see
where we did this for -Os already as you claim. In fact it is totally
against the spirit of early inlining now :(
Why does IPA inlining not figure out that inlining the indirect call is good?
> + /* Unlike for functions called once, we play unsafe with
> + COMDATs. We can allow that since we know functions
> + in consideration are small (and thus risk is small) and
> + moreover grow estimates already accounts that COMDAT
> + functions may or may not disappear when eliminated from
> + current unit. With good probability making aggressive
> + choice in all units is going to make overall program
> + smaller.
> +
> + Consequently we ask cgraph_can_remove_if_no_direct_calls_p
> + instead of
> + cgraph_will_be_removed_from_program_if_no_direct_calls */
> + && !DECL_EXTERNAL (callee->decl)
> + && cgraph_can_remove_if_no_direct_calls_p (callee)
> + && estimate_growth (callee) <= 0)
> + ;
> + else if (!DECL_DECLARED_INLINE_P (callee->decl)
> + && !flag_inline_functions)
> + {
> + e->inline_failed = CIF_NOT_DECLARED_INLINED;
> + want_inline = false;
> + }
> + else if (!DECL_DECLARED_INLINE_P (callee->decl)
> + && growth >= MAX_INLINE_INSNS_AUTO)
> + {
> + e->inline_failed = CIF_MAX_INLINE_INSNS_AUTO_LIMIT;
> + want_inline = false;
> + }
> + /* If call is cold, do not inline when function body would grow. */
> + else if (!cgraph_maybe_hot_edge_p (e))
>
> - /* Unlike for functions called once, we play unsafe with
> - COMDATs. We can all
Re: [patch] should not define bool, true or false as macros for C++
I've just seen Richard's status email, so I guess this should wait for 4.8 On 9 January 2012 08:48, Jonathan Wakely wrote: > GCC's implementation of is not valid for C++11 because > [support.runtime] p8 says "The header and the header > shall not define macros named bool, true, or false." > > This patch adds a libstdc++ test for that requirement and adjusts > stdbool.h to meet it. I've left _Bool defined in C++ as a GNU > extension. > > It's conceivable someone is relying on these macros being defined in > C++, in which case we could only define them when __cplusplus < > 201103L, but IMHO it's better to not define them at all. > > Tested x86_64-linux, OK for trunk? > > gcc/ > * ginclude/stdbool.h (true, false, bool): Do not define for C++. > > libstdc++/ > * testsuite/18_support/headers/cstdbool/macros.cc: New.
Re: [Patch, Fortran] PR51578 Fix symbol import with renaming and only
Dear all,
this email contains a updated patch, which replaces the FIXME by an
implementation. See below.
Dear Dominique,
On 01/08/2012 11:13 PM, Dominique Dhumieres wrote:
Your patch passed my tests and in top of that fixes the ICE for pr51522.f90.
:-)
However I don't understand the errors:
integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)&
1
Error: Parameter 'c_int' at (1) has not been declared or is a variable, which
does not reduce to a constant expression
real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
1
Error: Parameter 'c_double' at (1) has not been declared or is a variable,
which does not reduce to a constant expression
Is it related to the FIXME?
No, it's related to two bugs in the source code:
a) The USE statement is not a statement by its own (due to the tailing "&")
b) There is no USE statement for: vect_Utils_vuNorm_c
I think the error message for (b) is good. I admit that for (a) a syntax
error would have been better.
Excerpt from the test case (which has been created using "delta" which
deletes lines, honouring certain constraints):
integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol,
exception) &
use, intrinsic :: iso_c_binding
real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel,
exception) bind(c)
end function vect_Utils_vuNorm_c
* * *
Regarding the FIXME: No, it is completely unrelated and it is rather
difficult to encounter.
Ingredients for reject-valid bugs related to the FIXME:
- One needs to USE a module name of an intrinsic module (iso_* or omp*)
- No non_intrinsic module with that name exists
- Multiple USE statements are used - some but not all with INTRINSIC
attribute
- One renames symbols
- One uses the renamed-away symbols for other purposes
I believe that it is very unlikely that someone generates such a code.
Example:
use iso_c_binding
use, intrinsic :: iso_c_binding, c_double_orig => c_double
integer :: c_double
That's valid and rejected. If a non_intrinsic module "iso_c_binding"
exists, the code actually works correctly. It only wrongly
use-associates "c_double" if no non_intrinsic module exists. Workaround:
Use "intrinsic" in both USE statements - or in none.
However, I have now decided that it is better to actually implement the
FIXME; the updated patch is attached. (It was simpler than expected.)
Only gfc_use_modules has been changed and a new test case been added.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-01-09 Tobias Burnus
PR fortran/51578
* gfortran.h (gfc_use_list):
* match.h (gfc_use_module): Rename to ...
(gfc_use_modules): ... this.
* module.c (use_locus, specified_nonint, specified_int): Remove
global variable.
(module_name): Change type to const char*, used with gfc_get_string.
(module_list): New global variable.
(free_rename): Free argument not global var.
(gfc_match_use): Save match to module_list.
(load_generic_interfaces, read_module): Don't free symtree.
(write_dt_extensions, gfc_dump_module): Fix module-name I/O due to the
type change of module_name.
(write_symbol0, write_generic): Optimize due to the type change.
(import_iso_c_binding_module, use_iso_fortran_env_module): Use
locus of rename->where.
(gfc_use_module): Take module_list as argument.
(gfc_use_modules): New function.
(gfc_module_init_2, gfc_module_done_2): Init module_list, rename_list.
* parse.c (last_was_use_stmt): New global variable.
(use_modules): New function.
(decode_specification_statement, decode_statement): Move USE match up
and call use_modules.
(next_free, next_fixed): Call use_modules.
(accept_statement): Don't call gfc_module_use.
2012-01-09 Tobias Burnus
PR fortran/51578
* gfortran.dg/use_17.f90: New.
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index e8a3de0..f339271 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1299,7 +1299,9 @@ gfc_use_rename;
typedef struct gfc_use_list
{
const char *module_name;
- int only_flag;
+ bool intrinsic;
+ bool non_intrinsic;
+ bool only_flag;
struct gfc_use_rename *rename;
locus where;
/* Next USE statement. */
diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h
index df18074..a5d5497 100644
--- a/gcc/fortran/match.h
+++ b/gcc/fortran/match.h
@@ -249,7 +249,7 @@ match gfc_match_expr (gfc_expr **);
/* module.c. */
match gfc_match_use (void);
-void gfc_use_module (void);
+void gfc_use_modules (void);
#endif /* GFC_MATCH_H */
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 1ab08ae..1542263 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -188,10 +188,8 @@ static FILE *module_fp;
static struct md5_ctx ctx;
/* The name of the module we're reading (USE'ing) or writing. */
-static char module_name[GFC_MAX_SYMBOL_LEN + 1];
-
-/* The way the module we're reading was specified. */
-static bool specified_nonint, specified_int;
+s
[Patch, Fortran] PR 51758 - fix ICE with null() in elemental procedures
The issue was discovered when looking at the optional + elemental +
scalarizer issue (PR 50981, 4.4-4.7 regression). However, the example of
this PR never worked. Passing null() to denote an absent argument (for
nonallocatable/nonpointer dummies) is a Fortran 2008 / GCC 4.6 feature.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-01-09 Tobias Burnus
PR fortran/51758
* trans-expr (gfc_conv_procedure_call): Handle EXPR_NULL
in a scalarized loop.
2012-01-09 Tobias Burnus
PR fortran/51758
* gfortran.dg/optional_absent_2.f90: New.
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c (revision 182995)
+++ gcc/fortran/trans-expr.c (working copy)
@@ -3408,6 +3408,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
parmse.expr = null_pointer_node;
if (arg->missing_arg_type == BT_CHARACTER)
parmse.string_length = build_int_cst (gfc_charlen_type_node, 0);
+ if (se->ss && (se->ss->info->type == GFC_SS_SCALAR
+ || se->ss->info->type == GFC_SS_REFERENCE))
+ gfc_advance_se_ss_chain (se);
}
else if (fsym && fsym->ts.type == BT_CLASS
&& e->ts.type == BT_DERIVED)
Index: gcc/testsuite/gfortran.dg/optional_absent_2.f90
===
--- gcc/testsuite/gfortran.dg/optional_absent_2.f90 (revision 0)
+++ gcc/testsuite/gfortran.dg/optional_absent_2.f90 (working copy)
@@ -0,0 +1,53 @@
+! { dg-do run }
+!
+! PR fortran/51758
+!
+! Contributed by Mikael Morin
+!
+! Check whether passing NULL() to an elemental procedure works,
+! where NULL() denotes an absent optional argument.
+!
+program p
+
+ integer :: a(2)
+ integer :: b
+
+ a = 0
+ a = foo((/ 1, 1 /), null())
+! print *, a
+ if (any(a /= 2)) call abort
+
+ a = 0
+ a = bar((/ 1, 1 /), null())
+! print *, a
+ if (any(a /= 2)) call abort
+
+ b = 0
+ b = bar(1, null())
+! print *, b
+ if (b /= 2) call abort
+
+contains
+
+ function foo(a, b)
+integer :: a(:)
+integer, optional :: b(:)
+integer :: foo(size(a))
+
+if (present(b)) call abort
+
+foo = 2
+ end function foo
+
+ elemental function bar(a, b)
+integer, intent(in) :: a
+integer, intent(in), optional :: b
+integer :: bar
+
+bar = 2
+
+if (present(b)) bar = 1
+
+ end function bar
+
+end program p
Re: [patch] Fix PR tree-optimization/51624
> Can you get me a testcase that I can compile? This should be fixed in FRE. This is gnat.dg/pack9.ad[sb]. You need a bare cross-compiler to s390x-linux: configure, build with make CFLAGS=-g, when the build fails, do gcc/ada then make gnatlib. Go back to the build dir, copy gnat.dg/pack9.ad[sb] and do: gcc/xgcc -Bgcc -S -O2 -gnatp pack9.adb -Igcc/ada/rts -fdump-tree-optimized The .optimized dump shouldn't contain any call to gnat_rcheck_21. If you install a change, please mention PR tree-optimization/51775. TIA. -- Eric Botcazou
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
On 17/12/2011 11:07, Eric Botcazou wrote: >> I am happily using this patch and await this to be committed. > > Only after the import library issue is addressed. What do the other > libraries > bundled with GCC do here? Sorry for the delay guys, I got rather busy over the holidays. I see we're now discussing a patch for next stage 1. Well, to the point: I thinko'd slightly when I said that import libraries are "preferred"; it's the platform convention, and it's the way the MS toolchain works because it can't link directly against DLLs, but it's not (as I mistakenly assumed at the time, although did not explicitly state) any more correct or valid. It does however solve the problem of wanting the DLL to be in the /bin directory, while still needing something to stand in its place in the /lib directory so that the linker can find it without the compiler having to put -L$prefix/bin in the specs. It's also used on Cygwin and MinGW to address library versioning: the actual DLL has a numbered suffix to indicate version, but the import library is unnumbered, so you can just say -lblah as usual and automatically link against whatever the installed version of the DLL is without having to know the version suffix and specify it in the -l option. Ada doesn't need that, as it happens, because it always generates the specfile to explicitly include the version number of libgnat/libgnarl in the -l option, and doesn't try to keep the shared library compatible across point releases of the compiler, but it's how all the other runtimes work on Windows; they all put an import library in /lib and the DLL itself into /bin. Ada should work the same way, because otherwise you either need to point your PATH into gcc's private dir at runtime, or point your linker into /bin at linktime, neither of which are entirely neat solutions. cheers, DaveK
Re: PR tree-optimization/51680 (not inlining comdats)
> > That surely should be MAX_INLINE_INSNS_AUTO instead. At _least_. > You are triggering very much more inlining during early inlining now - > I don't see > where we did this for -Os already as you claim. In fact it is totally > against the spirit of early inlining now :( This is IPA inlining, not early inlining. I just moved the logic from -Os logic to include -O2 logic, too. I added the size check because I was worried of units containing one very large function that simplifies quite a lot by inlining (because of the new predicate code). Because badness function is not really worried about function sizes (it expects them to be small) and merely accounts relative benefits, we would end up then inlining this large function quite early in queue preventing other inlining from happening. So it seemed safer to add the size check. Except the degenerate case described above it should not make much of practical difference. > > Why does IPA inlining not figure out that inlining the indirect call is good? For reasons described in the original mail. We are doing -O2, function is not declared inline and so far we was inlining only for size at -O2 in that case. Honza
Re: [PING] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
On 01/09/2012 10:02 AM, Gary Funck wrote:
On 01/06/12 08:34:52, Tom Tromey wrote:
The patch is ok with either that change or with those 2 lines removed.
Applied as svn version 183003.
I get the build failure:
libcpp/macro.c:220:26: error: variable 'map' set but not used
[-Werror=unused-but-set-variable]
Your patch removed:
- map = linemap_lookup (pfile->line_table,
pfile->line_table->highest_line);
- while (! MAIN_FILE_P (map))
- map = INCLUDED_FROM (pfile->line_table, map);
- name = ORDINARY_MAP_FILE_NAME (map);
I concur with the compiler, given that only the following remains:
_cpp_builtin_macro_text (cpp_reader *pfile, cpp_hashnode *node)
{
const struct line_map *map;
...
case BT_SPECLINE:
map = LINEMAPS_LAST_ORDINARY_MAP (pfile->line_table);
which looks like dead code to me.
Tobias
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
On 17/12/2011 10:06, Christian Joensson wrote: > I can add that I also, manually, copy the > lto-plugin/.libs/cyglto_plugin-0.dll into $bindir too. Why? It deliberately installs into libexecsubdir rather than bindir because it's only ever invoked by the gcc driver, which passes the full explicit path in the -plugin option on the command-line for ld to pass to dlopen(); it shouldn't need to be found on $PATH at all if everything's working as intended. cheers, DaveK
Re: [patch] Fix PR tree-optimization/51624
On Mon, Jan 9, 2012 at 11:33 AM, Eric Botcazou wrote: >> Can you get me a testcase that I can compile? This should be fixed in FRE. > > This is gnat.dg/pack9.ad[sb]. You need a bare cross-compiler to s390x-linux: > configure, build with make CFLAGS=-g, when the build fails, do gcc/ada then > make gnatlib. Go back to the build dir, copy gnat.dg/pack9.ad[sb] and do: > > gcc/xgcc -Bgcc -S -O2 -gnatp pack9.adb -Igcc/ada/rts -fdump-tree-optimized > > The .optimized dump shouldn't contain any call to gnat_rcheck_21. > > > If you install a change, please mention PR tree-optimization/51775. TIA. Hmm, it seems to be because we do not value-number loads that satisfy stmt_could_throw_p (for whatever reason ...). Seems to date back to rev. 131610, the fix for PR34648. Looking at that bug it seems that we could at least allow stmts that only throw externally (but generally CSE should still work, so value-number them when we are doing FRE but not PRE). Richard. > -- > Eric Botcazou
Re: PR tree-optimization/51680 (not inlining comdats)
On Mon, Jan 9, 2012 at 12:07 PM, Jan Hubicka wrote: >> >> That surely should be MAX_INLINE_INSNS_AUTO instead. At _least_. >> You are triggering very much more inlining during early inlining now - >> I don't see >> where we did this for -Os already as you claim. In fact it is totally >> against the spirit of early inlining now :( > > This is IPA inlining, not early inlining. I just moved the logic from -Os > logic > to include -O2 logic, too. Ok, I was confused then. But as you re-order the tests this exception will apply always, no? > I added the size check because I was worried of units containing one very > large > function that simplifies quite a lot by inlining (because of the new predicate > code). Because badness function is not really worried about function sizes (it > expects them to be small) and merely accounts relative benefits, we would end > up then inlining this large function quite early in queue preventing other > inlining from happening. > > So it seemed safer to add the size check. Except the degenerate case described > above it should not make much of practical difference. But the size check is inconsistent wrt inline declares, non-inline declared fns should get the _auto limit. >> >> Why does IPA inlining not figure out that inlining the indirect call is good? > > For reasons described in the original mail. We are doing -O2, function is not > declared inline and so far we was inlining only for size at -O2 in that case. > > Honza
Re: [patch] Fix PR tree-optimization/51624
> Hmm, it seems to be because we do not value-number loads that > satisfy stmt_could_throw_p (for whatever reason ...). Seems to date > back to rev. 131610, the fix for PR34648. Looking at that bug it > seems that we could at least allow stmts that only throw externally > (but generally CSE should still work, so value-number them when > we are doing FRE but not PRE). OK. The annoying thing is that it's optimized if you have y_1(D)->i2: t$F$i2_9 = y_1(D)->i2; D.1579_3 = y_1(D)->i2; and this is equivalent wrt throwing (in particular TREE_THIS_NOTRAP is not set anywhere). -- Eric Botcazou
Re: [Patch, Fortran] PR51578 Fix symbol import with renaming and only
On Mon, Jan 9, 2012 at 12:02, Tobias Burnus wrote: > Dear all, > > this email contains a updated patch, which replaces the FIXME by an > implementation. See below. > > > Dear Dominique, > > > On 01/08/2012 11:13 PM, Dominique Dhumieres wrote: >> >> Your patch passed my tests and in top of that fixes the ICE for >> pr51522.f90. > > :-) > >> However I don't understand the errors: >> >> integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, >> exception)& >> 1 >> Error: Parameter 'c_int' at (1) has not been declared or is a variable, >> which does not reduce to a constant expression >> >> real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) >> bind >> 1 >> Error: Parameter 'c_double' at (1) has not been declared or is a variable, >> which does not reduce to a constant expression >> >> Is it related to the FIXME? > > > No, it's related to two bugs in the source code: > a) The USE statement is not a statement by its own (due to the tailing "&") > b) There is no USE statement for: vect_Utils_vuNorm_c > > I think the error message for (b) is good. I admit that for (a) a syntax > error would have been better. > > Excerpt from the test case (which has been created using "delta" which > deletes lines, honouring certain constraints): > > > integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception) & > use, intrinsic :: iso_c_binding > real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) > bind(c) > end function vect_Utils_vuNorm_c > > * * * > > Regarding the FIXME: No, it is completely unrelated and it is rather > difficult to encounter. > > Ingredients for reject-valid bugs related to the FIXME: > - One needs to USE a module name of an intrinsic module (iso_* or omp*) > - No non_intrinsic module with that name exists > - Multiple USE statements are used - some but not all with INTRINSIC > attribute > - One renames symbols > - One uses the renamed-away symbols for other purposes > > I believe that it is very unlikely that someone generates such a code. > > Example: > use iso_c_binding > use, intrinsic :: iso_c_binding, c_double_orig => c_double > integer :: c_double > > That's valid and rejected. If a non_intrinsic module "iso_c_binding" exists, > the code actually works correctly. It only wrongly use-associates "c_double" > if no non_intrinsic module exists. Workaround: Use "intrinsic" in both USE > statements - or in none. > > > However, I have now decided that it is better to actually implement the > FIXME; the updated patch is attached. (It was simpler than expected.) Only > gfc_use_modules has been changed and a new test case been added. > > Build and regtested on x86-64-linux. > OK for the trunk? Thanks, looks good. Ok for trunk. Given that this has been broken since 4.3 and nobody noticed until now, and the patch is somewhat intrusive, I think it's ok to not backport it to the other branches. -- Janne Blomqvist
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
> Sorry for the delay guys, I got rather busy over the holidays. I see > we're now discussing a patch for next stage 1. No, not necessarily, the patch is specific to Ada on Windows so the risk is quite low. > It does however solve the problem of wanting the DLL to be in the /bin > directory, while still needing something to stand in its place in the /lib > directory so that the linker can find it without the compiler having to put > -L$prefix/bin in the specs. This indeed sounds compelling enough. > It's also used on Cygwin and MinGW to address library versioning: the > actual DLL has a numbered suffix to indicate version, but the import > library is unnumbered, so you can just say -lblah as usual and > automatically link against whatever the installed version of the DLL is > without having to know the version suffix and specify it in the -l option. > Ada doesn't need that, as it happens, because it always generates the > specfile to explicitly include the version number of libgnat/libgnarl in > the -l option, and doesn't try to keep the shared library compatible across > point releases of the compiler, but it's how all the other runtimes work on > Windows; they all put an import library in /lib and the DLL itself into > /bin. Ada should work the same way, because otherwise you either need to > point your PATH into gcc's private dir at runtime, or point your linker > into /bin at linktime, neither of which are entirely neat solutions. If all the other runtimes do it, I think we should do it too. Pacal, what do you think? -- Eric Botcazou
[RFC/ARM] Prefer branches over conditional execution for Cortex-A15.
The attached patch tunes the costs of conditional execution and branches
for Cortex-A15 to be the same as that for Cortex-A5.
This gives an average improvement of over 6% on a popular embedded
benchmark.
Note that the tuning parameter structure added for Cortex-A15 is only tuned
for branch costs, and otherwise takes the generic values. Tuning for other
optimisations (notably preload insertion) is still to be done.
Thanks,
Matt
gcc/ChangeLog:
2012-01-06 Matthew Gretton-Dann
* config/arm/arm-cores.def (cortex-a15): Use cortex_a15_tune for
tuning parameters.
* config/arm/arm.c (arm_cortex_a15_tune): New static variable.
--
Matthew Gretton-Dann
Principal Engineer, PD Software, ARM Ltd.diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
index 80609e0..b0bd172 100644
--- a/gcc/config/arm/arm-cores.def
+++ b/gcc/config/arm/arm-cores.def
@@ -129,7 +129,7 @@ ARM_CORE("cortex-a5", cortexa5, 7A,
FL_LDSCHED, cortex_a5)
ARM_CORE("cortex-a7",cortexa7, 7A,
FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV, cortex)
ARM_CORE("cortex-a8",cortexa8, 7A,
FL_LDSCHED, cortex)
ARM_CORE("cortex-a9",cortexa9, 7A,
FL_LDSCHED, cortex_a9)
-ARM_CORE("cortex-a15", cortexa15,7A,
FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV, cortex)
+ARM_CORE("cortex-a15", cortexa15,7A,
FL_LDSCHED | FL_THUMB_DIV | FL_ARM_DIV, cortex_a15)
ARM_CORE("cortex-r4",cortexr4, 7R,
FL_LDSCHED, cortex)
ARM_CORE("cortex-r4f", cortexr4f,7R,
FL_LDSCHED, cortex)
ARM_CORE("cortex-r5",cortexr5, 7R,
FL_LDSCHED | FL_ARM_DIV, cortex)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 0bded8d..6f1eb13 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -961,6 +961,17 @@ const struct tune_params arm_cortex_a9_tune =
arm_default_branch_cost
};
+const struct tune_params arm_cortex_a15_tune =
+{
+ arm_9e_rtx_costs,
+ NULL,
+ 1, /* Constant limit. */
+ 1, /* Max cond insns. */
+ ARM_PREFETCH_NOT_BENEFICIAL, /* TODO: Calculate correct
values. */
+ false, /* Prefer constant pool. */
+ arm_cortex_a5_branch_cost
+};
+
const struct tune_params arm_fa726te_tune =
{
arm_9e_rtx_costs,
Re: PR tree-optimization/51680 (not inlining comdats)
> On Mon, Jan 9, 2012 at 12:07 PM, Jan Hubicka wrote: > >> > >> That surely should be MAX_INLINE_INSNS_AUTO instead. At _least_. > >> You are triggering very much more inlining during early inlining now - > >> I don't see > >> where we did this for -Os already as you claim. In fact it is totally > >> against the spirit of early inlining now :( > > > > This is IPA inlining, not early inlining. I just moved the logic from -Os > > logic > > to include -O2 logic, too. > > Ok, I was confused then. But as you re-order the tests this exception > will apply always, no? Yes, for all sorts of auto inlining we have. It makes sense now. When the code was written we did not have indirect inlining, did not special case comdats and did not have the context sensitivity, so it was safe to first do all small function inlining and later all inlining of all functions called once. Now order matters, by deferring even relatively small functions for very end we loose the context sensitivity, like in the testcase discussed. > > > I added the size check because I was worried of units containing one very > > large > > function that simplifies quite a lot by inlining (because of the new > > predicate > > code). Because badness function is not really worried about function sizes > > (it > > expects them to be small) and merely accounts relative benefits, we would > > end > > up then inlining this large function quite early in queue preventing other > > inlining from happening. > > > > So it seemed safer to add the size check. Except the degenerate case > > described > > above it should not make much of practical difference. > > But the size check is inconsistent wrt inline declares, non-inline declared > fns should get the _auto limit. Not really, I want even _auto limit to be bypassed in this case. We may introduce new parameter for this, but _single limit is resonably big and available and we do have too many parameters already. Well, this hits the problem that the limits as written does not make that good sense with the inliner logic as it works now. As i think about it now we have three basic cases. 1) We do have cases where we inline just to reduce size. This is quite clear and don't really need a parameter. 2) We have case where we inline just because we do -O3 and we don't see particular benefit of inlining but we will reduce call overhead and we may hope that something simplifies later. This is sort of what current _auto limit serves. 3) We know that inlining will be a win - either by profile, or by user hint, or by fact that we know a lot of code will optimize out, or we know call will devirtualize, or we know that program will not grow etc. etc. This is sort of what current _single limit serves, but not really well, since the benefits have different importance... Honza
Re: [patch] Fix PR tree-optimization/51624
On Mon, Jan 9, 2012 at 12:45 PM, Eric Botcazou wrote: >> Hmm, it seems to be because we do not value-number loads that >> satisfy stmt_could_throw_p (for whatever reason ...). Seems to date >> back to rev. 131610, the fix for PR34648. Looking at that bug it >> seems that we could at least allow stmts that only throw externally >> (but generally CSE should still work, so value-number them when >> we are doing FRE but not PRE). > > OK. The annoying thing is that it's optimized if you have y_1(D)->i2: > > t$F$i2_9 = y_1(D)->i2; > D.1579_3 = y_1(D)->i2; > > and this is equivalent wrt throwing (in particular TREE_THIS_NOTRAP is not set > anywhere). Yeah, there is no good reason to disallow CSEing throwing loads (or even volatile loads). The change that introduced this is no longer necessary as the PRE set filling was re-organized completely, avoiding the original issue (PRE indeed should not insert throwing stmts - well, at least if they throw internally, but we can't distinguish the case we have two matching loads, one throwing internally and one externally). I have a patch. Richard. > -- > Eric Botcazou
Re: increase call_saved_regs[] in caller-save.c
Hi, On Sat, 7 Jan 2012, Peter Bergner wrote: > While digging through ira-color.c tracking down an IRA shuffle copy > issue, I noticed we only seem to do real copy coalescing for spilled > pseudos. It seems we rely on coloring to try and assign the same hard > reg to pseudos connected by a copy so the copy can be removed as a nop. > Looking at all the code used to do the cost preferencing to achieve > that, I'm guessing just coalescing them would be a lot easier. The complexity starts when you want to retroactively decide that a coalesce was not that worthwhile or even harmful. Copies sometimes are nice live-range split points (and sometimes not), so some copies you want to coalesce, others you don't want to. Deciding which ones to coalesce influences the others, spilling influences it too, and finally coloring decisions itself influence the optimality of coalescing retroactively. Past approaches to this included a host of things including the iterated approach, the coalesce-split approach and the like. When I still fiddled with all this in new-ra I found it most natural to just do coalescing while coloring (i.e. try to give same colors to copy-connected neighbors), including taking care not to take away colors from nodes that would prefer to get colors from a copy-neighbor. This way reverting a coalesce merely becomes a "oh well, so this color in the end wasn't really available", instead of an operation on the conflict/coalesce graph. I assume that Vlad does similar. Ciao, Michael.
Re: RFC: An alternative -fsched-pressure implementation
On 12/23/2011 12:46 PM, Richard Sandiford wrote: > In the end I tried an ad-hoc approach in an attempt to do something > about (2), (3) and (4b). The idea was to construct a preliminary > "model" schedule in which the only objective is to keep register > pressure to a minimum. This schedule ignores pipeline characteristics, > latencies, and the number of available registers. The maximum pressure > seen in this initial model schedule (MP) is then the benchmark for ECC(X). Interesting. I had also thought about trying to address the problem in the scheduler, so I'll just share some of my thoughts (not intended as a negative comment on your approach). Essentially the problem I usually see is that the wider your machine gets, the happier sched1 will be to fill unused slots with instructions that could just as well be scheduled 200 cycles later. That's really an artifact of forward scheduling, so why not schedule both forwards and then backwards (or the other way round)? Produce an initial schedule, then perform a fixup phase: start at the other end and look for instructions that can be scheduled in a wide range of cycles, and move them if doing so can be shown to reduce register pressure, and we retain a correct schedule. This can be done without trying to have a global pressure estimate which has the problems you noted. Doing this would require constructing a backwards DFA, and I gave up on this for the moment after a day or so spent with genautomata, but it should be possible. Bernd
Ping^2: Re: [patch libstdc++]: Fix PR/51673
Ping
2012/1/5 Kai Tietz :
> Ping!
>
> 2012/1/2 Paolo Carlini :
>> Hi,
>>
>>> Hello,
>>>
>>> additionally to the suggested patch by Pawel Sikora, I added the
>>> adjustments for mt-allocator to it too.
>>>
>>> ChangeLog
>>>
>>> 2012-01-01 Kai Tietz
>>>
>>> PR libstc++/51673
>>> * config/abi/pre/gnu-versioned-namespace.ver: Adjusted new/delete
>>> operators signature for LLP64 size_t, and adjusted signatures for
>>> mt-allocator using size_t.
>>>
>>> Tested for x86_64-w64-mingw32, and regression tested also for
>>> x86_64-unknown-linux-gnu. Ok for apply to trunk and 4.6.x?
>>
>> Benjamin, can you have a look to this? I suspect the other established
>> allocators (like, eg, pool) should be also dealt with, but I don't know
>> versioned namespace well enough to properly review the patch.
>>
>> Thanks,
>> Paolo.
>
>
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: [PING] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
> I get the build failure: ...
I got the same failure. The following patch
--- ../_clean/libcpp/macro.c2012-01-09 11:15:22.0 +0100
+++ ../work/libcpp/macro.c 2012-01-09 12:28:06.0 +0100
@@ -217,7 +217,7 @@ static const char * const monthnames[] =
const uchar *
_cpp_builtin_macro_text (cpp_reader *pfile, cpp_hashnode *node)
{
- const struct line_map *map;
+ const struct line_map __attribute__((unused)) *map;
const uchar *result = NULL;
linenum_type number = 1;
allowed me to finish the build.
Cheers,
Dominique
PS I always wonder you such failures can escape the maintainers' tests!-(
Re: [RFC/ARM] Prefer branches over conditional execution for Cortex-A15.
On 09/01/12 12:01, Matthew Gretton-Dann wrote: > The attached patch tunes the costs of conditional execution and branches > for Cortex-A15 to be the same as that for Cortex-A5. > > This gives an average improvement of over 6% on a popular embedded > benchmark. > > Note that the tuning parameter structure added for Cortex-A15 is only tuned > for branch costs, and otherwise takes the generic values. Tuning for other > optimisations (notably preload insertion) is still to be done. > > Thanks, > > Matt > > gcc/ChangeLog: > > 2012-01-06 Matthew Gretton-Dann > > * config/arm/arm-cores.def (cortex-a15): Use cortex_a15_tune for > tuning parameters. > * config/arm/arm.c (arm_cortex_a15_tune): New static variable. > > Technically this is too late for 4.7, but the risk is very low and Cortex-A15 tuning is new. So OK, but please check in ASAP. R.
[PATCH] Fix PR51775
This fixes PR51775, we do not need to avoid value-numbering for
stmts that can throw. PRE already ensures to not enter anything
into the EXP/TMP_GEN sets for those so it won't ever end up
trying to insert throwing expressions.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-01-09 Richard Guenther
PR tree-optimization/51775
* tree-ssa-sccvn.c (visit_use): Value-number throwing stmts.
* tree-ssa-pre.c (eliminate): Properly fixup EH info.
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 183007)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -3178,8 +3178,7 @@ visit_use (tree use)
if (gimple_code (stmt) == GIMPLE_PHI)
changed = visit_phi (stmt);
else if (!gimple_has_lhs (stmt)
- || gimple_has_volatile_ops (stmt)
- || stmt_could_throw_p (stmt))
+ || gimple_has_volatile_ops (stmt))
changed = defs_to_varying (stmt);
else if (is_gimple_assign (stmt))
{
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 183007)
+++ gcc/tree-ssa-pre.c (working copy)
@@ -4194,6 +4194,7 @@ eliminate (void)
tree sprime = NULL;
pre_expr lhsexpr = get_or_alloc_expr_for_name (lhs);
pre_expr sprimeexpr;
+ gimple orig_stmt = stmt;
sprimeexpr = bitmap_find_leader (AVAIL_OUT (b),
get_expr_value_id (lhsexpr),
@@ -4231,6 +4232,16 @@ eliminate (void)
propagate_tree_value_into_stmt (&gsi, sprime);
stmt = gsi_stmt (gsi);
update_stmt (stmt);
+
+ /* If we removed EH side-effects from the statement, clean
+its EH information. */
+ if (maybe_clean_or_replace_eh_stmt (orig_stmt, stmt))
+ {
+ bitmap_set_bit (need_eh_cleanup,
+ gimple_bb (stmt)->index);
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file, " Removed EH side-effects.\n");
+ }
continue;
}
@@ -4286,7 +4297,7 @@ eliminate (void)
/* If we removed EH side-effects from the statement, clean
its EH information. */
- if (maybe_clean_or_replace_eh_stmt (stmt, stmt))
+ if (maybe_clean_or_replace_eh_stmt (orig_stmt, stmt))
{
bitmap_set_bit (need_eh_cleanup,
gimple_bb (stmt)->index);
Re: [PING] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
On 01/09/12 12:08:22, Tobias Burnus wrote: > I get the build failure: > > libcpp/macro.c:220:26: error: variable 'map' set but not used > [-Werror=unused-but-set-variable] Tobias, thanks. Will fix. - Gary
[PATCH] Fix bootstrap
Committed as obvious.
Richard.
2012-01-09 Richard Guenther
libcpp/
* macro.c (_cpp_builtin_macro_text): Remove unused variable map.
Index: macro.c
===
--- macro.c (revision 183012)
+++ macro.c (working copy)
@@ -217,7 +217,6 @@ static const char * const monthnames[] =
const uchar *
_cpp_builtin_macro_text (cpp_reader *pfile, cpp_hashnode *node)
{
- const struct line_map *map;
const uchar *result = NULL;
linenum_type number = 1;
@@ -300,7 +299,6 @@ _cpp_builtin_macro_text (cpp_reader *pfi
break;
case BT_SPECLINE:
- map = LINEMAPS_LAST_ORDINARY_MAP (pfile->line_table);
/* If __LINE__ is embedded in a macro, it must expand to the
line of the macro's invocation, not its definition.
Otherwise things like assert() will not work properly. */
Re: [Patch, Fortran] PR 51758 - fix ICE with null() in elemental procedures
Sorry Tobias, I was about to post a patch about this when I saw your
message.
The issue is that the code handling NULL() doesn't consume the gfc_ss
struct created for it. Your fix, which advances to the next one anyway
would work just well, but I think it is slightly cleaner to not create
the struct in the first place, as it is unused.
I'm currently regtesting the following patch. The testcase is the same
as your. OK for 4.7/4.6?
2012-01-09 Mikael Morin
* trans-array.c (gfc_walk_elemental_function_args):
Skip over NULL() actual arguments.
diff --git a/trans-array.c b/trans-array.c
index b9902b9..ca6519b 100644
--- a/trans-array.c
+++ b/trans-array.c
@@ -8369,7 +8369,8 @@ gfc_walk_elemental_function_args (gfc_ss * ss,
gfc_actual_arglist *arg,
scalar = 1;
for (; arg; arg = arg->next)
{
- if (!arg->expr)
+ if (!arg->expr
+ || arg->expr->expr_type == EXPR_NULL)
continue;
newss = gfc_walk_subexpr (head, arg->expr);
[Patch, Fortran] gfortran.texi: Update (C) year and F2003 status
Ok for the trunk? (Build + "make pdf" tested)
Tobias
2012-01-09 Tobias Burnus
* gfortran.texi: Bump copyright year.
(Fortran 2003 Status): Update polymorphism item, add
item for generic interface with DT name.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index aac2d90..faa997e 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1,7 +1,7 @@
\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename gfortran.info
-@set copyrights-gfortran 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
+@set copyrights-gfortran 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
@include gcc-common.texi
@@ -795,8 +795,13 @@ override type-bound procedures or to have deferred binding.
@item Polymorphic entities (``@code{CLASS}'') for derived types -- including
@code{SAME_TYPE_AS}, @code{EXTENDS_TYPE_OF} and @code{SELECT TYPE}.
-Note that the support for array-valued polymorphic entities is incomplete
-and unlimited polymophism is currently not supported.
+Note that unlimited polymophism is currently not supported.
+
+@item Generic interface name which have the same name as derived types are
+now supported, which allows to write constructor functions. Note that
+Fortran does not support static constructor functions. For static
+variables, only default initialization or structure-constructor
+initialization are available.
@item The @code{ASSOCIATE} construct.
Re: [PING] PR33919/preprocessor fix __BASE_FILE__ when included from the command line
On 01/09/12 06:04:28, Gary Funck wrote: > On 01/09/12 12:08:22, Tobias Burnus wrote: > > I get the build failure: > > > > libcpp/macro.c:220:26: error: variable 'map' set but not used > > [-Werror=unused-but-set-variable] Richard, thanks. 2012-01-09 Richard Guenther libcpp/ * macro.c (_cpp_builtin_macro_text): Remove unused variable map.
Re: [Patch, Fortran] PR 51758 - fix ICE with null() in elemental procedures
On 01/09/2012 03:34 PM, Mikael Morin wrote: The issue is that the code handling NULL() doesn't consume the gfc_ss struct created for it. Your fix, which advances to the next one anyway would work just well, but I think it is slightly cleaner to not create the struct in the first place, as it is unused. I'm currently regtesting the following patch. The testcase is the same as your. OK for 4.7/4.6? OK. For the test case, either take mine or don't forget to enable all "if() abort"s and to change in the last "! print *,a" the "a" into a "b". + if (!arg->expr + || arg->expr->expr_type == EXPR_NULL) continue; (I'd prefer to have no line break before the "||".) Tobias
Re: [RFC, ARM][PATCH 4/5] Limit on frequency in if-conversion
On 12/30/2011 05:50 PM, Dmitry Melnik wrote: > If one of branches has significantly greater probability than the other, > then it may be better to rely on CPU's branch prediction and block > reordering, than putting rarely executed instructions into the pipeline. > In this patch we set 10% frequency ratio as a cutoff. > On SPEC2K INT with -O2 this reduced code size for 28 bytes (no > regressions). This probably should be controlled by a target hook. C6X for example probably doesn't want this. Bernd
Re: patch: remove is_gimple_non_addressable
Ok with simply excluding SSA_NAMEs like
@@ -4411,16 +4411,27 @@ gimplify_modify_expr_rhs (tree *expr_p,
/* It's OK to use the target directly if it's being
initialized. */
use_target = true;
- else if (TREE_CODE (*to_p) != SSA_NAME
&& )
- /* Don't use the original target if it's already addressable;
- if its address escapes, and the called function uses the
- NRV optimization, a conforming program could see *to_p
- change before the called function returns; see c++/19317.
- When optimizing, the return_slot pass marks more functions
- as safe after we have escape info. */
- use_target = false;
- else
- use_target = true;
as SSA_NAMEs can never become addressable during gimplification.
Ok, since I'm never quite 100% sure I'm following your suggestions...
I'm posting the final patch here. If tests pass, I'll commit.
Thanks again.
* gimple.c (is_gimple_non_addressable): Remove.
* gimple.h: Remove is_gimple_non_addressable.
* gimplify.c (gimplify_modify_expr_rhs): Use is_gimple_reg instead of
is_gimple_non_addressable.
* trans-mem.c (expand_assign_tm): Same.
Index: trans-mem.c
===
--- trans-mem.c (revision 182908)
+++ trans-mem.c (working copy)
@@ -2184,7 +2184,7 @@ expand_assign_tm (struct tm_region *regi
/* ??? Figure out if there's any possible overlap between the LHS
and the RHS and if not, use MEMCPY. */
- if (load_p && is_gimple_non_addressable (lhs))
+ if (load_p && is_gimple_reg (lhs))
{
tmp = create_tmp_var (TREE_TYPE (lhs), NULL);
lhs_addr = build_fold_addr_expr (tmp);
Index: gimplify.c
===
--- gimplify.c (revision 182848)
+++ gimplify.c (working copy)
@@ -4411,7 +4411,9 @@ gimplify_modify_expr_rhs (tree *expr_p,
/* It's OK to use the target directly if it's being
initialized. */
use_target = true;
- else if (!is_gimple_non_addressable (*to_p))
+ else if (TREE_CODE (*to_p) != SSA_NAME
+ && (!is_gimple_variable (*to_p)
+ || needs_to_live_in_memory (*to_p)))
/* Don't use the original target if it's already addressable;
if its address escapes, and the called function uses the
NRV optimization, a conforming program could see *to_p
Index: gimple.c
===
--- gimple.c(revision 182848)
+++ gimple.c(working copy)
@@ -2963,17 +2963,6 @@ is_gimple_reg (tree t)
}
-/* Return true if T is a GIMPLE variable whose address is not needed. */
-
-bool
-is_gimple_non_addressable (tree t)
-{
- if (TREE_CODE (t) == SSA_NAME)
-t = SSA_NAME_VAR (t);
-
- return (is_gimple_variable (t) && ! needs_to_live_in_memory (t));
-}
-
/* Return true if T is a GIMPLE rvalue, i.e. an identifier or a constant. */
bool
Index: gimple.h
===
--- gimple.h(revision 182848)
+++ gimple.h(working copy)
@@ -1006,9 +1006,6 @@ extern bool is_gimple_mem_rhs (tree);
/* Returns true iff T is a valid if-statement condition. */
extern bool is_gimple_condexpr (tree);
-/* Returns true iff T is a variable that does not need to live in memory. */
-extern bool is_gimple_non_addressable (tree t);
-
/* Returns true iff T is a valid call address expression. */
extern bool is_gimple_call_addr (tree);
libiberty: Fix "make pdf" for copying-lib.texi
"make pdf" fails with:
libiberty/copying-lib.texi:481: This command can
appear only outside of any environment, not in environment @enumerate.
@badenverr ...temp , not @inenvironment @thisenv }
@checkenv ...@ifx @thisenv @temp @else @badenverr
@fi
@sectionheading #1#2#3#4->{@checkenv {}
@csname #2fonts@endcsname
@rmisbold @...
@\heading ...tionheading {#1}{sec}{Yomitfromtoc}{}
@suppressfirstparagraphin...
l.481 @heading NO WARRANTY
The patch below fixes the issue, but I am not sure whether the numbering
should continue with "15.". (Which is the current result in "info" or
when continuing with "enter".)
OK?
Tobias
PS: Does this need special care, e.g. for sourceware?
--- a/libiberty/copying-lib.texi
+++ b/libiberty/copying-lib.texi
@@ -475,6 +475,7 @@ Software Foundation; we sometimes make exceptions
for this. Our
decision will be guided by the two goals of preserving the free status
of all derivatives of our free software and of promoting the sharing
and reuse of software generally.
+@end enumerate
@iftex
@heading NO WARRANTY
@@ -483,6 +484,7 @@ and reuse of software generally.
@center NO WARRANTY
@end ifinfo
+@enumerate 15
@item
BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
Re: Find more shrink-wrapping opportunities
On 12/04/2011 01:27 PM, Richard Sandiford wrote: > OK, here it is. As well as switching to the backward scan and incremental > liveness updates, I added a test for another case that I stumbled over: > > /* Reject targets of abnormal edges. This is needed for correctness > on ports like Alpha and MIPS, whose pic_offset_table_rtx can die on > exception edges even though it is generally treated as call-saved > for the majority of the compilation. Moving across abnormal edges > isn't going to be interesting for shrink-wrap usage anyway. */ > if (live_edge->flags & EDGE_ABNORMAL) > return NULL; > > * sched-int.h (bb_note): Move to... > * basic-block.h: ...here. > * haifa-sched.c (bb_note): Move to... > * cfgrtl.c: ...here. > * function.c (next_block_for_reg): New function. > (move_insn_for_shrink_wrap): Likewise. > (prepare_shrink_wrap): Rewrite to use the above. Ok and thanks. Bernd
[PATCH, AVR] Fix PR target/50925, use hard_frame_pointer_rtx
Hi Georg. I have found that conversion AVR port to using hard_frame_pointer have resolved PR 50925 . I have tested the patch without regressions, but I'm worry about it. Can you test it with your testsuite for regressions ? May be you have your own special difficult tests (special for addressing) ? 2012-01-09 Richard Henderson Denis Chertykov PR target/50925 * config/avr/avr-protos.h (avr_hard_regno_nregs): Declare. * config/avr/avr.c (avr_can_eliminate): Simplify. (avr_initial_elimination_offset): Likewise. (avr_prologue_setup_frame): Use hard_frame_pointer_rtx. (expand_epilogue): Likewise. (avr_legitimize_address): Gut. (avr_legitimize_reload_address): Use hard_frame_pointer_rtx. (avr_hard_regno_nregs): New. (avr_hard_regno_ok): Allow only Pmode for arg and frame_pointers. (avr_regno_mode_code_ok_for_base_b): Handle arg and frame pointers. * config/avr/avr.h (FIXED_REGISTERS): Adjust arg pointer, add soft frame pointer. (CALL_USED_REGISTERS): Likewise. (REG_CLASS_CONTENTS): Likewise. (REGISTER_NAMES): Likewise. (HARD_REGNO_NREGS): Use avr_hard_regno_nregs. (HARD_FRAME_POINTER_REGNUM): New. (FRAME_POINTER_REGNUM): Use soft frame pointer. (ELIMINABLE_REGS): Eliminate from the soft frame pointer, remove the HARD_FRAME_POINTER self-elimination. Denis. avr-sfp-patch Description: Binary data
[PATCH][Graphite] Fix PR50561
We have two Graphite related release blockers for 4.7. The
following patch fixes the first one.
The asserts in
static inline ppl_dimension_type
psct_dynamic_dim (poly_bb_p pbb, graphite_dim_t level)
{
graphite_dim_t result = 1 + 2 * level;
gcc_assert (result < pbb_nb_scattering_transform (pbb));
return result;
}
static inline ppl_dimension_type
psct_static_dim (poly_bb_p pbb, graphite_dim_t level)
{
graphite_dim_t result = 2 * level;
gcc_assert (result < pbb_nb_scattering_transform (pbb));
return result;
}
are not consistent in case both a dynamic and static dimension should
always exist at the same time. Changing psct_dynamic_dim to use <=
fixes the issue.
Tobias, you are the only active(?) Graphite reviewer left.
Ok?
Thanks,
Richard.
2012-01-09 Richard Guenther
PR tree-optimization/50561
* graphite-poly.h (psct_dynamic_dim): Fix assert.
* gcc.dg/graphite/pr50561.c: New testcase.
Index: gcc/graphite-poly.h
===
--- gcc/graphite-poly.h (revision 183013)
+++ gcc/graphite-poly.h (working copy)
@@ -656,7 +656,7 @@ psct_dynamic_dim (poly_bb_p pbb, graphit
{
graphite_dim_t result = 1 + 2 * level;
- gcc_assert (result < pbb_nb_scattering_transform (pbb));
+ gcc_assert (result <= pbb_nb_scattering_transform (pbb));
return result;
}
Index: gcc/testsuite/gcc.dg/graphite/pr50561.c
===
--- gcc/testsuite/gcc.dg/graphite/pr50561.c (revision 0)
+++ gcc/testsuite/gcc.dg/graphite/pr50561.c (revision 0)
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -floop-flatten -floop-strip-mine" } */
+
+void f (unsigned *s)
+{
+ int n;
+ for (n = 0; n < 256; n++)
+s[n] = 0;
+}
Re: [Patch, Fortran] gfortran.texi: Update (C) year and F2003 status
On Mon, Jan 09, 2012 at 03:38:21PM +0100, Tobias Burnus wrote: > Ok for the trunk? (Build + "make pdf" tested) > > Tobias The two "which" clauses in the 1st sentence seem awkward. How about the following changes? OK, after considering the suggested changes. +@item Generic interface name which have the same name as derived types are comma between "name which" and "types are". +now supported, which allows to write constructor functions. Note that Change comma to period. s/which allows/This allows one/ +Fortran does not support static constructor functions. For static +variables, only default initialization or structure-constructor +initialization are available. The complete suggested change: @item Generic interface name, which have the same name as derived types, are now supported. This allows one to write constructor functions. Note that Fortran does not support static constructor functions. For static variables, only default initialization or structure-constructor initialization are available. -- Steve
[PATCH][Graphite]
This fixes the 2nd P1 ICE.
There is a disconnect on how we analyze data-references during SCOP
detection
(outermost_loop is the root of the loop tree) and during SESE-to-poly
where
outermost is determined by outermost_loop_in_sese_1 (). That influences
the SCEV result and thus we do not break the SCOP at a stmt we have to
break
it.
The following patch fixes this using a sledgehammer - require the
data-ref to be representable if analyzed with respect to all loops
it can nest in.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Ok?
Thanks,
Richard.
2012-01-09 Richard Guenther
PR tree-optimization/50913
* graphite-scop-detection.c (stmt_has_simple_data_refs_p):
Require data-refs to be representable by Graphite with respect
to any loop nest.
* gcc.dg/graphite/interchange-16.c: New testcase.
Index: gcc/graphite-scop-detection.c
===
--- gcc/graphite-scop-detection.c (revision 183013)
+++ gcc/graphite-scop-detection.c (working copy)
@@ -258,25 +258,33 @@ graphite_can_represent_expr (basic_block
Graphite. */
static bool
-stmt_has_simple_data_refs_p (loop_p outermost_loop, gimple stmt)
+stmt_has_simple_data_refs_p (loop_p outermost_loop ATTRIBUTE_UNUSED,
+gimple stmt)
{
data_reference_p dr;
unsigned i;
int j;
bool res = true;
- VEC (data_reference_p, heap) *drs = VEC_alloc (data_reference_p, heap, 5);
+ VEC (data_reference_p, heap) *drs = NULL;
+ loop_p outer;
- graphite_find_data_references_in_stmt (outermost_loop,
-loop_containing_stmt (stmt),
-stmt, &drs);
+ for (outer = loop_containing_stmt (stmt); outer; outer = loop_outer (outer))
+{
+ graphite_find_data_references_in_stmt (outer,
+loop_containing_stmt (stmt),
+stmt, &drs);
- FOR_EACH_VEC_ELT (data_reference_p, drs, j, dr)
-for (i = 0; i < DR_NUM_DIMENSIONS (dr); i++)
- if (!graphite_can_represent_scev (DR_ACCESS_FN (dr, i)))
- {
- res = false;
- goto done;
- }
+ FOR_EACH_VEC_ELT (data_reference_p, drs, j, dr)
+ for (i = 0; i < DR_NUM_DIMENSIONS (dr); i++)
+ if (!graphite_can_represent_scev (DR_ACCESS_FN (dr, i)))
+ {
+ res = false;
+ goto done;
+ }
+
+ free_data_refs (drs);
+ drs = NULL;
+}
done:
free_data_refs (drs);
Index: gcc/testsuite/gcc.dg/graphite/interchange-16.c
===
--- gcc/testsuite/gcc.dg/graphite/interchange-16.c (revision 0)
+++ gcc/testsuite/gcc.dg/graphite/interchange-16.c (revision 0)
@@ -0,0 +1,22 @@
+void spread_i1 (int *rptr, int *sptr, int ncopies, int *extent, int rdelta,
int m)
+{
+ int *dest;
+ int n;
+
+ while (m--)
+{
+ dest = rptr;
+ for (n = 0; n < ncopies; n ++)
+ {
+ *dest = *sptr;
+ dest += rdelta;
+ }
+ if (extent [n])
+ if (n)
+ rptr ++;
+}
+}
+
+int main() { return 0; }
+
+/* { dg-final { cleanup-tree-dump "graphite" } } */
Re: patch: remove is_gimple_non_addressable
On Mon, Jan 9, 2012 at 3:57 PM, Aldy Hernandez wrote: > >> Ok with simply excluding SSA_NAMEs like >> >> @@ -4411,16 +4411,27 @@ gimplify_modify_expr_rhs (tree *expr_p, >> /* It's OK to use the target directly if it's being >> initialized. */ >> use_target = true; >> - else if (TREE_CODE (*to_p) != SSA_NAME >> && ) >> - /* Don't use the original target if it's already >> addressable; >> - if its address escapes, and the called function uses >> the >> - NRV optimization, a conforming program could see *to_p >> - change before the called function returns; see >> c++/19317. >> - When optimizing, the return_slot pass marks more >> functions >> - as safe after we have escape info. */ >> - use_target = false; >> - else >> - use_target = true; >> >> as SSA_NAMEs can never become addressable during gimplification. > > > Ok, since I'm never quite 100% sure I'm following your suggestions... I'm > posting the final patch here. If tests pass, I'll commit. Yes, that looks fine. Thanks, Richard. > Thanks again.
Re: Unreviewed libffi, libgfortran, libitm patches
Richard Henderson writes: > On 01/04/2012 11:27 PM, Rainer Orth wrote: >> [libgfortran, libitm] Link with -shared-libgcc >> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01382.html >> >> This will need a fortran resp. libitm maintainer. > > Does the following alleviate the need for -shared-libgcc for libitm? As mentioned, it did and also passed regtesting on alpha-dec-osf5.1b, i386-pc-solaris2* and x86_64-unknown-linux-gnu. Would you mind committing the patch? Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Unreviewed^3 libffi patch
The following patch has remained unreviewed for almost a month now, despite two reminders: [libffi] Build 64-bit multilib for i?86-linux http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01011.html In the absence of a listed libffi maintainer (Anthony Green used to be listed in MAINTAINERS, but isn't anymore despite still taking care of upstream libffi), it probably needs a global reviewer. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Unreviewed^3 libffi patch
On 01/09/2012 04:09 PM, Rainer Orth wrote: > In the absence of a listed libffi maintainer (Anthony Green used to be > listed in MAINTAINERS, but isn't anymore despite still taking care of > upstream libffi), it probably needs a global reviewer. Sorry, I usually do it but missed this one. It's fine. Andrew.
[build] Check if linker supports R_386_TLS_GD_PLT, R_386_TLS_LDM_PLT relocs
While the combination of Sun as with GNU ld isn't a recommended configuration on Solaris, it used to work half a year ago, but doesn't right now: stage 1 libgomp fails to link: /vol/gcc/bin/gld-2.22: .libs/team.o: unrecognized relocation (0xc) in section `.text' /vol/gcc/bin/gld-2.22: final link failed: Bad value collect2: error: ld returned 1 exit status make[5]: *** [libgomp.la] Error 1 where 0xc is R_386_TLS_GD_PLT, which is supported by Sun as and ld, but not (yet) by gas and gld 2.22. The following patch makes sure that both assembler and linker support the relocation (and its companion, R_386_TLS_LDM_PLT) before using it. It allowed the bootstrap to complete successfully, will commit after a as/ld bootstrap to verify it. Rainer 2012-01-07 Rainer Orth * configure.ac (gcc_cv_as_ix86_tlsgdplt): Check if linker supports R_386_TLS_GD_PLT reloc. (gcc_cv_as_ix86_tlsldmplt): Check if linker supports R_386_TLS_LDM_PLT reloc. * configure: Regenerate. * config.in: Regenerate. # HG changeset patch # Parent f01ec6505a7e1cac52ec68541cc2a83ac9858320 Check if linker supports R_386_TLS_GD_PLT, R_386_TLS_LDM_PLT relocs diff --git a/gcc/configure.ac b/gcc/configure.ac --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -3674,15 +3674,25 @@ foo: nop gcc_GAS_CHECK_FEATURE([R_386_TLS_GD_PLT reloc], gcc_cv_as_ix86_tlsgdplt,,, - [calltls_gd@tlsgdplt],, + [calltls_gd@tlsgdplt], + [if test x$gcc_cv_ld != x \ + && $gcc_cv_ld -o conftest conftest.o -G > /dev/null 2>&1; then + gcc_cv_as_ix86_tlsgdplt=yes + fi + rm -f conftest], [AC_DEFINE(HAVE_AS_IX86_TLSGDPLT, 1, -[Define if your assembler supports @tlsgdplt.])]) +[Define if your assembler and linker support @tlsgdplt.])]) gcc_GAS_CHECK_FEATURE([R_386_TLS_LDM_PLT reloc], gcc_cv_as_ix86_tlsldmplt,,, - [calltls_ld@tlsldmplt],, + [calltls_ld@tlsldmplt], + [if test x$gcc_cv_ld != x \ + && $gcc_cv_ld -o conftest conftest.o -G > /dev/null 2>&1; then + gcc_cv_as_ix86_tlsldmplt=yes + fi + rm -f conftest], [AC_DEFINE(HAVE_AS_IX86_TLSLDMPLT, 1, -[Define if your assembler supports @tlsldmplt.])]) +[Define if your assembler and linker support @tlsldmplt.])]) ;; -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [build] Check if linker supports R_386_TLS_GD_PLT, R_386_TLS_LDM_PLT relocs
On 01/09/2012 05:14 PM, Rainer Orth wrote: While the combination of Sun as with GNU ld isn't a recommended configuration on Solaris, it used to work half a year ago, but doesn't right now: stage 1 libgomp fails to link: /vol/gcc/bin/gld-2.22: .libs/team.o: unrecognized relocation (0xc) in section `.text' /vol/gcc/bin/gld-2.22: final link failed: Bad value collect2: error: ld returned 1 exit status make[5]: *** [libgomp.la] Error 1 where 0xc is R_386_TLS_GD_PLT, which is supported by Sun as and ld, but not (yet) by gas and gld 2.22. The following patch makes sure that both assembler and linker support the relocation (and its companion, R_386_TLS_LDM_PLT) before using it. It allowed the bootstrap to complete successfully, will commit after a as/ld bootstrap to verify it. Ok. Paolo
Re: [RFC][libitm] Convert to c++11 atomics
On 01/02/2012 01:19 PM, Torvald Riegel wrote: On Tue, 2011-12-20 at 01:13 +0100, Torvald Riegel wrote: On Mon, 2011-12-19 at 15:17 -0800, Richard Henderson wrote: On 12/19/2011 02:58 PM, Torvald Riegel wrote: In the particular case (the validated loads technique used in method-gl.cc, load(), store(), and validate()), we actually do not need to have loads or stores to be really atomic, but need the compiler to treat them as if they were atomics wrt. to reordering etc. (e.g., wrt. adjacent fences). Right now, I'm relying on the fact that GCC doesn't optimize atomics yet and am just using nonatomic loads/stores. For 4.7, these accesses need to be volatile if they're to interact with the adjacent atomic ops. What do you mean by "interact"? AFAIU Andrew, currently atomics act as full optimization barriers, leaving nonatomic memory accesses in place somewhere between the surrounding atomic accesses. Andrew, can you please comment on this? Thats true until you get to RTL patterns. once the atomics are expanded to RTL, they are no longer function calls, but are rtl patterns flagged as instructions with volatile memory references or something like that. (Im not as 'up' on the RTl side of things...)This prevents the rtl optimizations from doing much with them, WHEN they are related at least. Im not sure exactly where he is coming from, but my guess is that if you want those "non-atomic" unrelated loads and stores to never be moved around past atomics, (especially relaxed atomics), they have to look like atomics and thats accomplished by being volatile in RTL... (Im guessing and tp dancing a bit here :-) any reason you can't just make those loads/stores relaxed atomics? Andrew
Re: [PATCH, ARM] Fix stack red zone bug (PR38644) for GCC 4.6
On 9 January 2012 08:49, Sebastian Huber wrote: > What is missing to get this ported back to the GCC 4.6 branch? I ran a sanity check again today and backported them to the 4.6 branch. Sorry about the delay. I prefer to do the same for the 4.4 and 4.5 branches. If you are happy to test them then I'm ok with doing the backports. Thanks Ramana > > > On 12/21/2011 09:10 AM, Sebastian Huber wrote: >> >> Would someone mind committing this to the 4.6 branch. Thanks. >> >> The test suite results are only missing for the 4.4 and 4.5 branch. >> > -- > Sebastian Huber, embedded brains GmbH > > Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany > Phone : +49 89 18 90 80 79-6 > Fax : +49 89 18 90 80 79-9 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [PATCH, AVR] Fix PR target/50925, use hard_frame_pointer_rtx
Denis Chertykov wrote: > Hi Georg. > > I have found that conversion AVR port to using hard_frame_pointer have > resolved PR 50925 . > I have tested the patch without regressions, but I'm worry about it. > Can you test it with your testsuite for regressions ? > May be you have your own special difficult tests (special for addressing) ? Hi Denis. My test suite is plain vanilla, there are no special test cases that are not upstream. So you should get the same test results.
Ping [ARM back-end and middle-end patch] stack check for threads
Hello Even if I'm going to bore everyone. Is it possible to get an answer from the ARM maintainers? This is a serious question, and I hope there will be a serious answer. Regards Thomas Klein reference: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01774.html
[PATCH, i386]: Optimize AND with 0xffffffff
Hello!
Attached patch fixes oversight with AND pattern and 0x
immediate. While ANDs with 0xff and 0x are converted to equivalent
zero_extend pattern, AND with 0x isn't. This problem leaves
important optimization that would substitute "movq%rdi, %rax; andl
$4294967295, %eax" sequence with "movl %edi, %eax" ineffective.
This optimization happens ~100 times in cc1.
Moving to stage4 got me by a bit of surprise (I was away from the
keyboard for the weekend), so I will leave to RMs if this (otherwise
fairly safe patch) is OK for mainline.
2012-01-09 Uros Bizjak
PR target/51681
* config/i386/constraints.md ("L"): Return true for 0x.
* config/i386/i386.c (*anddi_1): Emit AND with 0x as MOV.
So, OK for mainline?
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 183014)
+++ config/i386/i386.md (working copy)
@@ -7678,19 +7678,23 @@
enum machine_mode mode;
gcc_assert (CONST_INT_P (operands[2]));
-if (INTVAL (operands[2]) == 0xff)
- mode = QImode;
+ if (INTVAL (operands[2]) == (HOST_WIDE_INT) 0x)
+ mode = SImode;
+ else if (INTVAL (operands[2]) == 0x)
+ mode = HImode;
else
{
- gcc_assert (INTVAL (operands[2]) == 0x);
- mode = HImode;
+ gcc_assert (INTVAL (operands[2]) == 0xff);
+ mode = QImode;
}
operands[1] = gen_lowpart (mode, operands[1]);
- if (mode == QImode)
+ if (mode == SImode)
+ return "mov{l}\t{%1, %k0|%k0, %1}";
+ else if (mode == HImode)
+ return "movz{wl|x}\t{%1, %k0|%k0, %1}";
+ else
return "movz{bl|x}\t{%1, %k0|%k0, %1}";
- else
- return "movz{wl|x}\t{%1, %k0|%k0, %1}";
}
default:
@@ -7726,19 +7730,19 @@
enum machine_mode mode;
gcc_assert (CONST_INT_P (operands[2]));
-if (INTVAL (operands[2]) == 0xff)
- mode = QImode;
+if (INTVAL (operands[2]) == 0x)
+ mode = HImode;
else
{
- gcc_assert (INTVAL (operands[2]) == 0x);
- mode = HImode;
+ gcc_assert (INTVAL (operands[2]) == 0xff);
+ mode = QImode;
}
operands[1] = gen_lowpart (mode, operands[1]);
- if (mode == QImode)
+ if (mode == HImode)
+ return "movz{wl|x}\t{%1, %0|%0, %1}";
+ else
return "movz{bl|x}\t{%1, %0|%0, %1}";
- else
- return "movz{wl|x}\t{%1, %0|%0, %1}";
}
default:
Index: config/i386/constraints.md
===
--- config/i386/constraints.md (revision 183014)
+++ config/i386/constraints.md (working copy)
@@ -149,9 +149,11 @@
(match_test "IN_RANGE (ival, -128, 127)")))
(define_constraint "L"
- "@code{0xFF} or @code{0x}, for andsi as a zero-extending move."
+ "@code{0xFF}, @code{0x} or @code{0x}
+ for AND as a zero-extending move."
(and (match_code "const_int")
- (match_test "ival == 0xFF || ival == 0x")))
+ (match_test "ival == 0xff || ival == 0x
+ || ival == (HOST_WIDE_INT) 0x")))
(define_constraint "M"
"0, 1, 2, or 3 (shifts for the @code{lea} instruction)."
[SPARC] Small tweak to Solaris unwinder
On the recent Solaris 10 version I have access to (s10_72), the kernel/libc sometimes calls the call_user_handler routines with a null returned address. This is responsible for the last ACATS failure (cb1010c). But, in most cases, the address is the expected one, so it isn't clear if this is a bug or not. Tested on Solaris 8, 9 and 10, applied on mainline, 4.6 and 4.5 branches. 2012-01-09 Eric Botcazou * config/sparc/sol2-unwind.h (sparc64_is_sighandler): Check that the purported sigacthandler address isn't null before dereferencing it. (sparc_is_sighandler): Likewise. -- Eric Botcazou Index: config/sparc/sol2-unwind.h === --- config/sparc/sol2-unwind.h (revision 183005) +++ config/sparc/sol2-unwind.h (working copy) @@ -124,10 +124,9 @@ sparc64_is_sighandler (unsigned int *pc, /* This matches the call_user_handler pattern for Solaris 10. There are 2 cases so we look for the return address of the caller's caller frame in order to do more pattern matching. */ - unsigned int sah_pattern - = *(unsigned int *)(*(unsigned long *)(cfa + 176 + 15*8) - 4); + unsigned long sah_address = *(unsigned long *)(cfa + 176 + 15*8); - if (sah_pattern == 0x92100019) + if (sah_address && *(unsigned int *)(sah_address - 4) == 0x92100019) /* This is the same setup as for Solaris 9, see below. */ *nframes = 3; else @@ -302,10 +301,9 @@ sparc_is_sighandler (unsigned int *pc, v /* This matches the call_user_handler pattern for Solaris 10. There are 2 cases so we look for the return address of the caller's caller frame in order to do more pattern matching. */ - unsigned int sah_pattern - = *(unsigned int *)(*(unsigned int *)(cfa + 96 + 15*4) - 4); + unsigned int sah_address = *(unsigned int *)(cfa + 96 + 15*4); - if (sah_pattern == 0x92100019) + if (sah_address && *(unsigned int *)(sah_address - 4) == 0x92100019) /* This is the same setup as for Solaris 9, see below. */ *nframes = 3; else
Re: [libitm] Port to ARM
> To get the ball rolling for other targets, and to let port maintainers see > how easy it really is, here's a first cut at a port to ARM. Do you plan to do something for the SPARC? I'm asking because you still are a maintainer of this arch as well, so if we can avoid doing the work twice... -- Eric Botcazou
Re: [Patch, Fortran] PR 51758 - fix ICE with null() in elemental procedures
On 09.01.2012 15:45, Tobias Burnus wrote:
On 01/09/2012 03:34 PM, Mikael Morin wrote:
The issue is that the code handling NULL() doesn't consume the gfc_ss
struct created for it. Your fix, which advances to the next one anyway
would work just well, but I think it is slightly cleaner to not create
the struct in the first place, as it is unused.
I'm currently regtesting the following patch. The testcase is the same
as your. OK for 4.7/4.6?
OK.
For the test case, either take mine or don't forget to enable all "if()
abort"s and to change in the last "! print *,a" the "a" into a "b".
+ if (!arg->expr
+ || arg->expr->expr_type == EXPR_NULL)
continue;
(I'd prefer to have no line break before the "||".)
Tobias
Thanks. Committed.
Mikael
Index: testsuite/gfortran.dg/optional_absent_2.f90
===
--- testsuite/gfortran.dg/optional_absent_2.f90 (révision 0)
+++ testsuite/gfortran.dg/optional_absent_2.f90 (révision 183024)
@@ -0,0 +1,53 @@
+! { dg-do run }
+!
+! PR fortran/51758
+!
+! Contributed by Mikael Morin
+!
+! Check whether passing NULL() to an elemental procedure works,
+! where NULL() denotes an absent optional argument.
+!
+program p
+
+ integer :: a(2)
+ integer :: b
+
+ a = 0
+ a = foo((/ 1, 1 /), null())
+! print *, a
+ if (any(a /= 2)) call abort
+
+ a = 0
+ a = bar((/ 1, 1 /), null())
+! print *, a
+ if (any(a /= 2)) call abort
+
+ b = 0
+ b = bar(1, null())
+! print *, b
+ if (b /= 2) call abort
+
+contains
+
+ function foo(a, b)
+integer :: a(:)
+integer, optional :: b(:)
+integer :: foo(size(a))
+
+if (present(b)) call abort
+
+foo = 2
+ end function foo
+
+ elemental function bar(a, b)
+integer, intent(in) :: a
+integer, intent(in), optional :: b
+integer :: bar
+
+bar = 2
+
+if (present(b)) bar = 1
+
+ end function bar
+
+end program p
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (révision 183023)
+++ testsuite/ChangeLog (révision 183024)
@@ -1,5 +1,10 @@
2012-01-09 Tobias Burnus
+ PR fortran/51758
+ * gfortran.dg/optional_absent_2.f90: New.
+
+2012-01-09 Tobias Burnus
+
PR fortran/51578
* gfortran.dg/use_17.f90: New.
Index: fortran/trans-array.c
===
--- fortran/trans-array.c (révision 183023)
+++ fortran/trans-array.c (révision 183024)
@@ -8369,7 +8369,7 @@ gfc_walk_elemental_function_args (gfc_ss * ss, gfc
scalar = 1;
for (; arg; arg = arg->next)
{
- if (!arg->expr)
+ if (!arg->expr || arg->expr->expr_type == EXPR_NULL)
continue;
newss = gfc_walk_subexpr (head, arg->expr);
Index: fortran/ChangeLog
===
--- fortran/ChangeLog (révision 183023)
+++ fortran/ChangeLog (révision 183024)
@@ -1,3 +1,9 @@
+2012-01-09 Mikael Morin
+
+ PR fortran/51758
+ * trans-array.c (gfc_walk_elemental_function_args):
+ Skip over NULL() actual arguments.
+
2012-01-09 Tobias Burnus
* gfortran.texi: Bump copyright year.
Re: [PATCH] [MIPS] Add Octeon2 cpu support to GCC
Gerald Pfeifer writes: > On Wed, 4 Jan 2012, Andrew Pinski wrote: >> Woops, I had missed that. Here is the patch which adds both octeon+ >> and octeon2 to that list. >> >> I committed as obvious after a build. > > You may want to update the release notes as well > (htdocs/gcc-4.7/changes.html). FWIW, I'm planning to do a sweep of MIPS changes in time for 4.7. (I prefer to write them all at once, although I realise there are good arguments for doing them as soon as the patch goes in.) Richard
[Patch, Fortran] PR51197 - print signal number before backtrace [RFC]
Hello,
in GCC 4.6, gfortran printed before the backtrace, e.g.,
Program received signal 8 (SIGFPE): Floating-point exception.
to STDERR followed by the backtrace.
This was done by registering an error handler and - finishing with a
sys_exit(5). Since 4.7 with the patch for PR 48915 (comment 3) [1], GCC
does no longer print this line but just a simple:
A fatal error occurred! Backtrace for this error:
followed by the the backtrace. It then raises the signal via the default
handler. (The system might then print more information, e.g. "Floating
point exception (core dumped)", which might end up on STDOUT contrary to
the backtrace which goes to STDERR.)
[1] Cf. runtime/compile_options.c at
http://gcc.gnu.org/viewcvs?view=revision&revision=173750
The attached patch by Harald Anlauf (cf. PR, minutely modified by me)
restores GCC 4.6's printing of the signal number by simply printing this
information before the back trace. (Copyright wise, the patch is simple
even as it exceeds ten lines: it mostly undoes part of Rev. 173750 [1].)
With the patch, one can get (cf. PR) an output to STDERR like:
Program received signal 8 (SIGFPE): Floating-point exception.
Backtrace for this error:
#0 0x805891F in _gfortrani_show_backtrace at backtrace.c:261
#1 0x804951F in _gfortrani_backtrace_handler at compile_options.c:93
#2 0xE3FF
#3 0x80493B3 in foo at gfcbug113.f90:8
#4 0x804940B in backtrace at gfcbug113.f90:3
which might be followed by the OS diagnostic, e.g. on Linux with a Bash
one gets the following to STDOUT:
Floating point exception (core dumped)
OK for the trunk?
Tobias
2012-01-09 Harald Anlauf
Tobias Burnus
PR fortran/51197
* runtime/backtrace.c (show_backtrace): Modify wording written
before the backtrace.
* runtime/compile_options.c (show_signal): New function.
(backtrace_handler): Use it.
diff --git a/libgfortran/runtime/backtrace.c b/libgfortran/runtime/backtrace.c
index e28bdcb..bb335e4 100644
--- a/libgfortran/runtime/backtrace.c
+++ b/libgfortran/runtime/backtrace.c
@@ -195,11 +195,11 @@ show_backtrace (void)
{
bt_state state;
state.frame_number = 0;
state.error = 0;
- estr_write ("\nA fatal error occurred! Backtrace for this error:\n");
+ estr_write ("\nBacktrace for this error:\n");
#if CAN_PIPE
if (addr2line_path == NULL)
goto fallback_noerr;
diff --git a/libgfortran/runtime/compile_options.c b/libgfortran/runtime/compile_options.c
index 0c139a2..aadd7eb 100644
--- a/libgfortran/runtime/compile_options.c
+++ b/libgfortran/runtime/compile_options.c
@@ -30,10 +30,56 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
compile_options_t compile_options;
volatile sig_atomic_t fatal_error_in_progress = 0;
+
+/* Helper function for backtrace_handler to write information about the
+ received signal to stderr before actually giving the backtrace. */
+static void
+show_signal (int signum)
+{
+ const char * name = NULL, * desc = NULL;
+
+ switch (signum)
+{
+#if defined(SIGSEGV)
+ case SIGSEGV:
+ name = "SIGSEGV";
+ desc = "Segmentation fault";
+ break;
+#endif
+
+#if defined(SIGBUS)
+ case SIGBUS:
+ name = "SIGBUS";
+ desc = "Bus error";
+ break;
+#endif
+
+#if defined(SIGILL)
+ case SIGILL:
+ name = "SIGILL";
+ desc = "Illegal instruction";
+ break;
+#endif
+
+#if defined(SIGFPE)
+ case SIGFPE:
+ name = "SIGFPE";
+ desc = "Floating-point exception";
+ break;
+#endif
+}
+
+ if (name)
+st_printf ("\nProgram received signal %d (%s): %s.\n", signum, name, desc);
+ else
+st_printf ("\nProgram received signal %d.\n", signum);
+}
+
+
/* A signal handler to allow us to output a backtrace. */
void
backtrace_handler (int signum)
{
/* Since this handler is established for more than one kind of signal,
@@ -41,10 +87,11 @@ backtrace_handler (int signum)
of signal. Use a static variable to keep track of that. */
if (fatal_error_in_progress)
raise (signum);
fatal_error_in_progress = 1;
+ show_signal (signum);
show_backtrace();
/* Now reraise the signal. We reactivate the signal's
default handling, which is to terminate the process.
We could just call exit or abort,
Re: [PING] [wwwdocs] - changes to GUPC page
Is it ok to make this update to the web page? Someone has to approve this change, even though it is GUPC specific. Nenad ? A Index: htdocs/projects/gupc.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/gupc.html,v retrieving revision 1.5 diff -u -r1.5 gupc.html --- htdocs/projects/gupc.html 31 Dec 2010 11:36:07 - 1.5 +++ htdocs/projects/gupc.html 9 Jan 2012 19:20:17 - @@ -68,7 +68,7 @@ Intel x86 Linux uniprocessor and symmetric multiprocessor systems (CentOS 5.3) Intel x86 Apple Mac OS X uniprocessor and symmetric multiprocessor -systems (Leopard 10.5.7+ and Snow Leopard 10.6) +systems (Leopard 10.5.7+, Snow Leopard 10.6, and Lion 10.7) Mips2 32-bit (-n32) ABI and mips4 64-bit (-n64) ABI (SGI IRIX 6.5) Cray XT3/4/5 CNL and Catamount As a front-end to the Berkeley UPC Berkeley UPC runtime @@ -81,6 +81,18 @@ GUPC discussion list. +Download + +The latest release of GUPC can be downloaded from http://www.gccupc.org/downloads.html";>gccupc.org. + + +Alternatively, read-only SVN access to the GUPC branch can be used to +acquire the latest development source tree: + + +svn checkout svn://gcc.gnu.org/svn/gcc/branches/gupc + Documentation For a list of configuration switches that you can use to build GUPC, consult
[Ada] Fix old thinko
This very likely has no consequence in release mode, but you can get ICES with tree checking enabled in some perculiar cases and on some platforms. Tested on i586-suse-linux, applied on the mainline, 4.6 and 4.5 branches. 2012-01-09 Eric Botcazou * gcc-interface/trans.c (addressable_p) : Fix thinko. -- Eric Botcazou Index: gcc-interface/trans.c === --- gcc-interface/trans.c (revision 182780) +++ gcc-interface/trans.c (working copy) @@ -8403,7 +8403,7 @@ addressable_p (tree gnu_expr, tree gnu_t || DECL_ALIGN (TREE_OPERAND (gnu_expr, 1)) >= TYPE_ALIGN (TREE_TYPE (gnu_expr /* The field of a padding record is always addressable. */ - || TYPE_PADDING_P (TREE_TYPE (TREE_OPERAND (gnu_expr, 0 + || TYPE_IS_PADDING_P (TREE_TYPE (TREE_OPERAND (gnu_expr, 0 && addressable_p (TREE_OPERAND (gnu_expr, 0), NULL_TREE)); case ARRAY_REF: case ARRAY_RANGE_REF:
Re: [SPARC] Small tweak to Solaris unwinder
Eric Botcazou writes: > On the recent Solaris 10 version I have access to (s10_72), the kernel/libc s10_72 is anything but recent: this is a Solaris 10 Express/Beta build which even predates Solaris 10 FCS (s10_74L2a), so this is ancient history by now. I suggest not caring about anything pre-FCS by now. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Patch, Fortran] PR51197 - print signal number before backtrace [RFC]
On Mon, Jan 09, 2012 at 08:21:31PM +0100, Tobias Burnus wrote: > > With the patch, one can get (cf. PR) an output to STDERR like: > > Program received signal 8 (SIGFPE): Floating-point exception. > > Backtrace for this error: > #0 0x805891F in _gfortrani_show_backtrace at backtrace.c:261 > #1 0x804951F in _gfortrani_backtrace_handler at compile_options.c:93 > #2 0xE3FF > #3 0x80493B3 in foo at gfcbug113.f90:8 > #4 0x804940B in backtrace at gfcbug113.f90:3 > > > which might be followed by the OS diagnostic, e.g. on Linux with a Bash > one gets the following to STDOUT: > > Floating point exception (core dumped) > > OK for the trunk? > OK. -- Steve
Re: [PATCH] PR51471. Don't speculate frame-related insns during delayed branch scheduling.
Tom de Vries writes: > 2012-01-08 Tom de Vries > Andrew Pinski > > * reorg.c (fill_slots_from_thread): Don't speculate frame-related insns. OK, thanks. Richard
Re: [Patch, fortran] PR51791 - [OOP] Failure to resolve typebound function call with base object in parentheses
Dear All,
Committed as r183032.
Thanks
Paul
On Sun, Jan 8, 2012 at 10:32 PM, Tobias Burnus wrote:
> Dear Paul,
>
> Paul Richard Thomas:
>
>> A question for the standard aficianados: Are there other base object
>> expressions that are legal?
>
>
> I don't think so. (Ignoring RESHAPE, SPREAD etc., cf. PR 47505.)
>
>
>> Bootstrapped and regtested on FC9/x86_64 - OK for trunk?
>
>
> OK. Thanks for the patch.
>
>> *** resolve_ordinary_assign (gfc_code *code,
>> *** 9208,9215
>> ! gfc_error ("Variable must not be polymorphic in assignment at %L",
>> ! &lhs->where);
>> --- 9208,9216
>> ! gfc_error ("Variable must not be polymorphic in assignment at %L "
>> ! "- check that there is a matching specific subroutine "
>> ! "for '=' operator",&lhs->where);
>
>
> I have to admit that I like the initial wording better - with "in
> assignment" changed to "in intrinsic assignment". (In F2008, I would even
> write: "Nonallocatable variable", but gfortran does not yet support
> allocatable with intrinsic assignments.)
>
> (By the way, there is no matching defined assignment - no need for the users
> to check whether there is one; they only need to check why there is none ;-)
>
> Tobias
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
Re: [Patch, Fortran] PR51197 - print signal number before backtrace [RFC]
On Mon, Jan 9, 2012 at 21:21, Tobias Burnus wrote: > Hello, > > in GCC 4.6, gfortran printed before the backtrace, e.g., > Program received signal 8 (SIGFPE): Floating-point exception. > to STDERR followed by the backtrace. > > This was done by registering an error handler and - finishing with a > sys_exit(5). Since 4.7 with the patch for PR 48915 (comment 3) [1], GCC does > no longer print this line but just a simple: > A fatal error occurred! Backtrace for this error: > followed by the the backtrace. It then raises the signal via the default > handler. (The system might then print more information, e.g. "Floating point > exception (core dumped)", which might end up on STDOUT contrary to the > backtrace which goes to STDERR.) > > [1] Cf. runtime/compile_options.c at > http://gcc.gnu.org/viewcvs?view=revision&revision=173750 > > The attached patch by Harald Anlauf (cf. PR, minutely modified by me) > restores GCC 4.6's printing of the signal number by simply printing this > information before the back trace. (Copyright wise, the patch is simple even > as it exceeds ten lines: it mostly undoes part of Rev. 173750 [1].) > > With the patch, one can get (cf. PR) an output to STDERR like: > > Program received signal 8 (SIGFPE): Floating-point exception. > > Backtrace for this error: > #0 0x805891F in _gfortrani_show_backtrace at backtrace.c:261 > #1 0x804951F in _gfortrani_backtrace_handler at compile_options.c:93 > #2 0xE3FF > #3 0x80493B3 in foo at gfcbug113.f90:8 > #4 0x804940B in backtrace at gfcbug113.f90:3 > > > which might be followed by the OS diagnostic, e.g. on Linux with a Bash one > gets the following to STDOUT: > > Floating point exception (core dumped) > > > OK for the trunk? I see this was already Ok'ed, but still a few comments: - The integer values for the signal numbers are not standardized, hence printing them might give the user a false impression that these numbers convey some information beyond whichever SIG* macro they map to on that particular target. - It doesn't test all the signals which are actually handled, see compile_options.c:set_options(). Also, as a minor point, there's no need to have #ifdef tests for the C89 signals, again see set_options(). - The floor is now open for some enterprising person to file a bug complaining that duplicate information is printed when, as usual, stdout and stderr are output to the same device. ;-) -- Janne Blomqvist
[Patch,AVR]: ad PR49868: Extend __pgmx semantics to flatten memory
This patch extends the semantics of 24-bit __pgmx address space qualifier to cover RAM and Flash. RAM is represented by setting the high byte of 24-bit address to 0x80. The code to read from 24-bit address space decides at runtime what instruction to use to read by if-else decision depending on bit 23 of the address, i.e. the code looks like. if address.23 return LD reg, Z // read from RAM else if have RAMPZ RAMPZ = address.msb return LPM reg, Z // read from Flash The code in avr.c actually gets simpler because more work is shifted to libgcc as the code to emit gets more complex. Moreover, there is better separation of 16-bit address spaces and 24-bit address spaces because even on small devices with just 1 flash segment 24-bit pointers make sense now. Ok for trunk? This should be the last patch for 4.7 from my side that adds new functionality, so that all what remains is documentation and release note updates, test cases and bug fixes. Unfortunately, the address space implementation in GCC is odd from the user perspective, in particular when dealing with literals. Johann libgcc/ PR target/49868 Extend __pgmx semantics to linearize memory. * config/avr/t-avr (LIB1ASMFUNCS): Add _xload_1, _movmemx. * config/avr/lib1funcs.S (__xload_1): New function. (__movmemx_qi, __movmemx_hi): New functions. (__xload_2, __xload_3, __xload_4): Rewrite to fit new __pgmx semantics. gcc/ PR target/49868 Extend __pgmx semantics to linearize memory. * config/avr/avr.md (mov): Use avr_xload_libgcc_p to determine if code comes inline or from libgcc. (MOVMEM_r_d:HI): Add "w" to constraint for better preference. (movmem_qi, movmem_qi): Set constraint #2 to "n". (movmem_qi_elpm, movmem_hi_elpm): Remove insns. (movmemx_qi, movmemx_hi): New insns. (xload__libgcc): Rewrite to new insn condition. (xload_): Remove insns. * config/avr/avr.c (avr_out_xload): Rewrite: Only need to handle cases that don't satisfy avr_xload_libgcc_p(). (avr_addr_space_convert): Allow converting in any direction. (avr_addr_space_subset_p): Return always true. (avr_xload_libgcc_p): Rewrite to fit new __pgmx semantics. (avr_emit_movmemhi): Ditto. (avr_out_lpm): No need to handle ADDR_SPACE_PGMX any more. (avr_out_movmem): Ditto. (AVR_SYMBOL_FLAG_PROGMEM): New macro. (AVR_SYMBOL_SET_ADDR_SPACE): New macro. (AVR_SYMBOL_GET_ADDR_SPACE): New macro. (avr_encode_section_info): Encode 'progmem' in symbol flags. (output_reload_in_const): Don't zero-extend any 24-bit symbols. Index: libgcc/config/avr/lib1funcs.S === --- libgcc/config/avr/lib1funcs.S (revision 182797) +++ libgcc/config/avr/lib1funcs.S (working copy) @@ -2061,19 +2061,14 @@ ENDF __load_4 #endif /* L_load_3 || L_load_3 */ ;;; -;; Loading n bytes from Flash; n = 2,3,4 -;; R22... = Flash[R21:Z] +;; Loading n bytes from Flash or RAM; n = 1,2,3,4 +;; R22... = Flash[R21:Z] or RAM[Z] depending on R21.7 ;; Clobbers: __tmp_reg__, R21, R30, R31 -#if (defined (L_xload_2)\ +#if (defined (L_xload_1)\ + || defined (L_xload_2) \ || defined (L_xload_3) \ - || defined (L_xload_4))\ -&& defined (__AVR_HAVE_ELPM__) \ -&& !defined (__AVR_HAVE_ELPMX__) - -#if !defined (__AVR_HAVE_RAMPZ__) -#error Need RAMPZ -#endif /* have RAMPZ */ + || defined (L_xload_4)) ;; Destination #define D0 22 @@ -2086,6 +2081,9 @@ ENDF __load_4 #define HHI8 21 .macro .xload dest, n +#if defined (__AVR_HAVE_ELPMX__) +elpm\dest, Z+ +#elif defined (__AVR_HAVE_ELPM__) elpm mov \dest, r0 .if \dest != D0+\n-1 @@ -2093,39 +2091,161 @@ ENDF __load_4 adc HHI8, __zero_reg__ out __RAMPZ__, HHI8 .endif -.endm +#elif defined (__AVR_HAVE_LPMX__) +lpm \dest, Z+ +#else +lpm +mov \dest, r0 +.if \dest != D0+\n-1 +adiwr30, 1 +.endif +#endif +.endm ; .xload + +#if defined (L_xload_1) +DEFUN __xload_1 +#if defined (__AVR_HAVE_LPMX__) && !defined (__AVR_HAVE_RAMPZ__) +ld D0, Z +sbrsHHI8, 7 +lpm D0, Z +ret +#else +sbrcHHI8, 7 +rjmp1f +#if defined (__AVR_HAVE_RAMPZ__) +out __RAMPZ__, HHI8 +#endif /* __AVR_HAVE_RAMPZ__ */ +.xload D0, 1 +ret +1: ld D0, Z +ret +#endif /* LPMx && ! RAMPZ */ +ENDF __xload_1 +#endif /* L_xload_1 */ #if defined (L_xload_2) DEFUN __xload_2 +sbrcHHI8, 7 +rjmp1f +#if defined (__AVR_HAVE_RAMPZ__) out __RAMPZ__, HHI8 -.xload D0, 2 -.xload D1, 2 +#endif /* __AVR_HAVE_RAMPZ__ */ +.xload D0, 2 +.xload D1, 2 +ret +1: ld D0, Z+ +ld D1, Z+ ret ENDF __xload_2 #endif /* L_xl
[Ada] Fix ICE on function call returning dynamic array
This is a regression present on the mainline. It occurs only when the return
value is assigned to an array with fixed size (this is possible with subtypes
of the same unconstrained array type).
Tested on i586-suse-linux, applied on the mainline.
2012-01-09 Eric Botcazou
* gcc-interface/trans.c (call_to_gnu): Create the temporary for the
return value in the variable-sized return type case if the target is
an array with fixed size. However, do not create it if this is the
expression of an object declaration.
2012-01-09 Eric Botcazou
* gnat.dg/array18.adb: New test.
* gnat.dg/array18_pkg.ads: New helper.
--
Eric Botcazou
-- { dg-do compile }
with Array18_Pkg; use Array18_Pkg;
procedure Array18 is
A : String (1 .. 1);
begin
A := F;
end;
package Array18_Pkg is
function N return Positive;
subtype S is String (1 .. N);
function F return S;
end Array18_Pkg;
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 183025)
+++ gcc-interface/trans.c (working copy)
@@ -3631,15 +3631,22 @@ call_to_gnu (Node_Id gnat_node, tree *gn
}
/* First, create the temporary for the return value if we need it: for a
- variable-sized return type if there is no target or if this is slice,
- because the gimplifier doesn't support these cases; or for a function
- with copy-in/copy-out parameters if there is no target, because we'll
- need to preserve the return value before copying back the parameters.
- This must be done before we push a new binding level around the call
- as we will pop it before copying the return value. */
+ variable-sized return type if there is no target and this is not an
+ object declaration, or else there is a target and it is a slice or an
+ array with fixed size, as the gimplifier doesn't handle these cases;
+ otherwise for a function with copy-in/copy-out parameters if there is
+ no target, because we need to preserve the return value before copying
+ back the parameters. This must be done before we push a binding level
+ around the call as we will pop it before copying the return value. */
if (function_call
&& ((TREE_CODE (TYPE_SIZE (gnu_result_type)) != INTEGER_CST
- && (!gnu_target || TREE_CODE (gnu_target) == ARRAY_RANGE_REF))
+ && ((!gnu_target
+ && Nkind (Parent (gnat_node)) != N_Object_Declaration)
+ || (gnu_target
+ && (TREE_CODE (gnu_target) == ARRAY_RANGE_REF
+ || (TREE_CODE (TREE_TYPE (gnu_target)) == ARRAY_TYPE
+ && TREE_CODE (TYPE_SIZE (TREE_TYPE (gnu_target)))
+ == INTEGER_CST)
|| (!gnu_target && TYPE_CI_CO_LIST (gnu_subprog_type
gnu_retval = create_temporary ("R", gnu_result_type);
[PATCH] Fix some powerpc debug options
I was recently trying to turn on some of the debug options I put in when doing
the initial power7 work to track down some performance regressions. The
following patches fix problems that come up in telling the compiler to use the
traditional floating point insns for scalar mode on power7
(-mno-vsx-scalar-double). It also adds reload helpers for using the VSX memory
load instructions when the compiler is allowed to use VSX memory instructions
for scalars. There were no regressions with these patches. Are they ok to be
checked in?
2012-01-09 Michael Meissner
* config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Add DF
reload patterns if -mvsx-scalar-memory.
* config/rs6000/vsx.md (vsx_xscvspdp): Allow xscvspdp to be
generated, even -mno-vsx-scalar-double was used.
(vsx_xscvdpsp_scalar): Likewise.
(vsx_xscvspdp_scalar2): Likewise.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 183033)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -1,6 +1,7 @@
/* Subroutines used for code generation on IBM RS/6000.
Copyright (C) 1991, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
- 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
+ 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,
+ 2012
Free Software Foundation, Inc.
Contributed by Richard Kenner (ken...@vlsi1.ultra.nyu.edu)
@@ -2332,6 +2333,11 @@ rs6000_init_hard_regno_mode_ok (bool glo
rs6000_vector_reload[V4SFmode][1] = CODE_FOR_reload_v4sf_di_load;
rs6000_vector_reload[V2DFmode][0] = CODE_FOR_reload_v2df_di_store;
rs6000_vector_reload[V2DFmode][1] = CODE_FOR_reload_v2df_di_load;
+ if (TARGET_VSX && TARGET_VSX_SCALAR_MEMORY)
+ {
+ rs6000_vector_reload[DFmode][0] = CODE_FOR_reload_df_di_store;
+ rs6000_vector_reload[DFmode][1] = CODE_FOR_reload_df_di_load;
+ }
}
else
{
@@ -2347,6 +2353,11 @@ rs6000_init_hard_regno_mode_ok (bool glo
rs6000_vector_reload[V4SFmode][1] = CODE_FOR_reload_v4sf_si_load;
rs6000_vector_reload[V2DFmode][0] = CODE_FOR_reload_v2df_si_store;
rs6000_vector_reload[V2DFmode][1] = CODE_FOR_reload_v2df_si_load;
+ if (TARGET_VSX && TARGET_VSX_SCALAR_MEMORY)
+ {
+ rs6000_vector_reload[DFmode][0] = CODE_FOR_reload_df_si_store;
+ rs6000_vector_reload[DFmode][1] = CODE_FOR_reload_df_si_load;
+ }
}
}
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 183033)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -1,5 +1,5 @@
;; VSX patterns.
-;; Copyright (C) 2009, 2010, 2011
+;; Copyright (C) 2009, 2010, 2011, 2012
;; Free Software Foundation, Inc.
;; Contributed by Michael Meissner
@@ -919,7 +919,7 @@ (define_insn "vsx_xscvspdp"
[(set (match_operand:DF 0 "vsx_register_operand" "=ws,?wa")
(unspec:DF [(match_operand:V4SF 1 "vsx_register_operand" "wa,wa")]
UNSPEC_VSX_CVSPDP))]
- "VECTOR_UNIT_VSX_P (DFmode)"
+ "VECTOR_UNIT_VSX_P (V4SFmode)"
"xscvspdp %x0,%x1"
[(set_attr "type" "fp")])
@@ -929,7 +929,7 @@ (define_insn "vsx_xscvdpsp_scalar"
[(set (match_operand:V4SF 0 "vsx_register_operand" "=wa")
(unspec:V4SF [(match_operand:SF 1 "vsx_register_operand" "f")]
UNSPEC_VSX_CVSPDP))]
- "VECTOR_UNIT_VSX_P (DFmode)"
+ "VECTOR_UNIT_VSX_P (V4SFmode)"
"xscvdpsp %x0,%x1"
[(set_attr "type" "fp")])
@@ -938,7 +938,7 @@ (define_insn "vsx_xscvspdp_scalar2"
[(set (match_operand:SF 0 "vsx_register_operand" "=f")
(unspec:SF [(match_operand:V4SF 1 "vsx_register_operand" "wa")]
UNSPEC_VSX_CVSPDP))]
- "VECTOR_UNIT_VSX_P (DFmode)"
+ "VECTOR_UNIT_VSX_P (V4SFmode)"
"xscvspdp %x0,%x1"
[(set_attr "type" "fp")])
[v3] add -Wabi to build flags
As requested by Jason, I've added -Wabi to the libstdc++ build flags. The patch is trivial. The results are in line with what we expect. After I did this part and verified the build went swimmingly, I ran the testsuite with -Wabi as well. This part had some problems, I'm getting some odd results (things like constexpr functions being marked as changing with -fabi-version=3, which makes no sense to me.) I've filed this stuff in bugzilla with some notes, see the link for more info: http://gcc.gnu.org/PR51804 As an aside, the mangling changes for -fabi-version=3 look like they will impact a lot of code. tested x86/linux -benjamin2012-01-09 Benjamin Kosnik * fragment.am (WARN_CXXFLAGS): Add -Wabi. * Makefile.in: Regenerate. * doc/Makefile.in: Same. * include/Makefile.in: Same. * libsupc++/Makefile.in: Same. * src/Makefile.in: Same. * testsuite/Makefile.in: Same. * po/Makefile.in: Same. * python/Makefile.in: Same. diff --git a/libstdc++-v3/fragment.am b/libstdc++-v3/fragment.am index cae1ffd..2bcbc1a 100644 --- a/libstdc++-v3/fragment.am +++ b/libstdc++-v3/fragment.am @@ -18,7 +18,7 @@ toolexeclibdir = $(glibcxx_toolexeclibdir) CONFIG_CXXFLAGS = \ $(SECTION_FLAGS) $(EXTRA_CXX_FLAGS) -frandom-seed=$@ WARN_CXXFLAGS = \ - $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once + $(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once -Wabi # -I/-D flags to pass when compiling. AM_CPPFLAGS = $(GLIBCXX_INCLUDES)
[google/main] Fix erroneous output of pubnames when no .debug_section is emitted. (issue5528054)
Certain source files will not produce a .debug_info section. This patch to
google/main adds a check for that case to output_pubnames, preventing a link
failure.
Tested:
By rebuild and bootstrap.
ChangeLog:
2012-01-09 Sterling Augustine
* gcc/dwarf2out.c (output_pubnames): Add check for info_section_emitted.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 3788cf8..57f18ad 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -8754,7 +8754,7 @@ output_pubnames (VEC (pubname_entry, gc) * names)
unsigned long pubnames_length = size_of_pubnames (names);
pubname_ref pub;
- if (!targetm.want_debug_pub_sections)
+ if (!targetm.want_debug_pub_sections || !info_section_emitted)
return;
if (names == pubname_table)
{
--
This patch is available for review at http://codereview.appspot.com/5528054
Re: [4.7][google] Adding a new option -fstack-protector-strong. (issue5461043)
Hi, all, it's been a long time, I've slightly modified my code -
TREE_ADDRESSABLE is only applied when TREE_CODE is VAR_DECL, and it's
combined with test for arrays/struct-union-contain-array, which makes
the code a little bit cleaner.
Comments, approvals? Thanks!
= Patch starts ==
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 2b2e464..eb48607 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -1509,15 +1509,38 @@ estimated_stack_frame_size (struct cgraph_node *node)
return size;
}
+/* Helper routine to check if a record or union contains an array field. */
+
+static int
+record_or_union_type_has_array (const_tree tree_type)
+{
+ tree fields = TYPE_FIELDS (tree_type);
+ tree f;
+ for (f = fields; f; f = DECL_CHAIN (f))
+{
+ if (TREE_CODE (f) == FIELD_DECL)
+ {
+ tree field_type = TREE_TYPE (f);
+ if (RECORD_OR_UNION_TYPE_P (field_type))
+ return record_or_union_type_has_array (field_type);
+ if (TREE_CODE (field_type) == ARRAY_TYPE)
+ return 1;
+ }
+}
+ return 0;
+}
+
/* Expand all variables used in the function. */
static void
expand_used_vars (void)
{
tree var, outer_block = DECL_INITIAL (current_function_decl);
+ referenced_var_iterator rvi;
VEC(tree,heap) *maybe_local_decls = NULL;
unsigned i;
unsigned len;
+ int gen_stack_protect_signal = 0;
/* Compute the phase of the stack frame for this function. */
{
@@ -1550,6 +1573,23 @@ expand_used_vars (void)
}
}
+ FOR_EACH_REFERENCED_VAR (cfun, var, rvi)
+if (!is_global_var (var))
+ {
+ tree var_type = TREE_TYPE (var);
+ /* Examine local referenced variables that have their addresses taken,
+ contain an array or are arrays. */
+ if (TREE_CODE (var) == VAR_DECL
+ && (TREE_CODE (var_type) == ARRAY_TYPE
+ || TREE_ADDRESSABLE (var)
+ || (RECORD_OR_UNION_TYPE_P (var_type)
+ && record_or_union_type_has_array (var_type
+ {
+ ++gen_stack_protect_signal;
+ break;
+ }
+ }
+
/* At this point all variables on the local_decls with TREE_USED
set are not associated with any block scope. Lay them out. */
@@ -1640,12 +1680,17 @@ expand_used_vars (void)
dump_stack_var_partition ();
}
- /* There are several conditions under which we should create a
- stack guard: protect-all, alloca used, protected decls present. */
+ /* There are several conditions under which we should create a stack guard:
+ protect-all, alloca used, protected decls present or a positive
+ gen_stack_protect_signal. */
if (flag_stack_protect == 2
- || (flag_stack_protect
+ || (flag_stack_protect == 1
&& (cfun->calls_alloca || has_protected_decls)))
create_stack_guard ();
+ else if (flag_stack_protect == 3
+ && (gen_stack_protect_signal
+ || cfun->calls_alloca || has_protected_decls))
+create_stack_guard ();
/* Assign rtl to each variable based on these partitions. */
if (stack_vars_num > 0)
diff --git a/gcc/common.opt b/gcc/common.opt
index 6cfe17a..0680057 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1836,6 +1836,10 @@ fstack-protector-all
Common Report RejectNegative Var(flag_stack_protect, 2)
Use a stack protection method for every function
+fstack-protector-strong
+Common Report RejectNegative Var(flag_stack_protect, 3)
+Use a smart stack protection method for certain functions
+
fstack-usage
Common RejectNegative Var(flag_stack_usage)
Output stack usage information on a per-function basis
diff --git a/gcc/testsuite/g++.dg/fstack-protector-strong.C
b/gcc/testsuite/g++.dg/fstack-protector-strong.C
new file mode 100644
index 000..a4f0f81
--- /dev/null
+++ b/gcc/testsuite/g++.dg/fstack-protector-strong.C
@@ -0,0 +1,35 @@
+/* Test that stack protection is done on chosen functions. */
+
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -fstack-protector-strong" } */
+
+class A
+{
+public:
+ A() {}
+ ~A() {}
+ void method();
+ int state;
+};
+
+/* Frame address exposed to A::method via "this". */
+int
+foo1 ()
+{
+ A a;
+ a.method ();
+ return a.state;
+}
+
+/* Possible destroying foo2's stack via &a. */
+int
+global_func (A& a);
+
+/* Frame address exposed to global_func. */
+int foo2 ()
+{
+ A a;
+ return global_func (a);
+}
+
+/* { dg-final { scan-assembler-times "stack_chk_fail" 2 } } */
diff --git a/gcc/testsuite/gcc.dg/fstack-protector-strong.c
b/gcc/testsuite/gcc.dg/fstack-protector-strong.c
new file mode 100644
index 000..5a5cf98
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fstack-protector-strong.c
@@ -0,0 +1,135 @@
+/* Test that stack protection is done on chosen functions. */
+
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -fstack-protector-strong" } */
+
+#include
+#include
+
+extern int g0;
+extern int* pg0;
+int
+goo (int *);
+int
+hoo (
Re: [PATCH][Graphite] Fix PR50561
On 01/09/2012 04:31 PM, Richard Guenther wrote:
We have two Graphite related release blockers for 4.7. The
following patch fixes the first one.
Hi Richard,
thanks a lot for working on this.
The asserts in
static inline ppl_dimension_type
psct_dynamic_dim (poly_bb_p pbb, graphite_dim_t level)
{
graphite_dim_t result = 1 + 2 * level;
gcc_assert (result< pbb_nb_scattering_transform (pbb));
return result;
}
static inline ppl_dimension_type
psct_static_dim (poly_bb_p pbb, graphite_dim_t level)
{
graphite_dim_t result = 2 * level;
gcc_assert (result< pbb_nb_scattering_transform (pbb));
return result;
}
are not consistent in case both a dynamic and static dimension should
always exist at the same time. Changing psct_dynamic_dim to use<=
fixes the issue.
I don't think this is the right fix. The asserts seem to be correct.
The problem is actually already shown when you run cc1.
[CLooG] INFO: 2 dimensions (over 3) are scalar.
[CLooG] WARNING: not enough constraints for 1 scattering function(s).
This means, the schedule/scattering that we defined was not sufficient
enough to define the execution order. It is underspecified. The result
is that CLooG generates the following code:
for (c2=-250;c2<=1535;c2++) {
for (i=max(0,ceild(51*c2,307))
i<=min(255,floord(51*c2+12800,307));i++) {
S1(i);
}
}
c2 is a scattering variable, but 'i' is actually a original loop
dimension. I believe graphite does not expect this dimension to show up.
Somehow the scattering that is defined is incorrect. I suspect the loop
flattening has some problems with the inequalities introduced by the
strip-mining.
I will look into this.
Tobias, you are the only active(?) Graphite reviewer left.
I am, though i have currently not a lot of time to write patches myself.
I am still looking into finishing Sebastians patches. Afterwards it
should be simple to use the new polyhedral optimizer as it was recently
added to isl.
Tobi
Re: [Patch, Fortran] PR51197 - print signal number before backtrace [RFC]
Dear Janne,
- The integer values for the signal numbers are not standardized,
hence printing them might give the user a false impression that these
numbers convey some information beyond whichever SIG* macro they map
to on that particular target.
- It doesn't test all the signals which are actually handled, see
compile_options.c:set_options(). Also, as a minor point, there's no
need to have #ifdef tests for the C89 signals, again see
set_options().
How about the attached version? The description is based on IEEE Std
1003.1:2003, though I additionally left "segmentation fault" and
"floating-point exception" as those names are presumably better known
that the long description and as SIGSEGV/SIGFPE. "Bus error" is also
somewhat known, but SIGBUS should be sufficient.
Tobias
2012-01-09 Tobias Burnus
PR fortran/51197
* runtime/compile_options.c (show_signal): List
more signals.
Index: libgfortran/runtime/compile_options.c
===
--- libgfortran/runtime/compile_options.c (Revision 183034)
+++ libgfortran/runtime/compile_options.c (Arbeitskopie)
@@ -43,37 +43,72 @@ show_signal (int signum)
switch (signum)
{
-#if defined(SIGSEGV)
+#if defined(SIGQUIT)
+ case SIGQUIT:
+ name = "SIGQUIT";
+ desc = "Terminal quit signal";
+ break;
+#endif
+
+ /* The following 4 signals are defined by C89. */
+ case SIGILL:
+ name = "SIGILL";
+ desc = "Illegal instruction";
+ break;
+
+ case SIGABRT:
+ name = "SIGABRT";
+ desc = "Process abort signal";
+ break;
+
+ case SIGFPE:
+ name = "SIGFPE";
+ desc = "Floating-point exception - erroneous arithmetic operation";
+ break;
+
case SIGSEGV:
name = "SIGSEGV";
- desc = "Segmentation fault";
+ desc = "Segmentation fault - invalid memory reference";
break;
-#endif
#if defined(SIGBUS)
case SIGBUS:
name = "SIGBUS";
- desc = "Bus error";
+ desc = "Access to an undefined portion of a memory object";
break;
#endif
-#if defined(SIGILL)
- case SIGILL:
- name = "SIGILL";
- desc = "Illegal instruction";
+#if defined(SIGSYS)
+ case SIGSYS:
+ name = "SIGSYS";
+ desc = "Bad system call";
break;
#endif
-#if defined(SIGFPE)
- case SIGFPE:
- name = "SIGFPE";
- desc = "Floating-point exception";
+#if defined(SIGTRAP)
+ case SIGTRAP:
+ name = "SIGTRAP";
+ desc = "Trace/breakpoint trap";
break;
#endif
+
+#if defined(SIGXCPU)
+ case SIGXCPU:
+ name = "SIGXCPU";
+ desc = "CPU time limit exceeded";
+ break;
+#endif
+
+#if defined(SIGXFSZ)
+ case SIGXFSZ:
+ name = "SIGXFSZ";
+ desc = "File size limit exceeded";
+ break;
+#endif
}
if (name)
-st_printf ("\nProgram received signal %d (%s): %s.\n", signum, name, desc);
+st_printf ("\nProgram received signal %s: %s.\n", name, desc);
else
st_printf ("\nProgram received signal %d.\n", signum);
}
[wwwdocs] correct libstdc++ links
Correct libstdc++ naming convention to be the same as used by the other html tarballs, ie library-html.tar.bz2. I just checked this in as I was fixing the recent gcc mailing list report of broken links. -benjamin2012-01-09 Benjamin Kosnik * onlinedocs/index.html: Use same naming conventions for html tarballs as the rest of the gcc docs. Index: onlinedocs/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/onlinedocs/index.html,v retrieving revision 1.120 diff -r1.120 index.html 68c68 < href="http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual.html.tar.bz2";>an --- > href="http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual-html.tar.bz2";>an 75c75 < href="http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-api.html.tar.bz2";>an --- > href="http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-api-html.tar.bz2";>an
Re: [PATCH][Graphite]
On 01/09/2012 04:34 PM, Richard Guenther wrote: This fixes the 2nd P1 ICE. There is a disconnect on how we analyze data-references during SCOP detection (outermost_loop is the root of the loop tree) and during SESE-to-poly where outermost is determined by outermost_loop_in_sese_1 (). That influences the SCEV result and thus we do not break the SCOP at a stmt we have to break it. The following patch fixes this using a sledgehammer - require the data-ref to be representable if analyzed with respect to all loops it can nest in. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Ok? This one looks good to me. The new region based scop detection should fix this issue, but until we can get the relevant patches in, this looks like a good fix. Thanks for fixing the graphite PRs. Tobi
Re: [google/main] Fix erroneous output of pubnames when no .debug_section is emitted. (issue5528054)
> Certain source files will not produce a .debug_info section. This patch to > google/main adds a check for that case to output_pubnames, preventing a link > failure. > > Tested: > By rebuild and bootstrap. > > ChangeLog: > > 2012-01-09 Sterling Augustine > > * gcc/dwarf2out.c (output_pubnames): Add check for > info_section_emitted. LGTM. -cary
Re: [PING] [wwwdocs] - changes to GUPC page
On Mon, 9 Jan 2012, Nenad Vukicevic wrote: > Is it ok to make this update to the web page? Someone has to approve > this change, even though it is GUPC specific. Yes, and no. ;-) This patch is okay, and I suggest you consider yourself maintainer of this page and change it as you see fit (just posting patches here). Alternately, I'll be happy to review, just have been on vacation when you originally posted this. Gerald
[Patch, Fortran, committed] PR 46328 - add another test case
Dear all,
I have committed that attached test case as Rev. 183039.
The test case is the one of PR 46328, comment 2. The failure was solved
by Paul's patch for PR 51791.
Tobias
Index: gcc/testsuite/gfortran.dg/typebound_operator_11.f90
===
--- gcc/testsuite/gfortran.dg/typebound_operator_11.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/typebound_operator_11.f90 (Arbeitskopie)
@@ -0,0 +1,42 @@
+! { dg-do compile }
+!
+! PR fortran/46328
+!
+! Contributed by Damian Rouson
+!
+module foo_module
+ type ,abstract :: foo
+ contains
+procedure(t_interface) ,deferred :: t
+procedure(assign_interface) ,deferred :: assign
+procedure(multiply_interface) ,deferred :: multiply
+generic :: operator(*) => multiply
+generic :: assignment(=) => assign
+ end type
+ abstract interface
+function t_interface(this)
+ import :: foo
+ class(foo) :: this
+ class(foo), allocatable ::t_interface
+end function
+function multiply_interface(lhs,rhs)
+ import :: foo
+ class(foo), allocatable :: multiply_interface
+ class(foo), intent(in) :: lhs
+ real, intent(in) :: rhs
+end function
+subroutine assign_interface(lhs,rhs)
+ import :: foo
+ class(foo), intent(in) :: rhs
+ class(foo), intent(inout) :: lhs
+end subroutine
+ end interface
+contains
+ subroutine bar(x,dt)
+class(foo) :: x
+real, intent(in) :: dt
+x = x%t()*dt
+ end subroutine
+end module
+
+! { dg-final { cleanup-modules "foo_module" } }
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 183038)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2012-01-09 Tobias Burnus
+
+ PR fortran/46328
+ * gfortran.dg/typebound_operator_11.f90: New.
+
2012-01-09 Eric Botcazou
* gnat.dg/array18.adb: New test.
@@ -12,7 +17,7 @@
2012-01-09 Martin Jambor
-PR tree-optimization/51759
+ PR tree-optimization/51759
* g++.dg/ipa/pr51759.C: New test.
2012-01-09 Tobias Burnus
Re: [PATCH] Adjust 'malloc' attribute documentation to match implementation
It looks non-ambiguous to me.
David
On Mon, Jan 9, 2012 at 1:05 AM, Richard Guenther wrote:
>
> Since GCC 4.4 applying the malloc attribute to realloc-like
> functions does not work under the documented constraints because
> the contents of the memory pointed to are not properly transfered
> from the realloc argument (or treated as pointing to anything,
> like 4.3 behaved).
>
> The following adjusts documentation to reflect implementation
> reality (we do have an implementation detail that treats the
> memory blob returned for non-builtins as pointing to any global
> variable, but that is neither documented nor do I plan to do
> so - I presume it is to allow allocation + initialization
> routines to be marked with malloc, but even that area looks
> susceptible to misinterpretation to me).
>
> Any comments?
>
> Thanks,
> Richard.
>
> 2012-01-09 Richard Guenther
>
> * doc/extend.texi (malloc attribute): Adjust according to
> implementation.
>
> Index: gcc/doc/extend.texi
> ===
> --- gcc/doc/extend.texi (revision 183001)
> +++ gcc/doc/extend.texi (working copy)
> @@ -2771,13 +2771,12 @@ efficient @code{jal} instruction.
> @cindex @code{malloc} attribute
> The @code{malloc} attribute is used to tell the compiler that a function
> may be treated as if any non-@code{NULL} pointer it returns cannot
> -alias any other pointer valid when the function returns.
> +alias any other pointer valid when the function returns and that the memory
> +has undefined content.
> This will often improve optimization.
> Standard functions with this property include @code{malloc} and
> -@code{calloc}. @code{realloc}-like functions have this property as
> -long as the old pointer is never referred to (including comparing it
> -to the new pointer) after the function returns a non-@code{NULL}
> -value.
> +@code{calloc}. @code{realloc}-like functions do not have this
> +property as the memory pointed to does not have undefined content.
>
> @item mips16/nomips16
> @cindex @code{mips16} attribute
Re: [patch libstdc++]: Fix PR/51673
This is ok, but I realized that some of the newer CXXABI symbols were
missing, so I added them as well and then checked all of this in. See
attached patch.
best,
Benjamin
2012-01-09 Kai Tietz
PR libstc++/51673 part 2
* config/abi/pre/gnu-versioned-namespace.ver: Adjusted new/delete
operators signature for LLP64 size_t, and adjusted signatures for
mt-allocator using size_t.
2012-01-09 Benjamin Kosnik
PR libstc++/51673 part 1
* config/abi/pre/gnu-versioned-namespace.ver: Sync cxxabi symbols
with gnu.ver.
diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
index 13f06ef..2bd23cd 100644
--- a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
+++ b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
@@ -1,6 +1,6 @@
## Linker script for GNU namespace versioning.
##
-## Copyright (C) 2002, 2003, 2004, 2005, 2007, 2009, 2011
+## Copyright (C) 2002, 2003, 2004, 2005, 2007, 2009, 2011, 2012
## Free Software Foundation, Inc.
##
## This file is part of the libstdc++ version 3 distribution.
@@ -42,9 +42,9 @@ GLIBCXX_7.0 {
__once_proxy;
# operator new(size_t)
-_Znw[jm];
+_Znw[jmy];
# operator new(size_t, std::nothrow_t const&)
-_Znw[jm]RKSt9nothrow_t;
+_Znw[jmy]RKSt9nothrow_t;
# operator delete(void*)
_ZdlPv;
@@ -52,9 +52,9 @@ GLIBCXX_7.0 {
_ZdlPvRKSt9nothrow_t;
# operator new[](size_t)
-_Zna[jm];
+_Zna[jmy];
# operator new[](size_t, std::nothrow_t const&)
-_Zna[jm]RKSt9nothrow_t;
+_Zna[jmy]RKSt9nothrow_t;
# operator delete[](void*)
_ZdaPv;
@@ -93,16 +93,16 @@ GLIBCXX_7.0 {
# __gnu_cxx::__pool
_ZN9__gnu_cxx3__76__poolILb[01]EE13_M_initializeEv;
-_ZN9__gnu_cxx3__76__poolILb[01]EE16_M_reserve_blockE[jm][jm];
-_ZN9__gnu_cxx3__76__poolILb[01]EE16_M_reclaim_blockEPc[jm];
+_ZN9__gnu_cxx3__76__poolILb[01]EE16_M_reserve_blockE[jmy][jmy];
+_ZN9__gnu_cxx3__76__poolILb[01]EE16_M_reclaim_blockEPc[jmy];
_ZN9__gnu_cxx3__76__poolILb[01]EE10_M_destroyEv;
_ZN9__gnu_cxx3__76__poolILb1EE16_M_get_thread_idEv;
-_ZN9__gnu_cxx3__717__pool_alloc_base9_M_refillE[jm];
-_ZN9__gnu_cxx3__717__pool_alloc_base16_M_get_free_listE[jm];
+_ZN9__gnu_cxx3__717__pool_alloc_base9_M_refillE[jmy];
+_ZN9__gnu_cxx3__717__pool_alloc_base16_M_get_free_listE[jmy];
_ZN9__gnu_cxx3__717__pool_alloc_base12_M_get_mutexEv;
-_ZN9__gnu_cxx3__79free_list6_M_getE[jm];
+_ZN9__gnu_cxx3__79free_list6_M_getE[jmy];
_ZN9__gnu_cxx3__79free_list8_M_clearEv;
# __gnu_cxx::stdio_sync_filebuf
@@ -145,16 +145,19 @@ CXXABI_2.0 {
global:
__cxa_allocate_exception;
+__cxa_allocate_dependent_exception;
__cxa_bad_cast;
__cxa_bad_typeid;
__cxa_begin_catch;
__cxa_begin_cleanup;
__cxa_call_unexpected;
__cxa_current_exception_type;
+__cxa_deleted_virtual;
__cxa_demangle;
__cxa_end_catch;
__cxa_end_cleanup;
__cxa_free_exception;
+__cxa_free_dependent_exception;
__cxa_get_exception_ptr;
__cxa_get_globals;
__cxa_get_globals_fast;
@@ -199,6 +202,11 @@ CXXABI_2.0 {
_ZSt17current_exceptionv;
_ZSt17rethrow_exceptionNSt15__exception_ptr13exception_ptrE;
+# std::nested_exception
+_ZNSt16nested_exceptionD*;
+_ZTISt16nested_exception;
+_ZTVSt16nested_exception;
+
# std::bad_function_call.
_ZNSt17bad_function_callD*;
_ZTISt17bad_function_call;
@@ -287,6 +295,11 @@ CXXABI_2.0 {
_ZTIPDn;
_ZTIPKDn;
+# typeinfo for __int128 and unsigned __int128
+_ZTI[no];
+_ZTIP[no];
+_ZTIPK[no];
+
# virtual table
_ZTVN10__cxxabiv117__array_type_infoE;
_ZTVN10__cxxabiv117__class_type_infoE;
Re: [PATCH] Fix some powerpc debug options
On Mon, Jan 9, 2012 at 4:30 PM, Michael Meissner wrote: > I was recently trying to turn on some of the debug options I put in when doing > the initial power7 work to track down some performance regressions. The > following patches fix problems that come up in telling the compiler to use the > traditional floating point insns for scalar mode on power7 > (-mno-vsx-scalar-double). It also adds reload helpers for using the VSX > memory > load instructions when the compiler is allowed to use VSX memory instructions > for scalars. There were no regressions with these patches. Are they ok to be > checked in? > > 2012-01-09 Michael Meissner > > * config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Add DF > reload patterns if -mvsx-scalar-memory. > > * config/rs6000/vsx.md (vsx_xscvspdp): Allow xscvspdp to be > generated, even -mno-vsx-scalar-double was used. > (vsx_xscvdpsp_scalar): Likewise. > (vsx_xscvspdp_scalar2): Likewise. Okay. Thanks, David
Re: [libitm] Port to ARM
On 01/10/2012 05:52 AM, Eric Botcazou wrote: >> To get the ball rolling for other targets, and to let port maintainers see >> how easy it really is, here's a first cut at a port to ARM. > > Do you plan to do something for the SPARC? I'm asking because you still are > a > maintainer of this arch as well, so if we can avoid doing the work twice... I have no immediate plans. If you have time to knock something together for Sparc, that would be fantastic. r~
Re: [PATCH] PR51271. Fix handling of frame-related insn in delay slot of annulled branch
On 01/08/2012 11:50 PM, Tom de Vries wrote: > * dwarf2cfi.c (scan_trace): Save and restore cur_row->reg_save when > handling annulled branch. Ok. r~
Re: Unreviewed libffi, libgfortran, libitm patches
On 01/10/2012 03:06 AM, Rainer Orth wrote: > Richard Henderson writes: > >> On 01/04/2012 11:27 PM, Rainer Orth wrote: >>> [libgfortran, libitm] Link with -shared-libgcc >>> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01382.html >>> >>> This will need a fortran resp. libitm maintainer. >> >> Does the following alleviate the need for -shared-libgcc for libitm? > > As mentioned, it did and also passed regtesting on alpha-dec-osf5.1b, > i386-pc-solaris2* and x86_64-unknown-linux-gnu. Would you mind > committing the patch? Done. r~
Re: [RFC, patch] libitm: Filter out undo writes that overlap with the libitm stack.
On 01/09/2012 06:26 AM, Torvald Riegel wrote: > libitm: Filter out undo writes that overlap with the libitm stack. > > libitm/ > * config/generic/tls.h (GTM::mask_stack_top, > GTM::mask_stack_bottom): New. > * local.cc (gtm_undolog::rollback): Filter out any updates that > overlap the libitm stack. Add current transaction as parameter. > * libitm_i.h (GTM::gtm_undolog::rollback): Adapt. > * beginend.cc (GTM::gtm_thread::rollback): Adapt. > * testsuite/libitm.c/stackundo.c: New test. One could steal code from bohem-gc for this. See GC_get_stack_base in os_dep.c. r~
Re: patch ping^2: PR 51516 (TM clone aliases)
On 01/07/2012 05:47 AM, Aldy Hernandez wrote: > Patrick Marlier > PR middle-end/51516 > * trans-mem.c (get_cg_data): Traverse aliases if requested. > (ipa_tm_scan_calls_block): Update parameters to get_cg_data. > (ipa_tm_note_irrevocable): Same. > (ipa_tm_scan_irr_block): Same. > (ipa_tm_decrement_clone_counts): Same. > (ipa_tm_scan_irr_function): Same. > (ipa_tm_create_version_alias): Same. > (ipa_tm_create_version): Same. > (ipa_tm_transform_calls_redirect): Same. > (ipa_tm_transform_calls): Same. > (ipa_tm_transform_transaction): Same. > (ipa_tm_execute): Same. Ok. r~
[Patch, Fortran] Minor wording changed for gfc_error and polym. (intr.) assignment
Hi all,
that's a follow up to my review comment for
http://gcc.gnu.org/ml/fortran/2012-01/msg00077.html
As stated, I think "in intrinsic assignment" makes the error message
clearer and correcter.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
PS: Other pending patches:
* http://gcc.gnu.org/ml/fortran/2012-01/msg00080.html - libgfortran SIG*
update
* http://gcc.gnu.org/ml/fortran/2012-01/msg00059.html -
allocate(character(len=...) ...) check
2012-01-09 Tobias Burnus
* resolve.c (resolve_ordinary_assign): Improve error wording.
2012-01-09 Tobias Burnus
* gfortran.dg/class_39.f03: Update dg-error string.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (Revision 183034)
+++ gcc/fortran/resolve.c (Arbeitskopie)
@@ -9208,8 +9223,8 @@ resolve_ordinary_assign (gfc_code *code, gfc_names
and coindexed; cf. F2008, 7.2.1.2 and PR 43366. */
if (lhs->ts.type == BT_CLASS)
{
- gfc_error ("Variable must not be polymorphic in assignment at %L "
- "- check that there is a matching specific subroutine "
+ gfc_error ("Variable must not be polymorphic in intrinsic assignment at "
+ "%L - check that there is a matching specific subroutine "
"for '=' operator", &lhs->where);
return false;
}
Index: gcc/testsuite/gfortran.dg/class_39.f03
===
--- gcc/testsuite/gfortran.dg/class_39.f03 (Revision 183034)
+++ gcc/testsuite/gfortran.dg/class_39.f03 (Arbeitskopie)
@@ -8,6 +8,6 @@
end type T
contains
class(T) function add() ! { dg-error "must be dummy, allocatable or pointer" }
-add = 1 ! { dg-error "Variable must not be polymorphic in assignment" }
+add = 1 ! { dg-error "Variable must not be polymorphic in intrinsic assignment" }
end function
end
Re: [Patch, Fortran] PR51197 - print signal number before backtrace [RFC]
On Tue, Jan 10, 2012 at 00:33, Tobias Burnus wrote: > Dear Janne, > > >> - The integer values for the signal numbers are not standardized, >> hence printing them might give the user a false impression that these >> numbers convey some information beyond whichever SIG* macro they map >> to on that particular target. >> >> - It doesn't test all the signals which are actually handled, see >> compile_options.c:set_options(). Also, as a minor point, there's no >> need to have #ifdef tests for the C89 signals, again see >> set_options(). > > > How about the attached version? The description is based on IEEE Std > 1003.1:2003, though I additionally left "segmentation fault" and > "floating-point exception" as those names are presumably better known that > the long description and as SIGSEGV/SIGFPE. "Bus error" is also somewhat > known, but SIGBUS should be sufficient. Ok, thanks! -- Janne Blomqvist
Re: [libitm] Port to ARM
> I have no immediate plans. If you have time to knock something > together for Sparc, that would be fantastic. OK, will try, thanks. -- Eric Botcazou
Re: [Patch,AVR]: ad PR49868: Extend __pgmx semantics to flatten memory
2012/1/10 Georg-Johann Lay : > This patch extends the semantics of 24-bit __pgmx address space qualifier to > cover RAM and Flash. > > RAM is represented by setting the high byte of 24-bit address to 0x80. The > code > to read from 24-bit address space decides at runtime what instruction to use > to > read by if-else decision depending on bit 23 of the address, i.e. the code > looks like. > > if address.23 > return LD reg, Z // read from RAM > else > if have RAMPZ > RAMPZ = address.msb > return LPM reg, Z // read from Flash > > The code in avr.c actually gets simpler because more work is shifted to libgcc > as the code to emit gets more complex. > > Moreover, there is better separation of 16-bit address spaces and 24-bit > address spaces because even on small devices with just 1 flash segment 24-bit > pointers make sense now. > > Ok for trunk? > > This should be the last patch for 4.7 from my side that adds new > functionality, > so that all what remains is documentation and release note updates, test cases > and bug fixes. > > Unfortunately, the address space implementation in GCC is odd from the user > perspective, in particular when dealing with literals. > > Johann > > libgcc/ > PR target/49868 > Extend __pgmx semantics to linearize memory. > * config/avr/t-avr (LIB1ASMFUNCS): Add _xload_1, _movmemx. > * config/avr/lib1funcs.S (__xload_1): New function. > (__movmemx_qi, __movmemx_hi): New functions. > (__xload_2, __xload_3, __xload_4): Rewrite to fit new __pgmx > semantics. > > gcc/ > PR target/49868 > Extend __pgmx semantics to linearize memory. > * config/avr/avr.md (mov): Use avr_xload_libgcc_p to > determine if code comes inline or from libgcc. > (MOVMEM_r_d:HI): Add "w" to constraint for better preference. > (movmem_qi, movmem_qi): Set constraint #2 to "n". > (movmem_qi_elpm, movmem_hi_elpm): Remove insns. > (movmemx_qi, movmemx_hi): New insns. > (xload__libgcc): Rewrite to new insn condition. > (xload_): Remove insns. > * config/avr/avr.c (avr_out_xload): Rewrite: Only need to handle > cases that don't satisfy avr_xload_libgcc_p(). > (avr_addr_space_convert): Allow converting in any direction. > (avr_addr_space_subset_p): Return always true. > (avr_xload_libgcc_p): Rewrite to fit new __pgmx semantics. > (avr_emit_movmemhi): Ditto. > (avr_out_lpm): No need to handle ADDR_SPACE_PGMX any more. > (avr_out_movmem): Ditto. > (AVR_SYMBOL_FLAG_PROGMEM): New macro. > (AVR_SYMBOL_SET_ADDR_SPACE): New macro. > (AVR_SYMBOL_GET_ADDR_SPACE): New macro. > (avr_encode_section_info): Encode 'progmem' in symbol flags. > (output_reload_in_const): Don't zero-extend any 24-bit symbols. Approved. Denis.
