4e1b2d52a80d79296a5d899d73249748dea71a53
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All errors (new ones prefixed by >>):
>> ERROR: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!
---
0-DAY kernel test infrastructure
make.cross ARCH=blackfin
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!
>
Blackfin is still maintained by Steven Miao right?
I had sent mail about this before, but did not hear a response, so I am
4e1b2d52a80d79296a5d899d73249748dea71a53
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All errors (new ones prefixed by >>):
>> ERROR: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!
---
0-DAY kernel test infrastructure
4e1b2d52a80d79296a5d899d73249748dea71a53
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All errors (new ones prefixed by >>):
>> ERROR: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!
---
0-DAY kernel test infrastructure
4e1b2d52a80d79296a5d899d73249748dea71a53
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All errors (new ones prefixed by >>):
>> ERROR: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!
---
0-DAY kernel test infrastructure
On Thursday 09 June 2016 11:16 PM, Andrew Morton wrote:
On Thu, 9 Jun 2016 22:53:33 +0100 Sudip Mukherjee
wrote:
We are having build failure with m32r and the error message being:
ERROR: "__ucmpdi2" [lib/842/842_decompress.ko] undefined!
ERROR: "__ucmpdi2" [fs/btrfs
On Thu, 9 Jun 2016 22:53:33 +0100 Sudip Mukherjee
wrote:
> We are having build failure with m32r and the error message being:
> ERROR: "__ucmpdi2" [lib/842/842_decompress.ko] undefined!
> ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined!
> ERROR: "__ucmpdi
We are having build failure with m32r and the error message being:
ERROR: "__ucmpdi2" [lib/842/842_decompress.ko] undefined!
ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!
ERROR: "__ucmpdi2" [driver
modules
ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined!
ERROR: "__ucmpdi2" [drivers/md/dm-verity.ko] undefined!
The attached patch resolves this problem. It is based on the s390
implementation of ucmpdi2.c.
Signed-off-by: John David Anglin
Cc: "James E.J. Bottomley"
Olaf Hering wrote:
On Tue, Jun 19, Stephen Hemminger wrote:
On Tue, 19 Jun 2007 21:02:53 +0200
Olaf Hering <[EMAIL PROTECTED]> wrote:
What happend to __ucmpdi2 from David Woodhouse?
google has a few hits about stuff like this on 32bit powerpc with gcc 4.1.2:
ERROR: "__ucmpdi2&qu
Andrew Morton wrote:
This fix is still not present in anyone's tree and is required for
2.6.22. Where are we up to with it?
It's in my mbox queue for 2.6.22 (hopefully today).
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
To: Stephen Hemminger
> > Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
> > Subject: Re: 2.6.22: ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!
> >
> > On Tue, Jun 19, Stephen Hemminger wrote:
> >
> > > On Tue, 19 Jun 2007 21:02:53 +0200
> &g
; [EMAIL PROTECTED]
Subject: Re: 2.6.22: ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!
On Tue, Jun 19, Stephen Hemminger wrote:
> On Tue, 19 Jun 2007 21:02:53 +0200
> Olaf Hering <[EMAIL PROTECTED]> wrote:
>
> >
> > What happend to __ucmpdi2 from David
On Tue, Jun 19, Stephen Hemminger wrote:
> On Tue, 19 Jun 2007 21:02:53 +0200
> Olaf Hering <[EMAIL PROTECTED]> wrote:
>
> >
> > What happend to __ucmpdi2 from David Woodhouse?
> > google has a few hits about stuff like this on 32bit powerpc with gcc 4.1.2:
>
On Tue, 19 Jun 2007 21:02:53 +0200
Olaf Hering <[EMAIL PROTECTED]> wrote:
>
> What happend to __ucmpdi2 from David Woodhouse?
> google has a few hits about stuff like this on 32bit powerpc with gcc 4.1.2:
>
> ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!
What happend to __ucmpdi2 from David Woodhouse?
google has a few hits about stuff like this on 32bit powerpc with gcc 4.1.2:
ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!
using the drivers/net/s2io* files from 2.6.21 with 2.6.22-rc5 fixes t
atch. I should send today or tomorrow to Linus,
> together with other patches.
Hi Mauro,
The __ucmpdi2() problem is still present in 2.6.20-rc5, please (re)send
your patch to Linus before 2.6.20 goes final...
Thanks.
--
Stelian Pop <[EMAIL PROTECTED]>
-
To unsubscribe from this list: sen
Em Qui, 2007-01-04 às 15:18 -0800, Andrew Morton escreveu:
> On Thu, 04 Jan 2007 20:59:08 -0200
> Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
>
> > > The largest value we use here is 0x0200. Perhaps v4l2_std_id
> > > shouldn't
> > > be 64-bit?
> > Too late to change it to 32 bits. It is
The largest value we use here is 0x0200. Perhaps v4l2_std_id
shouldn't
be 64-bit?
Too late to change it to 32 bits. It is at V4L2 userspace API since
kernel 2.6.0. We can, however use this approach as a workaround, with
the proper documentation.
Maybe with a BUG_ON(id > UINT_MAX) ?
If t
Le jeudi 04 janvier 2007 à 20:59 -0200, Mauro Carvalho Chehab a écrit :
> > The largest value we use here is 0x0200. Perhaps v4l2_std_id shouldn't
> > be 64-bit?
> Too late to change it to 32 bits. It is at V4L2 userspace API since
> kernel 2.6.0. We can, however use this approach as a workar
On Thu, 04 Jan 2007 20:59:08 -0200
Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > The largest value we use here is 0x0200. Perhaps v4l2_std_id shouldn't
> > be 64-bit?
> Too late to change it to 32 bits. It is at V4L2 userspace API since
> kernel 2.6.0.
You could perhaps make it 32-bit
Em Qui, 2007-01-04 às 14:48 -0800, Andrew Morton escreveu:
> On Thu, 04 Jan 2007 12:10:14 +0100
> Stelian Pop <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > This patch replaces a switch statement using 64 bit values with the
> > if/else equivalent in order t
On Thu, 04 Jan 2007 12:10:14 +0100
Stelian Pop <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This patch replaces a switch statement using 64 bit values with the
> if/else equivalent in order to prevent a call __ucmpdi2 generated by
> some versions of gcc (verified wi
Le jeudi 04 janvier 2007 à 04:09 -0800, Trent Piepho a écrit :
> On Thu, 4 Jan 2007, Stelian Pop wrote:
> > This patch replaces a switch statement using 64 bit values with the
> > if/else equivalent in order to prevent a call __ucmpdi2 generated by
> > some versions of gcc (ve
On Thu, 4 Jan 2007, Stelian Pop wrote:
> This patch replaces a switch statement using 64 bit values with the
> if/else equivalent in order to prevent a call __ucmpdi2 generated by
> some versions of gcc (verified with gcc-4.1.2 20060928):
>
> drivers/built-in
Hi,
This patch replaces a switch statement using 64 bit values with the
if/else equivalent in order to prevent a call __ucmpdi2 generated by
some versions of gcc (verified with gcc-4.1.2 20060928):
drivers/built-in.o: In function `v4l2_norm_to_name':
(.text+0x71100): unde
ther
> arches do is link libgcc.a into libs-y, and export the symbol
> they want from it.
You still get to 'accidentally' do 64-bit arithmetic in-kernel that way
though. Might be better just to provide __ucmpdi2, just as we have for
the other functions which are required from libg
hrdi3(long long, int);
> EXPORT_SYMBOL(__ashrdi3);
> EXPORT_SYMBOL(__ashldi3);
> EXPORT_SYMBOL(__lshrdi3);
> +
> +extern void __ucmpdi2(void);
> +EXPORT_SYMBOL(__ucmpdi2);
> #endif
>
> EXPORT_SYMBOL(memcpy);
> -
> To unsubscribe from this list: send the line "u
i3);
EXPORT_SYMBOL(__ashldi3);
EXPORT_SYMBOL(__lshrdi3);
+
+extern void __ucmpdi2(void);
+EXPORT_SYMBOL(__ucmpdi2);
#endif
EXPORT_SYMBOL(memcpy);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
Em Qua, 2006-12-13 às 14:11 +0200, Meelis Roos escreveu:
> MODPOST 618 modules
> WARNING: "__ucmpdi2" [drivers/media/video/v4l2-common.ko] undefined!
>
> This 32-bit ppc architecture, using gcc version 4.1.2 20061115
> (prerelease) (Debian 4.1.1-21). .config below if
Meelis Roos napisał(a):
MODPOST 618 modules
WARNING: "__ucmpdi2" [drivers/media/video/v4l2-common.ko] undefined!
This 32-bit ppc architecture, using gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21). .config below if important.
__ucmpdi2 seems to be 64-bit comparision. gc
MODPOST 618 modules
WARNING: "__ucmpdi2" [drivers/media/video/v4l2-common.ko] undefined!
This 32-bit ppc architecture, using gcc version 4.1.2 20061115
(prerelease) (Debian 4.1.1-21). .config below if important.
__ucmpdi2 seems to be 64-bit comparision. gcc seems to use it
In article <[EMAIL PROTECTED]>,
Jeremy Higdon <[EMAIL PROTECTED]> wrote:
>
>In my case, it is simple "long long" arithmetic. Shifts, ANDs, ORs,
>comparisons, etc. Not even any addition (which should be pretty efficient
>with the HW carry bit on X86). I don't know why:
Oh, I agree. In your cas
So I understand the point about filesystems and values that always happen
to be a power of two where the compiler can't know that.
However:
> From: [EMAIL PROTECTED] (Linus Torvalds)
>
> >So what we've said is: 64 bit is okay, except in a switch statement,
> >or other random expressions that mi
it >> filesystem->blocksize_bits;
which does exactly the same thing, except it is about a hundred times
faster.
See?
>> In the case of __ucmpdi2, it appears to be a combination of kernel and
>> compiler stupidity - there's no reason why __ucmpdi2 should not be done
&g
[Jeremy Higdon]
> Is there a little FAQ of C constructions you should not use if you
> are writing kernel code? It took a little doing to figure out that
> it was the switch that was causing trouble and not the shifts and
> arithmetic operations, and I'd like to avoid that in the future :-).
He
[Cahalan]
> Well, what do you care about most? The problem can be solved in
> other, more disturbing ways. :-) For example, gcc's computed goto.
[code snipped]
You are sick. (:
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
Jeremy Higdon writes:
> In reality, the switch does a 60 bit shift right, so I can cast to a
> uint, which is the right thing to do on old architectures :-), solving
> the problem. I had originally thought that the problem was in all the
> masks, shifts, and compares, but they are all inlined.
On Sep 19, 8:39am, Richard Henderson wrote:
>
> On Tue, Sep 19, 2000 at 12:22:41PM +0200, Andreas Schwab wrote:
> > IMHO it's a bug in gcc that it does not inline the comparison inside the
> > switch expression, since it already does it in all other places. Perhaps
> > some problem with the pat
I would have thought that the compiler would generate a shift if it
could (I'm presuming you're talking about shifting by a constant
here -- or are you talking about code that always shifts by a
computed power of two).
> In the case of __ucmpdi2, it appears to be a combination of kernel
en do horribly stupid things, and use 64-bit
>division etc instead of using a simple shift. Again, not linking
>against libgcc finds those things early rather than late, because the
>horribly stupid things end up requireing libgcc support.
>
> In the case of __ucmpdi2, it app
exceptions
- Linux developers often do horribly stupid things, and use 64-bit
division etc instead of using a simple shift. Again, not linking
against libgcc finds those things early rather than late, because the
horribly stupid things end up requireing libgcc support.
In the case of __ucmpdi
On Tue, Sep 19, 2000 at 12:22:41PM +0200, Andreas Schwab wrote:
> IMHO it's a bug in gcc that it does not inline the comparison inside the
> switch expression, since it already does it in all other places. Perhaps
> some problem with the patterns in the machine description.
Perhaps, but without
On Sep 19, 1:08pm, Matti Aarnio wrote:
>
> On Tue, Sep 19, 2000 at 02:58:01AM -0700, Jeremy Higdon wrote:
> > Hello,
> >
> > I'm using a 64 bit variable in a switch statement. Gcc is generating code
> > which make calls to __ucmpdi2, a function defined in
Matti Aarnio <[EMAIL PROTECTED]> writes:
|> On Tue, Sep 19, 2000 at 02:58:01AM -0700, Jeremy Higdon wrote:
|> > Hello,
|> >
|> > I'm using a 64 bit variable in a switch statement. Gcc is generating code
|> > which make calls to __ucmpdi2, a function defin
On Tue, Sep 19, 2000 at 02:58:01AM -0700, Jeremy Higdon wrote:
> Hello,
>
> I'm using a 64 bit variable in a switch statement. Gcc is generating code
> which make calls to __ucmpdi2, a function defined in libgcc. I figured
> out that it was the switch statement from exa
Hello,
I'm using a 64 bit variable in a switch statement. Gcc is generating code
which make calls to __ucmpdi2, a function defined in libgcc. I figured
out that it was the switch statement from examining the generated code.
The question is whether I should change C code to avoid construc
47 matches
Mail list logo
