[Bug tree-optimization/92233] New: missed optimisation for multiplication when it's known that at least one of the arguments is 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92233
Bug ID: 92233
Summary: missed optimisation for multiplication when it's known
that at least one of the arguments is 0
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: SztfG at yandex dot ru
Target Milestone: ---
testcase:
unsigned test_mult(unsigned a, unsigned b)
{
if ((a == 0) || (b == 0))
{
return a*b; // here a*0 or 0*b or 0*0 - always 0
}
return 0;
}
So this function should always return 0 no matter what, but GCC generate
comparisons and imul instruction, even with -O3
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #3 from Jerry DeLisle --- Created attachment 47116 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47116=edit Peliminary patch This is a preliminary patch to allow others to check the results
[Bug c/44515] improve message for missing ";"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44515 --- Comment #10 from Eric Gallager --- (In reply to David Malcolm from comment #9) > Trunk now emits: > > t.c: In function ‘foo’: > t.c:4:8: error: expected ‘;’ before ‘}’ token >bar() > ^ > ; > t.c:7:1: > } > ~ > > (as of r253690, I believe). > > This improves the location for the diagnostic (and adds a fix-it hint), but > it doesn't address the wording of the message, hence I'm keeping this PR > open. I think the improvement of the location and the addition of the fix-it is enough, personally, but maybe others have different opinions...
[Bug tree-optimization/92229] Optimization makes it impossible to read overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-10-26 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- >One could make the code more readable by using: This is very problematic. How do you know what statement, __builtin_overflow_p should be associated with? Take C++ code, where the types of a and b are not integer, how do you handle that? Likewise about floating point types? What does it mean to overflow floating point types. Even unsigned types, there is no overflow for them in the C/C++ language itself but the definitions of __builtin_umul*_overflow describe it as not a property of the language but rather if the multiple would not fit exactly from the infinite percission case.
[Bug target/92227] Optimizations on constant integer overflow checks lead to incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92227 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu Status|UNCONFIRMED |WAITING Last reconfirmed||2019-10-26 Component|tree-optimization |target Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- __builtin_sadd_overflow does not need to clobber or set any flags if is done correctly. Just like a compare might be done without using the flags register. I don't see what you are exactly complaining about if __builtin_sadd_overflow produces the correct results.
[Bug tree-optimization/92229] Optimization makes it impossible to read overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229 --- Comment #2 from Ariel Torti --- (In reply to jos...@codesourcery.com from comment #1) > Built-in functions related to integer overflow should be defined in terms > of the C abstract machine model, not in terms of processor flags. They should indeed, but what I want to implement here is a function that outputs the value of the OV flag, a behavior that cannot be achieved as a consequence of optimizations. > See recent WG14 discussions around this issue for various language design > ideas. Could you provide a link to the discussion in WG14 ? I'm not subscribed to it and I cannot find it.
[Bug c++/92232] New: [C++17] Unable to deduce template function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92232
Bug ID: 92232
Summary: [C++17] Unable to deduce template function parameter
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel at hebirobotics dot com
Target Milestone: ---
When trying to use a function pointer (which has a non-void return type and one
or more parameters) as a template argument parameter - whose return type is
specified as `auto` and one of its arguments is dependent on another template
typename - GCC fails to deduce the function template parameter.
A simplified use case is as followed:
---
enum MyEnumT {};
struct MyStructDecl;
typedef MyStructDecl* MyStructDeclPtr;
MyEnumT myFunc(MyStructDeclPtr, int someArg);
template
void deducer(FirstArgT arg, int i) {
auto ret = functor(arg, i);
// Something
}
int main() {
deducer(nullptr, 12);
}
---
Some interesting and potentially relevant notes:
* If you change the problematic template function parameter
(`auto(*functor)(FirstArgT, int)`) to have a `MyEnumT` return type
(`MyEnumT(*functor)(FirstArgT, int)`), the code will compile
* If you change the problematic template function parameter to accept a
non-template typename as the first parameter (`auto(*functor)(MyStructDeclPtr,
int)`), the code will compile.
I've seen this as an issue on 9.1 and 9.2, but I assume it to be an issue for
any version which can utilize C++17. This code compiles without any issues on
both Clang and MSVC ( https://gcc.godbolt.org/z/EIcOJc ).
[Bug c++/91165] [10 Regression] error: location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #3 from Marek Polacek ---
Cleaned up testcase:
template constexpr T bar(T c) { return c; }
template struct S {
T f;
U g;
constexpr S(T c, U h) : f(c), g(h) {}
};
template
constexpr S foo(T &, U h) {
return S(c, bar (h));
}
enum { X };
class C {
void m_fn1() const;
};
void
baz (int a)
{
foo(a, "");
}
void C::m_fn1() const { foo(X, ""); }
[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91661
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
The following patch fixes the ICE by forcing a simplification in the
declaration, but leads to regressions:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (Revision 277460)
+++ gcc/fortran/decl.c (Arbeitskopie)
@@ -2596,6 +2596,7 @@
if (e->expr_type != EXPR_CONSTANT)
{
n = gfc_copy_expr (e);
+ gfc_resolve_expr (n);
gfc_simplify_expr (n, 1);
if (n->expr_type == EXPR_CONSTANT)
gfc_replace_expr (e, n);
@@ -2606,6 +2607,7 @@
if (e->expr_type != EXPR_CONSTANT)
{
n = gfc_copy_expr (e);
+ gfc_resolve_expr (n);
gfc_simplify_expr (n, 1);
if (n->expr_type == EXPR_CONSTANT)
gfc_replace_expr (e, n);
The failing testcases are:
gfortran.dg/pr84734.f90
gfortran.dg/typebound_proc_32.f90
The first one misses the detection of an overflow.
The second one is a real negative side-effect I do not understand.
[Bug tree-optimization/92229] Optimization makes it impossible to read overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229 --- Comment #1 from joseph at codesourcery dot com --- Built-in functions related to integer overflow should be defined in terms of the C abstract machine model, not in terms of processor flags. See recent WG14 discussions around this issue for various language design ideas.
[Bug rtl-optimization/92213] internal compiler error: in lra_assign, at lra-assigns.c:1647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92213
--- Comment #6 from H.J. Lu ---
When the same register is assigned by assign_by_spills which sets
reg_renumber and assigned by assign_spill_hard_regs which sets
hard_regs_spilled_into, lra_create_live_ranges_1 treats the register
only for spill, not for assignment. Should lra_create_live_ranges_1
be updated to check for reg_renumber?
diff --git a/gcc/lra-lives.c b/gcc/lra-lives.c
index 1d1525ca2e5..cb5a482805e 100644
--- a/gcc/lra-lives.c
+++ b/gcc/lra-lives.c
@@ -1305,6 +1305,7 @@ lra_create_live_ranges_1 (bool all_p, bool dead_insn_p)
int i, hard_regno, max_regno = max_reg_num ();
int curr_point;
bool bb_live_change_p, have_referenced_pseudos = false;
+ HARD_REG_SET lra_assigned_reg_set;
timevar_push (TV_LRA_CREATE_LIVE_RANGES);
@@ -1314,6 +1315,7 @@ lra_create_live_ranges_1 (bool all_p, bool dead_insn_p)
"\n** Pseudo live ranges #%d: **\n\n",
++lra_live_range_iter);
memset (lra_hard_reg_usage, 0, sizeof (lra_hard_reg_usage));
+ CLEAR_HARD_REG_SET (lra_assigned_reg_set);
for (i = 0; i < max_regno; i++)
{
lra_reg_info[i].live_ranges = NULL;
@@ -1337,7 +1339,10 @@ lra_create_live_ranges_1 (bool all_p, bool dead_insn_p)
&& lra_reg_info[i].nrefs != 0)
{
if ((hard_regno = reg_renumber[i]) >= 0)
- lra_hard_reg_usage[hard_regno] += lra_reg_info[i].freq;
+ {
+lra_hard_reg_usage[hard_regno] += lra_reg_info[i].freq;
+SET_HARD_REG_BIT (lra_assigned_reg_set, hard_regno);
+ }
have_referenced_pseudos = true;
}
}
@@ -1392,7 +1397,8 @@ lra_create_live_ranges_1 (bool all_p, bool dead_insn_p)
DF-infrastructure solver to solve live data flow problem. */
for (int i = 0; HARD_REGISTER_NUM_P (i); ++i)
{
-if (TEST_HARD_REG_BIT (hard_regs_spilled_into, i))
+if (TEST_HARD_REG_BIT (hard_regs_spilled_into, i)
+&& !TEST_HARD_REG_BIT (lra_assigned_reg_set, i))
bitmap_clear_bit (_hard_regs_bitmap, i);
}
df_simple_dataflow
[Bug libstdc++/61601] C++11 regex resource exhaustion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601
--- Comment #10 from Tim Shen ---
(In reply to Eric Gallager from comment #9)
> (In reply to Tim Shen from comment #7)
> > (In reply to Maksymilian Arciemowicz from comment #6)
> > > > Do you have any other testcases?
> > >
> > > for trunk? maybe you have to use ::regex_match
> >
> > std::regex_match("findme", std::regex("(.*{100}{200}findme)"));
> >
> > there's no memory problem, it just takes exponentially long time to run
> > (which is expected when using backtracking).
> >
> > To avoid it, you can use Thompson NFA:
> >
> > #define _GLIBCXX_REGEX_USE_THOMPSON_NFA
> > #include
> >
> > int main (int argc, char *argv[])
> > {
> > std::regex_match("findme", std::regex("(.*{100}{200}findme)",
> > std::regex_constants::extended));
> >
> > return 0;
> >
> > }
> >
> > Notice that for now Thompson NFA doesn't support ECMAScript.
>
> Are you still working on this?
No, I'm not actively working on this.
[Bug c++/91581] ICE on usage requiring complete class in exception-specification of defaulted method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91581 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c++/91581] ICE on usage requiring complete class in exception-specification of defaulted method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91581 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Fri Oct 25 19:11:58 2019 New Revision: 277462 URL: https://gcc.gnu.org/viewcvs?rev=277462=gcc=rev Log: PR c++/91581 - ICE in exception-specification of defaulted ctor. * g++.dg/cpp0x/noexcept55.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept55.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/92231] New: [9/10 Regression] ICE in gimple_fold_stmt_to_constant_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92231
Bug ID: 92231
Summary: [9/10 Regression] ICE in
gimple_fold_stmt_to_constant_1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: malakhov at mcst dot ru
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi.
The compilation of the following test with 'master' version of gcc has failed
since commit a0e9bfbb865dcaf307a4a06a29a7e1e7be24ee15 replacing the usage of
`DECL_BUILT_IN ()' macro with `fndecl_built_in_p ()' function and removing
checks for FUNCTION_DECL if possible:
$ cat ./t.c
extern int bar (void);
int
foo (void)
{
return ( + 4096) ();
}
$ i386-linux-gcc -S ./t.c -O1
. . .
./t.c: In function 'foo':
./t.c:7:1: internal compiler error: tree check: expected function_decl, have
mem_ref in fndecl_built_in_p, at tree.h:6133
7 | }
| ^
0x15b7c8e tree_check_failed(tree_node const*, char const*, int, char const*,
...)
gcc/gcc/tree.c:9924
0x829ce8 tree_check(tree_node const*, char const*, int, char const*, tree_code)
gcc/gcc/tree.h:3523
0x829e39 fndecl_built_in_p(tree_node const*)
gcc/gcc/tree.h:6133
0xcda1e5 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
gcc/gimple-fold.c:6434
. . .
The reason is that TREE_OPERAND (fn, 0) turns out to be MEM_REF rather than a
FUNCTION_DECL in the following context:
$ cat gcc/gimple-fold.c
. . .
tree
gimple_fold_stmt_to_constant_1 (...)
{
. . .
fn = (*valueize) (gimple_call_fn (stmt));
if (TREE_CODE (fn) == ADDR_EXPR
&& fndecl_built_in_p (TREE_OPERAND (fn, 0))
. . .
Because the check for `TREE_CODE (TREE_OPERAND (fn, 0)) == FUNCTION_DECL' was
removed by the aforementioned commit, the invocation of `fndecl_built_in_p ()'
results in an ICE (if gcc is configured with `--enable-checking=tree', of
course):
$ cat gcc/tree.h
. . .
/* For a builtin function, identify which part of the compiler defined it. */
#define DECL_BUILT_IN_CLASS(NODE) \
((built_in_class) FUNCTION_DECL_CHECK (NODE)->function_decl.built_in_class)
. . .
inline bool
fndecl_built_in_p (const_tree node)
{
return (DECL_BUILT_IN_CLASS (node) != NOT_BUILT_IN);
}
. . .
P.S. The initial comment before fndecl_built_in_p () added by the same
commit said: "When a NULL argument is pass or tree code of the NODE is not
FUNCTION_DECL false is returned" which was not the case in fact. The next day
commit dfe2435feb0dc195652346a5e780380932763bdc removed this statement instead
of making fndecl_built_in_p () match it.
P.P.S. The comment is still confusing as it refers to the no longer existent
DECL_BUILT_IN() macro instead of fndecl_built_in_p (): "For instance, user
declared prototypes of C library functions are not DECL_IS_BUILTIN but may be
DECL_BUILT_IN".
[Bug middle-end/92230] New: Proposal to have builtin underflow detection function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92230 Bug ID: 92230 Summary: Proposal to have builtin underflow detection function Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: arieltorti14 at gmail dot com Target Milestone: --- Right now GCC provides `__builtin_sub_overflow` to check for overflows during subtraction, but there's not way to check for underflow, other than maybe comparing the operators beforehand. Maybe it would be a good idea to have `__builtin_sub_underflow` functions which could be optimized at a greater level by reading the flags instead of doing integer comparisons. As a side note, is the behavior of `__builtin_sub_overflow` the intended one ?
[Bug tree-optimization/92229] New: Optimization makes it impossible to read overflow flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229
Bug ID: 92229
Summary: Optimization makes it impossible to read overflow flag
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arieltorti14 at gmail dot com
Target Milestone: ---
I'm implementing a builtin to read the overflow flag. It is meant to be used to
simply the overflow checking code, instead of doing:
ov = __builtin_smul_overflow(a, b, );
if (ov) { ... }
One could make the code more readable by using:
res = a * b;
if (__builtin_overflow_p()) { ... }
The problem GCC optimizes many multiplication and addition operations by using
`lea` which doesn't set the overflow flag, which makes it impossible to do the
check.
What approach could I take to implement this ? Do note that this builtin is
only available on x86.
[Bug c++/90998] [9/10 Regression] ICE (segfalut) in gcc/cp/call.c compare_ics() with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90998 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/87237] __atomic_load on 4-byte-sized, 1-byte-aligned struct is not atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87237 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-25 Ever confirmed|0 |1
[Bug fortran/92113] [8 regression] r276673 causes segfault in gfortran.dg/pr51434.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #4 from Peter Bergner --- Since this works at -O1 and not -O2, I went through the options enabled by -O2 and disabled them one by one. I was able to get the test cases to pass at -O2 by specifying -fno-tree-vrp. Maybe GCC 9 and trunk have some VRP patch that fixes this?
[Bug target/92223] Redundant pushing to stack when passing empty structs to function (x86)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92223 --- Comment #4 from H.J. Lu --- This is related to PR 60336.
[Bug tree-optimization/92228] New: ICE in vectorizable_reduction, at tree-vect-loop.c:5730
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92228 Bug ID: 92228 Summary: ICE in vectorizable_reduction, at tree-vect-loop.c:5730 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jan at jki dot io Target Milestone: --- Created attachment 47115 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47115=edit preprocessed source gcc is version 10 and commit e1ad18d892a13ce7a39d088c01ed7f32f7ba COLLECT_GCC_OPTIONS='-D' 'ZEND_ENABLE_STATIC_TSRMLS_CACHE=1' '-I' 'ext/opcache/' '-I' '/var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/ext/opcache/' '-D' 'PHP_ATOM_INC' '-I' '/var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/include' '-I' '/var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/main' '-I' '/var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli' '-I' '/var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/ext/date/lib' '-I' '/usr/include/libxml2' '-I' '/usr/include/freetype2' '-I' '/usr/include/harfbuzz' '-I' '/usr/include/glib-2.0' '-I' '/usr/lib64/glib-2.0/include' '-I' '/var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/ext/mbstring/libmbfl' '-I' '/var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/ext/mbstring/libmbfl/mbfl' '-I' '/usr/include/pspell' '-I' '/var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/ext/zip/lib' '-I' '/var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/TSRM' '-I' '/var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/Zend' '-D' '_REENTRANT' '-pthread' '-I' '/usr/include' '-pipe' '-march=skylake' '-O3' '-g' '-v' '-save-temps' '-fuse-ld=bfd' '-fvisibility=hidden' '-pthread' '-D' 'ZTS' '-D' 'ZEND_SIGNALS' '-c' /usr/libexec/gcc/x86_64-pc-linux-gnu/10.0.0-pre/cc1 -fpreprocessed dfa_pass.i -quiet -dumpbase dfa_pass.c -march=skylake -auxbase dfa_pass -g -O3 -version -fuse-ld=bfd -fvisibility=hidden -o dfa_pass.s GNU C17 (Gentoo 10.0.0_pre) version 10.0.0-pre9999 20191025 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 10.0.0-pre9999 20191025 (experimental), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C17 (Gentoo 10.0.0_pre) version 10.0.0-pre9999 20191025 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 10.0.0-pre9999 20191025 (experimental), GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 214bc0594d89b21e03201165e89f3352 during GIMPLE pass: vect /var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/ext/opcache/Optimizer/dfa_pass.c: In function ‘zend_ssa_unlink_block.part.0’: /var/tmp/portage/dev-lang/php-7.3.11/work/sapis-build/cli/ext/opcache/Optimizer/dfa_pass.c:654:13: internal compiler error: in vectorizable_reduction, at tree-vect-loop.c:5730 654 | static void zend_ssa_unlink_block(zend_op_array *op_array, zend_ssa *ssa, zend_basic_block *block, int block_num) | ^ 0x92e9e4 vectorizable_reduction(_stmt_vec_info*, _slp_tree*, _slp_instance*, vec*) /var/tmp/portage/sys-devel/gcc-10.0.0_pre/work/gcc-10.0.0_pre/gcc/tree-vect-loop.c:5730 0x138f144 vect_analyze_loop_operations /var/tmp/portage/sys-devel/gcc-10.0.0_pre/work/gcc-10.0.0_pre/gcc/tree-vect-loop.c:1560 0x138f144 vect_analyze_loop_2 /var/tmp/portage/sys-devel/gcc-10.0.0_pre/work/gcc-10.0.0_pre/gcc/tree-vect-loop.c:2079 0x138f144 vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*) /var/tmp/portage/sys-devel/gcc-10.0.0_pre/work/gcc-10.0.0_pre/gcc/tree-vect-loop.c:2367 0x139cc5e try_vectorize_loop_1 /var/tmp/portage/sys-devel/gcc-10.0.0_pre/work/gcc-10.0.0_pre/gcc/tree-vectorizer.c:886 0x139c824 vectorize_loops() /var/tmp/portage/sys-devel/gcc-10.0.0_pre/work/gcc-10.0.0_pre/gcc/tree-vectorizer.c:1114 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions.
[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766 --- Comment #13 from Wilco --- (In reply to Wilco from comment #12) > (In reply to Andrew Pinski from comment #10) > > > This should be a global change and not just an aarch64 change. The reason > > is because then aarch64 is the odd man out when it comes to this. > > Agreed, see https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01549.html. It > would be great to sort that out so C and C++ finally address globals > identically. Patch: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html
[Bug c/85678] -fno-common should be default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #6 from Wilco --- (In reply to Jonathan Wakely from comment #5) > The other bug links to a patch to change the default: > > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01549.html Updated patch: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 84487, which changed state. Bug 84487 Summary: [8/9 Regression] Large rodate section increase in 465.tonto with r254427 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug other/84613] [meta-bug] SPEC compiler performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84613 Bug 84613 depends on bug 84487, which changed state. Bug 84487 Summary: [8/9 Regression] Large rodate section increase in 465.tonto with r254427 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 Thomas Koenig changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #32 from Thomas Koenig --- (In reply to Peter Bergner from comment #31) > (In reply to Christophe Lyon from comment #30) > > Since this was backported to gcc-8-branch, I've noticed: > > FAIL: gfortran.dg/pr51434.f90 -O2 execution test > > FAIL: gfortran.dg/pr51434.f90 -Os execution test > > on arm and aarch64 > > I'm seeing this on powerpc64le-linux as well, also only on FSF 8 branch. > I'm unsure if the patch is at fault or whether it's exposing a latent issue, > since I can get the tests to pass if I add -fno-tree-vrp. Maybe there's > some interaction between this patch and VRP? > > I'm reopening the bug until this is resolved. This is tracked on PR 92113.
[Bug rtl-optimization/87871] [9/10 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #63 from Richard Earnshaw --- We need to reach closure on this, but there's nothing really concrete to make such a decision. Which of the tests originally reported are still failing?
[Bug target/85969] avr/gen-avr-mmcu-specs.c:56: unused function ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85969 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Georg-Johann Lay --- Fixed in v10.
[Bug target/85969] avr/gen-avr-mmcu-specs.c:56: unused function ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85969 --- Comment #4 from Georg-Johann Lay --- Author: gjl Date: Fri Oct 25 15:13:23 2019 New Revision: 277455 URL: https://gcc.gnu.org/viewcvs?rev=277455=gcc=rev Log: PR target/85969 * config/avr/gen-avr-mmcu-specs.c (str_prefix_p): Remove unused static function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055
--- Comment #4 from Georg-Johann Lay ---
Created attachment 47114
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47114=edit
double64-5.diff: Support --with-double={32|64} --with-long-double={32|64}
[Bug c++/90505] [9/10 Regression] g++ rejects a valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90505
--- Comment #8 from Marek Polacek ---
Test from Bug 92221:
template class a {
using b = int;
using c = int;
b d;
void e() { g(d); }
template static void g(f...);
};
[Bug c++/90505] [9/10 Regression] g++ rejects a valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90505 Marek Polacek changed: What|Removed |Added CC||dimitar.yordanov at sap dot com --- Comment #7 from Marek Polacek --- *** Bug 92221 has been marked as a duplicate of this bug. ***
[Bug c++/92221] [9/10 Regression] template argument deduction/substitution failed after "Implement P0846R0, ADL and function templates"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92221 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Marek Polacek --- Most likely a dup of Bug 90505. *** This bug has been marked as a duplicate of bug 90505 ***
[Bug target/88656] [7/8/9 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656 Bug 88656 depends on bug 88167, which changed state. Bug 88167 Summary: [7/8/9 regression] [ARM] Function __builtin_return_address returns invalid address https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug target/88167] [7/8/9 regression] [ARM] Function __builtin_return_address returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167 Richard Earnshaw changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|10.0|7.5 --- Comment #7 from Richard Earnshaw --- Fixed on all active branches
[Bug target/88656] [7/8/9 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Earnshaw --- Fixed on all active branches
[Bug target/92137] [ia32] Missing documentation for ia32 builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92137 --- Comment #6 from Ariel Torti --- (In reply to Eric Gallager from comment #5) > (In reply to Jakub Jelinek from comment #3) > > Those are intrinsics and most of them are documented in the Intel > > architecture manuals, or various web sites. Not sure it is a good idea to > > duplicate that documentation. > > Might be worthwhile to at least provide a link to the manuals or websites > then, if we're not going to duplicate the info contained in them... Could you provide an example on how you would add them ?
[Bug target/88167] [7/8/9 regression] [ARM] Function __builtin_return_address returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167 --- Comment #6 from Richard Earnshaw --- Author: rearnsha Date: Fri Oct 25 14:39:06 2019 New Revision: 277454 URL: https://gcc.gnu.org/viewcvs?rev=277454=gcc=rev Log: [arm][PR88167] Fix __builtin_return_address returns invalid address This patch fixes a problem with the thumb1 prologue code where the link register could be unconditionally used as a scratch register even if the return value was still live at the end of the prologue. Additionally, the patch improves the code generated when we are not using many low call-saved registers to make use of any unused call clobbered registers to help with the saving of high registers that cannot be pushed directly (quite rare in normal code as the register allocator correctly prefers low registers). 2019-05-08 Mihail Ionescu Richard Earnshaw gcc: PR target/88167 * config/arm/arm.c (thumb1_prologue_unused_call_clobbered_lo_regs): New function. (thumb1_epilogue_unused_call_clobbered_lo_regs): New function. (thumb1_compute_save_core_reg_mask): Don't force a spare work register if both the epilogue and prologue can use call-clobbered regs. (thumb1_unexpanded_epilogue): Use thumb1_epilogue_unused_call_clobbered_lo_regs. Reverse the logic for picking temporaries for restoring high regs to match that of the prologue where possible. (thumb1_expand_prologue): Add any usable call-clobbered low registers to the list of work registers. Detect if the return address is still live at the end of the prologue and avoid using it for a work register if so. If the return address is not live, add LR to the list of pushable regs after the first pass. gcc/testsuite: PR target/88167 * gcc.target/arm/pr88167-1.c: New test. * gcc.target/arm/pr88167-2.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/pr88167-1.c branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/pr88167-2.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/arm/arm.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/92227] New: Optimizations on constant integer overflow checks lead to incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92227 Bug ID: 92227 Summary: Optimizations on constant integer overflow checks lead to incorrect results Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: arieltorti14 at gmail dot com Target Milestone: --- Created attachment 47113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47113=edit PoC generator When `fold_builtin_arith_overflow` optimizes the overflow check on integer constants it never sets the overflow flag on the flag register leading to incorrect results. Attached is a file containing two versions of a program showcasing the bug.
[Bug c++/92058] constinit disregards non-constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92058 --- Comment #2 from Marek Polacek --- Going to be fixed by https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01777.html
[Bug target/88167] [7/8/9 regression] [ARM] Function __builtin_return_address returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167 --- Comment #5 from Richard Earnshaw --- Author: rearnsha Date: Fri Oct 25 14:37:14 2019 New Revision: 277453 URL: https://gcc.gnu.org/viewcvs?rev=277453=gcc=rev Log: [arm][PR88167] Fix __builtin_return_address returns invalid address This patch fixes a problem with the thumb1 prologue code where the link register could be unconditionally used as a scratch register even if the return value was still live at the end of the prologue. Additionally, the patch improves the code generated when we are not using many low call-saved registers to make use of any unused call clobbered registers to help with the saving of high registers that cannot be pushed directly (quite rare in normal code as the register allocator correctly prefers low registers). 2019-05-08 Mihail Ionescu Richard Earnshaw gcc: PR target/88167 * config/arm/arm.c (thumb1_prologue_unused_call_clobbered_lo_regs): New function. (thumb1_epilogue_unused_call_clobbered_lo_regs): New function. (thumb1_compute_save_core_reg_mask): Don't force a spare work register if both the epilogue and prologue can use call-clobbered regs. (thumb1_unexpanded_epilogue): Use thumb1_epilogue_unused_call_clobbered_lo_regs. Reverse the logic for picking temporaries for restoring high regs to match that of the prologue where possible. (thumb1_expand_prologue): Add any usable call-clobbered low registers to the list of work registers. Detect if the return address is still live at the end of the prologue and avoid using it for a work register if so. If the return address is not live, add LR to the list of pushable regs after the first pass. gcc/testsuite: PR target/88167 * gcc.target/arm/pr88167-1.c: New test. * gcc.target/arm/pr88167-2.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/arm/pr88167-1.c branches/gcc-8-branch/gcc/testsuite/gcc.target/arm/pr88167-2.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/arm/arm.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug target/88167] [7/8/9 regression] [ARM] Function __builtin_return_address returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167 --- Comment #4 from Richard Earnshaw --- Author: rearnsha Date: Fri Oct 25 14:34:44 2019 New Revision: 277452 URL: https://gcc.gnu.org/viewcvs?rev=277452=gcc=rev Log: [arm][PR88167] Fix __builtin_return_address returns invalid address This patch fixes a problem with the thumb1 prologue code where the link register could be unconditionally used as a scratch register even if the return value was still live at the end of the prologue. Additionally, the patch improves the code generated when we are not using many low call-saved registers to make use of any unused call clobbered registers to help with the saving of high registers that cannot be pushed directly (quite rare in normal code as the register allocator correctly prefers low registers). 2019-05-08 Mihail Ionescu Richard Earnshaw gcc: PR target/88167 * config/arm/arm.c (thumb1_prologue_unused_call_clobbered_lo_regs): New function. (thumb1_epilogue_unused_call_clobbered_lo_regs): New function. (thumb1_compute_save_core_reg_mask): Don't force a spare work register if both the epilogue and prologue can use call-clobbered regs. (thumb1_unexpanded_epilogue): Use thumb1_epilogue_unused_call_clobbered_lo_regs. Reverse the logic for picking temporaries for restoring high regs to match that of the prologue where possible. (thumb1_expand_prologue): Add any usable call-clobbered low registers to the list of work registers. Detect if the return address is still live at the end of the prologue and avoid using it for a work register if so. If the return address is not live, add LR to the list of pushable regs after the first pass. gcc/testsuite: PR target/88167 * gcc.target/arm/pr88167-1.c: New test. * gcc.target/arm/pr88167-2.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.target/arm/pr88167-1.c branches/gcc-9-branch/gcc/testsuite/gcc.target/arm/pr88167-2.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/arm/arm.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/92226] [10 Regression] live nul char store to array eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92226 Martin Sebor changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-25 Blocks||83819 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug tree-optimization/92226] New: [10 Regression] live nul char store to array eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92226
Bug ID: 92226
Summary: [10 Regression] live nul char store to array
eliminated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
One of the recent strlen changes (bisection points to r277076) leads to a
miscompilation of the following test case.
The problem is that the nul-over-nul optimization is being applied when it
shouldn't be. It looks to me like the change above might have exposed a latent
bug here, or the change is incomplete. Before the change,
compare_nonzero_chars returned -1 in this case which doesn't really correspond
to the documentation of the function -- that SI might not start with OFF
nonzero characters, where SI length is in [0, 7] and OFF is 0 -- but now it
returns 0. That also doesn't
reflect exactly what's going on.
$ cat a.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout a.c
struct A { char a[8], c; };
void f (void*);
void g (const char *s)
{
if (__builtin_strlen (s) > 7)
return;
struct A a;
__builtin_strcpy (a.a, s);
a.a[0] = 0; // incorrectly eliminated
f ();
}
;; Function g (g, funcdef_no=0, decl_uid=1935, cgraph_uid=1, symbol_order=0)
g (const char * s)
{
struct A a;
long unsigned int _1;
long unsigned int _10;
[local count: 1073741824]:
_1 = __builtin_strlen (s_4(D));
if (_1 > 7)
goto ; [51.12%]
else
goto ; [48.88%]
[local count: 548896821]:
a ={v} {CLOBBER};
goto ; [100.00%]
[local count: 524845004]:
_10 = _1 + 1;
__builtin_memcpy (, s_4(D), _10);
f ();
a ={v} {CLOBBER};
[local count: 1073741824]:
return;
}
[Bug tree-optimization/92225] ice in gen_smaxv2di3, at config/i386/sse.md:12225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92225
--- Comment #7 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #6)
> This. V2DImode of REDUC_SSE_SMINMAX_MODE should be conditional on
> TARGET_SSE4_2.
--cut here--
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 403e91d4b176..245cb522321c 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -2771,7 +2771,7 @@
;; Modes handled by reduc_sm{in,ax}* patterns.
(define_mode_iterator REDUC_SSE_SMINMAX_MODE
[(V4SF "TARGET_SSE") (V2DF "TARGET_SSE")
- (V2DI "TARGET_SSE") (V4SI "TARGET_SSE") (V8HI "TARGET_SSE")
+ (V2DI "TARGET_SSE4_2") (V4SI "TARGET_SSE") (V8HI "TARGET_SSE")
(V16QI "TARGET_SSE")])
(define_expand "reduc__scal_"
--cut here--
[Bug target/88167] [7/8/9 regression] [ARM] Function __builtin_return_address returns invalid address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167 Richard Earnshaw changed: What|Removed |Added Priority|P3 |P2 Status|RESOLVED|REOPENED Blocks||88656 Resolution|FIXED |--- Summary|[ARM] Function |[7/8/9 regression] [ARM] |__builtin_return_address|Function |returns invalid address |__builtin_return_address ||returns invalid address --- Comment #3 from Richard Earnshaw --- Re-opening because needed for backporting to fix bug 88656 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656 [Bug 88656] [7/8/9 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
[Bug target/88656] [7/8/9 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656 Bug 88656 depends on bug 88167, which changed state. Bug 88167 Summary: [7/8/9 regression] [ARM] Function __builtin_return_address returns invalid address https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug tree-optimization/92225] ice in gen_smaxv2di3, at config/i386/sse.md:12225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92225
--- Comment #6 from Uroš Bizjak ---
(In reply to Richard Biener from comment #5)
> (define_expand "reduc_plus_scal_"
> [(plus:REDUC_PLUS_MODE
>(match_operand: 0 "register_operand")
>(match_operand:REDUC_PLUS_MODE 1 "register_operand"))]
> ""
> {
>
> simply in need of constraining for this mode?
This. V2DImode of REDUC_SSE_SMINMAX_MODE should be conditional on
TARGET_SSE4_2.
[Bug tree-optimization/92222] [9 Regression] ice in useless_type_conversion_p, at gimple-expr.c:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Oct 25 13:03:56 2019 New Revision: 277448 URL: https://gcc.gnu.org/viewcvs?rev=277448=gcc=rev Log: 2019-10-25 Richard Biener PR tree-optimization/9 * tree-vect-slp.c (_slp_oprnd_info::first_pattern): Remove. (_slp_oprnd_info::second_pattern): Likewise. (_slp_oprnd_info::any_pattern): New. (vect_create_oprnd_info): Adjust. (vect_get_and_check_slp_defs): Compute whether any stmt is in a pattern. (vect_build_slp_tree_2): Avoid building up a node from scalars if any of the operand defs, not just the first, is in a pattern. * gcc.dg/torture/pr9.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr9.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/92222] [9 Regression] ice in useless_type_conversion_p, at gimple-expr.c:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[9/10 Regression] ice in|[9 Regression] ice in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.c:86 |at gimple-expr.c:86 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug target/88656] [7/8/9 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656 --- Comment #7 from Richard Earnshaw --- This was fixed on trunk at some point, but not yet been backported.
[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from David Binderman --- I also see this problem, when compiling package range-v3 in fedora.
[Bug tree-optimization/92225] ice in gen_smaxv2di3, at config/i386/sse.md:12225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92225
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #5 from Richard Biener ---
Hmm, but we are asking
if (reduc_fn != IFN_LAST
&& !direct_internal_fn_supported_p (reduc_fn, vectype_out,
OPTIMIZE_FOR_SPEED))
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
"reduc op not supported by target.\n");
reduc_fn = IFN_LAST;
with reduc_fn == IFN_REDUC_MAX and a V2DImode type which eventually ends up
in direct_optab_supported_p (optab=reduc_smax_scal_optab calling
ix86_optab_supported_p with CODE_FOR_reduc_smax_scal_v2di and V2DImode
which doesn't handle that specially.
Richard - do all IFNs we query direct support for have to manually repeat
constraints we set up? Or is
(define_expand "reduc_plus_scal_"
[(plus:REDUC_PLUS_MODE
(match_operand: 0 "register_operand")
(match_operand:REDUC_PLUS_MODE 1 "register_operand"))]
""
{
simply in need of constraining for this mode?
CCing Uros since this likely requires a target fix.
[Bug c++/92158] Enum warning when -1 enum converted to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158 --- Comment #8 from Jonathan Wakely --- No, there's no need for a new bug.
[Bug tree-optimization/92225] ice in gen_smaxv2di3, at config/i386/sse.md:12225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92225 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Component|target |tree-optimization --- Comment #4 from Richard Biener --- OK, so I think we fail to check appropriately for support of the epilogue reduction. The in-loop reduction happens in V4SImode but the actual reduction IV is V2DImode and that's how the reduction is performed.
[Bug target/92225] ice in gen_smaxv2di3, at config/i386/sse.md:12225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92225
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-10-25
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
Confirmed. Eventually ix86_expand_int_vcond fails because the compare needs
4105 /* Only SSE4.1/SSE4.2 supports V2DImode. */
4106 if (mode == V2DImode)
and code is GT. Somehow
(define_expand "3"
[(set (match_operand:VI8_AVX2_AVX512F 0 "register_operand")
(maxmin:VI8_AVX2_AVX512F
(match_operand:VI8_AVX2_AVX512F 1 "register_operand")
(match_operand:VI8_AVX2_AVX512F 2 "register_operand")))]
"TARGET_SSE4_2"
doesn't work? Ah, because it's directly invoked via
(define_expand "reduc__scal_"
[(smaxmin:REDUC_SSE_SMINMAX_MODE
(match_operand: 0 "register_operand")
(match_operand:REDUC_SSE_SMINMAX_MODE 1 "register_operand"))]
""
{
rtx tmp = gen_reg_rtx (mode);
ix86_expand_reduc (gen_3, tmp, operands[1]);
emit_insn (gen_vec_extract (operands[0], tmp,
const0_rtx));
DONE;
})
[Bug c/87210] [RFE] introduce build time options to zero initialize automatic stack variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 Alexander Potapenko changed: What|Removed |Added CC||glider at google dot com --- Comment #4 from Alexander Potapenko --- To give an update, upstream Clang now supports force initialization of stack variables under the -ftrivial-auto-var-init flag. -ftrivial-auto-var-init=pattern initializes local variables with a 0xAA pattern (actually it's more complicated, see https://reviews.llvm.org/D54604) -ftrivial-auto-var-init=zero provides zero-initialization of locals. This mode isn't officially supported yet and is hidden behind an additional -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang flag. This is done to avoid creating a C++ dialect where all variables are zero-initialized. Starting v5.2, Linux kernel has a CONFIG_INIT_STACK_ALL config that performs the build with -ftrivial-auto-var-init=pattern. This one isn't widely adopted yet, partially because initializing locals with 0xAA isn't fast enough. Linus Torvalds is quite positive about zero-initializing the locals though, see https://lkml.org/lkml/2019/7/30/1303 So having a flag similar to -ftrivial-auto-var-init=zero in GCC will be appreciated by the Linux kernel community.
[Bug target/92225] ice in gen_smaxv2di3, at config/i386/sse.md:12225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92225
--- Comment #2 from David Binderman ---
Reduced code:
void a(long);
unsigned *b;
void c() {
long d;
for (int e; e; e++)
if (b[e] > d)
d = b[e];
a(d);
}
[Bug c++/92158] Enum warning when -1 enum converted to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158 --- Comment #7 from Jonny Grant --- > Would it be better if I re-file this ticket as implement -Wsign-conversion > for C++ ? I mean expand -Wsign-conversion for C++ to detect the enum conversion that the same option does for C code.
[Bug c++/92158] Enum warning when -1 enum converted to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158
--- Comment #6 from Jonny Grant ---
Many thanks for your reply. Would you rather I close this and create a new
ticket with just your test case so it is clearer on bugzilla?
Just to note, gcc trunk shows a warning in C - but oddly g++ does not for C++
-Wsign-conversion
enum E { a = -1 } ;
unsigned i = a;
Would it be better if I re-file this ticket as implement -Wsign-conversion for
C++ ?
[Bug d/92216] GDC generate duplicate symbols when mixins and interfaces are used to gather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92216 --- Comment #1 from Daniel Kozak --- Created attachment 47112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47112=edit Make thunk weak linking
[Bug target/92218] PowerPC indexed insn attribute misses some insns (bswap, atomic, small int float/vector load/store)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92218 --- Comment #1 from Michael Meissner --- The VSX instructions load scalar from memory and splat into the register are another class of x-form only memory instructions that would need the indexed insn attribute set.
[Bug tree-optimization/92222] [9/10 Regression] ice in useless_type_conversion_p, at gimple-expr.c:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Richard Biener changed: What|Removed |Added Known to work||8.3.0 Target Milestone|--- |9.3 Summary|ice in |[9/10 Regression] ice in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.c:86 |at gimple-expr.c:86
[Bug tree-optimization/92222] ice in useless_type_conversion_p, at gimple-expr.c:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #4 from Richard Biener --- Caused by r263290. From the log: I'm also not sure why: if (!first && !oprnd_info->first_pattern /* Allow different pattern state for the defs of the first stmt in reduction chains. */ && (oprnd_info->first_dt != vect_reduction_def is necessary. All that should matter is that the statements in the node are "similar enough". It turned out to be quite hard to find a convincing example that used a mixture of pattern and non-pattern statements, so bb-slp-pow-1.c is the best I could come up with. But it does show that the combination of "xi * xi" statements and "pow (xj, 2) -> xj * xj" patterns are handled correctly. The patch therefore just removes the whole if block. But the build-from scalars check relied on it.
[Bug middle-end/92153] [10 Regression] ICE / segmentation fault, use-after-free at gcc/ggc-page.c:1159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92153 --- Comment #3 from Jan Hubicka --- Author: hubicka Date: Fri Oct 25 11:17:38 2019 New Revision: 277443 URL: https://gcc.gnu.org/viewcvs?rev=277443=gcc=rev Log: Backport ggc_trim Backport from mainline 2019-10-18 Jakub Jelinek PR middle-end/92153 * ggc-page.c (release_pages): Read g->alloc_size before free rather than after it. 2019-10-11 Jan Hubicka * ggc-page.c (release_pages): Output statistics when !quiet_flag. (ggc_collect): Dump later to not interfere with release_page dump. (ggc_trim): New function. * ggc-none.c (ggc_trim): New. * ggc.h (ggc_trim): Declare. * lto-partition.c (add_symbol_to_partition_1): Update. (undo_parittion): Update. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/ggc-none.c branches/gcc-9-branch/gcc/ggc-page.c branches/gcc-9-branch/gcc/ggc.h branches/gcc-9-branch/gcc/lto/ChangeLog branches/gcc-9-branch/gcc/lto/lto.c
[Bug c++/92225] ice in gen_smaxv2di3, at config/i386/sse.md:12225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92225 --- Comment #1 from David Binderman --- The bug first seems to occur sometime between revision 277300 and 277350. Since this is C++ code, it may take me some time to reduce it.
[Bug c++/92225] New: ice in gen_smaxv2di3, at config/i386/sse.md:12225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92225 Bug ID: 92225 Summary: ice in gen_smaxv2di3, at config/i386/sse.md:12225 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 47111 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47111=edit gzipped C++ source code For the attached C++ code, recent gcc trunk and compiler flag -O3, it does this: during RTL pass: expand /home/dcb30/rpmbuild/BUILD/qfaxreader-0.3.2/src/qfrpostscript.cpp: In member function ‘bool QfrPostscript::drawLevel2Image(int, int, int, int, QfrTiffIO&)’: /home/dcb30/rpmbuild/BUILD/qfaxreader-0.3.2/src/qfrpostscript.cpp:362:6: internal compiler error: in gen_smaxv2di3, at config/i386/sse.md:12225 362 | bool QfrPostscript::drawLevel2Image(int x, int y, int w, int h, QfrTiffIO ) | ^ 0x888ac6 gen_smaxv2di3(rtx_def*, rtx_def*, rtx_def*) ../../trunk/gcc/config/i386/sse.md:12225 0x14b481b ix86_expand_reduc(rtx_def* (*)(rtx_def*, rtx_def*, rtx_def*), rtx_def*, rtx_def*) ../../trunk/gcc/config/i386/i386-expand.c:15062 0x1804e3c gen_reduc_smax_scal_v2di(rtx_def*, rtx_def*) ../../trunk/gcc/config/i386/sse.md:2784 0xfbac48 insn_gen_fn::operator()(rtx_def*, rtx_def*) const ../../trunk/gcc/recog.h:318
[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207 --- Comment #11 from Richard Earnshaw --- BTW, it looks like the libgloss implementation of the syscall API and startup code has had this change since 2015.
[Bug tree-optimization/92222] ice in useless_type_conversion_p, at gimple-expr.c:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #3 from Richard Biener --- I think this issue is probably latent. Testing patch.
[Bug c++/92158] Enum warning when -1 enum converted to unsigned int or int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92158
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Jonathan Wakely ---
Thank you for the corrected testcase, although compiling with -Werror when
asking for warnings is not very helpful (it obscures what's a warning and
what's an error) and posting code that doesn't even compile is not very helpful
either.
Confirming as a diagnostic enhancement for the following testcase:
enum E { a = -1 } ;
unsigned i = a;
Clang warns with -Wsign-conversion (not enabled by -Wall or -Wextra):
e.cc:2:14: warning: implicit conversion changes signedness: 'E' to 'unsigned
int' [-Wsign-conversion]
unsigned i = a;
~ ^
1 warning generated.
[Bug libstdc++/92224] Set: Can't be created a set with const template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92224 --- Comment #2 from Jonathan Wakely --- Also, set keys are *not* const, otherwise you wouldn't be able to assign one set to another set without reallocating every element. std::set::iterator only gives you const *access* to the elements, but the elements themselves are not actually const.
[Bug libstdc++/92224] Set: Can't be created a set with const template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92224 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- The standard says that the template argument for an allocator must be a non-const, non-volatile object type, so trying to instantiate std::allocator is undefined, and libstdc++ is allowed to reject it.
[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207 --- Comment #10 from Richard Earnshaw --- A bit more trace from the gdb session as evidence. (gdb) p HeapLimit 'HeapLimit' has unknown type; cast it to its declared type (gdb) p $1 = ( *) 0x48f78 (gdb) x/x $1 0x48f78:0x0804a000 (gdb) p __heap_limit No symbol "__heap_limit" in current context.
[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #9 from Richard Earnshaw --- This is a bug in newlib-3.1.0 that should have been fixed in trunk with https://sourceware.org/ml/newlib/2019/msg00413.html So closing as invalid.
[Bug tree-optimization/92222] ice in useless_type_conversion_p, at gimple-expr.c:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-25 Component|c |tree-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I will have a look.
[Bug libstdc++/92224] New: Set: Can't be created a set with const template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92224 Bug ID: 92224 Summary: Set: Can't be created a set with const template parameter Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mariogalindoq at hotmail dot com Target Milestone: --- std::set keys are always const, however it is not possible to create a set with a const template parameter. The following should be right but gives a error: std::set s; // error!!
[Bug target/92223] Redundant pushing to stack when passing empty structs to function (x32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92223 Jonathan Wakely changed: What|Removed |Added Target||i?86-*-* Status|WAITING |UNCONFIRMED Component|c++ |target Ever confirmed|1 |0 --- Comment #3 from Jonathan Wakely --- OK thanks, I'm changing the Component and setting the Target field then.
[Bug c++/92223] Redundant pushing to stack when passing empty structs to function (x32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92223 --- Comment #2 from Lahav Schlesinger --- (In reply to Jonathan Wakely from comment #1) > Are you talking about 32-bit x86 and 64-bit x86_64? > > Because "x32" means something completely different: > https://en.wikipedia.org/wiki/X32_ABI > > "x64" is also wrong, it's a stupid term used by Microsoft for x86_64, but > x32 means something completely different to 32-bit x86 a.k.a IA-32. > > Please avoid "x64" completely and only use "x32" if you actually mean x32, > not 32-bit x86. Yes, I'm referring to the 32-bit x86 and 64-bit x86_64. Thanks for clearing up the differences.
[Bug c++/92223] Redundant pushing to stack when passing empty structs to function (x32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92223 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-10-25 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Are you talking about 32-bit x86 and 64-bit x86_64? Because "x32" means something completely different: https://en.wikipedia.org/wiki/X32_ABI "x64" is also wrong, it's a stupid term used by Microsoft for x86_64, but x32 means something completely different to 32-bit x86 a.k.a IA-32. Please avoid "x64" completely and only use "x32" if you actually mean x32, not 32-bit x86.
[Bug c++/92223] New: Redundant pushing to stack when passing empty structs to function (x32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92223
Bug ID: 92223
Summary: Redundant pushing to stack when passing empty structs
to function (x32)
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lahav.sch.gcc at gmail dot com
Target Milestone: ---
Hi!
I tested the following code in several version of GCC, including trunk.
In the following code:
struct Empty {};
void foo(int, Empty, int);
int main() {
foo(10, Empty{}, 15);
}
The call to foo compiles to:
pushl $0xf
pushl $0x0
pushl $0xa
callfoo(int, Empty, int)
A similar issue was fixed in the GCC 8.1 release, but only for x86-64 - In x64
the Empty parameter is now completely removed (Instead of passing an dummy 0
value on the stack), but in x32 it still remains.
I'm not sure if the x32 ABI mandates that such empty classes should be
completely removed (In contrast with the System V x86-64 ABI which states they
indeed should not be passed).
In pre-GCC 8 version on x86-64 a similar behaviour happend - 0xa was into $edi,
the 0xf was passed to $esi, but there was a "pushq $0x0" to the stack.
Perhaps the two behaviour are related?
[Bug rtl-optimization/92213] internal compiler error: in lra_assign, at lra-assigns.c:1647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92213
--- Comment #5 from Hongtao.liu ---
all_hard_regs_bitmap didn't has 68(k0).
first = 0x37fd100 current = 0x37fd100 indx = 0
0x37fd100 next = (nil) prev = (nil) indx = 0
bits = { 0 1 2 3 4 5 6 7 8 9 10 11
12 13 14 15 16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31 32 33 34 35
36 37 38 39 40 41 42 43 44 45 46 47
48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 69 70 71 72
73 74 75 }
it's cleared by
/* As we did not change CFG since LRA start we can use
DF-infrastructure solver to solve live data flow problem. */
for (int i = 0; HARD_REGISTER_NUM_P (i); ++i)
{
if (TEST_HARD_REG_BIT (hard_regs_spilled_into, i))
=> bitmap_clear_bit (_hard_regs_bitmap, i);
}
Breakpoint 32, lra_create_live_ranges_1 (all_p=true, dead_insn_p=false) at
../../../gnu-toolchain/gcc/gcc/lra-lives.c:1396
1396bitmap_clear_bit (_hard_regs_bitmap, i);
(gdb) p i
$200 = 68
(gdb) p hard_regs_spilled_into
$201 = {elts = {0, 16}}
(gdb) p i
$202 = 68
[Bug c/92222] ice in useless_type_conversion_p, at gimple-expr.c:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #1 from David Binderman ---
Reduced C code is
unsigned char *a;
b;
c() {
char *d;
int e;
for (; b; b++) {
e = 7;
for (; e >= 0; e--)
*d++ = a[b] & 1 << e ? '1' : '0';
}
f();
}
[Bug c/92222] New: ice in useless_type_conversion_p, at gimple-expr.c:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Bug ID: 9 Summary: ice in useless_type_conversion_p, at gimple-expr.c:86 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 47110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47110=edit C source code The attached C code, when compiled by recent gcc trunk and compiler flag -O3, does this: ../results.277350/bin/gcc during GIMPLE pass: slp main.c: In function ‘disp_binary’: main.c:234:13: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:86 0x71c6dd tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) ../../trunk/gcc/tree.c:9975 0x626a1b tree_class_check(tree_node*, tree_code_class, char const*, int, char co nst*) ../../trunk/gcc/tree.h:3390 0x626a1b useless_type_conversion_p(tree_node*, tree_node*) ../../trunk/gcc/gimple-expr.c:86 0xea3fe4 verify_gimple_assign_single ../../trunk/gcc/tree-cfg.c:4545 0xea3fe4 verify_gimple_assign ../../trunk/gcc/tree-cfg.c:4609 The problem seems to start sometime between revision 277300 and 277350. I will have my usual go at reducing the code.
[Bug c/92220] -Wconversion generates a false warning for modulo expression when the modulus has smaller type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92220 --- Comment #3 from John Simon --- (In reply to Andrew Pinski from comment #1) > No i think there is one case where what you said is incorrect. When both are > INT_MIN. In this case the result will be 0.
[Bug c++/92221] [9/10 Regression] template argument deduction/substitution failed after "Implement P0846R0, ADL and function templates"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92221 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Known to work||8.3.0 Target Milestone|--- |9.3 Summary|[Regression] template |[9/10 Regression] template |argument|argument |deduction/substitution |deduction/substitution |failed after "Implement |failed after "Implement |P0846R0, ADL and function |P0846R0, ADL and function |templates" |templates" Known to fail||9.1.0
[Bug c/92220] -Wconversion generates a false warning for modulo expression when the modulus has smaller type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92220 --- Comment #2 from Richard Biener --- *** Bug 92219 has been marked as a duplicate of this bug. ***
[Bug c/92219] -Wconversion generates a false warning for modulo expression when the modulus has smaller type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92219 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- . *** This bug has been marked as a duplicate of bug 92220 ***
[Bug c/85678] -fno-common should be default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #5 from Jonathan Wakely --- The other bug links to a patch to change the default: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01549.html
[Bug tree-optimization/65930] Reduction with sign-change not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930 --- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #23 from Richard Biener --- [...] > I'm going to install a patch. The SPARC failues are fixed indeed. Thanks. Rainer
