[Bug libstdc++/50160] New: vector<bool> comparison very slow (no specialisation)

[Bug libstdc++/50160] New: vector<bool> comparison very slow (no specialisation)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

             Bug #: 50160
           Summary: vector<bool> comparison very slow (no specialisation)
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: devel@the-user.org


Hi!

Comparison (operator<) on vector<bool> seems to be extremely slow, because it
uses a generic implementation, i.e. bitwise iteration. It should be specialised
and use integer-comparisons provided by the CPU.

Regards

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-23 08:14:06 UTC ---
Do you have some numbers? Of course we can make progress on this, but we'd like
to know when it's good enough.

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #2 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-23 13:50:09 UTC ---
Well, it made my specific application very slow, when using vector<bool> as
key_type for (ordered) map.  What kind of numbers would be usefull? I think it
should simply have a specialised operator< implementation comparing chunks of
32/64 bits, there is also a specialised hash implementation, it should be like
that one.

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-23 16:31:40 UTC ---
I meant: which improvement do you expect, in practice? I supposed you are aware
if other implementations of the library already including the optimization. I'm
looking for some concrete evidence, because you know, vector<bool> is
deprecated, isn't a real container, and all the well known bad things about it,
thus we normally don't do much development work on it beyond ghe basic
maintainance. Of course, if you have already a patch, that would definitely
speed things up ;)

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #4 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-23 18:21:36 UTC ---
In libc++ it is the same, specialised hash, but no specialised operator<.

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #5 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-23 18:26:48 UTC ---
In libc++ it seems to be the same, specialised hashing, but no specialised
comparison. Ok, I can write a patch and test if it is actually faster (it
should). Is there any coding-guide line (style, variables etc.)?

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #6 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-23 18:29:19 UTC ---
Ok, I can write a patch and test if it is actually faster (it
should). Is there any coding-guide line (style, variables etc.)?

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #7 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-23 18:35:57 UTC ---
If I understand correctly, operator< is supposed to give a lexicographic order,
and vector<bool> stores {true,false,false} as 1 and {false,false,true} as 4, so
we can't just make operator< compare chunks. Reversing the order of the bits in
an unsigned long is a bit complicated, although it would still lead to code
faster than the current (easiest would be to compare byte by byte, and mirror
each byte using a table).

But you don't seem particularly interested in using the lexicographic order, is
that true? In that case you could try and specify some other order to std::map,
say comparing hashes ;-) I understand that the lexicographic order of the
chunks would be a fine order, but I don't think it can be exposed. I haven't
thought about the potential drawbacks of implementing vector<bool> backwards.

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #8 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-23 19:04:25 UTC ---
For my application I should simply use an unordered_map and all the overhead
has gone. :D But operator< simply should not be that slow.

“I haven't thought about the potential drawbacks of implementing vector<bool>
backwards.”
What do you mean? Chunk wise backwards?

“but I don't think it can be exposed.”
Well, that would not be portable.

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #9 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-23 19:10:06 UTC ---
Hmm, reversing really is not that nice.

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #10 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-23 19:15:20 UTC ---
There seem to be a lot of tricks to achieve that:
http://graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith64BitsDiv

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #11 from Marc Glisse <marc.glisse at normalesup dot org> 2011-08-23 19:16:40 UTC ---
(In reply to comment #8)
> For my application I should simply use an unordered_map and all the overhead
> has gone. :D

Great.

> “I haven't thought about the potential drawbacks of implementing vector<bool>
> backwards.”
> What do you mean? Chunk wise backwards?

Er, yes, start filling each chunk from the most significant bit to the least
significant, but otherwise keep things the same.

> Hmm, reversing really is not that nice.

Any particular reason? Not that the current implementation is likely to change
anytime soon, but if you found drawbacks it would be nice to have them written
somewhere in case the same question ever arises again.

[Bug libstdc++/50160] vector<bool> comparison very slow (no specialisation)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #12 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-23 19:31:37 UTC ---
“Any particular reason?”
No particular one, but a small specialisation would be nicer than changing
everything or doing bitfiddling.

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|vector<bool> comparison     |vector<bool> comparison
                   |very slow (no               |very slow (no overload)
                   |specialisation)             |

--- Comment #13 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-30 10:29:14 UTC ---
To be precise, we are talking about overloading not specializing. The issue, in
general, reminds me the way we overload std::fill and std::copy for ranges of
deque<>::iterator, but then in detail, there are the difficulties pointed out
by Marc. I'm certainly available for patch reviews, anyway.

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #14 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-30 23:25:25 UTC ---
Created attachment 25143
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25143
bits/stl_vector.h patch

moved operator== and operator< inside class, because I want to overload them

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #15 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-30 23:30:00 UTC ---
Created attachment 25144
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25144
b

More efficient (non representative benchmark!) implementation of operator< and
operator== for vector<bool>

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #16 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-30 23:30:36 UTC ---
Added basic patch…

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-08-30 23:34:42 UTC ---
(In reply to comment #14)
> moved operator== and operator< inside class, because I want to overload them

huh, why is that needed?  it's not acceptable anyway, it needs to be a
non-member

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #18 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-30 23:56:38 UTC ---
(In reply to comment #17)
> (In reply to comment #14)
> > moved operator== and operator< inside class, because I want to overload them
> 
> huh, why is that needed?  it's not acceptable anyway, it needs to be a
> non-member

Correct me, if I am wrong, isn't it considered as partial specialisation when
writing it straight-forward as non-member?

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #19 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-31 00:04:36 UTC ---
I'm wondering if processing an unsigned long at a time wouldn't be a step in
the right direction. Then, a compiler intrinsics would be the right place for
that, would naturally fit in the set of builtins fiddling with bits of integer
types. On top of that the library-proper code would become very simple, in
particular no ugly reinterpret_cast & co (by the way, Ch. 7 of "Hacker's
Delight" has some info about such operations). Assuming indeed, we *do* have to
revert the order, I'm not 101% sure.

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #20 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-31 00:26:49 UTC ---
Largely irrelevant here, but partial specialization of function templates
simply does not exist. We have been talking about adding an overload like:

 template<typename _Alloc>
   bool
   operator<(const vector<bool, _Alloc>&, const vector<bool, _Alloc>&)

or overloading std::lexicographical_compare, seems also an option.

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #21 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-31 00:30:58 UTC ---
It would indeed be nice to have such a builtin function (8, 16, 32, 64 bit
reversing), currently there is none in gcc, only bytewise reversing iirc.
Should that be put as wishlist-item in the bugzilla or something like that?

Reversing is necessary because the ordering should be lexicographic, but the
internal representation uses least-significant-first, reversing the internal
representation would probably not be that nice.

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #22 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-08-31 00:33:52 UTC ---
Can't you do ~a < ~b ?

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #23 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-31 00:34:28 UTC ---
@Paolo

Okay, I am sometimes overcautious with function-templates, because I often had
a lot of errors because of partial specialisation when it was indeed necessary
(function templates with explicit parameters).

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #24 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-08-31 00:39:57 UTC ---
@Andrew

Nope:
10000001 > 00000001 (lexicographically)
10000001 > 00000001 (as little-endian)
01111110 < 11111110 (as little-endian)

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #25 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-08-31 00:56:42 UTC ---
I think a separate Bugzilla requesting as an enhancement such intrinsics would
be certainly appropriate. I'm sure other code could exploit those.

Note, in the meanwhile we could as well do the exercise of separating the
operation to a C function - for unsigned long, the 32-bit and 64-bit cases
would be good enough for now - coded perhaps along the lines explained at the
beginning of Ch. 7 of "Hacker's Delight" and use the function for operator<
(please, not inline). See which performance come out.

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #26 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-08-31 15:23:56 UTC ---
Various processors have an instruction to reverse the bit order in a word 
(ARMv6T2 and later have RBIT, for example, and C6X has BITR on C64X and 
above).  I think a generic built-in function (variants for different type 
sizes) with associated generic RTL representation and lowering for 
processors without such an instruction makes sense.

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #27 from Marc Glisse <marc.glisse at normalesup dot org> 2011-09-22 09:25:44 UTC ---
(In reply to comment #25)
[builtins to reverse the bit order]
> I think a separate Bugzilla requesting as an enhancement such intrinsics would
> be certainly appropriate.

Has this RFE already been filed?

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #28 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-09-22 09:49:18 UTC ---
I think we should. Can you do that? Thanks!

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #29 from Marc Glisse <marc.glisse at normalesup dot org> 2011-09-22 10:29:07 UTC ---
See Bug 50481 about bit-reversal builtins (and feel free to add details there).

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[devel@the-user.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #30 from Jonathan Schmidt-Dominé <devel@the-user.org> 2011-09-22 13:39:22 UTC ---
Sorry, thank you for creating the feature-request.

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[DANISH8926536 at GMAIL dot COM]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

DANISH <DANISH8926536 at GMAIL dot COM> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |DANISH8926536 at GMAIL dot
                   |                            |COM

--- Comment #31 from DANISH <DANISH8926536 at GMAIL dot COM> 2012-03-13 08:30:00 UTC ---
Nice post. Thank you for taking the time to publish this information very
useful! I've been looking for books of this nature for a way too long. I'm just
glad that I found yours. Looking forward for your next post. Thanks :)
<a href="http://www.honeywellcentral.com/humidifiers">Honeywell Humidifiers</a>

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[ptim034 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

Tim Parker <ptim034 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ptim034 at gmail dot com

--- Comment #32 from Tim Parker <ptim034 at gmail dot com> 2012-03-29 10:42:52 UTC ---
Soo long conversation. It's booring.
<a href="http://www.buyanessay.com/">buy essays</a>

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[muhammadali.ca4 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

albcl111 <muhammadali.ca4 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |muhammadali.ca4 at gmail
                   |                            |dot com

--- Comment #33 from albcl111 <muhammadali.ca4 at gmail dot com> 2012-10-31 11:09:32 UTC ---
This is such a great resource that you are providing and you give it away for
free. I love seeing websites that understand the value of providing a quality
resource for free. It is the old what goes around comes around routine.
<a
href="http://www.genesishealthinstitute.com/testosterone.php">http://www.genesishealthinstitute.com/testosterone.php</a>

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[muhammadali.ca4 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #34 from albcl111 <muhammadali.ca4 at gmail dot com> 2012-12-21 06:46:07 UTC ---
positively enjoying each little bit of it and I have you bookmarked to check
out new stuff you weblog
AIHL
http://www.accidentinjuryhelplines.co.uk/

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[muhammadali.ca4 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #35 from albcl111 <muhammadali.ca4 at gmail dot com> 2012-12-21 11:58:37 UTC ---
Well said….positively enjoying each little bit of it and I have you bookmarked
to check out new stuff you weblog
airlinesplanet
http://www.airlinesplanet.com/

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[dparker1324 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

brett davis <dparker1324 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dparker1324 at gmail dot
                   |                            |com

--- Comment #36 from brett davis <dparker1324 at gmail dot com> 2013-04-30 12:30:06 UTC ---
Now that was an amazing post about the comparison of vector and their
additional features. It is a really useful post that helps to simplify the
issues and also helps to clarify the doubts regarding vectors and bool.
Awaiting new posts.<a
href="http://www.outlookemailsetup.com/outlook-express-help/how-to-merge-your-email-account-with-outlook-express/">outlookemailsetup.com</a>

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[amandalionard at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

jandyu rata <amandalionard at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amandalionard at gmail dot com

--- Comment #37 from jandyu rata <amandalionard at gmail dot com> ---
 “It is better to take many small steps in the right direction than to make a
great leap forward only to stumble backward.” 

http://rajasthanispecial.com/index.php/womens-collection/sarees.html
>From gcc-bugs-return-422491-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 17 07:17:51 2013
Return-Path: <gcc-bugs-return-422491-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10108 invoked by alias); 17 May 2013 07:17:51 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10073 invoked by uid 48); 17 May 2013 07:17:45 -0000
From: "skannan at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/47254] ICE: unspellable token PRAGMA_EOL with #pragma redefine_extname and -fdirectives-only
Date: Fri, 17 May 2013 07:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.6.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: skannan at redhat dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-47254-4-Betpe83w93@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-47254-4@http.gcc.gnu.org/bugzilla/>
References: <bug-47254-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg01164.txt.bz2
Content-length: 1474

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG254

Shakthi Kannan <skannan at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |skannan at redhat dot com

--- Comment #1 from Shakthi Kannan <skannan at redhat dot com> ---
Confirmed.

$  gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[tysonroy at yopmail dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

tysonroy <tysonroy at yopmail dot fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tysonroy at yopmail dot fr

--- Comment #38 from tysonroy <tysonroy at yopmail dot fr> ---
It is a really useful post that helps to simplify the issues and also helps to
clarify the doubts regarding vectors and bool. Awaiting new posts. <a
href="http://www.monsteribeatsbydrejp.com/">transparent music widget
android</a>

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[margaretnemon at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

Jmaescraig <margaretnemon at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |margaretnemon at gmail dot com

--- Comment #39 from Jmaescraig <margaretnemon at gmail dot com> ---
inproper installation or setting up program is might be the reason for such
kind of the problem. Its looks like a slower internet connection is also reason
for that. 
http://small-fridge.net/selecting-a-best-small-fridge/

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[elizbathjames at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

Elizbath Martin <elizbathjames at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |elizbathjames at gmail dot com

--- Comment #40 from Elizbath Martin <elizbathjames at gmail dot com> ---
Key factors might be the reason due to which its showing slow behavior. Make a
class of it and use it for the simple.
https://sourceforge.net/projects/working-of-smoothie-machines/ sometimes they
shows the abnormal behavior their might be list of reason you have to Go for.

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[feritzpowell at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

Wellamjames <feritzpowell at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |feritzpowell at gmail dot com

--- Comment #41 from Wellamjames <feritzpowell at gmail dot com> ---
Bugs and error can be quiet destructive for any system. So it's better to get
solved the problems on time. Like a cooling system a refrigerator or an air
conditioner are our daily us appliances but some times due to carelessness in
the maintenance it fails to deliver the desire results
http://airconditioner-notcooling.com/how-to-identify-problems-of-your-air-conditioner-and-get-it-fixed/
shows complete way out to face such kind of the problems.

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[100adult at armyspy dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

steve <100adult at armyspy dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |100adult at armyspy dot com

--- Comment #42 from steve <100adult at armyspy dot com> ---
<a href="http://www.10ults.com/escorts-in-usa.html" rel="dofollow">Escorts in
USA</a>

[Bug libstdc++/50160] vector<bool> comparison very slow (no overload)

[100adult at armyspy dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160

--- Comment #43 from steve <100adult at armyspy dot com> ---
http://www.10ults.com/escorts-in-usa.html
thanks for