x32 psABI status update
On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu wrote: > Hi, > > I updated x32 psABI draft to version 0.2 to change x32 library path > from lib32 to libx32 since lib32 is used for ia32 libraries on Debian, > Ubuntu and other derivative distributions. The new x32 psABI is > available from: > > https://sites.google.com/site/x32abi/home > Initial kernel, glibc and gcc port for x32 psABI draft version 0.2 is done: 1. Kernel should be very stable. Fedora 14 kernel patch is also available. 2. Need to fix GCC run-time libraries. 3. Need to fix glibc tests. Please check them out and provide feed backs. Thanks. -- H.J.
Re: MIPS: Trouble with address calculation near the useg/kseg boundary
On 02/16/2011 02:32 PM, Paul Koning wrote:
On Feb 16, 2011, at 5:25 PM, David Daney wrote:
What is the state of your C0_Status[{KX,SX,UX}] bits?
0, 0, 0
It is not really a compiler bug, but rather a defect in the n32 ABI. When using
32-bit pointers you can only do 32-bit operations on them. To do otherwise
raises the possibility of generating addresses that fall outside of the allowed
range.
Sure, I understand that. Actually, I'm using O64, but the issue is the same as
with N32.
??
The problem is that the machine is doing 64 bit arithmetic when applying an
offset to a base register. So what the compiler has to do is valid 64 bit
operations from 32-bit sign extended memory and constant values.
But as you have found, there is this 64kb region centered on the split where
behavior can become undefined.
The only real way to avoid it would be to prohibit GCC from generating non-zero
offsets for load/store instructions, the resulting code would be slower and
bigger than the current behavior of using the offsets in address calculations.
I don't think it needs to do anything slower. As far as I can tell, the only
change needed is that arithmetic on pointer values held in registers must be
done with 64-bit operations. That just changes the opcodes, but it doesn't
make them any longer.
So to answer your question:
I think your 'compiler bug' is a false predicate. And yes, I do suggest that
you modify your kernel.
I don't have the option of modifying the kernel, since I'm dealing with data
structures that are at hardwired addresses and moving them isn't an available
option.
I guess I'll go beat on the code generator...
It might be easier to do something to force the base address into a
register so that the offsetting doesn't happen.
Something like:
struct foo *v = (struct foo *)0x80007110UL;
v -= 2;
/* Clobber v so GCC forces the value into a register. */
asm("" : "+r" (v));
int bar = v->element;
.
.
.
Re: MIPS: Trouble with address calculation near the useg/kseg boundary
On Feb 16, 2011, at 5:25 PM, David Daney wrote:
> What is the state of your C0_Status[{KX,SX,UX}] bits?
0, 0, 0
>
> It is not really a compiler bug, but rather a defect in the n32 ABI. When
> using 32-bit pointers you can only do 32-bit operations on them. To do
> otherwise raises the possibility of generating addresses that fall outside of
> the allowed range.
Sure, I understand that. Actually, I'm using O64, but the issue is the same as
with N32.
The problem is that the machine is doing 64 bit arithmetic when applying an
offset to a base register. So what the compiler has to do is valid 64 bit
operations from 32-bit sign extended memory and constant values.
>
> But as you have found, there is this 64kb region centered on the split where
> behavior can become undefined.
>
> The only real way to avoid it would be to prohibit GCC from generating
> non-zero offsets for load/store instructions, the resulting code would be
> slower and bigger than the current behavior of using the offsets in address
> calculations.
I don't think it needs to do anything slower. As far as I can tell, the only
change needed is that arithmetic on pointer values held in registers must be
done with 64-bit operations. That just changes the opcodes, but it doesn't
make them any longer.
>
> So to answer your question:
>
> I think your 'compiler bug' is a false predicate. And yes, I do suggest that
> you modify your kernel.
I don't have the option of modifying the kernel, since I'm dealing with data
structures that are at hardwired addresses and moving them isn't an available
option.
I guess I'll go beat on the code generator...
paul
Re: MIPS: Trouble with address calculation near the useg/kseg boundary
On 02/16/2011 02:10 PM, Paul Koning wrote:
On Feb 16, 2011, at 5:08 PM, David Daney wrote:
On 02/16/2011 01:44 PM, Paul Koning wrote:
I'm running into a crash caused by mishandling of address calculation of an
array element address when that array is near the bottom of kseg0
(0x8000).
The code essentially does this
foo = v[i - 2].elem;
where i is current zero.
Assume for now the negative array offset is valid -- data structure elements in question
exist to both sides of the label "v".
The generated code looks like this:
/* i is in v0 */
addiu v0, -2
sll v0, 3
lui v1, 0x8000
adduv0, v1
lbu a1, 7110(v0)
What's going on here is that&v[0].elem is 0xf80007110. The reference
is valid -- array elements are 8 bytes so element -2 is still in kseg0.
However, the addu produces value 07ff0 in v0 -- the result of
adding -16 to the 32 bit value 0x8.
Given that I have an ABI with 64 bit registers -- even though it has 32 bit
pointers -- I would say the address adjustment should have been done with
daddu; if that had been done I would have gotten the correct address.
GCC is 4.5.1, NetBSD target.
This is why it is a bad idea to place anything in the 2^16 byte region centered
on the split.
The Linux kernel works around this by not using the lower 32kb of ckseg0. It
also never user the top 32kb of useg when in 32bit mode.
Ok, so are you suggesting I have to modify my kernel in order to work around
this compiler bug?
What is the state of your C0_Status[{KX,SX,UX}] bits?
It is not really a compiler bug, but rather a defect in the n32 ABI.
When using 32-bit pointers you can only do 32-bit operations on them.
To do otherwise raises the possibility of generating addresses that fall
outside of the allowed range.
But as you have found, there is this 64kb region centered on the split
where behavior can become undefined.
The only real way to avoid it would be to prohibit GCC from generating
non-zero offsets for load/store instructions, the resulting code would
be slower and bigger than the current behavior of using the offsets in
address calculations.
So to answer your question:
I think your 'compiler bug' is a false predicate. And yes, I do suggest
that you modify your kernel.
David Daney.
paul
Re: x32 psABI draft version 0.2
On 2/16/2011 3:46 PM, H.J. Lu wrote: > On Wed, Feb 16, 2011 at 12:39 PM, Andrew Pinski wrote: >> On Wed, Feb 16, 2011 at 12:35 PM, Chris Metcalf wrote: >>> For what it's worth, the Tilera 64-bit architecture (forthcoming) includes >>> support for a 32-bit compatibility layer that is similar to x32. It uses >>> 64-bit registers throughout (e.g. for double and long long), but 32-bit >>> addresses. The addresses between 2GB and 4GB are not directly usable as >>> 64-bit addresses since we sign-extend all 32-bit values to make the ISA >>> more straightforward. We use the "compat" layer to provide our syscall >>> table, since we don't have a traditional compatibility layer in this mode >>> (unlike x86_64 and i386). >> This sounds more like MIPS' n32 than x32 really. >> > Yes, x32 can access the full 4GB address space. There are some > additional optimizations which can be done in x32, but not in x86-64 > small model. Just to be clear, the "-m32" mode in our 64-bit architecture can access the full 4GB address space, but since "-m32" pointers are sign-extended in the high 32 bits, the kernel/userspace boundary has to convert between a sign-extended userspace pointer and a regular zero-extended pointer that the kernel wants to see. -- Chris Metcalf, Tilera Corp. http://www.tilera.com
Re: MIPS: Trouble with address calculation near the useg/kseg boundary
On Feb 16, 2011, at 5:08 PM, David Daney wrote: > On 02/16/2011 01:44 PM, Paul Koning wrote: >> I'm running into a crash caused by mishandling of address calculation of an >> array element address when that array is near the bottom of kseg0 >> (0x8000). >> >> The code essentially does this >> foo = v[i - 2].elem; >> where i is current zero. >> >> Assume for now the negative array offset is valid -- data structure elements >> in question exist to both sides of the label "v". >> >> The generated code looks like this: >> >> /* i is in v0 */ >> addiu v0, -2 >> sll v0, 3 >> lui v1, 0x8000 >> adduv0, v1 >> lbu a1, 7110(v0) >> >> What's going on here is that&v[0].elem is 0xf80007110. The >> reference is valid -- array elements are 8 bytes so element -2 is still in >> kseg0. >> >> However, the addu produces value 07ff0 in v0 -- the result of >> adding -16 to the 32 bit value 0x8. >> >> Given that I have an ABI with 64 bit registers -- even though it has 32 bit >> pointers -- I would say the address adjustment should have been done with >> daddu; if that had been done I would have gotten the correct address. >> >> GCC is 4.5.1, NetBSD target. >> > > This is why it is a bad idea to place anything in the 2^16 byte region > centered on the split. > > The Linux kernel works around this by not using the lower 32kb of ckseg0. It > also never user the top 32kb of useg when in 32bit mode. Ok, so are you suggesting I have to modify my kernel in order to work around this compiler bug? paul
Re: MIPS: Trouble with address calculation near the useg/kseg boundary
On 02/16/2011 01:44 PM, Paul Koning wrote: I'm running into a crash caused by mishandling of address calculation of an array element address when that array is near the bottom of kseg0 (0x8000). The code essentially does this foo = v[i - 2].elem; where i is current zero. Assume for now the negative array offset is valid -- data structure elements in question exist to both sides of the label "v". The generated code looks like this: /* i is in v0 */ addiu v0, -2 sll v0, 3 lui v1, 0x8000 adduv0, v1 lbu a1, 7110(v0) What's going on here is that&v[0].elem is 0xf80007110. The reference is valid -- array elements are 8 bytes so element -2 is still in kseg0. However, the addu produces value 07ff0 in v0 -- the result of adding -16 to the 32 bit value 0x8. Given that I have an ABI with 64 bit registers -- even though it has 32 bit pointers -- I would say the address adjustment should have been done with daddu; if that had been done I would have gotten the correct address. GCC is 4.5.1, NetBSD target. This is why it is a bad idea to place anything in the 2^16 byte region centered on the split. The Linux kernel works around this by not using the lower 32kb of ckseg0. It also never user the top 32kb of useg when in 32bit mode. David Daney.
MIPS: Trouble with address calculation near the useg/kseg boundary
I'm running into a crash caused by mishandling of address calculation of an array element address when that array is near the bottom of kseg0 (0x8000). The code essentially does this foo = v[i - 2].elem; where i is current zero. Assume for now the negative array offset is valid -- data structure elements in question exist to both sides of the label "v". The generated code looks like this: /* i is in v0 */ addiu v0, -2 sll v0, 3 lui v1, 0x8000 adduv0, v1 lbu a1, 7110(v0) What's going on here is that &v[0].elem is 0xf80007110. The reference is valid -- array elements are 8 bytes so element -2 is still in kseg0. However, the addu produces value 07ff0 in v0 -- the result of adding -16 to the 32 bit value 0x8. Given that I have an ABI with 64 bit registers -- even though it has 32 bit pointers -- I would say the address adjustment should have been done with daddu; if that had been done I would have gotten the correct address. GCC is 4.5.1, NetBSD target. paul
Re: x32 psABI draft version 0.2
On Wed, Feb 16, 2011 at 12:39 PM, Andrew Pinski wrote: > On Wed, Feb 16, 2011 at 12:35 PM, Chris Metcalf wrote: >> For what it's worth, the Tilera 64-bit architecture (forthcoming) includes >> support for a 32-bit compatibility layer that is similar to x32. It uses >> 64-bit registers throughout (e.g. for double and long long), but 32-bit >> addresses. The addresses between 2GB and 4GB are not directly usable as >> 64-bit addresses since we sign-extend all 32-bit values to make the ISA >> more straightforward. We use the "compat" layer to provide our syscall >> table, since we don't have a traditional compatibility layer in this mode >> (unlike x86_64 and i386). > > This sounds more like MIPS' n32 than x32 really. > Yes, x32 can access the full 4GB address space. There are some additional optimizations which can be done in x32, but not in x86-64 small model. -- H.J.
Re: x32 psABI draft version 0.2
On Wed, Feb 16, 2011 at 12:35 PM, Chris Metcalf wrote: > For what it's worth, the Tilera 64-bit architecture (forthcoming) includes > support for a 32-bit compatibility layer that is similar to x32. It uses > 64-bit registers throughout (e.g. for double and long long), but 32-bit > addresses. The addresses between 2GB and 4GB are not directly usable as > 64-bit addresses since we sign-extend all 32-bit values to make the ISA > more straightforward. We use the "compat" layer to provide our syscall > table, since we don't have a traditional compatibility layer in this mode > (unlike x86_64 and i386). This sounds more like MIPS' n32 than x32 really. -- Pinski
Re: x32 psABI draft version 0.2
On 2/16/2011 3:04 PM, H. Peter Anvin wrote: > On 02/16/2011 11:22 AM, H.J. Lu wrote: >> Hi, >> >> I updated x32 psABI draft to version 0.2 to change x32 library path >> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian, >> Ubuntu and other derivative distributions. The new x32 psABI is >> available from: >> >> https://sites.google.com/site/x32abi/home > I'm wondering if we should define a section header flag (sh_flags) > and/or an ELF header flag (e_flags) for x32 for the people unhappy about > keying it to the ELF class... For what it's worth, the Tilera 64-bit architecture (forthcoming) includes support for a 32-bit compatibility layer that is similar to x32. It uses 64-bit registers throughout (e.g. for double and long long), but 32-bit addresses. The addresses between 2GB and 4GB are not directly usable as 64-bit addresses since we sign-extend all 32-bit values to make the ISA more straightforward. We use the "compat" layer to provide our syscall table, since we don't have a traditional compatibility layer in this mode (unlike x86_64 and i386). We differentiate the 64-bit and 32-bit binaries just by the Elf class, a proposed by H.J. above. This seems plausible given that it does capture the differences correctly; everything else is the same, just the Elf class. (And we use /lib vs /lib32 on the 64-bit platform to support the 32-bit shared libraries, etc.) -- Chris Metcalf, Tilera Corp. http://www.tilera.com
Re: x32 psABI draft version 0.2
> I'm wondering if we should define a section header flag (sh_flags) > and/or an ELF header flag (e_flags) for x32 for the people unhappy about > keying it to the ELF class... I don't see what's wrong with paying attention to the class. IMHO sh_flags only makes sense if you might ever mix x32 and normal x86_64 code together in one link, in which case indeed neither class alone nor anything else file-global is sufficient. If you don't do that, e_flags seems redundant when it's already unambiguous from the class, but I suppose it doesn't hurt. The only other complaint I imagine is the weirdo case of 32-bit systems that deliver ELFCLASS64 core dump files so they can have a full 4GB of memory as well as the thread state notes, where perhaps you'd want something in the core file's headers (e.g. e_flags) to distinguish x32 from x86_64. But it seems to me the actual core note layouts for x32 ought to just be the x86_64 ones anyway, so it's hard to see really caring. Thanks, Roland
Re: x32 psABI draft version 0.2
On 02/16/2011 11:22 AM, H.J. Lu wrote: > Hi, > > I updated x32 psABI draft to version 0.2 to change x32 library path > from lib32 to libx32 since lib32 is used for ia32 libraries on Debian, > Ubuntu and other derivative distributions. The new x32 psABI is > available from: > > https://sites.google.com/site/x32abi/home > I'm wondering if we should define a section header flag (sh_flags) and/or an ELF header flag (e_flags) for x32 for the people unhappy about keying it to the ELF class... -hpa
x32 psABI draft version 0.2
Hi, I updated x32 psABI draft to version 0.2 to change x32 library path from lib32 to libx32 since lib32 is used for ia32 libraries on Debian, Ubuntu and other derivative distributions. The new x32 psABI is available from: https://sites.google.com/site/x32abi/home -- H.J.
Re: [trans-mem] _ITM_abortTransaction not considered as noreturn function
On 02/15/2011 05:33 PM, Richard Henderson wrote: On 02/15/2011 12:35 AM, Patrick Marlier wrote: When I was looking at this problem of tail call optimization, I have found that _ITM_abortTransaction was not considered as a 'noreturn' function. Do you have any reason not doing this? If not, I propose to add ECF_NORETURN in calls.c:special_function_p(). DEF_TM_BUILTIN (BUILT_IN_TM_ABORT, "_ITM_abortTransaction", BT_FN_INT, ATTR_TM_NORETURN_NOTHROW_LIST) It's already marked noreturn. The big switch in special_function_p is only there to add ECF_TM_OPS, for which we do not have an attribute. Thanks for the explanation. Now I get it. Patrick.
Re: Question about static code analysis features in GCC
On Wed, Feb 16, 2011 at 8:54 AM, sa...@hederstierna.com wrote: > Hi > > Thanks for you answer, I just discovered though that the array-bounds-error > could be catched by "-Warray-bounds" warning. > I guess this analysis is done in Range Value Propagation "tree-vrp.c" > The testcases I tried (+mine example code) did not warn though, is it a bug? the array-bounds warning only works when VRP is enabled which it is only at -O2 by default, usually in simple testcases accesses are optimized away. > testsuite/gcc.dg/Warray-bounds.c > testsuite/gcc.dg/Warray-bounds-2.c > testsuite/gcc.dg/Warray-bounds-3.c > testsuite/gcc.dg/Warray-bounds-4.c FAILED?? > testsuite/gcc.dg/Warray-bounds-5.c > testsuite/gcc.dg/Warray-bounds-6.c > testsuite/gcc.dg/Warray-bounds-7.c FAILED?? > testsuite/gcc.dg/Warray-bounds-8.c > > Couldn't NULL dereferences also be checked in tree-VRP to some extent? Yes, but VRP assumes that once you dereference a pointer it will be not NULL - thus its optimistic analysis does defeat the intent to warn for NULL accesses ;) > And about adding a opt-pass, do you mean about here (in passes.c) > > p = &all_regular_ipa_passes; > +NEXT_PASS (pass_ipa_static_analysis); > NEXT_PASS (pass_ipa_whole_program_visibility); No, I was thinking about Index: passes.c === --- passes.c(revision 170176) +++ passes.c(working copy) @@ -796,6 +796,7 @@ init_optimization_passes (void) *p = NULL; p = &all_regular_ipa_passes; + NEXT_PASS (pass_ipa_static_analysis); NEXT_PASS (pass_ipa_whole_program_visibility); NEXT_PASS (pass_ipa_profile); NEXT_PASS (pass_ipa_cp); at the point you show we are not yet in SSA form. The above will only reliably work at -O0 as otherwise early optimizations will have taken place. > What passes do you think have an additional mode for non-code generation, > value-numbering (tree-nrv? tree-ssa-sccvn, tree-ssa-pre?) or > constant-propagation (tree-cp)? There are none at the moment, but at least the SSA propagators (tree-ssa-ccp.c, tree-ssa-copy.c) and the value-numberer (tree-ssa-sccvn.c/tree-ssa-pre.c) whould be easy to modify. > Could this opt-stages be called earlier in the passes pipeline? I would rather arrange for the workers to be able to be called from the static analysis pass directly instead of trying to make them "passes without code-gen". Richard. > > Thanks and Best Regards > /Fredrik > > From: Richard Guenther [richard.guent...@gmail.com] > Sent: Sunday, February 13, 2011 10:54 > To: sa...@hederstierna.com > Cc: gcc@gcc.gnu.org > Subject: Re: Question about static code analysis features in GCC > > On Sun, Feb 13, 2011 at 2:34 AM, sa...@hederstierna.com > wrote: >> Hi >> >> I would like to have some advice regarding static code analysis and GCC. >> I've just reviewed several tools like Klocwork, Coverity, CodeSonar and >> PolySpace. >> These tools offer alot of features and all tools seems to find different >> types of defects. >> The tool that found most bugs on our code was Coverity, but it is also the >> most expensive tool. >> >> But basically I would most like just to find very "simple" basic errors like >> NULL-dereferences and buffer overruns. >> I attach a small example file with some very obvious errors like >> NULL-dereferences and buffer overruns. >> >> This buggy file compiles fine though without any warnings at all with GCC as >> expected >> >> gcc -o example example.c -W -Wall -Wextra >> >> I tried to add checking with mudflap: >> >> gcc -fmudflap -o example example.c -W -Wall -Wextra -lmudflap >> >> Then I found all defects in run-time, but I had to run the program so I >> could not find all potential errors in compile-time. >> Also Valgrind could be used to check run-time bugs, but I'm not 100% sure I >> can cover all execution paths in my tests (I also tried gcov). >> >> I tried to analyze my example file with CLANG, then I found "uninitialized" >> issues and NULL-pointers, but not buffer overruns: >> >> clang --analyze example.c >> example.c:7:3: warning: Dereference of null pointer loaded from variable >> 'a' >> example.c:41:3: warning: Undefined or garbage value returned to caller >> >> About NULL-checks and buffer-overruns, is there any possible path to get >> such checkers into a standard GCC, maybe in just some very limited level? >> I've checked the "MyGCC" (http://mygcc.free.fr) patch on Graphite, but it >> has been rejected, could it be rewritten somehow as a standard opt_pass to >> just find NULL-derefs? >> >> I've also checked TreeHydra in Mozilla project >> (https://developer.mozilla.org/en/Treehydra) that gives JavaScript interface >> to GIMPEL. >> Is the GCC4.5.x plugin API something that is recommended to use to implement >> such features, is performance okey to not have it as a core opt-pass? >> >> I'm willing to put some free time into this matter if it turns out its >>
Re: Announcing two testsuite maintainers
Gerald Pfeifer writes: > As usual, please adjust the MAINTAINERS file accordingly, and > Happy Hacking^WTesting guys! Done as follows. Thanks. Rainer 2011-02-16 Rainer Orth * MAINTAINERS: Add myself as testsuite maintainer. Index: MAINTAINERS === --- MAINTAINERS (revision 170209) +++ MAINTAINERS (working copy) @@ -237,6 +237,7 @@ auto-vectorizerIra Rosen i...@il.ibm.com loop infrastructureZdenek Dvorak o...@ucw.cz OpenMP Jakub Jelinek ja...@redhat.com +testsuite Rainer Orth r...@cebitec.uni-bielefeld.de testsuite Mike Stump mikest...@comcast.net Note that individuals who maintain parts of the compiler need approval to -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GCC bootstrap mismatch on OS X 10.4
On Mon, Feb 14, 2011 at 7:57 PM, David Fang wrote: > >> >> I suspect his problems will be solved by adding --with-dwarf2 to the >> configure options. We don't seem to have a specific PR for this but I > > This PR seems to match: :) > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248 > One user has reported that --with-dwarf2 was enough to fix bootstrap. Thank you Jack Howarth and David Fang. Adding --with-dwarf2 did indeed fix the bootstrap. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds
RE: Question about static code analysis features in GCC
Hi Thanks for you answer, I just discovered though that the array-bounds-error could be catched by "-Warray-bounds" warning. I guess this analysis is done in Range Value Propagation "tree-vrp.c" The testcases I tried (+mine example code) did not warn though, is it a bug? testsuite/gcc.dg/Warray-bounds.c testsuite/gcc.dg/Warray-bounds-2.c testsuite/gcc.dg/Warray-bounds-3.c testsuite/gcc.dg/Warray-bounds-4.c FAILED?? testsuite/gcc.dg/Warray-bounds-5.c testsuite/gcc.dg/Warray-bounds-6.c testsuite/gcc.dg/Warray-bounds-7.c FAILED?? testsuite/gcc.dg/Warray-bounds-8.c Couldn't NULL dereferences also be checked in tree-VRP to some extent? And about adding a opt-pass, do you mean about here (in passes.c) p = &all_regular_ipa_passes; +NEXT_PASS (pass_ipa_static_analysis); NEXT_PASS (pass_ipa_whole_program_visibility); What passes do you think have an additional mode for non-code generation, value-numbering (tree-nrv? tree-ssa-sccvn, tree-ssa-pre?) or constant-propagation (tree-cp)? Could this opt-stages be called earlier in the passes pipeline? Thanks and Best Regards /Fredrik From: Richard Guenther [richard.guent...@gmail.com] Sent: Sunday, February 13, 2011 10:54 To: sa...@hederstierna.com Cc: gcc@gcc.gnu.org Subject: Re: Question about static code analysis features in GCC On Sun, Feb 13, 2011 at 2:34 AM, sa...@hederstierna.com wrote: > Hi > > I would like to have some advice regarding static code analysis and GCC. > I've just reviewed several tools like Klocwork, Coverity, CodeSonar and > PolySpace. > These tools offer alot of features and all tools seems to find different > types of defects. > The tool that found most bugs on our code was Coverity, but it is also the > most expensive tool. > > But basically I would most like just to find very "simple" basic errors like > NULL-dereferences and buffer overruns. > I attach a small example file with some very obvious errors like > NULL-dereferences and buffer overruns. > > This buggy file compiles fine though without any warnings at all with GCC as > expected > >gcc -o example example.c -W -Wall -Wextra > > I tried to add checking with mudflap: > >gcc -fmudflap -o example example.c -W -Wall -Wextra -lmudflap > > Then I found all defects in run-time, but I had to run the program so I could > not find all potential errors in compile-time. > Also Valgrind could be used to check run-time bugs, but I'm not 100% sure I > can cover all execution paths in my tests (I also tried gcov). > > I tried to analyze my example file with CLANG, then I found "uninitialized" > issues and NULL-pointers, but not buffer overruns: > >clang --analyze example.c >example.c:7:3: warning: Dereference of null pointer loaded from variable > 'a' >example.c:41:3: warning: Undefined or garbage value returned to caller > > About NULL-checks and buffer-overruns, is there any possible path to get such > checkers into a standard GCC, maybe in just some very limited level? > I've checked the "MyGCC" (http://mygcc.free.fr) patch on Graphite, but it has > been rejected, could it be rewritten somehow as a standard opt_pass to just > find NULL-derefs? > > I've also checked TreeHydra in Mozilla project > (https://developer.mozilla.org/en/Treehydra) that gives JavaScript interface > to GIMPEL. > Is the GCC4.5.x plugin API something that is recommended to use to implement > such features, is performance okey to not have it as a core opt-pass? > > I'm willing to put some free time into this matter if it turns out its > possible to add some tree SSA optimization pass that could find some limited > set of errors. > Example given if some value is constant NULL and dereferenced, or some > element if accessed outside a constant length buffer using a constant index. > What is your recommended path to move forward using GCC and basic static code > analysis? It should be possible to fit static code analysis into GCC. The most prominent issue is that GCC is a compiler mainly looking at optimization quality, and optimization can defeat static code analysis in some cases (such as aggressively using undefined behavior to do dead code elimination). On the other hand optimization makes static analysis easier in some cases, and even more useful if issues in "really" dead code are removed. As a way to start I would suggest to restrict static analysis to -O0 (no optimization), a suitable place to do such analysis is the first entry in the IPA pass pipeline (then you have the whole program in SSA, a callgraph built and unused functions removed - you also have always_inline functions inlined). Something that can be done quite easily is have a mode for the standard SSA propagators (like constant propagation or even value-numbering) to only compute the propagation but do no modification to the program, if the results are then kept and not freed static analysis can use them. I don't see a good reason to not include a well-desige
