https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65200
--- Comment #7 from Janne Blomqvist ---
Author: jb
Date: Wed Mar 11 21:34:22 2015
New Revision: 221361
URL: https://gcc.gnu.org/viewcvs?rev=221361&root=gcc&view=rev
Log:
PR 65200 Handle EPERM in addition to EACCES.
gcc/fortran ChangeLog:
2015-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65200
Janne Blomqvist changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
As of the GCC-5 release there is a new __builtin_mul_overflow builtin
(https://gcc.gnu.org/gcc-5/changes.html ). GFortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
libgfortran uses (stack allocated) arrays of size PATH_MAX or smaller in many
places, when creating a temporary path name with a trailing NULL from a Fortran
string. However, it's possible for the us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587
Janne Blomqvist changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67414
--- Comment #3 from Janne Blomqvist ---
Author: jb
Date: Wed Sep 2 14:51:40 2015
New Revision: 227404
URL: https://gcc.gnu.org/viewcvs?rev=227404&root=gcc&view=rev
Log:
PR 67414 Better diagnostics on backtrace failure, gf_strerror bugfix
2015-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67414
--- Comment #4 from Janne Blomqvist ---
Author: jb
Date: Wed Sep 2 15:13:35 2015
New Revision: 227406
URL: https://gcc.gnu.org/viewcvs?rev=227406&root=gcc&view=rev
Log:
PR 67414 Handle newlocale failure
2015-09-02 Janne Blomqvist
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67414
Janne Blomqvist changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849
--- Comment #8 from Janne Blomqvist ---
(In reply to Dominique d'Humieres from comment #7)
> > So, to summarize: we already have a finalization function, cleanup().
> > Should we export it? I am not so sure, unless we have a real use case.
>
> C
-
||patches/2015-09/msg00382.ht
||ml
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
--- Comment #23 from Janne Blomqvist ---
Patch implementing "print backtrace on error terminatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #24 from Janne Blomqvist ---
Author: jb
Date: Fri Sep 4 22:17:11 2015
New Revision: 227503
URL: https://gcc.gnu.org/viewcvs?rev=227503&root=gcc&view=rev
Log:
PR 53379 Print backtrace on error termination.
2015-09-05 Janne Blomqvis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Janne Blomqvist changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
libgfortran should retry system calls failing with EINTR, with the exception of
close(). Rationale and further reading e.g. at
https://www.python.org/dev/peps/pep-0475/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67585
Janne Blomqvist changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Janne Blomqvis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53796
Janne Blomqvist changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #15 from Janne Blomqvi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119
--- Comment #14 from Janne Blomqvist ---
(In reply to Dominique d'Humieres from comment #12)
> I suppose most modern OS provide such optimized BLAS and, if not, one can
> install libraries such as atlas. So I wonder if it would not be more
> effe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119
--- Comment #25 from Janne Blomqvist ---
(In reply to Jerry DeLisle from comment #24)
> (In reply to Jerry DeLisle from comment #16)
> > For what its worth:
> >
> > $ gfc pr51119.f90 -lblas -fno-external-blas -Ofast -march=native
> > $ ./a.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119
--- Comment #26 from Janne Blomqvist ---
(In reply to Thomas Koenig from comment #15)
> Another issue: What should we do if the user supplies an external
> subroutine DGEMM which does something unrelated?
>
> I suppose we should then make DGEMM
||2015-01-24
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Janne Blomqvist ---
Confirmed.
Running the testcase under gdb gives the following backtrace:
#0 0x00446a5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64770
--- Comment #2 from Janne Blomqvist ---
Author: jb
Date: Sat Jan 24 21:52:34 2015
New Revision: 220086
URL: https://gcc.gnu.org/viewcvs?rev=220086&root=gcc&view=rev
Log:
PR libfortran/64770 Segfault when trying to open existing file with
status=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64770
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64770
--- Comment #5 from Janne Blomqvist ---
Author: jb
Date: Sun Jan 25 23:04:50 2015
New Revision: 220098
URL: https://gcc.gnu.org/viewcvs?rev=220098&root=gcc&view=rev
Log:
PR 64770 Make testcase work properly under DejaGNU.
2015-01-26 Janne Blom
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
In some cases at least Linux can return an EPERM rather than EACCES error in
case opening a file fails, see
https://stackoverflow.com/questions/28696539/fortran-open-call-differs-on-nfsv3-vs-nfsv4
Based on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65200
--- Comment #3 from Janne Blomqvist ---
Untested patch:
Index: io/open.c
===
--- io/open.c (revision 221202)
+++ io/open.c (working copy)
@@ -502,34 +502,12 @@
s = open_exter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65200
--- Comment #4 from Janne Blomqvist ---
Suggested doc patch:
Index: gfortran.texi
===
--- gfortran.texi (revision 221234)
+++ gfortran.texi (working copy)
@@ -1328,6 +13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471
--- Comment #5 from Janne Blomqvist ---
Ah, I suspected that other functions might be affected as well. Thanks for
finding them.
That being said, googling this issue I stumbled upon
https://gcc.gnu.org/ml/gcc-patches/2011-03/msg00545.html where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471
--- Comment #7 from Janne Blomqvist ---
(In reply to dave.anglin from comment #3)
> On some platforms (MacOS 10.4 and Solaris 11), ttyname_r may return a
> 'char *', not 'int'.
FWIW, libgfortran uses the AC_USE_SYSTEM_EXTENSIONS macro, which on
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
As reported on the ml, " if the PATH is not finished by ':' the last directory
present in the path is NOT processed.". Thus, in case addr2line is installed in
the last d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63589
Janne Blomqvist changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63589
--- Comment #2 from Janne Blomqvist ---
Author: jb
Date: Mon Oct 20 07:53:37 2014
New Revision: 216449
URL: https://gcc.gnu.org/viewcvs?rev=216449&root=gcc&view=rev
Log:
PR 63589 Fix splitting of PATH in find_addr2line.
2014-10-20 Janne Blomqv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63589
--- Comment #3 from Janne Blomqvist ---
Author: jb
Date: Mon Oct 20 08:04:39 2014
New Revision: 216450
URL: https://gcc.gnu.org/viewcvs?rev=216450&root=gcc&view=rev
Log:
PR 63589 Fix splitting of PATH in find_addr2line.
2014-10-20 Janne Blomqv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63589
--- Comment #4 from Janne Blomqvist ---
Author: jb
Date: Mon Oct 20 08:16:06 2014
New Revision: 216451
URL: https://gcc.gnu.org/viewcvs?rev=216451&root=gcc&view=rev
Log:
PR 63589 Fix splitting of PATH in find_addr2line.
2014-10-20 Janne Blomqv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63589
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #22 from Janne Blomqvist ---
(In reply to Tobias Burnus from comment #21)
> (In reply to Jerry DeLisle from comment #20)
> > Created attachment 33858 [details]
> > Proposed patch
>
> /* If the current locale is expecting a comma ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
Janne Blomqvist changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
Janne Blomqvist changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
--- Comment #24 from Janne Blomqvist ---
Author: jb
Date: Mon Nov 10 00:17:16 2014
New Revision: 217273
URL: https://gcc.gnu.org/viewcvs?rev=217273&root=gcc&view=rev
Log:
PR 47007 and 61847 Locale failures in libgfortran.
2014-11-10 Janne Blom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #24 from Janne Blomqvist ---
Author: jb
Date: Mon Nov 10 00:17:16 2014
New Revision: 217273
URL: https://gcc.gnu.org/viewcvs?rev=217273&root=gcc&view=rev
Log:
PR 47007 and 61847 Locale failures in libgfortran.
2014-11-10 Janne Blom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
Janne Blomqvist changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
--- Comment #25 from Janne Blomqvist ---
Fixed on trunk, closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744
Bug 56744 depends on bug 47007, which changed state.
Bug 47007 Summary: Values from namelist file should not depend on locale
settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
--- Comment #8 from Janne Blomqvist ---
Author: jb
Date: Thu Nov 13 12:05:01 2014
New Revision: 217480
URL: https://gcc.gnu.org/viewcvs?rev=217480&root=gcc&view=rev
Log:
PR 60324 Unbounded stack allocations in libgfortran.
2014-11-13 Janne Blo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Janne Blomqvist changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
--- Comment #10 from Janne Blomqvist ---
Author: jb
Date: Sun Nov 16 01:56:54 2014
New Revision: 217623
URL: https://gcc.gnu.org/viewcvs?rev=217623&root=gcc&view=rev
Log:
PR 60324 VLA related fixes to random number generator.
2014-11-16 Janne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
--- Comment #7 from Janne Blomqvist ---
(In reply to Rich Townsend from comment #6)
> This change introduces a dependency on strndup -- which, alas, is absent
> from libSystem in OS X 10.6 (Snow Leopard), although later releases of OS X
> include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62215
--- Comment #6 from Janne Blomqvist ---
(In reply to Steve Kargl from comment #3)
> Not having a copyright assignment won't interfere with this
> patch being applied. I'm waiting for confirmation from Janne
> that I can revert the changes in his
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62215
--- Comment #8 from Janne Blomqvist ---
Author: jb
Date: Fri Aug 29 20:46:15 2014
New Revision: 214742
URL: https://gcc.gnu.org/viewcvs?rev=214742&root=gcc&view=rev
Log:
PR 62215 Reinstate unlinking old module file before renaming.
2014-08-29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62215
--- Comment #9 from Janne Blomqvist ---
Author: jb
Date: Fri Aug 29 20:49:16 2014
New Revision: 214743
URL: https://gcc.gnu.org/viewcvs?rev=214743&root=gcc&view=rev
Log:
PR 62215 Unlink old module file before renaming.
2014-08-29 Jeffrey Armst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62215
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
libgfortran uses various C/POSIX functions for interfacing with the file
systems. In the C/POSIX world, file names are terminated by a null byte,
whereas Fortran strings are not. Consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62768
--- Comment #3 from Janne Blomqvist ---
Author: jb
Date: Tue Sep 16 21:40:28 2014
New Revision: 215307
URL: https://gcc.gnu.org/viewcvs?rev=215307&root=gcc&view=rev
Log:
PR libfortran/62768 Handle filenames with embedded null characters.
testsu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62768
--- Comment #4 from Janne Blomqvist ---
Author: jb
Date: Wed Sep 17 21:44:15 2014
New Revision: 215338
URL: https://gcc.gnu.org/viewcvs?rev=215338&root=gcc&view=rev
Log:
PR libfortran/62768 Use gfc_unit.filename also when HAVE_TTYNAME{_R} is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471
--- Comment #1 from Janne Blomqvist ---
Hmm, any idea how to fix it? Apparently just defining _REENTRANT globally might
not be a good idea, as some systems may require linking in some other C library
(libc_rt or such) then. We don't want to use t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471
--- Comment #2 from Janne Blomqvist ---
Hmm, maybe add something like
AC_CHECK_DECLS_ONCE([ttyname_r])
to configure.ac and then in unix.c(stream_ttyname) check with
#ifdef HAVE_TTYNAME_R && HAVE_DECL_TTYNAME_R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861
--- Comment #3 from Janne Blomqvist ---
Or rather, also fixing another similar potential issue, you might instead want
to test this:
diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c
index e5fc6e1..a1ce9a3 100644
--- a/libgfortran/io/un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861
--- Comment #6 from Janne Blomqvist ---
Author: jb
Date: Tue Jul 14 20:26:06 2015
New Revision: 225788
URL: https://gcc.gnu.org/viewcvs?rev=225788&root=gcc&view=rev
Log:
PR 66861 Fix null pointer crash on mingw.
2015-07-14 Janne Blomqvist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861
--- Comment #7 from Janne Blomqvist ---
Fixed on trunk. I'm not sure if the milestone thing implies an Ok to commit to
the gcc-5 branch, as we're already on 5.2 rc2, I'll ask explicitly for an Ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861
--- Comment #8 from Janne Blomqvist ---
Author: jb
Date: Wed Jul 15 07:00:23 2015
New Revision: 225805
URL: https://gcc.gnu.org/viewcvs?rev=225805&root=gcc&view=rev
Log:
PR 66861 Fix null pointer crash on mingw.
2015-07-15 Janne Blomqvist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861
Janne Blomqvist changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
Following the recent update to use libbacktrace instead of fork+exec of
addr2line in libgfortran, a small test program I had lying around shows a
strange address as the first stack
||2015-08-31
CC||fxcoudert at gcc dot gnu.org,
||jb at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Janne Blomqvist ---
Confirmed.
I'd say this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67414
Janne Blomqvist changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #29 from Janne Blomqvist 2011-03-08
22:38:49 UTC ---
(In reply to comment #28)
> (In reply to comment #26)
> > Tru64 UNIX doesn't support weak undefined symbols, which seems to be
> > what weakrefs are.
>
> Hmm, I think it is going t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #32 from Janne Blomqvist 2011-03-14
11:34:00 UTC ---
Created attachment 23648
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23648
Proposed patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #34 from Janne Blomqvist 2011-03-14
11:42:47 UTC ---
(In reply to comment #31)
> > That being said, I'd prefer to postpone this fix to stage 1 due to
> >
> > - I'm currently moving flats so my stuff is all over and I'm very busy
> > -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #35 from Janne Blomqvist 2011-03-14
11:50:26 UTC ---
(In reply to comment #33)
> I think you should add below the hunk defining conditionally
> GF_CLOCK_MONOTONIC:
> #ifndef GF_CLOCK_MONOTONIC
> #undef HAVE_CLOCK_GETTIME
> #undef HAVE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47552
--- Comment #7 from Janne Blomqvist 2011-03-15 15:26:05
UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > If not before, perhaps something to fix when/if we change to use size_t for
> > string lengths, see http://gcc.gnu.org/wiki/Li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
Janne Blomqvist changed:
What|Removed |Added
Attachment #23648|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #40 from Janne Blomqvist 2011-03-15
17:19:43 UTC ---
(In reply to comment #37)
> >> I'd really like to see this fixed before 4.6.0: it is a regression from
> >> 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #41 from Janne Blomqvist 2011-03-15
20:38:18 UTC ---
(In reply to comment #37)
> #if defined(__alpha__) && defined(__osf__)
> #undef HAVE_CLOCK_GETTIME
> #endif
>
> or some configure.ac equivalent. Ugly but still better than complet
||jb at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #1 from Janne Blomqvist 2011-03-18 15:45:59
UTC ---
AFAICS this is due to gfortran nowadays using libcpp rather than calling an
external cpp.
*** This bug has been marked as a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954
Janne Blomqvist changed:
What|Removed |Added
CC||thenlich at users dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419
Summary: Reduce gfortran stack usage for procedures doing IO
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
Ass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419
--- Comment #1 from Janne Blomqvist 2011-04-02 21:12:25
UTC ---
(In reply to comment #0)
> For #2 there are a few options. Say,
>
> a) A char array containing all the data. Walk over the flags variable, and for
> each set bit, read the appropria
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
Janne Blomqvist changed:
What|Removed |Added
AssignedTo|jvdelisle at gcc dot|pault at gcc dot gnu.org
||2011.04.09 21:19:09
CC||jb at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #3 from Janne Blomqvist 2011-04-09 21:19:09
UTC ---
Does any of the Fortran edit descriptors require, or for that matter allow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511
--- Comment #4 from Janne Blomqvist 2011-04-10 08:36:24
UTC ---
(In reply to comment #3)
> Does any of the Fortran edit descriptors require, or for that matter allow,
> this kind of "shortest decimal representation" output?
Well, the obvious(?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511
--- Comment #6 from Janne Blomqvist 2011-04-10 12:24:54
UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Does any of the Fortran edit descriptors require, or for that matter
> > > allow,
> > > this k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48543
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
Janne Blomqvist changed:
What|Removed |Added
URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587
Summary: Avoid exhausting unit number with NEWUNIT=
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
Assigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587
--- Comment #2 from Janne Blomqvist 2011-04-13 10:46:42
UTC ---
(In reply to comment #1)
> There is a problem with reusing numbers - it is probably only a small one -
> but
> it might be larger than the problem of running out of unit IDs:
>
> T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587
--- Comment #4 from Janne Blomqvist 2011-04-14 08:12:33
UTC ---
(In reply to comment #3)
> I suppose one could put an OPEN .. CLOSE in a DO LOOP and see what happens
> now.
With gfortran 4.4.3 on Linux 2.6.32, /tmp on ext4, single SATA disk, an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #52 from Janne Blomqvist 2011-04-15
04:21:26 UTC ---
Author: jb
Date: Fri Apr 15 04:21:19 2011
New Revision: 172469
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172469
Log:
PR 47571 Fix bootstrap regression on alpha-dec-osf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48618
Summary: Negative unit number in OPEN(...) is sometimes allowed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587
--- Comment #5 from Janne Blomqvist 2011-04-15 09:13:14
UTC ---
Reading the standard, my simple suggestion in #1 will not actually work. One
reason is that the NEWUNIT value may not be -1; with my approach this is
possible if one first closes fd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419
Janne Blomqvist changed:
What|Removed |Added
Depends on||45715
--- Comment #3 from Janne Blomqvi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48664
Summary: Use autoconf test instead of target blacklist to
determine weak undefined reference support
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #54 from Janne Blomqvist 2011-04-18
12:07:29 UTC ---
(In reply to comment #53)
> Rainer, all: Is the problem now fixed on 4.7? If so, should it be backported
> for 4.6.1? And can then the PR be closed?
FWIW, I just opened PR 48664 in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #56 from Janne Blomqvist 2011-04-18
15:49:23 UTC ---
Author: jb
Date: Mon Apr 18 15:49:16 2011
New Revision: 172656
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172656
Log:
PR 47571 Fix weakref trickery breakage on alpha-dec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
Janne Blomqvist changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48682
Summary: Incorrect field justification with Gw.d edit
descriptor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
||2011.04.20 08:53:15
CC||jb at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #4 from Janne Blomqvist 2011-04-20 08:53:15
UTC ---
Confirmed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48682
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #8 from Janne Blomqvist 2011-04-20 13:09:51
UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > > Here is some sample code (extreme, I admit) which profits a lot from
> > > inlining:
> > >
> > > - Strides are known to be
501 - 600 of 690 matches
Mail list logo
