[Patch, fortran, pr59678, v1] -- [F03] Segfault on equalizing variables of a complex derived type
Hi all,
this patch fixes a deep copy issue, when allocatable components of an entity
were not allocated. Before the patch the deep copy was run without
checking if the component is actually allocated and the program crashed because
a null pointer was dereferenced. Furthermore, was the code to copy a structure
component not checking the correct ref to determine whether a component was
allocated, when allocatable components were nested. Example:
type InnerT
integer, allocatable :: inner_I
end type
type T
type(InnerT), allocatable :: in
end type
The pseudo pseudo code generated for this was something like:
subroutine copy(src,dst)
dst = src
if (allocated (src.in.inner_I)) // crash
allocate (dst.in)
end if
dst.in.inner_I = src.in.inner_I // crash
end subroutine
The patch fixes this by generating:
subroutine copy(src,dst)
dst = src
if (allocated (src.in))
allocate (dst.in)
dst.in= src.in
if (allocated (src.in.inner_I))
allocate (dst.in.inner_I)
dst.in.inner_I = src.in.inner_I
end
end
end subroutine
Of course is this pseudo pseudo code shortened dramatically to show just the
necessary bits.
Bootstraps and regtests ok on x86_64-linux-gnu/F21.
Ok, for trunk?
Thanks to Dominique for identifying the pr addressed by this patch.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr59678_1.clog
Description: Binary data
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 1cb639d..08c8861 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7574,7 +7574,8 @@ gfc_full_array_size (stmtblock_t *block, tree decl, int rank)
static tree
duplicate_allocatable (tree dest, tree src, tree type, int rank,
- bool no_malloc, bool no_memcpy, tree str_sz)
+ bool no_malloc, bool no_memcpy, tree str_sz,
+ tree add_when_allocated)
{
tree tmp;
tree size;
@@ -7654,6 +7655,7 @@ duplicate_allocatable (tree dest, tree src, tree type, int rank,
}
}
+ gfc_add_expr_to_block (&block, add_when_allocated);
tmp = gfc_finish_block (&block);
/* Null the destination if the source is null; otherwise do
@@ -7673,10 +7675,11 @@ duplicate_allocatable (tree dest, tree src, tree type, int rank,
/* Allocate dest to the same size as src, and copy data src -> dest. */
tree
-gfc_duplicate_allocatable (tree dest, tree src, tree type, int rank)
+gfc_duplicate_allocatable (tree dest, tree src, tree type, int rank,
+ tree add_when_allocated)
{
return duplicate_allocatable (dest, src, type, rank, false, false,
-NULL_TREE);
+NULL_TREE, add_when_allocated);
}
@@ -7686,7 +7689,7 @@ tree
gfc_copy_allocatable_data (tree dest, tree src, tree type, int rank)
{
return duplicate_allocatable (dest, src, type, rank, true, false,
-NULL_TREE);
+NULL_TREE, NULL_TREE);
}
/* Allocate dest to the same size as src, but don't copy anything. */
@@ -7694,7 +7697,8 @@ gfc_copy_allocatable_data (tree dest, tree src, tree type, int rank)
tree
gfc_duplicate_allocatable_nocopy (tree dest, tree src, tree type, int rank)
{
- return duplicate_allocatable (dest, src, type, rank, false, true, NULL_TREE);
+ return duplicate_allocatable (dest, src, type, rank, false, true,
+NULL_TREE, NULL_TREE);
}
@@ -7726,27 +7730,32 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
tree ctype;
tree vref, dref;
tree null_cond = NULL_TREE;
+ tree add_when_allocated;
bool called_dealloc_with_status;
gfc_init_block (&fnblock);
decl_type = TREE_TYPE (decl);
- if ((POINTER_TYPE_P (decl_type) && rank != 0)
+ if ((POINTER_TYPE_P (decl_type))
|| (TREE_CODE (decl_type) == REFERENCE_TYPE && rank == 0))
-decl = build_fold_indirect_ref_loc (input_location, decl);
+{
+ decl = build_fold_indirect_ref_loc (input_location, decl);
+ /* Deref dest in sync with decl, but only when it is not NULL. */
+ if (dest)
+ dest = build_fold_indirect_ref_loc (input_location, dest);
+}
- /* Just in case in gets dereferenced. */
+ /* Just in case it gets dereferenced. */
decl_type = TREE_TYPE (decl);
- /* If this an array of derived types with allocatable components
+ /* If this is an array of derived types with allocatable components
build a loop and recursively call this function. */
if (TREE_CODE (decl_type) == ARRAY_TYPE
|| (GFC_DESCRIPTOR_TYPE_P (decl_type) && rank != 0))
{
tmp = gfc_conv_array_data (decl);
- var = build_fold_indirect_ref_loc (input_location,
- tmp);
+ var = build_fold_indirect_ref_loc (input_location, tmp);
/* Get the number of elements - 1 and set the counter. */
if (GFC_DESCRIPTOR_TYPE_P (decl_type))
@@ -7767,7 +7776,7 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
else
{
/* Otherwise use the TYPE_DOMAIN information. */
- tmp = array_type_nelts (decl_type);
+ tmp = array_type_nelts (decl_type);
tmp = fold_
[wwwdocs] Remove "old PROBLEMS file" entries from projects/index.html
In November 2009 I asked about these, and there was some good discussion following ( https://gcc.gnu.org/ml/gcc/2009-11/threads.html#8 ); at one point it just makes sense to remove things that were already considered old back in a decade ago. Committed. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/index.html,v retrieving revision 1.70 diff -u -r1.70 index.html --- index.html 29 Jun 2014 11:31:33 - 1.70 +++ index.html 17 Apr 2015 22:58:42 - @@ -31,7 +31,6 @@ Improve the installation procedure Simpler porting Generalize the machine model -The old PROBLEMS file Remember to keep other developers @@ -104,34 +103,5 @@ used for scalars and another for large objects. The compiler does not now have a way to understand this. -The old PROBLEMS file - -The following used to be in a file PROBLEMS in the GCC - distribution. Probably much of it is no longer relevant as of GCC 3.0 -(the file hadn't changed since GCC 2.0), but some might be. Someone -should go through it, identifying what is and isn't relevant, adding -anything applicable to current GCC (and describing a bug) to our -bug-tracking system and/or updating this patch to remove such analysed -entries from the list. - - - Possible special combination pattern: If the two - operands to a comparison die there and both come from insns that are - identical except for replacing one operand with the other, throw away - those insns. Ok if insns being discarded are known 1 to 1. An andl - #1 after a seq is 1 to 1, but how should compiler know that? - - Any number of slow zero-extensions in one loop, that - have their clr insns moved out of the loop, can share one register if - their original life spans are disjoint. But it may be hard to be sure - of this since the life span data that regscan produces may be hard to - interpret validly or may be incorrect after cse. - - In cse, when a bfext insn refers to a register, if the - field corresponds to a halfword or a byte and the register is - equivalent to a memory location, it would be possible to detect this - and replace it with a simple memory reference. - -
Re: [PATCH][AArch64] PR/64134: Make aarch64_expand_vector_init use 'ins' more often
On 17/04/15 16:48, Alan Lawrence wrote:
> From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64134, testcase
>
> #define vector __attribute__((vector_size(16)))
>
> float a; float b;
> vector float fb(void) { return (vector float){ 0,0,b,a};}
>
> currently produces (correct, but suboptimal):
>
> fb:
> fmovs0, wzr
> adrpx1, b
> adrpx0, a
> sub sp, sp, #16
> ldr w1, [x1, #:lo12:b]
> ldr w0, [x0, #:lo12:a]
> stp s0, s0, [sp]
> stp w1, w0, [sp, 8]
> ldr q0, [sp]
> add sp, sp, 16
> ret
>
> with this patch:
>
> fb:
> adrpx1, b
> moviv0.4s, 0
> adrpx0, a
> ldr s2, [x1, #:lo12:b]
> ldr s1, [x0, #:lo12:a]
> ins v0.s[2], v2.s[0]
> ins v0.s[3], v1.s[0]
> ret
>
> The reason is that aarch64_expand_vector_init presently loads a constant
> and then overwrites with 'ins' only if exactly one element of the vector
> is variable; otherwise, it dumps the entire vector out to the stack
> (later changed to STP) and then loads the whole vector in. This patch
> changes behaviour to load constants and then 'ins' if at most half the
> elements are variable rather than only one.
>
> AFAICT this code path is only used for initialization of GCC vector
> extension vectors, and there is already a special cases for all elements
> being the same (e.g. the _dup_ instrinsics). So it doesn't feel worth
> introducing a 'cost model'-type approach for this one use case (such
> would probably have to be based on an assumption about success of STP
> pattern later anyway). Instead this is a (relatively) simple heuristic
> improvement.
>
> There is a possibility of using ld1 rather than ldr+ins, which *may*
> generate further improvement (probably requiring adrp+add due to limited
> addressing modes of ld1, however); this patch does not tackle that.
>
> Tested on aarch64-none-elf.
>
> gcc/ChangeLog:
>
> PR target/64134
> config/aarch64/aarch64.c (aarch64_expand_vector_init): Load constant
> and overwrite variable parts if <= 1/2 the elements are variable.
>
> gcc/testsuite/ChangeLog:
>
> PR target/64134
> gcc.target/aarch64/vec_init_1.c: New test.
OK.
R.
Re: [AArch64][PR65139] use clobber with match_scratch for aarch64_lshr_sisd_or_int_3
On 16/04/15 00:00, Kugan wrote:
>
>
> On 16/04/15 08:32, Jakub Jelinek wrote:
>> On Thu, Apr 16, 2015 at 08:27:24AM +1000, Kugan wrote:
>>> +if ( == LSHIFTRT)
>>> + {
>>> +emit_insn (gen_aarch64_lshr_sisd_or_int_3 (operands[0],
>>> operands[1], operands[2]));
>>
>> That is way too long line, please wrap it.
>>
>>> +DONE;
>>> + }
>>>}
>>> )
>>>
>>> @@ -3361,11 +3367,12 @@
>>> )
>>>
>>> ;; Logical right shift using SISD or Integer instruction
>>> -(define_insn "*aarch64_lshr_sisd_or_int_3"
>>> - [(set (match_operand:GPI 0 "register_operand" "=w,&w,r")
>>> +(define_insn "aarch64_lshr_sisd_or_int_3"
>>> + [(set (match_operand:GPI 0 "register_operand" "=w,w,r")
>>> (lshiftrt:GPI
>>>(match_operand:GPI 1 "register_operand" "w,w,r")
>>> - (match_operand:QI 2 "aarch64_reg_or_shift_imm_"
>>> "Us,w,rUs")))]
>>> + (match_operand:QI 2 "aarch64_reg_or_shift_imm_"
>>> "Us,w,rUs")))
>>
>> Though, this one too...
>>
>
> Fixed in the attached patch.
>
> Thanks,
> Kugan
>
Not ok.
You need to ensure that your scratch register cannot overlap op1, since
the scratch is written before op1 is read.
R.
Re: [PATCH][ARM][cleanup] Use IN_RANGE more often
On 15/04/15 16:22, Kyrill Tkachov wrote: > Hi all, > > This patch goes through the arm backend and replaces expressions of the > form > a >= lo && a <= hi with IN_RANGE (a, lo, hi) which is that tiny bit smaller > and easier to read in my opinion. I guess there's also a chance it might > make > things infinitesimally faster since IN_RANGE evaluates 'a' only once. > The patch also substitutes expressions like a > hi || a < lo with > !IN_RANGE (a, lo, hi) which, again, conveys the intended meaning more > clearly. > I tried to make sure not to introduce any off-by-one errors and testing > caught some that I had made while writing these. > > Bootstrapped and tested arm-none-linux-gnueabihf. Built and run SPEC2006 > succesfully. > > Ok for trunk once 5.1 is released? > I think this is pretty obvious for those cases where the type of the range is [unsigned] HOST_WIDE_INT, but much less obvious for those cases where the type is just int, or unsigned. Cases that I think need more careful examination include vfp3_const_double_index and aapcs_vfp_is_call_or_return_candidate, but I haven't gone through every instance to check whether there are more cases. I'd be particularly concerned about these if the widening of the result caused a code quality regression on a native 32-bit machine (since HWI is a 64-bit type). R. > Thanks, > Kyrill > > 2015-04-15 Kyrylo Tkachov > > * config/arm/arm.md (*zeroextractsi_compare0_scratch): Use IN_RANGE > instead of two compares. > (*ne_zeroextractsi): Likewise. > (*ite_ne_zeroextractsi): Likewise. > (load_multiple): Likewise. > (store_multiple): Likewise. > * config/arm/arm.h (IS_IWMMXT_REGNUM): Likewise. > (IS_IWMMXT_GR_REGNUM): Likewise. > (IS_VFP_REGNUM): Likewise. > * config/arm/arm.c (arm_return_in_memory): Likewise. > (aapcs_vfp_is_call_or_return_candidate): Likewise. > (thumb_find_work_register): Likewise. > (thumb2_legitimate_address_p): Likewise. > (arm_legitimate_index_p): Likewise. > (thumb2_legitimate_index_p): Likewise. > (thumb1_legitimate_address_p): Likewise. > (thumb_legitimize_address): Likewise. > (vfp3_const_double_index): Likewise. > (neon_immediate_valid_for_logic): Likewise. > (bounds_check): Likewise. > (load_multiple_sequence): Likewise. > (store_multiple_sequence): Likewise. > (offset_ok_for_ldrd_strd): Likewise. > (callee_saved_reg_p): Likewise. > (thumb2_emit_strd_push): Likewise. > (arm_output_load_gr): Likewise. > (arm_vector_mode_supported_p): Likewise. > * config/arm/neon.md (ashldi3_neon_noclobber): Likewise. > (ashrdi3_neon_imm_noclobber): Likewise. > (lshrdi3_neon_imm_noclobber): Likewise. > * config/arm/thumb1.md (*thumb1_addsi3): Likewise. > * config/arm/thumb2.md (define_peephole2's after orsi_not_shiftsi_si): > Likewise.
Re: patch for PR65729
On 15/04/15 13:51, Yvan Roux wrote:
> Hi,
>
> On 14 April 2015 at 17:36, Vladimir Makarov wrote:
>> On 04/14/2015 04:11 AM, Jakub Jelinek wrote:
>>>
>>> On Tue, Apr 14, 2015 at 10:08:24AM +0200, Yvan Roux wrote:
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1656,8 +1656,7 @@ prohibited_class_reg_set_mode_p (enum reg_class
rclass,
{
HARD_REG_SET temp;
- // ??? Is this assert right
- // lra_assert (hard_reg_set_subset_p (set,
reg_class_contents[rclass]));
+ lra_assert (hard_reg_set_subset_p (reg_class_contents[rclass],set));
>>>
>>> Missing space after ,
>>> Otherwise, I'll defer to Vlad for review.
>>>
>>>
>> The patch is ok for me to commit it into the trunk. Thanks, Yvan.
>
> The testcase needs the hard float ABI support, and can fail if tested
> in a way the -march=armv7-a is overridden. This patch patch restrict
> the test to hard vfp compliant targets. Ok for trunk ?
>
> Thanks,
> Yvan
>
> 2015-04-15 Yvan Roux
>
> * gcc.target/arm/pr65729.c: Restrict to hard float ABI compliant targets.
>
OK.
Re: [ARM][PR65768] Keep constants in register when expanding
On 15/04/15 08:48, Kugan wrote: > As mentioned in PR65768, ARM gcc generates suboptimal code for constant > Uses in loop. Part of the reason is that ARM back-end is splitting > constants during expansion of RTL, making it hard for the RTL > optimization passes to optimize it. Zhenqiang posted a patch at > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00325.html to fix this > > As mentioned in PR65768, I tried with few more test-cases and enhanced > it. Regression tested on arm-none-linux-gnu and no new regressions. Is > this OK for trunk? > > Thanks, > Kugan > > > gcc/ChangeLog: > > 2015-04-15 Kugan Vivekanandarajah > Zhenqiang Chen > > PR target/65768 > * config/arm/arm-protos.h (const_ok_for_split): New definition. > * config/arm/arm.c (const_ok_for_split): New function. > * config/arm/arm.md (subsi3, andsi3, iorsi3, xorsi3, movsi): Keep some >large constants in register instead of splitting them. > > gcc/testsuite/ChangeLog: > > 2015-04-15 Kugan Vivekanandarajah > Zhenqiang Chen > > PR target/65768 > * gcc.target/arm/maskdata.c: New test. > While I support your goals, I think your approach needs some refinement. In particular, we DO NOT want another function that starts looking at constant values and tries to decide, on a case by case basis, what to do with that value. We need to keep the logic for that, as much as possible, in one small set of functions so that the compiler cannot end up with conflicting decisions coming from different bits of code. So const_ok_for_split has to go. Instead you should be using const_ok_for op (an existing routine) and a simple macro that encapsulates "optimize >= 2 && can_create_pseudo_p ()" as the gate for when to use a separate scratch register. R.
Re: [AArch64][PR65139] use clobber with match_scratch for aarch64_lshr_sisd_or_int_3
On Sat, Apr 18, 2015 at 03:07:16PM +0100, Richard Earnshaw wrote: > You need to ensure that your scratch register cannot overlap op1, since > the scratch is written before op1 is read. - (clobber (match_scratch:QI 3 "=X,w,X"))] + (clobber (match_scratch:QI 3 "=X,&w,X"))] incremental diff should ensure that, right? Jakub
[Patch, fortran] PR65792 unitialized structure constructor array subcomponent
Hello,
here is a fix for PR65792 where a structure constructor used as actual
argument was not fully initialized.
The test looks like the following...
type :: string_t
character(LEN=1), dimension(:), allocatable :: chars
end type string_t
type :: string_container_t
type(string_t) :: comp
end type string_container_t
type(string_t) :: prt_in
[...]
tmpc = new_prt_spec2 (string_container_t(prt_in))
The problem is in gfc_trans_subcomponent_assign, when initialising the
component comp with prt_in:
if (cm->ts.u.derived->attr.alloc_comp
&& expr->expr_type == EXPR_VARIABLE)
{
tmp = gfc_copy_alloc_comp (cm->ts.u.derived, se.expr,
dest, expr->rank);
gfc_add_expr_to_block (&block, tmp);
}
else
gfc_add_modify (&block, dest,
fold_convert (TREE_TYPE (dest), se.expr));
The if branch deep copies allocatable components, but does nothing for
other components, which is the case here (the array elements are copied,
not the array bounds).
The patch proposed here for backport, moves the existing shallow copy
out of the else branch.
For trunk, I wanted to reuse gfc_trans_scalar_assign which has all the
logic for copying stuff around. And as gfc_trans_scalar_assign is used
as fallback a few lines down, I have tried to use that fallback.
This change of control flow makes the patch a bit more risky, so I
prefer to use the other variant for the branches.
Setting the deep_copy argument of gfc_trans_scalar_assign to true is
necessary so that gfc_copy_alloc_comp is called as before.
Because of the branch the patch removes, I think the fallback code was
unreachable for non-derived types, and for those the deep_copy flag was
irrelevant anyway, so that that change should be rather harmless.
Both patches have been regression tested on trunk on x86_64-linux.
OK for trunk [first patch]?
OK for 4.9 and 5 (after the 5.1 release) [second patch]?
Mikael
PS: Dominiq reported that the variant of this patch posted on the PR was
also fixing PR49324. I couldn't confirm as what seems to be the
remaining testcase there (comment #6) doesn't fail with trunk here.
2015-04-18 Mikael Morin
PR fortran/65792
* trans-expr.c (gfc_trans_subcomponent_assign):
Don't special case non-structure-constructor derived type
expressions. Enable deep copying.
2015-04-18 Mikael Morin
PR fortran/65792
* gfortran.dg/derived_constructor_comps_5.f90: New.
Index: trans-expr.c
===
--- trans-expr.c (révision 221972)
+++ trans-expr.c (copie de travail)
@@ -6908,32 +6908,6 @@ gfc_trans_subcomponent_assign (tree dest, gfc_comp
fold_convert (TREE_TYPE (tmp), se.expr));
gfc_add_block_to_block (&block, &se.post);
}
- else if (expr->ts.type == BT_DERIVED && expr->ts.f90_type != BT_VOID)
-{
- if (expr->expr_type != EXPR_STRUCTURE)
- {
- gfc_init_se (&se, NULL);
- gfc_conv_expr (&se, expr);
- gfc_add_block_to_block (&block, &se.pre);
- if (cm->ts.u.derived->attr.alloc_comp
- && expr->expr_type == EXPR_VARIABLE)
- {
- tmp = gfc_copy_alloc_comp (cm->ts.u.derived, se.expr,
- dest, expr->rank);
- gfc_add_expr_to_block (&block, tmp);
- }
- else
- gfc_add_modify (&block, dest,
- fold_convert (TREE_TYPE (dest), se.expr));
- gfc_add_block_to_block (&block, &se.post);
- }
- else
- {
- /* Nested constructors. */
- tmp = gfc_trans_structure_assign (dest, expr, expr->symtree != NULL);
- gfc_add_expr_to_block (&block, tmp);
- }
-}
else if (gfc_deferred_strlen (cm, &tmp))
{
tree strlen;
@@ -6967,6 +6941,13 @@ gfc_trans_subcomponent_assign (tree dest, gfc_comp
gfc_add_expr_to_block (&block, tmp);
}
}
+ else if (expr->expr_type == EXPR_STRUCTURE
+ && expr->ts.f90_type != BT_VOID)
+{
+ /* Nested constructors. */
+ tmp = gfc_trans_structure_assign (dest, expr, expr->symtree != NULL);
+ gfc_add_expr_to_block (&block, tmp);
+}
else if (!cm->attr.artificial)
{
/* Scalar component (excluding deferred parameters). */
@@ -6977,7 +6958,7 @@ gfc_trans_subcomponent_assign (tree dest, gfc_comp
if (cm->ts.type == BT_CHARACTER)
lse.string_length = cm->ts.u.cl->backend_decl;
lse.expr = dest;
- tmp = gfc_trans_scalar_assign (&lse, &se, cm->ts, true, false, true);
+ tmp = gfc_trans_scalar_assign (&lse, &se, cm->ts, true, true, true);
gfc_add_expr_to_block (&block, tmp);
}
return gfc_finish_block (&block);
2015-04-18 Mikael Morin
PR fortran/65792
* trans-expr.c (gfc_trans_subcomponent_assign):
Always (shallow) copy the subcomponent.
2015-04-18 Mikael Morin
PR fortran/65792
* gfortran.dg/derived_constructor_comps_5.f90: New.
Index: trans-expr.c
===
--- t
Re: [AArch64][PR65139] use clobber with match_scratch for aarch64_lshr_sisd_or_int_3
On 18/04/15 16:13, Jakub Jelinek wrote: > On Sat, Apr 18, 2015 at 03:07:16PM +0100, Richard Earnshaw wrote: >> You need to ensure that your scratch register cannot overlap op1, since >> the scratch is written before op1 is read. > > - (clobber (match_scratch:QI 3 "=X,w,X"))] > + (clobber (match_scratch:QI 3 "=X,&w,X"))] > > incremental diff should ensure that, right? > > Jakub > Sorry, where in the patch is that hunk? I see just: + (clobber (match_scratch:QI 3 "=X,w,X"))] And why would early clobbering the scratch be notably better than the original? R.
Re: [PATCH 1/2] PR c++/61636
On 2015-04-17 22:06, Adam Butcher wrote:
On 2015-04-17 20:58, Jason Merrill wrote:
On 04/09/2015 11:31 PM, Adam Butcher wrote:
+ /* For generic lambdas, resolve default captured 'this' now. */
This isn't quite right. We don't want to capture 'this' any time we
see a member function call, as overload resolution might choose a
static member function that doesn't need 'this'. The special
handling
we want is for the case where the call depends on a generic lambda
parameter, in which case we capture 'this' because the call "names
[this] in a potentially-evaluated expression (3.2) where the
enclosing
full-expression depends on a generic lambda parameter declared
within
the reaching scope of the lambda-expression."
Good point. I'll look into it. So for a nullary member call we will
always capture 'this', but for N-ary, we only capture if we find one
of the lambda's parameters (or a parameter from an enclosing generic
lambda?) in the call's arguments right?
Test like this?
/* { dg-do run { target c++14 } } */
/* { dg-final { scan-assembler-not "..." } } */
struct X
{
int f (int, double) { return 255; }
static int f (int, int) { return 65535; }
auto m1 ()
{
return [=] (auto a) {
return f (7, a);
};
}
auto m2 ()
{
return [=] (auto a) {
return f (9, 10) + a;
};
}
};
#include
int main()
{
X x;
assert (x.m1 () (42.0) == 255);
assert (x.m1 () (42) == 65535);
assert (x.m2 () (42.0) == (65535 + 42));
assert (x.m2 () (42) == (65535 + 42));
assert (sizeof x.m2 () < sizeof x.m1 ());
}
Re: [AArch64][PR65139] use clobber with match_scratch for aarch64_lshr_sisd_or_int_3
> On Apr 18, 2015, at 8:21 PM, Richard Earnshaw > wrote: > > On 18/04/15 16:13, Jakub Jelinek wrote: >> On Sat, Apr 18, 2015 at 03:07:16PM +0100, Richard Earnshaw wrote: >>> You need to ensure that your scratch register cannot overlap op1, since >>> the scratch is written before op1 is read. >> >> - (clobber (match_scratch:QI 3 "=X,w,X"))] >> + (clobber (match_scratch:QI 3 "=X,&w,X"))] >> >> incremental diff should ensure that, right? >> >> Jakub >> > > > Sorry, where in the patch is that hunk? > > I see just: > > + (clobber (match_scratch:QI 3 "=X,w,X"))] Jakub's suggestion is an incremental patch on top of Kugan's. > > And why would early clobbering the scratch be notably better than the > original? > It will still be better. With this patch we want to allow RA freedom to optimally handle both of the following cases: 1. operand[1] dies after the instruction. In this case we want operand[0] and operand[1] to be assigned to the same reg, and operand[3] to be assigned to a different register to provide a temporary. In this case we don't care whether operand[3] is early-clobber or not. This case is not optimally handled with current insn patterns. 2. operand[1] lives on after the instruction. In this case we want operand[0] and operand[3] to be assigned to the same reg, and not clobber operand[1]. By marking operand[3] early-clobber we ensure that operand[1] is in a different register from what operand[0] and operand[3] were assigned to. This case should be handled equally well before and after the patch. My understanding is that Kugan's patch with Jakub's fix on top satisfy both of these cases. -- Maxim Kuvyrkov www.linaro.org
Re: [PATCH] remove need for store_values_directly
On Fri, Apr 17, 2015 at 09:29:07AM +0200, Richard Biener wrote:
> On Fri, Apr 17, 2015 at 6:38 AM, wrote:
> > From: Trevor Saunders
> >
> > Hi,
> >
> > Last stage 1 I introduced a second form of hash_table that stored elements
> > of
> > value_type in addition to the old form that stored elements of type
> > value_type
> > *. That lead to a fair bit of code dupplication in hash_table, but it
> > simplified the transition by allowing it to take place one hash table at a
> > time. Now I'm switching the rest of the hash_table users to use the new
> > setup,
> > and removing supporot for the old one.
> >
> > this was bootstrapped and regtested on x86_64-unknown-linux-gnu, and I ran
> > make
> > all-gcc for the following crosses to check the hash tables they use were
> > correctly converted
> > arm-linux-androideabi
> > i686-apple-darwin
> > i686-solaris2.11
> > i686-w64-mingw32
> > ia64-linux
> > mips64-linux
> > nvptx-elf
> > ppc64-linux
> >
> > Is this ok?
>
> Ok.
committed as r13 thanks!
Trev
>
> Thanks,
> Richard.
>
> > Trev
> >
> > gcc/
> >
> > * hash-table.h: Remove version of hash_table that stored value_type
> > *.
> > * asan.c, attribs.c, bitmap.c, cfg.c, cgraph.h, config/arm/arm.c,
> > config/i386/winnt.c, config/ia64/ia64.c, config/mips/mips.c,
> > config/sol2.c, coverage.c, cselib.c, dse.c, dwarf2cfi.c,
> > dwarf2out.c, except.c, gcse.c, genmatch.c, ggc-common.c,
> > gimple-ssa-strength-reduction.c, gimplify.c, haifa-sched.c,
> > hard-reg-set.h, hash-map.h, hash-set.h, ipa-devirt.c, ipa-icf.h,
> > ipa-profile.c, ira-color.c, ira-costs.c, loop-invariant.c,
> > loop-iv.c, loop-unroll.c, lto-streamer.h, plugin.c,
> > postreload-gcse.c,
> > reginfo.c, statistics.c, store-motion.c, trans-mem.c, tree-cfg.c,
> > tree-eh.c, tree-hasher.h, tree-into-ssa.c, tree-parloops.c,
> > tree-sra.c, tree-ssa-coalesce.c, tree-ssa-dom.c, tree-ssa-live.c,
> > tree-ssa-loop-im.c, tree-ssa-loop-ivopts.c, tree-ssa-phiopt.c,
> > tree-ssa-pre.c, tree-ssa-reassoc.c, tree-ssa-sccvn.c,
> > tree-ssa-structalias.c, tree-ssa-tail-merge.c,
> > tree-ssa-threadupdate.c, tree-vectorizer.c, tree-vectorizer.h,
> > valtrack.h, var-tracking.c, vtable-verify.c, vtable-verify.h:
> > Adjust.
> >
> >
> > libcc1/
> >
> > * plugin.cc: Adjust for hash_table changes.
> >
> > java/
> >
> > * jcf-io.c: Adjust for hash_table changes.
> >
> > lto/
> >
> > * lto.c: Adjust for hash_table changes.
> >
> > objc/
> >
> > * objc-act.c: Adjust for hash_table changes.
> >
> > diff --git a/gcc/asan.c b/gcc/asan.c
> > index 9e4a629..7b70ee2 100644
> > --- a/gcc/asan.c
> > +++ b/gcc/asan.c
> > @@ -407,11 +407,11 @@ asan_mem_ref_get_end (const asan_mem_ref *ref, tree
> > len)
> > struct asan_mem_ref_hasher
> >: typed_noop_remove
> > {
> > - typedef asan_mem_ref value_type;
> > - typedef asan_mem_ref compare_type;
> > + typedef asan_mem_ref *value_type;
> > + typedef asan_mem_ref *compare_type;
> >
> > - static inline hashval_t hash (const value_type *);
> > - static inline bool equal (const value_type *, const compare_type *);
> > + static inline hashval_t hash (const asan_mem_ref *);
> > + static inline bool equal (const asan_mem_ref *, const asan_mem_ref *);
> > };
> >
> > /* Hash a memory reference. */
> > diff --git a/gcc/attribs.c b/gcc/attribs.c
> > index c18bff2..7b7e2a9 100644
> > --- a/gcc/attribs.c
> > +++ b/gcc/attribs.c
> > @@ -67,21 +67,21 @@ substring_hash (const char *str, int l)
> >
> > struct attribute_hasher : typed_noop_remove
> > {
> > - typedef attribute_spec value_type;
> > - typedef substring compare_type;
> > - static inline hashval_t hash (const value_type *);
> > - static inline bool equal (const value_type *, const compare_type *);
> > + typedef attribute_spec *value_type;
> > + typedef substring *compare_type;
> > + static inline hashval_t hash (const attribute_spec *);
> > + static inline bool equal (const attribute_spec *, const substring *);
> > };
> >
> > inline hashval_t
> > -attribute_hasher::hash (const value_type *spec)
> > +attribute_hasher::hash (const attribute_spec *spec)
> > {
> >const int l = strlen (spec->name);
> >return substring_hash (spec->name, l);
> > }
> >
> > inline bool
> > -attribute_hasher::equal (const value_type *spec, const compare_type *str)
> > +attribute_hasher::equal (const attribute_spec *spec, const substring *str)
> > {
> >return (strncmp (spec->name, str->str, str->length) == 0
> > && !spec->name[str->length]);
> > diff --git a/gcc/bitmap.c b/gcc/bitmap.c
> > index d43a39f..71d5b11 100644
> > --- a/gcc/bitmap.c
> > +++ b/gcc/bitmap.c
> > @@ -61,20 +61,20 @@ struct loc
> >
> > struct bitmap_desc_hasher : typed_noop_remove
> > {
> > - typedef bitmap_descriptor_d value_type;
> > - typedef loc compare_type;
> > - static inline hashval_t hash (const value
Re: [wwwdocs] Some stuff for porting to
On Wed, 11 Feb 2015, Marek Polacek wrote: > Oops, I must have been thinking of __STDC_VERSION__ when writing that. > Fixed, thanks. Here is a small set of tweaks on top of this (no material changes). Applied. Gerald Index: porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v retrieving revision 1.7 diff -u -r1.7 porting_to.html --- porting_to.html 10 Mar 2015 17:58:12 - 1.7 +++ porting_to.html 18 Apr 2015 19:43:37 - @@ -24,6 +24,7 @@ manner. Additions and suggestions for improvement are welcome. + Preprocessor issues The preprocessor started to emit line markers to properly distinguish @@ -59,6 +60,7 @@ As can be seen, the exitfailure and 1 tokens are not on the same line anymore. + C language issues Default standard is now GNU11 @@ -290,9 +292,9 @@ As the default mode changed to C11, the __STDC_VERSION__ standard macro, introduced in C95, is now defined by default, and has -the value 201112L. +the value 201112L. -Typically, this macro is used as in the following: +Typically, this macro is used as in the following: #if !defined __STDC_VERSION__ || __STDC_VERSION__ < 199901L @@ -307,12 +309,12 @@ Different meaning of the %a *scanf conversion specification In C89, the GNU C library supports dynamic allocation via the %as, -%aS, and %a[...] conversion specification; see +%aS, and %a[...] conversion specifications; see https://www.gnu.org/software/libc/manual/html_node/Dynamic-String-Input.html#Dynamic-String-Input";> this for more info. -But in C99, the a conversion specifier is a synonym for f -(float), so the compiler expects an argument of type float *. Different -meaning of %a is a change in semantics, and in combination with the +In C99, the a conversion specifier is a synonym for f +(float), so the compiler expects an argument of type float *. +This is a change in semantics, and in combination with the -Wformat warning option the compiler may emit additional warnings: @@ -333,14 +335,14 @@ To use the dynamic allocation conversion specifier in C99 and C11, specify -m as a length modifier, specified by POSIX.1-2008. That is, use +m as a length modifier as per POSIX.1-2008. That is, use %ms or %m[...]. New warnings -Several new warnings have been added to the C front end. One of the new -warnings is that GCC now warns about non-standard predefined identifiers with -the -Wpedantic option. For instance: +Several new warnings have been added to the C front end. Among others +-Wpedantic now warns about non-standard predefined identifiers. +For instance: void @@ -363,14 +365,16 @@ const char *s = __extension__ __FUNCTION__; + C++ language issues Converting std::nullptr_t to bool -Converting std::nullptr_t to bool in the C++11 +Converting std::nullptr_t to bool in C++11 mode now requires direct-initialization. This has been changed in -http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1423";>DR 1423. -As a consequence, the following is invalid: +http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1423";>DR 1423. + +As a consequence, the following is invalid: bool b = nullptr;
