Re: [wwwdocs] AVR entry in readings.htmls
This is a new one. http://www.microchip.com/design-centers/8-bit/microchip-avr-mcus 2018-03-10 20:15 GMT+04:00 Gerald Pfeifer : > It appears this link at atmel.com has been taken down without > what appears a replacement, so I applied the patch below. > > Denis, if you have a new reference, happy to add that, of course. > > Gerald > > Index: readings.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v > retrieving revision 1.289 > diff -u -r1.289 readings.html > --- readings.html 4 Mar 2018 10:02:19 - 1.289 > +++ readings.html 10 Mar 2018 16:10:22 - > @@ -88,7 +88,6 @@ > > AVR >Manufacturer: Atmel > - http://www.atmel.com/products/microcontrollers/avr/";>AVR > Documentation > > > Blackfin
New Spanish PO file for 'gcc' (version 8.1-b20180128)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/gcc/es.po (This file, 'gcc-8.1-b20180128.es.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
PING^2: [PATCH] i386: Don't generate alias for function return thunk
On Mon, Mar 5, 2018 at 4:17 AM, H.J. Lu wrote: > On Mon, Feb 26, 2018 at 12:48 PM, H.J. Lu wrote: >> Function return thunks shouldn't be aliased to indirect branch thunks >> since indirect branch thunks are placed in COMDAT section and a COMDAT >> section with indirect branch may not have function return thunk. This >> patch generates function return thunks directly. >> >> Tested on i686 and x86-64. OK for trunk? >> >> H.J. >> --- >> gcc/ >> >> PR target/84574 >> * config/i386/i386.c (indirect_thunk_needed): Update comments. >> (indirect_thunk_bnd_needed): Likewise. >> (indirect_thunks_used): Likewise. >> (indirect_thunks_bnd_used): Likewise. >> (indirect_return_needed): New. >> (indirect_return_bnd_needed): Likewise. >> (output_indirect_thunk_function): Add a bool argument for >> function return. >> (output_indirect_thunk_function): Don't generate alias for >> function return thunk. >> (ix86_code_end): Call output_indirect_thunk_function to generate >> function return thunks. >> (ix86_output_function_return): Set indirect_return_bnd_needed >> and indirect_return_needed instead of indirect_thunk_bnd_needed >> and indirect_thunk_needed. >> >> gcc/testsuite/ >> >> PR target/84574 >> * gcc.target/i386/ret-thunk-9.c: Expect __x86_return_thunk >> label instead of __x86_indirect_thunk label. > > PING: > > https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01460.html > PING. -- H.J.
PING^2: [PATCH] x86: Force __x86_indirect_thunk_reg for function call via GOT
On Mon, Mar 5, 2018 at 4:20 AM, H.J. Lu wrote: > On Tue, Feb 27, 2018 at 11:39 AM, H.J. Lu wrote: >> For x86 targets, when -fno-plt is used, external functions are called >> via GOT slot, in 64-bit mode: >> >> [bnd] call/jmp *foo@GOTPCREL(%rip) >> >> and in 32-bit mode: >> >> [bnd] call/jmp *foo@GOT[(%reg)] >> >> With -mindirect-branch=, they are converted to, in 64-bit mode: >> >> pushq foo@GOTPCREL(%rip) >> [bnd] jmp __x86_indirect_thunk[_bnd] >> >> and in 32-bit mode: >> >> pushl foo@GOT[(%reg)] >> [bnd] jmp __x86_indirect_thunk[_bnd] >> >> which were incompatible with CFI. In 64-bit mode, since R11 is a scratch >> register, we generate: >> >> movq foo@GOTPCREL(%rip), %r11 >> [bnd] call/jmp __x86_indirect_thunk_[bnd_]r11 >> >> instead. We do it in ix86_output_indirect_branch so that we can use >> the newly proposed R_X86_64_THUNK_GOTPCRELX relocation: >> >> https://groups.google.com/forum/#!topic/x86-64-abi/eED5lzn3_Mg >> >> movq foo@OTPCREL_THUNK(%rip), %r11 >> [bnd] call/jmp __x86_indirect_thunk_[bnd_]r11 >> >> to load GOT slot into R11. If foo is defined locally, linker can can >> convert >> >> movq foo@GOTPCREL_THUNK(%rip), %reg >> call/jmp __x86_indirect_thunk_reg >> >> to >> >> call/jmp foo >> nop0L(%rax) >> >> In 32-bit mode, since all caller-saved registers, EAX, EDX and ECX, may >> used to function parameters, there is no scratch register available. For >> -fno-plt -fno-pic -mindirect-branch=, we expand external function call >> to: >> >> movl foo@GOT, %reg >> [bnd] call/jmp *%reg >> >> so that it can be converted to >> >> movl foo@GOT, %reg >> [bnd] call/jmp __x86_indirect_thunk_[bnd_]reg >> >> in ix86_output_indirect_branch. Since this is performed during RTL >> expansion, other instructions may be inserted between movl and call/jmp. >> Linker optimization isn't always possible. >> >> Tested on i686 and x86-64. OK for trunk? >> >> >> H.J. >> --- >> gcc/ >> >> PR target/83970 >> * config/i386/constraints.md (Bs): Allow GOT_memory_operand >> for TARGET_LP64 with indirect branch conversion. >> (Bw): Likewise. >> * config/i386/i386.c (ix86_expand_call): Handle -fno-plt with >> -mindirect-branch=. >> (ix86_nopic_noplt_attribute_p): Likewise. >> (ix86_output_indirect_branch): In 64-bit mode, convert function >> call via GOT with R11 as a scratch register using >> __x86_indirect_thunk_r11. >> (ix86_output_call_insn): In 64-bit mode, set xasm to NULL when >> calling ix86_output_indirect_branch with function call via GOT. >> * config/i386/i386.md (*call_got_thunk): New call pattern for >> TARGET_LP64 with indirect branch conversion. >> (*call_value_got_thunk): Likewise. >> >> gcc/testsuite/ >> >> PR target/83970 >> * gcc.target/i386/indirect-thunk-5.c: Updated. >> * gcc.target/i386/indirect-thunk-6.c: Likewise. >> * gcc.target/i386/indirect-thunk-bnd-3.c: Likewise. >> * gcc.target/i386/indirect-thunk-bnd-4.c: Likewise. >> * gcc.target/i386/indirect-thunk-extern-5.c: Likewise. >> * gcc.target/i386/indirect-thunk-extern-6.c: Likewise. >> * gcc.target/i386/indirect-thunk-inline-5.c: Likewise. >> * gcc.target/i386/indirect-thunk-inline-6.c: Likewise. >> * gcc.target/i386/indirect-thunk-13.c: New test. >> * gcc.target/i386/indirect-thunk-14.c: Likewise. >> * gcc.target/i386/indirect-thunk-bnd-5.c: Likewise. >> * gcc.target/i386/indirect-thunk-bnd-6.c: Likewise. >> * gcc.target/i386/indirect-thunk-extern-11.c: Likewise. >> * gcc.target/i386/indirect-thunk-extern-12.c: Likewise. >> * gcc.target/i386/indirect-thunk-inline-8.c: Likewise. >> * gcc.target/i386/indirect-thunk-inline-9.c: Likewise. > > PING: > > https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01527.html > PING. -- H.J.
New Swedish PO file for 'gcc' (version 8.1-b20180128)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-8.1-b20180128.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
[PATCH] Fix bogus strncpy source length warning on source bound by constant
Avoid issuing a bogus warning when the source of strncpy is bound by a
constant and is known to be less than the size of the destination.
Testsuite run is underway (not complete yet, but no new errors so far)
and a bootstrap is also underway, I'll report status once they're both
done.
gcc/
* gcc/tree-ssa-strlen.c (handle_builtin_stxncpy): Check bounds
of source length if available.
gcc/testsuite/
* gcc.dg/builtin-stringop-chk-10.c: New test case.
---
gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c | 17 +
gcc/tree-ssa-strlen.c | 24
2 files changed, 41 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c
diff --git a/gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c
b/gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c
new file mode 100644
index 000..13e4bd2f049
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c
@@ -0,0 +1,17 @@
+/* Bogus -Wstringop-overflow on strncpy when size is based on strlen but is
+ bound by a constant.
+ { dg-do compile }
+ { dg-options "-O2 -Wstringop-overflow" } */
+
+char dst[1024];
+
+void
+f1 (const char *src)
+{
+ unsigned long limit = 512;
+ unsigned long len = __builtin_strlen (src); /* { dg-bogus "length computed
here" } */
+ if (len > limit)
+len = limit;
+
+ __builtin_strncpy (dst, src, len); /* { dg-bogus "specified bound depends
on the length of the source argument" } */
+}
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 72f6a17cd32..49a31a551f5 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -2125,6 +2125,30 @@ handle_builtin_stxncpy (built_in_function,
gimple_stmt_iterator *gsi)
return;
}
+ /* When LEN is MIN_EXPR of strlen and a constant, then the copy is bound by
+ that constant. If the destination size is also constant then compare with
+ it to avoid a bogus warning. */
+ if (TREE_CODE (len) == SSA_NAME)
+{
+ gimple *def_stmt = SSA_NAME_DEF_STMT (len);
+
+ if (is_gimple_assign (def_stmt)
+ && gimple_assign_rhs_code (def_stmt) == MIN_EXPR)
+ {
+ /* RHS1 is the strlen, so check if RHS2 and DSTSIZE are constant. */
+ tree rhs2 = gimple_assign_rhs2 (def_stmt);
+ tree dstsize = compute_objsize (dst, 1);
+
+ if (TREE_CODE (rhs2) == INTEGER_CST
+ && TREE_CODE (dstsize) == INTEGER_CST
+ && int_cst_value (rhs2) < int_cst_value (dstsize))
+ {
+ gimple_set_no_warning (stmt, true);
+ return;
+ }
+ }
+}
+
/* Retrieve the strinfo data for the string S that LEN was computed
from as some function F of strlen (S) (i.e., LEN need not be equal
to strlen(S)). */
--
2.14.3
[PATCH, rs6000] Fix PR83789: __builtin_altivec_lvx fails for powerpc for altivec-4.c
PR83789 shows a problem in the builtin expansion code not calling the correct
define_insn, given the correct mode (32-bit versus 64-bit). One could add
tests in this code to call the correct pattern, but it's easier to create
a common define_expand which everyone can call that does the right thing.
This allows us to clean up all the callers, making for much simpler code.
This also fixes the issue that Segher mentioned that this needs fixing for
multiple other vector modes and not just the one mentioned in the bugzilla.
This passed bootstrap and regtesting on powerpc64le-linux and powerpc64-linux
(running testsuite in both 32-bit and 64-bit modes) with no regressions.
Ok for trunk?
I was not able to reproduce the failure reported in the bugzilla, but Kaushik
confirmed that this patch fixes the ICE.
P.S. I will be away on vacation for the neek week, so if this is ok, I won't
be able to commit the patch until I return. Unless you want to commit
it Segher and watch for fallout. It's up to you.
Peter
PR target/83789
* config/rs6000/altivec.md (altivec_lvx__2op): Delete define_insn.
(altivec_lvx__1op): Likewise.
(altivec_stvx__2op): Likewise.
(altivec_stvx__1op): Likewise.
(altivec_lvx_): New define_expand.
(altivec_stvx_): Likewise.
(altivec_lvx__2op_): New define_insn.
(altivec_lvx__1op_): Likewise.
(altivec_stvx__2op_): Likewise.
(altivec_stvx__1op_): Likewise.
* config/rs6000/rs6000-p8swap.c (rs6000_gen_stvx): Use new expanders.
(rs6000_gen_lvx): Likewise.
* config/rs6000/rs6000.c (altivec_expand_lv_builtin): Likewise.
(altivec_expand_stv_builtin): Likewise.
(altivec_expand_builtin): Likewise.
* config/rs6000/vector.md: Likewise.
Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md(revision 258348)
+++ gcc/config/rs6000/altivec.md(working copy)
@@ -2747,39 +2747,47 @@ (define_insn "altivec_lvx__interna
"lvx %0,%y1"
[(set_attr "type" "vecload")])
-; The next two patterns embody what lvx should usually look like.
-(define_insn "altivec_lvx__2op"
- [(set (match_operand:VM2 0 "register_operand" "=v")
-(mem:VM2 (and:DI (plus:DI (match_operand:DI 1 "register_operand" "b")
- (match_operand:DI 2 "register_operand" "r"))
-(const_int -16]
- "TARGET_ALTIVEC && TARGET_64BIT"
- "lvx %0,%1,%2"
- [(set_attr "type" "vecload")])
-
-(define_insn "altivec_lvx__1op"
- [(set (match_operand:VM2 0 "register_operand" "=v")
-(mem:VM2 (and:DI (match_operand:DI 1 "register_operand" "r")
-(const_int -16]
- "TARGET_ALTIVEC && TARGET_64BIT"
- "lvx %0,0,%1"
- [(set_attr "type" "vecload")])
+; The following patterns embody what lvx should usually look like.
+(define_expand "altivec_lvx_"
+ [(set (match_operand:VM2 0 "register_operand" "")
+ (match_operand:VM2 1 "altivec_indexed_or_indirect_operand" ""))]
+ "TARGET_ALTIVEC"
+{
+ rtx addr = XEXP (operand1, 0);
+ if (rs6000_sum_of_two_registers_p (addr))
+{
+ rtx op1 = XEXP (addr, 0);
+ rtx op2 = XEXP (addr, 1);
+ if (TARGET_64BIT)
+ emit_insn (gen_altivec_lvx__2op_di (operand0, op1, op2));
+ else
+ emit_insn (gen_altivec_lvx__2op_si (operand0, op1, op2));
+}
+ else
+{
+ if (TARGET_64BIT)
+ emit_insn (gen_altivec_lvx__1op_di (operand0, addr));
+ else
+ emit_insn (gen_altivec_lvx__1op_si (operand0, addr));
+}
+ DONE;
+})
-; 32-bit versions of the above.
-(define_insn "altivec_lvx__2op_si"
+; The next two patterns embody what lvx should usually look like.
+(define_insn "altivec_lvx__2op_"
[(set (match_operand:VM2 0 "register_operand" "=v")
-(mem:VM2 (and:SI (plus:SI (match_operand:SI 1 "register_operand" "b")
- (match_operand:SI 2 "register_operand" "r"))
-(const_int -16]
- "TARGET_ALTIVEC && TARGET_32BIT"
+ (mem:VM2 (and:P (plus:P (match_operand:P 1 "register_operand" "b")
+ (match_operand:P 2 "register_operand" "r"))
+ (const_int -16]
+ "TARGET_ALTIVEC"
"lvx %0,%1,%2"
[(set_attr "type" "vecload")])
-(define_insn "altivec_lvx__1op_si"
+(define_insn "altivec_lvx__1op_"
[(set (match_operand:VM2 0 "register_operand" "=v")
-(mem:VM2 (and:SI (match_operand:SI 1 "register_operand" "r")
-(const_int -16]
- "TARGET_ALTIVEC && TARGET_32BIT"
+ (mem:VM2 (and:P (match_operand:P 1 "register_operand" "r")
+ (const_int -16]
+ "TARGET_ALTIVEC"
"lvx %0,0,%1"
[(set_attr "type" "vecload")])
@@ -2795,39 +2803,47 @@ (define_insn "altivec_stvx__intern
"stvx %1,%y0"
[(set_attr "type" "vecstore")])
-; The next two patterns embody what
Re: [PATCH] Fix scoped enum debug info (PR debug/58150)
OK.
On Fri, Mar 9, 2018 at 1:15 PM, Jakub Jelinek wrote:
> Hi!
>
> As the following testcase shows, we emit bad debug info if a scoped
> enum is used before the enumerators are defined.
> gen_enumeration_type_die has support for enum forward declarations that
> have NULL TYPE_SIZE (i.e. incomplete), but in this case it is complete,
> just is ENUM_IS_OPAQUE and the enumerators aren't there. We still set
> TREE_ASM_WRITTEN on it and therefore don't do anything when it actually is
> completed.
>
> The following patch does change/fix a bunch of things:
> 1) I don't see the point of guarding the addition of DW_AT_declaration
> to just -gdwarf-4 or -gno-strict-dwarf, that is already DWARF2 attribute and
> we are emitting it for the forward declarations already
> 2) we don't set TREE_ASM_WRITTEN if ENUM_IS_OPAQUE
> 3) we don't try to do anything if it is ENUM_IS_OPAQUE that hasn't been
> newly created; similarly to incomplete forward redeclarations, we should
> have provided all that is needed on the first declaration
> 4) the addition of most attributes guarded with TYPE_SIZE is guarded by
> (!original_type_die || !get_AT (type_die, DW_AT_...)); the
> !original_type_die || part is just an optimization, so we don't try to query
> it in the common cases where we are creating a fresh type die; anyway, the
> reason for the guards is that we can now do the code twice for the same
> type_die (on declaration and definition), and don't want to add the attributes
> twice
> 5) not sure if ENUM_IS_OPAQUE must always imply non-NULL TYPE_SIZE, if not,
> in that case we'd add the DW_AT_deprecated attribute twice
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-03-09 Jakub Jelinek
>
> PR debug/58150
> * dwarf2out.c (gen_enumeration_type_die): Don't guard adding
> DW_AT_declaration for ENUM_IS_OPAQUE on -gdwarf-4 or
> -gno-strict-dwarf,
> but on TYPE_SIZE. Don't do anything for ENUM_IS_OPAQUE if not
> creating
> a new die. Don't set TREE_ASM_WRITTEN if ENUM_IS_OPAQUE. Guard
> addition of most attributes on !orig_type_die or the attribute not
> being present already. Assert TYPE_VALUES is NULL for ENUM_IS_OPAQUE.
>
> * g++.dg/debug/dwarf2/enum2.C: New test.
>
> --- gcc/dwarf2out.c.jj 2018-03-08 22:49:41.965225512 +0100
> +++ gcc/dwarf2out.c 2018-03-09 14:53:15.596115625 +0100
> @@ -21839,6 +21839,7 @@ static dw_die_ref
> gen_enumeration_type_die (tree type, dw_die_ref context_die)
> {
>dw_die_ref type_die = lookup_type_die (type);
> + dw_die_ref orig_type_die = type_die;
>
>if (type_die == NULL)
> {
> @@ -21846,20 +21847,18 @@ gen_enumeration_type_die (tree type, dw_
> scope_die_for (type, context_die), type);
>equate_type_number_to_die (type, type_die);
>add_name_attribute (type_die, type_tag (type));
> - if (dwarf_version >= 4 || !dwarf_strict)
> - {
> - if (ENUM_IS_SCOPED (type))
> - add_AT_flag (type_die, DW_AT_enum_class, 1);
> - if (ENUM_IS_OPAQUE (type))
> - add_AT_flag (type_die, DW_AT_declaration, 1);
> - }
> + if ((dwarf_version >= 4 || !dwarf_strict)
> + && ENUM_IS_SCOPED (type))
> + add_AT_flag (type_die, DW_AT_enum_class, 1);
> + if (ENUM_IS_OPAQUE (type) && TYPE_SIZE (type))
> + add_AT_flag (type_die, DW_AT_declaration, 1);
>if (!dwarf_strict)
> add_AT_unsigned (type_die, DW_AT_encoding,
> TYPE_UNSIGNED (type)
> ? DW_ATE_unsigned
> : DW_ATE_signed);
> }
> - else if (! TYPE_SIZE (type))
> + else if (! TYPE_SIZE (type) || ENUM_IS_OPAQUE (type))
> return type_die;
>else
> remove_AT (type_die, DW_AT_declaration);
> @@ -21871,10 +21870,14 @@ gen_enumeration_type_die (tree type, dw_
> {
>tree link;
>
> - TREE_ASM_WRITTEN (type) = 1;
> - add_byte_size_attribute (type_die, type);
> - add_alignment_attribute (type_die, type);
> - if (dwarf_version >= 3 || !dwarf_strict)
> + if (!ENUM_IS_OPAQUE (type))
> + TREE_ASM_WRITTEN (type) = 1;
> + if (!orig_type_die || !get_AT (type_die, DW_AT_byte_size))
> + add_byte_size_attribute (type_die, type);
> + if (!orig_type_die || !get_AT (type_die, DW_AT_alignment))
> + add_alignment_attribute (type_die, type);
> + if ((dwarf_version >= 3 || !dwarf_strict)
> + && (!orig_type_die || !get_AT (type_die, DW_AT_type)))
> {
> tree underlying = lang_hooks.types.enum_underlying_base_type (type);
> add_type_attribute (type_die, underlying, TYPE_UNQUALIFIED, false,
> @@ -21882,8 +21885,10 @@ gen_enumeration_type_die (tree type, dw_
> }
>if (TYPE_STUB_DECL (type) != NULL_TREE)
> {
> - add_src_coords_attributes (type_die, TYPE_STUB_DECL (type));
> - add_accessibility_attribute (type_die, TYPE_ST
[PATCH] Fortran -- clean up KILL
The attach patch cleans up KILL to match its
documentation. In doing so, I have changed
the argument keywords to consistently use
pid and sig. If no one objects, I intend to
commit this tomorrow.
2018-03-11 Steven G. Kargl
* check.c (gfc_check_kill): Check pid and sig are scalar.
(gfc_check_kill_sub): Restrict kind to 4 and 8.
* intrinsic.c (add_function): Sort keyword list. Add pid and sig
keywords for KILL. Remove redundant *back="back" in favor of the
original *bck="back".
(add_subroutines): Sort keyword list. Add pid and sig keywords
for KILL.
* intrinsic.texi: Fix documentation to consistently use pid and sig.
* iresolve.c (gfc_resolve_kill): Kind can only be 4 or 8. Choose the
correct function.
(gfc_resolve_rename_sub): Add comment.
--
Steve
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 258433)
+++ gcc/fortran/check.c (working copy)
@@ -2755,9 +2755,15 @@ gfc_check_kill (gfc_expr *pid, gfc_expr *sig)
if (!type_check (pid, 0, BT_INTEGER))
return false;
+ if (!scalar_check (pid, 0))
+return false;
+
if (!type_check (sig, 1, BT_INTEGER))
return false;
+ if (!scalar_check (sig, 1))
+return false;
+
return true;
}
@@ -2785,6 +2791,13 @@ gfc_check_kill_sub (gfc_expr *pid, gfc_expr *sig, gfc_
if (!scalar_check (status, 2))
return false;
+
+ if (status->ts.kind != 4 && status->ts.kind != 8)
+{
+ gfc_error ("Invalid kind type parameter for STATUS at %L",
+ &status->where);
+ return false;
+}
return true;
}
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (revision 258433)
+++ gcc/fortran/intrinsic.c (working copy)
@@ -1229,25 +1229,26 @@ set_attr_value (int n, ...)
static void
add_functions (void)
{
- /* Argument names as in the standard (to be used as argument keywords). */
+ /* Argument names. These are used as argument keywords and so need to
+match the documentation. Please keep this list in sorted order. */
const char
-*a = "a", *f = "field", *pt = "pointer", *tg = "target",
-*b = "b", *m = "matrix", *ma = "matrix_a", *mb = "matrix_b",
-*c = "c", *n = "n", *ncopies= "ncopies", *pos = "pos", *bck = "back",
-*i = "i", *v = "vector", *va = "vector_a", *vb = "vector_b",
-*j = "j", *a1 = "a1", *fs = "fsource", *ts = "tsource",
-*l = "l", *a2 = "a2", *mo = "mold", *ord = "order",
-*p = "p", *ar = "array", *shp = "shape", *src = "source",
-*r = "r", *bd = "boundary", *pad = "pad", *set = "set",
-*s = "s", *dm = "dim", *kind = "kind", *msk = "mask",
-*x = "x", *sh = "shift", *stg = "string", *ssg = "substring",
-*y = "y", *sz = "size", *sta = "string_a", *stb = "string_b",
-*z = "z", *ln = "len", *ut = "unit", *han = "handler",
-*num = "number", *tm = "time", *nm = "name", *md = "mode",
-*vl = "values", *p1 = "path1", *p2 = "path2", *com = "command",
-*ca = "coarray", *sub = "sub", *dist = "distance", *failed="failed",
-*c_ptr_1 = "c_ptr_1", *c_ptr_2 = "c_ptr_2", *back = "back",
-*team = "team", *image = "image", *level = "level";
+*a = "a", *a1 = "a1", *a2 = "a2", *ar = "array", *b = "b",
+*bck = "back", *bd = "boundary", *c = "c", *c_ptr_1 = "c_ptr_1",
+*c_ptr_2 = "c_ptr_2", *ca = "coarray", *com = "command",
+*dist = "distance", *dm = "dim", *f = "field", *failed="failed",
+*fs = "fsource", *han = "handler", *i = "i",
+*image = "image", *j = "j", *kind = "kind",
+*l = "l", *ln = "len", *level = "level", *m = "matrix", *ma = "matrix_a",
+*mb = "matrix_b", *md = "mode", *mo = "mold", *msk = "mask",
+*n = "n", *ncopies= "ncopies", *nm = "name", *num = "number",
+*ord = "order", *p = "p", *p1 = "path1", *p2 = "path2",
+*pad = "pad", *pid = "pid", *pos = "pos", *pt = "pointer",
+*r = "r", *s = "s", *set = "set", *sh = "shift", *shp = "shape",
+*sig = "sig", *src = "source", *ssg = "substring",
+*sta = "string_a", *stb = "string_b", *stg = "string",
+*sub = "sub", *sz = "size", *tg = "target", *team = "team", *tm = "time",
+*ts = "tsource", *ut = "unit", *v = "vector", *va = "vector_a",
+*vb = "vector_b", *vl = "values", *x = "x", *y = "y", *z = "z";
int di, dr, dd, dl, dc, dz, ii;
@@ -2255,7 +2256,7 @@ add_functions (void)
add_sym_2 ("kill", GFC_ISYM_KILL, CLASS_IMPURE, ACTUAL_NO, BT_INTEGER,
di, GFC_STD_GNU, gfc_check_kill, NULL, gfc_resolve_kill,
- a, BT_INTEGER, di, REQUIRED, b, BT_INTEGER, di, REQUIRED);
+ pid, BT_INTEGER, di, REQUIRED, sig, BT_INTEGER, di, REQUIRED);
make_generic ("kill", GFC_ISYM_KILL, GFC_STD_GNU);
@@ -2471,7 +2472,7 @@ add_functions (void)
gfc_check_minloc_maxloc, gfc_simplify_maxloc, gfc_resolve_maxloc,
ar, BT_REAL, dr, REQUIRED, dm, BT_INTEGER, ii, OPTIO
New German PO file for 'gcc' (version 8.1-b20180128)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/gcc/de.po (This file, 'gcc-8.1-b20180128.de.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
[wwwdocs] math.nist.gov has moved to https (readings.html)
Applied. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.290 diff -u -r1.290 readings.html --- readings.html 10 Mar 2018 16:15:35 - 1.290 +++ readings.html 11 Mar 2018 18:50:39 - @@ -370,7 +370,7 @@ - http://math.nist.gov/tnt/";>Template Numeric Toolkit + https://math.nist.gov/tnt/";>Template Numeric Toolkit http://www.boost.org";>The Boost C++ Libraries
[wwwdocs] www-cs-faculty.stanford.edu has moved to https (projects/prefetch.html)
It appears I already fixed this weeks, if not months ago, except that actually committing the changes helps? Done now. Gerald Index: projects/prefetch.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/prefetch.html,v retrieving revision 1.31 diff -u -r1.31 prefetch.html --- projects/prefetch.html 5 Nov 2017 11:05:57 - 1.31 +++ projects/prefetch.html 11 Mar 2018 18:57:43 - @@ -781,13 +781,13 @@ search from www.mips.com. [11] -http://www-cs-faculty.stanford.edu/~knuth/mmop.html";> +https://www-cs-faculty.stanford.edu/~knuth/mmop.html";> MMIX Op Codes, Don Knuth. [12] The Art of Computer Programming, Fascicle 1: MMIX, Don Knuth, Addison Wesley Longman, 2001; -http://www-cs-faculty.stanford.edu/~knuth/fasc1.ps.gz";> +https://www-cs-faculty.stanford.edu/~knuth/fasc1.ps.gz";> http://www-cs-faculty.stanford.edu/~uno/fasc1.ps.gz. [13]
[Patch, fortran] PR84546 - [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component
This regression came about because the vtable deep copy for derived
types with unlimited polymorphic components was not making use of the
_len parameter to compute the memory to be allocated and the offsets
to array elements.
The ChangeLogs are reasonably self explanatory.
Bootstraps and regtests on FC27/x86_64 - OK for trunk and 7-branch?
Paul
2018-03-11 Paul Thomas
PR fortran/84546
* trans-array.c (structure_alloc_comps): Make sure that the
vptr is copied and that the unlimited polymorphic _len is used
to compute the size to be allocated.
* trans-expr.c (gfc_get_class_array_ref): If unlimited, use the
unlimited polymorphic _len for the offset to the element.
(gfc_copy_class_to_class): Set the new 'unlimited' argument.
* trans.h : Add the boolean 'unlimited' to the prototype.
2018-03-11 Paul Thomas
PR fortran/84546
* gfortran.dg/unlimited_polymorphic_29.f90 : New test.
Index: gcc/fortran/trans-array.c
===
*** gcc/fortran/trans-array.c (revision 258189)
--- gcc/fortran/trans-array.c (working copy)
*** structure_alloc_comps (gfc_symbol * der_
*** 8883,
--- 8883,8913
gfc_init_block (&tmpblock);
+ gfc_add_modify (&tmpblock, gfc_class_vptr_get (dcmp),
+ gfc_class_vptr_get (comp));
+
+ /* Copy the unlimited '_len' field. If it is greater than zero
+ (ie. a character(_len)), multiply it by size and use this
+ for the malloc call. */
+ if (UNLIMITED_POLY (c))
+ {
+ tree ctmp;
+ gfc_add_modify (&tmpblock, gfc_class_len_get (dcmp),
+ gfc_class_len_get (comp));
+
+ size = gfc_evaluate_now (size, &tmpblock);
+ tmp = gfc_class_len_get (comp);
+ ctmp = fold_build2_loc (input_location, MULT_EXPR,
+ size_type_node, size,
+ fold_convert (size_type_node, tmp));
+ tmp = fold_build2_loc (input_location, GT_EXPR,
+ logical_type_node, tmp,
+ build_zero_cst (TREE_TYPE (tmp)));
+ size = fold_build3_loc (input_location, COND_EXPR,
+ size_type_node, tmp, ctmp, size);
+ size = gfc_evaluate_now (size, &tmpblock);
+ }
+
/* Coarray component have to have the same allocation status and
shape/type-parameter/effective-type on the LHS and RHS of an
intrinsic assignment. Hence, we did not deallocated them - and
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c (revision 258189)
--- gcc/fortran/trans-expr.c (working copy)
*** gfc_conv_class_to_class (gfc_se *parmse,
*** 1185,1199
of the referenced element. */
tree
! gfc_get_class_array_ref (tree index, tree class_decl, tree data_comp)
{
! tree data = data_comp != NULL_TREE ? data_comp :
! gfc_class_data_get (class_decl);
! tree size = gfc_class_vtab_size_get (class_decl);
! tree offset = fold_build2_loc (input_location, MULT_EXPR,
! gfc_array_index_type,
! index, size);
! tree ptr;
data = gfc_conv_descriptor_data_get (data);
ptr = fold_convert (pvoid_type_node, data);
ptr = fold_build_pointer_plus_loc (input_location, ptr, offset);
--- 1185,1216
of the referenced element. */
tree
! gfc_get_class_array_ref (tree index, tree class_decl, tree data_comp,
! bool unlimited)
{
! tree data, size, tmp, ctmp, offset, ptr;
!
! data = data_comp != NULL_TREE ? data_comp :
! gfc_class_data_get (class_decl);
! size = gfc_class_vtab_size_get (class_decl);
!
! if (unlimited)
! {
! tmp = fold_convert (gfc_array_index_type,
! gfc_class_len_get (class_decl));
! ctmp = fold_build2_loc (input_location, MULT_EXPR,
! gfc_array_index_type, size, tmp);
! tmp = fold_build2_loc (input_location, GT_EXPR,
! logical_type_node, tmp,
! build_zero_cst (TREE_TYPE (tmp)));
! size = fold_build3_loc (input_location, COND_EXPR,
! gfc_array_index_type, tmp, ctmp, size);
! }
!
! offset = fold_build2_loc (input_location, MULT_EXPR,
! gfc_array_index_type,
! index, size);
!
data = gfc_conv_descriptor_data_get (data);
ptr = fold_convert (pvoid_type_node, data);
ptr = fold_build_pointer_plus_loc (input_location, ptr, offset);
*** gfc_copy_class_to_class (tree from, tree
*** 1295,1308
if (is_from_desc)
{
! from_ref = gfc_get_class_array_ref (index, from, from_data);
vec_safe_push (args, from_ref);
}
else
vec_safe_push (args, from_data);
if (is_to_class)
! to_ref = gfc_get_class_array_ref (index, to, to_data);
else
{
tmp = gfc_conv_array_data (to);
--- 1312,1326
if (is_from_desc)
{
! from_ref = gfc_get_class_array_ref (index, from, from_data,
! unlimited);
vec_safe_push (args, from_ref);
}
else
vec_safe_push (args, from_da
Re: [Patch, fortran] PR84546 - [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component
On 03/11/2018 12:23 PM, Paul Richard Thomas wrote: This regression came about because the vtable deep copy for derived types with unlimited polymorphic components was not making use of the _len parameter to compute the memory to be allocated and the offsets to array elements. The ChangeLogs are reasonably self explanatory. Bootstraps and regtests on FC27/x86_64 - OK for trunk and 7-branch? Yes, OK and thanks for the work. Jerry Paul 2018-03-11 Paul Thomas PR fortran/84546 * trans-array.c (structure_alloc_comps): Make sure that the vptr is copied and that the unlimited polymorphic _len is used to compute the size to be allocated. * trans-expr.c (gfc_get_class_array_ref): If unlimited, use the unlimited polymorphic _len for the offset to the element. (gfc_copy_class_to_class): Set the new 'unlimited' argument. * trans.h : Add the boolean 'unlimited' to the prototype. 2018-03-11 Paul Thomas PR fortran/84546 * gfortran.dg/unlimited_polymorphic_29.f90 : New test.
[patch, fortran] Some more corrections to zero-size simplification
Hello world,
the attached patch fixes a few corner cases of a corner case in
simplification, i.e. empty arrays where array intrinsics can actually
have a non-empty array result.
Regression-tested. OK for trunk?
Regards
Thomas
2017-06-11 Thomas Koenig
PR fortran/66128
* simplify.c (simplify_transformation): Return default result for
empty array argument.
(gfc_simplify_all): Remove special-case handling for zerosize.
(gfc_simplify_any): Likewise.
(gfc_simplify_count): Likewise.
(gfc_simplify_iall): Likewise.
(gfc_simplify_iany): Likewise.
(gfc_simplify_iparity): Likewise.
(gfc_simplify_minval): Likewise.
(gfc_simplify_maxval): Likewise.
(gfc_simplify_norm2): Likewise.
(gfc_simplify_product): Likewise.
(gfc_simplify_sum): Likewise.
2017-06-11 Thomas Koenig
PR fortran/66128
* gfortran.dg/zero_sized_9.f90: New test.
! { dg-do run }
program main
implicit none
integer, parameter :: a(0,3) = 0
integer, parameter :: b(3,0) = -42
integer, parameter, dimension(3) :: a1 = minval(a,dim=1)
integer, parameter, dimension(0) :: a2 = minval(a,dim=2)
integer, parameter, dimension(0) :: b1 = minval(b,dim=1)
integer, parameter, dimension(3) :: b2 = minval(b,dim=2)
logical, parameter :: c(0,3) = .false.
logical, parameter :: d(3,0) = .false.
logical, parameter, dimension(3) :: tr = all(c,dim=1)
logical, parameter, dimension(3) :: fa = any(c,dim=1)
integer, parameter, dimension(3) :: ze = count(d,dim=2)
integer, parameter, dimension(3) :: ze2 = iany(b,dim=2)
integer, parameter, dimension(3) :: ze3 = iparity(a,dim=1)
real, parameter, dimension(0,3) :: r = 1.0
real, parameter, dimension(3) :: n2 = norm2(r,dim=1)
integer, parameter, dimension(3) :: one = product(b,dim=2)
integer, parameter, dimension(3) :: ze4 = sum(a,dim=1)
if (any(a1 /= huge(0))) stop 1
if (any(b2 /= huge(b2))) stop 2
if (any(.not.tr)) stop 3
if (any(fa)) stop 3
if (any(ze /= 0)) stop 4
if (any(ze2 /= 0)) stop 5
if (any(ze3 /= 0)) stop 6
if (any(n2 /= 0.0)) stop 7
if (any(one /= 1)) stop 8
if (any(ze4 /= 0)) stop 9
end program main
Index: simplify.c
===
--- simplify.c (Revision 258433)
+++ simplify.c (Arbeitskopie)
@@ -689,8 +689,11 @@ simplify_transformation (gfc_expr *array, gfc_expr
int init_val, transformational_op op)
{
gfc_expr *result;
+ bool size_zero;
- if (!is_constant_array_expr (array)
+ size_zero = gfc_is_size_zero_array (array);
+
+ if (!(is_constant_array_expr (array) || size_zero)
|| !gfc_is_constant_expr (dim))
return NULL;
@@ -703,6 +706,9 @@ simplify_transformation (gfc_expr *array, gfc_expr
array->ts.kind, &array->where);
init_result_expr (result, init_val, array);
+ if (size_zero)
+return result;
+
return !dim || array->rank == 1 ?
simplify_transformation_to_scalar (result, array, mask, op) :
simplify_transformation_to_array (result, array, dim, mask, op, NULL);
@@ -976,9 +982,6 @@ gfc_simplify_aint (gfc_expr *e, gfc_expr *k)
gfc_expr *
gfc_simplify_all (gfc_expr *mask, gfc_expr *dim)
{
- if (gfc_is_size_zero_array (mask))
-return gfc_get_logical_expr (mask->ts.kind, &mask->where, true);
-
return simplify_transformation (mask, dim, NULL, true, gfc_and);
}
@@ -1068,9 +1071,6 @@ gfc_simplify_and (gfc_expr *x, gfc_expr *y)
gfc_expr *
gfc_simplify_any (gfc_expr *mask, gfc_expr *dim)
{
- if (gfc_is_size_zero_array (mask))
-return gfc_get_logical_expr (mask->ts.kind, &mask->where, false);
-
return simplify_transformation (mask, dim, NULL, false, gfc_or);
}
@@ -1966,15 +1966,11 @@ gfc_expr *
gfc_simplify_count (gfc_expr *mask, gfc_expr *dim, gfc_expr *kind)
{
gfc_expr *result;
+ bool size_zero;
- if (gfc_is_size_zero_array (mask))
-{
- int k;
- k = kind ? mpz_get_si (kind->value.integer) : gfc_default_integer_kind;
- return gfc_get_int_expr (k, NULL, 0);
-}
+ size_zero = gfc_is_size_zero_array (mask);
- if (!is_constant_array_expr (mask)
+ if (!(is_constant_array_expr (mask) || size_zero)
|| !gfc_is_constant_expr (dim)
|| !gfc_is_constant_expr (kind))
return NULL;
@@ -1987,6 +1983,9 @@ gfc_simplify_count (gfc_expr *mask, gfc_expr *dim,
init_result_expr (result, 0, NULL);
+ if (size_zero)
+return result;
+
/* Passing MASK twice, once as data array, once as mask.
Whenever gfc_count is called, '1' is added to the result. */
return !dim || mask->rank == 1 ?
@@ -3265,9 +3264,6 @@ do_bit_and (gfc_expr *result, gfc_expr *e)
gfc_expr *
gfc_simplify_iall (gfc_expr *array, gfc_expr *dim, gfc_expr *mask)
{
- if (gfc_is_size_zero_array (array))
-return gfc_get_int_expr (array->ts.kind, NULL, -1);
-
return simplify_transformation (array, dim, mask, -1, do_bit_and);
}
@@ -3287,9 +3283,6 @@ do_bit_ior (gfc_expr *resu
Re: [PATCH] Fortran -- clean up KILL
On Sun, Mar 11, 2018 at 6:52 PM, Steve Kargl wrote: > The attach patch cleans up KILL to match its > documentation. In doing so, I have changed > the argument keywords to consistently use > pid and sig. If no one objects, I intend to > commit this tomorrow. > > 2018-03-11 Steven G. Kargl > > * check.c (gfc_check_kill): Check pid and sig are scalar. > (gfc_check_kill_sub): Restrict kind to 4 and 8. > * intrinsic.c (add_function): Sort keyword list. Add pid and sig > keywords for KILL. Remove redundant *back="back" in favor of the > original *bck="back". > (add_subroutines): Sort keyword list. Add pid and sig keywords > for KILL. > * intrinsic.texi: Fix documentation to consistently use pid and sig. > * iresolve.c (gfc_resolve_kill): Kind can only be 4 or 8. Choose the > correct function. > (gfc_resolve_rename_sub): Add comment. The patch per se looks fine, but while you're at it, it would be nice to get rid of all but one of the libgfortran entry points and do the typecasting etc. in the frontend instead.. -- Janne Blomqvist
Re: [patch, fortran] Some more corrections to zero-size simplification
On Sun, Mar 11, 2018 at 9:55 PM, Thomas Koenig wrote: > Hello world, > > the attached patch fixes a few corner cases of a corner case in > simplification, i.e. empty arrays where array intrinsics can actually > have a non-empty array result. > > Regression-tested. OK for trunk? Looks good, Ok. -- Janne Blomqvist
Re: [PATCH] Fortran -- clean up KILL
On Sun, Mar 11, 2018 at 10:16:01PM +0200, Janne Blomqvist wrote: > On Sun, Mar 11, 2018 at 6:52 PM, Steve Kargl > wrote: > > The attach patch cleans up KILL to match its > > documentation. In doing so, I have changed > > the argument keywords to consistently use > > pid and sig. If no one objects, I intend to > > commit this tomorrow. > > > > 2018-03-11 Steven G. Kargl > > > > * check.c (gfc_check_kill): Check pid and sig are scalar. > > (gfc_check_kill_sub): Restrict kind to 4 and 8. > > * intrinsic.c (add_function): Sort keyword list. Add pid and sig > > keywords for KILL. Remove redundant *back="back" in favor of the > > original *bck="back". > > (add_subroutines): Sort keyword list. Add pid and sig keywords > > for KILL. > > * intrinsic.texi: Fix documentation to consistently use pid and sig. > > * iresolve.c (gfc_resolve_kill): Kind can only be 4 or 8. Choose > > the > > correct function. > > (gfc_resolve_rename_sub): Add comment. > > The patch per se looks fine, but while you're at it, it would be nice > to get rid of all but one of the libgfortran entry points and do the > typecasting etc. in the frontend instead.. > Thanks. Note, the documentation specifically states that only INTEGER(4) and INTEGER(8) are supported, so there is only 2 entry points for the function and 4(?) for the subroutine version. nm shows T _gfortran_kill_i4 T _gfortran_kill_i4_sub T _gfortran_kill_i8 T _gfortran_kill_i8_sub T _gfortrani_kill_i4_sub T _gfortrani_kill_i8_sub I don't recall what the difference is between _gfortran_ and _gfortrani_. I suppose we could remove the restriction to INTEGER(4) and INTEGER(8), but I don't see any reason to do so. INTEGER(1) is too limited given that at least on FreeBSD the lower pid's correspond to system processes. Using 'ps ax' suggests that the first 1000 or so processes are from system start up. INTEGER(16) (if supported) seems to be overkill in that I doubt any OS uses a 64-bit pid_t. -- Steve
[PATCH] PR fortran/83939 -- Enforce F2018 C15100
The attach patch enforces F2018:C15100. Similar constraints are
present in older versions of the standard. The patch and testcase
are sufficiently explanatory. Regression tested on x86_64-*-freebsd.
OK to commit?
2018-03-11 Steven G. Kargl
PR fortran/83939
* resolve.c (resolve_fl_procedure): Enforce F2018:C15100.
2018-03-11 Steven G. Kargl
PR fortran/83939
* gfortran.dg/pr83939.f90
--
Steve
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 258433)
+++ gcc/fortran/resolve.c (working copy)
@@ -12451,6 +12451,19 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
}
}
+ /* F2018, C15100: "The result of an elemental function shall be scalar,
+ and shall not have the POINTER or ALLOCATABLE attribute." The scalar
+ pointer is tested and caught elsewhere. */
+ if (sym->attr.elemental && sym->result
+ && (sym->result->attr.allocatable || sym->result->attr.pointer))
+{
+ gfc_error ("Function result variable %qs at %L of elemental "
+ "function %qs shall not have an ALLOCATABLE or POINTER "
+ "attribute", sym->result->name,
+ &sym->result->declared_at, sym->name);
+ return false;
+}
+
if (sym->attr.is_bind_c && sym->attr.is_c_interop != 1)
{
gfc_formal_arglist *curr_arg;
Index: gcc/testsuite/gfortran.dg/pr83939.f90
===
--- gcc/testsuite/gfortran.dg/pr83939.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr83939.f90 (working copy)
@@ -0,0 +1,12 @@
+! { dg-do compile }
+elemental function f() result(s) ! { dg-error "shall not have an ALLOCATABLE or POINTER" }
+ allocatable s
+ allocate(s)
+ s = 3.5
+end function
+
+elemental function g() result(s) ! { dg-error "shall not have an ALLOCATABLE or POINTER" }
+ pointer s
+ allocate(s)
+ s = 3.5
+end function
Re: Patch ping (Re: [PATCH PR82965/PR83991]Fix invalid profile count in vectorization peeling)
On Fri, Mar 9, 2018 at 10:51 PM, Bin.Cheng wrote:
> On Fri, Mar 9, 2018 at 10:25 AM, Paul Hua wrote:
>> It's looks fixed
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965#c12 on mips64el.
> Hmm, is it fixed? or is it exposed now on mips64el? I read the latter
> from the comment.
It is fixed, Bootstrap and test passed on mips64el.
Thanks,
Paul Hua
> I think the issue is like explained, but haven't dug into when/why it
> is triggered in vect_peeling only for some targets.
> Honza asked couple questions about my patch offline, I will revisit
> the patch, see how to address
> his concern.
>
> Thanks,
> bin
>>
>> Thanks.
>>
>> On Mon, Feb 26, 2018 at 8:02 PM, Bin.Cheng wrote:
>>> Ping^2
>>>
>>> Thanks,
>>> bin
>>>
>>> On Mon, Feb 19, 2018 at 5:14 PM, Jakub Jelinek wrote:
Hi!
Honza, do you think you could have a look at this P1 fix?
Thanks.
On Wed, Jan 31, 2018 at 10:03:51AM +, Bin Cheng wrote:
> Hi,
> This patch fixes invalid profile count information in vectorization
> peeling.
> Current implementation is a bit confusing for me since it tries to compute
> an overall probability based on scaling probability and change of
> estimated
> niters. This patch does it in two steps. Firstly it does the scaling,
> then
> it adjusts to new estimated niters by simply adjusting loop's latch count
> information; scaling the loop's count information by the proportion
> new_estimated_niters/old_estimate_niters. Of course we have to adjust
> loop
> latch's count information back after scaling.
>
> Bootstrap and test on x86_64 and AArch64. gcc.dg/vect/pr79347.c is fixed
> for both PR82965 and PR83991. Is this OK?
>
> Thanks,
> bin
>
> 2018-01-30 Bin Cheng
>
> PR tree-optimization/82965
> PR tree-optimization/83991
> * cfgloopmanip.c (scale_loop_profile): Further scale loop's profile
> information if the loop was predicted to iterate too many times.
> diff --git a/gcc/cfgloopmanip.c b/gcc/cfgloopmanip.c
> index b9b76d8..1f560b8 100644
> --- a/gcc/cfgloopmanip.c
> +++ b/gcc/cfgloopmanip.c
> @@ -509,7 +509,7 @@ scale_loop_profile (struct loop *loop,
> profile_probability p,
> gcov_type iteration_bound)
> {
>gcov_type iterations = expected_loop_iterations_unbounded (loop);
> - edge e;
> + edge e, preheader_e;
>edge_iterator ei;
>
>if (dump_file && (dump_flags & TDF_DETAILS))
> @@ -521,77 +521,66 @@ scale_loop_profile (struct loop *loop,
> profile_probability p,
> (int)iteration_bound, (int)iterations);
> }
>
> + /* Scale the probabilities. */
> + scale_loop_frequencies (loop, p);
> +
>/* See if loop is predicted to iterate too many times. */
> - if (iteration_bound && iterations > 0
> - && p.apply (iterations) > iteration_bound)
> + if (iteration_bound == 0 || iterations <= 0
> + || p.apply (iterations) <= iteration_bound)
> +return;
> +
> + e = single_exit (loop);
> + preheader_e = loop_preheader_edge (loop);
> + profile_count count_in = preheader_e->count ();
> + if (e && preheader_e
> + && count_in > profile_count::zero ()
> + && loop->header->count.initialized_p ())
> {
> - /* Fixing loop profile for different trip count is not trivial;
> the exit
> - probabilities has to be updated to match and frequencies
> propagated down
> - to the loop body.
> -
> - We fully update only the simple case of loop with single exit that
> is
> - either from the latch or BB just before latch and leads from BB
> with
> - simple conditional jump. This is OK for use in vectorizer. */
> - e = single_exit (loop);
> - if (e)
> - {
> - edge other_e;
> - profile_count count_delta;
> + edge other_e;
> + profile_count count_delta;
>
> - FOR_EACH_EDGE (other_e, ei, e->src->succs)
> - if (!(other_e->flags & (EDGE_ABNORMAL | EDGE_FAKE))
> - && e != other_e)
> - break;
> + FOR_EACH_EDGE (other_e, ei, e->src->succs)
> + if (!(other_e->flags & (EDGE_ABNORMAL | EDGE_FAKE))
> + && e != other_e)
> + break;
>
> - /* Probability of exit must be 1/iterations. */
> - count_delta = e->count ();
> - e->probability = profile_probability::always ()
> + /* Probability of exit must be 1/iterations. */
> + count_delta = e->count ();
> + e->probability = profile_probability::always ()
> .apply_scale (1, iteration_bound);
> - other_e->probability = e->probability.invert ();
> - count_delta -= e
Re: [PATCH] PR fortran/83939 -- Enforce F2018 C15100
On 03/11/2018 01:48 PM, Steve Kargl wrote: The attach patch enforces F2018:C15100. Similar constraints are present in older versions of the standard. The patch and testcase are sufficiently explanatory. Regression tested on x86_64-*-freebsd. OK to commit? Looks OK Steve. Jerry 2018-03-11 Steven G. Kargl PR fortran/83939 * resolve.c (resolve_fl_procedure): Enforce F2018:C15100. 2018-03-11 Steven G. Kargl PR fortran/83939 * gfortran.dg/pr83939.f90
