PING: two middle-end builtin cproj patches
Kaveh R. Ghazi
ghazi@caip.rutgers.edu
Wed Apr 21 08:53:00 GMT 2010
From: "Richard Guenther" <richard.guenther@gmail.com>
> I am worried that with old glibc still around we now silently change
> cproj semantics. Can you at least add one executable testcase
> that would FAIL with the incorrect implementation and PASS with
> a correct implementation? Please add an entry to gcc-4.6/changes,html
> mentioning this change and the newest glibc version affected.
>
> Ok with that change.
Thanks for the review. Here's the extra testcase I just checked in. I'll
do the changes.html next.
I did as you asked, but IMHO having a FAIL (on all glibc boxes) on the trunk
is too much noise. I suggest XFAILing it on mainline and having it fail
only on the eventual 4.6 branch for release. I can add an XFAIL and open a
PR so we don't forget to remove the XFAIL on the branch...
--Kaveh
/* Copyright (C) 2010 Free Software Foundation.
Check the runtime behavior of the C library's cproj() function and
whether it follows the standard. Versions of GLIBC through 2.11.1
had an incorrect implementation which will conflict with GCC's
builtin cproj(). GLIBC 2.12+ should be okay.
Origin: Kaveh R. Ghazi, April 20, 2010. */
/* { dg-do run } */
/* { dg-options "-fno-builtin-cproj" } */
/* { dg-add-options c99_runtime } */
/* { dg-require-effective-target c99_runtime } */
extern void abort(void);
extern void exit(int);
double _Complex cproj(double _Complex);
int main (void)
{
if (cproj (2+3i) != 2+3i)
abort();
exit(0);
}
More information about the Gcc-patches
mailing list