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