[Bug fortran/52153] REAL128 gives extended precision, not quad precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 Alexander Vogt changed: What|Removed |Added CC||a.vogt at fulguritus dot com --- Comment #11 from Alexander Vogt --- This is issue is still present on 6.1.1. Any chance that this gets fixed? Anything I could do?
[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 Alexander Vogt a.vogt at fulguritus dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Alexander Vogt a.vogt at fulguritus dot com --- I don't think that is necessary... Thanks anyway!
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 Alexander Vogt a.vogt at fulguritus dot com changed: What|Removed |Added Attachment #35263|0 |1 is obsolete|| --- Comment #11 from Alexander Vogt a.vogt at fulguritus dot com --- Created attachment 35269 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35269action=edit Improved wording
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684
--- Comment #8 from Alexander Vogt a.vogt at fulguritus dot com ---
I think this happens in io/transfer.c:
413 void *
414 read_block_form (st_parameter_dt *dtp, int * nbytes)
415 {
...
419 if (!is_stream_io (dtp))
420 {
421 if (dtp-u.p.current_unit-bytes_left (gfc_offset) *nbytes)
422 {
...
430 if (unlikely (dtp-u.p.current_unit-pad_status ==
PAD_NO)
431!is_internal_unit (dtp))
432 {
433 /* Not enough data left. */
434 generate_error (dtp-common, LIBERROR_EOR, NULL);
435 return NULL;
436 }
437 }
...
I'm a little confused, though... Aren't we writing to an internal unit here?
This case seems not to be covered.
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 --- Comment #9 from Alexander Vogt a.vogt at fulguritus dot com --- Then, it would be as simple as passing generate_error the message instead of NULL.
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 --- Comment #6 from Alexander Vogt a.vogt at fulguritus dot com --- Fair enough... I have no experience in coding for GCC. Could you give me a hint where (which file) to start? I would propose a message like At line 5 of file test.F90 Fortran runtime error: End of record (number of characters to be written exceeds the length of the record)
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 --- Comment #10 from Alexander Vogt a.vogt at fulguritus dot com --- Created attachment 35263 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35263action=edit Patch for more specific error messages This is a suggestion for more verbose error messages... What do you think?
[Bug fortran/65684] New: Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 Bug ID: 65684 Summary: Wrong error message when writing to a string Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.vogt at fulguritus dot com gfortran gives the wrong output when writing to a string that is too short: Compiling and running this snippet program test implicit none character(2) :: str write(str,*) 100 print *, str end program results in At line 5 of file test.F90 Fortran runtime error: End of record ifort, on the other hand, gives the correct error message: forrtl: severe (66): output statement overflows record, unit -5, file Internal List-Directed Write Could the gfortran error message be adjusted?
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 --- Comment #1 from Alexander Vogt a.vogt at fulguritus dot com --- This is motivated by this post on Stack Overflow: https://stackoverflow.com/questions/29489388/fortran-end-of-record-error-when-saving-a-variable/29490374#29490374
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 --- Comment #3 from Alexander Vogt a.vogt at fulguritus dot com --- OK, I agree that the behavior is Standard conforming... Thanks for the clarification! Still, the error message issued is not really helpful if one is unfamiliar with the Standard. Maybe it could be improved for more guidance (point towards the overflow and maybe the Standard).
[Bug fortran/59765] [4.9/5 Regression] [OOP] ICE on valid with finalizable array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59765 Alexander Vogt a.vogt at fulguritus dot com changed: What|Removed |Added CC||a.vogt at fulguritus dot com --- Comment #12 from Alexander Vogt a.vogt at fulguritus dot com --- Is there any update on this? This regression currently prohibits moving to 4.9.x for my code :( Thanks a lot!
[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 --- Comment #9 from Alexander Vogt a.vogt at fulguritus dot com --- Thanks a lot!
[Bug fortran/60509] [OOP] Passing an array of derived type gives wrong boundaries when using 'class'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60509 --- Comment #2 from Alexander Vogt a.vogt at fulguritus dot com --- Sorry, I did not see the other bug report... I agree - it is a duplicate!
[Bug fortran/60509] New: Passing an array of derived type gives wrong boundaries when using 'class'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60509 Bug ID: 60509 Summary: Passing an array of derived type gives wrong boundaries when using 'class' Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.vogt at fulguritus dot com Created attachment 32340 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32340action=edit Sample code When passing an array of derived type variables to a procedure, I get wrong the wrong results from lbound and ubound when the array is declared as class(myType). Using type(myType) is working as expected. An example is attached. I'm using: gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 --- Comment #1 from Alexander Vogt a.vogt at fulguritus dot com --- Created attachment 32243 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32243action=edit Sample code
[Bug fortran/60392] New: Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 Bug ID: 60392 Summary: Problem with TRANSPOSE and CONTIGUOUS dummy arguments Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.vogt at fulguritus dot com When I use the TRANSPOSE intrinsic for function calls where the CONTIGUOUS statement is set I get wrong results. In the attached sample code I have two subroutines that multiply a 3x3 matrix with another one. One subroutine has the contiguous attribute set for the input, the other one does not. Using gfortran, I get a different result from both calls when the TRANSPOSE intrinsic is used: Normal: 0. Transposed: 6.9428321395983108 Ifort (14.0.1) shows no deviations. I am using gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
[Bug fortran/60286] INQUIRE reports STDOUT as not writable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60286 --- Comment #5 from Alexander Vogt a.vogt at fulguritus dot com --- Thanks for fixing it *that* fast (I'm impressed)!
[Bug fortran/60286] New: INQUIRE reports STDOUT as not writable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60286 Bug ID: 60286 Summary: INQUIRE reports STDOUT as not writable Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.vogt at fulguritus dot com Created attachment 32178 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32178action=edit Minumum Example The INQUIRE statement reports STDOUT as not writable: Compiling the minumum example attached results in: ./a.out writable? NO with gfortran (4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)), and into ./a.out writable? YES using ifort (13.1.3). This was also discussed on the mailing list in 2009 (http://gcc.gnu.org/ml/fortran/2009-03/msg00102.html), but I couldn't find any corresponding bug report. gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ifort -V Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.3.192 Build 20130607 Copyright (C) 1985-2013 Intel Corporation. All rights reserved.
[Bug fortran/60286] INQUIRE reports STDOUT as not writable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60286 --- Comment #1 from Alexander Vogt a.vogt at fulguritus dot com --- I just found out that the same holds true for STDERR...
