On 15/11/2012, at 2: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
> tests that fail on Android, but probably the problem is deeper than
> that and that would be only hiding our head in the sand.
The canonical way of building native applications for Android is to add
-fno-pic to the compiler flags. 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.
I think the right fix here is to add "-fno-pic" to dg-options for affected
tests in gcc.target/i386. For architecture-independent test, it may be more
prudent to use { target nonpic }, as you suggested, since we can't be sure that
a given target / multilib can handle non-pic code.
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
