On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld
writes:
>This page http://deputy.cs.berkeley.edu/ has a link to this document
http://hal.cs.berkeley.edu/cil/
>which describes a means to obtain three-address code
On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In a message dated 7/9/2007 2:37:03 P.M. Pacific Daylight Time,
[EMAIL PROTECTED] writes:
>On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> >In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld
>> writes:
On 7/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Summary
---
The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.
As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all
changes. If you have outstanding changes that have been approved, but
not committed, make t
On 7/12/07, John David Anglin <[EMAIL PROTECTED]> wrote:
> The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.
PR 32199 is a regression in behavior from 4.2.0. Although a libjava
build regression is probably not sufficient justification to block
the scheduled release, the change tha
On 7/12/07, Michael Eager <[EMAIL PROTECTED]> wrote:
Eric Botcazou wrote:
>> How does this work for 32-bit hosts and 64-bit targets?
>
> Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT.
Meaning that I can't build gcc-ppc64 on an IA32 host?
No, he said they require a 64 bit HOST_WIDE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32746
is really caused by a combination of two things
First is_gimple_min_invariant in try_to_simplify where it chooses
DECL_INITIAL should be valid_gimple_expression_p instead.
However, even if i fix this, the testcase still fails because
valid_gimpl
On 7/14/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> First is_gimple_min_invariant in try_to_simplify where it chooses
> DECL_INITIAL should be valid_gimple_expression_p instead.
That's a known problem, see tree-ssa-ccp.c:
I had forgotten about this because i hadn't done IPA in a while. At
On 7/18/07, Andreas Krebbel <[EMAIL PROTECTED]> wrote:
Hi,
GCC currently doesn't bootstrap on s390x. The problem is that
gengtype is miscompiled and I suspect the fre - sccvn changes to be
the culprit.
When sccvn performs the depth-first search for uses it might reach
global variable definitio
On 7/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 7/18/07, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 17, 2007 at 09:53:30AM -, Wolfram Gloger wrote:
> > Surely you agree that in my second example, "*p = 0" _cannot_ be moved
> > after the call to destroy_something_and
It used to be that the bitmap obstack known as "alias_bitmap_obstack"
was released and renewed every time we called compute_may_aliases.
This didn't really leak because the absolute last one was destroyed at
the end of compilation.
You changed it to be only released if gimple_aliases_computed_p (c
On 7/31/07, Tehila Meyzels <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'd like to bring up on the list a discussion that a bunch of people (most
> of those CC-ed above) started at the GCC Summit:
>
> Lately, there were few efforts, that are not necessarily related to each
> other, but are all relevant
On 8/1/07, Tehila Meyzels <[EMAIL PROTECTED]> wrote:
> "Daniel Berlin" <[EMAIL PROTECTED]> wrote on 31/07/2007 18:00:57:
>
> >
> > I agree with you for conditional stores/loads.
>
> Great!
>
> >
> > The unconditional store/load stuff, ho
On 8/1/07, Ayal Zaks <[EMAIL PROTECTED]> wrote:
> "Daniel Berlin" <[EMAIL PROTECTED]> wrote on 01/08/2007 18:27:35:
>
> > On 8/1/07, Tehila Meyzels <[EMAIL PROTECTED]> wrote:
> > > "Daniel Berlin" <[EMAIL PROTECTED]> wrote o
On 8/5/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
>There's something wrong with the bugzilla fields for host/build/target
> triplet:
>
> Build:
>
>
>
> Host:
>
>
>
> Eh, -2? By definition, it is at le
On 8/6/07, Alfred M. Szmidt <[EMAIL PROTECTED]> wrote:
>> Any chance of moving to launchpad.net?
>
>And launchpad.net forces everyone else to remember a new username
>and password.
>
> Launchpad is also non-free software.
>
Great!
We'll start the migration tomorrow then!
On 8/8/07, Cupertino Miranda <[EMAIL PROTECTED]> wrote:
> Hello everyone,
>
> I am currently trying to enable GCC to perform compilation without
> having to respect any compilation order, i.e. execute some pass to
> any function at any time (it is not only pass reordering).
>
> As what I have seen
On 08 Aug 2007 17:36:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Michael Matz <[EMAIL PROTECTED]> writes:
>
> > If you were to implement something like virtual functions into the middle
> > end, it should be expressed in a fairly low level way IMHO. E.g. a
> > virtual table simply bein
On 8/8/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Ollie Wild wrote:
> > On 8/8/07, Michael Matz <[EMAIL PROTECTED]> wrote:
>
> Ollie, thanks for patiently trying out different approaches.
>
> > I think the primary purpose of the middle end is to provide a
> > representation which captures the s
On 8/8/07, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On 8/8/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > I also haven't necessarily said what Ollie has proposed is a bad idea.
> > I have simply said the way he has come up with what he proposed is
> > not th
On 8/9/07, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On 8/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Daniel Berlin wrote:
> >
> > >> This is the source of my current woes, as this may involve virtual
> > >> function resolution, which
On 8/9/07, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote:
> > Also in Java it is possible to devirtualize calls in some situations
> > where only a bound on the type is known. For instance at a call site
> > we might know that all possible targets
On 9/1/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >> OK, great. Here's a draft patch for the trick; this works on the test
> >> case I had, and I'll be testing it now. If it passes testing, and I add
> >> testcases, does this look OK to you?
>
> Thanks for the spee
On 9/2/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > > That said, second, my understanding of restrict, from reading the c99
> > > standard, is that it is perfectly valid for restrict pointers to alias
> > > each other during *loads*.. IE you can guarantee any restricted
> > > pointer that is stor
On 9/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > On 9/2/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > > > > That said, second, my understanding of restrict, from reading the c99
> > &
On 9/4/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Summary
> ===
>
> The GCC 4.2.1 release was July 18, so our target for a 4.2.2 release is
> September 18th. I plan to build RC1 this Sunday, September 9. If all
> goes well, we'll have 4.2.2 out around the 18th; if not, we'll delay a
> bit
On 9/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 9/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > On 9/4/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > >
> > > We still have the nasty aliasing problems:
> > >
> > > PR
On 9/10/07, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> Mark> If the compiler treats:
> Mark> int *p = new int;
> Mark> any differently from:
> Mark> int &r = *new int;
> Mark> then we're missing an optimization opportunity.
>
> AFAIK we
># all tests fail with ICE in verify_curr_properties; -m32/-m64
>-O2 -fno-tree-salias
>-Os -fno-tree-salias
Known. This is normally the first place we build aliasing info.
Unless we have a compelling reason to have this flag, we should simply
remove the flag.
> # all tests fail with ICE in ver
On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > > On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > > > On 23 Sep 2007 09:54:29 -0700, Ian Lance Ta
On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > > On 23/09/2007, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > > > On 9/23/07, Manuel López-Ibáñez <[EMAIL PRO
On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 24/09/2007, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > On 9/23/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > >
> > > And *before* salias? Does it make a difference? It suits me b
On 9/24/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 9/24/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
>
> > That is exactly what I had in mind. If you invalidate a property then
> > the property is destroyed and whoever asks for it must invoke the
> > relevant function to enable it agai
On 10/6/07, Gary Funck <[EMAIL PROTECTED]> wrote:
> I'm also not certain why DECL_PRESERVE_P() was introduced
> when TREE_USED() seems to imply the same thing (that the
> variable/function is used and shouldn't be eliminated.
Because it doesn't mean that.
"/* Nonzero in a _DECL if the name is use
On 10/9/07, Pranav Bhandarkar <[EMAIL PROTECTED]> wrote:
> Hi,
> consider the following code,
>
> struct x { int a; int b; int c; int d; int e[120];};
> struct x *a, *b;
> void foo ( )
> {
> *a = *b;
> }
>
> Now for the stmt int the function foo a memcpy will be generated.
> However, this can b
On 11/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 11/3/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > > >> I believe that this is something new and is most likely fallout from
> > > >> diego's reworking of the tree to rtl converter.
> > > >>
> > > >> To fix this will requir
On 11/26/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Nov 2007, Paolo Bonzini wrote:
>
> > On the other hand, if it is meant for human usage the file list is already a
> > clue to spot "wrong" commits. Then, an equivalent but more versatile
> > feature
> > request would be to have
On 12/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > > How could a newcomer guess why the gcc_force_collect flag needs to be
> > > reset?
> >
> > That is supposed to be written in a comment. The change log entry
> > should describe _what_ is being changed, so that you can find out when a
> >
On 12/2/07, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
> Richard Kenner wrote:
> >>> How could a newcomer guess why the gcc_force_collect flag needs to be
> >>> reset?
> >> That is supposed to be written in a comment. The change log entry
> >> should describe _what_ is being changed, so that you can
On 12/2/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > I'd go even further, and say if the GNU coding standards say we
> > shouldn't be putting descriptions of why we are changing things in the
> > ChangeLog, than they should be changed and should be ignored on this
> > point until they do. Poin
On 12/2/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > Right, because surely one size fits all projects and possibilities,
>
> It was supposed to be the Coding Standards for The GNU Project.
Sorry, but again, this is not a good enough justification to me.
We do a lot of things different than "Th
On 12/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > If all the changelog entry says is something like
> >
> > (xyz): new function
> >
> > I don't see much point, since a diff can always easily tell
> > you *what* was changed.
>
> The point is that, by just looking at the ChangeLog, you can te
On 12/3/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > Sorry, but again, this is not a good enough justification to me.
> > We do a lot of things different than "The GNU Project".
> > So do plenty of parts of the "official GNU project".
> > They use different coding standards, bug tracking syste
On 12/5/07, NightStrike <[EMAIL PROTECTED]> wrote:
> On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > I already have two way sync with hg.
> > Maybe someday when git is more usable than hg to a normal developer,
> > or it at least is significantly smaller t
For the record:
[EMAIL PROTECTED]:/compilerstuff/gitgcc/gccrepo$ git --version
git version 1.5.3.7
(I downloaded it yesterday when i started the import)
On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> So I tried a full history conversion using git-svn of the gcc
> reposito
On 12/5/07, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On Dec 5, 2007 11:08 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > So I tried a full history conversion using git-svn of the gcc
> > repository (IE every trunk revision from 1-HEAD as of yesterday)
> > The git-
On 12/5/07, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
> >>>>> "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> Daniel> So I tried a full history conversion using git-svn of the gcc
> Daniel> repository (IE every trunk revision from 1
On Dec 5, 2007 6:15 PM, Ben Elliston <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-12-04 at 09:18 -0700, Tom Tromey wrote:
>
> > First, continuing to have good quality messages. Right now at the
> > very least you get a (semi-) accurate record of what was touched.
> > I've seen plenty of ChangeLog-les
So I tried a full history conversion using git-svn of the gcc
repository (IE every trunk revision from 1-HEAD as of yesterday)
The git-svn import was done using repacks every 1000 revisions.
After it finished, I used git-gc --aggressive --prune. Two hours
later, it finished.
The final size after t
Patch manager will be dying for a week or two while i change hosting.
of course, if nobody is still using it, i can just kill it permanently.
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 14:08:41 -0500
>
> > So I tried a full history conversion using git-svn of the gcc
> > repository (IE every trunk revision from 1-HEAD
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 21:41:19 -0500
>
> > It is true I gave up quickly, but this is mainly because i don't like
> > to fight with my tools.
> >
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 22:47:01 -0500
>
> > The size is clearly not just svn data, it's in the git pack itself.
>
> And other users have shown much sma
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 23:32:52 -0500
>
> > On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > > From: "Daniel Berlin"
> While you won't get the git svn metadata if you clone the infradead
> repo, it can be recreated on the fly by git svn if you want to start
> commiting directly to gcc svn.
>
I will give this a try :)
On 12/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Daniel Berlin wrote:
> >
> > Actually, it turns out that git-gc --aggressive does this dumb thing
> > to pack files sometimes regardless of whether you converted from an
> &g
On 12/6/07, Andrey Belevantsev <[EMAIL PROTECTED]> wrote:
> Vincent Lefevre wrote:
> > It's surprising that you don't mention svk, which is based on top
> > of Subversion[*]. Has anyone tried? Is there any problem with it?
> I must agree with Ismail's reply here. We have used svk for our
> interna
On 12/7/07, Alexander Monakov <[EMAIL PROTECTED]> wrote:
> Hi.
>
> Attached is the patch that allows to save dependence info obtained on tree
> level by data-reference analysis for usage on RTL level (for RTL memory
> disambiguation and dependence graph construction for modulo scheduling).
> It hel
On 12/7/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-12-07 at 14:14 -0800, Jakub Narebski wrote:
>
> > > >> Is SHA a significant portion of the compute during these repacks?
> > > >> I should run oprofile...
> > > > SHA1 is almost totally insignificant on x86. It hardly shows up. But
>
> Where did have you read this ? I missed that part.
>
> > When you object
> > that he's wasting your time, he'll start talking about freedom of speech.
> >
>
> Actually he never spoke like that (probably I missed that part too).
>
>
Read gcc mailing list archives, if you have a lot of time on
On 12/10/07, Alexander Monakov <[EMAIL PROTECTED]> wrote:
> Hi. Sorry for the previous empty reply.
>
> > also, i see
> > + /* We do not use operand_equal_p for ORIG_EXPRs because we need to
> > + distinguish memory references at different points of the loop
> > (which
> > + would have di
On 12/11/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> Total CPU time 196 CPU minutes vs 190 for gcc. Google's claims of
> being faster are not true.
Depends on your allocation patterns. For our apps, it certainly is :)
Of course, i don't know if we've updated the external allocator in a
while, i'l
On 12/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 5, 2007, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> > On 11/25/07 3:43 PM, Mark Mitchell wrote:
>
> >> My suggestion (not as a GCC SC member or GCC RM, but just as a fellow
> >> GCC developer with an interest in improving the compi
> It is obvious that you misunderstood what I want, and how intrusive
> the approach is.
>
Yes Alexandre, everyone who disagrees with you must not understand!
That's really the problem here.
None of us understand but you.
On 12/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Then, we let tree optimizers do their jobs. Whenever they rename,
> renumber, coalesce, combine or otherwise optimize a variable, they
> will automatically update debug statements that mention them as well.
>
Speaking only about the tree l
>
> It is desirable to be able to represent constants and other
> optimized-away values, rather than stating variables have values they
> can no longer have:
>
> int
> x1 (int x)
> {
> int i;
>
> i = 2;
> f(i);
> i = x;
> h();
> i = 7;
> g(i);
> }
>
> Even if variable i is completely
On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>
> > Consider PRE alone,
>
> > If your debug statement strategy is "move debug statements when we
> > insert code that is
On 12/19/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> > On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> >
> > > Consider PRE alone,
> >
> > > If your debu
On 12/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>
> >> int c = z;
> >> whatever0(c);
> >> c = x;
>
> > Because you have added information you have no way of knowing
On 12/19/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
> >
> > Here is the easy one:
> >
> > z_5 = a_3 + b_3
> > x_4 = z_5 + c_3
> >
> > DEBUG(x, x_4)
> >
> >
> > Reassoc may transform this into:
On 12/19/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
>
> > It gets worse, however
> >
> > c_3 = a_1 + b_2
> > z_5 = c_3 + d_9
> > x_4 = z_5 + e_10
> > DEBUG(x, x_4)
> > y_7 = x_4 + f_11
> > z_8 = y_7 + g_12
> > ->
> >
> > c_3 = a_1 + b_2
> > z_5 = c_3 + g_12
> > x_4 = z_5 + e_10
> > DEBUG(x, x_4
On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>
> > Here is the easy one:
>
> > z_5 = a_3 + b_3
> > x_4 = z_5 + c_3
>
> > DEBUG(x, x_4)
>
>
> > Reasso
On Dec 25, 2007 1:57 PM, Tim Josling <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-12-15 at 20:54 -0200, Alexandre Oliva wrote:
> > On Dec 3, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote:
> >
> > > In my view, ChangeLog is mostly "write-only" from a developer's
> > > perspective. It's a document th
1001 - 1072 of 1072 matches
Mail list logo
