Hi all!
I've made a toolchain for mips64el - binutils 2.17.90 + gcc 3.3.6 + glibc 2.3.6.
I've successfully compile a linux 2.16.62 kernel and run it in qemu.
But when I try to execute dynamically compiled Hello world program - I' ve
got a SIGSEGV
do_page_fault() #2: sending SIGSEGV to a.out for
Sergey Anosov wrote:
Does anybody have such problem? Or mips64 platform and gcc 3.3.6 are not
compatible?
If I were you, considering how old and currently completely unmaintained
it is, I would leave gcc3.3.x alone...
Paolo.
Hmm, it seems 3.2.x would *always* operate on a function-by-function
basis. The unit-at-a-time mode was only introduced with 3.4 (I don't
recall if it was already present in 3.3). I don't think there is any
way in 3.2.3 to check whether there is a main function in the file
before it is
When debugging graphite, we ran into code bloat issues due to
pass_complete_unrolli being called very early in the non-ipa
optimization sequence. Much later, the full-blown pass_complete_unroll
is scheduled, and this one does not do any harm.
Strangely, this early unrolling pass (tuned to only
My experience is that fold-const.c requires 20 MB of memory (not
including the size of the executable) to compile with -Os. That's
the biggest.
Is that typical/expected?
It doesn't seem too big.
Because it just occurred to me that maybe the lack of a normal
implementation of alloca() is
2009/8/19 Albert Cohen albert.co...@inria.fr:
When debugging graphite, we ran into code bloat issues due to
pass_complete_unrolli being called very early in the non-ipa
optimization sequence. Much later, the full-blown pass_complete_unroll
is scheduled, and this one does not do any harm.
On Wed, Aug 19, 2009 at 2:07 PM, Richard
Guentherrichard.guent...@gmail.com wrote:
2009/8/19 Albert Cohen albert.co...@inria.fr:
When debugging graphite, we ran into code bloat issues due to
pass_complete_unrolli being called very early in the non-ipa
optimization sequence. Much later, the
I haven't been able to connect to #gcc today. Is anyone else having
trouble connecting?
Diego.
On Wed, Aug 19, 2009 at 1:27 PM, Diego Novillodnovi...@google.com wrote:
I haven't been able to connect to #gcc today. Is anyone else having
trouble connecting?
Wonder if it is something else . I've been connected pretty much all
day and things seem to be working.
Ramana
Diego.
OFTC is rejecting all connections from me as well.
David
On Wed, Aug 19, 2009 at 8:33 AM, Ramana Radhakrishnanraman...@gmail.com wrote:
On Wed, Aug 19, 2009 at 1:27 PM, Diego Novillodnovi...@google.com wrote:
I haven't been able to connect to #gcc today. Is anyone else having
trouble
On Wed, Aug 19, 2009 at 08:35, David Edelsohndje@gmail.com wrote:
OFTC is rejecting all connections from me as well.
It seems to have dropped out of name servers. I get this from 3
different networks.
$ nslookup irc.oftc.net
;; connection timed out; no servers could be reached
Diego.
Richard Guenther wrote:
2009/8/19 Albert Cohen albert.co...@inria.fr:
When debugging graphite, we ran into code bloat issues due to
pass_complete_unrolli being called very early in the non-ipa
optimization sequence. Much later, the full-blown pass_complete_unroll
is scheduled, and this one
HI,
I am trying to port a 32bit target in GCC 4.4.0. My target supports
big and little endian. This is selected using a target switch. So i
have defined the macro
#define WORDS_BIG_ENDIAN (TARGET_BIG_ENDIAN)
Currently i have written pattens only for SImode moves. So GCC will
synthesize DImode
Albert Cohen wrote:
Thanks a lot for the quick and detailed response.
It is more difficult than I thought, then :-( We'll think more, and
maybe come up with yet another pass ordering proposal, but definitely
this tramp3d code deserves to be processed by graphite AFTER
unrolling+cse has done
On Wed, Aug 19, 2009 at 3:54 PM, Albert Cohenalbert.co...@inria.fr wrote:
Albert Cohen wrote:
Thanks a lot for the quick and detailed response.
It is more difficult than I thought, then :-( We'll think more, and
maybe come up with yet another pass ordering proposal, but definitely
this
On Wed, Aug 19, 2009 at 3:56 PM, Richard
Guentherrichard.guent...@gmail.com wrote:
On Wed, Aug 19, 2009 at 3:54 PM, Albert Cohenalbert.co...@inria.fr wrote:
Albert Cohen wrote:
Thanks a lot for the quick and detailed response.
It is more difficult than I thought, then :-( We'll think more,
Hi all:
I'm currently studying implementation of instruction sched in gcc.
it is possible to schedule insns directly from queue in case
there is nothing better to do and there are still vacant dispatch slots
in the current cycle.
Gcc only does this work in the second pass, but what's the
Amker.Cheng amker.ch...@gmail.com writes:
I'm currently studying implementation of instruction sched in gcc.
it is possible to schedule insns directly from queue in case
there is nothing better to do and there are still vacant dispatch slots
in the current cycle.
Gcc only does this work
Gcc only does this work in the second pass, but what's the
point? Is it wrong or just not necessary in the first sched
pass?
Regardless of the target architecture from the correctness point of view sched1
can be disabled. sched1 has as purpose shortening live ranges.
Short live ranges allow
I am quoting from several different messages.
On 8/17/09, Joseph S. Myers jos...@codesourcery.com wrote:
(A) Code compiled against headers from libc version X must be run
with libc version X or later.
What is the symptom of failing to meet this constraint?
(B) Code compiled against headers
Somehow I can't help but think I'm missing something here...
Given:
(set (reg X) (mem Y))
(...)
(set (mem Y) (reg Z))
(...)
(use (reg X))
update_equiv_regs can set an equivalence between (reg X) and (mem Y)
which is clearly wrong as (mem Y) is set to (reg Z).
99.99% of the
Jeff Law l...@redhat.com writes:
Somehow I can't help but think I'm missing something here...
Given:
(set (reg X) (mem Y))
(...)
(set (mem Y) (reg Z))
(...)
(use (reg X))
update_equiv_regs can set an equivalence between (reg X) and (mem Y)
which is clearly wrong as
When browsing e.g. gcc-cvs via the web it used to be possible to click on a
newly added file and get a 'download raw' (I think it was called) option to
see the file without all that idiotic html formatting. That seems to be gone
now. For me, at least, this is extremely counterproductive.
On Wed, 19 Aug 2009, Lawrence Crowl wrote:
I am quoting from several different messages.
On 8/17/09, Joseph S. Myers jos...@codesourcery.com wrote:
(A) Code compiled against headers from libc version X must be run
with libc version X or later.
What is the symptom of failing to meet
Mikael Pettersson mi...@it.uu.se writes:
When browsing e.g. gcc-cvs via the web it used to be possible to click on a
newly added file and get a 'download raw' (I think it was called) option to
see the file without all that idiotic html formatting. That seems to be gone
now. For me, at least,
On 08/19/09 17:46, Ian Lance Taylor wrote:
My understanding is that that scenario is supposed to not happen because
update_equiv_regs is only supposed to equate a register and a memory
location in the specific cases where that is OK. It's not no_equiv that
is supposed to fix this, the
Jeff Law l...@redhat.com writes:
You're right. This should have been rejected by validate_equiv_mem,
but isn't because the two memory references are in different alias
sets.
You can see this in the mainline sources configured for
i686-pc-linux-gnu by compiling
On 8/19/09, Joseph S. Myers jos...@codesourcery.com wrote:
On Wed, 19 Aug 2009, Lawrence Crowl wrote:
I am quoting from several different messages.
On 8/17/09, Joseph S. Myers jos...@codesourcery.com wrote:
(A) Code compiled against headers from libc version X must be run
with
Richard Guenther wrote:
gfortran.dg/reassoc_4.f, the hottest loop from calculix.
Thanks.
This example is slightly different. Graphite should be able to handle it
with loop fusion rather than pre-unrolling + cse. But I agree that the
unrolling + cse approach also makes sense (and does not
On Tue, 2009-08-18 at 08:43 -0700, Richard Henderson wrote:
On 08/17/2009 07:40 PM, Jerry Quinn wrote:
On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote:
I'm not sure why GCC sources would need to mangle function-local
structs, though.
Would it be helpful to reserve a leading
--- Comment #1 from bje at gcc dot gnu dot org 2009-08-19 06:14 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bje at gcc dot gnu dot org 2009-08-19 06:14 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bje at gcc dot gnu dot org 2009-08-19 06:15 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bje at gcc dot gnu dot org 2009-08-19 06:30 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-19 06:38 ---
I believe this is has an origin that could be related to PR41113
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933
--- Comment #8 from burnus at gcc dot gnu dot org 2009-08-19 06:38 ---
Subject: Bug 41102
Author: burnus
Date: Wed Aug 19 06:38:29 2009
New Revision: 150931
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150931
Log:
2009-08-19 Tobias Burnus bur...@net-b.de
PR
--- Comment #9 from burnus at gcc dot gnu dot org 2009-08-19 07:01 ---
Subject: Bug 41102
Author: burnus
Date: Wed Aug 19 07:01:03 2009
New Revision: 150932
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150932
Log:
2009-08-19 Tobias Burnus bur...@net-b.de
PR
--- Comment #10 from burnus at gcc dot gnu dot org 2009-08-19 07:12 ---
Subject: Bug 41102
Author: burnus
Date: Wed Aug 19 07:11:43 2009
New Revision: 150933
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150933
Log:
2009-08-19 Tobias Burnus bur...@net-b.de
PR
--- Comment #11 from burnus at gcc dot gnu dot org 2009-08-19 07:14 ---
The lib_omp.h problem is FIXED on the trunk (4.5) and in the 4.3 and 4.4
branches.
I changed the title to the remaining issue: Having (similarity to C/C++) a
less strict checking for files coming from the system
This is on an AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (using openSUSE
Factory in x86-64 mode).
When compiling the Polyhedron induct.f90 test case with and without
vectorization, the run time with vectorization is 30% longer. I think the
vectorization cost model needs to be tuned for this
--- Comment #4 from jakub at gcc dot gnu dot org 2009-08-19 08:29 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenther at suse dot de 2009-08-19 08:30 ---
Subject: Re: [4.5 Regression] FAIL:
gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
On Tue, 18 Aug 2009, dominiq at lps dot ens dot fr wrote:
--- Comment #2 from dominiq at lps dot ens
--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-19 08:58 ---
an ugly workaround is to write instead of
CALL S1(d%data)
the following
CALL S1(d%data(1))
which works in simple cases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
--- Comment #2 from ramana at gcc dot gnu dot org 2009-08-19 08:59 ---
(In reply to comment #1)
This fails for me with r149508 with a reload failure.
I don't seem to have a reload failure for this with 150624.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
Another case of a spurious pack (which really affects performance
unfortunately).
cat test.f90
MODULE M1
CONTAINS
SUBROUTINE S1(data)
REAL, DIMENSION(*) :: data
END SUBROUTINE S1
END MODULE
SUBROUTINE S2
REAL :: data(10,10)
DO i=1,10
CALL S1(data(:,i))
ENDDO
DO i=1,10
CALL
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-19 10:14 ---
more useless temps...the last two added eat quite a few percent of performance
in CP2K.
This really is an issue where frontend people need to step in to improve the
performance of gfortran.
--
jv244 at cam dot ac
--- Comment #12 from mikpe at it dot uu dot se 2009-08-19 10:38 ---
ICE confirmed with a gcc-4.4.1 cross to m68k-linux. Applying the PR37053 and
PR41064 fixes eliminated the ICE.
The mpegvideo.i test case does not compile as-is for me, as the compiler
complains about a syntax error:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-19 10:38 ---
The testcase was reduced to an invalid one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-19 11:15 ---
I'm reducing again, from a single-file testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from abnikant dot singh at atmel dot com 2009-08-19 11:57
---
If HARD_REGNO_MODE_OK (r, mode1) and HARD_REGNO_MODE_OK (r, mode2) are always
the same for any r, then MODES_TIEABLE_P (mode1, mode2) should be nonzero. If
they differ for any r, you should define this macro
Consider this example:
cat pr41118.c EOF
void foo(int n, int *a, int *b)
{
int i;
for (i = 0; i n; i++)
a[i] = b[i];
}
EOF
gcc -S -O2 pr41118.c -floop-parallelize-all -ftree-parallelize-loops=2
grep GOMP 41118.s
GCC considers the loop parallel, even though arrays pointed to by
--- Comment #18 from jv244 at cam dot ac dot uk 2009-08-19 13:03 ---
pointing Toon to some lto timing/memory usage data for 'large' Fortran
programs..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41069#c12
--
jv244 at cam dot ac dot uk changed:
What|Removed
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-19 13:30 ---
Created an attachment (id=18401)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18401action=view)
Draft patch - first steps but incomplete will not work
The problem is:
CALL S1(d%data)
We have the variable
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-19 13:36 ---
See also PR 41113
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41117
Revision 150805:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00485.html
caused:
g++ -c -o mg_dof_tools.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS
-Ddeal_II_dimension=3 -O2 -ffast-math -DSPEC_CPU_LP64 mg_dof_tools.cc
g++ -c -o mg_smoother.o -DSPEC_CPU -DNDEBUG -Iinclude
--- Comment #1 from hjl dot tools at gmail dot com 2009-08-19 14:12 ---
It doesn't fail with preprocessed code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41119
--- Comment #2 from hjl dot tools at gmail dot com 2009-08-19 14:18 ---
Valgrind reports:
==22210== Invalid read of size 2
==22210==at 0x51521D: is_empty_class (class.c:6524)
==22210==by 0x482E70: build_call_a (call.c:356)
==22210==by 0x483FF2: build_cxx_call (call.c:5782)
-languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.5.0 20090819 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps
--- Comment #1 from rubidium at openttd dot org 2009-08-19 14:30 ---
Created an attachment (id=18402)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18402action=view)
save-temps data
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41120
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-19 14:31 ---
See PR41120 for a testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Component|middle-end
--- Comment #1 from ubizjak at gmail dot com 2009-08-19 14:51 ---
Fixed in r150929.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-08-19 15:02 ---
It is caused by revision 150805:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00485.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41120
--- Comment #4 from hjl dot tools at gmail dot com 2009-08-19 15:06 ---
(gdb) bt
#0 0x005cec03 in is_empty_class (type=0xa5a5a5a5a5a5a5a5)
at ../../src/gcc/cp/class.c:6524
#1 0x0048 in build_call_a (function=0x70593e40, n=1,
argarray=0x7fffc750) at
With version r150889, compiling several BLAS and LAPACK source files produce
errors with the '-fimplicit-none' flag. For instance, when building
http://www.netlib.org/blas/dgbmv.f I get the following error message:
gfortran -c -fimplicit-none dgbmv.f
dgbmv.f:297.72:
END
--- Comment #29 from mahatma at eu dot by 2009-08-19 19:08 ---
(In reply to comment #28)
...
This is not mine and isn't needed.
OK. New patch working. While only so (tested in seamonkey with all included
libs).
Are realigning needed for both states of TREE_STATIC (decl)? Now in
--- Comment #2 from oliver dot kellogg at eads dot com 2009-08-19 18:54
---
Ada is not a default language currently and has not been since 4.0.0.
I find that counter-intuitive - how come all other languages are built,
just Ada is not?
--
introduced in the last few days:
gfortran -c small.f90
small.f90: In function write_cputime:
small.f90:1:0: internal compiler error: in gfc_conv_string_tmp, at
fortran/trans-expr.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html
--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-19 19:21 ---
guessing:
2009-08-17 Janus Weil ja...@gcc.gnu.org
PR fortran/40877
* array.c (gfc_resolve_character_array_constructor): Add NULL argument
to gfc_new_charlen.
* decl.c
--- Comment #2 from dominiq at lps dot ens dot fr 2009-08-19 19:26 ---
Confirmed with trunk revision 150825, the code compiles for 4.2.4, 4.3.4,
4.4.1, and 4.5.0 revision 147438.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41126
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-19 19:40 ---
I think we finally should enable ada and obj-c++ by default if all requirements
are met.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-19 19:40 ---
Subject: Bug 41071
Author: rguenth
Date: Wed Aug 19 19:40:28 2009
New Revision: 150943
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150943
Log:
2009-08-19 Richard Guenther rguent...@suse.de
*
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-19 19:43 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from oliver dot kellogg at eads dot com 2009-08-19 20:42
---
I think we finally should enable ada and obj-c++ by default if all
requirements
are met.
Could you point me to the relevant discussion about these requirements?
Thanks.
--
The following code:
#define CHAR_BIT 8
enum EE {ee};
typedef unsigned int T;
struct D {
T : sizeof(unsigned int) * CHAR_BIT; // OK
EE : sizeof(EE) * CHAR_BIT; // OK
enum EE : sizeof(EE) * CHAR_BIT; // not OK
enum EE : sizeof(EE) * CHAR_BIT; // OK
T
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-19 21:02 ---
Requirements as in configure detects a host ada compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41124
--- Comment #7 from robert dot mance at intel dot com 2009-08-19 21:28
---
I've managed to download and install 4.4.5 of gfortran and can verify that what
you're doing here is just about identical to what ifort is doing.
I have a request to emit a DW_TAG_common_inclusion record in
--- Comment #4 from carrot at google dot com 2009-08-19 21:55 ---
(In reply to comment #2)
Why does the basic block reordering pass also not handle this?
Basic block reordering is disabled with options -Os.
The basic block reordering algorithm is for performance only, it usually
--- Comment #2 from jakub at gcc dot gnu dot org 2009-08-19 22:51 ---
Subject: Bug 41123
Author: jakub
Date: Wed Aug 19 22:51:20 2009
New Revision: 150946
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150946
Log:
PR middle-end/41123
* expr.c (expand_expr_real_1)
--- Comment #3 from jakub at gcc dot gnu dot org 2009-08-19 22:52 ---
Subject: Bug 41123
Author: jakub
Date: Wed Aug 19 22:52:11 2009
New Revision: 150947
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150947
Log:
PR middle-end/41123
* expr.c (expand_expr_real_1)
--- Comment #4 from jakub at gcc dot gnu dot org 2009-08-19 22:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from kargl at gcc dot gnu dot org 2009-08-19 23:00 ---
Here's the backtrace
#0 gfc_conv_string_tmp (se=0x7fffdd70, type=0x201afec00, len=0x201af8d20)
at ../../gcc4x/gcc/fortran/trans-expr.c:1107
#1 0x0050c0be in gfc_conv_intrinsic_adjust (se=0x7fffdd70,
--- Comment #5 from rth at gcc dot gnu dot org 2009-08-19 23:06 ---
Basic block reordering *should* be altered to work with -Os.
It's definitely required to clean up silly jump sequences that
exception handling creates.
There's no reason, in principal, that the ordering algorithm
can't
6 honappal ezelott egy nagyszabasu hadmuveletbe fogtak a magyar jatekosok a
neten.
eMagyarorszag roman megszallas ala kerult,es vissza akartunk vagni.
4 honapig tatott a csata. 16 ezer magyar jatekos gyurte a a 18 ezres roman
sereget.
Es nyertunk.Visszafoglaltuk eMagyarorszagot, es
--- Comment #7 from joseph at codesourcery dot com 2009-08-19 23:58 ---
Subject: Re: 'configure' checks for Ada compiler but
does not build one
On Wed, 19 Aug 2009, jakub at gcc dot gnu dot org wrote:
obj-c++ isn't built by default either. And in both cases it is intentional.
It
The command line input
$ gcc max_memory.c -o max_memory.exe
currently gives
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot
find -luser32
collect2: ld returned 1 exit status
The command worked fine initially. Any suggestion as to correcting error would
be greatly
checking for wchar.h... (cached) yes
checking for wctype.h... (cached) yes
checking for ld version... 21901
checking for ld that supports -Wl,--gc-sections... configure: error:
Link tests are not allowed after GCC_NO_EXECUTABLES.
make[2]: *** [configure-target-libstdc++-v3] Error 1
The following code segment
program scr
type S1
real, dimension(:), pointer :: P ! NLEV
real, dimension(:), pointer :: t ! NLEV
end type S1
type S0
real, dimension(:), pointer :: P ! NLEV
end type S0
type (S0) :: x0
type (S1) :: x1
write
--- Comment #1 from evan dot fishbein at jpl dot nasa dot gov 2009-08-20
04:11 ---
(In reply to comment #0)
The following code segment
program scr
type S1
real, dimension(:), pointer :: P ! NLEV
real, dimension(:), pointer :: t ! NLEV
end type
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-20 04:42 ---
This is a bug in your installation of GCC and cygwin.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2009-08-20 05:59 ---
gfortran 4.5.0 gives
REMOVE:kargl[5] ./z
x0%P T
x0%P T
x1%P F
x1%P T
Given that you are using a f95 compiler, I believe that you are
invoking processor-dependent behavior. F95 states
2.4.6Pointer
A
92 matches
Mail list logo
