Tim Shen writes:
> On Fri, Aug 9, 2013 at 2:59 PM, Paolo Carlini
> wrote:
>> Yes, if, as it should, it works on -m32 too, let's go with this. By the way,
>> you didn't say how exactly you are testing?!? Because just make check
>> doesn't test -m32. I use, something like:
>>
>> make -k check-tar
On Fri, Aug 9, 2013 at 2:59 PM, Paolo Carlini wrote:
> Yes, if, as it should, it works on -m32 too, let's go with this. By the way,
> you didn't say how exactly you are testing?!? Because just make check
> doesn't test -m32. I use, something like:
>
> make -k check-target-libstdc++-v3
> RUNTESTFLA
Hi,
On 08/09/2013 07:08 AM, Tim Shen wrote:
On Fri, Aug 9, 2013 at 12:51 AM, Tim Shen wrote:
So here's the change. It's under testing now, but could took several
hours. If someone has a faster machine, please tell the result :)
Unfortuantely using `unsigned int => unsigned short` cannot work.
On Fri, Aug 9, 2013 at 12:51 AM, Tim Shen wrote:
> So here's the change. It's under testing now, but could took several
> hours. If someone has a faster machine, please tell the result :)
Unfortuantely using `unsigned int => unsigned short` cannot work.
Instead, I create a enum and do some operat
On 08/08/2013 06:51 PM, Tim Shen wrote:
On Fri, Aug 9, 2013 at 12:15 AM, Paolo Carlini wrote:
Indeed, I noticed it a few days ago, and seemed overkill ;) Really, we already
have implementation experience about these flags, eg in iostream, and I dont
think we want std::bitset everywhere.
So h
On Fri, Aug 9, 2013 at 12:15 AM, Paolo Carlini wrote:
> Indeed, I noticed it a few days ago, and seemed overkill ;) Really, we
> already have implementation experience about these flags, eg in iostream, and
> I dont think we want std::bitset everywhere.
So here's the change. It's under testing
Hi,
>> In my humble opinion involving the whole std::bitset container for a
>> syntax option is way overkill.
>
>It's already used for match_flag_type anyway.
Indeed, I noticed it a few days ago, and seemed overkill ;) Really, we already
have implementation experience about these flags, eg in
Hi,
>So flag_type shall not be the same as size_t. I don't know if when I
>switch flag_type from unsigned int to, say, unsigned short, conflicts
>will appear in 16bit archtectures.
Well 16-bit archs aren't really supported these days, as long as the c++
runtime is concerned. Thus if unsigned s
Paolo Carlini writes:
> In my humble opinion involving the whole std::bitset container for a
> syntax option is way overkill.
It's already used for match_flag_type anyway.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA
On Thu, Aug 8, 2013 at 11:14 PM, Paolo Carlini wrote:
> In my humble opinion involving the whole std::bitset container for a syntax
> option is way overkill. Do you really have to do overloading between size_t
> and that type? Or maybe you can use a type *smaller* than unsigned int.
The n3376 s
Hi,
>There's a typedef in regex_constants.h:
>
>`typedef unsigned int syntax_option_type;`
>
>Which is a little bit naive. It possibly conflicts with size_t under
>i386 when overloading. I'm trying to change it to a bitset. Or is
>there any better solution?
In my humble opinion involving the wh
On Thu, Aug 8, 2013 at 10:04 PM, Tim Shen wrote:
> On Thu, Aug 8, 2013 at 8:53 PM, Paolo Carlini
> wrote:
>> Tim, please address this ASAP, otherwise we have to revert the whole thing.
>
> I'm trying to reproduce the compilation failures.
There's a typedef in regex_constants.h:
`typedef unsign
On Thu, Aug 8, 2013 at 8:53 PM, Paolo Carlini wrote:
> Tim, please address this ASAP, otherwise we have to revert the whole thing.
I'm trying to reproduce the compilation failures.
--
Tim Shen
> Hi Paolo,
>
> >>This is already documented:
> >>
> >>http://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#c
> oding_style.bad_identifiers
> >
> > Indeed. As a simple to remember rule never use single underscore +
> single
> > uppercase. Usually we add a p, like _Cp, etc. Plenty
Hi,
>I wasn't certain about the right convention. The following patch
>allowed bootstrap to finish on i386-pc-solaris2.10 and
>x86_64-unknown-linux-gnu. I'll commit the patch once Solaris testing
>has finished.
Thanks a lot.
>E.g. the first one is
>
>FAIL: 28_regex/algorithms/regex_match/bas
Hi Paolo,
>>This is already documented:
>>
>>http://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#coding_style.bad_identifiers
>
> Indeed. As a simple to remember rule never use single underscore + single
> uppercase. Usually we add a p, like _Cp, etc. Plenty of examples
> everywh
Hi,
>This is already documented:
>
>http://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html#coding_style.bad_identifiers
Indeed. As a simple to remember rule never use single underscore + single
uppercase. Usually we add a p, like _Cp, etc. Plenty of examples everywhere. At
the
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Rainer Orth
> Sent: 08 August 2013 11:02
> To: Tim Shen
> Cc: libstdc++; gcc-patches
> Subject: Re: [Patch] Whole regex refactoring and current status
Tim Shen writes:
> As metioned in this[1] email, I here propose a refactored version of
> regex, and show the status:
This patch broke Solaris bootstrap:
In file included from /usr/include/ctype.h:18:0,
from
/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libstd
On Wed, Aug 7, 2013 at 12:04 AM, Paolo Carlini wrote:
> By the way, your last patch is fine with me, I like the new *.tcc a lot.
> Just allow a day or so for further comments..
Committed.
--
Tim Shen
20 matches
Mail list logo
