https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91422
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Tue Aug 13 10:05:44 2019
New Revision: 274369
URL: https://gcc.gnu.org/viewcvs?rev=274369=gcc=rev
Log:
2019-08-13 Thomas Koenig
Backport from trunk
PR fortran/91424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Tue Aug 13 10:05:44 2019
New Revision: 274369
URL: https://gcc.gnu.org/viewcvs?rev=274369=gcc=rev
Log:
2019-08-13 Thomas Koenig
Backport from trunk
PR fortran/91424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91422
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Mon Aug 12 20:21:37 2019
New Revision: 274320
URL: https://gcc.gnu.org/viewcvs?rev=274320=gcc=rev
Log:
2019-08-12 Thomas Koenig
PR fortran/91424
* frontend-passes.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Mon Aug 12 20:21:37 2019
New Revision: 274320
URL: https://gcc.gnu.org/viewcvs?rev=274320=gcc=rev
Log:
2019-08-12 Thomas Koenig
PR fortran/91424
* frontend-passes.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424
--- Comment #4 from Thomas Koenig ---
(In reply to Eric Gallager from comment #2)
> - the "2" location marker is a different color from the "1" location marker,
> if you have colorized output
That is now PR 91426.
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following program
program main
10 continue
10 continue
end
yields
label.f90:2:2:
2 | 10 continue
| 1
3 | 10 continue
| 2
Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424
--- Comment #3 from Thomas Koenig ---
(In reply to Eric Gallager from comment #2)
> Also:
> - there's no option flag controlling the warning
That one is by design. There is no way that this can even
be valid code.
> - the "2" location marker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424
--- Comment #1 from Thomas Koenig ---
A third problem: Zero-trip do loops are warned about.
program main
implicit none
integer :: i
real :: a(2)
do i=1,3,-1
a(i) = 2.
end do
print *,a
end program main
gets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91422
Thomas Koenig changed:
What|Removed |Added
Blocks||91424
--- Comment #2 from Thomas Koenig
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Currently, there are two problems with the warnings about DO loop
indices accessing arrays with out of bounds errors:
- They are not given for contained procedures
- They are given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91422
--- Comment #1 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #0)
> Hi,
>
> I get
the error with
gfortran -g -cpp -fcheck=all routine-7.f90
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Hi,
I get
At line 116 of file routine-7.f90
Fortran runtime error: Index '9' of dimension 1 of array 'a' above upper bound
of 8
||2019-08-10
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Thomas Koenig ---
Confirmed.
||2019-08-07
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Thomas Koenig ---
The first one, with the two different calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #37 from Thomas Koenig ---
Author: tkoenig
Date: Sat Aug 3 11:50:39 2019
New Revision: 274038
URL: https://gcc.gnu.org/viewcvs?rev=274038=gcc=rev
Log:
2019-08-03 Thomas Koenig
Paul Thomas
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #13 from Thomas Koenig ---
Author: tkoenig
Date: Sat Aug 3 11:50:39 2019
New Revision: 274038
URL: https://gcc.gnu.org/viewcvs?rev=274038=gcc=rev
Log:
2019-08-03 Thomas Koenig
Paul Thomas
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #12 from Thomas Koenig ---
Author: tkoenig
Date: Fri Aug 2 17:51:45 2019
New Revision: 274026
URL: https://gcc.gnu.org/viewcvs?rev=274026=gcc=rev
Log:
2019-08-02 Thomas Koenig
Paul Thomas
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #36 from Thomas Koenig ---
Author: tkoenig
Date: Fri Aug 2 17:51:45 2019
New Revision: 274026
URL: https://gcc.gnu.org/viewcvs?rev=274026=gcc=rev
Log:
2019-08-02 Thomas Koenig
Paul Thomas
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #34 from Thomas Koenig ---
Author: tkoenig
Date: Tue Jul 30 19:11:03 2019
New Revision: 273913
URL: https://gcc.gnu.org/viewcvs?rev=273913=gcc=rev
Log:
2019-07-29 Thomas Koenig
Paul Thomas
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #11 from Thomas Koenig ---
Author: tkoenig
Date: Tue Jul 30 19:11:03 2019
New Revision: 273913
URL: https://gcc.gnu.org/viewcvs?rev=273913=gcc=rev
Log:
2019-07-29 Thomas Koenig
Paul Thomas
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #6 from Thomas Koenig ---
(In reply to Xiong Hu XS Luo from comment #4)
> /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
> :(.text+0x114): undefined reference to `_gfortran_st_write'
> :(.text+0x12c): undefined reference to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #33 from Thomas Koenig ---
Author: tkoenig
Date: Mon Jul 29 17:45:24 2019
New Revision: 273880
URL: https://gcc.gnu.org/viewcvs?rev=273880=gcc=rev
Log:
2019-07-29 Thomas Koenig
PR fortran/90813
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Thu Jul 25 16:24:00 2019
New Revision: 273807
URL: https://gcc.gnu.org/viewcvs?rev=273807=gcc=rev
Log:
2019-07-25 Thomas Koenig
PR fortran/65819
* dependency.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #31 from Thomas Koenig ---
(In reply to rguent...@suse.de from comment #30)
> So something is odd with how the frontend handles 'c_'.
>
> The symbol table has two:
>
> __f_MOD_c_/2 (c_) @0x7f763892d300
> Type: variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819
--- Comment #6 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #5)
> Fixing the dependency for identical=true is a Good Thing(TM), but
> will not be enough to fix the test case:
Hm, another thought.
For this special case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819
--- Comment #5 from Thomas Koenig ---
Fixing the dependency for identical=true is a Good Thing(TM), but
will not be enough to fix the test case:
$ cat bar.f90
program main
implicit none
real, dimension(3,3,3) :: f,g
integer :: three
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #29 from Thomas Koenig ---
(In reply to rguent...@suse.de from comment #28)
> -fdump-tree-all-uid without the space
OK, so this works.
What we have in the *.004t.original dump is
fs ();
{
struct __class_f_S_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #41 from Thomas Koenig ---
Author: tkoenig
Date: Tue Jul 23 08:57:45 2019
New Revision: 273727
URL: https://gcc.gnu.org/viewcvs?rev=273727=gcc=rev
Log:
2019-07-23 Thomas König
Backport from trunk
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #40 from Thomas Koenig ---
Author: tkoenig
Date: Sun Jul 21 15:55:49 2019
New Revision: 273643
URL: https://gcc.gnu.org/viewcvs?rev=273643=gcc=rev
Log:
2019-07-21 Thomas König
PR libfortran/91030
* gfortran.texi
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!
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=91084
--- Comment #4 from Thomas Koenig ---
~/trunk $ svn diff contrib/
Index: contrib/download_prerequisites
===
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #3 from Thomas Koenig ---
~/trunk $ svn diff contrib/
Index: contrib/download_prerequisites
===
---
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.
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 #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?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077
Thomas Koenig changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Thomas
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
Target Milestone|--- |8.4
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=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
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 #21 from Thomas Koenig ---
Created attachment 46537
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46537=edit
Something to benchmark.
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 #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
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
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
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
real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #7 from Thomas
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
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
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
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
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=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=90813
Thomas Koenig changed:
What|Removed |Added
Priority|P4 |P3
--- Comment #16 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Thomas Koenig changed:
What|Removed |Added
Component|fortran |rtl-optimization
--- Comment #14 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #12 from Thomas Koenig ---
Another data point.
If the test case is split across two files (the module separate
from the main program), then it works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Thomas Koenig changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #10 from Thomas Koenig ---
I checked the *.optimized dump on POWER and x86_64 against each
other, and there are no differences (some renumbering of variables,
that's all).
Looking further...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #47 from Thomas Koenig ---
(In reply to Kaz Kylheku from comment #45)
> Hi everyone.
>
> Pardon my ignorance of C-Fortran bridging matters, but does any of the
> following make sense?
>
> The Fortran subroutine has no idea whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
--- Comment #9 from Thomas Koenig ---
Author: tkoenig
Date: Fri Jun 21 19:32:23 2019
New Revision: 272566
URL: https://gcc.gnu.org/viewcvs?rev=272566=gcc=rev
Log:
2019-06-21 Thomas Koenig
Backport from trunk
PR fortran/90937
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Fri Jun 21 19:30:51 2019
New Revision: 272565
URL: https://gcc.gnu.org/viewcvs?rev=272565=gcc=rev
Log:
2019-06-21 Thomas Koenig
Backport from trunk
PR fortran/90937
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Fri Jun 21 19:28:54 2019
New Revision: 272564
URL: https://gcc.gnu.org/viewcvs?rev=272564=gcc=rev
Log:
2019-06-21 Thomas Koenig
Backport from trunk
PR fortran/90937
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #31 from Thomas Koenig ---
(
> this patch makes Fortran logicals to become C unsigned types of
> corresponding size. I think it is better than making them signed
> because the globbing will affect aliasing within Fortran programs as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
Thomas Koenig changed:
What|Removed |Added
Summary|[7/8/9/10 Regression] ICE: |[7/8/9 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Thu Jun 20 11:56:50 2019
New Revision: 272506
URL: https://gcc.gnu.org/viewcvs?rev=272506=gcc=rev
Log:
2019-06-20 Thomas Koenig
PR fortran/90937
* trans-types.c
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #29 from Thomas Koenig ---
Created attachment 46493
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46493=edit
Patch to put all libgfortran functions into a namespace
This is something we should be doing as part of making
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90870
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90870
--- Comment #1 from Thomas Koenig ---
Author: tkoenig
Date: Thu Jun 13 17:00:22 2019
New Revision: 272249
URL: https://gcc.gnu.org/viewcvs?rev=272249=gcc=rev
Log:
2019-06-13 Thomas Koenig
PR fortran/90870
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #10 from Thomas Koenig ---
Author: tkoenig
Date: Wed Jun 12 20:08:38 2019
New Revision: 272214
URL: https://gcc.gnu.org/viewcvs?rev=272214=gcc=rev
Log:
2019-06-12 Thomas Koenig
Tomáš Trnka
Backport from trunk
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #9 from Thomas Koenig ---
Author: tkoenig
Date: Wed Jun 12 19:54:34 2019
New Revision: 272213
URL: https://gcc.gnu.org/viewcvs?rev=272213=gcc=rev
Log:
2019-06-12 Thomas Koenig
Tomáš Trnka
Backport from trunk
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Tue Jun 11 22:04:10 2019
New Revision: 272173
URL: https://gcc.gnu.org/viewcvs?rev=272173=gcc=rev
Log:
2019-06-11 Thomas Koenig
Tomáš Trnka
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #9 from Thomas Koenig ---
The segfault occurs at
35res => c_()
according to gdb.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #8 from Thomas Koenig ---
Stepping through the assembly, the segfaulting instruction is
"blr x3", which jumps to a NULL pointer, with predictable results:
│165 // proc_ptr_51.f90:30: end module f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #7 from Thomas Koenig ---
Created attachment 46475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46475=edit
Assembly for test case on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #28 from Thomas Koenig ---
(In reply to Jan Hubicka from comment #27)
> >
> > I think that's reasonably easy to do for LTO. We'd want to keep
> > the default boolean_type_node size BOOLEAN_TYPEs separate but
> > can glob larger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #5 from Thomas Koenig ---
(In reply to ktkachov from comment #4)
> LTO'ing libgfortran aside, how much work would it be to teach the scalarizer
> to at least elide the temporary arrays in expressions like:
> A(:) = minloc(...) ?
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Sat Jun 8 13:50:42 2019
New Revision: 272082
URL: https://gcc.gnu.org/viewcvs?rev=272082=gcc=rev
Log:
2019-06-08 Thomas Koenig
Tomáš Trnka
PR fortran/90744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #6 from Thomas Koenig ---
(In reply to Tomáš Trnka from comment #5)
> (In reply to Thomas Koenig from comment #4)
> > Good analysis, and this is indeed the correct fix.
>
> OK. I thought that perhaps get_formal_from_actual_arglist()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #4 from Thomas Koenig ---
(In reply to Tomáš Trnka from comment #3)
> I'm not sure how to fix this properly, but the following one-liner seems to
> work for me:
>
> --- a/gcc/fortran/trans-types.c
> +++ b/gcc/fortran/trans-types.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #25 from Thomas Koenig ---
(In reply to Jan Hubicka from comment #24)
> Hi,
> actually it won't help since C has only one bool type and not bools in
> different sizes (why would one need that?).
"Because it's in the Fortran language
||2019-06-05
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
I see this too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #21 from Thomas Koenig ---
(In reply to Jan Hubicka from comment #20)
> OK, the mismatched declaration types are:
> void (struct array01_integer(kind=4) &, float & restrict,
> logical(kind=4) *)
> and
> void (struct gfc_array_i4 *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #19 from Thomas Koenig ---
(In reply to rguent...@suse.de from comment #15)
Btw, I wonder what happens at
> the call boundary inside a single fortran module where
> the caller passes a dim[2] array to a subroutine
> handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #18 from Thomas Koenig ---
Created attachment 46451
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46451=edit
Preprocessed source of library file for LTO mismatch
Hi,
here is a test case (preprocessed source from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #12 from Thomas Koenig ---
In libgfortran, we have
#define GFC_ARRAY_DESCRIPTOR(type) \
struct {\
type *base_addr;\
size_t offset;\
dtype_type dtype;\
index_type span;\
descriptor_dimension dim[];\
}
and then later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #9 from Thomas Koenig ---
Created attachment 46446
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46446=edit
LTO tree dump from simple test case
So, I tried out a simple program:
$ cat minloc.f90
program main
real,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #6 from Thomas Koenig ---
So, I played around with this a little. By putting in
-flto and -ffat-lto-binaries into CFLAGS, FFLAGS and LDFLAGS
into the Makefile in the libgfortran build directory, it is
possible to build an LTO-enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #5 from Thomas Koenig ---
One thing we would also have to tackle is GFC_LOGICAL arguments.
C only has one bool type, which is (for gcc) equivalent to
logical(kind=1). We might just get by with
typedef enum { _zero=1, _one=1 }
901 - 1000 of 3578 matches
Mail list logo
