John Levon

levon@movementarian.org

2003 John Levon This document can be freely translated and distributed. It's released under the LDP License. GCC tree compiler I made a rather lame and simple patch to GCC 3.4 CVS to detect always-false expressions, as in if (!ua & 0x4). Whilst the change was relatively simple, even for some-one as clueless as I am, I found a couple of things quite awkward and not well-documented. So, I wrote this brief note. This is obviously the first step. You want to build current CVS and install it so you have a baseline to work against when something goes wrong. Follow the instructions for getting the CVS and build it as described. In my case, I did : cvs co -r gcc-3_3-branch -d gcc-3.3 gcc mkdir gcc/obj && cd gcc/obj ../configure --prefix=/usr/local/gcc-3.3cvs make bootstrap make install cd ../ && rm -rf obj && mkdir obj && cd obj ../configure --prefix=/usr/local/gcc-3.3mine Note that I was working on the 3.3 branch, because at the time of writing 3.4 is unusable. Now I have a GCC installed in /usr/local/gcc-3.3cvs I haven't touched, and I'm free to start hacking. This was a stupid way of doing it: note the comment about make restrap below. OK, so here I was, with no idea on where to start looking. So I just nosied around. gcc contains most of the "interesting" code for what I needed. gcc/cp is the C++ frontend, which shares quite a lot of code with the C frontend which is directly in gcc. First thing to remember is when making a change, you should build with make restrap. That way you won't have to bootstrap all over again. Remember the case I wanted to fix was if (!ua & 0x4) not giving a warning. This expands to always-false, and the author undoubtedly meant if (!(ua & 0x4)). So, I guessed that the code related to binary operations might be relevant. I chose a warning about binary operations (namely, "comparison between pointer and integer") and grepped for it. I found it inside the function build_binary_op() inside c-typeck.c. This referred to two "codes". A bit of grepping and reading code showed me that I needed to deal with the "tree" concept as described (all too briefly) in the GCC internals manual. A tree describes (part of) an expression, types, or values. Examples are the literal constant 0, COND_EXPR (a ? b : c), and the integer type. The header file tree.h contains a lot of tree-related functions and definitions, and there's some useful comments there too. You can get the code of a tree with the helper TREE_CODE(tree). This returns an enum with one of a set of codes. Expressions have codes like LT_EXPR for a binary <= expression. I soon found out that constants are represented similarly, with codes like INTEGER_CST. Every tree (or sub-tree) also has a type, as distinct from its code. You can get the type of a tree using TREE_CODE(TREE_TYPE(tree)). For example, a LT_EXPR tree will have a type of BOOLEAN_TYPE. There are undoubtedly many caveats to understanding how trees work, and I've only looked at a tiny subset. But here's one - NOP_EXPR. I was encountering this expression in the C++ frontend in the code bool b; if (!b & 0x4) ... The tree looked a bit like <bit_and_expr<nop_expr<truth_not_expr<var_decl(bool)>> & <integer_cst(0x4)>>>. What's going on here is that the "!b" is getting wrapped inside a NOP_EXPR, which essentially means "no conversion code is needed" (because a boolean value can become an integer one, as required by the bit-wise and, without anything special needing doing). As it turned out, this case needed special casing in my eventual patch. The "tree" type is just a pointer, and every tree is garbage-collected. Some helpers like STRIP_NOPS (which looks below any NOP_EXPRs in the given tree) merely alter the pointer to a lower level in the tree structure. The actual tree is a simple "C object orientation" struct, where each sub-class has a common prefix of values, and its class is defined by the tree code. I was finding all this out in a very laborious manner until a developer on IRC pointed me to debug_tree(), an extremely handy function that prints out a text representation of a tree. You can use this with breakpoints in GDB to see exactly what is happening simply by calling call debug_tree(op1) or whatever (remember, the "gcc" executable is just a frontend, you can invoke the actual compilers in GDB directly: they are called cc1 and cc1plus, and reside inside prefix/lib/gcc-lib/platform/version/). I found the helper integer_onep (note the LISPy heritage ...) which tells me if a tree evaluates to constant 1. Along with truth_value_p(), and the check for NOP_EXPR as mentioned, my patch was good to go ! Now, I'd done the work, and even found a bug with it (inside the Linux kernel's pnpbios code). I may as well submit it and see if it's good enough to go in. There are two main requirements here: testsuite entries, and documentation. Documentation was easy - edit the gcc/.texi files to mention the new warning. The testsuite changes were slightly less obvious, but the changes basically amounted to adding Wboolean-bitwise-and-{1,2}.c in gcc/testsuite/gcc.dg, and boolean-bitwise-and-{1,2}.c in gcc/testsuite/g++.dg. As these were testing a warning, I made the header say dg-options "-Wboolean-bitwise-and ", and for each line that would cause a warning, added /* { dg-warning "bitwise and expression is always false" } */. Two of these test files were PASS, which means that the testsuite would error out if they failed for some reason (internal compiler error (ICE), extra warnings, etc.). However, my code doesn't handle if (!(a ? b : c) & 0x4), so on a suggestion from a developer, I added this case as XFAIL testcases (which means: should pass, but we know it currently won't, so don't whine). You run the testsuite with make -k check in the obj/ directory. This creates .log and .sum files, which you can look at to see what happened in case your changes break a testcase. Note that you need to use the -k option, as otherwise the test run stops at the first test that fails unexpectedly (which seems to be often the case with GCC CVS). The testsuite can take forever, so I did make -k check RUNTESTFLAGS=dg.exp instead a couple of times, which only runs a subset of the tests. So now it's tested and documented, the only thing left to do is to make a diff and send it to gcc-patches@gcc.gnu.org, with a suitable changelog in the mail. You'll also need a copyright assignment from assign@gnu.org of the correct sort, of course.