[Bug c++/99310] [11/12 Regression] ICE: canonical types differ for identical types 'void (A::)(void*)' and 'void (A::)(void*)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99310 --- Comment #3 from Arseny Solokha --- I cannot reproduce it w/ gcc-12.0.0-alpha20210919 snapshot (g:32731fa5b0abf092029b8e2be64319b978bda514).
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org Component|testsuite |target --- Comment #18 from Andrew Pinski --- Never mind because it requires more thought on the side of the x86 headers.
[Bug testsuite/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 Andrew Pinski changed: What|Removed |Added Keywords|wrong-code | Status|NEW |ASSIGNED --- Comment #17 from Andrew Pinski --- The code is not wrong, just the testcase is written such a way it thinks it can get away with not using avx code which is not always going to be true. I have a patch which fixes avx-check.h, avx2-check.h, and avx512-check.h. Obvious it just accidently works really.
[Bug testsuite/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
Andrew Pinski changed:
What|Removed |Added
Component|target |testsuite
--- Comment #16 from Andrew Pinski ---
> > > FAIL: gcc.target/i386/avx512bw-pr70329-1.c execution test
> > > FAIL: gcc.target/i386/pr96814.c execution test
That seems like a testsuite issue.
main and check_osxsave don't turn off AVX512f.
This should fix the issue to the testsuite:
diff --git a/gcc/testsuite/gcc.target/i386/avx512-check.h
b/gcc/testsuite/gcc.target/i386/avx512-check.h
index 0ad9064f637..212dcea7600 100644
--- a/gcc/testsuite/gcc.target/i386/avx512-check.h
+++ b/gcc/testsuite/gcc.target/i386/avx512-check.h
@@ -25,6 +25,8 @@ do_test (void)
}
#endif
+static int
+check_osxsave (void) __attribute__((target("no-avx")));
static int
check_osxsave (void)
{
@@ -34,6 +36,8 @@ check_osxsave (void)
return (ecx & bit_OSXSAVE) != 0;
}
+int
+main () __attribute__((target("no-avx")));
int
main ()
{
[Bug c/32122] indirect goto to an integer accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32122 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-Septemb ||er/579792.html --- Comment #6 from Andrew Pinski --- Patch finally submitted: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579792.html
[PATCH] c: [PR32122] Require pointer types for computed gotos
From: Andrew Pinski
So GCC has always accepted non-pointer types in computed gotos but
that was wrong based on the documentation:
Any expression of type void * is allowed.
So this fixes the problem by requiring the type to
be a pointer type.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR c/32122
gcc/c/ChangeLog:
* c-parser.c (c_parser_statement_after_labels): Pass
the c_expr instead of the tree to c_finish_goto_ptr.
* c-typeck.c (c_finish_goto_ptr): Change the second
argument type to c_expr.
* c-tree.h (c_finish_goto_ptr): Likewise.
Error out if the expression was not of a pointer type.
gcc/testsuite/ChangeLog:
* gcc.dg/comp-goto-5.c: New test.
* gcc.dg/comp-goto-6.c: New test.
---
gcc/c/c-parser.c | 2 +-
gcc/c/c-tree.h | 2 +-
gcc/c/c-typeck.c | 11 ++-
gcc/testsuite/gcc.dg/comp-goto-5.c | 11 +++
gcc/testsuite/gcc.dg/comp-goto-6.c | 6 ++
5 files changed, 29 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/comp-goto-5.c
create mode 100644 gcc/testsuite/gcc.dg/comp-goto-6.c
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index fb1399e300d..bcd8a05489f 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -6141,7 +6141,7 @@ c_parser_statement_after_labels (c_parser *parser, bool
*if_p,
c_parser_consume_token (parser);
val = c_parser_expression (parser);
val = convert_lvalue_to_rvalue (loc, val, false, true);
- stmt = c_finish_goto_ptr (loc, val.value);
+ stmt = c_finish_goto_ptr (loc, val);
}
else
c_parser_error (parser, "expected identifier or %<*%>");
diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h
index d50d0cb7f2d..a046c6b0926 100644
--- a/gcc/c/c-tree.h
+++ b/gcc/c/c-tree.h
@@ -746,7 +746,7 @@ extern tree c_finish_expr_stmt (location_t, tree);
extern tree c_finish_return (location_t, tree, tree);
extern tree c_finish_bc_stmt (location_t, tree, bool);
extern tree c_finish_goto_label (location_t, tree);
-extern tree c_finish_goto_ptr (location_t, tree);
+extern tree c_finish_goto_ptr (location_t, c_expr val);
extern tree c_expr_to_decl (tree, bool *, bool *);
extern tree c_finish_omp_construct (location_t, enum tree_code, tree, tree);
extern tree c_finish_oacc_data (location_t, tree, tree);
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 49d1bb067a0..b472e448011 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -10783,10 +10783,19 @@ c_finish_goto_label (location_t loc, tree label)
the GOTO. */
tree
-c_finish_goto_ptr (location_t loc, tree expr)
+c_finish_goto_ptr (location_t loc, c_expr val)
{
+ tree expr = val.value;
tree t;
pedwarn (loc, OPT_Wpedantic, "ISO C forbids %");
+ if (expr != error_mark_node
+ && !POINTER_TYPE_P (TREE_TYPE (expr))
+ && !null_pointer_constant_p (expr))
+{
+ error_at (val.get_location (),
+ "computed goto must be pointer type");
+ expr = build_zero_cst (ptr_type_node);
+}
expr = c_fully_fold (expr, false, NULL);
expr = convert (ptr_type_node, expr);
t = build1 (GOTO_EXPR, void_type_node, expr);
diff --git a/gcc/testsuite/gcc.dg/comp-goto-5.c
b/gcc/testsuite/gcc.dg/comp-goto-5.c
new file mode 100644
index 000..d487729a5d4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/comp-goto-5.c
@@ -0,0 +1,11 @@
+/* PR c/32122 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+enum {a=1};
+void foo()
+{
+ goto *
+a; /* { dg-error "computed goto must be pointer type" } */
+}
+
diff --git a/gcc/testsuite/gcc.dg/comp-goto-6.c
b/gcc/testsuite/gcc.dg/comp-goto-6.c
new file mode 100644
index 000..497f6cd76ca
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/comp-goto-6.c
@@ -0,0 +1,6 @@
+/* PR c/32122 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+void foo(void *a) { goto *1000; } /* { dg-error "computed goto must be
pointer type" } */
+void foo1(void *a) { goto *a; }
+
--
2.17.1
[PATCH, Fortran] Fix testcases that violate C838, + revealed ICE
This patch fixes 3 testcases that violate F2018 C838 by passing an
assumed-rank argument to a procedure via an assumed-sized dummy, by
wrapping the call in a SELECT RANK construct. But wait, there's more!
This triggered an ICE due to a null pointer dereference in the code that
handles the associated variable in the SELECT RANK. I fixed that by
copying the idiom used in other places for GFC_DECL_SAVED_DESCRIPTOR, so
now all the tests pass again.
Is this OK to commit? I confess I'm not certain whether adding the
SELECT RANK causes the testcases now to do something different from what
they were originally trying to test, but they never should have worked
as originally written anyway. We were just not previously diagnosing
the C838 violations without the other patch I just posted to do that.
-Sandra
commit dd48922d40542eb1b9d17a78fcb3a7cfb857d555
Author: Sandra Loosemore
Date: Sun Sep 19 17:23:58 2021 -0700
Fortran: Fix testcases that violate C838, + revealed ICE
The three test cases fixed in this patch violated F2018 C838, which
only allows passing an assumed-rank argument to an assumed-rank dummy.
Wrapping the call in "select rank" revealed a null pointer dereference
which is fixed by guarding the use of the result of
GFC_DECL_SAVED_DESCRIPTOR similar to what is already done elsewhere.
2021-09-19 Sandra Loosemore
gcc/fortran/
* trans-stmt.c (trans_associate_var): Check that result of
GFC_DECL_SAVED_DESCRIPTOR is not null before using it.
gcc/testsuite/
* gfortran.dg/assumed_rank_18.f90 (g): Wrap call to h in
select rank.
* gfortran.dg/assumed_type_10.f90 (test_array): Likewise for
call to test_lib.
* gfortran.dg/assumed_type_11.f90 (test_array): Likewise.
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 11df186..a8ff473 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -1788,9 +1788,10 @@ trans_associate_var (gfc_symbol *sym, gfc_wrapped_block *block)
/* Go straight to the class data. */
if (sym2->attr.dummy && !sym2->attr.optional)
{
- class_decl = DECL_LANG_SPECIFIC (sym2->backend_decl) ?
- GFC_DECL_SAVED_DESCRIPTOR (sym2->backend_decl) :
- sym2->backend_decl;
+ class_decl = sym2->backend_decl;
+ if (DECL_LANG_SPECIFIC (class_decl)
+ && GFC_DECL_SAVED_DESCRIPTOR (class_decl))
+ class_decl = GFC_DECL_SAVED_DESCRIPTOR (class_decl);
if (POINTER_TYPE_P (TREE_TYPE (class_decl)))
class_decl = build_fold_indirect_ref_loc (input_location,
class_decl);
diff --git a/gcc/testsuite/gfortran.dg/assumed_rank_18.f90 b/gcc/testsuite/gfortran.dg/assumed_rank_18.f90
index a8fa3ff..0bc419a 100644
--- a/gcc/testsuite/gfortran.dg/assumed_rank_18.f90
+++ b/gcc/testsuite/gfortran.dg/assumed_rank_18.f90
@@ -7,7 +7,10 @@ program p
contains
subroutine g(x)
real :: x(..)
- call h(x)
+ select rank (x)
+rank (1)
+ call h(x)
+ end select
end
subroutine h(x)
real :: x(*)
diff --git a/gcc/testsuite/gfortran.dg/assumed_type_10.f90 b/gcc/testsuite/gfortran.dg/assumed_type_10.f90
index bf0c873..a8bbf2d 100644
--- a/gcc/testsuite/gfortran.dg/assumed_type_10.f90
+++ b/gcc/testsuite/gfortran.dg/assumed_type_10.f90
@@ -31,7 +31,10 @@ contains
subroutine test_array (a)
use iso_c_binding, only: c_size_t
class(*), dimension(..), target :: a
-call test_lib (a, int (sizeof (a), kind=c_size_t))
+select rank (a)
+ rank (1)
+call test_lib (a, int (sizeof (a), kind=c_size_t))
+end select
end subroutine
end module
diff --git a/gcc/testsuite/gfortran.dg/assumed_type_11.f90 b/gcc/testsuite/gfortran.dg/assumed_type_11.f90
index df6572d..391fa0d 100644
--- a/gcc/testsuite/gfortran.dg/assumed_type_11.f90
+++ b/gcc/testsuite/gfortran.dg/assumed_type_11.f90
@@ -31,7 +31,10 @@ contains
subroutine test_array (a)
use iso_c_binding, only: c_size_t
class(*), dimension(..), target :: a
-call test_lib (a, int (sizeof (a), kind=c_size_t))
+select rank (a)
+ rank (1)
+call test_lib (a, int (sizeof (a), kind=c_size_t))
+end select
end subroutine
end module
[PATCH, Fortran] Fixes for F2018 C838 (PR fortran/101334)
This patch fixes some bugs in handling of assumed-rank arguments
revealed by the TS29113 testsuite, allowing xfails to be removed from
those testcases. It was previously failing to diagnose an error when
passing an assumed-rank argument to a procedure via a non-assumed-rank
dummy, and giving a bogus error when passing one as the first argument
to the ASSOCIATED intrinsic. Both fixes turned out to be 1-liners. OK
to commit?
-Sandra
commit b967fe5f88a5245163f235cfa6a5808aa41e88f4
Author: Sandra Loosemore
Date: Sun Sep 19 17:32:03 2021 -0700
Fortran: Fixes for F2018 C838 (PR fortran/101334)
The compiler was failing to diagnose the error required by F2018 C838
when passing an assumed-rank array argument to a non-assumed-rank dummy.
It was also incorrectly giving an error for calls to the 2-argument form
of the ASSOCIATED intrinsic, which is supposed to be permitted by C838.
2021-09-19 Sandra Loosemore
PR fortran/101334
gcc/fortran/
* check.c (gfc_check_associated): Allow an assumed-rank
array for the pointer argument.
* interface.c (compare_parameter): Also give rank mismatch
error on assumed-rank array.
gcc/testsuite/
* testsuite/gfortran.dg/c-interop/c535b-2.f90: Remove xfails.
* testsuite/gfortran.dg/c-interop/c535b-3.f90: Likewise.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 851af1b..f31ad68 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1520,7 +1520,9 @@ gfc_check_associated (gfc_expr *pointer, gfc_expr *target)
t = true;
if (!same_type_check (pointer, 0, target, 1, true))
t = false;
- if (!rank_check (target, 0, pointer->rank))
+ /* F2018 C838 explicitly allows an assumed-rank variable as the first
+ argument of intrinsic inquiry functions. */
+ if (pointer->rank != -1 && !rank_check (target, 0, pointer->rank))
t = false;
if (target->rank > 0)
{
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 9e3e8aa..f9a7c9c 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2634,7 +2634,9 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
&& formal->as->type == AS_ASSUMED_SHAPE))
&& actual->expr_type != EXPR_NULL)
|| (actual->rank == 0 && formal->attr.dimension
- && gfc_is_coindexed (actual)))
+ && gfc_is_coindexed (actual))
+ /* Assumed-rank actual argument; F2018 C838. */
+ || actual->rank == -1)
{
if (where
&& (!formal->attr.artificial || (!formal->maybe_array
diff --git a/gcc/testsuite/gfortran.dg/c-interop/c535b-2.f90 b/gcc/testsuite/gfortran.dg/c-interop/c535b-2.f90
index 7bff14f..2dafd44 100644
--- a/gcc/testsuite/gfortran.dg/c-interop/c535b-2.f90
+++ b/gcc/testsuite/gfortran.dg/c-interop/c535b-2.f90
@@ -61,15 +61,14 @@ subroutine test_calls (x, y)
! assumed-rank dummies
call g (x, y) ! OK
! assumed-size dummies
- call h (x, & ! { dg-error "(A|a)ssumed.rank" "pr101334" { xfail *-*-* } }
+ call h (x, & ! { dg-error "(A|a)ssumed.rank" "pr101334" }
y) ! { dg-error "(A|a)ssumed.rank" "pr101337, failure to diagnose both operands" { xfail *-*-*} }
! assumed-shape dummies
call i (x, & ! { dg-error "(A|a)ssumed.rank" }
y) ! { dg-error "(A|a)ssumed.rank" "pr101337, failure to diagnose both operands" { xfail *-*-*} }
! fixed-size array dummies
- call j (x, & ! { dg-error "(A|a)ssumed.rank" "pr101334" { xfail *-*-* } }
+ call j (x, & ! { dg-error "(A|a)ssumed.rank" "pr101334" }
y) ! { dg-error "(A|a)ssumed.rank" "pr101337, failure to diagnose both operands" { xfail *-*-*} }
- ! { dg-bogus "Actual argument contains too few elements" "pr101334" { xfail *-*-* } .-2 }
end subroutine
! Check that you can't use an assumed-rank array variable in an array
diff --git a/gcc/testsuite/gfortran.dg/c-interop/c535b-3.f90 b/gcc/testsuite/gfortran.dg/c-interop/c535b-3.f90
index 6427bd6..23862e5 100644
--- a/gcc/testsuite/gfortran.dg/c-interop/c535b-3.f90
+++ b/gcc/testsuite/gfortran.dg/c-interop/c535b-3.f90
@@ -29,7 +29,7 @@ function test_associated3 (a, b)
integer, target :: b
logical :: test_associated3
- test_associated3 = associated (a, b) ! { dg-bogus "must be of rank -1" "pr101334" { xfail *-*-* } }
+ test_associated3 = associated (a, b) ! { dg-bogus "must be of rank -1" "pr101334" }
end function
function test_associated4 (a, b)
@@ -38,7 +38,7 @@ function test_associated4 (a, b)
integer, target :: b(:)
logical :: test_associated4
- test_associated4 = associated (a, b) ! { dg-bogus "must be of rank -1" "pr101334" { xfail *-*-* } }
+ test_associated4 = associated (a, b) ! { dg-bogus "must be of rank -1" "pr101334" }
end function
function test_associated5 (a, b)
@@ -47,7 +47,7 @@ function test_associated5 (a, b)
integer, target :: b(20)
logical :: test_associated5
- test_associated5 = associated (a, b) ! { dg-bogus "must be of rank -1" "pr101334" { xfail *-*-* } }
[Bug c/35980] The canonical type of types with may_alias attribute is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35980 --- Comment #1 from Andrew Pinski --- Hmm, we used to warn (error out for -pedantic-errors) for: typedef int __attribute__((may_alias)) mytype; mytype a; int *p = But starting in GCC 7, we no longer do.
[Bug c/101312] ICE with -g and may_alias and const array type with no bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101312 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70029 Last reconfirmed||2021-09-20 --- Comment #2 from Andrew Pinski --- The check was disabled before GCC 8 due to PR 70029 (reenabled by r8-3050; disabled by r6-7849). Also this ICEs with -fchecking from GCC 8+ (due the test being reenabled).
[Bug c/96546] [9/10/11/12 Regression] ICE in default_conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96546 Andrew Pinski changed: What|Removed |Added Known to fail||4.8.0 Keywords||ice-on-invalid-code Target Milestone|--- |9.5 Summary|ICE in default_conversion |[9/10/11/12 Regression] ICE ||in default_conversion Known to work||4.5.3, 4.6.4, 4.7.1, 4.7.4 --- Comment #2 from Andrew Pinski --- GCC 4.7.x did not ICE
[Bug c/86217] option aux-info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86217 --- Comment #2 from Andrew Pinski --- This seems this has always been this way (from 1992 or so).
[Bug c/86217] option aux-info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86217 --- Comment #1 from Andrew Pinski --- The const part is twice as the decl has TREE_READONLY set to true and the type has TYPE_READONLY is set to true.
[Bug c/44257] typeof(*(struct undefined *)) fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44257 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88827 --- Comment #1 from Andrew Pinski --- Fixed for GCC 10+, most likely by r10-5166 (aka PR 88827).
[Bug c/92935] typeof() on an atomic type doesn't always return the corresponding unqualified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92935 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |11.0
[Bug c/98047] assignment does not drop qualifier as observed by typeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98047 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |11.0
[Bug c/89495] [9 Regression] gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89495 Andrew Pinski changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 86137 has been marked as a duplicate of this bug. ***
[Bug c/86137] ubsan runtime error in c-format.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86137 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Fixed already. Dup of bug 89495. *** This bug has been marked as a duplicate of bug 89495 ***
[Bug c/81050] ICE with -fexec-charset=utf-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81050 Andrew Pinski changed: What|Removed |Added CC||rmansfield at qnx dot com --- Comment #5 from Andrew Pinski --- *** Bug 60368 has been marked as a duplicate of this bug. ***
[Bug preprocessor/60368] ICE on not unibyte character in execution character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60368 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 81050. *** This bug has been marked as a duplicate of bug 81050 ***
[Bug c/81050] ICE with -fexec-charset=utf-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81050 --- Comment #4 from Andrew Pinski --- clang rejects it: clang-14: error: invalid value 'utf-16' in '-fexec-charset=utf-16'
[Bug c/43027] #pragma rejected inside enum defn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43027 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-19 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70811 Ever confirmed|0 |1 Keywords||rejects-valid --- Comment #6 from Andrew Pinski --- Confirmed. definitely related to PR 70811.
[Bug middle-end/69130] explicit atomic ops treating non-constant memory orders as memory_order_seq_cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69130 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization Component|c |middle-end
[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 102403, which changed state. Bug 102403 Summary: [12 Regression] ICE in in init_from_control_deps, at gimple-predicate-analysis.cc:2364 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102403 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/102403] [12 Regression] ICE in in init_from_control_deps, at gimple-predicate-analysis.cc:2364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102403 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Thanks for the additional test case! The problem should be fixed now.
[Bug middle-end/102243] [12 Regression] ICE in get_range_query since r12-3300-gece28da924dd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102243 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Sebor --- Fixed in r12-3673.
[committed] avoid assuming cfun is nonnull [PR102243]
After the front end passes control to the middle end cfun is never
null (I'm pretty sure) but when a middle end helper is called
from the C++ front end cfun can be null for a namespace scope
initializer expression. A recent change of mine to the helper
introduced an assumption to the contrary, causing an ICE. In
r12-3673 I've committed the trivial fix below to correct this
mistake
Martin
Handle null cfun [PR102243].
Resolves:
PR middle-end/102243 - ICE on placement new at global scope
gcc/ChangeLog:
PR middle-end/102243
* tree-ssa-strlen.c (get_range): Handle null cfun.
gcc/testsuite/ChangeLog:
PR middle-end/102243
* g++.dg/warn/Wplacement-new-size-10.C: New test.
---
gcc/testsuite/g++.dg/warn/Wplacement-new-size-10.C | 13 +
gcc/tree-ssa-strlen.c | 14 ++
2 files changed, 23 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wplacement-new-size-10.C
diff --git a/gcc/testsuite/g++.dg/warn/Wplacement-new-size-10.C
b/gcc/testsuite/g++.dg/warn/Wplacement-new-size-10.C
new file mode 100644
index 000..6b71a832a30
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wplacement-new-size-10.C
@@ -0,0 +1,13 @@
+/* PR middle-end/102243 - ICE on placement new at global scope
+ { dg-do compile }
+ { dg-options "-Wall" } */
+
+void *operator new (__SIZE_TYPE__, void *);
+
+char a[2][sizeof (int)];
+
+int *p = new (a[1]) int;
+
+void *operator new[] (__SIZE_TYPE__, void *p) { return p; }
+
+int *q = new (a[1]) int[1];
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 7c93958e9ad..7c568a42d49 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -199,16 +199,22 @@ static bool handle_assign (gimple_stmt_iterator *,
tree, bool *,
/* Sets MINMAX to either the constant value or the range VAL is in
and returns either the constant value or VAL on success or null
- when the range couldn't be determined. Uses RVALS when nonnull
- to determine the range, otherwise uses CFUN or global range info,
- whichever is nonnull. */
+ when the range couldn't be determined. Uses RVALS or CFUN for
+ range info, whichever is nonnull. */
tree
get_range (tree val, gimple *stmt, wide_int minmax[2],
range_query *rvals /* = NULL */)
{
if (!rvals)
-rvals = get_range_query (cfun);
+{
+ if (!cfun)
+ /* When called from front ends for global initializers CFUN
+ may be null. */
+ return NULL_TREE;
+
+ rvals = get_range_query (cfun);
+}
value_range vr;
if (!rvals->range_of_expr (vr, val, stmt))
--
2.27.0
Re: [PATCH] introduce predicate analysis class
On 9/18/21 3:14 PM, Martin Sebor wrote: On 9/18/21 12:46 PM, Martin Sebor wrote: On 9/17/21 10:08 PM, Jeff Law wrote: On 9/17/2021 4:05 PM, Martin Sebor wrote: On 9/2/21 10:28 AM, Jeff Law via Gcc-patches wrote: On 8/30/2021 2:03 PM, Martin Sebor via Gcc-patches wrote: The predicate analysis subset of the tree-ssa-uninit pass isn't necessarily specific to the detection of uninitialized reads. Suitably parameterized, the same core logic could be used in other warning passes to improve their S/N ratio, or issue more nuanced diagnostics (e.g., when an invalid access cannot be ruled out but also need not in reality be unavoidable, issue a "may be invalid" type of warning rather than "is invalid"). Separating the predicate analysis logic from the uninitialized pass and exposing a narrow API should also make it easier to understand and evolve each part independently of the other, or replace one with a better implementation without modifying the other.(*) As the first step in this direction, the attached patch extracts the predicate analysis logic out of the pass, turns the interface into public class members, and hides the internals in either private members or static functions defined in a new source file. (**) The changes should have no externally observable effect (i.e., should cause no changes in warnings), except on the contents of the uninitialized dump. While making the changes I enhanced the dumps to help me follow the logic. Turning some previously free-standing functions into members involved changing their signatures and adjusting their callers. While making these changes I also renamed some of them as well some variables for improved clarity. Finally, I moved declarations of locals closer to their point of initialization. Tested on x86_64-linux. Besides the usual bootstrap/regtest I also tentatively verified the generality of the new class interfaces by making use of it in -Warray-bounds. Besides there, I'd like to make use of it in the new gimple-ssa-warn-access pass and, longer term, any other flow-sensitive warnings that might benefit from it. Martin [*] A review of open -Wuninitialized bugs I did while working on this project made me aware of a number of opportunities to improve the analyzer to reduce the number of false positives -Wmaybe-uninitiailzed suffers from. [**] The class isn't fully general and, like the uninit pass, only works with PHI nodes. I plan to generalize it to compute the set of predicates between any two basic blocks. gcc-predanal.diff Factor predidacte analysis out of tree-ssa-uninit.c into its own module. gcc/ChangeLog: * Makefile.in (OBJS): Add gimple-predicate-analysis.o. * tree-ssa-uninit.c (max_phi_args): Move to gimple-predicate-analysis. (MASK_SET_BIT, MASK_TEST_BIT, MASK_EMPTY): Same. (check_defs): (can_skip_redundant_opnd): (compute_uninit_opnds_pos): Adjust to namespace change. (find_pdom): Move to gimple-predicate-analysis.cc. (find_dom): Same. (struct uninit_undef_val_t): New. (is_non_loop_exit_postdominating): Move to gimple-predicate-analysis.cc. (find_control_equiv_block): Same. (MAX_NUM_CHAINS, MAX_CHAIN_LEN, MAX_POSTDOM_CHECK): Same. (MAX_SWITCH_CASES): Same. (compute_control_dep_chain): Same. (find_uninit_use): Use predicate analyzer. (struct pred_info): Move to gimple-predicate-analysis. (convert_control_dep_chain_into_preds): Same. (find_predicates): Same. (collect_phi_def_edges): Same. (warn_uninitialized_phi): Use predicate analyzer. (find_def_preds): Move to gimple-predicate-analysis. (dump_pred_info): Same. (dump_pred_chain): Same. (dump_predicates): Same. (destroy_predicate_vecs): Remove. (execute_late_warn_uninitialized): New. (get_cmp_code): Move to gimple-predicate-analysis. (is_value_included_in): Same. (value_sat_pred_p): Same. (find_matching_predicate_in_rest_chains): Same. (is_use_properly_guarded): Same. (prune_uninit_phi_opnds): Same. (find_var_cmp_const): Same. (use_pred_not_overlap_with_undef_path_pred): Same. (pred_equal_p): Same. (is_neq_relop_p): Same. (is_neq_zero_form_p): Same. (pred_expr_equal_p): Same. (is_pred_expr_subset_of): Same. (is_pred_chain_subset_of): Same. (is_included_in): Same. (is_superset_of): Same. (pred_neg_p): Same. (simplify_pred): Same. (simplify_preds_2): Same. (simplify_preds_3): Same. (simplify_preds_4): Same. (simplify_preds): Same. (push_pred): Same. (push_to_worklist): Same. (get_pred_info_from_cmp): Same. (is_degenerated_phi): Same. (normalize_one_pred_1): Same. (normalize_one_pred): Same. (normalize_one_pred_chain): Same. (normalize_preds): Same. (can_one_predicate_be_invalidated_p): Same. (can_chain_union_be_invalidated_p): Same. (uninit_uses_cannot_happen): Same. (pass_late_warn_uninitialized::execute): Define. *
[Bug middle-end/102403] [12 Regression] ICE in in init_from_control_deps, at gimple-predicate-analysis.cc:2364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102403 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:825293da703aa1f7ce870b40afce91c1e8b6c0fa commit r12-3674-g825293da703aa1f7ce870b40afce91c1e8b6c0fa Author: Martin Sebor Date: Sun Sep 19 17:18:48 2021 -0600 Correct a function pre/postcondition [PR102403]. Resolves: PR middle-end/102403 - ICE in init_from_control_deps, at gimple-predicate-analysis.cc:2364 gcc/ChangeLog: PR middle-end/102403 * gimple-predicate-analysis.cc (predicate::init_from_control_deps): Correct a function pre/postcondition. gcc/testsuite/ChangeLog: PR middle-end/102403 * gcc.dg/uninit-pr102403.c: New test. * gcc.dg/uninit-pr102403-c2.c: New test.
[Bug middle-end/102243] [12 Regression] ICE in get_range_query since r12-3300-gece28da924dd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102243 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:c3895ef466f3068cac6f5c18b55716f494484917 commit r12-3673-gc3895ef466f3068cac6f5c18b55716f494484917 Author: Martin Sebor Date: Sun Sep 19 17:16:26 2021 -0600 Handle null cfun [PR102243]. Resolves: PR middle-end/102243 - ICE on placement new at global scope gcc/ChangeLog: PR middle-end/102243 * tree-ssa-strlen.c (get_range): Handle null cfun. gcc/testsuite/ChangeLog: PR middle-end/102243 * g++.dg/warn/Wplacement-new-size-10.C: New test.
[Bug rtl-optimization/102356] [11/12 Regression] compile-time explosion at -O3 -g in var-tracking since r11-209-g74dc179a6da33cd0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102356 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.3
[Bug target/102264] [9/10/11/12 Regression] extra spilling when using inline-asm and all registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5
[Bug c++/101344] [11/12 Regression] braced-init-list not supported in an aggregate deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101344 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.3
[Bug middle-end/97968] [9/10/11/12 Regression] Unnecessary mov instruction with comparison and cmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97968 Andrew Pinski changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 98303 has been marked as a duplicate of this bug. ***
[Bug target/98303] cmov seems not to swap condition during RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98303 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 97968. *** This bug has been marked as a duplicate of bug 97968 ***
[Bug middle-end/97968] [9/10/11/12 Regression] Unnecessary mov instruction with comparison and cmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97968 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5
[Bug c++/102071] [10/11/12 Regression] crash when combining -faligned-new=N with array cookie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102071 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.4
[Bug c++/86515] [9/10 Regression] std::initializer_list constructor is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86515 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5
[Bug fortran/100651] [9/10/11/12 Regression] Weird memory corruption with multiple triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5 Keywords||wrong-code
[Bug middle-end/101204] [12 Regression] infinite recursion in gtype-desc.c since r12-1801-g7036e9ef462fde8181bece4ac4e03f3aa27204dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101204 --- Comment #6 from Andrew Pinski --- typedef int_hash xint_hash_t; typedef hash_map xint_hash_map_t; /* A mapping from a 'location_t' to the warning spec set for it. */ extern GTY(()) xint_hash_map_t *nowarn_map; int_hash has no fields
[Bug middle-end/101204] [12 Regression] infinite recursion in gtype-desc.c since r12-1801-g7036e9ef462fde8181bece4ac4e03f3aa27204dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101204
--- Comment #5 from Andrew Pinski ---
void
gt_pch_nx (int_hash* x ATTRIBUTE_UNUSED,
ATTRIBUTE_UNUSED gt_pointer_operator op,
ATTRIBUTE_UNUSED void *cookie)
{
gt_pch_nx (&((*x)), op, cookie);
}
[Bug middle-end/101204] [12 Regression] infinite recursion in gtype-desc.c since r12-1801-g7036e9ef462fde8181bece4ac4e03f3aa27204dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101204 Andrew Pinski changed: What|Removed |Added Keywords||internal-improvement Target Milestone|--- |12.0
[Bug target/46379] frv.md:*movdf_nodouble+6 is nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46379 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed, still there.
Re: [PATCH] Factor out `find_a_program` helper around `find_a_file`
> On 19 Sep 2021, at 16:10, Jeff Law via Gcc-patches
> wrote:
>
>
>
> On 8/4/2021 12:21 PM, John Ericson wrote:
>> The helper is for `--print-prog-name` and similar things. Since all
>> executable finding goes through it, we can move the default overrides
>> into that path too. This also ensures that if some is looking for a
>> *non*-program that called `as`, `ld`, etc., weird things don't happen.
>> ---
>> gcc/gcc.c | 59 ---
>> 1 file changed, 34 insertions(+), 25 deletions(-)
> Thanks. I added a ChangeLog entry and pushed this to the trunk.
This doesn’t appear to have been tested with —with-{as,ld,dsymutil}= where
bootstrap fails since ‘mode' is undefined in the reorganised code.
I’m testing the patch below and will apply it if all goes OK,
thanks
Iain
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 1a74bf92f7a..506c2acc282 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -3083,17 +3083,17 @@ find_a_program (const char *name)
/* Do not search if default matches query. */
#ifdef DEFAULT_ASSEMBLER
- if (! strcmp (name, "as") && access (DEFAULT_ASSEMBLER, mode) == 0)
+ if (! strcmp (name, "as") && access (DEFAULT_ASSEMBLER, X_OK) == 0)
return xstrdup (DEFAULT_ASSEMBLER);
#endif
#ifdef DEFAULT_LINKER
- if (! strcmp (name, "ld") && access (DEFAULT_LINKER, mode) == 0)
+ if (! strcmp (name, "ld") && access (DEFAULT_LINKER, X_OK) == 0)
return xstrdup (DEFAULT_LINKER);
#endif
#ifdef DEFAULT_DSYMUTIL
- if (! strcmp (name, "dsymutil") && access (DEFAULT_DSYMUTIL, mode) == 0)
+ if (! strcmp (name, "dsymutil") && access (DEFAULT_DSYMUTIL, X_OK) == 0)
return xstrdup (DEFAULT_DSYMUTIL);
#endif
[Bug middle-end/43523] TLS documentation in internals manual incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43523 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
gcc-12-20210919 is now available
Snapshot gcc-12-20210919 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20210919/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 32731fa5b0abf092029b8e2be64319b978bda514 You'll find: gcc-12-20210919.tar.xz Complete GCC SHA256=3f046195d02225d4f072b3a50efca4a791c00f369bfb5c6cf68d82bcffeba988 SHA1=c6ce140785d181703d81d3e6b4dff4a7e095ddd3 Diffs from 12-20210912 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 Roger Sayle changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Roger Sayle --- This has been fixed on mainline.
Development request
Hello there, We are 6 students from Egypt and now We are in our last year and We need to build a project as a graduation project. And We are interested in the area of runtime systems, operating systems and compilers. We are going to work 40-60 hrs a week Can We help in some tool you need as a graduation project given that We have a professor to mentor us. If not can you suggest some tool you need to build and We will work on it. The project take one academic year Thanks
[Bug tree-optimization/102405] Loop index limited by a function return value considered to result in too big array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102405
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||msebor at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Martin Sebor ---
The warning triggers for the IL below as designed. Your analysis is also on
the mark: GCC cannot determine that the index is in the bounds of the vec
array, and so it emits code for the cases when it isn't.
[local count: 883471484]:
i.42_76 = (unsigned int) i_74;
if (i.42_76 > 199)
goto ; [33.00%] >>> i is in [200, UINT_MAX]
else
goto ; [67.00%]
...
[local count: 291545588]:
nologmsg.43_77 = nologmsg;
fc_assert_fail ("../../../src/server/techtools.c", &__FUNCTION__, 674, "(i)
>= 0 && (i) < (signed int) sizeof((eligible_techs).vec) * 8", nologmsg.43_77,
nologmsg.43_77);
_78 = i_74 >> 3;
_79 = eligible_techs.vec[_78]; <<< -Warray-bounds: _78 is in [25, UINT_MAX
>> 3]
_80 = (unsigned int) _79;
_81 = i_74 & 7;
_82 = _80 >> _81;
_83 = (_Bool) _82;
if (_83 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
This kind of a transformation isn't uncommon and can be the result of optimizer
improvements or other changes. Having said that, I see the function asserts
that the index is in bounds just before using it:
{ Tech_type_id i = (1); for (; i < advance_count(); i++) { {
if (i) >= 0 && (i) < (signed int) sizeof((eligible_techs).vec) * 8) ?
(void) 0 : fc_assert_fail("../../../src/server/techtools.c", __FUNCTION__, 713,
"(i) >= 0 && (i) < (signed int) sizeof((eligible_techs).vec) * 8", nologmsg,
nologmsg)), ((eligible_techs).vec[((i) / 8)] & (1u << ((i) & 0x7))) != 0)) {
chosen--;
if (chosen == 0) {
return i;
}
}
} } };
Assuming fc_assert_fail() behaves similar to aborts() and doesn't return to the
caller, annotating it as such is one of the recommended ways to communicate pre
and postconditions to GCC, improve the emitted code, and avoid warnings for
that GCC cannot prove is unreachable, like so:
void fc_assert_fail(const char *file, const char *function, int line,
const char *assertion, const char *message, ...)
__attribute__((__format__ (__printf__, 5, 6), noreturn));
With that, I'm going to resolve the problem as invalid. (If I misunderstood
your point please clarify.)
Re: [PATCH] Enable auto-vectorization at O2 with very-cheap cost model.
On 9/16/21 3:03 AM, Hongtao Liu via Gcc-patches wrote:
On Thu, Sep 16, 2021 at 4:23 PM Richard Biener via Gcc-patches
wrote:
On Thu, 16 Sep 2021, liuhongt wrote:
Ping
rebased on latest trunk.
gcc/ChangeLog:
* common.opt (ftree-vectorize): Add Var(flag_tree_vectorize).
* doc/invoke.texi (Options That Control Optimization): Update
documents.
* opts.c (default_options_table): Enable auto-vectorization at
O2 with very-cheap cost model.
(finish_options): Use cheap cost model for
explicit -ftree{,-loop}-vectorize.
gcc/testsuite/ChangeLog:
* c-c++-common/Wstringop-overflow-2.c: Adjust testcase.
* g++.dg/tree-ssa/pr81408.C: Ditto.
* g++.dg/warn/Wuninitialized-13.C: Ditto.
* gcc.dg/Warray-bounds-51.c: Ditto.
* gcc.dg/Warray-parameter-3.c: Ditto.
* gcc.dg/Wstringop-overflow-13.c: Ditto.
* gcc.dg/Wstringop-overflow-14.c: Ditto.
* gcc.dg/Wstringop-overflow-21.c: Ditto.
* gcc.dg/Wstringop-overflow-68.c: Ditto.
* gcc.dg/gomp/pr46032-2.c: Ditto.
* gcc.dg/gomp/pr46032-3.c: Ditto.
* gcc.dg/gomp/simd-2.c: Ditto.
* gcc.dg/gomp/simd-3.c: Ditto.
* gcc.dg/graphite/fuse-1.c: Ditto.
* gcc.dg/pr67089-6.c: Ditto.
* gcc.dg/pr82929-2.c: Ditto.
* gcc.dg/pr82929.c: Ditto.
* gcc.dg/store_merging_1.c: Ditto.
* gcc.dg/store_merging_11.c: Ditto.
* gcc.dg/store_merging_15.c: Ditto.
* gcc.dg/store_merging_16.c: Ditto.
* gcc.dg/store_merging_19.c: Ditto.
* gcc.dg/store_merging_24.c: Ditto.
* gcc.dg/store_merging_25.c: Ditto.
* gcc.dg/store_merging_28.c: Ditto.
* gcc.dg/store_merging_30.c: Ditto.
* gcc.dg/store_merging_5.c: Ditto.
* gcc.dg/store_merging_7.c: Ditto.
* gcc.dg/store_merging_8.c: Ditto.
* gcc.dg/strlenopt-85.c: Ditto.
* gcc.dg/tree-ssa/dump-6.c: Ditto.
* gcc.dg/tree-ssa/pr19210-1.c: Ditto.
* gcc.dg/tree-ssa/pr47059.c: Ditto.
* gcc.dg/tree-ssa/pr86017.c: Ditto.
* gcc.dg/tree-ssa/pr91482.c: Ditto.
* gcc.dg/tree-ssa/predcom-1.c: Ditto.
* gcc.dg/tree-ssa/predcom-dse-3.c: Ditto.
* gcc.dg/tree-ssa/prefetch-3.c: Ditto.
* gcc.dg/tree-ssa/prefetch-6.c: Ditto.
* gcc.dg/tree-ssa/prefetch-8.c: Ditto.
* gcc.dg/tree-ssa/prefetch-9.c: Ditto.
* gcc.dg/tree-ssa/ssa-dse-18.c: Ditto.
* gcc.dg/tree-ssa/ssa-dse-19.c: Ditto.
* gcc.dg/uninit-40.c: Ditto.
* gcc.dg/unroll-7.c: Ditto.
* gcc.misc-tests/help.exp: Ditto.
* gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c: Ditto.
* gcc.target/i386/pr22141.c: Ditto.
* gcc.target/i386/pr34012.c: Ditto.
* gcc.target/i386/pr49781-1.c: Ditto.
* gcc.target/i386/pr95798-1.c: Ditto.
* gcc.target/i386/pr95798-2.c: Ditto.
* gfortran.dg/pr77498.f: Ditto.
---
gcc/common.opt | 2 +-
gcc/doc/invoke.texi| 8 +---
gcc/opts.c | 18 +++---
.../c-c++-common/Wstringop-overflow-2.c| 2 +-
gcc/testsuite/g++.dg/tree-ssa/pr81408.C| 2 +-
gcc/testsuite/g++.dg/warn/Wuninitialized-13.C | 2 +-
gcc/testsuite/gcc.dg/Warray-bounds-51.c| 2 +-
gcc/testsuite/gcc.dg/Warray-parameter-3.c | 2 +-
gcc/testsuite/gcc.dg/Wstringop-overflow-13.c | 2 +-
gcc/testsuite/gcc.dg/Wstringop-overflow-14.c | 2 +-
gcc/testsuite/gcc.dg/Wstringop-overflow-21.c | 2 +-
gcc/testsuite/gcc.dg/Wstringop-overflow-68.c | 2 +-
gcc/testsuite/gcc.dg/gomp/pr46032-2.c | 2 +-
gcc/testsuite/gcc.dg/gomp/pr46032-3.c | 2 +-
gcc/testsuite/gcc.dg/gomp/simd-2.c | 2 +-
gcc/testsuite/gcc.dg/gomp/simd-3.c | 2 +-
gcc/testsuite/gcc.dg/graphite/fuse-1.c | 2 +-
gcc/testsuite/gcc.dg/pr67089-6.c | 2 +-
gcc/testsuite/gcc.dg/pr82929-2.c | 2 +-
gcc/testsuite/gcc.dg/pr82929.c | 2 +-
gcc/testsuite/gcc.dg/store_merging_1.c | 2 +-
gcc/testsuite/gcc.dg/store_merging_11.c| 2 +-
gcc/testsuite/gcc.dg/store_merging_15.c| 2 +-
gcc/testsuite/gcc.dg/store_merging_16.c| 2 +-
gcc/testsuite/gcc.dg/store_merging_19.c| 2 +-
gcc/testsuite/gcc.dg/store_merging_24.c| 2 +-
gcc/testsuite/gcc.dg/store_merging_25.c| 2 +-
gcc/testsuite/gcc.dg/store_merging_28.c| 2 +-
gcc/testsuite/gcc.dg/store_merging_30.c| 2 +-
gcc/testsuite/gcc.dg/store_merging_5.c | 2 +-
gcc/testsuite/gcc.dg/store_merging_7.c | 2 +-
gcc/testsuite/gcc.dg/store_merging_8.c | 2 +-
gcc/testsuite/gcc.dg/strlenopt-85.c| 2 +-
gcc/testsuite/gcc.dg/tree-ssa/dump-6.c | 2 +-
gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c | 2 +-
gcc/testsuite/gcc.dg/tree-ssa/pr47059.c| 2 +-
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Should be fixed on affected branches. Closing. Thanks for the report!
[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6527feb07c31689c6d31b7bd16fec9ada691e06b commit r11-9015-g6527feb07c31689c6d31b7bd16fec9ada691e06b Author: Harald Anlauf Date: Thu Sep 16 20:12:21 2021 +0200 Fortran - fix handling of optional allocatable DT arguments with INTENT(OUT) gcc/fortran/ChangeLog: PR fortran/102287 * trans-expr.c (gfc_conv_procedure_call): Wrap deallocation of allocatable components of optional allocatable derived type procedure arguments with INTENT(OUT) into a presence check. gcc/testsuite/ChangeLog: PR fortran/102287 * gfortran.dg/intent_out_14.f90: New test. (cherry picked from commit cfea7b86f2430b9cb8018379b071f4004233119c)
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1ae01a88d35a0e2b7d7686fcb3a4fdcc2a04e9f4 commit r11-9014-g1ae01a88d35a0e2b7d7686fcb3a4fdcc2a04e9f4 Author: Harald Anlauf Date: Tue Sep 14 20:23:27 2021 +0200 Fortran - fix ICE during error recovery checking entry characteristics gcc/fortran/ChangeLog: PR fortran/102311 * resolve.c (resolve_entries): Attempt to recover cleanly after rejecting mismatched function entries. gcc/testsuite/ChangeLog: PR fortran/102311 * gfortran.dg/entry_25.f90: New test. (cherry picked from commit b305ec979d9dfc8153859a62a8ab9dd43c3bfc73)
Re: unexpected result with -O2 solved via "volatile"
On Sun, 19 Sep 2021, Allin Cottrell via Gcc wrote: Should this perhaps be considered a bug? Below is a minimal test case for a type of calculation that occurs in my real code. It works as expected when compiled without optimization, but produces what seems like a wrong result when compiled with -O2, using both gcc 10.3.1 20210422 on Fedora and gcc 11.1.0-1 on Arch Linux. I realize there's a newer gcc release but it's not yet available for Arch, and looking at https://gcc.gnu.org/gcc-11/changes.html I didn't see anything to suggest that something relevant has changed. https://gcc.gnu.org/bugs/ says that you should first try compiling your code with -fsanitize=undefined, which tells you at runtime that your code is broken. Apart from that, bug reports should go to https://gcc.gnu.org/bugzilla/ and questions to gcc-h...@gcc.gnu.org. -- Marc Glisse
[pushed] libgcc, Darwin: Remove unused symlinks.
Hi These were used on older systems to equate the FAT libgcc_s library to single-slice equivalents. Unused for any current system and never emitted by GCC. tested on x86_64, i686 darwin and x86_64-linux (,m32) pushed to master, thanks Iain Signed-off-by: Iain Sandoe libgcc/ChangeLog: * config/t-slibgcc-darwin: Delete unused code. --- libgcc/config/t-slibgcc-darwin | 18 -- 1 file changed, 18 deletions(-) diff --git a/libgcc/config/t-slibgcc-darwin b/libgcc/config/t-slibgcc-darwin index 60d6d176013..bd1e9631c17 100644 --- a/libgcc/config/t-slibgcc-darwin +++ b/libgcc/config/t-slibgcc-darwin @@ -93,16 +93,6 @@ install-darwin-libgcc-stubs : for d in $(INSTALL_FILES) ; do \ $(INSTALL_DATA) $$d $(DESTDIR)$(slibdir)/$$d || exit 1 ; \ done - if [ -f $(DESTDIR)$(slibdir)/libgcc_s_ppc64.1.dylib ]; then \ - rm -f $(DESTDIR)$(slibdir)/libgcc_s_ppc64.1.dylib; \ - else true; fi - $(LN_S) libgcc_s.1.dylib \ - $(DESTDIR)$(slibdir)/libgcc_s_ppc64.1.dylib - if [ -f $(DESTDIR)$(slibdir)/libgcc_s_x86_64.1.dylib ]; then \ - rm -f $(DESTDIR)$(slibdir)/libgcc_s_x86_64.1.dylib; \ - else true; fi - $(LN_S) libgcc_s.1.dylib \ - $(DESTDIR)$(slibdir)/libgcc_s_x86_64.1.dylib else @@ -122,12 +112,4 @@ install-darwin-libgcc-links: $(LN_S) ../$$file $(gcc_objdir)$(MULTISUBDIR)/; \ done - rm -f $(gcc_objdir)$(MULTISUBDIR)/libgcc_s_x86_64.1.dylib - $(LN_S) libgcc_s.1.dylib \ - $(gcc_objdir)$(MULTISUBDIR)/libgcc_s_x86_64.1.dylib - - rm -f $(gcc_objdir)$(MULTISUBDIR)/libgcc_s_ppc64.1.dylib - $(LN_S) libgcc_s.1.dylib \ - $(gcc_objdir)$(MULTISUBDIR)/libgcc_s_ppc64.1.dylib - endif --
[pushed] libgcc, X86, Darwin: Handle symbols for HF cases.
Hi
This reorganises the Darwin symbol vers files to include
the generic ones at the top level; allowing for arch ports
to override (via either exclusion or inclusion as needed).
We add an X86-specific vers file containing the new HF
symbols. Note that although Darwin does not use ELF-style
symbol versioning - the parser that produces the map can
consume it. Using the ELF-style description will help us
know at which rev the symbols were introduced.
tested on x86_64, i686 darwin and x86_64 linux (, m32).
pushed to master, thanks
Iain
Signed-off-by: Iain Sandoe
libgcc/ChangeLog:
* config/i386/t-darwin: Add in a vers file for X86-specific
symbols.
* config/t-darwin: Add the generic symbol maps here...
* config/t-slibgcc-darwin: ... removing from here.
* config/i386/libgcc-darwin.ver: New file.
---
libgcc/config/i386/libgcc-darwin.ver | 21 +
libgcc/config/i386/t-darwin | 3 +++
libgcc/config/t-darwin | 3 +++
libgcc/config/t-slibgcc-darwin | 1 -
4 files changed, 27 insertions(+), 1 deletion(-)
create mode 100644 libgcc/config/i386/libgcc-darwin.ver
diff --git a/libgcc/config/i386/libgcc-darwin.ver
b/libgcc/config/i386/libgcc-darwin.ver
new file mode 100644
index 000..5224cdc982e
--- /dev/null
+++ b/libgcc/config/i386/libgcc-darwin.ver
@@ -0,0 +1,21 @@
+
+
+%inherit GCC_12.0.0 GCC_7.0.0
+GCC_12.0.0 {
+ __divhc3
+ __mulhc3
+ __eqhf2
+ __nehf2
+ __extendhfdf2
+ __extendhfsf2
+ __extendhftf2
+ __extendhfxf2
+ __fixhfti
+ __fixunshfti
+ __floattihf
+ __floatuntihf
+ __truncdfhf2
+ __truncsfhf2
+ __trunctfhf2
+ __truncxfhf2
+}
diff --git a/libgcc/config/i386/t-darwin b/libgcc/config/i386/t-darwin
index 5f2c69725d0..c6b3acaaca2 100644
--- a/libgcc/config/i386/t-darwin
+++ b/libgcc/config/i386/t-darwin
@@ -1,3 +1,6 @@
LIB2_SIDITI_CONV_FUNCS = yes
LIB2ADD = $(srcdir)/config/darwin-64.c
LIB2FUNCS_EXCLUDE = _fixtfdi _fixunstfdi _floatditf _floatunditf
+
+# Extra symbols for this port.
+SHLIB_MAPFILES += $(srcdir)/config/i386/libgcc-darwin.ver
diff --git a/libgcc/config/t-darwin b/libgcc/config/t-darwin
index 4b6317b5d85..14ae6b35a4e 100644
--- a/libgcc/config/t-darwin
+++ b/libgcc/config/t-darwin
@@ -24,3 +24,6 @@ d10-uwfef.o: $(srcdir)/config/darwin10-unwind-find-enc-func.c
libd10-uwfef.a: d10-uwfef.o
$(AR_CREATE_FOR_TARGET) $@ d10-uwfef.o
$(RANLIB_FOR_TARGET) $@
+
+# Symbols for all the sub-ports.
+SHLIB_MAPFILES = libgcc-std.ver $(srcdir)/config/libgcc-libsystem.ver
diff --git a/libgcc/config/t-slibgcc-darwin b/libgcc/config/t-slibgcc-darwin
index a6ada456e40..60d6d176013 100644
--- a/libgcc/config/t-slibgcc-darwin
+++ b/libgcc/config/t-slibgcc-darwin
@@ -24,7 +24,6 @@ SHLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) $(LDFLAGS) -dynamiclib
-nodefaultlibs \
SHLIB_MKMAP = $(srcdir)/mkmap-flat.awk
SHLIB_MKMAP_OPTS = -v leading_underscore=1
-SHLIB_MAPFILES = libgcc-std.ver $(srcdir)/config/libgcc-libsystem.ver
SHLIB_VERPFX = $(srcdir)/config/$(cpu_type)/libgcc-darwin
# we're only going to build the stubs if the target slib is /usr/lib
--
[pushed] Darwin, crts: Build Darwin10 unwinder shim as a library.
Hi,
We have a small unwinder shim that is only used for Darwin10
(and only then in quite specific cases). To avoid linking
this code for every executable or DSO, we can present the crt
as a convenience library (rather than a .o file).
tested on x86_64-darwin10,18, x86_64-linux-gnu
pushed to master, thanks
Iain
Signed-off-by: Iain Sandoe
gcc/ChangeLog:
* config/darwin.h (LINK_COMMAND_SPEC_A): Use Darwin10
unwinder shim as a convenience library.
libgcc/ChangeLog:
* config.host: Use convenience library for Darwin10
unwinder shim.
* config/t-darwin: Build Darwin10 unwinder shim as a
convenience library.
---
gcc/config/darwin.h| 2 +-
libgcc/config.host | 2 +-
libgcc/config/t-darwin | 6 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 6396586c138..50524a51511 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -231,7 +231,7 @@ extern GTY(()) int darwin_ms_struct;
%{%:sanitize(address): -lasan } \
%{%:sanitize(undefined): -lubsan } \
%(link_ssp) \
- %:version-compare(>< 10.6 10.7 mmacosx-version-min= -ld10-uwfef.o) \
+ %:version-compare(>< 10.6 10.7 mmacosx-version-min= -ld10-uwfef) \
%(link_gcc_c_sequence) \
}}}\
%{!nostdlib:%{!r:%{!nostartfiles:%E}}} %{T*} %{F*} "\
diff --git a/libgcc/config.host b/libgcc/config.host
index 432a3e1e38e..6c34b13d611 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -215,7 +215,7 @@ case ${host} in
*-*-darwin*)
asm_hidden_op=.private_extern
tmake_file="$tmake_file t-darwin ${cpu_type}/t-darwin t-libgcc-pic
t-slibgcc-darwin"
- extra_parts="crt3.o d10-uwfef.o crttms.o crttme.o"
+ extra_parts="crt3.o libd10-uwfef.a crttms.o crttme.o"
;;
*-*-dragonfly*)
tmake_file="$tmake_file t-crtstuff-pic t-libgcc-pic t-eh-dw2-dip"
diff --git a/libgcc/config/t-darwin b/libgcc/config/t-darwin
index 3b5e3428958..4b6317b5d85 100644
--- a/libgcc/config/t-darwin
+++ b/libgcc/config/t-darwin
@@ -18,3 +18,9 @@ LIB2ADDEH = $(srcdir)/unwind-dw2.c
$(srcdir)/config/unwind-dw2-fde-darwin.c \
# Patch to __Unwind_Find_Enclosing_Function for Darwin10.
d10-uwfef.o: $(srcdir)/config/darwin10-unwind-find-enc-func.c
$(crt_compile) -mmacosx-version-min=10.6 -c $<
+
+# Using this crt as a library means that it will not be added to an exe
+# (or module) unless needed.
+libd10-uwfef.a: d10-uwfef.o
+ $(AR_CREATE_FOR_TARGET) $@ d10-uwfef.o
+ $(RANLIB_FOR_TARGET) $@
--
unexpected result with -O2 solved via "volatile"
Should this perhaps be considered a bug? Below is a minimal test
case for a type of calculation that occurs in my real code. It works
as expected when compiled without optimization, but produces what
seems like a wrong result when compiled with -O2, using both gcc
10.3.1 20210422 on Fedora and gcc 11.1.0-1 on Arch Linux. I realize
there's a newer gcc release but it's not yet available for Arch, and
looking at https://gcc.gnu.org/gcc-11/changes.html I didn't see
anything to suggest that something relevant has changed.
#include
#include
int test (int *pk, int n)
{
int err = 0;
if (*pk > n) {
err = 1;
if (*pk > 2e9) {
int k = *pk + n - INT_MAX;
*pk = k;
if (k > 0) {
printf("Got positive revised k = %d\n", k);
err = 0;
} else {
printf("k = %d tests as non-positive?!\n", k);
}
}
}
return err;
}
int main (void)
{
int k = INT_MAX - 10;
int err;
err = test(, 20);
printf("main: err = %d\n", err);
return 0;
}
What strikes me as "seems wrong" is that the "(k > 0)" branch in
test() is not taken, although in the alternative branch it turns out
that k = 10. This can be fixed by using the "volatile" keyword in
front of the statement "int k = *pk + n - INT_MAX;" or by
parenthesizing (n - INT_MAX) in that statement.
I can see the case for assuming that k can't be positive if one
thinks of the expression as (*pk + n) - INT_MAX, since (*pk + n)
can't be greater than INT_MAX in context, being the sum of two ints.
All the same, since gcc does in fact end up assigning the value 10
to k the optimization seems a risky one.
--
Allin Cottrell
Department of Economics
Wake Forest University
[committed] Make test names unique for a couple of goacc tests
A couple of goacc tests do not have unique names. This causes problems
for the test comparison script when one of the test passes and the other
fails -- in this scenario the test comparison script claims there is a
regression.
This slipped through for a while because I had turned off x86_64 testing
(others test it regularly and I was revamping the tester's hardware
requirements). Now that I've acquired more x86_64 resources and turned
on native x86 testing again, it's been flagged.
This patch just adds a numeric suffix to the TODO string to disambiguate
them.
Committed to the trunk,
Jeff
commit f75b237254f32d5be32c9d9610983b777abea633
Author: Jeff Law
Date: Sun Sep 19 13:31:32 2021 -0400
[committed] Make test names unique for a couple of goacc tests
gcc/testsuite
* gfortran.dg/goacc/privatization-1-compute.f90: Make test names
unique.
* gfortran.dg/goacc/routine-external-level-of-parallelism-2.f:
Likewise.
diff --git a/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute.f90
b/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute.f90
index ed7e9ec6437..31f998dfc92 100644
--- a/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute.f90
+++ b/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute.f90
@@ -39,9 +39,9 @@ contains
!$acc atomic write ! ... to force 'TREE_ADDRESSABLE'.
y = a
!$acc end parallel
-! { dg-note {variable 'i' in 'private' clause potentially has improper
OpenACC privatization level: 'parm_decl'} "TODO" { xfail *-*-* }
l_compute$c_compute }
-! { dg-note {variable 'j' in 'private' clause potentially has improper
OpenACC privatization level: 'parm_decl'} "TODO" { xfail *-*-* }
l_compute$c_compute }
-! { dg-note {variable 'a' in 'private' clause potentially has improper
OpenACC privatization level: 'parm_decl'} "TODO" { xfail *-*-* }
l_compute$c_compute }
+! { dg-note {variable 'i' in 'private' clause potentially has improper
OpenACC privatization level: 'parm_decl'} "TODO2" { xfail *-*-* }
l_compute$c_compute }
+! { dg-note {variable 'j' in 'private' clause potentially has improper
OpenACC privatization level: 'parm_decl'} "TODO3" { xfail *-*-* }
l_compute$c_compute }
+! { dg-note {variable 'a' in 'private' clause potentially has improper
OpenACC privatization level: 'parm_decl'} "TODO4" { xfail *-*-* }
l_compute$c_compute }
! { dg-note {variable 'C\.[0-9]+' declared in block potentially has
improper OpenACC privatization level: 'const_decl'} "TODO" { target *-*-* }
l_compute$c_compute }
! { dg-note {variable 'D\.[0-9]+' declared in block isn't candidate for
adjusting OpenACC privatization level: not addressable} "" { target *-*-* }
l_compute$c_compute }
end subroutine f
diff --git
a/gcc/testsuite/gfortran.dg/goacc/routine-external-level-of-parallelism-2.f
b/gcc/testsuite/gfortran.dg/goacc/routine-external-level-of-parallelism-2.f
index 04d507fef9a..949d571ee55 100644
--- a/gcc/testsuite/gfortran.dg/goacc/routine-external-level-of-parallelism-2.f
+++ b/gcc/testsuite/gfortran.dg/goacc/routine-external-level-of-parallelism-2.f
@@ -22,8 +22,8 @@
! { dg-warning "insufficient partitioning available to parallelize loop" "" {
target *-*-* } .-1 }
do j = 1, n
call workerr (a, n) ! { dg-message "optimized: assigned OpenACC
worker vector loop parallelism" }
-! { dg-bogus "note: routine 'workerr' declared here" "TODO" { xfail { !
offloading_enabled } } .-1 }
-! { dg-bogus "note: routine 'workerr_' declared here" "TODO" { xfail
offloading_enabled } .-2 }
+! { dg-bogus "note: routine 'workerr' declared here" "TODO1" { xfail { !
offloading_enabled } } .-1 }
+! { dg-bogus "note: routine 'workerr_' declared here" "TODO2" { xfail
offloading_enabled } .-2 }
end do
end do
!$acc end parallel loop
@@ -36,8 +36,8 @@
do j = 1, n
call gangr (a, n) ! { dg-message "optimized: assigned OpenACC
worker vector loop parallelism" }
! { dg-error "routine call uses same OpenACC parallelism as containing loop"
"" { target *-*-* } .-1 }
-! { dg-bogus "note: routine 'gangr' declared here" "TODO" { xfail { !
offloading_enabled } } .-2 }
-! { dg-bogus "note: routine 'gangr_' declared here" "TODO" { xfail
offloading_enabled } .-3 }
+! { dg-bogus "note: routine 'gangr' declared here" "TODO1" { xfail { !
offloading_enabled } } .-2 }
+! { dg-bogus "note: routine 'gangr_' declared here" "TODO2" { xfail
offloading_enabled } .-3 }
end do
end do
!$acc end parallel loop
@@ -162,8 +162,8 @@
!$acc parallel loop ! { dg-message "optimized: assigned OpenACC gang worker
loop parallelism" }
do i = 1, n
call vectorr (a, n) ! { dg-message "optimized: assigned OpenACC
vector loop parallelism" }
-! { dg-bogus "note: routine 'vectorr' declared here" "TODO" { xfail { !
offloading_enabled } } .-1 }
-! { dg-bogus "note: routine 'vectorr_' declared here" "TODO" {
[Bug c++/58646] [9/10/11/12 Regression] ICE on a multidimensional VLA with an empty initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58646 Andrew Pinski changed: What|Removed |Added CC||pkeir at outlook dot com --- Comment #13 from Andrew Pinski --- *** Bug 102406 has been marked as a duplicate of this bug. ***
[Bug c++/102406] ICE on array declaration sized by a struct member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102406 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 58646. *** This bug has been marked as a duplicate of bug 58646 ***
[Bug bootstrap/102389] [12 Regression] --with-build-config=bootstrap-lto bootstrap is broken due to r12-3491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102389 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug bootstrap/102389] [12 Regression] --with-build-config=bootstrap-lto bootstrap is broken due to r12-3491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102389 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:68aace4458364fee201889aaaedfce59beb972f2 commit r12-3666-g68aace4458364fee201889aaaedfce59beb972f2 Author: Andrew Pinski Date: Sat Sep 18 01:08:17 2021 + Fix PR bootstrap/102389: --with-build-config=bootstrap-lto is broken So the problem here is that now the lto-plugin requires NM that works with LTO to work so we need to pass down NM just like we do for ranlib and ar. OK? Bootstrapped and tested with --with-build-config=bootstrap-lto on aarch64-linux-gnu. Note you need to use binutils 2.35 or later too due to ttps://sourceware.org/PR25355 (I will submit another patch to improve the installation instructions too). config/ChangeLog: PR bootstrap/102389 * bootstrap-lto-lean.mk: Handle NM like RANLIB AND AR. * bootstrap-lto.mk: Likewise.
Re: [PATCH] c-family: Add more predefined macros for math flags
On 6/30/2021 2:59 AM, Matthias Kretz wrote: Library code, especially in headers, sometimes needs to know how the compiler interprets / optimizes floating-point types and operations. This information can be used for additional optimizations or for ensuring correctness. This change makes -freciprocal-math, -fno-signed-zeros, -fno-trapping-math, -fassociative-math, and -frounding-math report their state via corresponding pre-defined macros. Signed-off-by: Matthias Kretz gcc/testsuite/ChangeLog: * gcc.dg/associative-math-1.c: New test. * gcc.dg/associative-math-2.c: New test. * gcc.dg/no-signed-zeros-1.c: New test. * gcc.dg/no-signed-zeros-2.c: New test. * gcc.dg/no-trapping-math-1.c: New test. * gcc.dg/no-trapping-math-2.c: New test. * gcc.dg/reciprocal-math-1.c: New test. * gcc.dg/reciprocal-math-2.c: New test. * gcc.dg/rounding-math-1.c: New test. * gcc.dg/rounding-math-2.c: New test. gcc/c-family/ChangeLog: * c-cppbuiltin.c (c_cpp_builtins_optimize_pragma): Define or undefine __RECIPROCAL_MATH__, __NO_SIGNED_ZEROS__, __NO_TRAPPING_MATH__, __ASSOCIATIVE_MATH__, and __ROUNDING_MATH__ according to the new optimization flags. gcc/ChangeLog: * cppbuiltin.c (define_builtin_macros_for_compilation_flags): Define __RECIPROCAL_MATH__, __NO_SIGNED_ZEROS__, __NO_TRAPPING_MATH__, __ASSOCIATIVE_MATH__, and __ROUNDING_MATH__ according to their corresponding flags. * doc/cpp.texi: Document __RECIPROCAL_MATH__, __NO_SIGNED_ZEROS__, __NO_TRAPPING_MATH__, __ASSOCIATIVE_MATH__, and __ROUNDING_MATH__. OK. Sorry about the long wait. jeff
Re: [PATCH] Recognize highpart multiplication during RTL expansion
On 8/8/2021 4:48 AM, Roger Sayle wrote: This middle-end patch teaches RTL expansion to recognize widening multiplications followed by right shifts as highpart multiplications, and attempt to emit them using the backends [su]mul_highpart optab if possible. My first attempt at supporting this, from August 2020, is at: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551316.html and the nvptx portions were conditionally pre-approved here: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551373.html I completely agree with Richard's original review that it's best to avoid any potential problems with MULT_HIGHPART_EXPR, which is poorly supported by middle-end passes, by recognizing this later, during expansion to RTL, which is the approach implemented in the patch. https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553055.html The following patch has been tested on nvptx-none with a "make" and "make -k check", and on x86-pc-linux-gnu with a "make bootstrap" and "make -k check" both with no new failures. Future work may also support WIDEN_MULT_EXPR and larger shifts, but the current matching is already complex enough for v1.0. Ok for mainline? 2021-08-08 Roger Sayle gcc/ChangeLog * expr.c (try_expand_mult_highpart): New function to recognize a highpart multiplication and expand it using the appropriate optab. (expand_expr_real_2) [RSHIFT_EXPR]: Attempt to expand right shifts of widening multiplications using try_expand_mult_highpart. * config/nvptx/nvptx.md (smuldi3_highpart): New define_insn. (umuldi3_highpart): New define_insn. gcc/testsuite/ChangeLog * gcc.target/nvptx/mul-hi64.c: New test case. * gcc.target/nvptx/umul-hi64.c: New test case. ENOPATCH jeff
Re: obstack.h __PTR_ALIGN vs. ubsan
On 9/1/2021 10:03 PM, Alan Modra via Binutils wrote: Current ubsan complains on every use of __PTR_ALIGN (when ptrdiff_t is as large as a pointer), due to making calculations relative to a NULL pointer. This patch avoids the problem by extracting out and simplifying __BPTR_ALIGN for the usual case. I've continued to use ptrdiff_t here, where it might be better to throw away __BPTR_ALIGN entirely and just assume uintptr_t exists. OK to apply for gcc? * obstack.h (__PTR_ALIGN): Expand and simplify __BPTR_ALIGN rather than calculating relative to a NULL pointer. OK jeff
Re: [Patch][doc][PR101843]clarification on building gcc and binutils together
On 9/9/2021 9:05 AM, Qing Zhao wrote: Hi, Jeff, Sorry for the late reply. The following is the reply from John Henning and the updated patch based on your suggestions, Please take a look and let us know any issue there. I would strongly recommend removing all the documentation related to single tree builds. While they were quite useful in the past, setting up such a tree these days is error prone and discouraged. Jeff
Re: [PATCH 2/2] Update the section on binutils version
On 9/17/2021 7:21 PM, apinski--- via Gcc-patches wrote: From: Andrew Pinski LTO usage requires binutils 2.35 or newer due to https://sourceware.org/PR25355. This adds a note in the prerequisites page about it. Ok? gcc/ChangeLog: * doc/install.texi: Add note about binutils 2.35 is required for LTO usage. --- OK jeff
Re: [PATCH 1/2] Fix PR bootstrap/102389: --with-build-config=bootstrap-lto is broken
On 9/17/2021 7:21 PM, apinski--- via Gcc-patches wrote: From: Andrew Pinski So the problem here is that now the lto-plugin requires NM that works with LTO to work so we need to pass down NM just like we do for ranlib and ar. OK? Bootstrapped and tested with --with-build-config=bootstrap-lto on aarch64-linux-gnu. Note you need to use binutils 2.35 or later too due to ttps://sourceware.org/PR25355 (I will submit another patch to improve the installation instructions too). config/ChangeLog: PR bootstrap/102389 * bootstrap-lto-lean.mk: Handle NM like RANLIB AND AR. * bootstrap-lto.mk: Likewise. OK jeff
Re: [PATCH] Loop unswitching: support gswitch statements.
On 9/15/2021 2:46 AM, Martin Liška wrote: Hello. The patch extends the loop unswitching pass so that gswitch statements are supported. The pass now uses ranger which marks switch edges that are known to be unreachable in a versioned loop. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/ChangeLog: * tree-cfg.c (gimple_lv_add_condition_to_bb): Support non-gimple expressions that needs to be gimplified. * tree-ssa-loop-unswitch.c (tree_unswitch_loop): Add new cond_edge parameter. (tree_may_unswitch_on): Support gswitch statements. (clean_up_switches): New function. (tree_ssa_unswitch_loops): Call clean_up_switches. (simplify_using_entry_checks): Removed and replaced with ranger. (tree_unswitch_single_loop): Change assumptions. gcc/testsuite/ChangeLog: * gcc.dg/loop-unswitch-6.c: New test. * gcc.dg/loop-unswitch-7.c: New test. * gcc.dg/loop-unswitch-8.c: New test. * gcc.dg/loop-unswitch-9.c: New test. LGTM. OK. Jeff
Re: [PATCH] Jit, testsuite: Amend expect processing to tolerate more platforms.
Hi David, > On 2 Sep 2021, at 15:47, David Malcolm wrote: > > On Thu, 2021-08-19 at 19:59 +0100, Iain Sandoe wrote: >> >> tested on i686, x86_64-darwin, x86_64,powerpc64-linux, > > Which versions of DejaGnu, BTW? framework 1.5, 1.5.1, 1.6.2 expect 5.45 / 5.45.4 / 5.45r2(darwin) (various local patches from distros) tcl 8.5 and 8.6[.9,11] I do see problems with stability of the summary counts with 1.5.1*** on Power machines (for my usual work I have a local 1.6.2 build) >> OK for master? > > Did you try this with RUN_UNDER_VALGRIND set? Assuming that that still > works, yes, looks good to me. This turned into a small rabbit hole, (not sure if that relates to the depth or the size of the rabbit). — there are a lot of ERROR outputs that make their way into the summary file — it seems that these are XFAILed, but the noise makes it hard to check equivalence .. anyway I tried a whole bunch of build permutations to see if forcing DWARF-4 fixed the issues.. it did not. The end result is that for both x86_64 and powerpc64le*** I see 2 progressions in the valgrind results … and AFAICT no regressions - if I do a side-by-side compare of the .sum files, the results seem reasonable. Of couse, it’s very hard to be 100% sure since the error output includes process numbers which makes diffs less helpful. anyway, I’ve applied this, and think I can declare x86_64-darwin as supporting Jit (actually, so does i686 and powerpc, but there are problems with the threaded test - 99% sure that’s testsuite-related and the two toy examples use a system routine that’s not available in darwin9). thanks Iain *** I’d recommend using framework 1.6.2 for stability of summary counts, the actual .sum seems ok with 1.5.1 - but not the listed results - maybe some manifestation of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64983 (although that was not supposed to apply to 1.5.1 at least on Darwin).
Re: [PATCH] avr: Add atmega324pb MCU
вс, 19 сент. 2021 г. в 18:06, Jeff Law : > > > > On 6/13/2021 12:42 PM, Matwey V. Kornilov via Gcc-patches wrote: > > Reference: https://www.microchip.com/wwwproducts/en/ATMEGA324PB > Signed-off-by: Matwey V. Kornilov > --- > gcc/config/avr/avr-mcus.def | 1 + > gcc/doc/avr-mmcu.texi | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > THanks. I added a ChangeLog entry and committed this patch. > Cool! Thank you. > Jeff > -- With best regards, Matwey V. Kornilov
[COMMITTED] Make dump_ranger routines externally visible.
There was an inline extern declaration for dump_ranger that was a bit of
a hack. I've removed it in favor of an actual prototype. There are
also some trivial changes to the dumping code in the path solver.
gcc/ChangeLog:
* gimple-range-path.cc (path_range_query::path_range_query): Add
header.
(path_range_query::dump): Remove extern declaration of dump_ranger.
* gimple-range-trace.cc (dump_ranger): Add DEBUG_FUNCTION marker.
* gimple-range-trace.h (dump_ranger): Add prototype.
---
gcc/gimple-range-path.cc | 8 ++--
gcc/gimple-range-trace.cc | 4 ++--
gcc/gimple-range-trace.h | 3 +++
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc
index c616b65756f..10b018b5211 100644
--- a/gcc/gimple-range-path.cc
+++ b/gcc/gimple-range-path.cc
@@ -37,6 +37,9 @@ along with GCC; see the file COPYING3. If not see
path_range_query::path_range_query (gimple_ranger )
: m_ranger (ranger)
{
+ if (DEBUG_SOLVER)
+fprintf (dump_file, "\n*** path_range_query **\n");
+
m_cache = new ssa_global_cache;
m_has_cache_entry = BITMAP_ALLOC (NULL);
m_path = NULL;
@@ -85,14 +88,15 @@ path_range_query::set_cache (const irange , tree name)
void
path_range_query::dump (FILE *dump_file)
{
+ push_dump_file save (dump_file, dump_flags & ~TDF_DETAILS);
+
if (m_path->is_empty ())
return;
unsigned i;
bitmap_iterator bi;
- extern void dump_ranger (FILE *, const vec &);
- fprintf (dump_file, "Path is (length=%d):\n", m_path->length ());
+ fprintf (dump_file, "\nPath is (length=%d):\n", m_path->length ());
dump_ranger (dump_file, *m_path);
fprintf (dump_file, "Imports:\n");
diff --git a/gcc/gimple-range-trace.cc b/gcc/gimple-range-trace.cc
index 5175d1400c4..2417c21f1f2 100644
--- a/gcc/gimple-range-trace.cc
+++ b/gcc/gimple-range-trace.cc
@@ -176,7 +176,7 @@ push_dump_file::~push_dump_file ()
// Dump all that ranger knows for the current function.
-DEBUG_FUNCTION void
+void
dump_ranger (FILE *out)
{
push_dump_file save (out, dump_flags);
@@ -201,7 +201,7 @@ debug_ranger ()
// Note that the blocks are in reverse order, thus the exit block is
// path[0].
-DEBUG_FUNCTION void
+void
dump_ranger (FILE *dump_file, const vec )
{
if (path.length () == 0)
diff --git a/gcc/gimple-range-trace.h b/gcc/gimple-range-trace.h
index b9546a245d1..d3e69e03543 100644
--- a/gcc/gimple-range-trace.h
+++ b/gcc/gimple-range-trace.h
@@ -72,4 +72,7 @@ private:
dump_flags_t old_dump_flags;
};
+void dump_ranger (FILE *);
+void dump_ranger (FILE *, const vec );
+
#endif // GCC_GIMPLE_RANGE_TRACE_H
--
2.31.1
Re: [PATCH] Minor cleanups to forward threader.
On 9/19/2021 9:37 AM, Aldy Hernandez wrote: Every time we allocate a threading edge we push it onto the path in a distinct step. There's no need to do this in two steps, and avoiding this, keeps us from exposing the internals of the registry. I've also did some tiny cleanups in thread_across_edge, most importantly removing the bitmap in favor of an auto_bitmap. There are no functional changes. OK pending tests? gcc/ChangeLog: * tree-ssa-threadbackward.c (back_threader_registry::register_path): Use push_edge. * tree-ssa-threadedge.c (jump_threader::thread_around_empty_blocks): Same. (jump_threader::thread_through_normal_block): Same. (jump_threader::thread_across_edge): Same. Also, use auto_bitmap. Tidy up code. * tree-ssa-threadupdate.c (jt_path_registry::allocate_thread_edge): Remove. (jt_path_registry::push_edge): New. (dump_jump_thread_path): Make static. * tree-ssa-threadupdate.h (allocate_thread_edge): Remove. (push_edge): New. OK jeff
[PATCH] Minor cleanups to forward threader.
Every time we allocate a threading edge we push it onto the path in a
distinct step. There's no need to do this in two steps, and avoiding
this, keeps us from exposing the internals of the registry.
I've also did some tiny cleanups in thread_across_edge, most importantly
removing the bitmap in favor of an auto_bitmap.
There are no functional changes.
OK pending tests?
gcc/ChangeLog:
* tree-ssa-threadbackward.c
(back_threader_registry::register_path): Use push_edge.
* tree-ssa-threadedge.c
(jump_threader::thread_around_empty_blocks): Same.
(jump_threader::thread_through_normal_block): Same.
(jump_threader::thread_across_edge): Same. Also, use auto_bitmap.
Tidy up code.
* tree-ssa-threadupdate.c
(jt_path_registry::allocate_thread_edge): Remove.
(jt_path_registry::push_edge): New.
(dump_jump_thread_path): Make static.
* tree-ssa-threadupdate.h (allocate_thread_edge): Remove.
(push_edge): New.
---
gcc/tree-ssa-threadbackward.c | 10 ++---
gcc/tree-ssa-threadedge.c | 69 ++-
gcc/tree-ssa-threadupdate.c | 12 +++---
gcc/tree-ssa-threadupdate.h | 2 +-
4 files changed, 30 insertions(+), 63 deletions(-)
diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index 805b7ac5ef6..c6530d3a6bb 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -902,15 +902,11 @@ back_threader_registry::register_path (const
vec _path,
edge e = find_edge (bb1, bb2);
gcc_assert (e);
- jump_thread_edge *x
- = m_lowlevel_registry.allocate_thread_edge (e, EDGE_COPY_SRC_BLOCK);
- jump_thread_path->safe_push (x);
+ m_lowlevel_registry.push_edge (jump_thread_path, e, EDGE_COPY_SRC_BLOCK);
}
- jump_thread_edge *x
-= m_lowlevel_registry.allocate_thread_edge (taken_edge,
- EDGE_NO_COPY_SRC_BLOCK);
- jump_thread_path->safe_push (x);
+ m_lowlevel_registry.push_edge (jump_thread_path,
+taken_edge, EDGE_NO_COPY_SRC_BLOCK);
if (m_lowlevel_registry.register_jump_thread (jump_thread_path))
++m_threaded_paths;
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index 2b9a4c31592..04138cb06fe 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -898,10 +898,7 @@ jump_threader::thread_around_empty_blocks
(vec *path,
if (!bitmap_bit_p (visited, taken_edge->dest->index))
{
- jump_thread_edge *x
- = m_registry->allocate_thread_edge (taken_edge,
- EDGE_NO_COPY_SRC_BLOCK);
- path->safe_push (x);
+ m_registry->push_edge (path, taken_edge, EDGE_NO_COPY_SRC_BLOCK);
bitmap_set_bit (visited, taken_edge->dest->index);
return thread_around_empty_blocks (path, taken_edge, visited);
}
@@ -942,10 +939,7 @@ jump_threader::thread_around_empty_blocks
(vec *path,
return false;
bitmap_set_bit (visited, taken_edge->dest->index);
- jump_thread_edge *x
- = m_registry->allocate_thread_edge (taken_edge,
- EDGE_NO_COPY_SRC_BLOCK);
- path->safe_push (x);
+ m_registry->push_edge (path, taken_edge, EDGE_NO_COPY_SRC_BLOCK);
thread_around_empty_blocks (path, taken_edge, visited);
return true;
@@ -1051,16 +1045,9 @@ jump_threader::thread_through_normal_block
(vec *path,
/* Only push the EDGE_START_JUMP_THREAD marker if this is
first edge on the path. */
if (path->length () == 0)
- {
- jump_thread_edge *x
- = m_registry->allocate_thread_edge (e, EDGE_START_JUMP_THREAD);
- path->safe_push (x);
- }
+ m_registry->push_edge (path, e, EDGE_START_JUMP_THREAD);
- jump_thread_edge *x
- = m_registry->allocate_thread_edge (taken_edge,
- EDGE_COPY_SRC_BLOCK);
- path->safe_push (x);
+ m_registry->push_edge (path, taken_edge, EDGE_COPY_SRC_BLOCK);
/* See if we can thread through DEST as well, this helps capture
secondary effects of threading without having to re-run DOM or
@@ -1146,53 +1133,43 @@
edge_forwards_cmp_to_conditional_jump_through_empty_bb_p (edge e)
void
jump_threader::thread_across_edge (edge e)
{
- bitmap visited = BITMAP_ALLOC (NULL);
+ auto_bitmap visited;
m_state->push (e);
stmt_count = 0;
vec *path = m_registry->allocate_thread_path ();
- bitmap_clear (visited);
bitmap_set_bit (visited, e->src->index);
bitmap_set_bit (visited, e->dest->index);
- int threaded;
+ int threaded = 0;
if ((e->flags & EDGE_DFS_BACK) == 0)
threaded = thread_through_normal_block (path, e, visited);
- else
-threaded = 0;
if
Re: [PATCH] Simplify paradoxical subreg extensions of TRUNCATE
On 9/6/2021 8:24 AM, Segher Boessenkool wrote:
Hi!
On Mon, Sep 06, 2021 at 12:32:13PM +0100, Roger Sayle wrote:
I think the current documentation is sufficient. During compilation, GCC's
combine pass will often substitute a register with an expression defining
it's value, and then attempt to simplify it. As you point out, this often
produces
(temporary intermediate) expressions with poorly defined semantics.
Not "poorly defined". The documentation says (in rtl.texi)
@findex subreg
@item (subreg:@var{m1} @var{reg:m2} @var{bytenum})
@code{subreg} expressions are used to refer to a register in a machine
mode other than its natural one, or to refer to one register of
a multi-part @code{reg} that actually refers to several registers.
It goes on to say there also are subregs of mem currently; it
exhaustively lists all things you can take a subreg of, what the
different semantics of those are, how the semantics are further
"modified" (read: completely different) if some RTL flags are set, etc.
The instruction combiner very often creates invalid RTL (only
structurally valid, like, no missing operands). Invalid RTL is supposed
to never match (because backends will not have patterns that match
these). combine even creates invalid RTL on purpose (a clobber of
const0_rtx) to ensure its result is deemed invalid, when it wants to
abort a combination attempt for some reason.
The
purpose of my patch is to avoid (constructing) SUBREGs that have TRUNCATE
as an argument (that some folks consider undefined) and instead simplify
them to either a single TRUNCATE or a SUBREG of a REG, both of which are
well defined. I'm making/helping the implementation match the
documentation.
But this should never make it to simplify-rtx at all. You can only
validly do such transformations in combine, because you need to know
what insns you started with etc.
simplify-rtx is a part of combine, sure, but it is used from other
contexts as well nowadays. If you can safely do this from combine,
you can do it in combine.
[ ... ]
So what I think is missing here is some concrete path forward. If I'm
understanding your objection Segher, you'd like to see Roger look at
where these (subreg (truncate)) expressions came from and address them
earlier than simplify_rtx? The theory being that the simplification
bits could be used from other contexts than just combine and in those
other contexts (subreg (truncate)) isn't valid?
Jeff
Re: [PATCH] Factor out `find_a_program` helper around `find_a_file`
On 8/4/2021 12:21 PM, John Ericson wrote: The helper is for `--print-prog-name` and similar things. Since all executable finding goes through it, we can move the default overrides into that path too. This also ensures that if some is looking for a *non*-program that called `as`, `ld`, etc., weird things don't happen. --- gcc/gcc.c | 59 --- 1 file changed, 34 insertions(+), 25 deletions(-) Thanks. I added a ChangeLog entry and pushed this to the trunk. Jeff
[Bug c++/102406] New: ICE on array declaration sized by a struct member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102406
Bug ID: 102406
Summary: ICE on array declaration sized by a struct member
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 51483
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51483=edit
The code described in the bug report.
Compiling the code below (also attached) produces an internal compiler error.
struct Foo { unsigned x_; };
int main(int argc, char *argv[])
{
const Foo a{3};
float f[2][a.x_]{};
return 0;
}
The full error is below:
internal compiler error: in make_decl_rtl, at varasm.c:1446
6 | float f[2][a.x_]{};
| ^
0x86bd48 make_decl_rtl(tree_node*)
../../gcc/varasm.c:1446
0xda0967 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10457
0xdb274b expand_constructor
../../gcc/expr.c:8491
0xda015a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10749
0xdac0ec store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5994
0xdb1ab7 store_field
../../gcc/expr.c:7491
0xdae17d expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5589
0xc76a37 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3945
0xc76a37 expand_gimple_stmt
../../gcc/cfgexpand.c:4043
0xc7cf03 expand_gimple_basic_block
../../gcc/cfgexpand.c:6085
0xc7ecb7 execute
../../gcc/cfgexpand.c:6811
Re: [PATCH] avr: Add atmega324pb MCU
On 6/13/2021 12:42 PM, Matwey V. Kornilov via Gcc-patches wrote: Reference:https://www.microchip.com/wwwproducts/en/ATMEGA324PB Signed-off-by: Matwey V. Kornilov --- gcc/config/avr/avr-mcus.def | 1 + gcc/doc/avr-mmcu.texi | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) THanks. I added a ChangeLog entry and committed this patch. Jeff
Re: [PATCH] PCH large file bug
On 5/19/2021 10:19 PM, Evgeniy via Gcc-patches wrote: Hello, can I ask somebody to push the patch to fix the PCH large file problem (BUG 14940)? The bug fix was sent in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c49 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c50 I would copy and paste it, but I'm not the author of this patch. The patch would need to be updated for the trunk and go through the usual testing cycle. If you could do that and post the updated patch, that would be greatly appreciated. I would claim that the patch in bugzilla is mostly just copy-paste and moving some things around and thus would not require DCO sign-off or a copyright assignment. Thanks, jeff
Re: [PATCH] testsuite: Remove .exe suffix in prune_gcc_output
On 9/8/2021 2:49 AM, Christophe Lyon via Gcc-patches wrote: When running the testsuite under Windows, we noticed failures in testcase which attempt to match compiler error messages containing the name of the executable. For instance, gcc.dg/analyzer/signal-4a.c tries to match 'cc1:' which obviously fails when the executable is called cc1.exe. This patch removes the .exe suffix from various toolchain executables to avoid this problem. 2021-09-08 Christophe Lyon Torbjörn SVENSSON gcc/testsuite/ * lib/prune.exp (prune_gcc_output): Remove .exe suffix from toolchain executables names. OK jeff
Re: [PATCH] flag_complex_method: support optimize attribute
On 9/7/2021 3:42 AM, Martin Liška wrote: On 9/6/21 14:16, Richard Biener wrote: On Mon, Sep 6, 2021 at 1:46 PM Jakub Jelinek wrote: On Mon, Sep 06, 2021 at 01:37:46PM +0200, Martin Liška wrote: --- a/gcc/opts.c +++ b/gcc/opts.c @@ -1323,6 +1323,14 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set, = (opts->x_flag_unroll_loops || opts->x_flag_peel_loops || opts->x_optimize >= 3); + + /* With -fcx-limited-range, we do cheap and quick complex arithmetic. */ + if (opts->x_flag_cx_limited_range) + flag_complex_method = 0; + + /* With -fcx-fortran-rules, we do something in-between cheap and C99. */ + if (opts->x_flag_cx_fortran_rules) + flag_complex_method = 1; That should then be opts->x_flag_complex_method instead of flag_complex_method. Ok with that change. But the C/C++ langhooks also set flag_complex_method so I fail to see how this helps? As said I was referring to -fcx-limited-range on the command-line and -fno-cx-limited-range in the optimize node to undo this which should get you the langhook setting of flag_complex_method = 2. You are right, it's even more complicated as -fno-cx-limited-range is target specific. Option handling has been introducing surprises every time ... The following tested patch should handle it. Ready to be installed? Thanks, Martin Note, I think we want to do much more in finish_options and less in process_options, anything that is about Optimization options rather than just the global ones. Though one needs to be careful with the cases where the code diagnoses something. Jakub 0001-flag_complex_method-support-optimize-attribute.patch From e88ae14be7c5609a969897b5d09f40709fea8a34 Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Fri, 3 Sep 2021 10:53:00 +0200 Subject: [PATCH] flag_complex_method: support optimize attribute gcc/c-family/ChangeLog: * c-opts.c (c_common_init_options_struct): Set also x_flag_default_complex_method. gcc/ChangeLog: * common.opt: Add new variable flag_default_complex_method. * opts.c (finish_options): Handle flags related to x_flag_complex_method. * toplev.c (process_options): Remove option handling related to flag_complex_method. gcc/go/ChangeLog: * go-lang.c (go_langhook_init_options_struct): Set also x_flag_default_complex_method. gcc/lto/ChangeLog: * lto-lang.c (lto_init_options_struct): Set also x_flag_default_complex_method. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/attr-complex-method-2.c: New test. * gcc.c-torture/compile/attr-complex-method.c: New test. OK jeff
[Bug c/102405] Loop index limited by a function return value considered to result in too big array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102405 --- Comment #1 from Marko Lindqvist --- Created attachment 51482 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51482=edit preprocessed file
[Bug c/102405] New: Loop index limited by a function return value considered to result in too big array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102405
Bug ID: 102405
Summary: Loop index limited by a function return value
considered to result in too big array subscript
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cazfi74 at gmail dot com
Target Milestone: ---
For a code where for-loop terminates before index variable gets value 25*8,
compiler gives a warning that the variable/8 used as array subscript has value
of 25 and is thus above array bounds.
Warning (turned to an error by -Werror):
In function 'pick_random_tech_to_lose',
inlined from 'update_bulbs' at ../../../src/server/techtools.c:621:42:
../../../src/server/techtools.c:674:271: error: array subscript 25 is above
array bounds of 'unsigned char[25]' [-Werror=array-bounds]
674 | if (BV_ISSET(eligible_techs, i)) {
|
^
In file included from ../../../src/common/player.h:31,
from ../../../src/common/game.h:36,
from ../../../src/server/techtools.c:27:
../../../src/common/tech.h: In function 'update_bulbs':
../../../src/common/tech.h:144:32: note: while referencing 'vec'
144 | BV_DEFINE(bv_techs, A_LAST);
|^
cc1: all warnings being treated as errors
The code compiles fine with gcc-11 (and number of earlier versions). It has
failed for some weeks with the Debian's gcc-12 development snapshot, with
latest update just today:
$ /usr/lib/gcc-snapshot/bin/gcc --version
gcc (Debian 20210918-1) 12.0.0 20210918 (experimental) [master
r12-3644-g7afcb534239]
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The loop termination is determined by a function call, like this:
'for (; _index < advance_count(); _index++) {'
If 'advance_count()' is replaced by '(25*8)', it compiles fine. The compiler
doesn't know what values advance_count() can return (it's implemented in a
different source file) - the compile fails even if it's implemented as simple
'return 25*8;'
There's a lot of macro magic around in the original code (if you think that the
warning is what one should get from the attached .i, then the bug is probably
preprocessor side)
The command line:
/usr/lib/gcc-snapshot/bin/gcc -v -save-temps -DHAVE_CONFIG_H -I.
-I../../../src/server -I../gen_headers -I../../../src/ai
-I../../../src/ai/classic -I../../../src/common -I../../../src/common/aicore
-I../../../src/common/scriptcore -I../../../src/utility
-I../../../src/server/advisors -I../../../src/server/generator
-I../../../src/server/scripting -DLOCALEDIR="/usr/local/share/locale"
-DBINDIR="/usr/local/bin" -DFC_CONF_PATH="/usr/local/etc/freeciv"
-DDEFAULT_DATA_PATH=".:data:~/.freeciv/2.6:/usr/local/share/freeciv"
-DDEFAULT_SAVE_PATH=".:~/.freeciv/saves"
-DDEFAULT_SCENARIO_PATH=".:data/scenarios:~/.freeciv/2.6/scenarios:~/.freeciv/scenarios:/usr/local/share/freeciv/scenarios"
-Wall -Wpointer-arith -Wcast-align -Werror -Wmissing-prototypes
-Wmissing-declarations -Wformat -Wformat-security -Wnested-externs -Wshadow
-Wold-style-declaration -Wno-tautological-compare -Wno-nonnull-compare -g -O2
-MT techtools.lo -MD -MP -MF .deps/techtools.Tpo -c
../../../src/server/techtools.c -o techtools.o
[Bug target/43613] Some architecture-dependent codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53912 --- Comment #7 from Andrew Pinski --- /gcc/emit-rtl.c: Line 361: Fixed by r0-106223 /gcc/ggc-common.c: Line 310: r0-120670 (PR 53912) /gcc/graphite-dependences.c: Line 107: Removed. /gcc/src/gcc/pointer-set.c: Line 67: File full removed in 2014. /gcc/src/gcc/tree-dump.c: Line 168: Fixed by r0-120669 (53912) /gcc/src/gcc/cp/class.c: Line 6740, 6742, 6764, 6767, 6900: Fixed by r0-120604 (PR 53912) So just this one left I think: /gcc/src/gcc/ira-conflicts.c: Line 125: Still there, size_t is long long (64bits) while long is 32bits.
[Bug middle-end/102403] [12 Regression] ICE in in init_from_control_deps, at gimple-predicate-analysis.cc:2364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102403
Zhendong Su changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Comment #2 from Zhendong Su ---
Another repro:
[603] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210919 (experimental) [master r12-3660-ge9e46864cd0] (GCC)
[604] %
[604] % gcctk -O2 small.c
[605] %
[605] % gcctk -O2 -Wall -Wextra small.c
during GIMPLE pass: uninit
small.c: In function ‘main’:
small.c:6:5: internal compiler error: in init_from_control_deps, at
gimple-predicate-analysis.cc:2364
6 | int main() {
| ^~~~
0x1a93e03 predicate::init_from_control_deps(vec
const*, unsigned int)
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:2364
0x1a954ff predicate::init_from_phi_def(gphi*)
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:1829
0x1a989b4 predicate::is_use_guarded(gimple*, basic_block_def*, gphi*, unsigned
int, hash_set >*)
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:1874
0x1a99064 predicate::is_use_guarded(gimple*, basic_block_def*, gphi*, unsigned
int)
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:1933
0x103df8f find_uninit_use
../../gcc-trunk/gcc/tree-ssa-uninit.c:1092
0x103df8f warn_uninitialized_phi
../../gcc-trunk/gcc/tree-ssa-uninit.c:1150
0x103df8f execute_late_warn_uninitialized
../../gcc-trunk/gcc/tree-ssa-uninit.c:1275
0x103df8f execute
../../gcc-trunk/gcc/tree-ssa-uninit.c:1288
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.
[606] %
[606] % cat small.c
int printf(const char *, ...);
int a[1], b, c, d, e, h;
static int f;
long g;
void i() { b = 1 ^ a[b ^ (c & 1)]; }
int main() {
int j;
if (!f && ~h) {
if (g)
goto L2;
} else {
int m = 0;
L1:
e = m;
L2:
m ^= 1;
if (d)
printf("0");
for (j = 0; j < 10; j++)
i();
goto L1;
}
return 0;
}
[Bug target/43267] internal compiler error: in copyprop_hardreg_forward_1, at regrename.c:1603
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43267 --- Comment #2 from Andrew Pinski --- Might have been introduced by r0-90362.
[Bug target/42227] fr30-gcc-4.4.2 generate Illigal 32bit immediate data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42227 --- Comment #2 from Andrew Pinski --- The main thing I can think of that might have caused this was the change from HOST_WIDE_INT being 32bit to being now always 64bit.
[Bug target/16641] fr30-elf-gcc compiler error when building newlib-1.12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16641 Andrew Pinski changed: What|Removed |Added CC||larsi at wh2 dot tu-dresden.de --- Comment #7 from Andrew Pinski --- *** Bug 29555 has been marked as a duplicate of this bug. ***
[Bug target/29555] failure building cross compiler for fr30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29555 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 16641. *** This bug has been marked as a duplicate of bug 16641 ***
[Bug middle-end/93246] [8 Regression] Unexpected program behavior when -fsanitize=address and -O2/O3 used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93246 Andrew Pinski changed: What|Removed |Added CC||syomalina at gmail dot com --- Comment #18 from Andrew Pinski --- *** Bug 95202 has been marked as a duplicate of this bug. ***
[Bug c++/95202] Assignment to a member is wrongly optimized away by g++ with -fstrict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95202 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- So this is a dup of bug 93246. *** This bug has been marked as a duplicate of bug 93246 ***
[Bug libgcc/88641] crtstuff.c ctors/dtors list breaks with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88641 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-19 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/60446] [PATCH] [TIC6X] implementing abssf2/absdf2 insns, _fabs/_fabsf/__builtin_c6x_fabs/__builtin_c6x_fabsf intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60446 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-19 Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug target/60369] [PATCH] [TIC6X] new compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60369 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-09-19 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- confirmed.
[Bug target/64030] some libiberty sources includes stdio.h prior to config.h causing redefined symbol warnings on i?86-*-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64030 Andrew Pinski changed: What|Removed |Added Keywords||build Last reconfirmed||2021-09-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed, still an issue on the trunk.
[Bug bootstrap/67275] *** No rule to make target '../build-x86_64-w64-mingw32/libiberty/pic/libiberty.a', needed by 'build/genmddeps.exe'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67275 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #1 from Andrew Pinski --- Fixed for GCC 11 with r11-702.
[Bug target/58112] Ineffective addressing mode used in loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58112 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.9.0 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- This was actually fixed for GCC 4.9.0 release. There was many tweaks to IV-opts during Nov 2013 time frame which would have solved this.
[Bug middle-end/64396] Missed optimization in post-loop register handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64396 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |9.0 Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- This is fixed in GCC 9+ on the rtl level due to gimple level changes. GCC 10+ late FRE (which was added by r10-1420) can detect it and remove the redudancy. The GCC 9 change was due to this: _25 = _24 /[ex] 4; _27 = _25 + 1; _28 = _27 * 4; Being transformed into just: _28 = _24 + 4; Which was due to r9-3247. So fixed in GCC 9 with it fully fixed in GCC 10.
[Bug target/89073] x86 __attribute__ ((target("sha"))) not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89073 Andrew Pinski changed: What|Removed |Added CC||vapier at gcc dot gnu.org --- Comment #6 from Andrew Pinski --- *** Bug 69587 has been marked as a duplicate of this bug. ***
