https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #50 from Thomas Koenig ---
Author: tkoenig
Date: Sun Jun 2 15:18:22 2019
New Revision: 271844
URL: https://gcc.gnu.org/viewcvs?rev=271844=gcc=rev
Log:
2019-06-02 Thomas Koenig
PR fortran/90539
* trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #49 from Martin Liška ---
(In reply to Martin Liška from comment #48)
> I see the performance is back as seen here:
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=21.270.0
>
> -Ofast periodic tester hasn't finished yet,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Martin Liška changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #47 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #46 from Thomas Koenig ---
Let's see if the failures go away (they should) and also what the
performance impact is now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #45 from Thomas Koenig ---
Author: tkoenig
Date: Wed May 29 20:30:45 2019
New Revision: 271751
URL: https://gcc.gnu.org/viewcvs?rev=271751=gcc=rev
Log:
2019-05-29 Thomas Koenig
PR fortran/90539
* gfortran.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Keywords||patch, wrong-code
--- Comment #44 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #43 from Martin Liška ---
(In reply to Thomas Koenig from comment #42)
> Created attachment 46428 [details]
> Patch which should finally work
>
> So, this does not regress, apparently.
>
> Martin, could you give this one a shot?
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Attachment #46427|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #41 from Thomas Koenig ---
Just noticed that this causes a regression in
gfortran.fortran-torture/execute/arrayarg.f90 , but only at certain
optimization levels.
Oh well... need to look some more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Attachment #46420|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #38 from Thomas Koenig ---
So, I finally have a self-contained test case:
module t2
implicit none
contains
subroutine foo(a)
real, dimension(*) :: a
end subroutine foo
end module t2
module t1
use t2
implicit none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #37 from Thomas Koenig ---
Hm, with that patch, there still seems to be a failure in netcdf :-(
I will keep looking (possibly some small problem with the patch).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #36 from Thomas Koenig ---
... which should be
Index: testsuite/gfortran.dg/internal_pack_21.f90
===
--- testsuite/gfortran.dg/internal_pack_21.f90 (Revision 271629)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #35 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #34)
> Created attachment 46420 [details]
> Patch which includes a check for being contiguous
>
> This patch looks like it could do the job. I'll have to work a bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #34 from Thomas Koenig ---
Created attachment 46420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46420=edit
Patch which includes a check for being contiguous
This patch looks like it could do the job. I'll have to work a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #33 from Martin Liška ---
(In reply to Thomas Koenig from comment #32)
> Hi Martin,
>
> this
>
> 3822 ierr = pio_put_var (tape(t)%File, ps0var, (/ps0/))
>
> looks like the culprit (or rather, where gfortran currently
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #32 from Thomas Koenig ---
Hi Martin,
this
3822 ierr = pio_put_var (tape(t)%File, ps0var, (/ps0/))
looks like the culprit (or rather, where gfortran currently
generates wrong code). This is consistent with the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #31 from Martin Liška ---
I see this:
(gdb) frame
#2 0x00453b06 in pionfput_mod::put_var_vdesc_1d_double (file=...,
vardesc=..., ival=...) at pionfput_mod.fppized.f90:2468
2468ierr = put_var_1d_double (File,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #30 from Thomas Koenig ---
Hi,
what I mean is if you use "up" several times and list the
source of the calling routines, do you encounter something like
call foo([1.0, 2.0, 3.0, 4.0])
or
call foo((/1.0, 2.0, 3.0, 4.0/))
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #29 from Martin Liška ---
(In reply to Thomas Koenig from comment #28)
> https://gcc.gnu.org/ml/fortran/2019-05/msg00173.html reports
> the same symptoms for netcdf-fortran-4.4.5, presumably due
> to the same issue.
>
> I'll try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Martin Liška changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #26 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 26 14:02:51 2019
New Revision: 271630
URL: https://gcc.gnu.org/viewcvs?rev=271630=gcc=rev
Log:
2019-05-26 Thomas Koenig
PR fortran/90539
* trans-types.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #25 from Martin Liška ---
(In reply to Thomas Koenig from comment #22)
> I've been trying out some things, and I cannot construct a failing
> test case.
>
> A sane way to build such an interface would be
>
> cat tst.f90
> module x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #24 from Martin Liška ---
One another note is that the problematic code lives in src/netcdf/* and the
same code contain:
benchspec/CPU/521.wrf_r/src/netcdf/
and
benchspec/CPU/628.pop2_s/src/netcdf/
So that would explain also the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #23 from Martin Liška ---
(In reply to Thomas Koenig from comment #21)
> OK, if the callee is a C function... what is its declaration
> on the Fortran side? Is there any interface, bind(c) or otherwise?
>
> I suppose there must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #22 from Thomas Koenig ---
I've been trying out some things, and I cannot construct a failing
test case.
A sane way to build such an interface would be
cat tst.f90
module x
use, intrinsic :: iso_c_binding, only : c_double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #21 from Thomas Koenig ---
OK, if the callee is a C function... what is its declaration
on the Fortran side? Is there any interface, bind(c) or otherwise?
I suppose there must be something, otherwise nf_put_vara_double would
have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #20 from Martin Liška ---
(In reply to Thomas Koenig from comment #19)
> Thanks.
>
> A bit more:
>
> What are the declarations of the actual srgument,
> of the dummy argument (on the callee side),
> and what is the argument in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #19 from Thomas Koenig ---
Thanks.
A bit more:
What are the declarations of the actual srgument,
of the dummy argument (on the callee side),
and what is the argument in the call list?
Ill try to construct a test case tonight
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #18 from Martin Liška ---
$ cat -n netcdf/netcdf_expanded.f90:
...
1470 print *,shape(values)
1471 print *,size(values)
1472 print *,is_contiguous(values)
1473
1474 nf90_put_var_1D_EightByteReal = &
1475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #17 from Martin Liška ---
(In reply to Thomas Koenig from comment #16)
> Hi Martin,
>
> Is this for the slowdown or for the wrong-code issue?
It's the wrong code for cam4_r benchmark.
>
> To get another view, from a gdb seesion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #16 from Thomas Koenig ---
Hi Martin,
Is this for the slowdown or for the wrong-code issue?
To get another view, from a gdb seesion of the compiler:
call debug(expr)
call debug(fsym)
a look at expr->symtree->n.sym (I think call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #15 from Martin Liška ---
Resulting difference in original dump file is:
BEFORE:
D.20757 = _gfortran_internal_pack ();
__result_nf90_put_var_1d_eigh = nf_put_vara_double
((integer(kind=4) *) ncid,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #14 from Martin Liška ---
Ok, so I isolated that to a single file and one gfc_conv_subref_array_arg call.
Problematic file is netcdf/netcdf.f90 and the gfc_conv_subref_array_arg call
happens
for:
(gdb) p *expr
$3 = {
expr_type =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #13 from Thomas Koenig ---
I'm afraid the tree dumps will not help a lot - I know what they
look like before and after, but I don't know what is wrong with it.
I would therefore ask you to reduce the test case, maybe starting
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #11 from Martin Liška ---
Created attachment 46394
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46394=edit
521.wrf_r valgrind report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #12 from Martin Liška ---
Created attachment 46395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46395=edit
527.cam4_r valgrind report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #10 from Martin Liška ---
(In reply to Thomas Koenig from comment #8)
> (In reply to Martin Liška from comment #6)
> > So there's somebody who is having the file in a public git repository.
> > That's probably violating SPEC rules :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #8 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #7 from Martin Liška ---
Note that patch is also responsible for 521.wrf_r segfault with -Ofast
-march=native on a Zen machine (with ulimit -s == unlimited):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #5 from Martin Liška ---
Ok, looking at perf report:
$ head -n20 before.report.txt
# Overhead Command Shared ObjectSymbol
# ... ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #3 from Thomas Koenig ---
I think I have an idea what might be the problem.
Does the code do something like
call foo(a)
...
subroutine foo(a)
real, dimension(:) :: a
call bar(a,size(n))
...
subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #2 from Thomas Koenig ---
I am a bit surprised at this, that the library version
of packing seems to be faster than the inlined one.
Or maybe some argument is now packed which should not be.
Increased code size is sort of expected,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #1 from Richard Biener ---
Haswell as well
(https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/recent.html)
but only 10% and not bisected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
51 matches
Mail list logo
