public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "adelson.oliveira at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/109641] New: Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones. Date: Thu, 27 Apr 2023 01:41:48 +0000 [thread overview] Message-ID: <bug-109641-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641 Bug ID: 109641 Summary: Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones. Product: gcc Version: og10 (devel/omp/gcc-10) Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: adelson.oliveira at gmail dot com Target Milestone: --- Created attachment 54929 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54929&action=edit A small FORTRAN code to reproduce the bug I'm uploading a small fortran code to show the problem. The code has a module that overloads intrinsic operator (*) for a vector matrix multiplication. The bug is triggered when the matrix (and the result) is complex. The compilation with $ gfortran -o teste -O teste.f90 will fail with a error message reporting inconsistent rank declaration. As indicated in the snippet, simply changing from COMPLEX to REAL in the declaration of the matrix (and the result) everything goes fine. As an additional information, if one changes from the intrinsic (*) to something like (.MULT.) in the module then there is no error at all. Please look for the comments in the MODULE TESTEOP and in the PROGRAM TESTE to better test the bug. Thanks for any help
next reply other threads:[~2023-04-27 1:41 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-27 1:41 adelson.oliveira at gmail dot com [this message] 2023-04-27 18:04 ` [Bug fortran/109641] " anlauf at gcc dot gnu.org 2023-04-27 19:21 ` anlauf at gcc dot gnu.org 2023-04-27 20:15 ` anlauf at gcc dot gnu.org 2023-04-27 20:54 ` anlauf at gcc dot gnu.org 2023-04-28 0:34 ` adelson.oliveira at gmail dot com 2023-04-28 1:15 ` kargl at gcc dot gnu.org 2023-04-28 1:35 ` adelson.oliveira at gmail dot com 2023-04-28 1:37 ` adelson.oliveira at gmail dot com 2023-04-28 2:21 ` sgk at troutmask dot apl.washington.edu 2023-04-28 21:07 ` anlauf at gcc dot gnu.org 2023-04-29 2:20 ` adelson.oliveira at gmail dot com 2023-04-29 19:00 ` anlauf at gcc dot gnu.org 2023-04-30 2:55 ` adelson.oliveira at gmail dot com 2023-04-30 23:19 ` adelson.oliveira at gmail dot com 2023-05-01 16:31 ` anlauf at gcc dot gnu.org 2023-05-05 19:23 ` cvs-commit at gcc dot gnu.org 2023-05-18 16:54 ` cvs-commit at gcc dot gnu.org 2023-05-18 17:01 ` anlauf at gcc dot gnu.org 2023-05-19 0:41 ` adelson.oliveira 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-109641-4@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).