This is the mail archive of the
mailing list for the glibc project.
Re: inline __isctype no longer available for C++ programs
- From: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Ryan S Arnold <rsa at linux dot vnet dot ibm dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 8 Aug 2013 11:30:21 -0500
- Subject: Re: inline __isctype no longer available for C++ programs
- References: <1375977352 dot 1294 dot 14 dot camel at localhost dot localdomain> <mvm8v0ccgru dot fsf at hawking dot suse dot de> <CAAKybw8Ng1GjhFEiutXFQAQUxRoA-MS3XT2-W8wpWJsM_-rrmQ at mail dot gmail dot com>
On Thu, Aug 8, 2013 at 11:17 AM, Ryan S. Arnold <email@example.com> wrote:
> On Thu, Aug 8, 2013 at 11:02 AM, Andreas Schwab <firstname.lastname@example.org> wrote:
>> Ryan S Arnold <email@example.com> writes:
>>> int is = __isctype('a',_ISupper | _ISalpha);
>>> rather than:
>>> int is = isupper(a) | isalpha(a);
>> The compiler should be able to optimize the latter into the former.
> Good point. I'll check the disassembled object files to see if it
> does indeed do this. If it does there wouldn't really be a need for
> an inlined isctype function.
> I imagine this might be complicated by the fact that __isctype_f hides
> references into specification tables, are queried from thread specific
The GCC compiler does indeed optimize isupper(a) | isalpha(a) to same
instructions seqence as __isctype('a'|_ISupper | _ISalpha).
I think what we have is satisfactory.