public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c Date: Wed, 07 Jun 2023 20:57:47 +0000 [thread overview] Message-ID: <bug-109886-4-ZijaRYr1bb@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-109886-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886 Andrew Macleod <amacleod at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amacleod at redhat dot com --- Comment #6 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Martin Jambor from comment #5) > (In reply to Aldy Hernandez from comment #4) > > (In reply to Andrew Pinski from comment #3) > > > That is correct. The generated code has a VIEW_CONVERT_EXR from an integer > > > type to a RECORD_TYPE. > > > > Eeeech. In that case, then what you suggest is reasonable. Bail if > > param_type is not supported by the underlying range. Maybe the IPA experts > > could opine? > > With LTOed type mismateches or with K&R style code, IPA has to be prepared > to deal with such cases, unfortunately. So a check like that indeed looks > reasonable. The new range-op dispatch code is coming shortly.. when an unsupported type is passed in to any ranger routine, we'll simply return false instead of trapping like we do now.
next prev parent reply other threads:[~2023-06-07 20:57 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-05-17 8:55 [Bug ipa/109886] New: " jamborm at gcc dot gnu.org 2023-05-17 19:07 ` [Bug ipa/109886] " pinskia at gcc dot gnu.org 2023-05-22 18:04 ` aldyh at gcc dot gnu.org 2023-05-22 18:07 ` pinskia at gcc dot gnu.org 2023-05-22 18:13 ` aldyh at gcc dot gnu.org 2023-05-23 16:14 ` jamborm at gcc dot gnu.org 2023-06-07 20:57 ` amacleod at redhat dot com [this message] 2023-06-08 12:27 ` jamborm at gcc dot gnu.org 2023-06-08 19:00 ` amacleod at redhat dot com 2023-06-09 9:00 ` jamborm at gcc dot gnu.org 2023-06-09 13:14 ` amacleod at redhat dot com 2023-06-09 13:58 ` amacleod at redhat dot com 2023-06-09 16:37 ` cvs-commit at gcc dot gnu.org 2023-06-10 1:44 ` amacleod at redhat dot com 2023-06-13 9:16 ` jamborm 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-109886-4-ZijaRYr1bb@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).