On Thu, May 8, 2014 at 10:40 PM, Alan Modra wrote:
>> Please do not remove all of the comments from the two functions. The
>> comments should provide some documentation about the different
>> purposes of the two functions other than setting DEST to a CONST.
>
> I believe my updated comment covers
Here is a patch for the test. It contains two changes:
1. For emutls, there will be an explicit call generated at expand
pass, and no stack adjustment is needed. So add /* {
dg-require-effective-target tls_native } */ in the test.
2. Replace cfi_def_cfa_offset with insn sequence check.
Is it ok?
On Sat, May 10, 2014 at 3:53 PM, Marc Glisse wrote:
> Hello,
>
> in my recent phiopt patch enhancing value_replacement to optimize
> x!=0?x+y:y, I forgot to check that there is no other PHI (not sure how I
> managed to miss that since I copy-pasted the line just below the test).
>
> If there are o
On May 10, 2014, at 12:58 PM, Richard Sandiford
wrote:
> The rtx u2 field currently uses a desc/tag pair for GTY. This seems
> unnecessary though,
> OK to install?
Ick. I don’t favor skip. The change feels like a premature optimization that
doesn’t net any code gen benefit. I’ll defer to a
On May 10, 2014, at 12:29 PM, Richard Sandiford
wrote:
> Following on from the patch for PR61136, this patch avoids some other
> uses of const_binop in which we know both operands are INTEGER_CSTs
> and where a wi:: routine would do. As before, the idea is to avoid
> creating an INTEGER_CST only
On May 10, 2014, at 12:11 PM, Richard Sandiford
wrote:
> The new conversion can't be right because it loses overflow information.
> The question then is whether this function should be prepared to handle
> mismatched arguments (as the pre-wide-int version effectively did, since
> it did everythin
Hello,
in my recent phiopt patch enhancing value_replacement to optimize
x!=0?x+y:y, I forgot to check that there is no other PHI (not sure how I
managed to miss that since I copy-pasted the line just below the test).
If there are other phi nodes (with different arguments for those 2
branche
On Fri, May 09, 2014 at 08:11:40PM -0700, Teresa Johnson wrote:
> Thanks for catching that, I will fix it.
BTW I first misunderstood the goal of you patch.
(probably because there is no documentation ... something that should
also be fixed)
I originally thought it was a way to let user code use
Hello world,
this contains a straightforward fix for the regression by
not trying to do combine array constructors inside
association lists.
Regression-tested. OK for all affected open branches?
Thomas
2014-05-10 Thomas Koenig
PR fortran/60834
* frontend-passes.c (i
Richard Sandiford writes:
> Until the wide-int merge there was a 32-bit hole on 64-bit hosts between
> the end of the rtx flags and the start of the first field. It was decided
> that CONST_WIDE_INT should use this hole to store the number of HWIs.
>
> This patch series moves the "i" and int-type
Very much like the code to move ORIGINAL_REGNO, but with a few more
knock-on changes. I handled the printing by dumping the flags
immediately before the SYMBOL_REF_DATA.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
* rtl.def (SYMBOL_REF): Remove middle "0" field.
Hi,
I've noticed that the pr51244-14.c test case started to fail under some
circumstances. It seems that the original test criteria was too strict
which made it sensitive to some code motion effects.
Committed as r210301.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
PR target/51244
*
This is the other case (apart from INSN_UID) in which the field being
moved is an "i". I kept the gen_rtx_VAR_LOCATION interface the same
by writing it in C code. As with INSN_UID, removing an "i" is safe
because genrecog and the equality routines don't care about VAR_LOCATIONs.
(Equality would o
SCRATCH has a single "0" field because reload used to turn it directly
into a REG. It no longer does (or could do) that since REG has three
fields rather than one. This patch therefore updates the comment and
removes the field.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
This is a bit more complicated than REG because INSN_UID is an "i" field
and so is a parameter to the respective gen_rtx_FOOs. However, in all
but one case these uids were dummy values; the one exception can simply
set the INSN_UID after the call instead. These rtxes also don't matter
to genrecog
...and reduce the size of REGs by one field. This is still OK for REG->MEM
conversion since MEMs only have 2 fields.
In some ways it would have been nicer to move REGNO to the header,
since we wouldn't then need to fetch the second word of the rtx when
checking whether something is a REG and then
The print-rtl.c code for '0' fields has a complicated sequence of
ifndef GENERATOR_FILEs. None of the '0' data makes sense for generators
though, so it seems simpler to wrap the whole case instead.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
* print-rtl.c (print_rt
The rtx u2 field currently uses a desc/tag pair for GTY. This seems
unnecessary though, since the field is specifically supposed to be
32 bits wide on 64-bit hosts and so cannot hold a pointer.
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
* rtl.h (rtx_def): Mark u2
Until the wide-int merge there was a 32-bit hole on 64-bit hosts between
the end of the rtx flags and the start of the first field. It was decided
that CONST_WIDE_INT should use this hole to store the number of HWIs.
This patch series moves the "i" and int-typed "0" fields of some
other rtxes to
On Tue, 6 May 2014, Mike Stump wrote:
> All done… It is in.
Since (at least) 16:40 UTC that day my i386-unknown-freebsd10.0 builds
fail as follows:
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Following on from the patch for PR61136, this patch avoids some other
uses of const_binop in which we know both operands are INTEGER_CSTs
and where a wi:: routine would do. As before, the idea is to avoid
creating an INTEGER_CST only to test whether it's zero.
Tested on x86_64-linux-gnu. OK to i
While testing another patch, I hit cases where Ada was building or
folding additions involving integer_one_node without converting
it to the type of the other operand. This looked unintentional,
since all other uses of integer_one_node seemed to have the conversion.
Tested on x86_64-linux-gnu. O
get_addr_base_and_unit_offset_1 and get_ref_base_and_extent have similar
code to handle array indices. The code in tree-dfa.c extends from the
precision of the index, as before wide-int, but the tree-dfa.h version
was updated in a way that could introduce a type inconsistency (flagged
by a patch I
On 09/05/2014 9:53 PM, Ian Lance Taylor wrote:
> On Fri, May 9, 2014 at 7:35 AM, Andrew Burgess wrote:
>
>>if ((AUTO_DEMANGLING || GNU_DEMANGLING))
>> {
>> success = gnu_special (work, &mangled, &decl);
>> + if (!success)
>> +{
>> + dele
The wide-int version of int_const_binop_1 has:
static tree
int_const_binop_1 (enum tree_code code, const_tree arg1, const_tree parg2,
int overflowable)
{
[...]
tree type = TREE_TYPE (arg1);
[...]
wide_int arg2 = wide_int::from (parg2, TYPE_PRECISION (type),
Thanks for looking at this.
Matthew Fortune writes:
>> > Hi all,
>> > This caused some testsuite failures on arm:
>> > FAIL: gcc.target/arm/vfp-ldmdbd.c scan-assembler fldmdbd
>> > FAIL: gcc.target/arm/vfp-ldmdbs.c scan-assembler fldmdbs
>> > FAIL: gcc.target/arm/vfp-ldmiad.c scan-assembler fldmi
On Sat, 10 May 2014, Marek Polacek wrote:
> As the subject says. Along with some whitespace fixes.
>
> Regtested/bootstrapped on x86_64-linux, ok for trunk?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
In general, vectorization tests whose expectations on x86 depend on
whather AVX is available should only consider AVX available if
-mprefer-avx128 is not enabled. Some of the effective-target
functions in target-supports.exp handle this properly, but
check_effective_target_vect_sizes_32B_16B does
On 05/05/2014 07:34 AM, Dominique Dhumieres wrote:
> As posted in the PR, neither the patch in the PR nor the one in this thread
> fixes the test for powerpc-apple-darwin9.
>
I have tested the patch on powerpc linux and it works. That is a Bigendian
machine. Also tested on x86-64 -m32 and -m64. Un
> ...
> Tested again x86_64-linux, ok now?
>
> 2014-05-02 Marek Polacek
>
> PR c/50459
This caused on x86_64-apple-darwin13
FAIL: c-c++-common/pr50459.c -std=gnu++98 (test for excess errors)
FAIL: c-c++-common/pr50459.c -std=gnu++11 (test for excess errors)
FAIL: c-c++-common/pr50459.c -
Hi,
currently it is not possible to build Ada under Cygwin. That is because the
constants
DTR_CONTROL_ENABLE and RTS_CONTROL_ENABLE are missing. Additionally the
function
__gnat_map_SEH is missing under Cygwin64. That is because _WIN32 is not a
built-in define
under Cygwin, instead it is onl
domi...@lps.ens.fr (Dominique Dhumieres) writes:
>> This is the updated patch of pr58066-3.patch. ...
>
> On x86_64-apple-darwin13 I get
>
> FAIL: gcc.target/i386/pr58066.c scan-assembler-times .cfi_def_cfa_offset 16 2
Same on i386-pc-solaris2.* with Sun as (which doesn't support cfi
directives).
Its BRANCH_COST being the default, MMIX is one of them, here
doing away with a few regressions. Committed.
gcc/testsuite:
* lib/target-supports.exp
(check_effective_target_logical_op_short_circuit): Add mmix-*-*
to the list.
Index: gcc/testsuite/lib/target-supports.exp
==
As the subject says. Along with some whitespace fixes.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2014-05-10 Marek Polacek
* c-parser.c (c_parser_declaration_or_fndef): Pass init_loc to
maybe_warn_string_init.
(c_parser_postfix_expression_after_paren_type):
On Sat, 2014-05-10 at 07:42 +0200, Václav Zeman wrote:
> On 9.5.2014 23:14, David Malcolm wrote:
> > This patch is 2.2MB in size, so I've uploaded it to:
> > http://dmalcolm.fedorapeople.org/gcc/large-patches/6fb783b39f914574a1889aa51d06c08cf55678b4-0002-Autogenerated-part-of-introduction-of-GCC_OP
> This is the updated patch of pr58066-3.patch. ...
On x86_64-apple-darwin13 I get
FAIL: gcc.target/i386/pr58066.c scan-assembler-times .cfi_def_cfa_offset 16 2
Dominique
Andrew Bennett writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>> Sent: 09 May 2014 12:07
>> To: Andrew Bennett
>> Cc: gcc-patches@gcc.gnu.org; Matthew Fortune; Saeed Ghazanfar; Rich Fuhler
>> Subject: Re: [PATCH] Add support for MIPS r3 and r5
Tobias Burnus wrote:
! Use a lower bound which is not "1"
! For some reasons, the following does not align the memory!
!ptr(-5:) => array2(lbound(array2,dim=1)+offset2 :)
The reason is that it wrongly pointer-assigns the whole array, ignoring
the specified offset. (It works with an expli
38 matches
Mail list logo
