https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #22 from GCC Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:fe10ca6e3cf583640155812b230a0153ce4dc7b7
commit r16-455-gfe10ca6e3cf583640155812b230a0153ce4dc7b7
Author: Richard Earnshaw
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
Ilya Leoshkevich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #20 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Sep 2 10:10:23 2019
New Revision: 275303
URL: https://gcc.gnu.org/viewcvs?rev=275303&root=gcc&view=rev
Log:
PR target/91323
* doc/generic.texi (LTGT_EXPR): Merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #19 from rguenther at suse dot de ---
On Mon, 2 Sep 2019, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
>
> --- Comment #17 from Eric Botcazou ---
> Created attachment 46797
> --> https:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #18 from rguenther at suse dot de ---
On Mon, 2 Sep 2019, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
>
> --- Comment #16 from Eric Botcazou ---
> > Other than that my view is that the G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #17 from Eric Botcazou ---
Created attachment 46797
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46797&action=edit
Proposed wording change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #16 from Eric Botcazou ---
> Other than that my view is that the GENERIC/GIMPLE side is correct.
> Besides even RTL "high-level" get's this consistent (may_trap_p_1),
> likewise simplify-rtx if my quick survey is correct.
Yes, the RT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #15 from rguenther at suse dot de ---
On Sat, 31 Aug 2019, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
>
> Eric Botcazou changed:
>
>What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
Christophe Lyon changed:
What|Removed |Added
Target|x86_64-*-*, i?86-*-*|x86_64-*-*, i?86-*-*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #12 from joseph at codesourcery dot com ---
On Thu, 1 Aug 2019, ubizjak at gmail dot com wrote:
> It also means that __builtin_islessgreater is confusingly named.
No, __builtin_islessgreater corresponds to the ISO C islessgreater
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #11 from Richard Biener ---
(In reply to Uroš Bizjak from comment #10)
> (In reply to Richard Biener from comment #4)
> > quoting rtl.def:
> >
> > /* This is an ordered NE, ie !UNEQ, ie false for NaN. */
> > DEF_RTL_EXPR(LTGT, "ltgt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #10 from Uroš Bizjak ---
(In reply to Richard Biener from comment #4)
> quoting rtl.def:
>
> /* This is an ordered NE, ie !UNEQ, ie false for NaN. */
> DEF_RTL_EXPR(LTGT, "ltgt", "ee", RTX_COMM_COMPARE)
In gensupport.c, we have:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #9 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #8)
> FWIW, using __float128 also traps on LTGT. The adapted testcase:
Eh, __float128 should trap on LTGT, but currently, it doesn't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #8 from Uroš Bizjak ---
FWIW, using __float128 also traps on LTGT. The adapted testcase:
--cut here--
/* { dg-do run } */
/* { dg-add-options ieee } */
/* { dg-require-effective-target fenv_exceptions } */
#include
int
__attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Aug 2 09:58:04 2019
New Revision: 274005
URL: https://gcc.gnu.org/viewcvs?rev=274005&root=gcc&view=rev
Log:
PR target/91323
* config/i386/i386-expand.c (ix86_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #6 from rguenther at suse dot de ---
On Fri, 2 Aug 2019, ubizjak at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
>
> --- Comment #5 from Uroš Bizjak ---
> (In reply to Richard Biener from comment #3)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #5 from Uroš Bizjak ---
(In reply to Richard Biener from comment #3)
> That means this is a target issue, LTGT isn't an unordered compare.
So, it should create COMISS then?
The patch is then simple:
--cut here--
Index: config/i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #4 from Richard Biener ---
quoting rtl.def:
/* This is an ordered NE, ie !UNEQ, ie false for NaN. */
DEF_RTL_EXPR(LTGT, "ltgt", "ee", RTX_COMM_COMPARE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
Uroš Bizjak changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #1 from Uroš Bizjak ---
For x86, we have:
/* Figure out whether to use unordered fp comparisons. */
static bool
ix86_unordered_fp_compare (enum rtx_code code)
{
if (!TARGET_IEEE_FP)
return false;
switch (code)
{
ca
23 matches
Mail list logo
