when did this checkin happened? Did that gone through code review and
checkin review permission?
Sun
On Tue, Jan 3, 2012 at 6:27 PM, Ling Kun <erlv5...@gmail.com> wrote:
> 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
