[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #22 from Janne Blomqvist 2011-02-24 15:08:00 UTC --- (In reply to comment #21) > (In reply to comment #20) > > + if (q == EOF) > > > > Does this always work? We have in "static inline int fbuf_getc (gfc_unit * > > u)": > >

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #24 from Janne Blomqvist 2011-02-24 21:51:41 UTC --- Author: jb Date: Thu Feb 24 21:51:39 2011 New Revision: 170478 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170478 Log: PR 47802 Use strftime for CTIME and FDATE intrinsic

[Bug fortran/47928] New: Gfortran intrinsics documentation paragraph ordering illogical

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928 Summary: Gfortran intrinsics documentation paragraph ordering illogical Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Co

[Bug libfortran/47938] New: libgfortran symbol version node bumped unnecessarily

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47938 Summary: libgfortran symbol version node bumped unnecessarily Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assi

[Bug libfortran/47938] libgfortran symbol version node bumped unnecessarily

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47938 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #15

[Bug libfortran/47972] error.c:158:7: warning: return makes pointer from integer without a cast

||2011.03.03 17:58:32 CC||jb at gcc dot gnu.org Ever Confirmed|0 |1 Severity|normal |trivial --- Comment #2 from Janne Blomqvist 2011-03-03 17:58:32 UTC --- >From the c

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #31 from Janne Blomqvist 2011-03-04 17:37:23 UTC --- Author: jb Date: Fri Mar 4 17:37:11 2011 New Revision: 170679 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170679 Log: PR 47802 Update doc for CTIME and FDATE intrinsics

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #32 from Janne Blomqvist 2011-03-04 17:52:43 UTC --- Author: jb Date: Fri Mar 4 17:52:10 2011 New Revision: 170680 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170680 Log: PR 47802 Hack to work around draft POSIX localtime_

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #33 from Janne Blomqvist 2011-03-04 19:07:53 UTC --- Author: jb Date: Fri Mar 4 19:07:49 2011 New Revision: 170683 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170683 Log: PR 47802 Use builtins to check localtime_r return t

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #34 from Janne Blomqvist 2011-03-04 19:15:34 UTC --- (In reply to comment #30) > On Fri, 25 Feb 2011, burnus at gcc dot gnu.org wrote: > > > Please shout loudly if there you still encounter a build failure! > > > > > > TO BE DONE:

[Bug fortran/56919] [4.7/4.8 Regression] Wrong result for SYSTEM_CLOCK on Cygwin

||2013-05-15 Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] Wrong |Wrong result for|result for SYSTEM_CLOCK on |SYSTEM_CLOCK on

[Bug fortran/40958] module files too large

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Janne Blomqvist changed: What|Removed |Added Status|WAITING |REOPENED --- Comment #13 from Janne Blo

[Bug fortran/35385] gfortran does not support the COCO preprocessor

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35385 --- Comment #2 from Janne Blomqvist 2011-08-27 11:29:16 UTC --- In case anyone digs this PR up, on 2011-05-10 part 3 of the Fortran standard (that is, COCO) was officially withdrawn. See ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1874.txt .

[Bug fortran/50937] STAT option with ALLOCATE statement on large arrays

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937 --- Comment #3 from Janne Blomqvist 2011-10-31 18:24:14 UTC --- >From the metadata, it seems you're using version 4.4.3, where the overflow check when calculating the size to allocate was a bit stupid. Basically it did the calculation, and if the

[Bug fortran/50937] STAT option with ALLOCATE statement on large arrays

||jb at gcc dot gnu.org Resolution||INVALID --- Comment #5 from Janne Blomqvist 2011-10-31 19:01:59 UTC --- (In reply to comment #4) > I've now tested the same program on a 64-bit CentOs machine > with 16-Gb RAM, but was

[Bug fortran/50937] STAT option with ALLOCATE statement on large arrays

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937 --- Comment #10 from Janne Blomqvist 2011-11-01 07:55:06 UTC --- (In reply to comment #8) > I indeed do not know everything about the OS and what it does when I > "allocate" > an array. But that's exactly the purpose of a programming language li

[Bug fortran/46686] Improve backtracing (unwinding) on non-glibc targets

||2011-11-01 CC||jb at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Summary|Improve backtracing |Improve backtracing

[Bug libfortran/45723] opening /dev/null for appending writes

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45723 --- Comment #7 from Janne Blomqvist 2011-11-07 14:32:56 UTC --- Author: jb Date: Mon Nov 7 14:32:50 2011 New Revision: 181085 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181085 Log: Revert previous fix for PR 45723. libgfortran Chang

[Bug libfortran/45723] opening /dev/null for appending writes

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45723 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #8

[Bug other/42980] GCC parallel "make install" failures

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #17

[Bug libfortran/50016] [4.7 Regression] Drastic I/O performance regression on Windows

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50016 --- Comment #19 from Janne Blomqvist 2011-11-09 15:46:20 UTC --- Author: jb Date: Wed Nov 9 15:46:15 2011 New Revision: 181207 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181207 Log: PR 50016 Slow I/O on MingW due to _commit frontend

[Bug fortran/46686] Improve backtracing (unwinding) on non-glibc targets

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46686 --- Comment #4 from Janne Blomqvist 2011-11-09 16:04:47 UTC --- Author: jb Date: Wed Nov 9 16:04:42 2011 New Revision: 181209 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181209 Log: PR 46686 Implement backtrace with _Unwind_Backtrace

[Bug fortran/46686] Improve backtracing (unwinding) on non-glibc targets

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46686 --- Comment #5 from Janne Blomqvist 2011-11-09 17:52:19 UTC --- Author: jb Date: Wed Nov 9 17:52:11 2011 New Revision: 181217 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181217 Log: PR 46686 Fix incorrect comment. 2011-11-09 Janne B

[Bug fortran/46686] Improve backtracing (unwinding) on non-glibc targets

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46686 --- Comment #8 from Janne Blomqvist 2011-11-09 19:38:49 UTC --- (In reply to comment #7) > (In reply to comment #6) > > TODO: For Windows, one should be able to make use of SymFromAddr + > > SymGetLineFromAddr64 + IMAGEHLP_LINE64 to obtain the sy

[Bug fortran/51090] libgfortran main.c missing NULL check on return value from getenv()

||2011-11-11 CC||jb at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Janne

[Bug fortran/51090] libgfortran main.c missing NULL check on return value from getenv()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51090 --- Comment #3 from Janne Blomqvist 2011-11-11 16:31:59 UTC --- Author: jb Date: Fri Nov 11 16:31:47 2011 New Revision: 181288 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181288 Log: PR 51090 Check that getenv result != NULL before pro

[Bug fortran/51090] libgfortran main.c missing NULL check on return value from getenv()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51090 --- Comment #4 from Janne Blomqvist 2011-11-11 16:38:24 UTC --- Author: jb Date: Fri Nov 11 16:38:11 2011 New Revision: 181290 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181290 Log: PR 51090 Fix r181288 to conform to GNU style Modifi

[Bug fortran/51090] libgfortran main.c missing NULL check on return value from getenv()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51090 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010 --- Comment #12 from Janne Blomqvist 2012-05-05 07:59:28 UTC --- Author: jb Date: Sat May 5 07:59:22 2012 New Revision: 187191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187191 Log: PR 49010,24518 MOD/MODULO fixes. gcc/fortran: 201

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24518 --- Comment #25 from Janne Blomqvist 2012-05-05 07:59:30 UTC --- Author: jb Date: Sat May 5 07:59:22 2012 New Revision: 187191 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187191 Log: PR 49010,24518 MOD/MODULO fixes. gcc/fortran: 201

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug middle-end/53267] New: Constant fold BUILT_IN_FMOD

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53267 Bug #: 53267 Summary: Constant fold BUILT_IN_FMOD Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 --- Comment #9 from Janne Blomqvist 2012-05-14 19:39:27 UTC --- Author: jb Date: Mon May 14 19:39:23 2012 New Revision: 187478 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187478 Log: PR 52428 Range checking when reading integer values.

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 --- Comment #2 from Janne Blomqvist 2012-05-18 06:43:08 UTC --- AFAICS, this is an intentional change in behavior. When I proposed making backtracing enabled by default, there was some objections to the initial patch on the grounds that the backt

[Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 --- Comment #4 from Janne Blomqvist 2012-05-18 14:32:54 UTC --- (In reply to comment #3) > (In reply to comment #2) > > AFAICS, this is an intentional change in behavior. When I proposed making > > backtracing enabled by default, there was some o

[Bug fortran/53456] Add time support for VxWorks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #2

[Bug fortran/53456] Add time support for VxWorks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |NEW URL|

[Bug fortran/53456] Add time support for VxWorks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456 --- Comment #7 from Janne Blomqvist 2012-05-23 18:52:52 UTC --- Author: jb Date: Wed May 23 18:52:47 2012 New Revision: 187806 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187806 Log: PR 53456 clock_gettime fallback for gf_gettime 2012

[Bug fortran/53456] Add time support for VxWorks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456 --- Comment #9 from Janne Blomqvist 2012-05-24 20:19:46 UTC --- Author: jb Date: Thu May 24 20:19:37 2012 New Revision: 187846 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187846 Log: PR 53456 CPU timing fallback using clock_gettime. 2

[Bug fortran/53456] Add time support for VxWorks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456 --- Comment #10 from Janne Blomqvist 2012-06-04 19:13:54 UTC --- Author: jb Date: Mon Jun 4 19:13:49 2012 New Revision: 188201 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188201 Log: PR 53456 Fix typo in gf_cputime. 2012-06-04 Rober

[Bug fortran/53456] Add time support for VxWorks

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456 --- Comment #11 from Janne Blomqvist 2012-06-04 19:15:25 UTC --- Author: jb Date: Mon Jun 4 19:15:21 2012 New Revision: 188202 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188202 Log: PR 53456 Fix incorrect ChangeLog entry. Modified:

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

||jb at gcc dot gnu.org Resolution||WONTFIX --- Comment #5 from Janne Blomqvist 2012-06-06 07:48:30 UTC --- Based on the discussion here, 4.7+ already does what the reporter wants. For 4.6 and older releases, as it isn't a regressi

[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files

||http://gcc.gnu.org/ml/gcc-p ||atches/2012-06/msg01378.htm ||l AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org

[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654 --- Comment #8 from Janne Blomqvist 2012-06-21 18:47:06 UTC --- Author: jb Date: Thu Jun 21 18:47:01 2012 New Revision: 188858 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188858 Log: PR 39654 FTELL intrinsic function return type. fron

[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|

[Bug libfortran/51119] MATMUL slow for large matrices

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #7 from Janne Blomqvist 2012-06-28 12:15:05 UTC --- (In reply to comment #6) > Janne, have you had a chance to look at this ? For larger matrices MATMMUL is > really slow. Anything that includes even the most basic blocking scheme sho

[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53796 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #13

[Bug libfortran/30162] I/O with named pipes does not work

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #23 from Janne Blomqvist 2012-08-03 19:45:10 UTC --- (In reply to comment #22) > Revision 180701 removed all checks for special files in > unit.c:unit_truncate(). Yes. As the email message introducing the patch explained, special fi

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522 --- Comment #5 from Janne Blomqvist 2012-02-02 19:08:19 UTC --- Sorry, I'm unable to reproduce the ICE with today's trunk. I tried to testcase in comment #4 with and without the fixes from #3 as well as the original testcase.

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522 --- Comment #7 from Janne Blomqvist 2012-02-03 22:36:13 UTC --- (In reply to comment #6) > If I try the example of comment 4 with the line break before "&" undone and > using the newest 4.7 trunk (clean build), I see in valgrind: > > ==14154== I

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522 --- Comment #9 from Janne Blomqvist 2012-02-05 21:04:18 UTC --- So the complete valgrind error message I get (with the comment #4 testcase fixed per Tobias instructions in comment #6) is: ==14281== Invalid read of size 4 ==14281==at 0x528B66

[Bug fortran/25020] NAG extension: module F90_UNIX providing access to UNIX functions (abort ...)

||jb at gcc dot gnu.org Resolution||WONTFIX --- Comment #5 from Janne Blomqvist 2012-02-07 10:11:56 UTC --- Closing as wontfix. - The PR hasn't seen any activity in almost 5 years - GFortran nowadays has ISO_C_BINDING support, making it

[Bug libfortran/52434] New: Insufficient number of digits in floating point formatting

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52434 Bug #: 52434 Summary: Insufficient number of digits in floating point formatting Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED

[Bug libfortran/52434] Insufficient number of digits in floating point formatting

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52434 Janne Blomqvist changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org

[Bug libfortran/52434] Insufficient number of digits in floating point formatting

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52434 --- Comment #2 from Janne Blomqvist 2012-03-15 15:14:48 UTC --- Author: jb Date: Thu Mar 15 15:14:43 2012 New Revision: 185433 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185433 Log: 2012-03-15 Janne Blomqvist PR libfortran

[Bug libfortran/48878] Default I/O rounding on output should be round to nearest

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48878 --- Comment #2 from Janne Blomqvist 2012-03-15 15:14:49 UTC --- Author: jb Date: Thu Mar 15 15:14:43 2012 New Revision: 185433 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185433 Log: 2012-03-15 Janne Blomqvist PR libfortran

[Bug libfortran/38199] missed optimization: I/O performance

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #15 from Janne Blomqvist 2012-03-15 15:14:51 UTC --- Author: jb Date: Thu Mar 15 15:14:43 2012 New Revision: 185433 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185433 Log: 2012-03-15 Janne Blomqvist PR libfortra

[Bug libfortran/48878] Default I/O rounding on output should be round to nearest

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48878 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug libfortran/52434] Insufficient number of digits in floating point formatting

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52434 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug libfortran/52608] [4.8 Regression] The test FM110 of the NIST test suite fails since revision 185433

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52608 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug libfortran/52608] [4.8 Regression] The test FM110 of the NIST test suite fails since revision 185433

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52608 --- Comment #2 from Janne Blomqvist 2012-03-17 17:19:54 UTC --- Author: jb Date: Sat Mar 17 17:19:49 2012 New Revision: 185486 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185486 Log: PR libfortran/52608 Move the removal of initial zero

[Bug libfortran/52608] [4.8 Regression] The test FM110 of the NIST test suite fails since revision 185433

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52608 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug libfortran/52608] [4.8 Regression] The test FM110 of the NIST test suite fails since revision 185433

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52608 --- Comment #4 from Janne Blomqvist 2012-03-17 18:20:47 UTC --- Author: jb Date: Sat Mar 17 18:20:34 2012 New Revision: 185487 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185487 Log: 2012-03-17 Janne Blomqvist PR libfortran

[Bug libfortran/52608] [4.8 Regression] The test FM110 of the NIST test suite fails since revision 185433

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52608 --- Comment #5 from Janne Blomqvist 2012-03-17 18:24:15 UTC --- Author: jb Date: Sat Mar 17 18:24:09 2012 New Revision: 185488 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185488 Log: PR libfortran/52608 Add dejagnu directive to testcas

[Bug fortran/52606] Confusing diagnostics for long identifiers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #3

[Bug fortran/52606] Confusing diagnostics for long identifiers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 --- Comment #5 from Janne Blomqvist 2012-03-20 10:27:33 UTC --- (In reply to comment #4) > Indeed, one can construct examples which exceed the length: Namely module > procedures or module variables. The problem is that GFC_MAX_MANGLED_SYMBOL_LEN

[Bug fortran/52606] Confusing diagnostics for long identifiers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 --- Comment #7 from Janne Blomqvist 2012-03-21 08:48:38 UTC --- (In reply to comment #6) > (In reply to comment #5) > > What was the motivation for this hashing scheme, BTW? Linkers already > > support > > 1) long symbol names (I read somewhere

[Bug libfortran/51646] Make libgfortran compile on Android

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51646 --- Comment #5 from Janne Blomqvist 2012-04-18 08:31:47 UTC --- Another build problem at http://stackoverflow.com/questions/10202966/android-ndk-fortran-build-of-lapack-problems-with-unresolved-sincos

[Bug target/52790] Problems using x86_64-w64-mingw-w32-gfortran with mcmodel=large and medium

|UNCONFIRMED |NEW Last reconfirmed||2012-04-19 Component|fortran |target CC||jb at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Janne

[Bug fortran/48438] Several gfortran tests FAIL on Tru64 UNIX

||jb at gcc dot gnu.org Resolution||WONTFIX --- Comment #3 from Janne Blomqvist 2012-04-19 14:14:11 UTC --- AFAIU, for the 4.8 release Rainer has removed support for the alpha*-dec*-osf* target, hence closing this PR as wontfix.

[Bug fortran/40766] this fortran program is too slow

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #22

[Bug libfortran/53051] I/O: Support reading floating-point numbers which use "Q" for the exponent

||2012-04-20 CC||jb at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Janne Blomqvist 2012-04-20 08:21:05 UTC --- The argument against supporting this, I suppose, is that we never generate a &quo

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

||2012-04-24 CC||jb at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Janne Blomqvist 2012-04-24 06:37:16 UTC --- Confirmed. I agree that at runtime we should allow full use of the range that the

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 Janne Blomqvist changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 Janne Blomqvist changed: What|Removed |Added Attachment #27228|0 |1 is obsolete|

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 --- Comment #5 from Janne Blomqvist 2012-04-24 21:44:06 UTC --- See also PR 36515

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 --- Comment #7 from Janne Blomqvist 2012-04-25 06:11:58 UTC --- (In reply to comment #6) > I respectfully disagree. The Fortran model is/was developed over many years > with many knowledgeable people investing time into it of good reasons. Some

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52428 --- Comment #8 from Janne Blomqvist 2012-04-25 21:15:57 UTC --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01637.html

[Bug libfortran/59108] ACTION='READ' is using O_CREAT

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59108 --- Comment #2 from Janne Blomqvist --- Author: jb Date: Fri Nov 15 22:00:36 2013 New Revision: 204864 URL: http://gcc.gnu.org/viewcvs?rev=204864&root=gcc&view=rev Log: When file status is unknown, don't set O_CREAT when opening read-only. 2013-

[Bug libfortran/59108] ACTION='READ' is using O_CREAT

||jb at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Janne Blomqvist --- Closing, fixed on trunk (4.9).

[Bug libfortran/59419] [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419 --- Comment #4 from Janne Blomqvist --- Indeed I suspect we have many cases in the IO library where stuff fails, leaks memory, or leaves stuff in an inconsistent state when IOSTAT= is present. I think that we should modify generate_error() to no

[Bug libfortran/51119] New: MATMUL slow for large matrices

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 Bug #: 51119 Summary: MATMUL slow for large matrices Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3

[Bug libfortran/51119] MATMUL slow for large matrices

||2011-11-14 AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Janne Blomqvist 2011-11-14 06:49:11 UTC --- Assigning to myself. I have a

[Bug libfortran/51119] MATMUL slow for large matrices

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #5 from Janne Blomqvist 2011-11-15 15:47:54 UTC --- (In reply to comment #3) > I believe it would be more important to have actually highly efficient > (inlined) implementations for very small matrices. There's already PR 37131 for t

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197 --- Comment #3 from Janne Blomqvist 2011-11-18 06:41:15 UTC --- (In reply to comment #2) > Well, thanks for pointing out I was not precise enough. > While "reducing" the problem, I forgot that the difference > lies in where the line > > > > Floa

[Bug libfortran/50016] [4.7 Regression] Drastic I/O performance regression on Windows

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50016 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug fortran/46686] Improve backtracing (unwinding) on non-glibc targets

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46686 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|jb at gcc dot

[Bug fortran/47494] .MOD files: Consider removing the time stamp

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47494 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug fortran/25708] Module loading is not good at all

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 --- Comment #19 from Janne Blomqvist 2011-12-01 14:12:45 UTC --- Author: jb Date: Thu Dec 1 14:12:37 2011 New Revision: 181879 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181879 Log: PR 25708 Avoid seeking when parsing strings and whe

[Bug fortran/51591] Strange output from STOP statement in OpenMP region

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51591 --- Comment #2 from Janne Blomqvist 2011-12-17 11:27:40 UTC --- Looks like some kind of race condition.. E.g. what about: STOP calls exit(), which leads to the library destructor being called, which calls close_units(), which closes each open u

[Bug libfortran/51646] Make libgfortran compile on Android - without S_IREAD

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51646 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug libfortran/51646] Make libgfortran compile on Android - without S_IREAD

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51646 --- Comment #2 from Janne Blomqvist 2011-12-21 10:21:32 UTC --- (In reply to comment #1) > Good catch! I suppose it's possible that all targets we support have the POSIX > flags, but since we're in stage 3 I think it's fine to play it safe and do

[Bug libfortran/51646] Make libgfortran compile on Android - without S_IREAD

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51646 --- Comment #3 from Janne Blomqvist 2011-12-22 20:44:44 UTC --- Author: jb Date: Thu Dec 22 20:44:32 2011 New Revision: 182638 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182638 Log: PR 51646 Use POSIX mode flags in open() argument. 2

[Bug libfortran/51646] Make libgfortran compile on Android

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51646 Janne Blomqvist changed: What|Removed |Added Status|NEW |WAITING Summary|Make libgfor

[Bug libstdc++/51701] New: Remove reference to Henry Suter's RWLock from documentation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51701 Bug #: 51701 Summary: Remove reference to Henry Suter's RWLock from documentation Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED

[Bug fortran/51802] New: Duplicate mangling for OOP symbols

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51802 Bug #: 51802 Summary: Duplicate mangling for OOP symbols Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority:

[Bug libfortran/51803] gfortran getcwd at startup

||2012-01-10 AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Janne Blomqvist 2012-01-10 07:21:30 UTC --- Confirmed. I'll fix it fo

[Bug fortran/51808] New: Improve handling of ISO_C_BINDING binding names

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51808 Bug #: 51808 Summary: Improve handling of ISO_C_BINDING binding names Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement

<    1   2   3   4   5   6   7   >