On Tue, 2005-08-09 at 23:06 +0200, Björn Haase wrote:
> Steven Bosscher wrote:
> > In
> > any case, you should assume that it is a much bigger job than just
> > modifying the call expander.
>
> Ok, I had a closer look at what is happening in present state gcc and I
> understand that it is indeed
On Tue, 9 Aug 2005, Sebastian Pop wrote:
> Laurent GUERBY wrote:
> >
> > So I'm asking for project proposals, that is to say people that think
> > that their volunteer time to work on these old machine (scripts,
> > compiling, ... under the limit of minimal external bandwidth use) is of
> > some si
Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> This pass does simple forward propagation and simplification when
> an operand of an insn can only come from a single def. The pass has a
> very good potential of catching simplifications currently done by
> inter-basic-block CSE (-fcse-follow-jumps
Snapshot gcc-3.4-20050809 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050809/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050809
You'll
On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote:
> On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote:
> > There is a minor problem. How can I add crtfastmath.o for SSE targets
> > only?
>
> You don't. You either add code to detect sse, or you make the
> spec depend on -m
On Tue, 9 Aug 2005, Sebastian Pop wrote:
Joe Buck wrote:
Algorithms that are sometimes exponential can still be used if there is
a cutoff mechanism, to abort the algorithm if it exceeds a budget. This
assumes that we can then fall back to an algorithm that might produce
inferior results, but
Andrew wrote:
>> No threads in gcc, please.
>
> Why? If this is only for double checking, why not?
Sorry, I missed that boehm-gc already uses threads.
Ignore me, I'm just a cranky old-school programmer...
but still, if there's a way to implement the checker
without using threads, that would sur
On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote:
> There is a minor problem. How can I add crtfastmath.o for SSE targets
> only?
You don't. You either add code to detect sse, or you make the
spec depend on -mfpmath=sse.
> Can I add a new macro, TARGET_EXPAND_MAIN_FUNCTION, to
> expand_
On Tue, Aug 09, 2005 at 05:45:23PM -0400, Robert Dewar wrote:
> H. J. Lu wrote:
>
> >Yes, FTZ stands for flush to zero and DAZ stands for denormals are
> >zero.
>
> seems a bad idea to do this by default. lack of denormals
> gives fpt rather horrible properties
Not by default. It should be contr
H. J. Lu wrote:
Yes, FTZ stands for flush to zero and DAZ stands for denormals are
zero.
seems a bad idea to do this by default. lack of denormals
gives fpt rather horrible properties
On Tue, Aug 09, 2005 at 02:01:08PM -0700, H. J. Lu wrote:
> On Tue, Aug 09, 2005 at 01:35:11PM -0700, Richard Henderson wrote:
> > On Tue, Aug 09, 2005 at 11:02:22AM -0700, H. J. Lu wrote:
> > > I have a small testcase to show that enable FTZ/DAZ makes a huge (>160
> > > times faster) difference on
Steven Bosscher wrote:
> In
> any case, you should assume that it is a much bigger job than just
> modifying the call expander.
Ok, I had a closer look at what is happening in present state gcc and I
understand that it is indeed a much more complex task than I first thought.
One Issue would be a
On Tue, Aug 09, 2005 at 01:35:11PM -0700, Richard Henderson wrote:
> On Tue, Aug 09, 2005 at 11:02:22AM -0700, H. J. Lu wrote:
> > I have a small testcase to show that enable FTZ/DAZ makes a huge (>160
> > times faster) difference on SSE floating point code. Icc enables it by
> > defailt for -ON (N
On Tue, Aug 09, 2005 at 11:02:22AM -0700, H. J. Lu wrote:
> I have a small testcase to show that enable FTZ/DAZ makes a huge (>160
> times faster) difference on SSE floating point code. Icc enables it by
> defailt for -ON (N>=1). Should gcc do the same?
This is the flush-denormals-to-zero bit?
Se
I just accidentally deleted qmail's outgoing queue on sourceware,
thinking that I was actually deleting the queue on a new, improved
system which will be coming on line soon. This caused all outgoing
email to be deleted.
The majority of people affected were spammers but I'm sure that people
from
I have only tested it on Linux, can you give it a try? Ok if FX's
testing succeeds?
Testing succeeded on i686-mingw32. Configures and builds fine.
Can someone review this patch?
FX
On Tue, 2005-08-09 at 20:11 +0200, Laurent GUERBY wrote:
> On Tue, 2005-08-09 at 08:53 -0400, Daniel Berlin wrote:
> > > Looks good. I think it would be slightly more secure to have people
> > > commit the patch with a unique name in some access-controlled CVS
> > > (either some subdir of the GCC o
On Tue, 2005-08-09 at 08:53 -0400, Daniel Berlin wrote:
> > Looks good. I think it would be slightly more secure to have people
> > commit the patch with a unique name in some access-controlled CVS
> > (either some subdir of the GCC one or a new local one) than relying on
> > email "From" fields at
On Aug 9, 2005, at 1:59 PM, Daniel Kegel wrote:
No threads in gcc, please.
Why? If this is only for double checking, why not?
-- Pinski
I have a small testcase to show that enable FTZ/DAZ makes a huge (>160
times faster) difference on SSE floating point code. Icc enables it by
defailt for -ON (N>=1). Should gcc do the same?
H.J.
[EMAIL PROTECTED] wrote:
Okay, I stand corrected. As a practical implementation we can have a
mechanism as push/pop timevar, that would monitor the time and space
of an algorithm and that can cancel the computation for failing on a
safe approximation. As a first concretization, I was thinking t
On Tue, Aug 09, 2005 at 04:59:28PM +0200, Sebastian Pop wrote:
> Joe Buck wrote:
> > Algorithms that are sometimes exponential can still be used if there is
> > a cutoff mechanism, to abort the algorithm if it exceeds a budget. This
> > assumes that we can then fall back to an algorithm that might
On Tue, Aug 09, 2005 at 09:33:19AM +0200, Paolo Bonzini wrote:
>>Can someone with approval privilege over the build system look at this,
>>and OK it? (it's a very simple patch)
>
>I must apologize for the delay in handling this. This alternative patch
>avoids that mingw is hardcoded in the makef
Joe Buck wrote:
> Algorithms that are sometimes exponential can still be used if there is
> a cutoff mechanism, to abort the algorithm if it exceeds a budget. This
> assumes that we can then fall back to an algorithm that might produce
> inferior results, but will produce something usable in reaso
>
> Hi Jan,
>
> Your patch to mainline
>
> http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00388.html
>
> to defer handling of local statics has caused a regression
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22034
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22583
> http:
On Tue, 2005-08-09 at 12:54 +0200, Laurent GUERBY wrote:
> On Tue, 2005-08-09 at 11:02 +0200, Sebastian Pop wrote:
> > I'm proposing to automate gcc's bootstrap & regtest: for each mail
> > sent to [EMAIL PROTECTED], if 'From' is in gcc-developpers and 'body'
> > contains a patch against some branc
On Tue, 2005-08-09 at 12:28 +0100, Daniel Towner wrote:
> Hi all,
>
> I am encountering a problem with DWARF location lists. Consider the
> following assembly:
>
> _Ltext:
> main:
> _LVL0:
> ;# basic block 0
> _LVL1:
>
> This generates a DWARF location list entry whose begin and end add
Laurent GUERBY wrote:
> Looks good. I think it would be slightly more secure to have people
> commit the patch with a unique name in some access-controlled CVS
> (either some subdir of the GCC one or a new local one) than relying on
> email "From" fields at the cost of minor inconvenience.
>
We a
Hi all,
I am encountering a problem with DWARF location lists. Consider the
following assembly:
_Ltext:
main:
_LVL0:
;# basic block 0
_LVL1:
This generates a DWARF location list entry whose begin and end addresses
are identical, due to the empty basic block. Not a great problem on the
On Tue, 2005-08-09 at 11:02 +0200, Sebastian Pop wrote:
> I'm proposing to automate gcc's bootstrap & regtest: for each mail
> sent to [EMAIL PROTECTED], if 'From' is in gcc-developpers and 'body'
> contains a patch against some branch (ie. if it fails to apply to a
> branch, just drop it and warn
Hi Jan,
Your patch to mainline
http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00388.html
to defer handling of local statics has caused a regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22034
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22583
http://gcc.gnu.org/bugzilla/s
Summary:
This optimisation will allow GCC to access more than one object from
the same symbolic address. For example, suppose a section contains
two variables x and y, and x and y are close together. The
optimisation will create a common anchor point -- let's call it A --
and a
Hi Laurent,
Laurent GUERBY wrote:
>
> So I'm asking for project proposals, that is to say people that think
> that their volunteer time to work on these old machine (scripts,
> compiling, ... under the limit of minimal external bandwidth use) is of
> some significant benefit to some free softwar
This pass does simple forward propagation and simplification when
an operand of an insn can only come from a single def. The pass has a
very good potential of catching simplifications currently done by
inter-basic-block CSE (-fcse-follow-jumps and -fcse-skip-blocks) and
combine: however,
Can someone with approval privilege over the build system look at this,
and OK it? (it's a very simple patch)
I must apologize for the delay in handling this. This alternative patch
avoids that mingw is hardcoded in the makefiles. FWIW, it is also even
smaller,
3 files changed, 19 inserti
The consensus also seemed to be that it was just an aspect of a larger
problem that no good solution had been proposed to solve yet.
I am working on a fix that is the same as FX's, but does not pollute the
makefile with host triplets. I am not a maintainer, but this was my
primary objection t
36 matches
Mail list logo
