PR target/83862 pointed out a problem I put into the 128-bit floating point
type signbit optimization. The issue is we want to avoid doing a load to a
floating point/vector register and then a direct move to do signbit, so we
change the load to load the upper 64-bits of the floating point value to
Hi,
This patch supercedes and extends
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01479.html,
adding the remaining big-endian support for -mno-speculate-indirect-jumps.
This includes 32-bit support for indirect calls and sibling calls, and
64-bit support for indirect calls. The endian-neutral
The callee copies ABI used for 32-bit hppa causes no end of optimization
issues and problems with
OpenMP. The hppa target is only in Debian unstable and gentoo. In both
cases, packages are
rebuilt often. So, Helge and I decided that it was better to break the
ABI and accept whatever
problems
On 17.01.2018 02:52, John David Anglin wrote:
> When I defined MALLOC_ABI_ALIGNMENT, I inadvertently changed the default
> alignment for
> various hppa*-*-*bsd* targets. Nick Hudson is still maintaining the
> netbsd target.
>
> This patch corrects the default malloc alignment for 32-bit targest a
When I defined MALLOC_ABI_ALIGNMENT, I inadvertently changed the default
alignment for
various hppa*-*-*bsd* targets. Nick Hudson is still maintaining the
netbsd target.
This patch corrects the default malloc alignment for 32-bit targest and
moves the linux special
case to its own file.
Com
This shortens and simplifies a number of lines in ASM_DECLARE_FUNCTION_NAME.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2018-01-16 John David Anglin
* config/pa/som.h (ASM_DECLARE_FUNCTION_NAME): Cleanup type and mode
variables.
Index: config/pa/so
We need to apply CEIL to the case where mode != BLKmode.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2018-01-16 John David Anglin
* config/pa/pa.c (pa_function_arg_size): Apply CEIL to GET_MODE_SIZE
return value.
Index: config/pa/pa.c
===
I misunderstood how the dist codes are handled in block type 1. I
also think'od the length of the codes for the default table. This
patch fixes these problems, along with a test case that exposes them.
Bootstrapped and ran libbacktrace tests on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
20
.. regression testing actually completed successfully.
Paolo.
On 01/16/2018 02:32 PM, Jakub Jelinek wrote:
On Tue, Jan 16, 2018 at 01:36:26PM -0700, Martin Sebor wrote:
--- gcc/gimple-ssa-warn-restrict.c (revision 256752)
+++ gcc/gimple-ssa-warn-restrict.c (working copy)
@@ -384,6 +384,12 @@ builtin_memref::builtin_memref (tree expr, tree si
On 01/16/2018 03:54 PM, Eric Botcazou wrote:
This test fails on strict-alignment platforms because a call to memcpy is not
turned into a simple move and thus yields an additional warning:
warning: '__builtin_memcpy' writing 4 bytes into a region of size 0 overflows
the destination [-Wstringop-ov
On 01/16/2018 03:39 PM, Eric Botcazou wrote:
On these platforms, one of the instances of the constructor generated in
test_strcpy_bounds_memarray_range is put into the constant pool so the strlen
pass cannot do its magic.
Tested on visium-elf, SPARC64 and x86-64/Linux, applied on the mainline.
This test fails on Visium because of 3 separate issues. The first one is
benign, it's a warning about a pointer mismatch between int32_t* and int*
(On most newlib targets, int32_t is long int instead of int) in the test.
The other 2 are in the code itself (but cancel each other on most targets):
Like my recent patch for 83186, we were missing a build_non_dependent_expr.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5c63951fe987acd133bf59532896a4b397f49f12
Author: Jason Merrill
Date: Tue Jan 16 17:19:22 2018 -0500
PR c++/83714 - ICE checking return in template.
Hi!
On Tue, Jan 16, 2018 at 11:57:14AM -0800, Carl Love wrote:
> The following patch contains fixes for the stxvl and lxvl instructions
> and XL_LEN_R builtin that were found while adding additional Power 9
> test cases for the various load and store builtins. The new tests in
> builtins-5-p9-run
This test fails on strict-alignment platforms because a call to memcpy is not
turned into a simple move and thus yields an additional warning:
warning: '__builtin_memcpy' writing 4 bytes into a region of size 0 overflows
the destination [-Wstringop-overflow=]
The attached patch tweaks the test
On these platforms, one of the instances of the constructor generated in
test_strcpy_bounds_memarray_range is put into the constant pool so the strlen
pass cannot do its magic.
Tested on visium-elf, SPARC64 and x86-64/Linux, applied on the mainline.
2018-01-16 Eric Botcazou
* c-c++
On Tue, Jan 16, 2018 at 03:20:24PM -0700, Martin Sebor wrote:
> Thanks for looking at it! I confess it's not completely clear
> to me in what type the pass tracks string lengths. For string
> constants, get_stridx() returns an int with the their length
> bit-flipped. I tried to maintain that inv
Hi!
On Tue, Jan 16, 2018 at 01:39:28PM -0600, Will Schmidt wrote:
> Sniff-tests of the target tests on a single system look OK. Full regtests are
> currently running across assorted power systems.
> OK for trunk, pending successful results?
Just a few little things:
> 2018-01-16 Will Schmidt
On 01/16/2018 02:26 PM, Jakub Jelinek wrote:
On Tue, Jan 16, 2018 at 07:37:30PM +, Richard Sandiford wrote:
-/* Check if RHS is string_cst possibly wrapped by mem_ref. */
+/* If RHS, either directly or indirectly, refers to a string of constant
+ length, return it. Otherwise return a neg
On 01/16/2018 12:37 PM, Richard Sandiford wrote:
Martin Sebor writes:
Recent improvements to the strlen pass introduced the assumption
that when the length of a string has been recorded by the pass
the length is necessarily constant. Bug 83896 shows that this
assumption is not always true, and
On Jan 16 2018, DJ Delorie wrote:
> And it's not the host's bit size that counts; there are usually ways to
> get 64-bit file operations on 32-bit hosts.
If ACX_LARGEFILE doesn't succeed in enabling those 64-bit file
operations (thus making off_t a 64-bit type) then you are out of luck
(or AC_SY
The patch changes the test to exclude solaris for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80481
The first patch solved the problem for solaris too but solaris gcc still
generates vmovaps in some different part of the code (unrelated to the
problem) where linux gcc does not.
Committed as
Hi Jason
On 16/01/2018 22:35, Jason Merrill wrote:
On Tue, Jan 16, 2018 at 3:32 PM, Paolo Carlini wrote:
thus I figured out what was badly wrong in my first try: I misread
ensure_literal_type_for_constexpr_object and missed that it can return
NULL_TREE without emitting an hard error. Thus my f
On Tue, Jan 16, 2018 at 3:32 PM, Paolo Carlini wrote:
> thus I figured out what was badly wrong in my first try: I misread
> ensure_literal_type_for_constexpr_object and missed that it can return
> NULL_TREE without emitting an hard error. Thus my first try even caused
> miscompilations :( Anyway,
On Tue, Jan 16, 2018 at 01:36:26PM -0700, Martin Sebor wrote:
> --- gcc/gimple-ssa-warn-restrict.c(revision 256752)
> +++ gcc/gimple-ssa-warn-restrict.c(working copy)
> @@ -384,6 +384,12 @@ builtin_memref::builtin_memref (tree expr, tree si
> base = SSA_NAME_VAR (base);
>}
>
On Tue, Jan 16, 2018 at 07:37:30PM +, Richard Sandiford wrote:
> > -/* Check if RHS is string_cst possibly wrapped by mem_ref. */
> > +/* If RHS, either directly or indirectly, refers to a string of constant
> > + length, return it. Otherwise return a negative value. */
> > +
> > static i
On Visium, the compiler sometimes emits a NOP to avoid a pipeline hazard.
Tested on visium-elf and x86_64-suse-linux, applied on the mainline.
2018-01-16 Eric Botcazou
* c-c++-common/patchable_function_entry-decl.c: Use 3 NOPs on Visium.
* c-c++-common/patchable_function_entr
They either use too much space in the data segment or on the stack.
Tested on visium-elf, applied on the mainline.
2018-01-16 Eric Botcazou
* gcc.dg/tree-ssa/ldist-27.c: Skip on Visium.
* gcc.dg/tree-ssa/loop-interchange-1.c: Likewise.
* gcc.dg/tree-ssa/loop-interchan
Tested on visium-elf, applied on the mainline.
2018-01-16 Eric Botcazou
* config/visium/visium.md (nop): Tweak comment.
(hazard_nop): Likewise.
--
Eric BotcazouIndex: config/visium/visium.md
===
--- config/visiu
We need to enable delayed-branch scheduling to have sibling calls on SPARC.
Tested on SPARC64/Linux, applied on the mainline and 7 branch.
2018-01-16 Eric Botcazou
PR testsuite/77734
* gcc.dg/plugin/must-tail-call-1.c: Pass -fdelayed-branch on SPARC.
--
Eric BotcazouIndex:
The SPARC-V8 architecture contains a Y register so defines
a structure with a 'y' field on Linux.
Tested on SPARC64/Linux, applied on the mainline and 7 branch as obvious.
2018-01-16 Eric Botcazou
* testsuite/17_intro/names.cc: Undefine 'y' on SPARC/Linux.
--
Eric Botcazou
Index:
PR 83698 - bogus offset in -Wrestrict messages for strcat of
unknown strings, points out that the offsets printed by
-Wrestrict for possibly overlapping strcat calls with unknown
strings don't look meaningful in some cases. The root cause
of the bogus values is wrapping during the conversion from
Hi again,
thus I figured out what was badly wrong in my first try: I misread
ensure_literal_type_for_constexpr_object and missed that it can return
NULL_TREE without emitting an hard error. Thus my first try even caused
miscompilations :( Anyway, when DECL_DECLARED_CONSTEXPR_P is true we are
> I'd assumed that variable-length types couldn't occur here, since it
> seems strange to view-convert a variable-length type to a fixed-length
> one.
This happens all the time in Ada when you convert an unconstrained type into
one of its constrained subtypes (but the run-time sizes must match).
On Tue, Jan 16, 2018 at 8:09 AM, H.J. Lu wrote:
> On Tue, Jan 16, 2018 at 7:03 AM, Martin Liška wrote:
>> On 01/16/2018 01:35 PM, H.J. Lu wrote:
>>> On Tue, Jan 16, 2018 at 3:40 AM, H.J. Lu wrote:
This patch has been used with my Spectre backport for GCC 7 for many
weeks and has been c
GCC maintainers:
The following patch contains fixes for the stxvl and lxvl instructions
and XL_LEN_R builtin that were found while adding additional Power 9
test cases for the various load and store builtins. The new tests in
builtins-5-p9-runnable.c and builtins-6-p9-runnable.c are included that
On Sun, Jan 14, 2018 at 5:43 PM, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 5:35 PM, H.J. Lu wrote:
>> On Sun, Jan 14, 2018 at 8:19 AM, Uros Bizjak wrote:
>>> On Fri, Jan 12, 2018 at 9:01 AM, Uros Bizjak wrote:
On Thu, Jan 11, 2018 at 2:28 PM, H.J. Lu wrote:
> Hi Uros,
>
>>
Hi,
Add support for gimple folding of the mergeh, mergel intrinsics. Since the
low and high versions are almost identical, a new helper function is added
so that code can be shared.
The changes introduced here affect the existing target testcases
gcc.target/powerpc/builtins-1-be.c and built
Martin Sebor writes:
> Recent improvements to the strlen pass introduced the assumption
> that when the length of a string has been recorded by the pass
> the length is necessarily constant. Bug 83896 shows that this
> assumption is not always true, and that GCC fails with an ICE
> when it doesn'
Recent improvements to the strlen pass introduced the assumption
that when the length of a string has been recorded by the pass
the length is necessarily constant. Bug 83896 shows that this
assumption is not always true, and that GCC fails with an ICE
when it doesn't hold. To avoid the ICE the a
Hi,
This patch fills in a gap from the previous -mno-speculate-indirect-jumps
patch. That patch didn't provide support for indirect calls using ABI_AIX
as the default ABI. This fills in that missing support and changes the
one related powerpc64le-only test case to be compiled for all subtargets.
Well, it should all work fine as long as the xcoff64 file is less than 4
Gb.
And it's not the host's bit size that counts; there are usually ways to
get 64-bit file operations on 32-bit hosts.
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Tue, 16 Jan 2018 13:00:48 -0500
>
>
> I think that warning is valid - the host has a 32-bit limit to file
> sizes (off_t) but it's trying to read a 64-bit offset (in that clause).
> It's warning you that you won
Hi Kyrill,
>
> Hi Tamar,
>
> On 16/01/18 16:56, Tamar Christina wrote:
> > Th 01/16/2018 16:36, James Greenhalgh wrote:
> >> On Tue, Jan 16, 2018 at 02:21:30PM +, Tamar Christina wrote:
> >>> Hi Kyrill,
> >>>
> xgene1 was added a few releases ago, better to use one of the new
> addition
I think that warning is valid - the host has a 32-bit limit to file
sizes (off_t) but it's trying to read a 64-bit offset (in that clause).
It's warning you that you won't be able to handle files as large as the
field implies.
Can we hide the warning? Probably. Should we? Debatable, as long as
On January 16, 2018 5:14:50 PM GMT+01:00, Richard Sandiford
wrote:
>This PR is about a case in which we VIEW_CONVERT a variable-sized
>unaligned record:
>
>sizes-gimplified type_7 BLK
>size
>unit-size
>align:8 ...>
>
>to an aligned 32-bit integer. The strict-alignment handling of
>
Hi Kelvin,
On Tue, Jan 16, 2018 at 11:15:12AM -0600, Kelvin Nilsen wrote:
>
> A patch committed on 2018-01-10 is causing an ICE with existing test
> program $GCC_SRC/gcc/testsuite/gcc.target/powerpc/pr83399.c, when
> compiled with the -m32 option. At the time of the commit, it was
> thought that
Compiling GDB 8.0.91 with mingw.org's MinGW GCC 6.0.3 produces this
warning in libiberty:
gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I.
-I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes
-pedantic -D_GNU_SOURCE ./simple-object-xcoff.c -o simple-
Hi Tamar,
On 16/01/18 16:56, Tamar Christina wrote:
Th 01/16/2018 16:36, James Greenhalgh wrote:
On Tue, Jan 16, 2018 at 02:21:30PM +, Tamar Christina wrote:
Hi Kyrill,
xgene1 was added a few releases ago, better to use one of the new additions
from the above list.
For example -mtune=co
A patch committed on 2018-01-10 is causing an ICE with existing test
program $GCC_SRC/gcc/testsuite/gcc.target/powerpc/pr83399.c, when
compiled with the -m32 option. At the time of the commit, it was
thought that this was a problem with the recent resolution of PR83399.
However, further investiga
On Mon, Jan 15, 2018 at 11:34:19AM +, Wilco Dijkstra wrote:
> This fixes PR82964 which reports ICEs for some CONST_WIDE_INT immediates.
> It turns out decimal floating point CONST_DOUBLE get changed into
> CONST_WIDE_INT without checking the constraint on the operand, which
> results in failur
On Tue, 16 Jan 2018, Segher Boessenkool wrote:
> On Mon, Jan 15, 2018 at 09:21:07AM +0100, Richard Biener wrote:
> > We're still in pretty bad shape regression-wise. Please also take
> > the opportunity to check the state of your favorite host/target
> > combination to make sure building and test
This is needed for GCC 6 backport of Spectre patches:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01465.html
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01466.html
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01464.html
--
H.J.
From: hjl
Make ix86_frame available to i386 code generation. This is needed to
backport the patch set of -mindirect-branch= to mitigate variant #2 of
the speculative execution vulnerabilities on x86 processors identified
by CVE-2017-5715, aka Spectre.
Backport from mainline
2017
This patch set makes ix86_frame available to i386 code generation. They
are needed to backport the patch set of -mindirect-branch= to mitigate
variant #2 of the speculative execution vulnerabilities on x86 processors
identified by CVE-2017-5715, aka Spectre.
Tested on Linux/i686 and Linux/x86-64.
I seem to have forgotten the patch :)
The 01/16/2018 16:56, Tamar Christina wrote:
> Th 01/16/2018 16:36, James Greenhalgh wrote:
> > On Tue, Jan 16, 2018 at 02:21:30PM +, Tamar Christina wrote:
> > > Hi Kyrill,
> > >
> > > >
> > > > xgene1 was added a few releases ago, better to use one of
From: hjl
When there is no need to make a copy of ix86_frame, we can use reference
of struct ix86_frame to avoid copy.
Backport from mainline
2017-11-06 H.J. Lu
* config/i386/i386.c (ix86_can_use_return_insn_p): Use reference
of struct ix86_frame.
(ix8
Th 01/16/2018 16:36, James Greenhalgh wrote:
> On Tue, Jan 16, 2018 at 02:21:30PM +, Tamar Christina wrote:
> > Hi Kyrill,
> >
> > >
> > > xgene1 was added a few releases ago, better to use one of the new
> > > additions from the above list.
> > > For example -mtune=cortex-r52.
> >
> > Than
On Tue, Jan 16, 2018 at 02:21:30PM +, Tamar Christina wrote:
> Hi Kyrill,
>
> >
> > xgene1 was added a few releases ago, better to use one of the new additions
> > from the above list.
> > For example -mtune=cortex-r52.
>
> Thanks, I have updated the patch. I'll wait for an ok from an AArch
v2: Rebased after the big SVE commits
Remove the remaining uses of '*' from aarch64.md.
Using '*' in alternatives is typically incorrect as it tells the register
allocator to ignore those alternatives. Also add a missing '?' so we
prefer a floating point register for same-size int<->fp conversion
This PR is about a case in which we VIEW_CONVERT a variable-sized
unaligned record:
unit-size
align:8 ...>
to an aligned 32-bit integer. The strict-alignment handling of
this case creates an aligned temporary slot, moves the operand
into the slot in the operand's original mode, then a
On Tue, Jan 16, 2018 at 7:03 AM, Martin Liška wrote:
> On 01/16/2018 01:35 PM, H.J. Lu wrote:
>> On Tue, Jan 16, 2018 at 3:40 AM, H.J. Lu wrote:
>>> This patch has been used with my Spectre backport for GCC 7 for many
>>> weeks and has been checked into GCC 7 branch. Should I revert it on
>>> GC
Joseph Myers wrote:
> Another question to consider: what about configurations (mostly
> soft-float) where floating-point exceptions are not supported? (glibc
> wrongly defines math_errhandling to include MATH_ERREXCEPT there, but the
> only option actually permitted by C99 in that case would b
On 01/16/2018 06:41 AM, Segher Boessenkool wrote:
> On Mon, Dec 18, 2017 at 12:16:13PM -0700, Jeff Law wrote:
>> On 12/16/2017 02:03 PM, Segher Boessenkool wrote:
>>> In PR83424 combine's move_deaths puts a REG_DEAD not in the wrong place
>>> because dead_or_set_regno_p does not account for CLOBBER
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-01-16 Richard Biener
PR tree-optimization/83867
* tree-vect-stmts.c (vect_transform_stmt): Precompute
nested_in_vect_loop_p since the scalar stmt may get invalidated.
* gcc.dg/vect/pr
On Tue, Jan 16, 2018 at 2:29 PM, Richard Sandiford
wrote:
> vect_analyze_loop_operations was calling vectorizable_live_operation
> for all live-out phis, which led to a bogus ncopies calculation in
> the pure SLP case. I think v_a_l_o should only be passing phis
> that are vectorised using normal
On 01/15/2018 04:46 PM, Jakub Jelinek wrote:
Hi!
As the testcase shows, calls to member_vec_dedup and qsort are just guarded
by the vector being non-NULL, which doesn't mean it must be non-empty,
so we can't do (*member_vec)[0] on it. Fixed by the second hunk, the
rest is just a small cleanup t
On Tue, 16 Jan 2018, Jakub Jelinek wrote:
> Hi!
>
> After lengthy IRC discussions, here is an updated patch, which should also
> fix the problem that variably_modified_type_p on a REAL_TYPE returns true
> even when it has constant maximum and minimum.
>
> Bootstrapped/regtested on x86_64-linux a
On 01/16/2018 01:35 PM, H.J. Lu wrote:
> On Tue, Jan 16, 2018 at 3:40 AM, H.J. Lu wrote:
>> This patch has been used with my Spectre backport for GCC 7 for many
>> weeks and has been checked into GCC 7 branch. Should I revert it on
>> GCC 7 branch or check it into trunk?
>
> Ada build failed wit
Hi Richard,
> I'm quite sure Solaris supports comdats, after all it invented ELF ;)
true: gcc/configure.ac has
# Sun ld has COMDAT group support since Solaris 9, but it doesn't
# interoperate with GNU as until Solaris 11 build 130, i.e. ld
# version 1.688.
#
# If us
On 2018-01-16 9:48 AM, Richard Sandiford wrote:
Oops, yes. Installed with that change, thanks.
Oops, I just realized the CEIL function needs to be applied to the
GET_MODE_SIZE
return as well...
Dave
--
John David Anglin dave.ang...@bell.net
Hi Jan,
>> It makes the option using thunks unusable though, right? Can you simply make
>> them hidden on systems without comdat support? That duplicates them per TU
>> but at least the feature works. Or those systems should provide the
>> thunks via
>> libgcc.
>>
>> I agree we can followup wi
Hi Richard,
>>> Backport is blocked by
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83838
>>>
>>> There are many test failures due to lack of comdat support in linker on
>>> Solaris.
actually this is lack of hidden .gnu.linkonce support right now.
Currently that's disabled for all but gld
Hi!
After lengthy IRC discussions, here is an updated patch, which should also
fix the problem that variably_modified_type_p on a REAL_TYPE returns true
even when it has constant maximum and minimum.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-01-16 Jakub Jelinek
John David Anglin writes:
> On 2018-01-16 5:52 AM, Richard Sandiford wrote:
>> 2018-01-16 Richard Sandiford
>>
>> gcc/
>> PR target/83858
>> * config/pa/pa.h (FUNCTION_ARG_SIZE): Delete.
>> * config/pa/pa-protos.h (pa_function_arg_size): Declare.
>> * config/pa/som.h (ASM_DECL
On 2018-01-16 5:52 AM, Richard Sandiford wrote:
2018-01-16 Richard Sandiford
gcc/
PR target/83858
* config/pa/pa.h (FUNCTION_ARG_SIZE): Delete.
* config/pa/pa-protos.h (pa_function_arg_size): Declare.
* config/pa/som.h (ASM_DECLARE_FUNCTION_NAME): Use
pa_
On Jan 16, 2018, at 6:13 AM, Segher Boessenkool
wrote:
>
> Hi!
>
> On Tue, Jan 16, 2018 at 09:29:13AM +0100, Richard Biener wrote:
>> Did you consider simply removing the tablejump/casesi support so
>> expansion always
>> expands to a balanced tree? At least if we have any knobs to tune we
>>
Hi Kyrill,
>
> xgene1 was added a few releases ago, better to use one of the new additions
> from the above list.
> For example -mtune=cortex-r52.
Thanks, I have updated the patch. I'll wait for an ok from an AArch64
maintainer and a Docs maintainer.
>
> With that nit the arm changes look ok
On Mon, Dec 18, 2017 at 12:16:13PM -0700, Jeff Law wrote:
> On 12/16/2017 02:03 PM, Segher Boessenkool wrote:
> > In PR83424 combine's move_deaths puts a REG_DEAD not in the wrong place
> > because dead_or_set_regno_p does not account for CLOBBER insns. This
> > fixes it.
> >
> > Bootstrapped and
vect_analyze_loop_operations was calling vectorizable_live_operation
for all live-out phis, which led to a bogus ncopies calculation in
the pure SLP case. I think v_a_l_o should only be passing phis
that are vectorised using normal loop vectorisation, since
vect_slp_analyze_node_operations handles
.. nevermind, this requires more work: my simple patchlet would cause a
few regression in the libstdc++-v3 testsuite (the assert at the
beginning of finish_expr_stmt triggers)
Paolo.
On 15 January 2018 at 22:44, Jakub Jelinek wrote:
> Hi!
>
> When using the bswap pass infrastructure, BIT_NOT_EXPRs aren't allowed in
> the middle, but due to the way process_store handles those it can appear
> around the value, which is something output_merged_store didn't handle.
>
> Fixed thusl
On Mon, Jan 15, 2018 at 09:21:07AM +0100, Richard Biener wrote:
> We're still in pretty bad shape regression-wise. Please also take
> the opportunity to check the state of your favorite host/target
> combination to make sure building and testing works appropriately.
I tested building Linux (the k
The soon-to-be-released binutils 2.30 makes a small change to how
lambda functions are demangled, which causes some unwanted symbols to
match a wildcard pattern in the GLIBCXX_3.4 version node of our linker
script. The only symbol that is supposed to match the pattern is
std::cerr so we should jus
On Tue, Jan 16, 2018 at 3:40 AM, H.J. Lu wrote:
> This patch has been used with my Spectre backport for GCC 7 for many
> weeks and has been checked into GCC 7 branch. Should I revert it on
> GCC 7 branch or check it into trunk?
Ada build failed with this on trunk:
raised STORAGE_ERROR : stack o
Hi!
On Mon, Jan 15, 2018 at 05:09:06PM -0600, Bill Schmidt wrote:
> @@ -12933,9 +12974,27 @@
>""
> {
>if (TARGET_32BIT)
> -emit_jump_insn (gen_tablejumpsi (operands[0], operands[1]));
> +{
> + if (rs6000_speculate_indirect_jumps)
> + emit_jump_insn (gen_tablejumpsi (opera
Hi,
Just added myself to MAINTAINERS (write after approval)
Best Regards,
Sebastian
Index: ChangeLog
===
--- ChangeLog(revision 256737)
+++ ChangeLog(working copy)
@@ -1,3 +1,7 @@
+2018-01-16 Sebastian Perta
+
+* MAINTAINERS (wri
Hi!
On Tue, Jan 16, 2018 at 09:29:13AM +0100, Richard Biener wrote:
> Did you consider simply removing the tablejump/casesi support so
> expansion always
> expands to a balanced tree? At least if we have any knobs to tune we
> should probably
> tweak them away from the indirect jump using variant
On Tue, Jan 16, 2018 at 12:11:28PM +, Richard Sandiford wrote:
> We had:
>
> tree t = fold_vec_perm (type, arg1, arg2,
> vec_perm_indices (sel, 2, nelts));
>
> where fold_vec_perm takes a const vec_perm_indices &. GCC 4.1 apparently
> required
We had:
tree t = fold_vec_perm (type, arg1, arg2,
vec_perm_indices (sel, 2, nelts));
where fold_vec_perm takes a const vec_perm_indices &. GCC 4.1 apparently
required a public copy constructor:
gcc/vec-perm-indices.h:85: error: 'vec_perm_indic
This patch has been used with my Spectre backport for GCC 7 for many
weeks and has been checked into GCC 7 branch. Should I revert it on
GCC 7 branch or check it into trunk?
H.J.
---
When there is no need to make a copy of ix86_frame, we can use reference
of struct ix86_frame to avoid copy.
Hi Tamar,
On 16/01/18 10:04, Tamar Christina wrote:
Hi All,
This patch updates the GCC 8 release notes for ARM and AArch64.
Ok for cvs?
Thanks,
Tamar
--
+
+
+New Armv8.4-A FP16 Floating Point Multiplication Variant instructions have
been added. These instructions are
+mandat
Jakub Jelinek writes:
> On Tue, Jan 16, 2018 at 08:57:38AM +0100, Richard Biener wrote:
>> > - unsigned HOST_WIDE_INT off
>> > -= (tree_to_uhwi (DECL_FIELD_OFFSET (field))
>> > - + tree_to_uhwi (DECL_FIELD_BIT_OFFSET (field)) / BITS_PER_UNIT);
>> > - if ((off % warn_if_not_align) != 0)
On Tue, Jan 16, 2018 at 12:34 AM, Jan Hubicka wrote:
>> On Mon, Jan 15, 2018 at 5:53 PM, H.J. Lu wrote:
>> > On Mon, Jan 15, 2018 at 3:38 AM, H.J. Lu wrote:
>> >> On Mon, Jan 15, 2018 at 12:31 AM, Richard Biener
>> >> wrote:
>> >>> On Sun, Jan 14, 2018 at 4:08 PM, H.J. Lu wrote:
>> Now my
The port-local FUNCTION_ARG_SIZE:
MODE) != BLKmode \
? (HOST_WIDE_INT) GET_MODE_SIZE (MODE) \
: int_size_in_bytes (TYPE)) + UNITS_PER_WORD - 1) / UNITS_PER_WORD)
is used by code in pa.c and by ASM_DECLARE_FUNCTION_NAME in som.h.
Treating GET_MODE_SIZE as a constant is OK for the f
* Claudiu Zissulescu [2017-11-02 13:30:32
+0100]:
> gcc/
> 2017-03-20 Claudiu Zissulescu
>
> * config/arc/arc-arches.def: Option mrf16 valid for all
> architectures.
> * config/arc/arc-c.def (__ARC_RF16__): New predefined macro.
> * config/arc/arc-cpus.def (em_mini):
Hi Jeff
On 12/01/18 23:00, Jeff Law wrote:
On 01/12/2018 01:45 AM, Christophe Lyon wrote:
Hi,
On 11 January 2018 at 11:58, Sudakshina Das wrote:
Hi Jeff
On 10/01/18 21:08, Jeff Law wrote:
On 01/10/2018 09:25 AM, Sudakshina Das wrote:
Hi Jeff
On 10/01/18 10:44, Sudakshina Das wrote:
Hi,
in this error recovery regression we ICE when we end-up in an
inconsistent state after meaningful diagnostic emitted by
ensure_literal_type_for_constexpr_object and then some redundant /
slightly misleading one emitted by check_static_variable_definition. I
think we can just return early
* Claudiu Zissulescu [2017-11-02 13:30:31
+0100]:
> gcc/
> 2017-02-20 Claudiu Zissulescu
>
> * config/arc/arc-protos.h: Add arc_is_secure_call_p proto.
> * config/arc/arc.c (arc_handle_secure_attribute): New function.
> (arc_attribute_table): Add 'secure_call' attribute.
>
1 - 100 of 117 matches
Mail list logo
