Output sections
Hello all, Is it possible to emit a assembler directive at the end of each sections? Say like section_end Is there any support for doing something like this in the back-end files? Or should i need to the make changes in the gcc sources? Is so do does anyone know in which function it should happen? Regards, Shafi
Re: array semantic query
Hi,
I tried the following simple code segment in gcc and it gave the
incompatible type error as mentioned below.
int main() {
int arr[10];
arr = arr; // error: incompatible types when assigning to type
‘int[10]’ from type ‘int *’
}
Here it seems GCC is retaining the left hand side type of arr to be
array of 10 ints whereas on the right hand side
it has changed its type from array to pointer to integer. I tried
searching the relevant sections in the standard ISO C
document number WG14/N1124 justifying the above behaviour of GCC but
failed to conclude it from the specifications.
It would be of great help if someone can point me out the relevant
sections from the specs.
Thanks
Dharmendra
array semantic query
Hi,
I tried the following simple code segment in gcc and it gave the
incompatible type error as mentioned below.
int main() {
int arr[10];
arr = arr; // error: incompatible types when
// assigning to type ‘int[10]’ from type ‘int *’
}
Here it seems GCC is retaining the left hand side type of arr to be
array of 10 ints whereas on the right hand side
it has changed its type from array to pointer to integer. I tried
searching the relevant sections in the standard ISO C
document number WG14/N1124 justifying the above behaviour of GCC but
failed to conclude it from the specifications.
It would be of great help if someone can point me out the relevant
sections from the specs.
Thanks
Dharmendra
Re: i370 port
But sometimes r_or_s_operand is being used as a source, in
which case, the constant is fine. But when it is used as a
destination, it is not fine.
What is the *simplest* way of changing the setup so that the
code generation remains the same, but the warning is eliminated?
Well, I guess you need to do two things:
- Define the PREDICATE_CODES macro -- if this is undefined,
genrecog will consider *any* target-defined predicate as
potentially allowing non-lvalues, because it cannot know
better.
- Actually define two distinct predicates, one that allows
non-lvalue and one that doesn't, and use them as appropriate.
But wondering if there's something simpler and neater.
Well, you could also simply ignore the warning -- nothing
is going to go wrong because of it.
Thanks for pointing me in the right direction Ulrich. Unfortunately
just short of what would have been best for this situation.
I defined the PREDICATE_CODES macro and put in the things
I thought were appropriate:
C:\devel\gcc\gcc\config\i370>cvs diff -r 1.33 -r 1.34 i370.h
Index: i370.h
===
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.33
retrieving revision 1.34
diff -r1.33 -r1.34
200a201,204
#define PREDICATE_CODES \
{"r_or_s_operand", { REG, SUBREG, MEM, CONST_INT }}, \
{"s_operand", { MEM, CONST_INT }},
It had no effect on anything that I could see, but that was to be expected.
I then had a closer look at the machine definitions and realised that some
of them that were defined as r_or_s_operand could instead be
nonimmediate_operand, which started eliminating warnings.
So I proceeded down this track, eliminating things here and there, or
in some cases, opening things up to be more general, with the hope
that I would eventually have things so that the only r_or_s_operand
I needed were ones that didn't require literals, so that I could (at the
end), make this change:
C:\devel\gcc\gcc\config\i370>cvs diff -r 1.34 -r 1.35 i370.h
Index: i370.h
===
RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v
retrieving revision 1.34
retrieving revision 1.35
diff -r1.34 -r1.35
202,203c202,203
< {"r_or_s_operand", { REG, SUBREG, MEM, CONST_INT }}, \
< {"s_operand", { MEM, CONST_INT }},
---
{"r_or_s_operand", { REG, SUBREG, MEM }}, \
{"s_operand", { MEM }},
and something similar in i370.c, to make constants invalid, so that I
could eliminate the warnings.
It took a month to do that, because I kept on being hit by presumed
bugs, which started generating bad or unexpected code when I made
a seemingly innocuous change. To make matters worse, sometimes
I could only find out whether the code was good or not by running it on
MVS, via the emulator, which means a 2 hour wait for a result.
However, I did get it down to just a handful of warnings, which would
be eliminated now that I could drop the CONST_INT. And I would
check the generated code to see what I had missed when I took
off the CONST_INT.
Anyway, I took off the CONST_INT, and the warnings all disappeared,
and the code didn't change!
I then found out that even with old versions of the machine definition,
I can have the warning removed by simply not defining CONST_INT
in the PREDICATE_CODES, even though it is allowed when the
function is called. ie it seems to have no effect on the code
generation, but succeeds in eliminating the warning, and without
needing to define an extra constraint for non-constant situations.
So I've revamped the machine definition unnecessarily. Well, I
did make things defined more consistently, and did make code
generation improvements, but they're not major, and I wouldn't
have done any of it if I knew I could have just defined a predicate
that wasn't really going to be used.
Oh well. At the end of the day, the warning has gone, the code
is better and the machine definition is more correct. :-)
I've also got 3.4.6 working to some extent. I have managed to
build an single GCC executable, and if I call it with no parameters,
it prints its usage (as designed).
However, if I try to pass parameters it doesn't recognize them.
It could be something to do with not having run the appropriate
stuff through bison (or flex) on an EBCDIC platform.
Normally I use this to get around that problem:
C:\devel\gccnew\gcc>cvs diff -r release-3_4_6 c-parse.c
Index: c-parse.c
===
RCS file: c:\cvsroot/gccnew/gcc/c-parse.c,v
retrieving revision 1.1.1.1
retrieving revision 1.4
diff -r1.1.1.1 -r1.4
497a498,503
#if defined(__MVS__) || defined(__CMS__)
#define YYTRANSLATE(YYX) \
((unsigned int) (YYX) <= YYMAXUTOK ? \
((unsigned int) (YYX) < 256 ? yytranslate[_sch_ebcasc[YYX]] \
: yytranslate[YYX]) : YYUNDEFTOK)
#else
499a506
#endif
But perhaps the new gengtyp lex and yacc, although not used in the
actual GCC executable,
Re: Output sections
Mohamed Shafi wrote: > Hello all, > > Is it possible to emit a assembler directive at the end of each sections? > Say like section_end > Is there any support for doing something like this in the back-end files? > Or should i need to the make changes in the gcc sources? > Is so do does anyone know in which function it should happen? There isn't really such a concept as 'end of a section' until you get to final-link time and get all the contributions from different .o files to a given section. During assembler output GCC treats sections as random access, switching freely from one to another and back; it doesn't have any concept of starting/stopping/opening/closing a section but just jumps into any one it likes completely ad-hoc. Assuming you're happy with adding something to the end of each section in each generated .s file, you could use the TARGET_ASM_FILE_END hook to output directives that re-enter each used section and then output your new directive. You may find it hard to know which sections have been used or not in a given file - you can define TARGET_ASM_NAMED_SECTION and make a note of which sections get invoked there, but I'm not sure if that gets called for all sections e.g. init/fini, you may have to try it and see. cheers, DaveK
Re: array semantic query
According to 6.3.2.1 Para 3, the type conversion from "array of type"
to "pointer to type" should
happen irrespective of whether the operand is on right had side or the
left hand side of assignment
operator. But GCC is converting only the right side operator type to
"pointer of type" while retaining the
left hand side type to be "array of type".
-Dharmendra
On Sat, Jul 18, 2009 at 3:51 PM, Andrew Haley wrote:
> On 07/18/2009 10:35 AM, dharmendra pandit wrote:
>> Hi,
>>
>> I tried the following simple code segment in gcc and it gave the
>> incompatible type error as mentioned below.
>>
>> int main() {
>> int arr[10];
>> arr = arr; // error: incompatible types when assigning to type
>> ‘int[10]’ from type ‘int *’
>> }
>>
>> Here it seems GCC is retaining the left hand side type of arr to be
>> array of 10 ints whereas on the right hand side
>> it has changed its type from array to pointer to integer. I tried
>> searching the relevant sections in the standard ISO C
>> document number WG14/N1124 justifying the above behaviour of GCC but
>> failed to conclude it from the specifications.
>> It would be of great help if someone can point me out the relevant
>> sections from the specs.
>
> 6.3.2.1 Para 3.
>
> I'm surprised you ask, since this convention has been used since early
> K&R C.
>
> Andrew.
>
>
Re: array semantic query
On Sat, Jul 18, 2009 at 2:18 PM, dharmendra
pandit wrote:
> According to 6.3.2.1 Para 3, the type conversion from "array of type"
> to "pointer to type" should
> happen irrespective of whether the operand is on right had side or the
> left hand side of assignment
> operator. But GCC is converting only the right side operator type to
> "pointer of type" while retaining the
> left hand side type to be "array of type".
An array is never a valid lvalue in C. The error is slightly misleading.
Richard.
> -Dharmendra
>
> On Sat, Jul 18, 2009 at 3:51 PM, Andrew Haley wrote:
>> On 07/18/2009 10:35 AM, dharmendra pandit wrote:
>>> Hi,
>>>
>>> I tried the following simple code segment in gcc and it gave the
>>> incompatible type error as mentioned below.
>>>
>>> int main() {
>>> int arr[10];
>>> arr = arr; // error: incompatible types when assigning to type
>>> ‘int[10]’ from type ‘int *’
>>> }
>>>
>>> Here it seems GCC is retaining the left hand side type of arr to be
>>> array of 10 ints whereas on the right hand side
>>> it has changed its type from array to pointer to integer. I tried
>>> searching the relevant sections in the standard ISO C
>>> document number WG14/N1124 justifying the above behaviour of GCC but
>>> failed to conclude it from the specifications.
>>> It would be of great help if someone can point me out the relevant
>>> sections from the specs.
>>
>> 6.3.2.1 Para 3.
>>
>> I'm surprised you ask, since this convention has been used since early
>> K&R C.
>>
>> Andrew.
>>
>>
>
Re: array semantic query
> Here it seems GCC is retaining the left hand side type of arr to be > array of 10 ints whereas on the right hand side > it has changed its type from array to pointer to integer. I tried And rightly so. > searching the relevant sections in the standard ISO C > document number WG14/N1124 justifying the above behaviour of GCC but > failed to conclude it from the specifications. The C99 spec (I only have the draft one, but I think it's pretty much the same as the final) says, in 6.2.2.3: Except when it is the operand of the sizeof operator or the unary & operator, or is a character string literal used to initialize an array of character type, or is a wide string literal used to initialize an array with element type compatible with wchar_t, an lvalue that has type ‘‘array of type ’’ is converted to an expression that has type ‘‘pointer to type ’’ that points to the initial element of the array object and is not an lvalue. If the array object has register storage class, the behavior is undefined. That was spelled out (with different words) in the old K&R C and hasn't changed since. You can't assign arrays. Since ANSI C you can assign, pass and return structures and unions, but the array semantics did not change. Regards, Zoltan
current_function_outgoing_args_size
Hello all, 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. 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. Regards, Shafi
Re: RFA: libjava seems to miss some files for win32
Kai Tietz wrote: > Hello, > > I noticed, while trying to build libjava for x64 windows, that the > configure script fails to generate link to > 'libjava/gnu/java/security/jce/prng/natVMSecureRandomWin32.cc'. This > file isn't existing. Is there a fix for this? > > Thanks in advance for the answer, > Kai > You probably want to post this to the main list rather than -patches! Also the java list, I would suppose. The bug is strange. I get nothing from "grep -R SecureRandomWin32 libjava/*" in my sandbox (but I'm still on r.149334 from 07/07). cheers, DaveK
Re: RFA: libjava seems to miss some files for win32
2009/7/18 Dave Korn :
> Kai Tietz wrote:
>> Hello,
>>
>> I noticed, while trying to build libjava for x64 windows, that the
>> configure script fails to generate link to
>> 'libjava/gnu/java/security/jce/prng/natVMSecureRandomWin32.cc'. This
>> file isn't existing. Is there a fix for this?
>>
>> Thanks in advance for the answer,
>> Kai
>>
>
> You probably want to post this to the main list rather than -patches! Also
> the java list, I would suppose. The bug is strange. I get nothing from "grep
> -R SecureRandomWin32 libjava/*" in my sandbox (but I'm still on r.149334 from
> 07/07).
Yes, I missed to add java maintainer and the patch here.
I noticed, while trying to build libjava for x64 windows, that the
configure script fails to generate link to
'libjava/gnu/java/security/jce/prng/natVMSecureRandomWin32.cc'. This
file isn't existing.
The attached patch fixes this. The implementation is straight forward,
but works for win32 api. The random value generation could be improved
here.
ChangeLog
2009-07-18 Kai Tietz
* gnu/java/security/jce/prng/natVMSecureRandomWin32.cc: Implementation
for native win32.
Tested for x86 and x64 mingw targets. 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-18 14:35:14.102884300 +0200
@@ -0,0 +1,44 @@
+// 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)
+{
+ static int was_init = 0;
+ int a;
+ jbyte *bytes = elements (byte_array);
+ ssize_t count = 0;
+
+ if (!was_init)
+{
+ srand (256);
+ was_init = 1;
+}
+ for (a = 0; a < offset; ++a)
+bytes++;
+ for (a = 0; a < length; a++, count++)
+ *bytes++= (jbyte) rand ();
+
+ return count;
+}
+
Re: current_function_outgoing_args_size
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. Cc'ing Jan, since he removed the accessor macros. Ian
Re: RFA: libjava seems to miss some files for win32
Kai Tietz wrote: > * gnu/java/security/jce/prng/natVMSecureRandomWin32.cc: Implementation > for native win32. > > Tested for x86 and x64 mingw targets. Ok for apply? + for (a = 0; a < length; a++, count++) + *bytes++= (jbyte) rand (); Surely not, the standard C library rand() function is completely unsuitable for security purposes. It should use the win32 crypto api to get real high-quality random data I think. cheers, DaveK
Re: RFA: libjava seems to miss some files for win32
2009/7/18 Dave Korn :
> Kai Tietz wrote:
>
>> * gnu/java/security/jce/prng/natVMSecureRandomWin32.cc: Implementation
>> for native win32.
>>
>> Tested for x86 and x64 mingw targets. Ok for apply?
>
> + for (a = 0; a < length; a++, count++)
> + *bytes++= (jbyte) rand ();
>
> Surely not, the standard C library rand() function is completely unsuitable
> for security purposes. It should use the win32 crypto api to get real
> high-quality random data I think.
>
> cheers,
> DaveK
>
>
Yes, I agree to this as I said in the patch post. Can we assume that
any win32 target has a working wincrypt.h file?
I just suggested this patch, to have at least an implementation here
for win32 for further improvement (Btw I missed in my initial patch to
include explicit here, too).
I am just running through libjava for an initial port for x64 windows.
There are a lot of assumptions about sizeof (long) == sizeof (void*),
but the worse thing I see is the casting of HANDLE values to jint. For
x86 this is fine, but for x64 this can lead to serious troubles.
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: > Yes, I agree to this as I said in the patch post. Can we assume that > any win32 target has a working wincrypt.h file? Hmmm... it is supported since win2k. I imagine DGJPP runs on 9x targets, and believe it or not there are still some Cygwin users on NT4. I would think it needs an autoconf test, and on platforms that don't support CryptoAPI it should probably throw an exception to indicate 'not implemented' rather than (e.g.) fall back to rand(), but that's a policy decision for the Java maintainers really. > I just suggested this patch, to have at least an implementation here > for win32 for further improvement (Btw I missed in my initial patch to > include explicit here, too). > I am just running through libjava for an initial port for x64 windows. > There are a lot of assumptions about sizeof (long) == sizeof (void*), > but the worse thing I see is the casting of HANDLE values to jint. For > x86 this is fine, but for x64 this can lead to serious troubles. Ouch, yes! You'll probably be best off replacing those with something based on uintptr_t, which may or may not have a j* equivalent already. cheers, DaveK
Re: RFA: libjava seems to miss some files for win32
Kai Tietz wrote: Oh, I forgot to address: > I just suggested this patch, to have at least an implementation here > for win32 for further improvement This is the java security package. Having a vulnerable implementation is worse IMO than having none at all; I think it would be better to just throw an exception than use rand(), so if you want a patch to just get the build working, that would be a fairly simple solution. cheers, DaveK
Re: RFA: libjava seems to miss some files for win32
On 07/18/2009 07:27 PM, Dave Korn wrote: > Kai Tietz wrote: > >> Yes, I agree to this as I said in the patch post. Can we assume that >> any win32 target has a working wincrypt.h file? > > Hmmm... it is supported since win2k. I imagine DGJPP runs on 9x targets, > and believe it or not there are still some Cygwin users on NT4. I would think > it needs an autoconf test, and on platforms that don't support CryptoAPI it > should probably throw an exception to indicate 'not implemented' rather than > (e.g.) fall back to rand(), but that's a policy decision for the Java > maintainers really. Either this is a cryptographically strong random number or it must throw NotImplemented. >> I just suggested this patch, to have at least an implementation here >> for win32 for further improvement (Btw I missed in my initial patch to >> include explicit here, too). >> I am just running through libjava for an initial port for x64 windows. >> There are a lot of assumptions about sizeof (long) == sizeof (void*), >> but the worse thing I see is the casting of HANDLE values to jint. For >> x86 this is fine, but for x64 this can lead to serious troubles. > > Ouch, yes! You'll probably be best off replacing those with something based > on uintptr_t, which may or may not have a j* equivalent already. Don't use uintptr_t, use unsigned int __attribute__((mode(PTR)). This is built-in to gcc, not a dependency on the host libc which might not be c99.. Andrew.
Re: RFA: libjava seems to miss some files for win32
On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote: > Don't use uintptr_t, use unsigned int __attribute__((mode(PTR)). This > is built-in to gcc, not a dependency on the host libc which might not > be c99..' Except uintptr_t is required to be provided by a non hosted compiler like GCC. -- Pinski
Re: RFA: libjava seems to miss some files for win32
2009/7/18 Andrew Pinski :
> On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote:
>> Don't use uintptr_t, use unsigned int __attribute__((mode(PTR)). This
>> is built-in to gcc, not a dependency on the host libc which might not
>> be c99..'
>
> Except uintptr_t is required to be provided by a non hosted compiler like GCC.
>
> -- Pinski
>
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.
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
Andrew Pinski wrote: > On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote: >> Don't use uintptr_t, use unsigned int __attribute__((mode(PTR)). This >> is built-in to gcc, not a dependency on the host libc which might not >> be c99..' > > Except uintptr_t is required to be provided by a non hosted compiler like GCC. Come to think of it, we should use the __UINTPTR_TYPE__ thingy provided by jsm's recent stdint patch, shouldn't we? cheers, DaveK
Re: RFA: libjava seems to miss some files for win32
2009/7/18 Dave Korn :
> Andrew Pinski wrote:
>> On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote:
>>> Don't use uintptr_t, use unsigned int __attribute__((mode(PTR)). This
>>> is built-in to gcc, not a dependency on the host libc which might not
>>> be c99..'
>>
>> Except uintptr_t is required to be provided by a non hosted compiler like
>> GCC.
>
> Come to think of it, we should use the __UINTPTR_TYPE__ thingy provided by
> jsm's recent stdint patch, shouldn't we?
>
> cheers,
> DaveK
>
Well, this sounds good. I wasn't aware that __UINTPTR_TYPE__ is
present. I just was aware of the SIZE, and PTRDIFF builtin macros,
which aren't useful here for all targets.
Maybe a __ULONGPTR_TYPE__ should be added as internal macro, too.
Because sometimes the widest scalar type between MAX(sizeof(long),
sizeof(void *)) is necessary, too. E.g. in libiberty there are such
cases I remember.
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
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
Re: Order To New Zealand
Bryan James wrote: Hello there, Greetings from BJS New Zealand Pty Ltd. My name is Bryan James the CEO of the company. i will like to place order on some products in your company,but i would like to know if you ship to Christchurch, New Zealand and also do you accept Visa or Master card as method of payment? Please do not forget to include your web page in your replying back to my message and get back to me as fast as possible so that i can let you know the product i would like to order. Please email me back with the current price list on the products if you website is not updated. Thank you Yours Sincerely, Bryan James These scams are coming from New Zealand now too?? Very disappointed. Nicholas Sherlock, New Zealand
Vectorizing invariant data-ref
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. Thanks, Revital (See attached file: test41.f90.txt) MODULE foo_mod USE parameter_mod, ONLY : rfp IMPLICIT NONE PUBLIC foo1 PRIVATE real(kind=rfp), dimension(:,:,:), allocatable :: arr1 CONTAINS SUBROUTINE foo1(nx,ny,nz,arr2) USE globalvar_mod, ONLY : dyinv, xstart, xstop integer, intent(in) :: nx, ny, nz real(kind=rfp), intent(inout),& dimension(xstart:xstop+1,xstart:xstop+1,xstart:xstop+1) :: arr2 integer :: i, j, k 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 END MODULE foo_mod
