at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45756
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
: 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45602
--- 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
--- 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
--- 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
: 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
--- 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
--- 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
--- 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
: 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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_
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45507
--- 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
: 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
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
--- 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
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
--- 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
--- 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
--- 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
--- 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
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
1 - 100 of 4244 matches
Mail list logo
