[Bug fortran/65792] allocation of scalar elemental function with structure constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Created attachment 35352
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35352action=edit
Cumulated patch for PR61831 and 65792
Can you post a testcase for the remaining bug there?
I have lost sight of what is missing.
I have attached the patch I have applied on top of a clean tree at r12 and
regtested. As said before the patch fixes also pr49324.
Note that I have tested with
! { dg-additional-options -fsanitize=address }
IIRC this is not available on all targets.
[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #16 from vehre at gcc dot gnu.org --- A patch is available at: https://gcc.gnu.org/ml/fortran/2015-04/msg00061.html awaiting review.
Second GCC 5.1 Release Candidate available from gcc.gnu.org
The second release candidate for GCC 5.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/5.0.1-RC-20150418 and shortly its mirrors. It has been generated from SVN revision 11. Because the release candidate uses 5.0.1 as its version (5.1.0 is reserved for the GA 5.1 release only, see https://gcc.gnu.org/develop.html#num_scheme ), I've used the 5.0.1 version in the name of the directory and tarballs this time, where the first release candidate used 5.1.0-RC-20150412. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 5.1 on Wednesday, 22nd.
Re: [AArch64][PR65139] use clobber with match_scratch for aarch64_lshr_sisd_or_int_mode3
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 (CODE == LSHIFTRT)
+ {
+emit_insn (gen_aarch64_lshr_sisd_or_int_mode3 (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_mode3
- [(set (match_operand:GPI 0 register_operand =w,w,r)
+(define_insn aarch64_lshr_sisd_or_int_mode3
+ [(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_mode
Uscmode,w,rUscmode)))]
+ (match_operand:QI 2 aarch64_reg_or_shift_imm_mode
Uscmode,w,rUscmode)))
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 kyrylo.tkac...@arm.com * 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 vmaka...@redhat.com 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 yvan.r...@st.com
* gcc.target/arm/pr65729.c: Restrict to hard float ABI compliant targets.
OK.
[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_convert
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 kug...@linaro.org Zhenqiang Chen zhenqiang.c...@linaro.org 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 kug...@linaro.org Zhenqiang Chen zhenqiang.c...@linaro.org 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_mode3
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
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.
[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 @@ lia href=#improve_the_installation_procedureImprove the installation procedure/a/li lia href=#simpler_portingSimpler porting/a/li lia href=#generalize_the_machine_modelGeneralize the machine model/a/li -lia href=#the_old_problems_fileThe old PROBLEMS file/a/li /ul pRemember to a href=../contributewhy.htmlkeep 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./p -h2a name=the_old_problems_fileThe old PROBLEMS file/a/h2 - -pThe following used to be in a file codePROBLEMS/code 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./p - -ol - li value=110Possible 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?/li - - li value=117Any 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./li - - li value=118In 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./li -/ol - /body /html
Re: [AArch64][PR65139] use clobber with match_scratch for aarch64_lshr_sisd_or_int_mode3
On Apr 18, 2015, at 8:21 PM, Richard Earnshaw richard.earns...@foss.arm.com 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
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #9 from Frédéric Buclin LpSolit at netscape dot net --- Created attachment 35354 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35354action=edit GCC extension for 5.0, v2 And the corresponding new extension.
Second GCC 5.1 Release Candidate successful avr target build
On a x86_64 linux box I successfully built a gcc RC-20150418 toolchain including binutils-2.25 and avr-libc r2473(svn). I noticed some warnings in the logs: ../../../source/gcc-5.0.1-RC-20150418/gcc/vec.h:1048: warning: invalid access to non-static data member âvecipa_polymorphic_call_context, va_heap, vl_embed::m_vecdataâ of NULL object ../../../source/gcc-5.0.1-RC-20150418/gcc/vec.h:1048: warning: (perhaps the âoffsetofâ macro was used incorrectly) but the build completed successfully One small problem I found is that earlier snapshots (RC-20150405 I think) built OK without texinfo, but this RC build fails without it. I just installed texinfo instead of trying to fix the configure script. I compiled a small C program with -mmcu=attiny84,-Os and got a good binary. I also tried -Os -ftlo, and got a good binary. Unfortunately, despite the announced optimization improvements for lto and ipa, I'm seeing slightly larger binaries than 4.9.2. Hopefully the next 5.x release will surpass 4.9.2. Here's the build scripts I used if anyone wants to repeat it: https://github.com/nerdralph/nerdralph/tree/master/avr/make-avr-gcc -Ralph
[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 mik...@gcc.gnu.org
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 mik...@gcc.gnu.org
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 mik...@gcc.gnu.org
PR fortran/65792
* trans-expr.c (gfc_trans_subcomponent_assign):
Always (shallow) copy the subcomponent.
2015-04-18 Mikael Morin mik...@gcc.gnu.org
PR fortran/65792
* gfortran.dg/derived_constructor_comps_5.f90: New.
Index: trans-expr.c
[Bug c++/65799] Allows constexpr coversion from cv void * to other type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- Very similar to bug 49171.
[Bug c++/65801] New: Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
Bug ID: 65801
Summary: Allow -Wno-narrowing to silence stricter C++11
narrowing rules
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
This code:
---8---
static struct zai { unsigned int x; } x = {-1};
---8---
gives this error in C++11 mode:
$ g++-5 -std=gnu++11 -c y.cpp
y.cpp:1:46: error: narrowing conversion of ‘-1’ from ‘int’ to ‘unsigned int’
inside { }
Clang 3.5 offers using -Wno-narrowing to ignore this and continue with the
previous semantics of silently converting it, which is helpful if one's C++11
project has to include e.g. zend_API.h (which uses the -1 conversion).
Such a feature is missing from gcc.
$ gcc-5 -v
gcc version 5.0.1 20150416 (prerelease) [gcc-5-branch revision 222148] (SUSE
Linux)
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Attachment #34735|0 |1 is obsolete|| --- Comment #8 from Frédéric Buclin LpSolit at netscape dot net --- Created attachment 35353 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35353action=edit GCC patch for 5.0, v2 One of our customisations has been ported upstream (the hook to check new user accounts). One less thing to maintain ourselves.
[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802 Dmitry G. Dyachenko dimhen at gmail dot com changed: What|Removed |Added CC||tom at codesourcery dot com --- Comment #1 from Dmitry G. Dyachenko dimhen at gmail dot com --- r222168 PASS r222174 FAIL
Re: [AArch64][PR65139] use clobber with match_scratch for aarch64_lshr_sisd_or_int_mode3
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 cassert
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 ());
}
[Bug c++/65799] Allows constexpr coversion from cv void * to other type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-18 Ever confirmed|0 |1 Known to fail||4.9.2, 5.0, 6.0
[Bug tree-optimization/65802] New: [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65802
Bug ID: 65802
Summary: [6 Regression] ICE in redirect_eh_edge_1, at
tree-eh.c:2335
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
r222031 PASS
r222198 FAIL
$ cat x.ii
typedef int tf();
struct S {
tf m_fn1;
} a;
void fn1()
{
try {
__builtin_va_list c;
{
int *d = __builtin_va_arg(c, int *);
int **e = d;
__asm__( : =d(e));
a.m_fn1();
}
a.m_fn1();
}
catch (...) {
}
}
$ g++ -fpreprocessed -Wall -c x.ii
x.ii: In function 'void fn1()':
x.ii:6:6: internal compiler error: in redirect_eh_edge_1, at tree-eh.c:2335
void fn1()
^
0xe7050b redirect_eh_edge_1
/home/dimhen/src/gcc_current/gcc/tree-eh.c:2335
0xe70c4c cleanup_empty_eh_merge_phis
/home/dimhen/src/gcc_current/gcc/tree-eh.c:4259
0xe714e9 cleanup_empty_eh
/home/dimhen/src/gcc_current/gcc/tree-eh.c:4508
0xe714e9 cleanup_all_empty_eh
/home/dimhen/src/gcc_current/gcc/tree-eh.c:4551
0xe714e9 execute_cleanup_eh_1
/home/dimhen/src/gcc_current/gcc/tree-eh.c:4581
0xe714e9 execute
/home/dimhen/src/gcc_current/gcc/tree-eh.c:4639
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-static
--enable-checking=yes,df,fold,rtl --enable-languages=c,c++,lto --enable-plugin
--disable-libstdcxx-dual-abi --disable-multilib
Thread model: posix
gcc version 6.0.0 20150417 (experimental) [trunk revision 222198] (GCC)
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-04-18
CC||trippels at gcc dot gnu.org
Summary|Allow -Wno-narrowing to |[5/6 Regression] Allow
|silence stricter C++11 |-Wno-narrowing to silence
|narrowing rules |stricter C++11 narrowing
||rules
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Yes. This also breaks building Chromium.
markus@x4 ~ % echo int main () {int i = { 0x };} | g++ -std=c++11
-Wno-narrowing -x c++ -
stdin: In function ‘int main()’:
stdin:1:35: error: narrowing conversion of ‘4294967295u’ from ‘unsigned int’
to ‘int’ inside { }
While the standard is clear that this is an error,
accepting -Wno-narrowing as in 4.8, 4.9 and clang looks acceptable to me.
[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #5 from Artem S. Tashkinov t.artem at mailcity dot com --- Created attachment 35355 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35355action=edit Sources and Makefile (run make to reproduce) GCC 5.0.1 RC2 is also affected: g++ -O3 -march=native -Wno-attributes -fno-tree-vectorize -fprofile-use -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DRAR_SMP -DUNRAR -c hash.cpp blake2s.cpp: In function ‘void blake2s_update(blake2s_state*, const byte*, size_t)’: blake2s.cpp:138:40: error: corrupted value profile: value profile counter (10976192 out of 10966245) inconsistent with basic-block count (10996457) memcpy( S-buf + left, in, fill ); // Fill buffer ^ blake2s.cpp:162:49: error: corrupted value profile: value profile counter (10915050 out of 10973342) inconsistent with basic-block count (10932972) memcpy( S-buf + left, in, (size_t)inlen ); ^ make: *** [blake2s.o] Error 1 make: *** Waiting for unfinished jobs
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, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders tbsaunde+...@tbsaunde.org
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 asan_mem_ref
{
- 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 attribute_spec
{
- 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 bitmap_descriptor_d
{
- typedef bitmap_descriptor_d value_type;
- typedef loc compare_type;
- static inline hashval_t hash (const value_type *);
- static inline bool equal (const value_type *, const compare_type *);
+ typedef bitmap_descriptor_d *value_type;
+ typedef loc *compare_type;
+ static inline
Re: is it time to mass change from .c to .cc in gcc/ ?
Started with the latter. By the way, what is the policy concerning getting write access to the wiki? You are expected to ask one of the existing editors who's willing to vouch for you to add you to the EditorGroup: http://gcc.gnu.org/wiki/EditorGroup Martin
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. /p + h2Preprocessor issues/h2 pThe preprocessor started to emit line markers to properly distinguish @@ -59,6 +60,7 @@ As can be seen, the codeexitfailure/code and code1/code tokens are not on the same line anymore. + h2C language issues/h2 h3Default standard is now GNU11/h3 @@ -290,9 +292,9 @@ pAs the default mode changed to C11, the code__STDC_VERSION__/code standard macro, introduced in C95, is now defined by default, and has -the value code201112L/code. +the value code201112L/code./p -Typically, this macro is used as in the following:/p +pTypically, this macro is used as in the following:/p precode #if !defined __STDC_VERSION__ || __STDC_VERSION__ lt; 199901L @@ -307,12 +309,12 @@ h4Different meaning of the code%a *scanf/code conversion specification/h4 pIn C89, the GNU C library supports dynamic allocation via the code%as/code, -code%aS/code, and code%a[...]/code conversion specification; see +code%aS/code, and code%a[...]/code conversion specifications; see a href=https://www.gnu.org/software/libc/manual/html_node/Dynamic-String-Input.html#Dynamic-String-Input; this/a for more info. -But in C99, the codea/code conversion specifier is a synonym for codef/code -(float), so the compiler expects an argument of type codefloat */code. Different -meaning of code%a/code is a change in semantics, and in combination with the +In C99, the codea/code conversion specifier is a synonym for codef/code +(float), so the compiler expects an argument of type codefloat */code. +This is a change in semantics, and in combination with the code-Wformat/code warning option the compiler may emit additional warnings:/p precode @@ -333,14 +335,14 @@ /pre pTo use the dynamic allocation conversion specifier in C99 and C11, specify -codem/code as a length modifier, specified by POSIX.1-2008. That is, use +codem/code as a length modifier as per POSIX.1-2008. That is, use code%ms/code or code%m[...]/code./p h3New warnings/h3 -pSeveral 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 code-Wpedantic/code option. For instance:/p +pSeveral new warnings have been added to the C front end. Among others +code-Wpedantic/code now warns about non-standard predefined identifiers. +For instance:/p precode void @@ -363,14 +365,16 @@ const char *s = __extension__ __FUNCTION__; /code/pre + h2C++ language issues/h2 h3Converting codestd::nullptr_t/code to codebool/code/h3 -pConverting codestd::nullptr_t/code to codebool/code in the C++11 +pConverting codestd::nullptr_t/code to codebool/code in C++11 mode now requires direct-initialization. This has been changed in -a href=http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1423;DR 1423/a. -As a consequence, the following is invalid:/p +a href=http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1423;DR 1423/a./p + +pAs a consequence, the following is invalid:/p precode bool b = nullptr;
[Bug target/65803] New: blackfin: internal compiler error: segment fault linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65803
Bug ID: 65803
Summary: blackfin: internal compiler error: segment fault linux
kernel
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
The code:
[root@localhost gcc]# cat lbalance.i
struct a {
short count;
};
struct reiserfs_de_head {
unsigned short deh_location;
} __attribute__ ((__packed__));
void leaf_cut_from_buffer(struct a *ih, int from)
{
struct reiserfs_de_head *deh = (struct reiserfs_de_head *)ih;
int i;
for (i = ih-count - 1; i from; i--)
deh[i].deh_location--;
for (i = 0; i from; i++)
deh[i].deh_location--;
}
The error:
[root@localhost gcc]# /upstream/build-gcc-blackfin/gcc/cc1 lbalance.i -Os
-fno-strict-overflow
lbalance.i: In function 'leaf_cut_from_buffer':
lbalance.i:19:1: internal compiler error: Segmentation fault
}
^
0xa54a9f crash_signal
../../gcc-blackfin/gcc/toplev.c:383
0x77af8b INSN_UID
../../gcc-blackfin/gcc/rtl.h:1329
0x77af8b insn_current_reference_address(rtx_insn*)
../../gcc-blackfin/gcc/final.c:686 0xd39604
insn_current_length(rtx_insn*)
/upstream/build-gcc-blackfin/gcc/insn-attrtab.c:84
0x77c12e shorten_branches(rtx_insn*)
../../gcc-blackfin/gcc/final.c:1478
0x77c51f rest_of_handle_shorten_branches
../../gcc-blackfin/gcc/final.c:4580
0x77c51f execute
../../gcc-blackfin/gcc/final.c:4609
Please submit a full bug report,
The version:
[root@localhost gcc]# /upstream/release-blackfin/bin/bfin-gchen-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release-blackfin/bin/bfin-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/upstream/release-blackfin/libexec/gcc/bfin-gchen-elf/5.0.0/lto-wrapper
Target: bfin-gchen-elf
Configured with: ../gcc-blackfin/configure --target=bfin-gchen-elf
--disable-nls --disable-threads --disable-shared --disable-libssp
--disable-libquadmath --disable-libgomp --disable-libatomic
--prefix=/upstream/release-blackfin --without-headers
target_alias=bfin-gchen-elf --enable-languages=c,lto
Thread model: single
gcc version 5.0.0 20150401 (experimental) (GCC)
[Bug c++/61135] It seems to be not able to call virtual method of literal object in lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61135
lc289dafd7ybme05se at softbank dot ne.jp changed:
What|Removed |Added
CC||lc289dafd7ybme05se@softbank
||.ne.jp
--- Comment #6 from lc289dafd7ybme05se at softbank dot ne.jp ---
below also doesn't work
struct A
{
int funcA(){return 0;}
};
templateclass
struct B:virtual public A{
void funcB(){
[a=this-funcA()]{};
}
};
int main()
{
BA b;
b.funcB();
return 0;
}
//g++ 4.9.2
g++ -std=c++14 hd.cpp
hd.cpp: In instantiation of ‘void B template-parameter-1-1 ::funcB() [with
template-parameter-1-1 = A]’:
hd.cpp:15:10: required from here
hd.cpp:9:2: internal compiler error: in cp_genericize_r, at
cp/cp-gimplify.c:1175
}
^
[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 --- Comment #18 from Thomas Koenig tkoenig at gcc dot gnu.org --- Created attachment 35356 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35356action=edit First attempt that appears to work Well, this seems to work so far, no regressions.
[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #19 from Thomas Koenig tkoenig at gcc dot gnu.org --- This is about what I had in mind for a first commit. More to do afterwards: - Get more test cases - Handle TRANSPOSE - Better handling of temporaries - Remove the unnecessary run-time bounds checks - I forgot to make fe_runtime_error inaccessible to the user (trivial) - %ld may be doning the wrong thing in error reporting for bounds check with 32 bit
[Bug c++/61135] It seems to be not able to call virtual method of literal object in lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61135 --- Comment #7 from lc289dafd7ybme05se at softbank dot ne.jp --- 仮想継承の時もエラーになるみたいですね。
NIOS and atomic primitives
Hi with nios2-rtems on gcc 4.9.2, we are getting undefineds for some atomic primitives. Are these implemented or is some magic bit of configurery missing for nios-rtems? __sync_fetch_and_add_4 is missing on a simple C++ IO streams sanity test. Thanks -- Joel Sherrill Ask me about RTEMS: a free RTOS Support and Training Available
Re: NIOS and atomic primitives
On 04/18/2015 07:35 PM, Joel Sherrill wrote: Hi with nios2-rtems on gcc 4.9.2, we are getting undefineds for some atomic primitives. Are these implemented or is some magic bit of configurery missing for nios-rtems? __sync_fetch_and_add_4 is missing on a simple C++ IO streams sanity test. libgcc presently only provides these functions on nios2-*-linux* and does not have any configury for nios2-*-rtems. I think you are on your own here Chung-Lin and I are only set up for GCC testing on nios2-elf and nios2-linux-gnu and cannot really support RTEMS. Is it one of the standard g++ or libstdc++ test cases that is failing? I could check what nios2-elf does with it if I knew what to look for. -Sandra
[Bug target/65804] New: blackfin: Not support global frame pointer with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65804
Bug ID: 65804
Summary: blackfin: Not support global frame pointer with
-fno-omit-frame-pointer
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
The code:
[root@localhost gcc]# cat stacktrace.i
register unsigned long current_frame_pointer asm(FP);
void save_stack_trace(void)
{
unsigned long fp;
fp = current_frame_pointer;
}
For gcc5 from upstream (cause issue):
[root@localhost gcc]# /upstream/release-blackfin/bin/bfin-gchen-elf-gcc
-mcpu=bf533-0.3 -fno-omit-frame-pointer -pg -c stacktrace.i
stacktrace.i: In function 'save_stack_trace':
stacktrace.i:3:6: error: frame pointer required, but reserved
void save_stack_trace(void)
^
stacktrace.i:1:24: note: for 'current_frame_pointer'
register unsigned long current_frame_pointer asm(FP);
^
[root@localhost linux-next]#
/upstream/release-blackfin/bin/bfin-gchen-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release-blackfin/bin/bfin-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/upstream/release-blackfin/libexec/gcc/bfin-gchen-elf/5.0.0/lto-wrapper
Target: bfin-gchen-elf
Configured with: ../gcc-blackfin/configure --target=bfin-gchen-elf
--disable-nls --disable-threads --disable-shared --disable-libquadmath
--disable-libgomp --disable-libatomic --prefix=/upstream/release-blackfin
--without-headers target_alias=bfin-gchen-elf --enable-languages=c
Thread model: single
gcc version 5.0.0 20150401 (experimental) (GCC)
For blackfin gcc4.5.4 from soureforge (no issue):
root@gchen:/upstream/linux-next# /3p/release-blackfin/bin/bfin-gchen-elf-gcc
-mcpu=bf533-0.3 -fno-omit-frame-pointer -pg -c stacktrace.i
root@gchen:/upstream/linux-next# /3p/release-blackfin/bin/bfin-gchen-elf-gcc
-v
Using built-in specs.
COLLECT_GCC=/3p/release-blackfin/bin/bfin-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/3p/release-blackfin/libexec/gcc/bfin-gchen-elf/4.5.4/lto-wrapper
Target: bfin-gchen-elf
Configured with: ../gcc/configure --target=bfin-gchen-elf --disable-nls
--disable-threads --disable-shared --disable-libssp --disable-libquadmath
--disable-libgomp --disable-libatomic --prefix=/upstream/release-blackfin
--without-headers --enable-languages=c : (reconfigured) ../gcc/configure
--target=bfin-gchen-elf --disable-nls --disable-threads --disable-shared
--disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
--prefix=/3p/release-blackfin --without-headers --enable-languages=c
Thread model: single
gcc version 4.5.4 (GCC)
[Bug other/65800] New: gengtype aborts when run with -d (debug dump)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65800 Bug ID: 65800 Summary: gengtype aborts when run with -d (debug dump) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: maltsevm at gmail dot com Running gengtype with the following parameters (from GCC build directory): $ ./gcc/gengtype -r ./gcc/gtype.state -d Triggers assertion failure: typedefs: pair: name = vecivarref_entry,va_gc Type at 0x1e59200: kind = TYPE_USER_STRUCT pointer_to = 0x1e592c0 gc_used = GC_POINTED_TO u.s.tag = vecivarref_entry,va_gc fileloc: file = /home/miyuki/gcc/src/gcc/objc/objc-next-runtime-abi-02.c, line = 2776 u.s.fields = pair: name = va_gc Type at 0x1e59520: kind = TYPE_UNDEFINED pointer_to = (nil) gc_used = GC_UNUSED gengtype: Internal error: abort in dump_type, at gengtype.c:4956 I noticed two situations, where this (i.e. presence of TYPE_UNDEFINED in dumps) is possible: first, a combination of templates and typedefs (see comment for function gengtype.c:set_gc_used_type). Second is rtl expressions with optional fields (struct block_symbol in SYMBOL_REF).
[Bug fortran/65792] allocation of scalar elemental function with structure constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- The patch fixes the PR, but causes FAIL: gfortran.dg/class_19.f03 -O0 execution test ... False alarm! The failures are due to a conflict with another patch. The patch seems to fix also pr49324.
[Bug other/65800] gengtype aborts when run with -d (debug dump)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65800 --- Comment #1 from Mikhail Maltsev maltsevm at gmail dot com --- Created attachment 35350 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35350action=edit Fix Just in case, I also regtested it.
[Bug fortran/65792] allocation of scalar elemental function with structure constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 35351 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35351action=edit draft patch variant, untested again This one is less invasive and can be preferred for backports.
[Bug fortran/65792] allocation of scalar elemental function with structure constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792 --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) The patch seems to fix also pr49324. Can you post a testcase for the remaining bug there? I have lost sight of what is missing.
[Bug fortran/57957] [F03] Double free with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to janus from comment #2) Updated test case: That one seems to be memory-clean with current trunk. FIXED?
[Bug fortran/52921] With realloc-lhs: Conditional jump or move depends on uninitialised value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52921 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #1) I already get the valgrind warning Conditional jump or move depends on uninitialised value(s) for MY_ARR%ARR(I)%CMP = [1, 2] even without any optimization. (I replaced the READ by an assignment and marked i as VOLATILE.) No error here using the following program; FIXED? PROGRAM QUICK_TEST TYPE COMP INTEGER, ALLOCATABLE :: CMP(:) END TYPE COMP TYPE COMP_ARRAY TYPE (COMP), ALLOCATABLE :: ARR(:) END TYPE COMP_ARRAY INTEGER, VOLATILE :: I TYPE (COMP_ARRAY), TARGET :: MY_ARR I=10 ALLOCATE (MY_ARR%ARR(I)) MY_ARR%ARR(I)%CMP = [1, 2] END PROGRAM QUICK_TEST
[Bug fortran/57957] [F03] Double free with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57957 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- That one seems to be memory-clean with current trunk. FIXED? Confirmed for gcc 5 and trunk (6.0). The test in comment 0 succeeds with 4.9.2, but not the one in comment 2 (!?). Both tests fail with 4.8.5.
[Bug fortran/52921] With realloc-lhs: Conditional jump or move depends on uninitialised value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52921 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- No error here using the following program; FIXED? I cannot reproduce the problem with 4.8.4 and more recent versions.
Re: [gcc libcc1] build_qualified_type for self-referencing/incomplete types
On Fri, 17 Apr 2015 17:22:13 +0200, Jan Kratochvil wrote:
How to get 'volatile struct sv' GCC 'tree' type for:
volatile struct sv { volatile struct sv *p; };
I have found out how it can work, even with no change on the GCC side:
Instead of current:
plugin_build_record_type:
record_type = make_node (RECORD_TYPE)
plugin_build_add_field:
add fields to record_type... But there is no
qualified_record_type here!
plugin_finish_record_or_union:
TYPE_SIZE (record_type) etc. ... to finish the type
plugin_build_qualified_type:
qualified_record_type = build_qualified_type (record_type, ...)
one can do instead:
plugin_build_record_type:
record_type = make_node (RECORD_TYPE)
plugin_build_qualified_type:
qualified_record_type = build_qualified_type (record_type, ...)
plugin_build_add_field:
add fields to qualified_record_type
plugin_finish_record_or_union:
TYPE_SIZE (qualified_record_type) etc. ... to finish the type
And one forgets about the unfinished record_type.
For a different cv-quals of the same record type one builds a new cv-qualified
record from scratch.
Jan
