https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90504
--- Comment #2 from Janne Blomqvist ---
(In reply to anlauf from comment #1)
> (In reply to Janne Blomqvist from comment #0)
> > Hanson, Hopkins, Remark on Algorithm 539: A Modern Fortran Reference
> > Implementation for Carefully Computing the
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
This is from
https://stackoverflow.com/questions/74814027/where-to-report-possible-gfortran-compiler-bug
. Consider
program test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107373
--- Comment #3 from Janne Blomqvist ---
63ee540430c3 might be related wrt fixing it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886
--- Comment #4 from Janne Blomqvist ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Janne Blomqvist from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Is there anything to be done as the time_t is now defaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886
--- Comment #2 from Janne Blomqvist ---
(In reply to Andrew Pinski from comment #1)
> Is there anything to be done as the time_t is now defaults to 64bit on the
> trunk of glibc?
AFAIU it's not the default, you need to explicitly opt-in by
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
In order to solve the Y2038 problem glibc now supports 64-bit time_t on 32-bit
platforms. As this is an ABI change, it has to be explicitly enabled through
setting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
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 program
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
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
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
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.
||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 original
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 /=
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
> >
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=92463
Janne Blomqvist changed:
What|Removed |Added
Component|fortran |middle-end
--- Comment #4 from Janne
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=gcc=rev
Log:
PR 92463 MPFR modernization: Revert r269139
Commit r269139 fixed an accidental
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=gcc=rev
Log:
PR 92463 MPFR modernization: Revert r269139
Commit r269139 fixed an accidental
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=gcc=rev
Log:
PR 92463 MPFR modernization in GFortran
Now that we require a minimum of MPFR
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
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=91828
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
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=gcc=rev
Log:
Bump minimum MPFR version to 3.1.0
Bump the minimum MPFR version to 3.1.0, released
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=gcc=rev
Log:
Don't print warning when moving to static with -fno-automatic
As part of PR 91413,
||https://gcc.gnu.org/ml/gcc-
||patches/2019-11/msg00676.ht
||ml
Last reconfirmed||2019-11-09
Assignee|unassigned at gcc dot gnu.org |jb
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91543
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419
--- Comment #9 from Janne Blomqvist ---
Like Jerry said, we've recently had an ABI break (two, actually!), and I think
we should try hard to avoid yet another one. I think it should be possible to
create some new st_parameter_dt_2 or such, as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413
Janne Blomqvist changed:
What|Removed |Added
Assignee|jb at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300
Bug 91300 depends on bug 68401, which changed state.
Bug 68401 Summary: improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401
Janne Blomqvist changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401
--- Comment #13 from Janne Blomqvist ---
Author: jb
Date: Sat Aug 17 05:45:37 2019
New Revision: 274599
URL: https://gcc.gnu.org/viewcvs?rev=274599=gcc=rev
Log:
PR fortran/68401 Improve allocation error message
Improve the error message that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401
Janne Blomqvist changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
||jb at gcc dot gnu.org
Blocks||91300
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
--- Comment #11 from Janne Blomqvist ---
The variadic os_error type function is probably also necessary for solving PR
91300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414
Janne Blomqvist changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414
--- Comment #8 from Janne Blomqvist ---
Author: jb
Date: Tue Aug 13 09:04:18 2019
New Revision: 274365
URL: https://gcc.gnu.org/viewcvs?rev=274365=gcc=rev
Log:
PR fortran/91414 Bugfix for previous commit
Correctly fill master_seed from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414
--- Comment #7 from Janne Blomqvist ---
Author: jb
Date: Tue Aug 13 09:02:25 2019
New Revision: 274364
URL: https://gcc.gnu.org/viewcvs?rev=274364=gcc=rev
Log:
PR fortran/91414 Correctly fill master_state from os_seed.
Modified:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414
--- Comment #6 from Janne Blomqvist ---
Author: jb
Date: Tue Aug 13 09:00:46 2019
New Revision: 274363
URL: https://gcc.gnu.org/viewcvs?rev=274363=gcc=rev
Log:
PR fortran/91414 Improve initialization of PRNG
As part of PR 91414 an improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414
--- Comment #5 from Janne Blomqvist ---
Author: jb
Date: Tue Aug 13 08:42:43 2019
New Revision: 274362
URL: https://gcc.gnu.org/viewcvs?rev=274362=gcc=rev
Log:
PR fortran/91414 Improve initialization of PRNG
As part of PR 91414 an improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414
--- Comment #4 from Janne Blomqvist ---
Author: jb
Date: Tue Aug 13 08:24:43 2019
New Revision: 274361
URL: https://gcc.gnu.org/viewcvs?rev=274361=gcc=rev
Log:
PR fortran/91414: Improved PRNG
Update the PRNG from xorshift1024* to xoshiro256**
||2019-08-12
CC||jb at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Janne Blomqvist ---
AFAICT this is a valid bug report, albeit maybe not of the highest priority.
The problem is that the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413
--- Comment #3 from Janne Blomqvist ---
Author: jb
Date: Sun Aug 11 09:42:41 2019
New Revision: 274264
URL: https://gcc.gnu.org/viewcvs?rev=274264=gcc=rev
Log:
PR fortran/91413 Generate warning when making array static
When moving a local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414
Janne Blomqvist changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414
Janne Blomqvist changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
-
||patches/2019-08/msg00679.ht
||ml
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
--- Comment #2 from Janne Blomqvist ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00679
: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
Currently GFortran uses the xorshift1024* PRNG. The author of that PRNG has an
improved PRNG "xoshiro" at http://prng.di.unimi.it/ , described in detail at
https://arxiv.org/abs/1805.01407 . GFor
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
As of Fortran 2018, procedures are recursive by default. However, currently
GFortran places automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53796
--- Comment #23 from Janne Blomqvist ---
Author: jb
Date: Wed Aug 7 07:34:10 2019
New Revision: 274160
URL: https://gcc.gnu.org/viewcvs?rev=274160=gcc=rev
Log:
PR 53796 Make inquire(file=, recl=) conform to F2018
In my original patch to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #39 from Janne Blomqvist ---
Now, with the fixed benchmark in the previous comment, on Lustre (version 2.5)
system I get:
Test using 25000 bytes
Block size of file system: 4096
bs = 1024, 53.27 MiB/s
bs = 2048, 73.99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #38 from Janne Blomqvist ---
First, I think there's a bug in the benchmark in comment #c20. It writes
blocksize * sizeof(double), but then advances only blocksize for each iteration
of the loop. Fixed version writing just bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #37 from Janne Blomqvist ---
One thing we could do would be to switch to pread and pwrite instead of using
lseek. That would avoid a few syscalls when updating the record length marker.
Though I guess the issue with GPFS isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #50 from Janne Blomqvist ---
Jakub, should your fix be backported to the gcc-7 branch as well, considering
that the PR 87689 fix was applied to that branch as well?
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
--- Comment #2 from Janne Blomqvist ---
Thanks for the report. Fixed, closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91048
--- Comment #1 from Janne Blomqvist ---
Author: jb
Date: Tue Jul 2 05:54:31 2019
New Revision: 272921
URL: https://gcc.gnu.org/viewcvs?rev=272921=gcc=rev
Log:
mklog/91048: Open ~/.mklog in string mode.
2019-07-02 Janne Blomqvist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65921
--- Comment #3 from Janne Blomqvist ---
Author: jb
Date: Thu Jun 20 20:26:39 2019
New Revision: 272520
URL: https://gcc.gnu.org/viewcvs?rev=272520=gcc=rev
Log:
libfortran/65921: Add forgotten PR number to ChangeLog
2019-06-14 Janne Blomqvist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65921
--- Comment #2 from Janne Blomqvist ---
libgfortran/runtime/memory.c (xmallocarray) has been fixed for GCC 10, frontend
part still todo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100
--- Comment #12 from Janne Blomqvist ---
Author: jb
Date: Wed May 22 11:56:01 2019
New Revision: 271511
URL: https://gcc.gnu.org/viewcvs?rev=271511=gcc=rev
Log:
fortran/89100: Default widths with -fdec-format-defaults
gcc/fortran ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #13 from Janne Blomqvist ---
Author: jb
Date: Tue May 21 15:24:30 2019
New Revision: 271470
URL: https://gcc.gnu.org/viewcvs?rev=271470=gcc=rev
Log:
libfortran/90038: Document new wait=.false. implementation
2019-05-21 Janne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #12 from Janne Blomqvist ---
Author: jb
Date: Tue May 21 15:17:44 2019
New Revision: 271468
URL: https://gcc.gnu.org/viewcvs?rev=271468=gcc=rev
Log:
libfortran/90038: Document new wait=.false. implementation
2019-05-21 Janne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #11 from Janne Blomqvist ---
Author: jb
Date: Mon May 20 17:43:05 2019
New Revision: 271427
URL: https://gcc.gnu.org/viewcvs?rev=271427=gcc=rev
Log:
libfortran/90038 Use posix_spawn, reap dead children when wait=.false.
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #9 from Janne Blomqvist ---
Author: jb
Date: Sun May 19 19:38:11 2019
New Revision: 271384
URL: https://gcc.gnu.org/viewcvs?rev=271384=gcc=rev
Log:
libfortran/90038 Reap dead children when wait=.false.
When using posix_spawn or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #8 from Janne Blomqvist ---
Actually, wasn't this simple as the above patch broke the synchronous version.
Need to think more what to do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #7 from Janne Blomqvist ---
This should fix it:
--- a/libgfortran/intrinsics/execute_command_line.c
+++ b/libgfortran/intrinsics/execute_command_line.c
@@ -34,6 +34,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #5 from Janne Blomqvist ---
(In reply to kargl from comment #4)
> What does 'it' refer to? fork() is leaving a zombie?
> posix_spawn() is leaving a zombie?
posix_spawn. Though I guess the old fork() code suffers from the same issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #3 from Janne Blomqvist ---
Further testing revealed that it leaves zombie processes around as the child is
never wait()'ed for. E.g.
program cmd
implicit none
call execute_command_line("echo hi", wait=.FALSE.)
call sleep(30)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #2 from Janne Blomqvist ---
Author: jb
Date: Fri May 17 18:18:04 2019
New Revision: 271340
URL: https://gcc.gnu.org/viewcvs?rev=271340=gcc=rev
Log:
libfortran/90038: Use posix_spawn instead of fork
fork() semantics can be
-
||patches/2019-05/msg00992.ht
||ml
Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org
--- Comment #1 from Janne Blomqvist ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00992
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
Hanson, Hopkins, Remark on Algorithm 539: A Modern Fortran Reference
Implementation for Carefully Computing the Euclidean Norm,
https://dl.acm.org/citation.cfm?id=3134441
Above article tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90461
Janne Blomqvist changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90461
--- Comment #2 from Janne Blomqvist ---
Author: jb
Date: Wed May 15 18:02:36 2019
New Revision: 271260
URL: https://gcc.gnu.org/viewcvs?rev=271260=gcc=rev
Log:
Allow opening file on multiple units
As of Fortran 2018 it's allowed to open the
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
Fortran 2018 removes the restriction that a file can be opened only on one unit
at a time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #21 from Janne Blomqvist ---
I filed https://github.com/Reference-LAPACK/lapack/issues/339 to start a
discussion about fixing CBLAS and LAPACKE in upstream LAPACK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #18 from Janne Blomqvist ---
(In reply to Thomas Koenig from comment #15)
> Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9,
> I would suggest that we make -fno-optimize-sibling-calls
> the default on these branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #12 from Janne Blomqvist ---
(In reply to Tomas Kalibera from comment #11)
> At least in the case I debugged, I think gfortran could do better by not
> writing the 1 as string length to the place on the stack where the compiler
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #8 from Janne Blomqvist ---
(In reply to Janne Blomqvist from comment #3)
> 1) When compiling an external procedure, for character(len=1) arguments we
> don't generate the hidden string length argument. And similarly when calling
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #5 from Janne Blomqvist ---
(In reply to Thomas Koenig from comment #4)
> (In reply to Janne Blomqvist from comment #3)
> > 1) When compiling an external procedure, for character(len=1) arguments we
> > don't generate the hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #3
||jb at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Janne Blomqvist ---
It's not a thread-safety issue. If you uncomment the line
close(lun)
you get the same error message also without OpenMP. The reason is that
GFortran
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
Occasionally there are problems like
https://stackoverflow.com/questions/55120720/fortran-execute-command-line-runtime-error-depends-on-memory-consumption
where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879
Janne Blomqvist changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
Bug 32770 depends on bug 84509, which changed state.
Bug 84509 Summary: STOP and ERROR STOP statements with -fdefault-integer-8 and
large stop code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84509
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84509
Janne Blomqvist changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80408
--- Comment #5 from Janne Blomqvist ---
(In reply to Raphael Monod from comment #4)
> Thank you for your answer. But I don't understand why adding -lpthread
> option change the behavior if I do not use any thread.
In libgfortran, if a thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77908
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #5
||jb at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #3 from Janne Blomqvist ---
Indeed, this is invalid, as the GFortran I/O library is anything by
async-signal-safe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89274
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #1
||jb at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #6 from Janne Blomqvist ---
Fixed on trunk, closing.
The patch uses strtol() since that is in C89 and thus available everywhere.
This close to the GCC 9 release I didn't want to risk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81552
--- Comment #5 from Janne Blomqvist ---
Author: jb
Date: Thu Feb 14 21:33:29 2019
New Revision: 268906
URL: https://gcc.gnu.org/viewcvs?rev=268906=gcc=rev
Log:
PR 81552 Improve and document -flag-init-integer
Make the option handling code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #3
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jb at gcc dot gnu.org
Target Milestone: ---
When building libgfortran trunk one nowadays (within the past month or two,
maybe?) gets lots of warnings like below:
In file included from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88137
Janne Blomqvist changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88137
--- Comment #8 from Janne Blomqvist ---
Author: jb
Date: Thu Dec 6 15:38:25 2018
New Revision: 266858
URL: https://gcc.gnu.org/viewcvs?rev=266858=gcc=rev
Log:
Initialize backtrace state once
From backtrace.h for backtrace_create_state:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88137
--- Comment #7 from Janne Blomqvist ---
Author: jb
Date: Sun Dec 2 15:14:51 2018
New Revision: 266725
URL: https://gcc.gnu.org/viewcvs?rev=266725=gcc=rev
Log:
Use atomic load/store to access static backtrace state pointer
As the static
1 - 100 of 690 matches
Mail list logo
