Hi Mikhail,
Thanks for the comments. I haven't updated my GDB yet and I will test it
again once I have a newer version GDB.
Yuhang
On 06/06/2015 09:31 PM, Mikhail Maltsev wrote:
On 07.06.2015 0:15, steven...@gmail.com wrote:
Dear GCC developers,
I have successfully compiled &
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
ed Var(TARGET_SCHED_PROLOG) VarExists
This appears of course to be wrong.
The latter probably ought to be TARGET_SCHED_EPILOG, if that exists, eh?
Apparently we also don't have test cases to actually verify that the
proper forms of these options are accepted and have the desired
effect...
Gr.
Steven
d to mis-matches of the GIMPLE
code that you read in, where "i" is a 1x100 array, and the re-constructed
variable "i" which would be a 10x10 2D array.
Has anyone working on LTO already thought of these challanges?
I'm all new to both DWARF and LTO, so forgive me if my rant doesn't make
sense ;-)
Gr.
Steven
are, or perhaps by using cfghooks to update the loop
information on the fly when a pass changes the CFG. It would be
helpful if Zdenek could give an example where a LOOP_HEADER node is
really the only way to help keep loop info accurate.
Gr.
Steven
, just for the sake of knowing how
many iterations a loop has. I wouldn't be surprised if some passes are
not prepared to handle that, and it sounds like just a really bad
idea.
Gr.
Steven
e are convincing technical reasons
for this kind of tree node, then your idea should be seriously
considered. Many people thought ASSERT_EXPRs were a really bad idea
too, when they were invented...
Gr.
Steven
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
is before the loop, IIUC, so
any code moved out of the loop would not affect the value of the use
operand for the LOOP_HEADER (by definition, because we're in SSA form
so DEFs inside the loop can't reach the LOOP_HEADER node).
Gr.
Steven
f gmp/ amd mpfr/ directories exist in
the toplevel, they are built along with GCC? I don't mean actually
including gmp and mpfr in the gcc SVN repo, but just making it
possible to build them when someone unpacks gmp/mpfr tarballs in the
toplevel dir.
Gr.
Steven
the instability problems you folks apparently have on
Macs?
Gr.
Steven
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
oblematic system
is glibc, maybe this can be fixed with a fixincludes hack?
That would be a massive hack.
Gr.
Steven
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
AIK 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_ssa, which is a horrible compile
time hog).
Gr.
Steven
ions of generics. We have
actually lowered the threshold locally.
Heh, I believe you! :-)
IMHO we should add a OPT_Wdisabled_optimization warning there, though.
Gr.
Steven
cision should be made by each pass individually, because
the pass manager is one abstraction level higher where it shouldn't
have to know the behavior of each pass.
Gr.
Steven
o find a fix.
Gr.
Steven
.1.0-release.patch
Any plans to merge this into the FSF trunk?
Gr.
Steven
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
s.
Is this something that could be easily fixed? E.g. can we make it
that flow_loops_find only performs transformations if asked to (by
adding a function argument for that)?
Gr.
Steven
ws up in binary
distributions.
That happens with all improvements that are implemented between
releases, so I don't see your point.
Gr.
Steven
needed for
the C-family languages. So why steal two pointers on the generic
struct tree_type? Are you planning to make all front ends use these
fields, or is it just additional bloat for e.g. Ada, Fortran, Java?
;-)
Gr.
Steven
ced by
'expand' is valid, i.e. you should be able to call recog() on all
insns and not fail.
Gr.
Steven
g to allow in patches that cause
test suite failures.
Frankly, I don't understand why you even ask. We have rules for
testing for a reason.
Gr.
Steven
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
compiler error: in cse_find_path,
at cse.c:5930
Please submit a full bug report,
with preprocessed source if appropriate.
Sic :-) A test case would be helpful.
Gr.
Steven
our ICE, so whether that would allow me to reproduce
the problem remains to be seen. If you have a preprocessed c-decl.c
that ICEs for you, that would be helpful. If not, I'll just have to
figure out a way to reproduce the ICE in some different way.
Gr.
Steven
see if that makes the problem go away for you.
Gr.
Steven
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
work on
SH?
Gr.
Steven
ing -funroll-loops.
Gr.
Steven
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
into the RTL
structures. The CFG is independent of the intermediate
representations for the function instructions. It has to be, or you
could have the same CFG data structures for both GIMPLE and RTL.
Hope this helps,
Gr.
Steven
't make the binary slower.
You're confusing theory and practice...
Gr.
Steven
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.
aces (especially, see libcall_stack in gcse.c:local_cprop_pass)
but are bound to fail miserably in others.
This is something I've been wondering for a while. Maybe someone can
give a definitive answer: Can libcalls be nested, or not?
Gr.
Steven
also won't understand why they get a performance drop on
their code.
You say you doubt it affects performance. Based on what? Facts
please, not guesses and hand-waiving...
Gr.
Steven
f
loops. We now assume that is handled at the tree level.
We do hoist MEMs out of loops, in gcse.c.
Gr.
Steven
jns .L5
gcc 4.3pre -O2:
.L2:
addl4(%rdi), %eax
addl$1, %edx
cmpl$100, %edx
movl%eax, (%rdi)
jne .L2
Thoughts?
What does the code look like if you compile with -O2 -fgcse-sm?
Gr.
Steven
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
time, patches don't get approved (see e.g. [1]), or they
get approved by middle-end maintainers who, strictly speaking, should
not be approving backend patches, as I understand it.
So, can the SC please appoint a new/extra i386 port maintainer?
Thanks,
Gr.
Steven
[1] http://gcc.gnu.org/ml/g
mpiler mark
the patterns in the expand file with the insns names from the md file?
There isn't.
You would have to walk over the insn and make recog assign them an insn code.
Gr.
Steven
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
is
used only inside ada/decl.c. But I haven't been able to figure out
myself yet how to avoid using TREE_COMPLEXITY there...
Thanks,
Gr.
Steven
ould not
show any real benefit. There were almost no opportunities for this
kind of optimization in GCC itself or in some benchmarks I looked at.
There appear to be more bit operations in RTL, so perhaps it is a
better idea to implement a known-bits propagation pass for RTL, with
the new dataflow engine.
Gr.
Steven
k).
For example, I don't know if this table would be required after
gimplification, and I also don't even know how GNAT translates its own
representation to GIMPLE (whole translation unit at once? function at
a time?).
Gr.
Steven
it doesn't seem unreasonable
to me to expect people to upgrade if their distribution ships with an
even older flex.
Gr.
Steven
want build2 for EQ_EXPR.
Gr.
Steven
o them, or in
their area of expertise, are not allowed to merge a branch or big
patches into the trunk during Stage 1.
Not that I *really* believe that would work... But skipping releases
is IMHO not really a better idea.
Gr.
Steven
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
gt; As always, the best way to ensure that it is addressed if it is
> important to you is to address it yourself, or pay someone to do so :-)
The fix is in mainline. The question is if it should be backported to
4.2.
ISTR Dan already made it clear more than once that the answer to that
question is a loud NO.
Gr.
Steven
n't know if there is another place where we can store this
value, but we definitely should. It is hugely disappointing to see
that, just when we're there with all other front ends, you've just
introduced another user of the tree_exp.complexity field.
Can you please help me fix this ASAP?
Gr.
Steven
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,
as a bad thing, he
wouldn't have done it.
Fine.
Then consider all my efforts to remove it finished.
Gr.
Steven
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
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
smiling then, instead of a sad looking smlley.
Gr.
Steven
in it ?
Am I missing something here ?
recog* should ice if what it gets passed is not an insn (i.e. !INSN_P).
Gr.
Steven
;-)
Make your insns match only one pattern.
Gr.
Steven
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
speedups in RTL passes if they start using the df
register caches, instead of traversing the PATTERN of every insn.
Gr.
Steven
n
cleanup_cfg)
Maybe I overestimate the cost of some of these items, and maybe I'm
missing a few items. But the message is the same: There is still
considerable potential for speeding up GCC using the new dataflow
infrastructure.
Gr.
Steven
mation" was in the
"future work" section for most practical compilers. So, perhaps
combine, as it is now, does not need DU/UD chains. But maybe we can
improve passes like this if we re-implement them in, or migrate them
to a better dataflow framework.
Gr.
Steven
CC 4.3:
"I would hope that the
community would accept the major structural improvement, even if it is
not a 100% complete transition, and that we can then work on any
remaining conversions in the fullness of time."
-- Mark Mitchell, 11 Feb 2007 [1]
:-D
Gr.
Steven
[1] http://gc
ew dataflow scheme. Existing
on trunk even now: fwprop, see, web, loop-iv. New on the branch: at
least auto-inc-dec.
Gr.
Steven
ecking
enabled, so, you know, just checking... ;-)
Thanks,
Gr.
Steven
favorite target, and see if they can trigger a
test suite failure?
Hope you can help,
Thanks,
Gr.
Steven
at I would like to see
released.
Not releasing GCC 4.2 is IMHO not a really good option. If we do that,
GCC 4.3 will contain so much new code that the number of not yet
uncovered bugs that our users may run into, may be larger than we can
handle.
Gr.
Steven
e ?
It is not always possible. GCC is certainly not designed for it. You
will have problems mostly with types and decls, which are hard to
reproduce from the intermediate representation once it has been
lowered to GIMPLE.
Gr.
Steven
That means a fallthru edge
in cfglayout mode doesn't have to go to next_bb. It can go to *any*
bb.
Gr.
Steven
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
icated dump files (either with `-d'
or `-fdump-rtl-PASS'), dump a representation of the control
flow graph suitable for viewing with VCG to `FILE.PASS.vcg'.
So my guess is that the syntax is VCG's.
Gr.
Steven
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
correct approach to fix that issue. The correct fix is able for the
register allocator to work correctly and fix up the IR.
Andrew, your truth isn't necessarily _the_ truth in this matter ;-)
Gr.
Steven
and which version of gcc you're
> using.
>
> Cheers,
>
Please, give me a mail address of developers.
You're already reaching pretty much all of them through this mailing list.
Gr.
Steven
ss to a copy in a
university library, but that copy has been removed from the collection
and, apparently, it's been disposed off :-(
Could someone scan those pages and send them to me, please?
Thanks,
Gr.
Steven
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
x27;d actually much more enjoy the
book if I would not have to print out almost as many pages as the book
has to get all the errata. IMVHO very few books have a poorer
quality/price ratio than Muchnick, which is why I have never found it
worth it to buy it before. There should be a law that says you can
freely copy books with too many errata ;-)
Gr.
Steven
"Modern Compiler Design" is another good introduction
text, especially if you're interested in various parsing techniques.
Gr.
Steven
lines changed is
used as the norm) you don't need to have a copyright assignment on
file. Such small changes are apparently not covered by copyright.
So if you could send a patch, that'd be quite helpful ;-)
Gr.
Steven
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
t 64 bits extra on 64 bits hosts...)
Gr.
Steven
m a larger 'tree' and a
slower compiler, because g++ basically abuses a shared data structure.
Gr.
Steven
so there's almost no win in
rewriting it (one lame tree code in c-common.def -- not worth the
effort ;-).
Gr.
Steven
we're going to be stuck with those
hacks forever, because nobody will have any motivation to fix the real
problem for once.
But oh well. SEP.
Gr.
Steven
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
at the test results tonight and commit the fix if there are
no new failures (and this one is fixed).
This failure is caused by problems with dead jump tables. There's
another bug (with a PR filed for it) that is also related to dead jump
tables. The fix I have should fix both these cases.
Gr.
Steven
still gives special meaning to the fallthrough edge.
This should not matter, but it does for some reason, and I'm
investigating this right now. I'll try to come up with a fix asap.
Gr.
Steven
ged yet. There was a patch a while back to change
libobjc to use libffi but I need to go back to it and review it (as it
was before I became a libobjc maintainer).
Do you mean this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00841.html
?
Gr.
Steven
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
ield. IMHO this is still the better
solution than the subcodes idea.
Gr.
Steven
y code), so I figure I have at
least a 3% speedup credit I can apply against the 9-bit code patch.
That brings this patch under 2% net slow-down, so we should just put
it in now :)
But only for C++.
I'm still in favor of the 9-bit code patch. But I think the slowdown
should not be taken so lightly as you appear to do ;-)
Gr.
Steven
ork, more autovect work, OpenMP 3.0, and the tuples and LTO
projects, etc., all requiring more tree codes.
And if there comes a point somewhen, where we can go back to a smaller
tree code field, it is much easier to do so with the 9-bit tree code
approach, than with subcodes.
Gr.
Steven
x bits could move to
language specific trees, could it?
Gr.
Steven
bcodes cost complexity. And the cost with checking enabled is
IMHO unacceptable.
Gr.
Steven
e code?
Gr.
Steven
On 3/22/07, Mike Stump <[EMAIL PROTECTED]> wrote:
is more obvious than the correctness of the subcoding. Thoughts?
I fully agree.
Gr.
Steven
1 - 100 of 1056 matches
Mail list logo
