Re: [PATCH] Fix libjava build on current git glibc (PR bootstrap/50888)

[Jakub Jelinek]

On Wed, Nov 23, 2011 at 02:24:34PM -0700, Tom Tromey wrote:
> > "Jakub" == Jakub Jelinek  writes:
> 
> Jakub> As discussed in the PR, libjava fails to build against latest
> Jakub> glibc, because prims.cc is compiled with -fnon-call-exceptions,
> Jakub> uses ctype.h and libgcj isn't linked against -lsupc++ or -lstdc++.
> Jakub> isspace in latest glibc is a throw() inline that calls a throw()
> Jakub> function pointer.  Unfortunately, with -fnon-call-exceptions
> Jakub> the compiler doesn't have a guarantee that the function pointer
> Jakub> that is being called is always valid (it is in glibc) and thus adds
> Jakub> a __cxa_call_unexpected call if the call would throw and that symbol
> Jakub> isn't satisfied during linking of libgcj and apps against it.
> 
> BTW, it seems odd to me that this function is marked throw() instead of
> __attribute__((nothrow)).  The latter would avoid this problem entirely.

Well, appart from -fnon-call-exceptions it should make zero difference.
I guess glibc uses throw() because it is a C++ standard feature, not an
extension.

Jakub

Re: [C++ Patch] PR 51290

[Jason Merrill]

On 11/23/2011 08:09 PM, Paolo Carlini wrote:

   if (null_test)
 {
-  tree zero = cp_convert (TREE_TYPE (expr), integer_zero_node);
+  tree zero = cp_convert (TREE_TYPE (expr),
+ want_pointer ? nullptr_node : integer_zero_node);


This ?: is unnecessary; if null_test is true, so is want_pointer.

OK just using nullptr_node.

Jason

Re: [brobec...@adacore.com: Re: [PATCH 18/348] Fix -Wsahdow warnings]

[Alan Modra]

On Wed, Nov 23, 2011 at 12:05:56PM -0800, Joel Brobecker wrote:
> We were looking at -Wshadow warnings that we thought were counter
> productive, and found that you had written a patch that would help us.
> The patch was okayed, but never applied. Is there a reason for it?

I must have missed seeing the OK.  Committed revision 181684.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [libitm] Port to ARM

[Joseph S. Myers]

On Wed, 23 Nov 2011, Richard Henderson wrote:

> On 11/23/2011 04:00 PM, Joseph S. Myers wrote:
> > On Wed, 23 Nov 2011, Richard Henderson wrote:
> > 
> >> +  __asm volatile ("swi %1"
> >> +: "+r"(sc_0)
> >> +: "i"(SYS_futex), "r"(sc_1), "r"(sc_2), "r"(sc_3)
> >> +: "memory");
> > 
> > That looks wrong.  Passing the syscall number to swi is the old-ABI 
> > approach; the EABI uses syscall number in r7. 
> 
> Interesting to know.
> 
> I took as examples both glibc ports sysdeps.h

Overridden in the eabi/ subdirectory.  Yes, as ARM glibc maintainer it's 
probably time for me to kill the old-ABI support and simplify the 
directory structure

> and CLEAR_INSN_CACHE from linux-gas.h.  Which... I see is out of date 
> wrt libgcc lib1funcs.S clear_cache.

Again, an old-ABI-only version; I moved the EABI version to lib1funcs.S 
from linux-eabi.h to avoid a problem where building libgcc for Thumb-2 
with -O0 quietly produced broken code because of the conflict with the 
frame pointer .  
Dan ended up moving Thumb-2 syscalls out-of-line in glibc for much the 
same reason (unwinding being the problem there) 
.

> Perhaps I'm better off with the syscall function as libgomp uses?

That's certainly safer and avoids depending on EABI/old-ABI.

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

Re: [libitm] Port to ARM

[Richard Henderson]

On 11/23/2011 04:00 PM, Joseph S. Myers wrote:
> On Wed, 23 Nov 2011, Richard Henderson wrote:
> 
>> +  __asm volatile ("swi %1"
>> +  : "+r"(sc_0)
>> +  : "i"(SYS_futex), "r"(sc_1), "r"(sc_2), "r"(sc_3)
>> +  : "memory");
> 
> That looks wrong.  Passing the syscall number to swi is the old-ABI 
> approach; the EABI uses syscall number in r7. 

Interesting to know.

I took as examples both glibc ports sysdeps.h and CLEAR_INSN_CACHE from 
linux-gas.h.  Which... I see is out of date wrt libgcc lib1funcs.S clear_cache.

Perhaps I'm better off with the syscall function as libgomp uses?


r~

RE: PING: [PATCH, ARM, iWMMXt][4/5]: WMMX machine description

[Xinyu Qi]

Hi Ramana,

I solve the conflict, please try again. The new diff is attached.

Thanks,
Xinyu

At 2011-11-19 07:36:15,"Ramana Radhakrishnan"  
wrote:
> 
> Hi Xinyu,
> 
> This doesn't apply cleanly currently on trunk and the reject appears
> to come from iwmmxt.md and I've not yet investigated why.
> 
> Can you have a look ?
> 
> cheers
> Ramana
> 
> On 26 September 2011 04:22, Xinyu Qi  wrote:
> > Ping.
> >
> > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00279.html
> >
> >        * config/arm/arm.c (arm_output_iwmmxt_shift_immediate): New
> function.
> >        (arm_output_iwmmxt_tinsr): Likewise.
> >        * config/arm/arm-protos.h
> (arm_output_iwmmxt_shift_immediate): Declare.
> >        (arm_output_iwmmxt_tinsr): Likewise.
> >        * config/arm/iwmmxt.md (WCGR0, WCGR1, WCGR2, WCGR3):
> New constant.
> >        (iwmmxt_psadbw, iwmmxt_walign, iwmmxt_tmrc, iwmmxt_tmcr):
> Delete.
> >        (iwmmxt_tbcstqi, iwmmxt_tbcsthi, iwmmxt_tbcstsi): Likewise
> >        (*iwmmxt_clrv8qi, *iwmmxt_clrv4hi, *iwmmxt_clrv2si): Likewise.
> >        (tbcstv8qi, tbcstv4hi, tbsctv2si): New pattern.
> >        (iwmmxt_clrv8qi, iwmmxt_clrv4hi, iwmmxt_clrv2si): Likewise.
> >        (*and3_iwmmxt, *ior3_iwmmxt,
> *xor3_iwmmxt): Likewise.
> >        (rori3, ashri3_iwmmxt, lshri3_iwmmxt):
> Likewise.
> >        (ashli3_iwmmxt, iwmmxt_waligni, iwmmxt_walignr):
> Likewise.
> >        (iwmmxt_walignr0, iwmmxt_walignr1): Likewise.
> >        (iwmmxt_walignr2, iwmmxt_walignr3): Likewise.
> >        (iwmmxt_setwcgr0, iwmmxt_setwcgr1): Likewise.
> >        (iwmmxt_setwcgr2, iwmmxt_setwcgr3): Likewise.
> >        (iwmmxt_getwcgr0, iwmmxt_getwcgr1): Likewise.
> >        (iwmmxt_getwcgr2, iwmmxt_getwcgr3): Likewise.
> >        (All instruction patterns): Add wtype attribute.
> >        (*iwmmxt_arm_movdi, *iwmmxt_movsi_insn): iWMMXt coexist
> with vfp.
> >        (iwmmxt_uavgrndv8qi3, iwmmxt_uavgrndv4hi3): Revise the
> pattern.
> >        (iwmmxt_uavgv8qi3, iwmmxt_uavgv4hi3): Likewise.
> >        (iwmmxt_tinsrb, iwmmxt_tinsrh, iwmmxt_tinsrw):Likewise.
> >        (eqv8qi3, eqv4hi3, eqv2si3, gtuv8qi3): Likewise.
> >        (gtuv4hi3, gtuv2si3, gtv8qi3, gtv4hi3, gtv2si3): Likewise.
> >        (iwmmxt_wunpckihh, iwmmxt_wunpckihw, iwmmxt_wunpckilh):
> Likewise.
> >        (iwmmxt_wunpckilw, iwmmxt_wunpckehub, iwmmxt_wunpckehuh):
> Likewise.
> >        (iwmmxt_wunpckehuw, iwmmxt_wunpckehsb,
> iwmmxt_wunpckehsh): Likewise.
> >        (iwmmxt_wunpckehsw, iwmmxt_wunpckelub,
> iwmmxt_wunpckeluh): Likewise.
> >        (iwmmxt_wunpckeluw, iwmmxt_wunpckelsb, iwmmxt_wunpckelsh):
> Likewise.
> >        (iwmmxt_wunpckelsw, iwmmxt_wmadds, iwmmxt_wmaddu):
> Likewise.
> >        (iwmmxt_wsadb, iwmmxt_wsadh, iwmmxt_wsadbz,
> iwmmxt_wsadhz): Likewise.
> >        (iwmmxt2.md): Include.
> >        * config/arm/iwmmxt2.md: New file.
> >        * config/arm/iterators.md (VMMX2): New mode_iterator.
> >        * config/arm/arm.md (wtype): New attribute.
> >        (UNSPEC_WMADDS, UNSPEC_WMADDU): Delete.
> >        (UNSPEC_WALIGNI): New unspec.
> >        * config/arm/t-arm (MD_INCLUDES): Add iwmmxt2.md.
> >
> > At 2011-09-05 17:55:34,"Xinyu Qi"  wrote:
> >> At 2011-08-18 10:21:01,"Ramana Radhakrishnan"
> >>  wrote:
> >> > On 14 July 2011 08:45, Xinyu Qi  wrote:
> >> > >> Hi,
> >> > >>
> >> > >> It is the fourth part of iWMMXt maintenance.
> >> > >>
> >> >
> >> > Can this be broken down further. ? I'll have to do this again but
> >> > there are some initial comments below for some discussion.
> >>
> >> >
> >> > >  (*iwmmxt_arm_movdi, *iwmmxt_movsi_insn, iwmmxt_uavgrndv8qi3,
> >> > iwmmxt_uavgrndv4hi3, iwmmxt_uavgv8qi3, iwmmxt_uavgv4hi3,
> iwmmxt_tinsrb,
> >> > iwmmxt_tinsrh, iwmmxt_tinsrw, eqv8qi3, eqv4hi3, eqv2si3, gtuv8qi3,
> >> gtuv4hi3,
> >> > gtuv2si3, gtv8qi3, gtv4hi3, gtv2si3, iwmmxt_wunpckihb,
> iwmmxt_wunpckihh,
> >> > iwmmxt_wunpckihw, iwmmxt_wunpckilb, iwmmxt_wunpckilh,
> iwmmxt_wunpckilw,
> >> > iwmmxt_wunpckehub, iwmmxt_wunpckehuh, iwmmxt_wunpckehuw,
> >> iwmmxt_wunpckehsb,
> >> > iwmmxt_wunpckehsh, iwmmxt_wunpckehsw, iwmmxt_wunpckelub,
> >> iwmmxt_wunpckeluh,
> >> > iwmmxt_wunpckeluw, iwmmxt_wunpckelsb, iwmmxt_wunpckelsh,
> >> iwmmxt_wunpckelsw,
> >> > iwmmxt_wmadds, iwmmxt_wmaddu, iwmmxt_wsadb, iwmmxt_wsadh,
> iwmmxt_wsadbz,
> >> > iwmmxt_wsadhz): Revise.
> >> >
> >> > Revise to do what ?
> >>
> >> Sorry for late response.
> >>
> >> Some of them have incorrect RTL templates. For example, see
> iwmmxt_uavgv8qi3
> >> Its old RTL template is:
> >>   [(set (match_operand:V8QI                 0 "register_operand"
> "=y")
> >>         (ashiftrt:V8QI (plus:V8QI
> >>                           (match_operand:V8QI 1
> "register_operand" "y")
> >>                                  (match_operand:V8QI 2
> "register_operand" "y"))
> >>                             (const_int 1)))]
> >>
> >> According to the assembly behavior of wavg2b, the correct one should be:
> >>   [(set (match_operand:V8QI  0 "register_operand" "=y")
> >>         (truncate:V8QI
> >>           

RE: PING: [PATCH, ARM, iWMMXt][3/5]: built in define and expand

[Xinyu Qi]

At 2011-11-19 07:08:22,"Ramana Radhakrishnan"  
wrote: 
> On 20 October 2011 08:39, Xinyu Qi  wrote:
> > Ping
> >
> > http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01103.html
> >
> >        * config/arm/arm.c (enum arm_builtins): Revise built-in fcode.
> >        (builtin_description bdesc_2arg): Revise built in declaration.
> >        (builtin_description bdesc_1arg): Likewise.
> >        (arm_init_iwmmxt_builtins): Revise built in initialization.
> >        (arm_expand_builtin): Revise built in expansion.
> >
> 
> This currently doesn't apply - can you take a look ?

Hi Ramana,

I resolve the patch conflict with the newest trunk gcc. The resolved diff is 
attached.

Thanks,
Xinyu


3_arm_c.diff
Description: 3_arm_c.diff

[C++ Patch] PR 51290

[Paolo Carlini]

Hi,

another case of spurious -Wzero-as-null-pointer-constant, rather 
straightforward fix, IMHO. Well, with hindsight, I should have grepped 
more carefully for integer_zero_node, a couple of weeks ago ;)


Anyway, tested x86_64-linux. Ok?

Thanks,
Paolo.

///
/cp
2011-11-23  Paolo Carlini  

PR c++/51290
* class.c (build_base_path): For pointers, use nullptr_node instead
of integer_zero_node.

/testsuite
2011-11-23  Paolo Carlini  

PR c++/51290
* g++.dg/warn/Wzero-as-null-pointer-constant-3.C: New.
Index: testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-3.C
===
--- testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-3.C(revision 0)
+++ testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-3.C(revision 0)
@@ -0,0 +1,22 @@
+// PR c++/51290
+// { dg-options "-Wzero-as-null-pointer-constant" }
+
+class A { int a; };
+
+class B { int b; };
+
+class C : public A, public B
+{
+private:
+static void foo (A *x)
+{
+C *y = static_cast(x);
+(void) y;
+}
+
+static void bar (B *x)
+{
+C *y = static_cast(x);
+(void) y;
+}
+};
Index: cp/class.c
===
--- cp/class.c  (revision 181678)
+++ cp/class.c  (working copy)
@@ -338,7 +338,8 @@ build_base_path (enum tree_code code,
   /* Now that we've saved expr, build the real null test.  */
   if (null_test)
 {
-  tree zero = cp_convert (TREE_TYPE (expr), integer_zero_node);
+  tree zero = cp_convert (TREE_TYPE (expr),
+ want_pointer ? nullptr_node : integer_zero_node);
   null_test = fold_build2_loc (input_location, NE_EXPR, boolean_type_node,
   expr, zero);
 }

Re: [RFC] PR C++/51225

[Paolo Carlini]

Hi again,
Thus, what to do? Definitely adding CAST_EXPR to the switch works, but 
I'm wondering if we could do something else... but doesn't seem easy 
to me given the above. For example, I suppose changing 
potential_constant_expression to return true for error_mark_node would 
be catastrophic, even if error_mark_node is definitely constant ;)

Thus I decided to do the experiment: the below passes the testsuite, eh!

Interestingly the tweak to the testcase below *align* the error messages 
produced to those produced with -std=c++98, just a little more terse.  
Thus, is my idea really crazy after all? (of course, given the analysis 
in the previous message, c++/51225 is also fixed)


Thanks,
Paolo.

/
Index: testsuite/g++.dg/cpp0x/regress/error-recovery1.C
===
--- testsuite/g++.dg/cpp0x/regress/error-recovery1.C(revision 181678)
+++ testsuite/g++.dg/cpp0x/regress/error-recovery1.C(working copy)
@@ -5,7 +5,7 @@ template < bool > void
 foo ()
 {
   const bool b =;  // { dg-error "" }
-  foo < b > ();// { dg-error "constant expression" }
+  foo < b > ();
 };
 
 // { dg-error "no match" "" { target *-*-* } 8 }
Index: cp/semantics.c
===
--- cp/semantics.c  (revision 181678)
+++ cp/semantics.c  (working copy)
@@ -7923,9 +7923,7 @@ potential_constant_expression_1 (tree t, bool want
   if (cxx_dialect < cxx0x)
 return true;
 
-  if (t == error_mark_node)
-return false;
-  if (t == NULL_TREE)
+  if (t == NULL_TREE || t == error_mark_node)
 return true;
   if (TREE_THIS_VOLATILE (t))
 {

Re: [libitm] Port to ARM

[Joseph S. Myers]

On Wed, 23 Nov 2011, Richard Henderson wrote:

> +  __asm volatile ("swi %1"
> +   : "+r"(sc_0)
> +   : "i"(SYS_futex), "r"(sc_1), "r"(sc_2), "r"(sc_3)
> +   : "memory");

That looks wrong.  Passing the syscall number to swi is the old-ABI 
approach; the EABI uses syscall number in r7.  Maybe this works in EABI 
code if the kernel has CONFIG_OABI_COMPAT enabled, but you can't rely on 
CONFIG_OABI_COMPAT being enabled (and decoding the instruction is slower, 
which is why this changed for EABI); you need to pass the number in r7 
(easier from a pure assembly function, to avoid problems with it being 
used as the Thumb frame pointer) for EABI.

(It's probably time to deprecate the old-ABI targets with EABI equivalents 
(arm*-*-linux* not matching arm*-*-linux-*eabi, arm*-*-uclinux* not 
matching arm*-*-uclinux*eabi, arm*-*-elf not matching arm*-*-ecos-elf, 
arm*-*-rtems* not matching arm*-*-rtemseabi*).)

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

Re: [libitm] Port to ARM

[Richard Henderson]

On 11/23/2011 03:47 PM, Richard Henderson wrote:
> +GTM_longjmp:
> + ldm r0, { r4-r11, sp, pc }


Bah.  This should be

mov r2, r0  /* Move the jmpbuf out of the way.  */
mov r0, r1  /* Move the return value into place.  */
ldm r2, { r4-r11, sp, pc }



r~

[libitm] Port to ARM

[Richard Henderson]

To get the ball rolling for other targets, and to let port maintainers see how 
easy it really is, here's a first cut at a port to ARM.

Only cross-compiled as yet, and qemu-linux-user isn't good enough to emulate.  
I'll do another build on the armv7 host once my current bootstrap and test for 
the atomic optabs is complete.

Please review, especially the local setjmp-alike implementation.


r~
commit 09969bb6f3597ccb9fd176bb7dc10119cac91371
Author: Richard Henderson 
Date:   Wed Nov 23 15:31:33 2011 -0800

arm-linux: Add libitm support.

diff --git a/libitm/config/arm/sjlj.S b/libitm/config/arm/sjlj.S
new file mode 100644
index 000..f1e7769
--- /dev/null
+++ b/libitm/config/arm/sjlj.S
@@ -0,0 +1,48 @@
+/* Copyright (C) 2011 Free Software Foundation, Inc.
+   Contributed by Richard Henderson .
+
+   This file is part of the GNU Transactional Memory Library (libitm).
+
+   Libitm 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 of the License, or
+   (at your option) any later version.
+
+   Libitm 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.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+   .text
+   .align  2
+   .global _ITM_beginTransaction
+   .type   _ITM_beginTransaction, %function
+
+_ITM_beginTransaction:
+   push{ r4-r11, sp, lr }
+   mov r1, sp
+   bl  GTM_begin_transaction
+add sp, sp, #(9*4)
+pop{ pc }
+   .size   _ITM_beginTransaction, . - _ITM_beginTransaction
+
+   .global GTM_longjmp
+   .hidden GTM_longjmp
+   .type   GTM_longjmp, %function
+
+GTM_longjmp:
+   ldm r0, { r4-r11, sp, pc }
+   .size   GTM_longjmp, . - GTM_longjmp
+
+#ifdef __linux__
+.section .note.GNU-stack, "", %progbits
+#endif
diff --git a/libitm/config/arm/target.h b/libitm/config/arm/target.h
new file mode 100644
index 000..d889bc8
--- /dev/null
+++ b/libitm/config/arm/target.h
@@ -0,0 +1,60 @@
+/* Copyright (C) 2011 Free Software Foundation, Inc.
+   Contributed by Richard Henderson .
+
+   This file is part of the GNU Transactional Memory Library (libitm).
+
+   Libitm 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 of the License, or
+   (at your option) any later version.
+
+   Libitm 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.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+namespace GTM HIDDEN {
+
+typedef struct gtm_jmpbuf
+{
+  unsigned long s[8];  /* r4-r12 */
+  void *cfa;
+  unsigned long pc;
+} gtm_jmpbuf;
+
+/* ARM generally uses a fixed page size of 4K.  */
+#define PAGE_SIZE  4096
+#define FIXED_PAGE_SIZE1
+
+/* ??? The size of one line in hardware caches (in bytes). */
+#define HW_CACHELINE_SIZE 64
+
+static inline void
+cpu_relax (void)
+{
+  /* ??? Maybe use WFE.  */
+  __asm volatile ("" : : : "memory");
+}
+
+static inline void
+atomic_read_barrier (void)
+{
+  __sync_synchronize ();
+}
+
+static inline void
+atomic_write_barrier (void)
+{
+  __sync_synchronize ();
+}
+
+} // namespace GTM
diff --git a/libitm/config/linux/arm/futex_bits.h 
b/libitm/config/linux/arm/futex_bits.h
new file mode 100644
index 000..7e1b52f
--- /dev/null
+++ b/libitm/config/linux/arm/futex_bits.h
@@ -0,0 +1,48 @@
+/* Copyright (C) 2011 Free Software Foundation, Inc.
+   Contributed by Richard Henderson .
+
+   This file is part of the GNU Transactional Memory Library (libitm).
+
+   Libitm 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 of

Re: [PATCH 0/2] Add atomic support to m68k

[Richard Henderson]

On 11/23/2011 06:46 AM, Mikael Pettersson wrote:
> +FAIL: c-c++-common/gomp/atomic-10.c scan-tree-dump-times ompexp 
> "__atomic_fetch_add" 4
> +FAIL: c-c++-common/gomp/atomic-3.c scan-tree-dump-times ompexp "xyzzy, 4" 1
> +FAIL: c-c++-common/gomp/atomic-9.c scan-tree-dump-times ompexp 
> "__atomic_fetch_add" 1

What are these failures?

Are they fixed if you add m68k-linux to check_effective_target_sync_int_long 
and check_effective_target_sync_char_short in 
gcc/testsuite/lib/target-supports.exp?


r~

Re: [cxx-mem-model 2/2] arm: Install __sync libfuncs for Linux.

[Richard Henderson]

Ping 2.

r~

On 11/03/2011 04:24 PM, Richard Henderson wrote:
> Cc: Richard Earnshaw 
> ---
>  gcc/config/arm/arm.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 5f0d562..9963faa 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -1096,6 +1096,10 @@ arm_set_fixed_conv_libfunc (convert_optab optable, 
> enum machine_mode to,
>  static void
>  arm_init_libfuncs (void)
>  {
> +  /* For Linux, we have access to kernel support for atomic operations.  */
> +  if (arm_abi == ARM_ABI_AAPCS_LINUX)
> +init_sync_libfuncs (8);
> +
>/* There are no special library functions unless we are using the
>   ARM BPABI.  */
>if (!TARGET_BPABI)

Re: Memset/memcpy patch

[Michael Zolotukhin]

I found and fixed another problem in the latest memcpy/memest changes
- with this fix all the failing tests mentioned in #51134 started
passing. Bootstraps are also ok.
Though I still see fails in 32-bit make check, so probably, it'd be
better to revert the changes till these fails are fixed.

On 21 November 2011 20:36, Michael Zolotukhin
 wrote:
> Hi,
>
> Continuing investigation of fails on bootstrap I found next problem
> (besides the problem with unknown alignment described above): there is
> a mess with size_needed and epilogue_size_needed when we generate
> epilogue loop which also use SSE-moves, but no unrolled - that's
> probably the reason of the fails we saw.
>
> Please check the attached patch - though the full testing isn't over
> yet. bootstraps seem to be ok as well as arrayarg.f90-test (with
> sse_loop enabled).
>
> On 19 November 2011 05:38, Jan Hubicka  wrote:
>>> Given that x86 memset/memcpy is still broken, I think we should revert
>>> it for now.
>>
>> Well, looking into the code, the SSE alignment issues needs work - the
>> alignment test merely tests whether some alignmnet is known not whether 16 
>> byte
>> alignment is known that is the cause of failures in 32bit bootstrap.  I 
>> originally
>> convinced myself that this is safe since we soot for unaligned load/stores 
>> anyway.
>>
>>
>> I've commited the following patch that disabled SSE codegen and unbreaks atom
>> bootstrap.  This seems more sensible to me given that the patch cumulated 
>> some
>> good improvements on the non-SSE path as well and we could return into the 
>> SSE
>> alignment issues incremntally.  There is still falure in the fortran testcase
>> that I am convinced is previously latent issue.
>>
>> I will be offline tomorrow.  If there are futher serious problems, just fell
>> free to revert the changes and we could look into them for next stage1.
>>
>> Honza
>>
>>        * i386.c (atom_cost): Disable SSE loop until alignment issues are 
>> fixed.
>> Index: i386.c
>> ===
>> --- i386.c      (revision 181479)
>> +++ i386.c      (working copy)
>> @@ -1783,18 +1783,18 @@ struct processor_costs atom_cost = {
>>   /* stringop_algs for memcpy.
>>      SSE loops works best on Atom, but fall back into non-SSE unrolled loop 
>> variant
>>      if that fails.  */
>> -  {{{libcall, {{4096, sse_loop}, {4096, unrolled_loop}, {-1, libcall}}}, /* 
>> Known alignment.  */
>> -    {libcall, {{4096, sse_loop}, {4096, unrolled_loop}, {-1, libcall,
>> -   {{libcall, {{2048, sse_loop}, {2048, unrolled_loop}, {-1, libcall}}}, /* 
>> Unknown alignment.  */
>> -    {libcall, {{2048, sse_loop}, {2048, unrolled_loop},
>> +  {{{libcall, {{4096, unrolled_loop}, {-1, libcall}}}, /* Known alignment.  
>> */
>> +    {libcall, {{4096, unrolled_loop}, {-1, libcall,
>> +   {{libcall, {{2048, unrolled_loop}, {-1, libcall}}}, /* Unknown 
>> alignment.  */
>> +    {libcall, {{2048, unrolled_loop},
>>               {-1, libcall},
>>
>>   /* stringop_algs for memset.  */
>> -  {{{libcall, {{4096, sse_loop}, {4096, unrolled_loop}, {-1, libcall}}}, /* 
>> Known alignment.  */
>> -    {libcall, {{4096, sse_loop}, {4096, unrolled_loop}, {-1, libcall,
>> -   {{libcall, {{1024, sse_loop}, {1024, unrolled_loop},         /* Unknown 
>> alignment.  */
>> +  {{{libcall, {{4096, unrolled_loop}, {-1, libcall}}}, /* Known alignment.  
>> */
>> +    {libcall, {{4096, unrolled_loop}, {-1, libcall,
>> +   {{libcall, {{1024, unrolled_loop},   /* Unknown alignment.  */
>>               {-1, libcall}}},
>> -    {libcall, {{2048, sse_loop}, {2048, unrolled_loop},
>> +    {libcall, {{2048, unrolled_loop},
>>               {-1, libcall},
>>   1,                                   /* scalar_stmt_cost.  */
>>   1,                                   /* scalar load_cost.  */
>
>
>
> --
> ---
> Best regards,
> Michael V. Zolotukhin,
> Software Engineer
> Intel Corporation.



-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.

Re: [wwwdocs] [RFA] Update gcc-4.7/changes.html to document -mcpu=cortex-a7

[Gerald Pfeifer]

On Mon, 21 Nov 2011, Matthew Gretton-Dann wrote:
The attached patch updates gcc-4.7/changes.html to document the addition 
of support in the ARM backend for Cortex-A7 via the -mcpu=cortex-a7 
command line option.


Thanks, Matthew.  I just applied that patch on your behalf.

Gerald

Re: [PATCH] Fix libjava build on current git glibc (PR bootstrap/50888)

[Tom Tromey]

> "Jakub" == Jakub Jelinek  writes:

Jakub> As discussed in the PR, libjava fails to build against latest
Jakub> glibc, because prims.cc is compiled with -fnon-call-exceptions,
Jakub> uses ctype.h and libgcj isn't linked against -lsupc++ or -lstdc++.
Jakub> isspace in latest glibc is a throw() inline that calls a throw()
Jakub> function pointer.  Unfortunately, with -fnon-call-exceptions
Jakub> the compiler doesn't have a guarantee that the function pointer
Jakub> that is being called is always valid (it is in glibc) and thus adds
Jakub> a __cxa_call_unexpected call if the call would throw and that symbol
Jakub> isn't satisfied during linking of libgcj and apps against it.

BTW, it seems odd to me that this function is marked throw() instead of
__attribute__((nothrow)).  The latter would avoid this problem entirely.

Tom

Re: [PATCH] Fix libjava build on current git glibc (PR bootstrap/50888)

[Tom Tromey]

> "Jakub" == Jakub Jelinek  writes:

Jakub> 2011-11-23  Jakub Jelinek  
Jakub>  PR bootstrap/50888
Jakub>  * prims.cc: Don't include ctype.h.
Jakub>  (c_isspace): Define.
Jakub>  (next_property_key, next_property_value): Use it instead
Jakub>  of isspace.

This is ok.

Tom

[RFC] PR C++/51225

[Paolo Carlini]

Hi,

today I have been analyzing this issue - not terribly urgent, it's a 
regression but the ICE is on *invalid*. It happens only in C++11 mode 
and the test is the following, very simple:


template  struct A {};

template  void foo()
{
  A  a;
}



This is what happens. First we build anyway a CAST_EXPR even if the 
argument in this case is obviously error_mark_node, because in general, 
per the comment in cp_parser_parenthesized_expression_list, this leads 
to better diagnostics.


Then, in C++98 mode the CAST_EXPR is folded by fold_non_dependent_expr 
(called by cp_parser_template_argument immediately after 
cp_parser_constant_expression), because in that mode, the 
potential_constant_expression call which gates the tsubst_copy_and_build 
call returns true unconditionally. Instead, in C++11 mode it recurses 
until error_mark_node and returns false. This means that the CAST_EXPR 
is not simplified and can reach cxx_eval_constant_expression which 
doesn't know how to handle it and ICEs.


Thus, what to do? Definitely adding CAST_EXPR to the switch works, but 
I'm wondering if we could do something else... but doesn't seem easy to 
me given the above. For example, I suppose changing 
potential_constant_expression to return true for error_mark_node would 
be catastrophic, even if error_mark_node is definitely constant ;) 
Seriously, ideas?


Thanks!
Paolo.

[PATCH] Run remove_unreachable_handlers before expansion if needed (PR tree-optimization/50682)

[Jakub Jelinek]

Hi!

As mentioned in the PR, if gimple_purge_dead_eh_edges is ever called
after ehcleanup2 pass (or in its after todos as in the testcase below),
nothing removes the unreachable EH regions and we crash either in
cleanup_dead_labels_eh or, if we ignore those there, later on during
emitting of exception info.

We could run remove_unreachable_handlers unconditionally again shortly
before expansion, but that needs a walk of all stmts, so this
patch chooses to do it only if it sees some landing pads got removed.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2011-11-23  Jakub Jelinek  

PR tree-optimization/50682
* tree-eh.c (maybe_remove_unreachable_handlers): New function.
* tree-flow.h (maybe_remove_unreachable_handlers): New prototype.
* tree-optimize.c (execute_cleanup_cfg_post_optimizing): Call it.

* g++.dg/opt/pr50682.C: New test.

--- gcc/tree-eh.c.jj2011-11-08 23:35:12.0 +0100
+++ gcc/tree-eh.c   2011-11-23 17:32:10.726659121 +0100
@@ -3473,6 +3473,29 @@ remove_unreachable_handlers (void)
 #endif
 }
 
+/* Remove unreachable handlers if any landing pads have been removed after
+   last ehcleanup pass (due to gimple_purge_dead_eh_edges).  */
+
+void
+maybe_remove_unreachable_handlers (void)
+{
+  eh_landing_pad lp;
+  int i;
+
+  if (cfun->eh == NULL)
+return;
+  
+  for (i = 1; VEC_iterate (eh_landing_pad, cfun->eh->lp_array, i, lp); ++i)
+if (lp && lp->post_landing_pad)
+  {
+   if (label_to_block (lp->post_landing_pad) == NULL)
+ {
+   remove_unreachable_handlers ();
+   return;
+ }
+  }
+}
+
 /* Remove regions that do not have landing pads.  This assumes
that remove_unreachable_handlers has already been run, and
that we've just manipulated the landing pads since then.  */
--- gcc/tree-flow.h.jj  2011-11-08 23:35:12.0 +0100
+++ gcc/tree-flow.h 2011-11-23 17:33:27.211192957 +0100
@@ -789,6 +789,7 @@ extern bool maybe_duplicate_eh_stmt_fn (
 extern bool maybe_duplicate_eh_stmt (gimple, gimple);
 extern bool verify_eh_edges (gimple);
 extern bool verify_eh_dispatch_edge (gimple);
+extern void maybe_remove_unreachable_handlers (void);
 
 /* In tree-ssa-pre.c  */
 struct pre_expr_d;
--- gcc/tree-optimize.c.jj  2011-08-18 08:36:01.0 +0200
+++ gcc/tree-optimize.c 2011-11-23 17:34:12.661916087 +0100
@@ -159,6 +159,7 @@ static unsigned int
 execute_cleanup_cfg_post_optimizing (void)
 {
   cleanup_tree_cfg ();
+  maybe_remove_unreachable_handlers ();
   cleanup_dead_labels ();
   group_case_labels ();
   if ((flag_compare_debug_opt || flag_compare_debug)
--- gcc/testsuite/g++.dg/opt/pr50682.C.jj   2011-11-23 17:40:01.352786764 
+0100
+++ gcc/testsuite/g++.dg/opt/pr50682.C  2011-11-23 17:39:20.0 +0100
@@ -0,0 +1,39 @@
+// PR tree-optimization/50682
+// { dg-do compile }
+// { dg-options "-O2 -fnon-call-exceptions -ftracer -fno-tree-ccp 
-fno-tree-copy-prop -fno-tree-dce" }
+
+void foo () __attribute__ ((__noreturn__));
+int baz ();
+
+const int &
+bar (const int &x, const int &y)
+{
+  if (x >= y)
+return y;
+  return x;
+}
+
+int a, b;
+
+struct S
+{
+  ~S ();
+  bool m ()
+  {
+int l = bar (a, b);
+int r = baz ();
+if (r)
+r = l;
+  return r;
+  }
+};
+
+void
+test ()
+{
+  S s;
+  if (!s.m ())
+foo ();
+  if (!s.m ())
+foo ();
+}

Jakub

[PATCH] Fix libjava build on current git glibc (PR bootstrap/50888)

[Jakub Jelinek]

Hi!

As discussed in the PR, libjava fails to build against latest
glibc, because prims.cc is compiled with -fnon-call-exceptions,
uses ctype.h and libgcj isn't linked against -lsupc++ or -lstdc++.
isspace in latest glibc is a throw() inline that calls a throw()
function pointer.  Unfortunately, with -fnon-call-exceptions
the compiler doesn't have a guarantee that the function pointer
that is being called is always valid (it is in glibc) and thus adds
a __cxa_call_unexpected call if the call would throw and that symbol
isn't satisfied during linking of libgcj and apps against it.

In all locales on my box isspace is equivalent to POSIX locale isspace
(while iswspace is true also for various other characters, they are
always multi-byte and thus isspace which works on single byte only
isn't true for them), so this patch effectively makes no difference
in libgcj behavior.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.6?

2011-11-23  Jakub Jelinek  

PR bootstrap/50888
* prims.cc: Don't include ctype.h.
(c_isspace): Define.
(next_property_key, next_property_value): Use it instead
of isspace.

--- libjava/prims.cc.jj 2009-05-04 16:46:48.0 +0200
+++ libjava/prims.cc2011-11-23 13:56:34.067198033 +0100
@@ -38,7 +38,6 @@ details.  */
 #endif
 
 #ifndef DISABLE_GETENV_PROPERTIES
-#include 
 #include 
 #define PROCESS_GCJ_PROPERTIES process_gcj_properties()
 #else
@@ -985,6 +984,8 @@ static java::lang::Thread *main_thread;
 
 #ifndef DISABLE_GETENV_PROPERTIES
 
+#define c_isspace(c) (memchr (" \t\n\r\v\f", c, 6) != NULL)
+
 static char *
 next_property_key (char *s, size_t *length)
 {
@@ -993,7 +994,7 @@ next_property_key (char *s, size_t *leng
   JvAssert (s);
 
   // Skip over whitespace
-  while (isspace (*s))
+  while (c_isspace (*s))
 s++;
 
   // If we've reached the end, return NULL.  Also return NULL if for
@@ -1005,7 +1006,7 @@ next_property_key (char *s, size_t *leng
 
   // Determine the length of the property key.
   while (s[l] != 0
-&& ! isspace (s[l])
+&& ! c_isspace (s[l])
 && s[l] != ':'
 && s[l] != '=')
 {
@@ -1027,19 +1028,19 @@ next_property_value (char *s, size_t *le
 
   JvAssert (s);
 
-  while (isspace (*s))
+  while (c_isspace (*s))
 s++;
 
   if (*s == ':'
   || *s == '=')
 s++;
 
-  while (isspace (*s))
+  while (c_isspace (*s))
 s++;
 
   // Determine the length of the property value.
   while (s[l] != 0
-&& ! isspace (s[l])
+&& ! c_isspace (s[l])
 && s[l] != ':'
 && s[l] != '=')
 {

Jakub

[committed] Fix uninitialized var problem introduced with the sse memset changes (PR target/51261)

[Jakub Jelinek]

Hi!

With -O0 decide_alg wouldn't initialize *dynamic_check and the callers
would use an uninitialized variable.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious.

2011-11-23  Jakub Jelinek  

PR target/51261
* config/i386/i386.c (decide_alg): Initialize *dynamic_check
even if !optimize.

* gcc.dg/pr51261.c: New test.

--- gcc/config/i386/i386.c.jj   2011-11-21 16:21:58.0 +0100
+++ gcc/config/i386/i386.c  2011-11-23 13:06:18.185380361 +0100
@@ -22106,12 +22106,12 @@ decide_alg (HOST_WIDE_INT count, HOST_WI
   else
 optimize_for_speed = true;
 
+  *dynamic_check = -1;
   if (!optimize)
 return (rep_prefix_usable ? rep_prefix_1_byte : libcall);
 
   cost = optimize_for_speed ? ix86_cost : &ix86_size_cost;
 
-  *dynamic_check = -1;
   if (memset)
 algs = &cost->memset[align_unknown][TARGET_64BIT != 0];
   else
--- gcc/testsuite/gcc.dg/pr51261.c.jj   2011-11-23 13:12:14.493114983 +0100
+++ gcc/testsuite/gcc.dg/pr51261.c  2011-11-23 13:08:56.0 +0100
@@ -0,0 +1,9 @@
+/* PR target/51261 */
+/* { dg-do compile } */
+/* { dg-options "-fcompare-debug" } */
+
+void
+foo (void *p, int n)
+{
+  __builtin_memset (p, 0xff, n);
+}

Jakub

Re: [build] Cleanup rs6000/t-ppccomm configurations (PR other/51022)

[Joel Sherrill]

Thanks.

Works for me.  I posted test results for powerpc-rtems4.11
at http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02314.html

From the rtems perspective, you can commit it.

--joel

On 11/21/2011 12:08 PM, Rainer Orth wrote:

Joel Sherrill  writes:


Does this patch apply OK for others?

Ranier.. you can just send me the impacted files if you like.  I have
no local changes to libgcc.

$ cat /tmp/libgcc-t-savresfgpr.patch | patch -p1
patching file libgcc/config.host
Hunk #1 succeeded at 843 (offset -9 lines).
patching file libgcc/config/rs6000/t-ppccomm
patching file libgcc/config/rs6000/t-ppccomm-ldbl
patching file libgcc/config/rs6000/t-ppccomm
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 21.
2 out of 2 hunks FAILED -- saving rejects to file
libgcc/config/rs6000/t-ppccomm.rej

Released versions of patch cannot deal with git-style patches (a copy in
this case), it seems.  git patch (or a snapshot from alpha.gnu.org)
should be ok.

I'm including libgcc/config/rs6000/t-savresfgpr for your convenience.

Rainer

Re: [PATCH] Fix early inliner inlining uninlinable functions

[Diego Novillo]

On Sat, Nov 5, 2011 at 07:02, Iain Sandoe
 wrote:
>
> On 28 Oct 2011, at 13:57, Richard Guenther wrote:
>
>>
>> We fail to keep the cannot-inline flag up-to-date when turning
>> indirect to direct calls.  The following patch arranges to do
>> this during statement folding (which should always be called
>> when that happens).  It also makes sure to copy the updated flag
>> to the edge when iterating early inlining.
>
> This: http://gcc.gnu.org/ml/gcc-cvs/2011-11/msg00046.html
>
> regresses:
> acats/c740203a (x86-64-darwin10)
> gnat/aliasing3.adb  (m64 i486-darwin9 and x86-64-darwin10)
> ... don't know about other platforms at present.

I am also seeing a regression in some C++ code, specifically, this
call to gimple_call_set_cannot_inline() is not updating the
call_stmt_cannot_inline_p field in the corresponding call graph edge

!   if (callee
!   && !gimple_check_call_matching_types (stmt, callee))
! gimple_call_set_cannot_inline (stmt, true);

In this code I'm trying to build, we fail the assertion in can_inline_edge_p:

  /* Be sure that the cannot_inline_p flag is up to date.  */
  gcc_checking_assert (!e->call_stmt
   || (gimple_call_cannot_inline_p (e->call_stmt)
   == e->call_stmt_cannot_inline_p)

because gimple_fold_call did not update the inline flag on the edge.

I grepped for calls to gimple_call_set_cannot_inline() and we don't
always bother to update the corresponding edge.  I think the safest
approach here would be to make sure that we always do (patch below).

Thoughts?


Diego.

diff --git a/gcc/gimple.c b/gcc/gimple.c
index 071c651..e2b082a 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -5558,4 +5558,31 @@ gimple_asm_clobbers_memory_p (const_gimple stmt)

   return false;
 }
+
+
+/* Set the inlinable status of GIMPLE_CALL S to INLINABLE_P.  */
+
+void
+gimple_call_set_cannot_inline (gimple s, bool inlinable_p)
+{
+  bool prev_inlinable_p;
+
+  GIMPLE_CHECK (s, GIMPLE_CALL);
+
+  prev_inlinable_p = gimple_call_cannot_inline_p (s);
+
+  if (inlinable_p)
+s->gsbase.subcode |= GF_CALL_CANNOT_INLINE;
+  else
+s->gsbase.subcode &= ~GF_CALL_CANNOT_INLINE;
+
+  if (prev_inlinable_p != inlinable_p)
+{
+  struct cgraph_node *n = cgraph_get_node (current_function_decl);
+  struct cgraph_edge *e = cgraph_edge (n, s);
+  if (e)
+   e->call_stmt_cannot_inline_p = inlinable_p;
+}
+}
+
 #include "gt-gimple.h"
diff --git a/gcc/gimple.h b/gcc/gimple.h
index 8536c70..df31bf3 100644
--- a/gcc/gimple.h
+++ b/gcc/gimple.h
@@ -1035,6 +1035,7 @@ extern bool walk_stmt_load_store_ops (gimple, void *,
 extern bool gimple_ior_addresses_taken (bitmap, gimple);
 extern bool gimple_call_builtin_p (gimple, enum built_in_function);
 extern bool gimple_asm_clobbers_memory_p (const_gimple);
+extern void gimple_call_set_cannot_inline (gimple, bool);

 /* In gimplify.c  */
 extern tree create_tmp_var_raw (tree, const char *);
@@ -2343,19 +2344,6 @@ gimple_call_tail_p (gimple s)
 }


-/* Set the inlinable status of GIMPLE_CALL S to INLINABLE_P.  */
-
-static inline void
-gimple_call_set_cannot_inline (gimple s, bool inlinable_p)
-{
-  GIMPLE_CHECK (s, GIMPLE_CALL);
-  if (inlinable_p)
-s->gsbase.subcode |= GF_CALL_CANNOT_INLINE;
-  else
-s->gsbase.subcode &= ~GF_CALL_CANNOT_INLINE;
-}
-
-
 /* Return true if GIMPLE_CALL S cannot be inlined.  */

 static inline bool

Re: Re-merge crtstuff.c from the trans-mem branch

[Rainer Orth]

Richard Henderson  writes:

> On 11/22/2011 04:15 AM, Rainer Orth wrote:
>> This patch broke bootstrap on Solaris 8 and 9/x86 with Sun as which
>> doesn't support .hidden: linking the stage2 lto-plugin fails like this:
>> 
>> ld: fatal: relocation error: R_386_GOTOFF: file 
>> /var/gcc/regression/trunk/8-gcc/build/./prev-gcc/crtbegin.o: symbol 
>> __TMC_END__: relocation must bind locally
>> collect2: error: ld returned 1 exit status
>> make[4]: *** [liblto_plugin.la] Error 1
>
> Blah, of course it does.
>
> The first of these patches should fix this.  The second... well, I
> don't recall why we use -fno-inline atm.  It works for i386-linux,
> of course, to eliminate it.  But this is a twisty maze...

While the first patch allows Solaris 8/9 x86 bootstraps to finish
(testsuite still running), I happened to run a Solaris 10/SPARC
bootstrap that broke configuring stage 2 libgomp: even trivial
executables die with a SEGV in _init.

It turns out (still verifying with a fresh bootstrap) that the
-fno-inline removal is the culprit.

Rainer

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

Re: [RFC] Use which_alternative in preparation-statements of define_insn_and_split

[Richard Earnshaw]

On 22/11/11 19:06, Richard Henderson wrote:
> On 11/21/2011 05:38 PM, Jiangning Liu wrote:
>> But I still want to know why we don't want to support this? I don't see any
>> GCC documentation saying not allowing this usage.
> 
> Before reload, which_alternative doesn't make much sense, yet you compute it 
> anyway.  After reload, but for raw define_split, which_alternative doesn't 
> make much sense, yet you compute it anyway.
> 
> Now, either or both are fixable, but instead it seemed to me like maybe you 
> were going down the wrong path entirely.
> 
> 
> r~
> 

Plus extract_insn is a moderately expensive operation, given that we
have to scan all the alternatives in an insn to find the matching one.

I wouldn't have thought it was generally something we would want to do
on every split pattern we apply unless it is really needed.

R.

Re: Ping: Java, disable -fdelete-null-pointer-checks

[Jeff Law]

On 11/23/11 06:45, Jakub Jelinek wrote:

On Tue, Nov 22, 2011 at 01:53:54PM -0700, Jeff Law wrote:

+
+   /* Java catches catch NULL pointer exceptions, thus we can not necessarily


catches catch?

Fixed.

jeff

Re: [testsuite] Fix several atomic tests on 32-bit x86 (PR testsuite/51258)

[Richard Henderson]

On 11/23/2011 07:35 AM, Rainer Orth wrote:
> Richard Henderson  writes:
> 
>> But why don't we just change the default 64-bit target to have this enabled? 
>>  I somehow doubt that there are many people that have those very first 
>> machines that didn't have this feature...
> 
> I just saw that we still have them in large numbers...

Which suggests that the -mcx16 change by itself is wrong, we also need to check
for that cpuid bit in the sync_int_128 test.


r~

Re: Minor contrib.texi update

[Jeff Law]

On 11/23/11 04:16, Gerald Pfeifer wrote:

On Mon, 21 Nov 2011, Jeff Law wrote:

Just mind the long line

Do we wrap earlier in the texi file (first line is 79chars I think)?
Or are you referring to an output file?


I fail to find the reference now, but usually try to wrap things
such that a patch (which adds "+ " or "- ") still fits with wrapping,
or ideally a quoted patch (so ">  + " or ">  - "), so around 76.

Not a big deal, though.
I wrapped it before the checkin.  Good point about how it appears in a 
patch -- I've wrapped for that reason in the past as well.


jeff

Re: [testsuite] Fix several atomic tests on 32-bit x86 (PR testsuite/51258)

[Rainer Orth]

Richard Henderson  writes:

> But why don't we just change the default 64-bit target to have this enabled?  
> I somehow doubt that there are many people that have those very first 
> machines that didn't have this feature...

I just saw that we still have them in large numbers:

$ > isainfo -v
64-bit amd64 applications
sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc 
fpu 
32-bit i386 applications
ahf sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 
tsc fpu 
$ psrinfo -pv
The physical processor has 1 virtual processor (0)
  x86 (AuthenticAMD F5A family 15 model 5 step 10 clock 2391 MHz)
AMD Opteron(tm) Processor 250   [ Socket: 940 ]
The physical processor has 1 virtual processor (1)
  x86 (AuthenticAMD F5A family 15 model 5 step 10 clock 2391 MHz)
AMD Opteron(tm) Processor 250   [ Socket: 940 ]

These are Sun Fire V60z machines, admittedly not current, but probably
still in widespread use.

Rainer

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

Re: [PATCH] PR50325 store_bit_field: Fix for big endian targets

[Richard Earnshaw]

On 21/11/11 08:02, Eric Botcazou wrote:
> This seems to be a little risky for stage 3 though.

Being in stage 3 shouldn't stop us trying to fix bugs in the compiler:
we're not in the final run-up to a release yet (that could still be five
months away if history is anything to go by).  It should just be a
clamp-down on major new functionality.

R.

Re: [testsuite] Fix several atomic tests on 32-bit x86 (PR testsuite/51258)

[Richard Henderson]

On 11/23/2011 07:14 AM, Rainer Orth wrote:
>   PR testsuite/51258
>   * gcc.dg/atomic-compare-exchange-5.c: Add -mcx16 on i?86-*-*.
>   * gcc.dg/atomic-exchange-5.c: Likewise.
>   * gcc.dg/atomic-load-5.c: Likewise.
>   * gcc.dg/atomic-op-5.c: Likewise.
>   * gcc.dg/atomic-store-5.c: Likewise.
>   * gcc.dg/simulate-thread/atomic-other-int128.c: Fix typo.

Ok I guess...

But why don't we just change the default 64-bit target to have this enabled?  I 
somehow doubt that there are many people that have those very first machines 
that didn't have this feature...


r~

[testsuite] Fix several atomic tests on 32-bit x86 (PR testsuite/51258)

[Rainer Orth]

As described in the PR, several atomic tests were failing on bi-arch
32-bit x86 for the 64-bit multilib.  As Uros found, this is obvious and
corrected by the following patch, which also fixes a typo in
atomic-other-int128.c.

Tested with the appropriate runtest invocations on i386-pc-solaris2.10
and amd64-pc-solaris2.10, no change on the latter, the 64-bit tests pass
now (or are unsupported for the simulate-thread tests with gdb 7.1;
those fail instead with gdb 7.3.1 ;-).

Ok for mainline?

Rainer


2011-11-23  Rainer Orth  

PR testsuite/51258
* gcc.dg/atomic-compare-exchange-5.c: Add -mcx16 on i?86-*-*.
* gcc.dg/atomic-exchange-5.c: Likewise.
* gcc.dg/atomic-load-5.c: Likewise.
* gcc.dg/atomic-op-5.c: Likewise.
* gcc.dg/atomic-store-5.c: Likewise.
* gcc.dg/simulate-thread/atomic-other-int128.c: Fix typo.

# HG changeset patch
# Parent ad316ae6941ee37a3133fc84f8281ae9c07ebefa
Fix several atomic tests on 32-bit x86 (PR testsuite/51258)

diff --git a/gcc/testsuite/gcc.dg/atomic-compare-exchange-5.c b/gcc/testsuite/gcc.dg/atomic-compare-exchange-5.c
--- a/gcc/testsuite/gcc.dg/atomic-compare-exchange-5.c
+++ b/gcc/testsuite/gcc.dg/atomic-compare-exchange-5.c
@@ -2,7 +2,7 @@
values with each valid memory model.  */
 /* { dg-do run } */
 /* { dg-require-effective-target sync_int_128 } */
-/* { dg-options "-mcx16" { target { x86_64-*-* } } } */
+/* { dg-options "-mcx16" { target { i?86-*-* x86_64-*-* } } } */
 
 /* Test the execution of __atomic_compare_exchange_n builtin for an int_128.  */
 
diff --git a/gcc/testsuite/gcc.dg/atomic-exchange-5.c b/gcc/testsuite/gcc.dg/atomic-exchange-5.c
--- a/gcc/testsuite/gcc.dg/atomic-exchange-5.c
+++ b/gcc/testsuite/gcc.dg/atomic-exchange-5.c
@@ -2,7 +2,7 @@
values with each valid memory model.  */
 /* { dg-do run } */
 /* { dg-require-effective-target sync_int_128 } */
-/* { dg-options "-mcx16" { target { x86_64-*-* } } } */
+/* { dg-options "-mcx16" { target { i?86-*-* x86_64-*-* } } } */
 
 /* Test the execution of the __atomic_X builtin for a 16 byte value.  */
 
diff --git a/gcc/testsuite/gcc.dg/atomic-load-5.c b/gcc/testsuite/gcc.dg/atomic-load-5.c
--- a/gcc/testsuite/gcc.dg/atomic-load-5.c
+++ b/gcc/testsuite/gcc.dg/atomic-load-5.c
@@ -2,7 +2,7 @@
values with each valid memory model.  */
 /* { dg-do run } */
 /* { dg-require-effective-target sync_int_128 } */
-/* { dg-options "-mcx16" { target { x86_64-*-* } } } */
+/* { dg-options "-mcx16" { target { i?86-*-* x86_64-*-* } } } */
 
 extern void abort(void);
 
diff --git a/gcc/testsuite/gcc.dg/atomic-op-5.c b/gcc/testsuite/gcc.dg/atomic-op-5.c
--- a/gcc/testsuite/gcc.dg/atomic-op-5.c
+++ b/gcc/testsuite/gcc.dg/atomic-op-5.c
@@ -2,7 +2,7 @@
values with each valid memory model.  */
 /* { dg-do run } */
 /* { dg-require-effective-target sync_int_128 } */
-/* { dg-options "-mcx16" { target { x86_64-*-* } } } */
+/* { dg-options "-mcx16" { target { i?86-*-* x86_64-*-* } } } */
 
 /* Test the execution of the __atomic_*OP builtin routines for an int_128.  */
 
diff --git a/gcc/testsuite/gcc.dg/atomic-store-5.c b/gcc/testsuite/gcc.dg/atomic-store-5.c
--- a/gcc/testsuite/gcc.dg/atomic-store-5.c
+++ b/gcc/testsuite/gcc.dg/atomic-store-5.c
@@ -2,7 +2,7 @@
values with each valid memory model.  */
 /* { dg-do run } */
 /* { dg-require-effective-target sync_int_128 } */
-/* { dg-options "-mcx16" { target { x86_64-*-* } } } */
+/* { dg-options "-mcx16" { target { i?86-*-* x86_64-*-* } } } */
 
 /* Test the execution of the __atomic_store_n builtin for a 16 byte value.  */
 
diff --git a/gcc/testsuite/gcc.dg/simulate-thread/atomic-other-int128.c b/gcc/testsuite/gcc.dg/simulate-thread/atomic-other-int128.c
--- a/gcc/testsuite/gcc.dg/simulate-thread/atomic-other-int128.c
+++ b/gcc/testsuite/gcc.dg/simulate-thread/atomic-other-int128.c
@@ -1,6 +1,6 @@
 /* { dg-do link } */
 /* { dg-require-effective-target sync_int_128 } */
-/* { dg-options "-mcx16" { target { x86_64-*-* i?86-*-*] } } } */
+/* { dg-options "-mcx16" { target { x86_64-*-* i?86-*-* } } } */
 /* { dg-final { simulate-thread } } */
 
 #include 

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

Re: [PATCH] PR50325 store_bit_field: Fix for big endian targets

[Andreas Krebbel]

On 11/23/2011 03:47 PM, Richard Sandiford wrote:
> Since Andreas was fixing C++ bugs, I assume the same situation occurs there.
> What does it look like in a C++ context?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325#c4

value was (subreg:DI (reg:TI 70) 8)
and fieldmode == BLKmode

-Andreas-

Re: [PATCH] PR50325 store_bit_field: Fix for big endian targets

[Richard Sandiford]

Eric Botcazou  writes:
>> OK, I see how the two are different now, but I still don't get why the
>> current version is right.  If we say words are 16 bits for simplicity,
>> and we're storing VALUE == 0x0001_2345 into a 3-byte BLKmode bitfield,
>> surely we want to store 0x01_2345 rather than 0x00_0123?
>
> Why?  If you want this semantics, you need to use a bitfield with integer mode

It's the interpretation and mode of VALUE that I'm worried about.
Doesn't FIELDMODE describe STR_RTX (the stored bitfield) instead?

If so, it seems odd that we're using a property of STR_RTX to determine
the interpretation/justification of VALUE.  That is, we're using
FIELDMODE before, rather than after:

  /* This is the mode we must force value to, so that there will be enough
 subwords to extract.  Note that fieldmode will often (always?) be
 VOIDmode, because that is what store_field uses to indicate that this
 is a bit field, but passing VOIDmode to operand_subword_force
 is not allowed.  */
  fieldmode = GET_MODE (value);
  if (fieldmode == VOIDmode)
fieldmode = smallest_mode_for_size (nwords * BITS_PER_WORD, MODE_INT);

> In Ada, the following case is frequent: you have a record type with BLKmode 
> and 
> an alignment that causes it to padded (because the size is always a multiple 
> of the alignment).  You have a field in another record type whose type is the 
> first record type but with a representation clause that prescribes the size 
> without the padding.  The Ada compiler must accept that.  So the field is 
> made 
> a BLKmode bitfield, with DECL_SIZE (size w/o padding) smaller than TYPE_SIZE 
> (size w/ padding).  When you're assigning a value to the field, you drop the 
> rightmost bytes in memory order, which are junk since padding.

In this sort of assignment, what does VALUE look like?  Does it need to be
BLKmode?  Or can it have an integer mode?  (I assume the former, since the
latter seems contrary to what you said about integer modes above.)
Must VALUE be a memory?  Could we assert:

  gcc_assert ((fieldmode == BLKmode) == (GET_MODE (value) == BLKmode));
  gcc_assert (fieldmode != BLKmode || MEM_P (value));

at the beginning of store_bit_field_1?

Since Andreas was fixing C++ bugs, I assume the same situation occurs there.
What does it look like in a C++ context?

Richard

Re: [PATCH 0/2] Add atomic support to m68k

[Mikael Pettersson]

Mikael Pettersson writes:
 > Richard Henderson writes:
 >  > The first patch adds support for the m68k-linux syscall.  The second
 >  > patch adds native support for the m680[2346]0 CAS instruction, and
 >  > the m68000/Coldfire TAS instruction.
 >  > 
 >  > Both tested only via cross-compile.  
 >  > 
 >  > Please test...
 > 
 > Thanks Richard.  I'm currently bootstrapping and regtesting this
 > "natively" on aranym.

Bootstrapped fine and tested mostly OK.  Seems to have eliminated all
atomics-related regressions in 4.7-2012.  Compared to 4.7-2005
I have the following test suite result changes:

--- mail-report-4.7-2005-0  2011-11-09 21:31:02.0 +0100
+++ mail-report-4.7-2012-with-atomics   2011-11-23 04:59:39.0 
+0100
@@ -1,5 +1,5 @@
 cat <<'EOF' |
-LAST_UPDATED: Obtained from SVN: trunk revision 181017
+LAST_UPDATED: Obtained from SVN: trunk revision 181327
 
 Native configuration is m68k-unknown-linux-gnu
 
@@ -12,8 +12,20 @@
 FAIL: tmpdir-g++.dg-struct-layout-1/t016 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute 
 FAIL: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute 
-FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:98: note: function call is 
shrink-wrapped into error conditions."
-FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:108: note: function call is 
shrink-wrapped into error conditions."
+FAIL: g++.dg/cdce3.C -std=gnu++98 scan-tree-dump cdce "cdce3.C:98: note: 
function call is shrink-wrapped into error conditions."
+FAIL: g++.dg/cdce3.C -std=gnu++98 scan-tree-dump cdce "cdce3.C:108: note: 
function call is shrink-wrapped into error conditions."
+FAIL: g++.dg/cdce3.C -std=gnu++11 scan-tree-dump cdce "cdce3.C:98: note: 
function call is shrink-wrapped into error conditions."
+FAIL: g++.dg/cdce3.C -std=gnu++11 scan-tree-dump cdce "cdce3.C:108: note: 
function call is shrink-wrapped into error conditions."
+FAIL: g++.dg/opt/cfg3.C -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/opt/cfg3.C -std=gnu++98 (test for excess errors)
+FAIL: g++.dg/opt/cfg3.C -std=gnu++11 (internal compiler error)
+FAIL: g++.dg/opt/cfg3.C -std=gnu++11 (test for excess errors)
+FAIL: c-c++-common/gomp/atomic-10.c -std=gnu++98 scan-tree-dump-times ompexp 
"__atomic_fetch_add" 4
+FAIL: c-c++-common/gomp/atomic-10.c -std=gnu++11 scan-tree-dump-times ompexp 
"__atomic_fetch_add" 4
+FAIL: c-c++-common/gomp/atomic-3.c -std=gnu++98 scan-tree-dump-times ompexp 
"xyzzy, 4" 1
+FAIL: c-c++-common/gomp/atomic-3.c -std=gnu++11 scan-tree-dump-times ompexp 
"xyzzy, 4" 1
+FAIL: c-c++-common/gomp/atomic-9.c -std=gnu++98 scan-tree-dump-times ompexp 
"__atomic_fetch_add" 1
+FAIL: c-c++-common/gomp/atomic-9.c -std=gnu++11 scan-tree-dump-times ompexp 
"__atomic_fetch_add" 1
 FAIL: g++.dg/guality/redeclaration1.C  -O0  line 17 i == 24
 FAIL: g++.dg/guality/redeclaration1.C  -O1  line 17 i == 24
 FAIL: g++.dg/guality/redeclaration1.C  -O2  line 17 i == 24
@@ -106,11 +118,11 @@
 
=== g++ Summary ===
 
-# of expected passes   26073
-# of unexpected failures   96
-# of expected failures 151
-# of unsupported tests 413
-/mnt/scratch/objdir47/gcc/testsuite/g++/../../g++  version 4.7.0 2005 
(experimental) (GCC) 
+# of expected passes   43635
+# of unexpected failures   108
+# of expected failures 280
+# of unsupported tests 633
+/mnt/scratch/objdir47/gcc/testsuite/g++/../../g++  version 4.7.0 2012 
(experimental) (GCC) 
 
=== gcc tests ===
 
@@ -150,6 +162,10 @@
 FAIL: gcc.c-torture/execute/arith-rand-ll.c execution,  -O3 
-fomit-frame-pointer -funroll-all-loops -finline-functions 
 FAIL: gcc.c-torture/execute/arith-rand-ll.c execution,  -O3 -g 
 FAIL: gcc.c-torture/execute/arith-rand-ll.c execution,  -Os 
+FAIL: gcc.c-torture/execute/stdarg-3.c compilation,  -O3 -fomit-frame-pointer 
-funroll-loops  (internal compiler error)
+UNRESOLVED: gcc.c-torture/execute/stdarg-3.c execution,  -O3 
-fomit-frame-pointer -funroll-loops 
+FAIL: gcc.c-torture/execute/stdarg-3.c compilation,  -O3 -fomit-frame-pointer 
-funroll-all-loops -finline-functions  (internal compiler error)
+UNRESOLVED: gcc.c-torture/execute/stdarg-3.c execution,  -O3 
-fomit-frame-pointer -funroll-all-loops -finline-functions 

(Ignore this one, it's also in vanilla 4.7-2012.)

 FAIL: gcc.c-torture/execute/ieee/compare-fp-1.c execution,  -O0 
 FAIL: gcc.c-torture/execute/ieee/compare-fp-1.c execution,  -O1 
 FAIL: gcc.c-torture/execute/ieee/compare-fp-1.c execution,  -O2 
@@ -194,6 +210,9 @@
 FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc1 "Optimizing range tests 
a_[0-9]*.D. -.128, 159. and -.192, 223.[
 FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc2 "Optimizing range tests 
D.[0-9]*_[0-9]* -.0, 31. and -.128, 159.[
 FAIL: gcc.dg/pr46647.c scan-tree-dump-not optimized "memset"
+FAIL: c-c++-common/gomp/atomic-10.c scan-t

Re: building trunk fails due to C++

[Michael Matz]

Hi,

On Tue, 22 Nov 2011, Gary Funck wrote:

> Thanks for the tip.  Typically, we don't build with 
> --enable-checking=all, however ...
> 
> We build with --enable-checking=all when we're testing major changes, 
> moving GUPC to a new target architecture, etc.
> 
> In the past, it may have been slower, and certainly the final compiler 
> is slower (probably 3x-5x on average), but the extra checking did help 
> catch some bugs.

Makes sense.  What I do for this is to build (--disable-bootstrap) a 
checking=all compiler and just run the testsuite (or other tests).

> FYI, on the *very* long running compilations that I checked, the cc1plus 
> compiler appeared to be stuck in the garbage collector.
> 
> #1  0x009e838e in gt_ggc_mx_lang_tree_node (x_p=0x7fff268282d0)
> at ./gt-cp-tree.h:154

Yeah, =all includes GC checking, which includes always running the 
garbage collector even when not enough allocation activity was done.
It might very well be that the cc1plus frontend leaves more reachable 
memory live than cc1, making the repeated collection attempts hurt much 
more than with C only.  That's possibly something to investigate.


Ciao,
Michael.

Re: [google] Limit unrolling and peeling under LIPO estimates of large code size/icache pressure

[Teresa Johnson]

Tests clean on google 4-6 branch, so I will be committing this to
google/main and backporting to google/4-6 shortly.

Thanks,
Teresa

On Tue, Nov 22, 2011 at 1:26 PM, Xinliang David Li  wrote:
> The failures are independent which will be looked into at some point.
> Teresa's patch is/will be tested cleanly on google-46.
>
> David
>
> On Tue, Nov 22, 2011 at 1:12 PM, Diego Novillo  wrote:
>> On 11-11-22 16:06 , Teresa Johnson wrote:
>>>
>>> This patch is for google-main only.
>>> Tested with bootstrap and regression tests.
>>> Under LIPO, estimate the code size footprint from the partial call
>>> graph, and if it is large limit unrolling and peeling to avoid
>>> increasing icache pressure.
>>
>> So, currently, there are several broken LIPO tests in google/main, so I'm
>> not sure how testable LIPO is on the branch.  Is your patch related to any
>> of them?  (see contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
>> for a list of broken tests).
>>
>>
>> Diego.
>>
>



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: PR other/51174: handle architectures with no DECL_COMDAT_GROUP

[Jakub Jelinek]

On Wed, Nov 23, 2011 at 07:47:46AM -0600, Aldy Hernandez wrote:
> >>@@ -4198,7 +4198,7 @@ ipa_tm_create_version_alias (struct cgra
> >>   TREE_SYMBOL_REFERENCED (tm_name) = 1;
> >>
> >>   /* Perform the same remapping to the comdat group.  */
> >>-  if (DECL_COMDAT (new_decl))
> >>+  if (HAVE_COMDAT_GROUP&&  DECL_COMDAT (new_decl))
> >> DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP 
> >> (old_decl));
> >>
> >>   new_node = cgraph_same_body_alias (NULL, new_decl, info->new_decl);

Wouldn't it be better to test if (DECL_ONE_ONLY (new_decl))
instead?  That is actually test for non-NULL DECL_COMDAT_GROUP
and is what e.g. cp/ uses as guards on tweaking DECL_COMDAT_GROUP.

BTW, the formatting is wrong above, no space before && and two spaces after
it.

Jakub

[Ada] Dependencies of virtual extending projects

[Arnaud Charlet]

This change ensures that virtual extending projects generated when processing
an EXTENDS ALL project have a closure that is consistent with that of the
extending project. This is required to build DSA applications with the
gnatdist partitioning tool when RCI units come from some imported project.

No simple test (requires DSA setup).

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Thomas Quinot  

* prj-part.adb (Extension_Withs): New global variable,
contains the head of the list of WITH clauses from the EXTENDS
ALL projects for which virtual packages are being created.
(Look_For_Virtual_Projects_For): When recursing through
an EXTENDS ALL, add the WITH clauses of the extending
project to Extension_Withs.  When adding a project to the
Virtual_Hash, record the associated Extension_Withs list.
(Create_Virtual_Extending_Project): Add a copy of the appropriate
Extension_Withs to the virtual project.

Index: prj-part.adb
===
--- prj-part.adb(revision 181662)
+++ prj-part.adb(working copy)
@@ -99,12 +99,15 @@
package Virtual_Hash is new GNAT.HTable.Simple_HTable
  (Header_Num => Header_Num,
   Element=> Project_Node_Id,
-  No_Element => Empty_Node,
+  No_Element => Project_Node_High_Bound,
   Key=> Project_Node_Id,
   Hash   => Prj.Tree.Hash,
   Equal  => "=");
-   --  Hash table to store the node id of the project for which a virtual
-   --  extending project need to be created.
+   --  Hash table to store the node ids of projects for which a virtual
+   --  extending project need to be created. The corresponding value is the
+   --  head of a list of WITH clauses corresponding to the context of the
+   --  enclosing EXTEND ALL projects. Note: Default_Element is Project_Node_
+   --  High_Bound because we want Empty_Node to be a possible value.
 
package Processed_Hash is new GNAT.HTable.Simple_HTable
  (Header_Num => Header_Num,
@@ -148,11 +151,13 @@
--  Check that an aggregate project only imports abstract projects
 
procedure Create_Virtual_Extending_Project
- (For_Project  : Project_Node_Id;
-  Main_Project : Project_Node_Id;
-  In_Tree  : Project_Node_Tree_Ref);
+ (For_Project : Project_Node_Id;
+  Main_Project: Project_Node_Id;
+  Extension_Withs : Project_Node_Id;
+  In_Tree : Project_Node_Tree_Ref);
--  Create a virtual extending project of For_Project. Main_Project is
-   --  the extending all project.
+   --  the extending all project. Extension_Withs is the head of a WITH clause
+   --  list to be added to the created virtual project.
--
--  The String_Value_Of is not set for the automatically added with
--  clause and keeps the default value of No_Name. This enables Prj.PP
@@ -236,14 +241,45 @@
--  Returns No_Name if the path name is invalid, because the corresponding
--  project name does not have the syntax of an ada identifier.
 
+   function Copy_With_Clause
+ (With_Clause : Project_Node_Id;
+  In_Tree : Project_Node_Tree_Ref;
+  Next_Clause : Project_Node_Id) return Project_Node_Id;
+   --  Return a copy of With_Clause in In_Tree, whose Next_With_Clause is the
+   --  indicated one.
+
+   --
+   -- Copy_With_Clause --
+   --
+
+   function Copy_With_Clause
+ (With_Clause : Project_Node_Id;
+  In_Tree : Project_Node_Tree_Ref;
+  Next_Clause : Project_Node_Id) return Project_Node_Id
+   is
+  New_With_Clause : constant Project_Node_Id :=
+  Default_Project_Node (In_Tree, N_With_Clause);
+   begin
+  Set_Name_Of (New_With_Clause, In_Tree,
+Name_Of (With_Clause, In_Tree));
+  Set_Path_Name_Of (New_With_Clause, In_Tree,
+Path_Name_Of (With_Clause, In_Tree));
+  Set_Project_Node_Of (New_With_Clause, In_Tree,
+Project_Node_Of (With_Clause, In_Tree));
+  Set_Next_With_Clause_Of (New_With_Clause, In_Tree, Next_Clause);
+
+  return New_With_Clause;
+   end Copy_With_Clause;
+
--
-- Create_Virtual_Extending_Project --
--
 
procedure Create_Virtual_Extending_Project
- (For_Project  : Project_Node_Id;
-  Main_Project : Project_Node_Id;
-  In_Tree  : Project_Node_Tree_Ref)
+ (For_Project : Project_Node_Id;
+  Main_Project: Project_Node_Id;
+  Extension_Withs : Project_Node_Id;
+  In_Tree : Project_Node_Tree_Ref)
is
 
   Virtual_Name : constant String :=
@@ -323,7 +359,8 @@
 
   Project_Declaration := Project_Declaration_Of (Virtual_Project, In_Tree);
 
-  --  With clause
+  --  Add a WITH clause to the main project to import the newly created
+  --  virtual extending project.
 
   Set_Name_Of (With_Clau

[Ada] Consistent target names

[Arnaud Charlet]

This change makes the target names used by various tools consistent across the
whole tool chain. In particular, Standard'Target_Name and the default search
path for projects are changed to match the GCC target name.

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Thomas Quinot  

* Make-generated.in (Sdefault.Target_Name): Set to
$(target_noncanonical) instead of $(target) for consistency.

Index: Make-generated.in
===
--- Make-generated.in   (revision 181662)
+++ Make-generated.in   (working copy)
@@ -72,7 +72,7 @@
$(ECHO) "   S0 : constant String := \"$(prefix)/\";" >>tmp-sdefault.adb
$(ECHO) "   S1 : constant String := \"$(ADA_INCLUDE_DIR)/\";" 
>>tmp-sdefault.adb
$(ECHO) "   S2 : constant String := \"$(ADA_RTL_OBJ_DIR)/\";" 
>>tmp-sdefault.adb
-   $(ECHO) "   S3 : constant String := \"$(target)/\";" >>tmp-sdefault.adb
+   $(ECHO) "   S3 : constant String := \"$(target_noncanonical)/\";" 
>>tmp-sdefault.adb
$(ECHO) "   S4 : constant String := \"$(libsubdir)/\";" 
>>tmp-sdefault.adb
$(ECHO) "   function Include_Dir_Default_Name return String_Ptr is" 
>>tmp-sdefault.adb
$(ECHO) "   begin" >>tmp-sdefault.adb

[Ada] Aspect specifications on subprogram renaming declarations

[Arnaud Charlet]

The syntax of Ada 2012 accepts aspect specifications on renaming declarations,
but no language-defined aspects exist for them, so that pre- and postconditions
on these declarations must be rejected.

Compiling db.ads in Ada 2012 mode must yield:

db.ads:9:07: incorrect placement of aspect "PRE"
db.ads:10:07: incorrect placement of aspect "POST"
db.ads:11:06: incorrect placement of aspect "TEST_CASE"

---
package DB is
   type Account is tagged record
  X : Integer;
   end record;

   procedure Open (It : out Account; V : Integer);
   procedure Op (It : out Account; V : Integer) renames Open
   with
  Pre  => (V > 0),
  Post => (It.X = V),
 Test_Case => (Name => "existing account",
   Mode => Nominal,
   Ensures  =>  T.X > 0);
end DB;

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Ed Schonberg  

* sem_ch8.adb (Analyze_Subprogram_Renaming_Declaration):
If the declaration has aspects, analyze them so they can be
properly rejected.

Index: sem_ch8.adb
===
--- sem_ch8.adb (revision 181662)
+++ sem_ch8.adb (working copy)
@@ -52,6 +52,7 @@
 with Sem_Ch4;  use Sem_Ch4;
 with Sem_Ch6;  use Sem_Ch6;
 with Sem_Ch12; use Sem_Ch12;
+with Sem_Ch13; use Sem_Ch13;
 with Sem_Disp; use Sem_Disp;
 with Sem_Dist; use Sem_Dist;
 with Sem_Eval; use Sem_Eval;
@@ -2848,6 +2849,13 @@
   ("?redundant renaming, entity is directly visible", Name (N));
   end if;
 
+  --  Implementation-defined aspect specifications can appear in a renaming
+  --  declaration, but not language-defined ones.
+
+  if Has_Aspects (N) then
+ Analyze_Aspect_Specifications (N, New_S);
+  end if;
+
   Ada_Version := Save_AV;
   Ada_Version_Explicit := Save_AV_Exp;
end Analyze_Subprogram_Renaming;

[Ada] Taft-amendment types and Ada 2012 type invariants

[Arnaud Charlet]

The presence of a body freezes all entities previously declared
in the current list of declarations, but this does not apply
if the body does not come from source. A type invariant is
transformed into a subprogram body which is placed at the end of
the private part of the current package, but this body does not
freeze incomplete types that may be declared in this private part.

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Ed Schonberg  

* freeze.adb (Freeze_All_Ent): An incomplete type is not
frozen by a subprogram body that does not come from source.

Index: freeze.adb
===
--- freeze.adb  (revision 181662)
+++ freeze.adb  (working copy)
@@ -1342,7 +1342,9 @@
 
 --  If an incomplete type is still not frozen, this may be a
 --  premature freezing because of a body declaration that follows.
---  Indicate where the freezing took place.
+--  Indicate where the freezing took place. Freezing will happen
+--  if the body comes from source, but not if it is internally
+--  generated, for example as the body of a type invariant.
 
 --  If the freezing is caused by the end of the current declarative
 --  part, it is a Taft Amendment type, and there is no error.
@@ -1360,8 +1362,9 @@
  N_Protected_Body,
  N_Task_Body)
 or else Nkind (Bod) in N_Body_Stub)
- and then
-   List_Containing (After) = List_Containing (Parent (E))
+and then
+ List_Containing (After) = List_Containing (Parent (E))
+and then Comes_From_Source (Bod)
   then
  Error_Msg_Sloc := Sloc (Next (After));
  Error_Msg_NE

Re: PR other/51174: handle architectures with no DECL_COMDAT_GROUP

[Aldy Hernandez]

Richard, do you have an opinion on either one of these approaches?

Both bootstrap and regtest on x86-64 Linux and David AIX :-).  OK? 
Which one?


On 11/22/11 07:58, David Edelsohn wrote:

On Tue, Nov 22, 2011 at 8:06 AM, Aldy Hernandez  wrote:


This looks weird -- you're seting D_C_G after H_C_G is false?

We've already done copy_decl anyway -- you should be able to drop the
else.



David, can you try the following and see if it fixes the problem on your
end?

Index: trans-mem.c
===
--- trans-mem.c (revision 181588)
+++ trans-mem.c (working copy)
@@ -4198,7 +4198,7 @@ ipa_tm_create_version_alias (struct cgra
   TREE_SYMBOL_REFERENCED (tm_name) = 1;

   /* Perform the same remapping to the comdat group.  */
-  if (DECL_COMDAT (new_decl))
+  if (HAVE_COMDAT_GROUP&&  DECL_COMDAT (new_decl))
 DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl));

   new_node = cgraph_same_body_alias (NULL, new_decl, info->new_decl);
@@ -4233,7 +4233,7 @@ ipa_tm_create_version (struct cgraph_nod
   TREE_SYMBOL_REFERENCED (tm_name) = 1;

   /* Perform the same remapping to the comdat group.  */
-  if (DECL_COMDAT (new_decl))
+  if (HAVE_COMDAT_GROUP&&  DECL_COMDAT (new_decl))
 DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl));

   new_node = cgraph_copy_node_for_versioning (old_node, new_decl, NULL,
NULL);



I assume this will work because AIX never uses the info in DECL_COMDAT_GROUP.

Note that ipa_tm_create_version() calls copy_node(), but
ipa_tm_create_version_alias() *DOES NOT*, it calls build_decl(), so
D_C_G will be garbage.

Yes, setting D_C_G looks strange with !H_C_G, but note that many
places in GCC blindly copy D_C_G or initialize it to 0.

- David

Re: Ping: Java, disable -fdelete-null-pointer-checks

[Jakub Jelinek]

On Tue, Nov 22, 2011 at 01:53:54PM -0700, Jeff Law wrote:
> + 
> +   /* Java catches catch NULL pointer exceptions, thus we can not necessarily

catches catch?

> +  rely on a pointer having a non-NULL value after a dereference.  */
> +   opts->x_flag_delete_null_pointer_checks = 0;
>   }
>   
>   static void


Jakub

Re: PR other/51174: handle architectures with no DECL_COMDAT_GROUP

[David Edelsohn]

On Tue, Nov 22, 2011 at 8:06 AM, Aldy Hernandez  wrote:

> David, can you try the following and see if it fixes the problem on your
> end?
>
> Index: trans-mem.c
> ===
> --- trans-mem.c (revision 181588)
> +++ trans-mem.c (working copy)
> @@ -4198,7 +4198,7 @@ ipa_tm_create_version_alias (struct cgra
>   TREE_SYMBOL_REFERENCED (tm_name) = 1;
>
>   /* Perform the same remapping to the comdat group.  */
> -  if (DECL_COMDAT (new_decl))
> +  if (HAVE_COMDAT_GROUP && DECL_COMDAT (new_decl))
>     DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl));
>
>   new_node = cgraph_same_body_alias (NULL, new_decl, info->new_decl);
> @@ -4233,7 +4233,7 @@ ipa_tm_create_version (struct cgraph_nod
>   TREE_SYMBOL_REFERENCED (tm_name) = 1;
>
>   /* Perform the same remapping to the comdat group.  */
> -  if (DECL_COMDAT (new_decl))
> +  if (HAVE_COMDAT_GROUP && DECL_COMDAT (new_decl))
>     DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl));
>
>   new_node = cgraph_copy_node_for_versioning (old_node, new_decl, NULL,
> NULL);
>

I successfully bootstrapped with this patch.

Thanks, David

[Ada] Deallocation of a class-wide object with unknown discriminants

[Arnaud Charlet]

This patch corrects the creation of equivalent class-wide types for records
with unknown discriminants. Equivalent class-wide types are used by the back
end to determine the size of an object. As a result it is now possible to
deallocate a class-wide object whose root base type has unknown discriminants.

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Hristian Kirtchev  

* exp_intr.adb (Expand_Unc_Deallocation): Ensure that the
dereference has a proper type before the side effect removal
mechanism kicks in.
* sem_ch3.adb (Analyze_Subtype_Declaration): Handle a rare case
where the base type of the subtype is a private itype created
to act as the partial view of a constrained record type. This
scenario manifests with equivalent class-wide types for records
with unknown discriminants.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 181662)
+++ sem_ch3.adb (working copy)
@@ -4064,6 +4064,19 @@
 
   T := Process_Subtype (Subtype_Indication (N), N, Id, 'P');
 
+  --  Class-wide equivalent types of records with unknown discriminants
+  --  involve the generation of an itype which serves as the private view
+  --  of a constrained record subtype. In such cases the base type of the
+  --  current subtype we are processing is the private itype. Use the full
+  --  of the private itype when decorating various attributes.
+
+  if Is_Itype (T)
+and then Is_Private_Type (T)
+and then Present (Full_View (T))
+  then
+ T := Full_View (T);
+  end if;
+
   --  Inherit common attributes
 
   Set_Is_Generic_Type   (Id, Is_Generic_Type   (Base_Type (T)));
Index: exp_intr.adb
===
--- exp_intr.adb(revision 181662)
+++ exp_intr.adb(working copy)
@@ -1123,6 +1123,10 @@
D_Type   : Entity_Id;
 
 begin
+   --  Perform minor decoration as it is needed by the side effect
+   --  removal mechanism.
+
+   Set_Etype  (Deref, Desig_T);
Set_Parent (Deref, Free_Node);
D_Subtyp := Make_Subtype_From_Expr (Deref, Desig_T);
 

[Ada] Fixed bugs in iterators for set containers

[Arnaud Charlet]

There were several issues with the implementation of the set iterators.

The concrete type Iterator is declared as limited, because there is no need for
assignment for iterator objects.

For the ordered forms (which support specifying the start position when
iterating), the First and Last selector functions return a value that depends
on whether this is complete or partial iteration. For complete iteration, the
selector function returns the logical beginning of the entire sequence of items
in the container. (To be specific, Container.First for a forward iterator, and
Container.Last for a reverse iterator.) For partial iteration, the selector
function returns the start position value specified when the iterator object
was constructed (in this case, both First and Last return the same value).

The hashed forms do not support specifying a start position, so the node
component has been removed from the implementation of the iterator type.

The Next and Previous iterator operations vet the cursor parameter to ensure
that it designates a node in the same container as the iterator. The function
then forwards to the call to the analogous cursor-based operation.

Iterate constructs an iterator object whose state indicates whether this is
complete or partial iteration. There was also change in the semantics of the
partial iterator (per the ARG meeting in Denver on 2011/11): if the start
position equals No_Element, then it raises Constraint_Error; otherwise, it
constructs an iterator object to indicate the position from which the iteration
begins (which is in turn used by the selector functions First and Last).

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Matthew Heaney  

* a-coorse.ads, a-ciorse.ads, a-cborse.ads (Set_Iterator_Interfaces):
Renamed from Ordered_Set_Iterator_Interfaces.
* a-coorse.adb, a-ciorse.adb, a-cborse.adb (Iterator): Declared
Iterator type as limited (First, Last): Cursor return value
depends on iterator node value (Iterate): Use start position as
iterator node value (Next, Previous): Forward to corresponding
cursor-based operation.
* a-cohase.ads, a-cohase.adb: Implemented forward iterator.
* a-cihase.adb, a-cbhase.adb (Iterator): Removed unnecessary
node component (First, Next): Forward call to corresponding
cursor-based operation (Iterate): Representation of iterator no
longer has node component

Index: a-ciorse.adb
===
--- a-ciorse.adb(revision 181662)
+++ a-ciorse.adb(working copy)
@@ -42,9 +42,9 @@
 
 package body Ada.Containers.Indefinite_Ordered_Sets is
 
-   type Iterator is new
- Ordered_Set_Iterator_Interfaces.Reversible_Iterator with record
-Container : access constant Set;
+   type Iterator is limited new
+ Set_Iterator_Interfaces.Reversible_Iterator with record
+Container : Set_Access;
 Node  : Node_Access;
  end record;
 
@@ -600,8 +600,24 @@
 
function First (Object : Iterator) return Cursor is
begin
-  return Cursor'(
-Object.Container.all'Unrestricted_Access, Object.Container.Tree.First);
+  --  The value of the iterator object's Node component influences the
+  --  behavior of the First (and Last) selector function.
+
+  --  When the Node component is null, this means the iterator object was
+  --  constructed without a start expression, in which case the (forward)
+  --  iteration starts from the (logical) beginning of the entire sequence
+  --  of items (corresponding to Container.First, for a forward iterator).
+
+  --  Otherwise, this is iteration over a partial sequence of items. When
+  --  the Node component is non-null, the iterator object was constructed
+  --  with a start expression, that specifies the position from which the
+  --  (forward) partial iteration begins.
+
+  if Object.Node = null then
+ return Object.Container.First;
+  else
+ return Cursor'(Object.Container, Object.Node);
+  end if;
end First;
 
---
@@ -1259,22 +1275,62 @@
 
function Iterate
  (Container : Set)
-  return Ordered_Set_Iterator_Interfaces.Reversible_Iterator'class
+  return Set_Iterator_Interfaces.Reversible_Iterator'Class
is
-  It : constant Iterator :=
- (Container'Unchecked_Access, Container.Tree.First);
begin
-  return It;
+  --  The value of the Node component influences the behavior of the First
+  --  and Last selector functions of the iterator object. When the Node
+  --  component is null (as is the case here), this means the iterator
+  --  object was constructed without a start expression. This is a complete
+  --  iterator, meaning that the iteration starts from the (logical)
+  --  beginning of the sequence of items.
+
+  --  Note: For a forward iterator, Conta

Re: resent2 [PATCH] Fix ICE in redirect_jump, at jump.c:1497 PR50496

[Chung-Lin Tang]

On 2011/11/2 11:47 PM, Bernd Schmidt wrote:
> On 10/31/11 10:11, Eric Botcazou wrote:
>>> I'm suggesting a new patch, as attached. Before reload_completed, we
>>> directly return 0 upon nlabel == NULL, which should be identical with
>>> old behavior, while asserting fail if after reload (where we assume the
>>> simple_return/return distinction is required).
>>>
>>> This should ensure better that, if a post-prologue case of redirecting
>>> to the exit block ever happens we will more easily know (by some future
>>> PR :P)
>>>
>>> Bootstrapped and tested on i686, and cross tested on ARM using QEMU.
>>> Eric, is this approach okay?
>>
>> Don't you want epilogue_completed instead of reload_completed?  Otherwise,
>> yes, the approach is fine with me, but wait for Bernd's input.
> 
> That looks good to me too.
> 
> 
> Bernd

(returning to this...)

I've re-tested using epilogue_completed to be sure, everything's clean
as expected. Just applied, attaching committed patch.

Thanks,
Chung-Lin
Index: ChangeLog
===
--- ChangeLog   (revision 181662)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2011-11-23  Chung-Lin Tang  
+
+   PR rtl-optimization/50496
+   * jump.c (redirect_jump): Assert fail on nlabel == NULL_RTX
+   only after epilogue is created. Add comments.
+
 2011-11-22  Richard Henderson  
 
* config/ia64/ia64.c (ia64_expand_atomic_op): Add model parameter.
Index: jump.c
===
--- jump.c  (revision 181662)
+++ jump.c  (working copy)
@@ -1495,8 +1495,19 @@
 {
   rtx olabel = JUMP_LABEL (jump);
 
-  gcc_assert (nlabel != NULL_RTX);
+  if (!nlabel)
+{
+  /* If there is no label, we are asked to redirect to the EXIT block.
+When before the epilogue is emitted, return/simple_return cannot be
+created so we return 0 immediately.  After the epilogue is emitted,
+we always expect a label, either a non-null label, or a
+return/simple_return RTX.  */
 
+  if (!epilogue_completed)
+   return 0;
+  gcc_unreachable ();
+}
+
   if (nlabel == olabel)
 return 1;
 

Re: [libitm, build] Clear hardware capabilities on libitm.so with Sun ld

[Rainer Orth]

Richard Henderson  writes:

> What support does the Solaris 11 assembler have for this feature?
> The documentation only mentions the compiler...

I've asked exactly the same question when the spec was posted early last
year:

http://arc.opensolaris.org/caselog/PSARC/2010/022/mail

Unfortunately, there was none at the time.  The assembler manuals
mention nothing either, but they are incomplete and outdated,
unfortuantely.  There's nothing obvious even in the last beta (12.3) of
the Studio compilers either, so it seems you'll have to use the ld
mapfile trick to convert from object capabilities to symbol capabilities
for now, which feels clumsy.

I'll ask the linker engineers that developed that feature.

Rainer

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

Re: [ada] Fix bootstrap error in s-taprop-tru64.adb

[Arnaud Charlet]

> Tru64 UNIX Ada bootstrap recently got broken:
> 
> s-taprop.adb:892:12: access to volatile object cannot yield
> access-to-non-volatile type
> make[6]: *** [s-taprop.o] Error 1
> 
> s-taprop-tru64.adb missed a patch already applied to s-taprop-{irix,
> solaris}.adb.  With that change, the bootstrap continues and
> libgnat-4.7.so built.
> 
> Ok for mainline?
> 
>   Rainer
> 
> 
> 2011-11-23  Rainer Orth  
> 
>   * s-taprop-tru64.adb (Create_Task): Use Unrestricted_Access.

OK, thanks.

Arno

Re: [ada] Fix bootstrap error in s-taprop-tru64.adb

[Robert Dewar]

On 11/23/2011 7:31 AM, Rainer Orth wrote:

Tru64 UNIX Ada bootstrap recently got broken:

s-taprop.adb:892:12: access to volatile object cannot yield 
access-to-non-volatile type
make[6]: *** [s-taprop.o] Error 1

s-taprop-tru64.adb missed a patch already applied to s-taprop-{irix,
solaris}.adb.  With that change, the bootstrap continues and
libgnat-4.7.so built.

Ok for mainline?


Yes, this is fine

[ada] Fix bootstrap error in s-taprop-tru64.adb

[Rainer Orth]

Tru64 UNIX Ada bootstrap recently got broken:

s-taprop.adb:892:12: access to volatile object cannot yield 
access-to-non-volatile type
make[6]: *** [s-taprop.o] Error 1

s-taprop-tru64.adb missed a patch already applied to s-taprop-{irix,
solaris}.adb.  With that change, the bootstrap continues and
libgnat-4.7.so built.

Ok for mainline?

Rainer


2011-11-23  Rainer Orth  

* s-taprop-tru64.adb (Create_Task): Use Unrestricted_Access.

# HG changeset patch
# Parent e66650faff232e847ecd34c2b4ada1f361149fe6
Fix bootstrap error in s-taprop-tru64.adb

	gcc/ada:
	* s-taprop-tru64.adb (Create_Task): Use Unrestricted_Access.

diff --git a/gcc/ada/s-taprop-tru64.adb b/gcc/ada/s-taprop-tru64.adb
--- a/gcc/ada/s-taprop-tru64.adb
+++ b/gcc/ada/s-taprop-tru64.adb
@@ -887,9 +887,15 @@ package body System.Task_Primitives.Oper
   --  do not need to manipulate caller's signal mask at this point.
   --  All tasks in RTS will have All_Tasks_Mask initially.
 
+  --  Note: the use of Unrestricted_Access in the following call is needed
+  --  because otherwise we have an error of getting a access-to-volatile
+  --  value which points to a non-volatile object. But in this case it is
+  --  safe to do this, since we know we have no problems with aliasing and
+  --  Unrestricted_Access bypasses this check.
+
   Result :=
 pthread_create
-  (T.Common.LL.Thread'Access,
+  (T.Common.LL.Thread'Unrestricted_Access,
Attributes'Access,
Thread_Body_Access (Wrapper),
To_Address (T));


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

Re: Ping: Java, disable -fdelete-null-pointer-checks

[Andrew Haley]

On 11/22/2011 08:53 PM, Jeff Law wrote:
>
>   * lang.c (java_init_options_struct): Disable optimizations
>   which assume a NULL pointer dereference will cause a fault.

This is OK.

Thanks,
Andrew.

[Ada] Remove hard-coded clock ids

[Arnaud Charlet]

Remove hard-coded clock ids in s-taprop*.adb; instead, generate them
in System.OS_Constants.

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Thomas Quinot  

* s-osinte-hpux.ads, s-taprop-vxworks.adb, s-taprop-tru64.adb,
s-osinte-vxworks.ads, s-osinte-aix.ads, s-osinte-lynxos.ads,
s-osinte-solaris-posix.ads, s-taprop-solaris.adb, a-exetim-posix.adb,
s-osinte-irix.ads, s-osinte-solaris.ads, s-oscons-tmplt.c,
s-taprop-irix.adb, s-osinte-hpux-dce.ads, Makefile.rtl,
s-osinte-tru64.ads, s-osinte-darwin.ads, s-taprop.ads,
s-osinte-freebsd.ads, s-osinte-lynxos-3.ads, s-taprop-hpux-dce.adb,
s-osinte-lynxos-5.ads, s-taprop-posix.adb: Remove hard-coded clock ids;
instead, generate them in System.OS_Constants.
(System.OS_Constants.CLOCK_RT_Ada): New constant denoting the
id of the clock providing Ada.Real_Time.Monotonic_Clock.
* thread.c: New file.
(__gnat_pthread_condattr_setup): New function. For platforms where
CLOCK_RT_Ada is not CLOCK_REALTIME, set appropriate condition
variable attribute.

Index: s-osinte-hpux.ads
===
--- s-osinte-hpux.ads   (revision 181654)
+++ s-osinte-hpux.ads   (working copy)
@@ -180,11 +180,8 @@
 
type timespec is private;
 
-   type clockid_t is private;
+   type clockid_t is new int;
 
-   CLOCK_REALTIME  : constant clockid_t;
-   CLOCK_MONOTONIC : constant clockid_t;
-
function clock_gettime
  (clock_id : clockid_t;
   tp   : access timespec) return int;
@@ -529,10 +526,6 @@
end record;
pragma Convention (C, timespec);
 
-   type clockid_t is new int;
-   CLOCK_REALTIME  : constant clockid_t := 1;
-   CLOCK_MONOTONIC : constant clockid_t := CLOCK_REALTIME;
-
type pthread_attr_t is new int;
type pthread_condattr_t is new int;
type pthread_mutexattr_t is new int;
Index: s-taprop-vxworks.adb
===
--- s-taprop-vxworks.adb(revision 181654)
+++ s-taprop-vxworks.adb(working copy)
@@ -718,7 +718,7 @@
   TS : aliased timespec;
   Result : int;
begin
-  Result := clock_gettime (CLOCK_REALTIME, TS'Unchecked_Access);
+  Result := clock_gettime (OSC.CLOCK_RT_Ada, TS'Unchecked_Access);
   pragma Assert (Result = 0);
   return To_Duration (TS);
end Monotonic_Clock;
Index: s-taprop-tru64.adb
===
--- s-taprop-tru64.adb  (revision 181654)
+++ s-taprop-tru64.adb  (working copy)
@@ -589,7 +589,7 @@
   TS : aliased timespec;
   Result : Interfaces.C.int;
begin
-  Result := clock_gettime (CLOCK_REALTIME, TS'Unchecked_Access);
+  Result := clock_gettime (OSC.CLOCK_RT_Ada, TS'Unchecked_Access);
   pragma Assert (Result = 0);
   return To_Duration (TS);
end Monotonic_Clock;
Index: s-osinte-vxworks.ads
===
--- s-osinte-vxworks.ads(revision 181654)
+++ s-osinte-vxworks.ads(working copy)
@@ -243,10 +243,8 @@
end record;
pragma Convention (C, timespec);
 
-   type clockid_t is private;
+   type clockid_t is new int;
 
-   CLOCK_REALTIME : constant clockid_t;   --  System wide realtime clock
-
function To_Duration (TS : timespec) return Duration;
pragma Inline (To_Duration);
 
@@ -511,8 +509,5 @@
 
ERROR_PID : constant pid_t := -1;
 
-   type clockid_t is new int;
-   CLOCK_REALTIME : constant clockid_t := 0;
-
type sigset_t is new System.VxWorks.Ext.sigset_t;
 end System.OS_Interface;
Index: s-osinte-aix.ads
===
--- s-osinte-aix.ads(revision 181654)
+++ s-osinte-aix.ads(working copy)
@@ -197,11 +197,8 @@
 
type timespec is private;
 
-   type clockid_t is private;
+   type clockid_t is new int;
 
-   CLOCK_REALTIME  : constant clockid_t;
-   CLOCK_MONOTONIC : constant clockid_t;
-
function clock_gettime
  (clock_id : clockid_t;
   tp   : access timespec) return int;
@@ -547,10 +544,6 @@
end record;
pragma Convention (C, timespec);
 
-   type clockid_t is new int;
-   CLOCK_REALTIME  : constant clockid_t := 9;
-   CLOCK_MONOTONIC : constant clockid_t := 10;
-
type pthread_attr_t is new System.Address;
pragma Convention (C, pthread_attr_t);
--  typedef struct __pt_attr*pthread_attr_t;
Index: s-osinte-lynxos.ads
===
--- s-osinte-lynxos.ads (revision 181654)
+++ s-osinte-lynxos.ads (working copy)
@@ -197,11 +197,8 @@
 
type timespec is private;
 
-   type clockid_t is private;
+   type clockid_t is new int;
 
-   CLOCK_REALTIME  : constant clockid_t;
-   CLOCK_MONOTONIC : constant clockid_t;
-
function clock_gettime
  (clock_id : clockid_t;
   tp   : access timespec) re

[Ada] Remove unnecessary node component from hashed map iterator

[Arnaud Charlet]

The concrete type Iterator is declared as limited, because there is no need for
assignment for iterator objects.  Hashed maps also do not support partial
iteration, so the unnecessary node component is also removed from that type.

The Next operation vets the cursor parameter to ensure that it designates a
node in the same container as the iterator. The function then forwards to the
call to the corresponding cursor-based operation.

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Matthew Heaney  

* a-cohama.adb, a-cihama.adb, a-cbhama.adb (Iterator): Declare
type as limited, and remove node component.
(First, Next): Forward call to corresponding cursor-based operation.
(Iterate): Representation of iterator no longer has node component.

Index: a-cihama.adb
===
--- a-cihama.adb(revision 181654)
+++ a-cihama.adb(working copy)
@@ -45,10 +45,9 @@
procedure Free_Element is
   new Ada.Unchecked_Deallocation (Element_Type, Element_Access);
 
-   type Iterator is new
+   type Iterator is limited new
  Map_Iterator_Interfaces.Forward_Iterator with record
 Container : Map_Access;
-Node  : Node_Access;
  end record;
 
overriding function First (Object : Iterator) return Cursor;
@@ -476,14 +475,8 @@
end First;
 
function First (Object : Iterator) return Cursor is
-  M : constant Map_Access  := Object.Container;
-  N : constant Node_Access := HT_Ops.First (M.HT);
begin
-  if N = null then
- return No_Element;
-  else
- return Cursor'(Object.Container.all'Unchecked_Access, N);
-  end if;
+  return Object.Container.First;
end First;
 
--
@@ -715,13 +708,11 @@
   B := B - 1;
end Iterate;
 
-   function Iterate (Container : Map)
-  return Map_Iterator_Interfaces.Forward_Iterator'class
+   function Iterate
+ (Container : Map) return Map_Iterator_Interfaces.Forward_Iterator'Class
is
-  Node : constant Node_Access := HT_Ops.First (Container.HT);
-  It   : constant Iterator := (Container'Unrestricted_Access, Node);
begin
-  return It;
+  return Iterator'(Container => Container'Unrestricted_Access);
end Iterate;
 
-
@@ -809,11 +800,16 @@
 
function Next (Object : Iterator; Position : Cursor) return Cursor is
begin
-  if Position.Node = null then
+  if Position.Container = null then
  return No_Element;
-  else
- return (Object.Container, Next (Position).Node);
   end if;
+
+  if Position.Container /= Object.Container then
+ raise Program_Error with
+   "Position cursor of Next designates wrong map";
+  end if;
+
+  return Next (Position);
end Next;
 
---
Index: a-cohama.adb
===
--- a-cohama.adb(revision 181654)
+++ a-cohama.adb(working copy)
@@ -39,10 +39,9 @@
 
 package body Ada.Containers.Hashed_Maps is
 
-   type Iterator is new
+   type Iterator is limited new
  Map_Iterator_Interfaces.Forward_Iterator with record
 Container : Map_Access;
-Node  : Node_Access;
  end record;
 
overriding function First (Object : Iterator) return Cursor;
@@ -440,14 +439,8 @@
end First;
 
function First (Object : Iterator) return Cursor is
-  M : constant Map_Access  := Object.Container;
-  N : constant Node_Access := HT_Ops.First (M.HT);
begin
-  if N = null then
- return No_Element;
-  end if;
-
-  return Cursor'(Object.Container.all'Unchecked_Access, N);
+  return Object.Container.First;
end First;
 
--
@@ -667,12 +660,10 @@
end Iterate;
 
function Iterate
- (Container : Map) return Map_Iterator_Interfaces.Forward_Iterator'class
+ (Container : Map) return Map_Iterator_Interfaces.Forward_Iterator'Class
is
-  Node : constant Node_Access := HT_Ops.First (Container.HT);
-  It   : constant Iterator := (Container'Unrestricted_Access, Node);
begin
-  return It;
+  return Iterator'(Container => Container'Unrestricted_Access);
end Iterate;
 
-
@@ -752,11 +743,16 @@
   Position : Cursor) return Cursor
is
begin
-  if Position.Node = null then
+  if Position.Container = null then
  return No_Element;
-  else
- return (Object.Container, Next (Position).Node);
   end if;
+
+  if Position.Container /= Object.Container then
+ raise Program_Error with
+   "Position cursor of Next designates wrong map";
+  end if;
+
+  return Next (Position);
end Next;
 
---
Index: a-cbhama.adb
===
--- a-cbhama.adb(revision 181654)
+++ a-cbhama.adb(working copy)
@@ -41,7 +41,6 @@
type Iterator is n

[Ada] Fix check for entry family bounds out of range

[Arnaud Charlet]

This patch adds code to the semantic analyzer to properly check
that entry family bounds are in range. Previously this check was
done during code expansion, leading to messages posted at the
wrong point, omission of the check in -gnatc mode, and in the
case of task entry families a blow up in the expander.

The following tests compile with the errors shown in
both normal and -gnatc modes.

 1. procedure badentrymsg is
 2. protected type PT is
 3.   entry Test (Long_Long_Integer)
  |
>>> entry family low bound must be >= 0
>>> entry family high bound must be <= 16#7FFF_#

 4. (X : Integer);
 5. private
 6. Data : Integer := 0;
 7. end PT;
 8.
 9. protected body PT is
10.   entry Test
11. (for I in Long_Long_Integer)
12.   (X : Integer)
13. when True is
14. begin
15. Data := X;
16. end Test;
17. end PT;
18. PO : PT;
19. begin
20. PO.Test(3)(5);
21. end;

 1. procedure badtaskentry is
 2.Data : Integer;
 3.task type PT is
 4.   entry Test (Long_Long_Integer)
  |
>>> entry family low bound must be >= 0
>>> entry family high bound must be <= 16#7FFF_#

 5. (X : Integer);
 6. end PT;
 7.
 8.task body PT is
 9.begin
10.   accept Test (3) (X : Integer) do
11.  Data := X;
12.   end Test;
13. end PT;
14.
15. T : PT;
16. begin
17. null;
18. end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Robert Dewar  

* sem_ch9.adb (Analyze_Entry_Declaration): Check for entry
family bounds out of range.

Index: sem_ch9.adb
===
--- sem_ch9.adb (revision 181654)
+++ sem_ch9.adb (working copy)
@@ -905,6 +905,60 @@
  Bad_Predicated_Subtype_Use
("subtype& has predicate, not allowed in entry family",
 D_Sdef, Etype (D_Sdef));
+
+ --  Check entry family static bounds outside allowed limits
+
+ --  Note: originally this check was not performed here, but in that
+ --  case the check happens deep in the expander, and the message is
+ --  posted at the wrong location, and omitted in -gnatc mode.
+
+ declare
+PEI : constant Entity_Id := RTE (RE_Protected_Entry_Index);
+LB  : constant Uint  := Expr_Value (Type_Low_Bound (PEI));
+UB  : constant Uint  := Expr_Value (Type_High_Bound (PEI));
+
+LBR : Node_Id;
+UBR : Node_Id;
+
+ begin
+if Nkind (D_Sdef) = N_Range then
+   LBR := Low_Bound (D_Sdef);
+elsif Is_Entity_Name (D_Sdef)
+  and then Is_Type (Entity (D_Sdef))
+then
+   LBR := Type_Low_Bound (Entity (D_Sdef));
+else
+   goto Skip_LB;
+end if;
+
+if Is_Static_Expression (LBR)
+  and then Expr_Value (LBR) < LB
+then
+   Error_Msg_Uint_1 := LB;
+   Error_Msg_N ("entry family low bound must be '>'= ^!", D_Sdef);
+end if;
+
+<>
+if Nkind (D_Sdef) = N_Range then
+   UBR := High_Bound (D_Sdef);
+elsif Is_Entity_Name (D_Sdef)
+  and then Is_Type (Entity (D_Sdef))
+then
+   UBR := Type_High_Bound (Entity (D_Sdef));
+else
+   goto Skip_UB;
+end if;
+
+if Is_Static_Expression (UBR)
+  and then Expr_Value (UBR) > UB
+then
+   Error_Msg_Uint_1 := UB;
+   Error_Msg_N ("entry family high bound must be '<'= ^!", D_Sdef);
+end if;
+
+<>
+null;
+ end;
   end if;
 
   --  Decorate Def_Id

Re: Minor contrib.texi update

[Gerald Pfeifer]

On Mon, 21 Nov 2011, Jeff Law wrote:
>> Just mind the long line
> Do we wrap earlier in the texi file (first line is 79chars I think)?
> Or are you referring to an output file?

I fail to find the reference now, but usually try to wrap things
such that a patch (which adds "+ " or "- ") still fits with wrapping,
or ideally a quoted patch (so "> + " or "> - "), so around 76.

Not a big deal, though.

Gerald

[Ada] Change semantics of partial iteration

[Arnaud Charlet]

There were several issues with the implementation of the map iterator.

(1) Ordered maps support reverse iteration, so the type returned by the
iterator factory function was changed from Forward_Iterator'Class to
Reversible_Iterator'Class.

(2) The concrete type Iterator was declared as limited, because there is no
need for assignment for iterator objects.

(3) The First and Last selector functions return a value that depends on
whether this is complete or partial iteration. For complete iteration, the
selector function returns the logical beginning of the entire sequence of items
in the container. (To be specific, Container.First for a forward iterator, and
Container.Last for a reverse iterator.) For partial iteration, the selector
function returns the start position value specified when the iterator object
was constructed (in this case, both First and Last return the same value).

(4) The Next and Previous operations vet the cursor parameter to ensure that it
designates a node in the same container as the iterator. The function then
forwards to the call to the analogous cursor-based operation.

(5) Iterate constructs an iterator object whose state indicates whether this is
complete or partial iteration. There was also change in the semantics of the
partial iterator (per the ARG meeting in Denver on 2011/11): if the start
position equals No_Element, then it raises Constraint_Error; otherwise, it
constructs an iterator object to indicate the position from which the iteration
begins (which is in turn used by the selector functions First and Last).

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Matthew Heaney  

* a-coorma.ads, a-ciorma.ads, a-cborma.ads (Iterate): Returns
type Reversible_Iterator'Class.
* a-coorma.adb, a-ciorma.adb, a-cborma.adb (Iterator):
Declare type as limited.
(First, Last): Return value depends on iterator's start node value.
(Next, Previous): Call corresponding Cursor-based operation.
(Iterate): Indicate whether complete or partial iteration

Index: a-coorma.adb
===
--- a-coorma.adb(revision 181654)
+++ a-coorma.adb(working copy)
@@ -39,7 +39,7 @@
 
 package body Ada.Containers.Ordered_Maps is
 
-   type Iterator is new
+   type Iterator is limited new
  Map_Iterator_Interfaces.Reversible_Iterator with record
 Container : Map_Access;
 Node  : Node_Access;
@@ -518,13 +518,24 @@
end First;
 
function First (Object : Iterator) return Cursor is
-  M : constant Map_Access  := Object.Container;
-  N : constant Node_Access := M.Tree.First;
begin
-  if N = null then
- return No_Element;
+  --  The value of the iterator object's Node component influences the
+  --  behavior of the First (and Last) selector function.
+
+  --  When the Node component is null, this means the iterator object was
+  --  constructed without a start expression, in which case the (forward)
+  --  iteration starts from the (logical) beginning of the entire sequence
+  --  of items (corresponding to Container.First, for a forward iterator).
+
+  --  Otherwise, this is iteration over a partial sequence of items. When
+  --  the Node component is non-null, the iterator object was constructed
+  --  with a start expression, that specifies the position from which the
+  --  (forward) partial iteration begins.
+
+  if Object.Node = null then
+ return Object.Container.First;
   else
- return Cursor'(Object.Container.all'Unchecked_Access, N);
+ return Cursor'(Object.Container, Object.Node);
   end if;
end First;
 
@@ -534,7 +545,6 @@
 
function First_Element (Container : Map) return Element_Type is
   T : Tree_Type renames Container.Tree;
-
begin
   if T.First = null then
  raise Constraint_Error with "map is empty";
@@ -827,21 +837,60 @@
end Iterate;
 
function Iterate
- (Container : Map) return Map_Iterator_Interfaces.Forward_Iterator'class
+ (Container : Map) return Map_Iterator_Interfaces.Reversible_Iterator'Class
is
-  Node : constant Node_Access := Container.Tree.First;
-  It   : constant Iterator := (Container'Unrestricted_Access, Node);
+   begin
+  --  The value of the Node component influences the behavior of the First
+  --  and Last selector functions of the iterator object. When the Node
+  --  component is null (as is the case here), this means the iterator
+  --  object was constructed without a start expression. This is a
+  --  complete iterator, meaning that the iteration starts from the
+  --  (logical) beginning of the sequence of items.
 
-   begin
-  return It;
+  --  Note: For a forward iterator, Container.First is the beginning, and
+  --  for a reverse iterator, Container.Last is the beginning.
+
+  return Iterator'(Container'U

[Ada] Wrong dispatching call in returned class-wide interface object

[Arnaud Charlet]

If a function returns a class-wide interface object then the compiler
generates code that leaves the interface object not well initialized.
This causes wrong dispatching calls at runtime. The following test
must compile and execute without run-time errors.

package Pkg is
   type Iface is interface;
   procedure Prim_1 (Obj : Iface) is abstract;
   procedure Prim_2 (Obj : Iface) is abstract;

   type Root is tagged null record;
   procedure Prim_2 (Obj : Root);
   procedure Prim_1 (Obj : Root);

   type DT is new Root and Iface with null record;

   function Create return Iface'Class;
end;

with GNAT.IO; use GNAT.IO;
package body Pkg is
   procedure Prim_2 (Obj : Root) is
   begin
  raise Program_Error;
   end;

   procedure Prim_1 (Obj : Root) is
   begin
  Put_Line ("OK");
   end;

   function Create return Iface'Class is
   begin
  return DT'(Root with null record);
   end;
end;

with Pkg; use Pkg;
procedure Main is
begin
   Create.Prim_1;
end;

Command: gnatmake -gnat05 main; ./main
 Output: OK

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Javier Miranda  

* exp_ch6.adb (Expand_Simple_Function_Return): Add missing
implicit type conversion when the returned object is allocated
in the secondary stack and the type of the returned object is
an interface. Done to force generation of displacement of the
"this" pointer.

Index: exp_ch6.adb
===
--- exp_ch6.adb (revision 181654)
+++ exp_ch6.adb (working copy)
@@ -6700,6 +6700,14 @@
  Make_Explicit_Dereference (Loc,
  Prefix => New_Reference_To (Temp, Loc)));
 
+   --  Ada 2005 (AI-251): If the type of the returned object is
+   --  an interface then add an implicit type conversion to force
+   --  displacement of the "this" pointer.
+
+   if Is_Interface (R_Type) then
+  Rewrite (Exp, Convert_To (R_Type, Relocate_Node (Exp)));
+   end if;
+
Analyze_And_Resolve (Exp, R_Type);
 end;
 

[Ada] Locate error message on the first line of a pre/post/invariant aspect

[Arnaud Charlet]

The source location of an expression may not be the best place to put a mess in
the case of a failed precondition/postcondition/invariant. For example, it gets
located on the last "and" keyword in a chain of boolean expressiond and'ed
together. It is best put the message on the first character of an assertion,
which is done here. This is a follow-up of a previous patch that did the same
for pragmas.

Tested on x86_64-pc-linux-gnu, committed on trunk

2011-11-23  Yannick Moy  

* sem_ch13.adb (Analyze_Aspect_Specifications): Place error on
line of precondition/ postcondition/invariant.

Index: sem_ch13.adb
===
--- sem_ch13.adb(revision 181654)
+++ sem_ch13.adb(working copy)
@@ -728,8 +728,9 @@
 A_Id : constant Aspect_Id  := Get_Aspect_Id (Nam);
 Anod : Node_Id;
 
-Eloc : Source_Ptr := Sloc (Expr);
---  Source location of expression, modified when we split PPC's
+Eloc : Source_Ptr := No_Location;
+--  Source location of expression, modified when we split PPC's. It
+--  is set below when Expr is present.
 
 procedure Check_False_Aspect_For_Derived_Type;
 --  This procedure checks for the case of a false aspect for a
@@ -804,6 +805,18 @@
goto Continue;
 end if;
 
+--  Set the source location of expression, used in the case of
+--  a failed precondition/postcondition or invariant. Note that
+--  the source location of the expression is not usually the best
+--  choice here. For example, it gets located on the last AND
+--  keyword in a chain of boolean expressiond AND'ed together.
+--  It is best to put the message on the first character of the
+--  assertion, which is the effect of the First_Node call here.
+
+if Present (Expr) then
+   Eloc := Sloc (First_Node (Expr));
+end if;
+
 --  Check restriction No_Implementation_Aspect_Specifications
 
 if Impl_Defined_Aspects (A_Id) then

Keep static VTA locs in cselib tables only

[Alexandre Oliva]

This patch reduces VTA memory consumption and even speeds it up
somewhat, by avoiding recording permanent equivalences in dataflow sets
(and propagating them all the way down the control flow graph), keeping
them in cselib tables only.  This saves some micro-operations, some
duplicate attempts to expand the same complex operations, and most of
all time and memory for locations in dataflow sets.

I've also moved reverse operations and entry values, that are also
permanent equivalences, to cselib tables, introducing a mechanism to add
equivalences to cselib tables that doesn't depend on expressions hashing
equal: instead, locs for values in an equivalence set are grouped in the
loc list for the earliest (canonical) value in the set, in the cselib
tables, with a single entry in the loc list for all other set members
pointing to the canonical value.

The downside is that we don't sort loc lists in cselib as we do in
var-trackin, so we don't give expressions the same preferences we did
before, which means there's some potential for debug info degradation,
particularly for preferring entry value expressions over concrete
expressions guaranteed to have an available value.  I'm going to see
whether sorting gets us better/faster results next, but just sorting
them won't get us all the way: while before we'd sort all equivalences
for the var-tracking-canonical equivalence, we may now fail to merge
location lists because the static equivalences aren't taken into account
when dynamic equivalence sets in var-tracking dataflow sets.  I haven't
thought about whether this makes much of a difference, or how to do that
efficiently if desirable, but I figured I wouldn't wait any longer
before submitting this patch for 4.7.

This was regstrapped on i686-pc-linux-gnu and x86_64-linux-gnu.  I've
also run some debug info, memory and compile-time measurements:

- compiling stage3-gcc/ (--enable-languages=all,ada) became some 1-2%
faster on average (0.5% to 5% speedups were observed over 3
measurements)

- comparable speedups with a not-very-random sample of preprocessed
sources that used to be VTA bad-performers, with var-tracking memory use
down by 10% to 50%.

- compiling stage2 target libs and stage3 host patched sources (with
both unpatched and patched stage2 compiler) produced cc1plus with 10%
fewer entry value expressions (a welcome surprise!), 1% fewer call site
value expressions, an increase of 0.1% in the total number of variables
with location lists and less than 0.5% decrease in variables with full
coverage.

Here's the patch.  Ok to install?

for  gcc/ChangeLog
from  Alexandre Oliva  

	* cselib.h (cselib_add_permanent_equiv): Declare.
	(canonical_cselib_val): New.
	* cselib.c (new_elt_loc_list): Rework to support value
	equivalences.  Adjust all callers.
	(preserve_only_constants): Retain value equivalences.
	(references_value_p): Retain preserved values.
	(rtx_equal_for_cselib_1): Handle value equivalences.
	(cselib_invalidate_regno): Use canonical value.
	(cselib_add_permanent_equiv): New.
	* alias.c (find_base_term): Reset locs lists while recursing.
	* var-tracking.c (val_bind): New.  Don't add equivalences
	present in cselib table, compared with code moved from...
	(val_store): ... here.
	(val_resolve): Use val_bind.
	(VAL_EXPR_HAS_REVERSE): Drop.
	(add_uses): Do not create MOps for addresses.  Do not mark
	non-REG non-MEM expressions as requiring resolution.
	(reverse_op): Record reverse as a cselib equivalence.
	(add_stores): Use it.  Do not create MOps for addresses.
	Do not require resolution for non-REG non-MEM expressions.
	Simplify support for reverse operations.
	(compute_bb_dataflow): Drop reverse support.
	(emit_notes_in_bb): Likewise.
	(create_entry_value): Rename to...
	(record_entry_value): ... this.  Use cselib equivalences.
	(vt_add_function_parameter): Adjust.

Index: gcc/cselib.h
===
--- gcc/cselib.h.orig	2011-11-21 02:23:54.111708716 -0200
+++ gcc/cselib.h	2011-11-21 05:31:42.176203099 -0200
@@ -96,5 +96,24 @@ extern void cselib_preserve_value (cseli
 extern bool cselib_preserved_value_p (cselib_val *);
 extern void cselib_preserve_only_values (void);
 extern void cselib_preserve_cfa_base_value (cselib_val *, unsigned int);
+extern void cselib_add_permanent_equiv (cselib_val *, rtx, rtx);
 
 extern void dump_cselib_table (FILE *);
+
+/* Return the canonical value for VAL, following the equivalence chain
+   towards the earliest (== lowest uid) equivalent value.  */
+
+static inline cselib_val *
+canonical_cselib_val (cselib_val *val)
+{
+  cselib_val *canon;
+
+  if (!val->locs || val->locs->next
+  || !val->locs->loc || GET_CODE (val->locs->loc) != VALUE
+  || val->uid < CSELIB_VAL_PTR (val->locs->loc)->uid)
+return val;
+
+  canon = CSELIB_VAL_PTR (val->locs->loc);
+  gcc_checking_assert (canonical_cselib_val (canon) == canon);
+  return canon;
+}
Index: gcc/cselib.c
===

[Patch Darwin] fix thinko in TM crts

[Iain Sandoe]

I provided dummy functions for the libitm weak refs in the first  
version of this.
(a) this is unnecessary (except in the corner-case of testing lto)  
because there is never a need to use the crts unless libitm is linked.
(b) it no longer works across all *x86*-darwin* because weak linkage  
behavior differs.


the solution is to require the library to be present (no problem,  
since the crts are only fired up for -fgnu-tm) and to remove the dummy  
funcs from the crts,

OK for trunk?
Iain

libgcc:

* config/darwin-crt-tm.c: Remove dummy _ITM_ functions.


Index: libgcc/config/darwin-crt-tm.c
===
--- libgcc/config/darwin-crt-tm.c   (revision 181653)
+++ libgcc/config/darwin-crt-tm.c   (working copy)
@@ -72,12 +72,4 @@ void __doTMdeRegistrations (void)
 _ITM_deregisterTMCloneTable (tm_clone_table_sect_data);
 
 }
-
-/* Provide dumy funcs for the weak ones - needed on most Darwin versions
-   for now.  */
-
-void _ITM_registerTMCloneTable (void *n ATTRIBUTE_UNUSED, size_t s 
ATTRIBUTE_UNUSED)
-{}
-void _ITM_deregisterTMCloneTable (void *n ATTRIBUTE_UNUSED)
-{}
 #endif

Re: [PATCH SMS 1/2, RFC] Support traversing PS in reverse order

[Ayal Zaks]

On Mon, Nov 21, 2011 at 7:07 AM, Revital Eres  wrote:
> Hello,
>
> This patch support the estimation of register pressure in SMS.
> Although GCC is in stage 3 I would appreciate comments on it.
> Thanks to Richard and Ayal for discussing the implementation and their 
> insights.
>
> This part of the patch enables iterating on the partial schedule in the
> reverse order (from the last instruction the the first).
>
> Tested and bootstrap with the other patches in the series on
> ppc64-redhat-linux,
> enabling SMS on loops with SC 1.
>
> Comments are welcome.
>

This looks fine. Please rename rows_reverse to rows_last as discussed,
and simplify the bit that tracks last_in_row in ps_insn_find_column().
Thanks,
Ayal.

> Thanks,
> Revital
>
> Changelog:
>        * modulo-sched.c (rows_reverse): New field in struct partial_schedule.
>        (create_partial_schedule, free_partial_schedule,
>        ps_insert_empty_row, ps_insn_advance_column,
>        ps_insn_find_column, remove_node_from_ps, reset_partial_schedule,
>        rotate_partial_schedule, verify_partial_schedule): Update the
>        new field.
>