Hi, Jian-Xin:
Yes, it support.
I am afraid the comment need to update. We only support last field
variant-length firstly as the comment says, but after some regression test
for kernel build and debugging, we finally add any field variant-length
support.
Ling Kun
2012/1/3 Jian-Xin Lai <laij...@gmail.com>
> From the comments, this patch only supports the case of the last field
> is variant-length? Does this patch work for the following case:
> int foo(int x, int y) {
> struct {
> int arr1[x];
> int arr2[0];
> int arr3[y];
> } st;
> st.arr1[0] = st.arr2[0] = st.arr3[0] = 1;
> printf("%d, %d, %d\n", st.arr1[0], st.arr2[0], st.arr3[0]);
> }
>
> 2012/1/3 Ling Kun <erlv5...@gmail.com>:
> > Hi, Gang and Sun:
> > I have merged ICT's VLAS patch to open64, the code can work for a
> > minimal testcase. Please see the attachment. More testcase following the
> > standard is needed, and I am working on it.
> >
> > To make things done quickly, I modified some of the code, the patch
> in
> > the attachment is only a draft version. I also need more information
> about
> > the x86 kernel building environment to go on. And the patch itself need
> some
> > modification to satisfy the svn trunck commit rules.
> >
> > My team mate Zhao Hongjian is working on the document. It will take
> him
> > some times to finish.
> >
> >
> > Gang, would you please give me some details about your compile
> command
> > and the .i file after preprocessor. Thanks.
> >
> > Ling Kun.
> >
> > The testcase :
> > #include <assert.h>
> > int f2(int i2){ return i2; }
> > static void f1(int i1) {
> > struct VLS{ int ary1[f2(i1)]; } st1;
> > st1.ary1[1] = i1 + 1;
> > assert( st1.ary1[1] == 3);
> > }
> >
> > int main () {
> > f1(2);
> > return 0;
> >
> > }
> >
> >
> > On Sun, Jan 1, 2012 at 9:02 PM, Gang Yu <yugang...@gmail.com> wrote:
> >>
> >> Hi, Ling Kun:
> >>
> >> Glad to hear loongson team has solved this issue! I googled this
> >> feature on gnu site, I do not find the relevant documents. Could you
> please
> >> write some documents or elaborate more on your patch?
> >>
> >> Thanks a lot!
> >>
> >> Regards
> >> Gang
> >>
> >>
> >>
> >> 2012/1/1 凌坤 <erlv5...@gmail.com>
> >>>
> >>> Hi, Sun:
> >>> I am glad to do that. And now I am trying to merge this patch to
> >>> Open64 svn trunck, it is a little complex to try to pick it from the
> >>> Loongson branch :)
> >>> Hoping that a patch that can pass some testcase can be submit in 1-2
> >>> days :)
> >>>
> >>> Happy New year.
> >>>
> >>> Ling Kun
> >>>
> >>>
> >>> ------------------ Original ------------------
> >>> From: "Sun Chan"<sun.c...@gmail.com>;
> >>> Date: Sun, Jan 1, 2012 02:25 PM
> >>> To: "Ling Kun"<lkun.e...@gmail.com>;
> >>> Cc: "open64-devel"<open64-devel@lists.sourceforge.net>;
> >>> Subject: Re: [Open64-devel] Current build status for linux kernel on
> >>> open64
> >>>
> >>> LingKun,
> >>>
> >>> can you send the changes for VLS (or VLA) to this alias (or send to me
> >>> and Yugang privately and we can help review and test out on x86) for
> >>> review?
> >>> Sun
> >>>
> >>> On Sun, Jan 1, 2012 at 10:14 AM, Ling Kun <lkun.e...@gmail.com> wrote:
> >>> > hi, Gang Yu:
> >>> > Loongson compiler(based on Open64) team have successfully build
> MIPS
> >>> > Linux kernel 2.6.35, and make it run on Qemu. And we have solved the
> >>> > VLA
> >>> > issue, the debug record and patches (based on the Open64 trunck svn
> >>> > r28xx)
> >>> > of Loongson teams' work have be sent to Zhu qing.
> >>> > If it is possible, we are glad to merge our VLA work to Open64
> >>> > current
> >>> > SVN trunck version.
> >>> >
> >>> > Ling Kun.
> >>> >
> >>> >
> >>> >
> >>> > On Sat, Dec 31, 2011 at 10:45 AM, Gang Yu <yugang...@gmail.com>
> wrote:
> >>> >>
> >>> >> Thanks. we also wish could get input from the original wgen authors,
> >>> >> it is
> >>> >> leaving an unsupported feature for VLA and then compiler asserts. In
> >>> >> order
> >>> >> to avoid duplication of effort, we wish learn from the seniors and
> >>> >> then we
> >>> >> can go ahead or make workaround.
> >>> >>
> >>> >>
> >>> >> Regards
> >>> >> Gang
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Sat, Dec 31, 2011 at 10:42 AM, Sun Chan <sun.c...@gmail.com>
> wrote:
> >>> >>>
> >>> >>> Let me try to understand. You are asking for opinions on whether
> >>> >>> ope64
> >>> >>> should ignore the VLA problem until there is further documentation
> >>> >>> and/or evidence of more VLA usage? Until then, workaround that by
> >>> >>> changing kernel source?
> >>> >>> Sun
> >>> >>>
> >>> >>> On Sat, Dec 31, 2011 at 10:36 AM, Gang Yu <yugang...@gmail.com>
> >>> >>> wrote:
> >>> >>> > Hi, list:
> >>> >>> >
> >>> >>> > We have some efforts on building and tuning linux kernel on
> >>> >>> > open64,
> >>> >>> > we
> >>> >>> > have fixed several bugs and now we have only two building issues
> >>> >>> > and
> >>> >>> > several running issues at x86_64 target, O2 level.
> >>> >>> >
> >>> >>> > linux 2.6.32 as an example, the two building issues are:
> >>> >>> >
> >>> >>> > A). bug787, Rao Shivarama has submitted a patch, but due to the
> >>> >>> > regression
> >>> >>> > filed as bug882, the patch is backed out. This is still a pending
> >>> >>> > issue. My
> >>> >>> > personally investigation shows Rao's approach is on the right
> >>> >>> > track,
> >>> >>> > the
> >>> >>> > bug882 shows the fix triggers the SSA version verification issues
> >>> >>> > which
> >>> >>> > are
> >>> >>> > already known in open64, filed as bug889/891/892. We will
> continue
> >>> >>> > work
> >>> >>> > on
> >>> >>> > it.
> >>> >>> >
> >>> >>> > B). the Variable Length Array in Structs (VLAS), this is a common
> >>> >>> > issue
> >>> >>> > for
> >>> >>> > non-gnu compilers.
> >>> >>> >
> >>> >>> > clang documents the issue below:
> >>> >>> >
> >>> >>> > Intentionally unsupported GCC extensions
> >>> >>> >
> >>> >>> > clang does not support the gcc extension that allows
> >>> >>> > variable-length
> >>> >>> > arrays
> >>> >>> > in structures. This is for a few reasons: one, it is tricky to
> >>> >>> > implement,
> >>> >>> > two, the extension is completely undocumented, and three, the
> >>> >>> > extension
> >>> >>> > appears to be rarely used. Note that clang does support flexible
> >>> >>> > array
> >>> >>> > members (arrays with a zero or unspecified size at the end of a
> >>> >>> > structure).
> >>> >>> >
> >>> >>> >
> >>> >>> > I review the failure case of kernel build, the VLAS are not the
> >>> >>> > flexible
> >>> >>> > array members(case like this : struct A { int a; int b; char
> >>> >>> > ctx[]} is
> >>> >>> > called Flexible array menbers. It is a newly introduced feature
> c99
> >>> >>> > or
> >>> >>> > later, open64 supports it well.)
> >>> >>> >
> >>> >>> > VLAS does not appear in linux kernel source code frequently:
> >>> >>> >
> >>> >>> > lib/libcrc32c.c
> >>> >>> > u32 crc32c(u32 crc, const void *address, unsigned int length)
> >>> >>> > 43{
> >>> >>> > 44 struct {
> >>> >>> > 45 struct shash_desc shash;
> >>> >>> > 46 char ctx[crypto_shash_descsize(tfm)];
> >>> >>> > 47 } desc;
> >>> >>> > crypto/testmgr.c
> >>> >>> > struct {
> >>> >>> > 1432 struct shash_desc shash;
> >>> >>> > 1433 char ctx[crypto_shash_descsize(tfm)];
> >>> >>> > 1434 } sdesc;
> >>> >>> > crypo/hmac.c
> >>> >>> > struct {
> >>> >>> > 1432 struct shash_desc shash;
> >>> >>> > 1433 char ctx[crypto_shash_descsize(tfm)
> >>> >>> > ];
> >>> >>> > 1434 } sdesc;
> >>> >>> >
> >>> >>> >
> >>> >>> > I just speculate that clang will support kernel build by
> flexible
> >>> >>> > array
> >>> >>> > members. It is not the case,
> >>> >>> >
> >>> >>> > http://llvm.org/bugs/show_bug.cgi?id=4071
> >>> >>> >
> >>> >>> > and people claim that they build up kernel with clang, but it is
> >>> >>> > not
> >>> >>> > fully
> >>> >>> > functional.
> >>> >>> >
> >>> >>> >
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html
> >>> >>> >
> >>> >>> > as this guy pointed out,
> >>> >>> >
> >>> >>> > * SELinux, Posix ACLs, IPSec, eCrypt, anything that uses the
> >>> >>> > crypto
> >>> >>> > API -
> >>> >>> > None
> >>> >>> > of these will compile, due to either an ICE or variable-length
> >>> >>> > arrays in
> >>> >>> > structures (don't remember which, it's in my notes somewhere).
> If
> >>> >>> > it's
> >>> >>> > variable-length arrays or another intentionally unsupported
> >>> >>> > GNUtension,
> >>> >>> > I'm
> >>> >>> > hoping it's just used in some isolated implementation detail
> (or
> >>> >>> > details),
> >>> >>> > and not a fundamental part of the crypto API (honestly just
> >>> >>> > haven't
> >>> >>> > had
> >>> >>> > a
> >>> >>> > chance to dive into the crypto source yet). I'm really hoping
> >>> >>> > it's
> >>> >>> > an
> >>> >>> > issue
> >>> >>> > in Clang, though, as it's easier for me to hack Clang and I'm
> >>> >>> > trying to
> >>> >>> > avoid kernel patches as much as possible.
> >>> >>> >
> >>> >>> >
> >>> >>> > We meet the problem and post it out, we wish we could get input
> >>> >>> > from
> >>> >>> > community and go on the kernel building/tuning work to broaden
> the
> >>> >>> > open64's
> >>> >>> > application and improve the code quality.
> >>> >>> >
> >>> >>> > Thanks.
> >>> >>> >
> >>> >>> > Regards
> >>> >>> > Gang
> >>> >>> >
> >>> >>> >
> >>> >>> >
> >>> >>> >
> ------------------------------------------------------------------------------
> >>> >>> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> >>> >>> > complex
> >>> >>> > infrastructure or vast IT resources to deliver seamless, secure
> >>> >>> > access
> >>> >>> > to
> >>> >>> > virtual desktops. With this all-in-one solution, easily deploy
> >>> >>> > virtual
> >>> >>> > desktops for less than the cost of PCs and save 60% on VDI
> >>> >>> > infrastructure
> >>> >>> > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> >>> >>> > _______________________________________________
> >>> >>> > Open64-devel mailing list
> >>> >>> > Open64-devel@lists.sourceforge.net
> >>> >>> > https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>> >>> >
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> ------------------------------------------------------------------------------
> >>> >> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> >>> >> complex
> >>> >> infrastructure or vast IT resources to deliver seamless, secure
> access
> >>> >> to
> >>> >> virtual desktops. With this all-in-one solution, easily deploy
> virtual
> >>> >> desktops for less than the cost of PCs and save 60% on VDI
> >>> >> infrastructure
> >>> >> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> >>> >> _______________________________________________
> >>> >> Open64-devel mailing list
> >>> >> Open64-devel@lists.sourceforge.net
> >>> >> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > http://www.lingcc.com
> >>> >
> >>> >
> >>> >
> ------------------------------------------------------------------------------
> >>> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> >>> > complex
> >>> > infrastructure or vast IT resources to deliver seamless, secure
> access
> >>> > to
> >>> > virtual desktops. With this all-in-one solution, easily deploy
> virtual
> >>> > desktops for less than the cost of PCs and save 60% on VDI
> >>> > infrastructure
> >>> > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> >>> > _______________________________________________
> >>> > Open64-devel mailing list
> >>> > Open64-devel@lists.sourceforge.net
> >>> > https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>> >
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex
> >>> infrastructure or vast IT resources to deliver seamless, secure access
> to
> >>> virtual desktops. With this all-in-one solution, easily deploy virtual
> >>> desktops for less than the cost of PCs and save 60% on VDI
> infrastructure
> >>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> >>> _______________________________________________
> >>> Open64-devel mailing list
> >>> Open64-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex
> >>> infrastructure or vast IT resources to deliver seamless, secure access
> to
> >>> virtual desktops. With this all-in-one solution, easily deploy virtual
> >>> desktops for less than the cost of PCs and save 60% on VDI
> infrastructure
> >>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> >>> _______________________________________________
> >>> Open64-devel mailing list
> >>> Open64-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>>
> >>
> >
> >
> >
> > --
> > http://www.lingcc.com
> >
> >
> ------------------------------------------------------------------------------
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create
> > new or port existing apps to sell to consumers worldwide. Explore the
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > _______________________________________________
> > Open64-devel mailing list
> > Open64-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/open64-devel
> >
>
>
>
> --
> Regards,
> Lai Jian-Xin
>
--
http://www.lingcc.com
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
