Menu
▾
▴
gcc4cli-devel
|
From: Thierry L. <thi...@in...> - 2010-03-03 11:04:50
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi all,<br> <br> I'm currently in trouble to run a gcc4cli compiled CLI code (compiled on Linux/x86 machine) on a Linux/SPARC64 box with Mono (hello.exe simply printf "Hello World"):<br> <blockquote><font color="#993300"><tt>$ ls<br> gcc4net.dll hello.exe libstd.dll MSCorelibWrapper.dll<br> $ mono hello.exe<br> <br> Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object<br> at libstd.Obj?10?COBJ?init () [0x00000] in <filename unknown>:0<br> at libstd..init () [0x00000] in <filename unknown>:0<br> at hello..init () [0x00000] in <filename unknown>:0<br> at hello..start (System.String[] args) [0x00000] in <filename unknown>:0</tt></font><br> </blockquote> All the DLLs come from gcc4cli compiled on the x86 box. I thought these DLLs would work fine but this is not the case.<br> So I tried to compile gcc4cli on the SPARC64 box in order to get these DLLs fine. But the build failed:<br> <blockquote><font color="#993300"><tt>$ ../../gcc-src/gcc/configure --target=cil32 --enable-languages=c --disable-bootstrap --prefix=/local/lafage/gcc/image --with-local-prefix=/local/lafage/gcc/image/cil32 --with-mpfr=/local/lafage/misc --with-gmp=/local/lafage/misc<br> [...]<br> $ make<br> [...]<br> if /udd/lafage/local/gcc/gcc-build/gcc/./gcc/xgcc -B/udd/lafage/local/gcc/gcc-build/gcc/./gcc/ -B/local/lafage/gcc/image/cil32/bin/ -B/local/lafage/gcc/image/cil32/lib/ -isystem /local/lafage/gcc/image/cil32/include -isystem /local/lafage/gcc/image/cil32/sys-include -DHAVE_CONFIG_H -I. -I../../../../../gcc-src/gcc/libstd/src -I.. -nostdinc -iwithprefix include -I../../../../../gcc-src/gcc/libstd/include -g -O2 -MT libstd_dll-__io_fout.o -MD -MP -MF ".deps/libstd_dll-__io_fout.Tpo" -c -o libstd_dll-__io_fout.o `test -f '__io_fout.c' || echo '../../../../../gcc-src/gcc/libstd/src/'`__io_fout.c; \</tt><br> <tt> then mv -f ".deps/libstd_dll-__io_fout.Tpo" ".deps/libstd_dll-__io_fout.Po"; else rm -f ".deps/libstd_dll-__io_fout.Tpo"; exit 1; fi</tt><br> <tt>/tmp/ccKF1tBh.s (2014, 36):</tt><br> <tt>Unhandled Exception: System.ArgumentException: Destination array is not long enough to copy all the items in the collection. Check array index and length.</tt><br> <tt> at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src, Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0</tt><br> <tt> at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex) [0x00000] in <filename unknown>:0</tt><br> <tt> at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename unknown>:0</tt><br> <tt> at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd) [0x00000] in <filename unknown>:0</tt><br> <tt> at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path) [0x00000] in <filename unknown>:0</tt><br> <tt>make[4]: *** [libstd_dll-__io_fout.o] Error 1</tt></font><br> </blockquote> Note that I recompiled mpfr and gmp in 32-bit mode.<br> <br> So I have 2 questions:<br> <ol> <li>Is it normal that gcc4li DLLs are not portable since they are .NET assemblies?</li> <li>Are there special configuration options to compile gcc4cli on SPARC64?</li> </ol> Thanks for any help,<br> <pre class="moz-signature" cols="72">Thierry Lafage. </pre> </body> </html> |
|
From: Gabriele S. <gab...@gm...> - 2010-03-03 11:13:44
|
Hi Thierry, 2010/3/3 Thierry Lafage <thi...@in...>: > Hi all, > > [snip] > > So I have 2 questions: > > Is it normal that gcc4li DLLs are not portable since they are .NET > assemblies? Yes, it is normal because the structures layout is tied to 32-bit little-endian architectures (i.e. pointer are 32-bit large, bit-fields are arranged in little-endian fashion, etc...). On top of that SPARC64 requires 64-bit alignment for all 64-bit operands (including long integers, and floating-point doubles, not only pointers) something that the CLI-BE layout engine doesn't enforce. > Are there special configuration options to compile gcc4cli on SPARC64? If I remember correctly we should have a big-endian switch somewhere which might help but it won't fix the alignment/layout problems, aside from that you must make sure that on the SPARC64 you are using the 32-bit version of Mono and its libraries as we have no support for 64-bit architectures. Gabriele Svelto |
|
From: Thierry L. <thi...@in...> - 2010-03-03 11:19:55
|
Hi Gabriele, Thanks for your answer. For gcc4cli compilation, I've just realised that the build did not use the version of mono I wanted. It used an old 1.9.1 instead of the 2.6.1... Rebuild is on the way now... Thierry Lafage. Gabriele Svelto a écrit : > Hi Thierry, > > 2010/3/3 Thierry Lafage <thi...@in...>: > >> Hi all, >> >> [snip] >> >> So I have 2 questions: >> >> Is it normal that gcc4li DLLs are not portable since they are .NET >> assemblies? >> > > Yes, it is normal because the structures layout is tied to 32-bit > little-endian architectures (i.e. pointer are 32-bit large, bit-fields > are arranged in little-endian fashion, etc...). On top of that SPARC64 > requires 64-bit alignment for all 64-bit operands (including long > integers, and floating-point doubles, not only pointers) something > that the CLI-BE layout engine doesn't enforce. > > >> Are there special configuration options to compile gcc4cli on SPARC64? >> > > If I remember correctly we should have a big-endian switch somewhere > which might help but it won't fix the alignment/layout problems, aside > from that you must make sure that on the SPARC64 you are using the > 32-bit version of Mono and its libraries as we have no support for > 64-bit architectures. > > Gabriele Svelto > |
|
From: Andrea C. O. <and...@gm...> - 2010-03-03 11:20:15
|
Hi, the libraries are in pure CLI and are portable in compatible machine families (same pointer size, same endianness). by default we compile little endian, 32bit pointer size the 64bit pointer size was in the plans but we never got the time to actually do it. Now, looking at the errors you report. The first one, I guess was already reported from Erven and it's probably an error in Mono if I recall it correctly it mishandled a CLI copy object instruction when passed an unmanaged pointer (it happens in initialization of global variables) The second problem you have is in the assembler. you can compile with -S and see how the assembly file looks like, it should be the same on x86 and on sparc. If so the error is in the as tool you are using that is ilasm (from Mono again). Andrea On Wed, Mar 3, 2010 at 11:29 AM, Thierry Lafage <thi...@in...> wrote: > Hi all, > > I'm currently in trouble to run a gcc4cli compiled CLI code (compiled on > Linux/x86 machine) on a Linux/SPARC64 box with Mono (hello.exe simply printf > "Hello World"): > > $ ls > gcc4net.dll hello.exe libstd.dll MSCorelibWrapper.dll > $ mono hello.exe > > Unhandled Exception: System.NullReferenceException: Object reference not set > to an instance of an object > at libstd.Obj?10?COBJ?init () [0x00000] in <filename unknown>:0 > at libstd..init () [0x00000] in <filename unknown>:0 > at hello..init () [0x00000] in <filename unknown>:0 > at hello..start (System.String[] args) [0x00000] in <filename unknown>:0 > > All the DLLs come from gcc4cli compiled on the x86 box. I thought these DLLs > would work fine but this is not the case. > So I tried to compile gcc4cli on the SPARC64 box in order to get these DLLs > fine. But the build failed: > > $ ../../gcc-src/gcc/configure --target=cil32 --enable-languages=c > --disable-bootstrap --prefix=/local/lafage/gcc/image > --with-local-prefix=/local/lafage/gcc/image/cil32 > --with-mpfr=/local/lafage/misc --with-gmp=/local/lafage/misc > [...] > $ make > [...] > if /udd/lafage/local/gcc/gcc-build/gcc/./gcc/xgcc > -B/udd/lafage/local/gcc/gcc-build/gcc/./gcc/ > -B/local/lafage/gcc/image/cil32/bin/ -B/local/lafage/gcc/image/cil32/lib/ > -isystem /local/lafage/gcc/image/cil32/include -isystem > /local/lafage/gcc/image/cil32/sys-include -DHAVE_CONFIG_H -I. > -I../../../../../gcc-src/gcc/libstd/src -I.. -nostdinc -iwithprefix > include -I../../../../../gcc-src/gcc/libstd/include -g -O2 -MT > libstd_dll-__io_fout.o -MD -MP -MF ".deps/libstd_dll-__io_fout.Tpo" -c -o > libstd_dll-__io_fout.o `test -f '__io_fout.c' || echo > '../../../../../gcc-src/gcc/libstd/src/'`__io_fout.c; \ > then mv -f ".deps/libstd_dll-__io_fout.Tpo" > ".deps/libstd_dll-__io_fout.Po"; else rm -f > ".deps/libstd_dll-__io_fout.Tpo"; exit 1; fi > /tmp/ccKF1tBh.s (2014, 36): > Unhandled Exception: System.ArgumentException: Destination array is not long > enough to copy all the items in the collection. Check array index and > length. > at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src, > Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0 > at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex) > [0x00000] in <filename unknown>:0 > at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename > unknown>:0 > at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd) > [0x00000] in <filename unknown>:0 > at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path) > [0x00000] in <filename unknown>:0 > make[4]: *** [libstd_dll-__io_fout.o] Error 1 > > Note that I recompiled mpfr and gmp in 32-bit mode. > > So I have 2 questions: > > Is it normal that gcc4li DLLs are not portable since they are .NET > assemblies? > Are there special configuration options to compile gcc4cli on SPARC64? > > Thanks for any help, > > Thierry Lafage. > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel > > |
|
From: Thierry L. <thi...@in...> - 2010-03-04 14:27:34
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi, <br> <br> In fact, for the second problem, I used -S to compare the assembly files and they are the same (SPARC one compared to x86 one). <br> Then, I successfully compiled and installed Mono (2.6.1+patch for Sparc from <a class="moz-txt-link-freetext" href="https://bugzilla.novell.com/show_bug.cgi?id=566298">https://bugzilla.novell.com/show_bug.cgi?id=566298</a>) on my SPARC box, but the ilasm problem is still the same :<br> <blockquote><font color="#993300"><tt>Unhandled Exception: System.ArgumentException: Destination array is not long enough to copy all the items in the collection. Check array index and length.<br> at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src, Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0<br> at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex) [0x00000] in <filename unknown>:0<br> at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename unknown>:0<br> at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd) [0x00000] in <filename unknown>:0<br> at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path) [0x00000] in <filename unknown>:0</tt></font><br> </blockquote> The problematic source asm is:<br> <blockquote><font color="#993300"><tt>ldc.r8 float64(0x41dfffffffc00000) /* 2.147483647e+9 */</tt></font><br> </blockquote> It seems that SystemToDouble() does not manage to convert the constant because its byte[] parameter is not long enough (should be 8, but ...?)<br> I suspect something's wrong in ilasm build (jay?), but I don't know what. If you have any clue, feel free to share <span class="moz-smiley-s3"><span> ;-) </span></span><br> <br> <pre class="moz-signature" cols="72">Thierry Lafage. </pre> <br> <br> Andrea Carlo Ornstein a écrit : <blockquote cite="mid:b1d...@ma..." type="cite"> <pre wrap="">Hi, the libraries are in pure CLI and are portable in compatible machine families (same pointer size, same endianness). by default we compile little endian, 32bit pointer size the 64bit pointer size was in the plans but we never got the time to actually do it. Now, looking at the errors you report. The first one, I guess was already reported from Erven and it's probably an error in Mono if I recall it correctly it mishandled a CLI copy object instruction when passed an unmanaged pointer (it happens in initialization of global variables) The second problem you have is in the assembler. you can compile with -S and see how the assembly file looks like, it should be the same on x86 and on sparc. If so the error is in the as tool you are using that is ilasm (from Mono again). Andrea On Wed, Mar 3, 2010 at 11:29 AM, Thierry Lafage <a class="moz-txt-link-rfc2396E" href="mailto:thi...@in..."><thi...@in...></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi all, I'm currently in trouble to run a gcc4cli compiled CLI code (compiled on Linux/x86 machine) on a Linux/SPARC64 box with Mono (hello.exe simply printf "Hello World"): $ ls gcc4net.dll hello.exe libstd.dll MSCorelibWrapper.dll $ mono hello.exe Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object at libstd.Obj?10?COBJ?init () [0x00000] in <filename unknown>:0 at libstd..init () [0x00000] in <filename unknown>:0 at hello..init () [0x00000] in <filename unknown>:0 at hello..start (System.String[] args) [0x00000] in <filename unknown>:0 All the DLLs come from gcc4cli compiled on the x86 box. I thought these DLLs would work fine but this is not the case. So I tried to compile gcc4cli on the SPARC64 box in order to get these DLLs fine. But the build failed: $ ../../gcc-src/gcc/configure --target=cil32 --enable-languages=c --disable-bootstrap --prefix=/local/lafage/gcc/image --with-local-prefix=/local/lafage/gcc/image/cil32 --with-mpfr=/local/lafage/misc --with-gmp=/local/lafage/misc [...] $ make [...] if /udd/lafage/local/gcc/gcc-build/gcc/./gcc/xgcc -B/udd/lafage/local/gcc/gcc-build/gcc/./gcc/ -B/local/lafage/gcc/image/cil32/bin/ -B/local/lafage/gcc/image/cil32/lib/ -isystem /local/lafage/gcc/image/cil32/include -isystem /local/lafage/gcc/image/cil32/sys-include -DHAVE_CONFIG_H -I. -I../../../../../gcc-src/gcc/libstd/src -I.. -nostdinc -iwithprefix include -I../../../../../gcc-src/gcc/libstd/include -g -O2 -MT libstd_dll-__io_fout.o -MD -MP -MF ".deps/libstd_dll-__io_fout.Tpo" -c -o libstd_dll-__io_fout.o `test -f '__io_fout.c' || echo '../../../../../gcc-src/gcc/libstd/src/'`__io_fout.c; \ then mv -f ".deps/libstd_dll-__io_fout.Tpo" ".deps/libstd_dll-__io_fout.Po"; else rm -f ".deps/libstd_dll-__io_fout.Tpo"; exit 1; fi /tmp/ccKF1tBh.s (2014, 36): Unhandled Exception: System.ArgumentException: Destination array is not long enough to copy all the items in the collection. Check array index and length. at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src, Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0 at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex) [0x00000] in <filename unknown>:0 at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename unknown>:0 at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd) [0x00000] in <filename unknown>:0 at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path) [0x00000] in <filename unknown>:0 make[4]: *** [libstd_dll-__io_fout.o] Error 1 Note that I recompiled mpfr and gmp in 32-bit mode. So I have 2 questions: Is it normal that gcc4li DLLs are not portable since they are .NET assemblies? Are there special configuration options to compile gcc4cli on SPARC64? Thanks for any help, Thierry Lafage. ------------------------------------------------------------------------------ Download Intel&#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-sw-dev">http://p.sf.net/sfu/intel-sw-dev</a> _______________________________________________ Gcc4cli-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Gcc...@li...">Gcc...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel">https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel</a> </pre> </blockquote> </blockquote> </body> </html> |
|
From: Erven R. <erv...@in...> - 2010-03-08 17:31:34
|
Hello everybody, I understand that we assume 32-bit pointers. But about endianness: I remember that we generate initializers for both, and a small run-time check to pick the right one. What are the cases where we have problems? -- Erven. Andrea Carlo Ornstein a écrit : > Hi, > > the libraries are in pure CLI and are portable in compatible machine > families (same pointer size, same endianness). > by default we compile little endian, 32bit pointer size > the 64bit pointer size was in the plans but we never got the time to > actually do it. > > Now, looking at the errors you report. > The first one, I guess was already reported from Erven and it's > probably an error in Mono > if I recall it correctly it mishandled a CLI copy object instruction > when passed an unmanaged pointer (it happens in initialization of > global variables) > > The second problem you have is in the assembler. > you can compile with -S and see how the assembly file looks like, it > should be the same on x86 and on sparc. > If so the error is in the as tool you are using that is ilasm (from Mono again). > > Andrea > > > On Wed, Mar 3, 2010 at 11:29 AM, Thierry Lafage <thi...@in...> wrote: >> Hi all, >> >> I'm currently in trouble to run a gcc4cli compiled CLI code (compiled on >> Linux/x86 machine) on a Linux/SPARC64 box with Mono (hello.exe simply printf >> "Hello World"): >> >> $ ls >> gcc4net.dll hello.exe libstd.dll MSCorelibWrapper.dll >> $ mono hello.exe >> >> Unhandled Exception: System.NullReferenceException: Object reference not set >> to an instance of an object >> at libstd.Obj?10?COBJ?init () [0x00000] in <filename unknown>:0 >> at libstd..init () [0x00000] in <filename unknown>:0 >> at hello..init () [0x00000] in <filename unknown>:0 >> at hello..start (System.String[] args) [0x00000] in <filename unknown>:0 >> >> All the DLLs come from gcc4cli compiled on the x86 box. I thought these DLLs >> would work fine but this is not the case. >> So I tried to compile gcc4cli on the SPARC64 box in order to get these DLLs >> fine. But the build failed: >> >> $ ../../gcc-src/gcc/configure --target=cil32 --enable-languages=c >> --disable-bootstrap --prefix=/local/lafage/gcc/image >> --with-local-prefix=/local/lafage/gcc/image/cil32 >> --with-mpfr=/local/lafage/misc --with-gmp=/local/lafage/misc >> [...] >> $ make >> [...] >> if /udd/lafage/local/gcc/gcc-build/gcc/./gcc/xgcc >> -B/udd/lafage/local/gcc/gcc-build/gcc/./gcc/ >> -B/local/lafage/gcc/image/cil32/bin/ -B/local/lafage/gcc/image/cil32/lib/ >> -isystem /local/lafage/gcc/image/cil32/include -isystem >> /local/lafage/gcc/image/cil32/sys-include -DHAVE_CONFIG_H -I. >> -I../../../../../gcc-src/gcc/libstd/src -I.. -nostdinc -iwithprefix >> include -I../../../../../gcc-src/gcc/libstd/include -g -O2 -MT >> libstd_dll-__io_fout.o -MD -MP -MF ".deps/libstd_dll-__io_fout.Tpo" -c -o >> libstd_dll-__io_fout.o `test -f '__io_fout.c' || echo >> '../../../../../gcc-src/gcc/libstd/src/'`__io_fout.c; \ >> then mv -f ".deps/libstd_dll-__io_fout.Tpo" >> ".deps/libstd_dll-__io_fout.Po"; else rm -f >> ".deps/libstd_dll-__io_fout.Tpo"; exit 1; fi >> /tmp/ccKF1tBh.s (2014, 36): >> Unhandled Exception: System.ArgumentException: Destination array is not long >> enough to copy all the items in the collection. Check array index and >> length. >> at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src, >> Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0 >> at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex) >> [0x00000] in <filename unknown>:0 >> at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename >> unknown>:0 >> at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd) >> [0x00000] in <filename unknown>:0 >> at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path) >> [0x00000] in <filename unknown>:0 >> make[4]: *** [libstd_dll-__io_fout.o] Error 1 >> >> Note that I recompiled mpfr and gmp in 32-bit mode. >> >> So I have 2 questions: >> >> Is it normal that gcc4li DLLs are not portable since they are .NET >> assemblies? >> Are there special configuration options to compile gcc4cli on SPARC64? >> >> Thanks for any help, >> >> Thierry Lafage. >> |
|
From: Gabriele S. <gab...@gm...> - 2010-03-08 20:12:43
|
Hi Erven,
2010/3/8 Erven Rohou <erv...@in...>:
> Hello everybody,
>
> I understand that we assume 32-bit pointers.
> But about endianness: I remember that we generate initializers for both, and a
> small run-time check to pick the right one. What are the cases where we have
> problems?
One (composed) word: bit-fields. And unfortunately not only the
bit-fields which you can find in regular C/C++ but also the ones that
GCC happily generates under many conditions. Here's one example:
struct foo
{
short a;
short b;
}
bool bar(struct foo*f)
{
if (foo->a == 1 && foo->b == 2)
return 1;
else
return 0;
}
GCC will turn the comparison into a BIT_FIELD_REF (or whatever it's
called now, there have been some changes there) that loads both the
16-bit integers as a single 32-bit integer and compares it with a
specifically tailored integer value. Unfortunately that value will be
different depending on the target endianness. When I was working on
that part of the project I tried disabling that specific optimization
only to find out that it was done both during the gimplification pass
and in the front-end (!) so it was impossible to remove it. I believe
that there were plans to move those optimizations in a better place
but I haven't followed the mailing-lists recently so I have no idea if
they actually did it. If they didn't, it is impossible to work around
that problem and that taints our code with the endian type we have
chosen at GCC build-time.
Gabriele
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X