Re: [PATCH], Add PowerPC ISA 3.0 vec_vinsert4b and vec_vextract4b built-in functions
On Dez 13 2016, Michael Meissner wrote:
> @@ -15766,6 +15766,40 @@ altivec_expand_builtin (tree exp, rtx ta
> case VSX_BUILTIN_VEC_EXT_V1TI:
>return altivec_expand_vec_ext_builtin (exp, target);
>
> +case P9V_BUILTIN_VEXTRACT4B:
> +case P9V_BUILTIN_VEC_VEXTRACT4B:
> + arg1 = CALL_EXPR_ARG (exp, 1);
> + STRIP_NOPS (arg1);
> +
> + /* Generate a normal call if it is invalid. */
> + /* If we got invalid arguments bail out before generating bad rtl. */
> + if (arg1 == error_mark_node)
> + return expand_call (exp, target, false);
> +
> + if (TREE_CODE (arg1) != INTEGER_CST || TREE_INT_CST_LOW (arg1) > 11)
> + {
> + error ("second argument to vec_vextract4b must 0..11");
be
> + return expand_call (exp, target, false);
> + }
> + break;
> +
> +case P9V_BUILTIN_VINSERT4B:
> +case P9V_BUILTIN_VINSERT4B_DI:
> +case P9V_BUILTIN_VEC_VINSERT4B:
> + arg2 = CALL_EXPR_ARG (exp, 2);
> + STRIP_NOPS (arg2);
> +
> + /* If we got invalid arguments bail out before generating bad rtl. */
> + if (arg2 == error_mark_node)
> + return expand_call (exp, target, false);
> +
> + if (TREE_CODE (arg2) != INTEGER_CST || TREE_INT_CST_LOW (arg2) > 11)
> + {
> + error ("third argument to vec_vinsert4b must 0..11");
be
> + return expand_call (exp, target, false);
> + }
> + break;
> +
> default:
>break;
>/* Fall through. */
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [PATCH, ARM] PR71607: New approach to arm_disable_literal_pool
On 29/11/16 09:45, Andre Vieira (lists) wrote: > On 17/11/16 10:00, Ramana Radhakrishnan wrote: >> On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists) >> wrote: >>> Hello, >>> >>> This patch tackles the issue reported in PR71607. This patch takes a >>> different approach for disabling the creation of literal pools. Instead >>> of disabling the patterns that would normally transform the rtl into >>> actual literal pools, it disables the creation of this literal pool rtl >>> by making the target hook TARGET_CANNOT_FORCE_CONST_MEM return true if >>> arm_disable_literal_pool is true. I added patterns to split floating >>> point constants for both SF and DFmode. A pattern to handle the >>> addressing of label_refs had to be included as well since all >>> "memory_operand" patterns are disabled when >>> TARGET_CANNOT_FORCE_CONST_MEM returns true. Also the pattern for >>> splitting 32-bit immediates had to be changed, it was not accepting >>> unsigned 32-bit unsigned integers with the MSB set. I believe >>> const_int_operand expects the mode of the operand to be set to VOIDmode >>> and not SImode. I have only changed it in the patterns that were >>> affecting this code, though I suggest looking into changing it in the >>> rest of the ARM backend. >>> >>> I added more test cases. No regressions for arm-none-eabi with >>> Cortex-M0, Cortex-M3 and Cortex-M7. >>> >>> Is this OK for trunk? >> >> Including -mslow-flash-data in your multilib flags ? If no regressions >> with that ok . >> >> >> regards >> Ramana >> >>> > > Hello, > > I found some new ICE's with the -mslow-flash-data testing so I had to > rework this patch. I took the opportunity to rebase it as well. > > The problem was with the way the old version of the patch handled label > references. After some digging I found I wasn't using the right target > hook and so I implemented the 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' for > ARM. This target hook determines whether a literal pool ends up in an > 'object_block' structure. So I reverted the changes made in the old > version of the patch to the ARM implementation of the > 'TARGET_CANNOT_FORCE_CONST_MEM' hook and rely on > 'TARGET_USE_BLOCKS_FOR_CONSTANT_P' instead. This patch adds an ARM > implementation for this hook that returns false if > 'arm_disable_literal_pool' is set to true and true otherwise. > > This version of the patch also reverts back to using the check for > 'SYMBOL_REF' in 'thumb2_legitimate_address_p' that was removed in the > last version, this code is required to place the label references in > rodata sections. > > Another thing this patch does is revert the changes made to the 32-bit > constant split in arm.md. The reason this was needed before was because > 'real_to_target' returns a long array and does not sign-extend values in > it, which would make sense on hosts with 64-bit longs. To fix this the > value is now casted to 'int' first. It would probably be a good idea to > change the 'real_to_target' function to return an array with > 'HOST_WIDE_INT' elements instead and either use all 64-bits or > sign-extend them. Something for the future? > > I added more test cases in this patch and reran regression tests for: > Cortex-M0, Cortex-M4 with and without -mslow-flash-data. Also did a > bootstrap+regressions on arm-none-linux-gnueabihf. > > Is this OK for trunk? > > Cheers, > Andre > > gcc/ChangeLog: > > 2016-11-29 Andre Vieira > > PR target/71607 > * config/arm/arm.md (use_literal_pool): Removes. > (64-bit immediate split): No longer takes cost into consideration > if 'arm_disable_literal_pool' is enabled. > * config/arm/arm.c (arm_use_blocks_for_constant_p): New. > (TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define. > (arm_max_const_double_inline_cost): Remove use of > arm_disable_literal_pool. > * config/arm/vfp.md (no_literal_pool_df_immediate): New. > (no_literal_pool_sf_immediate): New. > > > gcc/testsuite/ChangeLog: > > 2016-11-29 Andre Vieira > Thomas Preud'homme > > PR target/71607 > * gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ... > * gcc.target/arm/thumb2-slow-flash-data-1.c: ... this. > * gcc.target/arm/thumb2-slow-flash-data-2.c: New. > * gcc.target/arm/thumb2-slow-flash-data-3.c: New. > * gcc.target/arm/thumb2-slow-flash-data-4.c: New. > * gcc.target/arm/thumb2-slow-flash-data-5.c: New. > Hello, As I have mentioned in my commit message for the fix on embedded-6 (see https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01304.html) I found an issue with this code when testing its backport on the embedded-6-branch. I misread the definition of the target hook TARGET_USE_BLOCKS_FOR_CONSTANT_P and it seems the way I implemented it before only changed code generation if the -mslow-flash-data option wasn't passed. I.e. I don't need to implement it to solve this issue. The other changes in this patch are sufficient... I reran regressions for arm-none-eabi-gcc with the following targets:
[PATCH, i386]: Allow non-REX memory operand for x86_64 zero-extracts involving high registers
Hello!
Attached patch allows non-REX memory operands for x86_64 zero-extracts
involving high registers. This needs to be implemented using peephole2
pattern, since we can't distinguish non-REX memory operand from normal
memory operands.
2016-12-28 Uros Bizjak
PR target/78904
* config/i386/constraints.md (Bn): New special memory constraint.
* config/i386/predicates.md (norex_memory_operand): New predicate.
* config/i386/i386.md (*extzvqi_mem_rex64): New insn pattern and
corresponding peephole2 pattern.
testsuite/ChangeLog:
2016-12-28 Uros Bizjak
PR target/78904
* gcc.target/i386/pr78904-4.c: New test.
* gcc.target/i386/pr78904-5.c: Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: config/i386/constraints.md
===
--- config/i386/constraints.md (revision 243954)
+++ config/i386/constraints.md (working copy)
@@ -169,6 +169,7 @@
;; g GOT memory operand.
;; m Vector memory operand
;; c Constant memory operand
+;; n Memory operand without REX prefix
;; s Sibcall memory operand, not valid for TARGET_X32
;; w Call memory operand, not valid for TARGET_X32
;; z Constant call address operand.
@@ -191,6 +192,10 @@
(and (match_operand 0 "memory_operand")
(match_test "constant_address_p (XEXP (op, 0))")))
+(define_special_memory_constraint "Bn"
+ "@internal Memory operand without REX prefix."
+ (match_operand 0 "norex_memory_operand"))
+
(define_constraint "Bs"
"@internal Sibcall memory operand."
(ior (and (not (match_test "TARGET_X32"))
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 243954)
+++ config/i386/i386.md (working copy)
@@ -2835,9 +2835,20 @@
[(set_attr "type" "imovx")
(set_attr "mode" "SI")])
+(define_insn "*extzvqi_mem_rex64"
+ [(set (match_operand:QI 0 "norex_memory_operand" "=Bn")
+ (subreg:QI
+ (zero_extract:SI (match_operand 1 "ext_register_operand" "Q")
+ (const_int 8)
+ (const_int 8)) 0))]
+ "TARGET_64BIT && reload_completed"
+ "mov{b}\t{%h1, %0|%0, %h1}"
+ [(set_attr "type" "imov")
+ (set_attr "mode" "QI")])
+
(define_insn "*extzvqi"
[(set (match_operand:QI 0 "nonimmediate_operand" "=QBc,?R,m")
-(subreg:QI
+ (subreg:QI
(zero_extract:SI (match_operand 1 "ext_register_operand" "Q,Q,Q")
(const_int 8)
(const_int 8)) 0))]
@@ -2863,6 +2874,21 @@
(const_string "SI")
(const_string "QI")))])
+(define_peephole2
+ [(set (match_operand:QI 0 "register_operand")
+ (subreg:QI
+ (zero_extract:SI (match_operand 1 "ext_register_operand")
+ (const_int 8)
+ (const_int 8)) 0))
+ (set (match_operand:QI 2 "norex_memory_operand") (match_dup 0))]
+ "TARGET_64BIT
+ && peep2_reg_dead_p (2, operands[0])"
+ [(set (match_dup 2)
+ (subreg:QI
+ (zero_extract:SI (match_dup 1)
+ (const_int 8)
+ (const_int 8)) 0))])
+
(define_expand "insv"
[(set (zero_extract:SWI248 (match_operand:SWI248 0 "register_operand")
(match_operand:SI 1 "const_int_operand")
Index: config/i386/predicates.md
===
--- config/i386/predicates.md (revision 243954)
+++ config/i386/predicates.md (working copy)
@@ -1037,6 +1037,10 @@
(ior (match_operand 0 "register_operand")
(match_operand 0 "const0_operand")))
+(define_predicate "norex_memory_operand"
+ (and (match_operand 0 "memory_operand")
+ (not (match_test "x86_extended_reg_mentioned_p (op)"
+
;; Return true for RTX codes that force SImode address.
(define_predicate "SImode_address_operand"
(match_code "subreg,zero_extend,and"))
Index: testsuite/gcc.target/i386/pr78904-4.c
===
--- testsuite/gcc.target/i386/pr78904-4.c (nonexistent)
+++ testsuite/gcc.target/i386/pr78904-4.c (working copy)
@@ -0,0 +1,21 @@
+/* PR target/78904 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -masm=att" } */
+
+typedef __SIZE_TYPE__ size_t;
+
+struct S1
+{
+ unsigned char pad1;
+ unsigned char val;
+ unsigned short pad2;
+};
+
+extern unsigned char t[256];
+
+void foo (struct S1 a, size_t i)
+{
+ t[i] = a.val;
+}
+
+/* { dg-final { scan-assembler "\[ \t\]movb\[\t \]*%.h," } } */
Index: testsuite/gcc.target/i386/pr78904-5.c
===
--- testsuite/gcc.target/i386/pr78904-5.c (nonexistent)
+++ testsuite/gcc.target/i386/pr78904-5.c (working copy)
@@ -0,0 +1,27 @@
+/* PR target/78904 */
+/* { dg-do assemble { target { ! ia32 } } } */
+/* { dg-options "-O2" } */
+
+
[Ping^3][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
Jiong Wang writes: > Jiong Wang writes: > >> Jiong Wang writes: >> >>> On 16/11/16 14:02, Jakub Jelinek wrote: On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: > On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote: >> The two operations DW_OP_AARCH64_paciasp and >> DW_OP_AARCH64_paciasp_deref were >> designed as shortcut operations when LR is signed with A key and using >> function's CFA as salt. This is the default behaviour of return address >> signing so is expected to be used for most of the time. >> DW_OP_AARCH64_pauth >> is designed as a generic operation that allow describing pointer signing >> on >> any value using any salt and key in case we can't use the shortcut >> operations >> we can use this. > > I admit to not fully understand the salting/keying involved. But given > that the DW_OP space is really tiny, so we would like to not eat up too > many of them for new opcodes. And given that introducing any new DW_OPs > using for CFI unwinding will break any unwinder anyway causing us to > update them all for this new feature. Have you thought about using a new > CIE augmentation string character for describing that the return > address/link register used by a function/frame is salted/keyed? > > This seems a good description of CIE records and augmentation > characters:http://www.airs.com/blog/archives/460 > > It obviously also involves updating all unwinders to understand the new > augmentation character (and possible arguments). But it might be more > generic and saves us from using up too many DW_OPs. From what I understood, the return address is not always scrambled, so it doesn't apply to the whole function, just to most of it (except for an insn in the prologue and some in the epilogue). So I think one op is needed. But can't it be just a toggable flag whether the return address is scrambled + some arguments to it? Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default way of scrambling starts here (if not already active) or any kind of scrambling ends here (if already active), and DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need to represent details of the less common variants with details what to do. Then you'd just hook through some MD_* macro in the unwinder the descrambling operation if the scrambling is active at the insns you unwind on. Jakub >>> >>> Hi Mark, Jakub: >>> >>>Thanks very much for the suggestions. >>> >>>I have done some experiments on your ideas and am thinking it's good to >>>combine them together. The use of DW_CFA instead of DW_OP can avoid >>> building >>>all information from scratch at each unwind location, while we can >>> indicate >>>the signing key index through new AArch64 CIE augmentation 'B'. This new >>>approach reduce the unwind table size overhead from ~25% to ~5% when >>> return >>>address signing enabled, it also largely simplified dwarf generation >>> code for >>>return address signing. >>> >>>As one new DWARF call frame instruction is needed for AArch64, I want to >>> reuse >>>DW_CFA_GNU_window_save to save the space. It is in vendor extension >>> space and >>>used for Sparc only, I think it make sense to reuse it for AArch64. On >>>AArch64, DW_CFA_GNU_window_save toggle return address sign status which >>> kept >>>in a new boolean type column in DWARF table, so DW_CFA_GNU_window_save >>> takes >>>no argument on AArch64, the same as on Sparc, this makes no difference >>> to those >>>existed encoding, length calculation code. >>> >>>Meanwhile one new DWARF expression operation number is still needed for >>>AArch64, it's useful for describing those complex pointer signing >>> scenarios >>>and it will be used to multiplex some further extensions on AArch64. >>> >>>OK on this proposal and to install this patch to gcc trunk? >>> >>> Hi GDB, Binutils maintainer: >>> >>>OK on this proposal and install this patch to binutils-gdb master? >>> >>> include/ >>> 2016-11-29 Richard Earnshaw >>> Jiong Wang >>> >>> * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. >> >> Ping~ > Ping^2 Ping^3 Can DWARF maintainers or global reviewers have a look at this? Thanks very much. -- Regards, Jiong
Re: [PATCH] Fix late dwarf generated early from optimized out globals
On December 27, 2016 11:17:00 PM GMT+01:00, Andreas Tobler wrote: >On 16.09.16 13:30, Richard Biener wrote: >> On Thu, 15 Sep 2016, Richard Biener wrote: >> >>> >>> This addresses sth I needed to address with the early LTO debug >patches >>> (you might now figure I'm piecemail merging stuff from that patch). >>> >>> When the cgraph code optimizes out a global we call the >late_global_decl >>> debug hook to eventually add a DW_AT_const_value to its DIE (we >don't >>> really expect a location as that will be invalid after optimizing >out >>> and will be pruned). >>> >>> With the early LTO debug patches I have introduced a >early_dwarf_finished >>> flag (mainly for consistency checking) and I figured I can use that >to >>> detect the call to the late hook during the early phase and provide >>> the following cleaned up variant of avoiding to create locations >that >>> require later pruning (which doesn't work with emitting the early >DIEs). >>> >>> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. >>> >>> I verified it does the correct thing for a unit like >>> >>> static const int i = 2; >>> >>> (but ISTR we do have at least one testcase in the testsuite as >well). >>> >>> Will commit if testing finishes successfully. >> >> Ok, so it showed issues when merging that back to early-LTO-debug. >> Turns out in LTO we never call early_finish and thus >early_dwarf_finished >> was never set. Also dwarf2out_late_global_decl itself is a better >> place to constrain generating locations. >> >> The following variant is in very late stage of testing. >> >> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. >> LTO bootstrap on x86_64-unknown-linux-gnu in stage3. LTO bootstrap >> with early-LTO-debug in stage3, bootstraped with early-LTO-debug, >> testing in progress. > >Any chance to backport this commit (r240228) to 6.x? >It fixes a bootstrap comparison issue on aarch64-*-freebsd*. >The aarch64-*-freebsd* port is not yet merged to 6.x and 5.4.x due to >the bootstrap comparison failure I faced. Did you analyze the bootstrap miscompare? I suspect the patch merely papers over the problem. Was that regular bootstrap (with or without compare-debug)? Richard. >I did a bootstrap with a backport of this revision to 6.x on >amd64-*-freebsd* and I did not see any issues. > >TIA, >Andreas > >> 2016-09-16 Richard Biener >> >> * dwarf2out.c (early_dwarf_finished): New global. >> (set_early_dwarf::set_early_dwarf): Assert early_dwarf_finished >> is false. >> (dwarf2out_early_finish): Set early_dwarf_finished at the end, >> if called from LTO exit early. >> (dwarf2out_late_global_decl): When being during the early >> debug phase do not add locations but only const value attributes. >> Adjust the way we generate early DIEs for LTO. >> >> lto/ >> * lto.c (lto_main): Invoke early_finish debug hook.
[PATCH][GIMPLEFE] Fix for ICE due to undeclared variable
Hi,
The attached patch tries fix ICE due to undeclared variable(s) in the input.
Successfully bootstrapped on x86_64-pc-linux-gnu, testing is in progress
Thanks,
Prasad
Changelog
Description: Binary data
diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index b7cef93..13bf2b1 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -516,7 +516,9 @@ c_parser_gimple_binary_expression (c_parser *parser)
rhs = c_parser_gimple_postfix_expression (parser);
if (c_parser_error (parser))
return ret;
- ret.value = build2_loc (ret_loc, code, ret_type, lhs.value, rhs.value);
+
+ if (lhs.value != error_mark_node && rhs.value != error_mark_node)
+ret.value = build2_loc (ret_loc, code, ret_type, lhs.value, rhs.value);
return ret;
}
@@ -653,7 +655,7 @@ c_parser_parse_ssa_name (c_parser *parser,
id = get_identifier (var_name);
tree parent = lookup_name (id);
XDELETEVEC (var_name);
- if (! parent)
+ if (! parent || parent == error_mark_node)
{
c_parser_error (parser, "base variable or SSA name not declared");
return error_mark_node;
@@ -1194,6 +1196,8 @@ c_parser_gimple_if_stmt (c_parser *parser, gimple_seq *seq)
location_t loc;
c_parser_consume_token (parser);
tree cond = c_parser_gimple_paren_condition (parser);
+ if (cond == error_mark_node)
+return;
if (c_parser_next_token_is_keyword (parser, RID_GOTO))
{
@@ -1252,7 +1256,7 @@ c_parser_gimple_if_stmt (c_parser *parser, gimple_seq *seq)
static void
c_parser_gimple_switch_stmt (c_parser *parser, gimple_seq *seq)
{
- c_expr cond_expr;
+ tree cond = error_mark_node;
tree case_label, label;
auto_vec labels;
tree default_label = NULL_TREE;
@@ -1261,9 +1265,11 @@ c_parser_gimple_switch_stmt (c_parser *parser, gimple_seq *seq)
if (c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
{
- cond_expr = c_parser_gimple_postfix_expression (parser);
+ cond = c_parser_gimple_postfix_expression (parser).value;
if (! c_parser_require (parser, CPP_CLOSE_PAREN, "expected %<)%>"))
return;
+ if (cond == error_mark_node)
+ return;
}
if (c_parser_require (parser, CPP_OPEN_BRACE, "expected %<{%>"))
@@ -1374,7 +1380,7 @@ c_parser_gimple_switch_stmt (c_parser *parser, gimple_seq *seq)
}
if (! c_parser_require (parser, CPP_CLOSE_BRACE, "expected %<}%>"))
return;
- gimple_seq_add_stmt (seq, gimple_build_switch (cond_expr.value,
+ gimple_seq_add_stmt (seq, gimple_build_switch (cond,
default_label, labels));
gimple_seq_add_seq (seq, switch_body);
labels.release();
Re: [PATCH][GIMPLEFE] Fix for ICE due to undeclared variable
Sorry for the wrong email address. On 28 December 2016 at 23:57, Prasad Ghangal wrote: > Hi, > The attached patch tries fix ICE due to undeclared variable(s) in the input. > Successfully bootstrapped on x86_64-pc-linux-gnu, testing is in progress > > > Thanks, > Prasad
Re: [PATCH] Fix late dwarf generated early from optimized out globals
On 28.12.16 19:24, Richard Biener wrote: On December 27, 2016 11:17:00 PM GMT+01:00, Andreas Tobler wrote: On 16.09.16 13:30, Richard Biener wrote: On Thu, 15 Sep 2016, Richard Biener wrote: This addresses sth I needed to address with the early LTO debug patches (you might now figure I'm piecemail merging stuff from that patch). When the cgraph code optimizes out a global we call the late_global_decl debug hook to eventually add a DW_AT_const_value to its DIE (we don't really expect a location as that will be invalid after optimizing out and will be pruned). With the early LTO debug patches I have introduced a early_dwarf_finished flag (mainly for consistency checking) and I figured I can use that to detect the call to the late hook during the early phase and provide the following cleaned up variant of avoiding to create locations that require later pruning (which doesn't work with emitting the early DIEs). Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. I verified it does the correct thing for a unit like static const int i = 2; (but ISTR we do have at least one testcase in the testsuite as well). Will commit if testing finishes successfully. Ok, so it showed issues when merging that back to early-LTO-debug. Turns out in LTO we never call early_finish and thus early_dwarf_finished was never set. Also dwarf2out_late_global_decl itself is a better place to constrain generating locations. The following variant is in very late stage of testing. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. LTO bootstrap on x86_64-unknown-linux-gnu in stage3. LTO bootstrap with early-LTO-debug in stage3, bootstraped with early-LTO-debug, testing in progress. Any chance to backport this commit (r240228) to 6.x? It fixes a bootstrap comparison issue on aarch64-*-freebsd*. The aarch64-*-freebsd* port is not yet merged to 6.x and 5.4.x due to the bootstrap comparison failure I faced. Did you analyze the bootstrap miscompare? I suspect the patch merely papers over the problem. gcc/contrib/compare-debug -p prev-gcc/ipa-icf.o gcc/ipa-icf.o prev-gcc/ipa-icf.o.stripped. gcc/ipa-icf.o.stripped. differ: char 52841, line 253 The objdump -dSx diff on the non stripped object looked always more or less the same, a rodata offset which was different. - 1448: R_AARCH64_ADD_ABS_LO12_NC .rodata+0x1d8 + 1448: R_AARCH64_ADD_ABS_LO12_NC .rodata+0x410 Was that regular bootstrap (with or without compare-debug)? Hm, regular bootstrap, --with-build-config=bootstrap-debug? Or do you have something else in mind? I rerun on 6.x w/o 'patch' now. Hopefully in 12h I have something. Btw, I bisected on trunk, r240227 was nok, the next, r240228 was ok. Then I took the part from r240228 to the 6.x branch and my comparison issue was gone. If I miss something you need to know pls let me know. TIA, Andreas
[PATCH, Fortran, pr78781, v1] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588
Hi all,
attached patch fixes and implements pointer components in derived typed
coarrays. The testcase in the description also has a class coarray, which is
still not implemented but tracked by pr77961. Therefore only the test in
comment #2 now passes.
Bootstraps and regtests ok on x86_64-linux/f23. Ok for trunk?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
pr78781_v1.clog
Description: Binary data
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index d351d0f..8ed2f23 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3734,9 +3734,20 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue)
if (rvalue->expr_type == EXPR_FUNCTION && !attr.pointer)
{
- gfc_error ("Target expression in pointer assignment "
- "at %L must deliver a pointer result",
- &rvalue->where);
+ /* F2008, C725. For PURE also C1283. Sometimes rvalue is a function call
+ to caf_get. Map this to the same error message as below when it is
+ still a variable expression. */
+ if (rvalue->value.function.isym
+ && rvalue->value.function.isym->id == GFC_ISYM_CAF_GET)
+ /* The test above might need to be extend when F08, Note 5.4 has to be
+ interpreted in the way that target and pointer with the same coindex
+ are allowed. */
+ gfc_error ("Data target at %L shall not have a coindex",
+ &rvalue->where);
+ else
+ gfc_error ("Target expression in pointer assignment "
+ "at %L must deliver a pointer result",
+ &rvalue->where);
return false;
}
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 200b419..39135bf 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2846,7 +2846,7 @@ int gfc_validate_kind (bt, int, bool);
int gfc_get_int_kind_from_width_isofortranenv (int size);
int gfc_get_real_kind_from_width_isofortranenv (int size);
tree gfc_get_union_type (gfc_symbol *);
-tree gfc_get_derived_type (gfc_symbol * derived, bool in_coarray = false);
+tree gfc_get_derived_type (gfc_symbol * derived, int codimen = 0);
extern int gfc_index_integer_kind;
extern int gfc_default_integer_kind;
extern int gfc_max_integer_kind;
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index f13b0f0..eb3dc0e 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2436,8 +2436,7 @@ gfc_expr_attr (gfc_expr *e)
static symbol_attribute
caf_variable_attr (gfc_expr *expr, bool in_allocate, bool *refs_comp)
{
- int dimension, codimension, pointer, allocatable, target, coarray_comp,
- alloc_comp;
+ int dimension, codimension, pointer, allocatable, target, coarray_comp;
symbol_attribute attr;
gfc_ref *ref;
gfc_symbol *sym;
@@ -2458,7 +2457,8 @@ caf_variable_attr (gfc_expr *expr, bool in_allocate, bool *refs_comp)
codimension = CLASS_DATA (sym)->attr.codimension;
pointer = CLASS_DATA (sym)->attr.class_pointer;
allocatable = CLASS_DATA (sym)->attr.allocatable;
- alloc_comp = CLASS_DATA (sym)->ts.u.derived->attr.alloc_comp;
+ attr.alloc_comp = CLASS_DATA (sym)->ts.u.derived->attr.alloc_comp;
+ attr.pointer_comp = CLASS_DATA (sym)->ts.u.derived->attr.pointer_comp;
}
else
{
@@ -2466,8 +2466,10 @@ caf_variable_attr (gfc_expr *expr, bool in_allocate, bool *refs_comp)
codimension = sym->attr.codimension;
pointer = sym->attr.pointer;
allocatable = sym->attr.allocatable;
- alloc_comp = sym->ts.type == BT_DERIVED
+ attr.alloc_comp = sym->ts.type == BT_DERIVED
? sym->ts.u.derived->attr.alloc_comp : 0;
+ attr.pointer_comp = sym->ts.type == BT_DERIVED
+ ? sym->ts.u.derived->attr.pointer_comp : 0;
}
target = coarray_comp = 0;
@@ -2545,7 +2547,6 @@ caf_variable_attr (gfc_expr *expr, bool in_allocate, bool *refs_comp)
attr.target = target;
attr.save = sym->attr.save;
attr.coarray_comp = coarray_comp;
- attr.alloc_comp = alloc_comp;
return attr;
}
@@ -2575,6 +2576,8 @@ gfc_caf_attr (gfc_expr *e, bool in_allocate, bool *refs_comp)
attr.pointer = CLASS_DATA (sym)->attr.class_pointer;
attr.allocatable = CLASS_DATA (sym)->attr.allocatable;
attr.alloc_comp = CLASS_DATA (sym)->ts.u.derived->attr.alloc_comp;
+ attr.pointer_comp = CLASS_DATA (sym)->ts.u.derived
+ ->attr.pointer_comp;
}
}
else if (e->symtree)
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index c559d0e..8a2b80e 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -5468,7 +5468,8 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg,
gfc_expr **lower;
gfc_expr **upper;
gfc_ref *ref, *prev_ref = NULL, *coref;
- bool allocatable, coarray, dimension, alloc_w_e3_arr_spec = false;
+ bool allocatable, coarray, dimension, alloc_w_e3_arr_spec = false,
+ non_ulimate_coarray_ptr_comp;
ref = expr->ref;
@@ -5482,10 +5483,17 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr, tree status, tree errmsg,
Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
> I'd like to point out that especially the vendor range of DW_OP_* is > extremely scarce resource, we have only a couple of unused values, so taking > 3 out of the remaining unused 12 for a single architecture is IMHO too much. > Can't you use just a single opcode and encode which of the 3 operations it is > in say the low 2 bits of a LEB 128 operand? > We'll likely need to do RSN some multiplexing even for the generic GNU > opcodes if we need just a few further ones (say 0xff as an extension, > followed by uleb128 containing the opcode - 0xff). > In the non-vendor area we still have 54 values left, so there is more space > for future expansion. Most of the Gnu extensions have been adopted into the standard as of DWARF 5: /* GNU extensions. */ DW_OP (DW_OP_GNU_push_tls_address, 0xe0) /* The following is for marking variables that are uninitialized. */ DW_OP (DW_OP_GNU_uninit, 0xf0) DW_OP (DW_OP_GNU_encoded_addr, 0xf1) /* The GNU implicit pointer extension. See http://www.dwarfstd.org/ShowIssue.php?issue=100831.1&type=open . */ DW_OP (DW_OP_GNU_implicit_pointer, 0xf2) /* The GNU entry value extension. See http://www.dwarfstd.org/ShowIssue.php?issue=100909.1&type=open . */ DW_OP (DW_OP_GNU_entry_value, 0xf3) /* The GNU typed stack extension. See http://www.dwarfstd.org/doc/040408.1.html . */ DW_OP (DW_OP_GNU_const_type, 0xf4) DW_OP (DW_OP_GNU_regval_type, 0xf5) DW_OP (DW_OP_GNU_deref_type, 0xf6) DW_OP (DW_OP_GNU_convert, 0xf7) DW_OP (DW_OP_GNU_reinterpret, 0xf9) /* The GNU parameter ref extension. */ DW_OP (DW_OP_GNU_parameter_ref, 0xfa) /* Extensions for Fission. See http://gcc.gnu.org/wiki/DebugFission. */ DW_OP (DW_OP_GNU_addr_index, 0xfb) DW_OP (DW_OP_GNU_const_index, 0xfc) Of these, I think only DW_OP_GNU_uninit and DW_OP_GNU_encoded_addr remain as Gnu extensions. The rest could be deprecated as of DWARF 5, and, if necessary, reused for other purposes in DWARF 6 and later. Depending on how aggressive we want to be with deprecation, we could even declare that they are available for reuse in DWARF 5 and later, as long as the Gnu toolchain uses only the new standard values when generating DWARF 5. That frees up 11 more opcodes. -cary
Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
> OK on this proposal and to install this patch to gcc trunk? > > Hi GDB, Binutils maintainer: > > OK on this proposal and install this patch to binutils-gdb master? > > include/ > 2016-11-29 Richard Earnshaw > Jiong Wang > > * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. This is OK, but: +/* AARCH64 extensions. + DW_OP_AARCH64_operation takes one mandatory unsigned LEB128 operand. + Bits[6:0] of this operand is the action code, all others bits are initialized + to 0 except explicitly documented for one action. Please refer AArch64 DWARF + ABI documentation for details. */ Is it possible to include a stable URL that points to the ABI document? -cary
[wwwdocs] news/ssa.html -- remove link to www.codesourcery.com
Applied. Gerald Index: news/ssa.html === RCS file: /cvs/gcc/wwwdocs/htdocs/news/ssa.html,v retrieving revision 1.6 diff -u -r1.6 ssa.html --- news/ssa.html 29 Dec 2006 10:03:38 - 1.6 +++ news/ssa.html 28 Dec 2016 01:56:56 - @@ -11,7 +11,7 @@ March 9, 2000 We are pleased to announce that -http://www.codesourcery.com";>CodeSourcery, LLC +CodeSourcery, LLC and http://www.redhat.com";>Cygnus, a Red Hat company have
[wwwdocs] Nick's Blog now defaults to https
...like all of developers.redhat.com. Applied. Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.1034 diff -u -r1.1034 index.html --- index.html 21 Dec 2016 11:21:20 - 1.1034 +++ index.html 28 Dec 2016 23:16:46 - @@ -115,7 +115,7 @@ https://gcc.gnu.org/news.html";>Older news | -http://developers.redhat.com/blog/author/nickclifton/";>Nick's Blog | +https://developers.redhat.com/blog/author/nickclifton/";>Nick's Blog | More news? Let ger...@pfeifer.com know!
[wwwdocs] Adjust to new upstream URL for OpenMP specifications
Adjust to new upstream URL for OpenMP specifications. On the way, avoid one duplicate (on that page) link and one for GCC 4.4. Appplied Index: gcc-4.4/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/changes.html,v retrieving revision 1.89 diff -u -r1.89 changes.html --- gcc-4.4/changes.html6 Dec 2014 16:29:22 - 1.89 +++ gcc-4.4/changes.html28 Dec 2016 23:40:24 - @@ -298,8 +298,7 @@ New Languages and Language specific improvements -Version 3.0 of the http://openmp.org/wp/openmp-specifications/";>OpenMP specification +Version 3.0 of the OpenMP specification is now supported for the C, C++, and Fortran compilers. New character data types, per Version 3.1 of the http://openmp.org/wp/openmp-specifications/";>OpenMP specification +href="http://www.openmp.org/specifications/";>OpenMP specification is now supported for the C, C++, and Fortran compilers. Index: gcc-4.9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.90 diff -u -r1.90 changes.html --- gcc-4.9/changes.html3 Aug 2016 04:48:49 - 1.90 +++ gcc-4.9/changes.html28 Dec 2016 23:40:26 - @@ -123,7 +123,7 @@ New Languages and Language specific improvements -Version 4.0 of the http://openmp.org/wp/openmp-specifications/"; +Version 4.0 of the http://www.openmp.org/specifications/"; >OpenMP specification is now supported in the C and C++ compilers and starting with the 4.9.1 release also in the Fortran compiler. The new -fopenmp-simd option can be used to enable OpenMP's @@ -753,9 +753,8 @@ complete (that is, it is possible that some PRs that have been fixed are not listed here). -Version 4.0 of the http://openmp.org/wp/openmp-specifications/"; - >OpenMP specification is supported even in Fortran, not just C and - C++. +Version 4.0 of the OpenMP specification is supported even in Fortran, +not just C and C++. GCC 4.9.2 Index: gcc-6/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v retrieving revision 1.90 diff -u -r1.90 changes.html --- gcc-6/changes.html 21 Dec 2016 07:46:08 - 1.90 +++ gcc-6/changes.html 28 Dec 2016 23:40:28 - @@ -178,7 +178,7 @@ C family -Version 4.5 of the http://openmp.org/wp/openmp-specifications/"; +Version 4.5 of the http://www.openmp.org/specifications/"; >OpenMP specification is now supported in the C and C++ compilers. The C and C++ compilers now support attributes on enumerators. For instance,
[RFC][C++] Parser: Simplifying tentative firewall
I carefully examined the code of setting up tentative firewalls to guard
current context in cp/parser.c recent days, and think the code could be
simplified.
For example, in function cp_parser_start_tentative_firewall,
4427 cp_parser_parse_tentatively (parser);
4428 cp_parser_commit_to_topmost_tentative_parse (parser);
A) cp_parser_parse_tentatively does following jobs:
1) create a new context
2) save current token
3) push deferring access
B) cp_parser_commit_to_topmost_tentative_parse does following jobs:
1) mark the new context as committed
2) pop current token
Clearly saving and popping current token is unneccessary.
Push deferring access is also unneccessary after a carefull analysis:
In function cp_parser_parse_definitely,
error_occurred = cp_parser_error_occurred (parser) will always return
false for committed context, so pop_to_parent_deferring_access_checks
is always got called, while pushed deferring access in step (A) won't
affect the result wether or not the access check should delayed to
parent access level.
Performance evaluation:
orig) perf stat -e instructions:u ../gcc/cc1plus.orig
g++.dg/template/friend28.C
59,171,628 instructions:u
after) perf stat -e instructions:u ../gcc/cc1plus g++.dg/template/friend28.C
59,171,598 instructions:u
bootstrapped and checked on x86-64
Signed-off-by: Zhouyi Zhou
---
gcc/cp/ChangeLog | 14 ++
gcc/cp/parser.c | 22 --
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 7aca3ac..f095b1d 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,17 @@
+2016-12-29 Zhouyi Zhou
+
+ Simplifying tentative firewalls
+ * parser.c (cp_parser_start_tentative_firewall): Simplifying
+ tentative firewall so that it only do the necessary jobs to
+ guard current context.
+ * parser.c (cp_parser_end_tentative_firewall): Simplifying the
+ end of tentative firewall.
+ * parser.c (tentative_firewall::tentative_firewall): Simplifying
+ tentative firewall so that it only do the necessary jobs to
+ guard current context.
+ * parser.c (tentative_firewall::~tentative_firewall): Simplifying
+ the end of tentative firewall.
+
2016-12-24 Jakub Jelinek
PR middle-end/78901
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index e2a0a49..ebcc802 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -4424,8 +4424,8 @@ cp_parser_start_tentative_firewall (cp_parser *parser)
if (!cp_parser_uncommitted_to_tentative_parse_p (parser))
return 0;
- cp_parser_parse_tentatively (parser);
- cp_parser_commit_to_topmost_tentative_parse (parser);
+ parser->context = cp_parser_context_new (parser->context);
+ parser->context->status = CP_PARSER_STATUS_KIND_COMMITTED;
return cp_lexer_token_position (parser->lexer, false);
}
@@ -4436,11 +4436,16 @@ static void
cp_parser_end_tentative_firewall (cp_parser *parser, cp_token_position start,
tree expr)
{
+ cp_parser_context *context;
+
if (!start)
return;
/* Finish the firewall level. */
- cp_parser_parse_definitely (parser);
+ context = parser->context;
+ parser->context = context->next;
+ context->next = cp_parser_context_free_list;
+ cp_parser_context_free_list = context;
/* And remember the result of the parse for when we try again. */
cp_token *token = cp_lexer_token_at (parser->lexer, start);
token->type = CPP_PREPARSED_EXPR;
@@ -4465,8 +4470,8 @@ struct tentative_firewall
firewall and then an inner tentative parse. */
if ((set = cp_parser_uncommitted_to_tentative_parse_p (parser)))
{
- cp_parser_parse_tentatively (parser);
- cp_parser_commit_to_topmost_tentative_parse (parser);
+ parser->context = cp_parser_context_new (parser->context);
+ parser->context->status = CP_PARSER_STATUS_KIND_COMMITTED;
cp_parser_parse_tentatively (parser);
}
}
@@ -4477,9 +4482,14 @@ struct tentative_firewall
{
/* Finish the inner tentative parse and the firewall, propagating any
uncommitted error state to the outer tentative parse. */
+ cp_parser_context *context;
bool err = cp_parser_error_occurred (parser);
cp_parser_parse_definitely (parser);
- cp_parser_parse_definitely (parser);
+ /* Finish the firewall level. */
+ context = parser->context;
+ parser->context = context->next;
+ context->next = cp_parser_context_free_list;
+ cp_parser_context_free_list = context;
if (err)
cp_parser_simulate_error (parser);
}
--
1.9.1
