On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>>
>> On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Doug,
>>>
>>> Yesterday, we spoke briefly about the need to efficiently determine
>>> the DECL's required by
On Thu, Jun 12, 2008 at 4:39 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>> I have no idea how to make sure, in whopr, that function x sees foobar if
>> you are going to cherry pick the globals also.
>
> I'm not sure I see the problem t
I haven't touched it in well over a year.
I'll look what's up.
On Mon, Jun 16, 2008 at 12:40 PM, Rainer Orth
<[EMAIL PROTECTED]> wrote:
> Daniel,
>
> I've submitted a bug report via gccbug about an hour ago, but so far have
> neither received a confirmation of the report nor a bounce. Is the gcc
On Tue, Jun 17, 2008 at 9:58 AM, David Kastrup <[EMAIL PROTECTED]> wrote:
>
> Hi, I reported a problem I have with abort to the glibc bug tracker at
> http://sourceware.org/bugzilla/show_bug.cgi?id=6522> which might
> provide some reading material.
>
> Anyway, it has been pointed out to me that the
On Thu, Jun 19, 2008 at 1:26 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Jens-Michael Hoffmann <[EMAIL PROTECTED]> writes:
>
>>> No. I've flipped the branch to start compiling the source files in
>>> gcc with C++. Unfortunately a number of issues will need to be
>>> addressed before all the
Maybe at some point then we should just stop using gengtype and just
hand-write the walkers once.
One of the reasons gengtype exists is because you can't easily have an
abstract interface with member functions that you can force people to
implement in C.
In C++, we can.
This is of course, a larg
On Wed, Jul 2, 2008 at 2:30 PM, Hendrik Boom <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Jun 2008 20:11:56 -0700, Ian Lance Taylor wrote:
>
>> Ivan Levashew <[EMAIL PROTECTED]> writes:
>>
Your comment makes little sense in context. Nobody could claim that
the existing gengtype code is simple
gcc.gnu.org/git/gcc.git tracks all branches.
Just remember to tell it to fetch all remote refs (since git-svn
branches are done as remotes)
On Sun, Jul 6, 2008 at 11:51 AM, Nix <[EMAIL PROTECTED]> wrote:
> [David, my fallible memory says that you operate this incredibly useful
> service: if not,
It's only "official" in that it lives on gcc.gnu.org.
It is maintained only by one person, not by the gcc project.
On Sun, Jul 6, 2008 at 2:31 PM, Nix <[EMAIL PROTECTED]> wrote:
> On 6 Jul 2008, Daniel Berlin spake thusly:
>
>> gcc.gnu.org/git/gcc.git tracks all
This is likely to have been my patch.
I'm minimizing the check_construct_destroy failure right now.
If someone could give me some idea of what is causing the execution
failures while i do that, i may be able to fix them faster :)
On Wed, Jul 9, 2008 at 10:31 AM, Paolo Carlini <[EMAIL PROTECTED]> w
On Fri, Jul 11, 2008 at 1:17 PM, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Hi,
>>
>> This is likely to have been my patch.
>> I'm minimizing the check_construct_destroy failure right now.
>> If someone could give me some idea of what is causing the execution
>> failures while i do that, i may be a
Okay, i isolated the problem (we are folding based on the wrong type
for constants, so we have a case where 1 << 63 becomes 0 instead of a
very large value).
Working on a patch now.
On Fri, Jul 11, 2008 at 1:56 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 11, 2008 at
On Sun, Jul 13, 2008 at 6:29 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Nils Pipenbrinck <[EMAIL PROTECTED]> writes:
>
>> Since the codebase is huge I have the feeling that I have overlooked
>> something. Does some kind of infrastructure to detect patterns within
>> a SSA tree already exists somew
On Mon, Jul 14, 2008 at 5:22 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> We are failing to build libjava on PPC64 because of this:
>
> /home/dnovillo/perf/sbox/tuples/local.ppc64/bld/./gcc/xgcc -shared
> -libgcc -B/home/dnovillo/perf/sbox/tuples/local.ppc64/bld/./gcc
> -nostdinc++ -L/home/d
> no
Patches welcome :)
On Tue, Jul 22, 2008 at 3:55 AM, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> It's pretty obvious the moment you read the content of any of the posts
>> that it can't be cvs and has to be svn, even more so if you follow one of
>> the
The easiest way to not delete trunk is to not delete trunk.
On Thu, Jul 24, 2008 at 10:06 AM, Peter Bergner <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-07-24 at 18:48 +0200, Andreas Schwab wrote:
>> Definitely something fishy around that time. svn log says:
>>
>> --
On Thu, Jul 24, 2008 at 2:13 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
> On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
>>>
>>> I thought the whole idea of the LTO project was to keep as much language
>>> specific type information as late as possible. If you start stripping out
>>> useful
On Sat, Jul 26, 2008 at 1:55 PM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> On Sat, Jul 26, 2008 at 7:48 PM, David Edelsohn <[EMAIL PROTECTED]> wrote:
>> Kenny> 2) Generate the debugging for the types early, and then add an
>> Kenny> interface that would parse and regenerate the debugging info w
On Sun, Jul 27, 2008 at 1:18 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> David Edelsohn wrote:
>
>>I do not expect LTO (or WHOPR) to work on AIX -- at least not
>> without a lot of work on wrappers around the AIX linker. However, I do
>> not understand why enhancing GCC to support LTO -
On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>
>>> I agree that, at least in principle, it should be possible to emit the
>>> debug
>>> info (whether the format is DWARF, Stabs, etc.) once.
>>
>>
On Sun, Jul 27, 2008 at 7:41 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Daniel Berlin wrote:
>>
>>>> I agree that, at least in principle, it should be possible to emit the
>
On Sun, Jul 27, 2008 at 7:48 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>> you may of course be right and this is what we will end up doing, but the
> implications for whopr are not good. The parser is going to have to work
> in lockstep with the t
On Sun, Jul 27, 2008 at 7:50 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>
>> Then again, I also don't see what the big deal about adding a debug
>> info parser is.
>
> OK, yes, we may need to read debug info back in.
>
> I don
On Tue, Jul 29, 2008 at 11:20 AM, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> For that matter, "print sizeof(X)" should print the same value when
> debugging optimized code as when debugging unoptimized code, even if the
> compiler has optimized X away to an empty structure!
On Tue, Jul 29, 2008 at 8:45 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>
>> If you built an AST that included sizeof before doing template
>> instantiation (which may not even be possible), you could at least
>> determine whether sizeof was u
On Mon, Aug 4, 2008 at 6:19 AM, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Aug 2008, Ralf Wildenhues wrote:
>
>> * Joseph S. Myers wrote on Sun, Aug 03, 2008 at 10:00:38PM CEST:
>> >
>> > (But the configure code also
>> > shouldn't allow configuring with a GPLv2 version of polylib.)
>>
Failure:
../../../libgfortran/intrinsics/cshift0.c: In function 'cshift0':
../../../libgfortran/intrinsics/cshift0.c:124: warning: passing
argument 1 of 'cshift0_i16' from incompatible pointer type
../../../libgfortran/intrinsics/cshift0.c:236: error: 'GFC_INTGER_16'
undeclared (first use in this
1. You can't assume VUSE's are must-aliases. The fact that there is a
vuse for something does not imply it is must-used, it implies it is
may-used.
We do not differentiate may-use from must-use in our alias system. You
can do some trivial must-use analysis if you like (by computing
cardinality of
On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/8/14 Daniel Berlin <[EMAIL PROTECTED]>:
>> 1. You can't assume VUSE's are must-aliases. The fact that there is a
>> vuse for something does not imply it is must-used, it i
On Fri, Aug 15, 2008 at 10:58 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-Ibáñez
> <[EMAIL PROTECTED]> wrote:
>> 2008/8/14 Daniel Berlin <[EMAIL PROTECTED]>:
>>> 1. You can't assume VUSE's are mus
On Fri, Aug 15, 2008 at 11:31 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/8/15 Daniel Berlin <[EMAIL PROTECTED]>:
>> On Fri, Aug 15, 2008 at 10:58 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>>> On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-
It's listed on the wiki that explains how to maintain branches :)
On Sun, Aug 17, 2008 at 2:32 PM, John Freeman <[EMAIL PROTECTED]> wrote:
> Christopher Faylor wrote:
>>
>> On Sat, Aug 16, 2008 at 02:35:08PM +0200, Manuel L?pez-Ib??ez wrote:
>>
>>>
>>> Dear GCC devs,
>>>
>>> Please do *not* use t
I'll commit your patch.
On Fri, Sep 5, 2008 at 12:42 PM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/9/5 Christopher Faylor <[EMAIL PROTECTED]>:
>> On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
>>> Daniel Berlin wrote:
>>>
&g
Feel free to edit the hook scripts to do this.
On Sat, Sep 6, 2008 at 1:26 PM, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Sat, 6 Sep 2008, Manuel López-Ibáñez wrote:
>
>> Well, that is a property change and it is surprising that the log
>> shows the diff of the change. Normally logs only sho
Honestly?
You should use whatever gets a response.
If you are at the point you have to ping a patch, it obviously has
fallen through the cracks, and you should do whatever is necessary to
make sure it gets attention.
To that end, I would just use new threads, as they make it clear it is
not part o
On Mon, Sep 22, 2008 at 8:48 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
>> char and signed char (if char is signed) are the same types for the
>> middle-end (but not for the Frontend).
>
> Is that desirable? Type-based alias analysis should be able to take
> advantage
On Mon, Sep 29, 2008 at 10:37 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> You would not want a lawyer designing a compiler, so why...
>
Oh.
I guess i'll just hang up my hat then ...
On 5/3/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 03 May 2007 16:59, Andrew Pinski wrote:
> On 5/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>>> dberlin has been mailed, but no reaction so far.
>>>
>> I was off fixing my Nintendo Wii, so i wasn
At the request of a few developers, I set up a mercurial
(http://www.selenic.com/mercurial/) repository that mirrors our SVN
one.
It is updated automatically from SVN every 30 minutes.
Note *only GCC developers have access right now*. I will make it
available by http anonymously soon.
The url
And today we learn why I think version control systems that think
"repacking" is something the user should be doing are worthless beasts
:)
It generally just means you didn't think through your storage
subsystem enough, but in git's case it's probably that the project it
was originally developed f
On 5/8/07, Ollie Wild <[EMAIL PROTECTED]> wrote:
> git-svnimport will not pack incrementally as it runs, so it might get
> pretty large. git-svn offers and incremental repack every x commits
> (I chose 1000) and that did wonders for the import time for me.
> Otherwise it will create a huge numbe
On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Every time I think we're almost there with this release, I seem to
manage to get stuck. :-( However, we're very close: the only PRs that
I'm waiting for are:
PR 31797: An infinite loop in the compiler while building RTEMS.
Daniel, I see you'v
On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Every time I think we're almost there with this release, I seem to
>> manage to get stuck. :-( However, we're very close: the
On 5/7/07, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
Hi Dan. Hi folks.
People (ok, so it was Dan) had asked if there was anything they could do to
help the tuples effort.
The pretty print routines could definitely use a lot of cases
(dump_gimple_stmt), and the work is very self contained.
So
On 5/21/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
I've received some feedback suggesting that some contributors may not
always be aware of what open issues are available to work on, and,
perhaps more importantly, what regressions they may have caused.
Is there a volunteer who would like to he
On 5/22/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> CCing the person who caused the regression is more appropriate. Assigning
> bugs to them detracts others from fixing the bug.
We already do that, and in lots of cases it doesn't work. CCing is not
coercive enough, you only receive
On 5/22/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor wrote:
[Danny, please see below for a request for your help.]
> It's a reasonable idea, but overall it would have a negative effect.
> People tend to ignore PRs that are assigned to somebody else; they
> assume that person is
Hi guys and gals,
A mercurial mirror of our SVN repository, which is updated every 30
minutes, is available to pull/clone from
http://gcc.gnu.org/hg/gcc/trunk
Any GCC folks who want to clone and put branches on the server, let me
know and i'll clone a repo in /hg/gcc for you that you can push to
Oh, some more details for those who want them:
The repo contains the complete history of gcc trunk (125000 svn revisions).
It takes roughly 350 meg of disk space (450 on mac due to inode size).
On 5/27/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
Hi guys and gals,
A mercurial mirror
On 5/28/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
On Wed, May 23, 2007 at 02:06:21PM -0400, Daniel Berlin wrote:
> I have to look into bugzilla 3.0 migration first though. Bugzilla 3.0
> introduces a custom fields mechanism, and i'd rather at least store
>
On 5/28/07, Rafael Espindola <[EMAIL PROTECTED]> wrote:
On 5/27/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> Oh, some more details for those who want them:
>
> The repo contains the complete history of gcc trunk (125000 svn revisions).
>
> It takes roughly 350 meg of
On 5/29/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Mon, May 28, 2007 at 07:29:33AM -0400, Daniel Berlin wrote:
> On 5/28/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> >On Wed, May 23, 2007 at 02:06:21PM -0400, Daniel Berlin wrote:
> >
.
>
> You ca
On 5/31/07, Seema S. Ravandale <[EMAIL PROTECTED]> wrote:
Hi...
This is Seema here. I am working on GCC in IITB as research fellow.
Actually i am trying to find out scope information of a variable.
But i
didnt find any information within "decl" data structure of a variable.
It's there, it's
On 5/31/07, Seema S. Ravandale <[EMAIL PROTECTED]> wrote:
> On 5/31/07, Seema S. Ravandale <[EMAIL PROTECTED]> wrote:
>> Hi...
>> This is Seema here. I am working on GCC in IITB as research fellow.
>>
>> Actually i am trying to find out scope information of a variable.
>
>> But i
>> didnt find an
On 5/31/07, Seema S. Ravandale <[EMAIL PROTECTED]> wrote:
Hello sir,
Thank you for help. you have already cleared my confusion.
But I am working on inter-procedural data flow analysis. And i am trying
to implement IPDFA on gimple-CFG IR.
If i were you, I would do it on the gimple-SSA IR, sinc
On 6/3/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
Hello,
I will greatly appreciate any suggestions regarding the following
problem I have with the ccp propagator. I am testing the new store
ccp patch which propagates constants by walking the virtual use-def
chain (http://gcc.gnu.org/ml/gcc-pa
On 6/4/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
> > I will greatly appreciate any suggestions regarding the following
> > problem I have with the ccp propagator. I am testing the new store
> > ccp patch which propagates constants by walking the virtual use-def
> > chain (http://gcc.gnu.org/ml
On 6/5/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
> I can modify it to catch it pretty easily, just walk back a few vuses
> if the current set of vuses is defined by something that does not
> actually touch our offset.
This sounds like what I am trying to do in ccp...
> >
> > I am not sure I
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01133.html,
it might be a good idea to try moving cfg to alloc pools. The patch
below does that for basic blocks (each function has a separate pool
from that its basic blocks
On 6/6/07, Ben Elliston <[EMAIL PROTECTED]> wrote:
On Wed, 2007-06-06 at 08:29 -0400, Diego Novillo wrote:
> You should not have conflicts in libjava. You may have botched a merger
> earlier. I never ran into this with the branches I've maintained. Try
> copying libjava out of trunk again.
O
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> > Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> >
> > > The problem is, that it does not give any speedups (it is almost
> > > completely compile-time neutral for compilation of preprocess
On 6/7/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> >
> > > Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> > >
> > > > The problem is, that it does not give any speedups (it is almost
On 6/12/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
> The engine only knew how to propagate cases that always make the same
> set of vdef/vuses, so it was safe to only tell it to use the first
> vdef.
>
> /* Note that for propagation purposes, we are only interested in
> visiting stat
On 6/15/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> Please, just look at those charts
>
> https://vmakarov.108.redhat.com/nonav/spec/comparison.html
>
> The compilation speed decrease without a performance improving (at least
> for the default case) is really scary.
Right, I also found those
On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote:
get_alias_set and internally record_component_aliases makes
assumptions about the IR that are only valid in RTL.
What is this assumption, exactly?
On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote:
Daniel Berlin writes:
> On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote:
> > get_alias_set and internally record_component_aliases makes
> > assumptions about the IR that are only valid in RTL.
>
> What is th
On 6/16/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> H. J. Lu wrote:
>
> >On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote:
> Vectorizer is a big a project and may be we will see more improvements
> in future. They promissed implement SLP two years ago and now I see it
> happ
On 6/16/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> HMm, i'd just record it for all of them, since the [fields] are accessible
> through a pointer to the structure.
They are indeed accessible this way...
> Just because you can't directly take the address of a bitfield doesn't
> mean you can'
On 6/16/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> If that was really true, we would get this right.
Well, this is true, I really don't understand why you keep denying that.
Because it wouldn't be pruning it if the alias sets conflicted!
Just grep the RTL expanders for MEM_KEEP_ALIAS_SE
On 6/16/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> You guys have come up with a very weird idea of what
> non-addressability means. These fields are all addressable, they
> are just not directly addressable.
Terminology is always tricky here. "addressable" in this context means
that no po
On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > So if I have
> > struct foo {int x; float y; } bar;
> > int *pi;
> > float *pf;
> >
> > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > affect bar.x.
>
> But if you add
>
> struct foo *foop
On 6/17/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
On Sun, 2007-06-17 at 15:31 -0400, Daniel Berlin wrote:
> On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > &
On 6/17/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > >
> > > But if you add
> > >
> > > struct foo *foop = &bar.
> > >
> > > foop->x = 5.
> > >
> > > It can, even though we *claim* X is nonaddressable.
> >
> > Which can
On 6/18/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> I'm completely unsurprised this is broken at the tree level given how
> it is implemented
Nice tautology. :-) You have resisted implementing anything at the tree level
to fix the problem and now you're complaining there is a problem...
Pa
On 6/18/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 17/06/2007 18:18:19:
...
>
> The whole purpose of SLP was to enable straight line code
> vectorization outside of loops.
I wouldn't say that's the whole p
On 6/18/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> If it was designed properly in the first place, there simply would *be
> no problem at the tree level*, because nothing would have broken.
That's certainly a point of view. The other is that the RTL implementation
predates the Tree one, wor
On 6/18/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 6/18/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > If it was designed properly in the first place, there simply would *be
> > no problem at the tree level*, because nothing would have broken.
>
> That
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Uh, except as we've discovered, the RTL uses alias set 0, so whatever
> alias set you choose for these doesn't matter anyway to the RTL level.
Only in some cases. That was a kludge put in to fix some obscure bug and
left there. I hope we c
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Again, the tree level relies on the documented (in the comments of
> alias.c) fact that given a structure, the fields contained in a
> structure will have alias sets that are strict subsets of the parent.
That is ONLY true for fields that d
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> His first patch, which simply makes #1 true, would cause missed optimization.
It doesn't "cause missed optimizations": it completely removes all the
functionality of DECL_NONADDRESSABLE_P!
Hence the reason for the second suggestion.
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > But throws away the entire DECL_NONADDRESSABLE_P mechanism!
>
> No, an int* will still not conflict with int:31
> a short * will still not conflict with short:31
Using what mechanism? That's what DECL_NONADDRESSABLE_P does!
Please read
On 6/18/07, Sebastian Pop <[EMAIL PROTECTED]> wrote:
On 6/18/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> > I can hand you more than the testcases i've given so far. There is
> > tons of code out there that would benefit from straight line
>
> Interesting. I wasn't aware of this potential. Ple
Hi guys, I have merged all patches touching lto/ into the new lto branch
I'm almost 100% positive the result will not compile. There are no
interesting conflicts to report (most were just formatting changes).
I have not merged ChangeLog.lto onto the new branch, since it looked
like it only conta
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> How does this get a different result for trees than RTL?
>
> As i've explained, we rely on the proper of the TBAA forest that given
>
> struct foo (set 1)
> / \
> int :31 (set 2) short :31 (set 3)
>
> se
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> It gives you the alias set of the parent, which, for the reason that
> OTHER THINGS USE THE ALIAS SET SPLAY TREES, gives the wrong answer.
Can you give a few sentence explanation of what "alias set splay trees"
are and why they aren't using
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> They are the alias set mechanism, which you don't seem to understand.
> They always have been.
I certainly understand the alias set mechanism. It sounded like you were
talking about something else since if the only thing we're using is ali
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Type of the expression passed to get_alias_set. And without the
> component_uses_parent_alias_set loop.
So you mean the type of the *field*? That can't work. That type can't
be used for *anything*!
Otherwise, if you have
struct
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > you have the fields A and C conflicting, which is wrong.
>
> Well, that is where structure-field aliasing comes in. The two cannot
> even alias for addressable fields:
At tree level I'll take your word for it, but what about RTL level?
I
On 6/19/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> Hi guys, I have merged all patches touching lto/ into the new lto branch
Thank you! Did you also pull over Kenny's LTO-writer code?
Yup.
I have the complete list of revisions merged with their log en
Apparently there are some fortran regressions caused by my patch.
The last time I modified the patch (which was before the freeze), I
did a test of C, C++, Fortran, objc.
After the freeze ended, I did an svn update in that tree, bootstrapped
and regtested c/c++, and committed it.
Other than the
I'm curious if it was the pre/fre changes. can you try -fno-tree-pre
and -fno-tree-fre and see if it slows down again?
On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
Hello!
It is worth noticing that latest changes to gcc brought more than 75%
speed-up on Polyhedron aermod.f90 benchmark [1].
On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> I'm curious if it was the pre/fre changes. can you try -fno-tree-pre
> and -fno-tree-fre and see if it slows down again?
Adding -fno-tree-pre slows aermod back to 33.942s. Nice optimization. ;)
Thanks.
(
On 7/4/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> Ok. So either we want to disallow invariant addresses as gimple value
> altogether or
> do more elaborate checks, to rule out such bogus cases. At least the
> transformation
> PRE is doing doesn't make sense -- and I know other optimization
On 7/4/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
On 7/4/07 6:24 PM, Eric Botcazou wrote:
>> The problem is that in GIMPLE we only allow TREE_INVARIANT as a gimple
>> value for ADDR_EXPRs. We still require a TREE_CONSTANT as an array
>> index. So, ARRAY[TREE_INVARIANT] is not valid GIMPLE.
>
On 7/4/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Also, we need to update the GIMPLE grammar so that ARRAY_REF and
> ARRAY_RANGE_REF take the appropriate values:
A minor comment is that operand 2 of COMPONENT_REF needs the same handling.
Can you please, again, explain why we even have th
On 7/5/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> Note that TREE_INVARIANT is not going to be useful in an IPA world
> anyway for these users, if it really means that different calls to the
> function could produce different results.
We could test TREE_CONSTANT instead and this would be enou
On 7/5/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> We never insert expressions for FRE, and the replacement we do will
> only replace the entire RHS with an SSA_NAME or a constant.
The problem is precisely that the expression is deemed a constant:
/* Setting value numbers to consta
On 7/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On Thu, 5 Jul 2007, Roman Zippel wrote:
> Hi,
>
> On Thu, 5 Jul 2007, Richard Guenther wrote:
>
> > If there is anything to fix, then all those variants should produce
> > the same code, not just foo3 and foo4. So for these cases we should
On 7/5/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
On Thu, 5 Jul 2007, I wrote:
> Exactly and that's why I think this transformation is done far too early.
> It doesn't make sense that these two examples produce different code:
>
> int foo1(int x)
> {
> return (x * 4) + 4;
> }
> int f
On 7/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>2007/4/10, Diego Novillo <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED])
>:
>Following up on the recent discussion about GIMPLE tuples
>(_http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html_
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html) ),
901 - 1000 of 1072 matches
Mail list logo
