Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> >> I think instead we should have a configuration switch that allows a
>> >> particular -mfp option to be inserted alongside -mabi=32 if no
>> >> explicit -mfp is given. This is how most --with options work. Mayb
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 13 March 2014 18:46
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: RE: dom requires PROP_loops
>
> On March 13, 2014 5:00:53 PM CET, Paulo Matos wrote:
> >> -Original Message-
> >> From: Ri
On Thu, Mar 13, 2014 at 10:44 PM, Thomas Schwinge
wrote:
> Hi!
>
> In gcc/c/c-parser.c:c_parser_omp_clause_num_threads (as well as other,
> similar functions), what is the point of setting the boolean tree c's
> location, given that this tree won't be used in the following?
>
> /* Attemp
Matthew Fortune writes:
> The spec on:
> https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
> has been updated and attempts to account for all the feedback. Not
> everything has been possible to simplify/rework as requested but I
> believe I have managed to address many point
Hello,
I'm writing a simple gcc backend and I'm experiencing a weird thing
regarding address legitimation process. Two scenarios:
If I only allow addresses to be either a register or symbols my gcc
works. To do so I add the restrictions into the
TARGET_LEGITIMATE_ADDRESS_P macro. This makes gcc t
On Fri, 14 Mar 2014 12:52:35 +0100
David Guillen wrote:
> If I allow also a 'PLUS' expression to be a valid address (adding the
> restriction that the two addends are a register and a constant) it
> happens (sometimes) that gcc comes up with an expression like this
> one:
>
> (plus:SI (plus
Richard Sandiford writes:
> Matthew Fortune writes:
> > The spec on:
> > https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinki
> > ng has been updated and attempts to account for all the feedback. Not
> > everything has been possible to simplify/rework as requested but I
> > beli
Thanks for you info Julian.
I actually read all the docs and I think I 'more or less' understand
the inner workings of gcc.
What surprises me most is that during the non-strict RTL generation I
do not see any 'strange' address pattern but during the post-reload
process the non-legitimate address c
Hi All,
To handle the below problem i.e making specific set of register as
base registers ,which is the subset of general registers set.
we see the *.c.208.ira logs as
Pass 0 for finding pseudo/allocno costs
r21: preferred BASE_REGS, alternative GENERAL_REGS, allocno GENERAL_REGS
a2 (
On Thu, Mar 13, 2014 at 4:44 PM, Richard Biener
wrote:
> On Tue, Mar 11, 2014 at 12:20 PM, Richard Biener
> wrote:
>> On Mon, Mar 10, 2014 at 7:29 PM, Prathamesh Kulkarni
>> wrote:
>>> Hi Richard,
>>> Sorry for the late reply. I would like to have few clarifications
>>> regarding the following p
On Fri, Mar 14, 2014 at 9:01 PM, Prathamesh Kulkarni
wrote:
> On Thu, Mar 13, 2014 at 4:44 PM, Richard Biener
> wrote:
>> On Tue, Mar 11, 2014 at 12:20 PM, Richard Biener
>> wrote:
>>> On Mon, Mar 10, 2014 at 7:29 PM, Prathamesh Kulkarni
>>> wrote:
Hi Richard,
Sorry for the late reply
On Fri, 14 Mar 2014, Prathamesh Kulkarni wrote:
I had a look at PR 14753
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14753) from the first
link. I have tried to implement those transforms (attached patch,
stage-1 compiled).
I have written the transforms to operate on GENERIC.
Why not directly
On 03/14/14 05:52, David Guillen wrote:
Hello,
I'm writing a simple gcc backend and I'm experiencing a weird thing
regarding address legitimation process. Two scenarios:
If I only allow addresses to be either a register or symbols my gcc
works. To do so I add the restrictions into the
TARGET_LE
On Fri, Mar 14, 2014 at 9:25 PM, Marc Glisse wrote:
> On Fri, 14 Mar 2014, Prathamesh Kulkarni wrote:
>
>> I had a look at PR 14753
>> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14753) from the first
>> link. I have tried to implement those transforms (attached patch,
>> stage-1 compiled).
>> I
On Fri, Mar 14, 2014 at 4:31 PM, Prathamesh Kulkarni
wrote:
> On Thu, Mar 13, 2014 at 4:44 PM, Richard Biener
> wrote:
>> On Tue, Mar 11, 2014 at 12:20 PM, Richard Biener
>> wrote:
>>> On Mon, Mar 10, 2014 at 7:29 PM, Prathamesh Kulkarni
>>> wrote:
Hi Richard,
Sorry for the late reply
On Fri, 14 Mar 2014, Prathamesh Kulkarni wrote:
On Fri, Mar 14, 2014 at 9:25 PM, Marc Glisse wrote:
On Fri, 14 Mar 2014, Prathamesh Kulkarni wrote:
The patterns mentioned in the links were:
a) (X >> CST1) >= CST2 -> X >= CST2 << CST1
however, an expression Y >= CST gets folded to Y > CST - 1
David Guillen writes:
> In any case I'm not using the restrict variable and I'm assuming
> strict is zero, this is, not checking the hard regsiters themselves.
> This is because any reg is OK for base reg. I'm pretty sure I'm
> behaving similarly to arm, cris or x86 backends.
"strict" doesn't me
Dear gcc contributors,
I am going to try to participate in Google Summer of Code 2014. My
project is "Integration of ISL code generator into Graphite".
My proposal can be found at on the following link
https://drive.google.com/file/d/0B2Wloo-931AoTWlkMzRobmZKT1U/edit?usp=sharing
. I would be ver
On 03/14/2014 09:21 PM, Roman Gareev wrote:
Dear gcc contributors,
I am going to try to participate in Google Summer of Code 2014. My
project is "Integration of ISL code generator into Graphite".
My proposal can be found at on the following link
https://drive.google.com/file/d/0B2Wloo-931AoTWl
Hello,
We previously had these same mirrors up under Go-Part.com but then changed our
domain to Go-Parts.com. The mirror links then dropped off. We apologize deeply
for this, and assure you that this is a one-time event. Going forward, the
mirrors will stay up for a very long time to come, and
I made a small mistake below on the ftp/rsync mirrors for the USA mirror. They
should be:
(USA)
http://mirrors-usa.go-parts.com/gcc
ftp://mirrors-usa.go-parts.com/gcc
rsync://mirrors-usa.go-parts.com/gcc
> From: dan1...@msn.com
> To: gcc@gcc.gnu.org
> Sub
21 matches
Mail list logo
