diff mbox

Fix up dg-set-compiler-env-var

Message ID 20160602121905.GE28550@tucnak.redhat.com
State New
Headers show

Commit Message

Jakub Jelinek June 2, 2016, 12:19 p.m. UTC
Hi!

On Fri, May 13, 2016 at 07:09:30PM +0200, Dhole wrote:
> --- a/gcc/testsuite/lib/gcc-dg.exp
> +++ b/gcc/testsuite/lib/gcc-dg.exp
> @@ -451,6 +451,38 @@ proc restore-target-env-var { } {
>      }
>  }
>  
> +proc dg-set-compiler-env-var { args } {

I've noticed last night pr61861.c FAIL in i686-linux bootstrap,
easily reproduceable with short:
make check-gcc RUNTESTFLAGS='cpp.exp=source_date* dg.exp=pr61861.c'

The problem is that in cleanup-after-saved-dg-test, there are missing global
directives, so when it tests/uses the set_compiler_env_var and
saved_compiler_env_var vars to see if it should call
restore-compiler-env-var, it uses local (non-existing) vars instead and
never restores the env var.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok of
trunk?

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

	* lib/gcc-dg.exp (cleanup-after-saved-dg-test): Add missing
	global set_compiler_env_var and global saved_compiler_env_var.



	Jakub

Comments

Bernd Schmidt June 2, 2016, 12:26 p.m. UTC | #1
On 06/02/2016 02:19 PM, Jakub Jelinek wrote:
> The problem is that in cleanup-after-saved-dg-test, there are missing global
> directives, so when it tests/uses the set_compiler_env_var and
> saved_compiler_env_var vars to see if it should call
> restore-compiler-env-var, it uses local (non-existing) vars instead and
> never restores the env var.

I'm puzzled how failing to restore the env var causes a failure, but 
your patch is (obviously) ok.


Bernd
Jakub Jelinek June 2, 2016, 12:33 p.m. UTC | #2
On Thu, Jun 02, 2016 at 02:26:28PM +0200, Bernd Schmidt wrote:
> On 06/02/2016 02:19 PM, Jakub Jelinek wrote:
> >The problem is that in cleanup-after-saved-dg-test, there are missing global
> >directives, so when it tests/uses the set_compiler_env_var and
> >saved_compiler_env_var vars to see if it should call
> >restore-compiler-env-var, it uses local (non-existing) vars instead and
> >never restores the env var.
> 
> I'm puzzled how failing to restore the env var causes a failure, but your
> patch is (obviously) ok.

The second of the tests using the new dg-set-compiler-env-var directive is
doing
/* { dg-set-compiler-env-var SOURCE_DATE_EPOCH "AAA" } */
and then expecting an error.  If the env var isn't restored, then on any of
the following testcases that uses __DATE__ and similar macros the env var
contains still AAA and thus results in an error.

	Jakub
diff mbox

Patch

--- gcc/testsuite/lib/gcc-dg.exp.jj	2016-06-01 19:16:51.000000000 +0200
+++ gcc/testsuite/lib/gcc-dg.exp	2016-06-02 11:56:54.429137894 +0200
@@ -895,6 +895,8 @@  if { [info procs saved-dg-test] == [list
 	global shouldfail
 	global testname_with_flags
 	global set_target_env_var
+	global set_compiler_env_var
+	global saved_compiler_env_var
 	global keep_saved_temps_suffixes
 	global multiline_expected_outputs