--- Comment #8 from burnus at gcc dot gnu dot org 2007-01-29 08:40 ---
> Should we commit the combined fix? I do think this
> is a bug.
So do I, but we also need a test case, I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
--- Comment #5 from burnus at gcc dot gnu dot org 2007-01-30 17:53 ---
Subject: Bug 30015
Author: burnus
Date: Tue Jan 30 17:52:46 2007
New Revision: 121348
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121348
Log:
2007-01-30 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #6 from burnus at gcc dot gnu dot org 2007-01-30 17:56 ---
Fixed in 4.3 and 4.2. I don't plan to fix it in 4.1.
=> FIXED.
Thanks again for reporting this bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from burnus at gcc dot gnu dot org 2007-01-30 17:58 ---
Let's then fix this bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed |
--- Comment #10 from burnus at gcc dot gnu dot org 2007-01-30 18:13 ---
Subject: Bug 30276
Author: burnus
Date: Tue Jan 30 18:13:14 2007
New Revision: 121350
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121350
Log:
2007-01-30 Tobias Burnus <[EMAI
--- Comment #11 from burnus at gcc dot gnu dot org 2007-01-30 18:14 ---
Paul Thomas wrote on 2007-01-14:
> > Fixed in 4.3; I will commit the patch for 4.2 in about a week; I will not
> > fix
> > 4.1.
> Are you in a position to do that now? The week is up and a
--- Comment #3 from burnus at gcc dot gnu dot org 2007-01-31 09:18 ---
Subject: Bug 30520
Author: burnus
Date: Wed Jan 31 09:18:33 2007
New Revision: 121379
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121379
Log:
fortran/
2007-01-31 Tobias Burnus <[EMAI
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-31 09:20 ---
FIXED in gcc 4.3 (note: VOLATILE is not in 4.2).
See PR 30522 for the missing parts.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2007-01-31 09:55 ---
> > http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00145.html
> Do we have consensus yet on this?
> The standard is not exactly straight forward interpret.
I'm not 100% sure. The standard is inde
--- Comment #11 from burnus at gcc dot gnu dot org 2007-01-31 10:24 ---
Subject: Bug 27588
Author: burnus
Date: Wed Jan 31 10:23:53 2007
New Revision: 121401
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121401
Log:
(This part was missing in the r118852 / Wed Nov 15
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: gcov-profile
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=30650
e for
files containing only procedures
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc do
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-31 19:54 ---
For completeness, it came up here:
http://gcc.gnu.org/ml/fortran/2006-09/msg00381.html
It came up again
http://gcc.gnu.org/ml/fortran/2007-01/msg00716.html
The c.l.fortran thread mentioned there is
http
c
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=30664
--- Comment #16 from burnus at gcc dot gnu dot org 2007-02-01 09:27 ---
Is this bug fixed or not? I see a 4.3 and a 4.2 check in.
Or is something missing, if yes, what?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
e-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30667
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-02 07:50 ---
This actually planed to do, cf.
http://gcc.gnu.org/wiki/GFortran43
"Projects for inclusion into gfortran-4.3"
"Formal/actual argument checking for same file procedures
There are a large number of
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-02 10:03 ---
> The patch seems to fix the problem with the test file. Unfortunately, the
> original problem with the Dynamo package remains:
Modified test case - added:
PRIVATE
PUBLIC :: ENergY_CON
ty: P3
Component: c
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=30682
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-03 16:40 ---
> We should really be initializing our starting values to +/-Inf, both
> in the library and the front end.
In principle yes, but we need still return +HUGE or -HUGE (respectively
-HUGE-1) for arrays wit
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-04 00:19 ---
Thomas asked at c.l.f:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e3745c39a11522c5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-05 14:45 ---
Thanks, aermod now works. :-)
channel, gas_dyn, induct, nf, protein, rnflow still fail respectively fail now.
$ gfortran -fprofile-generate -march=opteron -ffast-math -funroll-loops
-ftree-vectorize -O3 -o channel
--- Comment #5 from burnus at gcc dot gnu dot org 2007-02-05 19:40 ---
As Dick Hendrickson points out in c.l.fortran:
13.7 (the function descriptions) says
"A program is prohibited from invoking an intrinsic procedure under
circumstances where a value to be returned in a subro
--- Comment #7 from burnus at gcc dot gnu dot org 2007-02-06 12:30 ---
> I don't know what the status is of the other patch for MAXVAL/MINVAL, but we
> should probably combine them into a single patch (in particular to ease the
> backporting).
The status of the other pat
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-06 16:34 ---
Not that it much helps, but with today's gcc under x86_64-unknown-linux-gnu it
does not crash.
Maybe someone with Intel Mac can reproduce it.
Oherwise:
Compile with the "-v" option, e.g. gfortran -v
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-06 16:52 ---
Confirmed. It crashes with -O but not without optimization.
Reduced test case:
Subroutine xcc_V_CONVERT(iepoch)
implicit none
logical :: IEPOCH
real:: XVECTOR(1:3)
real:: YVECTOR(1:3
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-06 17:45 ---
> Reduced test case:
The line "xvector = 0.0" can also be removed. The dump-tree-original looks then
as follows:
xcc_v_convert (iepoch)
{
real4 xvector[3];
real4 yvector[3];
if (*iepoch)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-07 07:56 ---
Patch: http://gcc.gnu.org/ml/gcc/2007-02/msg00094.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-07 09:47 ---
> Patch implementing the -fbacktrace option
I think one should add also some userhandler
signal(SIGSEGV, my_segv_handler);
which calls show_backtrace and exits/coredumps then.
That way we calso get a backtr
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-08 07:32 ---
Seemingly fixed
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
BugsThisDependsOn: 30522
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-09 09:55 ---
Hi,
> I cannot judge how much work this would be, but would it be possible to extend
> this patch a little further so that these backtraces can be requested by the
> user?
Well, this is possible if one
--- Comment #11 from burnus at gcc dot gnu dot org 2007-02-09 21:56 ---
Subject: Bug 30512
Author: burnus
Date: Fri Feb 9 21:56:06 2007
New Revision: 121777
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121777
Log:
fortran/
2007-02-09 Tobias Burnus <[EMAI
duct: gcc
Version: 4.3.0
Status: 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=30783
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-13 18:19 ---
>From the Fortran 2003 standard:
--
C528 (R501) If the VALUE attribute is specified, the length type parameter
values shall be omitted or specified by initialization expressions.
--
Wh
--
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
llowed with -std=f95/f2003
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
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=30792
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-15 09:45 ---
The link to c.l.fortran is:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/23aa68ecce460e50
Richard Main: "The pointer assignment is ok. I [...] don't have
time to adequately perus
--- Comment #10 from burnus at gcc dot gnu dot org 2007-02-15 10:32 ---
> > I have still to re-read the test case to check whether TARGET is required
>
> However the accessed component is a POINTER to a derived type [...]
Ok, I somehow didn't realize
type fie
--
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 #14 from burnus at gcc dot gnu dot org 2007-02-16 09:55 ---
Subject: Bug 30793
Author: burnus
Date: Fri Feb 16 09:55:20 2007
New Revision: 122037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122037
Log:
fortran/
2007-02-16 Tobias Burnus <[EMAI
--- Comment #12 from burnus at gcc dot gnu dot org 2007-02-16 14:15 ---
Subject: Bug 30512
Author: burnus
Date: Fri Feb 16 14:15:36 2007
New Revision: 122043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122043
Log:
fortran/
2007-02-16 Tobias Burnus <[EMAI
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.2, 4.1 only] MAXVAL()|[4.1 only] MAXVAL()
|incorrect for zero-size int
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-20 08:57 ---
> The following is legal but we segfault on execution:
> subroutine checkv(ires,a1,opt1)
>integer :: a1(:,:)
>integer, optional :: opt1
>ires = size (a1, dim=opt1)
For those who wonder
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 09:03 ---
Error: Loop variable at (1) cannot have the POINTER attribute
C820 (R831) The do-variable shall be a named scalar variable of type integer.
The program is accepted by ifort, NAG f95, g95 and sunf95.
--
burnus
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-20 09:17 ---
Subject: Bug 30783
Author: burnus
Date: Tue Feb 20 09:16:58 2007
New Revision: 122156
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122156
Log:
2007-02-20 Tobias Burnus <[EMAIL PROTECTED]&
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-20 09:22 ---
Subject: Bug 30522
Author: burnus
Date: Tue Feb 20 09:22:28 2007
New Revision: 122157
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122157
Log:
fortran/
2007-02-20 Tobias Burnus <[EMAI
--- Comment #5 from burnus at gcc dot gnu dot org 2007-02-20 09:45 ---
Fixed in 4.3 (not present in 4.2).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-20 09:46 ---
Fixed in 4.3 (not present in 4.2).
Missed optimization is PR 30733
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-20 13:16 ---
(In reply to comment #2)
> For those who wonder (as I did) why using an optional argument is legal:
> It is only used as actual argument corresponding to an optional dummy
> argument. (cf. 12.4.1.6 in th
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-20 13:23 ---
I cannot reproduce the ICE with 4.3.0 20070220/x86_64-unknown-linux-gnu. I get
the following error:
CASE(TRANSFER(.TRUE.,K))
1
foo.f90:6.5:
CASE(TRANSFER(.FALSE.,K))
2
Error: CASE label at (1) overlaps with
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-20 13:54 ---
Works also for me on x86_64-unknown-linux-gnu with
4.3.0 20070220.
If it still occurs, please reopen and state the error message and the compiler
version/platform.
--
burnus at gcc dot gnu dot org changed
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 14:01 ---
gfortran rejects the procedure with:
SUBROUTINE S1(F1)
1
Error: Symbol 'f1' at (1) has no IMPLICIT type
The error goes away when the return value of f1 has a type, e.g.
INTERFACE
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 14:04 ---
IF(SIZE(a(1:10),1).NE.10) CALL ABORT()
1
Error: 'dim' argument of 'size' intrinsic at (1) is not a valid dimension index
Compiles just fine with ifort, nagf95 and g95.
--
b
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 14:14 ---
Error message:
USE M1
1
Error: Dummy 'd1' at (1) cannot have an initializer
Works with g95, nagf95 and ifort. It also works with gfortran if one changes
the ENTRY E1 into a separate function or if o
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-20 15:54 ---
Thanks for the report. I can confirm that it happens with 4.1.x (4.1.2 20070115
[SUSE Linux]); note however that the ICE does not occur with gfortran 4.2 and
4.3.
I'm not sure whether we have the resources to f
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 15:59 ---
INTEGER FUNCTION F1()
NAMELIST /NML/ F1
is rejected:
NAMELIST /NML/ F1
1
Error: PROCEDURE attribute conflicts with NAMELIST attribute in 'f1' at (1)
I didn't check y
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 16:24 ---
ENTRY E1(I)
1
Error: RESULT attribute required in ENTRY statement at (1)
Note: It works if one removes the "recursive".
Compiles just fine with nagf95, ifort and g95.
Ad hoc I don't see
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 16:28 ---
Compiles with nagf95 and g95.
ifort and gfortran give however the following error messages:
test=test(3)
1
Error: 'test' is array valued and directly recursive at (1) , so the keyword
RESU
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 16:32 ---
MODULE PROCEDURE F1
1
Error: Operator interface at (1) conflicts with intrinsic interface
In other words:
overloading "operator(*)" for intrinsic type (i.e. "complex") f
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 16:39 ---
EQUIVALENCE(a1,a2)
1
Error: Derived type variable 'a1' at (1) with default initializer cannot be an
EQUIVALENCE object
ffv.f90:11.17:
EQUIVALENCE(a1,a2)
1
Error: Initialized o
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 16:50 ---
Reduced test case:
INTEGER, PARAMETER, DIMENSION(2,3) :: bo= &
RESHAPE((/-1,1,-1,1,-1,1/),(/2,3/))
REAL(kind=8), DIMENSION( &
bo(1,1):bo(2,1), &
bo
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 16:53 ---
Error: Different character lengths in pointer assignment at (1)
Compiles with g95, ifort and nagf95.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 16:55 ---
The program compiles with ifort, g95 and nagf95.
gfortran rejects it with:
CALL SUB(xx,I)
1
Error: GENERIC non-INTRINSIC procedure 'xx' is not allowed as an actual
argument at (1)
--
burnus
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 17:00 ---
gfortran:
DATA (a(i),i=1,D1%I) /D1%I*D1%I/
1
Error: Syntax error in DATA statement at (1)
That is: compounds of derived types with parameter attribute are not possible
as data-stmt-value
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 17:32 ---
Paul, do you remember why you have added the following restriction?
(The example is accepted by ifort, nagf95 and g95.)
resolve.c:
if (((e->ts.type == BT_REAL || e->ts.type == BT_C
--- Comment #14 from burnus at gcc dot gnu dot org 2007-02-20 17:39 ---
(In reply to comment #13)
> should we close this?
We can close it as I think it is not worth to backport it to 4.1.
--
burnus at gcc dot gnu dot org changed:
What|Remo
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 19:54 ---
Confirmed.
It fails in resolve.c's resolve_actual_arglist
/* Intrinsics are still PROC_UNKNOWN here. However,
since same file external procedures are not resol
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-21 07:33 ---
(In reply to comment #0)
> The attached test code using a generic interface block produces wrong output
> when compiled with gfortran, and works fine with pgf90.
I think both compilers are right; or to b
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-21 13:53 ---
> Removing the error call
> if (proc->attr.recursive && result == NULL)
> {
> gfc_error ("RESULT attribute required in ENTRY statement at %C");
>
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-21 14:51 ---
This is a regression. With 4.1.2 20070115 (prerelease) (SUSE Linux) I get
"1.E-01", but with today's 4.2 and 4.3 I get "0.E+00".
--
burnus at gcc dot gnu dot org changed:
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-21 17:03 ---
Paul,
> > fortcom: Warning: dtgv.f90, line 9: Recursive array-valued function without
> > result variable ambiguous [TEST]
> Goes right to the nub of it. Within test, is an r-value expression th
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=30922
s: 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=30923
--- Comment #6 from burnus at gcc dot gnu dot org 2007-02-22 13:50 ---
I think I found why the output is wrong. The following condition has been
introduced 2006-08-27 with the patch
http://gcc.gnu.org/viewcvs?view=rev&revision=116502
Before the "if" the value is 0.1, af
--- Comment #7 from burnus at gcc dot gnu dot org 2007-02-22 13:59 ---
Forget to mention: If I comment out that if-block, the output is correct
(1.E-01). Now you need only to fix it without breaking the other PR ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30910
--
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
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=30929
--- Comment #15 from burnus at gcc dot gnu dot org 2007-02-23 14:12 ---
Subject: Bug 30793
Author: burnus
Date: Fri Feb 23 14:12:44 2007
New Revision: 122256
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122256
Log:
fortran/
2007-02-23 Tobias Burnus <[EMAI
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-23 16:18 ---
As the :ADDPATCH: mechanism didn't work:
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01839.html
--
burnus a
--- Comment #10 from burnus at gcc dot gnu dot org 2007-02-23 16:35 ---
Subject: Bug 30660
Author: burnus
Date: Fri Feb 23 16:35:25 2007
New Revision: 122263
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122263
Log:
2007-02-23 Paul Thomas <[EMAIL PROTECTED]&g
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
--- Comment #7 from burnus at gcc dot gnu dot org 2007-02-23 20:42 ---
> various intrinsics do not diagnose invalid argument kinds
The question is what is the right solution:
a) Only allow certain kinds
b) Allowing all kinds and doing the conversion/providing the needed functions.
--- Comment #16 from burnus at gcc dot gnu dot org 2007-02-23 20:53 ---
Fixed in 4.2 and the trunk.
Allocatable components are not in 4.1 and thus this bug fix cannot be ported to
4.1.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
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
on: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
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=30940
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-24 08:27 ---
(In reply to comment #1)
> This crash is with g77, which is no longer support.
To elaborate more: The GCC 4.x series comes with the compiler "gfortran" which
can compile Fortran 77/90/95 (and some
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-26 16:47 ---
I checked: " USE foo, ONLY:" is syntactically correct.
The problem is that "only_flag = 1;" and no symbol is in the only-list.
I think one needs to modify module.c's "read_module&qu
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-26 17:11 ---
Confirmed.
One needs the second "&" for:
"Hello&
& World"
But one does not need it for:
"Hello" &
, "World"
The following seems to be a gfortran
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-26 17:39 ---
> The bug in gfortran is that "Hello" & is correctly seen as non-character
> context whereas "Hello" & is wrongly regarded as character context.
The last line should be: &quo
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-26 20:17 ---
Patch.
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (Revision 122328)
+++ gcc/fortran/primary.c (Arbeitskopie)
@@ -773,7
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-26 21:36 ---
> Tobias, the same happens if the MODULE foo contains anything and the ONLY part
> actually lists something. I omitted this to keep the testcase short.
Good news. That means that indicates that my patch do
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-27 15:33 ---
The same is true for -Werror.
Warnings still give an exit status code of zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
--
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-02-27 17:07 ---
Could you post an example?
pow_r4_i4 means that you have x**a = **
I don't see how the exponent "a" can be infinity if it is an integer(4).
And the following program executes in <4 ms with gfort
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-27 17:44 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02134.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from burnus at gcc dot gnu dot org 2007-02-27 17:46 ---
The following additional patch needs to be applied when backporting:
http://gcc.gnu.org/ml/fortran/2007-02/msg00620.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30865
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-27 19:35 ---
Hi,
> > Could you post an example?
With example I mean something which actually compiles and runs. Here, I have
two problems:
include '$(where)/amos/include/essential.ecm'
is missing as
ssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30985
501 - 600 of 4285 matches
Mail list logo
