backported fix to fold-const.c breaks gcc 4.6
Well, at least with my cross it does. this change, or something like it: http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=09a77c2ea0b41fdff8820cbcbe41b35762db5c45 introduces a reference to TS_TYPED into the 4.6 branch for fold-const.c, and it isnt defined, or at least neither I nor my compiler can find it. Any helpful hints on how to proceed?
Re: backported fix to fold-const.c breaks gcc 4.6
On Mon, Feb 27, 2012 at 10:00 AM, Peter Garbett wrote: > Well, at least with my cross it does. > > this change, or something like it: > > http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=09a77c2ea0b41fdff8820cbcbe41b35762db5c45 > > introduces a reference to TS_TYPED into the 4.6 branch for > fold-const.c, and it isnt defined, > or at least neither I nor my compiler can find it. > > > Any helpful hints on how to proceed? That backport looks bogus and should be reverted. Richard.
Re: backported fix to fold-const.c breaks gcc 4.6
Thanks for the prompt and indeed helpful hint. I'll comment the offending line out locally for now. On Mon, Feb 27, 2012 at 9:08 AM, Richard Guenther wrote: > On Mon, Feb 27, 2012 at 10:00 AM, Peter Garbett > wrote: >> Well, at least with my cross it does. >> >> this change, or something like it: >> >> http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=09a77c2ea0b41fdff8820cbcbe41b35762db5c45 >> >> introduces a reference to TS_TYPED into the 4.6 branch for >> fold-const.c, and it isnt defined, >> or at least neither I nor my compiler can find it. >> >> >> Any helpful hints on how to proceed? > > That backport looks bogus and should be reverted. > > Richard.
Re: backported fix to fold-const.c breaks gcc 4.6
On Mon, Feb 27, 2012 at 10:08 AM, Richard Guenther wrote: >> Well, at least with my cross it does. >> >> this change, or something like it: >> >> http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=09a77c2ea0b41fdff8820cbcbe41b35762db5c45 >> >> introduces a reference to TS_TYPED into the 4.6 branch for >> fold-const.c, and it isnt defined, >> or at least neither I nor my compiler can find it. >> >> >> Any helpful hints on how to proceed? > > That backport looks bogus and should be reverted. Oops. it looks I didn't test this with --enable-checking=fold. However, reverting this will again trigger PR51118 - using TREE_TYPE on wrong expression. Is there equivalent to TS_TYPED on 4.6- ? Uros.
Re: backported fix to fold-const.c breaks gcc 4.6
On Mon, Feb 27, 2012 at 10:28 AM, Uros Bizjak wrote: > On Mon, Feb 27, 2012 at 10:08 AM, Richard Guenther > wrote: >>> Well, at least with my cross it does. >>> >>> this change, or something like it: >>> >>> http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=09a77c2ea0b41fdff8820cbcbe41b35762db5c45 >>> >>> introduces a reference to TS_TYPED into the 4.6 branch for >>> fold-const.c, and it isnt defined, >>> or at least neither I nor my compiler can find it. >>> >>> >>> Any helpful hints on how to proceed? >> >> That backport looks bogus and should be reverted. > > Oops. it looks I didn't test this with --enable-checking=fold. > However, reverting this will again trigger PR51118 - using TREE_TYPE > on wrong expression. Is there equivalent to TS_TYPED on 4.6- ? It's not important to fix ice-checking ICEs on branches, less even with non-standard checking options. So just leave it unfixed. Richard. > Uros.
Re: backported fix to fold-const.c breaks gcc 4.6
On Mon, Feb 27, 2012 at 10:45 AM, Richard Guenther wrote: Well, at least with my cross it does. this change, or something like it: http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=09a77c2ea0b41fdff8820cbcbe41b35762db5c45 introduces a reference to TS_TYPED into the 4.6 branch for fold-const.c, and it isnt defined, or at least neither I nor my compiler can find it. Any helpful hints on how to proceed? >>> >>> That backport looks bogus and should be reverted. >> >> Oops. it looks I didn't test this with --enable-checking=fold. >> However, reverting this will again trigger PR51118 - using TREE_TYPE >> on wrong expression. Is there equivalent to TS_TYPED on 4.6- ? > > It's not important to fix ice-checking ICEs on branches, less even > with non-standard checking options. So just leave it unfixed. OK, I will revert the patch immediatelly, under assumption that your mail grants RM approval for 4.6 branch. Uros.
Re: backported fix to fold-const.c breaks gcc 4.6
On Mon, Feb 27, 2012 at 10:48:35AM +0100, Uros Bizjak wrote: > OK, I will revert the patch immediatelly, under assumption that your > mail grants RM approval for 4.6 branch. Yes, the reversion is fine. Jakub
GCC 4.7.0 Status Report (2012-02-27)
Status == The trunk is still in regression and documentation fixes only state (so-called stage4). We have reached a point where it is sufficiently stable for a first release candidate. If there appear no serious release blockers in the next few days expect a release candidate this week. As soon as the release candidate is made all further changes to trunk will require explicit release-manager approval. This means it is a good idea to stabilize your non-primary/secondary targets now, otherwise you will be left behind with a release that is broken for your target. We do have still P1 classified bugs, but easy workarounds are possible for them or they have a patch already. Quality Data Priority # Change from Last Report --- --- P12 - 3 P2 70 + 6 P32 - 9 --- --- Total74 - 6 Previous Report === http://gcc.gnu.org/ml/gcc/2012-01/msg00337.html The next report will be sent by Jakub.
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
>
>
>
Parma Polyhedra Library 0.12
The core development team is very pleased to announce the availability of PPL 0.12, a new release of the Parma Polyhedra Library. This release includes portability improvements, a few bug fixes, and performance improvements for the MIP and PIP solvers. and PIP solvers. Configurability has also been improved, especially as far as the detection of GMP is concerned. ECLAIR (http://bugseng.com/products/eclair) has been introduced into the development workflow to bring the PPL into conformance with the applicable rules in MISRA, CERT, NASA/JPL, ESA/BSSC and other widely-used coding standards. The precise list of user-visible changes is available at http://bugseng.com/products/ppl/download/ftp/releases/0.12/NEWS . For more information, please come and visit the new PPL web site at http://bugseng.com/products/ppl On behalf of all the past and present developers listed at http://bugseng.com/products/ppl/credits and in the file CREDITS, Roberto Bagnara Patricia M. Hill Enea Zaffanella Abramo Bagnara BUGSENG srl (http://bugseng.com) -- Prof. Roberto Bagnara Applied Formal Methods Laboratory - University of Parma, Italy mailto:bagn...@cs.unipr.it BUGSENG srl - http://bugseng.com mailto:roberto.bagn...@bugseng.com
Re: [ARM] EABI and the default to short enums
Sorry for being late to the party. On Wed, Feb 15, 2012 at 9:55 AM, Ian Lance Taylor wrote: > Ouch, I did not know that the EABI left this open. That seems like a > bug, because it prevents code from being interoperable. This is > precisely the kind of thing an ABI should address. Does anybody know > why they did this? It's a matter of platform variants. There are a sufficient number of ARM use cases where the extra bytes matter (or else, there are a sufficient number of ARM vendors / customers who feel that it matters). But there's also cases like Linux where the advantages of int-sized enums outweigh the space cost. So the platform ABI supplement is supposed to decide. I believe that the Linux variant has other deviations from base than just this. The one I remember in particular is TLS models but there may be others. Please check the full range of differences before you decide which would be a better base for RTEMS. -- Thanks, Daniel
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;
> > 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.
>
Bill,
Thanks a lot for your explanation!
The bug could be exposed with -O2 if you apply the check-in r184435 made by
Richard.
BTW, at present is there anybody working on the NEW pass replacing dom? If no,
in short term, it would be good to still get it fixed just because it is
hurting benchmark. If Yes, may I know what that NEW pass will be focusing on?
Thanks,
-Jiangning
> Thanks,
> Bill
>
> > Thanks,
> > -Jiangning
> >
> >
> >
>
random commentary on -fsplit-stack (and a bug report)
Hello. A couple years ago I got really excited about the gcc "split stacks"
feature that was being developed, and I recently noticed that it is ready to
use now. I thereby have been spending the last few days trying it with one of
my side-projects (currently just a toy, but something I hope to have in
production one day: an event mediator that makes usage of light-weight
coroutine-based threads to implement various protocols).
Yesterday, I integrated support for the new -fsplit-stacks libgcc
__splitstack_*context functions (the ones that were added to allow coroutine
libraries to save/restore the splitstack context; I've linked to the relevant
mailing list threads below this paragraph), and I noticed that using
__splitstack_releasecontext didn't actually seem to cause anything to get
deallocated (watching with strace: mmap, no munmap).
http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg20517.html
http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg21898.html
After staring at it some in gdb, I figured out why: a pointer is being passed
as if it were a pointer to a pointer rather than a direct pointer, obscured and
not found by the compiler because it is being cast and marshaled through the
void *[10] array that is used to store split stack contexts (which, btw, might
be better represented internally as a struct, to avoid issues like this ;P).
223 __thread struct stack_segment *__morestack_segments
224 __attribute__ ((visibility ("default")));
... ...
992 __splitstack_getcontext (void *context[NUMBER_OFFSETS])
993 {
994 memset (context, 0, NUMBER_OFFSETS * sizeof (void *));
995 context[MORESTACK_SEGMENTS] = (void *) __morestack_segments;
... ...
1105 __splitstack_releasecontext (void *context[10])
1106 {
1107 __morestack_release_segments (context[MORESTACK_SEGMENTS], 1);
... ...
441 struct dynamic_allocation_blocks *
442 __morestack_release_segments (struct stack_segment **pp, int
free_dynamic)
As demonstrated by these snippets, __morestack_segments is a pointer to a
stack_segment; it is being stored in the context as a void *, but is being
removed from the context and being passed directly to
__morestack_release_segments, which in turn expects a pointer to a pointer to a
stack_segment, not just a bare pointer to a stack segment. Probably quite
simple to fix (although might be more complex than just "add a &").
While I am sending an e-mail regarding -fsplit-stack, though, I figured I would
also mention some design issues I've noticed while using it. Some of these may
just be "me being stupid" (as I've only been looking at this in depth over the
last few days), but I at least have had this idea "on the back burner" for a
long time now, and am actually integrating and consuming the APIs that are
resulting. Feel free to ignore me.
1) The current implementation (maybe this is intended to change?) uses mmap()
to allocate stack segments, which means that every allocation involves a system
call, a lock in the kernel on a slow data structure (anon_vma), and has some
non-zero probability of ending up with a separate VMA (which is not only slow,
but in my understanding uses up a limited resource: you can only have 64k VMAs
per process).
Is it possible to instead expose the functionality for allocating stack
segments out of libgcc for easy replacement by coroutine runtimes? I would
really love to be able to use my existing memory manager to allocate the stack
segments. I realize that this allocation routine would need to be able to
operate with almost no stack: that isn't a problem (I can always pivot to
another stack if I need any stack).
2) I had seen a discussion on the mailing list regarding argument copying, and
I must say I'm somewhat confused as to why it is sufficient to memcpy the
arguments from the old stack to the new one: if I have an argument with a
non-POD type that has a non-trivial copy constructor, it would seem like I need
a copy operation to be able to use the object from the new stack (maybe, for
example, it has an internal pointer).
3) If I have either blocked signals on my thread or have setup an alternate
signal stack with sigaltstack, I can get away with super-tiny stacks. However,
allocate_segment has a minimum stack size of MINSIGSTKSZ (I presume to allow
for signals), which on some systems I use (such as Mac OS X) I've seen be set
as high as 32kB. (Meanwhile, MINSIGSTKSZ on Linux is smaller than a page, so
mmap() can't even allocate it.)
4) 10 64-bit words for the splitstack context is a really large amount of
space. :( I don't even have that much CPU-state (there are only 8 registers
that really need to be saved when switching between coroutines). Considering
the stack segments form a doubly-linked-list, it would seem like
MORESTACK_SEGMENTS and CURRENT_SEGMENT are redundant. I also feel like
CURRENT_STACK could be worked around fairly well.
5) As currently
