| Message ID | 53DA9714.5070707@mentor.com |
|---|---|
| State | New |
| Headers | show |
On 07/31/14 13:20, Tom de Vries wrote: > Rainer, > > The test-case cproj-fails-with-broken-glibc.c does not work with broken > glibcs, as the header comment mentions: > ... > 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. > ... > > This patch skips the test for known broken glibcs. OK for trunk? Yes, this is fine. jeff
Hi Tom, > The test-case cproj-fails-with-broken-glibc.c does not work with broken > glibcs, as the header comment mentions: > ... > 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. > ... > > This patch skips the test for known broken glibcs. OK for trunk? I'm not at all happy with this patch: unless absolutely necessary, we shouldn't check for version numbers when there's any way to check for working/broken features instead. I'm all for keeping testsuite results clean, but this seems like a total corner case to me. Which distributions do still use affected glibc versions? That test, even if we go the glibc version route, needs to be XFAILed instead of requiring the working version. Apart from that, new effective-target keywords need documenting in doc/sourcebuild.texi. Thanks. Rainer
On Aug 1, 2014, at 3:35 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > I'm not at all happy with this patch > That test, even if we go the glibc version route, needs to be XFAILed > instead of requiring the working version. Apart from that, new > effective-target keywords need documenting in doc/sourcebuild.texi. Some background folks: https://gcc.gnu.org/ml/gcc-patches/2010-04/msg00490.html So I too agree that skipping the test case on known broken systems when the entire design of the test case is to fail on exactly those broken systems is borked. So, what should we do with it instead. Either xfailing it on known bad systems, or removing it entirely as misguided seem to be the two choices that make sense. What are people in favor of? Clearly the original author wanted at least the xfail. I lean toward removal I think. Why? The gcc test suite, while it could be a filesystem test suite, an OS test suite, a libc test suite, generally speaking that is beyond the scope of this project. From the test case: 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.
2014-07-31 Tom de Vries <tom@codesourcery.com> * lib/target-supports.exp (check_effective_target_glibc) (check_effective_target_glibc_2_12_or_later) (check_effective_target_not_glibc_2_11_or_earlier): New proc. * gcc.dg/cproj-fails-with-broken-glibc.c: Require effective target not_glibc_2_11_or_earlier. diff --git a/gcc/testsuite/gcc.dg/cproj-fails-with-broken-glibc.c b/gcc/testsuite/gcc.dg/cproj-fails-with-broken-glibc.c index fe143b9..1df29f9 100644 --- a/gcc/testsuite/gcc.dg/cproj-fails-with-broken-glibc.c +++ b/gcc/testsuite/gcc.dg/cproj-fails-with-broken-glibc.c @@ -11,6 +11,7 @@ /* { dg-options "-fno-builtin-cproj" } */ /* { dg-add-options c99_runtime } */ /* { dg-require-effective-target c99_runtime } */ +/* { dg-require-effective-target not_glibc_2_11_or_earlier } */ extern void abort(void); extern void exit(int); diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index fa5137e..cbe2930 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -5038,6 +5038,44 @@ proc check_effective_target_newlib {} { }] } +# Return true if this is a glibc target. + +proc check_effective_target_glibc {} { + return [check_no_compiler_messages glibc object { + #include <features.h> + #if !(defined (__GLIBC__) && defined (__GLIBC_MINOR__)) + #error FOO + #endif + }] +} + +# Return true if this is a glibc 2.12 or later target. + +proc check_effective_target_glibc_2_12_or_later {} { + return [check_no_compiler_messages glibc_2_12_or_later object { + #include <features.h> + #if !(defined (__GLIBC__) && defined (__GLIBC_MINOR__) \ + && __GLIBC_PREREQ(2,12)) + #error FOO + #endif + }] +} + +# Return true if this is a not a glibc 2.11 or earlier target. + +proc check_effective_target_not_glibc_2_11_or_earlier {} { + + if { ![check_effective_target_glibc] } { + return 1 + } + + if { [check_effective_target_glibc_2_12_or_later] } { + return 1 + } + + return 0 +} + # Return true if this is NOT a Bionic target. proc check_effective_target_non_bionic {} { -- 1.9.1
Rainer, The test-case cproj-fails-with-broken-glibc.c does not work with broken glibcs, as the header comment mentions: ... 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. ... This patch skips the test for known broken glibcs. OK for trunk? Thanks, - Tom