Re: [PATCH] Dissociate store_expr's temp from exp so that it is not marked as addressable

[Eric Botcazou]

> Yes, either way I suppose.  The following also looks dangerous to me:
>
> /* If OFFSET is making OP0 more aligned than BIGGEST_ALIGNMENT,
>record its alignment as BIGGEST_ALIGNMENT.  */
> if (MEM_P (op0) && bitpos == 0 && offset != 0
> && is_aligning_offset (offset, tem))
>   set_mem_align (op0, BIGGEST_ALIGNMENT);
>
> Maybe we can fall through most of the rest of the function if we
> canonicalized in the above way?  Eric?

Probably not, I'm afraid.  I agree that the above call to set_mem_align is 
potentially problematic if we previously allocated the temp.  Moreover, I 
think that the other temp allocation around line 9840 is problematic too.

On the other hand, we could avoid skipping set_mem_attributes entirely by 
passing the type instead of the expression.

So I'd set a flag for the first temp allocation, skip the set_mem_align call if 
it is set and pass the type instead of the expression in the final call to 
set_mem_attributes if it is set.  And I'd handle the second temp allocation 
independently and pass the type here too.

-- 
Eric Botcazou

Re: [PATCH] Dissociate store_expr's temp from exp so that it is not marked as addressable

[Richard Guenther]

On Tue, 3 Apr 2012, Eric Botcazou wrote:

> > Yes, either way I suppose.  The following also looks dangerous to me:
> >
> > /* If OFFSET is making OP0 more aligned than BIGGEST_ALIGNMENT,
> >record its alignment as BIGGEST_ALIGNMENT.  */
> > if (MEM_P (op0) && bitpos == 0 && offset != 0
> > && is_aligning_offset (offset, tem))
> >   set_mem_align (op0, BIGGEST_ALIGNMENT);
> >
> > Maybe we can fall through most of the rest of the function if we
> > canonicalized in the above way?  Eric?
> 
> Probably not, I'm afraid.  I agree that the above call to set_mem_align is 
> potentially problematic if we previously allocated the temp.  Moreover, I 
> think that the other temp allocation around line 9840 is problematic too.
> 
> On the other hand, we could avoid skipping set_mem_attributes entirely by 
> passing the type instead of the expression.
> 
> So I'd set a flag for the first temp allocation, skip the set_mem_align call 
> if 
> it is set and pass the type instead of the expression in the final call to 
> set_mem_attributes if it is set.  And I'd handle the second temp allocation 
> independently and pass the type here too.

Yeah, that sounds reasonable.

Richard.

Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere

[Eric Botcazou]

> Hmm, yeah.  Or something like
>
> Index: expr.c
> ===
> --- expr.c  (revision 186082)
> +++ expr.c  (working copy)
> @@ -4490,8 +4490,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b
>bitoffset += (tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1)
> - tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1));
>
> -  *bitstart = bitpos - bitoffset;
> -  *bitend = *bitstart + tree_low_cst (DECL_SIZE (repr), 1) - 1;
> +  *bitstart = bitpos < (HOST_WIDE_INT) bitoffset ? 0 : bitpos -
> bitoffset;
> +  *bitend = bitpos + tree_low_cst (DECL_SIZE (repr), 1) - bitoffset - 1;
>  }
>
>  /* Returns true if the MEM_REF REF refers to an object that does not
>
> which conservatively truncates the bitrange.

What do you think about allowing get_bit_range to adjust offset and bitpos?

  tem = get_inner_reference (to, &bitsize, &bitpos, &offset, &mode1,
 &unsignedp, &volatilep, true);

  if (TREE_CODE (to) == COMPONENT_REF
  && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
get_bit_range (&bitregion_start, &bitregion_end, &offset, &bitpos, to);

so as to have a really non-negative bitregion_start/bitregion_end?  It would 
assert that offset is already non-null in that case.

-- 
Eric Botcazou

Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere

[Richard Guenther]

On Tue, 3 Apr 2012, Eric Botcazou wrote:

> > Hmm, yeah.  Or something like
> >
> > Index: expr.c
> > ===
> > --- expr.c  (revision 186082)
> > +++ expr.c  (working copy)
> > @@ -4490,8 +4490,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b
> >bitoffset += (tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1)
> > - tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1));
> >
> > -  *bitstart = bitpos - bitoffset;
> > -  *bitend = *bitstart + tree_low_cst (DECL_SIZE (repr), 1) - 1;
> > +  *bitstart = bitpos < (HOST_WIDE_INT) bitoffset ? 0 : bitpos -
> > bitoffset;
> > +  *bitend = bitpos + tree_low_cst (DECL_SIZE (repr), 1) - bitoffset - 1;
> >  }
> >
> >  /* Returns true if the MEM_REF REF refers to an object that does not
> >
> > which conservatively truncates the bitrange.
> 
> What do you think about allowing get_bit_range to adjust offset and bitpos?
> 
>   tem = get_inner_reference (to, &bitsize, &bitpos, &offset, &mode1,
>&unsignedp, &volatilep, true);
> 
>   if (TREE_CODE (to) == COMPONENT_REF
> && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
>   get_bit_range (&bitregion_start, &bitregion_end, &offset, &bitpos, to);
> 
> so as to have a really non-negative bitregion_start/bitregion_end?  It would 
> assert that offset is already non-null in that case.

For the case in question offset is (D.2640_7 + -1) * 20 + 16.  I wonder
why DECL_FIELD_OFFSET of the outermost COMPONENT_REF is not added
to bitpos by get_inner_reference (that is what get_bit_range assumes ...).
The FIELD_DECL is

arg 1 
unsigned external packed bit-field nonaddressable SI file 
pack18_pkg.ads line 10 col 7
size  unit size 

align 1 offset_align 128
offset 
bit offset  
bit_field_type  
context >>

and TREE_OPERAND (to, 2) is NULL and component_ref_field_offset
returns 16.  In the alias-oracle variants we add constant field-offsets
to the bitposition part (at least that avoids the need to dissect
the constant part of the offset from the non-constant part).

So, how would you make sure this works?  Match the fact that
get_inner_reference does _not_ add DECL_FIELD_OFFSET to bitpos,
and, if DECL_FIELD_OFFSET is an INTEGER_CST simply subtract that
from offset and add it to bitpos?  I suppose that would work.

Though doing that in get_inner_reference for DECL_BIT_FIELD_TYPE
fields may make sense as well.

Richard.

Re: [PATCH] Don't ignore failures from compute_data_dependences_for_loop in build_rdg (PR tree-optimization/52835)

[Richard Guenther]

On Mon, Apr 2, 2012 at 11:53 PM, Jakub Jelinek  wrote:
> Hi!
>
> On the following testcase compute_data_dependences_for_loop
> fails, but build_rdg ignores its return value and happily goes
> on as if it didn't fail, optimizing away a call.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk/4.7?

Ok.

Thanks,
Richard.

> 2012-04-02  Jakub Jelinek  
>
>        PR tree-optimization/52835
>        * tree-data-ref.c (build_rdg): Return NULL if
>        compute_data_dependences_for_loop failed.
>
>        * gfortran.dg/pr52835.f90: New test.
>
> --- gcc/tree-data-ref.c.jj      2012-03-20 08:51:32.0 +0100
> +++ gcc/tree-data-ref.c 2012-04-02 21:30:13.783378347 +0200
> @@ -5129,20 +5129,19 @@ build_rdg (struct loop *loop,
>           VEC (data_reference_p, heap) **datarefs)
>  {
>   struct graph *rdg = NULL;
> -  VEC (gimple, heap) *stmts = VEC_alloc (gimple, heap, 10);
>
> -  compute_data_dependences_for_loop (loop, false, loop_nest, datarefs,
> -                                    dependence_relations);
> -
> -  if (known_dependences_p (*dependence_relations))
> +  if (compute_data_dependences_for_loop (loop, false, loop_nest, datarefs,
> +                                        dependence_relations)
> +      && known_dependences_p (*dependence_relations))
>     {
> +      VEC (gimple, heap) *stmts = VEC_alloc (gimple, heap, 10);
>       stmts_from_loop (loop, &stmts);
>       rdg = build_empty_rdg (VEC_length (gimple, stmts));
>       create_rdg_vertices (rdg, stmts);
>       create_rdg_edges (rdg, *dependence_relations);
> +      VEC_free (gimple, heap, stmts);
>     }
>
> -  VEC_free (gimple, heap, stmts);
>   return rdg;
>  }
>
> --- gcc/testsuite/gfortran.dg/pr52835.f90.jj    2012-04-02 21:35:42.616505464 
> +0200
> +++ gcc/testsuite/gfortran.dg/pr52835.f90       2012-04-02 21:35:08.0 
> +0200
> @@ -0,0 +1,16 @@
> +! PR tree-optimization/52835
> +! { dg-do compile }
> +! { dg-options "-O3 -fdump-tree-optimized" }
> +
> +subroutine foo (x, y, z, n)
> +  integer :: n, i
> +  real :: x(n), y(n), z(n)
> +  do i = 1, n
> +    z(i) = 0.0
> +    y(i) = 0.0
> +    call bar (y(i), z(i), x(i))
> +  end do
> +end subroutine
> +
> +! { dg-final { scan-tree-dump "bar " "optimized" } }
> +! { dg-final { cleanup-tree-dump "optimized" } }
>
>        Jakub

[RS6000] Stack tie fix.

[Alan Modra]

This patch merges the rs6000 stack_tie and frame_tie rtl, so that we
now should use a tie insn that mentions all base regs involved in
register saves and restores.  That should avoid any alias analysis
problems eg. http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01156.html.
I chose to put the regs of interest on the destination of the fake
set, rather than in the source as is currently done, because I figure
that relying on the compiler to not reorder reads is fragile.  Here's
an example of the new stack tie:

(set (mem:BLK (unspec:SI [(reg:SI 1) (reg:SI 12)] UNSPEC_TIE))
 (const_int 0))

Some notes:
- I tried putting the mem on both source and destination of the set,
  but that runs afoul of rtl dead code elimination.
- The rs6000_emit_epilogue places that called gen_frame_tie and
  gen_stack_tie both used alias set 0 mems.  I believe this was
  unnecessarily restrictive.
- CODE_FOR_stack_tie is mentioned in rs6000.c but not
  CODE_FOR_frame_tie.  Removing frame_tie fixes this sched bug too.

Bootstrapped and regression tested powerpc-linux with usual -O2
BOOT_CFLAGS and also -Os, and testcases from pr44199, pr30282, pr52828,
the url above and http://gcc.gnu.org/ml/gcc/2011-03/msg00123.html
examined for sanity.  OK to apply?

PR target/52828
* config/rs6000/rs6000.c (rs6000_emit_stack_tie): Rewrite with
tie regs on destination of set.  Delete forward declaration.
(rs6000_emit_stack_reset): Update rs6000_emit_stack_tie calls.
(rs6000_emit_prologue): Likewise.
(rs6000_emit_epilogue): Likewise.  Use in place of gen_frame_tie
and gen_stack_tie.
* config/rs6000/predicates.md (tie_operand): New.
* config/rs6000/rs6000.md (restore_stack_block): Generate new
stack tie rtl.
(restore_stack_nonlocal): Likewise.
(stack_tie): Update.
(frame_tie): Delete.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 185830)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -925,7 +925,6 @@ static const char *rs6000_invalid_within_doloop (c
 static bool rs6000_legitimate_address_p (enum machine_mode, rtx, bool);
 static bool rs6000_debug_legitimate_address_p (enum machine_mode, rtx, bool);
 static rtx rs6000_generate_compare (rtx, enum machine_mode);
-static void rs6000_emit_stack_tie (void);
 static bool spe_func_has_64bit_regs_p (void);
 static rtx gen_frame_mem_offset (enum machine_mode, rtx, int);
 static unsigned rs6000_hash_constant (rtx);
@@ -18517,12 +18516,28 @@ rs6000_aix_asm_output_dwarf_table_ref (char * fram
and the change to the stack pointer.  */
 
 static void
-rs6000_emit_stack_tie (void)
+rs6000_emit_stack_tie (rtx fp, bool hard_frame_needed)
 {
-  rtx mem = gen_frame_mem (BLKmode,
-  gen_rtx_REG (Pmode, STACK_POINTER_REGNUM));
+  rtx u;
+  rtvec p;
+  int i;
 
-  emit_insn (gen_stack_tie (mem));
+  if (REGNO (fp) == STACK_POINTER_REGNUM
+  || (hard_frame_needed
+ && REGNO (fp) == HARD_FRAME_POINTER_REGNUM))
+fp = NULL_RTX;
+
+  p = rtvec_alloc (1 + hard_frame_needed + (fp != NULL_RTX));
+
+  i = 0;
+  RTVEC_ELT (p, i++) = gen_rtx_REG (Pmode, STACK_POINTER_REGNUM);
+  if (hard_frame_needed)
+RTVEC_ELT (p, i++) = gen_rtx_REG (Pmode, HARD_FRAME_POINTER_REGNUM);
+  if (fp != NULL_RTX)
+RTVEC_ELT (p, i++) = fp;
+  u = gen_rtx_UNSPEC (Pmode, p, UNSPEC_TIE);
+
+  emit_insn (gen_stack_tie (gen_frame_mem (BLKmode, u)));
 }
 
 /* Emit the correct code for allocating stack space, as insns.
@@ -19142,7 +19157,7 @@ rs6000_emit_stack_reset (rs6000_stack_t *info,
   || (TARGET_SPE_ABI
  && info->spe_64bit_regs_used != 0
  && info->first_gp_reg_save != 32))
-rs6000_emit_stack_tie ();
+rs6000_emit_stack_tie (frame_reg_rtx, frame_pointer_needed);
   
   if (frame_reg_rtx != sp_reg_rtx)
 {
@@ -19362,7 +19377,7 @@ rs6000_emit_prologue (void)
}
   rs6000_emit_allocate_stack (info->total_size, copy_reg);
   if (frame_reg_rtx != sp_reg_rtx)
-   rs6000_emit_stack_tie ();
+   rs6000_emit_stack_tie (frame_reg_rtx, false);
 }
 
   /* Handle world saves specially here.  */
@@ -19866,7 +19881,7 @@ rs6000_emit_prologue (void)
sp_offset = info->total_size;
   rs6000_emit_allocate_stack (info->total_size, copy_reg);
   if (frame_reg_rtx != sp_reg_rtx)
-   rs6000_emit_stack_tie ();
+   rs6000_emit_stack_tie (frame_reg_rtx, false);
 }
 
   /* Set frame pointer, if needed.  */
@@ -20437,13 +20452,7 @@ rs6000_emit_epilogue (int sibcall)
   /* Prevent reordering memory accesses against stack pointer restore.  */
   else if (cfun->calls_alloca
   || offset_below_red_zone_p (-info->total_size))
-   {
- rtx mem1 = gen_rtx_MEM (BLKmode, hard_frame_pointer_rtx);
- rtx mem2 = gen_rtx_MEM (BLKmode, sp_reg_rtx);
- MEM_NOTRAP_P (mem1) = 1;
- MEM_NOTRAP_P (mem2) = 1;
-  

Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)

[Richard Guenther]

On Mon, Apr 2, 2012 at 9:41 PM, DJ Delorie  wrote:
>
> Ping 6...
>
> It's now been over EIGHT MONTHS since I posted the patch, back in
> stage 1 for 4.7.  Can someone please review and/or approve this before
> gcc 4.8's stage 1 is closed?  This is needed as a first step for ABI
> compatibility for rx-elf.

If it's required for ABI compatibility why is this an attribute and not
a target hook?

>> Ping 5...
>>
>> > Ping 4...
>> >
>> > > Ping 3?  It's been months with no feedback...
>> > >
>> > > > Ping 2 ?
>> > > >
>> > > > http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
>> > > > http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html
>> > http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00529.html
>> http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01246.html
> http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00636.html

[vms/committed]: Handle #pragma __nomember_alignment byte

[Tristan Gingold]

Hi,

this patch handles the 'byte' alignment that appears in standard VMS headers 
when a C++ compiler is used.
It also force the support of parameterless variadic functions to be compatible 
with standard VMS headers.

Committed on trunk after ia64-hp-openvms cross build.

Tristan.

2012-04-03  Tristan Gingold  

* config/vms/vms-c.c (vms_pragma_nomember_alignment): Handle
'byte' alignment.
(vms_c_common_override_options): Allow parameterless variadic
functions.

Index: gcc/config/vms/vms-c.c
===
--- gcc/config/vms/vms-c.c  (revision 186100)
+++ gcc/config/vms/vms-c.c  (working copy)
@@ -120,7 +120,9 @@
   if (arg[0] == '_' && arg[1] == '_')
 arg += 2;
 
-  if (strcmp (arg, "word") == 0)
+  if (strcmp (arg, "byte") == 0)
+maximum_field_alignment = 1 * BITS_PER_UNIT;
+  else if (strcmp (arg, "word") == 0)
 maximum_field_alignment = 2 * BITS_PER_UNIT;
   else if (strcmp (arg, "longword") == 0)
 maximum_field_alignment = 4 * BITS_PER_UNIT;
@@ -453,6 +455,9 @@
 void
 vms_c_common_override_options (void)
 {
+  /* Allow variadic functions without parameters (as declared in starlet).  */
+  flag_allow_parameterless_variadic_functions = TRUE;
+
   /* Initialize c_default_pointer_mode.  */
   switch (flag_vms_pointer_size)
 {

Re: [PATCH] Dissociate store_expr's temp from exp so that it is not marked as addressable

[Eric Botcazou]

> Yeah, that sounds reasonable.

There is a further subtlety in the second temp allocation when the expression 
doesn't use the alias set of its type.  In that case, we cannot pass the type 
to set_mem_attributes.  In fact, since assign_stack_temp_for_type already 
calls the appropriate set_mem_* routines, the best thing to do might be to 
remove the call to set_mem_attributes altogether in that case.

-- 
Eric Botcazou

[Patch]: use mmap.m4 in gcc/configure

[Tristan Gingold]

Hi,

the gcc_AC_FUNC_MMAP_BLACKLIST function in gcc/acinclude.m4 is exactly the same 
as the GCC_AC_FUNC_MMAP_BLACKLIST function in config/mmap.m4 (except the case 
of the first three letters).  This patch makes gcc/configure.ac uses 
config/mmap.m4 instead of its own version.

Also, I modified config/mmap.m4 to match *vms* instead of vms* like all other 
configuration scripts (because the official name is now openvms).

Tested by building for ia64-hp-openvms and by visual inspection of the 
generated configure (only the *vms* lines changed).

Ok for trunk ?

Tristan.

config/
2012-04-03  Tristan Gingold  

* mmap.m4: Use *vms* instead of vms*.

gcc/
2012-04-03  Tristan Gingold  

* configure.ac: Use GCC_AC_FUNC_MMAP_BLACKLIST instead
of gcc_AC_FUNC_MMAP_BLACKLIST.
* aclocal.m4: Include mmap.m4
* acinclude.m4 (gcc_AC_FUNC_MMAP_BLACKLIST): Remove.
* Makefile.in (aclocal_deps): Add mmap.m4.
* configure: Regenerate.

libitm/
2012-04-03  Tristan Gingold  

* configure: Regenerate.

diff --git a/config/mmap.m4 b/config/mmap.m4
index 39d79af..fba0d9d 100644
--- a/config/mmap.m4
+++ b/config/mmap.m4
@@ -24,7 +24,7 @@ else
# read() to the same fd.  The only system known to have a problem here
# is VMS, where text files have record structure.
case "$host_os" in
- vms* | ultrix*) 
+ *vms* | ultrix*)
 gcc_cv_func_mmap_file=no ;;
  *)
 gcc_cv_func_mmap_file=yes;;
@@ -42,7 +42,7 @@ else
# Systems known to be in this category are Windows (all variants),
# VMS, and Darwin.
case "$host_os" in
- vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
+ *vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
 gcc_cv_func_mmap_dev_zero=no ;;
  *)
 gcc_cv_func_mmap_dev_zero=yes;;
@@ -74,7 +74,7 @@ else
# above for use of /dev/zero.
# Systems known to be in this category are Windows, VMS, and SCO Unix.
case "$host_os" in
- vms* | cygwin* | pe | mingw* | sco* | udk* )
+ *vms* | cygwin* | pe | mingw* | sco* | udk* )
 gcc_cv_func_mmap_anon=no ;;
  *)
 gcc_cv_func_mmap_anon=yes;;
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index f5fa0c3..8fd8208 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1650,6 +1650,7 @@ aclocal_deps = \
$(srcdir)/../config/unwind_ipinfo.m4 \
$(srcdir)/../config/warnings.m4 \
$(srcdir)/../config/dfp.m4 \
+   $(srcdir)/../config/mmap.m4 \
$(srcdir)/acinclude.m4
 
 $(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(srcdir)/aclocal.m4
diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
index 84b828f..c24464b 100644
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -221,99 +221,6 @@ test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
 AC_SUBST(INSTALL_DATA)dnl
 ])
 
-# mmap(2) blacklisting.  Some platforms provide the mmap library routine
-# but don't support all of the features we need from it.
-AC_DEFUN([gcc_AC_FUNC_MMAP_BLACKLIST],
-[
-AC_CHECK_HEADER([sys/mman.h],
-   [gcc_header_sys_mman_h=yes], [gcc_header_sys_mman_h=no])
-AC_CHECK_FUNC([mmap], [gcc_func_mmap=yes], [gcc_func_mmap=no])
-if test "$gcc_header_sys_mman_h" != yes \
- || test "$gcc_func_mmap" != yes; then
-   gcc_cv_func_mmap_file=no
-   gcc_cv_func_mmap_dev_zero=no
-   gcc_cv_func_mmap_anon=no
-else
-   AC_CACHE_CHECK([whether read-only mmap of a plain file works], 
-  gcc_cv_func_mmap_file,
-  [# Add a system to this blacklist if 
-   # mmap(0, stat_size, PROT_READ, MAP_PRIVATE, fd, 0) doesn't return a
-   # memory area containing the same data that you'd get if you applied
-   # read() to the same fd.  The only system known to have a problem here
-   # is VMS, where text files have record structure.
-   case "$host_os" in
- vms* | ultrix*) 
-gcc_cv_func_mmap_file=no ;;
- *)
-gcc_cv_func_mmap_file=yes;;
-   esac])
-   AC_CACHE_CHECK([whether mmap from /dev/zero works],
-  gcc_cv_func_mmap_dev_zero,
-  [# Add a system to this blacklist if it has mmap() but /dev/zero
-   # does not exist, or if mmapping /dev/zero does not give anonymous
-   # zeroed pages with both the following properties:
-   # 1. If you map N consecutive pages in with one call, and then
-   #unmap any subset of those pages, the pages that were not
-   #explicitly unmapped remain accessible.
-   # 2. If you map two adjacent blocks of memory and then unmap them
-   #both at once, they must both go away.
-   # Systems known to be in this category are Windows (all variants),
-   # VMS, and Darwin.
-   case "$host_os" in
- vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
-gcc_cv_func_mmap_dev_zero=no ;;
- *)
-gcc_cv_func_mmap_dev_zero=yes;;
-   esac])
-
-   # Unlike /dev/zero, the MAP_ANON(YMOUS) defines can be probed for.
-   AC_CACHE_CHECK([for MAP_ANON(YMOUS)], gcc_cv_decl_map_anon,
-[AC_COMPILE_IFELSE([AC_LANG_PROG

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Andrew Haley]

On 04/02/2012 10:06 PM, dann frazier wrote:
> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
>> On 29/03/12 20:34, dann frazier wrote:
>>> This is an updated version of a patch Debian and Ubuntu are using to
>>> use an alternate linker path for hardfloat binaries. The difference
>>> with this one is that it covers the case where no float flag
>>> was passed in, defaulting to the softfloat path.
>>>
>>> 2012-03-29  dann frazier 
>>>
>>> * config/arm/linux-elf.h: Use alternate linker path
>>>   for hardfloat ABI
>>>
>>> Index: gcc/config/arm/linux-elf.h
>>> ===
>>> --- gcc/config/arm/linux-elf.h  (revision 185708)
>>> +++ gcc/config/arm/linux-elf.h  (working copy)
>>> @@ -59,14 +59,21 @@
>>>  
>>>  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
>>>  
>>> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
>>> +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
>>> +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
>>>  
>>>  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
>>> %{static:-Bstatic} \
>>> %{shared:-shared} \
>>> %{symbolic:-Bsymbolic} \
>>> %{rdynamic:-export-dynamic} \
>>> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
>>> +   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>>> +   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>>> +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>>> +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>>> +   %{!mfloat-abi: \
>>> + %{!msoft-float: \
>>> +   %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
>>> -X \
>>> %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
>>> SUBTARGET_EXTRA_LINK_SPEC
>>>
>>
>> Looks to me as though this will break the old Linux ABI.  While we've
>> marked that as deprecated, it hasn't been removed as yet.  So I think
>> this patch either needs to wait until that removal has taken place, or
>> provide the relevant updates to maintain the old ABI support.
> 
> Thanks for your review. You're right, this does appear to break the
> old ABI - that was a misunderstanding on my part. I think this fixes
> the problem:

But what about those of us who are using hard-float but not the
Debian liker path?  It'll break, surely.  This looks to be like
it's Debian-specific.

Andrew.


> Index: gcc/config/arm/linux-elf.h
> ===
> --- gcc/config/arm/linux-elf.h(revision 185708)
> +++ gcc/config/arm/linux-elf.h(working copy)
> @@ -60,13 +60,17 @@
>  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
>  
>  #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
> +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
>  
>  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
> %{static:-Bstatic} \
> %{shared:-shared} \
> %{symbolic:-Bsymbolic} \
> %{rdynamic:-export-dynamic} \
> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
> +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
> +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
> +   %{!mfloat-abi: \
> + %{!mhard-float:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}} \
> -X \
> %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
> SUBTARGET_EXTRA_LINK_SPEC
> 

Re: [PATCH, RTL] Fix PR 51106

[Jakub Jelinek]

On Mon, Apr 02, 2012 at 06:56:25PM +0400, Andrey Belevantsev wrote:
> After Richi's RTL generation related cleanups went it, the extra
> cleanup_cfg call was added so we are no longer lucky to have the
> proper fallthru edge in this case.  The PR trail has the patch to
> purge_dead_edges making it consider this situation, but I still
> prefer the below patch that fixes only the invalid asm case.  The
> reason is that I think it unlikely that after initial RTL expansion
> (of which the instantiate virtual regs pass seems to be the part) we
> will get the problematic situation.  However, I'm happy to test the
> PR trail patch, too.

I don't like blindly changing edge into FALLTHRU, generally the edge
could be abnormal, or EH, etc. and making that fallthru is not a good idea.
I'd prefer if wherever the fallthru edge is removed the other normal edge(s)
are adjusted.

Jakub

Re: [Patch]: use mmap.m4 in gcc/configure

[Paolo Bonzini]

Il 03/04/2012 11:25, Tristan Gingold ha scritto:
> Hi,
> 
> the gcc_AC_FUNC_MMAP_BLACKLIST function in gcc/acinclude.m4 is exactly the 
> same as the GCC_AC_FUNC_MMAP_BLACKLIST function in config/mmap.m4 (except the 
> case of the first three letters).  This patch makes gcc/configure.ac uses 
> config/mmap.m4 instead of its own version.
> 
> Also, I modified config/mmap.m4 to match *vms* instead of vms* like all other 
> configuration scripts (because the official name is now openvms).
> 
> Tested by building for ia64-hp-openvms and by visual inspection of the 
> generated configure (only the *vms* lines changed).
> 
> Ok for trunk ?
> 
> Tristan.
> 
> config/
> 2012-04-03  Tristan Gingold  
> 
>   * mmap.m4: Use *vms* instead of vms*.
> 
> gcc/
> 2012-04-03  Tristan Gingold  
> 
>   * configure.ac: Use GCC_AC_FUNC_MMAP_BLACKLIST instead
>   of gcc_AC_FUNC_MMAP_BLACKLIST.
>   * aclocal.m4: Include mmap.m4

aclocal.m4 is supposed to be automatically generated, can you check that
nothing strange happens if you configure with --enable-maintainer-mode
and do "touch acinclude.m4 && make aclocal.m4" in the GCC directory?

>   * acinclude.m4 (gcc_AC_FUNC_MMAP_BLACKLIST): Remove.
>   * Makefile.in (aclocal_deps): Add mmap.m4.
>   * configure: Regenerate.
> 
> libitm/
> 2012-04-03  Tristan Gingold  
> 
>   * configure: Regenerate.

Ok.

Paolo

Re: [Patch]: use mmap.m4 in gcc/configure

[Tristan Gingold]

On Apr 3, 2012, at 12:09 PM, Paolo Bonzini wrote:

> Il 03/04/2012 11:25, Tristan Gingold ha scritto:
>> Hi,
>> 
>> the gcc_AC_FUNC_MMAP_BLACKLIST function in gcc/acinclude.m4 is exactly the 
>> same as the GCC_AC_FUNC_MMAP_BLACKLIST function in config/mmap.m4 (except 
>> the case of the first three letters).  This patch makes gcc/configure.ac 
>> uses config/mmap.m4 instead of its own version.
>> 
>> Also, I modified config/mmap.m4 to match *vms* instead of vms* like all 
>> other configuration scripts (because the official name is now openvms).
>> 
>> Tested by building for ia64-hp-openvms and by visual inspection of the 
>> generated configure (only the *vms* lines changed).
>> 
>> Ok for trunk ?
>> 
>> Tristan.
>> 
>> config/
>> 2012-04-03  Tristan Gingold  
>> 
>>  * mmap.m4: Use *vms* instead of vms*.
>> 
>> gcc/
>> 2012-04-03  Tristan Gingold  
>> 
>>  * configure.ac: Use GCC_AC_FUNC_MMAP_BLACKLIST instead
>>  of gcc_AC_FUNC_MMAP_BLACKLIST.
>>  * aclocal.m4: Include mmap.m4
> 
> aclocal.m4 is supposed to be automatically generated, can you check that
> nothing strange happens if you configure with --enable-maintainer-mode
> and do "touch acinclude.m4 && make aclocal.m4" in the GCC directory?

Ah thanks.  I missed the fact that aclocal was able to automagically find which 
files to include.

'touch $srcdir/acinclude.m4 && make $srcdir/aclocal.m4' doesn't change anything.

> 
>>  * acinclude.m4 (gcc_AC_FUNC_MMAP_BLACKLIST): Remove.
>>  * Makefile.in (aclocal_deps): Add mmap.m4.
>>  * configure: Regenerate.
>> 
>> libitm/
>> 2012-04-03  Tristan Gingold  
>> 
>>  * configure: Regenerate.
> 
> Ok.

Thanks,

Tristan.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Earnshaw]

On 03/04/12 10:29, Andrew Haley wrote:
> On 04/02/2012 10:06 PM, dann frazier wrote:
>> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
>>> On 29/03/12 20:34, dann frazier wrote:
 This is an updated version of a patch Debian and Ubuntu are using to
 use an alternate linker path for hardfloat binaries. The difference
 with this one is that it covers the case where no float flag
 was passed in, defaulting to the softfloat path.

 2012-03-29  dann frazier 

* config/arm/linux-elf.h: Use alternate linker path
   for hardfloat ABI

 Index: gcc/config/arm/linux-elf.h
 ===
 --- gcc/config/arm/linux-elf.h (revision 185708)
 +++ gcc/config/arm/linux-elf.h (working copy)
 @@ -59,14 +59,21 @@
  
  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
  
 -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
 +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
 +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
  
  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
 %{static:-Bstatic} \
 %{shared:-shared} \
 %{symbolic:-Bsymbolic} \
 %{rdynamic:-export-dynamic} \
 -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
 +   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
 +   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
 +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
 +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
 +   %{!mfloat-abi: \
 + %{!msoft-float: \
 +   %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
 -X \
 %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
 SUBTARGET_EXTRA_LINK_SPEC

>>>
>>> Looks to me as though this will break the old Linux ABI.  While we've
>>> marked that as deprecated, it hasn't been removed as yet.  So I think
>>> this patch either needs to wait until that removal has taken place, or
>>> provide the relevant updates to maintain the old ABI support.
>>
>> Thanks for your review. You're right, this does appear to break the
>> old ABI - that was a misunderstanding on my part. I think this fixes
>> the problem:
> 
> But what about those of us who are using hard-float but not the
> Debian liker path?  It'll break, surely.  This looks to be like
> it's Debian-specific.
> 

Are you trying to tell me that some distros are using /lib/ld-linux.so.3
directly for hard-float?  Sigh, you distro guys need to start talking to
each other, rather than just going of inventing things ...

If, so then there's only one way to sort out this mess.

/lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
/lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
/lib/ld-linux.so.3 legacy symlink to one of the above.

Or something of this nature.

All this is outside of GCC's remit though and I'm not in a position to
drive any of it through.

:-( :-( :-(

R.

[PATCH] PR bootstrap/52840: libstdc++: let debug find sources for compatibility.lo

[Bernhard Reutner-Fischer]

2012-04-03  Bernhard Reutner-Fischer  

PR bootstrap/52840
* src/Makefile.am (build-debug): Do not adjust vpath dir, remove
Makefile.tmp
* src/Makefile.in: Adjust as per above.

Signed-off-by: Bernhard Reutner-Fischer 
---
 libstdc++-v3/src/Makefile.am |3 ++-
 libstdc++-v3/src/Makefile.in |3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/src/Makefile.am b/libstdc++-v3/src/Makefile.am
index 28430cf..52cf0d5 100644
--- a/libstdc++-v3/src/Makefile.am
+++ b/libstdc++-v3/src/Makefile.am
@@ -293,8 +293,9 @@ build-debug: stamp-debug
  mv Makefile Makefile.tmp; \
  sed -e 's,all-local: all-once,all-local:,' \
  -e 's,install-data-local: install-data-once,install-data-local:,' 
\
- -e 's,src/c,src/debug/c,' \
+ -e '/vpath/!s,src/c,src/debug/c,' \
  < Makefile.tmp > Makefile ; \
+ rm -f Makefile.tmp ; \
  $(MAKE) CXXFLAGS='$(DEBUG_FLAGS)' \
  toolexeclibdir=$(glibcxx_toolexeclibdir)/debug all) ;
 
diff --git a/libstdc++-v3/src/Makefile.in b/libstdc++-v3/src/Makefile.in
index 3c1facf..d211ba9 100644
--- a/libstdc++-v3/src/Makefile.in
+++ b/libstdc++-v3/src/Makefile.in
@@ -914,8 +914,9 @@ build-debug: stamp-debug
  mv Makefile Makefile.tmp; \
  sed -e 's,all-local: all-once,all-local:,' \
  -e 's,install-data-local: install-data-once,install-data-local:,' 
\
- -e 's,src/c,src/debug/c,' \
+ -e '/vpath/!s,src/c,src/debug/c,' \
  < Makefile.tmp > Makefile ; \
+ rm -f Makefile.tmp ; \
  $(MAKE) CXXFLAGS='$(DEBUG_FLAGS)' \
  toolexeclibdir=$(glibcxx_toolexeclibdir)/debug all) ;
 
-- 
1.7.9.1

Re: [PATCH, i386, Android] -mandroid support for i386 target

[Ilya Enkovich]

> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>
>>>
>>> The point is that one can build a toolchain for i686-linux-gnu that will 
>>> support both 32-bit and 64-bit multilibs.  The 32-bit multilib will be used 
>>> by default, and compilation for 64-bit user-space can be requested with 
>>> -m64 option.  Even though Android is not supported for -m64, such a 
>>> toolchain can support Android as a additional "-m32 -mandroid" multilib.  
>>> I.e., the toolchain will have three multilibs in total: "-m32" (default), 
>>> "-m64" and "-m32 -mandroid".  I386/linux64.h will be picked up for such a 
>>> toolchain, even though by default it would compile for 32-bit target.  Does 
>>> this clear up things?
>>>
>>
>> I think I see your point. And it seems to make all this work I'll also
>> have to rename i386/gnu-user.h into i386/gnu-user32.h and create
>> i386/gnu-user.h with common definitions to be included by
>> gnu-user[32|64].h. Otherwise I wont be able to use some definitions
>> (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in
>> linux64.h. Right?
>
> It's simpler that you think.  The target headers ($tm_file in config.gcc -- 
> gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which 
> serves as proxy to all those headers.  All definitions made in preceding 
> headers are available in subsequent headers.  So, given that i386/gnu-user*.h 
> precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch 
> linux*.h.
>
> Thanks,
>
> --
> Maxim Kuvyrkov
> CodeSourcery / Mentor Graphics
>


Hi,

I prepared version with common linux.h and gnu-user.h. Does it look OK?

Bootstrapped and checked on linux-x86_64.

Thanks,
Ilya
---
2012-04-03  Enkovich Ilya  

* config/i386/linux.h: Renamed to ...
* config/i386/linux32.h: ... this.

* config/i386/gnu-user.h: Renamed to ...
* config/i386/gnu-user32.h: ... this.
(CPP_SPEC): Remove.
(CC1_SPEC): Remove.
(ENDFILE_SPEC): Remove.
(GNU_USER_TARGET_LINK_SPEC): New.
(LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.

* config.gcc: Rename i386/linux.h to i386/linux32.h and
i386/gnu-user.h to i386/gnu-user32.h.

* config/i386/linux.h: New.

* config/i386/gnu-user.h: New.

* config/i386/linux64.h: Include i386/linux.h.

* config/i386/gnu-user64.h: Include i386/gnu-user.h
(CPP_SPEC): Remove.
(CC1_SPEC): Remove.
(ENDFILE_SPEC): Remove.
(GNU_USER_TARGET_LINK_SPEC): New.
(LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.


mandroid.patch
Description: Binary data

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Guenther]

On Tue, Apr 3, 2012 at 12:45 PM, Richard Earnshaw  wrote:
> On 03/04/12 10:29, Andrew Haley wrote:
>> On 04/02/2012 10:06 PM, dann frazier wrote:
>>> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
 On 29/03/12 20:34, dann frazier wrote:
> This is an updated version of a patch Debian and Ubuntu are using to
> use an alternate linker path for hardfloat binaries. The difference
> with this one is that it covers the case where no float flag
> was passed in, defaulting to the softfloat path.
>
> 2012-03-29  dann frazier 
>
>    * config/arm/linux-elf.h: Use alternate linker path
>           for hardfloat ABI
>
> Index: gcc/config/arm/linux-elf.h
> ===
> --- gcc/config/arm/linux-elf.h     (revision 185708)
> +++ gcc/config/arm/linux-elf.h     (working copy)
> @@ -59,14 +59,21 @@
>
>  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
>
> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
> +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
> +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
>
>  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
>     %{static:-Bstatic} \
>     %{shared:-shared} \
>     %{symbolic:-Bsymbolic} \
>     %{rdynamic:-export-dynamic} \
> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
> +   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
> +   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
> +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
> +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
> +   %{!mfloat-abi: \
> +     %{!msoft-float: \
> +       %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
>     -X \
>     %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
>     SUBTARGET_EXTRA_LINK_SPEC
>

 Looks to me as though this will break the old Linux ABI.  While we've
 marked that as deprecated, it hasn't been removed as yet.  So I think
 this patch either needs to wait until that removal has taken place, or
 provide the relevant updates to maintain the old ABI support.
>>>
>>> Thanks for your review. You're right, this does appear to break the
>>> old ABI - that was a misunderstanding on my part. I think this fixes
>>> the problem:
>>
>> But what about those of us who are using hard-float but not the
>> Debian liker path?  It'll break, surely.  This looks to be like
>> it's Debian-specific.
>>
>
> Are you trying to tell me that some distros are using /lib/ld-linux.so.3
> directly for hard-float?  Sigh, you distro guys need to start talking to
> each other, rather than just going of inventing things ...
>
> If, so then there's only one way to sort out this mess.
>
> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
> /lib/ld-linux.so.3 legacy symlink to one of the above.
>
> Or something of this nature.
>
> All this is outside of GCC's remit though and I'm not in a position to
> drive any of it through.
>
> :-( :-( :-(

Now, I wonder why the dynamic linker cannot figure out the ABI itself
by means of using ELF flags or so?

Richard.

> R.
>
>

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Earnshaw]

On 03/04/12 11:51, Richard Guenther wrote:
> On Tue, Apr 3, 2012 at 12:45 PM, Richard Earnshaw  wrote:
>> On 03/04/12 10:29, Andrew Haley wrote:
>>> On 04/02/2012 10:06 PM, dann frazier wrote:
 On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
> On 29/03/12 20:34, dann frazier wrote:
>> This is an updated version of a patch Debian and Ubuntu are using to
>> use an alternate linker path for hardfloat binaries. The difference
>> with this one is that it covers the case where no float flag
>> was passed in, defaulting to the softfloat path.
>>
>> 2012-03-29  dann frazier 
>>
>>* config/arm/linux-elf.h: Use alternate linker path
>>   for hardfloat ABI
>>
>> Index: gcc/config/arm/linux-elf.h
>> ===
>> --- gcc/config/arm/linux-elf.h (revision 185708)
>> +++ gcc/config/arm/linux-elf.h (working copy)
>> @@ -59,14 +59,21 @@
>>
>>  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
>>
>> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
>> +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
>> +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
>>
>>  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
>> %{static:-Bstatic} \
>> %{shared:-shared} \
>> %{symbolic:-Bsymbolic} \
>> %{rdynamic:-export-dynamic} \
>> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
>> +   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>> +   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>> +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>> +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>> +   %{!mfloat-abi: \
>> + %{!msoft-float: \
>> +   %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
>> -X \
>> %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
>> SUBTARGET_EXTRA_LINK_SPEC
>>
>
> Looks to me as though this will break the old Linux ABI.  While we've
> marked that as deprecated, it hasn't been removed as yet.  So I think
> this patch either needs to wait until that removal has taken place, or
> provide the relevant updates to maintain the old ABI support.

 Thanks for your review. You're right, this does appear to break the
 old ABI - that was a misunderstanding on my part. I think this fixes
 the problem:
>>>
>>> But what about those of us who are using hard-float but not the
>>> Debian liker path?  It'll break, surely.  This looks to be like
>>> it's Debian-specific.
>>>
>>
>> Are you trying to tell me that some distros are using /lib/ld-linux.so.3
>> directly for hard-float?  Sigh, you distro guys need to start talking to
>> each other, rather than just going of inventing things ...
>>
>> If, so then there's only one way to sort out this mess.
>>
>> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
>> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
>> /lib/ld-linux.so.3 legacy symlink to one of the above.
>>
>> Or something of this nature.
>>
>> All this is outside of GCC's remit though and I'm not in a position to
>> drive any of it through.
>>
>> :-( :-( :-(
> 
> Now, I wonder why the dynamic linker cannot figure out the ABI itself
> by means of using ELF flags or so?
> 

There are no ELF flags for this in executables.  The attributes only
apply to object files and anyway they are too expensive to decode at run
time.

R.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jakub Jelinek]

On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
> If, so then there's only one way to sort out this mess.
> 
> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader

The above scheme is a Debianism which no other distro is using.

Jakub

Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere

[Eric Botcazou]

> For the case in question offset is (D.2640_7 + -1) * 20 + 16.  I wonder
> why DECL_FIELD_OFFSET of the outermost COMPONENT_REF is not added
> to bitpos by get_inner_reference (that is what get_bit_range assumes ...).

DECL_FIELD_OFFSET is added to offset and DECL_FIELD_BIT_OFFSET to bitpos.

> So, how would you make sure this works?  Match the fact that
> get_inner_reference does _not_ add DECL_FIELD_OFFSET to bitpos,
> and, if DECL_FIELD_OFFSET is an INTEGER_CST simply subtract that
> from offset and add it to bitpos?  I suppose that would work.

Yes, but the amount is simply the negative bitstart (which is a multiple of 
BITS_PER_UNIT).  This is the same kind of adjustment now done at the end of 
get_inner_reference to avoid negative bit positions there too.

> Though doing that in get_inner_reference for DECL_BIT_FIELD_TYPE
> fields may make sense as well.

That would be more complicated, as we would need to split the offset into
variable and fixed part.


Tentative patch attached, regtested for Ada on x86 and x86-64.  I'll do a full 
testing cycle if it is approved.


* expr.c (get_bit_range): Add OFFSET parameter and adjust BITPOS.
Change type of BITOFFSET to signed.  Make sure the lower bound of
the computed range is non-negative by adjusting OFFSET and BITPOS.
(expand_assignment): Adjust call to get_bit_range.


-- 
Eric Botcazou
Index: expr.c
===
--- expr.c	(revision 186054)
+++ expr.c	(working copy)
@@ -4431,19 +4431,22 @@ optimize_bitfield_assignment_op (unsigne
 /* In the C++ memory model, consecutive bit fields in a structure are
considered one memory location.
 
-   Given a COMPONENT_REF EXP at bit position BITPOS, this function
+   Given a COMPONENT_REF EXP at position (OFFSET, BITPOS), this function
returns the bit range of consecutive bits in which this COMPONENT_REF
-   belongs in.  The values are returned in *BITSTART and *BITEND.
+   belongs in.  The values are returned in *BITSTART and *BITEND.  Both
+   OFFSET and BITPOS may be adjusted in the process.
+
If the access does not need to be restricted 0 is returned in
*BITSTART and *BITEND.  */
 
 static void
 get_bit_range (unsigned HOST_WIDE_INT *bitstart,
 	   unsigned HOST_WIDE_INT *bitend,
-	   tree exp,
-	   HOST_WIDE_INT bitpos)
+	   tree *offset,
+	   HOST_WIDE_INT *bitpos,
+	   tree exp)
 {
-  unsigned HOST_WIDE_INT bitoffset;
+  HOST_WIDE_INT bitoffset;
   tree field, repr;
 
   gcc_assert (TREE_CODE (exp) == COMPONENT_REF);
@@ -4490,7 +4493,25 @@ get_bit_range (unsigned HOST_WIDE_INT *b
   bitoffset += (tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1)
 		- tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1));
 
-  *bitstart = bitpos - bitoffset;
+  /* If the adjustment is larger than bitpos, we would have a negative bit
+ position for the lower bound and this may wreak havoc later.  This can
+ occur only if we have a non-null offset, so adjust offset and bitpos
+ to make the lower bound non-negative.  */
+  if (bitoffset > *bitpos)
+{
+  HOST_WIDE_INT adjust = bitoffset - *bitpos;
+
+  gcc_assert ((adjust % BITS_PER_UNIT) == 0);
+  gcc_assert (*offset != NULL_TREE);
+
+  *bitpos += adjust;
+  *offset
+	= size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
+  *bitstart = 0;
+}
+  else
+*bitstart = *bitpos - bitoffset;
+
   *bitend = *bitstart + tree_low_cst (DECL_SIZE (repr), 1) - 1;
 }
 
@@ -4595,7 +4616,7 @@ expand_assignment (tree to, tree from, b
 
   if (TREE_CODE (to) == COMPONENT_REF
 	  && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
-	get_bit_range (&bitregion_start, &bitregion_end, to, bitpos);
+	get_bit_range (&bitregion_start, &bitregion_end, &offset, &bitpos, to);
 
   /* If we are going to use store_bit_field and extract_bit_field,
 	 make sure to_rtx will be safe for multiple use.  */

[PATCH] Fix PR52808

[Richard Guenther]

The following patch fixes PR52808 - the issue is as in the
duplicate_block fixme comment - if we are destroying a loop
by means of adding another entry we have to do that.  Thus
tracer needs to cleanup the cfg after it finished (a good idea
anyway).  And jump threading needs to tell cfg manipulation it
behaves well when threading a loop latch edge.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2012-04-03  Richard Guenther  

PR tree-optimization/52808
* tracer.c (tail_duplicate): Return whether we have duplicated
any block.
(tracer): If we have duplicated any block, cleanup the CFG.
* cfghooks.c (duplicate_block): If we duplicated a loop
header but not its loop, destroy the loop because it now has
multiple entries.
* tree-ssa-threadupdate.c (thread_through_loop_header): Tell
the cfg manipulation routines we are not creating a multiple
entry loop.

* gcc.dg/pr52808.c: New testcase.

Index: gcc/tracer.c
===
--- gcc/tracer.c(revision 186066)
+++ gcc/tracer.c(working copy)
@@ -59,7 +59,6 @@ static bool better_p (const_edge, const_
 static edge find_best_successor (basic_block);
 static edge find_best_predecessor (basic_block);
 static int find_trace (basic_block, basic_block *);
-static void tail_duplicate (void);
 
 /* Minimal outgoing edge probability considered for superblock formation.  */
 static int probability_cutoff;
@@ -224,7 +223,7 @@ find_trace (basic_block bb, basic_block
 /* Look for basic blocks in frequency order, construct traces and tail 
duplicate
if profitable.  */
 
-static void
+static bool
 tail_duplicate (void)
 {
   fibnode_t *blocks = XCNEWVEC (fibnode_t, last_basic_block);
@@ -236,6 +235,7 @@ tail_duplicate (void)
   gcov_type cover_insns;
   int max_dup_insns;
   basic_block bb;
+  bool changed = false;
 
   /* Create an oversized sbitmap to reduce the chance that we need to
  resize it.  */
@@ -332,6 +332,7 @@ tail_duplicate (void)
 bb2->index, copy->index, copy->frequency);
 
  bb2 = copy;
+ changed = true;
}
  mark_bb_seen (bb2);
  bb = bb2;
@@ -353,6 +354,8 @@ tail_duplicate (void)
   free (trace);
   free (counts);
   fibheap_delete (heap);
+
+  return changed;
 }
 
 /* Main entry point to this file.  */
@@ -360,6 +363,8 @@ tail_duplicate (void)
 static unsigned int
 tracer (void)
 {
+  bool changed;
+
   gcc_assert (current_ir_type () == IR_GIMPLE);
 
   if (n_basic_blocks <= NUM_FIXED_BLOCKS + 1)
@@ -370,15 +375,14 @@ tracer (void)
 dump_flow_info (dump_file, dump_flags);
 
   /* Trace formation is done on the fly inside tail_duplicate */
-  tail_duplicate ();
+  changed = tail_duplicate ();
+  if (changed)
+free_dominance_info (CDI_DOMINATORS);
 
-  /* FIXME: We really only need to do this when we know tail duplication
-has altered the CFG. */
-  free_dominance_info (CDI_DOMINATORS);
   if (dump_file)
 dump_flow_info (dump_file, dump_flags);
 
-  return 0;
+  return changed ? TODO_cleanup_cfg : 0;
 }
 
 static bool
Index: gcc/cfghooks.c
===
--- gcc/cfghooks.c  (revision 186066)
+++ gcc/cfghooks.c  (working copy)
@@ -1009,18 +1009,28 @@ duplicate_block (basic_block bb, edge e,
 {
   struct loop *cloop = bb->loop_father;
   struct loop *copy = get_loop_copy (cloop);
-  add_bb_to_loop (new_bb, copy ? copy : cloop);
-  /* If we copied the loop latch block but not the loop, adjust
-loop state.
-???  If we copied the loop header block but not the loop
-we might either have created a loop copy or a loop with
-multiple entries.  In both cases we probably have to
-ditch the loops and arrange for a fixup.  */
+  /* If we copied the loop header block but not the loop
+we have created a loop with multiple entries.  Ditch the loop,
+add the new block to the outer loop and arrange for a fixup.  */
   if (!copy
- && cloop->latch == bb)
+ && cloop->header == bb)
{
+ add_bb_to_loop (new_bb, loop_outer (cloop));
+ cloop->header = NULL;
  cloop->latch = NULL;
- loops_state_set (LOOPS_MAY_HAVE_MULTIPLE_LATCHES);
+ loops_state_set (LOOPS_NEED_FIXUP);
+   }
+  else
+   {
+ add_bb_to_loop (new_bb, copy ? copy : cloop);
+ /* If we copied the loop latch block but not the loop, adjust
+loop state.  */
+ if (!copy
+ && cloop->latch == bb)
+   {
+ cloop->latch = NULL;
+ loops_state_set (LOOPS_MAY_HAVE_MULTIPLE_LATCHES);
+   }
}
 }
 
Index: gcc/testsuite/gcc.dg/pr52808.c
===
--- gcc/testsuite/gcc.dg/pr52808

Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere

[Richard Guenther]

On Tue, 3 Apr 2012, Eric Botcazou wrote:

> > For the case in question offset is (D.2640_7 + -1) * 20 + 16.  I wonder
> > why DECL_FIELD_OFFSET of the outermost COMPONENT_REF is not added
> > to bitpos by get_inner_reference (that is what get_bit_range assumes ...).
> 
> DECL_FIELD_OFFSET is added to offset and DECL_FIELD_BIT_OFFSET to bitpos.
> 
> > So, how would you make sure this works?  Match the fact that
> > get_inner_reference does _not_ add DECL_FIELD_OFFSET to bitpos,
> > and, if DECL_FIELD_OFFSET is an INTEGER_CST simply subtract that
> > from offset and add it to bitpos?  I suppose that would work.
> 
> Yes, but the amount is simply the negative bitstart (which is a multiple of 
> BITS_PER_UNIT).  This is the same kind of adjustment now done at the end of 
> get_inner_reference to avoid negative bit positions there too.
> 
> > Though doing that in get_inner_reference for DECL_BIT_FIELD_TYPE
> > fields may make sense as well.
> 
> That would be more complicated, as we would need to split the offset into
> variable and fixed part.
> 
> 
> Tentative patch attached, regtested for Ada on x86 and x86-64.  I'll do a 
> full 
> testing cycle if it is approved.

Yes, the patch is ok.

Thanks,
Richard.

> 
>   * expr.c (get_bit_range): Add OFFSET parameter and adjust BITPOS.
>   Change type of BITOFFSET to signed.  Make sure the lower bound of
>   the computed range is non-negative by adjusting OFFSET and BITPOS.
>   (expand_assignment): Adjust call to get_bit_range.

[Patch, Fortran] PR52729 - fix module-proc decl access for BLOCK/SELECT TYPE

[Tobias Burnus]

A rather obvious patch.

The module procedure had the FL_PROCEDURE due its use ("CALL sub" or 
"func()") - but no interface and no type. Thus, there was no attempt to 
search for the symbol in the parent namespace, which causes failures.


Build and tested on x86-84-linux.
OK for the trunk?

Tobias

PS: I lost track. Are there patches which still have to be reviewed?
2012-04-03  Tobias Burnus  

	PR fortran/52729
	* resolve.c (resolve_symbol): Fix searching for parent NS decl.

2012-04-03  Tobias Burnus  

	PR fortran/52729
	* gfortran.dg/block_11.f90: New.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index b63a0c6..910d322 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12246,7 +12277,10 @@ resolve_symbol (gfc_symbol *sym)
   symbol_attribute class_attr;
   gfc_array_spec *as;
 
-  if (sym->attr.flavor == FL_UNKNOWN)
+  if (sym->attr.flavor == FL_UNKNOWN
+  || (sym->attr.flavor == FL_PROCEDURE && !sym->attr.intrinsic
+	  && !sym->attr.generic && !sym->attr.external
+	  && sym->attr.if_source == IFSRC_UNKNOWN))
 {
 
 /* If we find that a flavorless symbol is an interface in one of the
@@ -12270,9 +12303,10 @@ resolve_symbol (gfc_symbol *sym)
 
   /* Otherwise give it a flavor according to such attributes as
 	 it has.  */
-  if (sym->attr.external == 0 && sym->attr.intrinsic == 0)
+  if (sym->attr.flavor == FL_UNKNOWN && sym->attr.external == 0
+	  && sym->attr.intrinsic == 0)
 	sym->attr.flavor = FL_VARIABLE;
-  else
+  else if (sym->attr.flavor == FL_UNKNOWN)
 	{
 	  sym->attr.flavor = FL_PROCEDURE;
 	  if (sym->attr.dimension)

--- /dev/null	2012-03-22 21:06:43.387787737 +0100
+++ gcc/gcc/testsuite/gfortran.dg/block_11.f90	2012-04-03 10:52:27.0 +0200
@@ -0,0 +1,68 @@
+! { dg-do link }
+!
+! PR fortran/52729
+!
+! Based on a contribution of Andrew Benson
+!
+module testMod
+  type testType
+  end type testType
+contains
+  subroutine testSub()
+implicit none
+procedure(double precision ), pointer :: r
+class(testType ), pointer :: testObject
+double precision  :: testVal
+
+! Failed as testFunc was BT_UNKNOWN
+select type (testObject)
+class is (testType)
+   testVal=testFunc()
+   r => testFunc
+end select
+return
+  end subroutine testSub
+
+  double precision function testFunc()
+implicit none
+return
+  end function testFunc
+end module testMod
+
+module testMod2
+  implicit none
+contains
+  subroutine testSub()
+procedure(double precision ), pointer :: r
+double precision  :: testVal
+! Failed as testFunc was BT_UNKNOWN
+block
+  r => testFunc
+  testVal=testFunc()
+end block
+  end subroutine testSub
+
+  double precision function testFunc()
+  end function testFunc
+end module testMod2
+
+module m3
+  implicit none
+contains
+  subroutine my_test()
+procedure(), pointer :: ptr
+! Before the fix, one had the link error
+! "undefined reference to `sub.1909'"
+block
+  ptr => sub
+  call sub()
+end block
+  end subroutine my_test
+  subroutine sub(a)
+integer, optional :: a
+  end subroutine sub
+end module m3
+
+end
+
+! { dg-final { cleanup-modules "testmod testmod2 m3" } }

[Patch, Fortran]: Fix libgfortran.h error for VMS

[Tristan Gingold]

Hi,

unfortunately VMS doesn't like to include complex.h after math.h, while the 
reverse is allowed.
The reason is that math.h (unless ANSI_C_SOURCE is defined but that hides many 
math functions) declares cabs/cabsf/cabsl for a structure representing a 
complex number, which is not compatible with the declarations in complex.h

The simplest path is simply to reverse the include order in libgfortran.h.  I 
know that this is somewhat VMS specific, and I welcome better ideas.

Tested by building gfortran for x86_64-darwin and ia64-hp-openvms.

Ok for trunk ?

Tristan.

libgfortran/
2012-04-03  Tristan Gingold  

* libgfortran.h: Include complex.h before math.h

diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h
index be5f133..ea20e14 100644
--- a/libgfortran/libgfortran.h
+++ b/libgfortran/libgfortran.h
@@ -42,11 +42,19 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #include "config.h"
 
 #include 
-#include 
 #include 
 #include 
 #include 
 
+#if HAVE_COMPLEX_H
+/* Must appear before math.h on VMS systems.  */
+# include 
+#else
+#define complex __complex__
+#endif
+
+#include 
+
 /* If we're support quad-precision floating-point type, include the
header to our support library.  */
 #ifdef HAVE_FLOAT128
@@ -66,12 +74,6 @@ extern long double __strtold (const char *, char **);
 #define gfc_strtold strtold
 #endif
 
-#if HAVE_COMPLEX_H
-# include 
-#else
-#define complex __complex__
-#endif
-
 #include "../gcc/fortran/libgfortran.h"
 
 #include "c99_protos.h"

Re: [google] Fix PR52822 in google's gcc-4.6 branch (issue5975063)

[Diego Novillo]

On 4/2/12 6:25 PM, Jeffrey Yasskin wrote:


2012-04-02   Jeffrey Yasskin

* libstdc++-v3/include/bits/stl_algo.h (__stable_partition_adaptive):
 Avoid move-assigning an object to itself by explicitly testing
 for identity.
* libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc:
 Test vectors, which have a destructive self-move-assignment.
* libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc 
(test02):
 Test with rvalstruct, which explicitly checks self-move-assignment.


This is OK for google/gcc-4_6, if trunk review requests changes, you can 
backport them later.



Diego.

Fw: [PATCH] Allow printing of escaped curly braces in assembler directives with operands

[Siddhesh Poyarekar]

Hi,

ping?

--
Siddhesh

Begin forwarded message:

Date: Tue, 27 Mar 2012 10:51:37 +0530
From: Siddhesh Poyarekar 
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Allow printing of escaped curly braces in assembler
directives with operands


Hi,

An assembler directive with an operand is filtered through
output_asm_insn (or asm_fprintf for gcc internal asm() directives) to
expand the operand values in the assembler as well as to choose
dialects if present. This patch is concerned primarily with the
dialects, since their syntax prevent inclusion of assembler strings
with curly braces, causing them to be interpreted as dialects.

The attached patch allows printing of curly braces in assembler by
preceding them with a \\. So to print the following code into assembler:

.pushsection ".foo"; .asciz "div { width : 50%% | height=10px }"; .long
42; .popsection

The following code needs to be used with this patch:

void f()
{
  asm ( ".pushsection \".foo\"; .asciz \"div \\{ width : 50%% |
height=10px \\} \"; .long %c0; .popsection" : : "i"(42) ); }

The other option to \\ (since it doesn't look as clean) was to use %
as an escape character, but I was not sure if that is a better looking
option or a worse looking one. I don't mind resubmitting the patch to
use %{ and %} to print curly braces if that is acceptable.

It is still possible to print curly braces in asm string literals
without operands since they do not undergo any transformation.

The patch does not introduce any regressions. I have tested this with
x86_64 and i686 and it works well with both of them.

Regards,
Siddhesh


gcc/ChangeLog:

2012-03-27  Siddhesh Poyarekar  

* final.c (output_asm_insn, asm_fprintf): Print curly braces if
preceded by an escaped backslash (\\).

testsuite/ChangeLog:

2012-03-27  Siddhesh Poyarekar  

* gcc.dg/asm-braces.c: New test case.
diff --git a/gcc/final.c b/gcc/final.c
index 718caf1..2393c0f 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -3444,6 +3444,12 @@ output_asm_insn (const char *templ, rtx *operands)
 	  output_operand_lossage ("invalid %%-code");
 	break;
 
+  /* Escaped braces. Print them as is. */
+  case '\\':
+if (*p == '{' || *p == '}')
+  c = *p++;
+/* FALLTHROUGH */
+
   default:
 	putc (c, asm_out_file);
   }
@@ -3955,6 +3961,12 @@ asm_fprintf (FILE *file, const char *p, ...)
 	  }
 	break;
 
+  /* Escaped braces. Print them as is. */
+  case '\\':
+if (*p == '{' || *p == '}')
+  c = *p++;
+/* FALLTHROUGH */
+
   default:
 	putc (c, file);
   }
diff --git a/gcc/testsuite/gcc.dg/asm-braces.c b/gcc/testsuite/gcc.dg/asm-braces.c
new file mode 100644
index 000..4f428c8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asm-braces.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+void f()
+{
+  asm ( ".pushsection \".foo\"; .asciz \"div \\{ width : 50%% | height = 10px \\} \"; .long %c0; .popsection" : : "i"(42) );
+}
+
+/* { dg-final { scan-assembler "div { width : 50%% | height = 10px }" } } */
-- 
1.7.7.6

Re: [C Patch]: pr52543

[Richard Sandiford]

Kenneth Zadeck  writes:
> +#define FORCE_LOWERING

Don't think you meant to keep this.

> -/* Return whether X is a simple object which we can take a word_mode
> -   subreg of.  */
> +static struct {
> +
> +  /* This pass can transform 4 different operations: move, ashift,
> + lshiftrt, and zero_extend.  There is a boolean vector for move
> + splitting that is indexed by mode and is true for each mode that is
> + to have its copies split.  The other three operations are only done
> + for one mode so they are only controlled by a single boolean  .*/

Comment out of date.

> +  bool move_modes_to_split[MAX_MACHINE_MODE];
> +  
> +  /* Other splitting operations to be done on the this platform.  */
> +  bool splitting_ashift[MAX_BITS_PER_WORD];
> +  bool splitting_lshiftrt[MAX_BITS_PER_WORD];
> +  bool splitting_zext;
> +
> +  bool something_to_do;
> +
> +  /* Precomputed cost values used to determine if lowering shift
> + operations is profitable.  */ 
> +  int word_mode_move_cost;
> +  int move_zero_cost;
> +} target_info;

This isn't right.  The point is that there is supposed to be one instance
of this structure per target, along the lines of target_expmed.

Yes, it's clunky.  Hopefully the move to C++ will allow a more elegant
approach.

> +/* Return true if it is profitable to lower and shift by SHIFT_AMT.
> +   CODE can be either ASHIFT or LSHIFTRT.  */
> +static bool
> +profitable_shift_p (enum rtx_code code, int shift_amt)
> +{
> +  rtx trg = gen_rtx_REG (GET_MODE_WIDER_MODE (word_mode), 
> FIRST_PSEUDO_REGISTER);
> +  rtx src = gen_rtx_REG (GET_MODE_WIDER_MODE (word_mode), 
> FIRST_PSEUDO_REGISTER + 1);
> +  int wide_cost 
> += insn_rtx_cost (gen_rtx_SET (VOIDmode, trg, 
> +   gen_rtx_fmt_ee (code, GET_MODE_WIDER_MODE 
> (word_mode), 
> +   src, GEN_INT (shift_amt))),
> +  true);

Lines still too long.  (You really need an 80-char-wide editor.
It's the future.)

More importantly, I'd not noticed last time that you're glossing
over the size/speed choice.  That's important, and in general
is made on a per-bb basis.  So I think we need to cache both
the size and speed costs.

> +#ifdef FORCE_LOWERING
> +  return true;
> +#endif
> +
> +#ifdef LOG_COSTS
> +  fprintf (stderr, "shift code %d, shift amt %d, wide_cost %d\n", 
> +code, shift_amt, wide_cost);
> +#endif
> +  if (shift_amt == BITS_PER_WORD)
> +return wide_cost 
> +  >= target_info.word_mode_move_cost + target_info.move_zero_cost;
> +  else
> +{
> +  int narrow_cost;
> +
> +  trg = gen_rtx_REG (word_mode, FIRST_PSEUDO_REGISTER);
> +  src = gen_rtx_REG (word_mode, FIRST_PSEUDO_REGISTER + 1);
> +  narrow_cost 
> + = insn_rtx_cost (gen_rtx_SET 
> +  (VOIDmode, trg, 
> +   gen_rtx_fmt_ee (code, word_mode, 
> +   src, 
> +   GEN_INT (shift_amt - BITS_PER_WORD))),
> +true);
> +
> +#ifdef LOG_COSTS
> +  fprintf (stderr, "narrow_cost %d\n", narrow_cost);
> +#endif
> +  return wide_cost > narrow_cost + target_info.move_zero_cost;

Should be ">=".

I think it'd be better to only create the rtx once and simply replace
the shift amount for each test.

> +/* Initialize pass once per execution.  This envolves determining

once per target

> +   which operations on the machine are profitable.  If none are found,
> +   then the pass just returns when called.  */
> +
> +void
> +init_lower_subreg (void)
> +{
> +  rtx trg = gen_rtx_REG (word_mode, FIRST_PSEUDO_REGISTER);
> +  rtx pat;
> +  unsigned int i;
> +  int factor;
> +
> +  memset (&target_info, 0, sizeof target_info);
> +
> +  target_info.word_mode_move_cost = compute_move_cost (word_mode);
> +  target_info.move_zero_cost 
> += insn_rtx_cost (gen_rtx_SET (VOIDmode, trg, 
> +   CONST0_RTX (word_mode)), true);
> +
> +#ifdef LOG_COSTS
> +  fprintf (stderr, "word mode move cost %d\n", 
> target_info.word_mode_move_cost);
> +  fprintf (stderr, "move 0 cost %d\n", target_info.move_zero_cost);
> +#endif
> +  for (i = 0; i < MAX_MACHINE_MODE; i++) 
> +{
> +  int t;
> +  factor = GET_MODE_SIZE (i) / UNITS_PER_WORD;
> +
> +  if (factor <= 1) 
> + continue;
> +
> +  t = compute_move_cost ((enum machine_mode) i);
> +
> +#ifdef LOG_COSTS
> +  fprintf (stderr, "mode %s, move cost %d, factor %d\n", 
> +mode_name[i], t, factor);
> +#endif
> +  if (t >= target_info.word_mode_move_cost * factor)
> + {
> +   target_info.move_modes_to_split[i] = true;
> +   target_info.something_to_do = true;
> + }
> +#ifdef FORCE_LOWERING
> +  target_info.move_modes_to_split[i] = true;
> +  target_info.something_to_do = true;
> +#endif
> +}

The code is a bit inconsistent about whether the costs are calculated
when FORCE_LOWERING is true.  He

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[dann frazier]

On Tue, Apr 03, 2012 at 03:29:06PM +1200, Michael Hope wrote:
> On 3 April 2012 09:06, dann frazier  wrote:
> > On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
> >> On 29/03/12 20:34, dann frazier wrote:
> >> > This is an updated version of a patch Debian and Ubuntu are using to
> >> > use an alternate linker path for hardfloat binaries. The difference
> >> > with this one is that it covers the case where no float flag
> >> > was passed in, defaulting to the softfloat path.
> 
> Hi Dann.  The change should be in the EABI specific linux-eabi.h
> instead of the shared/OABI linux-elf.h.  It breaks support for uClibc
> and Bionic by always using the GLIBC loader in hard float mode.  The
> final line in the spec is missing a '=hard' and always adds
> /lib/ld-linux.so.3.
> 
> How about:
> 
> 2012-04-03  Michael Hope  
> 
>* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
>(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float loader.

Nice, thanks Michael. I'd looked at doing something similar, but I
wasn't sure that defining GLIBC_DYNAMIC_LINKER to a spec macro would
work :)

 -dann
> 
> diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
> index 80bd825..8498472 100644
> --- a/gcc/config/arm/linux-eabi.h
> +++ b/gcc/config/arm/linux-eabi.h
> @@ -62,7 +62,12 @@
>  /* Use ld-linux.so.3 so that it will be possible to run "classic"
> GNU/Linux binaries on an EABI system.  */
>  #undef  GLIBC_DYNAMIC_LINKER
> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT
> "/lib/arm-linux-gnueabihf/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER \
> +   "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +%{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"
> 
>  /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
> use the GNU/Linux version, not the generic BPABI version.  */
> 
> 
> which works for the following test cases:
>  gcc -mhard-float foo.c => /lib/arm-linux-gnueabihf/ld-linux.so.3
>  gcc -mfloat-abi=hard foo.c => /lib/arm-linux-gnueabihf/ld-linux.so.3
>  gcc -msoft-float foo.c => /lib/ld-linux.so.3
>  gcc -mfloat-abi=softfp foo.c => /lib/ld-linux.so.3
>  gcc -mbionic => /system/bin/linker
>  gcc -mbionic -mhard-float => /system/bin/linker
>  gcc -muclibc => /lib/ld-uClibc.so.0
>  gcc -muclibc -mhard-float => /lib/ld-uClibc.so.0
> 
> -- Michael

Re: [RS6000] Stack tie fix.

[Olivier Hainque]

Hello Alan,

Thanks a lot for following up on this one. Coincidentally, I was just
about to submit the alternate approach we had discussed about, after
David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html.

We have experienced with it for a while on our gcc-4.5 series of
compilers and we are working on a transition to gcc 4.7.

This is of course a much heavier hammer so it would be nice if we can
indeed have a subtler way out :-)

Olivier

On Apr 3, 2012, at 10:40 , Alan Modra wrote:

> This patch merges the rs6000 stack_tie and frame_tie rtl, so that we
> now should use a tie insn that mentions all base regs involved in
> register saves and restores.  That should avoid any alias analysis
> problems eg. http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01156.html.
> I chose to put the regs of interest on the destination of the fake
> set, rather than in the source as is currently done, because I figure
> that relying on the compiler to not reorder reads is fragile.  Here's
> an example of the new stack tie:
> 
> (set (mem:BLK (unspec:SI [(reg:SI 1) (reg:SI 12)] UNSPEC_TIE))
> (const_int 0))
> 
> Some notes:
> - I tried putting the mem on both source and destination of the set,
>  but that runs afoul of rtl dead code elimination.
> - The rs6000_emit_epilogue places that called gen_frame_tie and
>  gen_stack_tie both used alias set 0 mems.  I believe this was
>  unnecessarily restrictive.
> - CODE_FOR_stack_tie is mentioned in rs6000.c but not
>  CODE_FOR_frame_tie.  Removing frame_tie fixes this sched bug too.
> 
> Bootstrapped and regression tested powerpc-linux with usual -O2
> BOOT_CFLAGS and also -Os, and testcases from pr44199, pr30282, pr52828,
> the url above and http://gcc.gnu.org/ml/gcc/2011-03/msg00123.html
> examined for sanity.  OK to apply?
> 
>   PR target/52828
>   * config/rs6000/rs6000.c (rs6000_emit_stack_tie): Rewrite with
>   tie regs on destination of set.  Delete forward declaration.
>   (rs6000_emit_stack_reset): Update rs6000_emit_stack_tie calls.
>   (rs6000_emit_prologue): Likewise.
>   (rs6000_emit_epilogue): Likewise.  Use in place of gen_frame_tie
>   and gen_stack_tie.
>   * config/rs6000/predicates.md (tie_operand): New.
>   * config/rs6000/rs6000.md (restore_stack_block): Generate new
>   stack tie rtl.
>   (restore_stack_nonlocal): Likewise.
>   (stack_tie): Update.
>   (frame_tie): Delete.
> 
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 185830)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -925,7 +925,6 @@ static const char *rs6000_invalid_within_doloop (c
> static bool rs6000_legitimate_address_p (enum machine_mode, rtx, bool);
> static bool rs6000_debug_legitimate_address_p (enum machine_mode, rtx, bool);
> static rtx rs6000_generate_compare (rtx, enum machine_mode);
> -static void rs6000_emit_stack_tie (void);
> static bool spe_func_has_64bit_regs_p (void);
> static rtx gen_frame_mem_offset (enum machine_mode, rtx, int);
> static unsigned rs6000_hash_constant (rtx);
> @@ -18517,12 +18516,28 @@ rs6000_aix_asm_output_dwarf_table_ref (char * fram
>and the change to the stack pointer.  */
> 
> static void
> -rs6000_emit_stack_tie (void)
> +rs6000_emit_stack_tie (rtx fp, bool hard_frame_needed)
> {
> -  rtx mem = gen_frame_mem (BLKmode,
> -gen_rtx_REG (Pmode, STACK_POINTER_REGNUM));
> +  rtx u;
> +  rtvec p;
> +  int i;
> 
> -  emit_insn (gen_stack_tie (mem));
> +  if (REGNO (fp) == STACK_POINTER_REGNUM
> +  || (hard_frame_needed
> +   && REGNO (fp) == HARD_FRAME_POINTER_REGNUM))
> +fp = NULL_RTX;
> +
> +  p = rtvec_alloc (1 + hard_frame_needed + (fp != NULL_RTX));
> +
> +  i = 0;
> +  RTVEC_ELT (p, i++) = gen_rtx_REG (Pmode, STACK_POINTER_REGNUM);
> +  if (hard_frame_needed)
> +RTVEC_ELT (p, i++) = gen_rtx_REG (Pmode, HARD_FRAME_POINTER_REGNUM);
> +  if (fp != NULL_RTX)
> +RTVEC_ELT (p, i++) = fp;
> +  u = gen_rtx_UNSPEC (Pmode, p, UNSPEC_TIE);
> +
> +  emit_insn (gen_stack_tie (gen_frame_mem (BLKmode, u)));
> }
> 
> /* Emit the correct code for allocating stack space, as insns.
> @@ -19142,7 +19157,7 @@ rs6000_emit_stack_reset (rs6000_stack_t *info,
>   || (TARGET_SPE_ABI
> && info->spe_64bit_regs_used != 0
> && info->first_gp_reg_save != 32))
> -rs6000_emit_stack_tie ();
> +rs6000_emit_stack_tie (frame_reg_rtx, frame_pointer_needed);
> 
>   if (frame_reg_rtx != sp_reg_rtx)
> {
> @@ -19362,7 +19377,7 @@ rs6000_emit_prologue (void)
>   }
>   rs6000_emit_allocate_stack (info->total_size, copy_reg);
>   if (frame_reg_rtx != sp_reg_rtx)
> - rs6000_emit_stack_tie ();
> + rs6000_emit_stack_tie (frame_reg_rtx, false);
> }
> 
>   /* Handle world saves specially here.  */
> @@ -19866,7 +19881,7 @@ rs6000_emit_prologue (void)
>   sp_offset = info->total_size;
>   rs6000_emit_allo

PING: PATCH: Backport x32 support to libtool

[H.J. Lu]

On Thu, Mar 29, 2012 at 7:34 AM, H.J. Lu  wrote:
> On Sat, Mar 3, 2012 at 9:54 AM, H.J. Lu  wrote:
>> Hi,
>>
>> This patch backports x32 support to libtool:
>>
>> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=88992fe6771ec3258bde1b03314ce579da0ac2d5
>>
>> OK to install?
>>
>> Thanks.
>>
>>
>> H.J.
>> ---
>> ommit 0d8c092cac25c3bce5dbfc1981b84df91b3f6086
>> Author: H.J. Lu 
>> Date:   Mon Dec 12 13:03:14 2011 -0800
>>
>>    Add x32 support to libtool.m4
>>
>>    2011-12-12  H.J. Lu  
>>
>>        * libtool.m4 (_LT_ENABLE_LOCK): Support x32.
>>
>> diff --git a/ChangeLog.x32 b/ChangeLog.x32
>> new file mode 100644
>> index 000..b6e01ee
>> --- /dev/null
>> +++ b/ChangeLog.x32
>> @@ -0,0 +1,3 @@
>> +2011-12-12  H.J. Lu  
>> +
>> +       * libtool.m4 (_LT_ENABLE_LOCK): Support x32.
>> diff --git a/libtool.m4 b/libtool.m4
>> index 67321a7..a7f99ac 100644
>> --- a/libtool.m4
>> +++ b/libtool.m4
>> @@ -1232,7 +1232,14 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
>>            LD="${LD-ld} -m elf_i386_fbsd"
>>            ;;
>>          x86_64-*linux*)
>> -           LD="${LD-ld} -m elf_i386"
>> +           case `/usr/bin/file conftest.o` in
>> +             *x86-64*)
>> +               LD="${LD-ld} -m elf32_x86_64"
>> +               ;;
>> +             *)
>> +               LD="${LD-ld} -m elf_i386"
>> +               ;;
>> +           esac
>>            ;;
>>          ppc64-*linux*|powerpc64-*linux*)
>>            LD="${LD-ld} -m elf32ppclinux"
>
>
> Hi Ralf,
>
> Can you review this patch?
>
> Thanks.
>

PING.

-- 
H.J.

Re: [RS6000] Stack tie fix.

[Olivier Hainque]

On Apr 3, 2012, at 16:34 , Olivier Hainque wrote:
> Thanks a lot for following up on this one. Coincidentally, I was just
> about to submit the alternate approach we had discussed about, after
> David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html.

> This is of course a much heavier hammer so it would be nice if we can
> indeed have a subtler way out :-)

 I realized that this last sentence is ambiguous ...

 To clarify: the heavier approach is the one I was about to submit
 (minor variation of Joseph's proposal in the thread just referenced),
 and the subtler way out is the one you are proposing here.

 Olivier

Re: [PATCH, i386, Android] -mandroid support for i386 target

[H.J. Lu]

On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich  wrote:
>> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>

 The point is that one can build a toolchain for i686-linux-gnu that will 
 support both 32-bit and 64-bit multilibs.  The 32-bit multilib will be 
 used by default, and compilation for 64-bit user-space can be requested 
 with -m64 option.  Even though Android is not supported for -m64, such a 
 toolchain can support Android as a additional "-m32 -mandroid" multilib.  
 I.e., the toolchain will have three multilibs in total: "-m32" (default), 
 "-m64" and "-m32 -mandroid".  I386/linux64.h will be picked up for such a 
 toolchain, even though by default it would compile for 32-bit target.  
 Does this clear up things?

>>>
>>> I think I see your point. And it seems to make all this work I'll also
>>> have to rename i386/gnu-user.h into i386/gnu-user32.h and create
>>> i386/gnu-user.h with common definitions to be included by
>>> gnu-user[32|64].h. Otherwise I wont be able to use some definitions
>>> (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in
>>> linux64.h. Right?
>>
>> It's simpler that you think.  The target headers ($tm_file in config.gcc -- 
>> gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which 
>> serves as proxy to all those headers.  All definitions made in preceding 
>> headers are available in subsequent headers.  So, given that 
>> i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only 
>> need to touch linux*.h.
>>
>> Thanks,
>>
>> --
>> Maxim Kuvyrkov
>> CodeSourcery / Mentor Graphics
>>
>
>
> Hi,
>
> I prepared version with common linux.h and gnu-user.h. Does it look OK?
>
> Bootstrapped and checked on linux-x86_64.
>

There are so many duplicates in gnu-user64.h and gnu-user32.h.
Please move all of them to gnu-user.h.

Thanks.

-- 
H.J.

Re: [C Patch]: pr52543

[Kenneth Zadeck]

Richard,

thanks, for doing the changes.In particular, i did not really 
understand how the target stuff was supposed to work.


I have one issue with the changes that you made.

I had actually decided that the speed/size decision was not relevant to 
this patch.The problem is that since this is a global optimization 
which propagates the info across the entire web of moves, you really 
want/need to use the same cost metric everywhere.  (of course, making 
the speed/size decision on the global optimization level would be fine; 
my issue is with the choice being at the bb level.)So now you are 
going to have some moves in a web saying yes while others saying no.
The ones that say no will dominate.   It is unlikely you will get what 
you want (the important nodes really running fast) out of this, assuming 
you have a target where the decision could go either way.


Aside from this, everything looks very good.

Kenny

On 04/03/2012 09:53 AM, Richard Sandiford wrote:

Index: gcc/lower-subreg.h
===
--- /dev/null   2012-01-03 10:09:21.739576622 +
+++ gcc/lower-subreg.h  2012-04-03 14:38:35.397879009 +0100
@@ -0,0 +1,59 @@
+/* Target-dependent costs for lower-subreg.c.
+   Copyright (C) 2012 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option; any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#ifndef LOWER_SUBREG_H
+#define LOWER_SUBREG_H 1
+
+/* Information about whether, and where, lower-subreg should be applied.  */
+struct lower_subreg_choices {
+  /* A boolean vector for move splitting that is indexed by mode and is
+ true for each mode that is to have its copies split.  */
+  bool move_modes_to_split[MAX_MACHINE_MODE];
+
+  /* True if zero-extensions from word_mode to twice_word_mode should
+ be split.  */
+  bool splitting_zext;
+
+  /* Index X is true if twice_word_mode shifts by X + BITS_PER_WORD
+ should be split.  */
+  bool splitting_ashift[MAX_BITS_PER_WORD];
+  bool splitting_lshiftrt[MAX_BITS_PER_WORD];
+
+  /* True if there is at least one mode that is worth splitting.  */
+  bool something_to_do;
+};
+
+/* Target-specific information for the subreg lowering pass.  */
+struct target_lower_subreg {
+  /* An integer mode that is twice as wide as word_mode.  */
+  enum machine_mode x_twice_word_mode;
+
+  /* What we have decided to do when optimizing for size (index 0)
+ and speed (index 1).  */
+  struct lower_subreg_choices x_choices[2];
+};
+
+extern struct target_lower_subreg default_target_lower_subreg;
+#if SWITCHABLE_TARGET
+extern struct target_lower_subreg *this_target_lower_subreg;
+#else
+#define this_target_lower_subreg (&default_target_lower_subreg)
+#endif
+
+#endif
Index: gcc/target-globals.h
===
--- gcc/target-globals.h2010-07-29 13:10:13.0 +0100
+++ gcc/target-globals.h2012-04-02 12:07:41.323231941 +0100
@@ -35,6 +35,7 @@ #define TARGET_GLOBALS_H 1
  extern struct target_builtins *this_target_builtins;
  extern struct target_gcse *this_target_gcse;
  extern struct target_bb_reorder *this_target_bb_reorder;
+extern struct target_lower_subreg *this_target_lower_subreg;

  struct GTY(()) target_globals {
struct target_flag_state *GTY((skip)) flag_state;
@@ -51,6 +52,7 @@ struct GTY(()) target_globals {
struct target_builtins *GTY((skip)) builtins;
struct target_gcse *GTY((skip)) gcse;
struct target_bb_reorder *GTY((skip)) bb_reorder;
+  struct target_lower_subreg *GTY((skip)) lower_subreg;
  };

  extern struct target_globals default_target_globals;
@@ -74,6 +76,7 @@ restore_target_globals (struct target_gl
this_target_builtins = g->builtins;
this_target_gcse = g->gcse;
this_target_bb_reorder = g->bb_reorder;
+  this_target_lower_subreg = g->lower_subreg;
  }
  #endif

Index: gcc/target-globals.c
===
--- gcc/target-globals.c2011-03-18 13:09:16.0 +
+++ gcc/target-globals.c2012-04-02 12:06:44.026273230 +0100
@@ -40,6 +40,7 @@ Software Foundation; either version 3, o
  #include "builtins.h"
  #include "gcse.h"
  #include "bb-reorder.h"
+#include "lower-subreg.h"

  #if SWITCHABLE_TARGET
  struct target_globals default_target_globals = {
@@ -56,7 +57,8 @@ struct target_globals default_target_glo
&default_target_ira_int,
   

Re: [PATCH H8300] Added -mno-exr option in case of function with "monitor" attribute

[Sandeep Kumar Singh]

Hello Jeff,

Thank you for reviewing the patch.

>> First, do you have an assignment on file with the FSF

We do have a corporate assignment for KPIT.

It was signed by Bradley Kuhn from FSF side and Dhananjay Deshpande 
from KPIT side, during April 2003. In a mail, Peter Brown from FSF has 
mentioned ticket number #22417 which was associated with this corporate
assignment. 

However, we do not have any assignment for individuals here. Please 
let me know whether we need to get it done for individuals as well.

>> My recollection was -mint32 was supported on the original H8/300; 
>> is there something in particular that makes you want to issue an 
>> error for that case?

My assumption was based on t-h8300 file. In this file, combination of 
h8300 and int32 is not considered for MULTILIB_OPTIONS. Did I 
misinterpret it? In that case I will remove the respective hunk from 
the patch and will repost it.

>> In h8300.opt, rather than say "Push exr on stack", would it make 
>> more sense to say "[Do not] Push extended registers on stack in 
>> monitor functions"?

Thank you for this suggestion. I have made this change. Please find the
updated patch attached here.

Thanks and Regards,
Sandeep Kumar Singh,
KPIT Cummins InfoSystems Ltd.
Pune, India



patch-EXR.patch
Description: patch-EXR.patch


ChangeLog.patch
Description: ChangeLog.patch

Re: [Patch, Fortran]: Fix libgfortran.h error for VMS

[Tobias Burnus]

On 04/03/2012 02:42 PM, Tristan Gingold wrote:

The simplest path is simply to reverse the include order in libgfortran.h.  I 
know that this is somewhat VMS specific, and I welcome better ideas.


Well, changing the order is not that bad than one has to try hard to  
find a better solution. (Unless, it fails on other systems with the new 
order.)



Tested by building gfortran for x86_64-darwin and ia64-hp-openvms.


OK. Thanks for the patch.

Tobias

[wwwdocs] Buildstat update for 4.4

[Tom G. Christensen]

Latest results for 4.4.x

-tgc

Testresults for 4.4.7:
  powerpc-apple-darwin8.11.0
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/buildstat.html,v
retrieving revision 1.25
diff -u -r1.25 buildstat.html
--- buildstat.html  21 Aug 2011 13:22:56 -  1.25
+++ buildstat.html  3 Apr 2012 16:06:23 -
@@ -344,6 +344,7 @@
 powerpc-apple-darwin8.11.0
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01661.html";>4.4.7,
 http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg00888.html";>4.4.6,
 http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg00887.html";>4.4.4,
 http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg03013.html";>4.4.4

[wwwdocs] Buildstat update for 4.5

[Tom G. Christensen]

Latest results for 4.5.x

-tgc

Testresults for 4.5.3:
  i386-pc-solaris2.8 (2)
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/buildstat.html,v
retrieving revision 1.13
diff -u -r1.13 buildstat.html
--- buildstat.html  21 Aug 2011 18:23:07 -  1.13
+++ buildstat.html  3 Apr 2012 16:05:33 -
@@ -129,6 +129,8 @@
 i386-pc-solaris2.8
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01359.html";>4.5.3,
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01215.html";>4.5.3,
 http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00795.html";>4.5.3,
 http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01977.html";>4.5.2,
 http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01703.html";>4.5.2,

[wwwdocs] Buildstat update for 4.6

[Tom G. Christensen]

Latest results for 4.6.x

-tgc

Testresults for 4.6.3:
  i386-pc-solaris2.8 (2)
  i386-pc-solaris2.10
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/buildstat.html,v
retrieving revision 1.10
diff -u -r1.10 buildstat.html
--- buildstat.html  18 Mar 2012 14:47:29 -  1.10
+++ buildstat.html  3 Apr 2012 16:04:48 -
@@ -108,6 +108,8 @@
 i386-pc-solaris2.8
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02401.html";>4.6.3,
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html";>4.6.3,
 http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01757.html";>4.6.3,
 http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html";>4.6.2,
 http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00139.html";>4.6.1,
@@ -134,6 +136,7 @@
 i386-pc-solaris2.10
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01817.html";>4.6.3,
 http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02468.html";>4.6.2,
 http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00327.html";>4.6.1,
 http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02738.html";>4.6.0,

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Earnshaw]

On 03/04/12 12:01, Jakub Jelinek wrote:
> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
>> If, so then there's only one way to sort out this mess.
>>
>> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
>> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
> 
> The above scheme is a Debianism which no other distro is using.
> 
>   Jakub
> 

Not really, it's just a naming convention for where the config-specific
dynamic loader lives.  It doesn't affect where the remaining shared
libraries live.

The subdirectories could be called fred and jim and it would still work.
 The only thing required is that this part of the naming scheme be
agreed amongst the distros.

This looks to me like it's turning into a bike-shed painting excerise
between the distros out there.  That's really sad.

R.

[wwwdocs] Buildstat update for 4.7

[Tom G. Christensen]

First round of results for 4.7.x

-tgc

Testresults for 4.7.0:
  alpha-dec-osf5.1b
  hppa2.0w-hp-hpux11.11
  i386-apple-darwin10.8.0
  i386-pc-solaris2.8 (2)
  i386-pc-solaris2.9
  i386-pc-solaris2.10
  i386-pc-solaris2.11
  powerpc-apple-darwin8.11.0
  sparc-sun-solaris2.8 (2)
  sparc-sun-solaris2.9
  sparc-sun-solaris2.11
  x86_64-apple-darwin10.8.0
  x86_64-apple-darwin11.3.0
  x86_64-unknown-linux-gnu (2)

Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/buildstat.html,v
retrieving revision 1.1
diff -u -r1.1 buildstat.html
--- buildstat.html  2 Mar 2012 10:20:03 -   1.1
+++ buildstat.html  3 Apr 2012 16:04:41 -
@@ -20,5 +20,122 @@
 http://gcc.gnu.org/install/finalinstall.html";>
 Installing GCC: Final Installation.
 
+
+
+
+alpha-dec-osf5.1b
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02967.html";>4.7.0
+
+
+
+hppa2.0w-hp-hpux11.11
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg00080.html";>4.7.0
+
+
+
+
+i386-apple-darwin10.8.0
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02742.html";>4.7.0
+
+
+
+
+i386-pc-solaris2.8
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02998.html";>4.7.0,
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02619.html";>4.7.0
+
+
+
+
+i386-pc-solaris2.9
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02618.html";>4.7.0
+
+
+
+
+i386-pc-solaris2.10
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02526.html";>4.7.0
+
+
+
+
+i386-pc-solaris2.11
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02519.html";>4.7.0
+
+
+
+powerpc-apple-darwin8.11.0
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02890.html";>4.7.0
+
+
+
+
+sparc-sun-solaris2.8
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02928.html";>4.7.0,
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02621.html";>4.7.0
+
+
+
+
+sparc-sun-solaris2.9
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02620.html";>4.7.0
+
+
+
+
+sparc-sun-solaris2.11
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02536.html";>4.7.0
+
+
+
+
+x86_64-apple-darwin10.8.0
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02708.html";>4.7.0
+
+
+
+
+x86_64-apple-darwin11.3.0
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02630.html";>4.7.0
+
+
+
+
+x86_64-unknown-linux-gnu
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02853.html";>4.7.0,
+http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02514.html";>4.7.0
+
+
+
+
+
 
 

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Andrew Haley]

On 04/03/2012 05:09 PM, Richard Earnshaw wrote:
> On 03/04/12 12:01, Jakub Jelinek wrote:
>> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
>>> If, so then there's only one way to sort out this mess.
>>>
>>> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
>>> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
>>
>> The above scheme is a Debianism which no other distro is using.
>>
>>  Jakub
>>
> 
> Not really, it's just a naming convention for where the config-specific
> dynamic loader lives.  It doesn't affect where the remaining shared
> libraries live.
> 
> The subdirectories could be called fred and jim and it would still work.
>  The only thing required is that this part of the naming scheme be
> agreed amongst the distros.
> 
> This looks to me like it's turning into a bike-shed painting excerise
> between the distros out there.  That's really sad.

I don't think we ever even had the discussion: Debian invented their
Debian-internal scheme for managing multiple ABIs.  They have in the past
used patched versions of gcc, as in the case of x86_64.

Andrew.

Re: [C Patch]: pr52543

[Ian Lance Taylor]

Richard Sandiford  writes:

> What do you think?  The patch looks OK to me with these changes,
> but I'd like to leave it for 48 hours to see if Ian has any comments.

The patch looks fine to me.

Thanks.

Ian

> 2012-04-03  Kenneth Zadeck  
>   Richard Sandiford  
>
>   * Makefile.in (lower-subreg.o, target-globals.o): Depend on
>   lower-subreg.h.
>   * lower-subreg.h: New file.
>   * target-globals.h (this_target_lower_subreg): Declare.
>   (target_globals): Add lower_subreg;
>   (restore_target_globals): Restore this_target_lower_subreg.
>   * target-globals.c: Include it.
>   (default_target_globals): Add default_target_lower_subreg.
>   (save_target_globals): Initialize target_lower_subreg.
>   * rtl.h (init_lower_subreg): Added declaration.
>   * toplev.c (backend_init_target): Call initializer for lower-subreg
>   pass.
>   * lower-subreg.c (LOG_COSTS, FORCE_LOWERING): New macros.
>   (default_target_lower_subreg): New variable.
>   (this_target_lower_subreg): Likewise.
>   (twice_word_mode, choices): New macros.
>   (shift_cost, compute_splitting_shift, compute_costs)
>   (init_lower_subreg): New functions.
>   (resolve_simple_move): Add speed_p argument.  Check choices.
>   (find_pseudo_copy): Don't check the mode size here.
>   (resolve_simple_move): Assert the mode size.
>   (find_decomposable_shift_zext): Add speed_p argument and return
>   a bool.  Check choices.
>   (resolve_shift_zext): Add comment.
>   (dump_shift_choices, dump_choices): New functions.
>   (decompose_multiword_subregs): Dump list of profitable
>   transformations.  Add code to skip non profitable transformations.
>   Update calls to simple_move and find_decomposable_shift_zext.

Re: [PATCH H8300] Added -mno-exr option in case of function with "monitor" attribute

[Jeff Law]

On 04/03/2012 09:40 AM, Sandeep Kumar Singh wrote:

First, do you have an assignment on file with the FSF


We do have a corporate assignment for KPIT.

Excellent.  Thanks for verifying.



My recollection was -mint32 was supported on the original H8/300;
is there something in particular that makes you want to issue an
error for that case?


My assumption was based on t-h8300 file. In this file, combination of
h8300 and int32 is not considered for MULTILIB_OPTIONS. Did I
misinterpret it? In that case I will remove the respective hunk from
the patch and will repost it.
Hmm, my memory must be faulty...  You're absolutely correct, based on 
the multilibs -mint32 isn't supported on the H8/300.


[law@stumpy gcc]$ ./xgcc -B./ -print-multi-lib
.;
h8300h;@mh
h8300s;@ms
h8sx;@msx
h8300h/normal;@mh@mn
h8300h/int32;@mh@mint32
h8300h/normal/int32;@mh@mn@mint32
h8300s/normal;@ms@mn
h8300s/int32;@ms@mint32
h8300s/normal/int32;@ms@mn@mint32
h8sx/normal;@msx@mn
h8sx/int32;@msx@mint32
h8sx/normal/int32;@msx@mn@mint32




In h8300.opt, rather than say "Push exr on stack", would it make
more sense to say "[Do not] Push extended registers on stack in
monitor functions"?


Thank you for this suggestion. I have made this change. Please find the
updated patch attached here.

I'll get it installed momentarily.

Thanks,
jeff

Re: [RS6000] Stack tie fix.

[David Edelsohn]

On Tue, Apr 3, 2012 at 10:55 AM, Olivier Hainque  wrote:
>
> On Apr 3, 2012, at 16:34 , Olivier Hainque wrote:
>> Thanks a lot for following up on this one. Coincidentally, I was just
>> about to submit the alternate approach we had discussed about, after
>> David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html.
>
>> This is of course a much heavier hammer so it would be nice if we can
>> indeed have a subtler way out :-)
>
>  To clarify: the heavier approach is the one I was about to submit
>  (minor variation of Joseph's proposal in the thread just referenced),
>  and the subtler way out is the one you are proposing here.

We can give Alan's patch a try.  I'm not sure if it is sufficient
given the experience of IBM's XL compiler.  I also would rather not
use the heavier hammer, but I don't want to leave a latent bug.

Thanks, David

Re: [PATCH] PR bootstrap/52623 Disable libquadmath on AIX

[David Edelsohn]

On Mon, Mar 26, 2012 at 7:40 AM, Joseph S. Myers
 wrote:
> On Fri, 23 Mar 2012, David Edelsohn wrote:
>
>> The build process of libquadmath sometimes encounters problems on AIX
>> due to multilib and LD_LIBRARY_PATH interfering with GCC's own library
>> dependencies.  Libquadmath is not used on AIX, so this patch adds it
>> to noconfigdirs.
>
> Please include this explanation in a comment on the powerpc-*-aix* |
> rs6000-*-aix* case.  Existing directory-disabling cases may be
> uncommented, but new ones ought to have comments explaining the reason for
> disabling the library.

Is the following okay?

Thanks, David

Index: configure.ac
===
--- configure.ac(revision 186108)
+++ configure.ac(working copy)
@@ -509,6 +509,15 @@
 fi
 fi

+# Disable libquadmath for some systems.
+case "${target}" in
+  # libquadmath is unused on AIX and libquadmath build process use of
+  # LD_LIBRARY_PATH can break AIX bootstrap.
+  powerpc-*-aix* | rs6000-*-aix*)
+noconfigdirs="$noconfigdirs target-libquadmath"
+;;
+esac
+
 # Disable libssp for some systems.
 case "${target}" in
   avr-*-*)

Re: rs6000 toc reference rtl again

[David Edelsohn]

On Tue, Mar 27, 2012 at 3:54 AM, Alan Modra  wrote:
> Now that we are back in stage1, I'd like to apply
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html, a change to
> toc reference rtl in order to properly specify r2 dependencies.  More
> commentary in that url.  I'm reposting the patch here since the old
> one no longer applies cleanly, and I've added some ENABLE_CHECKING
> code in rs6000_delegitimize_address.
>
> Bootstrapped and regression tested powerpc64-linux.  OK for mainline?
>
>        * cselib.c (preserve_only_constants): Remove HIGH rtx containing
>        value references.
>        * cprop.c (cprop_constant_p): Return false for HIGH rtx containing
>        value references.
>        * config/rs6000/predicates.md (input_operand): Match unspec.  Remove
>        redundant tests.
>        * rs6000-protos.h (toc_relative_expr_p): Update prototype.
>        * const/rs6000/rs6000.c (tocrel_base, tocrel_offset): Make const.
>        (legitimate_constant_pool_address_p): Move TARGET_TOC test and
>        register checks to..
>        (toc_relative_expr_p): ..here.  Add "strict" param.  Match new rtl
>        generated by create_TOC_reference.
>        (rs6000_delegitimize_address): Handle new rtl for toc refs.
>        (rs6000_cannot_force_const_mem, rs6000_find_base_term): Likewise.
>        (use_toc_relative_ref): New function, split out from..
>        (rs6000_emit_move): ..here.  Remove redundant tests.
>        (rs6000_legitimize_reload_address): Formatting.  Remove redundant
>        code.  Use use_toc_relative_ref.
>        (print_operand): Formatting, style.  Adjust for toc changes.
>        (print_operand_address): Likewise.
>        (rs6000_output_addr_const_extra): Likewise.
>        (create_TOC_reference): Put TOC_REGISTER in UNSPEC_TOCREL rather
>        than a PLUS.  Use this formulation for both high and low part
>        of -mcmodel=medium/large toc reference too.
>        * config/rs6000/rs6000.md (tls_gd, tls_gd_high): Similarly avoid
>        a PLUS in high part of addresses here.
>        (tls_ld, tls_ld_high, tls_got_dtprel, tls_got_dtprel_high): Likewise.
>        (tls_got_tprel, tls_got_tprel_high, largetoc_high): Likewise.
>        (largetoc_high, largetoc_low): Move earlier.  Cope when no
>        base reg available.

Now that PPC bootstrap appears to be fixed, this patch is okay to apply.

However, I cannot approve the cselib.c and cprop.c changes.

Thanks, David

Re: [Patch, fortran] PR 49010/24518 MOD/MODULO fixes

[Janne Blomqvist]

PING**2

On Wed, Mar 21, 2012 at 23:45, Janne Blomqvist
 wrote:
> PING
>
> On Wed, Mar 14, 2012 at 01:03, Janne Blomqvist
>  wrote:
>> Hi,
>>
>> the attached patch implements a few fixes and cleanups for the MOD and
>> MODULO intrinsics.
>>
>> - When the arguments are constant, use mpfr_fmod instead of the naive
>> algorithms which are numerically unstable for large arguments. This
>> extends the PR 24518 fix to constant arguments as well, and makes the
>> compile-time evaluation match the runtime implementation which also
>> uses fmod in the same manner.
>>
>> - Remove the old fallback path for the case builtin_fmod is not
>> available, as the builtin is AFAICS always available.
>>
>> The patch does not per se fix the corner-case bug as reported in PR
>> 49010, in fact it makes it worse in a way as with the patch the result
>> if the arguments are parameters is the same as the runtime result
>> (previously, the compile-time result was correct). But, I think we
>> should leave it as it is. Due to the reasons above, we're not using
>> the naive algorithms anyway, and IMHO -0.0 is quite a good
>> approximation for +0.0 anyway. One might even argue that due to the
>> numerical instability, specifying the naive algorithms is a bug in the
>> standard.
>>
>> The patch adds notes to the documentation about the usage of fmod, so
>> users interested in corner-case behavior can look up how that function
>> is supposed to behave on their target. FWIW, AFAICS MPFR and glibc
>> fmod conform to the behavior specified in C99 Annex F.
>>
>> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>>
>> 2012-03-14  Janne Blomqvist  
>>
>>        PR fortran/49010
>>        PR fortran/24518
>>        * intrinsic.texi (MOD,MODULO): Mention usage of fmod instead of
>>        naive algorithm.
>>        * simplify.c (gfc_simplify_mod): Use mpfr_fmod.
>>        (gfc_simplify_modulo): Likewise.
>>        * trans-intrinsic.c (gfc_conv_intrinsic_mod): Remove fallback as
>>        builtin_fmod is always available.
>>
>>
>> --
>> Janne Blomqvist
>
>
>
> --
> Janne Blomqvist



-- 
Janne Blomqvist

libgo patch committed: Fix testsuite on PPC

[Ian Lance Taylor]

The libgo testsuite looks for functions that match a certain name.  On
PPC functions are in the data segment, not the text segment.  This patch
to the testsuite script makes the script look in the data segment for
functions on PPC.  Bootstrapped and ran libgo testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline and 4.7 branch.

Ian

diff -r 5016046ebbfe libgo/Makefile.am
--- a/libgo/Makefile.am	Fri Mar 30 15:30:22 2012 -0700
+++ b/libgo/Makefile.am	Tue Apr 03 10:54:59 2012 -0700
@@ -1808,9 +1808,9 @@
 	prefix=`if test "$(@D)" = "regexp"; then echo regexp-test; else dirname $(@D); fi`; \
 	test "$${prefix}" != "." || prefix="$(@D)"; \
 	if test "$(use_dejagnu)" = "yes"; then \
-	  $(SHELL) $(srcdir)/testsuite/gotest --dejagnu=yes --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --prefix="libgo_$${prefix}" --pkgfiles="$(go_$(subst /,_,$(@D))_files)" --testname="$(@D)" $(GOTESTFLAGS); \
+	  $(SHELL) $(srcdir)/testsuite/gotest --dejagnu=yes --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --prefix="libgo_$${prefix}" --pkgfiles="$(go_$(subst /,_,$(@D))_files)" --testname="$(@D)" --goarch="$(GOARCH)" $(GOTESTFLAGS); \
 	else \
-	  if $(SHELL) $(srcdir)/testsuite/gotest --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --prefix="libgo_$${prefix}" --pkgfiles="$(go_$(subst /,_,$(@D))_files)" $(GOTESTFLAGS) >>$@-testlog 2>&1; then \
+	  if $(SHELL) $(srcdir)/testsuite/gotest --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --prefix="libgo_$${prefix}" --pkgfiles="$(go_$(subst /,_,$(@D))_files)" --goarch="$(GOARCH)" $(GOTESTFLAGS) >>$@-testlog 2>&1; then \
 	echo "PASS: $(@D)" >> $@-testlog; \
 	echo "PASS: $(@D)"; \
 	echo "PASS: $(@D)" > $@-testsum; \
diff -r 5016046ebbfe libgo/testsuite/gotest
--- a/libgo/testsuite/gotest	Fri Mar 30 15:30:22 2012 -0700
+++ b/libgo/testsuite/gotest	Tue Apr 03 10:54:59 2012 -0700
@@ -32,6 +32,7 @@
 keep=false
 prefix=
 dejagnu=no
+GOARCH=""
 timeout=240
 testname=""
 trace=false
@@ -86,6 +87,15 @@
 		dejagnu=`echo $1 | sed -e 's/^--dejagnu=//'`
 		shift
 		;;
+	x--goarch)
+		GOARCH=$2
+		shift
+		shift
+		;;
+	x--goarch=*)
+		GOARCH=`echo $1 | sed -e 's/^--goarch=//'`
+		shift
+		;;
 	x--timeout)
 		timeout=$2
 		shift
@@ -326,13 +336,18 @@
 }
 
 {
+	text="T"
+	case "$GOARCH" in
+	ppc*) text="D" ;;
+	esac
+
 	# test functions are named TestFoo
 	# the grep -v eliminates methods and other special names
 	# that have multiple dots.
 	pattern='Test([^a-z].*)?'
 	# The -p option tells GNU nm not to sort.
 	# The -v option tells Solaris nm to sort by value.
-	tests=$($NM -p -v _gotest_.o $xofile | egrep ' T .*\.'$pattern'$' | grep -v '\..*\..*\.' | fgrep -v '$' | sed 's/.* //' | sed 's/.*\.\(.*\.\)/\1/')
+	tests=$($NM -p -v _gotest_.o $xofile | egrep " $text .*\."$pattern'$' | grep -v '\..*\..*\.' | fgrep -v '$' | sed 's/.* //' | sed 's/.*\.\(.*\.\)/\1/')
 	if [ "x$tests" = x ]; then
 		echo 'gotest: warning: no tests matching '$pattern in _gotest_.o $xofile 1>&2
 		exit 2

Re: rs6000 toc reference rtl again

[Richard Sandiford]

Alan Modra  writes:
> Now that we are back in stage1, I'd like to apply
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html, a change to
> toc reference rtl in order to properly specify r2 dependencies.  More
> commentary in that url.  I'm reposting the patch here since the old
> one no longer applies cleanly, and I've added some ENABLE_CHECKING
> code in rs6000_delegitimize_address.

Sorry to be a pain, but I don't think HIGH is supposed contain
regs either.  Both HIGH and CONST are supposed to be true constants.

It's fine to have a non-HIGH expression as the first operand to
a LO_SUM though.  Alpha and MIPS use this for small data, where
the first LO_SUM operand is the small data pointer.  It can also
be an arbitrary rtx like a PLUS.

Richard

Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)

[DJ Delorie]

> If it's required for ABI compatibility why is this an attribute and not
> a target hook?

The ABI uses a #pragma; after this is in I'll do a target-specific
pragma handler to set the attribute.  Plus, when I originally proposed
the idea, I was told it was generic so make it an attribute ;-)

Re: [C Patch]: pr52543

[Richard Sandiford]

Kenneth Zadeck  writes:
> Richard,
>
> thanks, for doing the changes.In particular, i did not really 
> understand how the target stuff was supposed to work.
>
> I have one issue with the changes that you made.
>
> I had actually decided that the speed/size decision was not relevant to 
> this patch.The problem is that since this is a global optimization 
> which propagates the info across the entire web of moves, you really 
> want/need to use the same cost metric everywhere.  (of course, making 
> the speed/size decision on the global optimization level would be fine; 
> my issue is with the choice being at the bb level.)So now you are 
> going to have some moves in a web saying yes while others saying no.
> The ones that say no will dominate.   It is unlikely you will get what 
> you want (the important nodes really running fast) out of this, assuming 
> you have a target where the decision could go either way.

Yeah, I suppose that's true.  The problem is that both ways are wrong really.
If we just use the function-level speed setting, there'll be times where
a cold-only web will be optimised as hot.  But as you say, if we apply
the bb-level setting, cold blocks can hold back the hot blocks.
And I don't particularly relish the idea of trying to joust between
the two.

So yeah, applying it on a function-by-function basis is probably better.
Does anyone else have any thoughts before I make that change?

Richard

Re: [PATCH, i386, Android] -mandroid support for i386 target

[Maxim Kuvyrkov]

On 4/04/2012, at 2:56 AM, H.J. Lu wrote:

> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich  wrote:
>>> 
>>> It's simpler that you think.  The target headers ($tm_file in config.gcc -- 
>>> gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which 
>>> serves as proxy to all those headers.  All definitions made in preceding 
>>> headers are available in subsequent headers.  So, given that 
>>> i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only 
>>> need to touch linux*.h.
>>> 
>>> Thanks,
>>> 
>>> --
>>> Maxim Kuvyrkov
>>> CodeSourcery / Mentor Graphics
>>> 
>> 
>> 
>> Hi,
>> 
>> I prepared version with common linux.h and gnu-user.h. Does it look OK?
>> 
>> Bootstrapped and checked on linux-x86_64.
>> 
> 
> There are so many duplicates in gnu-user64.h and gnu-user32.h.
> Please move all of them to gnu-user.h.

Ilya,

Why i386/gnu-user.h had to change at all?  It seems like you trying to clean 
up/simplify stuff in i386/gnu-user.h, but in this case it seems (a) not 
required for the main purpose of this submission, and (b) excessive.

As a side note, if it were up to me, I would merge current i386/linux.h and 
i386/linux64.h into one file -- i386/linux.h -- instead of having similar 
definitions spread around.  But that would be a clean up in itself, and would 
require a separate submission.

Thank you,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics

libgo patch committed: Add some more networking constants

[Ian Lance Taylor]

This libgo patch changes mksysinfo.sh to add some more networking
constants.  This is really just a snapshot, there are more to come,
based on differences between gccgo and the master Go library.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian

diff -r 888f1f45a4aa libgo/configure.ac
--- a/libgo/configure.ac	Tue Apr 03 10:56:09 2012 -0700
+++ b/libgo/configure.ac	Tue Apr 03 12:33:57 2012 -0700
@@ -453,7 +453,7 @@
   ;;
 esac
 
-AC_CHECK_HEADERS(sys/mman.h syscall.h sys/epoll.h sys/ptrace.h sys/syscall.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/if.h sys/prctl.h sys/mount.h sys/vfs.h sys/statfs.h sys/timex.h sys/sysinfo.h utime.h linux/reboot.h)
+AC_CHECK_HEADERS(sys/mman.h syscall.h sys/epoll.h sys/ptrace.h sys/syscall.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/if.h net/if_arp.h sys/prctl.h sys/mount.h sys/vfs.h sys/statfs.h sys/timex.h sys/sysinfo.h utime.h linux/reboot.h)
 
 AC_CHECK_HEADERS([linux/filter.h linux/netlink.h linux/rtnetlink.h], [], [],
 [#ifdef HAVE_SYS_SOCKET_H
diff -r 888f1f45a4aa libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh	Tue Apr 03 10:56:09 2012 -0700
+++ b/libgo/mksysinfo.sh	Tue Apr 03 12:33:57 2012 -0700
@@ -94,6 +94,9 @@
 #if defined(HAVE_NET_IF_H)
 #include 
 #endif
+#if defined(HAVE_NET_IF_ARP_H)
+#include 
+#endif
 #if defined(HAVE_SYS_MOUNT_H)
 #include 
 #endif
@@ -211,7 +214,7 @@
 fi
 
 # Networking constants.
-egrep '^const _(AF|SOCK|SOL|SO|IPPROTO|TCP|IP|IPV6)_' gen-sysinfo.go |
+egrep '^const _(AF|ARPHRD|SOCK|SOL|SO|IPPROTO|TCP|IP|IPV6)_' gen-sysinfo.go |
   sed -e 's/^\(const \)_\([^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
 grep '^const _SOMAXCONN' gen-sysinfo.go |
   sed -e 's/^\(const \)_\(SOMAXCONN[^= ]*\)\(.*\)$/\1\2 = _\2/' \
@@ -710,6 +713,10 @@
 # The routing message flags.
 grep '^const _RTA' gen-sysinfo.go | \
 sed -e 's/^\(const \)_\(RTA[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
+grep '^const _RTF' gen-sysinfo.go | \
+sed -e 's/^\(const \)_\(RTF[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
+grep '^const _RTCF' gen-sysinfo.go | \
+sed -e 's/^\(const \)_\(RTCF[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
 grep '^const _RTM' gen-sysinfo.go | \
 sed -e 's/^\(const \)_\(RTM[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
 
@@ -938,6 +945,10 @@
   -e 's/_sock_filter/SockFilter/' \
 >> ${OUT}
 
+# The GNU/Linux filter flags.
+grep '^const _BPF_' gen-sysinfo.go | \
+  sed -e 's/^\(const \)_\(BPF_[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
+
 # The Solaris 11 Update 1 _zone_net_addr_t struct.
 grep '^type _zone_net_addr_t ' gen-sysinfo.go | \
 sed -e 's/_in6_addr/[16]byte/' \

PATCH: [x32] libitm failures on x32

[H.J. Lu]

Hi,

We need to use long long instead of long in gtm_jmpbuf for x86_64 since
long in x32 is 32bits.  OK for trunk and 4.7 branch?

Thanks.

H.J.
---
2012-04-03  H.J. Lu  

PR libitm/52854
* config/x86/target.h (gtm_jmpbuf): Replace long with long long
for x86-64.

diff --git a/libitm/config/x86/target.h b/libitm/config/x86/target.h
index 1d81a47..5c7e6fb 100644
--- a/libitm/config/x86/target.h
+++ b/libitm/config/x86/target.h
@@ -29,13 +29,13 @@ namespace GTM HIDDEN {
 typedef struct gtm_jmpbuf
 {
   void *cfa;
-  unsigned long rbx;
-  unsigned long rbp;
-  unsigned long r12;
-  unsigned long r13;
-  unsigned long r14;
-  unsigned long r15;
-  unsigned long rip;
+  unsigned long long rbx;
+  unsigned long long rbp;
+  unsigned long long r12;
+  unsigned long long r13;
+  unsigned long long r14;
+  unsigned long long r15;
+  unsigned long long rip;
 } gtm_jmpbuf;
 #else
 typedef struct gtm_jmpbuf

Re: Support for Runtime CPU type detection via builtins (issue5754058)

[Sriraman Tallam]

Hi,

i386 maintainers -  Is this patch ok?

Thanks,
-Sri.

On Mon, Apr 2, 2012 at 5:48 PM, Sriraman Tallam  wrote:
> On Mon, Apr 2, 2012 at 5:38 AM, Richard Guenther
>  wrote:
>> On Sat, Mar 31, 2012 at 1:03 AM, Sriraman Tallam  wrote:
>>> On Fri, Mar 30, 2012 at 5:47 AM, Michael Matz  wrote:
 Hi,

 On Thu, 29 Mar 2012, Sriraman Tallam wrote:

> +struct __processor_model
> +{
> +  /* Vendor. */
> +  unsigned int __cpu_is_amd : 1;
> +  unsigned int __cpu_is_intel : 1;
> +  /* CPU type. */
> +  unsigned int __cpu_is_intel_atom : 1;
> +  unsigned int __cpu_is_intel_core2 : 1;
> +  unsigned int __cpu_is_intel_corei7 : 1;
> +  unsigned int __cpu_is_intel_corei7_nehalem : 1;
> +  unsigned int __cpu_is_intel_corei7_westmere : 1;
> +  unsigned int __cpu_is_intel_corei7_sandybridge : 1;
> +  unsigned int __cpu_is_amdfam10h : 1;
> +  unsigned int __cpu_is_amdfam10h_barcelona : 1;
> +  unsigned int __cpu_is_amdfam10h_shanghai : 1;
> +  unsigned int __cpu_is_amdfam10h_istanbul : 1;
> +  unsigned int __cpu_is_amdfam15h_bdver1 : 1;
> +  unsigned int __cpu_is_amdfam15h_bdver2 : 1;
> +} __cpu_model;

 It doesn't make sense for the model to be a bitfield, a processor will
 have only ever exactly one model.  Just make it an enum or even just an
 int.
>>>
>>> Not entirely true, nehalem and corei7 can be both set. However, I
>>> modified this by dividing it into types and sub types and then did
>>> what you said.
>>
>> Uh...  then I suppose you need to document somewhere what names
>> match to what cpuid family/model (supposedly thats where your two-layer
>> hierarchy comes from, which incidentially misses one layer, the vendor?)
>
> Added documentation to extend.texi
>
> Patch available for review here:
> http://codereview.appspot.com/5754058
>
> Thanks,
> -Sri.
>
>
>>
>> Richard.
>>
>>>       * config/i386/i386.c (build_processor_features_struct): New function.
>>>       (build_processor_model_struct): New function.
>>>       (make_var_decl): New function.
>>>       (get_field_from_struct): New function.
>>>       (fold_builtin_target): New function.
>>>       (ix86_fold_builtin): New function.
>>>       (ix86_expand_builtin): Expand new builtins by folding them.
>>>       (make_cpu_type_builtin): New functions.
>>>       (ix86_init_platform_type_builtins): Make the new builtins.
>>>       (ix86_init_builtins): Make new builtins to detect CPU type.
>>>       (TARGET_FOLD_BUILTIN): New macro.
>>>       (IX86_BUILTIN_CPU_INIT): New enum value.
>>>       (IX86_BUILTIN_CPU_IS): New enum value.
>>>       (IX86_BUILTIN_CPU_SUPPORTS): New enum value.
>>>       * config/i386/i386-builtin-types.def: New function type.
>>>       * testsuite/gcc.target/builtin_target.c: New testcase.
>>>
>>>       * libgcc/config/i386/i386-cpuinfo.c: New file.
>>>       * libgcc/config/i386/t-cpuinfo: New file.
>>>       * libgcc/config.host: Include t-cpuinfo.
>>>       * libgcc/config/i386/libgcc-glibc.ver: Version symbols __cpu_model
>>>       and __cpu_features.
>>>
>>> Patch available for review here:
>>> http://codereview.appspot.com/5754058
>>>
>>> Thanks,
>>> -Sri.
>>>
>>>


 Ciao,
 Michael.

Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)

[DJ Delorie]

> Did you ever dig up the Apple test cases from the APPLE LOCAL work I
> pointed you at earlier?

Sorry, I read that as "the internal tree at Apple" not "the apple
branch at fsf".  I'll look at it, thanks!

> They will be more comprehensive that any testing you've done, and,
> if you get them to all pass, the work should be closer to being
> complete.  The feature needed a ton of testcases, a few didn't cut
> it.

Worse, the test cases need to be target-endian-specific, and
sizeof(int) agnostic.

Re: [PATCH] Fix PR18589

[William J. Schmidt]

On Wed, 2012-03-28 at 15:57 +0200, Richard Guenther wrote:
> On Tue, Mar 6, 2012 at 9:49 PM, William J. Schmidt
>  wrote:
> > Hi,
> >
> > This is a re-post of the patch I posted for comments in January to
> > address http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18589.  The patch
> > modifies reassociation to expose repeated factors from __builtin_pow*
> > calls, optimally reassociate repeated factors, and possibly reconstitute
> > __builtin_powi calls from the results of reassociation.
> >
> > Bootstrapped and passes regression tests for powerpc64-linux-gnu.  I
> > expect there may need to be some small changes, but I am targeting this
> > for trunk approval.
> >
> > Thanks very much for the review,
> 
> Hmm.  How much work would it be to extend the reassoc 'IL' to allow
> a repeat factor per op?  I realize what you do is all within what reassoc
> already does though ideally we would not require any GIMPLE IL changes
> for building up / optimizing the reassoc IL but only do so when we commit
> changes.
> 
> Thanks,
> Richard.

Hi Richard,

I've revised my patch along these lines; see the new version below.
While testing it I realized I could do a better job of reducing the
number of multiplies, so there are some changes to that logic as well,
and a couple of additional test cases.  Regstrapped successfully on
powerpc64-linux.

Hope this looks better!

Thanks,
Bill


gcc:

2012-04-03  Bill Schmidt  

PR tree-optimization/18589
* tree-pass.h: Replace pass_reassoc with pass_early_reassoc and
pass_late_reassoc.
* passes.c (init_optimization_passes): Change pass_reassoc calls to
pass_early_reassoc and pass_late_reassoc.
* tree-ssa-reassoc.c (reassociate_stats): Add two fields.
(operand_entry): Add count field.
(early_reassoc): New static var.
(add_repeat_to_ops_vec): New function.
(completely_remove_stmt): Likewise.
(remove_def_if_absorbed_call): Likewise.
(remove_visited_stmt_chain): Remove feeding builtin pow/powi calls.
(acceptable_pow_call): New function.
(linearize_expr_tree): Look for builtin pow/powi calls and add operand
entries with repeat counts when found.
(repeat_factor_d): New struct and associated typedefs.
(repeat_factor_vec): New static vector variable.
(compare_repeat_factors): New function.
(get_reassoc_pow_ssa_name): Likewise.
(attempt_builtin_powi): Likewise.
(reassociate_bb): Attempt to create __builtin_powi calls, and multiply
their results by any leftover reassociated factors; remove builtin
pow/powi calls that were absorbed by reassociation.
(fini_reassoc): Two new calls to statistics_counter_event.
(execute_early_reassoc): New function.
(execute_late_reassoc): Likewise.
(pass_early_reassoc): Replace pass_reassoc, renamed to reassoc1,
call execute_early_reassoc.
(pass_late_reassoc): New gimple_opt_pass named reassoc2 that calls
execute_late_reassoc.

gcc/testsuite:

2012-04-03  Bill Schmidt  

PR tree-optimization/18589
* gcc.dg/pr46309.c: Change -fdump-tree-reassoc-details to
-fdump-tree-reassoc[12]-details.
* gcc.dg/tree-ssa/pr18589-1.c: New test.
* gcc.dg/tree-ssa/pr18589-2.c: Likewise.
* gcc.dg/tree-ssa/pr18589-3.c: Likewise.
* gcc.dg/tree-ssa/pr18589-4.c: Likewise.
* gcc.dg/tree-ssa/pr18589-5.c: Likewise.
* gcc.dg/tree-ssa/pr18589-6.c: Likewise.
* gcc.dg/tree-ssa/pr18589-7.c: Likewise.
* gcc.dg/tree-ssa/pr18589-8.c: Likewise.
* gcc.dg/tree-ssa/pr18589-9.c: Likewise.
* gcc.dg/tree-ssa/pr18589-10.c: Likewise.


Index: gcc/tree-pass.h
===
--- gcc/tree-pass.h (revision 186108)
+++ gcc/tree-pass.h (working copy)
@@ -441,7 +441,8 @@ extern struct gimple_opt_pass pass_copy_prop;
 extern struct gimple_opt_pass pass_vrp;
 extern struct gimple_opt_pass pass_uncprop;
 extern struct gimple_opt_pass pass_return_slot;
-extern struct gimple_opt_pass pass_reassoc;
+extern struct gimple_opt_pass pass_early_reassoc;
+extern struct gimple_opt_pass pass_late_reassoc;
 extern struct gimple_opt_pass pass_rebuild_cgraph_edges;
 extern struct gimple_opt_pass pass_remove_cgraph_callee_edges;
 extern struct gimple_opt_pass pass_build_cgraph_edges;
Index: gcc/testsuite/gcc.dg/pr46309.c
===
--- gcc/testsuite/gcc.dg/pr46309.c  (revision 186108)
+++ gcc/testsuite/gcc.dg/pr46309.c  (working copy)
@@ -1,6 +1,6 @@
 /* PR tree-optimization/46309 */
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-reassoc-details" } */
+/* { dg-options "-O2 -fdump-tree-reassoc1-details 
-fdump-tree-reassoc2-details" } */
 /* The transformation depends on BRANCH_COST being greater than 1
(see the notes in the PR), so try to force that.  */
 

Re: [C Patch]: pr52543

[Ian Lance Taylor]

Richard Sandiford  writes:

> Does anyone else have any thoughts before I make that change?

I think that one of you should try to write a test case where it makes a
difference, and add the test case to the testsuite.

Ian

Re: [PATCH, i386, Android] -mandroid support for i386 target

[Ilya Enkovich]

> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich  wrote:
>>> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>>
>
> The point is that one can build a toolchain for i686-linux-gnu that will 
> support both 32-bit and 64-bit multilibs.  The 32-bit multilib will be 
> used by default, and compilation for 64-bit user-space can be requested 
> with -m64 option.  Even though Android is not supported for -m64, such a 
> toolchain can support Android as a additional "-m32 -mandroid" multilib.  
> I.e., the toolchain will have three multilibs in total: "-m32" (default), 
> "-m64" and "-m32 -mandroid".  I386/linux64.h will be picked up for such a 
> toolchain, even though by default it would compile for 32-bit target.  
> Does this clear up things?
>

 I think I see your point. And it seems to make all this work I'll also
 have to rename i386/gnu-user.h into i386/gnu-user32.h and create
 i386/gnu-user.h with common definitions to be included by
 gnu-user[32|64].h. Otherwise I wont be able to use some definitions
 (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in
 linux64.h. Right?
>>>
>>> It's simpler that you think.  The target headers ($tm_file in config.gcc -- 
>>> gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which 
>>> serves as proxy to all those headers.  All definitions made in preceding 
>>> headers are available in subsequent headers.  So, given that 
>>> i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only 
>>> need to touch linux*.h.
>>>
>>> Thanks,
>>>
>>> --
>>> Maxim Kuvyrkov
>>> CodeSourcery / Mentor Graphics
>>>
>>
>>
>> Hi,
>>
>> I prepared version with common linux.h and gnu-user.h. Does it look OK?
>>
>> Bootstrapped and checked on linux-x86_64.
>>
>
> There are so many duplicates in gnu-user64.h and gnu-user32.h.
> Please move all of them to gnu-user.h.
>
> Thanks.
>
> --
> H.J.

Hi,

Here is a new version with all gnu-user32.h and gnu-user64.h common
definitions moved to gnu-user.h.

Bootstrapped and checked on linux-x86_64.

Thanks,
Ilya
---
2012-04-04  Enkovich Ilya  

* config/i386/linux.h: Renamed to ...
* config/i386/linux32.h: ... this.

* config/i386/gnu-user.h: Renamed to ...
* config/i386/gnu-user32.h: ... this.
(CPP_SPEC): Removed.
(CC1_SPEC): Removed.
(ENDFILE_SPEC): Removed.
(DEFAULT_PCC_STRUCT_RETURN): Removed.
(TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed.
(TARGET_OS_CPP_BUILTINS): Removed.
(LIBGCC2_HAS_TF_MODE): Removed.
(LIBGCC2_TF_CEXT): Removed.
(TF_SIZE): Removed.
(TARGET_ASM_FILE_END): Removed.
(STACK_CHECK_MOVING_SP): Removed.
(STACK_CHECK_STATIC_BUILTIN): Removed.
(TARGET_THREAD_SSP_OFFSET): Removed.
(TARGET_CAN_SPLIT_STACK): Removed.
(TARGET_THREAD_SPLIT_STACK_OFFSET): Removed.
(GNU_USER_TARGET_LINK_SPEC): New.
(LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.

* config.gcc: Rename i386/linux.h to i386/linux32.h and
i386/gnu-user.h to i386/gnu-user32.h.

* config/i386/linux.h: New.

* config/i386/gnu-user.h: New.

* config/i386/linux64.h: Include i386/linux.h.

* config/i386/gnu-user64.h: Include i386/gnu-user.h
(CPP_SPEC): Removed.
(CC1_SPEC): Removed.
(ENDFILE_SPEC): Removed.
(DEFAULT_PCC_STRUCT_RETURN): Removed.
(TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed.
(TARGET_OS_CPP_BUILTINS): Removed.
(LIBGCC2_HAS_TF_MODE): Removed.
(LIBGCC2_TF_CEXT): Removed.
(TF_SIZE): Removed.
(TARGET_ASM_FILE_END): Removed.
(STACK_CHECK_MOVING_SP): Removed.
(STACK_CHECK_STATIC_BUILTIN): Removed.
(TARGET_THREAD_SSP_OFFSET): Removed.
(TARGET_CAN_SPLIT_STACK): Removed.
(TARGET_THREAD_SPLIT_STACK_OFFSET): Removed.
(GNU_USER_TARGET_LINK_SPEC): New.
(LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.


mandroid.patch
Description: Binary data

Re: [PATCH, i386, Android] -mandroid support for i386 target

[Ilya Enkovich]

> On 4/04/2012, at 2:56 AM, H.J. Lu wrote:
>
>> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich  wrote:

 It's simpler that you think.  The target headers ($tm_file in config.gcc 
 -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, 
 which serves as proxy to all those headers.  All definitions made in 
 preceding headers are available in subsequent headers.  So, given that 
 i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only 
 need to touch linux*.h.

 Thanks,

 --
 Maxim Kuvyrkov
 CodeSourcery / Mentor Graphics

>>>
>>>
>>> Hi,
>>>
>>> I prepared version with common linux.h and gnu-user.h. Does it look OK?
>>>
>>> Bootstrapped and checked on linux-x86_64.
>>>
>>
>> There are so many duplicates in gnu-user64.h and gnu-user32.h.
>> Please move all of them to gnu-user.h.
>
> Ilya,
>
> Why i386/gnu-user.h had to change at all?  It seems like you trying to clean 
> up/simplify stuff in i386/gnu-user.h, but in this case it seems (a) not 
> required for the main purpose of this submission, and (b) excessive.

Hi,

Initially my patch introduced few macroses in i386/gnu-user.h to use
them in i386/linux.h. After I created new i386/linux.h and included it
into i386/linux64.h I got a build failure because new i386/linux.h
used these new definition from i386/gnu-user.h and only
i386/gnu-user64.h was included into tm.h. So, I renamed
i386/gnu-user.h into i386/gnu-user32.h and created new i386/gnu-user.h
with these missing definitions. Otherwise I would have to copy all
changes made in i386/gnu-user.h to i386/gnu-user64.h.

Thanks,
Ilya

>
> As a side note, if it were up to me, I would merge current i386/linux.h and 
> i386/linux64.h into one file -- i386/linux.h -- instead of having similar 
> definitions spread around.  But that would be a clean up in itself, and would 
> require a separate submission.
>
> Thank you,
>
> --
> Maxim Kuvyrkov
> CodeSourcery / Mentor Graphics
>

Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)

[Mike Stump]

On Apr 3, 2012, at 12:57 PM, DJ Delorie wrote:
>> Did you ever dig up the Apple test cases from the APPLE LOCAL work I
>> pointed you at earlier?
> 
> Sorry, I read that as "the internal tree at Apple" not "the apple
> branch at fsf".  I'll look at it, thanks!

Oh, I just checked the llvm-gcc-4.2 tree, which should have all the work in it, 
no testcases...  Arg, never mind...  sorry.

[Patch, Fortran] PRs 52751/40973 - don't set TREE_PUBLIC for PRIVATE module procs/vars

[Tobias Burnus]

Dear all,

the attached patch only sets TREE_PUBLIC for module variables and module 
procedures which have neither the PRIVATE attribute nor a C-binding 
label. Seemingly, only NAG f95 does this for module variables and none 
of my compilers does this for module procedures.


The main effect of this patch is a code size reduction as the compiler 
might (even without -fwhole-program -flto) optimize unused 
variables/procedures away. Additionally, the compiler might inline code 
which it otherwise wouldn't do (due to the code size increase) or do 
optimizations based on the value of the module variables (though, GCC 
has room for improvement for optimizing static variables.)


Note: For C-binding variables without binding label ("bind(C, 
name='')"), I don't use DECL_COMMON. That should be okay as DECL_COMMON 
is only used to make sure that a variable can be initialized from either 
C or Fortran. But without binding name, that's not possible from C, 
hence, that's fine.


Build and regtested on x86-64-linux. (And currently regtesting again - 
after a minor modification.)

OK for the trunk?

Tobias

2012-04-03  Tobias Burnus  

	PR fortran/52751
	* trans-decl.c (gfc_finish_var_decl): Don't set TREE_PUBLIC
	for PRIVATE module variables without C-binding label.

	PR fortran/40973
	* trans-decl.c (build_function_decl): Ditto for procedures.

2012-04-03  Tobias Burnus  

	PR fortran/40973
	PR fortran/52751
	* gfortran.dg/public_private_module_2.f90: New.

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 8a1dd2e..23cf052 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -539,7 +539,7 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
   if (sym->attr.cray_pointee)
 return;
 
-  if(sym->attr.is_bind_c == 1)
+  if(sym->attr.is_bind_c == 1 && sym->binding_label)
 {
   /* We need to put variables that are bind(c) into the common
 	 segment of the object file, because this is what C would do.
@@ -565,7 +565,8 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
   /* TODO: Don't set sym->module for result or dummy variables.  */
   gcc_assert (current_function_decl == NULL_TREE || sym->result == sym);
   /* This is the declaration of a module variable.  */
-  TREE_PUBLIC (decl) = 1;
+  if (sym->attr.access != ACCESS_PRIVATE)
+	TREE_PUBLIC (decl) = 1;
   TREE_STATIC (decl) = 1;
 }
 
@@ -1842,7 +1857,8 @@ build_function_decl (gfc_symbol * sym, bool global)
   DECL_EXTERNAL (fndecl) = 0;
 
   if (!current_function_decl
-  && !sym->attr.entry_master && !sym->attr.is_main_program)
+  && !sym->attr.entry_master && !sym->attr.is_main_program
+  && (sym->attr.access != ACCESS_PRIVATE || sym->binding_label))
 TREE_PUBLIC (fndecl) = 1;
 
   attributes = add_attributes_to_decl (attr, NULL_TREE);

--- /dev/null	2012-03-22 21:06:43.387787737 +0100
+++ gcc/gcc/testsuite/gfortran.dg/public_private_module_2.f90	2012-04-03 23:02:59.0 +0200
@@ -0,0 +1,70 @@
+! { dg-do compile }
+! { dg-options "-O2" }
+!
+! PR fortran/52751 (top, "module mod")
+! PR fortran/40973 (bottom, "module m"
+!
+! Ensure that (only) those module variables and procedures which are PRIVATE
+! and have no C-binding label are optimized away.
+!
+  module mod
+integer :: aa
+integer, private :: iii
+integer, private, bind(C) :: jj ! { dg-warning "PRIVATE but has been given the binding label" }
+integer, private, bind(C,name='lll') :: kk  ! { dg-warning "PRIVATE but has been given the binding label" }
+integer, private, bind(C,name='') :: 
+integer, bind(C) :: nnn
+integer, bind(C,name='oo') :: pp
+integer, bind(C,name='') :: qq
+  end module mod
+
+  ! { dg-final { scan-assembler "__mod_MOD_aa" } }
+  ! { dg-final { scan-assembler-not "iii" } }
+  ! { dg-final { scan-assembler "jj" } }
+  ! { dg-final { scan-assembler "lll" } }
+  ! { dg-final { scan-assembler-not "kk" } }
+  ! { dg-final { scan-assembler-not "" } }
+  ! { dg-final { scan-assembler "nnn" } }
+  ! { dg-final { scan-assembler "oo" } }
+  ! { dg-final { scan-assembler "__mod_MOD_qq" } }
+
+MODULE M
+  PRIVATE :: two, three, four, six
+  PUBLIC :: one, seven, eight, ten
+CONTAINS
+  SUBROUTINE one(a)
+integer :: a
+a = two()
+  END SUBROUTINE one
+  integer FUNCTION two()
+ two = 42
+  END FUNCTION two
+  integer FUNCTION three() bind(C) ! { dg-warning "PRIVATE but has been given the binding label" }
+ three = 43
+  END FUNCTION three
+  integer FUNCTION four() bind(C, name='five') ! { dg-warning "PRIVATE but has been given the binding label" }
+ four = 44
+  END FUNCTION four
+  integer FUNCTION six() bind(C, name='')
+ six = 46
+  END FUNCTION six
+  integer FUNCTION seven() bind(C)
+ seven = 46
+  END FUNCTION seven
+  integer FUNCTION eight() bind(C, name='nine')
+ eight = 48
+  END FUNCTION eight
+  integer FUNCTION ten() bind(C, nam

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

On 4 April 2012 04:17, Andrew Haley  wrote:
> On 04/03/2012 05:09 PM, Richard Earnshaw wrote:
>> On 03/04/12 12:01, Jakub Jelinek wrote:
>>> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
 If, so then there's only one way to sort out this mess.

 /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
 /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
>>>
>>> The above scheme is a Debianism which no other distro is using.
>>>
>>>      Jakub
>>>
>>
>> Not really, it's just a naming convention for where the config-specific
>> dynamic loader lives.  It doesn't affect where the remaining shared
>> libraries live.
>>
>> The subdirectories could be called fred and jim and it would still work.
>>  The only thing required is that this part of the naming scheme be
>> agreed amongst the distros.
>>
>> This looks to me like it's turning into a bike-shed painting excerise
>> between the distros out there.  That's really sad.
>
> I don't think we ever even had the discussion: Debian invented their
> Debian-internal scheme for managing multiple ABIs.  They have in the past
> used patched versions of gcc, as in the case of x86_64.

(cc'ed cross-distro as the discussion is also going on there[1].  This
patch continues that)

I like the idea of incompatible binaries having different loaders.
The path doesn't matter but the concept does.  Like i686/x86_64, it
gives distros the option to install different binaries alongside each
other for compatibility, performance, or upgrade reasons.  The
compatibility cost is nice and low and lets Debian do some interesting
cross development things.

No one has released a hard float based distro yet.  We have time to
discuss and fix this so we don't get in the crazy situation where a
third party binary only runs on some distros.

-- Michael

[1] http://lists.linaro.org/pipermail/cross-distro/2012-March/000135.html
and http://lists.linaro.org/pipermail/cross-distro/2012-April/thread.html

[SH] PR50751 - rework displacement calculations pt. 2

[Oleg Endo]

Hi,

The attached patch restructures the move insn displacement calculations
a bit more.  The idea is to have the displacement addressing decision
making logic in a few simple functions and then re-use those in other
places, as opposed to having multiple special cases.

Tested against rev 185893 with...
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a-single/-mb,
-m4-single/-ml,-m4-single/-mb,
-m4a-single/-ml,-m4a-single/-mb}"

...and no new failures.

I've also checked the CSiBE size results for a bunch of variants.  There
is a slight overall code size increase, with a maximum of +0.03% on the
whole set for -m2 -ml/-mb -Os/-O2) due to some changes on how DImode
index range decisions are made.

OK?

Cheers,
Oleg

ChangeLog:

PR target/50751
* config/sh/sh.c (sh_find_mov_disp_adjust): Take machine_mode as
first argument instead of mode size.  Move displacement
calculations to...
(mov_insn_size, max_mov_insn_displacement,
mov_insn_alignment_mask): ...these new functions.
(disp_adjust): Remove max_mov_disp field.
(sh_legitimate_index_p): Use max_mov_insn_displacement and
mov_insn_alignment_mask.
(sh_address_cost): Use max_mov_insn_displacement.
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 185894)
+++ gcc/config/sh/sh.c	(working copy)
@@ -302,6 +302,9 @@
 static rtx sh_trampoline_adjust_address (rtx);
 static void sh_conditional_register_usage (void);
 static bool sh_legitimate_constant_p (enum machine_mode, rtx);
+static int mov_insn_size (enum machine_mode, bool);
+static int max_mov_insn_displacement (enum machine_mode, bool);
+static int mov_insn_alignment_mask (enum machine_mode, bool);
 
 static void sh_init_sync_libfuncs (void) ATTRIBUTE_UNUSED;
 
@@ -3129,24 +3132,105 @@
 }
 }
 
-/* Compute the cost of an address.  For the SH, all valid addresses are
-   the same cost.  Use a slightly higher cost for reg + reg addressing,
-   since it increases pressure on r0.  */
+/* Determine the size of the fundamental move insn that will be used
+   for the specified mode.  */
 
+static inline int
+mov_insn_size (enum machine_mode mode, bool consider_sh2a)
+{
+  const int mode_sz = GET_MODE_SIZE (mode);
+
+  if ((consider_sh2a && TARGET_SH2A_DOUBLE && mode == DFmode)
+  || (TARGET_FMOVD && mode == DFmode))
+return mode_sz;
+  else
+{
+  /* The max. available mode for actual move insns is SImode.
+	 Larger accesses will be split into multiple loads/stores.  */
+  const int max_mov_sz = GET_MODE_SIZE (SImode);
+  return mode_sz >= max_mov_sz ? max_mov_sz : mode_sz;
+}
+}
+
+/* Determine the maximum possible displacement for a move insn for the
+   specified mode.  */
+
 static int
-sh_address_cost (rtx X,
-	 bool speed ATTRIBUTE_UNUSED)
+max_mov_insn_displacement (enum machine_mode mode, bool consider_sh2a)
 {
-  /*  SH2A supports 4 byte displacement mov insns with higher offsets.
-  Consider those as more expensive than 2 byte insns.  */
-  if (DISP_ADDR_P (X) && GET_MODE (X) == QImode)
-return DISP_ADDR_OFFSET (X) < 16 ? 0 : 1;
+  /* The 4 byte displacement move insns are the same as the 2 byte
+ versions but take a 12 bit displacement.  All we need to do is to
+ scale the max. displacement value accordingly.  */
+  const int disp_scale = consider_sh2a ? (4095 / 15) : 1;
 
-  return (GET_CODE (X) == PLUS
-	  && ! CONSTANT_P (XEXP (X, 1))
-	  && ! TARGET_SHMEDIA ? 1 : 0);
+  /* FIXME: HImode with displacement addressing is not supported yet.
+ Make it purposefully fail for now.  */
+  if (mode == HImode)
+return 0;
+
+  /* SH2A supports FPU move insns with 12 bit displacements.
+ Other variants to do not support any kind of displacements for
+ FPU move insns.  */
+  if (! consider_sh2a && TARGET_FPU_ANY && GET_MODE_CLASS (mode) == MODE_FLOAT)
+return 0;
+  else
+{
+  const int mov_insn_sz = mov_insn_size (mode, consider_sh2a);
+  const int mode_sz = GET_MODE_SIZE (mode);
+  int r = 15 * mov_insn_sz * disp_scale;
+
+  /* If the mov insn will be split into multiple loads/stores, the
+	 maximum possible displacement is a bit smaller.  */
+  if (mode_sz > mov_insn_sz)
+	r -= mode_sz - mov_insn_sz;
+  return r;
+}
 }
 
+/* Determine the alignment mask for a move insn of the
+   specified mode.  */
+
+static inline int
+mov_insn_alignment_mask (enum machine_mode mode, bool consider_sh2a)
+{
+  const int mov_insn_sz = mov_insn_size (mode, consider_sh2a);
+  return mov_insn_sz > 0 ? (mov_insn_sz - 1) : 0;
+}
+
+/* Compute the cost of an address.  */
+
+static int
+sh_address_cost (rtx x, bool speed ATTRIBUTE_UNUSED)
+{
+  /* 'reg + disp' addressing.  */
+  if (DISP_ADDR_P (x))
+{
+  const HOST_WIDE_INT offset = DISP_ADDR_OFFSET (x);
+  const enum machine_mode mode = GET_MODE (x);
+
+  /* The displacement would fit 

Re: [PATCH] SH: Fix m2a-single-only compilation error

[Kaz Kojima]

I've just committed the patch in
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01970.html
on trunk.

Regards,
kaz

C++ PATCH for c++/52796 (missed value-initialization with variadic templates)

[Jason Merrill]

A parenthesized initializer containing a pack expansion that expands to 
0 elements is treated as value-initialization.  We were handling that 
properly for variable initializers, but not for mem-initializers in 
constructors.


Tested x86_64-pc-linux-gnu, applying to trunk, 4.7 and 4.6.
commit 58c6706693964e81e846905cdd747a4aec015d09
Author: Jason Merrill 
Date:   Tue Apr 3 15:31:39 2012 -0400

	PR c++/52796
	* pt.c (tsubst_initializer_list): A pack expansion with no elements
	means value-initialization.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index aabe477..03acd5b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19470,6 +19470,7 @@ tsubst_initializer_list (tree t, tree argvec)
 }
   else
 {
+	  tree tmp;
   decl = tsubst_copy (TREE_PURPOSE (t), argvec, 
   tf_warning_or_error, NULL_TREE);
 
@@ -19478,10 +19479,17 @@ tsubst_initializer_list (tree t, tree argvec)
 in_base_initializer = 1;
 
 	  init = TREE_VALUE (t);
+	  tmp = init;
 	  if (init != void_type_node)
 		init = tsubst_expr (init, argvec,
 tf_warning_or_error, NULL_TREE,
 /*integral_constant_expression_p=*/false);
+	  if (init == NULL_TREE && tmp != NULL_TREE)
+		/* If we had an initializer but it instantiated to nothing,
+		   value-initialize the object.  This will only occur when
+		   the initializer was a pack expansion where the parameter
+		   packs used in that expansion were of length zero.  */
+		init = void_type_node;
   in_base_initializer = 0;
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-value1.C b/gcc/testsuite/g++.dg/cpp0x/variadic-value1.C
new file mode 100644
index 000..179919a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-value1.C
@@ -0,0 +1,24 @@
+// PR c++/52796
+// { dg-do run { target c++11 } }
+
+inline void *operator new(__SIZE_TYPE__ s, void *p) { return p; }
+
+struct A
+{
+  int i;
+  template
+  A(Ts&&... ts): i(ts...) { }
+};
+
+static union {
+  unsigned char c[sizeof(A)];
+  int i;
+};
+
+int main()
+{
+  i = 0xdeadbeef;
+  new(c) A;
+  if (i != 0)
+__builtin_abort();
+}

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Joseph S. Myers]

On Tue, 3 Apr 2012, Michael Hope wrote:

> +#define GLIBC_DYNAMIC_LINKER \
> +   "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +%{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"

(a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to 
be handled in specs.

(b) You need to handle compilers configured with --with-float=hard, so 
make the specs depend on the default ABI the compiler was configured with.

(c) Please include libc-ports on future submissions and provide both the 
GCC patch and the glibc ports patch that have been tested to work together 
to build and install the library in the given path; a patch to one 
component like this cannot sensibly be considered in isolation.  I imagine 
you'll need appropriate ARM preconfigure support to detect what ABI the 
compiler is using, much like the support for MIPS, so that the right 
shlib-versions files are used.  I try to follow all ARM glibc discussions 
on libc-ports closely, as the ARM glibc maintainer; was there a previous 
discussion of the dynamic linker naming issue there that I missed?  (The 
only previous relevant discussion that I recall is one on 
patc...@eglibc.org starting at 
, regarding how the 
dynamic linker should check that a library has the right ABI, and there 
was no real followup on that after I indicated what would seem to be the 
appropriate implementation approaches and places for subsequent 
discussion.)

I have no idea whether shlib-versions files naming a file in a 
subdirectory will work - but if not, you'd need to send a patch to 
libc-alpha to support dynamic linkers in subdirectories, with appropriate 
justification for why you are doing something different from all other 
architectures.

(d) Existing practice for Power Architecture and MIPS at least is that 
hard-float and soft-float *don't* use different library directories / 
dynamic linkers.

(e) Existing practice for cases that do use different dynamic linkers is 
to use a separate library directory, not just dynamic linker name, as in 
lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to 
make two sets of libraries work in parallel if you have separate library 
directories like that.  So it would seem more appropriate to define a 
directory libhf for ARM (meaning you need a binutils patch as well to 
handle that directory, I think), and these different Debian-style names 
could be implemented separately in a multiarch patch if someone submits 
one that properly accounts for my review comments on previous patch 
versions (failure to produce such a fixed patch being why Debian multiarch 
directory support has not got into GCC so far).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jakub Jelinek]

On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
> >> The subdirectories could be called fred and jim and it would still work.
> >>  The only thing required is that this part of the naming scheme be
> >> agreed amongst the distros.
> >>
> >> This looks to me like it's turning into a bike-shed painting excerise
> >> between the distros out there.  That's really sad.
> >
> > I don't think we ever even had the discussion: Debian invented their
> > Debian-internal scheme for managing multiple ABIs.  They have in the past
> > used patched versions of gcc, as in the case of x86_64.
> 
> (cc'ed cross-distro as the discussion is also going on there[1].  This
> patch continues that)
> 
> I like the idea of incompatible binaries having different loaders.
> The path doesn't matter but the concept does.  Like i686/x86_64, it
> gives distros the option to install different binaries alongside each
> other for compatibility, performance, or upgrade reasons.  The
> compatibility cost is nice and low and lets Debian do some interesting
> cross development things.

Does the dynamic linker itself contain any routines that depend on the
soft/hard ABI?  That would quite surprise me, so I don't see the point of
having different dynamic linkers for those ABIs.  One dynamic linker should
handle both just fine.

> No one has released a hard float based distro yet.  We have time to
> discuss and fix this so we don't get in the crazy situation where a
> third party binary only runs on some distros.

Isn't e.g. Fedora 17/armv7hl a hard float based distro?

Jakub

[patch] Fix PR52822 (stable_partition move-assigns object to itself) in trunk, 4.7, and 4.6

[Jeffrey Yasskin]

The attached patches fix http://gcc.gnu.org/PR52822, and have been
tested with `make check-c++` on linux-x86_64. The trunk patch applies
and tests cleanly on gcc-4_7-branch. The gcc-4_6-branch patch is
significantly simpler, as Paolo suggested on the bug.

The test is still inadequate, but given that there's no way to force
get_temporary_buffer to return a short buffer, I'm not sure how to
improve it. It might be possible to use set_memory_limits(), but that
would require a very complex test program to make sure exactly the
right operator new call fails.

Jeffrey Yasskin


pr52822_trunk.patch
Description: Binary data


pr52822_gcc46.patch
Description: Binary data

libgo patch committed: Fix GNU/Linux netlink code for big-endian

[Ian Lance Taylor]

This patch to libgo fixes the support for GNU/Linux netlink code, used
to retrieve network interfaces, for big-endian systems.  Bootstrapped
and ran Go testsuite on x86_64-unknown-linux-gnu.  Committed to
mainline and 4.7 branch.

Ian

diff -r a2de1f2e5bf8 libgo/Makefile.am
--- a/libgo/Makefile.am	Tue Apr 03 12:36:26 2012 -0700
+++ b/libgo/Makefile.am	Tue Apr 03 16:41:49 2012 -0700
@@ -1559,6 +1559,7 @@
 	echo "package syscall" > syscall_arch.go.tmp
 	echo 'const ARCH = "'$(GOARCH)'"' >> syscall_arch.go.tmp
 	echo 'const OS = "'$(GOOS)'"' >> syscall_arch.go.tmp
+	echo 'const BigEndian = $(GO_BIGENDIAN)' >> syscall_arch.go.tmp
 	$(SHELL) $(srcdir)/../move-if-change syscall_arch.go.tmp syscall_arch.go
 	$(STAMP) $@
 
diff -r a2de1f2e5bf8 libgo/configure.ac
--- a/libgo/configure.ac	Tue Apr 03 12:36:26 2012 -0700
+++ b/libgo/configure.ac	Tue Apr 03 16:41:49 2012 -0700
@@ -400,6 +400,12 @@
 AC_SEARCH_LIBS([sched_yield], [rt])
 
 AC_C_BIGENDIAN
+case $ac_cv_c_bigendian in
+  yes) GO_BIGENDIAN=true ;;
+  no) GO_BIGENDIAN=false ;;
+  *) AC_MSG_ERROR([unknown endianness]) ;;
+esac
+AC_SUBST(GO_BIGENDIAN)
 
 GCC_CHECK_UNWIND_GETIPINFO
 
diff -r a2de1f2e5bf8 libgo/go/net/interface_linux.go
--- a/libgo/go/net/interface_linux.go	Tue Apr 03 12:36:26 2012 -0700
+++ b/libgo/go/net/interface_linux.go	Tue Apr 03 16:41:49 2012 -0700
@@ -64,7 +64,11 @@
 		case syscall.IFLA_IFNAME:
 			ifi.Name = string(a.Value[:len(a.Value)-1])
 		case syscall.IFLA_MTU:
-			ifi.MTU = int(uint32(a.Value[3])<<24 | uint32(a.Value[2])<<16 | uint32(a.Value[1])<<8 | uint32(a.Value[0]))
+			if syscall.BigEndian {
+ifi.MTU = int(uint32(a.Value[0])<<24 | uint32(a.Value[1])<<16 | uint32(a.Value[2])<<8 | uint32(a.Value[3]))
+			} else {
+ifi.MTU = int(uint32(a.Value[3])<<24 | uint32(a.Value[2])<<16 | uint32(a.Value[1])<<8 | uint32(a.Value[0]))
+			}
 		}
 	}
 	return ifi
@@ -196,7 +200,12 @@
 for i := 0; i+1 < len(f[0]); i += 2 {
 	b[i/2], _ = xtoi2(f[0][i:i+2], 0)
 }
-ifma := IPAddr{IP: IPv4(b[3], b[2], b[1], b[0])}
+var ifma IPAddr
+if syscall.BigEndian {
+	ifma = IPAddr{IP: IPv4(b[0], b[1], b[2], b[3])}
+} else {
+	ifma = IPAddr{IP: IPv4(b[3], b[2], b[1], b[0])}
+}
 ifmat = append(ifmat, ifma.toAddr())
 			}
 		}
diff -r a2de1f2e5bf8 libgo/go/syscall/netlink_linux.go
--- a/libgo/go/syscall/netlink_linux.go	Tue Apr 03 12:36:26 2012 -0700
+++ b/libgo/go/syscall/netlink_linux.go	Tue Apr 03 16:41:49 2012 -0700
@@ -30,23 +30,43 @@
 
 func (rr *NetlinkRouteRequest) toWireFormat() []byte {
 	b := make([]byte, rr.Header.Len)
-	b[0] = byte(rr.Header.Len)
-	b[1] = byte(rr.Header.Len >> 8)
-	b[2] = byte(rr.Header.Len >> 16)
-	b[3] = byte(rr.Header.Len >> 24)
-	b[4] = byte(rr.Header.Type)
-	b[5] = byte(rr.Header.Type >> 8)
-	b[6] = byte(rr.Header.Flags)
-	b[7] = byte(rr.Header.Flags >> 8)
-	b[8] = byte(rr.Header.Seq)
-	b[9] = byte(rr.Header.Seq >> 8)
-	b[10] = byte(rr.Header.Seq >> 16)
-	b[11] = byte(rr.Header.Seq >> 24)
-	b[12] = byte(rr.Header.Pid)
-	b[13] = byte(rr.Header.Pid >> 8)
-	b[14] = byte(rr.Header.Pid >> 16)
-	b[15] = byte(rr.Header.Pid >> 24)
-	b[16] = byte(rr.Data.Family)
+	if BigEndian {
+		b[0] = byte(rr.Header.Len >> 24)
+		b[1] = byte(rr.Header.Len >> 16)
+		b[2] = byte(rr.Header.Len >> 8)
+		b[3] = byte(rr.Header.Len)
+		b[4] = byte(rr.Header.Type >> 8)
+		b[5] = byte(rr.Header.Type)
+		b[6] = byte(rr.Header.Flags >> 8)
+		b[7] = byte(rr.Header.Flags)
+		b[8] = byte(rr.Header.Seq >> 24)
+		b[9] = byte(rr.Header.Seq >> 16)
+		b[10] = byte(rr.Header.Seq >> 8)
+		b[11] = byte(rr.Header.Seq)
+		b[12] = byte(rr.Header.Pid >> 24)
+		b[13] = byte(rr.Header.Pid >> 16)
+		b[14] = byte(rr.Header.Pid >> 8)
+		b[15] = byte(rr.Header.Pid)
+		b[16] = byte(rr.Data.Family)
+	} else {
+		b[0] = byte(rr.Header.Len)
+		b[1] = byte(rr.Header.Len >> 8)
+		b[2] = byte(rr.Header.Len >> 16)
+		b[3] = byte(rr.Header.Len >> 24)
+		b[4] = byte(rr.Header.Type)
+		b[5] = byte(rr.Header.Type >> 8)
+		b[6] = byte(rr.Header.Flags)
+		b[7] = byte(rr.Header.Flags >> 8)
+		b[8] = byte(rr.Header.Seq)
+		b[9] = byte(rr.Header.Seq >> 8)
+		b[10] = byte(rr.Header.Seq >> 16)
+		b[11] = byte(rr.Header.Seq >> 24)
+		b[12] = byte(rr.Header.Pid)
+		b[13] = byte(rr.Header.Pid >> 8)
+		b[14] = byte(rr.Header.Pid >> 16)
+		b[15] = byte(rr.Header.Pid >> 24)
+		b[16] = byte(rr.Data.Family)
+	}
 	return b
 }
 

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

On 4 April 2012 11:11, Jakub Jelinek  wrote:
> On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>> >> The subdirectories could be called fred and jim and it would still work.
>> >>  The only thing required is that this part of the naming scheme be
>> >> agreed amongst the distros.
>> >>
>> >> This looks to me like it's turning into a bike-shed painting excerise
>> >> between the distros out there.  That's really sad.
>> >
>> > I don't think we ever even had the discussion: Debian invented their
>> > Debian-internal scheme for managing multiple ABIs.  They have in the past
>> > used patched versions of gcc, as in the case of x86_64.
>>
>> (cc'ed cross-distro as the discussion is also going on there[1].  This
>> patch continues that)
>>
>> I like the idea of incompatible binaries having different loaders.
>> The path doesn't matter but the concept does.  Like i686/x86_64, it
>> gives distros the option to install different binaries alongside each
>> other for compatibility, performance, or upgrade reasons.  The
>> compatibility cost is nice and low and lets Debian do some interesting
>> cross development things.
>
> Does the dynamic linker itself contain any routines that depend on the
> soft/hard ABI?  That would quite surprise me, so I don't see the point of
> having different dynamic linkers for those ABIs.  One dynamic linker should
> handle both just fine.
>
>> No one has released a hard float based distro yet.  We have time to
>> discuss and fix this so we don't get in the crazy situation where a
>> third party binary only runs on some distros.
>
> Isn't e.g. Fedora 17/armv7hl a hard float based distro?

Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo.
None have been released yet.  Here's my understanding:

Fedora 17:
 * ARM is a secondary architecture
 * Alpha 1 release is out
 * Has both a ARMv5 soft float and ARMv7 hard float build

Ubuntu Precise:
 * ARM is a primary architecture
 * Beta 2 is out
 * ARMv7 hard float by default with ARMv7 softfp being community supported

Debian:
 * ARM is a primary architecture
 * Has a ARMv4T soft float and in-development ARMv7 hard float

openSUSE:
 * Kicked off at a hackfest in September 2011
 * Have a ARMv5T soft float and ARMv7 hard float build

Gentoo:
 * I'm unsure (help?)
 * The Gentoo manual suggests ARMv7 softfp is the default

-- Michael

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Peter Robinson]

On Wed, Apr 4, 2012 at 12:48 AM, Michael Hope  wrote:
> On 4 April 2012 11:11, Jakub Jelinek  wrote:
>> On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>>> >> The subdirectories could be called fred and jim and it would still work.
>>> >>  The only thing required is that this part of the naming scheme be
>>> >> agreed amongst the distros.
>>> >>
>>> >> This looks to me like it's turning into a bike-shed painting excerise
>>> >> between the distros out there.  That's really sad.
>>> >
>>> > I don't think we ever even had the discussion: Debian invented their
>>> > Debian-internal scheme for managing multiple ABIs.  They have in the past
>>> > used patched versions of gcc, as in the case of x86_64.
>>>
>>> (cc'ed cross-distro as the discussion is also going on there[1].  This
>>> patch continues that)
>>>
>>> I like the idea of incompatible binaries having different loaders.
>>> The path doesn't matter but the concept does.  Like i686/x86_64, it
>>> gives distros the option to install different binaries alongside each
>>> other for compatibility, performance, or upgrade reasons.  The
>>> compatibility cost is nice and low and lets Debian do some interesting
>>> cross development things.
>>
>> Does the dynamic linker itself contain any routines that depend on the
>> soft/hard ABI?  That would quite surprise me, so I don't see the point of
>> having different dynamic linkers for those ABIs.  One dynamic linker should
>> handle both just fine.
>>
>>> No one has released a hard float based distro yet.  We have time to
>>> discuss and fix this so we don't get in the crazy situation where a
>>> third party binary only runs on some distros.
>>
>> Isn't e.g. Fedora 17/armv7hl a hard float based distro?
>
> Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo.
> None have been released yet.  Here's my understanding:
>
> Fedora 17:
>  * ARM is a secondary architecture
>  * Alpha 1 release is out
>  * Has both a ARMv5 soft float and ARMv7 hard float build

Beta isn't far off and we're working toward Primary Arch.

> Ubuntu Precise:
>  * ARM is a primary architecture
>  * Beta 2 is out
>  * ARMv7 hard float by default with ARMv7 softfp being community supported
>
> Debian:
>  * ARM is a primary architecture
>  * Has a ARMv4T soft float and in-development ARMv7 hard float
>
> openSUSE:
>  * Kicked off at a hackfest in September 2011
>  * Have a ARMv5T soft float and ARMv7 hard float build

Is only hard float, they haven't ruled out doing v5 soft float but
it's not their current focus.

Peter

[google] revert r185948

[Dehao Chen]

Revert r185948, which causes regression to major applications.

Bootstrapped.

OK for google-4_6?

Thanks,
Dehao

Index: gcc/testsuite/gcc.dg/predict-3.c
===
--- gcc/testsuite/gcc.dg/predict-3.c(revision 186128)
+++ gcc/testsuite/gcc.dg/predict-3.c(working copy)
@@ -10,16 +10,10 @@
   int i, ret = 0;
   for (i = 0; i <= bound; i++)
 {
-  if (i < bound - 2)
-   global += bar (i);
-  if (i <= bound)
-   global += bar (i);
-  if (i + 1 < bound)
-   global += bar (i);
   if (i != bound)
global += bar (i);
 }
 }

-/* { dg-final { scan-tree-dump-times "loop iv compare heuristics:
100.0%" 4 "profile_estimate"} } */
+/* { dg-final { scan-tree-dump "loop iv compare heuristics"
"profile_estimate"} } */
 /* { dg-final { cleanup-tree-dump "profile_estimate" } } */
Index: gcc/testsuite/gcc.dg/predict-4.c
===
--- gcc/testsuite/gcc.dg/predict-4.c(revision 186128)
+++ gcc/testsuite/gcc.dg/predict-4.c(working copy)
@@ -15,5 +15,5 @@
 }
 }

-/* { dg-final { scan-tree-dump "loop iv compare heuristics: 50.0%"
"profile_estimate"} } */
+/* { dg-final { scan-tree-dump "loop iv compare heuristics"
"profile_estimate"} } */
 /* { dg-final { cleanup-tree-dump "profile_estimate" } } */
Index: gcc/testsuite/gcc.dg/predict-1.c
===
--- gcc/testsuite/gcc.dg/predict-1.c(revision 186128)
+++ gcc/testsuite/gcc.dg/predict-1.c(working copy)
@@ -10,18 +10,10 @@
   int i, ret = 0;
   for (i = 0; i < bound; i++)
 {
-  if (i > bound)
-   global += bar (i);
-  if (i >= bound + 2)
-   global += bar (i);
   if (i > bound - 2)
global += bar (i);
-  if (i + 2 > bound)
-   global += bar (i);
-  if (i == 10)
-   global += bar (i);
 }
 }

-/* { dg-final { scan-tree-dump-times "loop iv compare heuristics:
0.0%" 5 "profile_estimate"} } */
+/* { dg-final { scan-tree-dump "loop iv compare heuristics"
"profile_estimate"} } */
 /* { dg-final { cleanup-tree-dump "profile_estimate" } } */
Index: gcc/testsuite/gcc.dg/predict-5.c
===
--- gcc/testsuite/gcc.dg/predict-5.c(revision 186128)
+++ gcc/testsuite/gcc.dg/predict-5.c(working copy)
@@ -1,25 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-profile_estimate" } */
-
-extern int global;
-
-int bar (int);
-
-void foo (int base, int bound)
-{
-  int i, ret = 0;
-  for (i = base; i <= bound; i++)
-{
-  if (i > base)
-   global += bar (i);
-  if (i > base + 1)
-   global += bar (i);
-  if (i >= base + 3)
-   global += bar (i);
-  if (i - 2 >= base)
-   global += bar (i);
-}
-}
-
-/* { dg-final { scan-tree-dump-times "loop iv compare heuristics:
100.0%" 4 "profile_estimate"} } */
-/* { dg-final { cleanup-tree-dump "profile_estimate" } } */
Index: gcc/testsuite/gcc.dg/predict-2.c
===
--- gcc/testsuite/gcc.dg/predict-2.c(revision 186128)
+++ gcc/testsuite/gcc.dg/predict-2.c(working copy)
@@ -5,20 +5,12 @@

 int bar(int);

-void foo (int base, int bound)
+void foo (int bound)
 {
   int i, ret = 0;
-  for (i = base; i < bound; i++)
+  for (i = 0; i < bound; i++)
 {
-  if (i > bound * bound)
-   global += bar (i);
-  if (i > bound + 10)
-   global += bar (i);
-  if (i <= bound + 10)
-   global += bar (i);
-  if (i > base + 10)
-   global += bar (i);
-  if (i < base - 10)
+  if (i > bound * bound )
global += bar (i);
 }
 }
Index: gcc/testsuite/gcc.dg/predict-6.c
===
--- gcc/testsuite/gcc.dg/predict-6.c(revision 186128)
+++ gcc/testsuite/gcc.dg/predict-6.c(working copy)
@@ -1,25 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-profile_estimate" } */
-
-extern int global;
-
-int bar (int);
-
-void foo (int base, int bound)
-{
-  int i, ret = 0;
-  for (i = base; i <= bound; i++)
-{
-  if (i < base)
-   global += bar (i);
-  if (i < base + 1)
-   global += bar (i);
-  if (i <= base + 3)
-   global += bar (i);
-  if (i - 1 < base)
-   global += bar (i);
-}
-}
-
-/* { dg-final { scan-tree-dump-times "loop iv compare heuristics:
0.0%" 4 "profile_estimate"} } */
-/* { dg-final { cleanup-tree-dump "profile_estimate" } } */
Index: gcc/predict.c
===
--- gcc/predict.c   (revision 186128)
+++ gcc/predict.c   (working copy)
@@ -1070,10 +1070,6 @@
 bound = get_base_value (bound);
   if (!bound)
 return false;
-  if (TREE_CODE (base) != INTEGER_CST)
-base = get_base_value (base);
-  if (!base)
-return false;

   *loop_invariant = bound;
   *compare_code = code;

[google][4.6] back out change for pr49642 (issue5976073)

[Rong Xu]

Hi,

Google branch only. 

Backout this change due to performance regression. 

Tested with bootstrap.

Thanks,

-Rong

2012-04-03   Rong Xu  

Google ref b/6284235.
Manually remove upstream patch for PR49642 and it's
test case due to performance regression. 

* gcc/testsuite/gcc.dg/tree-ssa/pr49642.c: Remove.
* ipa-split.c (forbidden_dominators): Delete variable.
(check_forbidden_calls): Delete function.
(dominated_by_forbidden): Likewise.
(consider_split): Revert.
(execute_split_functions): Likewise.

Index: gcc/testsuite/gcc.dg/tree-ssa/pr49642.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr49642.c (revision 186124)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr49642.c (working copy)
@@ -1,49 +0,0 @@
-/* Verify that ipa-split is disabled following __builtin_constant_p.  */
-
-/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-optimized" } */
-
-typedef unsigned int u32;
-typedef unsigned long long u64;
-
-static inline __attribute__((always_inline)) __attribute__((const))
-int __ilog2_u32(u32 n)
-{
- int bit;
- asm ("cntlzw %0,%1" : "=r" (bit) : "r" (n));
- return 31 - bit;
-}
-
-
-static inline __attribute__((always_inline)) __attribute__((const))
-int __ilog2_u64(u64 n)
-{
- int bit;
- asm ("cntlzd %0,%1" : "=r" (bit) : "r" (n));
- return 63 - bit;
-}
-
-
-
-static u64 ehca_map_vaddr(void *caddr);
-
-struct ehca_shca {
-u32 hca_cap_mr_pgsize;
-};
-
-static u64 ehca_get_max_hwpage_size(struct ehca_shca *shca)
-{
- return 1UL << ( __builtin_constant_p(shca->hca_cap_mr_pgsize) ? ( 
(shca->hca_cap_mr_pgsize) < 1 ? ilog2_NaN() : (shca->hca_cap_mr_pgsize) & 
(1ULL << 63) ? 63 : (shca->hca_cap_mr_pgsize) & (1ULL << 62) ? 62 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 61) ? 61 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 60) ? 60 : (shca->hca_cap_mr_pgsize) & (1ULL << 59) ? 59 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 58) ? 58 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 57) ? 57 : (shca->hca_cap_mr_pgsize) & (1ULL << 56) ? 56 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 55) ? 55 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 54) ? 54 : (shca->hca_cap_mr_pgsize) & (1ULL << 53) ? 53 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 52) ? 52 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 51) ? 51 : (shca->hca_cap_mr_pgsize) & (1ULL << 50) ? 50 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 49) ? 49 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 48) ? 48 : (shca->hca_cap_mr_pgsize) & (1ULL << 47) ? 47 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 46) ? 46 : (shca->h
 ca_cap_mr_pgsize) & (1ULL << 45) ? 45 : (shca->hca_cap_mr_pgsize) & (1ULL << 
44) ? 44 : (shca->hca_cap_mr_pgsize) & (1ULL << 43) ? 43 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 42) ? 42 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 41) ? 41 : (shca->hca_cap_mr_pgsize) & (1ULL << 40) ? 40 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 39) ? 39 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 38) ? 38 : (shca->hca_cap_mr_pgsize) & (1ULL << 37) ? 37 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 36) ? 36 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 35) ? 35 : (shca->hca_cap_mr_pgsize) & (1ULL << 34) ? 34 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 33) ? 33 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 32) ? 32 : (shca->hca_cap_mr_pgsize) & (1ULL << 31) ? 31 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 30) ? 30 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 29) ? 29 : (shca->hca_cap_mr_pgsize) & (1ULL << 28) ? 28 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 27) ? 27 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 26) ? 26 : (shca->hca_cap_mr_pgsize) & (1ULL << 
 25) ? 25 : (shca->hca_cap_mr_pgsize) & (1ULL << 24) ? 24 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 23) ? 23 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 22) ? 22 : (shca->hca_cap_mr_pgsize) & (1ULL << 21) ? 21 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 20) ? 20 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 19) ? 19 : (shca->hca_cap_mr_pgsize) & (1ULL << 18) ? 18 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 17) ? 17 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 16) ? 16 : (shca->hca_cap_mr_pgsize) & (1ULL << 15) ? 15 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 14) ? 14 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 13) ? 13 : (shca->hca_cap_mr_pgsize) & (1ULL << 12) ? 12 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 11) ? 11 : (shca->hca_cap_mr_pgsize) & 
(1ULL << 10) ? 10 : (shca->hca_cap_mr_pgsize) & (1ULL << 9) ? 9 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 8) ? 8 : (shca->hca_cap_mr_pgsize) & (1ULL 
<< 7) ? 7 : (shca->hca_cap_mr_pgsize) & (1ULL << 6) ? 6 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 5) ? 5 : (shca->hca_cap_mr_pgsize) & 
 (1ULL << 4) ? 4 : (shca->hca_cap_mr_pgsize) & (1ULL << 3) ? 3 : 
(shca->hca_cap_mr_pgsize) & (1ULL << 2) ? 2 : (shca->hca_cap_mr_pgsize) & (1ULL 
<< 1) ? 1 : (shca->hca_cap_mr_pgsize) & (1ULL << 0) ? 0 : ilog2_NaN() ) : 
(sizeof(shca->hca_cap_mr_pgsize) <= 4) ? __ilog2_u32(shca->hca_cap_mr_pgsize) : 
__ilog2_u64(shca->hca_cap_mr_pgsize) );
-}
-
-int x(struct ehca_shca *shca) {
-r

Re: [google] revert r185948

[Rong Xu]

OK for google-4_6 branch.

-Rong

On Tue, Apr 3, 2012 at 5:30 PM, Dehao Chen  wrote:
>
> Revert r185948, which causes regression to major applications.
>
> Bootstrapped.
>
> OK for google-4_6?
>
> Thanks,
> Dehao
>
> Index: gcc/testsuite/gcc.dg/predict-3.c
> ===
> --- gcc/testsuite/gcc.dg/predict-3.c    (revision 186128)
> +++ gcc/testsuite/gcc.dg/predict-3.c    (working copy)
> @@ -10,16 +10,10 @@
>   int i, ret = 0;
>   for (i = 0; i <= bound; i++)
>     {
> -      if (i < bound - 2)
> -       global += bar (i);
> -      if (i <= bound)
> -       global += bar (i);
> -      if (i + 1 < bound)
> -       global += bar (i);
>       if (i != bound)
>        global += bar (i);
>     }
>  }
>
> -/* { dg-final { scan-tree-dump-times "loop iv compare heuristics:
> 100.0%" 4 "profile_estimate"} } */
> +/* { dg-final { scan-tree-dump "loop iv compare heuristics"
> "profile_estimate"} } */
>  /* { dg-final { cleanup-tree-dump "profile_estimate" } } */
> Index: gcc/testsuite/gcc.dg/predict-4.c
> ===
> --- gcc/testsuite/gcc.dg/predict-4.c    (revision 186128)
> +++ gcc/testsuite/gcc.dg/predict-4.c    (working copy)
> @@ -15,5 +15,5 @@
>     }
>  }
>
> -/* { dg-final { scan-tree-dump "loop iv compare heuristics: 50.0%"
> "profile_estimate"} } */
> +/* { dg-final { scan-tree-dump "loop iv compare heuristics"
> "profile_estimate"} } */
>  /* { dg-final { cleanup-tree-dump "profile_estimate" } } */
> Index: gcc/testsuite/gcc.dg/predict-1.c
> ===
> --- gcc/testsuite/gcc.dg/predict-1.c    (revision 186128)
> +++ gcc/testsuite/gcc.dg/predict-1.c    (working copy)
> @@ -10,18 +10,10 @@
>   int i, ret = 0;
>   for (i = 0; i < bound; i++)
>     {
> -      if (i > bound)
> -       global += bar (i);
> -      if (i >= bound + 2)
> -       global += bar (i);
>       if (i > bound - 2)
>        global += bar (i);
> -      if (i + 2 > bound)
> -       global += bar (i);
> -      if (i == 10)
> -       global += bar (i);
>     }
>  }
>
> -/* { dg-final { scan-tree-dump-times "loop iv compare heuristics:
> 0.0%" 5 "profile_estimate"} } */
> +/* { dg-final { scan-tree-dump "loop iv compare heuristics"
> "profile_estimate"} } */
>  /* { dg-final { cleanup-tree-dump "profile_estimate" } } */
> Index: gcc/testsuite/gcc.dg/predict-5.c
> ===
> --- gcc/testsuite/gcc.dg/predict-5.c    (revision 186128)
> +++ gcc/testsuite/gcc.dg/predict-5.c    (working copy)
> @@ -1,25 +0,0 @@
> -/* { dg-do compile } */
> -/* { dg-options "-O2 -fdump-tree-profile_estimate" } */
> -
> -extern int global;
> -
> -int bar (int);
> -
> -void foo (int base, int bound)
> -{
> -  int i, ret = 0;
> -  for (i = base; i <= bound; i++)
> -    {
> -      if (i > base)
> -       global += bar (i);
> -      if (i > base + 1)
> -       global += bar (i);
> -      if (i >= base + 3)
> -       global += bar (i);
> -      if (i - 2 >= base)
> -       global += bar (i);
> -    }
> -}
> -
> -/* { dg-final { scan-tree-dump-times "loop iv compare heuristics:
> 100.0%" 4 "profile_estimate"} } */
> -/* { dg-final { cleanup-tree-dump "profile_estimate" } } */
> Index: gcc/testsuite/gcc.dg/predict-2.c
> ===
> --- gcc/testsuite/gcc.dg/predict-2.c    (revision 186128)
> +++ gcc/testsuite/gcc.dg/predict-2.c    (working copy)
> @@ -5,20 +5,12 @@
>
>  int bar(int);
>
> -void foo (int base, int bound)
> +void foo (int bound)
>  {
>   int i, ret = 0;
> -  for (i = base; i < bound; i++)
> +  for (i = 0; i < bound; i++)
>     {
> -      if (i > bound * bound)
> -       global += bar (i);
> -      if (i > bound + 10)
> -       global += bar (i);
> -      if (i <= bound + 10)
> -       global += bar (i);
> -      if (i > base + 10)
> -       global += bar (i);
> -      if (i < base - 10)
> +      if (i > bound * bound )
>        global += bar (i);
>     }
>  }
> Index: gcc/testsuite/gcc.dg/predict-6.c
> ===
> --- gcc/testsuite/gcc.dg/predict-6.c    (revision 186128)
> +++ gcc/testsuite/gcc.dg/predict-6.c    (working copy)
> @@ -1,25 +0,0 @@
> -/* { dg-do compile } */
> -/* { dg-options "-O2 -fdump-tree-profile_estimate" } */
> -
> -extern int global;
> -
> -int bar (int);
> -
> -void foo (int base, int bound)
> -{
> -  int i, ret = 0;
> -  for (i = base; i <= bound; i++)
> -    {
> -      if (i < base)
> -       global += bar (i);
> -      if (i < base + 1)
> -       global += bar (i);
> -      if (i <= base + 3)
> -       global += bar (i);
> -      if (i - 1 < base)
> -       global += bar (i);
> -    }
> -}
> -
> -/* { dg-final { scan-tree-dump-times "loop iv compare heuristics:
> 0.0%" 4 "profile_estimate"} } */
> -/* { dg-final { cleanup-tree-dump "profile_estimate" } } */
> Index: gcc/predict.c
> 

Re: [google][4.6] back out change for pr49642 (issue5976073)

[Dehao Chen]

OK for google-4_6

Dehao

On Wed, Apr 4, 2012 at 8:36 AM, Rong Xu  wrote:
> Hi,
>
> Google branch only.
>
> Backout this change due to performance regression.
>
> Tested with bootstrap.
>
> Thanks,
>
> -Rong
>
> 2012-04-03   Rong Xu  
>
>        Google ref b/6284235.
>        Manually remove upstream patch for PR49642 and it's
>        test case due to performance regression.
>
>        * gcc/testsuite/gcc.dg/tree-ssa/pr49642.c: Remove.
>        * ipa-split.c (forbidden_dominators): Delete variable.
>        (check_forbidden_calls): Delete function.
>        (dominated_by_forbidden): Likewise.
>        (consider_split): Revert.
>        (execute_split_functions): Likewise.
>
> Index: gcc/testsuite/gcc.dg/tree-ssa/pr49642.c
> ===
> --- gcc/testsuite/gcc.dg/tree-ssa/pr49642.c     (revision 186124)
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr49642.c     (working copy)
> @@ -1,49 +0,0 @@
> -/* Verify that ipa-split is disabled following __builtin_constant_p.  */
> -
> -/* { dg-do compile } */
> -/* { dg-options "-O2 -fdump-tree-optimized" } */
> -
> -typedef unsigned int u32;
> -typedef unsigned long long u64;
> -
> -static inline __attribute__((always_inline)) __attribute__((const))
> -int __ilog2_u32(u32 n)
> -{
> - int bit;
> - asm ("cntlzw %0,%1" : "=r" (bit) : "r" (n));
> - return 31 - bit;
> -}
> -
> -
> -static inline __attribute__((always_inline)) __attribute__((const))
> -int __ilog2_u64(u64 n)
> -{
> - int bit;
> - asm ("cntlzd %0,%1" : "=r" (bit) : "r" (n));
> - return 63 - bit;
> -}
> -
> -
> -
> -static u64 ehca_map_vaddr(void *caddr);
> -
> -struct ehca_shca {
> -        u32 hca_cap_mr_pgsize;
> -};
> -
> -static u64 ehca_get_max_hwpage_size(struct ehca_shca *shca)
> -{
> - return 1UL << ( __builtin_constant_p(shca->hca_cap_mr_pgsize) ? ( 
> (shca->hca_cap_mr_pgsize) < 1 ? ilog2_NaN() : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 63) ? 63 : (shca->hca_cap_mr_pgsize) & (1ULL << 62) ? 62 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 61) ? 61 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 60) ? 60 : (shca->hca_cap_mr_pgsize) & (1ULL << 59) ? 59 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 58) ? 58 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 57) ? 57 : (shca->hca_cap_mr_pgsize) & (1ULL << 56) ? 56 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 55) ? 55 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 54) ? 54 : (shca->hca_cap_mr_pgsize) & (1ULL << 53) ? 53 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 52) ? 52 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 51) ? 51 : (shca->hca_cap_mr_pgsize) & (1ULL << 50) ? 50 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 49) ? 49 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 48) ? 48 : (shca->hca_cap_mr_pgsize) & (1ULL << 47) ? 47 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 46) ? 46 : (shca->h
>  ca_cap_mr_pgsize) & (1ULL << 45) ? 45 : (shca->hca_cap_mr_pgsize) & (1ULL << 
> 44) ? 44 : (shca->hca_cap_mr_pgsize) & (1ULL << 43) ? 43 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 42) ? 42 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 41) ? 41 : (shca->hca_cap_mr_pgsize) & (1ULL << 40) ? 40 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 39) ? 39 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 38) ? 38 : (shca->hca_cap_mr_pgsize) & (1ULL << 37) ? 37 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 36) ? 36 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 35) ? 35 : (shca->hca_cap_mr_pgsize) & (1ULL << 34) ? 34 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 33) ? 33 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 32) ? 32 : (shca->hca_cap_mr_pgsize) & (1ULL << 31) ? 31 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 30) ? 30 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 29) ? 29 : (shca->hca_cap_mr_pgsize) & (1ULL << 28) ? 28 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 27) ? 27 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 26) ? 26 : (shca->hca_cap_mr_pgsize) & (1ULL <<
>  25) ? 25 : (shca->hca_cap_mr_pgsize) & (1ULL << 24) ? 24 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 23) ? 23 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 22) ? 22 : (shca->hca_cap_mr_pgsize) & (1ULL << 21) ? 21 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 20) ? 20 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 19) ? 19 : (shca->hca_cap_mr_pgsize) & (1ULL << 18) ? 18 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 17) ? 17 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 16) ? 16 : (shca->hca_cap_mr_pgsize) & (1ULL << 15) ? 15 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 14) ? 14 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 13) ? 13 : (shca->hca_cap_mr_pgsize) & (1ULL << 12) ? 12 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 11) ? 11 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 10) ? 10 : (shca->hca_cap_mr_pgsize) & (1ULL << 9) ? 9 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 8) ? 8 : (shca->hca_cap_mr_pgsize) & 
> (1ULL << 7) ? 7 : (shca->hca_cap_mr_pgsize) & (1ULL << 6) ? 6 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 5) ? 5 : (shca->hca_cap_mr_pgsize) &
>  (1ULL << 4) ? 4 : (shca->hca_cap_mr_pgsize) & (1ULL << 3) ? 3 : 
> (shca->hca_cap_mr_pgsize) & (1ULL << 2) ? 2 : (shca->hca_cap_mr_pgsi

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Paulo César Pereira de Andrade]

Em 3 de abril de 2012 20:48, Michael Hope  escreveu:
> On 4 April 2012 11:11, Jakub Jelinek  wrote:
>> On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>>> >> The subdirectories could be called fred and jim and it would still work.
>>> >>  The only thing required is that this part of the naming scheme be
>>> >> agreed amongst the distros.
>>> >>
>>> >> This looks to me like it's turning into a bike-shed painting excerise
>>> >> between the distros out there.  That's really sad.
>>> >
>>> > I don't think we ever even had the discussion: Debian invented their
>>> > Debian-internal scheme for managing multiple ABIs.  They have in the past
>>> > used patched versions of gcc, as in the case of x86_64.
>>>
>>> (cc'ed cross-distro as the discussion is also going on there[1].  This
>>> patch continues that)
>>>
>>> I like the idea of incompatible binaries having different loaders.
>>> The path doesn't matter but the concept does.  Like i686/x86_64, it
>>> gives distros the option to install different binaries alongside each
>>> other for compatibility, performance, or upgrade reasons.  The
>>> compatibility cost is nice and low and lets Debian do some interesting
>>> cross development things.
>>
>> Does the dynamic linker itself contain any routines that depend on the
>> soft/hard ABI?  That would quite surprise me, so I don't see the point of
>> having different dynamic linkers for those ABIs.  One dynamic linker should
>> handle both just fine.
>>
>>> No one has released a hard float based distro yet.  We have time to
>>> discuss and fix this so we don't get in the crazy situation where a
>>> third party binary only runs on some distros.
>>
>> Isn't e.g. Fedora 17/armv7hl a hard float based distro?
>
> Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo.
> None have been released yet.  Here's my understanding:
>
> Fedora 17:
>  * ARM is a secondary architecture
>  * Alpha 1 release is out
>  * Has both a ARMv5 soft float and ARMv7 hard float build
>
> Ubuntu Precise:
>  * ARM is a primary architecture
>  * Beta 2 is out
>  * ARMv7 hard float by default with ARMv7 softfp being community supported
>
> Debian:
>  * ARM is a primary architecture
>  * Has a ARMv4T soft float and in-development ARMv7 hard float
>
> openSUSE:
>  * Kicked off at a hackfest in September 2011
>  * Have a ARMv5T soft float and ARMv7 hard float build
>
> Gentoo:
>  * I'm unsure (help?)
>  * The Gentoo manual suggests ARMv7 softfp is the default

  I did two ports of Mandriva to armv7. One of my choice to use softfp,
and another hardfp port to be compatible with other distros. But other
than a previous armv5 port, there is not much else of Mandriva arm,
so, it would be "good to have" to be able to run binaries for either
without resorting to a chroot, and only testing purposes.

  Bumping major or calling it ld-linux-foo.so.3 is out of question?

> -- Michael
>
> ___
> cross-distro mailing list
> cross-dis...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/cross-distro

Paulo

PATCH: PR debug/52857: DW_OP_GNU_regval_type is generated with INVALID_REGNUM

[H.J. Lu]

Hi,

As the testcase in

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857

shows, for

(subreg:SI (plus:DI (reg/f:DI 16 argp)
(const_int -128 [0xff80])) 0)

we generates DW_OP_GNU_regval_type with INVALID_REGNUM.  This patch
checks dbx_reg_number for INVALID_REGNUM before using it.  OK for
trunk and 4.7?

Thanks.

H.J.
---
2012-04-03  H.J. Lu  

PR debug/52857
* dwarf2out.c (mem_loc_descriptor): Don't generate
DW_OP_GNU_regval_type with INVALID_REGNUM.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index ca88fc5..935c86f 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -11664,7 +11664,8 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
 
  if (dwarf_strict)
break;
- if (REGNO (rtl) > FIRST_PSEUDO_REGISTER)
+ if (REGNO (rtl) > FIRST_PSEUDO_REGISTER
+ || dbx_reg_number (rtl) == INVALID_REGNUM)
break;
  type_die = base_type_for_mode (mode,
 GET_MODE_CLASS (mode) == MODE_INT);

Re: rs6000 toc reference rtl again

[Alan Modra]

On Tue, Apr 03, 2012 at 07:49:04PM +0100, Richard Sandiford wrote:
> Alan Modra  writes:
> > Now that we are back in stage1, I'd like to apply
> > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html, a change to
> > toc reference rtl in order to properly specify r2 dependencies.  More
> > commentary in that url.  I'm reposting the patch here since the old
> > one no longer applies cleanly, and I've added some ENABLE_CHECKING
> > code in rs6000_delegitimize_address.
> 
> Sorry to be a pain, but I don't think HIGH is supposed contain
> regs either.  Both HIGH and CONST are supposed to be true constants.

Eh, so the existing use of CONST is wrong then.  ;-)

I'm proposing
  (unspec [(symbol_ref sym) (reg r2)] UNSPEC_TOCREL)
for the small model, and
  (high (unspec [(symbol_ref sym) (reg r2)] UNSPEC_TOCREL)))
  (lo_sum (reg hi) (unspec [(symbol_ref sym) (reg r2)] UNSPEC_TOCREL))
for medium/large model.

You can see why I'd like to keep it this way;  The medium/large rtl is
a natural split of the small rtl.  (I'm going to experiment with
splitting the small rtl after reload for medium/large to see whether
that helps our usage of call-saved regs in loops.)

I'm not wedded to the representation, *but* we do want gcc to treat
the high part as a constant.  That's important because we don't ever
want reload saving the high part to a stack slot!  Which is what does
happen if you don't somehow tell gcc it is a constant.

Besides, the high part *is* a constant within any given function.  So
is the low part for that matter.  The only reason I want r2 mentioned
in this rtl is for register liveness, eg. so that a load of a function
pointer (which loads r2) for an indirect call doesn't get scheduled
before any uses of the old r2.

The alternative of removing r2 from the unspec and attaching a
(use (reg r2)) to all instructions that have this addressing form
might be clean but will require major duplication of patterns in
rs6000.md, won't it?

-- 
Alan Modra
Australia Development Lab, IBM

PATCH: Define TRY_EMPTY_VM_SPACE for Linux/x32

[H.J. Lu]

Hi,

This patch defines TRY_EMPTY_VM_SPACE for Linux/x32.  Tested on Linux/x32.
OK for trunk?

Thanks.


H.J.
---
2012-04-03  H.J. Lu  

* config/host-linux.c (TRY_EMPTY_VM_SPACE): Defined to
0x6000 for x32.

diff --git a/gcc/config/host-linux.c b/gcc/config/host-linux.c
index 94b7a0b..b89df46 100644
--- a/gcc/config/host-linux.c
+++ b/gcc/config/host-linux.c
@@ -68,8 +68,14 @@
 # define TRY_EMPTY_VM_SPACE0x100
 #elif defined(__ia64)
 # define TRY_EMPTY_VM_SPACE0x2001
-#elif defined(__x86_64)
+/* __LP64__ is defined for LP64 after GCC 3.3.  If __LP64__ isn't
+   defined for GCC 4.0 or newer, it must be x32.  */
+#elif defined(__x86_64) && (defined(__LP64__) \
+   || !defined(__GNUC__) \
+   || __GNUC__ < 4)
 # define TRY_EMPTY_VM_SPACE0x10
+#elif defined(__x86_64)
+# define TRY_EMPTY_VM_SPACE0x6000
 #elif defined(__i386)
 # define TRY_EMPTY_VM_SPACE0x6000
 #elif defined(__powerpc__)

Re: [RS6000] Stack tie fix.

[Alan Modra]

On Tue, Apr 03, 2012 at 01:05:08PM -0400, David Edelsohn wrote:
> On Tue, Apr 3, 2012 at 10:55 AM, Olivier Hainque  wrote:
> >
> > On Apr 3, 2012, at 16:34 , Olivier Hainque wrote:
> >> Thanks a lot for following up on this one. Coincidentally, I was just
> >> about to submit the alternate approach we had discussed about, after
> >> David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html.
> >
> >> This is of course a much heavier hammer so it would be nice if we can
> >> indeed have a subtler way out :-)
> >
> >  To clarify: the heavier approach is the one I was about to submit
> >  (minor variation of Joseph's proposal in the thread just referenced),
> >  and the subtler way out is the one you are proposing here.
> 
> We can give Alan's patch a try.  I'm not sure if it is sufficient
> given the experience of IBM's XL compiler.  I also would rather not
> use the heavier hammer, but I don't want to leave a latent bug.

I'll see whether my approach fixes pr30282 for gcc-4.4 which has known
deficiencies in alias analysis.  Olivier, would you be kind enough to
backport and test against other versions of gcc that needed your
bigger hammer?

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

2012/4/4 Paulo César Pereira de Andrade
:
> Em 3 de abril de 2012 20:48, Michael Hope  escreveu:



>> Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo.
>> None have been released yet.  Here's my understanding:
>>
>> Fedora 17:
>>  * ARM is a secondary architecture
>>  * Alpha 1 release is out
>>  * Has both a ARMv5 soft float and ARMv7 hard float build
>>
>> Ubuntu Precise:
>>  * ARM is a primary architecture
>>  * Beta 2 is out
>>  * ARMv7 hard float by default with ARMv7 softfp being community supported
>>
>> Debian:
>>  * ARM is a primary architecture
>>  * Has a ARMv4T soft float and in-development ARMv7 hard float
>>
>> openSUSE:
>>  * Kicked off at a hackfest in September 2011
>>  * Have a ARMv5T soft float and ARMv7 hard float build
>>
>> Gentoo:
>>  * I'm unsure (help?)
>>  * The Gentoo manual suggests ARMv7 softfp is the default
>
>  I did two ports of Mandriva to armv7. One of my choice to use softfp,
> and another hardfp port to be compatible with other distros. But other
> than a previous armv5 port, there is not much else of Mandriva arm,
> so, it would be "good to have" to be able to run binaries for either
> without resorting to a chroot, and only testing purposes.
>
>  Bumping major or calling it ld-linux-foo.so.3 is out of question?

I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
questions here though: can the hard float loader have a different path
and, if so, what should it be?  We're still working on the first part.

-- Michael

Re: [google] Work around PR52796 by replacing empty packs with explicit overloads. (issue5971053)

[Jason Merrill]

On 04/01/2012 12:38 PM, Diego Novillo wrote:

I'm not sure it makes sense to propose it for gcc-4_6-branch. Jason/Ben,
any opinions on PR 52796 and what should we do for gcc-4_6-branch?


Fixed.  :)

Jason

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

On 4 April 2012 10:56, Joseph S. Myers  wrote:
> On Tue, 3 Apr 2012, Michael Hope wrote:
>
>> +#define GLIBC_DYNAMIC_LINKER \
>> +   "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
>> +    %{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
>> +    %{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"
>
> (a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to
> be handled in specs.

Fixed.

> (b) You need to handle compilers configured with --with-float=hard, so
> make the specs depend on the default ABI the compiler was configured with.

GCC seems to take configure time options into account when evaluating
a spec file.

Tested by building a default, --with-float=hard, and
--with-float=softfp compiler then checking the loader path for all
combinations of {,-mglibc,-mbionic,-muclibc} x
{,-mhard-float,-msoft-float,-mfloat-abi=hard,-mfloat-abi=softfp}.

> (c) Please include libc-ports on future submissions and provide both the
> GCC patch and the glibc ports patch that have been tested to work together
> to build and install the library in the given path; a patch to one
> component like this cannot sensibly be considered in isolation.  I imagine
> you'll need appropriate ARM preconfigure support to detect what ABI the
> compiler is using, much like the support for MIPS, so that the right
> shlib-versions files are used.

Agreed.

>  I try to follow all ARM glibc discussions
> on libc-ports closely, as the ARM glibc maintainer; was there a previous
> discussion of the dynamic linker naming issue there that I missed?

Steve McIntyre is driving this inside Debian.  I'll ping him on the
GLIBC support.

The tricky one is new GCC with old GLIBC.  GCC may have to do a
configure time test and fall back to /lib/ld-linux.so.3 if the hard
float loader is missing.

>  (The only previous relevant discussion that I recall is one on
> patc...@eglibc.org starting at
> , regarding how the
> dynamic linker should check that a library has the right ABI, and there
> was no real followup on that after I indicated what would seem to be the
> appropriate implementation approaches and places for subsequent
> discussion.)

The patch above changes the loader to catch a mixed installation and
reject mixing incompatible libraries.  The static linker does this
currently but it's not essential.

> I have no idea whether shlib-versions files naming a file in a
> subdirectory will work - but if not, you'd need to send a patch to
> libc-alpha to support dynamic linkers in subdirectories, with appropriate
> justification for why you are doing something different from all other
> architectures.

Understood.  For now this is just a path.  There's more infrastructure
work needed if the path includes a directory.

> (d) Existing practice for Power Architecture and MIPS at least is that
> hard-float and soft-float *don't* use different library directories /
> dynamic linkers.

The goal is to have a standard loader path for all hard float distros
and, similar to how you can have a mixed 32/64 bit installation, allow
mixed softfp/hard float installations for distros that want it.  This
is a new requirement and ARM is the first one exposed to it.  I assume
Debian would push for similar changes on MIPS and PowerPC.

Do the MIPS or PowerPC loaders detect the ABI and change the library
path based on that?  I couldn't tell from the code.

> (e) Existing practice for cases that do use different dynamic linkers is
> to use a separate library directory, not just dynamic linker name, as in
> lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to
> make two sets of libraries work in parallel if you have separate library
> directories like that.

Is this required, or should it be left to the distro to choose?  Once
the loader is in control then it can account for any distro specific
features, which may be the standard /lib and /usr/lib for single ABI
distros like Fedora or /usr/lib/$tuple for multiarch distros like
Ubuntu and Debian.

> So it would seem more appropriate to define a directory libhf for ARM 
> (meaning you need a binutils patch as well to
> handle that directory, I think)

I'd like to leave that discussion for now.  The Debian goal is to
support incompatible ABIs and, past that, incompatible architectures.
libhf is ambiguous as you could have a MIPS hard float library
installed on the same system as an ARM hard float library.

> and these different Debian-style names
> could be implemented separately in a multiarch patch if someone submits
> one that properly accounts for my review comments on previous patch
> versions (failure to produce such a fixed patch being why Debian multiarch
> directory support has not got into GCC so far).

Agreed.  Note that this loader path discussion is unrelated to
multiarch.  It came from the same people so there's a family
resemblance.

(BTW Dann, apologies for stealing your patch)

-- Michae

Re: [google] Work around PR52796 by replacing empty packs with explicit overloads. (issue5971053)

[Paolo Carlini]

> On 04/01/2012 12:38 PM, Diego Novillo wrote:
>> I'm not sure it makes sense to propose it for gcc-4_6-branch. Jason/Ben,
>> any opinions on PR 52796 and what should we do for gcc-4_6-branch?
> 
> Fixed.  :)

I'm so relieved, seriously.

Thanks,
Paolo

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jakub Jelinek]

On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
> >  I did two ports of Mandriva to armv7. One of my choice to use softfp,
> > and another hardfp port to be compatible with other distros. But other
> > than a previous armv5 port, there is not much else of Mandriva arm,
> > so, it would be "good to have" to be able to run binaries for either
> > without resorting to a chroot, and only testing purposes.
> >
> >  Bumping major or calling it ld-linux-foo.so.3 is out of question?
> 
> I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
> questions here though: can the hard float loader have a different path
> and, if so, what should it be?  We're still working on the first part.

If the agreement is that arm 32-bit softfp really needs to be installable
alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it
like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the
various MIPS variants) and what FSB says, e.g. use
/lib/ld-linux.so.3 and */lib dirs for softfp,
/libhf/ld-linux.so.3 and */libhf dirs for hardfp and
/lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
MULTILIB_OSDIRNAMES, etc., have it configured in glibc, and for those that
choose the Debian layout instead, if it is added somehow configurable into
upstream gcc/glibc of course handle it similarly there.  I just wonder why
that hasn't been done 10 years ago and only needs doing now (of course,
aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).

One needs to wonder also why arm hasn't switched to 128-bit long double when
all other mainstream architectures did (I hope at least aarch64 will use it
by default).

Jakub