printf, scanf and
strftime) checking:Remember to keep other developers informed of any substantial projects you intend to work on.
You can investigate bugs in our bug tracking system and attempt to fix them or see whether they still are present in current GCC.
If you are new to GCC, start with our projects for beginners.
There is a separate project list for the C preprocessor.
There is a separate projects list for the web pages.
There is a separate projects list for projects for improving the GCC documentation.
There are several development branches pursuing various goals.
We also have a page detailing optimizer inadequacies, if you'd prefer to think about it in terms of problems instead of features.
The new version of the C standard (ISO/IEC 9899:1999) requires a number of library changes; these have to be provided by the C library, and not by gcc. In addition, there are also changes to the language proper, and some compiler support is needed for the new library features. An overview of the C99 implementation status is available.
The following are some miscellaneous ideas for GCC projects to work on.
-WconversionImprove -Wconversion so that it can be used for
security auditing as well as for its original intended purpose of
helping with converting old code to ISO C.
<tgmath.h>Design and implement builtin functions that assist in implementing
the ISO C99 <tgmath.h> macros. These builtins
could be along the general lines of the macros used in glibc 2.2 (for
example, the implementation of <tgmath.h> might use
__builtin_tgmath_unary_real_only (value, log2f, log2,
log2l) to implement the log2 macro), but should be
designed so that, if the Annex G imaginary types are implemented in
GCC, glibc does not need to change again to allow for them. This
means additional functions, beyond those corresponding to the macros
in glibc, are needed to handle the trigonometric functions which G.7
specifies have real or imaginary result type for imaginary arguments,
but which have complex result type for complex arguments. The design
for these builtins should be discussed with the gcc and libc-alpha
lists.
printf,
scanf and strftime) checking:$
format checking.strftime: warnings for use of 0,
- or _ flags without width on formats where
inappropriate. Similar warnings where use of one format feature is
useless unless another one is also used also apply for
printf formats (0 and - flags
when no width is specified and so there is no padding) and for
strfmon formats.printf formats: warn for integer constant
argument out of range of unpromoted type (including signed/unsigned
where it doesn't fit in range).wchar_t is char. This may
require changes elsewhere in the compiler to mark string constants
with this information.%q: anything more accurate than
long long? See messages 1 and
2
about this to gcc-bugs. (Note that %q is now largely
obsolete given the new C99 formats and macros.)gcc mailing list.format.exp handles
TORTURE_OPTIONS, by making changes elsewhere in the test
harness so that TORTURE_OPTIONS is initialized for each
dg-init rather than just once and so needing saving and
restoring.format or format_arg attribute is
applied to a function with a non-prototype declaration, and the
function is later redeclared with a prototype or defined, the
attribute should be checked again to see if it makes sense given the
argument types of the function. Similarly, these checks should be
made if the original attribute is on an old-style function
definition.__attribute__((__nonnull__)),
such as for functions such as execle that require
NULL-terminated argument lists.-Wformat-security:
sprintf into fixed length buffer if the
output can't be proved not to overrun. Similarly for
scanf %s and %[...] without
width to fixed length buffer (or possibly to any buffer); or
%s, %[...] and %c with width
to too short a buffer, including %lc, %ls
and %l[...].fopen, freopen: warning for the
incorrect format of the mode parameter, see PR
c/5127. Some ideas for how to implement such a warning
were discussed here.
$(libsubdir) be owned by root rather than the user who
did the build.i686-pc-linux-gnu-gcc and
i686-pc-linux-gnu-gcc-3.4.1. Any program embedding
architecture or version dependencies may need such links.--enable-cc-links or similar
which causes links to the compiler driver or shell scripts to be
installed under names cc (the traditional Unix compiler
name and a legacy utility in Unix98, accepting an unspecified C
language variant), c89 (POSIX; a script running gcc
-std=c89 -pedantic) and c99 (the Austin Group
revision of POSIX; a script running gcc -std=c99
-pedantic) for systems such as GNU/Linux where GCC is the
system compiler.Right now, describing the target machine's instructions is done cleanly, but describing its addressing mode is done with several ad-hoc macro definitions. Porting would be much easier if there were an RTL description for addressing modes like that for instructions. Tools analogous to genflags and genrecog would generate macros from this description.
There would be one pattern in the address-description file for each kind of addressing, and this pattern would have:
We currently have front ends for Ada, C, C++, Objective C, Fortran, and Java. A Pascal front end exists but has not yet been integrated.
Cobol and Modula-2 front ends might be useful, and are being worked on.
Some new compiler features may be needed to do a good job on machines where static data needs to be addressed using base registers.
Some machines have two stacks in different areas of memory, one used for scalars and another for large objects. The compiler does not now have a way to understand this.
The scheduler does not do very well on recent RISC machines. Haifa helps but not enough.
Warn about statements that are undefined because the order of evaluation of increment operators makes a big difference. Here is an example:
*foo++ = hack (*foo);
-Wsequence-point does some of this, but not that
particular case.
The following used to be in a file PROBLEMS in the GCC
distribution. Probably much of it is no longer relevant as of GCC 3.0
(the file hadn't changed since GCC 2.0), but some might be. Someone
should go through it, identifying what is and isn't relevant, adding
anything applicable to current GCC (and describing a bug) to our
bug-tracking system and sending patches to
gcc-patches to remove such analysed entries from the list.
Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.
These pages are maintained by the GCC team.
For questions related to the use of GCC, please consult these web pages and the GCC manuals. If that fails, the gcc-help@gcc.gnu.org mailing list might help.Copyright (C) Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
| Last modified 2005-01-31 |
|