Re: syncing the GCC vax port, atomic issue
On 01/10/2019 20:43, Jeff Law wrote: On 9/20/19 7:18 PM, co...@sdf.org wrote: On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote: Introducing the reversed jbb* patterns doesn't seem to help with the original issue. It crashes building libatomic. My loose understanding of what is going on: - GCC emits this atomic in expand. - When cleaning up, it looks for optimizations. - It decides this is a branch to another branch situation, so maybe can be improved. - This fails to output an instruction for unrelated reasons. - Hit an assert. I don't think that we should be trying to combine regular branch + atomic branch in very generic code. I can see how you might think that, but the way the RTL optimizers work, particularly the combiner is it tries to smash together two or more insns that are related by dataflow into a single insn (I'm over-simplifying, but it's good enough for this discussion). That's an inherent design decision for the combiner, it's not likely to change. If you want to prevent the combiner from doing that, you have to use UNSPECs Jeff There are some target hooks in combine that might help here. targetm.cannot_copy_insn_p and targetm.legitimate_combined_insn. The former is used more widely than just combine, so you might need to be careful that it doesn't adversely affect other optimizations. The latter relies on spotting that the combined insn is doing something stupid even though it matches a pattern in the back-end. So it may be that neither really solves your problem in this case. R.
Re: Modifying types during optimization
On Wed, Oct 2, 2019 at 1:43 AM Gary Oblock wrote: > > I'm working on structure reorganization optimizations and one of the > things that needs to happen is that pointers to arrays of structures > need to be modified into either being an integer of a structure depending > on which optimization is required. > > I'm seeing something similar happening in omp-low.c where the code in > install_var_field and fixup_child_record_type both seem to rebuild the > entire type from scratch if a field is either added or modified. Wouldn't > it be possible simply modify the field(s) in question and rerun layout_type? > > I suspect the answer will be no but reasons as to why that wouldn't work > will probably be equally valuable to me. I think it's undesirable at least. When last discussing "structure reorg" I was always arguing that trying to change the "type" is the wrong angle to look at (likewise computing something like "type escape"). It's really individual objects you are transforming and that you need to track so there may be very well instances of the original type T plus the modified type T' in the program after the transform. Richard. > > Thanks, > > Gary Oblock >
Re: compatibility of structs/unions/enums in the middle end
On Tue, Oct 1, 2019 at 7:49 PM Uecker, Martin
wrote:
>
>
>
> Hi,
>
> I have a proposal for making changes to the rules for
> compatibility of tagged types in C2X (N2366). This was
> received with interest by WG14, so there is a chance
> that this could get accepted into C2X.
>
> In particular, the idea is to make structs (+ unions, enums)
> with the same tag and the same members compatible. The
> current C standards says that such structs are compatible
> between different TUs but not inside the same TU, which
> is very strange and - as pointed out by Joseph
> in DR314 - this leads to "interesting" scenarios
> where types across different TU cannot be partitioned
> into equivalence classes in a consistent way.
>
> The new rules would fix these inconsistencies and also
> make some useful programming patterns possible: E.g. one
> could declare structs/union/enums types in a macro so
> that another invocation produces a compatible type.
> For example:
>
> #define MAYBE(T) struct foo_##T { _Bool flag; T value };
>
> MAYBE(int) x = { true, 0 };
> MAYBE(int) y = x;
>
>
> I am working on a patch for GCC which adds this as an
> optional feature. So far, I have a working patch to the
> C front end which changes the concept of type compatibility
> to match the proposed model. It uses the existing code
> for type compatibility, so is relatively simple.
>
> The question is now how this should interact with the
> middle end. So far, I have to insert some VIEW_CONVERT_EXPR
> to avoid "useless type conversion" errors during gimple
> verification.
>
> I am also wonder how to make TBAA do the right thing
> for the new rules. Currently, GCC assumes 's1p' and 's2p'
> cannot alias in the following example and outputs '2'
> in 'f', but this would not be true anymore according
> to the proposal.
>
>
> #include
>
> typedef struct { int i; } st1;
> typedef struct { int i; } st2;
>
> void f(void* s1v, void* s2v)
> {
> st1 *s1p = s1v;
> st2 *s2p = s2v;
> s1p->i = 2;
> s2p->i = 3;
> printf("f: s1p->i = %i\n", s1p->i);
> }
>
> int main()
> {
> st1 s = { .i = 1 };
> f(&s, &s);
> printf("s.i = %i\n", s.i);
> }
>
> BTW: According to current rules when 'f' is
> moved into a different TU, there is no UB.
> As both 'st1'
> and 'st2' in one TU are compatible
> to both 'st1' and 'st2' in the other TU there
> is no UB. Still, GCC
> incorrectly assumes that
> 's1p' and 's1p' do not alias.
>
>
> I would appreciate any information about how to
> approach this.
The frontend either needs to have the same internal
type representation for both or provide the middle-end
with unification of compatible types via the TYPE_CANONICAL
mechanism (that's what the C++ FE does in similar circumstances).
That is, the TBAA machinery relies on TYPE_CANONICAL (TYPE_MAIN_VARIANT (st1))
== TYPE_CANONICAL (TYPE_MAIN_VARIANT (st2))
(or requivalent TYPE_MAIN_VARIANT if that's already the case).
Richard.
>
> Best,
> Martin
>
Re: compatibility of structs/unions/enums in the middle end
On Wed, Oct 2, 2019 at 12:46 PM Richard Biener
wrote:
>
> On Tue, Oct 1, 2019 at 7:49 PM Uecker, Martin
> wrote:
> >
> >
> >
> > Hi,
> >
> > I have a proposal for making changes to the rules for
> > compatibility of tagged types in C2X (N2366). This was
> > received with interest by WG14, so there is a chance
> > that this could get accepted into C2X.
> >
> > In particular, the idea is to make structs (+ unions, enums)
> > with the same tag and the same members compatible. The
> > current C standards says that such structs are compatible
> > between different TUs but not inside the same TU, which
> > is very strange and - as pointed out by Joseph
> > in DR314 - this leads to "interesting" scenarios
> > where types across different TU cannot be partitioned
> > into equivalence classes in a consistent way.
> >
> > The new rules would fix these inconsistencies and also
> > make some useful programming patterns possible: E.g. one
> > could declare structs/union/enums types in a macro so
> > that another invocation produces a compatible type.
> > For example:
> >
> > #define MAYBE(T) struct foo_##T { _Bool flag; T value };
> >
> > MAYBE(int) x = { true, 0 };
> > MAYBE(int) y = x;
> >
> >
> > I am working on a patch for GCC which adds this as an
> > optional feature. So far, I have a working patch to the
> > C front end which changes the concept of type compatibility
> > to match the proposed model. It uses the existing code
> > for type compatibility, so is relatively simple.
> >
> > The question is now how this should interact with the
> > middle end. So far, I have to insert some VIEW_CONVERT_EXPR
> > to avoid "useless type conversion" errors during gimple
> > verification.
> >
> > I am also wonder how to make TBAA do the right thing
> > for the new rules. Currently, GCC assumes 's1p' and 's2p'
> > cannot alias in the following example and outputs '2'
> > in 'f', but this would not be true anymore according
> > to the proposal.
> >
> >
> > #include
> >
> > typedef struct { int i; } st1;
> > typedef struct { int i; } st2;
> >
> > void f(void* s1v, void* s2v)
> > {
> > st1 *s1p = s1v;
> > st2 *s2p = s2v;
> > s1p->i = 2;
> > s2p->i = 3;
> > printf("f: s1p->i = %i\n", s1p->i);
> > }
> >
> > int main()
> > {
> > st1 s = { .i = 1 };
> > f(&s, &s);
> > printf("s.i = %i\n", s.i);
> > }
> >
> > BTW: According to current rules when 'f' is
> > moved into a different TU, there is no UB.
> > As both 'st1'
> > and 'st2' in one TU are compatible
> > to both 'st1' and 'st2' in the other TU there
> > is no UB. Still, GCC
> > incorrectly assumes that
> > 's1p' and 's1p' do not alias.
> >
> >
> > I would appreciate any information about how to
> > approach this.
>
> The frontend either needs to have the same internal
> type representation for both or provide the middle-end
> with unification of compatible types via the TYPE_CANONICAL
> mechanism (that's what the C++ FE does in similar circumstances).
>
> That is, the TBAA machinery relies on TYPE_CANONICAL (TYPE_MAIN_VARIANT (st1))
> == TYPE_CANONICAL (TYPE_MAIN_VARIANT (st2))
> (or requivalent TYPE_MAIN_VARIANT if that's already the case).
Btw, for you example, how do you expect debug information to look like?
Would there be two type definitions that are not related?
Richard.
> Richard.
>
> >
> > Best,
> > Martin
> >
Re: compatibility of structs/unions/enums in the middle end
Am Mittwoch, den 02.10.2019, 12:47 +0200 schrieb Richard Biener: > On Wed, Oct 2, 2019 at 12:46 PM Richard Biener > wrote: > > > > On Tue, Oct 1, 2019 at 7:49 PM Uecker, Martin > > wrote: ... > > > > > > In particular, the idea is to make structs (+ unions, enums) > > > with the same tag and the same members compatible. The > > > current C standards says that such structs are compatible > > > between different TUs but not inside the same TU, which > > > is very strange and - as pointed out by Joseph > > > in DR314 - this leads to "interesting" scenarios > > > where types across different TU cannot be partitioned > > > into equivalence classes in a consistent way. ... > > > I would appreciate any information about how to > > > approach this. > > > > The frontend either needs to have the same internal > > type representation for both or provide the middle-end > > with unification of compatible types via the TYPE_CANONICAL > > mechanism (that's what the C++ FE does in similar circumstances). > > > > That is, the TBAA machinery relies on TYPE_CANONICAL (TYPE_MAIN_VARIANT > > (st1)) > > == TYPE_CANONICAL (TYPE_MAIN_VARIANT (st2)) > > (or requivalent TYPE_MAIN_VARIANT if that's already the case). Yes, this is what I assumed from looking at the code. The problem is that the front end would need to go over all types and set TYPE_CANONICAL. This seems easy to do on the fly whenever the front end needs to compare types anyway, but this would not be enough as also types which appear unrelated to the front end (e.g. two types declared in separate local scopes) could be compatible. To identify these types would require searching a data structure of all such types in the front end every time a new tagged type is created. This would not be too difficult to implement. On the other hand, the situation with this propsoal for such types is then very similar to any other complex type expressions which need to compared structurally in the middle end. So what I am wondering is whether it would be possible to do such comparisons in the middle end also for tagged types? Finally, how does LTO does it? It somehow also needs to unify different tagged types? Could we reuse this mechanism somehow? > Btw, for you example, how do you expect debug information to look like? > Would there be two type definitions that are not related? I don't know yet. This is why I am trying to implement it, to figure out all these practical issues. How does it work now for tagged types in different TUs that are compatible? Best, Martin
Re: compatibility of structs/unions/enums in the middle end
On Wed, Oct 2, 2019 at 1:57 PM Uecker, Martin wrote: > > Am Mittwoch, den 02.10.2019, 12:47 +0200 schrieb Richard Biener: > > On Wed, Oct 2, 2019 at 12:46 PM Richard Biener > > wrote: > > > > > > On Tue, Oct 1, 2019 at 7:49 PM Uecker, Martin > > > wrote: > > ... > > > > > > > > In particular, the idea is to make structs (+ unions, enums) > > > > with the same tag and the same members compatible. The > > > > current C standards says that such structs are compatible > > > > between different TUs but not inside the same TU, which > > > > is very strange and - as pointed out by Joseph > > > > in DR314 - this leads to "interesting" scenarios > > > > where types across different TU cannot be partitioned > > > > into equivalence classes in a consistent way. > ... > > > > > I would appreciate any information about how to > > > > approach this. > > > > > > The frontend either needs to have the same internal > > > type representation for both or provide the middle-end > > > with unification of compatible types via the TYPE_CANONICAL > > > mechanism (that's what the C++ FE does in similar circumstances). > > > > > > That is, the TBAA machinery relies on TYPE_CANONICAL (TYPE_MAIN_VARIANT > > > (st1)) > > > == TYPE_CANONICAL (TYPE_MAIN_VARIANT (st2)) > > > (or requivalent TYPE_MAIN_VARIANT if that's already the case). > > Yes, this is what I assumed from looking at the code. The problem > is that the front end would need to go over all types and set > TYPE_CANONICAL. Yes. > This seems easy to do on the fly whenever the front > end needs to compare types anyway, but this would not be enough > as also types which appear unrelated to the front end (e.g. two > types declared in separate local scopes) could be compatible. > To identify these types would require searching a data structure > of all such types in the front end every time a new tagged type > is created. This would not be too difficult to implement. > > On the other hand, the situation with this propsoal for such types > is then very similar to any other complex type expressions which > need to compared structurally in the middle end. So what I am > wondering is whether it would be possible to do such comparisons > in the middle end also for tagged types? The middle-end ensures there's only one such type via hashing types via type_hash_canon. > Finally, how does LTO does it? It somehow also needs to unify > different tagged types? Could we reuse this mechanism somehow? LTO structurally merges types via TYPE_CANONICAL. But rules for merging depend on language semantics, too much merging hinders optimization. > > Btw, for you example, how do you expect debug information to look like? > > Would there be two type definitions that are not related? > > I don't know yet. This is why I am trying to implement it, to > figure out all these practical issues. How does it work now for > tagged types in different TUs that are compatible? You get two copies. Richard. > Best, > Martin
Re: compatibility of structs/unions/enums in the middle end
Am Mittwoch, den 02.10.2019, 14:18 +0200 schrieb Richard Biener: > On Wed, Oct 2, 2019 at 1:57 PM Uecker, Martin > wrote: > > Thank you for your answers. > > Finally, how does LTO does it? It somehow also needs to unify > > different tagged types? Could we reuse this mechanism somehow? > > LTO structurally merges types via TYPE_CANONICAL. But rules > for merging depend on language semantics, too much merging > hinders optimization. LTO would need to merge types with identical tag and structure across TUs anyway as this is needed for C programs to work. But this implies that it also must merge such types inside a TU (because merging enforces an equivalence relationship). So if I am not missing anything important, LTO would already implement the exact semantics which I propose for C2X. Best, Martin
Re: compatibility of structs/unions/enums in the middle end
On Wed, Oct 2, 2019 at 2:35 PM Uecker, Martin wrote: > > Am Mittwoch, den 02.10.2019, 14:18 +0200 schrieb Richard Biener: > > On Wed, Oct 2, 2019 at 1:57 PM Uecker, Martin > > wrote: > > > > > Thank you for your answers. > > > > Finally, how does LTO does it? It somehow also needs to unify > > > different tagged types? Could we reuse this mechanism somehow? > > > > LTO structurally merges types via TYPE_CANONICAL. But rules > > for merging depend on language semantics, too much merging > > hinders optimization. > > LTO would need to merge types with identical tag and structure > across TUs anyway as this is needed for C programs to work. > But this implies that it also must merge such types inside a TU > (because merging enforces an equivalence relationship). > So if I am not missing anything important, LTO would already > implement the exact semantics which I propose for C2X. Sure LTO handles C2X fine. The issue is that it creates way larger equivalence classes than necessary for C2X (it has to work across language boundaries where compatibility is much less specified). Richard. > Best, > Martin
Re: compatibility of structs/unions/enums in the middle end
On Wed, Oct 2, 2019 at 3:10 PM Richard Biener
wrote:
>
> On Wed, Oct 2, 2019 at 2:35 PM Uecker, Martin
> wrote:
> >
> > Am Mittwoch, den 02.10.2019, 14:18 +0200 schrieb Richard Biener:
> > > On Wed, Oct 2, 2019 at 1:57 PM Uecker, Martin
> > > wrote:
> > > >
> >
> > Thank you for your answers.
> >
> > > > Finally, how does LTO does it? It somehow also needs to unify
> > > > different tagged types? Could we reuse this mechanism somehow?
> > >
> > > LTO structurally merges types via TYPE_CANONICAL. But rules
> > > for merging depend on language semantics, too much merging
> > > hinders optimization.
> >
> > LTO would need to merge types with identical tag and structure
> > across TUs anyway as this is needed for C programs to work.
> > But this implies that it also must merge such types inside a TU
> > (because merging enforces an equivalence relationship).
> > So if I am not missing anything important, LTO would already
> > implement the exact semantics which I propose for C2X.
>
> Sure LTO handles C2X fine. The issue is that it creates way
> larger equivalence classes than necessary for C2X (it has to
> work across language boundaries where compatibility is much
> less specified).
Oh, and LTO does _not_ merge types declared inside a function,
so
void foo () { struct S { int i; }; }
void bar () { struct S { int i; }; }
the two S are distinct and objects of that type do not conflict.
Richard.
> Richard.
>
> > Best,
> > Martin
Re: compatibility of structs/unions/enums in the middle end
Am Mittwoch, den 02.10.2019, 15:12 +0200 schrieb Richard Biener:
> On Wed, Oct 2, 2019 at 3:10 PM Richard Biener
> wrote:
> >
> > On Wed, Oct 2, 2019 at 2:35 PM Uecker, Martin
> > wrote:
> > >
> > > Am Mittwoch, den 02.10.2019, 14:18 +0200 schrieb Richard Biener:
> > > > On Wed, Oct 2, 2019 at 1:57 PM Uecker, Martin
> > > > wrote:
> > > > >
> > >
> > > Thank you for your answers.
> > >
> > > > > Finally, how does LTO does it? It somehow also needs to unify
> > > > > different tagged types? Could we reuse this mechanism somehow?
> > > >
> > > > LTO structurally merges types via TYPE_CANONICAL. But rules
> > > > for merging depend on language semantics, too much merging
> > > > hinders optimization.
> > >
> > > LTO would need to merge types with identical tag and structure
> > > across TUs anyway as this is needed for C programs to work.
> > > But this implies that it also must merge such types inside a TU
> > > (because merging enforces an equivalence relationship).
> > > So if I am not missing anything important, LTO would already
> > > implement the exact semantics which I propose for C2X.
> >
> > Sure LTO handles C2X fine. The issue is that it creates way
> > larger equivalence classes than necessary for C2X (it has to
> > work across language boundaries where compatibility is much
> > less specified).
Ok, using this would also for our purposes would pessimize things
too much.
> Oh, and LTO does _not_ merge types declared inside a function,
> so
>
> void foo () { struct S { int i; }; }
> void bar () { struct S { int i; }; }
>
> the two S are distinct and objects of that type do not conflict.
This is surprising as these types are compatible across TUs. So
if some pointer is passed between these functions this is
supposed to work.
Best,
Martin
Re: compatibility of structs/unions/enums in the middle end
On October 2, 2019 3:55:43 PM GMT+02:00, "Uecker, Martin"
wrote:
>Am Mittwoch, den 02.10.2019, 15:12 +0200 schrieb Richard Biener:
>> On Wed, Oct 2, 2019 at 3:10 PM Richard Biener
>> wrote:
>> >
>> > On Wed, Oct 2, 2019 at 2:35 PM Uecker, Martin
>> > wrote:
>> > >
>> > > Am Mittwoch, den 02.10.2019, 14:18 +0200 schrieb Richard Biener:
>> > > > On Wed, Oct 2, 2019 at 1:57 PM Uecker, Martin
>> > > > wrote:
>> > > > >
>> > >
>> > > Thank you for your answers.
>> > >
>> > > > > Finally, how does LTO does it? It somehow also needs to unify
>> > > > > different tagged types? Could we reuse this mechanism
>somehow?
>> > > >
>> > > > LTO structurally merges types via TYPE_CANONICAL. But rules
>> > > > for merging depend on language semantics, too much merging
>> > > > hinders optimization.
>> > >
>> > > LTO would need to merge types with identical tag and structure
>> > > across TUs anyway as this is needed for C programs to work.
>> > > But this implies that it also must merge such types inside a TU
>> > > (because merging enforces an equivalence relationship).
>> > > So if I am not missing anything important, LTO would already
>> > > implement the exact semantics which I propose for C2X.
>> >
>> > Sure LTO handles C2X fine. The issue is that it creates way
>> > larger equivalence classes than necessary for C2X (it has to
>> > work across language boundaries where compatibility is much
>> > less specified).
>
>Ok, using this would also for our purposes would pessimize things
>too much.
>
>> Oh, and LTO does _not_ merge types declared inside a function,
>> so
>>
>> void foo () { struct S { int i; }; }
>> void bar () { struct S { int i; }; }
>>
>> the two S are distinct and objects of that type do not conflict.
>
>This is surprising as these types are compatible across TUs. So
>if some pointer is passed between these functions this is
>supposed to work.
So if they are compatible the frontend needs to mark them so in this case.
Richard.
>Best,
>Martin
Re: syncing the GCC vax port, atomic issue
On Wed, Oct 02, 2019 at 10:39:23AM +0100, Richard Earnshaw (lists) wrote: > There are some target hooks in combine that might help here. > targetm.cannot_copy_insn_p and targetm.legitimate_combined_insn. The > former is used more widely than just combine, so you might need to be > careful that it doesn't adversely affect other optimizations. The > latter relies on spotting that the combined insn is doing something > stupid even though it matches a pattern in the back-end. So it may be > that neither really solves your problem in this case. Well, if what you need to prevent here is two branches from being combined into one, you need to prevent many more passes than just combine from doing the same, so this hook won't really help you. I don't quite see why the generic optimisers make something that ICEs later here, but yeah UNSPECs can side-step this whole issue. Segher
Re: compatibility of structs/unions/enums in the middle end
Am Mittwoch, den 02.10.2019, 17:37 +0200 schrieb Richard Biener:
> On October 2, 2019 3:55:43 PM GMT+02:00, "Uecker, Martin"
>
> wrote:
> > Am Mittwoch, den 02.10.2019, 15:12 +0200 schrieb Richard Biener:
> > > On Wed, Oct 2, 2019 at 3:10 PM Richard Biener
> > > wrote:
> > > >
...
> > > Oh, and LTO does _not_ merge types declared inside a function,
> > > so
> > >
> > > void foo () { struct S { int i; }; }
> > > void bar () { struct S { int i; }; }
> > >
> > > the two S are distinct and objects of that type do not conflict.
> >
> > This is surprising as these types are compatible across TUs. So
> > if some pointer is passed between these functions this is
> > supposed to work.
>
> So if they are compatible the frontend needs to mark them so in this case.
It can't. The front end never sees the other TU.
Best,
Martin
Re: Adding -Wshadow=local to gcc build rules
On 9/18/19 3:08 PM, Bernd Edlinger wrote: > Hi, > > I'm currently trying to add -Wshadow=local to the gcc build rules. > I started with -Wshadow, but gave up that idea immediately. > > As you could expect the current code base has plenty of shadowed > local variables. Most are trivial to resolve, some are less trivial. > I am not finished yet, but it is clear that it will be a rather big > patch. > > I would like to ask you if you agree that would be a desirable step, > in improving code quality in the gcc tree. > > > Thanks > Bernd. > Hurray!!! The build is now working with -Wshadow=local and I need to sort out the changes. I hope you are gonna like it :-) Currently it is a 600K patch file all together. Some parts are not trivial at all, but I hope it will pay off in more easy to follow code in various places and less errors in new code. Also one or two real bugs were hiding near the shadowed variable. Most of which are of the obvious kind where, one variable is shadowed by another one, and either the inner or the outer variable need to be renamed from name to name1, or i to j/k, or p to q, or x to y. Sometimes also to name2 or name3, etc. If it is a location_t I follow common practice that loc is renamed to loc0. I avoid renaming a parameter, unless it causes much more changes. Also when a renamed variable appears to be named in a comment I also update the comment. I tried to make the change smaller if possible, rather often the shadowed variable is of the exact same type, and no longer used at the place where the variable is declared again. I consider "unsigned" and "unsigned int" as too different to re-use the variable (or parameter). This means I did consider the control flow and data flow around each shadowed variable if avoiding the duplicate variable is safe. Unless there is disagreement I will go ahead and commit trivial parts after careful regression-testing under the obvious rule. I did also try to build a lot of cross compilers to make sure that the targets do not break when the warning is enabled. But it is nevertheless rather likely that you will see some fall-out once the warning will be enabled. So far each target (except tilepro) needed at least a few changes. This is the list of changed files: M ada/gcc-interface/decl.c M ada/gcc-interface/trans.c M asan.c M attribs.c M auto-inc-dec.c M bb-reorder.c M brig/brigfrontend/brig-basic-inst-handler.cc M brig/brigfrontend/brig-code-entry-handler.cc M brig/brigfrontend/brig-function-handler.cc M brig/brigfrontend/brig-util.cc M builtins.c M c/c-decl.c M c/c-parser.c M c/c-typeck.c M c/gimple-parser.c M c-family/c-ada-spec.c M c-family/c-common.c M c-family/c-cppbuiltin.c M c-family/c-lex.c M c-family/c-omp.c M caller-save.c M calls.c M cfg.c M cfgbuild.c M cfgcleanup.c M cfgexpand.c M cfgloopmanip.c M cfgrtl.c M cgraph.c M cgraph.h M cgraphbuild.c M cgraphclones.c M cgraphunit.c M combine.c M config/aarch64/aarch64.c M config/aarch64/cortex-a57-fma-steering.c M config/aarch64/falkor-tag-collision-avoidance.c M config/alpha/alpha.c M config/arm/arm.c M config/csky/csky.c M config/elfos.h M config/i386/i386-expand.c M config/i386/i386-features.c M config/i386/i386-options.c M config/i386/i386.c M config/i386/x86-tune-sched.c M config/ia64/ia64.c M config/m68k/m68k.c M config/m68k/m68k.md M config/microblaze/microblaze.c M config/mips/mips.c M config/nios2/nios2.c M config/pa/pa.c M config/pa/pa.md M config/rs6000/rs6000-call.c M config/rs6000/rs6000-logue.c M config/rs6000/rs6000-p8swap.c M config/rs6000/rs6000.c M config/rs6000/rs6000.md M config/s390/s390.c M config/sh/sh.c M config/sparc/sparc.c M config/xtensa/xtensa.c M configure M configure.ac M cp/call.c M cp/class.c M cp/constexpr.c M cp/constraint.cc M cp/cp-gimplify.c M cp/decl.c M cp/decl2.c M cp/error.c M cp/friend.c M cp/init.c M cp/method.c M cp/name-lookup.c M cp/parser.c M cp/pt.c M cp/rtti.c M cp/semantics.c M cp/typeck.c M cp/typeck2.c M cprop.c M cse.c M cselib.c M d/d-codegen.cc M d/decl.cc M d/dmd/doc.c M d/dmd/dscope.c M d/dmd/initsem.c M d/expr.cc M defaults.h M df-problems.c M df-scan.c M diagnostic-show-locus.c M doc/invoke.texi M dse.c M dumpfile.h M dwarf2cfi.c M dwarf2out.c M emit-rtl.c M expmed.c M expr.c M final.c M fold-const.c M fortran/arith.c M fortran/class.c M fortran/decl.c M fortran/dependenc
Go reposrgeon is production ready
Today I retired the original Python version of the reposurgeon code. I plan to spend the next couple of days fixing minor bugs that I was deferring until the Go port was finished. Then I'll dive back into the gcc conversion. Barring an emergency on the NTPsec project, I should be able to concentrate on the conversion until it's done. -- http://www.catb.org/~esr/";>Eric S. Raymond Our society won't be truly free until "None of the Above" is always an option.
