Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32704
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2007-07-09 08:15 ---
Note: The program fails with
"call sub(c+f())"
where c is a parameter and dimensions of c and f are (2,2). If one has
dimension(2) it works.
Working with 2007-05-08-r124539, failing
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2007-07-06 13:50 ---
I think this is invalid.
The normative words are, from 9.6.1.11
"The scalar-default-char-variable in the FORMATTED= specifier is
assigned the value YES if FORMATTED is included in the s
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2007-05-20 10:03 ---
The problem disappeared meanwhile: 4.3.0 20070519 is no longer crashing :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31935
: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32006
dBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29717
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-11-04 17:24 ---
Fix: Reverting the change in gcc/fortran/expr.c of the following patch (which I
don't understand):
r118338 | fxcoudert | 2006-10-31 21:15:22 +0100 (Tue, 31 Oct 2006) | 12 lines
tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29713
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de
2006-11-01 14:01 ---
This has been fixed in the meanwhile.
(Don't forget, gfortran is not that old.)
Possibilities:
- Use a GCC 4.1 branch build (newer than 4.1.1)
- Use a GCC 4.2 branch build
- Use a GCC 4.3
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-31 21:37 ---
Steve Lionel from Intel wrote
http://groups.google.com/group/comp.lang.fortran/tree/browse_frm/thread/062ce3447e5ef570/7e2c6b5723c3b228#doc_a7f0b804f755e27b
"For a record length greater
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-28 13:34 ---
Probably the same for binary and hexadecimal?
io/transfer.c(formatted_transfer_scalar): "case FMT_O:" seems to be a good
place for adding notify_std (&dtp->common, GFC_STD_GNU,
--- Comment #14 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-28 13:09 ---
> Do g95 and ifort also compile the original testcase and do The Right Thing?
No. g95 has a run-time error, ifort garbage at the beginning (but no crash);
f95 and sunf95 don't compile.
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29616
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-27 08:06 ---
Close as invalid then.
--
tobias dot burnus at physik dot fu-berlin dot de changed:
What|Removed |Added
--- Comment #12 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-26 20:29 ---
> > why is there no problem with this code?
> >
> > PROGRAM test_constructor
> > CHARACTER(len=32), DIMENSION(1,2) :: a
> > a = reshape((/ "one arg"
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-24 13:31 ---
I'm actually not any more sure what is meant by "formatted" in
inquire(). The Fortran 2003 standard says:
"The scalar-default-char-variable in the FORMATTED= specifier is
as
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-24 12:27 ---
Created an attachment (id=12482)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12482&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
portedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29572
--- Comment #12 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-23 18:52 ---
Cf. also bug 29471.
In the Intel Fortran Compiler
real :: r
data r/some BOZ/
gives the same result as using the Fortran 2003 statement in ifort:
real :: r
r = real(some boz)
(At least with
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-18 21:11 ---
Yes, you are right. I somehow missed those.
"12.5.4 Statement function
A statement function is a function defined by a single statement.
R1238 stmt-function-stmt is function-name ( [ dumm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29505
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-17 15:31 ---
The library problems are due to an error in the string comparison; one only
compares the first (fortran string length) characters, but never checks whether
the strings are of identical length
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-16 17:12 ---
(In reply to comment #2)
> > Fortran 2003:
> > a = real(z'F')
> > = 2.1019477E-44
>
> Are you sure this is the only correct value? The F2003 says noth
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-16 13:34 ---
Note that there is a change in meaning:
BOZ-everywhere extension:
a = real(z'F')
is the same as real(int(z'F')) = 15.0
(This is what gfortran does and Intel does by de
gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-13 10:13 ---
Some tests show:
open(13,file='foo',form='format')
close(13,status='del')
compiles and runs in gfortran.
Expected:
- A run-time error is shown.
- A compile
in gfortran
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29453
N', 'ZERO', 'NEAREST', 'COMPATIBLE'. 'PROCESSOR_DEFINED'
- SIGN: PLUS, SUPPRESS, PROCESSOR_DEFINED
--
Summary: Do compile-time specifier checks for WRITE and READ
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29407
eses around.
--
Summary: print ('(a)') not working, print '(a) works
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc
ception
(IEEE) support
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot b
unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29371
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29364
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-02 15:15 ---
> From Francois-Xavier Coudert 2006-06-08
I'm writing a patch to add substring bounds checking. I hope to post it in the
next few days.
What is the status? If you have something, I'd
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29277
e construct name
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin d
--- Comment #9 from tobias dot burnus at physik dot fu-berlin dot de
2006-09-20 11:57 ---
I think this is fixed.
If there are other errors, not covered, one could still reopen this bug or
create a new one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-09-20 08:27 ---
I looked what other are writing:
gfortran:
Fortran runtime error: Array reference out of bounds for array 'r', upper bound
of dimension 1 exceeded (in file 'array2.
--- Comment #5 from tobias dot burnus at physik dot fu-berlin dot de
2006-09-10 22:43 ---
> Can you try this patch? It required MPFR 2.2.0.
Tested on openSUSE/AMD64 with current gfortran trunk + patch and mpfr-2.2.0-9.
It works ok with kind = 4 and kind = 8. However, with kind = 1
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-09-10 19:23 ---
Maybe this should not be done with -fbounds-check, but put into a different
option. (NAG uses not -C=array but -C=call for this.)
The reason is that some programs (e.g. Exciting.sf.net) passes an
--- Comment #8 from tobias dot burnus at physik dot fu-berlin dot de
2006-08-24 19:43 ---
*ping*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-08-22 21:08 ---
Using gfortran 4.1.2 20060705 (prerelease) (SUSE Linux)
and GNU Fortran 95 (GCC) 4.2.0 20060822 (experimental)
it compiles and gives the output (from the program):
det for matrices bigger than
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-08-20 20:51 ---
Besides zero initialization (of Real, complex, integer, (what about logical?)),
a initialization to a (signaling) NaN (for complex, real) would be also nice to
find uninitialized variables
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-08-16 17:44 ---
Isn't this fixed as Steve bumped 4.2/TRUNK to libgfortran.so.2 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-08-09 18:10 ---
> One problem without using -tranditional-cpp is that some tokens in C are not
> tokens in Fortran so you could get the wrong result. This is why
> -tranditional-cpp is used.
I though
rtran: -traditional-cpp versus newer
macros like #x
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
ing: Positive width required in format string at (1)
-- and --
Fortran runtime error: Nonnegative width required in format
(f10.3,dc,f10.3,f10.3)
^
--
Summary: [F2003] In/output: DECIMAL=/dp/dc; SIGN=/S/SP/SS
BLANK=/PAD=; DELIM=; ENCODING=
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28655
pport NEW_LINE intrinsic
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-
--- Comment #8 from tobias dot burnus at physik dot fu-berlin dot de
2006-07-28 10:16 ---
> Resolution: FIXED
> Fixed on 4.2
What about 4.1.x?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28339
0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-07-17 17:54 ---
(CC myself)
I see the same problem for real(8) and for real(10) as for real = real(4),
except for
print *, scale (fraction (a), exponent (a)) / a
where I get "NaN" with real(10)
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-07-12 06:30 ---
Created an attachment (id=11863)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11863&action=view)
mpif.h (from MPICH)
> This file alone is not going to be able to reproduce this
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-07-11 23:01 ---
Created an attachment (id=11862)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11862&action=view)
Test file: mpi_bc_all.f
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28353
tedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28353
of flush.f90
--
Summary: flush() / write() statement on closed units - error?
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot or
nassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28309
--- Comment #7 from tobias dot burnus at physik dot fu-berlin dot de
2006-07-05 09:23 ---
> The patch did not apply to 4.1, so I will have to submit a back port.
Thanks, Paul. I think this is the most serious bug in gfortran 4.1.x as it
silently produces wrong results.
--
tob
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-07-04 12:03 ---
I reall should create a gfortran script which inclueds -std=f95 by default :-(
LANG=C gfortran -std=f95 test.f90
In file test.f90:3
write(*,*), 'Hello'
1
Error: Extens
after read() or
write()
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus
t org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28224
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-23 13:01 ---
Additional remarks (which I forget to make):
Both cases are valid Fortran as:
(1) If the length of 'variable' is less than that of 'expr', the value of
'expr' is
NCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28129
verity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28105
--- Comment #7 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-17 10:57 ---
The test case of comment #4 is invalid as the Fortran standard says that a
pointer is undefined unless it is associated (allocated, assigned) or
deassociated (nullifyed). In this case it is
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-15 12:26 ---
> .so, an error is definitely in order.
Maybe one could spit out a default warning and only with -std=f90 an error as
this is might be a commonly used Fortran extension. Or one simply alw
FIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-14 09:17 ---
Paul,
> I presented a patch for this problem and for detected unassigned r-values that
> was rejected. I don't know what to say; I think that it's a bug, in
> principle,
>
allocate negative memory
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
ummy variable is not set
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-
m test
--
Summary: character arrays: warn if erray constructor values have
different lengths
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
: Support type-spec for array constructor,
i.e. (/ real :: 1., 2., 3. /)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27996
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-11 20:05 ---
This should probably marked as blocking -fbounds-check meta bug 27786.
--
tobias dot burnus at physik dot fu-berlin dot de changed:
What|Removed |Added
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27989
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-08 19:53 ---
This could be the same as gfortran.fortran-torture/execute/assumed_size.f90,
I'm not completely sure, though.
--
tobias dot burnus at physik dot fu-berlin dot de changed:
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27965
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-01 21:41 ---
> Why not use gdb?
I don't see how gdb helps pinpointing the array-out-of-bound problem. As said:
the program ends with
Fortran runtime error: Array reference out of bounds
Program exi
or should at least crash
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin
a real
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.or
--- Comment #6 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-24 22:11 ---
> Gfortran will never support a real*16 data type on IA32 hardware.
> This would require software emulation of all of basic floating-point
> arthimetic
This is what Intel's Fortran
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-13 23:01 ---
The following is also not caught:
-
subroutine foo(y)
character(len=20) :: y
y = 'hello world'
end
pr
org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27594
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-13 14:17 ---
Post scriptum: In this case, using -Wuninitialized -O
the compiler detects that the variable is uninitialized; however, for the other
UIN*.FOR examples at polyhdron.com they are not detected at
oduct: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_
--
tobias dot burnus at physik dot fu-berlin dot de changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
igned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27587
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.
E on invalid "associate(x,(y))"
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27583
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-10 22:46 ---
> Is there really a standard for this or just an extension of OpenMP?
I'm not sure whether I understand the question.
Directive wise it is OpenMP augmented by a single directive: "sha
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27541
--- Comment #18 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-09 20:15 ---
Subject: Re: gfortran: Warn/abort when format in write
does not fit passed arguments
@resolution : FIXED
> This looks like you have an old version of the library around, and that it'
--- Comment #15 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-04 19:09 ---
I probably do something wrong, but with
GNU Fortran 95 (GCC) 4.2.0 20060504 (experimental)
from http://quatramaran.ens.fr/~coudert/gfortran/gfortran-x86_64-linux.tar.gz
I still don't get
descriptors in format after reversion
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot
--- Comment #14 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-02 08:37 ---
> Fixed on 4.1 and 4.2
Thanks for fixing :-)
Still it would be nice if it would be detected during compile time. In
my case it was burried in an
if(something that rarely happens) wr
1 - 100 of 112 matches
Mail list logo
