This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] cilkplus array notation for C (clean, independent patchset, take 1)
- From: Mike Stump <mrs at mrs dot kithrup dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, Aldy Hernandez <aldyh at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, "Iyer, Balaji V" <balaji dot v dot iyer at intel dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 21 Mar 2013 09:54:11 -0700
- Subject: Re: [patch] cilkplus array notation for C (clean, independent patchset, take 1)
- References: <5149D62F dot 9070503 at redhat dot com> <5149E4C7 dot 1090206 at redhat dot com> <514A9B12 dot 8050502 at redhat dot com> <20130321060933 dot GQ12913 at tucnak dot redhat dot com>
On Mar 20, 2013, at 11:09 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Mar 20, 2013 at 11:30:58PM -0600, Jeff Law wrote:
>> On 03/20/2013 10:33 AM, Aldy Hernandez wrote:
>>> As I'd mentioned, you have .exp files named compile.exp and execute.exp
>>> which seem to be causing ambiguity problems in parallel checks (make
>>> check -jN). For some reason, with this patch, the rest of dg.exp fails
>>> to run after Cilkplus' compile/execute.exp runs. Renaming these to
>>> something less generic does the trick. Do you mind prefixing all the
>>> .exp's with "cilkplus_" or something similar?
>
> Renaming is desirable anyway,
So, the problem that causes it to not work needs to be fixed, before the patches go in. Renaming is a form of bug pushing and that can't be used to fix the problem. When the underlying problem is fixed, then rename, not before. The problem is that the entire sanity of the test suite depends critically on resetting the environment to be back the way it was upon the finishing of any particular .exp. You can run with -v -v -v -v and see check differences in the output, it might let you narrow down the issue. You can run env (or parry env) before and after, and quickly see if it is due to an environment variable. In theory, you can have tcl dump all the variables from the symbol tables, (info locals and info globals being the starting point)… but you'd need to differentiate between the variables that must be the same, and the variables that can be different. One might be able to turn on tracing to find it, though, that can make your eyes bleed.