Hi,
As far as I can tell, dwarf.h is not included anywhere in gcc/
or any of its subdirectories. Is there any reason not to remove
this file?
Thanks,
Gr.
Steven
On 10/18/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
Looking at rs6000.opt I have found that the above command line switch
variable is defined TWICE:
msched-prolog
Target Report Var(TARGET_SCHED_PROLOG) Init(1)
Schedule the start and end of the procedure
msched-epilog
Target Undocumented Var(
Hello,
I want to make gfortran produce better debug information, but I want to do it
in a way that doesn't make it hard/impossible to read back in sufficient
information for LTO to work for gfortran.
I haven't really been following the whole LTO thing much, but if I understand
correctly, the
On 10/25/06, Devang Patel <[EMAIL PROTECTED]> wrote:
> > However, various optimizer needs to know about this special tree node.
>
> not really (not any more than they know about other tree codes that are
> not interesting for them).
If we take an example of Jump Threading pass then it needs to
On 10/25/06, Devang Patel <[EMAIL PROTECTED]> wrote:
> > One way to achieve this is to mark n_1 (in your example) as
> > "do not dead strip because I know it is used" , kind of attribute((used)).
>
> This is what as I understand LOOP_HEADER is used for.
Big difference. New tree vs TREE_USED or D
On 10/25/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
it definitely is not the only way, and seeing the reaction of people,
I probably won't use it. The main reason for considering to use
the tree node for me was the possibility to make the number of iterations
of the loop as its operand, so tha
On 10/26/06, Devang Patel <[EMAIL PROTECTED]> wrote:
On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> You could use TREE_USED, but your suggestion implies that dead code
> should be retained in the program,
May be I misunderstood, but it is not dead code. Here i
On 10/26/06, Jeffrey Law <[EMAIL PROTECTED]> wrote:
> So, the passes that maniuplate loop structure need to know about
> LOOP_HEADER and others do not need to worry about LOOP_HEADER.
Passes which do code motions may need to know about it -- they don't
need to update its contents, but they may ne
On 30 Oct 2006 22:56:59 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
I'm certainly not saying that we should pull out GMP and MPFR. But I
am saying that we need to do much much better about making it easy for
people to build gcc.
Can't we just make it so that, if gmp/ amd mpfr/ directo
On 10/31/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
This question is not related to the apparent
instability and thus
low quality of GMP/MPFR at all.
This is the second time I see someone complain about GMP/MPFR
instability. What is this complaint based on? We've used GMP in g95
and later g
On 11/1/06, Joern RENNECKE <[EMAIL PROTECTED]> wrote:
With literally more than ten thousand lines of error messages per
multilib for fortran, that makes the test results unreportable.
So you don't report any error messages at all and leave us guessing?
Gr.
Steven
On 10/31/06, Roger Sayle <[EMAIL PROTECTED]> wrote:
I foresee no problems in getting the fwprop pass merged into mainline
this week. One detail I would like resolved however, is if you and
Steven Bosscher could confirm you're both co-ordinating your efforts.
Presumably, adding fwprop
On 11/1/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> According to the proposal, we will restore the GNU handling for
> "extern inline" even when using -std=c99, which will fix the problem
> when using glibc.
I am probably overlooking something, but if the only problematic system
is glibc, may
On 11/2/06, Roger Sayle <[EMAIL PROTECTED]> wrote:
Steven Bosscher might even have plans for reorganizing jump bypassing
already as part of his CSE/GCSE overhaul?
Yes, and one part of that plan is to pre-split all critical edges so
that you never have to insert on edges. That would mak
On 11/5/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I lean to leave the numbers static even if they do increase as time goes
> by. Otherwise you get two effects, the first optimizations get to be
> run more, and you get the wierd non linear step functions where small
> changes in some upst
On 11/5/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> AFAIK not one of the tree optimizers disables itself, but perhaps we
> should. The obvious candidates would be the ones that require
> recomputation of alias analysis, and the ones that don't update SSA
> info on the fly (i.e. require update_
On 11/5/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
I would like to point out that the central point of my proposal was to
have the compilation manager be the process that manages if an
optimization is skipped or not rather than having each pass make a
decision on it's own. If we have a centra
On 11/11/06, Paul Thomas <[EMAIL PROTECTED]> wrote:
Richard,
>
> If I had to guess I would say it was the forwprop merge...
The what? :-)
fwprop, see
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00141.html
If someone can confirm that this patch causes the drop, I can help
trying to find a fix.
On 11/15/06, Sebastian Pop <[EMAIL PROTECTED]> wrote:
There is a ddg in this patch if somebody wants the classic Allen&Kennedy
way to look at the dependences:
http://gcc.gnu.org/wiki/OptimizationCourse?action=AttachFile&do=get&target=loop-distribution-patch-against-gcc-4.1.0-release.patch
Any
On 11/17/06, Brendon Costa <[EMAIL PROTECTED]> wrote:
Is there something i should be doing before using EXPR_HAS_LOCATION() ?
Compile with -g, perhaps?
Gr.
Steven
Hi Zdenek, all,
I'm running into some troubles with an if-conversion pass that runs
after reload, where we have to avoid lifting insns across a loop
exit edge into a loop. ifcvt.c uses flow_loops_find to find loops
and mark all loop exit edges:
if ((! targetm.cannot_modify_jumps_p ())
&&
On 11/19/06, Eric Weddington <[EMAIL PROTECTED]> wrote:
> Use gcc head, __builtin_bswap and make sure the AVR backend
> implements the
> bswap rtl patterns.
There's the problem. You can't just glibly say "make sure the AVR backend
implements the bswap rtl patterns". There are precious few volunt
On 11/28/06, Doug Gregor <[EMAIL PROTECTED]> wrote:
* tree.h (TYPE_CANONICAL): New.
(TYPE_STRUCTURAL_EQUALITY): New.
(struct tree_type): Added structural_equality, unused_bits,
canonical fields.
If I understand your patches correctly, this stuff is only needed fo
On 12/1/06, Andrija Radicevic <[EMAIL PROTECTED]> wrote:
Hi,
I have noticed that the INSN_CODE for all patterns in the rtl dumps
.00.expand are -1 ... does this mean that the .md file was not used for the
initial RTL generation?
It was used, but it is assumed that the initial RTL produced by
'
On 12/5/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
My preference is to check in the TER code which exposes this bug, and
open a PR against the failure with this info. That way we don't lose
track of the problem, and someone can fix it at their leisure. Until
then there will be a testsuite fai
On 12/9/06, Alexey Smirnov <[EMAIL PROTECTED]> wrote:
typedef void* handle_t;
DEF_VEC_I(handle_t);
DEF_VEC_ALLOC_I(handle_t,heap);
Why DEF_VEC_I instead of DEF_VEC_P?
See vec.h.
Gr.
Steven
On 12/11/06, David Daney <[EMAIL PROTECTED]> wrote:
From svn r119726 (Sun, 10 Dec 2006) I am getting an ICE during
bootstrap on mipsel-linux. This is a new failure since Wed Dec 6
06:34:07 UTC 2006 (revision 119575) which bootstrapped and tested just
fine. I don't really want to do a regressio
On 12/11/06, David Daney <[EMAIL PROTECTED]> wrote:
Lets assume that it doesn't effect i686 or x86_64. Because if it did,
someone else would have been hit by it by now.
I'm sure it doesn't, I bootstrapped&tested on those targets (and on ia64).
So you would need a mips[el]-linux system in ord
On 12/11/06, Kaz Kojima <[EMAIL PROTECTED]> wrote:
It seems that the first tree dump which differs before and
after r119711 is .099t.optimized.
In that case, this is a different problem, probably caused by the new
out-of-SSA pass. But to be sure, I suggest you revert my CSE patch
and see if th
On 12/12/06, Kaz Kojima <[EMAIL PROTECTED]> wrote:
"Steven Bosscher" <[EMAIL PROTECTED]> wrote:
> In that case, this is a different problem, probably caused by the new
> out-of-SSA pass. But to be sure, I suggest you revert my CSE patch
> and see if that makes the
On 12/13/06, Joern Rennecke <[EMAIL PROTECTED]> wrote:
In http://gcc.gnu.org/ml/gcc/2006-12/msg00328.html, you wrote:
However, because the SH has delayed branches, there is always a guaranteed way
to find a register - one can be saved, and then be restored in the delay slot.
Heh, that's an inte
On 12/13/06, Benoît Jacob <[EMAIL PROTECTED]> wrote:
g++ -DUNROLL -O3 toto.cpp -o toto ---> toto runs in 0.3 seconds
g++ -O3 toto.cpp -o toto---> toto runs in 1.9 seconds
So what can I do? Is that a bug in g++? If yes, any hope to see it fixed soon?
You could try adding -funroll-
On 12/13/06, Sandeep Kumar <[EMAIL PROTECTED]> wrote:
Hi all,
I tried compiling the above two programs :
on x86, 32 bit machines.
[EMAIL PROTECTED] ~]# gcc test.c
Try with optimization enabled (try -O1 and/or -O2).
Gr.
Steven
On 12/13/06, Frank Riese <[EMAIL PROTECTED]> wrote:
One of my professors stated that a GCC Back End uses the Control Flow Graph as
its input and that generation of RTL expressions occurs later on.
That is not true.
What roles
do Back and Middle End play in generation of RTL? Would you conside
On 12/14/06, Benoît Jacob <[EMAIL PROTECTED]> wrote:
I don't understand why you say that. At the language specification level,
templates come with no inherent speed overhead. All of the template stuff is
unfolded at compile time, none of it remains visible in the binary, so it
shouldn't make the
On 12/30/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
Once upon a time, the --disable-bootstrap configure option wasn't
necessary. "make" built gcc, and "make bootstrap" bootstrapped it.
Is this behavior useful? Should we have it back again?
For me the current behavior works Just Fine.
On Sunday 31 December 2006 00:59, Jan Hubicka wrote:
> > Also I should mention, this also fixes a possible bug with libcalls that
> > are embedded in one another. Before we were just assuming if we have a
> > REG_RETVAL, then the previous REG_LIBCALL would be the start of the
> > libcall but that
On 12/31/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
Also, as I understand it this change shouldn't affect gcc's
SPEC benchmark scores, since they're typically done with -O3
or better.
It's not all about benchmark scores. I think most users compile at
-O2 and they also won't understand why they
On 05 Jan 2007 07:18:47 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
At the tree level, the problem is that the assignment to a[0] is seen
as aliasing a[1]. This causes the use of a[1] to look like a USE of
an SMT, and the assignment to a[0] to look like a DEF of the same
SMT. So in tree-
On 1/5/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
This is from the gcc-help mailing list. It's mentioned there for ARM,
but it's just as bad for x86-64.
It appears that memory references to arrays aren't being hoisted out
of loops: in this test case, gcc 3.4 doesn't touch memory at all in
the
On 1/5/07, David Edelsohn <[EMAIL PROTECTED]> wrote:
>>>>> Steven Bosscher writes:
Steven> What does the code look like if you compile with -O2 -fgcse-sm?
Yep. Mark and I recently discussed whether gcse-sm should be
enabled by default at some optimizat
Hi,
We currently do not have an active maintainer for the i386 port. The
only listed maintainer for the port is rth, and he hasn't been around
to approve patches in a while. This situation is a bit strange for
a port that IMHO is one of the most important ports GCC has...
In the mean time, pat
On 1/11/07, Andrija Radicevic <[EMAIL PROTECTED]> wrote:
Hi,
how could I find out from which patterns, in the md file, the 00.expand file
was generated (i.e. to map the patterns in the expand file with the ones in the
.md file)? Is there a compiler option/switch which would tell the compiler ma
On 1/12/07, Andrija Radicevic <[EMAIL PROTECTED]> wrote:
> On Thursday 11 January 2007 19:27, Steven Bosscher wrote:
> > On 1/11/07, Andrija Radicevic <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > > how could I find out from which patterns, in the md file, t
Hello,
Ada is the last user of the tree_exp->complexity field. Removing this
field should reduce GCC's memory usage by about 5% on a 64 bit host.
Could an Ada maintainer see if it possible to remove the use of this
field? I would think it shouldn't be too hard -- TREE_COMPLEXITY is
used only ins
On Thursday 18 January 2007 09:31, Jeffrey Law wrote:
> I haven't followed this thread that closely, but it seems to me this
> could be done in the propagation engine.
>
> Basically we keep track of the known zero, sign bit copies and known
> nonzero bits for SSA names, then propagate them in the o
On 1/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Ada is the last user of the tree_exp->complexity field. Removing
> this field should reduce GCC's memory usage by about 5% on a 64 bit
> host. Could an Ada maintainer see if it possible to remove the use
> of this field? I would think it
On 21 Jan 2007 22:13:06 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Ben Elliston <[EMAIL PROTECTED]> writes:
> I think it's worth raising the minimum required version from 2.5.4 to
> 2.5.31.
I want to point out that Fedora Core 5 appears to still ship flex
2.5.4. At least, that is what
On 1/23/07, Ferad Zyulkyarov <[EMAIL PROTECTED]> wrote:
But, as I noticed this function "build" is not maintained (used) by
gcc any more. Instead build, what else may I use to create a
conditional expression node?
Look for buildN where N is a small integer ;-)
I think you want build2 for EQ_EX
On 1/23/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already crossed
the 1 year barrier.
Heh.
Maybe part of the problem here is that the release manager isn't very
actively
On 1/25/07, Andreas Bogk <[EMAIL PROTECTED]> wrote:
"It's not my fault if
people write buggy software" is a lame excuse for sloppy engineering on
the part of gcc.
So basically you're saying gcc developers should compensate for other
people's sloppy engineering? ;-)
Gr.
Steven
On 1/25/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >Gcc 4.2 has a serious FP performace issue:
> >
> >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
> >
> >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
> >will be addressed.
>
> As always, the best way to ensure that it is a
Hello rth,
Can you explain what went through your mind when you picked the
tree_exp.complexity field for something implemented new... :-(
You know (or so I assume) this was a very Very VERY BAD thing to do,
if we are ever going to get rid of TREE_COMPLEXITY, which is a major
memory hog. We are
purpose of GNAT, please go
ahead and change it any way you see fit ;-)
No point in getting too sophisticated here: this is just a small hack to
avoid pathalogical compile-time behavior when compiling certain very complex
record types.
Are these test cases in the FSF test suite?
Thanks,
On 1/28/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
It's entirely reasonable to look for a way to get rid of this use of
TREE_COMPLEXITY, but things like:
> You know (or so I assume) this was a very Very VERY BAD thing to do
are not helpful. Of course, if RTH had thought it was a bad thing, h
On 1/28/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
OK, attached is the preliminary hack I created some time ago. After
some changes, it now bootstraps, but I haven't tested it yet. I'm
passing it as an RFC.
This patch is hereby withdrawn.
Gr.
Steven
On 1/29/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
I hope Steven accepts a little deal: he exits angry-stevenb-mode, and I
donate him this untested patch to remove TREE_COMPLEXITY from C++.
No, thank you.
I've decided long ago that I'm not going to work on anything unless
there is nobody wor
On 1/29/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Mon, Jan 29, 2007 at 03:24:56PM +0100, Steven Bosscher wrote:
> But then to have Mark *support* rth's change, that really shows the
> total lack of leadership and a common plan in the design of gcc.
There you go again.
Act
On 1/29/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Email is a tricky thing. I've learned -- the hard way -- that it's best
to put a smiley on jokes, because otherwise people can't always tell
that they're jokes.
I did use a smiley.
Maybe I should put the smiley smiling then, instead of a sa
On 2/1/07, Pranav Bhandarkar <[EMAIL PROTECTED]> wrote:
However, the internals only warn against using INSN_CODE on use,
clobber, asm_input, addr_vec, addr_diff_vec. There is no mention of
other members of the other members of RTX_EXTRA. or shouldnt
recog_memoized have an INSN_P check in it ?
Am
On 2/8/07, 吴曦 <[EMAIL PROTECTED]> wrote:
Thanks. But what does it mean by saying:
"Sometimes an insn can match more than one instruction pattern. Then
the pattern that appears first in the machine description is the one
used."
Basically it means, "Don't do that" ;-)
Make your insns match only
On 2/10/07, Jie Zhang <[EMAIL PROTECTED]> wrote:
The code I posted in my first email is from libgloss/libnosys/_exit.c.
It's used to cause an exception deliberately. From your replies, it
seems it should find another way to do that.
Maybe you can use __builtin_trap() ?
Gr.
Steven
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df infrastructure has a design flaw. It
extracts a lot of information about RT
On 2/13/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
> There are certainly performance issues here. There are limits on
> how much I, and the others who have worked on this have been able to
> change before we do our merge. So far, only those passes that were
> directly hacked into flow,
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Wow, I got so many emails. I'll try to answer them in one email in
Let us look at major RTL optimizations: combiner, scheduler, RA.
...PRE, CPROP,SEE, RTL loop optimizers, if-conversion, ... It is easy
to make your arguments look valid
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
I am just trying to convince that the proposed df infrastructure is not
ready and might create serious problems for this release and future
development because it is slow. Danny is saying that the beauty of the
infrastracture is just in imp
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> Why is it unacceptable for it to mature further on mainline like
>Tree-SSA?
>
>
Two releases one after another to avoid. No one real experiment to try
to rewrite an RTL optimization to figure out how def-use chain will work.
Vlad,
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Getting 0.5% and 11.5% slowness
(308sec vs 275sec for compiling SPECINT2000) does not seems reasonable
Just to be sure: Did you build with --disable-checking for both
compilers? I often find myself comparing compilers with checking
enable
Hello,
As some folks perhaps have noticed, my effort to make gcc use cfglayout
mode between expand and, roughly, sched1, have stagnated a bit. I am
completely stuck on a problem that I basically can't trigger. In other
words, I *know* I should expect problems if I make a certain change, but
I ha
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
On 2/21/07, Thomas Bernard <[EMAIL PROTECTED]> wrote:
Hello all,
As far as I know, GCC 4.x is easily retargetable for a new architecture.
I would be interested by source-to-source compilation with the GCC
framework. For instance, let's say the input language is C and the
output language is C ann
On 3/2/07, Andrey Belevantsev <[EMAIL PROTECTED]> wrote:
I have tried to reorganize the check so that the "e->src->next_bb ==
e->dest" condition is checked for all edges (see the patch below). Of
course, GCC does not bootstrap with this patch, triggering an assert of
incorrect fallthru block in
On 3/2/07, Andrey Belevantsev <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote:
> No. The condition you're checking is simply not true in cfglayout
> mode. The whole point of cfglayout mode is to get rid of the
> requirement that basic blocks are serial. That means a fallthru
On 3/4/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote:
hello ppl,
when I use -fdump-rtl-all with -dv I get CFG files.
where can I learn the syntax of that CFG files ?
it seems some kind of LISP language...
As the fine manual says:
`-dv'
For each of the other indicated dump files
On 3/4/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote:
Forgive me, I had mistake in the question - I meant the debug dump files
that we get just by using the -fdump-rtl-all. not the vcg files.
how can I understand their syntax ?
http://gcc.gnu.org/onlinedocs/gccint/RTL.html#RTL
Gr.
Steven
On 3/4/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 3/4/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
> Another important thing to do is to make the 1st scheduler register
> pressure sensitive.
I don't know how many times this has to be said, no this is not the
correct approach to fix th
On 3/6/07, W. Ivanov <[EMAIL PROTECTED]> wrote:
Paulo J. Matos wrote:
> On 3/6/07, W. Ivanov <[EMAIL PROTECTED]> wrote:
>> Hi, I use multiple inheritance in my project. In the child class i have
>> functions GetParam() and SetParam().
>> In the cpp-file I call GetParam() function, but I fell to S
Hi,
I found this old patch
(http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01669.html) that refers
to pages 202-214 of Muchnick's "Advanced Compiler Design and
Implementation" book. That book still is not in my own compiler books
collection because of its price. I used to have access to a copy in a
On 3/8/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
Could someone scan those pages and send them to me, please?
I received some private mails from people that are concerned about
copyright issues and all that.
I should have said I've actually ordered the book from Amazon (the
pr
On 3/8/07, Robert Dewar <[EMAIL PROTECTED]> wrote:
Dave Korn wrote:
> A few pages for personal study? That's fair use by any meaningful
> definition, no matter how much the RIAA/MPAA/similar-copyright-nazis would
> like to redefine the meanings of perfectly clear words and phrases in the
> en
On 3/9/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
o Muchnik book is a fat one. Muchnick's book is rather encyclopedia
of optimizations and can be considered as collection of articles with
many details (sometimes too many). But some themes (like RA and
scheduling) are described not dee
On 3/12/07, Unruh, Erwin <[EMAIL PROTECTED]> wrote:
In a private port I had the problem that reg_equiv_alt_mem_list did
contain the
same RTL as reg_equiv_memory_loc. This caused an assert in
delete_output_reload,
where these are compared with equal_rtx_p.
The list is build with push_reg_equiv_alt
On 3/12/07, Andreas Krebbel <[EMAIL PROTECTED]> wrote:
Hi,
gcc currently doesn't boostrap on s390 and s390x:
See http://gcc.gnu.org/ml/gcc-bugs/2007-03/msg00930.html
Gr.
Steven
On 3/12/07, David Edelsohn <[EMAIL PROTECTED]> wrote:
I thought that the Tuples conversion was suppose to address this
in the long term.
The tuples conversion is only going to make things worse in the short term.
Doug, isn't there a lang_tree bit you can make available, and use it
to m
On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
we are unavoidably
adding tree codes and we must solve the issue, one way or another.
Another real solution would perhaps be to not use 'tree' for front end
specific data structures in C++, and instead just define g++ specific
data structures
On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
Can I recommend something just crazy, rewrite the C and C++ front-ends
so they don't use the tree structure at all except when lowering until
gimple like the rest of the GCC front-ends?
The C front end already emits generic, so there's almost
On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
In my opinion, "visions" for a better
future do not help here.
No, I fully agree. I mean, imagine we'd have a long term plan for
GCC. That would be so out of line!
;-)
I'm not arguing against a practical solution. But to me at least it is
On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
compile this with -O2 -msse2 -mfpmath=sse, and this testcase should
compile to maxsd.
I'll look into it this weekend.
Gr.
Steven
On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
BTW: Your patch also causes
FAIL: gcc.dg/torture/pr25183.c -O0 (internal compiler error)
FAIL: gcc.dg/torture/pr25183.c -O0 (test for excess errors)
Yes. Known. I bootstrapped a fix and had a box test it yesterday.
I'll look at the test re
On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
The testcase is:
double x;
q()
{
x=x<5?5:x;
}
compile this with -O2 -msse2 -mfpmath=sse, and this testcase should
compile to maxsd.
This happens because a "fallthrough edge" is meaningless in cfglayout
mode, but ifcvt.c still gives special
On 3/16/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 3/16/07, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> My thinking is that if libobjc was changed then we could put in a
> depreciated message on these builtins for 4.3 and maybe remove them for
> 4.4.
libobjc has not changed yet. There was a
On 3/18/07, Florian Weimer <[EMAIL PROTECTED]> wrote:
I don't need the 32-bit libraries, so disabling their compilation
would be fine. --enable-targets at configure time might do the trick,
but I don't know what arguments are accepted.
Would --disable-multilib work?
Gr.
Steven
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
I went ahead and implemented this, to see what the real impact would
be. The following patch frees up TREE_LANG_FLAG_5, and uses that extra
bit for the tree code.
On tramp3d, memory usage remains the same (obviously), and the
performance results
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
GCC has also been getting improved functionality, better
optimizations, and better language support. Some of these improvements
are going to cost us at compile time, because better optimizations can
require more time, and today's languages requir
On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
As for the current problem, I think a 3% hit is pretty big. I didn't
find subcodes that ugly, so I guess I'm inclined to go with subcodes,
and avoid the hit.
We know that one still mostly unaddressed problem that tree-ssa left
us with, is po
On 3/20/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
> So the memory hit shouldn't be
> as big as e.g. going to 16 bit tree codes if that means increasing the size
> of most of the trees the compiler uses.
Yes, this is true.
But this could be solved if all LANG_TREE_x bits could move to
language
On 3/22/07, Joe Buck <[EMAIL PROTECTED]> wrote:
But these numbers show that subcodes don't cost *ANY* time, or the
cost is in the noise, unless enable-checking is on. The difference
in real-time seems to be an artifact, since the user and sys times
are basically the same.
The subcodes cost com
On 3/22/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
The results, compile time:
For what test case?
For a bootstrapped, --disable-checking compiler:
8-bit tree code (baseline):
real0m51.987s
user0m41.283s
sys 0m0.420s
subcodes (this patch):
real0m53.168s
user0m41.297s
sy
On 3/22/07, Mike Stump <[EMAIL PROTECTED]> wrote:
is more obvious than the correctness of the subcoding. Thoughts?
I fully agree.
Gr.
Steven
Hi,
I managed to commit a ChangeLog entry that included the entire patch,
and a change to ifcvt.c that shouldn't have been commited. I use a
little script for checkins, but I passed the wrong file names to it.
I've fixed both issues, but anyone who has checked out or updated from
SVN between now
1 - 100 of 961 matches
Mail list logo
