Re: [Patch, fortran] [0/5] PR 45586: restrict vs. non-restrict type compatibility hell

[Dominique Dhumieres]

> ... In the meantime is it by any chance better if the first patch in the serie
> is replaced by the attached one?

With the new patch for trans-expr.c (keeping those for
trans-types.c and trans.h), typebound_proc_27.f03 -flto -O
now works, but not class_array_7.f03 nor the other tests
I have tried so far.

Dominique

Re: Patches to enable -ftrack-macro-expansion by default

[Dodji Seketeli]

Gabriel Dos Reis  writes:

> I think we show the stack not just for errors, but for any diagnostics.

I agree, FWIW.

-- 
Dodji

Re: random numbers in bulk

[Marc Glisse]

On Sat, 25 Aug 2012, Ulrich Drepper wrote:


On Sat, Aug 25, 2012 at 8:29 PM, Paolo Carlini  wrote:

Understood, but you do *not* loose performance by having those fill functions 
templates,


Let's see.  The prototypes will then be something like this:

 template
   class normal_distribution
   {

 template
void
fill(_OutputIterator __f, _OutputIterator __t,
 _UniformRandomNumberGenerator& __urng,
 const param_type& __p);
   };


The std::generate(_n) function seems closer than std::fill. Not sure if 
overloading that function (std::generate_n) would make sense, it avoids 
changing the interface.



Now I want to define a specialized function which works for a double
iterator and all RNGs.  That's not possible because it means partial
specialization.

Therefore I'd have to add another member function to the class.  If
this is what is wanted I can do this (in fact, I have the code ready).
It just looks worse because the special functions are in some cases
architecture-specific.  This means the code will be littered with
arch-specific code.


If the goal is to avoid listing several overloads in the class, it is 
still possible to dispatch in the (out-of-class) definition of fill. Or is 
the goal to make it extensible, in the sense that a user can still add 
"specializations" (whatever the technical means used, which don't have to 
be what C++ calls specialization)?


--
Marc Glisse

[PATCH, middle-end]: Introduce TARGET_LEGITIMATE_COMBINED_INSN target hook

[Uros Bizjak]

Hello!

Actually a v3 of TARGET_REJECT_COMBINED_INSN target hook.

Changes:
- rename the hook and reverse the return value

2012-08-25  Uros Bizjak  

* target.def (legitimate_combined_insn): New target hook.
* doc/tm.texi.in (TARGET_LEGITIMATE_COMBINED_INSN): New hook.
* doc/tm.texi: Regenerated.
* combine.c (recog_for_combine): Call targetm.legitimate_combined_insn
to allow targets to reject combined insn.
* hooks.h (hook_bool_rtx_true): New.
* hooks.c (hook_bool_rtx_true): Ditto.

Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32},
also with target-dependant x86 patch that implements the hook.

Uros.
Index: target.def
===
--- target.def  (revision 190665)
+++ target.def  (working copy)
@@ -1984,7 +1984,16 @@ DEFHOOK
  const char *, (const_rtx insn),
  default_invalid_within_doloop)
 
+/* Returns true for a legitimate combined insn.  */
 DEFHOOK
+(legitimate_combined_insn,
+"Take an instruction in @var{insn} and return @code{false} if the instruction\
+ is not appropriate as a combination of two or more instructions.  The\
+ default is to accept all instructions.",
+ bool, (rtx insn),
+ hook_bool_rtx_true)
+
+DEFHOOK
 (valid_dllimport_attribute_p,
 "@var{decl} is a variable or function with @code{__attribute__((dllimport))}\
  specified.  Use this hook if the target needs to add extra validation\
Index: hooks.c
===
--- hooks.c (revision 190665)
+++ hooks.c (working copy)
@@ -269,6 +269,12 @@ hook_bool_tree_bool_false (tree a ATTRIBUTE_UNUSED
 }
 
 bool
+hook_bool_rtx_true (rtx a ATTRIBUTE_UNUSED)
+{
+  return true;
+}
+
+bool
 hook_bool_rtx_false (rtx a ATTRIBUTE_UNUSED)
 {
   return false;
Index: hooks.h
===
--- hooks.h (revision 190665)
+++ hooks.h (working copy)
@@ -50,6 +50,7 @@ extern bool hook_bool_const_tree_hwi_hwi_const_tre
  HOST_WIDE_INT,
  HOST_WIDE_INT,
  const_tree);
+extern bool hook_bool_rtx_true (rtx);
 extern bool hook_bool_rtx_false (rtx);
 extern bool hook_bool_rtx_int_false (rtx, int);
 extern bool hook_bool_uintp_uintp_false (unsigned int *, unsigned int *);
Index: doc/tm.texi
===
--- doc/tm.texi (revision 190665)
+++ doc/tm.texi (working copy)
@@ -10938,6 +10938,10 @@ By default, the RTL loop optimizer does not use a
 loops containing function calls or branch on table instructions.
 @end deftypefn
 
+@deftypefn {Target Hook} bool TARGET_LEGITIMATE_COMBINED_INSN (rtx @var{insn})
+Take an instruction in @var{insn} and return @code{false} if the instruction 
is not appropriate as a combination of two or more instructions.  The default 
is to accept all instructions.
+@end deftypefn
+
 @defmac MD_CAN_REDIRECT_BRANCH (@var{branch1}, @var{branch2})
 
 Take a branch insn in @var{branch1} and another in @var{branch2}.
Index: doc/tm.texi.in
===
--- doc/tm.texi.in  (revision 190665)
+++ doc/tm.texi.in  (working copy)
@@ -10796,6 +10796,8 @@ By default, the RTL loop optimizer does not use a
 loops containing function calls or branch on table instructions.
 @end deftypefn
 
+@hook TARGET_LEGITIMATE_COMBINED_INSN
+
 @defmac MD_CAN_REDIRECT_BRANCH (@var{branch1}, @var{branch2})
 
 Take a branch insn in @var{branch1} and another in @var{branch2}.
Index: combine.c
===
--- combine.c   (revision 190665)
+++ combine.c   (working copy)
@@ -10500,11 +10500,13 @@ static int
 recog_for_combine (rtx *pnewpat, rtx insn, rtx *pnotes)
 {
   rtx pat = *pnewpat;
+  rtx pat_without_clobbers;
   int insn_code_number;
   int num_clobbers_to_add = 0;
   int i;
-  rtx notes = 0;
+  rtx notes = NULL_RTX;
   rtx old_notes, old_pat;
+  int old_icode;
 
   /* If PAT is a PARALLEL, check to see if it contains the CLOBBER
  we use to indicate that something didn't match.  If we find such a
@@ -10518,7 +10520,7 @@ recog_for_combine (rtx *pnewpat, rtx insn, rtx *pn
   old_pat = PATTERN (insn);
   old_notes = REG_NOTES (insn);
   PATTERN (insn) = pat;
-  REG_NOTES (insn) = 0;
+  REG_NOTES (insn) = NULL_RTX;
 
   insn_code_number = recog (pat, insn, &num_clobbers_to_add);
   if (dump_file && (dump_flags & TDF_DETAILS))
@@ -10564,6 +10566,9 @@ recog_for_combine (rtx *pnewpat, rtx insn, rtx *pn
  print_rtl_single (dump_file, pat);
}
 }
+
+  pat_without_clobbers = pat;
+
   PATTERN (insn) = old_pat;
   REG_NOTES (insn) = old_notes;
 
@@ -10605,6 +10610,35 @@ recog_for_combine (rtx *pnewpat, rtx insn, rtx *pn
   pat = newpat;
 }
 
+  if (insn_code_number >= 0
+  

Re: [PATCH, middle-end]: Introduce TARGET_LEGITIMATE_COMBINED_INSN target hook

[Georg-Johann Lay]

Uros Bizjak schrieb:

Hello!

Actually a v3 of TARGET_REJECT_COMBINED_INSN target hook.

Changes:
- rename the hook and reverse the return value

2012-08-25  Uros Bizjak  

* target.def (legitimate_combined_insn): New target hook.
* doc/tm.texi.in (TARGET_LEGITIMATE_COMBINED_INSN): New hook.
* doc/tm.texi: Regenerated.
* combine.c (recog_for_combine): Call targetm.legitimate_combined_insn
to allow targets to reject combined insn.
* hooks.h (hook_bool_rtx_true): New.
* hooks.c (hook_bool_rtx_true): Ditto.

Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32},
also with target-dependant x86 patch that implements the hook.

Uros.


Sorry for yet another question.

I had the situation where the decision depends on the values held in the
registers (not for x86) like zeroed bits.

Is that information available at the time the hook is called and could
it be passed down to the backend?

What I mean is information like nonzero_bits
  "what we know about the nonzero bits of a register, specifically
   which bits are known to be zero."

It would be great if the backend was supplied with such informations
if they are readily available.  It's merely impossible for the
backend to reconstruct that knowledge, e.g. if a value is know to
always be 0 or 1.

Thanks for your patience.

Johann

Re: Commit: FRV: Add support for -fstack-usage

[Gerald Pfeifer]

On Tue, 31 Jul 2012, Nick Clifton wrote:
>   I am applying the patch below to add support for the -fstack-usage
>   option to the FRV backend.

I also added the below to our release notes.  Feel free to tweak,
add more, or let me know of changes you'd like to see.

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.17
diff -u -3 -p -r1.17 changes.html
--- changes.html20 Aug 2012 12:23:39 -  1.17
+++ changes.html26 Aug 2012 10:27:18 -
@@ -153,6 +153,13 @@ by this change.
 libraries.  This includes the system libraries and startup modules.
   
 
+FRV
+
+  
+This target now supports the -fstack-usage 
+command-line option.
+  
+
 MIPS
   
 GCC now passes the -mmcu and -mno-mcu

[wwwdocs] Update links to C++ ABI (was: at exit alternative for AIX)

[Gerald Pfeifer]

On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
> The official link at http://codesourcery.com/cxx-abi/ (note trailing
> slash) still works.

It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
and now redirects to http://mentorembedded.github.com/cxx-abi/ .

I went ahead and updated all our references per the patch below.

Jonathan, libstdc++/doc/xml/manual/abi.xml also has three references
to the old address.

Gerald

Index: faq.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v
retrieving revision 1.215
diff -u -3 -p -r1.215 faq.html
--- faq.html20 Feb 2012 22:41:41 -  1.215
+++ faq.html26 Aug 2012 10:37:21 -
@@ -433,7 +433,7 @@ linkage the same name is a violation of 
 
 For more details about the way that GCC implements these and other
 C++ features, please read the http://sourcery.mentor.com/public/cxx-abi/";>C++ ABI specification.
+href="http://mentorembedded.github.com/cxx-abi/";>C++ ABI specification.
 Note the std::type_info objects which must be
 resolved all begin with "_ZTS". Refer to ld's
 documentation for a description of the "-E" &
Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.219
diff -u -3 -p -r1.219 readings.html
--- readings.html   23 Feb 2012 13:24:36 -  1.219
+++ readings.html   26 Aug 2012 10:37:21 -
@@ -37,7 +37,7 @@
   by Joachim Nadler and Tim Josling
   t...@melbpc.org.au>.
 
-  http://sourcery.mentor.com/public/cxx-abi/";>
+  http://mentorembedded.github.com/cxx-abi/";>
   The V3 multi-vendor standard C++ ABI is used in GCC releases 3.0 and
   above.
 
Index: gcc-3.2/c++-abi.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.2/c++-abi.html,v
retrieving revision 1.6
diff -u -3 -p -r1.6 c++-abi.html
--- gcc-3.2/c++-abi.html20 Feb 2012 22:51:27 -  1.6
+++ gcc-3.2/c++-abi.html26 Aug 2012 10:37:21 -
@@ -10,7 +10,7 @@
 The main point of the GCC 3.2 release is to have a relatively
 stable and common C++ ABI for GNU/Linux and BSD usage, following
 the documentation at
-http://sourcery.mentor.com/public/cxx-abi/";>http://sourcery.mentor.com/public/cxx-abi/.
+http://mentorembedded.github.com/cxx-abi/";>http://sourcery.mentor.com/public/cxx-abi/.

 Unfortunately this means that GCC 3.2 is incompatible with GCC 3.0
 and GCC 3.1 releases.
Index: gcc-4.0/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.0/changes.html,v
retrieving revision 1.60
diff -u -3 -p -r1.60 changes.html
--- gcc-4.0/changes.html20 Feb 2012 22:51:27 -  1.60
+++ gcc-4.0/changes.html26 Aug 2012 10:37:22 -
@@ -182,7 +182,7 @@
 -fvisibility option.
 
 The compiler now uses the library interface specified by the http://sourcery.mentor.com/public/cxx-abi/";>C++ ABI for
+href="http://mentorembedded.github.com/cxx-abi/";>C++ ABI for
 thread-safe initialization of function-scope static variables.
 Most users should leave this alone, but embedded programmers may
 want to disable this by specifying

Re: random numbers in bulk

[Ulrich Drepper]

On Sun, Aug 26, 2012 at 4:52 AM, Marc Glisse  wrote:
> The std::generate(_n) function seems closer than std::fill. Not sure if
> overloading that function (std::generate_n) would make sense, it avoids
> changing the interface.

I'm not wedded to fill.  generate_n is fine as well.


> If the goal is to avoid listing several overloads in the class, it is still
> possible to dispatch in the (out-of-class) definition of fill. Or is the
> goal to make it extensible, in the sense that a user can still add
> "specializations" (whatever the technical means used, which don't have to be
> what C++ calls specialization)?

As a first step, for instance, I want to add a function which
optimizes the normal_distribution to use SSE and x86 machines.  This
is only useful if I know the type underlying the iterator.  It will
have to match the generated value of the distribution.  I.e., I want
to define

template<>
template
  void
  normal_distribution::
  fill(double* __f, double* __t,
   _UniformRandomNumberGenerator& __urng, const param_type& __param)
  {
...
  }

As said before, this isn't possible because it's a partially
specialized function.

Defining this as a non-member function isn't practical because each
such function would have to be declared a friend.

What I could imagine working is that the iterator fill/generate_n
functions are defined and in addition the special versions which use
pointers of the result_type of the distribution.  There is only one
such type as specified by the template parameter of the distribution
class.  This makes it possible to specialize it and at the same time
it is trivial to specify a default.  In a standardization effort it'd
be possible to exclusively concentrate on the iterator version.
Implementations could provide the pointer versions as transparent
venues for possible optimizations.

Re: [Patch, fortran] [0/5] PR 45586: restrict vs. non-restrict type compatibility hell

[Dominique Dhumieres]

With the modified patch, gfortran.dg/restrict_type_compat_1.f90 fails
for a regular test:

FAIL: gfortran.dg/restrict_type_compat_1.f90  -O   scan-tree-dump-times 
original "VIEW_CONVERT_EXPR" 13

A manual check shows only 6 instances of VIEW_CONVERT_EXPR.

Cheers,

Dominique

Re: [Patch, fortran] [0/5] PR 45586: restrict vs. non-restrict type compatibility hell

[Mikael Morin]

On 26/08/2012 13:23, Dominique Dhumieres wrote:
> With the modified patch, gfortran.dg/restrict_type_compat_1.f90 fails
> for a regular test:
> 
> FAIL: gfortran.dg/restrict_type_compat_1.f90  -O   scan-tree-dump-times 
> original "VIEW_CONVERT_EXPR" 13
> 
> A manual check shows only 6 instances of VIEW_CONVERT_EXPR.
> 
Yes, this is expected.
It doesn't fix all the failures anyway, so something else is needed.

Mikael

Re: [PATCH] Small change for cloog.m4 configuration file

[Gerald Pfeifer]

On Wed, 22 Aug 2012, Art Haas wrote:
> I've been having to make this small change to the 'configure' script
> when building on sparc-sun-solaris2.10 to accomodate the shell executing
> the script. Without the change, I get an error message like so:
> 
> configure: test: unknown operator ==

Thanks for the report and patch, Art.  I applied this as below and
am copying the authors of the 2012-07-02 patch that added this.

Gerald


2012-08-26  Art Haas 

* cloog.m4 (CLOOG_INIT_FLAGS): Use = instead of == in test.

2012-08-26  Art Haas 

* configure: Regenerate.

Index: config/cloog.m4
===
--- config/cloog.m4 (revision 190683)
+++ config/cloog.m4 (working copy)
@@ -65,7 +65,7 @@
   fi
   dnl If no --with-cloog flag was specified and there is in-tree ClooG
   dnl source, set up flags to use that.
-  if test "x${clooginc}" == x && test "x${clooglibs}" == x \
+  if test "x${clooginc}" = x && test "x${clooglibs}" = x \
  && test -d ${srcdir}/cloog; then
  clooglibs='-L$$r/$(HOST_SUBDIR)/cloog/'"$lt_cv_objdir"' '
  clooginc='-I$$r/$(HOST_SUBDIR)/cloog/include -I$$s/cloog/include 
-I'${srcdir}'/cloog/include '
Index: configure
===
--- configure   (revision 190683)
+++ configure   (working copy)
@@ -5796,7 +5796,7 @@
   if test "x${with_cloog_lib}" != x; then
 clooglibs="-L$with_cloog_lib"
   fi
-  if test "x${clooginc}" == x && test "x${clooglibs}" == x \
+  if test "x${clooginc}" = x && test "x${clooglibs}" = x \
  && test -d ${srcdir}/cloog; then
  clooglibs='-L$$r/$(HOST_SUBDIR)/cloog/'"$lt_cv_objdir"' '
  clooginc='-I$$r/$(HOST_SUBDIR)/cloog/include -I$$s/cloog/include 
-I'${srcdir}'/cloog/include '

Re: [PATCH] Small change for cloog.m4 configuration file

[Tobias Grosser]

On 08/26/2012 02:20 PM, Gerald Pfeifer wrote:

On Wed, 22 Aug 2012, Art Haas wrote:

I've been having to make this small change to the 'configure' script
when building on sparc-sun-solaris2.10 to accomodate the shell executing
the script. Without the change, I get an error message like so:

configure: test: unknown operator ==


Thanks for the report and patch, Art.  I applied this as below and
am copying the authors of the 2012-07-02 patch that added this.


Thanks Art and Gerald for fixing this.

Tobi

Re: [PATCH] Intrinsics for RDSEED

[Gerald Pfeifer]

Hi Kirill,

On Mon, 30 Jul 2012, Kirill Yukhin wrote:
> Checked into the trunk: http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00878.html

are you going to document this (and others) in the GCC 4.8 release
notes at http://gcc.gnu.org/gcc-4.8/changes.html ?  That will be good.

Gerald

Re: PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes

[Paolo Bonzini]

Il 25/08/2012 17:58, H.J. Lu ha scritto:
> The change was introduced by
> 
> http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01452.html
> 
> Paolo, do you remember the reason for this?

Actually, this patch came before bfd started using libtool and hence .libs.

The patch is okay if binutils always uses libtool to link programs that
require libbfd and libopcodes.  Can you check?

Paolo

Re: random numbers in bulk

[Jonathan Wakely]

On 26 August 2012 14:08, Ulrich Drepper wrote:
>
> If people agree this is acceptable and the consensus is that
> generate_n() is the better name I can submit a patch so that the
> remaining  work can be submitted.  Still ways to go...

Unless you're thinking of changing the interface to take a pointer and
an integer then generate_n() is not a good name, maybe generate()
though.

Re: random numbers in bulk

[Jonathan Wakely]

Adding Daniel's correct address (Daniel, the thread started at
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01752.html)

On 26 August 2012 14:38, Jonathan Wakely wrote:
> On 26 August 2012 14:08, Ulrich Drepper wrote:
>>
>> If people agree this is acceptable and the consensus is that
>> generate_n() is the better name I can submit a patch so that the
>> remaining  work can be submitted.  Still ways to go...
>
> Unless you're thinking of changing the interface to take a pointer and
> an integer then generate_n() is not a good name, maybe generate()
> though.

Re: PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes

[H.J. Lu]

On Sun, Aug 26, 2012 at 6:22 AM, Paolo Bonzini  wrote:
> Il 25/08/2012 17:58, H.J. Lu ha scritto:
>> The change was introduced by
>>
>> http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01452.html
>>
>> Paolo, do you remember the reason for this?
>
> Actually, this patch came before bfd started using libtool and hence .libs.
>
> The patch is okay if binutils always uses libtool to link programs that
> require libbfd and libopcodes.  Can you check?
>

Yes, binutils always uses libtool. GDB doesn't use libtool. But it is linked
against libbfd.a and libopcodes.a when configured with --enable-shared.
I am checking it in.

-- 
H.J.

Re: [PATCH 2/2] mips: Add R4700 scheduling support

[Gerald Pfeifer]

On Sun, 3 Jun 2012, Richard Sandiford wrote:
>> The R4700 is identical to the R4600 except for the integer and
>> floating-point multiplication costs.
> Applied, thanks.
> 
> Richard

And I just added the snippet below to our release notes.

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.20
diff -u -3 -p -r1.20 changes.html
--- changes.html26 Aug 2012 10:28:42 -  1.20
+++ changes.html26 Aug 2012 13:54:36 -
@@ -214,6 +214,7 @@ by this change.
   
 GCC now passes the -mmcu and -mno-mcu
 options to the assembler.
+Support for the R4700 has been added.
   
 
 SH

Re: [v3] fix PR 54297 - segfaults with std::async

[Jonathan Wakely]

On 26 August 2012 00:02, Jonathan Wakely wrote:
> This fixes a stupid mistake I made where the functor and asynchronous
> result can go out of scope before the async thread is joined.
>
> The _Async_state_common destructor still needs to be exported from the
> library, which is what the macro hack is for.
>
> PR libstdc++/54297
> * include/std/future (~_Async_state_impl): Join thread before
> derived class members are destroyed.
> (~_Async_state_common): Only define non-trivial destructor when
> included from future.cc for ABI compatibility reasons.
> * src/c++11/future.cc (_GLIBCXX_ABI_COMPAT_ASYNC): Define.
> * testsuite/30_threads/async/54297.cc: New.
>
> Tested x86_64-linux, committed to trunk and 4.7

I realised the compatibility symbols should be in one of the files
used for that purpose, so this moves them to
src/c++11/compatibility-thread-c++0x.cc

PR libstdc++/54297
* src/c++11/future.cc (~_Async_state_common): Move to...
* src/c++11/compatibility-thread-c++0x.cc (~_Async_state_common):
Here.
(_GLIBCXX_ABI_COMPAT_ASYNC): Rename to _GLIBCXX_ASYNC_ABI_COMPAT.
* include/std/future (_GLIBCXX_ABI_COMPAT_ASYNC): Likewise.

Tested x86_64-linux, committed to trunk and 4.7
commit 463ac67acbdada5a558dcad097e030a7479086c5
Author: Jonathan Wakely 
Date:   Sun Aug 26 11:42:00 2012 +0100

PR libstdc++/54297
* src/c++11/future.cc (~_Async_state_common): Move to...
* src/c++11/compatibility-thread-c++0x.cc (~_Async_state_common):
Here.
(_GLIBCXX_ABI_COMPAT_ASYNC): Rename to _GLIBCXX_ASYNC_ABI_COMPAT.
* include/std/future (_GLIBCXX_ABI_COMPAT_ASYNC): Likewise.

diff --git a/libstdc++-v3/include/std/future b/libstdc++-v3/include/std/future
index feae382..9568192 100644
--- a/libstdc++-v3/include/std/future
+++ b/libstdc++-v3/include/std/future
@@ -1427,7 +1427,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   class __future_base::_Async_state_common : public __future_base::_State_base
   {
   protected:
-#if defined(_GLIBCXX_HAVE_TLS) && defined(_GLIBCXX_ABI_COMPAT_ASYNC)
+#ifdef _GLIBCXX_ASYNC_ABI_COMPAT
 ~_Async_state_common();
 #else
 ~_Async_state_common() = default;
diff --git a/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc 
b/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
index cc8761e..e5c7eec 100644
--- a/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
+++ b/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
@@ -22,11 +22,16 @@
 // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 // .
 
+#include 
+#if defined(_GLIBCXX_HAVE_TLS) && defined(PIC)
+#define _GLIBCXX_ASYNC_ABI_COMPAT
+#endif
+
 #include 
 #include 
 
 #ifndef __GXX_EXPERIMENTAL_CXX0X__
-# error "compatibility-c++0x.cc must be compiled with -std=gnu++0x"
+# error "compatibility-thread-c++0x.cc must be compiled with -std=gnu++0x"
 #endif
 
 #define _GLIBCXX_ASM_SYMVER(cur, old, version) \
@@ -70,3 +75,23 @@ _GLIBCXX_ASM_SYMVER(_ZN9__gnu_cxx11try_to_lockE, 
_ZSt11try_to_lock, GLIBCXX_3.4.
 
 #endif
 #endif // _GLIBCXX_HAS_GTHREADS && _GLIBCXX_USE_C99_STDINT_TR1
+
+
+// XXX GLIBCXX_ABI Deprecated
+// gcc-4.7.0
+//  export changes
+#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) \
+  && (ATOMIC_INT_LOCK_FREE > 1)
+#if defined(_GLIBCXX_HAVE_TLS) && defined(PIC)
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+  __future_base::_Async_state_common::~_Async_state_common() { _M_join(); }
+
+  // Explicit instantiation due to -fno-implicit-instantiation.
+  template void call_once(once_flag&, void (thread::*&&)(), 
reference_wrapper&&);
+  template _Bind_simple_helper>::__type __bind_simple(void (thread::*&&)(), 
reference_wrapper&&);
+_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace std
+#endif
+#endif // _GLIBCXX_HAS_GTHREADS && _GLIBCXX_USE_C99_STDINT_TR1
diff --git a/libstdc++-v3/src/c++11/future.cc b/libstdc++-v3/src/c++11/future.cc
index eaea393..0552537 100644
--- a/libstdc++-v3/src/c++11/future.cc
+++ b/libstdc++-v3/src/c++11/future.cc
@@ -22,8 +22,6 @@
 // see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 // .
 
-#define _GLIBCXX_ABI_COMPAT_ASYNC
-
 #include 
 
 namespace
@@ -86,15 +84,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __future_base::_Result_base::~_Result_base() = default;
 
   __future_base::_State_base::~_State_base() = default;
-
-#ifdef _GLIBCXX_HAVE_TLS
-  // Exported for compatibility with ABI version 3.4.17
-  __future_base::_Async_state_common::~_Async_state_common() { _M_join(); }
-
-  // Explicit instantiation due to -fno-implicit-instantiation.
-  template void call_once(once_flag&, void (thread::*&&)(), 
reference_wrapper&&);
-  template _Bind_simple_helper>::__type __bind_simple(void (thread::*&&)(), 
reference_wrapper&&);
-#endif
 #endif
 
 _GLIBCXX_END_NAMESPACE_VERSION

Re: random numbers in bulk

[Daniel Krügler]

2012/8/26 Ulrich Drepper :
> On Sun, Aug 26, 2012 at 7:20 AM, Ulrich Drepper  wrote:
>> What I could imagine working is that the iterator fill/generate_n
>> functions are defined and in addition the special versions which use
>> pointers of the result_type of the distribution.
>
> How about the following?  This version adds one more version of the
> fill() function which takes result_type pointers.  All these functions
> have a default definition which simply falls back to the iterator
> version.  Specializations can overload the new variant of the function
> and it all works without modifying anything in the class definition.

The signature using _OutputIterator need to be changed to
_ForwardIterator, because output iterator has no equality
comparison (as has already been remarked by someone else before).

The function really should have a different name, as mentioned by
others. I also agree with others that generate would be a better name
than fill.

The typedef "pointer" should be removed, because it is not used at all.

> As far as possible specification is concerned, only the iterator
> versions would have to be specified.  The new interface is a
> transparently added implementation detail.
>
> If people agree this is acceptable and the consensus is that
> generate_n() is the better name I can submit a patch so that the
> remaining  work can be submitted.  Still ways to go...

Personally I consider it as very unfortunate that an overload for pointers
should be necessary here. To solve the specialization problem I'm in
favour to provide free function templates instead (I also think that they
should better get an initially underscored name like _generate).

To solve the access problem I would suggest to isolate the
minimum needed access and to provide public available functions
with underscored names. This would allow to provide overloads instead
that are based on some constrained API.

Just an idea,

- Daniel

Re: random numbers in bulk

[Paolo Carlini]

Hi,

On 08/26/2012 04:04 PM, Daniel Krügler wrote:
Personally I consider it as very unfortunate that an overload for 
pointers should be necessary here. To solve the specialization problem 
I'm in favour to provide free function templates instead (I also think 
that they should better get an initially underscored name like _generate).
Minor nit: I don't have a strong opinion about this specific issue, but, 
as a matter of GCC policy, double underscore, in case.


Paolo.

Re: random numbers in bulk

[Paolo Carlini]

On 08/26/2012 04:04 PM, Daniel Krügler wrote:
The function really should have a different name, as mentioned by 
others. I also agree with others that generate would be a better name 
than fill.

Thus, all in all, for the time being I would go with __generate.

Paolo.

[PATCH] fix for PR53986 - missing vrp on bit-mask test, LSHIFT_EXPR not handled

[Tom de Vries]

Richard,

this patch fixes PR53986.

The patch calculates the range of an LSHIFT_EXPR in case both operands are
constants ranges, and the operation is guaranteed not to overflow.

F.i., it evaluates [1, 2] << [1, 8] to [2, 512].

Bootstrapped and reg-tested (ada inclusive) on x86_64.

Ok for trunk?

Thanks,
- Tom

2012-08-25  Tom de Vries  

PR tree-optimization/53986
* tree-vrp.c (extract_range_from_multiplicative_op_1): Allow
LSHIFT_EXPR.
(extract_range_from_binary_expr_1): Handle LSHIFT with constant range as
shift amount.

* gcc.dg/tree-ssa/vrp80.c: New test.
* gcc.dg/tree-ssa/vrp80-2.c: Same.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 190553)
+++ gcc/tree-vrp.c (working copy)
@@ -2068,7 +2068,8 @@ extract_range_from_multiplicative_op_1 (
 	  || code == CEIL_DIV_EXPR
 	  || code == EXACT_DIV_EXPR
 	  || code == ROUND_DIV_EXPR
-	  || code == RSHIFT_EXPR);
+	  || code == RSHIFT_EXPR
+	  || code == LSHIFT_EXPR);
   gcc_assert ((vr0->type == VR_RANGE
 	   || (code == MULT_EXPR && vr0->type == VR_ANTI_RANGE))
 	  && vr0->type == vr1->type);
@@ -2767,6 +2768,27 @@ extract_range_from_binary_expr_1 (value_
 	  flag_wrapv = saved_flag_wrapv;
 	  return;
 	}
+	  else if (code == LSHIFT_EXPR
+		   && range_int_cst_p (&vr0))
+	{
+	  int overflow_pos = TYPE_PRECISION (expr_type);
+	  int bound_shift;
+	  double_int bound;
+
+	  if (!TYPE_UNSIGNED (expr_type))
+		overflow_pos -= 1;
+
+	  bound_shift = overflow_pos - TREE_INT_CST_LOW (vr1.max);
+	  bound = double_int_one.llshift (bound_shift,
+	  TYPE_PRECISION (expr_type));
+	  if (tree_to_double_int (vr0.max).ult (bound))
+		{
+		  /* In the absense of overflow, (a << b) is equivalent
+		 to (a * 2^b).  */
+		  extract_range_from_multiplicative_op_1 (vr, code, &vr0, &vr1);
+		  return;
+		}
+	}
 	}
   set_value_range_to_varying (vr);
   return;
Index: gcc/testsuite/gcc.dg/tree-ssa/vrp80.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp80.c (revision 0)
@@ -0,0 +1,33 @@
+/* { dg-do link } */
+/* { dg-options "-O2 -fno-tree-switch-conversion" } */
+
+extern void link_error (void);
+
+/* Test <<.  */
+
+void
+f3 (int s, int b)
+{
+  if (s >> 3 == -2)
+/* s in range [-16, -9].  */
+{
+  s += 17;
+  /* s in range [1, 8].  */
+  b = (b & 1) + 1;
+  /* b in range [1, 2].  */
+  b =  b << s;
+  /* b in range [bmin << smin, bmax << smax],
+== [1 << 1, 2 << 8]
+== [2, 512].  */
+  if (b == 1 || b == 513)
+	link_error ();
+}
+}
+
+int
+main ()
+{
+  return 0;
+}
+
+
Index: gcc/testsuite/gcc.dg/tree-ssa/vrp80-2.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp80-2.c (revision 0)
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-switch-conversion -fdump-tree-vrp1" } */
+
+extern void vrp_keep (void);
+
+/* Test <<.  */
+
+void
+f3 (int s, int b)
+{
+  if (s >> 3 == -2)
+/* s in range [-16, -9].  */
+{
+  s += 17;
+  /* s in range [1, 8].  */
+  b = (b & 1) + 1;
+  /* b in range [1, 2].  */
+  b =  b << s;
+  /* b in range [bmin << smin, bmax << smax],
+== [1 << 1, 2 << 8]
+== [2, 512].  */
+  if (b == 2)
+	vrp_keep ();
+  if (b == 512)
+	vrp_keep ();
+}
+}
+
+int
+main ()
+{
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "vrp_keep \\(" 2 "vrp1"} } */
+/* { dg-final { cleanup-tree-dump "vrp1" } } */
+
+

[RFA:] fix configury version checks for in-tree binutils

[Hans-Peter Nilsson]

Found while investigating PR54373.  A combined tree (in-tree binutils)
using binutils post-2.22 is semi-broken at the moment: the version of
the assembler and linker can't be found.  The configury doesn't expect
the single-quote that has "appeared"; i.e.

 VERSION=2.22.0
vs.
 VERSION='2.23.51'

You see this in the build log as lots of:

checking assembler flags...
checking assembler for .balign and .p2align... /x/combined/gcc/configure: line 
21848: test: -ge: unary operator expected
no
checking assembler for .p2align with maximum skip... /x/combined/gcc/configure: 
line 21884: test: -ge: unary operator expected
no

obviously causing all optional features in the assembler and linker to
be turned off.  (This could have been the cause of not seeing PR54373
in a combined tree, but that's actually due to a combination of two
other bugs.)

Here's a patch to fix in-tree binutils and to sanity-check that the
version is extracted to avoid semi-silent failures like the above.  An
alternative would be to scrap the special-case and just go with
out-of-tree feature tests; it seems few enough people use it, that this
has gone undetected for a while.  I don't know how important this is
to canadian-cross support though (where you can't run the assembler
and linker to test features).

I tested this by building a combined tree for mmix-knuth-mmixware with
top-of-tree binutils as well as binutils-2.22 from CVS (see quotes
above) past the point of failure.  I also built gcc with out-of-tree
binutils past the point-of-failure, as well as versions of the patch
in-tree and out-tree with just the error check, to verify that it
works (is not executed, for out-of-tree binutils).

I don't need to tell build maintainers how much of a problem it is
matching a single-quote character portably; I just went for any
non-numeric/identifier character.  I also don't need to tell build
maintainers that "?" and "+" are unportables in sed regexps.  The
changequote calls in the ld version check in configure.ac, are
necessary to avoid autoconf terminating with a too-deep-recursion
message for the AC_MSG_ERROR call, which can't be helped by quoting
the message (duh).  Can be alternatively fixed by re/moving the
other/outer pair of changequotes visible in the context of this patch
and to add corresponding [] where needed.  Too much fun for me.

N.B. combining CVS binutils-2.20 in-tree is broken due to mismatching
libtool versions.  I did not test CVS binutils-2.21.

Ok to commit?  I'd suggest applying this to 4.7 as well.
Ok there after test?

gcc:

* acinclude.m4 (_gcc_COMPUTE_GAS_VERSION): Allow a single
character to quote the VERSION= contents.  Sanity-check contents.
* configure.ac ("what linker to use" ld version extraction): Ditto.
* configure: Regenerate.

Index: gcc/acinclude.m4
===
--- gcc/acinclude.m4(revision 190682)
+++ gcc/acinclude.m4(working copy)
@@ -393,11 +393,15 @@ for f in $gcc_cv_as_bfd_srcdir/configure
  $gcc_cv_as_gas_srcdir/configure \
  $gcc_cv_as_gas_srcdir/configure.in \
  $gcc_cv_as_gas_srcdir/Makefile.in ; do
-  gcc_cv_gas_version=`sed -n -e 's/^[[ 
]]*\(VERSION=[[0-9]]*\.[[0-9]]*.*\)/\1/p' < $f`
+  gcc_cv_gas_version=`sed -n -e 's/^[[ 
]]*VERSION=[[^0-9A-Za-z_]]*\([[0-9]]*\.[[0-9]]*.*\)/VERSION=\1/p' < $f`
   if test x$gcc_cv_gas_version != x; then
 break
   fi
 done
+case $gcc_cv_gas_version in
+  VERSION=[[0-9]]*) ;;
+  *) AC_MSG_ERROR([[cannot find version of in-tree assembler]]);;
+esac
 gcc_cv_gas_major_version=`expr "$gcc_cv_gas_version" : "VERSION=\([[0-9]]*\)"`
 gcc_cv_gas_minor_version=`expr "$gcc_cv_gas_version" : 
"VERSION=[[0-9]]*\.\([[0-9]]*\)"`
 gcc_cv_gas_patch_version=`expr "$gcc_cv_gas_version" : 
"VERSION=[[0-9]]*\.[[0-9]]*\.\([[0-9]]*\)"`
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 190682)
+++ gcc/configure.ac(working copy)
@@ -2030,11 +2030,17 @@ if test "$gcc_cv_ld" = ../ld/ld-new$buil
for f in $gcc_cv_ld_bfd_srcdir/configure 
$gcc_cv_ld_gld_srcdir/configure $gcc_cv_ld_gld_srcdir/configure.in 
$gcc_cv_ld_gld_srcdir/Makefile.in
do
 changequote(,)dnl
-   gcc_cv_gld_version=`sed -n -e 's/^[ 
]*\(VERSION=[0-9]*\.[0-9]*.*\)/\1/p' < $f`
+   gcc_cv_gld_version=`sed -n -e 's/^[ 
]*VERSION=[^0-9A-Za-z_]*\([0-9]*\.[0-9]*.*\)/VERSION=\1/p' < $f`
if test x$gcc_cv_gld_version != x; then
break
fi
done
+   case $gcc_cv_gld_version in
+ VERSION=[0-9]*) ;;
+changequote([,])dnl
+ *) AC_MSG_ERROR([[cannot find version of in-tree linker]]) ;;
+changequote(,)dnl
+   esac
gcc_cv_gld_major_version=`expr "$gcc_cv_gld_version" : 
"VERSION=\([0-9]*\)"`
gcc_cv_gld_minor_version=`expr "$gcc_cv_gld_version" : 
"VERSION=[0-9]*\.\([0-9]*\)"`
 changeq

Re: [v3] fix PR 54297 - segfaults with std::async

[H.J. Lu]

On Sun, Aug 26, 2012 at 7:00 AM, Jonathan Wakely  wrote:
> On 26 August 2012 00:02, Jonathan Wakely wrote:
>> This fixes a stupid mistake I made where the functor and asynchronous
>> result can go out of scope before the async thread is joined.
>>
>> The _Async_state_common destructor still needs to be exported from the
>> library, which is what the macro hack is for.
>>
>> PR libstdc++/54297
>> * include/std/future (~_Async_state_impl): Join thread before
>> derived class members are destroyed.
>> (~_Async_state_common): Only define non-trivial destructor when
>> included from future.cc for ABI compatibility reasons.
>> * src/c++11/future.cc (_GLIBCXX_ABI_COMPAT_ASYNC): Define.
>> * testsuite/30_threads/async/54297.cc: New.
>>
>> Tested x86_64-linux, committed to trunk and 4.7
>
> I realised the compatibility symbols should be in one of the files
> used for that purpose, so this moves them to
> src/c++11/compatibility-thread-c++0x.cc
>
> PR libstdc++/54297
> * src/c++11/future.cc (~_Async_state_common): Move to...
> * src/c++11/compatibility-thread-c++0x.cc (~_Async_state_common):
> Here.
> (_GLIBCXX_ABI_COMPAT_ASYNC): Rename to _GLIBCXX_ASYNC_ABI_COMPAT.
> * include/std/future (_GLIBCXX_ABI_COMPAT_ASYNC): Likewise.
>
> Tested x86_64-linux, committed to trunk and 4.7

Does it fix:

output is:
/export/gnu/import/git/gcc/libstdc++-v3/testsuite/30_threads/async/54297.cc:
In member function 'void Task::operator()() const':^M
/export/gnu/import/git/gcc/libstdc++-v3/testsuite/30_threads/async/54297.cc:42:5:
error: 'sleep_for' is not a member of 'std::this_thread'^M
 std::this_thread::sleep_for(std::chrono::seconds(1));^M
 ^^M

FAIL: 30_threads/async/54297.cc (test for excess errors)
Excess errors:
/export/gnu/import/git/gcc/libstdc++-v3/testsuite/30_threads/async/54297.cc:42:5:
error: 'sleep_for' is not a member of 'std::this_thread'


-- 
H.J.

Re: [v3] fix PR 54297 - segfaults with std::async

[Jonathan Wakely]

On 26 August 2012 15:48, H.J. Lu  wrote:
> On Sun, Aug 26, 2012 at 7:00 AM, Jonathan Wakely  
> wrote:
>> On 26 August 2012 00:02, Jonathan Wakely wrote:
>>> This fixes a stupid mistake I made where the functor and asynchronous
>>> result can go out of scope before the async thread is joined.
>>>
>>> The _Async_state_common destructor still needs to be exported from the
>>> library, which is what the macro hack is for.
>>>
>>> PR libstdc++/54297
>>> * include/std/future (~_Async_state_impl): Join thread before
>>> derived class members are destroyed.
>>> (~_Async_state_common): Only define non-trivial destructor when
>>> included from future.cc for ABI compatibility reasons.
>>> * src/c++11/future.cc (_GLIBCXX_ABI_COMPAT_ASYNC): Define.
>>> * testsuite/30_threads/async/54297.cc: New.
>>>
>>> Tested x86_64-linux, committed to trunk and 4.7
>>
>> I realised the compatibility symbols should be in one of the files
>> used for that purpose, so this moves them to
>> src/c++11/compatibility-thread-c++0x.cc
>>
>> PR libstdc++/54297
>> * src/c++11/future.cc (~_Async_state_common): Move to...
>> * src/c++11/compatibility-thread-c++0x.cc (~_Async_state_common):
>> Here.
>> (_GLIBCXX_ABI_COMPAT_ASYNC): Rename to _GLIBCXX_ASYNC_ABI_COMPAT.
>> * include/std/future (_GLIBCXX_ABI_COMPAT_ASYNC): Likewise.
>>
>> Tested x86_64-linux, committed to trunk and 4.7
>
> Does it fix:

No, that needs an extra dg-requires-xxx in the test, sorry about that.

I'll fix it now.


> output is:
> /export/gnu/import/git/gcc/libstdc++-v3/testsuite/30_threads/async/54297.cc:
> In member function 'void Task::operator()() const':^M
> /export/gnu/import/git/gcc/libstdc++-v3/testsuite/30_threads/async/54297.cc:42:5:
> error: 'sleep_for' is not a member of 'std::this_thread'^M
>  std::this_thread::sleep_for(std::chrono::seconds(1));^M
>  ^^M
>
> FAIL: 30_threads/async/54297.cc (test for excess errors)
> Excess errors:
> /export/gnu/import/git/gcc/libstdc++-v3/testsuite/30_threads/async/54297.cc:42:5:
> error: 'sleep_for' is not a member of 'std::this_thread'
>
>
> --
> H.J.

Re: random numbers in bulk

[Daniel Krügler]

2012/8/26 Paolo Carlini :
> On 08/26/2012 04:04 PM, Daniel Krügler wrote:
>>
>> The function really should have a different name, as mentioned by others.
>> I also agree with others that generate would be a better name than fill.
>
> Thus, all in all, for the time being I would go with __generate.

Yes, sure.

- Daniel

Re: [v3] fix PR 54297 - segfaults with std::async

[Jonathan Wakely]

   * testsuite/30_threads/async/54297.cc: Add dg-require-nanosleep.

Fixed on trunk and 4.7 branch.


--- a/libstdc++-v3/testsuite/30_threads/async/54297.cc
+++ b/libstdc++-v3/testsuite/30_threads/async/54297.cc
@@ -5,6 +5,7 @@
 // { dg-require-cstdint "" }
 // { dg-require-gthreads "" }
 // { dg-require-atomic-builtins "" }
+// { dg-require-nanosleep "" }

 // Copyright (C) 2012 Free Software Foundation, Inc.
 //

Re: random numbers in bulk

[Ulrich Drepper]

On Sun, Aug 26, 2012 at 10:04 AM, Daniel Krügler
 wrote:
> The typedef "pointer" should be removed, because it is not used at all.

That 'pointer' type is needed for the __normal_iterator use.  Unfortunately.

Re: [PATCH] OpenBSD/amd64 support and OpenBSD/i386 cleanup

[Gerald Pfeifer]

On Sun, 1 Jan 2012, Mark Kettenis wrote:
> The diff below adds support for OpenBSD/amd64 and cleans up the
> OpenBSD/i386 configury bits such that they can be shared.  The OpenBSD
> ports people have maintained their own set of patches for these
> targets, but this is a re-implementation from scratch to prevent
> copyright issues.  I have a copyright assignment in place for GCC.

I did not see any response to this patch by Mark.  In my experience
it really is preferrable if we can keep such things upstream on our
side (GCC) as opposed to OpenBSD or other distributions carrying their
own.

If anyone wants to approve this, I volunteer to commit the patch.

Gerald


libgcc/:

2011-12-27  Mark Kettenis  

* config.host (x86_64-*-openbsd*): New target.

gcc/:

2011-12-27  Mark Kettenis  

* config.gcc (x86_64-*-openbsd*): New target.
* config/openbsd.h (TARGET_C99_FUNCTIONS): Define.
* config/i386/openbsdelf.h: Remove some superfluous defines and
group things together in a more logical fashion.
(DBX_REGISTER_NUMBER): Provide a
definition that works on both 32-bit and 64-bit targets.
(WCHAR_TYPE_SIZE): Hardcode as 32.
(NO_DOLLAR_IN_LABEL): Remove undef.
(TARGET_DEFAULT): Remove.
(SET_ASM_OP): Remove.
(DEFAULT_PCC_STRUCT_RETURN): Undef first to prevent warning.
(ASM_OUTPUT_MAX_SKIP_ALIGN): Synch with x86-64.h
(DWARF2_UNWIND_INFO): Remove define.
(HAVE_ENABLE_EXECUTE_STACK): Define.
* config/host-openbsd.c: New file.
* config/t-openbsd (USER_H): Add EXTRA_HEADERS.
* config/x-openbsd: New file.


Index: libgcc/config.host
===
--- libgcc/config.host  (revision 182693)
+++ libgcc/config.host  (working copy)
@@ -532,6 +532,8 @@
;;
 i[34567]86-*-openbsd*)
;;
+x86_64-*-openbsd*)
+   ;;
 i[34567]86-*-linux*)
extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o 
crtfastmath.o"
tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff 
t-dfprules"
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 182693)
+++ gcc/config.gcc  (working copy)
@@ -1201,6 +1201,13 @@
gas=yes
gnu_ld=yes
;;
+x86_64-*-openbsd*)
+   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h"
+   tm_file="${tm_file} openbsd.h openbsd-stdint.h openbsd-libpthread.h 
i386/x86-64.h i386/openbsdelf.h"
+   extra_options="${extra_options} openbsd.opt"
+   gas=yes
+   gnu_ld=yes
+   ;;
 i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | 
i[34567]86-*-gnu* | i[34567]86-*-kopensolaris*-gnu)
# Intel 80386's running GNU/*
# with ELF format using glibc 2
Index: gcc/config.host
===
--- gcc/config.host (revision 182693)
+++ gcc/config.host (working copy)
@@ -296,6 +296,10 @@
 out_host_hook_obj=host-linux.o
 host_xmake_file="${host_xmake_file} x-linux"
 ;;
+  *-*-openbsd*)
+out_host_hook_obj=host-openbsd.o
+host_xmake_file="${host_xmake_file} x-openbsd"
+;;
   ia64-*-hpux*)
 use_long_long_for_widest_fast_int=yes
 out_host_hook_obj=host-hpux.o
Index: gcc/config/host-openbsd.c
===
--- gcc/config/host-openbsd.c   (revision 0)
+++ gcc/config/host-openbsd.c   (revision 0)
@@ -0,0 +1,83 @@
+/* OpenBSD host-specific hook definitions.
+   Copyright (C) 2004, 2007, 2008, 2010, 2011 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "hosthooks.h"
+#include "hosthooks-def.h"
+
+
+#undef HOST_HOOKS_GT_PCH_GET_ADDRESS
+#define HOST_HOOKS_GT_PCH_GET_ADDRESS openbsd_gt_pch_get_address
+#undef HOST_HOOKS_GT_PCH_USE_ADDRESS
+#define HOST_HOOKS_GT_PCH_USE_ADDRESS openbsd_gt_pch_use_address
+
+/* For various ports, try to guess a fixed spot in the vm space
+   that's probably free.  */
+#if defined(__amd64__)
+# define TRY_EMPTY_VM_SPACE0x4000
+#elif defined(__i386__)
+# define TRY_EMPTY_VM_SPACE0xb000
+#else
+# define TRY_

Is libstdcxx-time still experimental?

[H.J. Lu]

Hi,

According to

http://gcc.gnu.org/ml/libstdc++/2010-04/msg00064.html

One reason of --enable-libstdcxx-time=no on Linux is
"not all users will want for an experimental c++0x mode."
Is this feature still  experimental today?

Thanks.

-- 
H.J.

[doc] Add missing space in invoke.texi

[Gerald Pfeifer]

Applied to mainline; probably not worth it on release branches.

Gerald

2012-08-26  Gerald Pfeifer  

* doc/invoke.texi (C++ Dialect Options): Add missing space.

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 190691)
+++ doc/invoke.texi (working copy)
@@ -2313,7 +2313,7 @@
 
 @noindent
 In this case, G++ places @code{B::f2} into the same byte
-as@code{A::f1}; other compilers do not.  You can avoid this problem
+as @code{A::f1}; other compilers do not.  You can avoid this problem
 by explicitly padding @code{A} so that its size is a multiple of the
 byte size on your platform; that causes G++ and other compilers to
 lay out @code{B} identically.

Re: [wwwdocs] Update links to C++ ABI (was: at exit alternative for AIX)

[Ian Lance Taylor]

On Sun, Aug 26, 2012 at 3:43 AM, Gerald Pfeifer  wrote:
> On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
>> The official link at http://codesourcery.com/cxx-abi/ (note trailing
>> slash) still works.
>
> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
> and now redirects to http://mentorembedded.github.com/cxx-abi/ .
>
> I went ahead and updated all our references per the patch below.

I don't think that is wise.  The document itself promises that the
permanent URL is http://codesourcery.com/cxx-abi/ .  No other URL is
promised to be permanent.  I think we should link to the permanent URL
as long as it continues to work.

Ian

Re: [wwwdocs] Update links to C++ ABI

[Gerald Pfeifer]

On Sun, 26 Aug 2012, Ian Lance Taylor wrote:
>> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
>> and now redirects to http://mentorembedded.github.com/cxx-abi/ .
>>
>> I went ahead and updated all our references per the patch below.
> I don't think that is wise.  The document itself promises that the
> permanent URL is http://codesourcery.com/cxx-abi/ .  No other URL is
> promised to be permanent.  I think we should link to the permanent URL
> as long as it continues to work.

Well, the document itself also carries "Revised 20 March 2001" in
line 2. ;-)

Mark, any recommendation from your side?  Is it fine to refer to 
the new mentorembedded.github.com address?

(Linking to a page that redirects makes verifying the accuracy of
links tricky.)

Gerald

Re: Is libstdcxx-time still experimental?

[Jonathan Wakely]

On Aug 26, 2012 4:17 PM, "H.J. Lu" wrote:
>
> Hi,
>
> According to
>
> http://gcc.gnu.org/ml/libstdc++/2010-04/msg00064.html
>
> One reason of --enable-libstdcxx-time=no on Linux is
> "not all users will want for an experimental c++0x mode."
> Is this feature still  experimental today?

See http://gcc.gnu.org/ml/libstdc++/2012-05/msg00085.html

I'm working on a patch to enable it by default and to define
this_thread::sleep_xxx and this_thread::yield unconditionally.

--enable-libstdcxx-time=rt is still needed for a high-resolution
std::system_clock and that causes unacceptable performance overhead in
single-threaded code, because clock_gettime needs librt which depends
on libpthread which causes libstdc++'s reference-counting to use
atomic operations.

Re: Is libstdcxx-time still experimental?

[Jonathan Wakely]

On 26 August 2012 18:06, Jonathan Wakely wrote:
> On Aug 26, 2012 4:17 PM, "H.J. Lu" wrote:
>>
>> Hi,
>>
>> According to
>>
>> http://gcc.gnu.org/ml/libstdc++/2010-04/msg00064.html
>>
>> One reason of --enable-libstdcxx-time=no on Linux is
>> "not all users will want for an experimental c++0x mode."
>> Is this feature still  experimental today?
>
> See http://gcc.gnu.org/ml/libstdc++/2012-05/msg00085.html
>
> I'm working on a patch to enable it by default and to define
> this_thread::sleep_xxx and this_thread::yield unconditionally.

For anyone interested, here's a work-in-progress patch that enables
this_thread::sleep_for() and this_thread::yield() unconditionally, so
those APIs are complete even if --enable-libstdcxx-time isn't used.
commit 5fb51138670365f69942c42da7b0ec24a1e752d2
Author: Jonathan Wakely 
Date:   Thu Aug 9 20:16:13 2012 +0100

* acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Check for usleep and
sleep if nanosleep is not available. Bump libtool revision.
* config.h.in: Regenerate.
* configure: Likewise.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.18): Add __sleep_for.
* include/std/thread (this_thread::__sleep_for): Add.
(this_thread::yield,this_thread::sleep_until, this_thread::sleep_for):
Declare unconditionally.
* src/c++11/thread.cc (this_thread::__sleep_for): Define.
* testsuite/lib/libstdc++.exp (check_v3_target_nanosleep): Rename to
check_v3_target_sleep.
* testsuite/lib/dg-options.exp (dg-require-nanosleep): Rename to
dg-require-sleep.
* testsuite/30_threads/condition_variable_any/53830.cc: Update.
* testsuite/30_threads/this_thread/2.cc: Likewise.
* testsuite/30_threads/this_thread/3.cc: Likewise.
* testsuite/30_threads/this_thread/4.cc: Likewise.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 1179407..b9f8ed5 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -1246,6 +1246,20 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
   if test x"$ac_has_nanosleep" = x"yes"; then
 AC_DEFINE(_GLIBCXX_USE_NANOSLEEP, 1,
   [ Defined if nanosleep is available. ])
+  else
+  AC_MSG_CHECKING([for sleep])
+  AC_TRY_COMPILE([#include ],
+ [sleep(1)],
+ [AC_DEFINE(HAVE_SLEEP,1,
+  [Defined if sleep exists.])],[])
+  AC_MSG_RESULT($ac_has_sleep)
+  AC_MSG_CHECKING([for usleep])
+  AC_TRY_COMPILE([#include ],
+ [sleep(1);
+  usleep(100);],
+ [AC_DEFINE(HAVE_USLEEP,1,
+  [Defined if usleep exists.])],[])
+  AC_MSG_RESULT($ac_has_usleep)
   fi
 
   AC_SUBST(GLIBCXX_LIBS)
@@ -3139,7 +3153,7 @@ changequote([,])dnl
 fi
 
 # For libtool versioning info, format is CURRENT:REVISION:AGE
-libtool_VERSION=6:17:0
+libtool_VERSION=6:18:0
 
 # Everything parsed; figure out what files and settings to use.
 case $enable_symvers in
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index cd0be4e..13e4cf8 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1321,6 +1321,13 @@ GLIBCXX_3.4.17 {
 
 } GLIBCXX_3.4.16;
 
+GLIBCXX_3.4.18 {
+
+# std::this_thread::__sleep_for
+_ZNSt11this_thread11__sleep_for*;
+
+} GLIBCXX_3.4.17;
+
 # Symbols in the support library (libsupc++) have their own tag.
 CXXABI_1.3 {
 
diff --git a/libstdc++-v3/include/std/thread b/libstdc++-v3/include/std/thread
index 8a45b65..6f1e3fc 100644
--- a/libstdc++-v3/include/std/thread
+++ b/libstdc++-v3/include/std/thread
@@ -249,32 +249,39 @@ _GLIBCXX_END_NAMESPACE_VERSION
 inline thread::id
 get_id() noexcept { return thread::id(__gthread_self()); }
 
-#ifdef _GLIBCXX_USE_SCHED_YIELD
 /// yield
 inline void
 yield() noexcept
-{ __gthread_yield(); }
+{
+#ifdef _GLIBCXX_USE_SCHED_YIELD
+  __gthread_yield();
 #endif
+}
+
+void
+__sleep_for(chrono::seconds, chrono::nanoseconds);
 
 #ifdef _GLIBCXX_USE_NANOSLEEP
+inline void
+__sleep_for(chrono::seconds __s, chrono::nanoseconds __ns)
+{
+  __gthread_time_t __ts =
+   {
+ static_cast(__s.count()),
+ static_cast(__ns.count())
+   };
+  ::nanosleep(&__ts, 0);
+}
+#endif
+
 /// sleep_for
 template
   inline void
   sleep_for(const chrono::duration<_Rep, _Period>& __rtime)
   {
-   chrono::seconds __s =
- chrono::duration_cast(__rtime);
-
-   chrono::nanoseconds __ns =
- chrono::duration_cast(__rtime - __s);
-
-   __gthread_time_t __ts =
- {
-   static_cast(__s.count()),
-   static_cast(__ns.count())
- };
-
-   ::nanosleep(&__ts, 0);
+   auto __s = chrono::duration_cast(__rtime);
+   auto __ns = chrono::duration_cast(__rtime - __s);
+   __sleep_for(__s, __ns);
   }
 
 /// sleep_unti

Re: RFA: Add Epiphany port

[Gerald Pfeifer]

On Fri, 4 Nov 2011, Joern Rennecke wrote:

install.texi is a bit funny.  sourcebuild.texi says to add configurations
to the list in config.texi even if you have nothing to say about them.
install.texi says you shouldn't do that.  But after a while, it does do
that for a number of newer ports.  So this seems to be a case of 'do what I
do, not what I say' ...


I tried to reduce this conflict and adjust this to be more clear
(between what "is" and what "has to be").

Applied to mainline.

Gerald

2012-08-26  Gerald Pfeifer  

* doc/install.texi (Specific): Clarify what needs to be added to
this section.

Index: doc/install.texi
===
--- doc/install.texi(revision 190692)
+++ doc/install.texi(working copy)
@@ -2966,7 +2966,7 @@
Note that this list of install notes is @emph{not} a list of supported
hosts or targets.  Not all supported hosts and targets are listed
here, only the ones that require host-specific or target-specific
-information are.
+information have to. 


@ifhtml
@itemize

Re: random numbers in bulk

[Jonathan Wakely]

On 26 August 2012 18:19, Ulrich Drepper wrote:
> Also, I consider the interface clean and now very C++-y.  Iterators
> are used and transparently all kinds of overloads are possible.  Only
> the iterator variants need to be documented, making the extensions
> easy to use.  The only minor complication is that the pointer type had
> to be introduced (or something like __normal_iterator has to be
> reinvented).

It would be a lot easier to read with a typedef for the iterator type:

  template
void
__generate(result_type* __f, result_type* __t,
   _UniformRandomNumberGenerator& __urng,
   const param_type& __p)
{ this->__generate(__iterator(__f), __iterator(__t), __urng, __p); }

private:
  typedef result_type* pointer;
  typedef
__gnu_cxx::__normal_iterator
__iterator;

There's no need to qualify std::uniform_int_distribution and include
the template argument list, within the class scope the class' own name
is injected and can be used safely.

Re: random numbers in bulk

[Paolo Carlini]

Hi,

On 08/26/2012 07:19 PM, Ulrich Drepper wrote:

On Sun, Aug 26, 2012 at 10:27 AM, Paolo Carlini
 wrote:

Thus, all in all, for the time being I would go with __generate.

OK, here's a version of the patch with the patch for 54376 already assumed.

I changed to function name to __generate.  I feel much more
comfortable with using the leading underscores.

I changed _OutputIterator to _ForwardIterator.

If you have things like:

+  template
+   void
+   __generate(_ForwardIterator __f, _ForwardIterator __t,
+  _UniformRandomNumberGenerator& __urng)


then probably you want to swap the template parameters (or viceversa):

+  template
+   void
+   __generate(_ForwardIterator __f, _ForwardIterator __t,
+  _UniformRandomNumberGenerator& __urng)


Frankly, I'm finding the forwarding via __gnu_cxx::__normal_iterator 
pretty ugly. Can't we have instead an internal, private, 
__generate_impl(_ForwardIterator, _ForwardIterator, 
_UniformRandomNumberGenerator&, const param_type&) which is called by 
both the variant of __generate taking iterators and the variant taking 
pointers?


Paolo.

Re: random numbers in bulk

[Jonathan Wakely]

On 26 August 2012 18:34, Jonathan Wakely wrote:
> On 26 August 2012 18:19, Ulrich Drepper wrote:
>> Also, I consider the interface clean and now very C++-y.  Iterators
>> are used and transparently all kinds of overloads are possible.  Only
>> the iterator variants need to be documented, making the extensions
>> easy to use.  The only minor complication is that the pointer type had
>> to be introduced (or something like __normal_iterator has to be
>> reinvented).
>
> It would be a lot easier to read with a typedef for the iterator type:
>
>   template
> void
> __generate(result_type* __f, result_type* __t,
>_UniformRandomNumberGenerator& __urng,
>const param_type& __p)
> { this->__generate(__iterator(__f), __iterator(__t), __urng, __p); }
>
> private:
>   typedef result_type* pointer;
>   typedef
> __gnu_cxx::__normal_iterator
> __iterator;
>
> There's no need to qualify std::uniform_int_distribution and include
> the template argument list, within the class scope the class' own name
> is injected and can be used safely.

Or define the typedef locally to the function:

  template
void
__generate(result_type* __f, result_type* __t,
   _UniformRandomNumberGenerator& __urng,
   const param_type& __p)
{
  typedef __gnu_cxx::__normal_iterator
   __iterator;
  this->__generate(__iterator(__f), __iterator(__t), __urng, __p);
}

But I've just seen Paolo's suggestion for a __generate_impl that both
use, and I prefer that idea.

RE: [wwwdocs] Update links to C++ ABI

[Mitchell, Mark]

Gerald --

I think that the GitHub address is more canonical at this point, so I would 
recommend that.  That said, I would expect the codesourcery.com address to work 
"forever"; Mentor IT has set up permanent redirects for addresses from that 
domain.

Thank you,

--
Mark Mitchell
Mentor Graphics
mark_mitch...@mentor.com
+1 (510) 354-7337


> -Original Message-
> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
> Sent: Sunday, August 26, 2012 10:02 AM
> To: Ian Lance Taylor; Mitchell, Mark
> Cc: gcc-patches@gcc.gnu.org; Jonathan Wakely; g...@gcc.gnu.org
> Subject: Re: [wwwdocs] Update links to C++ ABI
> 
> On Sun, 26 Aug 2012, Ian Lance Taylor wrote:
> >> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of
> >> lately, and now redirects to http://mentorembedded.github.com/cxx-
> abi/ .
> >>
> >> I went ahead and updated all our references per the patch below.
> > I don't think that is wise.  The document itself promises that the
> > permanent URL is http://codesourcery.com/cxx-abi/ .  No other URL is
> > promised to be permanent.  I think we should link to the permanent
> URL
> > as long as it continues to work.
> 
> Well, the document itself also carries "Revised 20 March 2001" in line
> 2. ;-)
> 
> Mark, any recommendation from your side?  Is it fine to refer to the
> new mentorembedded.github.com address?
> 
> (Linking to a page that redirects makes verifying the accuracy of links
> tricky.)
> 
> Gerald

Re: [PATCH, middle-end]: Introduce TARGET_LEGITIMATE_COMBINED_INSN target hook

[Uros Bizjak]

On Sun, Aug 26, 2012 at 12:24 PM, Georg-Johann Lay  wrote:
>
>> Actually a v3 of TARGET_REJECT_COMBINED_INSN target hook.
>>
>> Changes:
>> - rename the hook and reverse the return value
>>
>> 2012-08-25  Uros Bizjak  
>>
>> * target.def (legitimate_combined_insn): New target hook.
>> * doc/tm.texi.in (TARGET_LEGITIMATE_COMBINED_INSN): New hook.
>> * doc/tm.texi: Regenerated.
>> * combine.c (recog_for_combine): Call
>> targetm.legitimate_combined_insn
>> to allow targets to reject combined insn.
>> * hooks.h (hook_bool_rtx_true): New.
>> * hooks.c (hook_bool_rtx_true): Ditto.
>>
>> Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32},
>> also with target-dependant x86 patch that implements the hook.
>
> Sorry for yet another question.
>
> I had the situation where the decision depends on the values held in the
> registers (not for x86) like zeroed bits.
>
> Is that information available at the time the hook is called and could
> it be passed down to the backend?

No, it is not yet available. You can get const_int there as an
operand, but values in registers are not known.

Uros.

Re: [wwwdocs] Update links to C++ ABI (was: at exit alternative for AIX)

[Gabriel Dos Reis]

On Sun, Aug 26, 2012 at 11:55 AM, Ian Lance Taylor  wrote:
> On Sun, Aug 26, 2012 at 3:43 AM, Gerald Pfeifer  wrote:
>> On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
>>> The official link at http://codesourcery.com/cxx-abi/ (note trailing
>>> slash) still works.
>>
>> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
>> and now redirects to http://mentorembedded.github.com/cxx-abi/ .
>>
>> I went ahead and updated all our references per the patch below.
>
> I don't think that is wise.  The document itself promises that the
> permanent URL is http://codesourcery.com/cxx-abi/ .  No other URL is
> promised to be permanent.  I think we should link to the permanent URL
> as long as it continues to work.
>
> Ian

That makes sense.

[Patch, Fortran] Plug memory leaks; fix tree-check ICE for PR

[Tobias Burnus]

This patch fixes one ICE and several memory leaks. But there are more.

*

The patch with symbol.c and resolve.c fixes the following issue: 
gfortran leaks memory for:


  REAL FUNCTION GGL(ds)
  GGL = 16806.D0
  END

The problem is the following code in resolve_symbol:

  /* Make sure the formal namespace is present.  */
  if (sym->formal && !sym->formal_ns)
...
  if (formal)
{
  sym->formal_ns = formal->sym->ns;
  sym->formal_ns->refs++;
}

Thus, there are now two references to the same namespace. At the end, 
the memory is freed via
gfc_symbol_done_2, which calls gfc_free_namespace (gfc_current_ns). In 
the latter, one has:


  ns->refs--;
  if (ns->refs > 0)
return;
  free_sym_tree (ns->sym_root);

and the latter frees the formal namespace. The problem is that "ns->ref 
== 2" won't get decreased. That's fixed by the first patch.


 * * *

A similar issue existed for the CONTAINS leakage, which was mentioned 
the other day. Here, the problem is the increment in get_proc_name. 
However, a simple patch with the sym->refs++ in decl.c and symbol.c's 
special case for ENTRY wasn't sufficient as 
gfortran.dg/proc_ptr_result_1.f90 failed. I have now added some extra 
code to parse. to handle "ppr@".


(If one uses valgrind on gfortran.dg/proc_ptr_result_1.f90 it leaks some 
gfc_symbol memory; however, the problems seem to be unrelated.)


* * *

gfortran didn't free gfc_common_head; I added a refs and free it now. 
(For blank commons, no special code is needed as ns->common_head is not 
a pointer.)


* * *

TODO: Despite my hopes for previous patch, there is at least one gfc_ss 
leak left (for channel.f90):


==12987==by 0xE6A7A8: xcalloc (xmalloc.c:162)
==12987==by 0x6074A3: gfc_get_array_ss(gfc_ss*, gfc_expr*, int, 
gfc_ss_type) (trans-array.c:561)

==12987==by 0x613870: gfc_walk_expr(gfc_expr*) (trans-array.c:8787)
==12987==by 0x63A908: gfc_trans_arrayfunc_assign(gfc_expr*, 
gfc_expr*) (trans-expr.c:6749)
==12987==by 0x63C281: gfc_trans_assignment(gfc_expr*, gfc_expr*, 
bool, bool) (trans-expr.c:7438)

==12987==by 0x602C31: trans_code(gfc_code*, tree_node*) (trans.c:1312)
==12987==by 0x65ED66: gfc_trans_do(gfc_code*, tree_node*) 
(trans-stmt.c:1395)



TODO: There are some more failures, e.g. fatigue.f90 shows invalid reads
==13021==at 0x57C718: _ZL10show_locusP5locusii.isra.3 (error.c:392)
==13021==by 0x57CD55: error_print(char const*, char const*, 
__va_list_tag*) (error.c:661)

==13021==by 0x57D878: gfc_error(char const*, ...) (error.c:956)
==13021==by 0x5C3C16: match_complex_part(gfc_expr**) (primary.c:1205)
==13021==by 0x5C3DE6: gfc_match_literal_constant(gfc_expr**, int) 
(primary.c:1296)

and memory leakage in
==13021==by 0xE6A7A8: xcalloc (xmalloc.c:162)
==13021==by 0x5F0077: gfc_new_symbol(char const*, gfc_namespace*) 
(symbol.c:2569)

==13021==by 0x5B5A75: read_module() (module.c:4698)
==13021==by 0x5B5E5B: gfc_use_module(gfc_use_list*) (module.c:6147)
==13021==by 0x5B7233: gfc_use_modules() (module.c:6270)
==13021==by 0x5BC147: use_modules() (parse.c:88)


 * * * * * * * * * * * * * * *

The trans-stmt.c patch fixes a tree-check ICE as we mix different 
logical types; I decided to use the previous type instead folding to the 
boolean_type_node.


Do you think it makes sense to backport it to 4.6/4.7?

 * * *

Build and regtested on x86-64-linux.
OK for the trunk?

Tobias

PS: I wonder why gfortran.dg/interface_3.f90 passed before, given that 
"proc_locus" wasn't set before. I also wonder why my patch causes the 
test case to segfault. Well, at least that bug is now also fixed.
2012-08-26  Tobias Burnus  

	PR fortran/41093
	* gfortran.h (gfc_common_head): Add "int refs".
	* match.c (gfc_match_common): Increment refs.
	* resolve.c (resolve_symbol): Only increment formal_ns->refs
	if formal_ns is not sym->ns.
	* symbol.c (gfc_free_symbol): Only free formal_ns if
	if formal_ns is not sym->ns. Free common_block if refs is one.
	(gfc_release_symbol): Release formal_ns only if the
	symbol is not ENTRY of a module.
	* decl.c (get_proc_name): Don't increment gfc_current_ns->refs.
	* parse.c (parse_interface): Incement proc_unit->refs++ for
	proc-pointer result variables.

	PR fortran/54370
	* trans-stmt.c (gfc_trans_do_while): Don't change the logical
	kind for negation of the condition.

2012-08-26  Tobias Burnus  

	PR fortran/54370
	* gfortran.dg/do_5.f90: New.

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 87eb8a0..efd21dc 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -891,7 +891,6 @@ get_proc_name (const char *name, gfc_symbol **result, bool module_fcn_entry)
 return rc;
 
   sym = *result;
-  gfc_current_ns->refs++;
 
   if (sym && !sym->gfc_new && gfc_current_state () != COMP_INTERFACE)
 {
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 4c8a856..d67d57b 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/for

Re: [Patch, Fortran] Plug memory leaks; fix tree-check ICE for PR

[Tobias Burnus]

Tobias Burnus wrote:


PS: I wonder why gfortran.dg/interface_3.f90 passed before, given that 
"proc_locus" wasn't set before. I also wonder why my patch causes the 
test case to segfault. Well, at least that bug is now also fixed.


Answer: Because I am too strupid to read the patch after spending way 
too much time on this patch. I had accidentally deleted a line:



@@ -2452,7 +2451,9 @@ loop:
accept_statement (st);
prog_unit = gfc_new_block;
prog_unit->formal_ns = gfc_current_ns;
-  proc_locus = gfc_current_locus;
+  if (prog_unit == prog_unit->formal_ns->proc_name
+  && prog_unit->ns != prog_unit->formal_ns)
+prog_unit->refs++;


On the other hand, I think the result of the current patch

subroutine thy_sub (a) ! { dg-error "enclosing procedure" }
  1
Error: INTERFACE procedure 'thy_sub' at (1) has the same name as the 
enclosing procedure


is better than the previous result

subroutine thy_sub (a) ! { dg-error "enclosing procedure" }
   1
Error: INTERFACE procedure 'thy_sub' at (1) has the same name as the 
enclosing procedure



Thus, puzzle solved and diagnostics improved.

Tobias

[Committed] Fix libffi on mips64 with soft-float

[Andrew Pinski]

Hi,
  The problem here was before FFI_ASSERT was turned off in 99% of the
time so nobody noticed that soft-float ABIS would fail.  When the
FFI_ASSERT was converted over to return FFI_BAD_ABI instead, n32 and
n64 soft-float abis started to fail.

I committed the following patch as obvious after a bootstrap/test on
mips64-linux-gnu with soft-float turned on.

Thanks,
Andrew Pinski

ChangeLog:
* src/mips/ffi.c (ffi_prep_closure_loc): Allow n32 with soft-float and n64 with
soft-float.
Index: src/mips/ffi.c
===
--- src/mips/ffi.c  (revision 190638)
+++ src/mips/ffi.c  (working copy)
@@ -670,9 +670,16 @@ ffi_prep_closure_loc (ffi_closure *closu
   if (cif->abi != FFI_O32 && cif->abi != FFI_O32_SOFT_FLOAT)
 return FFI_BAD_ABI;
   fn = ffi_closure_O32;
-#else /* FFI_MIPS_N32 */
-  if (cif->abi != FFI_N32 && cif->abi != FFI_N64)
+#else
+#if _MIPS_SIM ==_ABIN32
+  if (cif->abi != FFI_N32
+  && cif->abi != FFI_N32_SOFT_FLOAT)
 return FFI_BAD_ABI;
+#else
+  if (cif->abi != FFI_N64
+  && cif->abi != FFI_N64_SOFT_FLOAT)
+return FFI_BAD_ABI;
+#endif
   fn = ffi_closure_N32;
 #endif /* FFI_MIPS_O32 */
 

[obvious] Make scan-assembler-times require code generation

[Richard Sandiford]

scan-assembler and scan-assembler-not force -ffat-lto-objects, so that
there'll always be some assembly code to scan.  This patch extends that
to scan-assembler-times.

Tested on mipsisa64-elf, mips64-elf and mips64-linux-gnu.  Applied
as obvious.

Richard


gcc/testsuite/
* lib/scanasm.exp (scan-assembler-times_required_options): New proc.

Index: gcc/testsuite/lib/scanasm.exp
===
--- gcc/testsuite/lib/scanasm.exp   2012-08-26 10:47:25.0 +0100
+++ gcc/testsuite/lib/scanasm.exp   2012-08-26 11:38:17.612805181 +0100
@@ -228,6 +228,11 @@ proc scan-assembler-times { args } {
 }
 }
 
+proc scan-assembler-times_required_options { args } {
+global gcc_force_conventional_output
+return $gcc_force_conventional_output
+}
+
 # Utility for scanning demangled compiler result, invoked via dg-final.
 # Call pass if pattern is present, otherwise fail.
 proc scan-assembler-dem { args } {

[MIPS, committed] Add missing COSTS_N_INSNS call.

[Richard Sandiford]

I'm preparing a patch to turn gcc.target/mips into a torture-like
testsuite.  This showed up a fair few problems, the first of which is
fixed below.  The code that calculated the size cost of multiplications
was missing a COSTS_N_INSNS call.

Tested on mipsisa64-elf, mips64-elf and mips64-linux-gnu.  Applied.

Richard


gcc/
* config/mips/mips.c (mips_rtx_costs): Add missing COSTS_N_INSNS
to the size cost of multiplication.

Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c  2012-08-26 11:34:07.0 +0100
+++ gcc/config/mips/mips.c  2012-08-26 11:35:15.076810487 +0100
@@ -3841,7 +3841,7 @@ mips_rtx_costs (rtx x, int code, int out
  ? mips_cost->int_mult_si * 3 + 6
  : COSTS_N_INSNS (ISA_HAS_MUL3 ? 7 : 9));
   else if (!speed)
-   *total = (ISA_HAS_MUL3 ? 1 : 2);
+   *total = COSTS_N_INSNS (ISA_HAS_MUL3 ? 1 : 2);
   else if (mode == DImode)
*total = mips_cost->int_mult_di;
   else

[MIPS, committed] Fix cost of CINS

[Richard Sandiford]

CINS wasn't being used in -Os code because the combination didn't
seem profitable enough.

Tested on mipsisa64-elf, mips64-elf and mips64-linux-gnu.  Applied.
Will be tested once gcc.target/mips uses gcc-dg.

Richard


gcc/
* config/mips/mips.c (mips_rtx_costs): Add costs for CINS.

Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c  2012-08-26 11:32:09.0 +0100
+++ gcc/config/mips/mips.c  2012-08-26 11:34:07.346812457 +0100
@@ -3681,6 +3681,18 @@ mips_rtx_costs (rtx x, int code, int out
+ set_src_cost (XEXP (x, 0), speed));
  return true;
}
+  if (ISA_HAS_CINS && CONST_INT_P (XEXP (x, 1)))
+   {
+ rtx op = XEXP (x, 0);
+ if (GET_CODE (op) == ASHIFT
+ && CONST_INT_P (XEXP (op, 1))
+ && mask_low_and_shift_p (mode, XEXP (x, 1), XEXP (op, 1), 32))
+   {
+ *total = COSTS_N_INSNS (1) + set_src_cost (XEXP (op, 0), speed);
+ return true;
+   }
+   }
+   
   /* Fall through.  */
 
 case IOR:

[MIPS, committed] Tweak r10k cache barrier code

[Richard Sandiford]

r10k_safe_mem_expr_p couldn't cope with a MEM_REF of an ADDR_EXPR,
which for some reason is produced for r10k-cache-barrier-8.c when
compiled with -O2 -lto but not when compiled with just -O2.

This function is still much too conservative, but I wanted to be
safe for kernel code that plays clever tricks with link-time symbol
definitions.  A trivial example is:

extern char _region_start[];

where _region_start is defined in the linker script.
_region_start[1] can't be seen as an in-range access to an object
as far as the -mr10k-cache-barrier= option is concerned.

Tested on mipsisa64-elf, mips64-elf and mips64-linux-gnu.  Applied.
Will be tested once gcc.target/mips uses gcc-dg.

Richard


gcc/
* config/mips/mips.c (r10k_safe_mem_expr_p): Use get_inner_reference.

Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c  2012-08-26 11:35:15.0 +0100
+++ gcc/config/mips/mips.c  2012-08-26 11:36:43.667807911 +0100
@@ -14446,17 +14446,18 @@ r10k_safe_address_p (rtx x, rtx insn)
 static bool
 r10k_safe_mem_expr_p (tree expr, HOST_WIDE_INT offset)
 {
-  if (offset < 0 || offset >= int_size_in_bytes (TREE_TYPE (expr)))
-return false;
+  HOST_WIDE_INT bitoffset, bitsize;
+  tree inner, var_offset;
+  enum machine_mode mode;
+  int unsigned_p, volatile_p;
 
-  while (TREE_CODE (expr) == COMPONENT_REF)
-{
-  expr = TREE_OPERAND (expr, 0);
-  if (expr == NULL_TREE)
-   return false;
-}
+  inner = get_inner_reference (expr, &bitsize, &bitoffset, &var_offset, &mode,
+  &unsigned_p, &volatile_p, false);
+  if (!DECL_P (inner) || !DECL_SIZE_UNIT (inner) || var_offset)
+return false;
 
-  return DECL_P (expr);
+  offset += bitoffset / BITS_PER_UNIT;
+  return offset >= 0 && offset < tree_low_cst (DECL_SIZE_UNIT (inner), 1);
 }
 
 /* A for_each_rtx callback for which DATA points to the instruction

[MIPS, committed] Fix handling of long branches with delay slots

[Richard Sandiford]

Converting gcc.target/mips to gcc-dg showed up a brown-paper-bag bug
in my long-branch code.  The function that checks whether $gp is needed
only for long branches runs (and must run) after delayed-branch scheduling,
but it wasn't looking inside the SEQUENCEs.

I also made the code check the same jump condition as
mips16_split_long_branches.

Tested on mipsisa64-elf, mips64-elf and mips64-linux-gnu.  Applied.
Will be tested once gcc.target/mips uses gcc-dg.

Richard


gcc/
* config/mips/mips.c (mips_has_long_branch_p): New function,
split out from...
(mips_expand_ghost_gp_insns): ...here.  Look inside sequences.

Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c  2012-08-26 11:21:13.0 +0100
+++ gcc/config/mips/mips.c  2012-08-26 11:32:09.530815882 +0100
@@ -15513,23 +15513,15 @@ mips_reorg_process_insns (void)
   htab_delete (htab);
 }
 
-/* If we are using a GOT, but have not decided to use a global pointer yet,
-   see whether we need one to implement long branches.  Convert the ghost
-   global-pointer instructions into real ones if so.  */
+/* Return true if the function has a long branch instruction.  */
 
 static bool
-mips_expand_ghost_gp_insns (void)
+mips_has_long_branch_p (void)
 {
-  rtx insn;
+  rtx insn, subinsn;
   int normal_length;
 
-  /* Quick exit if we already know that we will or won't need a
- global pointer.  */
-  if (!TARGET_USE_GOT
-  || cfun->machine->global_pointer == INVALID_REGNUM
-  || mips_must_initialize_gp_p ())
-return false;
-
+  /* We need up-to-date instruction lengths.  */
   shorten_branches (get_insns ());
 
   /* Look for a branch that is longer than normal.  The normal length for
@@ -15538,12 +15530,32 @@ mips_expand_ghost_gp_insns (void)
  but they have no delay slot.  */
   normal_length = (TARGET_MIPS16 ? 4 : 8);
   for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
-if (JUMP_P (insn)
-   && USEFUL_INSN_P (insn)
-   && get_attr_length (insn) > normal_length)
-  break;
+FOR_EACH_SUBINSN (subinsn, insn)
+  if (JUMP_P (subinsn)
+ && USEFUL_INSN_P (subinsn)
+ && get_attr_length (subinsn) > normal_length
+ && (any_condjump_p (subinsn) || any_uncondjump_p (subinsn)))
+   return true;
+
+  return false;
+}
+
+/* If we are using a GOT, but have not decided to use a global pointer yet,
+   see whether we need one to implement long branches.  Convert the ghost
+   global-pointer instructions into real ones if so.  */
+
+static bool
+mips_expand_ghost_gp_insns (void)
+{
+  /* Quick exit if we already know that we will or won't need a
+ global pointer.  */
+  if (!TARGET_USE_GOT
+  || cfun->machine->global_pointer == INVALID_REGNUM
+  || mips_must_initialize_gp_p ())
+return false;
 
-  if (insn == NULL_RTX)
+  /* Run a full check for long branches.  */
+  if (!mips_has_long_branch_p ())
 return false;
 
   /* We've now established that we need $gp.  */

[MIPS, committed] Use round-robin allocation of floating-point condition codes

[Richard Sandiford]

This is the last patch (for today) brought about by the upcoming
gcc.target/mips patch.  It's also the one I'm least happy about.

For MIPS IV and above, we've traditionally created CCmode pseudo registers
for floating-point conditions but defined AVOID_CCMODE_COPIES to try to stop
the optimizers from getting too carried away.  Even then, we might have
to spill registers, either because we've run out or because they're live
across a call.  Moving a value out of a condition-code register and back
requires a tortuous sequence, and any time we use it, we know we're
generating bad code.

Running the paired-single tests at higher optimization levels hit the
same problem for CCV2 and CCV4.  We could take the same approach there,
but the sequences would be even worse.  They would almost certainly
outweigh whatever advantage we get from the vectorisation.

In principle, it would be nice for something like:

   if (float_a == float_b)
 foo;
   bar;
   if (float_a == float_b)
 frob;

to reuse a condition-code register.  But:

  (a) we never want to do that if there's a call inbetween
  (b) AVOID_CCMODE_COPIES makes it unlikely anyway
  (c) if it was really performance critical, we'd hope to thread
  the jumps instead.

The main advantage of using more than one condition-code register is
to allow better scheduling of blocks that contain more than one comparison.
We can get most of that advantage, without the downsides of pseudos,
by using a round-robin allocation of registers at expand time.

This produces better code for some of the mips testsuite tests
that already compile correctly.  It does feel very amateurish though...

Tested on mipsisa64-elf, mips64-elf and mips64-linux-gnu.  Applied.
Will be tested once gcc.target/mips uses gcc-dg.

Richard


gcc/
* config/mips/mips.h (AVOID_CCMODE_COPIES): Update rationale for
definition.
* config/mips/mips.c (machine_function): Add next_fcc.
(mips_output_move): Remove handling of fcc moves.
(mips_allocate_fcc): New function.
(mips_emit_compare, mips_expand_vcondv2sf): Use it.
(mips_hard_regno_mode_ok_p): Restrict CCmode to ST registers.
Remove special case for CCmode reloads.
(mips_expand_builtin_compare_1): Use mips_allocate_fcc and treat
the result a fixed operand.
* config/mips/mips.md (move_type): Remove lui_movf.
(type, length): Remove references to it.
(movcc, reload_incc, reload_outcc): Delete.

Index: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h  2012-08-26 20:15:38.585706187 +0100
+++ gcc/config/mips/mips.h  2012-08-26 20:29:05.983682714 +0100
@@ -2395,12 +2395,8 @@ #define Pmode (TARGET_64BIT && TARGET_LO
 #define FUNCTION_MODE SImode
 
 
-
-/* Define if copies to/from condition code registers should be avoided.
-
-   This is needed for the MIPS because reload_outcc is not complete;
-   it needs to handle cases where the source is a general or another
-   condition code register.  */
+/* We allocate $fcc registers by hand and can't cope with moves of
+   CCmode registers to and from pseudos (or memory).  */
 #define AVOID_CCMODE_COPIES
 
 /* A C expression for the cost of a branch instruction.  A value of
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c  2012-08-26 20:22:48.059693700 +0100
+++ gcc/config/mips/mips.c  2012-08-26 20:29:09.350682619 +0100
@@ -321,6 +321,10 @@ struct GTY(())  mips_frame_info {
 };
 
 struct GTY(())  machine_function {
+  /* The next floating-point condition-code register to allocate
+ for ISA_HAS_8CC targets, relative to ST_REG_FIRST.  */
+  unsigned int next_fcc;
+
   /* The register returned by mips16_gp_pseudo_reg; see there for details.  */
   rtx mips16_gp_pseudo_rtx;
 
@@ -4284,9 +4288,6 @@ mips_output_move (rtx dest, rtx src)
  retval[4] = COPNUM_AS_CHAR_FROM_REGNUM (REGNO (src));
  return dbl_p ? retval : retval + 1;
}
-
- if (ST_REG_P (REGNO (src)) && ISA_HAS_8CC)
-   return "lui\t%0,0x3f80\n\tmovf\t%0,%.,%1";
}
 
   if (src_code == MEM)
@@ -4527,6 +4528,63 @@ mips_reversed_fp_cond (enum rtx_code *co
 }
 }
 
+/* Allocate a floating-point condition-code register of mode MODE.
+
+   These condition code registers are used for certain kinds
+   of compound operation, such as compare and branches, vconds,
+   and built-in functions.  At expand time, their use is entirely
+   controlled by MIPS-specific code and is entirely internal
+   to these compound operations.
+
+   We could (and did in the past) expose condition-code values
+   as pseudo registers and leave the register allocator to pick
+   appropriate registers.  The problem is that it is not practically
+   possible for the rtl optimizers to guarantee that no spills will
+   be needed, even when AVOID_CCMODE_COPIES is defi

Committed, btest-gcc.sh: make fortran tests optional

[Hans-Peter Nilsson]

Some targets, like mmix-knuth-mmixware, has fortran turned off.
This patch has seen a large amount of testing, both for targets
with fortran on and off.  A similar patch in the past
() made
the libstdc++ tests optional, so I'm calling it obvious.
Committed.

contrib/regression:
* btest-gcc.sh (TESTLOGS): Make gfortran.sum optional.

Index: btest-gcc.sh
===
--- btest-gcc.sh(revision 190670)
+++ btest-gcc.sh(working copy)
@@ -118,5 +118,4 @@ H_REAL_TARGET=`$SOURCE/config.sub $H_TAR
 TESTLOGS="gcc/testsuite/gcc/gcc.sum
 gcc/testsuite/g++/g++.sum
-gcc/testsuite/gfortran/gfortran.sum
 gcc/testsuite/objc/objc.sum"
 
@@ -145,4 +145,8 @@ echo error > $RESULT || exit 1
 make $dashj -k check
 
+if [ -f gcc/testsuite/gfortran/gfortran.sum ] ; then
+  TESTLOGS="$TESTLOGS gcc/testsuite/gfortran/gfortran.sum"
+fi
+
 if [ -f $BUILD/$H_TARGET/libstdc++-v3/testsuite/libstdc++.sum ] ; then
   TESTLOGS="$TESTLOGS $H_TARGET/libstdc++-v3/testsuite/libstdc++.sum"

brgds, H-P

Re: Patches to enable -ftrack-macro-expansion by default

[Gerald Pfeifer]

On Sun, 26 Aug 2012, Dodji Seketeli wrote:
> Gabriel Dos Reis  writes:
>> I think we show the stack not just for errors, but for any diagnostics.
> I agree, FWIW.

Good point, thanks for the feedback!

I have applied the following, updated patch.

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.21
diff -u -3 -p -r1.21 changes.html
--- changes.html26 Aug 2012 13:55:23 -  1.21
+++ changes.html26 Aug 2012 15:59:47 -
@@ -56,9 +56,13 @@ by this change.
 -->
 
 
-
+
+  
+The option -ftrack-macro-expansion=2 is now
+enabled by default. This allows the compiler to display the
+macro expansion stack in diagnostics.
+  
 
 

Re: Patches to enable -ftrack-macro-expansion by default

[Gabriel Dos Reis]

On Sun, Aug 26, 2012 at 3:00 PM, Gerald Pfeifer  wrote:

> I have applied the following, updated patch.

Thank you!

-- Gaby

[PATCH,PING]] gcc/config/freebsd-spec.h: Fix building PIE

[Gerald Pfeifer]

I have tested this patch on i386-unknown-freebsd10.0 and volunteer
to create a ChangeLog and apply if approved.

Any reviewer?

On Tue, 8 May 2012, Alexis Ballier wrote:
> For the record, there's a similar logic in FreeBSD's gcc: 
> http://svnweb.freebsd.org/base/head/contrib/gcc/config/freebsd-spec.h?revision=200038&view=markup

Thanks for the patch, Alexis.  One question: why do we have the same
in freebsd-spec.h and i386/freebsd.h.  Isn't there a way to simplify
this?  Like omitting this from i386/freebsd.h at all?

Gerald

---
 gcc/config/freebsd-spec.h |9 +++--
 gcc/config/i386/freebsd.h |9 +++--
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
index 770a3d1..2808582 100644
--- a/gcc/config/freebsd-spec.h
+++ b/gcc/config/freebsd-spec.h
@@ -64,11 +64,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
before entering `main'.  */

 #define FBSD_STARTFILE_SPEC \
-  "%{!shared: \
- %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} \
-  %{!p:%{profile:gcrt1.o%s} \
-%{!profile:crt1.o%s \
-   crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}"
+  "%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \
+   crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
 
 /* Provide a ENDFILE_SPEC appropriate for FreeBSD.  Here we tack on
the magical crtend.o file (see crtstuff.c) which provides part of 
@@ -77,7 +74,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
`crtn.o'.  */
 
 #define FBSD_ENDFILE_SPEC \
-  "%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s"
+  "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
 
 /* Provide a LIB_SPEC appropriate for FreeBSD as configured and as
required by the user-land thread model.  Before __FreeBSD_version
diff --git a/gcc/config/i386/freebsd.h b/gcc/config/i386/freebsd.h
index 649274d..dd69e43 100644
--- a/gcc/config/i386/freebsd.h
+++ b/gcc/config/i386/freebsd.h
@@ -67,11 +67,8 @@ along with GCC; see the file COPYING3.  If not see

 #undef STARTFILE_SPEC
 #define STARTFILE_SPEC \
-  "%{!shared: \
- %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} \
-  %{!p:%{profile:gcrt1.o%s} \
-%{!profile:crt1.o%s \
-   crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}"
+  "%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \
+   crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
 
 /* Provide a ENDFILE_SPEC appropriate for FreeBSD.  Here we tack on
the magical crtend.o file (see crtstuff.c) which provides part of 
@@ -81,7 +78,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #undef ENDFILE_SPEC
 #define ENDFILE_SPEC \
-  "%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s"
+  "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
 
 /* Provide a LINK_SPEC appropriate for FreeBSD.  Here we provide support
for the special GCC options -static and -shared, which allow us to
-- 
1.7.8.6

Re: [PATCH] Add sparc Niagara4 scheduling description and tweaks.

[Gerald Pfeifer]

Hi David,

On Thu, 26 Apr 2012, David Miller wrote:
>   * config/sparc/niagara4.md: New file.
>   * config/sparc/sparc.md: Include it.
>   * config/sparc/sparc.c (niagara4_costs): New processor costs.
>   (sparc_option_override): Use it.
>   (sparc_use_sched_lookahead): Return 2 for niagara4.
>   (sparc_issue_rate): Likewise.

how about something like the following for our release notes?

Gerald


Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.22
diff -u -3 -p -r1.22 changes.html
--- changes.html26 Aug 2012 16:00:45 -  1.22
+++ changes.html26 Aug 2012 21:34:13 -
@@ -287,6 +287,12 @@ by this change.
 
   
 
+SPARC
+
+  
+Added optimized instruction scheduling for Niagara4.
+  
+
 

[Patch, Fortran] Make -Wall no longer imply -Wcompare-reals

[Tobias Burnus]

Dear all,

while -Wcompare-reals is a useful option to find bugs, practical 
experience and the discussion here and on c.l.f has shown that this 
option has too many false positives. Hence, it is not suitable for -Wall.


With patch, -Wall no longer implies -Wcompare-reals.

Build on x86-64-linux.
OK for the trunk?

Tobias

PS: I will update wiki/GFortran#news after the committal.
2012-08-26  Tobias Burnus  

	* options.c (set_Wall): Don't set for -Wcompare-reals.
	* invoke.texi (-Wall, -Wcompare-reals): -Wall no longer
	implies -Wcompare-reals.

diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index dfd4ca7..d5fdee3 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -727,7 +727,7 @@ warnings.
 Enables commonly used warning options pertaining to usage that
 we recommend avoiding and that we believe are easy to avoid.
 This currently includes @option{-Waliasing}, @option{-Wampersand},
-@option{-Wconversion}, @option{-Wcompare-reals}, @option{-Wsurprising},
+@option{-Wconversion}, @option{-Wsurprising},
 @option{-Wintrinsics-std}, @option{-Wno-tabs}, @option{-Wintrinsic-shadow},
 @option{-Wline-truncation}, @option{-Wtarget-lifetime},
 @option{-Wreal-q-constant} and @option{-Wunused}.
@@ -939,7 +939,6 @@ allocatable variable; this includes scalars and derived types.
 @item -Wcompare-reals
 @opindex @code{Wcompare-reals}
 Warn when comparing real or complex types for equality or inequality.
-Enabled by @option{-Wall}.
 
 @item -Wtarget-lifetime
 @opindex @code{Wtargt-lifetime}
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index cbec705..764f570 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -475,7 +475,6 @@ set_Wall (int setting)
   gfc_option.warn_character_truncation = setting;
   gfc_option.warn_real_q_constant = setting;
   gfc_option.warn_unused_dummy_argument = setting;
-  gfc_option.warn_compare_reals = setting;
   gfc_option.warn_target_lifetime = setting;
 
   warn_return_type = setting;

Re: [PATCH] Add sparc Niagara4 scheduling description and tweaks.

[David Miller]

From: Gerald Pfeifer 
Date: Sun, 26 Aug 2012 23:34:54 +0200 (CEST)

> Hi David,
> 
> On Thu, 26 Apr 2012, David Miller wrote:
>>  * config/sparc/niagara4.md: New file.
>>  * config/sparc/sparc.md: Include it.
>>  * config/sparc/sparc.c (niagara4_costs): New processor costs.
>>  (sparc_option_override): Use it.
>>  (sparc_use_sched_lookahead): Return 2 for niagara4.
>>  (sparc_issue_rate): Likewise.
> 
> how about something like the following for our release notes?

Looks fine to me.

To-be-committed: fix configure case when assembler COMDAT group support is lacking

[Hans-Peter Nilsson]

If the out-of-tree target assembler supports neither:
.section .text,"axG",@progbits,.foo,comdat
(tsk tsk no leading space, though that's a red herring)
nor:
.section .text,"axG",%progbits,.foo,comdat
then gcc/configure.ac drops through into the system-specific case seen
in the patch, where for *-*-solaris2*, gcc_cv_as_comdat_group_group is
set.  (If one of the above syntaxes work, then
gcc_cv_as_comdat_group_group is forced to "no".)  For other systems,
it is not set.  In subsequent code (setting HAVE_COMDAT_GROUP), a test
of that variable for such systems is seen in the build log as an error
message from "test":
...
checking assembler for section merging support... yes
checking assembler for COMDAT group support (GNU as)... no
checking assembler for COMDAT group support (GNU as, %type)... no
/mnt/2/tmp/hp/testgcc/tmp/st3/gcc/gcc/configure: line 23125: test: =: unary 
operator expected
checking assembler for line table discriminator support... yes
...
I'll commit this in a while as obvious.  The idiom for testing that
the variable is set (N.B. "manual" settings are supposed to work) is
copied from the closest variant, also the least objectionable one
among the extant ones.  There are lots of variants in there. :/

gcc:
* configure.ac (gcc_cv_as_comdat_group_group): Default to no.
* configure: Regenerate.

Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 190682)
+++ gcc/configure.ac(working copy)
@@ -2630,6 +2630,9 @@ else
  if test $gcc_cv_as_comdat_group_percent = yes; then
gcc_cv_as_comdat_group_group=no
  else
+   if test -z "${gcc_cv_as_comdat_group_group+set}"; then
+ gcc_cv_as_comdat_group_group=no
+   fi
case "${target}" in
  # Sun as uses a completely different syntax.
  *-*-solaris2*)

Re: [Patch, Fortran] Make -Wall no longer imply -Wcompare-reals

[Thomas Koenig]

Hi Tobias,



while -Wcompare-reals is a useful option to find bugs, practical
experience and the discussion here and on c.l.f has shown that this
option has too many false positives. Hence, it is not suitable for -Wall.



With patch, -Wall no longer implies -Wcompare-reals.

Build on x86-64-linux.
OK for the trunk?


Please also revert the change to bessel_5.f90.

I am also currently looking at a way to include the option in -Wextra
(which I think is suitable).  We currently don't handle -Wextra in
gfortran, which makes this a bit more difficult. However, I will
only find time for this in around two weeks.

OK for trunk.

Thomas

[PATCH] Remove RS6000_CALL_GLUE

[Segher Boessenkool]

On all supported targets, plain "nop" is the correct thing
to use ("cror 31,31,31" was for POWER).

Tested on powerpc64-linux --enable-languages=c,c++,fortran; no
regressions.  Okay for mainline?


Segher


2012-08-26  Segher Boessenkool  

gcc/
* config/rs6000/aix43.h (RS6000_CALL_GLUE): Delete.
* config/rs6000/aix51.h (RS6000_CALL_GLUE): Delete.
* config/rs6000/aix52.h (RS6000_CALL_GLUE): Delete.
* config/rs6000/aix53.h (RS6000_CALL_GLUE): Delete.
* config/rs6000/aix61.h (RS6000_CALL_GLUE): Delete.
* config/rs6000/freebsd64.h (RS6000_CALL_GLUE): Delete.
* config/rs6000/linux64.h (RS6000_CALL_GLUE): Delete.
* config/rs6000/rs6000.c (print_operand) ['.']: Delete.
* config/rs6000/rs6000.h (RS6000_CALL_GLUE): Delete.
* config/rs6000/rs6000.md (tls_gd_aix):
Replace %. with nop.
(tls_gd_call_aix): Ditto.
(tls_ld_aix): Ditto.
(tls_ld_call_aix): Ditto.
(call_nonlocal_aix32): Ditto.
(call_nonlocal_aix64): Ditto.
(call_value_nonlocal_aix32): Ditto.
(call_value_nonlocal_aix64): Ditto.
---
 gcc/config/rs6000/aix43.h |6 --
 gcc/config/rs6000/aix51.h |6 --
 gcc/config/rs6000/aix52.h |6 --
 gcc/config/rs6000/aix53.h |6 --
 gcc/config/rs6000/aix61.h |6 --
 gcc/config/rs6000/freebsd64.h |4 
 gcc/config/rs6000/linux64.h   |4 
 gcc/config/rs6000/rs6000.c|6 --
 gcc/config/rs6000/rs6000.h|4 
 gcc/config/rs6000/rs6000.md   |   22 --
 10 files changed, 12 insertions(+), 58 deletions(-)

diff --git a/gcc/config/rs6000/aix43.h b/gcc/config/rs6000/aix43.h
index c1a69dc..8ff2111 100644
--- a/gcc/config/rs6000/aix43.h
+++ b/gcc/config/rs6000/aix43.h
@@ -142,12 +142,6 @@ do {   
\
 #undef PTRDIFF_TYPE
 #define PTRDIFF_TYPE "long int"
 
-/* AIX 4 uses PowerPC nop (ori 0,0,0) instruction as call glue for PowerPC
-   and "cror 31,31,31" for POWER architecture.  */
-
-#undef RS6000_CALL_GLUE
-#define RS6000_CALL_GLUE "nop"
-
 /* AIX 4.2 and above provides initialization and finalization function
support from linker command line.  */
 #undef HAS_INIT_SECTION
diff --git a/gcc/config/rs6000/aix51.h b/gcc/config/rs6000/aix51.h
index 6ea30c1..d62d3fb 100644
--- a/gcc/config/rs6000/aix51.h
+++ b/gcc/config/rs6000/aix51.h
@@ -146,12 +146,6 @@ do {   
\
 #undef  WCHAR_TYPE_SIZE
 #define WCHAR_TYPE_SIZE (!TARGET_64BIT ? 16 : 32)
 
-/* AIX V5 uses PowerPC nop (ori 0,0,0) instruction as call glue for PowerPC
-   and "cror 31,31,31" for POWER architecture.  */
-
-#undef RS6000_CALL_GLUE
-#define RS6000_CALL_GLUE "nop"
-
 /* AIX 4.2 and above provides initialization and finalization function
support from linker command line.  */
 #undef HAS_INIT_SECTION
diff --git a/gcc/config/rs6000/aix52.h b/gcc/config/rs6000/aix52.h
index 1c9e77f..02b966d 100644
--- a/gcc/config/rs6000/aix52.h
+++ b/gcc/config/rs6000/aix52.h
@@ -158,12 +158,6 @@ do {   
\
 #undef  WCHAR_TYPE_SIZE
 #define WCHAR_TYPE_SIZE (!TARGET_64BIT ? 16 : 32)
 
-/* AIX V5 uses PowerPC nop (ori 0,0,0) instruction as call glue for PowerPC
-   and "cror 31,31,31" for POWER architecture.  */
-
-#undef RS6000_CALL_GLUE
-#define RS6000_CALL_GLUE "nop"
-
 /* AIX 4.2 and above provides initialization and finalization function
support from linker command line.  */
 #undef HAS_INIT_SECTION
diff --git a/gcc/config/rs6000/aix53.h b/gcc/config/rs6000/aix53.h
index d1a99e9..870eb06 100644
--- a/gcc/config/rs6000/aix53.h
+++ b/gcc/config/rs6000/aix53.h
@@ -156,12 +156,6 @@ do {   
\
 #undef  WCHAR_TYPE_SIZE
 #define WCHAR_TYPE_SIZE (!TARGET_64BIT ? 16 : 32)
 
-/* AIX V5 uses PowerPC nop (ori 0,0,0) instruction as call glue for PowerPC
-   and "cror 31,31,31" for POWER architecture.  */
-
-#undef RS6000_CALL_GLUE
-#define RS6000_CALL_GLUE "nop"
-
 /* AIX 4.2 and above provides initialization and finalization function
support from linker command line.  */
 #undef HAS_INIT_SECTION
diff --git a/gcc/config/rs6000/aix61.h b/gcc/config/rs6000/aix61.h
index 663777c..9216899 100644
--- a/gcc/config/rs6000/aix61.h
+++ b/gcc/config/rs6000/aix61.h
@@ -157,12 +157,6 @@ do {   
\
 #undef  WCHAR_TYPE_SIZE
 #define WCHAR_TYPE_SIZE (!TARGET_64BIT ? 16 : 32)
 
-/* AIX V5 uses PowerPC nop (ori 0,0,0) instruction as call glue for PowerPC
-   and "cror 31,31,31" for POWER architecture.  */
-
-#undef RS6000_CALL_GLUE
-#define RS6000_CALL_GLUE "nop"
-
 /* AIX 4.2 and above provides initialization and finalization function
support from linker command line.  */
 #undef HAS_INIT_SECTION
diff --git a/gcc/config/rs6000/fre

To-be-committed: correct out-of-tree .hidden support for mmix-knuth-mmixware

[Hans-Peter Nilsson]

GCC configure should say that the linker does *not* support .hidden.
For static-only linking (the only mode supported on this simulator-only
system) this shouldn't really matter.  But, different code is actually
used (not just the attribute-hidden decorations), so different bugs are
exposed.  Like PR54373.  There's a difference for in-tree and separate
build/out-of-tree binutils and this makes the out-of-tree-binutils case
align to the in-tree one, where the linker is found to emit something
that doesn't match the ELF test; the `grep 'EMUL = .*elf' ../ld/Makefile`
fails.  I'll hold this until the non-configury bugs in PR54373 are fixed.

gcc:
* configure.ac (out-of-tree linker .hidden support) Set to "no"
for mmix-knuth-mmixware.
* configure: Regenerate.

Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 190682)
+++ gcc/configure.ac(working copy)
@@ -2300,6 +2300,12 @@ else
   if test x"$ld_is_gold" = xyes; then
 :
   elif echo "$ld_ver" | grep GNU > /dev/null; then
+case "${target}" in
+  mmix-knuth-mmixware)
+# The linker emits by default mmo, not ELF, so "no" is appropriate.
+   gcc_cv_ld_hidden=no
+   ;;
+esac
 if test 0"$ld_date" -lt 20020404; then
   if test -n "$ld_date"; then
# If there was date string, but was earlier than 2002-04-04, fail


brgds, H-P

Re: another wrong-code problem with -fstrict-volatile-bitfields

[Sandra Loosemore]

A couple days ago I wrote:


While I was grovelling around trying to swap in more state on the
bitfield store/extract code for the patch rewrite being discussed here:

http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01546.html

I found a reference to PR23623 and found that it is broken again, but in
a different way. On ARM EABI, the attached test case correctly does
32-bit reads for the volatile int bit-field with
-fstrict-volatile-bitfields, but incorrectly does 8-bit writes. I
thought I should try to track this down and fix it first, as part of
making the bit-field read/extract code more consistent with each other,
before trying to figure out a new place to hook in the packedp attribute
stuff. The patch I previously submitted does not fix the behavior of
this test case for writing, nor does reverting the older patch that
added the packedp attribute for reading break that case.

After I tweaked a couple other places in store_bit_field_1 to handle
-fstrict-volatile-bitfields consistently with extract_bit_field_1, I've
gotten it into store_fixed_bit_field, to parallel the read case where it
is getting into extract_fixed_bit_field. But there it's failing to reach
the special case for using the declared mode of the field with
-fstrict-volatile-bitfields because it's been passed bitregion_start = 0
and bitregion_end = 7 so it thinks it must not write more than 8 bits no
matter what. Those values are coming in from expand_assignment, which is
in turn getting them from get_bit_range.


To be more specific, here is a work-in-progress patch that takes a 
brute-force approach by making store_fixed_bit_field ignore the provided 
bit region in the strict volatile bitfield case; it also has the other 
fixes to make the bitfield store control flow match that for extract. 
This fixes the previously-failing test case and regression tests OK on 
arm-none-eabi, but I haven't tried it on any other target yet.  Is this 
a reasonable way to resolve this conflict, or should something farther 
up the call chain take care of it?


-Sandra


2012-08-26  Sandra Loosemore  

gcc/
* expmed.c (store_bit_field_1): Make handling of strict
volatile bitfields parallel that for extraction.
(store_fixed_bit_field): Ignore bitregion for strict volatile
bitfields.
(extract_bit_field_1): Make test for strict volatile bitfields
explicit.

Index: gcc/expmed.c
===
--- gcc/expmed.c	(revision 190623)
+++ gcc/expmed.c	(working copy)
@@ -475,6 +475,19 @@ store_bit_field_1 (rtx str_rtx, unsigned
 	return true;
 }
 
+  offset = bitnum / unit;
+  bitpos = bitnum % unit;
+  byte_offset = (bitnum % BITS_PER_WORD) / BITS_PER_UNIT
++ (offset * UNITS_PER_WORD);
+
+  /* If the bitfield is volatile, we need to make sure the access
+ remains on a type-aligned boundary.  */
+  if (GET_CODE (op0) == MEM
+  && MEM_VOLATILE_P (op0)
+  && GET_MODE_BITSIZE (GET_MODE (op0)) > 0
+  && flag_strict_volatile_bitfields > 0)
+goto no_subreg_mode_swap;
+
   /* If the target is a register, overwriting the entire object, or storing
  a full-word or multi-word field can be done with just a SUBREG.
 
@@ -482,11 +495,6 @@ store_bit_field_1 (rtx str_rtx, unsigned
  done with a simple store.  For targets that support fast unaligned
  memory, any naturally sized, unit aligned field can be done directly.  */
 
-  offset = bitnum / unit;
-  bitpos = bitnum % unit;
-  byte_offset = (bitnum % BITS_PER_WORD) / BITS_PER_UNIT
-+ (offset * UNITS_PER_WORD);
-
   if (bitpos == 0
   && bitsize == GET_MODE_BITSIZE (fieldmode)
   && (!MEM_P (op0)
@@ -581,6 +589,7 @@ store_bit_field_1 (rtx str_rtx, unsigned
 	return true;
 	}
 }
+ no_subreg_mode_swap:
 
   /* Handle fields bigger than a word.  */
 
@@ -809,8 +818,11 @@ store_bit_field_1 (rtx str_rtx, unsigned
 }
 
   /* If OP0 is a memory, try copying it to a register and seeing if a
- cheap register alternative is available.  */
-  if (HAVE_insv && MEM_P (op0))
+ cheap register alternative is available.
+ Do not try this optimization for volatile bitfields if
+ -fstrict-volatile-bitfields is in effect.  */
+  if (HAVE_insv && MEM_P (op0)
+  && !(MEM_VOLATILE_P (op0) && flag_strict_volatile_bitfields > 0))
 {
   enum machine_mode bestmode;
   unsigned HOST_WIDE_INT maxbits = MAX_FIXED_MODE_SIZE;
@@ -988,8 +1000,6 @@ store_fixed_bit_field (rtx op0, unsigned
 	mode = word_mode;
 
   if (MEM_VOLATILE_P (op0)
-  && GET_MODE_BITSIZE (GET_MODE (op0)) > 0
-	  && GET_MODE_BITSIZE (GET_MODE (op0)) <= maxbits
 	  && flag_strict_volatile_bitfields > 0)
 	mode = GET_MODE (op0);
   else
@@ -1683,8 +1693,11 @@ extract_bit_field_1 (rtx str_rtx, unsign
 }
 
   /* If OP0 is a memory, try copying it to a register and seeing if a
- cheap register alternative is available.  */
-  if (ext_mode != MAX_MACHINE_