--- Comment #4 from dfranke at gcc dot gnu dot org 2010-09-18 15:58 ---
(In reply to comment #3)
Am I correct to understand that the current situation (i.e. the error message)
is a temporary fix for some missing gfc_simplify_*?
If the error message you refer to is
Error
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-09-16 11:14 ---
They are not, as there, afaik, are no simplifiers yet.
Hence, with your patch they will be accepted, but you'd end up with wrong code
at the end, as the functions are not properly simplified and thus not constant
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 ---
Subject: Bug 34260
Author: dfranke
Date: Sun Jul 18 20:49:30 2010
New Revision: 162287
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162287
Log:
gcc/fortran/:
2010-07-18 Daniel Franke franke.dan
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-07-18 20:49
---
Subject: Bug 31346
Author: dfranke
Date: Sun Jul 18 20:49:30 2010
New Revision: 162287
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162287
Log:
gcc/fortran/:
2010-07-18 Daniel Franke franke.dan
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 ---
Subject: Bug 30668
Author: dfranke
Date: Sun Jul 18 20:49:30 2010
New Revision: 162287
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162287
Log:
gcc/fortran/:
2010-07-18 Daniel Franke franke.dan
--- Comment #58 from dfranke at gcc dot gnu dot org 2010-07-18 20:49
---
Subject: Bug 40011
Author: dfranke
Date: Sun Jul 18 20:49:30 2010
New Revision: 162287
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162287
Log:
gcc/fortran/:
2010-07-18 Daniel Franke franke.dan
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-07-18 21:12 ---
Fixed in trunk and 4.5. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-07-18 21:13
---
Fixed in trunk and 4.5. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-07-18 21:15 ---
Fixed in trunk and 4.5. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-07-15 21:37
---
(In reply to comment #13)
I'm leaving this assigned to Janus because, as OOP master, he knows best
the
place(s) where the change(s) have to be applied, for better cleanness,
bullet-proof-ness, and any
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-07-15 21:39 ---
(From update of attachment 20021)
Obsolete duplicate.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44960
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-07-15 21:57 ---
Spin-off: PR44960
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-07-08 16:47 ---
Reduced testcase:
Type :: t
character (len=32) :: txt(2)
End Type
Type (t) :: tt = t(/ , /))
print *, tt
End
Notes:
* the vatiable 'tt' must be used, if not used only a warning is printed, no
ICE
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-07-08 18:23 ---
(In reply to comment #3)
Notes:
* the vatiable 'tt' must be used, if not used only a warning is printed, no
ICE
* doing the same with INTEGER instead of CHARACTER works
* explicitly assigning the txt
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-07-08 20:13 ---
(In reply to comment #4)
I'd hazard the guess that some string length is not properly copied somewhere.
Type :: t
character (len=X) :: txt(2)
End Type
Type (t) :: tt = t((/ 12345, 67890 /))
print *, tt
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-06-13 16:05
---
Subject: Bug 31588
Author: dfranke
Date: Sun Jun 13 16:05:01 2010
New Revision: 160684
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160684
Log:
2010-06-13 Daniel Franke franke.dan...@gmail.com
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-06-13 16:05 ---
Subject: Bug 43954
Author: dfranke
Date: Sun Jun 13 16:05:01 2010
New Revision: 160684
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160684
Log:
2010-06-13 Daniel Franke franke.dan...@gmail.com
PR
org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44526
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-06-13 16:07
---
Fixed in trunk. See PR44526 for a follow-up request for libcpp.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-06-13 16:09 ---
Makefile dependency generation is now available in trunk (-cpp -MD).
See PR44526 for a follow-up request to libcpp.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-06-12 11:21 ---
Subject: Bug 44347
Author: dfranke
Date: Sat Jun 12 11:21:17 2010
New Revision: 160658
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160658
Log:
gcc/fortran/:
2010-06-12 Daniel Franke franke.dan
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-06-12 11:22 ---
Fixed in trunk and 4.5. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-12 14:43 ---
This goes off at a tangent, but still related to this PR ...
I think this is valid as the RESULT f is in the scope of g only and shadows the
FUNCTION f (Lahey accepts it):
FUNCTION f()
contains
FUNCTION g
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-06-12 17:47 ---
The patch below fixes the ICE in comment #2, but not the original report.
However, it also message-regresses on
FAIL: gfortran.dg/derived_function_interface_1.f90 -O (test for errors, line
41)
FAIL: gfortran.dg
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-06-12 21:06
---
Would it be ok to require '-cpp' with '-M' or shall '-M' work without explicit
preprocessing enabled? In the latter case, would it be ok to enable
preprocessing implicitly?
--
http://gcc.gnu.org/bugzilla
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-06-12 21:46
---
(In reply to comment #13)
Would it be ok to require '-cpp' with '-M' or shall '-M' work without explicit
preprocessing enabled? In the latter case, would it be ok to enable
preprocessing implicitly?
Passing -M
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-10 17:47 ---
(In reply to comment #2)
Thus, I do not see why one should add another version check.
Fine by me.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-06-10 18:26 ---
Subject: Bug 44457
Author: dfranke
Date: Thu Jun 10 18:25:56 2010
New Revision: 160567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160567
Log:
gcc/fortran/:
2010-06-10 Daniel Franke franke.dan
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-06-10 18:26 ---
Thus fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-10 20:08 ---
(In reply to comment #2)
This gives a proper locus:
And fails the regression test on gfortran.dg/data_array_5.f90 - this turns out
to be another variation of PR35849.
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-06-10 19:09 ---
The same ICE is triggered by
subroutine s
contains
SUBROUTINE s
END SUBROUTINE
end subroutine
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-06-10 19:43 ---
With '-Wall' one also gets:
$ gfortran-svn -Wall pr44491.f90
pr44491.f90:1.31:
character*2 escape /'1B'x/
1
Warning: BOZ literal at (1) is bitwise transferred non-integer
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-06-10 19:54 ---
This gives a proper locus:
Index: expr.c
===
--- expr.c (revision 160567)
+++ expr.c (working copy)
@@ -3203,7 +3203,7 @@ gfc_check_assign
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-09 19:41 ---
Subject: Bug 44359
Author: dfranke
Date: Wed Jun 9 19:40:58 2010
New Revision: 160505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160505
Log:
gcc/fortran/:
2010-06-09 Daniel Franke franke.dan
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-06-09 19:42 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-09 19:45 ---
I believe this is a dupe of PR33341.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-06-09 20:11 ---
Confirmed.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-06-09 21:19 ---
This should work (untested). However, ASYNCHRONOUS is F2003. Should one
introduce standard-specific checks? The whole function seems to be agnostic in
this respect?!
Index: interface.c
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-06-09 21:36 ---
Subject: Bug 44347
Author: dfranke
Date: Wed Jun 9 21:36:33 2010
New Revision: 160506
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160506
Log:
gcc/fortran/:
2010-06-09 Daniel Franke franke.dan
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-06-01 19:50 ---
Haven't checked with the testcase from this PR, but it should be handled by:
http://gcc.gnu.org/ml/fortran/2010-05/msg00229.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44359
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-06-01 20:43 ---
(In reply to comment #1)
http://gcc.gnu.org/ml/fortran/2010-05/msg00229.html
With this patch:
$ gfortran-svn -Wall pr44359.f90
[no warning]
$ gfortran-svn -Wall -fno-range-check pr44359.f90
pr44359.f90:3.34
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-06-01 20:53 ---
This was recently fixed.
*** This bug has been marked as a duplicate of 24978 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #38 from dfranke at gcc dot gnu dot org 2010-06-01 20:53
---
*** Bug 44351 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from dfranke at gcc dot gnu dot org 2010-06-01 21:02
---
(In reply to comment #18)
Expected:
a) Allow it as extension (-std=gnu or -std=legacy; especially, for -std=gnu
one
could consider a default-enabled warning)
b) Reject it for -std=f(95,2003,2008)
I'd vote
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-25 18:10 ---
Subject: Bug 34260
Author: dfranke
Date: Tue May 25 18:10:01 2010
New Revision: 159838
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159838
Log:
gcc/fortran/:
2010-05-25 Daniel Franke franke.dan
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-25 18:10
---
Subject: Bug 31346
Author: dfranke
Date: Tue May 25 18:10:01 2010
New Revision: 159838
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159838
Log:
gcc/fortran/:
2010-05-25 Daniel Franke franke.dan
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-25 18:10 ---
Subject: Bug 30668
Author: dfranke
Date: Tue May 25 18:10:01 2010
New Revision: 159838
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159838
Log:
gcc/fortran/:
2010-05-25 Daniel Franke franke.dan
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-25 18:11 ---
Commit in #5 catches the OPTIONAL argument if the testcase is compiled with
-fwhole-file. However, the warning regarding the inconsistent use of SUB is
still missing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-05-24 10:44
---
(In reply to comment #12)
With -fwhole-file, we get for the short testcase:
../pr36553/pr36553.f90:2.9:
print *, f( (/ 0.0, 1.0/) )
1
Error: The reference to function 'f' at (1) either needs
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-05-24 14:03
---
(In reply to comment #13)
Should we close this?
Yes, this is testcase gfortran.dg/whole_file_2.f90.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-05-23 15:37
---
Adjusted summary to better describe the problem.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-23 16:16 ---
Aren't PR32454 and PR34741 duplicates of this also?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-23 18:40 ---
(In reply to comment #5)
if others feel like me, the PR can be closed as WONTFIX.
If I understand it correctly, this is a request to warn about a valid
operation. Err, no. WONTFIX, at the least.
--
dfranke
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-23 19:06
---
Still an issue with gcc version 4.6.0 20100520 (experimental) (GCC)
Replaced ice-on-invalid with accepts-invalid keyword. The compiler is fine, the
produced binary isn't - there should be no binary.
Smaller
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39795
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-23 19:18 ---
(In reply to comment #1)
What do you want to do with this, Tobias?
This PR is still somewhat sparse on detail of the nature of the problem?!
--
dfranke at gcc dot gnu dot org changed:
What
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-23 22:29 ---
I think this is a technical dupe of PR27989?!
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-23 22:34
---
*** This bug has been marked as a duplicate of 31346 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-23 22:34 ---
*** Bug 36553 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-23 22:35
---
The dupe had accepts-invalid, adding it here. Pushing back from enhancement to
normal.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-20 09:36 ---
Confirmed. The problem occurs with allocatable components only, allocatable
variables are fine.
#0 0x0813d1cd in conformable_arrays (e1=0x8bff710, e2=0x8bc9a30) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-20 14:33 ---
A similar example:
$ cat conversion.f90
REAL(8), PARAMETER :: h = HUGE(0.0_8)
real*4 x
data x / h /
end
$ gfortran-svn -Wall conversion.f90
conversion.f90:1.28:
REAL(8), PARAMETER :: h = HUGE(0.0_8
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-20 16:25 ---
Patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00242.html
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-20 17:01 ---
A proper come-on-and-pick-up testcase would be nice ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-20 19:19 ---
*** Bug 39994 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-20 19:19 ---
(In reply to comment #2)
I believe that this is a duplicate of PR 31059.
Me too.
*** This bug has been marked as a duplicate of 31059 ***
--
dfranke at gcc dot gnu dot org changed:
What
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-20 21:49 ---
Subject: Bug 38407
Author: dfranke
Date: Thu May 20 21:49:07 2010
New Revision: 159641
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159641
Log:
gcc/fortran/:
2010-05-20 Daniel Franke franke.dan
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-20 21:53 ---
It would be nice if -Wunused-dummy-argument would be split from
-Wunused-variable and also be moved from -Wall to -Wextra to make
it consistent with C, where -Wunused-parameter plays this role.
Mostly done. We
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-19 11:44 ---
Subject: Bug 34505
Author: dfranke
Date: Wed May 19 11:43:53 2010
New Revision: 159558
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159558
Log:
gcc/fortran/:
2010-05-19 Daniel Franke franke.dan
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-19 11:46 ---
Fixed in trunk. Closing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34505
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-19 12:55 ---
Subject: Bug 38404
Author: dfranke
Date: Wed May 19 12:55:26 2010
New Revision: 159561
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159561
Log:
gcc/fortran/:
2010-05-19 Daniel Franke franke.dan
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-19 12:56 ---
Fixed in trunk. Closing.
Thanks for the report!
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-19 12:57 ---
(In reply to comment #4)
Fixed in trunk. Closing
Second try.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-19 13:07 ---
Subject: Bug 42360
Author: dfranke
Date: Wed May 19 13:07:25 2010
New Revision: 159562
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159562
Log:
gcc/fortran/:
2010-05-19 Daniel Franke franke.dan
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-19 13:28 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from dfranke at gcc dot gnu dot org 2010-05-19 14:43
---
No more ICE, removed keyword.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-19 16:29 ---
Not related to types - this is more about namespace cleanup. Reduced testcase:
PROGRAM Main
USE, INTRINSIC :: iso_c_binding
CALL C_F_POINTER(rws, xrws)
XXX ! any error will do
END PROGRAM Main
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-19 16:36 ---
Subject: Bug 44055
Author: dfranke
Date: Wed May 19 16:35:34 2010
New Revision: 159586
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159586
Log:
gcc/fortran/:
2010-05-19 Daniel Franke franke.dan
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-19 16:57 ---
$ gfortran-4.5 pr38849.f90
pr38849.f90: In function 'MAIN__':
pr38849.f90:9:0: internal compiler error: in gimplify_expr, at gimplify.c:7346
$ gfortran-svn pr38849.f90
gimplification failed:
chararr addr_expr
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-19 17:34 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-19 17:53 ---
(In reply to comment #2)
I dedicate it to the run time test.
Test: Place program and subroutine in different files, compile and run them.
NAG f95 -C=all shows then:
Same as PR27989.
*** This bug has been
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-19 17:53 ---
*** Bug 30939 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 21:17 ---
If
print *, (foo())
is changed to
print *, foo()
one gets:
$ gfortran-svn pr41859.f90
pr41859.f90:17.19:
print *, foo() ! -- ICE here!
1
Error: Data transfer element at (1) cannot
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 21:30 ---
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 21:54 ---
Comment #3 is somewhat hard to parse. Once more with this reduced testcase:
TYPE :: ptype
character, pointer, dimension(:) :: x = null()
END TYPE
TYPE(ptype) :: p
print *, (p
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 22:09 ---
Reduced testcase:
type t
real :: a(3)
end type t
contains
function func(x)
type(t), target :: x(:)
real, dimension(:), pointer :: func
func = x%a(1)
end function func
end
--
dfranke
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 22:22 ---
Roughly the same testcase, same backtrace.
*** This bug has been marked as a duplicate of 34640 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-05-18 22:22
---
*** Bug 42851 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-18 22:26
---
As commented multiple times in PR34640, given the similarity of the testcase,
the identical backtrace and the same assignee ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-05-18 22:28
---
(In reply to comment #11)
As commented multiple times in PR34640, given the similarity of the testcase,
the identical backtrace and the same assignee ...
*** This bug has been marked as a duplicate of 34640
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-05-18 22:28
---
*** Bug 38471 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-05-18 22:30
---
The dupes PR38471 and PR42851 have more testcases, the former an equally
lengthy discussion as this PR.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from dfranke at gcc dot gnu dot org 2010-05-18 22:36
---
(In reply to comment #17)
Fixed on the trunk (4.6). Planned to be committed also to GCC 4.5.1.
Patch was applied to trunk about 6 weeks ago - how are the backporting plans?
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-18 22:38 ---
Paul, is there anything left to do here or can this PR be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43266
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 22:44 ---
(In reply to comment #2)
OK for trunk with the usual embellishments of ChangeLogs and testcase?
Yes, if you have an example for EXPR_FUNCTION - otherwise I would claim that
EXPR_VARIABLE is enough.
Paul, any
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-17 21:10 ---
The PR(In reply to comment #3)
I think the ICE has been fixed by the recent constructor work by Daniel.
That was PR24978. Given that this PR was opened against 4.1 in 2005 and a
simple workaround exists (fix your
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-17 22:23 ---
(In reply to comment #4)
We have complete control of whether to print the negative sign with
-fno-sign-zero. I am tempted to say this is a no-never-mind situation.
Using the testcase shown in comment #3
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-17 23:49 ---
(In reply to comment #6)
I already explained what dot_product is doing in comment #2.
dot_product(a,b) is equivalent to
s = 0
do n = 1, m
s = s + a(n) * b(n)
end do
(return s
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-16 20:01 ---
Subject: Bug 35779
Author: dfranke
Date: Sun May 16 20:01:06 2010
New Revision: 159465
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159465
Log:
gcc/fortran/:
2010-05-16 Daniel Franke franke.dan
1 - 100 of 1155 matches
Mail list logo
