[Bug fortran/93671] gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93671 --- Comment #1 from Damian Rouson --- The submitted code also compiles and executes cleanly with the NAG Fortran compiler version 7.0.
[Bug fortran/93671] New: gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93671 Bug ID: 93671 Summary: gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at sourceryinstitute dot org Target Milestone: --- The code below generates an internal compiler error (ICE) in gfortran 8.3.0, 9.2.0, and in 10.0.0 dated 20200111. A more complete demonstration the data structures of interest is shown in the code example at http://bit.ly/37aHXxG, which works with the Intel Fortran compiler version 18. I"m not clear on whether the code is standard-conforming, but the code compiles and executes without error with the Intel compiler version 18 as does the longer, more complex version at the aforementioned URL executes without error. $ cat gfortran-8-10-ice.f90 type flux_planes integer, allocatable :: normals end type type package type(flux_planes) surface_fluxes(1) end type type(package) mail[*], halo_data halo_data%surface_fluxes(1)%normals = 1 mail = halo_data end $ gfortran -fcoarray=single gfortran-8-10-ice.f90 gfortran-8-10-ice.f90:12:0: 12 | mail = halo_data | internal compiler error: Segmentation fault: 11 libbacktrace could not find executable to open $ gfortran --version GNU Fortran (GCC) 10.0.0 20200111 (experimental)
[Bug target/93670] ICE for _mm256_extractf32x4_ps (unrecognized insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93670 --- Comment #1 from Hongtao.liu --- Refer to https://godbolt.org/z/QfpRWu
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 Richard Biener changed: What|Removed |Added Target||x86_64-*-linux --- Comment #6 from Richard Biener --- Which also means the version of the dynamic linker is interesting (glibcs version or alternatively the exact OS version).
[Bug target/93670] New: ICE for _mm256_extractf32x4_ps (unrecognized insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93670
Bug ID: 93670
Summary: ICE for _mm256_extractf32x4_ps (unrecognized insn)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Target: i386, x86-64
cat test.c
---
#include
#include
__m128i i__mm256_extractf32x4_ps_VEXTRACTF32X4(__m256i arg_0, int arg_1) {
__m128i result;
switch (arg_1) {
case 0x00: // arg_1
result = _mm256_extracti32x4_epi32(arg_0, 0x00);
break;
case 0x01: // arg_1
result = _mm256_extracti32x4_epi32(arg_0, 0x01);
break;
default: // arg_1
assert(0);
break;
}
return result;
}
---
gcc10_20200110 -O2 -S test.c -mavx512f -mavx512vl
error:
test.c: In function ‘i__mm256_extractf32x4_ps_VEXTRACTF32X4’:
test.c:17:1: error: unrecognizable insn:
17 | }
| ^
(insn 20 19 21 6 (set (reg:V4SI 89)
(vec_merge:V4SI (vec_select:V4SI (reg:V8SI 90)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
]))
(reg:V4SI 91)
(reg:QI 92)))
"/export/users2/liuhongt/install/gcc10_trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/include/avx512vlintrin.h":10055:20
-1
(nil))
during RTL pass: vregs
test.c:17:1: internal compiler error: in extract_insn, at recog.c:2294
0x1185247 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../gcc/gnu-toolchain/gcc/gcc/rtl-error.c:108
0x1185288 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../../gcc/gnu-toolchain/gcc/gcc/rtl-error.c:116
0x111d0d4 extract_insn(rtx_insn*)
../../../gcc/gnu-toolchain/gcc/gcc/recog.c:2294
0xd0eece instantiate_virtual_regs_in_insn
../../../gcc/gnu-toolchain/gcc/gcc/function.c:1607
0xd10517 instantiate_virtual_regs
../../../gcc/gnu-toolchain/gcc/gcc/function.c:1977
0xd105e2 execute
../../../gcc/gnu-toolchain/gcc/gcc/function.c:2026
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552 --- Comment #12 from Segher Boessenkool --- Sure, but what makes shift amount special here? This works just fine in any other expression as well. That is, for unsigned n; for negative numbers modulo works differently: it returns 0 or negative, so it is either UB, or the masking works as expected. Is there not a better way to express that?
[Bug target/60181] constant folding of complex number incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181
Paul Zimmermann changed:
What|Removed |Added
CC||zimmerma+gcc at loria dot fr
--- Comment #9 from Paul Zimmermann ---
Here is another example:
$ cat t.c
#include
#include
#include
_Complex double __attribute__ ((noinline))
calc_div (_Complex double a, _Complex double b)
{
return a / b;
}
_Complex double __attribute__ ((noinline))
calc_mul (_Complex double a, _Complex double b)
{
return a * b;
}
int
main (int argc, char **argv)
{
double x, y, z, t;
_Complex double a, b, c, d;
x = -1.0689346237980500e+252; y = 7.8846096489686452e-145;
z = 5.1152592576527620e-318; t = 6.7327111521288819e+78;
a = calc_div (x + y * I, z + t * I);
b = (x + y * I) / (z + t * I);
printf ("calc_div: %ap + %ap * i\n", creal (a), cimag (a));
printf ("div: %ap + %ap * i\n", creal (b), cimag (b));
x = -4.8798814420289904e-22; y = -6.4569205261627488e+209;
z = -1.0918976936190148e+147; t = -8.2942999263695497e-85;
c = calc_mul (x + y * I, z + t * I);
d = (x + y * I) * (z + t * I);
printf ("calc_mul: %ap + %ap * i\n", creal (c), cimag (c));
printf ("mul: %ap + %ap * i\n", creal (d), cimag (d));
return 0;
}
With gcc version 9.2.1 20200123 (Debian 9.2.1-25) on x86_64 I get:
$ gcc -O0 t.c; ./a.out
calc_div: 0x1.5ac8471ecdabp-741p + 0x1.48aa457eda0eep+575p * i
div: 0x1.5ac8471ecdabp-741p + 0x1.48aa457eda0eep+575p * i
calc_mul: -0x1.07a6046b053p+410p + infp * i
mul: -0x1.07a6046b053p+410p + infp * i
$ gcc -O2 t.c; ./a.out
calc_div: 0x1.5ac8471ecdabp-741p + 0x1.48aa457eda0eep+575p * i
div: -0x1.4d35f7c831ef5p-746p + 0x1.48aa457eda0eep+575p * i
calc_mul: -0x1.07a6046b053p+410p + infp * i
mul: -0x1.07a6046b053p+410p + infp * i
For division, the correctly rounded result is the one for "div" with -O2
(negative real part).
For multiplication, all results are incorrectly rounded, we should get
-0x1.07a6046b05347p410 if I'm correct.
I understand there is no accuracy requirement, but I thought with -O2 gcc was
using GNU MPC to get correct rounding, thus with -O2 both the "div" and "mul"
results should be correctly rounded. Why isn't it the case for mul?
[Bug middle-end/71509] Bitfield causes load hit store with larger store than load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509 luoxhu at gcc dot gnu.org changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #13 from luoxhu at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #12) > But it could do just > > stw r4,0(r3) > > (on LE; and with a rotate first, on BE). Thanks for the catching, this optimization is not related to load hit store. I will investigate why store-merging pass failed to merge the 2 half store.
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552 --- Comment #11 from Li Jia He --- The reason is that it is the remainder of the nth power of 2. In x >> (n% 32), 32 is the fifth power of 2. The hexadecimal representation of 32 is 0x100. Taking the remainder of 0x100, the data range is 0 ～ 0xff. And the result is the same as x >> (n & 0xff).
[Bug analyzer/93669] New: ICE in dump_exploded_nodes, at analyzer/engine.cc:3239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93669 Bug ID: 93669 Summary: ICE in dump_exploded_nodes, at analyzer/engine.cc:3239 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc-10.0.1-alpha20200209 snapshot (g:8686c4d84517b54cf3dfe98fca3a814b7d606502) ICEs when compiling gcc/testsuite/gcc.dg/analyzer/paths-2.c w/ -fanalyzer --param analyzer-max-enodes-per-program-point=2: % gcc-10.0.1 -fanalyzer --param analyzer-max-enodes-per-program-point=2 -c gcc/testsuite/gcc.dg/analyzer/paths-2.c during IPA pass: analyzer cc1: internal compiler error: in dump_exploded_nodes, at analyzer/engine.cc:3239 0x71c445 ana::exploded_graph::dump_exploded_nodes() const /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/engine.cc:3239 0x10e93bb ana::impl_run_checkers(ana::logger*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/engine.cc:3633 0x10e9e2c ana::run_checkers() /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/engine.cc:3674 0x10df5b8 execute /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/analyzer-pass.cc:84 (I believe, it should not ICE even in the face of such parameters abuse.)
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 --- Comment #5 from Alexander Monakov --- GCC is emitting static_local as @gnu_unique_object, so it should be unified by the Glibc dynamic linker. You can use 'nm -CD' to check its type after linking for the main executable and the library to make sure ld keeps it unique, and LD_DEBUG=all (see 'man ld.so') to see how it gets resolved at runtime.
[Bug c++/93667] [10 regression] ICE in esra with nested [[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667 gcc-bugs at marehr dot dialup.fu-berlin.de changed: What|Removed |Added CC||gcc-bugs at marehr dot dialup.fu-b ||erlin.de --- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Is this a duplicate / variant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516?
[Bug rtl-optimization/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658 --- Comment #4 from Matthias Klose --- the file from icu 65.1 is built using g++ -v -Wdate-time -g -O3 -fstack-protector-strong -Wformat -Werror=format-security -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11 -c -o genmbcs.o genmbcs.ii no specific patches applied for the trunk. The compiler defaults to PIE, and the usual hardening defaults: /usr/lib/gcc/powerpc64le-linux-gnu/10/cc1plus -fpreprocessed genmbcs.ii -msecure-plt -quiet -dumpbase genmbcs.ii -mcpu=power8 -auxbase-strip genmbcs.o -g -O3 -Wdate-time -Wformat=1 -Werror=format-security -Wextra -Wall -Wpedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11 -version -fstack-protector-strong -fasynchronous-unwind-tables -fstack-protector-strong -Wformat-security -fstack-clash-protection
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552 --- Comment #10 from Segher Boessenkool --- What makes shift amount special at all, for those gimple simplifications?
[Bug c++/93668] constexpr delete[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93668
--- Comment #1 from fdlbxtqi ---
constexpr int f()
{
auto p(new int[1]);
delete p;
return 4;
}
int main()
{
constexpr auto w(f());
}
[Bug c++/93668] New: constexpr delete[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93668
Bug ID: 93668
Summary: constexpr delete[]
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
//This code should not compile because it is UB. delete a int[1]
constexpr int f()
{
auto p(new int[1]);
delete p;
return 4;
}
int main()
{
constexpr auto w(f());
}
//
constexpr int f()
{
auto p(new int);
delete[] p;
return 4;
}
int main()
{
constexpr auto w(f());
}
[Bug c++/93667] New: [10 regression] ICE in esra with nested [[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
Bug ID: 93667
Summary: [10 regression] ICE in esra with nested
[[no_unique_address]] field
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Compile with: -std=c++2a -O2
struct a {};
struct b { [[no_unique_address]] a aq; };
struct c {
int d;
[[no_unique_address]] b e;
};
c f() {return {};}
void g() { f(); }
Result:
during GIMPLE pass: esra
repro.cpp.i: In function ‘void g()’:
repro.cpp.i:8:17: internal compiler error: in verify_sra_access_forest, at
tree-sra.c:2327
8 | void g() { f(); }
| ^
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #9 from Li Jia He ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > (In reply to Andrew Pinski from comment #6)
> > > (In reply to Li Jia He from comment #5)
> > > > Could we consider doing this optimization on gimple? I use the following
> > > > code on gimple to produce optimized results on powerpc64.
> > >
> > > It might make sense. But fold-const.c might not be the correct location;
> > > match.pd might be a better place for it.
> >
> > Something like:
> > (simplify
> > (rshift @0 (mod @1 integer_pow2p@2))
> > (rshift @0 (bit_and @1 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
>
> Some typos:
> (simplify
> (rshift @0 (mod @1 integer_pow2p@2))
> (rshift @0 (bit_and @1 (minus @2 { build_int_cst (TREE_TYPE (@2), 1); }
>
> This would be under the for:
> (for mod (ceil_mod floor_mod round_mod trunc_mod)
Thank you for your suggestions. Let's try it on gcc11 stage1 ^ _ ^.
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > (In reply to Li Jia He from comment #5)
> > > Could we consider doing this optimization on gimple? I use the following
> > > code on gimple to produce optimized results on powerpc64.
> >
> > It might make sense. But fold-const.c might not be the correct location;
> > match.pd might be a better place for it.
>
> Something like:
> (simplify
> (rshift @0 (mod @1 integer_pow2p@2))
> (rshift @0 (bit_and @1 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
Some typos:
(simplify
(rshift @0 (mod @1 integer_pow2p@2))
(rshift @0 (bit_and @1 (minus @2 { build_int_cst (TREE_TYPE (@2), 1); }
This would be under the for:
(for mod (ceil_mod floor_mod round_mod trunc_mod)
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Li Jia He from comment #5)
> > Could we consider doing this optimization on gimple? I use the following
> > code on gimple to produce optimized results on powerpc64.
>
> It might make sense. But fold-const.c might not be the correct location;
> match.pd might be a better place for it.
Something like:
(simplify
(rshift @0 (mod @1 integer_pow2p@2))
(rshift @0 (bit_and @1 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
[Bug analyzer/93657] Ambiguous wording "is doing to"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93657 --- Comment #3 from Roland Illig --- (In reply to David Malcolm from comment #2) > Dump various analyzer internals to stderr. I like these. They are simple and to the point, and I cannot find any ambiguity anymore. :)
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552 --- Comment #6 from Andrew Pinski --- (In reply to Li Jia He from comment #5) > Could we consider doing this optimization on gimple? I use the following > code on gimple to produce optimized results on powerpc64. It might make sense. But fold-const.c might not be the correct location; match.pd might be a better place for it.
[Bug analyzer/93659] typo in analyzer.opt: call tha would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93659 --- Comment #5 from Roland Illig --- Cool, thank you for the quick fix. That makes translating GCC more fun than in the previous years. :)
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
Li Jia He changed:
What|Removed |Added
CC||helijia at gcc dot gnu.org
--- Comment #5 from Li Jia He ---
Could we consider doing this optimization on gimple? I use the following code
on gimple to produce optimized results on powerpc64.
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index aefa91666e2..a40681b271f 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -11131,7 +11131,6 @@ fold_binary_loc (location_t loc, enum tree_code code,
tree type,
WARN_STRICT_OVERFLOW_MISC);
return fold_convert_loc (loc, type, tem);
}
-
return NULL_TREE;
case CEIL_MOD_EXPR:
@@ -11191,6 +11190,22 @@ fold_binary_loc (location_t loc, enum tree_code code,
tree type,
prec) == 0)
return fold_convert_loc (loc, type, TREE_OPERAND (arg0, 0));
+ if (code == RSHIFT_EXPR
+ && (TREE_CODE (arg1) == CEIL_MOD_EXPR
+ || TREE_CODE (arg1) == FLOOR_MOD_EXPR
+ || TREE_CODE (arg1) == ROUND_MOD_EXPR
+ || TREE_CODE (arg1) == TRUNC_MOD_EXPR)
+ && TREE_CODE (TREE_OPERAND (arg1, 1)) == INTEGER_CST
+ && integer_pow2p (TREE_OPERAND (arg1, 1)))
+{
+ tree arg10 = TREE_OPERAND (arg1, 0);
+ tree arg11 = TREE_OPERAND (arg1, 1);
+ return fold_build2_loc (loc, code, type, arg0,
+ fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE(arg10), arg10,
+fold_build2_loc (loc, MINUS_EXPR, TREE_TYPE(arg11), arg11,
+ build_one_cst(TREE_TYPE(arg11);
+}
+
return NULL_TREE;
case MIN_EXPR:
[Bug c++/69448] Abbreviated function templates with deduced return type still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69448 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Patrick Palka --- Fixed on trunk for GCC 10.
[Bug c++/80471] (gcc extension) Forwarding-reference `auto` function parameters do not follow the same rules as template functions or generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80471 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a6ee556c7659877bb59b719f11ca2153e86ded59 commit r10-6571-ga6ee556c7659877bb59b719f11ca2153e86ded59 Author: Patrick Palka Date: Sun Feb 9 22:23:25 2020 -0500 c++: Fix return type deduction with an abbreviated function template This patch fixes two issues with return type deduction in the presence of an abbreviated function template. The first issue (PR 69448) is that if a placeholder auto return type contains any modifiers such as & or *, then the abbreviated function template compensation in splice_late_return_type does not get performed for the underlying auto node, leading to incorrect return type deduction. This happens because splice_late_return_type does not consider that a placeholder auto return type might have modifiers. To fix this it seems we need to look through modifiers in the return type to obtain the location of the underlying auto node in order to replace it with the adjusted auto node. To that end this patch refactors the utility function find_type_usage to return a pointer to the matched tree, and uses it to find and replace the underlying auto node. The second issue (PR 80471) is that the AUTO_IS_DECLTYPE flag is not being preserved in splice_late_return_type when compensating for an abbreviated function template, leading to us treating a decltype(auto) return type as if it was an auto return type. Fixed by making make_auto_1 set the AUTO_IS_DECLTYPE flag whenever we're building a decltype(auto) node and adjusting callers appropriately. The test for PR 80471 is adjusted to expect the correct behavior. gcc/cp/ChangeLog: PR c++/69448 PR c++/80471 * type-utils.h (find_type_usage): Refactor to take a tree * and to return a tree *, and update documentation accordingly. * pt.c (make_auto_1): Set AUTO_IS_DECLTYPE when building a decltype(auto) node. (make_constrained_decltype_auto): No need to explicitly set AUTO_IS_DECLTYPE anymore. (splice_late_return_type): Use find_type_usage to find and replace a possibly nested auto node instead of using is_auto. Check test for is_auto into an assert when deciding whether to late_return_type. (type_uses_auto): Adjust the call to find_type_usage. * parser.c (cp_parser_decltype): No need to explicitly set AUTO_IS_DECLTYPE anymore. libcc1/ChangeLog: PR c++/69448 PR c++/80471 * libcp1plugin.cc (plugin_get_expr_type): No need to explicitly set AUTO_IS_DECLTYPE anymore. gcc/testsuite/ChangeLog: PR c++/69448 PR c++/80471 * g++.dg/concepts/abbrev3.C: New test. * g++.dg/cpp2a/concepts-pr80471.C: Adjust a static_assert to expect the correct behavior. * g++.dg/cpp0x/auto9.C: Adjust a dg-error directive.
[Bug c++/69448] Abbreviated function templates with deduced return type still broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69448 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a6ee556c7659877bb59b719f11ca2153e86ded59 commit r10-6571-ga6ee556c7659877bb59b719f11ca2153e86ded59 Author: Patrick Palka Date: Sun Feb 9 22:23:25 2020 -0500 c++: Fix return type deduction with an abbreviated function template This patch fixes two issues with return type deduction in the presence of an abbreviated function template. The first issue (PR 69448) is that if a placeholder auto return type contains any modifiers such as & or *, then the abbreviated function template compensation in splice_late_return_type does not get performed for the underlying auto node, leading to incorrect return type deduction. This happens because splice_late_return_type does not consider that a placeholder auto return type might have modifiers. To fix this it seems we need to look through modifiers in the return type to obtain the location of the underlying auto node in order to replace it with the adjusted auto node. To that end this patch refactors the utility function find_type_usage to return a pointer to the matched tree, and uses it to find and replace the underlying auto node. The second issue (PR 80471) is that the AUTO_IS_DECLTYPE flag is not being preserved in splice_late_return_type when compensating for an abbreviated function template, leading to us treating a decltype(auto) return type as if it was an auto return type. Fixed by making make_auto_1 set the AUTO_IS_DECLTYPE flag whenever we're building a decltype(auto) node and adjusting callers appropriately. The test for PR 80471 is adjusted to expect the correct behavior. gcc/cp/ChangeLog: PR c++/69448 PR c++/80471 * type-utils.h (find_type_usage): Refactor to take a tree * and to return a tree *, and update documentation accordingly. * pt.c (make_auto_1): Set AUTO_IS_DECLTYPE when building a decltype(auto) node. (make_constrained_decltype_auto): No need to explicitly set AUTO_IS_DECLTYPE anymore. (splice_late_return_type): Use find_type_usage to find and replace a possibly nested auto node instead of using is_auto. Check test for is_auto into an assert when deciding whether to late_return_type. (type_uses_auto): Adjust the call to find_type_usage. * parser.c (cp_parser_decltype): No need to explicitly set AUTO_IS_DECLTYPE anymore. libcc1/ChangeLog: PR c++/69448 PR c++/80471 * libcp1plugin.cc (plugin_get_expr_type): No need to explicitly set AUTO_IS_DECLTYPE anymore. gcc/testsuite/ChangeLog: PR c++/69448 PR c++/80471 * g++.dg/concepts/abbrev3.C: New test. * g++.dg/cpp2a/concepts-pr80471.C: Adjust a static_assert to expect the correct behavior. * g++.dg/cpp0x/auto9.C: Adjust a dg-error directive.
[Bug middle-end/93663] [10 Regression] ICE in is_halfway_below, at real.c:5192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93663 Martin Sebor changed: What|Removed |Added Component|target |middle-end --- Comment #2 from Martin Sebor --- Whoops, I got the ChangeLog for r274927 wrong. It's actually this: Builtin function roundeven folding implementation 2019-08-26 Tejas Joshi * builtins.c (mathfn_built_in_2): Added CASE_MATHFN_FLOATN for ROUNDEVEN. * builtins.def: Added function definitions for roundeven function variants. * fold-const-call.c (fold_const_call_ss): Added case for roundeven function call. Adjust condition for floor, ceil, trunc and round. * fold-const.c (negate_mathfn_p): Added case for roundeven function. (tree_call_nonnegative_warnv_p): Added case for roundeven function. (integer_valued_real_call_p): Added case for roundeven function. * real.c (is_even): New function. Returns true if real number is even, otherwise returns false. (is_halfway_below): New function. Returns true if real number is halfway between two integers, else return false. (real_roundeven): New function. Round real number to nearest integer, rounding halfway cases towards even. * real.h (real_value): Added descriptive comments. Added function declaration for roundeven function. * doc/extend.texi (Other Builtins): List roundeven variants among functions which can be handled as builtins.
[Bug c++/93666] Dependence of optimization on use of constexpr seems inappropriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93666 Andrew Pinski changed: What|Removed |Added Depends on||4131 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > There is another bug report which talks about the same. PR 4131 :) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131 [Bug 4131] The C++ compiler doesn't place a const class object to ".rodata" section with non trivial constructor
[Bug c++/93666] Dependence of optimization on use of constexpr seems inappropriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93666 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|WAITING |NEW Severity|normal |enhancement --- Comment #4 from Andrew Pinski --- > seems inappropriate It is not because of the way C++ talks about global constructors.
[Bug c++/93666] Dependence of optimization on use of constexpr seems inappropriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93666
--- Comment #3 from Andrew Pinski ---
The source:
struct A
{
int i{1}, j{2};
A(int i_, int j_) : i(i_), j(j_) {}
};
A a{3,4};
struct B
{
int i{1}, j{2};
constexpr B(int i_, int j_) : i(i_), j(j_) {}
};
B b{3,4};
CUT
There is a big difference between B and A. OPtimization has nothing to do with
it. C++ says a has a dynamic constructor while b is required to be done
statically. So GCC does not currently implement dynamic to static constructor
optimization while clang does.
There is another bug report which talks about the same.
[Bug middle-end/71509] Bitfield causes load hit store with larger store than load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509 --- Comment #12 from Segher Boessenkool --- But it could do just stw r4,0(r3) (on LE; and with a rotate first, on BE).
[Bug c++/93666] Dependence of optimization on use of constexpr seems inappropriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93666 --- Comment #2 from Jonathan Wakely --- (In reply to Walt Karas from comment #0) > My understanding is that constexpr should not be used as a "register-esque" > hint to decide whether or not to optimize. 'constexpr' implies 'inline' which is used as a hint for inlining by GCC (although in this case the function is implicitly inline anyway, so that shouldn't matter).
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 --- Comment #4 from Walt Karas --- (conanrunenv) [root@d761696b8abf VagueDynLink]# cc -O2 -Wall -Wextra -pedantic -std=c++17 -fno-strict-aliasing -fwrapv -S main.cc (conanrunenv) [root@d761696b8abf VagueDynLink]# cat main.s .file "main.cc" .text .section .text._ZNSt11char_traitsIcE6lengthEPKc,"axG",@progbits,_ZNSt11char_traitsIcE6lengthEPKc,comdat .p2align 4,,15 .weak _ZNSt11char_traitsIcE6lengthEPKc .type _ZNSt11char_traitsIcE6lengthEPKc, @function _ZNSt11char_traitsIcE6lengthEPKc: .LFB419: .cfi_startproc jmp strlen .cfi_endproc .LFE419: .size _ZNSt11char_traitsIcE6lengthEPKc, .-_ZNSt11char_traitsIcE6lengthEPKc .section.rodata.str1.1,"aMS",@progbits,1 .LC0: .string "./lib.a" .LC1: .string "dlopen() failed: " .LC2: .string "lib" .LC3: .string "lib() not found\n" .LC4: .string "dlsym() fail: " .section.text.startup,"ax",@progbits .p2align 4,,15 .globl main .type main, @function main: .LFB1854: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movl$2, %esi movl$.LC0, %edi pushq %rbx .cfi_def_cfa_offset 24 .cfi_offset 3, -24 subq$24, %rsp .cfi_def_cfa_offset 48 calldlopen testq %rax, %rax je .L9 movl$.LC2, %esi movq%rax, %rdi movq%rax, %rbx calldlsym testq %rax, %rax je .L5 call*%rax leaq15(%rsp), %rbp .L6: movl_ZZ3foovE12static_local(%rip), %eax movl$_ZSt4cout, %edi leal1(%rax), %esi movl%esi, _ZZ3foovE12static_local(%rip) call_ZNSolsEi movq%rbp, %rsi movl$1, %edx movb$10, 15(%rsp) movq%rax, %rdi call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l movq%rbx, %rdi calldlclose addq$24, %rsp .cfi_remember_state .cfi_def_cfa_offset 24 xorl%eax, %eax popq%rbx .cfi_def_cfa_offset 16 popq%rbp .cfi_def_cfa_offset 8 ret .L5: .cfi_restore_state calldlerror movq%rax, %rbp testq %rax, %rax je .L10 movl$.LC4, %edi call_ZNSt11char_traitsIcE6lengthEPKc movl$.LC4, %esi movl$_ZSt4cout, %edi movq%rax, %rdx call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l movq%rbp, %rsi movl$_ZSt4cout, %edi leaq15(%rsp), %rbp call_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc movl$1, %edx movq%rbp, %rsi movb$10, 15(%rsp) movq%rax, %rdi call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l jmp .L6 .L10: movl$.LC3, %esi movl$_ZSt4cout, %edi leaq15(%rsp), %rbp call_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc jmp .L6 .L9: movl$.LC1, %edi call_ZNSt11char_traitsIcE6lengthEPKc movl$.LC1, %esi movl$_ZSt4cout, %edi movq%rax, %rdx call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l calldlerror movl$_ZSt4cout, %edi movq%rax, %rsi call_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc movl$1, %edx leaq15(%rsp), %rsi movb$10, 15(%rsp) movq%rax, %rdi call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l movl$1, %edi callexit .cfi_endproc .LFE1854: .size main, .-main .p2align 4,,15 .type _GLOBAL__sub_I_main, @function _GLOBAL__sub_I_main: .LFB2309: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 movl$_ZStL8__ioinit, %edi call_ZNSt8ios_base4InitC1Ev movl$__dso_handle, %edx movl$_ZStL8__ioinit, %esi movl$_ZNSt8ios_base4InitD1Ev, %edi addq$8, %rsp .cfi_def_cfa_offset 8 jmp __cxa_atexit .cfi_endproc .LFE2309: .size _GLOBAL__sub_I_main, .-_GLOBAL__sub_I_main .section.init_array,"aw" .align 8 .quad _GLOBAL__sub_I_main .weak _ZZ3foovE12static_local .section .bss._ZZ3foovE12static_local,"awG",@nobits,_ZZ3foovE12static_local,comdat .align 4 .type _ZZ3foovE12static_local, @gnu_unique_object .size
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 --- Comment #3 from Walt Karas --- (conanrunenv) [root@d761696b8abf setup-work]# cc -v Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-8/root/usr --mandir=/opt/rh/devtoolset-8/root/usr/share/man --infodir=/opt/rh/devtoolset-8/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-8.3.1-20190311/obj-x86_64-redhat-linux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC)
[Bug c++/93666] Dependence of optimization on use of constexpr seems inappropriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93666 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-02-10 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Please include all details relevant to your report, including a description of the problem you see and the expected result, in the report itself, not via links. Read https://gcc.gnu.org/bugs for more. (Links to third party sites might become dead.)
[Bug target/93663] [10 Regression] ICE in is_halfway_below, at real.c:5192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93663 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code Target||i386-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-10 CC||msebor at gcc dot gnu.org Component|c |target Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed. Bisection points to r274927. Based on the change below I assume it's a target-specific issue. 2019-08-26 Richard Biener PR target/91522 PR target/91527 * config/i386/i386-features.h (general_scalar_chain::defs_map): New member. (general_scalar_chain::replace_with_subreg): Remove. (general_scalar_chain::replace_with_subreg_in_insn): Likewise. (general_scalar_chain::convert_reg): Adjust signature. * config/i386/i386-features.c (scalar_chain::add_insn): Do not iterate over all defs of a reg. (general_scalar_chain::replace_with_subreg): Remove. (general_scalar_chain::replace_with_subreg_in_insn): Likewise. (general_scalar_chain::make_vector_copies): Populate defs_map, place copy only after defs that are used as vectors in the chain. (general_scalar_chain::convert_reg): Emit a copy for a specific def in a specific instruction. (general_scalar_chain::convert_op): All reg uses are converted here. (general_scalar_chain::convert_insn): Emit copies for scalar uses of defs here. Replace uses with the copies we created. Replace and convert the def. Adjust REG_DEAD notes, remove REG_EQUIV/EQUAL notes. (general_scalar_chain::convert_registers): Only handle copies into the chain here.
[Bug c++/93666] New: Dependence of optimization on use of constexpr seems inappropriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93666 Bug ID: 93666 Summary: Dependence of optimization on use of constexpr seems inappropriate Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wkaras at yahoo dot com Target Milestone: --- In this example, the optimization behavior changes simply by adding the constexpr keyword: https://gcc.godbolt.org/z/3zWWrH My understanding is that constexpr should not be used as a "register-esque" hint to decide whether or not to optimize. I think, for a constructor, it means, if the right conditions are met, non-locals constructed with it should be statically initialized, and are usable in compile-time const expressions. Clang compiles this example as I would expect: https://gcc.godbolt.org/z/hk6Zv5
[Bug analyzer/93350] ICE in make_region_for_type, at analyzer/region-model.cc:5975, or in get_lvalue_1, at analyzer/region-model.cc:4609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93350 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by above commit.
[Bug analyzer/93659] typo in analyzer.opt: call tha would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93659 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed by above commit.
[Bug analyzer/93647] ICE in get_lvalue_1, at analyzer/region-model.cc:4613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93647 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by above commit.
[Bug tree-optimization/93661] [10 Regression] ICE in tree_to_poly_int64, at tree.c:2976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93661 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-10 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Bisection points to r273194: 2019-07-08 Richard Biener PR tree-optimization/83518 * tree-ssa-sccvn.c: Include splay-tree.h. (struct pd_range, struct pd_data): New. (struct vn_walk_cb_data): Add data to track partial definitions. (vn_walk_cb_data::~vn_walk_cb_data): New. (vn_walk_cb_data::push_partial_def): New. (pd_tree_alloc, pd_tree_dealloc, pd_range_compare): New. (vn_reference_lookup_2): When partial defs are registered give up. (vn_reference_lookup_3): Track partial defs for memset and constructor zeroing and for defs from constants.
[Bug rtl-optimization/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658 --- Comment #3 from Peter Bergner --- I cannot recreate this with trunk or GCC 9 from today. DO you have extra patches applied or ???
[Bug libstdc++/93651] std::ranges::iota_view::iterator is not a Cpp17 input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93651 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- After consulting the C++ committee I can confirm that it's by design that iota_view's iterator does not model cpp17-input-iterator. It cannot necessarily be used in old APIs expecting an iterator. It is expected that vector and other containers will gain new constructors taking a range (after C++20), so that the old constructors taking old iterators don't need to work with new iterators.
[Bug analyzer/93659] typo in analyzer.opt: call tha would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93659 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:eb031d4ba27b3fdc292f5a1092e66024f5ee239c commit r10-6568-geb031d4ba27b3fdc292f5a1092e66024f5ee239c Author: David Malcolm Date: Mon Feb 10 16:04:13 2020 -0500 analyzer.opt: fix typos in descriptions (PR 93659) gcc/analyzer/ChangeLog: PR analyzer/93659 * analyzer.opt (-param=analyzer-max-recursion-depth=): Fix "tha" -> "that" typo. (Wanalyzer-use-of-uninitialized-value): Fix "initialized" -> "uninitialized" typo.
[Bug middle-end/93665] New: missing warning on strncmp reading past unterminated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93665
Bug ID: 93665
Summary: missing warning on strncmp reading past unterminated
array
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC 10 diagnoses the call to strcmp below because it attempts to read past the
end of the unterminated array a3 but not the call to strncmp even though it has
the same bug.
$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic z.c
const char a3[] = { 'a', 'b', 'c' };
const char s4[] = "abcd";
int f (void)
{
return __builtin_strcmp (a3, s4); // warning (good)
}
int g (void)
{
return __builtin_strncmp (a3, s4, sizeof s4); // missing warning
}
z.c: In function ‘f’:
z.c:6:10: warning: ‘__builtin_strcmp’ argument missing terminating nul
[-Wstringop-overflow=]
6 | return __builtin_strcmp (a3, s4); // warning (good)
| ^
z.c:1:12: note: referenced argument declared here
1 | const char a3[] = { 'a', 'b', 'c' };
|^~
[Bug tree-optimization/82456] missing -Wstringop-overflow on strcpy reading past the end of an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82456 Martin Sebor changed: What|Removed |Added Last reconfirmed|2019-01-14 00:00:00 |2020-2-10 Known to fail|9.0 |10.0, 9.1.0 --- Comment #2 from Martin Sebor --- No change in 10.0.
[Bug analyzer/93350] ICE in make_region_for_type, at analyzer/region-model.cc:5975, or in get_lvalue_1, at analyzer/region-model.cc:4609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93350 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:e87deb37649cfe480217fc83c8d56fe925600f93 commit r10-6567-ge87deb37649cfe480217fc83c8d56fe925600f93 Author: David Malcolm Date: Fri Feb 7 05:49:24 2020 -0500 analyzer: handle vector types (PR 93350) gcc/analyzer/ChangeLog: PR analyzer/93350 * region-model.cc (region_model::get_lvalue_1): Handle BIT_FIELD_REF. (make_region_for_type): Handle VECTOR_TYPE. gcc/testsuite/ChangeLog: PR analyzer/93350 * gcc.dg/analyzer/torture/pr93350.c: New test.
[Bug analyzer/93647] ICE in get_lvalue_1, at analyzer/region-model.cc:4613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93647 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:e953f9588d4a7ea4183d14914f915329cc37941f commit r10-6566-ge953f9588d4a7ea4183d14914f915329cc37941f Author: David Malcolm Date: Mon Feb 10 10:01:46 2020 -0500 analyzer: fix ICE reporting NULL dereference (PR 93647) gcc/analyzer/ChangeLog: PR analyzer/93647 * diagnostic-manager.cc (diagnostic_manager::prune_for_sm_diagnostic): Bulletproof against VAR being constant. * region-model.cc (region_model::get_lvalue_1): Provide a better error message when encountering an unhandled tree code. gcc/testsuite/ChangeLog: PR analyzer/93647 * gcc.dg/analyzer/torture/pr93647.c: New test.
[Bug middle-end/93646] confusing -Wstringop-truncation on strncat where -Wstringop-overflow is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93646 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00597.html
[Bug middle-end/93644] [10 Regression] spurious -Wreturn-local-addr with PHI of PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 --- Comment #6 from Jeffrey A. Law --- I think we might be able to do this in remove_range_assertions
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 --- Comment #10 from seurer at gcc dot gnu.org --- I ran the test 200,000 times on the same systems as before (p7 BE, p8 BE, 2 different p8 LE, and 2 different p9 LE) and all but one of them had at least 1 failure. One had 172. It looks like it may be failing with less frequency than before, though.
[Bug middle-end/93644] [10 Regression] spurious -Wreturn-local-addr with PHI of PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #5 from Jeffrey A. Law --- WRT c#2, yes it's a reasonable deduction, but the warning and the point where we have the asserts are in two different passes. ie, the info isn't really available when we need it. What we might be able to do is see the assert: buffer_16 = ASSERT_EXPR ; Then look at the DEF point for buffer_3: # buffer_3 = PHI <_buf(3), buffer_8(D)(9)> Which means at the point of the assertion that buffer_16 can only have the value buffer_8 and replace the assert with buffer_16 = buffer_8 That would in turn allow the use of buffer_16 in the problematic PHI to be replaced with buffer_8 and avoid the problem We have to be careful and ensure that doesn't break the SSA form (it's safe in this example because buffer_8 is the default def).
[Bug rtl-optimization/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #2 from seurer at gcc dot gnu.org --- How are you configuring ghostscript when you build it? I get a link error involving png: ./obj/pngrutil.o: In function `png_read_filter_row': pngrutil.c:(.text+0x8948): undefined reference to `png_init_filter_functions_vsx'
[Bug c++/93664] New: ICE: Segmentation fault on invalid concept code gcc/gcc/cp/constraint.cc:2537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93664
Bug ID: 93664
Summary: ICE: Segmentation fault on invalid concept code
gcc/gcc/cp/constraint.cc:2537
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
this (invalid!) code ICEs:
```c++
#include
#include
template
concept bool semiregular = requires(T t) {
{(t != t)};
};
template concept bool view_ = semiregular;
template concept bool is_true = B;
// this part is invalid, commenting in =, or
// ommiting bool resolves the ICE
template
concept bool
pair_like_convertible_from_ /*=*/ (is_true);
template
struct subrange {
template
requires pair_like_convertible_from_
operator PairLike();
};
int main() {
subrange> sub;
view_;
}
```
https://godbolt.org/z/c__ob5
When replacing all `concept bool` with `concept` the ICE vanishes.
```
> g++-git --std=c++2a
ice.cpp: In instantiation of ‘subrange::operator PairLike() [with PairLike =
const std::error_condition; I = std::istreambuf_iterator >]’:
ice.cpp:6:7: required from here
ice.cpp:6:7: internal compiler error: Segmentation fault
6 | {(t != t)};
|~~~^
0xc8026f crash_signal
/home/marehr/Packages/gcc-git/src/gcc/gcc/toplev.c:328
0x69819d force_rvalue(tree_node*, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/cvt.c:564
0x6834c2 satisfy_constraint_r
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2537
0x683bf8 satisfy_constraint
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2599
0x6845c4 satisfy_declaration_constraints
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2617
0x6850e8 constraint_satisfaction_value
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2733
0x6850e8 constraints_satisfied_p(tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2754
0x6511f2 add_function_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2281
0x6537fc add_template_candidate_real
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3440
0x653d86 add_template_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3481
0x653d86 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5829
0x64f0b5 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5744
0x64f0b5 build_user_type_conversion_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:4079
0x64fb43 reference_binding
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:1843
0x650121 implicit_conversion
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:1992
0x650e79 add_function_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2389
0x653dc4 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5842
0x654357 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5744
0x654357 add_operator_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5933
0x659344 build_new_op_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:6156
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/93637] [9 Regression] ICE: Segmentation fault (in force_operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] ICE: |[9 Regression] ICE: |Segmentation fault (in |Segmentation fault (in |force_operand) |force_operand) --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f57aa9503ff170ff6c8549718bd736f6c8168bab commit r10-6565-gf57aa9503ff170ff6c8549718bd736f6c8168bab Author: Jakub Jelinek Date: Mon Feb 10 22:44:40 2020 +0100 i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637] As mentioned in the PR, for -mavx -mno-avx2 the backend does support vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors aren't much supported in that case, it is performed using vandps/vandnps/vorps). The problem is that after the last generic vector lowering (where the VEC_COND_EXPR still compares two V4DF vectors and has two V4DI last operands and V4DI result and so is considered ok) fre4 folds the condition into constant, at which point the middle-end during expansion will try vcond_mask_optab and fall back to trying to expand it as the constant vector < 0 vcondv4div4di, but neither of them is supported for -mavx -mno-avx2 and thus we ICE. So, the options I see is either what the following patch does, also support vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current TARGET_AVX. 2020-02-10 Jakub Jelinek PR target/93637 * config/i386/sse.md (VI_256_AVX2): New mode iterator. (vcond_mask_): Use it instead of VI_256. Change condition from TARGET_AVX2 to TARGET_AVX. * gcc.target/i386/avx-pr93637.c: New test.
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 --- Comment #9 from seurer at gcc dot gnu.org --- I just tried the patch and am still seeing failures on at least some systems.
[Bug analyzer/93405] Passing constant arguments to subroutines in Fortran ... and the analyzer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405 David Malcolm changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|11.0|10.0 --- Comment #7 from David Malcolm --- Should be resolved by above patch.
[Bug analyzer/93405] Passing constant arguments to subroutines in Fortran ... and the analyzer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405 --- Comment #6 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:41a9e940c7014f117738a9a59b31833047a1083d commit r10-6564-g41a9e940c7014f117738a9a59b31833047a1083d Author: David Malcolm Date: Wed Feb 5 16:48:53 2020 -0500 analyzer: fix ICE with fortran constant arguments (PR 93405) PR analyzer/93405 reports an ICE with -fanalyzer when passing a constant "by reference" in gfortran. The issue is that the constant is passed as an ADDR_EXPR of a CONST_DECL, and region_model::get_lvalue_1 doesn't know how to handle CONST_DECL. This patch implements it for CONST_DECL by providing a placeholder region, holding the CONST_DECL's value, fixing the ICE. gcc/analyzer/ChangeLog: PR analyzer/93405 * region-model.cc (region_model::get_lvalue_1): Implement CONST_DECL. gcc/testsuite/ChangeLog: PR analyzer/93405 * gfortran.dg/analyzer/pr93405.f90: New test.
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 --- Comment #25 from mark --- As suggested, I've posted my comments as a question to the gcc-help mailing list, viewable at https://gcc.gnu.org/ml/gcc-help/2020-02/msg00048.html Further comments and suggestions are welcome as replies on the list. Thanks.
[Bug analyzer/93659] typo in analyzer.opt: call tha would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93659 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-10 Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- Thanks. I'm working on a patch.
Request For Partnership
Hello, CLI Investment Group here in New York, an affiliate of CLI Ventures. We are a Financial Investment Company looking for Company(s) with profitable projects or entrepreneurial teams that require partnership. We are focusing on supporting early to late stage Companies. If interested, please contact us for details and procedures. Regards, Samuel Price. Loan Administration CLI Investment Group 14 Wall St, New York, NY 10005 U.S.A Email: samuel.pr...@cliinvestmentgroups.com Samuel Price 14 Wall St , New York , NY 10005 Unsubscribe ( https://u14851712.ct.sendgrid.net/wf/unsubscribe?upn=PQSYFRt-2Bwqd75usGEgqqWVXdK29tZgmSzJh7GonUuAVbCv-2FKKZ8RusZa4MzJD0lqJM6VNAkZo63mi4GOw3dkC0uyDOiFbNk6oS2xXA0CpZoUaFj9I0xYYRGzTTdgODlWomga8ywHWVbZf1qHAE9VGLjeCnSzVeDiU-2FW4632cYt2P7cEFFfHUhV-2Fqgy33Wq7KfoEhFNtRy-2F-2FHvfQNBxHmOkR9Z7Sl1k2Q3g7WOsgViZGvfA9dPZwLR7-2Fm4BSbB-2FV1xYqWl0YgCDWW24t7Ouv5u7DewHMNe1HOV9UxX7yh3ZFpUZxsqIRSg15EjJws3sciOuBJUkU-2Bvi9jxVCN1nExpeEZvP5HhkB9bnDMwJ88bk9gJV-2Frj0s3Ke0kIjPgiS7hEptsWOK1y4NxKxvQmnussiDKpxxbdgiqmKLiEnz7hPKejj3wOscxS7PsZa9KqP8tIkZtoql-2BW0Dg2ZGK1i0xf-2FCebNw3biA3ERqG857BeeENPLZJRLn0vLrO-2BGTjcbWGSzZRSFklUfLQM-2BifJaYXq83REbKCmk138sQStvr2FYzKuCA42dyZ53cnZaZUgEhzATjiAlZJJVN5ZSkYhGS-2FhvfespaSmbTZxizRGuIjlsEePqv3BpMuliDcLiCXEq7eewHSC4wbJHEu2s5AM-2Bt0Ng-3D-3D )
[Bug analyzer/93657] Ambiguous wording "is doing to"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93657 --- Comment #2 from David Malcolm --- common.opt's has: fdump- Common Joined RejectNegative Var(common_deferred_options) Defer -fdump- Dump various compiler internals to a file. so how about: fdump-analyzer Common RejectNegative Var(flag_dump_analyzer) Dump various analyzer internals to SRCFILE.analyzer.txt. fdump-analyzer-stderr Common RejectNegative Var(flag_dump_analyzer_stderr) Dump various analyzer internals to stderr.
[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93643 --- Comment #4 from Andrew Pinski --- (In reply to Iñaki Ucar from comment #3) > I got no backtrace, just the output shown in my first comment, at least with > the gcc version included in Fedora Rawhide. I've just attached the test.ii > file too. With -v: Yes that is because the GCC is configured with "--enable-checking=release".
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 --- Comment #19 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #18) > > For bitfields there's also the ever present bitfield-lowering idea... > > I understood Andrew P. is working on something, but no idea how far it is. I am working towards regression free. I have most of it completed, the store merging regression is the main thing which is blocking it. > > > And the fact that optimize_bit_field_compare is done way too early. > > Agreed on that. Agreed there too.
[Bug tree-optimization/93661] [10 Regression] ICE in tree_to_poly_int64, at tree.c:2976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93661 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |10.0 --- Comment #1 from Andrew Pinski --- Note that memset is undefined. -1 is all of the size.
[Bug c/93663] New: [10 Regression] ICE in is_halfway_below, at real.c:5192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93663
Bug ID: 93663
Summary: [10 Regression] ICE in is_halfway_below, at
real.c:5192
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20190825 and 20190901 :
$ cat z1.c
void f() {roundeven(0x0.1p1128);}
$ gcc-10-20200209 -c z1.c -O2
z1.c: In function 'f':
z1.c:1:11: warning: implicit declaration of function 'roundeven'
[-Wimplicit-function-declaration]
1 | void f() {roundeven(0x0.1p1128);}
| ^
z1.c:1:11: warning: incompatible implicit declaration of built-in function
'roundeven'
z1.c:1:1: warning: floating constant exceeds range of 'double' [-Woverflow]
1 | void f() {roundeven(0x0.1p1128);}
| ^~~~
z1.c:1:1: internal compiler error: in is_halfway_below, at real.c:5192
0xc23e0b is_halfway_below(real_value const*)
../../gcc/real.c:5192
0xc23e24 real_roundeven(real_value*, format_helper, real_value const*)
../../gcc/real.c:5226
0x95c8fd fold_const_call_ss
../../gcc/fold-const-call.c:877
0x95ea12 fold_const_call_1
../../gcc/fold-const-call.c:1213
0x78c957 fold_builtin_1
../../gcc/builtins.c:10043
0x78c957 fold_builtin_n
../../gcc/builtins.c:10332
0x959a31 fold(tree_node*)
../../gcc/fold-const.c:12690
0x6d9a5c c_fully_fold_internal
../../gcc/c/c-fold.c:626
0x6dd417 c_fully_fold(tree_node*, bool, bool*, bool)
../../gcc/c/c-fold.c:125
0x670201 c_process_expr_stmt(unsigned int, tree_node*)
../../gcc/c/c-typeck.c:11095
0x6705ed c_finish_expr_stmt(unsigned int, tree_node*)
../../gcc/c/c-typeck.c:11140
0x6ca18a c_parser_statement_after_labels
../../gcc/c/c-parser.c:6294
0x6cc340 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5800
0x6ccaf6 c_parser_compound_statement
../../gcc/c/c-parser.c:5616
0x6ce431 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2504
0x6d8237 c_parser_external_declaration
../../gcc/c/c-parser.c:1746
0x6d8d59 c_parser_translation_unit
../../gcc/c/c-parser.c:1619
0x6d8d59 c_parse_file()
../../gcc/c/c-parser.c:21710
0x73df70 c_common_parse_file()
../../gcc/c-family/c-opts.c:1186
[Bug fortran/93662] New: [10 Regression] ICE in tree_to_poly_int64, at tree.c:2976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93662 Bug ID: 93662 Summary: [10 Regression] ICE in tree_to_poly_int64, at tree.c:2976 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20191103 (error) and 20191110 (ICE) at -O1+ : (for some reason much later than pr93661 ...) $ cat z1.f90 subroutine s type t integer, allocatable :: a character(huge(1_8)) :: c end type class(t), allocatable :: x allocate(t :: x) end $ cat z2.f90 subroutine s type t integer, allocatable :: a character(2_8**60) :: c end type class(t), allocatable :: x allocate(t :: x) end $ gfortran-10-20200209 -c z1.f90 -O2 z1.f90:1:12: 1 | subroutine s |1 Warning: size of '__def_init_s_T' 9223372036854775816 bytes exceeds maximum object size 9223372036854775807 [-Wlarger-than=] z1.f90:7:0: 7 |allocate(t :: x) | Warning: size of 't.6' 9223372036854775816 bytes exceeds maximum object size 9223372036854775807 [-Wlarger-than=] f951: Warning: size of '' 9223372036854775816 bytes exceeds maximum object size 9223372036854775807 [-Wlarger-than=] f951: Warning: size of '' 9223372036854775816 bytes exceeds maximum object size 9223372036854775807 [-Wlarger-than=] during GIMPLE pass: esra z1.f90:8:0: 8 | end | internal compiler error: in tree_to_poly_int64, at tree.c:2976 0x10403e2 tree_to_poly_int64(tree_node const*) ../../gcc/tree.c:2976 0xe45ed1 get_access_for_expr ../../gcc/tree-sra.c:3608 0xe4a7cb sra_modify_assign ../../gcc/tree-sra.c:4002 0xe4a7cb sra_modify_function_body ../../gcc/tree-sra.c:4325 0xe4a7cb perform_intra_sra ../../gcc/tree-sra.c:4435
[Bug c/93661] New: [10 Regression] ICE in tree_to_poly_int64, at tree.c:2976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93661
Bug ID: 93661
Summary: [10 Regression] ICE in tree_to_poly_int64, at
tree.c:2976
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20190630 and 20190728 :
$ cat z1.c
int f ()
{
unsigned x = 0x;
__builtin_memset (1+(char *) , 0, -1);
return (x != 0xf000);
}
$ gcc-10-20200209 -c z1.c -O2
during GIMPLE pass: fre
z1.c: In function 'f':
z1.c:6:1: internal compiler error: in tree_to_poly_int64, at tree.c:2976
6 | }
| ^
0xfd0a42 tree_to_poly_int64(tree_node const*)
../../gcc/tree.c:2976
0xecb460 vn_reference_lookup_3
../../gcc/tree-ssa-sccvn.c:2507
0xdf6910 walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
../../gcc/tree-ssa-alias.c:3568
0xec235e vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**)
../../gcc/tree-ssa-sccvn.c:3225
0xecd452 visit_reference_op_load
../../gcc/tree-ssa-sccvn.c:4547
0xecd452 visit_stmt
../../gcc/tree-ssa-sccvn.c:4964
0xecea9b process_bb
../../gcc/tree-ssa-sccvn.c:6633
0xed0c80 do_rpo_vn
../../gcc/tree-ssa-sccvn.c:7152
0xed168f execute
../../gcc/tree-ssa-sccvn.c:7420
[Bug analyzer/93659] typo in analyzer.opt: call tha would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93659 --- Comment #1 from Roland Illig --- And another typo, from the same file: - Warn about code paths in which an initialized value is used. + Warn about code paths in which an uninitialized value is used.
[Bug fortran/93660] New: ICE in ipa_simd_modify_function_body, at omp-simd-clone.c:993
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93660 Bug ID: 93660 Summary: ICE in ipa_simd_modify_function_body, at omp-simd-clone.c:993 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r7 : $ cat z1.f90 integer function f(x) integer :: x[*] !$omp declare simd f = x[1] end $ gfortran-10-20200209 -c z1.f90 -fopenmp -fcoarray=single $ $ gfortran-10-20200209 -c z1.f90 -fopenmp -fcoarray=lib during IPA pass: simdclone z1.f90:5:0: 5 | end | internal compiler error: in ipa_simd_modify_function_body, at omp-simd-clone.c:993 0x179e6cc ipa_simd_modify_function_body ../../gcc/omp-simd-clone.c:993 0x179f330 simd_clone_adjust ../../gcc/omp-simd-clone.c:1188 0x17a3faf expand_simd_clones(cgraph_node*) ../../gcc/omp-simd-clone.c:1751 0x17a4af7 ipa_omp_simd_clone ../../gcc/omp-simd-clone.c:1772 0x17a4af7 execute ../../gcc/omp-simd-clone.c:1800
[Bug analyzer/93659] New: typo in analyzer.opt: call tha would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93659 Bug ID: 93659 Summary: typo in analyzer.opt: call tha would Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from analyzer.opt: - call tha would + call that would
[Bug rtl-optimization/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658 Matthias Klose changed: What|Removed |Added Keywords||ra Target||powerpc64le-linux-gnu Known to work||9.2.0 Known to fail||10.0, 9.2.1 --- Comment #1 from Matthias Klose --- memory usage stays constant at about 2GB, the package build gets cancelled after 150 minutes.
[Bug rtl-optimization/93658] New: [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658 Bug ID: 93658 Summary: [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: doko at ubuntu dot com Target Milestone: --- Created attachment 47813 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47813=edit preprocessed source seen with gcc-9 and trunk 20200204, building ghostscript and icu with -O3 on powerpc64le-linux-gnu. Falling back to -O2 lets the build succeed, a -O3 build on x86_64-linux-gnu succeeds. Program received signal SIGTSTP, Stopped (user). push_to_sequence (first=0x7320d580) at ../../src/gcc/emit-rtl.c:5574 5574../../src/gcc/emit-rtl.c: No such file or directory. (gdb) bt #0 push_to_sequence (first=0x7320d580) at ../../src/gcc/emit-rtl.c:5574 #1 0x10843000 in process_address_1 (nop=nop@entry=0, check_only_p=check_only_p@entry=false, before=before@entry=0x7fffdbf0, after=after@entry=0x7fffdbe8) at ../../src/gcc/lra-constraints.c:3434 #2 0x1084527c in process_address (after=, before=, check_only_p=, nop=) at ../../src/gcc/lra-constraints.c:3637 #3 curr_insn_transform (check_only_p=check_only_p@entry=false) at ../../src/gcc/lra-constraints.c:3952 #4 0x1084ad10 in lra_constraints (first_p=) at ../../src/gcc/lra-constraints.c:5025 #5 0x10833940 in lra (f=) at ../../src/gcc/lra.c:2437 #6 0x107d893c in do_reload () at ../../src/gcc/ira.c:5518 #7 (anonymous namespace)::pass_reload::execute (this=) at ../../src/gcc/ira.c:5704 #8 0x10928280 in execute_one_pass (pass=pass@entry=0x11d106f0) at ../../src/gcc/passes.c:2500 #9 0x10929314 in execute_pass_list_1 (pass=0x11d106f0) at ../../src/gcc/passes.c:2588 #10 0x1092932c in execute_pass_list_1 (pass=0x11d0f4f0) at ../../src/gcc/passes.c:2589 #11 0x109293b8 in execute_pass_list (fn=, pass=) at ../../src/gcc/passes.c:2599 #12 0x104f4a2c in cgraph_node::expand (this=0x76ee7d28) at ../../src/gcc/context.h:48 #13 0x104f600c in expand_all_functions () at ../../src/gcc/cgraphunit.c:2454 #14 symbol_table::compile (this=this@entry=0x752f) at ../../src/gcc/cgraphunit.c:2804 #15 0x104f8c54 in symbol_table::compile (this=0x752f) at ../../src/gcc/cgraphunit.c:2984 #16 symbol_table::finalize_compilation_unit (this=0x752f) at ../../src/gcc/cgraphunit.c:2984 #17 0x10a321bc in compile_file () at ../../src/gcc/toplev.c:483 #18 0x10187c8c in do_compile () at ../../src/gcc/toplev.c:2273 #19 toplev::main (this=0x7fffe6a0, argc=, argv=) at ../../src/gcc/toplev.c:2412 #20 0x10189e78 in main (argc=, argv=0x7fffeac8) at ../../src/gcc/main.c:39 GCC defaults to hardening options and is configured using --enable-languages=c,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=powerpc64le-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos --enable-objc-gc=auto --enable-secureplt --with-cpu=power8 --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
[Bug analyzer/93657] Ambiguous wording "is doing to"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93657 Andrew Pinski changed: What|Removed |Added Keywords||documentation --- Comment #1 from Andrew Pinski --- Maybe: Dump to SRCFILE.analyzer.txt, internal details about what the analyzer is doing. By the way I don't think it is that ambiguous; just english is full of ambiguities in general.
[Bug analyzer/93657] New: Ambiguous wording "is doing to"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93657 Bug ID: 93657 Summary: Ambiguous wording "is doing to" Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From analyzer.opt: > Dump internal details about what the analyzer is doing to > SRCFILE.analyzer.txt. What is the analyzer doing to the SRCFILE? No harm, I hope. (I don't know whether the string becomes less ambiguous in its natural context; when I tried to translate it to German, I picked the wrong AST.)
[Bug ipa/93203] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5448 since r278893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93203 --- Comment #4 from David Binderman --- Another false result produced by my bad gcc config. Please ignore my previous comment.
[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549 --- Comment #9 from David Binderman --- False alarm. Sorry. Bad raspberry pi config.
[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635
--- Comment #2 from Steve Kargl ---
On Sun, Feb 09, 2020 at 06:39:31PM +, kargl at gcc dot gnu.org wrote:
>
> Fortuantely, I
> use neither namelist nor equivalence, so have no skin in the
> game. Someone else can complete the fix.
>
Here's a patch that fixes the issue and cures the ICE in the
old testcase. Whoever commit patch needs to convert the
example code here into a testcase.
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 280157)
+++ gcc/fortran/symbol.c(working copy)
@@ -394,18 +395,35 @@ gfc_check_function_type (gfc_namespace *ns)
/ Symbol attribute stuff */
+/* Older standard produced conflicts for some attributes that are now
+ allowed in newer standards. Check for the conflict and issue an
+ error depending on the standard in play. */
+
+static bool
+conflict_std (int standard, const char *a1, const char *a2, const char *name,
+ locus *where)
+{
+ if (name == NULL)
+{
+ return gfc_notify_std (standard, "%s attribute conflicts "
+ "with %s attribute at %L", a1, a2,
+ where);
+}
+ else
+{
+ return gfc_notify_std (standard, "%s attribute conflicts "
+"with %s attribute in %qs at %L",
+ a1, a2, name, where);
+}
+}
+
+
+
/* This is a generic conflict-checker. We do this to avoid having a
single conflict in two places. */
#define conf(a, b) if (attr->a && attr->b) { a1 = a; a2 = b; goto conflict; }
#define conf2(a) if (attr->a) { a2 = a; goto conflict; }
-#define conf_std(a, b, std) if (attr->a && attr->b)\
- {\
-a1 = a;\
-a2 = b;\
-standard = std;\
-goto conflict_std;\
- }
bool
gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where)
@@ -438,7 +456,7 @@ gfc_check_conflict (symbol_attribute *attr, const char
"OACC DECLARE DEVICE_RESIDENT";
const char *a1, *a2;
- int standard;
+ bool standard;
if (attr->artificial)
return true;
@@ -450,16 +468,18 @@ gfc_check_conflict (symbol_attribute *attr, const char
{
a1 = pointer;
a2 = intent;
- standard = GFC_STD_F2003;
- goto conflict_std;
+ standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+ if (!standard)
+ return standard;
}
if (attr->in_namelist && (attr->allocatable || attr->pointer))
{
a1 = in_namelist;
a2 = attr->allocatable ? allocatable : pointer;
- standard = GFC_STD_F2003;
- goto conflict_std;
+ standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+ if (!standard)
+ return standard;
}
/* Check for attributes not allowed in a BLOCK DATA. */
@@ -566,9 +586,31 @@ gfc_check_conflict (symbol_attribute *attr, const char
return false;
conf (allocatable, pointer);
- conf_std (allocatable, dummy, GFC_STD_F2003);
- conf_std (allocatable, function, GFC_STD_F2003);
- conf_std (allocatable, result, GFC_STD_F2003);
+ if (attr->allocatable && attr->dummy)
+{
+ a1 = allocatable;
+ a2 = dummy;
+ standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+ if (!standard)
+ return standard;
+}
+ if (attr->allocatable && attr->function)
+{
+ a1 = allocatable;
+ a2 = function;
+ standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+ if (!standard)
+ return standard;
+}
+ if (attr->allocatable && attr->result)
+{
+ a1 = allocatable;
+ a2 = result;
+ standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+ if (!standard)
+ return standard;
+}
+
conf (elemental, recursive);
conf (in_common, dummy);
@@ -908,25 +950,10 @@ conflict:
a1, a2, name, where);
return false;
-
-conflict_std:
- if (name == NULL)
-{
- return gfc_notify_std (standard, "%s attribute conflicts "
- "with %s attribute at %L", a1, a2,
- where);
-}
- else
-{
- return gfc_notify_std (standard, "%s attribute conflicts "
-"with %s attribute in %qs at %L",
- a1, a2, name, where);
-}
}
#undef conf
#undef conf2
-#undef conf_std
/* Mark a symbol as referenced. */
@@ -4039,6 +4066,31 @@ gfc_free_namespace (gfc_namespace *ns)
ns->refs--;
if (ns->refs > 0)
return;
+
+ /* If an error occurred while parsing a submodule, the namespace is freed.
+ However, gfortran reaches a ref count of -1. Note, gfc_state_stack does
+ not
[Bug other/93641] Wrong strncmp and strncasecmp size arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93641 --- Comment #6 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:c88ffcc6f4f46223c219014729f33f6cb9649928 commit r10-6561-gc88ffcc6f4f46223c219014729f33f6cb9649928 Author: Iain Sandoe Date: Mon Feb 10 20:29:30 2020 +0100 Darwin: -Wformat-diag fix (PR93641) The length used for the comparison for 'CFStringRef' was only comparing for 'CFString', potentially allowing mismatched identifiers. 2020-02-10 Iain Sandoe PR other/93641 * config/darwin-c.c (darwin_cfstring_ref_p): Fix up last argument of strncmp.
[Bug fortran/83113] Bogus "duplicate allocatable attribute" error for submodule character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113 Andrew Benson changed: What|Removed |Added Status|NEW |RESOLVED CC||abensonca at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from Andrew Benson --- Fixed by https://gcc.gnu.org/g:7848054c68bad6e2aa40cb59f77cc99bd8448d52
[Bug fortran/89943] Submodule functions are not allowed to have C binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89943 Bug 89943 depends on bug 83113, which changed state. Bug 83113 Summary: Bogus "duplicate allocatable attribute" error for submodule character function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/83113] Bogus "duplicate allocatable attribute" error for submodule character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113 --- Comment #10 from CVS Commits --- The master branch has been updated by Andrew Benson : https://gcc.gnu.org/g:7848054c68bad6e2aa40cb59f77cc99bd8448d52 commit r10-6560-g7848054c68bad6e2aa40cb59f77cc99bd8448d52 Author: Andrew Benson Date: Mon Feb 10 17:59:34 2020 + Fix bogus duplicate attribute errors for submodule functions. PR fortran/83113 * array.c: Do not attempt to set the array spec for a submodule function symbol (as it has already been set in the corresponding module procedure interface). * symbol.c: Do not reject duplicate POINTER, ALLOCATABLE, or DIMENSION attributes in declarations of a submodule function. * gfortran.h: Add a macro that tests for a module procedure in a submodule. * gfortran.dg/pr83113.f90: New test.
[Bug target/93656] New: FAIL: gcc.target/i386/pr67770.c execution test with -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656
Bug ID: 93656
Summary: FAIL: gcc.target/i386/pr67770.c execution test with
-fcf-protection
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Blocks: 81652
Target Milestone: ---
Target: i386
On Linux/x86-64,
$ make check-gcc RUNTESTFLAGS="--target_board='unix{-m32\ -fcf-protection}'
i386.exp=pr67770.c"
...
FAIL: gcc.target/i386/pr67770.c execution test
...
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full bugs
[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 H.J. Lu changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #12 from H.J. Lu --- Fixed for GCC 10, GCC 9.3 and GCC 8.4.
[Bug target/81652] [meta-bug] -fcf-protection=full bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 85334, which changed state. Bug 85334 Summary: Shadow stack isn't unwound properly through signal handler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug c/93653] diagnose calls to strncmp with bound less than constant string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93653 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I think we should warn about this if the second argument is a string literal, not when optimizers propagate a pointer to a string literal to it, so do it in the FEs, make sure it handles strncmp inline -D_FORTIFY_SOURCE=2 wrapper and also handle strncasecmp as well.
[Bug middle-end/93655] New: diagnose calls to strncmp with bound greater than constant string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93655
Bug ID: 93655
Summary: diagnose calls to strncmp with bound greater than
constant string length
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In addition to pr93653, the -Wstring-compare warning (new in GCC 10) could also
diagnose strncmp calls where the bound is so large that it could cause the
function to read past the end of one of the string, as is possible in all three
instances below. The warning should be issued regardless of how the result of
the call is used (i.e., for equality or otherwise).
$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic x.c
char a2[2], a3[3];
int f (void)
{
return __builtin_strncmp (a3, "12", 5); // missing warning
}
int g (void)
{
return __builtin_strncmp (a3, a2, 7); // missing warning
}
int h (const char *s)
{
return __builtin_strncmp (a3, s, 7); // missing warning
}
[Bug c/93653] diagnose calls to strncmp with bound less than constant string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93653 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug c/93640] The write_only and read_write attributes can be mistyped due to invalid strncmp size argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93640 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #4 from Martin Sebor --- Fixed.
[Bug c/93640] The write_only and read_write attributes can be mistyped due to invalid strncmp size argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93640 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:0cc575e4d8b68b743e07da02a74733f9b5cb585a commit r10-6559-g0cc575e4d8b68b743e07da02a74733f9b5cb585a Author: Martin Sebor Date: Mon Feb 10 10:27:00 2020 -0700 PR c/93640 - The write_only and read_write attributes can be mistyped due to invalid strncmp size argument gcc/c-family/ChangeLog: PR c/93640 * c-attribs.c (handle_access_attribute): Correct off-by-one mistakes. gcc/testsuite/ChangeLog: PR c/93640 * gcc.dg/attr-access.c: New test.
[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #8 from David Binderman --- I tried the pr93549.C source code file on ARM based raspberry pi hardware and the compiler crashed. No optimisation flags required.
[Bug ipa/93203] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5448 since r278893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93203 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #3 from David Binderman --- I tried the source code file pr93203.C on ARM raspberry pi hardware with compiler flag -O3 and it crashed a little later at line 5467. Maybe the patch isn't quite right at optimisation level -O3 ?
[Bug target/93654] New: Inappropriate "- -fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 Bug ID: 93654 Summary: Inappropriate "- -fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: andrew.cooper3 at citrix dot com Target Milestone: --- Bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87412 prohibited the use of -fcf-protection and -mindirect-branch=thunk in combination. However, it also breaks kernels which use -mindirect-branch=thunk-extern When retpoline protections were developed, I specifically requested thunk-extern to exist for kernels which provide their own, so that it can be made compatible with CET. A kernel which provides its own thunks will boot-time modify them to be appropriate for the system, and may not be a retpoline gadget. (They may be lfence; jmp *%reg which is recommended on AMD, or just jmp *%reg with IBRS) -mindirect-branch=thunk-extern specifically should be permitted with -fcf-protection, because this *was* the plan to make a single binary capable of using CET on applicable hardware, yet being safe to Spectre v2 on older hardware.
[Bug c/93653] New: diagnose calls to strncmp with bound less than constant string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93653
Bug ID: 93653
Summary: diagnose calls to strncmp with bound less than
constant string length
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
-Wstring-compare diagnoses equality expressions involving calls to strcmp and
strncmp that evaluate to constant s based on the size of one argument and the
length of another. Such calls are likely mistakes (it makes little sense to
compare a longer string for equality to a smaller array).
Another class of mistakes -Wstring-compare could help detect is those pointed
out in pr93640 and pr93641: calls with constant bounds that are less than the
length of the constant string argument. These should probably be detected and
diagnosed early, before non-constant expressions have been folded into
constants. Another question is whether the string arguments should be limited
to literals or whether all constant strings should be considered.
$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic x.c
char a[2];
int f (void)
{
return __builtin_strncmp (a, "123", 3) == 0; // warning
}
int g (const char *s)
{
return __builtin_strncmp (s, "123", 2) == 0; // should warn
}
x.c: In function ‘f’:
x.c:5:10: warning: ‘__builtin_strncmp’ of a string of length 3, an array of
size 2 and bound of 3 evaluates to nonzero [-Wstring-compare]
5 | return __builtin_strncmp (a, "123", 3) == 0; // warning
| ^~~
[Bug target/93372] cris performance regressions due to de-cc0 work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93372 --- Comment #1 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:7573521f46427d36a203f72794af7188ce04de88 commit r10-6557-g7573521f46427d36a203f72794af7188ce04de88 Author: Hans-Peter Nilsson Date: Mon Feb 10 17:39:00 2020 +0100 gcc.target/cris/pr93372-3.c, -4.c...-35.c: New tests. PR target/93372 * gcc.target/cris/pr93372-3.c, gcc.target/cris/pr93372-4.c, gcc.target/cris/pr93372-6.c, gcc.target/cris/pr93372-7.c, gcc.target/cris/pr93372-9.c, gcc.target/cris/pr93372-10.c, gcc.target/cris/pr93372-11.c, gcc.target/cris/pr93372-12.c, gcc.target/cris/pr93372-13.c, gcc.target/cris/pr93372-14.c, gcc.target/cris/pr93372-15.c, gcc.target/cris/pr93372-16.c, gcc.target/cris/pr93372-17.c, gcc.target/cris/pr93372-18.c, gcc.target/cris/pr93372-19.c, gcc.target/cris/pr93372-20.c, gcc.target/cris/pr93372-21.c, gcc.target/cris/pr93372-22.c, gcc.target/cris/pr93372-23.c, gcc.target/cris/pr93372-24.c, gcc.target/cris/pr93372-25.c, gcc.target/cris/pr93372-26.c, gcc.target/cris/pr93372-27.c, gcc.target/cris/pr93372-28.c, gcc.target/cris/pr93372-29.c, gcc.target/cris/pr93372-30.c, gcc.target/cris/pr93372-31.c, gcc.target/cris/pr93372-32.c, gcc.target/cris/pr93372-33.c, gcc.target/cris/pr93372-34.c, gcc.target/cris/pr93372-35.c: New tests. Check that somewhat-trivially eliminable compare-instructions are eliminated, for all instructions. Note that pr93372-23.c and pr93372-24.c are xfailed with cc0.
[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91489 --- Comment #4 from Paul Gofman --- I suppose I figured a better way to fix this and sent the patch to the mailing list: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00554.html
[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:3fde3398341ba900ed2e1eaecf00799fda66686a commit r9-8208-g3fde3398341ba900ed2e1eaecf00799fda66686a Author: H.J. Lu Date: Mon Feb 10 07:58:45 2020 -0800 i386: Properly pop restore token in signal frame Linux CET kernel places a restore token on shadow stack for signal handler to enhance security. The restore token is 8 byte and aligned to 8 bytes. It is usually transparent to user programs since kernel will pop the restore token when signal handler returns. But when an exception is thrown from a signal handler, now we need to pop the restore token from shadow stack. For x86-64, we just need to treat the signal frame as normal frame. For i386, we need to search for the restore token to check if the original shadow stack is 8 byte aligned. If the original shadow stack is 8 byte aligned, we just need to pop 2 slots, one restore token, from shadow stack. Otherwise, we need to pop 3 slots, one restore token + 4 byte padding, from shadow stack. This patch also includes 2 tests, one has a restore token with 4 byte padding and one without. Tested on Linux/x86-64 CET machine with and without -m32. libgcc/ Backport from mainline PR libgcc/85334 * config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment): New. gcc/testsuite/ Backport from mainline PR libgcc/85334 * g++.target/i386/pr85334-1.C: New test. * g++.target/i386/pr85334-2.C: Likewise. (cherry picked from commit bf6465d0461234ccd45ae34d5e2375a0bee0081d)
[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:86edfcfeccf16a30e541883532d9bdbece5d9f60 commit r10-6551-g86edfcfeccf16a30e541883532d9bdbece5d9f60 Author: Jakub Jelinek Date: Mon Feb 10 17:05:58 2020 +0100 arm: Add testcase for already fixed ICE [PR91913] 2020-02-10 Jakub Jelinek PR target/91913 * gfortran.dg/pr91913.f90: New test.
