Re: "cc" clobber
On 1/26/2016 4:31 PM, Bernd Schmidt wrote: On 01/27/2016 12:12 AM, David Wohlferd wrote: I started by just commenting out the code in ix86_md_asm_adjust that unconditionally clobbered the flags. I figured this would allow the 'normal' "cc" handling to occur. But apparently there is no 'normal' "cc" handling. I have a dim memory that there's a difference between the "cc" and "CC" spellings. You might want to check that. I checked, but my scan of the current code isn't turning up anything for "CC" related to clobbers either. While presumably "cc" did something at one time, apparently now it's just an unenforced comment (on extended asm). Not a problem, just a bit of a surprise. dw
GCC-Bridge: A Gimple Compiler targeting the JVM
I wanted to share a project we've been working on for sometime within the context of Renjin, a new interpreter for the R language running on the JVM. We basically needed a way to compile C and Fortran code to JVM classes, and for the last year or two we've been working on tool chain that's composed of a GCC plugin which dumps Gimple trees out to a JSON file, and a Java program which reads the JSON and compiles it to Java classfiles. I've written a bit more about it today here: http://www.renjin.org/blog/2016-01-31-introducing-gcc-bridge.html And you can find the whole project here: https://github.com/bedatadriven/renjin/tree/master/tools/gcc-bridge The compiler is part of the Renjin project, but can also be used in a standalone way to compile arbitrary C/Fortran code to Java classfiles, though the focus has been on pure scientific code, so we haven't bothered with some rather obvious things like fopen(). Anyway, using the GCC plugin interface has been terrific, and the gimple trees have been great to work with! -Alex
Re: "cc" clobber
David Wohlferd wrote: > On 1/26/2016 4:31 PM, Bernd Schmidt wrote: > > On 01/27/2016 12:12 AM, David Wohlferd wrote: > >> I started by just commenting out the code in ix86_md_asm_adjust that > >> unconditionally clobbered the flags. I figured this would allow the > >> 'normal' "cc" handling to occur. But apparently there is no 'normal' > >> "cc" handling. > > > > I have a dim memory that there's a difference between the "cc" and > > "CC" spellings. You might want to check that. > > I checked, but my scan of the current code isn't turning up anything for > "CC" related to clobbers either. > > While presumably "cc" did something at one time, apparently now it's > just an unenforced comment (on extended asm). Not a problem, just a bit > of a surprise. I think on many targets a clobber "cc" works because the backend actually defines a register named "cc" to correspond to the flags. Therefore the normal handling of clobbering named hard registers catches this case as well. This doesn't work on i386 because there the flags register is called "flags" in the back end. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
write, open and read statements in a fortran dll causing program to hang
Hello, I have write, open and read statements in a fortran program and compile as, gfortran -c test.f90 and create a dll with gfortran -shared test.dll -o test.o I import this dll in C# with dllimport and call one of the routine. After the call the program hangs on write(*,*) statement. May I know how I can compile test.f90 otherway to make it work with write, open and read statements? Regards,
Re: GCC-Bridge: A Gimple Compiler targeting the JVM
On 02/01/2016 03:34 PM, Bertram, Alexander wrote: > I wanted to share a project we've been working on for sometime within > the context of Renjin, > a new interpreter for the R language running on the JVM. > > We basically needed a way to compile C and Fortran code to JVM > classes, and for the last year or two we've been working on tool chain > that's composed of a GCC plugin which dumps Gimple trees out to a JSON > file, and a Java program which reads the JSON and compiles it to Java > classfiles. > > I've written a bit more about it today here: > http://www.renjin.org/blog/2016-01-31-introducing-gcc-bridge.html > > And you can find the whole project here: > https://github.com/bedatadriven/renjin/tree/master/tools/gcc-bridge > > The compiler is part of the Renjin project, but can also be used in a > standalone way to compile arbitrary C/Fortran code to Java classfiles, > though the focus has been on pure scientific code, so we haven't > bothered with some rather obvious things like fopen(). > > Anyway, using the GCC plugin interface has been terrific, and the > gimple trees have been great to work with! Interesting project. It's great to see that the plugin interface is actually used by real-world projects. P.S. I noticed this comment in your source code: // GCC won't let us malloc and I don't want to mess // around with GCC's internal memory management stuff, // so we'll just use a fixed-size stack You actually don't need to use any complex memory management stuff. GCC provides a wrapper for malloc called 'xmalloc'. It works like normal malloc, but aborts in case of allocation failure. -- Regards, Mikhail Maltsev
Help about how to bootstrap gcc with local version glibc other than system one
Hi, Recently I tried to bootstrap gcc against new glibc but failed. What I want to do is just bootstrap gcc against local version glibc other than system one, because I can't update glibc in that system. I tried this by configuring GCC using "--with-build-sysroot" or "--with-sysroot" or both, but all failed. When "--with-build-sysroot" is used, stage2 gcc failed when building internal binaries like genautomata, because it uses system version glibc and stage1 libstdc++. Apparently these two libraries are incompatible because stage1 libstdc++ is built against new glibc. When "--with-sysroot" is used, stage1 gcc failed when building libgcc, because it tried to find sysroot in build directory according to how sysroot is relocated in GCC. Apparently this doesn't exist because xgcc doesn't come from toolchain distribution. When "--with-sysroot" and "--with-build-sysroot" are used, stage2 GCC failed when configuring itself because some configuration check cannot find correct sysroot (standard headers like stdio.h). Seems to me Andrew was right in comment of PR69559, that we simply couldn't bootstrap GCC with sysroot. My question here is: If this is the case, how should I bootstrap a gcc against local version glibc, rather than the system one? Is chroot the only way to do that? Thanks, bin
Re: Help about how to bootstrap gcc with local version glibc other than system one
"Bin.Cheng" writes: > Seems to me Andrew was right in comment of PR69559, that we simply > couldn't bootstrap GCC with sysroot. The main use of sysroot is to build a cross compiler, which you cannot bootstrap anyway. > My question here is: If this is the case, how should I bootstrap a gcc > against local version glibc, rather than the system one? Is chroot > the only way to do that? Yes, building in a chroot or a VM is the best way to do it. For example, that's how the openSUSE Build Service works. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Help about how to bootstrap gcc with local version glibc other than system one
On Mon, Feb 1, 2016 at 6:08 PM, Andreas Schwab wrote: > "Bin.Cheng" writes: > >> Seems to me Andrew was right in comment of PR69559, that we simply >> couldn't bootstrap GCC with sysroot. > > The main use of sysroot is to build a cross compiler, which you cannot > bootstrap anyway. > >> My question here is: If this is the case, how should I bootstrap a gcc >> against local version glibc, rather than the system one? Is chroot >> the only way to do that? > > Yes, building in a chroot or a VM is the best way to do it. For > example, that's how the openSUSE Build Service works. Hi Andreas, Thanks very much for helping. I will try to do it in chroot. Thanks, Biin > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different."
Re: Help about how to bootstrap gcc with local version glibc other than system one
On 02/01/2016 12:07 PM, Bin.Cheng wrote: On Mon, Feb 1, 2016 at 6:08 PM, Andreas Schwab wrote: "Bin.Cheng" writes: Seems to me Andrew was right in comment of PR69559, that we simply couldn't bootstrap GCC with sysroot. The main use of sysroot is to build a cross compiler, which you cannot bootstrap anyway. My question here is: If this is the case, how should I bootstrap a gcc against local version glibc, rather than the system one? Is chroot the only way to do that? Yes, building in a chroot or a VM is the best way to do it. For example, that's how the openSUSE Build Service works. Hi Andreas, Thanks very much for helping. I will try to do it in chroot. Definitely what I'd recommend as well. We do this regularly with something called "mock" on Fedora. I'm sure SuSE, Debian, Ubuntu, etc have an equivalent. Essentially they create a chroot, populate it with build dependencies extracted from the source package, then build within the chroot. You can arrange to get a different glibc during instantiation of the chroot, or upgrade it after the chroot is fully instantiated. I'm sure there's a way to do this with containers too. jeff
Re: "cc" clobber
On 02/02/2016 01:58 AM, Ulrich Weigand wrote: I think on many targets a clobber "cc" works because the backend actually defines a register named "cc" to correspond to the flags. Therefore the normal handling of clobbering named hard registers catches this case as well. Yes. C.f. Sparc ADDITIONAL_REGISTER_NAMES. This doesn't work on i386 because there the flags register is called "flags" in the back end. Once upon a time i386 used cc0. A survey of existing asm showed that almost no one clobbered "cc", and that in the process of changing i386 from cc0 to an explicit flags register we would break almost everything that used asm. The only solution that scaled was to force a clobber of the flags register. That was 1999. I think you'll buy nothing but pain in trying to change this now. r~
Re: GCC-Bridge: A Gimple Compiler targeting the JVM
On 01/02/16 12:34, Bertram, Alexander wrote: I wanted to share a project we've been working on for sometime within the context of Renjin, a new interpreter for the R language running on the JVM. We basically needed a way to compile C and Fortran code to JVM classes, and for the last year or two we've been working on tool chain that's composed of a GCC plugin which dumps Gimple trees out to a JSON file, and a Java program which reads the JSON and compiles it to Java classfiles. This sounds interesting! (R is so slow) 1) Wouldn't it be better to directly compile to Java bytecode? I think GJC was able to do that in the past, but I'm not sure how bit-rotted that code is by now. https://gcc.gnu.org/ml/gcc/2000-02/msg00161.html It may be a more robust solution in the long run. 2) The reason that R uses so much C and Fortran code is because when compiled, that code is much faster than R. How much is lost by compiling and running in JVM? 3) Gimple is not completely target independent, but I think we would like to move towards that direction, so reporting bugs about that with specific testcases may be helpful. Of course, a JVM target would make this concern irrelevant. Anyway, using the GCC plugin interface has been terrific, and the gimple trees have been great to work with! Please, note that the plugin API is mainly driven by its users. If you want to see improvements, don't hesitate to propose patches. Cheers, Manuel.
Re: GCC-Bridge: A Gimple Compiler targeting the JVM
Thanks Mikhail and Manuel for the reactions! Mikhail, thanks for the tip on xmalloc, will take a look if that can help clean up the plugin code. Manuel, 0) Yes, we hope to make it faster! 1) Initially coding within GCC would have been too intimidating, but I think i've started to get a feel for the system and porting the compiler to some sort of C++ module might be a good long term to strategy to avoid drift as GCC internal evolve. I'm not sure exactly where it would fit in however- I don't think it could be described with the machine description language. There is alot of complexity involved in handling things like addressable local variables, which have to be allocated as unit length arrays so that we can pass around a reference to them. Would it be possible to write a backend that generates code from Gimple and not RTL? 2) I'm hoping we can get within 10-20% slowdown. However, the ultimate goal is to be include "native" code in Renjin's auto parallelization feature, which operates more on the level of aSQL query planner than at the instruction level, which would lead to a net speedup. That's the working hypothesis at least. I'm planning on doing a round of benchmarking in the next 1-2 months along with a comparison of the assembly generated by GCC on one hand for a given source, and the assembly ultimately generated by the JVM's JIT compiler. 3) Good to know! Is this right the mailing list to ask questions about some of the internal structure? The GCC Internals manual is very useful, and the source provides a lot of answers, but sometimes I run into questions, for example, on how exactly UNORDERED_EXPR is defined, or how to access the byte offset for COMPONENT_REF expression when field names vary. Best, Alex On Mon, Feb 1, 2016 at 10:25 PM, Manuel López-Ibáñez wrote: > On 01/02/16 12:34, Bertram, Alexander wrote: >> >> I wanted to share a project we've been working on for sometime within >> the context of Renjin, >> a new interpreter for the R language running on the JVM. >> >> We basically needed a way to compile C and Fortran code to JVM >> classes, and for the last year or two we've been working on tool chain >> that's composed of a GCC plugin which dumps Gimple trees out to a JSON >> file, and a Java program which reads the JSON and compiles it to Java >> classfiles. > > > This sounds interesting! (R is so slow) > > 1) Wouldn't it be better to directly compile to Java bytecode? I think GJC > was able to do that in the past, but I'm not sure how bit-rotted that code > is by now. https://gcc.gnu.org/ml/gcc/2000-02/msg00161.html It may be a more > robust solution in the long run. > > 2) The reason that R uses so much C and Fortran code is because when > compiled, that code is much faster than R. How much is lost by compiling and > running in JVM? > > 3) Gimple is not completely target independent, but I think we would like to > move towards that direction, so reporting bugs about that with specific > testcases may be helpful. Of course, a JVM target would make this concern > irrelevant. > >> Anyway, using the GCC plugin interface has been terrific, and the >> gimple trees have been great to work with! > > > Please, note that the plugin API is mainly driven by its users. If you want > to see improvements, don't hesitate to propose patches. > > Cheers, > > Manuel. > -- Alex Bertram Technical Director bedatadriven Web: http://bedatadriven.com Email: a...@bedatadriven.com Tel. Nederlands: +31(0)647205388 Skype: akbertram
Re: "cc" clobber
On 2/1/2016 6:58 AM, Ulrich Weigand wrote: I think on many targets a clobber "cc" works because the backend actually defines a register named "cc" to correspond to the flags. Therefore the normal handling of clobbering named hard registers catches this case as well. This doesn't work on i386 because there the flags register is called "flags" in the back end. Doh! Of course. This makes perfect sense. Thanks. dw
Re: "cc" clobber
On 2/1/2016 12:40 PM, Richard Henderson wrote:
On 02/02/2016 01:58 AM, Ulrich Weigand wrote:
I think on many targets a clobber "cc" works because the backend
actually defines a register named "cc" to correspond to the flags.
Therefore the normal handling of clobbering named hard registers
catches this case as well.
Yes. C.f. Sparc ADDITIONAL_REGISTER_NAMES.
This doesn't work on i386 because there the flags register is called
"flags" in the back end.
Once upon a time i386 used cc0. A survey of existing asm showed that
almost no one clobbered "cc", and that in the process of changing i386
from cc0 to an explicit flags register we would break almost
everything that used asm.
The only solution that scaled was to force a clobber of the flags
register.
That was 1999. I think you'll buy nothing but pain in trying to
change this now.
I expect you are right. After experimenting, the cases where this might
buy you any benefit are just too uncommon, and the 'benefit' is just too
small.
The one place where any of this would (sort of) be useful is checking
for the "cc" clobber conflicting with the output parameters. This
didn't used to be a thing, but now that i386 can 'output' flags, it is.
The compiler currently accepts both of these and they both produce the
same code:
asm("": "=@ccc"(x) : : );
asm("": "=@ccc"(x) : : "cc");
I assert (pr69095) that the second one should give an error (docs:
"Clobber descriptions may not in any way overlap with an input or output
operand"). Creating a check for this was more challenging than I
expected. I kept assuming that there 'had' to be existing code to
handle cc and I could tie into it if I could only figure out where it was.
But now that I have this written, I'm still vacillating about whether it
is useful. It seems like I could achieve the same result by adding
"Using @cc overrides the "cc" clobber" to the docs. But hey, it also
checks for duplicate "memory" and "cc" clobbers, so there's that...
dw
GCC compat testing and simulator question
I have a question about the compatibility tests (gcc.dg/compat and g++.dg/compat). Do they work with remote/simulator testing? I was trying to run them with qemu and even though I am setting ALT_CC_UNDER_TEST and ALT_CXX_UNDER_TEST it doesn't look like my alternative compiler is ever getting run. The README.compat file contains a line about 'make sure they work for testing with a simulator' does that mean they are known not to work with cross-testing and using a simulator? I don't get any errors or warnings, and tests are being compiled with GCC and run under qemu but it doesn't look like the second compiler is ever run to compile anything. I am using the multi-sim dejagnu board. Steve Ellcey sell...@imgtec.com
