On Mon, Jul 18, 2022 at 3:12 PM Segher Boessenkool
wrote:
>
> Assembler language is unforgiving. It isn't easy to write, and most
> mistakes will not be diagnosed. If the assmbler language makes it
> easier to read the code, that makes it more likely correct code will be
> written, and that
On Mon, Jul 18, 2022 at 12:06:52PM -0700, Linus Torvalds wrote:
> On Sun, Jul 17, 2022 at 9:41 PM Michael Ellerman wrote:
> > > li 4,254 #,
> >
> > Here we load 254 into r4, which is the 2nd parameter to memset (c).
>
> I love how even powerpc people know that "4" is
On Sun, Jul 17, 2022 at 9:41 PM Michael Ellerman wrote:
>
> > li 4,254 #,
>
> Here we load 254 into r4, which is the 2nd parameter to memset (c).
I love how even powerpc people know that "4" is bogus, and have to
make it clear that it means "r4".
I don't understand why
On Mon, Jul 18, 2022 at 01:52:38PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > Can't we simply have a small simple implementation of these functions in
> > arch/powerpc/boot/? This stuff is not performance-critical, and this is
> > not the first time we hit these problems.
>
From: Michael Ellerman
> Sent: 18 July 2022 05:41
...
> So we're memsetting all of args to 254, not zero.
>
> That's happening because allmodconfig with gcc 12 enables
> CONFIG_INIT_STACK_ALL_PATTERN, whereas gcc 11 doesn't.
I can't help feeling it would be better if that generated
a call to a
Sudip Mukherjee writes:
> On Thu, Jul 14, 2022 at 9:55 AM Sudip Mukherjee (Codethink)
> wrote:
>>
>> Hi All,
>>
>> Not sure if it has been reported before but the latest mainline kernel
>> branch fails to build for powerpc allmodconfig with gcc-12 and the er
Segher Boessenkool writes:
> On Sun, Jul 17, 2022 at 07:44:22AM -0700, Linus Torvalds wrote:
>> On Sun, Jul 17, 2022 at 2:13 AM Sudip Mukherjee
>> wrote:
>> > I was trying to check it. With gcc-11 the assembly code generated is
>> > not using memset, but using __memset.
>> > But with gcc-12, I
On Sun, Jul 17, 2022 at 2:49 PM Segher Boessenkool
wrote:
>
> > I can *kind of* see the logic that when you do a whole struct
> > assignment, it turns into a "memcpy" without regard for volatile
> > members. You're not actually accessing the volatile members in some
> > particular order, so the
On Sun, Jul 17, 2022 at 02:11:52PM -0700, Linus Torvalds wrote:
> On Sun, Jul 17, 2022 at 2:00 PM Segher Boessenkool
> wrote:
> > Calling mem* on a volatile object (or a struct containing one) is not
> > valid. I opened gcc.gnu.org/PR106335.
>
> Well, that very quickly got marked as a duplicate
On Sun, Jul 17, 2022 at 2:00 PM Segher Boessenkool
wrote:
>
> Calling mem* on a volatile object (or a struct containing one) is not
> valid. I opened gcc.gnu.org/PR106335.
Well, that very quickly got marked as a duplicate of a decade-old bug.
So I guess we shouldn't expect this to be fixed any
On Sun, Jul 17, 2022 at 01:29:07PM -0700, Linus Torvalds wrote:
> On Sun, Jul 17, 2022 at 1:25 PM Sudip Mukherjee
> wrote:
> >
> > And the generated assembly still has the memset for "struct prom_args".
>
> Strange. That smells like a compiler bug to me.
>
> But I can't read powerpc assembly
On Sun, Jul 17, 2022 at 1:38 PM Sudip Mukherjee
wrote:
>
> I have also tried adding volatile to all the members of that struct. :(
Can you read the code to figure otu what the memcpy is all about?
Or maybe there is something that disables 'volatile' with pre-processor hackery.
Because a
On Sun, Jul 17, 2022 at 9:29 PM Linus Torvalds
wrote:
>
> On Sun, Jul 17, 2022 at 1:25 PM Sudip Mukherjee
> wrote:
> >
> > And the generated assembly still has the memset for "struct prom_args".
>
> Strange. That smells like a compiler bug to me.
Both gcc-12 and clang gives this error.
>
> But
On Sun, Jul 17, 2022 at 1:25 PM Sudip Mukherjee
wrote:
>
> And the generated assembly still has the memset for "struct prom_args".
Strange. That smells like a compiler bug to me.
But I can't read powerpc assembly code - it's been too many years, and
even back when I did read it I hated how the
On Sun, Jul 17, 2022 at 3:44 PM Linus Torvalds
wrote:
>
> On Sun, Jul 17, 2022 at 2:13 AM Sudip Mukherjee
> wrote:
> >
> > I was trying to check it. With gcc-11 the assembly code generated is
> > not using memset, but using __memset.
> > But with gcc-12, I can see the assembly code is using
On Sun, Jul 17, 2022 at 07:44:22AM -0700, Linus Torvalds wrote:
> On Sun, Jul 17, 2022 at 2:13 AM Sudip Mukherjee
> wrote:
> > I was trying to check it. With gcc-11 the assembly code generated is
> > not using memset, but using __memset.
> > But with gcc-12, I can see the assembly code is using
On Sun, Jul 17, 2022 at 2:13 AM Sudip Mukherjee
wrote:
>
> I was trying to check it. With gcc-11 the assembly code generated is
> not using memset, but using __memset.
> But with gcc-12, I can see the assembly code is using memset. One
> example from the assembly:
You could try making the 'args'
On Thu, Jul 14, 2022 at 9:55 AM Sudip Mukherjee (Codethink)
wrote:
>
> Hi All,
>
> Not sure if it has been reported before but the latest mainline kernel
> branch fails to build for powerpc allmodconfig with gcc-12 and the error is:
>
> Error: External symbol 'memset' refere
Hi All,
Not sure if it has been reported before but the latest mainline kernel
branch fails to build for powerpc allmodconfig with gcc-12 and the error is:
Error: External symbol 'memset' referenced from prom_init.c
make[2]: *** [arch/powerpc/kernel/Makefile:204:
arch/powerpc/kernel
patch could break somewhere :-(
Thanks you very much for identifying and fixing this issue. Other patch looks
good to me.
-Vasant
powerpc allmodconfig build on the latest upstream kernel results in:
ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!
This is due
On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
On 09/08/2013 5:28 PM, Guenter Roeck wrote:
Hi all,
powerpc allmodconfig build on the latest upstream kernel results in:
ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!
This is due to commit 15863ff3b
On Wed, Sep 11, 2013 at 08:02:49AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-09-09 at 16:55 -0700, Asai Thambi S P wrote:
On 09/08/2013 5:28 PM, Guenter Roeck wrote:
Hi all,
powerpc allmodconfig build on the latest upstream kernel results in:
ERROR: .cpu_to_chip_id
On 09/08/2013 5:28 PM, Guenter Roeck wrote:
Hi all,
powerpc allmodconfig build on the latest upstream kernel results in:
ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!
This is due to commit 15863ff3b (powerpc: Make chip-id information
available to userspace
On 09/09/2013 04:55 PM, Asai Thambi S P wrote:
On 09/08/2013 5:28 PM, Guenter Roeck wrote:
Hi all,
powerpc allmodconfig build on the latest upstream kernel results in:
ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!
This is due to commit 15863ff3b (powerpc: Make chip
Hi all,
powerpc allmodconfig build on the latest upstream kernel results in:
ERROR: .cpu_to_chip_id [drivers/block/mtip32xx/mtip32xx.ko] undefined!
This is due to commit 15863ff3b (powerpc: Make chip-id information available to
userspace).
Not surprising, as cpu_to_chip_id() is not exported
weren't ready for
2.6.36, so Mark asked me to pick them back up[1]. It also has the
powerpc allmodconfig build failure fix.
[1]http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg45616.html
Cheers,
g.
The following changes since commit 17879857821adad4e180c5d6457c3b8bbf1d0c0c:
Linus
On Thu, 2008-10-16 at 13:02 -0700, Arjan van de Ven wrote:
On Thu, 16 Oct 2008 12:49:23 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
#endif
#define __WARN() warn_on_slowpath(__FILE__, __LINE__)
#define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
#else
#define
* David Miller [EMAIL PROTECTED] wrote:
net/dccp/options.c: In function 'dccp_parse_options':
net/dccp/options.c:67: warning: 'value' may be used uninitialized in
this function
Known issue, not trivial to fix, gcc is just being incredibly silly
here as it can't see all of the
On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
drivers/dma/ioat_dca.c:81: error: implicit declaration of function
'cpuid_eax'
drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
drivers/dma/ioat_dca.c:91:
Dan Williams wrote:
On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
drivers/dma/ioat_dca.c:81: error: implicit declaration of function
'cpuid_eax'
drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
From: Brice Goglin [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 08:55:08 +0200
Dan Williams wrote:
On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
drivers/dma/ioat_dca.c:81: error: implicit declaration of function
At Thu, 16 Oct 2008 10:38:36 +0300,
Adrian Bunk wrote:
On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
At Wed, 15 Oct 2008 21:33:37 -0700,
Andrew Morton wrote:
sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is
deprecated (declared at
On Wed, 15 Oct 2008, David Miller wrote:
kernel/resource.c: In function '__reserve_region_with_split':
kernel/resource.c:554: warning: format '%llx' expects type 'long long
unsigned int', but argument 3 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type
On Thu, 16 Oct 2008, David Miller wrote:
From: Geert Uytterhoeven [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 09:31:29 +0200 (CEST)
On Wed, 15 Oct 2008, David Miller wrote:
kernel/resource.c: In function '__reserve_region_with_split':
kernel/resource.c:554: warning: format '%llx'
On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
At Thu, 16 Oct 2008 10:38:36 +0300,
Adrian Bunk wrote:
On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
At Wed, 15 Oct 2008 21:33:37 -0700,
Andrew Morton wrote:
sound/soc/soc-dapm.c:1029: warning:
David Miller [EMAIL PROTECTED] writes:
net/dccp/options.c: In function 'dccp_parse_options':
net/dccp/options.c:67: warning: 'value' may be used uninitialized in this
function
Known issue, not trivial to fix, gcc is just being incredibly silly here as it
can't see all of the control flow.
At Thu, 16 Oct 2008 11:21:57 +0300,
Adrian Bunk wrote:
On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
At Thu, 16 Oct 2008 10:38:36 +0300,
Adrian Bunk wrote:
On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
At Wed, 15 Oct 2008 21:33:37 -0700,
Andrew
On Thu, Oct 16, 2008 at 10:43:33AM +0200, Takashi Iwai wrote:
At Thu, 16 Oct 2008 11:21:57 +0300,
Adrian Bunk wrote:
On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
At Thu, 16 Oct 2008 10:38:36 +0300,
Adrian Bunk wrote:
On Thu, Oct 16, 2008 at 07:57:29AM +0200,
On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
net/sched/sch_generic.c: In function 'dev_watchdog':
net/sched/sch_generic.c:224: warning: unused variable 'drivername'
Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer
on the stack looks unused.
I've
On Wed, Oct 15, 2008 at 09:33:37PM -0700, Andrew Morton wrote:
sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is
deprecated (declared at sound/soc/soc-dapm.c:1026)
sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is
deprecated (declared at
From: Johannes Berg [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 16:57:19 +0200
On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
net/sched/sch_generic.c: In function 'dev_watchdog':
net/sched/sch_generic.c:224: warning: unused variable 'drivername'
Sucky, if WARN_ONCE()
On Thu, 16 Oct 2008 12:49:23 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
#endif
#define __WARN() warn_on_slowpath(__FILE__, __LINE__)
#define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
#else
#define __WARN_printf(arg...) __WARN()
the easiest way I suppose would be to
On Wed, Oct 15, 2008 at 11:58 PM, David Miller [EMAIL PROTECTED] wrote:
There's already a completely different fix queued in netdev patchworks
(for myri10ge only right now, to be duplicated for Intel drivers). The
idea is to stop having almost-unrelated drivers select each other
directly, let
arch/powerpc/kernel/setup_64.c:447:5: warning: kernstart_addr is not defined
arch/powerpc/kernel/setup_64.c:447:5: warning: kernstart_addr is not defined
kernel/resource.c: In function '__reserve_region_with_split':
kernel/resource.c:554: warning: format '%llx' expects type 'long long unsigned
Some comments for some of these...
On Wed, 2008-10-15 at 21:33 -0700, Andrew Morton wrote:
kernel/resource.c: In function '__reserve_region_with_split':
kernel/resource.c:554: warning: format '%llx' expects type 'long long
unsigned int', but argument 3 has type 'resource_size_t'
From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 15 Oct 2008 21:33:37 -0700
kernel/resource.c: In function '__reserve_region_with_split':
kernel/resource.c:554: warning: format '%llx' expects type 'long long
unsigned int', but argument 3 has type 'resource_size_t'
kernel/resource.c:554:
On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 15 Oct 2008 21:33:37 -0700
kernel/resource.c: In function '__reserve_region_with_split':
kernel/resource.c:554: warning: format '%llx' expects type 'long long
unsigned int', but
At Wed, 15 Oct 2008 21:33:37 -0700,
Andrew Morton wrote:
sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is
deprecated (declared at sound/soc/soc-dapm.c:1026)
sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is
deprecated (declared at
Hi Andrew,
On Wed, 20 Aug 2008 18:16:26 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
powerpc allmodconfig:
ERROR: CMO_PageSize [arch/powerpc/platforms/pseries/cmm.ko] undefined!
(needed for 2.6.27)
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED
Hi Paul,
On Thu, 21 Aug 2008 15:01:43 +1000 Paul Mackerras [EMAIL PROTECTED] wrote:
OK. I think we need to export CMO_PrPSP and CMO_SecPSP as well.
(Lovely names. :()
These are only used (indirectly) in lparcfg.c which is never a module, so
should be OK.
--
Cheers,
Stephen Rothwell
on the toolchain is showing up a bug in ld.
powerpc allmodconfig:
ERROR: CMO_PageSize [arch/powerpc/platforms/pseries/cmm.ko] undefined!
(needed for 2.6.27)
OK. I think we need to export CMO_PrPSP and CMO_SecPSP as well.
(Lovely names. :()
Paul
51 matches
Mail list logo
