Re: Unifying the GCC Debugging Interface
Hi, On Fri, Nov 16, 2012 at 08:08:52AM -0500, Diego Novillo wrote: > On Fri, Nov 16, 2012 at 4:38 AM, Martin Jambor wrote: > > > So you do not plan to replace/rename at least some of them? This > > seems like unnecessary and confusing layering just to avoid the work > > to do the right thing. > > No, we plan to replace all the existing dumping routines. We are just > not planning to add *new* ones. Duplicating the existing routines > would indeed be useless. > > >> > >> dump_raw > >> > >> This function overload set provides the raw oriented dump, > >> e.g. a tuple. > > > > I'm not sure I understand the whole raw thing. > > This is to distinguish between: > > a = b + c; > > from > > > > ASTs and RTL have something similar. The raw output gives you a > different view. Not every data structure will have that distinction. > > > > I'm afraid we can't really always rely on overloading. For example, > > even though I often use debug_tree to examine a tree, probably even > > more often I just use debug_generic_expr. When I write stuff into a > > dump file, I rarely ever use the verbose variants but I certainly want > > them to exist. And there might be other similar cases, like the > > .*_brief dumping functions that are sometimes also used. > > Sure. The idea is to provide these variants via symbolic TDF_ style > flags. For combinations that are very popular, we provide alternate > entry names so that you don't have to be specifying the flags all the > time. Well, this is what I was actually afraid of. If things like generic or tree dump of a tree value is selected by new TDF_ flags, then you are in danger of just replacing current mess in function names by a mess of constants. I'd much rather have functions dump_generic, dump_tree (and dump_function!), with consistent parameters, for the three very different dumps than TDF_gimple, TDF_tree and TDF_function constants which would do some sort of second level function overloading. I understand my approach would not be a real grand unification, but I believe that either way we'll have to remember a few identifiers to make dumping useful. Yes, there is a lot of space for simplification so that we need to remember fewer and the parameters should be made much more consistent but I think this is not the place where overloading-only is appropriate for many uses. Moreover, would the TDF_ constants be available in gdb? IIRC hen I use them from gdb, I always have to pass numbers. Thanks, Martin > > > > Nevertheless, it would be great if we had fewer and consistent names > > of dumping functions, even though perhaps not just three. It would > > also be nice if all the file variants had an integer indent parameter > > ;-) > > Ah, good idea. Thanks. > > > Diego.
Implementing gcc pass - gcc crashes
Hi.
As an exercise, I am trying to implement a simple gcc pass
that unrolls the loops that have transactions.
The pass first identifies all the loops that have transactions,
and latter it unrolls the loop once by copying the loop body.
The pass works when I run gcc with -O0,
but it crashes gcc with -Ox (where x >= 0).
The diff in the attachment is made on the following branch:
remotes/origin/gcc-4_7-branch
git commit: 7551be1b393663d7034b30dc0be0560d7bab265c
Please, can somebody explain me what I am doing wrong?
Thanks,
Srdjan
P.S.
The code that I am transforming is the following:
/* hello.c */
int a;
int main(int argc, char* argv[]) {
int n = atoi(argv[1]);
int i;
for (i = 0; i < n; ++i) {
__transaction_atomic {
++a;
}
}
printf("%d\n", a);
return 0;
}
And I want to transform it to the:
/* hello.c */
int a;
int main(int argc, char* argv[]) {
int n = atoi(argv[1]);
int i;
for (i = 0; i < n; ++i) {
__transaction_atomic {
++a;
}
++i;
if (i >= n) break;
__transaction_atomic {
++a;
}
}
printf("%d\n", a);
return 0;
}
This is the compiler error message:
~/tm: ~/prog/gcc2/bin/gcc-4.7 hello.c -fgnu-tm -static -funroll2 -v -O1
Using built-in specs.
COLLECT_GCC=/home/srdjan/prog/gcc2/bin/gcc-4.7
COLLECT_LTO_WRAPPER=/home/srdjan/prog/gcc2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-repo/configure --prefix=/home/srdjan/prog/gcc2
--disable-bootstrap CFLAGS='-g3 -O0' --enable-languages=c
--disable-multilib --program-suffix=-4.7 --enable-checking=all
Thread model: posix
gcc version 4.7.3 20121115 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-fgnu-tm' '-static' '-funroll2' '-v' '-O1'
'-mtune=generic' '-march=x86-64' '-pthread'
/home/srdjan/prog/gcc2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1
-quiet -v -D_REENTRANT hello.c -quiet -dumpbase hello.c -mtune=generic
-march=x86-64 -auxbase hello -O1 -version -fgnu-tm -funroll2 -o
/tmp/ccgjXgEO.s
GNU C (GCC) version 4.7.3 20121115 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=0 --param ggc-min-heapsize=0
ignoring nonexistent directory
"/home/srdjan/prog/gcc2/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/srdjan/prog/gcc2/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include
/usr/local/include
/home/srdjan/prog/gcc2/include
/home/srdjan/prog/gcc2/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.7.3 20121115 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=0 --param ggc-min-heapsize=0
Compiler executable checksum: 1e5f74bf79add0dcb61ed00160af061e
hello.c: In function ‘main’:
hello.c:11:3: warning: incompatible implicit declaration of built-in
function ‘printf’ [enabled by default]
hello.c:13:1: error: SSA_NAME_DEF_STMT is wrong
Expected definition statement:
# .MEM_21 = VDEF <.MEM_12>
__transaction_atomic // SUBCODE=[ GTMA_HAVE_LOAD GTMA_HAVE_STORE ]
Actual definition statement:
# .MEM_15 = VDEF <.MEM_12>
__transaction_atomic // SUBCODE=[ GTMA_HAVE_LOAD GTMA_HAVE_STORE ]
hello.c:13:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
gcc_unroll_tx_pass.diff
Description: Binary data
int a;
int main(int argc, char* argv[]) {
int n = atoi(argv[1]);
int i;
for (i = 0; i < n; ++i) {
__transaction_atomic {
++a;
}
}
printf("%d\n", a);
return 0;
}
Re: Unifying the GCC Debugging Interface
On Mon, Nov 19, 2012 at 5:18 AM, Martin Jambor wrote: > Hi, > > On Fri, Nov 16, 2012 at 08:08:52AM -0500, Diego Novillo wrote: >> On Fri, Nov 16, 2012 at 4:38 AM, Martin Jambor wrote: >> >> > So you do not plan to replace/rename at least some of them? This >> > seems like unnecessary and confusing layering just to avoid the work >> > to do the right thing. >> >> No, we plan to replace all the existing dumping routines. We are just >> not planning to add *new* ones. Duplicating the existing routines >> would indeed be useless. >> >> >> >> >> dump_raw >> >> >> >> This function overload set provides the raw oriented dump, >> >> e.g. a tuple. >> > >> > I'm not sure I understand the whole raw thing. >> >> This is to distinguish between: >> >> a = b + c; >> >> from >> >> >> >> ASTs and RTL have something similar. The raw output gives you a >> different view. Not every data structure will have that distinction. >> >> >> > I'm afraid we can't really always rely on overloading. For example, >> > even though I often use debug_tree to examine a tree, probably even >> > more often I just use debug_generic_expr. When I write stuff into a >> > dump file, I rarely ever use the verbose variants but I certainly want >> > them to exist. And there might be other similar cases, like the >> > .*_brief dumping functions that are sometimes also used. >> >> Sure. The idea is to provide these variants via symbolic TDF_ style >> flags. For combinations that are very popular, we provide alternate >> entry names so that you don't have to be specifying the flags all the >> time. > > Well, this is what I was actually afraid of. If things like generic > or tree dump of a tree value is selected by new TDF_ flags, then you > are in danger of just replacing current mess in function names by a > mess of constants. No, that's not so. Combinations of flags that are very popular will have named entry points. Additionally, the functions you mention (dump_generic, dump_tree and dump_function) are actually three "different" data structures (at least at the conceptual level, since they are all trees), so they remain different entry points. The TDF_* flags are always going to be modifiers that alter the flavour of a given data structure, they are not selectors of different concepts that happen to use the same data structure. > Moreover, would the TDF_ constants be available in gdb? IIRC hen I > use them from gdb, I always have to pass numbers. Absolutely. I also dislike having to use numbers. Diego.
Re: Unifying the GCC Debugging Interface
Hi, On Mon, 19 Nov 2012, Martin Jambor wrote: > Well, this is what I was actually afraid of. If things like generic > or tree dump of a tree value is selected by new TDF_ flags, then you > are in danger of just replacing current mess in function names by a > mess of constants. I'd much rather have functions dump_generic, > dump_tree (and dump_function!), with consistent parameters, for the > three very different dumps than TDF_gimple, TDF_tree and TDF_function > constants which would do some sort of second level function > overloading. I understand my approach would not be a real grand > unification, but I believe that either way we'll have to remember a > few identifiers to make dumping useful. And -completion is faster with different function names than when the larger layout (in contrast to some little details) is determined by a flag. Look: (gdb) dump_stuff (t, TDF_function) vs (gdb) dump_function (t) So, yes, the larger layouting should be determined by name of the dump function. A flag argument might look nice from an interface design perspective, but it's harder to use in the debugger. Ciao, Michael.
Re: Unused Field in graphite-poly.h?
Hi, On Fri, 16 Nov 2012, Lawrence Crowl wrote: > I think the field "htab_t original_pddrs" in struct scop in > graphite-poly.h is unused. Seems I overlooked it during my post-isl cleanups. Yes, remove it. Ciao, Michael.
Re: Unifying the GCC Debugging Interface
On Mon, Nov 19, 2012 at 10:11 AM, Michael Matz wrote: > So, yes, the larger layouting should be determined by name of the dump > function. A flag argument might look nice from an interface design > perspective, but it's harder to use in the debugger. As long as all these different objects share the same data structure, we will need to have different named entry points. Ideally they would all respond to 'dump(t)' and overloading will figure it out automatically. For now, we'll need dump_function, dump_tree, dump_generic, and we may need a few more. Diego.
Re: RFC - Alternatives to gengtype
On Sun, Nov 18, 2012 at 06:37:29PM +, Jonathan Wakely wrote:
> On 18 November 2012 18:25, Basile Starynkevitch wrote:
> > On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote:
> >> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch
> >> wrote:
> >> > I really think that GCC need some form of garbage collector.
> > [...]
> >>
> >> What's wrong with std::shared_ptr?
> > How does it deal with complex circular references that every compiler has?
> >
> > I'm understanding that std::shared_ptr cannot realiably deal with circular
> > references
> > (because it maintains essentially a reference counter).
> >
> > Could you explain me how std::shared_ptr deal with circular references?
>
> See http://gcc.gnu.org/ml/gcc/2011-10/msg00285.html
Which mentions weak_ptr, which sort of prove my point.
You are suggesting that by appropriately and wisely mixing shared_ptr &
weak_ptr, some circular references could carefully be handled (with caution and
care).
I'm thinking that using them reliably in GCC (a so big piece of software that
very few people understand it enough) is practically impossible for newbies,
because it requires them to understand very deeply all
the possible interactions between other pieces of software and their own.
I do know about shared_ptr & weak_ptr (20+ years ago, I developped a lot of
NeWS code -NeWS was a graphical window server then developped at Sun and it has
also weak & shared references inside their PostScript superset). By experience,
these notions do not scale well to huge software base like GCC.
So my thinking is that, to lower the [huge] difficulties of enabling GCC
newbies to contribute robust code to GCC, a systematic approach like the one
given by gengtype+ggc, or the one possible with a real
garbage collector, you don't put the burden of knowing exactly where to put
shared_ptr, where to put auto_ptr, where to put weak_ptr, onto the shoulders of
GCC newbies. A garbage collector provides a systematic, fail-proof, solutions
(of course, even with a GC, memory leaks can happen; but they are much less
dangerous than sigsegv).
And notice also that the current GCC internal representations have very
incomplete documentation.
(most of the good documentation is outside GCC, e.g. on
http://www.cse.iitb.ac.in/grc/gcc-workshop-12/ etc). There is nowhere on
gcc.gnu.org a clear picture (or a clear, but complete text) of all the major
GCC internal representations (gimple, gimple_seq, basic_block, edge, loop,
cgraph, ...) and all their interdependencies.
I believe that GCC needs to worry much more about attracting and keeping new
young talents, and systematic solutions (like the one provided by a garbage
collector) are much more appropriate
than shared_ptr+weak_ptr tricks.
I am in favor of more generic and easy solutions, than ones which require a
deep knowledge of an huge existing undocumented or under-documented code base
(even if such approaches would slow down the compilation time a little bit; so
I would accept the 5% slowdown possible with Boehm GC).
I notice (and I am not alone) that most young people attracted by working on
compilation of procedural languages are today lurking on LLVM, not on GCC.
Using std::shared_ptr & std::weak_ptr reliably is not realistic for newbies on
a such large (and such under-documented) legacy code base as GCC. Gengtype+ggc
is ugly, but it did provide a systematic way to add data inside GCC.
shared_ptr+weak_ptr don't provide a systematic way.
Regards.
PS. LLVM has also a decisive documentation advantage w.r.t. GCC
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: RFC - Alternatives to gengtype
On 19 November 2012 19:35, Basile Starynkevitch wrote: > On Sun, Nov 18, 2012 at 06:37:29PM +, Jonathan Wakely wrote: >> On 18 November 2012 18:25, Basile Starynkevitch wrote: >> > On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote: >> >> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch >> >> wrote: >> >> > I really think that GCC need some form of garbage collector. >> > [...] >> >> >> >> What's wrong with std::shared_ptr? >> > How does it deal with complex circular references that every compiler has? >> > >> > I'm understanding that std::shared_ptr cannot realiably deal with circular >> > references >> > (because it maintains essentially a reference counter). >> > >> > Could you explain me how std::shared_ptr deal with circular references? >> >> See http://gcc.gnu.org/ml/gcc/2011-10/msg00285.html > > Which mentions weak_ptr, which sort of prove my point. Of course it mentions weak_ptr, that's the way shared_ptr is designed to deal with cycles. > You are suggesting that by appropriately and wisely mixing shared_ptr & > weak_ptr, some circular references could carefully be handled (with caution > and care). > I'm thinking that using them reliably in GCC (a so big piece of software that > very few people understand it enough) is practically impossible for newbies, > because it requires them to understand very deeply all > the possible interactions between other pieces of software and their own. No it doesn't. > I do know about shared_ptr & weak_ptr Then why did you ask how shared_ptr deals with circular references? > So my thinking is that, to lower the [huge] difficulties of enabling GCC > newbies to contribute robust code to GCC, a systematic approach like the one > given by gengtype+ggc, or the one possible with a real > garbage collector, you don't put the burden of knowing exactly where to put > shared_ptr, where to put auto_ptr, where to put weak_ptr, As I said in http://gcc.gnu.org/ml/gcc/2011-10/msg00285.html noone except you has mentioned auto_ptr, stop attacking that strawman. > onto the shoulders of GCC newbies. A garbage collector provides a systematic, > fail-proof, solutions (of course, even with a GC, memory leaks can happen; > but they are much less dangerous than sigsegv). Why would you get a sigsegv using shared_ptr and weak_ptr? This is another strawman. > I believe that GCC needs to worry much more about attracting and keeping new > young talents, and systematic solutions (like the one provided by a garbage > collector) are much more appropriate > than shared_ptr+weak_ptr tricks. Please stop referring to anything you don't like/understand as "tricks". > I am in favor of more generic and easy solutions, than ones which require a > deep knowledge of an huge existing undocumented or under-documented code base > (even if such approaches would slow down the compilation time a little bit; > so I would accept the 5% slowdown possible with Boehm GC). > > I notice (and I am not alone) that most young people attracted by working on > compilation of procedural languages are today lurking on LLVM, not on GCC. Which doesn't use tricks like GC, as has been pointed out to you repeatedly. > Using std::shared_ptr & std::weak_ptr reliably is not realistic for newbies > on a such large (and such under-documented) legacy code base as GCC. Simply claiming it repeatedly doesn't make it true.
Re: RFC - Alternatives to gengtype
On 11/17/12, Hans-Peter Nilsson wrote: > On Thu, 15 Nov 2012, Diego Novillo wrote: > > === Approach: Move GTY to cc1plus. > > > > Instead of a separate weak parser, we would make cc1plus > > understand GTY attributes. The compiler would emit IL in the > > object files instead of generating source. > > > > This solution would require a first boot stage that did not > > support PCH, because we cannot rely on the seed compiler > > supporting GTY. We would probably need to use the Boehm > > collector during the first stage as well. > > > > Because the first stage would be fundamentally different from the > > second stage, we may need to add an additional pass for correct > > object file comparisons. > > It sounds like this would, for cross-compilers, require a native > GTY-savvy g++? Please no. We cannot require a GTY savy seed compiler. In part, at least, because we do not have one now. :-) So, the GTY annotations would need to be invisible to the seed compiler. The implication is that the first built compiler does not have GGC and PCH. The first built compiler would, however, recognize GTY, and the second (and subsequent) built compiler would have these features. Because the first built compiler would not have GGC, we need some other memory management, and the Boehm collector is the nearest handy tool. -- Lawrence Crowl
Re: RFC - Alternatives to gengtype
On 11/16/12, Diego Novillo wrote: > On Nov 16, 2012 Basile Starynkevitch wrote: > > I actually disagree with the "Get rid of GC" idea, but I am not > > sure that we all understand the same thing about it (and I have > > the feeling of the opposite). I would probably agree with "Get > > rid of Gengtype+Ggc+PCH and replace it with something better" > > which might be what "Get rid of GC" mean. > > We mean get rid of it. No garbage collection, whatsoever. We both > think that it is better to structure the compiler around memory pools. > However, we also concede that we are probably in the minority and we > will need to keep GC around. > > > Thr fact that a compiler deals with a big lot of circular data > > makes me think that naive reference-counting approaches (and > > in my opinion, reference counting is just a very poor method > > of doing garbage collection, which does not work well with > > circular references) cannot work inside a compiler, why they > > do work inside graphical widget libraries ala Qt or GTK. > > > > Hence, I don't understand well how a pool-allocator would work > > in GCC without touching to a huge amount of code. > > Right. It would be a large effort to sort out. Particularly, > since GC has been around for a while and we've gotten lazy and > are probably relying on it quite a bit. For these reasons, > even if we convinced the community to go in this direction, > it would take a while to get there. > > > A big advantage of using Boehm GC is that the interface is > > familar to everyone, and that it handles very nicely local > > pointers without pain. So data inside passes could also > > be GC-ed. > > This may be the most practical approach long term. Boehm-gc is > a well supported and solid solution for GC. But we need to make > sure it works for us. While I think memory pools are the best long-term approach, we cannot get there in the short term. My preference for the short-term strategy is to place GTY allocation in the final destination address for PCH, and use the Boehm collector to manage that allocation. If the increase in PCH file size is unacceptable, then we can ensure we zero out unused memory and write/read that memory a compressed file. (PCH compresses pretty well already.) This approach has significant advantages. First, we do not need to do GTY annotations, which eliminates a source of error. Second, consequently, we do not need to upgrade gengtype to understand C++. Third, we still have garbage collection, so the vast bulk of the existing code will work unmodified. The only disadvantage, as near as I can tell, are small performance losses during normal compilation, and possibly somewhat larger losses for PCH. -- Lawrence Crowl
Unused components in sese.[hc]?
I believe the following components in sese.[hc] are completely unused. phis -- functions declared extern in sese.h but never defined extern void insert_loop_close_phis (htab_t, loop_p); extern void insert_guard_phis (basic_block, edge, edge, htab_t, htab_t); ivtype_map -- the hash table infrastructure is defined but never used. (In particular, the hash function and equality functions are defined but never used, and so no instances of the hash table can exist.) static inline ivtype_map_elt new_ivtype_map_elt (const char *cloog_iv, tree type) static void debug_ivtype_elt (ivtype_map_elt elt); static int debug_ivtype_map_1 (void **slot, void *s ATTRIBUTE_UNUSED); DEBUG_FUNCTION void debug_ivtype_map (htab_t map); hashval_t ivtype_map_elt_info (const void *elt); int eq_ivtype_map_elts (const void *e1, const void *e2); I have successfully built and tested with these components #if'd out. Should I remove them? -- Lawrence Crowl
Re: RFC - Alternatives to gengtype
On Mon, 19 Nov 2012, Lawrence Crowl wrote: > On 11/17/12, Hans-Peter Nilsson wrote: > > On Thu, 15 Nov 2012, Diego Novillo wrote: > > > === Approach: Move GTY to cc1plus. > > > > > > Instead of a separate weak parser, we would make cc1plus > > > understand GTY attributes. The compiler would emit IL in the > > > object files instead of generating source. > > > > > > This solution would require a first boot stage that did not > > > support PCH, because we cannot rely on the seed compiler > > > supporting GTY. We would probably need to use the Boehm > > > collector during the first stage as well. > > > > > > Because the first stage would be fundamentally different from the > > > second stage, we may need to add an additional pass for correct > > > object file comparisons. > > > > It sounds like this would, for cross-compilers, require a native > > GTY-savvy g++? Please no. > > We cannot require a GTY savy seed compiler. In part, at least, > because we do not have one now. :-) > > So, the GTY annotations would need to be invisible to the seed > compiler. The implication is that the first built compiler does > not have GGC and PCH. The first built compiler would, however, > recognize GTY, and the second (and subsequent) built compiler would > have these features. JFTR: above, I'm very explicitly referring to cross-compilers. For your comments above to be relevant to them, you seem to imply a different workflow for building cross-compilers than the current, in which one and the same host compiler builds a cross-compiler in a single stage. Currently there's no "second (and subsequent) built compiler" for the cross-compiler-build scenario; if you're referring to the just-built cross-compiler it doesn't matter whether it's GTY-savvy. Just mentioned in case this becomes relevant again; with Boehm GC or reference-counting pointers (I hope) it doesn't matter. It's similar to the native-compiler scenario only as far as requirements for the host compiler (compiling the first stage); you can "fix" both scenarios by requiring the host-compiler to be GTY-savvy. But for that to IMHO be tolerable, a few versions of GTY-savvy GCC have to be released before making any such a requirement. Not to mention that the first such release would likely contain bugs serious enough to be unusable for later versions. But you already agree that's not what should happen, so mentioned JFTR. > Because the first built compiler would not have GGC, we need some > other memory management, and the Boehm collector is the nearest > handy tool. I'd think the reference-counting-pointer scheme mentioned by others would be preferable as requiring less memory overhead but there you go. Trading one GC for another is simpler and better I guess, at least as a functional intermediate step. Maybe refcounting pointers can be better introduced later, if ever and measurably better. brgds, H-P
Re: Unused DSE Functions
On 11/12/12, Diego Novillo wrote: > On Mon, Nov 12, 2012 at 2:31 PM, Lawrence Crowl wrote: >> On 11/12/12, Lawrence Crowl wrote: >>> It appears that >>> >>> static bitmap clear_alias_sets = NULL; >>> >>> is never set, and as a consequence >>> >>> clear_alias_set_lookup (alias_set_type alias_set) >>> >>> is never called. This conclusion is reinforced because it >>> unconditionally uses htab_t clear_alias_mode_table, which is never >>> allocated. >> >> This is in dse.c. > > I looked at the comment above clear_alias_sets and it states that it > is only set by dse_record_singleton_alias_set, which has disappeared > from the source code. > > Richi, you removed dse_record_singleton_alias_set in March. Perhaps > this whole thing is dead code and should be removed? Richi, ping? -- Lawrence Crowl
Re: RFC - Alternatives to gengtype
On 11/19/2012 08:24 PM, Lawrence Crowl wrote: On 11/16/12, Diego Novillo wrote: On Nov 16, 2012 Basile Starynkevitch wrote: I actually disagree with the "Get rid of GC" idea, but I am not sure that we all understand the same thing about it (and I have the feeling of the opposite). I would probably agree with "Get rid of Gengtype+Ggc+PCH and replace it with something better" which might be what "Get rid of GC" mean. We mean get rid of it. No garbage collection, whatsoever. We both think that it is better to structure the compiler around memory pools. However, we also concede that we are probably in the minority and we will need to keep GC around. I wouldn't jump to that conclusion too quickly.I think we should be GC free as well, and I doubt I am the only other one. Andrew
Re: RFC - Alternatives to gengtype
Basile Starynkevitch writes: > PS. LLVM has also a decisive documentation advantage w.r.t. GCC What...? The last time I tried to do something with LLVM, the internals docs were awful (full of kinda stuff, usually just in the area I was confused about)... and gcc historically has had great internals documentation, though I don't know if it's managed to keep up with all the changes in the 4.x series... -miles -- "Yorton, Wressle, and Gospel Oak, the richness of your heritage is ended. We shall not stop at you again; for Dr Beeching stops at nothing."
Re: RFC - Alternatives to gengtype
On Tuesday 20 November 2012 10:30 AM, Miles Bader wrote: Basile Starynkevitch writes: PS. LLVM has also a decisive documentation advantage w.r.t. GCC What...? The last time I tried to do something with LLVM, the internals docs were awful (full of kinda stuff, usually just in the area I was confused about)... Yes but it is far better than that of GCC and the code itself is far better than GCC's code, not surprisingly because (a) it was designed in a closed group, (b) and the front end as well as back end were out of scope (c) back end generation from specification has remained out of scope In my opinion, at an abstract level the core LLVM is comparable to the framework of GIMPLE pass structure of GCC (and hence it is more easily describable). GCC on the other hand is a big spaghetti containing compiler generation thrown in. and gcc historically has had great internals documentation, though I don't know if it's managed to keep up with all the changes in the 4.x series... By great, if you mean in size, yes I agree with you :-) Otherwise, I strongly disagree with you. Please look up the teaching material and assignments available at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/ to see what the default GCC documentation lacks. Just as a case in point, try asking a novice to understand LTO from the official documentation and code and then refer him/her to my slides to understand LTO. Uday.
