public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rimvydas.jas at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects Date: Mon, 30 Aug 2021 21:23:46 +0000 [thread overview] Message-ID: <bug-101918-4-UIlNcxp1WV@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-101918-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918 --- Comment #18 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> --- (In reply to Steve Kargl from comment #17) > There is Fortran code in libgfortran that is compiled > by gfortran when the compiler is built. Whether that > code works as intended when someone uses -fdefault-* > or -freal-* family options remains to be seen. Someone in this same PR previously recommended that only -freal-*-real-* options should be used. Now even those are getting flagged as being broken. > REAL(c_float) should map to > C's float. Fortunately, -fdefault-real-8 does not > promote REAL(c_float) (aka REAL(4)) to REAL(8); OTOH > -freal-4-real-8 will do the promotion. This is observed behavior and a main reason why -freal-*-real-* options (including integer ones) are virtually unusable in any bigger project that interfaces to C or even Rust modules. > The IEEE ARITHMETIC module is partially built on-the-fly > when compiling code with some information coming from files > in gcc/libgfortran/ieee. Those files are compiled when > gfortran is built. I don't know if anyone has extensively > tried these options with IEEE modules. We have used IEEE_ARITHMETIC and IEEE_EXCEPTIONS modules, seem to be performing OK, except for handling inexact exceptions, but it is a minor issue. > COMMON, EQUIVALENCE, BOZ, external subprogram, etc are related > because these are affected by mucking around with storage > association and the ABI. These are not an issue if one is using modern portable Fortran code where system and sometimes vendor specific tuning/optimizations/hacks can be more easily implemented in pure C using interface safety provided by ISO_C_BINDING intrinsic module, thus keeping Fortran part of the project portable. However, none of these actually help to get closer to the actual issue in this PR. There are many things that could go wrong in the world, but this PR is about trying to get the bottom of this single issue. The -ftree-dump-original from Comment #8 in bar.f90.005t.original: __attribute__((fn spec (". "))) void bar () { static real(kind=8) b[4] = {[0 ... 3]=1.0e+0}; real(kind=8) h[4]; { struct array02_real(kind=8) parm.0; struct array01_real(kind=8) parm.1; struct array01_real(kind=8) * D.3962; static integer(kind=8) A.2[2] = {2, 2}; struct array01_integer(kind=8) parm.3; struct array01_integer(kind=8) * D.3971; parm.0.span = 8; parm.0.dtype = {.elem_len=8, .rank=2, .type=3}; parm.0.dim[0].lbound = 1; parm.0.dim[0].ubound = 2; parm.0.dim[0].stride = 1; parm.0.dim[1].lbound = 1; parm.0.dim[1].ubound = 2; parm.0.dim[1].stride = 2; parm.0.data = (void *) &h[0]; parm.0.offset = -3; parm.1.span = 8; parm.1.dtype = {.elem_len=8, .rank=1, .type=3}; parm.1.dim[0].lbound = 1; parm.1.dim[0].ubound = 4; parm.1.dim[0].stride = 1; parm.1.data = (void *) &b[0]; parm.1.offset = -1; D.3962 = &parm.1; parm.3.span = 8; parm.3.dtype = {.elem_len=8, .rank=1, .type=1}; parm.3.dim[0].lbound = 1; parm.3.dim[0].ubound = 2; parm.3.dim[0].stride = 1; parm.3.data = (void *) &A.2[0]; parm.3.offset = -1; D.3971 = &parm.3; _gfortran_reshape_r8 (&parm.0, D.3962, D.3971, 0B, 0B); } } The tree dump for foo.f90 is identical + call to bar() and main() ofc. The most puzzling bit is why LTO sees a different information for _gfortran_reshape_r8() runtime intrinsic function?
next prev parent reply other threads:[~2021-08-30 21:23 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-15 8:41 [Bug fortran/101918] New: " rimvydas.jas at gmail dot com 2021-08-15 8:42 ` [Bug fortran/101918] " rimvydas.jas at gmail dot com 2021-08-15 15:36 ` kargl at gcc dot gnu.org 2021-08-16 9:15 ` rguenth at gcc dot gnu.org 2021-08-16 14:57 ` sgk at troutmask dot apl.washington.edu 2021-08-16 18:49 ` anlauf at gcc dot gnu.org 2021-08-16 21:34 ` sgk at troutmask dot apl.washington.edu 2021-08-30 10:26 ` rimvydas.jas at gmail dot com 2021-08-30 10:28 ` rimvydas.jas at gmail dot com 2021-08-30 14:34 ` sgk at troutmask dot apl.washington.edu 2021-08-30 14:39 ` kargl at gcc dot gnu.org 2021-08-30 14:48 ` kargl at gcc dot gnu.org 2021-08-30 15:23 ` rimvydas.jas at gmail dot com 2021-08-30 16:16 ` sgk at troutmask dot apl.washington.edu 2021-08-30 17:11 ` rimvydas.jas at gmail dot com 2021-08-30 18:26 ` sgk at troutmask dot apl.washington.edu 2021-08-30 19:08 ` rimvydas.jas at gmail dot com 2021-08-30 20:54 ` sgk at troutmask dot apl.washington.edu 2021-08-30 21:23 ` rimvydas.jas at gmail dot com [this message] 2021-08-30 22:18 ` sgk at troutmask dot apl.washington.edu 2021-08-30 22:26 ` rimvydas.jas at gmail dot com 2021-09-02 11:01 ` rimvydas.jas at gmail dot com 2021-09-02 11:02 ` rimvydas.jas at gmail dot com 2021-09-02 11:05 ` rimvydas.jas at gmail dot com 2021-09-02 11:06 ` rimvydas.jas at gmail dot com 2021-09-02 11:08 ` rimvydas.jas at gmail dot com 2021-09-12 19:12 ` rimvydas.jas at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-101918-4-UIlNcxp1WV@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).