http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #44 from Hans-Werner Boschmann 2011-01-03 12:55:53 UTC ---
I've run my project on R168414, there are no error messages so far. Thank you
all for making this fix, this bug has bothered me for a long time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
--- Comment #23 from Hans-Werner Boschmann 2011-08-26 10:05:32 UTC ---
Is there any chance that gfortran 4.7.0 will support allocatable character
lengths? Using fortran for text processing has been painful since time
immemorial and this little fea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
--- Comment #25 from Hans-Werner Boschmann 2011-08-26 19:44:10 UTC ---
(In reply to comment #24)
> Looking at your code in comment #17, one can easily find
> a trivial change to make it work.
Thank you, I was not aware of this. I was always wond
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059
Summary: [OOP] ICE in in gfc_conv_component_ref: character
function of extended type
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059
--- Comment #2 from Hans-Werner Boschmann 2011-03-10 14:06:06 UTC ---
I have removed this character function from my project and found the same ICE
message with other, non character-valued functions of extended types. So it
seems to be a more gene
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
Summary: mio_component_ref(): Component not found when mixing
f90 and f03 in large projects
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #9 from Hans-Werner Boschmann 2010-09-29 11:49:11 UTC ---
My makefile is now:
FC=gfortran
FFLAGS=-ffree-form -ffree-line-length-0 -I. -L.
all: common.o common_module.mod arguments.o arguments_module.mod kinds.o
kinds.mod
kinds.o kind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #11 from Hans-Werner Boschmann 2010-09-30 07:37:46 UTC ---
So it works with 4.6.0 20100924, but it still doesn't work with 4.6.0 20100921.
Unfortunately, I cannot use the latest revision, until bug 45746 is fixed.
Plus, I assume that t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #13 from Hans-Werner Boschmann 2010-09-30 13:03:09 UTC ---
(In reply to comment #12)
> Actually, I am confused: From that comment it sounds as if 20100921 does not
> have the bug 45746 - but it has been reported using 20100921 and a co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #15 from Hans-Werner Boschmann 2010-10-01 06:52:14 UTC ---
Thank you, now I understand the difference. The correct invocation does not
supply any new information.
Revision 20100928 compiles my code, so it's fine for me now. But I have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #16 from Hans-Werner Boschmann 2010-10-01 07:57:44 UTC ---
I have checked the f90/f03 combination again, there DEFINITELY IS A CORRELATION
between mixing dialects and the error. Using -std=f2003 also fixed the problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #22 from Hans-Werner Boschmann 2010-10-24 10:17:00 UTC ---
Yes, I still get the error with later revisions. I am using an amd64 machine
with open SuSE 11.2. Here are some updates of my statements:
* All means like renaming files or us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #30 from Hans-Werner Boschmann 2010-10-26 15:27:27 UTC ---
I've realized today, that the sample code is actually invalid. If you look at
lines 488 and 681 in arguments.f03, you'll see:
subroutine
argument_initialize(this,arg_list,shor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46196
Summary: [OOP] gfortran compiles invalid generic TBP: dummy
arguments are type compatible
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827
--- Comment #31 from Hans-Werner Boschmann 2010-10-27 09:35:07 UTC ---
I've posted the generic issue as Bug 46196
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46210
Summary: segfault when using large arrays with -fopenmp
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46210
--- Comment #1 from Hans-Werner Boschmann 2010-10-28 12:23:15 UTC ---
(In reply to comment #0)
Sorry, I was to quick. The reason is already given in the valgrind output. The
stack size is to small. So it's neither gcc's fault nor openmp's fault.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562
Summary: [OOP] ICE at invalid code: assigning value to function
of polymorphic object
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630
Summary: [OOP] ICE on obsolescent assumed length deferred type
bound character function
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630
--- Comment #2 from Hans-Werner Boschmann 2011-07-04 19:29:50 UTC ---
"C417: A function name shall not be declared with an asterisk type-param-value
unless it is of type CHAR- ACTER and is the name of the result of an external
function or the name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638
Summary: [OOP] length parameter is ignored when overriding type
bound character functions with constant length.
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: nor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
Hans-Werner Boschmann changed:
What|Removed |Added
CC||boschmann at tp1 dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
--- Comment #17 from Hans-Werner Boschmann 2011-07-12 15:00:22 UTC ---
This sounds like there is still a lot of work to do in this character issue.
Has anyone ever managed to allocate such strings dynamically? In
(In reply to comment #15)
> char
23 matches
Mail list logo
