On Fri, May 31, 2019 at 9:30 AM Martin Sebor wrote:
>
> On 5/31/19 10:12 AM, Sean Gillespie wrote:
> > On Thu, May 30, 2019 at 4:28 PM Martin Sebor wrote:
> >>
> >> On 5/28/19 3:30 PM, Sean Gillespie wrote:
> >>> This adds a new warning, -Wglobal-constructors, that warns whenever a
> >>> decl req
Revising previous version of this patch to pick another missed
uglification.
>From 543d6be586ad8c29ef0ceefd55a249c715bd2480 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Fri, 31 May 2019 13:28:32 -0700
Subject: [PATCH] Clean up non-conforming names
* include/pstl/algorithm_impl.h (__para
On 05/29/2019 12:15 AM, Richard Biener wrote:
Of course. We are merely discussing of where the triggering of processing
starts: debug hooks, or something like:
dwarf2out_early_finish() {
...
if (ctf)
ctf_emit();
}
(and then in addition if the current DWARF info would be the so
Tested on Linux-PPC64, acked by Jason on irc. Applying to trunk
on Saturday.
2019-06-01 Ville Voutilainen
gcc/cp
PR c++/85254
* class.c (fixup_type_variants): Handle CLASSTYPE_FINAL.
testsuite/
PR c++/85254
* g++.dg/ext/is_final.C: Amend.
diff --git a/gcc/cp/class.
On Sat, 1 Jun 2019 at 01:24, Ed Smith-Rowland via libstdc++
wrote:
>
> Greetings,
>
> Iterators for and are usabe in a constexpr context
> since C++2017.
>
> This just adds a compile test to make sure and check a box for C++20
> p0858 - ConstexprIterator requirements.
Those tests don't use the
hoard.org is a bit strange in that https is broken (certificate
problem), so switch that back to plain http.
Committed.
Gerald
2019-05-31 Gerald Pfeifer
* doc/xml/manual/allocator.xml: Move hoard.org back to http.
Index: doc/xml/manual/allocator.xml
Greetings,
Iterators for and are usabe in a constexpr context
since C++2017.
This just adds a compile test to make sure and check a box for C++20
p0858 - ConstexprIterator requirements.
Ed
2019-06-03 Edward Smith-Rowland <3dw...@verizon.net>
Test for C++20 p0858 - ConstexprIt
On 5/30/19 10:38 AM, Wilco Dijkstra wrote:
> Fix the alignment option parser to always allow up to 4 alignments.
> Now -falign-functions=16:8:8:8 no longer reports an error.
>
> OK for commit (and backport to GCC9)?
>
> ChangeLog:
> 2019-05-30 Wilco Dijkstra
>
>
> PR driver/90684
>
On 5/30/19 2:53 AM, Hongtao Liu wrote:
> On Thu, May 30, 2019 at 3:23 AM Jeff Law wrote:
>> On 5/9/19 10:54 PM, Hongtao Liu wrote:
>>> On Fri, May 10, 2019 at 3:55 AM Jeff Law wrote:
On 5/6/19 11:38 PM, Hongtao Liu wrote:
> Hi Uros and GCC:
> This patch is to fix ix86_expand_sse_co
On 5/22/19 3:13 AM, Martin Liška wrote:
> On 5/21/19 1:51 PM, Richard Biener wrote:
>> On Tue, May 21, 2019 at 1:02 PM Martin Liška wrote:
>>>
>>> On 5/21/19 11:38 AM, Richard Biener wrote:
On Tue, May 21, 2019 at 12:07 AM Jeff Law wrote:
>
> On 5/13/19 1:41 AM, Martin Liška wrote:
>
Hi!
The following patch adds lastprivate(conditional:) support for simd
construct (at least when not combined with worksharing construct, that will
be done incrementally).
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2019-05-31 Jakub Jelinek
* tree.h (OM
On 5/22/19 12:13 AM, Dragan Mladjenovic wrote:
> Hi all,
>
> This patch makes the behavior of __builtin_msa_ fmadd/fmsub/maddv match the
> expected one. While not a recent regression, it would be nice if this can
> be back-ported in order to minimize the fragmentation.
>
> Best regards,
>
> Drag
This libgo patch drops unused C type reflection code. In particular,
it drops __go_type_descriptors_equal, which is no longer used, and
will be made obsolete by https://golang.org/cl/179598. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofro
On 5/28/19 11:26 AM, Wilco Dijkstra wrote:
> Improve the fix for PR64242. Various optimizations can change a memory
> reference
> into a frame access. Given there are multiple virtual frame pointers which
> may
> be replaced by multiple hard frame pointers, there are no checks for writes
> to
This patch to the Go frontend by Cherry Zhang optimizes calling append
with a second argument of a call to make. The gc compiler recognizes
append(s, make([]T, n)...), and generates code to directly zero the
tail instead of allocating a new slice and copying. This patch lets
the Go frontend do ba
On 5/31/19 1:56 PM, Martin Sebor wrote:
> Given a poiner to array p, tree dumps for expressions like &(*p)[2]
> actually show &*p[2]. That's not right -- the parentheses are
> important to differentiate indexing into the array the pointer
> points to from indexing into the pointer.
>
> The attach
On 5/22/19 3:34 PM, Martin Sebor wrote:
> -Wreturn-local-addr detects a subset of instances of returning
> the address of a local object from a function but the warning
> doesn't try to handle alloca or VLAs, or some non-trivial cases
> of ordinary automatic variables[1].
>
> The attached patch ex
* include/pstl/algorithm_impl.h (__parallel_set_union_op):
Uglfiy copy_range1 and copy_range2
* include/pstl/parallel_backend_tbb.h (struct __binary_no_op):
Rename parameter _T to _Tp.
---
libstdc++-v3/include/pstl/algorithm_impl.h | 16
lib
On Fri, May 31, 2019 at 1:38 AM Richard Biener wrote:
>
> On Thu, 30 May 2019, Alex Henrie wrote:
>
> > In Wine we need a way to (without warnings) put ms_hook_prologue into
> > a macro that is applied to functions, function pointers, and function
> > pointer typedefs. It sounds like you're saying
This patch to the Go frontend by Cherry Zhang fixes int-to-string
conversion with large integer constants.
Currently, the type conversion code thinks the int-to-string
conversion is constant if the integer operand is constant, but it
actually generates a call to runtime.intstring if the integer do
Given a poiner to array p, tree dumps for expressions like &(*p)[2]
actually show &*p[2]. That's not right -- the parentheses are
important to differentiate indexing into the array the pointer
points to from indexing into the pointer.
The attached patch adjusts the tree pretty printer to add the
On 1/11/19 1:10 PM, Martin Sebor wrote:
> The attached patch extends the detection of references to static
> variables in inline functions to the function signatures, including
> their return type. Since the declaration of a function need not be
> yet available at the time the static is referenced
On 05/24/2019 02:26 AM, Richard Biener wrote:
Currently, it does look like CTF for possibly to-be-omitted symbols will be
generated... I assume even DWARF needs to handle this case. Can you point me to
how DWARF does this ?
It emits the debug information. DWARF outputs a representation of th
On 31/05/19 17:18 +0200, Jonas Jelten wrote:
On 31/05/2019 16.38, Jonathan Wakely wrote:
On 31/05/19 15:35 +0200, Jonas Jelten wrote:
Hi!
I'm trying to build the x86_64-w64-mingw64 crosscompiler on gentoo.
It breaks because a fixincludes-fix is applied at a place where it should not
be applie
another ping
On 12/05/2019 17:57, Harald van Dijk wrote:
ping again
On 26/04/2019 19:58, Harald van Dijk wrote:
ping
On 13/04/2019 10:01, Harald van Dijk wrote:
Hi,
For PR60531, GCC wrongly rejects function templates with explicitly
specified template arguments as overloaded. They are resol
Alejandro Martinez Vicente writes:
> Hi,
>
> This patch fixes bug 90681. It was caused by trying to SLP vectorize a non
> grouped load. We've fixed it by tweaking a bit the implementation: mark
> masked loads as not vectorizable, but support them as an special case. Then
> the detect them in th
On 2/25/19 6:13 PM, luo...@linux.ibm.com wrote:
> From: Xiong Hu Luo
>
> dfp printf/scanf of Ha/HA, Da/DA and DDa/DDA is not set properly, cause
> incorrect warning happens:
> "use of 'D' length modifier with 'a' type character".
>
> Regression-tested on powerpc64le-linux, OK for trunk and gcc-8
On 5/23/19 4:26 PM, Joseph Myers wrote:
> On Tue, 21 May 2019, Jeff Law wrote:
>
>> On 5/20/19 6:56 PM, luoxhu wrote:
>>> Ping for GCC-10.
>> I thought this was a NAK in its current form.
>>
>> See Ryan's c#1 in the BZ.
>
> I don't see that as relevant to this bug report.
>
> That comment is abo
On 5/30/19 2:50 PM, Michael Forney wrote:
> VLAs are optional in C11, and an implementation that does not support
> them will define __STDC_NO_VLA__ to 1.
>
> 2019-05-30 Michael Forney
>
> * cp-demangle.c: Don't define CP_DYNAMIC_ARRAYS if __STDC_NO_VLA__
> is non-zero.
THanks. I'
On 5/31/19 9:56 AM, Martin Sebor wrote:
> On 5/30/19 5:49 PM, Jeff Law wrote:
>> So in several places there's a comment which indicates that debugging
>> dumps and the like do not follow conventions. Presumably you've tried
>> to keep a narrow scope on the diagnostic push/pops. I'm also concerned
On Fri, May 31, 2019 at 10:43 AM Jakub Jelinek wrote:
>
> On Fri, May 31, 2019 at 09:53:42AM -0700, H.J. Lu wrote:
> > 2019-05-31 H.J. Lu
> > Hongtao Liu
> >
> > gcc/
> >
> > PR target/89355
> > * config/i386/i386.c (ix86_init_large_pic_reg): Don't set
> > LABEL_PR
This libgo patch by Cherry Zhang implements cheaper goroutine context
switches on x86_64 GNU/Linux.
Currently, goroutine switches are implemented with libc
getcontext/setcontext functions, which saves/restores the machine
register states and also the signal context. This does more than what
we ne
On Fri, May 31, 2019 at 09:53:42AM -0700, H.J. Lu wrote:
> 2019-05-31 H.J. Lu
> Hongtao Liu
>
> gcc/
>
> PR target/89355
> * config/i386/i386.c (ix86_init_large_pic_reg): Don't set
> LABEL_PRESERVE_P.
Why this change? It is both not needed and undesirable, the
l
I discovered we could occasionally create TYPE_DECLs with
error_mark_node type, and then successfully push them into the symbol table!
I don't think we should be doing this -- it means TREE_TYPE of a
TYPE_DECL might not be a type, with resulting ICE fallout. (When we
cons up a VAR_DECL to cop
On Tue, May 21, 2019 at 2:43 PM H.J. Lu wrote:
>
> On Fri, Feb 22, 2019 at 8:25 AM H.J. Lu wrote:
> >
> > Hi Jan, Uros,
> >
> > This patch fixes the wrong code bug:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229
> >
> > Tested on AVX2 and AVX512 with and without --with-arch=native.
>
On Tue, May 28, 2019 at 10:33 AM Jeff Law wrote:
>
> On 5/28/19 9:48 AM, Jakub Jelinek wrote:
> > On Tue, May 28, 2019 at 08:30:59AM -0700, H.J. Lu wrote:
> >>> We shouldn't generate ENDBR in that case, nothing can goto to bar
> >>> (otherwise
> >>> it would remain a normal label, not a deleted l
Hi,
This patch fixes bug 90681. It was caused by trying to SLP vectorize a non
grouped load. We've fixed it by tweaking a bit the implementation: mark
masked loads as not vectorizable, but support them as an special case. Then
the detect them in the test for normal non-grouped loads that was al
On 5/31/19 10:12 AM, Sean Gillespie wrote:
On Thu, May 30, 2019 at 4:28 PM Martin Sebor wrote:
On 5/28/19 3:30 PM, Sean Gillespie wrote:
This adds a new warning, -Wglobal-constructors, that warns whenever a
decl requires a global constructor or destructor. This new warning fires
whenever a th
Hans-Peter Nilsson writes:
> On Tue, 14 May 2019, Richard Sandiford wrote:
>> Several SVE patterns need define_insn_and_splits that generate the
>> same insn_code, but with different operands. That's probably a
>> niche requirement, but it's cropping up often enough on the ACLE
>> branch that I t
On Fri, May 31, 2019 at 06:25:03PM +0200, Jakub Jelinek wrote:
> On Fri, May 31, 2019 at 12:16:58PM -0400, Marek Polacek wrote:
> > > The warning is not meant to diagnose these. But I do agree that the
> > > documentation for the new warning should be improved.
> >
> > I was partially wrong: if i
On Fri, May 31, 2019 at 12:16:58PM -0400, Marek Polacek wrote:
> > The warning is not meant to diagnose these. But I do agree that the
> > documentation for the new warning should be improved.
>
> I was partially wrong: if i/j are at file scope, then the warning triggers.
> But if i/j are in a fu
On Fri, May 31, 2019 at 11:50:47AM -0400, Marek Polacek wrote:
> On Thu, May 30, 2019 at 05:28:47PM -0600, Martin Sebor wrote:
> > On 5/28/19 3:30 PM, Sean Gillespie wrote:
> > > This adds a new warning, -Wglobal-constructors, that warns whenever a
> > > decl requires a global constructor or destru
On Thu, May 30, 2019 at 4:28 PM Martin Sebor wrote:
>
> On 5/28/19 3:30 PM, Sean Gillespie wrote:
> > This adds a new warning, -Wglobal-constructors, that warns whenever a
> > decl requires a global constructor or destructor. This new warning fires
> > whenever a thread_local or global variable is
> Hmm, ISTR we had such mitigations in place (or have) elsewhere keying
> on the most significant bit set instead of power-of-two.
fold_plusminus_mult_expr only factors out for power-of-two:
if (exact_log2 (absu_hwi (int11)) > 0 && int01 % int11 == 0
/* The remainder should not be
Hi Steve,
> I have no objection to the change but could the commit message and/or
> comments be expanded to explain the ':12' part of this value. I
> couldn't find an explanation for it in the code and I don't understand
> what it does.
See
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.ht
On 5/30/19 5:49 PM, Jeff Law wrote:
On 5/22/19 10:34 AM, Martin Sebor wrote:
Incorporating the feedback I got on the -Wformat-diag checker
provided an opportunity to tighten up existing and implement
a small number of few additional rules based on GCC Coding
Conventions (https://gcc.gnu.org/codi
Sure. No problem. Thanks for looking at this.
Aldy
On Fri, May 31, 2019, 17:48 Marc Glisse wrote:
> On Fri, 31 May 2019, Aldy Hernandez wrote:
>
> > I've never been too happy with the too large due to cast warnings. For
> that
> > matter, it seems like a lot of the unbounded alloca warning vari
On Thu, May 30, 2019 at 05:28:47PM -0600, Martin Sebor wrote:
> On 5/28/19 3:30 PM, Sean Gillespie wrote:
> > This adds a new warning, -Wglobal-constructors, that warns whenever a
> > decl requires a global constructor or destructor. This new warning fires
> > whenever a thread_local or global vari
On Fri, 31 May 2019, Aldy Hernandez wrote:
I've never been too happy with the too large due to cast warnings. For that
matter, it seems like a lot of the unbounded alloca warning variants were
artifacts of the way we couldn't get precise ranges after vrp asserts had
disappeared and we were tryin
On 5/30/19 4:56 PM, Martin Sebor wrote:
> On 5/30/19 10:15 AM, Jeff Law wrote:
>> On 5/30/19 9:34 AM, Martin Sebor wrote:
>>
> If the alias oracle can be used to give the same results without
> excessive false positives then I think it would be fine to make
> use of it. Is that somethi
On Fri, 2019-05-31 at 11:52 +, Wilco Dijkstra wrote:
> With -mcpu=generic the function alignment is currently 8, however almost all
> supported cores prefer 16 or higher, so increase the default to 16:12.
> This gives ~0.2% performance increase on SPECINT2017, while codesize is 0.12%
> larger.
On 31/05/2019 16.38, Jonathan Wakely wrote:
> On 31/05/19 15:35 +0200, Jonas Jelten wrote:
>> Hi!
>>
>> I'm trying to build the x86_64-w64-mingw64 crosscompiler on gentoo.
>> It breaks because a fixincludes-fix is applied at a place where it should
>> not be applied.
>>
>> This broke the cross-gcc
On 5/31/19 1:24 AM, Richard Biener wrote:
> On Thu, 30 May 2019, Jeff Law wrote:
>
>> On 5/30/19 12:41 AM, Richard Biener wrote:
>>> On May 29, 2019 10:18:01 PM GMT+02:00, Jeff Law wrote:
On 5/23/19 6:11 AM, Richard Biener wrote:
> On Thu, 23 May 2019, Jiufu Guo wrote:
>
>> Hi,
>
* include/std/tuple (tuple<>): Add noexcept to allocator-extended
constructors.
(tuple::__nothrow_default_constructible()): New helper
function.
(tuple::tuple(), explicit tuple::tuple()): Use helper.
Tested powerpc64le-linux, committed to trunk.
commit d09
On 5/31/19 3:00 AM, Richard Biener wrote:
> On Fri, May 31, 2019 at 2:27 AM Jeff Law wrote:
>>
>> On 5/29/19 10:20 AM, Aldy Hernandez wrote:
>>> On 5/29/19 12:12 PM, Jeff Law wrote:
On 5/29/19 9:58 AM, Aldy Hernandez wrote:
> On 5/29/19 9:24 AM, Richard Biener wrote:
>> On Wed, May 29
On 5/31/19 3:23 AM, Martin Liška wrote:
> Hi.
>
> With the patch one can see more info during debugging:
>
> (gdb) pp
> 6)>
> 5 [11.0% (guessed)] count:105119324 (estimated locally)
> (FALLTHRU,CAN_FALLTHRU,LOOP_EXIT)
>
> Ready for trunk?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-05-3
On 31/05/19 15:35 +0200, Jonas Jelten wrote:
Hi!
I'm trying to build the x86_64-w64-mingw64 crosscompiler on gentoo.
It breaks because a fixincludes-fix is applied at a place where it should not
be applied.
This broke the cross-gcc build for gcc-8.3.0 and 9.1.0 with error messages that
made i
On 31/05/19 11:36 +0100, Jonathan Wakely wrote:
On 29/05/19 21:00 +0100, Jonathan Wakely wrote:
These using-declarations appear to have been added for simplicity when
moving the non-standard extensions from namespace std to namespace
__gnu_cxx. Dumping all these names into namespace __gnu_cxx al
Hi.
I've been working on an overhaul of IPA ICF and I noticed that issue.
Looks to me obvious.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-05-31 Martin Liska
* fold-const.c (operand_equal_p): Fix
Hi!
I'm trying to build the x86_64-w64-mingw64 crosscompiler on gentoo.
It breaks because a fixincludes-fix is applied at a place where it should not
be applied.
This broke the cross-gcc build for gcc-8.3.0 and 9.1.0 with error messages that
made it tricky to figure out what was
really going o
Lambda types have names that are anonymous for all intents and purposes,
but sometimes need to be distinguished from other unnamed types. We
currently create lambda names specially. This patch changes that to use
the anon-name machinery, and then set another spare bit on that
identifier to ma
On 5/31/19 2:50 PM, Richard Biener wrote:
> On Wed, May 22, 2019 at 11:13 AM Martin Liška wrote:
>>
>> On 5/21/19 1:51 PM, Richard Biener wrote:
>>> On Tue, May 21, 2019 at 1:02 PM Martin Liška wrote:
On 5/21/19 11:38 AM, Richard Biener wrote:
> On Tue, May 21, 2019 at 12:07 AM Jeff
On Wed, May 22, 2019 at 11:13 AM Martin Liška wrote:
>
> On 5/21/19 1:51 PM, Richard Biener wrote:
> > On Tue, May 21, 2019 at 1:02 PM Martin Liška wrote:
> >>
> >> On 5/21/19 11:38 AM, Richard Biener wrote:
> >>> On Tue, May 21, 2019 at 12:07 AM Jeff Law wrote:
>
> On 5/13/19 1:41 AM,
> > +/* Return true if TYPE is a composite type (i.e. we may apply one of
> > handled
> > + components on it). */
> > +
> > +static bool
> > +access_patch_may_continue_p (tree type)
>
> 'path', but I think type_has_components_p would be a better fit?
Thanks, looks better indeed!
>
> > +{
> >
On Wed, 29 May 2019, Jan Hubicka wrote:
> Hi,
> this is a variant of testcase I have comitted. Once Martin implements SRA
> part, we could add next variant that drops -fno-tree-sra.
>
> It seems odd that constant propagation only happens in fre3.
> I woud expect fre1 to discover this already.
> T
With -mcpu=generic the function alignment is currently 8, however almost all
supported cores prefer 16 or higher, so increase the default to 16:12.
This gives ~0.2% performance increase on SPECINT2017, while codesize is 0.12%
larger.
ChangeLog:
2019-05-31 Wilco Dijkstra
* config/aarch6
Re https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00903.html
On 15/10/18 22:46 +0200, François Dumont wrote:
I started considering PR libstdc++/68303.
First thing was to write a dedicated performance test case, it is the
unordered_small_size.cc I'd like to add with this patch.
Great, more pe
On Wed, 29 May 2019, Jakub Jelinek wrote:
> On Wed, May 29, 2019 at 09:57:50AM -0600, Jeff Law wrote:
> > > FAIL: gcc.dg/builtin-object-size-1.c execution test
> > > FAIL: gcc.dg/builtin-object-size-5.c scan-assembler-not abort
>
> I admit I haven't looked at the details here, but wonder if the o
On Fri, May 31, 2019 at 11:56 AM Eric Botcazou wrote:
>
> Hi,
>
> this is a regression present for 32-bit targets on mainline and 9 branch only,
> but the underlying issue dates back from the removal of the TYPE_IS_SIZETYPE
> machinery. Since the removal of this machinery, there is an internal co
On Fri, 31 May 2019, Jakub Jelinek wrote:
> On Fri, May 31, 2019 at 11:43:29AM +0200, Richard Biener wrote:
> > Hmm. Is it enough to set TREE_THIS_NOTRAP on the ARRAY_REF instead?
>
> That works too.
>
> > At least it's documented the ARRAY_REF then isn't the issue.
> > As for conditional vs. u
On Fri, 31 May 2019, Jan Hubicka wrote:
> Hi
> in most common cases we have access paths that ends by read/write of a
> non-composite type. When aliasing_component_refs_p finds no match in
> the acccess path it asks alias oracle if the one alias set is subset of
> other to figure out whether one
On 27/05/19 22:11 +0200, François Dumont wrote:
I had miss some occurences of __bucket_hint to replace with
__bucket_count_hint so here is a new version.
Ok to commit with the simple ChangeLog entry below ?
OK for trunk, thanks.
On 29/05/19 21:00 +0100, Jonathan Wakely wrote:
These using-declarations appear to have been added for simplicity when
moving the non-standard extensions from namespace std to namespace
__gnu_cxx. Dumping all these names into namespace __gnu_cxx allows
uses like __gnu_cxx::size_t and __gnu_cxx::p
Make these functions restore the default handlers when passed a null
pointer. This is consistent with std::pmr::set_default_resource(0), and
also matches the current behaviour of libc++.
In order to avoid duplicating the preprocessor condition from
eh_term_handler.cc more that into a new eh_term_
On 31/05/19 08:58 +0300, Antony Polukhin wrote:
On Thu, May 30, 2019, 19:38 Jonathan Wakely wrote:
<...>
I've attached a relative diff, to be applied on top of yours, with my
suggested tweaks. Do you see any issues with it?
(If you're happy with those tweaks I can go ahead and apply this,
the
On 31/05/19 10:47 +0100, Jonathan Wakely wrote:
On 31/05/19 10:46 +0100, Jonathan Wakely wrote:
On 31/05/19 09:26 +, Szabolcs Nagy wrote:
On 29/05/2019 23:03, Jonathan Wakely wrote:
This fixes a test that started to fail in mingw.
Tested x86_64-linux, powerpc64le-linux and x86_64-w64-ming
Hi.
One obvious pretty printer change.
Martin
gcc/ChangeLog:
2019-05-31 Martin Liska
* gdbhooks.py: Add const_tree to TreePrinter.
---
gcc/gdbhooks.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
index 7b1a7be0002..39f5c4772
On Fri, May 31, 2019 at 11:43:29AM +0200, Richard Biener wrote:
> Hmm. Is it enough to set TREE_THIS_NOTRAP on the ARRAY_REF instead?
That works too.
> At least it's documented the ARRAY_REF then isn't the issue.
> As for conditional vs. unconditional I'm not so sure but automatic
> vars are exc
Hi,
this is a regression present for 32-bit targets on mainline and 9 branch only,
but the underlying issue dates back from the removal of the TYPE_IS_SIZETYPE
machinery. Since the removal of this machinery, there is an internal conflict
for sizetype: it's an unsigned type so with wrap-around
On 31/05/19 10:46 +0100, Jonathan Wakely wrote:
On 31/05/19 09:26 +, Szabolcs Nagy wrote:
On 29/05/2019 23:03, Jonathan Wakely wrote:
This fixes a test that started to fail in mingw.
Tested x86_64-linux, powerpc64le-linux and x86_64-w64-ming32.
Committed to trunk.
note that the updated
On 31/05/19 09:26 +, Szabolcs Nagy wrote:
On 29/05/2019 23:03, Jonathan Wakely wrote:
This fixes a test that started to fail in mingw.
Tested x86_64-linux, powerpc64le-linux and x86_64-w64-ming32.
Committed to trunk.
note that the updated test fails on baremetal
FAIL: 26_numerics/random
>
> * gcc.dg/lto/alias-access-path-2.0.c: New testcase.
>
> * tree-ssa-alias.c (aliasing_component_refs_p): Do not give up
> immediately after same_types_for_tbaa_p returns -1 and continue
> looking for possible exact match; if matching types are arrays
> watch for p
Hi
in most common cases we have access paths that ends by read/write of a
non-composite type. When aliasing_component_refs_p finds no match in
the acccess path it asks alias oracle if the one alias set is subset of
other to figure out whether one access path can be extended to the
other.
This is
On Fri, 31 May 2019, Jakub Jelinek wrote:
> Hi!
>
> As a preparation for lastprivate(conditional:) on #pragma omp simd, I need
> if-conversion to handle "omp simd array" accesses. These are safe, no
> matter whether written or read, each simd lane accesses their own element,
> after the vectoriz
Kugan Vivekanandarajah writes:
> @@ -609,8 +615,14 @@ vect_set_loop_masks_directly (struct loop *loop,
> loop_vec_info loop_vinfo,
>
>/* Get the mask value for the next iteration of the loop. */
>next_mask = make_temp_ssa_name (mask_type, NULL, "next_mask");
> - gcall *cal
Hi!
As a preparation for lastprivate(conditional:) on #pragma omp simd, I need
if-conversion to handle "omp simd array" accesses. These are safe, no
matter whether written or read, each simd lane accesses their own element,
after the vectorization it is all just a single vector read or store or R
On 29/05/2019 23:03, Jonathan Wakely wrote:
> This fixes a test that started to fail in mingw.
>
> Tested x86_64-linux, powerpc64le-linux and x86_64-w64-ming32.
>
> Committed to trunk.
note that the updated test fails on baremetal
FAIL: 26_numerics/random/random_device/cons/token.cc execution t
Hi.
With the patch one can see more info during debugging:
(gdb) pp
6)>
5 [11.0% (guessed)] count:105119324 (estimated locally)
(FALLTHRU,CAN_FALLTHRU,LOOP_EXIT)
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2019-05-31 Martin Liska
* cfg.c (debug): Use TDF_DETAILS for debug an
Hi,
noticed this typo: we are passing the location to build_nt as third
argument instead of passing it to cp_expr as second argument. Tested
x86_64-linux.
By the way, we have the option of using build_min_nt_loc instead of
build_nt in all these places for BIT_NOT_EXPR in
cp_parser_unqualifi
On Fri, May 31, 2019 at 10:39 AM Thomas De Schampheleire
wrote:
>
>
>
> On Fri, May 31, 2019, 10:23 Richard Biener wrote:
>>
>> On Wed, May 29, 2019 at 12:10 PM Thomas De Schampheleire
>> wrote:
>> >
>> > Hi Richard,
>>
>> Sorry for the delay - I have bootstrapped/tested the patch and
>> install
Thanks. I will adjust accordingly.
On Fri, May 31, 2019, 02:26 Martin Sebor wrote:
> On 5/30/19 12:58 AM, Aldy Hernandez wrote:
> > Hi.
> >
> > We have zero_p in the API, but we don't have non_zero_p. Instead we use
> > a non-API function range_is_nonnull. I've fixed this.
> >
> > I have also
I've never been too happy with the too large due to cast warnings. For that
matter, it seems like a lot of the unbounded alloca warning variants were
artifacts of the way we couldn't get precise ranges after vrp asserts had
disappeared and we were trying to guess at what the actual range in the
ori
On Fri, May 31, 2019 at 2:27 AM Jeff Law wrote:
>
> On 5/29/19 10:20 AM, Aldy Hernandez wrote:
> > On 5/29/19 12:12 PM, Jeff Law wrote:
> >> On 5/29/19 9:58 AM, Aldy Hernandez wrote:
> >>> On 5/29/19 9:24 AM, Richard Biener wrote:
> On Wed, May 29, 2019 at 2:18 PM Aldy Hernandez
> wrote
On Thu, May 30, 2019 at 10:46 PM David Malcolm wrote:
>
> On Thu, 2019-05-30 at 11:23 -0500, Qing Zhao wrote:
> > Hi,
> >
> > PR 90581 (provide an option to adjust the maximum depth of nested
> > #include)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
> >
> > is to add a new cpp option -f
On Wed, May 29, 2019 at 11:28 PM Marc Glisse wrote:
>
> On Mon, 20 May 2019, Richard Biener wrote:
>
> > On Mon, May 20, 2019 at 10:16 AM Marc Glisse wrote:
> >>
> >> On Mon, 20 May 2019, Richard Biener wrote:
> >>
> >>> On Sun, May 19, 2019 at 6:16 PM Marc Glisse wrote:
>
> Hello,
> >
On Fri, May 31, 2019, 10:23 Richard Biener
wrote:
> On Wed, May 29, 2019 at 12:10 PM Thomas De Schampheleire
> wrote:
> >
> > Hi Richard,
>
> Sorry for the delay - I have bootstrapped/tested the patch and
> installed it on trunk.
> If there will be no complaints I plan to backport it for GCC 9.2
On Thu, May 30, 2019 at 12:02 AM Marc Glisse wrote:
>
> On Mon, 20 May 2019, Richard Biener wrote:
>
> > On Sun, May 19, 2019 at 6:22 PM Marc Glisse wrote:
> >>
> >> Hello,
> >>
> >> I noticed this one with BIT_NOT_EXPR a while ago. C++ testcase because I
> >> haven't looked at gimplefe yet...
>
On Wed, May 29, 2019 at 12:10 PM Thomas De Schampheleire
wrote:
>
> Hi Richard,
Sorry for the delay - I have bootstrapped/tested the patch and
installed it on trunk.
If there will be no complaints I plan to backport it for GCC 9.2 (you
may need to
remind me in a few weeks).
Thanks again,
Richard
On Thu, 30 May 2019, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on the trunk, because both gsi_split_seq_after
> and gsi_insert_seq_after have assertions that the split is not after
> gsi_end_p iterator or insertion is not after such an iterator.
>
> My understanding of Alex' cha
On Thu, 30 May 2019, Alex Henrie wrote:
> On Thu, May 30, 2019 at 6:59 PM Joseph Myers wrote:
> >
> > On Thu, 30 May 2019, Alex Henrie wrote:
> >
> > > At this point I think I'm convinced that any attribute that applies to
> > > a function should also be allowed on a function pointer without any
1 - 100 of 105 matches
Mail list logo
