public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rdapp at linux dot ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/104335] [12 regression] build failure if go is included in languages after r12-6747
Date: Wed, 02 Feb 2022 10:17:50 +0000 [thread overview]
Message-ID: <bug-104335-4-UqqEyhqxAX@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-104335-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
rdapp at linux dot ibm.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rdapp at linux dot ibm.com
--- Comment #1 from rdapp at linux dot ibm.com ---
The problem is that we pass a CC comparison to rs6000_emit_cmove (). In the
sequence before it will return false via
if (FLOAT_MODE_P (compare_mode) && !FLOAT_MODE_P (result_mode))
because compare_mode == SFmode and result_mode == DImode.
Now it continues with compare_mode == CCFPmode and result_mode still DImode.
Finally, in rs6000_generate_compare the validation fails.
It looks like this function does not expect CC comparison. It looks like you
always try to generate one in the .md file already, regardless of whether the
incoming comparison already is a CC comparison or not.
I'm not really sure how to proceed. I guess CCFPmode is not a real FLOAT_MODE
but maybe we should not continue at this point anyway? Or would we need some
other mechanism now to make backends aware that this situation can occur now?
I haven't checked all of them but I was expecting the backend to just return
NULL_RTX if it cannot handle a specific combination of ops.
next prev parent reply other threads:[~2022-02-02 10:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-01 21:04 [Bug target/104335] New: " seurer at gcc dot gnu.org
2022-02-01 21:18 ` [Bug target/104335] " wschmidt at gcc dot gnu.org
2022-02-02 9:55 ` rguenth at gcc dot gnu.org
2022-02-02 10:17 ` rdapp at linux dot ibm.com [this message]
2022-02-02 10:25 ` marxin at gcc dot gnu.org
2022-02-02 23:00 ` segher at gcc dot gnu.org
2022-02-03 7:26 ` rdapp at linux dot ibm.com
2022-02-03 18:59 ` segher at gcc dot gnu.org
2022-02-10 15:03 ` rdapp at linux dot ibm.com
2022-02-10 15:04 ` rdapp at linux dot ibm.com
2022-02-10 16:51 ` segher at gcc dot gnu.org
2022-02-17 19:01 ` cvs-commit at gcc dot gnu.org
2022-02-23 23:40 ` meissner at gcc dot gnu.org
2022-03-11 9:57 ` jakub at gcc dot gnu.org
2022-03-14 18:59 ` seurer at gcc dot gnu.org
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-104335-4-UqqEyhqxAX@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: link
Be 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).