Recovering REG_EXPR information after temporary expression replacement
A member of our team was working on some switch statement optimizations,
and ran into a situation that seems a little curious on the face of it.
Consider these two test variants:
int
test_switch_1 (unsigned int *index, int i)
{
switch (*index)
{
case 0:
return i;
case 1:
return i+1;
case 2:
return i+2;
default:
return i+3;
}
}
int
test_switch_2 (unsigned int *index, int i)
{
switch (*index)
{
case 0:
return i;
case 1:
return i+1;
case 2:
return i+2;
default:
return *index+3;
}
}
For the second case we see the following from expand. The key point is
that reg:SI 120 has a REG_EXPR of D.2004, which allows getting type
information from the original decl of D.2004:
;; D.2004_3 = *index_2(D);
(insn 7 6 0 (set (reg:SI 120 [ D.2004 ])
(mem:SI (reg/v/f:SI 123 [ index ]) [2 *index_2(D)+0 S4 A32]))
t2.i:4 -1
(nil))
;; switch (D.2004_3) , case 0: , case 1: , case 2:
>
(insn 8 7 9 (set (reg:CCUNS 125)
(compare:CCUNS (reg:SI 120 [ D.2004 ])
(const_int 1 [0x1]))) t2.i:4 -1
(nil))
However, for the first case, temporary expression replacement has
effectively removed the assignment to D.2004_3 (single local immediate
use permits replacement), so instead we see:
;; switch (D.2004_3) , case 0: , case 1: , case 2:
>
(insn 7 6 8 (set (reg:SI 124)
(mem:SI (reg/v/f:SI 122 [ index ]) [2 *index_2(D)+0 S4 A32]))
t1.i:4 -1
(nil))
(insn 8 7 9 (set (reg:CC 125)
(compare:CC (reg:SI 124)
(const_int 1 [0x1]))) t1.i:4 -1
(nil))
The REG_EXPR is missing for reg:SI 124, so the type information for
D.2004 can't be recovered.
I am not very familiar with all the ins and outs of expand, so it's not
clear to me whether this is necessary. It seems to me that it would be
theoretically possible to attach the REG_EXPR data here when doing the
TER lookup while expanding the switch, but perhaps there are reasons why
that's difficult.
It would be a nice enhancement if the REG_EXPR could be preserved in
such cases. Does anyone know if there's something that would prevent
this?
Thanks!
Bill
Re: Recovering REG_EXPR information after temporary expression replacement
Great, thanks! Results are good on this specific test case. Seems like
a nice thing to add in 4.8.
On Fri, 2012-01-27 at 18:40 +0100, Michael Matz wrote:
> Hi,
>
> On Fri, 27 Jan 2012, William J. Schmidt wrote:
>
> >
> > int
> > test_switch_1 (unsigned int *index, int i)
> > {
> > switch (*index)
> ...
> > However, for the first case, temporary expression replacement has
> > effectively removed the assignment to D.2004_3 (single local immediate
> > use permits replacement), so instead we see:
> >
> >
> > ;; switch (D.2004_3) , case 0: , case 1: , case 2:
> > >
> >
> > (insn 7 6 8 (set (reg:SI 124)
> > (mem:SI (reg/v/f:SI 122 [ index ]) [2 *index_2(D)+0 S4 A32]))
> > t1.i:4 -1
>
> With TER there is no decl anymore to associate the pseudo with.
> Conceptually, what's expanded is "*index", not an assignment to a pseudo.
> The move into a pseudo (and the creation of that very pseudo) is done by
> copy_to_reg in expand_case.
>
> > It would be a nice enhancement if the REG_EXPR could be preserved in
> > such cases. Does anyone know if there's something that would prevent
> > this?
>
> The hack below works in this specific situation (TERed into a switch), and
> adds a REG_EXPR when an TERed SSA name ever expanded into a pseudo (i.e.
> also for some more generic situations).
>
>
> Ciao,
> Michael.
> Index: expr.c
> ===
> --- expr.c(revision 183559)
> +++ expr.c(working copy)
> @@ -8991,8 +8991,13 @@ expand_expr_real_1 (tree exp, rtx target
> && stmt_is_replaceable_p (SSA_NAME_DEF_STMT (exp)))
> g = SSA_NAME_DEF_STMT (exp);
>if (g)
> - return expand_expr_real (gimple_assign_rhs_to_tree (g), target, tmode,
> - modifier, NULL);
> + {
> + rtx r = expand_expr_real (gimple_assign_rhs_to_tree (g), target,
> + tmode, modifier, NULL);
> + if (REG_P (r) && !REG_EXPR (r))
> + set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (exp), r);
> + return r;
> + }
>
>ssa_name = exp;
>decl_rtl = get_rtx_for_ssa_name (ssa_name);
> Index: stmt.c
> ===
> --- stmt.c(revision 183559)
> +++ stmt.c(working copy)
> @@ -2381,7 +2381,11 @@ expand_case (gimple stmt)
> do_pending_stack_adjust ();
>
> if (MEM_P (index))
> - index = copy_to_reg (index);
> + {
> + index = copy_to_reg (index);
> + if (TREE_CODE (index_expr) == SSA_NAME)
> + set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (index_expr), index);
> + }
>
> /* We generate a binary decision tree to select the
>appropriate target code. This is done as follows:
>
Re: A question about redundant PHI expression stmt
On Fri, 2012-02-24 at 16:07 +0800, Jiangning Liu wrote:
> Hi,
>
> For the small case below, there are some redundant PHI expression stmt
> generated, and finally cause back-end generates redundant copy instructions
> due to some reasons around IRA.
>
> int *l, *r, *g;
> void test_func(int n)
> {
> int i;
> static int j;
> static int pos, direction, direction_pre;
>
> pos = 0;
> direction = 1;
>
> for ( i = 0; i < n; i++ )
> {
> direction_pre = direction;
>
> for ( j = 0; j <= 400; j++ )
> {
>
> if ( g[pos] == 200 )
> break;
>
> if ( direction == 0 )
> pos = l[pos];
> else
> pos = r[pos];
>
> if ( pos == -1 )
> {
> if ( direction_pre != direction )
> break;
>
> pos = 0;
> direction = !direction;
> }
>
> }
>
> f(g[pos]);
> }
> }
>
> I know PR39976 has something to do with this case, and check-in r182140
> caused big degradation on the real benchmark, but I'm still confusing around
> this issue.
>
> The procedure is like this,
>
> Loop store motion generates code below,
>
> :
> D.4084_17 = l.4_13 + D.4077_70;
> pos.5_18 = *D.4084_17;
> pos_lsm.34_103 = pos.5_18;
> goto ;
>
> :
> D.4088_23 = r.6_19 + D.4077_70;
> pos.7_24 = *D.4088_23;
> pos_lsm.34_104 = pos.7_24;
>
> :
> # prephitmp.29_89 = PHI
> # pos_lsm.34_53 = PHI
> pos.2_25 = prephitmp.29_89;
> if (pos.2_25 == -1)
> goto ;
> else
> goto ;
>
> And then, copy propagation transforms block 8 it into
>
> :
> # prephitmp.29_89 = PHI
> # pos_lsm.34_53 = PHI
> ...
>
> And then, these two duplicated PHI stmts have been kept until expand pass.
>
> In dom2, a stmt like below
>
> # pos_lsm.34_54 = PHI
>
> is transformed into
>
> # pos_lsm.34_54 = PHI
>
> just because they are equal.
>
> Unfortunately, this transformation changed back-end behavior to generate
> redundant copy instructions and hurt performance. This case is from a real
> benchmark and hurt performance a lot.
>
> Does the fix in r182140 intend to totally clean up this kind of redundancy?
> Where should we get it fixed?
>
Hi, sorry not to have responded sooner -- I just now got some time to
look at this.
I compiled your code with -O3 for revisions 182139 and 182140 of GCC
trunk, and found no difference between the code produced by the middle
end for the two versions. So something else has apparently come along
since then that helped produce the problematic code generation for you.
Either that or I need to use different compile flags; you didn't specify
what you used.
The fix in r182140 does just what you saw in dom2: identifies duplicate
PHIs in the same block and ensures only one of them is used. This
actually avoids inserting extra blocks during expand in certain loop
cases. I am not sure why you are getting redundant copies as a result,
but it sounds from your comments like IRA didn't coalesce a register
copy or something like that. You may want to bisect revisions on the
trunk to see where your bad code generation started to occur to get a
better handle on what happened.
As Richard said, the dom pass is likely to be removed someday, whenever
someone can get around to it. My redundant-phi band-aid in dom would go
away then as well, but presumably an extra pass of PRE would replace it,
and redundant PHIs would still be removed.
Thanks,
Bill
> Thanks,
> -Jiangning
>
>
>
Re: A question about redundant PHI expression stmt
On Tue, 2012-02-28 at 11:21 +0100, Richard Guenther wrote:
> On Tue, Feb 28, 2012 at 9:33 AM, Jiangning Liu wrote:
> >
> >
> >> -Original Message-
> >> From: Jiangning Liu
> >> Sent: Tuesday, February 28, 2012 4:07 PM
> >> To: Jiangning Liu; 'William J. Schmidt'
> >> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> >> Subject: RE: A question about redundant PHI expression stmt
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> >> Of
> >> > Jiangning Liu
> >> > Sent: Tuesday, February 28, 2012 11:19 AM
> >> > To: 'William J. Schmidt'
> >> > Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> >> > Subject: RE: A question about redundant PHI expression stmt
> >> >
> >> >
> >> >
> >> > > -Original Message-
> >> > > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> >> Behalf
> >> > Of
> >> > > William J. Schmidt
> >> > > Sent: Monday, February 27, 2012 11:32 PM
> >> > > To: Jiangning Liu
> >> > > Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> >> > > Subject: Re: A question about redundant PHI expression stmt
> >> > >
> >> > > On Fri, 2012-02-24 at 16:07 +0800, Jiangning Liu wrote:
> >> > > > Hi,
> >> > > >
> >> > > > For the small case below, there are some redundant PHI expression
> >> > > stmt
> >> > > > generated, and finally cause back-end generates redundant copy
> >> > > instructions
> >> > > > due to some reasons around IRA.
> >> > > >
> >> > > > int *l, *r, *g;
> >> > > > void test_func(int n)
> >> > > > {
> >> > > > int i;
> >> > > > static int j;
> >> > > > static int pos, direction, direction_pre;
> >> > > >
> >> > > > pos = 0;
> >> > > > direction = 1;
> >> > > >
> >> > > > for ( i = 0; i < n; i++ )
> >> > > > {
> >> > > > direction_pre = direction;
> >> > > >
> >> > > > for ( j = 0; j <= 400; j++ )
> >> > > > {
> >> > > >
> >> > > > if ( g[pos] == 200 )
> >> > > > break;
> >> > > >
> >> > > > if ( direction == 0 )
> >> > > > pos = l[pos];
> >> > > > else
> >> > > > pos = r[pos];
> >> > > >
> >> > > > if ( pos == -1 )
> >> > > > {
> >> > > > if ( direction_pre != direction )
> >> > > > break;
> >> > > >
> >> > > > pos = 0;
> >> > > > direction = !direction;
> >> > > > }
> >> > > >
> >> > > > }
> >> > > >
> >> > > > f(g[pos]);
> >> > > > }
> >> > > > }
> >> > > >
> >> > > > I know PR39976 has something to do with this case, and check-in
> >> > > r182140
> >> > > > caused big degradation on the real benchmark, but I'm still
> >> > confusing
> >> > > around
> >> > > > this issue.
> >> > > >
> >> > > > The procedure is like this,
> >> > > >
> >> > > > Loop store motion generates code below,
> >> > > >
> >> > > > :
> >> > > > D.4084_17 = l.4_13 + D.4077_70;
> >> > > > pos.5_18 = *D.4084_17;
> >> > > > pos_lsm.34_103 = pos.5_18;
> >> > > > goto ;
> >> > > >
> >> > > > :
> >> > > > D.4088_23 = r.6_19 + D.4077_70;
> >>
Re: A question about redundant PHI expression stmt
On Tue, 2012-02-28 at 11:03 -0600, William J. Schmidt wrote: > I think this is probably a problem with how cprop_into_successor_phis > works. It only propagates into immediate successors of a block. In > this case copies are propagated from bb12 into phis in bb13 and bb14 (of > which there are none). Seems like it could propagate into phis of all > dominator children, which would catch bb15. I haven't looked at this > part of the code in too much detail, but I'm guessing since bb15's > immediate dominator is bb12, this is the last chance to get the value > propagated into the phi. > > When I get more time, I'll walk through the logic for this test to > confirm, and post here with the results. > > If this is the problem, then I doubt anything will be fixed for this in > the limited time left for 4.7. You'd want to open a missed-optimization > PR for it. No, this isn't right. I see in the dump that the copy is being removed from the const_and_copies_table after processing block 13 and before processing block 14. That's presumably a bug. I'll keep looking. Bill
Re: A question about redundant PHI expression stmt
On Tue, 2012-02-28 at 11:52 -0600, William J. Schmidt wrote: > On Tue, 2012-02-28 at 11:03 -0600, William J. Schmidt wrote: > > > I think this is probably a problem with how cprop_into_successor_phis > > works. It only propagates into immediate successors of a block. In > > this case copies are propagated from bb12 into phis in bb13 and bb14 (of > > which there are none). Seems like it could propagate into phis of all > > dominator children, which would catch bb15. I haven't looked at this > > part of the code in too much detail, but I'm guessing since bb15's > > immediate dominator is bb12, this is the last chance to get the value > > propagated into the phi. > > > > When I get more time, I'll walk through the logic for this test to > > confirm, and post here with the results. > > > > If this is the problem, then I doubt anything will be fixed for this in > > the limited time left for 4.7. You'd want to open a missed-optimization > > PR for it. > > No, this isn't right. I see in the dump that the copy is being removed > from the const_and_copies_table after processing block 13 and before > processing block 14. That's presumably a bug. I'll keep looking. > OK, I see the problem. We have a long-standing bug in dom's use of edge threading, which quietly corrupts the const_and_copy stack. I'll create a bug report and post a patch for you to try out. My testing shows that the redundant phi is properly handled now, but let's see if it solves your performance issue. Thanks, Bill > Bill
Question about bitsizetype
Greetings,
I've been debugging a Fedora 17 build problem on ppc64-redhat-linux, and
ran into an issue with bitsizetype. I have a patch that fixes the
problem, but I'm not yet convinced it's the right fix. I'm hoping
someone here can help me sort it out.
The problem occurs when compiling some Java code at -O3. The symptom is
a segv during predictive commoning. The problem comes when analyzing a
data dependence between two field references. The access functions for
the data refs are determined in tree-data-ref.c: dr_analyze_indices ():
else if (TREE_CODE (ref) == COMPONENT_REF
&& TREE_CODE (TREE_TYPE (TREE_OPERAND (ref, 0))) == RECORD_TYPE)
{
/* For COMPONENT_REFs of records (but not unions!) use the
FIELD_DECL offset as constant access function so we can
disambiguate a[i].f1 and a[i].f2. */
tree off = component_ref_field_offset (ref);
off = size_binop (PLUS_EXPR,
size_binop (MULT_EXPR,
fold_convert (bitsizetype, off),
bitsize_int (BITS_PER_UNIT)),
DECL_FIELD_BIT_OFFSET (TREE_OPERAND (ref, 1)));
VEC_safe_push (tree, heap, access_fns, off);
}
Note the use of bitsizetype. On a 64-bit target that defines TImode,
this is apparently set to a 128-bit unsigned type, verified in gdb:
(gdb) ptr bitsizetype
constant 128>
unit size constant 16>
align 128 symtab 0 alias set -1 canonical type 0xfffb5d700a8
precision 128 min max >
The problem arises in tree-data-ref.c: analyze_ziv_subscript:
type = signed_type_for_types (TREE_TYPE (chrec_a), TREE_TYPE (chrec_b));
chrec_a = chrec_convert (type, chrec_a, NULL);
chrec_b = chrec_convert (type, chrec_b, NULL);
difference = chrec_fold_minus (type, chrec_a, chrec_b);
Both input types are bitsizetype of mode TImode. This call reduces to a
call to tree.c: signed_or_unsigned_type_for ():
return lang_hooks.types.type_for_size (TYPE_PRECISION (t), unsignedp);
So this is the interesting point. We are calling back to the front end
to find a type having the same precision as bitsizetype, in this case
128. The C lang hook handles this fine, but the Java one does not:
tree
java_type_for_size (unsigned bits, int unsignedp)
{
if (bits <= TYPE_PRECISION (byte_type_node))
return unsignedp ? unsigned_byte_type_node : byte_type_node;
if (bits <= TYPE_PRECISION (short_type_node))
return unsignedp ? unsigned_short_type_node : short_type_node;
if (bits <= TYPE_PRECISION (int_type_node))
return unsignedp ? unsigned_int_type_node : int_type_node;
if (bits <= TYPE_PRECISION (long_type_node))
return unsignedp ? unsigned_long_type_node : long_type_node;
return 0;
}
This returns zero, causing the first call to chrec_convert in
analyze_ziv_subscript to segfault.
I can cause the build to succeed with the following patch...
Index: gcc/java/typeck.c
===
--- gcc/java/typeck.c (revision 187158)
+++ gcc/java/typeck.c (working copy)
@@ -189,6 +189,12 @@ java_type_for_size (unsigned bits, int unsignedp)
return unsignedp ? unsigned_int_type_node : int_type_node;
if (bits <= TYPE_PRECISION (long_type_node))
return unsignedp ? unsigned_long_type_node : long_type_node;
+ /* A 64-bit target with TImode requires 128-bit type definitions
+ for bitsizetype. */
+ if (int128_integer_type_node
+ && bits == TYPE_PRECISION (int128_integer_type_node))
+return (unsignedp ? int128_unsigned_type_node
+ : int128_integer_type_node);
return 0;
}
...but I wonder whether this is the correct approach. Is the problem
really that the lang hook is missing handling for bitsizetype for
certain targets, or is the problem that bitsizetype is 128 bits? All of
the other front ends seem to get along fine with a 128-bit bitsizetype;
it's just kind of an odd choice on a 64-bit machine. Or is the problem
in the dr_analyze_indices code that's using bitsizetype?
The thing that gives me pause here is that other machines would likely
have the same problem. Any machine using a 128-bit bitsizetype would
hit this problem sooner or later when optimizing Java code. Perhaps
it's just that few people compile Java statically anymore -- certainly
we don't even build it during normal development.
I had myself convinced that all 64-bit machines with a TImode would have
a 128-bit bitsizetype, but I'm having trouble connecting the dots on
that at the moment, so that may or may not be true. If it is, though,
then this would seemingly come up periodically on Intel building Java.
That makes me suspicious that I don't understand this well enough yet.
Thanks in advance for any help! I'd like to get this resolved quickly
for the Fedora folks, but I want to do it properly.
Thanks,
Bill
Re: Question about bitsizetype
On Wed, 2012-05-09 at 13:47 -0700, Andrew Pinski wrote:
> On Wed, May 9, 2012 at 1:36 PM, William J. Schmidt
> wrote:
> > Greetings,
> >
> > I've been debugging a Fedora 17 build problem on ppc64-redhat-linux, and
> > ran into an issue with bitsizetype. I have a patch that fixes the
> > problem, but I'm not yet convinced it's the right fix. I'm hoping
> > someone here can help me sort it out.
> >
> > The problem occurs when compiling some Java code at -O3. The symptom is
> > a segv during predictive commoning. The problem comes when analyzing a
> > data dependence between two field references. The access functions for
> > the data refs are determined in tree-data-ref.c: dr_analyze_indices ():
> >
> > else if (TREE_CODE (ref) == COMPONENT_REF
> > && TREE_CODE (TREE_TYPE (TREE_OPERAND (ref, 0))) ==
> > RECORD_TYPE)
> >{
> > /* For COMPONENT_REFs of records (but not unions!) use the
> > FIELD_DECL offset as constant access function so we can
> > disambiguate a[i].f1 and a[i].f2. */
> > tree off = component_ref_field_offset (ref);
> > off = size_binop (PLUS_EXPR,
> >size_binop (MULT_EXPR,
> >fold_convert (bitsizetype, off),
> >bitsize_int (BITS_PER_UNIT)),
> >DECL_FIELD_BIT_OFFSET (TREE_OPERAND (ref, 1)));
> > VEC_safe_push (tree, heap, access_fns, off);
> >}
> >
> > Note the use of bitsizetype. On a 64-bit target that defines TImode,
> > this is apparently set to a 128-bit unsigned type, verified in gdb:
> >
> > (gdb) ptr bitsizetype
> > >size > bitsizetype> constant 128>
> >unit size > 0xfffb5d7 sizetype> constant 16>
> >align 128 symtab 0 alias set -1 canonical type 0xfffb5d700a8
> > precision 128 min max > 0xfffb5c82360 -1>>
> >
> > The problem arises in tree-data-ref.c: analyze_ziv_subscript:
> >
> > type = signed_type_for_types (TREE_TYPE (chrec_a), TREE_TYPE (chrec_b));
> > chrec_a = chrec_convert (type, chrec_a, NULL);
> > chrec_b = chrec_convert (type, chrec_b, NULL);
> > difference = chrec_fold_minus (type, chrec_a, chrec_b);
> >
> > Both input types are bitsizetype of mode TImode. This call reduces to a
> > call to tree.c: signed_or_unsigned_type_for ():
> >
> > return lang_hooks.types.type_for_size (TYPE_PRECISION (t), unsignedp);
>
> And that was fixed by not calling type_for_size with the following patch:
> r185226 | rguenth | 2012-03-12 06:04:43 -0700 (Mon, 12 Mar 2012) | 9 lines
>
> 2012-03-12 Richard Guenther
>
> * tree.c (signed_or_unsigned_type_for): Use
> build_nonstandard_integer_type.
> (signed_type_for): Adjust documentation.
> (unsigned_type_for): Likewise.
> * tree-pretty-print.c (dump_generic_node): Use standard names
> for non-standard integer types if available.
> Thanks,
> Andrew Pinski
>
>
Ah, Andrew, you're a life-saver. Thanks!
Bill
>
> >
> > So this is the interesting point. We are calling back to the front end
> > to find a type having the same precision as bitsizetype, in this case
> > 128. The C lang hook handles this fine, but the Java one does not:
> >
> > tree
> > java_type_for_size (unsigned bits, int unsignedp)
> > {
> > if (bits <= TYPE_PRECISION (byte_type_node))
> >return unsignedp ? unsigned_byte_type_node : byte_type_node;
> > if (bits <= TYPE_PRECISION (short_type_node))
> >return unsignedp ? unsigned_short_type_node : short_type_node;
> > if (bits <= TYPE_PRECISION (int_type_node))
> >return unsignedp ? unsigned_int_type_node : int_type_node;
> > if (bits <= TYPE_PRECISION (long_type_node))
> >return unsignedp ? unsigned_long_type_node : long_type_node;
> > return 0;
> > }
> >
> > This returns zero, causing the first call to chrec_convert in
> > analyze_ziv_subscript to segfault.
> >
> > I can cause the build to succeed with the following patch...
> >
> > Index: gcc/java/typeck.c
> > ===
> > --- gcc/java/typeck.c (revision 187158)
> > +++ gcc/java/typeck.c (working copy)
> > @@ -189,6 +189,12 @@ java_type_for_size (unsigned bits, int unsignedp)
> > return unsignedp ? unsigned_int_type_node : int_type_node;
> > if (bits <= TYPE_PRECISION (long_type_
Build problem with libgo runtime
I'm investigating another build failure for Fedora 17 (based on 4.7).
The failing compile from the build log is as follows:
/bin/sh ./libtool --tag=CC
--mode=compile
/builddir/build/BUILD/gcc-4.7.0-20120504/obj-ppc64-redhat-linux/./gcc/xgcc
-B/builddir/build/BUILD/gcc-4.7.0-20120504/obj-ppc64-redhat-linux/./gcc/
-B/usr/ppc64-redhat-linux/bin/ -B/usr/ppc64-redhat-linux/lib/ -isystem
/usr/ppc64-redhat-linux/include -isystem /usr/ppc64-redhat-linux/sys-include
-DHAVE_CONFIG_H -I. -I../../../libgo -I ../../../libgo/runtime
-I../../../libgo/../libffi/include -I../libffi/include -pthread -fexceptions
-fplan9-extensions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror
-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I
../../../libgo/../libgcc -I ../../gcc/include -O2 -O3 -mtune=power7
-mcpu=power7 -g -fsigned-char -MT proc.lo -MD -MP -MF .deps/proc.Tpo -c -o
proc.lo `test -f 'runtime/proc.c' || echo '../../../libgo/'`runtime/proc.c
The reported failure:
../../../libgo/runtime/proc.c: In function ‘__go_go’:
../../../libgo/runtime/proc.c:1323:8: error: variable ‘sp’ might be
clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
../../../libgo/runtime/proc.c:1324:9: error: variable ‘spsize’ might be
clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
cc1: all warnings being treated as errors
The declarations in question are:
byte *sp;
size_t spsize;
G * volatile newg; // volatile to avoid longjmp warning
What's interesting here is that I don't see a problem when compiling for
a 32-bit target. However, it's also apparent that making "newg"
volatile was deemed sufficient up till now, so I am wondering if there
is something about our build options/environment that could cause the
problem.
I can work around the problem with the following patch, but would
appreciate any insights into whether this should be necessary, and if
not, what we're doing "wrong."
Thanks!
Bill
*** proc.c.orig 2012-05-10 21:02:13.394995624 -0500
--- proc.c 2012-05-10 21:01:36.050994265 -0500
*** __go_go(void (*fn)(void*), void* arg)
*** 1323,1328
--- 1323,1330
byte *sp;
size_t spsize;
G * volatile newg; // volatile to avoid longjmp warning
+ byte * volatile vsp;
+ size_t volatile vspsize;
schedlock();
*** __go_go(void (*fn)(void*), void* arg)
*** 1363,1374
if(sp == nil)
runtime_throw("nil g->stack0");
getcontext(&newg->context);
! newg->context.uc_stack.ss_sp = sp;
#ifdef MAKECONTEXT_STACK_TOP
! newg->context.uc_stack.ss_sp += spsize;
#endif
! newg->context.uc_stack.ss_size = spsize;
makecontext(&newg->context, kickoff, 0);
newprocreadylocked(newg);
--- 1365,1379
if(sp == nil)
runtime_throw("nil g->stack0");
+ vsp = sp;
+ vspsize = spsize;
+
getcontext(&newg->context);
! newg->context.uc_stack.ss_sp = vsp;
#ifdef MAKECONTEXT_STACK_TOP
! newg->context.uc_stack.ss_sp += vspsize;
#endif
! newg->context.uc_stack.ss_size = vspsize;
makecontext(&newg->context, kickoff, 0);
newprocreadylocked(newg);
Re: GNU MPC 1.0 release candidate - Second call for help
On Sat, 2012-07-14 at 01:00 +0200, Steven Bosscher wrote: > Andreas Enge wrote: > > > > powerpc-ibm-aix5.3.0.0, s390-linux-gnu, > > Perhaps Bill Schmidt can help here? > Unfortunately not, at least not directly. David Bernstein and Andreas Krebbel, respectively, might be able to point you to the right people for these targets. Bill
