Re: [m68k] Fix option handling for -m68020-40 and -m68020-60
Gunther Nikl gn...@users.sourceforge.net writes: While working with GCC 4.7, I noticed that the -m68020-40 and -m68020-60 options are broken. Broken in which way? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
[lra] patch to prevent ASHIFT exchange and dead early clobber operand
The following patch prevents mistaken ASHIFT exchange found by
Richard Sandiford and removes check early_clobber matching operand.
The patch was successfully bootstrap on x86-64.
Committed as rev. 192742.
2012-10-23 Vladimir Makarov vmaka...@redhat.com
* lra-constraints.c (extract_loc_address_regs): Don't swap ASHIFT
operands.
(process_alt_operands): Remove code for checking DEAD note for
early clobber.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 192702)
+++ lra-constraints.c (working copy)
@@ -639,7 +639,7 @@ extract_loc_address_regs (bool top_p, en
rtx *arg0_loc = XEXP (x, 0);
enum rtx_code code0 = GET_CODE (*arg0_loc);
- if (code0 == CONST_INT)
+ if (code0 == CONST_INT code == MULT)
arg0_loc = XEXP (x, 1);
extract_loc_address_regs (false, mode, as, arg0_loc, true,
outer_code, code, modify_p, ad);
@@ -1781,17 +1781,7 @@ process_alt_operands (int only_alternati
match_p = false;
if (operands_match_p (*curr_id-operand_loc[nop],
*curr_id-operand_loc[m], m_hregno))
- {
- /* We should reject matching of an early
- clobber operand if the matching operand is
- not dying in the insn. */
- if (! curr_static_id-operand[m].early_clobber
- || operand_reg[nop] == NULL_RTX
- || (find_regno_note (curr_insn, REG_DEAD,
- REGNO (operand_reg[nop]))
- != NULL_RTX))
- match_p = true;
- }
+ match_p = true;
if (match_p)
{
/* If we are matching a non-offsettable
patch to fix a testsuite failure in LRA
Uros reported that GCC after LRA submitting has a new test failure on
x86. The reason was in wrong update live info in EBB containing empty
BB as the last EBB block. For such case live_out of the last EBB was
undefined and actually a garbage. It resulted in triggering a code
which checks that pseudo assigned to call clobbered hard register does
not live through calls.
The following patch fixes the problem.
The patch was successfully tested and bootstrapped on x86.
Committed as rev. 192743.
2012-10-23 Vladimir Makarov vmaka...@redhat.com
* lra-constraints.c (update_ebb_live_info): Process empty blocks.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 192719)
+++ lra-constraints.c (working copy)
@@ -4300,8 +4300,6 @@ update_ebb_live_info (rtx head, rtx tail
curr_insn = prev_insn)
{
prev_insn = PREV_INSN (curr_insn);
- if (! INSN_P (curr_insn))
- continue;
curr_bb = BLOCK_FOR_INSN (curr_insn);
if (curr_bb != prev_bb)
{
@@ -4336,7 +4334,7 @@ update_ebb_live_info (rtx head, rtx tail
prev_bb = curr_bb;
bitmap_and (live_regs, check_only_regs, df_get_live_out (curr_bb));
}
- if (DEBUG_INSN_P (curr_insn))
+ if (! NONDEBUG_INSN_P (curr_insn))
continue;
curr_id = lra_get_insn_recog_data (curr_insn);
remove_p = false;
Re: [lra] patch to fix testsuite regressions
On 10/21/2012 05:27 AM, Richard Sandiford wrote:
Hi Vlad,
Richard, sorry for long delay with the answer. I was really busy all
these days trying to fix a lot of GCC testsuite failures (for some ones
it was extremely difficult to find failure reasons) and push LRA into trunk.
Vladimir Makarov vmaka...@redhat.com writes:
@@ -543,23 +544,34 @@ extract_loc_address_regs (bool top_p, en
code1 = GET_CODE (arg1);
}
+ if (CONSTANT_P (arg0)
+ || code1 == PLUS || code1 == MULT || code1 == ASHIFT)
+ {
+ tloc = arg1_loc;
+ arg1_loc = arg0_loc;
+ arg0_loc = tloc;
+ arg0 = *arg0_loc;
+ code0 = GET_CODE (arg0);
+ arg1 = *arg1_loc;
+ code1 = GET_CODE (arg1);
+ }
When does this happen? Is it from the extract_address_regs calls
in equiv_address_substitution, or somewhere else?
I did not analyzed this. Sorry, I had no time for this. I just saw it
on a broken test.
I think the future work would be a support of canonical expressions
through all LRA and machine depended code and also address extract
rewriting when we figure out the exact syntax of the addresses.
/* If this machine only allows one register per address, it
must be in the first operand. */
if (MAX_REGS_PER_ADDRESS == 1 || code == LO_SUM)
{
- extract_loc_address_regs (false, mode, as, arg0_loc, false, code,
- code1, modify_p, ad);
lra_assert (ad-disp_loc == NULL);
ad-disp_loc = arg1_loc;
+ extract_loc_address_regs (false, mode, as, arg0_loc, false, code,
+ code1, modify_p, ad);
}
/* Base + disp addressing */
- else if (code != PLUS code0 != MULT code0 != ASHIFT
+ else if (code0 != PLUS code0 != MULT code0 != ASHIFT
CONSTANT_P (arg1))
{
- extract_loc_address_regs (false, mode, as, arg0_loc, false, PLUS,
- code1, modify_p, ad);
lra_assert (ad-disp_loc == NULL);
ad-disp_loc = arg1_loc;
+ extract_loc_address_regs (false, mode, as, arg0_loc, false, PLUS,
+ code1, modify_p, ad);
}
/* If index and base registers are the same on this machine,
just record registers in any non-constant operands. We
Wasn't sure: is the order of the disp_loc assignment and
extract_loc_address_regs call significant here, or did you just swap
them for cosmetic reasons? The original order seemed stronger on the
face of it, because we assert that the recursive call hasn't also
installed a displacement.
It was not a cosmetic change. It was a necessary fix for a broken test.
@@ -624,11 +635,18 @@ extract_loc_address_regs (bool top_p, en
case MULT:
case ASHIFT:
- extract_loc_address_regs (false, mode, as, XEXP (*loc, 0), true,
- outer_code, code, modify_p, ad);
- lra_assert (ad-index_loc == NULL);
- ad-index_loc = loc;
- break;
+ {
+ rtx *arg0_loc = XEXP (x, 0);
+ enum rtx_code code0 = GET_CODE (*arg0_loc);
+
+ if (code0 == CONST_INT)
+ arg0_loc = XEXP (x, 1);
+ extract_loc_address_regs (false, mode, as, arg0_loc, true,
+ outer_code, code, modify_p, ad);
+ lra_assert (ad-index_loc == NULL);
+ ad-index_loc = loc;
+ break;
+ }
Is this just for the MULT case? Treating X in (ashift 1 X) as an
index register seems odd on the face of it.
Yes, right. It is really safe but it should be fixed for code clearness.
@@ -1757,10 +1786,10 @@ process_alt_operands (int only_alternati
clobber operand if the matching operand is
not dying in the insn. */
if (! curr_static_id-operand[m].early_clobber
- /*|| operand_reg[nop] == NULL_RTX
+ || operand_reg[nop] == NULL_RTX
|| (find_regno_note (curr_insn, REG_DEAD,
REGNO (operand_reg[nop]))
-!= NULL_RTX)*/)
+!= NULL_RTX))
match_p = true;
}
if (match_p)
Ah, so did you find the reason why this was done? :-)
I already wrote you that I am going to restore the code, as I really
remember that I added this for purpose to fix some bug on some target.
It is better to have a safer code in the trunk. My intention is remove
this code again on the branch to figure out details why I did it. In
any case, even if this code is necessary, the code should be rewritten
to match when the operand is the same independently on presence of
REG_DEAD note.
Index:
[lra] patch fixing a testsuite failure
The patch is a patch posted for trunk on
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02085.html
Committed as rev. 192744.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 192719)
+++ lra-constraints.c (working copy)
@@ -4300,8 +4300,6 @@ update_ebb_live_info (rtx head, rtx tail
curr_insn = prev_insn)
{
prev_insn = PREV_INSN (curr_insn);
- if (! INSN_P (curr_insn))
- continue;
curr_bb = BLOCK_FOR_INSN (curr_insn);
if (curr_bb != prev_bb)
{
@@ -4336,7 +4334,7 @@ update_ebb_live_info (rtx head, rtx tail
prev_bb = curr_bb;
bitmap_and (live_regs, check_only_regs, df_get_live_out (curr_bb));
}
- if (DEBUG_INSN_P (curr_insn))
+ if (! NONDEBUG_INSN_P (curr_insn))
continue;
curr_id = lra_get_insn_recog_data (curr_insn);
remove_p = false;
Re: patch to fix constant math - 4th patch - the wide-int class.
On 10/23/12, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 10/23/2012 02:38 PM, Lawrence Crowl wrote:
On 10/23/12, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 10/23/2012 10:12 AM, Richard Biener wrote:
+ inline bool minus_one_p () const;
+ inline bool zero_p () const;
+ inline bool one_p () const;
+ inline bool neg_p () const;
what's wrong with w == -1, w == 0, w == 1, etc.?
I would love to do this and you seem to be somewhat knowledgeable
of c++. But i cannot for the life of me figure out how to do it.
Starting from the simple case, you write an operator ==.
as global operator: bool operator == (wide_int w, int i);
as member operator: bool wide_int::operator == (int i);
In the simple case,
bool operator == (wide_int w, int i)
{
switch (i)
{
case -1: return w.minus_one_p ();
case 0: return w.zero_p ();
case 1: return w.one_p ();
default: unexpected
}
}
no, this seems wrong.you do not want to write code that can only
fail at runtime unless there is a damn good reason to do that.
Well, that's because it's the oversimplified case. :-)
say i have a TImode number, which must be represented in 4 ints
on a 32 bit host (the same issue happens on 64 bit hosts, but
the examples are simpler on 32 bit hosts) and i compare it to -1.
The value that i am going to see as the argument of the function
is going have the value 0x. but the value that i have
internally is 128 bits. do i take this and 0 or sign extend it?
What would you have done with w.minus_one_p ()?
the code knows that -1 is a negative number and it knows the
precision of w. That is enough information. So it logically
builds a -1 that has enough bits to do the conversion.
And the code could also know that '-n' is a negative number and do
the identical conversion. It would certainly be more difficult to
write and get all the edge cases.
in particular if someone wants to compare a number to 0xdeadbeef i
have no idea what to do. I tried defining two different functions,
one that took a signed and one that took and unsigned number but
then i wanted a cast in front of all the positive numbers.
This is where it does get tricky. For signed arguments, you should sign
extend. For unsigned arguments, you should not. At present, we need
multiple overloads to avoid type ambiguities.
bool operator == (wide_int w, long long int i);
bool operator == (wide_int w, unsigned long long int i);
inline bool operator == (wide_int w, long int i)
{ return w == (long long int) i; }
inline bool operator (wide_int w, unsigned long int i)
{ return w == (unsigned long long int) i; }
inline bool operator == (wide_int w, int i)
{ return w == (long long int) i; }
inline bool operator (wide_int w, unsigned int i)
{ return w == (unsigned long long int) i; }
(There is a proposal before the C++ committee to fix this problem.)
Even so, there is room for potential bugs when wide_int does not
carry around whether or not it is signed. The problem is that
regardless of what the programmer thinks of the sign of the wide int,
the comparison will use the sign of the int.
when they do we can revisit this. but i looked at this and i said the
potential bugs were not worth the effort.
I won't disagree. I was answering what I thought were questions on
what was possible.
If there is a way to do this, then i will do it, but it is going
to have to work properly for things larger than a HOST_WIDE_INT.
The long-term solution, IMHO, is to either carry the sign information
around in either the type or the class data. (I prefer type, but
with a mechanism to carry it as data when needed.) Such comparisons
would then require consistency in signedness between the wide int
and the plain int.
carrying the sign information is a non starter.The rtl level does
not have it and the middle end violates it more often than not.My
view was to design this having looked at all of the usage. I have
basically converted the whole compiler before i released the abi. I am
still getting out the errors and breaking it up in reviewable sized
patches, but i knew very very well who my clients were before i wrote
the abi.
Okay.
I know that double-int does some of this and it does not carry
around a notion of signedness either. is this just code that has
not been fully tested or is there a trick in c++ that i am missing?
The double int class only provides == and !=, and only with other
double ints. Otherwise, it has the same value query functions that
you do above. In the case of double int, the goal was to simplify
use of the existing semantics. If you are changing the semantics,
consider incorporating sign explicitly.
i have, and it does not work.
Unfortunate.
--
Lawrence Crowl
PR tree-optimization/54985
When we try to thread across a back edge in the CFG we have a check to
ensure that we don't use temporary equivalences which are invalidated by
traversal of the back edge to simplify the final conditional.
About a year ago I added code to pick up secondary threading
opportunities after an initial jump threading was successful. However,
I failed to account for equivalences which were invalidated by the back
edge traversal in those new cases.
This patch extracts the check into its own function, then calls it from
the 3 locations where it's necessary.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed onto the trunk.
Oh how I want to rewrite all this code
Jeff
ps. First time commiting using git svn, hopefully I did all the steps
correctly.
* tree-ssa-threadedge.c (cond_arg_set_in_bb): New function extracted
from thread_across_edge.
(thread_across_edge): Use it in all cases where we might thread
across a back edge.
* gcc.c-torture/execute/pr54985.c: New test.
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr54985.c
b/gcc/testsuite/gcc.c-torture/execute/pr54985.c
new file mode 100644
index 000..678c9f4
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr54985.c
@@ -0,0 +1,36 @@
+
+typedef struct st {
+int a;
+} ST;
+
+int __attribute__((noinline,noclone))
+foo(ST *s, int c)
+{
+ int first = 1;
+ int count = c;
+ ST *item = s;
+ int a = s-a;
+ int x;
+
+ while (count--)
+{
+ x = item-a;
+ if (first)
+first = 0;
+ else if (x = a)
+return 1;
+ a = x;
+ item++;
+}
+ return 0;
+}
+
+extern void abort (void);
+
+int main ()
+{
+ ST _1[2] = {{2}, {1}};
+ if (foo(_1, 2) != 0)
+abort ();
+ return 0;
+}
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index 105e3ab..491aa9f 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -572,6 +572,44 @@ simplify_control_stmt_condition (edge e,
return cached_lhs;
}
+/* Return TRUE if the statement at the end of e-dest depends on
+ the output of any statement in BB. Otherwise return FALSE.
+
+ This is used when we are threading a backedge and need to ensure
+ that temporary equivalences from BB do not affect the condition
+ in e-dest. */
+
+static bool
+cond_arg_set_in_bb (edge e, basic_block bb, int n)
+{
+ ssa_op_iter iter;
+ use_operand_p use_p;
+ gimple last = gsi_stmt (gsi_last_bb (e-dest));
+
+ /* E-dest does not have to end with a control transferring
+ instruction. This can occurr when we try to extend a jump
+ threading opportunity deeper into the CFG. In that case
+ it is safe for this check to return false. */
+ if (!last)
+return false;
+
+ if (gimple_code (last) != GIMPLE_COND
+ gimple_code (last) != GIMPLE_GOTO
+ gimple_code (last) != GIMPLE_SWITCH)
+return false;
+
+ FOR_EACH_SSA_USE_OPERAND (use_p, last, iter, SSA_OP_USE | SSA_OP_VUSE)
+{
+ tree use = USE_FROM_PTR (use_p);
+
+ if (TREE_CODE (use) == SSA_NAME
+ gimple_code (SSA_NAME_DEF_STMT (use)) != GIMPLE_PHI
+ gimple_bb (SSA_NAME_DEF_STMT (use)) == bb)
+ return true;
+}
+ return false;
+}
+
/* TAKEN_EDGE represents the an edge taken as a result of jump threading.
See if we can thread around TAKEN_EDGE-dest as well. If so, return
the edge out of TAKEN_EDGE-dest that we can statically compute will be
@@ -705,19 +743,8 @@ thread_across_edge (gimple dummy_cond,
safe to thread this edge. */
if (e-flags EDGE_DFS_BACK)
{
- ssa_op_iter iter;
- use_operand_p use_p;
- gimple last = gsi_stmt (gsi_last_bb (e-dest));
-
- FOR_EACH_SSA_USE_OPERAND (use_p, last, iter, SSA_OP_USE | SSA_OP_VUSE)
- {
- tree use = USE_FROM_PTR (use_p);
-
- if (TREE_CODE (use) == SSA_NAME
- gimple_code (SSA_NAME_DEF_STMT (use)) != GIMPLE_PHI
- gimple_bb (SSA_NAME_DEF_STMT (use)) == e-dest)
- goto fail;
- }
+ if (cond_arg_set_in_bb (e, e-dest, 1))
+ goto fail;
}
stmt_count = 0;
@@ -758,7 +785,9 @@ thread_across_edge (gimple dummy_cond,
address. If DEST is not null, then see if we can thread
through it as well, this helps capture secondary effects
of threading without having to re-run DOM or VRP. */
- if (dest)
+ if (dest
+ ((e-flags EDGE_DFS_BACK) == 0
+ || ! cond_arg_set_in_bb (taken_edge, e-dest, 2)))
{
/* We don't want to thread back to a block we have already
visited. This may be overly conservative. */
@@ -816,11 +845,16 @@ thread_across_edge (gimple dummy_cond,
e3 = taken_edge;
do
{
- e2 = thread_around_empty_block (e3,
- dummy_cond,
-
Re: PR tree-optimization/54985
On Tue, Oct 23, 2012 at 02:35:24PM -0600, Jeff Law wrote:
+/* Return TRUE if the statement at the end of e-dest depends on
+ the output of any statement in BB. Otherwise return FALSE.
+
+ This is used when we are threading a backedge and need to ensure
+ that temporary equivalences from BB do not affect the condition
+ in e-dest. */
+
+static bool
+cond_arg_set_in_bb (edge e, basic_block bb, int n)
+{
+ ssa_op_iter iter;
+ use_operand_p use_p;
+ gimple last = gsi_stmt (gsi_last_bb (e-dest));
Use gimple last = last_stmt (e-dest); instead? That way any possible
debug stmts are ignored.
Jakub
Follow-up to PR bootstrap/54820
As reported by Ian and Peter in the audit trail, the check I added to detect
whether -static-libstdc++ is supported by g++ doesn't work because the option
is silently rejected by versions prior to 4.5.
The attached patch forces an error for these versions so as to make the check
always fail. Tested with GCC 4.3 and GCC 4.5, OK for mainline?
2012-10-23 Eric Botcazou ebotca...@adacore.com
PR bootstrap/54820
* configure.ac (have_static_libs): Force 'no' for GCC version 4.5.
* configure: Regenerate.
--
Eric BotcazouIndex: configure.ac
===
--- configure.ac (revision 192666)
+++ configure.ac (working copy)
@@ -1190,7 +1190,11 @@ if test $GCC = yes; then
LDFLAGS=$LDFLAGS -static-libstdc++ -static-libgcc
AC_MSG_CHECKING([whether g++ accepts -static-libstdc++ -static-libgcc])
AC_LANG_PUSH(C++)
- AC_LINK_IFELSE([int main() {}],
+ AC_LINK_IFELSE([
+#if (__GNUC__ 4) || (__GNUC__ == 4 __GNUC_MINOR__ 5)
+#error -static-libstdc++ not implemented
+#endif
+int main() {}],
[AC_MSG_RESULT([yes]); have_static_libs=yes],
[AC_MSG_RESULT([no])])
AC_LANG_POP(C++)
Re: PR tree-optimization/54985
On 10/23/2012 02:50 PM, Jakub Jelinek wrote:
On Tue, Oct 23, 2012 at 02:35:24PM -0600, Jeff Law wrote:
+/* Return TRUE if the statement at the end of e-dest depends on
+ the output of any statement in BB. Otherwise return FALSE.
+
+ This is used when we are threading a backedge and need to ensure
+ that temporary equivalences from BB do not affect the condition
+ in e-dest. */
+
+static bool
+cond_arg_set_in_bb (edge e, basic_block bb, int n)
+{
+ ssa_op_iter iter;
+ use_operand_p use_p;
+ gimple last = gsi_stmt (gsi_last_bb (e-dest));
Use gimple last = last_stmt (e-dest); instead? That way any possible
debug stmts are ignored.
I thought I'd already dealt with this before. I'll double-check and
take appropriate action.
Any opinions about pulling it into 4.7.x as that release is affected by
this codegen bug? I've got no strong opinions and I'm willing to pull
it onto the branch if you want it.
jeff
Re: PR tree-optimization/54985
On Tue, Oct 23, 2012 at 03:21:59PM -0600, Jeff Law wrote:
On 10/23/2012 02:50 PM, Jakub Jelinek wrote:
+static bool
+cond_arg_set_in_bb (edge e, basic_block bb, int n)
+{
+ ssa_op_iter iter;
+ use_operand_p use_p;
+ gimple last = gsi_stmt (gsi_last_bb (e-dest));
Use gimple last = last_stmt (e-dest); instead? That way any possible
debug stmts are ignored.
I thought I'd already dealt with this before. I'll double-check and
take appropriate action.
Any opinions about pulling it into 4.7.x as that release is affected
by this codegen bug? I've got no strong opinions and I'm willing to
pull it onto the branch if you want it.
I think it should be backported to 4.7, perhaps with a few days delay after the
trunk commit.
Jakub
Remove unused debugging arg from last change
Committed as obvious.
* tree-ssa-threadedge.c (cond_arg_set_in_bb): Remove unused
debugging argument.
Index: tree-ssa-threadedge.c
===
--- tree-ssa-threadedge.c (revision 192745)
+++ tree-ssa-threadedge.c (working copy)
@@ -580,7 +580,7 @@
in e-dest. */
static bool
-cond_arg_set_in_bb (edge e, basic_block bb, int n)
+cond_arg_set_in_bb (edge e, basic_block bb)
{
ssa_op_iter iter;
use_operand_p use_p;
Re: [patch] libitm: Clarify ABI requirements for data-logging functions.
On 2012-10-24 01:50, Torvald Riegel wrote: Clarify ABI requirements for data-logging functions. * libitm.texi: Clarify ABI requirements for data-logging functions. Ok. r~
Re: LRA has been merged into trunk.
From: Vladimir Makarov vmaka...@redhat.com Date: Tue, 23 Oct 2012 11:46:34 -0400 Hi, I was going to merge LRA into trunk last Sunday. It did not happen. LRA was actively changed last 4 weeks by implementing reviewer's proposals which resulted in a lot of new LRA regressions on GCC testsuite in comparison with reload. Finally, they were fixed and everything looks ok to me. So I've committed the patch into trunk as rev. 192719. The final patch is in the attachment. Thanks for doing this work Vlad. Just as a heads up I started playing with LRA on Sparc.
Re: patch to fix constant math - 4th patch - the wide-int class.
On 10/23/2012 04:25 PM, Lawrence Crowl wrote:
On 10/23/12, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 10/23/2012 02:38 PM, Lawrence Crowl wrote:
On 10/23/12, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 10/23/2012 10:12 AM, Richard Biener wrote:
+ inline bool minus_one_p () const;
+ inline bool zero_p () const;
+ inline bool one_p () const;
+ inline bool neg_p () const;
what's wrong with w == -1, w == 0, w == 1, etc.?
I would love to do this and you seem to be somewhat knowledgeable
of c++. But i cannot for the life of me figure out how to do it.
Starting from the simple case, you write an operator ==.
as global operator: bool operator == (wide_int w, int i);
as member operator: bool wide_int::operator == (int i);
In the simple case,
bool operator == (wide_int w, int i)
{
switch (i)
{
case -1: return w.minus_one_p ();
case 0: return w.zero_p ();
case 1: return w.one_p ();
default: unexpected
}
}
no, this seems wrong.you do not want to write code that can only
fail at runtime unless there is a damn good reason to do that.
Well, that's because it's the oversimplified case. :-)
say i have a TImode number, which must be represented in 4 ints
on a 32 bit host (the same issue happens on 64 bit hosts, but
the examples are simpler on 32 bit hosts) and i compare it to -1.
The value that i am going to see as the argument of the function
is going have the value 0x. but the value that i have
internally is 128 bits. do i take this and 0 or sign extend it?
What would you have done with w.minus_one_p ()?
the code knows that -1 is a negative number and it knows the
precision of w. That is enough information. So it logically
builds a -1 that has enough bits to do the conversion.
And the code could also know that '-n' is a negative number and do
the identical conversion. It would certainly be more difficult to
write and get all the edge cases.
I am not a c++ hacker. if someone wants to go there later, we can
investigate this.
but it seems like a can of worms right now.
in particular if someone wants to compare a number to 0xdeadbeef i
have no idea what to do. I tried defining two different functions,
one that took a signed and one that took and unsigned number but
then i wanted a cast in front of all the positive numbers.
This is where it does get tricky. For signed arguments, you should sign
extend. For unsigned arguments, you should not. At present, we need
multiple overloads to avoid type ambiguities.
bool operator == (wide_int w, long long int i);
bool operator == (wide_int w, unsigned long long int i);
inline bool operator == (wide_int w, long int i)
{ return w == (long long int) i; }
inline bool operator (wide_int w, unsigned long int i)
{ return w == (unsigned long long int) i; }
inline bool operator == (wide_int w, int i)
{ return w == (long long int) i; }
inline bool operator (wide_int w, unsigned int i)
{ return w == (unsigned long long int) i; }
(There is a proposal before the C++ committee to fix this problem.)
Even so, there is room for potential bugs when wide_int does not
carry around whether or not it is signed. The problem is that
regardless of what the programmer thinks of the sign of the wide int,
the comparison will use the sign of the int.
when they do we can revisit this. but i looked at this and i said the
potential bugs were not worth the effort.
I won't disagree. I was answering what I thought were questions on
what was possible.
If there is a way to do this, then i will do it, but it is going
to have to work properly for things larger than a HOST_WIDE_INT.
The long-term solution, IMHO, is to either carry the sign information
around in either the type or the class data. (I prefer type, but
with a mechanism to carry it as data when needed.) Such comparisons
would then require consistency in signedness between the wide int
and the plain int.
carrying the sign information is a non starter.The rtl level does
not have it and the middle end violates it more often than not.My
view was to design this having looked at all of the usage. I have
basically converted the whole compiler before i released the abi. I am
still getting out the errors and breaking it up in reviewable sized
patches, but i knew very very well who my clients were before i wrote
the abi.
Okay.
I know that double-int does some of this and it does not carry
around a notion of signedness either. is this just code that has
not been fully tested or is there a trick in c++ that i am missing?
The double int class only provides == and !=, and only with other
double ints. Otherwise, it has the same value query functions that
you do above. In the case of double int, the goal was to simplify
use of the existing semantics. If you are changing the semantics,
consider incorporating sign explicitly.
i have, and it does not work.
Unfortunate.
There is certainly a desire here not
Re: [Patch] libitm: Ask dispatch whether it requires serial mode.
On 2012-10-24 01:48, Torvald Riegel wrote: Ask dispatch whether it requires serial mode. * retry.cc (gtm_thread::decide_begin_dispatch): Ask dispatch whether it requires serial mode instead of assuming that for certain dispatchs. * dispatch.h (abi_dispatch::requires_serial): New. (abi_dispatch::abi_dispatch): Adapt. * method-gl.cc (gl_wt_dispatch::gl_wt_dispatch): Adapt. * method-ml.cc (ml_wt_dispatch::ml_wt_dispatch): Same. * method-serial.cc (serialirr_dispatch::serialirr_dispatch, serial_dispatch::serial_dispatch, serialirr_onwrite_dispatch::serialirr_onwrite_dispatch): Same. Ok. r~
Re: PR tree-optimization/54985
On 10/23/2012 03:22 PM, Jakub Jelinek wrote:
On Tue, Oct 23, 2012 at 03:21:59PM -0600, Jeff Law wrote:
On 10/23/2012 02:50 PM, Jakub Jelinek wrote:
+static bool
+cond_arg_set_in_bb (edge e, basic_block bb, int n)
+{
+ ssa_op_iter iter;
+ use_operand_p use_p;
+ gimple last = gsi_stmt (gsi_last_bb (e-dest));
Use gimple last = last_stmt (e-dest); instead? That way any possible
debug stmts are ignored.
I thought I'd already dealt with this before. I'll double-check and
take appropriate action.
Any opinions about pulling it into 4.7.x as that release is affected
by this codegen bug? I've got no strong opinions and I'm willing to
pull it onto the branch if you want it.
I think it should be backported to 4.7, perhaps with a few days delay after the
trunk commit.
Do we even have debug statements after control flow statements?
jeff
Re: Tidy store_bit_field_1 co.
I should probably have responded to this earlier, sorry. I'm not sure
which part you mean, so here's an attempt at justifying the whole block:
1) WORDS_BIG_ENDIAN is deliberately ignored:
/* The following line once was done only if WORDS_BIG_ENDIAN,
but I think that is a mistake. WORDS_BIG_ENDIAN is
meaningful at a much higher level; when structures are copied
between memory and regs, the higher-numbered regs
always get higher addresses. */
2) For MEM:
The old code reached this if statement with:
unsigned int unit = (MEM_P (str_rtx)) ? BITS_PER_UNIT : BITS_PER_WORD;
offset = bitnum / unit;
bitpos = bitnum % unit;
I.e.:
offset = bitnum / BITS_PER_UNIT;
bitpos = bitnum % BITS_PER_UNIT;
which the new code does explicitly with:
unsigned HOST_WIDE_INT bitpos = bitnum;
if (MEM_P (xop0))
{
/* Get a reference to the first byte of the field. */
xop0 = adjust_bitfield_address (xop0, byte_mode,
bitpos / BITS_PER_UNIT); -- offset
bitpos %= BITS_PER_UNIT;
}
The following:
unit = GET_MODE_BITSIZE (op_mode);
if (BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN)
xbitpos = unit - bitsize - xbitpos;
code is the same as before.
3) For REG, !BYTES_BIG_ENDIAN, !BITS_BIG_ENDIAN:
The easy case. The old code reached this if statement with:
unsigned int unit = (MEM_P (str_rtx)) ? BITS_PER_UNIT : BITS_PER_WORD;
offset = bitnum / unit;
bitpos = bitnum % unit;
...
if (!MEM_P (op0) ...)
{
...set op0 to the word containing the field...
offset = 0;
}
where the awkward thing is that OFFSET and BITPOS are now out of sync
with BITNUM. So before the if statement:
offset = 0;
bitpos = bitnum % BITS_PER_WORD;
which if the !MEM_P block above had updated BITNUM too would just
have been:
offset = 0;
bitpos = bitnum;
The new code does update BITNUM:
if (!MEM_P (op0) ...)
{
...set op0 to the word containing the field...
bitnum %= BITS_PER_WORD;
}
...
unsigned HOST_WIDE_INT bitpos = bitnum;
so both the following hold:
offset = 0;
bitpos = bitnum % BITS_PER_WORD;
offset = 0;
bitpos = bitnum;
The if statement doesn't do any endian modification to (X)BITPOS
before or after the patch.
4) For REG, !BYTES_BIG_ENDIAN, BITS_BIG_ENDIAN:
Like (3), but at the end we also have:
unit = GET_MODE_BITSIZE (op_mode);
if (BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN)
xbitpos = unit - bitsize - xbitpos;
This is the same as before, although the assignment to UNIT has moved
up a bit.
5) For REG, BYTES_BIG_ENDIAN, BITS_BIG_ENDIAN:
In this case the code leading up to the if statement was:
unsigned int unit = (MEM_P (str_rtx)) ? BITS_PER_UNIT : BITS_PER_WORD;
offset = bitnum / unit;
bitpos = bitnum % unit;
...
/* If OP0 is a register, BITPOS must count within a word.
But as we have it, it counts within whatever size OP0 now has.
On a bigendian machine, these are not the same, so convert. */
if (BYTES_BIG_ENDIAN
!MEM_P (op0)
unit GET_MODE_BITSIZE (GET_MODE (op0)))
bitpos += unit - GET_MODE_BITSIZE (GET_MODE (op0));
...
if (!MEM_P (op0) ...)
{
...set op0 to the word containing the field...
offset = 0;
}
So:
offset = 0
bitpos = bitnum % BITS_PER_WORD;
if (...original op0 was smaller than a word...)
bitpos += BITS_PER_WORD - bits in op0;
The !MEM_P block narrows OP0s that are wider than a word to word_mode --
it never narrows more than that -- so this is equivalent to:
offset = 0
bitpos = bitnum % BITS_PER_WORD;
if (...current op0 is smaller than a word...)
bitpos += BITS_PER_WORD - bits in op0;
And thanks to the !MEM_P code, op0 is never _wider_ than a word at
this point, so we have:
offset = 0
bitpos = bitnum % BITS_PER_WORD + BITS_PER_WORD - bits in op0;
Then, inside the if statement we did:
/* We have been counting XBITPOS within UNIT.
Count instead within the size of the register. */
if (BYTES_BIG_ENDIAN !MEM_P (xop0))
xbitpos += GET_MODE_BITSIZE (op_mode) - unit;
where UNIT is still BITS_PER_WORD. So we have:
offset = 0
bitpos = (bitnum % BITS_PER_WORD + BITS_PER_WORD - bits in op0
+ bits in op_mode - BITS_PER_WORD);
which cancels to:
offset = 0
bitpos = bitnum % BITS_PER_WORD + (bits in op_mode - bits in op0);
As above, if the subreg code had updated BITNUM too, this would be
equivalent to:
offset = 0
bitpos = bitnum + (bits in op_mode - bits in op0);
but isn't as things stand. The new code does update BITNUM:
if (!MEM_P (op0)
Re: PR tree-optimization/54985
On Tue, Oct 23, 2012 at 03:34:46PM -0600, Jeff Law wrote: I think it should be backported to 4.7, perhaps with a few days delay after the trunk commit. Do we even have debug statements after control flow statements? They shouldn't be there, so if you just give up the same way for gsi_stmt NULL as well as non-control stmt, it shouldn't make a difference. So last_stmt might be just shorter to type and more commonly used, nothing more. Jakub
Re: [Patch] Fix the tests gcc.dg/vect/vect-8[23]_64.c
On Oct 23, 2012, at 6:52 AM, Dominique Dhumieres domi...@lps.ens.fr wrote: Following the changes in [PATCH] Add option for dumping to stderr (issue6190057) the tests gcc.dg/vect/vect-8[23]_64.c fails on powerpc*-*-*. This patch adjust the dump files and has been tested on powerpc-apple-darwin9. Ok. gcc/testsuite/ChangeLog 2012-10-23 Dominique d'Humieres domi...@lps.ens.fr * gcc.dg/vect/vect-82_64.c: Adjust the dump file. * gcc.dg/vect/vect-83_64.c: Likewise.
Re: PR c++/54928 infinite ICE when reporting ICE on macro expansion
On 18 October 2012 00:24, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Wed, Oct 17, 2012 at 6:26 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: On 17 October 2012 11:55, Dodji Seketeli do...@redhat.com wrote: Hello Manuel, Let's CC Gaby on this one as well. Manuel López-Ibáñez lopeziba...@gmail.com writes: The problem is that the macro unwinder code is changing the original diagnostic type and not restoring it, so the code detecting that we ICE fails to abort, which triggers another ICE, and so on. But there is no point in modifying the original diagnostic, we can simply create a temporary copy and use that for macro unwinding. We modify the context as well, and we set it back to its original value before getting out. Why not just doing the same for the diagnostic_info type? I mean, just save diagnostics-kind before changing it, and set it back to the saved value before getting out? That is less expensive than copying all of the diagnostic_info. Well, the difference is that for context, we are not sure that what we get at the end of the function is actually the same that we received. I am not sure if there is some buffer/obstack growth there. For diagnostic_info it is very different: we want to return exactly the original. (And in fact, both maybe_unwind_expanded_macro_loc and diagnostic_build_prefix should take a const * diagnostic_info). Also, I am not sure why we need to restore the prefix. Once the warning/error has been printed and we are just attaching notes from the unwinder, we don't care about the original prefix so we may simply destroy it. In fact, I think we are *leaking memory* by not destroying the prefix. Perhaps the prefix should be destroyed always after the finalizer and the default finalizer should be empty? Actually, I would propose going even a step further and use a more high-level api instead of calling into the pretty-printer directly. Something like: diagnostic_attach_note(context, const * diagnostic_info, location_t, const char * message, ...) that for example will check for context-inhibit_notes_p, will make sure the message is translated, will make sure that diagnostic_info is not overriden, will print the caret (or not), etc. This will live in diagnostic.c and could be used by customized diagnostic hooks to attach notes to an existing diagnostic. It would be a bit less optimized than the current code, but more re-usable. What do you think? That makes sense and is what we should do. The attached patch implements this idea. I have bootstrapped and regression tested it on x86_64-linux-gnu. And I have checked that it fixes the cascade of ICEs. I don't think there is any point in adding the original testcase because it will be added when the first ICE is fixed, and then, it won't work as a test of this fix. I couldn't figure out a way to trigger this issue without triggering an ICE first. OK? 2012-10-23 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/54928 gcc/ * tree-diagnostic.c (maybe_unwind_expanded_macro_loc): Use diagnostic_attach_note. * diagnostic.c (diagnostic_build_prefix): Make diagnostic const. (default_diagnostic_finalizer): Do not destroy prefix here. (diagnostic_report_diagnostic): Destroy it here. (diagnostic_attach_note): New. * diagnostic.h (diagnostic_attach_note): Declare. fix-pr54928.diff Description: Binary data
Re: Follow-up to PR bootstrap/54820
On Tue, Oct 23, 2012 at 2:11 PM, Eric Botcazou ebotca...@adacore.com wrote: 2012-10-23 Eric Botcazou ebotca...@adacore.com PR bootstrap/54820 * configure.ac (have_static_libs): Force 'no' for GCC version 4.5. * configure: Regenerate. This is OK. Thanks. Ian
Re: [Patch] Fix the test libgomp.graphite/force-parallel-6.c
On Oct 23, 2012, at 6:33 AM, Dominique Dhumieres domi...@lps.ens.fr wrote:
The test libgomp.graphite/force-parallel-6.c is not valid as it tries
to write Y[2*N] for Y defined as
Ok. [ Could someone check it in for Dominique? ]
2012-10-23 Dominique d'Humieres domi...@lps.ens.fr
* testsuite/libgomp.graphite/force-parallel-6.c: Adjust the loops.
--- ../_clean/libgomp/testsuite/libgomp.graphite/force-parallel-6.c
2011-12-06 15:36:08.0 +0100
+++ libgomp/testsuite/libgomp.graphite/force-parallel-6.c 2012-10-23
14:55:12.0 +0200
@@ -7,13 +7,13 @@ int foo(void)
{
int i, j, k;
- for (i = 1; i = N; i++)
+ for (i = 0; i N; i++)
{
X[i] = Y[i] + 10;
- for (j = 1; j = N; j++)
+ for (j = 0; j N; j++)
{
B[j] = A[j][N];
- for (k = 1; k = N; k++)
+ for (k = 0; k N; k++)
{
A[j+1][k] = B[j] + C[j][k];
}
[AARCH64] Update maintainers file
Patch to update the MAINTAINERS file following the merge of the aarch64 port. R. 2012-10-23 Richard Earnshaw rearn...@arm.com * MAINTAINERS (aarch64): Add Marcus and myself. Index: MAINTAINERS === --- MAINTAINERS (revision 192746) +++ MAINTAINERS (working copy) @@ -43,6 +43,8 @@ CPU Port Maintainers (CPU alphabetical order) +aarch64 port Marcus Shawcroft marcus.shawcr...@arm.com +aarch64 port Richard Earnshaw richard.earns...@arm.com alpha port Richard Henderson r...@redhat.com arm port Nick Clifton ni...@redhat.com arm port Richard Earnshaw richard.earns...@arm.com
[RS6000] libffi ppc64 assembly
Gold on powerpc64 doesn't support old ABI objects, but libffi contains old ABI assembly. This patch modifies those files to support both old and new ABI, and adds a builtin define to powerpc64 gcc that can be used to select between the ABIs in assembly. I figure a define is generally useful, and more robust than trying to duplicate gcc configury in libffi (which could be overridden by CFLAGS anyway). Bootstrapped and regression tested powerpc64-linux. OK to apply mainline? gcc/ * config/rs6000/linux64.h (TARGET_OS_CPP_BUILTINS): Define _CALL_LINUX. libffi/ * src/powerpc/linux64_closure.S: Add new ABI support. * src/powerpc/linux64.S: Likewise. Index: gcc/config/rs6000/linux64.h === --- gcc/config/rs6000/linux64.h (revision 192660) +++ gcc/config/rs6000/linux64.h (working copy) @@ -318,6 +318,8 @@ builtin_define (__PPC64__); \ builtin_define (__powerpc__); \ builtin_define (__powerpc64__); \ + if (!DOT_SYMBOLS) \ + builtin_define (_CALL_LINUX); \ builtin_assert (cpu=powerpc64); \ builtin_assert (machine=powerpc64); \ } \ Index: libffi/src/powerpc/linux64_closure.S === --- libffi/src/powerpc/linux64_closure.S(revision 192660) +++ libffi/src/powerpc/linux64_closure.S(working copy) @@ -32,16 +32,24 @@ #ifdef __powerpc64__ FFI_HIDDEN (ffi_closure_LINUX64) - FFI_HIDDEN (.ffi_closure_LINUX64) - .globl ffi_closure_LINUX64, .ffi_closure_LINUX64 + .globl ffi_closure_LINUX64 .section.opd,aw .align 3 ffi_closure_LINUX64: +#ifdef _CALL_LINUX + .quad .L.ffi_closure_LINUX64,.TOC.@tocbase,0 + .type ffi_closure_LINUX64,@function + .text +.L.ffi_closure_LINUX64: +#else + FFI_HIDDEN (.ffi_closure_LINUX64) + .globl .ffi_closure_LINUX64 .quad .ffi_closure_LINUX64,.TOC.@tocbase,0 .size ffi_closure_LINUX64,24 .type .ffi_closure_LINUX64,@function .text .ffi_closure_LINUX64: +#endif .LFB1: # save general regs into parm save area std %r3, 48(%r1) @@ -91,7 +99,11 @@ addi %r6, %r1, 128 # make the call +#ifdef _CALL_LINUX + bl ffi_closure_helper_LINUX64 +#else bl .ffi_closure_helper_LINUX64 +#endif .Lret: # now r3 contains the return type @@ -194,7 +206,11 @@ .LFE1: .long 0 .byte 0,12,0,1,128,0,0,0 +#ifdef _CALL_LINUX + .size ffi_closure_LINUX64,.-.L.ffi_closure_LINUX64 +#else .size .ffi_closure_LINUX64,.-.ffi_closure_LINUX64 +#endif .section.eh_frame,EH_FRAME_FLAGS,@progbits .Lframe1: Index: libffi/src/powerpc/linux64.S === --- libffi/src/powerpc/linux64.S(revision 192660) +++ libffi/src/powerpc/linux64.S(working copy) @@ -30,16 +30,25 @@ #include ffi.h #ifdef __powerpc64__ - .hidden ffi_call_LINUX64, .ffi_call_LINUX64 - .globl ffi_call_LINUX64, .ffi_call_LINUX64 + .hidden ffi_call_LINUX64 + .globl ffi_call_LINUX64 .section.opd,aw .align 3 ffi_call_LINUX64: +#ifdef _CALL_LINUX + .quad .L.ffi_call_LINUX64,.TOC.@tocbase,0 + .type ffi_call_LINUX64,@function + .text +.L.ffi_call_LINUX64: +#else + .hidden .ffi_call_LINUX64 + .globl .ffi_call_LINUX64 .quad .ffi_call_LINUX64,.TOC.@tocbase,0 .size ffi_call_LINUX64,24 .type .ffi_call_LINUX64,@function .text .ffi_call_LINUX64: +#endif .LFB1: mflr%r0 std %r28, -32(%r1) @@ -58,7 +67,11 @@ /* Call ffi_prep_args64. */ mr %r4, %r1 +#ifdef _CALL_LINUX + bl ffi_prep_args64 +#else bl .ffi_prep_args64 +#endif ld %r0, 0(%r29) ld %r2, 8(%r29) @@ -137,7 +150,11 @@ .LFE1: .long 0 .byte 0,12,0,1,128,4,0,0 +#ifdef _CALL_LINUX + .size ffi_call_LINUX64,.-.L.ffi_call_LINUX64 +#else .size .ffi_call_LINUX64,.-.ffi_call_LINUX64 +#endif .section.eh_frame,EH_FRAME_FLAGS,@progbits .Lframe1: -- Alan Modra Australia Development Lab, IBM
Re: [AARCH64] Update maintainers file
On Wed, Oct 24, 2012 at 12:32 AM, Richard Earnshaw wrote: Patch to update the MAINTAINERS file following the merge of the aarch64 port. Congrats on the new port! Will you also add an announcement of this to the news page (home page) and to gcc-4.8/changes.html? Ciao! Steven
Re: Remove unused debugging arg from last change
On Tue, Oct 23, 2012 at 03:28:37PM -0600, Jeff Law wrote:
Committed as obvious.
* tree-ssa-threadedge.c (cond_arg_set_in_bb): Remove unused
debugging argument.
Could you please remove the third argument in the calls to cond_arg_set_in_bb
as well?
/MF
Index: tree-ssa-threadedge.c
===
--- tree-ssa-threadedge.c (revision 192745)
+++ tree-ssa-threadedge.c (working copy)
@@ -580,7 +580,7 @@
in e-dest. */
static bool
-cond_arg_set_in_bb (edge e, basic_block bb, int n)
+cond_arg_set_in_bb (edge e, basic_block bb)
{
ssa_op_iter iter;
use_operand_p use_p;
Re: [AARCH64] Update maintainers file
On 23/10/12 23:36, Steven Bosscher wrote: On Wed, Oct 24, 2012 at 12:32 AM, Richard Earnshaw wrote: Patch to update the MAINTAINERS file following the merge of the aarch64 port. Congrats on the new port! Will you also add an announcement of this to the news page (home page) and to gcc-4.8/changes.html? Ciao! Steven I'm sure we can... :-) R.
Re: LRA has been merged into trunk.
On 12-10-23 5:28 PM, David Miller wrote: From: Vladimir Makarov vmaka...@redhat.com Date: Tue, 23 Oct 2012 11:46:34 -0400 Hi, I was going to merge LRA into trunk last Sunday. It did not happen. LRA was actively changed last 4 weeks by implementing reviewer's proposals which resulted in a lot of new LRA regressions on GCC testsuite in comparison with reload. Finally, they were fixed and everything looks ok to me. So I've committed the patch into trunk as rev. 192719. The final patch is in the attachment. Thanks for doing this work Vlad. Just as a heads up I started playing with LRA on Sparc. Thanks, David. I am not sure that anything except x86/x86-64 will work now on the branch. There were too many changes on the branch and I tested only x86/x86-64. I'll start testing the rest of targets on the branch next week when LRA is settled on trunk.
[C++ Patch PING] PR 53761
Hi, I'm pinging this patchlet: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01013.html For sure not an high priority issue, neither I can say to fully understand whether in C++ we can and should have the exact same semantics of the __transparent_union__ attribute in C, but I think that it would be good to decide one way or the other what we want to do and resolve the issue. Thanks! Paolo.
Re: PR tree-optimization/54985
The following trivial patch seems to fix it.
Index: tree-ssa-threadedge.c
===
--- tree-ssa-threadedge.c (revision 192749)
+++ tree-ssa-threadedge.c (working copy)
@@ -743,7 +743,7 @@
safe to thread this edge. */
if (e-flags EDGE_DFS_BACK)
{
- if (cond_arg_set_in_bb (e, e-dest, 1))
+ if (cond_arg_set_in_bb (e, e-dest))
goto fail;
}
@@ -787,7 +787,7 @@
of threading without having to re-run DOM or VRP. */
if (dest
((e-flags EDGE_DFS_BACK) == 0
- || ! cond_arg_set_in_bb (taken_edge, e-dest, 2)))
+ || ! cond_arg_set_in_bb (taken_edge, e-dest)))
{
/* We don't want to thread back to a block we have already
visited. This may be overly conservative. */
@@ -846,7 +846,7 @@
do
{
if ((e-flags EDGE_DFS_BACK) == 0
- || ! cond_arg_set_in_bb (e3, e-dest, 3))
+ || ! cond_arg_set_in_bb (e3, e-dest))
e2 = thread_around_empty_block (e3,
dummy_cond,
handle_dominating_asserts,
Sharad
On Tue, Oct 23, 2012 at 4:48 PM, Sharad Singhai sing...@google.com wrote:
The trunk seems to be broken at r192749 due to this patch.
../../srctrunk/gcc/tree-ssa-threadedge.c: In function ‘void
thread_across_edge(gimple_statement_d*, edge_def*, bool,
vec_ttree_node***, tree_node* (*)(gimple_statement_d*,
gimple_statement_d*))’:
../../srctrunk/gcc/tree-ssa-threadedge.c:583: error: too many
arguments to function ‘bool cond_arg_set_in_bb(edge_def*,
basic_block_def*)’
../../srctrunk/gcc/tree-ssa-threadedge.c:746: error: at this point in file
../../srctrunk/gcc/tree-ssa-threadedge.c:583: error: too many
arguments to function ‘bool cond_arg_set_in_bb(edge_def*,
basic_block_def*)’
../../srctrunk/gcc/tree-ssa-threadedge.c:790: error: at this point in file
../../srctrunk/gcc/tree-ssa-threadedge.c:583: error: too many
arguments to function ‘bool cond_arg_set_in_bb(edge_def*,
basic_block_def*)’
../../srctrunk/gcc/tree-ssa-threadedge.c:849: error: at this point in file
make: *** [tree-ssa-threadedge.o] Error 1
Sharad
Re: [Patch] Fix the tests gcc.dg/vect/vect-8[23]_64.c
Committed in r192750. Thanks, Sharad On Tue, Oct 23, 2012 at 2:46 PM, Mike Stump mikest...@comcast.net wrote: On Oct 23, 2012, at 6:52 AM, Dominique Dhumieres domi...@lps.ens.fr wrote: Following the changes in [PATCH] Add option for dumping to stderr (issue6190057) the tests gcc.dg/vect/vect-8[23]_64.c fails on powerpc*-*-*. This patch adjust the dump files and has been tested on powerpc-apple-darwin9. Ok. gcc/testsuite/ChangeLog 2012-10-23 Dominique d'Humieres domi...@lps.ens.fr * gcc.dg/vect/vect-82_64.c: Adjust the dump file. * gcc.dg/vect/vect-83_64.c: Likewise.
Re: PR c/53063 Handle Wformat with LangEnabledBy
On Tue, 23 Oct 2012, Manuel López-Ibáñez wrote: The problem is how to represent that Wformat-y2k is enabled by -Wformat=X with X = 2, while Wformat-zero-length is enabled by X =1. One possiblity is to allow to specify a condition directly: I guess that's reasonable. -- Joseph S. Myers jos...@codesourcery.com
Restore bootstrap
The obvious fix.
commit 36d5e6eace0697b2f8613ab5c24bc23ea359d347
Author: law law@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Wed Oct 24 00:43:24 2012 +
* tree-ssa-threadedge.c (thread_across_edge): Remove unused
parameter in call to cond_arg_set_in_bb.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@192754
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index cda72a0..fe52992 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,8 @@
2012-10-23 Jeff Law l...@redhat.com
+ * tree-ssa-threadedge.c (thread_across_edge): Remove unused
+ parameter in call to cond_arg_set_in_bb.
+
* tree-ssa-threadedge.c (cond_arg_set_in_bb): Remove unused
debugging argument.
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index 4669f65..6249e2f 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -743,7 +743,7 @@ thread_across_edge (gimple dummy_cond,
safe to thread this edge. */
if (e-flags EDGE_DFS_BACK)
{
- if (cond_arg_set_in_bb (e, e-dest, 1))
+ if (cond_arg_set_in_bb (e, e-dest))
goto fail;
}
@@ -787,7 +787,7 @@ thread_across_edge (gimple dummy_cond,
of threading without having to re-run DOM or VRP. */
if (dest
((e-flags EDGE_DFS_BACK) == 0
- || ! cond_arg_set_in_bb (taken_edge, e-dest, 2)))
+ || ! cond_arg_set_in_bb (taken_edge, e-dest)))
{
/* We don't want to thread back to a block we have already
visited. This may be overly conservative. */
@@ -846,7 +846,7 @@ thread_across_edge (gimple dummy_cond,
do
{
if ((e-flags EDGE_DFS_BACK) == 0
- || ! cond_arg_set_in_bb (e3, e-dest, 3))
+ || ! cond_arg_set_in_bb (e3, e-dest))
e2 = thread_around_empty_block (e3,
dummy_cond,
handle_dominating_asserts,
RFA: Add lock_lenth attribute to support the ARC port (Was: Re: Ping: RFA: add lock_length attribute to break branch-shortening cycles)
Quoting Richard Biener richard.guent...@gmail.com:
On Tue, Oct 16, 2012 at 9:35 PM, Joern Rennecke
joern.renne...@embecosm.com wrote:
..
Well, we could split it anyway, and give ports without the need for
multiple length attributes the benefit of the optimistic algorithm.
I have attached a patch that implements this.
Looks reasonable to me, though I'm not familiar enough with the code
to approve it.
Now that Richard Sandiford has reviewed that split-off part and it's in
the source tree, we can return to the remaining functionality needed
by for the ARC port.
I'd strongly suggest to try harder to make things work for you without
the new attribute even though I wasn't really able to follow your reasoning
on why that wouldn't work. It may be easier to motivate this change
once the port is in without that attribute so one can actually look at
the machine description and port details.
Well, it doesn't simply drop in with the existing branch shortening -
libgcc won't compile because of out-of-range branches.
I tried to lump the length and lock_length atribute together, and that
just gives genattrtab indigestion. It sits there looping forever.
I could start debugging this, but that would take an unknown amount of
time, and then the review of the fix would take an unknown amount of time,
and then the ARC port probably needs fixing up again because it just
doesn't work right with these fudged lengths. And even if we could get
everything required in before the close of phase 1, the branch shortening
would be substandard.
It seems more productive to get the branch shortening working now.
The lock_length atrtibute is completely optional, so no port maintainer
would be forced to use the functionality if it's not desired.
The issue is that the some instructions need to be aligned or unaligned
for performance or in a few cases even for correctness. Just inserting
random nops would be a waste of code space and cycles, since most of the
time, the desired (mis)alignment can be archived by selectively making
a short instruction long. If an instruction that is long once was forced
to stay long henceforth, that would actually defeat the purpose of getting
the desired alignment. Then another short instruction - if it can be found -
would need to be upsized. So a size increase could ripple through as
alignments are distorted. The natural thing to do is really when the
alignemnt changes is really to let the upsized instruction be short again.
Only length-determined branch sizes have to be locked to avoid cycles.
This is the documentation for the new role of the lock_length attribute
(reduced from my previous attempt):
@cindex lock_length
Usually, when doing optimizing branch shortening, the instruction length
is calculated by avaluating the @code{length} attribute, applying
@code{ADJUST_INSN_LENGTH}, and taking the maximum of the resultant
value and the length of the instruction in the previous iteration.
If you define the @code{lock_length} attribute, the @code{lock_length}
attribute will be evaluated, and then the maximum with of @code{lock_length}
value from the previous iteration will be formed and saved.
Then the maximum of that value with the @code{length} attribute will
be formed, and @code{ADJUST_INSN_LENGTH} will be applied.
Thus, you can allow the length to vary downwards as well as upwards
across iterations with suitable definitions of the @code{length} attribute
and/or @code{ADJUST_INSN_LENGTH}. Care has to be taken that this does not
lead to infinite loops.
The new patch builds on this patch:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01890.html
as a prerequisite.
build tested with libraries in revision 192654 for i686-pc-linux-gnu X
mipsel-elf .
bootstrapped in revision 192703 on i686-pc-linux-gnu;
I've also successfully run config-list.mk with the patch applied to this
revision. The following ports had pre-existing failures, which are
documented in the sub-PRs or PR47093/PR44756:
alpha64-dec-vms alpha-dec-vms am33_2.0-linux arm-netbsdelf arm-wrs-vxworks
avr-elf avr-rtems c6x-elf c6x-uclinux cr16-elf fr30-elf
i686-interix3 --enable-obsolete i686-openbsd3.0 i686-pc-msdosdjgpp
ia64-hp-vms iq2000-elf lm32-elf lm32-rtems lm32-uclinux mep-elf
microblaze-elf microblaze-linux mn10300-elf moxie-elf moxie-rtems
moxie-uclinux pdp11-aout picochip-elf --enable-obsolete rl78-elf
rx-elf score-elf --enable-obsolete sh5el-netbsd sh64-elf --with-newlib
sh64-linux sh64-netbsd sh-elf shle-linux sh-netbsdelf sh-rtems sh-superh-elf
sh-wrs-vxworks tilegx-linux-gnu tilepro-linux-gnu vax-linux-gnu vax-netbsdelf
vax-openbsd x86_64-knetbsd-gnu
I'll be posting the ARC port shortly; it does not fit into a single
100 KB posting, so I'm thinking of splitting it in a configury patch
and zx
compressed files/tarballs for arc.c, arc.md, libgcc, and the rest of the port.
2012-10-22 Joern Rennecke joern.renne...@embecosm.com
* doc/md.texi (node Defining Attributes): Add lock_length to
Re: LRA has been merged into trunk.
From: Vladimir Makarov vmaka...@redhat.com Date: Tue, 23 Oct 2012 19:04:03 -0400 I am not sure that anything except x86/x86-64 will work now on the branch. There were too many changes on the branch and I tested only x86/x86-64. I'll start testing the rest of targets on the branch next week when LRA is settled on trunk. I anticipated problems, I wanted to work on solving these puzzles as it's quite fun :-) The first issue sparc runs into is that it does not define it's extra constraints properly. In particular 'T' and 'W' must use define_memory_constraint. Otherwise the EXTRA_MEMORY_CONSTRAINT logic in process_alt_operands() does not trigger and we therefore cannot even load a constant into floating point registers properly.
Re: Minimize downward code motion during reassociation
On Tue, Oct 23, 2012 at 2:52 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Oct 22, 2012 at 8:31 PM, Easwaran Raman era...@google.com wrote:
On Mon, Oct 22, 2012 at 12:59 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Oct 19, 2012 at 12:36 AM, Easwaran Raman era...@google.com wrote:
Hi,
During expression reassociation, statements are conservatively moved
downwards to ensure that dependences are correctly satisfied after
reassocation. This could lead to lengthening of live ranges. This
patch moves statements only to the extent necessary. Bootstraps and no
test regression on x86_64/linux. OK for trunk?
Thanks,
Easwaran
2012-10-18 Easwaran Raman era...@google.com
* tree-ssa-reassoc.c(assign_uids): New function.
(assign_uids_in_relevant_bbs): Likewise.
(ensure_ops_are_available): Likewise.
(rewrite_expr_tree): Do not move statements beyond what is
necessary. Remove call to swap_ops_for_binary_stmt...
(reassociate_bb): ... and move it here.
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c (revision 192487)
+++ gcc/tree-ssa-reassoc.c (working copy)
@@ -2250,6 +2250,128 @@ swap_ops_for_binary_stmt (VEC(operand_entry_t, hea
}
}
+/* Assign UIDs to statements in basic block BB. */
+
+static void
+assign_uids (basic_block bb)
+{
+ unsigned uid = 0;
+ gimple_stmt_iterator gsi;
+ /* First assign uids to phis. */
+ for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (gsi))
+{
+ gimple stmt = gsi_stmt (gsi);
+ gimple_set_uid (stmt, uid++);
+}
+
+ /* Then assign uids to stmts. */
+ for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (gsi))
+{
+ gimple stmt = gsi_stmt (gsi);
+ gimple_set_uid (stmt, uid++);
+}
+}
+
+/* For each operand in OPS, find the basic block that contains the
statement
+ which defines the operand. For all such basic blocks, assign UIDs. */
+
+static void
+assign_uids_in_relevant_bbs (VEC(operand_entry_t, heap) * ops)
+{
+ operand_entry_t oe;
+ int i;
+ struct pointer_set_t *seen_bbs = pointer_set_create ();
+
+ for (i = 0; VEC_iterate (operand_entry_t, ops, i, oe); i++)
+{
+ gimple def_stmt;
+ basic_block bb;
+ if (TREE_CODE (oe-op) != SSA_NAME)
+continue;
+ def_stmt = SSA_NAME_DEF_STMT (oe-op);
+ bb = gimple_bb (def_stmt);
+ if (!pointer_set_contains (seen_bbs, bb))
+{
+ assign_uids (bb);
+ pointer_set_insert (seen_bbs, bb);
+}
+}
+ pointer_set_destroy (seen_bbs);
+}
Please assign UIDs once using the existing renumber_gimple_stmt_uids ().
You seem to call the above multiple times and thus do work bigger than
O(number of basic blocks).
The reason I call the above multiple times is that gsi_move_before
might get called between two calls to the above. For instance, after
rewrite_expr_tree is called once, the following sequence of calls
could happen:
reassociate_bb - linearize_expr_tree - linearize_expr -
gsi_move_before. So it is not sufficient to call
renumber_gimple_stmt_uids once per do_reassoc. Or do you want me to
use renumber_gimple_stmt_uids_in_blocks instead of
assign_uids_in_relevant_bbs?
It's sufficient to call it once if you conservatively update UIDs at stmt
move / insert time (assign the same UID as the stmt before/after).
I was worried that that would make the code brittle, but looking at
the places where a new statement is added or moved, I think it is
fine. I have made the change in the new patch.
+/* Ensure that operands in the OPS vector starting from OPINDEXth
entry are live
+ at STMT. This is accomplished by moving STMT if needed. */
+
+static void
+ensure_ops_are_available (gimple stmt, VEC(operand_entry_t, heap) *
ops, int opindex)
+{
+ int i;
+ int len = VEC_length (operand_entry_t, ops);
+ gimple insert_stmt = stmt;
+ basic_block insert_bb = gimple_bb (stmt);
+ gimple_stmt_iterator gsi_insert, gsistmt;
+ for (i = opindex; i len; i++)
+{
Likewise you call this for each call to rewrite_expr_tree, so it seems to me
this is quadratic in the number of ops in the op vector.
The call to ensure_ops_are_available inside rewrite_expr_tree is
guarded by if (!moved) and I am setting moved = true there to ensure
that ensure_ops_are_available inside is called once per reassociation
of a expression tree.
It would be a lot easier to understand this function if you call it once
after rewrite_expr_tree finished.
I think you meant before rewrite_expr_tree. One thing to note here
is this function is called only when we first see a statement whose
operand changes after reassociation. That's the reason the moving of
statements happen inside rewrite_expr_tree.
Why make this all so complicated? It seems to me that we should
fixup stmt order only after the whole ops vector has been materialized.
Re: LRA has been merged into trunk.
From: David Miller da...@davemloft.net
Date: Tue, 23 Oct 2012 21:44:05 -0400 (EDT)
The first issue sparc runs into is that it does not define it's
extra constraints properly. In particular 'T' and 'W' must use
define_memory_constraint.
Otherwise the EXTRA_MEMORY_CONSTRAINT logic in process_alt_operands()
does not trigger and we therefore cannot even load a constant into
floating point registers properly.
Ok, the next problem we hit will be a little bit more difficult
to solve.
Sparc accepts addresses of the form:
(plus:DI (lo_sum:DI (reg/f:DI 282)
(symbol_ref:DI (__mf_opts) var_decl 0xf78d74a0 __mf_opts))
(const_int 40 [0x28]))
These make use of Sparc's offsetable %lo() relocations.
But LRA is unable to cope with this expression when it is processed by
extract_address_regs() because when the LO_SUM is inspected
ad-disp_loc is already non-NULL triggering this assertion:
/* If this machine only allows one register per address, it
must be in the first operand. */
if (MAX_REGS_PER_ADDRESS == 1 || code == LO_SUM)
{
= lra_assert (ad-disp_loc == NULL);
ad-disp_loc = arg1_loc;
extract_loc_address_regs (false, mode, as, arg0_loc, false, code,
code1, modify_p, ad);
}
ARC port (1/5): configuration file patches
Prerequisites to allow the port to build properly: the lock_length attribute:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01890.html
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02120.html
And from Easwaran Raman era...@google.com:
PR middle-end/54957
* optabs.c (emit_cmp_and_jump_insn_1): Remove bogus assert.
* stmt.c (get_outgoing_edge_probs): Check default_edge / stmt_bb
for NULL before dereferencing.
(emit_case_dispatch_table): Check default_edge for NULL before
dereferencing.
Provide sane basic block parameter to emit_case_dispatch_table.
http://gcc.gnu.org/bugzilla/attachment.cgi?id=28466
For testing the ARC port, most recently I have been using revision
192641 as a GCC baseline.
The other pieces of the toolchain can be found at:
https://github.com/foss-for-synopsys-dwc-arc-processors
There is also a gcc port there, but it's an older one, based on GCC 4.4 .
The intention is to eventually contribute all parts of the GNU toolchain
to the FSF, but some pieces need redesigning first, e.g. variable size
fragment handling (or the current lack thereof) in the gas port.
I hope I can polish up the port a bit more before the 4.8 code feature
freeze, but right now the priority is get the required infrastructure for
branch shortening hashed out. And for this, it is useful for everyone
to be able to look at the ARC port - so here it is.
libgcc:
2012-10-09 Joern Rennecke joern.renne...@embecosm.com
* config.host (arc-*-elf*, arc*-*-linux-uclibc*): New configurations.
gcc:
2012-10-09 Joern Rennecke joern.renne...@embecosm.com
Brendan Kehoe bren...@zen.org
* config.gcc (arc-*-elf*, arc*-*-linux-uclibc*): New configurations.
gcc/testsuite:
2012-08-17 Joern Rennecke joern.renne...@embecosm.com
* gcc.c-torture/execute/20101011-1.c [__arc__] (DO_TEST): Define as 0.
libstdc++-v3:
2012-08-16 Joern Rennecke joern.renne...@embecosm.com
* acinclude.m4 (GLIBCXX_ENABLE_SJLJ_EXCEPTIONS): Also check for
_Unwind_SjLj_Register when deciding if to set enable_sjlj_exceptions.
* configure: Regenerate.
Index: libgcc/config.host
===
--- libgcc/config.host (revision 2572)
+++ libgcc/config.host (working copy)
@@ -303,6 +303,14 @@
extra_parts=$extra_parts vms-dwarf2.o vms-dwarf2eh.o
md_unwind_header=alpha/vms-unwind.h
;;
+arc-*-elf*)
+ tmake_file=arc/t-arc-newlib arc/t-arc
+ extra_parts=crti.o crtn.o crtend.o crtbegin.o crtendS.o crtbeginS.o
libgmon.a crtg.o crtgend.o
+ ;;
+arc*-*-linux-uclibc*)
+ tmake_file=${tmake_file} t-slibgcc-libgcc t-slibgcc-nolc-override
arc/t-arc700-uClibc arc/t-arc
+ extra_parts=crti.o crtn.o crtend.o crtbegin.o crtendS.o crtbeginS.o
libgmon.a crtg.o crtgend.o
+ ;;
arm-wrs-vxworks)
tmake_file=$tmake_file arm/t-arm arm/t-vxworks t-fdpbit
extra_parts=$extra_parts crti.o crtn.o
Index: gcc/testsuite/gcc.c-torture/execute/20101011-1.c
===
--- gcc/testsuite/gcc.c-torture/execute/20101011-1.c(revision 2572)
+++ gcc/testsuite/gcc.c-torture/execute/20101011-1.c(working copy)
@@ -36,6 +36,9 @@
#elif defined (__CRIS__)
/* No SIGFPE for CRIS integer division. */
# define DO_TEST 0
+#elif defined (__arc__)
+ /* No SIGFPE for ARC integer division. */
+# define DO_TEST 0
#elif defined (__arm__) defined (__ARM_EABI__)
# ifdef __ARM_ARCH_EXT_IDIV__
/* Hardware division instructions may not trap, and handle trapping
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 2572)
+++ gcc/config.gcc (working copy)
@@ -813,6 +813,39 @@
tm_file=${tm_file} vms/vms.h alpha/vms.h
tmake_file=${tmake_file} alpha/t-vms
;;
+arc-*-elf*)
+ extra_headers=arc-simd.h
+ tm_file=dbxelf.h elfos.h newlib-stdint.h ${tm_file}
+ tmake_file=arc/t-arc-newlib arc/t-arc
+ case x${with_cpu} in
+ xarc600|xarc601|xarc700)
+ target_cpu_default=TARGET_CPU_$with_cpu
+ ;;
+ esac
+ ;;
+arc*-*-linux-uclibc*)
+ extra_headers=arc-simd.h
+ tm_file=dbxelf.h elfos.h linux.h ${tm_file}
+ tmake_file=arc/t-arc-uClibc arc/t-arc
+ case x${with_cpu} in
+ xarc600|xarc601|xarc700)
+ target_cpu_default=TARGET_CPU_$with_cpu
+ ;;
+ esac
+ if test x${with_endian} = x; then
+ case ${target} in
+ arc*be-*-* | arc*eb-*-*)with_endian=big ;;
+ *) with_endian=little ;;
+ esac
+ fi
+ case ${with_endian} in
+ big|little) ;;
+ *) echo with_endian=${with_endian} not supported.; exit 1 ;;
+ esac
+ case ${with_endian} in
+ big*)
ARC port (3/5): gcc/config/arc/arc.md
gcc: 2012-10-22 Saurabh Verma saurabh.ve...@codito.com Ramana Radhakrishnan ramana.radhakrish...@codito.com Joern Rennecke joern.renne...@embecosm.com Muhammad Khurram Riaz khurram.r...@arc.com Brendan Kehoe bren...@zen.org Michael Eager ea...@eagercon.com * config/arc: New directory. arc.md.tar.xz Description: application/xz
ARC port (4/5): libgcc/config/arc/
libgcc: 2012-10-18 Joern Rennecke joern.renne...@embecosm.com Brendan Kehoe bren...@zen.org * libgcc/config/arc: New directory. arc-libgcc.tar.xz Description: application/xz
ARC port (5/5): rest of gcc/{,common/}config/arc/
2012-10-22 Saurabh Verma saurabh.ve...@codito.com Ramana Radhakrishnan ramana.radhakrish...@codito.com Joern Rennecke joern.renne...@embecosm.com Muhammad Khurram Riaz khurram.r...@arc.com Brendan Kehoe bren...@zen.org Michael Eager ea...@eagercon.com * config/arc, common/config/arc: New directories. arc-rest.tar.xz Description: application/xz
Re: [RS6000] libffi ppc64 assembly
On Tue, Oct 23, 2012 at 6:34 PM, Alan Modra amo...@gmail.com wrote: Gold on powerpc64 doesn't support old ABI objects, but libffi contains old ABI assembly. This patch modifies those files to support both old and new ABI, and adds a builtin define to powerpc64 gcc that can be used to select between the ABIs in assembly. I figure a define is generally useful, and more robust than trying to duplicate gcc configury in libffi (which could be overridden by CFLAGS anyway). Bootstrapped and regression tested powerpc64-linux. OK to apply mainline? gcc/ * config/rs6000/linux64.h (TARGET_OS_CPP_BUILTINS): Define _CALL_LINUX. libffi/ * src/powerpc/linux64_closure.S: Add new ABI support. * src/powerpc/linux64.S: Likewise. The patch is okay. But the libffi changes need to be submitted upstream to the libffi repository with libffi-discuss and Anthony Green. Thanks, David
Doc patch committed: The '+' constraint does not require a register
Back in May 2004 Richard Henderson ensured that using a '+' constraint
in an extended asm statement would work with an 'm' constraint.
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00438.html
Unfortunately he did not update the documentation. I verified that
Richard's code is still in the compiler, and updated the documentation
as follows.
Bootstrapped on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2012-10-23 Ian Lance Taylor i...@google.com
* doc/extend.texi (Extended Asm): The '+' constraint does not
require a register.
Index: doc/extend.texi
===
--- doc/extend.texi (revision 192525)
+++ doc/extend.texi (working copy)
@@ -5864,10 +5864,7 @@ The ordinary output operands must be wri
the values in these operands before the instruction are dead and need
not be generated. Extended asm supports input-output or read-write
operands. Use the constraint character @samp{+} to indicate such an
-operand and list it with the output operands. You should only use
-read-write operands when the constraints for the operand (or the
-operand in which only some of the bits are to be changed) allow a
-register.
+operand and list it with the output operands.
You may, as an alternative, logically split its function into two
separate operands, one input operand and one write-only output
libgo patch committed: Set libgo version number
This patch for mainline corresponds to the one I committed earlier on the 4.7 branch. This sets a different version for libgo.so on mainline going forward. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. I actually committed this yesterday but forgot to press ^C^C on the e-mail. Ian Index: libgo/configure.ac === --- libgo/configure.ac (revision 192705) +++ libgo/configure.ac (revision 192706) @@ -11,7 +11,7 @@ AC_INIT(package-unused, version-unused,, AC_CONFIG_SRCDIR(Makefile.am) AC_CONFIG_HEADER(config.h) -libtool_VERSION=1:0:0 +libtool_VERSION=3:1:0 AC_SUBST(libtool_VERSION) AM_ENABLE_MULTILIB(, ..) Index: libgo/Makefile.am === --- libgo/Makefile.am (revision 192705) +++ libgo/Makefile.am (revision 192706) @@ -1860,7 +1860,8 @@ libgo_go_objs = \ libgo_la_SOURCES = $(runtime_files) -libgo_la_LDFLAGS = $(PTHREAD_CFLAGS) $(AM_LDFLAGS) +libgo_la_LDFLAGS = \ + -version-info $(libtool_VERSION) $(PTHREAD_CFLAGS) $(AM_LDFLAGS) libgo_la_LIBADD = \ $(libgo_go_objs) ../libbacktrace/libbacktrace.la \
[PATCH] Use define_memory_constraint on sparc when necessary.
While playing around with LRA on sparc I noticed that we had some
poorly formed target memory constraints on sparc.
In particular, they were not using define_memory_constraint, so we
would not get a true return from EXTRA_MEMORY_CONSTRAINT for them.
Also, these were matching 'reg' objects for special pseudo treatment.
But the EXTRA_MEMORY_CONSTRAINT logic in reload (and LRA) take care of
that stuff for us.
As a result memory_ok_for_ldd also no longer needs to handle non-MEM
cases.
Committed to master.
* config/sparc/constraints.md (T, W): Change
definitions to use define_memory_constraint. Do not match
'reg'.
* config/sparc/sparc.c (memory_ok_for_ldd): Remove all non-MEM
handling code, update comment.
---
gcc/ChangeLog | 8
gcc/config/sparc/constraints.md | 8
gcc/config/sparc/sparc.c| 25 +++--
3 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9b780ee..e5714c5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2012-10-23 David S. Miller da...@davemloft.net
+
+ * config/sparc/constraints.md (T, W): Change
+ definitions to use define_memory_constraint. Do not match
+ 'reg'.
+ * config/sparc/sparc.c (memory_ok_for_ldd): Remove all non-MEM
+ handling code, update comment.
+
2012-10-23 Ian Lance Taylor i...@google.com
* doc/extend.texi (Extended Asm): The '+' constraint does not
diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md
index 472490f..ffe5304 100644
--- a/gcc/config/sparc/constraints.md
+++ b/gcc/config/sparc/constraints.md
@@ -132,10 +132,10 @@
(match_test fp_high_losum_p (op
;; Not needed in 64-bit mode
-(define_constraint T
+(define_memory_constraint T
Memory reference whose address is aligned to 8-byte boundary
(and (match_test TARGET_ARCH32)
- (match_code mem,reg)
+ (match_code mem)
(match_test memory_ok_for_ldd (op
;; Not needed in 64-bit mode
@@ -148,9 +148,9 @@
(match_test register_ok_for_ldd (op
;; Equivalent to 'T' but available in 64-bit mode
-(define_constraint W
+(define_memory_constraint W
Memory reference for 'e' constraint floating-point register
- (and (match_code mem,reg)
+ (and (match_code mem)
(match_test memory_ok_for_ldd (op
(define_constraint Y
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 8849c03..272632e 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -8065,29 +8065,18 @@ register_ok_for_ldd (rtx reg)
return 1;
}
-/* Return 1 if OP is a memory whose address is known to be
- aligned to 8-byte boundary, or a pseudo during reload.
- This makes it suitable for use in ldd and std insns. */
+/* Return 1 if OP, a MEM, has an address which is known to be
+ aligned to an 8-byte boundary. */
int
memory_ok_for_ldd (rtx op)
{
- if (MEM_P (op))
-{
- /* In 64-bit mode, we assume that the address is word-aligned. */
- if (TARGET_ARCH32 !mem_min_alignment (op, 8))
- return 0;
+ /* In 64-bit mode, we assume that the address is word-aligned. */
+ if (TARGET_ARCH32 !mem_min_alignment (op, 8))
+return 0;
- if (! can_create_pseudo_p ()
- !strict_memory_address_p (Pmode, XEXP (op, 0)))
- return 0;
-}
- else if (REG_P (op) REGNO (op) = FIRST_PSEUDO_REGISTER)
-{
- if (!(reload_in_progress reg_renumber [REGNO (op)] 0))
- return 0;
-}
- else
+ if (! can_create_pseudo_p ()
+ !strict_memory_address_p (Pmode, XEXP (op, 0)))
return 0;
return 1;
--
1.7.12.2.dirty
