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.ht
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 b
> 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 th
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* Pipelin
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
Hi Harald,
OK for trunk? Or rather wait for post-9.1?
I think this can go into current trunk.
Thanks!
Regards
Thomas
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
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 express
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_bindi
* 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
* 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 i
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 exac
12 matches
Mail list logo
