https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64958
--- Comment #8 from Thomas Koenig ---
As long as we use a single file, it would be possible to
warn about this.
What we could do is to analyze dusty and check that its argument
n may be redefined. If it appears in a variable definition
context,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52274
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
Thomas Koenig changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
Thomas Koenig changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #4 from Thomas Koenig ---
(In reply to David Edelsohn from comment #3)
> Conversion carries an overhead, but the overhead need not be worse than
> necessary. The conversion overhead for libgfortran is significantly worse
> than for c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #6 from Thomas Koenig ---
I cannot reproduce this on an AMD Ryzen 7 1700X (little-endian):
$ gfortran -fconvert=native wr.f90 walltime.c
cc1: Warnung: command-line option »-fconvert=native« is valid for Fortran but
not for C
$ rm -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #7 from Thomas Koeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #9 from Thomas Koenig ---
On powerpc64le-unknown-linux-gnu:
write time(sec) = 0.48150300979614258
done
real0m0.889s
user0m0.279s
sys 0m0.608s
vs.
write time(sec) =1.4788339138031006
done
real0m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #11 from Thomas Koenig ---
(In reply to David Edelsohn from comment #10)
> With EXT4: difference is 2x
> With SHM: difference is 4.5x
> With GPFS: difference is 10x
>
> Is libgfortran doing something unusual with the creation of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #15 from Thomas Koenig ---
(In reply to David Edelsohn from comment #13)
> Why should -fconvert affect the strategy for writing?
If we get passed a contiguous block of memory (like in
your test case) we can do this in a single write.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #17 from Thomas Koenig ---
(In reply to David Edelsohn from comment #16)
> libgfortran unix.c:raw_write() will access the WRITE system call with up to
> 2GB of data, which the testcase is using for the native format.
>
> Should libgf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #20 from Thomas Koenig ---
(In reply to David Edelsohn from comment #18)
> For GPFS, the striping unit is 16M. The 8K buffer size chosen by GFortran
> is a huge performance sink. We have confirmed this with testing.
Could you share
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #21 from Thomas Koenig ---
Created attachment 46537
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46537&action=edit
Something to benchmark.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #23 from Thomas Koenig ---
Some numbers for the provisionary patch, varying the
size for the buffers.
With the patch, the original benchmark (minus some output, only
the elapsed time is shown) and the script
for a in 1024 2048 4096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #25 from Thomas Koenig ---
(In reply to Jerry DeLisle from comment #24)
> On a different Ryzen machine:
>
> $ ./run.sh
> 1024 3.2604169845581055
> 2048 2.7804551124572754
> 4096 2.6416599750518799
> 8192 2.598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #26 from Thomas Koenig ---
Jerry, you are working on a Linux box, right? What does
stat -f -c %b .
tell you?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |8.4
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
From a c.l.f. post by ygalkl...@gmail.com (slightly modified):
program test
implicit none
integer, parameter :: length = 9
real(8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077
Thomas Koenig changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Thomas Ko
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #28 from Thomas Koenig ---
(In reply to Jerry DeLisle from comment #27)
> (In reply to Thomas Koenig from comment #26)
> > Jerry, you are working on a Linux box, right? What does
> >
> > stat -f -c %b .
> >
> > tell you?
>
> 13429
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
It fails with
sha512sum: not found
(This can be tested on gcc220.fsffrance.org at the moment).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #30 from Thomas Koenig ---
> Why are you opposed to the larger 65536 or 131072 as a default?
Please look at Jerry's numbers from comment #24.
They show a severe regression (for his system) for blocksizes > 32768.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #3 from Thomas Koenig ---
~/trunk $ svn diff contrib/
Index: contrib/download_prerequisites
===
--- contrib/download_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #4 from Thomas Koenig ---
~/trunk $ svn diff contrib/
Index: contrib/download_prerequisites
===
--- contrib/download_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #34 from Thomas Koenig ---
There is another point to consider.
I suppose not very many people use big-endian data formats
these days. Little-endian dominates these days, and people
who require that conversion on a regular basis (why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #27 from Thomas Koenig ---
(In reply to Richard Biener from comment #26)
> The odd thing is that for the Fortran example even the tree oracle claims
> the store doesn't alias the load...
>
> Because they are different variables! Du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417
--- Comment #3 from Thomas Koenig ---
The idea of the warning is to ensure that we have
Location information everywhere, and that patches
Which do not correctly set the location should cause
something visible during testing. We do not have this f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417
--- Comment #3 from Thomas Koenig ---
The idea of the warning is to ensure that we have
Location information everywhere, and that patches
Which do not correctly set the location should cause
something visible during testing. We do not have this f
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 44368
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44368&action=edit
config.log from failed build
Recent trunk at r262520 failed to build on, it was con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417
--- Comment #11 from Thomas Koenig ---
(In reply to janus from comment #10)
> (In reply to janus from comment #9)
> > The following patch seems to be sufficient to fix the regression:
>
>
> ... however, it lacks a safety check for the existence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
--- Comment #9 from Thomas Koenig ---
(In reply to Jonathan Wakely from comment #7)
> These warnings have been present for weeks - the idea that they're suddenly
> preventing anybody from working on gfortran is odd. Why can't you use
> autoconf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
--- Comment #15 from Thomas Koenig ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Thomas Koenig from comment #9)
> > (In reply to Jonathan Wakely from comment #7)
> > > These warnings have been present for weeks - the idea that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
--- Comment #19 from Thomas Koenig ---
As a more long-term solution, I think that having -Werror on as the
default should actually be preferred, at least for those parts of
gcc which are clean at the moment.
If somebody then does something which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
--- Comment #21 from Thomas Koenig ---
(In reply to Jonathan Wakely from comment #20)
> For libstdc++ the default (without --enable-werror or --disable-werror) is
> to add $(WERROR_FLAG) to WARN_FLAGS. WERROR_FLAG is empty by default, but
> conta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
For division by small integers which fit into registers,
gcc uses quite a few tricks. For 128-bit integers, a function is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
--- Comment #1 from Thomas Koenig ---
Originally found by profiling Fortran code like
integer(16) :: i, j
...
j = i/2
and wondering why this took so long :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
--- Comment #54 from Thomas Koenig ---
Grepping for IN in the execution traces and then running
a diff reveals interesting things:
IN: __libc_start_main
IN: __libc_start_main
IN: _dl_discover_osversion
-IN: uname
-IN: uname
+IN: __uname
+IN:
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 44559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44559&action=edit
config.log from failed build
This is on gcc119.fsffrance.org, in case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87018
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |9.0
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Since r263082, array_constructor_8.f90 fails on armeb.
PR 25829 contains debugging info on that, see also
https://gcc.gnu.org/ml/fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87048
Thomas Koenig changed:
What|Removed |Added
Blocks||25829
Target Milestone|---
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87018
Thomas Koenig changed:
What|Removed |Added
Component|bootstrap |target
Summary|[9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837
--- Comment #5 from Thomas Koenig ---
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Fri Aug 24 17:26:57 2018
New Revision: 263838
URL: https://gcc.gnu.org/viewcvs?rev=263838&root=gcc&view=rev
Log:
2018-08-24 Thomas Koenig
PR fortran/86837
* frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Fri Aug 24 22:08:48 2018
New Revision: 263844
URL: https://gcc.gnu.org/viewcvs?rev=263844&root=gcc&view=rev
Log:
2018-08-24 Thomas Koenig
Backport from trunk
PR fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|UNCONFIRMED |NEW
Last reconfirmed||2018-08-25
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
Confirmed; valgrind shows uninitialized variables
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86704
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Sat Aug 25 21:31:30 2018
New Revision: 263856
URL: https://gcc.gnu.org/viewcvs?rev=263856&root=gcc&view=rev
Log:
2018-08-25 Thomas Koenig
PR libfortran/86704
* m4/m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86704
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sun Aug 26 12:02:28 2018
New Revision: 263861
URL: https://gcc.gnu.org/viewcvs?rev=263861&root=gcc&view=rev
Log:
2018-08-26 Thomas Koenig
Backport from trunk
PR libf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86704
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
--- Comment #12 from Thomas Koenig ---
Created attachment 44600
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44600&action=edit
Patch which has a problem
The attached patch shows how something could be done, but it
has one problem: The ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
Thomas Koenig changed:
What|Removed |Added
Attachment #44600|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Sun Sep 16 19:37:44 2018
New Revision: 264349
URL: https://gcc.gnu.org/viewcvs?rev=264349&root=gcc&view=rev
Log:
2018-09-16 Thomas Koenig
PR fortran/37802
* frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
Bug 27766 depends on bug 37802, which changed state.
Bug 37802 Summary: Improve wording for matmul bound checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
--- Comment #14 from Thomas Koenig ---
Author: tkoenig
Date: Tue Sep 18 19:59:46 2018
New Revision: 264411
URL: https://gcc.gnu.org/viewcvs?rev=264411&root=gcc&view=rev
Log:
2018-09-18 Thomas Koenig
PR fortran/29550
* gfortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
Bug 37131 depends on bug 29550, which changed state.
Bug 29550 Summary: Optimize -fexternal-blas calls for conjg()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
Bug 36854 depends on bug 29550, which changed state.
Bug 29550 Summary: Optimize -fexternal-blas calls for conjg()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
--- Comment #16 from Thomas Koenig ---
Author: tkoenig
Date: Tue Sep 18 20:18:09 2018
New Revision: 264412
URL: https://gcc.gnu.org/viewcvs?rev=264412&root=gcc&view=rev
Log:
2018-09-18 Thomas Koenig
PR fortran/29550
* gfortra
||tkoenig at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #1)
> Is there an easy way to check than a scalar pass-by-reference intent-in
> argument has been loaded at the beginning of the function?
Easiest to check the
,
||tkoenig at gcc dot gnu.org
--- Comment #1 from Thomas Koenig ---
Hi Paul,
just a heads-up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #4 from Thomas Koenig ---
After generating a lot of module files with -fsyntax-only
so make succeeds, and then running "make check" on the
reproducer, I get
|===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 25829, which changed state.
Bug 25829 Summary: [F03] Asynchronous IO support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #7 from Thomas Koenig ---
Well, I can confirm this. Output from valgrind shows as the first error:
Running test: event_transforms_1| Process library 'event_transforms_1_lib':
initialized
==23957== Invalid read of size 8
==23957==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359
--- Comment #8 from Thomas Koenig ---
Created attachment 44728
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44728&action=edit
Makefile for the shortened reproducer
Hi,
if you want to compile the reproducer, you can use this Makefile,
it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2013-03-29 00:00:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Sat Sep 22 18:44:01 2018
New Revision: 264506
URL: https://gcc.gnu.org/viewcvs?rev=264506&root=gcc&view=rev
Log:
2018-09-22 Thomas Koenig
PR fortran/41453
* trans.h
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
I was trying to debug PR 87395 a bit, and found that there was
an ICE now instead...
This is with r264506, so this is really recent. I have
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #2 from Thomas Koenig ---
Yes, r264506 it was. r264505 is OK.
So, next thing is to find out how to run a single compilation
from that rather big build system...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87395
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Sun Sep 23 10:52:27 2018
New Revision: 264512
URL: https://gcc.gnu.org/viewcvs?rev=264512&root=gcc&view=rev
Log:
2018-09-23 Thomas Koenig
PR fortran/87395
* gfc_conv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87395
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453
Bug 41453 depends on bug 87395, which changed state.
Bug 87395 Summary: [9 Regression] ICE in in lookup_field_for_decl with whizard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87395
What|Removed |Added
||2018-09-23
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
Let's see...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87397
--- Comment #2 from Thomas Koenig ---
Author: tkoenig
Date: Sun Sep 23 20:17:25 2018
New Revision: 264518
URL: https://gcc.gnu.org/viewcvs?rev=264518&root=gcc&view=rev
Log:
2018-09-23 Thomas Koenig
PR fortran/87397
* gfc_conv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87395
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Sun Sep 23 20:17:25 2018
New Revision: 264518
URL: https://gcc.gnu.org/viewcvs?rev=264518&root=gcc&view=rev
Log:
2018-09-23 Thomas Koenig
PR fortran/87397
* gfc_conv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87397
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87395
--- Comment #8 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #7)
> Bazinga! And now I might a number error again PR87259 -> PR87359.
There have been occasions where I thought that having a checksum
on PR numbers might have
||2018-09-24
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87401
--- Comment #2 from Thomas Koenig ---
Quite clear what is going on. The tree dump shows
assoc_intent_out ()
{
static void sub (real(kind=4) & restrict);
real(kind=4) r;
{
real(kind=4) * o;
o = &r;
o = {CLOBBER};
sub (o);
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
I'm seeing failures of the kind
FAIL: gfortran.dg/coarray_lib_alloc_4.f90 -O0 scan-tree-dump-times original
"_gfortran_caf_is_present \\(xx\
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87418
Thomas Koenig changed:
What|Removed |Added
CC||cesar at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87401
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Mon Sep 24 17:12:34 2018
New Revision: 264539
URL: https://gcc.gnu.org/viewcvs?rev=264539&root=gcc&view=rev
Log:
2018-09-24 Thomas Koenig
PR fortran/87397
* gfc_conv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87397
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Mon Sep 24 17:12:34 2018
New Revision: 264539
URL: https://gcc.gnu.org/viewcvs?rev=264539&root=gcc&view=rev
Log:
2018-09-24 Thomas Koenig
PR fortran/87397
* gfc_conv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87401
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87418
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #2 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #1)
> so we are generating a factor of 15 more code.
I mean 150.
,
||memory-hog
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-09-30
CC||tkoenig at gcc dot gnu.org
Target Milestone|--- |9.0
Summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453
--- Comment #5 from Thomas Koenig ---
Still missing: To clobber
- ariables passed by reference to the caller
- saved variables
- associated variables (there are passed as pointers to
the associate blocsk)
- intent(out) variables on entry to th
||2018-09-30
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Thomas Koenig ---
Would be useful, yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
--- Comment #7 from Thomas Koenig ---
Ah, I see where the problem is.
Consider the test case
module zero
implicit none
contains
subroutine foo(a)
real, contiguous :: a(:,:)
print *,a
end subroutine foo
subroutine bar(a)
real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
Thomas Koenig changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560
--- Comment #29 from Thomas Koenig ---
Author: tkoenig
Date: Mon Feb 12 20:13:30 2018
New Revision: 257602
URL: https://gcc.gnu.org/viewcvs?rev=257602&root=gcc&view=rev
Log:
2018-02-12 Thomas Koenig
PR fortran/68560
* gfortra
1701 - 1800 of 3746 matches
Mail list logo
