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: 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).