All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Pedro Falcato <pfalcato@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	kernel test robot <lkp@intel.com>,
	Josh Law <objecting@objecting.org>,
	oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org,
	Linux Memory Management List <linux-mm@kvack.org>,
	linux-mips@vger.kernel.org, Bradley Morgan <brads@mainlining.org>
Subject: Re: arch/mips/boot/compressed/decompress.c:undefined reference to `__ashldi3'
Date: Fri, 2 Oct 2026 10:53:33 +0100	[thread overview]
Message-ID: <20261002105333.6f77abd0@pumpkin> (raw)
In-Reply-To: <ar4050mdKL_W8yI9@pedro-suse.tail5790ac.ts.net>

On Thu, 1 Oct 2026 11:30:09 +0100
Pedro Falcato <pfalcato@suse.de> wrote:

> On Wed, Sep 30, 2026 at 12:01:59PM -0700, Andrew Morton wrote:
> > On Wed, 30 Sep 2026 18:36:50 +0200 kernel test robot <lkp@intel.com> wrote:
> >   
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > head:   551c722f40809618230001baccf219193e22fc5a
> > > commit: d4dba3b9c03a326cfa73833d6b166aeb442f82b5 lib: decompress_bunzip2: fix 32-bit shift undefined behavior
> > > date:   6 months ago
> > > config: mips-randconfig-r2300-20260930 (https://download.01.org/0day-ci/archive/20260930/202609301826.MFaFMsmd-lkp@intel.com/config)
> > > compiler: mips-linux-gcc (GCC) 15.2.0
> > > sparse: v0.6.5-rc1
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260930/202609301826.MFaFMsmd-lkp@intel.com/reproduce)
> > > 
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Fixes: d4dba3b9c03a ("lib: decompress_bunzip2: fix 32-bit shift undefined behavior")
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202609301826.MFaFMsmd-lkp@intel.com/
> > > 
> > > All errors (new ones prefixed by >>):
> > > 
> > >    mips-linux-ld: arch/mips/boot/compressed/decompress.o: in function `get_bits':  
> > > >> arch/mips/boot/compressed/decompress.c:(.text+0xf4): undefined reference to `__ashldi3'
> > > >> mips-linux-ld: arch/mips/boot/compressed/decompress.c:(.text+0x168): undefined reference to `__ashldi3'  
> > 
> > I dunno, I'd be suspecting a toolchain issue here?
> > 
> > --- a/lib/decompress_bunzip2.c
> > +++ b/lib/decompress_bunzip2.c
> > @@ -135,7 +135,7 @@ static unsigned int INIT get_bits(struct bunzip_data *bd, char bits_wanted)
> >  		}
> >  		/* Avoid 32-bit overflow (dump bit buffer to top of output) */
> >  		if (bd->inbufBitCount >= 24) {
> > -			bits = bd->inbufBits&((1 << bd->inbufBitCount)-1);
> > +			bits = bd->inbufBits & ((1ULL << bd->inbufBitCount) - 1);
> >  			bits_wanted -= bd->inbufBitCount;
> >  			bits <<= bits_wanted;
> >  			bd->inbufBitCount = 0;
> > @@ -146,7 +146,7 @@ static unsigned int INIT get_bits(struct bunzip_data *bd, char bits_wanted)
> >  	}
> >  	/* Calculate result */
> >  	bd->inbufBitCount -= bits_wanted;
> > -	bits |= (bd->inbufBits >> bd->inbufBitCount)&((1 << bits_wanted)-1);
> > +	bits |= (bd->inbufBits >> bd->inbufBitCount) & ((1ULL << bits_wanted) - 1);
> >  
> >  	return bits;
> >  }
> > 
> > 32-bit MIPS should be able to do this?  
> 
> FWIW the patch seems entirely bogus. I don't think you can have inbufBitCount >=
> 32. If you could, then the patch would still not fix anything, because
> bd->inbufBits is an (32-bit) unsigned int.

The 1 should probably be 1U (or possibly 1UL is 64bit values can happen on
64bit) rather than 1ULL.

Wasn't the problem being solved '1 << 31' being undefined (or UB) and one of
the static checkers deciding that should never shift a signed value left?
That is entirely bogus anyway.
It is only non-portable because C allows 1's compliment and sign overpunch
for negative integers, gcc supports neither (and I think the next C standard
mandates 2's compliment).

That is separate from shift right of negative values being UB to allow for
cpu that don't have a sign replicating shift (all modern ones do).
Think about it, for a shift/rotate left you need one of 0/carry/high-bit and
for shift right 0/carry/low-bit so two instruction bits can select one of
0/carry/low-bit/high-bit (giving the often implemented but undocumented shift
left that replicates the low bit).

David

> 
> As per MIPS itself, MIPS does not link ashldi3.o into the decompressor for BZ2.
> It only does so for XZ and ZSTD.
> 
> Changing arch/mips/boot/compressed/Makefile would work, but since the change is
> entirely wrong I would suggest perhaps reverting?
> 
> 


  parent reply	other threads:[~2026-10-02  9:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30 16:36 arch/mips/boot/compressed/decompress.c:undefined reference to `__ashldi3' kernel test robot
2026-09-30 19:01 ` Andrew Morton
2026-09-30 19:11   ` Bradley Morgan
2026-10-01 10:30   ` Pedro Falcato
2026-10-02  1:07     ` Andrew Morton
2026-10-02  9:53     ` David Laight [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-07-24 13:33 kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261002105333.6f77abd0@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=brads@mainlining.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=objecting@objecting.org \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=pfalcato@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.