Jeff Law wrote:
> (*) Imagine something like this (and related variants)
>
> EXECUTE_IF_SET_IN_BITMAP (bitmap, 0, i, bi)
> {
> blah blah blah
>
> if (bitmap_empty_p (bitmap))
>{
> modify bitmap
> break;
>}
> more blah blah
> }
>
> We exit without iterating BI and thus miss
daniel.tian wrote:
>> Which means that reg 91 was spilled (ie, it did not get a hard register
>> assigned). You can verify this by looking at reg_equiv_mem[91] just
>> before this loop in reload1.c:
>>
>> /* This loop scans the entire function each go-round
>> and repeats until one repetition spill
Vladimir Makarov wrote:
Dave Korn wrote:
Albert Cohen wrote:
Unfortunately, the state of the art (more recent that the thesis
referenced in the original email, see Touati's web page) is limited to
basic block and software-pipelining scopes, and limited to scheduling.
Compared to the tasks c
Vladimir Makarov wrote:
So, now my questions: How much do you think could this could improve
compiled code speed? Would the current GCC/YARA benefit from such an
optimization pass at all?
I think nobody can answer the questions until it is implemented.
Agreed.
If you are going to work on t
Dave Korn wrote:
Albert Cohen wrote:
Unfortunately, the state of the art (more recent that the thesis
referenced in the original email, see Touati's web page) is limited to
basic block and software-pipelining scopes, and limited to scheduling.
Compared to the tasks currently managed by relo
Hi,
I'm back!
On Jun 21, 2009, Richard Guenther wrote:
> So I just tested tramp3d for memory usage
Thanks!
> -g -fno-var-tracking -fno-var-tracking-assignments: 615305 kB +18.5%
> -g -fno-var-tracking -fvar-tracking-assignments: 647773 kB +5%
> So keeping the VTA notes for tramp3d is an over
Hi,
we recently use GCC 4.3.3 to build userland application use ARM EABI,
for running on a ARM7TDMI, mmuless platform.
after explicit compile application with -fstack-limit-register=R10,
there is no binary change with or without this option. Does this option work?
another thing, in old GCC 3.x s
Greetings old friends. Long time no see. I have been off fighting
the spam wars for about the past 10-15 years, but I hope I'll still
be welcome in these parts.
I just dropped in again because I've got a bit of a C programming
difficulty, and if nobody else has a solution, I'd like to propose
> Which means that reg 91 was spilled (ie, it did not get a hard register
> assigned). You can verify this by looking at reg_equiv_mem[91] just
> before this loop in reload1.c:
>
> /* This loop scans the entire function each go-round
> and repeats until one repetition spills no additional hard reg
Alexander Monakov wrote:
On Fri, 26 Jun 2009, Joe Buck wrote:
On Fri, Jun 26, 2009 at 03:38:31AM -0700, Alexander Monakov wrote:
1. Add bool field `modified_p' in bitmap structure.
2. Make iterator setup functions (e.g. bmp_iter_set_init) reset it to
false.
3. Make functions that modify the
Dave Korn wrote:
Jeff Law wrote:
My biggest concern would be catching all the exit paths from the
gazillion iterators we use and making sure they all reset the readonly
flag. Ick...
Heh. GCC-in-CXX would solve that for us :) or we could implement
try...finally clauses
One
Dave Hudson wrote:
I did some more digging into this over the last couple of days and it
seems that the RA appears to over-emphasize the benefits of
propagating hard regs - in this case one or more hard regs that are
holding incoming function arguments. The RA ends up believing that
the har
Jim Wilson wrote:
Dobes wrote:
I am working on a port to an architecture with some strict rules. The
restriction that I am unable to figure out how to enforce is a base
register
that is allowed in the destination operand, but not in a source operand.
GCC does not provide any way in the old
daniel.tian wrote:
>> This looks like a different problem. What pass generates insn 17? What
>> does insn 17 look like in the prior pass? If r14 is your stack/frame
>> pointer, this might point to a problem in how your port interacts with
>> register allocation/reload as reload can replace a pseudo
daniel.tian wrote:
>
>
>
>> This looks like a different problem. What pass generates insn 17? What
>> does insn 17 look like in the prior pass? If r14 is your stack/frame
>> pointer, this might point to a problem in how your port interacts with
>> register allocation/reload as reload can replace
daniel tian wrote:
>> The compiler should work with or without defining LEGITIMIZE_RELOAD_ADDRESS.
>> It's often difficult to write a correct LEGITIMIZE_RELOAD_ADDRESS without
>> knowing the internals of how reload works. Therefore, I strongly recommend
>> first writing the port without LEGITIMI
daniel tian wrote:
> Only do using R0. Like the following with loading 0x12345:
>
> MOVI 0x2345 -L //To load the lower 16bit data
> MOVI 0x1 -H //Load the up 16bit data
>
OK. So it appears to me like R0 needs to be an intermediate secondary
reload for register anyt
Snapshot gcc-4.4-20090630 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090630/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Tue, 30 Jun 2009, Richard Sandiford wrote:
> The 4.5 C constant expressions patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01061.html
>
> stopped us from emitting the warnings expected by gcc.dg/fixed-point/addsub.c.
> We used to handle the warnings in parser_build_binary_op, but
Messrs.
We needed that they cotizen to us with URGENCY, the following elements.
It 1 Amount 245
Brief description SUPPORT|ASTM A36|RT|PLN05399M934
Extensive description SUPPORT, TABLE, MADE IN STEEL ASTM A-36, PAINTED
COLOR RAL-2002,|| ACCORDING TO PLANE RT. #053-99-M-934
Best Regards
Claudio
On 06/30/2009 07:26 PM, Steven Bosscher wrote:
What to do, oh what to do...
Does it work to:
mv include/elf include/elfold
svn up include/elf
cp -R include/elfold/* include/elf
rm -rf include/elfold
svn revert include/elf/dwarf2.h
?
Paolo
The 4.5 C constant expressions patch:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01061.html
stopped us from emitting the warnings expected by gcc.dg/fixed-point/addsub.c.
We used to handle the warnings in parser_build_binary_op, but now that
fixed-point constant folding is delayed until c_f
2009/6/30 Larry Evans:
>
> So... I read `man gcc` which claimed passing "CFLAGS=" on the
> command line is how to do this. Well, since in my case was
> '-g3 -O0' I had to pass it as CFLAGS='-g3 oO0'.
http://gcc.gnu.org/install/build.html
If you wish to use non-default GCC flags when compiling t
Hi Tom, all,
Since this commit by Tom of include/elf/ I can't update svn in a
combined tree anymore
(http://gcc.gnu.org/viewcvs/trunk/include/elf/dwarf2.h?revision=149070&view=markup).
What I have, is a combined tree as described in
http://gcc.gnu.org/simtest-howto.html.
I usually just run gcc_u
Ian Lance Taylor wrote:
> I recently added the new -Wjump-misses-init warning option. It warns
> when a goto or switch jumps into the scope of an initialized variable
> without actually initializing the variable. I added the warning to
> -Wall because it seems to me to fit the criteria of -Wall:
Rainer Emrich wrote:
> It's the same as described in the following thread
> http://gcc.gnu.org/ml/gcc/2009-06/msg00594.html
>
> I used binutils-cvs and gcc-trunk as of today and gcc-4.4.1 with binutils-cvs
> as
> of today as bootstrap compiler.
Hi, yeah, I've tracked this one down to several
g...@coreland.ath.cx wrote:
> Hello.
>
> I opened this issue a while back:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40310
>
> I was told that I needed to run the test suite in order for the patches
> to be accepted. I had trouble getting the test suite to run but have
> now managed (tu
Hello.
I opened this issue a while back:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40310
I was told that I needed to run the test suite in order for the patches
to be accepted. I had trouble getting the test suite to run but have
now managed (turned out to be a problem specific to my system
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It's the same as described in the following thread
http://gcc.gnu.org/ml/gcc/2009-06/msg00594.html
I used binutils-cvs and gcc-trunk as of today and gcc-4.4.1 with binutils-cvs as
of today as bootstrap compiler.
Rainer
-BEGIN PGP SIGNATURE-
Hello All,
This discussion is triggered by the one-line patch
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02227.html (I might have
already written some email on this in a different way). I believe it has
been at least informally discussed at the GCC summit a few weeks ago
(which I was not ab
I am pleased to announce that the GCC Steering Committee has
appointed Tobias Grosser as a Graphite maintainer.
Please join me in congratulating Tobi on his new role.
Tobi, please update your listing in the MAINTAINERS file.
Happy hacking!
David
I'm trying to debug the compiler. I've gotten the gcc/Makefile to
compile the programs with '-g3 -O0' so that no function called are
rm'ed (the -O0 option) and so that I can see what macros to (the -g3
option). However, I had to trial-and-error edit the Makefile's to
change what I thought was the
On Mon, Jun 29, 2009 at 9:59 AM, Olivier Hainque wrote:
> Working on a collect2 related patch resubmission for ppc-aix, I
> stumbled on regressions in the c++ series for a problem unrelated to
> my change. Not sure how you'd typically deal with these, so providing
> the datapoints here.
>
> tmpdir-
Vladimir Makarov wrote:
I've just checked the thesis again. I don't think decreasing register
pressure through spilling will work well. First of all Polleto linear
scan RA is worse than Chaitin-Briggs approach. Even its major
improvement extending linear scan is worse than Chaitin-Briggs
ap
34 matches
Mail list logo
