public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c Date: Fri, 27 Jan 2023 10:13:12 +0000 [thread overview] Message-ID: <bug-107608-4-UryXau4hS1@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-107608-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 --- Comment #49 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to rguenther@suse.de from comment #47) > > Glibc already changed the code from Inf/Inf to (x - x) / (x - x) where x (x - x) / (x - x) is 0 / 0, not Inf / Inf. Anyway, for frange potential in GCC 14, I'd hope we do figure out that x - x has [0, 0] range (never -0.0 even, unless -frounding-math where it could be -0.0 when rounding to -Inf) provided x is known to be finite - all of Inf - Inf, (-Inf) - (-Inf) and NaN - NaN are NaN. And frange already has an infrastructure for that, foperator_minus::rv_fold is passed relation_kind between op1 and op2, so if it is VREL_EQ and we can check that Inf or NaN isn't possible in the range, we should yield [0, 0]. Or for -ffast-math do it always and yield [-0., 0] as Inf/NaN aren't expected but signed zeros are present but are insignificant. Shall we file a PR for that? > > is not a constant, but I'm wandering if the compiler will attempt to > > optimize out (x - x) / (x - x) later... Is it possible to provide a > > "__builtin_feraiseexcept" so we'd be able to use it instead of the nasty > > (x - x) / (x - x) to raise the exception? > > Not trivially. I'd suggest glibc uses a volatile use, like for example > > tem = Inf/Inf; > __asm__ volatile ("" : : "g" (tem)); In this case I guess that is at least right now fine (and glibc I think even has a macro for that, some math_*). The thing is that the result is NaN and we don't treat NaN as singleton (because there are many representations of NaN). Similarly the workaround for fold-overflow-1.c added in this PR will not treat for now operations from finite operands yielding singleton Inf or -Inf as singleton. But if it is something else, say finite + finite and the expectation is that inexact is raised, then the above wouldn't help, because we'd just turn it into "g" (constant) in the asm.
next prev parent reply other threads:[~2023-01-27 10:13 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-10 9:47 [Bug tree-optimization/107608] New: [13 Regression] Failure on fold-overflow-1.c jakub at gcc dot gnu.org 2022-11-10 9:49 ` [Bug tree-optimization/107608] " jakub at gcc dot gnu.org 2022-11-10 13:47 ` rguenth at gcc dot gnu.org 2022-11-10 18:13 ` pinskia at gcc dot gnu.org 2022-11-11 7:18 ` pinskia at gcc dot gnu.org 2022-11-13 6:30 ` [Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c xry111 at gcc dot gnu.org 2022-11-28 10:06 ` rguenth at gcc dot gnu.org 2022-12-05 13:22 ` aldyh at gcc dot gnu.org 2022-12-05 15:14 ` rguenth at gcc dot gnu.org 2022-12-05 16:30 ` aldyh at gcc dot gnu.org 2022-12-16 13:20 ` jakub at gcc dot gnu.org 2022-12-16 13:32 ` rguenth at gcc dot gnu.org 2023-01-09 15:18 ` aldyh at gcc dot gnu.org 2023-01-10 8:56 ` rguenth at gcc dot gnu.org 2023-01-10 8:58 ` rguenth at gcc dot gnu.org 2023-01-10 10:20 ` aldyh at gcc dot gnu.org 2023-01-10 10:25 ` aldyh at gcc dot gnu.org 2023-01-10 11:00 ` rguenth at gcc dot gnu.org 2023-01-10 11:09 ` jakub at gcc dot gnu.org 2023-01-10 12:08 ` rguenther at suse dot de 2023-01-10 14:14 ` jakub at gcc dot gnu.org 2023-01-10 14:25 ` amacleod at redhat dot com 2023-01-10 14:33 ` aldyh at gcc dot gnu.org 2023-01-10 14:39 ` jakub at gcc dot gnu.org 2023-01-10 14:40 ` aldyh at gcc dot gnu.org 2023-01-10 14:42 ` jakub at gcc dot gnu.org 2023-01-12 11:42 ` aldyh at gcc dot gnu.org 2023-01-12 12:03 ` jakub at gcc dot gnu.org 2023-01-12 12:26 ` xry111 at gcc dot gnu.org 2023-01-13 13:19 ` aldyh at gcc dot gnu.org 2023-01-13 13:25 ` aldyh at gcc dot gnu.org 2023-01-15 15:43 ` cvs-commit at gcc dot gnu.org 2023-01-16 21:38 ` romain.geissler at amadeus dot com 2023-01-16 21:46 ` jakub at gcc dot gnu.org 2023-01-16 21:55 ` romain.geissler at amadeus dot com 2023-01-16 21:58 ` fw at gcc dot gnu.org 2023-01-18 12:26 ` aldyh at gcc dot gnu.org 2023-01-18 12:54 ` jakub at gcc dot gnu.org 2023-01-18 12:56 ` aldyh at gcc dot gnu.org 2023-01-18 13:00 ` rguenth at gcc dot gnu.org 2023-01-18 13:03 ` rguenth at gcc dot gnu.org 2023-01-18 13:05 ` rguenth at gcc dot gnu.org 2023-01-19 1:15 ` xry111 at gcc dot gnu.org 2023-01-19 7:17 ` rguenther at suse dot de 2023-01-26 14:29 ` xry111 at gcc dot gnu.org 2023-01-27 7:35 ` rguenth at gcc dot gnu.org 2023-01-27 7:59 ` xry111 at gcc dot gnu.org 2023-01-27 9:53 ` rguenther at suse dot de 2023-01-27 10:02 ` xry111 at gcc dot gnu.org 2023-01-27 10:13 ` jakub at gcc dot gnu.org [this message] 2023-01-27 11:30 ` rguenther at suse dot de
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-107608-4-UryXau4hS1@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).