This is the mail archive of the gcc@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]

Re: Warning policy?


 > From: Joe Buck <jbuck@Synopsys.COM>
 > 
 >  "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > > |> 	The "label `???' defined but not used" warnings mostly appear
 > > |> in insn-recog.c.  In this case genrecog.c needs to be fixed.  It may be
 > > |> non-trivial to deduce which labels are unnecessary, I haven't looked. 
 > > |> Another approach might be to get the compiler to allow attribute
 > > |> __unused__ on a label and just mark all of them unused in the generated
 > > |> insn-recog.c file.
 > 
 > Andreas Schwab writes: 
 > > Well, the brute force method would be to just emit a `goto L' before
 > > each label L.
 > 
 > That would only create more warnings, as some of these gotos would be
 > unreachable code, which produces a warning.


	Good point, but I'm not seeing this in actual practice from gcc. 
I wrote a small patch to attempt what Andreas suggested and gcc does not
complain about unreachable code.  Various stage1-cc's might complain,
e.g. SunOS4 cc does in fact, but we could arrange to only output the
goto when __GNUC__ is defined. 




 > The purpose in removing the warnings is to improve the code quality.
 > A -Wall-clean compile is nice, but if all the warnings are gone except
 > for warnings about unused labels in a generated file that would be enough,
 > in my opinion, for Kaveh to declare victory in his war on the warnings.
 > The idea is that we can say there should be no warnings except certain
 > specific warnings in specific files (like this one).



	I agree in principle, but ... consider the following patch.
It eliminates the 60-80 `unused label' warnings without adding any.
IMHO its relatively clean and painless, and it addresses the concern
you raised above.

		--Kaveh


--- egcs-CVS19981230/gcc/genrecog.c~	Wed Dec 30 09:58:54 1998
+++ egcs-CVS19981230/gcc/genrecog.c	Wed Dec 30 14:28:38 1998
@@ -51,6 +51,17 @@ Boston, MA 02111-1307, USA.  */
 #include "rtl.h"
 #include "obstack.h"
 
+/* We output a `goto' right before the actual label to ensure we don't
+   get `unused label' warnings.  Only do it if we are gcc since other
+   compilers might warn about `unreachable code'. */
+#ifdef __GNUC__
+#define OUTPUT_LABEL(INDENT_STRING, LABEL_NUMBER) \
+  printf("%sgoto L%d; L%d:\n", (INDENT_STRING), (LABEL_NUMBER), (LABEL_NUMBER))
+#else
+#define OUTPUT_LABEL(INDENT_STRING, LABEL_NUMBER) \
+  printf("%sL%d:\n", (INDENT_STRING), (LABEL_NUMBER))
+#endif /* __GNUC__ */
+
 static struct obstack obstack;
 struct obstack *rtl_obstack = &obstack;
 
@@ -1103,7 +1114,7 @@ write_tree_1 (tree, prevpos, afterward, 
   printf ("\n");
   if (tree && tree->subroutine_number == 0)
     {
-      printf ("  L%d:\n", tree->number);
+      OUTPUT_LABEL ("  ", tree->number);
       tree->label_needed = 0;
     }
 
@@ -1239,7 +1250,7 @@ write_tree_1 (tree, prevpos, afterward, 
 
       if (p->label_needed && (p->retest_mode || p->retest_code))
 	{
-	  printf ("%sL%d:\n", indents[indent - 2], p->number);
+	  OUTPUT_LABEL (indents[indent - 2], p->number);
 	  p->label_needed = 0;
 	}
 
@@ -1330,7 +1341,7 @@ write_tree_1 (tree, prevpos, afterward, 
       /* Now that most mode and code tests have been done, we can write out
 	 a label for an inner node, if we haven't already.  */
       if (p->label_needed)
-	printf ("%sL%d:\n", indents[indent - 2], p->number);
+	OUTPUT_LABEL (indents[indent - 2], p->number);
 
       inner_indent = indent;
 
@@ -1563,7 +1574,7 @@ write_tree (tree, prevpos, afterward, in
 
   if (! initial && tree->subroutine_number > 0)
     {
-      printf (" L%d:\n", tree->number);
+      OUTPUT_LABEL (" ", tree->number);
 
       if (afterward)
 	{

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.


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