[Bug fortran/45756] New: Multiple DECL for array valued PARAMETER (-fwhole-file issue)
Currently, gfc_get_symbol_decl only deals with -fwhole-file issues of module variable (FL_VARIABLE( but not with array-valued (or non-intrinsic-type) parameters (FL_PARAMETER). Thus, for the following program, multiple UIDs will be generated for the program below: module m integer, parameter :: para(3) = [1, 2, 3] end module m subroutine one use m i = para(1) end subroutine one subroutine two use m j = para(1) end subroutine two -fdump-tree-original-uid shows: extern integer(kind=4)D.8 paraD.1556[3]; extern integer(kind=4)D.8 paraD.1561[3]; -- Summary: Multiple DECL for array valued PARAMETER (-fwhole-file issue) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45756
[Bug fortran/45756] Multiple DECL for array valued PARAMETER (-fwhole-file issue)
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-23 09:59 --- Note: The implementation should honour PR 40571, i.e. array parameters from intrinsic modules, which do not exist as .o file. My current idea is to generate them per use association as local static variable - which would break if uses gsym for them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45756
[Bug fortran/45757] New: Accepts invalid: SHAPE with scalar
I have *not* checked the standard (F2008), but I think the following is invalid as a is not an array but a scalar. gfortran accepts it but does not print any value. integer :: a(3) print *, shape(a(1)) end -- Summary: Accepts invalid: SHAPE with scalar 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: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45757
[Bug fortran/45757] Accepts invalid: SHAPE with scalar
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-23 11:44 --- Mikael, thanks for checking! Close as INVALID. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45757
[Bug fortran/45745] [4.6 Regression] ICE in gfc_conv_array_stride
--- Comment #7 from burnus at gcc dot gnu dot org 2010-09-23 13:23 --- Can the PR be closed? Or is something still missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45745
[Bug fortran/45744] [4.6 Regression] ICE with -O1 in gfc_conv_expr_op, at fortran/trans-expr.c:1366
--- Comment #4 from burnus at gcc dot gnu dot org 2010-09-22 07:45 --- (In reply to comment #3) Confirmed as a regression: The assert is in gfc_conv_expr_op: gcc_assert (expr-value.op.op1-ts.type == expr-value.op.op2-ts.type); For mask = (rnd(parsize) popcross) the OP is INTRINSIC_LT and both op1 and op2 are BT_REAL; however, with -O1, op1 is BT_LOGICAL. If one disables frontend-passes.c by adding a return to gfc_run_passes, it works. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.6.0 Known to work||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-09-22 07:45:44 date|| Summary|internal compiler error: in |[4.6 Regression] ICE with - |gfc_conv_expr_op, at|O1 in gfc_conv_expr_op, at |fortran/trans-expr.c:1366 |fortran/trans-expr.c:1366 Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45744
[Bug fortran/45745] [4.6 Regression] ICE in gfc_conv_array_stride
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-22 08:24 --- Works Rev. 164472 Fails Rev. 164509 (ICE) Mikael, I think your patch could be the culprit (Rev. 164494, PR 45648). -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||mikael at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-22 08:24:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45745
[Bug fortran/45746] [OOP] ICE in fold_convert_loc: pointer to allocatable array with select type
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-22 08:35 --- Fails in gfc_trans_scalar_assign for the line: gfc_add_modify (block, lse-expr, fold_convert (TREE_TYPE (lse-expr), rse-expr)); as switch (TREE_CODE (type)) in fold_convert reaches gcc_unreachable. Hereby, (gdb) p lse-expr-common.type-base-code $1 = RECORD_TYPE (gdb) p rse-expr-common.type-base-code $2 = RECORD_TYPE And both types are different, cf. (gdb) p rse-expr-common.type $4 = (tree) 0x2d533e70 (gdb) p lse-expr-common.type $5 = (tree) 0x2d538000 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45746
[Bug fortran/45748] [4.5/4.6 Regression] -fimplicit-none failures when using intrinsic MAX
--- Comment #4 from burnus at gcc dot gnu dot org 2010-09-22 20:22 --- As you might have guessed, the error is with regards to the arguments of MAX which are A1 and A2. The arguments are defined as BT_UNKNOWN, cf. in intrinsics.c: add_sym_1m (max, GFC_ISYM_MAX, CLASS_ELEMENTAL, ACTUAL_NO, BT_UNKNOWN, 0, GFC_STD_F77, gfc_check_min_max, gfc_simplify_max, gfc_resolve_max, a1, BT_UNKNOWN, dr, REQUIRED, a2, BT_UNKNOWN, dr, REQUIRED); The backtrace shows: #0 gfc_set_default_type (sym=0x144e6b0, error_flag=1, ns=value optimized out) at fortran/symbol.c:263 #1 0x005328d7 in resolve_formal_arglist (proc=0x144d1f0) at fortran/resolve.c:303 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||4.5.0 4.6.0 Known to work||4.4.0 Last reconfirmed|-00-00 00:00:00 |2010-09-22 20:22:16 date|| Summary|-fimplicit-none strange |[4.5/4.6 Regression] - |behaviour |fimplicit-none failures when ||using intrinsic MAX Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45748
[Bug fortran/45715] [ABI cleanup] Move runtime parsing of I/O control list to front end
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-21 06:54 --- (In reply to comment #1) Here is a case where we do have to evaluate at run time. So maybe we can not do what is proposed above. Well, I understood the request such that one passes a boolean for the 'YES' / 'NO' items. If it cannot be simplified at compile time, one adds (in trans*c) code like: advance = _gfortran_compare_string (3, YES, len, str) == 0; Possibly, one should add a new function like advance = _gfortran_io_yes_no (len, str, ADVANCE); which takes then also into account invalid values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45715
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #15 from burnus at gcc dot gnu dot org 2010-09-21 09:20 --- Any idea what could be done from the gfortran side? Without being able to reproduce it, it is a bit difficult to debug :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug fortran/45319] [4.5 Regression] FAIL: libgomp.fortran/vla4.f90
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-21 09:28 --- (In reply to comment #1) Similar fails: FAIL: libgomp.fortran/vla5.f90 -O0 (test for warnings, line 69) FAIL: libgomp.fortran/vla5.f90 -O0 (test for excess errors) Excess errors: libgomp.fortran/vla5.f90:68:0: warning: barrier region may not be closely nested inside of work-sharing, critical, ordered, master or explicit task region That is: The warning is in line 68 instead of 69. Does this still occur? I could imagine that the input-location fixes solved this issue, but maybe it didn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45319
[Bug fortran/45740] New: PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code
From Fortran 2008: C549 An entity with the PROTECTED attribute shall be a procedure pointer or variable. C551 A nonpointer object that has the PROTECTED attribute and is accessed by use association shall not appear in a variable definition context (16.6.7) or as the data-target or proc-target in a pointer-assignment-stmt. C552 A pointer that has the PROTECTED attribute and is accessed by use association shall not appear in a pointer association context (16.6.8). module m procedure(), pointer :: p, p2 protected :: p end module m subroutine one use m procedure(), pointer :: ptr1 = p ! Invalid end subroutine one subroutine two use m procedure(), pointer :: ptr2 ptr2 = p ! Invalid end subroutine two subroutine three use m procedure(), pointer :: ptr3 = p2 ! Valid call ptr3() ! ICE, related to PR 45290 ! internal compiler error: in record_reference, at cgraphbuild.c:60 end subroutine three -- Summary: PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740
[Bug fortran/45290] [F08] pointer initialization
--- Comment #9 from burnus at gcc dot gnu dot org 2010-09-21 12:37 --- Another issue besides comment 5 is the following program (from PR 45740), which gives an ICE. Actually, I am not quite sure the example is valid as p2's target is not known at compile time. module m procedure(), pointer :: p2 end module m use m procedure(), pointer :: ptr3 = p2 call ptr3() ! ICE, related to PR 45290 ! internal compiler error: in record_reference, at cgraphbuild.c:60 end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug fortran/45740] PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-21 13:47 --- TODO: Check whether the code is really invalid - C551 talks only about nonpointers, but it also talks about proc-target - which only applies to procedures and the PROTECTED only applies per C549 to variables and procedure pointers. Re-reading F2008's 4.5.4.6 Default initialization for components and R505 and following, the procedure(), pointer :: ptr3 = p2 ! Valid is invalid as p2 does not have the target attribute. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-valid-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740
[Bug fortran/45290] [F08] pointer initialization
--- Comment #10 from burnus at gcc dot gnu dot org 2010-09-21 13:52 --- (In reply to comment #9) procedure(), pointer :: ptr3 = p2 I now believe that this is invalid (all quotes are F2008): R505 initialization is [...] or = initial-data-target R443 initial-data-target is designator C461 (R443) The designator shall designate a nonallocatable variable that has the TARGET and SAVE attributes and does not have a vector subscript. Every subscript, section subscript, substring starting point, and substring ending point in designator shall be a constant expression. Well, in the example (cf. also the ICE in comment 5) p2 is a POINTER and a pointer cannot have the TARGET attribute (cf. C556). Thus, the initial-data-target can neither be a pointer nor a proc-pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug fortran/45740] PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-21 14:19 --- (In reply to comment #1) TODO: Check whether the code is really invalid I have now asked at J3, cf. http://j3-fortran.org/pipermail/j3/2010-September/thread.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740
[Bug fortran/45710] WRITE of NAMELIST group to internal file contains newline characters
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-20 07:56 --- (In reply to comment #0) In gfortran a WRITE of a NAMELIST group into an internal file appears to all go into the first record. [...] only major complaint with that is that I first guessed that your output into an internal file would be formatted just like it was to stdout. But gfortran output to stdout or to a file writes in a very different format, putting one keyword=value per line (which I like, but is also not required by any standard requirement I can find). If you use a scalar string, there is only a single record - thus gfortran has no choice then using only one record. You could instead use a character array, e.g. character(30) :: str(6) integer :: a, b, c, d namelist /nml/ a,b,c,d str = '' write(str,nml=nml) write(*,'(a)')str end From the F2008 standard: If the file is a scalar character variable, it consists of a single record whose length is the same as the length of the scalar character variable. If the file is a character array, it is treated as a sequence of character array elements. Each array element, if any, is a record of the file. (In reply to comment #4) This issue, line ending for namelist to character arrays, has come up before. I don't remember the outcome of that previous discussion. I will research a little. Well, in gfortran character arrays seem to do what urbanjost would like to have: A new record for each namelist element. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #26 from burnus at gcc dot gnu dot org 2010-09-16 21:30 --- Subject: Bug 43665 Author: burnus Date: Thu Sep 16 21:30:05 2010 New Revision: 164348 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164348 Log: 2010-09-16 Tobias Burnus bur...@net-b.de PR fortran/43665 * trans-types.c (create_fn_spec): New function. (gfc_get_function_type): Call it. 2010-09-16 Tobias Burnus bur...@net-b.de PR fortran/43665 * gfortran.dg/cray_pointers_2.f90: Disable inlining to avoid optimizations. * gfortran.dg/intent_optimize_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intent_optimize_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/cray_pointers_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug fortran/42359] ICEs with specification function and init expression
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-12 09:25 --- (In reply to comment #1) (ii) An automatic array cannot have an initialization expression. I disagree: Initialization expressions should be allowed (= compile-time constant) - but specification expressions not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42359
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #24 from burnus at gcc dot gnu dot org 2010-09-12 09:32 --- (In reply to comment #23) I have applied the patch in comment #21 without regression, but the test case from attachment 21265 [edit] fails: - create_fn_spec (sym, type); + type = create_fn_spec (sym, type); as in the original patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #19 from burnus at gcc dot gnu dot org 2010-09-10 06:02 --- Subject: Bug 45186 Author: burnus Date: Fri Sep 10 06:01:50 2010 New Revision: 164143 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164143 Log: 2010-09-10 Tobias Burnus bur...@net-b.de PR fortran/45186 * trans.h (build1_stat_loc, build2_stat_loc, build3_stat_loc, build4_stat_loc): New inline functions. (build1_loc, build2_loc, build3_loc, build4_loc): New macros. (build1_v, build2_v, build3_v, build4_v): Use input_location as locus. * trans-array.c (gfc_trans_scalarized_loop_end, gfc_conv_array_parameter): Replace build[1-4] by build[1-4]_loc. * trans.c (gfc_build_addr_expr, gfc_build_array_ref, gfc_finish_wrapped_block): Ditto. * trans-decl.c (gfc_init_default_dt, init_intent_out_dt): Ditto. * trans-expr.c (gfc_conv_missing_dummy, gfc_trans_alloc_subarray_assign, gfc_trans_zero_assign): Ditto. * trans-openmp.c (gfc_omp_clause_default_ctor, gfc_trans_omp_critical, gfc_trans_omp_parallel, gfc_trans_omp_parallel_do, gfc_trans_omp_parallel_sections, gfc_trans_omp_parallel_workshare, gfc_trans_omp_sections gfc_trans_omp_single, gfc_trans_omp_task, gfc_trans_omp_workshare): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #21 from burnus at gcc dot gnu dot org 2010-09-10 07:25 --- (In reply to comment #20) many thanks for working on this... I mentioned this before in the PR, but it would be very good if some line number testcases were added to the regression tests. I concur - with -dump-tree-original-lineno this should be possible. If there would be some semi-automatic way of checking the lineno quality (such as e.g. in the original dump line numbers should always increase??) No! As the example in comment 18 shows the line numbers should not always monotonically increase. Or at least I expect the i = i + 1 to be associated with the line do i = 1, 10 rather than with the line a(i) = b(i) as the gfortran currently does. If you disagree, I can simply close this PR as fixed ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45629] New: libgfortran/io/list_read.c:1872:10: warning: variable 'elem' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]
At least on MinGW64 (as reported by nightstrike), the following warning is
printed when compiling libgfortran:
libgfortran/io/list_read.c:1872:10: warning: variable 'elem' might be clobbered
by 'longjmp' or 'vfork' [-Wclobbered]
If one looks at the source, one sees:
1869 list_formatted_read (st_parameter_dt *dtp, bt type, void *p, int kind,
1870 size_t size, size_t nelems)
1871 {
1872size_t elem;
[...]
1880for (elem = 0; elem nelems; elem++)
1881 {
1882dtp-u.p.item_count++;
1883list_formatted_read_scalar (dtp, type, tmp + stride*elem, kind,
size);
with
1704 list_formatted_read_scalar (st_parameter_dt *dtp, volatile bt type,
void *p,
1710jmp_buf eof_jump;
However, I do not see how elem itself gets clobbered - thus the warning looks
bogus to me, but I have only glanced at the code.
--
Summary: libgfortran/io/list_read.c:1872:10: warning: variable
'elem' might be clobbered by 'longjmp' or 'vfork' [-
Wclobbered]
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45629
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6
--- Comment #43 from burnus at gcc dot gnu dot org 2010-09-10 10:29 --- The attachment is not viewable in your browser due to security restrictions enabled by Bugzilla. In order to view the attachment, you first have to download it. I think at least text/* attachments should be shown. I think the restriction is to avoid problems with, e.g., HTML attachments, which can steal cookies. Thus some sites (like bugzilla.mozilla.org) use a different (sub)domain for the attachments. (A different subdomain would be fine for me as well - as would be HTTPS [at least for the login] but I think that's an item for overseers.) In any case, I would like to see the possibility to view patches and examples w/o downloading. Example: http://gcc.gnu.org/bugzilla-test/attachment.cgi?id=21126action=edit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #21 from burnus at gcc dot gnu dot org 2010-09-10 12:09 --- Created an attachment (id=21765) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21765action=view) Updated patch Updated patch to fix review issues and the Cray patch issue. I won't be able to work on this (i.e. regtest + submit) for the next days thus I put it here. Cf. http://gcc.gnu.org/ml/fortran/2010-09/msg00198.html and http://gcc.gnu.org/ml/fortran/2010-09/msg00234.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #21265|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #22 from burnus at gcc dot gnu dot org 2010-09-10 12:12 --- (In reply to comment #21) Created an attachment (id=21765) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21765action=view) [edit] Updated patch Note: I forgot to include the test case from attachment 21265 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug fortran/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
--- Comment #11 from burnus at gcc dot gnu dot org 2010-09-09 09:00 --- [Move comment from IRC #gcc to bugzilla] (In reply to comment #9) For what it is worth, on AMD Athlon 64 X2 4800+ / x86-64-linux, [...] That's a +16% increase in run-time with -fwhole-program. (In reply to comment #10) So hot-bb-frequency-fraction solves the whole regression? For me (cf. system above), --param hot-bb-frequency-fraction=2000 reduces the slow down due to -fwhole-program from 16% to 3%. (The LTO version with and without -fwhole-file is about 2% slower than the corresponding -fno-lto version.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #18 from burnus at gcc dot gnu dot org 2010-09-09 19:33 --- (In reply to comment #0) This is pretty widespread. I have attached one example That's now mostly fixed - though one patch is pending. Now gfortran -fdump-tree-original-lineno generates mostly sensible line numbers. For the given example, only for the DO loop the line numbers are a bit counter intuitive, given the line numbers 14do i = 1,10 15 array1(i) = i 16end do the dump of the internal representation (shown in a C-like syntax) is: [debug.f90 : 14] i = 1; [debug.f90 : 15] if ([debug.f90 : 15] i = 10) ... [debug.f90 : 15] array1[[debug.f90 : 15] (integer(kind=8)) i + -1] = i; L.1:; [debug.f90 : 15] D.1577 = [debug.f90 : 15] i == 10; [debug.f90 : 15] i = [debug.f90 : 15] i + 1; [debug.f90 : 15] if (D.1577) goto L.2; The i = 1 is in the expected line - as is the array1(i) = i assignment, but the loop increment and the exit conditions I would expect in line 14 and not in line 15. If no one else does, I will have a look after the last input_location patch has been committed. I expect that there are more cases where the annotation is slightly misplaced. If one looks at GCC 4.4, one finds: [debug.f90 : 14] i = 1; [debug.f90 : 14] if (i = 10) [debug.f90 : 15] array1[(integer(kind=8)) i + -1] = i; L.1:; D.1550 = i == 10; i = i + 1; if (D.1550) goto L.2; Thus, the first loop condition is in the proper line (14) while there is no line number associated with the loop increment and the exit condition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #19 from burnus at gcc dot gnu dot org 2010-09-08 06:25 --- Reviewed patch (OK) available at http://gcc.gnu.org/ml/fortran/2010-09/msg00198.html however, it causes regressions as some of the intrinsics (in intrinsic.c) have the wrong intents - which causes wrong code (too much optimized away). Thus, one first needs to audit and fix intrinsic.c before this patch can be committed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug fortran/45602] New: Reject coarrays for move_alloc
For MOVE_ALLOC coarrays should not be allowed - maybe some other places should be checked as well. For MOVE_ALLOC, see interpretation request at http://j3-fortran.org/doc/meeting/193/10-200.txt Test program: integer, allocatable :: a[:], b call move_alloc (a, b) end -- Summary: Reject coarrays for move_alloc 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: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45602
[Bug fortran/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
--- Comment #9 from burnus at gcc dot gnu dot org 2010-09-08 21:00 --- For what it is worth, on AMD Athlon 64 X2 4800+ / x86-64-linux, I get for gfortran -O3 -ffast-math -march=native -- and with with and without -flto: 0m45.132s -- (options as above) 0m52.731s -- additionally -fwhole-program That's a +16% increase in run-time with -fwhole-program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334
[Bug fortran/45608] Bogus error about procedure attribute
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-09 05:35 --- I am not sure how to improve this (internally). NAG also prints: f95 hjf.f90 Error: hjf.f90, line 26: Inconsistent usage of CURVE detected at )@% Error: hjf.f90, line 26: Component of function reference detected at )@% However, the error location could be better - instead of pointing to the NAMELIST line, one could - as NAG, ifort and g95 do - point to the PRINT line, e.g. g95: print *, curve(1)%symbol%typee 1 Error: PROCEDURE attribute conflicts with NAMELIST attribute in 'curve' at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45608
[Bug fortran/45577] [4.6 Regression] Bogus(?) ... type incompatible with source-expr ... error
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-07 09:29 --- Hi Janus. I wonder whether it could be due to the fix PR fortran/45507; could you have a look? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
[Bug middle-end/45579] New: Re-enable IPA-CP for fn spec
Follow up to PR 43665. Both fn spec (a TYPE_ATTRIBUTES) and -fipa-cp are important optimization features. However, -fipa-cp can eliminate arguments and does not update fn spec, leading to wrong code. Thus, ipa-cp has been disabled if it encounters an attribute, cf. PR 43665 's attachment 21714. Expected (missed optimization): ipa-cp updates fn spec to account for the eliminated arguments. fn spec allows to annotate to aid optimization via: /* Nonzero if the argument is not dereferenced recursively, thus only directly reachable memory is read or written. */ #define EAF_DIRECT(1 0) /* Nonzero if memory reached by the argument is not clobbered. */ #define EAF_NOCLOBBER (1 1) /* Nonzero if the argument does not escape. */ #define EAF_NOESCAPE (1 2) /* Nonzero if the argument is not used by the function. */ #define EAF_UNUSED(1 3) And IPA-cp does a complementary optimization: -fipa-cp Perform interprocedural constant propagation. This optimization analyzes the program to determine when values passed to functions are constants and then optimizes accordingly. This optimization can substantially increase performance if the application has constants passed to functions. This flag is enabled by default at -O2, -Os and -O3. -- Summary: Re-enable IPA-CP for fn spec Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 43665 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45579
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #15 from burnus at gcc dot gnu dot org 2010-09-07 11:37 --- Created an attachment (id=21725) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21725action=view) tree.h patch tp add build[0-9]_loc (In reply to comment #9) grep -w build[0-9] trans*.c | wc -l 38 grep -w build[0-9]_v trans*.c | wc -l 158 That part requires the attached patch to add build[0-9]_loc to gcc/tree.h. The patch still needs to be build with all languages - and then make -k check regtested ... grep -w fold_build[0-9] trans*.c | wc -l 734 That's now down to trans-array.c:198 and down to 117 in my local tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45575] ICE on missing module file
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-07 15:09 --- Works with x86_64-unknown-linux-gnu (4.6.0 20100907 (experimental) [trunk revision 163943]) and also under i686-w64-mingw and x86_64-w64-mingw. A test with i586-pc-mingw32 is pending; Kai offered to do it. Brad, if possible, can you provide more information, i.e. which version of MinGW32 exactly (if known, for me gfortran -v prints the version + the SVN revision), where did you get the build from? Can you run the compiler in a debugger? Use: gfortran -v bugtest.f90 and search for the line with starts with /some/path/f95 and run then the f951 line in a debugger, e.g. gdb --args /some/path/to/f951 many, many, many options and then in (gdb) run bt and post the result of the backtrace (bt). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45575
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #16 from burnus at gcc dot gnu dot org 2010-09-07 15:29 --- (In reply to comment #15) Created an attachment (id=21725) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21725action=view) [edit] +#define build6_loc(l,c,t1,t2,t3,t4,t5,t6,t7) \ + build1_stat_loc (l,c,t1,t2,t3,t4,t5,t6,t7 MEM_STAT_INFO) The last line should use -6- and not -1-, i.e. build1_stat_loc - build6_stat_loc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45583] New: Typo in onlinedocs/gfortran/COS.html / intrinsics.texi
http://gcc.gnu.org/onlinedocs/gfortran/COS.html shows a typo for the Specific names -- some superfluous n after COS. -- Summary: Typo in onlinedocs/gfortran/COS.html / intrinsics.texi Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45583
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #17 from burnus at gcc dot gnu dot org 2010-09-07 19:03 --- Subject: Bug 45186 Author: burnus Date: Tue Sep 7 19:03:41 2010 New Revision: 163964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163964 Log: 2010-09-07 Tobias Burnus bur...@net-b.de PR fortran/45186 * trans-array.c (gfc_conv_descriptor_data_get, gfc_conv_descriptor_data_set, gfc_conv_descriptor_data_addr, gfc_conv_descriptor_offset, gfc_conv_descriptor_dtype, gfc_conv_descriptor_dimension, gfc_conv_descriptor_stride, gfc_conv_descriptor_lbound, gfc_conv_descriptor_ubound, gfc_conv_shift_descriptor_lbound, gfc_set_loop_bounds_from_array_spec, gfc_trans_allocate_array_storage, gfc_trans_create_temp_array, gfc_conv_array_transpose, gfc_get_iteration_count, gfc_grow_array, gfc_trans_array_ctor_element, gfc_trans_array_constructor_subarray, gfc_trans_array_constructor_value, constant_array_constructor_loop_size, gfc_trans_array_constructor, gfc_set_vector_loop_bounds, gfc_trans_array_bound_check, gfc_conv_array_index_offset, gfc_conv_scalarized_array_ref, gfc_conv_array_ref, gfc_trans_preloop_setup, gfc_trans_scalarized_loop_end, gfc_conv_ss_startstride, gfc_conv_loop_setup, gfc_conv_array_extent_dim, gfc_conv_descriptor_size, gfc_array_init_size, gfc_array_allocate, gfc_array_deallocate, gfc_trans_array_bounds, gfc_trans_auto_array_allocation, gfc_trans_dummy_array_bias, gfc_get_dataptr_offset, get_array_charlen, gfc_conv_expr_descriptor, array_parameter_size, gfc_conv_array_parameter, gfc_trans_dealloc_allocated, get_full_array_size, duplicate_allocatable, structure_alloc_comps): Change fold_build[0-9] to fold_build[0-9]_loc. (duplicate_allocatable, structure_alloc_comps, gfc_duplicate_allocatable): Add space after function name. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45583] Typo in onlinedocs/gfortran/COS.html / intrinsics.texi
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-07 19:07 --- FIXED -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45583
[Bug fortran/45583] Typo in onlinedocs/gfortran/COS.html / intrinsics.texi
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-07 19:07 --- Subject: Bug 45583 Author: burnus Date: Tue Sep 7 19:07:36 2010 New Revision: 163965 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163965 Log: 2010-09-07 Tobias Burnus bur...@net-b.de PR fortran/45583 * intrinsic.texi (COS): Remove superfluous n. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45583
[Bug fortran/45592] New: [OOP] Valid structure constructor rejected
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5c7eef953c5653ff Assuming the definition, type, abstract :: pointGen ! ... end type pointGen type, extends( pointGen) :: point2d real :: x real :: y end type point2d the structure constructor will fail with: myPoint = point2d(2.3, 4.2) 1 Error: Invalid character in name at (1) It works if one uses: myPoint = point2d(x=2.3, y=4.2) -- Summary: [OOP] Valid structure constructor rejected Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45592
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #12 from burnus at gcc dot gnu dot org 2010-09-06 13:35 --- DONE: - POPPAR, POPCNT [and LEADZ/TAILZ already in GCC 4.4] - IALL, IANY, IPARITY TODO (cf. comment 2) a) F2008's bit intrinsics: DSHIFTL, DSHIFTR, SHIFTA, SHIFTL, SHIFTR, MASKL, MASKR, BGE, BGT, BLE, BLT, MERGE_BITS c) HPF only: ILEN(I) Cf. http://wotug.org/parallel/standards/hpf/, HPF 2.0, Section 7.6 d) IBCHNG(POS, I) Industrial Real-Time Fortran Standard (ISO 7846:1985; withdrawn) and common vendor extension -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug fortran/40571] F2008: ISO_FORTRAN_ENV: Missing constants
--- Comment #4 from burnus at gcc dot gnu dot org 2010-09-06 14:52 --- Created an attachment (id=21712) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21712action=view) New draft patch New draft patch. New: Documentation added; REAL_KINDS and REAL_KINDS(1) works now. TODO - The test case in the file, i.e. REAL(REAL_KINDS(1)) fails with Error: Constant expression required - Include attachment 21126 as test case -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #21122|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40571
[Bug fortran/45560] New: debugging: Add EXPR pretty printer (gfc_debug_expr)
Richard wrote in IRC:
fortran needs a pretty-printer
gfc_show_expr is annoying as it doesn't flush and you have to manually set
dumpfile
to stdout
Untested draft patch:
Index: dump-parse-tree.c
===
--- dump-parse-tree.c (revision 163921)
+++ dump-parse-tree.c (working copy)
@@ -48,6 +48,17 @@
static void show_code_node (int, gfc_code *);
static void show_namespace (gfc_namespace *ns);
+/* Allow dumping of an expression in the debugger. */
+void gfc_debug_expr (gfc_expr *);
+void
gfc_debug_expr (gfc_expr *e)
+{
+ FILE *tmp = dumpfile;
+ dumpfile = stdout;
+ show_expr (e)
+ fputc ('\n', dumpfile);
+ dumpfile = tmp;
+}
/* Do indentation for a specific level. */
--
Summary: debugging: Add EXPR pretty printer (gfc_debug_expr)
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45560
[Bug fortran/40571] F2008: ISO_FORTRAN_ENV: Missing constants
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-06 17:55 --- More failures: use iso_fortran_env integer :: i print *, shape(real_kinds(1)) ! should be rejected (scalar) i = real_kinds(1) ! ICE end Thus, the FE has problems if one takes a REF of an EXPR_ARRAY, i.e. the shape does not get updated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40571
[Bug fortran/45560] debugging: Add EXPR pretty printer (gfc_debug_expr)
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-06 18:17 --- Subject: Bug 45560 Author: burnus Date: Mon Sep 6 18:16:50 2010 New Revision: 163928 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163928 Log: 2010-09-06 Tobias Burnus bur...@net-b.de PR fortran/45560 * dump-parse-tree.c (gfc_debug_expr): New function. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45560
[Bug fortran/45560] debugging: Add EXPR pretty printer (gfc_debug_expr)
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-06 18:17 --- FIXED for 4.6. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45560
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #17 from burnus at gcc dot gnu dot org 2010-09-06 18:43 --- (In reply to comment #16) This patch makes IPA-CP to refrain from modifying a function when it sees a any type attributes. In a way that's unfortunate: Both fn attr and argument removal are optimization options. As far as I understand it there is already a test in our testsuite that fails (with the patch from comment #7 applied) and so I am not going to add an extra one. OK. I think it's best to check this in separately and I will submit it for approval tomorrow if there are no unforeseen problems. I will also submit my patch - for committal after yours is in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug fortran/45560] debugging: Add EXPR pretty printer (gfc_debug_expr)
--- Comment #3 from burnus at gcc dot gnu dot org 2010-09-06 18:52 --- Subject: Bug 45560 Author: burnus Date: Mon Sep 6 18:51:48 2010 New Revision: 163931 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163931 Log: 2010-09-06 Tobias Burnus bur...@net-b.de PR fortran/45560 * dump-parse-tree.c (gfc_debug_expr): Use stderr instead of stdout. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45560
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #14 from burnus at gcc dot gnu dot org 2010-09-05 18:10 --- Subject: Bug 45186 Author: burnus Date: Sun Sep 5 18:10:11 2010 New Revision: 163879 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163879 Log: 2010-09-05 Tobias Burnus bur...@net-b.de PR fortran/45186 * trans-intrinsic.c (gfc_conv_intrinsic_sign, gfc_conv_intrinsic_leadz): Use build_call_expr_loc instead of build_call_expr. * trans-expr.c (gfc_conv_expr_present, gfc_conv_missing_dummy, gfc_conv_string_length, gfc_conv_substring, gfc_conv_component_ref, gfc_conv_unary_op, gfc_conv_powi, gfc_conv_cst_int_power, gfc_conv_string_tmp, gfc_conv_concat_op, gfc_conv_expr_op, gfc_build_compare_string, gfc_set_interface_mapping_bounds, gfc_conv_subref_array_arg, gfc_conv_derived_to_class, conv_isocbinding_procedure, gfc_conv_procedure_call, fill_with_spaces, gfc_trans_string_copy, gfc_trans_alloc_subarray_assign, gfc_trans_structure_assign, gfc_trans_pointer_assignment, gfc_trans_scalar_assign, gfc_trans_zero_assign, gfc_trans_array_copy, gfc_trans_array_constructor_copy): Change fold_build[0-9] to fold_build[0-9]_loc. * trans-io.c (set_parameter_const, set_parameter_value, set_parameter_ref, gfc_convert_array_to_string, set_string, set_internal_unit, io_result, set_error_locus, nml_get_addr_expr, build_dt): Ditto. * trans-openmp.c (gfc_omp_clause_default_ctor, gfc_omp_clause_copy_ctor, gfc_omp_clause_assign_op, gfc_trans_omp_array_reduction, gfc_trans_omp_atomic, gfc_trans_omp_do): Ditto. * trans.c (gfc_add_modify, gfc_build_addr_expr, gfc_build_array_ref, gfc_trans_runtime_error_vararg, gfc_trans_runtime_check, gfc_call_malloc, gfc_allocate_with_status, gfc_allocate_array_with_status, gfc_call_free, gfc_deallocate_with_status, gfc_call_realloc): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/convert.c trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/trans-intrinsic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #11 from burnus at gcc dot gnu dot org 2010-09-06 05:55 --- Subject: Bug 38282 Author: burnus Date: Mon Sep 6 05:55:10 2010 New Revision: 163898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163898 Log: 2010-09-06 Tobias Burnus bur...@net-b.de PR fortran/38282 * intrinsic.c (add_functions): Support IALL, IANY, IPARITY. (check_specific): Special case for those intrinsics. * gfortran.h (gfc_isym_id): Add new intrinsics * intrinsic.h (gfc_check_transf_bit_intrins, gfc_simplify_iall, gfc_simplify_iany, gfc_simplify_iparity, gfc_resolve_iall, gfc_resolve_iany, gfc_resolve_iparity): New prototypes. * iresolve.c (gfc_resolve_iall, gfc_resolve_iany, gfc_resolve_iparity, resolve_transformational): New functions. (gfc_resolve_product, gfc_resolve_sum, gfc_resolve_parity): Use resolve_transformational. * check.c (gfc_check_transf_bit_intrins): New function. * simplify.c (gfc_simplify_iall, gfc_simplify_iany, gfc_simplify_iparity, do_bit_any, do_bit_ior, do_bit_xor, simplify_transformation): New functions. (gfc_simplify_all, gfc_simplify_any, gfc_simplify_parity, gfc_simplify_sum, gfc_simplify_product): Use simplify_transformation. * trans-intrinsic.c (gfc_conv_intrinsic_arith, gfc_conv_intrinsic_function, gfc_is_intrinsic_libcall): Handle IALL, IANY and IPARITY intrinsics. * intrinsic.texi (IMAGE_INDEX): Move up to fix alphabetic order. (IALL, IANY, IPARITY): Document new intrinsics. 2010-09-06 Tobias Burnus bur...@net-b.de PR fortran/38282 * gfortran.dg/iall_iany_iparity_1.f90: New. * gfortran.dg/iall_iany_iparity_2.f90: New. 2010-09-06 Tobias Burnus bur...@net-b.de PR fortran/38282 * gfortran.map: Add new iany, iall and iparity intrinsics. * Makefile.am: Ditto. * m4/iany.m4: New. * m4/iall.m4: New. * m4/iparity.m4: New. * Makefile.in: Regenerate. * generated/iall_i1.c: Generate. * generated/iall_i2.c: Generate. * generated/iall_i4.c: Generate. * generated/iall_i8.c: Generate. * generated/iall_i16.c: Generate. * generated/iany_i1.c: Generate. * generated/iany_i2.c: Generate. * generated/iany_i4.c: Generate. * generated/iany_i8.c: Generate. * generated/iany_i16.c: Generate. * generated/iparity_i1.c: Generate. * generated/iparity_i2.c: Generate. * generated/iparity_i4.c: Generate. * generated/iparity_i8.c: Generate. * generated/iparity_i16.c: Generate. Added: trunk/gcc/testsuite/gfortran.dg/iall_iany_iparity_1.f90 trunk/gcc/testsuite/gfortran.dg/iall_iany_iparity_2.f90 trunk/libgfortran/generated/iall_i1.c trunk/libgfortran/generated/iall_i16.c trunk/libgfortran/generated/iall_i2.c trunk/libgfortran/generated/iall_i4.c trunk/libgfortran/generated/iall_i8.c trunk/libgfortran/generated/iany_i1.c trunk/libgfortran/generated/iany_i16.c trunk/libgfortran/generated/iany_i2.c trunk/libgfortran/generated/iany_i4.c trunk/libgfortran/generated/iany_i8.c trunk/libgfortran/generated/iparity_i1.c trunk/libgfortran/generated/iparity_i16.c trunk/libgfortran/generated/iparity_i2.c trunk/libgfortran/generated/iparity_i4.c trunk/libgfortran/generated/iparity_i8.c trunk/libgfortran/m4/iall.m4 trunk/libgfortran/m4/iany.m4 trunk/libgfortran/m4/iparity.m4 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/gfortran.map -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug fortran/45532] gfortran namelist read error
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-04 07:35 --- CONFIRM. The program works with NAG, g95, ifort and prints 1. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-09-04 07:35:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45532
[Bug fortran/45530] gfortran internal compiler error
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-04 08:14 --- CONFIRM. NAG prints: Error: nm2.f90, line 22: Namelist-group-object CURVE has a POINTER component -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2010-09-04 08:14:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45530
[Bug fortran/45530] gfortran internal compiler error
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-04 16:43 --- The endless loop happens in derived_inaccessible - seemingly called by resolve_fl_namelist (all resolve.c); that check happens before the pointer-components check. Moving the PRIVATE/accessible check _after_ the pointer/allocatable components cures the issue. -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-09-04 08:14:29 |2010-09-04 16:43:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45530
[Bug fortran/45530] gfortran internal compiler error
--- Comment #3 from burnus at gcc dot gnu dot org 2010-09-04 17:47 --- Subject: Bug 45530 Author: burnus Date: Sat Sep 4 17:47:02 2010 New Revision: 163862 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163862 Log: 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45530 * resolve.c (resolve_fl_namelist): Change constraint checking order to prevent endless loop. 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45530 * gfortran.dg/namelist_63.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/namelist_63.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45530
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #13 from burnus at gcc dot gnu dot org 2010-09-04 19:21 --- Subject: Bug 45019 Author: burnus Date: Sat Sep 4 19:20:53 2010 New Revision: 163863 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163863 Log: 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45019 * dependency.c (gfc_check_dependency): Add argument alising * check. * symbol.c (gfc_symbols_could_alias): Add argument alising * check. 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45019 * gfortran.dg/aliasing_dummy_5.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/aliasing_dummy_5.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/dependency.c branches/gcc-4_5-branch/gcc/fortran/symbol.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #14 from burnus at gcc dot gnu dot org 2010-09-04 19:21 --- FIXED. Thanks for the bugreport. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/45489] Default initialization of derived-type function result missing
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-04 19:25 --- Subject: Bug 45489 Author: burnus Date: Sat Sep 4 19:25:36 2010 New Revision: 163865 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163865 Log: 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45489 * resolve.c (apply_default_init): Mark symbol as referenced, if it is initialized. (resolve_symbol): Change intialized check for BT_DERIVED such that also function results get initialized. 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45489 * gfortran.dg/initialization_27.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/initialization_27.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45489
[Bug fortran/45530] gfortran internal compiler error
--- Comment #4 from burnus at gcc dot gnu dot org 2010-09-04 19:37 --- Subject: Bug 45530 Author: burnus Date: Sat Sep 4 19:36:47 2010 New Revision: 163866 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163866 Log: 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45530 * resolve.c (resolve_fl_namelist): Change constraint checking order to prevent endless loop. 2010-09-04 Tobias Burnus bur...@net-b.de PR fortran/45530 * gfortran.dg/namelist_63.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/namelist_63.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45530
[Bug fortran/45489] Default initialization of derived-type function result missing
--- Comment #6 from burnus at gcc dot gnu dot org 2010-09-04 19:48 --- FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45489
[Bug fortran/45530] gfortran internal compiler error
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-04 19:49 --- FIXED on the trunk (4.6) and on the 4.5 branch. Thanks for the bug report! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45530
[Bug fortran/45513] New: BOZ kinds differently handled, F2008: BOZ in bit intrinsics
As reported by Fran,cois-Xavier at http://gcc.gnu.org/ml/fortran/2010-08/msg00484.html a) integer(kind=8) :: i i = 0 print *, kind(ior (i, zff1e)) print *, kind(ior (0_8, zff1e)) end gives different different results for the compile-time and run-time evaluation. b) F2008 allows BOZ in bit intrinsics, which need to be properly handled; for IOR(I,J) one has: * I or J can be BOZ or integers, but they can't both be BOZ. * Result Characteristics. Same as I if I is of type integer; otherwise, same as J. -- Summary: BOZ kinds differently handled, F2008: BOZ in bit intrinsics Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45513
[Bug fortran/34162] F2008: Allow internal procedures as actual argument
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-03 08:39 --- Asked at gcc-patches/fortran for suggestions how to implement this: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00211.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34162
[Bug fortran/45516] [F08] allocatable compontents of recursive type
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-03 12:12 --- (In reply to comment #1) Here is a patch to accept the type declaration in comment #0: Well, you at least need to use gfc_notify_std(GFC_STD_F2008, ... And one should make sure that the allocation/clean up works as expected. * * * As follow up to the initial implementation, one should implement at some point the following, which does not do a deep copy but simply appends the old data. (Example from the mentioned article.) type entry real :: value integer :: index type(entry), allocatable :: next end type entry type (entry), allocatable :: top top = entry ( new_value, new_index, top ) (The last line assume reallocate on assignment; I think it already works for derived types with structure constructor; I know that it does not yet work for intrinsic types - not does it work on other assignment than structure constructors.) The classical way to append a new item is the following, which should avoid a deep copy (check!): type (entry), allocatable :: top, temp temp = entry ( new_value, new_index, temp ) call move_alloc(top,temp%next) call move_alloc(temp,top) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot ||org, burnus at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45516
[Bug fortran/45521] New: Fortran 2008: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
As the introduction of Fortran 2008 mentions: - ALLOCATABLE and POINTER attributes are used in generic resolution. - Procedureness of a dummy argument is used in generic resolution. Or as The new features of Fortran 2008 puts it: A pair of specific procedures in a generic interface are permitted to be distinguishable by virtue of a pointer argument without intent in of one corresponding to an allocatable argument of the other or a data argument of one corresponding to a procedure argument of the other. Fortran 2008's 12.4.3.4.5 Restrictions on generic declarations has Two dummy arguments are distinguishable if - one is a procedure and the other is a data object, - they are both data objects or known to be functions, and neither is TKR compatible with the other, - one has the ALLOCATABLE attribute and the other has the POINTER attribute, or - one is a function with nonzero rank and the other is not known to be a function. Interpretation request F08/0001 / 10-145 changes this (EDITS to 10-007) '[286:4] In 12.4.3.4.5p3, after the other has the POINTER attribute, Insert and not the INTENT(IN) attribute.' Cf. http://j3-fortran.org/doc/meeting/193/10-199.txt Fortran 2003 just had (16.2.3 Restrictions on generic declarations): Two dummy arguments are distinguishable if neither is a subroutine and neither is TKR compatible (5.1.1.2) with the other. -- Summary: Fortran 2008: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 39627 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #13 from burnus at gcc dot gnu dot org 2010-09-03 19:41 --- Subject: Bug 45186 Author: burnus Date: Fri Sep 3 19:41:11 2010 New Revision: 163838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163838 Log: 2010-09-03 Tobias Burnus bur...@net-b.de PR fortran/45186 * trans-intrinsic.c (gfc_conv_intrinsic_sign, gfc_conv_intrinsic_leadz): Use build_call_expr_loc instead of build_call_expr. * trans-expr.c (gfc_conv_expr_present, gfc_conv_missing_dummy, gfc_conv_string_length, gfc_conv_substring, gfc_conv_component_ref, gfc_conv_unary_op, gfc_conv_powi, gfc_conv_cst_int_power, gfc_conv_string_tmp, gfc_conv_concat_op, gfc_conv_expr_op, gfc_build_compare_string, gfc_set_interface_mapping_bounds, gfc_conv_subref_array_arg, gfc_conv_derived_to_class, conv_isocbinding_procedure, gfc_conv_procedure_call, fill_with_spaces, gfc_trans_string_copy, gfc_trans_alloc_subarray_assign, gfc_trans_structure_assign, gfc_trans_pointer_assignment, gfc_trans_scalar_assign, gfc_trans_zero_assign, gfc_trans_array_copy, gfc_trans_array_constructor_copy): Change fold_build[0-9] to fold_build[0-9]_loc. * trans-io.c (set_parameter_const, set_parameter_value, set_parameter_ref, gfc_convert_array_to_string, set_string, set_internal_unit, io_result, set_error_locus, nml_get_addr_expr, build_dt): Ditto. * trans-openmp.c (gfc_omp_clause_default_ctor, gfc_omp_clause_copy_ctor, gfc_omp_clause_assign_op, gfc_trans_omp_array_reduction, gfc_trans_omp_atomic, gfc_trans_omp_do): Ditto. * trans.c (gfc_add_modify, gfc_build_addr_expr, gfc_build_array_ref, gfc_trans_runtime_error_vararg, gfc_trans_runtime_check, gfc_call_malloc, gfc_allocate_with_status, gfc_allocate_array_with_status, gfc_call_free, gfc_deallocate_with_status, gfc_call_realloc): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45489] Default initialization of derived-type function result missing
--- Comment #3 from burnus at gcc dot gnu dot org 2010-09-02 07:31 ---
(In reply to comment #2)
It seems to work if one adds
if (!a-referenced sym-value)
gfc_set_sym_referenced (sym);
As gfortran does not use a static initializer via sym-value but an assignment,
this check does not work.
The following patch should work:
--- resolve.c (revision 163759)
+++ resolve.c (working copy)
@@ -9476,6 +9476,7 @@ apply_default_init (gfc_symbol *sym)
return;
build_init_assign (sym, init);
+ sym-attr.referenced = 1;
}
/* Build an initializer for a local integer, real, complex, logical, or
@@ -12148,7 +12149,6 @@ resolve_symbol (gfc_symbol *sym)
described in 14.7.5, to those variables that have not already
been assigned one. */
if (sym-ts.type == BT_DERIVED
- sym-attr.referenced
sym-ns == gfc_current_ns
!sym-value
!sym-attr.allocatable
@@ -12158,6 +12158,7 @@ resolve_symbol (gfc_symbol *sym)
if ((!a-save !a-dummy !a-pointer
!a-in_common !a-use_assoc
+ (a-referenced || a-result)
!(a-function sym != sym-result))
|| (a-dummy a-intent == INTENT_OUT !a-pointer))
apply_default_init (sym);
@@ -12166,10 +12167,7 @@ resolve_symbol (gfc_symbol *sym)
if (sym-ts.type == BT_CLASS sym-ns == gfc_current_ns
sym-attr.dummy sym-attr.intent == INTENT_OUT
!sym-attr.pointer !sym-attr.allocatable)
-{
- apply_default_init (sym);
- gfc_set_sym_referenced (sym);
-}
+apply_default_init (sym);
/* If this symbol has a type-spec, check it. */
if (sym-attr.flavor == FL_VARIABLE || sym-attr.flavor == FL_PARAMETER
Extended test case
Note, I failed to create a failing dummy test case. Seemingly, sym-value is
set for the dummies below; thus, only the f part of the test case is failing
without the patch above.
--
program test_init
implicit none
integer, target :: tgt
type A
integer, pointer:: p = null ()
integer:: i=3
end type A
type(A):: x, y(3)
x=f()
if (associated(x%p) .or. x%i /= 3) call abort ()
y(1)%p = tgt
y%i = 99
call sub1(3,y)
if (associated(y(1)%p) .or. any(y(:)%i /= 3)) call abort ()
y(1)%p = tgt
y%i = 99
call sub2(y)
if (associated(y(1)%p) .or. any(y(:)%i /= 3)) call abort ()
contains
function f() result (fr)
type(A):: fr
end function f
subroutine sub1(n,x)
integer :: n
type(A), intent(out) :: x(n:n+2)
end subroutine sub1
subroutine sub2(x)
type(A), intent(out) :: x(:)
end subroutine sub2
end program test_init
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-09-02 07:31:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45489
[Bug fortran/45489] Default initialization of derived-type function result missing
--- Comment #4 from burnus at gcc dot gnu dot org 2010-09-02 10:11 --- Subject: Bug 45489 Author: burnus Date: Thu Sep 2 10:11:39 2010 New Revision: 163767 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163767 Log: 2010-09-02 Tobias Burnus bur...@net-b.de PR fortran/45489 * resolve.c (apply_default_init): Mark symbol as referenced, if it is initialized. (resolve_symbol): Change intialized check for BT_DERIVED such that also function results get initialized; remove now obsolete gfc_set_sym_referenced for BT_CLASS. 2010-09-02 Tobias Burnus bur...@net-b.de PR fortran/45489 * gfortran.dg/initialization_27.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45489
[Bug fortran/45495] ICE: For character function with length specifier dependent on non-present arg
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-02 11:32 --- 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. The program compiles (and runs) if one passes an actual argument - thus the problem only occurs very late during folding. The best probably would be to add a warning (default on?) and some conditions around the expression such that it remains valid for folding even if the argument is not present. Due to the complexity of fixing it for invalid programs - without having a chance to print an error message at compile time, I have reduced the priority to minor. Valgrind shows: ==5725== Invalid read of size 8 ==5725==at 0x896636: get_frame_type (tree-nested.c:223) ==5725==by 0x896BFF: get_chain_decl (tree-nested.c:330) ==5725==by 0x899ED5: get_nonlocal_debug_decl (tree-nested.c:842) ==5725==by 0x89A7C1: convert_nonlocal_reference_op (tree-nested.c:920) ==5725==by 0x9D0B66: walk_tree_1 (tree.c:10174) ==5725==by 0x70F96B: walk_gimple_op (gimple.c:1356) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.2.1 4.1.2 4.3.4 4.4.0 ||4.5.1 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-09-02 11:32:28 date|| Summary|ICE: For character function |ICE: For character function |with length specifier |with length specifier |dependent on non-present|dependent on non-present arg |arg.| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45495
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #12 from burnus at gcc dot gnu dot org 2010-09-02 14:04 --- Subject: Bug 45186 Author: burnus Date: Thu Sep 2 14:04:06 2010 New Revision: 163776 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163776 Log: 2010-09-02 Tobias Burnus bur...@net-b.de PR fortran/45186 * trans-common.c (create_common): Change build[0-9] to build[0-9]_loc. * trans-const.c (gfc_conv_constant_to_tree, gfc_conv_constant_to_tree): Ditto. * trans-decl.c (gfc_build_qualified_array, build_entry_thunks, gfc_get_fake_result_decl, gfc_trans_auto_character_variable, add_argument_checking, create_main_function, gfc_generate_return): Ditto. * trans-types.c (gfc_get_dtype, gfc_get_array_type_bounds): * Ditto. * trans-stmt.c (allocate_temp_for_forall_nest_1, compute_inner_temp_size, compute_overall_iter_number, generate_loop_for_rhs_to_temp, generate_loop_for_temp_to_lhs, gfc_conv_elemental_dependencies, gfc_do_allocate, gfc_evaluate_where_mask, gfc_trans_allocate, gfc_trans_arithmetic_if, gfc_trans_call, gfc_trans_character_select, gfc_trans_deallocate, gfc_trans_do, gfc_trans_do_while, gfc_trans_forall_1, gfc_trans_forall_loop, gfc_trans_goto, gfc_trans_if_1, gfc_trans_integer_select, gfc_trans_logical_select, gfc_trans_pointer_assign_need_temp, gfc_trans_return, gfc_trans_simple_do, gfc_trans_sync, gfc_trans_where_2, gfc_trans_where_assign) Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-common.c trunk/gcc/fortran/trans-const.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-types.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-02 18:32 --- That's a -m32 (fails) vs. -m64 (works) issue, cf. http://gcc.gnu.org/ml/fortran/2010-09/msg00062.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505
[Bug fortran/45507] New: [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)
Reported at http://gcc.gnu.org/ml/fortran/2010-09/msg00061.html Working: 163780 / 163718 Failing: 163661 / 163773 Error: Can't convert TYPE(c_ptr) to INTEGER(4) module filter use, intrinsic :: iso_c_binding type :: cType type(c_ptr) :: accelPtr = c_null_ptr end type cType type filterType type(cType) :: accel end type filterType type(filterType), allocatable, dimension(:) :: filters contains subroutine load() allocate(filters(1)) return end subroutine load end module filter -- Summary: [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45507
[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-02 19:47 --- Forgot to mention: Initial report and test case was by Andrew Benson (thanks!) Janus reported that the culprit is Rev. 163744 http://gcc.gnu.org/viewcvs?root=gccview=revrev=163744 which is the patch for PR fortran/44541 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45507
[Bug fortran/45474] New: Missing definable check actuals to INTENT(INOUT) dummies of intrinsics
No error is printed for:
call execute_command_line(date, .true.,(1),(1),('aa'))
end
although the third to fifth argument are declared as INTENT(INOUT) in
intrinsic.c and thus they have to be definable. The example is for
execute_command_line, but I think it applies to all intrinsics.
--
Summary: Missing definable check actuals to INTENT(INOUT) dummies
of intrinsics
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: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45474
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #8 from burnus at gcc dot gnu dot org 2010-09-01 12:01 --- (In reply to comment #0) Main program is written in C. (see the following) I strongly suggest using the C Binding facility of Fortran 2003 instead of relying on the internals of a given compiler. GCC/gfortran supports the C binding since 4.3.0 and newer version of most other compilers support it as well. Cf. http://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html The article at http://www.fortranplus.co.uk/resource/fortran_2003_2008_compiler_support.pdf lists for some compilers the support of Fortran 2003 (and 2008) features; interesting for you are the items Interoperability with C. Note: The list is incomplete as not all vendors have submitted their data. Regarding GCC/gfortran 4.1: I have no idea why it worked for you, but the calling convention of 4.1 was the same (I just checked). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
--- Comment #10 from burnus at gcc dot gnu dot org 2010-09-01 12:02 --- I think this is a variant of PR 42647: Allocatable components of allocatable scalars are not correctly handled. -- burnus at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||42647 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
[Bug target/45476] libgcc should contain TCmode functions
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-01 13:31 --- Cf. patch by Uros for cygming, darwin, freebsd at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00040.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
[Bug target/45476] libgcc should contain TCmode functions
--- Comment #6 from burnus at gcc dot gnu dot org 2010-09-01 13:35 --- Uros, did you see the comment of Dominique regarding x86_64-apple-darwin10? (In reply to comment #4) and bootstrap fails at stage 1 with ld: duplicate symbol ___fixtfdi in fixtfdi_s.o and _fixtfdi_s.o That's with the patch from comment 2 (or comment 4) - but I think that's identical to the submitted patch (comment 5). -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string
--- Comment #10 from burnus at gcc dot gnu dot org 2010-09-01 14:32 --- (In reply to comment #9) when the return value is character string, is it more intuitive to be requestdouble ( real(kind=8) rlat, real(kind=8) rlng,character(kind=1)[1:16] __result, integer(kind=4) .__result) instead of requestdouble (character(kind=1)[1:16] __result, integer(kind=4) .__result , real(kind=8) rlat, real(kind=8) rlng) ? I find both equally intuitive. I think the current order matches g77 and some other compilers; for instance NAG uses: void requestdouble_(requestdouble_Result,requestdouble_ResultLen,rlat_,rlng_) Thus as the other order is not clearly superior, sticking to the current order avoids a lot of trouble both for the compiler development and for user code. with three different compilers (Intel ifort, AbfSalford ftn95 and gfortran). Ifort supports Fortran 2003's C binding since quite some time; I think Salfort doesn't nor does Absoft, but I might be wrong. (Of AbfSalfort I have never heard.) For general Fortran discussion, I suggest the newsgroup comp.lang.fortran (via your news server or via http://groups.google.com/group/comp.lang.fortran/) or the gfortran mailing list. A bug report is not the proper method of communication :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466
[Bug fortran/43018] alloc_comp_scalar_1.f90: Valgrind Invalid read of size 4
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-01 14:36 --- Using 4.6.0 20100901 (experimental) [trunk revision 163720], I still see: gfortran -g alloc_comp_scalar_1.f90 valgrind ./a.out ==14804== Invalid read of size 8 ==14804==at 0x400B82: MAIN__ (alloc_comp_scalar_1.f90:14) ==14804==by 0x400D22: main (alloc_comp_scalar_1.f90:17) ==14804== Address 0x58e63d0 is 0 bytes inside a block of size 4 alloc'd ==14804==at 0x4C26C36: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14804==by 0x4008F9: MAIN__ (alloc_comp_scalar_1.f90:12) ==14804==by 0x400D22: main (alloc_comp_scalar_1.f90:17) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43018
[Bug fortran/45489] New: Default initialization of derived-type function result missing
The following program fails because the function result in f is never initialized. It should be default initialized, which works using other compilers. type A integer, pointer:: p = null () integer:: i=3 end type A type(A):: x x=f() if (associated(x%p) .or. x%i /= 3) call abort () contains function f() result (fr) type(A):: fr end function f end -- Summary: Default initialization of derived-type function result missing Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 32834 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45489
[Bug fortran/45489] Default initialization of derived-type function result missing
--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-01 21:05 ---
See thread at http://gcc.gnu.org/ml/fortran/2010-09/msg00044.html (+
previous/later emails) for the discussion.
Note: The following simple patch does *not* work but gives an ICE:
test.f90:9:0: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:1055
--- resolve.c (Revision 163740)
+++ resolve.c
@@ -12175,27 +12147,33 @@ resolve_symbol (gfc_symbol *sym)
|| sym-ns-proc_name-attr.flavor != FL_MODULE)))
gfc_error (Threadprivate at %L isn't SAVEd, sym-declared_at);
/* If we have come this far we can apply default-initializers, as
described in 14.7.5, to those variables that have not already
- been assigned one. */
+ been assigned one. That includes arrays with non-constant bounds
+ and function results. */
if (sym-ts.type == BT_DERIVED
- sym-attr.referenced
sym-ns == gfc_current_ns
!sym-value
!sym-attr.allocatable
!sym-attr.alloc_comp)
{
symbol_attribute *a = sym-attr;
if ((!a-save !a-dummy !a-pointer
!a-in_common !a-use_assoc
+ (sym-attr.referenced || sym-attr.result)
!(a-function sym != sym-result))
|| (a-dummy a-intent == INTENT_OUT !a-pointer))
apply_default_init (sym);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45489
[Bug fortran/45489] Default initialization of derived-type function result missing
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-01 21:19 --- (In reply to comment #1) Note: The following simple patch does *not* work but gives an ICE: test.f90:9:0: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1055 It seems to work if one adds if (!a-referenced sym-value) gfc_set_sym_referenced (sym); after apply_default_init (sym); in the inner if-block. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45489
[Bug fortran/44541] [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD
--- Comment #7 from burnus at gcc dot gnu dot org 2010-09-01 21:25 --- Close as fixed (on the 4.6 trunk). Thanks for the patch, Janus! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541
[Bug fortran/44529] [F03] array allocation with SOURCE
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-29 18:05 --- Cf. also PR 45440 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44529
[Bug fortran/45440] New: [OOP] ALLOCATE with SOURCE gives an ICE (segfault)
The following segfaults with the current trunk, a 20100701 trunk, and a 4.5.1 build. type t integer :: x real :: y(5) logical, allocatable :: z(:) end type t type(t) :: mt mt%x = 1 mt%y = [1,2,3,4,5] allocate ( mt%z, source = [ .true., .false., .true.]) ! ICE(segfault) print *, mt%x print *, mt%y print *, mt%z !print *, mt ! Invalid - ultimate allocatable component end Expected: As with ifort and crayftn: It compiles and ./a.out prints 1 1., 2., 3., 4., 5. T, F, T -- Summary: [OOP] ALLOCATE with SOURCE gives an ICE (segfault) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)
--- Comment #5 from burnus at gcc dot gnu dot org 2010-08-28 14:05 --- (In reply to comment #4) It works though when explicitly specifying the size of z to allocate: logical, allocatable :: z(:) allocate ( z(3), source = [ .true., .false., .true. ] ) Congratulation - you have found another bug: C633 (R631) If allocate-object is an array either allocate-shape-spec-list shall appear or source-expr shall appear [...] In your example both appear. (source-expr is either SOURCE= or MOLD=.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
[Bug fortran/45425] Bounds check applied before MASK of WHERE construct
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-28 15:40 --- The error message is generated in gfc_conv_array_ref it's called via gfc_trans_where_3 - gfc_conv_loop_setup - gfc_add_loop_ss_code - gfc_conv_variable Thus, the condition (mask) ends up at gfc_add_ss_to_loop (loop, css); and the bounds check is added via gfc_conv_loop_setup (loop, tdst-where); Thus, it ends up at loop-pre which comes before the actual loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45425
[Bug fortran/43217] Output of Hollerith constants which are not a multiple of 4 bytes
--- Comment #9 from burnus at gcc dot gnu dot org 2010-08-27 07:26 --- Close as FIXED (on the 4.6 trunk). Thanks for fixing it, Jerry! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
--- Comment #8 from burnus at gcc dot gnu dot org 2010-08-27 07:30 --- (In reply to comment #7) So the only ToDo item left here is comment #3. Which is C836, i.e. checking invalid use of the selector in a variable definition context. This will probably be fixes as part of PR 38936 (ASSOCIATE construct; SELECT TYPE uses it internally) - thus mark this PR as depending on PR 38936. -- burnus at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||38936 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug fortran/45424] New: F2008: Add is_contiguous intrinsic
For compile-time checking that can simply use the the gfc_is_simply_contiguous check. For run time, it should use the flag in the descriptor (if existing) or some library check, cf. pack checks. Because of the potential descriptor element, mark dependent on PR 36825. From Fortran 2008: 13.7.86 IS_CONTIGUOUS (ARRAY) Description. Test contiguity of an array (5.3.7). Class. Inquiry function. Argument. ARRAY may be of any type. It shall be an array. If it is a pointer it shall be associated. Result Characteristics. Default logical scalar. Result Value. The result has the value true if ARRAY is contiguous, and false otherwise. Example. After the pointer assignment AP = TARGET (1:10:2), IS_CONTIGUOUS (AP) has the value false. -- Summary: F2008: Add is_contiguous intrinsic Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 36825 OtherBugsDependingO 39627 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45424
[Bug fortran/45308] [F2003] DATE_AND_TIME does _not_ blank-pad strings
--- Comment #6 from burnus at gcc dot gnu dot org 2010-08-27 09:03 --- Close as FIXED (on the 4.6 trunk). Thanks, Jakub, for the patch! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[F2003] DATE_AND_TIME does |[F2003] DATE_AND_TIME does |_not_ black-pad strings |_not_ blank-pad strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45308
[Bug fortran/45426] New: Fixed-form: END may not be continued
Fortran 2008 (and earlier) have: 3.3.3.5 Fixed form statements The program unit END statement shall not be continued. A statement whose initial line appears to be a program unit END statement shall not be continued. (That applies to all END: A program unit is a main program, an external subprogram, a module, a submodule, or a block data program unit.) gfortran currently does not diagnose this: a) EXAMPLE 1: initial line appears to be a program unit END statement integer :: ender end +er = 5 print *, ender end b) EXAMPLE 2: END statement which is continued subroutine test end * subroutine test Expected: With -std=f2008 / -pedantic, the continuation line is rejected / being warned for - with -std=gnu/legacy it is accepted. Intel's ifort prints with -stand f03: test.f(2): error #5269: Operator END of program unit cannot be continued. end --^ Though I do not like Intel's wording. -- Summary: Fixed-form: END may not be continued 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: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45426
[Bug fortran/45426] Fixed-form: END may not be continued
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-27 10:11 --- I learned about this restriction at http://groups.google.com/group/comp.lang.fortran/msg/94c45e3d727f49fc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45426
[Bug fortran/45425] Bounds check applied before MASK of WHERE construct
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-27 11:58 ---
Confirm, the bounds checks are misplaces. Simplified test case:
implicit none
integer :: A(1), i,b(1)
logical :: mask(1)
mask = .false.
b = 5
do i = 2, 2
where (mask)
A = b(i)
end where
end do
end
If one looks at the dump of the internal representation (-fdump-tree-original)
one sees that WHERE itself is properly handled - only the bounds check is
outside of the WHERE loop and thus outside of the MASK:
if (__builtin_expect (i = 0, 0))
_gfortran_runtime_error_at (...);
[...]
S.1 = 1;
while (1)
{
if (S.1 1) goto L.4;
if (mask[S.1 + -1])
{
a[S.1 + -1] = b[i + -1];
}
S.1 = S.1 + 1;
}
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27766
nThis||
Keywords||wrong-code
Known to fail||4.1.2 4.6.0
Summary|where mask not applied |Bounds check applied before
|before where clause |MASK of WHERE construct
|evaluated |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45425
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #40 from burnus at gcc dot gnu dot org 2010-08-27 19:18 ---
Subject: Bug 33197
Author: burnus
Date: Fri Aug 27 19:17:45 2010
New Revision: 163595
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163595
Log:
gcc/fortran/
2010-08-27 Tobias Burnus bur...@net-b.de
PR fortran/33197
* gcc/fortran/intrinsic.c (add_functions): Add norm2 and parity.
* gcc/fortran/intrinsic.h (gfc_check_norm2, gfc_check_parity):
gfc_simplify_norm2, gfc_simplify_parity, gfc_resolve_norm2,
gfc_resolve_parity): New prototypes.
* gcc/fortran/gfortran.h (gfc_isym_id): New enum items
GFC_ISYM_NORM2 and GFC_ISYM_PARITY.
* gcc/fortran/iresolve.c (gfc_resolve_norm2,
gfc_resolve_parity): New functions.
* gcc/fortran/check.c (gfc_check_norm2, gfc_check_parity):
New functions.
* gcc/fortran/trans-intrinsic.c (gfc_conv_intrinsic_arith,
gfc_conv_intrinsic_function): Handle NORM2 and PARITY.
* gcc/fortran/intrinsic.texi (NORM2, PARITY): Add.
* gcc/fortran/simplify.c (simplify_transformation_to_array):
Add post-processing opterator.
(gfc_simplify_all, gfc_simplify_any, gfc_simplify_count,
gfc_simplify_product, gfc_simplify_sum): Update call.
(add_squared, do_sqrt, gfc_simplify_norm2, do_xor,
gfc_simplify_parity): New functions.
gcc/testsuite/
2010-08-27 Tobias Burnus bur...@net-b.de
PR fortran/33197
* gcc/testsuite/gfortran.dg/norm2_1.f90: New.
* gcc/testsuite/gfortran.dg/norm2_2.f90: New.
* gcc/testsuite/gfortran.dg/norm2_3.f90: New.
* gcc/testsuite/gfortran.dg/norm2_4.f90: New.
* gcc/testsuite/gfortran.dg/parity_1.f90: New.
* gcc/testsuite/gfortran.dg/parity_2.f90: New.
* gcc/testsuite/gfortran.dg/parity_3.f90: New.
libgfortran/
2010-08-27 Tobias Burnus bur...@net-b.de
PR fortran/33197
* libgfortran/m4/ifunction.m4 (FINISH_ARRAY_FUNCTION,
ARRAY_FUNCTION): Allow expression after loop.
* libgfortran/m4/norm2.m4: New for _gfortran_norm2_r{4,8,10,16}.
* libgfortran/m4/parity.m4: New for
* _gfortran_parity_l{1,2,4,8,16}.
* libgfortran/gfortran.map: Add new functions.
* libgfortran/Makefile.am: Ditto.
* libgfortran/m4/minloc1.m4: Add empty argument for
* ARRAY_FUNCTION.
* libgfortran/m4/maxloc1.m4: Ditto.
* libgfortran/m4/all.m4: Ditto.
* libgfortran/m4/minval.m4: Ditto.
* libgfortran/m4/maxval.m4: Ditto.
* libgfortran/m4/count.m4: Ditto.
* libgfortran/m4/product.m4: Ditto.
* libgfortran/m4/any.m4: Ditto.
* Makefile.in: Regenerated.
* generated/minval_r8.c: Regenerated.
* generated/maxloc1_4_r8.c: Regenerated.
* generated/minloc1_16_r16.c: Regenerated.
* generated/norm2_r4.c: Regenerated.
* generated/sum_i8.c: Regenerated.
* generated/parity_l2.c: Regenerated.
* generated/any_l16.c: Regenerated.
* generated/maxval_i2.c: Regenerated.
* generated/any_l2.c: Regenerated.
* generated/product_r4.c: Regenerated.
* generated/maxloc1_8_i4.c: Regenerated.
* generated/parity_l16.c: Regenerated.
* generated/all_l1.c: Regenerated.
* generated/product_i2.c: Regenerated.
* generated/minloc1_8_r16.c: Regenerated.
* generated/maxloc1_8_r16.c: Regenerated.
* generated/sum_r16.c: Regenerated.
* generated/sum_i1.c: Regenerated.
* generated/minloc1_4_r8.c: Regenerated.
* generated/maxloc1_16_r16.c: Regenerated.
* generated/minloc1_16_i4.c: Regenerated.
* generated/maxloc1_16_i4.c: Regenerated.
* generated/maxval_r16.c: Regenerated.
* generated/product_c10.c: Regenerated.
* generated/minloc1_8_i4.c: Regenerated.
* generated/all_l2.c: Regenerated.
* generated/product_c4.c: Regenerated.
* generated/sum_r4.c: Regenerated.
* generated/all_l16.c: Regenerated.
* generated/minloc1_16_r10.c: Regenerated.
* generated/sum_i2.c: Regenerated.
* generated/maxloc1_8_r8.c: Regenerated.
* generated/minval_i16.c: Regenerated.
* generated/parity_l4.c: Regenerated.
* generated/maxval_i4.c: Regenerated.
* generated/any_l4.c: Regenerated.
* generated/minval_i8.c: Regenerated.
* generated/maxloc1_4_i8.c: Regenerated.
* generated/minloc1_4_i16.c: Regenerated.
* generated/maxloc1_4_i16.c: Regenerated.
* generated/minloc1_8_r10.c: Regenerated.
* generated/product_i4.c: Regenerated.
* generated/maxloc1_8_r10.c: Regenerated.
* generated/sum_c16.c: Regenerated.
* generated/minloc1_16_r8.c: Regenerated.
* generated/maxloc1_16_r8.c: Regenerated.
* generated/count_4_l.c: Regenerated.
* generated/sum_r10.c: Regenerated
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #41 from burnus at gcc dot gnu dot org 2010-08-27 19:20 --- FIXED on the 4.6 trunk. Thanks to all involved in implementing the math intrinsics. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
[Bug fortran/45432] New: gfortran.dg/allocate_alloc_opt_9.f90: Segfault due to invalid FREE
When running gfortran gfortran.dg/allocate_alloc_opt_9.f90 I get an ICE with free_expr0(): Bad expr type That happens for the second call to gfc_match_allocate and the ICE happens via gfc_match_allocate (match.c:309) - gfc_free_expr valgrind writes: ==2974== Invalid read of size 4 ==2974== at 0x508BC9: gfc_match_allocate (match.c:3098) ==2974== by 0x518FA9: match_word (parse.c:65) ==2974== by 0x519EFC: decode_statement (parse.c:332) If one prints the value of tmp and tmp-expr_type, one gets tmp != NULL and expr_type == 1549556828 ... Daniel checked 4.5.0 and found the same valgrind error. -- Summary: gfortran.dg/allocate_alloc_opt_9.f90: Segfault due to invalid FREE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45432
