Re: Details for svn test repository
* Daniel Berlin: > It's not easier to implement. Trying to translate cvs into changesets > is not easy (though the reverse is), unless you do it the stupid way (IE > not try to discover what is a copy and what isn't). > So matching commit for commit won't give you good history. > Especially on branches. The CVS loginfo script is invoked with a list of files changed in that commit. (I don't think that conversion should be done this way, but it's still an option.)
latent bug in PRE?
Hi!
I have isolated the patch (attached) that caused the previously reported
build ICE and a testcase. The patch enables folding of
&a[i] + cst to &a[i+cst] in addition to &a[i] + cst*j -> &a[i+j].
If enabled, this transformation triggeres two times in the
testcase derived from libiberty/sort.c:
#define UCHAR_MAX ((unsigned char)(-1))
#define DIGIT_MAX (UCHAR_MAX + 1)
void sort_pointers (void)
{
unsigned int count[DIGIT_MAX];
unsigned int *countp;
for (countp = count + 1; countp < count + DIGIT_MAX; ++countp)
;
}
namely transforming
unit size
align 32 symtab 0 alias set -1 precision 32 min max
pointer_to_this >
public unsigned SI size unit size
align 32 symtab 0 alias set -1>
invariant
arg 0
arg 0
addressable used BLK file t.c line 6
size
unit size
align 32 context chain
>
arg 1
arg 2
arg 3 >>
constant invariant 4>
>
to
unit size
align 32 symtab 0 alias set -1 precision 32 min max
pointer_to_this >
public unsigned SI size unit size
align 32 symtab 0 alias set -1>
invariant
arg 0
arg 0
addressable used BLK file t.c line 6
size
unit size
align 32 context chain
>
arg 1
arg 2
arg 3 >>
and
unit size
align 32 symtab 0 alias set -1 precision 32 min max
pointer_to_this >
public unsigned SI size unit size
align 32 symtab 0 alias set -1>
invariant
arg 0
arg 0
addressable used BLK file t.c line 6
size
unit size
align 32 context chain
>
arg 1
arg 2
arg 3 >>
constant invariant 4>
>
to
unit size
align 32 symtab 0 alias set -1 precision 32 min max
pointer_to_this >
public unsigned SI size unit size
align 32 symtab 0 alias set -1>
invariant
arg 0
arg 0
addressable used BLK file t.c line 6
size
unit size
align 32 context chain
>
arg 1
arg 2
arg 3 >>
where I cannot find an errorneous transformation. This triggers
a PRE ICE then:
/tmp/gcc-obj-checking/gcc/cc1 -quiet -v -I.
-I/net/alwazn/home/rguenth/src/gcc/gcc/libiberty/../include -iprefix
/tmp/gcc-obj-checking/gcc/../lib/gcc/i686-pc-linux-gnu/4.0.0/ -isystem
/tmp/gcc-obj-checking/gcc/include -DHAVE_CONFIG_H -isystem
/i686-pc-linux-gnu/include -isystem /i686-pc-linux-gnu/sys-include t.c
-quiet -dumpbase t.c -mtune=pentiumpro -auxbase-strip t.o -g -O2 -W -Wall
-pedantic -version -o /tmp/ccnVnHo2.s -fdump-tree-all
t.c: In function
'sort_pointers':
t.c:5: internal compiler error: in insert_aux, at tree-ssa-pre.c:1624
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
where the dump before pre looks like
sort_pointers ()
{
unsigned int * countp;
unsigned int count[256];
unsigned int * D.1137;
:
# countp_1 = PHI ;
:;
countp_4 = countp_1 + 4B;
if (countp_4 < &count[256]) goto ; else goto ;
:;
goto ();
:;
return;
}
Any idea how to debug what is going wrong? Any PRE expert around?
Thanks,
Richard.
Index: fold-const.c
===
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.511
diff -c -3 -p -r1.511 fold-const.c
*** fold-const.c14 Feb 2005 16:07:08 - 1.511
--- fold-const.c15 Feb 2005 10:15:11 -
*** fold_sign_changed_comparison (enum tree_
*** 6184,6217
}
/* Tries to replace &a[idx] CODE s * delta with &a[idx CODE delta], if s is
!step of the array. ADDR is the address. MULT is the multiplicative
expression.
!If the function succeeds, the new address expression is returned.
Otherwise
!NULL_TREE is returned. */
static tree
! try_move_mult_to_index (enum tree_code code, tree addr, tree mult)
{
! tree s, delta, step;
! tree arg0 = TREE_OPERAND (mult, 0), arg1 = TREE_OPERAND (mult, 1);
tree ref = TREE_OPERAND (addr, 0), pref;
tree ret, pos;
! tree itype;
! STRIP_NOPS (arg0);
! STRIP_NOPS (arg1);
!
! if (TREE_CODE (arg0) == INTEGER_CST)
{
! s = arg0;
! delta = arg1;
}
! else if (TREE_CODE (arg1) == INTEGER_CST)
{
! s = arg1;
! delta = arg0;
}
else
! return NULL_TREE;
for (;; ref = TREE_OPERAND (ref, 0))
{
--- 6184,6229
}
/* Tries to replace &a[idx] CODE s * delta with &a[idx CODE delta], if s is
!step of the array. Also handles the case of &a[idx] CODE delta with
!delta being a constant multiple of the step of the array.
!ADDR is the address. MULT is the multiplicative expressi
Re: latent bug in PRE?
On Tue, 15 Feb 2005, Richard Guenther wrote:
> Hi!
>
> I have isolated the patch (attached) that caused the previously reported
> build ICE and a testcase. The patch enables folding of
> &a[i] + cst to &a[i+cst] in addition to &a[i] + cst*j -> &a[i+j].
> If enabled, this transformation triggeres two times in the
> testcase derived from libiberty/sort.c:
>
> #define UCHAR_MAX ((unsigned char)(-1))
> #define DIGIT_MAX (UCHAR_MAX + 1)
>
> void sort_pointers (void)
> {
> unsigned int count[DIGIT_MAX];
> unsigned int *countp;
>
> for (countp = count + 1; countp < count + DIGIT_MAX; ++countp)
> ;
> }
Ok, stepping through PRE is seems that folding of &count[1]+1 at
tree-ssa-pre:1622 by calling fully_constant_expression on it
will get us &count[2] (obviously) and this one does not have a
value handle, and such we ICE. Wether fully_constant_expression
is in error, or the assert, I do not know. But I guess other
kind of folding could trigger this, too.
One could work around this either by removing the call to
fully_constant_expression or by wrapping this in sth like
tmp = fully_constant_expression (eprime);
vprime = get_value_handle (tmp);
if (!vprime)
vprime = get_value_handle (eprime);
else
eprime = tmp;
gcc_assert(vprime);
at least, this fixes the ICE.
Any ideas?
Thanks,
Richard.
--
Richard Guenther
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
Accessing the subversion repository
Hi, Joern and I are having difficulty accessing the subversion test repository. "svn co svn://svn.toolchain.org/svn/gcc/trunk" does not work due to the ST corporate firewall (don't ask - the wheels turn slowly), so I have been looking for an alternative approach. Is there any alternative to straight svn protocol set up? I know subversion supports them, but I haven't seen anything on the list or wiki announcing it. I have tried "svn co svn+shh://svn.toolchain.org/svn/gcc/trunk", but that does not work either. I appear to have contacted the remote ssh server, but the devtest username and password given do not seem to work. Are they are for svn only?. Or am I missing some settings somewhere? I have also tried "svn co http://svn.toolchain.org/svn/gcc/trunk";, but this is just a guess and receives the response "302 Moved Temporarily" (once I figured out .subversion/servers proxy settings). Is this just the wrong URL? It might be that our proxy does not support DAV? I can access the repository via web browser at http://www.toolchain.org/websvn/listing.php?repname=gcc&path=%2F&sc=0 but that isn't exactly what I had in mind. The subversion book at red-bean seems to cover server setup, but is rather light on client setup (not that I have read it in detail). If no other method currently exists, is there any possibility of getting one set up? Also, once (if) the subversion repository goes 'live' on gcc.gnu.org, is there any plans to support the alternative protocols? Thanks -- Andrew Stubbs [EMAIL PROTECTED]
[PATCH]: Latent bug in value numbering (Was Re: latent bug in PRE?)
On Tue, 2005-02-15 at 11:31 +0100, Richard Guenther wrote:
> On Tue, 15 Feb 2005, Richard Guenther wrote:
>
> > Hi!
> >
> > I have isolated the patch (attached) that caused the previously reported
> > build ICE and a testcase. The patch enables folding of
> > &a[i] + cst to &a[i+cst] in addition to &a[i] + cst*j -> &a[i+j].
> > If enabled, this transformation triggeres two times in the
> > testcase derived from libiberty/sort.c:
> >
> > #define UCHAR_MAX ((unsigned char)(-1))
> > #define DIGIT_MAX (UCHAR_MAX + 1)
> >
> > void sort_pointers (void)
> > {
> > unsigned int count[DIGIT_MAX];
> > unsigned int *countp;
> >
> > for (countp = count + 1; countp < count + DIGIT_MAX; ++countp)
> > ;
> > }
>
> Ok, stepping through PRE is seems that folding of &count[1]+1 at
> tree-ssa-pre:1622 by calling fully_constant_expression on it
> will get us &count[2] (obviously) and this one does not have a
> value handle, and such we ICE.
No matter what, it should have a value handle at that point
1. if it's is_gimple_min_invariant, get_value_handle should return the
expression.
2. If it isn't, fully_constant_expression would have returned the
original, which should have been value numbered by compute_avail.
Thus, the assert is correct.
> Wether fully_constant_expression
> is in error, or the assert, I do not know. But I guess other
> kind of folding could trigger this, too.
Neither is really in error, it should catch exactly this case :).
This is a real bug, but in get_value_handle.
Fully_constant_expression only returns something other than what you
passed it when it folded to something to an is_gimple_min_invariant.
get_value_handle MUST return the expression when handed an
is_gimple_min_invariant thing.
And we have a winner!
get_value_handle is returning NULL instead of expr when handed your
expression.
Move the is_gimple_min_invariant check in get_value_handle above the
other checks, and your bug should be fixed.
I'll add a comment stating that get_value_handle is *required* to return
the expression when it is is_gimple_min_invariant when I do that.
Please try the attached
>
> One could work around this either by removing the call to
> fully_constant_expression or by wrapping this in sth like
>
> tmp = fully_constant_expression (eprime);
> vprime = get_value_handle (tmp);
> if (!vprime)
> vprime = get_value_handle (eprime);
> else
> eprime = tmp;
> gcc_assert(vprime);
>
> at least, this fixes the ICE.
This isn't right, but it would work. :)
PS feel free to copy me on any PRE bugs.
Index: tree-vn.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-vn.c,v
retrieving revision 2.6
diff -u -p -r2.6 tree-vn.c
--- tree-vn.c 25 Sep 2004 14:36:40 - 2.6
+++ tree-vn.c 15 Feb 2005 14:43:01 -
@@ -267,11 +267,15 @@ vn_lookup_or_add (tree expr, vuse_optype
/* Get the value handle of EXPR. This is the only correct way to get
the value handle for a "thing". If EXPR does not have a value
- handle associated, it returns NULL_TREE. */
+ handle associated, it returns NULL_TREE.
+ NB: If EXPR is min_invariant, this function is *required* to return EXPR. */
tree
get_value_handle (tree expr)
{
+ if (is_gimple_min_invariant (expr))
+return expr;
+
if (TREE_CODE (expr) == SSA_NAME)
return SSA_NAME_VALUE (expr);
else if (EXPR_P (expr) || DECL_P (expr))
@@ -280,10 +284,7 @@ get_value_handle (tree expr)
return ((ann) ? ann->common.value_handle : NULL_TREE);
}
else
-{
- gcc_assert (is_gimple_min_invariant (expr));
- return expr;
-}
+gcc_unreachable ();
}
Re: [PATCH]: Latent bug in value numbering (Was Re: latent bug in PRE?)
On Tue, 15 Feb 2005, Daniel Berlin wrote: > On Tue, 2005-02-15 at 11:31 +0100, Richard Guenther wrote: > > > Wether fully_constant_expression > > is in error, or the assert, I do not know. But I guess other > > kind of folding could trigger this, too. > > Neither is really in error, it should catch exactly this case :). > This is a real bug, but in get_value_handle. > > Fully_constant_expression only returns something other than what you > passed it when it folded to something to an is_gimple_min_invariant. > get_value_handle MUST return the expression when handed an > is_gimple_min_invariant thing. > > And we have a winner! > get_value_handle is returning NULL instead of expr when handed your > expression. > > Move the is_gimple_min_invariant check in get_value_handle above the > other checks, and your bug should be fixed. > > I'll add a comment stating that get_value_handle is *required* to return > the expression when it is is_gimple_min_invariant when I do that. > > Please try the attached Indeed, the patch fixes the problem and I'm happy again ;) Thanks for the quick fix, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
Re: Accessing the subversion repository
On Tue, 2005-02-15 at 12:36 +, Andrew STUBBS wrote: > Hi, > > Joern and I are having difficulty accessing the subversion test repository. > > "svn co svn://svn.toolchain.org/svn/gcc/trunk" does not work due to the ST > corporate firewall (don't ask - the wheels turn slowly), so I have been > looking for an alternative approach. > > Is there any alternative to straight svn protocol set up? I know subversion > supports them, but I haven't seen anything on the list or wiki announcing > it. > > I have tried "svn co svn+shh://svn.toolchain.org/svn/gcc/trunk", but that > does not work either. I appear to have contacted the remote ssh server, but > the devtest username and password given do not seem to work. Are they are > for svn only?. Or am I missing some settings somewhere? The ssh username is actually gcc, password foo2bar so svn+ssh://[EMAIL PROTECTED]/gcc/trunk would work (note for ssh, it's /gcc/trunk, not /svn/gcc/trunk. This is because it's running svnserve with a different root. Just an oversight, AFAIK :P) I should note that svn treats it's remote connections as disposable, so svn+ssh will probably connect more than once for things like remote diffs. So if it takes a while to authenticate, this may not be your best bet if you are looking for blazing speed (as some seem to be :P). On the live repo, we should be able to provide http/https for people who feel svn+ssh is too slow. > > I have also tried "svn co http://svn.toolchain.org/svn/gcc/trunk";, but this > is just a guess and receives the response "302 Moved Temporarily" (once I > figured out .subversion/servers proxy settings). Is this just the wrong URL? > It might be that our proxy does not support DAV? No, i never asked our kind host to set up DAV for this repository, because he doesn't have DAV enabled for his other repos, AFAIK. I can, of course, ask. > The subversion book at red-bean seems to cover server setup, but is rather > light on client setup (not that I have read it in detail). > > If no other method currently exists, is there any possibility of getting one > set up? For purposes of testing, maybe, maybe not. again, i'll ask. > Also, once (if) the subversion repository goes 'live' on > gcc.gnu.org, is there any plans to support the alternative protocols? We should be able to. Note that allowing anonymous over http should alleviate JSM's "Log sending uncompressed" complaint, since you can set it to enable deflate by default if you wanted, so that even log output would be compressed. (Dunno about cpu usage server side for this).
RE: Accessing the subversion repository
> The ssh username is actually gcc, password foo2bar > > so svn+ssh://[EMAIL PROTECTED]/gcc/trunk > > would work (note for ssh, it's /gcc/trunk, not /svn/gcc/trunk. This is > because it's running svnserve with a different root. Just an > oversight, > AFAIK :P) Excellent. I now have a successful checkout. I have added this info to the wiki as I suspect it will be important to more than just myself. > I should note that svn treats it's remote connections as > disposable, so > svn+ssh will probably connect more than once for things like remote > diffs. So if it takes a while to authenticate, this may not be your > best bet if you are looking for blazing speed (as some seem to be :P). Isn't there some was of setting up a svnserve deamon or something? I'm sure I read that somewhere, or maybe I just misunderstood something somewhere. Anyway, I can live with it for the moment. Thanks a lot. -- Andrew Stubbs [EMAIL PROTECTED]
RE: Accessing the subversion repository
On Tue, 2005-02-15 at 15:35 +, Andrew STUBBS wrote: > > The ssh username is actually gcc, password foo2bar > > > > so svn+ssh://[EMAIL PROTECTED]/gcc/trunk > > > > would work (note for ssh, it's /gcc/trunk, not /svn/gcc/trunk. This is > > because it's running svnserve with a different root. Just an > > oversight, > > AFAIK :P) > > Excellent. I now have a successful checkout. I have added this info to the > wiki as I suspect it will be important to more than just myself. > > > I should note that svn treats it's remote connections as > > disposable, so > > svn+ssh will probably connect more than once for things like remote > > diffs. So if it takes a while to authenticate, this may not be your > > best bet if you are looking for blazing speed (as some seem to be :P). > > Isn't there some was of setting up a svnserve deamon or something? I'm sure > I read that somewhere, or maybe I just misunderstood something somewhere. > Anyway, I can live with it for the moment. This is the svnserve daemon (that's what svn:// and svn+ssh:// urls access). :) svnserve is the proprietary protocol like pserver. http uses DAV. > > Thanks a lot. > > -- > Andrew Stubbs > [EMAIL PROTECTED] >
RE: Accessing the subversion repository
> > > I should note that svn treats it's remote connections as > > > disposable, so > > > svn+ssh will probably connect more than once for things > like remote > > > diffs. So if it takes a while to authenticate, this may > not be your > > > best bet if you are looking for blazing speed (as some > seem to be :P). > > > > Isn't there some was of setting up a svnserve deamon or > something? I'm sure > > I read that somewhere, or maybe I just misunderstood > something somewhere. > > Anyway, I can live with it for the moment. > > This is the svnserve daemon (that's what svn:// and svn+ssh:// urls > access). :) > svnserve is the proprietary protocol like pserver. > http uses DAV. When accessing a server via ssh svn spawns an svnserve with the -t option, does it not? I got the impression from somewhere that this could be made to persist. However, since svnserve clearly does persist when run as a local server (in deamon mode, not inetd) it is clear where I could have gotten the wires crossed. It is possible to run a local server as a proxy for a remote server, in order to limit the number of password requests?
RE: Accessing the subversion repository
On Tue, 2005-02-15 at 15:59 +, Andrew STUBBS wrote: > > > > I should note that svn treats it's remote connections as > > > > disposable, so > > > > svn+ssh will probably connect more than once for things > > like remote > > > > diffs. So if it takes a while to authenticate, this may > > not be your > > > > best bet if you are looking for blazing speed (as some > > seem to be :P). > > > > > > Isn't there some was of setting up a svnserve deamon or > > something? I'm sure > > > I read that somewhere, or maybe I just misunderstood > > something somewhere. > > > Anyway, I can live with it for the moment. > > > > This is the svnserve daemon (that's what svn:// and svn+ssh:// urls > > access). :) > > svnserve is the proprietary protocol like pserver. > > http uses DAV. > > When accessing a server via ssh svn spawns an svnserve with the -t option, > does it not? I got the impression from somewhere that this could be made to > persist. It does persist, but svnserve is just spawning threads/forking. The client is what is opening multiple connections. > > However, since svnserve clearly does persist when run as a local server (in > deamon mode, not inetd) it is clear where I could have gotten the wires > crossed. > > It is possible to run a local server as a proxy for a remote server, in > order to limit the number of password requests? Not at the moment, but you could just use svk and access stuff that way if that was your goal. should work fine.
Re: Accessing the subversion repository
Daniel Berlin wrote: > I should note that svn treats it's remote connections as disposable, so > svn+ssh will probably connect more than once for things like remote > diffs. So if it takes a while to authenticate, this may not be your > best bet if you are looking for blazing speed (as some seem to be :P). It would seem to be possible to use fsh to cache ssh connections for svn. But I have not tried it with svn and have not worked out the exact client side svn configuration syntax. http://www.lysator.liu.se/fsh/ This works well to speed up CVS connections. Does the server side have fsh capability? If so this could be useful. Bob
Re: pch on sparc64
On Sun, 7 Nov 2004 10:36:13 -0500 Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > Yes, this is also rounded up to the page size at present. Redefining > HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY should be all it takes.. [ responding to an ancient email, sorry... ] This actually turns out to be impractical, as the necessary value on sparc is: 1) variable, it's 16K when running on a sparc64 machine but totally different and dependant upon what kind of cpu is plugged into the computer on sparc32 machines. There is no simply way to probe for this value either. 2) can be large, up to 4MB or so with certain sparc32 configurations So I guess the recent version of the fix to simply read in the file contents into anonymous memory when necessary is the most appropriate. It's probably cheaper than relocating things too.
__register_frame_info and unwinding shared libraries
This is about DWARF 2 unwinding through shared libraries. As far as I can see, on current x86 GNU/Linux targets we don't call __register_frame_info() or __register_frame_info_bases() from the library startup code in crtbegin. There is code to do it, but it's disabled. When _Unwind_Find_FDE() is called during unwinding, it first calls _Unwind_Find_registered_FDE(), which promptly returns because nothing has ever been registered. Then, _Unwind_Find_FDE() calls dl_iterate_phdr (_Unwind_IteratePhdrCallback, ...) to iterate over every shared library looking for a PC address. This is a linear search, so if you have many shared libraries open this can be pretty slow. So, now for my question: why do we not call __register_frame_info() or __register_frame_info_bases() ? We'd avoid a great many trips through dl_iterate_phdr () and _Unwind_IteratePhdrCallback(). Thanks, Andrew.
Re: [RFC] fold Reorganization Plan
I agree with Nathan. I'm going to try to restate. Premises: 1. Exactly what expressions need to get folded at compile-time is language-dependent. Therefore, front ends need to control what expressions get folded and how that folding takes place. 2. It is of course useful to share optimization technology across languages. Constant-folding, reassociation, and other transformations made by "fold" are optimizations, and, therefore, we want to share them. So, there's no question that this functionality should be shared. 3. The transformations done by fold are also useful in more global settings; the compiler should be able to fold arithmetic involving constants whether the constants occur in a single expression, or in separate basic blocks. Conclusion: 1. Front ends should build up trees, calling fold only when/if they want. For example, in C++, we would want to call fold when we finish processing an "integral constant expression", which is a term of art in C++. (Though that operation would be recursive, that doesn't say anything about whether or not the code in fold.c must be recursive. The C++ front end can always handle the recursion itself, if it so desires.) The C++ front end probably should *not* call fold in any other circumstance. 2. Then, the gimplifier should perform whatever transformations are required by the middle end, like eliminating double NEGATE_EXPRs. 3. Kazu's proposal doesn't get in the way of this plan. All he's doing is making a change that will reduce memory usage, without making major changes to the existing interface. I think the key obstacle to the plan expressed here is not fold, but rather than the gimplifier doesn't do the transformations required. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: __register_frame_info and unwinding shared libraries
On Tue, Feb 15, 2005 at 05:27:15PM +, Andrew Haley wrote: > So, now for my question: why do we not call __register_frame_info() or > __register_frame_info_bases() ? Because in the normal case for C/C++, folks don't use that many exceptions. So delaying doing anything until it's needed is a win. Obviously the normal case is different for Java. > We'd avoid a great many trips through > dl_iterate_phdr () and _Unwind_IteratePhdrCallback(). While I still like using dl_iterate_phdr instead of __register_frame_info_bases for totally aesthetic reasons, there have been changes made to the dl_iterate_phdr interface since the gcc support was written that would allow the dl_iterate_phdr results to be cached. r~
Re: __register_frame_info and unwinding shared libraries
On Tue, Feb 15, 2005 at 09:41:22AM -0800, Richard Henderson wrote: > On Tue, Feb 15, 2005 at 05:27:15PM +, Andrew Haley wrote: > > So, now for my question: why do we not call __register_frame_info() or > > __register_frame_info_bases() ? > > Because in the normal case for C/C++, folks don't use that many > exceptions. So delaying doing anything until it's needed is a win. > > Obviously the normal case is different for Java. > > > We'd avoid a great many trips through > > dl_iterate_phdr () and _Unwind_IteratePhdrCallback(). > > While I still like using dl_iterate_phdr instead of > __register_frame_info_bases for totally aesthetic reasons, there have > been changes made to the dl_iterate_phdr interface since the gcc support > was written that would allow the dl_iterate_phdr results to be cached. This may be exactly what you're suggesting, but could we do this instead of what we do now? - Search the registered FDEs - use dl_iterate_phdr to register and search any unregistered objects -- Daniel Jacobowitz CodeSourcery, LLC
Re: __register_frame_info and unwinding shared libraries
On Tue, Feb 15, 2005 at 12:43:44PM -0500, Daniel Jacobowitz wrote: > This may be exactly what you're suggesting, but could we do this > instead of what we do now? > > - use dl_iterate_phdr to register and search any unregistered objects Done naievely, this will fail with dlclose. r~
Re: [RFC] fold Reorganization Plan
1. Exactly what expressions need to get folded at compile-time is language-dependent. Therefore, front ends need to control what expressions get folded and how that folding takes place. I think I'm agreeing with you, but I just want to make sure that "need" in the above means "required to be made into a constant by the semantics of the language".
Re: [RFC] fold Reorganization Plan
Richard Kenner wrote: 1. Exactly what expressions need to get folded at compile-time is language-dependent. Therefore, front ends need to control what expressions get folded and how that folding takes place. I think I'm agreeing with you, but I just want to make sure that "need" in the above means "required to be made into a constant by the semantics of the language". Yes. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
C++ frontend generating bogous trees
Hi! The C++ frontend creates from cp/call.c:3864 (build_new_op (code=PLUS_EXPR, flags=3, ...)) with arg1 (gdb) call debug_tree(arg1) volatile unsigned type_6 DI size unit size align 64 symtab -1780663408 alias set -1 pointer_to_this > BLK size unit size align 64 symtab -1780664448 alias set -1 domain DI size unit size align 64 symtab 0 alias set -1 precision 64 min max > pointer_to_this > side-effects addressable volatile used public protected static external nonlocal decl_3 decl_5 decl_6 BLK file /net/pherkad/scratch/rguenth/gcc-obj2/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/pool_allocator.h line 91 size unit size align 64 context chain > in #5 0x00515552 in build_binary_op (code=PLUS_EXPR, orig_op0=0x2a95dd4680, orig_op1=0x2a95df5ea0, convert_p=1) at /net/pherkad/scratch/rguenth/gcc/gcc/cp/typeck.c:2819 2819return cp_pointer_int_sum (PLUS_EXPR, op0, op1); (gdb) call debug_tree(op0) volatile unsigned type_6 DI size unit size align 64 symtab -1780663408 alias set -1 pointer_to_this > asm_written unsigned type_6 DI size unit size align 64 symtab -1780663488 alias set -1> constant invariant arg 0 unsigned DI size unit size align 64 symtab 0 alias set -1> constant invariant arg 0 side-effects addressable volatile used public protected static external nonlocal decl_3 decl_5 decl_6 BLK file /net/pherkad/scratch/rguenth/gcc-obj2/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/pool_allocator.h line 91 size unit size align 64 context chain >>> which will fail gimplify.c:4403 because the type of the ADDR_EXPR is not 0x2a95dd4b60 like the type of the array element. I guess this may origin from some stuff in decay_conversion, though I don't have time to investigate this ATM. Maybe someone has an idea. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
Re: __register_frame_info and unwinding shared libraries
Richard Henderson writes: > On Tue, Feb 15, 2005 at 05:27:15PM +, Andrew Haley wrote: > > So, now for my question: why do we not call __register_frame_info() or > > __register_frame_info_bases() ? > > Because in the normal case for C/C++, folks don't use that many > exceptions. So delaying doing anything until it's needed is a win. > > Obviously the normal case is different for Java. Yeah. In the big server application I'm working on, almost 40% of total CPU time is spent inside one function, _Unwind_IteratePhdrCallback(). This is for a few reasons: firstly, java uses stack traces for things other than throwing exceptions. Exceptions are relatively rare. Also, in a big server application you have a lot of shared libraries: this one has 86. So, for every single stack frame we're doing many excursions through _Unwind_IteratePhdrCallback(). > > We'd avoid a great many trips through > > dl_iterate_phdr () and _Unwind_IteratePhdrCallback(). > > While I still like using dl_iterate_phdr instead of > __register_frame_info_bases for totally aesthetic reasons, there > have been changes made to the dl_iterate_phdr interface since the > gcc support was written that would allow the dl_iterate_phdr > results to be cached. That would be nice. Also, we could fairly easily build a tree of nodes, one for each loaded object, then we wouldn't be doing a linear search through them. We could do that lazily, so it wouldn't kick in 'til needed. Andrew.
Re: Accessing the subversion repository
On Tue, Feb 15, 2005 at 09:20:57AM -0700, Bob Proulx wrote: >Daniel Berlin wrote: >>I should note that svn treats it's remote connections as disposable, so >>svn+ssh will probably connect more than once for things like remote >>diffs. So if it takes a while to authenticate, this may not be your >>best bet if you are looking for blazing speed (as some seem to be :P). > >It would seem to be possible to use fsh to cache ssh connections for >svn. But I have not tried it with svn and have not worked out the >exact client side svn configuration syntax. > >http://www.lysator.liu.se/fsh/ > >This works well to speed up CVS connections. Does the server side have >fsh capability? If so this could be useful. I don't think fsh is a good idea. That could mean potentially hundreds of persistent ssh connections sitting around on the server.
Re: __register_frame_info and unwinding shared libraries
On Tue, Feb 15, 2005 at 06:02:39PM +, Andrew Haley wrote:
> Richard Henderson writes:
> > On Tue, Feb 15, 2005 at 05:27:15PM +, Andrew Haley wrote:
> > > So, now for my question: why do we not call __register_frame_info() or
> > > __register_frame_info_bases() ?
> >
> > Because in the normal case for C/C++, folks don't use that many
> > exceptions. So delaying doing anything until it's needed is a win.
> >
> > Obviously the normal case is different for Java.
>
> Yeah. In the big server application I'm working on, almost 40% of
> total CPU time is spent inside one function,
> _Unwind_IteratePhdrCallback(). This is for a few reasons: firstly,
> java uses stack traces for things other than throwing exceptions.
> Exceptions are relatively rare.
>
> Also, in a big server application you have a lot of shared libraries:
> this one has 86. So, for every single stack frame we're doing many
> excursions through _Unwind_IteratePhdrCallback().
>
> > > We'd avoid a great many trips through
> > > dl_iterate_phdr () and _Unwind_IteratePhdrCallback().
> >
> > While I still like using dl_iterate_phdr instead of
> > __register_frame_info_bases for totally aesthetic reasons, there
> > have been changes made to the dl_iterate_phdr interface since the
> > gcc support was written that would allow the dl_iterate_phdr
> > results to be cached.
>
> That would be nice. Also, we could fairly easily build a tree of
> nodes, one for each loaded object, then we wouldn't be doing a linear
> search through them. We could do that lazily, so it wouldn't kick in
> 'til needed.
Here is a rough patch for what you can do.
The actual cache is not implemented, only comments say what would be
done in that case.
Now, it depends if we want to use malloc for creation of the cache or not
(because _Unwind_* is also used for backtrace etc. and at that point
the program can be in rather unstable state).
So, if e.g. a 8 entries fixed cache for PC
range -> (load_base, p_eh_frame_hdr, p_dynamic) is enough, it could be
searched linearly. If you need a dynamically created binary tree,
that's another alternative, but will need malloc. Or you can combine
a few static entries with a dynamically allocated rest of the tree.
You still need to call dl_iterate_phdr, so that ld.so grabs the
mutex and tells you if there have been any dlcloses or dlopens since
last time you called it, but you don't have to scan all the libs
and can just search the one that is known to contain the pc.
--- unwind-dw2-fde-glibc.c.jj 2004-10-28 15:25:20.0 +0200
+++ unwind-dw2-fde-glibc.c 2005-02-15 19:10:48.183511095 +0100
@@ -74,6 +74,7 @@ struct unw_eh_callback_data
void *dbase;
void *func;
const fde *ret;
+ int check_cache;
};
struct unw_eh_frame_hdr
@@ -123,11 +124,15 @@ _Unwind_IteratePhdrCallback (struct dl_p
const struct unw_eh_frame_hdr *hdr;
_Unwind_Ptr eh_frame;
struct object ob;
-
- /* Make sure struct dl_phdr_info is at least as big as we need. */
- if (size < offsetof (struct dl_phdr_info, dlpi_phnum)
-+ sizeof (info->dlpi_phnum))
-return -1;
+ struct ext_dl_phdr_info
+{
+ ElfW(Addr) dlpi_addr;
+ const char *dlpi_name;
+ const ElfW(Phdr) *dlpi_phdr;
+ ElfW(Half) dlpi_phnum;
+ unsigned long long int dlpi_adds;
+ unsigned long long int dlpi_subs;
+};
match = 0;
phdr = info->dlpi_phdr;
@@ -135,6 +140,31 @@ _Unwind_IteratePhdrCallback (struct dl_p
p_eh_frame_hdr = NULL;
p_dynamic = NULL;
+ if (data->check_cache && size >= sizeof (struct ext_dl_phdr_info))
+{
+ static unsigned long long adds = -1ULL, subs;
+ struct ext_dl_phdr_info *einfo = (struct ext_dl_phdr_info *) info;
+ if (einfo->dlpi_adds == adds && einfo->dlpi_subs == subs)
+{
+ /* Find data->pc in shared library cache.
+ Set load_base, p_eh_frame_hdr and p_dynamic
+ plus match from the cache and goto
+ "Read .eh_frame_hdr header." below. */
+}
+ else
+{
+ adds = einfo->dlpi_adds;
+ subs = einfo->dlpi_subs;
+ /* Invalidate cache. */
+}
+ data->check_cache = 0;
+}
+
+ /* Make sure struct dl_phdr_info is at least as big as we need. */
+ if (size < offsetof (struct dl_phdr_info, dlpi_phnum)
++ sizeof (info->dlpi_phnum))
+return -1;
+
/* See if PC falls into one of the loaded segments. Find the eh_frame
segment at the same time. */
for (n = info->dlpi_phnum; --n >= 0; phdr++)
@@ -289,6 +319,7 @@ _Unwind_Find_FDE (void *pc, struct dwarf
data.dbase = NULL;
data.func = NULL;
data.ret = NULL;
+ data.check_cache = 1;
if (dl_iterate_phdr (_Unwind_IteratePhdrCallback, &data) < 0)
return NULL;
Jakub
Re: [RFC] fold Reorganization Plan
Mark Mitchell writes: > > > 1. Front ends should build up trees, calling fold only when/if they > want. For example, in C++, we would want to call fold when we finish > processing an "integral constant expression", which is a term of art in > C++. (Though that operation would be recursive, that doesn't say > anything about whether or not the code in fold.c must be recursive. The > C++ front end can always handle the recursion itself, if it so desires.) There's one other thing to bear in mind when considering the way that fold relates to language front ends. We've seen problems in Java where fold() returned tree nodes that Java didn't recognize: one time, for example, it returned a BITFIELD_EXPR. Andrew.
g++ compile-time error with template arguments in 4.0 CVS?
Hi,
I have a reduced testcase from BOOST that fails with yesterdays CVS
(4.0.0 20050214 (experimental)), but compiles under 3.4. I don't know
if this is a bug in BOOST or in g++:
-- begin testcase
template< typename T, T N >
struct integral_c
{
static const T value = N;
typedef integral_c< T, static_cast((value + 1)) > next;
// typedef integral_c< T, static_cast((value - 1)) > prior;
// operator T() const { return static_cast(this->value); }
};
--- end testcase
% g++-cvs testcase.C
c.C:6: error: template argument 2 is invalid
Note that simply replacing 'value' by 'N' make this compile.
The original error was obtained by including
The following error was recieved:
In file included from /usr/include/boost/config.hpp:35,
from /usr/include/boost/numeric/ublas/config.hpp:24,
from /usr/include/boost/numeric/ublas/matrix.hpp:20,
from a.C:1:
/usr/include/boost/config/compiler/gcc.hpp:92:7: warning: #warning
"Unknown compiler version - please run the configure tests and report
the results"
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:72: error: template
argument 2 is invalid
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:73: error: template
argument 2 is invalid
Please let me know if I should file a PR
thanks!
-BenRI
Re: g++ compile-time error with template arguments in 4.0 CVS?
On Feb 15, 2005, at 2:37 PM, Benjamin Redelings I wrote:
Hi,
I have a reduced testcase from BOOST that fails with yesterdays CVS
(4.0.0 20050214 (experimental)), but compiles under 3.4. I don't know
if this is a bug in BOOST or in g++:
-- begin testcase
template< typename T, T N >
struct integral_c
{
static const T value = N;
typedef integral_c< T, static_cast((value + 1)) > next;
// typedef integral_c< T, static_cast((value - 1)) > prior;
// operator T() const { return static_cast(this->value); }
};
--- end testcase
This is related to PR 19883.
-- Pinski
Re: [RFC] fold Reorganization Plan
Andrew Haley wrote: Mark Mitchell writes: > > > 1. Front ends should build up trees, calling fold only when/if they > want. For example, in C++, we would want to call fold when we finish > processing an "integral constant expression", which is a term of art in > C++. (Though that operation would be recursive, that doesn't say > anything about whether or not the code in fold.c must be recursive. The > C++ front end can always handle the recursion itself, if it so desires.) There's one other thing to bear in mind when considering the way that fold relates to language front ends. We've seen problems in Java where fold() returned tree nodes that Java didn't recognize: one time, for example, it returned a BITFIELD_EXPR. Yes, that's certainly problematic. Although I think that fold should remain in language-independent code, that is not to say that it should not necessarily be informed by langhooks as to what exactly it should do. However, while that may be necessary for Java, it's not necessary for C++. In C++, fold should only be called for "integral constant expressions", which, by definition, are made up of simple operations on integers. (It's a little more complicated than that, but all the operands collapse to integers immediately.) So, all we really need for C++ is the ability to convert floating-point constants to integer constants, and the ability to do basic arithmetic on integer constants. I certainly hope that given those inputs, any reasonable implementation of fold will only return an integer constant. So, the plan I outlined would solve the kind of problem you describe for C++ because C++ will only call fold with these limited inputs, and therefore never see unexpected returns. The gimplifier can introduce all the weird nodes it wants, as at that point the C++ front end is out of the picture. Of course, for C++, we could -- and perhaps should -- just avoid fold altogether, and just use int_const_binop instead. Thus, as I said earlier, from a C++ point of view, the obstacle is that failure to call fold may result in the output of the gimplifier being invalid, as Roger Sayle has indicated that the middle-end is expecting the front end to call fold before gimplification. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [RFC] fold Reorganization Plan
On Tue, 15 Feb 2005, Andrew Haley wrote: > There's one other thing to bear in mind when considering the way that > fold relates to language front ends. We've seen problems in Java > where fold() returned tree nodes that Java didn't recognize: one time, > for example, it returned a BITFIELD_EXPR. I see the current java front-end's inability to lower standard tree nodes in to JVM bytecodes as a failing of the gcj implementation rather an intrinsic problem in the constant folder. The operator BIT_FIELD_REF, for example, can be seen as a canonical representation of a shift-and-mask or a mask-and-shift operation. Hence, should the tree-ssa analysis passes prefer to see "(x & 12) >> 2" or "(x >> 2) & 3" as BIT_FIELD_REF (x, 2, 2), it should be a relatively trivial task for jcf-write.c to convert BIT_FIELD_REF (x, 2, 2) back into an ishr/iand sequence. Exactly, the same problems were claimed with jcf-write's inability to handle ABS_EXPR, MIN_EXPR, MAX_EXPR, NOP_EXPR, RSHIFT_EXPR, etc... The design decision made by gcj was that rather than to provide a JVM back-end target, was to instead side-step GCC's RTL expansion and perform the lowering to Java bytecodes itself. As such, any RTL expansion functionality that failed to get implemented in gcj would appear to be a short coming of the java front-end, i.e. a sorry(), rather than a bug or problem in fold or the middle-end. My understanding is that its this failure of the java folks to finish implementing an expand_expr replacement for JVM bytecodes thats the primary motivating factor for the new "gcjx" front-end :) Roger --
Re: [RFC] fold Reorganization Plan
Roger Sayle writes: > > On Tue, 15 Feb 2005, Andrew Haley wrote: > > There's one other thing to bear in mind when considering the way that > > fold relates to language front ends. We've seen problems in Java > > where fold() returned tree nodes that Java didn't recognize: one time, > > for example, it returned a BITFIELD_EXPR. > > I see the current java front-end's inability to lower standard tree > nodes in to JVM bytecodes as a failing of the gcj implementation > rather an intrinsic problem in the constant folder. The operator > BIT_FIELD_REF, for example, can be seen as a canonical representation > of a shift-and-mask or a mask-and-shift operation. Hence, should > the tree-ssa analysis passes prefer to see "(x & 12) >> 2" or > "(x >> 2) & 3" as BIT_FIELD_REF (x, 2, 2), it should be a relatively > trivial task for jcf-write.c to convert BIT_FIELD_REF (x, 2, 2) back > into an ishr/iand sequence. Well, okay. If bitfields are to be declared language independent, I won't argue. But there's a more general point here: if a language doesn't have pointers, for example, must its front end cope with them just in case fold() decides to return one? > Exactly, the same problems were claimed with jcf-write's inability > to handle ABS_EXPR, MIN_EXPR, MAX_EXPR, NOP_EXPR, RSHIFT_EXPR, etc... > > The design decision made by gcj was that rather than to provide a > JVM back-end target, was to instead side-step GCC's RTL expansion > and perform the lowering to Java bytecodes itself. As such, any > RTL expansion functionality that failed to get implemented in gcj > would appear to be a short coming of the java front-end, i.e. a > sorry(), rather than a bug or problem in fold or the middle-end. The gcj bytecode writer isn't really the primary issue, as far as I can see. It's whether every front end must handle all of the possible tree nodes, when some of those nodes cannot arise during parsing of the source language. > My understanding is that its this failure of the java folks to finish > implementing an expand_expr replacement for JVM bytecodes thats the > primary motivating factor for the new "gcjx" front-end :) Er, that is not my understanding. The primary primary motivating factor for gcjx is a parser that's easier to expand with new langauge constructs and, of course, to maintain. Andrew.
Re: Accessing the subversion repository
Daniel Berlin wrote: On Tue, 2005-02-15 at 15:59 +, Andrew STUBBS wrote: I should note that svn treats it's remote connections as disposable, so svn+ssh will probably connect more than once for things like remote diffs. So if it takes a while to authenticate, this may not be your best bet if you are looking for blazing speed (as some seem to be :P). Isn't there some was of setting up a svnserve deamon or something? I'm sure I read that somewhere, or maybe I just misunderstood something somewhere. Anyway, I can live with it for the moment. This is the svnserve daemon (that's what svn:// and svn+ssh:// urls access). :) svnserve is the proprietary protocol like pserver. http uses DAV. When accessing a server via ssh svn spawns an svnserve with the -t option, does it not? I got the impression from somewhere that this could be made to persist. It does persist, but svnserve is just spawning threads/forking. The client is what is opening multiple connections. However, since svnserve clearly does persist when run as a local server (in deamon mode, not inetd) it is clear where I could have gotten the wires crossed. It is possible to run a local server as a proxy for a remote server, in order to limit the number of password requests? Not at the moment, but you could just use svk and access stuff that way if that was your goal. should work fine. One could always use ssh to open a tunnel to the remote host, then use plain svn:// over that, I suppose. -- Brane
Re: C++ frontend generating bogous trees
Ok, I guess the following excerpts from cp/typechk.c show a discrepancy:
tree
build_address (tree t)
{
tree addr;
if (error_operand_p (t) || !cxx_mark_addressable (t))
return error_mark_node;
addr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
return addr;
}
1381 (decay_conversion)
ptrtype = build_pointer_type (TREE_TYPE (type));
if (TREE_CODE (exp) == VAR_DECL)
{
if (!cxx_mark_addressable (exp))
return error_mark_node;
adr = build_nop (ptrtype, build_address (exp));
return adr;
}
where of course we are doing redundant work, but we are also
building an ADDR_EXPR with the wrong type. I guess the above
should rather read
if (TREE_CODE (exp) == VAR_DECL)
{
if (!cxx_mark_addressable (exp))
return error_mark_node;
adr = build1 (ADDR_EXPR, ptrtype, exp);
return adr;
}
no? At least this let's my bootstrap continue.
Re: C++ frontend generating bogous trees
On Feb 15, 2005, at 4:26 PM, Richard Guenther wrote: Ok, I guess the following excerpts from cp/typechk.c show a discrepancy: Can you at least reduce the C++ code and also provide the patch which you are working on currently, this will help us understand the problem better? -- Pinski
Re: C++ frontend generating bogous trees
On Tue, 15 Feb 2005 16:29:09 -0500, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > On Feb 15, 2005, at 4:26 PM, Richard Guenther wrote: > > > Ok, I guess the following excerpts from cp/typechk.c show a > > discrepancy: > > Can you at least reduce the C++ code and also provide the patch which > you are working on currently, this will help us understand the problem > better? Yes, I'm working at fixing PR19807, i.e. folding of &a[] + c and &a + c, current patch (and related fixes) attached. The failure above occours during the build of libstdc++ - the exact file/condition (I think this was just a regular build, not a bootstrap, and with CFLAGS=-g for better debugging, because a previous bootstrap failure was not debuggable) is currently unavailable, but I can dig that out tomorrow. Fact is, the tree-checker in gimplify.c chokes on the tree generated by the frontend and the patch fixes that. I made the fix by inspection of the code and think the bug is obvious, but of course I'm not very familiar with the C++ frontend. Hope this clarifies things a bit - I'll collect the testcases for the latent bugs I'm uncovering for inclusion once I submit the triggering patch. Richard.
Re: C++ frontend generating bogous trees
> Yes, I'm working at fixing PR19807, i.e. folding of &a[] + c and &a + c, > current patch (and related fixes) attached. Now, really. Richard. p Description: Binary data
Want to sponsor Steve Kargl's "Write after approval" status.
As per http://gcc.gnu.org/cvswrite.html: "If you already have an account on sources.redhat.com, please send email to overseers(at)gcc.gnu.org with a request for access to the GCC repository. Include the name of the person who is sponsoring your access. Else use this form to supply your SSH public key (which you can generate via the ssh-keygen program) and other details." Unfortunately, "this form" returned: "Thank you. This request will now be processed by: None." Which doesn't look promising. Perhaps we need a human actor in the loop. Please, advise. Thanks, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: C++ frontend generating bogous trees
On Tue, 15 Feb 2005 22:26:31 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> I guess the above
> should rather read
>
> if (TREE_CODE (exp) == VAR_DECL)
> {
> if (!cxx_mark_addressable (exp))
> return error_mark_node;
> adr = build1 (ADDR_EXPR, ptrtype, exp);
> return adr;
> }
>
> no? At least this let's my bootstrap continue.
No, while this bootstraps ok, all hell breaks loose during g++ testing :(
With the patch as attached in this thread further up (removing the
broken fix) bootstrap fails with
/net/pherkad/scratch/rguenth/gcc-obj/gcc/xgcc -shared-libgcc
-B/net/pherkad/scratch/rguenth/gcc-obj/gcc/ -nostdinc++
-L/net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include
-I/net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/net/pherkad/scratch/rguenth/gcc/libstdc++-v3/libsupc++ -g -O2
-D_GNU_SOURCE -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -c
/net/pherkad/scratch/rguenth/gcc/libstdc++-v3/src/pool_allocator.cc
-fPIC -DPIC -o .libs/pool_allocator.o
/net/pherkad/scratch/rguenth/gcc/libstdc++-v3/src/pool_allocator.cc:
In member function '__gnu_cxx::__pool_alloc_base::_Obj* volatile*
__gnu_cxx::__pool_alloc_base::_M_get_free_list(size_t)':
/net/pherkad/scratch/rguenth/gcc/libstdc++-v3/src/pool_allocator.cc:47:
internal compiler error: in check_pointer_types_r, at gimplify.c:4403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
There with the patch we will now fold the
return _S_free_list + __i;
to
_S_free_list[i];
I'll debug this further, so do not waste your own time yet - it's for
sure a bug in my patch.
Thanks anyway,
Richard.
Re: [RFC] fold Reorganization Plan
> "Roger" == Roger Sayle <[EMAIL PROTECTED]> writes: Roger> The operator BIT_FIELD_REF, for example, can be seen as a Roger> canonical representation of a shift-and-mask or a Roger> mask-and-shift operation. The problem that lead to the creation of the can_use_bit_fields_p lang hook was that fold was turning references to two adjacent fields into a single BIT_FIELD_REF. This confused the bytecode writer, and inverting the transforms done by fold looked tricky. IMO, gcj has always inhabited a sort of grey area here. It has relied on fold() not to do things that jcf-write.c didn't expect. That this assumption breaks from time to time isn't really surprising. In addition to relying on the output of fold() to be acceptable for bytecode generation purposes, gcj has also relied on fold to do the constant folding required by the java programming language. This has also caused problems from time to time; I think there are still open PRs about this (plus hacky little workarounds here and there). Roger> My understanding is that its this failure of the java folks to finish Roger> implementing an expand_expr replacement for JVM bytecodes thats the Roger> primary motivating factor for the new "gcjx" front-end :) Heh. Really my motivation was to have a more maintainable code base for adding the new language features (generics, primarily, but there are others). In particular I was interested in a front end that used static typing instead of 'tree'. In gcjx, the only time we see trees is when we know we want to generate object code. In this situation, anything fold() or other parts of the middle-end decide to do will be ok (with the minimal assumption that they are semantics-preserving transformations). My goal in doing this was to insulate language-mandated parts of gcjx, and non-gcc-related things like bytecode generation, from decisions made in the rest of GCC. The drawback of this approach, as Roger pointed out on irc once, is that sometimes we may lose optimizations. For instance, he wrote a cool jcf-write.c patch to handle RSHIFT_EXPR of unsigned types, which let us generate better bytecode in some situations. But in the end I think this isn't of great consequence -- optimizing java bytecode is not very important (performance sensitive folks use JITs which already do all these optimizations anyway). I would recommend this general approach to anybody writing a GCC front end. It is, to my mind, simpler to write and to maintain. Tom
Re: [RFC] fold Reorganization Plan
Mark Mitchell wrote:- > However, while that may be necessary for Java, it's not necessary for > C++. In C++, fold should only be called for "integral constant > expressions", which, by definition, are made up of simple operations on > integers. (It's a little more complicated than that, but all the > operands collapse to integers immediately.) So, all we really need for > C++ is the ability to convert floating-point constants to integer > constants, and the ability to do basic arithmetic on integer constants. I think it's desirable for front-ends to be able to fold floating point constant expressions too, no? It can be handy for diagnostics such as detecting overflow or unreachable code based on conditionals whose expression is a floating one, albeit constant. Neil.
Re: [RFC] fold Reorganization Plan
Neil Booth wrote: Mark Mitchell wrote:- However, while that may be necessary for Java, it's not necessary for C++. In C++, fold should only be called for "integral constant expressions", which, by definition, are made up of simple operations on integers. (It's a little more complicated than that, but all the operands collapse to integers immediately.) So, all we really need for C++ is the ability to convert floating-point constants to integer constants, and the ability to do basic arithmetic on integer constants. I think it's desirable for front-ends to be able to fold floating point constant expressions too, no? It can be handy for diagnostics such as detecting overflow or unreachable code based on conditionals whose expression is a floating one, albeit constant. Yes, that's useful -- but it's not actually *necessary* for a conforming C++ compiler to be able to fold floating-point constants. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Using up double diskspace for working copies (Was Re: Details forsvn test repository)
> This is not actually true. Both ArX and tla support hardlinking the > tree against the extra pristine copy. In fact, for the use case given > (lots of old test builds), some or all could be linked against each > other. You could do this with svn as well if you wanted to.
Re: [RFC] fold Reorganization Plan
On Wed, Feb 16, 2005 at 08:01:13AM +0900, Neil Booth wrote: > Mark Mitchell wrote:- > > > However, while that may be necessary for Java, it's not necessary for > > C++. In C++, fold should only be called for "integral constant > > expressions", which, by definition, are made up of simple operations on > > integers. (It's a little more complicated than that, but all the > > operands collapse to integers immediately.) So, all we really need for > > C++ is the ability to convert floating-point constants to integer > > constants, and the ability to do basic arithmetic on integer constants. > > I think it's desirable for front-ends to be able to fold floating > point constant expressions too, no? It can be handy for diagnostics > such as detecting overflow or unreachable code based on conditionals > whose expression is a floating one, albeit constant. The problem is that the user can independently set the IEEE rounding mode. This means that you can only fold floating point constants in cases where the generated result is exact; you cannot fold 1./3. for example. Also, you should not assume that the user wants the kinds of diagnostics you describe; they might *want* the Infinity or NaN they generated.
Re: [RFC] fold Reorganization Plan
On Tue, 15 Feb 2005, Joe Buck wrote: > The problem is that the user can independently set the IEEE rounding mode. > This means that you can only fold floating point constants in cases where > the generated result is exact; you cannot fold 1./3. for example. You can fold 1./3. unless the user uses the FENV_ACCESS pragma to say you can't in a particular region of the code. (Or -frounding-math while we don't have FENV_ACCESS, although -frounding-math may not work fully either as parts of the compiler may not be aware that the results of apparently identical floating-point computations may depend on the rounding mode.) Even with FENV_ACCESS, for C you still need to fold 1./3. in static initializers (using the default rounding mode in that case). -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: [RFC] fold Reorganization Plan
Mark Mitchell wrote: Yes, that's useful -- but it's not actually *necessary* for a conforming C++ compiler to be able to fold floating-point constants. Also, note that strictly speaking, folding floating-point operations usually violates the IEEE standard, which requires rounding mode to be able to be set dynamically. So at least there should be an option to disable such folding if it is not defined in the language (in Ada, such folding is well defined and so is required to happen at compile time).
Re: [RFC] fold Reorganization Plan
Joe Buck wrote: The problem is that the user can independently set the IEEE rounding mode. This means that you can only fold floating point constants in cases where the generated result is exact; you cannot fold 1./3. for example. Also, you should not assume that the user wants the kinds of diagnostics you describe; they might *want* the Infinity or NaN they generated That's a bit more extreme statement of the requirements. Does C++ require IEEE compliance to this extent? EVen if it does, it is reasonable to have an option (probably the default) in which fpt is folded (of course it is mandatory to use a simulator that will give EXACTLY the results that would have been obtained if the expression had been evaluated at run time. In practice everyone uses round to nearest even.
Shipping gmp and mpfr with gcc-4.0?
Sorry if this has been answered before. I installed gmp and mpfr successfully on my Mac G5 and so I can test gfortran on my Mac. I tried this evening to install gmp-4.1.4 and mpfr-2.1.0 on my Solaris machines and I failed on the first try. (I think the default install for gmp on my machines is a 64-bit version, but the default for mpfr and gcc is 32-bit, so I'm going to have to figure out how to configure everything to match.) Now, I'm not a great systems administrator, but I've been maintaining my own unix/linux/MacOS X machines since 1987, and installing gmp and mpfr as they come from the default distributions in such a way that gcc can use them seems to be nontrivial. So, my question. Will gcc-4.0 ship with a properly configured gmp/mpfr distribution so gfortran will be built by ./configure; make; make install? Brad
Re: SVN Test Repo updated
On Tue, 2005-02-15 at 03:09 +, Joseph S. Myers wrote: > Another incidental observation from experiments with subversion: the > output from svn diff seems to be in a fairly random order (rather than > alphabetical order of filenames). Alphabetical order tends to be easier > to follow when checking svn diff output to see that the changes you're > about to commit are exactly those you intended to commit and that the > ChangeLog entries you've written correspond to those changes (e.g. the > list of files - alphabetical - in the ChangeLog entries covers all the > files in the svn diff output). Complete alphabetical order is not in the cards for diff, at least for diffs involving server side (diffs that are client side are easily sorted by filename). This is because it would require losing the "streaminess" of the protocol (unlike cvs, the client and the server in svn are really seperate, and the client just gets a stream of results. Sorting would require at least holding all the directory entries in the server at once, before sending them to the client, if not worse), as well as their being locale issues (the server would have to know the client's locale to sort the files so they appeared in the alphabetical order you expect). In other words, so far the cost of trying to do it has outweighed the benefit of having diffs appear in some well-specified order. However, if you are satisfied with client-only diff (which is the main case when you'd be writing changelogs) working in alphabetical order, i should be able to wing that. >
Re: Shipping gmp and mpfr with gcc-4.0?
> I tried this evening to install gmp-4.1.4 and mpfr-2.1.0 on my Solaris > machines and I failed on the first try. (I think the default install > for gmp on my machines is a 64-bit version, but the default for mpfr > and gcc is 32-bit, so I'm going to have to figure out how to configure > everything to match.) ./configure sparc-sun-solaris2.9 --prefix=xxx --enable-mpfr -- Eric Botcazou
