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

Julian Elischer julian at elischer.org
Mon May 28 07:04:53 UTC 2007


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 at gmail.com
>>> Cc: current at freebsd.org
>>> Subject: Re: [Regression] snd_emu10k1 doesn't work after GCC
>>> 4.2 upgrade
>>>
>>> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32100
>> 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,
>> ismaster: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.
>>
>>
>> Yuriy.
> 
> 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
now.


> 
> --HPS
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"



More information about the freebsd-current mailing list