[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131 --- Comment #12 from Jakub Jelinek --- Otherwise it LGTM, so please post it this week, I'd really like to see it in GCC 10.
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #11 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #10)
> Oh, and there is another case I'm worried about. While match.pd has the
> /* X == C (or X & Z == Y | C) is impossible if ~nonzero(X) & C != 0. */
> (for cmp (eq ne)
> (simplify
> (cmp:c (with_possible_nonzero_bits2 @0) (with_certain_nonzero_bits2 @1))
> (if (wi::bit_and_not (wi::to_wide (@1), get_nonzero_bits (@0)) != 0)
>{ constant_boolean_node (cmp == NE_EXPR, type); })))
> optimization, not sure if we can rely on that one happening always before
> this one, and if it doesn't, e.g.
> ((x & 6) == 5) & ((x & 15) == 13)
> where the precondition ((6 & 15) & 5) == ((6 & 15) & 13) is true we would
> incorrectly transform it into (x & 15) == 13, even when it should be false.
> So, shouldn't the precondition be (N) == (N) && (CST1&~N) == 0
> && (CST2&~M) == 0?
> Especially when get_nonzero_bits will not really do anything until ccp or
> other optimization determines those.
Yes I agree. Let me add those conditions too. Especially when it comes to
generic version, rather than just the gimple version.
[Bug target/93119] [ICE] The traditional TLS support of aarch64-ilp32 target may be not perfect while enable fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-03
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Target Milestone|--- |10.0
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Simplier patch, change PTR to P instead. Mine then.
That is:
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index f114f85..dd10ec5 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -6725,7 +6725,7 @@
[(parallel [(set (match_operand 0 "register_operand")
(call (mem:DI (match_dup 2)) (const_int 1)))
(unspec:DI [(const_int 0)] UNSPEC_CALLEE_ABI)
-(unspec:DI [(match_operand:PTR 1 "aarch64_valid_symref")]
UNSPEC_GOTSMALLTLS)
+(unspec:DI [(match_operand:P 1 "aarch64_valid_symref")]
UNSPEC_GOTSMALLTLS)
(clobber (reg:DI LR_REGNUM))])]
""
{
@@ -6736,7 +6736,7 @@
[(set (match_operand 0 "register_operand" "")
(call (mem:DI (match_operand:DI 2 "" "")) (const_int 1)))
(unspec:DI [(const_int 0)] UNSPEC_CALLEE_ABI)
- (unspec:DI [(match_operand:PTR 1 "aarch64_valid_symref" "S")]
UNSPEC_GOTSMALLTLS)
+ (unspec:DI [(match_operand:P 1 "aarch64_valid_symref" "S")]
UNSPEC_GOTSMALLTLS)
(clobber (reg:DI LR_REGNUM))
]
""
[Bug target/93119] [ICE] The traditional TLS support of aarch64-ilp32 target may be not perfect while enable fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
--- Comment #1 from Peakulorain ---
Here is my patch to fix this program.
diff -Nurp a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
--- a/gcc/config/aarch64/aarch64.md 2019-12-20 03:16:50.706754343 +0800
+++ b/gcc/config/aarch64/aarch64.md 2019-12-31 04:33:11.229005263 +0800
@@ -5288,20 +5288,41 @@
;; The TLS ABI specifically requires that the compiler does not schedule
;; instructions in the TLS stubs, in order to enable linker relaxation.
;; Therefore we treat the stubs as an atomic sequence.
-(define_expand "tlsgd_small_"
+(define_expand "tlsgd_small_si"
[(parallel [(set (match_operand 0 "register_operand" "")
(call (mem:DI (match_dup 2)) (const_int 1)))
-(unspec:DI [(match_operand:PTR 1 "aarch64_valid_symref" "")]
UNSPEC_GOTSMALLTLS)
+(unspec:DI [(match_operand:SI 1 "aarch64_valid_symref" "")]
UNSPEC_GOTSMALLTLS)
(clobber (reg:DI LR_REGNUM))])]
""
{
operands[2] = aarch64_tls_get_addr ();
})
-(define_insn "*tlsgd_small_"
+(define_expand "tlsgd_small_di"
+ [(parallel [(set (match_operand 0 "register_operand" "")
+ (call (mem:DI (match_dup 2)) (const_int 1)))
+ (unspec:DI [(match_operand:DI 1 "aarch64_valid_symref" "")]
UNSPEC_GOTSMALLTLS)
+ (clobber (reg:DI LR_REGNUM))])]
+ ""
+{
+ operands[2] = aarch64_tls_get_addr ();
+})
+
+(define_insn "*tlsgd_small_si"
[(set (match_operand 0 "register_operand" "")
(call (mem:DI (match_operand:DI 2 "" "")) (const_int 1)))
- (unspec:DI [(match_operand:PTR 1 "aarch64_valid_symref" "S")]
UNSPEC_GOTSMALLTLS)
+ (unspec:DI [(match_operand:SI 1 "aarch64_valid_symref" "S")]
UNSPEC_GOTSMALLTLS)
+ (clobber (reg:DI LR_REGNUM))
+ ]
+ ""
+ "adrp\\tx0, %A1\;add\\tx0, x0, %L1\;bl\\t%2\;nop"
+ [(set_attr "type" "call")
+ (set_attr "length" "16")])
+
+(define_insn "*tlsgd_small_di"
+ [(set (match_operand 0 "register_operand" "")
+(call (mem:DI (match_operand:DI 2 "" "")) (const_int 1)))
+ (unspec:DI [(match_operand:DI 1 "aarch64_valid_symref" "S")]
UNSPEC_GOTSMALLTLS)
(clobber (reg:DI LR_REGNUM))
]
""
[Bug c++/93138] [10 regression] elaborated type specifier visibility check problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93138 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-03 CC||jakub at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r279480.
[Bug preprocessor/55820] cpp: unterminated argument list invoking macro "BAR" for #include in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55820 --- Comment #3 from Dominik Czarnota --- (In reply to Dominik Czarnota from comment #2) > Six years later this is still unconfirmed :(. Seven*. Oh those off by ones.
[Bug fortran/68020] Issue with implied-shape array parameter of rank > 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68020 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Jan 2 23:58:35 2020 New Revision: 279849 URL: https://gcc.gnu.org/viewcvs?rev=279849=gcc=rev Log: PR fortran/68020 * gfortran.dg/impled_shape_5.f90: Use dg-do compile rather than dg-do run. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/implied_shape_5.f90
[Bug preprocessor/55820] cpp: unterminated argument list invoking macro "BAR" for #include in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55820
Dominik Czarnota changed:
What|Removed |Added
CC||dominik.b.czarnota+bugzilla
||@gmail.com
--- Comment #2 from Dominik Czarnota ---
Six years later this is still unconfirmed :(.
>(In reply to Andrew Pinski from comment #1)
> yes this code is undefined at compile time. GCC used to reject #define in a
> macro usage but it was decided we will accept that. I can find the old bugs
> if needed.
Shall this be then changed to WONTFIX (or INVALID)? It would be nice if someone
provide some C standard reference if there is something regarding to this.
Just for reference, I stumbled across this when analysing a CTF challenge
solution (https://twitter.com/disconnect3d_pl/status/1212880292593229825) and
wanted to do:
#define TOSTR(a) #a
#define hxp TOSTR(
#include "flag"
);
where the `flag` file contained: `hxp{flag}` (without backticks).
[Bug testsuite/93139] New: new test case gfortran.dg/implied_shape_5.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93139 Bug ID: 93139 Summary: new test case gfortran.dg/implied_shape_5.f90 fails Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/implied_shape_5.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O0 -pedantic-errors -B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs -B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs -L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs -lm -o ./implied_shape_5.exe /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/implied_shape_5.f90:10:31: Error: Bad specification for deferred shape array at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/implied_shape_5.f90:15:38: Error: Bad specification for assumed size array at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/implied_shape_5.f90:16:34: Error: Bad specification for assumed size array at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/implied_shape_5.f90:21:50: Error: Bad array specification for implied-shape array at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/implied_shape_5.f90:22:48: Error: Bad array specification for implied-shape array at (1) /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/implied_shape_5.f90:9:38: Error: Assumed size array at (1) must be a dummy argument compiler exited with status 1 PASS: gfortran.dg/implied_shape_5.f90 -O0 (test for errors, line 9) PASS: gfortran.dg/implied_shape_5.f90 -O0 (test for errors, line 10) PASS: gfortran.dg/implied_shape_5.f90 -O0 (test for errors, line 15) PASS: gfortran.dg/implied_shape_5.f90 -O0 (test for errors, line 16) PASS: gfortran.dg/implied_shape_5.f90 -O0 (test for errors, line 21) PASS: gfortran.dg/implied_shape_5.f90 -O0 (test for errors, line 22) Executing on host: /home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/ exceptions_enabled119839.c-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -S -o exceptions_enabled119839.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/ exceptions_enabled119839.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -S -o exceptions_enabled119839.s exceptions_enabled119839.c: In function 'foo': exceptions_enabled119839.c:4:7: error: 'throw' undeclared (first use in this function) exceptions_enabled119839.c:4:7: note: each undeclared identifier is reported only once for each function it appears in exceptions_enabled119839.c:4:12: error: expected ';' before numeric constant compiler exited with status 1 PASS: gfortran.dg/implied_shape_5.f90 -O0 (test for excess errors) UNRESOLVED: gfortran.dg/implied_shape_5.f90 -O0 compilation failed to produce executable
[Bug libstdc++/93121] std::bit_cast missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121 --- Comment #1 from Jonathan Wakely --- Not really a bug - C++20 isn't final yet, and we don't claim full support for the current draft (not even close).
[Bug c++/93120] gcc-9 complains fails to see that switch handles all enum values, and still complains ' "control reaches end of non-void function" when there is no return after the switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93120 --- Comment #2 from Jonathan Wakely --- Also this is not a valid bug report. https://gcc.gnu.org/bugs clearly says we need you to provide the actual code, not a URL.
[Bug debug/93122] ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93122 --- Comment #3 from Segher Boessenkool --- Alternatively, we should generate the patterns we have by name, not indirectly like this.
[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093 --- Comment #4 from JeanHeyd Meneide --- I changed the library test cases, but maybe there needs to be something that helps the library developers tag a constant evaluation function as something that should be ran later / deferred. I don't have any good ideas, just spitballing. Either way, the new patch passes by not testing for some of the cases similar to what's in the Standard passage in [support.srcloc]: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00036.html
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #10 from Jakub Jelinek ---
Oh, and there is another case I'm worried about. While match.pd has the
/* X == C (or X & Z == Y | C) is impossible if ~nonzero(X) & C != 0. */
(for cmp (eq ne)
(simplify
(cmp:c (with_possible_nonzero_bits2 @0) (with_certain_nonzero_bits2 @1))
(if (wi::bit_and_not (wi::to_wide (@1), get_nonzero_bits (@0)) != 0)
{ constant_boolean_node (cmp == NE_EXPR, type); })))
optimization, not sure if we can rely on that one happening always before this
one, and if it doesn't, e.g.
((x & 6) == 5) & ((x & 15) == 13)
where the precondition ((6 & 15) & 5) == ((6 & 15) & 13) is true we would
incorrectly transform it into (x & 15) == 13, even when it should be false.
So, shouldn't the precondition be (N) == (N) && (CST1&~N) == 0 &&
(CST2&~M) == 0?
Especially when get_nonzero_bits will not really do anything until ccp or other
optimization determines those.
[Bug c++/93138] New: [10 regression] elaborated type specifier visibility check problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93138
Bug ID: 93138
Summary: [10 regression] elaborated type specifier visibility
check problem
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s...@li-snyder.org
Target Milestone: ---
hi -
With this version of gcc10 (svn rev 279832):
gcc version 10.0.0 20200102 (experimental) (GCC)
This source does not compile:
-- x.cc -
struct Foo
{
enum Kind { a };
private:
Kind Kind;
};
enum Foo::Kind foo();
-
$ g++ -std=c++17 -c x.cc
x.cc: In function ‘Foo::Kind foo()’:
x.cc:9:11: error: ‘Foo::Kind Foo::Kind’ is private within this context
9 | enum Foo::Kind foo();
| ^~~~
x.cc:6:8: note: declared private here
6 | Kind Kind;
|^~~~
$
This does compile OK with gcc 9.2.1 and with clang 8.0.0
The source from which this was reduced also built ok with gcc trunk
10.0.0 20191202.
[Bug debug/93122] ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93122 --- Comment #2 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #1) > Created attachment 47581 [details] > gcc10-pr93122.patch > > Untested fix. With additional -fno-asynchronous-unwind-tables, it doesn't > ICE, but just emit wrong-code, the stack clash protection code expects r12 > to be r1 + stack offset, but it is not initialized to anything at all. > The bug seems to be that add3 expander uses reg_or_add_cint_operand > predicate for the last operand and if that isn't satisfied, gen_add3_insn > simply doesn't emit anything. Yeah, gen_add3_insn needs to be fixed; it shouldn't silently generate bad code. This may not be so easy though? > On top of that, I think we want to use > add_operand as before too, because otherwise gen_add3_insn can emit multiple > instructions and in that case we really need to describe the effect to > dwarf2frame.c properly. Does that not happen automatically here?
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #9 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #8)
>
> Formatting, s/(/ (/g
>
> >}
> >(if (wi::eq(mask & cst1,mask & cst2))
>
> Ditto, also add space before ,
>
> > (cmp (bit_and @0 {wide_int_to_tree (type1, mask); } ) { wide_int_to_tree
>
> And here add space before wide_int_to_tree.
>
> > (cst1|cst2, mask); } )
>
> And these arguments need to be (type1, cst1 | cst2), right?
> The line is too long, so maybe put the second { wide_int... on another line
> indented below (bit_and ?
>
> > { constant_boolean_node (cmp == EQ_EXPR, type); }
I wrote that directly in the bug report :). Yes I Know the formating is wrong.
and looks like I messed up the arguments to the second wide_int_to_tree too
:).
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #8 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #7)
> so something like:
> (for bitop (bit_and bit_ior)
> cmp (eq ne)
> (simplify
> (bitop
>(cmp (bit_and @0 INTEGER_CST@mask1) INTEGER_CST@CST1)
>(cmp (bit_and @0 INTEGER_CST@mask2) INTEGER_CST@CST2))
> (with
>{
> tree type1 = TREE_TYPE (@0);
> wide_int mask = wi::to_wide(@mask1) | wi::to_wide(@mask2);
> wide_int cst1 = wi::to_wide(@cst1);
> wide_int cst2 = wi::to_wide(@cst2);
Formatting, s/(/ (/g
>}
>(if (wi::eq(mask & cst1,mask & cst2))
Ditto, also add space before ,
> (cmp (bit_and @0 {wide_int_to_tree (type1, mask); } ) { wide_int_to_tree
And here add space before wide_int_to_tree.
> (cst1|cst2, mask); } )
And these arguments need to be (type1, cst1 | cst2), right?
The line is too long, so maybe put the second { wide_int... on another line
indented below (bit_and ?
> { constant_boolean_node (cmp == EQ_EXPR, type); }
[Bug c++/93137] New: [10 regression] ICE in refs_may_alias_p_2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93137
Bug ID: 93137
Summary: [10 regression] ICE in refs_may_alias_p_2
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s...@li-snyder.org
Target Milestone: ---
hi -
With this version of gcc10 (svn rev 279832):
gcc version 10.0.0 20200102 (experimental) (GCC)
this source gives an ICE when compiled with -O:
-- x.cc -
#include
void foo (const std::string& s)
{
struct GCCLibSuffix {
std::string LibSuffix;
bool Active;
}
Suffixes[] =
{
{"/gcc/" + s, true}
};
}
-
$ g++ -std=c++17 -O -c x.cc
during IPA pass: fnsummary
x.cc: In function ‘void foo(const string&)’:
x.cc:13:1: internal compiler error: Segmentation fault
13 | }
| ^
0xc1467f crash_signal
/home/sss/gcc/gcc/gcc/toplev.c:328
0xcdb7c4 refs_may_alias_p_2
/home/sss/gcc/gcc/gcc/tree-ssa-alias.c:2190
0xcdc736 refs_may_alias_p_1(ao_ref*, ao_ref*, bool)
/home/sss/gcc/gcc/gcc/tree-ssa-alias.c:2227
0xcdc736 stmt_may_clobber_ref_p_1(gimple*, ao_ref*, bool)
/home/sss/gcc/gcc/gcc/tree-ssa-alias.c:3001
0xcdcdc0 walk_aliased_vdefs_1
/home/sss/gcc/gcc/gcc/tree-ssa-alias.c:3656
0xcdcf0f walk_aliased_vdefs(ao_ref*, tree_node*, bool (*)(ao_ref*, tree_node*,
void*), void*, bitmap_head**, bool*, unsigned int)
/home/sss/gcc/gcc/gcc/tree-ssa-alias.c:3679
0xa4cda2 parm_ref_data_pass_through_p
/home/sss/gcc/gcc/gcc/ipa-prop.c:1052
0xa58c39 ipa_compute_jump_functions_for_edge
/home/sss/gcc/gcc/gcc/ipa-prop.c:2237
0xa59cca ipa_compute_jump_functions_for_bb
/home/sss/gcc/gcc/gcc/ipa-prop.c:2297
0xa59cca analysis_dom_walker::before_dom_children(basic_block_def*)
/home/sss/gcc/gcc/gcc/ipa-prop.c:2823
0x137e977 dom_walker::walk(basic_block_def*)
/home/sss/gcc/gcc/gcc/domwalk.c:309
0xa5495d ipa_analyze_node(cgraph_node*)
/home/sss/gcc/gcc/gcc/ipa-prop.c:2893
0xa3c4df inline_indirect_intraprocedural_analysis
/home/sss/gcc/gcc/gcc/ipa-fnsummary.c:4020
0xa3c4df inline_analyze_function(cgraph_node*)
/home/sss/gcc/gcc/gcc/ipa-fnsummary.c:4040
0xa3c653 ipa_fn_summary_generate
/home/sss/gcc/gcc/gcc/ipa-fnsummary.c:4084
0xb5848b execute_ipa_summary_passes(ipa_opt_pass_d*)
/home/sss/gcc/gcc/gcc/passes.c:2189
0x86564d ipa_passes
/home/sss/gcc/gcc/gcc/cgraphunit.c:2629
0x86564d symbol_table::compile()
/home/sss/gcc/gcc/gcc/cgraphunit.c:2739
0x86712c symbol_table::compile()
/home/sss/gcc/gcc/gcc/cgraphunit.c:2719
0x86712c symbol_table::finalize_compilation_unit()
/home/sss/gcc/gcc/gcc/cgraphunit.c:2986
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.
$
Compiles OK with gcc 9.2.1.
The source from which this was reduced also built ok with gcc trunk
10.0.0 20191202.
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Note the generic version of this is:
> ((A & N) == CST1) & ((A & M) == CST2)
>
> if (N) == (N), then
>(A&(N|M)) == (CST1|CST2)
> else
> false
And now for the !=/| case:
((A & N) != CST1) | ((A & M) != CST2)
if (N) == (N), then
(A&(N|M)) != (CST1|CST2)
else
true
so something like:
(for bitop (bit_and bit_ior)
cmp (eq ne)
(simplify
(bitop
(cmp (bit_and @0 INTEGER_CST@mask1) INTEGER_CST@CST1)
(cmp (bit_and @0 INTEGER_CST@mask2) INTEGER_CST@CST2))
(with
{
tree type1 = TREE_TYPE (@0);
wide_int mask = wi::to_wide(@mask1) | wi::to_wide(@mask2);
wide_int cst1 = wi::to_wide(@cst1);
wide_int cst2 = wi::to_wide(@cst2);
}
(if (wi::eq(mask & cst1,mask & cst2))
(cmp (bit_and @0 {wide_int_to_tree (type1, mask); } ) { wide_int_to_tree
(cst1|cst2, mask); } )
{ constant_boolean_node (cmp == EQ_EXPR, type); }
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131 --- Comment #6 from Andrew Pinski --- Note the generic version of this is: ((A & N) == CST1) & ((A & M) == CST2) if (N) == (N), then (A&(N|M)) == (CST1|CST2) else false
[Bug fortran/65428] ICE on nest array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65428 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug target/93005] Redundant NEON loads/stores from stack are not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93005 --- Comment #2 from Joel Holdsworth --- Are you saying that if the GIMPLE were defined for the intrinsics, then the optimizer would eliminate them automatically? Or is there more to it?
[Bug target/93135] [10 Regression] g++.dg/cpp0x/initlist118.C fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93135 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |10.0 Summary|g++.dg/cpp0x/initlist118.C |[10 Regression] |fails on aarch64|g++.dg/cpp0x/initlist118.C ||fails on aarch64
[Bug c/90677] [9 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Jakub Jelinek --- Fixed for 9.3, 10.1 and later.
[Bug c/90677] [9 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 --- Comment #18 from Jakub Jelinek --- Author: jakub Date: Thu Jan 2 17:36:50 2020 New Revision: 279841 URL: https://gcc.gnu.org/viewcvs?rev=279841=gcc=rev Log: PR c/90677 * cp-objcp-common.c (identifier_global_tag): Return NULL_TREE if name has not been found, rather than error_mark_node. * c-c++-common/pr90677-2.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/c-c++-common/pr90677-2.c Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/cp-objcp-common.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c/90677] [9 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 --- Comment #17 from Jakub Jelinek --- Author: jakub Date: Thu Jan 2 17:29:59 2020 New Revision: 279840 URL: https://gcc.gnu.org/viewcvs?rev=279840=gcc=rev Log: PR c/90677 * cp-objcp-common.c (identifier_global_tag): Return NULL_TREE if name has not been found, rather than error_mark_node. * c-c++-common/pr90677-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr90677-2.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.c trunk/gcc/testsuite/ChangeLog
[Bug target/93110] [10 Regression] grub-2.04/grub-core/lib/division.c:28:1: internal compiler error: in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93110 --- Comment #3 from Khem Raj --- (In reply to Jakub Jelinek from comment #2) > Created attachment 47579 [details] > gcc10-pr93110.patch > > Untested fix. Thanks, I tried it out and it fixes the syslinux and grub failures on x86_64 that I was observing, I will give it a try for whole ycoto distro build tonight and see if it caused any other build regressions. But so far it looks okay
[Bug rtl-optimization/93088] [10 Regression] Compile time hog on gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93088
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
The problem is that pend is uninitialized in the testcase and we end up with:
(insn 6 70 71 14 (set (reg/v:DI 90 [ pend ])
(reg/v:DI 89 [ p ])) "pr56348.c":29:5 66 {*movdi_internal}
(nil))
and
(insn 9 88 63 12 (set (reg/v:DI 89 [ p ])
(reg/v:DI 90 [ pend ])) "pr56348.c":28:3 66 {*movdi_internal}
(nil))
as the only setters of the two pseudos (reg:DI 89 and reg:DI 90) and on that
kind of thing find_single_def_src just loops forever, alternating between the
two.
Hangs since r277923, but I think has been latent since r146700 aka
https://gcc.gnu.org/ml/gcc-patches/2009-04/msg00246.html
Guess a fix could be either to add some counter and punt after following e.g.
128 single definition pseudos with REG_P SET_SRCs, or add a hash_set or bitmap
or whatever to record pseudos we've seen already and punt when we notice a
loop, or combine both ways, start with handling a few without a bitmap/hash_set
and only after certain amount keep track on what we've seen and punt when we
see something again.
Though, even with a hash_set/bitmap, having unbounded search might result in
bad compilation complexity, if we have many loops with similar pseudos that
require extremely deep searches.
[Bug libgomp/93030] [OpenACC] libgomp.oacc-c-c++-common/deep-copy-10.c FAILS on AMDGCN – invalid 'async' usage?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93030 --- Comment #1 from jules at gcc dot gnu.org --- Thanks for the report -- there's a fix for this on the og9 branch, but I'm not sure if I've posted that upstream (the GCN worker-partitioning patches were separated out from the deep-copy patches, so fixes around the intersection of those two features are easy to overlook). I'll dig that up and post it.
[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92929 --- Comment #6 from jules at gcc dot gnu.org --- Apologies for breakage. This part of the patch was originally from the og9 patch supporting Fortran polymorphic class pointers posted at https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00752.html. The rationale was as follows: [...] OpenACC "enter data" and "exit data" now have GOMP_MAP_POINTER and GOMP_MAP_PSET mappings removed during gimplification. In some circumstances, passing an array to a function/subroutine and then doing an "enter data" on it could leave dangling references to the function's stack, although the actual array data is defined outside the function. In any case, the pointer/pointer-set mappings don't seem to be necessary for OpenACC "enter data". I observed the described problem with a large test program, and unfortunately did not manage to come up with a minimised test case at the time. Someone more familiar with Fortran might be able to do so more easily than me! In terms of backwards compatibility, we can't do anything about the "parasitic binding" to a function's expired stack frame as generated by an older version of the compiler in this case, I don't think. That's most likely going to manifest as an intermittent crash.
[Bug ipa/93115] gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115 Jan Hubicka changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #5 from Jan Hubicka --- OK, the missed optimization follows from the following: 1) ipa-cp creates specialized node for o. It is called only once from fn3 p calls unspecialized o. I wonder why this happens since both calls in p and fn3 leads to devirtualization. 2) inliner inlines k to o. This does not enable devirtualization because o is not specialized. 3) at the end of inlining remove_unreachable_nodes removes the offiline copy of m::av 4) we inline o to p enabling devirtualization but it is too late. Adding inline keyword to p makes inliner to inline it early but we still miss the devirutalization. So we have two issues a) for some reason ipa-cp rules out reasonable specialization I it is decided here: Evaluating opportunities for void o(j&)/11. - considering value for param #0 p1 (caller_count: 1) good_cloning_opportunity_p (time: 1, size: 36, freq_sum: 1000) -> evaluation: 27, threshold: 500 good_cloning_opportunity_p (time: 199, size: 120, freq_sum: 1000) -> evaluation: 1658, threshold: 500 Creating a specialized node of void o(j&)/11. the new node is o.constprop/37. known ctx 0 is Outer type:struct j offset 0 - considering value for param #0 p1 (caller_count: 1) good_cloning_opportunity_p (time: 1, size: 36, freq_sum: 202) -> evaluation: 5, threshold: 500 good_cloning_opportunity_p (time: 103, size: 120, freq_sum: 202) -> evaluation: 173, threshold: 500 I assume it is because freq_sum is 202 instead of 1000 because call is conditional, but that is really way too strict... 20% is outcome of: Predictions for bb 2 DS theory heuristics: 20.24% combined heuristics: 20.24% call heuristics of edge 2->3: 33.00% early return (on trees) heuristics of edge 2->3: 34.00% Predictions for bb 3 which seems reasonable. b) we do not devirtualize after inlining. We combine context correctly: Polymorphic call context combine:Speculative outer type:struct j (or a derived type) at offset 0 With context:Outer type:struct m offset 0 Updated as: Outer type:struct m offset 0 Speculative outer type:struct j (or a derived type) at offset 0 but I am not sure why it does not trigger devirt at this stage. We also do not need to have speculative outer type when we know outer type precisely, but it is cosmetic issue.
[Bug tree-optimization/91579] tailr1 pass creates redundant phi nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91579 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Jambor --- This has been fixed with the following, sorry about messing up the ChangeLog PR reference: Author: jamborm Date: Fri Aug 30 08:08:42 2019 New Revision: 275062 URL: https://gcc.gnu.org/viewcvs?rev=275062=gcc=rev Log: [PR 91579] Avoid creating redundant PHI nodes in tail-call pass 2019-08-30 Martin Jambor tree-optimization/91579 * tree-tailcall.c (tailr_arg_needs_copy): New variable. (find_tail_calls): Allocate tailr_arg_needs_copy and set its bits as appropriate. (arg_needs_copy_p): Removed. (eliminate_tail_call): Test tailr_arg_needs_copy instead of calling arg_needs_copy_p. (tree_optimize_tail_calls_1): Likewise. Free tailr_arg_needs_copy. testsuite/ * gcc.dg/tree-ssa/pr91579.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr91579.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-tailcall.c
[Bug target/93136] [10 regression] gcc.dg/vmx/ops.c and several other test break after r279772
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93136 Peter Bergner changed: What|Removed |Added CC||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Target Milestone|--- |10.0
[Bug target/93136] [10 regression] gcc.dg/vmx/ops.c and several other test break after r279772
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93136 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-02 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Peter Bergner --- Mine. Strange, I did BE testing on POWER8 and didn't see these.
[Bug c++/93106] [c++2a] Deleted move constructor is not selected when returning an automatic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93106 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- What you cite doesn't say anything that would make the testcase invalid. The standard says that for an implicitly movable entity seen in return statement shall first perform overload resolution for the copy constructor as if it was an rvalue, which in this case fails because the move ctor is deleted. And in that case, another overload resolution is performed, this time considering the implicitly movable entity as lvalue, and that succeeds. So, if copy-ellision wouldn't be performed, not_movable::not_movable(not_movable const&) would be invoked, but in this case copy-ellision is invoked and thus it is default constructed into the return value object in the caller.
[Bug ipa/93115] gcc fails to emit inline function on llvm-roc project: -O1 -fPIC -fdevirtualize -fdevirtualize-speculatively -fipa-cp -fipa-cp-clone -fvisibility-inlines-hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115
--- Comment #4 from Jan Hubicka ---
The problem here is that we produce ipa-cp clone to devirtualize v::av which
also lead to devirtualization of m::av, but we miss this optimization. After
inlining we remove m::av and while producing the ipa-cp clone we devirtualize
to it which elads to undefined reference.
I am testing the following:
Index: ipa.c
===
--- ipa.c (revision 279810)
+++ ipa.c (working copy)
@@ -187,6 +187,7 @@ walk_polymorphic_call_targets (hash_set<
for (i = 0; i < targets.length (); i++)
{
struct cgraph_node *n = targets[i];
+ bool added = false;
/* Do not bother to mark virtual methods in anonymous namespace;
either we will find use of virtual table defining it, or it is
@@ -212,11 +213,18 @@ walk_polymorphic_call_targets (hash_set<
&& symtab->state < IPA_SSA_AFTER_INLINING)
reachable->add (body);
reachable->add (n);
+ added = true;
}
/* Even after inlining we want to keep the possible targets in the
boundary, so late passes can still produce direct call even if
-the chance for inlining is lost. */
- enqueue_node (n, first, reachable);
+the chance for inlining is lost.
+Do not keep references to comdat groups - removing their
definition
+first and adding references later is going to give undefined
+reference errors. */
+ if (added || (!DECL_COMDAT (n->decl)
+ || DECL_EXTERNAL (n->decl)
+ || !TREE_PUBLIC (n->decl)))
+ enqueue_node (n, first, reachable);
}
}
[Bug fortran/68020] Issue with implied-shape array parameter of rank > 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68020 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- Thanks for the bug report – and sorry for fixing it more than 4 years later. See also: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00024.html Close as FIXED
[Bug target/93136] New: [10 regression] gcc.dg/vmx/ops.c and several other test break after r279772
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93136
Bug ID: 93136
Summary: [10 regression] gcc.dg/vmx/ops.c and several other
test break after r279772
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
This is the list for powerpc64 BE on a power 8.
> FAIL: gcc.dg/vmx/ops.c -O0 (test for excess errors)
> FAIL: gcc.dg/vmx/ops.c -O1 (test for excess errors)
> FAIL: gcc.dg/vmx/ops.c -O2 (test for excess errors)
> FAIL: gcc.dg/vmx/ops.c -O2 -flto -fno-use-linker-plugin
> -flto-partition=none (test for excess errors)
> FAIL: gcc.dg/vmx/ops.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
> (test for excess errors)
> FAIL: gcc.dg/vmx/ops.c -O3 -g (test for excess errors)
> FAIL: gcc.dg/vmx/ops.c -Os (test for excess errors)
> FAIL: gcc.target/powerpc/vsx-vector-6.p7.c scan-assembler-times xxland 13
> FAIL: gcc.target/powerpc/vsx-vector-6.p7.c scan-assembler-times xxlxor 2
> FAIL: gcc.target/powerpc/vsx-vector-6.p8.c scan-assembler-times
> \\mxvcmpeqdp\\.\\s 5
> FAIL: gcc.target/powerpc/vsx-vector-6.p8.c scan-assembler-times
> \\mxvcmpgtdp\\.\\s 6
> FAIL: gcc.target/powerpc/vsx-vector-6.p8.c scan-assembler-times xxland 13
> FAIL: gcc.target/powerpc/vsx-vector-6.p8.c scan-assembler-times xxlxor 2
> FAIL: gcc.target/powerpc/vsx-vector-6.p9.c scan-assembler-times xxland 13
The vsx-vector-6.xx test failures vary depending on BE versus LE but the ops.c
test fails everywhere.
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vmx/ops.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never-O0 -maltivec
-mabi=altivec -std=gnu99 -mno-vsx -Wno-deprecated -S -o ops.s(timeout =
300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vmx/ops.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O0 -maltivec -mabi=altivec
-std=gnu99 -mno-vsx -Wno-deprecated -S -o ops.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vmx/ops.c: In function 'f19':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vmx/ops.c:1670:3: note: use
'-flax-vector-conversions' to permit conversions between vectors with differing
element types or numbers of subparts
In file included from
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vmx/ops.c:3:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vmx/ops.c:1670:19: error:
incompatible types when assigning to type '__vector signed char' {aka
'__vector(16) signed char'} from type '__vector __bool char' {aka '__vector(16)
__bool char'}
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vmx/ops.c:1673:19: error:
incompatible types when assigning to type '__vector signed char' {aka
'__vector(16) signed char'} from type '__vector __bool char' {aka '__vector(16)
__bool char'}
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vmx/ops.c: In function 'f28':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vmx/ops.c:2390:19: error:
incompatible types when assigning to type '__vector unsigned char' {aka
'__vector(16) unsigned char'} from type '__vector __bool char' {aka
'__vector(16) __bool char'}
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vmx/ops.c:2393:19: error:
incompatible types when assigning to type '__vector unsigned char' {aka
'__vector(16) unsigned char'} from type '__vector __bool char' {aka
'__vector(16) __bool char'}
compiler exited with status 1
[Bug fortran/68020] Issue with implied-shape array parameter of rank > 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68020 --- Comment #2 from Tobias Burnus --- Author: burnus Date: Thu Jan 2 15:40:51 2020 New Revision: 279835 URL: https://gcc.gnu.org/viewcvs?rev=279835=gcc=rev Log: Fortran] PR68020 – Fix implied-shape handling for rank > 2 PR fortran/68020 * array.c (gfc_match_array_spec): Fix implied-type matching for rank > 2. PR fortran/68020 * gfortran.dg/implied_shape_4.f90: New. * gfortran.dg/implied_shape_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/implied_shape_4.f90 trunk/gcc/testsuite/gfortran.dg/implied_shape_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog
[Bug target/93124] [10 Regression] ICE in df_install_refs at df-scan.c:2376
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93124
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org
Target Milestone|--- |10.0
Summary|ICE in df_install_refs at |[10 Regression] ICE in
|df-scan.c:2376 |df_install_refs at
||df-scan.c:2376
--- Comment #1 from Jakub Jelinek ---
Started with r276318.
Slightly tweaked testcase (e.g. no need for unsigned a[a];), still needs the
uninitialized b variable used in one of the variable length structures:
int x;
void fn2 ();
void fn3 ();
void fn4 ();
void fn5 ();
void fn6 ();
void
fn1 (void)
{
int n;
for (n = 0;; ++n) {
{
struct { char a[n]; } s;
fn2 (s);
}
struct { unsigned a[x]; } s;
int i, b;
for (i = 0; i < n; ++i)
;
fn2 (s);
{
struct { char a[n]; } s;
int i;
for (i = 0; i < n; ++i)
s.a[i] = i;
fn3 (s, s);
}
fn4 ();
{
struct { unsigned a[n]; } s;
fn5 (s);
}
{
struct { char a[b]; } s;
for (; i < n;)
s.a[i] = i;
fn6 (s);
}
}
}
[Bug target/93133] __builtin_isgreater emits trapping compare instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ktkachov at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This happens during combine. If whether the comparison raises exception or not is distinguished on aarch64 with CCFPEmode vs. CCFPmode, then guess the problem is when that distinction gets ignored (unless in fast-math mode) or when it goes away completely. So, either the Trying 11 -> 12: 11: r102:SI=cc:CCFP>0 REG_DEAD cc:CCFP 12: r98:SI=-r102:SI REG_DEAD r102:SI Successfully matched this instruction: (set (reg:SI 98) (neg:SI (gt:SI (reg:CCFP 66 cc) (const_int 0 [0] transformation is wrong (at least I don't see the new insn doing something different for CCFP vs. CCFPE modes), or the further one: Trying 7 -> 12: 7: cc:CCFP=cmp(r103:SF,r104:SF) REG_DEAD r104:SF REG_DEAD r103:SF 12: r98:SI=-cc:CCFP>0 REG_DEAD cc:CCFP Successfully matched this instruction: (set (reg:SI 98) (neg:SI (gt:SI (reg:SF 103) (reg:SF 104 where the CCFP vs. CCFPE mode goes away completely and is signalling always? in that case.
[Bug target/93135] New: g++.dg/cpp0x/initlist118.C fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93135 Bug ID: 93135 Summary: g++.dg/cpp0x/initlist118.C fails on aarch64 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- The test fails on aarch64: g++.dg/cpp0x/initlist118.C -std=c++14 (internal compiler error) g++.dg/cpp0x/initlist118.C -std=c++14 (test for excess errors) g++.dg/cpp0x/initlist118.C -std=c++17 (internal compiler error) g++.dg/cpp0x/initlist118.C -std=c++17 (test for excess errors) g++.dg/cpp0x/initlist118.C -std=c++2a (internal compiler error) g++.dg/cpp0x/initlist118.C -std=c++2a (test for excess errors) The log says: during RTL pass: reload /gcc/testsuite/g++.dg/cpp0x/initlist118.C: In function 'array<__vector(4) float, 4> transpose(array<__vector(4) float, 4>)': /gcc/testsuite/g++.dg/cpp0x/initlist118.C:25:1: internal compiler error: maximum number of generated reload insns per insn achieved (90) 0xd7686f lra_constraints(bool) /gcc/lra-constraints.c:4946 0xd5d834 lra(_IO_FILE*) /gcc/lra.c:2437 0xd10209 do_reload /gcc/ira.c:5526 0xd10209 execute /gcc/ira.c:5712
[Bug fortran/68950] [fortran] gfc_format_decoder cannot handle %qE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68950 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #13 from Tobias Burnus --- I believe this has been fixed properly by the patch for PR fortran/79886 in r246203 by adding the following to gcc/fortran/error.c's gfc_format_decoder: default: - return false; + /* Fall through info the middle-end decoder, as e.g. stor-layout.c +etc. diagnostics can use the FE printer while the FE is still +active. */ + return default_tree_printer (pp, text, spec, precision, wide, + set_locus, hash); HENCE: Closed as FIXED. @Tom: Sorry for now following up to your RFC patch of 2015 and two-follow-up pings in 2016 and 2018. — I strongly believe the mentioned patch by Jakub fixes the issue properly; if you disagree, feel free to reopen this PR.
[Bug tree-optimization/93134] New: [graphite] ICE: Segmentation fault in ISL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93134
Bug ID: 93134
Summary: [graphite] ICE: Segmentation fault in ISL
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: drfiemost at email dot it
Target Milestone: ---
Getting a crash with snapshots gcc-9-20191221/gcc-8-20191220 and isl-0.22 on
x86_64-linux compiling the following reduced code using "-O2 -floop-block"
flags:
typedef struct {
int a[128]
} b;
b c;
d, e, f, g;
h() {
int i;
for (; g < e; g++) {
i = 1;
for (; i < d; i++)
c.a[f + i * 16 + g] = c.a[6 + g];
}
}
root [ /mnt/devel/build/gcc/gcc-9-20191221/build ]# LANG=C gcc/cc1 -O2
-floop-block /usr/src/gcc_ice.c
/usr/src/gcc_ice.c:3:1: warning: no semicolon at end of struct or union
3 | } b;
| ^
/usr/src/gcc_ice.c:5:1: warning: data definition has no type or storage class
5 | d, e, f, g;
| ^
/usr/src/gcc_ice.c:5:1: warning: type defaults to 'int' in declaration of 'd'
[-Wimplicit-int]
/usr/src/gcc_ice.c:5:4: warning: type defaults to 'int' in declaration of 'e'
[-Wimplicit-int]
5 | d, e, f, g;
|^
/usr/src/gcc_ice.c:5:7: warning: type defaults to 'int' in declaration of 'f'
[-Wimplicit-int]
5 | d, e, f, g;
| ^
/usr/src/gcc_ice.c:5:10: warning: type defaults to 'int' in declaration of 'g'
[-Wimplicit-int]
5 | d, e, f, g;
| ^
h
/usr/src/gcc_ice.c:6:1: warning: return type defaults to 'int' [-Wimplicit-int]
6 | h() {
| ^
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Streaming LTO
Assembling
functions:
hduring GIMPLE pass: graphite
/usr/src/gcc_ice.c: In function 'h':
/usr/src/gcc_ice.c:6:1: internal compiler error: Segmentation fault
0x1128de4 crash_signal
../../gcc/toplev.c:326
0x7f9145e857bf ???
/mnt/devel/build/glibc/glibc-2.30/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x21433a8 isl_basic_map_underlying_set
../../isl/isl_map.c:5515
0x20ec8ea equalities_in_underlying_set
../../isl/isl_affine_hull.c:860
0x20ecae4 isl_basic_map_detect_equalities
../../isl/isl_affine_hull.c:919
0x20ecc9b isl_basic_set_detect_equalities
../../isl/isl_affine_hull.c:952
0x21611ff uset_gist
../../isl/isl_map_simplify.c:2702
0x2162008 isl_basic_map_gist
../../isl/isl_map_simplify.c:3176
0x21622d1 isl_map_gist_basic_map
../../isl/isl_map_simplify.c:3234
0x2162dca map_gist
../../isl/isl_map_simplify.c:3601
0x2139072 isl_map_align_params_map_map_and
../../isl/isl_map.c:1531
0x2162e20 isl_map_gist
../../isl/isl_map_simplify.c:3611
0x2162ffe isl_map_gist_domain
../../isl/isl_map_simplify.c:3661
0x21ed605 bin_add_pair
../../isl/isl_union_map.c:872
0x21ed88e gen_bin_entry
../../isl/isl_union_map.c:957
0x2125f7e isl_hash_table_foreach
../../isl/isl_hash.c:207
0x21ed985 gen_bin_op
../../isl/isl_union_map.c:982
0x21ee560 union_map_gist_domain
../../isl/isl_union_map.c:1390
0x21ee5aa isl_union_map_gist_domain
../../isl/isl_union_map.c:1403
0x1e77f5a optimize_isl
../../gcc/graphite-optimize-isl.c:128
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/92994] [10 Regression] ICE on invalid in gfc_get_class_from_expr, at fortran/trans-expr.c:486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92994 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- Not crashing but giving an odd error message is the following (for 'g'): program m implicit none print *, f(3) print *, g(3) contains recursive integer function f(n) integer, value :: n if (n == 0) then f = 1 else f = n * f (n-1) ! Error: … name of a recursive function and so refers to the result variable. end if end function f recursive integer function f(n) integer, value :: n if (n == 0) then f = 1 else associate (x => f(n-1)) f = n * x ! Error: Operands of binary numeric operator ‘*’ at (1) are INTEGER(4)/PROCEDURE end associate end if end function f end program m
[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 --- Comment #8 from Jan Hubicka --- > @Richi: > > About the param_max_fields_for_field_sensitive: > Do I understand it correctly that the param is used in IPA PTA for global > variables? If so, we can't easily use Optimization keyword as the param value > will not make sense to be different for different functions. There is global var use_field_sensitive which IMO needs to go but otherwise I think PTA should always analyze an assignment that is withing some function. So it can always query the OPTIMIZATION node of the function the statement lives in. Honza
[Bug target/93133] New: __builtin_isgreater emits trapping compare instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133
Bug ID: 93133
Summary: __builtin_isgreater emits trapping compare instruction
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Target: aarch64-*-*
Compile the following test case for aarch64 with -O2:
#include
int f(float x, float y)
{
std::feclearexcept(FE_ALL_EXCEPT);
int r = -__builtin_isgreater(x, y);
if (std::fetestexcept(FE_ALL_EXCEPT) != 0)
__builtin_abort();
return r;
}
int main()
{
float x = 0.f;
return f(x / x, 1.f);
}
The __builtin_isgreater call is turned into a trapping fcmgt instruction. The
negation is necessary to trigger this issue. The same issue seems to exists for
all non-trapping compare functions.
[Bug target/93123] Lacking basic optimization around __int128 bitwise operations against constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93123 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Similarly on x86_64: movq%rdi, %rax movq%rsi, %rdx andq$-16, %rax The problem on the rs6000 side is that it has andti3 instruction that is split quite late (post reload in split2) and that instruction enforces the immediate into register, even if e.g. both halves of it are suitable constants for having the immediate in it. E.g. the define_insn could be allowed some selected immediates in one of the operands and told RA that either it needs to be forced into a v register if the other registers are v too, or it can stay as immediate otherwise and then be split + handle the splitting e.g. with the & -1 special cases.
[Bug debug/93122] ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93122 --- Comment #1 from Jakub Jelinek --- Created attachment 47581 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47581=edit gcc10-pr93122.patch Untested fix. With additional -fno-asynchronous-unwind-tables, it doesn't ICE, but just emit wrong-code, the stack clash protection code expects r12 to be r1 + stack offset, but it is not initialized to anything at all. The bug seems to be that add3 expander uses reg_or_add_cint_operand predicate for the last operand and if that isn't satisfied, gen_add3_insn simply doesn't emit anything. On top of that, I think we want to use add_operand as before too, because otherwise gen_add3_insn can emit multiple instructions and in that case we really need to describe the effect to dwarf2frame.c properly.
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131 --- Comment #5 from Andrew Pinski --- So ((a&8) != 0 ) | ((a&2) != 0 ) is already handled by the generic "(x != 0 | y != 0) -> (x | typeof(x)(y)) != 0". Anyways this is for tomorrow.
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131 --- Comment #4 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #3) > We are still in stage3, why not do it now? > I don't see the point in handling &/== and |/!= in the same simplification > when you do something completely different for those. > Why not e.g. > (simplify > (bit_and:c >(eq (bit_and @0 INTEGER_CST@1) @1) >(eq (bit_and @0 INTEGER_CST@2) @2)) > (eq (bit_and @0 (bit_ior @1 @2)) (bit_ior @1 @2))) > and something with integer_onep@2 for the bit_ior/ne? > Also, why do you treat &/== and |/!= differently? > I mean, if ((x&7)==7)&((x&13)==13) can be optimized into (x&15)==15, why > can't you optimize ((x&7)!=7)|((x&13)!=13) into (x&15)!=15? integer_onep should have been integer_zerop :) I had a few typos anyways. I have to think this through really; that is why not for stage3; also I am working on other things at this point. This was a side part of the what was I working on doing. Also we change (x&7)==7 to (x&7)!=0 before hand which means we need to match that also.
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- We are still in stage3, why not do it now? I don't see the point in handling &/== and |/!= in the same simplification when you do something completely different for those. Why not e.g. (simplify (bit_and:c (eq (bit_and @0 INTEGER_CST@1) @1) (eq (bit_and @0 INTEGER_CST@2) @2)) (eq (bit_and @0 (bit_ior @1 @2)) (bit_ior @1 @2))) and something with integer_onep@2 for the bit_ior/ne? Also, why do you treat &/== and |/!= differently? I mean, if ((x&7)==7)&((x&13)==13) can be optimized into (x&15)==15, why can't you optimize ((x&7)!=7)|((x&13)!=13) into (x&15)!=15?
[Bug c/93132] New: bogus `attribute((access))' warning when size-index is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93132 Bug ID: 93132 Summary: bogus `attribute((access))' warning when size-index is specified Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Created attachment 47580 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47580=edit Use formatted attribute specifier `attrspec', not the input one Hi. `append_access_attrs' at `gcc/c-family/c-attribs.c' has a slight issue when it tries to match the size-index parameter: 3973 if (n2 && strncmp (attrstr + n1 + 1, pos + n1, n2)) The problem is that `attrstr' is the input / human-readable attribute string (e.g. `attribute((__read_only__, 1, 2))' and not the formatted one (denoted by `attrspec', e.g. `r0\01'). The corresponding warning message has this typo, too, and it uses `atoi (attrstr + n1 + 1)' while it should of course use `attrspec'. Attached a proposed patch. As a side note, it's possibly a bit misleading that the values in the warning message are one less than the given inputs; Perhaps `atoi()' values should be incremented by one.
[Bug target/93125] ICE in insert_regs, at cse.c:1128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93125 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Maybe dup of PR90275 ? I've given up on that one, needs somebody more familiar with CSE.
[Bug target/93126] PPC altivec -Wunused-but-set-variable false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93126 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Can't reproduce with powerpc64-linux, though I see much more severe issue, vec_promote just completely ignores the second argument and so if it e.g. has side-effects, those are ignored. Consider vec_promote (a, bar ()) where int bar (); isn't const or pure. With C++ a and b are reported with -Wunused-but-set-parameter, which means nothing in the end calls mark_exp_read on those (converts those from lvalues to rvalues).
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
--- Comment #2 from Andrew Pinski ---
Something like:
(for bitop (bit_and bit_ior)
cmp (eq ne)
(simplify
(bitop:c
(cmp (bit_and @0 INTEGER_CST@mask1) INTEGER_CST@CST1)
(cmp (bit_and @0 INTEGER_CST@mask2) INTEGER_CST@CST2))
(with
{
tree type1 = TREE_TYPE (@0);
wide_int mask1 = wi::to_wide (@mask1);
wide_int mask2 = wi::to_wide (@mask2);
tree mask = wide_int_to_tree (type1, mask1 | mask2);
}
(switch
(if (bitop == BIT_AND_EXPR
&& operand_equal_p (@mask1, @CST1, OEP_ONLY_CONST)
&& operand_equal_p (@mask1, @CST1, OEP_ONLY_CONST))
(cmp (bit_and @0 { mask; } ) { mask; } ))
(if (bitop == BIT_IOR_EXPR
&& integer_onep (@CST1)
&& integer_onep (@CST2))
(cmp (bit_and @0 { mask; } ) @CST1 )
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-02 Summary|((a&8) == 8) && ((a&2) == |((a&8) == 8) && ((a&2) == |2) is not optimized to |2) is not optimized to |(a&(8|2)) == * |(a&(8|2)) == (8|2) Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- I have this for GCC 11. I noticed this while working on lowering bit-fields and seeing if we implement an optimization from fold-const.c to later on.
[Bug tree-optimization/93131] New: ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131
Bug ID: 93131
Summary: ((a&8) == 8) && ((a&2) == 2) is not optimized to
(a&(8|2)) == *
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
int f(int a)
{
char b = (a&8) == 8;
char c = (a&2) == 2;
char d = (a&4) == 4;
return b
}
int f1(int a)
{
return (a&(8|2|4)) == (8|2|4);
}
[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 Martin Liška changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #7 from Martin Liška --- @Richi: About the param_max_fields_for_field_sensitive: Do I understand it correctly that the param is used in IPA PTA for global variables? If so, we can't easily use Optimization keyword as the param value will not make sense to be different for different functions.
[Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084 --- Comment #11 from Jan Hubicka --- > xxx.localalias is gcc-generated as a noninterposable alias to xxx. But I guess > target node returned by xxx.localalias->function_symbol() is not xxx. A simple that ought to return xxx unless the target of localalias is thunk that is not recursive. > thing we can do is to write a simple case to force generation of .localalias > and test that. To do that you can probably write simple C++ self-recursive inline function and compile with -fpic. Honza
Re: [Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO
> xxx.localalias is gcc-generated as a noninterposable alias to xxx. But I guess > target node returned by xxx.localalias->function_symbol() is not xxx. A simple that ought to return xxx unless the target of localalias is thunk that is not recursive. > thing we can do is to write a simple case to force generation of .localalias > and test that. To do that you can probably write simple C++ self-recursive inline function and compile with -fpic. Honza
[Bug tree-optimization/93118] >>32<<32 is not always converted into &~0ffffffffull at the tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93118 --- Comment #2 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > Created attachment 47578 [details] > gcc10-pr93118.patch Thanks, I did not expect this to be fixed for GCC 10 really :).
[Bug target/93130] New: PCC simple memset not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93130
Bug ID: 93130
Summary: PCC simple memset not inlined
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Input:
void memspace16(char *p)
{
memset(p, ' ', 16);
}
Expected result:
li 4,0x2020
rldimi 4,4,16,0
rldimi 4,4,32,0
std 4,0(3)
Splatting the memset input to 64-bit can be done using li + 2xrldimi.
But also
._Z13memspace16OptPc:
LFB..3:
lis 9,0x2020
ori 9,9,0x2020
sldi 9,9,32
oris 9,9,0x2020
ori 9,9,0x2020
std 9,0(3)
std 9,8(3)
blr
would perform better than the function call to memset.
[Bug target/93110] [10 Regression] grub-2.04/grub-core/lib/division.c:28:1: internal compiler error: in extract_insn, at recog.c:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93110 --- Comment #2 from Jakub Jelinek --- Created attachment 47579 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47579=edit gcc10-pr93110.patch Untested fix.
[Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084 --- Comment #10 from Martin Jambor --- (In reply to fxue from comment #8) > [...] > Then is there a case that a ipcp_lattice be shared by different cgraph nodes? No, there isn't.
[Bug target/93128] PPC small floating point constants can be constructed using vector operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93128 --- Comment #1 from Jens Seifert --- Wrong number range for Power7: -16..15
[Bug target/93129] New: PPC memset not using vector instruction on >= Power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93129
Bug ID: 93129
Summary: PPC memset not using vector instruction on >= Power8
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Input:
void memclear16(char *p)
{
memset(p, 0, 16);
}
void memFF16(char *p)
{
memset(p, 0xFF, 16);
}
Output:
._Z10memclear16Pc:
LFB..0:
li 9,0
std 9,0(3)
std 9,8(3)
blr
._Z7memFF16Pc:
LFB..1:
mflr 0
li 5,16
li 4,255
std 0,16(1)
stdu 1,-112(1)
LCFI..0:
bl .memset
nop
addi 1,1,112
LCFI..1:
ld 0,16(1)
mtlr 0
LCFI..2:
blr
Expected output:
vsplitb + vector store
Unaligned vector stores only perform on >= Power8, vector stores should be used
only on >= Power8. On Power7 you would need to know it is at least 8-byte
aligned.
vsplitb has the -16..+15 limit. On Power9 a splat for 0.255 exists.
[Bug ipa/93087] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93087 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Jan 2 09:15:00 2020 New Revision: 279829 URL: https://gcc.gnu.org/viewcvs?rev=279829=gcc=rev Log: PR ipa/93087 * predict.c (compute_function_frequency): Don't call warn_function_cold on functions that already have cold attribute. * c-c++-common/cold-1.c: New test. Added: trunk/gcc/testsuite/c-c++-common/cold-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/93118] >>32<<32 is not always converted into &~0ffffffffull at the tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93118 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-02 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 47578 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47578=edit gcc10-pr93118.patch Untested fix.
[Bug target/93128] New: PPC small floating point constants can be constructed using vector operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93128
Bug ID: 93128
Summary: PPC small floating point constants can be constructed
using vector operations
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Input:
#include
double d2()
{
return 2.0;
}
vector double v2()
{
return vec_splats(2.0);
}
gcc -O2 -maix64 -mcpu=power7 -maltivec const.C
gcc uses load from constant area.
Better alternative for "integer" values -15.0..+16.0.
vspltisw 0,
xvcvsxwdp 1,32
0.0 already get constructed using xxlxor, which is great.
Similar things can be done for
vector float v2f()
{
return vec_splats(2.0f);
}
[Bug target/93127] New: PPC altivec vec_promote creates unnecessary xxpermdi instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93127
Bug ID: 93127
Summary: PPC altivec vec_promote creates unnecessary xxpermdi
instruction
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
vec_promote can leave half of register undefined and therefore should not issue
extra instruction.
Input:
#include
double vmax(double a, double b)
{
#ifdef _BIG_ENDIAN
const int PREF = 0;
#else
const int PREF = 1;
#endif
vector double va = vec_promote(a,PREF);
vector double vb = vec_promote(b,PREF);
return vec_extract(vec_max(va, vb), PREF);
}
Output:
._Z4vmaxdd:
LFB..0:
xxpermdi 2,2,2,0
xxpermdi 1,1,1,0
xvmaxdp 1,1,2
# vec_extract to same register
blr
Both xxpermdi are unnecessary.
[Bug target/93127] PPC altivec vec_promote creates unnecessary xxpermdi instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93127 Jens Seifert changed: What|Removed |Added Target||powerpc-*-*-* --- Comment #1 from Jens Seifert --- Command line: gcc -O2 -maix64 -mcpu=power7 -maltivec warn.C -save-temps
[Bug target/93126] New: PPC altivec -Wunused-but-set-variable false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93126
Bug ID: 93126
Summary: PPC altivec -Wunused-but-set-variable false positive
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Input:
#include
double vmax(double a, double b)
{
#ifdef _BIG_ENDIAN
const long PREF = 0;
#else
const long PREF = 1;
#endif
vector double va = vec_promote(a,PREF);
vector double vb = vec_promote(b,PREF);
return vec_extract(vec_max(va, vb), PREF);
}
gcc -O2 -maix64 -mcpu=power7 -maltivec -Wall
warn.C: In function 'double vmax(double, double)':
warn.C:6:15: warning: variable 'PREF' set but not used
[-Wunused-but-set-variable]
const long PREF = 0;
^~~~
[Bug target/93125] New: ICE in insert_regs, at cse.c:1128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93125
Bug ID: 93125
Summary: ICE in insert_regs, at cse.c:1128
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: arm-linux-gnueabi
The following ICEs:
$ cat ice2.i
enum { LODI } a;
int *b;
long long c;
void fn1() {
for (;;)
switch (a)
case LODI:
*b = c -= (long long) << 32;
}
$ arm-linux-gnueabi-gcc -O3 -fno-dce -c ice2.i
ice2.i: In function ‘fn1’:
ice2.i:9:17: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
9 | *b = c -= (long long) << 32;
| ^
during RTL pass: cse_local
ice2.i:10:1: internal compiler error: in insert_regs, at cse.c:1128
10 | }
| ^
0x5a97a9 insert_regs
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:1128
0x1129488 cse_insn
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:5955
0x112b78d cse_extended_basic_block
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:6613
0x112b78d cse_main
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:6792
0x112c41d rest_of_handle_cse_after_global_opts
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:7764
0x112c41d execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cse.c:7815
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/93124] ICE in df_install_refs at df-scan.c:2376
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93124 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-02 Ever confirmed|0 |1 Known to fail||10.0
[Bug target/93124] New: ICE in df_install_refs at df-scan.c:2376
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93124
Bug ID: 93124
Summary: ICE in df_install_refs at df-scan.c:2376
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: aarch64-linux-gnu
The following test-case ICEs:
$ cat ice.i
int a;
void fn2();
void fn3();
void fn4();
void fn5();
void fn6();
void
fn1() {
int n = 0;
for (;; ++n) {
{
struct {
char a[n];
} s;
fn2(s);
}
struct {
unsigned a[a];
} s;
int i = 0, b;
for (; i < n; ++i)
;
fn2(s);
{
struct {
char a[n];
} s;
int i;
for (i = 0; i < n; ++i)
s.a[i] = i;
fn3(s, s);
}
fn4();
{
struct {
unsigned a[n];
} s;
fn5(s);
}
{
struct {
char a[b];
} s;
for (; i < n;)
s.a[i] = i;
fn6(s);
}
}
}
$ aarch64-linux-gnu-gcc ice.i -O2 -fno-rerun-cse-after-loop
-fno-guess-branch-probability -fno-tree-fre -c
during RTL pass: reload
ice.i: In function ‘fn1’:
ice.i:51:1: internal compiler error: Segmentation fault
51 | }
| ^
0xb118bf crash_signal
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.c:328
0x7f4f7b6bb14f ???
/usr/src/debug/glibc-2.30-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x788e04 df_install_refs
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2376
0x788ed8 df_install_refs
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2422
0x788ed8 df_refs_add_to_chains
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2422
0x78f275 df_bb_refs_record(int, bool)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:3339
0x78f48c df_scan_blocks()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:588
0x969776 do_reload
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5590
0x969776 execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5712
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/93123] Lacking basic optimization around __int128 bitwise operations against constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93123 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c++ |target Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- AARCH64 is fine: and128WithConst: and x1, x1, -16 ret So this is a target issue.
