https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
Thomas Koenig changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
--- Comment #6 from Thomas Koenig ---
This actually segfaults at runtime.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
Thomas Koenig changed:
What|Removed |Added
Summary|[OOP] segfault with |[OOP] ICE with procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94408
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
|--- |FIXED
CC||tkoenig at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
Works now, fixed by I don't know what commit.
Test case committed as
https://gcc.gnu.org/g:80198c701a7fc09e736ccffe470ee5033ca59a69 , closing.
Thanks fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93524
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
||tkoenig at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #4 from Thomas Koenig ---
Seems fixed... I'll try to commit the test case this evening.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following is currently rejected:
program main
use, intrinsic :: iso_fortran_env
type (team_type) :: odd_even
integer :: me
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 50233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50233&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199
Thomas Koenig changed:
What|Removed |Added
Version|unknown |11.0
Target Milestone|---
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Consider
unsigned int foo(unsigned int *a, int n)
{
int i;
unsigned int res = 0;
for (i=0; i:
0: 00 00 04 2c cmpwi r4,0
4: 30 00 81
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
Thomas Koenig changed:
What|Removed |Added
Status|SUSPENDED |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
--- Comment #4 from Thomas Koenig ---
Yes, the masking should be only performed at the end.
However, the inner loop could be further simplified to
label:
lwzu r8,4(r10)
add r3,r8,r3
bdnz label
without the need to do anything with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100989
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed||2021-06-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100989
Thomas Koenig changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #48 from Thomas Koenig ---
Clang gets this right, even without the pragma; the original test case is
compiled to
pushq %r14
pushq %rbx
subq$24, %rsp
movq%rsi, %r14
movq%rdi, %rb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #49 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #48)
> Clang gets this right, even without the pragma;
The "even without the pragma" part is wrong.
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Split from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678#c47 .
The test case
$ cat y.f90
module y
implicit none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329
Thomas Koenig changed:
What|Removed |Added
Version|unknown |13.0
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329
--- Comment #2 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #1)
> As long as PR 36678
That should be PR 34678 .
||2023-01-07
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|tkoenig at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31756
Thomas Koenig changed:
What|Removed |Added
CC||mehdi.chinoune at hotmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204
Thomas Koenig changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #8 from Thomas Koe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #6 from Thomas Koenig ---
(In reply to Michael_S from comment #5)
> Hi Thomas
> Are you in or out?
Depends a bit on what exactly you want to do, and if there is
a chance that what you want to do will be incorporated into gcc.
If yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #9 from Thomas Koenig ---
Created attachment 54273
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54273&action=edit
matmul_r16.i
Here is matmul_r16.i from a relatively recent trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #10 from Thomas Koenig ---
What we would need for incorporation into gcc is to have several
functions, which would then called depending on which floating point
options are in force at the time of invocation.
So, let's go through th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #13 from Thomas Koenig ---
I tried compiling your tests on Apple silicon using Asahi Linux, but
without success. A first step was rather easy; replacing __float128 by
_Float128 was required. I then bootstrapped gcc on that machine a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #14 from Thomas Koenig ---
Seems that libquadmath is not built on that particular Linux/CPU variant,
for whatever reason. At last I cannot find any '*quadmath* files
in the build directory.
/proc/cpuinfo tells me that
processor
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
A meta-bug to hang Fortran 2023 support PRs on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #12 from Thomas Koenig ---
(In reply to anlauf from comment #11)
> (In reply to Jerry DeLisle from comment #8)
> > Doing the search in bugzilla, 137 bugs are marked as ic-on-invalid-code. I
> > suggest we make all of these P5 or Won
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108592
--- Comment #2 from Thomas Koenig ---
(In reply to anlauf from comment #1)
> @Thomas: do you remember the reason you chose the "_now" version?
I'm not sure any more. It's been a few years :-)
: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
In the Fortran front end, we could sometimes reverse loops at runtime if
dependency analysis shows that either a
nhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
In the code
#include
#include
#include
uint64_t foo (uint64_t x)
{
x = x | (x >> 1);
x = x | (x >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108710
--- Comment #1 from Thomas Koenig ---
Actually, register allocation is OK for an architecture with destructive shifts
only.
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
For the code (reduced from embench)
struct {
unsigned int table[4][100];
} * _nettle_aes_decrypt_T;
unsigned int _nettle_aes_decrypt_w1;
void
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Code sometimes contains manual unrolling. For example, the BLAS
reference implementation, subroutine DSCAL, has
IF (INCX.EQ.1) THEN
*
*code for increment
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Two related test cases (which do the same, but are handled differently).
This is code for calculating a Jacobian, a frequent task in solving
non-linear systems of equations
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 54497
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54497&action=edit
Assembly code generated by test case
Looking a bit more at t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108863
Thomas Koenig changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Looks like a general RTL issue, I see this on POWER, RV64 and ARM64 (the
latter two on godbolt).
[tkoenig@gcc135 ~]$ cat c.c
long foo (long b, long c)
{
return b + c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109019
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
rnflow from the pb11 Polyhedron benchmark hangs at -O3 with recent trunk,
gcc-Version 13.0.1 20230308 (experimental) [master revision
e87559d202d:f4e6da6e8ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
--- Comment #1 from Thomas Koenig ---
Created attachment 54617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54617&action=edit
rnflow.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
--- Comment #2 from Thomas Koenig ---
Created attachment 54618
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54618&action=edit
Header file needed for compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
--- Comment #3 from Thomas Koenig ---
Created attachment 54619
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54619&action=edit
Compressed input file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
Thomas Koenig changed:
What|Removed |Added
Keywords||needs-bisection
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
--- Comment #5 from Thomas Koenig ---
Might be invalid code, see
https://gcc.gnu.org/pipermail/fortran/2023-March/059062.html
That appears to be a problem with widely used old-style linear congruential
random number generators, which expect ov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
Thomas Koenig changed:
What|Removed |Added
Known to work||12.2.0
--- Comment #7 from Thomas Koeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104811
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
IEEE mandates correct rounding of square roots, and sqrtq rounds
incorrectly for some values:
#include
#include
#define MPFR_WANT_FLOAT128
#include
#include
#define NDIG 113
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #39 from Thomas Koenig ---
(In reply to Richard Biener from comment #37)
> The issue itself is long latent so we probably have to live with GCC 12
> exposing slightly more cases of it in the real world (I have yet to see
> one there
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
A meta-bug for Fortran IEEE support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #5 from Thomas Koenig ---
There is another, much worse, problem, reported and analyzed by "Michael S"
on comp.arch. The code has
#ifdef HAVE_SQRTL
{
long double xl = (long double) x;
if (xl <= LDBL_MAX && xl >= LDBL_MIN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #7 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Thomas Koenig from comment #5)
> > There is another, much worse, problem, reported and analyzed by "Michael S"
> > on comp.arch. The code has
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93256
--- Comment #2 from Thomas Koenig ---
Works for 12.0., fails with 9.4.0.
So, I assume this has been fixed in the meantime, it would be interesting
to see when.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93256
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following test case
module x
implicit none
type foo
real :: r
end type foo
interface read(formatted)
module procedure read_formatted
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
--- Comment #1 from Thomas Koenig ---
This "fixes" the bug in question, but is almost certainly entirely
incorrect for a lot of other cases. Will have to look a bit further.
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
--- Comment #2 from Thomas Koenig ---
As expected:
FAIL: gfortran.dg/list_read_8.f90 -O0 execution test
FAIL: gfortran.dg/list_read_8.f90 -O1 execution test
FAIL: gfortran.dg/list_read_8.f90 -O2 execution test
FAIL: gfortran.dg/list_re
||tkoenig at gcc dot gnu.org
--- Comment #7 from Thomas Koenig ---
(In reply to Steve Kargl from comment #6)
> On Wed, Apr 27, 2022 at 12:03:54AM +, hp at gcc dot gnu.org wrote:
> >
> > --- Comment #5 from Hans-Peter Nilsson ---
> > (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78054
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78054
--- Comment #10 from Thomas Koenig ---
(In reply to anlauf from comment #9)
> (In reply to Thomas Koenig from comment #8)
> > Fixed on trunk by
> >
> > https://gcc.gnu.org/pipermail/gcc-cvs/2022-April/362724.html .
>
> Thomas,
>
> you'd bette
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Test case:
$ cat g2.f90
module y
implicit none
type foo
integer :: n
contains
final :: cleanup
end type foo
interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576
--- Comment #1 from Thomas Koenig ---
There currently is a c.l.f. thread on this, with this test case.
Although what nagfor and xlf are doing makes sense, it does
not (to me) follow from the language of the standard.
https://groups.google.com/g
dot gnu.org |tkoenig at gcc dot
gnu.org
Last reconfirmed||2022-08-13
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from Thomas Koenig ---
Created attachment 53451
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53451&acti
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The code from PR 103109
#include
void Long_multiplication( uint64_t multiplicand[],
uint64_t multiplier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104265
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453
--- Comment #16 from Thomas Koenig ---
(In reply to Mikael Morin from comment #15)
> Status update:
A lot of progress :-)
> (In reply to Thomas Koenig from comment #5)
> > Still missing: To clobber
> >
> > - variables passed by reference to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317
--- Comment #3 from Thomas Koenig ---
As this is invalid code (and in Fortran), should this actually be P2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317
Thomas Koenig changed:
What|Removed |Added
Priority|P2 |P3
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following code
#include
void Long_multiplication( uint64_t multiplicand[],
uint64_t multiplier[],
uint64_t sum
|RESOLVED
CC||tkoenig at gcc dot gnu.org
--- Comment #6 from Thomas Koenig ---
Fixed by https://gcc.gnu.org/g:962ff7d2849e1fa6a1fe0535aa2dec5c2b9a32a6
Thanks for the bug report!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103043
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
--- Comment #13 from Thomas Koenig ---
(In reply to anlauf from comment #12)
> Any reason not to use the macros from safe-ctype.h?
Can we actually use it? This is part of libiberty, AFAIK,
and I am not sure that we link libgfortran against it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #11 from Thomas Koenig ---
(In reply to Richard Biener from comment #10)
> Is there any case where the frontend would make 'data' point into the
> middle of the array and iteration over the array would end up accessing
> elements on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #13 from Thomas Koenig ---
(In reply to Mikael Morin from comment #12)
> (In reply to Thomas Koenig from comment #11)
> > (In reply to Richard Biener from comment #10)
> >
> > > Is there any case where the frontend would make 'data'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Thomas Koenig changed:
What|Removed |Added
CC||sandra at codesourcery dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #20 from Thomas Koenig ---
(In reply to Mikael Morin from comment #19)
> (In reply to Thomas Koenig from comment #15)
> > One possibility would be to extend the patch Sandra posted at
> > https://gcc.gnu.org/pipermail/fortran/2021-Ja
||tkoenig at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
I can confirm the bug with gcc 9 (didn't check any other
version).
Current trunk gives me
.f90:10:13:
10 | ]
| 1
interner Compiler-Fehler: tree check: expected integer_cst, have save_ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115
--- Comment #4 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #3)
> Thomas, are you sure? I cannot see an ICE, neither with the master from
> September 21 nor with the master from yesterday.
I see the ICE with
gcc version 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115
--- Comment #5 from Thomas Koenig ---
I can confirm the ICE with current trunk both on x86_64 and
on POWER.
x86_64:
$ gfortran -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115
--- Comment #7 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #6)
> Really interesting, I don't get an ICE with the following setup:
> ../configure --prefix=/usr/local/ --with-gmp=/usr/local/
> --with-mpfr=/usr/local/ --with-mp=
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
$ cat a.c
double
sin(double x) {
return x/2 + x;
}
double
foo(double x) {
return 1 - sin(-x);
}
$ gcc -S -fdump-tree-original a.c
$ cat a.c.005t.original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103323
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||tkoenig at gcc dot gnu.org
Last reconfirmed||2021-11-18
Status|UNCONFIRMED |NEW
--- Comment #15 from Thomas Koenig ---
There should at least be a warning for code like
double
sin(double x) {
return x/2 + x;
}
double
foo
NCONFIRMED
Severity: blocker
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 51899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51899&action=edit
po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103476
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
If x is a NaN, then x > 1 will fail, so the __builtin_isnan function
could be removed in comparisons l
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Just stumbled across this...
module prec
implicit none
private
public :: wp
integer, parameter :: dp = selected_real_kind(15)
integer, param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707
--- Comment #1 from Thomas Koenig ---
This is with gcc 11, no time to further reduce / try with trunk right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707
--- Comment #5 from Thomas Koenig ---
Thanks for the quick reduction, Gerhard.
This originally came from something like
program p
real, parameter :: fmin(1) = 0.
real, parameter :: fmax(1) = 1.
real :: x(1)
where (fmin <= 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102079
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #13 from Thomas Koenig ---
Here is a complete strace of a "Hello, world" program on Linux, compiled
with -static-libgfortran (to remove some of the shared library loading :-)
and executed with
$ strace ./a.out > hello.dat
execve(".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #14 from Thomas Koenig ---
(In reply to Iain Sandoe from comment #6)
> I had a brief look at some new fails on macOS12 / Darwin21 for gcov.
>
> It seems that .mod_term_funcs entries are not being run - so if libgfortran
> relies on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #15 from Thomas Koenig ---
Hmm, to test this further: What does
program main
use, intrinsic :: iso_fortran_env, only: output_unit
write (*,'(A)') 'Hello, world!'
flush output_unit
end program main
yield, does that create the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #19 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #18)
> write(0x1, " Hello, world!\\n\n\0", 0x11) = 17 0
Hmm, was this actually the string that you put into the Fortran
program, or is something very s
3401 - 3500 of 3756 matches
Mail list logo
