Re: Vectorizing invariant data-ref
On Sun, Jul 19, 2009 at 8:18 AM, Revital1 Eres wrote: > > Hello, > > The following snippet is from a f90 program which contains > a loop that does not get vectorized. > > SUBROUTINE foo1(nx,ny,nz,arr2) > USE globalvar_mod, ONLY : dyinv, xstart, xstop > > k=1 > do j=1,ny > do i=1,nx > > arr1(i,j,k) = arr2(i,j,k ) *dyinv > > end do > end do > END SUBROUTINE foo1 > > The vectorizer failure message is: > > base_address: &dyinv > offset from base address: 0 > constant offset from base address: 0 > step: 0 > aligned to: 128 > base_object: dyinv > FAILED as dr address is invariant > > test41.f90:24: note: get vectype with 2 units of type real(kind=8) > test41.f90:24: note: vectype: vector real(kind=8) > test41.f90:24: note: not vectorized: unhandled data-ref > test41.f90:24: note: bad data references. > test41.f90:7: note: vectorized 0 loops in function. > > I am not familiar with f90 at all; seemingly dyinv is a regular > variable but according to the message in the dump file > it's a reference. > > One option to vectorize this loop is to extend the vectorizer's versioning > for aliasing capability to version the loop also in this case. > Other suggestions will be appreciated. The testcase is from 459.GemsFDTD, right? dyinv is a regular global variable. The issue is the global arrays arr1 and arr2 end up pointing to anything even though the Fortran aliasing rules say the do not. We are working on this issue. Thanks, Richard. > Thanks, > Revital > > > (See attached file: test41.f90.txt)
Re: Vectorizing invariant data-ref
Hello, > The testcase is from 459.GemsFDTD, right? dyinv is a regular > global variable. The issue is the global arrays arr1 and arr2 end > up pointing to anything even though the Fortran aliasing rules say > the do not. Yes, the testcase is from 459.GemsFDTD. > We are working on this issue. Great, thanks, Revital > > Thanks, > Richard. > > > Thanks, > > Revital > > > > > > (See attached file: test41.f90.txt)
Re: RFA: libjava seems to miss some files for win32
2009/7/18 Andrew Pinski :
> On Sat, Jul 18, 2009 at 12:22 PM, Kai Tietz wrote:
>> Well, uintptr_t/intptr_t are available to most (but not all hosts).
>> IIRC there is a gcc version of stdint.h (gstdint.h), which could be
>> used here. The mode version is fine too, as long as we can assume that
>> libjava isn't build by any other compiler then gcc.
>
> It is provided by GCC even without gstdint.h. See bug 448. Since
> __UINTPTR_TYPE__ is provided to be able to use stdint.h :).
>
> Thanks,
> Andrew PInski
>
So, I was able to build libjave (using the upstream boehm-gc source as
the version in gcc at the moment doesn't support x64) for x64 windows.
There are a lot of issues about casting HANDLE values into jint types,
which is for x86 valid, but for x64 can lead potential to pointer
truncations. Those part need some review by libjava maintainers. My
patch simply casts those kind of pointers via __UINTPTR_TYPE__ into
integer scalar before casting it into jint. I put comments at those
places, where some rework is necessary.
Additionally I removed the use of srand()/rand () and just throw an
exception in the Win32 specific implementation of
gnu::java::security::jce::prng::VMSecureRandom::natGenerateSeed.
ChangeLog
2009-07-19 Kai Tietz
* gnu/java/security/jce/prng/natVMSecureRandomWin32.cc: New Win32
specific implementation.
* nclude/win32.h (_Jv_platform_ffi_abi): Use for _WIN64 case
FFI_DEFAULT_ABI.
* java/lang/natString.cc (UNMASK_PTR, MASK_PTR, PTR_MASKED): Use
__UINTPTR_TYPE__ instead of unsigned long for pointer casts.
* gnu/java/net/natPlainDatagramSocketImplWin32.cc: Likewise.
* gnu/java/net/natPlainSocketImplWin32.cc: Likwise.
* gnu/java/nio/channels/natFileChannelWin32.cc: Likewise.
* include/jvm.h: Likewise.
* java/lang/natClass.cc: Likewise.
* java/lang/natClassLoader.cc: Likewise.
* java/lang/natWin32Process.cc: Likewise.
* link.cc: Likewise.
Regression tested for i686-pc-mingw32. Ok, for apply?
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Index: gcc/libjava/gnu/java/security/jce/prng/natVMSecureRandomWin32.cc
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ gcc/libjava/gnu/java/security/jce/prng/natVMSecureRandomWin32.cc 2009-07-19 12:13:45.715476500 +0200
@@ -0,0 +1,32 @@
+// natVMSecureRandomPosix.cc - Native part of VMSecureRandom class for POSIX.
+
+/* Copyright (C) 2009 Free Software Foundation
+
+ This file is part of libgcj.
+
+This software is copyrighted work licensed under the terms of the
+Libgcj License. Please consult the file "LIBGCJ_LICENSE" for
+details. */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+jint
+gnu::java::security::jce::prng::VMSecureRandom::natGenerateSeed(jbyteArray byte_array, jint offset, jint length)
+{
+ if (length != 0)
+throw new ::java::lang::InternalError
+ (JvNewStringLatin1 ("Error function not implemented for Win32 target."));
+ return 0;
+}
+
Index: gcc/libjava/gnu/java/net/natPlainDatagramSocketImplWin32.cc
===
--- gcc.orig/libjava/gnu/java/net/natPlainDatagramSocketImplWin32.cc 2009-07-19 12:06:54.197476000 +0200
+++ gcc/libjava/gnu/java/net/natPlainDatagramSocketImplWin32.cc 2009-07-19 12:13:45.721476500 +0200
@@ -75,7 +75,8 @@
// We use native_fd in place of fd here. From leaving fd null we avoid
// the double close problem in FileDescriptor.finalize.
- native_fd = (jint) hSocket;
+ // Fixme, it is pretty dangerous to cast here a HANDLE to integer scalar.
+ native_fd = (jint) (__UINTPTR_TYPE__) hSocket;
}
void
Index: gcc/libjava/gnu/java/net/natPlainSocketImplWin32.cc
===
--- gcc.orig/libjava/gnu/java/net/natPlainSocketImplWin32.cc 2009-07-19 12:06:54.200476000 +0200
+++ gcc/libjava/gnu/java/net/natPlainSocketImplWin32.cc 2009-07-19 12:13:45.727476500 +0200
@@ -58,7 +58,8 @@
// We use native_fd in place of fd here. From leaving fd null we avoid
// the double close problem in FileDescriptor.finalize.
- native_fd = (jint) hSocket;
+ // Fixme, it isn't correct to cast a HANDLE to integer scalar here for x64
+ native_fd = (jint) (__UINTPTR_TYPE__) hSocket;
}
void
@@ -304,7 +305,8 @@
// Cast this to a HANDLE so we can make
// it non-inheritable via _Jv_platform_close_on_exec.
- hSocket = (HANDLE) new_socket;
+ // Fixme, it isn't correct to cast a integer scalar here to HANDLE for x64
+ hSocket = (HANDLE) (__UINTPTR_TYPE__) new_socket;
_Jv_platform_close_on_exec (hSocket);
jbyteArray raddr;
@@ -325,8 +327,8 @@
#endif
else
throw new ::java::net::SocketException (JvNewStringUTF ("invalid family"));
-
- s->n
Re: RFA: libjava seems to miss some files for win32
Kai Tietz wrote: > There are a lot of issues about casting HANDLE values into jint types, > which is for x86 valid, but for x64 can lead potential to pointer > truncations. Those part need some review by libjava maintainers. My > patch simply casts those kind of pointers via __UINTPTR_TYPE__ into > integer scalar before casting it into jint. I put comments at those > places, where some rework is necessary. Argh. You're replacing a bunch of warnings that draw attention to a real problem by a bunch of silent fixmes in the code. That's a bit scary to me. > Index: gcc/libjava/gnu/java/net/natPlainSocketImplWin32.cc > === > --- gcc.orig/libjava/gnu/java/net/natPlainSocketImplWin32.cc 2009-07-19 > 12:06:54.200476000 +0200 > +++ gcc/libjava/gnu/java/net/natPlainSocketImplWin32.cc 2009-07-19 > 12:13:45.727476500 +0200 > @@ -58,7 +58,8 @@ > >// We use native_fd in place of fd here. From leaving fd null we avoid >// the double close problem in FileDescriptor.finalize. > - native_fd = (jint) hSocket; > + // Fixme, it isn't correct to cast a HANDLE to integer scalar here for x64 > + native_fd = (jint) (__UINTPTR_TYPE__) hSocket; > } Question is, can we change the sizes of the members of class objects, such as gnu::java::net::PlainSocketImpl::native_fd, or do these objects and their layout form part of an ABI, and/or do they ever get serialised? The Java guys will be able to tell us. cheers, DaveK
Re: RFA: libjava seems to miss some files for win32
2009/7/19 Dave Korn :
> Kai Tietz wrote:
>
>> There are a lot of issues about casting HANDLE values into jint types,
>> which is for x86 valid, but for x64 can lead potential to pointer
>> truncations. Those part need some review by libjava maintainers. My
>> patch simply casts those kind of pointers via __UINTPTR_TYPE__ into
>> integer scalar before casting it into jint. I put comments at those
>> places, where some rework is necessary.
>
> Argh. You're replacing a bunch of warnings that draw attention to a real
> problem by a bunch of silent fixmes in the code. That's a bit scary to me.
Right, therefore those comments are for. But otherwise I couldn't get
it build, as those kind of failures are treated as errors (what is in
fact a good thing).
>> Index: gcc/libjava/gnu/java/net/natPlainSocketImplWin32.cc
>> ===
>> --- gcc.orig/libjava/gnu/java/net/natPlainSocketImplWin32.cc 2009-07-19
>> 12:06:54.200476000 +0200
>> +++ gcc/libjava/gnu/java/net/natPlainSocketImplWin32.cc 2009-07-19
>> 12:13:45.727476500 +0200
>> @@ -58,7 +58,8 @@
>>
>> // We use native_fd in place of fd here. From leaving fd null we avoid
>> // the double close problem in FileDescriptor.finalize.
>> - native_fd = (jint) hSocket;
>> + // Fixme, it isn't correct to cast a HANDLE to integer scalar here for x64
>> + native_fd = (jint) (__UINTPTR_TYPE__) hSocket;
>> }
>
>
> Question is, can we change the sizes of the members of class objects, such
> as gnu::java::net::PlainSocketImpl::native_fd, or do these objects and their
> layout form part of an ABI, and/or do they ever get serialised? The Java guys
> will be able to tell us.
>
> cheers,
> DaveK
This was the reason, why I didn't changed api here. The final patch I
see here done by the java team, as I have no real idea, if those types
and members are part of abi, here. If it is there are ways to solve
this (e.g. making abstract handle values for OS handles as example).
So it is for sure necessary that a java maintainer takes action here.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: RFA: libjava seems to miss some files for win32
Kai Tietz wrote: > 2009/7/19 Dave Korn : >> Kai Tietz wrote: >> >>> There are a lot of issues about casting HANDLE values into jint types, >>> which is for x86 valid, but for x64 can lead potential to pointer >>> truncations. Those part need some review by libjava maintainers. My >>> patch simply casts those kind of pointers via __UINTPTR_TYPE__ into >>> integer scalar before casting it into jint. I put comments at those >>> places, where some rework is necessary. >> Argh. You're replacing a bunch of warnings that draw attention to a real >> problem by a bunch of silent fixmes in the code. That's a bit scary to me. > > Right, therefore those comments are for. But otherwise I couldn't get > it build, as those kind of failures are treated as errors (what is in > fact a good thing). Yes, so since they are a good thing, you should *not* get rid of them. It is better for it not to build than for it to silently build bad code. If you want it to work, you should make it *actually* work, otherwise just add it to noconfigdirs until such time as you can make it work. There is not only no point successfully building a broken library, there is _less_ than no point. Whenever adding fixmes, you must plan on there being a very great likelihood of them getting forgotten and never fixed. Rule #1 of maintenance-friendly coding. >> Question is, can we change the sizes of the members of class objects, such >> as gnu::java::net::PlainSocketImpl::native_fd, or do these objects and their >> layout form part of an ABI, and/or do they ever get serialised? The Java >> guys >> will be able to tell us. > This was the reason, why I didn't changed api here. The final patch I > see here done by the java team, as I have no real idea, if those types > and members are part of abi, here. If it is there are ways to solve > this (e.g. making abstract handle values for OS handles as example). > So it is for sure necessary that a java maintainer takes action here. I fail to see the value of building a broken libjava for w64. It's not a step you need to get past on the roadmap to making a working java for w64. Just don't build it at all. --disable-libjava or $noconfigdirs. Alternatively, wait a few hours until the java guys have a chance to respond. Maybe we can just change the datatypes, after all. But I really can't see any use and only harm in adding a silently broken implementation. cheers, DaveK
Re: RFA: libjava seems to miss some files for win32
2009/7/19 Dave Korn :
> Kai Tietz wrote:
>> 2009/7/19 Dave Korn :
>>> Kai Tietz wrote:
>>>
There are a lot of issues about casting HANDLE values into jint types,
which is for x86 valid, but for x64 can lead potential to pointer
truncations. Those part need some review by libjava maintainers. My
patch simply casts those kind of pointers via __UINTPTR_TYPE__ into
integer scalar before casting it into jint. I put comments at those
places, where some rework is necessary.
>>> Argh. You're replacing a bunch of warnings that draw attention to a real
>>> problem by a bunch of silent fixmes in the code. That's a bit scary to me.
>>
>> Right, therefore those comments are for. But otherwise I couldn't get
>> it build, as those kind of failures are treated as errors (what is in
>> fact a good thing).
>
> Yes, so since they are a good thing, you should *not* get rid of them. It
> is better for it not to build than for it to silently build bad code. If you
> want it to work, you should make it *actually* work, otherwise just add it to
> noconfigdirs until such time as you can make it work. There is not only no
> point successfully building a broken library, there is _less_ than no point.
>
> Whenever adding fixmes, you must plan on there being a very great likelihood
> of them getting forgotten and never fixed. Rule #1 of maintenance-friendly
> coding.
>
>>> Question is, can we change the sizes of the members of class objects, such
>>> as gnu::java::net::PlainSocketImpl::native_fd, or do these objects and their
>>> layout form part of an ABI, and/or do they ever get serialised? The Java
>>> guys
>>> will be able to tell us.
>
>> This was the reason, why I didn't changed api here. The final patch I
>> see here done by the java team, as I have no real idea, if those types
>> and members are part of abi, here. If it is there are ways to solve
>> this (e.g. making abstract handle values for OS handles as example).
>> So it is for sure necessary that a java maintainer takes action here.
>
> I fail to see the value of building a broken libjava for w64. It's not a
> step you need to get past on the roadmap to making a working java for w64.
> Just don't build it at all. --disable-libjava or $noconfigdirs.
>
> Alternatively, wait a few hours until the java guys have a chance to
> respond. Maybe we can just change the datatypes, after all. But I really
> can't see any use and only harm in adding a silently broken implementation.
Well, in standard I agree. But in this special case is the code just
broken for apps using more then 32-bit address range for heap (and
handles). Btw a run of testsuite works here in pretty much cases.
The patch I sent here is more a head-up (and it fixes build for 32-bit
windows builds, too). If I keep stuff in my back-chamber, things won't
improve and nobody knows that there is an issue present.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: RFA: libjava seems to miss some files for win32
Kai Tietz wrote: > The patch I sent here is more a head-up (and it fixes build for 32-bit > windows builds, too). Ok, I see the point in a headsup (but I'm not sure it was worth spending the time to generate the patch). I take it the sole problem with the 32-bit build is the missing natVMSecureRandomWin32.cc? You should break that out into a separate patch. cheers, DaveK
Re: RFA: libjava seems to miss some files for win32
On 07/19/2009 02:29 PM, Dave Korn wrote: > Kai Tietz wrote: > >> There are a lot of issues about casting HANDLE values into jint types, >> which is for x86 valid, but for x64 can lead potential to pointer >> truncations. Those part need some review by libjava maintainers. My >> patch simply casts those kind of pointers via __UINTPTR_TYPE__ into >> integer scalar before casting it into jint. I put comments at those >> places, where some rework is necessary. > > Argh. You're replacing a bunch of warnings that draw attention to a real > problem by a bunch of silent fixmes in the code. That's a bit scary to me. Me too. That patch will not be accepted. >> Index: gcc/libjava/gnu/java/net/natPlainSocketImplWin32.cc >> === >> --- gcc.orig/libjava/gnu/java/net/natPlainSocketImplWin32.cc 2009-07-19 >> 12:06:54.200476000 +0200 >> +++ gcc/libjava/gnu/java/net/natPlainSocketImplWin32.cc 2009-07-19 >> 12:13:45.727476500 +0200 >> @@ -58,7 +58,8 @@ >> >>// We use native_fd in place of fd here. From leaving fd null we avoid >>// the double close problem in FileDescriptor.finalize. >> - native_fd = (jint) hSocket; >> + // Fixme, it isn't correct to cast a HANDLE to integer scalar here for x64 >> + native_fd = (jint) (__UINTPTR_TYPE__) hSocket; >> } > > > Question is, can we change the sizes of the members of class objects, such > as gnu::java::net::PlainSocketImpl::native_fd, or do these objects and their > layout form part of an ABI, and/or do they ever get serialised? The Java guys > will be able to tell us. Yes, you can change them. Yes, they are part of an ABI. native_fd should be a jlong. Andrew.
Re: RFA: libjava seems to miss some files for win32
Andrew Haley wrote: > > Yes, you can change them. Yes, they are part of an ABI. native_fd should be > a jlong. That's the best possible answer to our questions! Kai? I'll leave this with you; I'm busy tracking down libffi FAILs right now. cheers, DaveK
Can I have some basic BZ perms please?
Hi team, I'd like to have some basic BZ perms if I may, so I can help out with cygwin/win32-related PRs. I'd like to be able to assign bugs to myself (at least ones that I created myself, depending how fine-grained it is), and perhaps be allowed to change status on other bugs too (I occasionally run into already fixed bugs, or bugs waiting for confirmation that I can confirm). Is there a policy? I'm only a WAA contributor, not a maintainer, but I think I can generally be trusted to know what I'm doing :) cheers, DaveK
Re: Can I have some basic BZ perms please?
On Sun, Jul 19, 2009 at 7:29 PM, Dave Korn wrote: > > Hi team, > > I'd like to have some basic BZ perms if I may, so I can help out with > cygwin/win32-related PRs. I'd like to be able to assign bugs to myself (at > least ones that I created myself, depending how fine-grained it is), and > perhaps be allowed to change status on other bugs too (I occasionally run into > already fixed bugs, or bugs waiting for confirmation that I can confirm). Is > there a policy? I'm only a WAA contributor, not a maintainer, but I think I > can generally be trusted to know what I'm doing :) Permissions are automatically granted to people with a gcc.gnu.org login (thus if you have write-after approval SVN access). Just register a new bugzilla user with that e-mail address. Richard.
Re: Can I have some basic BZ perms please?
2009/7/19 Dave Korn :
>
> Hi team,
>
> I'd like to have some basic BZ perms if I may, so I can help out with
> cygwin/win32-related PRs. I'd like to be able to assign bugs to myself (at
> least ones that I created myself, depending how fine-grained it is), and
> perhaps be allowed to change status on other bugs too (I occasionally run into
> already fixed bugs, or bugs waiting for confirmation that I can confirm). Is
> there a policy? I'm only a WAA contributor, not a maintainer, but I think I
> can generally be trusted to know what I'm doing :)
>
> cheers,
> DaveK
>
Do you use for bugzilla your gcc.gnu.org email address?
By doing this you should have some rights more.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: Can I have some basic BZ perms please?
Richard Guenther wrote: > On Sun, Jul 19, 2009 at 7:29 PM, Dave > Korn wrote: >>Hi team, >> >> I'd like to have some basic BZ perms if I may, so I can help out with >> cygwin/win32-related PRs. I'd like to be able to assign bugs to myself (at >> least ones that I created myself, depending how fine-grained it is), and >> perhaps be allowed to change status on other bugs too (I occasionally run >> into >> already fixed bugs, or bugs waiting for confirmation that I can confirm). Is >> there a policy? I'm only a WAA contributor, not a maintainer, but I think I >> can generally be trusted to know what I'm doing :) > > Permissions are automatically granted to people with a gcc.gnu.org > login (thus if you have write-after approval SVN access). Just register > a new bugzilla user with that e-mail address. Ah, I didn't know that. I bet the perms are only generated during account creation and not if I update my existing email address Thanks for the info, Rich and Kai. My gcc addy forwards to my gmail anyway so I'll just do as you suggest. cheers, DaveK
Re: how to use expand_builtin_alloca
Hi, Frank
>Those in turn
>might be represented with almost the normal mf_xform_decls(), while
>letting __builtin_alloca() remain.
How can we just remain __builtin_alloca() only for variable-length array?
Mudflap changes expand_builtin_alloca function.
I think it is enough for apply mudflap in Linux Kernel.
Janboe Ye
2009/7/16 Frank Ch. Eigler :
>
>> Janboe Ye writes:
>
>>> normally gcc will use expand_builtin_alloca to handle variable array.
>>> But mudflap will force this function to return immediately to invoke
>>> alloca explicit.
>>>
>>> Is there some way to still use expand_builtin_alloca without changing
>>> gcc source code?
>
> I don't think so.
>
>
> Ian Lance Taylor writes:
>
>> mudflap can't check accesses to memory allocated using alloca unless
>> it overrides __builtin_alloca.
>
> It can't currently. But instead of redirecting the call to a
> heap-based alloca() wannabe in libmudflap/mf-hooks1.c, perhaps
> mudflap could instrument alloca() by generating code like this
> instead:
>
> __builtin_alloca(N) --> GIMPLE_TRY_FINALLY( try {
> ptr = __builtin_alloca(N)
> __mf_register(ptr ...)
> ptr;
> } finally (attached to the function scope) {
> __mf_unregister(ptr ...)
> }
>
> Or perhaps not, if alloca() can be used in loops in way that
> prevents clean nesting of the try/finally.
>
> OTOH, I believe the original poster's case came from gcc-synthesized
> alloca's, coming from variable-length array allocation. Those in turn
> might be represented with almost the normal mf_xform_decls(), while
> letting __builtin_alloca() remain.
>
> Either of these requires gcc changes though.
>
>
>> [...] Although, of course, you could simply not use mudflap for the
>> code in question.
>
> The original poster's purpose is specifically to build bits of the
> linux kernel with mudflap instrumentation.
>
>
> - FChE
>
gcc-4.3-20090719 is now available
Snapshot gcc-4.3-20090719 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090719/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 149793 You'll find: gcc-4.3-20090719.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090719.tar.bz2 C front end and core compiler gcc-ada-4.3-20090719.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090719.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090719.tar.bz2 C++ front end and runtime gcc-java-4.3-20090719.tar.bz2 Java front end and runtime gcc-objc-4.3-20090719.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090719.tar.bz2The GCC testsuite Diffs from 4.3-20090712 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: current_function_outgoing_args_size
2009/7/18 Ian Lance Taylor : > Mohamed Shafi writes: > >> The change logs says that current_function_outgoing_args_size is no >> more available. But it doesnt say with what it is replaced. Looking at >> the other targets i find that its replaced with some field in a >> structure crtl. Where is this defined/declared. > > crtl is declared in function.h. > >> I am working in GCC 4.4.0. I checked with the mainline internals. Even >> there the references of these deleted variables are not replaced. >> Could somebody please take care of this. > And also references to "regs_ever_live". Regards, Shafi
