Re: [patch] Shorten Windows path
Hi,
On 04/01/2014 05:17 AM, Joey Ye wrote:
diff --git a/libcpp/files.c b/libcpp/files.c
index 7e88778..ad68682 100644
--- a/libcpp/files.c
+++ b/libcpp/files.c
@@ -387,8 +387,14 @@ find_file_in_dir (cpp_reader *pfile, _cpp_file *file,
bool *invalid_pch)
char *copy;
void **pp;
- /* We try to canonicalize system headers. */
- if (CPP_OPTION (pfile, canonical_system_headers) file-dir-sysp)
+ /* We try to canonicalize system headers. For DOS based file
+ * system, we always try to shorten non-system headers, as DOS
+ * has a tighter constraint on max path length. */
+ if (CPP_OPTION (pfile, canonical_system_headers) file-dir-sysp
+#ifdef HAVE_DOS_BASED_FILE_SYSTEM
+ || !file-dir-sysp
+#endif
+ )
{
char * canonical_path = maybe_shorter_path (path);
Recently I have been working with a Windows GCC user that is running into the
minuscule Windows path limits discussed here. I backported this patch to see
if it helped their case, but it didn't.
The problem we ran into is that 'lrealpath' is used in 'maybe_shorter_path' to
compute the canonical file path that has the relative portions removed. On
Windows the implementation uses 'GetFullPathName'. Unfortunately,
'GetFullPathName' suffers from the same MAX_PATH limit thus the
canonicalization fails (and from what I can tell the relative path that is
passed to 'GetFullPathName' is below the limit, but the joining of the current
working directory with the relative path name passed is not).
Did y'all run into anything like this? Were other options to produce a
canonical path name discussed? Nothing obvious jumped out at me. Despite the
limits, using 'GetFullPathName' seems like the natural way to handle it because
it knows about all the various Windows file system quirks.
--
Meador Inge
CodeSourcery / Mentor Embedded
Re: [PATCH] Don't issue array bound warnings on zero-length arrays
On 09/02/2013 04:27 AM, Richard Biener wrote:
On Fri, Aug 30, 2013 at 5:13 PM, Meador Inge mead...@codesourcery.com wrote:
Hi All,
This patch fixes a minor issue that can occur when issuing array bounds
warnings. In GNU C mode we allow empty lists and their upper bound is
initialized to -1. This confuses the array bound analysis in VRP and
in some cases we end up issuing false positives. This patch fixes
the issue by bailing out when a zero-length array is encountered.
OK for trunk?
gcc/
2013-08-30 Meador Inge mead...@codesourcery.com
* tree-vrp.c (check_array_ref): Bail out no emtpy arrays.
gcc/testsuite/
2013-08-30 Meador Inge mead...@codesourcery.com
* gcc.dg/Warray-bounds-11.c: New testcase.
Index: gcc/testsuite/gcc.dg/Warray-bounds-11.c
===
--- gcc/testsuite/gcc.dg/Warray-bounds-11.c (revision 0)
+++ gcc/testsuite/gcc.dg/Warray-bounds-11.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -Warray-bounds -std=gnu99 } */
+/* Test zero-length arrays for GNU C. */
+
+unsigned int a[] = { };
+unsigned int size_a;
+
+int test(void)
+{
+ /* This should not warn. */
+ return size_a ? a[0] : 0;
+}
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 202088)
+++ gcc/tree-vrp.c (working copy)
@@ -6137,9 +6137,10 @@ check_array_ref (location_t location, tr
low_sub = up_sub = TREE_OPERAND (ref, 1);
up_bound = array_ref_up_bound (ref);
- /* Can not check flexible arrays. */
+ /* Can not check flexible arrays or zero-length arrays. */
if (!up_bound
- || TREE_CODE (up_bound) != INTEGER_CST)
+ || TREE_CODE (up_bound) != INTEGER_CST
+ || tree_int_cst_equal (up_bound, integer_minus_one_node))
That doesn't look correct - what if the lower bound is -10? That can
easily happen
for Ada, so please revert the patch.
OK.
And I fail to see why the testcase should
not warn. Clearly you have a definition of a here and it doesn't have
an element
so the access is out of bounds.
Not always, 'size_a' can be zero and the warning is worded such that the out of
bounds access always happens. In fact, changing the code to 'size_a = 0' still
issues a warning.
--
Meador Inge
CodeSourcery / Mentor Embedded
Re: [PATCH] Don't issue array bound warnings on zero-length arrays
On 09/03/2013 10:45 AM, Jakub Jelinek wrote: On Tue, Sep 03, 2013 at 10:40:16AM -0500, Meador Inge wrote: And I fail to see why the testcase should not warn. Clearly you have a definition of a here and it doesn't have an element so the access is out of bounds. Not always, 'size_a' can be zero and the warning is worded such that the out of bounds access always happens. In fact, changing the code to 'size_a = 0' still issues a warning. How would that be different if you had that invalid access in a function and never called the function, or called it only if (0) or similar? We don't do reachability analysis, if any code we warn about can be reachable from main, and still warn about invalid code, this is invalid code, so it is IMHO just fine to warn about it. True. Perhaps I am getting too caught up in the wording. I thought we typically use may for warnings that aren't definitive, but in this case we use is (instead of something like may be): warning: array subscript is above array bounds [-Warray-bounds] -- Meador Inge CodeSourcery / Mentor Embedded
[PATCH] Don't issue array bound warnings on zero-length arrays
Hi All,
This patch fixes a minor issue that can occur when issuing array bounds
warnings. In GNU C mode we allow empty lists and their upper bound is
initialized to -1. This confuses the array bound analysis in VRP and
in some cases we end up issuing false positives. This patch fixes
the issue by bailing out when a zero-length array is encountered.
OK for trunk?
gcc/
2013-08-30 Meador Inge mead...@codesourcery.com
* tree-vrp.c (check_array_ref): Bail out no emtpy arrays.
gcc/testsuite/
2013-08-30 Meador Inge mead...@codesourcery.com
* gcc.dg/Warray-bounds-11.c: New testcase.
Index: gcc/testsuite/gcc.dg/Warray-bounds-11.c
===
--- gcc/testsuite/gcc.dg/Warray-bounds-11.c (revision 0)
+++ gcc/testsuite/gcc.dg/Warray-bounds-11.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options -O2 -Warray-bounds -std=gnu99 } */
+/* Test zero-length arrays for GNU C. */
+
+unsigned int a[] = { };
+unsigned int size_a;
+
+int test(void)
+{
+ /* This should not warn. */
+ return size_a ? a[0] : 0;
+}
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 202088)
+++ gcc/tree-vrp.c (working copy)
@@ -6137,9 +6137,10 @@ check_array_ref (location_t location, tr
low_sub = up_sub = TREE_OPERAND (ref, 1);
up_bound = array_ref_up_bound (ref);
- /* Can not check flexible arrays. */
+ /* Can not check flexible arrays or zero-length arrays. */
if (!up_bound
- || TREE_CODE (up_bound) != INTEGER_CST)
+ || TREE_CODE (up_bound) != INTEGER_CST
+ || tree_int_cst_equal (up_bound, integer_minus_one_node))
return;
/* Accesses to trailing arrays via pointers may access storage
Re: [PATCH][ARM][testsuite] Add 'dg-require-effective-target sync_*' to some atomic tests
Ping. On 06/12/2013 11:46 AM, Meador Inge wrote: Hi All, This patch adds the needed 'dg-require-effective-target sync_*' lines to some of the atomic tests so that they will not be run if the appropriate atomic support is not available. OK for trunk? 2013-06-12 Meador Inge mead...@codesourcery.com * gcc.dg/atomic-flag.c: Add dg-require-effective-target sync_*. * g++.dg/simulate-thread/atomics-2.C: Likewise. * g++.dg/simulate-thread/atomics-1.C: Likewise. -- Meador Inge CodeSourcery / Mentor Embedded
Re: [PATCH] ARM: Don't clobber CC reg when it is live after the peephole window
Ping. On 06/06/2013 01:23 PM, Meador Inge wrote: On 06/06/2013 08:11 AM, Richard Earnshaw wrote: I understand (and agree with) this bit... +(define_peephole2 + [(set (reg:CC CC_REGNUM) +(compare:CC (match_operand:SI 0 register_operand ) +(match_operand:SI 1 arm_rhs_operand ))) + (cond_exec (ne (reg:CC CC_REGNUM) (const_int 0)) + (set (match_operand:SI 2 register_operand ) (const_int 0))) + (cond_exec (eq (reg:CC CC_REGNUM) (const_int 0)) + (set (match_dup 2) (const_int 1))) + (match_scratch:SI 3 r)] + TARGET_32BIT !peep2_reg_dead_p (3, operands[0]) + [(set (match_dup 3) (minus:SI (match_dup 0) (match_dup 1))) + (parallel +[(set (reg:CC CC_REGNUM) + (compare:CC (const_int 0) (match_dup 3))) + (set (match_dup 2) (minus:SI (const_int 0) (match_dup 3)))]) + (set (match_dup 2) +(plus:SI (plus:SI (match_dup 2) (match_dup 3)) + (geu:SI (reg:CC CC_REGNUM) (const_int 0]) + ... but what's this bit about? The original intent was to revert back to the original peephole pattern (pre-PR 46975) when the CC reg is still live, but that doesn't properly maintain the CC state either (it just happened to pass in the test case I was looking at because I only cared about the Z flag, which is maintained the same). OK with the above bit left out? -- Meador Inge CodeSourcery / Mentor Embedded
[PATCH][ARM][testsuite] Add 'dg-require-effective-target sync_*' to some atomic tests
Hi All,
This patch adds the needed 'dg-require-effective-target sync_*' lines to some
of the atomic tests so that they will not be run if the appropriate atomic
support is not available.
OK for trunk?
2013-06-12 Meador Inge mead...@codesourcery.com
* gcc.dg/atomic-flag.c: Add dg-require-effective-target sync_*.
* g++.dg/simulate-thread/atomics-2.C: Likewise.
* g++.dg/simulate-thread/atomics-1.C: Likewise.
Index: gcc/testsuite/gcc.dg/atomic-flag.c
===
--- gcc/testsuite/gcc.dg/atomic-flag.c (revision 199961)
+++ gcc/testsuite/gcc.dg/atomic-flag.c (working copy)
@@ -1,5 +1,6 @@
/* Test __atomic routines for existence and execution. */
/* { dg-do run } */
+/* { dg-require-effective-target sync_char_short } */
/* Test that __atomic_test_and_set and __atomic_clear builtins execute. */
Index: gcc/testsuite/g++.dg/simulate-thread/atomics-2.C
===
--- gcc/testsuite/g++.dg/simulate-thread/atomics-2.C (revision 199961)
+++ gcc/testsuite/g++.dg/simulate-thread/atomics-2.C (working copy)
@@ -1,6 +1,7 @@
/* { dg-do link } */
/* { dg-options -std=c++0x } */
/* { dg-final { simulate-thread } } */
+/* { dg-require-effective-target sync_int_long } */
using namespace std;
Index: gcc/testsuite/g++.dg/simulate-thread/atomics-1.C
===
--- gcc/testsuite/g++.dg/simulate-thread/atomics-1.C (revision 199961)
+++ gcc/testsuite/g++.dg/simulate-thread/atomics-1.C (working copy)
@@ -1,6 +1,8 @@
/* { dg-do link } */
/* { dg-options -std=c++0x } */
/* { dg-final { simulate-thread } } */
+/* { dg-require-effective-target sync_char_short } */
+/* { dg-require-effective-target sync_int_long } */
/* Test that atomic int and atomic char work properly. */
Re: [PATCH] ARM: Don't clobber CC reg when it is live after the peephole window
On 06/06/2013 01:23 PM, Meador Inge wrote: On 06/06/2013 08:11 AM, Richard Earnshaw wrote: I understand (and agree with) this bit... +(define_peephole2 + [(set (reg:CC CC_REGNUM) +(compare:CC (match_operand:SI 0 register_operand ) +(match_operand:SI 1 arm_rhs_operand ))) + (cond_exec (ne (reg:CC CC_REGNUM) (const_int 0)) + (set (match_operand:SI 2 register_operand ) (const_int 0))) + (cond_exec (eq (reg:CC CC_REGNUM) (const_int 0)) + (set (match_dup 2) (const_int 1))) + (match_scratch:SI 3 r)] + TARGET_32BIT !peep2_reg_dead_p (3, operands[0]) + [(set (match_dup 3) (minus:SI (match_dup 0) (match_dup 1))) + (parallel +[(set (reg:CC CC_REGNUM) + (compare:CC (const_int 0) (match_dup 3))) + (set (match_dup 2) (minus:SI (const_int 0) (match_dup 3)))]) + (set (match_dup 2) +(plus:SI (plus:SI (match_dup 2) (match_dup 3)) + (geu:SI (reg:CC CC_REGNUM) (const_int 0]) + ... but what's this bit about? The original intent was to revert back to the original peephole pattern (pre-PR 46975) when the CC reg is still live, but that doesn't properly maintain the CC state either (it just happened to pass in the test case I was looking at because I only cared about the Z flag, which is maintained the same). OK with the above bit left out? OK? -- Meador Inge CodeSourcery / Mentor Embedded
Re: [PATCH] ARM: Don't clobber CC reg when it is live after the peephole window
On 06/06/2013 08:11 AM, Richard Earnshaw wrote: I understand (and agree with) this bit... +(define_peephole2 + [(set (reg:CC CC_REGNUM) +(compare:CC (match_operand:SI 0 register_operand ) +(match_operand:SI 1 arm_rhs_operand ))) + (cond_exec (ne (reg:CC CC_REGNUM) (const_int 0)) + (set (match_operand:SI 2 register_operand ) (const_int 0))) + (cond_exec (eq (reg:CC CC_REGNUM) (const_int 0)) + (set (match_dup 2) (const_int 1))) + (match_scratch:SI 3 r)] + TARGET_32BIT !peep2_reg_dead_p (3, operands[0]) + [(set (match_dup 3) (minus:SI (match_dup 0) (match_dup 1))) + (parallel +[(set (reg:CC CC_REGNUM) + (compare:CC (const_int 0) (match_dup 3))) + (set (match_dup 2) (minus:SI (const_int 0) (match_dup 3)))]) + (set (match_dup 2) +(plus:SI (plus:SI (match_dup 2) (match_dup 3)) + (geu:SI (reg:CC CC_REGNUM) (const_int 0]) + ... but what's this bit about? The original intent was to revert back to the original peephole pattern (pre-PR 46975) when the CC reg is still live, but that doesn't properly maintain the CC state either (it just happened to pass in the test case I was looking at because I only cared about the Z flag, which is maintained the same). OK with the above bit left out? -- Meador Inge CodeSourcery / Mentor Embedded
Re: [PATCH] ARM: Don't clobber CC reg when it is live after the peephole window
Ping.
On 05/29/2013 12:15 PM, Meador Inge wrote:
Hi All,
This patch fixes a bug in one of the ARM peephole2 optimizations. The
peephole2 optimization in question was changed to use the CC-updating
form for all of the instructions produced by the peephole so that the
encoding will be smaller when compiling for thumb [1]. However, I don't
think that is always safe.
For example, the CC register might be used by something *after* the
peephole window. The current peephole will transform:
(insn:TI 7 49 18 2 (set (reg:CC 24 cc)
(compare:CC (reg:SI 3 r3 [orig:136 *endname_1(D) ] [136])
(const_int 0 [0]))) repro.c:5 212 {*arm_cmpsi_insn}
(nil))
(insn:TI 18 7 11 2 (cond_exec (ne (reg:CC 24 cc)
(const_int 0 [0]))
(set (reg:SI 3 r3 [140])
(const_int 0 [0]))) repro.c:8 3366 {*p *arm_movsi_vfp}
(expr_list:REG_EQUIV (const_int 0 [0])
(nil)))
(insn 11 18 19 2 (cond_exec (eq (reg:CC 24 cc)
(const_int 0 [0]))
(set (reg:SI 3 r3 [138])
(const_int 1 [0x1]))) repro.c:6 3366 {*p *arm_movsi_vfp}
(expr_list:REG_EQUIV (const_int 1 [0x1])
(nil)))
(insn:TI 19 11 12 2 (cond_exec (ne (reg:CC 24 cc)
(const_int 0 [0]))
(set (mem/c:SI (reg/f:SI 2 r2 [143]) [2 atend+0 S4 A32])
(reg:SI 3 r3 [140]))) repro.c:8 3366 {*p *arm_movsi_vfp}
(expr_list:REG_DEAD (reg/f:SI 2 r2 [143])
(nil)))
(insn:TI 12 19 22 2 (cond_exec (eq (reg:CC 24 cc)
(const_int 0 [0]))
(set (mem/c:SI (reg/f:SI 2 r2 [143]) [2 atend+0 S4 A32])
(reg:SI 3 r3 [138]))) repro.c:6 3366 {*p *arm_movsi_vfp}
(nil))
(insn:TI 22 12 58 2 (cond_exec (ne (reg:CC 24 cc)
(const_int 0 [0]))
(set (mem:QI (reg/v/f:SI 0 r0 [orig:135 endname ] [135]) [0
*endname_1(D)+0 S1 A8])
(reg:QI 3 r3 [140]))) repro.c:9 3115 {*p *arm_movqi_insn}
(expr_list:REG_DEAD (reg:CC 24 cc)
(expr_list:REG_DEAD (reg:QI 3 r3 [140])
(expr_list:REG_DEAD (reg/v/f:SI 0 r0 [orig:135 endname ]
[135])
(nil)
into the following:
(insn 59 49 60 2 (parallel [
(set (reg:CC 24 cc)
(compare:CC (reg:SI 3 r3 [orig:136 *endname_1(D) ] [136])
(const_int 0 [0])))
(set (reg:SI 1 r1)
(minus:SI (reg:SI 3 r3 [orig:136 *endname_1(D) ] [136])
(const_int 0 [0])))
]) repro.c:6 -1
(nil))
(insn 60 59 61 2 (parallel [
(set (reg:CC 24 cc)
(compare:CC (const_int 0 [0])
(reg:SI 1 r1)))
(set (reg:SI 3 r3 [140])
(minus:SI (const_int 0 [0])
(reg:SI 1 r1)))
]) repro.c:6 -1
(nil))
(insn 61 60 19 2 (parallel [
(set (reg:SI 3 r3 [140])
(plus:SI (plus:SI (reg:SI 3 r3 [140])
(reg:SI 1 r1))
(geu:SI (reg:CC 24 cc)
(const_int 0 [0]
(clobber (reg:CC 24 cc))
]) repro.c:6 -1
(nil))
(insn:TI 19 61 12 2 (cond_exec (ne (reg:CC 24 cc)
(const_int 0 [0]))
(set (mem/c:SI (reg/f:SI 2 r2 [143]) [2 atend+0 S4 A32])
(reg:SI 3 r3 [140]))) repro.c:8 3366 {*p *arm_movsi_vfp}
(nil))
(insn:TI 12 19 22 2 (cond_exec (eq (reg:CC 24 cc)
(const_int 0 [0]))
(set (mem/c:SI (reg/f:SI 2 r2 [143]) [2 atend+0 S4 A32])
(reg:SI 3 r3 [138]))) repro.c:6 3366 {*p *arm_movsi_vfp}
(expr_list:REG_DEAD (reg/f:SI 2 r2 [143])
(nil)))
(insn:TI 22 12 58 2 (cond_exec (ne (reg:CC 24 cc)
(const_int 0 [0]))
(set (mem:QI (reg/v/f:SI 0 r0 [orig:135 endname ] [135]) [0
*endname_1(D)+0 S1 A8])
(reg:QI 3 r3 [140]))) repro.c:9 3115 {*p *arm_movqi_insn}
(expr_list:REG_DEAD (reg:CC 24 cc)
(expr_list:REG_DEAD (reg:QI 3 r3 [140])
(expr_list:REG_DEAD (reg/v/f:SI 0 r0 [orig:135 endname ]
[135])
(nil)
This gets compiled into the incorrect sequence:
ldrbr3, [r0, #0]
ldr r2, .L4
subsr1, r3, #0
rsbsr3, r1, #0
adcsr3, r3, r1
strne r3, [r2, #0]
streq r3, [r2, #0]
strneb r3, [r0, #0]
The conditional stores are now dealing with an incorrect condition state.
This patch fixes the problem by ensuring that the CC reg is dead after the
peephole window for the current peephole definition and falls back on the
original pre
[PATCH] ARM: Don't clobber CC reg when it is live after the peephole window
that exposed it. Built and tested a full ARM GNU/Linux toolchain. No regressions in the GCC test suite. OK? gcc/ 2013-05-29 Meador Inge mead...@codesourcery.com * config/arm/arm.md (conditional move peephole2): Only clobber CC register when it is dead after the peephole window. [1] http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01336.html Index: gcc/config/arm/arm.md === --- gcc/config/arm/arm.md (revision 199414) +++ gcc/config/arm/arm.md (working copy) @@ -9978,29 +9978,48 @@ ;; Attempt to improve the sequence generated by the compare_scc splitters ;; not to use conditional execution. (define_peephole2 - [(set (reg:CC CC_REGNUM) + [(set (match_operand 0 cc_register ) (compare:CC (match_operand:SI 1 register_operand ) (match_operand:SI 2 arm_rhs_operand ))) (cond_exec (ne (reg:CC CC_REGNUM) (const_int 0)) - (set (match_operand:SI 0 register_operand ) (const_int 0))) + (set (match_operand:SI 3 register_operand ) (const_int 0))) (cond_exec (eq (reg:CC CC_REGNUM) (const_int 0)) - (set (match_dup 0) (const_int 1))) - (match_scratch:SI 3 r)] - TARGET_32BIT + (set (match_dup 3) (const_int 1))) + (match_scratch:SI 4 r)] + TARGET_32BIT peep2_reg_dead_p (3, operands[0]) [(parallel [(set (reg:CC CC_REGNUM) (compare:CC (match_dup 1) (match_dup 2))) - (set (match_dup 3) (minus:SI (match_dup 1) (match_dup 2)))]) + (set (match_dup 4) (minus:SI (match_dup 1) (match_dup 2)))]) (parallel [(set (reg:CC CC_REGNUM) - (compare:CC (const_int 0) (match_dup 3))) - (set (match_dup 0) (minus:SI (const_int 0) (match_dup 3)))]) + (compare:CC (const_int 0) (match_dup 4))) + (set (match_dup 3) (minus:SI (const_int 0) (match_dup 4)))]) (parallel -[(set (match_dup 0) - (plus:SI (plus:SI (match_dup 0) (match_dup 3)) +[(set (match_dup 3) + (plus:SI (plus:SI (match_dup 3) (match_dup 4)) (geu:SI (reg:CC CC_REGNUM) (const_int 0 (clobber (reg:CC CC_REGNUM))])]) +(define_peephole2 + [(set (reg:CC CC_REGNUM) + (compare:CC (match_operand:SI 0 register_operand ) + (match_operand:SI 1 arm_rhs_operand ))) + (cond_exec (ne (reg:CC CC_REGNUM) (const_int 0)) + (set (match_operand:SI 2 register_operand ) (const_int 0))) + (cond_exec (eq (reg:CC CC_REGNUM) (const_int 0)) + (set (match_dup 2) (const_int 1))) + (match_scratch:SI 3 r)] + TARGET_32BIT !peep2_reg_dead_p (3, operands[0]) + [(set (match_dup 3) (minus:SI (match_dup 0) (match_dup 1))) + (parallel +[(set (reg:CC CC_REGNUM) + (compare:CC (const_int 0) (match_dup 3))) + (set (match_dup 2) (minus:SI (const_int 0) (match_dup 3)))]) + (set (match_dup 2) + (plus:SI (plus:SI (match_dup 2) (match_dup 3)) +(geu:SI (reg:CC CC_REGNUM) (const_int 0]) + (define_insn *cond_move [(set (match_operand:SI 0 s_register_operand =r,r,r) (if_then_else:SI (match_operator 3 equality_operator
[PATCH] libgcc: Add DWARF info to aeabi_ldivmod and aeabi_uldivmod
Hi All,
This patch fixes a minor annoyance that causes backtraces to disappear
inside of aeabi_ldivmod and aeabi_uldivmod due to the lack of appropriate
DWARF information. I fixed the problem by adding the necessary cfi_*
macros in these functions.
OK?
2013-03-05 Meador Inge mead...@codesourcery.com
* config/arm/bpabi.S (aeabi_ldivmod): Add DWARF information for
computing the location of the link register.
(aeabi_uldivmod): Ditto.
Index: libgcc/config/arm/bpabi.S
===
--- libgcc/config/arm/bpabi.S (revision 196470)
+++ libgcc/config/arm/bpabi.S (working copy)
@@ -123,6 +123,7 @@ ARM_FUNC_START aeabi_ulcmp
#ifdef L_aeabi_ldivmod
ARM_FUNC_START aeabi_ldivmod
+ cfi_start __aeabi_ldivmod, LSYM(Lend_aeabi_ldivmod)
test_div_by_zero signed
sub sp, sp, #8
@@ -132,17 +133,20 @@ ARM_FUNC_START aeabi_ldivmod
#else
do_push {sp, lr}
#endif
+98:cfi_push 98b - __aeabi_ldivmod, 0xe, -0xc, 0x10
bl SYM(__gnu_ldivmod_helper) __PLT__
ldr lr, [sp, #4]
add sp, sp, #8
do_pop {r2, r3}
RET
+ cfi_end LSYM(Lend_aeabi_ldivmod)
#endif /* L_aeabi_ldivmod */
#ifdef L_aeabi_uldivmod
ARM_FUNC_START aeabi_uldivmod
+ cfi_start __aeabi_uldivmod, LSYM(Lend_aeabi_uldivmod)
test_div_by_zero unsigned
sub sp, sp, #8
@@ -152,11 +156,13 @@ ARM_FUNC_START aeabi_uldivmod
#else
do_push {sp, lr}
#endif
+98:cfi_push 98b - __aeabi_uldivmod, 0xe, -0xc, 0x10
bl SYM(__gnu_uldivmod_helper) __PLT__
ldr lr, [sp, #4]
add sp, sp, #8
do_pop {r2, r3}
RET
-
+ cfi_end LSYM(Lend_aeabi_uldivmod)
+
#endif /* L_aeabi_divmod */
Re: [PATCH] gcc-{ar,nm,ranlib}: Find binutils binaries relative to self
On 11/26/2012 09:05 AM, Richard Biener wrote: On Wed, Nov 7, 2012 at 10:51 PM, Meador Inge mead...@codesourcery.com wrote: Ping ^ 4. Ok. Thanks for the review. Committed to trunk. -- Meador Inge CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software
Re: [PATCH] gcc-{ar,nm,ranlib}: Find binutils binaries relative to self
Ping ^ 4.
On 10/29/2012 10:46 AM, Meador Inge wrote:
Ping ^ 3.
On 10/18/2012 10:30 AM, Meador Inge wrote:
Ping ^ 2.
On 10/09/2012 09:44 PM, Meador Inge wrote:
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped binutils program. This goes against the
accepted practice in GCC to find sub-programs relative to where the
GCC binaries are stored and to not make assumptions about the PATH.
This patch changes the gcc-{ar,nm,ranlib} utilities to do the same
by factoring out some utility code for finding files from collect2.c.
These functions are then leveraged to find the binutils programs.
Note that similar code exist in gcc.c. Perhaps one day everything
can be merged to the file-find files.
Tested for Windows and GNU/Linux hosts and i686-pc-linux-gnu and
arm-none-eabi targets. OK?
P.S. I am not quite sure what is best for the copyrights and contributed
by comments in the file-find* files I added since that code was just moved.
This patch drops the contributed by and keeps all the copyright dates from
collect2.c.
2012-10-04 Meador Inge mead...@codesourcery.com
* collect2.c (main): Call find_file_set_debug.
(find_a_find, add_prefix, prefix_from_env, prefix_from_string):
Factor out into ...
* file-find.c (New file): ... here and ...
* file-find.h (New file): ... here.
* gcc-ar.c (standard_exec_prefix): New variable.
(standard_libexec_prefix): Ditto.
(tooldir_base_prefix) Ditto.
(self_exec_prefix): Ditto.
(self_libexec_prefix): Ditto.
(self_tooldir_prefix): Ditto.
(target_version): Ditto.
(path): Ditto.
(target_path): Ditto.
(setup_prefixes): New function.
(main): Rework how wrapped programs are found.
* Makefile.in (OBJS-libcommon-target): Add file-find.o.
(AR_OBJS): New variable.
(gcc-ar$(exeext)): Add dependency on $(AR_OBJS).
(gcc-nm$(exeext)): Ditto.
(gcc-ranlib(exeext)): Ditto.
(COLLECT2_OBJS): Add file-find.o.
(collect2.o): Add file-find.h prerequisite.
(file-find.o): New rule.
Index: gcc/gcc-ar.c
===
--- gcc/gcc-ar.c (revision 192099)
+++ gcc/gcc-ar.c (working copy)
@@ -21,21 +21,110 @@
#include config.h
#include system.h
#include libiberty.h
+#include file-find.h
#ifndef PERSONALITY
#error Please set personality
#endif
+/* The exec prefix as derived at compile-time from --prefix. */
+
+static const char standard_exec_prefix[] = STANDARD_EXEC_PREFIX;
+
+/* The libexec prefix as derived at compile-time from --prefix. */
+
static const char standard_libexec_prefix[] = STANDARD_LIBEXEC_PREFIX;
+
+/* The bindir prefix as derived at compile-time from --prefix. */
+
static const char standard_bin_prefix[] = STANDARD_BINDIR_PREFIX;
-static const char *const target_machine = TARGET_MACHINE;
+/* A relative path to be used in finding the location of tools
+ relative to this program. */
+
+static const char *const tooldir_base_prefix = TOOLDIR_BASE_PREFIX;
+
+/* The exec prefix as relocated from the location of this program. */
+
+static const char *self_exec_prefix;
+
+/* The libexec prefix as relocated from the location of this program. */
+
+static const char *self_libexec_prefix;
+
+/* The tools prefix as relocated from the location of this program. */
+
+static const char *self_tooldir_prefix;
+
+/* The name of the machine that is being targeted. */
+
+static const char *const target_machine = DEFAULT_TARGET_MACHINE;
+
+/* The target version. */
+
+static const char *const target_version = DEFAULT_TARGET_VERSION;
+
+/* The collection of target specific path prefixes. */
+
+static struct path_prefix target_path;
+
+/* The collection path prefixes. */
+
+static struct path_prefix path;
+
+/* The directory separator. */
+
static const char dir_separator[] = { DIR_SEPARATOR, 0 };
+static void
+setup_prefixes (const char *exec_path)
+{
+ const char *self;
+
+ self = getenv (GCC_EXEC_PREFIX);
+ if (!self)
+self = exec_path;
+ else
+self = concat (self, gcc- PERSONALITY, NULL);
+
+ /* Relocate the exec prefix. */
+ self_exec_prefix = make_relative_prefix (self,
+ standard_bin_prefix,
+ standard_exec_prefix);
+ if (self_exec_prefix == NULL)
+self_exec_prefix = standard_exec_prefix;
+
+ /* Relocate libexec prefix. */
+ self_libexec_prefix = make_relative_prefix (self,
+standard_bin_prefix,
+standard_libexec_prefix);
+ if (self_libexec_prefix == NULL)
+self_libexec_prefix = standard_libexec_prefix;
+
+
+ /* Build the relative path to the target-specific tool directory. */
+ self_tooldir_prefix = concat
Re: [PATCH] gcc-{ar,nm,ranlib}: Find binutils binaries relative to self
Ping ^ 3.
On 10/18/2012 10:30 AM, Meador Inge wrote:
Ping ^ 2.
On 10/09/2012 09:44 PM, Meador Inge wrote:
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped binutils program. This goes against the
accepted practice in GCC to find sub-programs relative to where the
GCC binaries are stored and to not make assumptions about the PATH.
This patch changes the gcc-{ar,nm,ranlib} utilities to do the same
by factoring out some utility code for finding files from collect2.c.
These functions are then leveraged to find the binutils programs.
Note that similar code exist in gcc.c. Perhaps one day everything
can be merged to the file-find files.
Tested for Windows and GNU/Linux hosts and i686-pc-linux-gnu and
arm-none-eabi targets. OK?
P.S. I am not quite sure what is best for the copyrights and contributed
by comments in the file-find* files I added since that code was just moved.
This patch drops the contributed by and keeps all the copyright dates from
collect2.c.
2012-10-04 Meador Inge mead...@codesourcery.com
* collect2.c (main): Call find_file_set_debug.
(find_a_find, add_prefix, prefix_from_env, prefix_from_string):
Factor out into ...
* file-find.c (New file): ... here and ...
* file-find.h (New file): ... here.
* gcc-ar.c (standard_exec_prefix): New variable.
(standard_libexec_prefix): Ditto.
(tooldir_base_prefix) Ditto.
(self_exec_prefix): Ditto.
(self_libexec_prefix): Ditto.
(self_tooldir_prefix): Ditto.
(target_version): Ditto.
(path): Ditto.
(target_path): Ditto.
(setup_prefixes): New function.
(main): Rework how wrapped programs are found.
* Makefile.in (OBJS-libcommon-target): Add file-find.o.
(AR_OBJS): New variable.
(gcc-ar$(exeext)): Add dependency on $(AR_OBJS).
(gcc-nm$(exeext)): Ditto.
(gcc-ranlib(exeext)): Ditto.
(COLLECT2_OBJS): Add file-find.o.
(collect2.o): Add file-find.h prerequisite.
(file-find.o): New rule.
Index: gcc/gcc-ar.c
===
--- gcc/gcc-ar.c(revision 192099)
+++ gcc/gcc-ar.c(working copy)
@@ -21,21 +21,110 @@
#include config.h
#include system.h
#include libiberty.h
+#include file-find.h
#ifndef PERSONALITY
#error Please set personality
#endif
+/* The exec prefix as derived at compile-time from --prefix. */
+
+static const char standard_exec_prefix[] = STANDARD_EXEC_PREFIX;
+
+/* The libexec prefix as derived at compile-time from --prefix. */
+
static const char standard_libexec_prefix[] = STANDARD_LIBEXEC_PREFIX;
+
+/* The bindir prefix as derived at compile-time from --prefix. */
+
static const char standard_bin_prefix[] = STANDARD_BINDIR_PREFIX;
-static const char *const target_machine = TARGET_MACHINE;
+/* A relative path to be used in finding the location of tools
+ relative to this program. */
+
+static const char *const tooldir_base_prefix = TOOLDIR_BASE_PREFIX;
+
+/* The exec prefix as relocated from the location of this program. */
+
+static const char *self_exec_prefix;
+
+/* The libexec prefix as relocated from the location of this program. */
+
+static const char *self_libexec_prefix;
+
+/* The tools prefix as relocated from the location of this program. */
+
+static const char *self_tooldir_prefix;
+
+/* The name of the machine that is being targeted. */
+
+static const char *const target_machine = DEFAULT_TARGET_MACHINE;
+
+/* The target version. */
+
+static const char *const target_version = DEFAULT_TARGET_VERSION;
+
+/* The collection of target specific path prefixes. */
+
+static struct path_prefix target_path;
+
+/* The collection path prefixes. */
+
+static struct path_prefix path;
+
+/* The directory separator. */
+
static const char dir_separator[] = { DIR_SEPARATOR, 0 };
+static void
+setup_prefixes (const char *exec_path)
+{
+ const char *self;
+
+ self = getenv (GCC_EXEC_PREFIX);
+ if (!self)
+self = exec_path;
+ else
+self = concat (self, gcc- PERSONALITY, NULL);
+
+ /* Relocate the exec prefix. */
+ self_exec_prefix = make_relative_prefix (self,
+ standard_bin_prefix,
+ standard_exec_prefix);
+ if (self_exec_prefix == NULL)
+self_exec_prefix = standard_exec_prefix;
+
+ /* Relocate libexec prefix. */
+ self_libexec_prefix = make_relative_prefix (self,
+ standard_bin_prefix,
+ standard_libexec_prefix);
+ if (self_libexec_prefix == NULL)
+self_libexec_prefix = standard_libexec_prefix;
+
+
+ /* Build the relative path to the target-specific tool directory. */
+ self_tooldir_prefix = concat (tooldir_base_prefix, target_machine
Re: [PATCH] gcc-{ar,nm,ranlib}: Find binutils binaries relative to self
On 10/18/2012 01:33 PM, Bernhard Reutner-Fischer wrote:
On 18 October 2012 17:30:20 Meador Inge mead...@codesourcery.com wrote:
Ping ^ 2
Been a while but wasn't --with-build-sysroot for exactly this?
AFAICT, no. --with-build-sysroot seems to be used for setting a different
sysroot to use for compiling target libraries while GCC is being built [1].
This patch fixes the gcc-{ar,nm,ranlib} programs that are built and deployed
with GCC to not rely on the current PATH when running the binutils programs
they are wrapping.
[1] http://gcc.gnu.org/install/configure.html
--
Meador Inge
CodeSourcery / Mentor Embedded
Re: [PATCH] gcc-{ar,nm,ranlib}: Find binutils binaries relative to self
CC'ing the LTO maintainers.
On 10/18/2012 10:30 AM, Meador Inge wrote:
Ping ^ 2.
On 10/09/2012 09:44 PM, Meador Inge wrote:
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped binutils program. This goes against the
accepted practice in GCC to find sub-programs relative to where the
GCC binaries are stored and to not make assumptions about the PATH.
This patch changes the gcc-{ar,nm,ranlib} utilities to do the same
by factoring out some utility code for finding files from collect2.c.
These functions are then leveraged to find the binutils programs.
Note that similar code exist in gcc.c. Perhaps one day everything
can be merged to the file-find files.
Tested for Windows and GNU/Linux hosts and i686-pc-linux-gnu and
arm-none-eabi targets. OK?
P.S. I am not quite sure what is best for the copyrights and contributed
by comments in the file-find* files I added since that code was just moved.
This patch drops the contributed by and keeps all the copyright dates from
collect2.c.
2012-10-04 Meador Inge mead...@codesourcery.com
* collect2.c (main): Call find_file_set_debug.
(find_a_find, add_prefix, prefix_from_env, prefix_from_string):
Factor out into ...
* file-find.c (New file): ... here and ...
* file-find.h (New file): ... here.
* gcc-ar.c (standard_exec_prefix): New variable.
(standard_libexec_prefix): Ditto.
(tooldir_base_prefix) Ditto.
(self_exec_prefix): Ditto.
(self_libexec_prefix): Ditto.
(self_tooldir_prefix): Ditto.
(target_version): Ditto.
(path): Ditto.
(target_path): Ditto.
(setup_prefixes): New function.
(main): Rework how wrapped programs are found.
* Makefile.in (OBJS-libcommon-target): Add file-find.o.
(AR_OBJS): New variable.
(gcc-ar$(exeext)): Add dependency on $(AR_OBJS).
(gcc-nm$(exeext)): Ditto.
(gcc-ranlib(exeext)): Ditto.
(COLLECT2_OBJS): Add file-find.o.
(collect2.o): Add file-find.h prerequisite.
(file-find.o): New rule.
Index: gcc/gcc-ar.c
===
--- gcc/gcc-ar.c(revision 192099)
+++ gcc/gcc-ar.c(working copy)
@@ -21,21 +21,110 @@
#include config.h
#include system.h
#include libiberty.h
+#include file-find.h
#ifndef PERSONALITY
#error Please set personality
#endif
+/* The exec prefix as derived at compile-time from --prefix. */
+
+static const char standard_exec_prefix[] = STANDARD_EXEC_PREFIX;
+
+/* The libexec prefix as derived at compile-time from --prefix. */
+
static const char standard_libexec_prefix[] = STANDARD_LIBEXEC_PREFIX;
+
+/* The bindir prefix as derived at compile-time from --prefix. */
+
static const char standard_bin_prefix[] = STANDARD_BINDIR_PREFIX;
-static const char *const target_machine = TARGET_MACHINE;
+/* A relative path to be used in finding the location of tools
+ relative to this program. */
+
+static const char *const tooldir_base_prefix = TOOLDIR_BASE_PREFIX;
+
+/* The exec prefix as relocated from the location of this program. */
+
+static const char *self_exec_prefix;
+
+/* The libexec prefix as relocated from the location of this program. */
+
+static const char *self_libexec_prefix;
+
+/* The tools prefix as relocated from the location of this program. */
+
+static const char *self_tooldir_prefix;
+
+/* The name of the machine that is being targeted. */
+
+static const char *const target_machine = DEFAULT_TARGET_MACHINE;
+
+/* The target version. */
+
+static const char *const target_version = DEFAULT_TARGET_VERSION;
+
+/* The collection of target specific path prefixes. */
+
+static struct path_prefix target_path;
+
+/* The collection path prefixes. */
+
+static struct path_prefix path;
+
+/* The directory separator. */
+
static const char dir_separator[] = { DIR_SEPARATOR, 0 };
+static void
+setup_prefixes (const char *exec_path)
+{
+ const char *self;
+
+ self = getenv (GCC_EXEC_PREFIX);
+ if (!self)
+self = exec_path;
+ else
+self = concat (self, gcc- PERSONALITY, NULL);
+
+ /* Relocate the exec prefix. */
+ self_exec_prefix = make_relative_prefix (self,
+ standard_bin_prefix,
+ standard_exec_prefix);
+ if (self_exec_prefix == NULL)
+self_exec_prefix = standard_exec_prefix;
+
+ /* Relocate libexec prefix. */
+ self_libexec_prefix = make_relative_prefix (self,
+ standard_bin_prefix,
+ standard_libexec_prefix);
+ if (self_libexec_prefix == NULL)
+self_libexec_prefix = standard_libexec_prefix;
+
+
+ /* Build the relative path to the target-specific tool directory. */
+ self_tooldir_prefix = concat (tooldir_base_prefix
Re: [PATCH] gcc-{ar,nm,ranlib}: Find binutils binaries relative to self
Ping ^ 2.
On 10/09/2012 09:44 PM, Meador Inge wrote:
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped binutils program. This goes against the
accepted practice in GCC to find sub-programs relative to where the
GCC binaries are stored and to not make assumptions about the PATH.
This patch changes the gcc-{ar,nm,ranlib} utilities to do the same
by factoring out some utility code for finding files from collect2.c.
These functions are then leveraged to find the binutils programs.
Note that similar code exist in gcc.c. Perhaps one day everything
can be merged to the file-find files.
Tested for Windows and GNU/Linux hosts and i686-pc-linux-gnu and
arm-none-eabi targets. OK?
P.S. I am not quite sure what is best for the copyrights and contributed
by comments in the file-find* files I added since that code was just moved.
This patch drops the contributed by and keeps all the copyright dates from
collect2.c.
2012-10-04 Meador Inge mead...@codesourcery.com
* collect2.c (main): Call find_file_set_debug.
(find_a_find, add_prefix, prefix_from_env, prefix_from_string):
Factor out into ...
* file-find.c (New file): ... here and ...
* file-find.h (New file): ... here.
* gcc-ar.c (standard_exec_prefix): New variable.
(standard_libexec_prefix): Ditto.
(tooldir_base_prefix) Ditto.
(self_exec_prefix): Ditto.
(self_libexec_prefix): Ditto.
(self_tooldir_prefix): Ditto.
(target_version): Ditto.
(path): Ditto.
(target_path): Ditto.
(setup_prefixes): New function.
(main): Rework how wrapped programs are found.
* Makefile.in (OBJS-libcommon-target): Add file-find.o.
(AR_OBJS): New variable.
(gcc-ar$(exeext)): Add dependency on $(AR_OBJS).
(gcc-nm$(exeext)): Ditto.
(gcc-ranlib(exeext)): Ditto.
(COLLECT2_OBJS): Add file-find.o.
(collect2.o): Add file-find.h prerequisite.
(file-find.o): New rule.
Index: gcc/gcc-ar.c
===
--- gcc/gcc-ar.c (revision 192099)
+++ gcc/gcc-ar.c (working copy)
@@ -21,21 +21,110 @@
#include config.h
#include system.h
#include libiberty.h
+#include file-find.h
#ifndef PERSONALITY
#error Please set personality
#endif
+/* The exec prefix as derived at compile-time from --prefix. */
+
+static const char standard_exec_prefix[] = STANDARD_EXEC_PREFIX;
+
+/* The libexec prefix as derived at compile-time from --prefix. */
+
static const char standard_libexec_prefix[] = STANDARD_LIBEXEC_PREFIX;
+
+/* The bindir prefix as derived at compile-time from --prefix. */
+
static const char standard_bin_prefix[] = STANDARD_BINDIR_PREFIX;
-static const char *const target_machine = TARGET_MACHINE;
+/* A relative path to be used in finding the location of tools
+ relative to this program. */
+
+static const char *const tooldir_base_prefix = TOOLDIR_BASE_PREFIX;
+
+/* The exec prefix as relocated from the location of this program. */
+
+static const char *self_exec_prefix;
+
+/* The libexec prefix as relocated from the location of this program. */
+
+static const char *self_libexec_prefix;
+
+/* The tools prefix as relocated from the location of this program. */
+
+static const char *self_tooldir_prefix;
+
+/* The name of the machine that is being targeted. */
+
+static const char *const target_machine = DEFAULT_TARGET_MACHINE;
+
+/* The target version. */
+
+static const char *const target_version = DEFAULT_TARGET_VERSION;
+
+/* The collection of target specific path prefixes. */
+
+static struct path_prefix target_path;
+
+/* The collection path prefixes. */
+
+static struct path_prefix path;
+
+/* The directory separator. */
+
static const char dir_separator[] = { DIR_SEPARATOR, 0 };
+static void
+setup_prefixes (const char *exec_path)
+{
+ const char *self;
+
+ self = getenv (GCC_EXEC_PREFIX);
+ if (!self)
+self = exec_path;
+ else
+self = concat (self, gcc- PERSONALITY, NULL);
+
+ /* Relocate the exec prefix. */
+ self_exec_prefix = make_relative_prefix (self,
+ standard_bin_prefix,
+ standard_exec_prefix);
+ if (self_exec_prefix == NULL)
+self_exec_prefix = standard_exec_prefix;
+
+ /* Relocate libexec prefix. */
+ self_libexec_prefix = make_relative_prefix (self,
+ standard_bin_prefix,
+ standard_libexec_prefix);
+ if (self_libexec_prefix == NULL)
+self_libexec_prefix = standard_libexec_prefix;
+
+
+ /* Build the relative path to the target-specific tool directory. */
+ self_tooldir_prefix = concat (tooldir_base_prefix, target_machine
Re: [PATCH] gcc-{ar,nm,ranlib}: Find binutils binaries relative to self
Ping.
On 10/04/2012 03:45 PM, Meador Inge wrote:
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped binutils program. This goes against the
accepted practice in GCC to find sub-programs relative to where the
GCC binaries are stored and to not make assumptions about the PATH.
This patch changes the gcc-{ar,nm,ranlib} utilities to do the same
by factoring out some utility code for finding files from collect2.c.
These functions are then leveraged to find the binutils programs.
Note that similar code exist in gcc.c. Perhaps one day everything
can be merged to the file-find files.
Tested for Windows and GNU/Linux hosts and i686-pc-linux-gnu and
arm-none-eabi targets. OK?
P.S. I am not quite sure what is best for the copyrights and contributed
by comments in the file-find* files I added since that code was just moved.
This patch drops the contributed by and keeps all the copyright dates from
collect2.c.
2012-10-04 Meador Inge mead...@codesourcery.com
* collect2.c (main): Call find_file_set_debug.
(find_a_find, add_prefix, prefix_from_env, prefix_from_string):
Factor out into ...
* file-find.c (New file): ... here and ...
* file-find.h (New file): ... here.
* gcc-ar.c (standard_exec_prefix): New variable.
(standard_libexec_prefix): Ditto.
(tooldir_base_prefix) Ditto.
(self_exec_prefix): Ditto.
(self_libexec_prefix): Ditto.
(self_tooldir_prefix): Ditto.
(target_version): Ditto.
(path): Ditto.
(target_path): Ditto.
(setup_prefixes): New function.
(main): Rework how wrapped programs are found.
* Makefile.in (OBJS-libcommon-target): Add file-find.o.
(AR_OBJS): New variable.
(gcc-ar$(exeext)): Add dependency on $(AR_OBJS).
(gcc-nm$(exeext)): Ditto.
(gcc-ranlib(exeext)): Ditto.
(COLLECT2_OBJS): Add file-find.o.
(collect2.o): Add file-find.h prerequisite.
(file-find.o): New rule.
Index: gcc/gcc-ar.c
===
--- gcc/gcc-ar.c (revision 192099)
+++ gcc/gcc-ar.c (working copy)
@@ -21,21 +21,110 @@
#include config.h
#include system.h
#include libiberty.h
+#include file-find.h
#ifndef PERSONALITY
#error Please set personality
#endif
+/* The exec prefix as derived at compile-time from --prefix. */
+
+static const char standard_exec_prefix[] = STANDARD_EXEC_PREFIX;
+
+/* The libexec prefix as derived at compile-time from --prefix. */
+
static const char standard_libexec_prefix[] = STANDARD_LIBEXEC_PREFIX;
+
+/* The bindir prefix as derived at compile-time from --prefix. */
+
static const char standard_bin_prefix[] = STANDARD_BINDIR_PREFIX;
-static const char *const target_machine = TARGET_MACHINE;
+/* A relative path to be used in finding the location of tools
+ relative to this program. */
+
+static const char *const tooldir_base_prefix = TOOLDIR_BASE_PREFIX;
+
+/* The exec prefix as relocated from the location of this program. */
+
+static const char *self_exec_prefix;
+
+/* The libexec prefix as relocated from the location of this program. */
+
+static const char *self_libexec_prefix;
+
+/* The tools prefix as relocated from the location of this program. */
+
+static const char *self_tooldir_prefix;
+
+/* The name of the machine that is being targeted. */
+
+static const char *const target_machine = DEFAULT_TARGET_MACHINE;
+
+/* The target version. */
+
+static const char *const target_version = DEFAULT_TARGET_VERSION;
+
+/* The collection of target specific path prefixes. */
+
+static struct path_prefix target_path;
+
+/* The collection path prefixes. */
+
+static struct path_prefix path;
+
+/* The directory separator. */
+
static const char dir_separator[] = { DIR_SEPARATOR, 0 };
+static void
+setup_prefixes (const char *exec_path)
+{
+ const char *self;
+
+ self = getenv (GCC_EXEC_PREFIX);
+ if (!self)
+self = exec_path;
+ else
+self = concat (self, gcc- PERSONALITY, NULL);
+
+ /* Relocate the exec prefix. */
+ self_exec_prefix = make_relative_prefix (self,
+standard_bin_prefix,
+standard_exec_prefix);
+ if (self_exec_prefix == NULL)
+self_exec_prefix = standard_exec_prefix;
+
+ /* Relocate libexec prefix. */
+ self_libexec_prefix = make_relative_prefix (self,
+ standard_bin_prefix,
+ standard_libexec_prefix);
+ if (self_libexec_prefix == NULL)
+self_libexec_prefix = standard_libexec_prefix;
+
+
+ /* Build the relative path to the target-specific tool directory. */
+ self_tooldir_prefix = concat (tooldir_base_prefix, target_machine,
+ dir_separator, NULL
[PATCH] gcc-{ar,nm,ranlib}: Find binutils binaries relative to self
Hi All,
Currently the gcc-{ar,nm,ranlib} utilities assume that binutils is in
path when invoking the wrapped binutils program. This goes against the
accepted practice in GCC to find sub-programs relative to where the
GCC binaries are stored and to not make assumptions about the PATH.
This patch changes the gcc-{ar,nm,ranlib} utilities to do the same
by factoring out some utility code for finding files from collect2.c.
These functions are then leveraged to find the binutils programs.
Note that similar code exist in gcc.c. Perhaps one day everything
can be merged to the file-find files.
Tested for Windows and GNU/Linux hosts and i686-pc-linux-gnu and
arm-none-eabi targets. OK?
P.S. I am not quite sure what is best for the copyrights and contributed
by comments in the file-find* files I added since that code was just moved.
This patch drops the contributed by and keeps all the copyright dates from
collect2.c.
2012-10-04 Meador Inge mead...@codesourcery.com
* collect2.c (main): Call find_file_set_debug.
(find_a_find, add_prefix, prefix_from_env, prefix_from_string):
Factor out into ...
* file-find.c (New file): ... here and ...
* file-find.h (New file): ... here.
* gcc-ar.c (standard_exec_prefix): New variable.
(standard_libexec_prefix): Ditto.
(tooldir_base_prefix) Ditto.
(self_exec_prefix): Ditto.
(self_libexec_prefix): Ditto.
(self_tooldir_prefix): Ditto.
(target_version): Ditto.
(path): Ditto.
(target_path): Ditto.
(setup_prefixes): New function.
(main): Rework how wrapped programs are found.
* Makefile.in (OBJS-libcommon-target): Add file-find.o.
(AR_OBJS): New variable.
(gcc-ar$(exeext)): Add dependency on $(AR_OBJS).
(gcc-nm$(exeext)): Ditto.
(gcc-ranlib(exeext)): Ditto.
(COLLECT2_OBJS): Add file-find.o.
(collect2.o): Add file-find.h prerequisite.
(file-find.o): New rule.
Index: gcc/gcc-ar.c
===
--- gcc/gcc-ar.c(revision 192099)
+++ gcc/gcc-ar.c(working copy)
@@ -21,21 +21,110 @@
#include config.h
#include system.h
#include libiberty.h
+#include file-find.h
#ifndef PERSONALITY
#error Please set personality
#endif
+/* The exec prefix as derived at compile-time from --prefix. */
+
+static const char standard_exec_prefix[] = STANDARD_EXEC_PREFIX;
+
+/* The libexec prefix as derived at compile-time from --prefix. */
+
static const char standard_libexec_prefix[] = STANDARD_LIBEXEC_PREFIX;
+
+/* The bindir prefix as derived at compile-time from --prefix. */
+
static const char standard_bin_prefix[] = STANDARD_BINDIR_PREFIX;
-static const char *const target_machine = TARGET_MACHINE;
+/* A relative path to be used in finding the location of tools
+ relative to this program. */
+
+static const char *const tooldir_base_prefix = TOOLDIR_BASE_PREFIX;
+
+/* The exec prefix as relocated from the location of this program. */
+
+static const char *self_exec_prefix;
+
+/* The libexec prefix as relocated from the location of this program. */
+
+static const char *self_libexec_prefix;
+
+/* The tools prefix as relocated from the location of this program. */
+
+static const char *self_tooldir_prefix;
+
+/* The name of the machine that is being targeted. */
+
+static const char *const target_machine = DEFAULT_TARGET_MACHINE;
+
+/* The target version. */
+
+static const char *const target_version = DEFAULT_TARGET_VERSION;
+
+/* The collection of target specific path prefixes. */
+
+static struct path_prefix target_path;
+
+/* The collection path prefixes. */
+
+static struct path_prefix path;
+
+/* The directory separator. */
+
static const char dir_separator[] = { DIR_SEPARATOR, 0 };
+static void
+setup_prefixes (const char *exec_path)
+{
+ const char *self;
+
+ self = getenv (GCC_EXEC_PREFIX);
+ if (!self)
+self = exec_path;
+ else
+self = concat (self, gcc- PERSONALITY, NULL);
+
+ /* Relocate the exec prefix. */
+ self_exec_prefix = make_relative_prefix (self,
+ standard_bin_prefix,
+ standard_exec_prefix);
+ if (self_exec_prefix == NULL)
+self_exec_prefix = standard_exec_prefix;
+
+ /* Relocate libexec prefix. */
+ self_libexec_prefix = make_relative_prefix (self,
+ standard_bin_prefix,
+ standard_libexec_prefix);
+ if (self_libexec_prefix == NULL)
+self_libexec_prefix = standard_libexec_prefix;
+
+
+ /* Build the relative path to the target-specific tool directory. */
+ self_tooldir_prefix = concat (tooldir_base_prefix, target_machine,
+ dir_separator, NULL);
+ self_tooldir_prefix = concat (self_exec_prefix, target_machine,
+ dir_separator
[PATCH] Correct handling of gcc-[ar|nm|ranlib] exit codes
Hi All,
The gcc-[ar|nm|ranlib] LTO utils use 'pex_one' to spawn the wrapped binutils
program. However, currently it is blindly returning the value of the 'err'
parameter for the exit code. According the documentation [1] 'err' is only
set for an error return and 'status' is only set for a successful return.
This patch fixes the bug by appropriately checking the returned status
and extracting the exit code when needed. Tested on GNU/Linux and Windows.
OK?
2012-09-27 Meador Inge mead...@codesourcery.com
* gcc-ar.c (main): Handle the returning of the sub-process error
code correctly.
[1] http://gcc.gnu.org/onlinedocs/libiberty/Functions.html#Functions
Index: gcc/gcc-ar.c
===
--- gcc/gcc-ar.c(revision 191792)
+++ gcc/gcc-ar.c(working copy)
@@ -42,6 +42,7 @@
const char *err_msg;
const char **nargv;
bool is_ar = !strcmp (PERSONALITY, ar);
+ int exit_code = FATAL_EXIT_CODE;
exe_name = PERSONALITY;
#ifdef CROSS_DIRECTORY_STRUCTURE
@@ -96,6 +97,20 @@
NULL,NULL, status, err);
if (err_msg)
fprintf(stderr, Error running %s: %s\n, exe_name, err_msg);
+ else if (status)
+{
+ if (WIFSIGNALED (status))
+ {
+ int sig = WTERMSIG (status);
+ fprintf (stderr, %s terminated with signal %d [%s]%s\n,
+ exe_name, sig, strsignal(sig),
+ WCOREDUMP(status) ? , core dumped : );
+ }
+ else if (WIFEXITED (status))
+ exit_code = WEXITSTATUS (status);
+}
+ else
+exit_code = SUCCESS_EXIT_CODE;
- return err;
+ return exit_code;
}
[PATCH] Add myself to write-after-approval section of MAINTAINERS file
Subject says it all ... 2012-06-21 Meador Inge mead...@codesourcery.com * MAINTAINERS (Write After Approval): Add myself. Index: MAINTAINERS === --- MAINTAINERS (revision 188858) +++ MAINTAINERS (working copy) @@ -392,6 +392,7 @@ Andrew John Hughes gnu_and...@member.fsf.org Andy Hutchinsonhutchinsona...@aim.com Naveen H.S navee...@kpitcummins.com +Meador Ingemead...@codesourcery.com Bernardo Innocenti ber...@develer.com Balaji V. Iyer bvi...@gmail.com Daniel Jacobowitz d...@false.org
[PATCH] PR c/53702: Fix -Wunused-local-typedefs with nested functions
Hi,
A few weeks ago I submitted a fix for a garbage collection issue I ran
into involving -Wunused-local-typedefs [1]. The analysis for that patch
still stands, but unfortunately the patch is wrong.
The problem is that the allocation reuse can't be removed otherwise the
information about local typedefs for a parent function is lost after
a nested function is parsed. I obviously missed that distinction the
first time.
This patch restores the previous behavior and just clears the 'x_cur_stmt_list'
field to avoid the GC issue. The patch was tested by building mips-linux-gnu
(to verify that the GC crash that I originally encountered is still fixed) and
by bootstrapping and running the full test suite for i686-pc-linux-gnu.
OK?
P.S. If it is OK, then can someone commit for me (I don't have write access)?
[1] http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01936.html
gcc/
2012-06-20 Meador Inge mead...@codesourcery.com
PR c/53702
* c-decl.c (c_push_function_context): Restore the behavior to reuse
the language function allocated for -Wunused-local-typedefs.
(c_pop_function_context): If necessary, clear the language function
created in c_push_function_context. Always clear out the
x_cur_stmt_list field of the restored language function.
gcc/testsuite/
2012-06-20 Meador Inge mead...@codesourcery.com
PR c/53702
* gcc.dg/Wunused-local-typedefs.c: New testcase.
Index: gcc/testsuite/gcc.dg/Wunused-local-typedefs.c
===
--- gcc/testsuite/gcc.dg/Wunused-local-typedefs.c (revision 0)
+++ gcc/testsuite/gcc.dg/Wunused-local-typedefs.c (revision 0)
@@ -0,0 +1,36 @@
+/* Origin PR c/53702
+{ dg-options -Wunused-local-typedefs }
+{ dg-do compile }
+*/
+
+/* Only test nested functions for C. More tests that work for C and C++
+ can be found in c-c++-common.
+*/
+
+void
+test0 ()
+{
+ typedef int foo; /* { dg-warning locally defined but not used } */
+ void f ()
+ {
+ }
+}
+
+void
+test1 ()
+{
+ void f ()
+ {
+typedef int foo; /* { dg-warning locally defined but not used } */
+ }
+}
+
+
+void
+test2 ()
+{
+ void f ()
+ {
+ }
+ typedef int foo; /* { dg-warning locally defined but not used } */
+}
Index: gcc/c-decl.c
===
--- gcc/c-decl.c(revision 188841)
+++ gcc/c-decl.c(working copy)
@@ -8579,9 +8579,11 @@ check_for_loop_decls (location_t loc, bo
void
c_push_function_context (void)
{
- struct language_function *p;
- p = ggc_alloc_language_function ();
- cfun-language = p;
+ struct language_function *p = cfun-language;
+ /* cfun-language might have been already allocated by the use of
+ -Wunused-local-typedefs. In that case, just re-use it. */
+ if (p == NULL)
+cfun-language = p = ggc_alloc_cleared_language_function ();
p-base.x_stmt_tree = c_stmt_tree;
c_stmt_tree.x_cur_stmt_list
@@ -8607,7 +8609,12 @@ c_pop_function_context (void)
pop_function_context ();
p = cfun-language;
- cfun-language = NULL;
+
+ /* When -Wunused-local-typedefs is in effect, cfun-languages is
+ used to store data throughout the life time of the current cfun,
+ So don't deallocate it. */
+ if (!warn_unused_local_typedefs)
+cfun-language = NULL;
if (DECL_STRUCT_FUNCTION (current_function_decl) == 0
DECL_SAVED_TREE (current_function_decl) == NULL_TREE)
@@ -8620,6 +8627,7 @@ c_pop_function_context (void)
}
c_stmt_tree = p-base.x_stmt_tree;
+ p-base.x_stmt_tree.x_cur_stmt_list = NULL;
c_break_label = p-x_break_label;
c_cont_label = p-x_cont_label;
c_switch_stack = p-x_switch_stack;
Re: PATCH: Always create a new language function for nested functions
On 06/17/2012 09:28 AM, Markus Trippelsdorf wrote: On 2012.05.29 at 19:07 +, Joseph S. Myers wrote: On Tue, 29 May 2012, Meador Inge wrote: 2012-05-29 Meador Inge mead...@codesourcery.com * c-decl.c (c_push_function_context): Always create a new language function. (c_pop_function_context): Clear the language function created in c_push_function_context. Thanks, committed. This patch caused http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53702 Thanks. I am looking into it. -- Meador Inge CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software
PATCH: Always create a new language function for nested functions
Hi All,
Last week I went to build a mips-gnu-linux toolchain and the built compiler
seg faulted while building glibc. Bisecting the change pointed to r187757. The
problem really goes back to r178692, which added support for
-Wunused-local-typedefs. r187757 just made it easier to hit by enabling
the warning more aggressively.
The problem is that in r187757 the following changes were applied:
@@ -8455,9 +8479,11 @@
void
c_push_function_context (void)
{
- struct language_function *p;
- p = ggc_alloc_language_function ();
- cfun-language = p;
+ struct language_function *p = cfun-language;
+ /* cfun-language might have been already allocated by the use of
+ -Wunused-local-typedefs. In that case, just re-use it. */
+ if (p == NULL)
+cfun-language = p = ggc_alloc_cleared_language_function ();
p-base.x_stmt_tree = c_stmt_tree;
c_stmt_tree.x_cur_stmt_list
@@ -8483,7 +8509,11 @@
pop_function_context ();
p = cfun-language;
- cfun-language = NULL;
+ /* When -Wunused-local-typedefs is in effect, cfun-languages is
+ used to store data throughout the life time of the current cfun,
+ So don't deallocate it. */
+ if (!warn_unused_local_typedefs)
+cfun-language = NULL;
This causes problems with nested functions because the following scenario
might happen (and did happen in the cause of building glibc for MIPS):
1. A nested function is found while compiling with -Wunused-local-typedefs.
2. c_push_function_context reuses the outer functions cfun-language
instance.
3. c_push_function_context saves a reference to the current functions
statement tree:
p-base.x_stmt_tree = c_stmt_tree;
4. c_pop_function_context is executed after processing the nested function.
Note the c_stmt_tree value is still saved per step (3).
5. The outer function continues to be parsed and upon encountering more
statements the statement tree is resized. This puts the original
statement tree memory back in the free pool. Therefore
cfun-language-base.x_stmt_tree is pointing to free memory.
6. The memory that was previously associated with the statement tree gets
allocated to something else and written.
7. finish_function is called for the outer function and the garbage collector
is invoked. The garbage collector crashes trying to walk the memory
associated with the x_stmt_tree field, which is now owned by something
else.
The attached patch fixes the problem by always allocating a new language
function when going into a new function context (it reverts back to the
original code). I suppose another option would be to clear all the saved
fields in c_pop_function_context, but that seems like more trouble than
it is worth.
I wasn't able to devise a simplified reproduction case for this problem. I
could only reproduce it by building glibc. The patch was tested by building
mips-linux-gnu and bootstrapping and running the full test suite for
i686-pc-linux-gnu.
OK?
P.S. If it is OK, then can someone commit for me (I don't have write access)?
2012-05-29 Meador Inge mead...@codesourcery.com
* c-decl.c (c_push_function_context): Always create a new language
function.
(c_pop_function_context): Clear the language function created in
c_push_function_context.
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
Index: gcc/c-decl.c
===
--- gcc/c-decl.c (revision 187923)
+++ gcc/c-decl.c (working copy)
@@ -8579,11 +8579,9 @@ check_for_loop_decls (location_t loc, bo
void
c_push_function_context (void)
{
- struct language_function *p = cfun-language;
- /* cfun-language might have been already allocated by the use of
- -Wunused-local-typedefs. In that case, just re-use it. */
- if (p == NULL)
-cfun-language = p = ggc_alloc_cleared_language_function ();
+ struct language_function *p;
+ p = ggc_alloc_language_function ();
+ cfun-language = p;
p-base.x_stmt_tree = c_stmt_tree;
c_stmt_tree.x_cur_stmt_list
@@ -8609,11 +8607,7 @@ c_pop_function_context (void)
pop_function_context ();
p = cfun-language;
- /* When -Wunused-local-typedefs is in effect, cfun-languages is
- used to store data throughout the life time of the current cfun,
- So don't deallocate it. */
- if (!warn_unused_local_typedefs)
-cfun-language = NULL;
+ cfun-language = NULL;
if (DECL_STRUCT_FUNCTION (current_function_decl) == 0
DECL_SAVED_TREE (current_function_decl) == NULL_TREE)
Re: [PATCH] PR rtl-optimization/53352
On 05/18/2012 09:16 AM, H.J. Lu wrote: On Thu, May 17, 2012 at 1:46 PM, Meador Inge mead...@codesourcery.com wrote: On 05/17/2012 03:02 PM, Richard Sandiford wrote: After agonising over this for a couple of days, I think it's probably the correct fix. What we're doing now would be valid if the only use of equiv_constant(x) were to substitute for x. The name and current use of the function obviously require equality though. Patch is OK, thanks. It might be worth extending fold_rtx and equiv_constant to set a flag that says whether the returned value is equivalent or simply one of many valid replacement values. We'd then be able to replace uses of registers like 142 with 0, while not replacing uses of 0 with 142. I don't know how much it would buy us though. That kind of thing is probably more of a job for fwprop. Thanks for the review. Please add UL to the hex constants in the testcase. Not sure whether it matters for 16-bit int targets or not, but better safe than sorry :-) Fixed. Also, rather than: + /* Otherwise see if we already have a constant for the inner REG. + Don't bother with paradoxical subregs because we have no way + of knowing what the upper bytes are. */ how about: /* Otherwise see if we already have a constant for the inner REG, and if that is enough to calculate an equivalent constant for the subreg. Note that the upper bits of paradoxical subregs are undefined, so they cannot be said to equal anything. */ Sounds good to me. v2 OK? If so, would you mind committing for me? I don't have write access. The test fails on Linux/x86 and Linux/x86-64. I will look into it. Thanks. -- Meador Inge CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software
Re: [PATCH] PR rtl-optimization/53352
On 05/18/2012 09:16 AM, H.J. Lu wrote: On Thu, May 17, 2012 at 1:46 PM, Meador Inge mead...@codesourcery.com wrote: On 05/17/2012 03:02 PM, Richard Sandiford wrote: After agonising over this for a couple of days, I think it's probably the correct fix. What we're doing now would be valid if the only use of equiv_constant(x) were to substitute for x. The name and current use of the function obviously require equality though. Patch is OK, thanks. It might be worth extending fold_rtx and equiv_constant to set a flag that says whether the returned value is equivalent or simply one of many valid replacement values. We'd then be able to replace uses of registers like 142 with 0, while not replacing uses of 0 with 142. I don't know how much it would buy us though. That kind of thing is probably more of a job for fwprop. Thanks for the review. Please add UL to the hex constants in the testcase. Not sure whether it matters for 16-bit int targets or not, but better safe than sorry :-) Fixed. Also, rather than: + /* Otherwise see if we already have a constant for the inner REG. + Don't bother with paradoxical subregs because we have no way + of knowing what the upper bytes are. */ how about: /* Otherwise see if we already have a constant for the inner REG, and if that is enough to calculate an equivalent constant for the subreg. Note that the upper bits of paradoxical subregs are undefined, so they cannot be said to equal anything. */ Sounds good to me. v2 OK? If so, would you mind committing for me? I don't have write access. The test fails on Linux/x86 and Linux/x86-64. Oh, Richard Guenther already fixed this (thanks!): http://gcc.gnu.org/viewcvs?view=revisionrevision=187654 -- Meador Inge CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software
Re: [PATCH] PR rtl-optimization/53352
On 05/17/2012 03:02 PM, Richard Sandiford wrote:
After agonising over this for a couple of days, I think it's probably
the correct fix. What we're doing now would be valid if the only use of
equiv_constant(x) were to substitute for x. The name and current use
of the function obviously require equality though.
Patch is OK, thanks. It might be worth extending fold_rtx and
equiv_constant to set a flag that says whether the returned value
is equivalent or simply one of many valid replacement values.
We'd then be able to replace uses of registers like 142 with 0,
while not replacing uses of 0 with 142. I don't know how much it
would buy us though. That kind of thing is probably more of a job
for fwprop.
Thanks for the review.
Please add UL to the hex constants in the testcase. Not sure whether
it matters for 16-bit int targets or not, but better safe than sorry :-)
Fixed.
Also, rather than:
+ /* Otherwise see if we already have a constant for the inner REG.
+ Don't bother with paradoxical subregs because we have no way
+ of knowing what the upper bytes are. */
how about:
/* Otherwise see if we already have a constant for the inner REG,
and if that is enough to calculate an equivalent constant for
the subreg. Note that the upper bits of paradoxical subregs
are undefined, so they cannot be said to equal anything. */
Sounds good to me.
v2 OK? If so, would you mind committing for me? I don't have write access.
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
Index: testsuite/gcc.dg/pr53352.c
===
--- testsuite/gcc.dg/pr53352.c (revision 0)
+++ testsuite/gcc.dg/pr53352.c (revision 0)
@@ -0,0 +1,41 @@
+/* { dg-do run } */
+/* { dg-options -O1 } */
+
+#include stdlib.h
+
+typedef union
+{
+ struct
+ {
+unsigned char a;
+unsigned char b;
+unsigned char c;
+unsigned char d;
+ } parts;
+ unsigned long whole;
+} T;
+
+T *g_t;
+
+void bar (unsigned long x)
+{
+ if (x != 0)
+abort ();
+}
+
+int main ()
+{
+ T one;
+ T two;
+ T tmp1, tmp2;
+
+ one.whole = 0xFFE0E0E0UL;
+ two.whole = 0xFF00UL;
+ tmp1.parts = two.parts;
+ tmp2.parts = one.parts;
+ tmp2.parts.c = tmp1.parts.c;
+ one.parts = tmp2.parts;
+
+ g_t = one;
+ bar (0);
+}
Index: cse.c
===
--- cse.c (revision 187470)
+++ cse.c (working copy)
@@ -3786,8 +3786,12 @@ equiv_constant (rtx x)
}
}
- /* Otherwise see if we already have a constant for the inner REG. */
+ /* Otherwise see if we already have a constant for the inner REG,
+ and if that is enough to calculate an equivalent constant for
+ the subreg. Note that the upper bits of paradoxical subregs
+ are undefined, so they cannot be said to equal anything. */
if (REG_P (SUBREG_REG (x))
+ (GET_MODE_SIZE (mode) = GET_MODE_SIZE (imode))
(new_rtx = equiv_constant (SUBREG_REG (x))) != 0)
return simplify_subreg (mode, new_rtx, imode, SUBREG_BYTE (x));
Re: [PATCH] PR rtl-optimization/53352
I meant to CC the RTL optimization maintainers before ...
On 05/15/2012 02:39 PM, Meador Inge wrote:
Hi All,
As reported in PR rtl-optimization/53352 CSE currently trips up on a
paradoxical subreg case. When compiling for ARM GNU/Linux with -O3
the expanded RTL of interest looks like:
(insn 12 11 13 3 (set (reg:SI 140)
(lshiftrt:SI (reg/v:SI 135 [ tmp1 ])
(const_int 16 [0x10])))
(nil))
(insn 13 12 14 3 (set (reg:QI 141)
(subreg:QI (reg:SI 140) 0))
(nil))
(insn 14 13 15 3 (set (reg:SI 142)
(subreg:SI (reg:QI 141) 0))
(nil))
(insn 15 14 16 3 (set (reg:SI 134 [ tmp1$2 ])
(and:SI (reg:SI 142)
(const_int 255 [0xff])))
(nil))
...
(insn 29 28 30 3 (set (reg:SI 0 r0)
(const_int 0 [0]))
(nil))
after cse1 things look like:
(insn 12 11 13 2 (set (reg:SI 140)
(const_int 65280 [0xff00]))
(nil))
(insn 13 12 14 2 (set (reg:QI 141)
(subreg:QI (reg:SI 140) 0))
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
;; This is *not* equal to zero because the upper
;; two bytes are undefined.
(insn 14 13 15 2 (set (reg:SI 142)
(subreg:SI (reg:QI 141) 0))
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
(insn 15 14 16 2 (set (reg:SI 134 [ tmp1$2 ])
(reg:SI 142))
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
...
(insn 29 28 30 2 (set (reg:SI 0 r0)
(reg:SI 142))
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
I believe the REG_EQUAL note on the set involving a paradoxical subreg
is incorrect. It eventually causes 0xFF00 to be passed to the function
'foo'.
The attached patch fixes the issue by skipping the paradoxical subreg
in 'equiv_constant'. Compiler bootstrapped for i686-pc-linux-gnu and
full GCC test runs for i686-pc-linux-gnu and arm-none-linux-gnueabi (no
regressions). OK? (If this is OK, then can someone commit for me. I don't
have write access).
gcc/
2012-05-15 Meador Inge mead...@codesourcery.com
PR rtl-optimization/53352
* cse.c (equiv_constant): Ignore paradoxical subregs.
gcc/testsuite/
2012-05-15 Meador Inge mead...@codesourcery.com
PR rtl-optimization/53352
* gcc.dg/pr53352.c: New test.
pr53352.patch
Index: gcc/testsuite/gcc.dg/pr53352.c
===
--- gcc/testsuite/gcc.dg/pr53352.c(revision 0)
+++ gcc/testsuite/gcc.dg/pr53352.c(revision 0)
@@ -0,0 +1,41 @@
+/* { dg-do run } */
+/* { dg-options -O1 } */
+
+#include stdlib.h
+
+typedef union
+{
+ struct
+ {
+unsigned char a;
+unsigned char b;
+unsigned char c;
+unsigned char d;
+ } parts;
+ unsigned long whole;
+} T;
+
+T *g_t;
+
+void bar (unsigned long x)
+{
+ if (x != 0)
+abort ();
+}
+
+int main ()
+{
+ T one;
+ T two;
+ T tmp1, tmp2;
+
+ one.whole = 0xFFE0E0E0;
+ two.whole = 0xFF00;
+ tmp1.parts = two.parts;
+ tmp2.parts = one.parts;
+ tmp2.parts.c = tmp1.parts.c;
+ one.parts = tmp2.parts;
+
+ g_t = one;
+ bar (0);
+}
Index: gcc/cse.c
===
--- gcc/cse.c (revision 187470)
+++ gcc/cse.c (working copy)
@@ -3786,8 +3786,11 @@ equiv_constant (rtx x)
}
}
- /* Otherwise see if we already have a constant for the inner REG. */
+ /* Otherwise see if we already have a constant for the inner REG.
+ Don't bother with paradoxical subregs because we have no way
+ of knowing what the upper bytes are. */
if (REG_P (SUBREG_REG (x))
+(GET_MODE_SIZE (mode) = GET_MODE_SIZE (imode))
(new_rtx = equiv_constant (SUBREG_REG (x))) != 0)
return simplify_subreg (mode, new_rtx, imode, SUBREG_BYTE (x));
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
[PATCH] PR rtl-optimization/53352
Hi All,
As reported in PR rtl-optimization/53352 CSE currently trips up on a
paradoxical subreg case. When compiling for ARM GNU/Linux with -O3
the expanded RTL of interest looks like:
(insn 12 11 13 3 (set (reg:SI 140)
(lshiftrt:SI (reg/v:SI 135 [ tmp1 ])
(const_int 16 [0x10])))
(nil))
(insn 13 12 14 3 (set (reg:QI 141)
(subreg:QI (reg:SI 140) 0))
(nil))
(insn 14 13 15 3 (set (reg:SI 142)
(subreg:SI (reg:QI 141) 0))
(nil))
(insn 15 14 16 3 (set (reg:SI 134 [ tmp1$2 ])
(and:SI (reg:SI 142)
(const_int 255 [0xff])))
(nil))
...
(insn 29 28 30 3 (set (reg:SI 0 r0)
(const_int 0 [0]))
(nil))
after cse1 things look like:
(insn 12 11 13 2 (set (reg:SI 140)
(const_int 65280 [0xff00]))
(nil))
(insn 13 12 14 2 (set (reg:QI 141)
(subreg:QI (reg:SI 140) 0))
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
;; This is *not* equal to zero because the upper
;; two bytes are undefined.
(insn 14 13 15 2 (set (reg:SI 142)
(subreg:SI (reg:QI 141) 0))
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
(insn 15 14 16 2 (set (reg:SI 134 [ tmp1$2 ])
(reg:SI 142))
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
...
(insn 29 28 30 2 (set (reg:SI 0 r0)
(reg:SI 142))
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
I believe the REG_EQUAL note on the set involving a paradoxical subreg
is incorrect. It eventually causes 0xFF00 to be passed to the function
'foo'.
The attached patch fixes the issue by skipping the paradoxical subreg
in 'equiv_constant'. Compiler bootstrapped for i686-pc-linux-gnu and
full GCC test runs for i686-pc-linux-gnu and arm-none-linux-gnueabi (no
regressions). OK? (If this is OK, then can someone commit for me. I don't
have write access).
gcc/
2012-05-15 Meador Inge mead...@codesourcery.com
PR rtl-optimization/53352
* cse.c (equiv_constant): Ignore paradoxical subregs.
gcc/testsuite/
2012-05-15 Meador Inge mead...@codesourcery.com
PR rtl-optimization/53352
* gcc.dg/pr53352.c: New test.
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
Index: gcc/testsuite/gcc.dg/pr53352.c
===
--- gcc/testsuite/gcc.dg/pr53352.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr53352.c (revision 0)
@@ -0,0 +1,41 @@
+/* { dg-do run } */
+/* { dg-options -O1 } */
+
+#include stdlib.h
+
+typedef union
+{
+ struct
+ {
+unsigned char a;
+unsigned char b;
+unsigned char c;
+unsigned char d;
+ } parts;
+ unsigned long whole;
+} T;
+
+T *g_t;
+
+void bar (unsigned long x)
+{
+ if (x != 0)
+abort ();
+}
+
+int main ()
+{
+ T one;
+ T two;
+ T tmp1, tmp2;
+
+ one.whole = 0xFFE0E0E0;
+ two.whole = 0xFF00;
+ tmp1.parts = two.parts;
+ tmp2.parts = one.parts;
+ tmp2.parts.c = tmp1.parts.c;
+ one.parts = tmp2.parts;
+
+ g_t = one;
+ bar (0);
+}
Index: gcc/cse.c
===
--- gcc/cse.c (revision 187470)
+++ gcc/cse.c (working copy)
@@ -3786,8 +3786,11 @@ equiv_constant (rtx x)
}
}
- /* Otherwise see if we already have a constant for the inner REG. */
+ /* Otherwise see if we already have a constant for the inner REG.
+ Don't bother with paradoxical subregs because we have no way
+ of knowing what the upper bytes are. */
if (REG_P (SUBREG_REG (x))
+ (GET_MODE_SIZE (mode) = GET_MODE_SIZE (imode))
(new_rtx = equiv_constant (SUBREG_REG (x))) != 0)
return simplify_subreg (mode, new_rtx, imode, SUBREG_BYTE (x));
Re: [PATCH] PR c++/52672
On 03/26/2012 09:14 AM, Meador Inge wrote: Hi All, This patch fixes an ICE that occurs when attempting to fold nested INDIRECT_REF trees that have conversions in between the indirect references. For example: constexpr unsigned long b = *((ul_ptr)(*((ul_ptr)0x0))); What happens is that 'cxx_fold_indirect_ref' gets the top indirect reference, strips out all the conversions ending up with the nested indirect reference, and then asserts that the type is a pointer type, which (obviously) it isn't. This patch fixes the problem by exiting the fold for non-pointer sub-trees instead of doing the assert. 'fold_indirect_ref_1' already does things this way. Tested on x86_64 GNU/Linux. OK? Also, This fixes the problem on trunk, but I have reproduced the issue back to the 4.6 branch as well. On the 4.6 branch I think it is OK to just remove the 'gcc_assert (POINTER_TYPE_P (subtype))' assert. I tested this and saw no regressions. P.S. If it is OK can some please commit for me? I don't have write access. Hi Jason, I saw where the fix for this got committed in r185890. Thanks for applying it for me. What about the release branches? I can reproduce the ICE in 4.6 and 4.7. The patch from trunk applies to 4.7. For 4.6 I think we can just drop the assert. -- Meador Inge CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software
Re: [PATCH] rs6000: Extend TARGET_NO_LWSYNC to cover more processors
On 03/28/2012 03:59 PM, David Edelsohn wrote:
On Tue, Mar 27, 2012 at 5:21 PM, Meador Inge mead...@codesourcery.com wrote:
Hi All,
This patch fixes an issue reported by one of our customers where an
instruction
exception gets raised when using '__sync_fetch_and_add' on a PowerPC 440
processor. The instruction causing the exception is 'lwsync'. Luckily
Joseph
laid the groundwork when solving a similar issue for e500 cores [1] by
adding a
new macro ('TARGET_NO_LWSYNC') for controlling whether 'lwsync' is available
.
This patch extends the 'TARGET_NO_LWSYNC' macro to include the PowerPC 440
and 603 processors. The 440 because that is what the problem was reported
against and the 603 because problems have been reported elsewhere [4] about
that. It doesn't seem like 'lwsync' is supported on 603 processors anyway.
I
looked at the IBM [2] and Freescale [3] manuals and both use the heavyweight
implementation of 'sync' (i.e. the 'sync' bit L=0).
Meador,
Something does not make sense about this patch. Other than unique
issues with e500, lwsync should be accepted everywhere. On older
processors, the L bit is ignored and it is treated as hwsync. So I do
not understand the need for explicit TARGET_NO_LWSYNC on PPC440 or
PPC603.
Is this some sort of PPC440 errata for the specific 440 being used by
Mentor's customer?
David,
I am still working on getting the specific processor information. Thanks
for the lwsync info and review feedback. If I can't get the processor
specifics, then I will just drop the patch.
Thanks again,
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
[PATCH] rs6000: Extend TARGET_NO_LWSYNC to cover more processors
Hi All,
This patch fixes an issue reported by one of our customers where an instruction
exception gets raised when using '__sync_fetch_and_add' on a PowerPC 440
processor. The instruction causing the exception is 'lwsync'. Luckily Joseph
laid the groundwork when solving a similar issue for e500 cores [1] by adding a
new macro ('TARGET_NO_LWSYNC') for controlling whether 'lwsync' is available .
This patch extends the 'TARGET_NO_LWSYNC' macro to include the PowerPC 440
and 603 processors. The 440 because that is what the problem was reported
against and the 603 because problems have been reported elsewhere [4] about
that. It doesn't seem like 'lwsync' is supported on 603 processors anyway. I
looked at the IBM [2] and Freescale [3] manuals and both use the heavyweight
implementation of 'sync' (i.e. the 'sync' bit L=0).
FWIW, I also took a look at the Linux kernel code and 'lwsync' is only used
on 64-bit PowerPC processors and e500 processors that can support it. This
can be seen in 'arch/powerpc/include/asm/synch.h':
#if defined(__powerpc64__)
#define LWSYNC lwsync
#elif defined(CONFIG_E500)
#define LWSYNC \
START_LWSYNC_SECTION(96); \
sync; \
MAKE_LWSYNC_SECTION_ENTRY(96, __lwsync_fixup);
#else
#define LWSYNC sync
#endif
Support for the e500 processors is determined at runtime and the kernel is
dynamically patched.
Regression tested with powerpc-none-eabi.
OK?
P.S. If it is OK can some please commit for me? I don't have write access.
[1] http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01238.html
[2]
https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF7785256996006F9795/$file/603e_um.pdf
[3] http://cache.freescale.com/files/32bit/doc/ref_manual/MPC603EUM.pdf
[4] http://gcc.gnu.org/ml/gcc/2008-06/msg00449.html
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
2012-03-27 Meador Inge mead...@codesourcery.com
* config/rs6000/rs6000.h (TARGET_NO_LWSYNC): Extended to cover PPC
440 and 603 processors.
Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h (revision 185881)
+++ gcc/config/rs6000/rs6000.h (working copy)
@@ -501,8 +501,10 @@ extern int rs6000_vector_align[];
-/* E500 processors only support plain sync, not lwsync. */
-#define TARGET_NO_LWSYNC TARGET_E500
+/* Some processors only support plain sync, not lwsync. */
+#define TARGET_NO_LWSYNC (TARGET_E500 \
+ || rs6000_cpu == PROCESSOR_PPC440 \
+ || rs6000_cpu == PROCESSOR_PPC603)
/* Which machine supports the various reciprocal estimate instructions. */
#define TARGET_FRES (TARGET_HARD_FLOAT TARGET_PPC_GFXOPT \
[PATCH] PR c++/52672
Hi All,
This patch fixes an ICE that occurs when attempting to fold nested INDIRECT_REF
trees that have conversions in between the indirect references. For example:
constexpr unsigned long b = *((ul_ptr)(*((ul_ptr)0x0)));
What happens is that 'cxx_fold_indirect_ref' gets the top indirect reference,
strips out all the conversions ending up with the nested indirect reference,
and then asserts that the type is a pointer type, which (obviously) it isn't.
This patch fixes the problem by exiting the fold for non-pointer sub-trees
instead of doing the assert. 'fold_indirect_ref_1' already does things this
way.
Tested on x86_64 GNU/Linux. OK?
Also, This fixes the problem on trunk, but I have reproduced the issue back to
the 4.6 branch as well. On the 4.6 branch I think it is OK to just remove the
'gcc_assert (POINTER_TYPE_P (subtype))' assert. I tested this and saw no
regressions.
P.S. If it is OK can some please commit for me? I don't have write access.
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
cp/
2012-03-26 Meador Inge mead...@codesourcery.com
PR c++/52672
* gcc/cp/semantics.c (cxx_fold_indirect_ref): Don't attempt to fold
stripped child trees that are not pointer types.
testsuite/
2012-03-26 Meador Inge mead...@codesourcery.com
PR c++/52672
* g++.dg/cpp0x/constexpr-52672.C: New testcase.Index: gcc/testsuite/g++.dg/cpp0x/constexpr-52672.C
===
--- gcc/testsuite/g++.dg/cpp0x/constexpr-52672.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-52672.C (revision 0)
@@ -0,0 +1,8 @@
+// PR c++/52672
+// { dg-do compile }
+// { dg-options -std=c++11 }
+
+typedef unsigned long * ul_ptr;
+constexpr unsigned long a = *((ul_ptr)0x0); // { dg-error }
+constexpr unsigned long b = *((ul_ptr)(*((ul_ptr)0x0))); // { dg-error }
+constexpr unsigned long c = *((ul_ptr)*((ul_ptr)(*((ul_ptr)0x0; // { dg-error }
Index: gcc/cp/semantics.c
===
--- gcc/cp/semantics.c (revision 185750)
+++ gcc/cp/semantics.c (working copy)
@@ -7202,7 +7202,8 @@ cxx_fold_indirect_ref (location_t loc, tree type,
sub = op0;
STRIP_NOPS (sub);
subtype = TREE_TYPE (sub);
- gcc_assert (POINTER_TYPE_P (subtype));
+ if (!POINTER_TYPE_P (subtype))
+return NULL_TREE;
if (TREE_CODE (sub) == ADDR_EXPR)
{
