public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Thompson <susurrus.of.qualia@gmail.com>
To: gcc-help@gcc.gnu.org
Subject: Fwd: Multiple symbols defined in object files that should not be there.
Date: Fri, 7 Apr 2023 12:38:21 -0700	[thread overview]
Message-ID: <CAA0MYJVSPNm7FPxRg0C6KcyfTPDXMKx3YGy6voxvTuGDKazbYA@mail.gmail.com> (raw)
In-Reply-To: <CAH6eHdQLHvbjDyRCn-o7cAWLfsfZnuShc9erFonqfDU3nsznqA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

---------- Forwarded message ---------
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Fri, Apr 7, 2023 at 1:54 AM
Subject: Re: Multiple symbols defined in object files that should not be
there.
To: Steve Thompson <susurrus.of.qualia@gmail.com>


Please reply to the list, not just to me.

The preprocessor is dumb, it doesn't do anything complicated. If platform.h
doesn't include microsecond_time.h there must be an include guard stopping
it.

If #undef MICROSECOND_TIME_H doesn't change anything, maybe that's not the
name of the include guard.

None of those is a gcc problem, it's just your code not working how you
want it to.

--------------------------------------------------

Your suggestion to use "-E and -dD" was what I needed to find the
embarassing mistake that caused it all.  FTR I had guard clauses in the
microsecond_time.c file as well as the .h file for some odd reason.  Not a
recent change it seems and my brain was fooled and mostly eliminated those
clauses from my perception, possibly because they are present about half
the time I'm editing any given file and are more-or-less invisible.

I still have the problem that the compiler is generating code in some
object modules for an inline function that is not referenced in the
individual .c files.  Only 7 of 15 source files.  Some of the affected
source files are trivial while others are reasonably complex.

I defined the offending function as "static inline" and tried adding
-fno-keep-inline-functions, but there was no change.  Fooling aroung with
related options had no effect.

From my understanding, GCC simply shouldn't be marking an inline function
for inclusion in an object file unless it is referenced in the source file
it is compiling.  There simply no instances where apool_init_freelist() is
written in any of the .c files; it is only defined in the one .h file.  So
what on Earth is going on?

For the moment I'm going to hope that space aliens beam inspiration
directly into my brain before it melts completely.

      parent reply	other threads:[~2023-04-07 19:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06  4:03 Steve Thompson
2023-04-06  9:08 ` Jonathan Wakely
     [not found]   ` <CAA0MYJXVX7wue=03DJan21M-wwhkZUuaCQ2BqKmRkyj+yO5f9Q@mail.gmail.com>
     [not found]     ` <CAH6eHdQLHvbjDyRCn-o7cAWLfsfZnuShc9erFonqfDU3nsznqA@mail.gmail.com>
2023-04-07 19:38       ` Steve Thompson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA0MYJVSPNm7FPxRg0C6KcyfTPDXMKx3YGy6voxvTuGDKazbYA@mail.gmail.com \
    --to=susurrus.of.qualia@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).