ormal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
From
https://stackoverflow.com/questions/62937435/compilation-warning-with-gfortran-on-assignment-of-logicalc-bool-variable
Consider the pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #4
gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Janne Blomqvist ---
Assigning to myself, patch at
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00676.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413
--- Comment #5 from Janne Blomqvist ---
Author: jb
Date: Sun Nov 10 21:25:25 2019
New Revision: 278027
URL: https://gcc.gnu.org/viewcvs?rev=278027&root=gcc&view=rev
Log:
Don't print warning when moving to static with -fno-automatic
As part of P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828
--- Comment #6 from Janne Blomqvist ---
Author: jb
Date: Mon Nov 11 15:59:48 2019
New Revision: 278058
URL: https://gcc.gnu.org/viewcvs?rev=278058&root=gcc&view=rev
Log:
Bump minimum MPFR version to 3.1.0
Bump the minimum MPFR version to 3.1.0,
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
As part of resolving PR 91828, the minimum MPFR version required to build GCC
was bumped to 3.1.0 from the previous 2.4.0.
This enables a bunch of cleanups, mostly in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463
Bug 92463 depends on bug 91828, which changed state.
Bug 91828 Summary: gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR
3.0.0, unavailable in mpfr-2.4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463
--- Comment #1 from Janne Blomqvist ---
Seems r269139 can be reverted, that's apparently a patch to fix some accidental
breakage due to depending on a too new MPFR version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463
--- Comment #2 from Janne Blomqvist ---
Author: jb
Date: Wed Nov 20 20:01:25 2019
New Revision: 278523
URL: https://gcc.gnu.org/viewcvs?rev=278523&root=gcc&view=rev
Log:
PR 92463 MPFR modernization in GFortran
Now that we require a minimum of M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #38 from Janne Blomqvist ---
Author: jb
Date: Wed Nov 20 20:08:29 2019
New Revision: 278525
URL: https://gcc.gnu.org/viewcvs?rev=278525&root=gcc&view=rev
Log:
PR 92463 MPFR modernization: Revert r269139
Commit r269139 fixed an accid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463
--- Comment #3 from Janne Blomqvist ---
Author: jb
Date: Wed Nov 20 20:08:29 2019
New Revision: 278525
URL: https://gcc.gnu.org/viewcvs?rev=278525&root=gcc&view=rev
Log:
PR 92463 MPFR modernization: Revert r269139
Commit r269139 fixed an accide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463
Janne Blomqvist changed:
What|Removed |Added
Component|fortran |middle-end
--- Comment #4 from Janne B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #9 from Janne Blomqvist ---
(In reply to Thomas Koenig from comment #8)
> > No. The inquire() is used only to see if the file exists already. If it
> > does, the code branches to read the file, if it does not, the code branches
> > to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #13 from Janne Blomqvist ---
To clarify my previous message, instead of
inquire(..., exist=exist)
if (exist) then
open(...)
else
! Handle file not existing
end if
you can do
open(..., status='old', iostat=stat)
if (stat /= o)
||jb at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #13 from Janne Blomqvist ---
Running the testsuite on today's master (2020-01-18) on x86_64-pc-linux-gnu
fails with
FAIL: gfortran.dg/pr93263_1.f90 -O scan-tree-dump-not ori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263
--- Comment #19 from Janne Blomqvist ---
This latest commit fixes the testsuite failure. Thanks for the quick fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413
--- Comment #7 from Janne Blomqvist ---
(In reply to Tobias Burnus from comment #6)
> Currently, direct recursive use is still not permitted:
>
> Error: Function ‘faculty’ at (1) cannot be called recursively, as it is not
> RECURSIVE
>
> This h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #17 from Janne Blomqvist ---
(In reply to Jerry DeLisle from comment #15)
> Did we conclude that this is an expected race condition?
>
> I run the example comment 14 and it just hangs for me.
Well, hangs in what sense?
For me it ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
Janne Blomqvist changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #46 from Janne Blomqvist 2013-02-18
20:16:28 UTC ---
(In reply to comment #44)
> If unformatted sequential ever worked, it was by chance.
>
> Look at this piece of code:
>
> /* Seek to the head and overwrite the bogus le
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #50 from Janne Blomqvist 2013-02-19
10:59:30 UTC ---
(In reply to comment #47)
> Am 18.02.2013 21:16, schrieb jb at gcc dot gnu.org:
> >> Look at this piece of code:
> >> >
> >> > /
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #51 from Janne Blomqvist 2013-02-19
22:48:50 UTC ---
(In reply to comment #22)
> Revision 180701 removed all checks for special files in
> unit.c:unit_truncate().
> As a consequence programs compiled with gfortran 4.6.3 and ne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #11 from Janne Blomqvist 2013-02-20
21:20:44 UTC ---
Looking at the frontend, calls to runtime_error_at are generated from
gfc_trans_runtime_check() and gfc_trans_runtime_error(). I went through calls
to these functions, and IM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #52 from Janne Blomqvist 2013-02-21
19:03:19 UTC ---
Author: jb
Date: Thu Feb 21 19:03:10 2013
New Revision: 196210
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196210
Log:
Fix regression when writing formatted se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #53 from Janne Blomqvist 2013-02-21
20:13:12 UTC ---
Author: jb
Date: Thu Feb 21 20:13:04 2013
New Revision: 196212
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196212
Log:
Fix regression when writing formatted se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #54 from Janne Blomqvist 2013-02-21
20:39:58 UTC ---
I'd suggest to close the unformatted sequential part of this PR as WONTFIX.
Maybe it worked sometime in the past for small record sizes when buffered IO
was used for pipes, b
||atches/2013-04/msg00554.htm
||l
CC||jb at gcc dot gnu.org
--- Comment #8 from Janne Blomqvist 2013-04-09 18:35:46
UTC ---
Patch for compressing module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919
--- Comment #2 from Janne Blomqvist 2013-04-11 18:32:19
UTC ---
(In reply to comment #0)
> The problem is that Cygwin does not support CLOCK_MONOTONIC; using it will
> return always return 0.
>
> Note that Cygwin not only defines CLOCK_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919
Janne Blomqvist changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
--- Comment #4 from Janne Blomqvist 2013-04-17 10:50:07
UTC ---
The reason why gfortran is slow here is that for non-regular files we use
unbuffered I/O. If you write to a regular file instead of /dev/null, you'll see
us doing ~8 KB writes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981
Janne Blomqvist changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028
Janne Blomqvist changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028
Janne Blomqvist changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028
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=57028
--- Comment #8 from Janne Blomqvist 2013-04-25 19:19:05
UTC ---
Author: jb
Date: Thu Apr 25 19:16:46 2013
New Revision: 198318
URL: http://gcc.gnu.org/viewcvs?rev=198318&root=gcc&view=rev
Log:
PR 57028 Bootstrap regression wrt zlib.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028
--- Comment #9 from Janne Blomqvist 2013-04-25 19:19:59
UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > Updated patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01517.html
>
> This one works. Thanks.
Thanks for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #2 from Janne Blomqvist 2012-09-16 08:33:42
UTC ---
(In reply to comment #1)
> You need unwind frames present for this to work, i.e. the space (and to some
> extent optimization-reducing - yes I'm sure) overhead of -funwind-tables.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #27 from Janne Blomqvist 2012-11-10
20:21:41 UTC ---
(In reply to comment #26)
> Is this caused by
>
> http://gcc.gnu.org/viewcvs?view=revision&revision=180701
>
> ?
>
> Maybe we need to remember if we have a special fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296
--- Comment #8 from Janne Blomqvist 2011-01-15 19:31:17
UTC ---
I suppose one thing that could be done is to set opp->file and opp->file_len
regardless of whether mkstemp() succeeds or not, that is lines 1987:1093 in
unix.c, and then in open.c:ne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296
--- Comment #10 from Janne Blomqvist 2011-01-16
20:12:55 UTC ---
Well, I was thinking more something like the patch I just posted at
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01086.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46267
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46267
Janne Blomqvist changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
||2011.01.21 13:44:37
CC||jb at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #5 from Janne Blomqvist 2011-01-21 13:44:37
UTC ---
Assigning to myself. The linking issues is probably not solvable, but at
|atches/2011-01/msg01400.htm |atches/2011-01/msg01486.htm
|l |l
AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org
|gnu.org |
--- Comment #7 from Janne Blomqvist 2011-01-21 17:26:08
UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46267
--- Comment #8 from Janne Blomqvist 2011-01-21 22:42:26
UTC ---
Author: jb
Date: Fri Jan 21 22:42:17 2011
New Revision: 169110
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169110
Log:
PR 46267 strerror thread safety
Modified:
trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46267
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47431
Summary: ctime() not thread-safe
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gnu.
||2011.01.24 09:55:30
AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432
Summary: ttyname() not thread-safe
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gn
||2011.01.24 09:57:38
AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439
--- Comment #1 from Janne Blomqvist 2011-01-25 09:28:14
UTC ---
Seems the reason for Windows _mktemp() behavior is due to replicating some
age-old BSD behavior. From the Linux mktemp(3) manpage:
BUGS
Never use mktemp(). Some implementati
||jb at gcc dot gnu.org
Resolution|FIXED |
--- Comment #7 from Janne Blomqvist 2011-01-25 12:01:17
UTC ---
Reopening..
(In reply to comment #6)
> I believe this is fixed by PR30940.
>
> The first example gives:
> Warnung: Actual argum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47375
--- Comment #6 from Janne Blomqvist 2011-01-25 16:46:07
UTC ---
Author: jb
Date: Tue Jan 25 16:46:00 2011
New Revision: 169243
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169243
Log:
PR 47375 getlog thread safety
Modified:
trunk/l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47491
--- Comment #2 from Janne Blomqvist 2011-01-27 16:10:41
UTC ---
Some git-grepping showed that at least libjava has in configure.ac
AC_DEFINE(_POSIX_PTHREAD_SEMANTICS, 1, [Required define if using POSIX
threads])
and in case Boehm GC is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47491
Janne Blomqvist changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47491
--- Comment #5 from Janne Blomqvist 2011-01-27 17:34:18
UTC ---
Author: jb
Date: Thu Jan 27 17:34:14 2011
New Revision: 169334
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169334
Log:
PR 47491 getpwuid_r() bootstrap regression on Solari
||FIXED
AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org
|gnu.org |
--- Comment #6 from Janne Blomqvist 2011-01-27 19:42:58
UTC ---
Fixed, closing. Please reopen if it still doesn't work on Solaris.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47375
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432
--- Comment #4 from Janne Blomqvist 2011-01-27 20:05:49
UTC ---
Author: jb
Date: Thu Jan 27 20:05:45 2011
New Revision: 169337
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169337
Log:
PR 47432 Use ttyname_r() if available
Modified:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432
--- Comment #5 from Janne Blomqvist 2011-01-27 20:08:44
UTC ---
Fixed, closing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47431
--- Comment #3 from Janne Blomqvist 2011-01-27 20:22:46
UTC ---
Author: jb
Date: Thu Jan 27 20:22:37 2011
New Revision: 169338
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169338
Log:
Pr 47431 CTIME/FDATE thread-safety using ctime_r()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47431
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47552
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #2 from Janne Blomqvist 2011-02-01 15:08:13
UTC ---
On Linux/Glibc libgfortran is built with _GNU_SOURCE, which according to the
glibc manual is a superset of all kinds of
_POSIX_C_SOURCE=[latest_supported_standard]
XOPEN_SOURCE=[late
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #6 from Janne Blomqvist 2011-02-01 15:50:52
UTC ---
(In reply to comment #3)
> clock_gettime is defined in librt, so if libgfortran started using librt
> symbols, it needs to a) link against it dynamically for libgfortran.so
Yes, tha
|ASSIGNED
Last reconfirmed||2011.02.01 16:02:50
Host|i686-pc-linux-gnu |
AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #11 from Janne Blomqvist 2011-02-01
16:20:06 UTC ---
(In reply to comment #8)
> (In reply to comment #6)
> > > clock_gettime is defined in librt, so if libgfortran started using librt
> > > symbols, it needs to a) link against it dyna
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #13 from Janne Blomqvist 2011-02-01
20:02:38 UTC ---
(In reply to comment #9)
> How many fortran users actually need to more precise DATE_AND_TIME though?
None, since the DATE_AND_TIME API is limited to millisecond precision. The
mot
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/bugzilla/show_bug.cgi?id=47571
--- Comment #15 from Janne Blomqvist 2011-02-02
08:48:27 UTC ---
Author: jb
Date: Wed Feb 2 08:48:24 2011
New Revision: 169517
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169517
Log:
PR 47571 Weakref trickery for clock_gettime()
Modi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #18 from Janne Blomqvist 2011-02-03
09:53:50 UTC ---
To add to Tobias comment, in the patch the only place where a weakref is used
is
+#ifdef SUPPORTS_WEAK
+static int weak_gettime (clockid_t, struct timespec *)
+ __attribute__((__
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=47571
--- Comment #22 from Janne Blomqvist 2011-02-05
16:22:09 UTC ---
Author: jb
Date: Sat Feb 5 16:22:04 2011
New Revision: 169852
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169852
Log:
PR 47571 Fix HPUX bootstrap regression, cleanup
Mo
||http://gcc.gnu.org/ml/gcc-p
||atches/2011-02/msg00331.htm
||l
AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org
|gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42434
--- Comment #2 from Janne Blomqvist 2011-02-05 20:20:52
UTC ---
Author: jb
Date: Sat Feb 5 20:20:48 2011
New Revision: 169854
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169854
Log:
PR 42434 Update SYSTEM_CLOCK documentation
Modified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42434
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694
--- Comment #11 from Janne Blomqvist 2011-02-15
09:42:12 UTC ---
Unfortunately I don't think I'll have time to look into it this week.
As can be seen from Tobias patch, reading one character at a time is very slow.
But, the comment in read_sf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694
--- Comment #13 from Janne Blomqvist 2011-02-17
12:13:53 UTC ---
(In reply to comment #12)
> the "file" is not seekable so the position eturne by seek always returns
> zero.
If you mean sseek(), don't count on that; the unix.c:raw_*() function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802
--- Comment #3 from Janne Blomqvist 2011-02-19 16:57:18
UTC ---
(In reply to comment #2)
> > Is there no way to get a posix compliant ctime? Alternatively, we'll need
> > autoconf magic to detect the extra arg. I know at one time it was
> > re
||2011.02.20 09:34:06
CC||jb at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Janne Blomqvist 2011-02-20 09:34:06
UTC ---
Confirmed.
While AFAICS this is not a problem wrt removing the timestamp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802
--- Comment #13 from Janne Blomqvist 2011-02-22
08:37:13 UTC ---
FWIW here's a glibc PR wrt overflowing the 26 byte limit:
http://sourceware.org/bugzilla/show_bug.cgi?id=1460
This was fixed in 2005, which is a while ago, but not long enough so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47552
--- Comment #2 from Janne Blomqvist 2011-02-22 15:34:57
UTC ---
This seems to be because the libgfortran implementation uses gfc_charlen_type
for the length of the string, but the frontend passes the address of an
integer(8) variable. As a quick
gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #15 from Janne Blomqvist 2011-02-22
16:21:09 UTC ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01453.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694
--- Comment #16 from Janne Blomqvist 2011-02-22
19:43:10 UTC ---
Patch using the fbuf_getc approach:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01475.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802
--- Comment #16 from Janne Blomqvist 2011-02-22
20:24:13 UTC ---
Patch which should hopefully fix the getpwuid_r issue on HP-UX 10.2:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01478.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694
--- Comment #17 from Janne Blomqvist 2011-02-23
06:59:54 UTC ---
Author: jb
Date: Wed Feb 23 06:59:51 2011
New Revision: 170432
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432
Log:
PR 47694 Read from named pipe fails
Modified:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47854
Summary: omp_get_wtime documentation incorrect
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassig.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694
--- Comment #18 from Janne Blomqvist 2011-02-23
07:11:55 UTC ---
Fixed on trunk. Keeping this PR open in order to remind us to
1) Backport to older releases once we have some experience on trunk.
2) Fix io/read.c(read_x) in the same way to use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802
--- Comment #21 from Janne Blomqvist 2011-02-24
11:34:18 UTC ---
(In reply to comment #20)
> libgfortran.sl is built twice on HP-UX 10, once for the single thread
> model and once for the dce thread model. It's the single thread build
> that's t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802
--- Comment #22 from Janne Blomqvist 2011-02-24
14:51:21 UTC ---
Author: jb
Date: Thu Feb 24 14:51:17 2011
New Revision: 170471
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170471
Log:
PR 47802 Test for POSIX getpwuid_r
Modified:
t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47883
Summary: libgfortran configuration should use AC_LINK_IFELSE
instead of AC_TRY_LINK
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: trivial
Priority: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694
--- Comment #21 from Janne Blomqvist 2011-02-24
15:04:42 UTC ---
(In reply to comment #20)
> Some random thoughts looking at the patch
> (http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432) - probably not
> helping at all with the regression
1 - 100 of 690 matches
Mail list logo
