[Bug other/43449] New: sbitmap is broken if gcc is built with -m32 on a 64-bit machine.

[Bug other/43449] New: sbitmap is broken if gcc is built with -m32 on a 64-bit machine.

[dougkwan at google dot com]

We found a problem in sbitmap.c:


bool
sbitmap_range_empty_p (const_sbitmap bmap, unsigned int start, unsigned int n)
{
  unsigned int i = start / SBITMAP_ELT_BITS;
  SBITMAP_ELT_TYPE elm;
...
      /* The bits are totally contained in a single element.  */
      if (shift + n < SBITMAP_ELT_BITS)
        elm &= ((1 << n) - 1);

depending on configuration, SBITMAP_ELT_TYPE can be wider than the int type. 
The masking above will mistakenly strip off top bits from elm.  The correct
code should be written as:

      /* The bits are totally contained in a single element.  */
      if (shift + n < SBITMAP_ELT_BITS)
        elm &= (((SBITMAP_ELF_BITS) 1 << n) - 1);

The same problem appears in another location of the same function.  The broken
code is in both 4.4.0 and trunk.


-- 
           Summary: sbitmap is broken if gcc is built with -m32 on a 64-bit
                    machine.
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dougkwan at google dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu (with -m32)
GCC target triplet: arm-none-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43449

[Bug other/43449] sbitmap is broken if gcc is built with -m32 on a 64-bit machine.

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2010-03-19 21:02 -------
SBITMAP_ELT_TYPE is defined as HOST_WIDEST_FAST_INT. And HOST_WIDEST_FAST_INT
(added by me) is either "long" or "long long".  Yes there should be a cast but
it cannot be an issue really with -m32 really because long is the same size as
int there.  The host is LP32 as you described so long is the same size as int. 
If HOST_WIDEST_FAST_INT is "long long" there, there is bug in the configuration
as that will slow down the compiler anyways.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43449

[Bug other/43449] sbitmap is broken if gcc is built with -m32 on a 64-bit machine.

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2010-03-19 21:05 -------
This is the comment from hwint.h (which I know I did :) ):

/* Define HOST_WIDEST_FAST_INT to the widest integer type supported
   efficiently in hardware.  (That is, the widest integer type that fits
   in a hardware register.)  Normally this is "long" but on some hosts it
   should be "long long" or "__int64".  This is no convenient way to
   autodetect this, so such systems must set a flag in config.host; see there
   for details.  */

Only two hosts use it as "long long", x86_64-mingw and ia64-hpux.  Now I think
you are lying to configure that the host is x86_64-linux-gnu anyways if you are
using -m32.  I think the host (and build should be i686-linux-gnu).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43449

[Bug other/43449] sbitmap is broken if gcc is built with -m32 on a 64-bit machine.

[dougkwan at google dot com]

------- Comment #3 from dougkwan at google dot com  2010-03-19 23:09 -------
Yes, I lied to configure.  So this is not a real bug.


-- 

dougkwan at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43449