This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch to projects lists


On Sun, 4 Jul 2004, Gerald Pfeifer wrote:

> > (If you think one of the items I'm removing these comments from is
> > obsolete in its entirety, or otherwise needs updating, please submit
> > a followup patch to update or remove it as necessary.)
> 
> It would be good if some of our developers could check the list; I'm
> quite sure several entries are not really appropriate any longer.

OK to commit the following second followup patch which updates and removes
more entries?  (In the case of the removed optimization project, I checked
the tree-ssa dumps to see that we do now optimize this.)

The entries from the old PROBLEMS file really need someone who was
involved at the time of GCC 2.0 to work out what is relevant and what it
means.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Index: beginner.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/beginner.html,v
retrieving revision 1.48
diff -u -r1.48 beginner.html
--- beginner.html	4 Jul 2004 14:27:14 -0000	1.48
+++ beginner.html	4 Jul 2004 17:02:45 -0000
@@ -120,10 +120,7 @@
 unsigned" in a GCC build, but unless you really know what you're
 doing, you should leave them alone.</p>
 
-<p>Also, some warnings are spurious: for example, the floods
-of "ISO C requires rest arguments to be used" complaints on some
-platforms are technically correct but useless, because the offending
-macro is <code>printf</code>.  If you can patch the part of the
+<p>Also, some warnings are spurious.  If you can patch the part of the
 compiler that issues spurious warnings, so it doesn't anymore (but
 still does generate the warning where it's appropriate), we're happy
 to take those patches too.</p>
@@ -933,16 +930,14 @@
 
 <li>Install all Texinfo manuals.
 
-<p>Such as <code>libstdc++-v3/porting.texi</code>.  You will have
-to adapt the configure checks for available makeinfo to use outside the gcc
-subdirectory.</p></li>
+<p>Such as <code>libstdc++-v3/docs/html/17_intro/porting.texi</code>.</p></li>
 
 <li>Improve support for building other manual formats.
 
 <p>For example, arrange for <code>make dvi</code> at top level to
 build DVI versions of all manuals.  Add a <code>make html</code>
-target to build HTML versions of manuals (using either
-<code>texi2html</code> or <code>makeinfo --html</code>).  Consider
+target to build HTML versions of manuals (using
+<code>makeinfo --html</code>).  Consider
 adding targets to build PostScript and PDF versions of manuals
 (<code>texinfo.tex</code> includes some support for PDF
 output).</p></li>
@@ -967,7 +962,7 @@
 
 <ul>
 
-<li>Implement <samp>-std</samp> for the Fortran and Java front ends?</li>
+<li>Implement <samp>-std</samp> for the Java front end?</li>
 
 <li>Fix the places where <samp>-std=c89</samp> is not the same thing
 as <samp>-ansi</samp>.</li>
@@ -1125,14 +1120,10 @@
 <code>special_function_p</code> checks for a function not defined by
 ISO C, the attribute ought to be added by fixincludes rather than
 presuming anything about its semantics within the compiler.  All this
-special handing should be disabled by <samp>-ffreestanding</samp>.</p>
-
-<p>There is now a unified way of attaching attributes to functions
-with known semantics when they are declared (explicitly or
-implicitly); see <code>builtin-attrs.def</code>.
-This should be used for "builtins" such as exit and
-abort that only exist for this purpose as well as for functions such
-as <code>malloc</code> handled by <code>special_function_p</code>.</p></li>
+special handing should be disabled by <samp>-ffreestanding</samp>.
+Where the function is defined by ISO C (and possibly where it has a
+name reserved by ISO C), it should be declared as a built-in function
+with the attribute in <code>builtins.def</code>.</p>
 
 <li>Find warnings that only the C front end does that would make sense
 with C++ and have the C++ front end support them as well, sharing code
Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/index.html,v
retrieving revision 1.44
diff -u -r1.44 index.html
--- index.html	4 Jul 2004 14:27:14 -0000	1.44
+++ index.html	4 Jul 2004 17:02:45 -0000
@@ -46,8 +46,6 @@
 <li><a href="#the_old_projects_file">The old PROJECTS file</a>
 <ul>
 <li><a href="#putting_constants_in_special_sections">Putting constants in special sections.</a></li>
-<li><a href="#optimize_a_sequence_of_if_statements_whose_conditions_are">Optimize a sequence of if statements whose conditions are
-exclusive.</a></li>
 <li><a href="#un_cse">Un-cse.</a></li>
 <li><a href="#clean_up_how_cse_works">Clean up how cse works.</a></li>
 <li><a href="#support_more_general_tail_recursion_among_different_functions">Support more general tail-recursion among different functions.</a></li>
@@ -67,7 +65,6 @@
 </ul></li>
 <li><a href="#simpler_porting">Simpler porting</a></li>
 <li><a href="#other_languages">Other languages</a></li>
-<li><a href="#more_extensions">More extensions</a></li>
 <li><a href="#generalize_the_machine_model">Generalize the machine model</a></li>
 <li><a href="#more_warnings">More warnings</a></li>
 <li><a href="#better_documentation_of_how_gcc_works_and_how_to_port_it">Better documentation of how GCC works and how to port it</a></li>
@@ -402,13 +399,10 @@
 <code>$(libsubdir)</code> be owned by root rather than the user who
 did the build.</li>
 
-<li>Install driver programs under names such as <code>gcc-3.0</code>,
-to discourage the use of <code>-V</code> by making it easier to keep
-old driver programs around.  Also, be consistent about what programs
-get links such as <code>i686-pc-linux-gnu-gcc</code>.  Possibly
-<code>gccbug</code> needs this treatment as well as driver programs,
-since it embeds architecture and version information.  (Maybe, after
-this is done <code>-V</code> could be deprecated.)</li>
+<li>Be consistent about what programs get links such as
+<code>i686-pc-linux-gnu-gcc</code> and
+<code>i686-pc-linux-gnu-gcc-3.4.1</code>.  Any program embedding
+architecture or version dependencies may need such links.</li>
 
 <li>Add a configure option <code>--enable-cc-links</code> or similar
 which causes links to the compiler driver or shell scripts to be
@@ -444,28 +438,6 @@
 specify a section for string constants would be useful for the Linux
 kernel.)</p>
 
-<h3><a name="optimize_a_sequence_of_if_statements_whose_conditions_are">Optimize a sequence of if statements whose conditions are
-exclusive.</a></h3>
-
-<p>It is possible to optimize</p>
-
-<pre>
-if (x == 1) ...;
-if (x == 2) ...;
-if (x == 3) ...;
-</pre>
-into
-<pre>
-if (x == 1) ...;
-else if (x == 2) ...;
-else if (x == 3) ...;
-</pre>
-<p>provided that x is not altered by the contents of the if statements.</p>
-
-<p>It's not certain whether this is worth doing.  Perhaps programmers
-nearly always write the else's themselves, leaving few opportunities
-to improve anything.</p>
-
 <h3><a name="un_cse">Un-cse.</a></h3>
 
 <p>Perhaps we should have an un-cse step right after cse, which tries to


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]