On 1/23/19 7:28 PM, Segher Boessenkool wrote:
> Hi Martin,
>
> On Wed, Jan 23, 2019 at 10:29:40AM +0100, Martin Liška wrote:
>> diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
>> index 172bdf585d0..5dd316efb63 100644
>> --- a/gcc/cfgrtl.c
>> +++ b/gcc/cfgrtl.c
>> @@ -4396,6 +4396,25 @@ cfg_layout_redirec
On 23/01/19 12:50 -0700, Sandra Loosemore wrote:
I ran libstdc++ tests on nios2-elf target. I observed several new
tests failing with
error: 'mutex' in namespace 'std' does not name a type
The definition of class mutex in include/bits/std_mutex.h is guarded
with "#ifdef _GLIBCXX_HAS_GTHREADS
On Wed, 23 Jan 2019, Richard Earnshaw (lists) wrote:
> On 22/01/2019 15:46, Jakub Jelinek wrote:
> > On Tue, Jan 22, 2019 at 02:43:38PM +, Richard Earnshaw (lists) wrote:
> >>PR target/88469
> >>* profile-count.h (profile_count): Add dummy file with 64-bit alignment
> >>on arm-base
On Wed, Jan 23, 2019 at 6:18 PM Thomas Koenig wrote:
>
> Hi Dominique,
>
> > FAIL: gfortran.dg/internal_pack_4.f90 -O3 -fomit-frame-pointer
> > -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
> >
> > with -m32.
> >
> > gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/internal
On Thu, Jan 24, 2019 at 2:18 AM Nikhil Benesch wrote:
>
> This patch fixes an ICE I reported earlier today as PR go/89019, which
> occurs when compiling sufficiently complicated Go code with link-time
> optimization (i.e., -flto) enabled.
>
> Both of these simple test programs are sufficient to tr
Uros Bizjak writes:
> Hello!
>
> RTL store motion pass transforms:
>
> (insn 19 18 20 4 (parallel [
> (set (mem/c:SI (symbol_ref:SI ("bar_arg") [flags 0x2]
> ) [1 bar_arg+0 S4 A32])
> (fix:SI (reg:DF 89)))
> (clobber (scratch:XF))
> ]) "stdarg-3.c":6
I finally reproduced the bug on native darwin and it is caused
by early -g making dwarf2out.c to set self-DECL_ABSTRACT_ORIGIN
which late dwarf2out.c barfs on when we do not have actual
early DIEs available.
The "fix" is to not make late dwarf2out.c think it has already
emitted early DIEs.
Boot
On 23/01/19 17:01 +0100, Christophe Lyon wrote:
On Wed, 23 Jan 2019 at 16:28, Jonathan Wakely wrote:
On 09/01/19 13:53 +0100, Christophe Lyon wrote:
>On Wed, 9 Jan 2019 at 11:11, Jonathan Wakely wrote:
>>
>> On 09/01/19 10:09 +, Jonathan Wakely wrote:
>> >On 08/01/19 11:13 +0100, Christop
On Wed, 23 Jan 2019 at 22:14, H.J. Lu wrote:
>
> On Wed, Jan 23, 2019 at 12:50 PM Joseph Myers wrote:
> >
> > On Wed, 23 Jan 2019, H.J. Lu wrote:
> >
> > > + fesetround (FE_DOWNWARD);
> > > + float fs = s128;
> > > + if (fs != -0x1p+127)
> > > +abort ();
> > > + double ds = s128;
> > > +
Uros Bizjak writes:
> On Thu, Jan 24, 2019 at 12:52 PM Richard Sandiford
> wrote:
>
>> Another potential problem is that gen_move_insn should only really
>> be used for general_operands.
>>
>> process_insert_insn seems to get this right, so it'd probably be
>> cleanest to split the innards out in
On Thu, Jan 24, 2019 at 12:52 PM Richard Sandiford
wrote:
> Another potential problem is that gen_move_insn should only really
> be used for general_operands.
>
> process_insert_insn seems to get this right, so it'd probably be
> cleanest to split the innards out into something that takes the des
Hi,
I wrote a test-case:
...
int
main (void)
{
for (unsigned i = 0; i < 128; ++i)
{
acc_init (acc_device_nvidia);
acc_shutdown (acc_device_nvidia);
}
return 0;
}
...
and ran it under valgrind. The only leak location reported with a frequency
of 128, was the allocation of
On Thu, 24 Jan 2019, Christophe Lyon wrote:
> The attached small patch adds
> /* { dg-require-effective-target fenv_exceptions } */
> to them.
It should be a *new* effective-target, because these tests are nothing to
do with exceptions; they're about rounding modes (but actually you only
need a
On 1/23/19 2:07 AM, Joseph Myers wrote:
> On Tue, 22 Jan 2019, Richard Biener wrote:
>
>>> Or instead just come up with target specific strings to determine the ABI,
>>> say i386, x86_64 and x32 for the 3 ABIs on x86, powerpc{,64}{,le} on rs6000
>>> etc.
>>
>> Yeah, I would even suggest to use a t
On Thu, Jan 24, 2019 at 6:01 AM Richard Biener
wrote:
>
> On Thu, Jan 24, 2019 at 2:18 AM Nikhil Benesch
> wrote:
> >
> > diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
> > index 7fbdd074119..4e9e0e3026a 100644
> > --- a/gcc/go/go-gcc.cc
> > +++ b/gcc/go/go-gcc.cc
> > @@ -1049,6 +1049,7 @@ Gcc
On Thu, Jan 24, 2019 at 03:57:56PM +0100, Martin Liška wrote:
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -29577,6 +29577,17 @@ ix86_warn_parameter_passing_abi (cumulative_args_t
> cum_v, tree type)
>cum->warn_empty = false;
> }
>
> +static const char *
Missing funct
On 1/23/19 10:53 PM, Alexandre Oliva wrote:
On Jan 21, 2019, Jason Merrill wrote:
"does this have its own template arguments, not just the ones from its
enclosing class?"
Perhaps compare the number of levels of template arguments of the
function to that of its enclosing context?
Is this t
On Thu, Jan 24, 2019 at 3:59 PM Nikhil Benesch wrote:
>
> On Thu, Jan 24, 2019 at 6:01 AM Richard Biener
> wrote:
> >
> > On Thu, Jan 24, 2019 at 2:18 AM Nikhil Benesch
> > wrote:
> > >
> > > diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
> > > index 7fbdd074119..4e9e0e3026a 100644
> > > ---
On 1/24/19 4:05 PM, Jakub Jelinek wrote:
> On Thu, Jan 24, 2019 at 03:57:56PM +0100, Martin Liška wrote:
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -29577,6 +29577,17 @@ ix86_warn_parameter_passing_abi (cumulative_args_t
>> cum_v, tree type)
>>cum->warn_empty = false
The TST instruction no longer matches in all cases due to changes in
Combine. The fix is simple, we now need to allow a subreg as well when
selecting the cc_mode. This fixes the tst_5.c and tst_6.c failures.
AArch64 regress & bootstrap OK.
ChangeLog:
2019-01-23 Wilco Dijkstra
PR rtl
Clang fails to compile std::vector because the static member
__use_relocate cannot be evaluated for an incomplete type. Replace with
a static member function that will not be odr-used until needed, by
which point the type must be complete.
PR libstdc++/88840
* include/bits/stl_vec
On Thu, 24 Jan 2019 at 15:31, Joseph Myers wrote:
>
> On Thu, 24 Jan 2019, Christophe Lyon wrote:
>
> > The attached small patch adds
> > /* { dg-require-effective-target fenv_exceptions } */
> > to them.
>
> It should be a *new* effective-target, because these tests are nothing to
> do with excep
On 24/01/2019 15:36, Wilco Dijkstra wrote:
> The TST instruction no longer matches in all cases due to changes in
> Combine. The fix is simple, we now need to allow a subreg as well when
> selecting the cc_mode. This fixes the tst_5.c and tst_6.c failures.
>
> AArch64 regress & bootstrap OK.
>
On Wed, 23 Jan 2019, Alexander Monakov wrote:
> It appears that sched-deps tries to take notice of a barrier after a jump, but
> similarly to sched-ebb doesn't anticipate that for a tablejump the barrier
> will
> appear after two more insns (a code_label and a jump_table_data).
>
> If so, it nee
On Thu, Jan 24, 2019 at 10:15 AM Richard Biener
wrote:
>
> Ah, I missed that pt is probably a pointer type as well, then the code
> simply aligns the pointed-to type (note dependent on how pt was built
> this seems prone to wreck the TYPE_POINTER_TO/TYPE_NEXT_PTR_TO
> chains which link pointer typ
On 1/24/19 3:46 AM, Jonathan Wakely wrote:
On 23/01/19 12:50 -0700, Sandra Loosemore wrote:
I ran libstdc++ tests on nios2-elf target. I observed several new
tests failing with
error: 'mutex' in namespace 'std' does not name a type
The definition of class mutex in include/bits/std_mutex.h is
The test gcc.dg/torture/fp-int-convert-timode-3.c fails on darwin: the results
are
-0x1p+127
-0x1p+127
TIA
Dominique
This test ICEs since r159006 which added
type = ENUM_UNDERLYING_TYPE (type);
to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we
haven't yet parsed '}' of the enum and the underlying type isn't fixed, and
so checking TYPE_UNSIGNED crashed.
I've added some checks to the
On Wed, Jan 23, 2019 at 09:23:53AM +0100, Richard Biener wrote:
> On Tue, 22 Jan 2019, Jakub Jelinek wrote:
>
> > Hi!
> >
> > SCEV can analyze not just integral/pointer IVs, but (scalar) float ones as
> > well. Calling build_int_cst on such types results in ICE, build_zero_cst
> > works. Though
Hi!
During the vectorizer pass, these magic arrays can be shrink, but the code
doing so expects they are accessed only as array elts, not as whole arrays,
so if there is a clobber for them, it causes checking failure.
It isn't worth adding that support now, so this patch just makes sure we
don't
Hi!
As the following testcase shows, during var-tracking we can end trying to
delegitimize e.g. (plus:SI (unspec:SI ... UNSPEC_SET_GOT)
(const:SI (unspec:SI (symbol_ref:SI ...) UNSPEC_GOTOFF)). The code is
prepared to handle PIC register + UNSPEC_GOTOFF, delegitimizing that
to the underlying SYMB
On January 24, 2019 8:19:11 PM GMT+01:00, Jakub Jelinek
wrote:
>On Wed, Jan 23, 2019 at 09:23:53AM +0100, Richard Biener wrote:
>> On Tue, 22 Jan 2019, Jakub Jelinek wrote:
>>
>> > Hi!
>> >
>> > SCEV can analyze not just integral/pointer IVs, but (scalar) float
>ones as
>> > well. Calling buil
Hi!
On the following testcase,
_cpp_bracket_include -> glue_header_name emits
if (token->type == CPP_EOF)
{
cpp_error (pfile, CPP_DL_ERROR, "missing terminating > character");
break;
}
which works, that last token has proper src_loc etc., but then
parse_
Hi!
The following patch fixes C++ FE ICE during instantiation if if clause
argument is type or value dependent (ideally we'd keep the cancel
directive as OMP_* and finish it again during instantiation, but adding a
new tree code etc. just for this seems overkill). Fixed by using what we
use for i
Hi!
For the tree-nested.c purposes, host teams construct is like parallel or task,
we need shared clause to propagate the frame structures etc., after all,
host teams is just another parallelization level, just spread across NUMA
nodes. For the target teams that is not the case, we ignore there a
Greetings,
This makes memory_order in a scoped enum *only* for C++20.
This is built and tested on x86_64-linux.
OK?
Index: include/bits/atomic_base.h
===
--- include/bits/atomic_base.h (revision 268246)
+++ include/bits/atomic_
This patch adds two variables named 'TV_CGRAPH_FUNC_EXPANSION' and
'TV_CGRAPH_IPA_PASSES' that count the elapsed time of the functions
'expand_all_functions' and 'ipa_passes', respectivelly.
The main point of this is that these functions takes a very long time
when compiling the 'gimple-match.c' f
Hi,
as far as I can see this ICE on invalid points to a substantive, if
minor, weakness of our implementation of the destroying operator delete
facility: we aren't implementing the bits, per 7.6.2.5/(10.1), about
destroying operator delete having precedence over any other operator
delete. Thu
On Thu, Jan 24, 2019 at 8:28 PM Jakub Jelinek wrote:
>
> Hi!
>
> As the following testcase shows, during var-tracking we can end trying to
> delegitimize e.g. (plus:SI (unspec:SI ... UNSPEC_SET_GOT)
> (const:SI (unspec:SI (symbol_ref:SI ...) UNSPEC_GOTOFF)). The code is
> prepared to handle PIC r
On 24/01/19 11:53 -0700, Sandra Loosemore wrote:
On 1/24/19 3:46 AM, Jonathan Wakely wrote:
On 23/01/19 12:50 -0700, Sandra Loosemore wrote:
I ran libstdc++ tests on nios2-elf target. I observed several new
tests failing with
error: 'mutex' in namespace 'std' does not name a type
The defini
On Thu, 24 Jan 2019, Christophe Lyon wrote:
> On Thu, 24 Jan 2019 at 15:31, Joseph Myers wrote:
> >
> > On Thu, 24 Jan 2019, Christophe Lyon wrote:
> >
> > > The attached small patch adds
> > > /* { dg-require-effective-target fenv_exceptions } */
> > > to them.
> >
> > It should be a *new* effec
On 24/01/19 20:20 +, Jonathan Wakely wrote:
On 24/01/19 11:53 -0700, Sandra Loosemore wrote:
On 1/24/19 3:46 AM, Jonathan Wakely wrote:
On 23/01/19 12:50 -0700, Sandra Loosemore wrote:
I ran libstdc++ tests on nios2-elf target. I observed several
new tests failing with
error: 'mutex' in
On Thu, Jan 24, 2019 at 03:36:46PM +, Wilco Dijkstra wrote:
> The TST instruction no longer matches in all cases due to changes in
> Combine. The fix is simple, we now need to allow a subreg as well when
> selecting the cc_mode.
You needed to before, it just wasn't as obvious yet. It now is
On Thu, Jan 24, 2019 at 06:43:38PM +0300, Alexander Monakov wrote:
> On Wed, 23 Jan 2019, Alexander Monakov wrote:
>
> > It appears that sched-deps tries to take notice of a barrier after a jump,
> > but
> > similarly to sched-ebb doesn't anticipate that for a tablejump the barrier
> > will
> >
On 1/23/19 4:41 PM, Joseph Myers wrote:
On Wed, 23 Jan 2019, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00969.html
This patch is OK.
Thanks. I committed it in r268251.
As a heads up, before I did that I noticed a failure in
gcc.c-torture/execute/eeprof-1.c due
It used to be the case that the mangled name of a reference temporary didn't
need to be standardized, because all access would be through the reference.
But now constant expressions can look through references and so different
translation units need to agree on the address of a temporary in the
ini
On Thu, 2019-01-24 at 16:25 +0100, Martin Liška wrote:
>
> >
> > > +ix86_get_multilib_abi_name (void)
> > > +{
> > > + if (!(TARGET_64BIT_P (ix86_isa_flags)))
> > > +return "i386";
> > > + else if (TARGET_X32_P (ix86_isa_flags))
> > > +return "x32";
> > > + else
> > > +return "x86_
> md.texi says
>
> The @samp{tablejump} insn is always the last insn before the jump
> table it uses. Its assembler code normally has no need to use the
> second operand, but you should incorporate it in the RTL pattern so
> that the jump optimizer will not delete the table as unreachable code.
>
On 1/24/19 2:16 PM, Marek Polacek wrote:
This test ICEs since r159006 which added
type = ENUM_UNDERLYING_TYPE (type);
to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we
haven't yet parsed '}' of the enum and the underlying type isn't fixed, and
so checking TYPE_UNSIG
On 1/24/19 2:40 PM, Jakub Jelinek wrote:
Hi!
On the following testcase,
_cpp_bracket_include -> glue_header_name emits
if (token->type == CPP_EOF)
{
cpp_error (pfile, CPP_DL_ERROR, "missing terminating > character");
break;
}
which works, that last
On 1/24/19 2:53 PM, Paolo Carlini wrote:
Hi,
as far as I can see this ICE on invalid points to a substantive, if
minor, weakness of our implementation of the destroying operator delete
facility: we aren't implementing the bits, per 7.6.2.5/(10.1), about
destroying operator delete having prece
Hi Harald,
OK for trunk?
OK. Also not likely to cause a regression, so I think this is quite
fine for now.
Regards
Thomas
On 1/23/19 10:31 AM, Segher Boessenkool wrote:
>> (rs6000_init_hard_regno_mode_ok, direct_move_p): Use
>> HARD_REGISTER_NUM_P.
>
> This line is too long.
Fixed.
> And that is the worst I see in that whole patch! Please apply it.
Committed after a svn update and another self review of th
Here is my attempt at creating a couple of new instructions to
generate more bfi instructions on aarch64. I haven't finished
testing this but it helps with gcc.target/aarch64/combine_bfi_1.c.
Before I went any further with it I wanted to see if anyone
else was working on something like this and i
I just tripped over a segfault in libbacktrace. We apply strrchr to a
possibly NULL filename, with predictable results when it is.
elf.c:3044 passes NULL as the filename parm:
ret = elf_add (state, NULL, d, base_address, error_callback, data,
fileline_fn, foun
On 1/24/19 1:20 PM, Jonathan Wakely wrote:
On 24/01/19 11:53 -0700, Sandra Loosemore wrote:
BTW, I'm more worried about the link errors introduced by the patch
for PR 86756. Those are regressions and apparently a problem that
could affect user code, not just broken test cases for half-baked n
On Wed, Jan 23, 2019 at 03:34:04PM -0500, Jason Merrill wrote:
> On Wed, Jan 23, 2019 at 12:57 PM Marek Polacek wrote:
> >
> > On Wed, Jan 23, 2019 at 09:00:36AM -0500, Jason Merrill wrote:
> > > I was talking about digest_init, not reshape_init. digest_init calls
> > > convert_for_initialization
On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
>
> I just tripped over a segfault in libbacktrace. We apply strrchr to a
> possibly NULL filename, with predictable results when it is.
>
> elf.c:3044 passes NULL as the filename parm:
> ret = elf_add (state, NULL, d, base_address,
All,
My original patch for this PR simply fixed an ICE, which
then allowed the code to compile. In reality, an alternate
return is not ISO C interoperable, so an error message is
a more appropriate response. So, I re-opened the PR.
The attached patch has been tested on x86_64-*-freebsd.
OK to c
On Thu, Jan 24, 2019 at 05:16:52PM -0500, Jason Merrill wrote:
> > --- libcpp/expr.c.jj2019-01-01 12:38:16.132007335 +0100
> > +++ libcpp/expr.c 2019-01-24 14:07:10.080774120 +0100
> > @@ -2238,7 +2238,9 @@ parse_has_include (cpp_reader *pfile, en
> > XDELETEVEC (fname);
> >
On Wed, Jan 23, 2019 at 11:41:55PM +, Joseph Myers wrote:
> On Wed, 23 Jan 2019, Martin Sebor wrote:
>
> > Ping: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00969.html
>
> This patch is OK.
Note, the testcase FAILs on i686-linux:
+FAIL: gcc.dg/Wbuiltin-declaration-mismatch-7.c (test for w
On 1/24/19 8:18 AM, Jakub Jelinek wrote:
> On Thu, Jan 24, 2019 at 06:39:22AM +, Bernd Edlinger wrote:
>> --- gcc/c-family/c-warn.c(revision 268195)
>> +++ gcc/c-family/c-warn.c(working copy)
>> @@ -2725,14 +2725,18 @@ static tree
>> check_address_or_pointer_of_packed_member (tree type
Hi Steve,
That's OK. Thanks
Paul
On Fri, 25 Jan 2019 at 01:50, Steve Kargl
wrote:
>
> All,
>
> My original patch for this PR simply fixed an ICE, which
> then allowed the code to compile. In reality, an alternate
> return is not ISO C interoperable, so an error message is
> a more appropriate
63 matches
Mail list logo
