Re: ifcvt cond_exec support rewrite

2012-03-03 Thread Maxim Kuvyrkov
On 3/03/2012, at 1:55 PM, Maxim Kuvyrkov wrote:

 On 30/09/2011, at 1:11 AM, Bernd Schmidt wrote:
 ...
 
 The following patch rewrites essentially all the cond_exec support in
 ifcvt; reviewing is probably easier if it's thought of as new code.
 
 Kudos for improving if-conversion!
 
 I reviewed this patch to the extent I know ifcvt.c, which is below your level 
 of understanding.

I realized this sentence can be read in two different ways.  Obviously I meant 
that you have a superior understanding of if-conversion than I :-).

  The new implementation looks good to me, and my review mostly focuses on 
 making the code more understandable to someone without the in-depth knowledge 
 of optimization.


--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics




[patch mingw/cygwin]: Allow relocated const data to be put in read-only section by default

2012-03-03 Thread Kai Tietz
Hi,

this patch allows that relocated const data is placed into .rdata.  To provide
old behavior for older runtimes not supporting pseudo-relocation operating on
read-only sections, the option -fwritable-relocated-rdata can be used.

ChangeLog

2012-03-03  Kai Tietz  kti...@redhat.com

* doc/invoke.texi (fwritable-relocated-rdata): Document
new Cygwin/MinGW target option.
* config/i386/winnt.c (i386_pe_unique_section): Ignore
reloc if flag -fwritable-relocated-rdata is not set.
(i386_pe_section_type_flags): Likewise.
* config/i386/cygming.opt (fwritable-relocated-rdata):
Add new flag variable flag_writable_rel_rdata.

Tested for i686-w64-mingw32, x86_64-w64-mingw32, and i686-pc-cygwin.
Ok for apply?

Regards,
Kai

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 184760)
+++ doc/invoke.texi (working copy)
@@ -13826,6 +13826,13 @@
 Windows, as there the user32 API, which is used to set executable
 privileges, isn't available.

+@item -fwritable-relocated-rdata
+@opindex fno-writable-relocated-rdata
+This option is available for MinGW and Cygwin targets.  It specifies
+that relocated-data in read-only section is put into .data
+section.  This is a necessary for older runtimes not supporting
+modification of .rdata sections for pseudo-relocation.
+
 @item -mpe-aligned-commons
 @opindex mpe-aligned-commons
 This option is available for Cygwin and MinGW targets.  It
Index: config/i386/winnt.c
===
--- config/i386/winnt.c (revision 184760)
+++ config/i386/winnt.c (working copy)
@@ -395,6 +395,10 @@
   const char *name, *prefix;
   char *string;

+  /* Ignore RELOC, if we are allowed to put relocated
+ const data into read-only section.  */
+  if (!flag_writable_rel_rdata)
+reloc = 0;
   name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl));
   name = i386_pe_strip_name_encoding_full (name);

@@ -441,6 +445,10 @@
   unsigned int flags;
   unsigned int **slot;

+  /* Ignore RELOC, if we are allowed to put relocated
+ const data into read-only section.  */
+  if (!flag_writable_rel_rdata)
+reloc = 0;
   /* The names we put in the hashtable will always be the unique
  versions given to us by the stringtable, so we can just use
  their addresses as the keys.  */
Index: config/i386/cygming.opt
===
--- config/i386/cygming.opt (revision 184760)
+++ config/i386/cygming.opt (working copy)
@@ -53,4 +53,8 @@
 posix
 Driver

+fwritable-relocated-rdata
+Common Report Var(flag_writable_rel_rdata) Init(0)
+Put relocated read-only data into .data section.
+
 ; Retain blank line above


[fortran, patch] Improve module version error messages

2012-03-03 Thread FX
Hi all,

Attached patch was triggered by PR 52313 
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52313), and tries to improve error 
messages for module reading. It fixes one spelling of GFORTRAN -- GNU 
Fortran and improves the error reporting of old *unversioned* format from:

 Parse error when checking module version for file 'blah.mod' opened at (1)


to:

 Cannot read module file 'blah.mod' opened at (1), because it was created by 
 an older version of GNU Fortran



In addition, I looked at the message emitted for old, *versioned* format:

 Wrong module version '6' (expected '9') for file 'blah.mod' opened at (1)


I think this message is not actually clearer to the user than the new one, so I 
substituted the new message to it too. That means we don't present the version 
strings (which are currently numbers) to the user, and it also seems better to 
me: those are for internal use anyway, and not documented. They're useful only 
to us, and they're written in the module file anyway.

So, bootstrapped and regtested on x86_64-apple-darwin11, OK for trunk?

FX
 




module.ChangeLog
Description: Binary data


module.diff
Description: Binary data


Re: [4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113

2012-03-03 Thread Tobias Burnus

Dear Paul,

thanks for the review.

Paul Richard Thomas wrote:

I have a couple of remarks:
(i) The DTYPE_TYPE_MASK is 0x38 so that we saturated it a long time
since!  At the moment it does not cause any problems because of the
extremely limited use of the dtype 'type'.  Whilst the array
descriptor revamp will eliminate such worries, we should be mindful of
this; and


Thanks for the reminder. I kind of expected such an issue - and decided 
not to worry about it.



(ii) By making such substantial use of scan-tree-dump-times in the
dg-run test case, you are potentially building in instability against
future development, I suppose?  Are the runtime tests not sufficient?


In principle, run-time tests are sufficient. But they rely on C tests - 
or at least on a working C_LOC. However, one currently cannot use 
C_LOC() on assumed-shape variables nor BIND(C) for assumed-shape 
dummies. [Which is allowed in TS29113.]  Besides, the C program needs 
then to make use of gfortran's array descriptor to really check.


I tried a bit, but it gets rather complicated so that at some point, I 
gave up, deleted the traces of the C code and surrendered. I checked the 
argument manually and added them to the scan-tree-dump-times. I tried 
carefully to use them such that they should work on all targets. 
However, if the array descriptor will change, they might break. However, 
the work to fix them once or twice might be less than writing a run-time 
test.


Tobias


Re: PATCH: Add Linux/x32 support to Ada

2012-03-03 Thread Eric Botcazou
 This patch adds Linux/x32 support to Ada.  It sets LIBGNAT_TARGET_PAIRS
 similar to Linux/x86-64 and replaces system-linux-x86_64.ads with
 system-linux-x86.ads.  It also adds orl $0x0,(%esp) check for SIGSEGV
 probe and sets __gnat_default_libgcc_subdir to libx32 for x32.  Tested
 on Linux/x32 with the following Ada test failures:

 FAIL: gnat.dg/curr_task.adb execution test
 FAIL: gnat.dg/lto8.adb (test for excess errors)
 FAIL: gnat.dg/requeue1.adb execution test
 FAIL: gnat.dg/test_image.adb execution test
 FAIL: gnat.dg/timer_cancel.adb execution test
 FAIL: gnat.dg/specs/addr1.ads  (test for bogus messages, line 24)
 FAIL: gnat.dg/specs/addr1.ads (test for excess errors)
 FAIL: gnat.dg/specs/atomic1.ads  (test for errors, line 9)
 FAIL: gnat.dg/specs/atomic1.ads  (test for errors, line 13)

Thanks for working on this.

 2012-03-02  H.J. Lu  hongjiu...@intel.com

   * init.c (__gnat_adjust_context_for_raise): Also check
   orq $0x0,(%esp) for x32.

   * link.c (__gnat_default_libgcc_subdir): set to libx32 for x32.

   * gcc-interface/Makefile.in (arch): Set to x32 if MULTISUBDIR
   is /x32.
   Support x32.

This looks good to me, modulo the following nits:

 --- a/gcc/ada/init.c
 +++ b/gcc/ada/init.c
 @@ -615,9 +615,16 @@ __gnat_adjust_context_for_raise (int signo
 ATTRIBUTE_UNUSED, void *ucontext) if (signo == SIGSEGV  pc  *pc ==
 0x00240c83)
  mcontext-gregs[REG_ESP] += 4096 + 4 * sizeof (unsigned long);
  #elif defined (__x86_64__)
 -  unsigned long *pc = (unsigned long *)mcontext-gregs[REG_RIP];
 -  /* The pattern is orq $0x0,(%rsp) for a probe in 64-bit mode.  */
 -  if (signo == SIGSEGV  pc  (*pc  0xff) == 0x00240c8348)
 +  unsigned long long *pc = (unsigned long long *)mcontext-gregs[REG_RIP];
 +  if (signo == SIGSEGV  pc
 +  /* The pattern is orq $0x0,(%rsp) for a probe in 64-bit mode.  */
 +   ((*pc  0xffLL) == 0x00240c8348LL
 +# ifndef __LP64__
 +  /* The pattern may also be orl $0x0,(%esp) for a probe in x32
 +  mode.  */
 +   || (*pc  0xLL) == 0x00240c83LL
 +# endif
 +  ))
  mcontext-gregs[REG_RSP] += 4096 + 4 * sizeof (unsigned long);
  #elif defined (__ia64__)
/* ??? The IA-64 unwinder doesn't compensate for signals.  */

The preprocessor directive is very likely superfluous, let's remove it and just 
add the || thing.

 diff --git a/gcc/ada/link.c b/gcc/ada/link.c
 index 8bcad27..3648878 100644
 --- a/gcc/ada/link.c
 +++ b/gcc/ada/link.c
 @@ -187,7 +187,11 @@ unsigned char __gnat_using_gnu_linker = 1;
  const char *__gnat_object_library_extension = .a;
  unsigned char __gnat_separate_run_path_options = 0;
  #if defined (__x86_64)
 +# if defined __LP64__
  const char *__gnat_default_libgcc_subdir = lib64;
 +# else
 +const char *__gnat_default_libgcc_subdir = libx32;
 +# endif
  #else
  const char *__gnat_default_libgcc_subdir = lib;
  #endif

Please follow the existing idiom and write defined (__LP64__) instead.

OK with these changes.

-- 
Eric Botcazou


Re: [PATCH, 4.4, PR 52430] IPA-CP has to clone or leave alone externally_visible nodes

2012-03-03 Thread Jakub Jelinek
On Fri, Mar 02, 2012 at 06:54:13PM +1300, Maxim Kuvyrkov wrote:
  --- gcc/ipa-cp.c(revision 184662)
  +++ gcc/ipa-cp.c(working copy)
  @@ -508,7 +508,7 @@ ipcp_initialize_node_lattices (struct cg
  
if (ipa_is_called_with_var_arguments (info))
  type = IPA_BOTTOM;
  -  else if (!node-needed)
  +  else if (!node-needed  !node-local.externally_visible)
  type = IPA_TOP;
/* When cloning is allowed, we can assume that externally visible 
  functions
   are not called.  We will compensate this by cloning later.  */
 
 Because this is for a branch, I would be more conservative and avoid any
 new instances of IPA_TOP -- those that can be obtained from subsequent
 else-if clauses.  I.e.,
 
 else if (!node-needed)
   type = !node-local.externally_visible ? IPA_TOP : IPA_BOTTOM;

The above doesn't add any new instances of IPA_TOP, the
node-local.externally_visible  !node-needed
will be either IPA_BOTTOM, if not desirable for cloning, or IPA_TOP with
n_cloning_candidates++ (previously they would all be IPA_TOP).

I think Martin's patch as is is fine.

Jakub


New German PO file for 'gcc' (version 4.7-b20120128)

2012-03-03 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/gcc/de.po

(This file, 'gcc-4.7-b20120128.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.
coordina...@translationproject.org



Can you have delight over again?

2012-03-03 Thread Leslie Delgado

http://memoriadelcarrer.com/therefore.html Short way to long bed energy



[4.6] Fix PR target/52425

2012-03-03 Thread Eric Botcazou
This is a regression present on the 4.6 branch only.  Applied on the branch.


2012-03-03  Eric Botcazou  ebotca...@adacore.com

PR target/52425
Backport from mainline
2011-05-22  Eric Botcazou  ebotca...@adacore.com

* config/sparc/sparc.c (sparc_delegitimize_address): Handle
UNSPEC_MOVE_PIC pattern.


-- 
Eric Botcazou
Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c	(revision 183919)
+++ config/sparc/sparc.c	(working copy)
@@ -3658,13 +3658,17 @@ sparc_delegitimize_address (rtx x)
 {
   x = delegitimize_mem_from_attrs (x);
 
-  if (GET_CODE (x) == LO_SUM
-   GET_CODE (XEXP (x, 1)) == UNSPEC
-   XINT (XEXP (x, 1), 1) == UNSPEC_TLSLE)
-{
-  x = XVECEXP (XEXP (x, 1), 0, 0);
-  gcc_assert (GET_CODE (x) == SYMBOL_REF);
-}
+  if (GET_CODE (x) == LO_SUM  GET_CODE (XEXP (x, 1)) == UNSPEC)
+switch (XINT (XEXP (x, 1), 1))
+  {
+  case UNSPEC_MOVE_PIC:
+  case UNSPEC_TLSLE:
+	x = XVECEXP (XEXP (x, 1), 0, 0);
+	gcc_assert (GET_CODE (x) == SYMBOL_REF);
+	break;
+  default:
+	break;
+  }
 
   return x;
 }


Re: Fix POINTER_PLUS_EXPR oversight

2012-03-03 Thread Richard Guenther
On Fri, Mar 2, 2012 at 6:59 PM, Mike Stump mikest...@comcast.net wrote:
 On Mar 2, 2012, at 1:33 AM, Richard Guenther wrote:
 Interestingly, the C++ frontend also has a pointer_diff function, but
 doesn't seem to attempt to optimize. Is there a reason for this?

 Frontends should not optimize when they are not required to.

 Actually, the frontends should optimize as long as it produces a faster 
 compilation (and they are permitted to).  You're thinking of the rule that 
 proceeded this one, we switch away from many many years back.

Well, I think we should work towards the FEs preserving as much of the
AST that reflects the source program as possible.

Richard.


Re: [4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113

2012-03-03 Thread Tobias Burnus

Tobias Burnus wrote:

thanks for the review.

Paul Richard Thomas wrote:
[...]


Something is odd. The test case didn't regtest, but I could swear that 
it did so yesterday.


_1.f90: That was correctly failing because one cannot pass an 
assumed-size array to an assumed-shape array.


_4.f90: Somehow, the line has changed.

_3.f90: Besides some more obvious issues, there is:

fourteen is really odd: Depending on the position of that subroutine 
in file, I get an error or not. I think one should try to better 
understand why that happens.


Tobias
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 184855)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,6 +1,13 @@
 2012-03-03  Tobias Burnus  bur...@net-b.de
 
 	PR fortran/48820
+	* gfortran.dg/assumed_type_1.f90: Correct dg-error.
+	* gfortran.dg/assumed_type_3.f90: Correct dg-error.
+	* gfortran.dg/assumed_type_4.f90: Correct dg-error.
+
+2012-03-03  Tobias Burnus  bur...@net-b.de
+
+	PR fortran/48820
 	* gfortran.dg/assumed_type_1.f90: New.
 	* gfortran.dg/assumed_type_2.f90: New.
 	* gfortran.dg/assumed_type_3.f90: New.
Index: gcc/testsuite/gfortran.dg/assumed_type_1.f90
===
--- gcc/testsuite/gfortran.dg/assumed_type_1.f90	(Revision 184855)
+++ gcc/testsuite/gfortran.dg/assumed_type_1.f90	(Arbeitskopie)
@@ -49,7 +49,6 @@ use mpi_interface
 contains
 subroutine foo(x)
 type(*):: x(*)
-call MPI_Send(x, 1, 1,1,1,j,i)
 call MPI_Send2(x, 1, 1,1,1,j,i)
   end
 end
Index: gcc/testsuite/gfortran.dg/assumed_type_4.f90
===
--- gcc/testsuite/gfortran.dg/assumed_type_4.f90	(Revision 184855)
+++ gcc/testsuite/gfortran.dg/assumed_type_4.f90	(Arbeitskopie)
@@ -5,6 +5,6 @@
 !
 ! Test TYPE(*)
 
-subroutine one(a) ! { dg-error TS 29113: Assumed type }
-  type(*)  :: a
+subroutine one(a)
+  type(*)  :: a ! { dg-error TS 29113: Assumed type }
 end subroutine one
Index: gcc/testsuite/gfortran.dg/assumed_type_3.f90
===
--- gcc/testsuite/gfortran.dg/assumed_type_3.f90	(Revision 184855)
+++ gcc/testsuite/gfortran.dg/assumed_type_3.f90	(Arbeitskopie)
@@ -5,6 +5,11 @@
 !
 ! Test TYPE(*)
 
+subroutine fourteen(x)
+  type(*) :: x
+  x = x ! { dg-error Invalid expression with assumed-type variable }
+end subroutine fourteen
+
 subroutine one(a) ! { dg-error may not have the ALLOCATABLE, CODIMENSION, POINTER or VALUE attribute }
   type(*), value :: a
 end subroutine one
@@ -52,10 +57,10 @@ subroutine nine()
 subroutine okay2(x)
   type(*) :: x(*)
 end subroutine okay2
-subroutine okay2(x,y)
+subroutine okay3(x,y)
   integer :: x
   type(*) :: y
-end subroutine okay2
+end subroutine okay3
   end interface
   interface two
 subroutine okok1(x)
@@ -100,10 +105,10 @@ end subroutine eleven
 
 subroutine twelf(x)
   type(*) :: x
-  call bar(x)
+  call bar(x) ! { dg-error Type mismatch in argument }
 contains
   subroutine bar(x)
-integer :: x ! { dg-error Type mismatch in argument }
+integer :: x
   end subroutine bar
 end subroutine twelf
 
@@ -113,7 +118,4 @@ subroutine thirteen(x, y)
   print *, ubound(y, dim=x) ! { dg-error must be INTEGER }
 end subroutine thirteen
 
-subroutine fourteen(x)
-  type(*) :: x
-  x = x ! { dg-error Invalid expression with assumed-type variable }
-end subroutine fourteen
+


[Patch, Fortran] Add -Wc-binding-type warning

2012-03-03 Thread Tobias Burnus

GNU Fortran warns by default for code like the following:

interface
  subroutine sub (n)  bind (C)
integer :: n
  end subroutine sub
end interface

Namely, it prints:

Warning: Variable 'n' at (1) is a parameter to the BIND(C) procedure 
'sub' but may not be C interoperable



That's on one hand correct: There is no defined relation between Fortran 
default kinds (or any kind number) and the C types. Thus, the proper way 
is to use the parameters defined in ISO_C_BINDING, such as c_int.


On the other hand, integer and int is the same on many (but not on 
all systems) and, thus, many users simply use the default type.


Compiling interfaces with hundreds of such definitions clutters the 
screen with those warnings and makes it difficult to spot other warnings.


Thus, this patch adds a warning flag for this purpose - and it also 
excludes those warnings from the default setting. That's a bit in line 
with Fortran 2008 and TS 29113, which remove more and more constraints 
and force the users to ensure themselves that the variables are 
interoperable. However, keeping it as default warning is also fine with me.


Build and regtested on x86-64-linux.
OK?

Tobias
2012-03-03  Tobias Burnus  bur...@net-b.de

	* lang.opt (Wc-binding-type): New flag.
	* options.c (gfc_init_options, gfc_handle_option): Handle it.
	* invoke.texi (Wc-binding-type): Document it.
	* gfortran.h (gfc_option_t): Add warn_c_binding_type.
	* decl.c (verify_bind_c_sym): Handle -Wc-binding-type.
	* symbol.c (gfc_set_default_type, verify_bind_c_derived_type):
	Ditto.

2012-03-03  Tobias Burnus  bur...@net-b.de

	* gfortran.dg/bind_c_dts_4.f03: Add dg-options -Wc-binding-type.
	* gfortran.dg/bind_c_implicit_vars.f03: Ditto.
	* gfortran.dg/bind_c_usage_8.f03: Ditto.
	* gfortran.dg/c_kind_tests_2.f03: Ditto.
	* gfortran.dg/class_30.f90: Remove dg-warning line.
	* gfortran.dg/bind_c_usage_25.f90: New.

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index bdb8c39..75b8a89 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3930,7 +3930,7 @@ verify_bind_c_sym (gfc_symbol *tmp_sym, gfc_typespec *ts,
 {
   tmp_sym = tmp_sym-result;
   /* Make sure it wasn't an implicitly typed result.  */
-  if (tmp_sym-attr.implicit_type)
+  if (tmp_sym-attr.implicit_type  gfc_option.warn_c_binding_type)
 	{
 	  gfc_warning (Implicitly declared BIND(C) function '%s' at 
%L may not be C interoperable, tmp_sym-name,
@@ -3951,7 +3951,7 @@ verify_bind_c_sym (gfc_symbol *tmp_sym, gfc_typespec *ts,
   if (gfc_verify_c_interop ((tmp_sym-ts)) != SUCCESS)
 	{
 	  /* See if we're dealing with a sym in a common block or not.	*/
-	  if (is_in_common == 1)
+	  if (is_in_common == 1  gfc_option.warn_c_binding_type)
 	{
 	  gfc_warning (Variable '%s' in common block '%s' at %L 
may not be a C interoperable 
@@ -3965,7 +3965,7 @@ verify_bind_c_sym (gfc_symbol *tmp_sym, gfc_typespec *ts,
 gfc_error (Type declaration '%s' at %L is not C 
interoperable but it is BIND(C),
tmp_sym-name, (tmp_sym-declared_at));
-  else
+  else if (gfc_option.warn_c_binding_type)
 gfc_warning (Variable '%s' at %L 
  may not be a C interoperable 
  kind but it is bind(c),
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index a5edd13..1c242b4 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2200,6 +2201,7 @@ typedef struct
   int warn_aliasing;
   int warn_ampersand;
   int gfc_warn_conversion;
+  int warn_c_binding_type;
   int warn_conversion_extra;
   int warn_function_elimination;
   int warn_implicit_interface;
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 1f6de84..38ebfe9 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -142,7 +142,7 @@ by type.  Explanations are in the following sections.
 @xref{Error and Warning Options,,Options to request or suppress errors
 and warnings}.
 @gccoptlist{-Waliasing -Wall -Wampersand -Warray-bounds
--Wcharacter-truncation @gol
+-Wc-binding-type -Wcharacter-truncation @gol
 -Wconversion -Wfunction-elimination -Wimplicit-interface @gol
 -Wimplicit-procedure -Wintrinsic-shadow -Wintrinsics-std @gol
 -Wline-truncation -Wno-align-commons -Wno-tabs -Wreal-q-constant @gol
@@ -773,6 +773,14 @@ Warn about array temporaries generated by the compiler.  The information
 generated by this warning is sometimes useful in optimization, in order to
 avoid such temporaries.
 
+@item -Wc-binding-type
+@opindex @code{Wc-binding-type}
+@cindex warning, C binding type
+Warn if the a variable might not be C interoperable.  In particular, warn if 
+the variable has been declared using an intrinsic type with default kind
+instead of using a kind parameter defined for C interoperability in the
+intrinsic @code{ISO_C_Binding} module.
+
 @item 

[fortran, patch] Fix display of locus when source contains wide characters

2012-03-03 Thread FX
The attached patch fixes PR 36160 
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36160). It should correctly 
account for wide characters when display error loci. I'm not sure if we can 
check that in the testsuite harness, but you can manually see it at work on the 
attached test.f90.

Bootstrapped and regtested on x86_64-apple-darwin11, OK for trunk?
FX




widechar_locus.ChangeLog
Description: Binary data


widechar_locus.diff
Description: Binary data


test.f90
Description: Binary data


Re: [Patch, Fortran] Add -Wc-binding-type warning

2012-03-03 Thread FX
 Thus, this patch adds a warning flag for this purpose - and it also excludes 
 those warnings from the default setting. That's a bit in line with Fortran 
 2008 and TS 29113, which remove more and more constraints and force the users 
 to ensure themselves that the variables are interoperable. However, keeping 
 it as default warning is also fine with me.

No, please really remove them, I find them really annoying (and I think I 
argued against it at some point during ISO_C_BINDING merge!). They warn you not 
about something that is wrong, but something that is unportable and could be 
wrong, but probably is OK in most cases. It can have value, but not as a 
default warning I think.

I don't think I can approve patches given that I'm not following gfortran 
development very closely, but if I could I would approve it, it seems OK :)

FX


Re: [fortran, patch] Allow displaying backtraces from user code

2012-03-03 Thread Steve Kargl
On Sat, Mar 03, 2012 at 08:44:56AM +0100, FX wrote:
 PR 36044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044) is an 
 enhancement request for a way to display backtraces from user code. I'm 
 against adding yet another nonstandard intrinsic for this purpose (which is 
 how Intel Fortran does it), but I would like to offer the following solution 
 to the issue, as I think it can be useful in some cases (and the way I 
 suggest should not be a maintainance burden for us):
 
   -- export _gfortran_show_backtrace() from libgfortran (instead of it being 
 an internal function)
   -- add documentation on how to call this function from user-code using 
 BIND(C)
 
 Patch was bootstrapped and regtested on x86_64-apple-darwin11, also tested 
 with make info html pdf. OK for trunk?
 FX
 
 

I think that this approach is a mistake.  The patch
starts us down a slippery slope.  Why not export all
the nonstandard intrinsics?  In additions, the 
_gfortran_ prefix was used to separate the libgfortran
namespace from userspace.  Providing a means to 
circumvent this separation seems to asking for more
PR.

I would rather see a new intrinsic procedure add to
gfortran.  The standard does not prevent a vendor
from offer additional intrinsic procedures not found
in the standard.

-- 
Steve


Re: [fortran, patch] Improve module version error messages

2012-03-03 Thread Steve Kargl
On Sat, Mar 03, 2012 at 10:53:24AM +0100, FX wrote:
 Hi all,
 
 Attached patch was triggered by PR 52313 
 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52313), and tries to improve 
 error messages for module reading. It fixes one spelling of GFORTRAN -- 
 GNU Fortran and improves the error reporting of old *unversioned* format 
 from:
 
  Parse error when checking module version for file 'blah.mod' opened at (1)
 
 
 to:
 
  Cannot read module file 'blah.mod' opened at (1), because it was created by 
  an older version of GNU Fortran
 
 
 
 In addition, I looked at the message emitted for old, *versioned* format:
 
  Wrong module version '6' (expected '9') for file 'blah.mod' opened at (1)
 
 
 I think this message is not actually clearer to the user than the new one, so 
 I substituted the new message to it too. That means we don't present the 
 version strings (which are currently numbers) to the user, and it also seems 
 better to me: those are for internal use anyway, and not documented. They're 
 useful only to us, and they're written in the module file anyway.
 
 So, bootstrapped and regtested on x86_64-apple-darwin11, OK for trunk?
 
 FX
  

OK.

-- 
Steve


Re: [fortran, patch] Improve module version error messages

2012-03-03 Thread Janne Blomqvist
On Sat, Mar 3, 2012 at 11:53, FX fxcoud...@gmail.com wrote:
 Hi all,

 Attached patch was triggered by PR 52313 
 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52313), and tries to improve 
 error messages for module reading. It fixes one spelling of GFORTRAN -- 
 GNU Fortran and improves the error reporting of old *unversioned* format 
 from:

 Parse error when checking module version for file 'blah.mod' opened at (1)


 to:

 Cannot read module file 'blah.mod' opened at (1), because it was created by 
 an older version of GNU Fortran

What if the .mod file has been created by another compiler? Or do we
have a separate error message for that?

 In addition, I looked at the message emitted for old, *versioned* format:

 Wrong module version '6' (expected '9') for file 'blah.mod' opened at (1)


 I think this message is not actually clearer to the user than the new one, so 
 I substituted the new message to it too. That means we don't present the 
 version strings (which are currently numbers) to the user, and it also seems 
 better to me: those are for internal use anyway, and not documented. They're 
 useful only to us, and they're written in the module file anyway.

Yes, showing the version number isn't really useful.




-- 
Janne Blomqvist


Re: [Patch, Fortran] Add -Wc-binding-type warning

2012-03-03 Thread Steve Kargl
On Sat, Mar 03, 2012 at 03:23:01PM +0100, Tobias Burnus wrote:
 GNU Fortran warns by default for code like the following:
 
 interface
   subroutine sub (n)  bind (C)
 integer :: n
   end subroutine sub
 end interface
 
 Namely, it prints:
 
 Warning: Variable 'n' at (1) is a parameter to the BIND(C) procedure 
 'sub' but may not be C interoperable
 
 That's on one hand correct: There is no defined relation between Fortran 
 default kinds (or any kind number) and the C types. Thus, the proper way 
 is to use the parameters defined in ISO_C_BINDING, such as c_int.
 
 On the other hand, integer and int is the same on many (but not on 
 all systems) and, thus, many users simply use the default type.
 
 Compiling interfaces with hundreds of such definitions clutters the 
 screen with those warnings and makes it difficult to spot other warnings.
 
 Thus, this patch adds a warning flag for this purpose - and it also 
 excludes those warnings from the default setting. That's a bit in line 
 with Fortran 2008 and TS 29113, which remove more and more constraints 
 and force the users to ensure themselves that the variables are 
 interoperable. However, keeping it as default warning is also fine with me.
 
 Build and regtested on x86-64-linux.
 OK?
 

OK.

-- 
Steve


Re: PATCH: Add Linux/x32 support to Ada

2012-03-03 Thread H.J. Lu
On Sat, Mar 3, 2012 at 2:31 AM, Eric Botcazou ebotca...@adacore.com wrote:
 This patch adds Linux/x32 support to Ada.  It sets LIBGNAT_TARGET_PAIRS
 similar to Linux/x86-64 and replaces system-linux-x86_64.ads with
 system-linux-x86.ads.  It also adds orl $0x0,(%esp) check for SIGSEGV
 probe and sets __gnat_default_libgcc_subdir to libx32 for x32.  Tested
 on Linux/x32 with the following Ada test failures:

 FAIL: gnat.dg/curr_task.adb execution test
 FAIL: gnat.dg/lto8.adb (test for excess errors)
 FAIL: gnat.dg/requeue1.adb execution test
 FAIL: gnat.dg/test_image.adb execution test
 FAIL: gnat.dg/timer_cancel.adb execution test
 FAIL: gnat.dg/specs/addr1.ads  (test for bogus messages, line 24)
 FAIL: gnat.dg/specs/addr1.ads (test for excess errors)
 FAIL: gnat.dg/specs/atomic1.ads  (test for errors, line 9)
 FAIL: gnat.dg/specs/atomic1.ads  (test for errors, line 13)

 Thanks for working on this.

 2012-03-02  H.J. Lu  hongjiu...@intel.com

       * init.c (__gnat_adjust_context_for_raise): Also check
       orq $0x0,(%esp) for x32.

       * link.c (__gnat_default_libgcc_subdir): set to libx32 for x32.

       * gcc-interface/Makefile.in (arch): Set to x32 if MULTISUBDIR
       is /x32.
       Support x32.

 This looks good to me, modulo the following nits:

 --- a/gcc/ada/init.c
 +++ b/gcc/ada/init.c
 @@ -615,9 +615,16 @@ __gnat_adjust_context_for_raise (int signo
 ATTRIBUTE_UNUSED, void *ucontext) if (signo == SIGSEGV  pc  *pc ==
 0x00240c83)
      mcontext-gregs[REG_ESP] += 4096 + 4 * sizeof (unsigned long);
  #elif defined (__x86_64__)
 -  unsigned long *pc = (unsigned long *)mcontext-gregs[REG_RIP];
 -  /* The pattern is orq $0x0,(%rsp) for a probe in 64-bit mode.  */
 -  if (signo == SIGSEGV  pc  (*pc  0xff) == 0x00240c8348)
 +  unsigned long long *pc = (unsigned long long *)mcontext-gregs[REG_RIP];
 +  if (signo == SIGSEGV  pc
 +      /* The pattern is orq $0x0,(%rsp) for a probe in 64-bit mode.  */
 +       ((*pc  0xffLL) == 0x00240c8348LL
 +# ifndef __LP64__
 +      /* The pattern may also be orl $0x0,(%esp) for a probe in x32
 +      mode.  */
 +       || (*pc  0xLL) == 0x00240c83LL
 +# endif
 +      ))
      mcontext-gregs[REG_RSP] += 4096 + 4 * sizeof (unsigned long);
  #elif defined (__ia64__)
    /* ??? The IA-64 unwinder doesn't compensate for signals.  */

 The preprocessor directive is very likely superfluous, let's remove it and 
 just
 add the || thing.

 diff --git a/gcc/ada/link.c b/gcc/ada/link.c
 index 8bcad27..3648878 100644
 --- a/gcc/ada/link.c
 +++ b/gcc/ada/link.c
 @@ -187,7 +187,11 @@ unsigned char __gnat_using_gnu_linker = 1;
  const char *__gnat_object_library_extension = .a;
  unsigned char __gnat_separate_run_path_options = 0;
  #if defined (__x86_64)
 +# if defined __LP64__
  const char *__gnat_default_libgcc_subdir = lib64;
 +# else
 +const char *__gnat_default_libgcc_subdir = libx32;
 +# endif
  #else
  const char *__gnat_default_libgcc_subdir = lib;
  #endif

 Please follow the existing idiom and write defined (__LP64__) instead.

 OK with these changes.


I checked in the updated change.

Thanks.

-- 
H.J.


PATCH: Backport x32 support to libtool

2012-03-03 Thread H.J. Lu
Hi,

This patch backports x32 support to libtool:

http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=88992fe6771ec3258bde1b03314ce579da0ac2d5

OK to install?

Thanks.


H.J.
---
ommit 0d8c092cac25c3bce5dbfc1981b84df91b3f6086
Author: H.J. Lu hjl.to...@gmail.com
Date:   Mon Dec 12 13:03:14 2011 -0800

Add x32 support to libtool.m4

2011-12-12  H.J. Lu  hongjiu...@intel.com

* libtool.m4 (_LT_ENABLE_LOCK): Support x32.

diff --git a/ChangeLog.x32 b/ChangeLog.x32
new file mode 100644
index 000..b6e01ee
--- /dev/null
+++ b/ChangeLog.x32
@@ -0,0 +1,3 @@
+2011-12-12  H.J. Lu  hongjiu...@intel.com
+
+   * libtool.m4 (_LT_ENABLE_LOCK): Support x32.
diff --git a/libtool.m4 b/libtool.m4
index 67321a7..a7f99ac 100644
--- a/libtool.m4
+++ b/libtool.m4
@@ -1232,7 +1232,14 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
LD=${LD-ld} -m elf_i386_fbsd
;;
  x86_64-*linux*)
-   LD=${LD-ld} -m elf_i386
+   case `/usr/bin/file conftest.o` in
+ *x86-64*)
+   LD=${LD-ld} -m elf32_x86_64
+   ;;
+ *)
+   LD=${LD-ld} -m elf_i386
+   ;;
+   esac
;;
  ppc64-*linux*|powerpc64-*linux*)
LD=${LD-ld} -m elf32ppclinux


Re: [4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1

2012-03-03 Thread Richard Henderson
On 03/02/2012 10:11 AM, Richard Henderson wrote:
 I'm in the process of sanity testing this on x86_64 with trueval set to 0x80.
 Jakub, ok for 4.7 branch if it passes?
 
   * optabs.c (expand_atomic_test_and_set): Honor
   atomic_test_and_set_trueval even when atomic_test_and_set
   optab is not in use.

I've committed this patch to mainline.  I still think it ought to 
go onto the 4.7 branch...


r~


Re: [4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113

2012-03-03 Thread Tobias Burnus

Tobias Burnus wrote:

_3.f90: [...]
fourteen is really odd: Depending on the position of that subroutine 
in file, I get an error or not. I think one should try to better 
understand why that happens.


I found it with the help of Paul. The problem was that I set instead of 
re-set the variable at the end of resolve_actual_arglist. Now, it works.


Committed the attached patch as Rev. 184863 after a fresh rebuild and 
regtesting.


Tobias

PS: Sorry for the glitches.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(Revision 184861)
+++ gcc/fortran/resolve.c	(Arbeitskopie)
@@ -1833,7 +1833,7 @@ resolve_actual_arglist (gfc_actual_arglist *arg, p
   return FAILURE;
 }
 }
-  assumed_type_expr_allowed = true;
+  assumed_type_expr_allowed = false;
 
   return SUCCESS;
 }
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 184861)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,11 @@
 2012-03-03  Tobias Burnus  bur...@net-b.de
 
+	PR fortran/48820
+	* resolve.c (resolve_actual_arglist): Properly reset
+	assumed_type_expr_allowed.
+
+2012-03-03  Tobias Burnus  bur...@net-b.de
+
 	* lang.opt (Wc-binding-type): New flag.
 	* options.c (gfc_init_options, gfc_handle_option): Handle it.
 	* invoke.texi (Wc-binding-type): Document it.
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 184861)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,10 @@
 2012-03-03  Tobias Burnus  bur...@net-b.de
 
+	PR fortran/48820
+	* gfortran.dg/assumed_type_3.f90: Undo previous commit.
+
+2012-03-03  Tobias Burnus  bur...@net-b.de
+
 	* gfortran.dg/bind_c_dts_4.f03: Add dg-options -Wc-binding-type.
 	* gfortran.dg/bind_c_implicit_vars.f03: Ditto.
 	* gfortran.dg/bind_c_usage_8.f03: Ditto.
Index: gcc/testsuite/gfortran.dg/assumed_type_3.f90
===
--- gcc/testsuite/gfortran.dg/assumed_type_3.f90	(Revision 184861)
+++ gcc/testsuite/gfortran.dg/assumed_type_3.f90	(Arbeitskopie)
@@ -5,11 +5,6 @@
 !
 ! Test TYPE(*)
 
-subroutine fourteen(x)
-  type(*) :: x
-  x = x ! { dg-error Invalid expression with assumed-type variable }
-end subroutine fourteen
-
 subroutine one(a) ! { dg-error may not have the ALLOCATABLE, CODIMENSION, POINTER or VALUE attribute }
   type(*), value :: a
 end subroutine one
@@ -118,4 +113,7 @@ subroutine thirteen(x, y)
   print *, ubound(y, dim=x) ! { dg-error must be INTEGER }
 end subroutine thirteen
 
-
+subroutine fourteen(x)
+  type(*) :: x
+  x = x ! { dg-error Invalid expression with assumed-type variable }
+end subroutine fourteen


Re: [4.7][SH] Binary compatibility with atomic_test_and_test_trueval != 1

2012-03-03 Thread Jakub Jelinek
On Sat, Mar 03, 2012 at 10:31:17AM -0800, Richard Henderson wrote:
 On 03/02/2012 10:11 AM, Richard Henderson wrote:
  I'm in the process of sanity testing this on x86_64 with trueval set to 
  0x80.
  Jakub, ok for 4.7 branch if it passes?
  
  * optabs.c (expand_atomic_test_and_set): Honor
  atomic_test_and_set_trueval even when atomic_test_and_set
  optab is not in use.
 
 I've committed this patch to mainline.  I still think it ought to 
 go onto the 4.7 branch...

Ok.

Jakub


Re: [fortran, patch] Improve module version error messages

2012-03-03 Thread FX
 What if the .mod file has been created by another compiler? Or do we have a 
 separate error message for that?

For that, we get (only spelling was fixed by my patch, the message already 
existed):

 Fatal Error: File 'foo.mod' opened at (1) is not a GNU Fortran module file

I committed the patch based on Steve approval. Thanks for the review!

FX


Re: [fortran, patch] Allow displaying backtraces from user code

2012-03-03 Thread FX
 I think that this approach is a mistake.  The patch
 starts us down a slippery slope.  Why not export all
 the nonstandard intrinsics?  In additions, the 
 _gfortran_ prefix was used to separate the libgfortran
 namespace from userspace.  Providing a means to 
 circumvent this separation seems to asking for more
 PR.

Well, the mean exists. All _gfortran_* functions can already be called, they're 
part of libgfortran's public (and versioned) API. I'm just saying adding a 
simple backtrace function to that list is useful, and documenting it too.

 I would rather see a new intrinsic procedure add to
 gfortran.  The standard does not prevent a vendor
 from offer additional intrinsic procedures not found
 in the standard.

I just think multiplicating vendor intrinsics makes our life harder. I'd like 
to hear other's opinions on this issue, but I'll implement the new intrinsic if 
that's the consensus.

Thanks,
FX


Re: [fortran, patch] Improve module version error messages

2012-03-03 Thread Janne Blomqvist
On Sat, Mar 3, 2012 at 23:02, FX fxcoud...@gmail.com wrote:
 What if the .mod file has been created by another compiler? Or do we have a 
 separate error message for that?

 For that, we get (only spelling was fixed by my patch, the message already 
 existed):

 Fatal Error: File 'foo.mod' opened at (1) is not a GNU Fortran module file

Ah, good!

Another thing I realized, would it be better to change the error message

Cannot read module file 'blah.mod' opened at (1), because it was
created by an older version of GNU Fortran

to because it was created by a different version of GNU Fortran, or
something like that which would take into account the possibility that
the .mod file was created by a newer GFortran version?


-- 
Janne Blomqvist


[patch committed SH] Fix sh64-elf build failure [1/3]

2012-03-03 Thread Kaz Kojima
Hi,

This is the first one of the 3 tiny patches to fix the build failures
for sh64-elf.

stmt.c:lshift_cheap_p is testing the cost for (ashift (const1_rtx) (reg)).
SH doesn't such insns but returns COSTS_N_INSNS (1) as its cost for
SHmedia target.  This results an unrecognized insn error for that target.
Also sh.c:sh_rtx_costs returns COSTS_N_INSNS (MAX_COST) instead of MAX_COST
for non existant shift patterns.  The patch below is to fix these problems.
Regtested on sh4-unkonwn-linux-gnu.

Regards,
kaz
--
2012-03-03  Kaz Kojima  kkoj...@gcc.gnu.org

* config/sh/sh.c (shiftcosts): Return MAX_COST when the first
operand is CONST_INT.  Take COSTS_N_INSNS into account.
(sh_rtx_costs): Don't apply COSTS_N_INSNS to the return value
of shiftcosts.

diff -up ORIG/trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.c
--- ORIG/trunk/gcc/config/sh/sh.c   2012-03-03 11:53:10.0 +0900
+++ trunk/gcc/config/sh/sh.c2012-03-03 17:40:19.0 +0900
@@ -2828,22 +2828,26 @@ shiftcosts (rtx x)
 {
   int value;
 
+  /* There is no pattern for constant first operand.  */
+  if (CONST_INT_P (XEXP (x, 0)))
+return MAX_COST;
+
   if (TARGET_SHMEDIA)
-return 1;
+return COSTS_N_INSNS (1);
 
   if (GET_MODE_SIZE (GET_MODE (x))  UNITS_PER_WORD)
 {
   if (GET_MODE (x) == DImode
   CONST_INT_P (XEXP (x, 1))
   INTVAL (XEXP (x, 1)) == 1)
-   return 2;
+   return COSTS_N_INSNS (2);
 
   /* Everything else is invalid, because there is no pattern for it.  */
   return MAX_COST;
 }
   /* If shift by a non constant, then this will be expensive.  */
   if (!CONST_INT_P (XEXP (x, 1)))
-return SH_DYNAMIC_SHIFT_COST;
+return COSTS_N_INSNS (SH_DYNAMIC_SHIFT_COST);
 
   /* Otherwise, return the true cost in instructions.  Cope with out of range
  shift counts more or less arbitrarily.  */
@@ -2855,10 +2859,10 @@ shiftcosts (rtx x)
   /* If SH3, then we put the constant in a reg and use shad.  */
   if (cost  1 + SH_DYNAMIC_SHIFT_COST)
cost = 1 + SH_DYNAMIC_SHIFT_COST;
-  return cost;
+  return COSTS_N_INSNS (cost);
 }
   else
-return shift_insns[value];
+return COSTS_N_INSNS (shift_insns[value]);
 }
 
 /* Return the cost of an AND/XOR/IOR operation.  */
@@ -3091,7 +3095,7 @@ sh_rtx_costs (rtx x, int code, int outer
 case ASHIFT:
 case ASHIFTRT:
 case LSHIFTRT:
-  *total = COSTS_N_INSNS (shiftcosts (x));
+  *total = shiftcosts (x);
   return true;
 
 case DIV:


[patch committed SH] Fix sh64-elf build failure [2/3]

2012-03-03 Thread Kaz Kojima
The attatched patch is to fix a thinko in sh_dwarf_register_span
which was found with a failure during sh64-elf build.  Regtested
on sh4-unkonwn-linux-gnu.

Regards,
kaz
--
2012-03-03  Kaz Kojima  kkoj...@gcc.gnu.org

* config/sh/sh.c (sh_dwarf_register_span): Don't apply
DBX_REGISTER_NUMBER.

diff -up ORIG/trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.c
--- ORIG/trunk/gcc/config/sh/sh.c   2012-03-03 17:40:19.0 +0900
+++ trunk/gcc/config/sh/sh.c2012-03-03 17:41:48.0 +0900
@@ -8162,10 +8162,8 @@ sh_dwarf_register_span (rtx reg)
   return
 gen_rtx_PARALLEL (VOIDmode,
  gen_rtvec (2,
-gen_rtx_REG (SFmode,
- DBX_REGISTER_NUMBER (regno+1)),
-gen_rtx_REG (SFmode,
- DBX_REGISTER_NUMBER (regno;
+gen_rtx_REG (SFmode, regno + 1),
+gen_rtx_REG (SFmode, regno)));
 }
 
 static enum machine_mode


[patch committed SH] Fix sh64-elf build failure [3/3]

2012-03-03 Thread Kaz Kojima
The attached patch is a one liner to fix another unrecognized
error when compiling libgcc on sh64-elf.  We have no abssi2
insn for SHmedia ATM.  Regtested on sh4-unkonwn-linux-gnu.

Regards,
kaz
--
2012-03-03  Kaz Kojima  kkoj...@gcc.gnu.org

* config/sh/sh.md (abssi2): Add TARGET_SH1 condition.

diff -up ORIG/trunk/gcc/config/sh/sh.md trunk/gcc/config/sh/sh.md
--- ORIG/trunk/gcc/config/sh/sh.md  2012-02-27 09:57:51.0 +0900
+++ trunk/gcc/config/sh/sh.md   2012-03-01 12:55:49.0 +0900
@@ -4462,7 +4462,7 @@ label:
   [(set (match_operand:SI 0 arith_reg_dest )
(abs:SI (match_operand:SI 1 arith_reg_operand )))
(clobber (reg:SI T_REG))]
-  
+  TARGET_SH1
   )
 
 (define_insn_and_split *abssi2


Re: C++ PATCH for c++/51925 (ICE with using in template)

2012-03-03 Thread Jason Merrill

On 01/23/2012 11:59 AM, Jason Merrill wrote:

The problem in this case was that a few places in the compiler were
assuming that when we have an OVERLOAD, all the functions within it come
from the same context. But that isn't the case when we have
using-declarations involved, so we need to take them into account.


Here's an associated representation change that I held back until stage 1.

Tested x86_64-pc-linux-gnu, applying to trunk.

commit 98637c44e8829792172581d449b3835588dc5563
Author: Jason Merrill ja...@redhat.com
Date:   Mon Jan 23 11:06:38 2012 -0500

	* class.c (add_method): Always build an OVERLOAD for using-decls.
	* search.c (lookup_member): Handle getting an OVERLOAD for a
	single function.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 5d834d9..6ed4cde 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -1117,9 +1117,13 @@ add_method (tree type, tree method, tree using_decl)
 return false;
 
   /* Add the new binding.  */
-  overload = build_overload (method, current_fns);
-  if (using_decl  TREE_CODE (overload) == OVERLOAD)
-OVL_USED (overload) = true;
+  if (using_decl)
+{
+  overload = ovl_cons (method, current_fns);
+  OVL_USED (overload) = true;
+}
+  else
+overload = build_overload (method, current_fns);
 
   if (conv_p)
 TYPE_HAS_CONVERSION (type) = 1;
diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index e48dcec..a1f8a3d 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -1250,10 +1250,12 @@ lookup_member (tree xbasetype, tree name, int protect, bool want_type,
 only the first call to f is valid.  However, if the function is
 static, we can check.  */
   if (rval  protect 
-   !really_overloaded_fn (rval)
-   !(TREE_CODE (rval) == FUNCTION_DECL
-	DECL_NONSTATIC_MEMBER_FUNCTION_P (rval)))
-perform_or_defer_access_check (basetype_path, rval, rval);
+   !really_overloaded_fn (rval))
+{
+  tree decl = is_overloaded_fn (rval) ? get_first_fn (rval) : rval;
+  if (!DECL_NONSTATIC_MEMBER_FUNCTION_P (decl))
+	perform_or_defer_access_check (basetype_path, decl, decl);
+}
 
   if (errstr  protect)
 {


C++ PATCH for NSDMI that depends on itself

2012-03-03 Thread Jason Merrill
While thinking about core issue 1351, I noticed that we weren't dealing 
very well with an NSDMI that depends on itself.  This patch gives a 
helpful error message.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 46131bcba27d82f43a26daa12a8c8e95f7208696
Author: Jason Merrill ja...@redhat.com
Date:   Mon Feb 20 06:15:24 2012 -0500

	* init.c (perform_member_init): Cope with uninstantiated NSDMI.

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 2355a04..1b2a1ef 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -540,6 +540,12 @@ perform_member_init (tree member, tree init)
   else
 	{
 	  init = DECL_INITIAL (member);
+	  if (init  TREE_CODE (init) == DEFAULT_ARG)
+	{
+	  error (constructor required before non-static data member 
+		 for %qD has been parsed, member);
+	  init = NULL_TREE;
+	}
 	  /* Strip redundant TARGET_EXPR so we don't need to remap it, and
 	 so the aggregate init code below will see a CONSTRUCTOR.  */
 	  if (init  TREE_CODE (init) == TARGET_EXPR
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C b/gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C
new file mode 100644
index 000..033c142
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++11 } }
+
+struct A			// { dg-error non-static data member }
+{
+  int i = (A(), 42);		// { dg-message required here }
+};
+
+A a;


C++ PATCH for core issue 1270 (brace elision in list-initialization of temporaries)

2012-03-03 Thread Jason Merrill
The initializer-list paper did not allow brace elision for all 
list-initialization, only for the traditional C aggregate 
initialization.  But extending it to all list-initialization has been 
deemed desirable, so this patch implements that.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 649364f67c5020e231818384cd03bc6ec17c9ca5
Author: Jason Merrill ja...@redhat.com
Date:   Wed Feb 1 06:15:19 2012 -0500

	Core 1270
	* call.c (build_aggr_conv): Call reshape_init.
	(convert_like_real): Likewise.
	* typeck2.c (process_init_constructor): Clear TREE_CONSTANT if
	not all constant.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c962ca0..8baad82 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -886,6 +886,10 @@ build_aggr_conv (tree type, tree ctor, int flags)
   tree field = next_initializable_field (TYPE_FIELDS (type));
   tree empty_ctor = NULL_TREE;
 
+  ctor = reshape_init (type, ctor, tf_none);
+  if (ctor == error_mark_node)
+return NULL;
+
   for (; field; field = next_initializable_field (DECL_CHAIN (field)))
 {
   tree ftype = TREE_TYPE (field);
@@ -5795,6 +5799,7 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum,
 	  expr = build2 (COMPLEX_EXPR, totype, real, imag);
 	  return fold_if_not_in_template (expr);
 	}
+  expr = reshape_init (totype, expr, complain);
   return get_target_expr (digest_init (totype, expr, complain));
 
 default:
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index a2606f1..974f92f 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1392,7 +1392,10 @@ process_init_constructor (tree type, tree init, tsubst_flags_t complain)
   TREE_TYPE (init) = type;
   if (TREE_CODE (type) == ARRAY_TYPE  TYPE_DOMAIN (type) == NULL_TREE)
 cp_complete_array_type (TREE_TYPE (init), init, /*do_default=*/0);
-  if (!(flags  PICFLAG_NOT_ALL_CONSTANT))
+  if (flags  PICFLAG_NOT_ALL_CONSTANT)
+/* Make sure TREE_CONSTANT isn't set from build_constructor.  */
+TREE_CONSTANT (init) = false;
+  else
 {
   TREE_CONSTANT (init) = 1;
   if (!(flags  PICFLAG_NOT_ALL_SIMPLE))
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist65.C b/gcc/testsuite/g++.dg/cpp0x/initlist65.C
new file mode 100644
index 000..3612706
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist65.C
@@ -0,0 +1,9 @@
+// Core 1270
+// { dg-options -std=c++11 }
+
+struct A
+{
+  int i[2];
+};
+
+A f() { return {1,2}; }


C++ PATCH for c++/36797 (use of __is_empty in template signature)

2012-03-03 Thread Jason Merrill
Since we've decided not to mangle __is_empty and such, this patch 
provides a more helpful error message.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit bdaa797823a9e45261cfe7a97e4f568decba790b
Author: Jason Merrill ja...@redhat.com
Date:   Thu Jan 12 12:42:07 2012 -0500

	PR c++/36797
	* mangle.c (write_expression): Improve diagnostic for TRAIT_EXPR.

diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 34f19ef..04f4344 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -2808,7 +2808,17 @@ write_expression (tree expr)
 
   if (name == NULL)
 	{
-	  sorry (mangling %C, code);
+	  switch (code)
+	{
+	case TRAIT_EXPR:
+	  error (use of built-in trait %qE in function signature; 
+		 use library traits instead, expr);
+	  break;
+
+	default:
+	  sorry (mangling %C, code);
+	  break;
+	}
 	  return;
 	}
   else
diff --git a/gcc/testsuite/g++.dg/ext/is_empty2.C b/gcc/testsuite/g++.dg/ext/is_empty2.C
new file mode 100644
index 000..d1bf64c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_empty2.C
@@ -0,0 +1,11 @@
+// PR c++/36797
+
+template int struct A { };
+
+template class T
+int foo (A__is_empty (T)* = 0); // { dg-error built-in trait }
+
+int main ()
+{
+fooint();
+}


Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322 and more)

2012-03-03 Thread Jason Merrill
And here's a hunk I held back from that patch to be conservative; 
applying now that we're in stage 1.  It should have no effect, but is 
more consistent with other uses.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit ed1e0f5a5dc43e87cfddbdca9adffd72e8c4719e
Author: Jason Merrill ja...@redhat.com
Date:   Wed Jan 11 14:40:56 2012 -0500

	* mangle.c (write_nested_name): Use decl_mangling_context.
	(write_prefix, write_template_prefix): Likewise.

diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 04f4344..1379e3b 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -942,7 +942,7 @@ write_nested_name (const tree decl)
 	}
   else
 	{
-	  write_prefix (CP_DECL_CONTEXT (decl));
+	  write_prefix (decl_mangling_context (decl));
 	  write_unqualified_name (decl);
 	}
 }
@@ -1030,7 +1030,7 @@ write_prefix (const tree node)
 	}
   else
 	{
-	  write_prefix (CP_DECL_CONTEXT (decl));
+	  write_prefix (decl_mangling_context (decl));
 	  write_unqualified_name (decl);
 	}
 }
@@ -1060,7 +1060,7 @@ write_template_prefix (const tree node)
 {
   tree decl = DECL_P (node) ? node : TYPE_NAME (node);
   tree type = DECL_P (node) ? TREE_TYPE (node) : node;
-  tree context = CP_DECL_CONTEXT (decl);
+  tree context = decl_mangling_context (decl);
   tree template_info;
   tree templ;
   tree substitution;