Re: [Android] -fpic default option
>> The canonical way of building native applications for Android is to add
>> -fno-pic to the compiler flags.
That’s true for programs in userspace, but for Android system-level
programs (standalone executables) like system tools, console apps or
tests it seems -fpic doesn’t make much sense.
>> The intent was to make the most common behavior the default, and for Android
>> that
>> happens to be building shared libraries that can then be called through JNI.
Okay, but for building shared libs we either provide -shared to the
driver, or -c, right? In these cases
we can go with -fPIC by default. 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.
That would solve the problem with a lot of tests that failed on
Android and also with native applications (executables, not libs) that
are built
with -fPIC now. What do you think?
2012/11/15 H.J. Lu :
> On Wed, Nov 14, 2012 at 5:26 AM, Alexander Ivchenko
> wrote:
>> By default in Android we always compile with -fpic or -fPIC, even when
>> compiling executable. Because of that we have some test fails on
>> Android:
>>
>> For example:
>> gcc/testsuite/gcc.target/i386/pr47312.c
>> /* { dg-do run } */
>> /* { dg-options "-O2" } */
>>
>> void exit (int);
>> void noreturn_autodetection_failed ();
>> __attribute__ ((noinline))
>> detect_noreturn ()
>> {
>> exit (0);
>> }
>> int
>> main (void)
>> {
>> detect_noreturn ();
>> noreturn_autodetection_failed ();
>> return 0;
>> }
>>
>> If gcc knew, that we are not going to make a shared library (which is
>> implied if we are using pic option), then it would delete the call of
>> noreturn_autodetection_failed as a dead code. But in case of pic we
>> cannot rely on the fact that detect_noreturn () will not be
>> overwritten on runtime, eventhough we are compiling executable and
>> that will never happen! So in addition to several testfails, it seems
>> that we are losing an optimization opportunity here also.
>> I'm wondering, maybe we can use -fpie instead of -fpic by default in
>> the compiler (of course if there are no -shared or -c options; those
>> cases will mean that we cannot rely on the fact that we will have an
>> executable after linking)? It seems that it would solve the problem..
>> Of course we always can add something like { target nonpic } to all
>
> We should add { target nonpic } independent of Android.
>
>> tests that fail on Android, but probably the problem is deeper than
>> that and that would be only hiding our head in the sand.
>
> Using -fPIE to compile executables is a good idea.
>
> --
> H.J.
Re: Simplifying Gimple Generation
Hi Lawrence,
On Wed, 14 Nov 2012, Lawrence Crowl wrote:
> Diego and I seek your comments on the following (loose) proposal.
In principle I agree with the goal, I'm not sure I like the specific way
yet, and even if I do I have some suggestions:
> We will add a set of helper classes to be used as local variables
> to manage the details of handling the existing types.
I think one goal should be to minimize the number of those helper classes
if we can. And use clear names, for the statement builder e.g.
stmt_builder, or the like, not just ssa_seq.
> We propose a simplified form using new build helper classes ssa_seq
> and ssa_stmt that would allow the above code to be written as
> follows.
>
> ssa_seq q;
> ssa_stmt t = q.stmt (NE_EXPR, shadow, 0);
> ssa_stmt a = q.stmt (BIT_AND_EXPR, base_addr, 7);
> ssa_stmt b = q.stmt (shadow_type, a);
I think consistency should trump brevity here, so also add a tree code for
the converter, i.e.
ssa_stmt b = q.stmt (NOP_EXPR, shadow_type, a);
The method name should imply the action, e.g. 'add_stmt' or append_stmt
or the like. I'm not sure if we need the ssa_stmt class. We could use
overloading to accept 'gimple' as operands, with the understanding that
those will be implicitely converted to 'tree' by accessing the LHS:
gimple append_stmt (gimple g, tree_code code, gimple op1, tree op2)
{
return append_stmt (g, code, gimple_lhs (op1), op2);
}
(where gimple_lhs would ICE when the stmt in question doesn't have
one). As gimple statements are their own iterators meanwhile I'm not even
sure if you need the ssa_seq (or ssa_stmt_builder) class. The above
append_stmt would simply add the newly created statement to after 'g'.
That is, I'm not yet convinced that you really need any local data for
which you'd have to add helper classes.
So, you solve multiple problems (and I agree that they are problems), and
these are:
> There are a few important things to note about this example.
>
> .. We have a new class (ssa_seq) that knows how to sequence
> statements automatically and can build expressions out of types.
1) automatic sequencing; I think we don't need a helper class for that,
just new helper functions.
> .. Every statement created produces an SSA name. Referencing an
> ssa_stmt instance in a an argument to ssa_seq::stmt retrieves the
> SSA name generated by that statement.
2) gimple with LHS and their LHS are isomorphic; I think overloads will
solve this as well without a wrapper class.
>
> .. The statement result type is that of the arguments.
3) easy stmt building
3a) type inference; I agree with all your rules
> .. The type of integral constant arguments is that of the other
> argument. (Which implies that only one argument can be constant.)
>
> .. The 'stmt' method handles linking the statement into the sequence.
See 1)
> .. The 'set_location' method iterates over all statements.
So it iterates from the starting point of the ssa_seq to its end
(presumably only overriding locations that don't yet have one). This can
also be implemented by remembering the starting point of the gimple
sequence (I'd remember a gimple stmt, you have to remember the ssa_seq
object, so it's the same there).
All in all I think we can severely improve on building gimple statements
without introduction of any helper class. Basically, whenever a helper
class merely contains one member of a different type, then I think that
other type should be improved so that the wrapper class isn't necessary
anymore. Fewer types -> good :)
> Generating a Type
Apart from naming of some methods to imply the action done, I don't have
any opinion about this at this point. Though I agree that again the
boilerplate sequencing (_CONTEXT and _CHAIN) should be improved.
Ciao,
Michael.
Re: Simplifying Gimple Generation
On Thu, Nov 15, 2012 at 8:48 AM, Michael Matz wrote: [...] > The method name should imply the action, e.g. 'add_stmt' or append_stmt > or the like. strongly agreed. [...] > All in all I think we can severely improve on building gimple statements > without introduction of any helper class. Basically, whenever a helper > class merely contains one member of a different type, then I think that > other type should be improved so that the wrapper class isn't necessary > anymore. Fewer types -> good :) no, it is the opposite. Distinct abstractions should be materialized by distinct types. => less opportunities for bugs. -- Gaby
Re: Simplifying Gimple Generation
Hi, On Thu, 15 Nov 2012, Gabriel Dos Reis wrote: > On Thu, Nov 15, 2012 at 8:48 AM, Michael Matz wrote: > [...] > > The method name should imply the action, e.g. 'add_stmt' or append_stmt > > or the like. > > strongly agreed. > [...] > > > All in all I think we can severely improve on building gimple statements > > without introduction of any helper class. Basically, whenever a helper > > class merely contains one member of a different type, then I think that > > other type should be improved so that the wrapper class isn't necessary > > anymore. Fewer types -> good :) > > no, it is the opposite. Distinct abstractions should be materialized But the proposed improvements aren't distinct abstractions at all, they are interface cleanups and idiom shortenings. That's my point, those improvements should be made to the interface of the gimple type, so that working with that one becomes nicer, instead of adding an abstractiong with which working is easier than with gimple directly. It's not that our gimple interface is cast in stone so that we have to wrap it to improve it. We can _directly_ improve it. > by distinct types. => less opportunities for bugs. Ciao, Michael.
Re: Simplifying Gimple Generation
On Thu, Nov 15, 2012 at 9:01 AM, Michael Matz wrote: > Hi, > > On Thu, 15 Nov 2012, Gabriel Dos Reis wrote: > >> On Thu, Nov 15, 2012 at 8:48 AM, Michael Matz wrote: >> [...] >> > The method name should imply the action, e.g. 'add_stmt' or append_stmt >> > or the like. >> >> strongly agreed. >> [...] >> >> > All in all I think we can severely improve on building gimple statements >> > without introduction of any helper class. Basically, whenever a helper >> > class merely contains one member of a different type, then I think that >> > other type should be improved so that the wrapper class isn't necessary >> > anymore. Fewer types -> good :) >> >> no, it is the opposite. Distinct abstractions should be materialized > > But the proposed improvements aren't distinct abstractions at all, they > are interface cleanups and idiom shortenings. That's my point, those > improvements should be made to the interface of the gimple type, so that > working with that one becomes nicer, instead of adding an > abstractiong with which working is easier than with gimple directly. > > It's not that our gimple interface is cast in stone so that we have to > wrap it to improve it. We can _directly_ improve it. Without examples to show otherwise, I tend to agree with your point. David > >> by distinct types. => less opportunities for bugs. > > > Ciao, > Michael.
Re: bootstrap comparison failure ppc64 FreeBSD
On 14.11.12 21:57, Peter Bergner wrote: > On Wed, 2012-11-14 at 18:51 +0100, Andreas Tobler wrote: >> Hello, >> >> on trunk (193501) I get a comparison failure: >> --- >> Bootstrap comparison failure! >> gcc/tree-ssa-forwprop.o differs >> --- >> >> This is with --disable-checking. Leaving disable-checking away, the >> bootstrap completes succesfully. > > I just fired off a --disable-checking build and I see the same > thing on powerpc64-linux. > > >> -9658: e8 89 00 09 ldu r4,8(r9) >> -965c: 39 08 00 01 addir8,r8,1 >> +9658: 39 08 00 01 addir8,r8,1 >> +965c: e8 89 00 09 ldu r4,8(r9) > > Looks like a harmless scheduling difference, but enough trigger > the stage2/stage3 comparison. :( Thank you for confirming. I'll try to bisect this weekend. My last good results are from November 2nd. Andreas
Re: Unifying the GCC Debugging Interface
On 11/14/12, Andrew Pinski wrote: > On Nov 14, 2012, Lawrence Crowl wrote: >> Diego and I seek your comments on the following (loose) proposal. >> >> >> It is sometimes hard to remember which printing function is used >> for debugging a type, or even which type you have. >> >> We propose to rely on overloading to unify the interface to a small >> set of function names. Every major data type should have associated >> debug/dump functionality. We will unify the current *_dump/*_debug >> functions under the same common overloaded name. >> >> We intend to only apply this approach to functions that take the >> type to display as an argument, and that are routinely used in >> debugging. >> >> We propose to provide several function overload sets, as below. > > Here is my proposal though I don't have time to work on it. Make some > python scripts which do the basic function of the debug_* functions. > This way you can use them while debugging a core file and when the > stack has become full. As I said I don't have time to work on this > and really don't know python well enough to do it either. But I think > would be more useful than changing the debug functions inside gcc. The intent was to include debugging by adding source code. Python would not be available then. (It is a good solution for many tasks from within gdb.) > > Thanks. > Andrew Pinski > >> >> >> dump_pretty >> >> This function overload set provides the bulk of the printing. >> They will use the existing pretty-printer functions in their >> implementation. >> >> dump_raw >> >> This function overload set provides the raw oriented dump, >> e.g. a tuple. >> >> dump_verbose >> >> This function overload set provides the extra details dump. >> >> >> All of these functions come in two forms. >> >> function (FILE *, item_to_dump, formatting) >> function (item_to_dump, formatting) >> >> If the FILE* is not specified, the output is to stderr. The >> formatting argument is optional, with a default suitable to the kind >> of item to dump. >> >> >> We should remove tree-browser.c. It is not used at all and it is >> likely broken. >> >> -- >> Lawrence Crowl > -- Lawrence Crowl
Re: Simplifying Gimple Generation
On 11/14/12, Basile Starynkevitch wrote: > On Wed, Nov 14, 2012 at 05:13:12PM -0800, Lawrence Crowl wrote: >> Diego and I seek your comments on the following (loose) proposal. >> >> >> Generating gimple and tree expressions require lots of detail, >> which is hard to remember and easy to get wrong. There is some >> amount of boilerplate code that can, in most cases, be reduced and >> managed automatically. >> >> We will add a set of helper classes to be used as local variables >> to manage the details of handling the existing types. That is, >> a layer over 'gimple_build_*'. We intend to provide helpers for >> those facilities that are both commonly used and have room for >> significant simplification. > > I do agree (in principle) on this and the previous (debugging-like) > proposal, but: > > do you target the 4.8 release? (I believe not, since its stage 1 is > ending) Not 4.8. > do you intend to remove the current way of doing? Definitely not. Our intent is to provide an easier tool that accomplishes the common tasks. We expect that tricky stuff will use the existing interfaces. -- Lawrence Crowl
Re: Simplifying Gimple Generation
On 11/15/12, Michael Matz wrote:
> On Wed, 14 Nov 2012, Lawrence Crowl wrote:
> > Diego and I seek your comments on the following (loose) proposal.
>
> In principle I agree with the goal, I'm not sure I like the
> specific way yet, and even if I do I have some suggestions:
>
> > We will add a set of helper classes to be used as local variables
> > to manage the details of handling the existing types.
>
> I think one goal should be to minimize the number of those
> helper classes if we can. And use clear names, for the statement
> builder e.g. stmt_builder, or the like, not just ssa_seq.
The helper classes provide benefits.
They allow us to keep state needed to tie actions together.
Without that state, we would either require the user to create their
own extra variables, or require extending the representation of
the primary data structures. The former is a programming burden,
the latter is a space problem.
They allow us to use the same name for the same actions in two
different contexts. In particular, distinguishing between statement
construction in SSA and non-SSA.
> > We propose a simplified form using new build helper classes
> > ssa_seq and ssa_stmt that would allow the above code to be
> > written as follows.
> >
> > ssa_seq q;
> > ssa_stmt t = q.stmt (NE_EXPR, shadow, 0);
> > ssa_stmt a = q.stmt (BIT_AND_EXPR, base_addr, 7);
> > ssa_stmt b = q.stmt (shadow_type, a);
>
> I think consistency should trump brevity here, so also add a tree
> code for the converter, i.e.
>
> ssa_stmt b = q.stmt (NOP_EXPR, shadow_type, a);
Personally, I found that "NOP_EXPR" was confusing, because I was
expecting a cast operation. My expectation is that folks learning
GCC would have a lower hurdle without the misdirection. However,
I don't have strong feelings here.
> The method name should imply the action, e.g. 'add_stmt' or
> append_stmt or the like.
I was thinking more declaratively, but making it a verb is okay
with me.
> I'm not sure if we need the ssa_stmt class. We could use
> overloading to accept 'gimple' as operands, with the understanding
> that those will be implicitely converted to 'tree' by accessing
> the LHS:
>
> gimple append_stmt (gimple g, tree_code code, gimple op1, tree op2)
> {
> return append_stmt (g, code, gimple_lhs (op1), op2);
> }
>
> (where gimple_lhs would ICE when the stmt in question doesn't have
> one). As gimple statements are their own iterators meanwhile I'm
> not even sure if you need the ssa_seq (or ssa_stmt_builder) class.
> The above append_stmt would simply add the newly created statement
> to after 'g'.
Yes, simplifications like that were the intent.
> That is, I'm not yet convinced that you really need any local
> data for which you'd have to add helper classes.
We also need to ask if we will ever need local data. If we plan
for it now, future changes might be possible without affecting
existing code. Otherwise, we might require more substantial patches.
> So, you solve multiple problems (and I agree that they are
> problems), and these are:
>
> > There are a few important things to note about this example.
> >
> > .. We have a new class (ssa_seq) that knows how to sequence
> > statements automatically and can build expressions out of types.
>
> 1) automatic sequencing; I think we don't need a helper class
> for that, just new helper functions.
>
> > .. Every statement created produces an SSA name. Referencing an
> > ssa_stmt instance in a an argument to ssa_seq::stmt retrieves
> > the SSA name generated by that statement.
>
> 2) gimple with LHS and their LHS are isomorphic; I think overloads
> will solve this as well without a wrapper class.
>
> > .. The statement result type is that of the arguments.
>
> 3) easy stmt building
> 3a) type inference; I agree with all your rules
>
> > .. The type of integral constant arguments is that of the
> > other argument. (Which implies that only one argument can
> > be constant.)
> >
> > .. The 'stmt' method handles linking the statement into the
> > sequence.
>
> See 1)
>
> > .. The 'set_location' method iterates over all statements.
>
> So it iterates from the starting point of the ssa_seq to its end
> (presumably only overriding locations that don't yet have one).
> This can also be implemented by remembering the starting point
> of the gimple sequence (I'd remember a gimple stmt, you have to
> remember the ssa_seq object, so it's the same there).
>
> All in all I think we can severely improve on building gimple
> statements without introduction of any helper class. Basically,
> whenever a helper class merely contains one member of a different
> type, then I think that other type should be improved so that
> the wrapper class isn't necessary anymore. Fewer types -> good :)
While I would agree that unnecessary types are bad, I have found
that having types to represent distinct concepts is a good way to
structure my thinking and catch my errors.
> > Generating a Type
>
> Apart from naming of some methods to impl
RFC - Alternatives to gengtype
As we continue adding new C++ features in the compiler, gengtype is becoming an increasing source of pain. In this proposal, we want to explore different approaches to GC that we could implement. At this point, we are trying to reach consensus on the general direction that we should take. Given how intertwined GC and PCH are, the choices we make for one affect the other. We don't have a strong preference at the moment, but we are leaning in these directions: Diego: Get rid of GC completely. Move into pool allocation. If we continue to use GC, then either use boehm-gc or continue use the precise allocator, but with user generated marking. Lawrence: Get rid of GC completely. Move into pool allocation. If we continue to use GC, either move to user-generated marking or implement the GTY attributes in cc1plus (read below). For PCH, used a fixed address where all the PCH-able data would go, as this would represent less work than implementing streamable types. Gengtype is a poor C parser. It is a long way from handling all of the C++ constructs what are used by the C++ standard library. We have a few potential solutions. Solution: Stick with Gengtype As gengtype currently does not handle what we need, something must change. === Approach: Limit the Language Used We could avoid the problem by limiting the language we use to near that which gengtype currently understands. This approach has significant consequences. It will make the standard library incompatible with GTY. It will prevent the use of common idioms, such as iterators, within GTY types. These limitations are significant and not desirable. Approach: Upgrade Gengtype Full C++ support would essentially require building a new C++ parser. === Approach: Both Limit and Upgrade We can try upgrading gengtype to handle a more extensive subset of C++, without trying to handle the full language. See Thoughts on Gengtype and Single Inheritance. Taking this approach would likely mean we would be unable to use the C++ standard library within GCC. === 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. === Approach: Do GTY manually In this approach we would be converting GTY from a declarative form into a procedural one using the C++ type system and manually-implemented structure field handlers. At the highest level, this roughly means that all the structures using GTY(()) markers will start using GTY((user)). The marking code dealing with the semantics of the marked data structure is co-located with the data structure. When GC problems occur, this simplifies debugging. The user is no longer faced with a mass of auto generated code that is unfamiliar and hard to trace. The code to implement is straightforward. For every pointer field in the given instance pointer, a single "mark" function needs to be called. Common facilities to mark arrays will be provided via a base GC class. No generated header files to #include at the end of the source file. No new dependencies to add to the Makefile. No need to parse C++. The problem with this approach is that the declarative approach puts the field additions and the GTY annotations in the same place, as opposed to in separate code. While it is possible to use standard library containers with GC pointers in them, we would not be able to write these containers to PCH images. === Approach: Get rid of GTY This approach engenders more choices. The pre-compiled header implementation uses gengtype, so this approach is not viable unless we have an alternate implementation for PCH. We will also need another approach to memory management. === Approach: Permanent Addresses for PCH Create an alternate implementation of PCH using mmap and a region allocator. The essential difference is that we need to allocate the data structures in their final location, rather than the current approach of allocating someplace and then walking the trees to move them to the desired and fixed mmap address. Because this implementation would not do a final copy, it may leave allocation holes in the memory region. To reduce this cost, we can zero all unallocated memory in the region and then compress it before writing the PCH file. Compressing the file has already proven effective on existing PCH files, and so the compression work would not be a problem. We still need to indicate which objects go into PCH memory. For compiler-specif
Re: [Android] -fpic default option
On 15/11/2012, at 10:39 PM, Alexander Ivchenko wrote: >>> The canonical way of building native applications for Android is to add >>> -fno-pic to the compiler flags. > That’s true for programs in userspace, but for Android system-level > programs (standalone executables) like system tools, console apps or > tests it seems -fpic doesn’t make much sense. We seem to be saying the same thing, but it sounds like a disagreement. Native (as in non-java) applications should be compiled with -fno-pic as -fpic (and -fPIE) is unnecessary. > >>> The intent was to make the most common behavior the default, and for >>> Android that >>> happens to be building shared libraries that can then be called through JNI. > Okay, but for building shared libs we either provide -shared to the > driver, or -c, right? In these cases > we can go with -fPIC by default. Assuming normal build process (i.e., when one doesn't compile and link application in one command), by the time you provide -shared to the driver all the object files are already compiled. They /need/ to be compiled as PIC for use in shared library or /can/ be compiled as non-PIC for use in native executable. And there are also various games with partial linking. > 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. Am I missing something? Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
Re: expansion of vector shifts...
From: Richard Sandiford
Date: Mon, 29 Oct 2012 10:14:53 +
> ...given that the code is like you say written:
>
> if (SHIFT_COUNT_TRUNCATED)
> {
> if (CONST_INT_P (op1)
> ...
> else if (GET_CODE (op1) == SUBREG
> && subreg_lowpart_p (op1)
> && INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1
> op1 = SUBREG_REG (op1);
> }
>
> INTEGRAL_MODE_P (GET_MODE (op1)) might be better than an explicit
> VECTOR_MODE_P check. The code really doesn't make sense for anything
> other than integers.
>
> (It amounts to the same thing in practice, of course...)
Agreed, I've just committed the following. Thanks!
Fix gcc.c-torture/compile/pr53410-2.c on sparc.
* expmed.c (expand_shift_1): Don't strip non-integral SUBREGs.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@193547
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 2 ++
gcc/expmed.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9abd396..62bde4e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,7 @@
2012-11-15 David S. Miller
+ * expmed.c (expand_shift_1): Don't strip non-integral SUBREGs.
+
* configure.ac: Add check for assembler SPARC4 instruction
support.
* configure: Rebuild.
diff --git a/gcc/expmed.c b/gcc/expmed.c
index 5b697a1..8640427 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -2165,7 +2165,8 @@ expand_shift_1 (enum tree_code code, enum machine_mode
mode, rtx shifted,
% GET_MODE_BITSIZE (mode));
else if (GET_CODE (op1) == SUBREG
&& subreg_lowpart_p (op1)
- && INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1
+ && INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
+ && INTEGRAL_MODE_P (GET_MODE (op1)))
op1 = SUBREG_REG (op1);
}
--
1.7.12.2.dirty
