[Bug c++/86859] New: error: expansion pattern contains no parameter pack when a pack from introduced in a capture is used in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86859
Bug ID: 86859
Summary: error: expansion pattern contains no parameter pack
when a pack from introduced in a capture is used in
decltype
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gufideg at gmail dot com
Target Milestone: ---
Here's the code snippet that triggers the bug:
int main() {
auto builder = [](auto b) {
return [b](auto... treeArgs) {
return [b, treeArgs...]()
-> decltype(b(treeArgs...)) {
return b(treeArgs...);
};
};
};
builder([]{});
}
GCC outputs a quite weird error message:
In instantiation of 'main():: [with auto:1 =
main()::]':
required from here
error: expansion pattern '#'nontype_argument_pack' not supported by
dump_expr#' contains no parameter packs
-> decltype(b(treeArgs...)) {
~^
This code compiles fine in clang.
Changing the `decltype()` for a `decltype(auto)` work around the bug:
int main() {
auto builder = [](auto b) {
return [b](auto... treeArgs) {
return [b, treeArgs...]()
-> decltype(auto) {
return b(treeArgs...);
};
};
};
builder([]{});
}
[Bug tree-optimization/84202] missing -Wnonnull on a returns_nonnull function returning null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84202 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-05 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- Confirmed.
[Bug tree-optimization/58689] [meta-bug] __attribute__((returns_nonnull)) enhancements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58689 Eric Gallager changed: What|Removed |Added Keywords||meta-bug Summary|Enhance returns_nonnull |[meta-bug] ||__attribute__((returns_nonn ||ull)) enhancements --- Comment #12 from Eric Gallager --- (In reply to Eric Gallager from comment #8) > Confirmed that -Wsuggest-attribute=returns_nonnull would be nice to have. Actually that's bug 84203 now; making this one a meta-bug per bug 84203 comment 2.
[Bug tree-optimization/84203] add -Wsuggest-attribute=returns_nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84203 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-05 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- (In reply to Martin Sebor from comment #2) > I just noticed -Wsuggest-attribute=returns_nonnull mentioned in bug 58689 > comment #8. I'm on the fence between resolving this as a duplicate of that > bug and treating pr58689 as a meta-bug. Let me go with the latter for now > and make this a blocker of it. ok confirming this one too then
[Bug tree-optimization/86858] New: gcc ICE at -O3 in as_a, at is-a.h:197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86858
Bug ID: 86858
Summary: gcc ICE at -O3 in as_a, at is-a.h:197
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
It appears to be a recent regression. gcc-8.1 compiles at -O3.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180804 (experimental) [trunk revision 263307] (GCC)
$ gcc-trunk -O3 abc.c
during GIMPLE pass: vect
abc.c: In function ‘h’:
abc.c:3:6: internal compiler error: in as_a, at is-a.h:197
void h() {
^
0x6e2143 gphi* as_a(gimple*)
../../gcc/gcc/is-a.h:197
0x6e2143 vect_is_simple_reduction
../../gcc/gcc/tree-vect-loop.c:2859
0xef63b2 vect_force_simple_reduction(_loop_vec_info*, _stmt_vec_info*, bool*,
bool)
../../gcc/gcc/tree-vect-loop.c:3277
0xef63b2 vect_analyze_scalar_cycles_1
../../gcc/gcc/tree-vect-loop.c:560
0xf01e0f vect_analyze_scalar_cycles
../../gcc/gcc/tree-vect-loop.c:648
0xf01e0f vect_analyze_loop_2
../../gcc/gcc/tree-vect-loop.c:1855
0xf01e0f vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
../../gcc/gcc/tree-vect-loop.c:2315
0xf1d8b0 try_vectorize_loop_1
../../gcc/gcc/tree-vectorizer.c:867
0xf1e6c5 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:1069
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ cat abc.c
int a, b, c, d;
char(e)(char f, char g) { return f + g; }
void h() {
for (; c; ++c) {
d = 0;
for (; d != 8; d = e(d, 3)) {
a = b && a;
b = c;
}
}
}
[Bug target/86856] Warning: unknown conversion type for ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856 nightstrike changed: What|Removed |Added Host||x86_64-*-linux --- Comment #4 from nightstrike --- Itwhen building the "all-gcc" target, but I'm building a cross compiler (I just updated the Host field in the PR to reflect this). When building a cross, I'm guessing it uses the host compiler for the whole thing, which in my case was gcc 7.3.
[Bug tree-optimization/86841] ICE in /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 with graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86841
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-05
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor ---
Finally confirmed (after I downloaded/installed in-tree prerequisites and
disabled jit due to pr86845). Not sure what's going on yet but here's what I
see in GDB:
#4 wide_int_range_lshift(generic_wide_int&,
generic_wide_int&, signop, unsigned int,
generic_wide_int const&, generic_wide_int
const&, generic_wide_int const&,
generic_wide_int const&, bool, bool) ()
at /opt/notnfs/msebor/src/gcc/git/gcc/wide-int-range.cc:326
326 int shift = wi::extract_uhwi (vr1_ub, 0, vr1_ub.get_precision
());
(gdb) p vr1_ub
$1 = (const wide_int &) @0x7fffd6e0: { = {val = {1,
140737226891768, 41149888}, len = 1, precision = 128},
static is_sign_extended = true}
...
#9 0x015c5dbe in (anonymous
namespace)::sprintf_dom_walker::before_dom_children(basic_block_def*) ()
at /opt/notnfs/msebor/src/gcc/git/gcc/gimple-ssa-sprintf.c:4063
4063 evrp_range_analyzer.record_ranges_from_stmt (stmt, false);
(gdb) p stmt
$6 = (gimple *) 0x706f7318
(gdb) p debug_gimple_stmt(stmt)
niters_vector_mult_vf.80_8 = bnd.79_7 << 1;
[Bug other/86857] configure sprintf with target-specific details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86857 Martin Sebor changed: What|Removed |Added Keywords||build, diagnostic, ||missed-optimization Severity|normal |enhancement --- Comment #1 from Martin Sebor --- This would improve both diagnostics by making them more accurate, as well as optimization (for the same reason).
[Bug other/86857] New: configure sprintf with target-specific details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86857 Bug ID: 86857 Summary: configure sprintf with target-specific details Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- As discussed in the following thread: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00355.html rather than hardcoding permissive ranges describing the implementation-defined sprintf output based on the most restrictive/permissive known implementation it would be preferable to determine those that can be easily determined during configuration (e.g., "inf" vs "infinity" or the %p format) or provide a target hook to describe some of the more involved ones.
[Bug tree-optimization/86571] AIX NaNQ and NaNS output format conflicts with __builtin_sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86571 Martin Sebor changed: What|Removed |Added Known to fail||7.3.0, 8.2.0 --- Comment #5 from Martin Sebor --- Committed to trunk in r263312.
[Bug tree-optimization/86571] AIX NaNQ and NaNS output format conflicts with __builtin_sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86571 --- Comment #4 from Martin Sebor --- Author: msebor Date: Sat Aug 4 22:14:41 2018 New Revision: 263312 URL: https://gcc.gnu.org/viewcvs?rev=263312=gcc=rev Log: PR tree-optimization/86571 - AIX NaNQ and NaNS output format conflicts with __builtin_sprintf gcc/ChangeLog: PR tree-optimization/86571 * gimple-ssa-sprintf.c (format_floating): Extend upper bound of NaN output to 4. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c
[Bug target/86856] Warning: unknown conversion type for ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856 --- Comment #3 from Uroš Bizjak --- (In reply to nightstrike from comment #0) > When building the compiler to target x86_64-w64-mingw32, the warnings listed > below appear. I tried making them be %zu instead of %z, but that didn't > help. Maybe it has something to do with the special printf / mingw_printf > on windows targets? Does this happen during stage1? Otherwise, these specifiers are listed in c-family/c-format.c, so the compiler should know about them, see asm_fprintf_char_table.
[Bug c++/86767] [6/7/8/9 Regression] continue statements in constexpr functions causes unbounded looping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86767
--- Comment #3 from Marek Polacek ---
This should fix it. More testing needed.
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3950,6 +3950,16 @@ cxx_eval_statement_list (const constexpr_ctx *ctx, tree
t,
for (i = tsi_start (t); !tsi_end_p (i); tsi_next ())
{
tree stmt = tsi_stmt (i);
+ /* We've found a continue, so skip everything until we reach
+the label its jumping to. */
+ if (continues (jump_target))
+ {
+ if (label_matches (ctx, jump_target, stmt))
+ /* Found it. */
+ *jump_target = NULL_TREE;
+ else
+ continue;
+ }
if (TREE_CODE (stmt) == DEBUG_BEGIN_STMT)
continue;
r = cxx_eval_constant_expression (ctx, stmt, false,
[Bug tree-optimization/80537] missing -Wformat-overflow on POSIX %C conversion specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80537 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86853 --- Comment #2 from Martin Sebor --- A patch for this and bug 86853 posted here: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00345.html
[Bug target/86856] Warning: unknown conversion type for ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856
--- Comment #2 from nightstrike ---
Final set:
../../../gccsvn/gcc/tree-ssa-ccp.c:3459:34: warning: format '%u' expects
argument of type 'unsigned int', but argument 4 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-ccp.c:3459:34: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/tree-ssa-strlen.c: In function 'bool
maybe_diag_stxncpy_trunc(gimple_stmt_iterator, tree, tree)':
../../../gccsvn/gcc/tree-ssa-strlen.c:2047:21: warning: unknown conversion type
character 'G' in format [-Wformat=]
stmt, func, cnt);
^
../../../gccsvn/gcc/tree-ssa-strlen.c:2047:21: warning: format '%D' expects
argument of type 'tree_node*', but argument 6 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2047:21: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/tree-ssa-strlen.c:2047:21: warning: unknown conversion type
character 'G' in format [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2047:21: warning: format '%D' expects
argument of type 'tree_node*', but argument 6 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2047:21: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/tree-ssa-strlen.c:2061:46: warning: unknown conversion type
character 'G' in format [-Wformat=]
stmt, func, cnt, lenrange[0].to_uhwi ());
^
../../../gccsvn/gcc/tree-ssa-strlen.c:2061:46: warning: format '%D' expects
argument of type 'tree_node*', but argument 6 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2061:46: warning: format '%wu' expects
argument of type 'long unsigned int', but argument 8 has type 'tree {aka
tree_node*}' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2061:46: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/tree-ssa-strlen.c:2061:46: warning: unknown conversion type
character 'G' in format [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2061:46: warning: format '%D' expects
argument of type 'tree_node*', but argument 6 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2061:46: warning: format '%wu' expects
argument of type 'long unsigned int', but argument 8 has type 'tree {aka
tree_node*}' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2061:46: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/tree-ssa-strlen.c:2067:52: warning: unknown conversion type
character 'G' in format [-Wformat=]
cntrange[1].to_uhwi (), lenrange[0].to_uhwi ());
^
../../../gccsvn/gcc/tree-ssa-strlen.c:2067:52: warning: format '%D' expects
argument of type 'tree_node*', but argument 4 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2067:52: warning: format '%wu' expects
argument of type 'long unsigned int', but argument 5 has type 'tree {aka
tree_node*}' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2067:52: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/tree-ssa-strlen.c:2080:46: warning: unknown conversion type
character 'G' in format [-Wformat=]
stmt, func, cnt, lenrange[1].to_uhwi ());
^
../../../gccsvn/gcc/tree-ssa-strlen.c:2080:46: warning: format '%D' expects
argument of type 'tree_node*', but argument 6 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2080:46: warning: format '%wu' expects
argument of type 'long unsigned int', but argument 8 has type 'tree {aka
tree_node*}' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2080:46: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/tree-ssa-strlen.c:2080:46: warning: unknown conversion type
character 'G' in format [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2080:46: warning: format '%D' expects
argument of type 'tree_node*', but argument 6 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2080:46: warning: format '%wu' expects
argument of type 'long unsigned int', but argument 8 has type 'tree {aka
tree_node*}' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2080:46: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/tree-ssa-strlen.c:2086:52: warning: unknown conversion type
character 'G' in format [-Wformat=]
cntrange[1].to_uhwi (), lenrange[1].to_uhwi ());
^
../../../gccsvn/gcc/tree-ssa-strlen.c:2086:52: warning: format '%D' expects
argument of type 'tree_node*', but argument 4 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2086:52: warning: format '%wu' expects
argument of type 'long unsigned int', but argument 5 has type 'tree {aka
tree_node*}' [-Wformat=]
../../../gccsvn/gcc/tree-ssa-strlen.c:2086:52: warning: too many arguments for
format
[Bug target/86856] Warning: unknown conversion type for ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856
--- Comment #1 from nightstrike ---
Additional format warnings:
../../../gccsvn/gcc/gimple-fold.c: In function 'bool
gimple_fold_builtin_strncpy(gimple_stmt_iterator*, tree, tree, tree)':
../../../gccsvn/gcc/gimple-fold.c:1668:22: warning: unknown conversion type
character 'G' in format [-Wformat=]
stmt, fndecl, slen);
^
../../../gccsvn/gcc/gimple-fold.c:1668:22: warning: format '%D' expects
argument of type 'tree_node*', but argument 4 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/gimple-fold.c:1668:22: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/gimple-fold.c:1672:16: warning: unknown conversion type
character 'G' in format [-Wformat=]
stmt, fndecl);
^
../../../gccsvn/gcc/gimple-fold.c:1672:16: warning: format '%D' expects
argument of type 'tree_node*', but argument 4 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/gimple-fold.c:1672:16: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/gimple-fold.c: In function 'bool
gimple_fold_builtin_strncat(gimple_stmt_iterator*)':
../../../gccsvn/gcc/gimple-fold.c:2043:37: warning: unknown conversion type
character 'G' in format [-Wformat=]
stmt, fndecl, len, dstsize);
^
../../../gccsvn/gcc/gimple-fold.c:2043:37: warning: format '%D' expects
argument of type 'tree_node*', but argument 4 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/gimple-fold.c:2043:37: warning: unknown conversion type
character 'G' in format [-Wformat=]
../../../gccsvn/gcc/gimple-fold.c:2043:37: warning: format '%D' expects
argument of type 'tree_node*', but argument 4 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/gimple-fold.c:2043:37: warning: format '%wu' expects
argument of type 'long unsigned int', but argument 6 has type 'tree {aka
tree_node*}' [-Wformat=]
../../../gccsvn/gcc/gimple-fold.c:2043:37: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/gimple-fold.c:2060:26: warning: unknown conversion type
character 'G' in format [-Wformat=]
stmt, fndecl, len))
^
../../../gccsvn/gcc/gimple-fold.c:2060:26: warning: format '%D' expects
argument of type 'tree_node*', but argument 4 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/gimple-fold.c:2060:26: warning: too many arguments for
format [-Wformat-extra-args]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c: In function 'bool
{anonymous}::maybe_diag_overlap(location_t, gimple*,
{anonymous}::builtin_access&)':
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: unknown
conversion type character 'G' in format [-Wformat=]
offstr[0], offstr[1], ovlsiz[0], offstr[2]);
^
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%D'
expects argument of type 'tree_node*', but argument 4 has type 'gimple*'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%wu'
expects argument of type 'long unsigned int', but argument 5 has type 'tree
{aka tree_node*}' [-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%s'
expects argument of type 'char*', but argument 6 has type 'long int'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%wu'
expects argument of type 'long unsigned int', but argument 8 has type 'char*'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%s'
expects argument of type 'char*', but argument 9 has type 'long int'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: unknown
conversion type character 'G' in format [-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%D'
expects argument of type 'tree_node*', but argument 4 has type 'gimple*'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%wu'
expects argument of type 'long unsigned int', but argument 5 has type 'tree
{aka tree_node*}' [-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%s'
expects argument of type 'char*', but argument 6 has type 'long int'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%wu'
expects argument of type 'long unsigned int', but argument 8 has type 'char*'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%s'
expects argument of type 'char*', but argument 9 has type 'long int'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: unknown
conversion type character 'G' in format [-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%D'
expects argument of type 'tree_node*', but argument 4 has type 'gimple*'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%wu'
expects
[Bug target/86856] New: Warning: unknown conversion type for ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856 Bug ID: 86856 Summary: Warning: unknown conversion type for ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- When building the compiler to target x86_64-w64-mingw32, the warnings listed below appear. I tried making them be %zu instead of %z, but that didn't help. Maybe it has something to do with the special printf / mingw_printf on windows targets? Anyway, I leave this here for smarter people to look at. In file included from ./tm.h:20:0, from ../../../gccsvn/gcc/backend.h:28, from ../../../gccsvn/gcc/final.c:49: ../../../gccsvn/gcc/final.c: In function 'void profile_function(FILE*)': ../../../gccsvn/gcc/config/i386/i386.h:2161:51: warning: unknown conversion type character 'z' in format [-Wformat=] asm_fprintf ((FILE), "\tpush%z\t%%%r\n", (REGNO)) ^ ../../../gccsvn/gcc/final.c:1856:5: note: in expansion of macro 'ASM_OUTPUT_REG_PUSH' ASM_OUTPUT_REG_PUSH (file, REGNO (sval)); ^~~ ../../../gccsvn/gcc/config/i386/i386.h:2161:51: warning: unknown conversion type character 'z' in format [-Wformat=] asm_fprintf ((FILE), "\tpush%z\t%%%r\n", (REGNO)) ^ ../../../gccsvn/gcc/final.c:1858:5: note: in expansion of macro 'ASM_OUTPUT_REG_PUSH' ASM_OUTPUT_REG_PUSH (file, REGNO (chain)); ^~~ ../../../gccsvn/gcc/config/i386/i386.h:2166:50: warning: unknown conversion type character 'z' in format [-Wformat=] asm_fprintf ((FILE), "\tpop%z\t%%%r\n", (REGNO)) ^ ../../../gccsvn/gcc/final.c:1865:5: note: in expansion of macro 'ASM_OUTPUT_REG_POP' ASM_OUTPUT_REG_POP (file, REGNO (chain)); ^~ ../../../gccsvn/gcc/config/i386/i386.h:2166:50: warning: unknown conversion type character 'z' in format [-Wformat=] asm_fprintf ((FILE), "\tpop%z\t%%%r\n", (REGNO)) ^ ../../../gccsvn/gcc/final.c:1867:5: note: in expansion of macro 'ASM_OUTPUT_REG_POP' ASM_OUTPUT_REG_POP (file, REGNO (sval)); ^~
[Bug middle-end/84184] gcc generates wrong relocations with negative offsets in struct arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84184
Ulya changed:
What|Removed |Added
CC||skvadrik at gmail dot com
--- Comment #12 from Ulya ---
(In reply to Eric Botcazou from comment #11)
> > Why those are handled differently? First looks like it works, second does
> > not. It was my main signal to file a bug against gcc as asymmetry looked
> > fishy.
>
> Because the problematic bitfield path is only used for fields in structures,
> i.e. misaligned integers are handled by another, simpler path.
More details on the problematic path for this simple example:
extern char __some_table[] __attribute__((visibility("hidden")));
struct s { long v; };
long end(void) { return ((struct s *)__some_table)[-1].v; }
1. The problematic path makes an illegal signed-to-unsigned integer conversion
in expand_expr_real_1 (expr.c) when passing the signed 'bitnum' variable, with
value -64, as the 3rd param of extract_bit_field (expmed.c), with value
18446744073709551552.
2. The conversion itself doesn't spoil the value (meaning that the bits of
'bitnum' are not changed), and the value is passed on to extract_bit_field_1,
extract_integral_bit_field and extract_fixed_bit_field unharmed.
3. Finally, 'bitnum' is passed as the 5th param 'bitpos' to
extract_split_bit_field, where it gets involved in unsigned integer arithmetics
and bad things start to happen:
static rtx
extract_split_bit_field (rtx op0, opt_scalar_int_mode op0_mode,
unsigned HOST_WIDE_INT bitsize,
unsigned HOST_WIDE_INT bitpos, int unsignedp,
bool reverse)
{
unsigned int unit;
unsigned int bitsdone = 0;
// ...
while (bitsdone < bitsize)
{
unsigned HOST_WIDE_INT thissize;
rtx part;
unsigned HOST_WIDE_INT thispos;
unsigned HOST_WIDE_INT offset;
offset = (bitpos + bitsdone) / unit; // <=== BAD THING 1
thispos = (bitpos + bitsdone) % unit; // <=== BAD THING 2
// ...
Regardless of whether GCC wants to handle this example or not, implicit
signed-to-unsigned conversion looks wrong to me. Even an assertion failure from
the compiler is better than this silent code corruption. Furthermore, can we
even guess all the possible cases when the problematic path is taken?
Full backtrace:
Breakpoint 15, extract_split_bit_field (op0=0x76cb7c60, op0_mode=...,
bitsize=64, bitpos=18446744073709551552, unsignedp=0, reverse=false)
at ../../gcc/gcc/expmed.c:2266
2266 thispos = (bitpos + bitsdone) % unit;
(gdb) bt
#0 extract_split_bit_field (op0=0x76cb7c60, op0_mode=..., bitsize=64,
bitpos=18446744073709551552, unsignedp=0, reverse=false) at
../../gcc/gcc/expmed.c:2266
#1 0x00aafff7 in extract_fixed_bit_field (tmode=E_DImode,
op0=0x76cb7c60, op0_mode=..., bitsize=64, bitnum=18446744073709551552,
target=0x76cb7bb8,
unsignedp=0, reverse=false) at ../../gcc/gcc/expmed.c:2125
#2 0x00aaf793 in extract_integral_bit_field (op0=0x76cb7c60,
op0_mode=..., bitsize=64, bitnum=18446744073709551552, unsignedp=0,
target=0x76cb7bb8,
mode=E_DImode, tmode=E_DImode, reverse=false, fallback_p=true) at
../../gcc/gcc/expmed.c:2016
#3 0x00aaeb74 in extract_bit_field_1 (str_rtx=0x76cb7c60,
bitsize=..., bitnum=..., unsignedp=0, target=0x76cb7bb8, mode=E_DImode,
tmode=E_DImode,
reverse=false, fallback_p=true, alt_rtl=0x0) at ../../gcc/gcc/expmed.c:1827
#4 0x00aafe8c in extract_bit_field (str_rtx=0x76cb7c60,
bitsize=..., bitnum=..., unsignedp=0, target=0x76cb7bb8, mode=E_DImode,
tmode=E_DImode,
reverse=false, alt_rtl=0x0) at ../../gcc/gcc/expmed.c:2096
#5 0x00aecaff in expand_expr_real_1 (exp=0x76ca6840,
target=0x76cb7bb8, tmode=E_DImode, modifier=EXPAND_NORMAL, alt_rtl=0x0,
inner_reference_p=false)
at ../../gcc/gcc/expr.c:10777
#6
[Bug tree-optimization/86853] sprintf optimization for wide strings doesn't account for conversion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86853 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00345.html
[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412 --- Comment #4 from Arseny Solokha --- (In reply to Jason Duerstock from comment #3) > This bit python3.7 as well on ia64: I believe you can replace -O3 w/ -O2 as a workaround when building for IA64.
[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412 Jason Duerstock changed: What|Removed |Added CC||jason.duerstock at gmail dot com --- Comment #3 from Jason Duerstock --- This bit python3.7 as well on ia64: https://buildd.debian.org/status/fetch.php?pkg=python3.7=ia64=3.7.0-4=1533196157=0
[Bug c++/86091] [fold expression] Slow compile time and high memory usage compared to initializer_list folds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86091 Vasili Burdo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vasili Burdo --- Confirmed. As of current git (master 571ee70a6d4), fold expression compliation is fast.
[Bug libstdc++/86852] [DR 3025] map and unordered_map wrong deduction guides for inilializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86852
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed||2018-08-04
Summary|map and unordered_map wrong |[DR 3025] map and
|deduction guides for|unordered_map wrong
|inilializer_list|deduction guides for
||inilializer_list
Ever confirmed|0 |1
--- Comment #4 from Jonathan Wakely ---
(In reply to Michael Veksler from comment #3)
> As you mention, there is https://cplusplus.github.io/LWG/issue3025 ,
> but even if this proposal is accepted things are still too brittle in
> libstd++:
>
> std::unordered_map m{{1,2}, {3,4}} does not work, and forcing
> std::unordered_map m{std::pair{1,2}, {3,4}} is counterintuitive.
Neither of these works in clang despite following the standard, which is why
there's an open issue (reported by a libstdc++ developer). The current guides
in the standard aren't very useful.
> Worse:
> std::unordered_map m(
> std::initializer_list>{
> {1, 2}, {2, 3}});
> does not work, which means that:
> std::unordered_map m(
> std::initializer_list>{
> {1, 2}, {2, 3}});
> does not work either.
Good! Neither of those should ever be written, and should never pass a code
review. Just say std::unordered_map.
I'm suspending this until issue 3025 is resolved, because failing to follow a
defective standard is not a bug.
[Bug fortran/86116] [6/7/8/9 Regression] Ambiguous generic interface not recognised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86116 --- Comment #3 from janus at gcc dot gnu.org --- Regtesting the patch in comment 2 shows the following failures: FAIL: gfortran.dg/dummy_procedure_4.f90 -O (test for errors, line 28) FAIL: gfortran.dg/proc_ptr_30.f90 -O (test for errors, line 25) FAIL: gfortran.dg/proc_ptr_comp_32.f90 -O (test for errors, line 34) FAIL: gfortran.dg/proc_ptr_comp_33.f90 -O (test for errors, line 14) FAIL: gfortran.dg/proc_ptr_comp_33.f90 -O (test for errors, line 54)
[Bug fortran/86116] [6/7/8/9 Regression] Ambiguous generic interface not recognised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86116 --- Comment #2 from janus at gcc dot gnu.org --- The problem can be fixed by removing the following piece of code: Index: gcc/fortran/interface.c === --- gcc/fortran/interface.c (revision 263308) +++ gcc/fortran/interface.c (working copy) @@ -735,12 +735,6 @@ compare_type (gfc_symbol *s1, gfc_symbol *s2) if (s2->attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK)) return true; - /* TYPE and CLASS of the same declared type are type compatible, - but have different characteristics. */ - if ((s1->ts.type == BT_CLASS && s2->ts.type == BT_DERIVED) - || (s1->ts.type == BT_DERIVED && s2->ts.type == BT_CLASS)) -return false; - return gfc_compare_types (>ts, >ts) || s2->ts.type == BT_ASSUMED; } This was added by Tobias in r201329 (for PR 57530), which is certainly the origin of the regression. Unfortunately the commit does not include a test case, nevertheless I expect that the patch above will trigger some testsuite regressions (but haven't checked yet).
[Bug fortran/39627] [meta-bug] Fortran 2008 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627 Bug 39627 depends on bug 45521, which changed state. Bug 45521 Summary: [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from janus at gcc dot gnu.org --- (In reply to janus from comment #21) > Still open: Comment 19. Fixed with r263308. Closing for good.
[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521 --- Comment #22 from janus at gcc dot gnu.org --- Author: janus Date: Sat Aug 4 15:37:23 2018 New Revision: 263308 URL: https://gcc.gnu.org/viewcvs?rev=263308=gcc=rev Log: 2018-08-04 Janus Weil PR fortran/45521 * interface.c (gfc_compare_interfaces): Apply additional distinguishability criteria of F08 to operator interfaces. 2018-08-04 Janus Weil PR fortran/45521 * gfortran.dg/interface_assignment_6.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/interface_assignment_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/86855] REGRESSON: [8.0] -Ofast optimize away mm_set_ps(0.0f,0.0f,-0.0f,0.0f);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86855 --- Comment #5 from vincenzo Innocente --- I have indeed worked-around with const __m128i neg = _mm_set_epi32(0,0,0x8000,0); __m128i ret = __m128i(_mm_sub_ps(v5, v3)); return __m128(_mm_xor_si128(ret,neg)); const __m256i neg = _mm256_set_epi64x(0,0,0x8000,0); return __m256d(_mm256_xor_si256(__m256i(ret), neg)); etc
[Bug tree-optimization/86855] REGRESSON: [8.0] -Ofast optimize away mm_set_ps(0.0f,0.0f,-0.0f,0.0f);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86855
--- Comment #4 from Marc Glisse ---
It happens during inlining.
If I write instead:
const __m128 neg={0.0f,0.0f,-0.0f,-0.0f};
then the front-end already turns it into
const __m128 neg = { 0.0, 0.0, 0.0, 0.0 };
You really need -fsigned-zeros to counteract what -Ofast is doing there.
The question is whether we should have a way to ignore signed zero arithmetic
issues (simplify x+(±0.) to x) without arbitrarily changing the sign of a
constant 0 we happen to have already, which may be used in weird bit
operations. That may not be trivial to specify, but the special case of SSE on
x86 is a motivation.
Workarounds may include specifying the vector as an integer vector, going
through inline asm to hide the constants, etc.
[Bug tree-optimization/86855] REGRESSON: [8.0] -Ofast optimize away mm_set_ps(0.0f,0.0f,-0.0f,0.0f);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86855 --- Comment #3 from vincenzo Innocente --- looks more undefined behavior as const __m128 neg = _mm_set_ps(0.0f,0.0f,-0.0f,-0.0f); return _mm_xor_ps(_mm_sub_ps(v5, v3), neg); with -O3 compiles in xorps .LC0(%rip), %xmm0 ret .LC0: .long 2147483648 .long 2147483648 .long 0 .long 0 while -Ofast in xorps .LC0(%rip), %xmm0 ret .LC0: .long 2147483648 .long 2147483648 .long 2147483648 .long 2147483648 needless to say that neither clang nor icc display such a behavior...
[Bug libstdc++/86852] map and unordered_map wrong deduction guides for inilializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86852
--- Comment #3 from Michael Veksler ---
I agree that this is a ridiculous example. That's why there should be an
official DR to it. It is a bad idea to have each compiler, do a different thing
-- that's why there is a C++ standard. clang are sticking to the standard, so
code that compiles under clang does not compile under gcc and vice versa.
As you mention, there is https://cplusplus.github.io/LWG/issue3025 ,
but even if this proposal is accepted things are still too brittle in libstd++:
std::unordered_map m{{1,2}, {3,4}} does not work, and forcing
std::unordered_map m{std::pair{1,2}, {3,4}} is counterintuitive.
Worse:
std::unordered_map m(
std::initializer_list>{
{1, 2}, {2, 3}});
does not work, which means that:
std::unordered_map m(
std::initializer_list>{
{1, 2}, {2, 3}});
does not work either.
It took me some time to find the right combination that makes this work, which
you mentioned above. I have seen other struggle with this, so it is not just
me. The current way GCC does is not very intuitive.
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #19 from janus at gcc dot gnu.org --- (In reply to janus from comment #17) > Huh, sounds possible. However, I see the buggy behavior also with sde64 (on > the same machine where I also see it in real HW, see comment 16). Another machine (Haswell CPU, Ubuntu 18.04) also shows the bug with sde64.
[Bug tree-optimization/86855] REGRESSON: [8.0] -Ofast optimize away mm_set_ps(0.0f,0.0f,-0.0f,0.0f);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86855 --- Comment #2 from Marc Glisse --- More precisely -ffast-math implies -fno-signed-zeros.
[Bug fortran/56491] [OOP] Memory leak with vtab's type-bound-procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56491 janus at gcc dot gnu.org changed: What|Removed |Added Blocks|86754 |68800 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > On darwin10, r208594, I get > > ==84656== 4 bytes in 1 blocks are definitely lost in loss record 1 of 2 > ==84656==at 0x100012679: malloc (vg_replace_malloc.c:266) > ==84656==by 0x10C90: MAIN__ (in ./a.out) > ==84656==by 0x10D87: main (in ./a.out) Dominique, you're running valgrind on a.out; Tobias was running it on gfortran/f951. This PR is concerned with compile-time leaks, not run-time leaks, therefore it should not block PR 86754, but rather PR 68800. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 [Bug 68800] Fortran FE produces many memory leaks https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86754 [Bug 86754] [meta-bug] Memory leaks at run time
[Bug fortran/54384] gfortran memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Blocks|86754 |68800 --- Comment #12 from janus at gcc dot gnu.org --- This PR is concerned with compile-time leaks, not run-time leaks, therefore it should not block PR 86754, but rather PR 68800. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 [Bug 68800] Fortran FE produces many memory leaks https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86754 [Bug 86754] [meta-bug] Memory leaks at run time
[Bug testsuite/86153] [8/9 regression] test case g++.dg/pr83239.C fails starting with r261585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153 --- Comment #10 from uros at gcc dot gnu.org --- Author: uros Date: Sat Aug 4 10:09:21 2018 New Revision: 263307 URL: https://gcc.gnu.org/viewcvs?rev=263307=gcc=rev Log: PR testsuite/86153 * g++.dg/pr83239.C (dg-options): Add -finline-limit=500. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/g++.dg/pr83239.C
[Bug testsuite/86153] [8/9 regression] test case g++.dg/pr83239.C fails starting with r261585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153 --- Comment #9 from uros at gcc dot gnu.org --- Author: uros Date: Sat Aug 4 10:01:54 2018 New Revision: 263306 URL: https://gcc.gnu.org/viewcvs?rev=263306=gcc=rev Log: PR testsuite/86153 * g++.dg/pr83239.C (dg-options): Add -finline-limit=500. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/pr83239.C
[Bug libstdc++/86852] map and unordered_map wrong deduction guides for inilializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86852
--- Comment #2 from Jonathan Wakely ---
(In reply to Michael Veksler from comment #0)
> According to
> https://en.cppreference.com/w/cpp/container/unordered_map/deduction_guides
>
> Deduction guides for unodrered_map:
> template,
> class Pred = std::equal_to,
> class Alloc = std::allocator>>
> unordered_map(std::initializer_list>,
> typename /*see below*/::size_type = /*see below*/,
> Hash = Hash(), Pred = Pred(), Alloc = Alloc())
> -> unordered_map;
>
>
> Note that the guide is for std::pair, i.e., the key is const.
> In libstdc++'s unodered_map:
>
> unordered_map(initializer_list>,
> typename unordered_map::size_type = {},
> _Hash = _Hash(), _Pred = _Pred(), _Allocator =
> _Allocator())
> -> unordered_map<_Key, _Tp, _Hash, _Pred, _Allocator>;
>
>
> Note that pair<_Key, _Tp>, i.e., the key is not const.
>
> This breaks unordered_map and map deduction guides:
> #include
> #include
> int main() {
> std::unordered_map m1(std::initializer_list<
> std::pair>({{1, 2}, {2, 3}}));
> }
This is a ridiculous example, and I see no advantage to supporting it.
Ideally it would work as:
std::unordered_map m{{1,2}, {3,4}};
Having to write std::initializer_list> is ridiculous,
and giving the std::pair type explicitly isn't much better. You might as well
just avoid argument deduction entirely at that point:
std::unordered_map m{{1,2}, {3,4}};
The point of class template argument deduction is to simplify code, not so you
can make it far more verbose.
> The only way to make this work in gcc is
>std::unordered_map m{std::pair{1,2}, {3,4}};
You can deduce the pair type:
std::unordered_map m{std::pair{1,2}, {3,4}};
[Bug libstdc++/86852] map and unordered_map wrong deduction guides for inilializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86852 --- Comment #1 from Jonathan Wakely --- I think this is https://wg21.link/lwg3025
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #18 from janus at gcc dot gnu.org --- (In reply to janus from comment #17) > However, I see the buggy behavior also with sde64 (on > the same machine where I also see it in real HW, see comment 16). But then again, I don't see it with sde64 on a different machine: * Ubuntu 16.04 * kernel 4.15.0 * glibc 2.23 * binutils 2.26 Kernel version (and gcc trunk version) is the same. So what could it be that makes the difference? glibc? binutils? Something else?
[Bug tree-optimization/86855] REGRESSON: [8.0] -Ofast optimize away mm_set_ps(0.0f,0.0f,-0.0f,0.0f);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86855 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Most likely treating -0.0 the same as 0.0 as -ffast-math enables -ffinite-math-only. So yes, it is expected.
[Bug tree-optimization/86847] [9 Regression] Switch code size growth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86847 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-04 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine
[Bug tree-optimization/86855] New: REGRESSON: [8.0] -Ofast optimize away mm_set_ps(0.0f,0.0f,-0.0f,0.0f);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86855
Bug ID: 86855
Summary: REGRESSON: [8.0] -Ofast optimize away
mm_set_ps(0.0f,0.0f,-0.0f,0.0f);
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
Target Milestone: ---
this function
_m128 _mm_cross_ps(__m128 v1, __m128 v2) {
// same order is _MM_SHUFFLE(3,2,1,0)
// x2, z1,z1
__m128 v3 = _mm_shuffle_ps(v2, v1, _MM_SHUFFLE(3, 0, 2, 2));
// y1, x2,y2
__m128 v4 = _mm_shuffle_ps(v1, v2, _MM_SHUFFLE(3, 1, 0, 1));
__m128 v5 = _mm_mul_ps(v3, v4);
// x1, z2,z2
v3 = _mm_shuffle_ps(v1, v2, _MM_SHUFFLE(3, 0, 2, 2));
//y2, x1,y1
v4 = _mm_shuffle_ps(v2, v1, _MM_SHUFFLE(3, 1, 0, 1));
v3 = _mm_mul_ps(v3, v4);
const __m128 neg = _mm_set_ps(0.0f,0.0f,-0.0f,0.0f);
return _mm_xor_ps(_mm_sub_ps(v5, v3), neg);
}
compiled more or less in
mm_cross_ps(float __vector(4), float __vector(4)):
movaps %xmm1, %xmm2
movaps %xmm0, %xmm4
movaps %xmm0, %xmm3
shufps $202, %xmm0, %xmm2
shufps $209, %xmm1, %xmm4
shufps $202, %xmm1, %xmm3
shufps $209, %xmm0, %xmm1
mulps %xmm4, %xmm2
mulps %xmm3, %xmm1
movaps %xmm2, %xmm0
subps %xmm1, %xmm0
xorps .LC0(%rip), %xmm0
ret
.LC0:
.long 0
.long 2147483648
.long 0
.long 0
according to godbolt since 8.1 the xor is optimized away with -Ofast as
mm_cross_ps(float __vector(4), float __vector(4)):
movaps %xmm1, %xmm2
movaps %xmm0, %xmm4
movaps %xmm0, %xmm3
shufps $209, %xmm1, %xmm4
shufps $202, %xmm0, %xmm2
mulps %xmm4, %xmm2
shufps $202, %xmm1, %xmm3
shufps $209, %xmm0, %xmm1
mulps %xmm3, %xmm1
movaps %xmm2, %xmm0
subps %xmm1, %xmm0
ret
is this intended?
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #17 from janus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #14) > /usr/src/sde/sde64 -- ./pr86735 >1 2 3 4 5 6 > 7 8 9 10 11 12 13 > 14 15 16 >1 2 3 4 5 6 > 7 8 9 10 11 12 13 > 14 15 16 > Perhaps sde64 behaves differently from real HW? Huh, sounds possible. However, I see the buggy behavior also with sde64 (on the same machine where I also see it in real HW, see comment 16).
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #16 from janus at gcc dot gnu.org --- (In reply to H.J. Lu from comment #15) > I can no longer reproduce it under kernel 4.17.11. But five days ago you could, right? What changed in the meantime? I still see the problem with 8.2.0 and today's trunk, in the following setup: * Ubuntu 18.04, kernel 4.15.0 * Intel(R) Core(TM) i9-7980XE CPU * glibc 2.27, binutils 2.30
[Bug target/86831] three failures in gfortran.fortran-torture with "-Ofast -march=native" on skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86831 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to H.J. Lu from comment #7) > Which kernel are you using? 4.15.0-29-generic (as shipped with Ubuntu 18.04).
