Hi!
On Fri, Sep 07, 2018 at 04:27:34PM -0500, Will Schmidt wrote:
> The expected instructions for this test (p8-vec-xl-*) were incorrect for some
> of the power targets. Add codegen variations as appropriate for
> the targeted platform.
> pr86952/testsuite
I think you need to write this a
Hi,
The expected instructions for this test (p8-vec-xl-*) were incorrect for some
of the power targets. Add codegen variations as appropriate for
the targeted platform.
Tested across power platforms. This appears to now run clean.
OK for trunk?
Thanks
-Will
[testsuite]
2018-09
Hi,
Update the fold-vec-splat-* tests to match current codegen results.
Due to codegen variations across assorted P7,p8,p9 targets, I've split
the -char test out into additional .p8 and .p9 versions with the common
parts contained in a .h included file. The assorted scan-assembly stanzas
for t
Now that we have RANGE_FOR_INIT_STMT we should handle it in cxx_pretty_printer.
I don't actually know how to trigger it but it seems straightforward to add.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-09-07 Marek Polacek
* cxx-pretty-print.c (cxx_pretty_printer::stateme
On Fri, Sep 7, 2018 at 4:37 PM Bernhard Reutner-Fischer <
rep.dot@gmail.com> wrote:
> Janne,
>
> On Mon, 27 Nov 2017 at 20:57, Thomas Koenig wrote:
> >
> > Hi Janne,
> >
> > > PING
> >
> > Looks good for trunk. Thanks!
>
> AFAICS this removed the last user of
>
> static void
> init_unsigned_
Running make check-c++-all I noticed some more failures, mostly caused by me.
Tested on x86_64-linux, ok for trunk?
2018-09-07 Marek Polacek
* c-c++-common/array-init.c: Add dg-error.
* g++.dg/cpp0x/lambda/lambda-const-this.C: Add dg-warning.
* g++.dg/cpp0x/lambda/lamb
On 09/07/18 15:36, Bernd Edlinger wrote:
> On 09/07/18 08:51, Bernd Edlinger wrote:
>> On 09/07/18 00:26, Jeff Law wrote:
>>> On 09/06/2018 04:16 PM, Jeff Law wrote:
On 09/06/2018 04:01 PM, Jeff Law wrote:
> On 09/06/2018 11:12 AM, Bernd Edlinger wrote:
>
>>>
>>
>> Ah, than
I realized that I was not checking the Debug implementations.
Doing so also have the advantage to show clearly which overload of the
algos is being used. If it is using the correct Debug overload I
consider that there are chances that it is also using the correct normal
overload. This is easie
Hi Richard,
Here's the updated patch and some comments inline below.
An example sequence is:
.cfi_startproc
mov x15, sp
cntbx16, all, mul #11
add x16, x16, 304
.cfi_def_cfa_register 15
.SVLPSRL0:
cmp x16, 65536
b.lt.BRRC
Hi Richard,
The 08/28/2018 21:58, Richard Sandiford wrote:
> Tamar Christina writes:
> > + HOST_WIDE_INT guard_used_by_caller = STACK_CLASH_CALLER_GUARD;
> > + /* When doing the final adjustment for the outgoing argument size we
> > can't
> > + assume that LR was saved at position 0. So s
Hello!
Attached patch rewrites float patterns. When disabled by
X87_ENABLE_FLOAT macro, generic expanders are able to correctly use
wider FPmode patterns and float truncation sequence, so there is no
need to do the same functionality manually in the expander.
The patch also re-enables floatdi2_i3
My recent changes regarding narrowing conversions removed the "inside {}"
part of the diagnostic, so this test needs to be updated.
Tested x86_64-linux, applying to trunk.
2018-09-07 Marek Polacek
* g++.dg/cpp1z/direct-enum-init1.C: Remove "inside" from diagnostic
messages.
d
On Fri, Sep 07, 2018 at 01:40:53PM +0100, Jason Merrill wrote:
> > 2018-08-13 Marek Polacek
> >
> > PR c++/57891
> > * call.c (struct conversion): Add check_narrowing_const_only.
> > (build_converted_constant_expr): Set check_narrowing and
> > check_narrowing_cons
On Fri, Sep 07, 2018 at 12:04:47PM +0100, Jason Merrill wrote:
> I finally found the recent discussion I mentioned earlier:
>
> http://lists.isocpp.org/core/2018/06/4562.php
>
> which hasn't made it into the issues list yet.
>
> This discussion seems to suggest that the standard is likely to cha
Janne,
On Mon, 27 Nov 2017 at 20:57, Thomas Koenig wrote:
>
> Hi Janne,
>
> > PING
>
> Looks good for trunk. Thanks!
AFAICS this removed the last user of
static void
init_unsigned_integer
which manifests itself as
../../../../../src/gcc-9.0.mine/libgfortran/runtime/environ.c:104:1:
warning: ‘
On 09/07/18 08:51, Bernd Edlinger wrote:
> On 09/07/18 00:26, Jeff Law wrote:
>> On 09/06/2018 04:16 PM, Jeff Law wrote:
>>> On 09/06/2018 04:01 PM, Jeff Law wrote:
On 09/06/2018 11:12 AM, Bernd Edlinger wrote:
>>
>
> Ah, thanks a lot.
>
> Okay, this is the status of t
Heads
Due too -Wabi empty class std::intergal_constant warning compiling
libstdc++/c++/cxx11-shim_facets.cc
Graham
On Mon, Aug 13, 2018 at 11:24 PM, Marek Polacek wrote:
> On Mon, Aug 13, 2018 at 10:14:21PM +1200, Jason Merrill wrote:
>> >> >> > --- gcc/cp/decl.c
>> >> >> > +++ gcc/cp/decl.c
>> >> >> > @@ -9581,7 +9581,7 @@ compute_array_index_type (tree name, tree
>> >> >> > size, tsubst_flags_t complain)
>>
OK
On Fri, Sep 7, 2018 at 4:29 AM, Marek Polacek wrote:
> Turned out our range-based for loops with initializer are completely broken
> in templates, because I neglected to add the init-statement to RANGE_FOR_STMT.
> range-for18.C should verify we put it into the right scope.
>
> tsubst_expr then
On 06.09.2018 10:41, Robin Dapp wrote:
>
> Similar to zEC12, the change in latencies helps match the real machine's
> behavior better.
>
> --
>
> gcc/ChangeLog:
>
> 2018-09-06 Robin Dapp
>
> * config/s390/2964.md: Increase latencies for some FP instructions.
Ok, thanks!
Andreas
On 06.09.2018 10:41, Robin Dapp wrote:
>
> Hi,
>
> this patch increases the latency of some floating point instructions to better
> match the real machine's behavior.
>
> Regards
> Robin
>
> --
>
> gcc/ChangeLog:
>
> 2018-09-06 Robin Dapp
>
> * config/s390/2827.md: Increase latenci
I finally found the recent discussion I mentioned earlier:
http://lists.isocpp.org/core/2018/06/4562.php
which hasn't made it into the issues list yet.
This discussion seems to suggest that the standard is likely to change
to allow this example and 87109, so fixing G++ to reject them may not
be
Turning on --enable-gather-detailed-mem-stats was producing for me a
compiler that crashed before main() because initializing the
hash_table sem_item::m_type_hash_cache was trying to add to
hash_table_usage before the latter had been initialized. This patch
fixes this by changing hash_table_usage
Semi obvious patch here...
As the comment for alloca_type_and_limit says:
// For ALLOCA_BOUND_MAYBE_LARGE and ALLOCA_BOUND_DEFINITELY_LARGE
// types, this field indicates the assumed limit if known or
// integer_zero_node if unknown. For any other alloca types, this
// field is undefine
On Wed, 5 Sep 2018 at 20:57, Janne Blomqvist wrote:
>
> On Wed, Sep 5, 2018 at 5:58 PM Bernhard Reutner-Fischer
> wrote:
>> Bootstrapped and regtested on x86_64-foo-linux.
>>
>> I'd appreciate if someone could double check for regressions on other
>> setups. Git branch:
>> https://gcc.gnu.org/g
25 matches
Mail list logo
