Building valgrind on Mountain Lion with Xcode 4.5.whatever (from the command line, of course :-)) generated some const-qualifier-removed warnings and some data-type warnings. Reproducible: Always Steps to Reproduce: ./autogen.sh; ./configure; make
Created attachment 76346 [details] patch to squelch the warnings
There are also some signedness warnings; I haven't looked to see whether those can be cleanly and correctly fixed by changing some types. (DEC has a lot to answer for with the sign-extending byte instructions on the PDP-11.... :-))
Created attachment 76355 [details] patch to squelch the warnings in the VEX subtree (So what's the deal with VEX? Should patches for that be submitted here or to the external source whence it comes?) This change turns vassert(imm8 >= 0 && imm8 <= 255); into vassert(imm8 <= 255); and does similar things for imm4 because imm8 and imm4 are unsigned and are thus always >= 0. If it's considered a bit more "self-documenting" to put in a check against 0, feel free to leave that check in (or leave it in, commented out).
(In reply to comment #3) > (So what's the deal with VEX? Should patches for that be submitted here or > to the external source whence it comes?) I guess the answer is "the vex component"; should I file a separate bug for it, or is this sufficient?
(In reply to comment #1) > Created attachment 76346 [details] > patch to squelch the warnings Thanks for the patch. I've applied it as r13231.
(In reply to comment #3) > Created attachment 76355 [details] > patch to squelch the warnings in the VEX subtree > > (So what's the deal with VEX? Should patches for that be submitted here or > to the external source whence it comes?) Yes, just select the VEX component. There is no separate bugzilla for VEX. > > This change turns > > vassert(imm8 >= 0 && imm8 <= 255); > > into > > vassert(imm8 <= 255); > > and does similar things for imm4 because imm8 and imm4 are unsigned and are > thus always >= 0. If it's considered a bit more "self-documenting" to put > in a check against 0, feel free to leave that check in (or leave it in, > commented out). Yes, this style is intentional. You'll find it all over valgrind. You will have to silence clang somehow. I've committed the change to guest_amd_toIR.c as VEX r2634. Thanks for the patches.