[Bug fortran/87991] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87991 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.3 --- Comment #3 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch. Thanks for bug report.
[Bug fortran/87991] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87991 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Aug 14 04:38:29 2019 New Revision: 274413 URL: https://gcc.gnu.org/viewcvs?rev=274413=gcc=rev Log: 2019-08-13 Steven G. Kargl PR fortran/87991 * resolve.c (check_data_variable): data-stmt-object with pointer attribute requires a data-stmt-value with the target attribute. 2019-08-13 Steven G. Kargl PR fortran/87991 * gfortran.dg/pr87991.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr87991.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/resolve.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/87991] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87991 --- Comment #1 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Aug 14 04:22:31 2019 New Revision: 274412 URL: https://gcc.gnu.org/viewcvs?rev=274412=gcc=rev Log: 2019-08-13 Steven G. Kargl PR fortran/87991 * resolve.c (check_data_variable): data-stmt-object with pointer attribute requires a data-stmt-value with the target attribute. 2019-08-13 Steven G. Kargl PR fortran/87991 * gfortran.dg/pr87991.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr87991.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #38 from luoxhu at gcc dot gnu.org --- Author: luoxhu Date: Wed Aug 14 02:18:33 2019 New Revision: 274411 URL: https://gcc.gnu.org/viewcvs?rev=274411=gcc=rev Log: Enable math functions linking with static library for LTO In LTO mode, if static library and dynamic library contains same function and both libraries are passed as arguments, linker will link the function in dynamic library no matter the sequence. This patch will output LTO symbol node as UNDEF if BUILT_IN_NORMAL function FNDECL is a math function, then the function in static library will be linked first if its sequence is ahead of the dynamic library. gcc/ChangeLog 2019-08-14 Xiong Hu Luo PR lto/91287 * builtins.c (builtin_with_linkage_p): New function. * builtins.h (builtin_with_linkage_p): New function. * symtab.c (write_symbol): Remove redundant assert. * lto-streamer-out.c (symtab_node::output_to_lto_symbol_table_p): Remove FIXME and use builtin_with_linkage_p. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/builtins.h trunk/gcc/lto-streamer-out.c trunk/gcc/symtab.c
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095 Tom Honermann changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.2.1 Resolution|--- |FIXED Target Milestone|--- |9.3 Known to fail||9.1.0, 9.2.0 --- Comment #7 from Tom Honermann --- Fixed for 9.3 and 10.
[Bug driver/91130] [9 Regression] -MF clashes with -flto on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #46 from Tom Honermann --- Fixed for 9.3 and 10.
[Bug rtl-optimization/91347] [7/8/9/10 Regression] pointer_string in linux vsprintf.c is miscompiled when sibling calls are optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91347 --- Comment #3 from John David Anglin --- I see in dse.c: /* Get arguments passed to CALL_INSN. Return TRUE if successful. So far it only handles arguments passed in registers. */ static bool get_call_args (rtx call_insn, tree fn, rtx *args, int nargs)
[Bug rtl-optimization/91347] [7/8/9/10 Regression] pointer_string in linux vsprintf.c is miscompiled when sibling calls are optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91347 John David Anglin changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from John David Anglin --- Problem can easily be duplicated with x86 cross. Should sibcalls be disabled on 32-bit hppa if call requires arguments passed on stack?
[Bug fortran/90563] [8/9/10 Regression] Out of bounds error when compiling with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90563 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Thomas Koenig --- Fixed on all open branches. Thanks for the bug report!
[Bug fortran/90563] [8/9/10 Regression] Out of bounds error when compiling with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90563 --- Comment #6 from Thomas Koenig --- Author: tkoenig Date: Tue Aug 13 22:57:31 2019 New Revision: 274406 URL: https://gcc.gnu.org/viewcvs?rev=274406=gcc=rev Log: 2013-08-13 Thomas Koenig Backport from trunk PR fortran/90563 * frontend-passes.c (insert_index): Suppress errors while simplifying the resulting expression. 2013-08-13 Thomas Koenig Backport from trunk PR fortran/90563 * gfortran.dg/do_subscript_5.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/do_subscript_5.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/frontend-passes.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/68301] self-dependent reference member initialization not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68301 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #4) > This is a duplicate of bug 19808. There's a patch there that I believe > needs just a little more work. ok, closing it as such then *** This bug has been marked as a duplicate of bug 19808 ***
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 68301, which changed state. Bug 68301 Summary: self-dependent reference member initialization not diagnosed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68301 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 Eric Gallager changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #45 from Eric Gallager --- *** Bug 68301 has been marked as a duplicate of this bug. ***
[Bug fortran/90563] [8/9/10 Regression] Out of bounds error when compiling with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90563 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Tue Aug 13 22:25:32 2019 New Revision: 274405 URL: https://gcc.gnu.org/viewcvs?rev=274405=gcc=rev Log: 2013-08-13 Thomas Koenig Backport from trunk PR fortran/90563 * frontend-passes.c (insert_index): Suppress errors while simplifying the resulting expression. 2013-08-13 Thomas Koenig Backport from trunk PR fortran/90563 * gfortran.dg/do_subsript_5.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/do_subscript_5.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/frontend-passes.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug target/91421] [10 Regression] runtime error: load of value 2463, which is not a valid value for type 'built_in_function' since r274119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91421 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from rsandifo at gcc dot gnu.org --- Fixed on trunk (I hope).
[Bug target/91421] [10 Regression] runtime error: load of value 2463, which is not a valid value for type 'built_in_function' since r274119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91421 --- Comment #3 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Aug 13 21:35:10 2019 New Revision: 274403 URL: https://gcc.gnu.org/viewcvs?rev=274403=gcc=rev Log: Protect some checks of DECL_FUNCTION_CODE This patch protects various uses of DECL_FUNCTION_CODE that didn't obviously check for BUILT_IN_NORMAL first (either directly or in callers). They could therefore trigger for functions that either aren't built-ins or are a different kind of built-in. Also, the patch removes a redundant GIMPLE_CALL check from optimize_stdarg_builtin, since it gave the impression that the stmt was less well checked than it actually is. 2019-08-13 Richard Sandiford gcc/ PR middle-end/91421 * attribs.c (decl_attributes): Check the DECL_BUILT_IN_CLASS before the DECL_FUNCTION_CODE. * calls.c (maybe_warn_alloc_args_overflow): Use fndecl_built_in_p to check for a BUILT_IN_ALLOCA call. * ipa-cp.c (ipa_get_indirect_edge_target_1): Likewise for BUILT_IN_UNREACHABLE. Don't check for a FUNCTION_TYPE. * ipa-devirt.c (possible_polymorphic_call_target_p): Likewise. * ipa-prop.c (try_make_edge_direct_virtual_call): Likewise. * gimple-ssa-isolate-paths.c (is_addr_local): Check specifically for BUILT_IN_NORMAL functions. * trans-mem.c (expand_block_edges): Use gimple_call_builtin_p to test for BUILT_IN_TM_ABORT. * tree-ssa-ccp.c (optimize_stack_restore): Use fndecl_built_in_p to check for a BUILT_IN_STACK_RESTORE call. (optimize_stdarg_builtin): Remove redundant check for GIMPLE_CALL. * tree-ssa-threadedge.c (record_temporary_equivalences_from_stmts_at_dest): Check for a BUILT_IN_NORMAL decl before checking its DECL_FUNCTION_CODE. * tree-vect-patterns.c (vect_recog_pow_pattern): Use a positive test for a BUILT_IN_NORMAL call instead of a negative test for an internal function call. gcc/c/ PR middle-end/91421 * c-decl.c (header_for_builtin_fn): Take a FUNCTION_DECL instead of a built_in_function. (diagnose_mismatched_decls, implicitly_declare): Update accordingly. Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/calls.c trunk/gcc/gimple-ssa-isolate-paths.c trunk/gcc/ipa-cp.c trunk/gcc/ipa-devirt.c trunk/gcc/ipa-prop.c trunk/gcc/trans-mem.c trunk/gcc/tree-ssa-ccp.c trunk/gcc/tree-ssa-threadedge.c trunk/gcc/tree-vect-patterns.c
[Bug target/91421] [10 Regression] runtime error: load of value 2463, which is not a valid value for type 'built_in_function' since r274119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91421 --- Comment #4 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Aug 13 21:35:20 2019 New Revision: 274404 URL: https://gcc.gnu.org/viewcvs?rev=274404=gcc=rev Log: Use checking forms of DECL_FUNCTION_CODE (PR 91421) We were shoe-horning all built-in enumerations (including frontend and target-specific ones) into a field of type built_in_function. This was accessed as either an lvalue or an rvalue using DECL_FUNCTION_CODE. The obvious danger with this (as was noted by several ??? comments) is that the ranges have nothing to do with each other, and targets can easily have more built-in functions than generic code. But my patch to make the field bigger was the straw that finally made the problem visible. This patch therefore: - replaces the field with a plain unsigned int - turns DECL_FUNCTION_CODE into an rvalue-only accessor that checks that the function really is BUILT_IN_NORMAL - adds corresponding DECL_MD_FUNCTION_CODE and DECL_FE_FUNCTION_CODE accessors for BUILT_IN_MD and BUILT_IN_FRONTEND respectively - adds DECL_UNCHECKED_FUNCTION_CODE for places that need to access the underlying field (should be low-level code only) - adds new helpers for setting the built-in class and function code - makes DECL_BUILT_IN_CLASS an rvalue-only accessor too, since all assignments should go through the new helpers 2019-08-13 Richard Sandiford gcc/ PR middle-end/91421 * tree-core.h (function_decl::function_code): Change type to unsigned int. * tree.h (DECL_FUNCTION_CODE): Rename old definition to... (DECL_UNCHECKED_FUNCTION_CODE): ...this. (DECL_BUILT_IN_CLASS): Make an rvalue macro only. (DECL_FUNCTION_CODE): New function. Assert that the built-in class is BUILT_IN_NORMAL. (DECL_MD_FUNCTION_CODE, DECL_FE_FUNCTION_CODE): New functions. (set_decl_built_in_function, copy_decl_built_in_function): Likewise. (fndecl_built_in_p): Change the type of the "name" argument to unsigned int. * builtins.c (expand_builtin): Move DECL_FUNCTION_CODE use after check for DECL_BUILT_IN_CLASS. * cgraphclones.c (build_function_decl_skip_args): Use set_decl_built_in_function. * ipa-param-manipulation.c (ipa_modify_formal_parameters): Likewise. * ipa-split.c (split_function): Likewise. * langhooks.c (add_builtin_function_common): Likewise. * omp-simd-clone.c (simd_clone_create): Likewise. * tree-streamer-in.c (unpack_ts_function_decl_value_fields): Likewise. * config/darwin.c (darwin_init_cfstring_builtins): Likewise. (darwin_fold_builtin): Use DECL_MD_FUNCTION_CODE instead of DECL_FUNCTION_CODE. * fold-const.c (operand_equal_p): Compare DECL_UNCHECKED_FUNCTION_CODE instead of DECL_FUNCTION_CODE. * lto-streamer-out.c (hash_tree): Use DECL_UNCHECKED_FUNCTION_CODE instead of DECL_FUNCTION_CODE. * tree-streamer-out.c (pack_ts_function_decl_value_fields): Likewise. * print-tree.c (print_node): Use DECL_MD_FUNCTION_CODE when printing DECL_BUILT_IN_MD. Handle DECL_BUILT_IN_FRONTEND. * config/aarch64/aarch64-builtins.c (aarch64_expand_builtin) (aarch64_fold_builtin, aarch64_gimple_fold_builtin): Use DECL_MD_FUNCTION_CODE instead of DECL_FUNCTION_CODE. * config/aarch64/aarch64.c (aarch64_builtin_reciprocal): Likewise. * config/alpha/alpha.c (alpha_expand_builtin, alpha_fold_builtin): (alpha_gimple_fold_builtin): Likewise. * config/arc/arc.c (arc_expand_builtin): Likewise. * config/arm/arm-builtins.c (arm_expand_builtin): Likewise. * config/avr/avr-c.c (avr_resolve_overloaded_builtin): Likewise. * config/avr/avr.c (avr_expand_builtin, avr_fold_builtin): Likewise. * config/bfin/bfin.c (bfin_expand_builtin): Likewise. * config/c6x/c6x.c (c6x_expand_builtin): Likewise. * config/frv/frv.c (frv_expand_builtin): Likewise. * config/gcn/gcn.c (gcn_expand_builtin_1): Likewise. (gcn_expand_builtin): Likewise. * config/i386/i386-builtins.c (ix86_builtin_reciprocal): Likewise. (fold_builtin_cpu): Likewise. * config/i386/i386-expand.c (ix86_expand_builtin): Likewise. * config/i386/i386.c (ix86_fold_builtin): Likewise. (ix86_gimple_fold_builtin): Likewise. * config/ia64/ia64.c (ia64_fold_builtin): Likewise. (ia64_expand_builtin): Likewise. * config/iq2000/iq2000.c (iq2000_expand_builtin): Likewise. * config/mips/mips.c (mips_expand_builtin): Likewise. * config/msp430/msp430.c (msp430_expand_builtin): Likewise. * config/nds32/nds32-intrinsic.c (nds32_expand_builtin_impl): Likewise. * config/nios2/nios2.c (nios2_expand_builtin): Likewise. * config/nvptx/nvptx.c (nvptx_expand_builtin): Likewise. *
[Bug fortran/88072] gfortran crashes with an internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88072 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.3 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch. Thanks for bug report.
[Bug fortran/88072] gfortran crashes with an internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88072 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Aug 13 20:38:01 2019 New Revision: 274401 URL: https://gcc.gnu.org/viewcvs?rev=274401=gcc=rev Log: 2019-08-13 Steven G. Kargl PR fortran/88072 * misc.c (gfc_typename): Do not point to something that ought not to be pointed at. 2019-08-13 Steven G. Kargl PR fortran/88072 * gfortran.dg/pr88072.f90: New test. * gfortran.dg/unlimited_polymorphic_28.f90: Fix error message. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr88072.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/misc.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_28.f90
[Bug fortran/88072] gfortran crashes with an internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88072 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Aug 13 20:13:59 2019 New Revision: 274400 URL: https://gcc.gnu.org/viewcvs?rev=274400=gcc=rev Log: 2019-08-13 Steven G. Kargl PR fortran/88072 * gfortran.dg/unlimited_polymorphic_28.f90: Fix error message. Left out of previous commit! Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_28.f90
[Bug fortran/88072] gfortran crashes with an internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88072 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Aug 13 20:10:25 2019 New Revision: 274399 URL: https://gcc.gnu.org/viewcvs?rev=274399=gcc=rev Log: 2019-08-13 Steven G. Kargl PR fortran/88072 * misc.c (gfc_typename): Do not point to something that ought not to be pointed at. 2019-08-13 Steven G. Kargl PR fortran/88072 * gfortran.dg/pr88072.f90: New test. * gfortran.dg/unlimited_polymorphic_28.f90: Fix error message. Added: trunk/gcc/testsuite/gfortran.dg/pr88072.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/misc.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 90561, which changed state. Bug 90561 Summary: [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90561 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/90561] [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90561 --- Comment #11 from Thomas Koenig --- Author: tkoenig Date: Tue Aug 13 20:01:43 2019 New Revision: 274398 URL: https://gcc.gnu.org/viewcvs?rev=274398=gcc=rev Log: 2019-08-13 Thomas Koenig Backport from trunk PR fortran/90561 * trans.h (gfc_evaluate_now_function_scope): New function. * trans.c (gfc_evaluate_now_function_scope): New function. * trans-expr.c (gfc_trans_assignment): Use it. 2019-08-13 Thomas Koenig Backport from trunk PR fortran/90561 * gfortran.dg/deferred_character_34.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/deferred_character_34.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/trans-expr.c branches/gcc-9-branch/gcc/fortran/trans.c branches/gcc-9-branch/gcc/fortran/trans.h branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/90561] [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90561 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Thomas Koenig --- Fixed on all affected branches, closing.
[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 --- Comment #12 from Jonathan Wakely --- Yes, sorry I missed the deadline for 9.2.
[Bug fortran/89647] Host associated procedure unable to be used as binding target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89647 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.3 --- Comment #6 from kargl at gcc dot gnu.org --- Committed to trunk and 9-branch. Thanks for bug report.
[Bug fortran/89647] Host associated procedure unable to be used as binding target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89647 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Aug 13 18:49:00 2019 New Revision: 274395 URL: https://gcc.gnu.org/viewcvs?rev=274395=gcc=rev Log: 2019-08-13 Steven G. Kargl PR fortran/89647 resolve.c (resolve_typebound_procedure): Allow host associated procedure to be a binding target. While here, wrap long line. 2019-08-13 Steven G. Kargl PR fortran/89647 * gfortran.dg/pr89647.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr89647.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/resolve.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/90563] [8/9/10 Regression] Out of bounds error when compiling with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90563 --- Comment #4 from Thomas Koenig --- Author: tkoenig Date: Tue Aug 13 18:49:02 2019 New Revision: 274396 URL: https://gcc.gnu.org/viewcvs?rev=274396=gcc=rev Log: 2013-08-13 Thomas Koenig PR fortran/90563 * gfortran.dg/do_subsript_5.f90: Correct test. Modified: trunk/gcc/testsuite/gfortran.dg/do_subscript_5.f90
[Bug fortran/90563] [8/9/10 Regression] Out of bounds error when compiling with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90563 --- Comment #3 from Thomas Koenig --- Author: tkoenig Date: Tue Aug 13 18:43:00 2019 New Revision: 274394 URL: https://gcc.gnu.org/viewcvs?rev=274394=gcc=rev Log: 2013-08-13 Thomas Koenig PR fortran/90563 * frontend-passes.c (insert_index): Suppress errors while simplifying the resulting expression. 2013-08-13 Thomas Koenig PR fortran/90563 * gfortran.dg/do_subsript_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/do_subscript_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/89647] Host associated procedure unable to be used as binding target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89647 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Aug 13 18:35:33 2019 New Revision: 274393 URL: https://gcc.gnu.org/viewcvs?rev=274393=gcc=rev Log: 2019-08-13 Steven G. Kargl PR fortran/89647 resolve.c (resolve_typebound_procedure): Allow host associated procedure to be a binding target. While here, wrap long line. 2019-08-13 Steven G. Kargl PR fortran/89647 * gfortran.dg/pr89647.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr89647.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87993] ICE in gfc_constructor_first, at fortran/constructor.c:234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87993 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.3 --- Comment #5 from kargl at gcc dot gnu.org --- Committed to trunk and 9-branch. Thanks for bug report.
[Bug fortran/87994] ICE in match_data_constant, at fortran/decl.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87994 Bug 87994 depends on bug 87993, which changed state. Bug 87993 Summary: ICE in gfc_constructor_first, at fortran/constructor.c:234 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87993 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/87993] ICE in gfc_constructor_first, at fortran/constructor.c:234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87993 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Aug 13 18:27:05 2019 New Revision: 274390 URL: https://gcc.gnu.org/viewcvs?rev=274390=gcc=rev Log: 2019-08-13 Steven G. Kargl PR fortran/87993 * expr.c (gfc_simplify_expr): Simplifcation of an array with a kind type inquiry suffix yields a constant expression. 2019-08-13 Steven G. Kargl PR fortran/87993 * gfortran.dg/pr87993.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr87993.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/expr.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/87993] ICE in gfc_constructor_first, at fortran/constructor.c:234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87993 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Aug 13 18:06:08 2019 New Revision: 274388 URL: https://gcc.gnu.org/viewcvs?rev=274388=gcc=rev Log: 2019-08-13 Steven G. Kargl PR fortran/87993 * expr.c (gfc_simplify_expr): Simplifcation of an array with a kind type inquiry suffix yields a constant expression. 2019-08-13 Steven G. Kargl PR fortran/87993 * gfortran.dg/pr87993.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr87993.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/91438] [10 Regression] Profiledbootstrap broken on i586 in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91438 --- Comment #4 from H.J. Lu --- Is this related to PR 91404?
[Bug other/91396] Link error when I use -fvtable-verify=std and -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396 --- Comment #5 from ctice at gcc dot gnu.org --- Author: ctice Date: Tue Aug 13 16:11:20 2019 New Revision: 274386 URL: https://gcc.gnu.org/viewcvs?rev=274386=gcc=rev Log: Fix PR other/91396 static linke error with -fvtable-verify Fix a bug where linking with -fvtable-verify and -static causes the linker to complain about multiple definitions of things in the vtv_end*.o files (once from the .o file and once from libvtv.a). 2019-08-12 Caroline Tice PR other/91396 * config/gnu-user.h (GNU_USER_TARGET_ENDFILE_SPEC): Only add the vtv_end.o or vtv_end_preinit.o files if !static. Modified: trunk/gcc/ChangeLog trunk/gcc/config/gnu-user.h
[Bug c++/68301] self-dependent reference member initialization not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68301 --- Comment #4 from Manuel López-Ibáñez --- This is a duplicate of bug 19808. There's a patch there that I believe needs just a little more work.
[Bug c/80619] bad fix-it hint for GCC %lu directive with int argument: %wu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80619 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #7 from Martin Sebor --- Fixed by r274385.
[Bug c/80619] bad fix-it hint for GCC %lu directive with int argument: %wu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80619 --- Comment #6 from Martin Sebor --- Author: msebor Date: Tue Aug 13 15:55:40 2019 New Revision: 274385 URL: https://gcc.gnu.org/viewcvs?rev=274385=gcc=rev Log: PR c/80619 - bad fix-it hint for GCC %lu directive with int argument: %wu gcc/c-family/ChangeLog: PR c/80619 * c-format.c (printf_length_specs): Set FMT_LEN_w for "w". (asm_fprintf_length_spec): Same. * c-format.h (format_lengths): Add FMT_LEN_w. gcc/testsuite/ChangeLog: PR c/80619 * gcc.dg/format/pr80619.c: New test. Added: trunk/gcc/testsuite/gcc.dg/format/pr80619.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-format.c trunk/gcc/c-family/c-format.h trunk/gcc/testsuite/ChangeLog
[Bug c++/91434] gcc optimization behaviour is inconsistent with -O2 with 4.1.2 and 4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91434
Rajabharathi s changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #3 from Rajabharathi s ---
(In reply to Jonathan Wakely from comment #2)
> This code has undefined behaviour:
>
> int main()
> {
> FSPI pi;
> FSPG* pg = new FSPG();
> new (_a) FSPGI(pg);
> pi.m_a.~FSPGI();
> return 0;
> }
>
> pi.m_a is part of an object on the stack, so its destructor will run
> automatically. If you invoke it explicitly as pi.m_a.~FSPGI() then you cause
> the same object to be destroyed twice. This is undefined. You need to fix
> your code.
Thanks for your reply. I understand this.
But since m_a is member variable of other object FSPI, this memory exists in
stack until its destruction.
m_g is set to NULL in destructor part when called for first time.
So second time, this if condition should be false.
If -fno-tree-dse option is used, then this if condition is false and works fine
in 4.9.4.
~FSPGI()
{cout << "FSPGI dtor\n";
if(NULL != m_g)
{
cout << "m_g is not NULL\n";
delete m_g;
m_g = NULL;
}
}
class FSPI
{
public:
FSPI()
{
cout << "FSPI ctor\n";
}
~FSPI()
{
cout << "FSPI dtor \n";
}
FSPGI m_a;
};
[Bug fortran/80931] ICE on move_alloc in gimplify_expr, at gimplify.c:11335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80931 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from Thomas Koenig --- Yep, it's fixed.
[Bug c/91440] New: Precompiled headers regression in 9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91440
Bug ID: 91440
Summary: Precompiled headers regression in 9.2
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rcopley at gmail dot com
Target Milestone: ---
In some circumstances, builds using precompiled headers which worked with GCC
9.1 no longer work with GCC 9.2.
Complete test case (as a bash script):
>precompiled.h echo "void f();"
>main.c echo "void f() {}"
mkdir some-subdir
gcc -Winvalid-pch -pedantic -c -o some-subdir/precompiled.h.gch precompiled.h
gcc -Winvalid-pch -pedantic -c -include some-subdir/precompiled.h -o main.o
main.c
# END OF SCRIPT
Expected behaviour (as seen with GCC 9.1) is to succeed, with no output.
Actual behaviour with GCC 9.2 is to fail, with output:
cc1.exe: warning: ./.obj/precompiled.h.gch: had text segment at different
address
cc1.exe: error: one or more PCH files were found, but they were invalid
cc1.exe: fatal error: .obj/precompiled.h: No such file or directory
(The errors don't happen if you remove all occurrences of " -pedantic" and/or
"some-subdir/" from the recipe.)
Output of gcc -v (in 9.2):
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-9.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --enable-plugin --with-libiconv --with-system-zlib
--with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
--with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 9.2.0 (Rev1, Built by MSYS2 project)
[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 --- Comment #11 from Viktor Ostashevskyi --- Cool! Thanks a lot, sad that this doesn't make to 9.2.
[Bug c++/90473] gcc does not call function in comma operator for default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90473 --- Comment #6 from Marek Polacek --- Fixed on trunk, will backport to 9.3.
[Bug fortran/90561] [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90561 --- Comment #10 from Thomas Koenig --- Author: tkoenig Date: Tue Aug 13 15:08:10 2019 New Revision: 274383 URL: https://gcc.gnu.org/viewcvs?rev=274383=gcc=rev Log: 2019-08-13 Thomas Koenig PR fortran/90561 * trans.h (gfc_evaluate_now_function_scope): New function. * trans.c (gfc_evaluate_now_function_scope): New function. * trans-expr.c (gfc_trans_assignment): Use it. 2019-08-13 Thomas Koenig PR fortran/90561 * gfortran.dg/deferred_character_34.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_34.f90 Modified: trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h
[Bug c++/90473] gcc does not call function in comma operator for default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90473 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Tue Aug 13 15:05:48 2019 New Revision: 274382 URL: https://gcc.gnu.org/viewcvs?rev=274382=gcc=rev Log: PR c++/90473 - wrong code with nullptr in default argument. * call.c (null_ptr_cst_p): Update quote from the standard. * decl.c (check_default_argument): Don't return nullptr when the arg has side-effects. * g++.dg/cpp0x/nullptr42.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nullptr42.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/91431] Using class template for containers and iterators rather than defining template only for iterators caused a trouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91431 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- --- Comment #4 from Jonathan Wakely --- Please don't close the bug: GCC should not crash even for invalid code.
[Bug fortran/91426] Different colors for errors with multiple locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91426
--- Comment #1 from David Malcolm ---
The diagnostic is coming from
gfc_define_st_label in gcc/fortran/symbol.c:2711
2711gfc_error ("Duplicate statement label %d at %L and %L", labelno,
2712 >where, label_locus);
This ultimately leads to a call to diagnostic_show_locus from
gfc_diagnostic_starter, with a rich_location containing two locations.
A rich_location can contain an arbitrary number of location_t values. The
first is considered the "primary" location, subsequent ones are considered
"secondary" locations.
diagnostic_show_locus currently colorizes locations by using the
"diagnostic_kind" color for the primary location_t within the rich_location,
and then alternating between two other colors for any secondary location_t
values within the rich_location ("range1" and "range2" within GCC_COLORS).
It's not clear to me what ought to happen here for Fortran.
Currently the fortran/error.c seems to be set up to support at most 2 locations
per diagnostic (via the %L formatting code).
Some possible ways forward:
- generalize the fortran diagnostics-handling code to support more than 2
locations (though would any diagnostics use this?)
- special-case fortran's colorization so it uses the same color for both
locations
- something else I haven't thought of
[Bug bootstrap/91438] [10 Regression] Profiledbootstrap broken on i586 in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91438 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- r273856 is fine, so probably started with my r273857.
[Bug c/66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 --- Comment #21 from Jonathan Wakely --- Clang is changing __has_builtin so it recognizes all function-like built-ins, not just the ones starting with "__builtin_". See https://reviews.llvm.org/D66100 This means __has_builtin yields true for all of __is_aggregate, __builtin_launder and __builtin_offsetof.
[Bug c++/91431] Using class template for containers and iterators rather than defining template only for iterators caused a trouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91431 Hyundeok Park changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Hyundeok Park --- Inherently impossible to deduce container type from iterators.
[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jonathan Wakely --- This is fixed now. I'll add something to the release notes about the status in the 9.1 and 9.2 releases.
[Bug sanitizer/61071] Compiling with AddressSanitizer with 4.9 breaks printng some variables in gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61071 Krzysztof Kundzicz changed: What|Removed |Added Attachment #32739|0 |1 is obsolete|| --- Comment #6 from Krzysztof Kundzicz --- Created attachment 46707 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46707=edit updated testcase With gcc 9.1 (?) size of the t array triggering the bug changed to 63B.
[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 --- Comment #9 from Jonathan Wakely --- Author: redi Date: Tue Aug 13 13:14:45 2019 New Revision: 274379 URL: https://gcc.gnu.org/viewcvs?rev=274379=gcc=rev Log: PR libstdc++/90361 add missing macro definition The src/c++17/string-inst.cc file needs to override the default string ABI so that it still contains the expected symbols even when the library is configured with --with-default-libstdcxx-abi=gcc4-compatible. Backport from mainline 2019-08-12 Jonathan Wakely PR libstdc++/90361 * src/c++17/string-inst.cc: Use _GLIBCXX_USE_CXX11_ABI=1 by default. Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/src/c++17/string-inst.cc
[Bug bootstrap/91438] [10 Regression] Profiledbootstrap broken on i586 in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91438 --- Comment #2 from Martin Liška --- (In reply to Martin Liška from comment #1) > Probably r274238 is fine. I was wrong, the revision is also affected.
[Bug sanitizer/61071] Compiling with AddressSanitizer with 4.9 breaks printng some variables in gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61071 --- Comment #5 from Krzysztof Kundzicz --- (In reply to Johannes Altmanninger from comment #4) > I can't reproduce this on Arch Linux, perhaps it is fixed by now? > > Linux 5.2.2 > gcc 9.1.0 > gdb 8.3 > glibc 2.29 > binutils 2.32 Just increase the `t` array size to 63 and and it's broken again. Same setup, newer kernel.
[Bug tree-optimization/91435] Better induction variable for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91435 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-13 Blocks||53947 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. Note that IVOPTs does not even look at vector IVs and unfortunately the vectorizer itself doesn't try to be clever in any way here. Indeed there's a lot to be desired for the vector code we generate for this testcase... Even when not vectorized unrolling the loop to eliminate the conditional would be profitable I guess (no convenient pass to do this though). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug sanitizer/91439] Wrong debug information with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91439
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-08-13
Ever confirmed|0 |1
Known to fail||7.4.0, 9.2.0
--- Comment #1 from Martin Liška ---
Confirmed, I see a strange value for GCC 7 and GCC 9:
marxin@marxinbox:~/Programming/testcases> gcc-7 pr91439.c -g -fsanitize=address
&& gdb -batch ./a.out -ex 'b main' -ex 'run'
Breakpoint 1 at 0x401141: file pr91439.c, line 4.
Missing separate debuginfo for /usr/lib64/libasan.so.4
Try: zypper install -C
"debuginfo(build-id)=b3ac3f35d7015cbcfad7f1c3b963e359c4d2a450"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /usr/lib64/libstdc++.so.6
Try: zypper install -C
"debuginfo(build-id)=9fa6bebc5c9e4c2924c52dda95476b810da94c0e"
Missing separate debuginfo for /lib64/libgcc_s.so.1
Try: zypper install -C
"debuginfo(build-id)=65ec11084e680032661897cbee7871aa5abf08e9"
Breakpoint 1, main (argc=1, argv=0x7fffdd38) at pr91439.c:4
4 f();
marxin@marxinbox:~/Programming/testcases> gcc-8 pr91439.c -g -fsanitize=address
&& gdb -batch ./a.out -ex 'b main' -ex 'run'
Breakpoint 1 at 0x4011bf: file pr91439.c, line 3.
Missing separate debuginfo for /usr/lib64/libasan.so.5
Try: zypper install -C
"debuginfo(build-id)=8b1a1889c7398f0594ecb4d2288419a17e2a9167"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /usr/lib64/libstdc++.so.6
Try: zypper install -C
"debuginfo(build-id)=9fa6bebc5c9e4c2924c52dda95476b810da94c0e"
^[[AMissing separate debuginfo for /lib64/libgcc_s.so.1
Try: zypper install -C
"debuginfo(build-id)=65ec11084e680032661897cbee7871aa5abf08e9"
Breakpoint 1, main (argc=0, argv=0x7fffdd38) at pr91439.c:3
3 int main(int argc, char **argv) {
marxin@marxinbox:~/Programming/testcases> gcc-9 pr91439.c -g -fsanitize=address
&& gdb -batch ./a.out -ex 'b main' -ex 'run'
Breakpoint 1 at 0x4011ad: file pr91439.c, line 3.
Missing separate debuginfo for /usr/lib64/libasan.so.5
Try: zypper install -C
"debuginfo(build-id)=8b1a1889c7398f0594ecb4d2288419a17e2a9167"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /usr/lib64/libstdc++.so.6
Try: zypper install -C
"debuginfo(build-id)=9fa6bebc5c9e4c2924c52dda95476b810da94c0e"
Missing separate debuginfo for /lib64/libgcc_s.so.1
Try: zypper install -C
"debuginfo(build-id)=65ec11084e680032661897cbee7871aa5abf08e9"
Breakpoint 1, main (argc=2, argv=0x7fffdd38) at pr91439.c:3
3 int main(int argc, char **argv) {
[Bug tree-optimization/91419] [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419 --- Comment #4 from Hans-Peter Nilsson --- (In reply to rguent...@suse.de from comment #3) > OK, so all testcases in this PR use 'int' which means disabling > for !natural_alignment_32 would be enough (unless 'int' is not 32bit ;)) I'd assume alert target maintainers will notice and take action. > I agree that using target lists is imperfect (but it has the lowest > testsuite time overhead). JFTR, I'd say lower maintenance time beats lower test-run time ;) and the attribute is suitable for caching. But now that it's there I'd probably also just pile-on. > I'll amend the testcases with xfails for > !natural_alignment_32. Can you amend the target lists appropriately? > I guess cris-*-* (not only cris-*-elf) would need to be added. It seems you already did this in your patch, that's right, thanks!
[Bug sanitizer/91439] New: Wrong debug information with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91439 Bug ID: 91439 Summary: Wrong debug information with -fsanitize=address Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: aclopte at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Similarly to an issue with Clang https://bugs.llvm.org/show_bug.cgi?id=26673, gcc with Address Sanitizer on Arch Linux produces wrong debug information in certain cases. It seems to happen when a function takes as parameter the address of a local variable. Then the debug information describing the location of that variable in the caller is off. gcc version 10.0.0 20190812 (experimental) (GCC) git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@274308 The same issue occurs with gcc 9.1.0. Linux 5.2.2 gdb 8.3 glibc 2.29 binutils 2.32 # I built with default options: mkdir build && cd build && ../configure && make # This is a minimal test case: cat > x.c <
[Bug fortran/90561] [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90561
--- Comment #9 from Thomas Koenig ---
... and this
Index: trans-expr.c
===
--- trans-expr.c(Revision 274370)
+++ trans-expr.c(Arbeitskopie)
@@ -10796,7 +10796,13 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr
if (expr1->ts.deferred
&& gfc_expr_attr (expr1).allocatable
&& gfc_check_dependency (expr1, expr2, true))
- rse.string_length = gfc_evaluate_now (rse.string_length, );
+ {
+ /* Add the variable to function scope. */
+ tree str_len;
+ str_len = gfc_create_var_np (TREE_TYPE (rse.string_length), NULL);
+ gfc_add_decl_to_function (str_len);
+ gfc_add_modify (, str_len, rse.string_length);
+ }
string_length = rse.string_length;
}
else
causes a regression in dependency_52.f90.
[Bug fortran/90561] [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90561
--- Comment #8 from Thomas Koenig ---
This
Index: trans-expr.c
===
--- trans-expr.c(Revision 274370)
+++ trans-expr.c(Arbeitskopie)
@@ -10796,7 +10796,13 @@
if (expr1->ts.deferred
&& gfc_expr_attr (expr1).allocatable
&& gfc_check_dependency (expr1, expr2, true))
- rse.string_length = gfc_evaluate_now (rse.string_length, );
+ {
+ /* Add the variable to function scope. */
+ tree string_length;
+ string_length = gfc_create_var_np (TREE_TYPE (rse.string_length),
NULL);
+ gfc_add_decl_to_function (string_length);
+ gfc_add_modify (, rse.string_length, string_length);
+ }
string_length = rse.string_length;
}
else
gets rid of the ICE, but introduces new ones (and the run-time behavior
of the code is wrong, if one adds print *,z at the end of z1.f90).
[Bug c++/91429] Conditional explicit not respected with out-of-line definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91429 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-13 Ever confirmed|0 |1
[Bug c++/91431] Using class template for containers and iterators rather than defining template only for iterators caused a trouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91431
Jonathan Wakely changed:
What|Removed |Added
Keywords|needs-reduction |ice-on-invalid-code
--- Comment #2 from Jonathan Wakely ---
Reduced:
template class Blob {
public:
template<
template class Alloc,
template> class Container,
class Iter = typename Container::iterator
> Blob(Iter b, Iter e) {
}
private:
};
int main()
{
int i = 0;
Blob i_blob(, );
}
The code is invalid, you can't deduce the container and allocator from the
iterator type like that.
[Bug sanitizer/61071] Compiling with AddressSanitizer with 4.9 breaks printng some variables in gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61071 Johannes Altmanninger changed: What|Removed |Added CC||aclopte at gmail dot com --- Comment #4 from Johannes Altmanninger --- I can't reproduce this on Arch Linux, perhaps it is fixed by now? Linux 5.2.2 gcc 9.1.0 gdb 8.3 glibc 2.29 binutils 2.32
[Bug c++/91434] gcc optimization behaviour is inconsistent with -O2 with 4.1.2 and 4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91434
--- Comment #2 from Jonathan Wakely ---
This code has undefined behaviour:
int main()
{
FSPI pi;
FSPG* pg = new FSPG();
new (_a) FSPGI(pg);
pi.m_a.~FSPGI();
return 0;
}
pi.m_a is part of an object on the stack, so its destructor will run
automatically. If you invoke it explicitly as pi.m_a.~FSPGI() then you cause
the same object to be destroyed twice. This is undefined. You need to fix your
code.
[Bug bootstrap/91438] [10 Regression] Profiledbootstrap broken on i586 in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91438 Martin Liška changed: What|Removed |Added Keywords||needs-bisection --- Comment #1 from Martin Liška --- Probably r274238 is fine.
[Bug c++/91436] Confusing suggestion to include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91436
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-08-13
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
This is a trivial bug in the map of names:
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -5619,7 +5619,7 @@ get_std_name_hint (const char *name)
{"multimap", "", cxx98},
/* . */
{"make_shared", "", cxx11},
-{"make_unique", "", cxx11},
+{"make_unique", "", cxx14},
{"shared_ptr", "", cxx11},
{"unique_ptr", "", cxx11},
{"weak_ptr", "", cxx11},
[Bug c++/91434] gcc optimization behaviour is inconsistent with -O2 with 4.1.2 and 4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91434 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Martin Liška --- If I see correctly, you're attempting to do a double-free: $ g++ pr91434.cpp -fsanitize=address -g -O2 && ./a.out FSPGI ctor1 FSPI ctor FSPG ctor FSPGI ctor FSPGI dtor m_g is not NULL FSPG dtor FSPI dtor FSPGI dtor m_g is not NULL FSPG dtor = ==11968==ERROR: AddressSanitizer: attempting double-free on 0x60200010 in thread T0: #0 0x7f08b2c80595 in operator delete(void*, unsigned long) (/usr/lib64/libasan.so.5+0x10d595) #1 0x4012cb in FSPI::~FSPI() /home/marxin/Programming/testcases/pr91434.cpp:45 #2 0x4012cb in main /home/marxin/Programming/testcases/pr91434.cpp:54 #3 0x7f08b2694bca in __libc_start_main ../csu/libc-start.c:308 #4 0x4013e9 in _start (/home/marxin/Programming/testcases/a.out+0x4013e9) 0x60200010 is located 0 bytes inside of 1-byte region [0x60200010,0x60200011) freed by thread T0 here: #0 0x7f08b2c80595 in operator delete(void*, unsigned long) (/usr/lib64/libasan.so.5+0x10d595) #1 0x4012b4 in main /home/marxin/Programming/testcases/pr91434.cpp:57 previously allocated by thread T0 here: #0 0x7f08b2c7f10f in operator new(unsigned long) (/usr/lib64/libasan.so.5+0x10c10f) #1 0x40126f in main /home/marxin/Programming/testcases/pr91434.cpp:55 SUMMARY: AddressSanitizer: double-free (/usr/lib64/libasan.so.5+0x10d595) in operator delete(void*, unsigned long) ==11968==ABORTING
[Bug bootstrap/91438] New: [10 Regression] Profiledbootstrap broken on i586 in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91438 Bug ID: 91438 Summary: [10 Regression] Profiledbootstrap broken on i586 in Ada Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Target Milestone: --- Host: i586-linux-gnu Target: i586-linux-gnu Build: i586-linux-gnu I see following problem: [12028s] /home/abuild/rpmbuild/BUILD/gcc-10.0.0+r274314/obj-i586-suse-linux/./prev-gcc/xgcc -B/home/abuild/rpmbuild/BUILD/gcc-10.0.0+r274314/obj-i586-suse-linux/./prev-gcc/ -B/usr/i586-suse-linux/bin/ -B/usr/i586-suse-linux/bin/ -B/usr/i586-suse-linux/lib/ -isystem /usr/i586-suse-linux/include -isystem /usr/i586-suse-linux/sys-include-c -fomit-frame-pointer -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -U_FORTIFY_SOURCE -fprofile-use -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc/ada -I../../gcc/ada/gcc-interface -Iada/libgnat -I../../gcc/ada/libgnat ../../gcc/ada/exp_ch5.adb -o ada/exp_ch5.o [12032s] raised STORAGE_ERROR : stack overflow or erroneous memory access [12032s] make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:140: ada/exp_ch5.o] Error 1 Where valgrind complains about: ==1530751== Invalid read of size 4 ==1530751==at 0x88F2888: lookup_page_table_entry (ggc-page.c:641) ==1530751==by 0x88F2888: ggc_set_mark(void const*) (ggc-page.c:1531) ==1530751==by 0x8B39D48: gt_ggc_mx_symtab_node(void*) (gtype-desc.c:1302) ==1530751==by 0x8B39DFE: gt_ggc_mx_symtab_node(void*) (gtype-desc.c:1353) ==1530751==by 0x852A89E: gt_ggc_mx_lang_tree_node(void*) (gtype-ada.h:287) ==1530751==by 0x8B3728A: gt_ggc_mx_rtx_def(void*) (gtype-desc.c:717) ==1530751==by 0x89D0F4E: gt_ggc_mx (vec.h:1317) ==1530751==by 0x89D0F4E: gt_ggc_mx_vec_dw_attr_node_va_gc_ (gt-dwarf2out.h:274) ==1530751==by 0x89D0F4E: gt_ggc_mx_vec_dw_attr_node_va_gc_(void*) (gt-dwarf2out.h:269) ==1530751==by 0x89D0FD3: gt_ggc_mx_die_struct (gt-dwarf2out.h:45) ==1530751==by 0x89D0FD3: gt_ggc_mx_die_struct(void*) (gt-dwarf2out.h:23) ==1530751==by 0x89D0FF9: gt_ggc_mx_die_struct (gt-dwarf2out.h:47) ==1530751==by 0x89D0FF9: gt_ggc_mx_die_struct(void*) (gt-dwarf2out.h:23) ==1530751==by 0x89D0F4E: gt_ggc_mx (vec.h:1317) ==1530751==by 0x89D0F4E: gt_ggc_mx_vec_dw_attr_node_va_gc_ (gt-dwarf2out.h:274) ==1530751==by 0x89D0F4E: gt_ggc_mx_vec_dw_attr_node_va_gc_(void*) (gt-dwarf2out.h:269) ==1530751==by 0x89D0FD3: gt_ggc_mx_die_struct (gt-dwarf2out.h:45) ==1530751==by 0x89D0FD3: gt_ggc_mx_die_struct(void*) (gt-dwarf2out.h:23) ==1530751==by 0x89C9B62: ggc_mx (hash-traits.h:235) ==1530751==by 0x89C9B62: ggc_maybe_mx (hash-traits.h:242) ==1530751==by 0x89C9B62: gt_ggc_mx (hash-table.h:1166) ==1530751==by 0x89C9B62: gt_ggc_mx_hash_table_decl_die_hasher_ (gt-dwarf2out.h:395) ==1530751==by 0x89C9B62: gt_ggc_mx_hash_table_decl_die_hasher_(void*) (gt-dwarf2out.h:390) ==1530751==by 0x8AC4683: ggc_mark_root_tab(ggc_root_tab const*) (ggc-common.c:77) ==1530751== Address 0x2968 is not stack'd, malloc'd or (recently) free'd ==1530751== raised STORAGE_ERROR : stack overflow or erroneous memory access The regression must be couple of days old. Note that one needs PGO bootstrap and i586 target.
[Bug bootstrap/91438] [10 Regression] Profiledbootstrap broken on i586 in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91438 Martin Liška changed: What|Removed |Added Last reconfirmed||2019-8-13 Known to work||9.1.1 Target Milestone|--- |10.0 Known to fail||10.0
[Bug fortran/90561] [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90561 --- Comment #7 from Thomas Koenig --- The ICE already occurs for program p character(:), allocatable :: z(:) z = z(2) end (invalid code, but shorter :-)
[Bug testsuite/91437] New: Problem with multi-line test outputs on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91437 Bug ID: 91437 Summary: Problem with multi-line test outputs on x86_64-w64-mingw32 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg00909.html shows quite a few bugs on x86_64-w64-mingw32. However, many of these appear to be false positives. Some analysis of the original data at https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W shows that some of these "failures" seem to be an artifact. For example, looking at the file gfortran.log.gz under https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W?path=%2F9.1.1-rev.274208%2Fgcc%2Ftestsuite%2Fgfortran one finds D:/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.1/gcc/testsuite/gfortran.dg/do_subscript_1.f90:6:7: Warning: (1) D:/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.1/gcc/testsuite/gfortran.dg/do_subscript_1.f90:5:46: Warning: Array reference at (1) out of bounds (-1 < 1) in loop beginning at (2) D:/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.1/gcc/testsuite/gfortran.dg/do_subscript_1.f90:9:7: Warning: (1) D:/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.1/gcc/testsuite/gfortran.dg/do_subscript_1.f90:8:46: Warning: Array reference at (1) out of bounds (4 > 3) in loop beginning at (2) [..] PASS: gfortran.dg/do_subscript_1.f90 -O (test for warnings, line 5) FAIL: gfortran.dg/do_subscript_1.f90 -O (test for warnings, line 6) PASS: gfortran.dg/do_subscript_1.f90 -O (test for warnings, line 8) FAIL: gfortran.dg/do_subscript_1.f90 -O (test for warnings, line 9) [...] D:/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.1/gcc/testsuite/gfortran.dg/do_subscript_1.f90:6:7: Warning: (1) D:/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.1/gcc/testsuite/gfortran.dg/do_subscript_1.f90:9:7: Warning: (1) [...] so the problem appears to be with the regexp of the test, the output of the compiler, or dejagnu. I think if this kind of problem was fixed, the test tesults would look _much_ cleaner.
[Bug target/81800] [8/9 regression] on aarch64 ilp32 lrint should not be inlined as two instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800 Wilco changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 regression] on |[8/9 regression] on aarch64 |aarch64 ilp32 lrint should |ilp32 lrint should not be |not be inlined as two |inlined as two instructions |instructions| --- Comment #18 from Wilco --- Fixed on trunk so far.
[Bug target/81800] [8/9/10 regression] on aarch64 ilp32 lrint should not be inlined as two instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800 --- Comment #17 from Wilco --- Author: wilco Date: Tue Aug 13 10:46:44 2019 New Revision: 274376 URL: https://gcc.gnu.org/viewcvs?rev=274376=gcc=rev Log: [AArch64] Fix PR81800 PR81800 is about the lrint inline giving spurious FE_INEXACT exceptions. The previous change for PR81800 didn't fix this: when lrint is disabled in the backend, the midend will simply use llrint. This actually makes things worse since llrint now also ignores FE_INVALID exceptions! The fix is to disable lrint/llrint on double if the size of a long is smaller (ie. ilp32). gcc/ PR target/81800 * gcc/config/aarch64/aarch64.md (lrint): Disable lrint pattern if GPF operand is larger than a long int. testsuite/ PR target/81800 * gcc.target/aarch64/no-inline-lrint_3.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/no-inline-lrint_3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md trunk/gcc/testsuite/ChangeLog
[Bug c++/91436] New: Confusing suggestion to include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91436
Bug ID: 91436
Summary: Confusing suggestion to include
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
When the reason for an undefined function is too low c++ standard, g++ still
suggests to include the header where it's supposed to be. As a result, when in
a project you're not familiar with you're trying to use all usual C++ features,
and then get upon compilation such error, you start thinking that the project
managed to somehow screw defines and what-not. When it's a Qt project, you
think it's code generator's problem.
When the reality is that the suggestion is just wrong: you just can't make this
function defined with the standard the project is using.
# Steps to reproduce (in terms of terminal commands)
$ cat test.cpp
#include
int main() {
auto foo = std::make_unique();
}
$ g++ test.cpp -std=c++11
test.cpp: In function ‘int main()’:
test.cpp:4:21: error: ‘make_unique’ is not a member of ‘std’
4 | auto foo = std::make_unique();
| ^~~
test.cpp:2:1: note: ‘std::make_unique’ is defined in header ‘’; did
you forget to ‘#include ’?
1 | #include
+++ |+#include
2 |
test.cpp:4:33: error: expected primary-expression before ‘char’
4 | auto foo = std::make_unique();
## Expected
There's no suggestion to #include because that's just not gonna work.
## Actual
There's suggestion to #include .
[Bug fortran/90561] [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90561 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #6 from Thomas Koenig --- I'll take a look.
[Bug fortran/90561] [9/10 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90561 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- Probably, a gfc_start_block needs to be changed to a gfc_init_block somewhere.
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Janne Blomqvist --- Fixed on trunk, and improved seeding backported to 9 and 8 branches. Closing.
[Bug fortran/91424] Extend warnings about DO loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Thomas Koenig --- Fixed on trunk and gcc-9.
[Bug testsuite/91422] Illegal Fortran in testsuite/libgomp.oacc-fortran/routine-7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91422 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Thomas Koenig --- Fixed, closing.
[Bug fortran/91424] Extend warnings about DO loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424 Bug 91424 depends on bug 91422, which changed state. Bug 91422 Summary: Illegal Fortran in testsuite/libgomp.oacc-fortran/routine-7.f90 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91422 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug testsuite/91422] Illegal Fortran in testsuite/libgomp.oacc-fortran/routine-7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91422 --- Comment #4 from Thomas Koenig --- Author: tkoenig Date: Tue Aug 13 10:05:44 2019 New Revision: 274369 URL: https://gcc.gnu.org/viewcvs?rev=274369=gcc=rev Log: 2019-08-13 Thomas Koenig Backport from trunk PR fortran/91424 * frontend-passes.c (do_subscript): Do not warn for an expression a second time. Do not warn about a zero-trip loop. (doloop_warn): Also look at contained namespaces. 2019-08-13 Thomas Koenig Backport from trunk PR fortran/91424 * gfortran.dg/do_subscript_3.f90: New test. * gfortran.dg/do_subscript_4.f90: New test. * gfortran.dg/pr70754.f90: Use indices that to not overflow. 2019-08-13 Thomas Koenig Backport from trunk PR fortran/91422 * testsuite/libgomp.oacc-fortran/routine-7.f90: Correct array dimension. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/do_subscript_3.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/do_subscript_4.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/frontend-passes.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr70754.f90 branches/gcc-9-branch/libgomp/ChangeLog branches/gcc-9-branch/libgomp/testsuite/libgomp.oacc-fortran/routine-7.f90
[Bug fortran/91424] Extend warnings about DO loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91424 --- Comment #6 from Thomas Koenig --- Author: tkoenig Date: Tue Aug 13 10:05:44 2019 New Revision: 274369 URL: https://gcc.gnu.org/viewcvs?rev=274369=gcc=rev Log: 2019-08-13 Thomas Koenig Backport from trunk PR fortran/91424 * frontend-passes.c (do_subscript): Do not warn for an expression a second time. Do not warn about a zero-trip loop. (doloop_warn): Also look at contained namespaces. 2019-08-13 Thomas Koenig Backport from trunk PR fortran/91424 * gfortran.dg/do_subscript_3.f90: New test. * gfortran.dg/do_subscript_4.f90: New test. * gfortran.dg/pr70754.f90: Use indices that to not overflow. 2019-08-13 Thomas Koenig Backport from trunk PR fortran/91422 * testsuite/libgomp.oacc-fortran/routine-7.f90: Correct array dimension. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/do_subscript_3.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/do_subscript_4.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/frontend-passes.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr70754.f90 branches/gcc-9-branch/libgomp/ChangeLog branches/gcc-9-branch/libgomp/testsuite/libgomp.oacc-fortran/routine-7.f90
[Bug tree-optimization/91435] Better induction variable for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91435
--- Comment #1 from Marc Glisse ---
(In reply to Marc Glisse from comment #0)
> If we are only ever going to use x+2, why not use that instead, initialize
> with {2,3,4,...}, and skip the +2 at every iteration?
Or since we have another variable
# vect_vec_iv_.13_57 = PHI <{ 1, 2, 3, 4, 5, 6, 7, 8 }(5),
vect_vec_iv_.13_58(6)>
vect_vec_iv_.13_58 = vect_vec_iv_.13_57 + { 8, 8, 8, 8, 8, 8, 8, 8 };
use that one +1 and maintain one less variable.
[Bug tree-optimization/91435] New: Better induction variable for vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91435
Bug ID: 91435
Summary: Better induction variable for vectorization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
(from https://stackoverflow.com/q/57465290/1918193)
long RegularTest(int n) {
long sum = 0;
for (int i = 0; i < n; ++i)
if (i % 2 != 0)
sum += i + 1;
return sum;
}
Compiling with -O3 -march=skylake, this gets vectorized, but the result has
# vect_vec_iv_.14_60 = PHI <{ 0, 1, 2, 3, 4, 5, 6, 7 }(5),
vect_vec_iv_.14_61(6)>
vect_vec_iv_.14_61 = vect_vec_iv_.14_60 + { 8, 8, 8, 8, 8, 8, 8, 8 };
vect__3.17_66 = vect_vec_iv_.14_60 + { 2, 2, 2, 2, 2, 2, 2, 2 };
(those are the only uses of vect_vec_iv_.14_6[01])
If we are only ever going to use x+2, why not use that instead, initialize with
{2,3,4,...}, and skip the +2 at every iteration?
(there are other things to discuss about optimizing this testcase, for instance
clang is clever enough to unroll by a factor of 2 and remove the condition, but
let's stick to the induction variable for this PR)
[Bug c++/91434] New: gcc optimization behaviour is inconsistent with -O2 with 4.1.2 and 4.9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91434 Bug ID: 91434 Summary: gcc optimization behaviour is inconsistent with -O2 with 4.1.2 and 4.9.4 Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rajawrite at gmail dot com Target Milestone: --- Created attachment 46706 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46706=edit member variable is not set to NULL when destructor is called manually once and self destruction In our project, we moved from g++ 4.1.2 to 4.9.4. There is behaviour change with member variable setting to NULL when manually called destructor and during self destruction. ouput with gcc 4.9.4: = cds-build15:1044> /usr/local/bin/g++ -O2 sample1.cpp -o sample1.o cds-build15:1045> ./sample1.o FSPGI ctor1 FSPI ctor FSPG ctor FSPGI ctor FSPGI dtor m_g is not NULL FSPG dtor FSPI dtor FSPGI dtor m_g is not NULL FSPG dtor *** Error in `./sample1.o': double free or corruption (fasttop): 0x0137c010 *** === Backtrace: = /lib64/libc.so.6(+0x81499)[0x7fd25345e499] ouput with gcc 4.9.4 with -fno-tree-dse: cds-build15:1048> /usr/local/bin/g++ -O2 -fno-tree-dse sample1.cpp -o sample1.o cds-build15:1049> ./sample1.o FSPGI ctor1 FSPI ctor FSPG ctor FSPGI ctor FSPGI dtor m_g is not NULL FSPG dtor FSPI dtor FSPGI dtor cds-build15:1050> output with g++ 4.1.2: == cds-build3:1011> g++ -O2 sample1.cpp -o sample1.o cds-build3:1012> ./sample1.o FSPGI ctor1 FSPI ctor FSPG ctor FSPGI ctor FSPGI dtor m_g is not NULL FSPG dtor FSPI dtor FSPGI dtor cds-build3:1013> Please check if this is the correct behviour and -fno-tree-dse should be used for this code and impact of disabling dse.
[Bug c++/91423] address-of-packed-member when taking packed struct member by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91423 --- Comment #5 from Anders Schau Knatten --- (In reply to Andrew Pinski from comment #4) > Vec size = s.size; > > you are invoking the copy constructor here ... > Which means you are taking the address (implicitly). Good point. This should be safe though, as `Vec` itself is packed, so its copy constructor would have to handle unaligned arguments. (In fact, if `Vec` wasn't packed, the compiler would not allow `S` to be packed either.) I'm however not sure if we should expect gcc to take this information into account when deciding whether to emit the warning, what do you think?
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 --- Comment #8 from Janne Blomqvist --- Author: jb Date: Tue Aug 13 09:04:18 2019 New Revision: 274365 URL: https://gcc.gnu.org/viewcvs?rev=274365=gcc=rev Log: PR fortran/91414 Bugfix for previous commit Correctly fill master_seed from os_seed. Modified: trunk/libgfortran/intrinsics/random.c
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 --- Comment #7 from Janne Blomqvist --- Author: jb Date: Tue Aug 13 09:02:25 2019 New Revision: 274364 URL: https://gcc.gnu.org/viewcvs?rev=274364=gcc=rev Log: PR fortran/91414 Correctly fill master_state from os_seed. Modified: branches/gcc-9-branch/libgfortran/intrinsics/random.c
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 --- Comment #6 from Janne Blomqvist --- Author: jb Date: Tue Aug 13 09:00:46 2019 New Revision: 274363 URL: https://gcc.gnu.org/viewcvs?rev=274363=gcc=rev Log: PR fortran/91414 Improve initialization of PRNG As part of PR 91414 an improved PRNG was contributed to trunk. This is a partial backport of some related changes to the PRNG. Namely when seeding the PRNG, it needs only 8 bytes of randomness from the OS, and uses a simple splitmix64 PRNG to fill in the rest of the state, instead of getting all the state from the OS. This can be useful for operating systems that can run out of entropy. libgfortran/ChangeLog: 2019-08-13 Janne Blomqvist Partial backport from trunk PR fortran/91414 * intrinsics/random.c (lcg_parkmiller): Replace with splitmix64. (splitmix64): New function. (getosrandom): Fix return value, simplify. (init_rand_state): Use getosrandom only to get 8 bytes, splitmix64 to fill rest of state. Modified: branches/gcc-8-branch/libgfortran/ChangeLog branches/gcc-8-branch/libgfortran/intrinsics/random.c
[Bug middle-end/91433] Performance Regression when upgrading from 8.3.0 to 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91433 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-linux Status|UNCONFIRMED |WAITING Last reconfirmed||2019-08-13 Component|c |middle-end Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- 9.0 is not a released GCC version, the first release from the GCC 9 branch is versioned GCC 9.1.0 with GCC 9.2.0 just released yesterday. I assume you tested on x86_64-linux. What compile-flags did you use and what machine sub-architecture are you running on (in case phoronix uses -march=native).
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 --- Comment #5 from Janne Blomqvist --- Author: jb Date: Tue Aug 13 08:42:43 2019 New Revision: 274362 URL: https://gcc.gnu.org/viewcvs?rev=274362=gcc=rev Log: PR fortran/91414 Improve initialization of PRNG As part of PR 91414 an improved PRNG was contributed to trunk. This is a partial backport of some related changes to the PRNG. Namely when seeding the PRNG, it needs only 8 bytes of randomness from the OS, and uses a simple splitmix64 PRNG to fill in the rest of the state, instead of getting all the state from the OS. This can be useful for operating systems that can run out of entropy. libgfortran/ChangeLog: 2019-08-13 Janne Blomqvist Partial backport from trunk PR fortran/91414 * intrinsics/random.c (lcg_parkmiller): Replace with splitmix64. (splitmix64): New function. (getosrandom): Fix return value, simplify. (init_rand_state): Use getosrandom only to get 8 bytes, splitmix64 to fill rest of state. Modified: branches/gcc-9-branch/libgfortran/ChangeLog branches/gcc-9-branch/libgfortran/intrinsics/random.c
[Bug c++/91431] Using class template for containers and iterators rather than defining template only for iterators caused a trouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91431 Richard Biener changed: What|Removed |Added Keywords||needs-reduction Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-13 Ever confirmed|0 |1 Known to fail||10.0, 6.4.0, 7.4.0, 8.3.0, ||9.1.0 --- Comment #1 from Richard Biener --- Confirmed on x86_64-linux.
[Bug c/91433] New: Performance Regression when upgrading from 8.3.0 to 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91433 Bug ID: 91433 Summary: Performance Regression when upgrading from 8.3.0 to 9.0 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mc_george123 at hotmail dot com Target Milestone: --- During the phoronix tests of botan-1.4.0-blowfish benchmark and crafty-1.4.4 benchmark, there are performance regressions in compilation process between version 8.3.0-433 and 9.0-454.
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 --- Comment #4 from Janne Blomqvist --- Author: jb Date: Tue Aug 13 08:24:43 2019 New Revision: 274361 URL: https://gcc.gnu.org/viewcvs?rev=274361=gcc=rev Log: PR fortran/91414: Improved PRNG Update the PRNG from xorshift1024* to xoshiro256** by the same author. For details see http://prng.di.unimi.it/ and the paper at https://arxiv.org/abs/1805.01407 Also the seeding is slightly improved, by reading only 8 bytes from the operating system and using the simple splitmix64 PRNG to fill in the rest of the PRNG state (as recommended by the xoshiro author), instead of reading the entire state from the OS. Regtested on x86_64-pc-linux-gnu, Ok for trunk? gcc/fortran/ChangeLog: 2019-08-13 Janne Blomqvist PR fortran/91414 * check.c (gfc_check_random_seed): Reduce seed_size. * intrinsic.texi (RANDOM_NUMBER): Update to match new PRNG. gcc/testsuite/ChangeLog: 2019-08-13 Janne Blomqvist PR fortran/91414 * gfortran.dg/random_seed_1.f90: Update to match new seed size. libgfortran/ChangeLog: 2019-08-13 Janne Blomqvist PR fortran/91414 * intrinsics/random.c (prng_state): Update state struct. (master_state): Update to match new size. (get_rand_state): Update to match new PRNG. (rotl): New function. (xorshift1024star): Replace with prng_next. (prng_next): New function. (jump): Update for new PRNG. (lcg_parkmiller): Replace with splitmix64. (splitmix64): New function. (getosrandom): Fix return value, simplify. (init_rand_state): Use getosrandom only to get 8 bytes, splitmix64 to fill rest of state. (random_r4): Update to new function and struct names. (random_r8): Likewise. (random_r10): Likewise. (random_r16): Likewise. (arandom_r4): Liekwise. (arandom_r8): Likewise. (arandom_r10): Likwewise. (arandom_r16): Likewise. (xor_keys): Reduce size to match new PRNG. (random_seed_i4): Update to new function and struct names, remove special handling of variable p used in previous PRNG. (random_seed_i8): Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/random_seed_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/random.c
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #1 from Marc Glisse --- The warning basically says "you may have forgotten 'break;'". If it falls through to break anyway, what difference does it make if I add a redundant break?
[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109 --- Comment #14 from Bernd Edlinger --- I can reproduce with trunk: arm-linux-gnueabihf-gcc -S -O2 -mthumb -flto -fno-use-linker-plugin 20040709-1.c but not with -O3 -g, neither with gcc-9 and my fix applied. Nevertheless it is quite obvious that the second patch is needed to handle the case when rematerialized instructions have scratches, but nothing needs to be spilled so the loop need to continue with lra_assign instead of lra_spill.
[Bug c/91432] New: gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
Bug ID: 91432
Summary: gcc -Wimplicit-fallthrough does not warn when
fallthrough to break;
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joe at perches dot com
Target Milestone: ---
This code does not emit a fallthrough warning:
int foo(int i)
{
switch (i) {
case 1:
i = 0;
default:
break;
}
return i;
}
Basically any case block that falls through to another
block of just a break statement does not get a warning.
Is this a defect or what was the logic behind this decision?
[Bug tree-optimization/91419] [10 Regression]: gcc.dg/tree-ssa/pr91091-2.c, ssa-fre-61.c, ssa-fre-61.c with r273232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419
--- Comment #3 from rguenther at suse dot de ---
On Mon, 12 Aug 2019, hp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91419
>
> --- Comment #2 from Hans-Peter Nilsson ---
>
> (In reply to Richard Biener from comment #1)
> > Jeff also noticed this. The issue should happen on targets where
> > alignof(int) != sizeof(int) since there we cannot conclude that with int *p,
> > *q; the
> > accesses *p and *q either overlap exactly (p == q) or they do not overlap.
>
> Ew! I'd hope there was some language constraint forbidding such incomplete
> overlap. Doesn't that mean a pointer to a structure can overlap another for
> structures with piecewise similarity (for all targets)?
No, usually type-based alias rules forbid this (-fstrict-aliasing).
But relying on that proved difficult/impossible for the value-numbering
feature tested by these testcases so we now rely solely on alignment...
> > Skimming through target-supports.exp I see natural_alignment_32 but that
> > seems to be incomplete, not matching either of the affected targets of this
> > bug:
> >
> > # Return 1 if types of size 32 bit or less are naturally aligned
> > # (aligned to their type-size), 0 otherwise.
> > #
> > # This won't change for different subtargets so cache the result.
> >
> > proc check_effective_target_natural_alignment_32 { } {
> > # FIXME: 32bit powerpc: guaranteed only if MASK_ALIGN_NATURAL/POWER.
> > return [check_cached_effective_target_indexed natural_alignment_32 {
> > if { ([istarget *-*-darwin*] && [is-effective-target lp64])
> > || [istarget avr-*-*] } {
> >return 0
> > } else {
> >return 1
> > }
> > }]
> > }
> >
> > Thus known issue but no easy testsuite workaround sofar unless we fix the
> > above. natural_alignment_32 is used in
> > gcc.dg/ipa/propalign-?.c
> > and some powerpc specific vector tests. Do the above also fail for you?
>
> Yes.
>
> At r274275 for ipa.exp:
> Running /x/autotestgcc1/gcc/gcc/testsuite/gcc.dg/ipa/ipa.exp ...
> FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be
> created; target is discardable"
> FAIL: gcc.dg/ipa/propalign-1.c scan-ipa-dump cp "Adjusting align"
> FAIL: gcc.dg/ipa/propalign-1.c scan-tree-dump-not optimized "fail_the_test"
> FAIL: gcc.dg/ipa/propalign-2.c scan-ipa-dump cp "Adjusting align"
> FAIL: gcc.dg/ipa/propalign-2.c scan-tree-dump-not optimized "fail_the_test"
> FAIL: gcc.dg/ipa/propalign-5.c scan-ipa-dump cp "align: 2"
> (These tests have failed at every auto-test-run, i.e. not regressions, i.e. I
> haven't paid attention to them.)
>
> > Does it make sense to have natural_alignment_16 (not sure about the targets
> > you cite, but m68k would fall into this category).
>
> For cris-elf there's byte alignment, not (u)int16_t-alignment, so I guess we'd
> have to introduce another effective_target. But, I think it could better use
> a
> compile-test and alignof as the default, rather than a target-list.
OK, so all testcases in this PR use 'int' which means disabling
for !natural_alignment_32 would be enough (unless 'int' is not 32bit ;))
I agree that using target lists is imperfect (but it has the lowest
testsuite time overhead). I'll amend the testcases with xfails for
!natural_alignment_32. Can you amend the target lists appropriately?
I guess cris-*-* (not only cris-*-elf) would need to be added.
