On Wed, 2008-06-04 at 21:35 -0700, Joe Schaefer wrote:
> Needs a comment in the source about why we're using
> volatile here, but otherwise +1.
Done on both the trunk and v2_10 branch.
Any comment regarding my other patch about strict aliasing warnings?
--
Bojan
--- Bojan Smojver <[EMAIL PROTECTED]> wrote:
> I propose we fix this as attached. I tested this on
> Fedora 9 and it
> works OK. Opinions?
Needs a comment in the source about why we're using
volatile here, but otherwise +1.
I propose we fix this as attached. I tested this on Fedora 9 and it
works OK. Opinions?
--
Bojan
Index: library/parser_multipart.c
===
--- library/parser_multipart.c (revision 663420)
+++ library/parser_multipart.c (working copy)
@@
On Sun, 2006-06-11 at 20:31 -0400, Joe Schaefer wrote:
> This is the right approach, I think. But the person who'd be
> in the best place to test/commit it is Bojan. Just be sure
> to bump the patch level in apreq_version.h, and add a comment
> to CHANGES.
Get this. This code works:
--
Quoting Joe Schaefer <[EMAIL PROTECTED]>:
do { ... } while (0) is better- it's no longer a loop.
Instead of "while (e != APR_BRIGADE_FIRST(in))"?
What is the assembler now?
Similar:
---
.L19:
movq40(%rsp), %rbp
.LVL27:
movq
Bojan Smojver <[EMAIL PROTECTED]> writes:
> Quoting Joe Schaefer <[EMAIL PROTECTED]>:
>
>> This is the right approach, I think. But the person who'd be
>> in the best place to test/commit it is Bojan. Just be sure
>> to bump the patch level in apreq_version.h, and add a comment
>> to CHANGES.
>
Quoting Joe Schaefer <[EMAIL PROTECTED]>:
This is the right approach, I think. But the person who'd be
in the best place to test/commit it is Bojan. Just be sure
to bump the patch level in apreq_version.h, and add a comment
to CHANGES.
This code hangs the test (Joe Orton's original suggestio
Quoting Bojan Smojver <[EMAIL PROTECTED]>:
Looks like the offsetof() provided by the platform isn't being used.
Which in turn causes a lot of casting all over the place, which
creates the aliasing problem? Maybe?
Nah, it isn't that... Fails just the same with native offsetof() :-(
--
Bojan
Quoting Bojan Smojver <[EMAIL PROTECTED]>:
I can test the above in my setup and see what comes out, but I'm more
worried about the incorrectly compiled code and why it happened. I'm not
sure if it's due to bugs in gcc, or is it something that RING/BRIGADE
macros are doing that really isn't quite
On Sun, 2006-06-11 at 20:31 -0400, Joe Schaefer wrote:
> > APR_RING_UNSPLICE(f, l, link);
> > APR_RING_SPLICE_TAIL(&out->list, f, l, apr_bucket, link);
> >
>
> This is the right approach, I think. But the person who'd be
> in the best place to test/commit it is Bojan. Just b
"Philip M. Gollucci" <[EMAIL PROTECTED]> writes:
> do {
> apr_bucket *f = APR_BRIGADE_FIRST(in);
> APR_BUCKET_REMOVE(f);
> APR_BRIGADE_INSERT_TAIL(out, f);
> } while (e != APR_BRIGADE_FIRST(in));
This loop appends all the buc
Joe Orton wrote:
A loop like this will not terminate if "e" points to the brigade
sentinel on entry; not sure if this is possible in the context of this
code, but it's easy enough to verify with an assertion.
else if (off > 0) {
/* prior (partial) strncmp failed,
[please CC me on replies]
On Tue, May 30, 2006 at 12:13:09PM +1000, Bojan Smojver wrote:
> I'm seeing an endless loop in this part of the code:
>
>
> do {
> apr_bucket *f = APR_BRIGADE_FIRST(in);
> APR_BU
Quoting "Philip M. Gollucci" <[EMAIL PROTECTED]>:
Seems to be Fedora Core X specific.
Happens on x84_64 as well and with 2.07. Rebuilding the package in
Fedora Extras 5 now.
--
Bojan
Quoting Joe Schaefer <[EMAIL PROTECTED]>:
At least now it's a bit clearer why the no-strict-aliasing
optimization is getting confused ;-)
Hey, speak for yourself ;-)
--
Bojan
Bojan Smojver <[EMAIL PROTECTED]> writes:
> Quoting Joe Schaefer <[EMAIL PROTECTED]>:
>
>> Are you sure the "intermediate code" is correct?
>> It's calling free and destroy, which makes me think
>> that's some other "delete buckets" loop, not this one.>
>
> Nice catch! The correct snippet is:
>
>
Quoting Joe Schaefer <[EMAIL PROTECTED]>:
Are you sure the "intermediate code" is correct?
It's calling free and destroy, which makes me think
that's some other "delete buckets" loop, not this one.>
Nice catch! The correct snippet is:
---
do {
Bojan Smojver <[EMAIL PROTECTED]> writes:
> Quoting Bojan Smojver <[EMAIL PROTECTED]>:
>
>> I will report this in Red Hat Bugzilla and we'll see what the problem
>> really is (i.e. is it something in gcc or maybe even APR).
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193740
Are you s
Quoting Bojan Smojver <[EMAIL PROTECTED]>:
I will report this in Red Hat Bugzilla and we'll see what the problem
really is (i.e. is it something in gcc or maybe even APR).
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193740
--
Bojan
Quoting "Philip M. Gollucci" <[EMAIL PROTECTED]>:
gcc version 3.4.4 [FreeBSD] 20050518
That's probably why. Optimization was reworked in 4.1 completely.
--
Bojan
Bojan Smojver wrote:
Quoting "Philip M. Gollucci" <[EMAIL PROTECTED]>:
my CFLAGS on FreeBSD are
-g -O2 -Werror -Wall -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -Wwrite-strings -Wcast-qual -Wfloat-equal
-Wshadow -Wpointer-arith -Wbad-function-cast -Wsign-compare
-Waggregate-
Quoting "Philip M. Gollucci" <[EMAIL PROTECTED]>:
my CFLAGS on FreeBSD are
-g -O2 -Werror -Wall -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -Wwrite-strings -Wcast-qual -Wfloat-equal
-Wshadow -Wpointer-arith -Wbad-function-cast -Wsign-compare
-Waggregate-return -Wmissing-noret
With -fno-strict-aliasing, I get:
my CFLAGS on FreeBSD are
-g -O2 -Werror -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wwrite-strings -Wcast-qual
-Wfloat-equal -Wshadow -Wpointer-arith -Wbad-function-cast -Wsign-compare -Waggregate-return -Wmissing-noreturn
-Wmissing-f
On Wed, 2006-05-31 at 10:49 -0700, Philip M. Gollucci wrote:
> So, does library/t/parsers fail for you without the -fno-strict-aliasing flag
> under -02 ?
Yes. The output is:
versionok
cookie.ok
params.ok
parsersok 1/542
Now, the same code compiled with -fno-strict-aliasing (and -O2) gives:
EGAD!
I'll look later... I don't think I'll do much better then you. Maybe we should
forward to
the gcc-dev list ?
Also, is -fno-strict-aliasing support on all gcc versions ?
So, does library/t/parsers fail for you withou
On Wed, 2006-05-31 at 02:18 -0700, Philip M. Gollucci wrote:
> Looking at library/parser_multipart.c and associated tests t/parsers.c ->
> we definetely exercise that code block sucessfully.
Here is the good news: I don't think this is a problem in libapreq2 (or
at least not on all platforms/comp
Thanks for your help. I'll see I go with GDB first. If I get nowhwere,
I'll try the .t.
Looking at library/parser_multipart.c and associated tests t/parsers.c ->
we definetely exercise that code block sucessfully.
If you copy httpd's .gdbinit file you can make use of
dump_brigade in
dump_brigade
Quoting "Philip M. Gollucci" <[EMAIL PROTECTED]>:
I'm guessing this is a Perl thing. I'm in C, so this probably isn't
going to be very useful. I'm watching the whole thing in gdb anyway.
If you can write a *.t test for it, I can try and see if I A)
duplicate, and B) help
you some this evening
I'm guessing this is a Perl thing. I'm in C, so this probably isn't
going to be very useful. I'm watching the whole thing in gdb anyway.
If you can write a *.t test for it, I can try and see if I A) duplicate, and B)
help
you some this evening.
--
Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.
Quoting "Philip M. Gollucci" <[EMAIL PROTECTED]>:
You might try using Apache2::DebugFilter to see what buckets are
getting passed, but I think
the apreq filter is hooked before that.
I'm guessing this is a Perl thing. I'm in C, so this probably isn't
going to be very useful. I'm watching the
Bojan Smojver wrote:
I'm seeing an endless loop in this part of the code:
do {
apr_bucket *f = APR_BRIGADE_FIRST(in);
APR_BUCKET_REMOVE(f);
APR_BRIGADE_INSERT_TAIL(out, f);
}
On Tue, 2006-05-30 at 12:13 +1000, Bojan Smojver wrote:
> I'm seeing an endless loop in this part of the code:
Sorry... Forgot to mention that this is 2.08-RC2.
--
Bojan
I'm seeing an endless loop in this part of the code:
do {
apr_bucket *f = APR_BRIGADE_FIRST(in);
APR_BUCKET_REMOVE(f);
APR_BRIGADE_INSERT_TAIL(out, f);
} while (e != APR_BRIGADE
33 matches
Mail list logo
