Re: Struct declaration and initialization in TREES
On December 17, 2019 8:31:00 PM GMT+01:00, Erick Ochoa
wrote:
>Hi,
>
>I'm interested in printing VAR_DECL trees that are of type
>RECORD_TYPE. I am using the function print_generic_decl
>for debugging and found this interesting behaviour.
>
>When I do initialization of structs using the following
>syntax:
>
>```
>struct aStruct { _Bool e; int a; char b; float c; double d; _Bool f;
>long h;};
>struct aStruct astruct = { .e = 0, .a = 1, .b = 2, .c = 3.0, .d = 4.0,
>.f = 5, .h = 6 };
>```
>
>print_generic_decl will print the following output:
>
>```
>INTERESTED IN: static struct aStruct astruct = <<< error >>>;
>```
>
>Am I using the correct API? Is this a limitation of the API?
You need to ask IPA about the static initializer, DECL_INITIAL is adjusted at
some point.
Richard.
>Would people be interested in me extending this API to print
>out something more useful? I already have some code that
>iterates over fields and prints out names and types. It
>can still use some work though.
>
>However, I understand if this is the intended behaviour.
>Another question (related to the possibility of intended behaviour)
>is: how is struct initialization represented in trees?
>(I.e. will each field be initialized separately or something else
>happens?)
>
>Thanks! I also include the patch in case people want a simple
>working example on how to print declarations.
>
>diff --git a/gcc/Makefile.in b/gcc/Makefile.in
>index 6b857bd..f4f1376 100644
>--- a/gcc/Makefile.in
>+++ b/gcc/Makefile.in
>@@ -1368,6 +1368,7 @@ OBJS = \
> incpath.o \
> init-regs.o \
> internal-fn.o \
>+ ipa-hello-world.o \
> ipa-cp.o \
> ipa-sra.o \
> ipa-devirt.o \
>diff --git a/gcc/common.opt b/gcc/common.opt
>index b4dc31c..304ec9f 100644
>--- a/gcc/common.opt
>+++ b/gcc/common.opt
>@@ -3348,4 +3348,7 @@ fipa-ra
> Common Report Var(flag_ipa_ra) Optimization
> Use caller save register across calls if possible.
>
>+fipa-typelist
>+Common Report Var(flag_ipa_typelist) TBD
>+
> ; This comment is to ensure we retain the blank line above.
>diff --git a/gcc/ipa-hello-world.c b/gcc/ipa-hello-world.c
>new file mode 100644
>index 000..ed4ae11
>--- /dev/null
>+++ b/gcc/ipa-hello-world.c
>@@ -0,0 +1,78 @@
>+#include "config.h"
>+#include "system.h"
>+#include "coretypes.h"
>+#include "backend.h"
>+#include "tree.h"
>+#include "gimple-expr.h"
>+#include "predict.h"
>+#include "alloc-pool.h"
>+#include "tree-pass.h"
>+#include "cgraph.h"
>+#include "diagnostic.h"
>+#include "fold-const.h"
>+#include "gimple-fold.h"
>+#include "symbol-summary.h"
>+#include "tree-vrp.h"
>+#include "ipa-prop.h"
>+#include "tree-pretty-print.h"
>+#include "tree-inline.h"
>+#include "ipa-fnsummary.h"
>+#include "ipa-utils.h"
>+#include "tree-ssa-ccp.h"
>+#include "stringpool.h"
>+#include "attribs.h"
>+
>+
>+static unsigned int
>+iphw_execute()
>+{
>+ if (!dump_file) return 0;
>+ varpool_node *node;
>+ FOR_EACH_VARIABLE(node)
>+ {
>+gcc_assert(node->decl);
>+tree decl = node->decl;
>+gcc_assert(TREE_CODE(decl) == VAR_DECL);
>+
>+tree curr_type = TREE_TYPE(decl);
>+gcc_assert(curr_type);
>+
>+const bool is_struct = TREE_CODE(curr_type) == RECORD_TYPE;
>+if (is_struct) fprintf(dump_file, "INTERESTED IN: ");
>+print_generic_decl(dump_file, decl, TDF_DETAILS);
>+fprintf(dump_file, "\n");
>+ }
>+ return 0;
>+}
>+
>+namespace {
>+const pass_data pass_data_ipa_hello_world =
>+{
>+ SIMPLE_IPA_PASS,
>+ "hello_world",
>+ OPTGROUP_NONE,
>+ TV_NONE,
>+ (PROP_cfg | PROP_ssa),
>+ 0,
>+ 0,
>+ 0,
>+ 0,
>+};
>+
>+class pass_ipa_hello_world : public simple_ipa_opt_pass
>+{
>+public:
>+ pass_ipa_hello_world (gcc::context *ctx)
>+: simple_ipa_opt_pass(pass_data_ipa_hello_world, ctx)
>+ {}
>+
>+ virtual bool gate(function*) { return flag_ipa_typelist; }
>+ virtual unsigned execute (function*) { return iphw_execute(); }
>+};
>+} // anon namespace
>+
>+simple_ipa_opt_pass*
>+make_pass_ipa_hello_world (gcc::context *ctx)
>+{
>+ return new pass_ipa_hello_world (ctx);
>+}
>diff --git a/gcc/passes.def b/gcc/passes.def
>index 798a391..52cd14b 100644
>--- a/gcc/passes.def
>+++ b/gcc/passes.def
>@@ -146,6 +146,7 @@ along with GCC; see the file COPYING3. If not see
> NEXT_PASS (pass_ipa_profile);
> NEXT_PASS (pass_ipa_icf);
> NEXT_PASS (pass_ipa_devirt);
>+ NEXT_PASS (pass_ipa_hello_world);
> NEXT_PASS (pass_ipa_cp);
> NEXT_PASS (pass_ipa_sra);
> NEXT_PASS (pass_ipa_cdtor_merge);
>diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
>index a987661..915fc69 100644
>--- a/gcc/tree-pass.h
>+++ b/gcc/tree-pass.h
>@@ -498,6 +498,7 @@ extern ipa_opt_pass_d *make_pass_ipa_fn_summary
>(gcc::context *ctxt);
> extern ipa_opt_pass_d *make_pass_ipa_inline (gcc::context *ctxt);
>extern simple_ipa_opt_pass *make_pass_ipa_free_lang_data (gcc::context
>*ctxt);
>extern simple_ipa_opt_pass *make_pass_ipa_free_fn_summary (gcc::context
>*ctxt);
>+extern simple_ipa_opt_pass *make_pass_ipa_hello_world (gcc::context
>*ct
Re: Test GCC conversion with reposurgeon available
On Tue, Dec 17, 2019 at 4:39 PM Joseph Myers wrote: > Points for consideration: > > 1. Do we want some kind of rearrangement of refs as in the 1b > repository or not? > Maybe? How much space does that save in a clone? How much work does a partial clone add on the server, since the server needs to pack up the objects for the partial clone rather than just transmitting its own packs? > 2. Should the final converted repository contain refs/deleted/ refs or > not? > I think not. > 3. Where an attribution comes from an author map rather than a > ChangeLog file, do we wish to use the existing author map or do people > prefer using names from that map but with @gcc.gnu.org addresses (and > @gnu.org for usernames that only committed in the gcc2 period)? > I lean toward the latter. Jason
Your request is being processed
Hi You could have the last payment in your personal account. You need to address this instantly or it will be deleted. Go Here To Verify Your Payment Data Is Correct. Customer email: g...@gnu.org User ID: TQNLMFJOC9 Enjoy & please let me know how you do. Thank you! Cortez E Marketer 202 Lower High Street Watford WD17 2EH United Kingdom You received this email because you are registered with P Marketer. Unsubscribe here volume jail
Re: Test GCC conversion with reposurgeon available
On Wed, 18 Dec 2019, Joseph Myers wrote: > On Wed, 18 Dec 2019, Joseph Myers wrote: > > > On Wed, 18 Dec 2019, Bernd Schmidt wrote: > > > > > On 12/17/19 10:32 PM, Joseph Myers wrote: > > > > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git > > > > > > It seems that permission bits are not reproduced entirely correctly. For > > > example, contrib/check_GNU_style_lib.py went from -rwxr-xr-x in svn (and > > > the > > > git-svn repository) to -rw-r--r-- in this new git repository. > > > > Thanks, I've reduced this to a minimal test for Eric, so hopefully it > > should be resolved soon. > > I believe I have a fix for this; I'm now running a full GCC conversion > with that fix (and with some fixes related to merge commits). The full validation of all branch tips and tags is still running, but I've confirmed that this conversion now has execute permissions on master exactly the same as in SVN trunk, that the spurious merges I previously saw have disappeared and that .cvsignore now appears in the history as requested. I'll upload new repository conversions later today. -- Joseph S. Myers jos...@codesourcery.com
Re: Code bloat due to silly IRA cost model?
Hi Richard, On Fri, Dec 13, 2019 at 10:31:54PM +, Richard Sandiford wrote: > >> I didn't say it was combine's fault that RA was bad. I said it was > >> combine's fault that we have two pseudos rather than one. See below. > My point was the extra pseudo<-pseudo2 move is created by combine for > its own internal purposes And my point is that it is *not* internal purposes :-) This is done because we no longer combine with the hard register, but combining with just a register move is quite beneficial for many targets. We could (and probably should) do a 1->1 combine first, i.e. just simplification for every single insn, but that causes other problems right now. GCC 11, I hope. What happens is we have this: insn_cost 4 for14: r44:SF=r22:SF REG_DEAD r22:SF insn_cost 4 for 2: r43:SF=r44:SF REG_DEAD r44:SF insn_cost 4 for 6: r22:SF=r43:SF REG_DEAD r43:SF insn_cost 0 for 7: r22:SF=call [`g'] argc:0 REG_CALL_DECL `g' (where insn 14 and r44 are created by make_more_copies). Now, insn 14 would normally be combined into insn 2. But this doesn't happen because the target prohibits it, with the targetm.class_likely_spilled_p in cant_combine_insn_p. I wonder if we still need that at all? Segher
Re: Code bloat due to silly IRA cost model?
Segher Boessenkool writes: >> My point was the extra pseudo<-pseudo2 move is created by combine for >> its own internal purposes > > And my point is that it is *not* internal purposes :-) This is done > because we no longer combine with the hard register, but combining with > just a register move is quite beneficial for many targets. But that's what I meant by "its own internal purposes". It's something one part of combine does to make other parts of combine work better. Richard
Re: Errors building libgcc for powerpc64le-linux-gnu
On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote: > On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool > wrote: > > > > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote: > > > I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu, > > > cross-compiling from x86_64-pc-linux-gnu. I'm at SVN revision 279830. > > > I'm seeing the following. Is anybody else seeing this crash? Thanks. > > > > No, and that makes me wonder what is going on. The error is simple enough > > of course, as you note in a later message; but why do we not see it on > > every other build? > > I think it's because clang treats a left shift by a negative number as > undefined behavior but GCC does not. So GCC is consistently producing > some number, and clang is producing different numbers. > > I should note that I don't really understand what purpose that > constant is serving anyhow. It's the (old, changed months ago!) register number for CR7. This code creates the bitfield that says which CR fields to save or restore. Anyway, should be fixed now. If you can confirm, please do :-) Segher
Options disabled under -Os
Hello, In GCC documentation, 3.1 Options that Control Optimization: it is indicated -Os disables alignment of functions, jumps, labels, and loops. However, with -v -Q passed to the compile step, I see all these options enabled under -Os. Is this intended behavior, therefore a documentation bug? I have tried this with GCC4.4.7 and GCC8.3.1 Thanks, Visda
Re: PPC64 libmvec implementation of sincos
‐‐‐ Original Message ‐‐‐ On Monday, December 9, 2019 3:39 AM, Richard Biener wrote: > You don't want to do it this way but map _Complex double to a vector > of 2 * n doubles instead. > Look into get_related_vectype_for_scalar_type where it alreday has > code to "change" the > scalar type into something that fits what we allow for vectors. > > Richard. I'm a little farther along. I'm comparing a compilation that calls sine in a loop, and is successfully vectorized, to a compilation calling sincos in a loop and for which vectorization fails. The earliest difference between the two now is that vectorizing sine returns true in the call to vectorizable_simd_clone_call but is false for vectorizing sincos. My understanding is that sine is known to be vectorizable because there is a vector sine prototype in GLIBC's math-vector.h. In which director(y|ies) do declaration and definition of a vector version of built-in cexpi go? Bert.
Re: Proposal for the transition timetable for the move to GIT
On Mon, Dec 16, 2019 at 06:19:26PM -0500, Eric S. Raymond wrote: > Segher Boessenkool : > > There is absolutely no reason to trust a system that supposedly was > > already very mature, but that required lots of complex modifications, > > and even a complete rewrite in a different language, that even has its > > own bug tracker, to work without problems (although we all have *seen* > > some of its many problems over the last years), and at the same time > > bad-mouthing simple scripts that simply work, and have simple problems. > > Some factual corrections: > > I didn't port to Go to fix bugs, I ported for better performance. That is not a correction, because that is not what I said. > I very carefully *didn't* bad-mouth Maxim's scripts - in facrt I have > said on-list that I think his approach is on the whole pretty > intelligent. To anyone who didn't have some of the experiences I have > had, even using git-svn to analyze basic blocks would appear > reasonable and I don't actually fault Maxim for it. And yet, you do it once again now. Judge the conversion candidates by what they are, not by if the tool to create them is named "reposurgeon" or not. > I *did* bad-mouth git-svn - and I will continue to do so until it no > longer troubles the world with botched conversions. Relying on it is, > in my subject-matter-expert opinion, unacceptably risky. While I don't > blame Maxim for not being aware of this, it remains a serious > vulnerability in his pipeline. More unfounded aspersions. Yay. > I don't know how it is on your planet, but here on Earth having a > bug tracker - and keeping it reasonably clean - is generally > considered a sign of responsible maintainership. Having a bugtracker is a sign of having more bugs than you can count on one hand. > In conclusion, I'm happy that you're so concerned about bugs in > reposurgeon. I am concerned if the conversion we eeventually select will be usable for our purposes. And I am concerned it will take some more years. Segher
Re: Proposal for the transition timetable for the move to GIT
On Mon, 2019-12-16 at 16:42 -0600, Segher Boessenkool wrote: > Hi! > > On Mon, Dec 16, 2019 at 03:13:49PM -0700, Jeff Law wrote: > > On Mon, 2019-12-16 at 15:59 -0600, Segher Boessenkool wrote: > > > In particular, we should look carefully at the commit > > > > attributions in both conversions and Maxim's may well give ideas for > > > > improving the reposurgeon changelogs command (Richard came up with > > > > three > > > > ideas recently, which I've just filed in the reposurgeon issue > > > > tracker). > > > > But I also think: > > > > > > > > * reposurgeon is a safer approach than ad hoc scripts, provided we get > > > > clean verification of basic properties such as branch tip contents. > > > > > > I totally do not agree. Black boxes are not safe. *New* black boxes > > > are even worse. > > > > > > I trust scripts that have low internal complexity much better. > > Perhaps. But there's also limits to what scripts can do. > > Absolutely. Just this trust in complicated things is very misplaced, in > my opinion. It's as much about trusting the people as much as the tools. While I don't have the opportunity to work with Joseph all that much, I have seen his work and attention to detail for 20+ years. When he says that, in his opinion, the reposurgeon conversion is already a better conversion than Maxim's conversion, I absolutely trust him. Furthermore I trust that if there are significant issues that he'll engaged to fix them. > > > There is absolutely no reason to trust a system that supposedly was > > > already very mature, but that required lots of complex modifications, > > > and even a complete rewrite in a different language, that even has its > > > own bug tracker, to work without problems (although we all have *seen* > > > some of its many problems over the last years), and at the same time > > > bad-mouthing simple scripts that simply work, and have simple problems. > > I'd disagree. THe experience and testsuites from that system are a > > significant benefit. > > That isn't what I said. I said that freshly constructed complex software > will have more and deeper errors than stupid simple scripts do (or I > implied that at least, maybe it wasn't clear). And I only say this > because the opposite was claimed, which is laughable imnsho. But it's not that freshly constructed, at least not in my mind. All the experience ESR has from the python implementation carries to the Go implementation. And the "simple scripts" argument dismisses the fact that those scripts are built on top of complex software. It just doesn't hold water IMHO. Where I think we could have done better would have been to get more concrete detail from ESR about the problems with git-svn. That was never forthcoming and it's a disappointment. Maybe some of the recent discussions are in fact related to these issues and I simply missed that point. I do think we've gotten some details about the "scar tissue" from the cvs->svn transition as well as some of our branch problems. It's my understanding reposurgeon cleans this up significantly whereas Maxim's scripts don't touch this stuff IIUC. > > > > > * Richard's improvements to commit messages are a great improvement to > > > > the > > > > resulting repository (and it's OK if a small percentage end up > > > > misleading > > > > because someone used the wrong PR number, sometimes people use the > > > > wrong > > > > commit message or commit changes they didn't mean to and so having some > > > > misleading messages is unavoidable). > > > > > > As long as the original commit message is kept, verbatim, and you only > > > add a new summary line, all is fine. If not -> nope, not okay. > > Sorry, have to disagree here. I think what Richard has done is a > > significant step forward. > > We talked about it for days, and as far as I understand it Richard agreed. When Richard and I spoke we generally agreed that we felt a reposurgeon conversion, if it could be made to work was the preferred solution, followed by Maxim's approach and lastly the existing git-svn mirror. If I'm mis-representing Richard's position I hope he'll chime in and correct the record. > > But, there is no way I can verify this yet, or is there? Is there a repo > we can look at? Something close to final. I think Joseph posted something good enough to verify. There's still work going on, but I'd consider the outstanding issues nits and well within the scope of what can reasonably still be changing. I would have had a similar position for Maxim's scripts if there were minor changes still happening with them. Jeff
Re: Test GCC conversion with reposurgeon available
On Wed, 18 Dec 2019, Jason Merrill wrote: > On Tue, Dec 17, 2019 at 4:39 PM Joseph Myers > wrote: > > > Points for consideration: > > > > 1. Do we want some kind of rearrangement of refs as in the 1b > > repository or not? > > > > Maybe? How much space does that save in a clone? How much work does a > partial clone add on the server, since the server needs to pack up the > objects for the partial clone rather than just transmitting its own packs? I haven't measured work on the server, and timing individual clones is liable to a lot of variation from variable load there, but for a single clone --mirror of the 1b repository (so all refs, including refs/deleted/) I got real13m16.473s user16m45.429s sys 0m33.901s and 1360 MB objects directory, but for a clone without --mirror (so only a limited subset of refs and the server needing to build a pack) real15m5.554s user12m11.771s sys 0m26.914s and 950 MB objects directory. Adding the objects from the existing git-svn mirror (presumably also under refs not fetched by default) increases repository size by about 300 MB, based on a previous test of doing that (most blob and tree objects will be shared between the two versions of the history, but all the commit objects are separate). > > 3. Where an attribution comes from an author map rather than a > > ChangeLog file, do we wish to use the existing author map or do people > > prefer using names from that map but with @gcc.gnu.org addresses (and > > @gnu.org for usernames that only committed in the gcc2 period)? > > I lean toward the latter. I'll plan to change the author map to default to @gcc.gnu.org and @gnu.org addresses. -- Joseph S. Myers jos...@codesourcery.com
Re: Proposal for the transition timetable for the move to GIT
On Wed, 18 Dec 2019, Jeff Law wrote: > > That isn't what I said. I said that freshly constructed complex software > > will have more and deeper errors than stupid simple scripts do (or I > > implied that at least, maybe it wasn't clear). And I only say this > > because the opposite was claimed, which is laughable imnsho. > But it's not that freshly constructed, at least not in my mind. All > the experience ESR has from the python implementation carries to the Go > implementation. > > And the "simple scripts" argument dismisses the fact that those scripts > are built on top of complex software. It just doesn't hold water IMHO. Nor do I think reposurgeon (or at least the SVN reader, which is the main part engaged here) is significantly more complicated than implied by the task it's performing of translating between the different conceptual models of SVN and git. I've found it straightforward to produce reduced testcases for issues found, and fixed several of them myself despite not actually knowing Go. The issues remaining are generally conceptually straightforward to understand the issue and how to fix it. -- Joseph S. Myers jos...@codesourcery.com
Re: Struct declaration and initialization in TREES
On 2019-12-18 6:02 a.m., Richard Biener wrote:
> On December 17, 2019 8:31:00 PM GMT+01:00, Erick Ochoa
> wrote:
>> Hi,
>>
>> I'm interested in printing VAR_DECL trees that are of type
>> RECORD_TYPE. I am using the function print_generic_decl
>> for debugging and found this interesting behaviour.
>>
>> When I do initialization of structs using the following
>> syntax:
>>
>> ```
>> struct aStruct { _Bool e; int a; char b; float c; double d; _Bool f;
>> long h;};
>> struct aStruct astruct = { .e = 0, .a = 1, .b = 2, .c = 3.0, .d = 4.0,
>> .f = 5, .h = 6 };
>> ```
>>
>> print_generic_decl will print the following output:
>>
>> ```
>> INTERESTED IN: static struct aStruct astruct = <<< error >>>;
>> ```
>>
>> Am I using the correct API? Is this a limitation of the API?
>
> You need to ask IPA about the static initializer, DECL_INITIAL is adjusted at
> some point.
>
> Richard.
Thanks Richard.
I still don't understand very well what I should do. I found the
place in GCC internals where DECL_INITIAL is described.
https://gcc.gnu.org/onlinedocs/gccint/Working-with-declarations.html
VAR_DECL
If this variable is initialized (but does not require a constructor),
the DECL_INITIAL will be an expression for the initializer.
The initializer should be evaluated, and a bitwise copy into the variable
performed. If the DECL_INITIAL is the error_mark_node, there is an
initializer,
but it is given by an explicit statement later in the code; no bitwise copy
is required.
So, now I understand that I can now change my patch to something like this:
>> +iphw_execute()
>> +{
>> + if (!dump_file) return 0;
>> + varpool_node *node;
>> + FOR_EACH_VARIABLE(node)
>> + {
>> +gcc_assert(node->decl);
>> +tree decl = node->decl;
>> +gcc_assert(TREE_CODE(decl) == VAR_DECL);
>> +
>> +tree curr_type = TREE_TYPE(decl);
>> +gcc_assert(curr_type);
>> +
>> +const bool is_struct = TREE_CODE(curr_type) == RECORD_TYPE;
>> +if (is_struct) fprintf(dump_file, "INTERESTED IN: ");
tree expr = DECL_INITIAL(decl);
if (expr == error_mark_node) {
fprintf(dump_file, "initializer is given by explicit statement later
in code\n");
continue;
}
>> +print_generic_decl(dump_file, decl, TDF_DETAILS);
>> +fprintf(dump_file, "\n");
>> + }
However I still don't know how to ask IPA about the static initializer.
I tried iterating over the ipa_refs (i.e. node->iterate_referring (i, ref))
and then looking for writes, but there are now writes because it is a
initialized statically.
>
>> Would people be interested in me extending this API to print
>> out something more useful? I already have some code that
>> iterates over fields and prints out names and types. It
>> can still use some work though.
>>
>> However, I understand if this is the intended behaviour.
>> Another question (related to the possibility of intended behaviour)
>> is: how is struct initialization represented in trees?
>> (I.e. will each field be initialized separately or something else
>> happens?)
>>
>> Thanks! I also include the patch in case people want a simple
>> working example on how to print declarations.
>>
>> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
>> index 6b857bd..f4f1376 100644
>> --- a/gcc/Makefile.in
>> +++ b/gcc/Makefile.in
>> @@ -1368,6 +1368,7 @@ OBJS = \
>> incpath.o \
>> init-regs.o \
>> internal-fn.o \
>> +ipa-hello-world.o \
>> ipa-cp.o \
>> ipa-sra.o \
>> ipa-devirt.o \
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index b4dc31c..304ec9f 100644
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -3348,4 +3348,7 @@ fipa-ra
>> Common Report Var(flag_ipa_ra) Optimization
>> Use caller save register across calls if possible.
>>
>> +fipa-typelist
>> +Common Report Var(flag_ipa_typelist) TBD
>> +
>> ; This comment is to ensure we retain the blank line above.
>> diff --git a/gcc/ipa-hello-world.c b/gcc/ipa-hello-world.c
>> new file mode 100644
>> index 000..ed4ae11
>> --- /dev/null
>> +++ b/gcc/ipa-hello-world.c
>> @@ -0,0 +1,78 @@
>> +#include "config.h"
>> +#include "system.h"
>> +#include "coretypes.h"
>> +#include "backend.h"
>> +#include "tree.h"
>> +#include "gimple-expr.h"
>> +#include "predict.h"
>> +#include "alloc-pool.h"
>> +#include "tree-pass.h"
>> +#include "cgraph.h"
>> +#include "diagnostic.h"
>> +#include "fold-const.h"
>> +#include "gimple-fold.h"
>> +#include "symbol-summary.h"
>> +#include "tree-vrp.h"
>> +#include "ipa-prop.h"
>> +#include "tree-pretty-print.h"
>> +#include "tree-inline.h"
>> +#include "ipa-fnsummary.h"
>> +#include "ipa-utils.h"
>> +#include "tree-ssa-ccp.h"
>> +#include "stringpool.h"
>> +#include "attribs.h"
>> +
>> +
>> +static unsigned int
>> +iphw_execute()
>> +{
>> + if (!dump_file) return 0;
>> + varpool_node *node;
>> + FOR_EACH_VARIABLE(node)
>> + {
>> +gcc_assert(node->decl);
>> +tree decl = node->decl;
>> +gcc_assert(TREE_CODE(decl) == VAR_DECL);
>> +
>>
Re: Proposal for the transition timetable for the move to GIT
On Wed, Dec 18, 2019 at 11:07:11AM -0700, Jeff Law wrote: > > That isn't what I said. I said that freshly constructed complex software > > will have more and deeper errors than stupid simple scripts do (or I > > implied that at least, maybe it wasn't clear). And I only say this > > because the opposite was claimed, which is laughable imnsho. > But it's not that freshly constructed, at least not in my mind. All > the experience ESR has from the python implementation carries to the Go > implementation. What, writing code in Python made him learn Go? > And the "simple scripts" argument dismisses the fact that those scripts > are built on top of complex software. It just doesn't hold water IMHO. This is the Unix philosophy though! > Where I think we could have done better would have been to get more > concrete detail from ESR about the problems with git-svn. That was > never forthcoming and it's a disappointment. Yes. And as far as I can see you can wait forever for it. Oh well, we have a lot of experience in waiting. > I do think we've gotten some details about the "scar tissue" from the > cvs->svn transition as well as some of our branch problems. It's my > understanding reposurgeon cleans this up significantly whereas Maxim's > scripts don't touch this stuff IIUC. They do, I think? This was easy to do, too: git://git.linaro.org/people/maxim-kuvyrkov/gcc-reparent.git/ > > > > As long as the original commit message is kept, verbatim, and you only > > > > add a new summary line, all is fine. If not -> nope, not okay. > > > Sorry, have to disagree here. I think what Richard has done is a > > > significant step forward. > > > > We talked about it for days, and as far as I understand it Richard agreed. > When Richard and I spoke we generally agreed that we felt a reposurgeon > conversion, if it could be made to work was the preferred solution, > followed by Maxim's approach and lastly the existing git-svn mirror. > If I'm mis-representing Richard's position I hope he'll chime in and > correct the record. This is just about the "we should not try to change the commit message", and Joseph confirmed that is what is done now. So that is all fine. Segher
Re: Proposal for the transition timetable for the move to GIT
On Wed, 2019-12-18 at 13:50 -0600, Segher Boessenkool wrote: > On Wed, Dec 18, 2019 at 11:07:11AM -0700, Jeff Law wrote: > > > That isn't what I said. I said that freshly constructed complex software > > > will have more and deeper errors than stupid simple scripts do (or I > > > implied that at least, maybe it wasn't clear). And I only say this > > > because the opposite was claimed, which is laughable imnsho. > > But it's not that freshly constructed, at least not in my mind. All > > the experience ESR has from the python implementation carries to the Go > > implementation. > > What, writing code in Python made him learn Go? ?!? What does that question have to do with anything? My point is the experience of writing reposurgeon and in particular being intimately familiar with what does on under the hood inside CVS, SVN and GIT has great value, particularly in converting a large repo like ours that has warts from the CVS and SVN days as well as warts from the CVS->SVN conversion. > > And the "simple scripts" argument dismisses the fact that those scripts > > are built on top of complex software. It just doesn't hold water IMHO. > > This is the Unix philosophy though! But your comment doesn't address the fact that in both cases, reposurgeon and Maxim's scripts, there's complex code involved. In Maxim's case it's just under the covers. Ultimately I don't care about the Unix philosophy. I'm pragmatic. If reposurgeon gives us a better conversion, and it sounds very much like it already does, then the fact that it doesn't follow the Unix philosophy is irrelevant to me. > > > Where I think we could have done better would have been to get more > > concrete detail from ESR about the problems with git-svn. That was > > never forthcoming and it's a disappointment. > > Yes. And as far as I can see you can wait forever for it. Oh well, we > have a lot of experience in waiting. Umm, no, I'm not suggesting we wait in any way at all. Based on what I've heard from Joseph, I'd vote today to go with reposurgeon as soon as it's convenient for the people doing the conversion and our development cycle. This highlights one big issue that we have as a project. Specifically that we don't have a clear cut way to make these kinds of technical decisions when there isn't unanimous consent. > > > I do think we've gotten some details about the "scar tissue" from the > > cvs->svn transition as well as some of our branch problems. It's my > > understanding reposurgeon cleans this up significantly whereas Maxim's > > scripts don't touch this stuff IIUC. > > They do, I think? This was easy to do, too: > git://git.linaro.org/people/maxim-kuvyrkov/gcc-reparent.git/ Good. Thanks for clarifying. > > > > > > As long as the original commit message is kept, verbatim, and you only > > > > > add a new summary line, all is fine. If not -> nope, not okay. > > > > Sorry, have to disagree here. I think what Richard has done is a > > > > significant step forward. > > > > > > We talked about it for days, and as far as I understand it Richard agreed. > > When Richard and I spoke we generally agreed that we felt a reposurgeon > > conversion, if it could be made to work was the preferred solution, > > followed by Maxim's approach and lastly the existing git-svn mirror. > > If I'm mis-representing Richard's position I hope he'll chime in and > > correct the record. > > This is just about the "we should not try to change the commit message", > and Joseph confirmed that is what is done now. So that is all fine. OK jeff
Re: Test GCC conversion with reposurgeon available
On Tue, 17 Dec 2019, Joseph Myers wrote: > I've made test conversions of the GCC repository with reposurgeon > available (gcc.gnu.org / sourceware.org account required to access > these git+ssh repositories, it doesn't need to be one in the gcc group > or to have shell access). More information about the repositories, > conversion choices made and known issues is given below, and, as noted > there, I'm running another conversion now with fixes for some of those > issues and the remaining listed issues not fixed in that conversion > are being actively worked on. > > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1b.git There are now four more repositories available. git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-2a.git git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-2b.git git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3b.git The 2a and 2b repositories are similar to 1a and 1b, but have fixes to issues 4 and 5 I listed (they include attribution extraction from ChangeLog. files and all of Richard's commit message improvements). The 3a and 3b repositories have further improvements to the conversion machinery. Verification shows that 3a and 3b have execute permissions on files exactly the same as in SVN, at all (non-deleted) branch tips and tags. .cvsignore files are present as requested. There are mergeinfo improvements to avoid spuriously marking cherry-picks as merge commits and to avoid having excessive numbers of merge parents in some cases, but the mergeinfo improvements should be considered a work in progress; further improvements have since been implemented in reposurgeon since then to allow many more merges to result in git merge commits without false positives for cherry-picks, so will be in the next trial conversion after these ones. -- Joseph S. Myers jos...@codesourcery.com
Re: Commit messages and the move to git
On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote: > I've attached a sample from the start of the fixed list - the full list is far > too big to post to give a flavour of how the script currently works. Note > that annotations of the form [checkme: ] in the summary are for diagnostic > purposes. These are where heuristics suggest that there's a higher than > normal chance that the PR number is incorrect and that manual auditing is > recommended. Such annotations would not be appropriate in the final > conversion. Concretely, here is the current list of 664 checkme: annotations where something was suspicious about the PR number (either component mismatch or resolved as INVALID). Would some people like to volunteer to pick up sections of this list and, for their section, produce a list of SVN revisions (at the end of the checkme line) for which the PR number appears to be correct, and a list of mappings from SVN revision to correct PR number when the PR number appears to be wrong? For any that don't get reviewed like that we can easily make the script, for the final conversion, decline to add a new summary line for any commit where the PR number is suspicious. -- Joseph S. Myers jos...@codesourcery.comre PR fortran/13911 ([g77] Cannot initialize variables with declation as allowed by g77 [checkme: g++ SVN r17128]) re PR c++/2823 (kde2/artsd miscompilation (part 1) [checkme: g++ SVN r42648]) re PR c++/2823 (kde2/artsd miscompilation (part 1) [checkme: g++ SVN r42650]) re PR c++/2936 (gcc gives me an internal error when compiling mozilla with --enable-optimization="-O3" [checkme: g++ SVN r42704]) re PR c++/2936 (gcc gives me an internal error when compiling mozilla with --enable-optimization="-O3" [checkme: g++ SVN r42705]) re PR c++/4476 (g++ does not parse the definition of friend function within a class properly [checkme: g++ SVN r46226]) re PR c++/4206 (ICE with switch in while [checkme: g++ SVN r46992]) re PR c++/3154 (Tree check: expected class 't', have 'd' (type_decl) in is_aggr_type, at cp/init.c:1435 [checkme: g++ SVN r47047]) re PR c++/3145 (virtual inheritance still creates wrong code [checkme: g++ SVN r47316]) re PR c++/3381 (explicit template instantations fail with absolutely qualified names [checkme: g++ SVN r47546]) re PR debug/5163 (Internal compiler error in add_abstract_origin_attribute, at dwarf2out.c:9296 [checkme: c SVN r48302]) re PR fortran/6138 (Incorrect access of integer*1 variables on PA [checkme: f SVN r52630]) re PR fortran/6138 (Incorrect access of integer*1 variables on PA [checkme: f SVN r52631]) re PR libffi/10610 ([powerpc-linux] 230 testsuite failures due to alignment errors [checkme: libgcj SVN r73019]) re PR libffi/10610 ([powerpc-linux] 230 testsuite failures due to alignment errors [checkme: libgcj SVN r73021]) re PR rtl-optimization/13024 (gcj can't build current rhug [checkme: java SVN r73752]) backport: re PR rtl-optimization/12816 (internal compiler error pari-2.1.5/Olinux-i686 [checkme: c++ SVN r75851]) revert: re PR tree-optimization/16115 (double-destruction problem with argument passing via temporary (breaks auto_ptr) [checkme: c++ SVN r84147]) re PR tree-optimization/15262 ([tree-ssa] Alias analyzer cannot handle addressable fields [checkme: c SVN r86398]) re PR rtl-optimization/15857 (Wrong code with optimization >= -O1 [checkme: c++ SVN r87429]) re PR c/16403 (Floating-point assignment to int is inconsistent [checkme: INVALID SVN r94142]) re PR c++/20505 (internal error when compiling with -ggdb2 and no error with -ggdb1 [checkme: debug SVN r97528]) re PR libgcj/21058 (fragile libgcj link process omits some inner classes [checkme: libgj SVN r102140]) re PR rtl-optimization/19210 (not using do-loop for some loops [checkme: tree-optimization SVN r102225]) re PR tree-optimization/21562 (Quiet bad codegen (unrolling + tail call interaction) [checkme: c SVN r103245]) re PR boehm-gc/23662 (Binaries generated by arm-linux-gcj segfault on execution on arm target [checkme: libgcj SVN r103945]) re PR boehm-gc/23662 (Binaries generated by arm-linux-gcj segfault on execution on arm target [checkme: libgcj SVN r103946]) re PR c++/7874 (g++ finds friend functions defined in class-definition but not declared in the enclosing namespace [checkme: g++ SVN r104188]) re PR c/21419 (Accepts writting to const via asm [checkme: tree-optimization SVN r104991]) re PR awt/26641 (AWT mouse event handling regression [checkme: libgcj SVN r112464]) re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114637]) re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114639]) re PR middle-end/25505 (gcc uses way too much stack space for this code [checkme: c++ SVN r116634]) re PR libstdc++/39238 (trunk revision 144279 - cfenv:54: error: â::fenv_tâ has not been declared [checkme: fortran SVN r120056]) re PR cp-tools/30707 (gjavah cannot handle more than one CLASS [checkme
Re: Commit messages and the move to git
On Wed, 18 Dec 2019, Joseph Myers wrote: > On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote: > > > I've attached a sample from the start of the fixed list - the full list is > > far > > too big to post to give a flavour of how the script currently works. Note > > that annotations of the form [checkme: ] in the summary are for > > diagnostic > > purposes. These are where heuristics suggest that there's a higher than > > normal chance that the PR number is incorrect and that manual auditing is > > recommended. Such annotations would not be appropriate in the final > > conversion. > > Concretely, here is the current list of 664 checkme: annotations where > something was suspicious about the PR number (either component mismatch or > resolved as INVALID). Would some people like to volunteer to pick up > sections of this list and, for their section, produce a list of SVN > revisions (at the end of the checkme line) for which the PR number appears > to be correct, and a list of mappings from SVN revision to correct PR > number when the PR number appears to be wrong? For any that don't get > reviewed like that we can easily make the script, for the final > conversion, decline to add a new summary line for any commit where the PR > number is suspicious. Here's a slightly shorter version with 644 checkme: annotations, after adding a few more component aliases to the script (e.g., no longer considering it suspicious if the log message says PR g++/something and that PR is in the component that's actually called c++). -- Joseph S. Myers jos...@codesourcery.comre PR fortran/13911 ([g77] Cannot initialize variables with declation as allowed by g77 [checkme: g++ SVN r17128]) re PR debug/5163 (Internal compiler error in add_abstract_origin_attribute, at dwarf2out.c:9296 [checkme: c SVN r48302]) re PR libffi/10610 ([powerpc-linux] 230 testsuite failures due to alignment errors [checkme: libgcj SVN r73019]) re PR libffi/10610 ([powerpc-linux] 230 testsuite failures due to alignment errors [checkme: libgcj SVN r73021]) re PR rtl-optimization/13024 (gcj can't build current rhug [checkme: java SVN r73752]) backport: re PR rtl-optimization/12816 (internal compiler error pari-2.1.5/Olinux-i686 [checkme: c++ SVN r75851]) revert: re PR tree-optimization/16115 (double-destruction problem with argument passing via temporary (breaks auto_ptr) [checkme: c++ SVN r84147]) re PR tree-optimization/15262 ([tree-ssa] Alias analyzer cannot handle addressable fields [checkme: c SVN r86398]) re PR rtl-optimization/15857 (Wrong code with optimization >= -O1 [checkme: c++ SVN r87429]) re PR c/16403 (Floating-point assignment to int is inconsistent [checkme: INVALID SVN r94142]) re PR c++/20505 (internal error when compiling with -ggdb2 and no error with -ggdb1 [checkme: debug SVN r97528]) re PR rtl-optimization/19210 (not using do-loop for some loops [checkme: tree-optimization SVN r102225]) re PR tree-optimization/21562 (Quiet bad codegen (unrolling + tail call interaction) [checkme: c SVN r103245]) re PR c/21419 (Accepts writting to const via asm [checkme: tree-optimization SVN r104991]) re PR awt/26641 (AWT mouse event handling regression [checkme: libgcj SVN r112464]) re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114637]) re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114639]) re PR middle-end/25505 (gcc uses way too much stack space for this code [checkme: c++ SVN r116634]) re PR libstdc++/39238 (trunk revision 144279 - cfenv:54: error: â::fenv_tâ has not been declared [checkme: fortran SVN r120056]) re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121666]) re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121667]) re PR debug/33739 (Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin [checkme: fortran SVN r130244]) re PR c++/31863 (g++-4.1: out of memory with -O1/-O2 [checkme: middle-end SVN r131405]) re PR c/34601 (ICE with undefined enum [checkme: middle-end SVN r131506]) re PR middle-end/34668 (ICE in find_compatible_field with -combine [checkme: c SVN r131572]) re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131649]) re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131670]) re PR tree-optimization/34885 (ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574 [checkme: c SVN r131694]) re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131719]) re PR c++/34953 (ICE on destructor + noreturn-function at -O3 [checkme: middle-end SVN r131782]) re PR translation/35002 (Incorrect spelling of "hottest" [checkme: c SVN r131940]) re PR driver/30330 (-Wdeprecated is not documented [checkme: documentation SVN r132131]) re P
Re: Test GCC conversion with reposurgeon available
On 12/18/19 10:55 PM, Joseph Myers wrote: git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git I cloned this one and started trying random things again. The previous one had some strange-looking merge commits, but it sounded like that was a known issue, and indeed the ones I had seen were fixed in this new version. I decided to write a small script to check whether there were any merge commits with more than two parents, and there are a few which have three. One commit seems to occur as a parent in all of these: 422854db0e8605867e0834035aa2b1da1b71cbfb. An example is b743e467e43e6211f2c2537f1f07bbceb4d3aa61, apparently from spu-4_5-branch. No idea whether there is an issue or whether this is worth looking at, but I figured I'd point it out at least. Bernd
Re: Proposal for the transition timetable for the move to GIT
Jeff Law : > But it's not that freshly constructed, at least not in my mind. All > the experience ESR has from the python implementation carries to the Go > implementation. Not only do you have reposurgeon, you have me. I wish this mattered less than it does. I have *far* more experience doing big, messy repository moves than anybody else. I try to exteriorize that knowledge into the reposurgeon code and documents as much as I can, but as with other kinds of expertise a lot of it is implicit knowledge that is only elicited by practice and answering questions. On small conversions of clean repositories such implicit expertise doesn't matter too much. You may be able to pull off a once-and-done with the tools, especially if they're my tools and you've read all my stuff on good practice. As an example, the CVS-to-git conversion of groff didn't really need me. Lifts from CVS are normally horrible, but the groff devs were the best I've ever seen at not leaving debris from operator errors in the history. Any of them could have read my docs and done a clean coversion in two hours. Only...there was no way to way to know that in advance. The odds were heavily against it. Emacs was, and GCC is, the messy opposite case. You guys needed a seasoned "I know these things so you don't have to" expert more than you will probably ever really understand. And, sadly, there aren't any others but me yet. Nobody else has been interested enough in the problem to invest the time. > Where I think we could have done better would have been to get more > concrete detail from ESR about the problems with git-svn. That was > never forthcoming and it's a disappointment. Maybe some of the recent > discussions are in fact related to these issues and I simply missed > that point. I posted this link before: http://esr.ibiblio.org/?p=6778 I can't actually tell you much more than that. Actually, if I understood git-svn's failure modes in enough detail to tell you more I might be less frightened of it. Mostly what I know is that during several other conversions I have stumbled across trails of metadata damage for which use of git-svn seems to have been to blame. Though, admittedly, I'm not certain of that in any individual case; the ways git-svn screws up are not necessarily disinguishable from the aftereffects of cvs2svn conversion damage, or from normal kinds of operator error. Overall, though, defect rates seemed noticeably higher when git-svn had been used as a front end. I learned to flinch when people wanting me to do a full conversion of an SVN repo admitted git-svn had been deployed, even though I was hard-put to explain why I was flinching. > I do think we've gotten some details about the "scar tissue" from the > cvs->svn transition as well as some of our branch problems. It's my > understanding reposurgeon cleans this up significantly whereas Maxim's > scripts don't touch this stuff IIUC. That's correct. And again, no blame to Maxim for this; he took a conventional approach that does as little analysis as it can get away with, which can be a good tradeoff on smaller, cleaner repositories without a CVS back-history. > There's still > work going on, but I'd consider the outstanding issues nits and well > within the scope of what can reasonably still be changing. Issue list here: https://gitlab.com/esr/reposurgeon/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=GCC Presently 6 items including 2 bugs. One of those bugs may already be fixed, we're waiting on Joseph's current conversion to see. Counting time do all the RFEs requested, polishing, and final review I think we're looking at another week, maybe a bit less if things go well. You guys could get a final conversion under your Yule tree. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Proposal for the transition timetable for the move to GIT
Joseph Myers : > Nor do I think reposurgeon (or at least the SVN reader, which is the main > part engaged here) is significantly more complicated than implied by the > task it's performing of translating between the different conceptual > models of SVN and git. I've found it straightforward to produce reduced > testcases for issues found, and fixed several of them myself despite not > actually knowing Go. The issues remaining are generally conceptually > straightforward to understand the issue and how to fix it. Let me note for the record that I found Joseph's ability to find and fix bugs in the reader quite impressive. Maybe not as impressive as it would have been before the recent rewrite. That code used to be a pretty nasty hairball. It's a lot cleaner and easier to understand now. But impedence-matching the two data models is tricky, subtler than it looks, and has rebarbative edge cases. Even given the ckeanest possible implementatiion, troubleshooting it is no mean feat. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Test GCC conversion with reposurgeon available
On Thu, 19 Dec 2019, Bernd Schmidt wrote: > On 12/18/19 10:55 PM, Joseph Myers wrote: > > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git > > I cloned this one and started trying random things again. > The previous one had some strange-looking merge commits, but it sounded like > that was a known issue, and indeed the ones I had seen were fixed in this new > version. > I decided to write a small script to check whether there were any merge > commits with more than two parents, and there are a few which have three. One > commit seems to occur as a parent in all of these: > 422854db0e8605867e0834035aa2b1da1b71cbfb. An example is > b743e467e43e6211f2c2537f1f07bbceb4d3aa61, apparently from spu-4_5-branch. > > No idea whether there is an issue or whether this is worth looking at, but I > figured I'd point it out at least. b743e467e43e6211f2c2537f1f07bbceb4d3aa61 is r152464, from named-addr-spaces-branch. This merge is the first one that added an svn:mergeinfo property on named-addr-spaces-branch, which previously had only svnmerge-integrated (the svn:mergeinfo property was copied from the one that was on trunk at that time). That svn:mergeinfo property specifies merges from /branches/cxx0x-lambdas-branch, /branches/lto and /trunk, and the merge parents are for the first two of those. For /trunk, it only specifies two revisions, which is clearly not a valid merge and this version of reposurgeon avoids creating merge commits for cherry-picks. svnmerge-integrated specifies /trunk:1-151687,151691-152437, which would be a valid merge from trunk (there are no trunk revisions in the gap) but reposurgeon only looks at svnmerge-integrated if svn:mergeinfo is empty. I'll file a request that it take the union of revision ranges from the two properties, which ought to be easy to implement. Once it recognises that commit as a merge from trunk, it will should automatically discard the other merge parents because it now avoids adding a merge parent that is an ancestor of another merge parent. I.e. this is an artifact of someone having done a merge with svnmerge.py that brought in svn:mergeinfo from another branch where SVN's native merge tracking had been used, and should be straightforward to fix. -- Joseph S. Myers jos...@codesourcery.com
Unix philosopy vs. poor semantic locality
[New thread] Segher Boessenkool : > > And the "simple scripts" argument dismisses the fact that those scripts > > are built on top of complex software. It just doesn't hold water IMHO. > > This is the Unix philosophy though! I'm now finishing a book in which I have a lot to say about this, inspired in part by experience with reposurgeon. One of the major concepts I introduce in the book is "semantic locality". This is a property of data representations and structures. A representation has good semantic locality when the context you need to interpret any individual part of it is reliably nearby. A classic example of a representation wth good semantic locality is a Unix password file. All the information associated with a username is on one line. It is accordingly easy to parse and extract individual records. Databases have very poor semantic locality. So do version-control systems. You need a lot of context to understand any individual data element, and that context can be arbitrarily far away in terms of retrieval complexity and time. The Unix philosophy of small loosely-coupled tools has few more fervent advocates than me. But I have come to understand that it almost necessarily fails in the presence of data representations with poor semantic locality. This contraint can be inverted and used as a guide to good design: to enable loose coupling, design your representations to have good semantic locality. If the Unix password file were an SQL database, could you grep it? No. You'd have to use an SQL-specific query method rather than a generic utility like grep that is uncoupled from the specifics of the database's schema. The ideal data representation for enabling the Unix ecology of tools is textual, self-describing, and has good semantic locality. Historically, Unix programmers have understood the importance of textuality and self-description. But we've lacked the concept of and a term for semantic locality. Having that allows one to talk about some things that were hard to even notice before. Here's one: the effort required to parallelize an operation on a data structure is inversely proportional to its semantic locality. If it has good semantic locality, you can carve it into pieces that are easy units of work for parallelization. If it doesn't...you can't. Best case is you'll need locking for shared parts. Worst case is that the referential structure of the representation is so tangled that you can't parallelize at all. Version-control systems rely on data structures with very poor semantic locality. It is therefore predictable that attacking them with small unspecialized tools and scripting is...difficult. It can be done, sometimes, with sufficient cleverness, but the results are too often like making a pig fly by strapping JATO units to it. That is to say: a brief and glorious ascent followed by entirely predictable catastrophe. Having trouble believing me? OK, here's a challenge: rewrite GCC's code-generation stage in awk/sed/m4. The attempt, if you actually made it, would teach you that poor semantic locality forces complexity on the tools that have to deal with it. And that, ladies and gentlemen, is why reposurgeon has to be as large and complex as it is. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Unix philosopy vs. poor semantic locality
On Wed, 18 Dec 2019, Eric S. Raymond wrote: > And that, ladies and gentlemen, is why reposurgeon has to be as > large and complex as it is. And, in the end, it *is* complex software on which you build simple scripts. gcc.lift is a simple script, written in the domain-specific reposurgeon language. -- Joseph S. Myers jos...@codesourcery.com
Re: Unix philosopy vs. poor semantic locality
Joseph Myers : > On Wed, 18 Dec 2019, Eric S. Raymond wrote: > > > And that, ladies and gentlemen, is why reposurgeon has to be as > > large and complex as it is. > > And, in the end, it *is* complex software on which you build simple > scripts. gcc.lift is a simple script, written in the domain-specific > reposurgeon language. The Patterns crowd speaks of "alternating hard and soft layers". The design of reposurgeon was driven by two insights: 1. Previous VCS-conversion tools sucked in part because they tried to be too automatic, eliminating human judgment. Repposurgeon is designed and intended to be a *judgment amplifier*, doing mechanics and freeing the human operator to think about conversion policy. Hence the DSL. 2. git fast-import streams are a pretty capable format for interchanging version-control histories. Not perfect, but good enough that you can gain a lot by co-opting existing importers and exporters. Mate the idea of a judgment-amplifying DSL to a structure editor for git fast-import streams and reposurgeon is what you get. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Test GCC conversion with reposurgeon available
On Wed, Dec 18, 2019 at 1:17 PM Joseph Myers wrote: > On Wed, 18 Dec 2019, Jason Merrill wrote: > > > On Tue, Dec 17, 2019 at 4:39 PM Joseph Myers > > wrote: > > > > > Points for consideration: > > > > > > 1. Do we want some kind of rearrangement of refs as in the 1b > > > repository or not? > > > > > > > Maybe? How much space does that save in a clone? How much work does a > > partial clone add on the server, since the server needs to pack up the > > objects for the partial clone rather than just transmitting its own > packs? > > I haven't measured work on the server, and timing individual clones is > liable to a lot of variation from variable load there, but for a single > clone --mirror of the 1b repository (so all refs, including refs/deleted/) > I got > > real13m16.473s > user16m45.429s > sys 0m33.901s > > and 1360 MB objects directory, but for a clone without --mirror (so only a > limited subset of refs and the server needing to build a pack) > > real15m5.554s > user12m11.771s > sys 0m26.914s > > and 950 MB objects directory. Adding the objects from the existing > git-svn mirror (presumably also under refs not fetched by default) > increases repository size by about 300 MB, based on a previous test of > doing that (most blob and tree objects will be shared between the two > versions of the history, but all the commit objects are separate). > So a 30% space savings; that's pretty significant. Though I wonder how much of that is refs/dead and refs/deleted, which seem unnecessary to carry over to git at all. I wonder if it would make sense to put them in a separate repository that refers to the main gcc.git? Jason
Re: Options disabled under -Os
on 2019/12/19 上午12:49, visda.vokhsho...@microchip.com wrote: > Hello, > > In GCC documentation, 3.1 Options that Control Optimization: it is indicated > -Os disables alignment of functions, jumps, labels, and loops. However, with > -v -Q passed to the compile step, I see all these options enabled under -Os. > Is this intended behavior, therefore a documentation bug? > I have tried this with GCC4.4.7 and GCC8.3.1 Hi Visda, This issue has been fixed in GCC 9 and trunk. I can reproduce it with gcc 8.3.1 but it's gone with gcc 9.2.1 and latest trunk. I also checked the latest gcc-branch-8 code, they are guarded in OPT_LEVELS_2_PLUS_SPEED_ONLY, so gcc8 just dumps inaccurate information but the behavior should be the same as documentation. BR, Kewen
