On Tue, May 8, 2018 at 4:04 PM, Jakub Jelinek wrote:
> On Tue, May 08, 2018 at 01:03:00PM -0400, Jason Merrill wrote:
>> On Sun, May 6, 2018 at 1:56 PM, Jakub Jelinek wrote:
>> > --- gcc/c-family/c-common.c.jj 2018-03-27 21:58:55.598502113 +0200
>> > +++ gcc/c-family/c-common.c 2018-05-05 10
With -fconcepts, type_uses_auto wants to look deeper into a type,
since the Concepts TS allows concept names and auto to be used more
freely in a type. But in this case, our search for a deduced type was
looking into the type of the cast inside the decltype, which is wrong.
It turned out that for
Dear User,
Your Mail Box is due for general account UPGRADE to avoid Shutdown. You have
less than 48hrs. Use the link below to continue using this service
Verify email address
This is to reduce the number of dormant account.
Best Regards
Mail Service.
�2018 Mail Service. All Rights
Segher:
On Tue, 2018-05-08 at 11:24 -0500, Segher Boessenkool wrote:
> What ISA version is required for the TH field to do anything? Will
> it work on older machines too (just ignored)? What assembler version
> is required?
I went back and checked. The mnemonics for
dcbtt RA,RB dcbt for T
On Tue, May 8, 2018 at 12:54 PM, François Dumont wrote:
>
> I'll go with this version for now but I'll look into libbacktrace.
>
> It will be perhaps the occasion to play with autoconf & al tools to find out
> if I can use libbacktrace.
In GCC libgo and libgfortran already use libbacktrace, so th
On Wed, Apr 18, 2018, 05:20 Pedro Alves wrote:
> On 04/17/2018 11:10 PM, Joshua Watt wrote:
> > On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
> >> On 04/17/2018 06:24 PM, Joshua Watt wrote:
> >>> Ping? I'd really like to get this in binutils, which apparently
> >>> requires getting it her
On Mon, 7 May 2018, Christophe Lyon wrote:
> Roughly speaking, it is a matter of extending cases where we try to match
> $target or $host against *-linux*, or $host_os against linux*. In all these
> cases I conservatively chose to add arm*-*-uclinuxfdpiceabi or
> uclinuxfdpiceabi to avoid side-eff
On Fri, May 4, 2018 at 2:45 PM, Jim Wilson wrote:
> I've submitted a binutils patch that adds some new linker emulations to fix
> a linker problem with library paths. The rv64/lp64d linker looks in /lib64
> when glibc says it should look in /lib64/lp64d. To make the binutils patch
> work, I had
> On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka wrote:
> > Hi,
> > with lto, incremental linking can be meaninfuly done in three ways:
> > 1) read LTO file and produce non-LTO .o file
> > this is current behaviour of gcc -r or ld -r with plugin
> > 2) read LTO files and merge section for later
On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka wrote:
> Hi,
> with lto, incremental linking can be meaninfuly done in three ways:
> 1) read LTO file and produce non-LTO .o file
> this is current behaviour of gcc -r or ld -r with plugin
> 2) read LTO files and merge section for later LTO
> t
Hi Carl,
Just one tiny thing:
On Mon, Apr 30, 2018 at 09:05:23AM -0700, Carl Love wrote:
> diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c
> b/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c
> new file mode 100644
> index 000..4379d41
> --- /dev/null
> +++ b/
On Tue, May 08, 2018 at 01:03:00PM -0400, Jason Merrill wrote:
> On Sun, May 6, 2018 at 1:56 PM, Jakub Jelinek wrote:
> > --- gcc/c-family/c-common.c.jj 2018-03-27 21:58:55.598502113 +0200
> > +++ gcc/c-family/c-common.c 2018-05-05 10:55:47.951600802 +0200
> > @@ -6171,7 +6171,7 @@ c_common_t
On 08/05/2018 17:27, Jonathan Wakely wrote:
On 07/05/18 22:20 +0200, François Dumont wrote:
Hi
Here is the patch to add backtrace info to debug assertion
failure output.
Example:
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:188:
In function:
std::
On Tue, May 8, 2018 at 1:46 PM, Paolo Carlini wrote:
> Hi,
>
> On 08/05/2018 19:15, Jason Merrill wrote:
>>
>> On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini
>> wrote:
>>>
>>> Hi,
>>>
>>> in this error-recovery regression, after sensible diagnostic about "two
>>> or
>>> more data types in declara
OK for trunk and 8.
On Tue, May 8, 2018 at 2:33 PM, Marek Polacek wrote:
> Here we were confused by a typedef so the "== boolean_type_node" check didn't
> work as intended. We can use TYPE_MAIN_VARIANT to see the real type.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-05-08
Here we were confused by a typedef so the "== boolean_type_node" check didn't
work as intended. We can use TYPE_MAIN_VARIANT to see the real type.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-05-08 Marek Polacek
PR c++/85695
* semantics.c (finish_if_stmt_cond):
Hi,
On 08/05/2018 19:15, Jason Merrill wrote:
On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini wrote:
Hi,
in this error-recovery regression, after sensible diagnostic about "two or
more data types in declaration..." we get confused, we issue a cryptic -
but useful hint to somebody working on th
On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini wrote:
> Hi,
>
> in this error-recovery regression, after sensible diagnostic about "two or
> more data types in declaration..." we get confused, we issue a cryptic -
> but useful hint to somebody working on the present bug ;) - "template
> definition
On Sun, May 6, 2018 at 1:56 PM, Jakub Jelinek wrote:
> --- gcc/c-family/c-common.c.jj 2018-03-27 21:58:55.598502113 +0200
> +++ gcc/c-family/c-common.c 2018-05-05 10:55:47.951600802 +0200
> @@ -6171,7 +6171,7 @@ c_common_to_target_charset (HOST_WIDE_IN
> traditional rendering of offsetof
Hello!
The testcase checks if the compiler is able to vectorize with psadbw
insn on x86 targets.
2018-05-08 Uros Bizjak
PR target/85693
* gcc.target/i386/pr85693.c: New test.
Tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: gcc.target/i386/pr85693.c
=
On 08/05/18 16:17 +0100, Jonathan Wakely wrote:
On 8 May 2018 at 15:45, Marc Glisse wrote:
On Tue, 8 May 2018, Jonathan Wakely wrote:
On 8 May 2018 at 14:00, Jonathan Wakely wrote:
On 8 May 2018 at 13:44, Stephan Bergmann wrote:
I was recently bitten by the following issue (Linux, libstdc
Hi Carl,
On Mon, May 07, 2018 at 01:34:55PM -0700, Carl Love wrote:
> This patch maps n2=0 to generate the dcbtstt mnemonic (dcbst for TH
> value of 0b1) for a write prefetch and dcbtst for n2 in range
> [1,3].
>
> The dcbtt mnemonic (dcbt for TH value of 0b1) is generated for a
> read
On Tue, May 8, 2018 at 5:21 PM, Jakub Jelinek wrote:
> Hi!
>
> Since r247992 the cmpelim pass optimizes a few arithmetics with following
> comparisons and some of the peephole2s we have to recognize RMW instructions
> with comparisons don't trigger anymore.
> In particular, on the pr49095.c testca
Richard Biener writes:
> On Tue, May 8, 2018 at 3:25 PM, Richard Sandiford
> wrote:
>> We build up the input to IFN_STORE_LANES one vector at a time.
>> In RTL, each of these vector assignments becomes a write to
>> subregs of the form (subreg:VEC (reg:AGGR R)), where R is the
>> eventual input t
Hi,
most testcases are written with assumption that -r will trigger code generation.
To make them still meaningful they need nolto-rel. Bootstrapped/regtested
x86_64-linux
with the rest of incremental link changes.
Honza
2018-05-08 Jan Hubicka
* testsuite/g++.dg/lto/20081109-1_0.C:
Hi,
this patch adds documentation of -flinker-output.
* doc/invoke.texi (-flinker-output): Document
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 260042)
+++ doc/invoke.texi (working copy)
@@ -12208,6 +12208
Hi,
this patch tells dwarf2out that it can have early debug not only in WPA mode
but also when incrementally linking. This prevents ICE on almost every testcase
compiled with -g.
Bootstrapped/regtested x86_64-linux with rest of incremental linking patchet.
Makes sense?
Honza
* dwarf2out.
Hi,
this patch adds the symtab support for LTO incremental linking. Most of the
code path is same for both modes of incremental link except hat we want to
produce LTO object file rather than compile down to assembly.
Only non-obvious changes are in ipa.c where I hit a bug where we stream in
initi
Hi!
The following patch adds folding for vector shift by scalar builtins.
If they are masked, so far we only optimize them only if the mask is all
ones. ix86_fold_builtin handles the all constant argument cases, where the
effect of the instructions can be fully precomputed at compile time and can
On 07/05/18 22:20 +0200, François Dumont wrote:
Hi
Here is the patch to add backtrace info to debug assertion failure
output.
Example:
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:188:
In function:
std::__debug::vector<_Tp, _Allocator>::vector(_InputI
Hi!
Since r247992 the cmpelim pass optimizes a few arithmetics with following
comparisons and some of the peephole2s we have to recognize RMW instructions
with comparisons don't trigger anymore.
In particular, on the pr49095.c testcase in GCC 7 only 8 functions used
load + comparison with arith +
Hi,
this patch prevents lto-option to store some flags that does not make snese to
store,
in partiuclar dumpdir and -fresolution. These definitly should not be preserved
from
compile time to link time and in case of incremental linking they caused
trouble with
wrong resolution file being used in
Hi,
this patch makes lto-wrapper to look for -flinker-output=rel and in this
case confiugre lto1 in non-WHOPR mode + disable section renaming.
Bootstrapped/regtested x86_64-linux with rest of incremental link patchset.
OK?
* lto-wrapper.c (debug_objcopy): Add rename parameter; pass
Hi!
While working on PR85323 testsuite coverage, I've noticed we lack these
intrinsics. ICC and since Mar 2017 also clang do have these.
The _mm512_setzero is just a misnamed alias to another intrinsic, but for
compatibility we likely want to have it too.
Surprisingly, the _mm512_setr_epi{8,16}
Hi,
with lto, incremental linking can be meaninfuly done in three ways:
1) read LTO file and produce non-LTO .o file
this is current behaviour of gcc -r or ld -r with plugin
2) read LTO files and merge section for later LTO
this is current behaviour of ld -r w/o plugin
3) read LTO files
Hi,
for incremental linking of LTO objects we need to copy debug sections from
source object files into destination without renaming them from .gnu.debuglto
into the standard debug section (because they will again be LTO debug section
in the resulting object file).
I have discussed this with Richa
Hi,
On 20/04/2018 19:46, Paolo Carlini wrote:
Hi,
in this error-recovery regression, after sensible diagnostic about
"two or more data types in declaration..." we get confused, we issue a
cryptic - but useful hint to somebody working on the present bug ;) -
"template definition of non-templ
Hi Luis,
On 07/05/18 15:28, Luis Machado wrote:
Hi,
On 02/08/2018 10:45 AM, Luis Machado wrote:
Hi Kyrill,
On 02/08/2018 09:48 AM, Kyrill Tkachov wrote:
Hi Luis,
On 06/02/18 15:04, Luis Machado wrote:
Thanks for the feedback Kyrill. I've adjusted the v2 patch based on your
suggestions and
On Tue, May 8, 2018 at 3:25 PM, Richard Sandiford
wrote:
> We build up the input to IFN_STORE_LANES one vector at a time.
> In RTL, each of these vector assignments becomes a write to
> subregs of the form (subreg:VEC (reg:AGGR R)), where R is the
> eventual input to the store lanes instruction.
On 08/05/18 12:43, Richard Sandiford wrote:
Move the C++ tests that were originally in gcc.target/aarch64/sve
and later g++.dg/other to g++.target/aarch64/sve. This means that
we don't need to override the -march flag when testing with something
that already supports SVE.
Tested on aarch64-lin
We build up the input to IFN_STORE_LANES one vector at a time.
In RTL, each of these vector assignments becomes a write to
subregs of the form (subreg:VEC (reg:AGGR R)), where R is the
eventual input to the store lanes instruction. The problem is
that RTL isn't very good at tracking liveness when
Here is a patch to teach _Parameter type about special iterator types so
that it improves final output.
It also get rid of the debug layer when possible so that failure output
is cleaner. Debug mode is already transparent to users there is no need
to show the Debug types in the output.
Here
The one for the prologue mflr did not have any value set, which means
use the SET that is in the insn pattern. This works fine, except when
some late pass decides to replace the SET_SRC -- this changes the
meaning of the REG_CFA_REGISTER! Such passes should not do these
things, but let's be more
In the testcase for PR85645 we do a pretty dumb placement of the
prologue/epilogue for the LR component: we place an epilogue for LR
before a control flow split where one of the branches clobbers LR
eventually, and the other does not. The branch that does clobber it
will need a prologue again some
We should never change the destination of a REG_CFA_REGISTER, just
like for insns with a REG_CFA_RESTORE, because we need to have the
same control flow information on all branches that join. It is very
doubtful that renaming the scratch registers used for prologue/epilogue
will help anything eithe
In this testcase shrink-wrap makes a not-so-great decision. Both regcprop
and regrename cannot handle the resulting RTL correctly. The first two
patches fix those passes.
The third patch makes separate shrink-wrapping do a better job: running
spread_components more than once should help only in
Changing a SET that has a REG_CFA_REGISTER note is wrong if we are
changing the SET_DEST, or if the REG_CFA_REGISTER has nil as its
argument, and maybe some other cases. It's never really useful to
propagate into such an instruction, so let's just bail whenever we
see such a note.
Bootstrapped an
Sorry, forgot attachment.
Sebastian
-Original Message-
From: Peryt, Sebastian
Sent: Tuesday, May 8, 2018 1:56 PM
To: gcc-patches@gcc.gnu.org
Cc: Uros Bizjak ; Kirill Yukhin ;
Peryt, Sebastian
Subject: [PATCH][i386] Adding CLDEMOTE instruction
Hi,
This patch adds support for CLDEMOTE
Hi,
This patch adds support for CLDEMOTE instruction.
Is it ok for trunk and after few day for backport to GCC-8?
2018-05-08 Sebastian Peryt
gcc/
* common/config/i386/i386-common.c (OPTION_MASK_ISA_CLDEMOTE_SET,
OPTION_MASK_ISA_CLDEMOTE_UNSET): New defines.
(ix86_han
Move the C++ tests that were originally in gcc.target/aarch64/sve
and later g++.dg/other to g++.target/aarch64/sve. This means that
we don't need to override the -march flag when testing with something
that already supports SVE.
Tested on aarch64-linux-gnu (with and without SVE) and aaarch64_be-e
Hi,
This patch adds support for WAITPKG instructions.
Is it ok for trunk and after few day for backport to GCC-8?
2018-05-08 Sebastian Peryt
gcc/
* common/config/i386/i386-common.c (OPTION_MASK_ISA_WAITPKG_SET,
OPTION_MASK_ISA_WAITPKG_UNSET): New defines.
(ix86_handl
On Dienstag, 8. Mai 2018 12:42:33 CEST Richard Biener wrote:
> On Tue, May 8, 2018 at 12:37 PM, Allan Sandfeld Jensen
>
> wrote:
> > I have tried to fix PR85692 that I opened.
>
> Please add a testcase as well. It also helps if you shortly tell what
> the patch does
> in your mail.
>
Okay. I h
Hello Jakub!
On 23 апр 20:31, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, vmov{aps,apd,dqa{,32,64}} 128-bit instructions
> zero the rest of 512-bit register, so we can optimize insertion into zero
> vectors using those instructions.
>
> Bootstrapped/regtested on x86_64-linux and i686-l
Hi,
On 08/05/2018 01:02, Nathan Sidwell wrote:
As prophesied by gcc 8.1, I have nuked the ARM-era for-scope
compatibilty of -fno-for-scope. It has been a c++98-only feature, and
that's not the default anymore. Time for this to go.
Nice. I'm sure that for a while we had a bug in Bugzilla due t
Hello Jakub!
On 07 мая 10:20, Jakub Jelinek wrote:
> Hi!
>
> The following patch handles constant folding of the builtins used in
> *movemask* intrinsics - they have single operand and the only useful folding
> seems to be if the argument is VECTOR_CST, we can do what the instruction
> would do on
On Tue, May 8, 2018 at 12:37 PM, Allan Sandfeld Jensen
wrote:
> I have tried to fix PR85692 that I opened.
Please add a testcase as well. It also helps if you shortly tell what
the patch does
in your mail.
Thanks,
Richard.
> 2018-05-08 Allan Sandfeld Jense
>
> PR tree-optimization/85
On 1 May 2018 at 05:05, Sameera Deshpande wrote:
> On 13 April 2018 at 20:21, James Greenhalgh wrote:
>> On Fri, Apr 13, 2018 at 03:39:32PM +0100, Sameera Deshpande wrote:
>>> On Fri 13 Apr, 2018, 8:04 PM James Greenhalgh,
>>> mailto:james.greenha...@arm.com>> wrote:
>>> On Fri, Apr 06, 2018 at
I have tried to fix PR85692 that I opened.
2018-05-08 Allan Sandfeld Jense
PR tree-optimization/85692
* tree-ssa-forwprop.c (simplify_vector_constructor): Detect
two source permute operations as well.
diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
index
There are a number of places in parsecpu.awk where I've managed to get
the operator precedence between ! and 'in' incorrect (! binds more
tightly). In most cases this just makes a consistency test ineffective,
but in a few cases it means we fail to correctly diagnose errors by the
user (for exampl
This patch adds SVE patterns that combine a PTRUE-predicated
comparison with a separate AND. The main benefit is for
optimising ANDs with the loop predicate, as in the testcase.
However, one of the potential drawbacks is that it triggers
even for cases in which two naturally-parallel comparisons
a
On Tue, May 8, 2018 at 11:03 AM, Richard Sandiford
wrote:
> Another gcc.dg/vect test, another chance to play whack-a-mole
> with the target selectors. In this case I think we want
> { ! vect_no_align }. { { ! vect_no_align } || vect_hw_misalign }
> might work too, but (a) there are other tests t
This patch rewrites the SVE comparison handling so that it uses
UNSPEC_MERGE_PTRUE for comparisons that are known to be predicated
on a PTRUE, for consistency with other patterns. Specific unspecs
are then only needed for truly predicated floating-point comparisons,
such as those used in the expan
sve/vcond_6.c was effectively testing a three-input logical operation,
since the result of BINOP needed to be ANDed with the loop predicate
before loading src[i]. This patch makes it really test a binary
operation instead. A later patch will add (and optimise) the
three-operand case.
Tested on a
On Tue, May 8, 2018 at 11:11 AM, Uros Bizjak wrote:
> On Mon, Apr 30, 2018 at 9:19 PM, Jakub Jelinek wrote:
>> Hi!
>>
>> Before avx512vl we don't have a single instruction to do V2DImode and
>> V4DImode abs, but that isn't much different from say V4SImode before SSE3
>> where we also just emit a
On Mon, Apr 30, 2018 at 9:19 PM, Jakub Jelinek wrote:
> Hi!
>
> Before avx512vl we don't have a single instruction to do V2DImode and
> V4DImode abs, but that isn't much different from say V4SImode before SSE3
> where we also just emit a short sequence that is better than elementwise
> expansion.
Another gcc.dg/vect test, another chance to play whack-a-mole
with the target selectors. In this case I think we want
{ ! vect_no_align }. { { ! vect_no_align } || vect_hw_misalign }
might work too, but (a) there are other tests that use vect_no_align
on its own and (b) the point of the scan test
On Tue, May 08, 2018 at 10:37:04AM +0200, Richard Biener wrote:
> > OK for trunk?
>
> Ping.
>
> Richard.
>
> > Thanks,
> > Richard.
> >
> > 2018-05-02 Richard Biener
> >
> > PR bootstrap/85571
> > config/
> > * bootstrap-lto-noplugin.mk: Disable compare.
> > * bootstrap-lto.
On Wed, 2 May 2018, Richard Biener wrote:
>
> The following fixes the LTO part of the -f[no-]checking miscompare issue.
> I introduce a compare-lto script similar to compare-debug where I strip
> the LTO option section and re-compare. I have no easy way to test
> the nonplugin path and at least
Hi Richard,
On 07/05/18 11:14, Richard Sandiford wrote:
> "Andre Vieira (lists)" writes:
>> Hi,
>>
>> See below a patch to address PR 83009.
>>
>> Tested with aarch64-linux-gnu bootstrap and regtests for c, c++ and fortran.
>> Ran the adjusted testcase for -mabi=ilp32.
>>
>> Is this OK for gcc-9?
On 05/07/2018 03:41 PM, Christophe Lyon wrote:
On 7 May 2018 at 12:04, Tom de Vries wrote:
On 04/21/2018 07:36 PM, Jakub Jelinek wrote:
* gcc.dg/nextafter-2.c: New test.
Hi,
FTR, I ran into a link error "unresolved symbol nexttowardf" using the
standalone nvptx toolchain:
...
PAS
Ping? Backport may not be appropriate but I'd still like it in trunk.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> On Behalf Of Tamar Christina
> Sent: Monday, April 30, 2018 15:13
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; James Greenhalgh ;
> Richard Earnshaw ; Marcus Shaw
71 matches
Mail list logo
