* (len % 1) != 0 @ 2008-02-17 5:57 Bin Chen 2008-02-17 14:13 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Bin Chen @ 2008-02-17 5:57 UTC (permalink / raw) To: gdb Hello, In gdb/gdbserver/server.c, there is a line: if ((len % 1) != 0 || unhexify (mon, own_buf + 6, len / 2) != len / 2) I am curious that (len % 1) != 0 is always false, why put here? Thanks. Bin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: (len % 1) != 0 2008-02-17 5:57 (len % 1) != 0 Bin Chen @ 2008-02-17 14:13 ` Eli Zaretskii 2008-02-17 14:41 ` Bin Chen 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2008-02-17 14:13 UTC (permalink / raw) To: Bin Chen; +Cc: gdb > Date: Sun, 17 Feb 2008 13:57:31 +0800 > From: "Bin Chen" <binary.chen@gmail.com> > > Hello, > > In gdb/gdbserver/server.c, > > there is a line: > > if ((len % 1) != 0 || unhexify (mon, own_buf + 6, len / 2) != len / 2) > > I am curious that (len % 1) != 0 is always false, why put here? It's probably a bug: they meant len % 2. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: (len % 1) != 0 2008-02-17 14:13 ` Eli Zaretskii @ 2008-02-17 14:41 ` Bin Chen 2008-02-17 15:26 ` Daniel Jacobowitz 0 siblings, 1 reply; 12+ messages in thread From: Bin Chen @ 2008-02-17 14:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb, drow Hi Daniel, Is it a bug? On Sun, Feb 17, 2008 at 10:12 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > Date: Sun, 17 Feb 2008 13:57:31 +0800 > > From: "Bin Chen" <binary.chen@gmail.com> > > > > > > Hello, > > > > In gdb/gdbserver/server.c, > > > > there is a line: > > > > if ((len % 1) != 0 || unhexify (mon, own_buf + 6, len / 2) != len / 2) > > > > I am curious that (len % 1) != 0 is always false, why put here? > > It's probably a bug: they meant len % 2. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: (len % 1) != 0 2008-02-17 14:41 ` Bin Chen @ 2008-02-17 15:26 ` Daniel Jacobowitz 2008-02-19 16:32 ` Sheng-Liang Song 0 siblings, 1 reply; 12+ messages in thread From: Daniel Jacobowitz @ 2008-02-17 15:26 UTC (permalink / raw) To: Bin Chen; +Cc: Eli Zaretskii, gdb On Sun, Feb 17, 2008 at 10:41:36PM +0800, Bin Chen wrote: > Hi Daniel, > > Is it a bug? Yes. Fixed as below. -- Daniel Jacobowitz CodeSourcery 2008-02-17 Daniel Jacobowitz <dan@codesourcery.com> * server.c (handle_query): Correct length check. Index: server.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/server.c,v retrieving revision 1.64 diff -u -p -r1.64 server.c --- server.c 14 Feb 2008 16:42:55 -0000 1.64 +++ server.c 17 Feb 2008 15:25:22 -0000 @@ -649,7 +649,7 @@ handle_query (char *own_buf, int packet_ char *mon = malloc (PBUFSIZ); int len = strlen (own_buf + 6); - if ((len % 1) != 0 || unhexify (mon, own_buf + 6, len / 2) != len / 2) + if ((len % 2) != 0 || unhexify (mon, own_buf + 6, len / 2) != len / 2) { write_enn (own_buf); free (mon); ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: (len % 1) != 0 2008-02-17 15:26 ` Daniel Jacobowitz @ 2008-02-19 16:32 ` Sheng-Liang Song 2008-02-19 18:25 ` Dave Korn 0 siblings, 1 reply; 12+ messages in thread From: Sheng-Liang Song @ 2008-02-19 16:32 UTC (permalink / raw) To: Bin Chen, Eli Zaretskii, gdb or (len & 1) != 0 <=> (len % 2) != 0 Daniel Jacobowitz wrote: > On Sun, Feb 17, 2008 at 10:41:36PM +0800, Bin Chen wrote: > >> Hi Daniel, >> >> Is it a bug? >> > > Yes. Fixed as below. > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: (len % 1) != 0 2008-02-19 16:32 ` Sheng-Liang Song @ 2008-02-19 18:25 ` Dave Korn 2008-02-19 18:30 ` David Daney ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Dave Korn @ 2008-02-19 18:25 UTC (permalink / raw) To: 'Sheng-Liang Song', 'Bin Chen', 'Eli Zaretskii', gdb On 19 February 2008 16:30, Sheng-Liang Song wrote: > or > > (len & 1) != 0 <=> (len % 2) != 0 > That would have the advantage of not requiring a divide operation :) cheers, DaveK -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: (len % 1) != 0 2008-02-19 18:25 ` Dave Korn @ 2008-02-19 18:30 ` David Daney [not found] ` <18363.7810.91075.314867@gargle.gargle.HOWL> 2008-02-19 21:41 ` Andreas Schwab 2 siblings, 0 replies; 12+ messages in thread From: David Daney @ 2008-02-19 18:30 UTC (permalink / raw) To: Dave Korn Cc: 'Sheng-Liang Song', 'Bin Chen', 'Eli Zaretskii', gdb Dave Korn wrote: > On 19 February 2008 16:30, Sheng-Liang Song wrote: > >> or >> >> (len & 1) != 0 <=> (len % 2) != 0 >> > > That would have the advantage of not requiring a divide operation :) > But GCC will fold it to the bitwise and form, so it doesn't really matter. David Daney ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <18363.7810.91075.314867@gargle.gargle.HOWL>]
* RE: (len % 1) != 0 [not found] ` <18363.7810.91075.314867@gargle.gargle.HOWL> @ 2008-02-19 18:35 ` Dave Korn 2008-02-19 18:47 ` David Daney 0 siblings, 1 reply; 12+ messages in thread From: Dave Korn @ 2008-02-19 18:35 UTC (permalink / raw) To: gdb On 19 February 2008 18:23, Paul Koning wrote: >>>>>> "Dave" == Dave Korn <dave.korn@artimi.com> writes: > > Dave> On 19 February 2008 16:30, Sheng-Liang Song wrote: > >> or > >> > >> (len & 1) != 0 <=> (len % 2) != 0 > >> > > Dave> That would have the advantage of not requiring a divide > Dave> operation :) > > It shouldn't matter -- the optimizer will do the right thing, as I > recall. NB len == signed int. Yes, it can simplify it to a bunch of shifts and sign extends and masks without using an explicit divide, but it's not as good as a simple AND operation. (Maybe VRP in 4.x could handle that by knowing that the result of strlen has to be >= 0, but 3.x series won't do it). cheers, DaveK -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: (len % 1) != 0 2008-02-19 18:35 ` Dave Korn @ 2008-02-19 18:47 ` David Daney 2008-02-19 18:49 ` Daniel Jacobowitz 2008-02-19 19:08 ` Dave Korn 0 siblings, 2 replies; 12+ messages in thread From: David Daney @ 2008-02-19 18:47 UTC (permalink / raw) To: Dave Korn; +Cc: gdb Dave Korn wrote: > On 19 February 2008 18:23, Paul Koning wrote: > >>>>>>> "Dave" == Dave Korn <dave.korn@artimi.com> writes: >> Dave> On 19 February 2008 16:30, Sheng-Liang Song wrote: >> >> or >> >> >> >> (len & 1) != 0 <=> (len % 2) != 0 >> >> >> >> Dave> That would have the advantage of not requiring a divide >> Dave> operation :) >> >> It shouldn't matter -- the optimizer will do the right thing, as I >> recall. > > NB len == signed int. > > Yes, it can simplify it to a bunch of shifts and sign extends and masks > without using an explicit divide, but it's not as good as a simple AND > operation. (Maybe VRP in 4.x could handle that by knowing that the result of > strlen has to be >= 0, but 3.x series won't do it). > ?? Not to be pedantic, but on 3.4.3 for mipsel-linux I get: $ cat j.c int f1 (int a) { return (a % 2) != 0; } $ mipsel-linux-gcc -c -O3 j.c $ mipsel-linux-objdump -d j.o j.o: file format elf32-tradlittlemips Disassembly of section .text: 00000000 <f1>: 0: 03e00008 jr ra 4: 30820001 andi v0,a0,0x1 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: (len % 1) != 0 2008-02-19 18:47 ` David Daney @ 2008-02-19 18:49 ` Daniel Jacobowitz 2008-02-19 19:08 ` Dave Korn 1 sibling, 0 replies; 12+ messages in thread From: Daniel Jacobowitz @ 2008-02-19 18:49 UTC (permalink / raw) To: David Daney; +Cc: Dave Korn, gdb On Tue, Feb 19, 2008 at 10:35:20AM -0800, David Daney wrote: > ?? Not to be pedantic, but on 3.4.3 for mipsel-linux I get: Not to pick either of you in particular, but i you want to continue this, could you do it on the GCC lists instead of here? -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: (len % 1) != 0 2008-02-19 18:47 ` David Daney 2008-02-19 18:49 ` Daniel Jacobowitz @ 2008-02-19 19:08 ` Dave Korn 1 sibling, 0 replies; 12+ messages in thread From: Dave Korn @ 2008-02-19 19:08 UTC (permalink / raw) To: 'David Daney'; +Cc: gdb On 19 February 2008 18:35, David Daney wrote: > Dave Korn wrote: >> On 19 February 2008 18:23, Paul Koning wrote: >> >>>>>>>> "Dave" == Dave Korn <dave.korn@artimi.com> writes: >>> Dave> On 19 February 2008 16:30, Sheng-Liang Song wrote: >> or >>> >> >>> >> (len & 1) != 0 <=> (len % 2) != 0 >>> >> >>> >>> Dave> That would have the advantage of not requiring a divide Dave> >>> operation :) >>> >>> It shouldn't matter -- the optimizer will do the right thing, as I >>> recall. >> >> NB len == signed int. >> >> Yes, it can simplify it to a bunch of shifts and sign extends and masks >> without using an explicit divide, but it's not as good as a simple AND >> operation. (Maybe VRP in 4.x could handle that by knowing that the result >> of strlen has to be >= 0, but 3.x series won't do it). >> > > ?? Not to be pedantic, but on 3.4.3 for mipsel-linux I get: > > $ cat j.c > int f1 (int a) > { > return (a % 2) != 0; > } > $ mipsel-linux-gcc -c -O3 j.c > $ mipsel-linux-objdump -d j.o > > j.o: file format elf32-tradlittlemips > > Disassembly of section .text: > > 00000000 <f1>: > 0: 03e00008 jr ra > 4: 30820001 andi v0,a0,0x1 <lightbulb> Ah, it's the !=0 that allows the compiler to go that last step of the way, I was just testing int bar (int len) { return len % 2; } int baz (int len) { return len & 1; } Hmm, 3.4.4 on x86 still doesn't optimise it quite as well: /artimi/boards $ gcc -xc -S -oo.s -O2 - int bar (int len) { return len % 2; } int baz (int len) { return len & 1; } int bat (int len) { return (len % 2) != 0; } int quux (int len) { return (len & 1) != 0; } /artimi/boards $ cat o.s .file "" .text .globl _bar .def _bar; .scl 2; .type 32; .endef _bar: pushl %ebp movl %esp, %ebp movl 8(%ebp), %eax popl %ebp movl %eax, %edx shrl $31, %edx leal (%eax,%edx), %edx andl $-2, %edx subl %edx, %eax ret .p2align 4,,15 .globl _baz .def _baz; .scl 2; .type 32; .endef _baz: pushl %ebp movl %esp, %ebp movl 8(%ebp), %eax popl %ebp andl $1, %eax ret .p2align 4,,15 .globl _bat .def _bat; .scl 2; .type 32; .endef _bat: pushl %ebp xorl %eax, %eax movl %esp, %ebp testb $1, 8(%ebp) popl %ebp setne %al ret .p2align 4,,15 .globl _quux .def _quux; .scl 2; .type 32; .endef _quux: pushl %ebp movl %esp, %ebp movl 8(%ebp), %eax popl %ebp andl $1, %eax ret /artimi/boards/Kitsman/Test Boards/A200_TPCB002 $ cheers, DaveK -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: (len % 1) != 0 2008-02-19 18:25 ` Dave Korn 2008-02-19 18:30 ` David Daney [not found] ` <18363.7810.91075.314867@gargle.gargle.HOWL> @ 2008-02-19 21:41 ` Andreas Schwab 2 siblings, 0 replies; 12+ messages in thread From: Andreas Schwab @ 2008-02-19 21:41 UTC (permalink / raw) To: Dave Korn Cc: 'Sheng-Liang Song', 'Bin Chen', 'Eli Zaretskii', gdb "Dave Korn" <dave.korn@artimi.com> writes: > On 19 February 2008 16:30, Sheng-Liang Song wrote: > >> or >> >> (len & 1) != 0 <=> (len % 2) != 0 >> > > That would have the advantage of not requiring a divide operation :) The divide operation is already required and can be combined with the modulo operation. And this is by no means performance critical. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "Premature optimization is the root of all evil." ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-02-19 20:47 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-17 5:57 (len % 1) != 0 Bin Chen
2008-02-17 14:13 ` Eli Zaretskii
2008-02-17 14:41 ` Bin Chen
2008-02-17 15:26 ` Daniel Jacobowitz
2008-02-19 16:32 ` Sheng-Liang Song
2008-02-19 18:25 ` Dave Korn
2008-02-19 18:30 ` David Daney
[not found] ` <18363.7810.91075.314867@gargle.gargle.HOWL>
2008-02-19 18:35 ` Dave Korn
2008-02-19 18:47 ` David Daney
2008-02-19 18:49 ` Daniel Jacobowitz
2008-02-19 19:08 ` Dave Korn
2008-02-19 21:41 ` Andreas Schwab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox