[v3 PATCH] Implement C++17 string searchers.

[Ville Voutilainen]

The first patch just transforms the TS version into an std one, the second
patch makes it conform by implementing P0253R1. I haven't added
any tests for the pair-seconds of the new api, and I noticed that we
might want to go through our make_pairs and make_tuples and qualify
them throughout the library, where applicable. Such things can be
added with subsequent patches.

2016-09-12  Ville Voutilainen  

Implement C++17 string searchers.
* include/std/functional: (unordered_map, vector): New includes
in C++17 mode.
(array, bits/stl_algo.h): Likewise.
(default_searcher, __boyer_moore_map_base): New.
(__boyer_moore_array_base, __is_std_equal_to): Likewise.
(__boyer_moore_base_t, boyer_moore_searcher): Likewise.
(boyer_moore_horspool_searcher, make_default_searcher): Likewise.
(make_boyer_moore_searcher): Likewise.
(make_boyer_moore_horspool_searcher): Likewise.
* testsuite/20_util/function_objects/searchers.cc: New.


2016-09-12  Ville Voutilainen  

Implement P0253R1, Fixing a design mistake in the searchers
interface in Library Fundamentals.
* include/std/functional: (utility): New include in C++17 mode.
(default_searcher): Use a pair as return type, adjust the definition.
(boyer_moore_searcher): Likewise.
(boyer_moore_horspool_searcher): Likewise.
* testsuite/20_util/function_objects/searchers.cc: Adjust.
diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index 05d4282..3f0c1a8 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -58,6 +58,13 @@
 #include 
 #include 
 
+#if __cplusplus > 201402L
+#include 
+#include 
+#include 
+#include 
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -2197,6 +2204,308 @@ _GLIBCXX_MEM_FN_TRAITS(&&, false_type, true_type)
   return _Not_fn>{std::forward<_Fn>(__fn)};
 }
 
+  // Searchers
+
+  template>
+class default_searcher
+{
+public:
+  default_searcher(_ForwardIterator1 __pat_first,
+  _ForwardIterator1 __pat_last,
+  _BinaryPredicate __pred = _BinaryPredicate())
+  : _M_m(__pat_first, __pat_last, std::move(__pred))
+  { }
+
+  template
+   _ForwardIterator2
+   operator()(_ForwardIterator2 __first, _ForwardIterator2 __last) const
+   {
+ return std::search(__first, __last,
+std::get<0>(_M_m), std::get<1>(_M_m),
+std::get<2>(_M_m));
+   }
+
+private:
+  std::tuple<_ForwardIterator1, _ForwardIterator1, _BinaryPredicate> _M_m;
+};
+
+  template
+struct __boyer_moore_map_base
+{
+  template
+   __boyer_moore_map_base(_RAIter __pat, size_t __patlen,
+  _Hash&& __hf, _Pred&& __pred)
+   : _M_bad_char{ __patlen, std::move(__hf), std::move(__pred) }
+   {
+ if (__patlen > 0)
+   for (__diff_type __i = 0; __i < __patlen - 1; ++__i)
+ _M_bad_char[__pat[__i]] = __patlen - 1 - __i;
+   }
+
+  using __diff_type = _Tp;
+
+  __diff_type
+  _M_lookup(_Key __key, __diff_type __not_found) const
+  {
+   auto __iter = _M_bad_char.find(__key);
+   if (__iter == _M_bad_char.end())
+ return __not_found;
+   return __iter->second;
+  }
+
+  _Pred
+  _M_pred() const { return _M_bad_char.key_eq(); }
+
+  std::unordered_map<_Key, _Tp, _Hash, _Pred> _M_bad_char;
+};
+
+  template
+struct __boyer_moore_array_base
+{
+  template
+   __boyer_moore_array_base(_RAIter __pat, size_t __patlen,
+_Unused&&, _Pred&& __pred)
+   : _M_bad_char{ std::array<_Tp, _Len>{}, std::move(__pred) }
+   {
+ std::get<0>(_M_bad_char).fill(__patlen);
+ if (__patlen > 0)
+   for (__diff_type __i = 0; __i < __patlen - 1; ++__i)
+ {
+   auto __ch = __pat[__i];
+   using _UCh = std::make_unsigned_t;
+   auto __uch = static_cast<_UCh>(__ch);
+   std::get<0>(_M_bad_char)[__uch] = __patlen - 1 - __i;
+ }
+   }
+
+  using __diff_type = _Tp;
+
+  template
+   __diff_type
+   _M_lookup(_Key __key, __diff_type __not_found) const
+   {
+ auto __ukey = static_cast>(__key);
+ if (__ukey >= _Len)
+   return __not_found;
+ return std::get<0>(_M_bad_char)[__ukey];
+   }
+
+  const _Pred&
+  _M_pred() const { return std::get<1>(_M_bad_char); }
+
+  std::tuple, _Pred> _M_bad_char;
+};
+
+  template
+struct __is_std_equal_to : std::false_type { };
+
+  template<>
+struct __is_std_equal_to> : std::true_type { };
+
+  // Use __boyer_moore_array_base when pattern consists of narrow characters
+  // and uses std::equal_to as the predicate.
+  template::value_type,
+  typename _Diff = typename iterator_traits<_

Re: [PATCH] Add -Wshadow-local and -Wshadow-compatible-local.

[Mark Wielaard]

Hi Manuel,

On Sun, Sep 11, 2016 at 08:26:20PM +0100, Manuel López-Ibáñez wrote:
> On 11/09/16 14:02, Mark Wielaard wrote:
> >   -Wshadow-local which warns if a local variable shadows another local
> >   variable or parameter,
> > 
> >   -Wshadow-compatible-local which warns if a local variable shadows
> >   another local variable or parameter whose type is compatible with that
> >   of the shadowing variable.
> 
> I honestly don't see the need for the second flag. Why not make Wshadow, or
> at least Wshadow-local, work in this way by default?

Because they are different (subsets) of warnings, projects might prefer
warnings for a wider or smaller set. Also -Wshadow is known to have the
current behaviour, so changing it now will be confusing. Also google
already released a gcc variant with these warnings using these semantics.

> variables that will nevertheless trigger errors/warnings if used wrongly
> seems not very useful anyway.

I am sorry, I cannot follow your reasoning here.
Could you try to explain in different words or with a specific example?

> > +   /* If '-Wshadow-compatible-local' is specified without other
> > +  -Wshadow flags, we will warn only when the types of the
> > +  shadowing variable (i.e. new_decl) and the shadowed variable
> > +  (old_decl) are compatible.  */
> > +   if (comptypes (TREE_TYPE (old_decl), TREE_TYPE (new_decl)))
> > + warning_code = OPT_Wshadow_compatible_local;
> > +   else
> > + warning_code = OPT_Wshadow_local;
> > +   warned = warning (warning_code,
> > + "declaration of %q+D shadows a parameter",
> > + new_decl);
> 
> Please don't use +D. Use warning_at with DECL_SOURCE_LOCATION(new_decl).
> See: https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Locations

Thanks. I think I fixed it in the attached. But note that this was
existing code and that the wiki page you reference doesn't mention
warning_at even once. If you want this kind of pattern changed in
the code base it would be helpful to add an example of how to change
existing code to use the new/correct way to the wiki so people can do
this as an easy hack.

> > + /* If '-Wshadow-compatible-local' is specified without other
> > +-Wshadow flags, we will warn only when the type of the
> > +shadowing variable (i.e. x) can be converted to that of
> > +the shadowed parameter (oldlocal). The reason why we only
> > +check if x's type can be converted to oldlocal's type
> > +(but not the other way around) is because when users
> > +accidentally shadow a parameter, more than often they
> > +would use the variable thinking (mistakenly) it's still
> > +the parameter. It would be rare that users would use the
> > +variable in the place that expects the parameter but
> > +thinking it's a new decl.  */
> 
> As said above, IMHO, this behavior should be the default of -Wshadow, or at
> least, of -Wshadow-local. The current behavior only leads to people not
> using -Wshadow (and us not including it in -Wall -Wextra). There is a Linus
> rant from some years ago that explains vehemently why Wshadow is useless in
> its current form.

As I explained above I don't think changing the semantics of the warnings
is a good idea. There are projects currently using -Wshadow and expecting
it to warn as it does. I am not familiar with this "rant". If you believe
it is useful input to the discussion could you provide a pointer or ask
Linus to participate in this discussion to explain what his preferences
are?

> > +@item -Wshadow-compatible-local
> > +@opindex Wshadow-compatible-local
> > +@opindex Wno-shadow-compatible-local
> > +Warn when a local variable shadows another local variable or parameter
> > +whose type is compatible with that of the shadowing variable. In C++,
> > +type compatibility here means the type of the shadowing variable can be
> > +converted to that of the shadowed variable. The creation of this flag
> > +(in addition to @option{-Wshadow-local}) is based on the idea that when
> > +a local variable shadows another one of incompatible type, it is most
> > +likely intentional, not a bug or typo, as shown in the following example:
> 
> -Wshadow-compatible-local seems safe enough to be enabled by -Wall (or
> -Wextra). Options not enabled by either are rarely used (and, hence, rarely
> tested).

There are multiple testcases provided. I am not against enabling any of
these options in -Wall or -Wextra, but it would be good to see some
experiments using them first on some larger codebases (maybe gcc itself).
If you could try it on some and report what the rate of false positive
is (plus maybe some examples to show whether one might or might not want
to fix them anyway) then we can see if it makes sense. But I believe that
should be done independent from intr

Re: [PATCH, LRA] Fix PR rtl-optimization 77289, LRA matching constraint problem

[Peter Bergner]

On 9/11/16 3:35 PM, Bernd Edlinger wrote:

FYI: I have a patch for the aarch64 regression here:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=39600

It passes bootstrap and reg-testing on x86_64-linux-gnu.


Thanks for debugging and fixing this!



Also the mentioned aarch64 and powerpc test cases
pass manually in a cross-compiler, but I cannot do the
boot-strap on powerpc or aarch64 by myself.

So It would be nice if one of you would take the time
and try that patch.


I can confirm that is bootstraps and regtests with no regressions
on powerpc64le-linux and that the pr77289.c test case does pass.

Peter

Re: [PATCH, LRA] Fix PR rtl-optimization 77289, LRA matching constraint problem

[Bernd Edlinger]

FYI: I have a patch for the aarch64 regression here:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=39600

It passes bootstrap and reg-testing on x86_64-linux-gnu.

Also the mentioned aarch64 and powerpc test cases
pass manually in a cross-compiler, but I cannot do the
boot-strap on powerpc or aarch64 by myself.

So It would be nice if one of you would take the time
and try that patch.


Thanks
Bernd.

Re: [PATCH] Add -Wshadow-local and -Wshadow-compatible-local.

[Manuel López-Ibáñez]

On 11/09/16 14:02, Mark Wielaard wrote:

  -Wshadow-local which warns if a local variable shadows another local
  variable or parameter,

  -Wshadow-compatible-local which warns if a local variable shadows
  another local variable or parameter whose type is compatible with that
  of the shadowing variable.


I honestly don't see the need for the second flag. Why not make Wshadow, or at 
least Wshadow-local, work in this way by default? Warning for shadowed 
variables that will nevertheless trigger errors/warnings if used wrongly seems 
not very useful anyway.




+   /* If '-Wshadow-compatible-local' is specified without other
+  -Wshadow flags, we will warn only when the types of the
+  shadowing variable (i.e. new_decl) and the shadowed variable
+  (old_decl) are compatible.  */
+   if (comptypes (TREE_TYPE (old_decl), TREE_TYPE (new_decl)))
+ warning_code = OPT_Wshadow_compatible_local;
+   else
+ warning_code = OPT_Wshadow_local;
+   warned = warning (warning_code,
+ "declaration of %q+D shadows a parameter",
+ new_decl);


Please don't use +D. Use warning_at with DECL_SOURCE_LOCATION(new_decl).
See: https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Locations



+ /* If '-Wshadow-compatible-local' is specified without other
+-Wshadow flags, we will warn only when the type of the
+shadowing variable (i.e. x) can be converted to that of
+the shadowed parameter (oldlocal). The reason why we only
+check if x's type can be converted to oldlocal's type
+(but not the other way around) is because when users
+accidentally shadow a parameter, more than often they
+would use the variable thinking (mistakenly) it's still
+the parameter. It would be rare that users would use the
+variable in the place that expects the parameter but
+thinking it's a new decl.  */


As said above, IMHO, this behavior should be the default of -Wshadow, or at 
least, of -Wshadow-local. The current behavior only leads to people not using 
-Wshadow (and us not including it in -Wall -Wextra). There is a Linus rant from 
some years ago that explains vehemently why Wshadow is useless in its current form.



+@item -Wshadow-compatible-local
+@opindex Wshadow-compatible-local
+@opindex Wno-shadow-compatible-local
+Warn when a local variable shadows another local variable or parameter
+whose type is compatible with that of the shadowing variable. In C++,
+type compatibility here means the type of the shadowing variable can be
+converted to that of the shadowed variable. The creation of this flag
+(in addition to @option{-Wshadow-local}) is based on the idea that when
+a local variable shadows another one of incompatible type, it is most
+likely intentional, not a bug or typo, as shown in the following example:


-Wshadow-compatible-local seems safe enough to be enabled by -Wall (or 
-Wextra). Options not enabled by either are rarely used (and, hence, rarely 
tested).


Cheers,

Manuel.

Re: [PATCH] PR fortran/77507

[Steve Kargl]

On Sat, Sep 10, 2016 at 08:04:40PM +0200, Andreas Schwab wrote:
> FAIL: gfortran.dg/pr77507.f90   -O  (test for excess errors)
> Excess errors:
> /opt/gcc/gcc-20160910/gcc/testsuite/gfortran.dg/pr77507.f90:3:6: Fatal Error: 
> Can't open module file 'ieee_arithmetic.mod' for reading at (1): No such file 
> or directory
> 
> Andreas.
> 

Should be fixed by

Committed revision 240085

2016-09-11  Steven G. Kargl  

* gfortran.dg/pr77507.f90: Move to ...
* gfortran.dg/ieee/pr77507.f90: here.

-- 
Steve

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

[Mike Stump]

On Sep 11, 2016, at 8:35 AM, Moritz Klammler  wrote:
> 
> There is a long-standing
> [bug report](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61439)
> pointing out that the `download_prerequisites` script doesn't verify the
> integrity of the packages it downloads.

I like the script.

Verify package integrity of downloaded prerequisites (partially fixes 61439)

[Moritz Klammler]

There is a long-standing
[bug report](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61439)
pointing out that the `download_prerequisites` script doesn't verify the
integrity of the packages it downloads.  The original bug report is only
concerned about stability but for me, this is first and foremost a
security issue.  Even more so since the downloads happen over unsecured
FTP connections.

I have already posted an improved version of the script that does verify
checksums on the Bugzilla thread in February this year but apparently,
it went unnoticed there.

Coincidentally, another person posted an alternative solution at the
same place just about the same time that didn't seem to have received
any attention either.  Their fix is minimal invasive while I essentially
re-wrote the script and added a bunch of command-line options.  I
believe those are useful but you could also arguably call it
over-engineering.  I'm okay with either fix but I'm not going to speak
for the other person so I'll only explain my own patch here.

The script relies on the files `contrib/prerequisites.sha512` and
`contrib/prerequisites.md5` to be present in the GCC tarball and will
use them to verify the package integrity.  Said files are tiny and
readily available here

ftp://gcc.gnu.org/pub/gcc/infrastructure/sha512.sum
ftp://gcc.gnu.org/pub/gcc/infrastructure/md5.sum

but I didn't include them into the patch because I have no way of
verifying their integrity.  Somebody who has secure access to the GNU
servers should verify that we add the correct checksums into the GCC
archive.  Every time a new version of the prerequisites is used, the
checksum files have to be updated as well.

The integrity of the downloaded prerequisites then follows transitively
assuming that GCC's own tarball hasn't been tampered with which we have
to assume anyway.  (Ensuring this is beyond the scope of anything we can
put *inside* the tarball itself.)

Since my patch doesn't contain said checksum files and other than that,
merely replaces a single file completely, I'm attaching just the new
version of the `download_prerequisites` scripts and not a diff.  It
would be nice of somebody with trusted access to the GNU servers could
be so kind to prepare the actual SVN patch for me.

After adding the checksum files, the ChangeLog entry might be like this:

* contrib/download_prerequisites: Verify integrity of downloaded
packages and added more command-line options.

* contrib/prerequisites.sha512: New.

* contrib/prerequisites.md5: New.

I already went through the copyright assignment process for GCC so I
think you should be able to include my patch if it is accepted.  (I also
took the liberty to mention the FSF as copyright holder in the script
without waiting for the patch being accepted.)

I believe that attacking a system by compromising the compiler is a very
serious threat so I hope that you'll consider patching the script.  If
there are any portability or other issues with the way I wrote the
script, I'll be ready to fix them.


Moritz
-- 
OpenPGP:

Public Key:   http://openpgp.klammler.eu
Fingerprint:  2732 DA32 C8D0 EEEC A081  BE9D CF6C 5166 F393 A9C0

#! /bin/sh -eu
#! -*- coding:utf-8; mode:shell-script; -*-

# Download some prerequisites needed by GCC.
# Run this from the top level of the Gcc source tree and the Gcc build will do
# the right thing.  Run it with the `--help` option for more information.
#
# (C) 2016 Free Software Foundation
#
# This program is free software: you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free Software
# Foundation, either version 3 of the License, or (at your option) any later
# version.
#
# This program 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
# this program.  If not, see http://www.gnu.org/licenses/.


program='download_prerequisites'
version='(unversioned)'

graphite=1
verify=1
force=0
chksum='sha512'
directory='.'

gmp='gmp-4.3.2.tar.bz2'
mpfr='mpfr-2.4.2.tar.bz2'
mpc='mpc-0.8.1.tar.gz'
isl='isl-0.15.tar.bz2'

base_url='ftp://gcc.gnu.org/pub/gcc/infrastructure/'

echo_archives() {
echo "${gmp}"
echo "${mpfr}"
echo "${mpc}"
if [ ${graphite} -gt 0 ]; then echo "${isl}"; fi
}

helptext="usage: ${program} [OPTION...]

Downloads some prerequisites needed by GCC.  Run this from the top level of the
GCC source tree and the GCC build will do the right thing.

The following options are available:

 --directory=DIR  download and unpack packages into DIR instead of '.'
 --force  download again overwriting existing packages
 --no-force   do not download existing packages again (default)
 --isldownload ISL, needed for Graph

Re: [PATCH] Remove extraneous whitespace in libbacktrace

[Ian Lance Taylor]

On Sun, Jan 3, 2016 at 7:43 PM, Michael McConville  wrote:
> This was committed to Rust's copy of libbacktrace in October by Carlos
> Liam.

Thanks.  I committed this patch to the GCC repository, with this
ChangeLog entry:

2016-09-11  Carlos Liam  

* all: Remove meaningless trailing whitespace.

Ian

libgo patch committed: add runtime/internal/sys package

[Ian Lance Taylor]

This patch to libgo adds the runtime/internal/sys package that is in
the gc toolchain.  In the gc toolchain this package is mostly a
collection of generated files, one for each GOARCH value and one for
each GOOS value.  Rather than doing it in the gofrontend, we record
the information in configure.ac and write it out in Makefile.  My hope
is that this will make it easier to add new ports: people will have to
change the information in one place, configure.ac.

This change also removes the automake GOARCH conditionals, which are
no longer used.  The GOOS conditionals remain, as they are currently
used while building the C runtime code.

The new package includes intrinsics for ctz and bswap, so I have added
definitions of the builtin functions to the Gcc_backend constructor
along with the other builtin function definitions.  This is in the GCC
Go interface, not the gofrontend proper.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Because the file version.go is moving from the runtime package to the
sys package as part of this change, people with existing working
directories may need to remove their libgo directories before
rebuilding.  The automatic dependencies won't handle that change
correctly.

Ian

2016-09-11  Ian Lance Taylor  

* go-gcc.cc (Gcc_backend::Gcc_backend): Add builtin versions of
ctz, ctzll, bswap32, bswap64.
Index: gcc/go/go-gcc.cc
===
--- gcc/go/go-gcc.cc(revision 240053)
+++ gcc/go/go-gcc.cc(working copy)
@@ -692,6 +692,28 @@ Gcc_backend::Gcc_backend()
NULL_TREE),
   false, false);
 
+  // Used by runtime/internal/sys.
+  this->define_builtin(BUILT_IN_CTZ, "__builtin_ctz", "ctz",
+  build_function_type_list(integer_type_node,
+   unsigned_type_node,
+   NULL_TREE),
+  true, false);
+  this->define_builtin(BUILT_IN_CTZLL, "__builtin_ctzll", "ctzll",
+  build_function_type_list(integer_type_node,
+   long_long_unsigned_type_node,
+   NULL_TREE),
+  true, false);
+  this->define_builtin(BUILT_IN_BSWAP32, "__builtin_bswap32", "bswap32",
+  build_function_type_list(uint32_type_node,
+   uint32_type_node,
+   NULL_TREE),
+  true, false);
+  this->define_builtin(BUILT_IN_BSWAP64, "__builtin_bswap64", "bswap64",
+  build_function_type_list(uint64_type_node,
+   uint64_type_node,
+   NULL_TREE),
+  true, false);
+
   // We provide some functions for the math library.
   tree math_function_type = build_function_type_list(double_type_node,
 double_type_node,
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 240071)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-d3a145b111a4f4ea772b812c6a0b3a853c207819
+841bea960b1f097e2cff5ad2618800296dcd4ec2
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 240070)
+++ libgo/Makefile.am   (working copy)
@@ -586,12 +586,54 @@ time.c: $(srcdir)/runtime/time.goc goc2c
 version.go: s-version; @true
 s-version: Makefile
rm -f version.go.tmp
-   echo "package runtime" > version.go.tmp
-   echo 'const defaultGoroot = "$(prefix)"' >> version.go.tmp
-   echo 'const theVersion = "'`cat $(srcdir)/VERSION | sed 1q`' '`$(GOC) 
--version | sed 1q`'"' >> version.go.tmp
-   echo 'const theGoarch = "'$(GOARCH)'"' >> version.go.tmp
-   echo 'const theGoos = "'$(GOOS)'"' >> version.go.tmp
-   echo 'const theGccgoToolDir = "$(libexecsubdir)"' >> version.go.tmp
+   echo "package sys" > version.go.tmp
+   echo 'const DefaultGoroot = "$(prefix)"' >> version.go.tmp
+   echo 'const TheVersion = "'`cat $(srcdir)/VERSION | sed 1q`' '`$(GOC) 
--version | sed 1q`'"' >> version.go.tmp
+   echo 'const GOARCH = "'$(GOARCH)'"' >> version.go.tmp
+   echo 'const GOOS = "'$(GOOS)'"' >> version.go.tmp
+   echo 'const GccgoToolDir = "$(libexecsubdir)"' >> version.go.tmp
+   echo >> version.go.tmp
+   echo "type ArchFamilyType int" >> version.go.tmp
+   echo >> version.go.tmp
+   echo "const (" >> version.go.tmp
+   echo "  UNKNOWN ArchFamilyType = iota" >> version.go.tmp
+   for a in $(ALLGOARCHFAMILY

[PATCH] Add -Wshadow-local and -Wshadow-compatible-local.

[Mark Wielaard]

On Sat, Sep 10, 2016 at 09:51:57AM -0400, Eric Gallager wrote:
> On 9/10/16, Ian Lance Taylor  wrote:
> > I'm not sure about the patch to configure.ac/configure.  The last I
> > looked -Wshadow would warn if a local variable shadows a global
> > variable.  That can cause a pointless build break if some system
> > header file defines a global variable that happens to have the same
> > name as a local variable.  It's not a likely scenario but I don't see
> > a need to court a build breakage.
>
> Maybe if the patch to add -Wshadow-local went in, the configure script
> could use that instead? For reference:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01317.html

That is a nice idea. Thanks. Lets try to get this in, I forward ported
it and cleaned things up a bit.

This patch from Le-Chun Wu adds two two new shadow warning flags for
C and C++:

  -Wshadow-local which warns if a local variable shadows another local
  variable or parameter,

  -Wshadow-compatible-local which warns if a local variable shadows
  another local variable or parameter whose type is compatible with that
  of the shadowing variable.

It is already on the google/main branch (Google ref 39127) and was
previously submitted by Diego Novillo and reviewed on
http://codereview.appspot.com/4452058

I addressed the review comments and made the following changes:
- The Wshadow, Wshadow-local and -Wshadow-compatible-local relationships
  are expressed in common.opt instead of in opts.c and documented in
  invoke.texi.
- The "previous declaration" warnings were turned into notes and use
  the (now) existing infrastructure instead of duplicating the warnings.
  The testcases have been adjusted to expect the notes.
- The conditional change in name-lookup.c for non-locals (where we
  don't want to change the warnings, but just check the global ones)
  has been dropped.

gcc/ChangeLog:
2016-09-11  Le-Chun Wu  
Mark Wielaard  

   * common.opt (Wshadow-local): New option.
   (Wshadow-compatible-local): New option.
   * doc/invoke.texi: Document Wshadow-local and Wshadow-compatible-local.

gcc/c/ChangeLog:
2016-09-11  Le-Chun Wu  
Mark Wielaard  

   * c-decl.c (warn_if_shadowing): Use the warning code corresponding
   to the given -Wshadow- variant.

gcc/cp/ChangeLog:
2016-09-11  Le-Chun Wu  
Mark Wielaard  

   * name-lookup.c (pushdecl_maybe_friend): When emitting a
   shadowing warning, use the code corresponding to the
   given -Wshadow- variant.
---
 gcc/c/c-decl.c | 39 +++---
 gcc/common.opt | 10 +++-
 gcc/cp/name-lookup.c   | 28 --
 gcc/doc/invoke.texi| 41 ++
 .../g++.dg/warn/Wshadow-compatible-local-1.C   | 63 ++
 gcc/testsuite/g++.dg/warn/Wshadow-local-1.C| 35 
 gcc/testsuite/g++.dg/warn/Wshadow-local-2.C| 63 ++
 gcc/testsuite/gcc.dg/Wshadow-compatible-local-1.c  | 36 +
 gcc/testsuite/gcc.dg/Wshadow-local-1.c | 22 
 gcc/testsuite/gcc.dg/Wshadow-local-2.c | 49 +
 gcc/testsuite/gcc.dg/Wshadow-local-3.c |  9 
 14 files changed, 404 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wshadow-compatible-local-1.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wshadow-local-1.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wshadow-local-2.C
 create mode 100644 gcc/testsuite/gcc.dg/Wshadow-compatible-local-1.c
 create mode 100644 gcc/testsuite/gcc.dg/Wshadow-local-1.c
 create mode 100644 gcc/testsuite/gcc.dg/Wshadow-local-2.c
 create mode 100644 gcc/testsuite/gcc.dg/Wshadow-local-3.c

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index 8f49c35..31f83d8 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -2735,7 +2735,9 @@ warn_if_shadowing (tree new_decl)
   struct c_binding *b;
 
   /* Shadow warnings wanted?  */
-  if (!warn_shadow
+  if (!(warn_shadow
+|| warn_shadow_local
+|| warn_shadow_compatible_local)
   /* No shadow warnings for internally generated vars.  */
   || DECL_IS_BUILTIN (new_decl)
   /* No shadow warnings for vars made for inlining.  */
@@ -2759,9 +2761,21 @@ warn_if_shadowing (tree new_decl)
break;
  }
else if (TREE_CODE (old_decl) == PARM_DECL)
- warned = warning (OPT_Wshadow,
-   "declaration of %q+D shadows a parameter",
-   new_decl);
+ {
+   enum opt_code warning_code;
+
+   /* If '-Wshadow-compatible-local' is specified without other
+  -Wshadow flags, we will warn only when the types of the
+  shadowing variable (i.e. new_decl) and the shadowed variable
+  (old_decl) are compatible.  */
+   if (comptypes (TREE_TYPE (old_decl), TREE_TYPE (new_decl)))
+  

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 10/09/16 12:59, NightStrike wrote:
> Could we at least reach out and see if there's someone else who could
> be the maintainer?  I noticed gcj patches recently, so there's still
> interest.

1.  It's too late.  We have been discussing this for a long time, and
we're now doing what we decided.

2.  Maintaining GCJ requires a lot of knowledge of both Java and GCC
internals.  There are very few people in the world with that
knowledge, and I'm fairly sure I know them by name.

3.  The Classpath library is very old and is unmaintained.  The only
practical way to update GCJ would be to use the OpenJDK class
libraries instead, but updating GCJ to use those class libraries is a
very substantial job.

So, I cannot prevent anyone from coming along to maintain GCJ, and
neither would I want to.  However, such a proposal would have to be
credible.  It is a multi-engineer-year commitment, and not just any
ordinary engineers.

Andrew.

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

[Jonathan Wakely]

On 11/09/16 11:55 +0200, Christophe Lyon wrote:

On 11 September 2016 at 11:38, Jonathan Wakely  wrote:

Hmm, I'm not sure why it's not failing on all targets, but this should

I don't know either: the same target (arm-none-eabi) but
--with-cpu=cortex-a9 does build.


fix it. Could you test it?


It's not sufficient: I had to apply the same change to new_opvant.cc
for the build to complete.


Tested powerpc64le-linux.  Committed to trunk.

Thanks for the quick testing.



commit 8f127734ff660dabfe6c8f196e34ccc5dc436518
Author: Jonathan Wakely 
Date:   Sun Sep 11 11:07:22 2016 +0100

Fix bootstrap failure when ATOMIC_INT_LOCK_FREE < 2

	* libsupc++/new_opant.cc: Include exception_defines.h.
	* libsupc++/new_opvant.cc: Likewise.

diff --git a/libstdc++-v3/libsupc++/new_opant.cc b/libstdc++-v3/libsupc++/new_opant.cc
index c863d64..1c6ccab 100644
--- a/libstdc++-v3/libsupc++/new_opant.cc
+++ b/libstdc++-v3/libsupc++/new_opant.cc
@@ -24,6 +24,7 @@
 // .
 
 #include 
+#include 
 #include "new"
 
 _GLIBCXX_WEAK_DEFINITION void*
diff --git a/libstdc++-v3/libsupc++/new_opvant.cc b/libstdc++-v3/libsupc++/new_opvant.cc
index a32fec8..2b29547 100644
--- a/libstdc++-v3/libsupc++/new_opvant.cc
+++ b/libstdc++-v3/libsupc++/new_opvant.cc
@@ -24,6 +24,7 @@
 // .
 
 #include 
+#include 
 #include "new"
 
 _GLIBCXX_WEAK_DEFINITION void*

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

[Christophe Lyon]

On 11 September 2016 at 11:38, Jonathan Wakely  wrote:
> On 11/09/16 09:08 +0200, Christophe Lyon wrote:
>>
>> On 10 September 2016 at 08:59, Christophe Lyon
>>  wrote:
>>>
>>> On 9 September 2016 at 23:20, Jason Merrill  wrote:

 On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely 
 wrote:
>
> On 08/09/16 09:10 +0200, Marc Glisse wrote:
>>
>>
>> Do we want a generic fallback implementation (similar to
>> gcc/config/i386/gmm_malloc.h)? A windows version with _aligned_malloc
>> /
>> _aligned_free would also be possible.
>
>
> Making it work for MinGW would be nice.


 OK, this is what I'm checking in; could someone test it on MinGW?

 Jason
>>>
>>>
>>> Hi Jason,
>>>
>>> I'm seeing problems on arm*linux: the tests aligned-new[1235].C fail to
>>> link:
>>> aligned-new5.C:(.text+0x14): undefined reference to `operator
>>> new(unsigned int, std::align_val_t)'
>>>
>>>
>>> On aarch64*-elf and arm-eabi (using newlib), I'm seeing:
>>> /gccsrc/libstdc++-v3/libsupc++/new_opa.cc:66: undefined reference to
>>> `aligned_alloc'
>>>
>>> Am I missing something in my setup?
>>>
>>
>> I'm seeing an additional problem: to GCC build is broken after this
>> commit for target arm-none-eabi (using default cpu):
>>
>> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:
>> In function 'void* operator new(std::size_t, std::align_val_t, const
>> std::nothrow_t&)':
>>
>> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:33:3:
>> error: '__try' was not declared in this scope
>>   __try
>>   ^
>>
>> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:37:11:
>> error: expected primary-expression before '...' token
>>   __catch(...)
>>   ^~~
>>
>> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:37:3:
>> error: '__catch' was not declared in this scope
>>   __catch(...)
>>   ^~~
>>
>> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:41:1:
>> warning: no return statement in function returning non-void
>> [-Wreturn-type]
>> }
>> ^
>>
>> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:30:26:
>> warning: unused parameter 'sz' [-Wunused-parameter]
>> operator new(std::size_t sz, std::align_val_t al, const std::nothrow_t&)
>>  ^~
>>
>> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:30:47:
>> warning: unused parameter 'al' [-Wunused-parameter]
>> operator new(std::size_t sz, std::align_val_t al, const std::nothrow_t&)
>>   ^~
>> make[4]: *** [new_opant.lo] Error 1
>> make[4]: Leaving directory
>>
>> `/home/christophe.lyon/src/GCC/builds/gcc-fsf-reg-240062/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/libsupc++'
>
>
> Hmm, I'm not sure why it's not failing on all targets, but this should
I don't know either: the same target (arm-none-eabi) but
--with-cpu=cortex-a9 does build.

> fix it. Could you test it?
>
It's not sufficient: I had to apply the same change to new_opvant.cc
for the build to complete.

Thanks,

Christophe

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

[Jonathan Wakely]

On 11/09/16 10:38 +0100, Jonathan Wakely wrote:

On 11/09/16 09:08 +0200, Christophe Lyon wrote:

On 10 September 2016 at 08:59, Christophe Lyon
 wrote:

On 9 September 2016 at 23:20, Jason Merrill  wrote:

On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely  wrote:

On 08/09/16 09:10 +0200, Marc Glisse wrote:


Do we want a generic fallback implementation (similar to
gcc/config/i386/gmm_malloc.h)? A windows version with _aligned_malloc /
_aligned_free would also be possible.


Making it work for MinGW would be nice.


OK, this is what I'm checking in; could someone test it on MinGW?

Jason


Hi Jason,

I'm seeing problems on arm*linux: the tests aligned-new[1235].C fail to link:
aligned-new5.C:(.text+0x14): undefined reference to `operator
new(unsigned int, std::align_val_t)'


On aarch64*-elf and arm-eabi (using newlib), I'm seeing:
/gccsrc/libstdc++-v3/libsupc++/new_opa.cc:66: undefined reference to
`aligned_alloc'

Am I missing something in my setup?



I'm seeing an additional problem: to GCC build is broken after this
commit for target arm-none-eabi (using default cpu):
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:
In function 'void* operator new(std::size_t, std::align_val_t, const
std::nothrow_t&)':
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:33:3:
error: '__try' was not declared in this scope
 __try
 ^
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:37:11:
error: expected primary-expression before '...' token
 __catch(...)
 ^~~
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:37:3:
error: '__catch' was not declared in this scope
 __catch(...)
 ^~~
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:41:1:
warning: no return statement in function returning non-void
[-Wreturn-type]
}
^
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:30:26:
warning: unused parameter 'sz' [-Wunused-parameter]
operator new(std::size_t sz, std::align_val_t al, const std::nothrow_t&)
^~
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:30:47:
warning: unused parameter 'al' [-Wunused-parameter]
operator new(std::size_t sz, std::align_val_t al, const std::nothrow_t&)
 ^~
make[4]: *** [new_opant.lo] Error 1
make[4]: Leaving directory
`/home/christophe.lyon/src/GCC/builds/gcc-fsf-reg-240062/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/libsupc++'


Hmm, I'm not sure why it's not failing on all targets, [...]


OK, I see why.  gets included indirectly at
the end of  via

#if (__cplusplus >= 201103L) && (ATOMIC_INT_LOCK_FREE > 1)
#include 
#include 
#endif

The condition isn't true for all targets.

So including it explicitly in new_opant.cc is the right fix.

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

[Jonathan Wakely]

On 11/09/16 09:08 +0200, Christophe Lyon wrote:

On 10 September 2016 at 08:59, Christophe Lyon
 wrote:

On 9 September 2016 at 23:20, Jason Merrill  wrote:

On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely  wrote:

On 08/09/16 09:10 +0200, Marc Glisse wrote:


Do we want a generic fallback implementation (similar to
gcc/config/i386/gmm_malloc.h)? A windows version with _aligned_malloc /
_aligned_free would also be possible.


Making it work for MinGW would be nice.


OK, this is what I'm checking in; could someone test it on MinGW?

Jason


Hi Jason,

I'm seeing problems on arm*linux: the tests aligned-new[1235].C fail to link:
aligned-new5.C:(.text+0x14): undefined reference to `operator
new(unsigned int, std::align_val_t)'


On aarch64*-elf and arm-eabi (using newlib), I'm seeing:
/gccsrc/libstdc++-v3/libsupc++/new_opa.cc:66: undefined reference to
`aligned_alloc'

Am I missing something in my setup?



I'm seeing an additional problem: to GCC build is broken after this
commit for target arm-none-eabi (using default cpu):
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:
In function 'void* operator new(std::size_t, std::align_val_t, const
std::nothrow_t&)':
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:33:3:
error: '__try' was not declared in this scope
  __try
  ^
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:37:11:
error: expected primary-expression before '...' token
  __catch(...)
  ^~~
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:37:3:
error: '__catch' was not declared in this scope
  __catch(...)
  ^~~
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:41:1:
warning: no return statement in function returning non-void
[-Wreturn-type]
}
^
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:30:26:
warning: unused parameter 'sz' [-Wunused-parameter]
operator new(std::size_t sz, std::align_val_t al, const std::nothrow_t&)
 ^~
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:30:47:
warning: unused parameter 'al' [-Wunused-parameter]
operator new(std::size_t sz, std::align_val_t al, const std::nothrow_t&)
  ^~
make[4]: *** [new_opant.lo] Error 1
make[4]: Leaving directory
`/home/christophe.lyon/src/GCC/builds/gcc-fsf-reg-240062/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/libsupc++'


Hmm, I'm not sure why it's not failing on all targets, but this should
fix it. Could you test it?

--- a/libstdc++-v3/libsupc++/new_opant.cc
+++ b/libstdc++-v3/libsupc++/new_opant.cc
@@ -24,6 +24,7 @@
 // .
 
 #include 
+#include 
 #include "new"
 
 _GLIBCXX_WEAK_DEFINITION void*

Re: [PATCH, PR71602, 4/4] Make canonical_va_list_type more strict

[Christophe Lyon]

On 10 September 2016 at 00:04, Jeff Law  wrote:
> On 08/29/2016 10:12 AM, Tom de Vries wrote:
>>
>> On 29/08/16 17:51, Joseph Myers wrote:
>>>
>>> On Wed, 24 Aug 2016, Tom de Vries wrote:
>>>
 This patch fixes PR71602 by making canonical_va_list_type more strict.

 Bootstrapped and reg-tested on x86_64.

 OK for trunk, 6-branch?
>>>
>>>
>>> ENOPATCH
>>>
>>
>> Patch attached this time.
>>
>> Thanks,
>> - Tom
>>
>> 0004-Make-canonical_va_list_type-more-strict.patch
>>
>>
>> Make canonical_va_list_type more strict
>>
>> 2016-08-22  Tom de Vries  
>>
>> PR C/71602
>> * builtins.c (std_canonical_va_list_type): Strictly return
>> non-null for
>> va_list type only.
>> * config/i386/i386.c (ix86_canonical_va_list_type): Same.
>> * gimplify.c (gimplify_va_arg_expr): Handle &va_list.
>>
>> * c-common.c (build_va_arg): Handle more strict
>> targetm.canonical_va_list_type.
>>
>> * c-c++-common/va-arg-va-list-type.c: New test.
>>
>> ---
>
> Happy to see the _REF nodes disappearing from std_canonical_va_list_type.
> If I understand the code correctly its argument should always be a type
> node, so handling an _REF node makes no sense.
>
> OK for the trunk.
>
> jeff

Hi Tom,

I've noticed that the new testcase (va-arg-va-list-type.c) fails on
arm and aarch64 targets.

On aarch64, the compiler emits no error/warning message, hence the test failure.

On arm, the compiler actually ICEs:
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/c-c++-common/va-arg-va-list-type.c:
In function 'fn1':
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/c-c++-common/va-arg-va-list-type.c:8:26:
internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have pointer_type in
arm_extract_valist_ptr, at config/arm/arm.c:2767
0xde4cda tree_check_failed(tree_node const*, char const*, int, char const*, ...)
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree.c:9742
0xe8c28a tree_check3
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree.h:3066
0xe8c28a arm_extract_valist_ptr
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/arm/arm.c:2767
0xe8c2b0 arm_gimplify_va_arg_expr
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/arm/arm.c:2788
0xd566fa expand_ifn_va_arg_1
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1043
0xd566fa expand_ifn_va_arg
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:
0xd5697b execute
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-stdarg.c:1217


Let me know if you need more details.

Thanks,

Christophe

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

[Christophe Lyon]

On 10 September 2016 at 08:59, Christophe Lyon
 wrote:
> On 9 September 2016 at 23:20, Jason Merrill  wrote:
>> On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely  wrote:
>>> On 08/09/16 09:10 +0200, Marc Glisse wrote:

 Do we want a generic fallback implementation (similar to
 gcc/config/i386/gmm_malloc.h)? A windows version with _aligned_malloc /
 _aligned_free would also be possible.
>>>
>>> Making it work for MinGW would be nice.
>>
>> OK, this is what I'm checking in; could someone test it on MinGW?
>>
>> Jason
>
> Hi Jason,
>
> I'm seeing problems on arm*linux: the tests aligned-new[1235].C fail to link:
> aligned-new5.C:(.text+0x14): undefined reference to `operator
> new(unsigned int, std::align_val_t)'
>
>
> On aarch64*-elf and arm-eabi (using newlib), I'm seeing:
> /gccsrc/libstdc++-v3/libsupc++/new_opa.cc:66: undefined reference to
> `aligned_alloc'
>
> Am I missing something in my setup?
>

I'm seeing an additional problem: to GCC build is broken after this
commit for target arm-none-eabi (using default cpu):
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:
In function 'void* operator new(std::size_t, std::align_val_t, const
std::nothrow_t&)':
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:33:3:
error: '__try' was not declared in this scope
   __try
   ^
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:37:11:
error: expected primary-expression before '...' token
   __catch(...)
   ^~~
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:37:3:
error: '__catch' was not declared in this scope
   __catch(...)
   ^~~
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:41:1:
warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:30:26:
warning: unused parameter 'sz' [-Wunused-parameter]
 operator new(std::size_t sz, std::align_val_t al, const std::nothrow_t&)
  ^~
/home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:30:47:
warning: unused parameter 'al' [-Wunused-parameter]
 operator new(std::size_t sz, std::align_val_t al, const std::nothrow_t&)
   ^~
make[4]: *** [new_opant.lo] Error 1
make[4]: Leaving directory
`/home/christophe.lyon/src/GCC/builds/gcc-fsf-reg-240062/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/libsupc++'

Let me know if you need more details.

Thanks,

Christophe


> Thanks,
>
> Christophe