Two weeks since the last comment... Anyone?
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01089.html
> 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 Thu, 16 May 2013, DJ Delorie wrote:
> SIZE_TYPE is compared - with individual strcmp's! - against a fixed
> set of C types, instead of using some sort of table lookup to support
> non-power-of-two types.
Joern had a patch (as of December 2010, possibly updated since then) to
convert at least
> I thought it was the other way round - that after Bernd's fixes (July
> 2011) towards support for 40-bit integers, FRACTIONAL_INT_MODE worked
> better than PARTIAL_INT_MODE.
Probably most accurate to say that both ways are not well supported.
In general, I always have a hard time with anythin
On Thu, 16 May 2013, DJ Delorie wrote:
> > What's the blocker to convert the existing 5 cases of
> > PARTIAL_INT_MODE use to specify a precision?
>
> In general? For me, PARTIAL_INT_MODE() works, FRACTIONAL_INT_MODE()
> didn't.
I thought it was the other way round - that after Bernd's fixes (Ju
> What's the blocker to convert the existing 5 cases of
> PARTIAL_INT_MODE use to specify a precision?
In general? For me, PARTIAL_INT_MODE() works, FRACTIONAL_INT_MODE()
didn't.
> Interestingly we have exactly that for AVR:
>
> config/avr/avr-modes.def:FRACTIONAL_INT_MODE (PSI, 24, 3);
I know. I tried copying them, it didn't work for me.
On Wed, May 15, 2013 at 7:24 PM, Mike Stump wrote:
> On May 15, 2013, at 1:27 AM, Richard Biener
> wrote:
>> My question is, if you end up with
>>
>> (truncate:PSI (reg:SI 27))
>>
>> and then constant propagate 0x7fff to reg:SI 27, what does simplify-rtx.c
>> do here? Truncate to _what_ pr
On May 15, 2013, at 1:27 AM, Richard Biener wrote:
> My question is, if you end up with
>
> (truncate:PSI (reg:SI 27))
>
> and then constant propagate 0x7fff to reg:SI 27, what does simplify-rtx.c
> do here? Truncate to _what_ precision exactly?
In my world, I change PSI to be P28SI, and
On Tue, May 14, 2013 at 6:03 PM, DJ Delorie wrote:
>
>> How can you then ever "truncate" from SImode to PSImode?
>
> If you use PARTIAL_INT_MODE(), you get a PSImode that has a "default"
> bitsize (i.e. the value stored in the data structure) that's the same
> as SImode, that is, 32. There is no
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:
>
>
> How can you then ever "truncate" from SImode to PSImode?
If you use PARTIAL_INT_MODE(), you get a PSImode that has a "default"
bitsize (i.e. the value stored in the data structure) that's the same
as SImode, that is, 32. There is no way to specify the usable
bitsize, so it's "undefined/unspeci
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
On Mon, May 13, 2013 at 7:23 PM, DJ Delorie wrote:
>
>> Can you add that (partial int modes have fewer bits than int modes)
>> as verification to genmodes.c:make_partial_integer_mode?
>
> I could, but it would be a no-op for PARTIAL_INT_MODE()
>
>> I wonder if this should not use GET_MODE_PRECISIO
> "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
> Can you add that (partial int modes have fewer bits than int modes)
> as verification to genmodes.c:make_partial_integer_mode?
I could, but it would be a no-op for PARTIAL_INT_MODE()
> I wonder if this should not use GET_MODE_PRECISION - after all it is
> the precision that determines whether
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 Sat, May 11, 2013 at 1:41 AM, 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, the
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
> > 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 separate messages, each one
>
> > 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 separate messages, each one
>
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
37 matches
Mail list logo
