Now gcc 3.2 bit me and allowed code before declaration. Any flags you can add to CFLAGS to not allow that sort of evilness?
That is the default.
pelix:~/tmp% gcc -c foo.c pelix:~/tmp% gcc -std=c89 -c foo.c pelix:~/tmp% gcc -std=c99 -c foo.c pelix:~/tmp% gcc -pedantic -c foo.c foo.c: In function `main': foo.c:5: warning: ISO C89 forbids mixed declarations and code pelix:~/tmp% gcc -pedantic -std=c89 -c foo.c foo.c: In function `main': foo.c:5: warning: ISO C89 forbids mixed declarations and code pelix:~/tmp% gcc -pedantic -std=c99 -c foo.c pelix:~/tmp%
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-12-09 15:33: Subject: gcc 3.2
Try
gcc -std=c89
/ Niels Möller ()
-pedantic isn't very useful. It gives too many warnings - 4 every source file from includes clogs most other output.
bignum.h:63: warning: ISO C89 does not support `long long' bignum.h:64: warning: ISO C89 does not support `long long' global.h:241: warning: ISO C89 does not support `long long' global.h:241: warning: ISO C89 does not support `long long'
long long is useful and configure-tested to work, so these warnings are useless. I suppose there is no way to error for declarations in the wrong order and yet not warn for long long?
/ Mirar
Previous text:
2002-12-09 17:00: Subject: gcc 3.2
That is the default.
pelix:~/tmp% gcc -c foo.c pelix:~/tmp% gcc -std=c89 -c foo.c pelix:~/tmp% gcc -std=c99 -c foo.c pelix:~/tmp% gcc -pedantic -c foo.c foo.c: In function `main': foo.c:5: warning: ISO C89 forbids mixed declarations and code pelix:~/tmp% gcc -pedantic -std=c89 -c foo.c foo.c: In function `main': foo.c:5: warning: ISO C89 forbids mixed declarations and code pelix:~/tmp% gcc -pedantic -std=c99 -c foo.c pelix:~/tmp%
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
-pedantic -Wno-long-long
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-12-09 17:10: Subject: gcc 3.2
-pedantic isn't very useful. It gives too many warnings - 4 every source file from includes clogs most other output.
bignum.h:63: warning: ISO C89 does not support `long long' bignum.h:64: warning: ISO C89 does not support `long long' global.h:241: warning: ISO C89 does not support `long long' global.h:241: warning: ISO C89 does not support `long long'
long long is useful and configure-tested to work, so these warnings are useless. I suppose there is no way to error for declarations in the wrong order and yet not warn for long long?
/ Mirar
I find it odd that you need -pedantic to get warnings. Something like -std=c89 -Wall ought to be enough. (Of course, you may want to use -pedantic anywy, for some other reason, that should be orthogonal to selecting the ANSI-C version)
/ Niels Möller ()
Previous text:
2002-12-09 17:00: Subject: gcc 3.2
That is the default.
pelix:~/tmp% gcc -c foo.c pelix:~/tmp% gcc -std=c89 -c foo.c pelix:~/tmp% gcc -std=c99 -c foo.c pelix:~/tmp% gcc -pedantic -c foo.c foo.c: In function `main': foo.c:5: warning: ISO C89 forbids mixed declarations and code pelix:~/tmp% gcc -pedantic -std=c89 -c foo.c foo.c: In function `main': foo.c:5: warning: ISO C89 forbids mixed declarations and code pelix:~/tmp% gcc -pedantic -std=c99 -c foo.c pelix:~/tmp%
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
It's gcc. Being odd is what it does best.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-12-09 17:30: Subject: gcc 3.2
I find it odd that you need -pedantic to get warnings. Something like -std=c89 -Wall ought to be enough. (Of course, you may want to use -pedantic anywy, for some other reason, that should be orthogonal to selecting the ANSI-C version)
/ Niels Möller ()
And -pedantic _is_ orthogonal to selecting the ANSI-C version. -pedantic just controls whether gcc actually cares if you break the selected standard.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-12-09 17:30: Subject: gcc 3.2
I find it odd that you need -pedantic to get warnings. Something like -std=c89 -Wall ought to be enough. (Of course, you may want to use -pedantic anywy, for some other reason, that should be orthogonal to selecting the ANSI-C version)
/ Niels Möller ()
I added a --enable-pedantic to configure now. I also made the warnings reappear for me (make.conf set CFLAGS which set cflags_is_set which disabled both warnings and optimizations), including -Wno-long-long.
Most of the warnings are considered about empty ";" outside functions. I suppose they come from define usage such as:
#if (something) #define SOME_FUNC(X) int PIKE_CONCAT(SOME_FUNC,X) (blah) #else #define SOME_FUNC(X) #endif
SOME_FUNC(foo); ^
But I haven't investigated more then fix a zillion of those in layers.c yet. I'll compile my xenofarm 7.5 with pedantic so I get a good warning log...
/ Mirar
Previous text:
2002-12-09 17:34: Subject: gcc 3.2
And -pedantic _is_ orthogonal to selecting the ANSI-C version. -pedantic just controls whether gcc actually cares if you break the selected standard.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
In the last episode (Dec 10), Mirar @ Pike developers forum said:
I added a --enable-pedantic to configure now. I also made the warnings reappear for me (make.conf set CFLAGS which set cflags_is_set which disabled both warnings and optimizations), including -Wno-long-long.
Most of the warnings are considered about empty ";" outside functions. I suppose they come from define usage such as:
#if (something) #define SOME_FUNC(X) int PIKE_CONCAT(SOME_FUNC,X) (blah) #else #define SOME_FUNC(X) #endif
SOME_FUNC(foo); ^
But I haven't investigated more then fix a zillion of those in layers.c yet. I'll compile my xenofarm 7.5 with pedantic so I get a good warning log...
If you want to fix stuff like that, I'll turn my strict tcc build back on. I'm not sure it's worth fixing though. A took a lot at some of them and it would be difficult to ensure that no stray ;'s remained in all cases.
I got about 34 unique such warnings in interpret_functions.h and 1 warning in gc.h, it doesn't seem to hard to fix. But I don't know what happens on other systems...
/ Mirar
Previous text:
2002-12-10 17:55: Subject: Re: gcc 3.2
In the last episode (Dec 10), Mirar @ Pike developers forum said:
I added a --enable-pedantic to configure now. I also made the warnings reappear for me (make.conf set CFLAGS which set cflags_is_set which disabled both warnings and optimizations), including -Wno-long-long.
Most of the warnings are considered about empty ";" outside functions. I suppose they come from define usage such as:
#if (something) #define SOME_FUNC(X) int PIKE_CONCAT(SOME_FUNC,X) (blah) #else #define SOME_FUNC(X) #endif
SOME_FUNC(foo); ^
But I haven't investigated more then fix a zillion of those in layers.c yet. I'll compile my xenofarm 7.5 with pedantic so I get a good warning log...
If you want to fix stuff like that, I'll turn my strict tcc build back on. I'm not sure it's worth fixing though. A took a lot at some of them and it would be difficult to ensure that no stray ;'s remained in all cases.
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
Gah, I'm confused.
Why does
| OPCODE1_BRANCH(F_BRANCH_IF_NOT_LOCAL, "branch if !local", 0, { | ... | }); ^ expand to
| void opcode_F_BRANCH_IF_NOT_LOCAL(int arg1) { ... } } } ^ while
| CJUMP(F_BRANCH_WHEN_EQ, "branch if ==", is_eq); ^ expands to
| void opcode_F_BRANCH_WHEN_EQ(void) { ... } }; ^ ?
Ie/and is there a prettier way of getting rid of the warnings without rewriting interpret_functions.h without semicolons?
/ Mirar
Previous text:
2002-12-10 18:43: Subject: Re: gcc 3.2
I got about 34 unique such warnings in interpret_functions.h and 1 warning in gc.h, it doesn't seem to hard to fix. But I don't know what happens on other systems...
/ Mirar
Ok, first tcc problem:
"conftest.c", line 1: Error: [ISO 6.8.4]: Line number out of range in '#line'.
#line 32857 "configure"
C89 appears to have had a linenumber limit of 16bits signed. C99 has a limit of 32bits signed:
6.8.4 Line control [...] The digit sequence shall not specify zero, nor a number greater than 2147483647.
/ Henrik Grubbström (Lysator)
Previous text:
2002-12-10 17:55: Subject: Re: gcc 3.2
In the last episode (Dec 10), Mirar @ Pike developers forum said:
I added a --enable-pedantic to configure now. I also made the warnings reappear for me (make.conf set CFLAGS which set cflags_is_set which disabled both warnings and optimizations), including -Wno-long-long.
Most of the warnings are considered about empty ";" outside functions. I suppose they come from define usage such as:
#if (something) #define SOME_FUNC(X) int PIKE_CONCAT(SOME_FUNC,X) (blah) #else #define SOME_FUNC(X) #endif
SOME_FUNC(foo); ^
But I haven't investigated more then fix a zillion of those in layers.c yet. I'll compile my xenofarm 7.5 with pedantic so I get a good warning log...
If you want to fix stuff like that, I'll turn my strict tcc build back on. I'm not sure it's worth fixing though. A took a lot at some of them and it would be difficult to ensure that no stray ;'s remained in all cases.
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
In the last episode (Dec 11), Henrik Grubbstrm (Lysator) @ Pike (-) developers forum said:
Ok, first tcc problem:
"conftest.c", line 1: Error: [ISO 6.8.4]: Line number out of range in '#line'.
#line 32857 "configure"
C89 appears to have had a linenumber limit of 16bits signed. C99 has a limit of 32bits signed:
The current release of tcc is only C89 compliant. I am rebuilding a tcc with that check removed, since it seems to be one of the few that I cannot simply convert into a warning with commandline switches. I doubt any compiler actually does this range check in real life.
The limit is probably a remnant of old compilers which had 16bit ints. Since Pike doesn't support compilation with such compilers it's a non- issue.
/ Henrik Grubbström (Lysator)
Previous text:
2002-12-11 16:41: Subject: Re: gcc 3.2
In the last episode (Dec 11), Henrik Grubbstrm (Lysator) @ Pike (-) developers forum said:
Ok, first tcc problem:
"conftest.c", line 1: Error: [ISO 6.8.4]: Line number out of range in '#line'.
#line 32857 "configure"
C89 appears to have had a linenumber limit of 16bits signed. C99 has a limit of 32bits signed:
The current release of tcc is only C89 compliant. I am rebuilding a tcc with that check removed, since it seems to be one of the few that I cannot simply convert into a warning with commandline switches. I doubt any compiler actually does this range check in real life.
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
Another unimportant warning is that C89 limits strings to 509 bytes or something. Larger strings is used on several occations in Pike.
/ Mirar
Previous text:
2002-12-11 16:58: Subject: Re: gcc 3.2
The limit is probably a remnant of old compilers which had 16bit ints. Since Pike doesn't support compilation with such compilers it's a non- issue.
/ Henrik Grubbström (Lysator)
I'd really prefer if such cases weren't "fixed", actually. Such semicolons help keep the context sensitive indentation provided by e.g. CC Mode sane.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-12-10 08:56: Subject: gcc 3.2
I added a --enable-pedantic to configure now. I also made the warnings reappear for me (make.conf set CFLAGS which set cflags_is_set which disabled both warnings and optimizations), including -Wno-long-long.
Most of the warnings are considered about empty ";" outside functions. I suppose they come from define usage such as:
#if (something) #define SOME_FUNC(X) int PIKE_CONCAT(SOME_FUNC,X) (blah) #else #define SOME_FUNC(X) #endif
SOME_FUNC(foo); ^
But I haven't investigated more then fix a zillion of those in layers.c yet. I'll compile my xenofarm 7.5 with pedantic so I get a good warning log...
/ Mirar
And the compilation logs provided by Xenofarm is already filtered, so it is possible to make this noise dissapear from our radar as well. Currently the following are removed completely (case insensitive):
constant removed_warnings = ({ "configure: warning: cleaning the environment from autoconf 2.5x pollution", "cc: 1501-245 warning: hard ulimit has been reduced to less than " "rlim_infinity. there may not be enough space to complete the " "compilation.", "cc1: warning: -fpic ignored (all code is position independent)", });
/ Martin Nilsson (hehe Torgny)
Previous text:
2002-12-10 22:11: Subject: gcc 3.2
I'd really prefer if such cases weren't "fixed", actually. Such semicolons help keep the context sensitive indentation provided by e.g. CC Mode sane.
/ Martin Stjernholm, Roxen IS
It's still a problem for anyone who compile locally with --enable-pedantic, so it's a gross oversimplification to say that the problem disappear just because there's a filter in Xenofarm.
I just tried with --enable-pedantic and got countless of warnings about the gcc-isms that comes from valgrind.h (by use of --with-valgrind). Pity.. :\
/ Martin Stjernholm, Roxen IS
Previous text:
2002-12-10 22:19: Subject: gcc 3.2
And the compilation logs provided by Xenofarm is already filtered, so it is possible to make this noise dissapear from our radar as well. Currently the following are removed completely (case insensitive):
constant removed_warnings = ({ "configure: warning: cleaning the environment from autoconf 2.5x pollution", "cc: 1501-245 warning: hard ulimit has been reduced to less than " "rlim_infinity. there may not be enough space to complete the " "compilation.", "cc1: warning: -fpic ignored (all code is position independent)", });
/ Martin Nilsson (hehe Torgny)
The goal here is of course to increase portability and to fix bugs by getting as strict warnings as possible and then remove them either by code changes or by dismissal and filtering. To save paper for people compiling Pike on a printer TTY is a non-goal as I see it.
/ Martin Nilsson (hehe Torgny)
Previous text:
2002-12-10 22:39: Subject: gcc 3.2
It's still a problem for anyone who compile locally with --enable-pedantic, so it's a gross oversimplification to say that the problem disappear just because there's a filter in Xenofarm.
I just tried with --enable-pedantic and got countless of warnings about the gcc-isms that comes from valgrind.h (by use of --with-valgrind). Pity.. :\
/ Martin Stjernholm, Roxen IS
Now you're silly. The usefulness of warnings rapidly disappears if there is irrelevant noise among them. A filter in Xenofarm is very far from a complete solution for that.
I hope there's some way to remove that particular warning altogether.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-12-10 22:46: Subject: gcc 3.2
The goal here is of course to increase portability and to fix bugs by getting as strict warnings as possible and then remove them either by code changes or by dismissal and filtering. To save paper for people compiling Pike on a printer TTY is a non-goal as I see it.
/ Martin Nilsson (hehe Torgny)
Hmm. You can build binaries with valgrind support? What benefit is this over running valgrind on a normal binary?
/ David Hedbor
Previous text:
2002-12-10 22:39: Subject: gcc 3.2
It's still a problem for anyone who compile locally with --enable-pedantic, so it's a gross oversimplification to say that the problem disappear just because there's a filter in Xenofarm.
I just tried with --enable-pedantic and got countless of warnings about the gcc-isms that comes from valgrind.h (by use of --with-valgrind). Pity.. :\
/ Martin Stjernholm, Roxen IS
Yes. It allows more accurate checking inside e.g. the block_alloc memory blocks, on the unitialized part of the pike stack, and of the memory block padding that dmalloc adds (although it's painfully slow to run a pike with both valgrind and dmalloc).
/ Martin Stjernholm, Roxen IS
Previous text:
2002-12-10 22:46: Subject: gcc 3.2
Hmm. You can build binaries with valgrind support? What benefit is this over running valgrind on a normal binary?
/ David Hedbor
How does a valgrind-xenofarm-target look like? Simply --with-valgrind?
/ Mirar
Previous text:
2002-12-10 22:39: Subject: gcc 3.2
It's still a problem for anyone who compile locally with --enable-pedantic, so it's a gross oversimplification to say that the problem disappear just because there's a filter in Xenofarm.
I just tried with --enable-pedantic and got countless of warnings about the gcc-isms that comes from valgrind.h (by use of --with-valgrind). Pity.. :\
/ Martin Stjernholm, Roxen IS
It looks like it. It terminates with:
| Doing tests in testsuite (10401 tests) | 0: +==11678== discard 2 (36 -> 283) translations in range 0x2DF5F51E .. 0x2DF5F541 | REPE then 0xF | | valgrind: the `impossible' happened: | Unhandled REPE case | Basic block ctr is approximately 87450000 | | sched status: | | Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 | ==11678== at 0x80FB3A0: float_promote (in /home/xenofarm/xenoclient/pike-7.5/orchid.mirar.org/buildtmp/Pike7.5-20021211-071641/build/linux-2.4.20-i686/test-install/pike/7.5.1/bin/pike) | ==11678== by 0x8100BD1: o_divide (in /home/xenofarm/xenoclient/pike-7.5/orchid.mirar.org/buildtmp/Pike7.5-20021211-071641/build/linux-2.4.20-i686/test-install/pike/7.5.1/bin/pike) | ==11678== by 0x2E40D974: ??? | ==11678== by 0x80785E6: o_catch (in /home/xenofarm/xenoclient/pike-7.5/orchid.mirar.org/buildtmp/Pike7.5-20021211-071641/build/linux-2.4.20-i686/test-install/pike/7.5.1/bin/pike) | | | For fixes for some common problems, see FAQ.txt in the source distribution. | | Please report this bug to me at: jseward@acm.org
:)
/ Mirar
Previous text:
2002-12-11 09:07: Subject: gcc 3.2
That and valgrind being installed should do it, I think.
/ Martin Stjernholm, Roxen IS
Haven't seen exactly that problem, but it doesn't live through the naughtier fork/thread tests.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-12-11 10:16: Subject: gcc 3.2
It looks like it. It terminates with:
| Doing tests in testsuite (10401 tests) | 0: +==11678== discard 2 (36 -> 283) translations in range 0x2DF5F51E .. 0x2DF5F541 | REPE then 0xF | | valgrind: the `impossible' happened: | Unhandled REPE case | Basic block ctr is approximately 87450000 | | sched status: | | Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 | ==11678== at 0x80FB3A0: float_promote (in /home/xenofarm/xenoclient/pike-7.5/orchid.mirar.org/buildtmp/Pike7.5-20021211-071641/build/linux-2.4.20-i686/test-install/pike/7.5.1/bin/pike) | ==11678== by 0x8100BD1: o_divide (in /home/xenofarm/xenoclient/pike-7.5/orchid.mirar.org/buildtmp/Pike7.5-20021211-071641/build/linux-2.4.20-i686/test-install/pike/7.5.1/bin/pike) | ==11678== by 0x2E40D974: ??? | ==11678== by 0x80785E6: o_catch (in /home/xenofarm/xenoclient/pike-7.5/orchid.mirar.org/buildtmp/Pike7.5-20021211-071641/build/linux-2.4.20-i686/test-install/pike/7.5.1/bin/pike) | | | For fixes for some common problems, see FAQ.txt in the source distribution. | | Please report this bug to me at: jseward@acm.org
:)
/ Mirar
I got the same error if I compile --without-copt --without-mmx --without-threads. (mmx needs -O to work.)
Valgrind 1.1.0 halts immediately on:
| Memcheck: mc_main.c:607 (set_address_range_perms): Assertion `vgSkin_cheap_sanity_check()' failed. | | sched status: | | Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 | ==22005== at 0x80FD1EE: alloc_more_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80FD214: alloc_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80FDAAD: debug_allocate_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80810B4: init_builtin_constants (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | | Please report this bug to: jseward@acm.org
The 1.1.0 header file lacks the macros Pike is using, so I used the 1.0.4 header file. I don't know if that matters.
Does Pike do anything wierd I should know about if I (as instructed) report the bug to valgrind author?
/ Mirar
Previous text:
2002-12-11 18:52: Subject: gcc 3.2
Haven't seen exactly that problem, but it doesn't live through the naughtier fork/thread tests.
/ Martin Stjernholm, Roxen IS
I wouldn't think it's safe to use the 1.0.4 header file with 1.1.0, considering that it expands to some magic assembler code that valgrind recognizes at runtime. What macros have disappeared in 1.1.0?
/ Martin Stjernholm, Roxen IS
Previous text:
2002-12-11 22:32: Subject: gcc 3.2
I got the same error if I compile --without-copt --without-mmx --without-threads. (mmx needs -O to work.)
Valgrind 1.1.0 halts immediately on:
| Memcheck: mc_main.c:607 (set_address_range_perms): Assertion `vgSkin_cheap_sanity_check()' failed. | | sched status: | | Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 | ==22005== at 0x80FD1EE: alloc_more_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80FD214: alloc_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80FDAAD: debug_allocate_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80810B4: init_builtin_constants (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | | Please report this bug to: jseward@acm.org
The 1.1.0 header file lacks the macros Pike is using, so I used the 1.0.4 header file. I don't know if that matters.
Does Pike do anything wierd I should know about if I (as instructed) report the bug to valgrind author?
/ Mirar
Also, 1.1.0 is not a stable version and not recommended for normal use.
/ Jonas Walldén
Previous text:
2002-12-11 22:34: Subject: gcc 3.2
I wouldn't think it's safe to use the 1.0.4 header file with 1.1.0, considering that it expands to some magic assembler code that valgrind recognizes at runtime. What macros have disappeared in 1.1.0?
/ Martin Stjernholm, Roxen IS
I was only using it to see if the 1.0.4 bug (9456031) was fixed.
The VALGRIND_MAKE_* macros has disappeared. The macro they use, VALGRIND_MAGIC_SEQUENCE, is identical.
Can the bug be caused by something Pike does with the macros? (To clearify, I'm talking about the one mentioned in 9456031.)
/ Mirar
Previous text:
2002-12-11 22:36: Subject: gcc 3.2
Also, 1.1.0 is not a stable version and not recommended for normal use.
/ Jonas Walldén
Sounds to me like 1.1.0 doesn't support that, then. I hope it's only temporary during the development, or else we'd better get in touch with him and let him know that those client calls are really useful and that it'd be a shame if they went away.
Can the bug be caused by something Pike does with the macros?
Apparently just by using them at all. You can always compile with --without-valgrind to avoid that, of course.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-12-11 22:51: Subject: gcc 3.2
I was only using it to see if the 1.0.4 bug (9456031) was fixed.
The VALGRIND_MAKE_* macros has disappeared. The macro they use, VALGRIND_MAGIC_SEQUENCE, is identical.
Can the bug be caused by something Pike does with the macros? (To clearify, I'm talking about the one mentioned in 9456031.)
/ Mirar
I don't think we are using 1.1.0, since it is a development version. Ensuring that it does work when it is released is of course a good...
/ Martin Nilsson (hehe Torgny)
Previous text:
2002-12-11 22:32: Subject: gcc 3.2
I got the same error if I compile --without-copt --without-mmx --without-threads. (mmx needs -O to work.)
Valgrind 1.1.0 halts immediately on:
| Memcheck: mc_main.c:607 (set_address_range_perms): Assertion `vgSkin_cheap_sanity_check()' failed. | | sched status: | | Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 | ==22005== at 0x80FD1EE: alloc_more_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80FD214: alloc_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80FDAAD: debug_allocate_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80810B4: init_builtin_constants (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | | Please report this bug to: jseward@acm.org
The 1.1.0 header file lacks the macros Pike is using, so I used the 1.0.4 header file. I don't know if that matters.
Does Pike do anything wierd I should know about if I (as instructed) report the bug to valgrind author?
/ Mirar
No, I assume most peopel is using 1.0.4. But 1.1.0 shouldn't be *that* bad... But I'm not very experienced with valgrind.
/ Mirar
Previous text:
2002-12-11 22:36: Subject: gcc 3.2
I don't think we are using 1.1.0, since it is a development version. Ensuring that it does work when it is released is of course a good...
/ Martin Nilsson (hehe Torgny)
1.1.0 is a rewrite, so it can be any kind of unpredictably good and bad.
/ Martin Nilsson (hehe Torgny)
Previous text:
2002-12-11 22:54: Subject: gcc 3.2
No, I assume most peopel is using 1.0.4. But 1.1.0 shouldn't be *that* bad... But I'm not very experienced with valgrind.
/ Mirar
But to answer your question: No, Pike only uses the macros in valgrind.h according to the docs.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-12-11 22:32: Subject: gcc 3.2
I got the same error if I compile --without-copt --without-mmx --without-threads. (mmx needs -O to work.)
Valgrind 1.1.0 halts immediately on:
| Memcheck: mc_main.c:607 (set_address_range_perms): Assertion `vgSkin_cheap_sanity_check()' failed. | | sched status: | | Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 | ==22005== at 0x80FD1EE: alloc_more_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80FD214: alloc_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80FDAAD: debug_allocate_mapping (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | ==22005== by 0x80810B4: init_builtin_constants (in /tmp/pikevalgrind/test-install/pike/7.5.1/bin/pike) | | Please report this bug to: jseward@acm.org
The 1.1.0 header file lacks the macros Pike is using, so I used the 1.0.4 header file. I don't know if that matters.
Does Pike do anything wierd I should know about if I (as instructed) report the bug to valgrind author?
/ Mirar
Yes, valgrind doesn't like code like the following:
if ((s->type == T_FUNCTION) && (s->subtype == FUNCTION_BUILTIN)) ...
which gcc (correctly) optimizes into
if (*((INT32 *)(&s->type)) == (T_FUNCTION | (FUNCTION_BUILTIN<<16))) ...
valgrind doesn't like that the value in the comparison isn't fully welldefined, but it doesn't need to be as long as the welldefined part of the value differs.
/ Henrik Grubbström (Lysator)
Previous text:
2002-12-11 10:18: Subject: gcc 3.2
You'll probably also need to disable all gcc optimizations.
/ Henrik Grubbström (Lysator)
"configure: warning: cleaning the environment from autoconf 2.5x pollution",
Why not just remove this warning from the configure script? It's pretty pointless anyway...
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-12-10 22:19: Subject: gcc 3.2
And the compilation logs provided by Xenofarm is already filtered, so it is possible to make this noise dissapear from our radar as well. Currently the following are removed completely (case insensitive):
constant removed_warnings = ({ "configure: warning: cleaning the environment from autoconf 2.5x pollution", "cc: 1501-245 warning: hard ulimit has been reduced to less than " "rlim_infinity. there may not be enough space to complete the " "compilation.", "cc1: warning: -fpic ignored (all code is position independent)", });
/ Martin Nilsson (hehe Torgny)
Just change "warning" to "note".
/ Peter Bortas
Previous text:
2002-12-10 23:06: Subject: gcc 3.2
"configure: warning: cleaning the environment from autoconf 2.5x pollution",
Why not just remove this warning from the configure script? It's pretty pointless anyway...
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Or to nothing at all. The message is only useful when debugging the configure script itself. It is of no utility to people just using the configure script.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-12-10 23:08: Subject: gcc 3.2
Just change "warning" to "note".
/ Peter Bortas
With --enable-pedantic I was hoping to avoid the mistake *before* checkin. It's not needed to detect the errors when it's built by xenofarm, the stricter compilers will show up red then anyway.
/ Mirar
Previous text:
2002-12-10 22:19: Subject: gcc 3.2
And the compilation logs provided by Xenofarm is already filtered, so it is possible to make this noise dissapear from our radar as well. Currently the following are removed completely (case insensitive):
constant removed_warnings = ({ "configure: warning: cleaning the environment from autoconf 2.5x pollution", "cc: 1501-245 warning: hard ulimit has been reduced to less than " "rlim_infinity. there may not be enough space to complete the " "compilation.", "cc1: warning: -fpic ignored (all code is position independent)", });
/ Martin Nilsson (hehe Torgny)
I kind of agree. That's why I wanted to see if there was a nother way of solving that. If the extra ';' isn't a problem in tcc -strict, or any other compiler, maybe we can get around it by filtering with -Wno-something?
/ Mirar
Previous text:
2002-12-10 22:11: Subject: gcc 3.2
I'd really prefer if such cases weren't "fixed", actually. Such semicolons help keep the context sensitive indentation provided by e.g. CC Mode sane.
/ Martin Stjernholm, Roxen IS
pike-devel@lists.lysator.liu.se
-
Dan Nelson -
David Hedbor ＠ Pike developers forum -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum
-
Jonas Walld�n ＠ Pike developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (hehe Torgny) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Niels M�ller () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum