Re: [PATCH v6 18/19] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32

[pinskia]

> On Nov 18, 2015, at 12:11 AM, Zhangjian (Bamvor) 
>  wrote:
> 
> Hi, Yury
> 
>> On 2015/11/18 5:16, Yury Norov wrote:
>> From: Philipp Tomsich 
>> 
>> To make life for tools (such as gdb) easier when dealing with ILP32 
>> processes,
>> we report a proper subarchitecture for ILP32 in the ELF auxiliary vectors.
> I saw some ilp32 relative patches in binutils mailing list. Does gdb
> fully support ilp32?

I have a patch set but I have not tested them with the latest kernel patch set 
yet. The branch is located in the binutils-gdb git is 
https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/pinskia/gdb-aarch64-ilp32
 .
I think it will mostly work except for core support might need to be changed 
slightly. 

Thanks,
Andrew
> 
> Regards
> 
> Bamvor
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 18/19] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32

[pinskia]

> On Nov 18, 2015, at 12:11 AM, Zhangjian (Bamvor) 
> <bamvor.zhangj...@huawei.com> wrote:
> 
> Hi, Yury
> 
>> On 2015/11/18 5:16, Yury Norov wrote:
>> From: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
>> 
>> To make life for tools (such as gdb) easier when dealing with ILP32 
>> processes,
>> we report a proper subarchitecture for ILP32 in the ELF auxiliary vectors.
> I saw some ilp32 relative patches in binutils mailing list. Does gdb
> fully support ilp32?

I have a patch set but I have not tested them with the latest kernel patch set 
yet. The branch is located in the binutils-gdb git is 
https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/pinskia/gdb-aarch64-ilp32
 .
I think it will mostly work except for core support might need to be changed 
slightly. 

Thanks,
Andrew
> 
> Regards
> 
> Bamvor
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v6 00/17] ILP32 for ARM64

[pinskia]

> On Nov 9, 2015, at 10:36 PM, Arnd Bergmann  wrote:
> 
>> On Monday 09 November 2015 15:33:51 Andreas Schwab wrote:
>> Arnd Bergmann  writes:
>> 
 On Monday 09 November 2015 14:23:59 Andreas Schwab wrote:
 Yury Norov  writes:
 
> This is what I run:
> https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t
 
 That doesn't work for me:
 
 ../sysdeps/unix/sysv/linux/generic/sysdep.h:24:22: error: ‘__NR_llseek’ 
 undeclar
 ed (first use in this function)
 ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:41:32: error: ‘__NR_fcntl64’ 
 undeclared (first use in this function)
>>> 
>>> Did you re-export the kernel headers that you use as the base?
>> 
>> I'm using the patched 4.3 kernel headers.
> 
> Ok.
> 
>> Why is  defining __BITS_PER_LONG to 64 unconditionally?
> 
> It should not, that is a bug. I don't know how Yury built his glibc,
> but it can't work if __BITS_PER_LONG is wrong.


Looks like I had changed the header file manually for building glibc and Yury 
and myself missed that when  he updated the patches. 


Thanks,
Andrew

> 
>Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v6 00/17] ILP32 for ARM64

[pinskia]

> On Nov 9, 2015, at 10:36 PM, Arnd Bergmann  wrote:
> 
>> On Monday 09 November 2015 15:33:51 Andreas Schwab wrote:
>> Arnd Bergmann  writes:
>> 
 On Monday 09 November 2015 14:23:59 Andreas Schwab wrote:
 Yury Norov  writes:
 
> This is what I run:
> https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t
 
 That doesn't work for me:
 
 ../sysdeps/unix/sysv/linux/generic/sysdep.h:24:22: error: ‘__NR_llseek’ 
 undeclar
 ed (first use in this function)
 ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:41:32: error: ‘__NR_fcntl64’ 
 undeclared (first use in this function)
>>> 
>>> Did you re-export the kernel headers that you use as the base?
>> 
>> I'm using the patched 4.3 kernel headers.
> 
> Ok.
> 
>> Why is  defining __BITS_PER_LONG to 64 unconditionally?
> 
> It should not, that is a bug. I don't know how Yury built his glibc,
> but it can't work if __BITS_PER_LONG is wrong.


Looks like I had changed the header file manually for building glibc and Yury 
and myself missed that when  he updated the patches. 


Thanks,
Andrew

> 
>Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[pinskia]

> On Sep 2, 2015, at 1:30 AM, Mark Rutland  wrote:
> 
> [...]
> 
> On Sat, Aug 29, 2015 at 07:46:22PM +0100, Andrew Pinski wrote:
> It is useful to pass down MIDR register down to userland if all of
> the online cores are all the same type.  This adds AT_ARM64_MIDR
> aux vector type and passes down the midr system register.
> 
> This is alternative to MIDR_EL1 part of
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html.
> It allows for faster access to midr_el1 than going through a trap and
> does not exist if the set of cores are not the same.
 
 I'm not sure I follow the rationale. If speed is important the
 application can cache the value the first time it reads it with a trap.
>>> 
>>> It is also about compatibility also. Exposing the register is not backwards 
>>> compatible but using the aux vector is.
>> 
>> That would also break big.little too. So either break it with hot plug or 
>> break it in userland, your choice.
> 
> The value wouldn't be representative of the system as a whole; that is
> true. However, we never guaranteed that it was, while the aux vector
> code implied that we did.

Yes but I guess you talk about caching the value in userspace but doing it via 
the aux vector is the same as your suggestion. Just one difference is you don't 
get the aux vector entry if there is a CPU that is online which is different. 
No difference from your suggestion of caching it. Without considering hot pug 
for a second (that is a huge different issue all together), if userland wants 
to know if all up CPUs have the same midr, they would either read /sys entries 
(lots of syscalls) or bind to each CPU and do the trap. That means at least 
three or two syscalls/traps for each CPU. My way is none and gets a value of 
midr if they are all the Same for free. 

Again what is the difference between the aux vector and caching the value in 
userspace? Because it seems like you suggesting I do that but then avoiding 
big.little also. 

Thanks,
Andrew

> 
> For optimisation that may be good enough; code optimized for a different
> uArch should still function on another, even if it is slower.
> 
 This also means that the behaviour is different across homogeneous and
 heterogeneous systems.
>> 
>> That should be ok because it is still backwards compatible with what
>> was done before.  My goal here is just to allow quick easy access to
>> midr in the case of a homogeneous system which I care about, thunderx
>> and to allow glibc to select a memcpy/memset that is better for
>> thunderx.
> 
> As I mentioned in the other thread, I think that HWCAP_CPUID is
> sufficient to enable forwards and backwards compatibility. If it is
> present then you can use the current CPU's MIDR to select a better
> memcpy/memset if required.
> 
> Thanks,
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[pinskia]

> On Sep 2, 2015, at 12:33 AM, Mark Rutland  wrote:
> 
> Hi,
> 
>> On Sat, Aug 29, 2015 at 07:46:22PM +0100, Andrew Pinski wrote:
>> It is useful to pass down MIDR register down to userland if all of
>> the online cores are all the same type.  This adds AT_ARM64_MIDR
>> aux vector type and passes down the midr system register.
>> 
>> This is alternative to MIDR_EL1 part of
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html.
>> It allows for faster access to midr_el1 than going through a trap and
>> does not exist if the set of cores are not the same.
> 
> I'm not sure I follow the rationale. If speed is important the
> application can cache the value the first time it reads it with a trap.

It is also about compatibility also. Exposing the register is not backwards 
compatible but using the aux vector is. 

> 
> This also means that the behaviour is different across homogeneous and
> heterogeneous systems.
> 
>> Changes from v1:
>> Forgot to include the auxvec.h part.
>> 
>> Signed-off-by: Andrew Pinski 
>> ---
>> arch/arm64/include/asm/cpu.h |1 +
>> arch/arm64/include/asm/elf.h |6 ++
>> arch/arm64/include/uapi/asm/auxvec.h |3 +++
>> arch/arm64/kernel/cpuinfo.c  |   22 ++
>> 4 files changed, 32 insertions(+)
>> 
>> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
>> index 8e797b2..fab0aa1 100644
>> --- a/arch/arm64/include/asm/cpu.h
>> +++ b/arch/arm64/include/asm/cpu.h
>> @@ -62,5 +62,6 @@ DECLARE_PER_CPU(struct cpuinfo_arm64, cpu_data);
>> 
>> void cpuinfo_store_cpu(void);
>> void __init cpuinfo_store_boot_cpu(void);
>> +u32 get_arm64_midr(void);
>> 
>> #endif /* __ASM_CPU_H */
>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>> index faad6df..d3549de 100644
>> --- a/arch/arm64/include/asm/elf.h
>> +++ b/arch/arm64/include/asm/elf.h
>> @@ -17,6 +17,7 @@
>> #define __ASM_ELF_H
>> 
>> #include 
>> +#include 
>> 
>> /*
>>  * ELF register definitions..
>> @@ -138,8 +139,13 @@ typedef struct user_fpsimd_state elf_fpregset_t;
>> 
>> #define ARCH_DLINFO\
>> do {\
>> +u32 midr;\
>> +\
>>NEW_AUX_ENT(AT_SYSINFO_EHDR,\
>>(elf_addr_t)current->mm->context.vdso);\
>> +midr = get_arm64_midr();\
>> +if (midr != 0)\
>> +NEW_AUX_ENT(AT_ARM64_MIDR, (elf_addr_t)midr);\
>> } while (0)
>> 
>> #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
>> diff --git a/arch/arm64/include/uapi/asm/auxvec.h 
>> b/arch/arm64/include/uapi/asm/auxvec.h
>> index 22d6d88..dc55c56 100644
>> --- a/arch/arm64/include/uapi/asm/auxvec.h
>> +++ b/arch/arm64/include/uapi/asm/auxvec.h
>> @@ -19,4 +19,7 @@
>> /* vDSO location */
>> #define AT_SYSINFO_EHDR33
>> 
>> +/* Machine IDenfier Register (MDIR). */
>> +#define AT_ARM64_MIDR 38
>> +
>> #endif
>> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
>> index 75d5a86..b14c87d 100644
>> --- a/arch/arm64/kernel/cpuinfo.c
>> +++ b/arch/arm64/kernel/cpuinfo.c
>> @@ -254,3 +254,25 @@ void __init cpuinfo_store_boot_cpu(void)
>> 
>>boot_cpu_data = *info;
>> }
>> +
>> +u32 get_arm64_midr(void)
>> +{
>> +int i;
>> +u32 midr = 0;
>> +
>> +for_each_online_cpu(i) {
>> +struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
>> +u32 oldmidr = midr;
>> +
>> +midr = cpuinfo->reg_midr;
>> +/*
>> + * If there are cpus which have a different
>> + * midr just return 0.
>> + */
>> +if (oldmidr && oldmidr != midr)
>> +return 0;
>> +}
>> +
>> +return midr;
>> +}
> 
> If I have a big.LITTLE system where all the big CPUs are currently
> offline, this will leave the MIDR the little CPUs in the auxvec.
> However, at any point after this has run, I could hotplug the big CPUs
> on and the little CPUs off, leaving this reporting a MIDR that
> represents none of the online CPUs.
> 
> Given big.LITTLE and the potential for physical/dynamic hotplug (where
> we won't know all the MIDRs in advance), I don't think that we can
> generally expose a common MIDR in this fashion, and I don't think that
> we should give the impression that we can.

This is standard issue with hot plug and big.little. Really big.little is a 
design flaw but I am not going into that here. 


> 
> I think that the only things we can do are expose the MIDR for CPU the
> code is currently executing on (as Suzuki's patches do), and/or expose
> all the MIDRs for currently online CPUs (as Steve's [1] patch does).
> Anything else leaves us trying to provide semantics that we cannot
> guarantee.

Except they are not backwards compatible which means nobody in their right mind 
would use the register to get the midr that way. I am sorry but having a newer 
version of glibc working 

Re: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[pinskia]

> On Sep 2, 2015, at 1:30 AM, Mark Rutland  wrote:
> 
> [...]
> 
> On Sat, Aug 29, 2015 at 07:46:22PM +0100, Andrew Pinski wrote:
> It is useful to pass down MIDR register down to userland if all of
> the online cores are all the same type.  This adds AT_ARM64_MIDR
> aux vector type and passes down the midr system register.
> 
> This is alternative to MIDR_EL1 part of
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html.
> It allows for faster access to midr_el1 than going through a trap and
> does not exist if the set of cores are not the same.
 
 I'm not sure I follow the rationale. If speed is important the
 application can cache the value the first time it reads it with a trap.
>>> 
>>> It is also about compatibility also. Exposing the register is not backwards 
>>> compatible but using the aux vector is.
>> 
>> That would also break big.little too. So either break it with hot plug or 
>> break it in userland, your choice.
> 
> The value wouldn't be representative of the system as a whole; that is
> true. However, we never guaranteed that it was, while the aux vector
> code implied that we did.

Yes but I guess you talk about caching the value in userspace but doing it via 
the aux vector is the same as your suggestion. Just one difference is you don't 
get the aux vector entry if there is a CPU that is online which is different. 
No difference from your suggestion of caching it. Without considering hot pug 
for a second (that is a huge different issue all together), if userland wants 
to know if all up CPUs have the same midr, they would either read /sys entries 
(lots of syscalls) or bind to each CPU and do the trap. That means at least 
three or two syscalls/traps for each CPU. My way is none and gets a value of 
midr if they are all the Same for free. 

Again what is the difference between the aux vector and caching the value in 
userspace? Because it seems like you suggesting I do that but then avoiding 
big.little also. 

Thanks,
Andrew

> 
> For optimisation that may be good enough; code optimized for a different
> uArch should still function on another, even if it is slower.
> 
 This also means that the behaviour is different across homogeneous and
 heterogeneous systems.
>> 
>> That should be ok because it is still backwards compatible with what
>> was done before.  My goal here is just to allow quick easy access to
>> midr in the case of a homogeneous system which I care about, thunderx
>> and to allow glibc to select a memcpy/memset that is better for
>> thunderx.
> 
> As I mentioned in the other thread, I think that HWCAP_CPUID is
> sufficient to enable forwards and backwards compatibility. If it is
> present then you can use the current CPU's MIDR to select a better
> memcpy/memset if required.
> 
> Thanks,
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

[pinskia]

> On Sep 2, 2015, at 12:33 AM, Mark Rutland  wrote:
> 
> Hi,
> 
>> On Sat, Aug 29, 2015 at 07:46:22PM +0100, Andrew Pinski wrote:
>> It is useful to pass down MIDR register down to userland if all of
>> the online cores are all the same type.  This adds AT_ARM64_MIDR
>> aux vector type and passes down the midr system register.
>> 
>> This is alternative to MIDR_EL1 part of
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358995.html.
>> It allows for faster access to midr_el1 than going through a trap and
>> does not exist if the set of cores are not the same.
> 
> I'm not sure I follow the rationale. If speed is important the
> application can cache the value the first time it reads it with a trap.

It is also about compatibility also. Exposing the register is not backwards 
compatible but using the aux vector is. 

> 
> This also means that the behaviour is different across homogeneous and
> heterogeneous systems.
> 
>> Changes from v1:
>> Forgot to include the auxvec.h part.
>> 
>> Signed-off-by: Andrew Pinski 
>> ---
>> arch/arm64/include/asm/cpu.h |1 +
>> arch/arm64/include/asm/elf.h |6 ++
>> arch/arm64/include/uapi/asm/auxvec.h |3 +++
>> arch/arm64/kernel/cpuinfo.c  |   22 ++
>> 4 files changed, 32 insertions(+)
>> 
>> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
>> index 8e797b2..fab0aa1 100644
>> --- a/arch/arm64/include/asm/cpu.h
>> +++ b/arch/arm64/include/asm/cpu.h
>> @@ -62,5 +62,6 @@ DECLARE_PER_CPU(struct cpuinfo_arm64, cpu_data);
>> 
>> void cpuinfo_store_cpu(void);
>> void __init cpuinfo_store_boot_cpu(void);
>> +u32 get_arm64_midr(void);
>> 
>> #endif /* __ASM_CPU_H */
>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>> index faad6df..d3549de 100644
>> --- a/arch/arm64/include/asm/elf.h
>> +++ b/arch/arm64/include/asm/elf.h
>> @@ -17,6 +17,7 @@
>> #define __ASM_ELF_H
>> 
>> #include 
>> +#include 
>> 
>> /*
>>  * ELF register definitions..
>> @@ -138,8 +139,13 @@ typedef struct user_fpsimd_state elf_fpregset_t;
>> 
>> #define ARCH_DLINFO\
>> do {\
>> +u32 midr;\
>> +\
>>NEW_AUX_ENT(AT_SYSINFO_EHDR,\
>>(elf_addr_t)current->mm->context.vdso);\
>> +midr = get_arm64_midr();\
>> +if (midr != 0)\
>> +NEW_AUX_ENT(AT_ARM64_MIDR, (elf_addr_t)midr);\
>> } while (0)
>> 
>> #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
>> diff --git a/arch/arm64/include/uapi/asm/auxvec.h 
>> b/arch/arm64/include/uapi/asm/auxvec.h
>> index 22d6d88..dc55c56 100644
>> --- a/arch/arm64/include/uapi/asm/auxvec.h
>> +++ b/arch/arm64/include/uapi/asm/auxvec.h
>> @@ -19,4 +19,7 @@
>> /* vDSO location */
>> #define AT_SYSINFO_EHDR33
>> 
>> +/* Machine IDenfier Register (MDIR). */
>> +#define AT_ARM64_MIDR 38
>> +
>> #endif
>> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
>> index 75d5a86..b14c87d 100644
>> --- a/arch/arm64/kernel/cpuinfo.c
>> +++ b/arch/arm64/kernel/cpuinfo.c
>> @@ -254,3 +254,25 @@ void __init cpuinfo_store_boot_cpu(void)
>> 
>>boot_cpu_data = *info;
>> }
>> +
>> +u32 get_arm64_midr(void)
>> +{
>> +int i;
>> +u32 midr = 0;
>> +
>> +for_each_online_cpu(i) {
>> +struct cpuinfo_arm64 *cpuinfo = _cpu(cpu_data, i);
>> +u32 oldmidr = midr;
>> +
>> +midr = cpuinfo->reg_midr;
>> +/*
>> + * If there are cpus which have a different
>> + * midr just return 0.
>> + */
>> +if (oldmidr && oldmidr != midr)
>> +return 0;
>> +}
>> +
>> +return midr;
>> +}
> 
> If I have a big.LITTLE system where all the big CPUs are currently
> offline, this will leave the MIDR the little CPUs in the auxvec.
> However, at any point after this has run, I could hotplug the big CPUs
> on and the little CPUs off, leaving this reporting a MIDR that
> represents none of the online CPUs.
> 
> Given big.LITTLE and the potential for physical/dynamic hotplug (where
> we won't know all the MIDRs in advance), I don't think that we can
> generally expose a common MIDR in this fashion, and I don't think that
> we should give the impression that we can.

This is standard issue with hot plug and big.little. Really big.little is a 
design flaw but I am not going into that here. 


> 
> I think that the only things we can do are expose the MIDR for CPU the
> code is currently executing on (as Suzuki's patches do), and/or expose
> all the MIDRs for currently online CPUs (as Steve's [1] patch does).
> Anything else leaves us trying to provide semantics that we cannot
> guarantee.

Except they are not backwards compatible which means nobody in their right mind 
would use the register to get the midr that way. I am sorry 

Re: [PATCH] kernel: use the gnu89 standard explicitly

[pinskia]

> On Oct 19, 2014, at 4:05 PM, Linus Torvalds  
> wrote:
> 
>> On Sun, Oct 19, 2014 at 2:03 PM, Aaro Koskinen  wrote:
>> 
>> Here's one example how it fails: 
>> http://marc.info/?l=gcc=141349914632010=2
> 
> Ok, that just looks like a gnu11 bug, then. Not being able to
> initialize structures because some sub-structure has a volatile member
> is just pure BS.
> 
> Has anybody reported this as a gcc bug? That email may be on the gcc
> list, but I'm not seeing anybody acknowledge it as a bug..

Yes it was reported and both problems relating to this extension has been added 
to gnu99 and gnu11. Though there are other issues with the kernel dealing with 
extern inline have different semantics between gnu89 and gnu99/11. 

Thanks,
Andrew

> 
> I cannot imagine that anybody sane claims that this is *wanted*
> behavior from "gnu11".
> 
>   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel: use the gnu89 standard explicitly

[pinskia]

 On Oct 19, 2014, at 4:05 PM, Linus Torvalds torva...@linux-foundation.org 
 wrote:
 
 On Sun, Oct 19, 2014 at 2:03 PM, Aaro Koskinen aaro.koski...@iki.fi wrote:
 
 Here's one example how it fails: 
 http://marc.info/?l=gccm=141349914632010w=2
 
 Ok, that just looks like a gnu11 bug, then. Not being able to
 initialize structures because some sub-structure has a volatile member
 is just pure BS.
 
 Has anybody reported this as a gcc bug? That email may be on the gcc
 list, but I'm not seeing anybody acknowledge it as a bug..

Yes it was reported and both problems relating to this extension has been added 
to gnu99 and gnu11. Though there are other issues with the kernel dealing with 
extern inline have different semantics between gnu89 and gnu99/11. 

Thanks,
Andrew

 
 I cannot imagine that anybody sane claims that this is *wanted*
 behavior from gnu11.
 
   Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/