> 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 with an
> equivalent m
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 GO_IF_LEGITIMATE_ADD
daniel.tian wrote:
Hi,
I check the MIPS and ARM, both those cc1 files opened in Insight debug tool
contain the mips.md and arm.md file. It is convenient while break point can
be set in it.
My port md file doesn't appear in the insight.
The mips.md and arm.md file end up in the debug info becaus
Thanks. I thought that if I just try to disallow this in the operand
predicates/constraints in my define_insn patterns, I would end up
getting an unrecognizable instruction error. I will try that and see
what happens.
Brice
On Jun 29, 2009, at 5:11 PM, Ian Lance Taylor wrote:
Dobes wr
2009/6/29 Jan Engelhardt :
>
> On Monday 2009-06-29 16:09, Manuel López-Ibáñez wrote:
>>2009/6/29 Richard Guenther wrote:
>>> On Mon, Jun 29, 2009 at 3:10 PM, Jan Engelhardt wrote:
Hi gcc list,
I am forwarding below's bugreport here(*), to implicitly make aware
of a feature
Dobes writes:
> 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.
> For example, this would be allowed "add 4($1), $8, $9
Richard Sandiford writes:
> Is this really the intended behaviour? Andrew closed the bug as invalid,
> saying that this is what we expect, but the docs seem to suggest that we
> ought to do something like:
>
> ...
> __cyg_profile_func_enter (&main, ...);
> ...
> __cyg_profile_fun
"daniel.tian" writes:
> I check the MIPS and ARM, both those cc1 files opened in Insight debug tool
> contain the mips.md and arm.md file. It is convenient while break point can
> be set in it.
> My port md file doesn't appear in the insight.
You seem to be asking a question about Insight rather
Jerry Quinn writes:
> Both 3.1.1 and 3.2.3 fail to bootstrap with the following error:
>
> make[1]: Entering directory `/home/jlquinn/gcc/dev/build/gcc323/gcc'
> gcc -c -DIN_GCC--std=gnu89 -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic
> -Wno-long-
Vladimir Makarov schrieb:
Michael Kruse wrote:
In the thesis, a modified Poletto algorithm is presented to add spill
code.
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 Chait
Michael Kruse wrote:
Vladimir Makarov wrote:
Michael Kruse wrote:
If the register sufficiency is higher than the physical number of
registers, spill code is added to the graph.
For me, that is the most interesting part, unfortunately Touti (as I
remember) in his thesis say practically noth
Vladimir Makarov wrote:
Michael Kruse wrote:
If the register sufficiency is higher than the physical number of
registers, spill code is added to the graph.
For me, that is the most interesting part, unfortunately Touti (as I
remember) in his thesis say practically nothing about this.
In th
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.
For example, this would be allowed "add 4($1), $8, $9", but this would not
b
On Monday 2009-06-29 16:09, Manuel López-Ibáñez wrote:
>2009/6/29 Richard Guenther wrote:
>> On Mon, Jun 29, 2009 at 3:10 PM, Jan Engelhardt wrote:
>>> Hi gcc list,
>>>
>>>
>>> I am forwarding below's bugreport here(*), to implicitly make aware
>>> of a feature that I deem important to have in a f
> "Ralf" == Ralf Wildenhues writes:
Ralf> I'd be grateful about feedback as to whether the general plan is
Ralf> acceptable for everyone; thanks.
Tom> Sounds good to me. Please don't forget Classpath.
Ralf> If you are talking about gcc/libjava/classpath, then yes, I have that on
Ralf> my r
Hi Tom,
* Tom Tromey wrote on Mon, Jun 29, 2009 at 07:05:26PM CEST:
> > "Ralf" == Ralf Wildenhues writes:
>
> Ralf> I'd be grateful about feedback as to whether the general plan is
> Ralf> acceptable for everyone; thanks.
>
> Sounds good to me. Please don't forget Classpath.
If you are ta
> "Ralf" == Ralf Wildenhues writes:
Ralf> I'd be grateful about feedback as to whether the general plan is
Ralf> acceptable for everyone; thanks.
Sounds good to me. Please don't forget Classpath.
Ralf> I'd prefer to do the transition on the GCC trunk rather than in a
Ralf> branch, unless 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
Dave Korn wrote:
Michael Kruse 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? What are the chances that this could get into
the main GCC tree if it shows up to be an im
Michael Kruse wrote:
Hello GCC developers,
I am going to write a Master's Thesis about instruction scheduling
based on the technique presented in [1]. This will also include a
implementation.
The basic idea is to have an additional pass on the data dependency
graph before instruction schedu
On Mon, Jun 29, 2009 at 5:39 AM, NightStrike wrote:
> On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor wrote:
>> Richard Guenther writes:
>>
>>> All that above said - do you expect us to carry both vec.h (for VEC in
>>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>>> for the a
2009/6/29 Richard Guenther :
> On Mon, Jun 29, 2009 at 3:10 PM, Jan Engelhardt wrote:
>> Hi gcc list,
>>
>>
>> I am forwarding below's bugreport here(*), to implicitly make aware
>> of a feature that I deem important to have in a future gcc.
>>
>
> -Wconversion should say
>
> t.c:4: warning: conver
A colleague recently came across the interaction between
-finstrument-functions and inline functions mentioned here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23296
As the bug submitter says, the problem is that for something like:
#include
void g (void) { printf("Here\n"); }
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-g++.dg-struct-layout-1/t027 and a couple of other tests failed
from
On Mon, Jun 29, 2009 at 3:10 PM, Jan Engelhardt wrote:
> Hi gcc list,
>
>
> I am forwarding below's bugreport here(*), to implicitly make aware
> of a feature that I deem important to have in a future gcc.
>
-Wconversion should say
t.c:4: warning: conversion to ‘unsigned char’ from ‘int’ may alte
Hi gcc list,
I am forwarding below's bugreport here(*), to implicitly make aware
of a feature that I deem important to have in a future gcc.
(*) should have posted to bugzilla instead? Don't feel like setting
up a bugmenot tho..
-- Forwarded message --
Date: Mon, 29 Jun 2009 1
NightStrike wrote:
> On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor wrote:
>> Richard Guenther writes:
>>
>>> All that above said - do you expect us to carry both vec.h (for VEC in
>>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>>> for the alloca trick ...)? Or do you thin
On Sat, Jun 27, 2009 at 6:25 PM, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
>> All that above said - do you expect us to carry both vec.h (for VEC in
>> GC memory) and std::vector (for VECs in heap memory) (and vec.h
>> for the alloca trick ...)? Or do you think we should try to make th
Hi,
I check the MIPS and ARM, both those cc1 files opened in Insight debug tool
contain the mips.md and arm.md file. It is convenient while break point can
be set in it.
My port md file doesn't appear in the insight.
How can I make it?
___
Best Regards
Hi, Jeff:
> OK. Subregs of MEMs are a little special. In general, you don't want to
> see these at all. I wouldn't necessarily expect this to be a
> PROMOTE_MODE problem.
>
> As others have suggested, find the first pass where you see a (subreg
> (mem)) expression. That will be a big help. Extra c
30 matches
Mail list logo
