Hi,
In sh/predicates.md, I see
(define_predicate "sh_rep_vec"
(match_code "const_vector")
{
int i;
rtx x, y;
if ((GET_CODE (op) != CONST_VECTOR && GET_CODE (op) != PARALLEL)
|| (GET_MODE (op) != mode && mode != VOIDmode))
return 0;
Notice that match_code at the beginning does
Bradley Lucier wrote:
> I'm having all kinds of trouble running svn on my RHEL 4.0 system. A
> typical example of what's happening is:
>
> euler-62% svn cleanup
> svn: XML parser failed in 'gcc/testsuite/gcc.dg/special'
>
> I first got that message when I tried contrib/gcc_update after doing a
Bradley Lucier wrote:
> I'm having all kinds of trouble running svn on my RHEL 4.0 system. A
> typical example of what's happening is:
>
> euler-62% svn cleanup
> svn: XML parser failed in 'gcc/testsuite/gcc.dg/special'
I'm sorry, I'm a little sleepy, in the hurry of trying to "help" I
totally
Bradley Lucier <[EMAIL PROTECTED]> writes:
> I'm having all kinds of trouble running svn on my RHEL 4.0 system. A
> typical example of what's happening is:
>
> euler-62% svn cleanup
> svn: XML parser failed in 'gcc/testsuite/gcc.dg/special'
>
> I first got that message when I tried contrib/gcc_
Hi,
I posted this message on gnu-help yesterday and did not get a reply.
I am going to post it here. I hope that does not bother anyone.
I can not find a description of what the different versions of libgcc
and libstd++ are for. Some versions are obvious, others are not.
In particular,
Try removing the offending directory (gcc/testsuite/gcc.dg/special) and
run svn cleanup again, updating the tree afterwards. If you didn't have
any local changes in that directory you should not lose anything. If the
problem persists then you probably have a hardware problem.
Just "for the re
Here is my script to compile. The ulimit is because I log in as a
user and then su to root so I have the normal user limits which is
too small. See:
http://gcc.gnu.org/ml/gcc-help/2005-05/msg00105.html
and its follow ups for more info.
The CONFIG_SHELL is set because without it the config
On Wed, 28 Dec 2005, Liu Haibin wrote:
(I'm this far ^ behind on reading mailing lists.)
It's likely that you have since long noticed, but in case not:
> I got a dump of sha.c.27.flow2 from gcc 3.4.1. I don't quite
> understand the LOG_LINKS of insn 498. LOG_LINKS in insn 498 shows that
> it has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
While trying to debug a long-standing ICE on the
gcjx branch, I have found out that the root cause
of the problem is with the tree-ssa operands processing
code and it still seems to exist on the mainline
(as of revision 109471), though I have tr
On Jan 8, 2006, at 9:04 AM, Andreas Schwab wrote:
Try removing the offending directory (gcc/testsuite/gcc.dg/special)
and
run svn cleanup again, updating the tree afterwards. If you didn't
have
any local changes in that directory you should not lose anything.
If the
problem persists the
> Perry Smith writes:
Perry> I can not find a description of what the different versions of libgcc
Perry> and libstd++ are for. Some versions are obvious, others are not.
Perry> In particular, I am trying to determine what these libraries are
Perry> for: (this is on AIX version 5.3) (h
Thanks David,
I discovered the --disable-hosted-libstdcxx configure option for
libstdc++-v3 and I'm going to build it and see where that takes me.
Right now, my biggest offender as far as dragging in lots of symbols
(like iob, fprintf, etc) is the verbose_terminate_handler. --disable-
h
> Perry Smith writes:
Perry> Maybe you can help on another item. I recall back around 1995 or so,
Perry> gcc could not be used for AIX device drivers because it did not
Perry> handle the floating point registers properly. I have only a vague
Perry> memory of this. Do you recall anythi
Hello,
With a friend, we are interested in the port of gcc on Microchip Pic18.
So can you tell me more about your experience with the Microchip 18F, if
somebody is currently working on this device, how to find his work, or if the
memory model of the PIC18 is definitively a problem to gcc porting
On Jan 8, 2006, at 9:12 AM, Daniel Berlin wrote:
Try removing the offending directory (gcc/testsuite/gcc.dg/
special) and
run svn cleanup again, updating the tree afterwards. If you
didn't have
any local changes in that directory you should not lose anything.
If the
problem persists th
Hello,
> While trying to debug a long-standing ICE on the
> gcjx branch, I have found out that the root cause
> of the problem is with the tree-ssa operands processing
> code and it still seems to exist on the mainline
> (as of revision 109471), though I have traced the code
> path in a debugger
On Sun, 2006-01-08 at 18:05 -0600, Bradley Lucier wrote:
> On Jan 8, 2006, at 9:12 AM, Daniel Berlin wrote:
>
> >>
> >> Try removing the offending directory (gcc/testsuite/gcc.dg/
> >> special) and
> >> run svn cleanup again, updating the tree afterwards. If you
> >> didn't have
> >> any local
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zdenek Dvorak wrote:
>
> this can never happen. Note that is_real_op = is_gimple_reg (var), and
> a call clobbered variable can never satisfy is_gimple_reg. Most likely
> you forget to set TREE_ADDRESSABLE for this variable. Or it gets to
> call_cl
Hi,
I have downloaded latest GCC and Binutils sources from FSF for M16C
port. Using these sources, I could successfully build the cross
toolchain i.e. m32c-elf-*.
I have observed the following behavior while using "float" and
"double" data types for m16c target. Any computation involving
a "f
19 matches
Mail list logo
