According to our records, your request has been resolved. If you have any
further questions or concerns, please reply to this email.
Jan,
Here are the testcases for inlining improvements we've discussed on IRC a
couple of days ago.
Current mainline handles inline-devirt-1.C and inline-devirt-5.C cases. With
my w-i-p patches to teach inlining heuristics about devirtualization
opportunities (also attached) inline-devirt-2.C,
2010/12/23 Vladimir Makarov :
> On 12/23/2010 03:13 AM, roy rosen wrote:
>>
>> Hi All,
>>
>> I am looking at the code generated by my port and it seems that I have
>> a problem that too many copies between registers are generated.
>> I looked a bit at the register allocation and wanted to verify th
Hello,
I'm trying to make a port to a new architecture work on the current gcc. There
hasn't been any work
done on this port since Nov-2008.
The compiler builds now, but I'm getting an ICE when I try to compile a program.
-
X:
--
(mem/f/c/i:PSI (plus:PSI (reg/f:PSI 87 virtual-stack-var
Christian Grössler writes:
> Looking at the history of optabs.c, the MODE_CC test was introduced when
> merging the cond-optab branch
> to main. I didn't find a description of the cond-optab branch and what it was
> supposed to do.
This is the description of the now-merged cond-optab branch, f
On 28.12.10 00:22, Ian Lance Taylor wrote:
Christian Grössler writes:
Looking at the history of optabs.c, the MODE_CC test was introduced when
merging the cond-optab branch
to main. I didn't find a description of the cond-optab branch and what it was
supposed to do.
This is the description
Christian Grössler writes:
> Sorry, the line numbers in the ICE are wrong, since I added some debug
> messages.
> The abort happens here in prepare_cmp_insn():
>
> /* Handle a libcall just for the mode we are using. */
> libfunc = optab_libfunc (cmp_optab, mode);
> gcc_assert
