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 corr
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 bogus
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 th
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 me
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 ca
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 st
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 cod
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 compil
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 r
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 memse
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 me
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&#x
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/powe
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
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
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/mti
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:
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 usersp
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 no
tches 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 17879857821adad4e180c5d6457c3b8bbf1d0c0
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
> >
* 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
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
>> direc
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
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 WA
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 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
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 sound/soc/soc-
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 -0
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:
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
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' expect
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 cont
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 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 sound/soc/soc-dapm.c:1026)
> > sound/soc/soc-dapm.c:1029: warning: 'sn
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' expects type 'long long
> > > unsigned int',
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 func
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':
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
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 sound/soc/soc-dapm
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',
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:
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'
> kernel/r
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 unsig
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
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!
>
> (need
f puts 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
/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-ld:
vmlinux: section .data.gcov lma 0xc2cdbb78 overlaps previous sections
that probably happens in linux-next and maybe mainline too.
Also
From: Andrew Morton <[EMAIL PROTECTED]>
powerpc allmodconfig:
54 matches
Mail list logo
