at can be removed? The reason
> why I am asking is that I would like to experiment with this front-end a
> little bit.
You could rewrite the parser... ;-)
Gr.
Steven
wo depend on the CFG inliner.
> # Profiling on Trees, gcov on Trees (1.2)
At least the tree value profiling bits of this are already in CVS.
Gr.
Steven
On Sunday 08 May 2005 06:11, Kazu Hirata wrote:
> I created an array with more than one thousand elements. I still did
> not see a RANGE_EXPR in the array's CONSTRUCTOR. How do I get a
> RANGE_EXPR in a CONSTRUCTOR?
IIRC G++ only builds RANGE_EXPRs for all-zero constructors.
Gr.
Steven
is kind of address arithmetic to the tree
optimizers? Should we?
For some of the other constant propagations that RTL GCSE does,
I have filed PR21451. I also found a few where expanding a tail
call exposed new constants, more about that in a minute.
Gr.
Steven
e do not know if the call we marked as a
tail call will indeed be expanded as one, so just adding a return
at the end of BLOCK 3 may pessimize the code. Maybe we can do it
somewhere late in the tree optimizer path, but before the final
constant propagation pass?
Gr.
Steven
of
> > whether the array is declared with const, so that's not useful to
> > determine whether the array is declared with const.
>
> cp_type_quals (type) & CP_QUAL_CONST
I believe Kazu is not looking at these constructors in the front
end, but in the middle-end. ;-)
Gr.
Steven
On Sunday 08 May 2005 22:19, Richard Henderson wrote:
> On Sun, May 08, 2005 at 10:06:04PM +0200, Steven Bosscher wrote:
> > A test case that shows what is going on is this:
> >
> > extern char *x;
> > void
> > foo (char *a, char *b)
> > {
> > if
On Sunday 08 May 2005 21:00, Richard Henderson wrote:
> On Sun, May 08, 2005 at 04:33:28PM +0200, Steven Bosscher wrote:
> > Can we expose this kind of address arithmetic to the tree
> > optimizers? Should we?
>
> No and no.
Clear enough :-)
> I've always believe
,628,016.WKU.&OS=PN/5,628,
> > 016&RS=PN/5,628,016
>
> http://snipurl.com/et1w
And FWIW, patches exist outside the FSF tree to support SEH, see e.g.
http://reactos.csh-consult.dk/index.php?page=gccseh
Gr.
Steven
bits in this commit:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00621.html
Gr.
Steven
n embedded targets focus
on code quality and new features, instead of on the compile time
and memory footprint issues that you would expect their group of
users to complain about.
Gr.
Steven
On Monday 16 May 2005 17:53, Richard Earnshaw wrote:
> On Mon, 2005-05-16 at 16:17, Steven Bosscher wrote:
> > On Monday 16 May 2005 16:53, Scott Robert Ladd wrote:
> > > The problem is, a bloated GCC has no consequences for the majority of
> > > GCC developers -- thei
On Monday 16 May 2005 20:26, Karel Gardas wrote:
> On Mon, 16 May 2005, Steven Bosscher wrote:
> > Just for the record, attached is gcctest's history of the overall
> > memory requirement at -O[0123] for combine.i, insn-attrtab.i, and
> > generate.ii (aka PR8361). Ho
ty don't give a s*** about.
It is IMVHO rediculous that the list where GCC is bashed the most
is the GCC list itself.
Gr.
Steven
On Tuesday 17 May 2005 00:07, Joe Buck wrote:
> On Mon, May 16, 2005 at 10:15:29PM +0200, Steven Bosscher wrote:
> > On Monday 16 May 2005 20:26, Karel Gardas wrote:
> > > On Mon, 16 May 2005, Steven Bosscher wrote:
> > > > Just for the record, attached is gc
On Tuesday 17 May 2005 02:53, Ralf Corsepius wrote:
> On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
> > On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
> > > On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
> > > > Until package maintainers tak
On Tuesday 17 May 2005 02:59, Steven Bosscher wrote:
> On Tuesday 17 May 2005 02:53, Ralf Corsepius wrote:
> > On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
> > > On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
> > > > On Mon, 2005-05-16 at 1
On Tuesday 17 May 2005 03:16, Joe Buck wrote:
> On Tue, May 17, 2005 at 03:11:03AM +0200, Steven Bosscher wrote:
> > On Tuesday 17 May 2005 02:59, Steven Bosscher wrote:
> > > Oh, and how helpful of you to post that patch to gcc-patches@ too...
> > > NOT!
> >
>
On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
>
> > No, I just don't build gfortran as a cross. There are many reasons
> > why this is a bad idea anyway.
>
> Such as?
For one thin
On May 17, 2005 12:21 PM, Ralf Corsepius <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote:
> > On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 2005-05-17 at 01:59, Steven Bosscher wr
er pressure in tree-outof-ssa,
so fixing this may be hard. Perhaps we should disallow TER to combine
things across loads, or limit the maximum number of expressions it is
allowed to combine...
Gr.
Steven
pools of et-forest :-)
Gr.
Steven
On Sunday 22 May 2005 00:16, Jan Hubicka wrote:
> (not sure of -fdump-rtl-expand ever worked, but I
> might try to restore it if it did).
It very definitely did work, and quite nicely too.
Try -fdump-rtl-expand-details.
Gr.
Steven
On Monday 23 May 2005 18:20, Jeffrey A Law wrote:
> I'd much rather take the time to fix all these problems, install the
> fixes along with the checking bits to ensure they never come back
> rather than to iterate on each one separately.
And int the mean time, things stay broken?
Gr.
Steven
d because
of this VRP bug here: http://gcc.gnu.org/PR21332 ?
Gr.
Steven
in or cos
> is an angle. They are just functions! Suppose you're evaluating an
> approximation of a Fourrier series expansion.
It would, in a way, still be a phase angle ;-)
Gr.
Steven
()? What kind of
strange indirect jump would that be? And shouldn't the check just use
computed_jump_p() if that is what it is looking for??
Gr.
Steven
e the value of the actural loop count after
> SMS schedule, and assign its value to 'ar.lc'.
Actually, should SMS just not update the loop register in place?
I never figured out why it tries to produce a sub insns (using
gen_sub2_insn which is also wrong btw).
Gr.
Steven
description.
No, the machine description is fine. There simply are no sub and add
insns for ar.lc (loop counter reg on ia64).
Gr.
Steven
way of doing this at present. I could be
> wrong, though. We could certainly add logic to compute this, using
> techniques similar to those in target-supports.exp.
Doesn't "is-effective-target ilp32" test for 32 bits int?
Gr.
Steven
> Is this supposed to happen?
It happens, iiuc, when people merge branches as a whole instead of
piece-wise.
Gr.
Steven
e number for CSE1 is this high. But 820 out of 11686 is
still only 7% of the times that CSE1 needs to rebuild labels.
Gr.
Steven
where you dismissed another wrong-code
bug (PR21173) as just another .0 bug?
> * 21847: DCE over-eagerness.
I'll have a look at this one right now.
Gr.
Steven
On Sunday 05 June 2005 19:29, Mark Mitchell wrote:
> Steven Bosscher wrote:
> > On Sunday 05 June 2005 19:18, Mark Mitchell wrote:
> >>The reason that this release is slightly ahead of schedule is because of
> >>a relatively frequently-encountered wrong-code regre
esting to see what they'll do, but it would be pretty
surprising to see them drop GCC right now, unless they have an Ace up their
sleeve (i.e. a non-GCC ObjC compiler). But it is not like the end of the
world if Apple does not support GCC any longer, and if they will, well, I
guess it _could_ be good for most of us, no? ;-)
Gr.
Steven
He could try and join the hack-the-xbox effort :-)
Gr.
Steven
;
> Is this an addition for a scheduled (pre)release or i just can't find it in
> the released gcc-4.0.0 ??
The VRP pass is inside tree-ssa-dom.c for GCC 4.0.
GCC 4.1 has a much more powerful VRP pass, which is not related
to the DOM pass.
Gr.
Steven
;-)
And some more information in the mean time:
Starting program: /home/steven/devel/build-test/gcc/cc1 -mthumb t.c -O
foo
Breakpoint 1, fancy_abort (file=0xa19258
"../../mainline/gcc/tree-ssa-address.c", line=585,
function=0xa192d3 "create_mem_ref") at diagnostic.c:588
5
Hi,
This adds a link in "Further readings" to the Wikipedia page
about IEEE 754r. Seems interesting enough...
The change to the existing link is necessary to make the page
render without unnecessary spaces before "Differences".
OK?
Gr.
Steven
Index:
tium 4
NetBurst uops buffer and all that other crap in this microarch that
behave so very unpredictably (especially for gcc)?
- icc/ifc just are "optimized for SPEC" to make their compiler look
really good compared to others on this industry-standard benchmark,
while for Joe User's code the difference is not nearly this large?
Gr.
Steven
hey care about, and you can't force them to care
about your itches if they really just don't care. Persisting upsets
people, and that is perfectly normal I think.
Gr.
Steven
e your points by now, don't
you think?! Can we return to discussions about the development of GCC,
which is what this list is for? Discussions at the meta-level are OK,
but this one is going round in circles.
Geez. I've never seen such long nonsense threads before on [EMAIL PROTECTED]
Gr.
Steven
ng about? :-) Putting the collected
wisdom of previous threads on CW/MS assembler syntax is also useful
I suppose, so we have a place to point people at when this question
comes up again of why GCC doesn't support this already...
Gr.
Steven
ery constructive one.
Gr.
Steven
iven
> that it wasn't very well documented on the web site, it appeared to be a
> private channel for existing GCC developers.
Newbie GCC developers are also existing GCC developers.
Gr.
Steven
red before
it is called (see the SWITCH_EXPR case, "gcc_assert (!label_bb->aux )").
You must have seen this if you tested your patch with checking enabled, the
patch broke fortran on all platforms.
Can you please fix this? (It is also http://gcc.gnu.org/PR22100)
Gr.
Steven
oblem on amd64-*-freebsd. I is quite
> annoying that someone would make a change to the backend
> without testing it.
Indeed.
See http://gcc.gnu.org/ml/gcc/2005-06/msg00728.html...
Gr.
Steven
by all means, pretty _please_, get your story consistent or quit arguing.
And frankly, I _do_ expect a patch from you, now that PR323 is no longer
marked invalid. If you don't post a patch, that will be the ultimate proof
that you are just trolling here.
Gr.
Steven
h the mess of a couple of years ago, we are much
better off now.
Gr.
Steven
d") loop
optimizer is. Or otherwise jump bypassing should be moved to
after loop2. There is a problem report about this in bugzilla.
Gr.
Steven
unction your poorer code is in. You
could e.g. try to make the .optimized dump of that function compilable
and see if the problem shows up there again. Then work your way down
to something small.
Gr.
Steven
1608-1612) to kill early-clobbered
operands is precisely the same as what is done just a few lines
earlier (lines 1595-1598). Is this a thinko or is this necessary for
some non-obvious reason??
Gr.
Steven
tionally where it actually can?
Because it disallows compiler transformations? E.g. suddenly a
loop with a signed variable as the loop counter may wrap around,
which that means some transformations that are safe now would
no longer be safe.
Gr.
Steven
suddenly countable loops are turned into noncountable loops, overflow
can occur, dependencies may be introduced that never happen in reality,
and so on.
Anyway, I've started a SPEC run with "-O2" vs. "-O2 -fwrapv". Let's see
how big the damage would be ;-)
Gr.
Steven
On Tuesday 28 June 2005 14:02, Ulrich Weigand wrote:
> Steven Bosscher wrote:
> > Anyway, I've started a SPEC run with "-O2" vs. "-O2 -fwrapv". Let's see
> > how big the damage would be ;-)
>
> Please make sure to include a 64-bit target, w
On Tuesday 28 June 2005 14:16, Paul Koning wrote:
> >>>>> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
>
> Steven> Indeed. Frankly this "seems likely" guess confuses me. It
> Steven> is already well known that using unsigned
On Tuesday 28 June 2005 14:34, Michael Veksler wrote:
> Steven Bosscher <[EMAIL PROTECTED]> wrote on 28/06/2005 15:30:27:
> > On Tuesday 28 June 2005 14:16, Paul Koning wrote:
> > > I must be missing something.
> >
> > Yes.
> >
> > > Unsigned h
On Tuesday 28 June 2005 14:09, Steven Bosscher wrote:
> On Tuesday 28 June 2005 14:02, Ulrich Weigand wrote:
> > Steven Bosscher wrote:
> > > Anyway, I've started a SPEC run with "-O2" vs. "-O2 -fwrapv". Let's
> > > see how big the damage
ks is a serious regression.
Even without exercising the heavy-ammo loop optimizers, -fwrapv is
a serious performance-hurter.
Gr.
Steven
RUE 8 (nil))
(nil))
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?
Gr.
Steven
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 who actually understands the
scheduler will have to figure out a fix :-/
Gr.
Steven
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 b
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
mem with -O2 and more.
If the code is obsolete as rth suggested, wouldn't it be even better to
remover all traces of it, i.e. clean up all places where flag_force_mem
is checked?
Gr.
Steven
that got fixed with -fforced-mem. And
besides, it is better to fix bugs than to work around them.
Making the option a nop, issuing a warning in 4.1 and removing the
option completely for gcc 4.2 looks like a very reasonable approach to
me.
Gr.
Steven
that -O0 -fschedule-insns works at all.
Gr.
Steven
. It is
interesting to see that the "(p6)" checks are in front of those
insns, when in fact we already know that p6 must be true if the
branch is taken (because in gcc, p7 not set implies p6 set ;-).
Are predicate checks free, or should there be some post-pass to
clean up this kind o
ave worked. Ever.
And when he fixed it, sched_get_condition started working for the first
time, which of course uncovered a bunch of bugs latent up till then.
Gr.
Steven
the end of
a basic block when doing intra-block scheduling. The add_dependence
changes are necessary because it was literally impossible to add this
kind of dependency. add_dependence simply refuses to add dependencies
with mutually exlusive conditions.
I have not even tried to compile this ye
ttribute to those instructions that cannot be in delay slots,
and change this define_delay to disallow instructions with that attr?
Gr.
Steven
On Monday 04 July 2005 12:41, Balaji S wrote:
> _On 04-Jul-2005 15:31, Steven Bosscher san wrote_:
> > Add an attribute to those instructions that cannot be in delay slots,
> > and change this define_delay to disallow instructions with that attr?
>
> Any instruction other th
ismissed as
not necessary pretty clearly explained that, and I'm not sure why you
just ignored my explanation.
If you remove that #if 0 from sched_get_condition, you will break all
cond_exec targets except ia64.
Gr.
Steven
tional re-implementation of the IBM stack
smashing protection patch described here:
http://www.research.ibm.com/trl/projects/security/ssp/
This version is *much* less intrusive than the IBM version:
//
Looks like a re-implementation to me, then! ;-)
Gr.
Steven
tor wants to add it. If you
think it should be moved else where, move it elsewhere.
Gr.
Steven
w, as in
right here right now; or go through months of patch nit-picking a 12
line patch and work incrementally.
2) they don't have to write a copyright assignment and go through other
barriers.
Personally I strongly prefer working on the wiki over working on the
GCC manual for internals stuff.
Gr.
Steven
t I'd prefer that rather than flipping to Twiki.
So, contribute to the manual then. And let the folks who prefer to
work on the wiki work on the wiki.
Unless we are going to require reviewing for wiki changes now, too,
there is no point in this entire discussion. And if we are going
to require reviewing for the wiki, there is no point in having the
wiki.
Gr.
Steven
not my intention to sign over the various Wiki contributions I have
made to the FSF.
Gr.
Steven
On Monday 11 July 2005 16:50, Bernd Schmidt wrote:
> Steven Bosscher wrote:
> > I guess that, apart from the legal discussion of whether this enough,
> > such a statement would not apply to existing content. It was certainly
> > not my intention to sign over the various Wiki
nder a free license.
In practice, people have already contributed significants amount of
documentation as comment because they disagree with the GFDL.
Gr.
Steven
*sigh*
> To play the Devil's advocate: One could argue that someone contributing
> to the GCC code under the GPL does not agree with the GFDL, and therefore
> the FSF can't live up to its promise (that iirc it makes in the copyright
> assignment) to keep the code under a free license.
... if comm
ternals manual in without review. Is that something people are
willing to consider and discuss?
Gr.
Steven
On Tuesday 12 July 2005 00:06, Gabriel Dos Reis wrote:
> Steven Bosscher <[EMAIL PROTECTED]> writes:
> | Another idea that was coined on IRC is to have reviewing and commit
> | after approval rules for the user manual, but to allow patches to the
> | internals manual in withou
he thread starting
here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01936.html.
Finally, you've apparently used grep to find all the places where
PARAM_MAX_INLINE_INSNS_SINGLE and its friends are used, but you hve
missed the ones in opts.c and maybe elsewhere.
Good luck, and thanks for working on this difficult stuff.
Gr.
Steven
aram_value ("max-inline-insns-single", 5);
set_param_value ("max-inline-insns-auto", 5);
flag_inline_functions = 1;
(...)
}
You didn't update those two.
Gr.
Steven
y the sixtrack and parser increases. I have not looked
at the SPEC scores, but eon miscompares now.
Gr.
Steven
On Sunday 17 July 2005 19:48, Daniel Berlin wrote:
> On Sun, 2005-07-17 at 18:05 +0200, Steven Bosscher wrote:
> > Hi,
> >
> > There are some huge compile time regressions between 16/7 and 17/7, most
> > likely due to the IPA work from Kenny and Dan. These are the
names disappearing underneath
me) that I never found time for to investigate.
I've appended the last incarnation of my hack that I could find in my
local mail archive. This was supposed to help implement the first two
points of (b). Actually linking things together is something I never
On Wednesday 20 July 2005 18:53, girish vaitheeswaran wrote:
> I am seeing a 20% slowdown with feedback optimization.
> Does anyone have any thoughts on this.
My first thought is that you should probably first tell what compiler
you are using.
Gr.
Steven
gt; howto.
Hmm, I've never seen any discussions about this on [EMAIL PROTECTED] Could you
give some links to messages in the mailing list archives that you
may have found?
Gr.
Steven
;s so difficult to find
information on this option.
---
Dr. Gay Steven
Centrale de Compensation
Coordination Informatique et organisation (CIO)
CH-1211 Geneva 2 - Switzerland
Tel : +41 22 795 97 30
Fax: +41 22 795 92 90
[EMAIL PROTECTED]
Hi,
You added the stack protector patch on May 12, but Joseph already
pointed out then that you did not add user documentation (see his
mail: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01235.html).
Can you add this documentation please?
Gr.
Steven
should of course be
[EMAIL PROTECTED] Who can fix this?
Gr.
Steven
uleâ:
> reorg.c:4237: error: invalid lvalue in increment
> reorg.c:4312: warning: incompatible implicit declaration of built-in
> function âmemsetâ
> make: *** [reorg.o] Error 1
>
>
> Can someone tell me the right set of flags for compiling 176.gcc?
> I am using "-DUSG -O3"
See http://www.spec.org/cpu2000/issues/, look for gcc.
Gr.
Steven
the curious...
Gr.
Steven
want me to miss the
> > patches to branch.
>
> Forgot to mention, the tag is ipa-branch ;)
I guess the web pages should be updated with something like the attached?
Gr.
Steven
Index: cvs.html
===
RCS file: /cvs/gcc/wwwdo
t; That will only help with the fortran problem,
That is the only problem we have to care about, isn't it? The C++
front-end folks can fix their own front end.
Gr.
Steven
like?
The i386 backend uses it. Just look for cgraph in i386.c. Note that
changing the calling conventions does not change the sets of call-used
and call-clobbered registers.
Gr.
Steven
I have no idea how much, or if it is at all feasible. In
any case, you should assume that it is a much bigger job than just
modifying the call expander.
Gr.
Steven
aused this?
Gr.
Steven
[1]
http://www.suse.de/~aj/SPEC/amd64/CFP/summary-britten/200_sixtrack_recent_big.png
[2]
http://people.redhat.com/dnovillo/spec2000.ppc64/gcc/200.sixtrack-run-ratio.png
[2]
http://people.redhat.com/dnovillo/spec2000.i686/gcc/200.sixtrack-run-ratio.png
lem you're seeing go
> > away, just as an experiment...
>
> Couldn't it also make it much worse?
Depends on what the scheduler does with the memory references
vs. register pressure. I have no idea.
Gr.
Steven
201 - 300 of 1056 matches
Mail list logo
