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
------------------------------------------------------------------------------
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
