Re: [testsuite] XFAIL gcc.dg/torture/pr60092.c execution on Solaris 11

2014-02-19 Thread Richard Biener
On Tue, 18 Feb 2014, Rainer Orth wrote:

> As described in PR middle-end/60092, gcc.dg/torture/pr60092.c execution
> FAILs at -O0 on Solaris 11.  posix_memalign modifies it's first arg in
> the error case, which is at least a QOI issue.
> 
> Therefore I'd like to XFAIL the test like this.  Tested with the
> appropriate runtest invocation on i386-pc-solaris2.10,
> i386-pc-solaris2.11, sparc-sun-solaris2.11, and
> x86_64-unknown-linux-gnu.
> 
> Ok for mainline?

Ok.

Thanks,
Richard.

>   Rainer
> 
> 
> 2014-02-18  Rainer Orth  
> 
>   * gcc.dg/torture/pr60092.c: xfail execution on *-*-solaris2.11* at -O0.


Re: [PATCH] Fix -ftrack-macro-expansion preprocessing of A######A (PR preprocessor/58844)

2014-02-19 Thread Dodji Seketeli
Jakub Jelinek  writes:

> Hi!
>
> The following testcase build with -ftrack-macro-expansion=0,
> but don't build otherwise.  The problem seems to be that
> the libcpp for macro redefinition warning/error purposes if it sees
> more than one paste operator adds those extra CPP_PASTE tokens at the end,
> after normal tokens from the macro.  For -ftrack-macro-expansion=0 we were
> using macro_real_token_count (macro) to only use the real tokens for macro
> expansion purposes, but for track_macro_expansion it used macro->count,
> which includes also the extra tokens.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk (and after a while for 4.8)?

For what it's worth, this is OK for me, yes.  Though I am just a casual
contributor giving my point of view here.

>
> 2014-02-18  Jakub Jelinek  
>
>   PR preprocessor/58844
>   * macro.c (enter_macro_context): Only push
>   macro_real_token_count (macro) tokens rather than
>   macro->count tokens, regardless of
>   CPP_OPTION (pfile, track-macro-expansion).
>
>   * c-c++-common/cpp/pr58844-1.c: New test.
>   * c-c++-common/cpp/pr58844-2.c: New test.

Thanks.

-- 
Dodji


Re: FRE may run out of memory

2014-02-19 Thread dxq
Richard Biener-2 wrote
> On Fri, Feb 14, 2014 at 3:50 AM, dxq <

> ziyan01@

> > wrote:
> 
> What compiler version did you check?  I think that 4.8 has improvements
> for 1. and 2. (SMS is unmaintained).  Note that we only spent time to
> make -O1 behave sanely with extremely large functions.
> 
> Finally I'd suggest you open a bugreport and attach a testcase to it
> that exposes the issues you list.
> 
> Richard.

hi Richard,

We are working on gcc-4.7.1.  seems that these issues have been fixed in
gcc-4.8.3.

BTW, we notice that Obstack is used in LIM for memory management, which is
really a nice way, 
and also, we used Ostack to solve the GGC problem in our SMS-UNROLL
framework, 
we put all backup into the  Obstack, so it's safe now. 

http://gcc.1065356.n5.nabble.com/A-GGC-related-question-td988400.html
 
Thanks!

danxiaoqiang



--
View this message in context: 
http://gcc.1065356.n5.nabble.com/FRE-may-run-out-of-memory-tp1009578p1012489.html
Sent from the gcc - patches mailing list archive at Nabble.com.


Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs

2014-02-19 Thread Richard Biener
On Tue, 18 Feb 2014, Richard Biener wrote:

> 
> The following two pieces fix the fallout of
> 
> 2013-05-22  Mark Mitchell  
> Sandra Loosemore  
> 
> * configure.ac (dbexecdir): Base on $(toolexeclibdir), not
> $(libdir).
> ...
> 
> that makes a wreck out of my 4.9-based libjava installs.
> 
> First it avoids to break dbexecdir with MULTSUBDIR= by removing
> the redundant but non-version-specific-aware multilib addition.
> 
> Second, it makes sure that gcc_version, used in the
> version-specific path, is defined at all in classpath/ and its
> subdirs.
> 
> Tested for my particular configuration, I'll do a default,
> non-version-specific one as well (but expect no changes).
> 
> Ok for trunk?

In addition to my weird non-multilib version-specific variant
I now tested regular non-version-specific and multilib variant
as well as version-specific multilib variant and all looks ok.

Thus,

Ok for trunk?

Thanks,
Richard.

> Thanks,
> Richard.
> 
> 2014-02-18  Richard Biener  
> 
>   PR libjava/60261
>   * configure.ac (dbexecdir): Remove redundant multilib addition.
>   * Makefile.am (gcc_version): Export.
>   * configure: Regenerate.
>   * Makefile.in: Likewise.
> 
> Index: libjava/configure.ac
> ===
> --- libjava/configure.ac  (revision 207837)
> +++ libjava/configure.ac  (working copy)
> @@ -1596,15 +1596,7 @@ AC_DEFINE_UNQUOTED(GCJVERSION, "$GCJVERS
>  # Determine where the standard .db file and GNU Classpath JNI
>  # libraries are found.
>  gcjsubdir=gcj-$gcjversion-$libgcj_soversion
> -multi_os_directory=`$CC -print-multi-os-directory`
> -case $multi_os_directory in
> -  .)
> -   dbexecdir='$(toolexeclibdir)/'$gcjsubdir # Avoid /.
> -   ;;
> -  *)
> -   dbexecdir='$(toolexeclibdir)/'$multi_os_directory/$gcjsubdir
> -   ;;
> -esac
> +dbexecdir='$(toolexeclibdir)/'$gcjsubdir
>  AC_SUBST(dbexecdir)
>  AC_SUBST(gcjsubdir)
>  
> Index: libjava/configure
> ===
> --- libjava/configure (revision 207837)
> +++ libjava/configure (working copy)
> @@ -24016,15 +24016,7 @@ _ACEOF
>  # Determine where the standard .db file and GNU Classpath JNI
>  # libraries are found.
>  gcjsubdir=gcj-$gcjversion-$libgcj_soversion
> -multi_os_directory=`$CC -print-multi-os-directory`
> -case $multi_os_directory in
> -  .)
> -   dbexecdir='$(toolexeclibdir)/'$gcjsubdir # Avoid /.
> -   ;;
> -  *)
> -   dbexecdir='$(toolexeclibdir)/'$multi_os_directory/$gcjsubdir
> -   ;;
> -esac
> +dbexecdir='$(toolexeclibdir)/'$gcjsubdir
>  
>  
>  
> Index: libjava/Makefile.am
> ===
> --- libjava/Makefile.am   (revision 207837)
> +++ libjava/Makefile.am   (working copy)
> @@ -6,6 +6,7 @@ ACLOCAL_AMFLAGS = -I . -I .. -I ../confi
>  
>  # May be used by various substitution variables.
>  gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
> +export gcc_version
>  
>  SUBDIRS = $(DIRLTDL) gcj include classpath
>  if TESTSUBDIR
> Index: libjava/Makefile.in
> ===
> --- libjava/Makefile.in   (revision 207837)
> +++ libjava/Makefile.in   (working copy)
> @@ -10581,6 +10581,7 @@ uninstall-am: uninstall-binPROGRAMS unin
>   uninstall-libexecsubPROGRAMS uninstall-toolexeclibLTLIBRARIES \
>   uninstall-toolexecmainlibDATA
>  
> +export gcc_version
>  
>  interpret.lo:  AM_CXXFLAGS += -fwrapv
>  prims.lo: AM_CXXFLAGS += -fno-omit-frame-pointer
> 

-- 
Richard Biener 
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer


[PATCH] Fix up -save-temps with #pragma simd

2014-02-19 Thread Jakub Jelinek
Hi!

While fixing PR60267, I've noticed that #pragma simd is not registered
when -E -fcilkplus, even when it asks for macro replacements in the clauses.

So, either we have to register it even when preprocessing, so that say for
-save-temps, or other cases of separate preprocessing and separate
compilation you get the macro replacement in there, or #pragma simd doesn't
want to do macro replacement in the clauses, in that case it should call
the cpp_register_deferred_pragma function with false, false rather than
true, false.  But then even #define N 8 ... #pragma simd vectorlength(N)
wouldn't work.

2014-02-19  Jakub Jelinek  

* c-pragma.c (c_pp_lookup_pragma): Handle PRAGMA_CILK_SIMD.
(init_pragma): Call cpp_register_deferred_pragma for PRAGMA_CILK_SIMD
even when flag_preprocess_only.

* c-c++-common/cilk-plus/PS/vectorlength-2.c: New test.
* c-c++-common/cilk-plus/PS/vectorlength-3.c: New test.

--- gcc/c-family/c-pragma.c.jj  2014-02-19 09:49:08.0 +0100
+++ gcc/c-family/c-pragma.c 2014-02-19 10:02:52.148421881 +0100
@@ -1221,6 +1221,13 @@ c_pp_lookup_pragma (unsigned int id, con
return;
   }
 
+  if (id == PRAGMA_CILK_SIMD)
+{
+  *space = NULL;
+  *name = "simd";
+  return;
+}
+
   if (id >= PRAGMA_FIRST_EXTERNAL
   && (id < PRAGMA_FIRST_EXTERNAL + registered_pp_pragmas.length ()))
 {
@@ -1384,7 +1391,7 @@ init_pragma (void)
  omp_pragmas_simd[i].id, true, true);
 }
 
-  if (flag_cilkplus && !flag_preprocess_only)
+  if (flag_cilkplus)
 cpp_register_deferred_pragma (parse_in, NULL, "simd", PRAGMA_CILK_SIMD,
  true, false);
 
--- gcc/testsuite/c-c++-common/cilk-plus/PS/vectorlength-2.c.jj 2014-02-19 
10:07:10.478961407 +0100
+++ gcc/testsuite/c-c++-common/cilk-plus/PS/vectorlength-2.c2014-02-19 
10:07:57.005697907 +0100
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcilkplus" } */
+
+#define vl(n) vectorlength(2*n)
+void
+foo (int *a, int *b, int *c)
+{
+  int i;
+#pragma simd vl(4)
+  for (i = 0; i < 64; i++)
+a[i] = b[i] * c[i];
+}
--- gcc/testsuite/c-c++-common/cilk-plus/PS/vectorlength-3.c.jj 2014-02-19 
10:07:13.955941631 +0100
+++ gcc/testsuite/c-c++-common/cilk-plus/PS/vectorlength-3.c2014-02-19 
10:07:49.812737607 +0100
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcilkplus -save-temps" } */
+
+#define vl(n) vectorlength(2*n)
+void
+foo (int *a, int *b, int *c)
+{
+  int i;
+#pragma simd vl(4)
+  for (i = 0; i < 64; i++)
+a[i] = b[i] * c[i];
+}
+
+/* { dg-final { cleanup-saved-temps } } */

Jakub


Re: [PATCH] Remove N^2 update-ssa calls in IPA SRA

2014-02-19 Thread Jakub Jelinek
On Mon, Feb 17, 2014 at 02:38:42PM +0100, Richard Biener wrote:
> 
> This removes the update_ssa call in ipa_modify_call_arguments by
> keeping virtual SSA form up-to-date.  It also avoids leaking
> the virtual SSA name defined by the replaced call (and thus
> keeping more than necessary memory live during early transforms).
> 
> Bootstrap and regtest in progress on x86_64-unknown-linux-gnu, ok
> for trunk at this stage?  (didn't come here with the compile-time
> issue but with the leaked SSA name, both would improve the
> general compile-time-hog/memory-usage regression)

> 2014-02-17  Richard Biener  
> 
>   * ipa-prop.c: Include stringpool.h and tree-ssanames.h.
>   (ipa_modify_call_arguments): Emit an argument load explicitely and
>   preserve virtual SSA form there and for the replacement call.
>   Do not update SSA form nor free dominance info.

Ok, thanks.

Jakub


RE: [PATCH][4.8] Backport strict-volatile-bitfields fixes to 4.8

2014-02-19 Thread Joey Ye
Ping ^ 4

> -Original Message-
> From: Joey Ye [mailto:joey...@arm.com]
> Sent: Friday, February 14, 2014 9:58
> To: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][4.8] Backport strict-volatile-bitfields fixes to 4.8
> 
> Ping ^3
> 
> These fixes are very important to 4.8 ARM embedded users, as they rely on
> strict volatile bitfields a lot. Please let them in 4.8.
> 
> > -Original Message-
> > From: Joey Ye [mailto:joey...@arm.com]
> > Sent: Saturday, February 08, 2014 10:42
> > To: gcc-patches@gcc.gnu.org
> > Subject: RE: [PATCH][4.8] Backport strict-volatile-bitfields fixes to
> > 4.8
> >
> > Ping ^ 2
> >
> > OK to 4.8?
> >
> > > -Original Message-
> > > From: Joey Ye [mailto:joey...@arm.com]
> > > Sent: Monday, January 20, 2014 10:47
> > > To: gcc-patches@gcc.gnu.org
> > > Subject: RE: [PATCH][4.8] Backport strict-volatile-bitfields fixes
> > > to 4.8
> > >
> > > Ping
> > >
> > > > -Original Message-
> > > > From: Joey Ye [mailto:joey...@arm.com]
> > > > Sent: Thursday, January 16, 2014 16:28
> > > > To: gcc-patches@gcc.gnu.org
> > > > Subject: [PATCH][4.8] Backport strict-volatile-bitfields fixes to
> > > > 4.8
> > > >
> > > > 4.8 has a number of strict-volatile-bitfields issues that can be
> > > > fixed by following patches.
> > > > trunk@205899, 205898, 205897, 205896, 203003
> > > >
> > > > Tested on x86_64 and arm without regression.
> > > >
> > > > OK to 4.8?
> > > >
> > > > 2013-09-28  Sandra Loosemore  
> > > >
> > > > gcc/
> > > > * expr.h (extract_bit_field): Remove packedp parameter.
> > > > * expmed.c (extract_fixed_bit_field): Remove packedp
parameter
> > > > from forward declaration.
> > > > (store_split_bit_field): Remove packedp arg from calls to
> > > > extract_fixed_bit_field.
> > > > (extract_bit_field_1): Remove packedp parameter and packedp
> > > > argument from recursive calls and calls to
extract_fixed_bit_field.
> > > > (extract_bit_field): Remove packedp parameter and
corresponding
> > > > arg to extract_bit_field_1.
> > > > (extract_fixed_bit_field): Remove packedp parameter.
> > > > Remove
> > code
> > > > to issue warnings.
> > > > (extract_split_bit_field): Remove packedp arg from call to
> > > > extract_fixed_bit_field.
> > > > * expr.c (emit_group_load_1): Adjust calls to
extract_bit_field.
> > > > (copy_blkmode_from_reg): Likewise.
> > > > (copy_blkmode_to_reg): Likewise.
> > > > (read_complex_part): Likewise.
> > > > (store_field): Likewise.
> > > > (expand_expr_real_1): Likewise.
> > > > * calls.c (store_unaligned_arguments_into_pseudos): Adjust
call
> > > > to extract_bit_field.
> > > > * config/tilegx/tilegx.c (tilegx_expand_unaligned_load):
Adjust
> > > > call to extract_bit_field.
> > > > * config/tilepro/tilepro.c (tilepro_expand_unaligned_load):
Adjust
> > > > call to extract_bit_field.
> > > > * doc/invoke.texi (Code Gen Options): Remove mention of
> warnings
> > > > and special packedp behavior from
-fstrict-volatile-bitfields
> > > > documentation.
> > > >
> > > > 2013-12-11  Bernd Edlinger  
> > > >
> > > > * expr.c (expand_assignment): Remove dependency on
> > > > flag_strict_volatile_bitfields. Always set the memory
> > > > access mode.
> > > > (expand_expr_real_1): Likewise.
> > > >
> > > > 2013-12-11  Sandra Loosemore  
> > > >
> > > > PR middle-end/23623
> > > > PR middle-end/48784
> > > > PR middle-end/56341
> > > > PR middle-end/56997
> > > >
> > > > gcc/
> > > > * expmed.c (strict_volatile_bitfield_p): New function.
> > > > (store_bit_field_1): Don't special-case strict volatile
> > > > bitfields here.
> > > > (store_bit_field): Handle strict volatile bitfields here
instead.
> > > > (store_fixed_bit_field): Don't special-case strict volatile
> > > > bitfields here.
> > > > (extract_bit_field_1): Don't special-case strict volatile
> > > > bitfields here.
> > > > (extract_bit_field): Handle strict volatile bitfields here
instead.
> > > > (extract_fixed_bit_field): Don't special-case strict
volatile
> > > > bitfields here.  Simplify surrounding code to resemble that
in
> > > > store_fixed_bit_field.
> > > > * doc/invoke.texi (Code Gen Options): Update
> > > > -fstrict-volatile-bitfields description.
> > > >
> > > > gcc/testsuite/
> > > > * gcc.dg/pr23623.c: New test.
> > > > * gcc.dg/pr48784-1.c: New test.
> > > > * gcc.dg/pr48784-2.c: New test.
> > > > * gcc.dg/pr56341-1.c: New test.
> > > > * gcc.dg/pr56341-2.c: New test.
> > > > * gcc.dg/pr56997-1.c: New test.
> > > > * gcc.dg/pr56997-2.c: New test.
> > > > * gcc.dg/pr56997-3.c: New test.
> 

Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs

2014-02-19 Thread Andrew Haley
On 02/19/2014 09:03 AM, Richard Biener wrote:
> On Tue, 18 Feb 2014, Richard Biener wrote:
> 
>>
>> The following two pieces fix the fallout of
>>
>> 2013-05-22  Mark Mitchell  
>> Sandra Loosemore  
>>
>> * configure.ac (dbexecdir): Base on $(toolexeclibdir), not
>> $(libdir).
>> ...
>>
>> that makes a wreck out of my 4.9-based libjava installs.
>>
>> First it avoids to break dbexecdir with MULTSUBDIR= by removing
>> the redundant but non-version-specific-aware multilib addition.
>>
>> Second, it makes sure that gcc_version, used in the
>> version-specific path, is defined at all in classpath/ and its
>> subdirs.
>>
>> Tested for my particular configuration, I'll do a default,
>> non-version-specific one as well (but expect no changes).
>>
>> Ok for trunk?
> 
> In addition to my weird non-multilib version-specific variant
> I now tested regular non-version-specific and multilib variant
> as well as version-specific multilib variant and all looks ok.
> 
> Thus,
> 
> Ok for trunk?

It may be that someone understands this, but I don't.  What does this change
do?

Andrew.



Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs

2014-02-19 Thread Richard Biener
On Wed, 19 Feb 2014, Andrew Haley wrote:

> On 02/19/2014 09:03 AM, Richard Biener wrote:
> > On Tue, 18 Feb 2014, Richard Biener wrote:
> > 
> >>
> >> The following two pieces fix the fallout of
> >>
> >> 2013-05-22  Mark Mitchell  
> >> Sandra Loosemore  
> >>
> >> * configure.ac (dbexecdir): Base on $(toolexeclibdir), not
> >> $(libdir).
> >> ...
> >>
> >> that makes a wreck out of my 4.9-based libjava installs.
> >>
> >> First it avoids to break dbexecdir with MULTSUBDIR= by removing
> >> the redundant but non-version-specific-aware multilib addition.
> >>
> >> Second, it makes sure that gcc_version, used in the
> >> version-specific path, is defined at all in classpath/ and its
> >> subdirs.
> >>
> >> Tested for my particular configuration, I'll do a default,
> >> non-version-specific one as well (but expect no changes).
> >>
> >> Ok for trunk?
> > 
> > In addition to my weird non-multilib version-specific variant
> > I now tested regular non-version-specific and multilib variant
> > as well as version-specific multilib variant and all looks ok.
> > 
> > Thus,
> > 
> > Ok for trunk?
> 
> It may be that someone understands this, but I don't.  What does this change
> do?

It fixes breakage introduced by Sandras patch.  In particular it avoids
libjava to end up in random places:

/usr/lib64/gcc/x86_64-suse-linux/
4.9  gcj-4.9-15  lib64  logging.properties  security

/usr/lib64/gcc/x86_64-suse-linux/4.9/
ecj.jar  include  jvgenmainlibgcj.la  libgcj.spec   libgij.so
ecj1 jc1  libgcj-tools.so  libgcj.so  libgcj_bc.so  pkgconfig

/usr/lib64/gcc/x86_64-suse-linux/gcj-4.9-15/
libjavamath.la  libjavamath.so

/usr/lib64/gcc/x86_64-suse-linux/lib64/gcj-4.9-15
classmap.db  libjvm.la  libjvm.so

and changes that to

/usr/lib64/gcc/x86_64-suse-linux/4.9/
ecj.jar  include  jvgenmainlibgcj.la  libgcj.spec   libgij.so
ecj1 jc1  libgcj-tools.so  libgcj.so  libgcj_bc.so  pkgconfig
gcj-4.9-15 logging.properties  security

/usr/lib64/gcc/x86_64-suse-linux/4.9/gcj-4.9-15
classmap.db  libjvm.la  libjvm.so libjavamath.la  libjavamath.so

for --enable-version-specific-runtime-libs (no changes for without
that option).  Sandras patch was supposed to introduce support
for --enable-version-specific-runtime-libs in libgcj (but obviously
it failed, given the result above).

With multilibs there is a 2nd gcj-4.9-15 inside
/usr/lib64/gcc/x86_64-suse-linux/4.9/32/ with the patch.

Hope this helps.

Thanks,
Richard.


[Patch, Fortran, OOP] PR 60232: The rank of the element in the structure constructor does not match that of the component

2014-02-19 Thread Janus Weil
Hi all,

here is a small patch for an OOP-related rejects-valid problem, which
is technically not a regression, but I hope the patch is simple enough
to still make it into trunk.

The problem is this: When using a dimensionful function as an
EXPR_VARIABLE (e.g. as the target in a procedure pointer assignment),
we wrongly add a REF_ARRAY, because we are tricked to believe that the
expression is dimensionful (which is not the case). In the test case
at hand this problem appears in an OOP context, where we have a
dimensionful type-bound procedure, which then appears as the target to
the corresponding procedure-pointer component in the vtab.

The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus


2014-02-19  Janus Weil  

PR fortran/60232
* expr.c (gfc_get_variable_expr): Don't add REF_ARRAY for dimensionful
functions, which are used as procedure pointer target.


2014-02-19  Janus Weil  

PR fortran/60232
* gfortran.dg/typebound_proc_33.f90: New.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 207846)
+++ gcc/fortran/expr.c  (working copy)
@@ -3962,9 +3962,10 @@ gfc_get_variable_expr (gfc_symtree *var)
   e->symtree = var;
   e->ts = var->n.sym->ts;
 
-  if ((var->n.sym->as != NULL && var->n.sym->ts.type != BT_CLASS)
-  || (var->n.sym->ts.type == BT_CLASS && CLASS_DATA (var->n.sym)
- && CLASS_DATA (var->n.sym)->as))
+  if (var->n.sym->attr.flavor != FL_PROCEDURE
+  && ((var->n.sym->as != NULL && var->n.sym->ts.type != BT_CLASS)
+  || (var->n.sym->ts.type == BT_CLASS && CLASS_DATA (var->n.sym)
+  && CLASS_DATA (var->n.sym)->as)))
 {
   e->rank = var->n.sym->ts.type == BT_CLASS
? CLASS_DATA (var->n.sym)->as->rank : var->n.sym->as->rank;
! { dg-do compile }
!
! PR 60232: [OOP] The rank of the element in the structure constructor does not match that of the component
!
! Contributed by Antony Lewis 

module ObjectLists
  implicit none

  Type TObjectList
  contains
procedure :: ArrayItem
  end Type

contains

  function ArrayItem(L) result(P)
Class(TObjectList) :: L
Class(TObjectList), pointer :: P(:)
  end function

end module


  use ObjectLists
  implicit none

  Type, extends(TObjectList):: TSampleList
  end Type

contains

  subroutine TSampleList_ConfidVal(L)
Class(TSampleList) :: L
  end subroutine

end

! { dg-final { cleanup-modules "ObjectLists" } }


Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs

2014-02-19 Thread Andrew Haley
On 02/19/2014 09:34 AM, Richard Biener wrote:
> Sandras patch was supposed to introduce support
> for --enable-version-specific-runtime-libs in libgcj (but obviously
> it failed, given the result above).

Sandra?  You're very quiet.  What say you?

I don't want this ping-ponging.

Andrew.



Re: [Patch, Fortran, OOP] PR 60232: The rank of the element in the structure constructor does not match that of the component

2014-02-19 Thread Tobias Burnus
Hi Janus,

Janus Weil wrote:
> The problem is this: When using a dimensionful function as an
> EXPR_VARIABLE (e.g. as the target in a procedure pointer assignment),
> we wrongly add a REF_ARRAY, because we are tricked to believe that the
> expression is dimensionful

> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Looks good to me. Thanks for the patch!

Tobias


[PATCH, ARM] Support ORN for DImode

2014-02-19 Thread Ian Bolton
Hi,

Patterns had previously been added to thumb2.md to support ORN, but only for
SImode.

This patch adds DImode support, to cover the full 64|64->64 operation and
the various 32|64->64 operations (see AND:DI variants that use NOT).

The patch comes with its own execution test and looks for correct number of
ORN instructions in the assembly.

Regressions passed.

OK for stage 1?


2014-02-19  Ian Bolton  

gcc/
* config/arm/thumb2.md (*iordi_notdi_di): New pattern.
(*iordi_notzesidi): New pattern.
(*iordi_notsesidi_di): New pattern.
testsuite/
* gcc.target/arm/iordi_notdi-1.c: New test.diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index 4f247f8..6a71fec 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -1366,6 +1366,79 @@
(set_attr "type" "alu_reg")]
 )
 
+; Constants for op 2 will never be given to these patterns.
+(define_insn_and_split "*iordi_notdi_di"
+  [(set (match_operand:DI 0 "s_register_operand" "=&r,&r")
+   (ior:DI (not:DI (match_operand:DI 1 "s_register_operand" "0,r"))
+   (match_operand:DI 2 "s_register_operand" "r,0")))]
+  "TARGET_THUMB2"
+  "#"
+  "TARGET_THUMB2 && reload_completed"
+  [(set (match_dup 0) (ior:SI (not:SI (match_dup 1)) (match_dup 2)))
+   (set (match_dup 3) (ior:SI (not:SI (match_dup 4)) (match_dup 5)))]
+  "
+  {
+operands[3] = gen_highpart (SImode, operands[0]);
+operands[0] = gen_lowpart (SImode, operands[0]);
+operands[4] = gen_highpart (SImode, operands[1]);
+operands[1] = gen_lowpart (SImode, operands[1]);
+operands[5] = gen_highpart (SImode, operands[2]);
+operands[2] = gen_lowpart (SImode, operands[2]);
+  }"
+  [(set_attr "length" "8")
+   (set_attr "predicable" "yes")
+   (set_attr "predicable_short_it" "no")
+   (set_attr "type" "multiple")]
+)
+
+(define_insn_and_split "*iordi_notzesidi_di"
+  [(set (match_operand:DI 0 "s_register_operand" "=&r,&r")
+   (ior:DI (not:DI (zero_extend:DI
+(match_operand:SI 2 "s_register_operand" "r,r")))
+   (match_operand:DI 1 "s_register_operand" "0,?r")))]
+  "TARGET_THUMB2"
+  "#"
+  ; (not (zero_extend...)) means operand0 will always be 0x
+  "TARGET_THUMB2 && reload_completed"
+  [(set (match_dup 0) (ior:SI (not:SI (match_dup 2)) (match_dup 1)))
+   (set (match_dup 3) (const_int -1))]
+  "
+  {
+operands[3] = gen_highpart (SImode, operands[0]);
+operands[0] = gen_lowpart (SImode, operands[0]);
+operands[1] = gen_lowpart (SImode, operands[1]);
+  }"
+  [(set_attr "length" "4,8")
+   (set_attr "predicable" "yes")
+   (set_attr "predicable_short_it" "no")
+   (set_attr "type" "multiple")]
+)
+
+(define_insn_and_split "*iordi_notsesidi_di"
+  [(set (match_operand:DI 0 "s_register_operand" "=&r,&r")
+   (ior:DI (not:DI (sign_extend:DI
+(match_operand:SI 2 "s_register_operand" "r,r")))
+   (match_operand:DI 1 "s_register_operand" "0,r")))]
+  "TARGET_THUMB2"
+  "#"
+  "TARGET_THUMB2 && reload_completed"
+  [(set (match_dup 0) (ior:SI (not:SI (match_dup 2)) (match_dup 1)))
+   (set (match_dup 3) (ior:SI (not:SI
+   (ashiftrt:SI (match_dup 2) (const_int 31)))
+  (match_dup 4)))]
+  "
+  {
+operands[3] = gen_highpart (SImode, operands[0]);
+operands[0] = gen_lowpart (SImode, operands[0]);
+operands[4] = gen_highpart (SImode, operands[1]);
+operands[1] = gen_lowpart (SImode, operands[1]);
+  }"
+  [(set_attr "length" "8")
+   (set_attr "predicable" "yes")
+   (set_attr "predicable_short_it" "no")
+   (set_attr "type" "multiple")]
+)
+
 (define_insn "*orsi_notsi_si"
   [(set (match_operand:SI 0 "s_register_operand" "=r")
(ior:SI (not:SI (match_operand:SI 2 "s_register_operand" "r"))
diff --git a/gcc/testsuite/gcc.target/arm/iordi_notdi-1.c 
b/gcc/testsuite/gcc.target/arm/iordi_notdi-1.c
new file mode 100644
index 000..cda9c0e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/iordi_notdi-1.c
@@ -0,0 +1,54 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fno-inline --save-temps" } */
+
+extern void abort (void);
+
+typedef long long s64int;
+typedef int s32int;
+typedef unsigned long long u64int;
+typedef unsigned int u32int;
+
+s64int
+iordi_notdi (s64int a, s64int b)
+{
+  return (a | ~b);
+}
+
+s64int
+iordi_notzesidi (s64int a, u32int b)
+{
+  return (a | ~(u64int) b);
+}
+
+s64int
+iordi_notsesidi (s64int a, s32int b)
+{
+  return (a | ~(s64int) b);
+}
+
+int main ()
+{
+  s64int a64 = 0xdeadbeefll;
+  s64int b64 = 0x4f4f0112ll;
+
+  u32int c32 = 0x01124f4f;
+  s32int d32 = 0xabbaface;
+
+  s64int z = iordi_notdi (a64, b64);
+  if (z != 0xb0b0feedll)
+abort ();
+
+  z = iordi_notzesidi (a64, c32);
+  if (z != 0xfeedb0b0ll)
+abort ();
+
+  z = iordi_notsesidi (a64, d32);
+  if (z != 0xdeadbeef54450531ll)
+abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-assembler-times "orn\t" 5 { target arm_t

[Ada] Error recovery in task body

2014-02-19 Thread Arnaud Charlet
This patch fixes a crash in a task body with a single statement missing a
terminating semicolon. The tree can be repaired locally so further compilation
can proceed.

Compiling libthr3.adb must yield:

libthr3.adb:10:18: missing ";"
libthr3.adb:13:04: warning: no accept for entry "Test"

---
procedure Libthr3 is
   task type TSK;

   task Driver is
  entry Test;
   end Driver;

   task body TSK is
   begin
  Driver.Test  -- Missing ; gives GNAT BUG DETECTED box
   end TSK;

   task body Driver is
  P : access TSK;
   begin
  P := new TSK;
   end Driver;
begin
   null;
end Libthr3;

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

2014-02-19  Ed Schonberg  

* par-ch9.adb (P_Task): Add a null statement to produce a
well-formed task body when due to a previous syntax error the
statement list is empty.

Index: par-ch9.adb
===
--- par-ch9.adb (revision 207879)
+++ par-ch9.adb (working copy)
@@ -144,6 +144,17 @@
 end if;
 
 Parse_Decls_Begin_End (Task_Node);
+
+--  The statement list of a task body needs to include at least a
+--  null statement, so if a parsing error produces an empty list,
+--  patch it now.
+
+if
+  No (First (Statements (Handled_Statement_Sequence (Task_Node
+then
+   Set_Statements (Handled_Statement_Sequence (Task_Node),
+   New_List (Make_Null_Statement (Token_Ptr)));
+end if;
  end if;
 
  return Task_Node;


[Ada] Accept a constituent in a null dependency clause

2014-02-19 Thread Arnaud Charlet
This patch implements the following SPARK RM rule from 7.2.5 (3g):

   at least one of its constituents shall be denoted in the input_list of a
   null_dependency_clause; or


-- Source --


--  null_dependency.ads

package Null_Dependency
  with Abstract_State => (Input_State, Output_State)
is
   procedure OK_1
 with Global  => (Input => Input_State),
  Depends => (null  => Input_State);

   procedure OK_2
 with Global  => (Input  => Input_State,
  Output => Output_State),
  Depends => (Output_State => Input_State);
end Null_Dependency;

--  null_dependency.adb

package body Null_Dependency
  with Refined_State => (Input_State  => (C1, C2),
 Output_State => (C3, C4))
is
   C1, C2, C3, C4 : Integer := 0;

   procedure OK_1
 with Refined_Global  => (Input => C1),
  Refined_Depends => (null  => C1)
   is begin null; end OK_1;

   procedure OK_2
 with Refined_Global  => (Input  => (C1, C2),
  Output => (C3, C4)),
  Refined_Depends => ((C3, C4) => C1,
   null=> C2)
   is begin null; end OK_2;
end Null_Dependency;

-
-- Compilation --
-

$ gcc -c null_dependency.adb

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

2014-02-19  Hristian Kirtchev  

* sem_prag.adb (Check_Dependency_Clause): Account
for the case where a state with a non-null refinement matches a
null output list. Comment reformatting.
(Inputs_Match): Copy a solitary input to avoid an assertion failure
when trying to match the same input in multiple clauses.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 207879)
+++ sem_prag.adb(working copy)
@@ -21434,16 +21434,38 @@
   elsif Has_Non_Null_Refinement (Dep_Id) then
  Has_Refined_State := True;
 
- if Is_Entity_Name (Ref_Output) then
+ --  Account for the case where a state with a non-null
+ --  refinement matches a null output list:
+
+ --Refined_State   => (State_1 => (C1, C2),
+ --State_2 => (C3, C4))
+ --Depends => (State_1 => State_2)
+ --Refined_Depends => (null=> C3)
+
+ if Nkind (Ref_Output) = N_Null
+   and then Inputs_Match
+  (Dep_Clause  => Dep_Clause,
+   Ref_Clause  => Ref_Clause,
+   Post_Errors => False)
+ then
+Has_Constituent := True;
+
+--  Note that the search continues after the clause is
+--  removed from the pool of candidates because it may
+--  have been normalized into multiple simple clauses.
+
+Remove (Ref_Clause);
+
+ --  Otherwise the output of the refinement clause must be
+ --  a valid constituent of the state:
+
+ --Refined_State   => (State => (C1, C2))
+ --Depends => (State => )
+ --Refined_Depends => (C1=> )
+
+ elsif Is_Entity_Name (Ref_Output) then
 Ref_Id := Entity_Of (Ref_Output);
 
---  The output of the refinement clause is a valid
---  constituent of the state. Remove the clause from
---  the pool of candidates if both input lists match.
---  Note that the search continues because one clause
---  may have been normalized into multiple clauses as
---  per the example above.
-
 if Ekind_In (Ref_Id, E_Abstract_State, E_Variable)
   and then Present (Encapsulating_State (Ref_Id))
   and then Encapsulating_State (Ref_Id) = Dep_Id
@@ -21453,6 +21475,12 @@
   Post_Errors => False)
 then
Has_Constituent := True;
+
+   --  Note that the search continues after the clause
+   --  is removed from the pool of candidates because
+   --  it may have been normalized into multiple simple
+   --  clauses.
+
Remove (Ref_Clause);
 end if;
  end if;
@@ -21819,12 +21847,13 @@
   begin
  --  Construct a list of all refinement inputs. Note that the input
  --  list is copied because the algorithm modifies its content

[Ada] Incorrect error on valid global refinement

2014-02-19 Thread Arnaud Charlet
This patch updates the analysis of aspect/pragma Refined_Global to interpret
states and variables with an encapsulating state as constituents only when the
related state has visible refinement.


-- Source --


--  parent.ads

package Parent
  with Abstract_State => State
is
   procedure Dummy;
private
   Var : Integer := 0 with Part_Of => State;
end Parent;

--  parent.adb

with Parent.Priv_Child;

package body Parent
  with Refined_State => (State => (Var, Parent.Priv_Child.Priv_State))
is
   procedure Dummy is begin null; end Dummy;
end Parent;

--  parent-priv_child.ads

private package Parent.Priv_Child
  with Abstract_State => (Priv_State with Part_Of => State)
is
   procedure OK (Param : Integer)
 with Global => (In_Out => (Var, Priv_State));
end Parent.Priv_Child;

--  parent-priv_child.adb

package body Parent.Priv_Child
  with Refined_State => (Priv_State => Priv_Var)
is
   Priv_Var : Integer := 0;

   procedure OK (Param : Integer)
 with Refined_Global => (In_Out => (Var, Priv_Var))
   is begin null; end OK;
end Parent.Priv_Child;

-
-- Compilation --
-

$ gcc -c parent-priv_child.adb

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

2014-02-19  Hristian Kirtchev  

* sem_prag.adb (Check_Refined_Global_Item):
A state or variable acts as a constituent only it is part of an
encapsulating state and the state has visible refinement.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 207884)
+++ sem_prag.adb(working copy)
@@ -22610,10 +22610,13 @@
  --  Start of processing for Check_Refined_Global_Item
 
  begin
---  The state or variable acts as a constituent of a state, collect
---  it for the state completeness checks performed later on.
+--  When the state or variable acts as a constituent of another
+--  state with a visible refinement, collect it for the state
+--  completeness checks performed later on.
 
-if Present (Encapsulating_State (Item_Id)) then
+if Present (Encapsulating_State (Item_Id))
+ and then Has_Visible_Refinement (Encapsulating_State (Item_Id))
+then
if Global_Mode = Name_Input then
   Add_Item (Item_Id, In_Constits);
 


[Ada] GNAT driver and externally built library project files

2014-02-19 Thread Arnaud Charlet
When the GNAT driver is invoked to bind a main of a project file, and
there are externally built library projects in the closure of the main
project file, the invocation of gnatbind may fail if the object directory
does not contain any ALI files.

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

2014-02-19  Vincent Celier  

* gnatcmd.adb (GNATCmd): Always replace the object dirs of
imported library projects with the library ALI dirs, when setting
the object paths.
* prj-env.ads (Ada_Objects_Path): Correct comments about
argument Including_Libraries.

Index: gnatcmd.adb
===
--- gnatcmd.adb (revision 207879)
+++ gnatcmd.adb (working copy)
@@ -1040,6 +1040,7 @@
 "accept project file switches -vPx, -Pprj and -Xnam=val");
   New_Line;
end Non_VMS_Usage;
+
--
-- Process_Link --
--
@@ -2106,7 +2107,7 @@
  --  Set up the env vars for project path files
 
  Prj.Env.Set_Ada_Paths
-   (Project, Project_Tree, Including_Libraries => False);
+   (Project, Project_Tree, Including_Libraries => True);
 
  --  For gnatcheck, gnatstub, gnatmetric, gnatpp and gnatelim, create
  --  a configuration pragmas file, if necessary.
Index: prj-env.adb
===
--- prj-env.adb (revision 207879)
+++ prj-env.adb (working copy)
@@ -1681,8 +1681,6 @@
  Path : Path_Name_Type;
 
   begin
- --  ??? This is almost the equivalent of For_All_Source_Dirs
-
  if Process_Source_Dirs then
 
 --  Add to path all source directories of this project if there are
Index: prj-env.ads
===
--- prj-env.ads (revision 207879)
+++ prj-env.ads (working copy)
@@ -92,7 +92,7 @@
   Including_Libraries : Boolean := True) return String_Access;
--  Get the ADA_OBJECTS_PATH of a Project file. For the first call with the
--  exact same parameters, compute it and cache it. When Including_Libraries
-   --  is False, the object directory of a library project is replaced with the
+   --  is True, the object directory of a library project is replaced with the
--  library ALI directory of this project (usually the library directory of
--  the project, except when attribute Library_ALI_Dir is declared) except
--  when the library ALI directory does not contain any ALI file.


Re: [PATCH] Fixing SEH exceptions for languages != C++

2014-02-19 Thread Jonathan Schleifer
Am Tue, 18 Feb 2014 17:51:00 +0100
schrieb Kai Tietz :

> So patch is ok with proper ChangeLog mentioning PR.  Patch is ok for
> back-port too.

I wonder if the instaned of RtlUnwindEx that come before the patched
line should be changed as well, though.

--
Jonathan


[Ada] Missing parentheses on [Refined_]Global and [Refined_]Depends

2014-02-19 Thread Arnaud Charlet
This patch modifies the parser to detect missing parentheses on SPARK aspects
Global, Depends, Refined_Global and Refined_Depends.


-- Source --


--  malformed_contracts.ads

package Malformed_Contracts
  with Abstract_State => (State_1, State_2)
is
   procedure OK_1
 with Global => State_1;

   procedure OK_2
 with Global => (State_1, State_2);

   procedure Error_0
 with Global => State_1, State_2;

   procedure Error_1
 with Global => Input => State_1;

   procedure Error_2
 with Global => (Input => State_1;

   procedure Error_3
 with Global => Input => State_1, In_Out => State_2;

   procedure Error_4
 with Global => (Input => State_1, In_Out => State_2;

   procedure Error_5
 with Global  => (In_Out  => State_1),
  Depends =>  State_1 => State_1;

   procedure Error_6
 with Global  => (In_Out  => State_1),
  Depends => (State_1 => State_1;

   procedure Error_7
 with Global  => (Input   => State_1, In_Out => State_2),
  Depends =>  State_2 => State_1, null   => State_2;

   procedure Error_8
 with Global  => (Input   => State_1, In_Out => State_2),
  Depends => (State_2 => State_1, null   => State_2;
end Malformed_Contracts;


-- Compilation and output --


$ gcc -c malformed_contracts.ads
malformed_contracts.ads:11:21: missing "("
malformed_contracts.ads:14:21: missing "("
malformed_contracts.ads:17:38: ";" should be ","
malformed_contracts.ads:20:21: missing "("
malformed_contracts.ads:23:57: ";" should be ","
malformed_contracts.ads:27:23: missing "("
malformed_contracts.ads:31:41: ";" should be ","
malformed_contracts.ads:35:23: missing "("
malformed_contracts.ads:39:60: missing ")"

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

2014-02-19  Hristian Kirtchev  

* par.adb Alphabetize the routines in Par.Sync.
(Resync_Past_Malformed_Aspect): New routine.
* par-ch13.adb (Get_Aspect_Specifications): Alphabetize local
variables. Code and comment reformatting. Detect missing
parentheses on aspects [Refined_]Global and [Refined_]Depends
with a non-null definition.
* par-sync.adb: Alphabetize all routines in this separate unit.
(Resync_Past_Malformed_Aspect): New routine.

Index: par-sync.adb
===
--- par-sync.adb(revision 207879)
+++ par-sync.adb(working copy)
@@ -148,47 +148,75 @@
   end if;
end Resync_Init;
 
-   ---
-   -- Resync_Past_Semicolon --
-   ---
+   --
+   -- Resync_Past_Malformed_Aspect --
+   --
 
-   procedure Resync_Past_Semicolon is
+   procedure Resync_Past_Malformed_Aspect is
begin
   Resync_Init;
 
   loop
- --  Done if we are at a semicolon
+ --  A comma may separate two aspect specifications, but it may also
+ --  delimit multiple arguments of a single aspect.
 
- if Token = Tok_Semicolon then
-Scan; -- past semicolon
+ if Token = Tok_Comma then
+declare
+   Scan_State : Saved_Scan_State;
+
+begin
+   Save_Scan_State (Scan_State);
+   Scan; -- past comma
+
+   --  The identifier following the comma is a valid aspect, the
+   --  current malformed aspect has been successfully skipped.
+
+   if Token = Tok_Identifier
+ and then Get_Aspect_Id (Token_Name) /= No_Aspect
+   then
+  Restore_Scan_State (Scan_State);
+  exit;
+
+   --  The comma is delimiting multiple arguments of an aspect
+
+   else
+  Restore_Scan_State (Scan_State);
+   end if;
+end;
+
+ --  An IS signals the last aspect specification when the related
+ --  context is a body.
+
+ elsif Token = Tok_Is then
 exit;
 
- --  Done if we are at a token which normally appears only after
- --  a semicolon. One special glitch is that the keyword private is
- --  in this category only if it does NOT appear after WITH.
+ --  A semicolon signals the last aspect specification
 
- elsif Token in Token_Class_After_SM
-and then (Token /= Tok_Private or else Prev_Token /= Tok_With)
- then
+ elsif Token = Tok_Semicolon then
 exit;
 
- --  Otherwise keep going
+ --  In the case of a mistyped semicolon, any token which follows a
+ --  semicolon signals the last aspect specification.
 
- else
-Scan;
+ elsif Token in Token_Class_After_SM then
+exit;
  end if;
+
+ --  Keep on resyncing
+
+ Scan;
   end loop;
 
   --  Fall out of loop wit

[Ada] Semantics of attribute 'Old in aspect/pragma Contract_Cases

2014-02-19 Thread Arnaud Charlet
This patch implements rule SPARK RM 6.1.3 (5) which states:

   If an Old attribute_reference occurs within a consequence other than the
   consequence selected for (later) evaluation as described above, then the
   associated implicit constant declaration (see Ada RM 6.1.1) is not
   elaborated. [In particular, the prefix of the Old attribute_reference is
   not evaluated].


-- Source --


--  old_evaluation.ads

package Old_Evaluation is
   procedure Reset_Self;

   function Self (Val : Integer) return Integer;

   procedure Check_Old (Val : in out Integer)
 with Contract_Cases =>
(Val < 0 => Val = Self (Val)'Old - 1,
 Val = 0 => Val = Self (Val)'Old,
 Val > 0 => Val = Self (Val)'Old + 1);
end Old_Evaluation;

--  old_evaluation.adb

package body Old_Evaluation is
   Self_Called : Boolean := False;

   procedure Check_Old (Val : in out Integer) is
   begin
  if Val < 0 then
 Val := Val - 1;
  elsif Val > 0 then
 Val := Val + 1;
  end if;
   end Check_Old;

   procedure Reset_Self is
   begin
  Self_Called := False;
   end Reset_Self;

   function Self (Val : Integer) return Integer is
   begin
  if Self_Called then
 raise Program_Error;
  else
 Self_Called := True;
 return Val;
  end if;
   end Self;
end Old_Evaluation;

--  old_main.adb

with Ada.Text_IO;use Ada.Text_IO;
with Old_Evaluation; use Old_Evaluation;

procedure Old_Main is
   procedure Test_Value (Val : Integer) is
  Num : Integer := Val;
   begin
  Reset_Self;
  Check_Old (Num);
   exception
  when others => Put_Line ("ERROR:" & Val'Img & " failed");
   end Test_Value;

begin
   Test_Value (-2);
   Test_Value (0);
   Test_Value (5);
end Old_Main;

-
-- Compilation --
-

$ gnatmake -q -gnata old_main.adb
$ ./old_main

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

2014-02-19  Hristian Kirtchev  

* exp_ch6.adb Add with and use clause for Exp_Prag.
(Expand_Contract_Cases): Relocated to Exp_Prag.
* exp_ch6.ads (Expand_Contract_Cases): Relocated to Exp_Prag.
* exp_prag.adb Add with and use clauses for Checks and Validsw.
(Expand_Contract_Cases): Relocated from Exp_Ch6. Update the
structure of the expanded code to showcase the evaluation of
attribute 'Old prefixes. Add local variable Old_Evals. Expand
any attribute 'Old references found within a consequence. Add
circuitry to evaluate the prefixes of attribute 'Old that
belong to a selected consequence.
(Expand_Old_In_Consequence): New routine.
* exp_prag.ads (Expand_Contract_Cases): Relocated from Exp_Ch6.
* sem_attr.adb (Check_Use_In_Contract_Cases): Warn that a
potentially unevaluated prefix is always evaluated.

Index: exp_ch6.adb
===
--- exp_ch6.adb (revision 207890)
+++ exp_ch6.adb (working copy)
@@ -41,6 +41,7 @@
 with Exp_Dist; use Exp_Dist;
 with Exp_Intr; use Exp_Intr;
 with Exp_Pakd; use Exp_Pakd;
+with Exp_Prag; use Exp_Prag;
 with Exp_Tss;  use Exp_Tss;
 with Exp_Util; use Exp_Util;
 with Exp_VFpt; use Exp_VFpt;
@@ -4118,476 +4119,6 @@
   end if;
end Expand_Call;
 
-   ---
-   -- Expand_Contract_Cases --
-   ---
-
-   --  Pragma Contract_Cases is expanded in the following manner:
-
-   --subprogram S is
-   --   Flag_1   : Boolean := False;
-   --   . . .
-   --   Flag_N   : Boolean := False;
-   --   Flag_N+1 : Boolean := False;  --  when "others" present
-   --   Count: Natural := 0;
-
-   --   
-
-   --   if Case_Guard_1 then
-   --  Flag_1 := True;
-   --  Count  := Count + 1;
-   --   end if;
-   --   . . .
-   --   if Case_Guard_N then
-   --  Flag_N := True;
-   --  Count  := Count + 1;
-   --   end if;
-
-   --   if Count = 0 then
-   --  raise Assertion_Error with "xxx contract cases incomplete";
-   --
-   --  Flag_N+1 := True;  --  when "others" present
-
-   --   elsif Count > 1 then
-   --  declare
-   -- Str0 : constant String :=
-   --  "contract cases overlap for subprogram ABC";
-   -- Str1 : constant String :=
-   --  (if Flag_1 then
-   -- Str0 & "case guard at xxx evaluates to True"
-   --   else Str0);
-   -- StrN : constant String :=
-   --  (if Flag_N then
-   -- StrN-1 & "case guard at xxx evaluates to True"
-   --   else StrN-1);
-   --  begin
-   -- raise Assertion_Error with StrN;
-   --  end;
-   --   end if;
-
-   --   procedure _Postconditions is
-   --   begin
-   --  
-
-   --  i

[Ada] Fix removal of side-effects in GNATprove mode

2014-02-19 Thread Arnaud Charlet
In the GNATprove mode for formal verification, side-effects are removed
from expressions when the corresponding procedure is called in the
frontend. This should only be done when not inside a generic, which is
both useless and harmful as it deactivates the mechanism for name
resolution of generic instances. Now fixed.

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

2014-02-19  Yannick Moy  

* exp_util.adb (Remove_Side_Effects): Do not remove side-effects
inside a generic.

Index: exp_util.adb
===
--- exp_util.adb(revision 207892)
+++ exp_util.adb(working copy)
@@ -6638,9 +6638,12 @@
begin
   --  Handle cases in which there is nothing to do. In GNATprove mode,
   --  removal of side effects is useful for the light expansion of
-  --  renamings.
+  --  renamings. This removal should only occur when not inside a
+  --  generic and not doing a pre-analysis.
 
-  if not (Expander_Active or (Full_Analysis and GNATprove_Mode)) then
+  if not Expander_Active
+and (Inside_A_Generic or not Full_Analysis or not GNATprove_Mode)
+  then
  return;
   end if;
 


[Ada] Legality rules for Synchronization aspect on protected operations

2014-02-19 Thread Arnaud Charlet
This patch detects additional errors when a Synchronization aspect on an
overriding protected operation does not match the given aspect on the
overridden operation of an ancestor interface.

Compiling b95000g.ads must yield:

b95000g.ads:29:13:
 type "Lock_Type" must implement abstract subprogram "Unlock" with a
 procedure
b95000g.ads:30:17:
 overriding operation "Unlock_2" must have synchronization
   "BY_PROTECTED_PROCEDURE"
b95000g.ads:32:17:
 type "Lock_Type" must implement abstract subprogram "Lock" with an entry
b95000g.ads:33:17:
 overriding operation "Lock_2" must have syncrhonization "OPTIONAL"
b95000g.ads:38:14:
 overriding operation "Try_Lock" must have syncrhonization "OPTIONAL"

---
-- B95000G.A
--
--*
--
-- OBJECTIVE:
--  Check that primitive procedures of synchronized interfaces with
--  a Synchronization aspect cannot be completed with different callable
--  entity, or can have conflicting 
--
-- CHANGE HISTORY:
--  16 Nov 13   GRB Initial version
--!

package B95000G is
   type Spinlock is synchronized interface;

   procedure Unlock (L : in out Spinlock) is abstract
  with Synchronization => By_Protected_Procedure;
   procedure Lock (L : in out Spinlock) is abstract
  with Synchronization => By_Entry;
   procedure Try_Lock  (L : in out Spinlock; Success : out Boolean) is abstract
  with Synchronization => Optional;
   procedure Unlock_2 (L : in out Spinlock) is abstract
  with Synchronization => By_Protected_Procedure;
   procedure Lock_2 (L : in out Spinlock) is abstract
  with Synchronization => Optional;

   protected type Lock_Type is new Spinlock with
  entry Unlock;  -- ERROR: must be protected procedure
  procedure Unlock_2 
with Synchronization => Optional; -- ERROR: should be By_Prot_Proc
  procedure Lock; -- ERROR: must be entry
  procedure Lock_2 with Synchronization => By_Entry; -- ERROR: is procedure
   private
  Unlocked : Boolean := True;
   end Lock_Type; 

   procedure Try_Lock
 (L   : in out Lock_Type;
  Success : out Boolean) 
   with Synchronization => By_Entry; -- ERROR: is procedure
end B95000G;

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

2014-02-19  Ed Schonberg  

* sem_ch3.adb (Check_Pragma_Implemented): Detect additional
errors when a Synchronization aspect on an overriding protected
operation does not match the given aspect on the overridden
operation of an ancestor interface.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 207879)
+++ sem_ch3.adb (working copy)
@@ -9377,7 +9377,26 @@
Error_Msg_NE
  ("type & must implement abstract subprogram & with a " &
   "procedure", Subp_Alias, Contr_Typ);
+
+elsif Present (Get_Rep_Pragma (Impl_Subp, Name_Implemented))
+  and then Implementation_Kind (Impl_Subp) /= Impl_Kind
+then
+   Error_Msg_Name_1 := Impl_Kind;
+   Error_Msg_N
+("overriding operation& must have synchronization%",
+   Subp_Alias);
 end if;
+
+ --  If primitive has Optional synchronization, overriding operation
+ --  must match if it has an explicit synchronization..
+
+ elsif Present (Get_Rep_Pragma (Impl_Subp, Name_Implemented))
+   and then Implementation_Kind (Impl_Subp) /= Impl_Kind
+ then
+   Error_Msg_Name_1 := Impl_Kind;
+   Error_Msg_N
+("overriding operation& must have syncrhonization%",
+   Subp_Alias);
  end if;
   end Check_Pragma_Implemented;
 


Re: [PING] [PATCH] _Cilk_for for C and C++

2014-02-19 Thread Jakub Jelinek
On Wed, Feb 19, 2014 at 04:43:06AM +, Iyer, Balaji V wrote:
> Attached, please find a patch with the test case attached (for1.cc). The
> patch is the same but the cp-changelog has been modified to reflect the
> new test-case.  Is this OK to install?

1) have you tested the patch at all?  I see
FAIL: g++.dg/gomp/for-1.C -std=c++98  (test for errors, line 27)
FAIL: g++.dg/gomp/for-1.C -std=c++98 (test for excess errors)
FAIL: g++.dg/gomp/for-1.C -std=c++11  (test for errors, line 27)
FAIL: g++.dg/gomp/for-1.C -std=c++11 (test for excess errors)
FAIL: g++.dg/gomp/for-19.C -std=gnu++98 (internal compiler error)
FAIL: g++.dg/gomp/for-19.C -std=gnu++98  (test for warnings, line 30)
FAIL: g++.dg/gomp/for-19.C -std=gnu++98  (test for warnings, line 37)
FAIL: g++.dg/gomp/for-19.C -std=gnu++98  (test for warnings, line 40)
FAIL: g++.dg/gomp/for-19.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/gomp/for-19.C -std=gnu++11 (internal compiler error)
FAIL: g++.dg/gomp/for-19.C -std=gnu++11  (test for warnings, line 30)
FAIL: g++.dg/gomp/for-19.C -std=gnu++11  (test for warnings, line 37)
FAIL: g++.dg/gomp/for-19.C -std=gnu++11  (test for warnings, line 40)
FAIL: g++.dg/gomp/for-19.C -std=gnu++11 (test for excess errors)
regressions caused by the patch, that is of course unacceptable.

2) try this updated cf3.cc, e.g. with -O2 -fcilkplus if you can't find out
why calling something multiple times is a bad idea, actually the latest patch
is even worse than the older one, you now create 3 calls to the end method
and 3 calls to operator-.  There should be just one call to that, before the
#pragma omp parallel obviously, anything that doesn't do that is just bad.
I don't see a point in having if clause on the _Cilk_for, just keep it on
the #pragma omp parallel only, at ompexp time you can easily find it there,
there is no point to check it again in the parallel body of the function.

typedef __PTRDIFF_TYPE__ ptrdiff_t;

template 
class I
{
public:
  typedef ptrdiff_t difference_type;
  I ();
  ~I ();
  I (T *);
  I (const I &);
  T &operator * ();
  T *operator -> ();
  T &operator [] (const difference_type &) const;
  I &operator = (const I &);
  I &operator ++ ();
  I operator ++ (int);
  I &operator -- ();
  I operator -- (int);
  I &operator += (const difference_type &);
  I &operator -= (const difference_type &);
  I operator + (const difference_type &) const;
  I operator - (const difference_type &) const;
  template  friend bool operator == (I &, I &);
  template  friend bool operator == (const I &, const I &);
  template  friend bool operator < (I &, I &);
  template  friend bool operator < (const I &, const I &);
  template  friend bool operator <= (I &, I &);
  template  friend bool operator <= (const I &, const I &);
  template  friend bool operator > (I &, I &);
  template  friend bool operator > (const I &, const I &);
  template  friend bool operator >= (I &, I &);
  template  friend bool operator >= (const I &, const I &);
  template  friend typename I::difference_type operator - (I 
&, I &);
  template  friend typename I::difference_type operator - (const 
I &, const I &);
  template  friend I operator + (typename I::difference_type 
, const I &);
private:
  T *p;
};
template  I::I () : p (0) {}
template  I::~I () {}
template  I::I (T *x) : p (x) {}
template  I::I (const I &x) : p (x.p) {}
template  T &I::operator * () { return *p; }
template  T *I::operator -> () { return p; }
template  T &I::operator [] (const difference_type &x) const { 
return p[x]; }
template  I &I::operator = (const I &x) { p = x.p; return 
*this; }
template  I &I::operator ++ () { ++p; return *this; }
template  I I::operator ++ (int) { return I (p++); }
template  I &I::operator -- () { --p; return *this; }
template  I I::operator -- (int) { return I (p--); }
template  I &I::operator += (const difference_type &x) { p += 
x; return *this; }
template  I &I::operator -= (const difference_type &x) { p -= 
x; return *this; }
template  I I::operator + (const difference_type &x) const { 
return I (p + x); }
template  __attribute__((noinline)) I I::operator - (const 
difference_type &x) const { __asm (""); return I (p - x); }
template  bool operator == (I &x, I &y) { return x.p == y.p; }
template  bool operator == (const I &x, const I &y) { return 
x.p == y.p; }
template  bool operator != (I &x, I &y) { return !(x == y); }
template  bool operator != (const I &x, const I &y) { return 
!(x == y); }
template  bool operator < (I &x, I &y) { return x.p < y.p; }
template  bool operator < (const I &x, const I &y) { return 
x.p < y.p; }
template  bool operator <= (I &x, I &y) { return x.p <= y.p; }
template  bool operator <= (const I &x, const I &y) { return 
x.p <= y.p; }
template  bool operator > (I &x, I &y) { return x.p > y.p; }
template  bool operator > (const I &x, const I &y) { return 
x.p > y.p; }
template  bool operator >= (I &x, I &y) { return x.p >= y.p; }
template  bool operator >= (const I &x, const I &y) { return 
x.p >= y.p; }
te

Re: [Patch, Fortran, OOP] PR 60232: The rank of the element in the structure constructor does not match that of the component

2014-02-19 Thread Janus Weil
Hi,

>> The problem is this: When using a dimensionful function as an
>> EXPR_VARIABLE (e.g. as the target in a procedure pointer assignment),
>> we wrongly add a REF_ARRAY, because we are tricked to believe that the
>> expression is dimensionful
>
>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> Looks good to me. Thanks for the patch!

thanks. Committed as r207896.

Cheers,
Janus


Re: [patch] Fix wrong code with VCE to bit-field type at -O

2014-02-19 Thread Eric Botcazou
> Woudln't it be better to do this in the series of "conversions", that is
> inside the preceeding if-statement?  (the integral type case using
> convert_modes looks weird enough, so adding this kind-of "less"
> weird one there looks sensible)

Yes, the integral type case is very strange: it was introduced in r103660 as

+  /* If both modes are integral, then we can convert from one to the
+other.  */
+  else if (SCALAR_INT_MODE_P (GET_MODE (op0))
+  && SCALAR_INT_MODE_P (TYPE_MODE (type)))
+   op0 = convert_modes (TYPE_MODE (type), GET_MODE (op0), op0, 
+TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (exp, 
0;

which was very problematic (to say the least), so I've restricted it to 
integral types in r158675.  I don't think that we should touch it here.

Something like the attached patch?  This seems to work fine too.

> Ok with moving it there (before the else if (!MEM_P (op0))).  You
> probably want to guard with INTEGRAL_TYPE_P (type) as well,
> not only GET_MODE (op0) != mode - just to prepare for weird
> stuff like a vector-type where TYPE_PRECISION means sth else.

It's already guarded since reduce_bit_field => INTEGRAL_TYPE_P (type).

-- 
Eric BotcazouIndex: expr.c
===
--- expr.c	(revision 207796)
+++ expr.c	(working copy)
@@ -10436,6 +10436,11 @@ expand_expr_real_1 (tree exp, rtx target
   else if (INTEGRAL_TYPE_P (type) && INTEGRAL_TYPE_P (TREE_TYPE (treeop0)))
 	op0 = convert_modes (mode, GET_MODE (op0), op0,
 			 TYPE_UNSIGNED (TREE_TYPE (treeop0)));
+  /* If the output type is a bit-field type, do an extraction.  */
+  else if (reduce_bit_field)
+	return extract_bit_field (op0, TYPE_PRECISION (type), 0,
+  TYPE_UNSIGNED (type), NULL_RTX,
+  mode, mode);
   /* As a last resort, spill op0 to memory, and reload it in a
 	 different mode.  */
   else if (!MEM_P (op0))

[PATCH] Allow cfgcleanup to remove forwarder loop preheaders and latches

2014-02-19 Thread Richard Biener

This allows cfgcleanup to remove some of the extra CFG that exists
just for loop analysis passes convenience (those can be and are
easily re-created by passes doing loop_optimizer_init ()).

It may fix a regression uncovered in private communication.

Untested - my original idea how to fix this (tree_forwarder_block_p
hunk) ran into the issue in remove_forwarder_block which causes
loops to be removed / re-discovered (losing meta-data).

Richard.

2014-02-19  Richard Biener  

* tree-cfgcleanup.c (tree_forwarder_block_p): Protect
latches and preheaders only if requested.
(remove_forwarder_block): Update loop structure if we
removed a forwarder that is a loop latch.

Index: gcc/tree-cfgcleanup.c
===
*** gcc/tree-cfgcleanup.c   (revision 207878)
--- gcc/tree-cfgcleanup.c   (working copy)
*** tree_forwarder_block_p (basic_block bb,
*** 307,321 
  
if (current_loops)
  {
!   basic_block dest;
!   /* Protect loop latches, headers and preheaders.  */
if (bb->loop_father->header == bb)
return false;
-   dest = EDGE_SUCC (bb, 0)->dest;
  
!   if (dest->loop_father->header == dest)
return false;
  }
return true;
  }
  
--- 307,324 
  
if (current_loops)
  {
!   /* Protect loop headers.  */
if (bb->loop_father->header == bb)
return false;
  
!   /* Protect loop latches and preheaders if requested.  */
!   basic_block dest = EDGE_SUCC (bb, 0)->dest;
!   if (dest->loop_father->header == dest
! && (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
! || loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)))
return false;
  }
+ 
return true;
  }
  
*** remove_forwarder_block (basic_block bb)
*** 497,503 
set_immediate_dominator (CDI_DOMINATORS, dest, dom);
  }
  
!   /* And kill the forwarder block.  */
delete_basic_block (bb);
  
return true;
--- 500,511 
set_immediate_dominator (CDI_DOMINATORS, dest, dom);
  }
  
!   /* And kill the forwarder block, but first adjust its parent loop
!  latch info as otherwise the cfg hook has a hard time not to
!  kill the loop.  */
!   if (current_loops
!   && bb->loop_father->latch == bb)
! bb->loop_father->latch = dest;
delete_basic_block (bb);
  
return true;


Re: [patch] Fix wrong code with VCE to bit-field type at -O

2014-02-19 Thread Richard Biener
On Wed, Feb 19, 2014 at 12:55 PM, Eric Botcazou  wrote:
>> Woudln't it be better to do this in the series of "conversions", that is
>> inside the preceeding if-statement?  (the integral type case using
>> convert_modes looks weird enough, so adding this kind-of "less"
>> weird one there looks sensible)
>
> Yes, the integral type case is very strange: it was introduced in r103660 as
>
> +  /* If both modes are integral, then we can convert from one to the
> +other.  */
> +  else if (SCALAR_INT_MODE_P (GET_MODE (op0))
> +  && SCALAR_INT_MODE_P (TYPE_MODE (type)))
> +   op0 = convert_modes (TYPE_MODE (type), GET_MODE (op0), op0,
> +TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (exp,
> 0;
>
> which was very problematic (to say the least), so I've restricted it to
> integral types in r158675.  I don't think that we should touch it here.
>
> Something like the attached patch?  This seems to work fine too.

Yes.  That looks fine.

Thanks,
Richard.

>> Ok with moving it there (before the else if (!MEM_P (op0))).  You
>> probably want to guard with INTEGRAL_TYPE_P (type) as well,
>> not only GET_MODE (op0) != mode - just to prepare for weird
>> stuff like a vector-type where TYPE_PRECISION means sth else.
>
> It's already guarded since reduce_bit_field => INTEGRAL_TYPE_P (type).
>
> --
> Eric Botcazou


Re: RFA: Fix some gcc tests for 16-bit targets

2014-02-19 Thread Richard Biener
On Tue, Feb 18, 2014 at 5:39 PM, nick clifton  wrote:
> Hi Richard,
>
>
>> Instead of modifying testcases I'd be less nervous if you'd make them
>> require 32bit. Otherwise you should reproduce the original issues with the
>> modified testcases.
>
>
> OK, I can do that.  How about this patch.
>
>
> OK to apply ?

Ok.

Thanks,
Richard.

> Cheers
>   Nick
>
> gcc/testsuite/ChangeLog
> 2014-02-18  Nick Clifton  
>
> * gcc.dg/graphite/pr46966.c: Only run on 32-bit+ targets.
> * gcc.dg/pr23623.c: Likewise.
> * gcc.dg/pr48784-1.c: Likewise.
> * gcc.dg/pr48784-2.c: Likewise.
> * gcc.dg/pr56997-2.c: Likewise.
> * gcc.dg/sms-6.c: Likewise.
> * gcc.dg/torture/pr60183.c: Likewise.
> * gcc.dg/torture/vec-cvt-1.c: Likewise.
> * gcc.c-torture/execute/20061220-1.x: New.
> * gcc.c-torture/execute/pr43220.x: New.
> * gcc.c-torture/execute/pr51581-1.x: New.
> * gcc.c-torture/execute/pr51581-2.x: New.
> * gcc.c-torture/execute/pr58570.x: New.
> * gcc.c-torture/unsorted/DFcmp.x: New.
> * gcc.c-torture/unsorted/SFset.x: New.
>


c-parser.c replace error() by error_at()

2014-02-19 Thread Prathamesh Kulkarni
Replace calls to error() by error_at().

* c-parser.c (c_parser_declspecs): replace call to error () by error_at ()
* c-parser.c (c_parser_parameter_declaration): Likewise

Bootstrapped on x86_64-unknown-linux-gnu
Ok for trunk ?

Thanks and Regards,
Prathamesh

Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c (revision 207700)
+++ gcc/c/c-parser.c (working copy)
@@ -2223,7 +2223,7 @@ c_parser_declspecs (c_parser *parser, st
   attrs_ok = true;
   if (kind == C_ID_ID)
 {
-  error ("unknown type name %qE", value);
+  error_at (loc, "unknown type name %qE", value);
   t.kind = ctsk_typedef;
   t.spec = error_mark_node;
 }
@@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
   c_parser_set_source_position_from_token (token);
   if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
  {
-  error ("unknown type name %qE", token->value);
+  error_at (token->location,  "unknown type name %qE", token->value);
   parser->error = true;
  }
   /* ??? In some Objective-C cases '...' isn't applicable so there


Re: [PATCH] Fix sanitizer build on sparc (PR sanitizer/59758)

2014-02-19 Thread Jose E. Marchesi

> On Tue, Feb 18, 2014 at 06:55:51PM +0100, Jose E. Marchesi wrote:
> > This patch fixes builds with --enable-sanitizer, which seems to be the
> > default for sparc now.
> >
> > Build tested in a sparc64-*-linux-gnu system with linux 3.8.13 headers.
> >
> > 2014-02-18  Jose E. Marchesi  
> >
> >   PR sanitizer/59758
> >   * sanitizer_common/sanitizer_platform_limits_posix.h 
(__sanitizer):
> >   Define struct__old_kernel_stat_sz, struct_kernel_stat_sz and
> >   struct_kernel_stat64_sz for sparc targets (both 32 and 64 bits).
> >   (__sanitizer_ipc_perm): Adjust for sparc targets.
> >   (__sanitizer_shmid_ds): Likewise.
> >   (__sanitizer_sigaction): Likewise.
> >   (IOC_SIZE): Likewise.
> >
> >   * sanitizer_common/sanitizer_platform_limits_linux.cc (time_t):
> >   defined as __kernel_time_t, which is needed for sparc.
> >   (struct___old_kernel_stat_sz): Don't check if __sparc__ is 
defined.
>
> Please talk to Konstantin about getting this into the upstream compiler-rt
> repository, we don't need to wait for a merge from there, so once it
> is accepted there, the same patch can be applied to gcc too.

Right. Please read
https://code.google.com/p/address-sanitizer/wiki/HowToContribute

Ok, I follow up on llvm-comm...@cs.uiuc.edu then..




[PATCH] Missing __divtf3@@GCC_4.4.0 on ia64

2014-02-19 Thread Andreas Schwab
Since there is already the __divtf3@GCC_3.0 compatibility alias in
libgcc we need to attach an explicit symbol version to the real __divtf3
in order to get it exported.  This fixes the unversioned reference in
libgfortran.so, and fixes the failure of gfortran.dg/erf_3.F90.  Tested
on ia64-suse-linux.

Andreas.

gcc/testsuite/
PR libfortran/59227
* gfortran.dg/erf_3.F90: Remove XFAIL on ia64-*-linux*.

libgcc/
PR target/59230
PR libfortran/59227
* config/ia64/t-softfp-compat (softfp_file_list): Filter out
soft-fp/divtf3.c.
(LIB2ADD): Add config/ia64/divtf3.c.
* config/ia64/divtf3.c: New file.
---
 gcc/testsuite/gfortran.dg/erf_3.F90 | 5 +
 libgcc/config/ia64/divtf3.c | 9 +
 libgcc/config/ia64/t-softfp-compat  | 3 +++
 3 files changed, 13 insertions(+), 4 deletions(-)
 create mode 100644 libgcc/config/ia64/divtf3.c

diff --git a/gcc/testsuite/gfortran.dg/erf_3.F90 
b/gcc/testsuite/gfortran.dg/erf_3.F90
index d9d6589..e7130f6 100644
--- a/gcc/testsuite/gfortran.dg/erf_3.F90
+++ b/gcc/testsuite/gfortran.dg/erf_3.F90
@@ -1,4 +1,4 @@
-! { dg-do run { xfail spu-*-* ia64-*-linux* } }
+! { dg-do run { xfail spu-*-* } }
 ! { dg-options "-fno-range-check -ffree-line-length-none -O0" }
 ! { dg-add-options ieee }
 !
@@ -7,9 +7,6 @@
 !
 ! XFAILed for SPU targets because our library implementation of
 ! the double-precision erf/erfc functions is not accurate enough.
-!
-! XFAILed for IA64 Linux because of a glibc bug:
-! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227
 
 program test
   use, intrinsic :: iso_fortran_env
diff --git a/libgcc/config/ia64/divtf3.c b/libgcc/config/ia64/divtf3.c
new file mode 100644
index 000..e1afa29
--- /dev/null
+++ b/libgcc/config/ia64/divtf3.c
@@ -0,0 +1,9 @@
+#ifdef SHARED
+#define __divtf3 __divtf3_shared
+#endif
+
+#include "soft-fp/divtf3.c"
+
+#ifdef SHARED
+asm (".symver __divtf3_shared, __divtf3@@GCC_4.4.0");
+#endif
diff --git a/libgcc/config/ia64/t-softfp-compat 
b/libgcc/config/ia64/t-softfp-compat
index 00f45d5..38bcea7 100644
--- a/libgcc/config/ia64/t-softfp-compat
+++ b/libgcc/config/ia64/t-softfp-compat
@@ -5,3 +5,6 @@ libgcc1-tf-functions = __divxf3  _fixtfdi _fixunstfdi _floatditf
 LIB1ASMFUNCS := $(filter-out $(libgcc1-tf-functions), $(LIB1ASMFUNCS))
 libgcc1-tf-compats = $(addsuffix .S, $(libgcc1-tf-functions))
 LIB2ADD += $(addprefix $(srcdir)/config/ia64/, $(libgcc1-tf-compats))
+# Wrap divtf3.c to set the default symbol version
+softfp_file_list := $(filter-out $(srcdir)/soft-fp/divtf3.c, 
$(softfp_file_list))
+LIB2ADD += $(srcdir)/config/ia64/divtf3.c
-- 
1.9.0


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."


[PATCH][i386][AVX512] PR60204 - update abi for large structs.

2014-02-19 Thread Ilya Tocar
Hi everyone,
As AVX512 abi for passing/returing structs was recently changed in
https://github.com/hjl-tools/x86-64-psABI/commit/6d7ccd614fe67111d2aecec853c3df0310b372d2
We need to update GCC accordingly. This patch does it.
It bootstraps, passes make check (including updated abi tests), spec2006
is ok. Ok for trunk?
ChangeLog bellow:

2014-02-19  Ilya Tocar  

* config/i386/i386.c (classify_argument): Update to reflect abi fix.

And for testsuite:

2014-02-19  Ilya Tocar  

* gcc.target/x86_64/abi/avx512f/test_passing_structs.c: Update to
reflect abi fix.
* gcc.target/x86_64/abi/avx512f/test_passing_unions.c: Ditto.

---
 gcc/config/i386/i386.c |  4 +-
 .../x86_64/abi/avx512f/test_passing_structs.c  | 12 +---
 .../x86_64/abi/avx512f/test_passing_unions.c   | 78 +++---
 3 files changed, 12 insertions(+), 82 deletions(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index acfc021..2d16fb9 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -6431,8 +6431,8 @@ classify_argument (enum machine_mode mode, const_tree 
type,
   tree field;
   enum x86_64_reg_class subclasses[MAX_CLASSES];
 
-  /* On x86-64 we pass structures larger than 32 bytes on the stack.  */
-  if (bytes > 32)
+  /* On x86-64 we pass structures larger than 64 bytes on the stack.  */
+  if (bytes > 64)
return 0;
 
   for (i = 0; i < words; i++)
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c 
b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c
index a5e1477..8daa676 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c
+++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c
@@ -26,16 +26,8 @@ check_struct_passing1 (struct m512_struct ms1 
ATTRIBUTE_UNUSED,
   struct m512_struct ms7 ATTRIBUTE_UNUSED,
   struct m512_struct ms8 ATTRIBUTE_UNUSED)
 {
-  /* Check the passing on the stack by comparing the address of the
- stack elements to the expected place on the stack.  */
-  assert ((unsigned long)&ms1.x == rsp+8);
-  assert ((unsigned long)&ms2.x == rsp+72);
-  assert ((unsigned long)&ms3.x == rsp+136);
-  assert ((unsigned long)&ms4.x == rsp+200);
-  assert ((unsigned long)&ms5.x == rsp+264);
-  assert ((unsigned long)&ms6.x == rsp+328);
-  assert ((unsigned long)&ms7.x == rsp+392);
-  assert ((unsigned long)&ms8.x == rsp+456);
+  /* Check register contents.  */
+  check_m512_arguments;
 }
 
 void
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_unions.c 
b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_unions.c
index 9712290..370d15b6 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_unions.c
+++ b/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_unions.c
@@ -52,24 +52,8 @@ check_union_passing1(union un1 u1 ATTRIBUTE_UNUSED,
 union un1 u7 ATTRIBUTE_UNUSED,
 union un1 u8 ATTRIBUTE_UNUSED)
 {
-   /* Check the passing on the stack by comparing the address of the
-  stack elements to the expected place on the stack.  */
-  assert ((unsigned long)&u1.x == rsp+8);
-  assert ((unsigned long)&u1.f == rsp+8);
-  assert ((unsigned long)&u2.x == rsp+72);
-  assert ((unsigned long)&u2.f == rsp+72);
-  assert ((unsigned long)&u3.x == rsp+136);
-  assert ((unsigned long)&u3.f == rsp+136);
-  assert ((unsigned long)&u4.x == rsp+200);
-  assert ((unsigned long)&u4.f == rsp+200);
-  assert ((unsigned long)&u5.x == rsp+264);
-  assert ((unsigned long)&u5.f == rsp+264);
-  assert ((unsigned long)&u6.x == rsp+328);
-  assert ((unsigned long)&u6.f == rsp+328);
-  assert ((unsigned long)&u7.x == rsp+392);
-  assert ((unsigned long)&u7.f == rsp+392);
-  assert ((unsigned long)&u8.x == rsp+456);
-  assert ((unsigned long)&u8.f == rsp+456);
+  /* Check register contents.  */
+  check_m512_arguments;
 }
 
 void
@@ -82,24 +66,8 @@ check_union_passing2(union un2 u1 ATTRIBUTE_UNUSED,
 union un2 u7 ATTRIBUTE_UNUSED,
 union un2 u8 ATTRIBUTE_UNUSED)
 {
-   /* Check the passing on the stack by comparing the address of the
-  stack elements to the expected place on the stack.  */
-  assert ((unsigned long)&u1.x == rsp+8);
-  assert ((unsigned long)&u1.d == rsp+8);
-  assert ((unsigned long)&u2.x == rsp+72);
-  assert ((unsigned long)&u2.d == rsp+72);
-  assert ((unsigned long)&u3.x == rsp+136);
-  assert ((unsigned long)&u3.d == rsp+136);
-  assert ((unsigned long)&u4.x == rsp+200);
-  assert ((unsigned long)&u4.d == rsp+200);
-  assert ((unsigned long)&u5.x == rsp+264);
-  assert ((unsigned long)&u5.d == rsp+264);
-  assert ((unsigned long)&u6.x == rsp+328);
-  assert ((unsigned long)&u6.d == rsp+328);
-  assert ((unsigned long)&u7.x == rsp+392);
-  assert ((unsigned long)&u7.d == rsp+392);
-  assert ((unsigned long)&u8.x == rsp+456);
- 

Re: c-parser.c replace error() by error_at()

2014-02-19 Thread Marek Polacek
On Wed, Feb 19, 2014 at 06:05:12PM +0530, Prathamesh Kulkarni wrote:
> Replace calls to error() by error_at().
> 
> * c-parser.c (c_parser_declspecs): replace call to error () by error_at ()

"Replace", drop ()'s, full stop at the end.

> * c-parser.c (c_parser_parameter_declaration): Likewise

Full stop at the end.

> @@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
>c_parser_set_source_position_from_token (token);
>if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
>   {
> -  error ("unknown type name %qE", token->value);
> +  error_at (token->location,  "unknown type name %qE", token->value);

Only one space between , and ".

It'd be nice to add a testcase as well, e.g. something like this

void
fn1 (const foo x) /* { dg-error "..." } */
{
}

void
fn2 (int i; foo a; int i) /* { dg-error "..." } */
{
}

void
fn3 (char c, foo x, ...) /* { dg-error "..." } */
{
}

Marek


Re: [PATCH][i386][AVX512] PR60204 - update abi for large structs.

2014-02-19 Thread Uros Bizjak
On Wed, Feb 19, 2014 at 2:30 PM, Ilya Tocar  wrote:
> Hi everyone,
> As AVX512 abi for passing/returing structs was recently changed in
> https://github.com/hjl-tools/x86-64-psABI/commit/6d7ccd614fe67111d2aecec853c3df0310b372d2
> We need to update GCC accordingly. This patch does it.
> It bootstraps, passes make check (including updated abi tests), spec2006
> is ok. Ok for trunk?
> ChangeLog bellow:
>
> 2014-02-19  Ilya Tocar  
>
> * config/i386/i386.c (classify_argument): Update to reflect abi fix.

Better say "Pass structures of size 64 bytes or less in register."

> And for testsuite:
>
> 2014-02-19  Ilya Tocar  
>
> * gcc.target/x86_64/abi/avx512f/test_passing_structs.c: Update to
> reflect abi fix.
> * gcc.target/x86_64/abi/avx512f/test_passing_unions.c: Ditto.

Please mention PR target/60204 in both ChangeLogs.

OK for mainline with these (minor) changes.

Thanks,
Uros.


Re: [PATCH] Properly check for _Cilk_spawn in return stmt (PR c/60197)

2014-02-19 Thread Marek Polacek
On Tue, Feb 18, 2014 at 10:06:14PM +, Iyer, Balaji V wrote:
> This is invalid.

Thanks.  In that case, this patch should error out on such invalid uses as
well, instead of ICEing.

Regtested/bootstrapped on x86_64-linux.

2014-02-19  Marek Polacek  

PR c/60197
c-family/
* cilk.c (contains_cilk_spawn_stmt): New function.
(contains_cilk_spawn_stmt_walker): Likewise.
(recognize_spawn): Give error on invalid use of _Cilk_spawn.
* c-common.h (contains_cilk_spawn_stmt): Add declaration.
c/
* c-typeck.c (c_finish_return): Call contains_cilk_spawn_stmt instead
of checking tree code.
cp/
* typeck.c (check_return_expr): Call contains_cilk_spawn_stmt instead
of checking tree code.
testsuite/
* c-c++-common/cilk-plus/CK/pr60197.c: New test.
* c-c++-common/cilk-plus/CK/pr60197-2.c: New test.

diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index f074ab1..1099b10 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -1389,4 +1389,5 @@ extern tree make_cilk_frame (tree);
 extern tree create_cilk_function_exit (tree, bool, bool);
 extern tree cilk_install_body_pedigree_operations (tree);
 extern void cilk_outline (tree, tree *, void *);
+extern bool contains_cilk_spawn_stmt (tree);
 #endif /* ! GCC_C_COMMON_H */
diff --git gcc/c-family/cilk.c gcc/c-family/cilk.c
index f2179dfc..6a7bf4f 100644
--- gcc/c-family/cilk.c
+++ gcc/c-family/cilk.c
@@ -235,6 +235,9 @@ recognize_spawn (tree exp, tree *exp0)
   walk_tree (exp0, unwrap_cilk_spawn_stmt, NULL, NULL);
   spawn_found = true;
 }
+  /* _Cilk_spawn can't be wrapped in expression such as PLUS_EXPR.  */
+  else if (contains_cilk_spawn_stmt (exp))
+error ("invalid use of %<_Cilk_spawn%>");
   return spawn_found;
 }
 
@@ -1292,3 +1295,25 @@ build_cilk_sync (void)
   TREE_SIDE_EFFECTS (sync) = 1;
   return sync;
 }
+
+/* Helper for contains_cilk_spawn_stmt, callback for walk_tree.  Return
+   non-null tree if TP contains CILK_SPAWN_STMT.  */
+
+static tree
+contains_cilk_spawn_stmt_walker (tree *tp, int *, void *)
+{
+  if (TREE_CODE (*tp) == CILK_SPAWN_STMT)
+return *tp;
+  else
+return NULL_TREE;
+}
+
+/* Returns true if EXPR or any of its subtrees contain CILK_SPAWN_STMT
+   node.  */
+
+bool
+contains_cilk_spawn_stmt (tree expr)
+{
+  return walk_tree (&expr, contains_cilk_spawn_stmt_walker, NULL, NULL)
+!= NULL_TREE;
+}
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 2b54290..7c4ba0e 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -9140,7 +9140,7 @@ c_finish_return (location_t loc, tree retval, tree 
origtype)
  return error_mark_node;
}
 }
-  if (flag_cilkplus && retval && TREE_CODE (retval) == CILK_SPAWN_STMT)
+  if (flag_cilkplus && retval && contains_cilk_spawn_stmt (retval))
 {
   error_at (loc, "use of %<_Cilk_spawn%> in a return statement is not "
"allowed");
diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 5fc0e6b..566411f 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -8328,7 +8328,7 @@ check_return_expr (tree retval, bool *no_warning)
 
   *no_warning = false;
 
-  if (flag_cilkplus && retval && TREE_CODE (retval) == CILK_SPAWN_STMT)
+  if (flag_cilkplus && retval && contains_cilk_spawn_stmt (retval))
 {
   error_at (EXPR_LOCATION (retval), "use of %<_Cilk_spawn%> in a return "
"statement is not allowed");
diff --git gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c 
gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
index e69de29..1e5ca00 100644
--- gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
+++ gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197-2.c
@@ -0,0 +1,35 @@
+/* PR c/60197 */
+/* { dg-do compile } */
+/* { dg-options "-fcilkplus" } */
+
+extern int foo (void);
+
+int
+fn1 (void)
+{
+  int i;
+  i = (_Cilk_spawn foo ()) + 1; /* { dg-error "invalid use of" } */
+  return i;
+}
+
+int
+fn2 (void)
+{
+  int i = (_Cilk_spawn foo ()) + 1; /* { dg-error "invalid use of" } */
+  return i;
+}
+
+int
+fn3 (int j, int k, int l)
+{
+  int i = (_Cilk_spawn foo ()) + 1) - l) * k) / j); /* { dg-error "invalid 
use of" } */
+  return i;
+}
+
+int
+fn4 (int j, int k, int l)
+{
+  int i;
+  i = (_Cilk_spawn foo ()) + 1) - l) * k) / j); /* { dg-error "invalid use 
of" } */
+  return i;
+}
diff --git gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197.c 
gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197.c
index e69de29..2b47d1e 100644
--- gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197.c
+++ gcc/testsuite/c-c++-common/cilk-plus/CK/pr60197.c
@@ -0,0 +1,66 @@
+/* PR c/60197 */
+/* { dg-do compile } */
+/* { dg-options "-fcilkplus" } */
+
+extern int foo (void);
+extern int bar (int);
+
+int
+fn1 (void)
+{
+  return (_Cilk_spawn foo ()) * 2; /* { dg-error "in a return statement is not 
allowed" } */
+}
+
+int
+fn2 (void)
+{
+  return (_Cilk_spawn foo ()) > 2; /* { dg-error "in a return statement is not 
allowed" } */
+}
+
+int
+fn3 (int i, int j

Re: [PATCH] Allow cfgcleanup to remove forwarder loop preheaders and latches

2014-02-19 Thread Bin.Cheng
Hi Richard,
Does this have to wait for stage 1? Or I will try to work out a full
patch with loop recreating issue fixed.

On Wed, Feb 19, 2014 at 7:57 PM, Richard Biener  wrote:
>
> This allows cfgcleanup to remove some of the extra CFG that exists
> just for loop analysis passes convenience (those can be and are
> easily re-created by passes doing loop_optimizer_init ()).
>
> It may fix a regression uncovered in private communication.
It's the regression about the code size checks in
gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c

>
> Untested - my original idea how to fix this (tree_forwarder_block_p
> hunk) ran into the issue in remove_forwarder_block which causes
> loops to be removed / re-discovered (losing meta-data).
>
> Richard.
>
> 2014-02-19  Richard Biener  
>
> * tree-cfgcleanup.c (tree_forwarder_block_p): Protect
> latches and preheaders only if requested.
> (remove_forwarder_block): Update loop structure if we
> removed a forwarder that is a loop latch.
>
> Index: gcc/tree-cfgcleanup.c
> ===
> *** gcc/tree-cfgcleanup.c   (revision 207878)
> --- gcc/tree-cfgcleanup.c   (working copy)
> *** tree_forwarder_block_p (basic_block bb,
> *** 307,321 
>
> if (current_loops)
>   {
> !   basic_block dest;
> !   /* Protect loop latches, headers and preheaders.  */
> if (bb->loop_father->header == bb)
> return false;
> -   dest = EDGE_SUCC (bb, 0)->dest;
>
> !   if (dest->loop_father->header == dest)
> return false;
>   }
> return true;
>   }
>
> --- 307,324 
>
> if (current_loops)
>   {
> !   /* Protect loop headers.  */
> if (bb->loop_father->header == bb)
> return false;
>
> !   /* Protect loop latches and preheaders if requested.  */
> !   basic_block dest = EDGE_SUCC (bb, 0)->dest;
> !   if (dest->loop_father->header == dest
> ! && (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
> ! || loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)))
> return false;
>   }
Sorry for being nit-picking here. There is a scenario that bb is
pre-header and loop prop is set to (!LOOPS_HAVE_PREHEADERS &&
LOOPS_HAVE_SIMPLE_LATCHES).  Of course, this may not happen anyway.

> +
> return true;
>   }
>
> *** remove_forwarder_block (basic_block bb)
> *** 497,503 
> set_immediate_dominator (CDI_DOMINATORS, dest, dom);
>   }
>
> !   /* And kill the forwarder block.  */
> delete_basic_block (bb);
>
> return true;
> --- 500,511 
> set_immediate_dominator (CDI_DOMINATORS, dest, dom);
>   }
>
> !   /* And kill the forwarder block, but first adjust its parent loop
> !  latch info as otherwise the cfg hook has a hard time not to
> !  kill the loop.  */
> !   if (current_loops
> !   && bb->loop_father->latch == bb)
> ! bb->loop_father->latch = dest;
> delete_basic_block (bb);
By this code, do you mean to prevent cfgcleanup from
removing/rebuilding the loop struct?
>
> return true;

Thanks,
bin


Re: [AArch64 00/14] Pipeline-independent changes for XGene-1

2014-02-19 Thread Richard Earnshaw
On 18/02/14 21:09, Philipp Tomsich wrote:
> The following patch-set contains the pipeline-independent changes to gcc
> to support the APM XGene-1 and contains various enhancements derived from
> real-world applications and benchmarks running on XGene-1.
> 
> As the pipeline model has not been fully adapted to the new instruction
> typing shared between the ARM backend and the AArch64 backend, it is not
> yet contained in these patches.
> 
> The most controversial part of these patches will likely consist in the
> new cost-model, which has intentionally been provided as a "hook" that
> intercepts the current cost-model when compiling for XGene-1. Given that
> the matching/structure of this cost-model is different from the existing
> implementation, we've chosen to keep this in a separate function for the
> time being.
> 

This patch series is too late for 4.9 and for stage 1 I'd like to see
this fixed before the code goes in.  Code like this rapidly becomes
unmaintainable and makes it difficult to add support for future
variants; it tends to proliferate once started and then it becomes
necessary to analyse every part of the machine description each time a
new device is added to find out whether it needs adjusting.

It should be possible to plug the XGene timings into the current
infrastructure, though it might be necessary to add some new data values
when doing so.

The end goal is that nothing in the back-end, apart from instruction
scheduling, should be testing for a specific CPU; the backend should
make all its code generation decisions from the architecture and tuning
tables.

R.

> 
> Philipp Tomsich (14):
>   Use "generic" target, if no other default.
>   Add "xgene1" core identifier.
>   Retrieve BRANCH_COST from tuning structure.
>   Correct the maximum shift amount for shifted operands.
>   Add AArch64 'prefetch'-pattern.
>   Extend '*tb1'.
>   Define additional patterns for adds/subs.
>   Define a variant of cmp for the CC_NZ case.
>   Add special cases of zero-extend w/ compare operations.
>   Add movcc definition for GPF case.
>   Optimize and(s) patterns for HI/QI operands.
>   Generate 'bics', when only interested in CC_NZ.
>   Initial tuning description for XGene-1 core.
>   Add cost-model for XGene-1.
> 
>  gcc/config/aarch64/aarch64-cores.def |   1 +
>  gcc/config/aarch64/aarch64-protos.h  |   2 +
>  gcc/config/aarch64/aarch64-tune.md   |   2 +-
>  gcc/config/aarch64/aarch64.c | 922 
> ++-
>  gcc/config/aarch64/aarch64.h |  10 +-
>  gcc/config/aarch64/aarch64.md| 246 +-
>  gcc/config/aarch64/iterators.md  |   2 +
>  gcc/config/arm/types.md  |   2 +
>  8 files changed, 1172 insertions(+), 15 deletions(-)
> 




Re: [PATCH] Allow cfgcleanup to remove forwarder loop preheaders and latches

2014-02-19 Thread Richard Biener
On Wed, 19 Feb 2014, Bin.Cheng wrote:

> Hi Richard,
> Does this have to wait for stage 1? Or I will try to work out a full
> patch with loop recreating issue fixed.

If it is a regression and there is a bugzilla about it it doesn't
have to wait.

The patch should be complete (but is untested yet)

> On Wed, Feb 19, 2014 at 7:57 PM, Richard Biener  wrote:
> >
> > This allows cfgcleanup to remove some of the extra CFG that exists
> > just for loop analysis passes convenience (those can be and are
> > easily re-created by passes doing loop_optimizer_init ()).
> >
> > It may fix a regression uncovered in private communication.
> It's the regression about the code size checks in
> gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c

I see.  So it is a regression then.

> >
> > Untested - my original idea how to fix this (tree_forwarder_block_p
> > hunk) ran into the issue in remove_forwarder_block which causes
> > loops to be removed / re-discovered (losing meta-data).
> >
> > Richard.
> >
> > 2014-02-19  Richard Biener  
> >
> > * tree-cfgcleanup.c (tree_forwarder_block_p): Protect
> > latches and preheaders only if requested.
> > (remove_forwarder_block): Update loop structure if we
> > removed a forwarder that is a loop latch.
> >
> > Index: gcc/tree-cfgcleanup.c
> > ===
> > *** gcc/tree-cfgcleanup.c   (revision 207878)
> > --- gcc/tree-cfgcleanup.c   (working copy)
> > *** tree_forwarder_block_p (basic_block bb,
> > *** 307,321 
> >
> > if (current_loops)
> >   {
> > !   basic_block dest;
> > !   /* Protect loop latches, headers and preheaders.  */
> > if (bb->loop_father->header == bb)
> > return false;
> > -   dest = EDGE_SUCC (bb, 0)->dest;
> >
> > !   if (dest->loop_father->header == dest)
> > return false;
> >   }
> > return true;
> >   }
> >
> > --- 307,324 
> >
> > if (current_loops)
> >   {
> > !   /* Protect loop headers.  */
> > if (bb->loop_father->header == bb)
> > return false;
> >
> > !   /* Protect loop latches and preheaders if requested.  */
> > !   basic_block dest = EDGE_SUCC (bb, 0)->dest;
> > !   if (dest->loop_father->header == dest
> > ! && (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
> > ! || loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)))
> > return false;
> >   }
> Sorry for being nit-picking here. There is a scenario that bb is
> pre-header and loop prop is set to (!LOOPS_HAVE_PREHEADERS &&
> LOOPS_HAVE_SIMPLE_LATCHES).  Of course, this may not happen anyway.

Yeah, but then we'd have to detect whether this is a preheader
forwarder or a latch forwarder.  I doubt it happens right now
so I thought it doesn't matter to do it like above.

> > +
> > return true;
> >   }
> >
> > *** remove_forwarder_block (basic_block bb)
> > *** 497,503 
> > set_immediate_dominator (CDI_DOMINATORS, dest, dom);
> >   }
> >
> > !   /* And kill the forwarder block.  */
> > delete_basic_block (bb);
> >
> > return true;
> > --- 500,511 
> > set_immediate_dominator (CDI_DOMINATORS, dest, dom);
> >   }
> >
> > !   /* And kill the forwarder block, but first adjust its parent loop
> > !  latch info as otherwise the cfg hook has a hard time not to
> > !  kill the loop.  */
> > !   if (current_loops
> > !   && bb->loop_father->latch == bb)
> > ! bb->loop_father->latch = dest;
> > delete_basic_block (bb);
> By this code, do you mean to prevent cfgcleanup from
> removing/rebuilding the loop struct?

Yes.  It prevents triggering cfghooks.c:

void
delete_basic_block (basic_block bb)
{
...
  /* If we remove the header or the latch of a loop, mark the loop for
 removal by setting its header and latch to NULL.  */
  if (loop->latch == bb
  || loop->header == bb)
{
  loop->header = NULL;
  loop->latch = NULL;
  loops_state_set (LOOPS_NEED_FIXUP);

generally delete_basic_block has too little context to work out
anything more specific than the above (so it's a very bad tool ;))

Richard.

> >
> > return true;
> 
> Thanks,
> bin
> 


Re: c-parser.c replace error() by error_at()

2014-02-19 Thread Prathamesh Kulkarni
On Wed, Feb 19, 2014 at 7:01 PM, Marek Polacek  wrote:
> On Wed, Feb 19, 2014 at 06:05:12PM +0530, Prathamesh Kulkarni wrote:
>> Replace calls to error() by error_at().
>>
>> * c-parser.c (c_parser_declspecs): replace call to error () by error_at ()
>
> "Replace", drop ()'s, full stop at the end.
>
>> * c-parser.c (c_parser_parameter_declaration): Likewise
>
> Full stop at the end.
>
>> @@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
>>c_parser_set_source_position_from_token (token);
>>if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
>>   {
>> -  error ("unknown type name %qE", token->value);
>> +  error_at (token->location,  "unknown type name %qE", token->value);
>
> Only one space between , and ".
>
> It'd be nice to add a testcase as well, e.g. something like this
>
> void
> fn1 (const foo x) /* { dg-error "..." } */
> {
> }
>
> void
> fn2 (int i; foo a; int i) /* { dg-error "..." } */
> {
> }
>
> void
> fn3 (char c, foo x, ...) /* { dg-error "..." } */
> {
> }
>
Is this fine ?

* c-parser.c (c_parser_declspecs): Replace call to error by error_at.
* c-parser.c (c_parser_parameter_declaration): Likewise.

Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c (revision 207700)
+++ gcc/c/c-parser.c (working copy)
@@ -2223,7 +2223,7 @@ c_parser_declspecs (c_parser *parser, st
   attrs_ok = true;
   if (kind == C_ID_ID)
 {
-  error ("unknown type name %qE", value);
+  error_at (loc, "unknown type name %qE", value);
   t.kind = ctsk_typedef;
   t.spec = error_mark_node;
 }
@@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
   c_parser_set_source_position_from_token (token);
   if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
  {
-  error ("unknown type name %qE", token->value);
+  error_at (token->location, "unknown type name %qE", token->value);
   parser->error = true;
  }
   /* ??? In some Objective-C cases '...' isn't applicable so there
Index: gcc/testsuite/gcc.dg/decl-9.c
===
--- gcc/testsuite/gcc.dg/decl-9.c (revision 207700)
+++ gcc/testsuite/gcc.dg/decl-9.c (working copy)
@@ -30,3 +30,14 @@ void *f3()
   return x; /* { dg-bogus "'x' undeclared" } */
 }

+void
+f4(const foo x) /* { dg-error "unknown type name 'foo'" } */
+{}
+
+void
+f5(int i; foo x, int i) /* { dg-error "unknown type name 'foo'" } */
+{}
+
+void
+f6(char c, foo x, ...) /* { dg-error "unknown type name 'foo'" } */
+{}
> Marek


Re: [PATCH] Allow cfgcleanup to remove forwarder loop preheaders and latches

2014-02-19 Thread Bin.Cheng
On Wed, Feb 19, 2014 at 10:06 PM, Richard Biener  wrote:
> On Wed, 19 Feb 2014, Bin.Cheng wrote:
>
>> Hi Richard,
>> Does this have to wait for stage 1? Or I will try to work out a full
>> patch with loop recreating issue fixed.
>
> If it is a regression and there is a bugzilla about it it doesn't
> have to wait.
>
> The patch should be complete (but is untested yet)
>
>> On Wed, Feb 19, 2014 at 7:57 PM, Richard Biener  wrote:
>> >
>> > This allows cfgcleanup to remove some of the extra CFG that exists
>> > just for loop analysis passes convenience (those can be and are
>> > easily re-created by passes doing loop_optimizer_init ()).
>> >
>> > It may fix a regression uncovered in private communication.
>> It's the regression about the code size checks in
>> gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c
>
> I see.  So it is a regression then.
OK, I will file a PR about it.

>
>> >
>> > Untested - my original idea how to fix this (tree_forwarder_block_p
>> > hunk) ran into the issue in remove_forwarder_block which causes
>> > loops to be removed / re-discovered (losing meta-data).
>> >
>> > Richard.
>> >
>> > 2014-02-19  Richard Biener  
>> >
>> > * tree-cfgcleanup.c (tree_forwarder_block_p): Protect
>> > latches and preheaders only if requested.
>> > (remove_forwarder_block): Update loop structure if we
>> > removed a forwarder that is a loop latch.
>> >
>> > Index: gcc/tree-cfgcleanup.c
>> > ===
>> > *** gcc/tree-cfgcleanup.c   (revision 207878)
>> > --- gcc/tree-cfgcleanup.c   (working copy)
>> > *** tree_forwarder_block_p (basic_block bb,
>> > *** 307,321 
>> >
>> > if (current_loops)
>> >   {
>> > !   basic_block dest;
>> > !   /* Protect loop latches, headers and preheaders.  */
>> > if (bb->loop_father->header == bb)
>> > return false;
>> > -   dest = EDGE_SUCC (bb, 0)->dest;
>> >
>> > !   if (dest->loop_father->header == dest)
>> > return false;
>> >   }
>> > return true;
>> >   }
>> >
>> > --- 307,324 
>> >
>> > if (current_loops)
>> >   {
>> > !   /* Protect loop headers.  */
>> > if (bb->loop_father->header == bb)
>> > return false;
>> >
>> > !   /* Protect loop latches and preheaders if requested.  */
>> > !   basic_block dest = EDGE_SUCC (bb, 0)->dest;
>> > !   if (dest->loop_father->header == dest
>> > ! && (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
>> > ! || loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)))
>> > return false;
>> >   }
>> Sorry for being nit-picking here. There is a scenario that bb is
>> pre-header and loop prop is set to (!LOOPS_HAVE_PREHEADERS &&
>> LOOPS_HAVE_SIMPLE_LATCHES).  Of course, this may not happen anyway.
>
> Yeah, but then we'd have to detect whether this is a preheader
> forwarder or a latch forwarder.  I doubt it happens right now
> so I thought it doesn't matter to do it like above.
>
>> > +
>> > return true;
>> >   }
>> >
>> > *** remove_forwarder_block (basic_block bb)
>> > *** 497,503 
>> > set_immediate_dominator (CDI_DOMINATORS, dest, dom);
>> >   }
>> >
>> > !   /* And kill the forwarder block.  */
>> > delete_basic_block (bb);
>> >
>> > return true;
>> > --- 500,511 
>> > set_immediate_dominator (CDI_DOMINATORS, dest, dom);
>> >   }
>> >
>> > !   /* And kill the forwarder block, but first adjust its parent loop
>> > !  latch info as otherwise the cfg hook has a hard time not to
>> > !  kill the loop.  */
>> > !   if (current_loops
>> > !   && bb->loop_father->latch == bb)
>> > ! bb->loop_father->latch = dest;
>> > delete_basic_block (bb);
>> By this code, do you mean to prevent cfgcleanup from
>> removing/rebuilding the loop struct?
>
> Yes.  It prevents triggering cfghooks.c:
>
> void
> delete_basic_block (basic_block bb)
> {
> ...
>   /* If we remove the header or the latch of a loop, mark the loop for
>  removal by setting its header and latch to NULL.  */
>   if (loop->latch == bb
>   || loop->header == bb)
> {
>   loop->header = NULL;
>   loop->latch = NULL;
>   loops_state_set (LOOPS_NEED_FIXUP);
>
> generally delete_basic_block has too little context to work out
> anything more specific than the above (so it's a very bad tool ;))

Well, it can't.  From what I observed, it is pass_ch that modifies the
loop header with some specific control flow graph.  Doesn't matter if
the LOOPS_NEED_FIXUP is set before pass_ch, since it calls
loop_optimizer_init to fix loop structure before starting work.  In
another word, pass_ch always starts with LOOPS_NEED_FIXUP cleared.

I will do further investigation on pass_ch.

Thanks,
bin
>
> Richard.
>



-- 
Best Regards.


Re: c-parser.c replace error() by error_at()

2014-02-19 Thread Marek Polacek
On Wed, Feb 19, 2014 at 07:43:56PM +0530, Prathamesh Kulkarni wrote:
> Index: gcc/testsuite/gcc.dg/decl-9.c
> ===
> --- gcc/testsuite/gcc.dg/decl-9.c (revision 207700)
> +++ gcc/testsuite/gcc.dg/decl-9.c (working copy)
> @@ -30,3 +30,14 @@ void *f3()
>return x; /* { dg-bogus "'x' undeclared" } */
>  }
> 
> +void
> +f4(const foo x) /* { dg-error "unknown type name 'foo'" } */
> +{}
> +
> +void
> +f5(int i; foo x, int i) /* { dg-error "unknown type name 'foo'" } */
> +{}
> +
> +void
> +f6(char c, foo x, ...) /* { dg-error "unknown type name 'foo'" } */
> +{}

I'd omit the 'foo' in dg-error and please create a new testcase for this,
don't reuse decl-9.c.

Otherwise looks good (can't approve though), thanks.

Marek


Re: [AArch64 00/14] Pipeline-independent changes for XGene-1

2014-02-19 Thread Ramana Radhakrishnan
On Tue, Feb 18, 2014 at 9:09 PM, Philipp Tomsich
 wrote:
> The following patch-set contains the pipeline-independent changes to gcc
> to support the APM XGene-1 and contains various enhancements derived from
> real-world applications and benchmarks running on XGene-1.
>
> As the pipeline model has not been fully adapted to the new instruction
> typing shared between the ARM backend and the AArch64 backend, it is not
> yet contained in these patches.
>
> The most controversial part of these patches will likely consist in the
> new cost-model, which has intentionally been provided as a "hook" that
> intercepts the current cost-model when compiling for XGene-1. Given that
> the matching/structure of this cost-model is different from the existing
> implementation, we've chosen to keep this in a separate function for the
> time being.

And please produce Changelog entries for each of the changes. Can I
also ask you to confirm that you have a copyright assignment with the
FSF on file for contributing these changes ?


Ramana

>
>
> Philipp Tomsich (14):
>   Use "generic" target, if no other default.
>   Add "xgene1" core identifier.
>   Retrieve BRANCH_COST from tuning structure.
>   Correct the maximum shift amount for shifted operands.
>   Add AArch64 'prefetch'-pattern.
>   Extend '*tb1'.
>   Define additional patterns for adds/subs.
>   Define a variant of cmp for the CC_NZ case.
>   Add special cases of zero-extend w/ compare operations.
>   Add movcc definition for GPF case.
>   Optimize and(s) patterns for HI/QI operands.
>   Generate 'bics', when only interested in CC_NZ.
>   Initial tuning description for XGene-1 core.
>   Add cost-model for XGene-1.
>
>  gcc/config/aarch64/aarch64-cores.def |   1 +
>  gcc/config/aarch64/aarch64-protos.h  |   2 +
>  gcc/config/aarch64/aarch64-tune.md   |   2 +-
>  gcc/config/aarch64/aarch64.c | 922 
> ++-
>  gcc/config/aarch64/aarch64.h |  10 +-
>  gcc/config/aarch64/aarch64.md| 246 +-
>  gcc/config/aarch64/iterators.md  |   2 +
>  gcc/config/arm/types.md  |   2 +
>  8 files changed, 1172 insertions(+), 15 deletions(-)
>
> --
> 1.9.0
>


[Ada] Do not perform expansion of generics even in GNATprove mode

2014-02-19 Thread Arnaud Charlet
In GNATprove mode for formal verification, some treatment typically only
done during expansion needs to be performed on the tree, but it should
not be applied inside generics. Otherwise, this breaks the name
resolution mechanism for genetic instances. This completes a previous
similar fix.

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

2014-02-19  Yannick Moy  

* expander.adb (Expand): Do nothing inside generics.
* sem_aggr.adb (Aggregate_Constraint_Checks): Do nothing inside
generics.

Index: sem_aggr.adb
===
--- sem_aggr.adb(revision 207879)
+++ sem_aggr.adb(working copy)
@@ -459,7 +459,9 @@
   --  added in the tree, so that the formal verification can rely on those
   --  to be present.
 
-  if not (Expander_Active or GNATprove_Mode) or In_Spec_Expression then
+  if not Expander_Active
+and (Inside_A_Generic or not Full_Analysis or not GNATprove_Mode)
+  then
  return;
   end if;
 
Index: expander.adb
===
--- expander.adb(revision 207879)
+++ expander.adb(working copy)
@@ -90,7 +90,8 @@
   --  analysis, in which case Full_Analysis = True or a pre-analysis in
   --  which case Full_Analysis = False. See the spec of Sem for more info
   --  on this. Additionally, the GNATprove_Mode flag indicates that a light
-  --  expansion for formal verification should be used.
+  --  expansion for formal verification should be used. This expansion is
+  --  never done inside generics.
 
   --  The second reason for the Expander_Active flag to be False is that
   --  we are performing a pre-analysis. During pre-analysis all expansion
@@ -108,7 +109,9 @@
   --  given that the expansion actions that would normally process it will
   --  not take place. This prevents cascaded errors due to stack mismatch.
 
-  if not (Expander_Active or (Full_Analysis and GNATprove_Mode)) then
+  if not Expander_Active
+and (Inside_A_Generic or not Full_Analysis or not GNATprove_Mode)
+  then
  Set_Analyzed (N, Full_Analysis);
 
  if Serious_Errors_Detected > 0 and then Scope_Is_Transient then


[PATCH ARM] Fix PR60264 (ICE in dwarf2out_frame_debug_adjust_cfa) part 2

2014-02-19 Thread Christian Bruel
Hello,

This patch is a followup of
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01042.html

If fixes a bunch of ICEs for the testsuite ran with
--target_board=arm-sim/\{-mapcs-frame\},  noticed on a reference branch
for testing the former patch.

One of the strange issue I had to deal with, for instance with
./gcc.c-torture/compile/991202-1.c,  is that the epilogue emitted the
CFA notes in the following order:

(set/f (reg:SI 12 ip)
(plus:SI (reg:SI 12 ip)
(const_int 16 [0x10])))
(set/f (reg:DF 32 s16)
(mem/c:DF (reg:SI 12 ip) [3  S8 A64]))
(set/f (reg:DF 34 s18)
(mem/c:DF (plus:SI (reg:SI 12 ip)
(const_int 8 [0x8])) [3  S8 A64]))
]) /home/bruelc/tmp/991202-1.c:18 347
{*vfp_pop_multiple_with_writeback}
 (expr_list:REG_UNUSED (reg:SI 12 ip)
(expr_list:REG_CFA_ADJUST_CFA (set (reg:SI 12 ip)
(plus:SI (reg:SI 12 ip)
(const_int 16 [0x10])))
(expr_list:REG_CFA_DEF_CFA (reg/f:SI 11 fp)
(expr_list:REG_CFA_RESTORE (reg:DF 34 s18)
(expr_list:REG_CFA_RESTORE (reg:DF 32 s16)
(nil)))

but shrink-wrapping duplicates it as

(insn/f:TI 140 137 171 (parallel [
(set/f (reg:SI 12 ip)
(plus:SI (reg:SI 12 ip)
(const_int 16 [0x10])))
(set/f (reg:DF 32 s16)
(mem/c:DF (reg:SI 12 ip) [3  S8 A64]))
(set/f (reg:DF 34 s18)
(mem/c:DF (plus:SI (reg:SI 12 ip)
(const_int 8 [0x8])) [3  S8 A64]))
]) /home/bruelc/tmp/991202-1.c:18 347
{*vfp_pop_multiple_with_writeback}
 (expr_list:REG_UNUSED (reg:SI 12 ip)
(expr_list:REG_CFA_RESTORE (reg:DF 32 s16)
(expr_list:REG_CFA_RESTORE (reg:DF 34 s18)
(expr_list:REG_CFA_DEF_CFA (reg/f:SI 11 fp)
(expr_list:REG_CFA_ADJUST_CFA (set (reg:SI 12 ip)
(plus:SI (reg:SI 12 ip)
(const_int 16 [0x10])))
(nil)))

Since the CFA_RESTORE order is inverted with CFA_DEF_CFA, cur_cfa->reg
was set with IP instead of FP

I fixed this by not emitting the CFA_ADJUST_CFA in this case, since it's
not needed anyway as we have:

fldmfddip!, {d8-d9}@ 140*vfp_pop_multiple_with_writeback
subsp, fp, #12@ 142  
ldmfdsp, {fp, sp, pc}@ 143   

so after @140 cur_cfa can't be IP.

Regression tested for for armv7-a
--target_board=arm-sim/\{,-mapcs-frame\}. Fixes a large number of tests

OK for trunk ?

Many thanks


--- config/arm/arm.c	2014-02-19 15:28:34.0 +0100
+++ /work1/bruel/superh_elf/gnu_trunk.devs/gcc/gcc/config/arm/arm.c	2014-02-19 14:30:44.0 +0100
@@ -19911,10 +19911,14 @@
 
   /* Make sure cfa doesn't leave with IP_REGNUM.  */
   if (TARGET_VFP && REGNO (base_reg) == IP_REGNUM)
-add_reg_note (par, REG_CFA_DEF_CFA, hard_frame_pointer_rtx);
+{
+  RTX_FRAME_RELATED_P (par) = 1;
+  add_reg_note (par, REG_CFA_DEF_CFA, hard_frame_pointer_rtx);
+}
+  else
+arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs,
+ base_reg, base_reg);
 
-  arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs,
-			   base_reg, base_reg);
 
 }
 
@@ -27109,8 +27113,8 @@
   if (saved_size > 0)
 {
 	  rtx insn;
-	  floats_from_frame += saved_size;
-	  insn = emit_insn (gen_addsi3 (gen_rtx_REG (SImode, IP_REGNUM),
+  floats_from_frame += saved_size;
+  insn = emit_insn (gen_addsi3 (gen_rtx_REG (SImode, IP_REGNUM),
 	hard_frame_pointer_rtx,
 	GEN_INT (-floats_from_frame)));
 	  RTX_FRAME_RELATED_P (insn) = 1;
@@ -27192,7 +27196,9 @@
   insn = emit_insn (gen_addsi3 (stack_pointer_rtx,
 hard_frame_pointer_rtx,
 GEN_INT (- 4 * num_regs)));
-  RTX_FRAME_RELATED_P (insn) = 1;
+
+  arm_add_cfa_adjust_cfa_note (insn, - 4 * num_regs,
+   stack_pointer_rtx, hard_frame_pointer_rtx);
 }
 
   arm_emit_multi_reg_pop (saved_regs_mask);


[Ada] Duplicate projects due to symbolic links

2014-02-19 Thread Arnaud Charlet
When the same projec is imported by several projects in the project tree
through different paths that includes symbolic links, the Project Manager
may reported an error indicating that two different projects have the
same name. This is corrected by this patch.

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

2014-02-19  Vincent Celier  

* prj-part.adb (Parse_Single_Project): Use the fully resolved
project path, with all symbolic links resolved, to check if the
same project is imported with a different unresolved path.
* prj-tree.ads (Project_Name_And_Node): Component Canonical_Path
changed to Resolved_Path to reflect that all symbolic links
are resolved.

Index: prj-part.adb
===
--- prj-part.adb(revision 207879)
+++ prj-part.adb(working copy)
@@ -1126,8 +1126,8 @@
 
 if Project_Qualifier_Of (Imported, In_Tree) = Aggregate then
Error_Msg_Name_1 := Name_Id (Path_Name_Of (Imported, In_Tree));
-  Error_Msg
-(Flags, "cannot import aggregate project %%", Token_Ptr);
+   Error_Msg
+ (Flags, "cannot import aggregate project %%", Token_Ptr);
exit;
 end if;
 
@@ -1280,6 +1280,7 @@
 
   Normed_Path_Name: Path_Name_Type;
   Canonical_Path_Name : Path_Name_Type;
+  Resolved_Path_Name  : Path_Name_Type;
   Project_Directory   : Path_Name_Type;
   Project_Scan_State  : Saved_Project_Scan_State;
   Source_Index: Source_File_Index;
@@ -1329,6 +1330,20 @@
  Name_Len := Canonical_Path'Length;
  Name_Buffer (1 .. Name_Len) := Canonical_Path;
  Canonical_Path_Name := Name_Find;
+
+ if Opt.Follow_Links_For_Files then
+Resolved_Path_Name := Canonical_Path_Name;
+
+ else
+Name_Len := 0;
+Add_Str_To_Name_Buffer
+  (Normalize_Pathname
+ (Canonical_Path,
+  Resolve_Links => True,
+  Case_Sensitive => False));
+Resolved_Path_Name := Name_Find;
+ end if;
+
   end;
 
   if Has_Circular_Dependencies
@@ -1351,7 +1366,7 @@
   while
 A_Project_Name_And_Node /= Tree_Private_Part.No_Project_Name_And_Node
   loop
- if A_Project_Name_And_Node.Canonical_Path = Canonical_Path_Name then
+ if A_Project_Name_And_Node.Resolved_Path = Resolved_Path_Name then
 if Extended then
 
if A_Project_Name_And_Node.Extended then
@@ -1773,6 +1788,17 @@
 
   if Present (Extended_Project) then
 
+ if Project_Qualifier_Of (Extended_Project, In_Tree) =
+   Aggregate
+ then
+Error_Msg_Name_1 :=
+  Name_Id (Path_Name_Of (Extended_Project, In_Tree));
+Error_Msg
+  (Env.Flags,
+   "cannot extend aggregate project %%",
+   Location_Of (Project, In_Tree));
+ end if;
+
  --  A project that extends an extending-all project is
  --  also an extending-all project.
 
@@ -1987,7 +2013,7 @@
 E => (Name   => Name_Of_Project,
   Display_Name   => Display_Name_Of_Project,
   Node   => Project,
-  Canonical_Path => Canonical_Path_Name,
+  Resolved_Path  => Resolved_Path_Name,
   Extended   => Extended,
   From_Extended  => From_Extended /= None,
   Proj_Qualifier => Project_Qualifier_Of (Project, In_Tree)));
Index: prj-tree.adb
===
--- prj-tree.adb(revision 207893)
+++ prj-tree.adb(working copy)
@@ -2922,7 +2922,7 @@
 Prj.Tree.Tree_Private_Part.Project_Name_And_Node'
   (Name   => Name,
Display_Name   => Name,
-   Canonical_Path => No_Path,
+   Resolved_Path  => No_Path,
Node   => Project,
Extended   => False,
From_Extended  => False,
Index: prj-tree.ads
===
--- prj-tree.ads(revision 207879)
+++ prj-tree.ads(working copy)
@@ -1469,7 +1469,7 @@
  Node : Project_Node_Id;
  --  Node of the project in table Project_Nodes
 
- Canonical_Path : Path_Name_Type;
+ Resolved_Path : Path_Name_Type;
  --  Resolved and canonical path of a real project file.
  --  No_Name in case of virtual projects.
 
@@ -1488,7 +1488,7 @@
 (Name   => No_Name,
  Display_Name   => No_Name,
  

[PATCH] Fix up preprocessing of #pragma GCC ivdep (PR c++/60267)

2014-02-19 Thread Jakub Jelinek
Hi!

In #pragma GCC ivdep there is nothing the preprocessor should care about,
thus there is no reason to register it when doing just -E (and, otherwise
we'd have to handle PRAGMA_IVDEP in pragma lookups).

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2014-02-19  Jakub Jelinek  

PR c++/60267
* c-pragma.c (init_pragma): Don't call cpp_register_deferred_pragma
for PRAGMA_IVDEP if flag_preprocess_only.

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

--- gcc/c-family/c-pragma.c.jj  2014-02-12 17:46:22.0 +0100
+++ gcc/c-family/c-pragma.c 2014-02-19 09:49:08.410079037 +0100
@@ -1392,8 +1392,9 @@ init_pragma (void)
 cpp_register_deferred_pragma (parse_in, "GCC", "pch_preprocess",
  PRAGMA_GCC_PCH_PREPROCESS, false, false);
 
-  cpp_register_deferred_pragma (parse_in, "GCC", "ivdep", PRAGMA_IVDEP, false,
-   false);
+  if (!flag_preprocess_only)
+cpp_register_deferred_pragma (parse_in, "GCC", "ivdep", PRAGMA_IVDEP, 
false,
+ false);
 #ifdef HANDLE_PRAGMA_PACK_WITH_EXPANSION
   c_register_pragma_with_expansion (0, "pack", handle_pragma_pack);
 #else
--- gcc/testsuite/gcc.dg/pr60267.c.jj   2014-02-19 09:57:15.083327458 +0100
+++ gcc/testsuite/gcc.dg/pr60267.c  2014-02-19 09:57:51.383122054 +0100
@@ -0,0 +1,14 @@
+/* PR c++/60267 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -save-temps" } */
+
+void
+foo (int *a, int *b, int *c)
+{
+  int i;
+#pragma GCC ivdep
+  for (i = 0; i < 64; i++)
+a[i] = b[i] * c[i];
+}
+
+/* { dg-final { cleanup-saved-temps } } */

Jakub


Re: c-parser.c replace error() by error_at()

2014-02-19 Thread Prathamesh Kulkarni
On Wed, Feb 19, 2014 at 7:56 PM, Marek Polacek  wrote:
> On Wed, Feb 19, 2014 at 07:43:56PM +0530, Prathamesh Kulkarni wrote:
>> Index: gcc/testsuite/gcc.dg/decl-9.c
>> ===
>> --- gcc/testsuite/gcc.dg/decl-9.c (revision 207700)
>> +++ gcc/testsuite/gcc.dg/decl-9.c (working copy)
>> @@ -30,3 +30,14 @@ void *f3()
>>return x; /* { dg-bogus "'x' undeclared" } */
>>  }
>>
>> +void
>> +f4(const foo x) /* { dg-error "unknown type name 'foo'" } */
>> +{}
>> +
>> +void
>> +f5(int i; foo x, int i) /* { dg-error "unknown type name 'foo'" } */
>> +{}
>> +
>> +void
>> +f6(char c, foo x, ...) /* { dg-error "unknown type name 'foo'" } */
>> +{}
>
> I'd omit the 'foo' in dg-error and please create a new testcase for this,
> don't reuse decl-9.c.
Ok. I moved the test cases into new file decl-10.c (suggest a better name ?)
>
> Otherwise looks good (can't approve though), thanks.
>
[gcc/c]
* c-parser.c (c_parser_declspecs): Replace call to error by error_at.
* c-parser.c (c_parser_parameter_declaration): Likewise.

[gcc/testsuite]
* gcc.dg/decl-10.c: New test case.

Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c (revision 207700)
+++ gcc/c/c-parser.c (working copy)
@@ -2223,7 +2223,7 @@ c_parser_declspecs (c_parser *parser, st
   attrs_ok = true;
   if (kind == C_ID_ID)
 {
-  error ("unknown type name %qE", value);
+  error_at (loc, "unknown type name %qE", value);
   t.kind = ctsk_typedef;
   t.spec = error_mark_node;
 }
@@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
   c_parser_set_source_position_from_token (token);
   if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
  {
-  error ("unknown type name %qE", token->value);
+  error_at (token->location, "unknown type name %qE", token->value);
   parser->error = true;
  }
   /* ??? In some Objective-C cases '...' isn't applicable so there
Index: gcc/testsuite/gcc.dg/decl-10.c
===
--- gcc/testsuite/gcc.dg/decl-10.c (revision 0)
+++ gcc/testsuite/gcc.dg/decl-10.c (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+void
+f4(const foo x) /* { dg-error "unknown type name" } */
+{}
+
+void
+f5(foo x, int i) /* { dg-error "unknown type name" } */
+{}
+
+void
+f6(char c, foo x, ...) /* { dg-error "unknown type name" } */
+{}

> Marek


RFA: fix compile/pr17906.c / compile/pr35432.c -O3 -g ICEs

2014-02-19 Thread Joern Rennecke
When compiling compile/pr17906.c, compute_frame_pointer_to_fb_displacement
passes the argument pointer to eliminate_regs.  This eliminates it to
the frame pointer,
which later causes and ICE because frame_pointer_needed is not set.

The problem is that ELIMINABLE_REGS in avr.h does not specify a direct
elimination
from the argument pointer to the stack pointer; the attached patch
rectifies that.
Regression tested with the avr simulator.

OK to apply?


fb_offset-fix
Description: Binary data


Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

2014-02-19 Thread Janus Weil
Hi all,

the patch below has been posted a long time ago, but was never
actually committed (although it seems close to being finished).

Could it still be considered for trunk? I think it is a rather popular
feature, which would be helpful for many users ...

Cheers,
Janus



2013-03-19 22:17 GMT+01:00 Tobias Burnus :
> Dear Paul, dear all,
>
>
> On February 24, 2013 Paul Richard Thomas wrote:
>>
>> The attached patch represents progress to date.  It fixes the original
>> problem in this PR and allows John Reid's version of
>> iso_varying_string/vocabulary_word_count.f90 to compile and run
>> correctly.  It even bootstraps and regtests!
>
>
> Attached is a re-diffed patch; I have additionally fixed some indenting
> issues.
>
> Additionally, I have tested the patch - and it fails with deferred-length
> *array* character components. See attached test case. Also, the following
> line of the included test case leaks memory:
> allocate (array(2), source = [t("abcedefg","hi"), t("jkl","mnop")])
>
> I think at least the array bug should be fixed prior committal. (Fixing the
> memory leak and some of the below-mentioned issues would be nice, too.)
> Otherwise, I think the patch looks fine. For completeness, I have some
> naming remarks, which I would also like to considered:
> http://thread.gmane.org/gmane.comp.gcc.fortran/40393/focus=281580
>
> Tobias
>
>
>> However, it doe not fix:
>> PR51976 comment #6 and PR51550 - allocate with typespec ICEs
>> PR51976 comment #6 FORALL assignment is messed up and ICEs..
>> PR47545 the compiler complains about the lack of an initializer for
>> the hidden character length field.
>> PR45170 will need going through from one end to the other - there is a
>> lot of "stuff" here!
>>
>> Of these, I consider the fix of the PR47545 problem to be a must and
>> the allocate with typespec desirable.


[C++ PATCH] Handle #pragma GCC ivdep during tsubst (PR c++/60267)

2014-02-19 Thread Jakub Jelinek
Hi!

This patch fixes ICE on #pragma GCC ivdep used in templates.

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

2014-02-19  Jakub Jelinek  

PR c++/60267
* pt.c (tsubst_expr): Handle ANNOTATE_EXPR.

* g++.dg/ext/ivdep-1.C: New test.

--- gcc/cp/pt.c.jj  2014-02-18 08:18:51.0 +0100
+++ gcc/cp/pt.c 2014-02-19 10:30:24.201080070 +0100
@@ -13806,6 +13806,11 @@ tsubst_expr (tree t, tree args, tsubst_f
RECUR (TREE_OPERAND (t, 1)),
complain));
 
+case ANNOTATE_EXPR:
+  tmp = RECUR (TREE_OPERAND (t, 0));
+  RETURN (build2_loc (EXPR_LOCATION (t), ANNOTATE_EXPR,
+ TREE_TYPE (tmp), tmp, RECUR (TREE_OPERAND (t, 1;
+
 default:
   gcc_assert (!STATEMENT_CODE_P (TREE_CODE (t)));
 
--- gcc/testsuite/g++.dg/ext/ivdep-1.C.jj   2014-02-19 10:31:41.867639731 
+0100
+++ gcc/testsuite/g++.dg/ext/ivdep-1.C  2014-02-19 10:30:59.0 +0100
@@ -0,0 +1,18 @@
+// PR c++/60267
+// { dg-do compile }
+// { dg-options "-O3" }
+
+template 
+void
+foo (int *a, int *b, int *c)
+{
+#pragma GCC ivdep
+  for (int i = 0; i < N; i++)
+a[i] = b[i] * c[i];
+}
+
+void
+bar (int *a, int *b, int *c)
+{
+  foo <64> (a, b, c);
+}

Jakub


[C++ PATCH] Fix up DW_AT_explicit handling (PR debug/56563)

2014-02-19 Thread Jakub Jelinek
Hi!

Say on
struct S { explicit S () {}; } s;
struct T { explicit T (int x) {}; } t(2);
struct U { explicit operator int () { return 6; } } u;
G++ mysteriously emits DW_AT_explicit only on T::T(int) and not
on S::S() nor U::operator int().

Fixed thusly, ok for trunk?

2014-02-19  Jakub Jelinek  

PR debug/56563
* cp-objcp-common.c (cp_function_decl_explicit_p): Remove
FUNCTION_FIRST_USER_PARMTYPE (decl) != void_list_node check.

--- gcc/cp/cp-objcp-common.c.jj 2014-01-02 23:50:57.0 +0100
+++ gcc/cp/cp-objcp-common.c2014-02-19 15:13:05.576141197 +0100
@@ -160,7 +160,6 @@ bool
 cp_function_decl_explicit_p (tree decl)
 {
   return (decl
- && FUNCTION_FIRST_USER_PARMTYPE (decl) != void_list_node
  && DECL_LANG_SPECIFIC (STRIP_TEMPLATE (decl))
  && DECL_NONCONVERTING_P (decl));
 }

Jakub


Re: [PATCH 1/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

2014-02-19 Thread Ilmir Usmanov

Hi Tobias!

Thanks a lot for your review!

I have tested your notes on two compilers which support OpenACC: PGI 
14.1 and CAPS 3.4.1.


If I made a mistake and you've collected results which differ from mine 
(whether you compiler is one of the above or not), please, let me know.


Unfortunally, neither PGI nor CAPS don't support Fortran 2008.

These are results:

On 10.02.2014 02:22, Tobias Burnus wrote:


a) Does this part work well when both -fopenmp and -fopenacc is used? 
I mean: "!$acc loop" followed/preceded by "!$omp do"? I could imagine 
that there could be clashes, especially when - e.g. - collapse doesn't 
match.

PGI: Silently ignores OpenMP pragmas.
CAPS: Ignored option '--define' (_OPENMP=).



b) Do you also handle DO CONCURRENT - either by rejecting it or by 
accepting it? Namely,


!$acc loop
do concurrent(i=1:5)
end do
!$acc end loop
end
Side remark, with -fopenmp, it does ICE: 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60127



My implemetation also fails, will fix.
By the way, should we support these loops? I think we should, since DO 
CONCURRENT loops are parallelizable.




Talking about "!$acc loop": I vaguely remember that OpenACC 1.0's spec 
doesn't have "!$acc end loop" while I have seen OpenACC programs which 
use it. How do you handle "!$acc end loop"?
Looking at parse.c, it seems to simply error out. I wonder whether one 
should be a bit more graceful. For instance, the following examples 
use "!$acc end loop": 
http://devblogs.nvidia.com/parallelforall/openacc-example-part-2/ [If 
I remember correctly, pgf95 and Cray ftn silently accepts "end loop" 
while pathf95 accepts it with a warning.]


And looking at the spec of OpenACC 1.0 and 2.0a, the "end loop" seems 
to be invalid. How about following PathScale's ENZO and accepting "end 
loop" with a warning? Or at least error out with a good error message.


No, the spec doesn't specify !$acc end loop. However, compilers handle 
this construction differently:

PGI: silently accepts.
CAPS: Syntax error: expecting ('parallel' ('loop' or end)) or 
(('kernels' or 'dfkernels') ('loop' or end)) or 'data' or 'host_data'

!$acc  end loop
My implementation also errors out, but I agree, we should accept this 
with warning.





+  if (gfc_pure (NULL))
+{
+  gfc_error_now ("OpenACC directives at %C may not appear in PURE "
+ "or ELEMENTAL procedures");


Using gfc_pure() you do not check for ELEMENTAL: Since Fortran 2008, 
there are also IMPURE ELEMENTAL procedures. I don't know the spec, but 
I don't really see a reason why OpenACC shouldn't be permitted in 
IMPURE ELEMENTAL procedures. (BTW: "ELEMENTAL" implies PURE unless an 
explicit IMPURE is used.)


In any case, either drop "or ELEMENTAL" or also check for the 
elemental attribute.


I think I should drop "or ELEMENTAL" since OpenMP also accepts 
directives in IMPURE ELEMENTAL procecdures.



+  if (gfc_implicit_pure (NULL))
+gfc_current_ns->proc_name->attr.implicit_pure = 0;


I believe that will fail with BLOCK - cf. gfc_implicit_pure()

real function foo(n)
  integer, value :: n
  BLOCK
 integer i
 real sum
 !$acc loop reduce(+:sum)
 do i=1, n
sum += sin(real(i))
 end do
  END BLOCK
end


Fortunally, it doesn't.

--
Ilmir.


[S390] Fix scheduling performance regression from my shrink-wrap patches

2014-02-19 Thread Richard Sandiford
In the covering message for the shrink-wrap patch I said:

  Perhaps the only subtle thing is the handling of call-clobbered base
  registers.  The idea is to emit the initialising main_pool pattern in
  both early_mach -- at the very beginning of the function -- and in the
  prologue.  Then, if shrink-wrapping is used, the one added by early_mach
  will still be the first in the function.  If shrink-wrapping isn't used
  then the one added by the prologue will be the first in the function.
  s390_mainpool_start then deletes whichever isn't needed.

And as so often, the "subtle" bit wasn't really well thought out.
Having an extra unspec_volatile main_pool instruction until md_reorg
unnecessarily constrained the second scheduling pass.  This caused a
regression in some internal benchmarking.

When the base register is call-clobbered and can be set and used
anywhere in the function, there's no real need to emit it before
md_reorg.  The patch below therefore defers it until then.

Tested on s390x-linux-gnu.  OK to install?

Thanks,
Richard


gcc/
* config/s390/s390.c (s390_mainpool_start): Emit the main_pool
instruction at the start of the function if the base register is
call-clobbered.  Revert 2014-02-07 change.
(s390_early_mach): Don't initialize the base register here.
(s390_emit_prologue): Only initialize the base register if it
is call-saved.
(s300_extra_live_on_entry): New function.
(TARGET_EXTRA_LIVE_ON_ENTRY): Define.

Index: gcc/config/s390/s390.c
===
--- gcc/config/s390/s390.c  2014-02-07 14:56:19.205859847 +
+++ gcc/config/s390/s390.c  2014-02-13 12:49:55.756293247 +
@@ -6668,20 +6668,21 @@ s390_mainpool_start (void)
 
   for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
 {
+  /* If the base register is call-clobbered, output the initializing
+instruction at the start of the function.  */
+  if (!pool->pool_insn
+ && NONDEBUG_INSN_P (insn)
+ && cfun->machine->base_reg
+ && call_really_used_regs[REGNO (cfun->machine->base_reg)])
+   pool->pool_insn
+ = emit_insn_before (gen_main_pool (cfun->machine->base_reg), insn);
+
   if (NONJUMP_INSN_P (insn)
  && GET_CODE (PATTERN (insn)) == SET
  && GET_CODE (SET_SRC (PATTERN (insn))) == UNSPEC_VOLATILE
  && XINT (SET_SRC (PATTERN (insn)), 1) == UNSPECV_MAIN_POOL)
{
- /* There might be two main_pool instructions if base_reg
-is call-clobbered; one for shrink-wrapped code and one
-for the rest.  We want to keep the first.  */
- if (pool->pool_insn)
-   {
- insn = PREV_INSN (insn);
- delete_insn (NEXT_INSN (insn));
- continue;
-   }
+ gcc_assert (!pool->pool_insn);
  pool->pool_insn = insn;
}
 
@@ -8643,11 +8644,6 @@ s390_early_mach (void)
   /* Re-compute register info.  */
   s390_register_info ();
 
-  /* If we're using a base register, ensure that it is always valid for
- the first non-prologue instruction.  */
-  if (cfun->machine->base_reg)
-emit_insn_at_entry (gen_main_pool (cfun->machine->base_reg));
-
   /* Annotate all constant pool references to let the scheduler know
  they implicitly use the base register.  */
   for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
@@ -8728,7 +8724,8 @@ s390_emit_prologue (void)
 
   /* Dummy insn to mark literal pool slot.  */
 
-  if (cfun->machine->base_reg)
+  if (cfun->machine->base_reg
+  && !call_really_used_regs[REGNO (cfun->machine->base_reg)])
 emit_insn (gen_main_pool (cfun->machine->base_reg));
 
   offset = cfun_frame_layout.f0_offset;
@@ -9183,6 +9180,19 @@ s390_emit_epilogue (bool sibcall)
 }
 }
 
+/* Implement TARGET_EXTRA_LIVE_ON_ENTRY.  */
+
+static void
+s300_extra_live_on_entry (bitmap regs)
+{
+  /* If the base register is call-clobbered, the main_pool instruction
+ should go at the beginning of the function.  We only add it during
+ md_reorg.  */
+  if (cfun->machine->base_reg
+  && call_really_used_regs[REGNO (cfun->machine->base_reg)])
+bitmap_set_bit (regs, REGNO (cfun->machine->base_reg));
+}
+
 /* Implement TARGET_SET_UP_BY_PROLOGUE.  */
 
 static void
@@ -12230,6 +12240,9 @@ #define TARGET_ATTRIBUTE_TABLE s390_attr
 #undef TARGET_CAN_INLINE_P
 #define TARGET_CAN_INLINE_P s390_can_inline_p
 
+#undef TARGET_EXTRA_LIVE_ON_ENTRY
+#define TARGET_EXTRA_LIVE_ON_ENTRY s300_extra_live_on_entry
+
 #undef TARGET_SET_UP_BY_PROLOGUE
 #define TARGET_SET_UP_BY_PROLOGUE s300_set_up_by_prologue
 



[jit] Add some type-checking to parameters requiring pointers

2014-02-19 Thread David Malcolm
Committed to branch dmalcolm/jit:

gcc/jit/
* libgccjit.c (gcc_jit_context_new_rvalue_from_ptr): Verify that
pointer_type is indeed a pointer type.
(gcc_jit_context_null): Likewise.
(gcc_jit_context_new_array_access): Verify that ptr is indeed a
pointer.

* TODO.rst: Update
---
 gcc/jit/ChangeLog.jit | 10 ++
 gcc/jit/TODO.rst  |  9 +
 gcc/jit/libgccjit.c   | 13 +
 3 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 860bee6..0978a9c 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,13 @@
+2014-02-19  David Malcolm  
+
+   * libgccjit.c (gcc_jit_context_new_rvalue_from_ptr): Verify that
+   pointer_type is indeed a pointer type.
+   (gcc_jit_context_null): Likewise.
+   (gcc_jit_context_new_array_access): Verify that ptr is indeed a
+   pointer.
+
+   * TODO.rst: Update
+
 2014-02-18  David Malcolm  
 
* libgccjit.h (gcc_jit_struct): New.
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index 7288aef..51a3cc9 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -96,20 +96,15 @@ Initial Release
 
 * gcc_jit_context_one: must be a numeric type
 
-* gcc_jit_context_null: must be a pointer type
-
 * gcc_jit_context_new_rvalue_from_double: must be a numeric type
 
-* gcc_jit_context_new_rvalue_from_ptr: must be a pointer type
-
 * gcc_jit_context_new_unary_op: various checks needed
 
 * gcc_jit_context_new_binary_op: various checks needed
 
 * gcc_jit_context_new_comparison: must be numeric or pointer types
 
-* gcc_jit_context_new_array_lookup: "ptr" must be of pointer type;
-  "index" must be of numeric type.
+* gcc_jit_context_new_array_access: "index" must be of numeric type.
 
 * gcc_jit_lvalue_access_field: must be field of correct struct
 
@@ -119,8 +114,6 @@ Initial Release
 
 * gcc_jit_function_add_assignment_op: check the types
 
-* gcc_jit_function_add_conditional: boolval must be of numeric type
-
 * gcc_jit_loop_end: verify that loops are validly nested?
 
 Bugs
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index d089ad5..797785b 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -680,6 +680,10 @@ gcc_jit_context_new_rvalue_from_ptr (gcc_jit_context *ctxt,
 {
   RETURN_NULL_IF_FAIL (ctxt, NULL, "NULL context");
   RETURN_NULL_IF_FAIL (pointer_type, ctxt, "NULL type");
+  RETURN_NULL_IF_FAIL_PRINTF1 (
+pointer_type->dereference (), ctxt,
+"not a pointer type (type: %s)",
+pointer_type->get_debug_string ());
 
   return (gcc_jit_rvalue *)ctxt->new_rvalue_from_ptr (pointer_type, value);
 }
@@ -690,6 +694,10 @@ gcc_jit_context_null (gcc_jit_context *ctxt,
 {
   RETURN_NULL_IF_FAIL (ctxt, NULL, "NULL context");
   RETURN_NULL_IF_FAIL (pointer_type, ctxt, "NULL type");
+  RETURN_NULL_IF_FAIL_PRINTF1 (
+pointer_type->dereference (), ctxt,
+"not a pointer type (type: %s)",
+pointer_type->get_debug_string ());
 
   return gcc_jit_context_new_rvalue_from_ptr (ctxt, pointer_type, NULL);
 }
@@ -823,6 +831,11 @@ gcc_jit_context_new_array_access (gcc_jit_context *ctxt,
   RETURN_NULL_IF_FAIL (ctxt, NULL, "NULL context");
   RETURN_NULL_IF_FAIL (ptr, ctxt, "NULL ptr");
   RETURN_NULL_IF_FAIL (index, ctxt, "NULL index");
+  RETURN_NULL_IF_FAIL_PRINTF2 (
+ptr->get_type ()->dereference (), ctxt,
+"%s (type: %s) is not a pointer",
+ptr->get_debug_string (),
+ptr->get_type ()->get_debug_string ());
 
   return (gcc_jit_lvalue *)ctxt->new_array_access (loc, ptr, index);
 }
-- 
1.7.11.7



Re: [patch c++]: Fix pr/58835 [4.7/4.8/4.9 Regression] ICE with __PRETTY_FUNCTION__ in broken function

2014-02-19 Thread Kai Tietz
Ping?

2014-02-11 15:11 GMT+01:00 Kai Tietz :
> Hi,
>
> the following patch adds missing handling of error_mark_node result of
> fname_decl within finish_fname.
>
> ChangeLog
>
> 2014-02-11  Kai Tietz  
>
> PR c++/58835
> * semantics.c (finish_fname): Handle error_mark_node.
>
> Regression tested for x86_64-unknown-linux-gnu, i686-w64-mingw32.  Ok for 
> apply?
>
> Regards,
> Kai
>
> Index: semantics.c
> ===
> --- semantics.c (Revision 207686)
> +++ semantics.c (Arbeitskopie)
> @@ -2630,7 +2630,8 @@ finish_fname (tree id)
>tree decl;
>
>decl = fname_decl (input_location, C_RID_CODE (id), id);
> -  if (processing_template_decl && current_function_decl)
> +  if (processing_template_decl && current_function_decl
> +  && decl != error_mark_node)
>  decl = DECL_NAME (decl);
>return decl;
>  }


Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

2014-02-19 Thread Janus Weil
The patch was not applying cleanly any more, so here is a re-diffed
version for current trunk. It works nicely on the included test case
as well as the one provided by Walter Spector in comment 12 of the PR.

Since, also in the current state, "character(:)" works only in a
subset of all cases, I think it cannot hurt to add more cases that
work for 4.9 (even if still not all possible cases work).

Please let me know what you think ...

Cheers,
Janus




2014-02-19 16:16 GMT+01:00 Janus Weil :
> Hi all,
>
> the patch below has been posted a long time ago, but was never
> actually committed (although it seems close to being finished).
>
> Could it still be considered for trunk? I think it is a rather popular
> feature, which would be helpful for many users ...
>
> Cheers,
> Janus
>
>
>
> 2013-03-19 22:17 GMT+01:00 Tobias Burnus :
>> Dear Paul, dear all,
>>
>>
>> On February 24, 2013 Paul Richard Thomas wrote:
>>>
>>> The attached patch represents progress to date.  It fixes the original
>>> problem in this PR and allows John Reid's version of
>>> iso_varying_string/vocabulary_word_count.f90 to compile and run
>>> correctly.  It even bootstraps and regtests!
>>
>>
>> Attached is a re-diffed patch; I have additionally fixed some indenting
>> issues.
>>
>> Additionally, I have tested the patch - and it fails with deferred-length
>> *array* character components. See attached test case. Also, the following
>> line of the included test case leaks memory:
>> allocate (array(2), source = [t("abcedefg","hi"), t("jkl","mnop")])
>>
>> I think at least the array bug should be fixed prior committal. (Fixing the
>> memory leak and some of the below-mentioned issues would be nice, too.)
>> Otherwise, I think the patch looks fine. For completeness, I have some
>> naming remarks, which I would also like to considered:
>> http://thread.gmane.org/gmane.comp.gcc.fortran/40393/focus=281580
>>
>> Tobias
>>
>>
>>> However, it doe not fix:
>>> PR51976 comment #6 and PR51550 - allocate with typespec ICEs
>>> PR51976 comment #6 FORALL assignment is messed up and ICEs..
>>> PR47545 the compiler complains about the lack of an initializer for
>>> the hidden character length field.
>>> PR45170 will need going through from one end to the other - there is a
>>> lot of "stuff" here!
>>>
>>> Of these, I consider the fix of the PR47545 problem to be a must and
>>> the allocate with typespec desirable.
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h  (revision 207896)
+++ gcc/fortran/gfortran.h  (working copy)
@@ -811,6 +811,9 @@ typedef struct
   /* Attributes set by compiler extensions (!GCC$ ATTRIBUTES).  */
   unsigned ext_attr:EXT_ATTR_NUM;
 
+  /* Is a parameter associated with a deferred type component.  */
+  unsigned deferred_parameter:1;
+
   /* The namespace where the attribute has been set.  */
   struct gfc_namespace *volatile_ns, *asynchronous_ns;
 }
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 207896)
+++ gcc/fortran/primary.c   (working copy)
@@ -2355,7 +2355,7 @@ build_actual_constructor (gfc_structure_ctor_compo
}
 
   /* If it was not found, try the default initializer if there's any;
-otherwise, it's an error.  */
+otherwise, it's an error unless this is a deferred parameter.  */
   if (!comp_iter)
{
  if (comp->initializer)
@@ -2365,7 +2365,7 @@ build_actual_constructor (gfc_structure_ctor_compo
return false;
  value = gfc_copy_expr (comp->initializer);
}
- else
+ else if (!comp->attr.deferred_parameter)
{
  gfc_error ("No initializer for component '%s' given in the"
 " structure constructor at %C!", comp->name);
@@ -2447,7 +2447,7 @@ gfc_convert_to_structure_constructor (gfc_expr *e,
{
  /* Components without name are not allowed after the first named
 component initializer!  */
- if (!comp)
+ if (!comp || comp->attr.deferred_parameter)
{
  if (last_name)
gfc_error ("Component initializer without name after component"
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 207896)
+++ gcc/fortran/resolve.c   (working copy)
@@ -12105,14 +12105,6 @@ resolve_fl_derived0 (gfc_symbol *sym)
   if (c->attr.artificial)
continue;
 
-  /* See PRs 51550, 47545, 48654, 49050, 51075 - and 45170.  */
-  if (c->ts.type == BT_CHARACTER && c->ts.deferred && !c->attr.function)
-   {
- gfc_error ("Deferred-length character component '%s' at %L is not "
-"yet supported", c->name, &c->loc);
- return false;
-   }
-
   /* F2008, C442.  */
   if ((!sym->attr.is_class || c != 

[gomp4] libgomp: plugin for non-shared memory host execution (was: libgomp.c/target-1.c failing in fn2's GOMP_target_update)

2014-02-19 Thread Thomas Schwinge
Hi!

On Thu, 12 Dec 2013 12:31:40 +0100, I wrote:
> On Fri, 8 Nov 2013 16:40:00 +0100, Jakub Jelinek  wrote:
> > [...], device 257 is just a temporary testing hack, [...]
> 
> > [...], once we have at least one supported offloading target,
> > hopefully we'll nuke device 257.
> 
> Hmm, in contrast, I'd advocate to preserve that device, under a proper
> ID, for two (similar) reasons: even if it's the same architecture, we'll
> still want a generic non-shared-memory "offloading target" for GCC
> testsuite usage.  We can't assume that any of the "real hardware"
> acceleration devices to be available, but will still want to test the
> non-shared-memory stuff.  And likewise, GCC users can use this for
> testing their code for shared-memory host (fallback) execution vs.
> non-shared-memory execution.  So basically, just like a user can decide
> to use OpenMP/libgomp, but tie the runtime down to just one thread; but
> that's still different from host fallback execution.  Makes sense?

Here is such a libgomp plugin plus the infrastructure for initial support
of non-shared memory host execution.  Any comments?

I have not yet integrated the plugin into the libgomp build system; use
something like:

$ gcc -m64 -Wall -Wextra -shared -o libgomp-plugin-host.so.1 
[...]/libgomp/plugin-host.c -fPIC -O -DDEBUG

..., and then set LIBGOMP_PLUGIN_PATH=$PWD in the environment.  (Plus
OMP_DEFAULT_DEVICE=0, but that's the default.)

commit 8495aab54fb244ef2643e43eb3e91a092ff0b14e
Author: Thomas Schwinge , James Norris 

Date:   Wed Feb 19 16:53:14 2014 +0100

libgomp: plugin for non-shared memory host execution.

libgomp/
* plugin-host.c: New file.
* target.c (struct gomp_device_descr): Add device_alloc_func,
device_free_func, device_dev2host_func, device_host2dev_func
members.
(gomp_load_plugin_for_device): Load these.
(gomp_map_vars, gomp_unmap_tgt, gomp_unmap_vars, gomp_update): Use
these.
(resolve_device, gomp_find_available_plugins): Remove ID 257 hack.

diff --git libgomp/plugin-host.c libgomp/plugin-host.c
new file mode 100644
index 000..5354ebe
--- /dev/null
+++ libgomp/plugin-host.c
@@ -0,0 +1,84 @@
+/* Plugin for non-shared memory host execution.
+
+   Copyright (C) 2014 Free Software Foundation, Inc.
+
+   Contributed by Thomas Schwinge .
+
+   This file is part of the GNU OpenMP Library (libgomp).
+
+   Libgomp is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   Libgomp is distributed in the hope that it will be useful, but WITHOUT ANY
+   WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+   FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+   more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+/* Simple implementation of a libgomp plugin for non-shared memory host
+   execution.  */
+
+#include 
+#include 
+#include 
+#include 
+
+bool
+device_available (void)
+{
+#ifdef DEBUG
+  printf ("libgomp plugin: %s:%s\n", __FILE__, __FUNCTION__);
+#endif
+
+  return true;
+}
+
+void *
+device_alloc (size_t size)
+{
+  void *ptr = malloc (size);
+
+#ifdef DEBUG
+  printf ("libgomp plugin: %s:%s (%zd): %p\n", __FILE__, __FUNCTION__, size, 
ptr);
+#endif
+
+  return ptr;
+}
+
+void
+device_free (void *ptr)
+{
+#ifdef DEBUG
+  printf ("libgomp plugin: %s:%s (%p)\n", __FILE__, __FUNCTION__, ptr);
+#endif
+
+  free (ptr);
+}
+
+void *device_dev2host (void *dest, const void *src, size_t n)
+{
+#ifdef DEBUG
+  printf ("libgomp plugin: %s:%s (%p, %p, %zd)\n", __FILE__, __FUNCTION__, 
dest, src, n);
+#endif
+
+  return memcpy (dest, src, n);
+}
+
+void *device_host2dev (void *dest, const void *src, size_t n)
+{
+#ifdef DEBUG
+  printf ("libgomp plugin: %s:%s (%p, %p, %zd)\n", __FILE__, __FUNCTION__, 
dest, src, n);
+#endif
+
+  return memcpy (dest, src, n);
+}
diff --git libgomp/target.c libgomp/target.c
index 55d3891..48f35c4 100644
--- libgomp/target.c
+++ libgomp/target.c
@@ -122,6 +122,10 @@ struct gomp_device_descr
 
   /* Function handlers.  */
   bool (*device_available_func) (void);
+  void *(*device_alloc_func) (size_t);
+  void (*device_free_func) (void *);
+  void *(*device_dev2host_func)(void *, const void *, size_t);
+  void *(*device_host2dev_func)(void *, const void *, size_t);
 
   /* Splay tree containing information about mapped memory regions.  */
   struct splay_tree_s dev_splay_tree;
@@ -146,14 +

Re: c-parser.c replace error() by error_at()

2014-02-19 Thread Marek Polacek
On Wed, Feb 19, 2014 at 08:45:04PM +0530, Prathamesh Kulkarni wrote:
> Index: gcc/c/c-parser.c
> ===
> --- gcc/c/c-parser.c (revision 207700)
> +++ gcc/c/c-parser.c (working copy)
> @@ -2223,7 +2223,7 @@ c_parser_declspecs (c_parser *parser, st
>attrs_ok = true;
>if (kind == C_ID_ID)
>  {
> -  error ("unknown type name %qE", value);
> +  error_at (loc, "unknown type name %qE", value);
>t.kind = ctsk_typedef;
>t.spec = error_mark_node;
>  }
> @@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
>c_parser_set_source_position_from_token (token);
>if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
>   {
> -  error ("unknown type name %qE", token->value);
> +  error_at (token->location, "unknown type name %qE", token->value);
>parser->error = true;
>   }
>/* ??? In some Objective-C cases '...' isn't applicable so there

BTW, your MUA eats tabs, so the patch can't be applied (common gmail
problem).

> Index: gcc/testsuite/gcc.dg/decl-10.c
> ===
> --- gcc/testsuite/gcc.dg/decl-10.c (revision 0)
> +++ gcc/testsuite/gcc.dg/decl-10.c (working copy)
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +
> +void
> +f4(const foo x) /* { dg-error "unknown type name" } */
> +{}
> +
> +void
> +f5(foo x, int i) /* { dg-error "unknown type name" } */
> +{}
> +
> +void
> +f6(char c, foo x, ...) /* { dg-error "unknown type name" } */
> +{}

Since we're testing the column numbers here, those dg-errors should
test that.  So please adjust them:
/* { dg-error "10:unknown type name" } */
/* { dg-error "4:unknown type name" } */
/* { dg-error "12:unknown type name" } */

Thanks.

Marek


Re: [PATCH] Fix up preprocessing of #pragma GCC ivdep (PR c++/60267)

2014-02-19 Thread Jeff Law

On 02/19/14 07:52, Jakub Jelinek wrote:

Hi!

In #pragma GCC ivdep there is nothing the preprocessor should care about,
thus there is no reason to register it when doing just -E (and, otherwise
we'd have to handle PRAGMA_IVDEP in pragma lookups).

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2014-02-19  Jakub Jelinek  

PR c++/60267
* c-pragma.c (init_pragma): Don't call cpp_register_deferred_pragma
for PRAGMA_IVDEP if flag_preprocess_only.

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

OK.
jeff



Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs

2014-02-19 Thread Sandra Loosemore

On 02/19/2014 02:43 AM, Andrew Haley wrote:

On 02/19/2014 09:34 AM, Richard Biener wrote:

Sandras patch was supposed to introduce support
for --enable-version-specific-runtime-libs in libgcj (but obviously
it failed, given the result above).


Sandra?  You're very quiet.  What say you?

I don't want this ping-ponging.


This was actually not even my patch -- it was Mark Mitchell's patch, 
which I re-pinged and committed on his behalf.


http://gcc.gnu.org/ml/java-patches/2009-q1/msg00025.html

I am OK with Richard's fix.

-Sandra




Re: c-parser.c replace error() by error_at()

2014-02-19 Thread Prathamesh Kulkarni
On Wed, Feb 19, 2014 at 9:41 PM, Marek Polacek  wrote:
> On Wed, Feb 19, 2014 at 08:45:04PM +0530, Prathamesh Kulkarni wrote:
>> Index: gcc/c/c-parser.c
>> ===
>> --- gcc/c/c-parser.c (revision 207700)
>> +++ gcc/c/c-parser.c (working copy)
>> @@ -2223,7 +2223,7 @@ c_parser_declspecs (c_parser *parser, st
>>attrs_ok = true;
>>if (kind == C_ID_ID)
>>  {
>> -  error ("unknown type name %qE", value);
>> +  error_at (loc, "unknown type name %qE", value);
>>t.kind = ctsk_typedef;
>>t.spec = error_mark_node;
>>  }
>> @@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
>>c_parser_set_source_position_from_token (token);
>>if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
>>   {
>> -  error ("unknown type name %qE", token->value);
>> +  error_at (token->location, "unknown type name %qE", token->value);
>>parser->error = true;
>>   }
>>/* ??? In some Objective-C cases '...' isn't applicable so there
>
> BTW, your MUA eats tabs, so the patch can't be applied (common gmail
> problem).
I have sent it attached this time.
>
>> Index: gcc/testsuite/gcc.dg/decl-10.c
>> ===
>> --- gcc/testsuite/gcc.dg/decl-10.c (revision 0)
>> +++ gcc/testsuite/gcc.dg/decl-10.c (working copy)
>> @@ -0,0 +1,13 @@
>> +/* { dg-do compile } */
>> +
>> +void
>> +f4(const foo x) /* { dg-error "unknown type name" } */
>> +{}
>> +
>> +void
>> +f5(foo x, int i) /* { dg-error "unknown type name" } */
>> +{}
>> +
>> +void
>> +f6(char c, foo x, ...) /* { dg-error "unknown type name" } */
>> +{}
>
> Since we're testing the column numbers here, those dg-errors should
> test that.  So please adjust them:
> /* { dg-error "10:unknown type name" } */
> /* { dg-error "4:unknown type name" } */
> /* { dg-error "12:unknown type name" } */
Added.
>
> Thanks.
>
[gcc/c]
* c-parser.c (c_parser_declspecs): Replace call to error by error_at.
* c-parser.c (c_parser_parameter_declaration): Likewise.

[gcc/testsuite]
* gcc.dg/decl-10.c: New test case.

> Marek
Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c	(revision 207700)
+++ gcc/c/c-parser.c	(working copy)
@@ -2223,7 +2223,7 @@ c_parser_declspecs (c_parser *parser, st
 	  attrs_ok = true;
 	  if (kind == C_ID_ID)
 	{
-	  error ("unknown type name %qE", value);
+	  error_at (loc, "unknown type name %qE", value);
 	  t.kind = ctsk_typedef;
 	  t.spec = error_mark_node;
 	}
@@ -3608,7 +3608,7 @@ c_parser_parameter_declaration (c_parser
   c_parser_set_source_position_from_token (token);
   if (c_parser_next_tokens_start_typename (parser, cla_prefer_type))
 	{
-	  error ("unknown type name %qE", token->value);
+	  error_at (token->location, "unknown type name %qE", token->value);
 	  parser->error = true;
 	}
   /* ??? In some Objective-C cases '...' isn't applicable so there
Index: gcc/testsuite/gcc.dg/decl-10.c
===
--- gcc/testsuite/gcc.dg/decl-10.c	(revision 0)
+++ gcc/testsuite/gcc.dg/decl-10.c	(working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+void
+f4(const foo x) /* { dg-error "10:unknown type name" } */
+{}
+
+void
+f5(foo x, int i) /* { dg-error "4:unknown type name" } */
+{}
+
+void
+f6(char c, foo x, ...) /* { dg-error "12:unknown type name" } */
+{}


Re: [PATCH 2/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

2014-02-19 Thread Ilmir Usmanov

Hi Tobias!

On 10.02.2014 03:10, Tobias Burnus wrote:
Shouldn't you also reject polymorphic types ("BT_CLASS" and 
"BT_ASSUMED")? [BT_CLASS = "class(derived_type_name)" or "class(*)"; 
BT_ASSUMED = "type(*)"]



+  if (n->sym->attr.pointer)
+gfc_error ("POINTER object '%s' in %s clause at %L",
+   n->sym->name, name, &code->loc);


Actually, here and probably elsewhere: Do you need to take care of 
derived-type components? I mean something like

   clause(derived_type%comp)

Do you also need to reject AS_ASSUMED_RANK (new since Fortran 
Technical Specification ISO/IEC TS 29113:2012)? I mean code like:


   subroutine foo(x)
 integer, DIMENSION(..) :: x
 ... openacc_clause(x)

Side note: One should also check how OpenMP handles those.

I think we should reject assumed size, assumed shape and assumed rank 
variables, as OpenMP does.



+  case OMP_LIST_DEVICEPTR:
+if (n->sym->attr.pointer)
+  gfc_error ("POINTER object '%s' in %s clause at %L",
+ n->sym->name, name, &code->loc);


Talking about pointers, you probably also want to reject Cray pointers 
(attr.cray_pointee - and cray_pointee). [One should also check what 
OpenMP does; I think it does handle it correctly.]


I agree, currently my implementation does not handle Cray pointers 
correctly, will fix.


And another point: I think you have to check whether the argument is a 
named constant (PARAMETER, attr.flavor == FL_PARAMETER), I think those 
you cannot put them there either.


What happens if you try to use a literal such as "deviceptr(5)"?


Both parameter and literal are rejected.
By the way, PGI compiler accepts parameters with warning, CAPS silently 
accepts. I think, we also should support parameters with warning.





+  resolve_oacc_positive_int_expr (el->expr, "TILE");
+  if (el->expr->expr_type != EXPR_CONSTANT)
+gfc_error ("TILE requires constant expression at %L", 
&code->loc);


Is the following permitted: "tile(4+5)"? If so, do you need to call 
gfc_simplify_expr() as some point? (Or is this already done at some 
point?)



Yes, the syntax is allowed, but ...
CAPSCompilers-3.4.1/bin/hmpp: [Error HP0112] tile.f95:30: Syntax error: 
expecting ')'

!$acc  parallel loop collapse(1+ 1)

CAPS compiler doesn't support this. But PGI does.

There is no need to simplify expression since it is constant anyway. The 
simplification is done during match stage (gfc_match_expr calls gfc_add).


--
Ilmir.


Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs

2014-02-19 Thread Andrew Haley
On 02/19/2014 04:38 PM, Sandra Loosemore wrote:
> I am OK with Richard's fix.

Fine by me then,

Andrew.



Re: [gomp4] libgomp: Don't update copy_from for the existing mappings.

2014-02-19 Thread Thomas Schwinge
Hi Ilya!

On Tue, 18 Feb 2014 20:49:39 +0400, Ilya Verbin  wrote:
> 2014-02-18 20:25 GMT+04:00 Thomas Schwinge :
> > Sure; this was the consensus, as I understand it.  Though, wouldn't it
> > make sense to also add a test case to a) test for this behavior, and also
> > b) to document the "GCC interpretation of the OpenMP standard" in this
> > case (including a link to the OpenMP issue tracker, or Jakub's email on
> > this topic)?
> 
> This issue is not reproducible on the shared memory.  So, currently
> (while we perform host fallback), it's impossible to create a
> test-case.  But we're going to create a libgomp plugin, that will
> emulate a target device with a private memory.  It will allow to run
> tests for offloading without having accelerator device.

Right, that's what we also had suggested, prepared, and now posted in
.


Using this, and extending your test case as follows:

@@ -6,10 +6,13 @@
 int main ()
 {
   int *a = malloc (N * sizeof (int));
+  int *b = a;
   printf ("1: %p\n", a);
 #pragma omp target data map(tofrom: a[0:N])
   {
 printf ("2: %p\n", a);
+if (a != b)
+  abort ();
 #pragma omp target
 {
   int i;
@@ -17,8 +20,12 @@
a[i] = i;
 }
 printf ("3: %p\n", a);
+if (a != b)
+  abort ();
   }
   printf ("4: %p\n", a);
+  if (a != b)
+abort ();
   free (a);
   return 0;
 }

..., I then see the following with the current code:

$ LIBGOMP_PLUGIN_PATH=$PWD ./a.out 
1: 0x1737030
libgomp plugin: ../source/libgomp/plugin-host.c:device_alloc (4015): 
0x1738040
libgomp plugin: ../source/libgomp/plugin-host.c:device_host2dev (0x1738040, 
0x1737030, 4000)
libgomp plugin: ../source/libgomp/plugin-host.c:device_host2dev (0x1738fe0, 
0x7fff808f2cb8, 8)
2: 0x1737030
libgomp plugin: ../source/libgomp/plugin-host.c:device_alloc (39): 0x17391a0
libgomp plugin: ../source/libgomp/plugin-host.c:device_host2dev (0x17391a0, 
0x7fff808f2c38, 8)
libgomp plugin: ../source/libgomp/plugin-host.c:device_free (0x17391a0)
3: 0x1737030
libgomp plugin: ../source/libgomp/plugin-host.c:device_dev2host (0x1737030, 
0x1738040, 4000)
libgomp plugin: ../source/libgomp/plugin-host.c:device_dev2host 
(0x7fff808f2d48, 0x1738fe0, 8)
libgomp plugin: ../source/libgomp/plugin-host.c:device_free (0x1738040)
4: 0x1738040
Aborted (core dumped)

..., and with your libgomp patch applied:

$ LIBGOMP_PLUGIN_PATH=$PWD ./a.out
1: 0x74c030
libgomp plugin: ../source/libgomp/plugin-host.c:device_alloc (4015): 
0x74d040
libgomp plugin: ../source/libgomp/plugin-host.c:device_host2dev (0x74d040, 
0x74c030, 4000)
libgomp plugin: ../source/libgomp/plugin-host.c:device_host2dev (0x74dfe0, 
0x7fffef55f0f8, 8)
2: 0x74c030
libgomp plugin: ../source/libgomp/plugin-host.c:device_alloc (39): 0x74e1a0
libgomp plugin: ../source/libgomp/plugin-host.c:device_host2dev (0x74e1a0, 
0x7fffef55f078, 8)
libgomp plugin: ../source/libgomp/plugin-host.c:device_free (0x74e1a0)
3: 0x74c030
libgomp plugin: ../source/libgomp/plugin-host.c:device_dev2host (0x74c030, 
0x74d040, 4000)
libgomp plugin: ../source/libgomp/plugin-host.c:device_free (0x74d040)
4: 0x74c030


Grüße,
 Thomas


pgpdQGEfbKbKo.pgp
Description: PGP signature


Re: [gomp4] libgomp: plugin for non-shared memory host execution (was: libgomp.c/target-1.c failing in fn2's GOMP_target_update)

2014-02-19 Thread Ilya Verbin
2014-02-19 20:10 GMT+04:00 Thomas Schwinge :
> Here is such a libgomp plugin plus the infrastructure for initial support
> of non-shared memory host execution.  Any comments?
>
> Grüße,
>  Thomas

This plugin looks good.

I think the function call in GOMP_target also should be replaced with
a call to plugin:
- fn ((void *) tgt->tgt_start);
+ devicep->device_run_func (fn, (void *) tgt->tgt_start);

Also I have a question (not related with this plugin): How will
libgomp work with multiple devices of the same type?  Probably it
should load the plugin once, query it for the number of available
devices, add received number of descriptors to the devices[] array, an
then pass devicep->id as an argument to all plugin's interfaces.

  -- Ilya


Re: [patch c++]: Fix pr/58835 [4.7/4.8/4.9 Regression] ICE with __PRETTY_FUNCTION__ in broken function

2014-02-19 Thread Jason Merrill

OK.

Jason


Re: [C++ PATCH] Fix up DW_AT_explicit handling (PR debug/56563)

2014-02-19 Thread Jason Merrill

OK.

Jason


Re: [C++ PATCH] Handle #pragma GCC ivdep during tsubst (PR c++/60267)

2014-02-19 Thread Jason Merrill

OK.

Jason


Re: c-parser.c replace error() by error_at()

2014-02-19 Thread Joseph S. Myers
On Wed, 19 Feb 2014, Prathamesh Kulkarni wrote:

> I have sent it attached this time.

Thanks, this version is OK.  Please start the copyright assignment 
paperwork process if you haven't already done so, if you may be 
contributing more changes in future.

http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future

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


Re: [gomp4] libgomp: plugin for non-shared memory host execution (was: libgomp.c/target-1.c failing in fn2's GOMP_target_update)

2014-02-19 Thread Jakub Jelinek
On Wed, Feb 19, 2014 at 09:49:20PM +0400, Ilya Verbin wrote:
> 2014-02-19 20:10 GMT+04:00 Thomas Schwinge :
> > Here is such a libgomp plugin plus the infrastructure for initial support
> > of non-shared memory host execution.  Any comments?
> >
> > Grüße,
> >  Thomas
> 
> This plugin looks good.
> 
> I think the function call in GOMP_target also should be replaced with
> a call to plugin:
> - fn ((void *) tgt->tgt_start);
> + devicep->device_run_func (fn, (void *) tgt->tgt_start);
> 
> Also I have a question (not related with this plugin): How will
> libgomp work with multiple devices of the same type?  Probably it
> should load the plugin once, query it for the number of available
> devices, add received number of descriptors to the devices[] array, an
> then pass devicep->id as an argument to all plugin's interfaces.

Or the devicep pointer.

Jakub


Re: c-parser.c replace error() by error_at()

2014-02-19 Thread Marek Polacek
On Wed, Feb 19, 2014 at 06:02:23PM +, Joseph S. Myers wrote:
> On Wed, 19 Feb 2014, Prathamesh Kulkarni wrote:
> 
> > I have sent it attached this time.
> 
> Thanks, this version is OK.  Please start the copyright assignment 
> paperwork process if you haven't already done so, if you may be 
> contributing more changes in future.
> 
> http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future

I'll commit the latest version shortly.

Marek


PATCH: PR target/60207: Wrong TFmode check in construct_container

2014-02-19 Thread H.J. Lu
Hi,

There is no need to check TFmode for X86_64_INTEGER_CLASS since TFmode
is passed in vector register.  This patch has been pre-approved for
mainline and release branches.  I checked it into mainline and will
backport it to 4.7/4.8 branch.

H.J.
---
Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 207912)
+++ gcc/ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2014-02-19  H.J. Lu  
+
+   PR target/60207
+   * config/i386/i386.c (construct_container): Remove TFmode check
+   for X86_64_INTEGER_CLASS.
+
 2014-02-19  Uros Bizjak  
 
PR target/59794
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 207912)
+++ gcc/config/i386/i386.c  (working copy)
@@ -6966,7 +6966,7 @@ construct_container (enum machine_mode m
   if (n == 2
   && regclass[0] == X86_64_INTEGER_CLASS
   && regclass[1] == X86_64_INTEGER_CLASS
-  && (mode == CDImode || mode == TImode || mode == TFmode)
+  && (mode == CDImode || mode == TImode)
   && intreg[0] + 1 == intreg[1])
 return gen_rtx_REG (mode, intreg[0]);
 


C++ PATCH for c++/60046 (ICE with noexcept)

2014-02-19 Thread Jason Merrill
In this testcase, when we see a non-dependent use of a function template 
instance we mark it as used, but we don't want to instantiate the 
noexcept-specification at that point because we aren't doing full 
expression evaluation yet.


Tested x86_64-pc-linux-gnu, applying to trunk, 4.8, 4.7.
commit 783a814e999b5c1de5f8cd1e4df13eee78cff244
Author: Jason Merrill 
Date:   Wed Feb 19 12:59:50 2014 -0500

	PR c++/60046
	* pt.c (maybe_instantiate_noexcept): Don't instantiate exception
	spec from template context.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 7967db8..0b4a889 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19280,6 +19280,10 @@ maybe_instantiate_noexcept (tree fn)
 {
   tree fntype, spec, noex, clone;
 
+  /* Don't instantiate a noexcept-specification from template context.  */
+  if (processing_template_decl)
+return;
+
   if (DECL_CLONED_FUNCTION_P (fn))
 fn = DECL_CLONED_FUNCTION (fn);
   fntype = TREE_TYPE (fn);
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept22.C b/gcc/testsuite/g++.dg/cpp0x/noexcept22.C
new file mode 100644
index 000..7aab0f4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept22.C
@@ -0,0 +1,21 @@
+// PR c++/60046
+// { dg-require-effective-target c++11 }
+
+constexpr bool foo () { return noexcept (true); }
+template 
+struct V
+{
+  void bar (V &) noexcept (foo ()) {}
+};
+template 
+struct W : public V 
+{
+  void bar (W &x) { V ::bar (x); }
+};
+
+int
+main ()
+{
+  W  a, b;
+  a.bar (b);
+}


[PATCH, rs6000, committed] Most significant bit of zero is not one.

2014-02-19 Thread Bill Schmidt
Hi,

I ran across this obvious error when developing a test case for another
patch.  The value assigned for the most significant bit of a value is
obviously wrong for zero here.  I haven't added a test case because this
will be covered by the test case added for the other patch.

Bootstrapped and tested for powerpc64le-unknown-linux-gnu with no
regressions.  Committed as obvious.

Thanks,
Bill


2014-02-19  Bill Schmidt  

* config/rs6000/rs6000.c (vspltis_constant): Fix most significant
bit of zero.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 207910)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5020,7 +5020,7 @@ vspltis_constant (rtx op, unsigned step, unsigned
 
   val = const_vector_elt_as_int (op, BYTES_BIG_ENDIAN ? nunits - 1 : 0);
   splat_val = val;
-  msb_val = val > 0 ? 0 : -1;
+  msb_val = val >= 0 ? 0 : -1;
 
   /* Construct the value to be splatted, if possible.  If not, return 0.  */
   for (i = 2; i <= copies; i *= 2)




[PATCH] Use __UINT{16,32,64}_TYPE__ for builtins when available (PR c/37743)

2014-02-19 Thread Jakub Jelinek
Hi!

This patch changes the return type of the __builtin_bswap{16,32,64} builtins
to the __UINT{16,32,64}_TYPE__ types if the target defines them, instead
of a nonstandard integer type, which is a problem for -Wformat warnings
or for C++ overload resolution.

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

2014-02-19  Jakub Jelinek  

PR c/37743
* c-common.c (c_common_nodes_and_builtins): When initializing
c_uint{16,32,64}_type_node, also set corresponding
uint{16,32,64}_type_node to the same value.

* g++.dg/ext/builtin-bswap1.C: New test.
* c-c++-common/pr37743.c: New test.

--- gcc/c-family/c-common.c.jj  2014-02-19 17:42:46.0 +0100
+++ gcc/c-family/c-common.c 2014-02-19 19:00:43.038726087 +0100
@@ -5610,13 +5610,13 @@ c_common_nodes_and_builtins (void)
 uint8_type_node =
   TREE_TYPE (identifier_global_value (c_get_ident (UINT8_TYPE)));
   if (UINT16_TYPE)
-c_uint16_type_node =
+c_uint16_type_node = uint16_type_node =
   TREE_TYPE (identifier_global_value (c_get_ident (UINT16_TYPE)));
   if (UINT32_TYPE)
-c_uint32_type_node =
+c_uint32_type_node = uint32_type_node =
   TREE_TYPE (identifier_global_value (c_get_ident (UINT32_TYPE)));
   if (UINT64_TYPE)
-c_uint64_type_node =
+c_uint64_type_node = uint64_type_node =
   TREE_TYPE (identifier_global_value (c_get_ident (UINT64_TYPE)));
   if (INT_LEAST8_TYPE)
 int_least8_type_node =
--- gcc/testsuite/g++.dg/ext/builtin-bswap1.C.jj2014-02-19 
18:51:07.012975025 +0100
+++ gcc/testsuite/g++.dg/ext/builtin-bswap1.C   2014-02-19 18:53:54.160029098 
+0100
@@ -0,0 +1,22 @@
+// PR c/37743
+// { dg-do compile }
+
+#if defined(__UINT32_TYPE__) && defined(__INT32_TYPE__)
+
+void foo (__UINT32_TYPE__);
+void foo (__INT32_TYPE__);
+
+void
+bar (__UINT32_TYPE__ x)
+{
+  foo (__builtin_bswap32 (x));
+}
+
+#else
+
+void
+bar ()
+{
+}
+
+#endif
--- gcc/testsuite/c-c++-common/pr37743.c.jj 2014-02-19 18:55:09.947603407 
+0100
+++ gcc/testsuite/c-c++-common/pr37743.c2014-02-19 18:58:23.153511710 
+0100
@@ -0,0 +1,13 @@
+/* PR c/37743 */
+/* This needs to be run only on targets where __UINT32_TYPE__ is defined
+   to unsigned int.  */
+/* { dg-do compile { target *-*-linux-gnu* } } */
+/* { dg-options "-Wformat" } */
+
+int foo (const char *, ...) __attribute__ ((format (printf, 1, 2)));
+
+void
+bar (unsigned int x)
+{
+  foo ("%x", __builtin_bswap32 (x));
+}

Jakub


Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

2014-02-19 Thread Paul Richard Thomas
Dear Janus,

I had completely forgotten about this patch... I even thought that it
had been applied :-)

I'll have time, either tomorrow evening or Saturday to take a look.
After nearly 11 months, a couple more days will not hurt!

Thanks for bringing it to my attention.

Paul

On 19 February 2014 16:51, Janus Weil  wrote:
> The patch was not applying cleanly any more, so here is a re-diffed
> version for current trunk. It works nicely on the included test case
> as well as the one provided by Walter Spector in comment 12 of the PR.
>
> Since, also in the current state, "character(:)" works only in a
> subset of all cases, I think it cannot hurt to add more cases that
> work for 4.9 (even if still not all possible cases work).
>
> Please let me know what you think ...
>
> Cheers,
> Janus
>
>
>
>
> 2014-02-19 16:16 GMT+01:00 Janus Weil :
>> Hi all,
>>
>> the patch below has been posted a long time ago, but was never
>> actually committed (although it seems close to being finished).
>>
>> Could it still be considered for trunk? I think it is a rather popular
>> feature, which would be helpful for many users ...
>>
>> Cheers,
>> Janus
>>
>>
>>
>> 2013-03-19 22:17 GMT+01:00 Tobias Burnus :
>>> Dear Paul, dear all,
>>>
>>>
>>> On February 24, 2013 Paul Richard Thomas wrote:

 The attached patch represents progress to date.  It fixes the original
 problem in this PR and allows John Reid's version of
 iso_varying_string/vocabulary_word_count.f90 to compile and run
 correctly.  It even bootstraps and regtests!
>>>
>>>
>>> Attached is a re-diffed patch; I have additionally fixed some indenting
>>> issues.
>>>
>>> Additionally, I have tested the patch - and it fails with deferred-length
>>> *array* character components. See attached test case. Also, the following
>>> line of the included test case leaks memory:
>>> allocate (array(2), source = [t("abcedefg","hi"), t("jkl","mnop")])
>>>
>>> I think at least the array bug should be fixed prior committal. (Fixing the
>>> memory leak and some of the below-mentioned issues would be nice, too.)
>>> Otherwise, I think the patch looks fine. For completeness, I have some
>>> naming remarks, which I would also like to considered:
>>> http://thread.gmane.org/gmane.comp.gcc.fortran/40393/focus=281580
>>>
>>> Tobias
>>>
>>>
 However, it doe not fix:
 PR51976 comment #6 and PR51550 - allocate with typespec ICEs
 PR51976 comment #6 FORALL assignment is messed up and ICEs..
 PR47545 the compiler complains about the lack of an initializer for
 the hidden character length field.
 PR45170 will need going through from one end to the other - there is a
 lot of "stuff" here!

 Of these, I consider the fix of the PR47545 problem to be a must and
 the allocate with typespec desirable.



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
   --Hitchhikers Guide to the Galaxy


Re: [PATCH] Use __UINT{16,32,64}_TYPE__ for builtins when available (PR c/37743)

2014-02-19 Thread Joseph S. Myers
On Wed, 19 Feb 2014, Jakub Jelinek wrote:

> Hi!
> 
> This patch changes the return type of the __builtin_bswap{16,32,64} builtins
> to the __UINT{16,32,64}_TYPE__ types if the target defines them, instead
> of a nonstandard integer type, which is a problem for -Wformat warnings
> or for C++ overload resolution.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

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


Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

2014-02-19 Thread Tobias Burnus

Hi Paul,

Paul Richard Thomas wrote:

I had completely forgotten about this patch... I even thought that it
had been applied :-) I'll have time, either tomorrow evening or Saturday to 
take a look.
After nearly 11 months, a couple more days will not hurt!


I think it went as follows: We found out that some code doesn't - in 
particular code which uses array-valued deferred-length characters. 
After trying to fix it, you (Paul) decided that the simplest way to fix 
it would be the new array descriptor - and then it got stuck.


Regarding this patch, I have mixed feelings. I think it is a much wished 
feature - but I am not sure about the stability of the patch and it is 
rather large, given that we are in stage 4.



Regarding the new array descriptor: I think it would be useful if we 
could get the new descriptor working early in the GCC 4.10/5.0/2015 
development stage. I think the main large task is to convert all all 
remaining stride-based code to stride-multiplier code without breaking 
vectorization and causing other regressions. Additionally, it would be 
nice to get rid of "offset" - and have in the descriptor always an 
lower_bound of 0, except for pointers/allocatables (cf. TS29113). I 
think the version on the branch is in a relatively good shape; however, 
the stride and offset changes seem to be of such a kind that one needs 
to modify several code locations simultaneously - otherwise, it will 
break badly. Additionally, all remaining regressions have to be fixed. 
When that's done, adding some extra field is all what's needed. (As 
follow up, enough remains to be done: I'd like to use it for all 
class(*), possibly even for nonarray class(type), assumed-rank needs an 
update, assumed-shape/-rank/deferred-shape character arrays also have to 
be adapted (also mandated by TS29113 for interop). And we should do an 
ABI cleanup in libgfortran as we have now the chance to break the ABI.) 
- Is anyone volunteering?


Also planned for GCC post-4.9: Getting an initial really working coarray 
version.


(Besides more mundane tasks like finishing finalization, completing OOP 
or ...)


Tobias


Re: [PATCH 1/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

2014-02-19 Thread Tobias Burnus

Hi Ilmir,

thanks for your reply; I am looking forward to your updated patch.

Ilmir Usmanov wrote:
I have tested your notes on two compilers which support OpenACC: PGI 
14.1 and CAPS 3.4.1.


I can add Cray ftn results, if you want me to cross-check something.


On 10.02.2014 02:22, Tobias Burnus wrote:


a) Does this part work well when both -fopenmp and -fopenacc is used? 
I mean: "!$acc loop" followed/preceded by "!$omp do"? I could imagine 
that there could be clashes, especially when - e.g. - collapse 
doesn't match.

PGI: Silently ignores OpenMP pragmas.
CAPS: Ignored option '--define' (_OPENMP=).


I like how Cray handles it: It permits both - but neither OpenMP -> 
OpenACC nesting nor vice versa. (It might not always detectable.)


ERROR:
  The !$OMP PARALLEL DO directive cannot be specified within a !$ACC 
PARALLEL region.


And adding OpenACC to an OpenMP loop fails with:

ERROR:
  The !$ACC LOOP directive cannot be specified within a !$OMP PARALLEL 
DO region.


(One gets the same error independent whether one tries to place the 
pragma on the same loop or just nested in the parallel pragma or on 
different loops.)


I think doing likewise would be best. A simpler approach is to reject 
using -fopenmp and -fopenacc simultaneously.


b) Do you also handle DO CONCURRENT - either by rejecting it or by 
accepting it? Namely,


!$acc loop
do concurrent(i=1:5)
end do
!$acc end loop
end
Side remark, with -fopenmp, it does ICE: 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60127


My implemetation also fails, will fix. By the way, should we support 
these loops? I think we should, since DO CONCURRENT loops are 
parallelizable.


I think one should at least error out and not ICE.

The long-term solution should be to support DO CONCURRENT with both 
OpenMP and OpenACC; although one option would be to wait until the specs 
officially support it.


If you want to support it, please recall that do concurrent also permits 
a mask argument, which makes everything a bit more complicated. (Cf. 
gcc/fortran/trans-stmt.c's gfc_trans_forall_1 function.)


No, the spec doesn't specify !$acc end loop. However, compilers handle 
this construction differently:

PGI: silently accepts.


Which is not surprising given that NVidia's and PGI's example often use 
"!$acc end loop". [Cray ftn also accepts it silently.]



+  if (gfc_pure (NULL))
+{
+  gfc_error_now ("OpenACC directives at %C may not appear in 
PURE "

+ "or ELEMENTAL procedures");

...
In any case, either drop "or ELEMENTAL" or also check for the 
elemental attribute.


I think I should drop "or ELEMENTAL" since OpenMP also accepts 
directives in IMPURE ELEMENTAL procecdures.


Fine with me.


+  if (gfc_implicit_pure (NULL))
+gfc_current_ns->proc_name->attr.implicit_pure = 0;


I believe that will fail with BLOCK - cf. gfc_implicit_pure()

Fortunally, it doesn't.


Are you sure that it works? A block starts a new namespace, hence, 
gfc_implicit_pure() does:


--cut---
  /* Check if the current procedure is implicit_pure.  Walk up
 the procedure list until we find a procedure.  */
  for (ns = gfc_current_ns; ns; ns = ns->parent)
{
  sym = ns->proc_name;
  if (sym == NULL)
return 0;

  if (sym->attr.flavor == FL_PROCEDURE)
break;
}
}

  return sym->attr.flavor == FL_PROCEDURE && sym->attr.implicit_pure
&& !sym->attr.pure;
--cut---

But you set "gfc_current_ns->proc_name->attr.implicit_pure = 0". If 
gfc_current_ns is the BLOCK, the procedure might still have the 
"implict_pure" attribute set.


Side question: Do we also need to unset implicit_pure for OpenMP?

Tobias


[PATCH] Fix PR c++/60052.

2014-02-19 Thread Adam Butcher
PR c++/60052
* parser.c (cp_parser_parameter_declaration_list): Correctly reset
implicit_template_scope upon leaving an out-of-line generic member
function definition.

PR c++/60052
* g++.dg/cpp1y/pr60052.C: New testcase.
---
 gcc/cp/parser.c  | 16 +---
 gcc/testsuite/g++.dg/cpp1y/pr60052.C | 15 +++
 2 files changed, 28 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr60052.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 9818213..68573f1 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -18372,11 +18372,21 @@ cp_parser_parameter_declaration_list (cp_parser* 
parser, bool *is_error)
   parser->in_unbraced_linkage_specification_p
 = saved_in_unbraced_linkage_specification_p;
 
+  /* Reset implicit_template_scope if we are about to leave the function
+ parameter list that introduced it.  Note that for out-of-line member
+ definitions, there will be one or more class scopes before we get to
+ the template parameter scope.  */
+
   if (cp_binding_level *its = parser->implicit_template_scope)
-if (current_binding_level->level_chain == its)
+if (cp_binding_level *maybe_its = current_binding_level->level_chain)
   {
-   parser->implicit_template_parms = 0;
-   parser->implicit_template_scope = 0;
+   while (maybe_its->kind == sk_class)
+ maybe_its = maybe_its->level_chain;
+   if (maybe_its == its)
+ {
+   parser->implicit_template_parms = 0;
+   parser->implicit_template_scope = 0;
+ }
   }
 
   return parameters;
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr60052.C 
b/gcc/testsuite/g++.dg/cpp1y/pr60052.C
new file mode 100644
index 000..191e5ac
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr60052.C
@@ -0,0 +1,15 @@
+// PR c++/60052
+// { dg-do compile }
+// { dg-options "-std=c++1y" }
+
+struct A
+{
+  void foo(auto);
+};
+
+void A::foo(auto) {}
+
+struct B
+{
+  void bar(auto);
+};
-- 
1.8.5.5



Re: [PATCH] Fix PR c++/60052 and c++/60053

2014-02-19 Thread Adam Butcher

On 2014-02-20 1:24, Adam Butcher wrote:

PR c++/60052
* parser.c (cp_parser_parameter_declaration_list): Correctly reset
implicit_template_scope upon leaving an out-of-line generic member
function definition.


Turns out this fixes 60053 too.


[PATCH] Fix PR c++/60065.

2014-02-19 Thread Adam Butcher
PR c++/60065
* parser.c (cp_parser_parameter_declaration_list): Use
current_template_parms and scope check as predicate for
inspecting current function template parameter list length
rather than num_template_parameter_lists.

PR c++/60065
* g++.dg/cpp1y/pr60065.C: New testcase.
---
 gcc/cp/parser.c  | 20 +---
 gcc/testsuite/g++.dg/cpp1y/pr60065.C |  8 
 2 files changed, 25 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr60065.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 68573f1..0b88bd3 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -18241,15 +18241,29 @@ cp_parser_parameter_declaration_list (cp_parser* 
parser, bool *is_error)
 = parser->in_unbraced_linkage_specification_p;
   parser->in_unbraced_linkage_specification_p = false;
 
+  /* Determine whether this parameter list applies to a function template
+ currently being declared to support extending the template with generic
+ type parameters.  */
+  bool declaring_template_p = false;
+  if (current_template_parms)
+{
+  cp_binding_level *maybe_tmpl_scope = current_binding_level->level_chain;
+  while (maybe_tmpl_scope && maybe_tmpl_scope->kind == sk_class)
+   maybe_tmpl_scope = maybe_tmpl_scope->level_chain;
+  if (maybe_tmpl_scope && maybe_tmpl_scope->kind == sk_template_parms)
+   declaring_template_p = true;
+}
+
   /* Look for more parameters.  */
   while (true)
 {
   cp_parameter_declarator *parameter;
   tree decl = error_mark_node;
   bool parenthesized_p = false;
-  int template_parm_idx = (parser->num_template_parameter_lists?
-  TREE_VEC_LENGTH (INNERMOST_TEMPLATE_PARMS
-   (current_template_parms)) : 0);
+  int template_parm_idx =
+   ((declaring_template_p || parser->fully_implicit_function_template_p)?
+TREE_VEC_LENGTH (INNERMOST_TEMPLATE_PARMS
+ (current_template_parms)) : 0);
 
   /* Parse the parameter.  */
   parameter
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr60065.C 
b/gcc/testsuite/g++.dg/cpp1y/pr60065.C
new file mode 100644
index 000..2aaa1e3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr60065.C
@@ -0,0 +1,8 @@
+// PR c++/60065
+// { dg-do compile }
+// { dg-options "-std=c++1y" }
+
+template  void foo(auto... x);
+template  void foo2(auto... x);
+template  void foo3(auto... x, auto y, auto... z);
+template  void foo4(auto... x, auto y, auto... z);
-- 
1.9.0



PR ipa/58555

2014-02-19 Thread Jan Hubicka
Hi,
this patch fies the division by zero in recursive_inlining by adding a non-zero 
guard.
More importantly it however fixed ages long bug in clone_inlined_nodes that does
not update properly frequencies of edges when function with already inlined 
edges
is inlined into another function.

Bootstrapped/regtested x86_64-linux, comitted.

Honza

PR ipa/58555
* ipa-inline-transform.c (clone_inlined_nodes): Add freq_scale parameter
specifying the scaling.
(inline_call): Update.
(want_inline_recursively): Guard division by zero.
(recursive_inlining): Update.
* ipa-inline.h (clone_inlined_nodes): Update.
* testsuite/g++.dg/torture/pr58555.C: New testcase.
Index: ipa-inline-transform.c
===
--- ipa-inline-transform.c  (revision 207870)
+++ ipa-inline-transform.c  (working copy)
@@ -127,11 +127,15 @@
the edge and redirect it to the new clone.
DUPLICATE is used for bookkeeping on whether we are actually creating new
clones or re-using node originally representing out-of-line function call.
-   */
+   By default the offline copy is removed, when it appears dead after inlining.
+   UPDATE_ORIGINAL prevents this transformation.
+   If OVERALL_SIZE is non-NULL, the size is updated to reflect the
+   transformation.
+   FREQ_SCALE specify the scaling of frequencies of call sites.  */
 
 void
 clone_inlined_nodes (struct cgraph_edge *e, bool duplicate,
-bool update_original, int *overall_size)
+bool update_original, int *overall_size, int freq_scale)
 {
   struct cgraph_node *inlining_into;
   struct cgraph_edge *next;
@@ -175,8 +179,11 @@
   else
{
  struct cgraph_node *n;
+
+ if (freq_scale == -1)
+   freq_scale = e->frequency;
  n = cgraph_clone_node (e->callee, e->callee->decl,
-e->count, e->frequency, update_original,
+e->count, freq_scale, update_original,
 vNULL, true, inlining_into);
  cgraph_redirect_edge_callee (e, n);
}
@@ -191,7 +198,7 @@
 {
   next = e->next_callee;
   if (!e->inline_failed)
-clone_inlined_nodes (e, duplicate, update_original, overall_size);
+clone_inlined_nodes (e, duplicate, update_original, overall_size, 
freq_scale);
   if (e->speculative && !speculation_useful_p (e, true))
{
  cgraph_resolve_speculation (e, NULL);
@@ -260,7 +267,7 @@
}
 }
 
-  clone_inlined_nodes (e, true, update_original, overall_size);
+  clone_inlined_nodes (e, true, update_original, overall_size, e->frequency);
 
   gcc_assert (curr->callee->global.inlined_to == to);
 
Index: ipa-inline.c
===
--- ipa-inline.c(revision 207870)
+++ ipa-inline.c(working copy)
@@ -708,6 +708,12 @@
   if (outer_node->global.inlined_to)
 caller_freq = outer_node->callers->frequency;
 
+  if (!caller_freq)
+{
+  reason = "function is inlined and unlikely";
+  want_inline = false;
+}
+
   if (!want_inline)
 ;
   /* Inlining of self recursive function into copy of itself within other 
function
@@ -1385,7 +1391,7 @@
false, vNULL, true, NULL);
  for (e = master_clone->callees; e; e = e->next_callee)
if (!e->inline_failed)
- clone_inlined_nodes (e, true, false, NULL);
+ clone_inlined_nodes (e, true, false, NULL, CGRAPH_FREQ_BASE);
   cgraph_redirect_edge_callee (curr, master_clone);
   reset_edge_growth_cache (curr);
}
Index: ipa-inline.h
===
--- ipa-inline.h(revision 207870)
+++ ipa-inline.h(working copy)
@@ -233,7 +233,8 @@
 /* In ipa-inline-transform.c  */
 bool inline_call (struct cgraph_edge *, bool, vec *, int *, 
bool);
 unsigned int inline_transform (struct cgraph_node *);
-void clone_inlined_nodes (struct cgraph_edge *e, bool, bool, int *);
+void clone_inlined_nodes (struct cgraph_edge *e, bool, bool, int *,
+ int freq_scale);
 
 extern int ncalls_inlined;
 extern int nfunctions_inlined;
Index: testsuite/g++.dg/torture/pr58555.C
===
--- testsuite/g++.dg/torture/pr58555.C  (revision 0)
+++ testsuite/g++.dg/torture/pr58555.C  (revision 0)
@@ -0,0 +1,114 @@
+/* { dg-do compile } */
+template  _Tp *__addressof(_Tp &) {}
+template  class A {
+public:
+  typedef _Tp *pointer;
+};
+template  class M : public A<_Tp> {
+public:
+  typedef M other;
+  ~M();
+};
+class B {
+public:
+  B(int *);
+};
+class C {
+public:
+  void GetNext();
+  C *GetChildren();
+};
+template  void _Destroy(_Tp *p1) { p1->~_Tp(); }
+struct D {
+  template 
+  static void __destroy(_ForwardIterato