On Sat, 2005-07-16 at 23:28 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
> | > Daniel Berlin wrote:
> | > >>> object volatile).
> | > >>
> You don&#x
On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | You make it sound like the standard is crystal clear on this issue, and
> | everyone who disagrees with your viewpoint are just slimeballs trying to
On Sun, 2005-07-10 at 00:16 +0200, Gerald Pfeifer wrote:
> On Fri, 8 Jul 2005, Daniel Berlin wrote:
> > Here's a patch.
>
> Thanks.
>
> There are a couple of commas between items missing (usually when
> there is a line break)
fixed.
> and some of the lines are
On Sat, 2005-07-16 at 21:36 -0400, D. Hugh Redelmeier wrote:
> | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
>
> | After many exchanges via private mails and
> | looking at the various reports related to this issue, it has become
> | clear to me that the interpretations offered to justify why GCC
> At this point we need:
> (1) agreement from C and C++ maintainers on access through volatile
> lvalue
> (2) agreement with the middle-end maintainers not to "optimize"
> volatile lvalue expressions
We already don't optimize expressions considered to have "volatile"
operands.
I
On Sun, 2005-07-17 at 05:13 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | > I think that is urgent.
> | No offense, but everyone thinks the problems that affect them are the
> | most urgent.
>
> miscompilation of
On Sun, 2005-07-17 at 08:18 +0300, Michael Veksler wrote:
>
>
>
> Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
>
> > Daniel Berlin <[EMAIL PROTECTED]> writes:
> >
> > | Anything it sees anything in a statement with volatile, it marks the
> > | st
On Sun, 2005-07-17 at 18:05 +0200, Steven Bosscher wrote:
> Hi,
>
> There are some huge compile time regressions between 16/7 and 17/7, most
> likely due to the IPA work from Kenny and Dan.
Definitely.
The peak compile time slowdown is due to the promote statics pass, which
in term causes more w
On Sun, 2005-07-17 at 18:05 +0200, Steven Bosscher wrote:
> Hi,
>
> There are some huge compile time regressions between 16/7 and 17/7, most
> likely due to the IPA work from Kenny and Dan. These are the build times
> in seconds, taken from Diego Novillo's nightly SPEC tester box:
As i expected,
> 200.sixtrack 74 258 348.65%
I can get this down to something slightly more sane (cut down
global-alloc time by 80%) by upping the global var threshold.
The problem is that the global var threshold causes us to make all the
promoted statics touch the global var.
# .GLOBAL_VAR_2
> Would you care to characterize the number of extra variables created
> at the tree level and the number of extra pseudos created at the rtl
> level?
We only create as many variables as we have statics we promote right
now.
At the RTL level, global reg has 6373 regs to allocate with promote
st
On Mon, 2005-07-18 at 17:24 +0200, Gabriel Dos Reis wrote:
> Gerald Pfeifer <[EMAIL PROTECTED]> writes:
>
> | On Sat, 16 Jul 2005, Gabriel Dos Reis wrote:
> | > No, I have no such plan. (And the branch has seen no much development
> | > recently)
> |
> | But you still plan on working on it late
(I have put these directions at
http://www.dberlin.org/~dberlin/patchdirections.html)
After much discussion on IRC.
I've set up a simple patch queue for tracking patches at
http://www.dberlin.org/cgi-bin/patches.py
The data in there is real, those are patches that need to be reviewed,
along wit
On Tue, 2005-07-19 at 09:37 +0200, FX Coudert wrote:
> > There are regressions involving complex aritmetic in the testsuite too:
> > FAIL: gfortran.dg/real_const_1.f (test for excess errors)
> > WARNING: gfortran.dg/real_const_1.f compilation failed to produce
> > executable
>
> The regression
For the curious, the patch queue source (which is just about 60 lines
python + cheetah templates) is at
http://www.dberlin.org/cgi-bin/viewcvs.cgi/?root=webrepo
I haven't added the thing that grabs info from gcc-patches into the
source yet.
Patches welcome, of course (Ian Taylor submitted a patch
toolchains. Or some third party linker may load DLLs
relative to its install path.
I'd say that using cp for mingw32 is not a huge step backwards. If
someone triggers a failure case, then we can do more work on it then.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Wed, Jul 20, 2005 at 10:10:03PM -0400, Christopher Faylor wrote:
> On Tue, Jul 19, 2005 at 04:21:04PM -0400, Daniel Jacobowitz wrote:
> >On Tue, Jul 19, 2005 at 04:14:04PM -0400, Christopher Faylor wrote:
> >>Ok. Given that 'cp' was an acceptable fallback in the
by default and avoid the need for this kind of
> system-specific behavior in the makefile?
On other systems, this makes the GCC build not relocatable at install
time. I don't know if that is true on mingw32 also, but I presume so.
--
Daniel Jacobowitz
CodeSourcery, LLC
to use this feature. GCC usually passes ld
> whatever path specifications it needs.
I build mingw cross toolchains with sysroots :-) That'll be affected
by this change. Of course, currently I cross-build them from
--build=i686-linux, so it doesn't affect me directly.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Thu, 2005-07-21 at 14:51 +0200, Volker Reichelt wrote:
> Ian Lance Taylor wrote in http://gcc.gnu.org/ml/gcc/2005-07/msg00625.html:
>
> > In preparation for the future transition to subversion, I've written
> > some code to merge the old-gcc repository into current mainline. I
> > would like t
I ran into a template-y ICE building a real app with gcc-4.0.1:
my-callback-specializations.h: At global scope:
my-callback-specializations.h: In instantiation of
'_MemberResultCallback_0_1':
my-flow.cc:894: instantiated from here
my-callback-specializations.h:2064: internal compiler error: in
On Fri, 2005-07-22 at 17:53 -0700, Steve Kargl wrote:
> On Fri, Jul 22, 2005 at 05:44:44PM -0700, Jerry DeLisle wrote:
> > Steve Kargl wrote:
> > >Does this look familiar to anyone?
> > >
> > I was having troubles doing a build after a cvs update. I had to delete
> > everything in the build direc
On Sun, 2005-07-24 at 19:44 +0200, Gabriel Dos Reis wrote:
> Hi Dan,
>
> Commands for querying open bugs for a specific target (say 3.4.5) of
> a product do not seem to exist. The documentation for "index" says
>
> index
>
> But what I'm looking for is something like
>
> index
Fixed now
Sorry about that.
On Sun, 2005-07-24 at 21:03 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | > But what I'm looking for is something like
> | >
> | > index
> | >
> | > probably augmented wi
On Sun, 2005-07-24 at 22:06 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | Fixed now
>
> Indeed. works now.
> It would be great if bugzilla could send a notice back when it decides
> to ignore commands :-)
Perl error handling is
> OK.
>
> I have one more request.
>
> Is it possible for "index" to also output the number of matches found,
> as first line? (just like with the web interface).
>
> One thing I would also find quite valuable is that the description
> contains the component name, e.g.
>
> c++/21784:
On Mon, 2005-07-25 at 11:41 +0200, Gabriel Dos Reis wrote:
> Hi,
>
> The SC has agreed me taking up the GCC-3.4.5 ball.
> I'm planning for two releases from the GCC-3.4.x series this year:
> (a) GCC-3.4.5 on September 30, and
> (b) GCC-3.4.6 on December, 15.
>
> The number of bugs (reg
On Mon, 2005-07-25 at 14:01 +0400, Vladimir A. Merzliakov wrote:
> > Hi all,
> >
> > Are there any open-source(or free) front-end which translates C++ to C?
> > I could find some commercial things - Comeau, AT&T Cfront, etc., but
> > these have many limitations(especially, It's too difficult to ge
On Tue, 2005-07-26 at 18:39 -0400, drizzle drizzle wrote:
> I am not sure if I unerstand ...can you elaborate please ? So what I
> need is if I identify say a reference a[i] inside a loop, I want to
> identify the corresponding RTL.
What are you trying to do at the RTL level with array reference
On Tue, 2005-07-26 at 19:42 -0400, drizzle drizzle wrote:
> What doesnt exist very long - the references ?
By RTL, they've been expanded to pointer accesses.
> At RTL level, I just want to insert a counter for each one of
> these.
Why do it at the rtl level.
Why not do it at the tree lev
call_expr.
Look at what tree-profile.c does.
> I
> know how to insert it into the tree but some how all my creations
> attempts with build_function_call fail.
>
> thanks once again ...
>
> On 7/26/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-0
On Wed, 2005-07-27 at 13:08 +0200, Richard Guenther wrote:
> Hi all!
>
> I reduced my array aliasing libstdc++ failures to the following
> testcase:
>
> struct iterator
> {
> int* ptr;
> iterator(int* _ptr) : ptr(_ptr) {}
> };
>
> struct container {
> int* first;
> container(int*
On Wed, 2005-07-27 at 16:02 +0200, Richard Guenther wrote:
> On Wed, 27 Jul 2005, Diego Novillo wrote:
>
> > On Wed, Jul 27, 2005 at 03:09:09PM +0200, Richard Guenther wrote:
> >
> > > i.e. while we see that the temporary pointer points to array[0], for
> > > SFT.2_6 (i.p) we don't see anything?
On Wed, 2005-07-27 at 12:33 -0400, drizzle drizzle wrote:
> Hi
> I am trying to insert a function call "foo" inside the tree list.
>
>
> Inside this particular loop
> for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
> {
>
> //if a partic
On Wed, 2005-07-27 at 12:58 -0400, drizzle drizzle wrote:
> Its inside this function
>
> static inline var_ann_t
> var_ann (tree t)
>
> from the error dump itseems to the following assertion
> gcc_assert (DECL_P (t))
>
>
> thanks
>
I'm gonna need a lot more info than that.
Maybe you shoul
On Wed, 2005-07-27 at 17:54 +0100, Paul Brook wrote:
> On Wednesday 27 July 2005 17:33, drizzle drizzle wrote:
> > Hi
> > I am trying to insert a function call "foo" inside the tree list.
> >
> >
> > Inside this particular loop
> > for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next
On Wed, 2005-07-27 at 13:39 -0400, drizzle drizzle wrote:
> Thanks for your help. I am attaching my patch. Most of the code dont
> modify anything. The code I am talking about is ia small piece in
> tree-data-ref.c in a function insert_annotations. The only
> modification in the rest of the code i
ost part but if,
> for example, you take the address of the function, use the
> actual symbol stat(). But I see that most other fixincs
> use static inline.
Huh? This paragraph conflicts with the previous one I quoted. You
don't want extern inline, because you don't want the symbol stat() to
be called - that's your whole problem.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Thu, 2005-07-28 at 19:26 +0200, François-Xavier Coudert wrote:
> Hi all,
>
> PR 22619 and PR 22509 are two examples of recent 4.1 regressions that
> showed up in gfortran, due to middle-end or optimization bugs (only
> happen at -O3). Since these are regressions, they should be treated
> before
new programs. Any alternative that allows you to
generate an undefined reference to stat is a bad alternative, because
it will call the legacy function from new code.
--
Daniel Jacobowitz
CodeSourcery, LLC
hope that makes at least a little sense.
>
> I suspect that the problem is mips specific as _gp_disp handling is mips
> specific.
Yes, you're probably right. I thought this sounded familiar, but
couldn't find any references.
--
Daniel Jacobowitz
CodeSourcery, LLC
ed to their solution in principle, AFAICT, although there
was some discussion afterwards about whether the use of strong
namespace using was really necessary. I'm afraid I don't understand
C++ well enough to explain the rest of that conversation.
May just need someone to do the work.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Sun, Jul 31, 2005 at 03:53:42PM +0100, Mike Hearn wrote:
> On Sun, 31 Jul 2005 00:57:49 -0400, Daniel Jacobowitz wrote:
> > You may wish to read the proceedings from this year's GCC summit, where
> > another solution was presented by some gentlemen from Intel. For various
It has gotten to the point where people are reporting bugs in our wiki
that i can't fix because the phpwiki code it too much like spaghetti.
There is one main phpwiki developer, and while he's very good at php
development, the codebase dwarfs him :).
I'm thinking of moving us to a more actively d
On Mon, 2005-08-01 at 00:30 +0200, Gerald Pfeifer wrote:
> On Fri, 15 Jul 2005, Tom Tromey wrote:
> >> The FAQ is badly in need of an update - in fact, it should be moved
> >> over to the Wiki (http://gcc.gnu.org/wiki/GCJ) in order to be easier
> >> to update and maintain.
> > Great idea, I agree.
On Mon, 2005-08-01 at 01:02 +0200, Gerald Pfeifer wrote:
> On Sun, 31 Jul 2005, Daniel Berlin wrote:
> >> We may to want to wait until we hear about the outcome of discussion
> >> on the copyright (assignment) aspects of the Wiki vs wwwdocs and gcc/doc,
> > We are
On Sun, 2005-07-31 at 23:12 +, Joseph S. Myers wrote:
> On Mon, 1 Aug 2005, Gerald Pfeifer wrote:
>
> > We may to want to wait until we hear about the outcome of discussion
> > on the copyright (assignment) aspects of the Wiki vs wwwdocs and gcc/doc,
> > or we may be in troubles at some point
On Sun, 2005-07-31 at 22:50 -0400, Robert Dewar wrote:
> Gerald Pfeifer wrote:
> > On Sun, 31 Jul 2005, Daniel Berlin wrote:
> >
> >>For code.
> >>I have never seen such claims made for documentation, since it's much
> >>easier to remove and deal
On Sun, 2005-07-31 at 23:20 -0400, Richard Kenner wrote:
> You don't really need copyright assignment (IE you can go along with
> just licenses) unless you plan on suing people over your documentation,
> which seems even less likely than suing someone over your code.
>
> I don't follow
On Mon, 2005-08-01 at 22:36 +0800, Chunjiang Li wrote:
> Hi, all:
>
> Also the problem about Pseudo register usage.
>
> I want to know the Pseudo registers used (def and ref) in a basic block.
> How can I get these result using the APIs presented in GCC?
> Need help. Urgently
>
See df.h/df.c
On Mon, 2005-08-01 at 17:27 +0300, Dorit Naishlos wrote:
>
>
>
> > ...
> >
> > The problem seems to be that analyze_offset_expr calls the scev
> > analyzer explicitely asking for recomputation (third parameter is
> > true):
> >
> > ...
> >
> > Why should we start the analysis from scratch in thi
It would be if the line were:
ptr = &((cons *)(ptr))->cdr;
which is equivalent to some offset plus ptr. But there's an extra
dereference:
ptr = &((cons *)(*ptr))->cdr;
^
As far as I can tell, this code doesn't actually violate any of the
aliasing rules. It just looks funny.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Tue, Aug 02, 2005 at 09:57:39AM -0400, Diego Novillo wrote:
> On Tue, Aug 02, 2005 at 09:39:56AM -0400, Daniel Jacobowitz wrote:
>
> > Then the alias analyzer's broken.
> >
> Broken? I'm saying that we currently get this right. I don't
> know what posit
> > OK, thanks. That settles it then.
>
> Just to close out this thread for the record, Andrew Pinski opened PR
> 23912 for this problem, and Diego checked in a patch for the 4.0
> br
> n
> h. So all should be well in 4.0.2.
>
And the alias analyzer for 4.1 has tihs code, which is why it comes
On Tue, 2005-08-02 at 22:07 +0200, Gabriel Dos Reis wrote:
> Hi,
>
> The number of open PRs registered as CC-3.4.x regressions only and
> targetted for 3.4.5 has decreased from 125 (last week) to 115. Which
> is a progress! Still, we have too many PRs for a stable branch.
>
> Here is the com
2nd implementation?:
http://www.cs.berkeley.edu/~dsw/
This is what we all use, AFAIK :)
On Wed, 2005-08-03 at 22:54 -0700, Dan Kegel wrote:
> Geez, 'delta' from http://www.cs.berkeley.edu/~dsw
> really does seem to make it easy to track down
> near-minimal testcases for ICEs.
Just remember to use topformflat and -Wfatal-errors to make it faster
(it's particularly helpful for C++ :P)
On Mon, 2005-08-08 at 08:40 -0700, Dan Kegel wrote:
> Sebastian Pop wrote:
>
> Since I started playing with delta debugging for
> tracking down ICEs, I've been thinking it might
> be nice to have an option to gcc to perform
> delta debugging automatically if an ICE occurs,
> and have it automatica
Hi all,
I am encountering a problem with DWARF location lists. Consider the
following assembly:
_Ltext:
main:
_LVL0:
;# basic block 0
_LVL1:
This generates a DWARF location list entry whose begin and end addresses
are identical, due to the empty basic block. Not a great problem on the
On Tue, 2005-08-09 at 12:28 +0100, Daniel Towner wrote:
> Hi all,
>
> I am encountering a problem with DWARF location lists. Consider the
> following assembly:
>
> _Ltext:
> main:
> _LVL0:
> ;# basic block 0
> _LVL1:
>
> This generates a DWARF loc
On Tue, 2005-08-09 at 12:54 +0200, Laurent GUERBY wrote:
> On Tue, 2005-08-09 at 11:02 +0200, Sebastian Pop wrote:
> > I'm proposing to automate gcc's bootstrap & regtest: for each mail
> > sent to [EMAIL PROTECTED], if 'From' is in gcc-developpers and 'body'
> > contains a patch against some branc
[EMAIL PROTECTED] wrote:
Okay, I stand corrected. As a practical implementation we can have a
mechanism as push/pop timevar, that would monitor the time and space
of an algorithm and that can cancel the computation for failing on a
safe approximation. As a first concretization, I was thinking t
On Tue, 2005-08-09 at 20:11 +0200, Laurent GUERBY wrote:
> On Tue, 2005-08-09 at 08:53 -0400, Daniel Berlin wrote:
> > > Looks good. I think it would be slightly more secure to have people
> > > commit the patch with a unique name in some access-controlled CVS
> > >
Andrew wrote:
>> No threads in gcc, please.
>
> Why? If this is only for double checking, why not?
Sorry, I missed that boehm-gc already uses threads.
Ignore me, I'm just a cranky old-school programmer...
but still, if there's a way to implement the checker
without using threads, that would sur
On Tue, 9 Aug 2005, Sebastian Pop wrote:
Joe Buck wrote:
Algorithms that are sometimes exponential can still be used if there is
a cutoff mechanism, to abort the algorithm if it exceeds a budget. This
assumes that we can then fall back to an algorithm that might produce
inferior results, but
On Tue, 2005-08-09 at 23:06 +0200, Björn Haase wrote:
> Steven Bosscher wrote:
> > In
> > any case, you should assume that it is a much bigger job than just
> > modifying the call expander.
>
> Ok, I had a closer look at what is happening in present state gcc and I
> understand that it is indeed
n mingw.
>
> FWIW, I'm opposed to the "#!" change to MinGW. It just seems hackish to
> me, and it means that we'll pay an additional cost on all normal uses of
> pex-* on MinGW, even after the compiler is installed.
Not if it's implemented after CreatePro
Could you please check what's going on there? Is this a general problem
with gcc-gnats processing or a problem parsing that particular message?
Dunno. Grepping mail logs older than an hour takes a while on
sourceware, because they are large. Can you resend it and notify me when
you do?
gc
On Fri, 2005-08-12 at 13:24 +0200, Gabriel Dos Reis wrote:
> Rainer Orth <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I'm using gccbug since it provides the complete template where I just need
> | to fill in the beef of the report. All I care for is the ability to handle
> | bugs completely by em
On Fri, 2005-08-12 at 11:23 +0200, Rainer Orth wrote:
> Daniel Berlin writes:
>
> > > Could you please check what's going on there? Is this a general problem
> > > with gcc-gnats processing or a problem parsing that particular message?
> >
> > Dunno. Gr
> The other thing we could try to do is put virtual variables in loop-closed-
> form, at least just before the vectorizer, and at least just for some
> loops. Does this sound reasonabale? (By the way, why don't we keep virtual
> variables in loop-closed-form?)
We used to, nobody could come up with
On Fri, 2005-08-12 at 16:52 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | AFAICT (at least according to mail logs, etc) you are the only user of
>
> apparently, you've to count properly.
What?
You do read what i wrote, right?
I said
>
> Should I open a PR?
Yes
>
> Cheers,
> Martin
On Sun, 2005-08-14 at 01:12 +0200, Sebastian Pop wrote:
> Joe Buck wrote:
> > The problem with using time as a cutoff is that you then get results that
> > can't be reproduced reliably. Better to count something that is a feature
> > of the algorithm, e.g. number of executions of some inner loop,
On Sun, 2005-08-14 at 13:14 +0200, Sebastian Pop wrote:
> Daniel Berlin wrote:
> >
> > Sebastian, I really think you are worrying too much.
>
> right.
>
> > It's pretty rare that it will take going all the way to omega to be able
> > to disambiguate
> You'd expect the attempt to grow the stack to be made only *after*
> keep_going hits zero.
Only if you thought you knew better than the compiler :)
> I'd rather not have the compiler presume
> certainty of a 10GB stack allocation, especially not if it's actually
> pretty unlikely.
It could
re was implemented back in
3.3; the behavior hasn't been _changed_ and won't be until there is
consensus.
I believe that it's still can be caught, must be rethrown, or the
program will be aborted. Someone who knows better than I may want to
confirm this.
--
Daniel Jacobowitz
CodeSourcery, LLC
> As already stated I think that the usage of different algorithms for
> calculating live info causes the problem. Is there a reason that the
> live analysis used by global alloc isn't used everywhere?
Vlad promised to update it to use df.c once it wasn't "1% slower", which
would make it easily re
tions? Can anyone point me at
another port which solves this problem?
thanks,
dan.
Daniel Towner
picoChip Designs Ltd., Riverside Buildings, 108, Walcot Street, BATH,
BA1 5BG
[EMAIL PROTECTED]
07786 702589
On Wed, 2005-08-17 at 02:45 +0200, Sebastian Pop wrote:
> Steven Bosscher wrote:
> > Hi,
> >
> > Something commited a few days ago had resulted in a serious performance
> > hit for SPEC sixtrack on 64 bits machines... The obvious suspect is
> > Sebastian Pop's scev patch. The affected targets ar
On Sat, 2005-08-20 at 00:44 +0200, Laurent GUERBY wrote:
> On Sat, 2005-08-20 at 00:36 +0200, Laurent GUERBY wrote:
> > A patch by Andrew Pinski is there:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01666.html
> >
> > But review was negative, so it was not commited.
> >
> > Hope this he
On Sat, 2005-08-20 at 19:15 -0700, Richard Henderson wrote:
> On Fri, Aug 19, 2005 at 09:34:35PM -0400, Daniel Berlin wrote:
> > But for general IPA working on the cgraph + GIMPLE level, as is what is
> > happening here, I think we really need to do something about static
> >
> And would that be because analyze_expr isn't implemented for Ada?
That doesn't bother me so much, actually (mainly because i don't care
about Ada). It's the fact that it's popping up in C/C++ that does.
>
> > IE if we have something very funky like:
> >
> > static int c;
> > static int d;
>
> Warning for pointer generation is going to be a *lot* harder and I
> suspect will always result in more false positives.
In order to increase the accuracy of the data dependence analysis, i do,
at some point, plan on tracking the sizes of malloc sites, and giving an
upper bound on them (for cas
On Tue, 2005-08-23 at 16:44 +0200, Bernd Schmidt wrote:
> Andreas Krebbel wrote:
>
> > Ok I understand that implementing the special lifeness analyzers in global
> > alloc
> > using the df.c framework would ease reusing it somewhere else. But my
> > question
> > was more basic.
> > So do you agr
On Tue, 2005-08-23 at 17:06 +0200, Bernd Schmidt wrote:
> Daniel Berlin wrote:
>
> > If you make them all defined, then it's going to be live where it wasn't
> > before, even though it's not really *used* over those paths.
>
> The idea is to put the initi
On Tue, 2005-08-23 at 22:10 -0500, Peter Bergner wrote:
> On Tue, 2005-08-23 at 21:26 +0200, Bernd Schmidt wrote:
> > As Jim points out, we may have to do that for IA64 anyway, so we could
> > consider doing it on all targets. Dan is correct that this can
> > introduce new code that won't be eli
On Wed, 2005-08-24 at 08:47 -0500, Peter Bergner wrote:
> On Wed, 2005-08-24 at 00:07 -0400, Daniel Berlin wrote:
> > I imagine if you have 300k bb's or 1.5 million live pseudos to consider,
> > it probably makes a real difference, but that's not *too* common in our
>
Currently, get_expr_operands "renormalizes" the actual tree operands on
it's own whim , such that if you call update_stmt on something like "a +
c", it may be "c + a" after the call to update_stmt.
This is not the same as sorting the use operands, vuses, etc, which is
fine.
This is actually modify
On Wed, 2005-08-24 at 18:15 +0200, Niko Matsakis wrote:
> Attempting to edit the Wiki or otherwise login seems to generate an
> error. This may be because I don't have an account. Error text below.
>
You don't need a real account, just login as any wikiword.
I think you are probably trying to
> The auto-canonicalization does present some problems. No doubt about
> that. However, I was added specifically because it was allowing us
> to eliminate more useless crud. IIRC it was comparison elimination
> that primarily benefited from auto canonicalization.
I think that part may have been
On Wed, 2005-08-24 at 12:33 -0700, James E Wilson wrote:
> Nick Clifton wrote:
> > The reason for this behaviour is that the debug information is being
> > written out before the variables have been fully resolved. In
> > particular DECL_SET() for the second and third observer functions is
>
> If we take this after DCE, we still refer to a statement which no longer
> exists which we don't collect in the GC.
As i said when i pointed this out to you, we should probably skip
walking common.chain on SSA_NAME.
But that's non-trivial hard because it's a reused field :(
>
> Could someone lo
On Wed, 2005-08-24 at 19:19 -0400, Andrew MacLeod wrote:
> On Wed, 2005-08-24 at 18:28 -0400, Daniel Berlin wrote:
> > > Could someone look into this and see what they can do?
> >
> > You should probably ask Diego or Andrew directly whether they'd like us
> &
will have a rather perplexing effect
> if such a file is compiled. Maybe that's OK.
Personally, I think that's OK. Document ./@file.
--
Daniel Jacobowitz
CodeSourcery, LLC
s a general convention, on any platform.
(That said I don't love the @filename syntax; but it could be worse,
and it seems fairly well-known...)
--
Daniel Jacobowitz
CodeSourcery, LLC
Ivan Novick <[EMAIL PROTECTED]> wrote:
> Can you recommend a solution for compiling Windows DLLs on any variation of
UNIX?
You want mingw, I think. The doc for this is somewhat scanty.
See e.g.
http://www.mingw.org/mingwfaq.shtml#faq-cross
http://wiki.wxwidgets.org/wiki.pl?Install_The_Mingw_Cro
y
to disable all floating point tests, and all IO tests in the testsuite,
other than adding suitable target directives in each file?
thanks,
dan.
Daniel Towner
picoChip Designs Ltd., Riverside Buildings, 108, Walcot S
as clever as we cross-GCC people who were
> considered being complete idiots? :-)
As one of the people who implemented this, I take offense at your
comments. If you couldn't tell.
--
Daniel Jacobowitz
CodeSourcery, LLC
> If what I'm saying here is correct, some redundant expression might
> be inserted.
We have testcases (search bugzilla for GCSE) with redundant expressions
being inserted by GCSE (repeatedly, such that if you run GCSE 5 times,
it inserts the same expression 5 times in the same place). If you ar
501 - 600 of 2005 matches
Mail list logo
