public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/44308] New: ranlib: file: libbackend
@ 2010-05-28 11:10 jay dot krell at cornell dot edu
2010-05-28 13:06 ` [Bug middle-end/44308] " steven at gcc dot gnu dot org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: jay dot krell at cornell dot edu @ 2010-05-28 11:10 UTC (permalink / raw)
To: gcc-bugs
There are a number of these unsightly warnings (not errors) building gcc on
MacOSX:
ranlib: file: libbackend.a(insn-peep.o) has no symbols
ranlib: file: libbackend.a(graphite-blocking.o) has no symbols
ranlib: file: libbackend.a(graphite-clast-to-gimple.o) has no symbols
ranlib: file: libbackend.a(graphite-dependences.o) has no symbols
ranlib: file: libbackend.a(graphite-interchange.o) has no symbols
ranlib: file: libbackend.a(graphite-poly.o) has no symbols
ranlib: file: libbackend.a(graphite-ppl.o) has no symbols
ranlib: file: libbackend.a(graphite-scop-detection.o) has no symbols
ranlib: file: libbackend.a(graphite-sese-to-poly.o) has no symbols
ranlib: file: libbackend.a(loop-doloop.o) has no symbols
ranlib: file: libbackend.a(vmsdbgout.o) has no symbols
ranlib: file: libbackend.a(xcoffout.o) has no symbols
What I've done is at the end of each of them is put:
char quash_apple_ranlib_warning_foo;
Where "foo" is chosen from the file's non-static symbols.
I didn't see insn-peep.c, it is presumably generated, so I didn't fix it.
--
Summary: ranlib: file: libbackend
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
GCC build triplet: ranlib: file: libbackend.a(xcoffout.o) has no symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug middle-end/44308] ranlib: file: libbackend
2010-05-28 11:10 [Bug c/44308] New: ranlib: file: libbackend jay dot krell at cornell dot edu
@ 2010-05-28 13:06 ` steven at gcc dot gnu dot org
2010-05-30 8:07 ` jay dot krell at cornell dot edu
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: steven at gcc dot gnu dot org @ 2010-05-28 13:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from steven at gcc dot gnu dot org 2010-05-28 13:06 -------
This is OK, those files have only content for certain configurations (with
CLOOG, doloop pattern in the backend, etc.). You should look for a way to
suppress the warning without adding new symbols at random.
--
steven at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug middle-end/44308] ranlib: file: libbackend
2010-05-28 11:10 [Bug c/44308] New: ranlib: file: libbackend jay dot krell at cornell dot edu
2010-05-28 13:06 ` [Bug middle-end/44308] " steven at gcc dot gnu dot org
@ 2010-05-30 8:07 ` jay dot krell at cornell dot edu
2010-05-30 8:56 ` jay dot krell at cornell dot edu
2010-05-31 12:15 ` jay dot krell at cornell dot edu
3 siblings, 0 replies; 5+ messages in thread
From: jay dot krell at cornell dot edu @ 2010-05-30 8:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from jay dot krell at cornell dot edu 2010-05-30 08:06 -------
I understand it is "ok".
Question is: Do you want to be warning free?
At what cost?
I think you do, at some finite cost, and I think the change is worthwhile here.
This isn't adding symbols at random, it is adding them in a small safe way that
fixes the warnings, leading more configurations, common ones, to be
warning-free.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug middle-end/44308] ranlib: file: libbackend
2010-05-28 11:10 [Bug c/44308] New: ranlib: file: libbackend jay dot krell at cornell dot edu
2010-05-28 13:06 ` [Bug middle-end/44308] " steven at gcc dot gnu dot org
2010-05-30 8:07 ` jay dot krell at cornell dot edu
@ 2010-05-30 8:56 ` jay dot krell at cornell dot edu
2010-05-31 12:15 ` jay dot krell at cornell dot edu
3 siblings, 0 replies; 5+ messages in thread
From: jay dot krell at cornell dot edu @ 2010-05-30 8:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from jay dot krell at cornell dot edu 2010-05-30 08:55 -------
Hm. There are more. Perhaps better to not compile/lib/link files that can be
easily predicted to have no symbols? Maybe just ignore it. Maybe get Apple to
change ranlib. Maybe they already have.
ranlib: file: ../.././gcc/libgcc.a(_trampoline.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_ctors.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_powitf2.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_multc3.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_divtc3.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_fixtfdi.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_fixunstfdi.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_floatditf.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_floatunditf.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_fixsfti.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_fixdfti.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_fixxfti.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_fixtfti.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_fixunssfti.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_fixunsdfti.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_fixunsxfti.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_fixunstfti.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_floattisf.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_floattidf.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_floattixf.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_floattitf.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_floatuntisf.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_floatuntidf.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_floatuntixf.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(_floatuntitf.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(darwin-64.o) has no symbols
ranlib: file: ../.././gcc/libgcc.a(unwind-sjlj.o) has no symbols
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug middle-end/44308] ranlib: file: libbackend
2010-05-28 11:10 [Bug c/44308] New: ranlib: file: libbackend jay dot krell at cornell dot edu
` (2 preceding siblings ...)
2010-05-30 8:56 ` jay dot krell at cornell dot edu
@ 2010-05-31 12:15 ` jay dot krell at cornell dot edu
3 siblings, 0 replies; 5+ messages in thread
From: jay dot krell at cornell dot edu @ 2010-05-31 12:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from jay dot krell at cornell dot edu 2010-05-31 12:14 -------
Here is the fix for insn-peep.o (against 4.3, granted):
diff -u -r1.5 genpeep.c
--- gcc/gcc/genpeep.c 14 Apr 2008 12:48:21 -0000 1.5
+++ gcc/gcc/genpeep.c 31 May 2010 12:14:37 -0000
@@ -424,6 +424,7 @@
printf ("rtx peep_operand[%d];\n", max_opno + 1);
printf ("#endif\n");
+ printf ("\nchar quash_apple_randlib_warning_peephole;\n");
fflush (stdout);
return (ferror (stdout) != 0 ? FATAL_EXIT_CODE : SUCCESS_EXIT_CODE);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-05-31 12:15 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-05-28 11:10 [Bug c/44308] New: ranlib: file: libbackend jay dot krell at cornell dot edu
2010-05-28 13:06 ` [Bug middle-end/44308] " steven at gcc dot gnu dot org
2010-05-30 8:07 ` jay dot krell at cornell dot edu
2010-05-30 8:56 ` jay dot krell at cornell dot edu
2010-05-31 12:15 ` jay dot krell at cornell dot edu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).