[Bug fortran/45710] WRITE of NAMELIST group to internal file contains newline characters
--- Comment #3 from kargl at gcc dot gnu dot org 2010-09-18 17:11 --- (In reply to comment #2) So what was required to clarify an issue for a number of people ended up confusing you. Also note that every compiler tried (XL, ifort, g95, gfortran) had different results, which was only clear when OUT was filled with a non-white-space character and annotated. Looking back on it I see that what we thought was a trivial example program could confuse someone not privy to the discussions that lead from the above example code to what was entered in bugzilla. Please go to http://gcc.gnu.org/buzilla/show_bug.cgi?id=45710 My original comment was directed at how *extremely difficult* it is to read your bug report because of the poorly formatted narrative. Long lines get wrapped in bugzilla, which means that the large comment in the posted code is broken into different lines that are no longer comments. So one cannot simply cut-n-paste the original code into a program that one can easily compile to demonstrate the problem. Oh, and yes, you should have included the original simple program because that program is a good candidate for the dejagnu testsuite; whereas the large code may be more difficult to add the dg directives and possibly a final scan pass of an intermediate file. For the sarcasm impaired, the above was purposely written with poor line breaks to hopefully demonstrate the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710
[Bug fortran/45710] WRITE of NAMELIST group to internal file contains newline characters
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-17 21:53 --- Could you format your bug report any more poorly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710
[Bug fortran/45681] internal compiler error: in make_decl_rtl, at varasm.c:1297
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-15 18:30 --- Thanks for the bug report. The problem appears to be fixed in gcc version 4.6.0 20100913 (experimental) (GCC) and gcc version 4.5.1 20100728 (prerelease) (GCC). It is unlikely that this will be fixed in 4.4.x because it does not appear to be a regression. The code has the same failure in 4.2.x and 4.3.x. If it is possible to upgrade to 4.5.x, then I suggest that route. A possible work around is to change the declaration of 'character*(n) c' to 'character*(*) c'. I'll leave the bug report open for a few days to see if one of the other gfortran developers has a quick fix, but I think this problem is going to be caught by insufficient man power to fixed it. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45681
[Bug fortran/45681] internal compiler error: in make_decl_rtl, at varasm.c:1297
--- Comment #3 from kargl at gcc dot gnu dot org 2010-09-15 21:08 --- (In reply to comment #2) Hi, as it's already fixed in newer versions, please don't spend any more time on this. OK. Once again thanks for sending a bug report. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45681
[Bug fortran/45636] Failed to fold simple Fortran string
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-10 15:12 --- I have a slightly different result with your code. troutmask:sgk[212] gfc4x -c -O g.f90 g.f90: In function 'rcrdrd': g.f90:1:0: internal compiler error: in build_int_cst_wide, at tree.c:1218 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. If I replace the SAVE attribute by PARAMETER (which will most likely cause the folding you want), everything compiles fine. The ICE also goes away if I increase the length of DBL from one to any larger value. troutmask:sgk[219] gfc4x -v Using built-in specs. COLLECT_GCC=/home/sgk/work/4x/bin/gfortran COLLECT_LTO_WRAPPER=/usr/home/sgk/work/4x/bin/../libexec/gcc/x86_64-unknown-freebsd9.0/4.6.0/lto-wrapper Target: x86_64-unknown-freebsd9.0 Configured with: ../gcc4x/configure --prefix=/home/sgk/work/4x --enable-languages=c,fortran --disable-libmudflap --disable-bootstrap --with-quad=/home/sgk/work Thread model: posix gcc version 4.6.0 20100909 (experimental) (GCC) -- kargl at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636
[Bug fortran/45636] Failed to fold simple Fortran string
--- Comment #2 from kargl at gcc dot gnu dot org 2010-09-10 15:20 ---
The -fdump-tree-original for HJ's original code look like
rcrdrd (character(kind=1)[1:4] restrict vtyp, integer(kind=4) _vtyp)
{
static character(kind=1) dbl[1:1] = D;
(MEM[(c_char * {ref-all})vtyp] = MEM[(c_char * {ref-all})dbl];, (void *)
vtyp;);
__builtin_memset ((void *) vtyp + 1, 32, 3);
}
If I increase the length of DBL to 2, then the dump looks like
rcrdrd (character(kind=1)[1:4] restrict vtyp, integer(kind=4) _vtyp)
{
static character(kind=1) dbl[1:2] = D ;
__builtin_memmove ((void *) vtyp, (void *) dbl, 2);
__builtin_memset ((void *) vtyp + 2, 32, 2);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636
[Bug fortran/45636] Failed to fold simple Fortran string
--- Comment #4 from kargl at gcc dot gnu dot org 2010-09-10 15:34 --- (In reply to comment #3) (In reply to comment #1) I have a slightly different result with your code. troutmask:sgk[212] gfc4x -c -O g.f90 g.f90: In function 'rcrdrd': g.f90:1:0: internal compiler error: in build_int_cst_wide, at tree.c:1218 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It is fixed by http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00475.html HJ, Thanks. I updated by trunk right before your patch, so I missed it my most recent build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636
[Bug fortran/45495] ICE: For character function with length specifier dependent on non-present arg
--- Comment #6 from kargl at gcc dot gnu dot org 2010-09-09 19:02 --- Fixed in trunk. No plans for back port to 4.5.x branch. I'll open a bug report about intent(out) issues with dummy arguments. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45495
[Bug fortran/45619] New: intent(out) dummy arguements in specification statements
gfortran does not correctly check that an intent(out) dummy argument does not appear in a specification statement. The following code is invalid, yet gfortan compiles it without error. subroutine sub(n, s) integer, intent(out) :: n character(len=*), intent(out) :: s character(len=len(s)) :: a ! Valid even though s is intent(out) character(len=len(s(1:n))) :: b! Invalid because n is intent(out) n = 0 a = 'tobias' s = a b = a end subroutine See the discussion in http://gcc.gnu.org/ml/fortran/2010-09/msg00074.html for more details. -- Summary: intent(out) dummy arguements in specification statements Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45619
[Bug c/45620] GCC library allows the use of a negative value for 'NAN'
--- Comment #3 from kargl at gcc dot gnu dot org 2010-09-09 20:44 --- (In reply to comment #2) How do I open a glibc bug? Although you say that the sign bit is set, thus you can have a negative NAN. But it does not make much sense to allow this. A negative not-a-number is not mathematically sensible. It wasn't the case in previous releases of the library, so why did it just suddenly change? This change is causing some of our code to break, so we would like to investigate it more before we are able to change code to accommodate new changes. I believe you may need to fix your code. The draft of the IEEE 754 standard (dated OCt 2006) I have states 8.2.1 NaN encodings in binary formats This clause further specifies the encodings of NaNs as bit strings when they are the results of operations. When encoded, all NaNs have a sign bit and a pattern of bits necessary to identify the encoding as a NaN and which determines its kind (sNaN vs. qNaN). The remaining bits, which are in the trailing field, encode the payload, which might be diagnostic information (see 8.2). 8.3 The sign bit When either an input or result is NaN, this standard does not interpret the sign of a NaN. Note however that operations on bitstrings copy, negate, abs, copySign specify the sign bit of a NaN result, sometimes based upon the sign bit of a NaN operand. The logical predicate totalOrder is also affected by the sign bit of a NaN operand. For all other operations, this standard does not specify the sign bit of a NaN result, even when there is only one input NaN, or when the NaN is produced from an invalid operation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45620
[Bug fortran/45624] Division by zero compiler error
--- Comment #2 from kargl at gcc dot gnu dot org 2010-09-09 22:25 --- There is no way to fix this problem unless you would like +inf along the diagonal. gfortran will constant fold 1./alpha if alpha has the parameter attribute. After all, this attribute tells the compiler that alpha is a named constant, ie., it will not change. PS: Fortran bugs are never given a severity high than normal unless the bug breaks bootstrapping the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45624
[Bug fortran/45495] ICE: For character function with length specifier dependent on non-present arg
--- Comment #3 from kargl at gcc dot gnu dot org 2010-09-02 14:17 --- (In reply to comment #2) Confirm: It compiles with g95 and NAG f95, but ICEs with gfortran (4.1 to 4.6) and a couple of other compilers. My feeling is that the program is invalid - at least in case the actual argument is not present. Yes, the code is invalid. See restrictions on specification expression. C710 and 3 lines down to item (2). PS: I'm willing to bet that you can get g95 (and may be Nag) to die on the code by replacing jack = '' in the subroutine with a sufficiently long string on the RHS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45495
[Bug fortran/45495] ICE: For character function with length specifier dependent on non-present arg
--- Comment #4 from kargl at gcc dot gnu dot org 2010-09-02 20:12 --- I may have a patch for this one. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-09-02 11:32:28 |2010-09-02 20:13:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45495
[Bug fortran/45495] ICE: For character function with length specifier dependent on non-present arg
--- Comment #5 from kargl at gcc dot gnu dot org 2010-09-02 21:46 --- http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00190.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45495
[Bug fortran/45463] gfortran internal write bug
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-31 13:28 --- Did you see the responses to your post in c.l.f? It seems that your program is non-conforming. I leave the PR open until either I or someone else has time to verify the conformity of the program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45463
[Bug fortran/45463] gfortran internal write bug
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-31 16:40 --- (In reply to comment #3) (In reply to comment #2) Sorry. When I looked after I had posted the question there was only one response and that response said it was a bug so I submitted this bug report. Now other people have posted saying that the program is non-conforming. Update: More responses in comp.lang.fortran bring up the point that if trim(line) is supposed to return a temporary, the code might be conforming. Seems that the situation is not clear... IMNSHO, it's not conforming. trim(line) is associated with line. I don't see how one could interpret the standard in in other way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45463
[Bug fortran/45463] gfortran internal write bug
--- Comment #5 from kargl at gcc dot gnu dot org 2010-08-31 16:49 --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) Sorry. When I looked after I had posted the question there was only one response and that response said it was a bug so I submitted this bug report. Now other people have posted saying that the program is non-conforming. Update: More responses in comp.lang.fortran bring up the point that if trim(line) is supposed to return a temporary, the code might be conforming. Seems that the situation is not clear... IMNSHO, it's not conforming. trim(line) is associated with line. I don't see how one could interpret the standard in in other way. In fact, 16.5.7 in F2003, is fairly unambiguous. The code is nonconforming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45463
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-31 17:53 ---
Try compiling with -fdump-tree-original and inspecting the
expected argument lists. You really don't want to use a
function here. Use a subroutine.
include stdio.h
void requestdouble_(double*, double*, char *, int *len);
int main()
{
char str[20];
int len;
double lat=10.0;
double lon=20.0;
requestdouble_(lat, lon, str, len);
return 0;
}
subroutine requestdouble(rlat,rlng,str)
IMPLICIT NONE
REAL(KIND=8), INTENT(IN) :: rlat ! - latitude -
REAL(KIND=8), INTENT(IN) :: rlng ! - longitude -
CHARACTER(LEN=*) :: str
PRINT *, ' requestdouble rlat=', rlat,' rlng=', rlng
str=''
RETURN
END subroutine requestdouble
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-31 17:53 --- Closing as INVALID. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #6 from kargl at gcc dot gnu dot org 2010-08-31 19:09 --- (In reply to comment #5) Thanks. I do know how to work around it with subroutine which I already did in my program. But it doesn't explain why 4.1.2 version allows return character string from function. Our program works well until the gcc upgrade. Is this new standard? I don't know what you mean by 'new standard'. I have gfortran 4.3.x, 4.4.x, 4.5.x, and 4.6.0 installed. -fdump-tree-original for these compilers all show 4.3 requestdouble (__result, .__result, rlat, rlng) 4.4, 4.5, and 4.6: requestdouble (character(kind=1)[1:.__result] __result, integer(kind=4) .__result, real(kind=8) rlat, real(kind=8) rlng) The first returned argument is a pointer to the string and the second returned argument is the length. I don't know what 4.1 and 4.2 do. You're clearly (ab)using the abi to do mixed language program, and you need to investigate the calling conventions when you have problems. -- steve -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug libfortran/45436] [4.6 Regression] Failed to bootstrap
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-27 23:39 --- I believe that it is related to r163597. During the build of libgfortran, the file kinds.h is generated. This file now has GFC_REAL_10 and GFC_REAL_16 typedef'd to 'long double'. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-27 23:39:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45436
[Bug libfortran/45436] [4.6 Regression] Failed to bootstrap
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-27 23:47 --- FX, I've added you to this pr because I think your recent patch to start integration of the REAL(16) code is the cause. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45436
[Bug libfortran/45436] [4.6 Regression] Failed to bootstrap
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-28 00:25 --- Reverting 163597 fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45436
[Bug fortran/45339] Failure on interfacing a function passed as an argument as a custom operator
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-19 13:08 --- *** This bug has been marked as a duplicate of 45338 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45339
[Bug fortran/45338] Failure on interfacing a function passed as an argument as a custom operator
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-19 13:08 --- *** Bug 45339 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45338
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
--- Comment #6 from kargl at gcc dot gnu dot org 2010-08-19 23:28 --- (In reply to comment #5) Created an attachment (id=21526) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21526action=view) [edit] Run-time implementation Implementation works, but I would like to pass the arguments by VALUE not by reference. Additionally, a test case is missing. I read the patch. It looks correct to me. This is OK to commit ever with the by reference semantics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
[Bug fortran/45170] [F2003] allocatable character lengths
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-15 18:46 --- A patch to do the parsing and some error checking has been posted at http://gcc.gnu.org/ml/fortran/2010-08/msg00181.html It is not a complete implementation of the feature and requires much additional work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
[Bug fortran/45244] Incorrect passing of character string array argument triggers an internal compiler error
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-10 17:49 ---
Might as well confirm the bug.
This patch stops the segmentation fault, but I do not know
if it is the correct fix.
Index: interface.c
===
--- interface.c (revision 163075)
+++ interface.c (working copy)
@@ -1611,7 +1611,8 @@ compare_parameter (gfc_symbol *formal, g
if (formal-ts.type == BT_CHARACTER
(ref == NULL
|| (actual-expr_type == EXPR_VARIABLE
- (actual-symtree-n.sym-as-type == AS_ASSUMED_SHAPE
+ ((actual-symtree-n.sym-as
+ actual-symtree-n.sym-as-type == AS_ASSUMED_SHAPE)
|| actual-symtree-n.sym-attr.pointer
{
if (where (gfc_option.allow_std GFC_STD_F2003) == 0)
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-08-10 17:49:56
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45244
[Bug fortran/45244] Incorrect passing of character string array argument triggers an internal compiler error
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-10 20:19 --- The patch in comment #4 passes regression testing on x86_64-*-freebsd. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45244
[Bug fortran/45244] Incorrect passing of character string array argument triggers an internal compiler error
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-10 02:37 --- Created an attachment (id=21444) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21444action=view) Reduced testcase Reduced testcase. gdb shows Program received signal SIGSEGV, Segmentation fault. 0x080ed4c0 in compare_actual_formal (ap=0x4969174c, formal=0x495054e8, ranks_must_agree=0, is_elemental=0, where=0x4969171c) at ../../gcc4x/gcc/fortran/interface.c:1606 warning: Source file is more recent than executable. 1606if (ref-type == REF_ARRAY ref-u.ar.type == AR_ELEMENT (gdb) bt #0 0x080ed4c0 in compare_actual_formal (ap=0x4969174c, formal=0x495054e8, ranks_must_agree=0, is_elemental=0, where=0x4969171c) at ../../gcc4x/gcc/fortran/interface.c:1606 #1 0x080eec1c in gfc_procedure_use (sym=0x496973c0, ap=0x4969174c, where=0x4969171c) at ../../gcc4x/gcc/fortran/interface.c:2623 #2 0x0812a978 in resolve_call (c=0x49691710) at ../../gcc4x/gcc/fortran/resolve.c:3288 #3 0x0812b341 in resolve_code (code=0x49691710, ns=0x49623200) at ../../gcc4x/gcc/fortran/resolve.c:8617 #4 0x0812c453 in resolve_codes (ns=0x49623200) at ../../gcc4x/gcc/fortran/resolve.c:13052 #5 0x0812c37c in resolve_codes (ns=0x49621d00) at ../../gcc4x/gcc/fortran/resolve.c:13038 #6 0x0812c52c in gfc_resolve (ns=0x49621d00) at ../../gcc4x/gcc/fortran/resolve.c:13079 #7 0x0811f4c7 in gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:4379 #8 0x08153e30 in gfc_be_parse_file (set_yydebug=0) at ../../gcc4x/gcc/fortran/f95-lang.c:236 #9 0x0848fc35 in do_compile () at ../../gcc4x/gcc/toplev.c:978 #10 0x084909c6 in toplev_main (argc=2, argv=0xbfbfe57c) at ../../gcc4x/gcc/toplev.c:2374 #11 0x081ada92 in main (argc=4, argv=0x6) at ../../gcc4x/gcc/main.c:36 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45244
[Bug bootstrap/45206] [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc
--- Comment #5 from kargl at gcc dot gnu dot org 2010-08-10 02:54 --- Does anyone know which combination of recent commits is causing this problem? I've tried individually backing out several of the likely offenders, but I still can't bootstrap. So, I'm guessing that I need to back out some set of commits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
[Bug bootstrap/45206] [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-08 15:15 --- Change severity to blocker. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|blocker Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
[Bug bootstrap/45222] New: internal compiler error: in ix86_expand_epilogue
Someone has broken bootstrap on i386-*-freebsd. I've backed out r162837, r162 /usr/home/kargl/gcc/obj4x/./gcc/xgcc -B/usr/home/kargl/gcc/obj4x/./gcc/ -B/usr/home/kargl/work/i386-unknown-freebsd9.0/bin/ -B/usr/home/kargl/work/i386-unknown-freebsd9.0/lib/ -isystem /usr/home/kargl/work/i386-unknown-freebsd9.0/include -isystem /usr/home/kargl/work/i386-unknown-freebsd9.0/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../gcc4x/libgcc -I../../../gcc4x/libgcc/. -I../../../gcc4x/libgcc/../gcc -I../../../gcc4x/libgcc/../include -DHAVE_CC_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c ../../../gcc4x/libgcc/../gcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from ../../../gcc4x/libgcc/../gcc/unwind-dw2.c:1582:0: ../../../gcc4x/libgcc/../gcc/unwind.inc: In function '_Unwind_RaiseException': ../../../gcc4x/libgcc/../gcc/unwind.inc:136:1: internal compiler error: in ix86_expand_epilogue, at config/i386/i386.c:10184 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gmake[2]: *** [unwind-dw2.o] Error 1 gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/libgcc' gmake[1]: *** [all-target-libgcc] Error 2 gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj4x' gmake: *** [all] Error 2 -- Summary: internal compiler error: in ix86_expand_epilogue Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org GCC host triplet: i386-unknown-freebsd http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45222
[Bug bootstrap/45222] internal compiler error: in ix86_expand_epilogue
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-07 05:49 --- (In reply to comment #0) Someone has broken bootstrap on i386-*-freebsd. I've backed out r162837, r162 I meant to state that I've backout 162837, 162888, 162889, and one other likely recent commit to no avail. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Summary|internal compiler error: in |internal compiler error: in |ix86_expand_epilogue|ix86_expand_epilogue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45222
[Bug fortran/45190] Compile-time error on valid code: can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr)
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-05 15:46 --- The problem also occurs with 4.6.0. Note, if you remove the ', only : c_ptr' in NAG_J_TYPES, the code compiles and produces laptop:kargl[214] gfc4x -o z tr.f90 laptop:kargl[215] ./z C_ASSOCIATED = T ASSOCIATED = T So, there appears to be a problem with using an ONLY clause with ISO C binding. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-05 15:46:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45190
[Bug fortran/45183] [4.6 Regression] FAIL: gfortran.dg/derived_constructor_char_1.f90
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-04 18:09 ---
(In reply to comment #1)
PATCH - lightly tested. Now regtesting.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (Revision 162868)
+++ gcc/fortran/resolve.c (Arbeitskopie)
@@ -936,11 +936,26 @@ resolve_structure_cons (gfc_expr *expr)
p = gfc_constructor_first (cons-expr-value.constructor);
if (cons-expr-ts.u.cl != p-expr-ts.u.cl)
{
- gfc_free_expr (cons-expr-ts.u.cl-length);
- gfc_free (cons-expr-ts.u.cl);
+ gfc_charlen *cl, *cl2;
+
+ cl2 = NULL;
+ for (cl = gfc_current_ns-cl_list; cl; cl = cl-next)
+ {
+ if (cl == cons-expr-ts.u.cl)
+ break;
+ cl2 = cl;
+ }
+
+ gcc_assert (cl);
+
+ if (cl2)
+ cl2-next = cl-next;
+
+ gfc_free_expr (cl-length);
+ gfc_free (cl);
}
- cons-expr-ts.u.cl = gfc_get_charlen ();
+ cons-expr-ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL);
cons-expr-ts.u.cl-length_from_typespec = true;
cons-expr-ts.u.cl-length = gfc_copy_expr
(comp-ts.u.cl-length);
gfc_resolve_character_array_constructor (cons-expr);
I must be missing something here. What does cl2 do in the above
patch? You set it, but it is never used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45183
[Bug fortran/45183] [4.6 Regression] FAIL: gfortran.dg/derived_constructor_char_1.f90
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-04 18:13 --- I must be missing something here. What does cl2 do in the above patch? You set it, but it is never used. Nevermind, I understand what the code does. I can't even claim that I haven't had enough coffee this morning. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45183
[Bug fortran/45170] suspected bug in error generated by allocatable character array
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-03 02:31 --- This statement: character(:), allocatable :: io_message uses a deferred type parameter (a F2003 feature), which is not supported by gfortran at this time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
[Bug fortran/45092] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:5016
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-27 06:11 --- Here's an even shorter testcase. MODULE FunctionTypes IMPLICIT NONE integer, parameter :: OpconNameLength = 4 TYPE, PUBLIC :: TTermDefinition CHARACTER (OpconNameLength) :: termName(2) END TYPE TTermDefinition TYPE (TTermDefinition), PARAMETER :: e = TTermDefinition ([ , ]) end module FunctionTypes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45092
[Bug fortran/45092] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:5016
--- Comment #7 from kargl at gcc dot gnu dot org 2010-07-27 06:15 --- (In reply to comment #5) From the error location it looks like a duplicate of PR 44857. Yes, I think you're right. I've reduced it further in comment #6. The code compiles if the array constructor is changed. That is, this compiles MODULE FunctionTypes IMPLICIT NONE integer, parameter :: OpconNameLength = 4 TYPE, PUBLIC :: TTermDefinition CHARACTER (OpconNameLength) :: termName(2) END TYPE TTermDefinition TYPE (TTermDefinition), PARAMETER :: e = TTermDefinition ([, ]) end module FunctionTypes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45092
[Bug fortran/45092] internal compiler error regression bug in the latest trunk build of the gfortran compiler
--- Comment #3 from kargl at gcc dot gnu dot org 2010-07-27 04:53 --- Created an attachment (id=21323) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21323action=view) Reduced testcase Here's a reduced testcase. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Attachment #21322|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45092
[Bug fortran/45092] internal compiler error regression bug in the latest trunk build of the gfortran compiler
--- Comment #4 from kargl at gcc dot gnu dot org 2010-07-27 04:54 --- Reset severity to normal. Fortran bugs are rarely anything but normal. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45092
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #16 from kargl at gcc dot gnu dot org 2010-07-22 20:02 --- Created an attachment (id=21289) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21289action=view) Updated diff that handles intrinsics type The attached patch handles intrinsic types in match_type_spec better. It does not fix the issues found in the massive valgrind log. The handling of derive types is too opaque for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #17 from kargl at gcc dot gnu dot org 2010-07-22 20:03 --- Unassign myself. I don't have the smarts to trace through the derive type handling. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kargl at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #13 from kargl at gcc dot gnu dot org 2010-07-21 22:34 --- Subject: Bug 44929 Author: kargl Date: Wed Jul 21 22:34:07 2010 New Revision: 162386 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162386 Log: 2010-07-21 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * Revert my commit r162325 for this PR. Removed: trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_derived_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #14 from kargl at gcc dot gnu dot org 2010-07-21 22:47 --- Subject: Bug 44929 Author: kargl Date: Wed Jul 21 22:47:36 2010 New Revision: 162389 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162389 Log: 2010-07-21 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * Revert my commit r162326 for this PR. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/match.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_derived_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #15 from kargl at gcc dot gnu dot org 2010-07-21 22:49 --- Re-opening the bug. My previous patch has been reverted due to the problems outlined in PR fortran/45005. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/45005] gfortran.dg/allocate_with_typespec.f90 failed
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-21 22:50 --- I'm closing this PR as FIXED such that I reverted the patch that caused the problem and re-opened PR fortran/44929. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45005
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #10 from kargl at gcc dot gnu dot org 2010-07-20 04:01 --- Subject: Bug 44929 Author: kargl Date: Tue Jul 20 04:01:32 2010 New Revision: 162325 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162325 Log: 2010-07-19 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * gfortran.dg/allocate_with_typespec.f90: New test. * gfortran.dg/allocate_derived_1.f90: Update error message. 2010-07-19 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * fortran/match.c (match_type_spec): Check for derived type before intrinsic types. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_derived_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #11 from kargl at gcc dot gnu dot org 2010-07-20 05:39 --- Subject: Bug 44929 Author: kargl Date: Tue Jul 20 05:38:49 2010 New Revision: 162326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162326 Log: 2010-07-19 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * gfortran.dg/allocate_with_typespec.f90: New test. * gfortran.dg/allocate_derived_1.f90: Update error message. 2010-07-19 Steven G. Kargl ka...@gcc.gnu.org PR fortran/44929 * fortran/match.c (match_type_spec): Check for derived type before intrinsic types. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/match.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_derived_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #12 from kargl at gcc dot gnu dot org 2010-07-20 05:40 --- Fixed on 4,5 and trunk. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #11 from kargl at gcc dot gnu dot org 2010-07-16 14:48 --- (In reply to comment #10) (In reply to comment #9) (In reply to comment #6) Please don't keep reopening this bug. The symbols are weak undefs because libgfortran doesn't require (and shouldn't require) libpthread, it is thread-safe only when libpthread is linked in. After reviewing the thread (and recalling others along this line), Jakub, if you want to make the combination of -static -fopenmp a fatal error for gfortran, a patch is pre-approved. I am against it - if you properly link it, e.g. using -Wl,--whole-archive or with a POSIX Threads (pthread) library, which is linked with ld -r, it works. I don't see this in the information in the gfortran documentation. That's a similar issue to -m(no-)align-double: It leads to difficult to understand crashes, but it is nontrivial to diagnose properly as there are valid/working combinations - even though most combinations lead to crashes. Well, I would like to disable the use of -malign-double on gfortran as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44957] generic procedure name not included in symbol table
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-16 17:18 --- (In reply to comment #3) I've investigated further, and can reproduce it, but with one more condition that I didn't mention in the original bugreport. Basically, it happens when we have two modules, both defining a subroutine with the same name, where one happens to use the other (with a renaming). For example: The module m_dropdead defines an interface 'die'. The module m_die also defines an interface 'die'. So far, so good, and both compile fine. However the subroutines in m_die use the die interface from m_dropdead: use m_dropdead, only : ddie = die Not a problem so far. But then, when I attempt to compile other files that use m_die, the compiler gets confused. For example, when compiling m_IndexBin_char, we get to the line: use m_die, only : die and the compiler complains that m_die doesn't have a die routine. It looks like a compiler bug - somehow or other the remapping to ddie in m_die has messed up the symbol table beyond the scope of the subroutine it was used in. I'm attaching three files that demonstrate the bug. If you remove the line that's commented out in m_die, and run them through gfortran, you should see it trip up when compiling m_IndexBin_char What command line? With the renaming line uncommented, I see troutmask:sgk[209] gfc43 -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 troutmask:sgk[210] rm *.mod troutmask:sgk[211] gfc44 -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 troutmask:sgk[212] rm *.mod troutmask:sgk[213] gfc45 -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 troutmask:sgk[214] rm *.mod troutmask:sgk[215] gfc4x -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 BTW I'm running gcc 4.3.0 On Mac OS X 10.5.8. Ah, here the potential problem, Mac OS X is notorious for having problems that other OS's do not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44957
[Bug fortran/44957] generic procedure name not included in symbol table
--- Comment #9 from kargl at gcc dot gnu dot org 2010-07-16 18:45 --- (In reply to comment #8) Here's my command line, and the results: % gfortran -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90 m_IndexBin_char.F90:12.25: use m_die, only : die 1 Error: Symbol 'die' referenced at (1) not found in module 'm_die' m_IndexBin_char.F90:18.25: use m_die, only : die 1 Error: Symbol 'die' referenced at (1) not found in module 'm_die' % gfortran -v Using built-in specs. Target: i386-apple-darwin9.0.0 Configured with: ../gcc-4.3-20071026/configure --enable-languages=fortran Thread model: posix gcc version 4.3.0 20071026 (experimental) (GCC) In that case, I think you need to update to a newer version of gfortran. gfc43 in my comment #6 is gcc version 4.3.6 20100622 (prerelease) (GCC) BUt, if you go with an upgrade, I'll suggest 4.4.x or even 4.5.x. These versions of course have many more bug fixes than in the 4.3.x branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44957
[Bug fortran/44957] generic procedure name not included in symbol table
--- Comment #11 from kargl at gcc dot gnu dot org 2010-07-16 19:46 --- Closing as WONTFIX. With trunk being for active development and 4.4 and 4.5 under maintenance commits, I doubt anyone will find time to investigate this further. Thanks for the bug report. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44957
[Bug fortran/44957] generic procedure name not included in symbol table
--- Comment #1 from kargl at gcc dot gnu dot org 2010-07-15 17:48 --- (In reply to comment #0) When compiling a generic procedure, the generic name is not entered in the symbol table, which then causes subsequent 'use' statements to fail. Example: in m_die.F90 we declare: module m_die use m_mpif90, only : MP_perr implicit none private ! except public :: die ! signal an exception interface die; module procedure die0_, ! die(where) die1_, ! die(where,message) die2_, ! die(where,proc,ier) die4_ ! die(where,mesg1,ival1,mesg2,ival2) end interface etc... Which compiles fine. In other files we try: subroutine IndexBin1_(n,indx,keys,bins,lcs,lns) use m_die, only : die ...and the compiler complains: use m_die, only : die 1 Error: Symbol 'die' referenced at (1) not found in module 'm_die' A quick check of the symbol table confirms the actual procedures are there, but the generic name is missing: 09ba T ___m_die_MOD_die0_ 0953 T ___m_die_MOD_die1_ 08e5 T ___m_die_MOD_die2_ 0862 T ___m_die_MOD_die4_ but no 'die' There is insufficient code here to try to reproduce your problem. Please attach a small self-contained example. It may also be advantageous to update your version of gfortran to 4.4.4, 4.5.0, or trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44957
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #9 from kargl at gcc dot gnu dot org 2010-07-16 04:28 --- (In reply to comment #6) Please don't keep reopening this bug. The symbols are weak undefs because libgfortran doesn't require (and shouldn't require) libpthread, it is thread-safe only when libpthread is linked in. After reviewing the thread (and recalling others along this line), Jakub, if you want to make the combination of -static -fopenmp a fatal error for gfortran, a patch is pre-approved. Something like Index: options.c === --- options.c (revision 161930) +++ options.c (working copy) @@ -390,6 +390,9 @@ gfc_post_options (const char **pfilename if (pedantic gfc_option.flag_whole_file) gfc_option.flag_whole_file = 2; + if (gfc_option.flag_openmp THE_STATIC_FLAG) +gfc_fatal_error (Conflicting options -fopenmp and -static); + gfc_cpp_post_options (); /* FIXME: return gfc_cpp_preprocess_only (); where I could not find the right flag for THE_STATIC_FLAG. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug fortran/44934] [4.6 Regression] Bogus Missing format for FORMATTED data transfer
--- Comment #3 from kargl at gcc dot gnu dot org 2010-07-14 18:21 --- (In reply to comment #2) The original code has a line REWIND I04 after ENDFILE I04 I have removed it to reduce the test, but adding it does not change the runtime error. Also I doubt that the NIST suite contains invalid code. Apparently ENDFILE opens the file as formatted. Even with the rewind statement, the code may still be invalid. See 9.4.3 Connection of a file to a unit in F2003, and also see 9.7.2 ENDFILE statement. ENDFILE only operates on connected files. The unit number I04 in your example is not connected to a file at the point of execution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #5 from kargl at gcc dot gnu dot org 2010-07-13 20:35 --- Talking about (c): The following valid program is also rejected: real(8),allocatable :: r8 allocate( real(8) :: r8) end Hmm. Interesting. real(8),allocatable :: r8 allocate(real(kind=8) :: r8) end works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-13 20:41 --- (In reply to comment #1) Reported by Satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00152.html Is the original code invalid? A type is specified in several contexts by a type specifier. R401 type-spec is intrinsic-type-spec or derived-type-spec C401 (R401) The derived-type-spec shall not specify an abstract type (4.5.6). Satish extends an abstract type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #7 from kargl at gcc dot gnu dot org 2010-07-13 21:01 --- Created an attachment (id=21194) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21194action=view) patch for original problem Patch the fixed Satish's original problem. It simply checks for a derived type prior to an intrinsic type in the allocate statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'
--- Comment #9 from kargl at gcc dot gnu dot org 2010-07-13 22:20 --- I'm working on a patch, so I might as well take ownership of the PR. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-13 22:20:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929
[Bug fortran/44879] MOVE_ALLOC rejects FROM= which is a function result
--- Comment #2 from kargl at gcc dot gnu dot org 2010-07-09 06:02 --- Is there a testsuite program to check this? Perhaps, your code should be added so the correct behavior doesn't get unfixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44879
[Bug testsuite/44797] INQUIRE EXIST variable must be default LOGICAL
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-08 18:07 --- (In reply to comment #5) Subject: Re: INQUIRE EXIST variable must be default LOGICAL By the way, the NUMBER variable must be default INTEGER as well. Do you agree there is the same problem as with the EXIST variable? Vittorio Yes. I suspect that gfortran accepts any kind type as an extension when a default kind is required by the standard. I suppose at some point someone should audit gfortran. Note, that F2008 has lifted this restriction in all(?) (or most) cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44797
[Bug testsuite/44797] INQUIRE EXIST variable must be default LOGICAL
--- Comment #4 from kargl at gcc dot gnu dot org 2010-07-05 20:24 --- Closing as fix. The default behavior of gfortran is to accept any logical kind supported by gfortran. If either -std=f95 or -std=f2003 is given on the command line, gfortran will issue an error. Vittorio thanks for the bug report. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44797
[Bug testsuite/44797] INQUIRE EXIST variable must be default LOGICAL
--- Comment #2 from kargl at gcc dot gnu dot org 2010-07-04 06:07 --- A patch has been posted here http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00291.html laptop:kargl[208] gfc4x -o z -std=f2003 inquire_5.f90 inquire_5.f90:22.59: inquire (file = 'inquire_5.txt', number = unit8, exist = exist8) 1 Error: default LOGICAL required in EXIST tag at (1) inquire_5.f90:26.59: inquire (file = 'inquire_5.txt', number = unit2, exist = exist2) 1 Error: default LOGICAL required in EXIST tag at (1) inquire_5.f90:28.59: inquire (file = 'inquire_5.txt', number = unit1, exist = exist1) 1 Error: default LOGICAL required in EXIST tag at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44797
[Bug testsuite/44799] MAX arguments should have same kind
--- Comment #1 from kargl at gcc dot gnu dot org 2010-07-03 15:58 --- It's an extension. laptop:kargl[231] gfc4x -o z -std=f95 intrinsic_minmax.f90 intrinsic_minmax.f90:26.17: if (max (4d0, r) .ne. 4d0) call abort 1 Error: Extension: Different type kinds at (1) -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44799
[Bug testsuite/44797] INQUIRE EXIST variable must be default LOGICAL
--- Comment #1 from kargl at gcc dot gnu dot org 2010-07-03 16:04 --- I believe that this is an intended extension. However, laptop:kargl[238] gfc4x -o z -std=f95 -fall-intrinsics inquire_5.f90 laptop:kargl[239] ./z Thus, an error should have been emitted when enforcing f95 or f2003. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-03 16:04:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44797
[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()
--- Comment #7 from kargl at gcc dot gnu dot org 2010-06-25 06:14 --- (In reply to comment #5) Subject: Re: [regression 4.4/4.5/4.6] ICE in resolve_equivalence() On Thu, Jun 24, 2010 at 23:02, kargl at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: Comment #1 from kargl at gcc dot gnu dot org 2010-06-25 04:02 --- Index: resolve.c === --- resolve.c (revision 161047) +++ resolve.c (working copy) @@ -12506,6 +12506,9 @@ resolve_equivalence (gfc_equiv *eq) This patch doesn't fix the problem I am seeing. If I'm testing this in the loop before taking the value of e-symtree-n.sym-ts, then it passes without ICE: We'll need another test case then. However, I note that... diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c index 48bb618..7f66be4 100644 --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -12360,6 +12360,9 @@ resolve_equivalence (gfc_equiv *eq) ... there is a 200 line difference in the location of your diff and my clean trunk. Do you have other changes in your source code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()
--- Comment #10 from kargl at gcc dot gnu dot org 2010-06-25 06:29 --- (In reply to comment #6) Subject: Re: [regression 4.4/4.5/4.6] ICE in resolve_equivalence() These previous patches don't seem to solve the problem: here is another reduced case that still fails in resolve_equivalence at a different place than before. $ cat bug.f CALL TRFWTM(JKT,XX,NX,Y,NIX,NORB2,1,TOL) IF(DBUG.AND.NX.GT.0) THEN EQUIVALENCE (DBUGME, DBUGME_STR) END IF END What language is GAMESS written in? The above simply is not Fortran. EQUIVALENCE is a specification-statement. It cannot appear after an executable-statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()
--- Comment #14 from kargl at gcc dot gnu dot org 2010-06-25 17:14 --- (In reply to comment #11) Well, it is invalid code - based on a valid Fortran code. If you use Delta to reduce a test case (cf. http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction), it simply removes lines of the source code using a constraint. I think Sebastian's constraint was that it segfaults. This seemingly happens for the unmodified gamess due to a Graphite bug - but also due to a buggy error recovery in gfortran. Well, then Delta is broken for fortran. Reducing valid fortran that is causing a compiler issue to some invalid fortran fragment that may or (more than likely) may not have anything to do with the original issue is a waste of time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-25 04:02 --- Index: resolve.c === --- resolve.c (revision 161047) +++ resolve.c (working copy) @@ -12506,6 +12506,9 @@ resolve_equivalence (gfc_equiv *eq) int object, cnt_protected; const char *msg; + if (eq-expr-symtree-n.sym == NULL) +return; + last_ts = eq-expr-symtree-n.sym-ts; first_sym = eq-expr-symtree-n.sym; -- kargl at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.5 4.5.1 4.6.0 Known to work||4.3.6 Summary|ICE in resolve_equivalence()|[regression 4.4/4.5/4.6] ICE ||in resolve_equivalence() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
[Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()
--- Comment #3 from kargl at gcc dot gnu dot org 2010-06-25 04:42 --- (In reply to comment #2) Confirmed. I came up with the exact same patch and it does pass regression testing, of course. Collided when I tried to post this. :) :) The mangled Fortran code caught my eye. I'm actually wondering where Sebastian found this gem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #8 from kargl at gcc dot gnu dot org 2010-06-20 16:41 --- (In reply to comment #7) The following occurs in the snapshot of June 19, but not in earlier snapshots: mrich...@msc545ux:~$ cat test.f90 PROGRAM test END FILE 10 END FILE 10 END PROGRAM test mrich...@msc545ux:~$ gfortran test.f90 mrich...@msc545ux:~$ ./a.out At line 3 of file test.f90 (unit = 10, file = 'fort.10') Fortran runtime error: Cannot perform ENDFILE on a file already positioned after the EOF marker Did you read the error message? The code is invalid. For the Fortran 95 standard: After execution of an ENDFILE statement, a BACKSPACE or REWIND statement shall be used to reposition the file prior to execution of any data transfer input/output statement or ENDFILE statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44595] New: SIZE in RANDOM_SEED is an intent(out) variable.
gfortran compiles the following code subroutine reset_seed(iseed) implicit none integer, intent(in) :: iseed call random_seed(iseed) end subroutine reset_seed SIZE (optional) shall be scalar and of type default integer. It is an INTENT (OUT) argument. It is assigned the number N of integers that the processor uses to hold the value of the seed. The problem is in check_variable() in check.c. The first if-statement prevents the second one from being reached. -- Summary: SIZE in RANDOM_SEED is an intent(out) variable. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: kargl at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44595
[Bug fortran/44595] INTENT of argeuments to intrinsics procedure not check
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-20 03:53 --- Update the summary. AFAICT, for intrinsics procedure that specify an INTENT for its arguments, the INTENT isn't checked. Sigh. This is opening a can of worms. More later. :( -- kargl at gcc dot gnu dot org changed: What|Removed |Added Summary|SIZE in RANDOM_SEED is an |INTENT of argeuments to |intent(out) variable. |intrinsics procedure not ||check http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44595
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #3 from kargl at gcc dot gnu dot org 2010-06-18 18:49 --- (In reply to comment #2) it should be 0.0 always, NOT to be chaotic number like C, because when ddx is declared, it has to be initialized to 0.0 by fortran standard. Can you point the language in the Fortran Standard that supports your claim? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-18 19:10 --- (In reply to comment #4) O.K. I doublechecked the standard. The array declared does not need to be initialized in this case. So the return value could be any number. However, this kind of implementation should fail in a certian case. I am trying to write a small example to prove this. I will post it later. Well, actually the array needs to be initialized, but not by the compiler. It is the responsibility of the programmer to initialize his/her variables. Techincally, your function is invalid because function ddx(array) implicit double precision (a-h,o-z) double precision:: array(:,:) double precision:: ddx(size(array,dim=1),size(array,dim=2)) print *, ddx(1,1) end function ddx the print statement references an undefined variable. See section 16.5.1: (1) An array is defined if and only if all of its elements are defined. A careful reading of 16.5 might be useful. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/44556] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-17 15:22 --- Remove [4.5/4.6 Regression] from the summary as this has never worked, so it can't be a regression. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5/4.6 Regression]|incorrect error: Stat- |incorrect error: Stat- |variable at (1) shall not be |variable at (1) shall not be|DEALLOCATEd within the same |DEALLOCATEd within the same |DEALLOCATE statement |DEALLOCATE statement| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556
[Bug fortran/44556] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement
--- Comment #6 from kargl at gcc dot gnu dot org 2010-06-17 15:26 --- (In reply to comment #5) Remove [4.5/4.6 Regression] from the summary as this has never worked, so it can't be a regression. Note, the OP's code appears to work in 4.4.0 because prior to the commit noted in comment #4 there was no checking on the constraints listed in the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556
[Bug fortran/44556] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement
--- Comment #7 from kargl at gcc dot gnu dot org 2010-06-17 19:08 --- The following patch restores the 4.4.0 behavior for STAT of not checking derived type components. This of course now allows invalid code to compile such as this modified version of OP's test subroutine subroutine test type(test_type) :: foo deallocate(foo%array, stat=foo%array(1)) end subroutine test Index: resolve.c === --- resolve.c (revision 160935) +++ resolve.c (working copy) @@ -6588,7 +6588,8 @@ resolve_allocate_deallocate (gfc_code *c variable, stat-where); for (p = code-ext.alloc.list; p; p = p-next) - if (p-expr-symtree-n.sym-name == stat-symtree-n.sym-name) + if (stat-symtree-n.sym-ts.type != BT_DERIVED +p-expr-symtree-n.sym-name == stat-symtree-n.sym-name) gfc_error (Stat-variable at %L shall not be %sd within the same %s statement, stat-where, fcn, fcn); } @@ -6617,7 +6618,8 @@ resolve_allocate_deallocate (gfc_code *c variable, errmsg-where); for (p = code-ext.alloc.list; p; p = p-next) - if (p-expr-symtree-n.sym-name == errmsg-symtree-n.sym-name) + if (errmsg-symtree-n.sym-ts.type != BT_DERIVED +p-expr-symtree-n.sym-name == errmsg-symtree-n.sym-name) gfc_error (Errmsg-variable at %L shall not be %sd within the same %s statement, errmsg-where, fcn, fcn); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556
[Bug fortran/44556] [4.5/4.6 Regression] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement
--- Comment #2 from kargl at gcc dot gnu dot org 2010-06-16 14:34 --- (In reply to comment #1) The following check is to simplistic, it does not work for structures but only for simple object names. - with structures, it gets more complicated as also comparing the name of the last part-ref won't work - but one needs to walk through the whole structure references. Not sure how I got added to the CC list. Remove myself. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC|kargl at gcc dot gnu dot org| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556
[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #6 from kargl at gcc dot gnu dot org 2010-06-16 21:51 --- (In reply to comment #5) This makes no sense at all. Rainer, I'm really sorry if it seems that I'm shooting questions a bit at random, but I have a hard time imagining how to narrow it down. Can you try the following equivalent C code (at -O0): (Code) Right now, the only thing I can see make sense is numerically instability in the libm. Also, how are atan2f and atan2 defined in the system's math.h header? Do they have simple prototypes? Are they actually macros? Does -ffloat-store change the outcome? This looks to possibly be an excess precision problem and the difference between something in a register and main memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
[Bug tree-optimization/43924] [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)
--- Comment #12 from kargl at gcc dot gnu dot org 2010-06-17 04:43 --- (In reply to comment #11) Disappeared for cris-elf in (160828:r160836], which agrees i686-linux results on gcc100 at http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01649.html (160820) and http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01712.html (160836). A deliberate fix (perhaps as a side-effect of fixing PR43905) or just accidental cover-up? I see the same thing with i686-*-freebsd. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43924
[Bug tree-optimization/43924] [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)
--- Comment #13 from kargl at gcc dot gnu dot org 2010-06-17 05:08 --- (In reply to comment #12) (In reply to comment #11) Disappeared for cris-elf in (160828:r160836], which agrees i686-linux results on gcc100 at http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01649.html (160820) and http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01712.html (160836). A deliberate fix (perhaps as a side-effect of fixing PR43905) or just accidental cover-up? I see the same thing with i686-*-freebsd. REverting the patch for 43905 with svn merge -r 160832:160831 . indeed shows that the ICE returns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43924
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- Comment #2 from kargl at gcc dot gnu dot org 2010-06-11 18:12 --- Reset several to 'normal'. Fortran bugs are never 'major'. I believe your code is invalid, and so gfortran can do anything it wants. F2003 has 19 6.3.3.2 Deallocation of pointer targets If a pointer appears in a DEALLOCATE statement, its association status shall be defined. Deallocating a pointer that is disassociated or whose target was not created by an ALLOCATE statement causes an error condition in the DEALLOCATE statement. If a pointer is associated with an allocatable entity, the pointer shall not be deallocated. If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an object that was created by allocation. Deallocating a pointer target causes the pointer association status of any other pointer that is associated with the target or a portion of the target to become undefined. Your statement deallocate (p1, stat=ios) causes p2 to become undefined. Thus, your statement deallocate (p2, stat=ios) violates the first sentence in this section. Of course, I could be wrong. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug fortran/44489] Transfer with boz constant can confuse - add documentation
--- Comment #4 from kargl at gcc dot gnu dot org 2010-06-10 06:31 --- (In reply to comment #3) The result of transfer is largest kind of decimal. Can be kind=8 or kind=16 depending on the system. Maybe we should add some documentation in the manual on this. Thanks Steve for pointing this out. Well, to be more exact, the result of transfer() has the type of its 2nd argument. In transfer(ii8,z'1000'), the BOZ may have a kind type parameter of 8 or 16 depending on the target; while the INTEGER(4) ii8 can only supply 32 bits. Note, the documentation for transfer() already describes this situation without explicitly mentioning BOZ literal constants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489
[Bug fortran/44497] [4.6 Regression] gfortran.dg/maxlocval_2.f90
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-10 22:37 --- This is a context free PR. Please provide details. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|[4.6 Regression]|[4.6 Regression] |gfortran.dg/maxlocval_2.f90 |gfortran.dg/maxlocval_2.f90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44497
[Bug fortran/44346] gfortran accepts illegal arguments to intrinsics
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-09 16:39 --- Patch has been committed to 4.4, 4.5, and trunk. Closing. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
[Bug fortran/44489] Transfer with boz constant gives wrong results
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-10 04:24 --- This is probably a bogus PR. The BOZ literal constants are INTEGER(16) entities (at least of x86_64). ii8 is an INTEGER(4) item. The transfer() in the print statement is returning a INTEGER(16) entity where only INTEGER(4) worth of bits are set. I've removed the 'wrong-code' keyword, because I think you are getting processor dependent behavior. In fact, the program might be nonconforming, but I'd need to read up on transfer(). -- kargl at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489
[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-02 00:42 ---
The problem is caused by gfc_match_stopcode().
if (gfc_match_eos () != MATCH_YES)
{
m = gfc_match_init_expr (e);
if (m == MATCH_ERROR)
goto cleanup;
if (m == MATCH_NO)
goto syntax;
}
#if 0
if (gfc_match_eos () != MATCH_YES)
goto syntax;
#endif
If the first gfc_match_eos () does not match an end-of-statement,
gfortran immediate calls gfc_match_eos () again. With the #if 0
above the code in comment #1 compiles and executes. So, why is
there a 2nd call to gfc_match_eos().
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
CC||sgk at troutmask dot apl dot
||washington dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44371
[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code
--- Comment #3 from kargl at gcc dot gnu dot org 2010-06-02 02:03 ---
Here's a dejagnu testcase.
! { dg-do run }
character(1) c, y
y = 'y'
read(y,*) c
if (c=='y') stop; if (c=='Y') stop
call abort()
end
The 'dg-do run' could be changed to 'dg-do compile'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44371
[Bug fortran/44346] gfortran accepts illegal arguments to intrinsics
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-31 16:29 --- Thanks for the bug report. Technically, the prohibition of nonnegative is on the programmer, and as such the code is illegal. gfortran can do anything it wants with the program including starting world war iii. OTOH, this appears to be a quality-of-implementation issue, and if gfortran can diagnosis the problem, and error should be emitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
[Bug fortran/44346] gfortran accepts illegal arguments to intrinsics
--- Comment #2 from kargl at gcc dot gnu dot org 2010-05-31 17:22 --- I have a patch for the IBITS() portion of the problem. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-31 17:22:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
[Bug fortran/44346] gfortran accepts illegal arguments to intrinsics
--- Comment #3 from kargl at gcc dot gnu dot org 2010-05-31 17:51 --- I have a complete patch with the mvbits checking done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
[Bug fortran/44354] incorrect output at run time
--- Comment #4 from kargl at gcc dot gnu dot org 2010-05-31 18:33 --- (In reply to comment #2) Note that fortran is case insensitive, ... Indeed, but I think the implied do loop should still go from 1 to 5. Note that if I print 'i' after the loop I get 5. Of course it prints 5. The 'i' in the do-loop has the scope of the implied-do-loop. The 'I' in the program has the scope of the program. laptop:kargl[247] cat ui.f90 integer j(4) I=5 j = 42 j = (/(i,i=1,I-1)/) print '(A,I0,A,4(I0,1X))', 'I = ', I, ' j = ', j end laptop:kargl[248] gfc4x -o z -fdump-tree-original ui.f90 laptop:kargl[249] ./z I = 5 j = 0 134516008 0 0 The question becomes whether the 'I' in the implied-do-loop is being used uninitialized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44354] incorrect output at run time
--- Comment #6 from kargl at gcc dot gnu dot org 2010-05-31 20:02 --- (In reply to comment #5) The question becomes whether the 'I' in the implied-do-loop is being used uninitialized. From comment #3, I think the 'i' in i,i= should not be the same as the 'i' in =1,i. Well, it still comes back to scope. The implied-do-loop is different from integer j(5) I=5 j = 42 do i = 1, I j(i) = i end do print '(A,I0,A,5(I0,1X))', 'I = ', I, ' j = ', j end because in the above 'i' and 'I' are in the same scoping unit. If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in a different scoping unit. I agree that the scalar-int-expr '1' and 'I' need to be evaluated to establish the the loop start and stop values. The question again based on scoping unit is whether 'I' is uninitialized. Confirmed. However, having this in real world codes seems like the best way to confuse people. Agreed!-) I am always baffled by the users' talent to make their life miserable. Nevertheless the compiler should follow the standard, i.e., from my understanding of the construct, print the 1 to 5 sequence. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44354] incorrect output at run time
--- Comment #11 from kargl at gcc dot gnu dot org 2010-05-31 21:54 --- (In reply to comment #7) (In reply to comment #6) because in the above 'i' and 'I' are in the same scoping unit. I couldn't find what mandates in the standard that i and I are in a different scoping unit/are different variables. Are they ? If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in a different scoping unit. I agree that the scalar-int-expr '1' and 'I' need to be evaluated to establish the the loop start and stop values. The question again based on scoping unit is whether 'I' is uninitialized. How could it be ? I don't understand what you are asking. integer j(5) I = 5 j = (/ (i,i=1,I) /) ! (i,i=m1,m2) for discussion below end 'I' in line 2 is in the scope of the main program. 'i' in line 3 is in the scope of the implied-do-loop. 'I' in line 2 is not the same as 'i' in line 3. The only thing that 'i' in line 3 gets from 'I' in line 2 is its type and kind type parameter. When 'i' in line 3 comes into scope, does 'I' in the m2 become undefined? I can't find anything in the standard that states that it becomes undefined and I can't find anywhere that states that it is still defined to have a value of 5 in the evaluation of m2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44345] ICE in fold_convert_loc
--- Comment #3 from kargl at gcc dot gnu dot org 2010-05-31 22:20 --- Interestingly, if one does not use implicit type, one finds that the following compiles: integer, pointer :: p integer, target :: q q(i)=i p=q(110) print *,p end and integer, pointer :: p integer, target :: q integer i q(i)=i p=q(110) print *,p end and real, pointer :: p real, target :: q real i q(i)=i p=q(110.) print *,p end Finally, this one does not compile real, pointer :: p real, target :: q integer i q(i)=i p=q(110) print *,p end laptop:kargl[218] gfc4x -o z t.f90 ./z t.f90: In function 'MAIN__': t.f90:5:0: internal compiler error: in fold_convert_loc, at fold-const.c:1920 Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44345
[Bug fortran/44354] incorrect output at run time
--- Comment #12 from kargl at gcc dot gnu dot org 2010-05-31 22:47 --- (In reply to comment #8) Created an attachment (id=20787) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20787action=view) [edit] draft patch This makes loop bounds evaluation before the internal variable substitution. BTW, I believe your patch is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
