further hints :
The immediate which gcc wants to move in R_REGS is a (const_int 8) as described
in the error message below :
arithmetic.c:197: error: insn does not satisfy its constraints:
(insn 1505 903 1506 0 (set (reg:SI 25 $R9)
(const_int 8 [0x8])) 0 {movsi_in
I would like to analyse code using the GCC CFG, however,
some steps invalidate it notably delay slot scheduling.
Are there plans to move toward "how it ought to work" as outlined in :
http://gcc.gnu.org/wiki/basic_block_graph
Peter.
Hi,
genmodes.c has the following comment:
/* Again, nothing more need be said. For historical reasons,
the size of a CC mode is four units. */
validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET);
m->bytesize = 4;
Now, this is probably ok for _most_ a
>genmodes.c has the following comment:
>
>
> /* Again, nothing more need be said. For historical reasons,
>
>
> the size of a CC mode is four units. */
> validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET);
>
> m->bytesize = 4;
>
>
>Now, this is probably ok f
Quoting paul_kon...@dell.com:
It would seem that making it equal to word size (whatever that is on
the platform) or size of the int type would be a way to make this
better. Would that have any bad consequences for other platforms?
For MXP (16-bit word addressed, with 128 bit vector regis
In the msp430 back end, hard registers 4 through 15 are HImode, with
adjacent register sequences used for SImode and DImode. In preparation for
a library call, I'm emitting RTL that assigns values directly to reg:SI 4.
Despite that, in gcc 4.5.x IRA choses reg:HI 4 as the destination
for a pseudo
On 09/15/2011 11:16 AM, Peter Bigot wrote:
In the msp430 back end, hard registers 4 through 15 are HImode, with
adjacent register sequences used for SImode and DImode. In preparation for
a library call, I'm emitting RTL that assigns values directly to reg:SI 4.
Despite that, in gcc 4.5.x IRA ch
LGTM
Ollie
On Wed, Sep 14, 2011 at 3:29 PM, Diego Novillo wrote:
>
> This merge brings google/integration up to rev 178783. I also
> merged rev 178833 to get the testsuite validation script I
> committed to trunk yesterday.
>
> Simon, Ollie, I expect our internal builder to fail until I
> incor
> > I'd say they should be optimization barriers too (and at the tree level
> > they I think work that way, being represented as function calls), so if
> > they don't act as memory barriers in RTL, the *.md patterns should be
> > fixed. The only exception should be IMHO the __SYNC_MEM_RELAXED
> >
On 09/15/2011 06:19 PM, Richard Henderson wrote:
I wouldn't go that far. They *used* to be compiler barriers,
but clearly something broke at some point without anyone noticing.
We don't know how many versions are affected until we debug it.
For all we know it broke in 4.5 and 4.4 is fine.
4.4
This merge adds the testsuite validation script to
google/gcc-4_6. Merged up to rev 178854.
Validated on x86_64.
Diego.
On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov wrote:
> On 09/15/2011 11:16 AM, Peter Bigot wrote:
>>
>> In the msp430 back end, hard registers 4 through 15 are HImode, with
>> adjacent register sequences used for SImode and DImode. In preparation
>> for
>> a library call, I'm emitting RTL th
Thanks Ian.
Any idea what the size of the problem would be , perhaps first for
backends that don't chose to vandalise things themselves 1st?
On 09/15/2011 03:06 PM, Peter Bigot wrote:
On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov wrote:
On 09/15/2011 11:16 AM, Peter Bigot wrote:
In the msp430 back end, hard registers 4 through 15 are HImode, with
adjacent register sequences used for SImode and DImode. In preparation
for
a lib
On Thu, Sep 15, 2011 at 4:09 PM, Vladimir Makarov wrote:
> On 09/15/2011 03:06 PM, Peter Bigot wrote:
>>
>> On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov
>> wrote:
>>>
>>> On 09/15/2011 11:16 AM, Peter Bigot wrote:
In the msp430 back end, hard registers 4 through 15 are HImode, wit
Snapshot gcc-4.5-20110915 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110915/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi Richard,
I slightly changed the case to be like below,
int f(char *t) {
int s=0;
while (*t && s != 1) {
switch (s) {
case 0: /* path 1 */
s = 2;
break;
case 2: /* path 2 */
s = 3; /* changed */
break;
17 matches
Mail list logo