On Mon, 2 Jul 2018, Richard Sandiford wrote:
> Richard Biener writes:
> > On Fri, 22 Jun 2018, David Malcolm wrote:
> >
> >> NightStrike and I were chatting on IRC last week about
> >> issues with trying to vectorize the following code:
> >>
> >> #include
> >> std::size_t f(std::vector> const &
Hi!
This testcase got fixed in G++ 3.2, where we used for decision if inline
function body should be kept TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (...)),
but we now use cgraph and the testcase fails again; the particular problem
is that we set TREE_USED only on the local extern decl and don't
On Mon, Jul 2, 2018 at 7:00 PM David Malcolm wrote:
>
> On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote:
> > On Fri, 29 Jun 2018 at 10:09, Richard Biener > com> wrote:
> > >
> > > On Tue, Jun 26, 2018 at 5:43 PM David Malcolm
> > > wrote:
> > > >
> > > > This patch adds a concept of nes
Hi!
While working on OpenMP range-for support, I ran into the weird thing that
the C++ FE accepts
for (auto &i : a)
if (i != *__for_begin || &i == __for_end || &__for_range[0] != &a[0])
__builtin_abort ();
outside of templates, but doesn't inside of templates.
I think we shouldn't let
r262275 allowed pattern matching on pattern statements. Testing for
SVE on more benchmarks showed a case where this interacted badly
with 14/n.
The new over-widening detection could narrow a COND_EXPR A to another
COND_EXPR B, which mixed_size_cond could then match. This was working
as expected.
The PR85694 series removed the only cases in which a pattern recogniser
could attach patterns to more than one statement. I think it would be
better to avoid adding any new instances of that, since it interferes
with the normal matching order.
This patch therefore switches the interface back to p
Various recognisers set PATTERN_DEF_SEQ to null before adding
statements to it, but it should always be null at that point anyway.
This patch asserts for that in vect_pattern_recog_1 and removes
the redundant code.
Tested on aarch64-linux-gnu, arm-linux-gnueabihf and x86_64-linux-gnu.
OK to instal
The PR85694 series added a vectype argument to append_pattern_def_seq.
This patch makes more callers use it.
Tested on aarch64-linux-gnu, arm-linux-gnueabihf and x86_64-linux-gnu.
OK to install?
Richard
2018-07-03 Richard Sandiford
gcc/
* tree-vect-patterns.c (vect_recog_rotate_patt
On 06/29/2018 09:04 PM, Jeff Law wrote:
> I think this is fine for the trunk.
>
> jeff
Thank you Jeff.
I found some issues when doing build of all targets (contrib/config-list.mk).
I'll update patch and test that affected cross-compilers still produce same
output.
However I noticed one ppc64 i
On 03/07/18 07:47 +0200, François Dumont wrote:
Here is the updated patch.
* include/bits/stl_algobase.h (__niter_wrap): New.
(__copy_move_a2(_II, _II, _OI)): Use latter.
(__copy_move_backward_a2(_BI1, _BI1, _BI2)): Likewise.
(fill_n(_OI, _Size, const _Tp&)): Likewise.
(equal
On 07/02/2018 10:16 AM, Jakub Jelinek wrote:
> On Mon, Jul 02, 2018 at 09:44:04AM +0200, Richard Biener wrote:
>> Given the array has size i + 1 it's upper bound should be 'i' and 'i'
>> should be available via DW_OP_[GNU_]entry_value.
>>
>> I see it is
>>
>> <175> DW_AT_upper_bound : 10 byte
On 07/02/2018 07:08 AM, Christophe Lyon wrote:
On 11/07/2017 10:33 AM, Aldy Hernandez wrote:
While poking around in the backwards threader I noticed that we bail if
we have already seen a starting BB.
/* Do not jump-thread twice from the same block. */
if (bitmap_bit_p (thread
On Tue, Jul 3, 2018 at 9:49 AM Jakub Jelinek wrote:
>
> Hi!
>
> While working on OpenMP range-for support, I ran into the weird thing that
> the C++ FE accepts
> for (auto &i : a)
> if (i != *__for_begin || &i == __for_end || &__for_range[0] != &a[0])
> __builtin_abort ();
> outside of
On Tue, Jul 3, 2018 at 10:02 AM Richard Sandiford
wrote:
>
> r262275 allowed pattern matching on pattern statements. Testing for
> SVE on more benchmarks showed a case where this interacted badly
> with 14/n.
>
> The new over-widening detection could narrow a COND_EXPR A to another
> COND_EXPR B,
On Tue, Jul 3, 2018 at 10:06 AM Richard Sandiford
wrote:
>
> The PR85694 series removed the only cases in which a pattern recogniser
> could attach patterns to more than one statement. I think it would be
> better to avoid adding any new instances of that, since it interferes
> with the normal ma
On Tue, Jul 3, 2018 at 10:10 AM Richard Sandiford
wrote:
>
> Various recognisers set PATTERN_DEF_SEQ to null before adding
> statements to it, but it should always be null at that point anyway.
> This patch asserts for that in vect_pattern_recog_1 and removes
> the redundant code.
>
> Tested on aa
On Tue, Jul 3, 2018 at 10:11 AM Richard Sandiford
wrote:
>
> The PR85694 series added a vectype argument to append_pattern_def_seq.
> This patch makes more callers use it.
>
> Tested on aarch64-linux-gnu, arm-linux-gnueabihf and x86_64-linux-gnu.
> OK to install?
OK.
Richard.
> Richard
>
>
> 20
On 16/05/18 13:53 +0200, Martin Liška wrote:
On 12/21/2017 10:13 AM, Martin Liška wrote:
On 12/20/2017 06:45 PM, Jakub Jelinek wrote:
Another thing is that the "/" in there is wrong, so
const char dir_separator_str[] = { DIR_SEPARATOR, '\0' };
char *b = concat (profile_data_prefix, dir_sepa
On Tue, Jul 03, 2018 at 11:34:51AM +0200, Richard Biener wrote:
> Can we make them DECL_ARTIFICIAL and/or make name-lookup never
They are DECL_ARTIFICIAL already.
> lookup DECL_ARTIFICIAL vars instead?
Not sure about that, will try to gather some statistics on how often we
rely on name-lookup of
On Tue, Jul 03, 2018 at 10:53:20AM +0200, Martin Liška wrote:
> On 06/29/2018 09:04 PM, Jeff Law wrote:
> > I think this is fine for the trunk.
> >
> > jeff
>
> Thank you Jeff.
>
> I found some issues when doing build of all targets (contrib/config-list.mk).
> I'll update patch and test that aff
On Tue, Jul 3, 2018 at 11:43 AM Jakub Jelinek wrote:
>
> On Tue, Jul 03, 2018 at 11:34:51AM +0200, Richard Biener wrote:
> > Can we make them DECL_ARTIFICIAL and/or make name-lookup never
>
> They are DECL_ARTIFICIAL already.
>
> > lookup DECL_ARTIFICIAL vars instead?
>
> Not sure about that, will
On 29/06/18 11:13, David Malcolm wrote:
> On Fri, 2018-06-29 at 10:15 +0200, Richard Biener wrote:
>> On Fri, 22 Jun 2018, Jan Hubicka wrote:
>>
>>> Hi,
>>> this patch adds dumpfile support for dumps that come in multiple
>>> parts. This
>>> is needed for WPA stream-out dump since we stream partit
Richard Biener writes:
> On Fri, Jun 29, 2018 at 1:36 PM Richard Sandiford
> wrote:
>>
>> Richard Sandiford writes:
>> > This patch is the main part of PR85694. The aim is to recognise at least:
>> >
>> > signed char *a, *b, *c;
>> > ...
>> > for (int i = 0; i < 2048; i++)
>> > c[i] =
On 07/03/2018 11:55 AM, Segher Boessenkool wrote:
> On Tue, Jul 03, 2018 at 10:53:20AM +0200, Martin Liška wrote:
>> On 06/29/2018 09:04 PM, Jeff Law wrote:
>>> I think this is fine for the trunk.
>>>
>>> jeff
>>
>> Thank you Jeff.
>>
>> I found some issues when doing build of all targets (contrib/
On Tue, Jul 03, 2018 at 12:15:48PM +0200, Martin Liška wrote:
> > toplev.c already has (in init_alignments):
> >
> > if (align_jumps_max_skip > align_jumps)
> > align_jumps_max_skip = align_jumps - 1;
>
> I'm rewriting this logic in the patch set. Issue is that
> checking for value of alig
The target has been removed, so we shouldn't try to build it.
Segher
2018-07-03 Segher Boessenkool
* contrib/config-list.mk: Remove powerpc-linux_paired.
---
contrib/config-list.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/config-list.mk b/contrib
On Tue, Jul 03, 2018 at 11:58:31AM +0200, Richard Biener wrote:
> On Tue, Jul 3, 2018 at 11:43 AM Jakub Jelinek wrote:
> >
> > On Tue, Jul 03, 2018 at 11:34:51AM +0200, Richard Biener wrote:
> > > Can we make them DECL_ARTIFICIAL and/or make name-lookup never
> >
> > They are DECL_ARTIFICIAL alrea
On Tue, Jul 03, 2018 at 01:24:28PM +0200, Jakub Jelinek wrote:
> On Tue, Jul 03, 2018 at 11:58:31AM +0200, Richard Biener wrote:
> > On Tue, Jul 3, 2018 at 11:43 AM Jakub Jelinek wrote:
> > >
> > > On Tue, Jul 03, 2018 at 11:34:51AM +0200, Richard Biener wrote:
> > > > Can we make them DECL_ARTIFI
Hi.
It caused UBSAN errors:
$ cat ubsan.i
int a;
void d() { int c, b = 8 - a; }
$ /home/marxin/Programming/gcc2/objdir/./gcc/xgcc
-B/home/marxin/Programming/gcc2/objdir/./gcc/ ubsan.i -c -O2
../../gcc/tree-vrp.c:1715:26: runtime error: load of value 255, which is not a
valid value for type 'bo
On 07/03/2018 12:58 PM, Segher Boessenkool wrote:
> On Tue, Jul 03, 2018 at 12:15:48PM +0200, Martin Liška wrote:
>>> toplev.c already has (in init_alignments):
>>>
>>> if (align_jumps_max_skip > align_jumps)
>>> align_jumps_max_skip = align_jumps - 1;
>>
>> I'm rewriting this logic in the pa
On Tue, Jul 03, 2018 at 02:51:27PM +0200, Martin Liška wrote:
> On 07/03/2018 12:58 PM, Segher Boessenkool wrote:
> > On Tue, Jul 03, 2018 at 12:15:48PM +0200, Martin Liška wrote:
> >>> toplev.c already has (in init_alignments):
> >>>
> >>> if (align_jumps_max_skip > align_jumps)
> >>> align_
On 07/03/2018 08:15 AM, Jakub Jelinek wrote:
And it isn't limited to that, omp_priv/omp_orig/omp_in/omp_out too (the
OpenMP UDR artifical vars), also variables captured in lambdas,
anon union fields, ...
So I'm afraid it is not possible to ignore DECL_ARTIFICIAL VAR_DECLs in name
lookup and gene
This PR complains about bogus -Wsign-conversion warning even with an
explicit static_cast. It started with this hunk from the delayed folding
merge:
@@ -5028,20 +5022,12 @@ cp_build_binary_op (location_t location,
if (short_compare)
{
- /* Don't write &op0, etc., because that wou
could a global reviewer comment? This touches a lot of target-specific
config files. David has kindly checked AIX is ok, the known target
needing the functionality.
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01568.html
nathan
On 06/25/2018 12:48 PM, Nathan Sidwell wrote:
NO_IMPLICIT_EXTE
On Tue, 2018-07-03 at 09:37 +0200, Richard Biener wrote:
> On Mon, Jul 2, 2018 at 7:00 PM David Malcolm
> wrote:
> >
> > On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote:
> > > On Fri, 29 Jun 2018 at 10:09, Richard Biener > > ail.
> > > com> wrote:
> > > >
> > > > On Tue, Jun 26, 2018 a
On Tue, Jul 3, 2018 at 3:52 PM David Malcolm wrote:
>
> On Tue, 2018-07-03 at 09:37 +0200, Richard Biener wrote:
> > On Mon, Jul 2, 2018 at 7:00 PM David Malcolm
> > wrote:
> > >
> > > On Mon, 2018-07-02 at 14:23 +0200, Christophe Lyon wrote:
> > > > On Fri, 29 Jun 2018 at 10:09, Richard Biener
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
>From 52aad98947e5cfcb5624ff24f0c557d0029c34fe Mon Sep 17 00:00:00 2001
From: Richard Guenther
Date: Tue, 3 Jul 2018 14:04:01 +0200
Subject: [PATCH] fix-pr86389
2018-07-03 Richard Biener
PR ipa/86389
*
Another batch of cleanups/consolidations.
First, the move patterns. This consolidates the movXX expanders -- this
can slightly change the generated code on the H8/SX due to an
inconsistency in the old movhi expander that is fixed by this change.
The expanders for logicals and basic arithmetic w
On Fri, Jun 29, 2018 at 04:24:58AM -0500, Richard Sandiford wrote:
> This patch adds AArch64 patterns for the new AVG_FLOOR/CEIL operations.
> AVG_FLOOR is [SU]HADD and AVG_CEIL is [SU]RHADD.
>
> Tested on aarch64-linux-gnu (with and without SVE). OK to install?
OK.
Thanks,
James
> 2018-06-29
On Tue, 2018-07-03 at 15:53 +0200, Richard Biener wrote:
> On Tue, Jul 3, 2018 at 3:52 PM David Malcolm
> wrote:
> >
> > On Tue, 2018-07-03 at 09:37 +0200, Richard Biener wrote:
> > > On Mon, Jul 2, 2018 at 7:00 PM David Malcolm > > >
> > > wrote:
> > > >
> > > > On Mon, 2018-07-02 at 14:23 +0200
On Tue, Jul 3, 2018 at 4:10 PM David Malcolm wrote:
>
> On Tue, 2018-07-03 at 15:53 +0200, Richard Biener wrote:
> > On Tue, Jul 3, 2018 at 3:52 PM David Malcolm
> > wrote:
> > >
> > > On Tue, 2018-07-03 at 09:37 +0200, Richard Biener wrote:
> > > > On Mon, Jul 2, 2018 at 7:00 PM David Malcolm >
This patch merely adds a test for an already fixed issue.
Tested on x86_64-linux, ok for trunk?
2018-07-03 Marek Polacek
PR c++/84306
* g++.dg/overload/conv-op3.C: New test.
diff --git gcc/testsuite/g++.dg/overload/conv-op3.C
gcc/testsuite/g++.dg/overload/conv-op3.C
index e6
On Tue, 2018-07-03 at 11:00 +0100, Andre Vieira (lists) wrote:
> On 29/06/18 11:13, David Malcolm wrote:
> > On Fri, 2018-06-29 at 10:15 +0200, Richard Biener wrote:
> > > On Fri, 22 Jun 2018, Jan Hubicka wrote:
> > >
> > > > Hi,
> > > > this patch adds dumpfile support for dumps that come in
> >
OK.
On Tue, Jul 3, 2018 at 10:14 AM, Marek Polacek wrote:
> This patch merely adds a test for an already fixed issue.
>
> Tested on x86_64-linux, ok for trunk?
>
> 2018-07-03 Marek Polacek
>
> PR c++/84306
> * g++.dg/overload/conv-op3.C: New test.
>
> diff --git gcc/testsuite/g
Hi Thomas,
> the attached patch is the third take on Nicolas' and my patch
> for implementing asynchronous I/O. Some parts have been reworked, and
> several bugs which caused either incorrect I/O or hangs have been
> fixed in the process.
>
> I have to say that getting out these bugs has been muc
Hi Thomas,
> another test run on i386-pc-solaris2.11 is underway. However, may
> (all?) gfortran tests now SEGV. One example is
the good news is: all three libgomp.fortran/async_io_?.f90 tests now
PASS for both 32 and 64-bit, as do gfortran.dg/f2003_inquire_1.f03 and
gfortran.dg/f2003_io_1.f03.
On Fri, Jun 8, 2018 at 3:27 AM, H.J. Lu wrote:
> On x86, swapcontext may return via indirect branch when shadow stack
> is enabled. To support code instrumentation of control-flow transfers
> with -fcf-protection, add indirect_return function attribute to inform
> compiler that a function may ret
This is an ICE of kind "Error reporting routines re-entered". From the PR:
The problem here is that we report the missing return value:
9224 permerror (input_location, "return-statement with no value, in "
9225"function returning %qT", valtype);
but permerror will en
On Tue, Jul 3, 2018 at 5:32 PM, H.J. Lu wrote:
> On Fri, Jun 8, 2018 at 3:27 AM, H.J. Lu wrote:
>> On x86, swapcontext may return via indirect branch when shadow stack
>> is enabled. To support code instrumentation of control-flow transfers
>> with -fcf-protection, add indirect_return function a
On 03/07/18 15:15, David Malcolm wrote:
> On Tue, 2018-07-03 at 11:00 +0100, Andre Vieira (lists) wrote:
>> On 29/06/18 11:13, David Malcolm wrote:
>>> On Fri, 2018-06-29 at 10:15 +0200, Richard Biener wrote:
On Fri, 22 Jun 2018, Jan Hubicka wrote:
> Hi,
> this patch adds dumpfile
This was a simple typo in strip_typedefs_expr, where we were iterating
but then building a new list consisting entirely of the first element.
Tested x86_64-pc-linux-gnu, applying to trunk, 8, 7.
commit 1cab1ce37320aac67d8fbf88d10930f5c769cfb1
Author: Jason Merrill
Date: Mon Jul 2 15:09:58 2018
OK.
On Tue, Jul 3, 2018 at 12:08 PM, Marek Polacek wrote:
> This is an ICE of kind "Error reporting routines re-entered". From the PR:
>
> The problem here is that we report the missing return value:
> 9224 permerror (input_location, "return-statement with no value, in "
> 9225
On Thu, Jun 28, 2018 at 5:39 AM, Paolo Carlini wrote:
> Hi,
>
> On 28/06/2018 03:22, David Malcolm wrote:
>>
>> [snip]
>>>
>>> If I'm following you right, the idea is that gcc should complain
>>> because two different things in the user's source code contradict
>>> each
>>> other.
>>>
>>> In such
On Fri, Jun 29, 2018 at 3:58 PM, Marek Polacek wrote:
> On Wed, Jun 27, 2018 at 07:35:15PM -0400, Jason Merrill wrote:
>> On Wed, Jun 27, 2018 at 12:53 PM, Marek Polacek wrote:
>> > This PR complains about us accepting invalid code like
>> >
>> > template struct A {};
>> > A<-1> a;
>> >
>> >
On Tue, Jul 3, 2018 at 9:12 AM, Uros Bizjak wrote:
> On Tue, Jul 3, 2018 at 5:32 PM, H.J. Lu wrote:
>> On Fri, Jun 8, 2018 at 3:27 AM, H.J. Lu wrote:
>>> On x86, swapcontext may return via indirect branch when shadow stack
>>> is enabled. To support code instrumentation of control-flow transfer
On Tue, Jun 19, 2018 at 09:09:27AM -0500, Tamar Christina wrote:
> Hi All,
OK.
Thanks,
James
> Thanks,
> Tamar
>
> gcc/
> 2018-06-19 Tamar Christina
>
> * config/aarch64/aarch64.c (aarch64_expand_movmem): Fix mode size.
>
> gcc/testsuite/
> 2018-06-19 Tamar Christina
>
>
Hi.
In order to make GCC 4.1 happy and build current tip, we need to define
static constants out of a class definition.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2018-07-03 Martin Liska
* tree-switch-conversion.h (struct jump_table_cluster): Define
constant values outs
Hi.
I'm sending fix for DOS-based system, it's a compilation error that
I introduced some time ago. Plus I add Jonathan's correction of a documentation
entry.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2018-07-03 Martin Liska
Jonathan Wakely
* coverage.c: Use corr
Hi.
As new option mangles absolute path of a compiled file, it's hard
to come up with a scan-file pattern. Note similar test is done in
gcc.dg/profile-dir-*.c that I adjusted few days ago.
Ready for trunk?
Thanks,
Martin
gcc/testsuite/ChangeLog:
2018-07-03 Martin Liska
* gcc.dg/pr4
On Tue, Jul 03, 2018 at 07:22:19PM +0200, Martin Liška wrote:
> In order to make GCC 4.1 happy and build current tip, we need to define
> static constants out of a class definition.
>
> Ready for trunk?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-03 Martin Liska
>
> * tree-switch
Hello!
Attached patch implements unsigned HImode and QImode vector average
instructions. This is all x86 has to offer...
2018-07-03 Uros Bizjak
PR target/85694
* config/i386/sse.md (uavg3_ceil): New expander.
(_uavg3): Simplify expander.
testsuite/ChangeLog:
2018-07-03 Uros Biz
Hi Rainer,
However, may
(all?) gfortran tests now SEGV. One example is
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
Segmentation Fault
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfe1b1f03
On 07/03/2018 08:16 AM, Martin Liška wrote:
Hi.
It caused UBSAN errors:
$ cat ubsan.i
int a;
void d() { int c, b = 8 - a; }
$ /home/marxin/Programming/gcc2/objdir/./gcc/xgcc
-B/home/marxin/Programming/gcc2/objdir/./gcc/ ubsan.i -c -O2
../../gcc/tree-vrp.c:1715:26: runtime error: load of val
Hi,
On 03/07/2018 18:36, Jason Merrill wrote:
if ((type_quals & TYPE_QUAL_VOLATILE)
- && (loc == UNKNOWN_LOCATION || locations[ds_volatile] < loc))
+ && (loc == UNKNOWN_LOCATION
+ || linemap_location_before_p (line_table,
+location
On Tue, Jul 03, 2018 at 12:40:51PM -0400, Jason Merrill wrote:
> On Fri, Jun 29, 2018 at 3:58 PM, Marek Polacek wrote:
> > On Wed, Jun 27, 2018 at 07:35:15PM -0400, Jason Merrill wrote:
> >> On Wed, Jun 27, 2018 at 12:53 PM, Marek Polacek wrote:
> >> > This PR complains about us accepting invalid
On 07/03/2018 10:53 AM, Martin Liška wrote:
Thank you Jeff.
I found some issues when doing build of all targets (contrib/config-list.mk).
I'll update patch and test that affected cross-compilers still produce same
output.
Hello.
I'm done with testing, I bootstrapped and regtested the patch o
On 06/13/2018 04:02 AM, Jeff Law wrote:
On 05/21/2018 07:55 AM, marxin wrote:
gcc/ChangeLog:
2017-04-18 Denys Vlasenko
* config/i386/i386-common.c (ix86_handle_option): Remove support
for obsolete -malign-loops, -malign-jumps and -malign-functions
options.
* config/i386
Another round.
This merges the movmd/movsd related patterns. Their primary difference
was normal vs advanced mode, so we can just use the P mode iterator and
significantly reduce duplication here.
This also merges two of the btst patterns and fixes the pattern's
condition. This also allows the
On Tue, Jul 3, 2018 at 2:58 PM, Marek Polacek wrote:
> On Tue, Jul 03, 2018 at 12:40:51PM -0400, Jason Merrill wrote:
>> On Fri, Jun 29, 2018 at 3:58 PM, Marek Polacek wrote:
>> > On Wed, Jun 27, 2018 at 07:35:15PM -0400, Jason Merrill wrote:
>> >> On Wed, Jun 27, 2018 at 12:53 PM, Marek Polacek
On Tue, 3 Jul 2018 at 12:02, Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Fri, Jun 29, 2018 at 1:36 PM Richard Sandiford
> > wrote:
> >>
> >> Richard Sandiford writes:
> >> > This patch is the main part of PR85694. The aim is to recognise at
> >> > least:
> >> >
> >> > signed
Hi
I plan to commit attached patch to fix the __gnu_debug::string
undefined macro.
Is it ok the way I used some tests to now validate
__gnu_debug::string on check-debug ?
François
diff --git a/libstdc++-v3/include/debug/string b/libstdc++-v3/include/debug/string
index 4aadf4c..963b
On 03/07/18 22:11 +0200, François Dumont wrote:
Hi
I plan to commit attached patch to fix the __gnu_debug::string
undefined macro.
Is it ok the way I used some tests to now validate
__gnu_debug::string on check-debug ?
Yes, good idea. We don't want to do that for *every* basic_stri
On Tue, Jul 3, 2018 at 3:41 PM, Jason Merrill wrote:
> On Tue, Jul 3, 2018 at 2:58 PM, Marek Polacek wrote:
>> On Tue, Jul 03, 2018 at 12:40:51PM -0400, Jason Merrill wrote:
>>> On Fri, Jun 29, 2018 at 3:58 PM, Marek Polacek wrote:
>>> > On Wed, Jun 27, 2018 at 07:35:15PM -0400, Jason Merrill wr
OK.
On Tue, Jul 3, 2018 at 2:37 PM, Paolo Carlini wrote:
> Hi,
>
> On 03/07/2018 18:36, Jason Merrill wrote:
>>
>>
>>> if ((type_quals & TYPE_QUAL_VOLATILE)
>>> - && (loc == UNKNOWN_LOCATION || locations[ds_volatile] < loc))
>>> + && (loc == UNKNOWN_LOCATION
>>> + || linema
On Tue, Jul 03, 2018 at 03:41:43PM -0400, Jason Merrill wrote:
> On Tue, Jul 3, 2018 at 2:58 PM, Marek Polacek wrote:
> > On Tue, Jul 03, 2018 at 12:40:51PM -0400, Jason Merrill wrote:
> >> On Fri, Jun 29, 2018 at 3:58 PM, Marek Polacek wrote:
> >> > On Wed, Jun 27, 2018 at 07:35:15PM -0400, Jaso
Hi Christophe,
> It seems the new bb-slp-over-widen tests lack a -fdump option:
> gcc.dg/vect/bb-slp-over-widen-2.c -flto -ffat-lto-objects : dump file
> does not exist
> UNRESOLVED: gcc.dg/vect/bb-slp-over-widen-2.c -flto -ffat-lto-objects
> scan-tree-dump-times vect "basic block vectorized" 2
i
On Tue, Jul 3, 2018 at 4:35 PM, Marek Polacek wrote:
> On Tue, Jul 03, 2018 at 03:41:43PM -0400, Jason Merrill wrote:
>> On Tue, Jul 3, 2018 at 2:58 PM, Marek Polacek wrote:
>> > On Tue, Jul 03, 2018 at 12:40:51PM -0400, Jason Merrill wrote:
>> >> On Fri, Jun 29, 2018 at 3:58 PM, Marek Polacek w
P0553R2 is not in the C++2a working draft yet, but is likely to be
approved soon. Neither proposal supports std::byte but this adds
overloads of each function for std::byte, assuming that will also get
added.
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate
The whole file is guarded by the same check already.
* include/bits/alloc_traits.h: Remove redundant preprocessor
condition.
Tested powerpc64le-linux, committed to trunk.
commit 76fd352d2bccd2a7399f6693cb5c7a8e9c65274b
Author: Jonathan Wakely
Date: Tue Jul 3 00:26:07 2018 +01
Segher:
On Mon, 2018-07-02 at 11:53 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Jun 29, 2018 at 07:38:39AM -0700, Carl Love wrote:
> > +;; Unpack high elements of float vector to vector of doubles
> > +(define_expand "altivec_unpackh_v4sf"
> > + [(set (match_operand:V2DF 0 "register_opera
On Tue, Jul 03, 2018 at 10:02:47PM +0100, Jonathan Wakely wrote:
> +#ifndef _GLIBCXX_BIT
> +#define _GLIBCXX_BIT 1
> +
> +#pragma GCC system_header
> +
> +#if __cplusplus >= 201402L
> +
> +#include
> +#include
> +
> +namespace std _GLIBCXX_VISIBILITY(default)
> +{
> +_GLIBCXX_BEGIN_NAMESPACE_VERS
On 03/07/18 23:40 +0200, Jakub Jelinek wrote:
On Tue, Jul 03, 2018 at 10:02:47PM +0100, Jonathan Wakely wrote:
+#ifndef _GLIBCXX_BIT
+#define _GLIBCXX_BIT 1
+
+#pragma GCC system_header
+
+#if __cplusplus >= 201402L
+
+#include
+#include
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBC
In computing the size of expected output for non-constant floating
arguments the sprintf pass doesn't consider the possibility that
the argument value may be not finite (i.e., it can be infinity or
NaN). Infinities and NaNs are formatted as "inf" or "infinity"
and "nan". As a result, any floatin
The pretty-printer formats NaNs simply as Nan, even though
there is much more to a NaN than than that. At the very
least, one might like to know if the NaN is signaling or
quiet, negative or positive. If it's not in a canonical
form, one might also be interested in the significand
and exponent p
On 07/03/2018 04:59 PM, Martin Sebor wrote:
> The pretty-printer formats NaNs simply as Nan, even though
> there is much more to a NaN than than that. At the very
> least, one might like to know if the NaN is signaling or
> quiet, negative or positive. If it's not in a canonical
> form, one might
On 07/03/2018 03:31 AM, Aldy Hernandez wrote:
> On 07/02/2018 07:08 AM, Christophe Lyon wrote:
>
On 11/07/2017 10:33 AM, Aldy Hernandez wrote:
> While poking around in the backwards threader I noticed that we bail if
>
> we have already seen a starting BB.
>
> /* D
On 07/03/2018 01:11 PM, Martin Liška wrote:
> On 07/03/2018 10:53 AM, Martin Liška wrote:
>> Thank you Jeff.
>>
>> I found some issues when doing build of all targets
>> (contrib/config-list.mk).
>> I'll update patch and test that affected cross-compilers still produce
>> same output.
>
> Hello.
>
So the H8 port has movmd and movsd instructions which are used to
implement block moves and stpcpy. Those expanders and patters are
necessarily fairly ugly, but not enough to warrant trying to simplify.
What is worth simplifying is the fact that we have two copies of each
pattern and splitter be
On 07/03/2018 04:50 PM, Martin Sebor wrote:
> In computing the size of expected output for non-constant floating
> arguments the sprintf pass doesn't consider the possibility that
> the argument value may be not finite (i.e., it can be infinity or
> NaN). Infinities and NaNs are formatted as "inf"
This patch consolidates the ior/xor expanders, patterns and splitters
using a code iterator.
This does make us a bit more lenient on what we accept for xor operands
than we were before. However, AFAICT xor should accept the same
operands as ior on all the supported H8 variants.
The additional l
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 06/24/2018 03:05 PM, Martin Sebor wrote:
Storing integer command line option arguments in type int
limits options such as -Wlarger-than= or -Walloca-larger-than
to at most INT_MAX (see bug 71905). Larger values wrap around
zero.
After consolidating HI and SI mode patterns for logical bit operators,
the remaining patterns "logical3_sn" "logical3" are in
effect identical.
This patch deletes logical3_sn.
This (not surprisingly) makes no difference in the generated code :-)
Installed on the trunk
Jeff
* config/h83
Committed to trunk in r86274. Jakub/Richard, can you please
also review and approve the corresponding fix for the release
branches?
Martin
On 07/03/2018 06:32 PM, Jeff Law wrote:
On 07/03/2018 04:50 PM, Martin Sebor wrote:
In computing the size of expected output for non-constant floating
arg
On 07/03/2018 11:24 AM, Martin Liška wrote:
> Hi.
>
> As new option mangles absolute path of a compiled file, it's hard
> to come up with a scan-file pattern. Note similar test is done in
> gcc.dg/profile-dir-*.c that I adjusted few days ago.
>
> Ready for trunk?
> Thanks,
> Martin
>
> gcc/tests
On 07/03/2018 11:23 AM, Martin Liška wrote:
> Hi.
>
> I'm sending fix for DOS-based system, it's a compilation error that
> I introduced some time ago. Plus I add Jonathan's correction of a
> documentation
> entry.
>
> Ready for trunk?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-03 Marti
On 06/29/2018 09:54 AM, Martin Sebor wrote:
>
> All the warnings I have seen are because of declarations like
> the one in the test below that checks for the presence of symbol
> sin in the library:
>
> char sin ();
> int main () { return sin (); }
>
> GCC has warned for this code by default
On 07/03/2018 10:53 AM, H.J. Lu wrote:
> On Tue, Jul 3, 2018 at 9:12 AM, Uros Bizjak wrote:
>> On Tue, Jul 3, 2018 at 5:32 PM, H.J. Lu wrote:
>>> On Fri, Jun 8, 2018 at 3:27 AM, H.J. Lu wrote:
On x86, swapcontext may return via indirect branch when shadow stack
is enabled. To support
On 07/03/2018 07:50 AM, Nathan Sidwell wrote:
> could a global reviewer comment? This touches a lot of target-specific
> config files. David has kindly checked AIX is ok, the known target
> needing the functionality.
>
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01568.html
So it's almost cer
On 05/23/2018 11:15 AM, Maxim Ostapenko wrote:
> Hi,
>
>
> as described in PR, when using both ASan and UBSan
> (-fsanitize=address,undefined ), we have symbols collision for global
> functions, like __sanitizer_set_report_path. This leads to fuzzy results
> when printing reports into files e.
99 matches
Mail list logo
