On Wed, 2010-08-25 at 22:41 +0300, Laurynas Biveinis wrote: > > > Besides, testing any gengtype change is very expensive for us (& > > probably for others), because we have to regenerate all the gt*.[ch] > > generated files & rebuild the entire compiler at each test. Even with > > the help of ccache, that takes a lot of time.
Perhaps my words are not very exact. By testing I meant "debugging". Currently, we remove every gt* files after every our changes in gengtype.c and then we make the full compiler, and that does take a lot of time. I probably am confusing testing & debugging; from my point of view of gengtype hacker, it is the same! > > Can you elaborate? I think it's a matter of "make s-gtype" or from a > clean tree: configure, make all-build-libiberty configure-stage1-gcc > && cd gcc && make s-gtype and then you can compare the output with a > known good copy, in fact, as far as GCC patch testing is concerned, > gengtype probably has it easiest if the output does not change. Save > the rebuildings, bootstraps & testsuites for the final test before > submission. > > > A question for gengtype experts: what exactly determines the set of > > generated gt*.[ch] files? We have the fuzzy impression that even some > > ada specific files are generated while ada was not configured but we may > > be wrong. > > make s-gtype-input is your friend. Also look at GTFILES in Makefile. > Basically the output set is determined by the input set which in turn > is the GTFILES variable. The frontends are pulled in by @all_gtfiles@ > part of it which is defined by looping through all the language > frontend directories in gcc/configure.ac and I didn't really figure > out if it was intended to be affected by --enable-languages or not. > However, --enable-languages=c resulted in gtyp-input.list containing > all the frontends, so that's how the things are right now. > > There is also GTFILES_LANG_H and ALL_GTFILES_H in Makefile.in which > you can ignore for your purposes. > > > Laurynas, Ian, others, could you please explain in a few words how you > > believe the various languages (cp, ada, objc, ...) work inside gengtype? > > Obviously, the bitmask is representing a set of languages, but neither > > Jérémie nor me Basile grasped all the details... I am not sure to > > understand what exact parts of gengtype is using the [cp] & [ada] ... > > tags in gtype-input.list, > > These tags are recognized by read_input_line which returns true upon > encountering one to read_input_list, look at the lines 425-440. Upon > reading the tag gengtype knows what language assign the file names > that follow it until the next [language name] tag. IMHO this is quite > vital for correct language bitmap handling or what will replace it. We don't change the bitmap stuff, however, we do change the fact that in current gengtype the bitmap is stored four bytes before the path name string (we find that is an unreadable kludge). We now have a real input_file structure containing the bitmap and the path name. We are not changing the facts that input files have a lang bitmap nor how it is used. > > > and I am not sure to grasp what > > TYPE_LANG_STRUCT & TYPE_PARAM_STRUCT are exactly for, even if I do > > guess a bit. > > TYPE_LANG_STRUCT is for structs that have a definition per frontend, > struct lang_decl and lang_type are the canonical examples, which are > defined by all the rontends and handled naively would result in > duplicate name clashes. Thanks for the nice explanation. I would imagine it could even belong to gty.texi... > > TYPE_PARAM_STRUCT is orthogonal to the frontends, it's for > parameterized structs (GTY options param and param_is), since > parameterized structs need separate gengtype representations for each > parameterization. > > > Does the set of configure-d languages matter to gengtype? > > If yes, how? > > I guess no. Doesn't that contradict your explanation of GTFILES & @all_gtfiles@ a few paragraphs above or I very probably misunderstood you. If, as I believe, GTFILES is based upon @all_gtfiles@ which is autoconf-igured, then I would imagine the gtyp-input.list should also depend on it. But I find [ada] tag & ada related files there even when I did not mention ada to configure (but only C, C++, LTO). Or are you suggesting that @all_gtfiles@ is not really autoconf-igured and always the same? Probably yes, but then why use it? And by the way, we don't intend to change the output of gengtype. As far as I understand, our patch -in its current state- don't change it (except for the bug we are hunting; to be fair, the output is not changed for C frontend & gcc middle-end & back-end, and we still have a bug for gengtyping C++ frontend since a #define is incorrectly missing in the generated gtype-desc.h). We will work on that bug tomorrow. Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
