if AltiVec PIM is available
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iano at apple dot com
http://gcc.gnu.org/bugzilla
--- Comment #4 from iano at apple dot com 2006-12-18 20:24 ---
A gcc test case that verfies behavior in this area would drive conformance by
external vendors like IBM.
Unfortunately, it is not clear that GCC even has an approved method for
determining if the PIM is active
--- Comment #5 from iano at apple dot com 2006-12-18 20:52 ---
I will nominate the following as a test case. It should compile without
errors:
for each affected arch:
gcc test_case.c
gcc test_case.c -maltivec
gcc test_case.c -faltivec
gcc test_case.c -maltivec -DINCLUDE_HEADER
: unassigned at gcc dot gnu dot org
ReportedBy: iano at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28877
--- Comment #3 from iano at apple dot com 2006-08-28 23:13 ---
Thanks for fixing it Andrew. I can confirm that -combine works. Hopefully Apple
will get around to updating to 4.0.3 one of these days.
...and really, you should be thrilled to get duplicate bug reports! They are
sooo much
--- Comment #14 from iano at apple dot com 2006-08-22 18:25 ---
For your amusement:
[ollmia:/tmp] iano% cat main.c
#include stdio.h
extern int __isnand( double );
static __inline__ int __inline_isnan( double __a )
{
if( __builtin_isnan( __builtin_nan
behave consistently
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iano at apple dot com
http://gcc.gnu.org
--- Comment #4 from iano at apple dot com 2006-08-22 00:14 ---
Pinski, look at the data I presented.
You do not actually return 0 for these cases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
--- Comment #6 from iano at apple dot com 2006-08-22 00:18 ---
Subject: Re: __builtin_isunordered() and __builtin_isnan() should behave
consistently
On Aug 21, 2006, at 5:16 PM, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08
--- Comment #5 from iano at apple dot com 2006-08-22 00:31 ---
My first complaint is that the implementation is inconsistent.
My second complaint is that the fine manual is wrong headed, leading to hacky
math flags that are less useful than they otherwise would be.
--
iano at apple
--- Comment #7 from iano at apple dot com 2006-08-22 00:39 ---
Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent
On Aug 21, 2006, at 5:34 PM, pinskia at gcc dot gnu dot org wrote:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-22
00:34
--- Comment #9 from iano at apple dot com 2006-08-22 00:49 ---
Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent
On Aug 21, 2006, at 5:42 PM, pinskia at physics dot uc dot edu wrote:
--- Comment #8 from pinskia at physics dot uc dot edu
2006-08-22 00:42
--- Comment #11 from iano at apple dot com 2006-08-22 01:45 ---
About the manual wrongheadedness:
The major argument that I have heard from members of the GCC community (here
and elsewhere) against isnan() in its various forms correctly detecting NaN
when various hacky math flags
--- Comment #12 from iano at apple dot com 2006-08-22 02:05 ---
That however is not a clear bug.
-ffinite-math-only says that it assumes that there are no NaNs in the
input, and you violated that assumption, so the results you will get are
undefined. That is, gcc is allowed to give
15 matches
Mail list logo
