Re: Requirements on Binutils and Linux kernel for GCC + Libsanitizer (was: Re: Bootstrap broken on x86_64 Linux?)
On Tue, Nov 12, 2013 at 11:52 AM, Jakub Jelinek wrote: > On Tue, Nov 12, 2013 at 11:34:41AM +0400, Kostya Serebryany wrote: >> On Sun, Nov 10, 2013 at 10:34 PM, FX 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 >> > >> > (It appears to be not only kernel, but binutils.) >> > >> > I think, at least the following should be done: >> > >> > - identify and document the minimal requirements >> > >> >> Agree. From our side we can only guarantee Ubuntu 12.04 and higher. > > For making sure libsanitizer at least compiles, just installing > /usr/include/ trees from a couple of important still supported distributions > from various eras and just using -isystem /path/to/distro1/usr/include/ as > additional (very quick) test of building the libraries on your bots > wouldn't be IMHO that difficult. Then we'll be getting complaints like 'this stuff compiles but doesn't work'. Still might be worth doing. Maybe we could create a wiki page somewhere describing the test process that everyone should follow when submitting changes to libsanitizer? --kcc
Re: [RFC] Replace Java with Go in default languages
> From what I can see, bootstrapping with Ada is slower than bootstapping > with Java, by around 15%. Again this is on one of my slower boxes, but > the results clearly show building Ada & its runtime takes a considerable > amount of time: > > default languages:67 minutes > default - java: 51 minutes > default - java + go: 56 minutes > default - java + ada: 77 minutes > > [...] > > Hard to justify switching from Java to Ada given those results if one of > the key goals is to reduce waiting time. The same discussion took place 3 years ago: http://gcc.gnu.org/ml/gcc/2010-10/msg00506.html with the Ada vs Java part: http://gcc.gnu.org/ml/gcc/2010-11/msg00451.html including some numbers: http://gcc.gnu.org/ml/gcc/2010-11/msg00452.html -- Eric Botcazou
Re: [RFC] Replace Java with Go in default languages
On 11/11/2013 09:27 PM, Matthias Klose wrote: > Am 11.11.2013 11:06, schrieb Andrew Haley: >> On 11/11/2013 03:22 AM, Jeff Law wrote: >>> 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 >> >> It's no different from porting GCC/libc. You have to write an >> assembler back end, the native parts of the runtime library, a >> bytecode interpreter, relocs for the runtime linker, and the compiler >> back end. Call it two programmer-years to get something decent >> working. >> >>> and is GCJ an integral part of that process. >> >> We have used GCJ in the past when porting OpenJDK because OpenJDK >> wasn't cross-compilable, but that's fixed now: we can cross-compile >> from a host which already has OpenJDK. So we don't need GCJ for that. > > that's only partly true. Sure, when using an unreleased OpenJDK snapshot > (leading to OpenJDK 8), then you are probably correct, however doing that for > a > released version of OpenJDK, it is still needed. Well, yes, but we're talking about legacy systems: for legacy OpenJDK you need legacy GCJ. There's no need for a new GCJ for porting new OpenJDK. Andrew.
Identifying compiler optimization to minimize energy consumption
Hi Everyone, The exploration of how compilation optimizations affect energy consumption of embedded devices has been written up and published. Full paper (open access) can be viewed here: http://comjnl.oxfordjournals.org/content/early/2013/11/11/comjnl.bxt129.abstract Thanks, James ABSTRACT === This paper presents an analysis of the energy consumption of an extensive number of the optimizations a modern compiler can perform. Using GCC as a test case, we evaluate a set of 10 carefully selected benchmarks for 5 different embedded platforms. A fractional factorial design is used to systematically explore the large optimization space (2^82 possible combinations), while still accurately determining the effects of optimizations and optimization combinations. Hardware power measurements on each platform are taken to ensure all architectural effects on the energy consumption are captured. We show that fractional factorial design can find more optimal combinations than relying on built-in compiler settings. We explore the relationship between run-time and energy consumption, and identify scenarios where they are and are not correlated. A further conclusion of this study is the structure of the benchmark has a larger effect than the hardware architecture on whether the optimization will be effective, and that no single optimization is universally beneficial for execution time or energy consumption.
Re: DWARF and atomic types
On Mon, 11 Nov 2013, Michael Eager wrote: > On 11/08/13 05:36, Joseph S. Myers wrote: > > I realised that the C11 atomics changes didn't do anything to record > > atomic types as such in DWARF debug info - then found that DWARF4 didn't > > provide a way to specify the C11 _Atomic qualifier at all. Could someone > > working with the DWARF committee get an appropriate tag into the next > > version of DWARF? > > > > (I've filed bug 59051 for the lack of use of DW_tag_restrict_type for > > restricted pointers.) > > Hi Joseph -- > > Can you go to http://dwarfstd.org/Comment.php and submit a description > of the change in C11 and a request that this be added. I've now done that. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Replace Java with Go in default languages
On 11/12/13 00:19, Eric Botcazou wrote: From what I can see, bootstrapping with Ada is slower than bootstapping with Java, by around 15%. Again this is on one of my slower boxes, but the results clearly show building Ada & its runtime takes a considerable amount of time: default languages:67 minutes default - java: 51 minutes default - java + go: 56 minutes default - java + ada: 77 minutes With what checking options? Weird, on my not so fast x86-64 machine, the 3rd item takes 40 min and the 4th 42 min with yes,rtl checking, so a difference of 21 min on yours is unexpected. I'm rerunning now. It's possible something was throwing jobs over to that machine -- I only reported the first run and stopped things as it looked pointless to continue. I won't have data until tomorrow :-) Jeff
Re: [RFC] Replace Java with Go in default languages
On 11/12/13 01:27, Eric Botcazou wrote: From what I can see, bootstrapping with Ada is slower than bootstapping with Java, by around 15%. Again this is on one of my slower boxes, but the results clearly show building Ada & its runtime takes a considerable amount of time: default languages:67 minutes default - java: 51 minutes default - java + go: 56 minutes default - java + ada: 77 minutes [...] Hard to justify switching from Java to Ada given those results if one of the key goals is to reduce waiting time. The same discussion took place 3 years ago: http://gcc.gnu.org/ml/gcc/2010-10/msg00506.html with the Ada vs Java part: http://gcc.gnu.org/ml/gcc/2010-11/msg00451.html including some numbers: http://gcc.gnu.org/ml/gcc/2010-11/msg00452.html :-) Thanks for the pointer, I vaguely recall that iteration of the discussion, but got lost following the 2008 thread. Jeff
Great example of why "everything is a tree" sucks
[rant] So I lost something like 3 hrs last night due to writing a hunk of code like this if (INTEGRAL_TYPE_P (gimple_assign_lhs (stmt))) With everything being a tree, the fact that I passed an SSA_NAME to INTEGRAL_TYPE_P rather than a tree type wasn't caught at compile time. Because this was guarding an optimization, it wasn't caught during a bootstrap -- in the particular context in which this occurred, a false result is always safe. It was only caught by a failure to optimize a particular test that I had tweaked with an earlier variant of the patch I was testing. So it wasn't until regression testing had completed and I looked at the results that there was any indication something was amiss. Could we fix this by adding more checking around INTEGRAL_TYPE_P? Sure and we'd probably trip the checker building the stage1 runtime or surely during the stage2 build for this particular instance. But fundamentally that's papering over the problem that I should not be able to do something stupid like that in the first place! We're using a language that has a type system that can easily express that what I wrote as utterly stupid and wrong. But our "everything is tree" model gets in the damn way. In a lot of ways the arguments against fixing this problem remind me of the nonsense we had to go through to stop shoving random pointers & integers into trees 18 years ago. If a field is a tree, then shoving an rtx or some 32 bit integer into the field is just stupid. We all take that for granted now, but it was fairly standard practice a long time ago. Fixing that was a necessary prerequisite for many of the things we now take for granted -- function as trees, inlining with trees, garbage collection, ssa, gimple, etc. It's time to move on and do something sensible with the core parts of our ILs so that we're all more effective in the long run. [/rant] Jeff
Re: Great example of why "everything is a tree" sucks
On Tue, Nov 12, 2013 at 2:59 PM, Jeff Law wrote: > It's time to move on and do something sensible with the core parts of our > ILs so that we're all more effective in the long run. My sentiments, exactly! Diego.
Re: Great example of why "everything is a tree" sucks
On Tue, Nov 12, 2013 at 12:59:47PM -0700, Jeff Law wrote: > So I lost something like 3 hrs last night due to writing a hunk of > code like this > > if (INTEGRAL_TYPE_P (gimple_assign_lhs (stmt))) INTEGRAL_TYPE_P is a macro, which accepts everything, just adding a TYPE_CHECK to that macro would be sufficient to catch that (but of course could break various parts of GCC, so if you wanted to change the representation of types from tree to tree_type or something similar, the addition of the TYPE_CHECK would be probably first step towards that). Note that we have tons of code which accept either objects or types, both in the frontends and in the middle-end, so changing TREE_TYPE from tree to something else is definitely non-trivial. Jakub
Re: Great example of why "everything is a tree" sucks
On Tue, Nov 12, 2013 at 3:35 PM, Jakub Jelinek wrote: > Note that we have tons of code which accept either objects or types, > both in the frontends and in the middle-end, so changing TREE_TYPE > from tree to something else is definitely non-trivial. Well, sure it's hard. This is the whole point behind Andrew's refactoring project: setting up the groundwork for this kind of conversion to be possible. The software engineering atrocities that we have committed in the code base are going to take a few iterations to fix. But fix them, we must. I am convinced that this is the only way for GCC to avoid untimely oblivion; and allow it to evolve in ways that are now hard or impossible to implement. Diego.
Re: Great example of why "everything is a tree" sucks
The name David Malcolm comes to mind, I remember watching a GCC ... bucket, tub, some sort of large container (pot?) talk on it. He was replacing all the macros with a class with no virtuals (only one data member, as used by the macros in effect) and so forth and using inheritance, doesn't that solve this? (or "wont that solve this?" <--future tense) C++11 has a lot of great things (like std::is_base_of and std::remove_pointer in type_traits) that help with this, I'm pretty sure these came from Boost, most good things come from Boost (read: I am certain they came from Boost and that Boost lets us do them, but it's been so long I couldn't tell you exactly how without reading documentation again). If C++11 stuff can't be used (I'm not saying we should, just observing, I agree that fairly old compilers should be able to build GCC) can't we just use what Boost does? I never spend much time looking but Boost does say which versions of what compilers are supported. If they can do it surely we can? This would allow some pretty solid compile time checks to be introduced I would have thought? Alec On 12/11/13 20:52, Diego Novillo wrote: On Tue, Nov 12, 2013 at 3:35 PM, Jakub Jelinek wrote: Note that we have tons of code which accept either objects or types, both in the frontends and in the middle-end, so changing TREE_TYPE from tree to something else is definitely non-trivial. Well, sure it's hard. This is the whole point behind Andrew's refactoring project: setting up the groundwork for this kind of conversion to be possible. The software engineering atrocities that we have committed in the code base are going to take a few iterations to fix. But fix them, we must. I am convinced that this is the only way for GCC to avoid untimely oblivion; and allow it to evolve in ways that are now hard or impossible to implement. Diego.
Re: Great example of why "everything is a tree" sucks
On 11/12/13 13:35, Jakub Jelinek wrote: On Tue, Nov 12, 2013 at 12:59:47PM -0700, Jeff Law wrote: So I lost something like 3 hrs last night due to writing a hunk of code like this if (INTEGRAL_TYPE_P (gimple_assign_lhs (stmt))) INTEGRAL_TYPE_P is a macro, which accepts everything, just adding a TYPE_CHECK to that macro would be sufficient to catch that Yes, I know full well that I could hack up INTEGRAL_TYPE_P to detect this case and my brain damage would have been caught via the check sometime during building the runtime libraries or the stage2 build. My point is the mere need to hack up INTEGRAL_TYPE_P in that way is a result of a fundamental misdesign of the tree structures. If the structures were properly designed what I did would have been flagged as a compile error. It's that fundamental mis-design that we're trying to correct now with the work from Andrew, David & others. Jeff
Re: Great example of why "everything is a tree" sucks
On 11/12/13 14:19, Alec Teal wrote: The name David Malcolm comes to mind, I remember watching a GCC ... bucket, tub, some sort of large container (pot?) talk on it. He was replacing all the macros with a class with no virtuals (only one data member, as used by the macros in effect) and so forth and using inheritance, doesn't that solve this? (or "wont that solve this?" <--future tense) Yup. My rant was to show a very clear, current, example of the kind of things that we're looking to fix with Andrew & David's work on our core data structures. Jeff
Fwd: Macros taking a function as argument - and evaluating it at least twice
[Sorry for double post - gmail insists that "GCC" is gcc-patches@, not gcc@ :-/ ] Hello, Here is a non-comprehensive list of macros that are used with a function passed to the macro's argument, and the macro evaluates that argument at least twice: gimple.c: && (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (gs)) gimple-ssa-strength-reduction.c: || !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (gs))) ipa-prop.c: && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def))) tree-inline.c:|| CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt))); tree-ssa-dom.c: && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (defstmt))) tree-ssa-forwprop.c: if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt))) tree-ssa-forwprop.c: || !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt))) tree-ssa-ifcombine.c: && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt))) tree-ssa-ifcombine.c:&& ((CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt)) tree-ssa-loop-im.c: if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt1))) tree-stdarg.c:|| CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt)) tree-vect-patterns.c: if (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (*def_stmt))) tree-vect-patterns.c: if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (use_stmt))) tree-vect-patterns.c: && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (use_stmt)) tree-vrp.c: if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)) tree-vrp.c: if (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt2)) tree-vrp.c: else if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (op_def))) tree-vrp.c: || !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt2)) tree-vrp.c: || !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt))) tree-vrp.c: || !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt))) tree-outof-ssa.c: && FLOAT_TYPE_P (gimple_expr_type (stmt))) tree-ssa-ccp.c: && (INTEGRAL_TYPE_P (gimple_expr_type (stmt)) tree-chrec.c: if (POINTER_TYPE_P (chrec_type (poly0))) tree-chrec.c: if (POINTER_TYPE_P (chrec_type (chrec))) tree-ssa-ccp.c: || POINTER_TYPE_P (gimple_expr_type (stmt tree-ssa-structalias.c: && !(POINTER_TYPE_P (gimple_expr_type (t)) Not sure what to do about them (if anything) but I don't think this is intended... Ciao! Steven
Re: [RFC] Replace Java with Go in default languages
On 11/12/13 01:27, Eric Botcazou wrote: From what I can see, bootstrapping with Ada is slower than bootstapping with Java, by around 15%. Again this is on one of my slower boxes, but the results clearly show building Ada & its runtime takes a considerable amount of time: default languages:67 minutes default - java: 51 minutes default - java + go: 56 minutes default - java + ada: 77 minutes [...] Hard to justify switching from Java to Ada given those results if one of the key goals is to reduce waiting time. Not sure what happened yesterday with the 77 minute timing. Across 10 runs we came in right at 70 minutes with the usual ~20 second variance. So it's slightly slower than the default languages right now. That doesn't help the cycle time for developers which was the major point for me. Given the problems Ian outlined around adding Go to the default languages and the build time issues with using Ada instead of Java, I'm unsure how best to proceed. I'm starting to wonder if we just remove Java from the default languages during stage1, but add it back when we leave stage1. Similarly I think we should add Go to the default languages when we leave stage1. As for Ada, I'm wondering if we should add it into the default languages, but not require it for the bootstrap/regression test cycle during stage1, but require it as we leave stage1. Thus, if a developer has Ada installed, it'll build & test by default. And, yes I'm aware of the wonderful irony that I'm debugging a bootstrap problem with Ada related to my recent work :-) Thoughts on the updated proposal? jeff
