The install.texi manual has the following bit of code for the title page:
--
@titlepage
@sp 10
@comment The title is printed in a large font.
@center @titlefont{Installing GCC}
--
However, thi
Andi Kleen <[EMAIL PROTECTED]> writes:
| "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
| >
| > And we don't want to arm our detractors with bad SPEC numbers. I can just
| > imagine the FUD spreading... we've got to fix it or backout.
|
| For me as a gcc user miscompilations are far worse than ba
On 2/19/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Tue, Feb 20, 2007 at 12:27:42AM +, Joseph S. Myers wrote:
>... *All* releases seem to have the
> predictions that they are useless, should be skipped because the next
> release will be so much better in way X or Y, etc.; I think the question
On Tue, Feb 20, 2007 at 06:23:14PM -0500, Kaveh R. GHAZI wrote:
> No it doesn't need stating, at least not for me. :-) Sure nobody likes
> bugs/miscompilations, but all compilers have them. We evaluate how
> serious they are and whether a performance hit from a bug fix is worth it.
> My understan
Paweł Sikora wrote:
> Current development line of PLD-Linux uses 4.2 too.
Thanks for that information.
> Mark, could you add the PR30052 to your 4.2-TODO ?
Did you mean personally? If so, I have no particular plans to work on
this PR. I'm afraid that my GCC time is pretty limited, and I'm try
Richard Guenther wrote:
>> This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP
>> ratios).
Clearly, 4.7% is significant. Grigory, thanks for the measurements!
>> Here is the full set of changes in cpu2k6/fp performance of GCC 4.2
>> compiler between r116799 and r120817, measure
On Tue, 20 Feb 2007, Andi Kleen wrote:
> "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
> >
> > And we don't want to arm our detractors with bad SPEC numbers. I can just
> > imagine the FUD spreading... we've got to fix it or backout.
>
> For me as a gcc user miscompilations are far worse than bad
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
>
> And we don't want to arm our detractors with bad SPEC numbers. I can just
> imagine the FUD spreading... we've got to fix it or backout.
For me as a gcc user miscompilations are far worse than bad SPEC numbers.
I never run SPEC, but if my programs
On 2/20/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
>> FP performance regressions of the recent GCC 4.2 (revision 120817)
>> compiler against September GCC 4.2 (revision 116799)
> What does that translate to in terms of overall score?
>
Hi,
This is 4.7% drop of SPECfp_b
Mark Mitchell wrote:
FP performance regressions of the recent GCC 4.2 (revision 120817)
compiler against September GCC 4.2 (revision 116799)
What does that translate to in terms of overall score?
Hi,
This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP
ratios).
Here is the f
Paolo Bonzini wrote:
I am agree, benchmarking is evil. My favorite benchmark is gcc
because it is my tool and I work on it. Compilation of gcc from
Spec2000 is >12% slower with df including last Paolo's patches
(which are a really big improvement).
Interesting enough, 176.gcc has a pre
> As a first step, to stay on conservative side, it makes sense
> consider the scalar cost of smaller block while calculating scalar cost.
> Note, smaller block may not exist.
I think that this should be considwered quite common.
We should base the weights of the costs of the two blocks on branch
I am agree, benchmarking is evil. My favorite benchmark is gcc because
it is my tool and I work on it. Compilation of gcc from Spec2000 is
>12% slower with df including last Paolo's patches (which are a really
big improvement).
Interesting enough, 176.gcc has a pretty bad result for runti
On 2/20/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> FWIW, in Apple distributed GCC 4.0.x, strict-aliasing is disabled by
> default when -O? is used because it breaks too much existing
> code (not just Apple internal code).
Much more than in 3.x?
I do not have data to answer this appropriate
> FWIW, in Apple distributed GCC 4.0.x, strict-aliasing is disabled by
> default when -O? is used because it breaks too much existing
> code (not just Apple internal code).
Much more than in 3.x?
--
Eric Botcazou
* How do we compare the costs of if-converted vectorized code to
it's scalar counterpart?
o It may be convenient to calculate scalar cost during if-conversion itself.
o It is possible that size of two sibling blocks (Block_A & Block_B)
does not match at the beginning of tree-ssa level if co
As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
bugs are pretty nasty it is hard to find a option to work around because
alias info is used in many optimizations.
All bugs we are talking about can be worked around by using
-fno-strict-aliasing.
FWIW, in Apple distribute
>
>
> Hello,
>
> We saw that the reassociation pass does not operate on built-in functions,
> for example:
>
> vp3 = vec_madd (vp1, vp2, vp3);
One thing which could be done is expand the builtins into tree code
instead of keeping around a builtin function.
This might also help other cases too
Paolo Bonzini wrote:
In term of ports, yes I am agree. As the preformance even with last
Paolo's patches (some changes could be applied to the mainline too,
so it is not only about df), the branch compiler is still 8.7% slower
for SPECint2000 compilation on 2.66Ghz Core2 with
--enable-chec
In term of ports, yes I am agree. As the preformance even with last
Paolo's patches (some changes could be applied to the mainline too, so
it is not only about df), the branch compiler is still 8.7% slower for
SPECint2000 compilation on 2.66Ghz Core2 with --enable-check=release.
Just to str
Steven Bosscher wrote:
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>[Option 1] Instead of 4.2, we should backport some functionality from
>4.2 to the 4.1 branch, and call that 4.2.
>
>[Option 2] Instead of 4.2, we should skip 4.2, stabilize 4.3, and call
>that 4.2.
>
>[Option 3] Li
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>[Option 1] Instead of 4.2, we should backport some functionality from
>4.2 to the 4.1 branch, and call that 4.2.
>
>[Option 2] Instead of 4.2, we should skip 4.2, stabilize 4.3, and call
>that 4.2.
>
>[Option 3] Like (2), but create (the ne
Steven Bosscher <[EMAIL PROTECTED]> writes:
> Hello,
>
...[snip]
> So I'm looking for help here: Who can help me find a test case to trigger
> a verify_flow_info ICE in GCC with the above patch applied? Can people
> try this patch on their favorite target, and see if they can trigger a
> test sui
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>
>> As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
>> bugs are pretty nasty it is hard to find a option to work around because
>> ali
Richard Guenther wrote:
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
bugs are pretty nasty it is hard to find a option to work around because
alias info is used in many optimizations.
All bugs we are talking a
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
bugs are pretty nasty it is hard to find a option to work around because
alias info is used in many optimizations.
All bugs we are talking about can be worked around b
Mark Mitchell wrote:
I've spent some time today looking at GCC 4.2.
I've heard various comments about whether or not it's worth doing a 4.2
release at all. For example:
[Option 1] Instead of 4.2, we should backport some functionality from
4.2 to the 4.1 branch, and call that 4.2.
[Option 2]
Hello,
> >this seems quite close to what TARGET_MEM_REFs are designed for. IMHO,
> >the best way would be to lower the memory references to TARGET_MEM_REFs
> >(*) just once, sometime quite late in the optimization pipeline (just after
> >loop optimizations, for example), so that high-level optimi
Ian Lance Taylor wrote:
Unfortunately support for the Intel i960 was dropped in gcc 4.0.
There is no way to generate i960 code with a recent gcc release.
which means that GNAT is also unavailable at this stage.
"sameer sinha" <[EMAIL PROTECTED]> writes:
> Please can any one tell me how to bulid gcc newer version for
> generating
> code for i960MC processor.
> is there any switch to generate coed for i960MC or i will
> have to build it first
> for target i960.
>
On Mon, 19 Feb 2007, Joe Buck wrote:
> On Tue, Feb 20, 2007 at 12:27:42AM +, Joseph S. Myers wrote:
> >... *All* releases seem to have the
> > predictions that they are useless, should be skipped because the next
> > release will be so much better in way X or Y, etc.; I think the question
> >
Zdenek Dvorak wrote:
Hello,
In principle, I don't see anything forbidding Zdenek's idea.
Unfortunately, what I avoided to mention is that TARGET_MEM_REF nodes
are also transformed into pointer arithmetics
and the equivalent
INDIRECT_REF memory access... therefore, this is not an option even o
Hello,
We saw that the reassociation pass does not operate on built-in functions,
for example:
vp3 = vec_madd (vp1, vp2, vp3);
In the RTL level the function is expanded to regular insn:
(insn 87 91 88 9 (set (reg/v:V4SF 217 [ vp3 ])
(plus:V4SF (mult:V4SF (reg/v:V4SF 219 [ vp1 ])
Hello,
> >>In principle, I don't see anything forbidding Zdenek's idea.
> >>Unfortunately, what I avoided to mention is that TARGET_MEM_REF nodes
> >>are also transformed into pointer arithmetics
> >>and the equivalent
> >>INDIRECT_REF memory access... therefore, this is not an option even only
Hi,
I am working on GCC 3.3.1 port. The architecture mostly based
on RISC architecture.
Here is the problem.
After compiling following code
--
void g(char *a);
f(char c)
{
g(&c);
}
-
The in the generated RTL (file.c.00.rtl)
I see inc
Zdenek Dvorak wrote:
Hello,
you might try turning the references to TARGET_MEM_REFs, and copy the
alias information using copy_ref_info to it. I am not sure how that
would interact with the transformations you want to do, but we do lot
of magic to keep the virtual operands for TARGET_MEM_REFs
Hello,
> >>>you might try turning the references to TARGET_MEM_REFs, and copy the
> >>>alias information using copy_ref_info to it. I am not sure how that
> >>>would interact with the transformations you want to do, but we do lot
> >>>of magic to keep the virtual operands for TARGET_MEM_REFs the
Richard Guenther napisał(a):
On 2/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
So, my feeling is that the best course of action is to set a relatively
low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
Then, we'll have a 4.2.0 release by (worst case, and allowing fo
On 2/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
So, my feeling is that the best course of action is to set a relatively
low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
Then, we'll have a 4.2.0 release by (worst case, and allowing for
lameness on my part) March 3
Zdenek Dvorak wrote:
Hello,
you might try turning the references to TARGET_MEM_REFs, and copy the
alias information using copy_ref_info to it. I am not sure how that
would interact with the transformations you want to do, but we do lot
of magic to keep the virtual operands for TARGET_MEM_REFs
40 matches
Mail list logo
