ignee: unassigned at gcc dot gnu.org
Reporter: fx at gnu dot org
Target Milestone: ---
I was reminded by comments on the report I made about poor fmod performance on
x86 that I should have commented on the original observation.
I'd looked at one of the Polyhedron benchmarks whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
--- Comment #4 from Dave Love ---
On further consideration, perhaps this is just a Fortran issue. I thought
-ffast-math should turn off all the relevant checks to allow reducing mod to
the arithmetic expression, but it probably doesn't. Also,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
--- Comment #3 from Dave Love ---
Created attachment 51709
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51709&action=edit
gglx.s extract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
--- Comment #2 from Dave Love ---
Created attachment 51708
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51708&action=edit
ggl.s extract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
--- Comment #1 from Dave Love ---
Created attachment 51707
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51707&action=edit
gglx.f90
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fx at gnu dot org
Target Milestone: ---
Target: x86_64
Created attachment 51706
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51706&action=edit
ggl.f90
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724
--- Comment #5 from Dave Love ---
Thanks for the explanation.
Could the manual entry for -fwhole-program just be amended to clarify that it's
a fallback for when a linker plugin isn't available for -flto. That may be
what it was intended to sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724
--- Comment #2 from Dave Love ---
The manual says not to use -flto with -fwhole-program. Is that misleading?
I checked self-built gfortran 10.2.0 again, and it definitely works for me
without -flto on Debian 10, but it fails with Red Hat devto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100725
--- Comment #2 from Dave Love ---
(In reply to Jakub Jelinek from comment #1)
> Those binutils are too old for dwarf5.
> When the linker doesn't print any diagnostics, that isn't a big deal, but if
> it needs to diagnose something and parse DWAR
Assignee: unassigned at gcc dot gnu.org
Reporter: fx at gnu dot org
Target Milestone: ---
Extending my example in #100724 with -g, I see a dwarf error, which I assume is
a separate issue:
$ cat test.f90
module tw
interface
real function twice (x)
end function twice
Assignee: unassigned at gcc dot gnu.org
Reporter: fx at gnu dot org
Target Milestone: ---
I found that trying gfortran -fwhole-program failed to link a case I tried,
with undefined references to routines with interface blocks. It's OK with
gfortran 10.
Here's a trivi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97160
Dave Love changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97160
--- Comment #2 from Dave Love ---
(In reply to Richard Biener from comment #1)
> gcc/fortran/f95-lang.c: if (targetm.libc_has_function (function_sincos))
I haven't checked why it's used there, but I concluded this wasn't a front end
issue from
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fx at gnu dot org
Target Milestone: ---
Target: ppc64le
Created attachment 49254
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49254&action=edit
Fortran benchmark
I looked at the other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #5 from Dave Love ---
I meant to show that x86_64 expands the built in fmod too. (I wasn't sure
whether "inline" was the right term, as it seems not to be done by
-finline-functions.)
Yes, xlf -O3 (?) and above imlies something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #4 from Dave Love ---
Created attachment 49249
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49249&action=edit
xlf -O5 -S
Assignee: unassigned at gcc dot gnu.org
Reporter: fx at gnu dot org
Target Milestone: ---
I ran some Fortran benchmarks (the "Polyhedron" set) on POWER9, and found one
of them has pathologically bad performance compared with xlf. Profiling shows
that's due to s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93253
--- Comment #4 from Dave Love ---
Apologies, I was misled by something else; that option does affect the result.
However, this change in behaviour isn't mentioned in release notes, the error
message doesn't point to that option, and documentatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93253
--- Comment #3 from Dave Love ---
You wrote:
> Do you read the document that comes with your compiler?
Do you appreciate how that sort of response sounds is likely to drive
people off (not for the first time)?
I read two sets of release notes
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: fx at gnu dot org
Target Milestone: ---
I tried to build the NAS benchmarks with snapshot 'GNU Fortran (GCC) 10.0.0
20200105 (experimental)' and got:
cd ../common; gfortran-10 -c -Ofast -march=native -std=le
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: fx at gnu dot org
Target Milestone: ---
The behaviour of the "omp simd" pragma may be unexpected, and it would be
useful if it could be spelt out somewhere in the docs.
Experimentally, using the pragma w
21 matches
Mail list logo
