On Tue, Oct 29, 2019 at 8:57 AM Jakub Jelinek wrote:
>
> Hi!
>
> While working on the OpenMP isa patch, I've noticed most of the x86 ISA
> options imply in the help text that it enables MMX, when they do not.
> We now have the mmx in sse2, so to some extent most of the built-in functions
> are ena
On Wed, Oct 30, 2019 at 08:01:28AM +0100, Uros Bizjak wrote:
> > While working on the OpenMP isa patch, I've noticed most of the x86 ISA
> > options imply in the help text that it enables MMX, when they do not.
> > We now have the mmx in sse2, so to some extent most of the built-in
> > functions
>
-finline-functions is enabled by default for O2 since r276469, update the
test cases that inline small functions caused instruction number difference.
gcc/testsuite/ChangeLog:
2019-10-30 Xiong Hu Luo
PR92090
* gcc/testsuite/gcc.target/powerpc/pr79439-1.c: Update
On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
> On 10/29/19 6:26 AM, John Paul Adrian Glaubitz wrote:
> > Hello!
> >
> > We have raised $5000 to support anyone willing to work on this for the
> > m68k target [1]. We really need the m68k to stay as it's essential to
> > be able to compile for L
Hi Jeff!!
On 10/29/19 8:34 PM, Jeff Law wrote:
>> Any chance that the unfinished code can be shared? I'm looking for any
>> blueprints that can be used as a guidance for the work on the m68k
>> backend.
> I'm not sure it'd be all that useful. The v850 bits would be a better
> starting point. The
Richard Biener writes:
> On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>>
>> On 10/29/19 6:26 AM, John Paul Adrian Glaubitz wrote:
>> > Hello!
>> >
>> > We have raised $5000 to support anyone willing to work on this for the
>> > m68k target [1]. We really need the m68k to stay as it's essential
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.
Thanks. I've fixed the common.opt changes, and I'll su
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 happen when we inline into functions
with indirect inlin
On Tue, 29 Oct 2019, Oleg Endo wrote:
> On Tue, 2019-10-29 at 11:26 +0100, Richard Biener wrote:
> > While I converted other iterators requiring special BREAK_FROM_XYZ
> > a few years ago FOR_EACH_IMM_USE_STMT is remaining. I've pondered
> > a bit but cannot arrive at a "nice" solution here with
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 more robust.
Verified on ppc64-redhat-linux. Should be fine o
Hi!
Generally, we need to consider the aim to test things sufficiently vs. the
already way too long test time of libgomp.fortran testsuite which is not
parallelized itself and often takes the longest time in the testsuite.
The primary reason to do any option cycling in libgomp.fortran are tests
i
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.
Here's the patch. Tested on x86_64-linux-gnu. Ok to i
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
>> wrote:
>>>
>>> Richard Biener writes:
>>> > On Wed, Oct 23, 2019 a
On Wed, 30 Oct 2019, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, while get_computation_at calls unshare_aff_combination
> and through that unshares the individual expressions, we then call
> aff_combination_to_tree which uses the fold-const.c APIs, and those do not
> guarantee the same
Hi Jeff,
> So I'm going to have to trust you on this one. It looks like you did
> more than just reorder the alternatives. For example, the constraints
> for operand0 look significantly different to me. THey're slightly
> different for operand1 as well (LR rather than Lc).
When we moved the AR
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.
Ok, here it is with a comment, bootstrapped/regtested again last night:
2019-
On 10/29/19 3:24 PM, Jan Hubicka wrote:
>> gcc/cgraph.c | 14 ++
>> gcc/cgraphclones.c | 5 +
>> gcc/ipa-fnsummary.c | 2 +-
>> gcc/ipa-hsa.c| 2 +-
>> gcc/ipa-icf.c| 2 +-
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 designed with LTO in mind; it probably even
predates LTO. We
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
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
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 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
> > > -
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
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, 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
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
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-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
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
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!
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
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!
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
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
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 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
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, 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
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, 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 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 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
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 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
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 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 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 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 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 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 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
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 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.
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 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
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 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]
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
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
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)));
>>
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
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
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/
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
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
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
> 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
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
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
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
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
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
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
* 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
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
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 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
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 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
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 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
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,
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
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
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
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.
>
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 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
>
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/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 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
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
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
> 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
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 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
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/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 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
1 - 100 of 118 matches
Mail list logo
