[Bug fortran/90290] -std=f2008 should reject non-constant stop and error stop codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90290 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch.
[Bug fortran/90290] -std=f2008 should reject non-constant stop and error stop codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90290 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 21 00:54:28 2019 New Revision: 272541 URL: https://gcc.gnu.org/viewcvs?rev=272541=gcc=rev Log: 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/90290 * match.c (gfc_match_stopcode): Check F2008 condition on stop code. 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/90290 * gfortran.dg/pr90290.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr90290.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/match.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/90002] ICE: free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90002 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.2 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch.
[Bug fortran/90002] ICE: free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90002 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 21 00:38:13 2019 New Revision: 272540 URL: https://gcc.gnu.org/viewcvs?rev=272540=gcc=rev Log: 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/90002 * array.c (gfc_free_array_spec): When freeing an array-spec, avoid an ICE for assumed-shape coarrays 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/90002 * gfortran.dg/pr90002.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr90002.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/array.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.2 --- Comment #9 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch.
[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 21 00:24:53 2019 New Revision: 272539 URL: https://gcc.gnu.org/viewcvs?rev=272539=gcc=rev Log: 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/89344 * expr.c (gfc_check_vardef_context): Check for INTENT(IN) variable in SELECT TYPE construct. 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/89344 * gfortran.dg/pr89344.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr89344.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/87907] ICE in resolve_contained_fntype, at fortran/resolve.c:587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87907 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|10.0|9.2 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch.
[Bug fortran/87907] ICE in resolve_contained_fntype, at fortran/resolve.c:587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87907 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 21 00:12:37 2019 New Revision: 272534 URL: https://gcc.gnu.org/viewcvs?rev=272534=gcc=rev Log: 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/87907 * resolve.c (resolve_contained_fntype): Do not dereference a NULL pointer. 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/87907 * gfortran.dg/pr87907.f90: New testcase. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr87907.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/86587] Derived-type with attributes BIND(C) and PRIVATE raises an error but standard accepts it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86587 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.2 --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch
[Bug fortran/86587] Derived-type with attributes BIND(C) and PRIVATE raises an error but standard accepts it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86587 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jun 21 00:01:23 2019 New Revision: 272533 URL: https://gcc.gnu.org/viewcvs?rev=272533=gcc=rev Log: 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/86587 * symbol.c (verify_bind_c_derived_type): Remove erroneous error checking for BIND(C) and PRIVATE attributes. 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/86587 * gfortran.dg/pr86587.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr86587.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/symbol.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/77632] [F08] Pointer initialisation does not quite work with arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77632 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Jun 20 23:50:54 2019 New Revision: 272532 URL: https://gcc.gnu.org/viewcvs?rev=272532=gcc=rev Log: 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/77632 * /decl.c (variable_decl): Mark a variable that is a target in pointer initialization when in PROGRAM, MODULE, or SUBMODULE scope with an implicit save. 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/77632 * gfortran.dg/pr77632_1.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr77632_1.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/decl.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.2 --- Comment #16 from kargl at gcc dot gnu.org --- Fixed on trunk and 9-branch.
[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499 --- Comment #15 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Jun 20 23:39:29 2019 New Revision: 272531 URL: https://gcc.gnu.org/viewcvs?rev=272531=gcc=rev Log: 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/69499 * match.c (gfc_match_select_type): SELECT TYPE is an executable statement, and cannot appear in MODULE or SUBMODULE scope. 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/69499 * gfortran.dg/pr69499.f90: New test. * gfortran.dg/module_error_1.f90: Update dg-error string. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr69499.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/match.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/module_error_1.f90
[Bug fortran/69398] [OOP] ICE on class with duplicate dimension attribute specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69398 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Jun 20 23:27:13 2019 New Revision: 272530 URL: https://gcc.gnu.org/viewcvs?rev=272530=gcc=rev Log: 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/69398 * decl.c (attr_decl): Check for duplicate DIMENSION attribute for a CLASS entity. 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/69398 * gfortran.dg/pr69398.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr69398.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/decl.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/69398] [OOP] ICE on class with duplicate dimension attribute specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69398 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.2 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk and branch-9
[Bug fortran/68544] ICE trying to pass derived type constructor as a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544 kargl at gcc dot gnu.org changed: What|Removed |Added Target Milestone|10.0|9.2 --- Comment #15 from kargl at gcc dot gnu.org --- Update target milestone after backport to branch-9.
[Bug fortran/68544] ICE trying to pass derived type constructor as a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544 --- Comment #14 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Jun 20 23:15:32 2019 New Revision: 272529 URL: https://gcc.gnu.org/viewcvs?rev=272529=gcc=rev Log: 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/68544 * resolve.c (is_dt_name): New function to compare symbol name against list of derived types. (resolve_actual_arglist): Use it to find wrong code. 2019-06-20 Steven G. Kargl Backport from mainline PR fortran/68544 * gfortran.dg/pr68544.f90: New test. * gfortran.dg/pr85687.f90: Modify test for new error message. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr68544.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/resolve.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr85687.f90
[Bug sanitizer/90865] ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865 sshannin at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #8 from sshannin at gmail dot com --- Thanks. Changing back to UNCONFIRMED.
[Bug c++/88853] ICE: verify_type failed (error: type variant differs by TYPE_PACKED)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88853 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-20 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- Confirmed with gcc version 10.0.0 20190620 (experimental) (GCC): 88853.C: In instantiation of ‘class yp >’: 88853.C:15:7: required from ‘class n1 >’ 88853.C:21:7: required from ‘class c4 >’ 88853.C:33:7: required from ‘class hb >’ 88853.C:45:7: required from ‘class fd’ 88853.C:52:7: required from ‘class dh > >’ 88853.C:17:22: required from ‘class n1 > >’ 88853.C:57:19: required from here 88853.C:26:7: error: type variant differs by TYPE_PACKED 26 | class yp | ^~ full-name "class fd" no-binfo use_template=1 interface-unknown chain > full-name "const class fd" no-binfo use_template=1 interface-unknown> 88853.C:26:7: internal compiler error: ‘verify_type’ failed 0x182ff70 verify_type(tree_node const*) /home/mpolacek/src/gcc/gcc/tree.c:14650 0xe2127e gen_type_die_with_usage /home/mpolacek/src/gcc/gcc/dwarf2out.c:25557 0xe21eb1 gen_type_die /home/mpolacek/src/gcc/gcc/dwarf2out.c:25787 0xe23b4c gen_decl_die /home/mpolacek/src/gcc/gcc/dwarf2out.c:26380 0xe1fffc gen_member_die /home/mpolacek/src/gcc/gcc/dwarf2out.c:25241 0xe20749 gen_struct_or_union_type_die /home/mpolacek/src/gcc/gcc/dwarf2out.c:25337 0xe21211 gen_tagged_type_die /home/mpolacek/src/gcc/gcc/dwarf2out.c:25538 0xe21b2b gen_type_die_with_usage /home/mpolacek/src/gcc/gcc/dwarf2out.c:25733 0xe21eb1 gen_type_die /home/mpolacek/src/gcc/gcc/dwarf2out.c:25787 0xe23df2 gen_decl_die /home/mpolacek/src/gcc/gcc/dwarf2out.c:26419 0xe252ee dwarf2out_decl /home/mpolacek/src/gcc/gcc/dwarf2out.c:26964 0xe24772 dwarf2out_type_decl /home/mpolacek/src/gcc/gcc/dwarf2out.c:26691 0x127930d rest_of_type_compilation(tree_node*, int) /home/mpolacek/src/gcc/gcc/passes.c:339 0x8a57a6 finish_struct_1(tree_node*) /home/mpolacek/src/gcc/gcc/cp/class.c:7091 0xab7d6c instantiate_class_template_1 /home/mpolacek/src/gcc/gcc/cp/pt.c:11495 0xab7ee2 instantiate_class_template(tree_node*) /home/mpolacek/src/gcc/gcc/cp/pt.c:11534 0xb845c2 complete_type(tree_node*) /home/mpolacek/src/gcc/gcc/cp/typeck.c:139 0xb845e7 complete_type_or_maybe_complain(tree_node*, tree_node*, int) /home/mpolacek/src/gcc/gcc/cp/typeck.c:151 0xb84685 complete_type_or_else(tree_node*, tree_node*) /home/mpolacek/src/gcc/gcc/cp/typeck.c:168 0x94ccfd xref_basetypes(tree_node*, tree_node*) /home/mpolacek/src/gcc/gcc/cp/decl.c:14310 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/79781] ICE on valid C++ code with -std=c++14 (in assemble_integer, at varasm.c:2733)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79781 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed.
[Bug c++/79781] ICE on valid C++ code with -std=c++14 (in assemble_integer, at varasm.c:2733)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79781 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Thu Jun 20 22:35:34 2019 New Revision: 272527 URL: https://gcc.gnu.org/viewcvs?rev=272527=gcc=rev Log: PR c++/79781 * g++.dg/ext/goto1.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/goto1.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/77632] [F08] Pointer initialisation does not quite work with arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77632 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #4) > Author: kargl > Date: Thu Jun 20 22:16:29 2019 > New Revision: 272526 > > URL: https://gcc.gnu.org/viewcvs?rev=272526=gcc=rev > Log: > 2019-06-20 Steven G. Kargl > > PR fortran/77632 > * /decl.c (variable_decl): Mark a variable that is a target in pointer > initialization when in PROGRAM, MODULE, or SUBMODULE scope with an > implicit save. > > 2019-06-20 Steven G. Kargl > > PR fortran/77632 > * gfortran.dg/pr77632_1.f90: New test. > > Added: > trunk/gcc/testsuite/gfortran.dg/pr77632_1.f90 > Modified: > trunk/gcc/fortran/ChangeLog > trunk/gcc/fortran/decl.c > trunk/gcc/testsuite/ChangeLog This patch fixes the issue with the code in comment #2. It does not fix the problem shown by the original code.
[Bug c++/79781] ICE on valid C++ code with -std=c++14 (in assemble_integer, at varasm.c:2733)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79781
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #6 from Marek Polacek ---
This is what ICEd:
void c() {
static __int128_t d = (long)& - (long)&
a:
b:;
}
I'll add it.
[Bug fortran/77632] [F08] Pointer initialisation does not quite work with arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77632 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Jun 20 22:16:29 2019 New Revision: 272526 URL: https://gcc.gnu.org/viewcvs?rev=272526=gcc=rev Log: 2019-06-20 Steven G. Kargl PR fortran/77632 * /decl.c (variable_decl): Mark a variable that is a target in pointer initialization when in PROGRAM, MODULE, or SUBMODULE scope with an implicit save. 2019-06-20 Steven G. Kargl PR fortran/77632 * gfortran.dg/pr77632_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr77632_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/68265] Arbitrary syntactic nonsense silently accepted after 'int (*){}' until the next close brace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug c++/68265] Arbitrary syntactic nonsense silently accepted after 'int (*){}' until the next close brace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Thu Jun 20 22:06:36 2019 New Revision: 272525 URL: https://gcc.gnu.org/viewcvs?rev=272525=gcc=rev Log: PR c++/68265 * g++.dg/parse/error62.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/error62.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/68265] Arbitrary syntactic nonsense silently accepted after 'int (*){}' until the next close brace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Fixed by r258549.
[Bug fortran/86587] Derived-type with attributes BIND(C) and PRIVATE raises an error but standard accepts it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86587 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Jun 20 21:39:43 2019 New Revision: 272524 URL: https://gcc.gnu.org/viewcvs?rev=272524=gcc=rev Log: 2019-06-20 Steven G. Kargl PR fortran/86587 * symbol.c (verify_bind_c_derived_type): Remove erroneous error checking for BIND(C) and PRIVATE attributes. 2019-06-20 Steven G. Kargl PR fortran/86587 * gfortran.dg/pr86587.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr86587.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug target/90952] New: Costs of moves are used for costs of RTL expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90952
Bug ID: 90952
Summary: Costs of moves are used for costs of RTL expressions
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: hubicka at ucw dot cz, skpgkp1 at gmail dot com, ubizjak at
gmail dot com
Target Milestone: ---
Target: i386,x86-64
This patch:
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00405.html
includes:
diff --git a/gcc/config/i386/x86-tune-costs.h
b/gcc/config/i386/x86-tune-costs.h
index e943d13..8409a5f 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -1557,7 +1557,7 @@ struct processor_costs skylake_cost = {
{4, 4, 4}, /* cost of loading integer registers
in QImode, HImode and SImode.
Relative to reg-reg move (2). */
- {6, 6, 6}, /* cost of storing integer registers */
+ {6, 6, 3}, /* cost of storing integer registers */
2, /* cost of reg,reg fld/fst */
{6, 6, 8}, /* cost of loading fp registers
in SFmode, DFmode and XFmode */
It lowered the cost for SImode store and made it cheaper than SSE<->integer
register move. It caused a regression:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90878
Since the cost for SImode store is also used to compute costs of
scalar_store RTL expression in ix86_builtin_vectorization_cost, it
changed loop costs in
void
foo (long p2, long *diag, long d, long i)
{
long k;
k = p2 < 3 ? p2 + p2 : p2 + 3;
while (i < k)
diag[i++] = d;
}
As the result, the loop is unrolled 4 times with -O3 -march=skylake,
instead of 3.
[Bug tree-optimization/90949] [9/10 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 --- Comment #6 from Jeffrey A. Law --- In response to c#5. The difference is when you use a bool for cleanup, it has to be promoted at the recursive call call to walk(). That's just enough to change the decision between using tail call (which still looks like a call) and tail recursion elimination which turns the recursive call into a simple backwards jump. In the former case (bool) we never have the copy propagation opportunity that triggers the problem. In the latter case, the backwards jump creates a loop and we determine it's profitable to copy the loop header which creates the PHI node with the dead incoming edge that triggers the copy propagation that causes the problems.
[Bug c++/67898] rejects-valid on overloaded function as non-type template argument of dependent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67898 --- Comment #2 from Richard Smith --- (Clang trunk now accepts both testcases.)
[Bug tree-optimization/84561] -Wstringop-truncation with -O2 depends on strncpy's size type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84561 --- Comment #7 from Martin Sebor --- That aside, I haven't given up and plan to post an updated patch for this bug for GCC 10.
[Bug c++/90951] [8/9/10 Regression] error initializing a constexpr array of a struct with const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90951 --- Comment #2 from Martin Sebor --- The compilation error was introduced in r209934 (gcc 5.0.0) via: PR c++/60980 * init.c (build_value_init): Don't try to call an array constructor. Prior to that GCC fails with an ICE on this test case. The ICE was in turn introduced in r203985 (gcc 4.9.0): In C++11 a trivial [cd]tor might not be callable. * class.c (user_provided_p): A function deleted on its declation in the class is not user-provided. (type_build_ctor_call): Also force a ctor call if we might have a deleted or private trivial ctor. (type_build_dtor_call): New. (deduce_noexcept_on_destructors): Remove obsolete code. * cp-tree.h: Declare type_build_dtor_call. * decl.c (expand_static_init): Make sure trivial dtors are callable. (cxx_maybe_build_cleanup): Likewise. * except.c (build_throw): Likewise. * init.c (build_value_init): Handle trivial but not callable ctors. (perform_target_ctor): Make sure trivial dtor is callable. (perform_member_init): Likewise. (expand_cleanup_for_base): Likewise. (build_vec_delete_1): Likewise. (build_delete): Likewise. (push_base_cleanups): Likewise. (build_new_1): Avoid redundant error. * method.c (synthesized_method_walk): Can't ever exit early in C++11. Always process the subobject destructor. * semantics.c (finish_compound_literal): Make sure trivial dtor is callable. * typeck2.c (split_nonconstant_init): Likewise. Before this change the test case was accepted.
[Bug c++/90951] [8/9/10 Regression] error initializing a constexpr array of a struct with const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90951
Martin Sebor changed:
What|Removed |Added
Known to work||4.8.5
Summary|[9/10 Regression] error |[8/9/10 Regression] error
|initializing a constexpr|initializing a constexpr
|array of a struct with |array of a struct with
|const member|const member
Known to fail||10.0, 4.9.1, 5.5.0, 6.4.0,
||7.4.0, 8.3.0, 9.1.0
--- Comment #1 from Martin Sebor ---
Actually, I don't think this is related to r270155. When the test case is
modified as shown below it fails to compile even prior to the change and all
the way to GCC 4.9. It is accepted by GCC 4.8. It needs -std=c++11:
#define assert(expr) static_assert (expr, #expr)
struct S { const char a[2]; };
constexpr struct S a[1][1][1] = { };
assert ('\0' == *a[0][0][0].a);
t.C:7:29: error: use of deleted function ‘S::S()’
7 | assert ('\0' == *a[0][0][0].a);
| ^
t.C:1:37: note: in definition of macro ‘assert’
1 | #define assert(expr) static_assert (expr, #expr)
| ^~~~
t.C:3:10: note: ‘S::S()’ is implicitly deleted because the default definition
would be ill-formed:
3 | struct S { const char a[2]; };
| ^
t.C:3:10: error: uninitialized const member in ‘struct S’
t.C:3:25: note: ‘const char S::a [2]’ should be initialized
3 | struct S { const char a[2]; };
| ^
t.C:7:31: error: use of deleted function ‘S::S()’
7 | assert ('\0' == *a[0][0][0].a);
| ^
t.C:7:14: error: non-constant condition for static assertion
7 | assert ('\0' == *a[0][0][0].a);
| ~^~~~
t.C:1:37: note: in definition of macro ‘assert’
1 | #define assert(expr) static_assert (expr, #expr)
| ^~~~
t.C:7:14: error: use of deleted function ‘S::S()’
7 | assert ('\0' == *a[0][0][0].a);
| ~^~~~
t.C:1:37: note: in definition of macro ‘assert’
1 | #define assert(expr) static_assert (expr, #expr)
| ^~~~
[Bug fortran/65921] GFortran should use __builtin_mul_overflow when checking allocation sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65921 --- Comment #3 from Janne Blomqvist --- Author: jb Date: Thu Jun 20 20:26:39 2019 New Revision: 272520 URL: https://gcc.gnu.org/viewcvs?rev=272520=gcc=rev Log: libfortran/65921: Add forgotten PR number to ChangeLog 2019-06-14 Janne Blomqvist PR fortran/65921 * runtime/memory.c (SIZE_MAX):Remove macro definition. (xmallocarray): Use __builtin_mul_overflow. Modified: trunk/libgfortran/ChangeLog
[Bug c++/90951] New: error initializing a constexpr array of a struct with const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90951
Bug ID: 90951
Summary: error initializing a constexpr array of a struct with
const member
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Here's another bug caused by my r270155. The valid code is accepted by Clang
and GCC 8 but rejected by GCC 9.1.0 and 10.0.
$ cat t.C && gcc -S -Wall t.C
struct S { const char a[2]; };
constexpr struct S a[1] = { { "" } };
static_assert ('\0' == *a[0].a, "!");
t.C:5:30: error: use of deleted function ‘S::S()’
5 | static_assert ('\0' == *a[0].a, "!");
| ^
t.C:1:8: note: ‘S::S()’ is implicitly deleted because the default definition
would be ill-formed:
1 | struct S { const char a[2]; };
|^
t.C:1:8: error: uninitialized const member in ‘struct S’
t.C:1:23: note: ‘const char S::a [2]’ should be initialized
1 | struct S { const char a[2]; };
| ^
t.C:5:37: error: use of deleted function ‘S::S()’
5 | static_assert ('\0' == *a[0].a, "!");
| ^
t.C:5:21: error: non-constant condition for static assertion
5 | static_assert ('\0' == *a[0].a, "!");
|~^~
t.C:5:21: error: use of deleted function ‘S::S()’
[Bug tree-optimization/84561] -Wstringop-truncation with -O2 depends on strncpy's size type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84561 --- Comment #6 from Martin Sebor --- The simple patch that fixed the warning was never approved. Here's my last attempt to get approval: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01415.html It too stalled, much to my frustration.
[Bug tree-optimization/90930] Excessive memory consumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90930 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog Status|WAITING |NEW CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Component|middle-end |tree-optimization --- Comment #5 from Richard Biener --- A lot of memory is somehow consumed during Run till exit from #0 reassociate_bb (bb=) at /space/rguenther/src/svn/trunk2/gcc/tree-ssa-reassoc.c:5944 for example for the function ua_namespace0 I suspect the bitops stuff which looks quadratic, not caching work done in dominators and eventually producing quite some GC garbage it doesn't cleanup. Testcase is too slow to investigate further right now.
[Bug tree-optimization/90949] [9/10 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 Łukasz Kucharski changed: What|Removed |Added CC||luk32 at o2 dot pl --- Comment #5 from Łukasz Kucharski --- Hi, I am the guy who isolated the issue for c++, behind the question. If this isn't too much, could anyone explain why does changing type of cleanup from int to bool solves the issue? Everything else I can understand, because those are changes in observable behaviour. Do the optimizers treat boolean and integers differently, even in bool contexts? This is intriguing. I know this is tangential, but it really bugs me and I am not sure if I can study the sourcecode of gcc optimizer in reasonable time.
[Bug tree-optimization/90949] [9/10 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 --- Comment #4 from Jeffrey A. Law --- Precisely. I didn't see a helper to set pt.null to 1/true, but it's trivial enough to add one.
[Bug tree-optimization/90949] [9/10 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC||rguenth at gcc dot gnu.org
Target Milestone|--- |9.2
--- Comment #3 from Richard Biener ---
Hmm, non-nullness isn't properly tracked by PTA but I remember somebody added
computing pt.null from VRP. But before that PTA info was flow-insensitive
and thus we didn't have to be careful with propagating it. After this change
it _is_ now flow-sensitive and we at least have to reset null-ness info
(set pi->pt.null to 1). There's helpers to reset flow-sensitive info on
SSA names/stmts. And the issue is latent since the introduction of
{set,get}_ptr_nonnull.
[Bug c++/90947] [9/10 Regression] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |9.2
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/84561] -Wstringop-truncation with -O2 depends on strncpy's size type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84561 --- Comment #5 from Romain Geissler --- Hi, With the new release of gcc 9, I am seeing new occurences of this issue. I am trying to put a statement _string[len] = 0; after the strncpy to silence the warning, but still it triggers sometimes. Is the patch you posted back then still being discussed ? Cheers, Romain
[Bug c++/90936] [9 Regression] Ambiguous call with ref-qualified conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90936 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid, ||rejects-valid Target Milestone|--- |9.2
[Bug tree-optimization/90949] [9/10 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #2 from Jeffrey A. Law --- OK. I see what's happening here. At the end of SRA we have the following key block: ;; basic block 7, loop depth 0 ;;pred: 4 ;;3 # module_12 = PHI <_14(4), module_16(D)(3)> # cleanup_19 = PHI _17 = module_12->child; walk (_17, cleanup_19); free (module_12); goto ; [100.00%] ;;succ: 6 DOM fires up and is going to correctly determine the edge 4->7 is not executable. DOM (via evrp analysis) is also going to know that module_16 _in this context_ must have a non-null value. The combination of those two factors will mean that module_12 always has a non-null value. DOM completes and we're left with that block looking like: ;; basic block 6, loop depth 0 ;;pred: 3 # module_12 = PHI # cleanup_19 = PHI _17 = module_16(D)->child; walk (_17, cleanup_13(D)); free (module_16(D)); goto ; [100.00%] ;;succ: 5 Now copyprop comes along. The degenerate PHI is just a copy so it's going to want to propagate it away. module_12 is a copy of module_16. We have no PTA information for module_16, but we do have PTA information for module_12. The copy propagator will copy the PTA information from module_12 to module_16, including the nonnull state (which remember was _context dependent_). So PTA now says that module_16 must be non-null and a subsequent pass deletes this test at the start of the function: ;; basic block 6, loop depth 0 ;;pred: 3 # module_12 = PHI # cleanup_19 = PHI _17 = module_16(D)->child; walk (_17, cleanup_13(D)); free (module_16(D)); goto ; [100.00%] ;;succ: 5 And we lose, badly. The copy propagator is already aware that it has to be careful with context sensitive information getting copied over like this (alignment info), but it didn't have a case for non-null status which is also context sensitive. A fix is in testing now. And all that explains why the referenced change is the trigger. Prior to that change we used a specialized copy propagator which didn't try to copy the PTA information. After the change we use the standard copy propagator which copies the PTA information.
[Bug fortran/77632] [F08] Pointer initialisation does not quite work with arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77632 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #2) > Ugh. Looked at this briefly. AFAIK, the following is legal code: > > program foo >implicit none >real, target :: a >real, pointer :: b => a >if (associated(b, a) .eqv. .false.) stop 2 > end program foo > > This produces the wonderfully bad result: > > troutmask:sgk[296] gfcx -c a.f90 > f951: internal compiler error: in get, at cgraph.h:424 > 0x714635 symtab_node::get(tree_node const*) > ../../gccx/gcc/cgraph.h:424 > 0x714635 varpool_node::get(tree_node const*) > ../../gccx/gcc/cgraph.h:2617 > 0x714635 varpool_node::get_create(tree_node*) > ../../gccx/gcc/varpool.c:146 > 0x9c4667 record_reference > ../../gccx/gcc/cgraphbuild.c:82 > 0x9c4667 record_reference > ../../gccx/gcc/cgraphbuild.c:48 > 0x10bebd5 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), > void*, hash_set >*, > tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), > void*, hash_set >*)) > ../../gccx/gcc/tree.c:12151 > 0x9c4e95 record_references_in_initializer(tree_node*, bool) > ../../gccx/gcc/cgraphbuild.c:386 > 0x10fda2f varpool_node::analyze() > ../../gccx/gcc/varpool.c:528 > 0x9cabff analyze_functions > ../../gccx/gcc/cgraphunit.c:1180 > 0x9cbc63 symbol_table::finalize_compilation_unit() > ../../gccx/gcc/cgraphunit.c:2833 > Please submit a full bug report, > with preprocessed source if appropriate. > Please include the complete backtrace with any bug report. I have a patch that fixes this issue.
[Bug tree-optimization/90949] [9/10 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-20 CC||law at redhat dot com Ever confirmed|0 |1 --- Comment #1 from Jeffrey A. Law --- Yea, it looks like we don't have NULL in the points-to set for "module", as a result we think the "module" parameter can never be NULL and the check gets eliminated. I don't think the referenced change introduced the issue, but certainly could have taken a latent issue and made it active. Anyway, poking at it now.
[Bug tree-optimization/90913] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7341 since r272239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90913 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- Aww. OK, so this is when we vectorize the inner loop of an if-converted outer-loop, then the outer loop LOOP_VECTORIZED condition replaced with the versioning condition dispatches to the variant supposed to be _scalar_ and the fallback is the if-converted nested copy designed for vectorization. So re-using the if-conversion copy is only possible when loop_to_version is the inner loop or we are vectorizing the outer loop (I think we never do versioning on outer loops currently though). Testing patch.
[Bug c++/90926] [7/8/9/10 Regression] member char array with string literal initializer causes = {} to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90926 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.5
[Bug libstdc++/90920] [9 Regression] ABI incompatibility in std::rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90920 --- Comment #4 from Jonathan Wakely --- I did experiment with putting the range checks in *both* places, the std::rotate function and the std::__rotate helpers it calls. But there's still no guarantee you won't get a "bad" combination of definitions from objects built with e.g. 9.1 and 8.3 If we change the mangled names to make the "new" functions different that doesn't help, because the "old" functions will still be present in already-built objects. Basically nothing we can do will fix the code in already compiled objects. The only guaranteed way to avoid the problem is to recompile anything built with 9.1, and if you have to do that anyway, then the fix I put on trunk works fine. So I think I'll just backport the same fix, and 9.1 will be a blip.
[Bug libstdc++/90920] [9 Regression] ABI incompatibility in std::rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90920 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||rguenth at gcc dot gnu.org Known to work||10.0 Summary|[9/10 Regression] ABI |[9 Regression] ABI |incompatibility in |incompatibility in |std::rotate |std::rotate Known to fail|10.0| --- Comment #3 from Richard Biener --- Fixed on trunk. I think I rather prefer the one-off incompatibility in 9.1. Unless you can think of a solution not breaking compatibility with 9.1 of course.
[Bug c++/90916] [10 Regression] ICE in retrieve_specialization, at cp/pt.c:1258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90916 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/90916] [10 Regression] ICE in retrieve_specialization, at cp/pt.c:1258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90916 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/90915] [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90915 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |9.2
[Bug debug/90914] [10 Regression] ICE in schedule_generic_params_dies_gen, at dwarf2out.c:27153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90914 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED CC||patrickdepinguin at gmail dot com Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I'll see what I can do.
[Bug tree-optimization/90913] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7341 since r272239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90913 --- Comment #6 from Jakub Jelinek --- The ICE is because .MASK_LOAD/.MASK_STORE calls are supported just for vectors. The way it is done is that during ifcvt those internal calls are added to the .LOOP_VECTORIZED guarded loops, and either we successfully vectorize those, then the .MASK_LOAD/.MASK_STORE ifn calls are replaced with their vectorized versions and all the checking is performed, or we should DCE that loop. The r272239 change which I haven't really understood breaks this on this testcase, we end up with _116 = .LOOP_VECTORIZED (1, 4); if (_116 != 0) goto ; [100.00%] else goto ; [100.00%] that guards these scalar .MASK_STORE calls being replaced with _116 = 0; if (_190 != 0) goto ; [100.00%] else goto ; [100.00%] that is just wrong, we can't and shouldn't reuse the for vectorization only loop if we don't vectorize it. Both because of these .MASK* calls, but also because e.g. there are COND_EXPRs all around in that which often isn't beneficial in scalar loops, etc.
[Bug tree-optimization/90913] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7341 since r272239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90913
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Somewhat reduced:
! PR tree-optimization/90913
! { dg-do compile }
! { dg-options "-O3 -ffast-math" }
! { dg-additional-options "-mavx -mveclibabi=svml" { target i?86-*-* x86_64-*-*
} }
subroutine foo (a, b, c, d, e, f, g, h, k, l)
implicit none
integer :: d, e, f, g, i, j
real :: a, b(5,6), c(6), h(6,10,5), k(5,10,2), l(10,5), m, n, o
do i=1,5
do j=1,6
m=l(f,g)*log(c(j))
if (m<2) then
if (m<-2) then
h(j,f,g)=n
else
h(j,f,g)=o
endif
endif
b(i,j)=a+k(i,d,e)+k(i,1,e)**h(j,f,g)
enddo
enddo
write(*,'()')
end
[Bug middle-end/50481] builtin to reverse the bit order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #5 from Wilco --- Yes it would be good to have a generic builtin, this issue keeps coming up: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01187.html
[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Thu Jun 20 15:37:35 2019 New Revision: 272512 URL: https://gcc.gnu.org/viewcvs?rev=272512=gcc=rev Log: PR c++/87512 * g++.dg/cpp1z/inline-var7.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/inline-var7.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/54855] Unnecessary duplication when performing scalar operation on vector element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #11 from H.J. Lu --- Fixed for GCC 10.
[Bug tree-optimization/88828] Inefficient update of the first element of vector registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88828 Bug 88828 depends on bug 54855, which changed state. Bug 54855 Summary: Unnecessary duplication when performing scalar operation on vector element https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/90947] [9/10 Regression] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947
--- Comment #3 from Martin Sebor ---
The root cause of the problem is that initializer_zerop (elt_init) doesn't
differentiate between the empty string and a null pointer in the same
initializer list and returns true for the CONSTRUCTOR ({"", 0}).
[Bug tree-optimization/54855] Unnecessary duplication when performing scalar operation on vector element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54855 --- Comment #10 from hjl at gcc dot gnu.org --- Author: hjl Date: Thu Jun 20 15:30:54 2019 New Revision: 272511 URL: https://gcc.gnu.org/viewcvs?rev=272511=gcc=rev Log: i386: Generate standard floating point scalar operation patterns Standard floating point scalar operation patterns for combiner, which preserve the rest of the vector, look like (vec_merge:V2DF (vec_duplicate:V2DF (reg:DF 87)) (reg/v:V2DF 85 [ x ]) (const_int 1 [0x1])])) and (vec_merge:V2DF (vec_duplicate:V2DF (op:DF (vec_select:DF (reg/v:V2DF 85 [ x ]) (parallel [ (const_int 0 [0])])) (reg:DF 87)) (reg/v:V2DF 85 [ x ]) (const_int 1 [0x1])])) This patch adds and generates such standard floating point scalar operation patterns for +, -, *, /, > and <. Tested on x86-64. gcc/ PR target/54855 * config/i386/i386-expand.c (ix86_expand_vector_set): Generate standard scalar operation pattern for V2DF. * config/i386/sse.md (*_vm3): New. (*_vm3): Likewise. (*ieee_3): Likewise. (vec_setv2df_0): Likewise. gcc/testsuite/ PR target/54855 * gcc.target/i386/pr54855-1.c: New test. * gcc.target/i386/pr54855-2.c: Likewise. * gcc.target/i386/pr54855-3.c: Likewise. * gcc.target/i386/pr54855-4.c: Likewise. * gcc.target/i386/pr54855-5.c: Likewise. * gcc.target/i386/pr54855-6.c: Likewise. * gcc.target/i386/pr54855-7.c: Likewise. * gcc.target/i386/pr54855-8.c: Likewise. * gcc.target/i386/pr54855-9.c: Likewise. * gcc.target/i386/pr54855-10.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr54855-1.c trunk/gcc/testsuite/gcc.target/i386/pr54855-10.c trunk/gcc/testsuite/gcc.target/i386/pr54855-2.c trunk/gcc/testsuite/gcc.target/i386/pr54855-3.c trunk/gcc/testsuite/gcc.target/i386/pr54855-4.c trunk/gcc/testsuite/gcc.target/i386/pr54855-5.c trunk/gcc/testsuite/gcc.target/i386/pr54855-6.c trunk/gcc/testsuite/gcc.target/i386/pr54855-7.c trunk/gcc/testsuite/gcc.target/i386/pr54855-8.c trunk/gcc/testsuite/gcc.target/i386/pr54855-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-expand.c trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug libfortran/77278] Use LTO for libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #31 from Thomas Koenig ---
(
> this patch makes Fortran logicals to become C unsigned types of
> corresponding size. I think it is better than making them signed
> because the globbing will affect aliasing within Fortran programs as
> well.
I think you're right there, I was wondering about that problem
as well.
Do I understand correctly that this type merging only happens
if LTO is enabled, and does not affect performance otherwise?
We would then have to redefine the GFC_LOGICAL_* types
in libgfortran to unsigned, but that should be doable.
Regarding the test case: As it is, this will only work if
there is a 16-byte integer. It is probably better to
use only up to 8-byte logicals, and put in a separate
test case with the 16-byte logicals and put in
! { dg-require-effective-target fortran_integer_16 }
This is looking very good, thanks!
[Bug c++/90947] [9/10 Regression] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947
Martin Sebor changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Keywords||wrong-code
Last reconfirmed||2019-06-20
CC||msebor at gcc dot gnu.org
Resolution|DUPLICATE |---
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=89980
Ever confirmed|0 |1
Summary|Simple lookup table of |[9/10 Regression] Simple
|array of strings is |lookup table of array of
|miscompiled |strings is miscompiled
--- Comment #2 from Martin Sebor ---
This is actually a different bug in the same commit. A simpler test case is
this:
void f (void)
{
const char* a[2][2] = {
{ "0", "1" },
{ "", 0 }
};
if (!a[1][0]) // should be folded to false with -O
__builtin_abort ();
}
There is code in place to handle this kind of initialization:
/* Pointers initialized to strings must be treated as non-zero
even if the string is empty. */
tree init_type = TREE_TYPE (elt_init);
if ((POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type))
|| !initializer_zerop (elt_init))
last_nonzero = index;
This was added in r270177 to fix pr89980. Unfortunately, the handling is
incomplete and the test insufficient to expose it.
[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-06-20 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Fixed by r266055; adding the test.
[Bug c++/90490] [9/10 Regression] ICE on noexcept with decltype expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90490 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #5 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01241.html
[Bug c++/90950] OpenMP clause handling rejecting references to incomplete types in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90950 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-06-20 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/90950] New: OpenMP clause handling rejecting references to incomplete types in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90950
Bug ID: 90950
Summary: OpenMP clause handling rejecting references to
incomplete types in templates
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
template
T
foo (void)
{
T y = 0;
T = y;
#pragma omp parallel for lastprivate (x)
for (int i = 0; i < 8; ++i)
x = i;
return x;
}
int a = foo ();
is incorrectly rejected.
[Bug libstdc++/90770] Building with --enable-libstdcxx-debug and make profiledbootstrap fails with mv: cannot stat 'Makefile': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90770 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Thu Jun 20 14:17:57 2019 New Revision: 272509 URL: https://gcc.gnu.org/viewcvs?rev=272509=gcc=rev Log: Skip libstdc++ debug build in early bootstrap stages As mentioned in PR 90770, this is a patch that Debian have been carrying for some time. The additional unoptimized copies of libstdc++ libs that get built during each stage are never going to be used, so don't bother building them. For a profiled bootstrap this means we won't train the compiler on the unoptimized library code with assertions enabled, but that doesn't seem like a big problem, as the same code has already been compiled once for the main libstdc++ library. * acinclude.m4 (GLIBCXX_ENABLE_DEBUG): Only do debug build for final stage of bootstrap. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug c++/83413] that's a compiler bug, not something we can address. MAME is known to be buildable for other ARM targets (e.g. Raspberry Pi) right now so it appears to be an issue with whatever you're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83413 Marek Polacek changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Marek Polacek --- Looks invalid, closing.
[Bug libstdc++/90943] Visiting inherited variants no longer works in 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|SUSPENDED --- Comment #3 from Jonathan Wakely --- https://wg21.link/LWG3052 would forbid us from supporting this.
[Bug ipa/90939] ICE in meet_with, at ipa-cp.c:1073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90939 --- Comment #1 from Martin Jambor --- The assert is there since the original implementation of IPA known bits propagation which was done for integers only. Some two months later Prathamesh replaced propagation of alignment with moving alignment information through the known_bits infrastructure, but the assert remained. I'll propose a patch that will remove the assert. If bit_value_binop can deal with the situation, it will, otherwise it will be pessimistic (like in the case of MAX_EXPR, by the way).
[Bug libfortran/77278] Use LTO for libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #30 from Jan Hubicka ---
Hi,
this patch makes Fortran logicals to become C unsigned types of
corresponding size. I think it is better than making them signed
because the globbing will affect aliasing within Fortran programs as
well. We still ignore sign on chars and size_t, so this is still
throwing away some precision (i.e. LOGICAL of size 1 will become INTEGER
if size 1 for TBAA purposes)
Index: lto/lto-common.c
===
--- lto/lto-common.c(revision 272506)
+++ lto/lto-common.c(working copy)
@@ -238,6 +238,8 @@ hash_canonical_type (tree type)
types. */
gcc_checking_assert (type_with_alias_set_p (type));
+ type = type_for_canonical_type_merging (type);
+
/* Combine a few common features of types so that types are grouped into
smaller sets; when searching for existing matching types to merge,
only existing types having the same features as the new type will be
Index: testsuite/gfortran.dg/lto/bind_c-7_0.f90
===
--- testsuite/gfortran.dg/lto/bind_c-7_0.f90(nonexistent)
+++ testsuite/gfortran.dg/lto/bind_c-7_0.f90(working copy)
@@ -0,0 +1,33 @@
+! { dg-lto-do run }
+! { dg-lto-options {{ -O3 -flto }} }
+! this testcase tests additional interoperability of Fortran logical
+! that is not part of the standard but needed by libgfortran.
+program main
+ logical (kind=1) :: l1
+ logical (kind=2) :: l2
+ logical (kind=4) :: l4
+ logical (kind=8) :: l8
+ logical (kind=16) :: l16
+
+ l1 = .true.
+ l2 = .true.
+ l4 = .true.
+ l8 = .true.
+ call logical_c (l1, l2, l4, l8, l16)
+ if (l1 .or. l2 .or. l4 .or. l8 .or. l16) stop 1
+end program main
+
+subroutine foo(l1, l2, l4, l8, l16)
+ logical (kind=1) :: l1
+ logical (kind=2) :: l2
+ logical (kind=4) :: l4
+ logical (kind=8) :: l8
+ logical (kind=16) :: l16
+
+ l1 = .false.
+ l2 = .false.
+ l4 = .false.
+ l8 = .false.
+ l16 = .false.
+end subroutine foo
+
Index: testsuite/gfortran.dg/lto/bind_c-7_1.c
===
--- testsuite/gfortran.dg/lto/bind_c-7_1.c (nonexistent)
+++ testsuite/gfortran.dg/lto/bind_c-7_1.c (working copy)
@@ -0,0 +1,6 @@
+
+extern void foo_ (_Bool *l1, unsigned short *l2, unsigned int *l4, unsigned
long long *l8, unsigned __int128 *l16);
+void logical_c_ (_Bool *l1, unsigned short *l2, unsigned int *l4, unsigned
long long *l8, unsigned __int128 *l16)
+{
+ foo_ (l1, l2, l4, l8, l16);
+}
Index: tree.c
===
--- tree.c (revision 272506)
+++ tree.c (working copy)
@@ -14047,6 +14053,25 @@ type_with_interoperable_signedness (cons
|| TYPE_PRECISION (type) == TYPE_PRECISION (size_type_node));
}
+/* Return type replacing TYPE for canonical type merging.
+
+ We translate BOOLEAN_TYPE of size different from C _Bool to
+ unsigned integers. This makes it possible to interoperate C
+ and Fortran on Fortran's LOGICAL types which come in different
+ sizes. This is not required by the language standard but
+ used by libgfortran. */
+
+extern tree
+type_for_canonical_type_merging (const_tree type)
+{
+ if (TREE_CODE (type) == BOOLEAN_TYPE
+ && !tree_int_cst_equal (TYPE_SIZE (type),
+ TYPE_SIZE (boolean_type_node)))
+return lang_hooks.types.type_for_mode (TYPE_MODE (type),
+ true);
+ return const_cast (type);
+}
+
/* Return true iff T1 and T2 are structurally identical for what
TBAA is concerned.
This function is used both by lto.c canonical type merging and by the
@@ -14066,6 +14091,8 @@ gimple_canonical_types_compatible_p (con
t1 = TYPE_MAIN_VARIANT (t1);
t2 = TYPE_MAIN_VARIANT (t2);
}
+ t1 = type_for_canonical_type_merging (t1);
+ t2 = type_for_canonical_type_merging (t2);
/* Check first for the obvious case of pointer identity. */
if (t1 == t2)
Index: tree.h
===
--- tree.h (revision 272506)
+++ tree.h (working copy)
@@ -5132,9 +5141,10 @@ extern void DEBUG_FUNCTION verify_type (
extern bool gimple_canonical_types_compatible_p (const_tree, const_tree,
bool trust_type_canonical =
true);
extern bool type_with_interoperable_signedness (const_tree);
+extern tree type_for_canonical_type_merging (const_tree type);
extern bitmap get_nonnull_args (const_tree);
extern int get_range_pos_neg (tree);
/* Return simplified tree code of type that is used for canonical type
merging. */
inline enum tree_code
[Bug sanitizer/90865] ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865 --- Comment #7 from Martin Liška --- (In reply to sshannin from comment #6) > Since we all agree that the current behavior is undesirable and since Jakub > proposes a possible solution, would it be reasonable to reopen this? > > For large (multi-hour) test suites, it would be meaningfully helpful to be > able to run a single time using a binary instrumented for both sanitizers > and coverage rather than having to run through the tests multiple times with > different binaries because ubsan makes gcov's output useless. Yes please.
[Bug c++/90490] [9/10 Regression] ICE on noexcept with decltype expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90490 --- Comment #4 from Marek Polacek --- I have a patch now.
[Bug c++/89873] internal compiler error: unexpected expression of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89873 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c++/89873] internal compiler error: unexpected expression of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89873 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Thu Jun 20 12:22:25 2019 New Revision: 272507 URL: https://gcc.gnu.org/viewcvs?rev=272507=gcc=rev Log: PR c++/89873 * g++.dg/cpp1y/noexcept1.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/noexcept1.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/90865] ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865 --- Comment #6 from sshannin at gmail dot com --- Since we all agree that the current behavior is undesirable and since Jakub proposes a possible solution, would it be reasonable to reopen this? For large (multi-hour) test suites, it would be meaningfully helpful to be able to run a single time using a binary instrumented for both sanitizers and coverage rather than having to run through the tests multiple times with different binaries because ubsan makes gcov's output useless.
[Bug c++/89873] internal compiler error: unexpected expression of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89873 --- Comment #2 from Marek Polacek --- And fixed by r270319.
[Bug fortran/90937] [7/8/9 Regression] ICE: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937 Thomas Koenig changed: What|Removed |Added Summary|[7/8/9/10 Regression] ICE: |[7/8/9 Regression] ICE: in |in gfc_get_symbol_decl, at |gfc_get_symbol_decl, at |fortran/trans-decl.c:1538 |fortran/trans-decl.c:1538 --- Comment #6 from Thomas Koenig --- Fixed on trunk so far.
[Bug fortran/90937] [7/8/9/10 Regression] ICE: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Thu Jun 20 11:56:50 2019 New Revision: 272506 URL: https://gcc.gnu.org/viewcvs?rev=272506=gcc=rev Log: 2019-06-20 Thomas Koenig PR fortran/90937 * trans-types.c (get_formal_from_actual_arglist): Get symbol from current namespace so it will be freed later. If symbol is of type character, get an empty character length. 2019-06-20 Thomas Koenig PR fortran/90937 * gfortran.dg/external_procedure_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/external_procedure_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/90859] [OMP] Mappings for VLA different depending on 'target { c && { ! lp64 } }'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90859 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-20 Ever confirmed|0 |1 --- Comment #2 from Thomas Schwinge --- Experimenting on x86_64-pc-linux-gnu with '-m32', this depends on the data type used for 'array_so'. If I change 'uint32_t' to 'unsigned int', I see the same strange behavior. If however I change it to 'unsigned long', the issue goes away, as it does for 'unsigned short', for example. The code inside the region is the same (aside from some type casting); in particular there aren't any 'array' references. Per 'gcc-testresults' received so far, the issue does not appear (thus, 'FAIL' for this 'scan-tree-dump') on powerpc-ibm-aix7.2.0.0, aarch64-suse-linux-gnu with '-mabi=ilp32' (manually confirmed), s390x-ibm-linux-gnu with '-m31', i686-apple-darwin9, powerpc-apple-darwin9, x86_64-apple-darwin16, x86_64-apple-darwin17.
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938
--- Comment #6 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #4)
> Yes, the problem is that triviality isn't sufficient to decide whether the
> transformation can be enabled. I think we need to check whether the type
> has a trivial default ctor. Maybe like this:
>
> --- gcc/cp/decl.c (revision 272482)
> +++ gcc/cp/decl.c (working copy)
> @@ -5853,7 +5853,7 @@ reshape_init_array_1 (tree elt_type, tree max_inde
> break;
> }
>
> - if (sized_array_p && trivial_type_p (elt_type))
> + if (sized_array_p && type_has_nontrivial_default_init (elt_type))
Is that backwards? That checks whether it has a non-trivial default ctor.
But I think that's still wrong, as comment 3 shows, the transformation can go
from calling a non-trivial ctor to something completely different. If the type
has any user-defined constructors then you can't assume that a zero initializer
is default init.
Also, the testcase from PR 90947 is miscompiled with an array of pointers,
which are definitely trivial and don't have a non-trivial default ctor.
#include
#include
static const char *vector_swizzle(int vecsize, int index)
{
static const char *swizzle[4][4] = {
{ ".x", ".y", ".z", ".w" },
{ ".xy", ".yz", ".zw", nullptr },
{ ".xyz", ".yzw", nullptr, nullptr },
{ "", nullptr, nullptr, nullptr },
};
assert(vecsize >= 1 && vecsize <= 4);
assert(index >= 0 && index < 4);
assert(swizzle[vecsize - 1][index]);
return swizzle[vecsize - 1][index];
}
int main()
{
puts(vector_swizzle(4, 0));
}
[Bug c++/90938] [9/10 Regression] Initializing array with {1} works, but not {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90938 Jonathan Wakely changed: What|Removed |Added CC||maister at archlinux dot us --- Comment #5 from Jonathan Wakely --- *** Bug 90947 has been marked as a duplicate of this bug. ***
[Bug c++/90947] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- This started with r270155 so is a dup of PR 90938 *** This bug has been marked as a duplicate of bug 90938 ***
[Bug tree-optimization/90949] New: [9/10 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949
Bug ID: 90949
Summary: [9/10 Regression] null pointer check removed
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: law at gcc dot gnu.org
Target Milestone: ---
From
https://stackoverflow.com/questions/56655137/undefined-behaviour-or-gcc-optimization-bug
int puts(const char*);
void free(void*);
void* malloc(unsigned long);
#define NULL 0
struct Node
{
struct Node* child;
};
void walk(struct Node* module, int cleanup)
{
if (module == NULL) {
return;
}
if (!cleanup) {
puts("No cleanup");
}
walk(module->child, cleanup);
if (cleanup) {
free(module);
}
}
int main()
{
struct Node* node = malloc(sizeof(struct Node));
node->child = NULL;
walk(node, 1);
}
This crashes when compiled with -O1 -foptimize-sibling-calls -ftree-vrp since
r270574
PR tree-optimization/90037
* Makefile.in (OBJS): Remove tree-ssa-phionlycprop.c
* passes.def: Replace all instance of phi-only cprop with the
lattice propagator. Move propagation pass from after erroneous
path isolation to before erroneous path isolation.
* tree-ssa-phionlycprop.c: Remove.
* gcc.dg/tree-ssa/20030710-1.c: Update dump file to scan.
* gcc.dg/isolate-2.c: Likewise.
* gcc.dg/isolate-4.c: Likewise.
* gcc.dg/pr19431.c: Accept either ordering of PHI args.
* gcc.dg/pr90037.c: New test.
[Bug fortran/90948] New: Polymorphic intrinsic assignment...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90948 Bug ID: 90948 Summary: Polymorphic intrinsic assignment... Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jplatas at ull dot edu.es Target Milestone: --- Hi I'm having problem with polymorphic intrinsic assignment. This version fails the compilation in gfortran. The message is: F:\GIT_ILL>gfortran -c example2.f90 example2.f90:38:9: local%atom(i)=list%atom(i) 1 Error: Nonallocatable variable must not be polymorphic in intrinsic assignment at (1) - check that there is a matching specific subroutine for '=' operator Under my opinion it would be ok. Javier Program Check implicit none !> Type definitions Type :: Atm_Type End Type Atm_Type Type, extends (Atm_type) :: Atm_Std_Type End Type Atm_Std_Type Type, extends (Atm_std_type) :: Atm_Ref_Type End Type Atm_Ref_Type Type :: AtList_Type integer:: Natoms class(Atm_Type), dimension(:), allocatable :: Atom end Type AtList_Type !> Variables type(AtList_Type) :: list call sub(list) Contains Subroutine Sub(List) ! Argument ! type (AtList_Type), intent(in out) :: List ! Local Variables ! integer:: i type (AtList_Type) :: local if (List%natoms <= 0 ) return allocate(local%atom(List%natoms)) do i=1, List%natoms local%atom(i)=list%atom(i) end do End Subroutine Sub End Program Check
[Bug c++/90947] New: Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947
Bug ID: 90947
Summary: Simple lookup table of array of strings is miscompiled
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maister at archlinux dot us
Target Milestone: ---
On GCC 9.1.0, this snippet is miscompiled:
#include
#include
#include
static const char *vector_swizzle(int vecsize, int index)
{
static const char *swizzle[4][4] = {
{ ".x", ".y", ".z", ".w" },
{ ".xy", ".yz", ".zw", nullptr },
{ ".xyz", ".yzw", nullptr, nullptr },
{ "", nullptr, nullptr, nullptr },
};
assert(vecsize >= 1 && vecsize <= 4);
assert(index >= 0 && index < 4);
assert(swizzle[vecsize - 1][index]);
return swizzle[vecsize - 1][index];
}
int main(int argc, char **argv)
{
puts(vector_swizzle(atoi(argv[1]), atoi(argv[2])));
}
Compiled with "g++ -o test test.cpp", and ran with ./test 4 0, and it asserts.
The last array entry of swizzle[3] are all nullptr for some reason. No other
compiler behaves like this.
[Bug fortran/90937] [7/8/9/10 Regression] ICE: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug c++/90925] gcc allows calling private overridden operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90925 --- Comment #4 from Jonathan Wakely --- Right. Just because all your code examples use "template" and "private" doesn't make them related.
[Bug libstdc++/90943] Visiting inherited variants no longer works in 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-06-20 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.2 Ever confirmed|0 |1
[Bug tree-optimization/89296] [7 Regression] tree copy-header masking uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89296 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Christophe Lyon --- I think we can close this bug.
[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 89296, which changed state. Bug 89296 Summary: [7 Regression] tree copy-header masking uninitialized warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89296 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
