Re: Backported r185234 from trunk (r194264 from google/gcc-4_7). (issue 6904043)

2012-12-06 Thread shenhan 

On 2012/12/07 00:29:39, asharif wrote:

On 2012/12/06 22:02:16, Diego Novillo wrote:
> On Thu, Dec 6, 2012 at 4:51 PM,  

wrote:

>
> > I don't think the rule is to *only* update ChangeLog.google*. The

rule

> > is to update ChangeLog, but also update ChangeLog.google*.
>
> Just ChangeLog.google*, actually.  When cherry picking revisions

from

> other branches, it's better not to update ChangeLog.  It's not

really

> necessary and it will actually cause merge conflicts later.  I'll
> clarify the developer notes.
>
>
> Thanks.  Diego.



Done.



I have removed the ChangeLog chunk. PTAL.


LGTM

https://codereview.appspot.com/6904043/

[PATCH] Add a new option "-fstack-protector-strong" (issue 6303078)

2012-06-14 Thread shenhan 

Reviewers: ,

Message:
Hi, this is to port the patch from google/main to trunk, which provides
a new stack protection option - "fstack-protector-strong".

Previous review for google trunk is here -
http://codereview.appspot.com/5461043

Status - it has been used in google/main for 2 quarters, building the
whole chromiumos with no securiy degradation.

Benefit - gain big performance while sacrificing little security (for
scenarios using -fstack-protector-all)

Background - some times stack-protector is too-simple while
stack-protector-all over-kills, for example, to build one of our core
systems, we forcibly add "-fstack-protector-all" to all compile
commands, which brings big performance penalty (due to extra stack
guard/check insns on function prologue and epilogue) on both atom and
arm. To use "-fstack-protector" is just regarded as not secure enough
(only "protects" <2% functions) by the system secure team. So I'd like
to add the option "-fstack-protector-strong", that hits the balance
between "-fstack-protector" and "-fstack-protector-all".

Detail -
https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU/edit?hl=en_US

Tested - dejagnu, building chromiumos from scratch.

Ok for trunk?

Thank,
-Han


Description:
This is to port the patch from google/main to trunk, which provides a
new stack protection option - "fstack-protector-strong".

Previous review for google trunk is here -
http://codereview.appspot.com/5461043

Status - it has been used in google/main for 2 quarters, building the
whole chromiumos with no securiy degradation.

Benefit - gain big performance while sacrificing little security (for
scenarios using -fstack-protector-all)

Background - some times stack-protector is too-simple while
stack-protector-all over-kills, for example, to build one of our core
systems, we forcibly add "-fstack-protector-all" to all compile
commands, which brings big performance penalty (due to extra stack
guard/check insns on function prologue and epilogue) on both atom and
arm. To use "-fstack-protector" is just regarded as not secure enough
(only "protects" <2% functions) by the system secure team. So I'd like
to add the option "-fstack-protector-strong", that hits the balance
between "-fstack-protector" and "-fstack-protector-all".

Detail -
https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU/edit?hl=en_US

Tested - building chromiumos from scratch.



Please review this at http://codereview.appspot.com/6303078/

Affected files:
  M gcc/cfgexpand.c
  M gcc/common.opt
  gcc/doc/invoke.texi
  A gcc/testsuite/g++.dg/fstack-protector-strong.C
  A gcc/testsuite/gcc.dg/fstack-protector-strong.c

Re: [google]Backport to enable stack protector for Android targets (issue 6220051)

2012-05-18 Thread shenhan 

On 2012/05/18 18:35:32, jingyu wrote:

Backport from trunk r187586
http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00583.html



Enable -fstack-protector support for Android targets.



The patch only affects targets where __BIONIC__ is defined.
Built Android arm toolchain.



Would like to commit the patch to google/gcc-4_6 and
google/gcc-4_6_2-mobile.



OK?



2012-05-18   Jing Yu  



Backport from trunk r187586:
2012-05-16  Igor Zamyatin  
* configure.ac: Stack protector enabling for Android targets.
* configure: Regenerate.



Index: gcc/configure
===
--- gcc/configure   (revision 187663)
+++ gcc/configure   (working copy)
@@ -25862,6 +25862,11 @@
 $target_header_dir/bits/uClibc_config.h > /dev/null; then
  gcc_cv_libc_provides_ssp=yes
fi
+  # all versions of Bionic support stack protector
+  elif test -f $target_header_dir/sys/cdefs.h \
+&& $EGREP '^[  ]*#[]*define[   ]+__BIONIC__[   ]+1' \
+   $target_header_dir/sys/cdefs.h > /dev/null; then
+ gcc_cv_libc_provides_ssp=yes
fi
;;
 *-*-gnu*)
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 187663)
+++ gcc/configure.ac(working copy)
@@ -4414,6 +4414,11 @@
 $target_header_dir/bits/uClibc_config.h > /dev/null; then
  gcc_cv_libc_provides_ssp=yes
fi
+  # all versions of Bionic support stack protector
+  elif test -f $target_header_dir/sys/cdefs.h \
+&& $EGREP '^[  ]*#[]*define[   ]+__BIONIC__[   ]+1' \
+   $target_header_dir/sys/cdefs.h > /dev/null; then
+ gcc_cv_libc_provides_ssp=yes
fi]
;;
 *-*-gnu*)
Index: gcc/ChangeLog.google-4_6
===
--- gcc/ChangeLog.google-4_6(revision 187663)
+++ gcc/ChangeLog.google-4_6(working copy)
@@ -1,3 +1,11 @@
+2012-05-18   Jing Yu  
+
+   Backport from trunk r187586:
+   2012-05-16  Igor Zamyatin  
+
+   * configure.ac: Stack protector enabling for Android targets.
+   * configure: Regenerate.
+
  2012-05-18   Teresa Johnson  



Backport from google/main r187660:



--
This patch is available for review at

http://codereview.appspot.com/6220051

LGTM

http://codereview.appspot.com/6220051/

Re: [google/gcc-4_6_3-mobile] Port r187569 from google/gcc-4_6 branch (issue 6210060)

2012-05-16 Thread shenhan 

On 2012/05/16 23:30:28, Diego Novillo wrote:

On 12-05-16 19:22 , mailto:jin...@google.com wrote:
> In my opinion, gcc/ChangeLog is for upstream commits only.
> It is fine that you want to port upstream gcc/ChangeLog as well.

Just

> remove your identities
> +2012-05-11 Han Shen 
> +
> + Backported r187569 from branches/google/gcc-4_6.



The convention for branches is that all the commits to them should get



ChangeLog entries in the file ChangeLog.



where  is generally the basename of the branch URL, though



it is sometimes changed slightly.  In the google branches we use the
convention 'google-' for all the branches under google/*




Diego.


Thanks, Jing and Diego.

Reverted gcc/ChangeLog.

Regards,
-Han

http://codereview.appspot.com/6210060/

Re: [google/gcc-4_6_3-mobile] Port r187569 from google/gcc-4_6 branch (issue 6210060)

2012-05-16 Thread shenhan 

On 2012/05/16 17:27:59, asharif1 wrote:

On 2012/05/16 01:02:26, shenhan wrote:
> Hi Amhad and Jing, could you take a look at this CL at
> http://codereview.appspot.com/6210060/
>
> Thanks,
> -Han



Shouldn't this have a corresponding ChangeLog entry and a
ChangeLog.google-gcc-4_6 entry?


Hi Ahmad, thanks!

Done recreating the patch from "svn merge -c".

Regards,
-Han

http://codereview.appspot.com/6210060/

[google/gcc-4_6_3-mobile] Port r187569 from google/gcc-4_6 branch (issue 6210060)

2012-05-15 Thread shenhan 

Reviewers: asharif1, jingyu,

Message:
Hi Amhad and Jing, could you take a look at this CL at
http://codereview.appspot.com/6210060/

Thanks,
-Han

Description:
Ported r187569 from google/gcc-4_6 branch.

2012-05-11  Han Shen  

Backport from mainline.
2012-05-01  Richard Earnshaw  

* arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_DEFAULT): Avoid ifdef
comparing enumeration values.  Update comments.

2012-04-26  Michael Hope  
Richard Earnshaw  

* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_SOFT_FLOAT):
Define.
(GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER_DEFAULT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.

Please review this at http://codereview.appspot.com/6210060/

Affected files:
  M gcc/config/arm/linux-eabi.h


Index: gcc/config/arm/linux-eabi.h
===
--- gcc/config/arm/linux-eabi.h (revision 187569)
+++ gcc/config/arm/linux-eabi.h (working copy)
@@ -32,7 +32,8 @@
   while (false)

 /* We default to a soft-float ABI so that binaries can run on all
-   target hardware.  */
+   target hardware.  If you override this to use the hard-float ABI then
+   change the setting of GLIBC_DYNAMIC_LINKER_DEFAULT as well.  */
 #undef  TARGET_DEFAULT_FLOAT_ABI
 #define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT

@@ -59,11 +60,26 @@
 #undef  SUBTARGET_EXTRA_LINK_SPEC
 #define SUBTARGET_EXTRA_LINK_SPEC " -m " TARGET_LINKER_EMULATION

-/* Use ld-linux.so.3 so that it will be possible to run "classic"
-   GNU/Linux binaries on an EABI system.  */
+/* GNU/Linux on ARM currently supports three dynamic linkers:
+   - ld-linux.so.2 - for the legacy ABI
+   - ld-linux.so.3 - for the EABI-derived soft-float ABI
+   - ld-linux-armhf.so.3 - for the EABI-derived hard-float ABI.
+   All the dynamic linkers live in /lib.
+   We default to soft-float, but this can be overridden by changing both
+   GLIBC_DYNAMIC_LINKER_DEFAULT and TARGET_DEFAULT_FLOAT_ABI.  */
+
 #undef  GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT \
+  RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT \
+  RUNTIME_ROOT_PREFIX "/lib/ld-linux-armhf.so.3"
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT

+#define GLIBC_DYNAMIC_LINKER \
+   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+%{mfloat-abi=soft*:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "} \
+%{!mfloat-abi=*:" GLIBC_DYNAMIC_LINKER_DEFAULT "}"
+
 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
use the GNU/Linux version, not the generic BPABI version.  */
 #undef  LINK_SPEC

Re: [google/google-main] Fix regression - SUBTARGET_EXTRA_SPECS overridden by LINUX_GRTE_EXTRA_SPECS (issue 6016047)

2012-05-14 Thread shenhan 

On 2012/04/12 21:14:29, shenhan wrote:

Hi, the newest chrome gcc (from google-main) fails to linking

anything, by

looking into specs file, it seems that 'link_emulation' section is

missing in

specs.



The problem I found is that SUBTARGET_EXTRA_SPECS, which is not empty

for

chromeos, is overridden by "LINUX_GRTE_EXTRA_SPECS".



Please review the proposed a patch. (Tested by buildit bootstrap).



-Han


Hi Jing and Rong, could you take a look at this?

Thanks,
-Han

http://codereview.appspot.com/6016047/

Re: [google/gcc-4_6] Backport arm hardfp patch from trunk (issue 6206055)

2012-05-14 Thread shenhan 

On 2012/05/11 22:15:37, carrot wrote:

http://codereview.appspot.com/6206055/diff/4001/gcc/ChangeLog
File gcc/ChangeLog (right):



http://codereview.appspot.com/6206055/diff/4001/gcc/ChangeLog#newcode11

gcc/ChangeLog:11:
It seems you also merged in another patch r187012, please mention it.



http://codereview.appspot.com/6206055/diff/4001/gcc/config/arm/linux-eabi.h

File gcc/config/arm/linux-eabi.h (right):



http://codereview.appspot.com/6206055/diff/4001/gcc/config/arm/linux-eabi.h#newcode77

gcc/config/arm/linux-eabi.h:77: RUNTIME_ROOT_PREFIX
GLIBC_DYNAMIC_LINKER_SOFT_FLOAT



Here the RUNTIME_ROOT_PREFIX may be redundant.


Hi Carrot, thanks!

Modified per your comments.

= Patch start

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 2f85855..afe7769 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,19 @@
+2012-05-11  Han Shen  
+
+   Backport from mainline.
+   2012-05-01  Richard Earnshaw  
+
+   * arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_DEFAULT): Avoid ifdef
+   comparing enumeration values.  Update comments.
+
+   2012-04-26  Michael Hope  
+   Richard Earnshaw  
+
+   * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.
+   (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
+   (GLIBC_DYNAMIC_LINKER_DEFAULT): Define.
+   (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
+
 2012-04-30  Uros Bizjak  

Backport from mainline
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 3a32188..e1d3415 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -32,7 +32,8 @@
   while (false)

 /* We default to a soft-float ABI so that binaries can run on all
-   target hardware.  */
+   target hardware.  If you override this to use the hard-float ABI
then
+   change the setting of GLIBC_DYNAMIC_LINKER_DEFAULT as well.  */
 #undef  TARGET_DEFAULT_FLOAT_ABI
 #define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT

@@ -59,10 +60,25 @@
 #undef  SUBTARGET_EXTRA_LINK_SPEC
 #define SUBTARGET_EXTRA_LINK_SPEC " -m " TARGET_LINKER_EMULATION

-/* Use ld-linux.so.3 so that it will be possible to run "classic"
-   GNU/Linux binaries on an EABI system.  */
+/* GNU/Linux on ARM currently supports three dynamic linkers:
+   - ld-linux.so.2 - for the legacy ABI
+   - ld-linux.so.3 - for the EABI-derived soft-float ABI
+   - ld-linux-armhf.so.3 - for the EABI-derived hard-float ABI.
+   All the dynamic linkers live in /lib.
+   We default to soft-float, but this can be overridden by changing
both
+   GLIBC_DYNAMIC_LINKER_DEFAULT and TARGET_DEFAULT_FLOAT_ABI.  */
+
 #undef  GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT \
+  RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT \
+  RUNTIME_ROOT_PREFIX "/lib/ld-linux-armhf.so.3"
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+
+#define GLIBC_DYNAMIC_LINKER \
+   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+%{mfloat-abi=soft*:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "} \
+%{!mfloat-abi=*:" GLIBC_DYNAMIC_LINKER_DEFAULT "}"

 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
use the GNU/Linux version, not the generic BPABI version.  */
=

http://codereview.appspot.com/6206055/

Re: [google/gcc-4_6] Backport arm hardfp patch from trunk (issue 6206055)

2012-05-11 Thread shenhan 

On 2012/05/11 18:48:40, carrot wrote:

Please add ChangeLog and the trunk patch revision.


Thanks.

Trunk patch revision is 186859.

ChangeLog entry added.

 Patch started.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 2f85855..588fa04 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2012-05-11  Han Shen  
+
+   Backport from mainline.
+   2012-04-26  Michael Hope  
+   Richard Earnshaw  
+
+   * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_SOFT_FLOAT): Define.
+   (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
+   (GLIBC_DYNAMIC_LINKER_DEFAULT): Define.
+   (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
+
 2012-04-30  Uros Bizjak  

Backport from mainline
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 3a32188..58d06c2 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -32,7 +32,8 @@
   while (false)

 /* We default to a soft-float ABI so that binaries can run on all
-   target hardware.  */
+   target hardware.  If you override this to use the hard-float ABI
then
+   change the setting of GLIBC_DYNAMIC_LINKER_DEFAULT as well.  */
 #undef  TARGET_DEFAULT_FLOAT_ABI
 #define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT

@@ -59,10 +60,26 @@
 #undef  SUBTARGET_EXTRA_LINK_SPEC
 #define SUBTARGET_EXTRA_LINK_SPEC " -m " TARGET_LINKER_EMULATION

-/* Use ld-linux.so.3 so that it will be possible to run "classic"
-   GNU/Linux binaries on an EABI system.  */
+/* GNU/Linux on ARM currently supports three dynamic linkers:
+   - ld-linux.so.2 - for the legacy ABI
+   - ld-linux.so.3 - for the EABI-derived soft-float ABI
+   - ld-linux-armhf.so.3 - for the EABI-derived hard-float ABI.
+   All the dynamic linkers live in /lib.
+   We default to soft-float, but this can be overridden by changing
both
+   GLIBC_DYNAMIC_LINKER_DEFAULT and TARGET_DEFAULT_FLOAT_ABI.  */
+
 #undef  GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT \
+  RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT \
+  RUNTIME_ROOT_PREFIX "/lib/ld-linux-armhf.so.3"
+#define GLIBC_DYNAMIC_LINKER_DEFAULT \
+  RUNTIME_ROOT_PREFIX GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+
+#define GLIBC_DYNAMIC_LINKER \
+   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+%{mfloat-abi=soft*:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "} \
+%{!mfloat-abi=*:" GLIBC_DYNAMIC_LINKER_DEFAULT "}"

 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
use the GNU/Linux version, not the generic BPABI version.  */


http://codereview.appspot.com/6206055/

[google/gcc-4_6] Port arm hardfp patch from Linaro (issue 6206055)

2012-05-11 Thread shenhan 

Reviewers: carrot, xur,

Message:
Hi Rong and Carrot, could you take a look at this patch, thanks!

The modification is in upstream (with a minor modification).

Background -

There is the need to agree on the runtime linker path for the various
ARM
hard-float ports that distros are working on right now. Without doing
this,
we'll break binary compatibility between the distros.

The conclusion was made. And here is the detailed information -
https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012

= Patch starts
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 3a32188..58d06c2 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -32,7 +32,8 @@
   while (false)

 /* We default to a soft-float ABI so that binaries can run on all
-   target hardware.  */
+   target hardware.  If you override this to use the hard-float ABI
then
+   change the setting of GLIBC_DYNAMIC_LINKER_DEFAULT as well.  */
 #undef  TARGET_DEFAULT_FLOAT_ABI
 #define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT

@@ -59,10 +60,26 @@
 #undef  SUBTARGET_EXTRA_LINK_SPEC
 #define SUBTARGET_EXTRA_LINK_SPEC " -m " TARGET_LINKER_EMULATION

-/* Use ld-linux.so.3 so that it will be possible to run "classic"
-   GNU/Linux binaries on an EABI system.  */
+/* GNU/Linux on ARM currently supports three dynamic linkers:
+   - ld-linux.so.2 - for the legacy ABI
+   - ld-linux.so.3 - for the EABI-derived soft-float ABI
+   - ld-linux-armhf.so.3 - for the EABI-derived hard-float ABI.
+   All the dynamic linkers live in /lib.
+   We default to soft-float, but this can be overridden by changing
both
+   GLIBC_DYNAMIC_LINKER_DEFAULT and TARGET_DEFAULT_FLOAT_ABI.  */
+
 #undef  GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT \
+  RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT \
+  RUNTIME_ROOT_PREFIX "/lib/ld-linux-armhf.so.3"
+#define GLIBC_DYNAMIC_LINKER_DEFAULT \
+  RUNTIME_ROOT_PREFIX GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+
+#define GLIBC_DYNAMIC_LINKER \
+   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+%{mfloat-abi=soft*:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "} \
+%{!mfloat-abi=*:" GLIBC_DYNAMIC_LINKER_DEFAULT "}"

 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
use the GNU/Linux version, not the generic BPABI version.  */


Description:
Hi Rong and Carrot, could you take a look at this patch, thanks!

The modification is in upstream (with a minor modification).

Background -

There is the need to agree on the runtime linker path for the various
ARM hard-float ports that distros are working on right now. Without
doing this, we'll break binary compatibility between the distros.

The conclusion was made. And here is the detailed information -
https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012

= Patch starts
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 3a32188..58d06c2 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -32,7 +32,8 @@
   while (false)

 /* We default to a soft-float ABI so that binaries can run on all
-   target hardware.  */
+   target hardware.  If you override this to use the hard-float ABI
then
+   change the setting of GLIBC_DYNAMIC_LINKER_DEFAULT as well.  */
 #undef  TARGET_DEFAULT_FLOAT_ABI
 #define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT

@@ -59,10 +60,26 @@
 #undef  SUBTARGET_EXTRA_LINK_SPEC
 #define SUBTARGET_EXTRA_LINK_SPEC " -m " TARGET_LINKER_EMULATION

-/* Use ld-linux.so.3 so that it will be possible to run "classic"
-   GNU/Linux binaries on an EABI system.  */
+/* GNU/Linux on ARM currently supports three dynamic linkers:
+   - ld-linux.so.2 - for the legacy ABI
+   - ld-linux.so.3 - for the EABI-derived soft-float ABI
+   - ld-linux-armhf.so.3 - for the EABI-derived hard-float ABI.
+   All the dynamic linkers live in /lib.
+   We default to soft-float, but this can be overridden by changing
both
+   GLIBC_DYNAMIC_LINKER_DEFAULT and TARGET_DEFAULT_FLOAT_ABI.  */
+
 #undef  GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT \
+  RUNTIME_ROOT_PREFIX "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT \
+  RUNTIME_ROOT_PREFIX "/lib/ld-linux-armhf.so.3"
+#define GLIBC_DYNAMIC_LINKER_DEFAULT \
+  RUNTIME_ROOT_PREFIX GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+
+#define GLIBC_DYNAMIC_LINKER \
+   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+%{mfloat-abi=soft*:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "} \
+%{!mfloat-abi=*:" GLIBC_DYNAMIC_LINKER_DEFAULT "}"

 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
use the GNU/Linux version, not the generic BPABI version.  */





Please review this at http://codereview.appspot.com/6206055/

Affected files:
  M gcc/config/arm/linux-eabi.h


Index: gcc/config/arm/linux-ea

[google/google-main] Fix regression - SUBTARGET_EXTRA_SPECS overridden by LINUX_GRTE_EXTRA_SPECS (issue 6016047)

2012-04-12 Thread shenhan 

Reviewers: asharif1, jingyu, Diego Novillo,

Message:
Hi, the newest chrome gcc (from google-main) fails to linking anything,
by looking into specs file, it seems that 'link_emulation' section is
missing in specs.

The problem I found is that SUBTARGET_EXTRA_SPECS, which is not empty
for chromeos, is overridden by "LINUX_GRTE_EXTRA_SPECS".

Please review the proposed a patch. (Tested by buildit bootstrap).

-Han



Description:
In linux.h, macro SUBTARGET_EXTRA_SPECS is overridden by
"LINUX_GRTE_EXTRA_SPECS", so the origin content of SUBTARGET_EXTRA_SPECS
never gets written into gcc spec, which causes linking failure for
chrome gcc.


Please review this at http://codereview.appspot.com/6016047/

Affected files:
  M gcc/config/i386/i386.h
  M gcc/config/i386/linux.h


Index: gcc/config/i386/i386.h
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 7721c46..29fdd0b 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -621,8 +621,9 @@ enum target_cpu_default
 #endif

 #define EXTRA_SPECS\
-  { "cc1_cpu",  CC1_CPU_SPEC },  \
-  SUBTARGET_EXTRA_SPECS
+  { "cc1_cpu",  CC1_CPU_SPEC },  \
+LINUX_GRTE_EXTRA_SPECS \
+SUBTARGET_EXTRA_SPECS
 

 /* Set the value of FLT_EVAL_METHOD in float.h.  When using only the
Index: gcc/config/i386/linux.h
diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
index ade524c..383dedf 100644
--- a/gcc/config/i386/linux.h
+++ b/gcc/config/i386/linux.h
@@ -30,7 +30,3 @@ along with GCC; see the file COPYING3.  If not see
 #ifndef LINUX_GRTE_EXTRA_SPECS
 #define LINUX_GRTE_EXTRA_SPECS
 #endif
-
-#undef  SUBTARGET_EXTRA_SPECS
-#define SUBTARGET_EXTRA_SPECS \
-  LINUX_GRTE_EXTRA_SPECS

[google/gcc-4_6] Added dejagnu base line for x86_64-cros-linux-gnu. (issue 5990044)

2012-04-05 Thread shenhan 

Reviewers: asharif1, jingyu,

Message:
Hi Jing and Ahmad,

This adds a new test base line for x86_64-cros-linux-gnu. Please take a
look.

Thanks,
Han

Description:
The new test base line for x86_64-cros-linux-gnu.

Please review this at http://codereview.appspot.com/5990044/

Affected files:
  A contrib/testsuite-management/x86_64-cros-linux-gnu.xfail


Index: contrib/testsuite-management/x86_64-cros-linux-gnu.xfail
diff --git a/contrib/testsuite-management/x86_64-cros-linux-gnu.xfail  
b/contrib/testsuite-management/x86_64-cros-linux-gnu.xfail

new file mode 100644
index 000..e9d8c0c
--- /dev/null
+++ b/contrib/testsuite-management/x86_64-cros-linux-gnu.xfail
@@ -0,0 +1,19 @@
+XPASS: g++.dg/uninit-pred-3_b.C (test for excess errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O0  (internal compiler  
error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -Os  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer   
(internal compiler error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 -flto  (internal  
compiler error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 -flto  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g  (internal compiler  
error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O1  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2  (internal compiler  
error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -Os  (internal compiler  
error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O0  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 -flto  
-flto-partition=none  (internal compiler error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer   
(test for excess errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 -flto  
-flto-partition=none  (test for excess errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O1  (internal compiler  
error)
+FAIL: gcc.dg/tree-prof/ic-misattribution-1.c compilation,  -fprofile-use  
-D_PROFILE_USE
+UNRESOLVED: gcc.dg/tree-prof/ic-misattribution-1.c execution, 
-fprofile-use -D_PROFILE_USE

Re: [trunk] RFS: translate built-in include paths for sysroot (issue 5394041)

2011-12-05 Thread shenhan 

Ping?

http://codereview.appspot.com/5394041/

Re: [trunk] RFS: translate built-in include paths for sysroot (issue 5394041)

2011-11-28 Thread shenhan 

Hi, Joseph, get a chance to take a look? Thanks!
-Han

On 2011/11/19 00:10:20, shenhan wrote:

Hi, Joseph, thanks!



ChangeLog entries added to the issue description.



ChangeLog
 * Makefile.in (GPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT): add a macro
 definition to compile command.
 * cppdefault.c (GPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT): replace

hard

 coded "add_sysroot" field with the control macro.
 * configure.ac (gcc_gxx_include_dir_add_sysroot): add a flag
 variable to control whether sysroot should be prepended to gxx
 include dir.
 * configure : Regenerate.



Yeah, I should include the URL for the previous discussion in the

mail. (I

previously put it in the issue description together with the

rationale.)


This is a follow up for issue - http://codereview.appspot.com/4641076.
The rationale for this patch is also copied here:
==



The setup:



Configuring a toolchain targeting x86-64 GNU Linux (Ubuntu Lucid), as

a

cross-compiler.  Using a sysroot to provide the Lucid

headers+libraries,

with the sysroot path being within the GCC install tree.  Want to use

the

Lucid system libstdc++ and headers, which means that I'm not
building/installing libstdc++-v3.



So, configuring with:
   --with-sysroot="$SYSROOT"
   --disable-libstdc++-v3 \
   --with-gxx-include-dir="$SYSROOT/usr/include/c++/4.4" \
(among other options).



Hoping to support two usage models with this configuration, w.r.t. use

of

the sysroot:



(1) somebody installs the sysroot in the normal location relative to

the

GCC install, and relocates the whole bundle (sysroot+GCC).  This works
great AFAICT, GCC finds its includes (including the C++ includes)

thanks

to the add_standard_paths iprefix handling.



(2) somebody installs the sysroot in a non-standard location, and uses
--sysroot to try to access it.  This works fine for the C headers, but
doesn't work.



For the C headers, add_standard_paths prepends the sysroot location to
the /usr/include path (since that's what's specified in cppdefault.c

for

that path).  It doesn't do the same for the C++ include path, though
(again, as specified in cppdefault.c).



add_standard_paths doesn't attempt to relocate built-in include paths

that

start with the compiled-in sysroot location (e.g., the g++ include

dir, in

this case).  This isn't surprising really: normally you either prepend

the

sysroot location or you don't (as specified by cppdefault.c); none of

the

built-in paths normally *start* with the sysroot location and need to

be

relocated.  However, in this odd-ball case of trying to use the C++

headers

from the sysroot, one of the paths *does* need to be relocated in this

way.

=




Chris(cgd@) provided a patch for the issue, but there was a different

opinion,

my patch here is just coded as suggested.



Tested before/after on a x86_64-unknown-linux-gnu system, with
--enable-languages=all,

RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}'.

No changes in test results.



-Han




On Fri, Nov 18, 2011 at 8:54 AM, Joseph S. Myers

wrote:


> On Tue, 15 Nov 2011, Han Shen wrote:
>
> > 2011-11-15   Han Shen  <mailto:shen...@google.com>
> >
> >   * gcc/Makefile.in:
> >   * gcc/configure:
> >   * gcc/cppdefault.c:
>
> You need to include the full ChangeLog entries with your patch.

Note that

> paths in ChangeLogs are relative to the directory with the

ChangeLog, so

> no gcc/ in this case.
>
> Please also include the full rationale with your patch *and URLs for

the

> previous discussion* (from June, it seems) so that reviewers don't

need to

> track that down themselves.
>
> > diff --git a/gcc/configure b/gcc/configure
> > index 99334ce..364d8c2 100755
> > --- a/gcc/configure
> > +++ b/gcc/configure
>
> It's not possible to review this patch as is because you've only

included

> the changes to the generated file configure, not to its source file
> configure.ac.  Please make sure that your resubmission includes all

the

> source file changes.  (There is no need to include the changes to

the

> generated file configure at all in the submission; the ChangeLog

entry can

> just mention it as "* configure: Regenerate.".)
>
> --
> Joseph S. Myers
> mailto:jos...@codesourcery.com
>





--





http://codereview.appspot.com/5394041/

Re: [trunk] RFS: translate built-in include paths for sysroot (issue 5394041)

2011-11-15 Thread shenhan 

On 2011/11/16 00:47:10, shenhan wrote:

2011-11-15   Han Shen  <mailto:shen...@google.com>



* gcc/Makefile.in:
* gcc/configure:
* gcc/cppdefault.c:



diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index ae4f4da..0a05783 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -615,6 +615,7 @@ gcc_tooldir = @gcc_tooldir@
  build_tooldir = $(exec_prefix)/$(target_noncanonical)
  # Directory in which the compiler finds target-independent g++

includes.

  gcc_gxx_include_dir = @gcc_gxx_include_dir@
+gcc_gxx_include_dir_add_sysroot = @gcc_gxx_include_dir_add_sysroot@
  # Directory to search for site-specific includes.
  local_includedir = $(local_prefix)/include
  includedir = $(prefix)/include
@@ -3979,6 +3980,7 @@ PREPROCESSOR_DEFINES = \
-DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
-DFIXED_INCLUDE_DIR=\"$(libsubdir)/include-fixed\" \
-DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \
+

-DGPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT=$(gcc_gxx_include_dir_add_sysroot) \


-DGPLUSPLUS_TOOL_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/$(target_noncanonical)\"
\

-DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/backward\" \

-DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \
diff --git a/gcc/configure b/gcc/configure
index 99334ce..364d8c2 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -638,6 +638,7 @@ host_xm_include_list
  host_xm_file_list
  host_exeext
  gcc_gxx_include_dir
+gcc_gxx_include_dir_add_sysroot
  gcc_config_arguments
  float_h_file
  extra_programs
@@ -3291,12 +3292,20 @@ gcc_gxx_include_dir=
  # Specify the g++ header file directory



  # Check whether --with-gxx-include-dir was given.
+gcc_gxx_include_dir_add_sysroot=0
  if test "${with_gxx_include_dir+set}" = set; then :
withval=$with_gxx_include_dir; case "${withval}" in
  yes)  as_fn_error "bad value ${withval} given for g++ include

directory"

"$LINENO" 5 ;;
  no)   ;;
  *)gcc_gxx_include_dir=$with_gxx_include_dir ;;
  esac
+  if test "${with_sysroot+set}" = set; then :
+gcc_gxx_without_sysroot=`expr "${gcc_gxx_include_dir}" :
"${with_sysroot}"'\(.*\)'`
+if test "${gcc_gxx_without_sysroot}"; then :
+  gcc_gxx_include_dir="${gcc_gxx_without_sysroot}"
+  gcc_gxx_include_dir_add_sysroot=1
+fi
+  fi
  fi




diff --git a/gcc/cppdefault.c b/gcc/cppdefault.c
index 099899a..e8341d5 100644
--- a/gcc/cppdefault.c
+++ b/gcc/cppdefault.c
@@ -44,15 +44,15 @@ const struct default_include

cpp_include_defaults[]

  = {
  #ifdef GPLUSPLUS_INCLUDE_DIR
  /* Pick up GNU C++ generic include files.  */
-{ GPLUSPLUS_INCLUDE_DIR, "G++", 1, 1, 0, 0 },
+{ GPLUSPLUS_INCLUDE_DIR, "G++", 1, 1,

GPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT, 0

},
  #endif
  #ifdef GPLUSPLUS_TOOL_INCLUDE_DIR
  /* Pick up GNU C++ target-dependent include files.  */
-{ GPLUSPLUS_TOOL_INCLUDE_DIR, "G++", 1, 1, 0, 1 },
+{ GPLUSPLUS_TOOL_INCLUDE_DIR, "G++", 1, 1,
GPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT, 1 },
  #endif
  #ifdef GPLUSPLUS_BACKWARD_INCLUDE_DIR
  /* Pick up GNU C++ backward and deprecated include files.  */
-{ GPLUSPLUS_BACKWARD_INCLUDE_DIR, "G++", 1, 1, 0, 0 },
+{ GPLUSPLUS_BACKWARD_INCLUDE_DIR, "G++", 1, 1,
GPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT, 0 },
  #endif
  #ifdef GCC_INCLUDE_DIR
  /* This is the dir for gcc's private headers.  */



--
This patch is available for review at

http://codereview.appspot.com/5394041

Hi, this is a follow up for issue
"http://codereview.appspot.com/4641076";.

The issue description from that issue is copied below:

=
The setup:

Configuring a toolchain targeting x86-64 GNU Linux (Ubuntu Lucid), as a
cross-compiler.  Using a sysroot to provide the Lucid headers+libraries,
with the sysroot path being within the GCC install tree.  Want to use
the
Lucid system libstdc++ and headers, which means that I'm not
building/installing libstdc++-v3.

So, configuring with:
  --with-sysroot="$SYSROOT"
  --disable-libstdc++-v3 \
  --with-gxx-include-dir="$SYSROOT/usr/include/c++/4.4" \
(among other options).

Hoping to support two usage models with this configuration, w.r.t. use
of
the sysroot:

(1) somebody installs the sysroot in the normal location relative to the
GCC install, and relocates the whole bundle (sysroot+GCC).  This works
great AFAICT, GCC finds its includes (including the C++ includes) thanks
to the add_standard_paths iprefix handling.

(2) somebody installs the sysroot in a non-standard location, and uses
--sysroot to try to access it.  This works fine for the C headers, but
doesn't work.

For the C headers, add_standard_paths prepends the sysroot location to
the /usr/include path (since that's what's specified in cppdefault.c for
that path).  It doesn't do t