On 05/28/2014 02:54 PM, Jeff Law wrote:
> On 05/28/14 15:52, Jakub Jelinek wrote:
>> On Wed, May 28, 2014 at 05:28:31PM -0400, Kai Tietz wrote:
>>> Yes, I missed the plus-part.
>>>
>>> I am just running bootstrap with regression testing for altering predicate
>>> to:
>>>
>>> (define_predicate "sib
On 05/28/2014 01:43 AM, Kai Tietz wrote:
> + if (GET_CODE (op) == CONST)
> +op = XEXP (op, 0);
> + return (GET_CODE (op) == SYMBOL_REF || CONSTANT_P (op));
Surely all this boils down to just CONSTANT_P (op),
without having to look through the CONST at all.
Otherwise this looks ok.
r~
On 05/27/2014 09:48 AM, Jeff Law wrote:
>> leaofs(base, index, scale), %eax
>> ...
>> call*0(%eax)
>>
>> we might as well include the memory load
>>
>> movofs(base, index, scale), %eax
>> ...
>> call*%eax
> Ok. My misunderstanding.
>
> Granted, this probabl
On 05/27/2014 08:39 AM, Jeff Law wrote:
> But the value we want may be sitting around in a convenient register (such as
> r11). So if we force the sibcall to use %rax, then we have to generate a
> copy. Yet if we have a constraint for the set of registers allowed here, then
> we give the register
On 05/22/2014 02:33 PM, Kai Tietz wrote:
> * config/i386/i386.c (ix86_expand_call): Enforce for sibcalls
> on memory the use of accumulator-register.
I don't like this at all.
I'm fine with allowing memories that are fully symbolic, e.g.
extern void (*foo)(void);
void f(void) { foo()
> +(define_expand "one_cmpl2"
> + [(match_operand:IMSA 0 "register_operand")
> + (match_operand:IMSA 1 "register_operand")]
> + "ISA_HAS_MSA"
> +{
> + if (mode == V16QImode)
> +emit_insn (gen_msa_nori_b (operands[0], operands[1], const0_rtx));
> + else
> +{
> + rtx reg = gen_reg_
On 05/05/2014 09:54 AM, Evgeny Stupachenko wrote:
> @@ -42943,6 +42944,10 @@ expand_vec_perm_1 (struct expand_vec_perm_d *d)
>if (expand_vec_perm_vpermil (d))
> return true;
>
> + /* Try palignr on one operand. */
> + if (d->one_operand_p && expand_vec_perm_palignr (d))
> +return t
On 05/05/2014 09:49 AM, Evgeny Stupachenko wrote:
> @@ -42946,6 +42948,10 @@ expand_vec_perm_1 (struct expand_vec_perm_d *d)
>if (expand_vec_perm_pshufb (d))
> return true;
>
> + /* Try the AVX2 vpshufb. */
> + if (expand_vec_perm_vpshufb2_vpermq (d))
> +return true;
Why is this h
On 05/19/2014 05:15 AM, Marcus Shawcroft wrote:
> On 1 April 2014 23:24, Richard Henderson wrote:
>> Comments? If approved, should this go in for 4.9, or wait for stage1?
>> Certainly it's self-contained...
>
>
> Hi, I think this should go in, with the c
On 05/14/2014 02:47 PM, Cary Coutant wrote:
>>> PR debug/61013
>>> * opts.c (common_handle_option): Don't special-case "-g".
>>> (set_debug_level): Default to at least level 2 with "-g".
>>
>> Ok. Thanks,
>
> Forgot to ask -- OK to backport to the 4.9 branch?
Yes please.
r~
On 05/14/2014 02:36 PM, Cary Coutant wrote:
> PR debug/61013
> * opts.c (common_handle_option): Don't special-case "-g".
> (set_debug_level): Default to at least level 2 with "-g".
Ok. Thanks,
r~
On 05/08/2014 01:12 PM, Richard Sandiford wrote:
> * wide-int.cc: Only include longlong.h if W_TYPE_SIZE==32 or
> __SIZEOF_INT128__ is defined.
FWIW, this looks pretty good to me.
r~
On 04/25/2014 05:45 AM, Marek Polacek wrote:
> 2014-04-25 Marek Polacek
>
> PR c/60351
> * c-typeck.c (build_binary_op): Use location when warning about
> shift count.
>
> * gcc.dg/pr60351.c: New test.
Ok.
r~
On 04/29/2014 01:59 AM, Tom de Vries wrote:
> On 24-04-14 17:13, Eric Botcazou wrote:
>>> The hook is called right after expansion of calls, and allows a target to do
>>> additional processing, such as f.i. adding clobbers to
>>> CALL_INSN_FUNCTION_USAGE.
>>>
>>> Instead of using the hook, we could
On 04/25/2014 08:44 AM, Marek Polacek wrote:
> 2014-04-25 Marek Polacek
>
> PR c/60139
> * c-typeck.c (output_init_element): Pass OPT_Wpedantic to pedwarn
> and pedwarn_init. Use loc insted of input_location.
>
> * gcc.dg/pr60139.c: New test.
Ok.
r~
On 04/29/2014 05:42 AM, Richard Earnshaw wrote:
> On 23/04/14 16:20, Alan Lawrence wrote:
>> This patch is a small tidy of a more-complicated expression that just flips
>> a
>> single bit and can thus be a simple XOR.
>>
>> No regressions on aarch64-none-elf or aarch64_be-none-elf. (I've verified
On 04/29/2014 10:13 AM, Evgeny Stupachenko wrote:
> + /* For a rotaion permutation with one operand like: {5 6 7 0 1 2 3 4}
> + PALIGNR is better than PSHUFB. Check for a rotation in permutation. */
> + for (i = 0; i < nelt; ++i)
> +if d->perm[(i + 1) & (nelt - 1)] - d->perm[i])) &
On 04/29/2014 06:50 AM, Evgeny Stupachenko wrote:
> + if (d->one_operand_p != true)
> +return false;
This looks odd. Better as !d->one_operand_p.
> +
> + /* For an in order permutation with one operand like: {5 6 7 0 1 2 3 4}
> + PALIGNR is better than PSHUFB. Check for an order in pe
On 04/28/2014 01:43 PM, Evgeny Stupachenko wrote:
> Agree on checks:
>
> /* PALIGNR of 2 128-bits registers takes only 1 instrucion.
> Requires SSSE3. */
> if (GET_MODE_SIZE (d->vmode) == 16)
> {
> if(!TARGET_SSSE3)
> return false;
> }
> /* PALIGNR of 2 256-bits r
On 04/17/2014 06:09 AM, Yuri Rumyantsev wrote:
> + /* Build cond expression using COND and constant operand
> + of reduction rhs. */
> + c = fold_build_cond_expr (TREE_TYPE (rhs1),
> + unshare_expr (cond),
> + swap? zero: op1,
> +
On 04/28/2014 08:00 AM, Eric Botcazou wrote:
> You can re-apply the gcc-interface/Makefile.in hunk
> (I reverted it as well) but you first need to adjust it to the mainline.
Done, after re-bootstrapping on aarch64 Just to Be Sure.
r~
On 04/28/2014 09:48 AM, Evgeny Stupachenko wrote:
> - /* Even with AVX, palignr only operates on 128-bit vectors. */
> - if (!TARGET_SSSE3 || GET_MODE_SIZE (d->vmode) != 16)
> + /* PALIGNR of 2 256-bits registers on AVX2 costs only 2 instructions:
> + PERM and PALIGNR. It is more profitabl
On 04/23/2014 01:37 PM, Eric Botcazou wrote:
>> But it breaks on IA-64 for the same reason as on Aarch64 so we'll need to
>> > find something else.
> Tentative revised patch attached. Can you give it a try when you have some
> time? There is a rationale based on my understanding in types.h. TIA
On 04/23/2014 01:45 PM, Mike Stump wrote:
> * gengtype.c: Remove include of double-int.h.
> (do_typedef): Use wide-int interfaces.
> (open_base_files): Add wide-int.h.
> (main): Add offset_int and widest_int typedefs.
> * gengtype-lex.l: Handle "^".
> (CXX_KEYWOR
On 04/23/2014 12:43 PM, Marc Glisse wrote:
> Would mangling the aarch64 builtins be a lot of work? Did other platforms
> break
> as well?
Hmm. Apparently, aarch64 already *has* mangling support, but it's broken.
The node is built with DFmode in aarch64_init_simd_builtins, but then (not)
matched
On 04/23/2014 12:43 PM, Marc Glisse wrote:
>> Any c++ compilation aborts at
>
> That's surprising, the code I touched is only ever supposed to run while
> compiling one file in libsupc++, if I understand correctly.
Ah, well, perhaps it's one of the first built for stage1 libstdc++.
I admit to not
On 04/23/2014 12:56 PM, Jeff Law wrote:
> On 04/22/14 15:38, Richard Henderson wrote:
>> On 04/22/2014 10:13 AM, David Malcolm wrote:
>>> On Mon, 2014-04-21 at 18:45 -0400, Trevor Saunders wrote:
>>>>> --- a/gcc/tree-loop-distribution.c
>>>>> ++
On 04/13/2014 01:41 AM, Marc Glisse wrote:
> Hello,
>
> this patch generates typeinfo for target types. On x86_64, it adds these 6
> lines to nm -C libsupc++.a. A follow-up patch will be needed to export and
> version those in the shared library.
>
> + V typeinfo for __float128
>
On 04/22/2014 10:13 AM, David Malcolm wrote:
> On Mon, 2014-04-21 at 18:45 -0400, Trevor Saunders wrote:
>>> --- a/gcc/tree-loop-distribution.c
>>> +++ b/gcc/tree-loop-distribution.c
>>> @@ -687,8 +687,9 @@ generate_loops_for_partition (struct loop *loop,
>>> partition_t partition,
>>>
On 04/21/2014 01:19 PM, Bill Schmidt wrote:
> + if (GET_CODE (trueop0) == VEC_SELECT
> + && GET_MODE (XEXP (trueop0, 0)) == mode)
> + {
> + rtx op0_subop1 = XEXP (trueop0, 1);
> + gcc_assert (GET_CODE (op0_subop1) == PARALLEL);
> + gcc_assert (XVECLEN (trueop1, 0) =
On 04/16/2014 12:55 AM, Eric Botcazou wrote:
>> Similarly with the HAVE_GNAT_ALTERNATE_STACK stuff. There aren't any
>> linux hosts that don't support sigaltstack, so why is this
>> conditionalized?
>
> Hum, I didn't know that Android also used the alternate stack... OK, let's
> use it uncondit
Building mainline I got
> .../aarch64.c:4879:134: error: invalid conversion from ‘reg_class_t {aka
> int}’ to ‘machine_mode’ [-fpermissive]
>if (! TARGET_SIMD && GET_MODE_SIZE (from) == 128 && GET_MODE_SIZE (to) ==
> 128)
Sure enough, TO and FROM are not modes. Did mainline just change awa
On 04/17/2014 08:56 AM, Eric Botcazou wrote:
> I presume that the attached kludge is sufficient to make it work?
>
>
> * fe.h (Compiler_Abort): Replace Fat_Pointer by String.
> (Error_Msg_N): Likewise.
> (Error_Msg_NE): Likewise.
> (Get_External_Name_With_Suffix): Likewise
On 04/17/2014 08:35 AM, Tristan Gingold wrote:
> What about this compile-time check:
>
> package Fatptralign is
>type String_Acc is access String;
>type Integer_acc is access Integer;
>
>pragma Compile_Time_Error
> (String_Acc'Alignment = 1 * Integer_Acc'Alignment,
> "Fat poi
On 04/17/2014 02:00 AM, Tristan Gingold wrote:
>
> On 16 Apr 2014, at 17:36, Richard Henderson wrote:
>
>> On 04/16/2014 12:39 AM, Eric Botcazou wrote:
>>>> The primary bit of rfc here is the hunk that applies to ada/types.h
>>>> with respect to Fat_Pointe
On 04/14/2014 10:32 AM, Marek Polacek wrote:
> + if (TREE_CODE (val) != IDENTIFIER_NODE
> + && TREE_CODE (val) != FUNCTION_DECL)
> + val = default_conversion (val);
> + else if (TREE_CODE (val) == IDENTIFIER_NODE)
> + {
> + tree t = lookup_name (val);
> + if (t &
On 04/16/2014 12:39 AM, Eric Botcazou wrote:
>> The primary bit of rfc here is the hunk that applies to ada/types.h
>> with respect to Fat_Pointer. Given that the Ada type, as defined in
>> s-stratt.ads, does not include alignment, I can't imagine why the C
>> type should have it.
>
> See gcc-int
On 04/10/2014 09:10 AM, Jakub Jelinek wrote:
> 2014-04-10 Jakub Jelinek
>
> PR rtl-optimization/60663
> * cse.c (cse_insn): Set src_volatile on ASM_OPERANDS in
> PARALLEL.
>
> * gcc.target/arm/pr60663.c: New test.
Ok if it passes.
But you're right that ARM backend nee
On 04/07/2014 04:33 AM, Rainer Orth wrote:
> The patch allowed i386-pc-solaris2.11 bootstraps to finish without
> regressions on trunk and 4.8 branch, still need to test 4.7 branch.
>
> Ok for trunk, 4.8 and 4.7 branches once testing completes?
>
> Rainer
>
>
> 2014-04-07 Rainer Orth
>
On 04/04/2014 01:45 PM, Bill Schmidt wrote:
> Per Richard Henderson's previous comment, I have changed the
> patch slightly to avoid the use of emit_move_insn.
Thanks.
r~
As recently pointed out in a thread porting libitm to aarch64, the PAGE_SIZE
and FIXED_PAGE_SIZE macros are unused. Indeed, not all of the ports actually
defined them at all.
Removed, lest they cause further confusion.
r~
* config/alpha/target.h (PAGE_SIZE, FIXED_PAGE_SIZE): Remove.
On 04/01/2014 03:41 PM, Andrew Pinski wrote:
> On Tue, Apr 1, 2014 at 3:24 PM, Richard Henderson wrote:
>> Comments? If approved, should this go in for 4.9, or wait for stage1?
>> Certainly it's self-contained...
>
> On Cavium's thunder processor the cache line si
j.S b/libitm/config/aarch64/sjlj.S
new file mode 100644
index 000..4a5e758
--- /dev/null
+++ b/libitm/config/aarch64/sjlj.S
@@ -0,0 +1,90 @@
+/* Copyright (C) 2014 Free Software Foundation, Inc.
+ Contributed by Richard Henderson .
+
+ This file is part of the GNU Transactional Memory Library (l
On 04/01/2014 08:22 AM, H.J. Lu wrote:
> On Tue, Apr 1, 2014 at 7:48 AM, Richard Henderson wrote:
>> Yet more fallout from my float->int changes.
>>
>> This time the failure is during sched1, where we try to constrain_operands to
>> figure out what the sched parame
Yet more fallout from my float->int changes.
This time the failure is during sched1, where we try to constrain_operands to
figure out what the sched parameters are for the insn. Except that since this
is before register allocation, where we are going to force the operand to
memory, there were no
On 03/28/2014 08:24 AM, Jakub Jelinek wrote:
> Here is the variant patch, which implements the above.
> Also bootstrapped/regtested on x86_64-linux and i686-linux.
>
> 2014-03-28 Jakub Jelinek
>
> PR c++/60689
> * c-tree.h (c_build_function_call_vec): New prototype.
> * c-typ
On 03/27/2014 06:51 AM, Jakub Jelinek wrote:
> Did you mean Jeff's original change, or say:
> --- gcc/config/i386/i386.c2014-03-20 17:41:45.917689676 +0100
> +++ gcc/config/i386/i386.c2014-03-27 14:47:21.876254288 +0100
> @@ -13925,13 +13925,13 @@ ix86_legitimize_address (rtx x, rtx oldx
>
On 03/26/2014 12:40 PM, Jakub Jelinek wrote:
> On Wed, Mar 26, 2014 at 01:32:44PM -0600, Jeff Law wrote:
>> On 03/26/14 12:28, Jakub Jelinek wrote:
>>> (mult:SI (const_int 0) (const_int 4)) is IMHO far from being canonical.
>>> And, I'd say it is likely other target legitimization hooks would also
On 03/24/2014 06:23 AM, Michael Matz wrote:
> I can't say why we have the !PUSH_ARGS_REVERSED path (so I guess that's
> the way that initially was there, before the distinction was made), but
> the PUSH_ARGS_REVERSED==1 path is important when you have push
> instructions and arguments grow in th
On 02/21/2014 08:30 AM, Tejas Belagod wrote:
> + /* If two vectors, we end up with a wierd mixed-endian mode on NEON.
> */
> + if (BYTES_BIG_ENDIAN)
> + {
> + if (!d->one_vector_p && d->perm[i] & nunits)
> + {
> + /* Extract the offset. */
> + elt
On 03/21/2014 01:38 PM, Jakub Jelinek wrote:
> PR target/60610
> * config/i386/i386.h (TARGET_64BIT_P): If not TARGET_BI_ARCH,
> redefine to 1 or 0.
> * config/i386/darwin.h (TARGET_64BIT_P): Redefine to
> TARGET_ISA_64BIT_P(x).
Ok.
r~
On 03/20/2014 06:38 PM, Bill Schmidt wrote:
> - rtx splat = gen_rtx_VEC_DUPLICATE (V16QImode,
> - gen_rtx_CONST_INT (QImode, -1));
> + rtx notx = gen_rtx_NOT (V16QImode, force_reg (V16QImode, x));
> + rtx andx = gen_rtx_AND (V16QImode, notx, notx)
On 03/18/2014 04:59 AM, Jakub Jelinek wrote:
> On Mon, Mar 17, 2014 at 03:24:14PM -0400, Vladimir Makarov wrote:
>> It is complicated. There is no guarantee that it is used only for
>> addresses. I need some time to think how to fix it.
>>
>> Meanwhile, you *should* commit the patch into the trun
Brown bag time on this one. While I did build and test both x86_64 and i686
separately, I apparently only missed the regression in test results.
Anyway, a simple fix for the problem: don't enable the pattern when it's not
supposed to be enabled due to excess precision. Moving the _387 pattern do
On 03/17/2014 11:47 AM, Jakub Jelinek wrote:
> 2014-03-17 Jakub Jelinek
>
> PR target/60516
> * config/i386/i386.c (ix86_expand_epilogue): Adjust REG_CFA_ADJUST_CFA
> note creation for the 2010-08-31 changes.
>
> * gcc.target/i386/pr60516.c: New test.
Ok.
r~
This PR is fallout from my patch from yesterday, which adjusted some of the
i386 float->int conversion patterns. In the gcc-patches message for that
change, I opined that in stage1 we should clean up all of these patterns.
Except that the existing state of affairs appears to have been too complex
The original ICE is caused by the dwarf2cfi pass not noticing a stack
adjustment in the insn stream. The reason for the miss is that the push/pop
was added by a post-reload splitter, which did nothing to mark the insn for
special treatment.
In the PR, Jakub and I threw around several ideas.
My f
On 03/03/2014 04:48 AM, Torvald Riegel wrote:
> Should I add myself as maintainer for libitm?
Yes.
> Does this come with any other responsibilities than reviewing patches?
No.
r~
On 02/17/2014 11:45 AM, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2014-02-17 Jakub Jelinek
>
> PR middle-end/60175
> * function.c (expand_function_end): Don't emit
> clobber_return_register sequence if clobber_after is a B
On 02/26/2014 10:09 PM, Alexandre Oliva wrote:
> Regstrapped on x86_64-linux-gnu and i686-linux-gnu, along with the other
> patch for PR debug/59992. Ok to install?
>
>
> for gcc/ChangeLog
>
> PR debug/59992
> * cselib.c (cselib_hasher::equal): Special-case VALUE lookup.
> (c
On 02/25/2014 09:02 AM, Alex Velenko wrote:
> +(define_expand "aarch64_reinterpretdf"
> + [(match_operand:DF 0 "register_operand" "")
> + (match_operand:VD_RE 1 "register_operand" "")]
> + "TARGET_SIMD"
> +{
> + aarch64_simd_reinterpret (operands[0], operands[1]);
> + DONE;
> +})
I believe y
On 02/25/2014 07:56 AM, Renlin Li wrote:
> +(define_insn_and_split "*combine_bfi3"
> + [(set (match_operand:GPI 0 "register_operand" "=r")
> +(ior:GPI (and:GPI (match_operand:GPI 1 "register_operand" "0")
> + (match_operand 2 "const_int_operand" "n"))
> +
On 02/20/2014 01:22 PM, Richard Henderson wrote:
> On 02/20/2014 12:09 PM, Jakub Jelinek wrote:
>> On Thu, Feb 20, 2014 at 11:49:30AM -0600, Richard Henderson wrote:
>>> Tested on x86_64 and i686, and manually inspecting the generated code.
>>> Any ideas how to regressi
On 02/20/2014 02:59 PM, Jakub Jelinek wrote:
> ... so all we care about is that
> target/op0/op1 have the right modes and that target is a different register
> from op0 and op0 either the same as op1 or yet another register.
That's my point: yet another register. Thus the creation of a brand new
On 02/20/2014 12:39 PM, Jakub Jelinek wrote:
> + if (!d->testing_p)
> +{
> + dremap.target = gen_reg_rtx (dremap.vmode);
> + dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
> +}
...
> + if (d->testing_p)
> + d_copy.target = gen_lowpart (V4DFmode, d->target);
On 02/20/2014 12:09 PM, Jakub Jelinek wrote:
> On Thu, Feb 20, 2014 at 11:49:30AM -0600, Richard Henderson wrote:
>> Tested on x86_64 and i686, and manually inspecting the generated code.
>> Any ideas how to regression test this?
>
> No idea about how to test this.
>
As described in the PR, we were performing an unconditional store back to the
EXPECT parameter. This is fine, so long as EXPECT is not in thread shared
memory, e.g. a local variable. But the example in the PR uses shared memory
where the extra store introduces a race condition.
I've left a note
On 02/16/2014 03:59 PM, Nathaniel Smith wrote:
> Yes, but the problem is that depending on what the user intends to do
> after forking, our pthread_atfork handler might help or it might hurt,
> and we don't know which. Consider these two cases:
> - fork+exec
> - fork+continue to use OMP in chil
On 02/18/2014 11:37 AM, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux, and Jan Kratochvil
> has tested it with GDB testsuite. Ok for trunk?
>
> 2014-02-18 Jakub Jelinek
>
> PR sanitizer/60142
> * final.c (SEEN_BB): Remove.
> (SEEN_NOTE, SEEN_EM
On 02/10/2014 03:06 PM, Jeff Law wrote:
> + PR rtl-optimization/60131
> + * ree.c (get_extended_src_reg): New function.
> + (combine_reaching_defs): Use it rather than assuming location
> + of REG.
> + (find_and_remove_re): Verify first operand of extension is
> + a REG befo
On 02/14/2014 12:21 AM, Jakub Jelinek wrote:
>> Any reason not to just run gomp_free_thread_pool from
>> gomp_after_fork_callback
>> directly? I see no restrictions on what kind of code is allowed to execute
>> during that callback.
>
> Well, fork is async signal safe function, so calling malloc
On 02/14/2014 07:19 AM, Kai Tietz wrote:
> 2014-02-14 Kai Tietz
>
> PR target/60193
> * config/i386/i386.c (ix86_expand_prologue): Use
> rax register as displacement for restoring %r10, %rax.
> Additional fix wrong offset for restoring both-registers.
>
> ChangeLog testsuite
>
On 02/14/2014 06:41 AM, Kai Tietz wrote:
> + else
> +{
> + t = plus_constant (Pmode, eax, UNITS_PER_WORD);
> + emit_move_insn (eax, t);
> + t = gen_rtx_PLUS (Pmode, stack_pointer_rtx, eax);
> +}
Uros is right that you don't need the move here: 8(rsp,
On 02/13/2014 02:46 PM, Jakub Jelinek wrote:
> 2014-02-13 Jakub Jelinek
>
> * tree-vect-loop.c (vect_is_slp_reduction): Don't set
> use_stmt twice.
> (get_initial_def_for_induction, vectorizable_induction): Ignore
> debug stmts when looking for exit_phi.
> (vectori
> +/* This is to enable best-effort cleanup after fork. */
> +static int gomp_we_are_forked = 0;
bool, no explicit initialization, possible removal, see below.
> +static void
> +gomp_free_thread_pool (int threads_running)
bool for threads_running. It looks like a count otherwise.
> +gomp_afte
On 02/03/2014 03:50 AM, Kyrill Tkachov wrote:
> +# For ARM, the -march option by itself conflicts with any -mcpu option that
> +# we might end up passing to the build, causing an error.
> +# Therefore we override the -mcpu option as well.
> +# This shouldn't affect tuning much because the affected
On 02/13/2014 03:17 AM, Alex Velenko wrote:
> +/* Sets "rmode" field of "FPCR" control register to
> + "FPROUNDING_ZERO". */
Comment is wrong, or at least misleading.
> +void __inline __attribute__ ((__always_inline__))
> +set_rounding_mode (uint32_t mode)
> +{
> + uint32_t r;
> +
> + /* Rea
[Re-send, since I never saw the original arrive on the list.]
After the first version passed Kai's testing, we chatted on IRC about
various other bits that might be relevant to the winx64 abi issues.
The conditional call to ix86_eax_live_at_start_p seemed to be harmless
either way, but confusing
On 02/11/2014 09:36 AM, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, this patch adds VCE if types aren't compatible,
> in order not to create invalid debug stmts.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
>
On 02/07/2014 03:12 PM, Richard Biener wrote:
> On February 7, 2014 8:35:16 PM GMT+01:00, Richard Henderson
> wrote:
>> In the testcases with the PR, we have a bit of type punning going on,
>>
>> *(int *) &s2.f = 0;
>> s2 = s1;
>>
>> which SRA tr
In the testcases with the PR, we have a bit of type punning going on,
*(int *) &s2.f = 0;
s2 = s1;
which SRA trasforms to
# DEBUG s2 => 0
MEM[(int *)&s2] = 0;
# DEBUG s2 => s1$f_7
# DEBUG s2$g => s1$g_6
s2 ={v} {CLOBBER};
Note that it has chosen not to expand s1.f like s1.g, but t
On 02/06/2014 08:25 AM, Jakub Jelinek wrote:
> On Thu, Feb 06, 2014 at 08:23:00AM -0800, Richard Henderson wrote:
>> On 02/06/2014 08:02 AM, Jakub Jelinek wrote:
>>> On Thu, Feb 06, 2014 at 06:53:55AM -0800, Richard Henderson wrote:
>>>> On 02/04/2014 04:40 AM, Jaku
On 02/06/2014 08:02 AM, Jakub Jelinek wrote:
> On Thu, Feb 06, 2014 at 06:53:55AM -0800, Richard Henderson wrote:
>> On 02/04/2014 04:40 AM, Jakub Jelinek wrote:
>>> - tem = expand_shift (LSHIFT_EXPR, mode, lopart, hprec, NULL_RTX, 1);
>>> + tem = gen_
On 02/06/2014 06:48 AM, Richard Sandiford wrote:
> Richard Henderson writes:
>> On 02/06/2014 01:55 AM, Richard Sandiford wrote:
>>> OK, I agree that's not 4.9 material. What about the other change
>>> of replacing:
>>>
>>>REF_CFA_D
On 01/30/2014 12:38 PM, Jakub Jelinek wrote:
> 2014-01-30 Jakub Jelinek
>
> PR target/59575
> * config/arm/arm.c (emit_multi_reg_push): Add dwarf_regs_mask argument,
> don't record in REG_FRAME_RELATED_EXPR registers not set in that
> bitmask.
> (arm_expand_prologu
On 02/04/2014 04:40 AM, Jakub Jelinek wrote:
> - tem = expand_shift (LSHIFT_EXPR, mode, lopart, hprec, NULL_RTX, 1);
> + tem = gen_rtx_SUBREG (mode, lopart, 0);
> + tem = expand_shift (LSHIFT_EXPR, mode, tem, hprec, NULL_RTX, 1);
I would be happier with gen_lowpart rather than th
> 2014-01-30 Jakub Jelinek
>
> PR debug/59992
> * var-tracking.c (adjust_mems): Before adding a SET
> to amd->side_effects, adjust it's SET_SRC using
> simplify_replace_fn_rtx.
>
> * gcc.dg/pr59992.c: New test.
Ok.
r~
On 02/06/2014 01:55 AM, Richard Sandiford wrote:
> OK, I agree that's not 4.9 material. What about the other change
> of replacing:
>
>REF_CFA_DEF_CFA (plus (stack_pointer_rtx) (const_int 160/96))
>
> with:
>
>REF_CFA_ADJUST_CFA (set (stack_pointer_rtx)
>(plu
On 02/05/2014 02:30 PM, Ulrich Weigand wrote:
> Jakub Jelinek wrote:
>> On Wed, Feb 05, 2014 at 10:26:16PM +0100, Ulrich Weigand wrote:
>>> Actually, now I think the problem originally described there is still
>>> valid: on s390 the CFA is *not* equal to the value at function entry,
>>> but biased
gt;> then we'll just keep the save slot from the previous (inner) frame instead.
>
> CCing Richard Henderson into the discussion.
If the sp is saved for a given frame, we'll use that instead of the CFA when
unwinding to a previous frame. That should be unaffected by wheth
This time with the patch...
On 02/05/2014 07:40 AM, Richard Henderson wrote:
> On 02/04/2014 09:35 AM, Jan Hubicka wrote:
>>> On 02/04/2014 08:48 AM, Jan Hubicka wrote:
>>>> How things are supposed to work in this case? So perhaps we need scheduler
>>>> to
On 02/04/2014 09:35 AM, Jan Hubicka wrote:
>> On 02/04/2014 08:48 AM, Jan Hubicka wrote:
>>> How things are supposed to work in this case? So perhaps we need scheduler
>>> to
>>> understand and move around the ARGS_SIZE note?
>>
>> I believe we do need to have the scheduler move the notes around.
On 02/04/2014 09:35 AM, Jan Hubicka wrote:
> I am not terribly familiar with the code, will you look into it or shall I
> give it a try?
I'm looking at it. Was there a PR for the Go bootstrap failure?
r~
On 02/04/2014 08:48 AM, Jan Hubicka wrote:
> How things are supposed to work in this case? So perhaps we need scheduler to
> understand and move around the ARGS_SIZE note?
I believe we do need to have the scheduler move the notes around.
r~
On 01/01/2014 06:23 AM, Jan Hubicka wrote:
> last_sp_adjust = 0;
> + /* We no longer adjust stack size. Whoever adjusted it earlier
> + hopefully got the note right. */
> + note = find_reg_note (insn, REG_ARGS_SIZE, NULL_RTX);
> + if (note)
>
The problem with this pr is that the -uninit pass could get itself
into a loop while processing nodes. Within this loop, it would
allocate memory, therefore the visible symptom was allocation
failure instead of a non-terminating loop.
Amusingly, the case that prods the -uninit pass into this beha
It seems that lower_try_finally_switch was not properly updated for the
addition of EH_ELSE. We tried to lower the finally construct before we
actually handled the EH_ELSE construct specially.
I examined the other lower_try_finally_* alternatives and they all seem to do
the right thing.
Testing
On 01/16/2014 10:21 AM, Jakub Jelinek wrote:
> So like this? Tested on x86_64 with
> make -k check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
> i386.exp=pr9771-1.c'
>
> 2014-01-16 Jakub Jelinek
>
> PR debug/54694
> * gcc.target/i386/pr9771-1.c (main): Rename to...
>
On 01/16/2014 09:35 AM, Jakub Jelinek wrote:
> Wonder if the test should be turned into dg-do compile,
> or perhaps a hack like:
> int xmain() __asm__ ("main");
> int xmain()
> instead of
> int main()
> to avoid the dynamic stack realigning in main (limit the test to *linux*
> then?), supply main w
On 01/15/2014 01:58 PM, Jakub Jelinek wrote:
> On Wed, Jan 15, 2014 at 01:43:18PM -0800, Richard Henderson wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/i386/pr54694.c
>> @@ -0,0 +1,11 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O&quo
701 - 800 of 2706 matches
Mail list logo
