[Bug c++/85031] New: internal compiler error: Segmentation fault (field_accessor_p()/dfs_locate_field_accessor_pre())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85031
Bug ID: 85031
Summary: internal compiler error: Segmentation fault
(field_accessor_p()/dfs_locate_field_accessor_pre())
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at oracle dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
Input:
struct {
private:
int a;
void b() { return; }
} *a(a->a);
Output:
$ cc1plus
void::b()
: At global scope:
:5:9: error: 'int ::a' is private within this context
:3:7: note: declared private here
:5:9: internal compiler error: Segmentation fault
0x3152ce9 crash_signal
/home/vegard/git/gcc/gcc/toplev.c:325
0x121f448 field_accessor_p
/home/vegard/git/gcc/gcc/cp/search.c:1764
0x121f448 dfs_locate_field_accessor_pre
/home/vegard/git/gcc/gcc/cp/search.c:1819
0x1247ebc dfs_walk_once_accessible_r
/home/vegard/git/gcc/gcc/cp/search.c:1536
0x1247ebc dfs_walk_once_accessible
/home/vegard/git/gcc/gcc/cp/search.c:1603
0x1247ebc locate_field_accessor(tree_node*, tree_node*, bool)
/home/vegard/git/gcc/gcc/cp/search.c:1839
0x1413c73 access_failure_info::maybe_suggest_accessor(bool) const
/home/vegard/git/gcc/gcc/cp/typeck.c:2727
0x1415702 finish_class_member_access_expr(cp_expr, tree_node*, bool, int)
/home/vegard/git/gcc/gcc/cp/typeck.c:2930
0xf4a842 cp_parser_postfix_dot_deref_expression
/home/vegard/git/gcc/gcc/cp/parser.c:7632
0xf75672 cp_parser_postfix_expression
/home/vegard/git/gcc/gcc/cp/parser.c:7276
0xf2a4b7 cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8322
0xebfeca cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9090
0xec24f6 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9191
0xec62ca cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9486
0xecc0a3 cp_parser_constant_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9770
0xed376b cp_parser_parenthesized_expression_list
/home/vegard/git/gcc/gcc/cp/parser.c:7758
0xedc2bc cp_parser_initializer
/home/vegard/git/gcc/gcc/cp/parser.c:21864
0xfa0f3d cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19677
0xfa57a7 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13065
0xfab998 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12883
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug sanitizer/85029] [8 Regression] -fsanitize=undefined internal compiler error: in maybe_optimize_ubsan_ptr_ifn, at sanopt.c:493
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85029 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-03-22 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |8.0 Summary|-fsanitize=undefined|[8 Regression] |internal compiler error: in |-fsanitize=undefined |maybe_optimize_ubsan_ptr_if |internal compiler error: in |n, at sanopt.c:493 |maybe_optimize_ubsan_ptr_if ||n, at sanopt.c:493 Ever confirmed|0 |1
[Bug sanitizer/85029] [8 Regression] -fsanitize=undefined internal compiler error: in maybe_optimize_ubsan_ptr_ifn, at sanopt.c:493
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85029 --- Comment #1 from Jakub Jelinek --- Created attachment 43730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43730&action=edit gcc8-pr85029.patch Untested fix.
[Bug fortran/77941] ICE in expand_expr_addr_expr_1, at expr.c:7805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77941 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist --- It works on x86_64-pc-linux-gnu (including running it), but the ICE remains on i686-pc-linux-gnu.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #12 from joseph at codesourcery dot com dot com> --- > On Wed, 21 Mar 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > >> Joseph, any suggestions? You mentioned that older versions of glibc >> didn't provide 16-byte alignment in i386 malloc; maybe there are other >> systems with the same issue that could equally benefit from some fix? > > The fix in glibc was to increase malloc alignment for i386. This is an > area where properly supporting a feature (_Float128 and _Decimal128, both > of which are 16-byte aligned on i386) requires cooperation between the > compiler and library - in this case, even without other library support > for those types, users can still legitimately expect memory from malloc to > be suitably aligned for them, and for max_align_t to have suitable > alignment for them. I see. So I'll go ahead and xfail the current testcase (unless Jonathan prefers to move the failing max_align_t part to a separate testcase) and pursue increasing i386 malloc alignment and the __float128 addition to max_align_t (for non-Studio compilers only, I guess) in Solaris. Thanks. Rainer
[Bug c++/84854] [7/8 Regression] ICE: unexpected expression in cxx_eval_constant_expression, at cp/constexpr.c:4774
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84854 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Thu Mar 22 08:08:07 2018 New Revision: 258756 URL: https://gcc.gnu.org/viewcvs?rev=258756&root=gcc&view=rev Log: PR c++/84854 * semantics.c (finish_if_stmt_cond): Check if the type of the condition is boolean. * g++.dg/cpp1z/constexpr-if15.C: New test. * g++.dg/cpp1z/constexpr-if16.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if15.C trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84854] [7 Regression] ICE: unexpected expression in cxx_eval_constant_expression, at cp/constexpr.c:4774
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84854 Marek Polacek changed: What|Removed |Added Summary|[7/8 Regression] ICE: |[7 Regression] ICE: |unexpected expression in|unexpected expression in |cxx_eval_constant_expressio |cxx_eval_constant_expressio |n, at cp/constexpr.c:4774 |n, at cp/constexpr.c:4774 --- Comment #4 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/84961] [7 Regression] ICE error: SSA_NAME_DEF_STMT is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84961 --- Comment #8 from rguenther at suse dot de --- On Wed, 21 Mar 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84961 > > Jakub Jelinek changed: > >What|Removed |Added > > Summary|[7/8 Regression] ICE error: |[7 Regression] ICE error: >|SSA_NAME_DEF_STMT is wrong |SSA_NAME_DEF_STMT is wrong > > --- Comment #7 from Jakub Jelinek --- > Fixed on the trunk so far. Thanks Jakub!
[Bug c++/85027] [6/7/8 Regression] ICE on invalid C++ code: in instantiate_type, at cp/class.c:8062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85027 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-22 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.5 Summary|ICE on invalid C++ code: in |[6/7/8 Regression] ICE on |instantiate_type, at|invalid C++ code: in |cp/class.c:8062 |instantiate_type, at ||cp/class.c:8062 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r154403.
[Bug c++/85027] [6/7/8 Regression] ICE on invalid C++ code: in instantiate_type, at cp/class.c:8062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85027 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Version|unknown |8.0.1
[Bug c++/85028] [8 Regression] ICE on invalid C++ code: in tsubst_default_argument, at cp/pt.c:12340
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85028 Marek Polacek changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-22 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |8.0 Summary|ICE on invalid C++ code: in |[8 Regression] ICE on |tsubst_default_argument, at |invalid C++ code: in |cp/pt.c:12340 |tsubst_default_argument, at ||cp/pt.c:12340 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- r251422
[Bug target/85026] [7 Regression] Error: branch out of range on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85026 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |7.4
[Bug c++/85031] internal compiler error: Segmentation fault (field_accessor_p()/dfs_locate_field_accessor_pre())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85031 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- Seems to be fixed already. I guess one of recent Nathan's patches.
[Bug c++/85028] [8 Regression] ICE on invalid C++ code: in tsubst_default_argument, at cp/pt.c:12340
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85028 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Version|unknown |8.0.1
[Bug sanitizer/85018] [8 Regression] Many sanitizer tests ICE since r258681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85018 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Mar 22 08:32:12 2018 New Revision: 258757 URL: https://gcc.gnu.org/viewcvs?rev=258757&root=gcc&view=rev Log: PR sanitizer/85018 * dwarf2asm.c (dw2_output_indirect_constant_1): Set DECL_INITIAL (decl) to decl at the end. * varasm.c (use_blocks_for_decl_p): Revert the 2018-03-20 change, adjust the comment. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2asm.c trunk/gcc/varasm.c
[Bug c++/85032] New: Wrong non-constant condition for static assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85032
Bug ID: 85032
Summary: Wrong non-constant condition for static assertion
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
We should accept this one
struct A
{
constexpr operator bool () { return true; }
int i;
};
A a;
template void f()
{
constexpr bool b = a;
static_assert (a);
}
int main()
{
f();
}
instead, we reject it with
constexpr-if17.C: In function ‘void f()’:
constexpr-if17.C:12:18: error: non-constant condition for static assertion
static_assert (a);
^
constexpr-if17.C:12:18: error: the value of ‘a’ is not usable in a constant
expression
constexpr-if17.C:7:3: note: ‘a’ was not declared ‘constexpr’
A a;
^
[Bug c++/85032] Wrong non-constant condition for static assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85032 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-03-22 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug sanitizer/85018] [8 Regression] Many sanitizer tests ICE since r258681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85018 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #14 from Jonathan Wakely --- We *could* make the libstdc++ operator new call malloc repeatedly until it gets something aligned to max_align_t, so that operator new and the C++ allocators meet the alignment requirements. But that seems quite horrible.
[Bug c++/85033] New: internal compiler error: in fold_offsetof_1, at c-family/c-common.c:6269
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85033
Bug ID: 85033
Summary: internal compiler error: in fold_offsetof_1, at
c-family/c-common.c:6269
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at oracle dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
Input:
int b = __builtin_offsetof(struct { enum { a }; }, a)
Output:
$ cc1plus
:1:53: internal compiler error: in fold_offsetof_1, at
c-family/c-common.c:6269
0x1502073 fold_offsetof_1(tree_node*, tree_code)
/home/vegard/git/gcc/gcc/c-family/c-common.c:6269
0x1504a82 fold_offsetof(tree_node*)
/home/vegard/git/gcc/gcc/c-family/c-common.c:6280
0xf38c24 cp_parser_builtin_offsetof
/home/vegard/git/gcc/gcc/cp/parser.c:9897
0xf38c24 cp_parser_primary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:5396
0xf7698b cp_parser_postfix_expression
/home/vegard/git/gcc/gcc/cp/parser.c:7030
0xf2a4b7 cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8322
0xebfeca cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9090
0xec24f6 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9191
0xec62ca cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9486
0xecc0a3 cp_parser_constant_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9770
0xed334e cp_parser_initializer_clause
/home/vegard/git/gcc/gcc/cp/parser.c:21916
0xedc293 cp_parser_initializer
/home/vegard/git/gcc/gcc/cp/parser.c:21856
0xfa0f3d cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19677
0xfa57a7 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13065
0xfab998 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12883
0xffead5 cp_parser_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12780
0xff5b8b cp_parser_declaration_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:12656
0xff71b3 cp_parser_translation_unit
/home/vegard/git/gcc/gcc/cp/parser.c:4561
0xff71b3 c_parse_file()
/home/vegard/git/gcc/gcc/cp/parser.c:38995
0x15a3a25 c_common_parse_file()
/home/vegard/git/gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/58969] bogus error: the value of 'kName' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58969 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.2 --- Comment #4 from Jonathan Wakely --- This was fixed by r249079 on trunk and r249325 for 7.2 Fix array decay handling in constant expressions. * parser.c (cp_parser_constant_expression): Check potential_rvalue_constant_expression after decay_conversion. * pt.c (convert_nontype_argument): Don't require linkage in C++17.
[Bug c++/52036] C++11 allows template parameters to have internal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52036 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.2 --- Comment #16 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #15) > (In reply to Jonathan Wakely from comment #14) > > For this PR, the only remaining bug seems to be comment 8. > > Which works in C++17 mode, so is only a bug for C++11 and C++14. Hmm, it also works in C++11 and C++14 mode. Not sure what I was testing. And that is PR 58969, which was fixed for 7.2
[Bug c++/85032] [8 regression] Wrong non-constant condition for static assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85032 Marek Polacek changed: What|Removed |Added Target Milestone|--- |8.0 Summary|Wrong non-constant |[8 regression] Wrong |condition for static|non-constant condition for |assertion |static assertion --- Comment #1 from Marek Polacek --- This is actually a regression; started with r256550. So likely P1.
[Bug c++/85033] internal compiler error: in fold_offsetof_1, at c-family/c-common.c:6269
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85033 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-22 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug bootstrap/85020] [8 Regression] gcc fails to bootstrap with profiledbootstrap and --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85020 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Richard Biener --- (In reply to Richard Biener from comment #2) > Can reproduce. The best thing would be to place some strategic asserts in > dwarf2out.c that trigger when we output "relocations" during early dwarf out. > I'll see to that tomorrow. > > Note there are some related acats FAILs that might be easier to analyze. Respective, c330001, c390011, c731001, c854002, cc50a01 and cc50a02 FAIL with unresolved symbols at link time when you edit gcc/testsuite/ada/acats/run_all.sh to have -O2 -flto -g in gccflags. Didn't succeed in quickly finding spots to assert on in the dwarf2out or dwarf2asm assembly emission to track those issues down earlier and more reliable. Help with that appreciated. It looks like that c330001_0-c330001_1.ads produces an invalid reference here: <3><32e>: Abbrev Number: 6 (DW_TAG_array_type) <32f> DW_AT_name: (indirect string, offset: 0xb3a): c330001_0__c33 0001_1__T5s__T8s__T9s <333> DW_AT_GNAT_descriptive_type: <0x351> <337> DW_AT_type: <0x15b> <33b> DW_AT_sibling : <0x351> <4><33f>: Abbrev Number: 24 (DW_TAG_subrange_type) <340> DW_AT_type: <0x23> <344> DW_AT_upper_bound : 11 byte block: 3 0 0 0 0 0 0 0 0 94 4 (DW_OP_addr: 0; DW_OP_deref_size: 4) <4><350>: Abbrev Number: 0 resulting in 23: 0 NOTYPE GLOBAL DEFAULT UND c330001_0__c330001_1__T5s 24: 0 NOTYPE GLOBAL DEFAULT UND c330001_0__c330001_1__Tpr c330001_0-c330001_1.ads:(.debug_info+0x9c3): undefined reference to `c330001_0__c330001_1__Tprivatechild_obj_02S__T19s__TT20sP1_(unsigned)' c330001_0-c330001_1.ads:(.debug_info+0x9eb): undefined reference to `c330001_0__c330001_1__Tprivatechild_obj_02S__T19s__TT20sP1_(unsigned)' added by #0 add_dwarf_attr (die=0x763ce730, attr=0x7fffc240) at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:4361 #1 0x00f5adcb in add_AT_loc (die=0x763ce730, attr_kind=DW_AT_upper_bound, loc=0x763ce820) at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:4820 #2 0x00f84b61 in add_scalar_info (die=0x763ce730, attr=DW_AT_upper_bound, value=0x76393000, forms=7, context=0x0) at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20652 #3 0x00f84de5 in add_bound_info (subrange_die=0x763ce730, bound_attr=DW_AT_upper_bound, bound=0x76393000, context=0x0) at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20758 #4 0x00f6cf1c in subrange_type_die (type=0x7638fbd0, low=0x767c8f90, high=0x76393000, bias=0x0, context_die=0x763ce690) at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:12950 #5 0x00f6e06e in modified_type_die (type=0x7638fbd0, cv_quals=0, reverse=false, context_die=0x763ce690) at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:13316 in this case the value we want to record for the upper bound is
[Bug inline-asm/85022] [6/7/8 Regression] internal compiler error: in write_dependence_p, at alias.c:3003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85022
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-03-22
CC||jakub at gcc dot gnu.org
Target Milestone|--- |6.5
Summary|internal compiler error: in |[6/7/8 Regression] internal
|write_dependence_p, at |compiler error: in
|alias.c:3003|write_dependence_p, at
||alias.c:3003
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
Started with r200241.
ICEs both in C and C++:
extern struct B b;
void
foo ()
{
asm ("" : "+m" (b));
}
I'm surprised we accept it; works at -O0.
[Bug c++/85032] [8 regression] Wrong non-constant condition for static assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85032 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/85026] [7 Regression] Error: branch out of range on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85026 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-22 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. Looks like a bug in in the length calculation of some insns to me. Compiling with -dp shows that GCC thinks insns like ldrsh r2, [r4]@ unaligned @ 168 unaligned_loadhis/1 [length = 2] have length 2 when in fact only register offset LDRSH can have length 2. So we underestimate them and cause this error
[Bug inline-asm/85034] New: -O1 internal compiler error: in elimination_costs_in_insn, at reload1.c:3633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85034
Bug ID: 85034
Summary: -O1 internal compiler error: in
elimination_costs_in_insn, at reload1.c:3633
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at oracle dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
Input:
void b() {
volatile float a;
asm("" : "=d"(a) : "0Ir"([] {}));
}
Output:
$ cc1plus -O1
void b() b():: static void b()_FUN()
b()operator void (*)()() const
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data>
Assembling functions:
void b()during RTL pass: ira
: In function 'void b()':
:4:1: internal compiler error: in elimination_costs_in_insn, at
reload1.c:3633
0x2e67ee7 elimination_costs_in_insn
/home/vegard/git/gcc/gcc/reload1.c:3630
0x2ea41cf calculate_elim_costs_all_insns()
/home/vegard/git/gcc/gcc/reload1.c:1607
0x26cd174 ira_costs()
/home/vegard/git/gcc/gcc/ira-costs.c:2249
0x2687568 ira_build()
/home/vegard/git/gcc/gcc/ira-build.c:3427
0x2640c54 ira
/home/vegard/git/gcc/gcc/ira.c:5295
0x2640c54 execute
/home/vegard/git/gcc/gcc/ira.c:5606
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/85026] [7 Regression] Error: branch out of range on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85026 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC|kyrylo.tkachov at arm dot com | --- Comment #2 from ktkachov at gcc dot gnu.org --- I think the bug is present on trunk btw. It's just not triggered by this particular testcase
[Bug c++/84782] Rejects a maybe C++ code snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84782
--- Comment #5 from Raphael Kubo da Costa ---
Sorry if my comment was too coarse-grained. My hypothesis that this is a
duplicate comes from playback_image_provider.ii looking like Chromium's
playback_image_provider.cc, which was failing to build with GCC when a copy
constructor was not defined inline (just like the union from bug 70431).
My reduced testcase from the original Chromium code (without templates) looks
like this:
-
struct S1 {
S1& operator=(const S1&) = default;
S1& operator=(S1&&) = default;
};
struct S2 {
S2() = default;
S2(const S2&);
S1 m;
};
S2::S2(const S2&) = default;
-
x.cc:12:1: note: ‘S2::S2(const S2&)’ is implicitly deleted because the default
definition would be ill-formed:
S2::S2(const S2&) = default;
^~
x.cc:12:1: error: use of deleted function ‘constexpr S1::S1(const S1&)’
x.cc:1:8: note: ‘constexpr S1::S1(const S1&)’ is implicitly declared as deleted
because ‘S1’ declares a move constructor or move assignment operator
struct S1 {
^~
The error goes away if S2's copy constructor is declared inline.
[Bug tree-optimization/84956] [6/7/8 Regression] ICE in replace_block_by, at tree-ssa-tail-merge.c:1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84956 Tom de Vries changed: What|Removed |Added Keywords||patch --- Comment #4 from Tom de Vries --- https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01161.html
[Bug inline-asm/85022] [6/7/8 Regression] internal compiler error: in write_dependence_p, at alias.c:3003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85022 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 43731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43731&action=edit gcc8-pr85022.patch Untested fix.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 Rainer Orth changed: What|Removed |Added Status|NEW |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-03/msg01162.ht ||ml Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #15 from Rainer Orth --- Mine, patch posted.
[Bug target/85035] New: nios2: adding -fdelete-null-pointer-checks with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85035 Bug ID: 85035 Summary: nios2: adding -fdelete-null-pointer-checks with -O2 enabled Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rvdv at vandewiele dot com Target Milestone: --- Created attachment 43732 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43732&action=edit source file The code in attachment reads a 64 bit integer to compare it. When loading the first 32 bit, an instruction is used that bypasses the cache. For the last 32 bit a regular load is used. The -mno-cache-volatile option is supposed to bypass the cache for volatile variables. But as you can see, no volatile variables are used in the example. I have noticed that working code is generated when the "-fdelete-null-pointer-checks" option is removed. The O2 option should also enable "-fdelete-null-pointer-checks", so I would expect the extra "-fdelete-null-pointer-checks" to be redundant. This doesn't seem to be the case. Target: nios2-elf Configured with: ../../src/gcc-7.3.0/configure --target=nios2-elf --with-newlib --disable-threads --disable-shared --disable-multilib --disable-nls --enable-languages=c,c++ --disable-libssp --enable-lto --without-headers --prefix=/c/gcc/gcc7.3-src/nios2-elf-7.3.0 --with-isl --enable-plugins Thread model: single gcc version 7.3.0 (GCC) build commad: ./7.3.0/bin/nios2-elf-gcc -O2 -fdelete-null-pointer-checks -mno-cache-volatile -Wall -Wextra -fno-strict-aliasing -fwrapv -save-temps test.cpp -o test.elf output: c:/gcc/nios2-elf-mingw/7.3.0/bin/../lib/gcc/nios2-elf/7.3.0/../../../../nios2-elf/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 10dc
[Bug fortran/77941] ICE in expand_expr_addr_expr_1, at expr.c:7805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77941 --- Comment #6 from Dominique d'Humieres --- > It works on x86_64-pc-linux-gnu (including running it), > but the ICE remains on i686-pc-linux-gnu. Confirmed.
[Bug tree-optimization/84956] [6/7/8 Regression] ICE in replace_block_by, at tree-ssa-tail-merge.c:1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84956 --- Comment #5 from Tom de Vries --- Author: vries Date: Thu Mar 22 10:21:12 2018 New Revision: 258758 URL: https://gcc.gnu.org/viewcvs?rev=258758&root=gcc&view=rev Log: [tail-merge] Don't merge bbs with bb_has_abnormal_pred 2018-03-22 Tom de Vries PR tree-optimization/84956 * tree-ssa-tail-merge.c (find_clusters_1): Skip bbs with bb_has_abnormal_pred. * gcc.dg/pr84956.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr84956.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-tail-merge.c
[Bug target/85026] [7 Regression] Error: branch out of range on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85026 --- Comment #3 from Jakub Jelinek --- Started with r240221 and stopped with r248863. Both these changes are generic changes, so this likely used to be latent in 6.x and before and is latent again on the trunk.
[Bug target/85025] libgcc/config/i386/shadow-stack-unwind.h is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85025 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-22 Blocks||81652 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 [Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug inline-asm/85030] [6/7/8 Regression] internal compiler error: Floating point exception (validate_subreg())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85030
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-03-22
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Target Milestone|--- |6.5
Summary|internal compiler error:|[6/7/8 Regression] internal
|Floating point exception|compiler error: Floating
|(validate_subreg()) |point exception
||(validate_subreg())
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started with r192719 - the introduction of LRA.
Reload would reject it with:
pr85030.c: In function ‘foo’:
pr85030.c:7:3: error: ‘asm’ operand constraint incompatible with operand size
asm volatile ("" : "=rm" (a) : "0" (1));
^
pr85030.c:7:3: error: ‘asm’ operand has impossible constraints
Slightly adjusted testcase:
struct S { int c, *b, *e; };
void
foo ()
{
struct S a;
asm volatile ("" : "=rm" (a) : "0" (1));
}
[Bug inline-asm/85030] [6/7/8 Regression] internal compiler error: Floating point exception (validate_subreg())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85030
--- Comment #2 from Jakub Jelinek ---
void
bar (int i)
{
struct S a;
asm volatile ("" : "=rm" (a) : "0" (i));
}
ICEs as well, but
int
baz (struct S a)
{
int i;
asm volatile ("" : "=rm" (i) : "0" (a));
return i;
}
is properly rejected:
pr85030-3.c: In function ‘baz’:
pr85030-3.c:7:3: error: inconsistent operand constraints in an ‘asm’
asm volatile ("" : "=rm" (i) : "0" (a));
^~~
[Bug tree-optimization/84956] [6/7/8 Regression] ICE in replace_block_by, at tree-ssa-tail-merge.c:1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84956 --- Comment #6 from Tom de Vries --- Author: vries Date: Thu Mar 22 10:39:43 2018 New Revision: 258759 URL: https://gcc.gnu.org/viewcvs?rev=258759&root=gcc&view=rev Log: backport "[tail-merge] Don't merge bbs with bb_has_abnormal_pred" 2018-03-22 Tom de Vries backport from trunk: 2018-03-22 Tom de Vries PR tree-optimization/84956 * tree-ssa-tail-merge.c (find_clusters_1): Skip bbs with bb_has_abnormal_pred. * gcc.dg/pr84956.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr84956.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/tree-ssa-tail-merge.c
[Bug inline-asm/85030] [6/7/8 Regression] internal compiler error: Floating point exception (validate_subreg())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85030 --- Comment #3 from Jakub Jelinek --- Trying to create BLKmode subreg of something (or subreg from BLKmode) is not going to work well, but don't know the LRA code enough to know how to safely get out to the point where we can error out on it.
[Bug testsuite/80092] Add effective-target keywords for unsupported nvptx features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80092 --- Comment #12 from Tom de Vries --- Author: vries Date: Thu Mar 22 10:44:51 2018 New Revision: 258760 URL: https://gcc.gnu.org/viewcvs?rev=258760&root=gcc&view=rev Log: Backport "Require effective target global_constructor for two testcases" 2017-03-27 Tom de Vries backport from trunk: 2017-03-24 Tom de Vries PR testsuite/80092 * gcc.dg/tls/emutls-2.c: Add dg-require-effective-target global_constructor. Modified: branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- The error seems to be fixed on the trunk with PR84833 / r258596. Further optimizations has Martin scheduled for 9+.
[Bug ada/85036] New: --disable-bootstrap --enable-languages=ada[,c++] fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85036
Bug ID: 85036
Summary: --disable-bootstrap --enable-languages=ada[,c++] fails
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
This is similar to PR81878 and regressed I think with
r254940 | ebotcazou | 2017-11-19 23:36:25 +0100 (Sun, 19 Nov 2017) | 11 lines
PR ada/83016
* gnatlink.adb (Process_Args): Accept multiple switches for --LINK.
(Usage): Adjust.
* gcc-interface/Makefile.in (GCC_LINK): Remove $(ADA_INCLUDES).
(common-tools): Pass $(CC) as --GCC= and $(GCC_LINK) as --LINK= in
the invocations of $(GNATLINK).
(../../gnatdll$(exeext)): Likewise.
(../../vxaddr2line$(exeext)): Likewise.
(gnatmake-re): Likewise.
(gnatlink-re): Likewise.
symptom:
../../gnatlink -v gnatcmd -o ../../gnat \
--GCC="../../xgcc -B../../ -I- -I../rts -I.
-I/space/rguenther/src/svn/early-lto-debug/gcc/ada" --LINK="g++
-static-libstdc++ -static-libgcc -static-libstdc++ -static-libgcc " ../link.o
../targext.o ../../ggc-none.o ../../libcommon-target.a ../../libcommon.a
../../../libcpp/libcpp.a ../rts/libgnat.a
../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a
GNATLINK 8.0.1 20180321 (experimental) [trunk revision 221942]
Copyright (C) 1995-2018, Free Software Foundation, Inc.
xgcc -c -gnatA -gnatWb -gnatiw -B../../ -I- -I../rts -I.
-I/space/rguenther/src/svn/early-lto-debug/gcc/ada -gnatws
/home/abuild/rguenther/obj/gcc/ada/tools/b~gnatcmd.adb
/usr/bin/g++ b~gnatcmd.o ../link.o ../targext.o ../../ggc-none.o ../rts/ada.o
../rts/a-charac.o ../rts/a-chlat1.o ../rts/gnat.o ../rts/interfac.o
../rts/system.o ../rts/s-addope.o ../rts/s-casuti.o ../rts/s-imenne.o
../rts/s-imgint.o ../rts/s-io.o ../rts/s-parame.o ../rts/s-crtl.o
../rts/i-cstrea.o ../rts/s-stoele.o ../rts/s-stache.o ../rts/s-strhas.o
../rts/s-htable.o ../rts/g-htable.o ../rts/s-string.o ../rts/s-traent.o
../rts/s-unstyp.o ../rts/s-imguns.o ../rts/s-wchcon.o ../rts/s-wchjis.o
../rts/s-wchcnv.o ../rts/s-carun8.o ../rts/s-conca2.o ../rts/s-conca3.o
../rts/s-traceb.o ../rts/a-exctra.o ../rts/s-soliin.o ../rts/s-soflin.o
../rts/s-secsta.o ../rts/s-exctab.o ../rts/a-ioexce.o ../rts/a-contai.o
../rts/s-except.o ../rts/a-string.o ../rts/s-excdeb.o ../rts/s-exctra.o
../rts/s-memory.o ../rts/s-bitops.o ../rts/a-stmaco.o ../rts/a-chahan.o
../rts/s-wchstw.o ../rts/s-valuti.o ../rts/s-valllu.o ../rts/s-vallli.o
../rts/s-os_lib.o ../rts/s-excmac.o ../rts/a-elchha.o ../rts/s-addima.o
../rts/s-boustr.o ../rts/s-stalib.o ../rts/a-strmap.o ../rts/i-c.o
../rts/s-mmauni.o ../rts/s-mmap.o ../rts/s-objrea.o ../rts/s-mmosin.o
../rts/s-trasym.o ../rts/a-except.o ../rts/s-dwalin.o ../rts/a-comlin.o
../rts/a-tags.o ../rts/a-stream.o ../rts/g-os_lib.o ../rts/s-ficobl.o
../rts/s-finroo.o ../rts/a-finali.o ../rts/s-fileio.o ../rts/s-valenu.o
../rts/a-textio.o ../rts/s-assert.o ./debug.o ./types.o ./alloc.o ./gnatvsn.o
./hostparm.o ./output.o ./rident.o ./tree_io.o ./opt.o ./csets.o ./table.o
./widechar.o ./namet.o ./fmap.o ./targparm.o ./osint.o ./sdefault.o ./switch.o
./gnatcmd.o ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a
../rts/libgnat.a ../../../libbacktrace/.libs/libbacktrace.a
../../../libiberty/libiberty.a -o ../../gnat -L../rts/ -L./
-L/space/rguenther/src/svn/early-lto-debug/gcc/ada/
-L/usr/local/lib64/gcc/x86_64-pc-linux-gnu/8.0.1/adalib/
/home/abuild/rguenther/obj/gcc/ada/rts/libgnat.a -ldl -B../../ -I- -I../rts -I.
-I/space/rguenther/src/svn/early-lto-debug/gcc/ada -static-libstdc++
-static-libgcc -static-libstdc++ -static-libgcc
g++: fatal error: braced spec
‘%:sanitize(address):%{!shared:libasan_preinit%O%s}
%{static-libasan:%{!shared:-Bstatic --whole-archive -lasan --no-whole-archive
-Bdynamic}}%{!static-libasan:-lasan}}
%{%:sanitize(thread):%{!shared:libtsan_preinit%O%s}
%{static-libtsan:%{!shared:-Bstatic --whole-archive -ltsan --no-whole-archive
-Bdynamic}}%{!static-libtsan:-ltsan}}
%{%:sanitize(leak):%{!shared:liblsan_preinit%O%s}
%{static-liblsan:%{!shared:-Bstatic --whole-archive -llsan --no-whole-archive
-Bdynamic}}%{!static-liblsan:-llsan}}’ is invalid at ‘%’
compilation terminated.
gnatlink: error when calling /usr/bin/g++
../gcc-interface/Makefile:2212: recipe for target 'common-tools' failed
note how we link with the host compiler but pass it -B../../
Removing -B../../ fixes the issue. In PR81878 the issue was we needed to
use the host libstdc++ which is fixed now by using the host CXX to link
but passing -B../../ is obviously broken - it happens that ../../specs
exists (for whatever reasons?!) and that is picked up by the link.
specs is re-generated when I remove it and try continuing:
make[2]: Entering d
[Bug tree-optimization/84956] [6/7/8 Regression] ICE in replace_block_by, at tree-ssa-tail-merge.c:1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84956 --- Comment #7 from Tom de Vries --- Author: vries Date: Thu Mar 22 11:01:15 2018 New Revision: 258762 URL: https://gcc.gnu.org/viewcvs?rev=258762&root=gcc&view=rev Log: backport "[tail-merge] Don't merge bbs with bb_has_abnormal_pred" 2018-03-22 Tom de Vries backport from trunk: 2018-03-22 Tom de Vries PR tree-optimization/84956 * tree-ssa-tail-merge.c (find_clusters_1): Skip bbs with bb_has_abnormal_pred. * gcc.dg/pr84956.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr84956.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-tail-merge.c
[Bug tree-optimization/84956] [6/7/8 Regression] ICE in replace_block_by, at tree-ssa-tail-merge.c:1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84956 Tom de Vries changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Tom de Vries --- Patch with test-case committed to stage 4 trunk, backported to 6 and 7 branch. Marking resolved-fixed.
[Bug ada/85036] --disable-bootstrap --enable-languages=ada[,c++] fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85036 --- Comment #1 from Richard Biener --- I need the following. Not sure why we ever need gcc/specs now (even for crosses) all specs should be builtin. Note that original issue of course only happens if the host driver cannot process the specs language of what we compile (in my case it's GCC 4.8). Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 258720) +++ gcc/Makefile.in (working copy) @@ -771,7 +771,7 @@ COMPILERS = @all_compilers@ # List of things which should already be built whenever we try to use xgcc # to compile anything (without linking). -GCC_PASSES=xgcc$(exeext) specs +GCC_PASSES=xgcc$(exeext) # Directory to link to, when using the target `maketest'. DIR = ../gcc @@ -1899,7 +1899,7 @@ all.internal: start.encap rest.encap doc all.cross: native gcc-cross$(exeext) cpp$(exeext) specs \ libgcc-support lang.all.cross doc selftest @GENINSRC@ srcextra # This is what must be made before installing GCC and converting libraries. -start.encap: native xgcc$(exeext) cpp$(exeext) specs \ +start.encap: native xgcc$(exeext) cpp$(exeext) \ libgcc-support lang.start.encap @GENINSRC@ srcextra # These can't be made until after GCC can run. rest.encap: lang.rest.encap @@ -2054,7 +2054,7 @@ checksum-options: libgcc-support: libgcc.mvars stmp-int-hdrs $(TCONFIG_H) \ $(MACHMODE_H) gcov-iov.h -libgcc.mvars: config.status Makefile specs xgcc$(exeext) +libgcc.mvars: config.status Makefile xgcc$(exeext) : > tmp-libgcc.mvars echo GCC_CFLAGS = '$(GCC_CFLAGS)' >> tmp-libgcc.mvars echo INHIBIT_LIBC_CFLAGS = '$(INHIBIT_LIBC_CFLAGS)' >> tmp-libgcc.mvars
[Bug inline-asm/85034] -O1 internal compiler error: in elimination_costs_in_insn, at reload1.c:3633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85034 --- Comment #1 from Vegard Nossum --- FWIW, gcc built from r258757 with asan gives: :4:1: internal compiler error: in elimination_costs_in_insn, at reload1.c:3633 /home/vegard/git/gcc/libbacktrace/elf.c:2891:22: runtime error: load of misaligned address 0x7fcd5cfafddd for type 'const uint32_t', which requires 4 byte alignment 0x7fcd5cfafddd: note: pointer points here 33 2e 73 6f 00 00 00 00 c4 0a 19 a5 00 2e 73 68 73 74 72 74 61 62 00 2e 6e 6f 74 65 2e 67 6e 75 ^ 0xfa62b80 elimination_costs_in_insn /home/vegard/git/gcc/gcc/reload1.c:3630 0xfb2e117 calculate_elim_costs_all_insns() /home/vegard/git/gcc/gcc/reload1.c:1607 0xcb6411a ira_costs() /home/vegard/git/gcc/gcc/ira-costs.c:2249 0xca59ed0 ira_build() /home/vegard/git/gcc/gcc/ira-build.c:3427 0xc8c9fc4 ira /home/vegard/git/gcc/gcc/ira.c:5295 0xc8c9fc4 execute /home/vegard/git/gcc/gcc/ira.c:5606
[Bug c++/85027] [6/7/8 Regression] ICE on invalid C++ code: in instantiate_type, at cp/class.c:8062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85027
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
build_conditional_expr_1 is called with BASELINK as arg1, and because arg2 is
not specified, wraps it into a SAVE_EXPR:
arg2 = arg1 = cp_save_expr (arg1);
Later on perform_implicit_conversion_flags fails the conversion and does:
if (complain & tf_error)
{
/* If expr has unknown type, then it is an overloaded function.
Call instantiate_type to get good error messages. */
if (TREE_TYPE (expr) == unknown_type_node)
instantiate_type (type, expr, complain);
but instantiate_type doesn't handle a BASELINK wrapped into a SAVE_EXPR, only a
BASELINK by itself.
So, shall build_conditional_expr_1 for BASELINK (or for TREE_TYPE (arg1) ==
unknown_type_node) not create the SAVE_EXPR, or cp_save_expr not create
SAVE_EXPR for these? Is there any chance that the BASELINK would actually be
successfully converted to something like a bool?
[Bug target/85025] libgcc/config/i386/shadow-stack-unwind.h is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85025 --- Comment #1 from itsimbal at gcc dot gnu.org --- Author: itsimbal Date: Thu Mar 22 11:22:31 2018 New Revision: 258763 URL: https://gcc.gnu.org/viewcvs?rev=258763&root=gcc&view=rev Log: Fix PR85025: libgcc/config/i386/shadow-stack-unwind.h is wrong. PR target/85025 * config/i386/shadow-stack-unwind.h (_Unwind_Frames_Extra): Fix a typo, tmp => 255. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/i386/shadow-stack-unwind.h
[Bug target/85025] libgcc/config/i386/shadow-stack-unwind.h is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85025 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #2 from H.J. Lu --- Fixed.
[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 85025, which changed state. Bug 85025 Summary: libgcc/config/i386/shadow-stack-unwind.h is wrong https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85025 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug inline-asm/85034] -O1 internal compiler error: in elimination_costs_in_insn, at reload1.c:3633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85034 --- Comment #2 from Vegard Nossum --- (In reply to Vegard Nossum from comment #1) > FWIW, gcc built from r258757 with asan gives: Nevermind, the asan thing comes from the stack trace and is unrelated (it appears for all stack traces regardless of the input).
[Bug ada/85036] --disable-bootstrap --enable-languages=ada[,c++] fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85036 --- Comment #2 from Richard Biener --- So one of the offending changes was done in r54614 which introduced the dependency on libgcc build. Previously it looks like only cross builds and install (and also fixincludes) depended on it.
[Bug bootstrap/85020] [8 Regression] gcc fails to bootstrap with profiledbootstrap and --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85020 Jakub Jelinek changed: What|Removed |Added CC||pmderodat at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Isn't that Ada FE bug that it doesn't call the debug hook for the global var before calling the debug hook on array that uses it as array size or something used in it?
[Bug libfortran/82962] valgrind reports "Conditional jump or move depends on uninitialised value" in EXECUTE_COMMAND_LINE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82962 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to janus from comment #7) > One thing that could be done instead is to mention the INTENTs of the > arguments in the documentation: > > https://gcc.gnu.org/onlinedocs/gfortran/EXECUTE_005fCOMMAND_005fLINE.html Also for the case of GET_COMMAND_ARGUMENT, the intents could use some clarification: https://gcc.gnu.org/onlinedocs/gfortran/GET_005fCOMMAND_005fARGUMENT.html
[Bug c++/84782] Rejects a maybe C++ code snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84782
--- Comment #6 from Jonathan Wakely ---
(In reply to Raphael Kubo da Costa from comment #5)
> Sorry if my comment was too coarse-grained. My hypothesis that this is a
> duplicate comes from playback_image_provider.ii looking like Chromium's
> playback_image_provider.cc, which was failing to build with GCC when a copy
> constructor was not defined inline (just like the union from bug 70431).
Not every example with a non-inline copy constructor is the same though.
> My reduced testcase from the original Chromium code (without templates)
> looks like this:
>
> -
> struct S1 {
> S1& operator=(const S1&) = default;
> S1& operator=(S1&&) = default;
> };
>
> struct S2 {
> S2() = default;
> S2(const S2&);
> S1 m;
> };
>
> S2::S2(const S2&) = default;
> -
>
> x.cc:12:1: note: ‘S2::S2(const S2&)’ is implicitly deleted because the
> default definition would be ill-formed:
> S2::S2(const S2&) = default;
> ^~
> x.cc:12:1: error: use of deleted function ‘constexpr S1::S1(const S1&)’
> x.cc:1:8: note: ‘constexpr S1::S1(const S1&)’ is implicitly declared as
> deleted because ‘S1’ declares a move constructor or move assignment operator
> struct S1 {
> ^~
>
> The error goes away if S2's copy constructor is declared inline.
Because that's what the C++ standard requires. A copy constructor that is
defined as defaulted outside the class body is ill-formed if it would be
implicitly deleted. If it's defaulted on its first declaration (i.e. inside the
class body) then it is defined as deleted.
Your example is not valid, and is rejected by GCC and Clang and EDG.
[Bug ada/85036] --disable-bootstrap --enable-languages=ada[,c++] fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85036 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-22 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou --- I presume that the -B../../ comes from $(CC).
[Bug bootstrap/85020] [8 Regression] gcc fails to bootstrap with profiledbootstrap and --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85020
--- Comment #5 from Richard Biener ---
So the following is a better fix, the comment already explains how this is
wrong to do early.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 258720)
+++ gcc/dwarf2out.c (working copy)
@@ -19878,6 +19878,7 @@ rtl_for_decl_location (tree decl)
in the current CU, resolve_addr will remove the expression referencing
it. */
if (rtl == NULL_RTX
+ && !early_dwarf
&& VAR_P (decl)
&& !DECL_EXTERNAL (decl)
&& TREE_STATIC (decl)
note for the specific case in the testcase this ends up without a location
because the context of the "location" is the TU (and current_function_decl
is NULL) so we fail
rtl = rtl_for_decl_location (loc);
if (rtl == NULL_RTX)
{
if (TREE_CODE (loc) != FUNCTION_DECL
&& early_dwarf
&& current_function_decl
&& want_address != 1
&& ! DECL_IGNORED_P (loc)
&& (INTEGRAL_TYPE_P (TREE_TYPE (loc))
|| POINTER_TYPE_P (TREE_TYPE (loc)))
&& DECL_CONTEXT (loc) == current_function_decl
&& (GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (TREE_TYPE (loc)))
<= DWARF2_ADDR_SIZE))
{
I guess the intent of the check was
(!decl_function_context (loc)
|| decl_function_context (loc) == current_function_decl)
so with additionally having
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 258720)
+++ gcc/dwarf2out.c (working copy)
@@ -18204,14 +18204,15 @@ loc_list_from_tree_1 (tree loc, int want
rtl = rtl_for_decl_location (loc);
if (rtl == NULL_RTX)
{
+ tree fn_ctx;
if (TREE_CODE (loc) != FUNCTION_DECL
&& early_dwarf
- && current_function_decl
&& want_address != 1
&& ! DECL_IGNORED_P (loc)
&& (INTEGRAL_TYPE_P (TREE_TYPE (loc))
|| POINTER_TYPE_P (TREE_TYPE (loc)))
- && DECL_CONTEXT (loc) == current_function_decl
+ && (!(fn_ctx = decl_function_context (loc))
+ || fn_ctx == current_function_decl)
&& (GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (TREE_TYPE (loc)))
<= DWARF2_ADDR_SIZE))
{
I get a location for this.
At this point it's probably better to instead guard with
!(early_dwarf && (flag_generate_lto || flag_generate_offload))
to not risk debug degradation for others. The 2nd change is optional
(preserve some debug), not sure if we should do that right now.
[Bug ada/85036] --disable-bootstrap --enable-languages=ada[,c++] fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85036 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- This looks fixable in gnatlink.adb.
[Bug bootstrap/85020] [8 Regression] gcc fails to bootstrap with profiledbootstrap and --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85020 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-03-22 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- Created attachment 43733 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43733&action=edit patch Patch I am testing.
[Bug ada/85036] --disable-bootstrap --enable-languages=ada[,c++] fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85036 --- Comment #5 from rguenther at suse dot de --- On Thu, 22 Mar 2018, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85036 > > Eric Botcazou changed: > >What|Removed |Added > > Status|UNCONFIRMED |NEW >Last reconfirmed||2018-03-22 > CC||ebotcazou at gcc dot gnu.org > Ever confirmed|0 |1 > > --- Comment #3 from Eric Botcazou --- > I presume that the -B../../ comes from $(CC). Yes.
[Bug go/85037] New: SIGSEGV in gotools testsuite affects several tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85037 Bug ID: 85037 Summary: SIGSEGV in gotools testsuite affects several tests Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ubizjak at gmail dot com CC: cmang at google dot com Target Milestone: --- Several tests in gotools testsuite start to fail with the following backtrace: FAIL: TestCgoSignalDeadlock crash_test.go:55: building testprogcgo []: exit status 2 # _/space/uros/gcc-svn/trunk/libgo/go/runtime/testdata/testprogcgo panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=1 addr=0 pc=2199037193288] goroutine 1 [running]: panic /space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/panic.go:557 internal_poll.FD.destroy /space/homedirs/uros/gcc-svn/trunk/libgo/go/internal/poll/fd_unix.go:71 internal_poll.FD.decref /space/homedirs/uros/gcc-svn/trunk/libgo/go/internal/poll/fd_mutex.go:211 internal_poll.FD.Close /space/homedirs/uros/gcc-svn/trunk/libgo/go/internal/poll/fd_unix.go:93 os.file.close /space/homedirs/uros/gcc-svn/trunk/libgo/go/os/file_unix.go:210 os.File.Close /space/homedirs/uros/gcc-svn/trunk/libgo/go/os/file_unix.go:202 os_exec.Cmd.closeDescriptors /space/homedirs/uros/gcc-svn/trunk/libgo/go/os/exec/exec.go:284 os_exec.Cmd.Start /space/homedirs/uros/gcc-svn/trunk/libgo/go/os/exec/exec.go:391 os_exec.Cmd.Run /space/homedirs/uros/gcc-svn/trunk/libgo/go/os/exec/exec.go:302 main.run /space/homedirs/uros/gcc-svn/trunk/gotools/../libgo/go/cmd/cgo/util.go:62 main.runGcc /space/homedirs/uros/gcc-svn/trunk/gotools/../libgo/go/cmd/cgo/gcc.go:1736 main.Package.gccDefines /space/homedirs/uros/gcc-svn/trunk/gotools/../libgo/go/cmd/cgo/gcc.go:1692 main.Package.loadDefines /space/homedirs/uros/gcc-svn/trunk/gotools/../libgo/go/cmd/cgo/gcc.go:203 main.Package.Translate /space/homedirs/uros/gcc-svn/trunk/gotools/../libgo/go/cmd/cgo/gcc.go:185 main.main /space/homedirs/uros/gcc-svn/trunk/gotools/../libgo/go/cmd/cgo/main.go:331
[Bug target/85038] New: x32: unnecessary address-size prefix when a pointer register is already zero-extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85038
Bug ID: 85038
Summary: x32: unnecessary address-size prefix when a pointer
register is already zero-extended
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
Bug 82267 was fixed for RSP only. (Or interpreted narrowly as only being about
RSP vs. ESP).
This bug is about the general case of using address-size prefixes in cases
where we could prove they're not needed. Either because out-of-bounds is UB so
we don't care about wrap vs. going outside 4GiB, or (simpler) the
single-register case when we know the pointer is already zero-extended. Maybe
we want separate bugs to track parts of this that can be fixed with separate
patches, but I won't consider this fixed until -mx32 emits optimal code for all
the cases listed here.
I realize this won't be any time soon, but it's still code-size (and thus
indirectly performance) that gcc is leaving on the table. Being smarter about
using 64-bit address-size is even more useful for AArch64 -mabi=ilp32, because
it doesn't have 32-bit address-size overrrides, so it always costs an extra
instruction every time we fail to prove that 64-bit is safe. (And AArch64
ILP32 may get more use than x32 these days). I intended this bug to be about
x32, though.
Useless 0x67 address-size override prefixes hurt code-size and thus performance
on everything, with more serious problems on some CPUs that have trouble with
more than 3 prefixes (especially Silvermont). See Bug 82267 for the details
which I won't repeat.
We still have tons of useless 0x67 prefixes in the default -maddress-mode=short
mode (for every memory operand other than RSP, or RIP-relative), and
-maddress-mode=long has lots of missed optimizations resulting in wasted LEA
instructions, so neither one is good.
float doublederef(float **p){
return **p;
}
// https://godbolt.org/g/exb74t
// gcc 8.0.1 (trunk) -O3 -mx32 -march=haswell -maddress-mode=short
movl(%edi), %eax
vmovss (%eax), %xmm0# could/should be (%rax)
ret
-maddress-mode=long gets that right, using (%rax), and also (%rdi) because the
ABI doc specifies that x32 passes pointers zero-extended. mode=short still
ensures that, so failure to take advantage is still a missed-opt.
Note that clang -mx32 violates that ABI guarantee by compiling
pass_arg(unsigned long long ptr) { ext_func((void*)ptr); } to just a tailcall
(while gcc does zero-extend). See output in the godbolt link above. IDK if we
care about being bug-compatible with clang for that corner case for this rare
ABI, though. A less contrived case would be a struct arg or return value
packed into a register passed on as just a pointer.
-
// arr+offset*4 is strictly within the low 32 bits because of range limits
float safe_offset(float *arr, unsigned offset){
unsigned tmp = (unsigned)arr;
arr = (void*)(tmp & -4096); // round down to a page
offset &= 0xf;
return arr[offset];
}
// on the above godbolt link
#mode=short
andl$-4096, %edi
andl$15, %esi
vmovss (%edi,%esi,4), %xmm0
# (%rdi,%rsi,4) would have been safe, but that's maybe not worth
looking for.
# most cases have less pointer alignment than offset range
#mode=long
andl$-4096, %edi
andl$15, %esi
leal(%rdi,%rsi,4), %eax
vmovss (%eax), %xmm0 # 32-bit addrmode after using a separate
LEA
So mode=long is just braindead here. It gets the worst of both worlds, using a
separate LEA but then not taking advantage of the zero-extended pointer. The
only way this could be worse is the LEA operand-size was 64-bit.
Without the masking, both modes just use vmovss (%edi,%esi,4), %xmm0, but the
extra operations defeat mode=long's attempts to recognize this case, and it
picks an LEA instead of (or as well as?!?) an address-size prefix.
---
With a 64-bit offset, and a pointer that's definitely zero-extended to 64 bits:
// same for signed or unsigned
float ptr_and_offset_zext(float **p, unsigned long long offset){
float *arr = *p;
return arr[offset];
}
# mode=short
movl(%edi), %eax # mode=long uses (%rdi) here
vmovss (%eax,%esi,4), %xmm0 # but still 32-bit here.
ret
Why are we using address-size prefixes to stop a base+index from going outside
4G on out of bounds UB? (%rax,%rsi,4) should work for a signed / unsigned
64-bit offset when the pointer is known to be zero-extended.
ISO C11 says that pointer+integer produces a result of pointer type, with UB if
the result goes outside the array. It does *not* say that the integer has
[Bug target/85026] [6/7/8 Regression] Error: branch out of range on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85026 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords|needs-bisection | Status|NEW |ASSIGNED Known to work|6.4.1, 7.1.0, 8.0 | Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Target Milestone|7.4 |6.5 Summary|[7 Regression] Error: |[6/7/8 Regression] Error: |branch out of range on |branch out of range on |arm-linux-gnueabihf |arm-linux-gnueabihf Known to fail|7.3.1 |6.4.1, 7.1.0, 8.0 --- Comment #4 from ktkachov at gcc dot gnu.org --- Thanks Jakub. I agree it's latent on the recent branches. I'm testing a patch.
[Bug c++/85039] New: nested_anon_class_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85039
Bug ID: 85039
Summary: nested_anon_class_index
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vegard.nossum at oracle dot com
CC: webrown.cpp at gmail dot com
Target Milestone: ---
Input:
constexpr int a() {
__builtin_offsetof(struct {
short b {
__builtin_offsetof(struct {
struct c {
void d() {
}
};
});
};
});
}
Output:
$ cc1plus
constexpr int a() void a()::c::d()
: At global scope:
:6:16: internal compiler error: in nested_anon_class_index, at
cp/mangle.c:1626
0x349df28 nested_anon_class_index
/home/vegard/git/gcc/gcc/cp/mangle.c:1626
0x349df28 write_unnamed_type_name
/home/vegard/git/gcc/gcc/cp/mangle.c:1640
0x349df28 write_unqualified_name
/home/vegard/git/gcc/gcc/cp/mangle.c:1407
0x34caa03 write_prefix
/home/vegard/git/gcc/gcc/cp/mangle.c:1166
0x34ca9fb write_prefix
/home/vegard/git/gcc/gcc/cp/mangle.c:1165
0x34d14eb write_nested_name
/home/vegard/git/gcc/gcc/cp/mangle.c:1083
0x33f4033 write_name
/home/vegard/git/gcc/gcc/cp/mangle.c:976
0x33f7cbc write_local_name
/home/vegard/git/gcc/gcc/cp/mangle.c:2057
0x33f7cbc write_name
/home/vegard/git/gcc/gcc/cp/mangle.c:964
0x33791c5 write_encoding
/home/vegard/git/gcc/gcc/cp/mangle.c:825
0x34e53f8 mangle_decl_string
/home/vegard/git/gcc/gcc/cp/mangle.c:3792
0x34ead33 get_mangled_id
/home/vegard/git/gcc/gcc/cp/mangle.c:3814
0x34ead33 mangle_decl(tree_node*)
/home/vegard/git/gcc/gcc/cp/mangle.c:3852
0x16745350 decl_assembler_name(tree_node*)
/home/vegard/git/gcc/gcc/tree.c:687
0x1716f86d notice_global_symbol(tree_node*)
/home/vegard/git/gcc/gcc/varasm.c:1668
0x7a4933b cgraph_node::finalize_function(tree_node*, bool)
/home/vegard/git/gcc/gcc/cgraphunit.c:452
0x4ffc8c0 expand_or_defer_fn(tree_node*)
/home/vegard/git/gcc/gcc/cp/semantics.c:4287
0x3fc3268 cp_parser_function_definition_after_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:26847
0x3fcdaa4 cp_parser_late_parsing_for_member
/home/vegard/git/gcc/gcc/cp/parser.c:27723
0x3d32a56 cp_parser_class_specifier_1
/home/vegard/git/gcc/gcc/cp/parser.c:22766
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/85033] internal compiler error: in fold_offsetof_1, at c-family/c-common.c:6269
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85033
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #2 from Marek Polacek ---
I think this could be fixed by just
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -4072,6 +4072,11 @@ finish_offsetof (tree object_ptr, tree expr, location_t
loc)
}
return error_mark_node;
}
+ if (TREE_CODE (expr) == CONST_DECL)
+{
+ error ("cannot apply % to an enumerator %qD", expr);
+ return error_mark_node;
+}
if (REFERENCE_REF_P (expr))
expr = TREE_OPERAND (expr, 0);
if (!complete_type_or_else (TREE_TYPE (TREE_TYPE (object_ptr)), object_ptr))
[Bug inline-asm/84941] [6/7/8 Regression] internal compiler error: in reg_overlap_mentioned_p, at rtlanal.c:1870 (reg_overlap_mentioned_p()/match_asm_constraints_1())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84941 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Mar 22 12:31:46 2018 New Revision: 258764 URL: https://gcc.gnu.org/viewcvs?rev=258764&root=gcc&view=rev Log: PR inline-asm/84941 * function.c (match_asm_constraints_1): Don't do the optimization if input isn't a REG, SUBREG, MEM or constant. * gcc.dg/pr84941.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr84941.c Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84782] Rejects a maybe C++ code snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84782 --- Comment #7 from Raphael Kubo da Costa --- (In reply to Jonathan Wakely from comment #6) > Your example is not valid, and is rejected by GCC and Clang and EDG. Ugh, I forgot to test it with clang before posting my comment. I stand corrected. Is it relevant that your testcase builds fine when G's copy constructor is inlined?
[Bug inline-asm/84941] [6/7 Regression] internal compiler error: in reg_overlap_mentioned_p, at rtlanal.c:1870 (reg_overlap_mentioned_p()/match_asm_constraints_1())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84941 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8 Regression] internal |[6/7 Regression] internal |compiler error: in |compiler error: in |reg_overlap_mentioned_p, at |reg_overlap_mentioned_p, at |rtlanal.c:1870 |rtlanal.c:1870 |(reg_overlap_mentioned_p()/ |(reg_overlap_mentioned_p()/ |match_asm_constraints_1()) |match_asm_constraints_1()) --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/85039] internal compiler error: in nested_anon_class_index, at cp/mangle.c:1626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85039
--- Comment #1 from Vegard Nossum ---
Alternative testcase:
struct d {
} * d::b(__builtin_offsetof(struct {
struct a {
int c() { return .1f; }
};
}, ))
[Bug libstdc++/85040] [8 Regression] std::less fails when operator< is overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85040 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-03-22 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1
[Bug libstdc++/85040] New: [8 Regression] std::less fails when operator< is overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85040
Bug ID: 85040
Summary: [8 Regression] std::less fails when operator< is
overloaded
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct string { } s;
bool operator<(const string&, const string&) { return false; }
std::less<> lt;
bool b = lt(s, s);
This fails since the fix for PR 78420
[Bug libstdc++/85040] [8 Regression] std::less fails when operator< is overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85040 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/84783] Missing _mm256_permutexvar_epi64() intrinsic for AVX512VL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84783 --- Comment #3 from Sebastian Peryt --- Proposed patch sent to list https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01181.html
[Bug target/85038] x32: unnecessary address-size prefix when a pointer register is already zero-extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85038
--- Comment #1 from Peter Cordes ---
Correction for AArch64: it supports addressing modes with a 64-bit base
register + 32-bit index register with zero or sign extension for the 32-bit
index. But not 32-bit base registers.
As a hack that's better than nothing, AArch64 could use a 32-bit pointer as the
index with a UXTW mode, using a zeroed register as the base (unless indexed
modes have any perf downside on real AArch64 chips). But unfortunately, the
architectural zero register isn't usable as the base: that encoding means the
stack pointer for this instruction. ldr w1,[xzr,w2,uxtw] doesn't assemble,
only x0-x30 or SP.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801b/BABBGCAC.html
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802b/LDR_reg_gen.html
describes LDR Wt, [Xn|SP, Rm{, extend {amount}}]
where Rm can be an X or W register, and "extend" can be SXTW or UXTW for word
regs, or LSL for X regs. (SXTX is a synonym for LSL). Any of the modes can
use a left-shift amount, applied *after* extension to 64-bit.
See
https://community.arm.com/processors/b/blog/posts/a64-shift-and-extend-operations-operand-modifiers
for details on operand-modifiers.
gcc6.3 doesn't take advantage with -mabi=ilp32, and Godbolt doesn't have later
AArch64 gcc.
So gcc will need to know about zero-extended pointers, and the signedness of
32-bit values, to take advantage of AArch64's addressing modes for the common
case of a 32-bit index. Teaching gcc to track signed/unsigned in RTL would
benefit x32 and AArch64 ILP32, if I understand the situation correctly.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #3 from Eric Reischer --- No, it used gnatmake -P . Is there a new recommended way to get gnatlink to generate a 32-bit bind file and link object on MULTIARCH systems (x86/x86_64 in this specific case)? It seems this would be functionality that would be needed by others, as well as needing a way to cross-compile for target hardware.
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #16 from Rainer Orth --- Author: ro Date: Thu Mar 22 13:33:29 2018 New Revision: 258766 URL: https://gcc.gnu.org/viewcvs?rev=258766&root=gcc&view=rev Log: xfail experimental/memory_resource/resource_adaptor.cc on 32-bit Solaris/x86 (PR libstdc++/77691) PR libstdc++/77691 * testsuite/experimental/memory_resource/resource_adaptor.cc: xfail execution on 32-bit Solaris/x86. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/experimental/memory_resource/resource_adaptor.cc
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #14 from Jonathan Wakely --- > We *could* make the libstdc++ operator new call malloc repeatedly until it > gets > something aligned to max_align_t, so that operator new and the C++ allocators > meet the alignment requirements. > > But that seems quite horrible. Indeed, and I'd rather not avoid that penalty for a corner case. To achieve this, one could instead use aligned_alloc instead, which is only in Solaris 11.4, however. Rainer
[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #18 from Rainer Orth --- Xfailed for GCC 8.1. I'm leaving the PR open for the underlying issue.
[Bug c++/84269] More suggestions for missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269 --- Comment #8 from David Malcolm --- From PR 84896: gcc 8 currently emits the following for: std::pair foo; error: 'pair' in namespace 'std' does not name a template type std::pair foo; ^~~~ We ought to suggest including for this, and probably various other stdlib templates.
[Bug c++/84269] More suggestions for missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269 --- Comment #9 from David Malcolm --- *** Bug 84896 has been marked as a duplicate of this bug. ***
[Bug c++/84896] Better handling of missing for std::pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84896 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from David Malcolm --- (reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269#c8 ) *** This bug has been marked as a duplicate of bug 84269 ***
[Bug fortran/77941] ICE in expand_expr_addr_expr_1, at expr.c:7805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77941 --- Comment #7 from Steve Kargl --- On Thu, Mar 22, 2018 at 07:53:14AM +, jb at gcc dot gnu.org wrote: > > It works on x86_64-pc-linux-gnu (including running it), but the ICE remains on > i686-pc-linux-gnu. > Janne, thanks for checking. 2_8**32+1 is 4GB+1byte of memory. Without PAE, i686 is limited to less than 4GB once an OS grabs a small portion of wired memory. Do we care if an ICE occurs? I suppose one could always check that a length type parameter less than some max integer based on 32-bit vs 64-bit system, but that would pessimize all uses of strings as this would need to be a runtime check.
[Bug libstdc++/85041] New: std::vector::data with -std=c++98 flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85041
Bug ID: 85041
Summary: std::vector::data with -std=c++98 flag
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gbalog at inbox dot ru
Target Milestone: ---
The code below compiles with the flag -std=c++98, but it shouldn't, because the
data() method appeared in c++11.
In the implementation of std::vector, there are no checks around this method.
With flag -pedantic there are no warnings either.
#include
int main()
{
std::vector v;
const int * ptr = v.data();
}
[Bug c++/84854] [7 Regression] ICE: unexpected expression in cxx_eval_constant_expression, at cp/constexpr.c:4774
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84854 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Thu Mar 22 14:14:06 2018 New Revision: 258770 URL: https://gcc.gnu.org/viewcvs?rev=258770&root=gcc&view=rev Log: PR c++/84854 * semantics.c (finish_if_stmt_cond): Check if the type of the condition is boolean. * g++.dg/cpp1z/constexpr-if13.C: New test. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-if13.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/semantics.c
[Bug c++/84854] [7 Regression] ICE: unexpected expression in cxx_eval_constant_expression, at cp/constexpr.c:4774
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84854 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- The ICE fixed for 7 too.
[Bug c++/84927] [7 Regression] ICE with NSDMI and reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84927 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Thu Mar 22 14:17:03 2018 New Revision: 258771 URL: https://gcc.gnu.org/viewcvs?rev=258771&root=gcc&view=rev Log: PR c++/84927 * constexpr.c (cxx_eval_bare_aggregate): Update constructor's flags as we evaluate the elements. (cxx_eval_constant_expression): Verify constructor's flags unconditionally. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr9.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/constexpr.c
[Bug c++/71638] [6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu with -Wall (internal compiler error: non-constant element in constant CONSTRUCTOR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71638 --- Comment #12 from Marek Polacek --- Author: mpolacek Date: Thu Mar 22 14:18:17 2018 New Revision: 258772 URL: https://gcc.gnu.org/viewcvs?rev=258772&root=gcc&view=rev Log: PR c++/71638, ICE with NSDMI and reference. * constexpr.c (cxx_eval_bare_aggregate): Update constructor's flags even when we replace an element. * g++.dg/cpp0x/nsdmi14.C: New test. * g++.dg/cpp1y/nsdmi-aggr10.C: New test. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/nsdmi14.C branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr10.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/constexpr.c
[Bug c++/84927] [7 Regression] ICE with NSDMI and reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84927 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug c++/71638] [6 Regression] ICE on invalid C++ code on x86_64-linux-gnu with -Wall (internal compiler error: non-constant element in constant CONSTRUCTOR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71638 Marek Polacek changed: What|Removed |Added Summary|[6/7 Regression] ICE on |[6 Regression] ICE on |invalid C++ code on |invalid C++ code on |x86_64-linux-gnu with -Wall |x86_64-linux-gnu with -Wall |(internal compiler error: |(internal compiler error: |non-constant element in |non-constant element in |constant CONSTRUCTOR) |constant CONSTRUCTOR) --- Comment #13 from Marek Polacek --- Fixed.
[Bug libstdc++/85040] [8 Regression] std::less fails when operator< is overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85040 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Thu Mar 22 14:23:27 2018 New Revision: 258773 URL: https://gcc.gnu.org/viewcvs?rev=258773&root=gcc&view=rev Log: PR libstdc++/85040 fix std::less etc. ambiguities PR libstdc++/85040 * include/bits/stl_function.h (greater::__not_overloaded) (less::__not_overloaded, greater_equal::__not_overloaded) (less_equal::__not_overloaded): Fix ambiguous specializations. * testsuite/20_util/function_objects/comparisons_pointer.cc: Add tests for type with overlaoded operators. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_function.h trunk/libstdc++-v3/testsuite/20_util/function_objects/comparisons_pointer.cc
[Bug libstdc++/85040] [8 Regression] std::less fails when operator< is overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85040 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Fixed.
[Bug libstdc++/78420] [6/7 Regression] std::less is not a total order with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 Bug 78420 depends on bug 85040, which changed state. Bug 85040 Summary: [8 Regression] std::less fails when operator< is overloaded https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85040 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/77941] ICE in expand_expr_addr_expr_1, at expr.c:7805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77941
--- Comment #8 from Janne Blomqvist ---
(In reply to Steve Kargl from comment #7)
> On Thu, Mar 22, 2018 at 07:53:14AM +, jb at gcc dot gnu.org wrote:
> >
> > It works on x86_64-pc-linux-gnu (including running it), but the ICE remains
> > on
> > i686-pc-linux-gnu.
> >
>
> Janne, thanks for checking. 2_8**32+1 is 4GB+1byte of memory.
> Without PAE, i686 is limited to less than 4GB once an OS grabs a
> small portion of wired memory. Do we care if an ICE occurs?
> I suppose one could always check that a length type parameter
> less than some max integer based on 32-bit vs 64-bit system,
> but that would pessimize all uses of strings as this would
> need to be a runtime check.
If one looks at the -fdump-tree-original dumps, for both i686 and x86-64 the
function f() looks Ok. However, the program p differs significantly. For x86-64
the working program p is:
p ()
{
static void f (character(kind=1)[1:] &, integer(kind=8), integer(kind=8));
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = &"z.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 2;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
{
character(kind=1)[1:4294967297] * pstr.1;
void * restrict D.3781;
D.3781 = (void * restrict) __builtin_malloc (4294967297);
pstr.1 = (character(kind=1)[1:4294967297] *) D.3781;
f (pstr.1, 4294967297, 4294967297);
_gfortran_transfer_character_write (&dt_parm.0, pstr.1, 4294967297);
__builtin_free ((void *) pstr.1);
}
_gfortran_st_write_done (&dt_parm.0);
}
}
whereas for i686 we have:
p ()
{
static void f (character(kind=1)[1:] &, integer(kind=4), integer(kind=8));
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = &"z.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 2;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
{
character(kind=1) str.1[1];
f ((character(kind=1)[1:1] *) &str.1, 1(OVF), 4294967297);
_gfortran_transfer_character_write (&dt_parm.0, (character(kind=1)[1:1]
*) &str.1, 1(OVF));
}
_gfortran_st_write_done (&dt_parm.0);
}
}
So evidently for i686 the frontend realizes that the size of the result array
overflows and then skips malloc()'ing space for it. So I guess in some way it
should be possible for the frontend to detect the overflow and abort before we
get the ICE.
[Bug fortran/77941] ICE in expand_expr_addr_expr_1, at expr.c:7805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77941 --- Comment #9 from Janne Blomqvist --- (In reply to Steve Kargl from comment #7) > I suppose one could always check that a length type parameter > less than some max integer based on 32-bit vs 64-bit system, > but that would pessimize all uses of strings as this would > need to be a runtime check. IMHO we shouldn't do runtime checks for this. Particularly now that we support 64-bit string lengths on 64-bit targets (which is what more or less everybody doing real work will be using), outside of artificial examples we're never going to hit the limit.
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #16 from Jakub Jelinek ---
For the non-LTO -O3 -g case, the issue is that while in the original testcase
the value was intentionally used afterwards, main in guality.h ignores the
result and so if guality_main is inlined into main, the argc > 0 ? 1 : -1
expression is only used by the guality_check call and so is stored only in a
call clobbered register %rsi; that is something we can't use from within the
call, so vartrack emits:
(note 489 259 262 13 (var_location b (reg:SI 4 si [orig:218 b ] [218]))
NOTE_INSN_VAR_LOCATION)
(call_insn:TI 262 489 490 13 (call (mem:QI (symbol_ref:DI
("guality_check.constprop.1") [flags 0x3] )) "pr41616-1.c":18 85 {*movdi_internal}
(nil))
(insn:TI 400 261 325 13 (set (strict_low_part (reg:QI 4 si [orig:133 b ]
[133]))
(gt:QI (reg:CCNO 17 flags)
(const_int 0 [0]))) "pr41616-1.c":17 669 {*setcc_qi_slp}
(expr_list:REG_DEAD (reg:CCNO 17 flags)
(nil)))
(insn:TI 325 400 257 13 (set (reg/v:SI 4 si [orig:133 b ] [133])
(plus:SI (mult:SI (reg/v:SI 4 si [orig:133 b ] [133])
(const_int 2 [0x2]))
(const_int -1 [0x]))) "pr41616-1.c":17 217 {*leasi}
(nil))
(debug_insn 257 325 258 13 (var_location:SI b (reg/v:SI 4 si [orig:133 b ]
[133])) -1
(nil))
(nil))
(call_insn:TI 262 259 263 13 (call (mem:QI (symbol_ref:DI
("guality_check.constprop.1") [flags 0x3] 0 ? -1 : 1;
bar (b);
return 0;
}
[Bug libstdc++/85041] std::vector::data with -std=c++98 flag succesfully compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85041 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Jonathan Wakely --- We supported that member before C++11, because it was added by Library DR 464 https://wg21.link/lwg464 A conforming C++98 program doesn't use that function, so doesn't care that it's present as an extension.
