[Bug fortran/27552] -fdump-parse-tree doesn't like Holleriths (but then, who does?)
--- Comment #3 from fengwang at gcc dot gnu dot org 2006-05-18 02:31 --- Subject: Bug 27552 Author: fengwang Date: Thu May 18 02:31:41 2006 New Revision: 113881 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113881 Log: 2006-05-18 Francois-Xavier Coudert <[EMAIL PROTECTED]> Feng Wang <[EMAIL PROTECTED]> PR fortran/27552 * dump-parse-tree.c (gfc_show_expr): Deal with Hollerith constants. * data.c (create_character_intializer): Set from_H flag if character is initialized by Hollerith constant. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/data.c trunk/gcc/fortran/dump-parse-tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27552
[Bug fortran/28213] ICE: Hollerith constant
--- Comment #4 from fengwang at gcc dot gnu dot org 2006-07-11 04:09 --- Subject: Bug 28213 Author: fengwang Date: Tue Jul 11 04:09:40 2006 New Revision: 115326 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115326 Log: 2006-07-11 Feng Wang <[EMAIL PROTECTED]> PR fortran/28213 * gfortran.dg/hollerith4.f90: Test hollerith constants used in I/O list. 2006-07-11 Feng Wang <[EMAIL PROTECTED]> PR fortran/28213 * trans-io.c (ransfer_expr): Deal with Hollerith constants used in I/O list. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/hollerith4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28213
[Bug fortran/28213] ICE: Hollerith constant
--- Comment #5 from fengwang at gcc dot gnu dot org 2006-07-11 04:10 --- Subject: Bug 28213 Author: fengwang Date: Tue Jul 11 04:10:31 2006 New Revision: 115327 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115327 Log: 2006-07-11 Feng Wang <[EMAIL PROTECTED]> PR fortran/28213 * gfortran.dg/hollerith4.f90: Test hollerith constants used in I/O list. 2006-07-11 Feng Wang <[EMAIL PROTECTED]> PR fortran/28213 * trans-io.c (ransfer_expr): Deal with Hollerith constants used in I/O list. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-io.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/hollerith4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28213
[Bug fortran/28213] ICE: Hollerith constant
--- Comment #6 from fengwang at gcc dot gnu dot org 2006-07-13 06:34 --- Fixed on trunk and 4.1 -- fengwang at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28213
[Bug fortran/12456] please recognize Fortran STRING(K:K) as single character
--- Comment #12 from fengwang at gcc dot gnu dot org 2006-01-09 02:27 --- Subject: Bug 12456 Author: fengwang Date: Mon Jan 9 02:27:45 2006 New Revision: 109489 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109489 Log: fortran ChangeLog entry: 2006-01-09 Feng Wang <[EMAIL PROTECTED]> PR fortran/12456 * trans-expr.c (gfc_to_single_character): New function that converts string to single character if its length is 1. (gfc_build_compare_string):New function that compare string and handle single character specially. (gfc_conv_expr_op): Use gfc_build_compare_string. (gfc_trans_string_copy): Use gfc_to_single_character. * trans-intrinsic.c (gfc_conv_intrinsic_strcmp): Use gfc_build_compare_string. * trans.h (gfc_build_compare_string): Add prototype. testsuite ChangeLog entry: 2006-01-09 Feng Wang <[EMAIL PROTECTED]> PR fortran/12456 * gfortran.dg/single_char_string.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/single_char_string.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12456
[Bug fortran/12456] please recognize Fortran STRING(K:K) as single character
--- Comment #13 from fengwang at gcc dot gnu dot org 2006-01-09 02:54 --- Subject: Bug 12456 Author: fengwang Date: Mon Jan 9 02:54:25 2006 New Revision: 109491 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109491 Log: fortran 2006-01-09 Feng Wang <[EMAIL PROTECTED]> PR fortran/12456 * trans-expr.c (gfc_to_single_character): New function that converts string to single character if its length is 1. (gfc_build_compare_string):New function that compare string and handle single character specially. (gfc_conv_expr_op): Use gfc_build_compare_string. (gfc_trans_string_copy): Use gfc_to_single_character. * trans-intrinsic.c (gfc_conv_intrinsic_strcmp): Use gfc_build_compare_string. * trans.h (gfc_build_compare_string): Add prototype. 2006-01-09 Feng Wang <[EMAIL PROTECTED]> * simplify.c (gfc_simplify_char): Use UCHAR_MAX instead of literal constant. (gfc_simplify_ichar): Get the result from unsinged char and in the range 0 to UCHAR_MAX instead of CHAR_MIN to CHAR_MAX. testsuite 2006-01-09 Feng Wang <[EMAIL PROTECTED]> PR fortran/12456 * gfortran.dg/single_char_string.f90: New test. 2006-01-09 Feng Wang <[EMAIL PROTECTED]> * gfortran.dg/ichar2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/ichar_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/single_char_string.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/simplify.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans.h branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12456
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #5 from fengwang at gcc dot gnu dot org 2006-01-11 03:18 --- Also fails on ia64-linux-gnu. This is the ruduced case: module cutils implicit none private type t integer :: kk(3) = (/30, 40, 50 /) end type t integer :: n8 = 3 type(t) :: tt2 public :: IntToChar7 contains function IntToChar7(integerValue) result(a) integer, intent(in) :: integerValue character(len=tt2%kk(n8)) :: a write(a, *) integerValue end function IntToChar7 end module cutils program test use cutils end program test And the dumped parse tree: Namespace: A-Z: (UNKNOWN 0) procedure name = cutils symtree: n8 Ambig 0 symbol n8 (INTEGER 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC) value: 3 symtree: cutils Ambig 0 symbol cutils (UNKNOWN 0)(MODULE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC) symtree: inttochar7 Ambig 0 symbol inttochar7 (CHARACTER cutils:tt2 % kk(__convert_i4_i8[[((cutils:n8))]]))(PROCEDURE UNKNOWN-INTENT PUBLIC MODULE-PROC FUNCTION) result: a Formal arglist: integervalue symtree: t Ambig 0 symbol t (UNKNOWN 0)(DERIVED UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC) components: (kk (INTEGER 4) DIMENSION (1 AS_EXPLICIT 1 3 )) symtree: tt2 Ambig 0 symbol tt2 (DERIVED t)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC) value: t((/ 30 , 40 , 50 /)) CONTAINS Namespace: A-Z: (UNKNOWN 0) procedure name = inttochar7 symtree: a Ambig 0 symbol a (CHARACTER cutils:tt2 % kk(__convert_i4_i8[[((cutils:n8))]]))(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC RESULT) symtree: integervalue Ambig 0 symbol integervalue (INTEGER 4)(VARIABLE IN UNKNOWN-ACCESS UNKNOWN-PROC DUMMY) symtree: inttochar7 Ambig 0 from namespace cutils WRITE UNIT=inttochar7:a FMT=-1 TRANSFER inttochar7:integervalue DT_END char_result_11.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Please note that symbol inttochar7 (CHARACTER cutils:tt2 % kk(__convert_i4_i8[[((cutils:n8))]])) I think it's the conversion that triggers the ICE. And If I use literal constant 3 instead of n8 in the fortran source code, it will be passed. -- fengwang at gcc dot gnu dot org changed: What|Removed |Added CC| |fengwang at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #6 from fengwang at gcc dot gnu dot org 2006-01-11 03:38
---
And the backtrace:
#0 mio_expr (ep=0x60033298)
at ../../gcc-4.2-20051231/gcc/fortran/module.c:1472
#1 0x4007caa0 in mio_charlen (clp=0x600fc0a8)
at ../../gcc-4.2-20051231/gcc/fortran/module.c:1668
#2 0x4007d5c0 in mio_typespec (ts=0x600fc098)
at ../../gcc-4.2-20051231/gcc/fortran/module.c:1726
#3 0x4007b9d0 in mio_expr (ep=0x600fc778)
at ../../gcc-4.2-20051231/gcc/fortran/module.c:2502
#4 0x4007d060 in mio_ref (rp=Variable "rp" is not available.
)
at ../../gcc-4.2-20051231/gcc/fortran/module.c:1809
#5 0x4007d500 in mio_ref_list (rp=0x600fc428)
in mio_charlen function, it run into
if (iomode == IO_OUTPUT)
1665{
1666 cl = *clp;
(gdb)
1667 if (cl != NULL)
1668mio_expr (&cl->length); <<<< ICE HERE!
1669}
(gdb) p *cl
$7 = {length = 0x1, next = 0x0, backend_decl = 0x0, resolved = 0}
The character length is an expression, not a constant integer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug fortran/18827] ICE on assign to common variable
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-03-16 00:19 --- Fixed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18827
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 18827, which changed state. Bug 18827 Summary: ICE on assign to common variable http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18827 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/20713] New: Don't pad parameter strings.
character(len = 10),parameter:: a = 'hello'
print *, a, "world"
end
the output:
helloworld.
--
Summary: Don't pad parameter strings.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: fengwang at gcc dot gnu dot org
ReportedBy: fengwang at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20713
[Bug fortran/23852] New: Array element as format specification.
Now we allow array and array element as format specification. The array should be assigned HOLLERITH constant first. The question is that if we should allow array element here. g77, pgf deny this, but intel accepts. Some discussions: http://gcc.gnu.org/ml/fortran/2005-09/msg00191.html http://gcc.gnu.org/ml/fortran/2005-09/msg00217.html -- Summary: Array element as format specification. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fengwang at gcc dot gnu dot org CC: Tobias dot Schlueter at physik dot uni-muenchen dot de,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23852
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-09-13 14:53 --- (In reply to comment #8) > Bloody hell. Stupid bug. > Alright then, let's see if I can fix this one. Steven, it seems to disappear on current gcc4.1 and gcc4.0. I once send you a patch to fix the gimple problem. The patch is attached. And this patch fixes another compiling ICE in the test case: subroutine s1 (a) integer a assign 777 to a go to a 777 print *, "Hello s1" end program test call s1 (1) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug fortran/24327] New: Does not detect duplicate symbol names in contains block
$cat test.f90 program test real :: foo contains function foo () end function foo end program test Gfortran passes it. If add external attribute, we'll get ICE. $cat test2.f90 program test real, external :: foo contains function foo () end function foo end program test $gfortran test2.f90 test2.f90: In function âMAIN__â? test2.f90:7: internal compiler error: in build_function_decl, at fortran/trans -decl.c:1063 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --enable-languages=c,fortran --prefix=/home/wf /local : (reconfigured) ../gcc/configure --prefix=/home/wf/local --enable-langua ges=c,fortran --no-create --no-recursion : (reconfigured) ../gcc/configure --pre fix=/home/wf/local --enable-languages=c,fortran --no-create --no-recursion Thread model: posix gcc version 4.1.0 20051010 (experimental) -- Summary: Does not detect duplicate symbol names in contains block Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, accepts-invalid Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fengwang at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24327
[Bug fortran/12456] please recognize Fortran STRING(K:K) as single character
--- Comment #10 from fengwang at gcc dot gnu dot org 2005-10-25 05:31 --- This will improve 168.wupwise at lease 1%. And I have partially fixed. Patches are coming soon. -- fengwang at gcc dot gnu dot org changed: What|Removed |Added CC||fengwang at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fengwang at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12456
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Comment #13 from fengwang at gcc dot gnu dot org 2005-10-25 14:09 --- Fixed. -- fengwang at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug tree-optimization/20610] Real by complex multiplications perform unnecessary operations
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-06-23 07:52 --- And in extract_component() in tree-complex.c file, I need handle VIEW_CONVER_EXPR. On gfortran front end, I need treat other type data as complex. So I build VIEW_CONVER_EXPR tree node and failed at extract_component(). Can you fix this, Richard? -- What|Removed |Added CC||wf_cs at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20610
[Bug libfortran/22170] New: Handle format slash error
write (*, "(3/)") end output 9 lines. Seems to double count repeated slash. -- Summary: Handle format slash error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fengwang at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22170
[Bug tree-optimization/22290] New: Optimize Assigned GOTO to cause error with -O1 or higher
See a fortran program:
$ cat t.f
integer nz
assign 93 to nz
go to nz,(93)
93 continue
end
$ gfortran -v
Target: ia64-unknown-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,f95 --
prefix=/home/wf/loc
al
Thread model: posix
gcc version 4.1.0 20050704 (experimental)
$ gfortran -O0 -w t.f
$ ./a.out
That's correct.
But if we compile with -O1 or higher, we get
$ ./a.out
Fortran runtime error: Assigned label is not in the list
We dump the original tree with -fdump-tree-original as follows:
MAIN__ ()
{
int4 nz;
void * nz.1;
int4 nz.0 = -2;
nz.0 = -1;
nz.1 = &__label_93;
if (__builtin_expect (nz.0 != -1, 0))
{
_gfortran_runtime_error ("Assigned label is not a target
label", "kgfm2.f"
, 5);
}
else
{
(void) 0;
}
if (&__label_93 == nz.1) goto __label_93; else (void) 0;
_gfortran_runtime_error ("Assigned label is not in the list", "kgfm2.f", 5);
__label_93:;
}
That's correct.
I think this is tree-optimization error. Tested on ia64/i686-pc-linux.
--
Summary: Optimize Assigned GOTO to cause error with -O1 or higher
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fengwang at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686/ia64-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-04 12:38 --- (In reply to comment #1) > Confirmed, This is a fortran front-end or gimplifier bug. > Look at what the gimplifier produces: > int4 nz.0 = -2; // <--- this is not gimple I am not very clear the gimple definition. Can you explain more? This is the initialization of nz.0 variable. I use this variable to indicate the integer is assigned a format label (-1) or target label (now it is the length of format string). See fortran/trans-decl.c (gfc_get_symbol_decl): 815 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-05
08:39 ---
(In reply to comment #3)
> "int4 nz.0 = -2;" look line an INIT_EXPR. It should be
>
> "int4 nz.0;
> nz.0 = -2"
Shall we add an assignment explicitly? Just give an initial value. I don't
think we should defer doing this when generate function codes.
And another question, all the variables which have initial values are treat as
static. Is this reasonable?
Back to this topic, in fact, the error is not caused by nz.0. It is used to
judge if we assign a target label. And the output is "Assigned label is not in
the list". So it has passed the judgement of nz.0.
>From the trees dumped, I found the CCP pass is wrong:
$cat as.f.t22.ccp
;; Function MAIN__ (MAIN__)
Removing basic block 3
Merging blocks 2 and 4
Merging blocks 2 and 5
MAIN__ ()
{
void * gotovar.2;
void * nz.1;
int4 nz.0 = -2;
int4 nz;
D.476;
logical4 D.475;
:
nz.0_1 = -1;
nz.1_2 = &__label_93;
D.475_3 = 0;
D.476_4 = 0;
if (D.476_4 != 0) goto ; else goto ;
:;
_gfortran_runtime_error ("Assigned label is not a target label", "as.f", 2);
__label_93:; <<<<<<<<<<<<<<<<<<<< Wrong here.
:;
_gfortran_runtime_error ("Assigned label is not in the list", "as.f", 2
return;
}
Before this pass, it it correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-05 08:44 --- >From as.f.t22.ccp: : nz.0_1 = -1; nz.1_2 = &__label_93; D.475_3 = 0; D.476_4 = 0; if (D.476_4 != 0) goto ; else goto ; This is also wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-06 07:42 --- (In reply to comment #4) > And another question, all the variables which have initial values are treat > as static. Is this reasonable? Yes, this is reasonable. Confirm myself. In section 5.1 (Fortran95, Working draft J3/97-007R2): The presence of initialization implies that object-name is saved, except for an object-name in a named common block or an object-name with the PARAMETER attribute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug fortran/20883] unassigned integer used as format
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-07 09:31 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20883
[Bug fortran/22327] [4.0 only] Wrong code in array constructor
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fengwang at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22327
[Bug fortran/16531] [4.0 only, gfortran] Hollerith Data not supported
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fengwang at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Summary|[gfortran] Hollerith Data |[4.0 only, gfortran] |not supported |Hollerith Data not supported http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16531
[Bug fortran/15966] [4.0 Only] ICE and segmentation fault on internal write
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fengwang at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Summary|ICE and segmentation fault |[4.0 Only] ICE and |on internal write |segmentation fault on ||internal write http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15966
[Bug fortran/18481] [g77 regression] ICE with assigned integer variable format
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-07 09:56 --- (In reply to comment #6) > The example in comment #0, I get the following error: > In file t.f:4 > read(chr,k) > 1 > Error: Variable 'k' has not been assigned a format label at (1) Fixed. They are all fixed by: http://gcc.gnu.org/ml/fortran/2005-05/msg00054.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18481
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 18481, which changed state. Bug 18481 Summary: [g77 regression] ICE with assigned integer variable format http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18481 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/22342] Internal write to character array causes "internal compiler error"
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-07 10:04 --- *** This bug has been marked as a duplicate of 15966 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22342
[Bug fortran/15966] [4.0 Only] ICE and segmentation fault on internal write
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-07 10:04 --- *** Bug 22342 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||mick at nag dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15966
[Bug libfortran/22423] New: Warnings when building libgfortran
(near initialization for
../../../gcc/libgfortran/io/list_read.c:2188: warning: missing braces around
ini
../../../gcc/libgfortran/io/list_read.c:2188: warning: (near initialization for
../../../gcc/libgfortran/io/list_read.c:2025: warning: 'first_nl' may be used
un
../../../gcc/libgfortran/io/list_read.c:2026: warning: 'root_nl' may be used
uni
../../../gcc/libgfortran/intrinsics/eoshift0.c:50: warning: 'roffset' may be
use
../../../gcc/libgfortran/intrinsics/eoshift0.c:64: warning: 'len' may be used
un
../../../gcc/libgfortran/intrinsics/eoshift0.c:56: warning: 'soffset' may be
use
../../../gcc/libgfortran/intrinsics/eoshift2.c:68: warning: 'len' may be used
un
../../../gcc/libgfortran/intrinsics/eoshift2.c:56: warning: 'soffset' may be
use
../../../gcc/libgfortran/intrinsics/eoshift2.c:50: warning: 'roffset' may be
use
../../../gcc/libgfortran/intrinsics/spread_generic.c:48: warning: 'rdelta' may
b
../../../gcc/libgfortran/intrinsics/rename.c:61: warning: implicit declaration
o
../../../gcc/libgfortran/intrinsics/rename.c:61: warning: incompatible implicit
../../../gcc/libgfortran/intrinsics/rename.c:68: warning: implicit declaration
o
../../../gcc/libgfortran/intrinsics/rename.c:94: warning: incompatible implicit
../../../gcc/libgfortran/intrinsics/unpack_generic.c:194: warning: passing
argum
[snip]
--
Summary: Warnings when building libgfortran
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fengwang at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug fortran/21730] Character length incorrect.
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-14
02:49 ---
I think we have to consider character arrays. See:
character*2 a (1)
character*4 b
character*6 c
parameter (a="12")
parameter (b = a(1))
write (c,'("#",A,"#")') b
if (c .ne. '#12 #') call abort
end
Or:
character*2 a (1)
character*4 b (1)
character*6 c
parameter (a="12")
parameter (b = a)
write (c,'("#",A,"#")') b
if (c .ne. '#12 #') call abort
end
gfortran report an Internal Error.
IMHO, your patch only handles the scalar character and is not entire, though a
different bug is revealed by the above examples.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug fortran/21730] Character length incorrect.
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-14 03:30 --- For comment #5, here is the backtrace: #0 gfc_internal_error ( format=0x8447620 "Initialization expression didn't reduce %C") at ../../gcc/gcc/fortran/error.c:662 #1 0x0805da16 in gfc_match_init_expr (result=0x0) at ../../gcc/gcc/fortran/expr.c:1523 #2 0x080586e8 in do_parm () at ../../gcc/gcc/fortran/decl.c:3084 #3 0x08058838 in gfc_match_parameter () at ../../gcc/gcc/fortran/decl.c:3135 #4 0x0807394b in match_word (str=0x0, subr=0x8058811 , old_locus=0x0) at ../../gcc/gcc/fortran/parse.c:65 #5 0x080740ee in decode_statement () at ../../gcc/gcc/fortran/parse.c:248 #6 0x080745fc in next_statement () at ../../gcc/gcc/fortran/parse.c:498 #7 0x08075279 in parse_spec (st=ST_PARAMETER) at ../../gcc/gcc/fortran/parse.c:1589 #8 0x08075c47 in parse_progunit (st=ST_ARITHMETIC_IF) at ../../gcc/gcc/fortran/parse.c:2287 #9 0x080760ec in gfc_parse_file () at ../../gcc/gcc/fortran/parse.c:2612 #10 0x08087e7c in gfc_be_parse_file (set_yydebug=0) at ../../gcc/gcc/fortran/f95-lang.c:263 #11 0x082d9d84 in compile_file () at ../../gcc/gcc/toplev.c:975 #12 0x082db33f in do_compile () at ../../gcc/gcc/toplev.c:1941 #13 0x082db3a1 in toplev_main (argc=2, argv=0xbfffde94) at ../../gcc/gcc/toplev.c:1973 #14 0x080ac2e3 in main (argc=2, argv=0xbfffde94) at ../../gcc/gcc/main.c:35 #15 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug fortran/21730] Character length incorrect.
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-14 03:46 --- I just hope you could work on this ;-) Having a good start, why not fix entirely? If somebody agrees to fix step by step, I have no objection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug middle-end/26001] [4.1 Regression] expand uses the wrong part of the string for array accesses
--- Comment #26 from fengwang at gcc dot gnu dot org 2006-02-04 07:51 --- Andrew, thank you for fixing this so quickly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug fortran/21730] New: Character length incorrect.
character*2 a
character*4 b
parameter(a="12")
parameter (b = a)
write (*, *) b
end
gfortran output: "12"
correct output: "12 "
--
Summary: Character length incorrect.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fengwang at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 19276
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
-- What|Removed |Added BugsThisDependsOn||21730 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
[Bug fortran/18481] [g77 regression] ICE with assigned integer variable format
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-05-25 10:45 --- Issues (#2, #3) related ASSIGN statement should be fixed by http://gcc.gnu.org/ml/fortran/2005-05/msg00054.html [committed]. Issue in the description should be fixed by http://gcc.gnu.org/ml/fortran/2005-05/msg00280.html [under reviewing]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18481
[Bug fortran/20883] unassigned integer used as format
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fengwang at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20883
