Their web pages primarily talk about the 64-bit performance on AMD
systems. Maybe they aren't well tuned for 32-bit performance and/or
Intel parts. Anyways, from what Daniel Berlin mentioned, it may be
that
the tree-ssa stuff in gcc4.x has negated much of their earlier
advantage.
I would
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jul 1, 2005, at 12:49 AM, Gabriel Dos Reis wrote:
|
| >
| > As I said, if you let user tell you that his loop behaves well, i.e.
| > bounds do not rely on wrapping semantics, and yet he writes his loop to
| > deceive the compiler, then he loses. Let
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jul 1, 2005, at 12:06 AM, Gabriel Dos Reis wrote:
| >
| > There are of course coner and pathological cases, but I don't think we
| > should worry too much about missing them. Let's first cover the
| > structured loops, and address the contorsed ones
On Jul 1, 2005, at 12:49 AM, Gabriel Dos Reis wrote:
As I said, if you let user tell you that his loop behaves well, i.e.
bounds do not rely on wrapping semantics, and yet he writes his loop to
deceive the compiler, then he loses. Let him choose his own poinson,
don't think you have to choose
On Jul 1, 2005, at 12:06 AM, Gabriel Dos Reis wrote:
There are of course coner and pathological cases, but I don't think we
should worry too much about missing them. Let's first cover the
structured loops, and address the contorsed ones later if they become
really important.
And I just submi
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Fri, 2005-07-01 at 03:39 +0200, Gabriel Dos Reis wrote:
| > Joe Buck <[EMAIL PROTECTED]> writes:
| >
| > | On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote:
| > | > But the reason question is why make it an undefined behavior instead of
On Fri, 2005-07-01 at 03:39 +0200, Gabriel Dos Reis wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> | On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote:
> | > But the reason question is why make it an undefined behavior instead of
> | > an implementation defined? This would have mad
On 30/06/2005, at 6:41 PM, Daniel Jacobowitz wrote:
On Thu, Jun 30, 2005 at 06:37:07PM -0700, Geoff Keating wrote:
On 30/06/2005, at 6:26 PM, David Edelsohn wrote:
Geoff Keating writes:
Geoff> Does anyone mind if I update libtool to the latest released
version,
Geoff> 1.5.18, and regen
On Thu, 2005-06-30 at 17:17 -0700, James E Wilson wrote:
> Vladimir Makarov wrote:
> > I just hope results
> > for 64-bit mode, amd machine, or SPECFP2000 are better.
>
> Their web pages primarily talk about the 64-bit performance on AMD
> systems. Maybe they aren't well tuned for 32-bit perfor
On Thu, 2005-06-30 at 14:11 -0700, Geoffrey Keating wrote:
> Richard Henderson <[EMAIL PROTECTED]> writes:
>
> > On Wed, Jun 29, 2005 at 09:17:07PM -0400, Daniel Berlin wrote:
> > > 1. In require_complete_types_for_parms, in the C++ FE, reset DECL_SIZE
> > > to NULL before we call layout_decl on t
On Thu, Jun 30, 2005 at 06:37:07PM -0700, Geoff Keating wrote:
>
> On 30/06/2005, at 6:26 PM, David Edelsohn wrote:
>
> >>Geoff Keating writes:
> >>
> >
> >Geoff> Does anyone mind if I update libtool to the latest released
> >version,
> >Geoff> 1.5.18, and regenerate everything with aut
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote:
| > But the reason question is why make it an undefined behavior instead of
| > an implementation defined? This would have made it clearer instead of
| > allowing the compiler not document what h
On 30/06/2005, at 6:26 PM, David Edelsohn wrote:
Geoff Keating writes:
Geoff> Does anyone mind if I update libtool to the latest released
version,
Geoff> 1.5.18, and regenerate everything with automake 1.9.5?
If everyone agrees to go forward with this
Oh, I should have said: "and
> Joe Buck <[EMAIL PROTECTED]>
> Undefined behavior doesn't mean that we should attempt to arbitrarily
> punish those who cross the line; that's why I don't think forcing integer
> overflows to trap (at least by default) is a good idea. In many cases,
> "assume no overflow, but don't trap" can pro
> Geoff Keating writes:
Geoff> Does anyone mind if I update libtool to the latest released version,
Geoff> 1.5.18, and regenerate everything with automake 1.9.5?
If everyone agrees to go forward with this, please work with Mark
to schedule a freeze on all other GCC development so th
My m32c port is generating tracking notes that look like this:
(var_location 0x2a95758dd0 (parallel [
(expr_list:REG_DEP_TRUE (reg/v:SI 0 r0 [orig:123 remainder_size ]
[123])
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:HI 1 r2 [ remainder_size+2 ])
On Thu, Jun 30, 2005 at 09:02:48PM -0400, Andrew Pinski wrote:
> But the reason question is why make it an undefined behavior instead of
> an implementation defined? This would have made it clearer instead of
> allowing the compiler not document what happens. Or is C++
> just following C here? I
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jun 30, 2005, at 8:48 PM, Gabriel Dos Reis wrote:
|
| > | Really? You've talked to Stroustrup?
| >
| > I work with him on daily basis, and as a matter of fact we've discussed
| > the heart of this topic of this thread yesterday over lunch. But, as
Does anyone mind if I update libtool to the latest released version,
1.5.18, and regenerate everything with automake 1.9.5?
smime.p7s
Description: S/MIME cryptographic signature
> Joe Buck <[EMAIL PROTECTED]>
> Undefined behavior doesn't mean that we should attempt to arbitrarily
> punish those who cross the line; that's why I don't think forcing integer
> overflows to trap (at least by default) is a good idea. In many cases,
> "assume no overflow, but don't trap" can pro
On Jun 30, 2005, at 8:48 PM, Gabriel Dos Reis wrote:
| Really? You've talked to Stroustrup?
I work with him on daily basis, and as a matter of fact we've discussed
the heart of this topic of this thread yesterday over lunch. But, as
much as I hate argument by authority I could not let this d
Joe Buck <[EMAIL PROTECTED]> writes:
| On Fri, Jul 01, 2005 at 12:25:58AM +0200, Gabriel Dos Reis wrote:
| > Joe Buck <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | Given your biases, you might be happier with Java as a language (than C or
| > | C++). The Java language designers decided to
Vladimir Makarov wrote:
I just hope results
for 64-bit mode, amd machine, or SPECFP2000 are better.
Their web pages primarily talk about the 64-bit performance on AMD
systems. Maybe they aren't well tuned for 32-bit performance and/or
Intel parts. Anyways, from what Daniel Berlin mentioned,
Snapshot gcc-4.0-20050630 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050630/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050630
You'll
On Friday 01 July 2005 01:05, Vladimir Makarov wrote:
> Andrey Belevantsev wrote:
> > Vladimir Makarov wrote:
> >> I'll look at this PR today.
> >
> > We've looked today at this issue. We think the problem is that
> > proposed patch of sched_get_condition() treats conditional jumps
> > likely to CO
On Friday 01 July 2005 01:05, Vladimir Makarov wrote:
> Andrey Belevantsev wrote:
> > Vladimir Makarov wrote:
> >> I'll look at this PR today.
> >
> > We've looked today at this issue. We think the problem is that
> > proposed patch of sched_get_condition() treats conditional jumps
> > likely to CO
On Fri, Jul 01, 2005 at 12:25:58AM +0200, Gabriel Dos Reis wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | Given your biases, you might be happier with Java as a language (than C or
> | C++). The Java language designers decided to strictly define many cases
> | that are not defined
Andrey Belevantsev wrote:
Vladimir Makarov wrote:
I'll look at this PR today.
We've looked today at this issue. We think the problem is that
proposed patch of sched_get_condition() treats conditional jumps
likely to COND_EXECs, but it doesn't fix other places in sched-deps,
where COND_EX
On Thu, 2005-06-30 at 18:23 -0400, Vladimir Makarov wrote:
> James E Wilson wrote:
>
> > Daniel Berlin wrote:
> >
> >> A bunch of random code #ifdef KEY'd
> >
> >
> > FYI Pathscale was formerly known as Key Research. So the KEY probably
> > wouldn't mean anything special here, it is likely just
Andrey Belevantsev wrote:
We've also found that current mainline ICEs compiling the testcase with
"-O0 -fschedule-insns -fschedule-insns2".
I suspect this is a bug in ia64_reorg in ia64.c. It shouldn't be trying
to schedule during a non-optimizing compile. So the line
if (ia64_flag_schedu
Joe Buck <[EMAIL PROTECTED]> writes:
[...]
| Given your biases, you might be happier with Java as a language (than C or
| C++). The Java language designers decided to strictly define many cases
| that are not defined in C (example: the order side effects is always
| strictly left to right, float
James E Wilson wrote:
Daniel Berlin wrote:
A bunch of random code #ifdef KEY'd
FYI Pathscale was formerly known as Key Research. So the KEY probably
wouldn't mean anything special here, it is likely just a marker for
local changes.
I heard a lot of this compiler and expected a better r
This function generates RTL from an expression to see how many RTL insns
it is. But this causes a problem compiling the Ada ACATS test cxa4006.
The problem is when part of the expression has a location. In that
case, record_block_change is called and that relies on
cfun->ib_boundaries_block bein
I had a friend call up and ask where he could find the gcc-4.0.0
tarball. I did a quick survey of the GNU FTP mirrors and only 1 out
of the first 7 had gcc-4.0.0 on it. :-( At least some of the GNU
mirrors aren't carrying gcc-4.0.0.
Kinda sad.
I did a quick survey of the our gcc mirrors
Steven Bosscher wrote:
Are predicate checks free, or should there be some post-pass to
clean up this kind of useless predication?
On IA-64, predicate checks are free in terms of run-time. There is the
problem that unnecessary predicate checks might increase register
lifetimes, causing extra
On Thu, Jun 30, 2005 at 03:14:54PM -0400, Paul Schlie wrote:
> Given that the formal implication of GCC's choice not define signed integer
> overflow semantics as being other than undefined will be to guaranteed that
> all programs, with reachable signed integer arithmetic operations which can
> no
Daniel Berlin wrote:
A bunch of random code #ifdef KEY'd
FYI Pathscale was formerly known as Key Research. So the KEY probably
wouldn't mean anything special here, it is likely just a marker for
local changes.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
On Tue, 28 Jun 2005, wangxiuli wrote:
> gcc some errors appear when compiling gcc-3.4.4 and gcc-4.0.0 on i386
> freebsd -5.2.1.those errrors are caused by byacc's convention of
> arguments .how to solve them?
In addition to what Zack wrote: you may want to use the lang/gcc34 and
lang/gcc40 ports
On Jun 30, 2005, at 12:47 PM, Steven Bosscher wrote:
Well, maybe so, but it would be a pretty lame workaround. Why are you
so worried about bugs? This flag was always disabled at -O1, and we
have never seen any bug reports that got fixed with -fforced-mem. And
besides, it is better to fix b
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Wed, Jun 29, 2005 at 09:17:07PM -0400, Daniel Berlin wrote:
> > 1. In require_complete_types_for_parms, in the C++ FE, reset DECL_SIZE
> > to NULL before we call layout_decl on the parm and let layout_decl
> > figure out what to do.
>
> This is w
On Thursday 30 June 2005 16:18, Andrey Belevantsev wrote:
> Vladimir Makarov wrote:
> > I'll look at this PR today.
>
> We've looked today at this issue. We think the problem is that proposed
> patch of sched_get_condition() treats conditional jumps likely to
> COND_EXECs, but it doesn't fix other
[EMAIL PROTECTED] (Gabriel Dos Reis) wrote on 27.06.05 in <[EMAIL PROTECTED]>:
> Nathan Sidwell <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis wrote:
> |
> | > But a compiler could define them to be modulo -- that is the whole
> | > point. The paragraph does not say they don't "modulo".
> |
On Thursday 30 June 2005 16:18, Andrey Belevantsev wrote:
> We don't know reload well enough to know for sure which place should be
> fixed in reload, or maybe in update_life_info(). Is this issue worth
> opening another PR?
This is a separate PR.
Actually, I'm surprised that -O0 -fschedule-insns
On Thursday 30 June 2005 04:24, Andrew Pinski wrote:
> Ada is now broken on the mainline by:
> 2005-06-28 Paul Brook <[EMAIL PROTECTED]>
> * Makefile.in: Set and use UNWIND_H. Install as unwind.h.
> * c-decl.c (finish_decl): Call default_init_unwind_resume_libfunc.
> * except.c
(sorry, meant additive/multiplicative inverse +/- MAX/MIN_ value;
but even that's wrong, which is why it seems that leaving signed overflow
as being undefined is such a bad idea, as it becomes correspondingly very
difficult to even try determine if a program is warranted to have a
deterministic
On Thursday 30 June 2005 21:05, Fariborz Jahanian wrote:
> On Jun 30, 2005, at 11:23 AM, Jeffrey A Law wrote:
> > On Thu, 2005-06-30 at 20:12 +0200, Bernd Schmidt wrote:
> >> Jeffrey A Law wrote:
> >>> I'd tend to agree. I'd rather see the option go away than linger on
> >>> if the option is no lo
Given that the formal implication of GCC's choice not define signed integer
overflow semantics as being other than undefined will be to guaranteed that
all programs, with reachable signed integer arithmetic operations which can
not warrant that their respective operand expressions are recursively
c
On Jun 30, 2005, at 11:23 AM, Jeffrey A Law wrote:
On Thu, 2005-06-30 at 20:12 +0200, Bernd Schmidt wrote:
Jeffrey A Law wrote:
I'd tend to agree. I'd rather see the option go away than linger on
if the option is no longer useful.
I wouldn't mind that, but I'd also like to point out tha
On Thu, 2005-06-30 at 20:47 +0200, Giovanni Bajo wrote:
> Daniel Berlin <[EMAIL PROTECTED]> wrote:
>
> > So we've got a parm decl that if you ask it for the DECL_SIZE, says 0,
> > but has a TYPE_SIZE of 12 bytes, and we access fields in it, etc.
>
>
> I am not sure of what the exact relations be
Daniel Berlin <[EMAIL PROTECTED]> wrote:
> So we've got a parm decl that if you ask it for the DECL_SIZE, says 0,
> but has a TYPE_SIZE of 12 bytes, and we access fields in it, etc.
I am not sure of what the exact relations between DECL_SIZE and TYPE_SIZE
are, but probably some verification coul
Joe Buck <[EMAIL PROTECTED]> wrote:
>>> I'd tend to agree. I'd rather see the option go away than linger on
>>> if the option is no longer useful.
>>
>> I wouldn't mind that, but I'd also like to point out that there are
>> Makefiles out there which hard-code things like -fforce-mem. Do we want
On Thu, 2005-06-30 at 20:12 +0200, Bernd Schmidt wrote:
> Jeffrey A Law wrote:
> > I'd tend to agree. I'd rather see the option go away than linger on
> > if the option is no longer useful.
>
> I wouldn't mind that, but I'd also like to point out that there are
> Makefiles out there which hard-c
On Thu, Jun 30, 2005 at 08:12:14PM +0200, Bernd Schmidt wrote:
> Jeffrey A Law wrote:
> >I'd tend to agree. I'd rather see the option go away than linger on
> >if the option is no longer useful.
>
> I wouldn't mind that, but I'd also like to point out that there are
> Makefiles out there which h
Jeffrey A Law wrote:
I'd tend to agree. I'd rather see the option go away than linger on
if the option is no longer useful.
I wouldn't mind that, but I'd also like to point out that there are
Makefiles out there which hard-code things like -fforce-mem. Do we want
to keep the option as a stu
I can confirm that Zdenek's patch for PR 21963 also fixes PR 22212.
On Thu, 2005-06-30 at 18:55 +0200, Steven Bosscher wrote:
> On Thursday 30 June 2005 18:05, fjahanian wrote:
> > On Jun 27, 2005, at 2:50 PM, Fariborz Jahanian wrote:
> > > On Jun 27, 2005, at 12:56 PM, Richard Henderson wrote:
> > >> Hmm. I would suspect this is obsolete now. We'll have forced
>
On Thursday 30 June 2005 18:05, fjahanian wrote:
> On Jun 27, 2005, at 2:50 PM, Fariborz Jahanian wrote:
> > On Jun 27, 2005, at 12:56 PM, Richard Henderson wrote:
> >> Hmm. I would suspect this is obsolete now. We'll have forced
> >> everything into "registers" (or something equivalent that we
>
On Thursday 30 June 2005 16:19, Mostafa Hagog wrote:
> Hi,
>
> Steven Bosscher <[EMAIL PROTECTED]> wrote on 30/06/2005 01:46:22:
> > Hi,
>
> [snip]
>
> > Then the ia64 machine-reorg scheduler gets to work, and it produces:
> >
> > (insn:TI 8 70 12 0 (set (reg:BI 262 p6 [353])
> > (ne:BI (re
The bug you describe most probably is PR 21963 (and there is a patch for
this PR submitted).
Actually, I found out after my email that the exact case I found is
PR22212, but 21963 does look like the same symptom. What's the status
of this patch?
On Jun 30, 2005, at 12:05 PM, fjahanian wrote:
Bootstrapped and dejagnu tested on apple-x86-darwin and
apple-ppc-darwin.
We also observed that on ppc, SPEC did not show any performance change
either way. On apple-x86-darwin 252.eon improved by 7% as expected,
with no noticeable change in oth
On Jun 27, 2005, at 2:50 PM, Fariborz Jahanian wrote:
On Jun 27, 2005, at 12:56 PM, Richard Henderson wrote:
Hmm. I would suspect this is obsolete now. We'll have forced
everything into "registers" (or something equivalent that we
can work with) during tree optimization. Any CSEs that ca
Diego Novillo <[EMAIL PROTECTED]> wrote on 28.06.2005 20:51:52:
> On Tue, Jun 28, 2005 at 08:38:13PM +0200, Ulrich Weigand wrote:
> > Hello,
> >
> > with current GCC mainline bootstrap fails on s390(x)-ibm-linux
> > during stage2 build with:
> >
> I'm on it.
s390(x) bootstrap failures are now fix
Hello,
> Isn't it the case that *any* conversion can be stripped for the purpose
> of this routine? I get an ICE compiling the Ada RTS a-strfix.adb because
> of that. The following seems to fix it, but is it right?
no, it is not. The uses of constant_multiple_of expect that it
determines wheth
On Jun 24, 2005, at 5:20 PM, fjahanian wrote:
On Jun 24, 2005, at 5:06 PM, Steven Bosscher wrote:
On Saturday 25 June 2005 01:48, fjahanian wrote:
On Jun 24, 2005, at 3:16 PM, Andrew Pinski wrote:
I wonder why combine can do the simplification though which is why
still
produce good co
On Jun 24, 2005, at 5:06 PM, Steven Bosscher wrote:
On Saturday 25 June 2005 01:48, fjahanian wrote:
On Jun 24, 2005, at 3:16 PM, Andrew Pinski wrote:
I wonder why combine can do the simplification though which is why
still
produce good code for the simple testcase:
void f1(double *d,float
Hi,
Steven Bosscher <[EMAIL PROTECTED]> wrote on 30/06/2005 01:46:22:
>
> Hi,
>
[snip]
> Then the ia64 machine-reorg scheduler gets to work, and it produces:
>
> (insn:TI 8 70 12 0 (set (reg:BI 262 p6 [353])
> (ne:BI (reg/v:SI 15 r15 [orig:348 b1 ] [348])
> (const_int 0 [0
Vladimir Makarov wrote:
I'll look at this PR today.
We've looked today at this issue. We think the problem is that proposed
patch of sched_get_condition() treats conditional jumps likely to
COND_EXECs, but it doesn't fix other places in sched-deps, where
COND_EXECs are considered. Maxim Kuvy
Steven Bosscher wrote:
Notice how the conditional sets of r14 and r17 in insns 9 and 10 have
been moved past insn 14, which uses these registers. Shouldn't there
be true dependencies on insns 9 and 10 for insn 14?
In theory, yes. But the scheduler (it is ebb scheduler as I understand)
fre
On Thursday 30 June 2005 12:53, Richard Earnshaw wrote:
> On Thu, 2005-06-30 at 11:22, Steven Bosscher wrote:
> > For your problem, I think the jump should just be forced somehow to
> > be the last insn in the block. You can't move things into other
> > basic blocks if you are not doing interblock
On Thu, 2005-06-30 at 11:22, Steven Bosscher wrote:
> For your problem, I think the jump should just be forced somehow to
> be the last insn in the block. You can't move things into other
> basic blocks if you are not doing interblock scheduling, after all.
> For the PR I was looking at, someone w
On Thursday 30 June 2005 11:32, Richard Earnshaw wrote:
> Hmm, certainly looks suspicious, but it's not really what the original
> bug report was about. This might be some interblock scheduling problem
> that is also triggered by the extra scheduling freedom we get with the
> disabled change.
Hm
On Wed, 2005-06-29 at 23:46, Steven Bosscher wrote:
> Hi,
>
> I have a question about the scheduler. Forgive me if I'm totally
> missing the point here, this scheduling business is not my thing ;-)
>
> Consider the following snippet that I've derived from PR17808 with a
> few hacks in the compil
... due to drinking to much programming fluid (i.e., beer - and it
wasn't even free).
I've ordered a new laptop - an AMD Athlon 64 based one; supplemented by
AMD64 Sarge (yes, I know, Real Men Prefer Big-Endian, but then, Real Men
Don't Cry, either).
However, delivery might take a few weeks,
73 matches
Mail list logo
