On 3/30/07, Antoine Eiche <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> On 3/27/07, Antoine Eiche <[EMAIL PROTECTED]> wrote:
>> Dear all,
>>
>> I want to insert functions calls during a new pass.
>
> Which version of GCC?
> The problem i
On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Aldy Hernandez <[EMAIL PROTECTED]> writes:
There are a number of other compilers with successful IR
implementations, and some of them are open source, such as LLVM or
Open64. Since you are essentially proposing a new IR,
On 3/30/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> The aliaser is fairly aggressive at removing TREE_ADDRESSABLE from
> variables that do not need it anymore, so that should not be a problem.
Yes, but you're calling the lang hook, which in theory, is allowed
to do all sorts of different thi
On 3/30/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> The lang hook is supposed to mark the variable as addressable.
> The lang hook should not be changing other things that have an affect
> on the *middle end*. No exceptions.
But how is it "supposed to mark the variable as addressable"? If
On 4/4/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hello,
>
> at the moment, any pass that needs to process memory references are
> complicated (or restricted to handling just a limited set of cases) by
> the
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
at the moment, any pass that needs to process memory references are
complicated (or restricted to handling just a limited set of cases) by
the need to interpret the quite complex representation of memory
references that we have in gimple
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> >Proposal:
> >
> >For each memory reference, we remember the following information:
> >
> >-- base of the reference
> >-- constant offset
> >-- vector of indices
> >-- type of the accessed location
> >-- original tree of the memory ref
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> >> >-- flags
> >> >
> >> >for each index, we remeber
> >> >-- lower and upper bound
> >> >-- step
> >> >-- value of the index
> >>
> >> This seems a lot, however, since most of it can be derived from the
> >> types, why are we also kee
On 4/4/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hello,
>
> at the moment, any pass that needs to process memory references are
> complicated (or restricted to handling just a limited set of cases) by
> the need to interpret the quite compl
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> >> >> That is, unless we could share most of the index struct (upper,
> >> >> lower, step) among expressions that access them (IE make index be
> >> >> immutable, and require unsharing and resharing if you want to modify
> >> >> the
On 4/5/07, Eric Weddington <[EMAIL PROTECTED]> wrote:
Hi,
My goal is to get more involved in Binutils, GCC, and possibly GDB, for the
AVR port, to help where I can. My FSF paperwork is in process on my
company's side but it may take a while. In the meantime I would like to
request Bugzilla-only
On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Following up on the recent discussion about GIMPLE tuples
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
our main ideas and implementation proposal in the attached document.
This should be enough to get the implementati
On 4/10/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor wrote on 04/10/07 13:53:
> I seem to recall that at one point somebody worked on a gensimplify
> program or something like that. Would it make sense to revive that
> approach, and use it to generate simplifiers for trees, GIM
On 12 Apr 2007 15:14:01 -0700, Geoffrey Keating <[EMAIL PROTECTED]> wrote:
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++.
The FSF libstdc++ is, I believe,
binary incompatible wit
On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 16:14:
> Looks great, still I think "locus" and "block" could be both merged into
> single integer, like RTL land has INSN_LOCATOR.
That's the idea. But it's simpler to do this for now. The insn locator
is easi
On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 21:14:
> I just wondered if your document is documenting the final shape or what
> should be done during hte first transition. If the second, probably 2
> words should be accounted for location as source_locues i
On 4/15/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote on 04/14/07 22:59:
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's for
> statements that generate vdefs/vuse
On 4/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
As has been remarked on the GCC mailing lists, I've not succeeded in
getting GCC 4.2.0 out the door. However, with the limited criteria that
we target only P1 regressions not present in 4.1.x, we seem to be
getting a bit closer. The only regr
On 4/16/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
Hello all,
I'm going through the bodies of all user-defined functions. I'm using
as user-defined function as one that:
DECL_BUILT_IN(node) == 0.
Problem is that for a function (derived from a C++ file) whose output
from my pass is (outpu
On 4/16/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> On 4/16/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> >Hello all,
> >
> >I'm going through the bodies of all user-defined functions. I'm using
> >as user-defined function as one that:
> >DECL_BUILT_IN(node) == 0.
>
> >
> >Problem is that for
We discussed the patch tracker. None of the active maintainers who
were there appear to use it very much or at all.
This is because it does not enable them to easily review patches, only
to see which they have missed ;)
I proposed
automatic e-mail pings, but that wasn't generally wel
On 20 Apr 2007 11:42:57 -0600, Tom Tromey <[EMAIL PROTECTED]> wrote:
Ian> I proposed automatic e-mail pings, but that wasn't generally
Ian> welcomed.
Bummer. Why?
Dan> If people are okay with this, I have no problem implementing it.
If you're taking feature requests, it would be handy to cano
On 4/21/07, Mike Stump <[EMAIL PROTECTED]> wrote:
We still have some lno bits in our tree. We tried to remove them and
found:
gzip +0.5%
vpr -0.4%
gcc -3.2%
mcf -0.3%
crafty +0.2%
parser +0.2%
perlbmk -2.2%
gap +0.2%
vortex -0.1%
bzip2 +1.9%
twolf -0.7%
on x86 (probably a core2 duo) in our 4.2
It still has the addresses_taken bitmap, remove it :)
Also, I assume for a call with no return, it will be a GS_CALL with lhs == NULL?
On 4/25/07, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
I have uploaded a new version of the tuples document, with the latest
discussions.
http://gcc.gnu.org/wi
On 5/3/07, Ralf Corsepius <[EMAIL PROTECTED]> wrote:
Hi,
for reasons I don't know, I am not able to create attachments in gcc's
bugzilla for ca the last 24hrs. When doing so, I am greeted with the
message below.
--- snip ---
Internal Error
GCC Bugzilla has suffered an internal error. Please sa
On Mon, 2005-02-28 at 00:38 +0100, Zdenek Dvorak wrote:
> Hello,
>
> > >Although you have listed it as "stage 2", I wish to commit the finished
> > >portion as soon as possible during stage 1. I have maintainership
> > >authority
> > >to do so. This will not interfere in any way with *any* of t
The SVN repo has been updated again.
Again, because different tags were included in this dump, you will have
to recheckout a working copy.
The only tags excluded from this run were tags with "merge" in the name,
and tags with ".*-ss-.*" and ".*_ss_.*".
For those who want http access, i can give
On Tue, 2005-03-01 at 21:00 +, Joseph S. Myers wrote:
> On Tue, 1 Mar 2005, Daniel Berlin wrote:
>
> > > Date: 2005-03-01 15:26:25 -0500 (Tue, 01 Mar 2005)
>
> I take it the time will be shown in gcc.gnu.org's timezone (fixed at UTC),
> not depending on the time
On Tue, 2005-03-01 at 22:21 +, Joseph S. Myers wrote:
> On Tue, 1 Mar 2005, Daniel Berlin wrote:
>
> > > That is, there won't be
> > > any problems like those mentioned in comments in bugzilla-checkout and
> > > htdocs-checkout and cgibin-checkout
Due to some massive speedups i've implemented in cvs2svn, the full gcc
repo, including all non-broken tags (more in a moment), is now
available. It would have taken ~7 days before, and now it takes less
than 2 (it's almost completely disk bound now, and my 7200rpm disks just
aren't fast enough app
On Sun, 2005-03-06 at 18:34 +, Joseph S. Myers wrote:
> On Sun, 6 Mar 2005, Daniel Berlin wrote:
>
> > I have converted most all of our scripts at this point, and verified
> > they work trivially (IE that changing something in www makes it update
> > the www dir
On Sun, 2005-03-06 at 18:34 +, Joseph S. Myers wrote:
> On Sun, 6 Mar 2005, Daniel Berlin wrote:
>
> > I have converted most all of our scripts at this point, and verified
> > they work trivially (IE that changing something in www makes it update
> > the www dir
On Sun, 2005-03-06 at 18:53 +, Joseph S. Myers wrote:
> On Sun, 6 Mar 2005, Daniel Berlin wrote:
>
> > I have no clue how the savannah mirroring works now, or who to contact.
> > Pointers would be appreciated.
> >
> > If they mirror via rsync, they just nee
On Sun, 6 Mar 2005, Joseph S. Myers wrote:
On Sun, 6 Mar 2005, Daniel Berlin wrote:
mailer.conf needs a bit more configuration to get all the right messages
to the right mailing lists, but that's trivial.
(And to ensure that the messages have the right sender address, i.e.
[EMAIL PROTECTED]
On Sun, 6 Mar 2005, Joseph S. Myers wrote:
On Sun, 6 Mar 2005, Daniel Berlin wrote:
The main waiting thing at htis point is for subversion 1.2 and for
With regard to this point, will accessing the repository via SVN protocols
need 1.2 on the client, or will it only be needed on the server and if
On Thu, 2005-03-10 at 18:02 +, Nathan Sidwell wrote:
> Razya Ladelsky wrote:
> > Hi,
> >
> > My case is this:
> > I version the operator<< function and name it operator<<.number (creating
> > an identifier which is not valid in the source code).
> > The assembly name created for the versioned
> My personal feeling I think the success of the Wiki is that it does not
> require review, rather than the fact that the Wiki syntax is partially
> lighter than HTML. The 48-hrs rule I propose seems sensible to me. The worst
> thing that can happen is that something incorrect goes live on the sit
On Fri, 11 Mar 2005, Jason Merrill wrote:
On Tue, 08 Mar 2005 10:28:44 -0500, Daniel Berlin <[EMAIL PROTECTED]> wrote:
However, according to Jakub,
"
TYPE_NAME (TYPE_MAIN_VARIANT (origin)) on that testcase is NULL, so it
doesn't help match."
...which is why we still need TYPE
On Sun, 2005-03-13 at 10:54 +0200, Razya Ladelsky wrote:
> Mark Mitchell <[EMAIL PROTECTED]> wrote on 11/03/2005 04:55:38:
>
> > Daniel Berlin wrote:
> >
> > > As for why the new name doesn't work, it's not clear from the above.
>
On Sun, 2005-03-13 at 16:42 +0100, Steven Bosscher wrote:
> On Sunday 13 March 2005 16:31, Daniel Berlin wrote:
> > > bl operator<<.585
> >
> > ^^^
> >
> > You are using the demangled name instead of the mangled one, which is
>
On Sun, 2005-03-13 at 15:26 +0100, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>
> | On 2005-03-12 02:59:46 +0100, Gabriel Dos Reis wrote:
> | > You probably noticed that in the polynomial expansion, you are using
> | > an integer power -- which everybody agrees on yield
On Wed, 2005-03-16 at 04:56 +0100, [EMAIL PROTECTED]
> | > | Bison remains a good solution in many cases, especially for languages
> | > | specifically designed to be easy to parse with an LALR parser (that is,
> | > | languages that don't look like C).
> | >
> | > Why don't we develop a "LR(k) /
On Tue, 2005-03-15 at 23:41 -0500, Daniel Berlin wrote:
> On Wed, 2005-03-16 at 04:56 +0100, [EMAIL PROTECTED]
> > | > | Bison remains a good solution in many cases, especially for languages
> > | > | specifically designed to be easy to parse with an LALR parser (that
> &
On Wed, 2005-03-16 at 06:09 +0100, [EMAIL PROTECTED]
wrote:
> | > It's possible that C++ doesn't require unbounded lookahead
> |
> | No, it's not.
> | In fact, if you'd read the language grammar definition, you'd discover
> | you could pretty produce the anti-program with some work.
> | That given
Updated as of yesterday's CVS.
As always, you'll need to blow away your working copy
I haven't had time to move the hooks from dberlin.org's repo to the new
repo yet.
> Truly Critical
> --
>
> 19225 Segmentation fault with VLAs, affects GLIBC
>
> This is the TYPE_STUB_DECL that Dan Berlin looked into for a while.
> What is the current status?
I think you mean 19345.
Anyway, the long and short of it is that the real bug here is that
TYPE_NAME
On Mon, 2005-03-28 at 16:08 +0200, Steven Bosscher wrote:
> On Mar 28, 2005 03:08 AM, Kazu Hirata <[EMAIL PROTECTED]> wrote:
> > Huh, whey I talked to them on IRC they didn't seem to have implemented
> > this. I'll try to get this issue one of these days.
>
> Ehm. I did in fact implement this.
On Mon, 2005-03-28 at 14:27 -0800, Mike Stump wrote:
> On Mar 28, 2005, at 12:12 PM, Christian Joensson wrote:
> > Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre)
> > sun4u:
>
> > I get these failures and just would like to ping for any ideas what
> > might be wrong...
> >
>
On Tue, 2005-03-29 at 15:50 +0200, Florian Weimer wrote:
> * Robert Dewar:
>
> > Unfortunately, you can't rely on sane judges, since the plaintiff can
> > always demand a jury trial, and you would be surprised what juries think.
> > Furthermore, deleting the test case makes no sense as a remedy. E
On Tue, 2005-03-29 at 10:10 -0500, Richard Kenner wrote:
> In reality, a person who submits code knowing it is going to be
> distilled and used in testsuites under our license would probably be
> estopped from claiming it violates their copyright to do so. They are
> going to have
On Tue, 2005-03-29 at 14:52 -0800, Joe Buck wrote:
> Daniel Berlin wrote:
> > >IE if we added a very large warning to the submission page that said
> > >"PLEASE NOTE: BY SUBMITTING A TESTCASE, YOU AGREE THAT WE HAVE THE RIGHT
> > >TO CREATE, USE, AND PUBLISH
On Fri, 2005-04-01 at 12:43 +0100, Andrew Haley wrote:
> Sam Lauber writes:
> > I know that Bohem's GC is used in the Java runtime for GCC.
> > However, the compiler proper itself can _really_ cramp people's
> > avalible RAM (for those who don't belive me and have Windows w/
> > DJGPP, change a
On Mon, 2005-04-04 at 22:49 +0200, Steven Bosscher wrote:
> Hi,
>
> We have a bootstrap time regression since March 30. Bootstrap times
> on Diego Novillo's SPEC box went up from (an already high) 5500s to
> almost 8000s, see:
> http://people.redhat.com/dnovillo/spec2000/gcc/gcc-compiler-build-s
in order to prevent being spammed, the wiki has been changed to require
"bogo" logins before editing pages.
You can use any WikiWord you like as a login name, and it will work (and
you can set a password if you really like).
So don't be thrown off when it asks you for a login name and password to
On Fri, 2005-04-08 at 12:45 -0400, Diego Novillo wrote:
> One of the micro-optimizations I am about to merge from TCB
> involves disregarding V_MAY_DEF/V_MUST_DEF operands for read-only
> globals.
>
> So, if a symbol is marked read-only and the operand scanner
> requests a V_MAY_DEF or V_MUST_DEF
> When we rescan the operands, we get a different set of V_MAY_DEFS,
> specifically we lose the V_MAY_DEF for SFT.3_20.
Why?
It should be copying subvars to the new vectorizer variable too.
At least, i believe i added that.
On Fri, 2005-04-08 at 11:08 -0600, Jeffrey A Law wrote:
> On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> > > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > > specifically we lose the V_MAY_DEF for SFT.3_20.
> >
> > Why?
> &g
On Fri, 2005-04-08 at 13:58 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 11:44:34AM -0600, Jeffrey A Law wrote:
>
> > For the alias not to be relevant would indicate that vectorization
> > actually improved alias analysis.
> >
> Right. Both ivopts and vectorization have that effect, an
> > Also, after ivopts, the whole CFG needs to be
> > re-scanned because the new alias relations it creates affect
> > statements that have not even been modified by the process.
> Wow. Egad.
>
Yes, this would be very ungood if it is the case.
If it is really changing the *semantics* of the pr
On Fri, 2005-04-08 at 18:48 -0400, Daniel Jacobowitz wrote:
> On Sat, Apr 09, 2005 at 12:35:47AM +0200, Steven Bosscher wrote:
> > On Saturday 09 April 2005 00:32, Diego Novillo wrote:
> > > On Thu, Apr 07, 2005 at 08:34:01PM -0400, Diego Novillo wrote:
> > > > I'm rebooting the machine into the pr
On Fri, 2005-04-08 at 16:51 -0700, Dale Johannesen wrote:
> On Apr 8, 2005, at 4:40 PM, Mark Mitchell wrote:
>
> > Daniel Berlin wrote:
> >
> >> Your transform is correct.
> >> The FE is not. The variable is not read only.
> >> It is write once, th
On Tue, 2005-04-12 at 19:42 +0100, Nathan Sidwell wrote:
> Hi,
> I promised to fix up the vector api, and there's a design decision
> which needs to be made (incidentally, if we were in C++ land, we wouldn't
> have to chose, as the right thing just happens).
> Option1 is more easy to implement. Op
But it turned out that CSE around basic blocks (-fcse-skip-blocks) was
still a very useful thing to do (and it still was, when I looked at it
again a couple of weeks ago).
And I would *very much* like to know why! My view was always that any
global CSE at all should render it unnecessary
On Mon, 2005-04-18 at 13:34 -0700, Dan Nicolaescu wrote:
> [EMAIL PROTECTED] (Richard Kenner) writes:
>
> > The correct viewpoint is "we shouldn't remove CSE until every
> > *profitable* transformation it makes is subsumed by something else".
> >
> > And, as I understand it, the cl
for a more concrete form than a basic block
> trace. Steven Bosscher pointed me in the direction of the region
> formation project by Daniel Berlin and Kenneth Zadeck, which sounds
> like a good basis for a superblock representation. What is the status
> of this project? Has any docum
On Tue, 2005-04-19 at 18:29 +0200, Jerome Guitton wrote:
> A Dwarf interpretation question:
>
> We have a problem to make GCC-compiled code interact with the HP
> native debugger, and it looks like it is caused by the way the
> attribute DW_AT_frame_base is interpreted. Apparently, when a frame
>
On Tue, 2005-04-19 at 15:36 +0530, Virender Kashyap wrote:
> Hi,
> I am working on interprocedural data flow analysis(IPDFA) and need some
> feedback on scalability issues in IPDFA. Firstly since one file is
> compiled at a time, we can do IPDFA only within a file.
For starters, we're worki
On Wed, 2005-04-27 at 15:13 -0700, Stan Shebs wrote:
> Steven Bosscher wrote:
>
> >On Wednesday 27 April 2005 17:45, Matt Thomas wrote:
> >
> >>>The features under discussion are new, they didn't exist before.
> >>>
> >>And because they never existed before, their cost for older platforms
> >>may
On Wed, 2005-04-27 at 16:40 -0700, Zack Weinberg wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2005-04-27 at 15:13 -0700, Stan Shebs wrote:
> >> Steven Bosscher wrote:
> >> >If someone had cared about them, it would have been noticed
On Wed, 2005-04-27 at 17:10 -0700, Zack Weinberg wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
> > On Wed, 2005-04-27 at 16:40 -0700, Zack Weinberg wrote:
> >> I have seen such complaints. Not about bootstrap times, no, that only
> >> affects people who c
On Thu, 2005-04-28 at 11:58 -0400, Peter Barada wrote:
> This is for a m68k-linux build (with coldfire-linux config for glibc),
> and its only the C compiler, so adding C++ will obvioulsy make it take
> longer.
>
> >A 2.4 Ghz P4 isn't what I would consider an obsolete machine and it took
> >90 m
On Wed, 2005-04-27 at 16:40 -0700, Zack Weinberg wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2005-04-27 at 15:13 -0700, Stan Shebs wrote:
> >> Steven Bosscher wrote:
> >> >If someone had cared about them, it would have been noticed
On Thu, 2005-04-28 at 19:31 +0200, Steven Bosscher wrote:
> On Apr 28, 2005 06:55 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Apr 28, 2005 at 06:45:10PM +0200, Steven Bosscher wrote:
> > > Hi,
> > >
> > > PR21173 and its duplicates are a class of wrong-code and ICE bugs
> > > in GCC 4.0
On Thu, 2005-04-28 at 10:23 -0700, Devang Patel wrote:
> On Apr 28, 2005, at 9:10 AM, Daniel Berlin wrote:
>
> > 1. make bootstrap on a 2.4ghz p4 takes 90 minutes for me as of
> > yesterday.
> > 2. Building XLC with (C,C++,Fortran) and a single backend takes
> >
On Thu, 2005-04-28 at 11:08 -0700, Devang Patel wrote:
> On Apr 28, 2005, at 10:54 AM, Daniel Berlin wrote:
>
> > On Thu, 2005-04-28 at 10:23 -0700, Devang Patel wrote:
> >> On Apr 28, 2005, at 9:10 AM, Daniel Berlin wrote:
> >>
> >>> 1. make bootstrap on
On Thu, 2005-04-28 at 11:03 -0700, Matt Thomas wrote:
> Someone complained I was unfair in my gcc bootstrap times since
> some builds included libjava/gfortran and some did not.
>
> So in the past day, I've done bootstrap with just c,c++,objc on
> both 3.4 and gcc4.1. I've put the results in a we
On Thu, 28 Apr 2005, Daniel Berlin wrote:
On Thu, 2005-04-28 at 11:03 -0700, Matt Thomas wrote:
Someone complained I was unfair in my gcc bootstrap times since
some builds included libjava/gfortran and some did not.
So in the past day, I've done bootstrap with just c,c++,objc on
both 3.
> Do you know why GCC4 is deprecated on sparc-openbsd ? It's simply
> because no-one so far has been able to dedicate the CPU time to track
> down the few bugs that prevented us from switching to gcc 3.x from 2.95.
>
> That's right, I said CPU-time. It takes too long to bootstrap the compiler,
>
On Mon, 2005-05-02 at 19:14 +0200, Biagio Lucini wrote:
> While discussing whether including gcc 4.0 in a Linux distro, someone pointed
> out this:
>
> http://lists.kde.org/?l=kde-devel&m=111471706310369&w=2
>
> I have checked the gcc bugzilla and either I am wrong or there is nothing
> relevan
On Thu, 2005-05-05 at 11:01 +0200, Steven Bosscher wrote:
> On Thursday 05 May 2005 07:40, Mark Mitchell wrote:
> > # CFG Transparent Inlining, Profile-Guided Inlining (1.3)
>
> This one was submitted on April 29, but nobody has reviewed it.
>
> > # Compilation Level Analysis of Types and Static
On Wed, 2005-05-04 at 22:40 -0700, Mark Mitchell wrote:
> GCC 4.1 is going rather well thus far.
>
> Technically, Stage 1 ended on April 25th, though I failed to announce
> that. There are a few stage 1 tasks that have not made it in yet,
> according to the Wiki:
> # Structure Aliasing Part II
On Thu, 2005-05-05 at 13:11 -0700, Mark Mitchell wrote:
> Steven Bosscher wrote:
> > On Thursday 05 May 2005 07:40, Mark Mitchell wrote:
> >
> >># CFG Transparent Inlining, Profile-Guided Inlining (1.3)
> >
> >
> > This one was submitted on April 29, but nobody has reviewed it.
> >
> >
> >># C
On Wed, 2005-05-04 at 20:41 -0400, Diego Novillo wrote:
> On Wed, May 04, 2005 at 05:08:23PM -0700, James E Wilson wrote:
>
> > We can perhaps handle this well in the tree-aliasing code (if
> > it handled restrict at all), but it would be difficult to
> > handle this well in the RTL aliasing code.
On Sun, 2005-05-08 at 14:24 -0700, Richard Henderson wrote:
> On Sun, May 08, 2005 at 10:26:19PM +0200, Steven Bosscher wrote:
> > Oops. Not a modified tree, non-standard command line options:
> > -O -fgcse --param max-cse-path-length=1
>
> Ah, I see. Well, I think this is a misfeature of gcse i
On Mon, 2005-05-09 at 03:03 +0100, Paul Brook wrote:
> On Monday 09 May 2005 02:26, Matt Kraai wrote:
> > Howdy,
> >
> > The rules for c-objc-common.o, loop-unroll.o, and tree-inline.o
> > include $(VARRAY_H), which is never defined, in their dependency
> > lists. The rest of the targets that depe
On Tue, 2005-05-10 at 10:14 +0100, Dave Korn wrote:
> Original Message
> >From: Zack Weinberg
> >Sent: 09 May 2005 19:38
>
> > Bernard Leak writes:
>
> >> Can something be done to make the problem less obstructive?
> >> It's not obvious that the script should try to be too clever and
> >>
Our proposed approach is to -- by default -- assume that "g" may access all
of "b". However, in the event that the corresponding parameter to "g" has an
attribute (name TBD, possibly the same as the one that appears in Danny's
recent patch), then we may assume that "g" (and its callees) do not
The attribute might well be unnecessary, and once it's in it's in forever.
And I suspect supporting
different semantics for different calls will create problems down the line,
somehow or other
(although I confess I don't think of any offhand).
Attributes and flags have more or less the same effec
On Thu, 2005-05-12 at 10:01 -0600, Zan Lynx wrote:
> I'm not subscribed to the list (please CC replies to me) and this isn't
> a real bug report, just a sort of quick check to see if its a known
> problem.
>
> When I compiled openssl-0.9.7g using -O3 and -ftree-loop-linear as
> CFLAGS, openssl fai
On Thu, 2005-05-12 at 18:45 +0200, Sebastian Pop wrote:
> Daniel Berlin wrote:
> > On Thu, 2005-05-12 at 10:01 -0600, Zan Lynx wrote:
> > > I'm not subscribed to the list (please CC replies to me) and this isn't
> > > a real bug report, just a sort
On Thu, 2005-05-12 at 18:20 -0600, Jeffrey A Law wrote:
> On Thu, 2005-05-12 at 15:37 -0700, Richard Henderson wrote:
> > On Thu, May 12, 2005 at 01:14:15PM -0400, Diego Novillo wrote:
> > > Am I missing something here?
> >
> > Probably not.
> Isn't operand_equal_p used in situations where we're e
On Fri, 2005-05-13 at 14:31 -0400, Andrew MacLeod wrote:
> Do we currently have an RTL infix printing mechanism hidden away
> somewhere? I seem to vaguely recall new-ra might have had something
> once upon a time... I also suspect others have fooled with it over the
> years.
Yes, new-ra has a
On Fri, 2005-05-13 at 14:49 -0500, Paul Albrecht wrote:
> Eric writes:
>
> >
> > -Wl,-Map=mapfile.map,--cref
> >
>
> I'm not looking for a cross-reference from a symbol to its memory location
> in linked file, rather a cross-reference from a symbol definition in a
> program source file to its lin
On Mon, 2005-05-16 at 16:53 +0100, Richard Earnshaw wrote:
> On Mon, 2005-05-16 at 16:17, Steven Bosscher wrote:
> > On Monday 16 May 2005 16:53, Scott Robert Ladd wrote:
> > > The problem is, a bloated GCC has no consequences for the majority of
> > > GCC developers -- their employers have other (
While my weekdays are booked with real stuff (structure aliasing,
array_ref/mem_ref, dependence, blah blah blah), the next couple weekends
i have plans to try to do some serious tree seperation.
My current evil plan is to try to seperate the really distinct _DECL
nodes into distinct DECL trees, sh
On Tue, 2005-05-17 at 10:46 -0700, Richard Henderson wrote:
> On Tue, May 17, 2005 at 01:08:29PM -0400, Daniel Berlin wrote:
> > This is probably going to hurt, and will require things like using
> > FIELD_DECL_ macros for FIELD_DECL's, TYPE_DECL_ macros for
> > TYPE_DEC
On Tue, 2005-05-17 at 14:59 -0400, Richard Kenner wrote:
> The main case i've hit so far is DECL_CONTEXT, which is also
> DECL_FIELD_CONTEXT
>
> Are there any other cases? Offhand, I can't think of another DECL field
> that's shared by only a subset of DECLs.
An example is DECL_INITIAL vs
On Wed, 2005-05-18 at 12:42 +, Joseph S. Myers wrote:
> On Wed, 18 May 2005, Richard Guenther wrote:
>
> (b) You'll probably need to change the code that autodetects const
> functions to do the same, and if there's any code autodetecting noreturn
> functions then likewise. Also any code ge
On Thu, 2005-05-19 at 16:42 +0200, Davide Pozza wrote:
> I'd need some help to develop a function, for a new gcc pass,
> located after the value range propagation pass.
>
> I'm working on the last release of gcc 4.1.
>
> I'd like to have a function that receiving a stmt (that is
> a CALL_EXPR) an
On Fri, 2005-05-20 at 11:13 +0200, Tomasz Chmielewski wrote:
> > Like now we have compiler options like "-mmmx -msse -msse2 -msse3
> > -m3dnow" - would it be possible to optimize the code of the binary to use
> > the GPU with "-with-nvidia-gpu" or "-with-ati-gpu"?
> >
> > I would like to hear s
101 - 200 of 1072 matches
Mail list logo
