https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #25 from Andrew Pinski ---
We have this now:
if (tmp.3_3 > 0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 633507679]:
_10 = _12 == 0;
[local count: 1073741824]:
# iftmp.2_5 = PHI <_10(3), 0(2)>
I suspec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #22 from Andrew Pinski ---
For the original testcase in comment #0 we produce (in GCC 11+):
movl%edi, %eax
mull%esi
seto%dl
xorl%r8d, %r8d
movzbl %dl, %edx
testl %eax,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #21 from Martin von Gagern ---
(In reply to myself from comment #15)
> (In reply to comment #7)
> > […] built-in operations where you can just say "multiply two
> > (signed) values, check whether the result fits in 31-bit unsigned an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #20 from Marc Glisse ---
(In reply to Zack Weinberg from comment #5)
> Addendum: what would *you* describe as the correct C idiom for
> ensuring that the product of two signed integers was positive and did
> not overflow the range of a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #19 from Martin von Gagern
2013-02-02 22:08:09 UTC ---
Bug 49467 asked about builtins, and got duped here, so small wonder people
wanting a builtin-colored bikeshed like I do end up here...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #18 from Zack Weinberg 2013-02-02 21:59:37
UTC ---
I find it a little disappointing that what should have been a straightforward
additional optimization has gotten totally derailed into bikeshedding of an
enormous class of buil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #17 from Martin von Gagern
2013-02-02 18:54:43 UTC ---
(In reply to comment #16)
> I somewhat disagree. A program must be correct; it should be secure;
> and it can be efficient. I'm interested in "correct" and "secure".
> If
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #16 from Jeffrey Walton 2013-02-02
17:01:55 UTC ---
(In reply to comment #15)
> I agree. The main point of all of this is optimization. And in terms of
> optimization, one would want to examine some flag immediately after an
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
Martin von Gagern changed:
What|Removed |Added
CC||Martin.vGagern at gmx dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #14 from joseph at codesourcery dot com 2011-10-05 15:19:01 UTC ---
On Wed, 5 Oct 2011, jules at gcc dot gnu.org wrote:
> I don't much like the idea of using builtins for operations as fundamental as
> integer arithmetic. How about th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #13 from jules at gcc dot gnu.org 2011-10-05 13:05:47 UTC ---
Coming to think of it, if _Sat were allowed on plain integers too, a _Flagged
_Sat int could also be queried for saturation using a similar mechanism, like:
int foo (_Sat in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
Joseph S. Myers changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
Steven Fuerst changed:
What|Removed |Added
CC||svfuerst at gmail dot com
--- Comment #10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #9 from joseph at codesourcery dot com 2011-04-13 12:45:35 UTC ---
On Wed, 13 Apr 2011, rguenth at gcc dot gnu.org wrote:
> For the latter reasons I think the builtins should be sth like
> __builtin_smul_ovfl_p (multiplication-result,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
18 matches
Mail list logo
