This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: using plugin and lto: problem linking c-pragma symbol


On Mon, 06 Jun 2011 10:41:49 -0400
Robert Dewar <dewar@adacore.com> wrote:

> On 6/6/2011 10:33 AM, Joseph S. Myers wrote:
> 
> >> Now, if we wanted to pack all the state of GCC inside some (very few,
> >> perhaps only one) variable, we would have to change most of the functions
> >> inside it. Perhaps the patch would be cosmetic, but it certainly would be
> >> very big.
> 
> I can't see any reason for packing everything into one variable. What
> possible gain is this? It might make some silly metric that counts
> global variables happier, but I don't see any practical gain, and in
> practice it would be obfuscation. Of course some packaging may be
> helpful, but going all the way to one global variable to me is
> nonsense.


Sorry, I did not mean a variable; but an "object" or a data (hopefully,
dynamically allocated, or stack-allocated often in main), but not a
global thing. In the same message, I referred to QApplication or
GtkApplication, as an example. See
http://doc.qt.nokia.com/latest/qapplication.html
(sadly QApplication can have only one instance and it keeps a pointer
to that in some static data). An older example is X11 Xlib Display
data. There is usually one, but there could be several instances of it
(e.g. in applications connecting to several X11 servers).
http://tronche.com/gui/x/xlib/display/opening.html

And regarding variables, this reminds me of one thing I don't
understand about lang_hooks. Why is it a variable (of some struct type)
and not a data? Why is there no (unless I am mistaken, which I could be
because that part of GCC is not familiar to me) lang_hook data, and
some function which would allocate or initialize it, with other parts
of the compiler getting that lang_hook data thru a given pointer (not a
global thing).  In gcc/lang-hooks.h near line 481 there is a struct
lang_hooks hang_hooks global variable, and I don't understand why is it
not a data, initialized by the user, and passed to other code.

So I agree that I choose the wrong word (I really meant "data" not
"variable" and referred to GtkApplication & QApplication as an example).
But then your (and also mine) objection that there is no good reason to
pack everything in a variable exists and applies, and I can't
understand why the lang_hook variable exist (but I do know it is a very 
important thing in GCC).

This is why I thought that "modularization" is a distant goal: in my
very naive opinion, it would mean removing important global data like
lang_hook, and I still believe that such a patch would be very big: one
can't remove that variable lang_hook -replacing it by some data
structure allocated or initialized suitably, which is not a global
variable- incrementally (and replace it by some data passed somehow).

My naive opinion is that if (this is a dream) GCC had no global state,
it would improve its modularity, by forcing the definition of a well
defined API to initialize and manipulate such states. And in that
modular dream, one could even have several states in parallel.
The tinycc compiler (which by all measures is a toy compiler, when
compared to the giant GCC) has apparently such a state, which sadly is
partly copied into some global variable -this is one of many tinycc
bugs!...
http://www.mail-archive.com/tinycc-devel@nongnu.org/msg01758.html I
would guess LLVM has also similar state-keeping data.

The silly example I gave was running both gcc-5.1 & gcc-5.2 in two
different threads of the same process. I agree it is a very silly
example, but I would suppose that when that would be possible, GCC
would have to be very modular.

Sorry for having wrongly expressed my thoughts. I mean data (or
object), not variable!

Regards.
-- 
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} ***


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]