--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-27 22:04 ---
> > Also isn't -huge()-1 undefined code for Fortran?
> -huge()-1 can be defined in Fortran. [...]
> I'll also note that -pedantic will reject -huge()-1
Just for completeness: In the original
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-27 23:33 ---
> The same is true for -Werror.
I have to correct myself:
-Werror gives a non-zero exit status, but still writes "Warning:". I think
gfortran should follow gcc by changing also the label from "W
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-28 08:04 ---
Subject: Bug 30968
Author: burnus
Date: Wed Feb 28 08:03:47 2007
New Revision: 122401
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122401
Log:
2007-02-28 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #12 from burnus at gcc dot gnu dot org 2007-02-28 11:28 ---
> The following additional patch needs to be applied when backporting:
> http://gcc.gnu.org/ml/fortran/2007-02/msg00620.html
This two-line patch is unrelated.
(I think one should nonetheless backport it to 4
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-28 18:17 ---
Subject: Bug 30888
Author: burnus
Date: Wed Feb 28 18:17:34 2007
New Revision: 122409
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122409
Log:
2007-02-28 Tobias Burnus <[EMAI
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-28 18:17 ---
Subject: Bug 30887
Author: burnus
Date: Wed Feb 28 18:17:34 2007
New Revision: 122409
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122409
Log:
2007-02-28 Tobias Burnus <[EMAI
--- Comment #9 from burnus at gcc dot gnu dot org 2007-02-28 18:26 ---
Fixed in GCC 4.3, not part of 4.2 => close PR.
Thanks for having reported this bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-28 18:26 ---
Fixed in GCC 4.3, not part of 4.2 => close PR.
Thanks for having reported this bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #6 from burnus at gcc dot gnu dot org 2007-02-28 20:52 ---
FIXED as commited to 4.1, 4.2 and 4.3/trunk. I think the fix is complete. If
not, please reopen.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2007-02-28 20:57 ---
> Author: tobi
> Date: Wed Nov 22 22:09:14 2006
>trunk/gcc/fortran/ChangeLog
What is the status on this? Will this be backported to 4.2 and 4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
--- Comment #13 from burnus at gcc dot gnu dot org 2007-03-01 08:19 ---
Subject: Bug 30865
Author: burnus
Date: Thu Mar 1 08:19:09 2007
New Revision: 122423
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122423
Log:
2007-03-01 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #14 from burnus at gcc dot gnu dot org 2007-03-01 09:44 ---
Subject: Bug 29820
Author: burnus
Date: Thu Mar 1 09:43:53 2007
New Revision: 122427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122427
Log:
fortran/
2007-03-01 Paul Thomas <[EMAI
--- Comment #11 from burnus at gcc dot gnu dot org 2007-03-01 09:44 ---
Subject: Bug 30660
Author: burnus
Date: Thu Mar 1 09:43:53 2007
New Revision: 122427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122427
Log:
fortran/
2007-03-01 Paul Thomas <[EMAI
--- Comment #12 from burnus at gcc dot gnu dot org 2007-03-01 09:45 ---
Backported to 4.2, not part of 4.1 => FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-01 16:33 ---
> I'd like to suggest to do the same for derived type components.
The point is not components or not, the point is: Known size at compile time or
not. (A different thing are arrays of derived types.)
The s
n
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31014
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
IRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31016
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-01 19:15 ---
subroutine bar(a,b,n)
implicit none
integer :: n
real :: a(n,n), b(n,n)
a = b
end subroutine
For that example example, the overhead is even more obvious. One needs to run
only:
for (int i = 0; i < n*n; i++)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-01 19:22 ---
And analogously for these kinds of dummy arguments:
subroutine x(a,n)
integer :: n
real :: a(n)
interface
subroutine foo(x,n)
integer :: n
real :: x(n)
end subroutine foo
end interface
call foo
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-01 19:26 ---
And another example for compile-time known sizes:
subroutine bar(a,n)
implicit none
integer :: n
real :: a(n),b(12)
a(1:12) = b
a(2:n) = b
! Here, n is unknown, but it is only valid if the shapes of b an a are
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-02 09:38 ---
On my "AMD Athlon(tm) 64 X2 Dual Core Processor 4800+", gfortran is in x86_64
mode only 13% slower:
gfortran: Kernel time 5.872366, real 0m33.121s; user 0m32.898s; sys 0m0.088s.
Ifort:Kernel time 5.24
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-02 10:43 ---
> Tobias, do the cases given in PR31016 include the one above?
> If yes, this PR could be closed as dupe?!
Actually not. PR 31016 (and related PR 31014) are about cases where one
actually knows that the mem
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-02 16:14 ---
Another thing which currently fails in gfortran (and g95) is:
module x
implicit none
integer, parameter :: d=8
interface
real(d) function y()
import
end
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-02 16:16 ---
(Example for the latter is: http://users.erols.com/dnagle/pub/pthread.f03,
which also needs ISO_C_BINDING)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-02 23:03 ---
Subject: Bug 30873
Author: burnus
Date: Fri Mar 2 23:03:26 2007
New Revision: 122495
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122495
Log:
2007-03-02 Paul Thomas <[EMAI
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-03 10:43 ---
Subject: Bug 30882
Author: burnus
Date: Sat Mar 3 10:43:25 2007
New Revision: 122503
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122503
Log:
2007-03-03 Paul Thomas <[EMAIL PROTECTED]&g
gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31030
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #24 from burnus at gcc dot gnu dot org 2007-03-03 20:55 ---
Is this actually now fixed or not? I see a 4.2 and a trunk commit. Can this bug
now be closed, is something missing or should it be checked in for 4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
--- Comment #10 from burnus at gcc dot gnu dot org 2007-03-05 09:29 ---
(In reply to comment #9) Tobias Schlüter wrote:
> Fixed on all release branches.
This sounds as if should have been marked as FIXED.
Did so. Please reopen if it should not have been closed.
--
burnus at gcc
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-05 12:58 ---
Subject: Bug 30968
Author: burnus
Date: Mon Mar 5 12:58:14 2007
New Revision: 122547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122547
Log:
2007-03-05 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-05 12:59 ---
Fixed in 4.2 (and 4.3). I don't think it is worth to porting to 4.1.
-> close bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-05 18:08 ---
> I am not sure if gfortran diagnostics are different,
I think gfortran handles the warnings quite different, not that I know much
about the details of the C frontend.
> but... are you sure that particular w
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-07 07:17 ---
> gcc version 4.3.0 20061021 (experimental)
I believe this has been fixed already by PR30005 since December 5.
At least my gfortran prints:
At line 6 of file foo.f90
Fortran runtime error: Permission denied try
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-07 07:23 ---
*** Bug 31059 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-07 07:23 ---
Confirmed, gfortran should print something like:
"Rank 1 of array operand has extent 2 instead of 3"
*** This bug has been marked as a duplicate of 30802 ***
--
burnus at gcc dot gnu dot o
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-07 17:13 ---
> I am trying to compile f90 code into objects that generate the symbol names
> in stdcall syntax, i.e. [EMAIL PROTECTED]
I think you are not looking for -mrtd but for versioned symbols.
-mrtd does:
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-08 12:31 ---
Subject: Bug 30973
Author: burnus
Date: Thu Mar 8 12:30:58 2007
New Revision: 122696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122696
Log:
2007-03-08 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #37 from burnus at gcc dot gnu dot org 2007-03-08 13:24 ---
Can this be closed or do you intent to backport it to 4.1?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-08 17:06 ---
> gfortran --target-help
> --add-stdcall-aliasExport symbols with and without @nn
> --disable-stdcall-fixupDon't link _sym to [EMAIL PROTECTED]
> --ena
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-08 21:06 ---
Subject: Bug 30873
Author: burnus
Date: Thu Mar 8 21:06:37 2007
New Revision: 122711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122711
Log:
2007-03-08 Paul Thomas <[EMAI
--- Comment #7 from burnus at gcc dot gnu dot org 2007-03-08 21:07 ---
Fixed in 4.2 (and 4.3), not a wrong-code bug => Won't fix for 4.1.
Close.
--
burnus at gcc dot gnu dot org changed:
What|Removed
nknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-09 12:29 ---
The error setting happens in io/transfer.c's write_buf:
/* Unformatted sequential. */
have_written = 0;
if (dtp->u.p.current_unit->flags.has_recl
&& (gfc_o
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-09 12:55 ---
I was checking where bytes_left is set:
open.c: u->bytes_left = 0;
This is the default setting in new_unit (/* Open an unused unit. */)
It is also set to 0 in file_pos.c (two places).
In list_read.c's n
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-09 22:49 ---
For completeness: This is on x86_64-unknown-linux-gnu
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
NFIRMED
Keywords: wrong-code, diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 27766
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31119
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-10 08:47 ---
The problem is that the bounds of an optional argument are checked,
regardlessly whether it is present.
int8 ubound.0;
if (ivec != 0B)
{
ubound.0 = (ivec->dim[0].ubound - ivec->dim[0].lboun
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
--- Comment #12 from burnus at gcc dot gnu dot org 2007-03-10 16:47 ---
Latest patch:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00607.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31124
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-11 14:07 ---
Ian, looking at the changelog, it seems as if your commit
http://gcc.gnu.org/viewcvs?view=rev&revision=122487
r122487 | ian | 2007-03-02 21:09:31 +0100 (Fri, 02 Mar 2007) | 35 lines
Used signed infinitie
--- Comment #7 from burnus at gcc dot gnu dot org 2007-03-11 21:42 ---
> Can you see if the patch I committed this morning fixes this problem?
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00664.html
Yes, the patch fixes this problem. Thanks!
--
burnus at gcc dot gnu dot org chan
nhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31139
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-11 22:45 ---
Contains the test case. The hand-made SSE version (USE_VECTORS) crashes here
for -m32, but as it is C vs. Fortran, one can completely ignore that test case
(for -m64 USE_VECTORS is about as fast as the other C
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-11 22:50 ---
Created an attachment (id=13191)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13191&action=view)
test.tar.gz
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31139
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-12 07:58 ---
> complex * complex is not a simple cross product in FP world.
Well, the program calculates: real * complex
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31139
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-12 08:16 ---
> Can someone try instead of doing "__real__ a += w[j] *__real__ mfi[*index];"
> Use "a+= xxx* yyy" and also use -std=c99 to get the correct multiplication?
Well, -std=c99 was used already
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-12 08:50 ---
Created an attachment (id=13193)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13193&action=view)
Patch draft (by Paul Thomas)
Notes by Paul:
(i) gfc_find_symbol searches via proc_name
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-12 19:09 ---
This is do to the fact that gfortran does no same-file checking; this checking
is outside the Fortran standard but still useful.
It is planed for this year; cf. PR 26227 and references therein.
*** This bug has been
--- Comment #8 from burnus at gcc dot gnu dot org 2007-03-12 19:09 ---
*** Bug 31149 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
BugsThisDependsOn: 30922
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31154
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-13 14:33 ---
Andrew wrote:
--
it is obvious from the tree dump, what is going on:
static struct foo_type f_a = {};
f_a.mv.data = 0B;
So save is done correctly but allocatables
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #80 from burnus at gcc dot gnu dot org 2007-03-14 15:15 ---
(In reply to comment #76)
> "One issue with OpenMP is that it is very easy to break an OpenMP
> code (it is just comments),"
> This is a complaint I've heard before. I wonder if you have a
--- Comment #10 from burnus at gcc dot gnu dot org 2007-03-15 06:55 ---
Fixed.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-15 08:47 ---
(In reply to comment #3)
> this issue now seems fixed on trunk for me as well, so I guess this could be
> closed.
Mark FIXED based on this comment and on the fact that it works with gfortran
4.3, 4.
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31189
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-15 19:31 ---
If one comments out the if block in gfc_simplify_expr (expr.c):
--
case EXPR_VARIABLE:
/* Only substitute array parameter variables if we are in an
initialization expression, or we want
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-15 20:21 ---
Accept. I have a patch for it. My analysis in comment 1 is misleading /
partially wrong, though.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-15 21:03 ---
> A compiler option that used a minimal width for output
> for list directed WRITEs would be convenient.
There are pros and cons for both.
Assume:
print *,(huge(0),i=1,6)
print*,(i,i=1,6)
print
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31194
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 09:34 ---
I'm not anymore sure whether it is valid or not.
Related:
NaN = transfer(ishft(int(z'FFF8',8),32),0.0_8)
this prints duly "NaN" with NAG f95, sunf95, ifort, g95 and gfortran.
The ex
--- Comment #9 from burnus at gcc dot gnu dot org 2007-03-16 09:45 ---
> The current problem is shown in this bit of code:
> write(*,*)'NaN(8)=',real(z'FFF8',8)
> end
Note: gfortran does not support Fortran 2003 BOZ yet.
> gfortran, e
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-16 10:57 ---
Subject: Bug 31188
Author: burnus
Date: Fri Mar 16 10:57:45 2007
New Revision: 122987
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122987
Log:
2007-03-16 Paul Thomas <[EMAI
ywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31222
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 13:21 ---
Expected result:
1 3 2 4
Gfortran:
1 3 1 3
This is correctly calculated with g95, NAG f95 and sunf95.
gfortran compiles and gives the wrong result and ifort gives an ICE.
--
burnus at gcc dot gnu dot org changed
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 13:25 ---
Expected:
"22"
The TRANSPOSE(RESHAPE(Z(:)%A(2:2),(/5,2/))) gives:
"22.�L+"
res contains:
"22�+2�?"
--
burnus at gcc dot gnu dot org changed
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 13:42 ---
The first two lines work, but the M() calls fail (SIGSEGV):
D.1257 = *a3;
if (D.1257 > M.0)
[...]
D.1258 = *a4;
That is: There is no optional check.
cmplx has one:
D.1260 = y != 0B ? *y :
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 13:54 ---
Current result:
a = ABCDEFXXX
b = ABCDEF
c = ABCDEFXXX
Expected (g95/ifort):
ABCDEFXXX
ABCDEFXXX
ABCDEFXXX
(NAG f95 has:
ABCDEFXXX
ABCXXDEF
ABCDEFXXX
)
--
burnus at gcc dot gnu dot org changed
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-16 14:07 ---
The problem is:
s3(f(x))
which is translated as
{
real4 D.1254;
D.1254 = *f (&x);
s3 (&D.1254);
}
instead of
D.1254 = f(&x)
--
burnus at gcc dot gnu dot org changed:
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-16 15:56 ---
(In reply to comment #1)
> All compilers I know reject this code, except g95. The list includes Lahey,
> which is a reason for me to doubt whether this code is legal or not.
NAG f95 and g95 compile it and
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-19 09:07 ---
> > Gfortran and Portland group Fortran accept it by default, while xlf, ifort,
> > NAG f95 and g95 reject it by default.
> I'd say the current behaviour is OK.
Then close as won't fix.
-
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-19 11:12 ---
Current result:
a = ABCDEFXXX
b = ABCDEF
c = ABCDEFXXX
Result by g95/ifort:
ABCDEFXXX
ABCDEFXXX
ABCDEFXXX
Result by NAG f95, SUN and HP:
ABCDEFXXX
ABCXXDEF
ABCDEFXXX
I think the latter is correct
--- Comment #8 from burnus at gcc dot gnu dot org 2007-03-19 12:53 ---
Reading further, I find:
"For nonadvancing input [...] If no error condition occurred in a nonadvancing
output statement, the file position is not changed."
If I understand the whole correctly, it me
dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 27766
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31278
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
BugsThisDependsOn: 31094
http://gcc.gnu.org/bugzilla
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279
ion: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31284
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-20 17:38 ---
Forgot to write that this is a Fortran program. Use
gfortran -Wall -O
to compile it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31284
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-20 17:45 ---
> It is not hard to do "b _gfortran_out_of_bounds" in gdb.
Well, it is not always easy to find the symbol. In C it is much easier:
Essentially all you type is what you get. Fortran with all its hidden
ct: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code, patch
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31286
edure interface in a procedure body
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Rep
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31293
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 10:49 ---
Please also check:
http://home.comcast.net/%7Ekmbtib/Fortran_stuff/interface2.f90
http://home.comcast.net/%7Ekmbtib/Fortran_stuff/interface3.f90
http://home.comcast.net/%7Ekmbtib/Fortran_stuff/interface4.f90
The
mary: Endless loop when compiling a cyclic code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
tatus: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31296
ormal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
601 - 700 of 4285 matches
Mail list logo
