[PATCH] Simplify VRP |& handling

2011-08-05 Thread Richard Guenther

This simplifies handling of | and & during propagation.  The generic
constant propagation code catches all special cases already (so should
the nonzero bits case).  I took the opportunity to disable CCP for
the testcases covering the | and & code to make sure VRP gets at it.

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

Richard.

2011-08-05  Richard Guenther  

* tree-vrp.c (zero_nonzero_bits_from_vr): Make sure to always
return true for constant integer ranges.
(extract_range_from_binary_expr_1): Simplify BIT_AND_EXPR and
BIT_IOR_EXPR handling.

* gcc.dg/tree-ssa/vrp51.c: Disable CCP.
* gcc.dg/tree-ssa/vrp52.c: Likewise.
* gcc.dg/tree-ssa/vrp53.c: Likewise.

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 177393)
+++ gcc/tree-vrp.c  (working copy)
@@ -2141,15 +2141,18 @@ static bool
 zero_nonzero_bits_from_vr (value_range_t *vr, double_int *may_be_nonzero,
   double_int *must_be_nonzero)
 {
+  may_be_nonzero->low = ALL_ONES;
+  may_be_nonzero->high = ALL_ONES;
+  must_be_nonzero->low = 0;
+  must_be_nonzero->high = 0;
   if (range_int_cst_p (vr))
 {
   if (range_int_cst_singleton_p (vr))
{
  *may_be_nonzero = tree_to_double_int (vr->min);
  *must_be_nonzero = *may_be_nonzero;
- return true;
}
-  if (tree_int_cst_sgn (vr->min) >= 0)
+  else if (tree_int_cst_sgn (vr->min) >= 0)
{
  double_int dmin = tree_to_double_int (vr->min);
  double_int dmax = tree_to_double_int (vr->max);
@@ -2174,13 +2177,9 @@ zero_nonzero_bits_from_vr (value_range_t
  may_be_nonzero->low |= mask;
  must_be_nonzero->low &= ~mask;
}
- return true;
}
+  return true;
 }
-  may_be_nonzero->low = ALL_ONES;
-  may_be_nonzero->high = ALL_ONES;
-  must_be_nonzero->low = 0;
-  must_be_nonzero->high = 0;
   return false;
 }
 
@@ -2638,59 +2637,17 @@ extract_range_from_binary_expr_1 (value_
 }
   else if (code == BIT_AND_EXPR || code == BIT_IOR_EXPR)
 {
-  bool vr0_int_cst_singleton_p, vr1_int_cst_singleton_p;
   bool int_cst_range0, int_cst_range1;
   double_int may_be_nonzero0, may_be_nonzero1;
   double_int must_be_nonzero0, must_be_nonzero1;
-  value_range_t *non_singleton_vr;
-  tree singleton_val;
 
-  vr0_int_cst_singleton_p = range_int_cst_singleton_p (&vr0);
-  vr1_int_cst_singleton_p = range_int_cst_singleton_p (&vr1);
   int_cst_range0 = zero_nonzero_bits_from_vr (&vr0, &may_be_nonzero0,
  &must_be_nonzero0);
   int_cst_range1 = zero_nonzero_bits_from_vr (&vr1, &may_be_nonzero1,
  &must_be_nonzero1);
 
-  singleton_val = (vr0_int_cst_singleton_p ? vr0.min : vr1.min);
-  non_singleton_vr = (vr0_int_cst_singleton_p ? &vr1 : &vr0);
-
   type = VR_RANGE;
-  if (vr0_int_cst_singleton_p && vr1_int_cst_singleton_p)
-   min = max = int_const_binop (code, vr0.max, vr1.max);
-  else if ((vr0_int_cst_singleton_p || vr1_int_cst_singleton_p)
-  && (integer_zerop (singleton_val)
-  || integer_all_onesp (singleton_val)))
-   {
- /* If one of the operands is zero for and-case, we know that
- *  the whole expression evaluates zero.
-If one of the operands has all bits set to one for
-or-case, we know that the whole expression evaluates
-to this one.  */
-  min = max = singleton_val;
-  if ((code == BIT_IOR_EXPR
-   && integer_zerop (singleton_val))
-  || (code == BIT_AND_EXPR
-  && integer_all_onesp (singleton_val)))
- /* If one of the operands has all bits set to one, we know
-that the whole expression evaluates to the other one for
-the and-case.
-If one of the operands is zero, we know that the whole
-expression evaluates to the other one for the or-case.  */
-   {
- type = non_singleton_vr->type;
- min = non_singleton_vr->min;
- max = non_singleton_vr->max;
-   }
- set_value_range (vr, type, min, max, NULL);
- return;
-   }
-  else if (!int_cst_range0 && !int_cst_range1)
-   {
- set_value_range_to_varying (vr);
- return;
-   }
-  else if (code == BIT_AND_EXPR)
+  if (code == BIT_AND_EXPR)
{
  min = double_int_to_tree (expr_type,
double_int_and (must_be_nonzero0,
@@ -2698,9 +2655,9 @@ extract_range_from_binary_expr_1 (value_
  max = double_int_to_tree (expr_type,
double_int_and (may_be_nonzero0,
may_be_nonzero1));
-  

Re: [PATCH] Correct zlib checks [Was: binutils prerequisites (recent zlib version - what else?)]

2011-08-05 Thread Paolo Bonzini

On 08/05/2011 12:07 AM, Maciej W. Rozycki wrote:

2011-08-04  Maciej W. Rozycki

config/
* zlib.m4 (AM_ZLIB): Check for compressBound instead of
zlibVersion.


Ok.

Paolo



Re: [patch i386]: Fix recent bootstrap failure for x86_64 windows target

2011-08-05 Thread Kai Tietz
2011/8/4 Kai Tietz :
> 2011/8/4 Richard Henderson :
>> On 08/04/2011 01:53 PM, Kai Tietz wrote:
>>>        diff = frame->stack_pointer_offset - 
>>> frame->hard_frame_pointer_offset;
>>> -      if (diff > 240 || (diff & 15) != 0)
>>> +      if (diff > 240 || (diff & 15) != 0 || cfun->calls_alloca != 0)
>>
>> Hmm.  Why didn't the diff > 240 test trigger?
>
> The point seems to be that the alloca block gets added later to rsp,
> but prologue is already layout, so it thinks it could use complete
> frame-size.  But due limitation of frame-size in SEH information to
> 240 bytes, this causes an assert in winnt.c:821
>
> Not sure if this is not more a paper-patch for another underlying
> issue, but it seems to work so far.

It seems not to be the proper fix.  The issue seems to be caused
somewhere else.  This patch fixed some testcases, but shows others
failing due it.

Kai


Re: [CFT, delay slots] Fix middle-end/49977

2011-08-05 Thread Hans-Peter Nilsson
On Thu, 4 Aug 2011, Richard Henderson wrote:
> This seems to do the trick for sim testing of sh-elf and cris-elf.
>
> I'm interested in advice re debugging experiences with delay slots.
> It seems like for calls there's no alternative but to have the unwind
> info be incorrect when stopped at the call insn itself.
>
> It also seems like we've similarly been generating unwind info that
> was incorrect for branches with frame-related insns in delay slots.
> Further, that by delaying the unwind info until after the sequence
> we can avoid that incorrectness.
>
> Have any of you experienced that incorrectness before, when debugging
> on your respective targets?

For calls, test crisv32-axis-elf; pre-v32 doesn't have
delay-slots for calls.  I can't claim to have done extensive
debugging on crisv32-* ... ok, blatant lie, but I mean, that
uses the debug info.  I can't remember complaints from any of
"my users" as I would probably automatically tell them from my
general experience: that debugging at any level above -O0 is
unusable.  (At least for the releases being used; 4.3 or so.)
I can have a more accurate and useful answer in two weeks...

But this in cris.md seems to answer "yes" for call insns, for
the unwind info experience (and thus the frame debug info):

;; We can't put prologue insns in call-insn delay-slots when
;; DWARF2 unwind info is emitted, because the unwinder matches the
;; address after the insn.  It must see the return address of a call at
;; a position at least *one byte after* the insn, or it'll think that
;; the insn hasn't been executed.  If the insn is in a delay-slot of a
;; call, it's just *exactly* after the insn.

(define_delay (eq_attr "slottable" "has_call_slot")
  [(and (eq_attr "slottable" "yes")
(ior (eq (symbol_ref "RTX_FRAME_RELATED_P (insn)")
 (const_int 0))
 (eq (symbol_ref "flag_exceptions")
 (const_int 0
   (nil) (nil)])

I think as long as unwind info is correct when the call has
happened, I'm ok.  If it's incorrect just before the call is
executed, then it's at least no regression.  Asynchronous
exceptions?  Never heard of them. :)

brgds, H-P


Re: [PATCH, ARM] Generate conditional compares in Thumb2 state

2011-08-05 Thread Paolo Bonzini

On 08/05/2011 03:19 AM, Ramana Radhakrishnan wrote:

cmp r0, #43
it  ne
cmpne   r1, #45
it  ne
movne   r0, r1
bx  lr



[...] there could be a single it block to handle both
and thus you could make this even better with

cmp r0, #43
itt ne
cmpne r1 ,#45
movne r0, r1


Conversion from it/op/it/op to itt/op/op (and likewise for it/op/ie/op) 
seems to be a good fit for a machine-dependent reorg pass.


Paolo


Re: Fix Tru64 UNIX Ada bootstrap

2011-08-05 Thread Arnaud Charlet
> unfortunately, it turned out that this fix only works when compiling
> ada/init.c inside gcc, not for gnatlib where CONST_CAST* isn't defined.
> I need the following patch instead, which is also simpler for using
> CONST_CAST, not CONST_CAST2, and provides a CONST_CAST definition in
> tsystem.h, where it doesn't have to care about non-gcc compilers and
> older versions of gcc.
> 
> alpha-dec-osf5.1b bootstrap has completed, make check currently
> running.  Of for mainline if that passes?

The Ada part is OK. I can't formally approve the tsystem.h bit though.

Arno


Re: CFT: [build] Move fp-bit support to toplevel libgcc

2011-08-05 Thread Rainer Orth
Paolo Bonzini  writes:

> On 08/03/2011 03:46 PM, Rainer Orth wrote:
>>
>> Ok for mainline if they pass?
>
> I think the avr-lib.h and h8300-lib.h files should be modified to only
> define the constants when compiling fp-bit, because they pollute the
> namespace.
>
> Both avr and h8300 only use floats, so you can wrap them in #ifdef FLOAT.

I'll do it this way.

> Another possibility is to add another -D option, like IN_FPBIT, to the
> Makefile and wrap the headers with that one.

Since there are only two instances currently, I think we should go for a
more general solution only when we need it.

> Otherwise ok.

Given that the patch is based on the unwinder one, could you have a look
at that, too?  While I could rebase this one and the soft-fp one if need
be, I'd like to avoid it if possible.

Thanks.
Rainer

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


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-05 Thread Paolo Bonzini

On 08/03/2011 03:32 PM, Rainer Orth wrote:

It should incorporate all review comments and a few errors I've noticed
during final review have been corrected.

I've received approval for the Darwin bits, Steve successfully tested on
HP-UX/IA64 and Linux/IA64 at least bootstrapped.  VMS/IA64 approval has
been given conditional on the approval of the other IA64 bits.  I've
also received approval for the libjava parts.

Bootstrapped without regressions (together with the next two, to be
resubmitted shortly: fp-bit and soft-fp moves) on
x86_64-unknown-linux-gnu.

i386-pc-solaris2.10, sparc-sun-solaris2.11, alpha-dec-osf5.1b,
mips-sgi-irix6.5 and i386-apple-darwin9.8.0 bootstraps in progress.
powerpc-apple-darwin9.8.0 currently broken (SIGBUS compiling
c-family/c-pretty-print.c and cp/call.c).

How should we proceed with this patch, especially given the quite
moderate comments from most affected target maintainers?


ARM is the only target we should care a bit about.  Any chance you can 
try cross-compiling it (with a combined tree it should not be hard)? 
Just to see that it builds.


Paolo


Re: [Patch, Fortran testsuite, committed] Add/fix dg-final cleanup-module

2011-08-05 Thread Mikael Morin
On Thursday 04 August 2011 23:46:08 Steve Kargl wrote:
> On Thu, Aug 04, 2011 at 11:36:11PM +0200, Mikael Morin wrote:
> > On Thursday 04 August 2011 22:45:34 Steve Kargl wrote:
> > > On Tue, Aug 02, 2011 at 05:34:46PM +0200, Tobias Burnus wrote:
> > > > There might be still some missing or wrong cleanups, but most
> > > > remaining .mod files are from gfortran.fortran-torture.
> > > 
> > > Yes, you missed a few.
> > 
> > And you missed my two patches from yesterday. ;-)
> > 
> > http://gcc.gnu.org/ml/fortran/2011-08/msg00015.html
> > http://gcc.gnu.org/ml/fortran/2011-08/msg00017.html
> 
> I saw your emails.
Note that I didn't say you missed them. :-)

> I did not read your patches.
> My statement above is correct.  Tobias missed a
> few. :-)  I had a testsuite cleanup patch sitting
> in my tree for several weeks/months; never got
> around to committing it.
> 
> ps: bessel_6.f90 is broken, but it won't show up
> until glibc finally fixes its libm.
> 
> 
> Index: gcc/testsuite/gfortran.dg/bessel_6.f90
> ===
> --- gcc/testsuite/gfortran.dg/bessel_6.f90(revision 177414)
> +++ gcc/testsuite/gfortran.dg/bessel_6.f90(working copy)
> @@ -12,7 +12,7 @@
>  implicit none
>  real,parameter :: values(*) = [0.0, 0.5, 1.0, 0.9,
> 1.8,2.0,3.0,4.0,4.25,8.0,34.53, 475.78] real,parameter ::
> myeps(size(values)) = epsilon(0.0) &
> -  * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 75, 15 ]
> +  * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 92, 15 ]
>  ! The following is sufficient for me - the values above are a bit
>  ! more tolerant
>  !  * [0, 5, 3, 4, 6, 7, 7, 5, 5, 6, 66, 4 ]

If you are seeking approval for this, it is OK.

Mikael



Re: CFT: [build] Move soft-fp support to toplevel libgcc

2011-08-05 Thread Rainer Orth
Paolo Bonzini  writes:

> On 08/03/2011 04:01 PM, Rainer Orth wrote:
>>> Configure tests could also make a better replacement for softfp_wrap_start
>>> and softfp_wrap_end.
>>
>> We've got two uses left right now:
>>
>> * libgcc/config/arm/t-softfp has #ifdef __ARM_ARCH_6M__.  One could
>>probably use AC_EGREP_CPP([__ARM_ARCH_6M__], , [arm_arch_6m=true]) in
>>configure.ac instead, but this is completely untested.
>
> It would have to be something like this:
>
> AC_EGREP_CPP([win win win], [#ifdef __ARM_ARCH_6M__
> win win win
> #endif], [arm_arch_6m=true])
>
> However, this cannot be in config.host because that file is sourced rather
> than m4_included.

It was meant to go into configure.ac directly.

> Alternatively, we can make a list of desired symbols and test them in
> configure.ac:
>
> arm-*-*)
>   ...
>   libgcc_cpp_symbols="$libgcc_cpp_symbols __ARM_ARCH_6M__"
>   tmake_file="$tm_file arm/t-softfp"
>   ;;
>
> ...
>
> # in configure.ac:
> # Look for preprocessor symbols that can be useful
> cpp_symbols=
> if test -n "$libgcc_cpp_symbols"; then
>   for i in $libgcc_cpp_symbols; do
> AC_EGREP_CPP([win win win], [#ifdef $i
>   win win win
> #endif], [AS_VAR_APPEND([cpp_symbols], [ $i])])
>   done
> fi
> AC_SUBST([cpp_symbols])
>
> ...
>
> # config/arm/t-softfp
> ifneq ($(filter __ARM_ARCH_6M__, $(cpp_symbols)),)
> include ../t-softfp-sfdf
> include ../t-softfp-excl
> include ../t-softfp
> endif

That looks like a very useful and general approach.

>> * libgcc/config/rs6000/t-linux64 has #ifndef __powerpc64__.  Again, one
>>could either check for __powerpc64__ or perform a long_type_size check
>>along the double_type_size etc. checks in the fp-bit patch.
>
> Yes, that's better than using a preprocessor symbol in this case:

Ok.

>> I'm impartial about how to handle this, but would rather get the patch
>> in and perform cleanup later than delay even more.
>
> Agreed.

Fine, thanks.  I'll work on the cleanups after I've beaten the whole
series in shape.  Right now, I've got those:

* SHLIB_* is close.

* crtstuff.c and extra_parts need a look-over.

* LIB1* and LIB2*/LIBGCC2* likewise.

* Before TARGET_LIBGCC2_CFLAGS can be removed,
  gcc/ada/gcc-interface/Makefile.in's use of it (which only needs
  PICFLAG, AFAICT) needs changing.  Right now, only three libraries may
  be built PIC, but don't use libtool: libiberty, libgcc_s, and
  libgnat/libgnarl.  Since I very much doubt that moving them to use
  libtool will get much traction, I suggest to at least centralize
  configuration of PICFLAG (in toplevel config/picflag.m4).  I've got an
  initial patch for that, but need to merge the data from libiberty and
  libgcc to complete it.

>> As the two others, bootstrapped without regressions on
>> x86_64-unknown-linux-gnu.  Bootstraps on i386-pc-solaris2.10,
>> sparc-sun-solaris2.11, alpha-dec-osf5.1b, mips-sgi-irix6.5, and
>> i386-apple-darwin9.8.0 still running.
>>
>> Ok for mainline if they pass?
>
> Yes, thank you very much!

Thanks, both for the review and the helpful suggestions.

Rainer

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


[PATCH] Add BIT_XOR_EXPR support to VRP

2011-08-05 Thread Richard Guenther

This adds BIT_XOR_EXPR support to propagation, similar to how we
have BIT_IOR_EXPR and BIT_AND_EXPR support (but without the
adjustment for constant vr0/1 min/max which I think we cannot do
for XOR).

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2011-08-05  Richard Guenther  

PR tree-optimization/49984
* tree-vrp.c (extract_range_from_binary_expr_1): Handle BIT_XOR_EXPR.

* gcc.dg/tree-ssa/vrp59.c: New testcase.

Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c  (revision 177423)
--- gcc/tree-vrp.c  (working copy)
*** extract_range_from_binary_expr_1 (value_
*** 2214,2220 
&& code != MIN_EXPR
&& code != MAX_EXPR
&& code != BIT_AND_EXPR
!   && code != BIT_IOR_EXPR)
  {
set_value_range_to_varying (vr);
return;
--- 2214,2221 
&& code != MIN_EXPR
&& code != MAX_EXPR
&& code != BIT_AND_EXPR
!   && code != BIT_IOR_EXPR
!   && code != BIT_XOR_EXPR)
  {
set_value_range_to_varying (vr);
return;
*** extract_range_from_binary_expr_1 (value_
*** 2635,2641 
min = vrp_int_const_binop (code, vr0.min, vr1.max);
max = vrp_int_const_binop (code, vr0.max, vr1.min);
  }
!   else if (code == BIT_AND_EXPR || code == BIT_IOR_EXPR)
  {
bool int_cst_range0, int_cst_range1;
double_int may_be_nonzero0, may_be_nonzero1;
--- 2636,2642 
min = vrp_int_const_binop (code, vr0.min, vr1.max);
max = vrp_int_const_binop (code, vr0.max, vr1.min);
  }
!   else if (code == BIT_AND_EXPR || code == BIT_IOR_EXPR || code == 
BIT_XOR_EXPR)
  {
bool int_cst_range0, int_cst_range1;
double_int may_be_nonzero0, may_be_nonzero1;
*** extract_range_from_binary_expr_1 (value_
*** 2694,2699 
--- 2695,2729 
  if (int_cst_range1)
min = vrp_int_const_binop (MAX_EXPR, min, vr1.min);
}
+   else if (code == BIT_XOR_EXPR)
+   {
+ double_int result_zero_bits, result_one_bits;
+ result_zero_bits
+   = double_int_ior (double_int_and (must_be_nonzero0,
+ must_be_nonzero1),
+ double_int_not
+   (double_int_ior (may_be_nonzero0,
+may_be_nonzero1)));
+ result_one_bits
+   = double_int_ior (double_int_and
+   (must_be_nonzero0,
+double_int_not (may_be_nonzero1)),
+ double_int_and
+   (must_be_nonzero1,
+double_int_not (may_be_nonzero0)));
+ max = double_int_to_tree (expr_type,
+   double_int_not (result_zero_bits));
+ min = double_int_to_tree (expr_type, result_one_bits);
+ /* Return a [min, max] range if we know the
+result range is either positive or negative.  */
+ if (tree_int_cst_sgn (max) >= 0)
+   /* The range is bound by a lower value of 0.  */;
+ else if (tree_int_cst_sgn (min) < 0)
+   /* The range is bound by an upper value of -1.  */;
+ else
+   /* We don't know whether the sign bit is set or not.  */
+   max = min = NULL_TREE;
+   }
else
{
  set_value_range_to_varying (vr);
Index: gcc/testsuite/gcc.dg/tree-ssa/vrp59.c
===
*** gcc/testsuite/gcc.dg/tree-ssa/vrp59.c   (revision 0)
--- gcc/testsuite/gcc.dg/tree-ssa/vrp59.c   (revision 0)
***
*** 0 
--- 1,35 
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -fno-tree-ccp -fdump-tree-vrp1" } */
+ 
+ int f(int x)
+ {
+   if (x >= 0 && x <= 3)
+ {
+   x = x ^ 3;
+   x = x & 3;
+ }
+   return x;
+ }
+ 
+ int g(int x)
+ {
+   if (x >= 0 && x <= 3)
+ {
+   x = x ^ 2;
+   x = x & 3;
+ }
+   return x;
+ }
+ 
+ int h(int x)
+ {
+   if (x >= 0 && x <= 3)
+ {
+   x = x ^ 1;
+   x = x & 3;
+ }
+   return x;
+ }
+ 
+ /* { dg-final { scan-tree-dump-not " & 3;" "vrp1" } } */
+ /* { dg-final { cleanup-tree-dump "vrp1" } } */


Re: [PATCH, ARM] Generate conditional compares in Thumb2 state

2011-08-05 Thread Ramana Radhakrishnan
> Conversion from it/op/it/op to itt/op/op (and likewise for it/op/ie/op)
> seems to be a good fit for a machine-dependent reorg pass.

It does happen in cases where you have proper cond-exec patterns. It's
final pre-scan that manages this though there is probably a win in
doing this before constant pool placements in md_reorg. If we could
represent this in rtl as cond-exec I think that will just pick this
up.

Ramana

>
> Paolo
>


Re: PR ada/49944, take 2 [4.5/4.6/4.7 regression] Bootstrapping on x86_64-pc-kfreebsd-gnu fails with "s-taprop.adb:856:10: "pthread_attr_setaffinity_np" is undefined (more references follow)"

2011-08-05 Thread Ludovic Brenta
Arnaud Charlet  writes:
> The above ChangeLog isn't quite in the proper format.
> Also see below for a few stylistic issues to fix.
>
> Once fixed, the patch is OK to commit, thanks.

Here is my amended patch.  I have fixed the stylistic issues in both
s-osinte-kfreebsd-gnu.ads and in the original place,
s-osinte-freebsd.ads.  I hope the changelog entry is more correct, too.

2011-08-05  Ludovic Brenta 

PR ada/49944
* s-osinte-freebsd.ads:
- update copyright years.
- minor reformatting.
(Stack_Base_Available): correct comments.
* gcc-interface/Makefile.in (kfreebsd%):
use s-taprop-posix.ad[bs] instead of s-taprop-linux.ad[bs].
use s-tasinf.ad[bs] instead of s-tasinf-linux.ad[bs].
* s-osinte-kfreebsd-gnu.ads
  (Time_Slice_Supported): copy from s-osinte-freebsd.ads.
  (nanosleep): ditto.
  (clock_id_t, clock_gettime): ditto.
  (Stack_Base_Available): ditto.
  (Get_Page_Size): ditto.
  (mprotect): ditto.
  (pthread_mutexattr_setprotocol): ditto.
  (pthread_mutexattr_getprotocol): ditto.
  (pthread_mutexattr_setprioceiling): ditto.
  (pthread_mutexattr_getprioceiling): ditto.
  (pthread_attr_setscope): ditto.
  (pthread_attr_getscope): ditto.
  (pthread_attr_setinheritsched): ditto.
  (pthread_attr_getinheritsched): ditto.

Index: b/src/gcc/ada/s-osinte-kfreebsd-gnu.ads
===
--- a/src/gcc/ada/s-osinte-kfreebsd-gnu.ads
+++ b/src/gcc/ada/s-osinte-kfreebsd-gnu.ads
@@ -7,7 +7,7 @@
 --  S p e c --
 --  --
 -- Copyright (C) 1991-1994, Florida State University--
--- Copyright (C) 1995-2005,2008 Free Software Foundation, Inc.  --
+--  Copyright (C) 1995-2011, Free Software Foundation, Inc. --
 --  --
 -- GNARL is free software; you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -32,7 +32,7 @@
 --  --
 --
 
---  This is the GNU/kFreeBSD (GNU/LinuxThreads) version of this package
+--  This is the GNU/kFreeBSD PTHREADS version of this package
 
 --  This package encapsulates all direct interfaces to OS services
 --  that are needed by children of System.
@@ -200,8 +200,24 @@
-- Time --
--
 
+   Time_Slice_Supported : constant Boolean := True;
+   --  Indicates whether time slicing is supported (i.e SCHED_RR is supported)
+
type timespec is private;
 
+   function nanosleep (rqtp, rmtp : access timespec) return int;
+   pragma Import (C, nanosleep, "nanosleep");
+
+   type clockid_t is private;
+
+   CLOCK_REALTIME : constant clockid_t;
+
+   function clock_gettime
+ (clock_id : clockid_t;
+  tp   : access timespec)
+  return int;
+   pragma Import (C, clock_gettime, "clock_gettime");
+
function To_Duration (TS : timespec) return Duration;
pragma Inline (To_Duration);
 
@@ -273,6 +289,10 @@
type pthread_key_t   is private;
 
PTHREAD_CREATE_DETACHED : constant := 1;
+   PTHREAD_CREATE_JOINABLE : constant := 0;
+
+   PTHREAD_SCOPE_PROCESS : constant := 0;
+   PTHREAD_SCOPE_SYSTEM  : constant := 2;
 
---
-- Stack --
@@ -296,9 +316,29 @@
Alternate_Stack_Size : constant := 0;
--  No alternate signal stack is used on this platform
 
+   Stack_Base_Available : constant Boolean := False;
+   --  Indicates whether the stack base is available on this target
+
function Get_Stack_Base (thread : pthread_t) return Address;
pragma Inline (Get_Stack_Base);
-   --  This is a dummy procedure to share some GNULLI files
+   --  returns the stack base of the specified thread. Only call this function
+   --  when Stack_Base_Available is True.
+
+   function Get_Page_Size return size_t;
+   function Get_Page_Size return Address;
+   pragma Import (C, Get_Page_Size, "getpagesize");
+   --  Returns the size of a page
+
+   PROT_NONE  : constant := 0;
+   PROT_READ  : constant := 1;
+   PROT_WRITE : constant := 2;
+   PROT_EXEC  : constant := 4;
+   PROT_ALL   : constant := PROT_READ + PROT_WRITE + PROT_EXEC;
+   PROT_ON: constant := PROT_NONE;
+   PROT_OFF   : constant := PROT_ALL;
+
+   function mprotect (addr : Address; len : size_t; prot : int) return int;
+   pragma Import (C, mprotect);
 
---
-- Nonstandard Thread Initialization --
@@ -387,6 +427,36 @@
-- POSIX.1c  Section 13 --
--
 
+   PTHREAD_PRIO_NONE: constant := 0;
+   PTHREAD_PRIO_PROTECT :

[PATCH] Extend VRP BIT_IOR_EXPR to handle sign-bit

2011-08-05 Thread Richard Guenther

This removes one weakness in BIT_IOR_EXPR handling which gives
up even if we can compute a fully negative range.  The following
thus extends zero_nonzero_bits_from_vr to extract sign-bit
information (I believe that's the only bit we know sth about
when both vr.min and vr.max are negative).  It also adjusts
BIT_IOR_EXPR handling to not give up for the min < max < 0 case.

Boostrapped on x86_64-unknown-linux-gnu, testing in progress.

I guess BIT_AND_EXPR handling will show a similar weakness but
a similar testcase (as added below) already passes.  So I suppose
we have to obfuscate it a bit more ;)

Richard.

2011-08-05  Richard Guenther  

* tree-vrp.c (zero_nonzero_bits_from_vr): Pass in a type.
For ranges with negative values return information about the
sign-bit.
(extract_range_from_binary_expr_1): Adjust BIT_IOR_EXPR handling
to handle sign-bit information for ranges with negative values.
(simplify_bit_ops_using_ranges): Adjust.

* gcc.dg/tree-ssa/vrp60.c: New testcase.

Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c  (revision 177425)
--- gcc/tree-vrp.c  (working copy)
*** vrp_int_const_binop (enum tree_code code
*** 2138,2144 
 the bit is 1, otherwise it might be 0 or 1.  */
  
  static bool
! zero_nonzero_bits_from_vr (value_range_t *vr, double_int *may_be_nonzero,
   double_int *must_be_nonzero)
  {
may_be_nonzero->low = ALL_ONES;
--- 2138,2145 
 the bit is 1, otherwise it might be 0 or 1.  */
  
  static bool
! zero_nonzero_bits_from_vr (value_range_t *vr, tree type,
!  double_int *may_be_nonzero,
   double_int *must_be_nonzero)
  {
may_be_nonzero->low = ALL_ONES;
*** zero_nonzero_bits_from_vr (value_range_t
*** 2178,2183 
--- 2179,2192 
  must_be_nonzero->low &= ~mask;
}
}
+   else if (tree_int_cst_sgn (vr->max) < 0)
+   {
+ /* The only thing we know when the range covers only negative
+values is that the sign bit must be set.  */
+ *may_be_nonzero = double_int_minus_one;
+ *must_be_nonzero
+   = double_int_setbit (double_int_zero, TYPE_PRECISION (type) - 1);
+   }
return true;
  }
return false;
*** extract_range_from_binary_expr_1 (value_
*** 2642,2650 
double_int may_be_nonzero0, may_be_nonzero1;
double_int must_be_nonzero0, must_be_nonzero1;
  
!   int_cst_range0 = zero_nonzero_bits_from_vr (&vr0, &may_be_nonzero0,
  &must_be_nonzero0);
!   int_cst_range1 = zero_nonzero_bits_from_vr (&vr1, &may_be_nonzero1,
  &must_be_nonzero1);
  
type = VR_RANGE;
--- 2651,2661 
double_int may_be_nonzero0, may_be_nonzero1;
double_int must_be_nonzero0, must_be_nonzero1;
  
!   int_cst_range0 = zero_nonzero_bits_from_vr (&vr0, expr_type,
! &may_be_nonzero0,
  &must_be_nonzero0);
!   int_cst_range1 = zero_nonzero_bits_from_vr (&vr1, expr_type,
! &may_be_nonzero1,
  &must_be_nonzero1);
  
type = VR_RANGE;
*** extract_range_from_binary_expr_1 (value_
*** 2683,2699 
  max = double_int_to_tree (expr_type,
double_int_ior (may_be_nonzero0,
may_be_nonzero1));
- if (tree_int_cst_sgn (max) < 0)
-   max = NULL_TREE;
  if (int_cst_range0)
!   {
! if (tree_int_cst_sgn (min) < 0)
!   min = vr0.min;
! else
!   min = vrp_int_const_binop (MAX_EXPR, min, vr0.min);
!   }
  if (int_cst_range1)
min = vrp_int_const_binop (MAX_EXPR, min, vr1.min);
}
else if (code == BIT_XOR_EXPR)
{
--- 2694,2709 
  max = double_int_to_tree (expr_type,
double_int_ior (may_be_nonzero0,
may_be_nonzero1));
  if (int_cst_range0)
!   min = vrp_int_const_binop (MAX_EXPR, min, vr0.min);
  if (int_cst_range1)
min = vrp_int_const_binop (MAX_EXPR, min, vr1.min);
+ if (tree_int_cst_sgn (min) < 0)
+   ;
+ else if (tree_int_cst_sgn (max) >= 0)
+   ;
+ else
+   min = max = NULL_TREE;
}
else if (code == BIT_XOR_EXPR)
{
*** simplify_bit_ops_using_ranges (gimple_st
*** 6984,6992 
else
  return false;
  
!   if (!zero_nonzero_bits_from_vr (&vr0, &may_be_nonzero0, &must_be_nonzero0))
   

Re: PR ada/49944, take 2 [4.5/4.6/4.7 regression] Bootstrapping on x86_64-pc-kfreebsd-gnu fails with "s-taprop.adb:856:10: "pthread_attr_setaffinity_np" is undefined (more references follow)"

2011-08-05 Thread Arnaud Charlet
> Here is my amended patch.  I have fixed the stylistic issues in both
> s-osinte-kfreebsd-gnu.ads and in the original place,
> s-osinte-freebsd.ads.  I hope the changelog entry is more correct, too.

Better but not quite the standard style yet. I believe there's a doc in gnu.org
explaining the proper format for ChangeLogs. I'd suggest you familiarize
yourself with this document.

> 2011-08-05  Ludovic Brenta 
> 
>   PR ada/49944
>   * s-osinte-freebsd.ads:
>   - update copyright years.
>   - minor reformatting.

We don't use "-" in changelog in general, so would be more something like:

* s-osinte-freebsd.ads: Update copyright years. Minor reformatting.
(Stack_Base_Available): Correct comments.

Also we don't put a newline just after the file name.

>   * gcc-interface/Makefile.in (kfreebsd%):
>   use s-taprop-posix.ad[bs] instead of s-taprop-linux.ad[bs].
>   use s-tasinf.ad[bs] instead of s-tasinf-linux.ad[bs].

>   * s-osinte-kfreebsd-gnu.ads
> (Time_Slice_Supported): copy from s-osinte-freebsd.ads.
> (nanosleep): ditto.
> (clock_id_t, clock_gettime): ditto.
> (Stack_Base_Available): ditto.
> (Get_Page_Size): ditto.
> (mprotect): ditto.
> (pthread_mutexattr_setprotocol): ditto.
> (pthread_mutexattr_getprotocol): ditto.
> (pthread_mutexattr_setprioceiling): ditto.
> (pthread_mutexattr_getprioceiling): ditto.
> (pthread_attr_setscope): ditto.
> (pthread_attr_getscope): ditto.
> (pthread_attr_setinheritsched): ditto.
> (pthread_attr_getinheritsched): ditto.

The indentation is wrong above, should be one TAB character everywhere.
You can also list all functions at once, and after a semicolon, usually
you should start with an upper case:

* s-osinte-kfreebsd-gnu.ads (Time_Slice_Supported, nanosleep,
clock_id_t, clock_gettime, Stack_Base_Available, Get_Page_Size,
mprotect, pthread_mutexattr_setprotocol, pthread_mutexattr_getprotocol,
pthread_mutexattr_setprioceiling, pthread_mutexattr_getprioceiling,
pthread_attr_setscope, pthread_attr_getscope,
pthread_attr_setinheritsched, pthread_attr_getinheritsched,
Time_Slice_Supported): Copy from s-osinte-freebsd.ads.

> ---  This is the GNU/kFreeBSD (GNU/LinuxThreads) version of this package
> +--  This is the GNU/kFreeBSD PTHREADS version of this package

Not sure why PTHREADS is upper cased here, any specific reason? If not,
I'd lower case it. Actually I'd probably replace it by:

--  This is the GNU/kFreeBSD (POSIX Threads) version of this package

unless "PTHREADS" has a special meaning on kFreeBSD.

OK with the above changes.

Arno


[patch, vectorizer] Fix a bug in creation of reduction epilogue

2011-08-05 Thread Ira Rosen

Hi,

In case of multiple loop exit phis in vectorization of reduction we reduce
them to one vector. The result of this reduction is later ignored in case
we do the final value extraction with scalar code. This causes wrong code
generation for gfortran.dg/forall_7.f90 with -O3 -funroll-loops on Cell
SPU. This patch fixes this.

Bootstrapped on powerpc64-suse-linux and tested on powerpc64-suse-linux and
on spu-redhat-linux.
Committed.

Ira

ChangeLog:

* tree-vect-loop.c (vect_create_epilog_for_reduction): Use the
result of multiple results reduction when extracting the final
value using scalar code.

Index: tree-vect-loop.c
===
--- tree-vect-loop.c(revision 177266)
+++ tree-vect-loop.c(working copy)
@@ -3683,13 +3683,13 @@ vect_create_epilog_for_reduction (VEC (tree, heap)
 {
   tree first_vect = PHI_RESULT (VEC_index (gimple, new_phis, 0));
   tree tmp;
+  gimple new_vec_stmt = NULL;

   vec_dest = vect_create_destination_var (scalar_dest, vectype);
   for (k = 1; k < VEC_length (gimple, new_phis); k++)
 {
   gimple next_phi = VEC_index (gimple, new_phis, k);
   tree second_vect = PHI_RESULT (next_phi);
-  gimple new_vec_stmt;

   tmp = build2 (code, vectype,  first_vect, second_vect);
   new_vec_stmt = gimple_build_assign (vec_dest, tmp);
@@ -3699,6 +3699,11 @@ vect_create_epilog_for_reduction (VEC (tree, heap)
 }

   new_phi_result = first_vect;
+  if (new_vec_stmt)
+{
+  VEC_truncate (gimple, new_phis, 0);
+  VEC_safe_push (gimple, heap, new_phis, new_vec_stmt);
+}
 }
   else
 new_phi_result = PHI_RESULT (VEC_index (gimple, new_phis, 0));
@@ -3809,7 +3814,10 @@ vect_create_epilog_for_reduction (VEC (tree, heap)
   vec_size_in_bits = tree_low_cst (TYPE_SIZE (vectype), 1);
   FOR_EACH_VEC_ELT (gimple, new_phis, i, new_phi)
 {
-  vec_temp = PHI_RESULT (new_phi);
+  if (gimple_code (new_phi) == GIMPLE_PHI)
+vec_temp = PHI_RESULT (new_phi);
+  else
+vec_temp = gimple_assign_lhs (new_phi);
   rhs = build3 (BIT_FIELD_REF, scalar_type, vec_temp, bitsize,
 bitsize_zero_node);
   epilog_stmt = gimple_build_assign (new_scalar_dest, rhs);



Re: [PATCH Atom][PR middle-end/44382] Tree reassociation improvement

2011-08-05 Thread Richard Guenther
On Tue, Jul 19, 2011 at 4:46 PM, Ilya Enkovich  wrote:
> Hello Richard,
>
> Thanks a lot for the review!
>
>> it's not easy to follow the flow of this function, esp. I wonder
>>
>> +      else
>> +       {
>> +         tree var = create_tmp_reg (TREE_TYPE (last_rhs1), "reassoc");
>> +         add_referenced_var (var);
>> +         stmts[i] = build_and_add_sum (var, op1, op2, opcode);
>> +       }
>>
>> what you need to create new stmts for, and if you possibly create
>> multiple temporary variables here.
>>
>> -  TODO_verify_ssa
>> +  TODO_remove_unused_locals
>> +    | TODO_verify_ssa
>>
>> why?
>>
>
> Current rewrite_expr_tree uses original statements and  just change
> order of operands (tree leafs) usage. To keep data flow correct it
> moves all statements down to the last one. I tried such approach but
> it did not work well because of increased registers pressure in some
> cases (all operands are live at the same time right before the first
> statement of our sequence). Then I tried to move existing statements
> to the appropriate places (just after the last operand definition) but
> it appeared to be not so easy. It is easy to guarantee consistence in
> the final result but not easy to keep data flow consistent after each
> statement move. And if we do not keep code consistent after each move
> then we may get wrong debug statement generated. After few tries I
> decided that the most easy for both understanding and implementation
> way is to recreate statements and remove the old chain. So, I used
> build_and_add_sum to create all statements except the last one which
> never needs recreation. I added TODO_remove_unused_locals since temps
> used in original statements should be removed. Is this approach OK?

Well, it's enough to delay that to later passes that do this, so I'd prefer
to not change this in this patch.

>> You don't seem to handle the special-cases of rewrite_expr_tree
>> for the leafs of your tree, especially the PHI node special-casing.
>> I think you may run into vectorization issues here.
>>
> I do not see any reason why these cases are checked in
> rewrite_expr_tree. It is optimization of operands order and may be it
> will be good to move it somewhere. Is it OK if I move related code to
> the end of optimize_ops_list method?

I suppose yes.  Maybe the cases are also obsoleted by the improved
loop PHI handling.

Richard.

> Thanks
> Ilya
>


Re: [PATCH] Extend VRP BIT_IOR_EXPR to handle sign-bit

2011-08-05 Thread Paolo Bonzini

On 08/05/2011 01:04 PM, Richard Guenther wrote:

(I believe that's the only bit we know sth about
when both vr.min and vr.max are negative).


Depends, if the value is between -2^16 and -1, we know something about 
all the bits to the left of bit 15.  I think a better mask is:


* MUST_BE_NONZERO = vr->min with all bits zero after the leftmost zero 
bit.  Or, the leftmost clz(~vr->min) bits are one.

* MAY_BE_NONZERO = all ones.

But something similar to xor_mask can likely be done with negative 
numbers too.  For example, if the value is between -32769 and -32768, 
you know that bits 1 to 14 are zero, and bits starting at 15 are one.


Paolo


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-05 Thread Rainer Orth
Paolo Bonzini  writes:

>> How should we proceed with this patch, especially given the quite
>> moderate comments from most affected target maintainers?
>
> ARM is the only target we should care a bit about.  Any chance you can try
> cross-compiling it (with a combined tree it should not be hard)? Just to
> see that it builds.

I've tried to setup crosstool-NG in the past, but failed and haven't
gotten around to debugging this yet.  I still mean to, especially given
that I need to investigate testsuite issues in a cross environment.

Nick already ok'ed the arm (and frv) parts, so we should be ok for now.

Rainer

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


Re: RFC: Rewriting auto-inc-dec.c

2011-08-05 Thread Bernd Schmidt
On 07/21/11 17:42, Richard Sandiford wrote:

> At the moment, auto-inc-dec.c only considers pairs of instructions,
> so it can't optimise this kind of sequence.  The attached patch is a
> WIP (but almost complete) attempt to handle longer sequences too.

So, I promised to look at it, I guess I better do so before disappearing
on vacation. It's a lot to take in; so far I think I get the overall
structure and some of the details.

On the whole I think it looks good. I've tried to come up with such
algorithms in the past, but I think I always tried too hard to find
"optimal" solutions. The algorithm here looks reasonable.

>   /* When optimizing for speed, don't introduce dependencies between
>  memory references in the chain and memory references outside of it,
>  since doing so would limit scheduling.  If the chain is truly
>  worthwhile, we can still try again using a new pseudo register.  */

Now, it's good that there is at least some consideration for this, but I
wonder whether it's possible to do better here. The basic principle is
that if something is achievable without autoinc, in the same number of
insns (or a factor 1.x thereof with x small), then it's preferrable not
to use autoinc at all.

For example,

>... = *r1... = *rN++
>... = *(r1 + 4)  ... = *rN
>  *(r1 + 4) = ...  *rN++ = ...
> r2 = r1 + 8  r2 = rN
>... = *r2  --->  ... = rN++
> r3 = r2 + 4  r3 = rN
>... = *r3... = rN++
> r4 = r1 + 16 r4 = rN
>... = *r4... = rN

On many targets, this would best be handled as a series of (reg +
offset) addressing modes. If an update is required, on targets that
support both (reg + offset) and {pre,post}_modify, it would be good to
have an automodify in just one of the addresses; if a single add insn is
required this may still be better if the number of memory references is
large enough. Do you think this is something that can be done in the
context of this pass?

Minor details:

I'm not sure all the code is completely safe if a hardreg is used with a
mix of single- and multi-word accesses. Maybe just mark a hardreg that
occurs in a multi-word mode as unavailable for the optimization?

It would be nice not to have semi-identical pairs of functions like
other_uses_before and other_uses_after or valid_mem_add_pair and
valid_add_mem_pair. Can these be merged sensibly?

Just to make sure, my understanding is that this will also generate
(automod (reg1) (plus (reg1) (reg2))). Right?

> /* Represents an offset that is applied to a valno base.  */
> union valno_offset {
>   HOST_WIDE_INT constant;
>   struct valno_def *valno;
> };

Should mention that this is used as splay tree key? For some reason I
find it slightly scary to use a union as a key; I see that things like
valno_splay have a constant_p parameter - maybe you want two separate
trees instead?

> /* Create a new entry with key KEY in ROOT's derived tree.  */
> 
> static struct valno_def *
> new_splay_valno (bool constant_p, struct valno_def *base,
>  union valno_offset *offset)

Comment doesn't match definition.

> Using rtx costs does make things worse on some targets, which I think
> is due to dubious MEM costs.  m68k is a particularly bad case, because
> for -Os, it uses byte counts rather than COSTS_N_INSNS.

Let the m68k maintainers worry about that particular problem. The basic
principle must be to have the optimizers use costs reasonably and expect
targets to define them reasonably.


Bernd


Re: Fix Tru64 UNIX Ada bootstrap

2011-08-05 Thread Rainer Orth
Arnaud Charlet  writes:

>> unfortunately, it turned out that this fix only works when compiling
>> ada/init.c inside gcc, not for gnatlib where CONST_CAST* isn't defined.
>> I need the following patch instead, which is also simpler for using
>> CONST_CAST, not CONST_CAST2, and provides a CONST_CAST definition in
>> tsystem.h, where it doesn't have to care about non-gcc compilers and
>> older versions of gcc.
>> 
>> alpha-dec-osf5.1b bootstrap has completed, make check currently
>> running.  Of for mainline if that passes?
>
> The Ada part is OK. I can't formally approve the tsystem.h bit though.

Since this fixes a bootstrap failure, I've installed the patch,
considering the tsystem.h part obvious.

Thanks.
Rainer

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


[libgomp, testsuite] Fix libgomp.c++/task-8.C on Solaris 11 (PR libgomp/49965)

2011-08-05 Thread Rainer Orth
As described in the PR, libgomp.c++/task-8.C FAILs on Solaris 11 with
Sun ld:

FAIL: libgomp.c++/task-8.C  -O0  (test for excess errors)
Excess errors:
ld: warning: symbol 'err' has differing types:
(file /var/tmp//ccD0aiQD.o type=OBJT; file /lib/libc.so type=FUNC);
/var/tmp//ccD0aiQD.o definition taken
ld: warning: symbol 'err' has differing types:
(file /var/tmp//ccD0aiQD.o type=OBJT; file /lib/libc.so type=FUNC);

Fixed as follows, tested with the appropriate runtest invocations on
x86_64-unknown-linux-gnu, i386-pc-solaris2.10, i386-pc-solaris2.11,
installed on mainline.

Rainer


2011-08-03  Rainer Orth  

PR libgomp/49965
* testsuite/libgomp.c++/task-8.C: Replaced err by errval.

diff --git a/libgomp/testsuite/libgomp.c++/task-8.C 
b/libgomp/testsuite/libgomp.c++/task-8.C
--- a/libgomp/testsuite/libgomp.c++/task-8.C
+++ b/libgomp/testsuite/libgomp.c++/task-8.C
@@ -3,42 +3,42 @@
 #include 
 #include 
 
-int err;
+int errval;
 
 int
 main ()
 {
   int e;
-#pragma omp parallel shared(err)
+#pragma omp parallel shared(errval)
   {
 if (omp_in_final ())
   #pragma omp atomic write
-   err = 1;
-#pragma omp task if (0) shared(err)
+   errval = 1;
+#pragma omp task if (0) shared(errval)
   {
if (omp_in_final ())
  #pragma omp atomic write
-   err = 1;
-   #pragma omp task if (0) shared(err)
+   errval = 1;
+   #pragma omp task if (0) shared(errval)
  if (omp_in_final ())
#pragma omp atomic write
- err = 1;
+ errval = 1;
   }
-#pragma omp task final (1) shared(err)
+#pragma omp task final (1) shared(errval)
   {
if (!omp_in_final ())
  #pragma omp atomic write
-   err = 1;
+   errval = 1;
#pragma omp taskyield
#pragma omp taskwait
-   #pragma omp task shared(err)
+   #pragma omp task shared(errval)
  if (!omp_in_final ())
#pragma omp atomic write
- err = 1;
+ errval = 1;
   }
   }
   #pragma omp atomic read
-e = err;
+e = errval;
   if (e)
 abort ();
 }

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


[PATCH] Handle BIT_NOT_EXPR in VRP

2011-08-05 Thread Richard Guenther

This extends VRP to handle BIT_NOT_EXPR by composing ~X as
-X - 1 (which should give us anti-range handling for free).

It requires factoring a value-range taking worker from
extract_range_from_unary_expr like I already did for
extract_range_from_binary_expr, thus that is included in this patch.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2011-08-05  Richard Guenther  

* tree-vrp.c (extract_range_from_unary_expr_1): New function,
split out from ...
(extract_range_from_unary_expr): ... here.  Handle BIT_NOT_EXPR
by composition.

Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c  (revision 177425)
--- gcc/tree-vrp.c  (working copy)
*** extract_range_from_binary_expr (value_ra
*** 2805,2864 
extract_range_from_binary_expr_1 (vr, code, expr_type, &vr0, &vr1);
  }
  
! /* Extract range information from a unary expression EXPR based on
!the range of its operand and the expression code.  */
  
  static void
! extract_range_from_unary_expr (value_range_t *vr, enum tree_code code,
!  tree type, tree op0)
  {
tree min, max;
int cmp;
!   value_range_t vr0 = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
  
/* Refuse to operate on certain unary expressions for which we
   cannot easily determine a resulting range.  */
if (code == FIX_TRUNC_EXPR
|| code == FLOAT_EXPR
-   || code == BIT_NOT_EXPR
|| code == CONJ_EXPR)
  {
-   /* We can still do constant propagation here.  */
-   if ((op0 = op_with_constant_singleton_value_range (op0)) != NULL_TREE)
-   {
- tree tem = fold_unary (code, type, op0);
- if (tem
- && is_gimple_min_invariant (tem)
- && !is_overflow_infinity (tem))
-   {
- set_value_range (vr, VR_RANGE, tem, tem, NULL);
- return;
-   }
-   }
set_value_range_to_varying (vr);
return;
  }
  
-   /* Get value ranges for the operand.  For constant operands, create
-  a new value range with the operand to simplify processing.  */
-   if (TREE_CODE (op0) == SSA_NAME)
- vr0 = *(get_value_range (op0));
-   else if (is_gimple_min_invariant (op0))
- set_value_range_to_value (&vr0, op0, NULL);
-   else
- set_value_range_to_varying (&vr0);
- 
-   /* If VR0 is UNDEFINED, so is the result.  */
-   if (vr0.type == VR_UNDEFINED)
- {
-   set_value_range_to_undefined (vr);
-   return;
- }
- 
/* Refuse to operate on symbolic ranges, or if neither operand is
   a pointer or integral type.  */
!   if ((!INTEGRAL_TYPE_P (TREE_TYPE (op0))
!&& !POINTER_TYPE_P (TREE_TYPE (op0)))
|| (vr0.type != VR_VARYING
  && symbolic_range_p (&vr0)))
  {
--- 2815,2854 
extract_range_from_binary_expr_1 (vr, code, expr_type, &vr0, &vr1);
  }
  
! /* Extract range information from a unary operation CODE based on
!the range of its operand *VR0 with type OP0_TYPE with resulting type TYPE.
!The The resulting range is stored in *VR.  */
  
  static void
! extract_range_from_unary_expr_1 (value_range_t *vr,
!enum tree_code code, tree type,
!value_range_t *vr0_, tree op0_type)
  {
+   value_range_t vr0 = *vr0_;
tree min, max;
int cmp;
! 
!   /* If VR0 is UNDEFINED, so is the result.  */
!   if (vr0.type == VR_UNDEFINED)
! {
!   set_value_range_to_undefined (vr);
!   return;
! }
  
/* Refuse to operate on certain unary expressions for which we
   cannot easily determine a resulting range.  */
if (code == FIX_TRUNC_EXPR
|| code == FLOAT_EXPR
|| code == CONJ_EXPR)
  {
set_value_range_to_varying (vr);
return;
  }
  
/* Refuse to operate on symbolic ranges, or if neither operand is
   a pointer or integral type.  */
!   if ((!INTEGRAL_TYPE_P (op0_type)
!&& !POINTER_TYPE_P (op0_type))
|| (vr0.type != VR_VARYING
  && symbolic_range_p (&vr0)))
  {
*** extract_range_from_unary_expr (value_ran
*** 2868,2896 
  
/* If the expression involves pointers, we are only interested in
   determining if it evaluates to NULL [0, 0] or non-NULL (~[0, 0]).  */
!   if (POINTER_TYPE_P (type) || POINTER_TYPE_P (TREE_TYPE (op0)))
  {
!   bool sop;
! 
!   sop = false;
!   if (range_is_nonnull (&vr0)
! || (tree_unary_nonzero_warnv_p (code, type, op0, &sop)
! && !sop))
set_value_range_to_nonnull (vr, type);
else if (range_is_null (&vr0))
set_value_range_to_null (vr, type);
else
set_value_range_to_varying (vr);
- 
return;
  }
  
/* Handle unary expressions on integer ranges.  */
if (CONVERT_EXPR_CODE_P (code)
&& INTEGRAL_TYPE_P (type)
!   && INTEGRAL_TYPE_P (TREE_TYPE (op0))

[MELT] Fix MELT breakage at build

2011-08-05 Thread Alexandre Lissy
Hello,

Following is a trivial patch patch that fixes build of the current
melt-branch, due to some previous commit changing identifier
"fullbinfile" to "binbase" in function parameters but not in some usages
at the end of the function.



[PATCH] Fix regression with unexistent symbol 'fullbinfile'

2011-08-05 Thread Alexandre Lissy

This symbol has been changed to binbase a couple of commits ago, yet
some places remained untouched for the new name.
---
 gcc/melt-runtime.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/melt-runtime.c b/gcc/melt-runtime.c
index 32a4288..ad49ccb 100644
--- a/gcc/melt-runtime.c
+++ b/gcc/melt-runtime.c
@@ -5044,13 +5044,13 @@ melt_run_make_for_plugin (const char*ourmakecommand, const char*ourmakefile, con
 melt_fatal_error ("MELT module compilation failed for command %s", cmdstr);
   cmdstr = NULL;
   obstack_free (&cmd_obstack, NULL); /* free all the cmd_obstack */
-  debugeprintf ("melt_run_make_for_plugin meltplugin did built fullbinfile %s", 
-		fullbinfile);
-  if (IS_ABSOLUTE_PATH (fullbinfile))
-inform (UNKNOWN_LOCATION, "MELT plugin has built module %s", fullbinfile);
+  debugeprintf ("melt_run_make_for_plugin meltplugin did built binbase %s", 
+		binbase);
+  if (IS_ABSOLUTE_PATH (binbase))
+inform (UNKNOWN_LOCATION, "MELT plugin has built module %s", binbase);
   else
 inform (UNKNOWN_LOCATION, "MELT plugin has built module %s in %s",
-	fullbinfile, mycwd);
+	binbase, mycwd);
   return;
 }
 


[Ada] Do not generate wrong transient scopes for pragma check in ALFA mode

2011-08-05 Thread Arnaud Charlet
In formal verification mode, pragma check and enclosed expression are not
expanded, so no transient scope should be introduced for a pragma check as a
result of the introduction of temporary variables during expansion.

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

2011-08-05  Yannick Moy  

* exp_ch7.adb (Establish_Transient_Scope): in formal verification mode,
if the node to wrap is a pragma check, this node and enclosed
expression are not expanded, so do not apply any transformations here.
* exp_prag.adb (Expand_Pragma_Check): document the need to avoid
introducing transient scopes.

Index: exp_prag.adb
===
--- exp_prag.adb(revision 177382)
+++ exp_prag.adb(working copy)
@@ -321,7 +321,10 @@
   --  be an explicit conditional in the source, not an implicit if, so we
   --  do not call Make_Implicit_If_Statement.
 
-  --  In formal verification mode, we keep the pragma check in the code
+  --  In formal verification mode, we keep the pragma check in the code,
+  --  and its enclosed expression is not expanded. This requires that no
+  --  transient scope is introduced for pragma check in this mode in
+  --  Exp_Ch7.Establish_Transient_Scope.
 
   if ALFA_Mode then
  return;
Index: exp_ch7.adb
===
--- exp_ch7.adb (revision 177407)
+++ exp_ch7.adb (working copy)
@@ -3532,6 +3532,16 @@
   elsif Nkind (Wrap_Node) = N_Iteration_Scheme then
  null;
 
+  --  In formal verification mode, if the node to wrap is a pragma check,
+  --  this node and enclosed expression are not expanded, so do not apply
+  --  any transformations here.
+
+  elsif ALFA_Mode
+and then Nkind (Wrap_Node) = N_Pragma
+and then Get_Pragma_Id (Wrap_Node) = Pragma_Check
+  then
+ null;
+
   else
  Push_Scope (New_Internal_Entity (E_Block, Current_Scope, Loc, 'B'));
  Set_Scope_Is_Transient;


[Ada] Add support for file attributes on VxWorks 6

2011-08-05 Thread Arnaud Charlet
The routines to modify the file attributes (rwx) are now implemented on
VxWorks 6 (kernel and RTP) using the underlying chmod VxWorks routine.

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

2011-08-05  Jose Ruiz  

* adaint.c (__gnat_set_writable, __gnat_set_readable,
__gnat_set_executable, __gnat_set_non_writable, __gnat_set_non_readable,
__gnat_copy_attribs): On VxWorks 6.x and later, the required chmod
routine is available, so we use the default implementation of these
functions.
* s-os_lib.ads (Copy_File, Copy_Time_Stamps): Document that there is
support for copying attributes on VxWorks 6.

Index: adaint.c
===
--- adaint.c(revision 177390)
+++ adaint.c(working copy)
@@ -56,6 +56,10 @@
 #include 
 #endif /* _WRS_CONFIG_SMP */
 
+/* We need to know the VxWorks version because some file operations
+   (such as chmod) are only available on VxWorks 6.  */
+#include "version.h"
+
 #endif /* VxWorks */
 
 #if (defined (__mips) && defined (__sgi)) || defined (__APPLE__)
@@ -84,6 +88,17 @@
 #include 
 #endif
 
+#ifdef __vxworks
+/* S_IREAD and S_IWRITE are not defined in VxWorks */
+#ifndef S_IREAD
+#define S_IREAD  (S_IRUSR | S_IRGRP | S_IROTH)
+#endif
+
+#ifndef S_IWRITE
+#define S_IWRITE (S_IWUSR)
+#endif
+#endif
+
 /* We don't have libiberty, so use malloc.  */
 #define xmalloc(S) malloc (S)
 #define xrealloc(V,S) realloc (V,S)
@@ -2191,7 +2206,8 @@
 
   SetFileAttributes
 (wname, GetFileAttributes (wname) & ~FILE_ATTRIBUTE_READONLY);
-#elif ! defined (__vxworks) && ! defined(__nucleus__)
+#elif ! (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 6) && \
+  ! defined(__nucleus__)
   GNAT_STRUCT_STAT statbuf;
 
   if (GNAT_STAT (name, &statbuf) == 0)
@@ -2213,7 +2229,8 @@
   if (__gnat_can_use_acl (wname))
 __gnat_set_OWNER_ACL (wname, GRANT_ACCESS, FILE_GENERIC_EXECUTE);
 
-#elif ! defined (__vxworks) && ! defined(__nucleus__)
+#elif ! (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 6) && \
+  ! defined(__nucleus__)
   GNAT_STRUCT_STAT statbuf;
 
   if (GNAT_STAT (name, &statbuf) == 0)
@@ -2240,7 +2257,8 @@
 
   SetFileAttributes
 (wname, GetFileAttributes (wname) | FILE_ATTRIBUTE_READONLY);
-#elif ! defined (__vxworks) && ! defined(__nucleus__)
+#elif ! (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 6) && \
+  ! defined(__nucleus__)
   GNAT_STRUCT_STAT statbuf;
 
   if (GNAT_STAT (name, &statbuf) == 0)
@@ -2262,7 +2280,8 @@
   if (__gnat_can_use_acl (wname))
 __gnat_set_OWNER_ACL (wname, GRANT_ACCESS, FILE_GENERIC_READ);
 
-#elif ! defined (__vxworks) && ! defined(__nucleus__)
+#elif ! (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 6) && \
+  ! defined(__nucleus__)
   GNAT_STRUCT_STAT statbuf;
 
   if (GNAT_STAT (name, &statbuf) == 0)
@@ -2283,7 +2302,8 @@
   if (__gnat_can_use_acl (wname))
 __gnat_set_OWNER_ACL (wname, DENY_ACCESS, FILE_GENERIC_READ);
 
-#elif ! defined (__vxworks) && ! defined(__nucleus__)
+#elif ! (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 6) && \
+  ! defined(__nucleus__)
   GNAT_STRUCT_STAT statbuf;
 
   if (GNAT_STAT (name, &statbuf) == 0)
@@ -3555,7 +3575,8 @@
 int
 __gnat_copy_attribs (char *from, char *to, int mode)
 {
-#if defined (VMS) || defined (__vxworks) || defined (__nucleus__)
+#if defined (VMS) || (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 6) || \
+  defined (__nucleus__)
   return -1;
 
 #elif defined (_WIN32) && !defined (RTX)
Index: s-os_lib.ads
===
--- s-os_lib.ads(revision 177274)
+++ s-os_lib.ads(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- S p e c  --
 --  --
---  Copyright (C) 1995-2010, Free Software Foundation, Inc. --
+--  Copyright (C) 1995-2011, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -343,7 +343,7 @@
--  effect of "cp -p" on Unix systems, and None corresponds to the typical
--  effect of "cp" on Unix systems.
 
-   --  Note: Time_Stamps and Full are not supported on VMS and VxWorks
+   --  Note: Time_Stamps and Full are not supported on VMS and VxWorks 5
 
procedure Copy_File
  (Name : String;
@@ -371,7 +371,7 @@
--  furthermore Dest must be writable. Success will be set to True if the
--  operation was successful and False otherwise.
--
-   --  Note: this procedure is not supported on VMS and VxWorks. On these
+   --  Note: this procedure is not supported on VMS and VxWorks 5. On these
--  platforms, Success is always set to False.
 
 

[Ada] update gnatmake usage

2011-08-05 Thread Arnaud Charlet
Switches --create-map-file and --create-map-file- are added to
the gnatmake usage. Lines for these switches should be in the output of
gnatmake --help.

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

2011-08-05  Vincent Celier  

* makeusg.adb: Add lines for --create-map-file switches.

Index: makeusg.adb
===
--- makeusg.adb (revision 177274)
+++ makeusg.adb (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2010, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2011, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -249,6 +249,14 @@
Write_Eol;
Write_Eol;
 
+   Write_Str ("  --create-map-file   Create map file mainprog.map");
+   Write_Eol;
+
+   Write_Str ("  --create-map-file=mapfile");
+   Write_Eol;
+   Write_Str ("  Create map file mapfile");
+   Write_Eol;
+
Write_Str ("  --GCC=command   Use this gcc command");
Write_Eol;
 


[s390] [committed]: fix call to store_bit_field()

2011-08-05 Thread Aldy Hernandez

Target could not build due to missing new arguments.

Tested by building cc1.

Committed as obvious.
* config/s390/s390.c (s390_expand_cs_hqi): Add new arguments to
store_bit_field.
(s390_expand_atomic): Same.

Index: config/s390/s390.c
===
--- config/s390/s390.c  (revision 177430)
+++ config/s390/s390.c  (working copy)
@@ -4733,7 +4733,8 @@ s390_expand_cs_hqi (enum machine_mode mo
   if (ac.aligned && MEM_P (cmp))
 {
   cmpv = force_reg (SImode, val);
-  store_bit_field (cmpv, GET_MODE_BITSIZE (mode), 0, SImode, cmp);
+  store_bit_field (cmpv, GET_MODE_BITSIZE (mode), 0,
+  0, 0, SImode, cmp);
 }
   else
 cmpv = force_reg (SImode, expand_simple_binop (SImode, IOR, cmp, val,
@@ -4741,7 +4742,8 @@ s390_expand_cs_hqi (enum machine_mode mo
   if (ac.aligned && MEM_P (new_rtx))
 {
   newv = force_reg (SImode, val);
-  store_bit_field (newv, GET_MODE_BITSIZE (mode), 0, SImode, new_rtx);
+  store_bit_field (newv, GET_MODE_BITSIZE (mode), 0,
+  0, 0, SImode, new_rtx);
 }
   else
 newv = force_reg (SImode, expand_simple_binop (SImode, IOR, new_rtx, val,
@@ -4818,7 +4820,8 @@ s390_expand_atomic (enum machine_mode mo
   /* FALLTHRU */
 case SET:
   if (ac.aligned && MEM_P (val))
-   store_bit_field (new_rtx, GET_MODE_BITSIZE (mode), 0, SImode, val);
+   store_bit_field (new_rtx, GET_MODE_BITSIZE (mode), 0,
+0, 0, SImode, val);
   else
{
  new_rtx = expand_simple_binop (SImode, AND, new_rtx, ac.modemaski,


[Ada] Set special options for ALFA mode (formal verification)

2011-08-05 Thread Arnaud Charlet
In ALFA mode, compiler is working in a special way in which it should believe
it generates actual object code, while it is not; warnings should not be
issued; checks should not be inserted in the code; various pragmas should be
ignored. Changing the startup of frontend to do that.

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

2011-08-05  Yannick Moy  

* debug.adb: Remove use of -gnatd.D.
* gnat1drv.adb (Adjust_Global_Switches): adjust switches for ALFA mode
* opt.ads: Simplify variables for ALFA mode, to keep one only
* restrict.adb, sem_prag.adb: Adapt treatment done for CodePeer mode
to ALFA mode.

Index: debug.adb
===
--- debug.adb   (revision 177351)
+++ debug.adb   (working copy)
@@ -122,8 +122,8 @@
--  d.B
--  d.C  Generate concatenation call, do not generate inline code
--  d.D
-   --  d.E  SPARK generation mode
-   --  d.F  Why generation mode
+   --  d.E
+   --  d.F  ALFA mode
--  d.G
--  d.H
--  d.I  SCIL generation mode
@@ -580,12 +580,10 @@
--  d.C  Generate call to System.Concat_n.Str_Concat_n routines in cases
--   where we would normally generate inline concatenation code.
 
-   --  d.E  SPARK generation mode. Generate intermediate code for the sake of
-   --   formal verification through SPARK and the SPARK toolset.
+   --  d.F  ALFA mode. Generate AST in a form suitable for formal verification,
+   --   as well as additional cross reference information in ALI files to
+   --   compute effects of subprograms.
 
-   --  d.F  Why generation mode. Generate intermediate code for the sake of
-   --   formal verification through Why and the Why VC generator.
-
--  d.I  Generate SCIL mode. Generate intermediate code for the sake of
--   of static analysis tools, and ensure additional tree consistency
--   between different compilations of specs.
Index: sem_prag.adb
===
--- sem_prag.adb(revision 177395)
+++ sem_prag.adb(working copy)
@@ -5059,9 +5059,9 @@
   --  Start of processing for Process_Restrictions_Or_Restriction_Warnings
 
   begin
- --  Ignore all Restrictions pragma in CodePeer mode
+ --  Ignore all Restrictions pragma in CodePeer and ALFA modes
 
- if CodePeer_Mode then
+ if CodePeer_Mode or else ALFA_Mode then
 return;
  end if;
 
@@ -5283,10 +5283,13 @@
   --  Start of processing for Process_Suppress_Unsuppress
 
   begin
- --  Ignore pragma Suppress/Unsuppress in codepeer mode on user code:
- --  we want to generate checks for analysis purposes, as set by -gnatC
+ --  Ignore pragma Suppress/Unsuppress in CodePeer and ALFA modes on
+ --  user code: we want to generate checks for analysis purposes, as
+ --  set respectively by -gnatC and -gnatd.F
 
- if CodePeer_Mode and then Comes_From_Source (N) then
+ if (CodePeer_Mode or else ALFA_Mode)
+   and then Comes_From_Source (N)
+ then
 return;
  end if;
 
@@ -9444,11 +9447,12 @@
 Check_Valid_Configuration_Pragma;
 Check_Restriction (No_Initialize_Scalars, N);
 
---  Initialize_Scalars creates false positives in CodePeer,
---  so ignore this pragma in this mode.
+--  Initialize_Scalars creates false positives in CodePeer, and
+--  incorrect negative results in ALFA mode, so ignore this pragma
+--  in these modes.
 
 if not Restriction_Active (No_Initialize_Scalars)
-  and then not CodePeer_Mode
+  and then not (CodePeer_Mode or else ALFA_Mode)
 then
Init_Or_Norm_Scalars := True;
Initialize_Scalars := True;
@@ -9475,10 +9479,10 @@
  when Pragma_Inline_Always =>
 GNAT_Pragma;
 
---  Pragma always active unless in CodePeer mode, since this causes
---  walk order issues.
+--  Pragma always active unless in CodePeer or ALFA mode, since
+--  this causes walk order issues.
 
-if not CodePeer_Mode then
+if not (CodePeer_Mode or else ALFA_Mode) then
Process_Inline (True);
 end if;
 
@@ -10917,10 +10921,11 @@
 Check_Arg_Count (0);
 Check_Valid_Configuration_Pragma;
 
---  Normalize_Scalars creates false positives in CodePeer, so
---  ignore this pragma in this mode.
+--  Normalize_Scalars creates false positives in CodePeer, and
+--  incorrect negative results in ALFA mode, so ignore this pragma
+--  in these modes.
 
-if not CodePeer_Mode then
+if not (CodePeer_Mode or else ALFA_Mode) then
Normalize_Scalars := True;
I

Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-05 Thread Paolo Bonzini

On 08/05/2011 01:46 PM, Rainer Orth wrote:

>>  How should we proceed with this patch, especially given the quite
>>  moderate comments from most affected target maintainers?

>
>  ARM is the only target we should care a bit about.  Any chance you can try
>  cross-compiling it (with a combined tree it should not be hard)? Just to
>  see that it builds.

I've tried to setup crosstool-NG in the past, but failed and haven't
gotten around to debugging this yet.  I still mean to, especially given
that I need to investigate testsuite issues in a cross environment.

Nick already ok'ed the arm (and frv) parts, so we should be ok for now.


Ok then.

Paolo


[Ada] Inherited subprograms may be both abstract and need overriding

2011-08-05 Thread Arnaud Charlet
AI05-0028 indicates that an inherited operation can be abstract, even if it
is overridden in a currently non-visible private part, and also require
overriding when the derived type is non-abstract. GNAT has always iplemented
this properly. This patch improves on the error message when this error is
encountered, by indicating that the overriding subprogram is not visible and
therefore not inherited.

Compiling r.ads below in Ada2005 mode must yield:

   r.ads:3:09: type must be declared abstract or "Op" overridden
   r.ads:3:09: "Op" has been inherited at line 3
   r.ads:3:09: "Op" has been inherited at q.ads:3
   r.ads:3:09: "Op" subprogram at q.ads:7 is not visible

package P is
   type I is interface;
   procedure Op (X : I) is abstract;
end P;
---
with P;
package Q is
   type T is abstract new P.I with private;
   -- Op inherited here.
private
   type T is new P.I with null record;
   procedure Op (X : T) is null;
end Q;
---
with Q;
package R is
   type T2 is new Q.T with null record;
   -- Legal? (No.) 
end R;

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

2011-08-05  Ed Schonberg  

* sem_ch3.adb: (Check_Private_Overriding): better error message,
suggested by AI95-0068.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 177431)
+++ sem_ch3.adb (working copy)
@@ -9118,9 +9118,21 @@
end loop;
 
Error_Msg_Sloc := Sloc (E);
-   Error_Msg_NE
- ("\& has been inherited from subprogram #",
+
+   --  AI05-0068: report if there is an overriding
+   --  non-abstract subprogram that is invisible.
+   if Is_Hidden (E)
+ and then not Is_Abstract_Subprogram (E)
+   then
+  Error_Msg_NE
+ ("\& subprogram# is not visible",
   T, Subp);
+
+   else
+  Error_Msg_NE
+("\& has been inherited from subprogram #",
+ T, Subp);
+   end if;
 end;
  end if;
   end if;


[Ada] Expansion of Ada2012 predicate checks for type conversions

2011-08-05 Thread Arnaud Charlet
This patch fixes an infinite recursion in the application of predicate checks
to type conversions.

The following must compile quietly:

gcc -c -gnat12 ./why-conversions.ads

---
with Why.Ids; use Why.Ids;
package Why.Conversions is

   function "+"
 (Id : W_Unused_At_Start_OId)
 return W_Unused_At_Start_Valid_OId;
private

   function "+"
 (Id : W_Unused_At_Start_OId)
 return W_Unused_At_Start_Valid_OId is
 (W_Unused_At_Start_Valid_OId (Id));
end Why.Conversions;
---
package Why is
   pragma Pure;
end Why;
---
with Why.Unchecked_Ids; use Why.Unchecked_Ids;
package Why.Ids is

   subtype W_Unused_At_Start_Valid_OId is
 W_Unused_At_Start_Unchecked_OId;

   type W_Unused_At_Start_OId is new
 W_Unused_At_Start_Valid_OId;
end Why.Ids;
---
with Why.Opaque_Ids;   use Why.Opaque_Ids;
package Why.Kind_Validity is
   --  Kind-validity checks

   function Unused_At_Start_OId_Kind_Valid
 (Id : W_Unused_At_Start_Opaque_OId)
 return Boolean;

private

   function Unused_At_Start_OId_Kind_Valid
 (Id : W_Unused_At_Start_Opaque_OId)
 return Boolean is
 (Id /= 0);
end Why.Kind_Validity;
---
package Why.Opaque_Ids is
   subtype W_Unused_At_Start_Opaque_OId is Integer;
end Why.Opaque_Ids;
---
with Why.Opaque_Ids;use Why.Opaque_Ids;
with Why.Kind_Validity; use Why.Kind_Validity;
package Why.Unchecked_Ids is
   subtype W_Unused_At_Start_Unchecked_OId is
 W_Unused_At_Start_Opaque_OId  with
Predicate =>
  (Unused_At_Start_OId_Kind_Valid
   (W_Unused_At_Start_Unchecked_OId));
end Why.Unchecked_Ids;

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

2011-08-05  Ed Schonberg  

* exp_ch4.adb (Expand_N_Type_Conversion): When expanding a predicate
check, indicate that the copy of the original node does not come from
source, to prevent an infinite recursion of the expansion.

Index: exp_ch4.adb
===
--- exp_ch4.adb (revision 177431)
+++ exp_ch4.adb (working copy)
@@ -9154,8 +9154,16 @@
 and then Target_Type /= Operand_Type
 and then Comes_From_Source (N)
   then
- Insert_Action (N,
-   Make_Predicate_Check (Target_Type, Duplicate_Subexpr (N)));
+ declare
+New_Expr : constant Node_Id := Duplicate_Subexpr (N);
+
+ begin
+--  Avoid infinite recursion on the subsequent expansion of
+--  of the copy of the original type conversion.
+
+Set_Comes_From_Source (New_Expr, False);
+Insert_Action (N, Make_Predicate_Check (Target_Type, New_Expr));
+ end;
   end if;
end Expand_N_Type_Conversion;
 


[Ada] Visibility error in formal package with no associations

2011-08-05 Thread Arnaud Charlet
This patch fixes a visbility error involving the use the name of a generic
package GP as a selector for a formal package that is an instantiation of GP.

Compiling p-child.adb below must yield:

   p-child.ads:9:43: "P1" is not a visible entity of "Tested"

package body P.Child is
   package body P1 is

  package body P2 is

 procedure Proc_2 is
 begin
null;
 end Proc_2;

  end P2;

   end P1;
end P.Child;
---
package P.Child is

   generic
  with package Tested is new P.P1 (<>);
   package P1 is

  generic
--   with package Tested is new Tested.P2 (<>);
 with package Tested is new Tested.P1.P2 (<>);
  package P2 is

 procedure Proc_2;
  end P2;
   end P1;
end P.Child;
---
package P is
   generic
   package P1 is

  generic
  package P2 is

 procedure Proc;

  end P2;
   end P1;

end P;

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

2011-08-05  Ed Schonberg  

* sem_ch12.adb (Analyze_Formal_Package_Declaration): in an
instantiation and a formal package the compiler generates a package
renaming declaration so that the generic name within the declaration
is interpreted as a renaming of the instance. At the end of a formal
package declaration, this renaming must become invisible.

Index: sem_ch12.adb
===
--- sem_ch12.adb(revision 177431)
+++ sem_ch12.adb(working copy)
@@ -2015,7 +2015,7 @@
   Renaming : Node_Id;
   Parent_Instance  : Entity_Id;
   Renaming_In_Par  : Entity_Id;
-  No_Associations  : Boolean := False;
+  Associations : Boolean := True;
 
   function Build_Local_Package return Node_Id;
   --  The formal package is rewritten so that its parameters are replaced
@@ -2186,7 +2186,7 @@
 or else No (Generic_Associations (N))
 or else Nkind (First (Generic_Associations (N))) = N_Others_Choice
   then
- No_Associations := True;
+ Associations := False;
   end if;
 
   --  If there are no generic associations, the generic parameters appear
@@ -2266,26 +2266,33 @@
   --  The formals for which associations are provided are not visible
   --  outside of the formal package. The others are still declared by a
   --  formal parameter declaration.
+  --  If there are no associations, the only local entity to hide is the
+  --  generated package renaming itself.
 
-  if not No_Associations then
- declare
-E : Entity_Id;
+  declare
+ E : Entity_Id;
 
- begin
-E := First_Entity (Formal);
-while Present (E) loop
-   exit when Ekind (E) = E_Package
- and then Renamed_Entity (E) = Formal;
+  begin
+ E := First_Entity (Formal);
+ while Present (E) loop
 
-   if not Is_Generic_Formal (E) then
-  Set_Is_Hidden (E);
-   end if;
+if Associations
+  and then not Is_Generic_Formal (E)
+then
+   Set_Is_Hidden (E);
+end if;
 
-   Next_Entity (E);
-end loop;
- end;
-  end if;
+if Ekind (E) = E_Package
+  and then Renamed_Entity (E) = Formal
+then
+   Set_Is_Hidden (E);
+   exit;
+end if;
 
+Next_Entity (E);
+ end loop;
+  end;
+
   End_Package_Scope (Formal);
 
   if Parent_Installed then


[Ada] Missing visibility check in formal packages

2011-08-05 Thread Arnaud Charlet
The compiler failed to reject a formal package whose name is the same as that
of the generic unit, or its ultimate prefix.

Compiling p-child2.ads must yield:

p-child2.ads:7:43: "Tested" is hidden within declaration of formal package

package P.Child2 is
   generic
  with package Tested is new P.P1 (<>);
   package P1 is

  generic
 with package Tested is new Tested.P2 (<>);
  package P2 is
 procedure Proc_2;
  end P2;
   end P1;
end P.Child2;
---
package P is
   generic
   package P1 is

  generic
  package P2 is
 procedure Proc;
  end P2;
   end P1;
end P;

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

2011-08-05  Ed Schonberg  

* sem_ch12.adb (Analyze_Formal_Package_Declaration): reject a formal
package whose name is the same as that of the generic unit, or its
ultimate prefix.

Index: sem_ch12.adb
===
--- sem_ch12.adb(revision 177437)
+++ sem_ch12.adb(working copy)
@@ -2124,7 +2124,7 @@
  return Pack_Decl;
   end Build_Local_Package;
 
-   --  Start of processing for Analyze_Formal_Package
+   --  Start of processing for Analyze_Formal_Package_Declaration
 
begin
   Text_IO_Kludge (Gen_Id);
@@ -2182,6 +2182,25 @@
  end if;
   end if;
 
+  --  Check that name of formal package does not hide name of generic,
+  --  or its leading prefix. This check must be done separately because
+  --  the name of the generic has already been analyzed.
+
+  declare
+ Gen_Name : Entity_Id;
+
+  begin
+ Gen_Name := Gen_Id;
+ while Nkind (Gen_Name) = N_Expanded_Name loop
+Gen_Name := Prefix (Gen_Name);
+ end loop;
+ if Chars (Gen_Name) = Chars (Pack_Id) then
+Error_Msg_NE
+ ("& is hidden within declaration of formal package",
+   Gen_Id, Gen_Name);
+ end if;
+  end;
+
   if Box_Present (N)
 or else No (Generic_Associations (N))
 or else Nkind (First (Generic_Associations (N))) = N_Others_Choice


Re: PR ada/49944, take 2 [4.5/4.6/4.7 regression] Bootstrapping on x86_64-pc-kfreebsd-gnu fails with "s-taprop.adb:856:10: "pthread_attr_setaffinity_np" is undefined (more references follow)"

2011-08-05 Thread Ludovic Brenta
Arnaud Charlet writes:
>> ---  This is the GNU/kFreeBSD (GNU/LinuxThreads) version of this package
>> +--  This is the GNU/kFreeBSD PTHREADS version of this package
>
> Not sure why PTHREADS is upper cased here, any specific reason?

Because that's how it was written in s-osint-freebsd.ads, that's all.

> If not, I'd lower case it. Actually I'd probably replace it by:

> --  This is the GNU/kFreeBSD (POSIX Threads) version of this package
>
> unless "PTHREADS" has a special meaning on kFreeBSD.

Not that I know.  I made the change you suggested in both files.

> OK with the above changes.

Thanks for your comments.

2011-08-05  Ludovic Brenta 

PR ada/49944
* s-osinte-freebsd.ads: Update copyright years. Minor reformatting.
(Stack_Base_Available): Correct comments.
* s-osinte-kfreebsd-gnu.ads (Time_Slice_Supported, nanosleep,
clock_id_t, clock_gettime, Stack_Base_Available, Get_Page_Size,
mprotect, pthread_mutexattr_setprotocol, pthread_mutexattr_getprotocol,
pthread_mutexattr_setprioceiling, pthread_mutexattr_getprioceiling,
pthread_attr_setscope, pthread_attr_getscope,
pthread_attr_setinheritsched, pthread_attr_getinheritsched,
Time_Slice_Supported): Copy from s-osinte-freebsd.ads.


Index: b/src/gcc/ada/s-osinte-kfreebsd-gnu.ads
===
--- a/src/gcc/ada/s-osinte-kfreebsd-gnu.ads
+++ b/src/gcc/ada/s-osinte-kfreebsd-gnu.ads
@@ -7,7 +7,7 @@
 --  S p e c --
 --  --
 -- Copyright (C) 1991-1994, Florida State University--
--- Copyright (C) 1995-2005,2008 Free Software Foundation, Inc.  --
+--  Copyright (C) 1995-2011, Free Software Foundation, Inc. --
 --  --
 -- GNARL is free software; you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -32,7 +32,7 @@
 --  --
 --
 
---  This is the GNU/kFreeBSD (GNU/LinuxThreads) version of this package
+--  This is the GNU/kFreeBSD (POSIX Threads) version of this package
 
 --  This package encapsulates all direct interfaces to OS services
 --  that are needed by children of System.
@@ -200,8 +200,24 @@
-- Time --
--
 
+   Time_Slice_Supported : constant Boolean := True;
+   --  Indicates whether time slicing is supported (i.e SCHED_RR is supported)
+
type timespec is private;
 
+   function nanosleep (rqtp, rmtp : access timespec) return int;
+   pragma Import (C, nanosleep, "nanosleep");
+
+   type clockid_t is private;
+
+   CLOCK_REALTIME : constant clockid_t;
+
+   function clock_gettime
+ (clock_id : clockid_t;
+  tp   : access timespec)
+  return int;
+   pragma Import (C, clock_gettime, "clock_gettime");
+
function To_Duration (TS : timespec) return Duration;
pragma Inline (To_Duration);
 
@@ -273,6 +289,10 @@
type pthread_key_t   is private;
 
PTHREAD_CREATE_DETACHED : constant := 1;
+   PTHREAD_CREATE_JOINABLE : constant := 0;
+
+   PTHREAD_SCOPE_PROCESS : constant := 0;
+   PTHREAD_SCOPE_SYSTEM  : constant := 2;
 
---
-- Stack --
@@ -296,9 +316,29 @@
Alternate_Stack_Size : constant := 0;
--  No alternate signal stack is used on this platform
 
+   Stack_Base_Available : constant Boolean := False;
+   --  Indicates whether the stack base is available on this target
+
function Get_Stack_Base (thread : pthread_t) return Address;
pragma Inline (Get_Stack_Base);
-   --  This is a dummy procedure to share some GNULLI files
+   --  returns the stack base of the specified thread. Only call this function
+   --  when Stack_Base_Available is True.
+
+   function Get_Page_Size return size_t;
+   function Get_Page_Size return Address;
+   pragma Import (C, Get_Page_Size, "getpagesize");
+   --  Returns the size of a page
+
+   PROT_NONE  : constant := 0;
+   PROT_READ  : constant := 1;
+   PROT_WRITE : constant := 2;
+   PROT_EXEC  : constant := 4;
+   PROT_ALL   : constant := PROT_READ + PROT_WRITE + PROT_EXEC;
+   PROT_ON: constant := PROT_NONE;
+   PROT_OFF   : constant := PROT_ALL;
+
+   function mprotect (addr : Address; len : size_t; prot : int) return int;
+   pragma Import (C, mprotect);
 
---
-- Nonstandard Thread Initialization --
@@ -387,6 +427,36 @@
-- POSIX.1c  Section 13 --
--
 
+   PTHREAD_PRIO_NONE: constant := 0;
+   PTHREAD_PRIO_PROTECT : constant := 2;
+   PTHREAD_PRIO_INHERIT : constant := 1;
+
+   function pthread_mutexattr_setprotocol
+ (attr : access pthre

Re: PR ada/49944, take 2 [4.5/4.6/4.7 regression] Bootstrapping on x86_64-pc-kfreebsd-gnu fails with "s-taprop.adb:856:10: "pthread_attr_setaffinity_np" is undefined (more references follow)"

2011-08-05 Thread Arnaud Charlet
> >> ---  This is the GNU/kFreeBSD (GNU/LinuxThreads) version of this
> >> package
> >> +--  This is the GNU/kFreeBSD PTHREADS version of this package
> >
> > Not sure why PTHREADS is upper cased here, any specific reason?
> 
> Because that's how it was written in s-osint-freebsd.ads, that's all.

Yes well, programming by copy/pasting isn't always a good idea :-)

In particular, the freebsd version isn't well maintained, so I wouldn't
take it as an example/reference.

Arno


[Ada] Implementation of AI05-0212 : implicit dereference types

2011-08-05 Thread Arnaud Charlet
Ada2012 introduces the notion of a reference type, to generalize the use of
cursors in containers. A reference type is a type with an access discriminant,
with the semantics that a reference to an object of the type is in fact a
reference to the object denoted by the access discriminant.
The following must compile and execute quietly in Ada2012 mode:

with Deref; use Deref;
procedure Test_Deref is
   C : Cursor := Index (5);
   V : Integer := Index (5);
   Fifteen : Float := Index (1234);

   Obj : Wrapper;

  C1 : Cursor := Obj.Ptr;
  V2 : Integer := Obj.Ptr;
begin
   if Value /= 1234 
 or else Value2 /= 1234
 or else V /= 1234
 or else V2 /= 1234
   then
  raise Program_Error;
   end if;
end;
---
package deref is
   type Cursor (E : access Integer) is tagged null record
   with  Implicit_Dereference => E;

   function Index (N : Integer) return Cursor;
   function Index (N : Integer) return Float;
   Thing : Cursor := (E => New Integer'(1234));
   Value : aliased Integer := Thing;

   type Wrapper is record
  Ptr : Cursor (Value'access);
   end record;

   type Table is array (1..10) of Cursor (Value'access);
   It : Table;
   Value2 : Integer :=  It (5);
end;
--

The following compilation:

   gcc -c -gnat12 -gnatf ambig_deref.ads

must yield the following errors:

   ambig_deref.ads:12:23: can be interpreted as implicit dereference
   ambig_deref.ads:12:30: ambiguous operands for equality
   ambig_deref.ads:12:32: can be interpreted as implicit dereference

---
package ambig_deref is
   type Cursor (E : access Integer) is tagged null record
   with  Implicit_Dereference => E;

   Thing : Cursor := (E => New Integer'(1234));
   Value : aliased Integer := Thing;

   type Table is array (1..10) of Cursor (Value'access);
   It : Table;
   Value2 : Integer :=  It (5);

   Maybe : Boolean := It (4) = It (5);
end;

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

2011-08-05  Ed Schonberg  

* sem_util.adb, sem_util.ads (Check_Implicit_Dereference): If a
possible interpretation of name is a reference type, add an
interpretation that is the designated type of the reference
discriminant of that type.
* sem_res.adb (resolve): If the interpretation imposed by context is an
implicit dereference, rewrite the node as the deference of the
reference discriminant.
* sem_ch3.adb (Analyze_Subtype_Declaration, Build_Derived_Record_Type,
Build_Discriminated_Subtype): Inherit Has_Implicit_Dereference from
parent type or base type.
* sem_ch4.adb (Process_Indexed_Component,
Process_Overloaded_Indexed_Component, Indicate_Name_And_Type,
Analyze_Overloaded_Selected_Component, Analyze_Selected_Component):
Check for implicit dereference.
(List_Operand_Interps): Indicate when an implicit dereference is
ambiguous.
* sem_ch8.adb (Find_Direct_Name): Check for implicit dereference.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 177441)
+++ sem_ch3.adb (working copy)
@@ -4215,6 +4215,8 @@
Set_Has_Discriminants(Id, Has_Discriminants  (T));
Set_Is_Constrained   (Id, Is_Constrained (T));
Set_Is_Limited_Record(Id, Is_Limited_Record  (T));
+   Set_Has_Implicit_Dereference
+(Id, Has_Implicit_Dereference (T));
Set_Has_Unknown_Discriminants
 (Id, Has_Unknown_Discriminants (T));
 
@@ -4248,6 +4250,8 @@
Set_Last_Entity(Id, Last_Entity   (T));
Set_Private_Dependents (Id, New_Elmt_List);
Set_Is_Limited_Record  (Id, Is_Limited_Record (T));
+   Set_Has_Implicit_Dereference
+(Id, Has_Implicit_Dereference (T));
Set_Has_Unknown_Discriminants
   (Id, Has_Unknown_Discriminants (T));
Set_Known_To_Have_Preelab_Init
@@ -7875,6 +7879,8 @@
 Set_Stored_Constraint
   (Derived_Type, Expand_To_Stored_Constraint (Parent_Type, Discs));
 Replace_Components (Derived_Type, New_Decl);
+Set_Has_Implicit_Dereference
+  (Derived_Type, Has_Implicit_Dereference (Parent_Type));
  end if;
 
  --  Insert the new derived type declaration
@@ -8586,6 +8592,8 @@
 
   Set_First_Entity  (Def_Id, First_Entity   (T));
   Set_Last_Entity   (Def_Id, Last_Entity(T));
+  Set_Has_Implicit_Dereference
+(Def_Id, Has_Implicit_Dereference (T));
 
   --  If the subtype is the completion of a private declaration, there may
   --  have been representation clauses for the partial view, and they must
Index: sem_util.adb
===
--- se

[Ada] SCO generation for pragma Debug

2011-08-05 Thread Arnaud Charlet
This change improves the SCO generation circuitry for pragma Debug.
Specific support is added for dyadic pragma Debug (where the first argument
is now treated as a P decision). SCO generation is suppressed altogether
for any pragma Debug, or decision nested therein, if the pragma is not
enabled.

The below unit must produce the indicated SCOs:

$ gcc -c -gnateS pragma_debug_scos.adb
CS 8:4-8:4

$ gcc -c -gnata -gnateS pragma_debug_scos.adb
CS P4:4-4:28 P5:4-5:65 P6:4-6:31 P7:4-7:74 8:4-8:4
CX &5:56 c5:54-5:54 c5:65-5:65
CP 6:4 c6:18-6:18
CP 7:4 c7:18-7:18
CX |7:66 c7:64-7:64 c7:74-7:74

with Ada.Text_IO; use Ada.Text_IO;
procedure Pragma_Debug_SCOs (A, B : Boolean) is
begin
   pragma Debug (Put_Line ("foo"));
   pragma Debug (Put_Line ("A&&B: " & Boolean'Image (A and then B)));
   pragma Debug (A, Put_Line ("A is True"));
   pragma Debug (B, Put_Line ("B True, A||B:" & Boolean'Image (A or else B)));
   null;
end Pragma_Debug_SCOs;

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

2011-08-05  Thomas Quinot  

* scos.ads: Update documentation of SCO table. Pragma statements can now
be marked as disabled (using 'p' instead of 'P' as the statement kind).
* par_sco.ads, par_sco.adb: Implement the above change.
(Process_Decisions_Defer): Generate a P decision for the first parameter
of a dyadic pragma Debug.
* sem_prag.adb (Analyze_Pragma, case Debug): Mark pragma as enabled if
necessary.
* put_scos.adb: Code simplification based on above change.

Index: par_sco.adb
===
--- par_sco.adb (revision 177431)
+++ par_sco.adb (working copy)
@@ -69,9 +69,9 @@
 
--  We need to be able to get to conditions quickly for handling the calls
--  to Set_SCO_Condition efficiently, and similarly to get to pragmas to
-   --  handle calls to Set_SCO_Pragma_Enabled. For this purpose we identify the
-   --  conditions and pragmas in the table by their starting sloc, and use this
-   --  hash table to map from these starting sloc values to SCO_Table indexes.
+   --  handle calls to Set_SCO_Pragma_Enabled. For this purpose we identify
+   --  the conditions and pragmas in the table by their starting sloc, and use
+   --  this hash table to map from these sloc values to SCO_Table indexes.
 
type Header_Num is new Integer range 0 .. 996;
--  Type for hash table headers
@@ -101,7 +101,10 @@
--  excluding OR and AND) and returns True if so, False otherwise, it does
--  no other processing.
 
-   procedure Process_Decisions (N : Node_Id; T : Character);
+   procedure Process_Decisions
+ (N   : Node_Id;
+  T   : Character;
+  Pragma_Sloc : Source_Ptr);
--  If N is Empty, has no effect. Otherwise scans the tree for the node N,
--  to output any decisions it contains. T is one of IEGPWX (for context of
--  expression: if/exit when/entry guard/pragma/while/expression). If T is
@@ -109,7 +112,10 @@
--  decision is always present (at the very least a simple decision is
--  present at the top level).
 
-   procedure Process_Decisions (L : List_Id; T : Character);
+   procedure Process_Decisions
+ (L   : List_Id;
+  T   : Character;
+  Pragma_Sloc : Source_Ptr);
--  Calls above procedure for each element of the list L
 
procedure Set_Table_Entry
@@ -316,13 +322,17 @@
 
--  Version taking a list
 
-   procedure Process_Decisions (L : List_Id; T : Character) is
+   procedure Process_Decisions
+ (L   : List_Id;
+  T   : Character;
+  Pragma_Sloc : Source_Ptr)
+   is
   N : Node_Id;
begin
   if L /= No_List then
  N := First (L);
  while Present (N) loop
-Process_Decisions (N, T);
+Process_Decisions (N, T, Pragma_Sloc);
 Next (N);
  end loop;
   end if;
@@ -330,11 +340,14 @@
 
--  Version taking a node
 
-   Pragma_Sloc : Source_Ptr := No_Location;
-   --  While processing decisions within a pragma Assert/Debug/PPC, this is set
-   --  to the sloc of the pragma.
+   Current_Pragma_Sloc : Source_Ptr := No_Location;
+   --  While processing a pragma, this is set to the sloc of the N_Pragma node
 
-   procedure Process_Decisions (N : Node_Id; T : Character) is
+   procedure Process_Decisions
+ (N   : Node_Id;
+  T   : Character;
+  Pragma_Sloc : Source_Ptr)
+   is
   Mark : Nat;
   --  This is used to mark the location of a decision sequence in the SCO
   --  table. We use it for backing out a simple decision in an expression
@@ -466,14 +479,6 @@
 
Loc := Sloc (Parent (Parent (N)));
 
-   if T = 'P' then
-
-  --  Record sloc of pragma (pragmas don't nest)
-
-  pragma Assert (Pragma_Sloc = No_Location);
-  Pragma_Sloc := Loc;
-   end if;
-
 when 'X' =>
 
--  F

[Ada] Equality testing against null in an instance

2011-08-05 Thread Arnaud Charlet
This patch fixes a view conflict in an instance, when an equality check against
null involves an operand whose type is private and whose full view is a specific
access type.

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

2011-08-05  Ed Schonberg  

* sem_type.adb (Specific_Type): in an instance, the type-specific
operand of an equality check that involves null may have a private
type. Use full view to determine legality of construct.

Index: sem_type.adb
===
--- sem_type.adb(revision 177433)
+++ sem_type.adb(working copy)
@@ -3198,6 +3198,17 @@
   then
  return T1;
 
+  --  In an instance, the specific type may have a private view. Use full
+  --  view to check legality.
+
+  elsif T2 = Any_Access
+and then Is_Private_Type (T1)
+and then Present (Full_View (T1))
+and then Is_Access_Type (Full_View (T1))
+and then In_Instance
+  then
+ return T1;
+
   elsif T2 = Any_Composite
 and then Is_Aggregate_Type (T1)
   then


[Ada] Generalized indexing in Ada2012

2011-08-05 Thread Arnaud Charlet
Ada2012 introduces a general indexing mechanism, using implicit dereference
and new aspects Constant_Indexing and Variable_Indexing.

The following must compile and execute quietly in Ada_2012 mode:

with Index1; use Index1;
procedure Test_Index1 is
   Obj : Container (15) := (15, T => (others => -999));
begin
   if Obj (10) /= -999 then
  raise Program_Error;
   end if;
   Obj (5) := 1;
end;
---   
package Index1 is
   type Table is Array (integer range <>) of Integer;

   type Container (D : Integer)  is tagged record
  T : Table (1 .. D);
   end record
   with Variable_Indexing => Retrieve;

   type Cursor  (Value : access constant Integer) is null record
with Implicit_Dereference => Value;

   function Retrieve (From : Container; Using : Integer) return Cursor;
   function Retrieve (From : Container; Using : Float) return Cursor;
end Index1;
---
package body Index1 is

   function Retrieve (From : Container; Using : Integer) return Cursor is
   begin
  return Cursor'(Value => new Integer'(From.T (Using)));
   end;

   function Retrieve (From : Container; Using : Float) return Cursor is
   begin
  return Cursor'(Value => new Integer'(From.T (Integer (Using;
   end;
end Index1;

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

2011-08-05  Ed Schonberg  

* sem_ch4.adb (Try_Container_Indexing): New procedure to implement the
general indexing aspects of Ada2012. Called when analyzing indexed
components when other interpretations fail.
* sem_ch8.adb (Find_Direct_Name): check for implicit dereference only
in an expression context where overloading is meaningful. This excludes
the occurrence in an aspect specification (efficiency only).
* sem_attr.adb (Analyze_Attribute): indicate that the attributes
related to iterators can be set by an attribute specification, but
cannot be queried.
* sem_ch13.adb (Analyze_Aspect_Specifications): handle
Constant_Indexing and Variable_Indexing.
(Check_Indexing_Functions): New procedure to perform legality checks.
Additional semantic checks at end of declarations.

Index: sem_attr.adb
===
--- sem_attr.adb(revision 177441)
+++ sem_attr.adb(working copy)
@@ -2110,13 +2110,15 @@
 
   case Attr_Id is
 
- --  Attributes related to Ada2012 iterators (placeholder ???)
+ --  Attributes related to Ada2012 iterators. Attribute specifications
+ --  exist for these, but they cannot be queried.
 
- when Attribute_Constant_Indexing=> null;
- when Attribute_Default_Iterator => null;
- when Attribute_Implicit_Dereference => null;
- when Attribute_Iterator_Element => null;
- when Attribute_Variable_Indexing=> null;
+ when Attribute_Constant_Indexing|
+  Attribute_Default_Iterator |
+  Attribute_Implicit_Dereference |
+  Attribute_Iterator_Element |
+  Attribute_Variable_Indexing=>
+Error_Msg_N ("illegal attribute", N);
 
   --
   -- Abort_Signal --
Index: sem_ch4.adb
===
--- sem_ch4.adb (revision 177442)
+++ sem_ch4.adb (working copy)
@@ -23,6 +23,7 @@
 --  --
 --
 
+with Aspects;  use Aspects;
 with Atree;use Atree;
 with Debug;use Debug;
 with Einfo;use Einfo;
@@ -248,6 +249,12 @@
--  Ada 2005: implementation of AI-310. An abstract non-dispatching
--  operation is not a candidate interpretation.
 
+   function Try_Container_Indexing
+ (N  : Node_Id;
+  Prefix : Node_Id;
+  Expr   : Node_Id) return Boolean;
+   --  AI05-0139: Generalized indexing to support iterators over containers
+
function Try_Indexed_Call
  (N  : Node_Id;
   Nam: Entity_Id;
@@ -2032,6 +2039,9 @@
 then
return;
 
+elsif Try_Container_Indexing (N, P, Exp) then
+   return;
+
 elsif Array_Type = Any_Type then
Set_Etype (N, Any_Type);
 
@@ -6270,6 +6280,130 @@
   end if;
end Remove_Abstract_Operations;
 
+   
+   -- Try_Container_Indexing --
+   
+
+   function Try_Container_Indexing
+ (N  : Node_Id;
+  Prefix : Node_Id;
+  Expr   : Node_Id) return Boolean
+   is
+  Loc   : constant Source_Ptr := Sloc (N);
+  Disc  : Entity_Id;
+  Func  : Entity_Id;
+  Func_Name : Node_Id;
+  Indexing  : Node_Id;
+  Is_Var: Boolean;
+  Ritem : Node_Id;
+
+   begin
+
+  --  Check whether type has a specified indexing aspect.
+
+  Func_Name := Empty;
+  Is_Var := 

Re: [Patch, Fortran] (Coarray) Fix constraint checks for LOCK_TYPE

2011-08-05 Thread Mikael Morin
OK, I played a bit myself to see what the "right way" would look like, and I 
came up with the attached patch, which is complicated, and not even correct. 
And indeed, it plays with allocatable and pointer stuff.
So your approach makes some sense now.

I do here some propositions for comment and error messages which IMO explain 
better where the problem lies (Iff I have understood the problem correctly). 
They are quite verbose however, and possibly not correct english (many 
negations). 
One could consider separating the "is LOCK_TYPE type" and "type has type 
LOCK_TYPE components" cases to make the diagnostic easier to read, but that 
would make the code even more complex.
Anyway comments and propositions welcome. 

review, 2nd try:
> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> index 2910ab5..9f732e5 100644
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -2148,15 +2157,61 @@ endType:
>  
>/* Looking for coarray components.  */
>if (c->attr.codimension
> -   || (c->attr.coarray_comp && !c->attr.pointer && !c->attr.allocatable))
> - sym->attr.coarray_comp = 1;
> +   || (c->ts.type == BT_CLASS && c->attr.class_ok
> +   && CLASS_DATA (c)->attr.codimension))
> + {
> +   coarray = true;
> +   sym->attr.coarray_comp = 1;
> + }
> + 
> +  if (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.codimension)
- Err, is the codimension attribute on the derived type?
Or did you mean [...] && c->ts.u.derived->attr.coarray_comp (to match the code 
removed)?
> + {
> +   coarray = true;
> +   if (!pointer && !allocatable)
> + sym->attr.coarray_comp = 1;
> + }
>  
>/* Looking for lock_type components.  */
> -  if (c->attr.lock_comp
> -   || (sym->ts.type == BT_DERIVED
> +  if ((c->ts.type == BT_DERIVED
> && c->ts.u.derived->from_intmod == INTMOD_ISO_FORTRAN_ENV
> -   && c->ts.u.derived->intmod_sym_id == ISOFORTRAN_LOCK_TYPE))
> - sym->attr.lock_comp = 1;
> +   && c->ts.u.derived->intmod_sym_id == ISOFORTRAN_LOCK_TYPE)
> +   || (c->ts.type == BT_CLASS && c->attr.class_ok
> +   && CLASS_DATA (c)->ts.u.derived->from_intmod
> +  == INTMOD_ISO_FORTRAN_ENV
> +   && CLASS_DATA (c)->ts.u.derived->intmod_sym_id
> +  == ISOFORTRAN_LOCK_TYPE)
> +   || (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.lock_comp
> +   && !allocatable && !pointer))
> + {
> +   lock_type = 1;
> +   lock_comp = c;
> +   sym->attr.lock_comp = 1;
> + }
> +
> +  /* F2008, C1302.  */
> +
Additional comment:
/* 5.3.14: An entity with the pointer attribute shall not be a coarray.
   2.4.7: A subobject of a coarray is a coarray if it doesn't have any pointer
   component selection.  */
> +  if (pointer && !coarray && (lock_type
> +   || (c->ts.type == BT_DERIVED
> +   && c->ts.u.derived->attr.lock_comp)))
> + gfc_error ("Component %s at %L of type LOCK_TYPE or with subcomponent "
> +"of type LOCK_TYPE is a pointer but not a coarray",
> +c->name, &c->loc);
"Component %s at %L can be neither a coarray as it is a pointer, nor a non-
coarray as it would be a non-coarray of type LOCK_TYPE or would have a non-
coarray subcomponent of type LOCK_TYPE", c->name, &c->loc

> +
/* 2.4.7: A subobject of a coarray is a coarray if it doesn't have any
   allocatable component selection. 
   Thus, an allocatable component has to be a coarray for its subcomponents to
   be coarrays.  */
> +  if (lock_type && allocatable && !coarray)
- If lock_type && allocatable is true, then subcomponents of type LOCK_TYPE 
are discarded (cf the condition above for lock_type = 1), is that right?
I don't think you have this case in the tests you proposed.

> + gfc_error ("Component %s at %L of type LOCK_TYPE or with subcomponent "
> +"of type LOCK_TYPE is allocatable but not a "
> +"coarray", c->name, &c->loc);
"Allocatable component %s at %L can't be a non-coarray as it would be a non-
coarray of type LOCK_TYPE or it would have a non-coarray sub-component of type 
LOCK_TYPE"

> +
/* 5.3.6: An entity whose type has a coarray ultimate component shall not be a
   coarray.  */
> +  if (sym->attr.coarray_comp && !coarray && lock_type)
> + gfc_error ("Component %s at %L of type LOCK_TYPE or with subcomponent "
> +"of type LOCK_TYPE is not a coarray, but other coarray "
> +"components exist", c->name, &c->loc);
"An entity of type %s at %L can be neither a coarray as it has a coarray 
sub-component, nor a non-coarray as its sub-component %s would be a non-
coarray of type LOCK_TYPE or would have a non-coarray sub-component of type 
LOCK_TYPE"

> +
> +  if (sym->attr.lock_comp && coarray && !lock_type)
> + gfc_error ("Component %s at %L of type LOCK_TYPE or with subcomponent "
> +   

Fix infinite recursion when recursively inlining function with alias

2011-08-05 Thread Jan Hubicka
Hi,
this patch fixes the infinite recursion triggered when buildling MIPS libgcc.
Bootstrapping/regtesting x86_64-linux and will commit it once it passes. Thanks 
to Richard
for reducing the testcase.

Honza

PR middle-end/49735
* gcc.c-torture/compile/pr49735.c: New testcase
* ipa-inline.c (recursive_inlining): Look through aliases.
Index: gcc/testsuite/gcc.c-torture/compile/pr49735.c
===
--- gcc/testsuite/gcc.c-torture/compile/pr49735.c   (revision 0)
+++ gcc/testsuite/gcc.c-torture/compile/pr49735.c   (revision 0)
@@ -0,0 +1,4 @@
+/* { dg-require-alias "" } */
+void bar (void);
+static void foo (void) { bar (); }
+void bar (void) __attribute__((alias("foo")));
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c(revision 177411)
+++ gcc/ipa-inline.c(working copy)
@@ -1206,8 +1206,9 @@ recursive_inlining (struct cgraph_edge *
   depth = 1;
   for (cnode = curr->caller;
   cnode->global.inlined_to; cnode = cnode->callers->caller)
-   if (node->decl == curr->callee->decl)
- depth++;
+   if (node->decl
+   == cgraph_function_or_thunk_node (curr->callee, NULL)->decl)
+  depth++;
 
   if (!want_inline_self_recursive_call_p (curr, node, false, depth))
continue;


Re: [PATCH Atom][PR middle-end/44382] Tree reassociation improvement

2011-08-05 Thread Ilya Enkovich
Hello Richard,

Thanks for reply!

>
> Well, it's enough to delay that to later passes that do this, so I'd prefer
> to not change this in this patch.
>
OK, I'll fix it in next patch version.

> I suppose yes.  Maybe the cases are also obsoleted by the improved
> loop PHI handling.
>
I noticed that PHI node special cases are caught only when we have
three operands in operands vector which is not a case for new expr
rewritter. Grouping of operands with the same rank is a good thing to
do though, so I moved this part of code into a separate function.

I've sent new patch in this mail:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02240.html
It has all comments fixed except TODO_remove_unused_locals flags.

Thanks
Ilya


Re: [PATCH, ARM] Support NEON's VABD with combine pass

2011-08-05 Thread Joseph S. Myers
On Fri, 5 Aug 2011, Ramana Radhakrishnan wrote:

>   I've had a couple of conversations about what the intrinsics
> behaviour should in such cases with folks. Should we try to match vabs
> (vsub)  even for intrinsics and generate a vabd or desist from doing
> this and generate only what was asked for. My personal preference is
> the former but it would be interesting to see what others think .

Intrinsics should generally be considered to have C-level semantics (that 
may happen to be the same as those of a particular machine instruction), 
rather than the semantics that they must generate a particular 
instruction.  I.e., the former.

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


[Ada] Do not generate SCO for use clause or rep clause

2011-08-05 Thread Arnaud Charlet
This change removes SCO generation for USE clauses and representation clauses,
which should not be subjected to coverage analysis.

The following compilation must produce a single statement SCO corresponding
to the declaration of type T:

$ gcc -c -gnateS no_sco.ads
$ grep "^CS" no_sco.ali
CS t3:4-3:25

with Ada;
package No_SCO is
   type T is range 0 .. 1;
   for T'Size use 1;
   use Ada;
end No_SCO;

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

2011-08-05  Thomas Quinot  

* par_sco.adb (Traverse_Declarations_Or_Statements): Do not generate a
statement SCO for a USE clause or a representation clause.

Index: par_sco.adb
===
--- par_sco.adb (revision 177448)
+++ par_sco.adb (working copy)
@@ -1483,7 +1483,8 @@
 
when others =>
 
-  --  Determine required type character code
+  --  Determine required type character code, or ASCII.NUL if
+  --  no SCO should be generated for this node.
 
   declare
  Typ : Character;
@@ -1505,11 +1506,19 @@
 when N_Generic_Instantiation =>
Typ := 'i';
 
+when
+  N_Representation_Clause|
+  N_Use_Package_Clause   |
+  N_Use_Type_Clause  =>
+   Typ := ASCII.NUL;
+
 when others  =>
Typ := ' ';
  end case;
 
- Extend_Statement_Sequence (N, Typ);
+ if Typ /= ASCII.NUL then
+Extend_Statement_Sequence (N, Typ);
+ end if;
   end;
 
   --  Process any embedded decisions


[Ada] Correct ALFA xrefs for separates and pre/post

2011-08-05 Thread Arnaud Charlet
The ALFA cross references generated for formal verification were missing
for separates and incorrect inside pre/post. Now corrected.

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

2011-08-05  Yannick Moy  

* lib-xref-alfa.adb (Collect_ALFA): generate the proper relation
between body and spec for stub.
(Detect_And_Add_ALFA_Scope): take into account subprogram stub
* lib-xref.adb (Enclosing_Subprogram_Or_Package): in the case of a
pragma precondition or postcondition, for which the enclosing
subprogram or package in the AST is not the desired one, return empty.

Index: lib-xref-alfa.adb
===
--- lib-xref-alfa.adb   (revision 177448)
+++ lib-xref-alfa.adb   (working copy)
@@ -845,6 +845,9 @@
if Present (Body_Entity) then
   if Nkind (Body_Entity) = N_Defining_Program_Unit_Name then
  Body_Entity := Parent (Body_Entity);
+  elsif Nkind (Body_Entity) = N_Subprogram_Body_Stub then
+ Body_Entity :=
+   Proper_Body (Unit (Library_Unit (Body_Entity)));
   end if;
 
   Spec_Entity := Corresponding_Spec (Body_Entity);
@@ -874,10 +877,12 @@
 
procedure Detect_And_Add_ALFA_Scope (N : Node_Id) is
begin
-  if Nkind_In (N, N_Subprogram_Declaration,
-  N_Subprogram_Body,
-  N_Package_Declaration,
-  N_Package_Body)
+  if Nkind_In (N,
+   N_Subprogram_Declaration,
+   N_Subprogram_Body,
+   N_Subprogram_Body_Stub,
+   N_Package_Declaration,
+   N_Package_Body)
   then
  Add_ALFA_Scope (N);
   end if;
Index: lib-xref.adb
===
--- lib-xref.adb(revision 177448)
+++ lib-xref.adb(working copy)
@@ -129,7 +129,7 @@
-
 
function Enclosing_Subprogram_Or_Package (N : Node_Id) return Entity_Id is
-  Result : Entity_Id;
+  Result : Entity_Id;
 
begin
   --  If N is the defining identifier for a subprogram, then return the
@@ -167,6 +167,20 @@
Result := Defining_Unit_Name (Specification (Result));
exit;
 
+--  The enclosing subprogram for a pre- or postconditions should be
+--  the subprogram to which the pragma is attached. This is not
+--  always the case in the AST, as the pragma may be declared after
+--  the declaration of the subprogram. Return Empty in this case.
+
+when N_Pragma =>
+   if Get_Pragma_Id (Result) = Pragma_Precondition
+ or else Get_Pragma_Id (Result) = Pragma_Postcondition
+   then
+  return Empty;
+   else
+  Result := Parent (Result);
+   end if;
+
 when others =>
Result := Parent (Result);
  end case;


[PATCH, PR 49923] Check for misaligned accesses before doing SRA

2011-08-05 Thread Martin Jambor
Hi,

the patch below fixes PR 49923 by checking for misaligned accesses
before doing IPA-SRA (on strict alignment targets).  I have checked it
fixes the issue on compile farm sparc64 and I also included this in a
bootstrap and testsuite run on an x86_64-linux just to double check.

OK for trunk and the 4.6 branch?

Thanks,

Martin


2011-08-04  Martin Jambor  

PR middle-end/49923
* tree-sra.c (access_precludes_ipa_sra_p): Also check access
memory alignment.

* testsuite/gcc.dg/tree-ssa/pr49923.c: New test.


Index: src/gcc/tree-sra.c
===
--- src.orig/gcc/tree-sra.c
+++ src/gcc/tree-sra.c
@@ -3688,6 +3688,9 @@ access_precludes_ipa_sra_p (struct acces
  || gimple_code (access->stmt) == GIMPLE_ASM))
 return true;
 
+  if (tree_non_mode_aligned_mem_p (access->expr))
+return true;
+
   return false;
 }
 
Index: src/gcc/testsuite/gcc.dg/tree-ssa/pr49923.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/tree-ssa/pr49923.c
@@ -0,0 +1,55 @@
+/* { dg-do run } */
+/* { dg-options "-O3" } */
+
+#define PACKED __attribute__(( packed ))
+
+struct PACKED aostk_point_u8 {
+  unsigned char x;
+  unsigned char y;
+};
+
+struct PACKED aostk_size_u8 {
+  unsigned char width;
+  unsigned char height;
+};
+
+struct PACKED aostk_glyph {
+   unsigned short i;
+   struct aostk_size_u8 size;
+   char top;
+   struct aostk_point_u8 advance;
+   unsigned char pitch;
+   unsigned char* data;
+   char left;
+};
+
+
+struct PACKED aostk_font {
+   unsigned short numglyphs;
+   unsigned char height;
+   struct aostk_glyph* glyphs;
+};
+
+struct aostk_font glob_font;
+
+static struct aostk_glyph* aostk_get_glyph(struct aostk_font* f, unsigned int 
c) {
+   return f->glyphs;
+}
+
+int aostk_font_strwidth(struct aostk_font* font, const char* str) {
+   struct aostk_glyph* g = aostk_get_glyph(font, 0);
+   return (g != 0);
+}
+
+struct aostk_font*
+__attribute__ ((noinline, noclone))
+get_some_font (void)
+{
+  return &glob_font;
+}
+
+int main (int argc, char *argv[])
+{
+  return (int) aostk_font_strwidth (get_some_font (), "sth");
+  
+}


[Ada] Improve flag positioning for missing quote when comma present

2011-08-05 Thread Arnaud Charlet
This patch improves the positioning for the case of a missing string
quote when a comma is the likely intended end of the string, as shown
by this example:

 1. procedure mquote is
 2. begin
 3.Error_Msg_NE ("this is a string with missing quote, N, E);
 |
>>> missing string quote

 4. end;

Previously the flag was placed on the right paren. this improves
quick fix processing in GPS for this case as well.

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

2011-08-05  Robert Dewar  

* scng.adb (Error_Unterminated_String): Improve flag position when
comma present.

Index: scng.adb
===
--- scng.adb(revision 177448)
+++ scng.adb(working copy)
@@ -919,6 +919,9 @@
  Err : Boolean;
  --  Error flag for Scan_Wide call
 
+ String_Start : Source_Ptr;
+ --  Point to first character of string
+
  procedure Error_Bad_String_Char;
  --  Signal bad character in string/character literal. On entry
  --  Scan_Ptr points to the improper character encountered during the
@@ -966,6 +969,8 @@
  ---
 
  procedure Error_Unterminated_String is
+S : Source_Ptr;
+
  begin
 --  An interesting little refinement. Consider the following
 --  examples:
@@ -973,6 +978,7 @@
 -- A := "this is an unterminated string;
 -- A := "this is an unterminated string &
 -- P(A, "this is a parameter that didn't get terminated);
+-- P("this is a parameter that didn't get terminated, A);
 
 --  We fiddle a little to do slightly better placement in these
 --  cases also if there is white space at the end of the line we
@@ -1012,6 +1018,8 @@
return;
 end if;
 
+--  Backup over semicolon or right-paren/semicolon sequence
+
 if Source (Scan_Ptr - 1) = ';' then
Scan_Ptr := Scan_Ptr - 1;
Unstore_String_Char;
@@ -1022,6 +1030,25 @@
end if;
 end if;
 
+--  See if there is a comma in the string, if so, guess that
+--  the first comma terminates the string.
+
+S := String_Start;
+while S < Scan_Ptr loop
+   if Source (S) = ',' then
+  while Scan_Ptr > S loop
+ Scan_Ptr := Scan_Ptr - 1;
+ Unstore_String_Char;
+  end loop;
+
+  exit;
+   end if;
+
+   S := S + 1;
+end loop;
+
+--  Now we have adjusted the scan pointer, give message
+
 Error_Msg_S -- CODEFIX
   ("missing string quote");
  end Error_Unterminated_String;
@@ -1161,6 +1188,8 @@
  --  quote). The latter case is an error detected by the character
  --  literal circuit.
 
+ String_Start := Scan_Ptr;
+
  Delimiter := Source (Scan_Ptr);
  Accumulate_Checksum (Delimiter);
 


[Ada] Implement -gnatyC for one space after -- in comments

2011-08-05 Thread Arnaud Charlet
For J505-006

This patch implements a new style switch option -gnatyC, which is just
like -gnatyc but requiring one space after -- instead of two.

Consider this test program:

 1. package onespace is
 2.--  don't flag this comment
 3.-- don't flag this comment if -gnatyC
 4.--do flag this comment
 5. end;

compiled with -gnatyc we get (before and after this patch)

 1. package onespace is
 2.--  don't flag this comment
 3.-- don't flag this comment if -gnatyC
  |
>>> (style) space required

 4.--do flag this comment
 |
>>> (style) two spaces required

 5. end;

compiled with -gnatyC after this patch we get

 1. package onespace is
 2.--  don't flag this comment
 3.-- don't flag this comment if -gnatyC
 4.--do flag this comment
 |
>>> (style) space required

 5. end;

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

2011-08-05  Robert Dewar  

* styleg.adb (Check_Comment): Implement comment spacing of 1 or 2
* stylesw.adb: Implement -gnatyC to control comment spacing
* stylesw.ads (Style_Check_Comments_Spacing): New switch (set by
-gnatyc/C).
* usage.adb: Add line for -gnatyC.

Index: usage.adb
===
--- usage.adb   (revision 177448)
+++ usage.adb   (working copy)
@@ -6,7 +6,7 @@
 --  --
 --B o d y   --
 --  --
---  Copyright (C) 1992-2010, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2011, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -548,7 +548,8 @@
Write_Line ("Acheck array attribute indexes");
Write_Line ("bcheck no blanks at end of lines");
Write_Line ("Bcheck no use of AND/OR for boolean expressions");
-   Write_Line ("ccheck comment format");
+   Write_Line ("ccheck comment format (two spaces)");
+   Write_Line ("Ccheck comment format (one space)");
Write_Line ("dcheck no DOS line terminators");
Write_Line ("echeck end/exit labels present");
Write_Line ("fcheck no form feeds/vertical tabs in source");
Index: stylesw.adb
===
--- stylesw.adb (revision 177448)
+++ stylesw.adb (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2010, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2011, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -160,7 +160,13 @@
   Add ('A', Style_Check_Array_Attribute_Index);
   Add ('b', Style_Check_Blanks_At_End);
   Add ('B', Style_Check_Boolean_And_Or);
-  Add ('c', Style_Check_Comments);
+
+  if Style_Check_Comments_Spacing = 2 then
+ Add ('c', Style_Check_Comments);
+  elsif Style_Check_Comments_Spacing = 1 then
+ Add ('C', Style_Check_Comments);
+  end if;
+
   Add ('d', Style_Check_DOS_Line_Terminator);
   Add ('e', Style_Check_End_Labels);
   Add ('f', Style_Check_Form_Feeds);
@@ -322,7 +328,12 @@
 
 when 'c' =>
Style_Check_Comments  := True;
+   Style_Check_Comments_Spacing  := 2;
 
+when 'C' =>
+   Style_Check_Comments  := True;
+   Style_Check_Comments_Spacing  := 1;
+
 when 'd' =>
Style_Check_DOS_Line_Terminator   := True;
 
@@ -484,7 +495,7 @@
 when 'B' =>
Style_Check_Boolean_And_Or:= False;
 
-when 'c' =>
+when 'c' | 'C' =>
Style_Check_Comments  := False;
 
 when 'd' =>
Index: stylesw.ads
===
--- stylesw.ads (revision 177448)
+++ stylesw.ads (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- S p

[PATCH, i386]: various address related fixes/cleanups

2011-08-05 Thread Uros Bizjak
Hello!

These problems were found by testing ZERO_EXTENDed addresses with x32
target. The problems were in handling of SUBREGs of parts.base and
parts.index and in usage of "offsetable operand", 'o' operand
constraint.

The patch does not generate zero extended addresses (yet), since there
is a problem in IRA/reload how "offsetable operand" addresses are
handled (I will post separate RFC patch for that).

2011-08-05  Uros Bizjak  

* config/i386/i386.md (*push2): Use "o" constraint instead
of "m" for operand 0.  Add type and mode attribute.
(*pushxf_nointeger"): Use "<" constraint for operand 0.
(*pushdf_rex64): New pattern, split out of *pushdf.  Use "m"
constraint instead of "o" for opreand 1.
(*pushdf): Disable for TARGET_64BIT.  Correct mode attribute.

2011-08-05  Uros Bizjak  

* config/i386/predicates.md (lea_address_operand): Rename from
no_seg_address_operand.
* config/i386/i386.md (*lea_1): Update operand 1 predicate for rename.
(*lea_1_zext): Ditto.
(*lea_2): Ditto.
(*lea_2_zext): Ditto.

2011-08-05  Uros Bizjak  

* config/i386/i386.c (ix86_print_operand_address): Handle SUBREGs of
parts.base and parts.index.
* config/i386/predicates.md (aligned_operand): Ditto.
(cmpxchg8b_pic_memory_operand): Ditto.

Patch was tested on x86_64-pc-linux-gnu {,-m32} and was committed to
mainline SVN.

Uros.
Index: i386/i386.md
===
--- i386/i386.md(revision 177430)
+++ i386/i386.md(working copy)
@@ -1648,9 +1648,11 @@
 
 (define_insn "*push2"
   [(set (match_operand:DWI 0 "push_operand" "=<")
-   (match_operand:DWI 1 "general_no_elim_operand" "riF*m"))]
+   (match_operand:DWI 1 "general_no_elim_operand" "riF*o"))]
   ""
-  "#")
+  "#"
+  [(set_attr "type" "multi")
+   (set_attr "mode" "")])
 
 (define_split
   [(set (match_operand:TI 0 "push_operand" "")
@@ -2704,7 +2706,7 @@
 ;; only once, but this ought to be handled elsewhere).
 
 (define_insn "*pushxf_nointeger"
-  [(set (match_operand:XF 0 "push_operand" "=X,X")
+  [(set (match_operand:XF 0 "push_operand" "=<,<")
(match_operand:XF 1 "general_no_elim_operand" "f,*rFo"))]
   "optimize_function_for_size_p (cfun)"
 {
@@ -2724,6 +2726,18 @@
(set (mem:XF (reg:P SP_REG)) (match_dup 1))]
   "operands[2] = GEN_INT (-GET_MODE_SIZE (XFmode));")
 
+(define_insn "*pushdf_rex64"
+  [(set (match_operand:DF 0 "push_operand" "=<,<,<")
+   (match_operand:DF 1 "general_no_elim_operand" "f,Yd*rFm,Y2"))]
+  "TARGET_64BIT"
+{
+  /* This insn should be already split before reg-stack.  */
+  gcc_unreachable ();
+}
+  [(set_attr "type" "multi")
+   (set_attr "unit" "i387,*,*")
+   (set_attr "mode" "DF,DI,DF")])
+
 ;; Size of pushdf is 3 (for sub) + 2 (for fstp) + memory operand size.
 ;; Size of pushdf using integer instructions is 2+2*memory operand size
 ;; On the average, pushdf using integers can be still shorter.
@@ -2731,14 +2745,14 @@
 (define_insn "*pushdf"
   [(set (match_operand:DF 0 "push_operand" "=<,<,<")
(match_operand:DF 1 "general_no_elim_operand" "f,Yd*rFo,Y2"))]
-  ""
+  "!TARGET_64BIT"
 {
   /* This insn should be already split before reg-stack.  */
   gcc_unreachable ();
 }
   [(set_attr "type" "multi")
(set_attr "unit" "i387,*,*")
-   (set_attr "mode" "DF,SI,DF")])
+   (set_attr "mode" "DF,DI,DF")])
 
 ;; %%% Kill this when call knows how to work this out.
 (define_split
@@ -5431,7 +5445,7 @@
 
 (define_insn "*lea_1"
   [(set (match_operand:SWI48 0 "register_operand" "=r")
-   (match_operand:SWI48 1 "no_seg_address_operand" "p"))]
+   (match_operand:SWI48 1 "lea_address_operand" "p"))]
   ""
   "lea{}\t{%a1, %0|%0, %a1}"
   [(set_attr "type" "lea")
@@ -5440,7 +5454,7 @@
 (define_insn "*lea_1_zext"
   [(set (match_operand:DI 0 "register_operand" "=r")
(zero_extend:DI
- (match_operand:SI 1 "no_seg_address_operand" "p")))]
+ (match_operand:SI 1 "lea_address_operand" "p")))]
   "TARGET_64BIT"
   "lea{l}\t{%a1, %k0|%k0, %a1}"
   [(set_attr "type" "lea")
@@ -5448,7 +5462,7 @@
 
 (define_insn "*lea_2"
   [(set (match_operand:SI 0 "register_operand" "=r")
-   (subreg:SI (match_operand:DI 1 "no_seg_address_operand" "p") 0))]
+   (subreg:SI (match_operand:DI 1 "lea_address_operand" "p") 0))]
   "TARGET_64BIT"
   "lea{l}\t{%a1, %0|%0, %a1}"
   [(set_attr "type" "lea")
@@ -5457,7 +5471,7 @@
 (define_insn "*lea_2_zext"
   [(set (match_operand:DI 0 "register_operand" "=r")
(zero_extend:DI
- (subreg:SI (match_operand:DI 1 "no_seg_address_operand" "p") 0)))]
+ (subreg:SI (match_operand:DI 1 "lea_address_operand" "p") 0)))]
   "TARGET_64BIT"
   "lea{l}\t{%a1, %k0|%k0, %a1}"
   [(set_attr "type" "lea")
Index: i386/predicates.md
===
--- i386/predicates.md  (revision 177430)
+++ i386/predicates.md  (working copy)
@@ 

[Ada] Implement Disable policy for Check/Debug_Policy

2011-08-05 Thread Arnaud Charlet
This patch adds a new policy DISABLE for Check_Policy, Debug_Policy
and Assertion_Policy. Selecting DISABLE completely disables the
corresponding pragma, including skipping semantic analysis of the
arguments. This allows the use of a package of debug stuff that
can be with'ed and referenced by debug/assert etc pragmas, but
which can be replaced by a null package when these pragmas are
turned off using DISABLE.

The following test package compiles clean, even though the pragmas
reference undefined subprograms (which would presumably be in the
package policydp.ads in a debug build).

 1. package PolicyDP is end;

 1. pragma Debug_Policy (Disable);
 2. pragma Assertion_Policy (Disable);
 3. with PolicyDP;
 4. package PolicyD is
 5.pragma Debug (Undefined);
 6.pragma Assert (Undefinedf = 0);
 7. end;

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

2011-08-05  Robert Dewar  

* opt.ads, opt.adb (Debug_Pragmas_Disabled): New switch.
* sem_prag.adb (Analyze_Pragma, case Debug_Policy): Implement Disable
mode.
(Analyze_Pragma, case Check_Policy): Ditto.
* sem_prag.ads (Check_Disabled): New function
* snames.ads-tmpl: Add Name_Disable.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 177458)
+++ sem_prag.adb(working copy)
@@ -352,12 +352,18 @@
   --  Check the specified argument Arg to make sure that it is a valid
   --  locking policy name. If not give error and raise Pragma_Exit.
 
-  procedure Check_Arg_Is_One_Of (Arg : Node_Id; N1, N2 : Name_Id);
-  procedure Check_Arg_Is_One_Of (Arg : Node_Id; N1, N2, N3 : Name_Id);
-  procedure Check_Arg_Is_One_Of (Arg : Node_Id; N1, N2, N3, N4 : Name_Id);
+  procedure Check_Arg_Is_One_Of
+(Arg: Node_Id;
+ N1, N2 : Name_Id);
+  procedure Check_Arg_Is_One_Of
+(Arg: Node_Id;
+ N1, N2, N3 : Name_Id);
+  procedure Check_Arg_Is_One_Of
+(Arg: Node_Id;
+ N1, N2, N3, N4, N5 : Name_Id);
   --  Check the specified argument Arg to make sure that it is an
-  --  identifier whose name matches either N1 or N2 (or N3 if present).
-  --  If not then give error and raise Pragma_Exit.
+  --  identifier whose name matches either N1 or N2 (or N3, N4, N5 if
+  --  present). If not then give error and raise Pragma_Exit.
 
   procedure Check_Arg_Is_Queuing_Policy (Arg : Node_Id);
   --  Check the specified argument Arg to make sure that it is a valid
@@ -1055,8 +1061,8 @@
   end Check_Arg_Is_One_Of;
 
   procedure Check_Arg_Is_One_Of
-(Arg: Node_Id;
- N1, N2, N3, N4 : Name_Id)
+(Arg: Node_Id;
+ N1, N2, N3, N4, N5 : Name_Id)
   is
  Argx : constant Node_Id := Get_Pragma_Arg (Arg);
 
@@ -1067,11 +1073,11 @@
and then Chars (Argx) /= N2
and then Chars (Argx) /= N3
and then Chars (Argx) /= N4
+   and then Chars (Argx) /= N5
  then
 Error_Pragma_Arg ("invalid argument for pragma%", Argx);
  end if;
   end Check_Arg_Is_One_Of;
-
   -
   -- Check_Arg_Is_Queuing_Policy --
   -
@@ -6419,7 +6425,7 @@
 
 Rewrite (N,
   Make_Pragma (Loc,
-Chars => Name_Check,
+Chars=> Name_Check,
 Pragma_Argument_Associations => Newa));
 Analyze (N);
  end Assert;
@@ -6428,7 +6434,7 @@
  -- Assertion_Policy --
  --
 
- --  pragma Assertion_Policy (Check | Ignore)
+ --  pragma Assertion_Policy (Check | Disable |Ignore)
 
  when Pragma_Assertion_Policy => Assertion_Policy : declare
 Policy : Node_Id;
@@ -6438,7 +6444,7 @@
 Check_Valid_Configuration_Pragma;
 Check_Arg_Count (1);
 Check_No_Identifiers;
-Check_Arg_Is_One_Of (Arg1, Name_Check, Name_Ignore);
+Check_Arg_Is_One_Of (Arg1, Name_Check, Name_Disable, Name_Ignore);
 
 --  We treat pragma Assertion_Policy as equivalent to:
 
@@ -6863,6 +6869,14 @@
 
 Check_Arg_Is_Identifier (Arg1);
 
+--  Completely ignore if disabled
+
+if Check_Disabled (Chars (Get_Pragma_Arg (Arg1))) then
+   Rewrite (N, Make_Null_Statement (Loc));
+   Analyze (N);
+   return;
+end if;
+
 --  Indicate if pragma is enabled. The Original_Node reference here
 --  is to deal with pragma Assert rewritten as a Check pragma.
 
@@ -6948,7 +6962,7 @@
  --[Name   =>] IDENTIFIER,
  --[Policy =>] POLICY_IDENTIFIER);
 
- --  POLICY_IDENTIFIER ::= ON | OFF |

[Ada] Correct unique name of entities for formal verification

2011-08-05 Thread Arnaud Charlet
As some entities end up with an unqualified name, for example for the
declaration of a library-level subprogram, the name given by Unique_Name should
match the qualified name. Now corrected.

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

2011-08-05  Yannick Moy  

* sem_util.adb (Unique_Name): only prefix with "standard" the names of
entities directly in package Standard, otherwise skip the standard
prefix.

Index: sem_util.adb
===
--- sem_util.adb(revision 177448)
+++ sem_util.adb(working copy)
@@ -12357,14 +12357,37 @@
-
 
function Unique_Name (E : Entity_Id) return String is
-  Name : constant String := Get_Name_String (Chars (E));
+
+  function Get_Scoped_Name (E : Entity_Id) return String;
+  --  Return the name of E prefixed by all the names of the scopes to which
+  --  E belongs, except for Standard.
+
+  -
+  -- Get_Scoped_Name --
+  -
+
+  function Get_Scoped_Name (E : Entity_Id) return String is
+ Name : constant String := Get_Name_String (Chars (E));
+  begin
+ if Has_Fully_Qualified_Name (E)
+   or else Scope (E) = Standard_Standard
+ then
+return Name;
+ else
+return Get_Scoped_Name (Scope (E)) & "__" & Name;
+ end if;
+  end Get_Scoped_Name;
+
begin
-  if Has_Fully_Qualified_Name (E)
-or else E = Standard_Standard
-  then
- return Name;
+  if E = Standard_Standard then
+ return Get_Name_String (Name_Standard);
+
+  elsif Scope (E) = Standard_Standard then
+ return Get_Name_String (Name_Standard) & "__" &
+   Get_Name_String (Chars (E));
+
   else
- return Unique_Name (Scope (E)) & "__" & Name;
+ return Get_Scoped_Name (E);
   end if;
end Unique_Name;
 
@@ -12478,7 +12501,7 @@
--  Start of processing for Unit_Is_Visible
 
begin
-  --  The currrent unit is directly visible.
+  --  The currrent unit is directly visible
 
   if Curr = U then
  return True;
@@ -12486,7 +12509,7 @@
   elsif Unit_In_Context (Curr) then
  return True;
 
-  --  If the current unit is a body, check the context of the spec.
+  --  If the current unit is a body, check the context of the spec
 
   elsif Nkind (Unit (Curr)) = N_Package_Body
 or else
@@ -12498,7 +12521,7 @@
  end if;
   end if;
 
-  --  If the spec is a child unit, examine the parents.
+  --  If the spec is a child unit, examine the parents
 
   if Is_Child_Unit (Curr_Entity) then
  if Nkind (Unit (Curr)) in N_Unit_Body then
@@ -12670,7 +12693,7 @@
 if Comes_From_Source (Expec_Type) then
Matching_Field := Expec_Type;
 
---  For an assignment, use name of target.
+--  For an assignment, use name of target
 
 elsif Nkind (Parent (Expr)) = N_Assignment_Statement
   and then Is_Entity_Name (Name (Parent (Expr)))


Re: [pph] Stream and merge line table. (issue4836050)

2011-08-05 Thread dnovillo

OK with these changes.

As far as the trunk changes go.  Just commit your changes to the branch.
 I will get the trunk changes whenever they get approved in some future
merge.


Diego.


http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer-in.c
File gcc/cp/pph-streamer-in.c (right):

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer-in.c#newcode73
gcc/cp/pph-streamer-in.c:73: int pph_loc_offset;
   71 /* Set in pph_in_and_merge_line_table. Represents the
source_location offset
   72which every streamed in token must add to it's serialized
source_location. */
   73 int pph_loc_offset;

Make it static.

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer-out.c
File gcc/cp/pph-streamer-out.c (right):

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer-out.c#newcode134
gcc/cp/pph-streamer-out.c:134: simply add them to the cache in the
preload.  */
  132   /* FIXME pph: we are streaming builtin locations, which implies
that we are
  133  streaming some builtins, we probably want to figure out what
those are and
  134  simply add them to the cache in the preload.  */

Hmm, we are streaming builtins?  The low-level streamer detects builtins
and only emits the builtin code, not the whole tree.  What builtins are
getting through?

This can be addressed on a follow-up patch.  It just sounds strange to
me that we are streaming builtins and locations.

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer.h
File gcc/cp/pph-streamer.h (right):

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer.h#newcode344
gcc/cp/pph-streamer.h:344: streamer hook back to pph_write_location.  */
 342FIXME pph: If pph_trace didn't depend on STREAM, we could avoid
having to
 343call this function, only for it to call lto_output_location,
which calls the
 344streamer hook back to pph_write_location.  */

Just call pph_write_location here.  No need to call lto_output_location
anymore.   We only rely on lto_output_location calling us when it's
called from tree leaves inside the tree streamer routines.

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer.h#newcode419
gcc/cp/pph-streamer.h:419:
415 /* Read and return a location_t from STREAM.
 416FIXME pph: If pph_trace didn't depend on STREAM, we could avoid
having to
 417call this function, only for it to call lto_input_location,
which calls the
 418streamer hook back to pph_read_location.  */
 419

Likewise here.

http://codereview.appspot.com/4836050/diff/1/gcc/lto-streamer-in.c
File gcc/lto-streamer-in.c (right):

http://codereview.appspot.com/4836050/diff/1/gcc/lto-streamer-in.c#newcode342
gcc/lto-streamer-in.c:342: if(streamer_hooks.input_location)
  342   if(streamer_hooks.input_location)

Space before '('

http://codereview.appspot.com/4836050/


Re: [PATCH, i386]: various address related fixes/cleanups

2011-08-05 Thread Uros Bizjak
On Fri, Aug 5, 2011 at 5:26 PM, Uros Bizjak  wrote:

> These problems were found by testing ZERO_EXTENDed addresses with x32
> target. The problems were in handling of SUBREGs of parts.base and
> parts.index and in usage of "offsetable operand", 'o' operand
> constraint.

Whops, forgot to commit this part:

2011-08-05  Uros Bizjak  

* config/i386/i386.md (*movdi_internal_rex64): Use "!o" constraint
instead of "!m" for operand 0, alternative 4.
(*movdf_internal_rex64): Ditto for operand 0, alernative 6.

Uros.


Re: [s390] [committed]: fix call to store_bit_field()

2011-08-05 Thread Andreas Krebbel
On Fri, Aug 05, 2011 at 08:32:39AM -0500, Aldy Hernandez wrote:
> Target could not build due to missing new arguments.
> 
> Tested by building cc1.
> 
> Committed as obvious.

>   * config/s390/s390.c (s390_expand_cs_hqi): Add new arguments to
>   store_bit_field.
>   (s390_expand_atomic): Same.

Thanks!

Bye,

-Andreas-


Re: [pph] Add initial support for including nested pph images (issue4847044)

2011-08-05 Thread Diego Novillo
On Thu, Aug 4, 2011 at 17:47,   wrote:
> So if I understand correctly, the reference system doesn't work yet, you
> just put out the design in this patch and you'll fill up functionality
> in an upcoming patch so that's it's clearer what you're adding?

Right, the 'if (0)' in pph_in_includes() disables support for it.

> http://codereview.appspot.com/4847044/diff/1/gcc/cp/pph-streamer-in.c
> File gcc/cp/pph-streamer-in.c (right):
>
> http://codereview.appspot.com/4847044/diff/1/gcc/cp/pph-streamer-in.c#newcode1491
> gcc/cp/pph-streamer-in.c:1491: pph_add_include (stream);
> does this mean the included pph has the include information for all of
> the headers in it's transitive closure? i.e. we don't need to load child
> information of a child? if so, isn't this bad from a dependency point of
> view?

Hmm?  Each header knows what other images it includes, so before
reading its own content it reads the contents from the others.  The
dependencies don't change.  The parent will not have the physical
representation of the ASTs from the children, just references to them.

> http://codereview.appspot.com/4847044/diff/1/gcc/cp/pph.c
> File gcc/cp/pph.c (right):
>
> http://codereview.appspot.com/4847044/diff/1/gcc/cp/pph.c#newcode164
> gcc/cp/pph.c:164: if (pph_out_file != NULL)
> shouldn't you use your new pph_enabled_p function here?

No.  I need to know whether we are *creating* a PPH image.  Perhaps I
should add a different predicate.

> http://codereview.appspot.com/4847044/diff/1/gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc
> File gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc (right):
>
> http://codereview.appspot.com/4847044/diff/1/gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc#newcode1
> gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc:1: /* { dg-options "-O
> -Wno-psabi -mtune=generic" } */
> Is this related to the rest of the changes in this patch? I don't see it
> mentioned in your patch comments

Gah.  I was going to commit this separately but forgot.  Sorry about that.


Diego.


Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

2011-08-05 Thread Mikael Morin
On Thursday 04 August 2011 23:42:11 Janus Weil wrote:
> Hi all,
> 
> attached is a draft patch fixing the PR in the subject line and
> extending the checks for overriding type-bound functions. It regtests
> cleanly on x86_64-unknown-linux-gnu already, but I would like to have
> some feedback.
Some quick comments: 

> 
> The patch is rather large, but most of it is just mechanical, due to
> the fact that I added an extra argument to 'gfc_dep_compare_expr'. 
You might want to make the flag an implementation detail, that is keep the 
gfc_dep_compare_expr interface unchanged, but make the function a wrapper 
around the real function with the flag.

> I use this function to compare the string-length expressions of a
> character-valued TBP and an overriding procedure (the standard
> requires them to be equal). Inside 'gfc_dep_compare_expr' I had to add
> a minor piece to correctly respect commutativity of the multiplication
> operator (for the addition operator this was done already). 
OK

> The extra
> argument controls whether we check variable symbols for equality or
> just their names. For the overriding checks it is sufficient to check
> for names, because the arguments of the overriding procedure are
> required to have the same names as in the base procedure.

Unless you extend the flag thing to all the children function of 
gfc_dep_compare_expr (there are zillions of them), it is preferable IMO to 
make the diagnostic a warning, as identical expressions could be missed.

> 
> Moreover I extended the type check in 'check_typebound_override' to
> also check for correct rank, via 'compare_type_rank' instead of
> 'gfc_compare_types'. However, the former was local to interface.c, so
> I made it public (and should probably also rename it to gfc_...),
Yes

> or should one rather move 'check_typebound_override' to interface.c
> itself? I think it fits in there pretty nicely. After all it is
> checking the interfaces of overriding procedures.
Makes sense too. Either is fine.

> 
> Anything else missing for this patch? Or is it ok for trunk? (I will
> add corresponding test cases and a ChangeLog, of course.)
Apart for the error/warning change and the missing tests and ChangeLog, the 
patch is OK.

Mikael



Re: [Patch, Fortran, OOP] PR 49112: [4.6/4.7 Regression] Missing type-bound procedure, "duplicate save" warnings and internal compiler error

2011-08-05 Thread Janus Weil
2011/7/31 Janus Weil :
>>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.6?
>>>
>> OK, Thanks.
>
> Thanks, Mikael. Committed to trunk as r176971. Will apply to 4.6 soon.

Committed to 4.6 as r177468.

Cheers,
Janus


Re: [C++0x] contiguous bitfields race implementation

2011-08-05 Thread Aldy Hernandez
Alright, I'm back and bearing patches.  Firmly ready for the crucifixion 
you will likely submit me to. :)


I've pretty much rewritten everything, taking into account all your 
suggestions, and adding a handful of tests for corner cases we will now 
handle correctly.


It seems the minimum needed is to calculate the byte offset of the start 
of the bit region, and the length of the bit region.  (Notice I say BYTE 
offset, as the start of any bit region will happily coincide with a byte 
boundary).  These will of course be adjusted as various parts of the 
bitfield infrastructure adjust offsets and memory addresses throughout.


First, it's not as easy as calling get_inner_reference() only once as 
you've suggested.  The only way to determine the padding at the end of a 
field is getting the bit position of the field following the field in 
question (or the size of the direct parent structure in the case where 
the field in question is the last field in the structure).  So we need 
two calls to get_inner_reference for the general case.  Which is at 
least better than my original call to get_inner_reference() for every field.


I have clarified the comments and made it clear what the offsets are 
relative to.


I am now handling large offsets that may appear as a tree OFFSET from 
get_inner_reference, and have added a test for one such corner case, 
including nested structures with head padding as you suggested.  I am 
still unsure that a variable length offset can happen before a bit field 
region.  So currently we assert that the final offset is host integer 
representable.  If you have a testcase that invalidates my assumption, I 
will gladly add a test and fix the code.


Honestly, the code isn't pretty, but neither is the rest of the bit 
field machinery.  I tried to make due, but I'll gladly take suggestions 
that are not in the form of "the entire bit field code needs to be 
rewritten" :-).


To aid in reviewing, the crux of everything is in the rewritten 
get_bit_range() and the first block of store_bit_field().  Everything 
else is mostly noise.  I have attached all of get_bit_range() as a 
separate attachment to aid in reviewing, since that's the main engine, 
and it has been largely rewritten.


This pacth handles all the testcases I could come up with, mostly 
inspired by your suggestions.  Eventually I would like to replace these 
target specific tests with target-agnostic tests using the gdb simulated 
thread test harness in the cxx-mem-model branch.


Finally, you had mentioned possible problems with tail padding in C++, 
and suggested I use DECL_SIZE instead of calculating the padding using 
the size of direct parent structure.  DECL_SIZE doesn't include padding, 
so I'm open to suggestions.


Fire away, but please be kind :).
* machmode.h (get_best_mode): Remove 2 arguments.
* fold-const.c (optimize_bit_field_compare): Same.
(fold_truthop): Same.
* expr.c (store_field): Change argument types in prototype.
(emit_group_store): Change argument types to store_bit_field call.
(copy_blkmode_from_reg): Same.
(write_complex_part): Same.
(optimize_bitfield_assignment_op): Change argument types.
Change arguments to get_best_mode.
(get_bit_range): Rewrite.
(expand_assignment): Adjust new call to get_bit_range.
Adjust bitregion_offset when to_rtx is changed.
Adjust calls to store_field with new argument types.
(store_field): New argument types.
Adjust calls to store_bit_field with new arguments.
* expr.h (store_bit_field): Change argument types.
* stor-layout.c (get_best_mode): Remove use of bitregion* arguments.
* expmed.c (store_bit_field_1): Change argument types.
Do not calculate maxbits.
Adjust bitregion_maxbits if offset changes.
(store_bit_field): Change argument types.
Adjust address taking into account bitregion_offset.
(store_fixed_bit_field): Change argument types.
Do not calculate maxbits.
(store_split_bit_field): Change argument types.
(extract_bit_field_1): Adjust arguments to get_best_mode.
(extract_fixed_bit_field): Same.

Index: machmode.h
===
--- machmode.h  (revision 176891)
+++ machmode.h  (working copy)
@@ -249,8 +249,6 @@ extern enum machine_mode mode_for_vector
 /* Find the best mode to use to access a bit field.  */
 
 extern enum machine_mode get_best_mode (int, int,
-   unsigned HOST_WIDE_INT,
-   unsigned HOST_WIDE_INT,
unsigned int,
enum machine_mode, int);
 
Index: fold-const.c
===
--- fold-const.c(revision 176891)
+++ fold-const.c(working copy)
@@ -3394,7 +3394,7 @@ opti

Re: [PATCH 1/7] Linemap infrastructure for virtual locations

2011-08-05 Thread Jason Merrill

On 08/05/2011 01:04 PM, Dodji Seketeli wrote:

Jason Merrill  writes:


Why not 0x?  I'm not sure what the rationale for using that
value here:


   /* If the column number is ridiculous or we've allocated a huge
  number of source_locations, give up on column numbers. */
   max_column_hint = 0;
- if (highest>0xF000)
+ if (highest>  MAX_SOURCE_LOCATION)
 return 0;


was, but I would think that we would be fine to use that upper range
for macro maps.


I have no idea where the 0xF000 comes from.  I have now set it to
0x and it passed bootstrap + tests fine.


Sorry, I should have been clearer; I think we want to leave this test 
alone so that ordinary locations don't grow past 0xF000, leaving the 
top range for macro locations.


Jason


Re: [pph] Stream and merge line table. (issue4836050)

2011-08-05 Thread Gabriel Charette
[+ccoutant]

>> Added lto streamer hooks to do this, but Cary (ccoutant) was saying he'd
>> want it directly in lto.
>>
>> Do we want to apply the changes to libcpp to trunk now or wait??
>
> How urgent is the merge?  It wouldn't hurt to run a few more test
> cases.  I have some hidden in my client


Neither the merge to lto (Cary said he'd like that), nor the libcpp
merge to trunk are required (libcpp changes are trivial, just pulling
out some inline code into a function for re-use and defined some
constants to avoid "magic numbers" in the code, but there is not much
point for them without the pph code (i.e. they'll only be used once
each, where they were originally pulled out from)).

Gab
We can definitely keep it in pph for a little while until it's stable.


Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

2011-08-05 Thread Janus Weil
Hi Mikael,

>> The extra
>> argument controls whether we check variable symbols for equality or
>> just their names. For the overriding checks it is sufficient to check
>> for names, because the arguments of the overriding procedure are
>> required to have the same names as in the base procedure.
>
> Unless you extend the flag thing to all the children function of
> gfc_dep_compare_expr (there are zillions of them), it is preferable IMO to
> make the diagnostic a warning, as identical expressions could be missed.

Well, it would not be really satisfying to degrade the error to a
warning, knowing it may be wrong sometimes. So I think one should
rather fix this, which I think is not as hard as you suggest:
gfc_dep_compare_expr doesn't exactly have "zillions" of children, but
just two AFAICS:

 * gfc_are_identical_variables
 * gfc_dep_compare_functions

Apart from those two, it is highly recursive and mostly calls itself,
where the argument is passed on already. So I think it's feasible to
add the extra argument to the above two functions, too (unless anyone
has a better idea).

I'll fix this and send an updated patch soon.

Thanks,
Janus


Re: [pph] Stream and merge line table. (issue4836050)

2011-08-05 Thread Dodji Seketeli
Hello Gabriel,

gch...@google.com (Gabriel Charette) a écrit:

[...]

> Do we want to apply the changes to libcpp to trunk now or wait??

[...]


> 2011-08-04  Gabriel Charette  

[...]

>   * include/line-map.h (LC_REASON_BIT): Define as CHAR_BIT.
>   (COLUMN_BITS_BIT): Define as 8.
>   (struct line_map): Use LC_REASON_BIT and COLUMN_BITS_BIT to represent
>   field specific bit requirements.
>   * line-map.c (linemap_ensure_extra_space_available): New.
>   (linemap_add): Call linemap_ensure_extra_space_available.
>   (linemap_line_start): Fixed missing space.

[...]

> diff --git a/libcpp/include/line-map.h b/libcpp/include/line-map.h
> index 3234423..657e47f 100644
> --- a/libcpp/include/line-map.h
> +++ b/libcpp/include/line-map.h
> @@ -44,6 +44,9 @@ typedef unsigned int source_location;
>  /* Memory allocation function typedef.  Works like xrealloc.  */
>  typedef void *(*line_map_realloc) (void *, size_t);
>  
> +#define LC_REASON_BIT CHAR_BIT

This is a nit, but I would keep this hunk ... 

>  /* Physical source file TO_FILE at line TO_LINE at column 0 is represented
> by the logical START_LOCATION.  TO_LINE+L at column C is represented by
> START_LOCATION+(L*(1< @@ -61,11 +64,11 @@ struct GTY(()) line_map {
>linenum_type to_line;
>source_location start_location;
>int included_from;
> -  ENUM_BITFIELD (lc_reason) reason : CHAR_BIT;
> +  ENUM_BITFIELD (lc_reason) reason : LC_REASON_BIT;

... and this one into your private branch for now and apply it to trunk
(provided the maintainers agree) with the rest of this patch.
Otherwise, in isolation, this new define could look like a gratuitous
change.

[...]

>  /* A set of chronological line_map structures.  */
> @@ -190,4 +193,24 @@ extern const struct line_map *linemap_lookup
>  extern source_location
>  linemap_position_for_column (struct line_maps *set, unsigned int to_column);
>  
> +/* Makes sure SET has at least one more unused line_map allocated.
> +   If it doesn't, this function allocates more room in SET.  */
> +
> +static inline void
> +linemap_ensure_extra_space_available (struct line_maps *set)
> +{
> +  if (set->used == set->allocated)
> +{
> +  line_map_realloc reallocator;
> +  reallocator  = set->reallocator ? set->reallocator : xrealloc;
> +
> +  set->allocated = 2 * set->allocated + 256;
> +  set->maps = (struct line_map *) (*reallocator) (set->maps,
> +   set->allocated * sizeof (struct line_map));
> +
> +  memset (&set->maps[set->used], 0,
> +  (set->allocated - set->used) * sizeof (struct line_map));
> +}
> +}
> +
>  #endif /* !LIBCPP_LINE_MAP_H  */
> diff --git a/libcpp/line-map.c b/libcpp/line-map.c
> index 86e2484..01ed7b5 100644
> --- a/libcpp/line-map.c
> +++ b/libcpp/line-map.c
> @@ -94,18 +94,7 @@ linemap_add (struct line_maps *set, enum lc_reason reason,
>if (set->used && start_location < set->maps[set->used - 1].start_location)
>  abort ();
>  
> -  if (set->used == set->allocated)
> -{
> -  line_map_realloc reallocator
> - = set->reallocator ? set->reallocator : xrealloc;
> -  set->allocated = 2 * set->allocated + 256;
> -  set->maps
> - = (struct line_map *) (*reallocator) (set->maps,
> -   set->allocated
> -   * sizeof (struct line_map));
> -  memset (&set->maps[set->used], 0, ((set->allocated - set->used)
> -  * sizeof (struct line_map)));
> -}
> +  linemap_ensure_extra_space_available (set);

Just FYI, in my macro location tracking patch set (that is also that is
being reviewed "at the moment") I have added a similar function named
new_linemap, that allocates a new line map and adds it to the set of
line maps.  The relevant patch is at [1].

I am CC-ing Tom, as I cannot approve or reject this patch.

Thanks.

[1]: http://tinyurl.com/3jkaeh2

-- 
Dodji


[trans-mem] Use per-transaction reader flags for the serial lock

2011-08-05 Thread Torvald Riegel
This is a two-piece patch set.

patch8:

The first patch merely keeps a list of all threads with transactions,
registering and deregistering gtm_transaction objects during their
construction and destruction. The aligment attribute for the start of
the shared part of a gtm_transaction object relies on allocating those
objects on separate cachelines (and thus aligned at cacheline
granularity). This has not been implemented yet, but is requested by the
xmalloc call for gtm_transaction.


patch9:

This is the major part, changing the serial lock implementation to a
have split and per-transaction/per-thread "reader-active" flags. See the
updates to libitm.texi for more information. Currently, only the
pthreads-based implementation is ready, but the futex-based one should
follow soon.
For the assumed common case of infrequent serial transactions, this
split of the flags reduces any contention between readers, but adds some
overhead when entering serial mode, and two barriers in the reader
fast-path.

For a simple performance test with the serial-on-write TM method and the
red-black integer set microbenchmark, I got the following numbers for
1/2/4 threads, and x% being the percentage of set update operations in
the benchmark (i.e., which percentage of transactions has to upgrade to
serial mode). "old" is the previous implementation, "new" the new one,
"nolock" is without reader-side locking (unsafe for >0%), "nofence" is
"new" but without the necessary fences in the reader fastpath (unsafe
for >0%, too). Numbers are throughput (million txns per 10s):

old 0%:   52 / 48 /  36

new 0%:   49 / 90 / 120
new 1%:   47 / 59 /  27
new 20%   34 /  6 /   3
new 100%: 15 /  1 /   1

nolock 0%:   56 / 104 / 120
nolock 1%:   55
nolock 20%:  38
nolock 100%: 16
nofence 0%:  55 / 100 / 120

As you can see, the old r/w lock wasn't performing well (I don't have
precise numbers anymore, but there were even larger slowdowns for >0%
updates).
The new implementation scales well when there is no serial mode, but has
higher single-thread overhead due to the fences. I'm not happy about the
slowdowns that occur when there is some serial mode (ideally, this
should be just flat for "new 100%"), even for 1% throughput already
suffers.
However, there is no spinning yet in the implementation. Adding and
tuning that should reduce the overheads. (At least for the similar
implementation in tinySTM++ which had only spinning, there was a bit of
slowdown for 100%, but not that much as above, even with ASF).
Furthermore, we could try proper queue locks (or other options) to
reduce writer-writer contention overheads, go for a simpler r/w lock for
low thread counts, or try to optimize how writers block for readers. But
in any case, I think this should be tuned later, and at least again when
we have real-world workloads (eg, to find practical values for how long
to spin).

Bottom line: I think it's an improvement, but there remains a lot of
tuning to be done.

OK for branch?
commit d51d095e341d16749f6d1c8153817db7fb31945a
Author: Torvald Riegel 
Date:   Fri Jul 29 22:12:14 2011 +0200

Maintain a list of all threads' transactions.

* libitm_i.h (next_tx): Add list of all threads' transaction.
* beginend.cc (GTM::gtm_transaction::begin_transaction): Register
transaction with list of transactions and ...
(thread_exit_handler): ... deregister here.

diff --git a/libitm/beginend.cc b/libitm/beginend.cc
index 08592a3..fc7cb8d 100644
--- a/libitm/beginend.cc
+++ b/libitm/beginend.cc
@@ -29,6 +29,7 @@ using namespace GTM;
 
 __thread gtm_thread GTM::_gtm_thr;
 gtm_rwlock GTM::gtm_transaction::serial_lock;
+gtm_transaction *GTM::gtm_transaction::list_of_tx = 0;
 
 gtm_stmlock GTM::gtm_stmlock_array[LOCK_ARRAY_SIZE];
 gtm_version GTM::gtm_clock;
@@ -75,6 +76,20 @@ thread_exit_handler(void *dummy __attribute__((unused)))
 {
   if (tx->nesting > 0)
 GTM_fatal("Thread exit while a transaction is still active.");
+
+  // Deregister this transaction.
+  gtm_transaction::serial_lock.write_lock ();
+  gtm_transaction **prev = >m_transaction::list_of_tx;
+  for (; *prev; prev = &(*prev)->next_tx)
+{
+  if (*prev == tx)
+{
+  *prev = (*prev)->next_tx;
+  break;
+}
+}
+  gtm_transaction::serial_lock.write_unlock ();
+
   delete tx;
   set_gtm_tx(NULL);
 }
@@ -124,6 +139,12 @@ GTM::gtm_transaction::begin_transaction (uint32_t prop, 
const gtm_jmpbuf *jb)
   tx = new gtm_transaction;
   set_gtm_tx(tx);
 
+  // Register this transaction with the list of all threads' transactions.
+  serial_lock.write_lock ();
+  tx->next_tx = list_of_tx;
+  list_of_tx = tx;
+  serial_lock.write_unlock ();
+
   if (pthread_once(&tx_release_once, thread_exit_init))
 GTM_fatal("Initializing tx release TLS key failed.");
   // Any non-null value is sufficient to trigger releasing of this
diff --gi

Re: Remove line 0 hack in cp/decl.c (issue4835047)

2011-08-05 Thread Tom Tromey
> "Gabriel" == Gabriel Charette  writes:

Gabriel> This hack, has described in more details in the email labeled
Gabriel> "Line 0 Hack??", was now causing problem when serializing the
Gabriel> line_table in pph.

I think you do have to handle location 0 somehow.
This is UNKNOWN_LOCATION, referred to widely in the sources.

Gabriel> 2011-08-01  Gabriel Charette  
Gabriel>* decl.c (finish_function): Remove unecessary line 0 hack.

Now that -Wunreachable-code is gone, I doubt this code is even
theoretically relevant.  So, while I can't approve or reject this patch,
it seems reasonable to me.

Tom


Re: Remove line 0 hack in cp/decl.c (issue4835047)

2011-08-05 Thread Diego Novillo
On Fri, Aug 5, 2011 at 13:37, Tom Tromey  wrote:
>> "Gabriel" == Gabriel Charette  writes:
>
> Gabriel> This hack, has described in more details in the email labeled
> Gabriel> "Line 0 Hack??", was now causing problem when serializing the
> Gabriel> line_table in pph.
>
> I think you do have to handle location 0 somehow.
> This is UNKNOWN_LOCATION, referred to widely in the sources.
>
> Gabriel> 2011-08-01  Gabriel Charette  
> Gabriel>        * decl.c (finish_function): Remove unecessary line 0 hack.
>
> Now that -Wunreachable-code is gone, I doubt this code is even
> theoretically relevant.  So, while I can't approve or reject this patch,
> it seems reasonable to me.

In that case, this is OK for trunk.  Thanks Tom.


Diego.


Re: [pph] Stream and merge line table. (issue4836050)

2011-08-05 Thread gchare

Fixed all, committing to pph.

Regarding builtins, it looked like some builtins like "int type" were
streamed out as part of streaming out a non-builtin decl, i.e. a
non-builtins with builtins in it's transitive closure.


http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer-out.c
File gcc/cp/pph-streamer-out.c (right):

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer-out.c#newcode134
gcc/cp/pph-streamer-out.c:134: simply add them to the cache in the
preload.  */
On 2011/08/05 16:01:15, Diego Novillo wrote:

   132   /* FIXME pph: we are streaming builtin locations, which

implies that we

are
   133  streaming some builtins, we probably want to figure out

what those

are and
   134  simply add them to the cache in the preload.  */



Hmm, we are streaming builtins?  The low-level streamer detects

builtins and

only emits the builtin code, not the whole tree.  What builtins are

getting

through?



This can be addressed on a follow-up patch.  It just sounds strange to

me that

we are streaming builtins and locations.


Right, I originally had an assert here that all locations written were
in the user-defined source_location range, but some were in the builtin
range.

My plan is to look into this next (after fixing the last asm diff
potentially)

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer.h
File gcc/cp/pph-streamer.h (right):

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer.h#newcode344
gcc/cp/pph-streamer.h:344: streamer hook back to pph_write_location.  */
On 2011/08/05 16:01:15, Diego Novillo wrote:

  342FIXME pph: If pph_trace didn't depend on STREAM, we could

avoid having

to
  343call this function, only for it to call lto_output_location,

which calls

the
  344streamer hook back to pph_write_location.  */



Just call pph_write_location here.  No need to call

lto_output_location anymore.

   We only rely on lto_output_location calling us when it's called from

tree

leaves inside the tree streamer routines.


Ah right, definitely :)!

http://codereview.appspot.com/4836050/


Re: [pph] Allocate string tables separately. (issue4843044)

2011-08-05 Thread gchare

Yep this fixes the problem I had with the strings being freed early.

See comments inline below.


http://codereview.appspot.com/4843044/diff/1/gcc/cp/pph-streamer-in.c
File gcc/cp/pph-streamer-in.c (right):

http://codereview.appspot.com/4843044/diff/1/gcc/cp/pph-streamer-in.c#newcode157
gcc/cp/pph-streamer-in.c:157: memcpy (new_strtab, strtab, strtab_size);
I don't think we need to memcpy, to be more efficient instead we can
just change the way stream->encoder.r.file_data is read to only read the
pph_file_header + body into it, and fread the strtab straight into
new_strtab.

This implies more logic when reading, but is potentially more efficient.

http://codereview.appspot.com/4843044/


Re: Correct fix for scheduler bug PR11320

2011-08-05 Thread Bernd Schmidt
On 07/22/11 19:23, Bernd Schmidt wrote:
> On 07/22/11 19:17, Richard Henderson wrote:
>> On 07/22/2011 10:00 AM, Eric Botcazou wrote:
 It's getting confused about loads/stores being control_flow_insns and
 getting scheduled past each other nonetheless. Mind testing the following?
>>>
>>> s/flag_non_call_exceptions/cfun->can_throw_non_call_exceptions/
>>>
>>
>> Why test either, since control_flow_insn_p has already done so?
> 
> Just to save an unnecessary call to add_dependence.
> 
> Although, come to think of it, it might not be unnecessary. The reason
> these two insns aren't already dependent on each other seems to be that
> they have opposite conditions, and I guess that might happen with
> conditional calls as well.

Ok, so Andreas has verified that the following fixes the problem on
ia64. Ok?


Bernd
PR rtl-optimization/49900
* sched-ebb.c (add_deps_for_risky_insns): Also add dependencies to
ensure basic blocks stay in the same order.

Index: gcc/sched-ebb.c
===
--- gcc/sched-ebb.c (revision 176879)
+++ gcc/sched-ebb.c (working copy)
@@ -397,6 +397,9 @@ add_deps_for_risky_insns (rtx head, rtx
  bb = BLOCK_FOR_INSN (insn);
  bb->aux = last_block;
  last_block = bb;
+ /* Ensure blocks stay in the same order.  */
+ if (last_jump)
+   add_dependence (insn, last_jump, REG_DEP_ANTI);
  last_jump = insn;
}
   else if (INSN_P (insn) && last_jump != NULL_RTX)


Re: [pph] Allocate string tables separately. (issue4843044)

2011-08-05 Thread Diego Novillo
On Fri, Aug 5, 2011 at 13:42,   wrote:

> Yep this fixes the problem I had with the strings being freed early.

Great.

> http://codereview.appspot.com/4843044/diff/1/gcc/cp/pph-streamer-in.c#newcode157
> gcc/cp/pph-streamer-in.c:157: memcpy (new_strtab, strtab, strtab_size);
> I don't think we need to memcpy, to be more efficient instead we can
> just change the way stream->encoder.r.file_data is read to only read the
> pph_file_header + body into it, and fread the strtab straight into
> new_strtab.
>
> This implies more logic when reading, but is potentially more efficient.

Yeah, I thought about that, but I didn't want to make the file reading
logic more convoluted than it already is.  Maybe we can do that at
some later point.  And I think that the multiple read operations may
in fact be slower than memcpy'ing, but I didn't really try that.


Diego.


[patch, ia64] Fix unaligned accesses on IA64 from dwarf2out.c

2011-08-05 Thread Steve Ellcey
Some recent changes in dwarf2out.c have caused GCC to generate unaligned
data traps on IA64 Linux.  In looking a this I tracked it down to
md5_read_ctx in libiberty, which is called by md5_finish_ctx, which in
turn is called by various routines in dwarf2out.c.

md5_read_ctx has a comment that the buffer must be 32 bit aligned but
there is nothing in dwarf2out.c to enforce this alignment to the
checksum buffer passed in to md5_finish_ctx.  I looked at calls to
md5_finish_ctx in fold-const.c to see why these didn't seem to have a
problem and noticed that the buffers used were always declared after the
md5_ctx structure and I think that 'accidentaly' got everything aligned
correctly.  If I do the same thing on the three buffer declarations in
dwarf2out.c the misaligned messages go away and things work fine.

Obviously this isn't a perfect fix, it is relying on how GCC is laying
out local variables which isn't gauranteed, but it fixes the problem and
I thought I would see if I could get approval for this simple fix or if
people think we need a more complete fix.  If we need a better fix, what
should I do?  It doesn't look like we use the alignment attribute in the
GCC code anywhere.  I could change the type of the checksum buffer from an
array of unsigned char to something that has a stronger alignment
requirement, but that would probably require a number of casts be added
where the checksum variable is used.

So, can I get someone to approve this simple, if imperfect, patch?
Tested on IA64 Linux.

Steve Ellcey
s...@cup.hp.com


2011-08-05  Steve Ellcey  

* dwarf2out.c (generate_type_signature): Change decl order to force
alignment.
(compute_section_prefix): 
(optimize_macinfo_range): Ditto.


Index: dwarf2out.c
===
--- dwarf2out.c (revision 177422)
+++ dwarf2out.c (working copy)
@@ -6369,8 +6369,8 @@ generate_type_signature (dw_die_ref die,
 {
   int mark;
   const char *name;
-  unsigned char checksum[16];
   struct md5_ctx ctx;
+  unsigned char checksum[16];
   dw_die_ref decl;
 
   name = get_AT_string (die, DW_AT_name);
@@ -6602,8 +6602,8 @@ compute_section_prefix (dw_die_ref unit_
   char *name = XALLOCAVEC (char, strlen (base) + 64);
   char *p;
   int i, mark;
-  unsigned char checksum[16];
   struct md5_ctx ctx;
+  unsigned char checksum[16];
 
   /* Compute the checksum of the DIE, then append part of it as hex digits to
  the name filename of the unit.  */
@@ -20662,8 +20662,8 @@ optimize_macinfo_range (unsigned int idx
 {
   macinfo_entry *first, *second, *cur, *inc;
   char linebuf[sizeof (HOST_WIDE_INT) * 3 + 1];
-  unsigned char checksum[16];
   struct md5_ctx ctx;
+  unsigned char checksum[16];
   char *grp_name, *tail;
   const char *base;
   unsigned int i, count, encoded_filename_len, linebuf_len;


Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

2011-08-05 Thread Mikael Morin
On Friday 05 August 2011 19:30:49 Janus Weil wrote:
> Hi Mikael,
> 
> >> The extra
> >> argument controls whether we check variable symbols for equality or
> >> just their names. For the overriding checks it is sufficient to check
> >> for names, because the arguments of the overriding procedure are
> >> required to have the same names as in the base procedure.
> > 
> > Unless you extend the flag thing to all the children function of
> > gfc_dep_compare_expr (there are zillions of them), it is preferable IMO
> > to make the diagnostic a warning, as identical expressions could be
> > missed.
> 
> Well, it would not be really satisfying to degrade the error to a
> warning, knowing it may be wrong sometimes. So I think one should
> rather fix this, which I think is not as hard as you suggest:
> gfc_dep_compare_expr doesn't exactly have "zillions" of children, but
> just two AFAICS:
> 
>  * gfc_are_identical_variables
gfc_are_identical_variables pulls in identical_array_ref too.
identical_array_ref can pull check_section_vs_section which needs 
gfc_is_same_range. ;-)

>  * gfc_dep_compare_functions
>  
> Apart from those two, it is highly recursive and mostly calls itself,
> where the argument is passed on already. 
Yes, OK there are not zillions of them (I thought almost all of dependency.c 
was pulled in).

> So I think it's feasible to
> add the extra argument to the above two functions, too (unless anyone
> has a better idea).
I still think that there could be some other cases that gfc_dep_compare_expr 
could possibly miss; but they are corner cases if functions and variables refs 
are handled, so an error is IMO OK then. We can wait a bug report to popup 
about it before deciding to downgrade to a warning. 

Mikael



Re: [pph] Add initial support for including nested pph images (issue4847044)

2011-08-05 Thread Gabriel Charette
On Fri, Aug 5, 2011 at 9:42 AM, Diego Novillo  wrote:
> On Thu, Aug 4, 2011 at 17:47,   wrote:
>> So if I understand correctly, the reference system doesn't work yet, you
>> just put out the design in this patch and you'll fill up functionality
>> in an upcoming patch so that's it's clearer what you're adding?
>
> Right, the 'if (0)' in pph_in_includes() disables support for it.
>
>> http://codereview.appspot.com/4847044/diff/1/gcc/cp/pph-streamer-in.c
>> File gcc/cp/pph-streamer-in.c (right):
>>
>> http://codereview.appspot.com/4847044/diff/1/gcc/cp/pph-streamer-in.c#newcode1491
>> gcc/cp/pph-streamer-in.c:1491: pph_add_include (stream);
>> does this mean the included pph has the include information for all of
>> the headers in it's transitive closure? i.e. we don't need to load child
>> information of a child? if so, isn't this bad from a dependency point of
>> view?
>
> Hmm?  Each header knows what other images it includes, so before
> reading its own content it reads the contents from the others.  The
> dependencies don't change.  The parent will not have the physical
> representation of the ASTs from the children, just references to them.
>

What I mean is if you have the following include structure A.c -> B.h
-> C.h -> D.h

Would B.h hold references to both C.h and D.h or only to C which in
turn knows about D?

From what I understood it seemed like all of the children in the
transitive closure of B will be referenced in B and that B will not
need to look at references in C when we read it (which is great from
an I/O standpoint, but maybe not from a dependency point of view? just
trying to understand the design)


>> http://codereview.appspot.com/4847044/diff/1/gcc/cp/pph.c
>> File gcc/cp/pph.c (right):
>>
>> http://codereview.appspot.com/4847044/diff/1/gcc/cp/pph.c#newcode164
>> gcc/cp/pph.c:164: if (pph_out_file != NULL)
>> shouldn't you use your new pph_enabled_p function here?
>
> No.  I need to know whether we are *creating* a PPH image.  Perhaps I
> should add a different predicate.
>

Ah ok I see, ya perhaps another inline function could clarify..

>> http://codereview.appspot.com/4847044/diff/1/gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc
>> File gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc (right):
>>
>> http://codereview.appspot.com/4847044/diff/1/gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc#newcode1
>> gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc:1: /* { dg-options "-O
>> -Wno-psabi -mtune=generic" } */
>> Is this related to the rest of the changes in this patch? I don't see it
>> mentioned in your patch comments
>
> Gah.  I was going to commit this separately but forgot.  Sorry about that.
>
K, why does this fix the test? seems weird that we had an infinite
loop before and changing the flags gets rid of it?

Thanks,
Gab


[pph] small multi-pph tests (issue4810074)

2011-08-05 Thread Lawrence Crowl
This patch ads a bunch of small tests for multi-pph includes.

Tested on x64.


Index: gcc/testsuite/ChangeLog.pph

2011-08-04  Lawrence Crowl  

* g++.dg/pph/README: Add new file types.
* g++.dg/pph/a0expinstinl.h: New.
* g++.dg/pph/a0expinstnin.h: New.
* g++.dg/pph/a0inline.h: New.
* g++.dg/pph/a0keyed.h: New.
* g++.dg/pph/a0keyno.h: New.
* g++.dg/pph/a0noninline.h: New.
* g++.dg/pph/a0nontrivinit.h: New.
* g++.dg/pph/a0rawstruct.h: New.
* g++.dg/pph/a0rtti.h: New.
* g++.dg/pph/a0template.h: New.
* g++.dg/pph/a0tmplclass.h: New.
* g++.dg/pph/a0typedef.h: New.
* g++.dg/pph/a0variables1.h: New.
* g++.dg/pph/a0variables2.h: New.
* g++.dg/pph/c0inline1.h: New.
* g++.dg/pph/c0inline2.h: New.
* g++.dg/pph/c0rawstruct1.h: New.
* g++.dg/pph/c0rawstruct2.h: New.
* g++.dg/pph/c0typedef1.h: New.
* g++.dg/pph/c0typedef2.h: New.
* g++.dg/pph/c0variables.h: Contents to a0variables.h.
Renamed to c0variables1.h.
* g++.dg/pph/c0variables1.h: New.
* g++.dg/pph/c0variables2.h: New.
* g++.dg/pph/c0variables3.h: New.
* g++.dg/pph/c0variables4.h: New.
* g++.dg/pph/c1variables.cc: Handle renaming.
* g++.dg/pph/c3rawstruct.cc: New.
* g++.dg/pph/c3rawstruct.s: New.
* g++.dg/pph/c3typedef.cc: New.
* g++.dg/pph/c3variables.cc: New.
* g++.dg/pph/c4inline.cc: New.
* g++.dg/pph/e0noninline1.h: New.
* g++.dg/pph/e0noninline2.h: New.
* g++.dg/pph/e4noninline.cc: New.
* g++.dg/pph/e4variables.cc: New.
* g++.dg/pph/pph.exp: Add FIXME.
* g++.dg/pph/x0keyed1.h: New.
* g++.dg/pph/x0keyed2.h: New.
* g++.dg/pph/x0keyno1.h: New.
* g++.dg/pph/x0keyno2.h: New.
* g++.dg/pph/x0nontrivinit.h: Contents to a0nontrivinit.h.
Renamed to x0nontrivinit1.h.
* g++.dg/pph/x0nontrivinit1.h: Renamed from x0nontrivinit.h.
* g++.dg/pph/x0nontrivinit2.h: New.
* g++.dg/pph/x0template.h: Contents to a0template.h.
Renamed to x0template1.h.
* g++.dg/pph/x0template1.h: Renamed from x0template.
* g++.dg/pph/x0template2.h: New.
* g++.dg/pph/x0tmplclass.h: Contents to a0tmplclass.h.
Renamed to x0tmplclass1.h.
* g++.dg/pph/x0tmplclass1.h: Renamed from x0tmplclass.h.
* g++.dg/pph/x0tmplclass2.h: New.
* g++.dg/pph/x1keyed.cc: New.
* g++.dg/pph/x1keyno.cc: New.
* g++.dg/pph/x1nontrivinit.cc: Handle renaming.
* g++.dg/pph/x1template.cc: Handle renaming.
* g++.dg/pph/x1tmplclass.cc: Handle renaming.
* g++.dg/pph/x1variables.h: Handle renaming.
* g++.dg/pph/x4keyed.cc: New.
* g++.dg/pph/x4keyno.cc: New.
* g++.dg/pph/x4template.cc: New.
* g++.dg/pph/x5rtti1.h: New.
* g++.dg/pph/x5rtti2.h: New.
* g++.dg/pph/x6rtti.cc: New.
* g++.dg/pph/x7rtti.cc: New.
* g++.dg/pph/z0expinstinl1.h: New.
* g++.dg/pph/z0expinstinl2.h: New.
* g++.dg/pph/z0expinstnin1.h: New.
* g++.dg/pph/z0expinstnin2.h: New.
* g++.dg/pph/z4expinstinl.cc: New.
* g++.dg/pph/z4expinstnin.cc: New.
* g++.dg/pph/z4nontrivinit.cc: New.


Index: gcc/testsuite/g++.dg/pph/z0expinstnin1.h
===
--- gcc/testsuite/g++.dg/pph/z0expinstnin1.h(revision 0)
+++ gcc/testsuite/g++.dg/pph/z0expinstnin1.h(revision 0)
@@ -0,0 +1,6 @@
+#ifndef X0EXPINSTNIN1_H
+#define X0EXPINSTNIN1_H
+
+#include "a0expinstnin.h"
+
+#endif
Index: gcc/testsuite/g++.dg/pph/e0noninline2.h
===
--- gcc/testsuite/g++.dg/pph/e0noninline2.h (revision 0)
+++ gcc/testsuite/g++.dg/pph/e0noninline2.h (revision 0)
@@ -0,0 +1,5 @@
+#ifndef E0NONINLINE2_H
+#define E0NONINLINE2_H
+#include "a0noninline.h"
+int h() { struct S s = { 3, 4 }; return f(s) * 3; }
+#endif
Index: gcc/testsuite/g++.dg/pph/x0tmplclass.h
===
--- gcc/testsuite/g++.dg/pph/x0tmplclass.h  (revision 177422)
+++ gcc/testsuite/g++.dg/pph/x0tmplclass.h  (working copy)
@@ -1,17 +0,0 @@
-#ifndef X0TMPLCLASS_H
-#define X0TMPLCLASS_H
-template< typename T >
-struct wrapper {
-  T value;
-  static T cache;
-};
-
-template< typename T >
-T wrapper::cache = 3;
-
-template<>
-struct wrapper {
-  int value;
-  static int cache;
-};
-#endif
Index: gcc/testsuite/g++.dg/pph/x0tmplclass2.h
===
--- gcc/testsuite/g++.dg/pph/x0tmplclass2.h (revision 0)
+++ gcc/testsuite/g++.dg/pph/x0tmplclass2.h (revision 0)
@@ -0,0 +1,4 @@
+#ifndef X0TMPLCLASS2_H
+#define X0TMPLCLASS2_H
+#include "a0tmplclass.h"
+#endif
Index: gcc/testsuite/g++.dg/pph/c0rawstruct1.h

Re: Remove line 0 hack in cp/decl.c (issue4835047)

2011-08-05 Thread Gabriel Charette
On Fri, Aug 5, 2011 at 10:37 AM, Tom Tromey  wrote:
>> "Gabriel" == Gabriel Charette  writes:
>
> Gabriel> This hack, has described in more details in the email labeled
> Gabriel> "Line 0 Hack??", was now causing problem when serializing the
> Gabriel> line_table in pph.
>
> I think you do have to handle location 0 somehow.
> This is UNKNOWN_LOCATION, referred to widely in the sources.
>

I do handle location 0, the problem is that this specific call to
linemap_line_start was made late, after all linemap entries had exited
(LC_LEAVE), and thus this would create a new LC_ENTER in the table and
the parsing would finish with line_table->depth == 1 (instead of 0 as
expected)... This bug never really showed up because at that point no
one is trying to add new entries to the line_table, it only shows up
now that we're trying to serialize the line_table.

> Gabriel> 2011-08-01  Gabriel Charette  
> Gabriel>        * decl.c (finish_function): Remove unecessary line 0 hack.
>
> Now that -Wunreachable-code is gone, I doubt this code is even
> theoretically relevant.  So, while I can't approve or reject this patch,
> it seems reasonable to me.
>

Ok Thanks,
Gabriel


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-05 Thread Mikael Morin
On Wednesday 03 August 2011 15:32:45 Rainer Orth wrote:
> This is the revised/updated version of the patch originally posted at
> 
>   [build] Move unwinder to toplevel libgcc
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html
> 
> and reposted as CFT at
> 
>   http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00201.html
> 
> It should incorporate all review comments and a few errors I've noticed
> during final review have been corrected.
> 
> I've received approval for the Darwin bits, Steve successfully tested on
> HP-UX/IA64 and Linux/IA64 at least bootstrapped.  VMS/IA64 approval has
> been given conditional on the approval of the other IA64 bits.  I've
> also received approval for the libjava parts.
> 
> Bootstrapped without regressions (together with the next two, to be
> resubmitted shortly: fp-bit and soft-fp moves) on
> x86_64-unknown-linux-gnu.
> 
> i386-pc-solaris2.10, sparc-sun-solaris2.11, alpha-dec-osf5.1b,
> mips-sgi-irix6.5 and i386-apple-darwin9.8.0 bootstraps in progress.
> powerpc-apple-darwin9.8.0 currently broken (SIGBUS compiling
> c-family/c-pretty-print.c and cp/call.c).
> 
> How should we proceed with this patch, especially given the quite
> moderate comments from most affected target maintainers?
> 
> Thanks.
>   Rainer

Hello, 

I suppose it is this patch that breaks bootstrap on 86_64-unknown-freebsd8.2:
/home/mik/gcc4x/src/gcc/crtstuff.c:64:28: fatal error: unwind-dw2-fde.h: No 
such file or directory

Fixed by the the following pat^Whack
Index: crtstuff.c
===
--- crtstuff.c  (révision 177469)
+++ crtstuff.c  (copie de travail)
@@ -61,7 +61,7 @@
 #include "tsystem.h"
 #include "coretypes.h"
 #include "tm.h"
-#include "unwind-dw2-fde.h"
+#include "../libgcc/unwind-dw2-fde.h"
 
 #ifndef FORCE_CODE_SECTION_ALIGN
 # define FORCE_CODE_SECTION_ALIGN

There is probably something better, but I have no clue.

Mikael


Re: Correct fix for scheduler bug PR11320

2011-08-05 Thread Richard Henderson
On 08/05/2011 10:41 AM, Bernd Schmidt wrote:
>   PR rtl-optimization/49900
>   * sched-ebb.c (add_deps_for_risky_insns): Also add dependencies to
>   ensure basic blocks stay in the same order.

Ok.


r~


Re: [pph] Add initial support for including nested pph images (issue4847044)

2011-08-05 Thread Diego Novillo
On Fri, Aug 5, 2011 at 14:10, Gabriel Charette  wrote:
> On Fri, Aug 5, 2011 at 9:42 AM, Diego Novillo  wrote:
>> On Thu, Aug 4, 2011 at 17:47,   wrote:
>>> So if I understand correctly, the reference system doesn't work yet, you
>>> just put out the design in this patch and you'll fill up functionality
>>> in an upcoming patch so that's it's clearer what you're adding?
>>
>> Right, the 'if (0)' in pph_in_includes() disables support for it.
>>
>>> http://codereview.appspot.com/4847044/diff/1/gcc/cp/pph-streamer-in.c
>>> File gcc/cp/pph-streamer-in.c (right):
>>>
>>> http://codereview.appspot.com/4847044/diff/1/gcc/cp/pph-streamer-in.c#newcode1491
>>> gcc/cp/pph-streamer-in.c:1491: pph_add_include (stream);
>>> does this mean the included pph has the include information for all of
>>> the headers in it's transitive closure? i.e. we don't need to load child
>>> information of a child? if so, isn't this bad from a dependency point of
>>> view?
>>
>> Hmm?  Each header knows what other images it includes, so before
>> reading its own content it reads the contents from the others.  The
>> dependencies don't change.  The parent will not have the physical
>> representation of the ASTs from the children, just references to them.
>>
>
> What I mean is if you have the following include structure A.c -> B.h
> -> C.h -> D.h
>
> Would B.h hold references to both C.h and D.h or only to C which in
> turn knows about D?

Ah, no.  B.pph only knows about C.pph.  When we load C.pph, it then
proceeds to load D.pph.
So, we shouldn't be loading D.pph twice when including B.pph.  I think
this now doesn't work and we will try to load D twice (which is a
bug).


>> Gah.  I was going to commit this separately but forgot.  Sorry about that.
>>
> K, why does this fix the test? seems weird that we had an infinite
> loop before and changing the flags gets rid of it?

It wasn't an infinite loop but an ICE in the tree caches.  The
different options were producing different ASTs, so the tree cache had
different trees on write-out and read-in.


Diego.


Re: [patch, ia64] Fix unaligned accesses on IA64 from dwarf2out.c

2011-08-05 Thread Andreas Schwab
Steve Ellcey  writes:

> Obviously this isn't a perfect fix, it is relying on how GCC is laying
> out local variables which isn't gauranteed, but it fixes the problem and
> I thought I would see if I could get approval for this simple fix or if
> people think we need a more complete fix.

Why not making it a union?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: [patch, ia64] Fix unaligned accesses on IA64 from dwarf2out.c

2011-08-05 Thread Richard Henderson
On 08/05/2011 10:54 AM, Steve Ellcey wrote:
> -  unsigned char checksum[16];
>struct md5_ctx ctx;
> +  unsigned char checksum[16];

How about

  struct md5_data
  {
struct md5_ctx ctx;
unsigned char checksum[16];
  };

  struct md5_data md5;

with the structure definition somewhere interesting?
If no where else, just dwarf2out.c file scope.


r~


[RFC PATCH, i386]: Allow zero_extended addresses (+ problems with reload and offsetable address, "o" constraint)

2011-08-05 Thread Uros Bizjak
Hello!

Attached patch introduces generation of addr32 prefixed addresses,
mainly intended to merge ZERO_EXTRACTed LEA calculations into address.
 After fixing various inconsistencies with "o" constraints, the patch
works surprisingly well (in its current form fixes all reported
problems in the PR [1]), but one problem remains w.r.t. handling of
"o" constraint.

Patched gcc ICEs on gcc.dg/torture/pr47744-2.c with:

$ ~/gcc-build-fast/gcc/cc1 -O2 -mx32 -std=gnu99 -quiet pr47744-2.c
pr47744-2.c: In function ‘matmul_i16’:
pr47744-2.c:40:1: error: insn does not satisfy its constraints:
(insn 116 66 67 4 (set (reg:TI 0 ax)
(mem:TI (zero_extend:DI (plus:SI (reg:SI 4 si [orig:114
ivtmp.26 ] [114])
(reg:SI 5 di [orig:101 dest_y ] [101]))) [6
MEM[base: dest_y_18, index: ivtmp.26_53, offset: 0B]+0 S16 A128]))
pr47744-2.c:34 60 {*movti_internal_rex64}
 (nil))
pr47744-2.c:40:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
...

... due to the fact that the address is not offsetable, and plus
((zero_extend (...)) (const_int ...)) gets rejected from
ix86_legitimate_address_p.

However, the section "16.8.1 Simple Constraints" of the documentation claims:

--quote--
   * A nonoffsettable memory reference can be reloaded by copying the
 address into a register.  So if the constraint uses the letter
 `o', all memory references are taken care of.
--/quote--

As I read this sentence, the RTX is forced into a temporary register,
and reload tries to satisfy "o" constraint with plus ((reg ...)
(const_int ...)), as said at the introduction of "o" constraint a
couple of pages earlier. Unfortunately, this does not seem to be the
case.

Is there anything wrong with my approach, or is there something wrong in reload?

2011-08-05  Uros Bizjak  

PR target/49781
* config/i386/i386.c (ix86_decompose_address): Allow zero-extended
SImode addresses.
(ix86_print_operand_address): Handle zero-extended addresses.
(memory_address_length): Add length of addr32 prefix for
zero-extended addresses.
* config/i386/predicates.md (lea_address_operand): Reject
zero-extended operands.

Patch is otherwise bootstrapped and tested on x86_64-pc-linux-gnu
{,-m32} without regressions.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49781

Thanks,
Uros.
Index: config/i386/predicates.md
===
--- config/i386/predicates.md   (revision 177456)
+++ config/i386/predicates.md   (working copy)
@@ -801,6 +801,10 @@
   struct ix86_address parts;
   int ok;
 
+  /*  LEA handles zero-extend by itself.  */
+  if (GET_CODE (op) == ZERO_EXTEND)
+return false;
+
   ok = ix86_decompose_address (op, &parts);
   gcc_assert (ok);
   return parts.seg == SEG_DEFAULT;
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 177456)
+++ config/i386/i386.c  (working copy)
@@ -11146,6 +11146,14 @@ ix86_decompose_address (rtx addr, struct ix86_addr
   int retval = 1;
   enum ix86_address_seg seg = SEG_DEFAULT;
 
+  /* Allow zero-extended SImode addresses,
+ they will be emitted with addr32 prefix.  */
+  if (TARGET_64BIT
+  && GET_CODE (addr) == ZERO_EXTEND
+  && GET_MODE (addr) == DImode
+  && GET_MODE (XEXP (addr, 0)) == SImode)
+addr = XEXP (addr, 0);
+ 
   if (REG_P (addr))
 base = addr;
   else if (GET_CODE (addr) == SUBREG)
@@ -14163,9 +14171,13 @@ ix86_print_operand_address (FILE *file, rtx addr)
 }
   else
 {
-  /* Print DImode registers on 64bit targets to avoid addr32 prefixes.  */
-  int code = TARGET_64BIT ? 'q' : 0;
+  int code = 0;
 
+  /* Print SImode registers for zero-extended addresses to force
+addr32 prefix.  Otherwise print DImode registers to avoid it.  */
+  if (TARGET_64BIT)
+   code = (GET_CODE (addr) == ZERO_EXTEND) ? 'l' : 'q';
+
   if (ASSEMBLER_DIALECT == ASM_ATT)
{
  if (disp)
@@ -21776,7 +21788,8 @@ assign_386_stack_local (enum machine_mode mode, en
 }
 
 /* Calculate the length of the memory address in the instruction
-   encoding.  Does not include the one-byte modrm, opcode, or prefix.  */
+   encoding.  Includes addr32 prefix, does not include the one-byte modrm,
+   opcode, or other prefixes.  */
 
 int
 memory_address_length (rtx addr)
@@ -21803,8 +21816,10 @@ memory_address_length (rtx addr)
   base = parts.base;
   index = parts.index;
   disp = parts.disp;
-  len = 0;
 
+  /* Add length of addr32 prefix.  */
+  len = (GET_CODE (addr) == ZERO_EXTEND);
+
   /* Rule of thumb:
- esp as the base always wants an index,
- ebp as the base always wants a displacement,


C++ PATCH to allow VLAs with C++0x auto

2011-08-05 Thread Jason Merrill
Paolo asked for GCC to allow deduction of auto from a variable-length 
array.  Since auto doesn't have the issues involved with normal template 
deduction from VLAs (namely, the type not being link-time constant), 
this seems reasonable to me.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 002b9c9ad8b14999fa87c65f3ccdce772086edd8
Author: Jason Merrill 
Date:   Thu Aug 4 11:48:40 2011 -0400

	* pt.c (unify) [TEMPLATE_TYPE_PARM]: Allow VLA for C++0x 'auto'.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 571da6d..10fdced 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -15932,10 +15932,11 @@ unify (tree tparms, tree targs, tree parm, tree arg, int strict,
 	 that were talking about variable-sized arrays (like
 	 `int[n]'), rather than arrays of unknown size (like
 	 `int[]').)  We'll get very confused by such a type since
-	 the bound of the array will not be computable in an
-	 instantiation.  Besides, such types are not allowed in
-	 ISO C++, so we can do as we please here.  */
-	  if (variably_modified_type_p (arg, NULL_TREE))
+	 the bound of the array is not constant, and therefore
+	 not mangleable.  Besides, such types are not allowed in
+	 ISO C++, so we can do as we please here.  We do allow
+	 them for 'auto' deduction, since that isn't ABI-exposed.  */
+	  if (!is_auto (parm) && variably_modified_type_p (arg, NULL_TREE))
 	return unify_vla_arg (explain_p, arg);
 
 	  /* Strip typedefs as in convert_template_argument.  */
diff --git a/gcc/testsuite/g++.dg/ext/vla11.C b/gcc/testsuite/g++.dg/ext/vla11.C
new file mode 100644
index 000..8f3be9e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/vla11.C
@@ -0,0 +1,8 @@
+// Test that auto works with VLAs.
+// { dg-options -std=c++0x }
+
+void bar(int n)
+{
+  float loc2[n];
+  auto&& range = loc2;
+}


C++ PATCHes for c++/47453 (rejecting ({...}) for non-class types)

2011-08-05 Thread Jason Merrill
DR 1214 established that an initializer of the form ({something}) is 
only valid for an object of class type.  This patch implements that, 
though I've only made it a pedwarn as there is some uncertainty about 
whether this is actually what we want.  I've also split the patch into 
two to make it easier to revert if that turns out not to be the case; 
the first part is a cleanup which is correct either way.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 93e7eecc08c50085336928d8093baff55103d176
Author: Jason Merrill 
Date:   Thu Aug 4 17:32:17 2011 -0400

	* init.c (perform_member_init): Always build_aggr_init
	for a class member with an explicit mem-initializer.

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 31171cf..d9e475e 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -547,7 +547,8 @@ perform_member_init (tree member, tree init)
 	  finish_expr_stmt (init);
 	}
 }
-  else if (type_build_ctor_call (type))
+  else if (type_build_ctor_call (type)
+	   || (init && CLASS_TYPE_P (strip_array_types (type
 {
   if (TREE_CODE (type) == ARRAY_TYPE)
 	{
commit ffa8f76324849e367023a06b0ae663a798db64ad
Author: Jason Merrill 
Date:   Thu Aug 4 17:32:32 2011 -0400

	PR c++/47453
	* typeck.c (build_x_compound_expr_from_list): Also complain
	about ({...}).

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index f53deb9..a1f6761 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5470,6 +5470,16 @@ build_x_compound_expr_from_list (tree list, expr_list_kind exp,
 {
   tree expr = TREE_VALUE (list);
 
+  if (BRACE_ENCLOSED_INITIALIZER_P (expr)
+  && !CONSTRUCTOR_IS_DIRECT_INIT (expr))
+{
+  if (complain & tf_error)
+	pedwarn (EXPR_LOC_OR_HERE (expr), 0, "list-initializer for "
+		 "non-class type must not be parenthesized");
+  else
+	return error_mark_node;
+}
+
   if (TREE_CHAIN (list))
 {
   if (complain & tf_error)
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist13.C b/gcc/testsuite/g++.dg/cpp0x/initlist13.C
index 9ed6c74..bc5ee2c 100644
--- a/gcc/testsuite/g++.dg/cpp0x/initlist13.C
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist13.C
@@ -4,5 +4,5 @@
 
 #include 
 
-__complex__ int i ({0});
-std::complex i2 ({0});
+__complex__ int i {0};
+std::complex i2 {0};
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist50.C b/gcc/testsuite/g++.dg/cpp0x/initlist50.C
index ef4e72c..5cb23e2 100644
--- a/gcc/testsuite/g++.dg/cpp0x/initlist50.C
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist50.C
@@ -8,7 +8,7 @@ struct A2 {
 
 template  struct B {
   T ar[1];
-  B(T t):ar({t}) {}
+  B(T t):ar{t} {}
 };
 
 int main(){
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist56.C b/gcc/testsuite/g++.dg/cpp0x/initlist56.C
new file mode 100644
index 000..862b41b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist56.C
@@ -0,0 +1,37 @@
+// PR c++/47453
+// { dg-options "-std=c++0x -pedantic-errors" }
+
+// invalid
+int a({0});			// { dg-error "" }
+
+// invalid
+int const &b({0});		// { dg-error "" }
+
+// invalid
+struct A1 { int a[2]; A1(); };
+A1::A1():a({1, 2}) { }		// { dg-error "" }
+
+struct A { explicit A(int, int); A(int, long); };
+
+// invalid
+A c({1, 2});			// { dg-error "" }
+
+// valid (by copy constructor).
+A d({1, 2L});
+
+// valid
+A e{1, 2};
+
+#include 
+
+struct B {
+  template
+  B(std::initializer_list, T ...);
+};
+
+// invalid (the first phase only considers init-list ctors)
+// (for the second phase, no constructor is viable)
+B f{1, 2, 3};			// { dg-error "" }
+
+// valid (T deduced to <>).
+B g({1, 2, 3});


C++ PATCH for c++/49983 (range-for/auto regression)

2011-08-05 Thread Jason Merrill

We can only do range for deduction if the range expression is non-dependent.

Tested x86_64-pc-linux-gnu, applied to trunk.
commit 2515fd89aeb268d395242d6ef3137da7119fdce8
Author: Jason Merrill 
Date:   Fri Aug 5 10:16:58 2011 -0400

	PR c++/49983
	* parser.c (cp_parser_range_for): Only do auto deduction in
	template if the range is non-dependent.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 9b3e56d..84b8c60 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -8679,7 +8679,8 @@ cp_parser_range_for (cp_parser *parser, tree scope, tree init, tree range_decl)
 {
   stmt = begin_range_for_stmt (scope, init);
   finish_range_for_decl (stmt, range_decl, range_expr);
-  do_range_for_auto_deduction (range_decl, range_expr);
+  if (!type_dependent_expression_p (range_expr))
+	do_range_for_auto_deduction (range_decl, range_expr);
 }
   else
 {
diff --git a/gcc/testsuite/g++.dg/cpp0x/range-for21.C b/gcc/testsuite/g++.dg/cpp0x/range-for21.C
new file mode 100644
index 000..07bb95f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/range-for21.C
@@ -0,0 +1,8 @@
+// PR c++/49983
+// { dg-options -std=c++0x }
+
+template 
+void f(T t)
+{
+  for (auto v : t);
+}


C++ PATCH for c++/49812 (type of i++)

2011-08-05 Thread Jason Merrill
If i is a volatile int, i++ is an int rvalue.  The compiler was treating 
it as a volatile int rvalue, of which there is no such thing.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit f0049ff597cdeb2437cc9e39f633843bdb12bcba
Author: Jason Merrill 
Date:   Fri Aug 5 11:57:30 2011 -0400

	PR c++/49812
	* typeck.c (cp_build_unary_op) [POSTINCREMENT_EXPR]: Strip cv-quals.

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index ab08eae..f53deb9 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5220,6 +5220,9 @@ cp_build_unary_op (enum tree_code code, tree xarg, int noconvert,
 	  }
 	val = boolean_increment (code, arg);
 	  }
+	else if (code == POSTINCREMENT_EXPR || code == POSTDECREMENT_EXPR)
+	  /* An rvalue has no cv-qualifiers.  */
+	  val = build2 (code, cv_unqualified (TREE_TYPE (arg)), arg, inc);
 	else
 	  val = build2 (code, TREE_TYPE (arg), arg, inc);
 
diff --git a/gcc/testsuite/g++.dg/overload/rvalue2.C b/gcc/testsuite/g++.dg/overload/rvalue2.C
new file mode 100644
index 000..8a2290d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/overload/rvalue2.C
@@ -0,0 +1,11 @@
+// PR c++/49812
+// The call should choose the second f because i++ is an int rvalue.
+
+template  void f(const volatile T& t) { t.i; }
+template  void f(const T&);
+
+int main()
+{
+  volatile int i = 0;
+  f(i++);
+}


PATCH to fix build failure on config/i386/i386.c

2011-08-05 Thread Jason Merrill

Kai's patch

2011-08-04  Kai Tietz  

* config/i386/i386.c (setup_incoming_varargs_ms_64): Set
ix86_varargs_gpr_size and ix86_varargs_fpr_size to zero.

broke build for me, as it put statements before the declarations at the 
beginning of the function.  I'm checking this in to restore the build.
commit bc18469d6d781828ce640fc2eb57c7c6eb1dc330
Author: Jason Merrill 
Date:   Fri Aug 5 10:24:16 2011 -0400

	* config/i386/i386.c (setup_incoming_varargs_ms_64): Move
	declarations to beginning of function.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 5d995ab..f1d6430 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -7507,14 +7507,14 @@ setup_incoming_varargs_64 (CUMULATIVE_ARGS *cum)
 static void
 setup_incoming_varargs_ms_64 (CUMULATIVE_ARGS *cum)
 {
+  alias_set_type set = get_varargs_alias_set ();
+  int i;
+
   /* Reset to zero, as there might be a sysv vaarg used
  before.  */
   ix86_varargs_gpr_size = 0;
   ix86_varargs_fpr_size = 0;
   
-  alias_set_type set = get_varargs_alias_set ();
-  int i;
-
   for (i = cum->regno; i < X86_64_MS_REGPARM_MAX; i++)
 {
   rtx reg, mem;


Re: [build] Move unwinder to toplevel libgcc (v2)

2011-08-05 Thread Paolo Bonzini
On Fri, Aug 5, 2011 at 20:18, Mikael Morin  wrote:
> I suppose it is this patch that breaks bootstrap on 86_64-unknown-freebsd8.2:
> /home/mik/gcc4x/src/gcc/crtstuff.c:64:28: fatal error: unwind-dw2-fde.h: No
> such file or directory
>
> Fixed by the the following pat^Whack
> Index: crtstuff.c
> ===
> --- crtstuff.c  (révision 177469)
> +++ crtstuff.c  (copie de travail)
> @@ -61,7 +61,7 @@
>  #include "tsystem.h"
>  #include "coretypes.h"
>  #include "tm.h"
> -#include "unwind-dw2-fde.h"
> +#include "../libgcc/unwind-dw2-fde.h"
>
>  #ifndef FORCE_CODE_SECTION_ALIGN
>  # define FORCE_CODE_SECTION_ALIGN
>
> There is probably something better, but I have no clue.

Adding a -I flag?  I suppose that makes sense even if crtstuff is
moved soon to toplevel libgcc.

Paolo


[patch, fortran] PR 37721, warn about target > source in TRANSFER

2011-08-05 Thread Thomas Koenig

Hello world,

the attached patch fixes PR 37721 by moving the check for TRANSFER size 
mismatches to checking, away from simplification.  That means that it is 
possible to check character MOLDs whose size is constant, but which 
aren't constant themselves.


I added the extra argument to gfc_target_interpret_expr because for a 
TRANSFER, we want a binary copy and not a conversion between wide and

normal characters.

Regression-tested.  OK for trunk?

Thomas

2011-08-05  Thomas Koenig  

PR fortran/37221
* gfortran.h (gfc_calculate_transfer_sizes):  Add prototype.
* target-memory.h (gfc_target_interpret_expr):  Add boolean
argument wether to convert wide characters.
* target-memory.c (gfc_target_expr_size):  Also return length
of characters for non-constant expressions if these can be
determined from the cl.
(interpret_array):  Add argument for gfc_target_interpret_expr.
(gfc_interpret_derived):  Likewise.
(gfc_target_interpret_expr):  Likewise.
* check.c:  Include target-memory.h.
(gfc_calculate_transfer_sizes):  New function.
(gfc_check_transfer):  When -Wsurprising is in force, calculate
sizes and warn if result is larger than size (check moved from
gfc_simplify_transfer).
* simplify.c (gfc_simplify_transfer):  Use
gfc_calculate_transfer_sizes.  Remove warning.

2011-08-05  Thomas Koenig  

PR fortran/37221
* gfortran.dg/transfer_check_2.f90:  New test case.
Index: gfortran.h
===
--- gfortran.h	(Revision 176933)
+++ gfortran.h	(Arbeitskopie)
@@ -2884,6 +2884,8 @@ int gfc_dep_compare_expr (gfc_expr *, gfc_expr *);
 
 /* check.c */
 gfc_try gfc_check_same_strlen (const gfc_expr*, const gfc_expr*, const char*);
+gfc_try gfc_calculate_transfer_sizes (gfc_expr*, gfc_expr*, gfc_expr*,
+  size_t*, size_t*, size_t*);
 
 /* class.c */
 void gfc_add_component_ref (gfc_expr *, const char *);
Index: target-memory.c
===
--- target-memory.c	(Revision 176933)
+++ target-memory.c	(Arbeitskopie)
@@ -103,16 +103,20 @@ gfc_target_expr_size (gfc_expr *e)
 case BT_LOGICAL:
   return size_logical (e->ts.kind);
 case BT_CHARACTER:
-  if (e->expr_type == EXPR_SUBSTRING && e->ref)
-{
-  int start, end;
+  if (e->expr_type == EXPR_CONSTANT)
+	return size_character (e->value.character.length, e->ts.kind);
+  else if (e->ts.u.cl != NULL && e->ts.u.cl->length != NULL
+	   && e->ts.u.cl->length->expr_type == EXPR_CONSTANT
+	   && e->ts.u.cl->length->ts.type == BT_INTEGER)
+	{
+	  int length;
 
-  gfc_extract_int (e->ref->u.ss.start, &start);
-  gfc_extract_int (e->ref->u.ss.end, &end);
-  return size_character (MAX(end - start + 1, 0), e->ts.kind);
-}
+	  gfc_extract_int (e->ts.u.cl->length, &length);
+	  return size_character (length, e->ts.kind);
+	}
   else
-return size_character (e->value.character.length, e->ts.kind);
+	return 0;
+
 case BT_HOLLERITH:
   return e->representation.length;
 case BT_DERIVED:
@@ -330,7 +334,8 @@ interpret_array (unsigned char *buffer, size_t buf
 
   gfc_constructor_append_expr (&base, e, &result->where);
 
-  ptr += gfc_target_interpret_expr (&buffer[ptr], buffer_size - ptr, e);
+  ptr += gfc_target_interpret_expr (&buffer[ptr], buffer_size - ptr, e,
+	true);
 }
 
   result->value.constructor = base;
@@ -456,7 +461,7 @@ gfc_interpret_derived (unsigned char *buffer, size
   e = gfc_get_constant_expr (cmp->ts.type, cmp->ts.kind, &result->where); 
   c = gfc_constructor_append_expr (&result->value.constructor, e, NULL);
   c->n.component = cmp;
-  gfc_target_interpret_expr (buffer, buffer_size, e);
+  gfc_target_interpret_expr (buffer, buffer_size, e, true);
   e->ts.is_iso_c = 1;
   return int_size_in_bytes (ptr_type_node);
 }
@@ -506,7 +511,7 @@ gfc_interpret_derived (unsigned char *buffer, size
   gcc_assert (ptr % 8 == 0);
   ptr = ptr/8 + TREE_INT_CST_LOW (DECL_FIELD_OFFSET (cmp->backend_decl));
 
-  gfc_target_interpret_expr (&buffer[ptr], buffer_size - ptr, e);
+  gfc_target_interpret_expr (&buffer[ptr], buffer_size - ptr, e, true);
 }
 
   return int_size_in_bytes (type);
@@ -516,7 +521,7 @@ gfc_interpret_derived (unsigned char *buffer, size
 /* Read a binary buffer to a constant expression.  */
 int
 gfc_target_interpret_expr (unsigned char *buffer, size_t buffer_size,
-			   gfc_expr *result)
+			   gfc_expr *result, bool convert_widechar)
 {
   if (result->expr_type == EXPR_ARRAY)
 return interpret_array (buffer, buffer_size, result);
@@ -562,7 +567,7 @@ gfc_target_interpret_expr (unsigned char *buffer,
   break;
 }
 
-  if (result->ts.type == BT_CHARACTER)
+  if (result->ts.type == BT_CHARACTER && convert_wid

Re: [pph] small multi-pph tests (issue4810074)

2011-08-05 Thread Gabriel Charette
I now get the following test failure output after pulling this patch
(potentially from the almost concurrent checkin of my linetable
patch?)

I can send you my diff's if you need to compare.

FAIL: g++.dg/pph/c4inline.cc  (assembly comparison, sums 46031=>36250)
FAIL: g++.dg/pph/x1keyed.cc  (assembly comparison, sums 17458=>63070)
FAIL: g++.dg/pph/x1keyno.cc  (assembly comparison, sums 20949=>46318)
XPASS: g++.dg/pph/x4keyed.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x4keyed.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
FAIL: g++.dg/pph/x4keyno.cc  (assembly comparison, sums 64958=>17472)
FAIL: g++.dg/pph/x4template.cc  (assembly comparison, sums 23306=>52012)
XPASS: g++.dg/pph/x6rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x6rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
XPASS: g++.dg/pph/x7rtti.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
# of expected passes277
# of unexpected failures5
# of unexpected successes   45
# of expected failures  42

Gab

On Fri, Aug 5, 2011 at 11:15 AM, Lawrence Crowl  wrote:
> This patch ads a bunch of small tests for multi-pph includes.
>
> Tested on x64.
>
>
> Index: gcc/testsuite/ChangeLog.pph
>
> 2011-08-04  Lawrence Crowl  
>
>        * g++.dg/pph/README: Add new file types.
>        * g++.dg/pph/a0expinstinl.h: New.
>        * g++.dg/pph/a0expinstnin.h: New.
>        * g++.dg/pph/a0inline.h: New.
>        * g++.dg/pph/a0keyed.h: New.
>        * g++.dg/pph/a0keyno.h: New.
>        * g++.dg/pph/a0noninline.h: New.
>        * g++.dg/pph/a0nontrivinit.h: New.
>        * g++.dg/pph/a0rawstruct.h: New.
>        * g++.dg/pph/a0rtti.h: New.
>        * g++.dg/pph/a0template.h: New.
>        * g++.dg/pph/a0tmplclass.h: New.
>        * g++.dg/pph/a0typedef.h: New.
>        * g++.dg/pph/a0variables1.h: New.
>        * g++.dg/pph/a0variables2.h: New.
>        * g++.dg/pph/c0inline1.h: New.
>        * g++.dg/pph/c0inline2.h: New.
>        * g++.dg/pph/c0rawstruct1.h: New.
>        * g++.dg/pph/c0rawstruct2.h: New.
>        * g++.dg/pph/c0typedef1.h: New.
>        * g++.dg/pph/c0typedef2.h: New.
>        * g++.dg/pph/c0variables.h: Contents to a0variables.h.
>        Renamed to c0variables1.h.
>        * g++.dg/pph/c0variables1.h: New.
>        * g++.dg/pph/c0variables2.h: New.
>        * g++.dg/pph/c0variables3.h: New.
>        * g++.dg/pph/c0variables4.h: New.
>        * g++.dg/pph/c1variables.cc: Handle renaming.
>        * g++.dg/pph/c3rawstruct.cc: New.
>        * g++.dg/pph/c3rawstruct.s: New.
>        * g++.dg/pph/c3typedef.cc: New.
>        * g++.dg/pph/c3variables.cc: New.
>        * g++.dg/pph/c4inline.cc: New.
>        * g++.dg/pph/e0noninline1.h: New.
>        * g++.dg/pph/e0noninline2.h: New.
>        * g++.dg/pph/e4noninline.cc: New.
>        * g++.dg/pph/e4variables.cc: New.
>        * g++.dg/pph/pph.exp: Add FIXME.
>        * g++.dg/pph/x0keyed1.h: New.
>        * g++.dg/pph/x0keyed2.h: New.
>        * g++.dg/pph/x0keyno1.h: New.
>        * g++.dg/pph/x0keyno2.h: New.
>        * g++.dg/pph/x0nontrivinit.h: Contents to a0nontrivinit.h.
>        Renamed to x0nontrivinit1.h.
>        * g++.dg/pph/x0nontrivinit1.h: Renamed from x0nontrivinit.h.
>        * g++.dg/pph/x0nontrivinit2.h: New.
>        * g++.dg/pph/x0template.h: Contents to a0template.h.
>        Renamed to x0template1.h.
>        * g++.dg/pph/x0template1.h: Renamed from x0template.
>        * g++.dg/pph/x0template2.h: New.
>        * g++.dg/pph/x0tmplclass.h: Contents to a0tmplclass.h.
>        Renamed to x0tmplclass1.h.
>        * g++.dg/pph/x0tmplclass1.h: Renamed from x0tmplclass.h.
>        * g++.dg/pph/x0tmplclass2.h: New.
>        * g++.dg/pph/x1keyed.cc: New.
>        * g++.dg/pph/x1keyno.cc: New.
>        * g++.dg/pph/x1nontrivinit.cc: Handle renaming.
>        * g++.dg/pph/x1template.cc: Handle renaming.
>        * g++.dg/pph/x1tmplclass.cc: Handle renaming.
>        * g++.dg/pph/x1variables.h: Handle renaming.
>        * g++.dg/pph/x4keyed.cc: New.
>        * g++.dg/pph/x4keyno.cc: New.
>        * g++.dg/pph/x4templ

Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

2011-08-05 Thread Thomas Koenig

Hi Janus,


The patch is rather large, but most of it is just mechanical, due to
the fact that I added an extra argument to 'gfc_dep_compare_expr'. I
use this function to compare the string-length expressions of a
character-valued TBP and an overriding procedure (the standard
requires them to be equal).


This will likely introduce rejects-valid bugs.  For example, 
gfc_dep_compare_expr is not able to see that a+b+c equals c+b+a.


What you can do is to raise an error if gfc_dep_compare_expr returns
1 or -1, because then we can prove that the expressions are unequal.
For -2, we just don't know.


 Inside 'gfc_dep_compare_expr' I had to add
a minor piece to correctly respect commutativity of the multiplication
operator (for the addition operator this was done already).


Good idea; maybe you can commit that separately.


The extra
argument controls whether we check variable symbols for equality or
just their names. For the overriding checks it is sufficient to check
for names, because the arguments of the overriding procedure are
required to have the same names as in the base procedure.


Could you explain for which cases this test is too strict?

It might also be interesting to see if gfc_are_identical_variables could 
also be relaxed.  Then again, we might get by if we don't treat

-2 from gfc_dep_compare_expr as an error.


Moreover I extended the type check in 'check_typebound_override' to
also check for correct rank, via 'compare_type_rank' instead of
'gfc_compare_types'. However, the former was local to interface.c, so
I made it public (and should probably also rename it to gfc_...), or
should one rather move 'check_typebound_override' to interface.c
itself? I think it fits in there pretty nicely. After all it is
checking the interfaces of overriding procedures.


Whatever you choose, please make sure that any global function is
prefixed with gfc_ .

Regards

Thomas



Fix ICE in remap_predicate

2011-08-05 Thread Jan Hubicka
Hi,
the fortran testcase mismatches parameter count on inlined function and makes 
us to ICE
on out of bounds array acces in remap_predicate.
Fixed thus.

Bootstrapped/regtested x86_64-linux, committed.
PR middle-end/49494
* ipa-inline-analysis.c (remap_predicate): Add bounds check.
* gfortran.dg/pr49494.f90: New testcase.
Index: testsuite/gfortran.dg/pr49494.f90
===
*** testsuite/gfortran.dg/pr49494.f90   (revision 0)
--- testsuite/gfortran.dg/pr49494.f90   (revision 0)
***
*** 0 
--- 1,12 
+ ! { dg-do compile }
+ ! { dg-options "-O -findirect-inlining -fno-guess-branch-probability 
-finline-functions -finline-small-functions" }
+ function more_OK (fcn)
+   character(*) more_OK
+   character (*), external :: fcn
+   more_OK = fcn ()
+ end function more_OK
+   character(4) :: answer
+   character(4), external :: is_OK, more_OK
+   answer = more_OK (is_OK)
+ contains
+ END
Index: ipa-inline-analysis.c
===
*** ipa-inline-analysis.c   (revision 177482)
--- ipa-inline-analysis.c   (working copy)
*** remap_predicate (struct inline_summary *
*** 1873,1878 
--- 1873,1879 
 /* See if we can remap condition operand to caller's operand.
Otherwise give up.  */
 if (!operand_map
+|| VEC_length (int, operand_map) <= c->operand_num
 || VEC_index (int, operand_map, c->operand_num) == -1)
   cond_predicate = true_predicate ();
 else


Re: [patch, fortran] PR 37721, warn about target > source in TRANSFER

2011-08-05 Thread Steve Kargl
On Fri, Aug 05, 2011 at 10:38:44PM +0200, Thomas Koenig wrote:
> Hello world,
> 
> the attached patch fixes PR 37721 by moving the check for TRANSFER size 
> mismatches to checking, away from simplification.  That means that it is 
> possible to check character MOLDs whose size is constant, but which 
> aren't constant themselves.
> 
> I added the extra argument to gfc_target_interpret_expr because for a 
> TRANSFER, we want a binary copy and not a conversion between wide and
> normal characters.
> 
> Regression-tested.  OK for trunk?
> 

OK.

-- 
Steve


[patch] fix bootstrap in libgcc for PowerPC FreeBSD

2011-08-05 Thread Andreas Tobler

Hi,

the patch below survives bootstrap stage-1 on PowerPC FreeBSD successfully.
W/o patch we try to fliter-out ibm-ldouble.c. So from my understanding 
the pattern ibm-ldouble.c does never match since there is a path 
prepended to the file name.

With the patch we look for everything which contains ibm-ldouble.c...

Is this ok for head?

Thanks,
Andreas

2011-08-05  Andreas Tobler  

* config/rs6000/t-freebsd: Add a wildcard to the filter to find
the file with the path.

Index: config/rs6000/t-freebsd
===
--- config/rs6000/t-freebsd (revision 177472)
+++ config/rs6000/t-freebsd (working copy)
@@ -19,4 +19,4 @@
 # .

 # We do not want to build ibm-ldouble.c.
-LIB2ADD := $(filter-out ibm-ldouble.c, $(LIB2ADD))
+LIB2ADD := $(filter-out %ibm-ldouble.c, $(LIB2ADD))


Re: [Patch, Fortran] Coarrays: Add/fix check for no coarrays as result value

2011-08-05 Thread Mikael Morin
On Thursday 04 August 2011 17:00:46 Tobias Burnus wrote:
> This patch fixes the result check for coarrays / variables with coarray
> subcomponents. It was working with a separate RESULT() variable - but
> not if the function name was the result variable.
> 
> Build and regtested on x86-64-linux.
> OK for the trunk?
> 
> Tobias
OK (and obvious).

Mikael



Re: [patch] C6X unwinding/exception handling

2011-08-05 Thread Bernd Schmidt
On 08/04/11 16:31, Paul Brook wrote:
> C6X uses an unwinding/exception handling echeme very similar to that defined 
> by the ARM EABI.  The core of the unwinder is the same, so I've pulled it out 
> into a common file.
> 
> Other than the obvious target specific bits, the main compiler visible 
> difference is that the C6X assembler generates the unwinding tables from 
> DWARF 
> .cfi directives, rather than the separate set of directives used by the ARM 
> assembler.
> 
> The libstdc++ changes probably deserve a bit of explanation. The ttype_base 
> field was clearly used in an early draft of the ARM EABI, and the current ARM 
> definition is a compatible subset of that used by C6X.  
> _GLIBCXX_OVERRIDE_TTYPE_ENCODING is an unfortunate hack because when doing 
> the 
> ARM implementation I failed to realise ttype_encoding was the same thing as 
> R_ARM_TARGET2.  We now have a lot of ARM binaries floating around with that 
> field set incorrectly, so it's either this or an ABI bump.

Just for the record, no objections to the C6X parts of the patch if the
rest is approved.

It would probably help to say what kind of testing you did on ARM.


Bernd


Re: [Patch, Fortran, OOP] PR 49638: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

2011-08-05 Thread Mikael Morin
On Friday 05 August 2011 23:02:33 Thomas Koenig wrote:
> > The extra
> > argument controls whether we check variable symbols for equality or
> > just their names. For the overriding checks it is sufficient to check
> > for names, because the arguments of the overriding procedure are
> > required to have the same names as in the base procedure.
> 
> Could you explain for which cases this test is too strict?
For dummy arguments. If they are "corresponding" (same position, same name), 
they should compare equal. Cf the PR.

This lets me think that one should enable the comparison by name for dummy 
arguments only. Other variables should compare normally.

Mikael



[PATCH, libiberty]: Check result of fwrite in test-expandargv.c

2011-08-05 Thread Uros Bizjak
Hello!

My system warns during compilation of libiberty test-expandargv.c test:

gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-svn/trunk/libiberty/testsuite/../../include
-DHAVE_CONFIG_H -I.. -o test-expandargv \
../../../gcc-svn/trunk/libiberty/testsuite/test-expandargv.c 
../libiberty.a
../../../gcc-svn/trunk/libiberty/testsuite/test-expandargv.c: In
function ‘writeout_test’:
../../../gcc-svn/trunk/libiberty/testsuite/test-expandargv.c:211:
warning: ignoring return value of ‘fwrite’, declared with attribute
warn_unused_result

Attached patch fixes this warning.

2011-08-05  Uros Bizjak  

* testsuite/test-expandargv.c (writeout_test): Check result of fwrite.

Tested on alphaev68-pc-linux-gnu and x86_64-pc-linux-gnu.

OK for mainline SVN and 4.6?

Uros.
Index: testsuite/test-expandargv.c
===
--- testsuite/test-expandargv.c (revision 177430)
+++ testsuite/test-expandargv.c (working copy)
@@ -189,7 +189,7 @@ writeout_test (int test, const char * test_data)
 {
   char filename[256];
   FILE *fd;
-  size_t len;
+  size_t len, sys_fwrite;
   char * parse;
 
   /* Unique filename per test */
@@ -208,7 +208,10 @@ writeout_test (int test, const char * test_data)
   /* Run all possible replaces */
   run_replaces (parse);
 
-  fwrite (parse, len, sizeof (char), fd);
+  sys_fwrite = fwrite (parse, sizeof (char), len, fd);
+  if (sys_fwrite != len)
+fatal_error (__LINE__, "Failed to write to test file.", errno);
+
   free (parse);
   fclose (fd);
 }


PATCH: Add a testcase for PR middle-end/47364.

2011-08-05 Thread H.J. Lu
Hi,

I checked in this patch to add a testcase for PR middle-end/47364.

H.J.
---
Index: gcc.target/i386/pr47364-1.c
===
--- gcc.target/i386/pr47364-1.c (revision 0)
+++ gcc.target/i386/pr47364-1.c (revision 0)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+
+static unsigned char foo[256];
+
+arc4_init(void)
+{
+  int n;
+
+  for (n = 0; n < 256; n++)
+foo[n] = n;
+}
Index: ChangeLog
===
--- ChangeLog   (revision 177486)
+++ ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+2011-08-05  H.J. Lu  
+
+   PR middle-end/47364
+   * gcc.dg/torture/pr47364-1.c: New.
+
 2011-08-05  Thomas Koenig  
 
PR fortran/37221


Re: PATCH: Add a testcase for PR middle-end/47364.

2011-08-05 Thread Andrew Pinski
On Fri, Aug 5, 2011 at 3:06 PM, H.J. Lu  wrote:
> Hi,
>
> I checked in this patch to add a testcase for PR middle-end/47364.
>
> H.J.
> ---
> Index: gcc.target/i386/pr47364-1.c
> ===
> --- gcc.target/i386/pr47364-1.c (revision 0)
> +++ gcc.target/i386/pr47364-1.c (revision 0)
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O" } */
> +
> +static unsigned char foo[256];
> +
> +arc4_init(void)
> +{
> +  int n;
> +
> +  for (n = 0; n < 256; n++)
> +    foo[n] = n;
> +}

This testcase looks like it could go into c-torture/compile directory
instead of a target specific directory.

Thanks,
Andrew Pinski


  1   2   >