diff mbox

Allow embedded timestamps by C/C++ macros to be set externally (3)

Message ID 20160602150411.GK28550@tucnak.redhat.com
State New
Headers show

Commit Message

Jakub Jelinek June 2, 2016, 3:04 p.m. UTC 
On Thu, Jun 02, 2016 at 04:49:59PM +0200, Christophe Lyon wrote:
> I'm also seeing that the new gcc.dg/cpp/source_date_epoch-1.c fails because
> the output pattern finishes with '\n' instead of the usual '(\n|\r\n|\r)'
> 
> Can I add this as obvious?

Some remote test invocations even eat the final newline from what I vaguely
remember from various complains about the asan and ubsan testsuite.

So we could just drop that ^ and \n$ from dg-output, but then, what is the
point of using dg-output at all here?

Isn't following just better?  Tested on x86_64-linux, ok for trunk?

2016-06-02  Jakub Jelinek  <jakub@redhat.com>

	* gcc.dg/cpp/source_date_epoch-1.c (main): Test __DATE__ and
	__TIME__ strings with __builtin_strcmp instead of printf and
	dg-output.



	Jakub

Comments

Bernd Schmidt June 2, 2016, 3:27 p.m. UTC | #1 
On 06/02/2016 05:04 PM, Jakub Jelinek wrote:
> Isn't following just better?  Tested on x86_64-linux, ok for trunk?
>
> 2016-06-02  Jakub Jelinek  <jakub@redhat.com>
>
> 	* gcc.dg/cpp/source_date_epoch-1.c (main): Test __DATE__ and
> 	__TIME__ strings with __builtin_strcmp instead of printf and
> 	dg-output.
>

Sure.


Bernd
Christophe Lyon June 2, 2016, 3:30 p.m. UTC | #2 
On 2 June 2016 at 17:04, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Jun 02, 2016 at 04:49:59PM +0200, Christophe Lyon wrote:
>> I'm also seeing that the new gcc.dg/cpp/source_date_epoch-1.c fails because
>> the output pattern finishes with '\n' instead of the usual '(\n|\r\n|\r)'
>>
>> Can I add this as obvious?
>
> Some remote test invocations even eat the final newline from what I vaguely
> remember from various complains about the asan and ubsan testsuite.
>
Yes, that's a nightmare :)
Also when combined with qemu, in my configuration it thinks that stderr is
a tty so *san tests use the colorization codes.

And when it comes to cross-testing as we do it in Linaro, we have problems
with dejagnu eating the trailing \n in the remote execution functions.
But that's
another different problem.

> So we could just drop that ^ and \n$ from dg-output, but then, what is the
> point of using dg-output at all here?
>
> Isn't following just better?  Tested on x86_64-linux, ok for trunk?
LGTM

Thanks

> 2016-06-02  Jakub Jelinek  <jakub@redhat.com>
>
>         * gcc.dg/cpp/source_date_epoch-1.c (main): Test __DATE__ and
>         __TIME__ strings with __builtin_strcmp instead of printf and
>         dg-output.
>
> --- gcc/testsuite/gcc.dg/cpp/source_date_epoch-1.c.jj   2016-06-01 21:26:27.000000000 +0200
> +++ gcc/testsuite/gcc.dg/cpp/source_date_epoch-1.c      2016-06-02 17:02:06.164281564 +0200
> @@ -2,10 +2,10 @@
>  /* { dg-set-compiler-env-var SOURCE_DATE_EPOCH "630333296" } */
>
>  int
> -main(void)
> +main ()
>  {
> -  __builtin_printf ("%s %s\n", __DATE__, __TIME__);
> +  if (__builtin_strcmp (__DATE__, "Dec 22 1989") != 0
> +      || __builtin_strcmp (__TIME__, "12:34:56") != 0)
> +    __builtin_abort ();
>    return 0;
>  }
> -
> -/* { dg-output "^Dec 22 1989 12:34:56\n$" } */
>
>
>         Jakub
diff mbox

Patch

--- gcc/testsuite/gcc.dg/cpp/source_date_epoch-1.c.jj	2016-06-01 21:26:27.000000000 +0200
+++ gcc/testsuite/gcc.dg/cpp/source_date_epoch-1.c	2016-06-02 17:02:06.164281564 +0200
@@ -2,10 +2,10 @@ 
 /* { dg-set-compiler-env-var SOURCE_DATE_EPOCH "630333296" } */
 
 int
-main(void)
+main ()
 {
-  __builtin_printf ("%s %s\n", __DATE__, __TIME__);
+  if (__builtin_strcmp (__DATE__, "Dec 22 1989") != 0
+      || __builtin_strcmp (__TIME__, "12:34:56") != 0)
+    __builtin_abort ();
   return 0;
 }
-
-/* { dg-output "^Dec 22 1989 12:34:56\n$" } */