On Dec 20, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> I'm addressing this in a bit more detail in a revised version of the
> spec, that I intend to publish in the GCC wiki RSN.
http://gcc.gnu.org/wiki/Var_Tracking_Assignments
Here's a diff between the version I posted a couple of days ag
On Nov 5, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote:
> Alex, maybe you could add a Wiki page about this project
Done, at last! :-)
http://gcc.gnu.org/wiki/Var_Tracking_Assignments
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member ht
I'm checking this in...
--- svn.html16 Nov 2007 11:11:59 -0200 1.69
+++ svn.html20 Dec 2007 06:02:39 -0200
@@ -156,7 +156,8 @@ list therefore provides only some repres
- var-tracking-assignments-branch
+ http://gcc.gnu.org/wiki/Var_Tracking_Assignments";>
+ var-trac
On Dec 20, 2007 9:00 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Nov 5, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote:
>
> > Alex, maybe you could add a Wiki page about this project
>
> Done, at last! :-)
>
> http://gcc.gnu.org/wiki/Var_Tracking_Assignments
Very nice. Thanks!
Gr.
Ste
Hi,
>
> Jan, wrt the optimization plan coming out of the analysis phase, and the
> various pieces of header/summary information, what do you think are the
> major pieces we need?
The cgraph used to be organized on a separate analysis, propagation and
modify stages and the passes in implemented
Ye, Joey writes:
>> This proposal values correctness at first place. So when compile
can't
>> make sure a function is only called from functions with the same or
bigger
>> preferred-stack-boundary, it will conservatively align the stack. One
>> optimization is to set INCOMING = PREFERRED for local
Andrew,
My proposal is supposed not limited to i386/x86_64. Would do please
spend some time review it and see if it can really solve problem in PowerPC?
Your comments is welcome.
Thanks - Joey
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Pins
Alexandre Oliva writes:
> On Dec 19, 2007, Andrew Haley <[EMAIL PROTECTED]> wrote:
>
> > Right, so read_type_die() doesn't know how to handle
> > DW_TAG_interface_type. The weird thing is that I have never seen
> > this error mesage before today, and AFAIAA gcj has been
> > generating these
On Dec 20, 2007, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva writes:
>> PR debug/7081
>> * lang.c (java_classify_record): New.
>> (LANG_HOOKS_CLASSIFY_RECORD): Override.
> Yeah, I discovered this today. Because your patch hadn't been flagged
> as affecting Java and no Java maintain
Alexandre Oliva writes:
>
> How about this patch, instead? It will restore debuggability to Java
> while at the same time maintaining the progress of using the
> long-supported-by-GDB DW_TAG_class_type in both C++ and Java.
>
> for gcc/java/ChangeLog
> from Alexandre Oliva <[EMAIL PROT
> My untested (and consequently firmly
> held) hypothesis is that
>
> 1) most combinations of && and || don't need parentheses because
>
> (a && b) || (c && d)
>
> is by far more common than
>
> a && (b || c) && d
>
> and, moreover, broken code fails at runtime, and
I dispute these cla
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> > How do i know i need to change this DEBUG expression.
>
> As reassoc looks for sets of variables it can freely mess with, it
> should take note of variables that are used in debug annotations in
> addition to the kind of single (?) non-debug uses it
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Dec 19, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > For some things, sure, but we are just talking about the values in
> > user visible variables stored in registers. There is no way we can
> > make that information be correct between
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> > And it will avoid the problem of turning the testsuite into a
> > regression testsuite rather than an accuracy testsuite.
>
> Sorry, I don't understand what you mean here.
It's not a major point.
When one adds a testsuite to working code, it is na
"James K. Lowden" <[EMAIL PROTECTED]> writes:
> > That particular warning happened to find dozens of real errors when I
> > ran it over a large code base. It may be noise for you, but I know
> > from personal experience that it is very useful.
>
> I would like to hear more about that, if you wou
In:
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00979.html
I propose a new mangling for embedded java resource files.
Quoting from that message:
> The mangling is as follows:
>
> The resource name is broken into path components by '/' characters. Each
> component then has an '_' prepended and
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> > How do i know i need to change this DEBUG expression.
>>
>> As reassoc looks for sets of variables it can freely mess with, it
>> should take note of variables that are used in debug an
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> It is technically feasible but problematic for other reasons.
> i = i * m + ((i / j) + k) / n;
> On a two register machine like the x86 i will change several times
> during that calculation.
No. The register used to hold its init
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > It is technically feasible but problematic for other reasons.
> > i = i * m + ((i / j) + k) / n;
> > On a two register machine like the x86 i will change several times
> > during t
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Right, which will significantly increase debugging size as you add two
> more notes around many lines.
If that's the price to avoid debug information consumers getting
incorrect values...
Would you argue for a position such as:
we
Alexandre Oliva wrote:
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Right, which will significantly increase debugging size as you add two
more notes around many lines.
If that's the price to avoid debug information consumers getting
incorrect values...
It may be an unaccept
I tried to compile gcc4.2.x on Ubuntu, and there is an error message
as the following.
"make[3]: *** No rule to make target
`../../../srcdir/fixincludes/../gcc/BASE-VER', needed by `mkheaders'.
Stop.
make[3]: Leaving directory
`/home/paul/gcc/gcc-4.2.0/objdir/build-i686-pc-linux-gnu/fixincludes'
m
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > Right, which will significantly increase debugging size as you add two
> > more notes around many lines.
>
> If that's the price to avoid debug information consumers getting
> incorre
Ian Lance Taylor wrote:
> A typical true positive looked more or less like
>
> if (a &&
> b || c)
http://www.jetcafe.org/jim/c-style.html
It's funny you should mention that. A warning about whitespace
indentation that's inconsistent with the expressed logic *would* be
helpful (and c
Hi,
Could someone give some hints of where to find the sources and
algorithms of implementing
the DFA pipeline hazard recognizer in GCC, which files and functions?
Thanks advance.
Qing
Qing Wei <[EMAIL PROTECTED]> writes:
> Could someone give some hints of where to find the sources and
> algorithms of implementing
> the DFA pipeline hazard recognizer in GCC, which files and functions?
The files haifa-sched.c, sched-*.[ch] .
Ian
26 matches
Mail list logo
