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
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
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,
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
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 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
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 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
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
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
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
>
> 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:
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
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
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
[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
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.
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
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 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
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
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
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
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
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 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
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 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
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_
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, 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
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
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
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
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
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
36 matches
Mail list logo
