https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738
--- Comment #5 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #4)
> What about a version that still sets lowest_bit to value & -value; rather
> than 1 < ctz?
I think this would be ideal, or close to it.
> Also, I'm not sure you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #14 from Thomas Koenig ---
Created attachment 49520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49520&action=edit
Numbers a, b so that 2^b ≡ 1 mod a up to b=64, larger b taken if several
solutions exist, plus the multiplicat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #3 from Thomas Koenig ---
Simplified test case:
program main
type foo
real, allocatable, dimension(:) :: a[:]
end type foo
type (foo) :: x
sync all
allocate (x%a(10)[*])
end program main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #16 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #15)
> I plan to work on this early in stage3.
> And we really shouldn't use any tables, GCC should figure it all out.
> So, for double-word modulo by constant that wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #17 from Thomas Koenig ---
To be compilable, my previous code lacks
typedef __uint128_t mytype;
> #define ONE ((__uint128_t) 1)
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
This is an offshoot from PR 97459.
The code
#define ONE ((__uint128_t) 1)
#define TWO_64 (ONE << 64)
#define MASK60 ((1ul << 60) - 1)
typedef __uint
|normal |enhancement
CC||tkoenig at gcc dot gnu.org
--- Comment #1 from Thomas Koenig ---
Could you post the benchmark and the exact architecture where the arithmetic
version is faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
--- Comment #1 from Thomas Koenig ---
Actually, it was on a Ryzen 1700 (for the -march=native).
I'm at odds with architecture names...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #4 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #3)
> Simplified test case:
>
> program main
> type foo
> real, allocatable, dimension(:) :: a[:]
> end type foo
> type (foo) :: x
> sync all
> allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #5 from Thomas Koenig -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Thomas Koeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97770
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21046
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2014-12-25 00:00:00 |2020-11-11
--- Comment #6 from Thomas Ko
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30398
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38592
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2017-08-15 00:00:00 |2020-11-11
--- Comment #10 from Thomas K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
--- Comment #9 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #8)
> Comment on attachment 49548 [details]
> bugtest.f -- program evincing bug
>
> So, commit the test case to guard against regressions
> (since it is not immediatel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |10.3
Summary|Passing CHARACTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #10 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #12 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #13 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #12)
> Reduced test case:
>
> program main
> type global_model_state
> real, allocatable :: ps(:) [:]
> end type global_model_state
> type (global_model_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #14 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #13)
> (In reply to Thomas Koenig from comment #12)
> > Reduced test case:
> >
> > program main
> > type global_model_state
> > real, allocatable :: ps(:) [:]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #16 from Thomas Koenig ---
program random_weather
implicit none
type global_model_state
real, allocatable :: ps(:,:) [:,:]
end type global_model_state
integer :: nxslab, nyslab
type(global_model_state) :: ms_full
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #15 from Thomas Koenig ---
Next reduced test-case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #17 from Thomas Koenig ---
A bit more reduced (no derived types necessary):
program random_weather
implicit none
real, allocatable :: ps(:,:) [:,:]
integer :: nxslab, nyslab
integer :: npx
integer :: i, j
real, paramete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #18 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #21 from Thomas Koenig
|1
Status|UNCONFIRMED |WAITING
CC||tkoenig at gcc dot gnu.org
--- Comment #1 from Thomas Koenig ---
Seems to be fixed on current trunk:
$ cat bug.f90
program p
real :: y(3)
n=3
y = func(0.)
stop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #22 from Thomas Koenig ---
Hi Toon,
it took some time, but we finally figured out that it is actually
a bug in your program that is causing problems.
It has (shortened)
nxglobal = 72;
This sets the coarray nxglobal to 72 on every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #26 from Thomas Koenig ---
After 00c2e5d1c15c67fc2c9d9ed86bfa1f5aa13848cc ,
the segfault for too many images is now also fixed,
and your program runs as expected.
I'd say an important milestone has been reached :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26183
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
There is dg-set-target-env-var , which we could use to check that
the runtime behavior which depends on environment variables is
indeed
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Currently, we use GFC_INTEGER_LARGEST for a lot of integer I/O.
One place where things could be improved is gfc_itoa:
const char *
gfc_itoa (GFC_INTEGER_LARGEST n, char *buffer
|1
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Severity|normal |enhancement
Target Milestone|--- |11.0
Last reconfirmed||2020-12-01
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #11 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #10)
> Could this PR be closed as INVALID?
Yes, I think so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #26 from Thomas Koenig ---
Yep, it's implemented and works great.
For a simple "sum of digits" program in base ten, it's an acceleration
by more than a factor of two.
Thanks!
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following program
program main
implicit none
integer, parameter :: n = 10**7
integer :: u,v
integer, dimension(:), allocatable :: a
open (newunit=u,file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #2 from Thomas Koenig ---
The problem seems to be related to an early return from the read system call:
strace -e trace=open,read,close ./a.out
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\v\2\0\0\0\0\0"...,
832) = 832
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #3 from Thomas Koenig ---
The problem seems to be that we assume that a short read is always
an EOF, in read_block_direct:
if (unlikely ((ssize_t) nbytes != have_read_record))
{
/* Short read, e.g. if we hit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
Thomas Koenig changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #10 from Thomas Koenig ---
(In reply to anlauf from comment #9)
> The patch seems to regtest ok, but certainly needs some wider testing.
Actually, I think the bug is in io/unix.c:raw_read. That should take
care of repeating the reads
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
alloc_comp_1.f90 has
! { dg-do run }
!
! Allocatable scalar corrays were mishandled (ICE)
!
type t
integer, allocatable :: caf[:]
end type t
type(t) :: a
gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Thomas Koenig ---
Fixed by
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=bd0f0243869b3941a256ca0ea9c8aca141412f7e
Closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
Bug 83700 depends on bug 98156, which changed state.
Bug 98156 Summary: [Coarray] alloc_comp_1.f90 tests for wrong condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98156
What|Removed |Added
---
||tkoenig at gcc dot gnu.org
--- Comment #1 from Thomas Koenig ---
Here is a slight extension of your program, which also
checks the compile-time simplification. Can you tell me
what it does?
program main
implicit none
integer :: i,n
complex z, sq
complex, parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #5 from Thomas Koenig ---
What is the output of
#include
#include
int main()
{
_Complex float z, sq, sq2;
int n;
float a;
a = -1.;
for (n = 1; n < 10; n++)
{
a = a * 10;
z = a + _Complex_I * 1.0;
sq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #8 from Thomas Koenig ---
(In reply to dpozar from comment #6)
> Thomas,
> I am running that code in code blocks with MS visual C++ 2010, but I can't
> find the output - no console screen, and no output file that I can find.
What if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #10 from Thomas Koenig ---
I don't have a working mingw system myself, but I dusted off my cygwin
system for this, using their cross-compiler to mingw.
With
$ x86_64-w64-mingw32-gfortran.exe -static -static-libgfortran csqrt.f90
th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207
--- Comment #5 from Thomas Koenig ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561720.html
allows debugging of the generated variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Currently, gcc calls the (long and slow) division routines for 128-bit
integers twice when both the residual and the value is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282
--- Comment #1 from Thomas Koenig ---
And here is a version which uses two 64-bit numbers for calculation of he
sum of decimal digits as a benchmark for the division and modulo:
unsigned long digsum3 (myint x)
{
unsigned long ret;
__uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89256
--- Comment #2 from Thomas Koenig ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282#c1 for one
example how this could be done for small integers (base 10 in that
case). The solution with the precomputed tables is probably not feasible
f
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 49310
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49310&action=edit
config.log f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302
--- Comment #1 from Thomas Koenig ---
Created attachment 49311
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49311&action=edit
Output from the attempt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302
--- Comment #3 from Thomas Koenig ---
Comment on attachment 49313
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49313
configure.ac patch
Seems to work, at least the compilation is proceeding now.
Thanks for the quick fix!
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
With PR 97302 out of the way (fixed by Tobias' patch in that PR),
compilation now fails with
ld: error: unable to find li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #1 from Thomas Koenig ---
Created attachment 49315
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49315&action=edit
config.log from failed attempt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #2 from Thomas Koenig ---
Created attachment 49316
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49316&action=edit
output from compilation that failed with -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Thomas Koenig changed:
What|Removed |Added
Component|bootstrap |target
--- Comment #3 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #9 from Thomas Koenig ---
WORKSFORME on OpenBSD 6.7.
NCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 49318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49318&action=edi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
--- Comment #2 from Thomas Koenig ---
Created attachment 49319
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49319&action=edit
config.log from gmp subdirectory
Here it is.
For what it is worth, I now tried bootstrapping with CC=cc and CX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
--- Comment #4 from Thomas Koenig ---
Created attachment 49320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49320&action=edit
config.log from failing libgomp
OK, so that one isn't a bug.
I hope you don't mind if I put in the next failur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
Thomas Koenig changed:
What|Removed |Added
Component|fortran |bootstrap
--- Comment #7 from Thomas Koe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Thomas Koenig changed:
What|Removed |Added
Component|target |bootstrap
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #8 from Thomas Koenig ---
(In reply to Andreas Tobler from comment #7)
> Any news on this? Or can we close this PR?
Neither. As far as I can determine, this still fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065
--- Comment #13 from Thomas Koenig ---
(In reply to Gabor from comment #10)
> Good to know that gfortran has come to an end. It means, for example, that
> i will not rely on the openacc implementation either. Or openmp5.
Those two fields are act
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Consider
program main
character (len=:), allocatable :: a(:)
allocate (character(len=10) :: a(5))
end program main
This yields (in the tree dump)
D.3941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93114
--- Comment #3 from Thomas Koenig ---
Probably a better idea:
If the span can be shown at compile-time to be a multiple of
the size of the component, we need not create the temporaray array
and instead set the strides of the descriptor according
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648
Thomas Koenig changed:
What|Removed |Added
Blocks||37336
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
||tkoenig at gcc dot gnu.org
--- Comment #3 from Thomas Koenig ---
At least something that works on the shared coarray branch :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
--- Comment #3 from Thomas Koenig ---
Could you simply post the complete C++ source code that you used
in the original example? This has the advantages of a) making it easier
to modify (for a non-C++-person such as me) and b) of conforming
to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
Severity|normal
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Consider
void foo (int *);
void bar (int n)
{
int i;
for (i=0; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
Thomas Koenig changed:
What|Removed |Added
Version|unknown |11.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
--- Comment #2 from Thomas Koenig ---
(In reply to Tobias Schlüter from comment #1)
> There's a typo in the example, /= instead of !=. Fixed example below:
The disease of a Fortran programmer writing C, I guess :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480
--- Comment #4 from Thomas Koenig ---
(In reply to Janne Blomqvist from comment #3)
> Actually, libgfortran already has a version of stat with integer(kind=int64)
> arguments. If you compile with -fdefault-integer-8 you get that one, and the
> ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
--- Comment #4 from Thomas Koenig ---
Yes, I think that translating a DO loop into something like
int i;
for (i=0; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66910
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 66910, which changed state.
Bug 66910 Summary: allocatable character in derived type gives segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66910
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
||tkoenig at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #7 from Thomas Koenig ---
I think the documentation for this is adequate:
1.3 Preprocessing and conditional compilation
=
Many Fortran
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Thomas Koenig ---
The test case works, I have committed it as
https://gcc.gnu.org/pipermail/gcc-cvs/2021-January/341018.html
to make sure it does not regress.
Thanks for the
||tkoenig at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #2 from Thomas Koenig ---
The code has been fixed in the meantime. I have committed the
test case as r11-6899-g7d54cccad332074d5fb81123796239f0f61b11a7
to make sure there is no
||tkoenig at gcc dot gnu.org
--- Comment #3 from Thomas Koenig ---
I just ran this through nagfor, and it agrees with gfortran.
Nagfor is usually quite picky.
xlf, on the other hand, agrees with you, so it does not seem
to be straightforward, at least.
This will take some further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 93925, which changed state.
Bug 93925 Summary: Invalid memory reference upon call of a routine taking a
procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925
What|Removed
3301 - 3400 of 3756 matches
Mail list logo
