> A random spotting; copyright header replacement miss, including
> but maybe not limited to:
Doh! I'll scan them all and fix them. Thanks!
On Wed, 19 Jun 2013, DJ Delorie wrote:
>
> Third revision, mostly the same as the last, haven't heard any additional
> feedback in the last few weeks. Ok to commit yet?
> [libgcc]
>
> * config.host (msp*-*-elf): New.
> * config/msp430/: New port.
A random spotting; copyright header r
Are there any further comments on this? Do I need to post a final
patch? Can it be committed yet?
On Tue, May 14, 2013 at 2:51 PM, nick clifton wrote:
> Hi Steven,
>
>> Should new ports be allowed in if they rely so heavily on reload?
>
> As it happens I am currently working on enabling LRA for the MSP430 target.
> Although I have run into a roadblock with a possibly unacceptable patch to
> sim
2013/5/14 nick clifton :
> Hi Steven,
>
>
>> Should new ports be allowed in if they rely so heavily on reload?
>
> As it happens I am currently working on enabling LRA for the MSP430 target.
> Although I have run into a roadblock with a possibly unacceptable patch to
> simplify_subreg_regno:
>
>
Hi Steven,
> Should new ports be allowed in if they rely so heavily on reload?
As it happens I am currently working on enabling LRA for the MSP430
target. Although I have run into a roadblock with a possibly
unacceptable patch to simplify_subreg_regno:
http://gcc.gnu.org/ml/gcc-patches/20
> "run-time", according to my reading of
> http://gcc.gnu.org/codingconventions.html .
I chenged it, but I note that "runtime" is used much more often than
"run-time" and "run time" in the docs.
However, "runtime" is preferred for "libraries and system support
present at run time", which is what
2013/5/13 Steven Bosscher :
> On Sun, May 12, 2013 at 8:56 PM, Gerald Pfeifer wrote:
>> On Fri, 10 May 2013, DJ Delorie wrote:
>>> Index: MAINTAINERS
>>> ===
>>> +msp430 port DJ Delorie d...@redhat.com
>>> +msp430
On Sun, 12 May 2013, Steven Bosscher wrote:
>> I'll bring this up on the steering committee (not that I expect
>> a lot of discussion :-).
> Actually I hope for some discussion:
>
> Should new ports be allowed in if they rely so heavily on reload?
That's a gcc(-patches)@gcc.gnu.org level discussi
On Sun, May 12, 2013 at 8:56 PM, Gerald Pfeifer wrote:
> On Fri, 10 May 2013, DJ Delorie wrote:
>> Index: MAINTAINERS
>> ===
>> +msp430 port DJ Delorie d...@redhat.com
>> +msp430 port Nick Clifton
On Fri, 10 May 2013, DJ Delorie wrote:
> Index: MAINTAINERS
> ===
> +msp430 port DJ Delorie d...@redhat.com
> +msp430 port Nick Cliftonni...@redhat.com
I'll bring this up on the steering comm
On May 9, 2013, at 2:06 AM, Richard Sandiford
wrote:
>> Hmmm... psi/si in memory are tieable, psi/si in registers
>> aren't... what's the right thing to do here?
>
> I think we assume everything is tieable in memory. MODES_TIEABLE_P says
> whether we should assume that a pseudo register in one
DJ Delorie writes:
>> It looks like the patch also treats PSImode->SImode as a truncation though.
>
> I'd have to check specifically for partial_int_mode, since there's
> nothing in PARTIAL_INT_MODE() to set the precision, unless there's
> some other way to set PSImode's bits *and* reliably use th
> It looks like the patch also treats PSImode->SImode as a truncation though.
I'd have to check specifically for partial_int_mode, since there's
nothing in PARTIAL_INT_MODE() to set the precision, unless there's
some other way to set PSImode's bits *and* reliably use that info.
For some reason,
I should also add generic new-port comments:
See the checklist under "Back End" in sourcebuild.texi. In particular,
add the target to contrib/config-list.mk so all-targets builds cover it.
Make sure that the port builds cleanly when configuring with
--enable-werror-always and building with a b
DJ Delorie writes:
>> > - if (GET_MODE_BITSIZE (GET_MODE (op0)) < GET_MODE_BITSIZE (GET_MODE
>> > (op1)))
>> > + /* Don't try to sign-extend SImode to PSImode, for example. */
>> > + if (GET_MODE_BITSIZE (GET_MODE (op0)) <= GET_MODE_BITSIZE
>> > (GET_MODE (op1)))
>>
>> Can't you do just
> > +;; This is weird. GCC testcase execute/20020615-1 compiled at -Os
>
> Another hack around a real problem, and a potential source of wrong
> code. Not OK IMHO.
I couldn't reproduce it, so I took it out. If it comes back, we'll
hit it harder :-)
> > - if (GET_MODE_BITSIZE (GET_MODE (op0)) < GET_MODE_BITSIZE
> > (GET_MODE (op1)))
> > + /* Don't try to sign-extend SImode to PSImode, for example. */
> > + if (GET_MODE_BITSIZE (GET_MODE (op0)) <= GET_MODE_BITSIZE
> > (GET_MODE (op1)))
>
> Can't you do just nothing
The assembler already exists (and is widely used, I think), and the
MSPABI specifies how registers and symbols are named at the assembler
level. Unfortunately, the MSPABI says that symbols should be like
||this|| when they need to mean "not a register" but our assembler
doesn't support that. The
On Tue, 7 May 2013, Steven Bosscher wrote:
> > Index: gcc/config/msp430/README.txt
> > ===
> > --- gcc/config/msp430/README.txt(revision 0)
> > +++ gcc/config/msp430/README.txt(revision 0)
> > @@ -0,0 +1,7 @@
> > +Rand
On Mon, 6 May 2013, DJ Delorie wrote:
> Note that I had to make a few changes (fixes?) in the MI portions of
> gcc to avoid problems I encountered, I don't know if these changes are
> "correct" or if there are better ways to avoid those cases. Those
In any case, they should best be posted in se
On Tue, May 7, 2013 at 4:41 AM, DJ Delorie wrote:
> Index: gcc/cfgexpand.c
> ===
> --- gcc/cfgexpand.c (revision 198591)
> +++ gcc/cfgexpand.c (working copy)
> @@ -3090,13 +3090,14 @@ expand_debug_expr (tree exp)
> siz
22 matches
Mail list logo
