Re: [PATCH] PR libstdc++/89446 fix null pointer dereference in char_traits
On 23/02/19 10:55 +0100, Eric Botcazou wrote: I forgot to say that this is a conservative list of targets where -fnon-call-exceptions is supported. Maybe it could run on other targets, but this should be enough to ensure we don't get a regression for this bug. What do you mean by supported exactly? The manual for -fnon-call-exceptions says: "Note that this requires platform-specific runtime support that does not exist everywhere." I don't know exactly what that means, so the test only runs on targets where I know it works. Ada and Go set it by default and they are supported on a bunch of other targets... It's not supposed to be an exhaustive list of targets where it's supported. As I said, it's a conservative list. It could run on more targets, but there might not be much benefit as long as the test runs on some targets that get tested often.
[PATCH] P0340R2 Making std::underlying_type SFINAE-friendly
* include/std/type_traits (__underlying_type_impl): New helper to
make underlying_type SFINAE-friendly.
(underlying_type): Derive from __underlying_type_impl.
* testsuite/20_util/underlying_type/requirements/typedefs-3.cc: New
test.
This was just approved in Kona.
Tested powerpc64le-linux, committed to trunk.
commit fbe2d0cc1229cf5804da50e23d9dbd00ec9b1c75
Author: Jonathan Wakely
Date: Sat Feb 23 03:32:47 2019 +
P0340R2 Making std::underlying_type SFINAE-friendly
* include/std/type_traits (__underlying_type_impl): New helper to
make underlying_type SFINAE-friendly.
(underlying_type): Derive from __underlying_type_impl.
* testsuite/20_util/underlying_type/requirements/typedefs-3.cc: New
test.
diff --git a/libstdc++-v3/include/std/type_traits
b/libstdc++-v3/include/std/type_traits
index 993967244ff..977ca0e1350 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -2176,12 +2176,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
common_type<_Tp, _Up>>::type, _Vp...>::type
{ };
+ template::value>
+struct __underlying_type_impl
+{
+ using type = __underlying_type(_Tp);
+};
+
+ template
+struct __underlying_type_impl<_Tp, false>
+{ };
+
/// The underlying type of an enum.
template
struct underlying_type
-{
- typedef __underlying_type(_Tp) type;
-};
+: public __underlying_type_impl<_Tp>
+{ };
template
struct __declval_protector
diff --git
a/libstdc++-v3/testsuite/20_util/underlying_type/requirements/typedefs-3.cc
b/libstdc++-v3/testsuite/20_util/underlying_type/requirements/typedefs-3.cc
new file mode 100644
index 000..5b9a4afb093
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/underlying_type/requirements/typedefs-3.cc
@@ -0,0 +1,52 @@
+// Copyright (C) 2019 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library 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.
+
+// This library 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 library; see the file COPYING3. If not see
+//
[PATCH] Improve error message for bad arguments to script
* generate_libstdcxx_web_docs: Improve error output.
This makes the script a bit more user friendly. Committed to trunk.
commit b771c659703e48b531c3df0999d56cec1c7dad39
Author: Jonathan Wakely
Date: Sat Feb 23 03:36:45 2019 +
Improve error message for bad arguments to script
* generate_libstdcxx_web_docs: Improve error output.
diff --git a/maintainer-scripts/generate_libstdcxx_web_docs
b/maintainer-scripts/generate_libstdcxx_web_docs
index 00ebcbf7f67..74886356bc7 100755
--- a/maintainer-scripts/generate_libstdcxx_web_docs
+++ b/maintainer-scripts/generate_libstdcxx_web_docs
@@ -3,16 +3,28 @@
# i.e. http://gcc.gnu.org/onlinedocs/gcc-x.y.z/libstdc++*
SRCDIR=${1}
-DOCSDIR=$(realpath ${2})
+DOCSDIR=${2}
if ! [ $# -eq 2 -a -x "${SRCDIR}/configure" -a -d "${DOCSDIR}" ]
then
+ if ! [ $# -eq 2 ]
+ then
+echo "$0: Wrong number of arguments" >&2
+ elif ! [ -x "${SRCDIR}/configure" ]
+ then
+echo "$0: No executable configure script found in $SRCDIR" >&2
+ elif ! [ -d "${DOCSDIR}" ]
+ then
+echo "$0: Output directory does not exist: $DOCSDIR" >&2
+ fi
echo "Usage: $0 " >&2
exit 1
fi
set -e
+DOCSDIR=$(realpath ${DOCSDIR})
+
# Check we have some of the required tools
for i in doxygen dot dblatex pdflatex makeindex
do
[PATCH] Include "../../../libgfortran/ISO_Fortran_binding.h"
PR testsuite/89476
* gfortran.dg/ISO_Fortran_binding_5.c: Include
"../../../libgfortran/ISO_Fortran_binding.h".
* gfortran.dg/ISO_Fortran_binding_6.c: Likewise.
---
gcc/testsuite/gfortran.dg/ISO_Fortran_binding_5.c | 2 +-
gcc/testsuite/gfortran.dg/ISO_Fortran_binding_6.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_5.c
b/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_5.c
index 116f548ad99..f8bdb2716cd 100644
--- a/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_5.c
+++ b/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_5.c
@@ -4,7 +4,7 @@
#include
#include
-#include "ISO_Fortran_binding.h"
+#include "../../../libgfortran/ISO_Fortran_binding.h"
typedef struct {
int i;
diff --git a/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_6.c
b/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_6.c
index 704b27cb28a..9ef46cea14f 100644
--- a/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_6.c
+++ b/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_6.c
@@ -4,7 +4,7 @@
#include
#include
-#include "ISO_Fortran_binding.h"
+#include "../../../libgfortran/ISO_Fortran_binding.h"
#define DEBUG 0
--
2.20.1
[Patch, fortran] PR88117 - [9 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2697
This one was sufficiently 'obvious' that not only has it been committed to 9-branch but to 7- and 8-branches as well. Although the choking gimplifier was a regression, the testcase never worked on any branch because resolve.c:deferred_op_assign should always have returned false for pointer expressions, since the reallocate on assign cannot be used. The part of the patch intrans-expr.c fixed the regression. Committed in revisions 269157, 269160 & 269163. Paul 2019-02-23 Paul Thomas PR fortran/88117 * resolve.c (deferred_op_assign): Return if the lhs expression has the pointer attribute. * trans-expr.c (gfc_trans_assignment_1): Do not fix the string length if the lhs expression has the pointer attribute. 2019-02-23 Paul Thomas PR fortran/88117 * gfortran.dg/deferred_character_32.f90 : New test
Re: [PR fortran/89266, patch] - ICE with TRANSFER of len=0 character array constructor
Hi! Please hold on! With the patch, compiling the test from 34202 program bug4a implicit none type bug4 ! Intentionally left empty end type bug4 type compound integer a type(bug4) b type(bug4) c integer d type(bug4) e end type compound type(bug4) t type(compound) c type(bug4), parameter :: f = bug4() type(compound), parameter :: g = compound(1,f,bug4(),4,f) type other real x(0) end type other c = compound(1,t,t,4,t) write(*,*) c write(*,*) g%d write(*,*) size(transfer(1,[bug4()])) write(*,*) size(transfer(1,[''])) write(*,*) size(transfer(1,[other()])) write(*,*) transfer(transfer([1],[bug4()]),[1],size[1]) end program bug4a start something weird after emitting the error % time gfcp pr34202.f90 pr34202.f90:27:54: 27 |write(*,*) transfer(transfer([1],[bug4()]),[1],size[1]) | 1 Error: Function 'size' requires an argument list at (1) ^C0.003u 0.005s 0:12.66 0.0%0+0k 0+0io 0pf+0w TIA Dominique
Re: [PR fortran/89266, patch] - ICE with TRANSFER of len=0 character array constructor
Hi Harald, OK for trunk? Or rather wait for post-9.1? I think this can go into current trunk. Thanks! Regards Thomas
C++ PATCH to add test for c++/89419
This test was fixed by r269094, a fix for PR88394.
Tested on x86_64-linux, applying to trunk.
2019-02-23 Marek Polacek
PR c++/89419
* g++.dg/cpp1y/lambda-generic-89419.C: New test.
diff --git gcc/testsuite/g++.dg/cpp1y/lambda-generic-89419.C
gcc/testsuite/g++.dg/cpp1y/lambda-generic-89419.C
new file mode 100644
index 000..46ce909f3b8
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-89419.C
@@ -0,0 +1,24 @@
+// PR c++/89419
+// { dg-do compile { target c++14 } }
+
+struct A;
+struct B {
+ struct C { C (); C (C &); } b;
+};
+struct D { A operator* (); };
+struct A {
+ template void foo (T x) { x (this); }
+};
+struct E {
+ auto bar () { return e; }
+ D e;
+};
+struct F { B f; int g; };
+
+int
+main ()
+{
+ E e;
+ auto f = *e.bar ();
+ auto i = [&] { F g; g.g = 1; auto h = [&](auto) { g.g = 0; }; f.foo (h);
return g; };
+}
Re : add tsv110 pipeline scheduling
Hi ,James:
Sorry for not responding to your email in time because of Chinese New Year’s
holiday and urgent work. The three questions you mentioned last email are due
to my misunderstanding of pipeline.
the first question, These instructions will occupy both the tsv110_ls* and
tsv110_fsu* Pipeline at the same time.
rewritten as follows:
(define_insn_reservation
"tsv110_neon_ld4_lane" 9
(and (eq_attr "tune" "tsv110")
(eq_attr "type" "neon_load4_all_lanes,neon_load4_all_lanes_q,\
neon_load4_one_lane,neon_load4_one_lane_q"))
"(tsv110_ls1 + tsv110_fsu1)|(tsv110_ls1 + tsv110_fsu2)|(tsv110_ls2 +
tsv110_fsu1)|(tsv110_ls2 + tsv110_fsu2)")
the second question, These instructions will use tsv110_fsu1 Pipeline or
tsv110_fsu2 Pipeline.
rewritten as follows:
(define_insn_reservation "tsv110_neon_abd_aba" 4
(and (eq_attr "tune" "tsv110")
(eq_attr "type" "neon_abd,neon_arith_acc"))
"tsv110_fsu1|tsv110_fsu2")
the third question, These instructions will use tsv110_fsu1 Pipeline or
tsv110_fsu2 Pipeline.
rewritten as follows:
(define_insn_reservation "tsv110_neon_abd_aba_q" 4
(and (eq_attr "tune" "tsv110")
(eq_attr "type" "neon_arith_acc_q"))
"tsv110_fsu1|tsv110_fsu2")
In addition to the above changes, I asked hardware engineers and colleagues to
review my patch and modify some of the errors. The detailed patches are as
follows:
* config/aarch64/aarch64-cores.def (tsv1100): Change scheduling model.
* config/aarch64/aarch64.md : Add "tsv110.md"
* config/aarch64/tsv110.md: New file.
diff --git a/gcc/config/aarch64/aarch64-cores.def
b/gcc/config/aarch64/aarch64-cores.def
index ed56e5e..82d91d6
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -105,7 +105,7 @@ AARCH64_CORE("neoverse-n1", neoversen1, cortexa57, 8_2A,
AARCH64_FL_FOR_ARCH8_
AARCH64_CORE("neoverse-e1", neoversee1, cortexa53, 8_2A,
AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | AARCH64_FL_DOTPROD
| AARCH64_FL_SSBS, cortexa53, 0x41, 0xd4a, -1)
/* HiSilicon ('H') cores. */
-AARCH64_CORE("tsv110", tsv110, cortexa57, 8_2A, AARCH64_FL_FOR_ARCH8_2 |
AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, tsv110,
0x48, 0xd01, -1)
+AARCH64_CORE("tsv110", tsv110, tsv110, 8_2A, AARCH64_FL_FOR_ARCH8_2 |
AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, tsv110,
0x48, 0xd01, -1)
/* ARMv8.4-A Architecture Processors. */
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index b7cd9fc..861f059 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -361,6 +361,7 @@
(include "thunderx.md")
(include "../arm/xgene1.md")
(include "thunderx2t99.md")
+(include "tsv110.md")
;; ---
;; Jumps and other miscellaneous insns
diff --git a/gcc/config/aarch64/tsv110.md b/gcc/config/aarch64/tsv110.md
new file mode 100644
index 000..9d12839
--- /dev/null
+++ b/gcc/config/aarch64/tsv110.md
@@ -0,0 +1,708 @@
+;; tsv110 pipeline description
+;; Copyright (C) 2018 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
+;;
Re: [PATCH] PR libstdc++/89446 fix null pointer dereference in char_traits
> I forgot to say that this is a conservative list of targets where > -fnon-call-exceptions is supported. Maybe it could run on other > targets, but this should be enough to ensure we don't get a regression > for this bug. What do you mean by supported exactly? Ada and Go set it by default and they are supported on a bunch of other targets... -- Eric Botcazou
[PATCH] Unreachable bb discovery for returns_twice/__builtin_setjmp_receiver/.ABNORMAL_DISPATCH (PR tree-optimization/89280)
Hi!
AFAIK we use EDGE_ABNORMAL edges (without EDGE_EH) for the following
purposes:
1) edges from various spots in the IL to an .ABNORMAL_DISPATCHER basic block
2) edges from that .ABNORMAL_DISPATCHER to bbs with DECL_NONLOCAL label
for non-local goto
3) edges from that .ABNORMAL_DISPATCHER to bbs with FORCED_LABEL label
for computed jumps
4) edges from that .ABNORMAL_DISPATCHER to bbs starting with
__builtin_setjmp_receiver (these actually also have a FORCED_LABEL,
and the FORCED_LABEL's address is taken in the __builtin_setjmp_receiver
call argument (and corresponding __builtin_setjmp_setup's second
argument)
5) edges from that .ABNORMAL_DISPATCHER to bbs starting with a returns_twice
call (like normal setjmp, vfork, ...)
4) and 5) above together represent returns_twice calls, which in reality
can't be reentered "second" time without actually be called "first" time
normally. As the testcase show, we can get ICEs if we remove the normal
basic blocks through which they are entered (which could define pre-SSA
form SSA_NAMEs that are used after them). If going successfully into SSA
form, we should be safe afterwards from this kind of issues, we just have
PHIs with (ab) SSA_NAMEs in it, but still if we can prove the returns_twice
call is not entered normally, we should be able to remove also the second
enter path and anything dominated by that as unreachable; right now that
can be eliminated only during RTL opts where we don't have those abnormal
edges.
The following patch implements this in cleanup_control_flow_pre which is
where GIMPLE removal of unreachable basic block happens.
For 5), we simply ignore such edges for visited propagation, we have
| +---AB2.ABNORMAL_DISPATCHER
| / ^
v v |
setjmp AB1
| \ |
v ++
normally if it is reachable, so by ignoring the AB2 edge, if there is
any normal edge to setjmp, it will be visited (and so will be
.ABNORMAL_DISPATCHER and anything that is reachable after setjmp).
If the normal incoming edge into setjmp is gone, setjmp will not be visited,
even when .ABNORMAL_DISPATCHER is reachable through some other AB edges
(we create those pessimistically from lots of spots).
For 4), we have
|
v
__builtin_setjmp_setup (..., &)
| \
v +-AB3>.ABNORMAL_DISPATCHER
/
+-AB4---+
/
v
:
__builtin_setjmp_receiver (&)
|
v
The patch ignores the AB4 edge above in normal processing
(.ABNORMAL_DISPATCHER could have again many incoming edges from lots of
spots, it could be visited before that __builtin_setjmp_setup or after it)
but has a special code when we make __builtin_setjmp_setup basic block
visited, we queue AB4 edge for special processing where it will not be
ignored.
And finally, for 1) the patch has a case for a dead .ABNORMAL_DISPATCHER,
one that has only incoming edges but no successors. I didn't want to
complicate or slow down the processing too much, so it is actually done
only if .ABNORMAL_DISPATCHER has no outgoing edges, rather than if it has
some, but all of them are in the end to non-visited basic blocks.
This means when we for 5) or 4) above remove all such bbs as dead in one
cfg cleanup, we remove .ABNORMAL_DISPATCHER only in the following cfg
cleanup.
Edges 2) and 3) are handled normally as before.
The reason the patch tries to be conservative in the checks rather than
having gcc_asserts that things are the way they should be is that it seems
we unfortunately expose those __builtin_setjmp_setup and
__builtin_setjmp_receiver builtins to users and they can do stuff like:
void *buf[5];
void
foo (int a)
{
__label__ lab;
__builtin_setjmp_setup (buf, &);
lab:
__builtin_setjmp_receiver (&);
// if (a)
//__builtin_longjmp (buf, 1);
}
and it actually compiles (ICEs with the longjmp in there, without/with the
following patch; I just didn't want to introduce further ICEs on these
bogus testcases).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-02-23 Jakub Jelinek
PR tree-optimization/89280
* tree-cfgcleanup.c (maybe_dead_abnormal_edge_p,
builtin_setjmp_setup_bb): New functions.
(cleanup_control_flow_pre): Ignore maybe_dead_abnormal_edge_p edges.
When visiting __builtin_setjmp_setup block, queue in special
setjmp_vec vector edges from .ABNORMAL_DISPATCHER to corresponding
__builtin_setjmp_receiver.
* gcc.c-torture/compile/pr89280.c: New test.
* gcc.dg/torture/pr57147-2.c: Don't expect a setjmp after noreturn
function. Skip the test for -O0.
--- gcc/tree-cfgcleanup.c.jj2019-02-23 01:14:03.032266203 +0100
+++ gcc/tree-cfgcleanup.c 2019-02-23 01:40:03.589681687 +0100
@@ -723,6
Re: [PATCH] make -Wformat-overflow consistent between data models
On Fri, Feb 22, 2019 at 07:25:53PM -0700, Martin Sebor wrote: > A few tests recently added for PR 88993 introduced an assumption > on the host compiler's data model that breaks between ILP32 and > LP64, causing failures test run failures > (see https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01867.html). > Rather than avoiding the problem in the tests the attached patch > removes the data model assumption from the sprintf pass itself, > making the warnings emitted by the pass consistent regardless. > > Bootstrapped and tested on x86_64-linux, and smoke-tested with > an i386-linux GCC. > > Martin > gcc/ChangeLog: > > * gimple-ssa-sprintf.c (target_strtol): Rename... > (target_strtohwi): ...to this. Handle values up to HOST_WIDE_INT_MAX. > (parse_directive): Adjust to name change. Use HOST_WIDE_INT_MAX to > check for range error. Ok. Jakub
