[Bug c++/78502] Analyze 'final'/'override' even for uninstantiated class templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78502 Richard Biener changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #3 from Richard Biener --- (In reply to prathamesh3492 from comment #2) > Hi, > From the trace, it seems ptrdiff_type_node is set to NULL for ada ? > Either we can guard setting range for CFN_BUILTIN_STRLEN by checking > ptrtdiff_type_node is non null, or make vrp_val_max return NULL if type is > NULL. > I am trying to reproduce on x86_64-unknown-linux-gnu. > > Thanks, > Prathamesh Looks like gimple-ssa-sprintf.c also unconditionally uses it. I suppose we should move its initialization to build_common_tree_nodes, it's built from the PTRDIFF_TYPE target macro. See how size_type_node is built. Also move unsigned_ptrdiff_type_node.
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #4 from Jakub Jelinek --- Even for Fortran and other non-C FEs I think ptrdiff_type_node isn't what you expect it to be. Wouldn't it be better to use signed_type_for (type) as the type instead (where type is the type of strlen's lhs, i.e. usually size_t)?
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #5 from Richard Biener --- Ugh, and lto does lto/lto-lang.c: ptrdiff_type_node = integer_type_node; (bogus, possibly causes wrong-code if it's ever used, make sure to remove that init as well)
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #4) > Even for Fortran and other non-C FEs I think ptrdiff_type_node isn't what > you expect it to be. Wouldn't it be better to use signed_type_for (type) as > the type instead (where type is the type of strlen's lhs, i.e. usually > size_t)? As ptrdiff_type_node is appearantly used (otherwise we'd not have the LTO variant) it should be a middle-end defined type (it's defined by the target via PTRDIFF_TYPE).
[Bug preprocessor/78497] compiling with -save-temps adds -Wimplicit-fallthrough warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78497 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-24 Component|regression |preprocessor Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. I'm also not sure we can do much about this... (inject a #pragma diagnostic into preprocessed output?)
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #7 from Jakub Jelinek --- (In reply to Richard Biener from comment #3) > (In reply to prathamesh3492 from comment #2) > > Hi, > > From the trace, it seems ptrdiff_type_node is set to NULL for ada ? > > Either we can guard setting range for CFN_BUILTIN_STRLEN by checking > > ptrtdiff_type_node is non null, or make vrp_val_max return NULL if type is > > NULL. > > I am trying to reproduce on x86_64-unknown-linux-gnu. > > > > Thanks, > > Prathamesh > > Looks like gimple-ssa-sprintf.c also unconditionally uses it. > > I suppose we should move its initialization to build_common_tree_nodes, > it's built from the PTRDIFF_TYPE target macro. See how size_type_node is > built. > Also move unsigned_ptrdiff_type_node. The way gimple-ssa-sprintf.c uses it looks just wrong to me. case FMT_LEN_z: dirtype = sign ? ptrdiff_type_node : size_type_node; break; case FMT_LEN_t: dirtype = sign ? ptrdiff_type_node : size_type_node; break; From what I can see in POSIX, it should be case FMT_LEN_z: dirtype = sign ? signed_type_for (size_type_node) : size_type_node; break; case FMT_LEN_t: dirtype = sign ? ptrdiff_type_node : unsigned_type_for (ptrdiff_type_node); break;
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #8 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #7) > case FMT_LEN_z: > dirtype = sign ? signed_type_for (size_type_node) : size_type_node; > break; > > case FMT_LEN_t: > dirtype = sign ? ptrdiff_type_node : unsigned_type_for > (ptrdiff_type_node); > break; Or maybe even better: dirtype = signed_or_unsigned_type_for (!sign, size_type_node); and dirtype = igned_or_unsigned_type_for (!sign, ptrdiff_type_node); sizeof (size_t) == sizeof (ptrdiff_t) can't be assumed. E.g. vms uses always 32-bit size_t, but either 32-bit or 64-bit ptrdiff_t.
[Bug fortran/60853] [OOP] Failure to disambiguate generic with unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60853 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug middle-end/78333] [5 Regression] always-inline gnu-inline functions break -finstrument-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78333 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #7 from Christophe Lyon --- We probably want to backport r242553 to the release branch(es), as otherwise gcc.dg/pr78333.c is failing on non-glibc systems. I can do it for the gcc-6 branch if you want. Regarding the gcc-5-branch, are you going to backport the whole series?
[Bug middle-end/71762] [5/6 Regression] ~X & Y to X < Y doesn't work for uninitialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #12 from Christophe Lyon --- It looks like you forgot to commit the gcc.dg/tree-ssa/forwprop-28.c part.
[Bug fortran/78505] New: [F08] Coarray source allocation not synchronizing on oversubscribed cores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505 Bug ID: 78505 Summary: [F08] Coarray source allocation not synchronizing on oversubscribed cores Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at sourceryinstitute dot org Target Milestone: --- The transcript below demonstrates that gfortran is not performing the synchronization required during the allocation of a coarray when the number of images exceeds the number of cores (8 images on 4 cores in the case below). I can't think of a way to test the allocate without "source=" because the coarray cannot be defined before the allocate and a definition of the coarray immediately after the allocate would happen asynchronously. The workaround is to add some form of synchronization (e.g., sync all) after the allocate, but requiring that does not conform with the standard. According to the discussion in OpenCoarrays issue #243 (https://github.com/sourceryinstitute/opencoarrays/issues/243#issuecomment-262638712), this is a compiler issue. $ cat source-allocation-not-syncing.f90 implicit none integer, allocatable :: f(:)[:] integer, parameter :: num_points=32 integer :: me,ni,my_num_points,neighbor_last_element me = this_image() if (mod(num_points,num_images())/=0) error stop "num_points not evenly divisible by num_images()" my_num_points = num_points/num_images() allocate( f(my_num_points)[*], source = 1 ) if (me>1) then neighbor_last_element = f(my_num_points)[me-1] if (neighbor_last_element /=1) print *,"Image ",me," gets ",neighbor_last_element end if end $ caf source-allocation-not-syncing.f90 $ cafrun -np 8 ./a.out Image5 gets0 $ cafrun -np 8 ./a.out Image3 gets0 Image5 gets0 $ caf --wraps caf wraps CAFC=/opt/mpich/3.1.4/gnu/7.0.0/bin/mpif90 $ /opt/mpich/3.1.4/gnu/7.0.0/bin/mpif90 --version GNU Fortran (GCC) 7.0.0 20160904 (experimental) ...
[Bug c++/78506] New: [c++1z] wrong value category for class decomposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78506
Bug ID: 78506
Summary: [c++1z] wrong value category for class decomposition
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
The spec and intent looks straightforward to me, i should be an lvalue.
//--
struct one {
int i;
};
int main()
{
auto&& [i] = one {};
// error: taking address of xvalue (rvalue reference)
&i;
}
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #9 from prathamesh3492 at gcc dot gnu.org --- Created attachment 40136 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40136&action=edit move ptrdiff_type_node initialization to build_common_tree_nodes Hi Richard, Thanks for the suggestion. I have attached untested patch for moving ptrdiff_type_node initialization to the build_common_tree_nodes. Does it look OK ? Validation in progress. Thanks, Prathamesh
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #10 from Jakub Jelinek --- Comment on attachment 40136 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40136 move ptrdiff_type_node initialization to build_common_tree_nodes So, what do you want to do for VRP in the vms case where size_t is unsigned int (32-bit) and ptrdiff_t is long long int (64-bit)? Shall we use VARYING range in that case, or 0 to SIZE_MAX / 2, something different? What about the hypothetical case where size_t would be larger than ptrdiff_t?
[Bug middle-end/71762] [5/6 Regression] ~X & Y to X < Y doesn't work for uninitialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762 --- Comment #13 from Richard Biener --- Author: rguenth Date: Thu Nov 24 09:45:01 2016 New Revision: 242822 URL: https://gcc.gnu.org/viewcvs?rev=242822&root=gcc&view=rev Log: 2016-11-23 Richard Biener PR middle-end/71762 * match.pd ((~X & Y) -> X < Y, (X & ~Y) -> Y < X, (~X | Y) -> X <= Y, (X | ~Y) -> Y <= X): Remove. * gcc.dg/torture/pr71762-1.c: New testcase. * gcc.dg/torture/pr71762-2.c: Likewise. * gcc.dg/torture/pr71762-3.c: Likewise. * gcc.dg/tree-ssa/forwprop-28.c: XFAIL. Modified: trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
[Bug middle-end/78333] [5 Regression] always-inline gnu-inline functions break -finstrument-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78333 --- Comment #8 from rguenther at suse dot de --- On Thu, 24 Nov 2016, clyon at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78333 > > Christophe Lyon changed: > >What|Removed |Added > > CC||clyon at gcc dot gnu.org > > --- Comment #7 from Christophe Lyon --- > We probably want to backport r242553 to the release branch(es), as otherwise > gcc.dg/pr78333.c is failing on non-glibc systems. > > I can do it for the gcc-6 branch if you want. Please do - I simply forgot about it, sorry. > Regarding the gcc-5-branch, are you going to backport the whole series? Probably not, only parts of it.
[Bug middle-end/71762] [5/6 Regression] ~X & Y to X < Y doesn't work for uninitialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762 --- Comment #14 from rguenther at suse dot de --- On Thu, 24 Nov 2016, clyon at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762 > > Christophe Lyon changed: > >What|Removed |Added > > CC||clyon at gcc dot gnu.org > > --- Comment #12 from Christophe Lyon --- > It looks like you forgot to commit the > gcc.dg/tree-ssa/forwprop-28.c part. Yeah, just noticed...
[Bug middle-end/78507] New: [7 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78507
Bug ID: 78507
Summary: [7 Regression] ICE: tree check: expected integer_type
or enumeral_type or boolean_type or real_type or
fixed_point_type, have pointer_type in
int_fits_type_p, at tree.c:9153
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
markus@x4 /tmp % cat StackMaps.ii
struct A {
template
int operator()(_Iterator1, _Iterator2);
};
struct B {
template
static _BI2 __copy_move_b(_BI1 p1, _BI2 p2) {
_BI1 a;
long b = p1 - a;
for (; b > 0; --b)
*--p2 = *--p1;
}
};
template
void __copy_move_backward_a(_BI1 p1, _BI2 p2) {
B::__copy_move_b(p1, p2);
}
template
void __copy_move_backward_a2(_BI1 p1, _BI2 p2) {
__copy_move_backward_a<0>(p1, p2);
}
template void move_backward(_BI1 p1, _BI2 p2) {
__copy_move_backward_a2<0>(p1, p2);
}
template
void __insertion_sort(_RandomAccessIterator, _Compare p2) {
for (_RandomAccessIterator c;; ++c)
if (p2(0, 0))
move_backward(c, c + 1);
}
template
void __final_insertion_sort(_RandomAccessIterator, _Compare p2) {
_RandomAccessIterator d;
__insertion_sort(d, p2);
}
template
void __sort(_RandomAccessIterator p1, _Compare p2) {
__final_insertion_sort(p1, p2);
}
template
void sort(_RandomAccessIterator, _RandomAccessIterator p2, _Compare) {
A e;
__sort(p2, e);
}
struct C {
struct D {
int DwarfRegNum;
};
int parseRegisterLiveOutMask() const;
};
int C::parseRegisterLiveOutMask() const {
D f, g;
sort(&f, &g, [] {});
}
markus@x4 /tmp % g++ -c -O3 StackMaps.ii
StackMaps.ii: In member function ‘int C::parseRegisterLiveOutMask() const’:
StackMaps.ii:51:5: internal compiler error: tree check: expected integer_type
or enumeral_type or boolean_type or real_type or fixed_point_type, have
pointer_type in int_fits_type_p, at tree.c:9153
int C::parseRegisterLiveOutMask() const {
^
0x101b69c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9815
0x102ea83 tree_check5(tree_node const*, char const*, int, char const*,
tree_code, tree_code, tree_code, tree_code, tree_code)
../../gcc/gcc/tree.h:3393
0x102ea83 int_fits_type_p(tree_node const*, tree_node const*)
../../gcc/gcc/tree.c:9153
0x117718f gimple_simplify_153
/var/tmp/gcc_build_dir/gcc/gimple-match.c:6868
0x117c41b gimple_simplify_COND_EXPR
/var/tmp/gcc_build_dir/gcc/gimple-match.c:66574
0x10f920d gimple_simplify
/var/tmp/gcc_build_dir/gcc/gimple-match.c:67679
0x10faaf8 gimple_resimplify3(gimple**, code_helper*, tree_node*, tree_node**,
tree_node* (*)(tree_node*))
../../gcc/gcc/gimple-match-head.c:223
0x11a6b85 gimple_simplify(gimple*, code_helper*, tree_node**, gimple**,
tree_node* (*)(tree_node*), tree_node* (*)(tree_node*))
../../gcc/gcc/gimple-match-head.c:692
0xadd520 fold_stmt_1
../../gcc/gcc/gimple-fold.c:4256
0xeadf49 execute
../../gcc/gcc/tree-ssa-forwprop.c:2391
Please submit a full bug report,
[Bug sanitizer/69278] Confusion option handling for -sanitize-recovery=alll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69278 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #12 from Martin Liška --- Final conclusion we made with Jakub is that we're not planning to add 'address' to -fsanitize-recover=all as it would break backwards compatibility. Looks the change done in LLVM was maybe unintended.
[Bug middle-end/78507] [7 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:9153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78507 Markus Trippelsdorf changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-24 CC||amker at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Started with r242750: commit 83c0fb434a2895d17dad003751a3cb88afafd298 Author: amker Date: Wed Nov 23 12:44:08 2016 + * fold-const.c (fold_cond_expr_with_comparison): Move simplification for A cmp C1 ? A : C2 to below, also simplify remaining code. * match.pd: Move and extend simplification from above to here: (cond (cmp (convert1? x) c1) (convert2? x) c2) -> (minmax (x c)). * tree-if-conv.c (ifcvt_follow_ssa_use_edges): New func. (predicate_scalar_phi): Call fold_stmt using the new valueize func.
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #11 from prathamesh3492 at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #10) > Comment on attachment 40136 [details] > move ptrdiff_type_node initialization to build_common_tree_nodes > > So, what do you want to do for VRP in the vms case where size_t is unsigned > int (32-bit) and ptrdiff_t is long long int (64-bit)? Shall we use VARYING > range in that case, or 0 to SIZE_MAX / 2, something different? > What about the hypothetical case where size_t would be larger than ptrdiff_t? For CFN_BUILT_IN_STRLEN, we have: tree type = TREE_TYPE (gimple_call_lhs (stmt)); tree max = vrp_val_max (ptrdiff_type_node); wide_int wmax = wi::to_wide (max, TYPE_PRECISION (TREE_TYPE (max))); tree range_min = build_zero_cst (type); tree range_max = wide_int_to_tree (type, wmax - 1); If ptrdiff_t > size_t, I suppose max would be truncated to PTRDIFF_MAX / 2, Since the type of range_max is type of lhs ? In ptrdiff_t < size_t, ah it would be incorrect to use upper bound as PTRDIFF_MAX -1 since the range could be [0, SSIZE_MAX - 1] ? So instead of PTRDIFF_MAX, I guess it would be better to set range to [0, max(signed_type_for (type) - 1] which would cover both cases. Ah I see this is what you suggested in comment 4, thanks! However regardless of this bug, should we be moving ptrdiff_type_node to middle-end ? As pointed out above lto/lto-lang.c has: ptrdiff_type_node = integer_type_node, which is probably incorrect. Thanks, Prathamesh
[Bug ipa/78309] [5/6 Regression] ICE: in get_hash, at ipa-icf.c:2124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78309 --- Comment #6 from Martin Liška --- Author: marxin Date: Thu Nov 24 10:12:24 2016 New Revision: 242824 URL: https://gcc.gnu.org/viewcvs?rev=242824&root=gcc&view=rev Log: Add sem_item::m_hash_set (PR ipa/78309) PR ipa/78309 * ipa-icf.c (void sem_item::set_hash): Update m_hash_set. (sem_function::get_hash): Use the new field. (sem_function::parse): Remove an argument from ctor. (sem_variable::parse): Likewise. (sem_variable::get_hash): Use the new field. (sem_item_optimizer::read_section): Use new ctor and set hash. * ipa-icf.h: _hash is removed from sem_item::sem_item, sem_variable::sem_variable, sem_function::sem_function. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/ipa-icf.c branches/gcc-5-branch/gcc/ipa-icf.h
[Bug middle-end/78507] [7 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:9153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78507 amker at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #2 from amker at gcc dot gnu.org --- Thanks for reporting, I will investigate.
[Bug pch/78508] New: valgrind error in gt_pch_note_object when compiling C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78508 Bug ID: 78508 Summary: valgrind error in gt_pch_note_object when compiling C++ Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I just tried a gcc trunk build with valgrind. Configure line was ../trunk/configure --prefix=/home/dcb/gcc/results.242818 \ --disable-bootstrap \ --disable-multilib \ --disable-werror \ --enable-checking=valgrind \ --enable-languages=c++ and the error is /home/dcb/gcc/working/./gcc/xgcc -shared-libgcc -B/home/dcb/gcc/working/./gcc -nostdinc++ -L/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/dcb/gcc/results.242818/x86_64-pc-linux-gnu/bin/ -B/home/dcb/gcc/results.242818/x86_64-pc-linux-gnu/lib/ -isystem /home/dcb/gcc/results.242818/x86_64-pc-linux-gnu/include -isystem /home/dcb/gcc/results.242818/x86_64-pc-linux-gnu/sys-include-x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE -I/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/dcb/gcc/trunk/libstdc++-v3/libsupc++ -O2 -g /home/dcb/gcc/trunk/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch ==21389== Invalid read of size 1 ==21389==at 0x4C30BC4: strlen (vg_replace_strmem.c:454) ==21389==by 0x8DBCE8: gt_pch_note_object(void*, void*, void (*)(void*, void*, void (*)(void*, void*), void*)) (ggc-common.c:285) ==21389==by 0x82C1DA: gt_pch_nx (vec.h:1128) ==21389==by 0x82C1DA: gt_pch_nx_vec_dw_attr_node_va_gc_(void*) (gt-dwarf2out.h:908)
[Bug middle-end/78507] [7 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:9153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78507 --- Comment #3 from Richard Biener --- Indeed int_fits_type_p requires an integral type.
[Bug middle-end/78507] [7 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:9153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78507 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |7.0
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #12 from Jakub Jelinek --- Or perhaps check ptrdiff_type_node != NULL && TYPE_PRECISION (ptrdiff_type_node) == TYPE_PRECISION (size_type_node) before trying to optimize this? I mean, on VMS it might be fine if strlen returns 0xfffe (maximum size_t minus 1), if the address space is 64-bit and so is ptrdiff_t. So the above would only optimize on sane targets. The other uses of ptrdiff_type_node in the middle-end, which need fixing anyway, would need something like your patch, but not sure if it is not a waste of time to compute it if the C/C++ FE will immediately override it anyway. So perhaps just compute it that way in the LTO FE? I mean, for the *printf warning/length stuff, those calls shouldn't appear in Ada/Go/Fortran code, they can in LTO or C-family. The gimple-ssa-sprintf.c code could just check if ptrdiff_type_node is non-NULL and if it is NULL, punt.
[Bug ipa/78309] [5/6 Regression] ICE: in get_hash, at ipa-icf.c:2124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78309 --- Comment #7 from Martin Liška --- Author: marxin Date: Thu Nov 24 10:19:22 2016 New Revision: 242825 URL: https://gcc.gnu.org/viewcvs?rev=242825&root=gcc&view=rev Log: Add sem_item::m_hash_set (PR ipa/78309) Backported from mainline 2016-11-22 Martin Liska PR ipa/78309 * ipa-icf.c (void sem_item::set_hash): Update m_hash_set. (sem_function::get_hash): Use the new field. (sem_function::parse): Remove an argument from ctor. (sem_variable::parse): Likewise. (sem_variable::get_hash): Use the new field. (sem_item_optimizer::read_section): Use new ctor and set hash. * ipa-icf.h: _hash is removed from sem_item::sem_item, sem_variable::sem_variable, sem_function::sem_function. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/ipa-icf.c branches/gcc-6-branch/gcc/ipa-icf.h
[Bug ipa/78309] [5/6 Regression] ICE: in get_hash, at ipa-icf.c:2124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78309 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Fixed on all active branches.
[Bug c++/77591] [6/7 Regression] decltype(auto) and ternary operator allow returning local reference without a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77591 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Indeed, this started with r230365.
[Bug middle-end/78509] New: [7 regression] ICE in in excess_precision_type, at tree.c:8875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509 Bug ID: 78509 Summary: [7 regression] ICE in in excess_precision_type, at tree.c:8875 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.12 Target: i386-pc-solaris2.12 Build: i386-pc-solaris2.12 Between 20161122 (r242728) and 20161123 (r242800), man AVX etc. tests started to FAIL for 32-bit Solaris/x86: +FAIL: gcc.target/i386/avx-cmpsd-1.c (internal compiler error) +FAIL: gcc.target/i386/avx-cmpsd-1.c (test for excess errors) +WARNING: gcc.target/i386/avx-cmpsd-1.c compilation failed to produce executable +FAIL: gcc.target/i386/avx-cmpss-1.c (internal compiler error) +FAIL: gcc.target/i386/avx-cmpss-1.c (test for excess errors) +WARNING: gcc.target/i386/avx-cmpss-1.c compilation failed to produce executable +FAIL: gcc.target/i386/avx-vcmppd-1.c (internal compiler error) +FAIL: gcc.target/i386/avx-vcmppd-1.c (test for excess errors) +WARNING: gcc.target/i386/avx-vcmppd-1.c compilation failed to produce executabl e +FAIL: gcc.target/i386/avx-vcmppd-256-1.c (internal compiler error) +FAIL: gcc.target/i386/avx-vcmppd-256-1.c (test for excess errors) +WARNING: gcc.target/i386/avx-vcmppd-256-1.c compilation failed to produce executable +FAIL: gcc.target/i386/avx-vcmpps-1.c (internal compiler error) +FAIL: gcc.target/i386/avx-vcmpps-1.c (test for excess errors) +WARNING: gcc.target/i386/avx-vcmpps-1.c compilation failed to produce executabl e +FAIL: gcc.target/i386/avx-vcmpps-256-1.c (internal compiler error) +FAIL: gcc.target/i386/avx-vcmpps-256-1.c (test for excess errors) +WARNING: gcc.target/i386/avx-vcmpps-256-1.c compilation failed to produce execu table +FAIL: gcc.target/i386/avx-vcmpsd-1.c (internal compiler error) +FAIL: gcc.target/i386/avx-vcmpsd-1.c (test for excess errors) +WARNING: gcc.target/i386/avx-vcmpsd-1.c compilation failed to produce executabl e +FAIL: gcc.target/i386/avx-vcmpss-1.c (internal compiler error) +FAIL: gcc.target/i386/avx-vcmpss-1.c (test for excess errors) +WARNING: gcc.target/i386/avx-vcmpss-1.c compilation failed to produce executabl e +FAIL: gcc.target/i386/avx512f-vcmppd-2.c (internal compiler error) +FAIL: gcc.target/i386/avx512f-vcmppd-2.c (test for excess errors) +WARNING: gcc.target/i386/avx512f-vcmppd-2.c compilation failed to produce execu table Excess errors: /var/gcc/regression/trunk/12-gcc/build/gcc/include/avx512bwintrin.h:443:3: internal compiler error: in excess_precision_type, at tree.c:8875 0x90386fc excess_precision_type(tree_node*) /vol/gcc/src/hg/trunk/local/gcc/tree.c:8875 0x88b08aa build_binary_op(unsigned int, tree_code, tree_node*, tree_node*, int) /vol/gcc/src/hg/trunk/local/gcc/c/c-typeck.c:10822 0x88b841a parser_build_binary_op(unsigned int, tree_code, c_expr, c_expr) /vol/gcc/src/hg/trunk/local/gcc/c/c-typeck.c:3617 0x88d1db3 c_parser_binary_expression /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:6778 0x88d223b c_parser_conditional_expression /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:6418 0x88d2998 c_parser_expr_no_commas /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:6335 0x88d2bf7 c_parser_expression /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:8553 0x88c5066 c_parser_postfix_expression /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:7659 0x88d04f1 c_parser_unary_expression /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:7009 0x88d1315 c_parser_cast_expression /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:6841 0x88d1401 c_parser_cast_expression /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:6830 0x88d1534 c_parser_binary_expression /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:6650 0x88d223b c_parser_conditional_expression /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:6418 0x88d2998 c_parser_expr_no_commas /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:6335 0x88d2bf7 c_parser_expression /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:8553 0x88d536c c_parser_expression_conv /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:8586 0x88e8dec c_parser_statement_after_labels /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:5257 0x88ea5e8 c_parser_compound_statement_nostart /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:4867 0x88ead00 c_parser_compound_statement /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:4700 0x88e6490 c_parser_declaration_or_fndef /vol/gcc/src/hg/trunk/local/gcc/c/c-parser.c:2085 and many more Rainer
[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509 Rainer Orth changed: What|Removed |Added Target Milestone|--- |7.0
[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509 Rainer Orth changed: What|Removed |Added CC||jgreenhalgh at gcc dot gnu.org --- Comment #1 from Rainer Orth --- James, this is caused by your patch series [Patch 1/17] Add a new target hook for describing excess precision intentions I believe. Rainer
[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509 --- Comment #2 from James Greenhalgh --- (In reply to Rainer Orth from comment #1) > James, this is caused by your patch series > > [Patch 1/17] Add a new target hook for describing excess precision intentions > > I believe. > > Rainer Thanks, and sorry for the break. Can you help me out with a configure line that would get me to a stage 1 solaris/x32 compiler so I can debug this?
[Bug tree-optimization/78343] [6/7 Regression] Loop is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78343 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Testing a patch.
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #13 from prathamesh3492 at gcc dot gnu.org --- Created attachment 40137 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40137&action=edit check precision of ptrdiff_type_node and lhs type is equal Hi Jakub, Thanks for the suggestion. Does this patch (stage-1 built) look OK ? However the tests pr78153-1.c and pr78153-2.c are bound to fail if type_precision (ptrdiff_t) != type_precision (size_t). What effective target check should I add to skip the test for targets like VMS where the precisions would be different ? Thanks, Prathamesh
[Bug c++/77591] [6/7 Regression] decltype(auto) and ternary operator allow returning local reference without a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77591 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 40138 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40138&action=edit gcc7-pr77591.patch Untested fix.
[Bug middle-end/31096] a*C == b*C where C is a constant is not optimized to a == b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096 hs.naveen2u at gmail dot com changed: What|Removed |Added CC||hs.naveen2u at gmail dot com --- Comment #3 from hs.naveen2u at gmail dot com --- https://gcc.gnu.org/ml/gcc-cvs/2016-11/msg01019.html
[Bug testsuite/77635] load/store pair testcases need to use -mcpu=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77635 hs.naveen2u at gmail dot com changed: What|Removed |Added CC||hs.naveen2u at gmail dot com --- Comment #1 from hs.naveen2u at gmail dot com --- Fixed. https://gcc.gnu.org/ml/gcc-cvs/2016-11/msg01102.html
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501
--- Comment #14 from Jakub Jelinek ---
Comment on attachment 40137
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40137
check precision of ptrdiff_type_node and lhs type is equal
Formatting is wrong. && should not be at the end of line, and as the condition
doesn't fit on one line, each subcondition should be on a separate line.
Also, the outer {} look ugly. Perhaps:
case CFN_BUILT_IN_STRLEN:
if (tree lhs = gimple_call_lhs (stmt))
if (ptrdiff_type_node
&& TYPE_PRECISION (ptrdiff_type_node) == TYPE_PRECISION (TREE_TYPE
(lhs)))
{
...
return;
}
break;
?
[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from James Greenhalgh --- > Thanks, and sorry for the break. No worries: as long as the thing still bootstraps ;-) > Can you help me out with a configure line that would get me to a stage 1 > solaris/x32 compiler so I can debug this? I suspect there's nothing Solaris specific here, but that you'd see the same failures in either an i686-pc-linux-gnu or an x86_64-pc-linux-gnu compiler with -m32. However, I don't believe you'll need more for a Solaris/x86 cross but --target i386-pc-solaris2.11 and (though unlikely) cross-binutils configured the same way. Rainer
[Bug c/78510] New: ice on invalid C code at -O2 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78510
Bug ID: 78510
Summary: ice on invalid C code at -O2 and above in both 32-bit
and 64-bit modes on x86_64-linux-gnu (internal
compiler error: verify_gimple failed)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161124 (experimental) [trunk revision 242818] (GCC)
$
$ gcc-trunk -O3 small.c
small.c: In function ‘main’:
small.c:17:5: error: type mismatch in conditional expression
int main() { fn2(); return 0; }
^~~~
short int
int
short int
iftmp.1_11 = _6 == 4 ? 4 : 0;
small.c:17:5: internal compiler error: verify_gimple failed
0xc317f6 verify_gimple_in_cfg(function*, bool)
../../gcc-source-trunk/gcc/tree-cfg.c:5258
0xb0f84a execute_function_todo
../../gcc-source-trunk/gcc/passes.c:1965
0xb10285 execute_todo
../../gcc-source-trunk/gcc/passes.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$ cat small.c
int a, b, c, e, f;
char d;
short g, h;
char fn1(int p1) {
for (;;) {
h = p1 << 2;
int i = h;
g = i > 32767 >> 13 ? i : i << 3;
f = a ?: c;
if (e)
return d;
}
}
static int fn2() { fn1(0 || b); }
int main() { fn2(); return 0; }
[Bug testsuite/77634] some vectorized testcases fail with -mcpu=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77634 hs.naveen2u at gmail dot com changed: What|Removed |Added CC||hs.naveen2u at gmail dot com --- Comment #1 from hs.naveen2u at gmail dot com --- Fixed. https://gcc.gnu.org/ml/gcc-cvs/2016-11/msg01096.html
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #15 from Jakub Jelinek --- For the tests, I think they would just pass on VMS. In one case you are comparing if 0x7fffULL <= (unsigned int) something, that is for 32-bit int clearly never true and should be folded. And in the other case, you are assigning 32-bit unsigned value into 64-bit signed var and then testing if it is negative, again, that is never true.
[Bug c++/77581] [5/6/7 Regression] ICE: instantiate_template_1, cp/pt.c:17391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77581 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Known to work|5.4.0 | Summary|[6/7 Regression] ICE: |[5/6/7 Regression] ICE: |instantiate_template_1, |instantiate_template_1, |cp/pt.c:17391 |cp/pt.c:17391 --- Comment #2 from Jakub Jelinek --- Started to ICE with r192448 (before that it has been rejected, because C++11 inheriting ctors weren't supported.
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #16 from prathamesh3492 at gcc dot gnu.org --- Created attachment 40139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40139&action=edit fix formatting of patch in comment 13 Done formatting changes in this version. Does it look OK ? Thanks, Prathamesh
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #17 from prathamesh3492 at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #15) > For the tests, I think they would just pass on VMS. In one case you are > comparing if 0x7fffULL <= (unsigned int) something, that is for > 32-bit int clearly never true and should be folded. And in the other case, > you are assigning 32-bit unsigned value into 64-bit signed var and then > testing if it is negative, again, that is never true. Ah right, thanks for pointing it out! Regards, Prathamesh
[Bug driver/77497] [5/6/7 Regression] Setting DWARF level and debug level together has flag-ordering-dependent results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77497 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- Still I'd classify the change as intentational, -gdwarf-N isn't unrelated option to -gN, but implies -g2 unless the level is already -g3.
[Bug middle-end/78507] [7 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:9153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78507 --- Comment #4 from amker at gcc dot gnu.org --- Types of @2/@3 are guarded by INTEGER_CST@2/INTEGER_CST@3, but type of @1 is not checked. Should check INTEGRAL_TYPE_P for it before calling int_fits_type_p.
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #18 from Jakub Jelinek --- Comment on attachment 40139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40139 fix formatting of patch in comment 13 LGTM.
[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509
James Greenhalgh changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2016-11-24
Assignee|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #4 from James Greenhalgh ---
Well, certainly this comment and assert in tree.c:
/* The target should not ask for unpredictable float evaluation (though
it might advertise that implicitly the evaluation is unpredictable,
but we don't care about that here, it will have been reported
elsewhere). If it does ask for unpredictable evaluation, we have
nothing to do here. */
gcc_assert (target_flt_eval_method != FLT_EVAL_METHOD_UNPREDICTABLE);
Suggest that the implementation I've put in for TARGET_C_EXCESS_PRECISION on
i386 is wrong (or the assert needs to be weakened).
static enum flt_eval_method
ix86_excess_precision (enum excess_precision_type type)
{
switch (type)
{
case EXCESS_PRECISION_TYPE_FAST:
/* The fastest type to promote to will always be the native type,
whether that occurs with implicit excess precision or
otherwise. */
return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
case EXCESS_PRECISION_TYPE_STANDARD:
case EXCESS_PRECISION_TYPE_IMPLICIT:
/* Otherwise, the excess precision we want when we are
in a standards compliant mode, and the implicit precision we
provide can be identical. */
if (!TARGET_80387)
return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
else if (TARGET_MIX_SSE_I387)
return FLT_EVAL_METHOD_UNPREDICTABLE;
else if (!TARGET_SSE_MATH)
return FLT_EVAL_METHOD_PROMOTE_TO_LONG_DOUBLE;
else if (TARGET_SSE2)
return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
else
return FLT_EVAL_METHOD_UNPREDICTABLE;
default:
gcc_unreachable ();
}
return FLT_EVAL_METHOD_UNPREDICTABLE;
}
I think the right fix is probably to return FLT_METHOD_PROMOTE_TO_FLOAT for
EXCESS_PRECISION_TYPE_STANDARD, but I'll need to think about that.
Sorry again for the break, by inspection it is obvious how you hit that assert.
[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65496
Zdenek Sojka changed:
What|Removed |Added
Known to fail||7.0
--- Comment #4 from Zdenek Sojka ---
Another testcase:
$ cat testcase.c
int c;
__int128 x;
void
foo ()
{
if (c)
x /= 5;
}
$ powerpc64-unknown-linux-gnu-gcc -O2 -fsched2-use-superblocks -g
--param=max-pending-list-length=0 testcase.c
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2328
}
^
0x78d4b0 maybe_record_trace_start
/repo/gcc-trunk/gcc/dwarf2cfi.c:2328
0x78e360 scan_trace
/repo/gcc-trunk/gcc/dwarf2cfi.c:2510
0x78ebca create_cfi_notes
/repo/gcc-trunk/gcc/dwarf2cfi.c:2664
0x78ebca execute_dwarf2_frame
/repo/gcc-trunk/gcc/dwarf2cfi.c:3022
0x78ebca execute
/repo/gcc-trunk/gcc/dwarf2cfi.c:3502
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug middle-end/78501] [7 regression] SEGV in vrp_val_max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78501 --- Comment #19 from prathamesh3492 at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #18) > Comment on attachment 40139 [details] > fix formatting of patch in comment 13 > > LGTM. Thanks, I have started bootstrap on x86_64-unknown-linux-gnu with --enable-languages=all,ada and will post it on patches list after the build completes. Thanks, Prathamesh
[Bug c/78510] [7 Regression] ICE on invalid C code at -O2 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78510 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-24 CC||amker.cheng at gmail dot com, ||marxin at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ice on invalid C code at|[7 Regression] ICE on |-O2 and above in both |invalid C code at -O2 and |32-bit and 64-bit modes on |above in both 32-bit and |x86_64-linux-gnu (internal |64-bit modes on |compiler error: |x86_64-linux-gnu (internal |verify_gimple failed) |compiler error: ||verify_gimple failed) Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r242751.
[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- I guess you should look at what the compiler did before your changes in these cases (mixed sse and i387 e.g.) and match that in the new hook.
[Bug bootstrap/78493] profiledbootstrap failure: error: attempt to free a non-heap object 'names' in ../../gcc/cp/parser.c:11482:23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78493 --- Comment #2 from Martin Liška --- Author: marxin Date: Thu Nov 24 11:26:12 2016 New Revision: 242828 URL: https://gcc.gnu.org/viewcvs?rev=242828&root=gcc&view=rev Log: cp_parser_range_for: use safe_push instead of quick_push (PR PR bootstrap/78493 * parser.c (cp_parser_range_for): Use safe_push instead of quick_push. PR bootstrap/78493 * g++.dg/cpp1z/decomp18.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/decomp18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c/78510] [7 Regression] ICE on invalid C code at -O2 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78510 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #2 from amker at gcc dot gnu.org --- Mine, I will investigate. Thanks.
[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509 --- Comment #6 from James Greenhalgh --- None of the logic was there in the original code, so there is not much to compare. The question for the backend when TYPE is EXCESS_PRECISION_TYPE_FAST or EXCESS_PRECISION_TYPE_STANDARD is, does it wants tree.c to insert operations to guarantee explicit excess precision for the types, or does it wants tree.c to keep them as their native types. The assert exists because it makes no sense to ask the front-end to explicitly make the operations unpredictable. The fix which most closely maps to the semantics I think i386 wants is... For EXCESS_PRECISION_TYPE_FAST: Always return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT For EXCESS_PRECISION_TYPE_STANDARD: If we're in a mode which should never promote, or we're in a mode which will be implicitly unpredictable, return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT If we're in the mode which should explicitly promote to LONG_DOUBLE, do that. For EXCESS_PRECISION_TYPE_IMPLICIT: Keep the current logic. I'll write a patch along those lines, and test it as well as I can, but I don't really know how to get good -m32 testing out of my x86_64 box, which doesn't have a good multilib environment set up. If you can point me at a machine in the compile farm I can use I'd be happy to test more extensively.
[Bug middle-end/78429] [6/7 Regression] ICE in set_value_range, at tree-vrp.c on non-standard boolean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 --- Comment #17 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 24 12:02:53 2016 New Revision: 242829 URL: https://gcc.gnu.org/viewcvs?rev=242829&root=gcc&view=rev Log: PR middle-end/78429 * tree.h (wi::fits_to_boolean_p): New predicate. (wi::fits_to_tree_p): Use it for boolean types. * tree.c (int_fits_type_p): Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20161124-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h
[Bug middle-end/78429] [6/7 Regression] ICE in set_value_range, at tree-vrp.c on non-standard boolean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 --- Comment #18 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 24 12:05:40 2016 New Revision: 242830 URL: https://gcc.gnu.org/viewcvs?rev=242830&root=gcc&view=rev Log: PR middle-end/78429 * tree.h (wi::fits_to_boolean_p): New predicate. (wi::fits_to_tree_p): Use it for boolean types. * tree.c (int_fits_type_p): Likewise. Added: branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/compile/20161124-1.c - copied unchanged from r242829, trunk/gcc/testsuite/gcc.c-torture/compile/20161124-1.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree.c branches/gcc-6-branch/gcc/tree.h
[Bug middle-end/78429] [6/7 Regression] ICE in set_value_range, at tree-vrp.c on non-standard boolean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78429 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Eric Botcazou --- Thanks for reporting the problem.
[Bug target/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509
--- Comment #7 from Jakub Jelinek ---
(In reply to James Greenhalgh from comment #6)
> None of the logic was there in the original code, so there is not much to
> compare.
?? Since -fexcess-precision=standard has been introduced, gcc has the excess
precision notion. So there is something to compare.
E.g. try
float foo (float x, float y, float z)
{
return x + y + z;
}
before your changes with
-fdump-tree-gimple -m32 -msse2 -mno-80387 -fexcess-precision=standard
-fdump-tree-gimple -m32 -msse2 -mfpmath=387+sse -fexcess-precision=standard
-fdump-tree-gimple -m32 -msse2 -mfpmath=387 -fexcess-precision=standard
-fdump-tree-gimple -m32 -msse2 -mfpmath=sse -fexcess-precision=standard
-fdump-tree-gimple -m32 -msse -mno-sse2 -mfpmath=sse
-fexcess-precision=standard
to match the different cases in your hook, and compare that to what you get
with the current trunk.
[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120 --- Comment #10 from Bernd Schmidt --- Author: bernds Date: Thu Nov 24 12:16:47 2016 New Revision: 242832 URL: https://gcc.gnu.org/viewcvs?rev=242832&root=gcc&view=rev Log: PR rtl-optimization/78120 * config/i386/i386.c (ix86_rtx_costs): Fully handle SETs. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120 --- Comment #11 from Bernd Schmidt --- Author: bernds Date: Thu Nov 24 12:17:52 2016 New Revision: 242833 URL: https://gcc.gnu.org/viewcvs?rev=242833&root=gcc&view=rev Log: PR rtl-optimization/78120 * rtlanal.c (insn_rtx_cost): Use set_rtx_cost. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c
[Bug tree-optimization/71595] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71595 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120 --- Comment #12 from Bernd Schmidt --- Author: bernds Date: Thu Nov 24 12:22:16 2016 New Revision: 242834 URL: https://gcc.gnu.org/viewcvs?rev=242834&root=gcc&view=rev Log: PR rtl-optimization/78120 * ifcvt.c (noce_conversion_profitable_p): Check original cost in all cases, and additionally test against max_seq_cost for speed optimization. (noce_process_if_block): Compute an estimate for the original cost when optimizing for speed, using the minimum of then and else block costs. testsuite/ PR rtl-optimization/78120 * gcc.target/i386/pr78120.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr78120.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/71595] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71595 --- Comment #8 from Richard Biener --- Author: rguenth Date: Thu Nov 24 12:25:22 2016 New Revision: 242835 URL: https://gcc.gnu.org/viewcvs?rev=242835&root=gcc&view=rev Log: 2016-11-24 Richard Biener PR tree-optimization/71595 * cfgloopmanip.h (remove_path): Add irred_invalidated and loop_closed_ssa_invalidated parameters, defaulted to NULL. * cfgloopmanip.c (remove_path): Likewise, pass them along to called functions. Only fix irred flags if the caller didn't request state. * tree-ssa-loop-ivcanon.c (unloop_loops): Use add_bb_to_loop. (unloop_loops): Pass irred_invalidated and loop_closed_ssa_invalidated to remove_path. * gcc.dg/torture/pr71595.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr71595.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloopmanip.c trunk/gcc/cfgloopmanip.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c
[Bug target/78012] -mfpxx produces assembly code using odd FP registers on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78012 Maciej W. Rozycki changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-24 Ever confirmed|0 |1
[Bug target/78460] [7 Regression] [SH] OOM building glibc string tst-cmp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #2 from Oleg Endo --- (In reply to Martin Liška from comment #1) > > Apart from that, I wondering why there's no limit, as for instance: > strncmp (left, right, 1000); emits battalion of instructions. Oh yeah, that's PR 67712.
[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Oleg Endo --- (In reply to Oleg Endo from comment #6) > (In reply to DJ Delorie from comment #4) > > Perhaps you need this patch: > > > > https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00993.html > > DJ, did you actually commit that patch? Just checked the source. That patch went in as r216844. Closing the issue as fixed.
[Bug c++/78511] New: ICE on using concept name as a "requires" parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78511
Bug ID: 78511
Summary: ICE on using concept name as a "requires" parameter
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at minijackson dot 33mail.com
Target Milestone: ---
GCC version and system:
gcc (Gentoo 6.2.0-r1 p1.1) 6.2.0
Compilation options:
-altivec -awt -cilk cxx -debug -doc -fixed-point fortran gcj -go -graphite
-hardened -jit -libssp -mpx multilib nls nptl -objc -objc++ -objc-gc openmp pch
-pie -regression-test sanitize -ssp -vanilla vtv
Example program (test.cpp):
template
concept bool A = true;
template
concept bool B = requires(A a) {
a;
}
Command line:
g++ -fconcepts -std=c++1z test.cpp
Error:
test.cpp:5:27: internal compiler error: in synthesize_implicit_template_parm,
at cp/parser.c:37866
concept bool B = requires(A a) {
^
test.ii generated file:
# 1 "test.cpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test.cpp"
template
concept bool A = true;
template
concept bool B = requires(A a) {
a;
}
[Bug c++/78282] [6/7 Regression] Overload resolution failure, in parameter pack expansion, inside a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78282 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This is rejected since r229722.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #56 from Jakub Jelinek --- So, is this resolved now?
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #57 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #56 from Jakub Jelinek --- > So, is this resolved now? The bootstrap failures are AFAIK, but perhaps we should keep it open for the fixinclude fix backports discovered? Rainer
[Bug pch/78508] valgrind error in gt_pch_note_object when compiling C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78508 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-24 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, I'll try to reduce that, but I guess it would take ages. Let's see.
[Bug target/70118] UBSan claims misaligned access in SSE instrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118 Allan Jensen changed: What|Removed |Added Attachment #40130|0 |1 is obsolete|| --- Comment #5 from Allan Jensen --- Created attachment 40140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40140&action=edit Patch Updated patch confirmed to work
[Bug c/78408] C loop initial declarations generate wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> Note in the testcase a = (struct buf) {}, b = (struct buf) {} generates
> significantly more efficient code than a = b = (struct buf) {} - the former
> is 2x memset, the latter 1x memset + 1x memcpy.
> So, shall we for large aggregates gimplify those differently as an
> optimization?
I believe the gimplifier is not a good place to do optimization. You can
pattern-match
memset (&a, ..., N);
memcpy (&b, &a, N);
and transform it to two times memset.
[Bug c/78408] C loop initial declarations generate wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408
--- Comment #11 from Jakub Jelinek ---
(In reply to Richard Biener from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > Note in the testcase a = (struct buf) {}, b = (struct buf) {} generates
> > significantly more efficient code than a = b = (struct buf) {} - the former
> > is 2x memset, the latter 1x memset + 1x memcpy.
> > So, shall we for large aggregates gimplify those differently as an
> > optimization?
>
> I believe the gimplifier is not a good place to do optimization. You can
> pattern-match
>
> memset (&a, ..., N);
> memcpy (&b, &a, N);
>
> and transform it to two times memset.
Even the *.optimized dump contains:
b = {};
a = b;
d = {};
c = d;
Can match.pd handle these, or would it need to be special folding code (where?
gimple-fold.c, tree dse, what other passes have good framework for that)?
[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from Dominik Vogt --- > Some things to try with reduction-10.c: > > 1) Remove all OMP pragmas from the code. If it still fails it's not a > limbgomp > bug. The failure goes away if I do this... > 2) Replace "p7" in foo with just "7". If it still fails we know the bug is > not > triggered by the dynamic allocation of a or b. ... but stays this way. Rainer
[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #10 from Rainer Orth --- Created attachment 40141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40141&action=edit reduced testcase and assembler output I've managed at least some reduction of the testcase: as you can see, one stack allocation is reduced, the other has vanished completely. Rainer
[Bug c/78512] New: [7 Regression] r242674 miscompiles Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 Bug ID: 78512 Summary: [7 Regression] r242674 miscompiles Linux kernel Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Since r242674 the Linux kernel hits a BUG() during boot: Kernel bug at net/core/skbuff.c:105 invalid opcode ... Adding -fno-printf-return-value to the CFLAGS "solves" the issue. Not sure which file gets miscompiled, I only did a quick gcc bisection.
[Bug bootstrap/78493] profiledbootstrap failure: error: attempt to free a non-heap object 'names' in ../../gcc/cp/parser.c:11482:23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78493 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug middle-end/78153] strlen return value can be assumed to be less than PTRDIFF_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78153 --- Comment #2 from Andreas Schwab --- This breaks ada on aarch64: /opt/gcc/gcc-20161124/Build/./prev-gcc/xgcc -B/opt/gcc/gcc-20161124/Build/./prev-gcc/ -B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem /usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include -c -g -O2 -gtoggle -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -I../../gcc/ada -I../../gcc/ada/gcc-interface ../../gcc/ada/osint.adb -o ada/osint.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[3]: *** [../../gcc/ada/gcc-interface/Make-lang.in:119: ada/osint.o] Error 1
[Bug rtl-optimization/78437] [7 Regression] invalid sign-extend conversion in REE pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78437 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 24 15:01:32 2016 New Revision: 242839 URL: https://gcc.gnu.org/viewcvs?rev=242839&root=gcc&view=rev Log: PR rtl-optimization/78437 * ree.c (get_uses): New function. (combine_reaching_defs): When a copy is needed, return false if any reaching use of the source register reads it in a mode larger than the mode it is set in and WORD_REGISTER_OPERATIONS is true. Modified: trunk/gcc/ChangeLog trunk/gcc/ree.c
[Bug rtl-optimization/78437] [7 Regression] invalid sign-extend conversion in REE pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78437 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Botcazou --- Thanks for distilling the reduced testcase.
[Bug middle-end/78153] strlen return value can be assumed to be less than PTRDIFF_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78153 --- Comment #3 from Andreas Schwab --- Program received signal SIGSEGV, Segmentation fault. vrp_val_max (type=0x0) at ../../gcc/tree-vrp.c:156 156 if (!INTEGRAL_TYPE_P (type))
[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #11 from Dominik Vogt --- (In reply to r...@cebitec.uni-bielefeld.de from comment #9) > > 2) Replace "p7" in foo with just "7". If it still fails we know the bug is > > not > > triggered by the dynamic allocation of a or b. > > ... but stays this way. Good, the assembly diff has shrunk a lot: -- @@ -8,7 +8,7 @@ ld [%i0+4], %g4 add %g4, 1, %i3 sll %i3, 2, %g1 - add %g1, 10, %g1 + add %g1, 7, %g1 <--- add (8 - 1) bytes and %g1, -8, %g1<--- round down to multiple of 8 mov 0, %g2 sub %sp, %g1, %sp @@ -25,7 +25,6 @@ add%g1, 4, %g1 add %g3, 1, %i2 sll %i2, 3, %g1 - add %g1, 8, %g1 < -- what was this good for? mov 0, %g2 sub %sp, %g1, %sp add %sp, 96, %i5 -- The marked instructions in the first chunk do look like the calculations of the dynamic stack area's address. The reduced source code does not have dynamic stack allocation, so that must come from libgomp. The next step is to figure out how libgomp generates instructions. Can you provide tree dumps for both Gccs?
[Bug sanitizer/78513] New: [7 Regression] Failure to build linux kernel with KASAN support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78513 Bug ID: 78513 Summary: [7 Regression] Failure to build linux kernel with KASAN support Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- I'm trying to build the Linux kernel 4.8.10, downloaded from kernel.org using an aarch64-none-linux-gnu trunk toolchain (r242837). I'm building a defconfig kernel with the additional: CONFIG_KASAN=y CONFIG_KASAN_OUTLINE=y in the .config file to enable KASAN. This works with a GCC 6 compiler. With trunk this fails to link with many undefined references, for example: net/built-in.o: In function `ethtool_set_per_queue': ncsi-manage.c:(.text+0x5e2a8): undefined reference to `__asan_unpoison_stack_memory' ncsi-manage.c:(.text+0x5e398): undefined reference to `__asan_poison_stack_memory' I guess this has something to do with the libsanitizer merge?
[Bug sanitizer/78513] [7 Regression] Failure to build linux kernel with KASAN support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78513 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||link-failure Target||aarch64-none-linux-gnu Known to work||6.2.1 Target Milestone|--- |7.0 Known to fail||7.0
[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |7.0
[Bug inline-asm/70184] Explicit register variables holding function arguments overwritten by conversion libcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70184 --- Comment #8 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Nov 24 15:22:34 2016 New Revision: 242840 URL: https://gcc.gnu.org/viewcvs?rev=242840&root=gcc&view=rev Log: [TER] PR target/48863 : Don't replace expressions across local register variable definitions PR target/48863 PR inline-asm/70184 * tree-ssa-ter.c (temp_expr_table): Add reg_vars_cnt field. (new_temp_expr_table): Initialise reg_vars_cnt. (free_temp_expr_table): Release reg_vars_cnt. (process_replaceable): Add reg_vars_cnt argument, set reg_vars_cnt field of TAB. (find_replaceable_in_bb): Use the above to record register variable write occurrences and cancel replacement across them. * gcc.target/arm/pr48863.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr48863.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ter.c
[Bug target/48863] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48863 --- Comment #6 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Nov 24 15:22:34 2016 New Revision: 242840 URL: https://gcc.gnu.org/viewcvs?rev=242840&root=gcc&view=rev Log: [TER] PR target/48863 : Don't replace expressions across local register variable definitions PR target/48863 PR inline-asm/70184 * tree-ssa-ter.c (temp_expr_table): Add reg_vars_cnt field. (new_temp_expr_table): Initialise reg_vars_cnt. (free_temp_expr_table): Release reg_vars_cnt. (process_replaceable): Add reg_vars_cnt argument, set reg_vars_cnt field of TAB. (find_replaceable_in_bb): Use the above to record register variable write occurrences and cancel replacement across them. * gcc.target/arm/pr48863.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr48863.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ter.c
[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 rdapp at linux dot vnet.ibm.com changed: What|Removed |Added CC||rdapp at linux dot vnet.ibm.com --- Comment #12 from rdapp at linux dot vnet.ibm.com --- (Writing from a colleagues machine ...) Thinking about it, I'm quite sure the dynamic allocation must come from here: > #pragma omp parallel for reduction(*:y[:p4]) reduction(|:a[:p5]) ^^ ^^ I.e. the bug should go awaz if you replace either p4 or p5 or both with the numeric values. Dominik ^_^ ^_^
[Bug target/48863] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48863 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org Known to work||7.0 Target Milestone|--- |7.0 --- Comment #7 from ktkachov at gcc dot gnu.org --- Fixed on trunk for GCC 7. I'll wait for a bit before proposing a backport (if this is needed on the branches)
[Bug c/78512] [7 Regression] r242674 miscompiles Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78512 --- Comment #1 from Markus Trippelsdorf --- I run md5sum on the object files with and without -fno-printf-return-value. Looking at a few files that differ they show a common pattern: good vs bad diff: @@ -312,7 +312,7 @@ movq$.LC1, %rsi movq%rax, %rdi callsprintf - cltq + movl$2, %eax ret .size show_tx_maxrate, .-show_tx_maxrate .section.rodata.str1.1 @@ -338,8 +338,8 @@ movq$.LC3, %rsi movq%rbp, %rdi callsprintf + movl$1, %eax popq%rbx - cltq popq%rbp ret .size show_trans_timeout, .-show_trans_timeout @@ -749,7 +749,7 @@ movq$fmt_u64, %rsi movq%rbp, %rdi callsprintf - cltq + movl$2, %eax .L121: movl$-256, %edx etc. Not sure if this a valid transformation or even the root cause of the issue.
[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #13 from Jakub Jelinek --- Yes, sure, there are 2 alloca uses in the parallel region, one is for y variable, which uses __builtin_alloca_with_align ((p4 - 1 + 1) * 4, 32) and the other is for a, which uses __builtin_alloca_with_align ((p5 - 1 + 1) * 8, 32). p4 is 3 and p5 is 4, so the former should be 12 bytes and the latter 32 bytes. But at least in the *.optimized dump I don't see anything that would attempt to write more, there is at most y[2].t and for a at most a[127 / 32].t. So, can you find out how much each alloca actually aligns and if what writes are to those areas? Does it fail also with OMP_NUM_THREADS=1?
[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44685 --- Comment #5 from David Binderman --- Seems fixed in gcc version 6.1.1, dated 20160621
[Bug c++/78514] New: ICE in tsubst, at cp/pt.c:13073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78514
Bug ID: 78514
Summary: ICE in tsubst, at cp/pt.c:13073
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
[forwarded from https://bugs.debian.org/845493]
seen with 4.8.5, 4.9.4, the 5 and 6 branches, and trunk r242638
$ cat index-sequence.cpp
typedef long unsigned a;
template struct b;
template struct b { typedef p c; };
template using e = typename b::c;
template struct g;
template struct h;
template struct h> { using c = g; };
template struct j;
template struct j> {
using c = g;
};
template struct k;
template struct k> { using c = g; };
template struct k> {
using c = typename h::c>::c;
};
template struct k> {
using c = typename j::c>::c;
};
template using m = typename k::c;
template template using n = g;
template using o = m;
template void increasing(n) {
increasing(o<10>{});
}
$ g++ -c -std=c++11 index-sequence.cpp
index-sequence.cpp: In substitution of 'template void
increasing(n) [with long unsigned int i = 1ul]':
index-sequence.cpp:24:21: required from here
index-sequence.cpp:23:21: internal compiler error: in tsubst, at cp/pt.c:13213
template void increasing(n) {
^~
0x682fde tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13213
0x69d1b6 tsubst_template_args
../../src/gcc/cp/pt.c:11410
0x69d362 tsubst_template_args
../../src/gcc/cp/pt.c:11370
0x681681 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13434
0x681af9 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13037
0x69adc2 tsubst_arg_types
../../src/gcc/cp/pt.c:12696
0x69b0ea tsubst_function_type
../../src/gcc/cp/pt.c:12830
0x6812f6 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13573
0x693c4c tsubst_decl
../../src/gcc/cp/pt.c:11991
0x681837 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13011
0x6a2d1f instantiate_template_1
../../src/gcc/cp/pt.c:17805
0x6a2d1f instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.c:17861
0x6ae531 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../src/gcc/cp/pt.c:18241
0x6099f7 add_template_candidate_real
../../src/gcc/cp/call.c:3158
0x60a5bc add_template_candidate
../../src/gcc/cp/call.c:3240
0x60a5bc add_candidates
../../src/gcc/cp/call.c:5475
0x60d071 perform_overload_resolution
../../src/gcc/cp/call.c:4136
0x60f5ce build_new_function_call(tree_node*, vec**, bool, int)
../../src/gcc/cp/call.c:4221
0x7afcb9 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../src/gcc/cp/semantics.c:2440
0x72b1da cp_parser_postfix_expression
../../src/gcc/cp/parser.c:7017
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug target/66358] [5/6/7 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358 --- Comment #23 from David Binderman --- Problem seems to have gone away with gcc version 6.1.1, dated 20160621
