From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27501 invoked by alias); 17 Nov 2009 22:18:57 -0000 Received: (qmail 27491 invoked by uid 22791); 17 Nov 2009 22:18:56 -0000 X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_40,RCVD_IN_JMF_BL,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Nov 2009 22:17:52 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0KT900000XOUE700@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Wed, 18 Nov 2009 00:17:29 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.37.193]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KT900MEVXX4VQ30@a-mtaout21.012.net.il>; Wed, 18 Nov 2009 00:17:29 +0200 (IST) Date: Tue, 17 Nov 2009 22:18:00 -0000 From: Eli Zaretskii Subject: Re: [patch 3/4] Fix hw watchpoints #2: reordered / simultaneously hit In-reply-to: <20091117194110.GC5266@adacore.com> To: Joel Brobecker Cc: jan.kratochvil@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83d43gn6dd.fsf@gnu.org> References: <20091116034156.GD22701@host0.dyn.jankratochvil.net> <20091117001056.GE4557@adacore.com> <83k4xpn6hz.fsf@gnu.org> <20091117141139.GA5266@adacore.com> <20091117152912.GA29979@host0.dyn.jankratochvil.net> <83fx8dm05c.fsf@gnu.org> <20091117194110.GC5266@adacore.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00396.txt.bz2 > Date: Tue, 17 Nov 2009 14:41:10 -0500 > From: Joel Brobecker > Cc: Jan Kratochvil , gdb-patches@sourceware.org > > > This is what I remembered, at least for x86. A single additional > > instruction can hardly cause any visible slowdown, at least not with > > access patterns typical for such flags. > > > > Any other reasons not to use bitfields? > > No. I just think it is unnecessary, and I'd rather avoid them. If you are > so strongly opinionated about this, or if others agree with you that it > is better, I really don't mind all that much. I don't have strong opinions either way. I was just surprised that you seemed to have opinions strong enough to comment on the usage of bitfields in Jan's code. FWIW, I've seen lots of good code using bitfields. Emacs comes to mind. I've also seen lots of code that didn't use them. I don't think we should care too much about this, except, as you point out, when memory is or could be at a premium.