A questionable predicate in sh/predicates.md
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 not mention PARALLEL, but
we have GET_CODE (op) != PARALLEL later. Is this predicate intended
to accept PARALLEL as well? If so, should we change the match_code at
the beginning? When I did the conversion from PREDICATE_CODES to
predicates.md, I did so in a mechanical way, so loose things like this
might have gone unnoticed.
Kazu Hirata
Re: svn access on RHEL 4.0
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 > svn checkout. Now I just get > > euler-63% contrib/gcc_update > Updating SVN tree > svn: Working copy '.' locked > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for > details) > Adjusting file timestamps > SVN update of full tree failed. Have you tried doing "svn cleanup" as the error message suggests? -- Pedro Lamarão
Re: svn access on RHEL 4.0
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 missed these lines. :-( -- Pedro Lamarão
Re: svn access on RHEL 4.0
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_update after doing > a svn checkout. Now I just get > > euler-63% contrib/gcc_update > Updating SVN tree > svn: Working copy '.' locked > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for > details) > Adjusting file timestamps > SVN update of full tree failed. > > > Does anyone have any helpful ideas of what to do? 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. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
libgcc.a, et. al.
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, I am trying to determine what these libraries are for: (this is on AIX version 5.3) (how are they different from each other perhaps is a better way to phrase my question. Or what objective do each of these have?) gcc/powerpc-ibm-aix5.3.0.0/4.0.2/libgcc_eh.a libgcc_s.a libsupc++.a libstdc++.a To provide some background, I am attempting to write a device driver on AIX 5.3 using C++. I want to use the try/catch/throw exception part of C++. I realize this may be an uphill battle but I think it will be worth it. To do this, the driver must be linked statically except for references resolved by exports provided by the AIX kernel services. I've been writing drivers using xlc on AIX for 18+ years so I am familiar with the AIX environment using C but want to start using C++. Thank you, Perry Smith
Re: svn access on RHEL 4.0
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 record": gcc.gnu.org runs RHEL4, and we've never had any trouble like this. All the snapshots are generated locally using svn, etc.
gcc 4.0.2 compiled on AIX 5.3 (53A)
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 configure of libstdc++ would take more than a day to complete. See: http://gcc.gnu.org/ml/gcc-help/2005-05/msg00307.html and its follow ups for more info. I started with gcc 3.3.2. #!/bin/sh ulimit -S -d unlimited export CONFIG_SHELL=/usr/local/bin/bash ../gcc-4.0.2/configure -v \ --disable-nls \ --with-libiconv-prefix=/usr \ --enable-languages=c,c++ 2>&1 | tee CONF-OUT gmake bootstrap > MAKE-OUT 2>&1
Re: on data depenence
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 a data dependence (a read after write dependence) with insn 3.
> Why is it so? I don't see any dependence between "mov r14 r4" and
> "addi r3, r4, 28". The bottom is the whole dump of the basic block.
It says r14 (14), not r4 (4).
>
> (insn 3 4 11 0 (set (reg/v/f:SI 14 r14 [orig:46 sha_info ] [46])
> (reg:SI 4 r4 [ sha_info ])) 8 {movsi_internal} (nil)
> (expr_list:REG_DEAD (reg:SI 4 r4 [ sha_info ])
> (nil)))
Set of R14.
>
>
> (insn 498 375 560 0 (set (reg/f:SI 3 r3 [235])
> (plus:SI (reg/v/f:SI 14 r14 [orig:46 sha_info ] [46])
> (const_int 28 [0x1c]))) 20 {addsi3} (insn_list 3 (nil))
> (nil))
Use of R14.
Or maybe you meant something else?
brgds, H-P
[gcjx] Tree-SSA Operands Processing Problem
-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 traced the code
path in a debugger and actually observed the problem only
on the gcjx branch.
In mainline, the code path starts from
tree-ssa-operands.c:1906 where we have a *local* variable
VAR whose address is passed on to add_stmt_operand() on
the next line:
- --- 8< ---
1903 /* Add a VUSE for each call-clobbered variable. */
1904 EXECUTE_IF_SET_IN_BITMAP (call_clobbered_vars, 0, u, bi)
1905 {
1906 tree var = referenced_var (u);
1907 add_stmt_operand (&var, &empty_ann, opf_none |
opf_non_specific);
1908 }
1909
- --- 8< ---
This function then passes this pointer to append_use() at
line 1634, which seems to just store it as-is in BUILD_USES:
- --- 8< ---
1572 static void
1573 add_stmt_operand (tree *var_p, stmt_ann_t s_ann, int flags)
1574 {
[...]
1628 if (is_real_op)
1629 {
1630 /* The variable is a GIMPLE register. Add it to real
operands. */
1631 if (flags & opf_is_def)
1632 append_def (var_p);
1633 else
1634 append_use (var_p);
1635 }
- --- 8< ---
This seems wrong.
I don't know whether this code path is actually ever
taken on mainline or why it hasn't caused any problems
yet, but on the gcjx branch it causes an ICE while
processing the method "of" of the inner class "UnicodeBlock"
of the class "java.lang.Character"
($GCC_SRC_DIR/libjava/java/lang/Character.java). Specifically,
it ICEs while processing the CALL_EXPR corresponding to
the call to _Jv_ThrowBadArrayIndex() thrown if a subscript
is beyond the limits of an array. The problem occurs when
the stack-slot for the VAR variable referred to earlier
is occupied by the NUM local variable of finalize_ssa_vuses()
and is overwritten when this variable is assigned a value in
this function.
Comments?
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDwT2fYb1hx2wRS48RAr8nAJ90iq5wgQpVeG09vihfwN1x1gvsRACfebPH
3ZjNpJLVJNJZTbWpDEKyxiU=
=NBsE
-END PGP SIGNATURE-
Re: svn access on RHEL 4.0
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 then you probably have a hardware problem. Thanks for I installed subversion 1.3.0 and tried your suggestion recursively and seemed to get into a cycle ---after removing libjava/testsuite/ libjava.lang as one of the "problem" directories on the way to getting a clean "xvn cleanup", it showed up again as one of the "problem" directories in trying to do contrib/gcc_update, notes are below. Actually, gcc_update appears to complain about libstdc++-v3/ testsuite/data immediately after installing a new version. (I got a slightly more detailed error message with 1.3.0 than with the default 1.1.4: euler-5% svn cleanup svn: XML parser failed in 'gcc/testsuite/gcc.dg/pch' svn: Bogus date but I don't know what "Bogus date" means in any detail.) It's interesting that you mention a possible hardware problem. The file system is mounted on a new SAN served from a Sparc NFSv4 server; do you thin that perhaps we should try to mount it using NFSv3 to see if that fixes the problem? Brad euler-36% tcsh euler-1% set path=(/export/users/lucier/local/subversion-1.3.0/bin/ $path) euler-2% which svn /export/users/lucier/local/subversion-1.3.0/bin//svn euler-3% dirs ~/programs/subversion-1.3.0 euler-4% pu ~/programs/gcc/4.2/ ~/programs/gcc/4.2 ~/programs/subversion-1.3.0 euler-5% svn cleanup svn: XML parser failed in 'gcc/testsuite/gcc.dg/pch' svn: Bogus date euler-6% /bin/rm -rf gcc/testsuite/gcc.dg/pch euler-7% svn cleanup svn: XML parser failed in 'libstdc++-v3/testsuite/data' svn: Bogus date euler-8% /bin/rm -rf libstdc++-v3/testsuite/data euler-9% svn cleanup svn: XML parser failed in 'libjava/classpath/org/omg/SendingContext' svn: Bogus date euler-10% /bin/rm -rf libjava/classpath/org/omg/SendingContext euler-11% svn cleanup svn: XML parser failed in 'libjava/testsuite/libjava.special' svn: Bogus date euler-12% /bin/rm -rf libjava/testsuite/libjava.special euler-13% svn cleanup svn: XML parser failed in 'libjava/testsuite/libjava.lang' svn: Bogus date euler-14% /bin/rm -rf libjava/testsuite/libjava.lang euler-15% svn cleanup svn: XML parser failed in 'libjava/testsuite/libjava.loader' svn: Bogus date euler-16% /bin/rm -rf libjava/testsuite/libjava.loader euler-17% svn cleanup euler-18% contrib/gcc_update Updating SVN tree Agcc/testsuite/gcc.dg/special Agcc/testsuite/gcc.dg/special/2419-2.c Agcc/testsuite/gcc.dg/special/wkali-1.c Agcc/testsuite/gcc.dg/special/wkali-2.c Agcc/testsuite/gcc.dg/special/wkali-2a.c Agcc/testsuite/gcc.dg/special/wkali-2b.c Agcc/testsuite/gcc.dg/special/mips-abi.exp Agcc/testsuite/gcc.dg/special/mips-abi.s Agcc/testsuite/gcc.dg/special/gcsec-1.c Agcc/testsuite/gcc.dg/special/weak-1.c Agcc/testsuite/gcc.dg/special/weak-2.c Agcc/testsuite/gcc.dg/special/weak-1a.c Agcc/testsuite/gcc.dg/special/weak-2a.c Agcc/testsuite/gcc.dg/special/alias-1.c Agcc/testsuite/gcc.dg/special/weak-2b.c Agcc/testsuite/gcc.dg/special/alias-2.c Agcc/testsuite/gcc.dg/special/special.exp Agcc/testsuite/gcc.dg/pch Agcc/testsuite/gcc.dg/pch/valid-1b.c Agcc/testsuite/gcc.dg/pch/macro-2.c Agcc/testsuite/gcc.dg/pch/decl-5.hs Agcc/testsuite/gcc.dg/pch/macro-4.c Agcc/testsuite/gcc.dg/pch/decl-1.c Agcc/testsuite/gcc.dg/pch/inline-3.hs Agcc/testsuite/gcc.dg/pch/decl-3.c Agcc/testsuite/gcc.dg/pch/import-1.c Agcc/testsuite/gcc.dg/pch/decl-5.c Agcc/testsuite/gcc.dg/pch/cpp-2.hs Agcc/testsuite/gcc.dg/pch/save-temps-1.hs Agcc/testsuite/gcc.dg/pch/static-2.hs Agcc/testsuite/gcc.dg/pch/import-1b.h Agcc/testsuite/gcc.dg/pch/cpp-2.c Agcc/testsuite/gcc.dg/pch/system-1.c Agcc/testsuite/gcc.dg/pch/pch.exp Agcc/testsuite/gcc.dg/pch/valid-3.hs Agcc/testsuite/gcc.dg/pch/macro-4.hs Agcc/testsuite/gcc.dg/pch/warn-1.hs Agcc/testsuite/gcc.dg/pch/valid-2.c Agcc/testsuite/gcc.dg/pch/empty.c Agcc/testsuite/gcc.dg/pch/decl-4.hs Agcc/testsuite/gcc.dg/pch/valid-4.c Agcc/testsuite/gcc.dg/pch/include Agcc/testsuite/gcc.dg/pch/include/import-2a.h Agcc/testsuite/gcc.dg/pch/include/import-2b.h Agcc/testsuite/gcc.dg/pch/valid-6.c Agcc/testsuite/gcc.dg/pch/inline-2.hs Agcc/testsuite/gcc.dg/pch/warn-1.c Agcc/testsuite/gcc.dg/pch/cpp-1.hs Agcc/testsuite/gcc.dg/pch/system-1.hs Agcc/testsuite/gcc.dg/pch/static-1.hs Agcc/testsuite/gcc.dg/pch/inline-2.c Agcc/testsuite/gcc.dg/pch/inline-4.c Agcc/testsuite/gcc.dg/pch/struct-1.c Agcc/testsuite/gcc.dg/pch/static-1.c Agcc/testsuite/gcc.dg/pch/common-1.c Agcc/testsuite/gcc.dg/pch/empty.hs Agcc/testsuite/gcc.dg/pch/valid-2.hs Agcc/testsuite/gcc.dg/pch/valid-1b.hs Agcc/
Re: libgcc.a, et. al.
> 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) (how are they different from each Perry> other perhaps is a better way to phrase my question. Or what Perry> objective do each of these have?) Perry> gcc/powerpc-ibm-aix5.3.0.0/4.0.2/libgcc_eh.a Perry> libgcc_s.a Perry> libsupc++.a Perry> libstdc++.a Perry> To provide some background, I am attempting to write a device driver Perry> on AIX 5.3 using C++. I want to use the try/catch/throw exception Perry> part of C++. I realize this may be an uphill battle but I think it Perry> will be worth it. To do this, the driver must be linked statically Perry> except for references resolved by exports provided by the AIX kernel Perry> services. I've been writing drivers using xlc on AIX for 18+ years Perry> so I am familiar with the AIX environment using C but want to start Perry> using C++. libgcc is a general, low-level runtime support library for GCC. On AIX, the XLC support routines are provided by the system libc. libgcc_s is the shared library version of the support library. libstdc++ provides the standard C++ library. libgcc_eh.a provides general support for exception handling for all GCC languages. libsupc++ is included in libstdc++. The VAC++ runtime libraries are much like the G++ libraries, but the two are incompatible. GCC, including G++, provides a "-static" option to link an application staticly. GCC invokes the appropriate options for AIX (similarly, an AIX shared object can be created with the "-shared" commandline option). One can examine the options generated for the linker with the "-v" commandline option. Using a C++ applications with exception handling to build a device driver is complicated, even without using G++. G++ needs all of its GCC and C++-related support libraries for exception handling. David
Re: libgcc.a, et. al.
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- hosted-libstdcxx should remove the reference to that routine and simply call abort (according to the comments). After that, I think I can plug in my versions for "free", "malloc", "realloc", and "abort" and be almost home. I tried a simple driver using exceptions and compiling with xlC but I got stuck. I fought with it for a day and decided to try the gcc/g++ route. Maybe you can help on another item. I recall back around 1995 or so, gcc could not be used for AIX device drivers because it did not handle the floating point registers properly. I have only a vague memory of this. Do you recall anything like that? Thanks Perry On Jan 8, 2006, at 11:13 AM, David Edelsohn wrote: 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) (how are they different from each Perry> other perhaps is a better way to phrase my question. Or what Perry> objective do each of these have?) Perry> gcc/powerpc-ibm-aix5.3.0.0/4.0.2/libgcc_eh.a Perry> libgcc_s.a Perry> libsupc++.a Perry> libstdc++.a Perry> To provide some background, I am attempting to write a device driver Perry> on AIX 5.3 using C++. I want to use the try/catch/throw exception Perry> part of C++. I realize this may be an uphill battle but I think it Perry> will be worth it. To do this, the driver must be linked statically Perry> except for references resolved by exports provided by the AIX kernel Perry> services. I've been writing drivers using xlc on AIX for 18 + years Perry> so I am familiar with the AIX environment using C but want to start Perry> using C++. libgcc is a general, low-level runtime support library for GCC. On AIX, the XLC support routines are provided by the system libc. libgcc_s is the shared library version of the support library. libstdc++ provides the standard C++ library. libgcc_eh.a provides general support for exception handling for all GCC languages. libsupc++ is included in libstdc++. The VAC++ runtime libraries are much like the G++ libraries, but the two are incompatible. GCC, including G++, provides a "-static" option to link an application staticly. GCC invokes the appropriate options for AIX (similarly, an AIX shared object can be created with the "-shared" commandline option). One can examine the options generated for the linker with the "-v" commandline option. Using a C++ applications with exception handling to build a device driver is complicated, even without using G++. G++ needs all of its GCC and C++-related support libraries for exception handling. David
Re: libgcc.a, et. al.
> 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 anything like that? GCC will generate uses of floating point registers from source code that only describes integer computations. GCC 4.1 will do so less often, but nothing has changed to prevent it. One can use the soft-float option, but this confuses people who want to use floating point registers in code that does describe floating point computations. David
Microchip Pic-18F port on GNU/Gcc
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 ? Thanks for answer, Francois Poulain Brest, France. 02 98 45 74 22
Re: svn access on RHEL 4.0
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 then you probably have a hardware problem. Just "for the record": gcc.gnu.org runs RHEL4, and we've never had any trouble like this. All the snapshots are generated locally using svn, etc. OK, here are some details. Our server is a dual UltraSparc running Solaris 10 attached to the SAN. Working client situation: subversion 1.3.0 on Sparc Solaris 9, not using Berkeley DB Non-working client situation: subversion 1.3.0 on x86-64 RHEL 4.0, using Berkeley DB I think everything is running NFSv4 at this point. So I don't know if the problem is with RHEL versus Solaris 10, or Berkeley DB versus non-Berkeley DB (whatever subversion uses when Berkeley DB is not available). Perhaps I can do some experiments to see whether Solaris 9 + Berkeley DB works or not. Brad
Re: [gcjx] Tree-SSA Operands Processing Problem
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 and actually observed the problem only
> on the gcjx branch.
>
> In mainline, the code path starts from
> tree-ssa-operands.c:1906 where we have a *local* variable
> VAR whose address is passed on to add_stmt_operand() on
> the next line:
> - --- 8< ---
>1903 /* Add a VUSE for each call-clobbered variable. */
>1904 EXECUTE_IF_SET_IN_BITMAP (call_clobbered_vars, 0, u, bi)
>1905 {
>1906 tree var = referenced_var (u);
>1907 add_stmt_operand (&var, &empty_ann, opf_none |
> opf_non_specific);
>1908 }
>1909
> - --- 8< ---
>
> This function then passes this pointer to append_use() at
> line 1634, which seems to just store it as-is in BUILD_USES:
> - --- 8< ---
>1572 static void
>1573 add_stmt_operand (tree *var_p, stmt_ann_t s_ann, int flags)
>1574 {
>[...]
>1628 if (is_real_op)
>1629 {
>1630 /* The variable is a GIMPLE register. Add it to real
> operands. */
>1631 if (flags & opf_is_def)
>1632 append_def (var_p);
>1633 else
>1634 append_use (var_p);
>1635 }
> - --- 8< ---
>
> This seems wrong.
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_clobbered_vars wrongly.
Zdenek
> I don't know whether this code path is actually ever
> taken on mainline or why it hasn't caused any problems
> yet, but on the gcjx branch it causes an ICE while
> processing the method "of" of the inner class "UnicodeBlock"
> of the class "java.lang.Character"
> ($GCC_SRC_DIR/libjava/java/lang/Character.java). Specifically,
> it ICEs while processing the CALL_EXPR corresponding to
> the call to _Jv_ThrowBadArrayIndex() thrown if a subscript
> is beyond the limits of an array. The problem occurs when
> the stack-slot for the VAR variable referred to earlier
> is occupied by the NUM local variable of finalize_ssa_vuses()
> and is overwritten when this variable is assigned a value in
> this function.
>
> Comments?
>
> Thanks,
> Ranjit.
>
> - --
> Ranjit Mathew Email: rmathew AT gmail DOT com
>
> Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
>
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFDwT2fYb1hx2wRS48RAr8nAJ90iq5wgQpVeG09vihfwN1x1gvsRACfebPH
> 3ZjNpJLVJNJZTbWpDEKyxiU=
> =NBsE
> -END PGP SIGNATURE-
>
Re: svn access on RHEL 4.0
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 changes in that directory you should not lose anything. > >> If the > >> problem persists then you probably have a hardware problem. > > > > Just "for the record": > > > > gcc.gnu.org runs RHEL4, and we've never had any trouble like this. > > > > All the snapshots are generated locally using svn, etc. > > OK, here are some details. Our server is a dual UltraSparc running > Solaris 10 attached to the SAN. > > Working client situation: subversion 1.3.0 on Sparc Solaris 9, not > using Berkeley DB > > Non-working client situation: subversion 1.3.0 on x86-64 RHEL 4.0, > using Berkeley DB > > I think everything is running NFSv4 at this point. Unless you are running a server locally, whether you've compiled in BDB or not doesn't matter.
Re: [gcjx] Tree-SSA Operands Processing Problem
-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_clobbered_vars wrongly.
Oh! That might explain why this hasn't manifested itself
on mainline yet and why even after I put in this workaround
patch:
- 8< ---
Index: tree-ssa-operands.c
===
- --- tree-ssa-operands.c (revision 109471)
+++ tree-ssa-operands.c (working copy)
@@ -1770,8 +1770,10 @@ add_call_read_ops (tree stmt)
/* Add a VUSE for each call-clobbered variable. */
EXECUTE_IF_SET_IN_BITMAP (call_clobbered_vars, 0, i, bi)
{
- - tree var = referenced_var (i);
- - add_stmt_operand (&var, &empty_ann, opf_none);
+ /* FIXME: Temporary workaround. */
+ tree **var_pp = ggc_alloc (sizeof (tree *));
+ *var_pp = &(referenced_var (i));
+ add_stmt_operand (*var_pp, &empty_ann, opf_none);
}
ro_call_aliased_loads = empty_ann.makes_aliased_loads;
- 8< ---
it still aborts later on (checking is enabled) in
var_ann() in tree-flow-inline.h where the assertion
DECL_P(t) fails - T happens to be an SSA_NAME that
wraps(?) the VAR_DECL for the "SPECIALS" field of
the UnicodeBlock inner class of java.lang.Character.
All the times that this erroneous code path was
taken, the variables were either "SPECIALS" itself
or aliases to it. Thanks a lot. I'll investigate this
when I get some more time.
However, it still remains true that the code path
I referred to is wrong and if, as you say, it can
never be taken, it should just be removed and
replaced with an assertion codifying what you
are saying.
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDwc/uYb1hx2wRS48RAiGjAJ9yXv0wlyEf3mTP8uhZWrAssvphBwCggLLM
Ve3PA7Ql4Qm40yUBSvjdNqU=
=w40V
-END PGP SIGNATURE-
[M16C-ELF] : Problem with double and float data types.
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 "float" or a "double" data type does not work on the m16c hardware.
However, the correct values can be observed using GDB simulator.
For example, the following code:
#include
int main(void)
{
float f1 = 3.0;
printf("\n f1 = %f \n",f1);
f1 += 2.0;
printf("\n f1 = %f \n",f1);
return 0;
}
prints the expected values of "f1" using gdb simulator.
However, the above code does not work on hardware.
Only the initial value of "f1",i.e. 3.0 is output on the serial port.
But the value after computation i.e. 5.0 in not output.
Similar behavior is observed when "double" data type is used.
Please note that for outputting these characters on the serial port
we have modified the printf() function a bit.
Also the option "-msim" is used to print the output on the console
using gdb simulator. But, even without this option ( with no printf()
function in the code) the values can be watched by debugging the
code using gdb.
Thanks in advance.
Regards,
Ina Pandit
KPIT Cummins InfoSystems Ltd.
Pune, India
Free download of GNU based tool-chains for Renesas' SH and H8 Series.
The following site also offers free technical support to its users.
Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on October 12, 2005.
