[testsuite] PATCH: Add check_effective_target_pie

[testsuite] PATCH: Add check_effective_target_pie

[H.J. Lu]

Hi,

This patch adds check_effective_target_pie to check if the current
multilib generatse PIE by default.  I will submit other patches to use
it.  OK for trunk?

Thanks.

H.J.
---
2015-01-11  H.J. Lu  <hongjiu.lu@intel.com>

	* gcc.target/i386/pie.c: New test.

	* lib/target-supports.exp (check_profiling_available): Return 0
	if PIE is enabled.
	(check_effective_target_pie): New.
---
 gcc/testsuite/gcc.target/i386/pie.c   | 12 ++++++++++++
 gcc/testsuite/lib/target-supports.exp | 15 +++++++++++++++
 2 files changed, 27 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/pie.c

diff --git a/gcc/testsuite/gcc.target/i386/pie.c b/gcc/testsuite/gcc.target/i386/pie.c
new file mode 100644
index 0000000..0a9f5ee
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pie.c
@@ -0,0 +1,12 @@
+/* { dg-do compile { target pie } } */
+/* { dg-options "-O2" } */
+
+int foo (void);
+
+int
+main (void)
+{
+  return foo ();
+}
+
+/* { dg-final { scan-assembler "foo@PLT" } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index f5c6db8..549bcdf 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -475,6 +475,11 @@ proc check_profiling_available { test_what } {
 	}
     }
 
+    # Profiling don't work with -fPIE -pie.
+    if { [check_effective_target_pie] } {
+      return 0
+    }
+
     # Support for -p on solaris2 relies on mcrt1.o which comes with the
     # vendor compiler.  We cannot reliably predict the directory where the
     # vendor compiler (and thus mcrt1.o) is installed so we can't
@@ -1080,6 +1085,16 @@ proc check_effective_target_nonpic { } {
     }]
 }
 
+# Return 1 if the current multilib generatse PIE by default.
+
+proc check_effective_target_pie { } {
+    return [check_no_compiler_messages pie assembly {
+	#ifndef __PIE__
+	#error unsupported
+	#endif
+    }]
+}
+
 # Return 1 if the target does not use a status wrapper.
 
 proc check_effective_target_unwrapped { } {
-- 
1.9.3

Re: [testsuite] PATCH: Add check_effective_target_pie

[Jeff Law]

On 01/11/15 16:58, H.J. Lu wrote:
> Hi,
>
> This patch adds check_effective_target_pie to check if the current
> multilib generatse PIE by default.  I will submit other patches to use
> it.  OK for trunk?
>
> Thanks.
>
> H.J.
> ---
> 2015-01-11  H.J. Lu  <hongjiu.lu@intel.com>
>
> 	* gcc.target/i386/pie.c: New test.
>
> 	* lib/target-supports.exp (check_profiling_available): Return 0
> 	if PIE is enabled.
> 	(check_effective_target_pie): New.
> ---
>   gcc/testsuite/gcc.target/i386/pie.c   | 12 ++++++++++++
>   gcc/testsuite/lib/target-supports.exp | 15 +++++++++++++++
>   2 files changed, 27 insertions(+)
>   create mode 100644 gcc/testsuite/gcc.target/i386/pie.c
>
> diff --git a/gcc/testsuite/gcc.target/i386/pie.c b/gcc/testsuite/gcc.target/i386/pie.c
> new file mode 100644
> index 0000000..0a9f5ee
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pie.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile { target pie } } */
> +/* { dg-options "-O2" } */
> +
> +int foo (void);
> +
> +int
> +main (void)
> +{
> +  return foo ();
> +}
> +
> +/* { dg-final { scan-assembler "foo@PLT" } } */
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
> index f5c6db8..549bcdf 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -475,6 +475,11 @@ proc check_profiling_available { test_what } {
>   	}
>       }
>
> +    # Profiling don't work with -fPIE -pie.
> +    if { [check_effective_target_pie] } {
> +      return 0
> +    }
Is this an inherent restriction of -fPIE, or is it merely an 
implementation detail?  If the latter, is that implementation detail a 
target issue?  ie, could we have a target that supports profiling in 
conjunction with -fPIE?  If so, then this test seems too restrictive.

>   }
>
> +# Return 1 if the current multilib generatse PIE by default.
s/generatse/generates/

Waiting on answer to PIE vs pg question above prior to approving or 
requesting further refinement.

jeff

Re: [testsuite] PATCH: Add check_effective_target_pie

[H.J. Lu]

On Mon, Jan 12, 2015 at 10:09 AM, Jeff Law <law@redhat.com> wrote:
> On 01/11/15 16:58, H.J. Lu wrote:
>>
>> Hi,
>>
>> This patch adds check_effective_target_pie to check if the current
>> multilib generatse PIE by default.  I will submit other patches to use
>> it.  OK for trunk?
>>
>> Thanks.
>>
>> H.J.
>> ---
>> 2015-01-11  H.J. Lu  <hongjiu.lu@intel.com>
>>
>>         * gcc.target/i386/pie.c: New test.
>>
>>         * lib/target-supports.exp (check_profiling_available): Return 0
>>         if PIE is enabled.
>>         (check_effective_target_pie): New.
>> ---
>>   gcc/testsuite/gcc.target/i386/pie.c   | 12 ++++++++++++
>>   gcc/testsuite/lib/target-supports.exp | 15 +++++++++++++++
>>   2 files changed, 27 insertions(+)
>>   create mode 100644 gcc/testsuite/gcc.target/i386/pie.c
>>
>> diff --git a/gcc/testsuite/gcc.target/i386/pie.c
>> b/gcc/testsuite/gcc.target/i386/pie.c
>> new file mode 100644
>> index 0000000..0a9f5ee
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/i386/pie.c
>> @@ -0,0 +1,12 @@
>> +/* { dg-do compile { target pie } } */
>> +/* { dg-options "-O2" } */
>> +
>> +int foo (void);
>> +
>> +int
>> +main (void)
>> +{
>> +  return foo ();
>> +}
>> +
>> +/* { dg-final { scan-assembler "foo@PLT" } } */
>> diff --git a/gcc/testsuite/lib/target-supports.exp
>> b/gcc/testsuite/lib/target-supports.exp
>> index f5c6db8..549bcdf 100644
>> --- a/gcc/testsuite/lib/target-supports.exp
>> +++ b/gcc/testsuite/lib/target-supports.exp
>> @@ -475,6 +475,11 @@ proc check_profiling_available { test_what } {
>>         }
>>       }
>>
>> +    # Profiling don't work with -fPIE -pie.
>> +    if { [check_effective_target_pie] } {
>> +      return 0
>> +    }
>
> Is this an inherent restriction of -fPIE, or is it merely an implementation
> detail?  If the latter, is that implementation detail a target issue?  ie,
> could we have a target that supports profiling in conjunction with -fPIE?
> If so, then this test seems too restrictive.

[hjl@gnu-6 tmp]$ gcc -pie -fPIE -pg h.c
/usr/local/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/gcrt1.o:
relocation R_X86_64_32S against `__libc_csu_fini' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/gcrt1.o:
error adding symbols: Bad value
collect2: error: ld returned 1 exit status
[hjl@gnu-6 tmp]$

There is no crt1.o from glibc to support -pg -pie -fPIE.
I don't know if other targets support -pie -fPIE.

>>   }
>>
>> +# Return 1 if the current multilib generatse PIE by default.
>
> s/generatse/generates/

I will fix it.

> Waiting on answer to PIE vs pg question above prior to approving or
> requesting further refinement.

Sure.

-- 
H.J.

Re: [testsuite] PATCH: Add check_effective_target_pie

[Jeff Law]

On 01/12/15 12:29, H.J. Lu wrote:

>> Is this an inherent restriction of -fPIE, or is it merely an implementation
>> detail?  If the latter, is that implementation detail a target issue?  ie,
>> could we have a target that supports profiling in conjunction with -fPIE?
>> If so, then this test seems too restrictive.
>
> [hjl@gnu-6 tmp]$ gcc -pie -fPIE -pg h.c
> /usr/local/bin/ld:
> /usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/gcrt1.o:
> relocation R_X86_64_32S against `__libc_csu_fini' can not be used when
> making a shared object; recompile with -fPIC
> /usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/gcrt1.o:
> error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
> [hjl@gnu-6 tmp]$
>
> There is no crt1.o from glibc to support -pg -pie -fPIE.
> I don't know if other targets support -pie -fPIE.
Can you please investigate the questions.  Showing me the link failure 
doesn't really help much here.  It tells me there's no crt1.o, but it 
says nothing about *why*.

Is there inherently something about PIE/pg that makes them impossible to 
work together or is this an implementation detail?  If the latter, then 
is the implementation detail a target issue or not.

Jeff

Re: [testsuite] PATCH: Add check_effective_target_pie

[H.J. Lu]

On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
> On 01/12/15 12:59, H.J. Lu wrote:
>>
>> I don't know if -pg will work PIE on any targets.  For Linux/x86
>> the choices of crt1.o are
>>
>> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
>>
>> -shared, -pg and -pie are mutually exclusive. Those crt1 files are
>> only crt1 files provided by glibc.  You can't even try -pg -pie on
>> Linux without changing glibc.
>
> You're totally missing the point.  What I care about is *why*.
>
> Showing me spec file fragments is totally unhelpful.  What is the technical
> reason why pg and pie are mutually exclusive?

What kind of "technical" reason are you looking for?  glibc doesn't
provide the right crt1 file for GCC to support this combination.  You
can't define GNU_USER_TARGET_STARTFILE_SPEC to support
-pg and -pie.

If you are asking "why" glibc doesn't provide one, my guess is no
one has requested one before.

-- 
H.J.

Re: [testsuite] PATCH: Add check_effective_target_pie

[Magnus Granberg]

måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
> On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
> > On 01/12/15 12:59, H.J. Lu wrote:
> >> I don't know if -pg will work PIE on any targets.  For Linux/x86
> >> the choices of crt1.o are
> >> 
> >> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
> >> 
> >> -shared, -pg and -pie are mutually exclusive. Those crt1 files are
> >> only crt1 files provided by glibc.  You can't even try -pg -pie on
> >> Linux without changing glibc.
> > 
> > You're totally missing the point.  What I care about is *why*.
> > 
With -pg it use gcrt1.o object file and that file is not compile with -fPIC. 
When you build a shared lib on x86_64 all the objects files need to be buiit 
with -fPIC else you get a error like that one abow and it is the same problems 
when you build bin with -fPIE and linke with -pie.
Glibc do not provide one that is compile with -fPIC

> > Showing me spec file fragments is totally unhelpful.  What is the
> > technical
> > reason why pg and pie are mutually exclusive?
> 
> What kind of "technical" reason are you looking for?  glibc doesn't
> provide the right crt1 file for GCC to support this combination.  You
> can't define GNU_USER_TARGET_STARTFILE_SPEC to support
> -pg and -pie.
> 
> If you are asking "why" glibc doesn't provide one, my guess is no
> one has requested one before.

Re: [testsuite] PATCH: Add check_effective_target_pie

[Jeff Law]

On 01/12/15 14:51, Magnus Granberg wrote:
> måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
>> On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
>>> On 01/12/15 12:59, H.J. Lu wrote:
>>>> I don't know if -pg will work PIE on any targets.  For Linux/x86
>>>> the choices of crt1.o are
>>>>
>>>> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
>>>>
>>>> -shared, -pg and -pie are mutually exclusive. Those crt1 files are
>>>> only crt1 files provided by glibc.  You can't even try -pg -pie on
>>>> Linux without changing glibc.
>>>
>>> You're totally missing the point.  What I care about is *why*.
>>>
> With -pg it use gcrt1.o object file and that file is not compile with -fPIC.
> When you build a shared lib on x86_64 all the objects files need to be buiit
> with -fPIC else you get a error like that one abow and it is the same problems
> when you build bin with -fPIE and linke with -pie.
> Glibc do not provide one that is compile with -fPIC
Is there some reason why glibc could not provide gcrt1.o compiled with 
-fPIC?


Jeff

Re: [testsuite] PATCH: Add check_effective_target_pie

[H.J. Lu]

On Mon, Jan 12, 2015 at 03:04:20PM -0700, Jeff Law wrote:
> On 01/12/15 14:51, Magnus Granberg wrote:
> >måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
> >>On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
> >>>On 01/12/15 12:59, H.J. Lu wrote:
> >>>>I don't know if -pg will work PIE on any targets.  For Linux/x86
> >>>>the choices of crt1.o are
> >>>>
> >>>>%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
> >>>>
> >>>>-shared, -pg and -pie are mutually exclusive. Those crt1 files are
> >>>>only crt1 files provided by glibc.  You can't even try -pg -pie on
> >>>>Linux without changing glibc.
> >>>
> >>>You're totally missing the point.  What I care about is *why*.
> >>>
> >With -pg it use gcrt1.o object file and that file is not compile with -fPIC.
> >When you build a shared lib on x86_64 all the objects files need to be buiit
> >with -fPIC else you get a error like that one abow and it is the same problems
> >when you build bin with -fPIE and linke with -pie.
> >Glibc do not provide one that is compile with -fPIC
> Is there some reason why glibc could not provide gcrt1.o compiled with
> -fPIC?

That is a good question. We can compile gcrt1.o with -fPIC and it will
work with both -pg and -pg -pie.  I will open a glibc bug.

Here is the updated patch without the check_profiling_available change.
OK for trunk?

Thanks.

H.J.
---
Subject: [PATCH 1/5] Add check_effective_target_pie

Hi,

This patch adds check_effective_target_pie to check if the current
multilib generates PIE by default.

Thanks.

H.J.
---
2015-01-11  H.J. Lu  <hongjiu.lu@intel.com>

	* gcc.target/i386/pie.c: New test.

	* lib/target-supports.exp (check_effective_target_pie): New.
---
 gcc/testsuite/gcc.target/i386/pie.c   | 12 ++++++++++++
 gcc/testsuite/lib/target-supports.exp | 10 ++++++++++
 2 files changed, 22 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/pie.c

diff --git a/gcc/testsuite/gcc.target/i386/pie.c b/gcc/testsuite/gcc.target/i386/pie.c
new file mode 100644
index 0000000..0a9f5ee
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pie.c
@@ -0,0 +1,12 @@
+/* { dg-do compile { target pie } } */
+/* { dg-options "-O2" } */
+
+int foo (void);
+
+int
+main (void)
+{
+  return foo ();
+}
+
+/* { dg-final { scan-assembler "foo@PLT" } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index f5c6db8..0ac9646 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1080,6 +1080,16 @@ proc check_effective_target_nonpic { } {
     }]
 }
 
+# Return 1 if the current multilib generates PIE by default.
+
+proc check_effective_target_pie { } {
+    return [check_no_compiler_messages pie assembly {
+	#ifndef __PIE__
+	#error unsupported
+	#endif
+    }]
+}
+
 # Return 1 if the target does not use a status wrapper.
 
 proc check_effective_target_unwrapped { } {
-- 
1.9.3

Re: [testsuite] PATCH: Add check_effective_target_pie

[Jeff Law]

On 01/13/15 05:52, H.J. Lu wrote:
> On Mon, Jan 12, 2015 at 03:04:20PM -0700, Jeff Law wrote:
>> On 01/12/15 14:51, Magnus Granberg wrote:
>>> måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
>>>> On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
>>>>> On 01/12/15 12:59, H.J. Lu wrote:
>>>>>> I don't know if -pg will work PIE on any targets.  For Linux/x86
>>>>>> the choices of crt1.o are
>>>>>>
>>>>>> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
>>>>>>
>>>>>> -shared, -pg and -pie are mutually exclusive. Those crt1 files are
>>>>>> only crt1 files provided by glibc.  You can't even try -pg -pie on
>>>>>> Linux without changing glibc.
>>>>>
>>>>> You're totally missing the point.  What I care about is *why*.
>>>>>
>>> With -pg it use gcrt1.o object file and that file is not compile with -fPIC.
>>> When you build a shared lib on x86_64 all the objects files need to be buiit
>>> with -fPIC else you get a error like that one abow and it is the same problems
>>> when you build bin with -fPIE and linke with -pie.
>>> Glibc do not provide one that is compile with -fPIC
>> Is there some reason why glibc could not provide gcrt1.o compiled with
>> -fPIC?
>
> That is a good question. We can compile gcrt1.o with -fPIC and it will
> work with both -pg and -pg -pie.  I will open a glibc bug.
Thanks for getting the bug opened, there's a reasonable chance that 
we'll have the gcrt1.o we want in the not too distant future.


>
> Here is the updated patch without the check_profiling_available change.
> OK for trunk?
>
> Thanks.
>
> H.J.
> ---
> Subject: [PATCH 1/5] Add check_effective_target_pie
>
> Hi,
>
> This patch adds check_effective_target_pie to check if the current
> multilib generates PIE by default.
>
> Thanks.
>
> H.J.
> ---
> 2015-01-11  H.J. Lu  <hongjiu.lu@intel.com>
>
> 	* gcc.target/i386/pie.c: New test.
>
> 	* lib/target-supports.exp (check_effective_target_pie): New.
OK.
Jeff

Re: [testsuite] PATCH: Add check_effective_target_pie

[Rainer Orth]

Jeff Law <law@redhat.com> writes:

>> Subject: [PATCH 1/5] Add check_effective_target_pie
>>
>> Hi,
>>
>> This patch adds check_effective_target_pie to check if the current
>> multilib generates PIE by default.
>>
>> Thanks.
>>
>> H.J.
>> ---
>> 2015-01-11  H.J. Lu  <hongjiu.lu@intel.com>
>>
>> 	* gcc.target/i386/pie.c: New test.
>>
>> 	* lib/target-supports.exp (check_effective_target_pie): New.
> OK.

The new proc is bogus, unfortunately: there's already an existing
check_effective_target_pie that checks if a target can support PIE.  The
new one just overrides the previous one.  On targets supporting PIE
(like Darwin), but not defaulting to it, the PIE tests suddenly turn out
UNSUPPORTED.

You should rename the new one to
e.g. check_effective_target_pie_default, update the single user, and
document it in sourcebuild.texi.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [testsuite] PATCH: Add check_effective_target_pie

[H.J. Lu]

On Tue, Feb 10, 2015 at 3:11 PM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> Jeff Law <law@redhat.com> writes:
>
>>> Subject: [PATCH 1/5] Add check_effective_target_pie
>>>
>>> Hi,
>>>
>>> This patch adds check_effective_target_pie to check if the current
>>> multilib generates PIE by default.
>>>
>>> Thanks.
>>>
>>> H.J.
>>> ---
>>> 2015-01-11  H.J. Lu  <hongjiu.lu@intel.com>
>>>
>>>      * gcc.target/i386/pie.c: New test.
>>>
>>>      * lib/target-supports.exp (check_effective_target_pie): New.
>> OK.
>
> The new proc is bogus, unfortunately: there's already an existing
> check_effective_target_pie that checks if a target can support PIE.  The
> new one just overrides the previous one.  On targets supporting PIE
> (like Darwin), but not defaulting to it, the PIE tests suddenly turn out
> UNSUPPORTED.
>
> You should rename the new one to
> e.g. check_effective_target_pie_default, update the single user, and
> document it in sourcebuild.texi.

I checked in this as an obvious fix.

Thanks.


-- 
H.J.
---
Index: ChangeLog
===================================================================
--- ChangeLog (revision 220617)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2015-02-11  H.J. Lu  <hongjiu.lu@intel.com>
+
+ * doc/sourcebuild.texi (pie_enabled): Document.
+
 2015-02-11  Martin Liska  <mliska@suse.cz>

  PR ipa/64813
Index: testsuite/lib/target-supports.exp
===================================================================
--- testsuite/lib/target-supports.exp (revision 220617)
+++ testsuite/lib/target-supports.exp (working copy)
@@ -1100,8 +1100,8 @@

 # Return 1 if the current multilib generates PIE by default.

-proc check_effective_target_pie { } {
-    return [check_no_compiler_messages pie assembly {
+proc check_effective_target_pie_enabled { } {
+    return [check_no_compiler_messages pie_enabled assembly {
  #ifndef __PIE__
  #error unsupported
  #endif
Index: testsuite/gcc.dg/tree-ssa/ssa-store-ccp-3.c
===================================================================
--- testsuite/gcc.dg/tree-ssa/ssa-store-ccp-3.c (revision 220617)
+++ testsuite/gcc.dg/tree-ssa/ssa-store-ccp-3.c (working copy)
@@ -13,6 +13,6 @@

 /* There should be no reference for nonpic targets to
    conststaticvariable as we should have inlined the 0. */
-/* { dg-final { scan-tree-dump-times "conststaticvariable" 0
"optimized" { target { pie || nonpic } } } } */
-/* { dg-final { scan-tree-dump-times "conststaticvariable" 1
"optimized" { target { { ! pie } && { ! nonpic } } } } } */
+/* { dg-final { scan-tree-dump-times "conststaticvariable" 0
"optimized" { target { pie_enabled || nonpic } } } } */
+/* { dg-final { scan-tree-dump-times "conststaticvariable" 1
"optimized" { target { { ! pie_enabled } && { ! nonpic } } } } } */
 /* { dg-final { cleanup-tree-dump "optimized" } } */
Index: testsuite/ChangeLog
===================================================================
--- testsuite/ChangeLog (revision 220617)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2015-02-11  H.J. Lu  <hongjiu.lu@intel.com>
+
+ * lib/target-supports.exp (check_effective_target_pie): Renamed
+ to ...
+ (check_effective_target_pie_enabled): This.
+ * gcc.dg/tree-ssa/ssa-store-ccp-3.c: Replace pie with pie_enabled.
+ * gcc.target/i386/pie.c: Likewise.
+
 2015-02-11  Andrew Pinski  <apinski@cavium.com>

  PR target/64893
Index: testsuite/gcc.target/i386/pie.c
===================================================================
--- testsuite/gcc.target/i386/pie.c (revision 220617)
+++ testsuite/gcc.target/i386/pie.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target pie } } */
+/* { dg-do compile { target pie_enabled } } */
 /* { dg-options "-O2" } */

 int foo (void);
Index: doc/sourcebuild.texi
===================================================================
--- doc/sourcebuild.texi (revision 220617)
+++ doc/sourcebuild.texi (working copy)
@@ -1884,6 +1884,9 @@
 @item nonpic
 Target does not generate PIC by default.

+@item pie_enabled
+Target generates PIE by default.
+
 @item pcc_bitfield_type_matters
 Target defines @code{PCC_BITFIELD_TYPE_MATTERS}.

Re: [testsuite] PATCH: Add check_effective_target_pie

[Rainer Orth]

"H.J. Lu" <hjl.tools@gmail.com> writes:

>> The new proc is bogus, unfortunately: there's already an existing
>> check_effective_target_pie that checks if a target can support PIE.  The
>> new one just overrides the previous one.  On targets supporting PIE
>> (like Darwin), but not defaulting to it, the PIE tests suddenly turn out
>> UNSUPPORTED.
>>
>> You should rename the new one to
>> e.g. check_effective_target_pie_default, update the single user, and
>> document it in sourcebuild.texi.
>
> I checked in this as an obvious fix.

I think pie_enabled is not a very descriptive name:

Index: doc/sourcebuild.texi
===================================================================
--- doc/sourcebuild.texi (revision 220617)
+++ doc/sourcebuild.texi (working copy)
@@ -1884,6 +1884,9 @@
 @item nonpic
 Target does not generate PIC by default.

+@item pie_enabled
+Target generates PIE by default.
+
 @item pcc_bitfield_type_matters
 Target defines @code{PCC_BITFIELD_TYPE_MATTERS}.

With -fpie, PIE is also enabled, just not the default without any
options.  Please either go with the pie_default I sugested or wait for
others to weigh in before rushing in another `obvious' fix.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [testsuite] PATCH: Add check_effective_target_pie

[H.J. Lu]

On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>>> The new proc is bogus, unfortunately: there's already an existing
>>> check_effective_target_pie that checks if a target can support PIE.  The
>>> new one just overrides the previous one.  On targets supporting PIE
>>> (like Darwin), but not defaulting to it, the PIE tests suddenly turn out
>>> UNSUPPORTED.
>>>
>>> You should rename the new one to
>>> e.g. check_effective_target_pie_default, update the single user, and
>>> document it in sourcebuild.texi.
>>
>> I checked in this as an obvious fix.
>
> I think pie_enabled is not a very descriptive name:
>
> Index: doc/sourcebuild.texi
> ===================================================================
> --- doc/sourcebuild.texi (revision 220617)
> +++ doc/sourcebuild.texi (working copy)
> @@ -1884,6 +1884,9 @@
>  @item nonpic
>  Target does not generate PIC by default.
>
> +@item pie_enabled
> +Target generates PIE by default.
> +
>  @item pcc_bitfield_type_matters
>  Target defines @code{PCC_BITFIELD_TYPE_MATTERS}.
>
> With -fpie, PIE is also enabled, just not the default without any

I was testing

# make RUNTESTFLAGS="--target_board='unix{-m32\ -fpie,-fpie}'

I don't consider PIE is default.  It is just enabled.

> options.  Please either go with the pie_default I sugested or wait for
> others to weigh in before rushing in another `obvious' fix.
>



-- 
H.J.

Re: [testsuite] PATCH: Add check_effective_target_pie

[Rainer Orth]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
> <ro@cebitec.uni-bielefeld.de> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>>> The new proc is bogus, unfortunately: there's already an existing
>>>> check_effective_target_pie that checks if a target can support PIE.  The
>>>> new one just overrides the previous one.  On targets supporting PIE
>>>> (like Darwin), but not defaulting to it, the PIE tests suddenly turn out
>>>> UNSUPPORTED.
>>>>
>>>> You should rename the new one to
>>>> e.g. check_effective_target_pie_default, update the single user, and
>>>> document it in sourcebuild.texi.
>>>
>>> I checked in this as an obvious fix.
>>
>> I think pie_enabled is not a very descriptive name:
>>
>> Index: doc/sourcebuild.texi
>> ===================================================================
>> --- doc/sourcebuild.texi (revision 220617)
>> +++ doc/sourcebuild.texi (working copy)
>> @@ -1884,6 +1884,9 @@
>>  @item nonpic
>>  Target does not generate PIC by default.
>>
>> +@item pie_enabled
>> +Target generates PIE by default.
>> +
>>  @item pcc_bitfield_type_matters
>>  Target defines @code{PCC_BITFIELD_TYPE_MATTERS}.
>>
>> With -fpie, PIE is also enabled, just not the default without any
>
> I was testing
>
> # make RUNTESTFLAGS="--target_board='unix{-m32\ -fpie,-fpie}'
>
> I don't consider PIE is default.  It is just enabled.
>
>> options.  Please either go with the pie_default I sugested or wait for
>> others to weigh in before rushing in another `obvious' fix.

Then the description (both sourcebuild.texi and target-supports.texi) is
confusing.

What are you trying to achieve here, actually?  Even on Solaris 11/x86
(which doesn't support PIE), -fpie lets the
check_effective_target_pie_enabled (or whatever it's called) proc pass.
Shouldn't it also check if the target can support PIE at all?

Please clarify your goals before going forward with this.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [testsuite] PATCH: Add check_effective_target_pie

[H.J. Lu]

On Wed, Feb 11, 2015 at 7:19 AM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
>> <ro@cebitec.uni-bielefeld.de> wrote:
>>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>
>>>>> The new proc is bogus, unfortunately: there's already an existing
>>>>> check_effective_target_pie that checks if a target can support PIE.  The
>>>>> new one just overrides the previous one.  On targets supporting PIE
>>>>> (like Darwin), but not defaulting to it, the PIE tests suddenly turn out
>>>>> UNSUPPORTED.
>>>>>
>>>>> You should rename the new one to
>>>>> e.g. check_effective_target_pie_default, update the single user, and
>>>>> document it in sourcebuild.texi.
>>>>
>>>> I checked in this as an obvious fix.
>>>
>>> I think pie_enabled is not a very descriptive name:
>>>
>>> Index: doc/sourcebuild.texi
>>> ===================================================================
>>> --- doc/sourcebuild.texi (revision 220617)
>>> +++ doc/sourcebuild.texi (working copy)
>>> @@ -1884,6 +1884,9 @@
>>>  @item nonpic
>>>  Target does not generate PIC by default.
>>>
>>> +@item pie_enabled
>>> +Target generates PIE by default.
>>> +
>>>  @item pcc_bitfield_type_matters
>>>  Target defines @code{PCC_BITFIELD_TYPE_MATTERS}.
>>>
>>> With -fpie, PIE is also enabled, just not the default without any
>>
>> I was testing
>>
>> # make RUNTESTFLAGS="--target_board='unix{-m32\ -fpie,-fpie}'
>>
>> I don't consider PIE is default.  It is just enabled.
>>
>>> options.  Please either go with the pie_default I sugested or wait for
>>> others to weigh in before rushing in another `obvious' fix.
>
> Then the description (both sourcebuild.texi and target-supports.texi) is
> confusing.

That is how other options are described.

> What are you trying to achieve here, actually?  Even on Solaris 11/x86
> (which doesn't support PIE), -fpie lets the
> check_effective_target_pie_enabled (or whatever it's called) proc pass.
> Shouldn't it also check if the target can support PIE at all?
>

Assembly outputs may be different, depending on if PIE is
enabled nor not. When we scan assembly outputs for test
results, we have different expected results when PIE is enabled.
That is how pie_enabled is used so far.

-- 
H.J.

Re: [testsuite] PATCH: Add check_effective_target_pie

[Rainer Orth]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Wed, Feb 11, 2015 at 7:19 AM, Rainer Orth
> <ro@cebitec.uni-bielefeld.de> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
>>> <ro@cebitec.uni-bielefeld.de> wrote:
>>>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>>
>>>>>> The new proc is bogus, unfortunately: there's already an existing
>>>>>> check_effective_target_pie that checks if a target can support PIE.  The
>>>>>> new one just overrides the previous one.  On targets supporting PIE
>>>>>> (like Darwin), but not defaulting to it, the PIE tests suddenly turn out
>>>>>> UNSUPPORTED.
>>>>>>
>>>>>> You should rename the new one to
>>>>>> e.g. check_effective_target_pie_default, update the single user, and
>>>>>> document it in sourcebuild.texi.
>>>>>
>>>>> I checked in this as an obvious fix.
>>>>
>>>> I think pie_enabled is not a very descriptive name:
>>>>
>>>> Index: doc/sourcebuild.texi
>>>> ===================================================================
>>>> --- doc/sourcebuild.texi (revision 220617)
>>>> +++ doc/sourcebuild.texi (working copy)
>>>> @@ -1884,6 +1884,9 @@
>>>>  @item nonpic
>>>>  Target does not generate PIC by default.
>>>>
>>>> +@item pie_enabled
>>>> +Target generates PIE by default.
>>>> +
>>>>  @item pcc_bitfield_type_matters
>>>>  Target defines @code{PCC_BITFIELD_TYPE_MATTERS}.
>>>>
>>>> With -fpie, PIE is also enabled, just not the default without any
>>>
>>> I was testing
>>>
>>> # make RUNTESTFLAGS="--target_board='unix{-m32\ -fpie,-fpie}'
>>>
>>> I don't consider PIE is default.  It is just enabled.
>>>
>>>> options.  Please either go with the pie_default I sugested or wait for
>>>> others to weigh in before rushing in another `obvious' fix.
>>
>> Then the description (both sourcebuild.texi and target-supports.texi) is
>> confusing.
>
> That is how other options are described.

You're not getting my point:

* target-supports.exp now has

# Return 1 if the current multilib generates PIE by default.

* sourcebuild.texi states

Target generates PIE by default.

Which one is it?

>> What are you trying to achieve here, actually?  Even on Solaris 11/x86
>> (which doesn't support PIE), -fpie lets the
>> check_effective_target_pie_enabled (or whatever it's called) proc pass.
>> Shouldn't it also check if the target can support PIE at all?
>
> Assembly outputs may be different, depending on if PIE is
> enabled nor not. When we scan assembly outputs for test
> results, we have different expected results when PIE is enabled.
> That is how pie_enabled is used so far.

But why would you need a new effective-target keyword for that?  Simply
test the existing { target pie }, add -fpie and scan the assembler
output.  Why would you need pie_enabled or whatever at all?  Again: what
are you trying to achieve that cannot be done with the current keyword?

Right now, in gcc.target/i386/pie.c, you're only testing the PIE case
when PIE has been enabled by some means external to testsuite.  The test
always comes out UNSUPPORTED if not, so it isn't even exercised in a
regular bootstrap (except on Darwin which defaults to PIE, I believe).

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [testsuite] PATCH: Add check_effective_target_pie

[H.J. Lu]

On Wed, Feb 11, 2015 at 8:15 AM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Wed, Feb 11, 2015 at 7:19 AM, Rainer Orth
>> <ro@cebitec.uni-bielefeld.de> wrote:
>>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>
>>>> On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
>>>> <ro@cebitec.uni-bielefeld.de> wrote:
>>>>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>>>
>>>>>>> The new proc is bogus, unfortunately: there's already an existing
>>>>>>> check_effective_target_pie that checks if a target can support PIE.  The
>>>>>>> new one just overrides the previous one.  On targets supporting PIE
>>>>>>> (like Darwin), but not defaulting to it, the PIE tests suddenly turn out
>>>>>>> UNSUPPORTED.
>>>>>>>
>>>>>>> You should rename the new one to
>>>>>>> e.g. check_effective_target_pie_default, update the single user, and
>>>>>>> document it in sourcebuild.texi.
>>>>>>
>>>>>> I checked in this as an obvious fix.
>>>>>
>>>>> I think pie_enabled is not a very descriptive name:
>>>>>
>>>>> Index: doc/sourcebuild.texi
>>>>> ===================================================================
>>>>> --- doc/sourcebuild.texi (revision 220617)
>>>>> +++ doc/sourcebuild.texi (working copy)
>>>>> @@ -1884,6 +1884,9 @@
>>>>>  @item nonpic
>>>>>  Target does not generate PIC by default.
>>>>>
>>>>> +@item pie_enabled
>>>>> +Target generates PIE by default.
>>>>> +
>>>>>  @item pcc_bitfield_type_matters
>>>>>  Target defines @code{PCC_BITFIELD_TYPE_MATTERS}.
>>>>>
>>>>> With -fpie, PIE is also enabled, just not the default without any
>>>>
>>>> I was testing
>>>>
>>>> # make RUNTESTFLAGS="--target_board='unix{-m32\ -fpie,-fpie}'
>>>>
>>>> I don't consider PIE is default.  It is just enabled.
>>>>
>>>>> options.  Please either go with the pie_default I sugested or wait for
>>>>> others to weigh in before rushing in another `obvious' fix.
>>>
>>> Then the description (both sourcebuild.texi and target-supports.texi) is
>>> confusing.
>>
>> That is how other options are described.
>
> You're not getting my point:
>
> * target-supports.exp now has
>
> # Return 1 if the current multilib generates PIE by default.
>
> * sourcebuild.texi states
>
> Target generates PIE by default.
>
> Which one is it?

I copied them from nonpic

# Return 1 if the current multilib does not generate PIC by default.

@item nonpic
Target does not generate PIC by default.

>>> What are you trying to achieve here, actually?  Even on Solaris 11/x86
>>> (which doesn't support PIE), -fpie lets the
>>> check_effective_target_pie_enabled (or whatever it's called) proc pass.
>>> Shouldn't it also check if the target can support PIE at all?
>>
>> Assembly outputs may be different, depending on if PIE is
>> enabled nor not. When we scan assembly outputs for test
>> results, we have different expected results when PIE is enabled.
>> That is how pie_enabled is used so far.
>
> But why would you need a new effective-target keyword for that?  Simply
> test the existing { target pie }, add -fpie and scan the assembler
> output.  Why would you need pie_enabled or whatever at all?  Again: what
> are you trying to achieve that cannot be done with the current keyword?
>
> Right now, in gcc.target/i386/pie.c, you're only testing the PIE case
> when PIE has been enabled by some means external to testsuite.  The test
> always comes out UNSUPPORTED if not, so it isn't even exercised in a
> regular bootstrap (except on Darwin which defaults to PIE, I believe).

That is intentional.  gcc.target/i386/pie.c will be test by

1. RUNTESTFLAGS="--target_board='unix{-m32\ -fpie,-fpie}'" .  Or
2. PIE is enabled by default:

https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00956.html


-- 
H.J.

[testsuite] PATCH: Check if -pg available

[H.J. Lu]

On Mon, Jan 12, 2015 at 03:04:20PM -0700, Jeff Law wrote:
> On 01/12/15 14:51, Magnus Granberg wrote:
> >måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
> >>On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
> >>>On 01/12/15 12:59, H.J. Lu wrote:
> >>>>I don't know if -pg will work PIE on any targets.  For Linux/x86
> >>>>the choices of crt1.o are
> >>>>
> >>>>%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
> >>>>
> >>>>-shared, -pg and -pie are mutually exclusive. Those crt1 files are
> >>>>only crt1 files provided by glibc.  You can't even try -pg -pie on
> >>>>Linux without changing glibc.
> >>>
> >>>You're totally missing the point.  What I care about is *why*.
> >>>
> >With -pg it use gcrt1.o object file and that file is not compile with -fPIC.
> >When you build a shared lib on x86_64 all the objects files need to be buiit
> >with -fPIC else you get a error like that one abow and it is the same problems
> >when you build bin with -fPIE and linke with -pie.
> >Glibc do not provide one that is compile with -fPIC
> Is there some reason why glibc could not provide gcrt1.o compiled with
> -fPIC?
> 
> 

Here is a patch to check if -pg is available.  If -pg doesn't link,
profiling isn't available.  OK for trunk?

Thanks.


H.J.
---
 gcc/testsuite/lib/target-supports.exp | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 0ac9646..7c09399 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -546,6 +546,12 @@ proc check_profiling_available { test_what } {
 	    set profiling_available_saved 0
 	} else {
 	    set profiling_available_saved 1
+	    if { [check_no_compiler_messages_nocache profiling executable {
+		  int main() { return 0; } } "-pg"] } {
+		set profiling_available_saved 1
+	     } else {
+		set profiling_available_saved 0
+	    }
 	}
     }
 
-- 
1.9.3

Re: [testsuite] PATCH: Check if -pg available

[H.J. Lu]

On Tue, Jan 13, 2015 at 04:54:32AM -0800, H.J. Lu wrote:
> On Mon, Jan 12, 2015 at 03:04:20PM -0700, Jeff Law wrote:
> > On 01/12/15 14:51, Magnus Granberg wrote:
> > >måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
> > >>On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
> > >>>On 01/12/15 12:59, H.J. Lu wrote:
> > >>>>I don't know if -pg will work PIE on any targets.  For Linux/x86
> > >>>>the choices of crt1.o are
> > >>>>
> > >>>>%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
> > >>>>
> > >>>>-shared, -pg and -pie are mutually exclusive. Those crt1 files are
> > >>>>only crt1 files provided by glibc.  You can't even try -pg -pie on
> > >>>>Linux without changing glibc.
> > >>>
> > >>>You're totally missing the point.  What I care about is *why*.
> > >>>
> > >With -pg it use gcrt1.o object file and that file is not compile with -fPIC.
> > >When you build a shared lib on x86_64 all the objects files need to be buiit
> > >with -fPIC else you get a error like that one abow and it is the same problems
> > >when you build bin with -fPIE and linke with -pie.
> > >Glibc do not provide one that is compile with -fPIC
> > Is there some reason why glibc could not provide gcrt1.o compiled with
> > -fPIC?
> > 
> > 
> 
> Here is a patch to check if -pg is available.  If -pg doesn't link,
> profiling isn't available.  OK for trunk?
> 
> Thanks.
> 
> 
> H.J.
> ---
>  gcc/testsuite/lib/target-supports.exp | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
> index 0ac9646..7c09399 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -546,6 +546,12 @@ proc check_profiling_available { test_what } {
>  	    set profiling_available_saved 0
>  	} else {
>  	    set profiling_available_saved 1
> +	    if { [check_no_compiler_messages_nocache profiling executable {
> +		  int main() { return 0; } } "-pg"] } {
> +		set profiling_available_saved 1
> +	     } else {
> +		set profiling_available_saved 0
> +	    }
>  	}
>      }
>  

Here is the ChangeLog entry.

2015-01-13  H.J. Lu  <hongjiu.lu@intel.com>

	* lib/target-supports.exp (check_profiling_available): Check if
	-pg links.

H.J.

Re: [testsuite] PATCH: Check if -pg available

[Jeff Law]

On 01/13/15 05:54, H.J. Lu wrote:
> On Mon, Jan 12, 2015 at 03:04:20PM -0700, Jeff Law wrote:
>> On 01/12/15 14:51, Magnus Granberg wrote:
>>> måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
>>>> On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
>>>>> On 01/12/15 12:59, H.J. Lu wrote:
>>>>>> I don't know if -pg will work PIE on any targets.  For Linux/x86
>>>>>> the choices of crt1.o are
>>>>>>
>>>>>> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
>>>>>>
>>>>>> -shared, -pg and -pie are mutually exclusive. Those crt1 files are
>>>>>> only crt1 files provided by glibc.  You can't even try -pg -pie on
>>>>>> Linux without changing glibc.
>>>>>
>>>>> You're totally missing the point.  What I care about is *why*.
>>>>>
>>> With -pg it use gcrt1.o object file and that file is not compile with -fPIC.
>>> When you build a shared lib on x86_64 all the objects files need to be buiit
>>> with -fPIC else you get a error like that one abow and it is the same problems
>>> when you build bin with -fPIE and linke with -pie.
>>> Glibc do not provide one that is compile with -fPIC
>> Is there some reason why glibc could not provide gcrt1.o compiled with
>> -fPIC?
>>
>>
>
> Here is a patch to check if -pg is available.  If -pg doesn't link,
> profiling isn't available.  OK for trunk?
OK with a suitable ChangeLog entry.

jeff

Re: [testsuite] PATCH: Check if -pg available

[H.J. Lu]

On Tue, Jan 13, 2015 at 11:27 AM, Jeff Law <law@redhat.com> wrote:
> On 01/13/15 05:54, H.J. Lu wrote:
>>
>> On Mon, Jan 12, 2015 at 03:04:20PM -0700, Jeff Law wrote:
>>>
>>> On 01/12/15 14:51, Magnus Granberg wrote:
>>>>
>>>> måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
>>>>>
>>>>> On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
>>>>>>
>>>>>> On 01/12/15 12:59, H.J. Lu wrote:
>>>>>>>
>>>>>>> I don't know if -pg will work PIE on any targets.  For Linux/x86
>>>>>>> the choices of crt1.o are
>>>>>>>
>>>>>>> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
>>>>>>>
>>>>>>> -shared, -pg and -pie are mutually exclusive. Those crt1 files are
>>>>>>> only crt1 files provided by glibc.  You can't even try -pg -pie on
>>>>>>> Linux without changing glibc.
>>>>>>
>>>>>>
>>>>>> You're totally missing the point.  What I care about is *why*.
>>>>>>
>>>> With -pg it use gcrt1.o object file and that file is not compile with
>>>> -fPIC.
>>>> When you build a shared lib on x86_64 all the objects files need to be
>>>> buiit
>>>> with -fPIC else you get a error like that one abow and it is the same
>>>> problems
>>>> when you build bin with -fPIE and linke with -pie.
>>>> Glibc do not provide one that is compile with -fPIC
>>>
>>> Is there some reason why glibc could not provide gcrt1.o compiled with
>>> -fPIC?
>>>
>>>
>>
>> Here is a patch to check if -pg is available.  If -pg doesn't link,
>> profiling isn't available.  OK for trunk?
>
> OK with a suitable ChangeLog entry.
>

Unfortunately it doesn't work with

make check-gcc RUNTESTFLAGS="--target_board='unix{-m32,-m64}'

since check_profiling_available result is cached.  It is wrong to use the
cached result from -m32 for -m64.  Here is the updated patch.  Tested
with RUNTESTFLAGS="--target_board='unix{-m32,-m64}'.  OK for
trunk?

Thanks.


-- 
H.J.
----
* lib/target-supports.exp (check_profiling_available): Check if
-pg links.
---
 gcc/testsuite/lib/target-supports.exp | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 0ac9646..61bff53 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -549,7 +549,16 @@ proc check_profiling_available { test_what } {
  }
     }

-    return $profiling_available_saved
+    # -pg link test result can't be cached since it may change between
+    # runs.
+    set profiling_working $profiling_available_saved
+    if { $profiling_available_saved == 1
+         && ![check_no_compiler_messages_nocache profiling executable {
+      int main() { return 0; } } "-pg"] } {
+ set profiling_working 0
+    }
+
+    return $profiling_working
 }

 # Check to see if a target is "freestanding". This is as per the definition
-- 
1.9.3

Re: [testsuite] PATCH: Check if -pg available

[Jeff Law]

On 01/13/15 13:42, H.J. Lu wrote:

>
> since check_profiling_available result is cached.  It is wrong to use the
> cached result from -m32 for -m64.  Here is the updated patch.  Tested
> with RUNTESTFLAGS="--target_board='unix{-m32,-m64}'.  OK for
> trunk?
Yes, the updated patch is OK.
jeff

Re: [testsuite] PATCH: Add check_effective_target_pie

[H.J. Lu]

On Mon, Jan 12, 2015 at 03:04:20PM -0700, Jeff Law wrote:
> On 01/12/15 14:51, Magnus Granberg wrote:
> >måndag 12 januari 2015 12.11.17 skrev  H.J. Lu:
> >>On Mon, Jan 12, 2015 at 12:03 PM, Jeff Law <law@redhat.com> wrote:
> >>>On 01/12/15 12:59, H.J. Lu wrote:
> >>>>I don't know if -pg will work PIE on any targets.  For Linux/x86
> >>>>the choices of crt1.o are
> >>>>
> >>>>%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
> >>>>
> >>>>-shared, -pg and -pie are mutually exclusive. Those crt1 files are
> >>>>only crt1 files provided by glibc.  You can't even try -pg -pie on
> >>>>Linux without changing glibc.
> >>>
> >>>You're totally missing the point.  What I care about is *why*.
> >>>
> >With -pg it use gcrt1.o object file and that file is not compile with -fPIC.
> >When you build a shared lib on x86_64 all the objects files need to be buiit
> >with -fPIC else you get a error like that one abow and it is the same problems
> >when you build bin with -fPIE and linke with -pie.
> >Glibc do not provide one that is compile with -fPIC
> Is there some reason why glibc could not provide gcrt1.o compiled with
> -fPIC?
> 

I opened a glibc bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=17836

and submitted a patch:

https://sourceware.org/ml/libc-alpha/2015-01/msg00284.html

H.J.