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=31295
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=31298
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 17:05 ---
"new" seems to be ok (should_write_tags=.true.) but new2 contains only garbage.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-21 17:13 ---
*** Bug 31211 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 17:13 ---
The following code is wrong, if cp_get_default_logger returns NULL.
struct cp_logger_type D.1364;
D.1364 = *cp_get_default_logger ();
cp_logger_log (&&D.1364);
*** This bug has been mar
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 17:15 ---
aad.f90: In function 'tricky':
aad.f90:24: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:877
Compiles with NAG f95 and g95, ICEs with ifort and sunf95.
--
burnus at gcc dot g
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-21 17:27 ---
I can reproduce this. With g95 it shows also with nohup the login, whereas with
gfortran, sunf95 and ifort it does not.
gfortran calls: char *getlogin(void)
g95 calls: getpwuid(getuid())->pw_name
--
h
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-21 18:02 ---
(In reply to comment #5)
> Anyways this is a bug with coreutils.
> coreutils 5.2.1's nohup works
> coreutils 5.93's nohup does not.
> You should report this bug to them.
I reported it now, cf
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-21 19:07 ---
(In reply to comment #3)
> The following program causes an infinite loop in gfortran, but not in other
> fortrans.
The program is plainly invalid as one redefines the DO thus your Fortran
compiler is free to d
Version: 4.3.0
Status: UNCONFIRMED
Keywords: compile-time-hog
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
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-21 21:56 ---
*** This bug has been marked as a duplicate of 20923 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-21 21:56 ---
*** Bug 31301 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-21 22:31 ---
Richard Main wrote in
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5e91eb94c1ea71ec/
See Notes 15.29 and 15.23 for a (bried) explanation and
example of exactly this. I knoew this was an
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-22 07:41 ---
(In reply to comment #5)
> Then, the following should be invalid and rejected, shouldn't it?
> recursive function f(i)
> integer :: f, i
> f = 0
> if (i > 0) f = f(i-1) + 1
> end f
--- Comment #8 from burnus at gcc dot gnu dot org 2007-03-22 07:42 ---
Close as Won't Fix
--
burnus at gcc dot gnu dot org changed:
What|Removed |
--- Comment #9 from burnus at gcc dot gnu dot org 2007-03-22 09:36 ---
Bob Proulx wrote at bugs-coreutils@
> Regardless of that I think it would be better if the program calling
> getlogin() avoided using it since using the utmp file for this
> accounting is often a
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-22 13:05 ---
> Or a workaround / new method for mixed case functions calls from gfortran
> to C.
In the Fortran-Experiments branch exists support for C bindings:
subroutine fortranname bind(C,name='C_Name')
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-22 22:20 ---
There are actually two run-time tests possible:
a) Check only local variables
(What to do about actual arguments to intent(in) dummy arguments? In the most
cases this is wrong, however foo(read_argument=.false.,arg
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-22 22:30 ---
Besides pointers, the same is also true for deallocated variables, only that
the unknown state does not exist. (Idea taken from 31318)
> I think there are essentially two problems possible with pointers:
&
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-22 22:32 ---
This is related to 29616 (same for nullified pointers). As the test is
essentially the same, I added a comment there and close this PR as duplicate.
Thanks for the idea though it will likely take a while until it
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-22 22:32 ---
*** Bug 31318 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
ran.dg/alloc_comp_assign_2.f90
and *_3.f90
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #8 from burnus at gcc dot gnu dot org 2007-03-31 18:34 ---
Author: burnus
Date: Sat Mar 31 18:30:11 2007
New Revision: 123385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123385
Log:
2007-03-31 Tobias Burnus <[EMAIL PROTECTED]>
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-31 22:51 ---
Created an attachment (id=13312)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13312&action=view)
Preliminary patch
> Valgrind gives no error related to uninitialized when compiling with gfortran.
I
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-31 23:01 ---
Confirmed:
"C1002 (R1002) The comma used to separate format-items in a format-item-list
may be omitted [...]
(4) Before or after a colon edit descriptor (10.7.3)"
--
burnus at gcc dot gnu dot o
--- Comment #7 from burnus at gcc dot gnu dot org 2007-03-31 23:05 ---
No regression, no serious bug -> won't fix in 4.2 -> close.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #18 from burnus at gcc dot gnu dot org 2007-04-02 22:49 ---
Is this PR fixed or not? Looking at the initial and the additional example, it
seems to be fixed both in 4.2 and in 4.3. Can this PR be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-02 23:10 ---
Hmm, I cannot reproduce this on x86_64-unknown-linux-gnu/openSUSE 10.2 with
either gcc 4.2 (vanilla) nor with gcc 4.3 (current SVN, very mildly patched)
and with neither -m32 nor -m64 running under valgrind. (This is
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-02 23:28 ---
> You can found the complete ranlux.f subroutine at
> http://www.systella.fr/~bertrand/rpl2/download/rpl-4.00pre8q.tar.bz2
The program does not compile for me:
gfortran ./src/fonctions_speciales.conv.f90
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-03 17:54 ---
Could you try the following code in ia64 and i686?
PROGRAM test
INTEGER(KIND=1) :: i(1)
i = (/ TRANSFER("a", 0_1) /)
print *, i
END PROGRAM test
I think this will compile and print "97". Is thi
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-03 21:58 ---
I believe this bug is invalid as the format string is invalid.
NAG f95 also claims:
*** Malformed format specification
Reasoning:
R1001 format-stmt is FORMAT format-specification
R1002 format-specification is
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-04 15:47 ---
Note: NAG f95 has the error:
Error: foo.f90, line 7: IMPLICIT setting for letter C changed after use in
TEST
Errors in declarations, no further processing for TEST
I think strictly speaking, NAG f95 is right
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-04 17:35 ---
> A program with an empty CONTAINS block is illegal
Well, this is a matter of arguments. It is invalid in Fortran 90, 95 and 2003.
But it is allowed in the current draft for Fortran 2008.
Therefore, we decided
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-04 17:39 ---
Confirm. If one uses DO or uses a wrong label, gfortran works correctly.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-04 17:41 ---
C732 (R758) If the forall-construct-stmt has a forall-construct-name, the
end-forall-stmt shall have the same forall-construct-name. If the
end-forall-stmt has a forall-construct-name, the forall-construct-stmt shall
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-04 17:48 ---
>From the standard:
"5.2.9 PARAMETER statement
[...]
The named constant shall have its type, type parameters, and shape specified in
a prior specification of the specification-part or declared implicitly (
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-04 18:47 ---
Accepted. Thanks for the report.
We do check for this but only for the PRIVATE/PUBLIC attribute and not for the
PUBLIC/PRIVATE statement.
Patch:
Index: gcc/fortran/decl.c
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-04 18:57 ---
Confirmed. Thanks for the report.
gfc_add_external and gfc_add_intrinsic do actually the right thing. However,
they are not used in decl.c's gfc_match_external:
gfc_clear_attr (¤t_attr);
current_attr.ext
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-04 20:47 ---
The problem seems to occur with procedure pointers to ENTRY points
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from burnus at gcc dot gnu dot org 2007-04-05 13:27 ---
This probably will work automatically if inter-file checking is implemented,
but if not, here is an invalid example which should be rejected:
-
SUBROUTINE PHLOAD (READER,*)
IMPLICIT NONE
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-05 14:13 ---
The patch is wrong since the PRIVATE/PUBLIC statement is also allowed for type:
module foo
type t
private
integer, public :: foo
end type t
end module foo
Actually, currently gfortran also invalidly rejects the
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-10 07:12 ---
With 4.3.0 20070404/x86_64-unknown-linux-gnu I don't get the ICE - and no
problem is discovered using valgrind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-10 07:41 ---
I can reproduce the crash with GCC/gfortran 4.1, but not with 4.2 or 4.3.
GCC 4.3 is the current developer version which gets all the fixes. GCC 4.2 and
4.1 are open only for regressions; some of the fixes are also
support)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-10 19:26 ---
Accept. I somehow missed the email/PR while reading all the messages after a
conference.
Patch at:
http://gcc.gnu.org/ml/fortran/2007-04/msg00105.html
(In reply to comment #1)
> xlf yields a bus error with
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-11 08:29 ---
Subject: Bug 31240
Author: burnus
Date: Wed Apr 11 08:28:49 2007
New Revision: 123712
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123712
Log:
2007-04-11 Tobias Burnus <[EMAIL PROTECTED]&
--- Comment #4 from burnus at gcc dot gnu dot org 2007-04-11 08:29 ---
Fixed. Thanks for the report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-11 08:42 ---
g95 and sunf95 also hang; NAG f95 quits with the error message:
"Record too long for input buffer
Program terminated by I/O error on unit 10
File="/dev/zero",Formatted,Sequential)"
(Thanks for tr
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-11 09:44 ---
Fortran 95
--
4.4.1 Derived-type definition
TYPE [ [ , access-spec ] :: ] type-name
[ private-sequence-stmt ] ! no PUBLIC!
access spec & PRIVATE statement only in specification part of a module.
5.1
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=31538
unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31540
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-11 19:56 ---
In resolve.c's resolve_fl_procedure there is:
if( ... && cl->length->expr_type != EXPR_CONSTANT)
thus the question is:
Why is "(137)" not an EXPR_CONSTANT
--
burnus a
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-11 20:26 ---
Actually, it turned out that this is an out-of-bounds problem:
character(len(ch)) :: chr(2)
chr = test2 (1)
however, test(1) returns an array of the size (2*1+1)+1 = 4.
gfortran's -fbounds-check message
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-12 09:19 ---
Cf. http://gcc.gnu.org/ml/fortran/2007-04/msg00120.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29785
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-12 09:46 ---
Subject: Bug 31472
Author: burnus
Date: Thu Apr 12 09:46:30 2007
New Revision: 123735
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123735
Log:
2007-04-12 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-12 09:58 ---
Fixed in 4.3. No regression and rejects only valid Fortran 2003 code -> no
backporting to 4.2 -> Fixed.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-12 10:52 ---
> > Is this example (PR 20541) really valid?
> Lahey does not complain.
At compile time? Or at run time?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31320
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
htt
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
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-12 19:00 ---
Which version are you using under i386-pc-mingw32? (I see "Reported against
4.3.0, however - see below.)
I'm asking because "4.0.3 (intel linux 64bit)" is very old. GCC 4.0.x contained
the fresh
--
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 #1 from burnus at gcc dot gnu dot org 2007-04-13 10:52 ---
Created an attachment (id=13362)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13362&action=view)
change struct complex into "complex float" in gfortran.dg/value_4.c
Does the attached test-ca
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-13 11:05 ---
Could you post a complete example? I have problems to create one with
type (ped_data) :: dataset
integer, dimension(dataset%maxsiz) :: nobs
as parameter is not allowed in a type specification and using a simple
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-13 11:59 ---
Subject: Bug 31562
Author: burnus
Date: Fri Apr 13 11:59:19 2007
New Revision: 123780
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123780
Log:
2007-04-12 Tobias Burnus <[EMAIL PROTECTED]&
--- Comment #7 from burnus at gcc dot gnu dot org 2007-04-13 12:26 ---
Subject: Bug 31562
Author: burnus
Date: Fri Apr 13 12:26:09 2007
New Revision: 123784
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123784
Log:
2007-04-13 Tobias Burnus <[EMAIL PROTECTED]&
--- Comment #8 from burnus at gcc dot gnu dot org 2007-04-13 12:37 ---
Close as FIXED, if it reappears, please reopen it.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-13 12:51 ---
The procedure does:
= + *
Source code (compiled with the default testsuite options -O2 -ftree-vectorize
-ftree-vectorizer-verbose -fdump-tree-vect-stats):
SUBROUTINE SAXPY(X, Y, A)
DIMENSION X(64), Y(64
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-13 15:08 ---
Well, gfortran is right:
x'8000' = 2147483648 > 2147483647 = huge(msk1)
and
o'377' = 4278190080 > 2147483647 = huge(msk4)
Thus the BOZ numbers are too big for the 4-byte vari
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-13 19:34 ---
Subject: Bug 31559
Author: burnus
Date: Fri Apr 13 19:34:36 2007
New Revision: 123793
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123793
Log:
2007-04-13 Tobias Burnus <[EMAIL PROTECTED]&g
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-13 19:43 ---
What's the plan regarding backporting the patch to GCC 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31051
--- Comment #8 from burnus at gcc dot gnu dot org 2007-04-13 19:44 ---
What's the plan regarding backporting the patch to GCC 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
--- Comment #7 from burnus at gcc dot gnu dot org 2007-04-13 19:45 ---
What's the plan regarding backporting the patch to GCC 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-15 18:39 ---
Minimal example:
program test
implicit none
type data_type
integer :: i=2
end type data_type
type(data_type) :: d
d%i = 4
call set(d,d)
contains
subroutine set(x1,x2)
type(data_type),intent(out
me is
of cause way too early.
--
Summary: Better error message for not-found operator
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
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=31580
--- Comment #4 from burnus at gcc dot gnu dot org 2007-04-15 20:20 ---
Created an attachment (id=13369)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13369&action=view)
Updated patch
This patch handles almost everything except of
operator() => operator(.user.)
where
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-16 15:28 ---
What about
include "foo.f90"
and
#include "bar.f90"
(g95 handles both)
And what about
include "z.f90"
where "z.f90" is foo/z.f90 and is found via
gfortran -Jfoo ?
(g95 do
us: UNCONFIRMED
Keywords: diagnostic
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=31592
--- Comment #4 from burnus at gcc dot gnu dot org 2007-04-16 21:14 ---
The assert is trans-array.c's gfc_conv_array_initializer
switch (expr->expr_type)
{
...
default:
gcc_unreachable ();
Here, expr->expr_type is EXPR_FUNCTION.
By the way, the scalar v
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=31600
FIRMED
Keywords: diagnostic
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=31601
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-17 13:14 ---
If one tries to change the attribute of an USE-associated symbol the error is
better:
external omp_get_num_threads, omp_get_thread_num
1
Error: Cannot change attributes of USE-associated
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-18 10:18 ---
(In reply to comment #4)
Another thing which needs to be supported:
use mod, only: operator(foo) => operator(.op.), &
operator(bar) => operator(.op.), &
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-18 10:21 ---
(In reply to comment #1)
>
> if (any (Up ("AbCdEfGhIjKlM") .ne. (/"ABCDEFGHIJKLM"/))) call abort ()
> contains
> Character (len=20) Function Up (string)
>
>
> It looks l
--- Comment #10 from burnus at gcc dot gnu dot org 2007-04-18 18:19 ---
> What happend to this? I can't find the patch in the tracker anymore, but
> there's no indication in the ChangeLog(s) that is was applied.
The last patch was applied, i.e. gfortran uses now _gfort
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44 ---
> Nevertheless, the accepts-invalid is also an embarassing problem (unless we
> collectively misunderstand Fortran rules :)
Well, we do.
if (any (Up ("AbCdEfGhIjKlM") .ne. (/"ABCDEFGHI
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-19 16:16 ---
Analogously for character lengths:
program test
character(len=10) :: x
call foo(x)
write(*,*) 'X=',x
contains
subroutine foo(y)
charac
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=31668
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-24 18:46 ---
This example is not valid. As NAG f95 claims:
Error: foo.f90, line 45: ALLOCATABLE array NCOSET used but never ALLOCATEd
(gfortran actually misses such an error/warning.
--
http://gcc.gnu.org/bugzilla
: normal
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=31688
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-24 19:58 ---
> > This example is not valid. As NAG f95 claims:
> it is not supposed to be a runable example
Well, for hunting miscompilation bugs, a runable example helps.
I think there are at leastfour problems:
a) Th
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-25 07:38 ---
foo1 (__result, n)
{
bar1 ((int4 *) n, foo1);
goto __return_foo1;
__return_foo1:;
looks strange. Shouldn't this be:
bar1 ((int4 *) n, __result)
In addition, the warning
g.f90:8: warning: Function doe
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-25 09:32 ---
Subject: Bug 31668
Author: burnus
Date: Wed Apr 25 09:32:21 2007
New Revision: 124147
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124147
Log:
fortran/
2007-04-25 Tobias Burnus <[EMAI
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-25 09:35 ---
Fixed. For completeness, I only support PROC_MODULE (for interfaces to external
routines) and not PROC_INTERNAL as there is no way (except VALUE) to make use
of a call-by-value variable.
--
http://gcc.gnu.org
gnedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31697
gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
GCC target triplet: x86_64-unknown-li
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-25 13:28 ---
Might be related to the similar PR 31699.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31697
701 - 800 of 4285 matches
Mail list logo
