[Bug tree-optimization/80925] [8 Regression] vect peeling failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #29 from Jeffrey A. Law --- This was fixed except for the pr56812 failures which are being tracked via pr81038.
[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897 Jeffrey A. Law changed: What|Removed |Added Summary|[6/7/8 Regression] spurious |[6/7 Regression] spurious |-Wmaybe-uninitialized |-Wmaybe-uninitialized |warning |warning Summary|[6/7/8 Regression] spurious |[6/7 Regression] spurious |-Wmaybe-uninitialized |-Wmaybe-uninitialized |warning |warning --- Comment #12 from Jeffrey A. Law --- Fixed on trunk so far. --- Comment #13 from Jeffrey A. Law --- Fixed on trunk so far.
[Bug middle-end/81897] [6/7/8 Regression] spurious -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897 --- Comment #11 from Jeffrey A. Law --- Author: law Date: Sun Jan 7 05:31:51 2018 New Revision: 256320 URL: https://gcc.gnu.org/viewcvs?rev=256320&root=gcc&view=rev Log: PR middle-end/81897 * tree-ssa-uninit.c (compute_control_dep_chain): Do not bail on basic blocks with a small number of successors. (convert_control_dep_chain_into_preds): Improve handling of forwarder blocks. (dump_predicates): Split apart into... (dump_pred_chain): ...here... (dump_pred_info): ...and here. (can_one_predicate_be_invalidated_p): Add debugging printfs. (can_chain_union_be_invalidated_p): Improve check for invalidation of paths. (uninit_uses_cannot_happen): Avoid unnecessary if convert_control_dep_chain_into_preds yielded nothing. PR middle-end/81897 * gcc.dg/uninit-pr81897.c: New test. Added: trunk/gcc/testsuite/gcc.dg/uninit-pr81897.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-uninit.c
[Bug c++/83710] Unsigned with Signed multiplication followed by right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710 --- Comment #8 from Chanpreet Singh --- (In reply to Jakub Jelinek from comment #7) > You shouldn't read random blogs, but the standard of the language you are > writing in. > E.g. in n3797.pdf it is in [expr]/10: > "Otherwise, the integral promotions (4.5) shall be performed on both > operands. Then the following rules shall be applied to the promoted operands: > — If both operands have the same type, no further conversion is needed. > — Otherwise, if both operands have signed integer types or both have > unsigned integer types, the operand with the type of lesser integer > conversion rank shall be converted to the type of the operand with greater > rank. > — Otherwise, if the operand that has unsigned integer type has rank greater > than or equal to the rank of the type of the other operand, the operand with > signed integer type shall be converted to the type of the operand with > unsigned integer type. > — Otherwise, if the type of the operand with signed integer type can > represent all of the values of the type of the operand with unsigned integer > type, the operand with unsigned integer type shall be converted to the type > of the operand with signed integer type. > — Otherwise, both operands shall be converted to the unsigned integer type > corresponding to the type of the operand with signed integer type. Thanks! Found more pointers in the documentation. I usually follow "preserve signedness of the type" but thats not the case here.
[Bug preprocessor/83722] [8 Regression] the ICE dumper doesn't comment-out some error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83722 --- Comment #1 from Andrew Pinski --- 0x81c19b8 gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long long>) ../../src/gcc/emit-rtl.c:1010 0x86d8a89 lra_substitute_pseudo(rtx_def**, int, rtx_def*, bool) ../../src/gcc/lra.c:1936 0x86d8b45 lra_substitute_pseudo(rtx_def**, int, rtx_def*, bool) ../../src/gcc/lra.c:1950 0x86d8b45 lra_substitute_pseudo(rtx_def**, int, rtx_def*, bool) ../../src/gcc/lra.c:1950 0x86d8c02 lra_substitute_pseudo_within_insn(rtx_insn*, int, rtx_def*, bool) ../../src/gcc/lra.c:1973 0x86ec39e remove_inheritance_pseudos ../../src/gcc/lra-constraints.c:6769 0x86ec39e lra_undo_inheritance() ../../src/gcc/lra-constraints.c:6970 0x86d954b lra(_IO_FILE*) ../../src/gcc/lra.c:2471 0x8698747 do_reload ../../src/gcc/ira.c:5462 0x8698747 execute ../../src/gcc/ira.c:5646 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug driver/83722] New: [8 Regression] the ICE dumper doesn't comment-out some error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83722 Bug ID: 83722 Summary: [8 Regression] the ICE dumper doesn't comment-out some error messages Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Created attachment 43052 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43052&action=edit preprocessed source seen with r256272 on i686-linux-gnu, trying to build freespace2 the ICE dumper doesn't comment-out some follow-up lines, leading to an invalid preprocessed source file. Unsure how to provide more information. in line 7699 of the preprocessed source, you see # 1 "/usr/include/SDL/close_code.h" 1 # 124 "/usr/include/SDL/SDL_timer.h" 2 # 43 "/usr/include/SDL/SDIn file included from ./globalincs/pstypes.h:25, from ./debris/debris.h:15, from debris/debris.cpp:12: ./windows_stub/config.h:67:44: warning: C++11 requires a space between string literal and macro [-Wc++11-co mpat] #define STUB_FUNCTION nprintf(( "Warning", "STUB: %s in "__FILE__" at line %d, thread %d\n", __FUNCTION__, __LINE__, getpid() )) ^ In file included from ./globalincs/pstypes.h:25, from ./debris/debris.h:15, from debris/debris.cpp:12: ./windows_stub/config.h:68:42: warning: C++11 requires a space between string literal and macro [-Wc++11-co mpat] #define DEBUGME(d1) nprintf(( "Warning", "DEBUGME: %s in "__FILE__" at line %d, msg \"%s\", thread %d\n", __FUNCTION__, __LINE__, d1, getpid() )) ^ L.h" 2 complete build log at https://launchpad.net/ubuntu/+archive/test-rebuild-20171220-gcc8/+build/14094308
[Bug lto/83201] [7/8 Regression] SPEC CPU2017 505.mcf_r produces incorrect output when built with -flto and FDO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |INVALID --- Comment #20 from Jeffrey A. Law --- Based on c#18.
[Bug middle-end/83721] New: [8 Regression] ICE: in generic_overlap, at gimple-ssa-warn-restrict.c:821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83721
Bug ID: 83721
Summary: [8 Regression] ICE: in generic_overlap, at
gimple-ssa-warn-restrict.c:821
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with r256272 on i686-linux-gnu, building multimail. omitting the -Wall
avoids the issue.
$ cat basic.ii
int a, c;
void b(char *d, char *e) { __builtin___strncpy_chk(d, e, a, 0); }
char *f;
void g() {
int h;
for (; h < c; h++)
;
b(&f[h], &f[h + 1]);
}
$ g++ -c -g -O2 -Wall basic.ii during GIMPLE pass: strlen
basic.ii: In function 'void g()':
basic.ii:4:6: internal compiler error: in generic_overlap, at
gimple-ssa-warn-restrict.c:821
void g() {
^
0x860b00c generic_overlap
../../src/gcc/gimple-ssa-warn-restrict.c:821
0x860e8cd overlap
../../src/gcc/gimple-ssa-warn-restrict.c:1198
0x860e8cd maybe_diag_overlap
../../src/gcc/gimple-ssa-warn-restrict.c:1215
0x860e8cd check_bounds_or_overlap(gcall*, tree_node*, tree_node*, tree_node*,
tree_node*, bool)
../../src/gcc/gimple-ssa-warn-restrict.c:1774
0x893d5fc handle_builtin_stxncpy
../../src/gcc/tree-ssa-strlen.c:2063
0x893f7d0 strlen_check_and_optimize_stmt
../../src/gcc/tree-ssa-strlen.c:3113
0x8244627 strlen_dom_walker::before_dom_children(basic_block_def*)
../../src/gcc/tree-ssa-strlen.c:3446
0x8e1e162 dom_walker::walk(basic_block_def*)
../../src/gcc/domwalk.c:308
0x8941de0 execute
../../src/gcc/tree-ssa-strlen.c:3526
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug tree-optimization/83563] [8 Regression] [graphite] ICE: Segmentation fault (in instantiate_scev_r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83563 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug tree-optimization/83572] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug tree-optimization/83640] [8 Regression] ICE in generic_overlap, at gimple-ssa-warn-restrict.c:814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83640 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law --- Fixed by Martin's patch on the trunk.
[Bug tree-optimization/83640] [8 Regression] ICE in generic_overlap, at gimple-ssa-warn-restrict.c:814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83640 --- Comment #7 from Jeffrey A. Law --- Author: law Date: Sun Jan 7 04:19:35 2018 New Revision: 256319 URL: https://gcc.gnu.org/viewcvs?rev=256319&root=gcc&view=rev Log: 2018-01-06 Martin Sebor PR tree-optimization/83640 * gimple-ssa-warn-restrict.c (builtin_access::builtin_access): Avoid subtracting negative offset from size. (builtin_access::overlap): Adjust offset bounds of the access to fall within the size of the object if possible. PR tree-optimization/83640 * gcc.dg/Wrestrict-6.c: New test. * gcc.dg/pr83640.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wrestrict-6.c trunk/gcc/testsuite/gcc.dg/pr83640.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-warn-restrict.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/83668] [8 Regression] wrong code with -O -fno-tree-dominator-opts -fgraphite-identity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83668 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law --- Should be fixed by Richard's patch on the trunk.
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 --- Comment #7 from Jeffrey A. Law --- Author: law Date: Sun Jan 7 03:59:54 2018 New Revision: 256318 URL: https://gcc.gnu.org/viewcvs?rev=256318&root=gcc&view=rev Log: PR rtl-optimization/83699 * expmed.c (extract_bit_field_1): Restrict the vector usage of extract_bit_field_as_subreg to cases in which the extracted value is also a vector. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c
[Bug lto/83720] New: [8 Regression] ICE: in mangle_decl, at cp/mangle.c:3847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83720
Bug ID: 83720
Summary: [8 Regression] ICE: in mangle_decl, at
cp/mangle.c:3847
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
seen with r256272, building pybind11
$ g++ -c -std=c++14 -g -O2 -flto test_alias_initialization.ii
during IPA pass: *free_lang_data
:13:5: internal compiler error: in mangle_decl, at cp/mangle.c:3847
0x594554 mangle_decl(tree_node*)
../../src/gcc/cp/mangle.c:3846
0xda5077 decl_assembler_name(tree_node*)
../../src/gcc/tree.c:687
0xda5077 assign_assembler_name_if_needed(tree_node*)
../../src/gcc/tree.c:5802
0xda6468 free_lang_data_in_cgraph
../../src/gcc/tree.c:5851
0xda6468 free_lang_data
../../src/gcc/tree.c:5892
0xda6468 execute
../../src/gcc/tree.c:5943
Please submit a full bug report,
with preprocessed source if appropriate.
$ cat test_alias_initialization.ii
# 9 "" 3
namespace b {
class h {
public:
template h(ae af::*...) {
[] {};
}
};
class ai {};
template class c {
public:
template aj(char *, ag f) { h(f, int()); }
};
}
template class al;
template class i {
protected:
static e g(const) {}
};
template class j;
template
class j : i {
typedef i ap;
public:
static an aq(const &ar, ao... as) { ap::g(ar)(as...); }
};
template class al {
template using ax = a;
public:
template , typename = ax>
al(e);
using ay = an (*)(const &, ao...);
ay az;
};
template
template
al::al(e) {
az = j::aq;
}
class k {
public:
k(al);
} d([](b::ai) {
struct be {
virtual f();
};
struct bf;
b::c().aj("", &be::f);
});
[Bug lto/83719] [8 Regression] ICE (segfault) in hash_table::elements()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83719 Matthias Klose changed: What|Removed |Added Keywords||ice-on-valid-code Target||i686-linux-gnu Known to work||7.2.1 Known to fail||8.0 --- Comment #1 from Matthias Klose --- smallest test case is the empty file
[Bug lto/83719] New: [8 Regression] ICE (segfault) in hash_table::elements()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83719 Bug ID: 83719 Summary: [8 Regression] ICE (segfault) in hash_table::elements() Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- seen with r256272 on i686-linux-gnu $ cat assembly.ii // $ g++ -std=c++11 -c -gsplit-dwarf -g -O2 -flto assembly.ii assembly.ii:1: internal compiler error: Segmentation fault // 0x8803dda crash_signal ../../src/gcc/toplev.c:325 0x855d42e hash_table::elements() const ../../src/gcc/hash-table.h:388 0x855d42e void hash_table::traverse(dwarf_form) ../../src/gcc/hash-table.h:987 0x8528e6f output_indirect_strings ../../src/gcc/dwarf2out.c:27799 0x855ac81 dwarf2out_early_finish ../../src/gcc/dwarf2out.c:30894 0x84da930 symbol_table::finalize_compilation_unit() ../../src/gcc/cgraphunit.c:2713 Please submit a full bug report, with preprocessed source if appropriate. Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8-20180104-0ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --enable-objc-gc=auto --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix
[Bug middle-end/83718] New: [8 Regression] ICE: Floating point exception in profile_count::apply_scale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83718
Bug ID: 83718
Summary: [8 Regression] ICE: Floating point exception in
profile_count::apply_scale
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with r256272, building slic3r on amd64:
$ g++ -c -O2 Print.ii
during GIMPLE pass: fnsplit
Print.ii: In function 'virtual int*::d(a, bool)':
Print.ii:138:4: internal compiler error: Floating point exception
} b;
^
0xbe45bf crash_signal
../../src/gcc/toplev.c:325
0xc2f89f profile_count::apply_scale(profile_count, profile_count) const
../../src/gcc/profile-count.h:76
0xc2f89f copy_edges_for_bb
../../src/gcc/tree-inline.c:2231
0xc2f89f copy_cfg_body
../../src/gcc/tree-inline.c:2752
0xc2f89f copy_body
../../src/gcc/tree-inline.c:2971
0xc32fc1 tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*)
../../src/gcc/tree-inline.c:6039
0x8cf109 cgraph_node::create_version_clone_with_body(vec, vec*, bitmap_head*, bool,
bitmap_head*, basic_block_def*, char const*)
../../src/gcc/cgraphclones.c:984
0x1251619 split_function
../../src/gcc/ipa-split.c:1369
0x1251619 execute_split_functions
../../src/gcc/ipa-split.c:1896
Please submit a full bug report,
with preprocessed source if appropriate.
$ cat Print.ii
class a {
public:
int c(const char *);
};
class B {
virtual int *d(a, bool);
};
bool e, f, g, h, i, j, k, l, m, n, o, p, aa, q, r, s, t, u, v, ab, w, x, y, z,
ac, ad;
class : B {
int ae;
int af;
int ag;
int ah;
int ai;
int aj;
int ak;
int al;
int am;
int an;
int ao;
int ap;
int aq;
int ar;
int as;
int at;
int au;
int av;
int aw;
int ax;
int ay;
int az;
int ba;
int bb;
int bc;
int bd;
int be;
int bf;
int bg;
int bh;
int bi;
int *d(a, bool) {
if (e)
return &ae;
a bj;
bj.c("");
if (f)
return
bj.c("");
if (e)
return &ag;
bj.c("");
if (f)
return &ah;
bj.c("");
if (e)
return &ai;
bj.c("");
if (ad)
return &aj;
bj.c("");
if (ac)
return &ak;
bj.c("");
if (z)
return &al;
bj.c("");
if (y)
return &am;
bj.c("");
if (x)
return &an;
bj.c("");
if (w)
return &ao;
bj.c("");
if (ab)
return ≈
bj.c("");
if (v)
return &aq;
bj.c("");
if (u)
return &ar;
bj.c("");
if (t)
return &as;
bj.c("");
if (s)
return &at;
bj.c("");
if (r)
return &au;
bj.c("");
if (q)
return &av;
bj.c("");
if (aa)
return &aw;
bj.c("");
if (p)
return &ax;
bj.c("");
if (o)
return &ay;
bj.c("");
if (n)
return &az;
bj.c("");
if (m)
return &ba;
bj.c("");
if (l)
return &bb;
bj.c("");
if (k)
return &bc;
bj.c("");
if (j)
return &bd;
bj.c("");
if (i)
return &be;
bj.c("");
if (h)
return &bf;
bj.c("");
if (g)
return &bg;
if (f)
return &bh;
{
a bj;
e = bj.c("");
}
return &bi;
}
} b;
[Bug fortran/83705] [8 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
Thomas Koenig changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #6 from Thomas Koenig ---
This case is probably related, apparently the simplification failure
leads to a somewhat misleading error message:
program main
integer(8), parameter :: n=2_8**32+1
character(len=n), parameter :: a1 = repeat('x',n), a2 = repeat('y',n)
character(len=*), parameter :: a3 = a1 // a2
end program main
concat.f90:4:37:
character(len=*), parameter :: a3 = a1 // a2
1
Error: Function ‘a1’ in initialization expression at (1) must be an intrinsic
function
[Bug fortran/83705] [8 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
--- Comment #5 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #4)
> Is there a way to check that the type of expr->value.character.length in
> gfc_conv_substring_expr (fortran/trans-expr.c) is gfc_charlen_t?
That is correct, see gfortran.h's definition of gfc_expr,
line 2205.
This contains
struct
{
gfc_charlen_t length;
gfc_char_t *string;
}
character;
gfc_constructor_base constructor;
}
value;
[Bug fortran/83705] [8 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705 --- Comment #4 from Dominique d'Humieres --- With integer(8), parameter :: n=2_8**31 - 1_8 I get (compilation time ~4 minutes) 2147483647 'xxx', 'xxx' With integer(8), parameter :: n=2_8**32 I get (compilation time ~4 minutes) 4294967296 '', '' For n=2_8**31 and n=2_8**32-1, the compilation did not finished in more than hour and I gave up). Is there a way to check that the type of expr->value.character.length in gfc_conv_substring_expr (fortran/trans-expr.c) is gfc_charlen_t?
[Bug c/83703] Loop termination condition ignored in -O3, works in -O2 or with smaller values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703 --- Comment #7 from Andrew Pinski --- If you want to have signed integer overflow being defined as wrapping use -fwrapv.
[Bug c/83703] Loop termination condition ignored in -O3, works in -O2 or with smaller values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703 --- Comment #6 from Freddie Chopin --- The runtime checks are no good in deeply embedded (like a MCU)... Anyway - would this behave the same if the values in `in[]` would NOT be known at compile time? For example provided by user for each run of the application? I'm trying to fully understand the problem here and this really seems wrong to me that the compiled program behaves so crazy just because 10 lines below there's an integer overflow...
[Bug fortran/83705] [8 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705 Dominique d'Humieres changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #3 from Dominique d'Humieres --- *** Bug 83717 has been marked as a duplicate of this bug. ***
[Bug fortran/83717] Segfault with long character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83717 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- I think it is a duplicate of pr83705. *** This bug has been marked as a duplicate of bug 83705 ***
[Bug fortran/83717] New: Segfault with long character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83717
Bug ID: 83717
Summary: Segfault with long character parameter
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
On powerpc64-unknown-linux-gnu:
program main
integer(8), parameter :: n=2_8**32+1
character(len=*), parameter :: a1 = repeat('x',n)
write (10) a1
end program main
(gdb) r param.f90
Starting program: /home/tkoenig/trunk-bin/gcc/f951 param.f90
Program received signal SIGSEGV, Segmentation fault.
0x10194c34 in add_init_expr_to_sym (name=name@entry=0x3fffe330
"a1", initp=initp@entry=0x3fffe3e8,
var_locus=var_locus@entry=0x3fffe3b0) at
../../trunk/gcc/fortran/decl.c:1747
1747sym->ts.u.cl->length =
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-196.el7_4.2.ppc64 gmp-6.0.0-15.el7.ppc64 libmpc-1.0.1-3.el7.ppc64
mpfr-3.1.1-4.el7.ppc64
(gdb) bt
#0 0x10194c34 in add_init_expr_to_sym (name=name@entry=0x3fffe330
"a1", initp=initp@entry=0x3fffe3e8,
var_locus=var_locus@entry=0x3fffe3b0) at
../../trunk/gcc/fortran/decl.c:1747
#1 0x101a0be8 in variable_decl (elem=1) at
../../trunk/gcc/fortran/decl.c:2589
#2 gfc_match_data_decl () at ../../trunk/gcc/fortran/decl.c:5692
#3 0x1021c2a4 in match_word (str=str@entry=0x0, subr=,
old_locus=) at ../../trunk/gcc/fortran/parse.c:65
#4 0x1021d158 in decode_statement () at
../../trunk/gcc/fortran/parse.c:376
#5 0x10221e08 in next_free () at ../../trunk/gcc/fortran/parse.c:1226
[Bug tree-optimization/83671] Fix for false positive reported by -Wstringop-overflow does not work at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83671 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Summary|Fix for false positive |Fix for false positive |reported by |reported by |-Wstringop-overflow does|-Wstringop-overflow does |not work with inlining |not work at -O1 --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00381.html
[Bug c/83703] Loop termination condition ignored in -O3, works in -O2 or with smaller values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703 --- Comment #5 from Jakub Jelinek --- We provide the sanitizers (-fsanitize=undefined, -fsanitize=address, etc.) that you can use to find those issues at runtime. There are some warnings but runtime instrumentation can catch far more than warnings can.
[Bug c/83703] Loop termination condition ignored in -O3, works in -O2 or with smaller values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703 --- Comment #4 from Freddie Chopin --- Would it be possible to have a warning with -Wall -Wextra when something like that happens? I think this behaviour here is really strange and really unexpected. In "real" programs I guess there are tons of such tiny undefined behaviours so eliminating them is probably very hard, which would then render -O3 option completely useless.
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #10 from Janne Blomqvist --- Author: jb Date: Sat Jan 6 19:09:52 2018 New Revision: 256313 URL: https://gcc.gnu.org/viewcvs?rev=256313&root=gcc&view=rev Log: PR 83704 Use size_t in write_character For printing long characters, we need to use size_t instead of int in the argument to write_character. Regtested on x86_64-pc-linux-gnu, approved in the PR, committed to trunk. libgfortran/ChangeLog: 2018-01-06 Dominique d'Humieres Janne Blomqvist PR fortran/83704 * io/write.c (write_character): Use size_t instead of int for length. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c
[Bug c++/83716] tree check: expected tree that contains ‘decl common’ structure, have ‘identifier_node’ in get_inner_reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83716 --- Comment #1 from uruwi at protonmail dot com --- Created attachment 43051 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43051&action=edit Preprocessed file (gzipped)
[Bug c++/83716] New: tree check: expected tree that contains ‘decl common’ structure, have ‘identifier_node’ in get_inner_reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83716 Bug ID: 83716 Summary: tree check: expected tree that contains ‘decl common’ structure, have ‘identifier_node’ in get_inner_reference Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: uruwi at protonmail dot com Target Milestone: --- GCC version: 8.0.0 20180106 System: GNU/Linux x64 (kernel version: 4.13.0-17) Options used when GCC was configured or built: none in particular Flags: -g -std=c++17 -Wall -Wpedantic -Wextra -Werror -fno-builtin -O0 -g Output: In file included from /usr/include/boost/asio/read_until.hpp:921:0, from /usr/include/boost/asio.hpp:91, from /home/uruwi/vane/Vane/main.cpp:8: /usr/include/boost/asio/impl/read_until.hpp: In constructor ‘boost::asio::detail::read_until_delim_string_op::read_until_delim_string_op(boost::asio::detail::read_until_delim_string_op&&)’: /usr/include/boost/asio/impl/read_until.hpp:551:62: internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘identifier_node’ in get_inner_reference, at expr.c:7002 delim_(BOOST_ASIO_MOVE_CAST(std::string)(other.delim_)), ^ 0x67e9b5 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../gcc-latest/gcc/tree.c:9268 0xb32778 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc-latest/gcc/tree.h:3202 0xb32778 get_inner_reference(tree_node*, long*, long*, tree_node**, machine_mode*, int*, int*, int*) ../../gcc-latest/gcc/expr.c:7002 0xb79a4b fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*) ../../gcc-latest/gcc/fold-const.c:7695 0xb7ae89 fold_build1_loc(unsigned int, tree_code, tree_node*, tree_node*) ../../gcc-latest/gcc/fold-const.c:12068 0x758b4c cp_fold_convert(tree_node*, tree_node*) ../../gcc-latest/gcc/cp/cvt.c:607 0x934665 build_static_cast_1 ../../gcc-latest/gcc/cp/typeck.c:6856 0x934da4 build_static_cast(tree_node*, tree_node*, int) ../../gcc-latest/gcc/cp/typeck.c:7078 0x8496cc cp_parser_postfix_expression ../../gcc-latest/gcc/cp/parser.c:6696 0x84c1ea cp_parser_unary_expression ../../gcc-latest/gcc/cp/parser.c:8363 0x8294b6 cp_parser_cast_expression ../../gcc-latest/gcc/cp/parser.c:9131 0x829d27 cp_parser_binary_expression ../../gcc-latest/gcc/cp/parser.c:9232 0x82b704 cp_parser_assignment_expression ../../gcc-latest/gcc/cp/parser.c:9519 0x82dad6 cp_parser_parenthesized_expression_list ../../gcc-latest/gcc/cp/parser.c:7822 0x84ff98 cp_parser_mem_initializer ../../gcc-latest/gcc/cp/parser.c:14548 0x84ff98 cp_parser_mem_initializer_list ../../gcc-latest/gcc/cp/parser.c:14434 0x84ff98 cp_parser_ctor_initializer_opt ../../gcc-latest/gcc/cp/parser.c:14405 0x84ff98 cp_parser_ctor_initializer_opt_and_function_body ../../gcc-latest/gcc/cp/parser.c:21859 0x852926 cp_parser_function_definition_after_declarator ../../gcc-latest/gcc/cp/parser.c:26765 0x853b7c cp_parser_late_parsing_for_member ../../gcc-latest/gcc/cp/parser.c:27645 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Preprocessed source: attached
[Bug c++/83710] Unsigned with Signed multiplication followed by right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- You shouldn't read random blogs, but the standard of the language you are writing in. E.g. in n3797.pdf it is in [expr]/10: "Otherwise, the integral promotions (4.5) shall be performed on both operands. Then the following rules shall be applied to the promoted operands: — If both operands have the same type, no further conversion is needed. — Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank shall be converted to the type of the operand with greater rank. — Otherwise, if the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type shall be converted to the type of the operand with unsigned integer type. — Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type shall be converted to the type of the operand with signed integer type. — Otherwise, both operands shall be converted to the unsigned integer type corresponding to the type of the operand with signed integer type.
[Bug c/83703] Loop termination condition ignored in -O3, works in -O2 or with smaller values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- The compiler optimizes with the assumption that undefined behavior doesn't happen (i.e. it compiles valid programs), so if you have UB in your code, all bets are off, it can do anything.
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #9 from Jerry DeLisle --- (In reply to Janne Blomqvist from comment #8) > - for (i = 0; i < length; i++) > + for (size_t = 0; i < length; i++) typo above. Change to: + for (size_t i = 0; i < length; i++)
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #8 from Janne Blomqvist ---
Good catch! Though as is, there's a few warnings due to signed/unsigned
comparisons. Some minor fixes results in:
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 3aa2f0e..f966917 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1359,9 +1359,9 @@ write_integer (st_parameter_dt *dtp, const char *source,
int kind)
#define NODELIM 0
static void
-write_character (st_parameter_dt *dtp, const char *source, int kind, int
length, int mode)
+write_character (st_parameter_dt *dtp, const char *source, int kind, size_t
length, int mode)
{
- int i, extra;
+ size_t extra;
char *p, d;
if (mode == DELIM)
@@ -1390,7 +1390,7 @@ write_character (st_parameter_dt *dtp, const char
*source, int kind, int length,
{
extra = 2;
- for (i = 0; i < length; i++)
+ for (size_t = 0; i < length; i++)
if (source[i] == d)
extra++;
}
@@ -1410,7 +1410,7 @@ write_character (st_parameter_dt *dtp, const char
*source, int kind, int length,
{
*p4++ = d4;
- for (i = 0; i < length; i++)
+ for (size_t i = 0; i < length; i++)
{
*p4++ = (gfc_char4_t) source[i];
if (source[i] == d)
@@ -1428,7 +1428,7 @@ write_character (st_parameter_dt *dtp, const char
*source, int kind, int length,
{
*p++ = d;
- for (i = 0; i < length; i++)
+ for (size_t i = 0; i < length; i++)
{
*p++ = source[i];
if (source[i] == d)
Consider this preapproved with a ChangeLog entry, if you'd like to do the
honors! :)
[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 Jeffrey A. Law changed: What|Removed |Added Summary|[7/8 Regression] Large |[7 Regression] Large C-Ray |C-Ray slowdown |slowdown --- Comment #20 from Jeffrey A. Law --- 8 regression marker removed per Aldy's testing. Assumption is Jan and Yuri's work addressed the problem.
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #7 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #6)
> > However this does not fix the output of
>
> print *, "'", ch(1:2_8**32_8+3_8), "'"
>
> This is fixed by the following patch
>
> --- ../_clean/libgfortran/io/write.c 2018-01-05 20:02:38.0 +0100
> +++ libgfortran/io/write.c2018-01-06 17:43:04.0 +0100
> @@ -1358,7 +1359,7 @@ write_integer (st_parameter_dt *dtp, con
> #define NODELIM 0
>
> static void
> -write_character (st_parameter_dt *dtp, const char *source, int kind, int
> length, int mode)
> +write_character (st_parameter_dt *dtp, const char *source, int kind, size_t
> length, int mode)
> {
>int i, extra;
>char *p, d;
Approved, make it so, and good catch!
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #6 from Dominique d'Humieres ---
> However this does not fix the output of
print *, "'", ch(1:2_8**32_8+3_8), "'"
This is fixed by the following patch
--- ../_clean/libgfortran/io/write.c2018-01-05 20:02:38.0 +0100
+++ libgfortran/io/write.c 2018-01-06 17:43:04.0 +0100
@@ -1358,7 +1359,7 @@ write_integer (st_parameter_dt *dtp, con
#define NODELIM 0
static void
-write_character (st_parameter_dt *dtp, const char *source, int kind, int
length, int mode)
+write_character (st_parameter_dt *dtp, const char *source, int kind, size_t
length, int mode)
{
int i, extra;
char *p, d;
[Bug c/83703] Loop termination condition ignored in -O3, works in -O2 or with smaller values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703 --- Comment #2 from Freddie Chopin --- Indeed, reducing the values in `in[]` makes the code behave properly. But anyway - how does this particular (minor) issue in the code affect a seemingly unrelated loop? After all, this loop's variable - `b1` - is never modified apart from the loop's incrementation... I'm not saying that this example code is perfectly valid (it was a quick and dirty test of something else), but the behaviour observed with -O3 is really surprising.
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #5 from Dominique d'Humieres --- > If I compile with -O2, or compile with -O0 and set the stack size limit > to unlimited before running, the segfault disappears for me. I can confirmed that the 'Illegal instruction' is gone if I compile the test with -O1 or with '-Wl,-stack_size,0x12000' (0x11000 is not enough and on darwin the stack size with ulimit is hard wired to 64Mb). However this does not fix the output of print *, "'", ch(1:2_8**32_8+3_8), "'" > I can compile it fine, but do not have enough memory to run it. > So dominiq, how much RAM do you have, maybe I can find a machine of sufficient > capacity. One has to be careful we dont take someones OS to its knees. I have 16Gb of RAM and I have been able to run tests using up to 2_8**35 characters (I didn't tried more).
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #4 from Jerry DeLisle --- I can compile it fine, but do not have enough memory to run it. So dominiq, how much RAM do you have, maybe I can find a machine of sufficient capacity. One has to be careful we dont take someones OS to its knees.
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #3 from Janne Blomqvist --- If I compile with -O2, or compile with -O0 and set the stack size limit to unlimited before running, the segfault disappears for me.
[Bug tree-optimization/83715] Missed optimization in math expression: optimize double comparing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83715 Marc Glisse changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-06 Version|tree-ssa|8.0 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- For int, this is handled by VRP, so not trivial to extend to float.
[Bug c++/80763] [7/8 Regression] -O3 causes error: inline clone in same comdat group list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80763 David Binderman changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #10 from David Binderman --- (In reply to David Binderman from comment #9) > Broken for over four months now. Still broken. Regression from 8.0 Since hubicka hasn't fixed it in six months, perhaps it is time to allow someone else to have a go ? I'd be happy to help with any testing of any speculative patch.
[Bug tree-optimization/83715] New: Missed optimization in math expression: optimize double comparing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83715
Bug ID: 83715
Summary: Missed optimization in math expression: optimize
double comparing
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zamazan4ik at tut dot by
Target Milestone: ---
gcc trunk with '-O3 -ffast-math -std=c++17' for this code:
double test(double x, double y)
{
if(x != y)
{
return 42.0;
}
return x/y;
}
generates this code:
test(double, double):
comisd xmm0, xmm1
jne .L3
divsd xmm0, xmm1
ret
.L3:
movsd xmm0, QWORD PTR .LC0[rip]
ret
.LC0:
.long 0
.long 1078263808
but we can optimize here divide operation and just return 1.0.
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 rsandifo at gcc dot gnu.org changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-01/msg00368.ht ||ml --- Comment #6 from rsandifo at gcc dot gnu.org --- In the end it seemed better to restrict the new code to vector extractions from vectors: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00368.html
[Bug c++/83714] New: [8 Regression] ICE in build_address, at cp/typeck.c:5733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83714
Bug ID: 83714
Summary: [8 Regression] ICE in build_address, at
cp/typeck.c:5733
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
Starting from r218879 we ICE on:
$ cat hell2.ii
class a {
typedef int b;
operator b();
};
struct c {
using d = a;
};
using e = c;
auto f(auto) -> e {
return e::d {};
};
$ g++ hell2.ii
hell2.ii: In function ‘e f(auto:1)’:
hell2.ii:10:16: internal compiler error: in build_address, at cp/typeck.c:5733
return e::d {};
^
0x85b2e1 build_address(tree_node*)
../../gcc/cp/typeck.c:5733
0x62d460 add_function_candidate
../../gcc/cp/call.c:2158
0x62ed6f add_candidates
../../gcc/cp/call.c:5516
0x629e63 add_candidates
../../gcc/cp/call.c:3840
0x629e63 build_user_type_conversion_1
../../gcc/cp/call.c:3841
0x62b854 implicit_conversion
../../gcc/cp/call.c:1889
0x627253 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:10516
0x874f21 check_return_expr(tree_node*, bool*)
../../gcc/cp/typeck.c:9346
0x81a4ae finish_return_stmt(tree_node*)
../../gcc/cp/semantics.c:890
0x76c7ac cp_parser_jump_statement
../../gcc/cp/parser.c:12335
0x76c7ac cp_parser_statement
../../gcc/cp/parser.c:10752
0x76d0c0 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11185
0x76d197 cp_parser_compound_statement
../../gcc/cp/parser.c:11139
0x785d20 cp_parser_function_body
../../gcc/cp/parser.c:21679
0x785d20 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21716
0x7864b0 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:26620
0x78717d cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:26536
0x78717d cp_parser_init_declarator
../../gcc/cp/parser.c:19405
0x78f4ac cp_parser_simple_declaration
../../gcc/cp/parser.c:12968
0x7903f8 cp_parser_block_declaration
../../gcc/cp/parser.c:12793
[Bug c++/83713] New: [6/7/8 Regression] ICE in do_narrow at gcc/convert.c:474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83713
Bug ID: 83713
Summary: [6/7/8 Regression] ICE in do_narrow at
gcc/convert.c:474
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Starting from r246756 we ICE on:
$ cat Buffer.ii
class a
{
char b;
void c ();
};
void
a::c ()
{
&b + ((long long) &b & 0);
}
$ g++ Buffer.ii -O2 -m32 -c
Buffer.ii: In member function ‘void a::c()’:
Buffer.ii:9:27: internal compiler error: tree check: expected boolean_type or
enumeral_type or integer_type, have pointer_type in do_narrow, at convert.c:474
&b + ((long long) &b & 0);
^
0x5f56dc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9347
0x9aa268 any_integral_type_check(tree_node*, char const*, int, char const*)
../../gcc/tree.h:3374
0x5e2f50 do_narrow
../../gcc/convert.c:474
0x9a892f convert_to_integer_1
../../gcc/convert.c:887
0x690b59 ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/cp/cvt.c:814
0x8968bc pointer_int_sum(unsigned int, tree_code, tree_node*, tree_node*, bool)
../../gcc/c-family/c-common.c:3147
0x86b192 cp_pointer_int_sum
../../gcc/cp/typeck.c:5445
0x86b192 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc/cp/typeck.c:4421
0x636aee build_new_op_1
../../gcc/cp/call.c:6002
0x63757e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/cp/call.c:6046
0x85a822 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/cp/typeck.c:4024
0x7616ce cp_parser_binary_expression
../../gcc/cp/parser.c:9284
0x762ee4 cp_parser_assignment_expression
../../gcc/cp/parser.c:9417
0x7636c8 cp_parser_expression
../../gcc/cp/parser.c:9586
0x765698 cp_parser_expression_statement
../../gcc/cp/parser.c:11042
0x76b86f cp_parser_statement
../../gcc/cp/parser.c:10858
0x76d0c0 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11185
0x76d197 cp_parser_compound_statement
../../gcc/cp/parser.c:11139
0x785d20 cp_parser_function_body
../../gcc/cp/parser.c:21679
0x785d20 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21716
[Bug c/83703] Loop termination condition ignored in -O3, works in -O2 or with smaller values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703 --- Comment #1 from Mikael Pettersson --- There's a signed int overflow in this code, leading to UB. Compile and run with -fsanitize=undefined and you'll get reg.cpp:49:23: runtime error: signed integer overflow: -359 * 599 cannot be represented in type 'int' Eliminate that and it should work.
[Bug target/83712] New: "Unable to find a register to spill" when compiling for thumb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
Bug ID: 83712
Summary: "Unable to find a register to spill" when compiling
for thumb1
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
Created attachment 43050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43050&action=edit
a reduced testcase for gcc bug
I get the following error when attempting co compile the attached file with:
$ arm-linux-gnueabi-gcc-7 -mfloat-abi=softfp -mthumb -march=armv5t -O2
kbd-min.c
kbd-min.c: In function ‘handle_trm’:
kbd-min.c:23:1: error: unable to find a register to spill
}
^
kbd-min.c:23:1: error: this is the insn:
(insn 17 43 44 2 (parallel [
(set (mem:SI (reg/f:SI 129 [121]) [0 S4 A32])
(mem:SI (reg/f:SI 135 [120]) [0 S4 A32]))
(set (mem:SI (plus:SI (reg/f:SI 129 [121])
(const_int 4 [0x4])) [0 S4 A32])
(mem:SI (plus:SI (reg/f:SI 135 [120])
(const_int 4 [0x4])) [0 S4 A32]))
(set (mem:SI (plus:SI (reg/f:SI 129 [121])
(const_int 8 [0x8])) [0 S4 A32])
(mem:SI (plus:SI (reg/f:SI 135 [120])
(const_int 8 [0x8])) [0 S4 A32]))
(set (reg/f:SI 129 [121])
(plus:SI (reg/f:SI 129 [121])
(const_int 12 [0xc])))
(set (reg/f:SI 135 [120])
(plus:SI (reg/f:SI 135 [120])
(const_int 12 [0xc])))
(clobber (reg:SI 126))
(clobber (reg:SI 127))
(clobber (reg:SI 128))
]) "kbd-min.c":16 836 {movmem12b}
(expr_list:REG_UNUSED (reg:SI 128)
(expr_list:REG_UNUSED (reg:SI 127)
(expr_list:REG_UNUSED (reg:SI 126)
(nil)
kbd-min.c:23: confused by earlier errors, bailing out
I reproduced the bug on gcc-4.8.4, gcc-6.3.0, gcc-7.2.0.
[Bug fortran/83705] [8 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
--- Comment #2 from Janne Blomqvist ---
With the following patch the testcase works:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 3e5abd4..d68975c 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -6084,8 +6084,8 @@ gfc_simplify_repeat (gfc_expr *e, gfc_expr *n)
(8 * 2**20 elements * 4 bytes (wide chars) per element) defer to
runtime instead of consuming (unbounded) memory and CPU at
compile time. */
- if (nlen > 8388608)
-return NULL;
+ // if (nlen > 8388608)
+ //return NULL;
result = gfc_get_character_expr (e->ts.kind, &e->where, NULL, nlen);
for (size_t i = 0; i < (size_t) ncop; i++)
diff --git a/gcc/fortran/trans-const.c b/gcc/fortran/trans-const.c
index 028e6d2..2d84ba7 100644
--- a/gcc/fortran/trans-const.c
+++ b/gcc/fortran/trans-const.c
@@ -89,7 +89,7 @@ gfc_build_string_const (int length, const char *s)
non-default character kinds. */
tree
-gfc_build_wide_string_const (int kind, int length, const gfc_char_t *string)
+gfc_build_wide_string_const (int kind, gfc_charlen_t length, const gfc_char_t
*string)
{
int i;
tree str, len;
@@ -141,7 +141,7 @@ gfc_conv_string_init (tree length, gfc_expr * expr)
{
gfc_char_t *s;
HOST_WIDE_INT len;
- int slen;
+ gfc_charlen_t slen;
tree str;
bool free_s = false;
diff --git a/gcc/fortran/trans-const.h b/gcc/fortran/trans-const.h
index 39693bb..d51c564 100644
--- a/gcc/fortran/trans-const.h
+++ b/gcc/fortran/trans-const.h
@@ -45,7 +45,7 @@ tree gfc_conv_constant_to_tree (gfc_expr *);
void gfc_conv_constant (gfc_se *, gfc_expr *);
tree gfc_build_string_const (int, const char *);
-tree gfc_build_wide_string_const (int, int, const gfc_char_t *);
+tree gfc_build_wide_string_const (int, gfc_charlen_t, const gfc_char_t *);
tree gfc_build_cstring_const (const char *);
tree gfc_build_localized_cstring_const (const char *);
Of course, commenting out the part in simplify.c makes the repeat_7.f90 test
fail. Also, when compiling the testcase in this PR the compiler uses 1.7 GB
RAM, so I do think it makes sense to have *some* limit where we give up and
defer to runtime.
The problem thus is that some code somewhere doesn't like that simplification
fails. If I don't comment out the simplify.c part I get the ICE:
f951: internal compiler error: Segmentation fault
0xcd4a3f crash_signal
../../trunk-git/gcc/toplev.c:325
0x6973ba add_init_expr_to_sym
../../trunk-git/gcc/fortran/decl.c:1748
0x6a0aa0 variable_decl
../../trunk-git/gcc/fortran/decl.c:2589
0x6a0aa0 gfc_match_data_decl()
../../trunk-git/gcc/fortran/decl.c:5692
0x6fe7a9 match_word_omp_simd
../../trunk-git/gcc/fortran/parse.c:93
0x701f3e match_word
../../trunk-git/gcc/fortran/parse.c:376
0x701f3e decode_statement
../../trunk-git/gcc/fortran/parse.c:376
0x703fc1 next_free
../../trunk-git/gcc/fortran/parse.c:1226
0x703fc1 next_statement
../../trunk-git/gcc/fortran/parse.c:1458
0x705abb parse_spec
../../trunk-git/gcc/fortran/parse.c:3836
0x708023 parse_progunit
../../trunk-git/gcc/fortran/parse.c:5649
0x7096c4 gfc_parse_file()
../../trunk-git/gcc/fortran/parse.c:6189
0x751e7f gfc_be_parse_file
../../trunk-git/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/83705] [8 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705 --- Comment #1 from Janne Blomqvist --- > which makes sense for variables, but IMO not for parameters. I agree, that's why a few lines before that block checking the size limit we have: /* For further simplification, we need the character string to be constant. */ if (e->expr_type != EXPR_CONSTANT) return NULL;
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #22 from Janne Blomqvist --- Author: jb Date: Sat Jan 6 10:42:57 2018 New Revision: 256311 URL: https://gcc.gnu.org/viewcvs?rev=256311&root=gcc&view=rev Log: PR 78534 libgfortran ChangeLog The libgfortran/ChangeLog entry was accidentally not included in r256284. Modified: trunk/libgfortran/ChangeLog
[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892 --- Comment #10 from Janne Blomqvist --- Author: jb Date: Sat Jan 6 10:41:03 2018 New Revision: 256310 URL: https://gcc.gnu.org/viewcvs?rev=256310&root=gcc&view=rev Log: PR 50892 Latent bug in char pointer assignment Due to r256284 (PR 78534) there was a latent bug that reared it's head due to different character length types in the pointer assignment. Fixed by this patch, which also adds a reduced testcase. Regtested on x86_64-pc-linux-gnu, committed to trunk as obvious. gcc/fortran/ChangeLog: 2018-01-06 Janne Blomqvist PR fortran/50892 * trans-expr.c (gfc_trans_pointer_assignment): fold_convert rhs to lhs type. gcc/testsuite/ChangeLog: 2018-01-06 Janne Blomqvist PR fortran/50892 * gfortran.dg/char_pointer_assign_icb_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_icb_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/83710] Unsigned with Signed multiplication followed by right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710 --- Comment #6 from Chanpreet Singh --- (In reply to Andrew Pinski from comment #5) > (In reply to Chanpreet Singh from comment #4) > > (In reply to Andrew Pinski from comment #3) > > > For imull discussion see > > > https://stackoverflow.com/questions/42587607/why-is-imul-used-for- > > > multiplying-unsigned-numbers . > > > > I understand that. However, can you point to me what made the compiler > > choose shrl instruction over sarl? > > Again: unsigned * int produces a type of unsigned. And then the shift is > done in unsigned type. See comment #1. imull is used for both signed and > unsigned multiply :). Understand. For a moment, I thought comment#1 was talking about type casting. Can you provide me with some documentation? There are blogs that says otherwise http://www.avrfreaks.net/forum/tut-signed-and-unsigned-multiplication. Thanks for your clarification.
[Bug c++/83710] Unsigned with Signed multiplication followed by right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710 --- Comment #5 from Andrew Pinski --- (In reply to Chanpreet Singh from comment #4) > (In reply to Andrew Pinski from comment #3) > > For imull discussion see > > https://stackoverflow.com/questions/42587607/why-is-imul-used-for- > > multiplying-unsigned-numbers . > > I understand that. However, can you point to me what made the compiler > choose shrl instruction over sarl? Again: unsigned * int produces a type of unsigned. And then the shift is done in unsigned type. See comment #1. imull is used for both signed and unsigned multiply :).
[Bug c++/83710] Unsigned with Signed multiplication followed by right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710 --- Comment #4 from Chanpreet Singh --- (In reply to Andrew Pinski from comment #3) > For imull discussion see > https://stackoverflow.com/questions/42587607/why-is-imul-used-for- > multiplying-unsigned-numbers . I understand that. However, can you point to me what made the compiler choose shrl instruction over sarl?
[Bug c++/83710] Unsigned with Signed multiplication followed by right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710 --- Comment #3 from Andrew Pinski --- For imull discussion see https://stackoverflow.com/questions/42587607/why-is-imul-used-for-multiplying-unsigned-numbers .
[Bug c++/83710] Unsigned with Signed multiplication followed by right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710 --- Comment #2 from Chanpreet Singh --- Can you please clarify a bit? In the above code, there are 3 vairable, c(int), b(unsigned int) & a(int). The type of 'a*b' is expected to be (int) [same as type of 'c', as also 'imull' instruction is used]. Shouldn't (int) type be used for right shifting by 1?
[Bug c++/83710] Unsigned with Signed multiplication followed by right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- The type of (int)*(unsigned int) is (unsigned int) since both types have equal conversion rank.
[Bug libgomp/82428] Builtins for openacc gang/worker/vector id/size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82428 Tom de Vries changed: What|Removed |Added Keywords||patch --- Comment #4 from Tom de Vries --- https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00363.html
