Re: vrp bitfield miscompilation (WAS: [Regression] snd_emu10k1 doesn't work after GCC 4.2 upgrade)

Hans Petter Selasky wrote:
On Monday 28 May 2007 08:22, Yuriy Tsibizov wrote:
-----Original Message-----
From: Yuriy Tsibizov
Sent: Sunday, May 27, 2007 1:42 AM
To: Yuriy Tsibizov; kabaev@xxxxxxxxx
Cc: current@xxxxxxxxxxx
Subject: Re: [Regression] snd_emu10k1 doesn't work after GCC
4.2 upgrade

Use of following variables _can_ be affected by above miscompilation
(these are signed single-bit variables):

amd64/amd64/mp_machdep.c: int cpu_present:1;
amd64/amd64/mp_machdep.c: int cpu_bsp:1;
amd64/amd64/mp_machdep.c: int cpu_disabled:1;
dev/acpica/acpi_pci_link.c: int l_routed:1;
dev/acpica/acpi_pci_link.c: int l_isa_irq:1;
dev/sound/isa/ess.c: int type, duplex:1, newspeed:1;
dev/sound/pci/emu10k1.c: int b16:1, stereo:1, busy:1, running:1,
dev/sound/pci/solo.c: int simplex_dir, type, duplex:1,
newspeed:1, dmasz[2];
dev/puc/puc.c: int p_hasintr:1;
dev/puc/puc_bfe.h: int sc_fastintr:1;
dev/puc/puc_bfe.h: int sc_leaving:1;
dev/puc/puc_bfe.h: int sc_polled:1;
dev/rp/rpvar.h: int rp_rts_iflow:1;
dev/rp/rpvar.h: int rp_disable_writes:1;
dev/rp/rpvar.h: int rp_cts:1;
dev/rp/rpvar.h: int rp_waiting:1;
dev/rp/rpvar.h: int rp_xmit_stopped:1;
dev/scc/scc_bfe.h: int m_attached:1;
dev/scc/scc_bfe.h: int m_fastintr:1;
dev/scc/scc_bfe.h: int m_hasintr:1;
dev/scc/scc_bfe.h: int m_probed:1;
dev/scc/scc_bfe.h: int m_sysdev:1;
dev/scc/scc_bfe.h: int ch_enabled:1;
dev/scc/scc_bfe.h: int ch_sysdev:1;
dev/scc/scc_bfe.h: int sc_fastintr:1;
dev/scc/scc_bfe.h: int sc_leaving:1;
dev/scc/scc_bfe.h: int sc_polled:1;
dev/uart/uart_bus.h: int sc_callout:1; /* This UART is
opened for callout. */
dev/uart/uart_bus.h: int sc_fastintr:1; /* This UART
uses fast interrupts. */
dev/uart/uart_bus.h: int sc_hwiflow:1; /* This UART has
HW input flow ctl. */
dev/uart/uart_bus.h: int sc_hwoflow:1; /* This UART has
HW output flow ctl. */
dev/uart/uart_bus.h: int sc_leaving:1; /* This UART is
going away. */
dev/uart/uart_bus.h: int sc_opened:1; /* This UART is
open for business. */
dev/uart/uart_bus.h: int sc_polled:1; /* This UART has
no interrupts. */
dev/uart/uart_bus.h: int sc_txbusy:1; /* This UART is
transmitting. */
fs/pseudofs/pseudofs_internal.h: int pvd_dead:1;
geom/part/g_part.h: int gpe_created:1; /* Entry is
newly created. */
geom/part/g_part.h: int gpe_deleted:1; /* Entry has
been deleted. */
geom/part/g_part.h: int gpe_modified:1; /* Entry has
been modified. */
geom/part/g_part.h: int gpt_isleaf:1; /* Cannot be
sub-partitioned. */
geom/part/g_part.h: int gpt_created:1; /* Newly
created. */
geom/part/g_part.h: int gpt_modified:1; /* Table changes
have been made. */
geom/part/g_part.h: int gpt_opened:1; /* Permissions
obtained. */
i386/i386/mp_machdep.c: int cpu_present:1;
i386/i386/mp_machdep.c: int cpu_bsp:1;
i386/i386/mp_machdep.c: int cpu_disabled:1;
i386/include/npx.h: int fp_sgn:1; /* mantissa sign */
sparc64/pci/psycho.c: int apb:1;
sparc64/pci/psycho.c: int ppb:1;

I can't say that there _is_ a miscompilation related to all variables in
this list.

Should most of them (I'm not shure for fp_sign) be changed to unsigned
int? With (signed) int these flags have values of (-1;0), with unsigned
int they will use more obvious (0;1) values.


Interesting find. Another issue:

I've seen that the compile will round the memory size of a bit-fields down to the nearest byte, if you turn on optimization. I think you should use "uint8_t".

My memory is that bitfields are only defined as parts of an 'int'
in the standard and that using anything else is a gcc 'feature'.

This is a 14 year old memory (from my SCSI days) so it may not be true

freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: right padding
    ... Using gcc in mingw on a windows machine.. ... helpful things a compiler can do if you are writing library code like ... int num = 123; ... area of memory freed is the area that was allocated in the subroutine. ...
  • Re: data types
    ... Usually short is smaller than an int. ... memory per dms structure if they are 32-bit integers. ... current compiler system. ... recommend either a version of gcc,, or Visual Studio ...
  • Re: Use of Long and Long Long
    ... intuitive and much more useful (as it is now, ... smaller types very inefficient since it would have to keep masking etc. So to write an 8 bit char to memory it would have to on one of the processors... ... load memory location shifting data left 8 bits (1 clock) ... but takes maybe twice as long under gcc because long int now takes twice the memory and the processor unnecessarily emulates 64-bit arithmetic. ...
  • Re: weird behaviour by gcc
    ... The compiler can align memory as it chooses. ... > int main ... profit) when I noticed this behaviour by gcc. ...
  • Re: data types
    ... Usually short is smaller than an int. ... Your compiler is either *really* old or broken or both. ... recommend either a version of gcc,, or Visual Studio ... Microsoft's Visual Studio Express has an onerous EULA). ...