On April 6, 2018 10:14:37 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>On the following testcase, we try to read from a huge VECTOR_CST that
>doesn't fit into 64 bytes and read completely random number out of it.
>
>The issue is that native_encode_expr has 2 modes of operation, when
>called with 3 a
This fixes a regression present on the 7 and 6 branches in the form of an ICE
on an unrecognizable insn generated for a jump table in PIC mode. It occurs
because the index of the table is folded to a constant at RTL expansion time
and not at the GIMPLE level (this pessimization is fixed on the
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-8.1-b20180401.de.po', h
On Sat, Apr 7, 2018 at 1:49 AM Joel Sherrill wrote:
> Thanks for submitting the patch. This patch is OK to merge to the
> master and all open branches that have this target.
> A corresponding patch for the RTEMS Source Builder is necessary
> because a gcc release with this patch won't be availab
Thanks for submitting the patch. This patch is OK to merge to the
master and all open branches that have this target.
A corresponding patch for the RTEMS Source Builder is necessary
because a gcc release with this patch won't be available for a while.
I am starting a build with this now. If Seba
Hi!
On the following testcase, we try to read from a huge VECTOR_CST that
doesn't fit into 64 bytes and read completely random number out of it.
The issue is that native_encode_expr has 2 modes of operation, when
called with 3 arguments, it is supposed to encode the whole object or
nothing (i.e.
On Thu, Apr 5, 2018 at 8:48 PM, Kito Cheng wrote:
> Theodore Teah sent an mail say "Your assignment/disclaimer process
> with the FSF is currently complete.".
>
> Could you help us to commit that?
Committed. With some riscv{32,64}-{elf,linux,freebsd} cross compiler
build tests, to make sure the
Hi!
All the gcc targets for RTEMS include gcc/config/rtems.h in tm_file to add
specific linker options using LIB_SPEC.
This patch simply intends to add the same to the x86_64 target.
There are no tests in this patch because I don't see any tests for any of the
other RTEMS targets - let me know i
Hi,
2018-04-06 12:15 GMT+02:00 Sameera Deshpande :
> Hi Christophe,
>
> Please find attached the updated patch with testcases.
>
> Ok for trunk?
Thanks for the update.
Since the new intrinsics are only available on aarch64, you want to
prevent the tests from running on arm.
Indeed gcc.target/aar
On Thu, 2018-03-29 at 09:20 -0400, Jason Merrill wrote:
> On Wed, Mar 28, 2018 at 4:44 PM, David Malcolm
> wrote:
> > This followup patch updates the specific error-handling path
> > to add a note showing the pertinent parameter decl, taking
> > the output from:
> >
> > test.cc: In function 'void
Hi,
On 06/04/2018 19:04, Jason Merrill wrote:
On Fri, Apr 6, 2018 at 5:01 AM, Paolo Carlini wrote:
here, for an incomplete type we ICE pretty soon in find_decomp_class_base.
Comparing to other cases too, I convinced myself that trying to complete the
type is Ok. Also, it seems that in these fu
On Fri, Apr 06, 2018 at 06:52:36PM +0200, Thomas König wrote:
>
> the attached patch fixes a buffer overrun in matmul, an 8 regression.
> No test case since this was only detectable with the address sanitizer
> or with valgrind.
>
> Regression-tested on trunk. OK?
>
Yes.
--
Steve
On Mon, Mar 26, 2018 at 01:17:22PM -0400, Jason Merrill wrote:
> On Sat, Mar 24, 2018 at 6:59 AM, Marek Polacek wrote:
> > Recently the code in finish_static_assert was changed to use
> > perform_implicit_conversion_flags followed by fold_non_dependent_expr. That
> > broke this test becase when i
Here, since the condition for the constexpr if depends on the type of
'j', it's still dependent when we are partially instantiating the
inner lambda, so we need to defer instantiating the constexpr if.
When we instantiated the inner lambda, we tried to substitute into the
typename, which failed bec
Hi!
As mentioned in the PR, we ICE on the following zero sized array
initializers, while domain is non-NULL and TYPE_MIN_VALUE is size_int (0),
TYPE_MAX_VALUE is NULL and not INTEGER_CST compare_tree_int assumes it is.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-04-
On April 6, 2018 6:04:48 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>When create_preheader is called with CP_FALLTHRU_PREHEADERS and
>the loop header is cold, but the bb dominating the loop is hot (or vice
>versa) and there are just 2 incoming edges into the header, we use
>split_edge, which unfort
On April 6, 2018 6:10:14 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>As mentioned in the PR, we ICE on the following zero sized array
>initializers, while domain is non-NULL and TYPE_MIN_VALUE is size_int
>(0),
>TYPE_MAX_VALUE is NULL and not INTEGER_CST compare_tree_int assumes it
>is.
>
>Bootstra
OK.
On Fri, Apr 6, 2018 at 11:44 AM, Jakub Jelinek wrote:
> Hi!
>
> During parsing we report error here, the decomp id shadowing parameter,
> but we still have a VAR_DECL for the decomp id, only during
> tsubst_decomp_names tsubst returns a PARM_DECL for it.
>
> I believe and (the code asserts th
On Fri, Apr 6, 2018 at 5:01 AM, Paolo Carlini wrote:
> here, for an incomplete type we ICE pretty soon in find_decomp_class_base.
> Comparing to other cases too, I convinced myself that trying to complete the
> type is Ok. Also, it seems that in these functions we want to talk about
> structured b
Hello world,
the attached patch fixes a buffer overrun in matmul, an 8 regression.
No test case since this was only detectable with the address sanitizer
or with valgrind.
Regression-tested on trunk. OK?
Regards
Thomas
2018-04-06 Thomas Koenig
PR libfortran/85253
*
Hi!
During parsing we report error here, the decomp id shadowing parameter,
but we still have a VAR_DECL for the decomp id, only during
tsubst_decomp_names tsubst returns a PARM_DECL for it.
I believe and (the code asserts that) this can only happen during error
recovery and we just should punt o
Hi!
When create_preheader is called with CP_FALLTHRU_PREHEADERS and
the loop header is cold, but the bb dominating the loop is hot (or vice
versa) and there are just 2 incoming edges into the header, we use
split_edge, which unfortunately make the new bb use the partition of the
source rather than
On Tue, 3 Apr 2018, Andrey Belevantsev wrote:
> Hello,
>
> In these PRs we deal with the dependencies we are forced to make between a
> debug insn and its previous insn (unless bb head). In the latter case, if
> such an insn has been moved, we fixup its movement so it aligns with the
> sel-sched
On 06/04/18 17:08, Ramana Radhakrishnan wrote:
On 06/04/2018 16:54, Thomas Preudhomme wrote:
Instruction pattern for setting the FPSCR expects the input value to be
in a register. However, __builtin_arm_set_fpscr expander does not ensure
that this is the case and as a result GCC ICEs when the
On Tue, 3 Apr 2018, Andrey Belevantsev wrote:
> Hello,
>
> This issue ended up being fixed the way different from described in the PR.
> We do not want to walk away from the invariant "zero SCHED_TIMES -- insn
> is not scheduled" even for bookkeeping copies (testing showed it trips over
> assert
On 06/04/2018 16:54, Thomas Preudhomme wrote:
> Instruction pattern for setting the FPSCR expects the input value to be
> in a register. However, __builtin_arm_set_fpscr expander does not ensure
> that this is the case and as a result GCC ICEs when the builtin is
> called with a constant literal.
>
When code containing "naked" function gets compiled with '-fstack-usage'
compiler prints the following warning:
-->8-
board/synopsys/hsdk/hsdk.c: In function 'hsdk_core_init_f':
board/synopsys/hsdk/hsdk.c:345:1: warning: stack usage comput
On Tue, 3 Apr 2018, Andrey Belevantsev wrote:
> Hello,
>
> This issues is about the correct order in which we need to call the
> routines that fix up the control flow for us.
OK with formatting both in the new comment and the Changelog fixed.
> Best,
> Andrey
>
> 2018-04-03 Andrey Belevantsev
On Tue, 3 Apr 2018, Andrey Belevantsev wrote:
> Hello,
>
> This issue is when we cannot correctly make insn tick data for the
> unscheduled code (but processed by the modulo scheduler). Fixed by closely
> following usual scheduling process as described in the PR.
This is ok with the following n
Instruction pattern for setting the FPSCR expects the input value to be
in a register. However, __builtin_arm_set_fpscr expander does not ensure
that this is the case and as a result GCC ICEs when the builtin is
called with a constant literal.
This commit fixes the builtin to force the input valu
On Fri, Apr 06, 2018 at 06:48:52AM -0700, Cesar Philippidis wrote:
> 2018-04-06 Cesar Philippidis
>
> PR middle-end/84955
>
> gcc/
> * cfgloop.c (flow_loops_find): Add assert.
> * omp-expand.c (expand_oacc_for): Add dummy false branch for
> tiled basic blocks wi
OK.
On Thu, Apr 5, 2018 at 7:40 PM, David Malcolm wrote:
> On Thu, 2018-03-29 at 15:25 -0400, Jason Merrill wrote:
>> On Thu, Mar 22, 2018 at 7:44 PM, David Malcolm
>> wrote:
>> > We provide fix-it hints for the most common "std" names when an
>> > explicit
>> > "std::" prefix is present, howeve
Here, we were trying to start defining a template in the middle of the
template parameter list for another template. Adjusting the
PROCESSING_REAL_TEMPLATE_DECL_P macro to exclude this situation seems
appropriate.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f7bcdc914de03d87a99bc7ebd85fe
poplevel already tries to keep undeduced autos out of BLOCK_VARS, but
in this testcase cp_genericize_r was adding one in later on.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 61f3456c563fd7b3354a688f40c1afbfa8423442
Author: Jason Merrill
Date: Fri Apr 6 07:45:01 2018 -0400
As shown in PR84955, GCC has problems empty infinite loops of the form
#pragma acc loop tile (2, 2)
for (...)
for (...)
{
for (...)
/* do nothing */
;
}
I also observed that it generates bad code for the following loop
#pragma acc loop
for (...)
{
Patch has been reverted as r259169 as requested.
Sorry for the breakage,
Tamar.
> -Original Message-
> From: Richard Biener
> Sent: Friday, April 6, 2018 12:36
> To: Eric Botcazou
> Cc: gcc-patches@gcc.gnu.org; Alan Modra ; Tamar
> Christina ; nd ;
> l...@redhat.com; i...@airs.com; berg
> -Original Message-
> From: Richard Biener
> Sent: Friday, April 6, 2018 12:36
> To: Eric Botcazou
> Cc: gcc-patches@gcc.gnu.org; Alan Modra ; Tamar
> Christina ; nd ;
> l...@redhat.com; i...@airs.com; berg...@vnet.ibm.com
> Subject: Re: [PATCH][GCC][mid-end] Fix PR85123 incorrect copi
On Fri, 6 Apr 2018, Jonathan Wakely wrote:
> On 6 April 2018 at 12:48, Jonathan Wakely wrote:
> > Currently --with-default-libstdcxx-abi doesn't alter the ABI of the
> > shared lib when the dual-abi is enabled, just whether the initial
> > value of the macro is 0 or 1. All the symbols in the libra
On 6 April 2018 at 12:48, Jonathan Wakely wrote:
> Currently --with-default-libstdcxx-abi doesn't alter the ABI of the
> shared lib when the dual-abi is enabled, just whether the initial
> value of the macro is 0 or 1. All the symbols in the library, and the
> type of exception thrown, are the same
On 6 April 2018 at 12:22, Richard Biener wrote:
> On Fri, 6 Apr 2018, Jonathan Wakely wrote:
>
>> On 6 April 2018 at 10:39, Richard Biener wrote:
>> >
>> > The following allows people configuring the gcc-4 compatible ABI
>> > as the default ABI to retain compatibility with old programs
>> > catchin
The following fixes PR85244 where we fail to handle a flex-array
reference as such and constrain it with the appearant size of an external
declaration. The fix is to handle this case much like the unconstrained
common one and to not regress some cases the patch adjusts the handling
of flex-array
On Fri, 6 Apr 2018, Eric Botcazou wrote:
> > I wonder if it's best to revert the original regression causing patch
> > and look for a proper solution in the GCC 9 timeframe?
>
> Probably the best course of action indeed, as changes in this area need to be
> thoroughly tested on various targets t
> I wonder if it's best to revert the original regression causing patch
> and look for a proper solution in the GCC 9 timeframe?
Probably the best course of action indeed, as changes in this area need to be
thoroughly tested on various targets to cover all the cases.
--
Eric Botcazou
On Fri, 6 Apr 2018, Jonathan Wakely wrote:
> On 6 April 2018 at 10:39, Richard Biener wrote:
> >
> > The following allows people configuring the gcc-4 compatible ABI
> > as the default ABI to retain compatibility with old programs
> > catching ios_base::failure by matching the abi version thrown
>
On 6 April 2018 at 10:39, Richard Biener wrote:
>
> The following allows people configuring the gcc-4 compatible ABI
> as the default ABI to retain compatibility with old programs
> catching ios_base::failure by matching the abi version thrown
> to the configured default ABI.
>
> This doesn't reall
On Fri, 6 Apr 2018, Alan Modra wrote:
> On Thu, Apr 05, 2018 at 01:29:06PM +0100, Tamar Christina wrote:
> > diff --git a/gcc/expr.c b/gcc/expr.c
> > index
> > 00660293f72e5441a6421a280b04c57fca2922b8..7daeb8c91d758edf0b3dc37f6927380b6f3df877
> > 100644
> > --- a/gcc/expr.c
> > +++ b/gcc/expr.c
On 6 April 2018 at 09:50, Marc Glisse wrote:
> On Fri, 6 Apr 2018, Jonathan Wakely wrote:
>
>> This attempts to solve some of the problems when mixing std::valarray
>> operations and 'auto', by storing nested closure objects as values
>> instead of references. This means we don't end up with dangli
On Thu, 5 Apr 2018, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, on the following testcase we cp_save_expr in order
> to avoid evaluating -1 * __builtin_expect (({ ... }), ...) twice and use
> the SAVE_EXPR in the original shift as well as in a comparison, but then
> we attempt to optim
Hi Christophe,
Please find attached the updated patch with testcases.
Ok for trunk?
- Thanks and regards,
Sameera D.
2017-12-14 22:17 GMT+05:30 Christophe Lyon :
> 2017-12-14 9:29 GMT+01:00 Sameera Deshpande :
>> Hi!
>>
>> Please find attached the patch implementing vld1_*_x3, vst1_*_x2 and
>
The following allows people configuring the gcc-4 compatible ABI
as the default ABI to retain compatibility with old programs
catching ios_base::failure by matching the abi version thrown
to the configured default ABI.
This doesn't really fix the PR but it makes behavior between
the dual-ABI with
From: claziss
Hi Andrew,
Please find a the following patches which are fixing a number of issues in ARC
toolchain.
//Claudiu
[ARC] Update movhi and movdi patterns.
This patch allows st w6,[b, s9] instructions to be used.
[ARC] Cleanup sdata handling.
This cleanup is requi
From: Claudiu Zissulescu
Allow signed 6-bit short immediates into st[d] instructions.
2017-10-19 Claudiu Zissulescu
* config/arc/arc.c (arc_split_move): Allow signed 6-bit constants
as source of std instructions.
* config/arc/arc.md (movsi_insn): Update pattern predic
Hi,
here, for an incomplete type we ICE pretty soon in
find_decomp_class_base. Comparing to other cases too, I convinced myself
that trying to complete the type is Ok. Also, it seems that in these
functions we want to talk about structured binding and use an
appropriate location, thus no comp
From: Claudiu Zissulescu
Clean up how we handle small data load/store operations. This patch clears
-flto-fat-lto-object LTO related errors.
gcc/
2018-01-18 Claudiu Zissulescu
* config/arc/arc-protos.h (prepare_extend_operands): Remove.
(small_data_pattern): Likewise.
From: claziss
Claudiu Zissulescu
* config/arc/arc.md ("vunspec"): Delete it, unify all the unspec
enums into a single definition.
(fls): Fix predicates and printing.
(seti): Likewise.
---
gcc/config/arc/arc.md | 14 +-
1 file changed, 5 insertions(+
Clear the instruction cache from `beg' to `end'. This makes an inline
system call to SYS_cacheflush.
gcc/
2017-03-28 Claudiu Zissulescu
* config/arc/linux.h (CLEAR_INSN_CACHE): Define.
---
gcc/config/arc/linux.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/gcc/
From: claziss
gcc/
2017-05-09 Claudiu Zissulescu
* config/arc/arc-protos.h (check_if_valid_sleep_operand): Remove.
* config/arc/arc.c (arc_expand_builtin): Sleep accepts registers
and short u6 immediate.
(check_if_valid_sleep_operand): Remove.
* config/
On Fri, 6 Apr 2018, Jonathan Wakely wrote:
This attempts to solve some of the problems when mixing std::valarray
operations and 'auto', by storing nested closure objects as values
instead of references. This means we don't end up with dangling
references to temporary closures that have already b
This attempts to solve some of the problems when mixing std::valarray
operations and 'auto', by storing nested closure objects as values
instead of references. This means we don't end up with dangling
references to temporary closures that have already been destroyed.
This makes the closure objects
gcc/testsuite/ChangeLog:
2018-04-06 Andreas Krebbel
* gcc.target/s390/vector/vcond-shift.c: Use the proper conditions
to trigger the optimization. Do some cleanup and function
renaming. Add more test functions.
---
gcc/testsuite/gcc.target/s390/vector/vcond-shift.c |
We still use lr r0,r0 as a NOP instruction although we have some kind
of dedicated NOP instruction (nopr) which maps to a "branch never".
As a side-effect this fixes testcases scanning for NOPs
e.g. patchable_function_entry-*.
As another side-effect this makes it difficult to distingiush NOPs
gen
On IBM Z we enforce function alignment to 8 bytes. Hence we get an
error instead of a warning when trying to specify smaller alignments.
gcc/testsuite/ChangeLog:
2018-04-06 Andreas Krebbel
* c-c++-common/Wattributes.c: Disable warning for s390* target and
check for an error i
These patch fix a couple of testsuite fails for IBM Z.
Bootstrapped and regression tested on s390x.
Committed to mainline
Andreas Krebbel (3):
Wattributes.c testcase: Disable warning check for IBM Z.
IBM Z: Use the dedicated NOP instructions for "nop"
IBM Z: Fix vcond-shift testcase.
gcc
63 matches
Mail list logo
