Bug 150150 - -Os causes static function to be omitted despite alias emitted referencing it
Summary: -Os causes static function to be omitted despite alias emitted referencing it
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
: 149758 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-03-02 22:35 UTC by Jeremy Katz
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Fixed In Version: 4.0.0-0.31
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-13 11:07:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
orinoco.c (147.92 KB, text/plain)
2005-03-03 13:13 UTC, Brian Millett
no flags Details
trivial test case for gcc bug (173 bytes, text/x-csrc)
2005-03-04 00:49 UTC, Roland McGrath
no flags Details

Description Jeremy Katz 2005-03-02 22:35:32 UTC
snd_ac97_codec: Unknown symbol alsa_ac97_exit
snd_ac97_codec: Unknown symbol alsa_ac97_init
snd_ac97_codec: Unknown symbol alsa_ac97_exit
snd_ac97_codec: Unknown symbol alsa_ac97_init
snd_intel8x0: Unknown symbol snd_ac97_pcm_close
snd_intel8x0: Unknown symbol snd_ac97_resume
snd_intel8x0: Unknown symbol snd_ac97_pcm_open
snd_intel8x0: Unknown symbol snd_ac97_set_rate
snd_intel8x0: Unknown symbol snd_ac97_update_bits
snd_intel8x0: Unknown symbol snd_ac97_mixer
snd_intel8x0: Unknown symbol snd_ac97_bus
snd_intel8x0: Unknown symbol snd_ac97_pcm_double_rate_rules
snd_intel8x0: Unknown symbol snd_ac97_suspend
snd_intel8x0: Unknown symbol snd_ac97_get_short_name
snd_intel8x0: Unknown symbol snd_ac97_pcm_assign
snd_intel8x0: Unknown symbol snd_ac97_tune_hardware
snd_ac97_codec: Unknown symbol alsa_ac97_exit
snd_ac97_codec: Unknown symbol alsa_ac97_init
snd_ac97_codec: Unknown symbol alsa_ac97_exit
snd_ac97_codec: Unknown symbol alsa_ac97_init
snd_intel8x0: Unknown symbol snd_ac97_pcm_close
snd_intel8x0: Unknown symbol snd_ac97_resume
snd_intel8x0: Unknown symbol snd_ac97_pcm_open
snd_intel8x0: Unknown symbol snd_ac97_set_rate
snd_intel8x0: Unknown symbol snd_ac97_update_bits
snd_intel8x0: Unknown symbol snd_ac97_mixer
snd_intel8x0: Unknown symbol snd_ac97_bus
snd_intel8x0: Unknown symbol snd_ac97_pcm_double_rate_rules
snd_intel8x0: Unknown symbol snd_ac97_suspend
snd_intel8x0: Unknown symbol snd_ac97_get_short_name
snd_intel8x0: Unknown symbol snd_ac97_pcm_assign
snd_intel8x0: Unknown symbol snd_ac97_tune_hardware
snd_ac97_codec: Unknown symbol alsa_ac97_exit
snd_ac97_codec: Unknown symbol alsa_ac97_init
snd_intel8x0m: Unknown symbol snd_ac97_resume
snd_intel8x0m: Unknown symbol snd_ac97_update_bits
snd_intel8x0m: Unknown symbol snd_ac97_mixer
snd_intel8x0m: Unknown symbol snd_ac97_bus
snd_intel8x0m: Unknown symbol snd_ac97_suspend
snd_intel8x0m: Unknown symbol snd_ac97_write

Somehow, I'm thinking this is a gcc 3.4-ism....

Comment 1 Bill Nottingham 2005-03-02 22:39:46 UTC
Surely, you mean a gcc 4-ism.

Comment 2 Michal Jaegermann 2005-03-02 23:58:19 UTC
For i686 kernel, up or smp,

depmod -ae -F /boot/System.map-2.6.10-1.1162_FC4 2.6.10-1.1162_FC4

brings for each kernel 73 "WARNING: ... unknown symbol ..."; but
on x86_64 only that one:

WARNING: /lib/modules/2.6.10-1.1162_FC4/kernel/drivers/char/rocket.ko
needs unknown symbol rp_cleanup_module


Comment 3 Dave Jones 2005-03-03 00:11:37 UTC
*** Bug 149758 has been marked as a duplicate of this bug. ***

Comment 4 Dave Jones 2005-03-03 00:14:07 UTC
jakub, I'm wondering if this is gcc4 optimising away these functions because it
thinks they are unused. Can you take a look plesae ?


Comment 5 Bojan Smojver 2005-03-03 00:50:10 UTC
BTW, the latest set of updates fails to bring up the default route, which is
configured in /etc/sysconfig/networks. Not sure if it may be related to this...

Comment 6 Brian Millett 2005-03-03 05:48:55 UTC
trying to compile the orinoco drivers, I can confirm the optimization
problem.
In orinoco.c, I get this error:
  Building modules, stage 2.
  MODPOST
*** Warning: "exit_orinoco" [/home/bpm/src/orinoco/orinoco.ko] undefined!

The function is defined as:

static void __exit exit_hermes(void)
{
}

By simply changing it to (as a test)

static void __exit exit_orinoco(void)
{
	printk(KERN_DEBUG "exit_orinoco.\n");
}

I get this:
 Building modules, stage 2.
  MODPOST
  CC      /home/bpm/src/orinoco/orinoco.mod.o
  LD [M]  /home/bpm/src/orinoco/orinoco.ko

success.  So it looks like it is nuking the function.

Comment 7 Brian Millett 2005-03-03 05:51:27 UTC
Well, that was silly of me.  Cut and paste late at night.  The first
should have been:
static void __exit exit_orinoco(void)
{
}

hermes.c has the same problem and I used the wrong buffer to cut from.
 Oh well, I'm going to sleep.

Comment 8 Jakub Jelinek 2005-03-03 06:46:16 UTC
If a static function is never used in a way visible to the compiler, the compiler
can optimize them out (unless it is marked __attribute__((used)) or
-fno-unit-at-a-time), but already GCC 3.4 did this.
Can you post a preprocessed source?

Comment 9 Dave Jones 2005-03-03 06:50:56 UTC
Odd, we should be building with -fno-unit-at-a-time by default on i386 at least.
(From arch/i386/Makefile..)

# Disable unit-at-a-time mode, it makes gcc use a lot more stack
# due to the lack of sharing of stacklots.
CFLAGS += $(call cc-option,-fno-unit-at-a-time)


Comment 10 Brian Millett 2005-03-03 13:13:10 UTC
Created attachment 111613 [details]
orinoco.c

Comment 11 Roland McGrath 2005-03-04 00:49:07 UTC
Created attachment 111649 [details]
trivial test case for gcc bug

With -Os -fno-unit-at-a-time this produces bad output, eliding the function
though it emits an alias to it.  Dropping either of those options makes the bug
disappear.

Comment 12 Dave Jones 2005-03-04 22:04:08 UTC
For now I've changed the kernel to build as -O2 instead of -Os.
Refiling this as a gcc bug so you can track it.


Comment 13 Roland McGrath 2005-03-13 10:29:28 UTC
Jakub, be sure to tell kernel folks know when -Os is supposedly fixed so we can
start testing it again.

Comment 14 Jakub Jelinek 2005-03-13 11:07:25 UTC
Alexandre's patch is already in 4.0.0-0.31 and above.  But it has not been
accepted upstream yet.


Note You need to log in before you can comment on or make changes to this bug.