On 10/30/19 7:29 PM, Jakub Jelinek wrote:
On Tue, Oct 29, 2019 at 04:26:14PM -0400, Jason Merrill wrote:
I think type_initializer_zero_p should return false if
CLASSTYPE_NON_AGGREGATE; we can't expect that value-initialization will have
the intended effect in that case.
That indeed works for t
On 10/30/19 7:20 AM, Jeff Chapman wrote:
Hello,
Attached is a patch that adds parsing of the optional requires-clause in a
lambda-expression and lambda-declarator. Additionally, shorthand constraints
from the template-parameter-list are now actually applied and constrain the
synthesized operator
Segher Boessenkool writes:
> Hi!
>
> On Wed, Oct 30, 2019 at 11:34:42AM +0800, Jiufu Guo wrote:
>> In this patch, loop unroll adjust hook is introduced for powerpc. In this
>> hook,
>> we can do target related hueristic adjustment. For this patch, we tunned for
>> O2 to unroll small loops with s
Previously we would put the template arguments for the concept-check in a
TEMPLATE_ID and then also pass them to constraints_satisfied_p, which meant
that we would try to normalize the concept-check with the fully instantiated
arguments, leading to sadness. Simply not passing the args to
constrain
On Fri, Oct 25, 2019 at 10:40 AM Craig Blackmore
wrote:
> The sched2 pass undoes some of the addresses generated by the RISC-V
> shorten_memrefs code size optimization (patch 1/2) and consequently increases
> code size. This patch prevents sched-deps.c from changing an address if it is
> expected
FYI the testcase I'm using to test the patch. Some of the functions
get smaller, some of them get bigger, and some don't change in size
but should when compiled for an rv64 target.
Jim
void
store1z (int *array)
{
array[200] = 0;
array[201] = 0;
array[202] = 0;
array[203] = 0;
}
void
stor
On Fri, Oct 25, 2019 at 10:40 AM Craig Blackmore
wrote:
> This patch aims to allow more load/store instructions to be compressed by
> replacing a load/store of 'base register + large offset' with a new load/store
> of 'new base + small offset'. If the new base gets stored in a compressed
> registe
Playing with the PR92284 test case revealed two issues related to
gfc_desc_to_cfi_desc:
* Access of uninitialized memory – copying the array bounds (in
libgfortran) does not make sense for unallocted allocatables and
nullified pointers. Hence, check for ".data == NULL".
* There is a memory l
On Tue, Oct 29, 2019 at 04:26:14PM -0400, Jason Merrill wrote:
> I think type_initializer_zero_p should return false if
> CLASSTYPE_NON_AGGREGATE; we can't expect that value-initialization will have
> the intended effect in that case.
That indeed works for this testcase and doesn't break anything
Hi!
On Wed, Oct 30, 2019 at 02:02:44AM -0500, Xiong Hu Luo wrote:
> -finline-functions is enabled by default for O2 since r276469, update the
> test cases that inline small functions caused instruction number difference.
> --- a/gcc/testsuite/gcc.target/powerpc/pr79439-1.c
> +++ b/gcc/testsuite/g
On 10/30/19 4:06 PM, Joseph Myers wrote:
> On Wed, 30 Oct 2019, Joseph Myers wrote:
>
>> This appears to have broken the build for Arm.
>
> And probably bfin and c6x as well, based on grep, but my bot only covers
> glibc targets so doesn't test those.
>
bfin and c6x are definitely affected. My
Hi!
On Wed, Oct 30, 2019 at 11:34:42AM +0800, Jiufu Guo wrote:
> In this patch, loop unroll adjust hook is introduced for powerpc. In this
> hook,
> we can do target related hueristic adjustment. For this patch, we tunned for
> O2 to unroll small loops with small unroll factor (2 times), for othe
On Wed, 30 Oct 2019, Joseph Myers wrote:
> This appears to have broken the build for Arm.
And probably bfin and c6x as well, based on grep, but my bot only covers
glibc targets so doesn't test those.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, Oct 30, 2019 at 04:26:17PM -0400, Jason Merrill wrote:
> OK.
>
Thanks, committed.
> > Now, for the accepts invalid issues.
> > From what I unde
This appears to have broken the build for Arm.
/scratch/jmyers/glibc-bot/src/gcc/gcc/config/arm/arm.c: In function 'arm_pcs
arm_get_pcs_model(const_tree, const_tree)':
/scratch/jmyers/glibc-bot/src/gcc/gcc/config/arm/arm.c:5959:4: error:
'cgraph_local_info' was not declared in this scope
cgr
On Tue, Oct 29, 2019 at 11:57:40PM +0100, Jakub Jelinek wrote:
> On Tue, Oct 29, 2019 at 05:40:11PM -0500, Segher Boessenkool wrote:
> > On Tue, Oct 29, 2019 at 06:15:31PM +0100, Jakub Jelinek wrote:
> > There already are a lot of different ways to get information about the
> > execution environmen
On 10/24/19 7:47 AM, Jakub Jelinek wrote:
On Tue, Oct 22, 2019 at 10:57:42AM -0400, Jason Merrill wrote:
So, do you prefer to do it the other way during build_cxx_call?
It seems more straightforward.
I've tried this approach, but am running into issues:
1) the normal constructors aren't an i
Iain Sandoe wrote:
> Iain Sandoe wrote:
>
>> Martin Sebor wrote:
>>
>>> On 10/20/2019 07:27 AM, Iain Sandoe wrote:
Martin Sebor wrote:
> On 10/19/19 2:56 AM, Iain Sandoe wrote:
>> Andreas Schwab wrote:
>>> On Okt 19 2019, Iain Sandoe wrote:
>>>
This test has
On 10/24/19 5:11 AM, Jakub Jelinek wrote:
Hi!
Jonathan has showed me a testcase with std::allocator::{,de}allocate
and std::construct_at which FAILs with the current constexpr new
implementation.
There are two problems that make the testcase rejected, and further issues
(not addressed by this p
On 10/12/19 2:10 PM, Bernd Edlinger wrote:
On 10/11/19 6:31 PM, Jason Merrill wrote:
On 10/10/19 2:06 PM, Bernd Edlinger wrote:
On 10/10/19 7:49 PM, Jason Merrill wrote:
On 10/10/19 10:42 AM, Bernd Edlinger wrote:
Hi,
this fixes a crash when -Wshadow=compatible-local is
enabled in the testca
On October 30, 2019 7:16:43 PM GMT+01:00, "Andre Vieira (lists)"
wrote:
>Hi,
>
>In this patch I turn epilogue vectorization on by default for all
>targets. After some discussions I decided to take the following testing
>
>approach:
>
>1) I have disabled epilogue vectorization for all tests that
On 10/30/19 9:30 AM, Marek Polacek wrote:
On Wed, Oct 30, 2019 at 10:58:57AM +0100, Jakub Jelinek wrote:
On Fri, Oct 25, 2019 at 10:44:18AM -0400, Marek Polacek wrote:
That is... sneaky. I guess I/we need to test with
--enable-symvers=gnu-versioned-namespace every now and then.
Indeed.
Pro
A cleanup I noticed while working on operator<=>.
Tested x86_64-pc-linux-gnu, applying to trunk.
---
gcc/cp/cxx-pretty-print.c | 48 ++-
1 file changed, 2 insertions(+), 46 deletions(-)
diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index 2
> On Oct 30, 2019, at 2:24 PM, Jeff Law wrote:
>
> On 10/30/19 2:12 AM, Richard Biener wrote:
>> On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
>>
>> I think the wiki has better examples. That said, I wonder how much can
>> be automated here, for example when just considering CCmode (m6
Hi Tobias,
OK for the trunk and GCC 9?
As far as I can see, this looks good.
So, OK for trunk. If it later turns out that there are problems
caused by this, I suspect we will hear about them soon enough :-)
Thanks for taking this on!
Regards
Thomas
Hi!
On Wed, Oct 23, 2019 at 05:42:45PM +0800, Kewen.Lin wrote:
> Following the previous one 2/3, this patch is to update the
> vector conversions between fixed point and floating point
> with different element unit sizes, such as: SP <-> DI, DP <-> SI.
> (vsx_xvcvdp[su]xws): New define_expa
On 10/24/19 6:30 PM, Marek Polacek wrote:
I wasn't properly setting LOOKUP_CONSTINIT in grokfield and so we didn't
detect a non-const initializer.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK.
2019-10-24 Marek Polacek
PR c++/92134 - constinit malfunction in static dat
On 10/24/19 5:50 PM, Marek Polacek wrote:
I noticed that for code like
struct S {
int *foo : 3;
};
we generate nonsensical
r.C:2:8: error: function definition does not declare parameters
2 | int *foo : 3;
It talks about a function because after parsing the declspecs of
On 10/24/19 3:24 PM, Marek Polacek wrote:
When fixing c++/91889 (r276251) I was assuming that we couldn't have a ck_qual
under a ck_ref_bind, and I was introducing it in the patch and so this
+ if (next_conversion (convs)->kind == ck_qual)
+ {
+ gcc_assert (same_type_p (TREE_TYPE (exp
On 10/30/19 2:12 AM, Richard Biener wrote:
> On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
> I think the wiki has better examples. That said, I wonder how much can
> be automated here, for example when just considering CCmode (m68k has
> setcc IIRC) then for example all define_insns like
>
Hi,
In this patch I turn epilogue vectorization on by default for all
targets. After some discussions I decided to take the following testing
approach:
1) I have disabled epilogue vectorization for all tests that failed due
to scan-tree-dump failures inside:
- gcc.dg/vect
- gcc.target/i
On Wed, 30 Oct 2019, Alexandre Oliva wrote:
> On Oct 28, 2019, Joseph Myers wrote:
>
> > We have a test in the testsuite that all option help text consistently
> > ends with '.' (see gcc.misc-tests/help.exp). I'd have expected these
> > options, lacking that '.', to cause that test to fail.
>
On 10/30/19 11:57 AM, John Paul Adrian Glaubitz wrote:
> On 10/30/19 6:52 PM, Gunther Nikl wrote:
>> Richard Sandiford wrote:
>>> FWIW it's already possible to do the transform you mention with:
>>>
>>> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>>>
>>> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "relo
Hi!
On Wed, Oct 23, 2019 at 05:40:35PM +0800, Kewen.Lin wrote:
> For those fixed point <-> floating point vector conversion with
> same element unit size, such as: SP <-> SI, DP <-> DI, it's fine
> to use the existing RTL operations like any_fix/any_float for them.
>
> This patch is to update the
Hi!
On Wed, Oct 23, 2019 at 05:39:14PM +0800, Kewen.Lin wrote:
> I noticed that vsx_xvcdpsp and vsx_xvcvdpsp are almost the same,
> and vsx_xvcdpsp looks replaceable with vsx_xvcvdpsp since it's only
> called by gen_*.
Okay for trunk. Thanks!
Segher
> 2019-10-23 Kewen Lin
>
> * con
On 10/30/19 11:52 AM, Gunther Nikl wrote:
> Richard Sandiford wrote:
>> FWIW it's already possible to do the transform you mention with:
>>
>> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>>
>> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "reload_completed")])
>
> Since "reload_completed" is referenced,
On 10/30/19 6:52 PM, Gunther Nikl wrote:
> Richard Sandiford wrote:
>> FWIW it's already possible to do the transform you mention with:
>>
>> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>>
>> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "reload_completed")])
>
> Since "reload_completed" is referenced, t
Richard Sandiford wrote:
> FWIW it's already possible to do the transform you mention with:
>
> s/(cc0)/(reg:CC CC_REGNUM_RC)/g
>
> (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "reload_completed")])
Since "reload_completed" is referenced, this is only about the CC0
conversion, right? Switc
On 30/10/19 17:42 +, Jonathan Wakely wrote:
This combines two of the std::ranges::swap.operator() overloads into a
single function template. Using if-constexpr to choose between
implementations should give the compiler less work to do than using
overloading.
P.S. this is how all the other s
This combines two of the std::ranges::swap.operator() overloads into a
single function template. Using if-constexpr to choose between
implementations should give the compiler less work to do than using
overloading.
* include/std/concepts (std::ranges::swap): Use a single overload for
On 10/30/19 12:36 PM, Jakub Jelinek wrote:
On Wed, Oct 30, 2019 at 12:33:00PM -0400, Nathan Sidwell wrote:
As discussed on IRC, this adds an L suffix to C++ feature macros, as
specified by the std. I'd forgotten that in preprocessor-land, expressions
are evaluated as longs anyway, but the user
On 30/10/2019 14:48, Jakub Jelinek wrote:
> ARM is an OpenMP member, so if you want, you can participate too.
> https://github.com/OpenMP/spec/issues/2028
> is where I'm trying to track all the declare variant issues that need
> clarification (plus in two examples tickets).
it's unfortunate that n
On 30/10/19 15:47 +, Jonathan Wakely wrote:
This ensures that __normal_iterator satisfies the
contiguous_iterator concept, by defining the iterator_concept member
type.
Also update vector's iterators, reverse_iterator,
istreambuf_iterator and ostreambuf_iterator to meet the C++20
requirement
* include/std/bit (__cpp_lib_bitops): Define.
* include/std/version (__cpp_lib_constexpr): Remove.
(__cpp_lib_bitops, __cpp_lib_constexpr_dynamic_alloc): Define.
* testsuite/26_numerics/bit/header.cc: New test.
* testsuite/26_numerics/bit/header-2.cc: New te
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01830.html
Original patch (without the early exit optimization):
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01591.html
Thanks,
- Eddy B.
On Fri, Oct 25, 2019, at 3:44 PM, Eduard-Mihai Burtescu wrote:
> > This can be further optimized by usin
On Wed, Oct 30, 2019 at 12:33:00PM -0400, Nathan Sidwell wrote:
> As discussed on IRC, this adds an L suffix to C++ feature macros, as
> specified by the std. I'd forgotten that in preprocessor-land, expressions
> are evaluated as longs anyway, but the user might be trying to printf these
> consta
On 10/30/19 4:55 PM, Jakub Jelinek wrote:
Do they? At least the C/C++ FEs should complain/remove before it makes
its way into the middle-end. […]
Haven't checked the Fortran FE.
The Fortran FE lacks many checks the C/C++ FE has – but, admittedly, it
*does* have this check. (Which obviously do
As discussed on IRC, this adds an L suffix to C++ feature macros, as
specified by the std. I'd forgotten that in preprocessor-land,
expressions are evaluated as longs anyway, but the user might be trying
to printf these constants, or similar, where the type suffix is significant.
Jakub, Thoma
Richard Biener writes:
> On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford
> wrote:
>>
>> This is another patch in the series to remove the assumption that
>> all modes involved in vectorisation have to be the same size.
>> Rather than have the target provide a list of vector sizes,
>> it makes t
On Wed, Oct 30, 2019 at 04:48:43PM +0100, Tobias Burnus wrote:
> On 10/30/19 11:12 AM, Jakub Jelinek wrote:
> > I believe it is easier to handle it at the same spot as we do it e.g.
> > for C/C++ pointer attachments (where we create the same clauses
> > regardless of the exact construct and then dr
> Hi,
>
> On Wed, Oct 30 2019, Jan Hubicka wrote:
> >>
> >> Looking at PR 92278, I think I found the real problem. In
> >> ipa_read_edge_info, you added code to throw away jump functions of edges
> >> that do not pass possibly_call_in_translation_unit_p() test. But that
> >> predicate incorrectl
Hi,
On Wed, Oct 30 2019, Jan Hubicka wrote:
>>
>> Looking at PR 92278, I think I found the real problem. In
>> ipa_read_edge_info, you added code to throw away jump functions of edges
>> that do not pass possibly_call_in_translation_unit_p() test. But that
>> predicate incorrectly - or at least
On 01.10.2019. 21:35, Jeff Law wrote:
> On 9/6/19 4:23 AM, Dragan Mladjenovic wrote:
>> On 24.07.2019. 20:57, Jeff Law wrote:
>>> On 7/17/19 2:29 AM, Dragan Mladjenovic wrote:
On 09.07.2019. 23:21, Jeff Law wrote:
> On 7/9/19 2:06 PM, Dragan Mladjenovic wrote:
>> This patch
On 10/30/19 11:12 AM, Jakub Jelinek wrote:
I believe it is easier to handle it at the same spot as we do it e.g.
for C/C++ pointer attachments (where we create the same clauses
regardless of the exact construct and then drop them later), in
particular in gimplify_scan_omp_clauses. […]
I concu
This ensures that __normal_iterator satisfies the
contiguous_iterator concept, by defining the iterator_concept member
type.
Also update vector's iterators, reverse_iterator,
istreambuf_iterator and ostreambuf_iterator to meet the C++20
requirements.
PR libstdc++/92272
* include/
Similar to some recent patches, this removes using-declarations for
names from namespace std, so that they are not redeclared in __gnu_cxx.
* include/bits/stl_iterator.h (namespace __gnu_cxx): Remove
using-declarations for std::iterator and std::iterator_traits.
(__gnu_cxx
The attached test case (w/o optional and with "this") gave an ICE as
"*this" was passed to DECL_ARTIFICIAL and only "this" but not the
INDIRECT_REF is a declaration. [I added optional as those often act
slightly different, but it doesn't seem to make a difference here.]
Solution: If it is an I
On 30/10/2019 14:51, Richard Biener wrote:
> On Wed, 30 Oct 2019, Joel Hutton wrote:
>
>> On 30/10/2019 13:49, Richard Biener wrote:
>>> Why do you need this? The vectorizer already creates such CTORs. Any
>>> testcase that you can show?
>> typedef long v2di __attribute__((vector_size(16)));
>>
Hello Jeff,
I already have write access on this e-mail address (but not on
the @wavecomp.com address, which you have been putting
into ChangeLogs), so I guess I could commit any further patches
that get approved.
Regards,
Mihailo
Hi.
There's a small code refactoring.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
From dc92c8c3e31887b23ef419bc60e3c1607d0e9e53 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Wed, 30 Oct 2019 12:50:51 +0100
Subject: [PATCH] Com
On Wed, 30 Oct 2019, Joel Hutton wrote:
> On 30/10/2019 13:49, Richard Biener wrote:
> > Why do you need this? The vectorizer already creates such CTORs. Any
> > testcase that you can show?
>
> typedef long v2di __attribute__((vector_size(16)));
> v2di v;
> void
> foo()
> {
> v = (v2di){v[1]
On Wed, Oct 30, 2019 at 02:12:30PM +, Szabolcs Nagy wrote:
> On 29/10/2019 17:15, Jakub Jelinek wrote:
> > +void f03 (void);
> > +#pragma omp declare variant (f03) match
> > (device={kind(any),arch(x86_64),isa(avx512f,avx512bw)})
> > +void f04 (void);
>
> 1) it's not clear from the omp spec w
On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford
wrote:
>
> This is another patch in the series to remove the assumption that
> all modes involved in vectorisation have to be the same size.
> Rather than have the target provide a list of vector sizes,
> it makes the target provide a list of vecto
Same problem in the go frontend.
(gdb) r
Starting program: /opt/gcc/test/Build/gcc/go1
../../../libgo/go/sync/atomic/doc.go ../../../libgo/go/sync/atomic/value.go
-quiet -dumpbase doc.go -mlittle-endian -mabi=lp64 -auxbase-strip doc.o -g -O2
-fgo-pkgpath=sync/atomic -I . -L/opt/gcc/test/Build/.
On 29/10/19 17:15 +, Jonathan Wakely wrote:
* testsuite/util/testsuite_iterators.h (BoundsContainer::size()): Add
new member function.
(WritableObject::operator=): Constrain with enable_if when available.
(remove_cv): Use std::remove_if when available.
Hi Richard,
> Please don't add -fcommon in lto.exp.
So what is the best way to add an extra option to lto.exp?
Note dg-lto-options completely overrides the options from lto.exp, so I can't
use that except in tests which already use it.
Cheers,
Wilco
Hi again, now also CCing the mailing list,
On Wed, Oct 30 2019, Jan Hubicka wrote:
>> Hi,
>>
>> On Wed, Oct 30 2019, Jan Hubicka wrote:
>> > Hi,
>> > this patch fixes another place we may have missing argument summary.
>> > Here the situation is that the call site being inlined has no jump
>> >
On Fri, Oct 25, 2019 at 2:34 PM Richard Sandiford
wrote:
>
> The validation phase of vectorizable_shift used TYPE_MODE to check
> whether the shift amount vector was compatible with the shifted vector:
>
> if ((op1_vectype == NULL_TREE
>|| TYPE_MODE (op1_vectype) != TYPE_MODE (ve
On Fri, Oct 25, 2019 at 2:32 PM Richard Sandiford
wrote:
>
> Except for one case, get_vectype_for_scalar_type_and_size calculates
> what the vector mode should be and then calls build_vector_type,
> which recomputes the mode from scratch. This patch makes it use
> build_vector_type_for_mode inste
On Wed, Oct 30, 2019 at 10:43 AM Richard Sandiford
wrote:
>
> The series posted so far now shows how the hook would be used in practice.
> Just wanted to follow up on some points here:
>
> Richard Sandiford writes:
> > Richard Biener writes:
> >> On Wed, Oct 23, 2019 at 2:12 PM Richard Sandiford
On Wed, Oct 23, 2019 at 1:06 PM Richard Sandiford
wrote:
>
> mode_for_int_vector, like mode_for_vector, can sometimes return
> an integer mode or an unsupported vector mode. But no callers
> are interested in that case, and only want supported vector modes.
> This patch therefore replaces mode_fo
On Sun, Oct 20, 2019 at 3:29 PM Richard Sandiford
wrote:
>
> These 11 patches just pass vec_infos to one routine each. Splitting
> them up make it easier to write the changelogs, but they're so trivial
> that it seemed better to send them all in one message.
OK.
>
> Pass a vec_info to vect_supp
On Sun, Oct 20, 2019 at 3:23 PM Richard Sandiford
wrote:
>
> The increase_alignment pass was using get_vectype_for_scalar_type
> to get the preferred vector type for each array element type.
> This has the effect of carrying over the vector size chosen by
> the first successful call to all subsequ
On 30/10/2019 13:49, Richard Biener wrote:
> Why do you need this? The vectorizer already creates such CTORs. Any
> testcase that you can show?
typedef long v2di __attribute__((vector_size(16)));
v2di v;
void
foo()
{
v = (v2di){v[1], v[0]};
}
>> * tree-vect-slp.c (vect_analyze_slp
On 29/10/2019 17:15, Jakub Jelinek wrote:
> +void f03 (void);
> +#pragma omp declare variant (f03) match
> (device={kind(any),arch(x86_64),isa(avx512f,avx512bw)})
> +void f04 (void);
1) it's not clear from the omp spec what is the intended
syntax for isa-name, arch-name and extension-name, but
i
The D frontend is also broken.
(gdb) r
Starting program: /opt/gcc/test/Build/gcc/d21
../../../../libphobos/libdruntime/core/sys/posix/utime.d -quiet -dumpbase
utime.d -mlittle-endian -mabi=lp64 -auxbase-strip core/sys/posix/.libs/utime.o
-g -O2 -fPIC -fversion=Shared -iprefix
/opt/gcc/test/Bui
On Tue, Oct 29, 2019 at 1:33 PM Wilco Dijkstra wrote:
>
> v2: Tweak testsuite options to avoid failures
>
> GCC currently defaults to -fcommon. As discussed in the PR, this is an
> ancient
> C feature which is not conforming with the latest C standards. On many
> targets
> this means global va
On Wed, Oct 30, 2019 at 1:06 PM Martin Jambor wrote:
>
> Hi,
>
> On Wed, Oct 30 2019, Jan Hubicka wrote:
> > Hi,
> > this patch fixes another place we may have missing argument summary.
> > Here the situation is that the call site being inlined has no jump
> > functions while function which is bei
On Wed, Oct 30, 2019 at 10:30 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR92127 shows, recent commit r276645 enables more unrollings,
> two ppc vectorization cost model test cases are fragile and failed
> after the change. This patch is to disable unrolling for the
> loops of interest to make test cases
On Wed, Oct 30, 2019 at 9:50 AM Martin Liška wrote:
>
> Hello.
>
> Have you ever waited for a LTO compilation and were curious about
> the progress? If so, the patch offers a way to communicate that information
> to user via setprocessname. The process will reflect progress of ltrans
> compilation
On Wed, 30 Oct 2019, Jiufu Guo wrote:
> Hi,
>
> In this patch, loop unroll adjust hook is introduced for powerpc. In this
> hook,
> we can do target related hueristic adjustment. For this patch, we tunned for
> O2 to unroll small loops with small unroll factor (2 times), for other
> optimization
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-10-30 Richard Biener
PR tree-optimization/92275
* tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
Copy all loop-closed PHIs.
* gcc.dg/torture/pr92275.c: New testcase.
In
On Wed, 30 Oct 2019, Joel Hutton wrote:
> On 15/10/2019 13:11, Richard Biener wrote:
> >> > You miss to check that CONSTRUCTOR_NELTS == TYPE_VECTOR_SUBPARTS
> >> > (we can have omitted trailing zeros).
> >
> > ^^^
> >
> > I don't see this being handled? You give up on non-SSA names
> > b
On Wed, Oct 30, 2019 at 10:58:57AM +0100, Jakub Jelinek wrote:
> On Fri, Oct 25, 2019 at 10:44:18AM -0400, Marek Polacek wrote:
> > That is... sneaky. I guess I/we need to test with
> > --enable-symvers=gnu-versioned-namespace every now and then.
>
> Indeed.
>
> > Probably deserves a comment.
>
On 15/10/2019 13:11, Richard Biener wrote:
>> > You miss to check that CONSTRUCTOR_NELTS == TYPE_VECTOR_SUBPARTS
>> > (we can have omitted trailing zeros).
>
> ^^^
>
> I don't see this being handled? You give up on non-SSA names
> but not on the omitted trailing zeros.
I had thought chec
Hi!
While in C a constant expression can't start with
score(constant-integral-expression),
in C++11 it can and so we need to do tentative parsing or skipping to the
closing ) to check if there is : to find out if it is trait-score or just
part of a constant expression.
The following patch adds a
Hi,
On Wed, Oct 30 2019, Jan Hubicka wrote:
> Hi,
> this patch fixes another place we may have missing argument summary.
> Here the situation is that the call site being inlined has no jump
> functions while function which is being inlines has another call with
> jump function. This can validly h
Hi!
Just for posterity.
On 2019-04-20T23:22:31+0200, Iain Buclaw wrote:
> On Sat, 20 Apr 2019 at 22:30, Thomas Schwinge wrote:
>> On Tue, 18 Sep 2018 02:39:46 +0200, Iain Buclaw
>> wrote:
>> > This patch adds the configure and make files used for building D
>> > runtime and Phobos. As well a
Program received signal SIGSEGV, Segmentation fault.
aarch64_sve::svbool_type_p (type=)
at ../../gcc/config/aarch64/aarch64-sve-builtins.cc:3239
3239 && TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (abi_type));
(gdb) bt
#0 aarch64_sve::svbool_type_p (type=)
at ../../gcc/confi
Hi.
After a discussion with Honza, he recommended to install the patch set
(which should be completely approved) without the last missing piece:
[PATCH 2/9] operand_equal_p: add support for FIELD_DECL
He's going to write a function that will compare two access paths.
I've retested the whole patch
Hi!
On 2019-09-03T10:04:14+0200, Iain Buclaw wrote:
> On Tue, 3 Sep 2019 at 08:10, Bernd Edlinger wrote:
>> I've noticed that testing libphobos fails for multi-lib configs:
>>
>> $ make check-target-libphobos RUNTESTFLAGS="--target_board=unix\{-m32,\}"
>>
>> fails for every 32bit execution, beca
This breaks boostrap.
/opt/gcc/gcc-20191030/Build/./prev-gcc/xgcc
-B/opt/gcc/gcc-20191030/Build/./prev-gcc/ -B/usr/aarch64-suse-linux/bin/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include
-fno
Hi!
On 2019-10-30T12:19:28+0100, Jakub Jelinek wrote:
> On Wed, Oct 30, 2019 at 11:57:12AM +0100, Thomas Schwinge wrote:
>> ..., and when building gcc-9-branch with
>> '--enable-checking=yes,extra,rtl' (apparently I'm the only one doing
>> that, huh?), runs into the following (at least I suppose
On Wed, 30 Oct 2019, Alexandre Oliva wrote:
> On Oct 28, 2019, Richard Biener wrote:
>
> > I guess you need to elaborate on 'per-file'. With LTO as far as I
> > understand you'll get the graph per LTRANS unit (did you check
> > where the output is generated?).
>
> Yeah, I guess this was not de
Hello,
Attached is a patch that adds parsing of the optional requires-clause in a
lambda-expression and lambda-declarator. Additionally, shorthand constraints
from the template-parameter-list are now actually applied and constrain the
synthesized operator().
Previously we were not parsing the req
On Wed, Oct 30, 2019 at 11:57:12AM +0100, Thomas Schwinge wrote:
> ..., and when building gcc-9-branch with
> '--enable-checking=yes,extra,rtl' (apparently I'm the only one doing
> that, huh?), runs into the following (at least I suppose that's what's
I'm testing release branches with
../configure
On Wed, Oct 30, 2019 at 11:45:11AM +0100, Tobias Burnus wrote:
> On 10/30/19 10:31 AM, Jakub Jelinek wrote:
> > > +++ b/libgomp/testsuite/libgomp.fortran/omp_orphan.f
> > > +++ b/libgomp/testsuite/libgomp.fortran/omp_reduction.f
> > > +++ b/libgomp/testsuite/libgomp.fortran/omp_workshare1.f
> > > -
Hi!
On 2019-05-06T11:36:22+0200, Richard Biener wrote:
> On Sat, 4 May 2019, Richard Sandiford wrote:
>> Richard Biener writes:
>> > On Fri, 3 May 2019, Richard Biener wrote:
>> >> I am testing the following patch [...]
... which apparently also got backported to gcc-9-branch eventually...
>>
On Mon, Oct 14, 2019 at 03:11:43PM +0200, Tobias Burnus wrote:
> gcc/fortran/
> * f95-lang.c (LANG_HOOKS_OMP_ARRAY_DATA): Set to gfc_omp_array_data.
> * trans-array.c
Description of what has been changed and how is missing.
> --- a/gcc/langhooks.h
> +++ b/gcc/langhooks.h
> @@ -2
On Fri, Oct 18, 2019 at 11:27:39AM +0200, Tobias Burnus wrote:
> Currently, one has for
> !$omp target exit data map(delete:x)
> in the original dump:
> #pragma omp target exit data map(delete:*x) map(alloc:x [pointer assign,
> bias: 0])
>
> The "alloc:" not only does not make sense but also g
1 - 100 of 118 matches
Mail list logo
