gcc in f8/x86 using more stack than in rhel5?

[Eric Sandeen]

I did a quick experiment, and it seems that by and large, gcc in f8 (gcc
version 4.1.2 20070821 (Red Hat 4.1.2-19)) is using slightly more stack
when building a kernel than is gcc on rhel5 (gcc version 4.1.1 20070105
(Red Hat 4.1.1-52))  There are a few functions using less, too, though.

After much checkstack output frobbing:

function [module] : old : new : delta
--------------------------------------
acpi_add_single_object [vmlinux]: 156 160 : 4
acpi_cpufreq_cpu_init [acpi-cpufreq]: 136 140 : 4
adi_connect [adi]: 144 148 : 4
aes_decrypt [aes]: 140 144 : 4
ahc_pci_config [aic7xxx]: 152 148 : -4
ata_do_eh [libata]: 292 304 : 12
aty128_probe [aty128fb]: 272 276 : 4
balance_internal [reiserfs]: 148 160 : 12
bond_arp_send_all [bonding]: 132 136 : 4
capidtmf_recv_block [divacapi]: 188 192 : 4
cciss_update_non_disk_devices [cciss]: 548 552 : 4
cfb_copyarea [vmlinux]: 148 144 : -4
check_balance [reiserfs]: 268 272 : 4
copy_to_user_tmpl [vmlinux]: 400 404 : 4
ctnetlink_new_expect [nf_conntrack_netlink]: 232 236 : 4
decode_rs16 [reed_solomon]: 220 224 : 4
diNewExt [jfs]: 112 108 : -4
diva_add_card [divacapi]: 144 156 : 12
do_balance [reiserfs]: 308 320 : 12
do_cciss_request [cciss]: 544 548 : 4
do_con_write [vmlinux]: 160 156 : -4
do_tx [eni]: 120 124 : 4
ea_dealloc_unstuffed [gfs2]: 116 120 : 4
ehci_urb_enqueue [ehci-hcd]: 196 212 : 16
ext4_expand_extra_isize_ea [ext4dev]: 128 132 : 4
ext4_ext_insert_extent [ext4dev]: 144 148 : 4
ext4_ext_remove_space [ext4dev]: 120 124 : 4
facility_req [divacapi]: 396 392 : -4
__fat_readdir [fat]: 252 256 : 4
fat_search_long [fat]: 408 412 : 4
fetch_frame [cpia]: 184 196 : 12
ftdi_elan_status_work [ftdi-elan]: 252 248 : -4
gdth_detect [gdth]: 440 436 : -4
get_far_parent [reiserfs]: 140 152 : 12
hfcpci_interrupt [hisax]: 356 360 : 4
hptiop_probe [hptiop]: 152 156 : 4
huft_build [vmlinux]: 152 144 : -8
ieee80211_master_start_xmit [mac80211]: 176 180 : 4
ieee80211_sta_work [mac80211]: 464 476 : 12
i_ipmi_request [ipmi_msghandler]: 108 100 : -8
inftl_scan_bbt [diskonchip]: 196 200 : 4
ip_route_input [vmlinux]: 196 192 : -4
ip_setsockopt [vmlinux]: 448 452 : 4
isdn_tty_write [isdn]: 160 164 : 4
ivtv_process_vbi_data [ivtv]: 116 120 : 4
jfs_readdir [jfs]: 348 340 : -8
key_schedule [cast5]: 608 596 : -12
matroxfb_dh_set_par [matroxfb_crtc2]: 116 120 : 4
matroxfb_ioctl [matroxfb_base]: 136 140 : 4
mmc_blk_issue_rq [mmc_block]: 360 356 : -4
module_verify_signature [vmlinux]: 124 120 : -4
myri10ge_xmit [myri10ge]: 112 116 : 4
nv_tx_timeout [forcedeth]: 156 144 : -12
ocfs2_write_cluster_by_desc [ocfs2]: 112 108 : -4
os_scsi_tape_open [osst]: 180 184 : 4
paging32_page_fault [kvm]: 116 108 : -8
parse_audio_unit [snd-usb-audio]: 132 144 : 12
patch_cmi9880 [snd-hda-intel]: 108 124 : 16
pbus_size_mem [vmlinux]: 124 128 : 4
pkt_open [pktcdvd]: 556 560 : 4
prism2_plx_probe [hostap_plx]: 116 136 : 20
qla1280_nvram_config [qla1280]: 128 160 : 32
r300_do_cp_cmdbuf [radeon]: 580 572 : -8
radeon_check_modes [radeonfb]: 204 212 : 8
radeon_get_pllinfo [radeonfb]: 176 192 : 16
s2io_add_isr [s2io]: 176 184 : 8
savage_dispatch_draw [savage]: 304 308 : 4
sd_revalidate_disk [sd_mod]: 156 116 : -40
search_by_key [reiserfs]: 256 272 : 16
send_s870 [atp870u]: 100 104 : 4
service_interrupt [atmel]: 188 192 : 4
_snd_emu10k1_audigy_init_efx [snd-emu10k1]: 160 164 : 4
snd_emu10k1_init_efx [snd-emu10k1]: 136 172 : 36
snd_intel8x0_probe [snd-intel8x0]: 156 148 : -8
snd_mixart_hw_params [snd-mixart]: 268 272 : 4
snd_pcm_common_ioctl1 [snd-pcm]: 272 276 : 4
snd_pcm_hw_refine [snd-pcm]: 160 168 : 8
snd_pcm_oss_change_params [snd-pcm-oss]: 168 176 : 8
snd_usb_create_midi_interface [snd-usb-lib]: 112 116 : 4
sr_probe [sr_mod]: 140 144 : 4
start_preview [saa7134]: 212 232 : 20
st_ioctl [st]: 128 144 : 16
stv680_newframe [stv680]: 176 192 : 16
svcauth_gss_accept [auth_rpcgss]: 216 208 : -8
sys_copyarea [syscopyarea]: 144 140 : -4
sys_init_module [vmlinux]: 232 236 : 4
tcp_sendmsg [vmlinux]: 128 120 : -8
tcp_v4_do_rcv [vmlinux]: 104 108 : 4
tulip_init_one [tulip]: 136 140 : 4
tveeprom_hauppauge_analog [tveeprom]: 156 164 : 8
txCommit [jfs]: 168 180 : 12
udf_get_block [udf]: 412 416 : 4
udf_get_filename [udf]: 584 580 : -4
write_filehandle [nfsd]: 208 204 : -4
xfs_alloc_delrec [xfs]: 132 144 : 12
xfs_bmap_btalloc [xfs]: 172 180 : 8
xfs_bmbt_delrec [xfs]: 212 216 : 4
xfs_bmbt_newroot [xfs]: 132 140 : 8
xfs_da_do_buf [xfs]: 188 192 : 4
xfs_inobt_delrec [xfs]: 148 152 : 4
xfs_inobt_newroot [xfs]: 172 176 : 4
xtSearch [jfs]: 104 116 : 12
xtUpdate [jfs]: 404 424 : 20
zd1201_usbrx [zd1201]: 100 108 : 8
------------------------
Functions increased: 79
Functions decreased: 25
Net change: +432 bytes


that starts with checkstack output, so it's only checking functions
using > 100 bytes of stack, and then the above is only showing functions
with changed stack usage... but from a spot-check, smaller stack-users
are affected as well.

With 4KSTACKS on x86, I'm afraid this could add up to more problems.

Any idea what might be causing this?

Thanks,

-Eric