Requirements on Binutils and Linux kernel for GCC + Libsanitizer (was: Re: Bootstrap broken on x86_64 Linux?)
FX wrote: I’m building with binutils 2.17.50.0.6, which is a bit old but I cannot find any mention of needing later binutils on the installation notes. Is bootstrap broken, or am I missing something? Second build, this time with trunk binutils. Still fails in libsanitizer at stage1, this time with: ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:25:30: fatal error: linux/perf_event.h: No such file or directory I run a Linux 2.6.18, with kernel headers installed. Are there stricter requirements on the linux version in GCC? Where is it documented? I don’t remember that bootstraping used to be so hard :( In principle, you could try --disable-libsanitizer --disable-target-libsanitizer but I am not sure whether that works, a fortnight ago, Janne remarked at #gcc that it didn't seem to work – maybe you have more luck. Your Linux 2.6.18 is already quite old (September 2007) thus I wouldn't be surprised that that's the reason. According to https://github.com/torvalds/linux/commit/cdd6c482c9ff9c55475ee7392ec8f672eddb7be6 , the file "perf_event.h" was renamed from "perf_counter.h" in September 2009 (2.6.32?). Regarding Binutils: "GNU binutils – Necessary in some circumstances, optional in others. See the host/target specific instructions for your platform for the exact requirements." Thus, that's kind of documented at http://gcc.gnu.org/install/prerequisites.html – even if it is not that helpful. – I don't know how old your binutils were. Actually, gcc20 (Debian 6/Squeeze) of the compile farm has Linux kernel 2.6.32, binutils 2.20.1 and glibc 2.11.3; those seem to be (just) sufficient. Tobias
Re: [RFC] Replace Java with Go in default languages
Eric Botcazou wrote: >> Right now Go does not build on a range of targets, notably including >> Windows, MacOS, AIX, and most embedded systems. We would have to >> disable it by default on targets that are not supported, which is >> straightforward (we already have rules to disable java on targets it >> does not support). But to the extent that there are options like >> -fnon-call-exceptions that are tested primarily by Java and Go, we >> would get less coverage of those options, since we would not test >them >> on systems that Java supports but Go does not. > >Let me make the case for Ada here: it's a general purpose, highly >portable >language, which is regularly built and tested on a significant range of > >platforms (I personally test it on x86/Linux, x86-64/Linux, >PowerPC/Linux, >IA-64/Linux, SPARC/Solaris and SPARC64/Solaris). It exercices some >features >of the compiler that aren't exercised by other languages and stretches >some >common features much more than the other languages. It turns out that >it also >enables -fnon-call-exceptions by default. It seamlessly works with >LTO. > >While the fact that a big part of the front-end is written in Ada could >be >seen as an annoyance (although GNAT has been largely available for >about a >decade on many systems), it can also be seen a boon; for example, a LTO > >bootstrap with Ada enabled really exercises cross-language >optimizations. > >Bootstrapping with Ada is marginally slower than with Go (a few >percents) and >the testsuite is small (4-way parallelizable, testing time of 6 minutes >on a >fast machine). > >> More seriously, the Go sources live in a separate repository, and are >> copied to the GCC repo. In practice this means that when Go breaks, >> it can't be fixed until I am online to fix it. I don't think it >would >> be good for GCC for a bootstrap break to depend on me. > >In contrast to that, the FSF repository is the master repository for >GNAT and >breakages can be quickly fixed by anyone with write access. I agree that testing ADA is much more useful than GO. It uses a much more interesting set of middle-end features. Oh, can we consider dropping java alltogether please? Richard.
Re: Requirements on Binutils and Linux kernel for GCC + Libsanitizer (was: Re: Bootstrap broken on x86_64 Linux?)
> In principle, you could try --disable-libsanitizer > --disable-target-libsanitizer but I am not sure whether that works, a > fortnight ago, Janne remarked at #gcc that it didn't seem to work – maybe you > have more luck. > > Your Linux 2.6.18 is already quite old (September 2007) thus I wouldn't be > surprised that that's the reason. According to > https://github.com/torvalds/linux/commit/cdd6c482c9ff9c55475ee7392ec8f672eddb7be6 > , the file "perf_event.h" was renamed from "perf_counter.h" in September > 2009 (2.6.32?). > > Regarding Binutils: "GNU binutils – Necessary in some circumstances, optional > in others. See the host/target specific instructions for your platform for > the exact requirements." Thus, that's kind of documented at > http://gcc.gnu.org/install/prerequisites.html – even if it is not that > helpful. – I don't know how old your binutils were. That’s not documented at all. I have read the host/target specific instructions, but there is no mention of a minimal binutils and/or Linux kernel versions for Linux targets or x86-linux or x86_64-linux. Not a word. I don’t like that building GCC has such strict dependencies on kernels/binutils/whatever versions. E.g., Linux 2.6.18 is the kernel in Redhat’s RHEL 5, which is still sold and supported. But that’s only my opinion. However, the fact that it is not tested/detected at compile-time is uncool. The fact that it is not documented is, plain and simple, bad behavior. FX
Mobail colling
Sent from my Nokia phone
Question about overloaded operators
Hello Everyone, In C++, when a binary/unary operator is overloaded, then the build_x_[binary/unary]_op replaces it with a call expression. Is there a way to know from the call expression (assume we are in the gimplification stage) what the operator is? I tried to look around but I didn't find any obvious way to figure this info out. Thanks, Balaji V. Iyer.
Re: Requirements on Binutils and Linux kernel for GCC + Libsanitizer (was: Re: Bootstrap broken on x86_64 Linux?)
[resending text-only] On Sun, Nov 10, 2013 at 8:51 AM, Konstantin Serebryany wrote: > Unfortunately, we are not able to keep up with the old kernels. > Two possible ways to go: > - disable libsanitizer on older kernels > - someone needs to work with us in upstream repository (llvm) to keep the > code old-kernel-compatible
Re: Requirements on Binutils and Linux kernel for GCC + Libsanitizer (was: Re: Bootstrap broken on x86_64 Linux?)
> Unfortunately, we are not able to keep up with the old kernels. > Two possible ways to go: > - disable libsanitizer on older kernels > - someone needs to work with us in upstream repository (llvm) to keep the > code old-kernel-compatible (It appears to be not only kernel, but binutils.) I think, at least the following should be done: - identify and document the minimal requirements - test for necessary features at compilation time (we have full autoconf, presence of crucial headers should be tested) and issue a meaningful error message if they are not found - ideally, but I know it is more work: disable libsanitizer automatically from toplevel configure if requirements are not met This is what is done for dependencies of all default parts of the compiler, as far as I can tell. FX
Re: Question about overloaded operators
On 11/10/2013 11:08 AM, Iyer, Balaji V wrote: In C++, when a binary/unary operator is overloaded, then the build_x_[binary/unary]_op replaces it with a call expression. Is there a way to know from the call expression (assume we are in the gimplification stage) what the operator is? I tried to look around but I didn't find any obvious way to figure this info out. Not a simple one. You might factor out the code for that in write_unqualified_id into a separate function. Jason
Re: [RFC] Replace Java with Go in default languages
* Richard Biener: > Oh, can we consider dropping java alltogether please? At least we could remove all those pregenerated files.
RE: Question about overloaded operators
> -Original Message- > From: Jason Merrill [mailto:ja...@redhat.com] > Sent: Sunday, November 10, 2013 1:55 PM > To: Iyer, Balaji V; gcc@gcc.gnu.org > Subject: Re: Question about overloaded operators > > On 11/10/2013 11:08 AM, Iyer, Balaji V wrote: > > In C++, when a binary/unary operator is overloaded, then the > build_x_[binary/unary]_op replaces it with a call expression. Is there a way > to know from the call expression (assume we are in the gimplification stage) > what the operator is? I tried to look around but I didn't find any obvious way > to figure this info out. > > Not a simple one. You might factor out the code for that in > write_unqualified_id into a separate function. > Semi crazy thought...If I do something like a string compare for the operation after operator toward the end of the function, will I get what I want? I guess another way to ask this is, will a '+' operation, for example, be mapped to a function ending in something other than "operator+" > Jason
Re: [RFC] Replace Java with Go in default languages
On 11/09/13 08:44, Alec Teal wrote: If Java must go, and it must have a replacement Ada makes sense. The issues with Go (sadly, you guys are doing superb work) do make sense. I don't know enough about Java (the GCC front end and such) to know if it should go, if it does go why should it be replaced? What we're trying to balance is developer time vs benefit of the language. I'm of the opinion that GCJ's importance continues to diminish across multiple axis and that we probably past the point where it's still worth our developer's time to continue to build/test it for every submitted patch. I originally liked Go as a replacement as it tests certain codepaths that are currently only tested by the GCJ frontend. However, it's looking like Ada might be a better choice. jeff
Re: [RFC] Replace Java with Go in default languages
On 11/09/13 08:55, Andrew Haley wrote: On 11/09/2013 03:44 PM, Alec Teal wrote: If Java must go, and it must have a replacement Ada makes sense. The issues with Go (sadly, you guys are doing superb work) do make sense. I don't know enough about Java (the GCC front end and such) to know if it should go, if it does go why should it be replaced? It always was very useful for detecting bugs in GCC: the code flow tends to trigger bugs that don't get detected by the usual GCC testsuites. That's certaily been the case in the past, but I'm seeing less and less of that now. If we can get coverage of the non-call-exceptions paths and cut 15% off the build/test cycle, then I think it's worth it. I'd even be willing to explicitly make this a trial and reinstate GCJ if we find that GCJ is catching problems not caught by the existing default language & runtime systems. Andrew -- my big question is what's the state of OpenJDK for other architectures. The most obvious being ARM(64), but in general, what's the process for bootstrapping OpenJDK on a new target and is GCJ an integral part of that process. jeff
Re: [RFC] Replace Java with Go in default languages
On 11/09/13 04:12, Eric Botcazou wrote: Right now Go does not build on a range of targets, notably including Windows, MacOS, AIX, and most embedded systems. We would have to disable it by default on targets that are not supported, which is straightforward (we already have rules to disable java on targets it does not support). But to the extent that there are options like -fnon-call-exceptions that are tested primarily by Java and Go, we would get less coverage of those options, since we would not test them on systems that Java supports but Go does not. Let me make the case for Ada here: it's a general purpose, highly portable language, which is regularly built and tested on a significant range of platforms (I personally test it on x86/Linux, x86-64/Linux, PowerPC/Linux, IA-64/Linux, SPARC/Solaris and SPARC64/Solaris). It exercices some features of the compiler that aren't exercised by other languages and stretches some common features much more than the other languages. It turns out that it also enables -fnon-call-exceptions by default. It seamlessly works with LTO. I'd kindof always dismissed Ada because it was so slow in the past and the need for an installed Ada front-end. Note the "slow" was back in the mid 90s last time I looked at it :-0 I haven't compared it to GCJ or anything like that, but that's certainly easily accomplished. At least for Linux systems, the bootstrapping problem is largely a solved problem by the major vendors. Let me run some tests, this may be a better alternative. jeff
