help you to solve problem
Hi, Did you ever get the mobile battery that is not full capacity, or fake capacity. so that you need charge it several times within a day. now I can solve this problme for you.We specialized in mobile phone battery for 11 years with CE FCC ROHS certifications,fit for iPhone,Samsung,Tecno and other mobile phone brands, we have 200 workers,5000㎡，imported machine,over 3pcs per day,and 70% well sold in USA,Germany,UK,France and other countries,so we can meet most of your demand, OEM&ODM is acceptable. Free sample will send to you if you contact me to talk more. Whatsapp: 0086 15874215117 wechat: feiyangLXY Best regards, Danliya
[Bug inline-asm/88559] error: Stack Pointer register clobbered by '%rsp' in 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88559 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- .
[Bug target/88556] Inline built-in sinh, cosh, tanh for -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88556 --- Comment #1 from Richard Biener --- glibc does this because its __expm1l implementation happens to be fast? That is, the question would be whether this falls under "canonicalization" and thus appropriate for a match.pd pattern? Of course if x87 has exmp1 then optab expansion of those functions would be appropriate as well. Though again this can be achieved via generic code querying for such support via direct_optab_supported_p. Does glibc have vectorized expm1 so that via this expansion we coudl vectorize a loop containing sinh() calls?
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #15 from Arseny Solokha ---
In build_atomic_assign() we have
4222 /* Create the expressions for floating-point environment
4223 manipulation, if required. */
4224 bool need_fenv = (flag_trapping_math
4225 && (FLOAT_TYPE_P (lhs_type) || FLOAT_TYPE_P
(rhs_type)));
4226 tree hold_call = NULL_TREE, clear_call = NULL_TREE, update_call =
NULL_TREE;
4227 if (need_fenv)
4228 targetm.atomic_assign_expand_fenv (&hold_call, &clear_call,
&update_call);
which gets us into this block in rs6000_atomic_assign_expand_fenv():
38906 if (!TARGET_HARD_FLOAT)
38907 {
38908 #ifdef RS6000_GLIBC_ATOMIC_FENV
<…>
38951 *hold = build_call_expr (atomic_hold_decl, 1, fenv_addr);
38952 *clear = build_call_expr (atomic_clear_decl, 0);
38953 *update = build_call_expr (atomic_update_decl, 1,
38954 fold_convert (const_double_ptr,
fenv_addr));
38955 #endif
38956 return;
38957 }
(it's the first build_call_expr() that fails deeper in the call stack in
comment 5), so ICEs from both comment 0 and comment 5 naturally go away w/
-fno-trapping-math. And we simply bail out from building these atomic FENV
manipulation calls w/ target glibc < 2.19, according to
RS6000_GLIBC_ATOMIC_FENV definition, which might explain why not all compilers
necessary crash.
I believe ICEs in comment 0 and comment 5 are unrelated after all, as in the
latter case we seem to have a GC-related memory corruption which I cannot
trigger w/ the testcase from comment 0:
==13546== Invalid read of size 1
==13546==at 0xFD336F: contains_struct_check (tree.h:3270)
==13546==by 0xFD336F: build_call_expr_loc_array(unsigned int, tree_node*,
int, tree_node**) (tree.c:11398)
==13546==by 0xFD35D1: build_call_expr(tree_node*, int, ...) (tree.c:11448)
==13546==by 0x10530B3: rs6000_atomic_assign_expand_fenv(tree_node**,
tree_node**, tree_node**) (rs6000.c:38951)
==13546==by 0x7A8C68: build_atomic_assign(unsigned int, tree_node*,
tree_code, tree_node*, bool) (c-typeck.c:4228)
==13546==by 0x7A96B1: build_unary_op(unsigned int, tree_code, tree_node*,
bool) (c-typeck.c:4670)
==13546==by 0x7D3826: c_parser_postfix_expression_after_primary(c_parser*,
unsigned int, c_expr) (c-parser.c:9648)
==13546==by 0x7C5C54: c_parser_postfix_expression(c_parser*)
(c-parser.c:9215)
==13546==by 0x7CF5EA: c_parser_unary_expression(c_parser*)
(c-parser.c:7358)
==13546==by 0x7D05D7: c_parser_cast_expression(c_parser*, c_expr*)
(c-parser.c:7200)
==13546==by 0x7D0824: c_parser_binary_expression(c_parser*, c_expr*,
tree_node*) (c-parser.c:7003)
==13546==by 0x7D174B: c_parser_conditional_expression(c_parser*, c_expr*,
tree_node*) (c-parser.c:6737)
==13546==by 0x7D1E0B: c_parser_expr_no_commas(c_parser*, c_expr*,
tree_node*) (c-parser.c:6654)
==13546== Address 0x1fe4421 is not stack'd, malloc'd or (recently) free'd
(here I changed ggc-min-expand value to 0).
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #16 from rguenther at suse dot de ---
On Thu, 20 Dec 2018, asolokha at gmx dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
>
> --- Comment #15 from Arseny Solokha ---
> In build_atomic_assign() we have
>
> 4222 /* Create the expressions for floating-point environment
> 4223 manipulation, if required. */
> 4224 bool need_fenv = (flag_trapping_math
> 4225 && (FLOAT_TYPE_P (lhs_type) || FLOAT_TYPE_P
> (rhs_type)));
> 4226 tree hold_call = NULL_TREE, clear_call = NULL_TREE, update_call =
> NULL_TREE;
> 4227 if (need_fenv)
> 4228 targetm.atomic_assign_expand_fenv (&hold_call, &clear_call,
> &update_call);
>
> which gets us into this block in rs6000_atomic_assign_expand_fenv():
>
> 38906 if (!TARGET_HARD_FLOAT)
> 38907 {
> 38908 #ifdef RS6000_GLIBC_ATOMIC_FENV
>
> <…>
>
> 38951 *hold = build_call_expr (atomic_hold_decl, 1, fenv_addr);
> 38952 *clear = build_call_expr (atomic_clear_decl, 0);
> 38953 *update = build_call_expr (atomic_update_decl, 1,
> 38954 fold_convert (const_double_ptr,
> fenv_addr));
> 38955 #endif
> 38956 return;
> 38957 }
>
> (it's the first build_call_expr() that fails deeper in the call stack in
> comment 5), so ICEs from both comment 0 and comment 5 naturally go away w/
> -fno-trapping-math. And we simply bail out from building these atomic FENV
> manipulation calls w/ target glibc < 2.19, according to
> RS6000_GLIBC_ATOMIC_FENV definition, which might explain why not all compilers
> necessary crash.
>
> I believe ICEs in comment 0 and comment 5 are unrelated after all, as in the
> latter case we seem to have a GC-related memory corruption which I cannot
> trigger w/ the testcase from comment 0:
>
> ==13546== Invalid read of size 1
> ==13546==at 0xFD336F: contains_struct_check (tree.h:3270)
> ==13546==by 0xFD336F: build_call_expr_loc_array(unsigned int, tree_node*,
> int, tree_node**) (tree.c:11398)
> ==13546==by 0xFD35D1: build_call_expr(tree_node*, int, ...) (tree.c:11448)
> ==13546==by 0x10530B3: rs6000_atomic_assign_expand_fenv(tree_node**,
> tree_node**, tree_node**) (rs6000.c:38951)
> ==13546==by 0x7A8C68: build_atomic_assign(unsigned int, tree_node*,
> tree_code, tree_node*, bool) (c-typeck.c:4228)
> ==13546==by 0x7A96B1: build_unary_op(unsigned int, tree_code, tree_node*,
> bool) (c-typeck.c:4670)
> ==13546==by 0x7D3826: c_parser_postfix_expression_after_primary(c_parser*,
> unsigned int, c_expr) (c-parser.c:9648)
> ==13546==by 0x7C5C54: c_parser_postfix_expression(c_parser*)
> (c-parser.c:9215)
> ==13546==by 0x7CF5EA: c_parser_unary_expression(c_parser*)
> (c-parser.c:7358)
> ==13546==by 0x7D05D7: c_parser_cast_expression(c_parser*, c_expr*)
> (c-parser.c:7200)
> ==13546==by 0x7D0824: c_parser_binary_expression(c_parser*, c_expr*,
> tree_node*) (c-parser.c:7003)
> ==13546==by 0x7D174B: c_parser_conditional_expression(c_parser*, c_expr*,
> tree_node*) (c-parser.c:6737)
> ==13546==by 0x7D1E0B: c_parser_expr_no_commas(c_parser*, c_expr*,
> tree_node*) (c-parser.c:6654)
> ==13546== Address 0x1fe4421 is not stack'd, malloc'd or (recently) free'd
>
> (here I changed ggc-min-expand value to 0).
Ah, thanks for debugging. Obviously the following need to be GTY(())
#ifdef RS6000_GLIBC_ATOMIC_FENV
/* Function declarations for rs6000_atomic_assign_expand_fenv. */
static tree atomic_hold_decl, atomic_clear_decl, atomic_update_decl;
#endif
ppc folks?
[Bug c++/88193] [9 Regression] ICE on (invalid) C++ code: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88193 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug rtl-optimization/88296] [9 Regression] Infinite loop in lra_split_hard_reg_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88296 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug ada/88200] [9 Regression] ada bootstrap failure on alpha-linux-gnu (aised STORAGE_ERROR : stack overflow or erroneous memory access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88200 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug target/88530] [8/9 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug rtl-optimization/88423] [9 Regression] ICE in begin_move_insn, at sched-ebb.c:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88423 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug rtl-optimization/88296] [9 Regression] Infinite loop in lra_split_hard_reg_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88296 --- Comment #1 from Arseny Solokha --- I cannot reproduce it w/ gcc-9.0.0-alpha20181216 snapshot (r267191), so it either was fixed or went latent in the meantime.
[Bug target/83443] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for warnings, line 119)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83443 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #5 from Christophe Lyon --- They also pass on my side when using cross-compilers. However, looking at gcc-testsults, builtin-sprintf-warn-18.c fails on armv8l-unknown-linux-gnueabihf, but this Linaro config is a native one. In the native case, gcc.log has: /builtin-sprintf-warn-18.c:120:3: warning: '%9223372036854775808i' directive width out of range [-Wformat-overflow=] /builtin-sprintf-warn-18.c:122:3: warning: '%.9223372036854775808i' directive precision out of range [-Wformat-overflow=] In the cross-compiler case, my gcc.log has: /builtin-sprintf-warn-18.c: In function 'test_width_and_precision_out_of_range': /builtin-sprintf-warn-18.c:120:3: warning: '%9223372036854775808i' directive width out of range [-Wformat-overflow=] /builtin-sprintf-warn-18.c:120:3: warning: '%9223372036854775808i' directive output of 9223372036854775807 bytes causes result to exceed 'INT_MAX' [-Wformat-overflow=] /builtin-sprintf-warn-18.c:122:3: warning: '%.9223372036854775808i' directive precision out of range [-Wformat-overflow=] /builtin-sprintf-warn-18.c:122:3: warning: '%.9223372036854775808i' directive output of 9223372036854775807 bytes causes result to exceed 'INT_MAX' [-Wformat-overflow=]
[Bug target/88197] ICE in decompose_normal_address, at rtlanal.c:6381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88197 --- Comment #1 from Arseny Solokha --- It ICEs only w/ -m32, apparently.
[Bug middle-end/88560] New: armv8_2-fp16-move-1.c and related regressions after r260385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
Bug ID: 88560
Summary: armv8_2-fp16-move-1.c and related regressions after
r260385
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: samtebbs at gcc dot gnu.org
Target Milestone: ---
Created attachment 45266
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45266&action=edit
Code generated for armv8_2-fp16-move-1.c with r260385
Several regressions were seen on arm-none-linux-gnueabihf and arm-none-eabi
after r260385.
FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
ldrh\\tr[0-9]+ 2
FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
vld1\\.16\\t{d[0-9]+\\[[0-9]+\\]}, \\[r[0-9]+\\] 2
FAIL: gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
vmov\\.f16\\ts[0-9]+, r[0-9]+ 2
FAIL: gcc.target/arm/fp16-aapcs-1.c scan-assembler
vmov(\\.f16)?\\tr[0-9]+, s[0-9]+
FAIL: gcc.target/arm/fp16-aapcs-1.c scan-assembler vmov(\\.f16)?\\ts0,
r[0-9]+
FAIL: gcc.target/arm/fp16-aapcs-3.c scan-assembler-times vmov\\tr[0-9]+,
s[0-2] 2
FAIL: gcc.target/arm/fp16-aapcs-3.c scan-assembler-times vmov\\ts0,
r[0-9]+ 2
Full command line used to compile and test armv8_2-fp16-move-1.c (done by make
check-gcc):
bin/gcc armv8_2-fp16-move-1.c -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2
-mfpu=fp-armv8 -march=armv8.2-a+fp16 -mfloat-abi=hard -ffat-lto-objects
-fno-ident -S -o armv8_2-fp16-move-1.s.
[Bug middle-end/88560] armv8_2-fp16-move-1.c and related regressions after r260385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 --- Comment #1 from Sam Tebbs --- Created attachment 45267 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45267&action=edit Code generated for armv8_2-fp16-move-1.c without r260385
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r260385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 Richard Biener changed: What|Removed |Added Version|unknown |9.0 Target Milestone|--- |9.0 Summary|armv8_2-fp16-move-1.c and |[9 Regression] |related regressions after |armv8_2-fp16-move-1.c and |r260385 |related regressions after ||r260385
[Bug tree-optimization/84050] [7/8/9 Regression] missing -Warray-bounds accessing a struct array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 84051, which changed state. Bug 84051 Summary: [7/8/9 Regression] missing -Warray-bounds on an out-of-bounds access via an array pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84051 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug tree-optimization/84051] [7/8/9 Regression] missing -Warray-bounds on an out-of-bounds access via an array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84051 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Richard Biener --- int A4[4] is a trailing array so this was an intended change.
[Bug tree-optimization/84053] [7/8 Regression] missing -Warray-bounds accessing a local array across inlined function boundaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84053
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work||9.0
Resolution|--- |FIXED
Summary|[7/8/9 Regression] missing |[7/8 Regression] missing
|-Warray-bounds accessing a |-Warray-bounds accessing a
|local array across inlined |local array across inlined
|function boundaries |function boundaries
--- Comment #3 from Richard Biener ---
Fixed in GCC 9.
> ./cc1 -quiet t.c -O2 -Warray-bounds
t.c: In function ‘h’:
t.c:3:13: warning: array subscript [3, 2147483647] is outside array bounds of
‘int[2]’ [-Warray-bounds]
3 | return p[i];
|~^~~
t.c:8:9: note: while referencing ‘a’
8 | int a[] = { 2, 3 };
| ^
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 84053, which changed state. Bug 84053 Summary: [7/8 Regression] missing -Warray-bounds accessing a local array across inlined function boundaries https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84053 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/84204] [8/9 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84204 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/84481] [8/9 Regression] 429.mcf with -O2 regresses by ~6% and ~4%, depending on tuning, on Zen compared to GCC 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84481 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* --- Comment #6 from Richard Biener --- What's the state on trunk?
[Bug target/84490] [8/9 regression] 436.cactusADM regressed by 6-8% percent with -Ofast on Zen and Haswell, compared to gcc 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84490 --- Comment #9 from Richard Biener --- what's the state on trunk?
[Bug c/84919] [8/9 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/85145] [8/9 Regression] include_next broken icw/ --with-gxx-include-dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85145 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-12-20 Ever confirmed|0 |1
[Bug tree-optimization/85459] [8/9 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-20 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Richard Biener --- So it's if (TREE_CODE (ref) != MEM_REF || TREE_CODE (TREE_OPERAND (ref, 0)) != ADDR_EXPR) return false; tree mem = TREE_OPERAND (TREE_OPERAND (ref, 0), 0); if (TYPE_MAIN_VARIANT (TREE_TYPE (ref)) != TYPE_MAIN_VARIANT (TREE_TYPE (mem))) return true; specifically the TYPE_MAIN_VARIANT check. This is probably too conservative given it labels writing a.i as MEM[&a + 4] as VCE. I wonder if for the purpose of total scalarization we can ignore VCEs on aggregate copies in case we do not need to re-materialize the thing? Not having looked at the actual testcase here but guessing from the testcase added by the above change and memcpy inlining now generating char[] typed load/stores this is what prevents total scalarization in too many cases.
[Bug target/84481] [8/9 Regression] 429.mcf with -O2 regresses by ~6% and ~4%, depending on tuning, on Zen compared to GCC 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84481 --- Comment #7 from Martin Jambor --- (In reply to Richard Biener from comment #6) > What's the state on trunk? I should have my own measurements only in January but according to https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch there is still 4% regression at -O2 and even over 8% at -Ofast on Zen.
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 --- Comment #17 from Segher Boessenkool --- Like this: === diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 5120202..429eac5 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -38865,7 +38865,9 @@ emit_fusion_gpr_load (rtx target, rtx mem) #ifdef RS6000_GLIBC_ATOMIC_FENV /* Function declarations for rs6000_atomic_assign_expand_fenv. */ -static tree atomic_hold_decl, atomic_clear_decl, atomic_update_decl; +static GTY(()) tree atomic_hold_decl; +static GTY(()) tree atomic_clear_decl; +static GTY(()) tree atomic_update_decl; #endif /* Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook. */ === Arseny, can you test that please?
[Bug target/84490] [8/9 regression] 436.cactusADM regressed by 6-8% percent with -Ofast on Zen and Haswell, compared to gcc 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84490 --- Comment #10 from Martin Jambor --- I should have my own numbers only in January, but according to https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch there is a 7% regression at -Ofast and generic march/mtune on Zen.
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 --- Comment #18 from Segher Boessenkool --- Or, if you want your compiler to build: === diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 5120202..c041f15 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -38862,11 +38862,10 @@ emit_fusion_gpr_load (rtx target, rtx mem) return ""; } ^L - -#ifdef RS6000_GLIBC_ATOMIC_FENV /* Function declarations for rs6000_atomic_assign_expand_fenv. */ -static tree atomic_hold_decl, atomic_clear_decl, atomic_update_decl; -#endif +static GTY(()) tree atomic_hold_decl ATTRIBUTE_UNUSED; +static GTY(()) tree atomic_clear_decl ATTRIBUTE_UNUSED; +static GTY(()) tree atomic_update_decl ATTRIBUTE_UNUSED; /* Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook. */ ===
[Bug ipa/88561] New: [8/9 Regression] PGO devirtualization miscompilation of firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88561
Bug ID: 88561
Summary: [8/9 Regression] PGO devirtualization miscompilation
of firefox
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
g++ -O3 -fprofile-generate -o test{1,.C}; ./test1; g++ -O3 -fprofile-use -o
test{2,.C}; ./test2
aborts when using g++ 8 or current trunk.
struct nsISupports
{
virtual int QueryInterface (const int &aIID, void **aInstancePtr) = 0;
virtual __attribute__((noinline, noclone)) unsigned AddRef (void) = 0;
virtual unsigned Release (void) = 0;
};
struct nsIObserver : public nsISupports
{
virtual int Observe (nsISupports * aSubject, const char *aTopic, const
unsigned short *aData) = 0;
};
struct nsISupportsWeakReference : public nsISupports
{
virtual int GetWeakReference (void **_retval) = 0;
};
struct nsSupportsWeakReference : public nsISupportsWeakReference
{
nsSupportsWeakReference () : mProxy (0) {}
virtual int GetWeakReference (void **_retval) override { return 0; }
~nsSupportsWeakReference () {}
void NoticeProxyDestruction () { mProxy = nullptr; }
void *mProxy;
void ClearWeakReferences ();
bool HasWeakReferences () const { return !!mProxy; }
};
struct mozIPersonalDictionary : public nsISupports
{
virtual int Load (void) = 0;
virtual int Save (void) = 0;
virtual int GetWordList (void **aWordList) = 0;
virtual int Check (const int &word, bool * _retval) = 0;
virtual int AddWord (const int &word) = 0;
virtual int RemoveWord (const int &word) = 0;
virtual int IgnoreWord (const int &word) = 0;
virtual int EndSession (void) = 0;
};
struct mozPersonalDictionary final
: public mozIPersonalDictionary, public nsIObserver, public
nsSupportsWeakReference
{
virtual int QueryInterface (const int &aIID, void **aInstancePtr) override;
virtual __attribute__((noinline, noclone)) unsigned AddRef (void) override;
virtual unsigned Release (void) override;
unsigned long mRefCnt;
virtual int Load (void) override { return 0; }
virtual int Save (void) override { return 0; }
virtual int GetWordList (void **aWordList) override { return 0; }
virtual int Check (const int &word, bool * _retval) override { return 0; }
virtual int AddWord (const int &word) override { return 0; }
virtual int RemoveWord (const int &word) override { return 0; }
virtual int IgnoreWord (const int &word) override { return 0; }
virtual int EndSession (void) override { return 0; }
virtual int Observe (nsISupports * aSubject, const char *aTopic, const
unsigned short *aData) override { return 0; }
mozPersonalDictionary () : mRefCnt(0) {}
int Init () { return 0; }
virtual ~mozPersonalDictionary () {}
bool mIsLoaded;
bool mSavePending;
void *mFile;
char mMonitor[96];
char mMonitorSave[96];
char mDictionaryTable[32];
char mIgnoreTable[32];
};
unsigned
mozPersonalDictionary::AddRef (void)
{
unsigned count = ++mRefCnt;
return count;
}
unsigned
mozPersonalDictionary::Release (void)
{
unsigned count = --mRefCnt;
if (count == 0)
{
mRefCnt = 1;
delete (this);
return 0;
}
return count;
}
int
mozPersonalDictionary::QueryInterface (const int &aIID, void **aInstancePtr)
{
nsISupports *foundInterface;
if (aIID == 122)
foundInterface = static_cast (this);
else
foundInterface = static_cast (this);
int status;
foundInterface->AddRef ();
*aInstancePtr = foundInterface;
return status;
}
__attribute__((noipa)) int
foo (nsISupports *p, const int &i)
{
void *q;
return p->QueryInterface (i, &q);
}
int
main ()
{
mozPersonalDictionary m;
int j = 123;
for (int i = 0; i < 10; i++)
foo (static_cast (&m), j);
if (m.mRefCnt != 10)
__builtin_abort ();
}
Testcase reduced from firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=1495742
The problem is that in the
_ZThn8_N21mozPersonalDictionary14QueryInterfaceERKiPPv thunk we devirtualize
incorrectly, call _ZThn8_N21mozPersonalDictionary6AddRefEv when we should have
called _ZThn16_N21mozPersonalDictionary6AddRefEv instead.
[Bug ipa/88561] [8/9 Regression] PGO devirtualization miscompilation of firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88561 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-20 CC||hubicka at gcc dot gnu.org Target Milestone|--- |8.3 Ever confirmed|0 |1
[Bug tree-optimization/84362] [7/8 Regression] Auto-vectorization regression when accessing member variable through getter/accessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84362 Richard Biener changed: What|Removed |Added Known to work||9.0 Summary|[7/8/9 Regression] |[7/8 Regression] |Auto-vectorization |Auto-vectorization |regression when accessing |regression when accessing |member variable through |member variable through |getter/accessor |getter/accessor --- Comment #8 from Richard Biener --- Fixed on trunk.
[Bug tree-optimization/84362] [7/8 Regression] Auto-vectorization regression when accessing member variable through getter/accessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84362 --- Comment #9 from Richard Biener --- Author: rguenth Date: Thu Dec 20 11:39:59 2018 New Revision: 267296 URL: https://gcc.gnu.org/viewcvs?rev=267296&root=gcc&view=rev Log: 2018-12-20 Richard Biener PR tree-optimization/84362 * tree-ssa-loop-im.c: Include alias.h, builtins.h and tree-dfa.h. (struct im_mem_ref): add ref_canonical flag. (struct mem_ref_hasher): Use ao_ref as compare_type. (mem_ref_hasher::equal): Adjust and add variant comparing ao_ref parts. (mem_ref_alloc): Take ao_ref parameter, initialize ref_canonical member. (gather_mem_refs_stmt): Set up ao_ref early and do the lookup using it. If we have non-equal refs canonicalize the one in the hashtable used for insertion. (tree_ssa_lim_initialize): Adjust. * g++.dg/vect/pr84362.cc: New testcase. Added: trunk/gcc/testsuite/g++.dg/vect/pr84362.cc Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-im.c
[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87504 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from David Malcolm --- > (In reply to Rainer Orth from comment #4) >> The patch broke Solaris/SPARC bootstrap: > > Sorry about that. Does the patch posted here: > https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01433.html > help? It does indeed. However, I didn't do a full bootstrap, but just reverted my workaround involving #pragma GCC diagnostic ignored "-Wtautological-compare", applied your patch and reran make && make check. The build completed with no changes in testsuite results except for the new testcase. Thanks. Rainer
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 --- Comment #19 from Arseny Solokha --- Patch from comment 17 fixes the second ICE (the one filed in comment 5).
[Bug c++/88557] Lambda in template parameter list compiler segmentation fault (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88557 --- Comment #1 from Vittorio Romeo --- The "ice-on-invalid-code" tag was added, but I thought this was valid C++2a code. Am I mistaken?
[Bug c++/88562] New: Incorrect pointer incrementing on ST-SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562
Bug ID: 88562
Summary: Incorrect pointer incrementing on ST-SH4
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zavadovsky.yan at gmail dot com
Target Milestone: ---
Created attachment 45268
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45268&action=edit
code to trigger the bug
Hello.
I have got some piece of source code which incorrectly works after optimized
compilation for ST-SH4 architecture.
But it works good with some other CPUs - checked on x86-64, armv8 and mips.
And works good with some optimizations off.
Details:
Here is the minimal piece of code to trigger this bug:
unsigned Read32(const unsigned char* ptr);
const unsigned char* ReadQm(const unsigned char* ptr, const unsigned char* end)
{
const unsigned char* ret = 0;
while(ptr < end)
{
unsigned char tag = *ptr++;
unsigned len = Read32(ptr);
ptr += 4;
if (!tag || !len)
break;
if (ptr + len > end)
break;
ret = ptr;
ptr += len;
}
return ret;
}
The error is in 'ptr += 4;' statement.
It is compiled like 'ptr += 5;'.
This leads to non-working assembler opcodes.
But some changes to this code will prevent this error.
I've checked these variants:
- replace 'return ret;' with 'return ptr;'
- add line 'AnyFuncWhichTakesPointerAsArgument(ptr);' before 'return ret;'
- compile without some optimizations
How to compile and get the bug: 'sh4-unknown-linux-gnu-g++ -Os -S -c
ReadQm.cpp'
Assembler output with some comments:
// r4 == ptr
cmp/hs r11,r4
bt/s.L8
mov r10,r0
mov r4,r8 // r8 = ptr
mov.b @r8+,r9 // r9 = tag, r8 = (ptr + 1)
mov r8,r4
jsr @r12 // call Read32(ptr + 1)
add #5,r8 // r8 = ((ptr + 1) + 5) HERE IS ERROR, must be '+=4'
How to compile and DON'T get the bug: 'sh4-unknown-linux-gnu-g++ -Os
-fno-expensive-optimizations -S -c ReadQm.cpp'
Assembler output with some comments:
// r8 == ptr
mov r8,r4 // r4 = ptr
jsr @r12 // call Read32(ptr + 1), note: this line is executed after
next because of SH4's 'delayed slot' stuff
mov.b @r4+,r9 // r9 = tag, r4 = (ptr + 1)
tst r9,r9
mov r8,r1 // r1 = ptr
bt/s.L5
add #5,r1 // r1 = ((ptr + 1) + 4) ALL GOOD HERE
GCC info:
yan@ws-zavadovskiy:~/000_sh4_qmreader$ ./820/bin/sh4-unknown-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=./820/bin/sh4-unknown-linux-gnu-g++
COLLECT_LTO_WRAPPER=/yan/000_sh4_qmreader/820/bin/../libexec/gcc/sh4-unknown-linux-gnu/8.2.0/lto-wrapper
Target: sh4-unknown-linux-gnu
Configured with:
/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=sh4-unknown-linux-gnu
--prefix=/yan/000_sh4_gcc/ct-ng/../sh4-unknown-linux-gnu
--with-sysroot=/yan/000_sh4_gcc/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sysroot
--enable-languages=c,c++ --with-pkgversion='crosstool-NG 1.23.0.580-eb72b4e'
--enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp
--disable-libquadmath --disable-libquadmath-support --disable-libsanitizer
--disable-libmpx
--with-gmp=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools
--with-mpfr=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools
--with-mpc=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools
--with-isl=/yan/000_sh4_gcc/ct-ng/.build/sh4-unknown-linux-gnu/buildtools
--disable-lto --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++ -lm'
--enable-threads=posix --enable-target-optspace --disable-plugin --disable-nls
--enable-multiarch
--with-local-prefix=/yan/000_sh4_gcc/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sysroot
--enable-long-long
Thread model: posix
gcc version 8.2.0 (crosstool-NG 1.23.0.580-eb72b4e)
I've additionally checked some GCC versions:
GCC 4.6 and 4.7 on st-sh4, x86-64, armv7, mips - no bug
GCC 4.9.4 on st-sh4 - no bug
GCC 5.4.0 on st-sh4 - has bug
GCC 6.3.0 on armv8, mips - no bug
GCC 6.3.0 on st-sh4 - has bug
GCC 6.5.0 on st-sh4 - has bug
GCC 7.4.0 on st-sh4 - has bug
[Bug c++/88562] Incorrect pointer incrementing on ST-SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562 --- Comment #1 from Zavadovsky Yan --- Created attachment 45269 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45269&action=edit ReadQm_Os.s Add full assembler output with buggy code. Command to compile: 'sh4-unknown-linux-gnu-g++ -Os -S -c ReadQm.cpp'
[Bug c++/88562] Incorrect pointer incrementing on ST-SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562 --- Comment #2 from Zavadovsky Yan --- Created attachment 45270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45270&action=edit ReadQm_Os_no_expensive_optimizations.s Add full assembler output with NON-buggy code. Command to compile: 'sh4-unknown-linux-gnu-g++ -Os -fno-expensive-optimizations -S -c ReadQm.cpp'
[Bug c++/88562] Incorrect pointer incrementing on ST-SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562 --- Comment #3 from Zavadovsky Yan --- Created attachment 45271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45271&action=edit main.cpp Add some testing code. Command to compile: './820/bin/sh4-unknown-linux-gnu-g++ --sysroot=./820/sh4-unknown-linux-gnu/sysroot -static -Os -o /export/st-sh4/rootfs/test820 ReadQm.cpp main.cpp' It will produce executable which will assert. Another command to compile: './820/bin/sh4-unknown-linux-gnu-g++ --sysroot=./820/sh4-unknown-linux-gnu/sysroot -static -Os -fno-expensive-optimizations -o /export/st-sh4/rootfs/test820 ReadQm.cpp main.cpp' It will produce executable which won't assert.
[Bug c++/88562] Incorrect pointer incrementing on ST-SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88562 --- Comment #4 from Zavadovsky Yan --- Some additional note. Test code is placed in separate file from 'Read32' function implementation because inlining of 'Read32' will avoid bug. Full source file on which bug was observed has about 300 lines of code. And 'Read32' wasn't inlined while compilation. But after stripping non-releated code compiler inlined remaining code. And bug was disappeared.
[Bug c++/88554] [9 Regression] Segfault ICE when falling off the end of a reference-returning friend operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88554
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Same ICE with:
struct S {};
S & operator += (S &, S &) { }
Jonathan, are you going to add testcases and post this patch? It LGTM.
[Bug tree-optimization/88563] New: [7/8/9 Regression] wrong code with -O2 -fno-code-hoisting -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-forwprop -fno-tree-fre -fno-tree-pre -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88563 Bug ID: 88563 Summary: [7/8/9 Regression] wrong code with -O2 -fno-code-hoisting -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-forwprop -fno-tree-fre -fno-tree-pre -fno-tree-vrp Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 45272 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45272&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O2 -fno-code-hoisting -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-forwprop -fno-tree-fre -fno-tree-pre -fno-tree-vrp testcase.c $ ./a.out Aborted Value of 'a' is 0xfffb (-5) instead of 0x4fffb (5 * 0x). $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-267263-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-267263-checking-yes-rtl-df-extra-amd64 Thread model: posix gcc version 9.0.0 20181219 (experimental) (GCC)
[Bug target/85640] [8/9 Regression] Code size regression vs 7.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85640 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #4 from Richard Biener --- Looking at trunk we have # RANGE [1, 5552] NONZERO 8191 # iftmp.2_14 = PHI <5552(6), len_29(5)> # prephitmp_53 = PHI <_52(6), 0(5)> _36 = (sizetype) iftmp.2_14; _37 = buf_11 + _36; [local count: 1073741824]: # buf_12 = PHI ... [local count: 118111601]: # _17 = PHI <_6(8)> # _59 = PHI <_8(8)> _46 = iftmp.2_14 + 4294967295; _45 = (sizetype) _46; _44 = _45 + 1; buf_47 = buf_11 + _44; where the final-value replacement failed to elide the +-1 dance because sizetype _45; unsigned int _46; IVOPTs is using tree-affine which performs some extra tricks such as using range-info to prove it can elide the casts. I think if we teach the same to SCEV we'd get it optimized again. I'm talking about /* If inner type has wrapping overflow behavior, fold conversion for below case: (T1)(X - CST) -> (T1)X - (T1)CST if X - CST doesn't overflow by range information. Also handle (T1)(X + CST) as (T1)(X - (-CST)). */ if (TYPE_UNSIGNED (itype) ... Note that the plan is to remove the unconditional final-value replacement and integrate it into passes that would benefit - first of all DCE which can trigger it if the IV (or the whole loop) can be eliminated.
[Bug sanitizer/85663] [8/9 Regression] gcc-8.0.1 regression: sanitizer fails to build on mips-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663 Richard Biener changed: What|Removed |Added Keywords||build Priority|P3 |P2
[Bug middle-end/85956] [8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85956 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/86019] [8/9 Regression] Unref implementation using atomic_thread_fence generates worse code on x86-64 in gcc 8.1 than 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86019 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/86020] [8/9 Regression] Performance regression in Eigen geometry.cpp test starting with r248334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86020 --- Comment #3 from Richard Biener --- Honza?
[Bug c++/86205] [9 Regression] ICE on valid C++11 code: in type_dependent_expression_p, at cp/pt.c:25193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86205 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/86212] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86212 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/86214] [8/9 Regression] Strongly increased stack usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86214
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC||matz at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #10 from Richard Biener ---
The issue with Alex testcase is that inlining when faced with
ff ()
{
charD.10 cD.2379[1000];
:
f (&cD.2379);
:
cD.2379 ={v} {CLOBBER};
return;
:
:
cD.2379 ={v} {CLOBBER};
resx 1
}
ends up unifying the resx 1 parts, making the lifetime of the two instances
overlap:
g (intD.9 nD.2380)
{
charD.10 cD.2411[1000];
charD.10 cD.2410[1000];
...
:
f (&cD.2410);
:
cD.2410 ={v} {CLOBBER};
f (&cD.2411);
:
cD.2411 ={v} {CLOBBER};
... all fine up to here
:
:
sD.2383 ={v} {CLOBBER};
cD.2399 ={v} {CLOBBER};
resx 1
oops. When analyzing lifetime of variables during RTL expansion we might
want to not consider blocks where only the clobbers mention the vars thus
virtually move those up as far as possible.
[Bug c++/86218] [9 Regression] ICE in compare_ics, at cp/call.c:9769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86218 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Depends on||78244 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244 [Bug 78244] Narrowing conversion is accepted in a function template, but it should be rejected
[Bug c++/86379] [8/9 Regression] Class member access of |using|'d field goes horribly awry in presence of templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86379 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/86521] [8/9 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/86524] [8/9 Regression] std::less with pointer arguments not usable in static_assert in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86524 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/86567] [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86567 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/86648] [9 Regression] ICE on class template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86648 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1
[Bug rtl-optimization/86685] [8/9 Regression] 436.cactusADM regression on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86685 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/86688] missing -Wstringop-overflow using a non-string local array in strnlen with excessive bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86688 Richard Biener changed: What|Removed |Added Target Milestone|9.0 |--- Summary|[9 Regression] missing |missing -Wstringop-overflow |-Wstringop-overflow using a |using a non-string local |non-string local array in |array in strnlen with |strnlen with excessive |excessive bound |bound | --- Comment #1 from Richard Biener --- Doesn't work with GCC 8 so not a regression. GCC 8 doesn't even know strnlen.
[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87504 Sam Tebbs changed: What|Removed |Added CC||samtebbs at gcc dot gnu.org --- Comment #7 from Sam Tebbs --- (In reply to David Malcolm from comment #5) > (In reply to Rainer Orth from comment #4) > > The patch broke Solaris/SPARC bootstrap: > > Sorry about that. Does the patch posted here: > https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01433.html > help? This patch also fixes the bootstrap on aarch64
[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86736 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/86827] [8/9 Regression] -Warray-bounds produces negative indicies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86827 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/86865] [9 Regression] Wrong code w/ -O2 -floop-parallelize-all -fstack-reuse=none -fwrapv -fno-tree-ch -fno-tree-dce -fno-tree-dominator-opts -fno-tree-loop-ivcanon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86865 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/86891] [9 Regression] wrong code with -O -frerun-cse-after-loop -fno-tree-dominator-opts -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/86932] [8/9 Regression] Empty non-type template parameter pack not considered for SFINAE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86932 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/86943] [7/8/9 Regression] Wrong code when converting stateless generic lambda to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/87007] [8/9 Regression] 10% slowdown with -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/88009] [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009 --- Comment #3 from janus at gcc dot gnu.org --- In fact, after getting rid of a few ICEs, the test case also shows a new (bogus) error with trunk: Error: PRIVATE attribute not allowed in BLOCK DATA program unit at (1) This is certainly bogus, because the code contains no PRIVATE attribute at all. The error seems to concern the _final procedures, which are part of the generated vtable. Will try to get rid of this as well.
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r260385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 Wilco changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-20 CC||wilco at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Wilco --- Eg. before test_load_store_1: ldrhr3, [r2, r1, lsl #1]@ __fp16 strhr3, [r0, r1, lsl #1]@ __fp16 bx lr after: test_load_store_1: vmov.f16s0, r3 @ __fp16 ldrhr3, [r2, r1, lsl #1]@ __fp16 strhr3, [r0, r1, lsl #1]@ __fp16 bx lr Inserting spurious extra moves certainly doesn't look correct.
[Bug inline-asm/88559] error: Stack Pointer register clobbered by '%rsp' in 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88559 --- Comment #3 from James Almer --- This code has compiled and the resulting assembly worked without issues for like a dozen major GCC releases, and now it's suddenly invalid?
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r260385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #3 from Florian Weimer --- Is the revision number (r260385) really correct?
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 --- Comment #4 from Sam Tebbs --- (In reply to Florian Weimer from comment #3) > Is the revision number (r260385) really correct? Sorry it was r266385, fixed that now.
[Bug c/88544] ICE on ARM Cortex A7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88544 --- Comment #4 from Richard Earnshaw --- One of these traces says 'illegal instruction' the other 'segmentation fault'; so *if* they are compiler bugs, then they are not the same. However, this smells more like a system problem than a compiler problem. Things to check: - you aren't running out of memory (check the system logs). - your memory is working correctly - run a memory tester. Compilers are almost always deterministic, so I'd be very surprised if failures are random in the way you are suggesting.
[Bug target/43944] libgcc2 fails to build in gcc 4.5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Richard Earnshaw --- No testcase submitted in 8 years
[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #5 from Richard Biener ---
So on trunk ESRA does some pointless stuff at least:
:
ISRA.2 = MEM[(const struct A &)&x];
+ SR.7_4 = MEM[(struct A *)&ISRA.2];
+ SR.8_5 = MEM[(struct A *)&ISRA.2 + 8B];
+ MEM[(struct A *)&ISRA.2] = SR.7_4;
+ MEM[(struct A *)&ISRA.2 + 8B] = SR.8_5;
MEM[(struct A *)&y] = ISRA.2;
- ISRA.2 ={v} {CLOBBER};
+ y$D2304$a_17 = MEM[(struct A *)&y];
ISRA.2 = MEM[(const struct A &)&x];
+ SR.5_20 = MEM[(struct A *)&ISRA.2];
+ SR.6_21 = MEM[(struct A *)&ISRA.2 + 8B];
+ MEM[(struct A *)&ISRA.2] = SR.5_20;
+ MEM[(struct A *)&ISRA.2 + 8B] = SR.6_21;
MEM[(struct A *)&z] = ISRA.2;
- ISRA.2 ={v} {CLOBBER};
- _1 = y.D.2304.a;
- _2 = z.D.2304.a;
+ z$D2304$a_24 = MEM[(struct A *)&z];
+ _1 = y$D2304$a_17;
+ _2 = z$D2304$a_24;
_6 = _1 - _2;
where the main grief is caused by IPA SRA which replaces
cp (&y.D.2304, &x.D.2304);
cp (&z.D.2304, &x.D.2304);
_1 = y.D.2304.a;
_2 = z.D.2304.a;
_6 = _1 - _2;
with
_Z2cpI1AEvRT_RKS1_.isra.0 (&y, MEM[(const struct A &)&x]);
_Z2cpI1AEvRT_RKS1_.isra.0 (&z, MEM[(const struct A &)&x]);
_1 = y.D.2304.a;
_2 = z.D.2304.a;
_6 = _1 - _2;
replacing the by-reference second argument by an aggregate by-value
argument.
I think that's unwarranted - Martin, can you see if there's a simple logic
error that can rectify this? The same behavior is happening when
the second parameter is not declared const.
With IPA SRA disabled the IL gets nicer but then ESRA doesnt' do anything
interesting anymore (but renaming stuff and uglifying/moving loads):
MEM[(struct A *)&y] = MEM[(const struct A &)&x];
+ y$D2304$a_4 = MEM[(struct A *)&y];
MEM[(struct A *)&z] = MEM[(const struct A &)&x];
- _1 = y.D.2304.a;
- _2 = z.D.2304.a;
+ z$D2304$a_5 = MEM[(struct A *)&z];
+ _1 = y$D2304$a_4;
+ _2 = z$D2304$a_5;
_6 = _1 - _2;
also sth to avoid IMHO. I guess it thinks it might fully scalarize
the copies but late decides not to but leaves the rest of the trasform
in-place.
So yes, the copy is viewed as contains_vce_or_bfcref_p because
we access a variable of type B via type A. But that only matters
for variables we can scalarize away - we call this for MEM[&x]
only but we want to scalarize MEM[&y] = MEM[&x] thus scalarize y
away. That we mark x as cannot_scalarize_away_bitmap shouldn't
affect total scalarization for the aggregate copy?
I wonder why build_accesses_from_assign only looks at the RHS for
total scalarization and not the LHS.
Well to sum it up, we see all uses of y and z and thus we _can_
total scalarize y and z simply eliding the aggregate copy.
[Bug target/41482] ICE in libgfortran arm thumb multilib compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41482 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Richard Earnshaw --- gcc 4.4.2 is well out of maintenance now. I've never been able to reproduce anything similar during testing.
[Bug lto/85574] [9 Regression] LTO bootstapped binaries differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574 Richard Biener changed: What|Removed |Added Last reconfirmed|2018-05-01 00:00:00 |2018-12-20 --- Comment #7 from Richard Biener --- Re-confirmed on trunk. prev-gcc/cc1 vs gcc/cc1 has - 57add1: e8 de e3 17 00 callq 6f91b4 <_ZL12bmp_iter_setP15bitmap_iteratorPj.part.0.lto_priv.0> + 57add1: e8 e0 e3 17 00 callq 6f91b6 <_ZL12bmp_iter_setP15bitmap_iteratorPj.part.0.lto_priv.0> ... @@ -22292,50 +22292,50 @@ 590038: be fc 03 00 00 mov$0x3fc,%esi 59003d: bf 60 35 74 01 mov$0x1743560,%edi 590042: e8 8f e9 fe ff callq 57e9d6 <_Z11fancy_abortPKciS0_> - 590047: ba cc 2d c7 01 mov$0x1c72dcc,%edx - 59004c: be 1a 05 00 00 mov$0x51a,%esi - 590051: bf 60 35 74 01 mov$0x1743560,%edi - 590056: e8 7b e9 fe ff callq 57e9d6 <_Z11fancy_abortPKciS0_> - 59005b: 45 31 c9xor%r9d,%r9d ... + 590047: 41 b8 c5 28 74 01 mov$0x17428c5,%r8d + 59004d: b9 73 01 00 00 mov$0x173,%ecx + 590052: ba 28 be 5b 01 mov$0x15bbe28,%edx + 590057: 4c 89 efmov%r13,%rdi + 59005a: be 0f 00 00 00 mov$0xf,%esi + 59005f: e8 bf 46 07 00 callq 604723 <_Z33tree_contains_struct_ check_failedPK9tree_node24tree_node_structure_enumPKciS4_> which looks like different inlining decisions happening?! I'd have to re-run with IPA dumps but there's definitely sth suspicious happening. I'll see if I can reproduce the same builds at least (so two times prev-gcc/cc1 are equal).
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #11 from Richard Earnshaw --- -mno-lra was dropped in gcc-5, so the old register allocator is no-longer supported in any maintained version of gcc. Closing
[Bug rtl-optimization/88563] [7/8/9 Regression] wrong code with -O2 -fno-code-hoisting -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-forwprop -fno-tree-fre -fno-tree-pre -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88563 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-20 Component|tree-optimization |rtl-optimization Target Milestone|--- |7.5 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Looks like middle-end or RTL: __int128 unsigned a.0_1; long long unsigned int _2; __int128 unsigned _13; ... a_10 = 5; a.0_1 = a_10; _2 = (long long unsigned int) a.0_1; _13 = _2 w* 18446744073709551615; _7 = COMPLEX_EXPR <_13, 0>; _3 = REALPART_EXPR <_7>;
[Bug rtl-optimization/88563] [7/8/9 Regression] wrong code with -O2 -fno-code-hoisting -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-forwprop -fno-tree-fre -fno-tree-pre -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88563 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug lto/45727] ICE: in subreg_get_info, at rtlanal.c:3092
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45727 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Richard Earnshaw --- This has gone stale and gcc-4.6 is no-longer maintained. If the problem persists in a currently maintained version of gcc, please create a new bug report with full details of how to reproduce the issue.
[Bug inline-asm/88559] error: Stack Pointer register clobbered by '%rsp' in 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88559 --- Comment #4 from James Almer --- To expand, as i mentioned and showed in the OP this code has compiled without issues up to some point between December 10 and December 17 with gcc trunk. I'm not arguing about clobbering the stack pointer being correct or not, I'm wondering if this a valid error for the code in question and not a bogus one product of a regression in gcc. Does the inline asm in the attached preprocessed output effectively try to clobber the stack pointer? And if so, why would it start erroring out now only after a recent gcc trunk commit if it was never meant to work? Has gcc been generating invalid assembly all this time?
[Bug other/54398] Incorrect ARM assembly when building with -fno-omit-frame-pointer -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Earnshaw --- I don't know precisely when this was fixed, but the testcase produces correct output on (at least) gcc-7 and later. So presume fixed.
[Bug lto/56115] Internal compiler error / unable to generate a relocatable output with object file(which is with lto info).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56115 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Richard Earnshaw --- No feedback forthcoming
[Bug bootstrap/56116] failed to build ARM native compiler by ARM cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56116 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Richard Earnshaw --- This bug report is very old and has gone stale. If the problem persists with a currently maintained version of gcc, please file a new bug report with full details of how to reproduce the problem.
[Bug target/57911] alignment of arrays allocated stack on ARM : 4 bytes ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57911 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Earnshaw --- No testcase forthcoming
[Bug target/58490] __sync_bool_compare_and_swap sign bit failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58490 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Richard Earnshaw --- No progress in 5 years and gcc-4.7 is no-longer maintained. If the problem persists in a currently maintained version of gcc, please can you open a new bug report with full details of the issue and how to reproduce.
[Bug target/65325] float/interger operation needs cast with 02 switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65325 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #11 from Richard Earnshaw --- No testcase supplied
[Bug other/54398] Incorrect ARM assembly when building with -fno-omit-frame-pointer -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398 --- Comment #10 from Jakub Jelinek --- Guess it would be nice to add the testcase into the testsuite in that case.
[Bug sanitizer/68100] runtime segfault ARM boost::regex_replace -fsanitize=undefined member access within misaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68100 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Earnshaw --- No testcase supplied
[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214 --- Comment #10 from Martin Jambor --- Author: jamborm Date: Thu Dec 20 14:14:22 2018 New Revision: 267298 URL: https://gcc.gnu.org/viewcvs?rev=267298&root=gcc&view=rev Log: [PR 88214] Assert that ptr is a pointer 2018-12-20 Martin Jambor PR ipa/88214 * tree-ssa-alias.c (ao_ref_init_from_ptr_and_size): Assert that ptr is a pointer. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug target/68494] [ARM] Use vector multiply by lane
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68494 Richard Earnshaw changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Richard Earnshaw --- Still looks like we are using vdup for the testcase.
[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87504 --- Comment #8 from David Malcolm --- Author: dmalcolm Date: Thu Dec 20 14:18:48 2018 New Revision: 267299 URL: https://gcc.gnu.org/viewcvs?rev=267299&root=gcc&view=rev Log: -Wtautological-compare: fix comparison of macro expansions gcc/c-family/ChangeLog: PR c++/87504 * c-warn.c (get_outermost_macro_expansion): New function. (spelled_the_same_p): Use it to unwind the macro expansions, and compare the outermost macro in each nested expansion, rather than the innermost. gcc/testsuite/ChangeLog: PR c++/87504 * c-c++-common/Wtautological-compare-8.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wtautological-compare-8.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-warn.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/70030] [LRA]ICE when reload insn with output scratch operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70030 --- Comment #9 from Richard Earnshaw --- Did the need for this patch go away?
[Bug rtl-optimization/70223] [ARM] Optimization level -O2 results in wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70223 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Earnshaw --- No feedback in 2 years. Changes have been made in the past to address issues like this, so presuming fixed.
[Bug c++/77662] arm-linux-gnueabihf-g++: internal compiler error: Killed (program cgcc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77662 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Earnshaw --- No feedback in 2 years. Presumed invalid
[Bug middle-end/77996] Miscompilation due to LTO on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #13 from Richard Earnshaw --- No further feedback in 2 years. Presumed invalid aliasing of data types in LLVM
