Re: [Android] -fpic default option
On 18/11/2012, at 7:50 AM, Alexander Ivchenko wrote: > You are right, we are talking about the same things. The only open > question I see is regarding: > > In other cases we can safely assume > that the executable will be created and > in such case it would be a good idea to use -fPIE. > >>> I don't see why it would be a good idea to use -fPIE for most normal >>> user-space applications when -fno-pic would >>> suffice and provide better code. > > Do you agree that if the driver knows that the executable will be at > the end of the build > we can safely use -fno-pic or -fPIE to override -fpic default? If the driver can be sure that an executable is being compiled (which is a challenge in general case, but simple cases -- compilation of GCC testsuites -- can be accommodated) then it is OK to revert to default for a particular -linux-gnu target. For most architectures that would mean reverting to -fno-pic, but at least mips-linux-gnu uses -fpic by default in certain configurations. This is me not picking on your proposal, just alerting that -fno-pic may not be the right choice for executables for all targets. > I'm not > quite sure which one is better for Android; -fPIE will > give us all the security advantages of the position independent code > and probably is a better option. Using -fPIE will also bring all the performance drawbacks of PIC, there is a reason why -fPIE is not the most common way of building applications. I don't think Android is too security-concious a platform to warrant -fPIE (does Android even use address-space randomization?). Performance is a more serious consideration for its target market. Alexander, I appreciate you looking into -fpic vs -fno-pic compilation for Android. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
Re: RFC - Alternatives to gengtype
I agree with the analysis of Uday and Basile. In my view, competition from Clang and LLVM is probably the best thing that could've happened to a compiler that was in danger of becoming fat, lazy and complacent. Simplifying the code base for new contributors and increased maintainability are the main motivators for the cleanup efforts of the last few months (http://gcc.gnu.org/wiki/ImprovementProjects). However, let's discuss this topic in some other thread, please. I'd like to take this thread back to the original topic: what do we do with GC and PCH? Thanks. Diego.
Re: RFC - Alternatives to gengtype
On Sun, Nov 18, 2012 at 11:25:55AM -0500, Diego Novillo wrote:
> I agree with the analysis of Uday and Basile. [...]
>
> However, let's discuss this topic in some other thread, please. I'd
> like to take this thread back to the original topic: what do we do
> with GC and PCH?
I really think that GCC need some form of garbage collector.
If it is Ggc+gengtype (to be improved), or Boehm GC, or even
some other GC (for instance both
http://starynkevitch.net/Basile/qishintro.html and
http://gcc.gnu.org/viewcvs/branches/melt-branch/gcc/melt-runtime.c
are or contain precise copying collectors that I wrote, and with
some effort that could be made nicely compatible with C++).
But my feeling is that a lot of people don't want GCC to
have any kind of garbage collector and dream of having only manual
allocation & de-allocation (I Basile personally think that it is not realistic
and not desirable, because it will make future contributions to GCC much more
costly to develop, and I probably would myself lose interest in GCC
when garbage collection will be removed).
Regarding PCH [pre-compiled header], I think that it is related to PPH
[pre-processed headers]
I don't understand yet if PPH is abandoned, or just post-poned. I was
believing it was a very mature experimental branch.
A very related question, now that we have switched to C++, is: do we accept
the idea of having a common ancestor class (e.g. a GccObject root class
for GCC, like GObject is for GTK and QObject is for Qt) with virtual methods
(i.e. do we accept a vtable) for essential GCC datatypes like edge, gimple,
basic_block and tree-s. My understanding is that many people firmly reject
such an idea (probably because it might perhaps make gimple one word fatter).
But I would easily imagine that having a single top GccObject root class,
with several virtual abstract methods inside, could considerably help
in implementing new garbage collection scheme and a lot of utility
functionality (e.g. for dump perhaps LTO & perhaps PCH
we would just have some virtual methods in GccObject for them).
I also don't understand if PCH is really important; I feel that very few people
are using it (in particular, because it practically requires a single header
file for all of the application). In other words, could we give up PCH
(probably not, but I don't understand why), e.g. give up PCH for GCC 5.0
(and aim to have PPH for GCC 5.1)?
My feeling is that the question of having a garbage collector inside GCC
is not the same as the question of keeping gengtype+ggc in its present form
(or in an improved form).
At last, I don't understand if experimenting with e.g. a single GccObject
root class is easily feasible (is it a matter of just adding some inheritance
in a few *.h files, or is it much worse than that).
Now, I do admit that I don't have a clear overall picture about GCC,
and that all global reviewers have a much better whole picture of GCC than I do.
BTW, perhaps what might be missing is a good analysis & detailed metrics
of the existing GCC source base. Perhaps some plugin or extension of GCC
could help to make it.
(I Basile would be very happy to work on a MELT extension to access and
measure and navigate inside the entire GCC compiler, but this is a quite
big project, and I don't know how could I be funded to work on this).
Regards.
--
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 Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch wrote: > I really think that GCC need some form of garbage collector. > If it is Ggc+gengtype (to be improved), or Boehm GC, or even > some other GC (for instance both > http://starynkevitch.net/Basile/qishintro.html and > http://gcc.gnu.org/viewcvs/branches/melt-branch/gcc/melt-runtime.c > are or contain precise copying collectors that I wrote, and with > some effort that could be made nicely compatible with C++). > But my feeling is that a lot of people don't want GCC to > have any kind of garbage collector and dream of having only manual > allocation & de-allocation (I Basile personally think that it is not realistic > and not desirable, because it will make future contributions to GCC much more > costly to develop, and I probably would myself lose interest in GCC > when garbage collection will be removed). What's wrong with std::shared_ptr?
Re: RFC - Alternatives to gengtype
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?
Cheers.
--
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 18 November 2012 18:03, Basile Starynkevitch wrote: > Regarding PCH [pre-compiled header], I think that it is related to PPH > [pre-processed headers] > > I don't understand yet if PPH is abandoned, or just post-poned. I was > believing it was a very mature experimental branch. See http://gcc.gnu.org/ml/gcc/2012-11/msg00253.html
Re: RFC - Alternatives to gengtype
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
gcc-4.8-20121118 is now available
Snapshot gcc-4.8-20121118 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20121118/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 193607 You'll find: gcc-4.8-20121118.tar.bz2 Complete GCC MD5=845d31a60e26b091d7d0a40eac34cf33 SHA1=6586d863383d60e5266b0ee09652d7bf882cf6b9 Diffs from 4.8-2012 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
