On Sat, Mar 12, 2016 at 09:43:50AM +1030, Alan Modra wrote:
> The underlying problem happens somewhere in tree-ssa-dse.c. So we get
> an indirect jump to a random location instead of a jump to 0.
Well, the testcase is there just to make sure we don't ICE on it.
And, changing just DSE can't be a c
On 03/02/2016 01:31 AM, Richard Biener wrote:
As a general remark I think handling of this simplification is
better done in the reassoc pass (see Jakubs comment #4) given
|| and && associate. So I'd rather go down that route if possible.
This seems to do the trick.
r~
diff --git a/gcc/tests
On Fri, Mar 11, 2016 at 5:41 PM, Michael Meissner
wrote:
> As I was auditing rs6000.md for power9 changes, I noticed that changes I had
> made in 2010 for power7 weren't as effective with power8.
>
> The FCTIWZ/FCTIWUZ instructions convert the scalar floating point value to a
> 32-bit signed/unsig
The underlying problem happens somewhere in tree-ssa-dse.c. So we get
an indirect jump to a random location instead of a jump to 0.
pr58164.c.035t.mergephi1
;; Function foo (foo, funcdef_no=0, decl_uid=1389, cgraph_uid=0, symbol_order=0)
foo ()
{
int x;
:
x = 0;
goto &x;
}
pr58164.c.0
As I was auditing rs6000.md for power9 changes, I noticed that changes I had
made in 2010 for power7 weren't as effective with power8.
The FCTIWZ/FCTIWUZ instructions convert the scalar floating point value to a
32-bit signed/unsigned integer in bits 32-63 of the floating point or vector
register.
On 03/10/2016 11:10 AM, Bernd Schmidt wrote:
When I submitted my previous lra-remat patch, I mentioned I had some
concerns about the way we dealt with register number comparisons, but I
didn't want to change things blindly without a testcase. PR70123 has now
provided such a testcase where we are
This is arguably invalid code, but we certainly shouldn't be faulting in
these kind of situations.
The FSM threader was presented with a computed goto. It was able to
trace values backwards through a PHI to a constant (as in a constant
integer, not a label).
In that case find_taken_edge w
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 Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-6.1-b20160131.sv.po',
On Fri, Mar 11, 2016 at 09:39:58PM +0100, Andreas Schwab wrote:
> I'm getting this crash on ia64 for gcc.c-torture/compile/pr58164.c:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x412286e0 in indirect_jump_optimize () at ../../gcc/ira.c:3865
> 3865 rtx_insn *def
On Thu, 2016-03-10 at 09:40 +0100, Bernd Schmidt wrote:
> This is a case where bogus #line directives can confuse libcpp into
> producing nonsensical line numbers, even leading to a crash later on
> in LTO.
>
> The following patch moves the test earlier to a point where we can
> more
> easily re
On 03/08/2016 07:17 AM, Andreas Schwab wrote:
This is needed to get gcc_version updated.
Andreas.
* configure.ac (CONFIG_STATUS_DEPENDENCIES): Substitute.
* configure: Regenerate.
* Makefile.in: Regenerate.
OK.
jeff
On 03/10/2016 11:10 AM, Bernd Schmidt wrote:
When I submitted my previous lra-remat patch, I mentioned I had some
concerns about the way we dealt with register number comparisons, but I
didn't want to change things blindly without a testcase. PR70123 has now
provided such a testcase where we are
On 03/08/2016 11:27 AM, Szabolcs Nagy wrote:
I'd like to mention musl libc support in the gcc 6 release notes.
(added under a linux section since only linux targets are supported now.)
Is it ok to commit?
Yes.
jeff
On 03/11/2016 03:02 AM, Richard Biener wrote:
[Big snip]
Can you please split out the 'index' introduction as a separate patch
and apply that?
I think it is quite obviously a good idea and might make regression
hunting easier later if needed.
Done. Actual patch installed attached for archival
> The following teaches phiprop to handle the case of aggregate copies
> where the aggregate has non-BLKmode which means it is very likely
> expanded as reg-reg moves (any better test for that apart from
> checking for non-BLKmode?).
!aggregate_value_p comes to mind, but non-BLKmode is the defin
I'm getting this crash on ia64 for gcc.c-torture/compile/pr58164.c:
Program received signal SIGSEGV, Segmentation fault.
0x412286e0 in indirect_jump_optimize () at ../../gcc/ira.c:3865
3865 rtx_insn *def_insn = DF_REF_INSN (DF_REG_DEF_CHAIN (regno));
(gdb) bt
#0 0x412
I posted a series of tests here:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00271.html
as part of the discussion around PR c/68187.
I've cleaned them into DejaGnu form and added them to the existing
test file; they add 16 PASS results to gcc.sum and 48 PASS results
to g++.sum.
Committed to t
PR c/70085 reported a false-positive from -Wmisleading-indentation.
The warning was fixed by the fix for PR c/68187 (r233972), but it seems
worth capturing the reproducer for PR c/70085 as an additional test case,
as it's slightly different to those seen in PR c/68187.
Committed to trunk (as "obv
On Fri, Mar 11, 2016 at 09:27:54AM -0500, Jason Merrill wrote:
> On 03/10/2016 01:39 PM, Jakub Jelinek wrote:
> >+ /* Don't reuse the result of cxx_eval_constant_expression
> >+ call if it isn't a constant initializer or if it requires
> >+ relocations. */
>
> Let's phrase this posit
I've applied this patch which backports my recent trunk changes to
gomp-4_0-branch. Specifically, this patch contains
* nvptx vector state propagation fix, which includes the updated test
fix for pr70009
* combined loop clauses fix
Cesar
2016-03-11 Cesar Philippidis
gcc/c/
* c-parser.
We can't set flag_pie to the default when flag_pic == 0, which may be
set by -fno-pic or -fno-PIC, since the default value of flag_pie is
non-zero when GCC is configured with --enable-default-pie. We need
to initialize flag_pic to -1 so that we can tell if -fpic, -fPIC,
-fno-pic or -fno-PIC is use
On Thu, Mar 10, 2016 at 6:38 PM, Patrick Palka wrote:
> I ran the command
>
> git grep -l "dg-do compile" | xargs grep -l __builtin_abort | xargs grep
> -lw main
>
> to find tests marked as compile-time tests that likely ought to instead
> be marked as run-time tests, by the rationale that they
On 11 March 2016 at 16:31, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> On 03/11/2016 10:55 AM, Jonathan Wakely wrote:
>>
>> The change approved in Jacksonville was to only add the special
>> functions to and not
>>
> That's easy.
> OK, since they changed that and the macro and made it noncondi
On 03/11/2016 10:55 AM, Jonathan Wakely wrote:
The change approved in Jacksonville was to only add the special
functions to and not
That's easy.
OK, since they changed that and the macro and made it nonconditional I
should also drop the old-style macros __WANT_MATH_CANNEVERREMEMBER__ and
th
On Mar 11, 2016, at 7:57 AM, Dominique d'Humières wrote:
> AFAICT pr45076 is fixed on the gcc-4.9, gcc-5 branches, and trunk. I have
> borrowed the machinery in g++.dg/tree-prof/tree-prof.exp for the attached
> patch and tested it on the three branches. Is it OK as such or is there a
> better w
AFAICT pr45076 is fixed on the gcc-4.9, gcc-5 branches, and trunk. I have
borrowed the machinery in g++.dg/tree-prof/tree-prof.exp for the attached patch
and tested it on the three branches. Is it OK as such or is there a better way
to do the testing?
TIA
Dominique
patch-45076
Description:
The change approved in Jacksonville was to only add the special
functions to and not
On Fri, Mar 11, 2016 at 03:19:54PM +, Kyrill Tkachov wrote:
> Hi all,
>
> I've been seeing this test FAIL for a toolchain configured with
> --with-cpu=cortex-a57 in the scan vectoriser dump check because the cost
> model for -mtune=cortex-a57 decides not to vectorise.
>
> This patch disables
Hi all,
As reported in the PR we can end up calling fclose twice on a file, causing an
error.
This patch fixes that by reorganising the logic a bit to ensure we return after
closing
the file the first time.
Bootstrapped and tested on arm-none-linux-gnueabihf
Ok for trunk?
Thanks,
Kyrill
201
On 10/03/16 14:51, James Greenhalgh wrote:
On Thu, Mar 03, 2016 at 11:38:11AM +, Kyrill Tkachov wrote:
Hi all,
This patch fixes the ICE that was introduced by my earlier patch to
aarch64_set_current_function:
FAIL: gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin
-flto-partition
Hi all,
I've been seeing this test FAIL for a toolchain configured with
--with-cpu=cortex-a57 in the
scan vectoriser dump check because the cost model for -mtune=cortex-a57 decides
not to vectorise.
This patch disables the vectoriser cost model and makes this test pass on all
configurations. I
Hi,
this patch fixes PR70045, a graphite 6 regression.
The problem is as follows: in graphite_create_new_loop_guard, a
condition cond_expr is constructed using an upper bound expression *ub.
During the call:
...
exit_edge = create_empty_if_region_on_edge (entry_edge, cond_expr);
...
the c
On Fri, Mar 11, 2016 at 09:27:54AM -0500, Jason Merrill wrote:
> On 03/10/2016 01:39 PM, Jakub Jelinek wrote:
> >+ /* Don't reuse the result of cxx_eval_constant_expression
> >+ call if it isn't a constant initializer or if it requires
> >+ relocations. */
>
> Let's phrase this posit
OK.
Jason
On 03/10/2016 01:39 PM, Jakub Jelinek wrote:
+ /* Don't reuse the result of cxx_eval_constant_expression
+call if it isn't a constant initializer or if it requires
+relocations. */
Let's phrase this positively ("Reuse the result if...").
+ if (new_ctx.ctor != ctx
The following teaches phiprop to handle the case of aggregate copies
where the aggregate has non-BLKmode which means it is very likely
expanded as reg-reg moves (any better test for that apart from
checking for non-BLKmode?). This improves code for the testcase
from
_Z14struct_ternary1SS_b:
.LFB
On Fri, 11 Mar 2016, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we ICE, because we call extract_ops_from_tree
> on COND_EXPR, and that inline asserts it doesn't have 3 operands.
> derive_constant_upper_bound_ops has a big switch on various tree codes,
> but doesn't handle any 3 ar
On Fri, Mar 11, 2016 at 12:11:42PM +, Alan Lawrence wrote:
> On 10/03/16 16:18, Dominique d'Humières wrote:
>
> > The test gfortran.dg/unconstrained_commons.f fails in the 32 bit mode. It
> > needs some regexp
>
> Indeed, confirmed on ARM, sorry for not spotting this earlier.
>
> I believe t
On 10/03/16 16:18, Dominique d'Humières wrote:
> The test gfortran.dg/unconstrained_commons.f fails in the 32 bit mode. It
> needs some regexp
Indeed, confirmed on ARM, sorry for not spotting this earlier.
I believe the variable, if there is one, should always be called 'j', as it is
in the sour
Hi!
On the following testcase we ICE, because we call extract_ops_from_tree
on COND_EXPR, and that inline asserts it doesn't have 3 operands.
derive_constant_upper_bound_ops has a big switch on various tree codes,
but doesn't handle any 3 argument ones right now, so there is no need
to pass the
On Fri, 11 Mar 2016, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on i?86/x86_64 and aarch64, because gen_lowpart
> (pointer to gen_lowpart_general at that spot) doesn't want to handle
> SUBREG of SYMBOL_REF. Fixed by using a variant that doesn't ICE and forcing
> the operand into
On Fri, Mar 11, 2016 at 11:14 AM, Alan Lawrence wrote:
> In this PR, a packed structure containing bitfields, loses part of its
> constant-pool initialization in SRA.
>
> A fuller explanation is on the PR:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013#c11. In short we need to
> treat const
Hi!
The following testcase ICEs on i?86/x86_64 and aarch64, because gen_lowpart
(pointer to gen_lowpart_general at that spot) doesn't want to handle
SUBREG of SYMBOL_REF. Fixed by using a variant that doesn't ICE and forcing
the operand into a register if it can't be optimized without generating
On Fri, 11 Mar 2016, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, we can get a FUNCTION_DECL or LABEL_DECL (on
> questionable code). The patch also removes the default gcc_unreachable (),
> as this is just a debugging aid function, nothing bad happens if we ignore
> some other tree code
Hi!
As the testcase shows, we can get a FUNCTION_DECL or LABEL_DECL (on
questionable code). The patch also removes the default gcc_unreachable (),
as this is just a debugging aid function, nothing bad happens if we ignore
some other tree code.
Bootstrapped/regtested on x86_64-linux and i686-linu
On Fri, Mar 11, 2016 at 12:13 PM, Ilya Enkovich wrote:
> Hi,
>
> This patch is for PR70160. The problem is that when we build
> instructions chain for conversion in STV pass we don't include
> instruction using unitialized register value but don't skip
> them when convert register. This patch si
Hi,
This patch is for PR70160. The problem is that when we build
instructions chain for conversion in STV pass we don't include
instruction using unitialized register value but don't skip
them when convert register. This patch simply fixes it by
skipping such register uses. Bootstrapped and tes
On 04/03/16 17:24, Alan Lawrence wrote:
On 26/02/16 14:52, James Greenhalgh wrote:
gcc/ChangeLog:
* gcc/config/aarch64/aarch64.c (aarch64_function_arg_alignment):
Rewrite, looking one level down for records and arrays.
---
gcc/config/aarch64/aarch64.c | 31 ---
In this PR, a packed structure containing bitfields, loses part of its
constant-pool initialization in SRA.
A fuller explanation is on the PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013#c11. In short we need to
treat constant-pool entries, like function parameters, as both come
'pre-initi
On Fri, Mar 11, 2016 at 4:01 AM, Jeff Law wrote:
>
> As discussed in the BZ, we have multiple problems with how we sort the
> coalesce list during out-of-ssa coalescing.
>
> First, the sort is not stable. If the cost of two coalesce pairs is the
> same, we break the tie by looking at the underlyi
50 matches
Mail list logo
