This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] new exec-charset testcase


> > Can do. I figured that tested the reliability of the translation library
> > and not that the translation work in gcc was firing though.
> 
> We want to be testing both.
> 

We do? Hrm I suppose for the character sets that we translate ourselves.

> >> Pointer to C++ patch?
> >> 
> >
> > http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00763.html
> >
> > It's kinda simple.
> 
> Let me see if I understand: you have to turn translation back on
> immediately after processing the token that might be the "C" in
> extern "C", rather than after several more tokens have been scanned.
> If so, patch is clearly the right thing and is approved.
> 

Yes, and thanks. I'll assume I can commit the testcase there (modified
to actually do something to the string) as well.

> > Though I've recently been pointed at a c++ + asm testcase that is
> > unlikely to work in the existing framework so it looks likely to
> > need rewriting for all of it. I can send you the testcase and
> > summary in email if you'd like.
> 
> sure.

A good example is this testcase:

int main()
{
  unsigned long int *ptr;
  ptr = ((unsigned long int *)
         ( { void *stack_ptr;
           __asm__ __volatile__ ( "foo %0" : "=r" (stack_ptr) );
           (stack_ptr); } ) );
  return 0;
}

Where it tentatively parses the cast to make sure it really is one
before continuing. Unfortunately it doesn't run through the actual
parsing code - it just creates trees from each element and then pushes
them on the stack. Unfortunately since it doesn't run through the actual
parsing code it doesn't know that it should/shouldn't translate the
strings as it gets them.

Now, this wouldn't be a problem if we were pushing the cpp_tokens onto
the stack, but we're pushing trees. :| Right now the only solution I can
see for this that doesn't require brain surgery in the parser is to
reconstruct the tree as we parse and translate then if needed. The other
idea is to only use cpp_tokens for the tentative parse and then actual
parse on our way through...

The unfortunate bit is that I get to rewrite a good chunk of the
exec-charset stuff for c++ and don't get to share code with the C front
end for it. (And have to set c_lex_string_translate permanently to false
in the C++ front end).

Any other thoughts?

> 
> >> Hmm.  We're going to be wanting tests for charsets other than IBM-1047
> >> at some point.  And it's inefficient to be running dg-require-iconv
> >> for every test...
> >
> > True. Though I think these two contradict each other without more
> > testsuite work than i want to do at the moment :)
> 
> Fair enough.  For right now, let's get the inefficiency; as a separate
> patch, please extract the dg-require-iconv operation to charset.exp.
> (It is most appropriate, I think, to call check_iconv_supported early
> in the .exp file, and bail out if not - like what tls/tls.exp does.)
> I'll preapprove such a patch.
> 

OK. I'll do that tonight then.

Thanks.

-eric

-- 
Eric Christopher <echristo@redhat.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]