[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421
--- Comment #5 from Markus Trippelsdorf ---
trippels@CFARM-IUT-TLSE3 ~ % cat octave.ii
template class A;
template <> struct A {
double m_fn1() { return _M_value; }
double _M_value;
};
double a;
template void mx_inline_and(unsigned long, bool *p2, X, Y) {
bool b;
for (long i; i; i++) {
A x;
b = x.m_fn1() || a;
p2[i] = b;
}
}
template
void do_mm_binary_op(int, Y, void(unsigned long, R *, X, Y),
void(unsigned long, R *, X, Y),
void(unsigned long, R *, X, Y), char *);
int c;
void mx_el_and_m2() {
do_mm_binary_op>(c, mx_el_and_m2, mx_inline_and,
mx_inline_and, mx_inline_and, "");
}
trippels@CFARM-IUT-TLSE3 ~ % g++ -w -O3 octave.ii
octave.ii: In function ‘void mx_inline_and(long unsigned int, bool*, X, Y)
[with X = A; Y = void (*)()]’:
octave.ii:7:34: error: type mismatch in conditional expression
template void mx_inline_and(unsigned long, bool *p2, X, Y)
{
^
vector(16) unsigned char
vector(16) unsigned char
vector(2)
vect_patt_15.42_168 = VEC_COND_EXPR ;
octave.ii:7:34: internal compiler error: verify_gimple failed
[Bug lto/69394] [5.3] ICE when linking with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394 --- Comment #3 from rguenther at suse dot de --- On Thu, 21 Jan 2016, daniel.f.starke at freenet dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394 > > --- Comment #2 from Daniel Starke --- > I have tested the same with gcc 4.9.3 to make clear whether this is a > regression or not. Sadly I was not able to build the libstdc++ with -flto. > Compiling the same program as before did not result in a ICE but did produce a > binary which was not exatuable on the target platform. > Next I build gcc 5.3.0 again and all used libraries with that compiler. Before > I did use some libraries I generated with gcc 5.3.0 on the target platform, > not > on Linux. So I suspect that the output of the same gcc differs on Windows and > Linux even though the same target is built. > The result was the same as with gcc 4.9.3. The produced binary was not > executable. > For information, this was the backtrace: > #0 0x00635ef2 in std::type_info::operator== (this=this@entry=0x6cffe8 > , arg=...) > at ../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/tinfo.cc:46 > #1 0x005bf0f4 in __cxxabiv1::__si_class_type_info::__do_dyncast > (this=0x6cffe8 , src2dst=0, > access_path=__cxxabiv1::__class_type_info::__contained_public, > dst_type=0x0, obj_ptr=0x3790a0, > src_type=0x6e5280 , src_ptr=0x3790a0, > result=...) > at > ../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/si_class_type_info.cc:52 > #2 0x006a6fdb in __cxxabiv1::__dynamic_cast (src_ptr=0x3790a0, > src_type=src_type@entry=0x6e5280 , > dst_type=dst_type@entry=0x0, src2dst=src2dst@entry=0) at > ../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/dyncast.cc:72 > #3 0x006a12b0 in std::use_facet > > (__loc=...) > at > /new-gcc/bin64-64/gcc-5.3.0/x86_64-w64-mingw32/libstdc++-v3/include/bits/locale_classes.tcc:139 > #4 0x004dfce5 in boost::filesystem::path::codecvt() () > #5 0x in ?? () > #6 0x0067b727 in std::__cxx11::basic_string std::char_traits, std::allocator >::basic_string(char const*, > std::allocator const&) [clone .isra.1100] () > #7 0x0022fde0 in ?? () > #8 0x004f4ed9 in atexit () > #9 0x006b52a0 in (anonymous namespace)::__new_handler () > #10 0x0003 in ?? () > #11 0x007050f0 in vtable for > boost::detail::sp_counted_impl_p > () > #12 0x006ab266 in > _GLOBAL__sub_I__ZN3pcf6parser6spirit18getInnerInfoStringB5cxx11ERKN5boost6spirit4infoE > () > #13 0x in ?? () > > Using the compiled libraries from before gives me the following ICE: > lto1: internal compiler error: bytecode stream: expected tag bit_field_ref > instead of error_mark > Replacing for example the libsqlite3 from the build with the compiler in > question gives me the following ICE: > In member function 'do_real_get': > lto1: internal compiler error: bytecode stream: expected tag real_type instead > of error_mark > > Is there no version tag within the LTO code which detects if the format is > compatible in an early stage? There is, but it's manually bumped and we do so only for each new major release. That is, we fail to be careful to detect all possible ways the format could change (because that's not always obvious). ICEs of the above kind strongly hint at incompatible binaries though. I suppose we could enhance the error reporting here (maybe even stream a stricter "version", like the SVN revision or some such and take a mismatch at the above ICE point as a hint of an incompatibility). What will have caused an incompatibility from 5.2 to 5.3 is 2015-10-06 Richard Biener Backport from mainline ... 2015-09-24 Richard Biener PR lto/67699 * lto-cgraph.c (compute_ltrans_boundary): Do not stream abstract origins. for example. There are various MPX related changes that look suspicious but those should only make a difference if you use MPX. That said, computing a checksum of the LTO streamer related bits might be a possibility (if we accept spurious incompatibility messages).
[Bug tree-optimization/69376] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69376 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- Let me have a look.
[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Started with r230098.
[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421
--- Comment #7 from Jakub Jelinek ---
Reduced testcase (in C now):
struct A { double a; };
double a;
void
foo (_Bool *x)
{
long i;
for (i = 0; i < 64; i++)
{
struct A c;
x[i] = c.a || a;
}
}
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
CC||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #8 from Richard Biener ---
Ok, I can reproduce the ICE.
(gdb) p deferred_asm_name->created_for
$4 = (tree) 0x764fc980
(gdb) p debug_generic_expr ($4)
.omp_data_s.34
aha and that's indeed a TYPE_DECL which is DECL_ARTIFICIAL but ! DECL_IGNORED.
Jakub - is debug info intended for this TYPE_DECL? Honza, do the TYPE_DECL
asm-names make sense here?
/* This is a GNU Extension. We are adding a
DW_AT_linkage_name attribute to the DIE of the
anonymous struct TYPE. The value of that attribute
is the name of the typedef decl naming the anonymous
struct. This greatly eases the work of consumers of
this debug info. */
add_linkage_name_raw (lookup_type_die (type), decl);
(gdb) p debug_tree ($4)
unit size
align 64 symtab -162595952 alias set 77 canonical type 0x764fad20
fields
unsigned DI file STAR.cpp line 56 col 17
size
unit size
align 64 offset_align 128
offset
bit offset context
chain >
pointer_to_this >
asm_written VOID file STAR.cpp line 353 col 9
align 1>
That said - we either need to make sure to compute and stream
DECL_ASSEMBLER_NAME for the above or avoid emitting late debug for this
(for example via adjusting is_naming_typedef_decl).
Note that it looks like free-lang-data misses to traverse
fn->static_chain_decl,
but fixing that doesn't fix this PR.
The DWARF for the above decl is created via
#4 0x008bfadc in dwarf2out_type_decl (decl=0x764fc980, local=0)
at /space/rguenther/src/svn/trunk3/gcc/dwarf2out.c:23536
#5 0x0076535f in lto_read_decls (decl_data=0x77fed000,
data=0x77ef3a00, resolutions=...)
at /space/rguenther/src/svn/trunk3/gcc/lto/lto.c:1761
So back to why this hasn't been assigned an assembler name in free-lang-data.
FLD has
static inline bool
need_assembler_name_p (tree decl)
{
...
if (flag_lto_odr_type_mering
&& TREE_CODE (decl) == TYPE_DECL
&& DECL_NAME (decl)
&& decl == TYPE_NAME (TREE_TYPE (decl))
&& !TYPE_ARTIFICIAL (TREE_TYPE (decl))
&& (type_with_linkage_p (TREE_TYPE (decl))
|| TREE_CODE (TREE_TYPE (decl)) == INTEGER_TYPE)
&& !variably_modified_type_p (TREE_TYPE (decl), NULL_TREE))
return !DECL_ASSEMBLER_NAME_SET_P (decl);
/* Only FUNCTION_DECLs and VAR_DECLs are considered. */
if (TREE_CODE (decl) != FUNCTION_DECL
&& TREE_CODE (decl) != VAR_DECL)
return false;
but TYPE_ARTIFICIAL (TREE_TYPE (decl)) is true. Guarding the above with
flag_lto_odr_type_merging also looks suspicious - seems the code doesn't
consider debug info for TYPE_DECLs at all?
dwarf2out guards the assembler-name use with
if (DECL_ORIGINAL_TYPE (decl))
...
else
{
type = TREE_TYPE (decl);
...
if (is_naming_typedef_decl (TYPE_NAME (type)))
{
it seems to me we can't really use debug_info_level at compile-time
to guard things here so we'd have to unconditionally assign
assembler names to TYPE_DECLs under the above condition?
Or arrange so that is_naming_typedef_decl doesn't apply to those artificial
OMP type-decls? (why do we have type-decls for this at all...?)
[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Jan 22 09:40:54 2016 New Revision: 232719 URL: https://gcc.gnu.org/viewcvs?rev=232719&root=gcc&view=rev Log: PR debug/8 * dwarf2out.c (add_child_die_after): New function. (dwarf_qual_info_t): New type. (dwarf_qual_info): New variable. (qualified_die_p): New function. (modified_type_die): For -fdebug-types-section, ensure canonical order of qualifiers. Put qualified DIEs adjacent to the corresponding non-qualified type DIE and search there for existing qualified DIEs. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012 Bernd Edlinger changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #17 from Bernd Edlinger --- I'd declare it fixed with Nick's check-in from yesterday. Thanks for reporting.
[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393 --- Comment #9 from Jakub Jelinek --- Yes, the type is meant to go into the debug info. But it is DECL_NAMELESS, so the debug info should not contain DW_AT_name or linkage name for it.
[Bug tree-optimization/69426] [6 Regression] ICE: verify_ssa failed (error: missing definition) w/ -O2 (and above) -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69426 --- Comment #2 from vries at gcc dot gnu.org --- Created attachment 37431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37431&action=edit tentative patch
[Bug c/65403] -Wno-error= is an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- -Werror=unknown-warning should not be ignored, as -Werror=unknown-warning implies also -Wunknown-warning (unlike -Wno-error=, which doesn't imply anything).
[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355 --- Comment #18 from Martin Jambor --- The reduced testcase does not fail for me for some reason, but the original one does. In any event, the problem is that an grp_unscalarized_data flag is zero even though evidently it should not be. That happens because of conditions which were added to ignore padding in case of total scalarization, which however misfired because the total scalarization was not successful (we do not scalarize when a scalar access has a smaller scalar access within it). The wrong grp_unscalarized_data value meant we removed original aggregate store even though we did not have scalar replacements for a part of it. I'll bootstrap the following patch to address this: diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c index 740542f..b0e737a 100644 --- a/gcc/tree-sra.c +++ b/gcc/tree-sra.c @@ -2421,7 +2421,7 @@ analyze_access_subtree (struct access *root, struct access *parent, if (covered_to < limit) hole = true; - if (scalar) + if (scalar || !allow_replacements) root->grp_total_scalarization = 0; }
[Bug fortran/69419] ICE: tree check: expected array_type, have real_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69419 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-22 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed: from 4.8 up to 5.3 the ICE is a Segmentation fault and the ICE is in gfc_conv_array_initializer, at fortran/trans-array.c for trunk (6.0).
[Bug c++/55843] ICE after exceeding template instantiation depth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55843 --- Comment #1 from Paolo Carlini --- This is fixed in trunk and 5.x. I'm adding a testcase and closing the bug.
[Bug fortran/69420] ICE: tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69420 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-22 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed: from 4.8 up to 5.3 the ICE is a Segmentation fault and the ICE is in gfc_conv_array_initializer, at fortran/trans-array.c for trunk (6.0). Related to pr69419. Note I am not sure that the code is valid.
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393
--- Comment #10 from rguenther at suse dot de ---
On Fri, 22 Jan 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393
>
> --- Comment #9 from Jakub Jelinek ---
> Yes, the type is meant to go into the debug info. But it is DECL_NAMELESS, so
> the debug info should not contain DW_AT_name or linkage name for it.
So is_naming_typedef_decl should check DECL_NAMELESS? Like so?
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 232717)
+++ gcc/dwarf2out.c (working copy)
@@ -22970,6 +22970,7 @@ is_naming_typedef_decl (const_tree decl)
{
if (decl == NULL_TREE
|| TREE_CODE (decl) != TYPE_DECL
+ || DECL_NAMELESS (decl)
|| !is_tagged_type (TREE_TYPE (decl))
|| DECL_IS_BUILTIN (decl)
|| is_redundant_typedef (decl)
this unfortunately doesn't fix the ICE for me because we don't
stream DECL_NAMELESS it seems. If I fix that the fix above works.
The lack of consistency between where free-lang-data forces a assembler
name and the debug
expectation is disturbing (I suppose with -fno-lto-odr-type-merging
it would ICE all over the place)
[Bug fortran/69423] [6 Regression] Invalid optimization with deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69423 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-22 CC||pault at gcc dot gnu.org Known to work||5.3.0 Blocks||68241 Target Milestone|--- |6.0 Summary|Invalid optimization|[6 Regression] Invalid ||optimization with ||deferred-length character Ever confirmed|0 |1 Known to fail||6.0 --- Comment #1 from Dominique d'Humieres --- Works with r232023, but not with r232451. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 [Bug 68241] [meta-bug] Deferred-length character
[Bug fortran/69422] Unexpected result with allocatable character type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69422 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-22 CC||pault at gcc dot gnu.org Blocks||68241 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 [Bug 68241] [meta-bug] Deferred-length character
[Bug middle-end/66877] [6 Regression] FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_over_widening_pattern: detected" 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66877 alalaw01 at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED CC||alalaw01 at gcc dot gnu.org Assignee|rguenth at gcc dot gnu.org |alalaw01 at gcc dot gnu.org --- Comment #7 from alalaw01 at gcc dot gnu.org --- I can test on ARM ;), so taken - https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01727.html.
[Bug libstdc++/69116] [4.9/5/6 Regression] compile error when including valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69116 Jonathan Wakely changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #6 from Jonathan Wakely --- OK thanks for looking, I'll try constraining the valarray operator overloads.
[Bug c++/55843] ICE after exceeding template instantiation depth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55843 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini --- Done.
[Bug c++/55843] ICE after exceeding template instantiation depth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55843 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Jan 22 11:03:54 2016 New Revision: 232721 URL: https://gcc.gnu.org/viewcvs?rev=232721&root=gcc&view=rev Log: 2016-01-22 Paolo Carlini PR c++/55843 * g++.dg/template/pr55843.C: New. Added: trunk/gcc/testsuite/g++.dg/template/pr55843.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/69328] [6 Regression] ice in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1379 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69328 Ilya Enkovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Ilya Enkovich --- Fixed
[Bug c/69429] New: gcc create sparse exec/libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69429 Bug ID: 69429 Summary: gcc create sparse exec/libs Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: joakim.tjernlund at transmode dot se Target Milestone: --- When building small libs/exec on ppc32 I usally get sparse files like so: ls -lsh | sort -n 64K -rwxr-xr-x 1 jocke users 68K Jan 22 11:20 mgmt_alarmd* 64K -rwxr-xr-x 1 jocke users 67K Jan 22 11:20 ne_memd* 56K -rwxr-xr-x 1 jocke users 67K Jan 22 11:20 cp_dummy* 56K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 mgmt_pmd* 48K -rwxr-xr-x 1 jocke users 69K Jan 22 11:20 ntpdate* 48K -rwxr-xr-x 1 jocke users 67K Jan 22 11:20 ne_rc* 48K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 relayd* 48K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ntptimeset* 44K -rwxr-xr-x 1 jocke users 67K Jan 22 11:20 mgmt_backup_tftpd* 44K -rwxr-xr-x 1 jocke users 67K Jan 22 11:20 emxp2_cm_bl_shell* 44K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 msntp* 44K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 cp_hw_i2c* 36K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 te_monitor* 36K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 mgmt_invd* 36K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 chat* 36K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 cgi-fcgi* 32K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ne_db_mgr* 32K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 dummy_hw_bl* 32K -rwxr-xr-x 1 jocke users 29K Jan 22 11:19 net-snmp-config* 28K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 tosv_server* 28K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 te_log* 28K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ntptrace* 28K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 hwdata* 24K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 te* 24K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 heat_test* 24K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 alib_psupd* 24K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 alib_memsupd* 20K -rwxr-xr-x 1 jocke users 68K Jan 22 11:20 ntptime* 20K -rwxr-xr-x 1 jocke users 68K Jan 22 11:20 dumpicn* 20K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 te_server* 20K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 mgmt_named* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 up_util_test_pmem* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 tosv_timer* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 tosv_test* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 tosv_supv* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ne_rc_supv* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ne_rc_memeater* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ne_rc_load* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 ne_mem_ram_test* 16K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 alib_test_psup* 16K -rwxr-xr-x 1 jocke users 16K Jan 22 11:15 convert_backup* 15M -rwxr-xr-x 1 jocke users 15M Jan 22 11:20 emxp2_hw_bl* 12K -rwxr-xr-x 1 jocke users 9.0K Jan 22 11:18 swu_prepost_script.sh* 12K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 tickadj* 12K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 tclsh8.4* 12K -rwxr-xr-x 1 jocke users 66K Jan 22 11:20 genkeys* downgraded binutils from 2.25.1 to 2.24 but the problem remains. Using earlier toolchain I can see that this extra sparse space is just garbage because there the files are much smaller, some 12-16KB This is a huge problem as these sparse file are packaged into a tar file and when unpacked they loose the sparse and will expand to 66K on disk and fill up the my small FS.
[Bug debug/66668] [6 regression] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 --- Comment #11 from Dominik Vogt --- The problem is gone with this fix on s390 and s390x, and check-gcc doesn't show any regressions. (Haven't run a full check though.)
[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421 Jakub Jelinek changed: What|Removed |Added CC||ienkovich at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- I see there confusion on the sign of element's type of vector boolean types - build_truth_vector_type / build_nonstandard_boolean_type creates a signed element type, while get_vectype_for_scalar_type_and_size creates unsigned element type. Plus for some strange reason the last argument is getting a V2DI mode vector type instead of expected vector boolean V16QI. Ilya, can you please have a look?
[Bug target/64411] ICE: in verify_target_availability, at sel-sched.c:1577 with -Os -mcmodel=medium -fPIC -fschedule-insns -fselective-scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64411 --- Comment #2 from Andrey Belevantsev --- Created attachment 37432 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37432&action=edit patch In this case, we get an inconsistency between the sched-deps interface, saying we can't move an insn writing si register through a vector insn, and the liveness analysis, saying we can. The latter doesn't take into account implicit_reg_pending_clobbers set calculated in sched-deps before register allocation. The solution is to reflect this set in our insn data (sets/uses/clobbers). An interesting thing would be to check what happens with the register allocator if we'd actually moved one insn past the other.
[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012 --- Comment #18 from Nick Clifton --- Hi Bernd, > I am still unsure, if we shouldn't also do something like this, > to prevent any remaining possibility for a further regression: > + /* Don't change the frame info after reload completed. */ > + if (reload_completed) > +return; Actually that might not be a bad idea. Or maybe, to be even more paranoid, we should check that a post-reload frame computation matches the last pre-reload frame computation. Hmm, maybe that is going to far. Anyway I like your patch idea, but I cannot approve it. Maybe the MIPS maintainers will like it... Cheers Nick
[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385 --- Comment #13 from janus at gcc dot gnu.org --- (In reply to Paul Thomas from comment #11) > Changing the entire block to: > [...] > fixes Martin's problem and makes the following work correctly: It also cures my problem, i.e. comment 5. Thanks a lot for the fix! > For some reason that I cannot for the life of me understand, my svn+ssh > connection from my laptop is failing because of some problem with my public > keys. I recently got an email from the sourceware admins which said they are currently scanning the ssh keys for continued compatibility. Possibly you need to generate a new key (in case yours is too weak). Mine is apparently still working, luckily.
[Bug libstdc++/69295] [6 Regression] New special math function failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295
--- Comment #8 from Jakub Jelinek ---
On i686-linux, it is clearly a matter of excess precision that sometimes
substantially changes the result. With -mfpmath=sse -msse2 or -ffloat-store it
passes.
The abs errors for various tests that fail are (first NNN in test(dataNNN,
tolerNNN), then max_abs_frac, then tolerNNN), the patch I've used was:
@@ -11554,7 +11554,7 @@ const double toler245 = 2.50
template
void
- test(const testcase_hyperg (&data)[Num], Tp toler)
+ test(const testcase_hyperg (&data)[Num], Tp toler, int nnn)
{
bool test __attribute__((unused)) = true;
const Tp eps = std::numeric_limits::epsilon();
@@ -11576,256 +11576,258 @@ template
max_abs_frac = std::abs(frac);
}
}
-VERIFY(max_abs_frac < toler);
+if (max_abs_frac >= toler)
+ __builtin_printf ("%d %a %a\n", nnn, max_abs_frac, toler);
+//VERIFY(max_abs_frac < toler);
}
plus adjusting all the test(dataNNN, tolerNNN); calls to test(dataNNN,
tolerNNN, NNN);
167 0x1.8ab4f2f1f35bcp-40 0x1.19799812dea15p-42
171 0x1.890df8f35d42ep-38 0x1.19799812dea15p-42
172 0x1.1acd4227e561bp-34 0x1.19799812dea15p-42
173 0x1.6f73999c8e5adp-40 0x1.19799812dea15p-42
197 0x1.8ab4f2f1f35bcp-40 0x1.19799812dea15p-42
201 0x1.d4e2f28348906p-39 0x1.19799812dea15p-42
202 0x1.afc3fee12aee8p-36 0x1.19799812dea15p-42
203 0x1.9f229da628598p-39 0x1.19799812dea15p-42
204 0x1.949b76928c351p-40 0x1.19799812dea15p-42
206 0x1.24585756ecfbap-33 0x1.19799812dea15p-42
207 0x1.662797d1185e5p-31 0x1.19799812dea15p-42
208 0x1.27de1e24e6ac3p-27 0x1.19799812dea15p-42
209 0x1.a0ac9ec2d7f45p-34 0x1.19799812dea15p-42
231 0x1.890df8f35d42ep-38 0x1.19799812dea15p-42
232 0x1.1acd4227e561bp-34 0x1.19799812dea15p-42
233 0x1.6f73999c8e5adp-40 0x1.19799812dea15p-42
236 0x1.24585756ecfbap-33 0x1.19799812dea15p-42
237 0x1.662797d1185e5p-31 0x1.19799812dea15p-42
238 0x1.27de1e24e6ac3p-27 0x1.19799812dea15p-42
239 0x1.a0ac9ec2d7f45p-34 0x1.19799812dea15p-42
241 0x1.67ee0388ff7a7p-27 0x1.19799812dea15p-42
242 0x1.7aa254470eb52p-26 0x1.19799812dea15p-42
243 0x1.fb4f73983f28cp-19 0x1.19799812dea15p-42
244 0x1.3b46fd92feda9p-22 0x1.19799812dea15p-42
245 0x1.58d8d7350d864p-21 0x1.19799812dea15p-42
What are the problematic tests on powerpc* (that one is not excess precision
target though)? Would it be acceptable to just increase the tolerNNN values
mentioned above (plus whatever powerpc needs)?
[Bug libstdc++/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69331 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421 Ilya Enkovich changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #9 from Ilya Enkovich --- Here we don't check boolean values get compatible vectypes when analyze VEC_COND statement. Here statement gets V16QI mode due to boolean type size. And one of its operand gets V2DI mode because it is a result of comparison of doubles. We have patterns to catch such cases and add additional mask conversion for comparison and bit operations but don't have them for VEC_COND. Suppose vectorization of such cases should be delayed until stage1. For now this patch helps to compile both reduced and original tests: diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c index 1d2246d..8cb1bfe 100644 --- a/gcc/tree-vect-stmts.c +++ b/gcc/tree-vect-stmts.c @@ -7528,6 +7528,7 @@ vectorizable_condition (gimple *stmt, gimple_stmt_iterator *gsi, tree vectype = STMT_VINFO_VECTYPE (stmt_info); int nunits = TYPE_VECTOR_SUBPARTS (vectype); + tree vectype1 = NULL_TREE, vectype2 = NULL_TREE; if (slp_node || PURE_SLP_STMT (stmt_info)) ncopies = 1; @@ -7547,9 +7548,19 @@ vectorizable_condition (gimple *stmt, gimple_stmt_iterator *gsi, return false; gimple *def_stmt; - if (!vect_is_simple_use (then_clause, stmt_info->vinfo, &def_stmt, &dt)) + if (!vect_is_simple_use (then_clause, stmt_info->vinfo, &def_stmt, &dt, + &vectype1)) +return false; + if (!vect_is_simple_use (else_clause, stmt_info->vinfo, &def_stmt, &dt, + &vectype2)) return false; - if (!vect_is_simple_use (else_clause, stmt_info->vinfo, &def_stmt, &dt)) + + if (vectype1 + && TYPE_VECTOR_SUBPARTS (vectype1) != TYPE_VECTOR_SUBPARTS (vectype)) +return false; + + if (vectype2 + && TYPE_VECTOR_SUBPARTS (vectype2) != TYPE_VECTOR_SUBPARTS (vectype)) return false; masked = !COMPARISON_CLASS_P (cond_expr);
[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421 --- Comment #10 from Jakub Jelinek --- Wouldn't a useless_type_conversion_p check be better instead of just testing number of elements?
[Bug c++/68949] [5/6 Regression] Implicit initialization of array member silently miscompiling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68949 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-22 Ever confirmed|0 |1
[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421 --- Comment #11 from Ilya Enkovich --- (In reply to Jakub Jelinek from comment #10) > Wouldn't a useless_type_conversion_p check be better instead of just testing > number of elements? Yep. Will use it.
[Bug c++/68514] [6 Regression] ICE in tr1/5_numerical_facilities libstdc++ test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68514 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Can you still reproduce it? If yes, can you attach preprocessed source for one of those, so it can be reduced even with a cross-compiler?
[Bug c++/68514] [6 Regression] ICE in tr1/5_numerical_facilities libstdc++ test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68514 --- Comment #2 from Rainer Emrich --- I'm starting bootstrap and testsuite run at the moment, will take some hours.
[Bug c/69429] gcc create sparse exec/libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69429 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- Why do you file this against gcc? If anything, it is related to binutils, which is separate project. But, I'd say it is not a bug nevertheless, sparse files are an optimization, if you want to force no use of sparse files, you'd just always get the larger ones. If using tar doesn't preserve holes in sparse files, use other means of copying them.
[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384 Andrey Belevantsev changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-22 Ever confirmed|0 |1 --- Comment #5 from Andrey Belevantsev --- We're looping because we decrease the counter of the insns we still can issue (can_issue_more) on a DEBUG_INSN. The following helps us to get away with it but frankly I have no idea why it was not surfaced before -- no such insns with usual debug info? diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c index c798935..893a3e5 100644 --- a/gcc/sel-sched.c +++ b/gcc/sel-sched.c @@ -4249,7 +4249,8 @@ invoke_aftermath_hooks (fence_t fence, rtx_insn *best_insn, int issue_more) issue_more); memcpy (FENCE_STATE (fence), curr_state, dfa_state_size); } - else if (GET_CODE (PATTERN (best_insn)) != USE + else if (! DEBUG_INSN_P (best_insn) + && GET_CODE (PATTERN (best_insn)) != USE && GET_CODE (PATTERN (best_insn)) != CLOBBER) issue_more--;
[Bug c++/68357] [6 Regression] FAIL: g++.dg/other/darwin-cfstring1.C -std=* (internal compiler error) on x86_64-apple-darwin1(0|4|5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68357 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Can you attach preprocessed source for the testcase?
[Bug rtl-optimization/69238] [4.9/5/6 Regression] gcc.dg/vect/vect-multitypes-1.c FAILs with -O2 -fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69238 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- Let's just close it as a DUP. *** This bug has been marked as a duplicate of bug 69195 ***
[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195 --- Comment #5 from Jakub Jelinek --- *** Bug 69238 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/69195] [4.9/5/6 Regression] gcc.dg/torture/pr44913.c FAILs with -O3 -fno-dce -fno-forward-propagate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195 --- Comment #6 from Jakub Jelinek --- Once we have a fix, please make sure to also check the PR69238 testcase and add it into the testsuite.
[Bug c/69429] gcc create sparse exec/libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69429 --- Comment #2 from joakim.tjernlund at transmode dot se --- (In reply to Jakub Jelinek from comment #1) > Why do you file this against gcc? If anything, it is related to binutils, You are right, I though it was a gcc problem because I downgraded binutils to 2.24 but not I ses I only thought I did so. > which is separate project. But, I'd say it is not a bug nevertheless, > sparse files are an optimization, if you want to force no use of sparse > files, you'd just always get the larger ones. If using tar doesn't preserve > holes in sparse files, use other means of copying them. Well, it breaks and tar cannot handle these sparse files and I think a lot of packing tools uses tar. I cannot change to something else on my targets as there is only tar installed I found this binutils 2.15.x commit: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=9059a151e33f2f9b7b989a22e63d711a2c8a335b;hp=6e7e69e72dc1c53c8d5a8794c845026c48ff343a (Set ppc COMMONPAGESIZE to 64k) I do wonder why it now became necessary to increase page size in binutils?
[Bug c++/69327] [6 Regression] constexpr leaves reference member var uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69327
Matthias Klose changed:
What|Removed |Added
Last reconfirmed||2016-1-22
CC||doko at gcc dot gnu.org
Known to work||5.3.1
Summary|constexpr leaves reference |[6 Regression] constexpr
|member var uninitialized|leaves reference member var
||uninitialized
Known to fail||6.0
--- Comment #1 from Matthias Klose ---
$ cat tst.cc
struct S {
constexpr S(int & x): n(x) {}
int & n;
};
constexpr S f1(int & x) { return S(x); }
constexpr S f2(int & x) { return f1(x); }
S f3(int & x) { return f2(x); }
int main() {
int n = 1;
return f3(n).n;
}
$ g++ -std=c++11 tst.cc && ./a.out
Segmentation fault (core dumped)
[Bug libstdc++/69413] [6 Regression] r232327 prevents libstdc++ working after upgrading glibc to 2.23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69413 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Fri Jan 22 12:47:26 2016 New Revision: 232726 URL: https://gcc.gnu.org/viewcvs?rev=232726&root=gcc&view=rev Log: Allow _GLIBCXX_HAVE_OBSOLETE_ISINF_ISNAN to be overridden PR libstdc++/69413 * config/os/gnu-linux/os_defines.h: Define _GLIBCXX_NO_OBSOLETE_ISINF_ISNAN_DYNAMIC. * include/c_global/cmath (isinf, isnan): Check it. * doc/xml/manual/internals.xml: Document it. * doc/html/*: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/os/gnu-linux/os_defines.h trunk/libstdc++-v3/doc/html/manual/internals.html trunk/libstdc++-v3/doc/xml/manual/internals.xml trunk/libstdc++-v3/include/c_global/cmath
[Bug c/69429] gcc create sparse exec/libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69429 --- Comment #3 from Jakub Jelinek --- Because most of the powerpc distros now use 64KB page size instead of 4KB, so having only 4KB common page size means security protection of relro area usually does not work or covers smaller amount of data. You can probably use -z common-page-size=4096 if you are sure you are never going to run your binaries on a kernel with 64KB pages.
[Bug libstdc++/69413] [6 Regression] r232327 prevents libstdc++ working after upgrading glibc to 2.23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69413 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- GCC 6 will now work if it is built against glibc <= 2.22 and then glibc is upgraded to >= 2.23 Using recent glibc 2.22 snapshots from git still requires rebuilding libstdc++. Specifically, if you build GCC against glibc before https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d9b965fa56350d6eea9f7f438a0714c7ffbb183f and then update glibc to a snapshot of 2.22 from git master after that commit, libstdc++ will not work. In that case glibc still reports itself as 2.22 and libstdc++ won't detect that the isinf and isnan declarations are gone, so must be reconfigured and rebuilt against the new glibc headers. When glibc releases 2.23 it weill be possible to upgrade to that without rebuilding libstdc++, because the version bump will tell libstdc++ the functions are gone.
[Bug c++/69327] [6 Regression] constexpr leaves reference member var uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69327 Matthias Klose changed: What|Removed |Added Keywords||wrong-code --- Comment #2 from Matthias Klose --- r232725
[Bug c++/69327] [6 Regression] constexpr leaves reference member var uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69327 --- Comment #3 from Jonathan Wakely --- (In reply to Matthias Klose from comment #2) > r232725 That commit is newer than Stephan's original report.
[Bug c++/69327] [6 Regression] constexpr leaves reference member var uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69327 --- Comment #4 from Matthias Klose --- more verbose: still seen with r232725
[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #10)
> I understand everything you're saying Richi. Note however that the MIPS
> backend explicitly wants to align things based on the object's alignment --
> even scalars passed in registers:
And that is the bug, backend should never do that.
Alignment of a scalar object is a property of that object, but if you pass it
by value, you just pass the value, so copy it to some other location.
Except for calls to unprototyped C (and Fortran) functions, one could argue
that some ABI could be using the alignment of the argument type on the function
definition (and require declarations to be matching). But with calls to
unprototyped functions this becomes major problem.
As for ARM, the questions are what the compiler will do say on:
typedef int alignedint __attribute__((aligned(8)));
int __attribute__((weak)) foo (int a, alignedint b)
{ return b;}
void bar (alignedint x)
{
foo (1, x);
}
void
bar2 (alignedint x)
{
foo (1, (alignedint) 1);
}
void
bar3 (alignedint x)
{
foo (1, x + (alignedint) 1);
}
alignedint q;
void
bar4 (alignedint x)
{
foo (1, q);
}
extern int baz (int, int);
void
bar5 (alignedint x)
{
baz (1, x);
}
[Bug tree-optimization/69376] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69376 --- Comment #5 from Richard Biener --- Created attachment 37433 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37433&action=edit patch Patch that I have tested but which exposes another latent issue? FAIL: 21_strings/basic_string/requirements/exception/generation_prohibited.cc ex ecution test FAIL: ext/vstring/requirements/exception/generation_prohibited.cc execution test on x86_64 both -m32 and -m64 with allocating gigabytes of memory and eventually throwing bad_alloc (). -fno-tree-pre recovers from this, so does -fno-tree-vrp (as expected), so does disabling only vrp2 (or vrp1).
[Bug c++/56260] [C++11] GCC hangs/crashes on invalid source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56260 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #1 from Paolo Carlini --- Mine.
[Bug tree-optimization/69376] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69376 --- Comment #6 from Jakub Jelinek --- (In reply to Richard Biener from comment #5) > Created attachment 37433 [details] > patch > > Patch that I have tested but which exposes another latent issue? That patch LGTM. > FAIL: > 21_strings/basic_string/requirements/exception/generation_prohibited.cc ex > ecution test > FAIL: ext/vstring/requirements/exception/generation_prohibited.cc execution > test > > > on x86_64 both -m32 and -m64 with allocating gigabytes of memory and > eventually throwing bad_alloc (). -fno-tree-pre recovers from this, so does > -fno-tree-vrp > (as expected), so does disabling only vrp2 (or vrp1). Are you going to debug those, or shall I have a look?
[Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
If cygwin or mingw or what wants to ensure EH_FRAME_SECTION_NAME is not set to
the default, then perhaps allow it to be set to NULL too, and change the few
uses of that macro, like:
#ifdef EH_FRAME_SECTION_NAME
eh_frame_section = get_section (EH_FRAME_SECTION_NAME, flags, NULL);
#else
eh_frame_section = ((flags == SECTION_WRITE)
? data_section : readonly_data_section);
#endif /* EH_FRAME_SECTION_NAME */
to
#ifdef EH_FRAME_SECTION_NAME
if (EH_FRAME_SECTION_NAME != NULL)
eh_frame_section = get_section (EH_FRAME_SECTION_NAME, flags, NULL);
else
#endif
eh_frame_section = ((flags == SECTION_WRITE)
? data_section : readonly_data_section);
and
#ifdef EH_FRAME_SECTION_NAME
builtin_define_with_value ("__LIBGCC_EH_FRAME_SECTION_NAME__",
EH_FRAME_SECTION_NAME, 1);
#endif
to
#ifdef EH_FRAME_SECTION_NAME
if (EH_FRAME_SECTION_NAME != NULL)
builtin_define_with_value ("__LIBGCC_EH_FRAME_SECTION_NAME__",
EH_FRAME_SECTION_NAME, 1);
#endif
and then just #define EH_FRAME_SECTION_NAME NULL for the ports that need that
(and add big comment why). You'd need to adjust also the tm.texi documentation
to explain that NULL means use the data sections as if named sections weren't
supported.
[Bug libstdc++/69413] [6 Regression] r232327 prevents libstdc++ working after upgrading glibc to 2.23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69413 --- Comment #3 from Dominik Vogt --- So, what is the proper way to compile -- snip -- #include -- snip -- using a current Gcc compiled with an old system Glibc so that the program uses a new (not installed) Glibc? The hack I tried earlier still does not work: $ g++ -std=c++11 x.C -v \ --sysroot ~/src/git/glibc/install \ -idirafter ~/src/git/glibc/install/usr/include \ -idirafter /usr/local/include \ -idirafter /usr/include ... ignoring nonexistent directory "~/src/git/glibc/install/usr/local/include" ignoring nonexistent directory "~/src/git/gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/../../../../s390x-ibm-linux-gnu/include" ignoring duplicate directory "~/src/git/glibc/install/usr/include" #include "..." search starts here: #include <...> search starts here: ~/src/git/gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/../../../../include/c++/6.0.0 ~/src/git/gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/../../../../include/c++/6.0.0/s390x-ibm-linux-gnu ~/src/git/gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/../../../../include/c++/6.0.0/backward ~/src/git/gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/include ~/src/git/gcc/install/include ~/src/git/gcc/install/lib/gcc/s390x-ibm-linux-gnu/6.0.0/include-fixed ~/src/git/glibc/install/usr/include /usr/local/include /usr/include End of search list. of search list. ...
[Bug tree-optimization/69376] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69376 --- Comment #7 from Richard Biener --- Ah, forgot to update free_scc_vn - retesting.
[Bug target/69403] [4.9/5/6 Regression] Wrong thumb2_ior_scc_strict_it insn pattern.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69403 --- Comment #4 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Jan 22 13:58:11 2016 New Revision: 232727 URL: https://gcc.gnu.org/viewcvs?rev=232727&root=gcc&view=rev Log: [ARM] Fix PR target/69403: Bug in thumb2_ior_scc_strict_it pattern PR target/69403 * config/arm/thumb2.md (*thumb2_ior_scc_strict_it): Convert to define_insn_and_split. Ensure operands[1] and operands[0] do not get assigned the same register. * gcc.c-torture/execute/pr69403.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr69403.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/thumb2.md trunk/gcc/testsuite/ChangeLog
[Bug c++/69327] [6 Regression] constexpr leaves reference member var uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69327 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #5 from Jakub Jelinek --- Started with r230365. In the testcase for testsuite you want f3(n).n == 1 instead, otherwise it will fail with non-zero return code even if not miscompiled.
[Bug tree-optimization/69376] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69376 --- Comment #8 from Bernd Schmidt --- Why not put this bit into range_info_def so as to not have the information scattered across two different places? Seems like it would be more robust and more readable.
[Bug tree-optimization/69376] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69376 --- Comment #9 from Jakub Jelinek --- (In reply to Bernd Schmidt from comment #8) > Why not put this bit into range_info_def so as to not have the information > scattered across two different places? Seems like it would be more robust > and more readable. It would, but it would increase the size of it by 64 bits. As we want to use these more and more, even for IPA VRP, the memory footprint of the range info matters.
[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674 --- Comment #16 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Fri Jan 22 14:16:47 2016 New Revision: 232728 URL: https://gcc.gnu.org/viewcvs?rev=232728&root=gcc&view=rev Log: 2016-01-22 Christian Bruel PR target/68674 * expr.c (expand_expr_real_1): Reset DECL_MODE if VECTOR_TYPE_P changed. // testsuite 2016-01-21 Christian Bruel PR target/68674 * gcc.target/i386/pr68674.c * gcc.target/aarch64/pr68674.c * gcc.target/arm/pr68674.c Added: trunk/gcc/testsuite/gcc.target/aarch64/pr68674.c trunk/gcc/testsuite/gcc.target/arm/pr68674.c trunk/gcc/testsuite/gcc.target/i386/pr68674.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Comment #11 from Markus Trippelsdorf ---
trippels@CFARM-IUT-TLSE3 ~ % cat STAR.ii
class A {
public:
int runThreadN, outBAMsortingThreadNactual;
};
class B {
public:
long *binTotalN;
};
class C {
public:
B *chunkOutBAMcoord;
};
main() {
A *P;
C *a[P->runThreadN];
#pragma omp parallel num_threads(P->outBAMsortingThreadNactual)
int b = a[0]->chunkOutBAMcoord->binTotalN[0];
}
trippels@CFARM-IUT-TLSE3 ~ % g++ -r -nostdlib -flto -g -O2 -fopenmp STAR.ii
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:27200
[Bug c++/68514] [6 Regression] ICE in tr1/5_numerical_facilities libstdc++ test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68514 --- Comment #3 from Rainer Emrich --- Will take more time, trunk doesn't bootstrap atm. I have to investigate.
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393 --- Comment #12 from Markus Trippelsdorf --- Perhaps "-shared -fPIC" instead of "-r -nostdlib" should be used for the testsuite.
[Bug libstdc++/69413] [6 Regression] r232327 prevents libstdc++ working after upgrading glibc to 2.23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69413 --- Comment #4 from Jonathan Wakely --- (In reply to Dominik Vogt from comment #3) > So, what is the proper way to compile > > -- snip -- > #include > -- snip -- > > using a current Gcc compiled with an old system Glibc so that the program > uses a new (not installed) Glibc? You can't, that's not supported. As I said, if you want to use glibc 2.22 headers from after the mentioned commit, libstdc++ must be built with those same headers. I thought this was fairly explicit: (In reply to Jonathan Wakely from comment #2) > Specifically, if you build GCC against glibc before > https://sourceware.org/git/gitweb.cgi?p=glibc.git; > h=d9b965fa56350d6eea9f7f438a0714c7ffbb183f and then update glibc to a > snapshot of 2.22 from git master after that commit, libstdc++ will not work. > In that case glibc still reports itself as 2.22 and libstdc++ won't detect > that the isinf and isnan declarations are gone, so must be reconfigured and > rebuilt against the new glibc headers. As a quick hack you can bump the value of __GLIBC_MINOR__ in ~/src/git/glibc/install/usr/include/features.h to make it appear to be glibc 2.23, but obviously that isn't supported either.
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393
--- Comment #13 from Jakub Jelinek ---
More reduced testcase:
int e = 5;
int
main ()
{
int a[e];
a[0] = 6;
#pragma omp parallel
if (a[0] != 6)
__builtin_abort ();
return 0;
}
Or it can be put into libgomp/testsuite/libgomp.c++/ and just have
// { dg-do run }
// { dg-options "-flto -g -fopenmp" }
?
[Bug fortran/69397] ICE on missing subprogram in generic interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69397 Jerry DeLisle changed: What|Removed |Added Status|WAITING |ASSIGNED
[Bug target/63681] ICE in cfg_layout_initialize, at cfgrtl.c:4233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681 Bernd Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Bernd Schmidt --- Done.
[Bug libstdc++/69116] [4.9/5/6 Regression] compile error when including valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69116
--- Comment #7 from Jonathan Wakely ---
The problem overload is this one:
template
inline _Expr<_BinClos<__shift_left, _Constant, _ValArray, _Tp, _Tp>, typename
__fun<__shift_left, _Tp>::result_type>
operator <<(const _Tp& __t, const valarray<_Tp>& __v)
{
typedef _BinClos<__shift_left, _Constant, _ValArray, _Tp, _Tp> _Closure;
typedef typename __fun<__shift_left, _Tp>::result_type _Rt;
return _Expr<_Closure, _Rt>(_Closure(__t, __v));
}
That deduces _Tp as x and so tries to instantiate valarray to see if __v can
be initialized from std::endl, which causes the "invalid abstract return type"
outside the immediate context.
It can be fixed using enable_if (or __gnu_cxx::__enable_if since this is C++98
code) to reject invalid types for valarray, maybe using __is_abstract. I just
need to figure out the best place to put it, and how many of the other
overloaded operators are affected.
It might make sense to make the first argument a non-deduced context, so we
only use this operator when the RHS is really a valarray, rather than matching
for anything on the LHS and then trying to convert the RHS to a valarray. I
don't know if that would break real code using valarray.
[Bug target/63681] ICE in cfg_layout_initialize, at cfgrtl.c:4233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681 --- Comment #9 from Bernd Schmidt --- Author: bernds Date: Fri Jan 22 14:49:22 2016 New Revision: 232730 URL: https://gcc.gnu.org/viewcvs?rev=232730&root=gcc&view=rev Log: Backport PR63681 fix PR target/63681 * cfgrtl.c (cfg_layout_initialize): Weaken assert to only trigger if flag_reorder_blocks_and_partition. * hw-doloop.c (reorg_loops): Avoid reordering if that flag is set. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/cfgrtl.c branches/gcc-4_9-branch/gcc/hw-doloop.c
[Bug tree-optimization/69426] [5/6 Regression] ICE: verify_ssa failed (error: missing definition) w/ -O2 (and above) -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69426 vries at gcc dot gnu.org changed: What|Removed |Added Known to work|5.3.0 | Summary|[6 Regression] ICE: |[5/6 Regression] ICE: |verify_ssa failed (error: |verify_ssa failed (error: |missing definition) w/ -O2 |missing definition) w/ -O2 |(and above) |(and above) |-ftree-parallelize-loops=2 |-ftree-parallelize-loops=2 Known to fail||5.3.0 --- Comment #3 from vries at gcc dot gnu.org --- Reproduced (on x86_64) with 5 branch. The ICE seems to have been triggered by removing the expand_omp_local from parloops and using a separate omp_expand_ssa pass.
[Bug rtl-optimization/69430] [6 regression] stage2 miscompiled by CCMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69430 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |6.0
[Bug rtl-optimization/69430] [6 regression] stage2 miscompiled by CCMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69430 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from ktkachov at gcc dot gnu.org --- Dup. *** This bug has been marked as a duplicate of bug 69416 ***
[Bug c/69415] -Wmisleading-indentation warns on "if (__b < __a) return __b; return __a;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69415 --- Comment #9 from David Malcolm --- Similar issue seen here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811579 Package: mosh > make[5]: Entering directory '/<>/src/protobufs' ... > userinput.pb.cc: In member function 'virtual bool > ClientBuffers::Instruction::IsInitialized() const': > userinput.pb.cc:375:53: error: statement is indented as if it were guarded > by... [-Werror=misleading-indentation] >if (!_extensions_.IsInitialized()) return false; return true; > ^~ > > userinput.pb.cc:375:3: note: ...this 'if' clause, but it is not >if (!_extensions_.IsInitialized()) return false; return true; >^~ The code looks like it was autogenerated from: https://github.com/mobile-shell/mosh/blob/master/src/protobufs/userinput.proto presumably using https://github.com/google/protobuf
[Bug rtl-optimization/69430] New: [6 regression] stage2 miscompiled by CCMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69430 Bug ID: 69430 Summary: [6 regression] stage2 miscompiled by CCMP Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: jiong.wang at arm dot com Target Milestone: --- Target: aarch64-*-* make[4]: Entering directory '/opt/gcc/gcc-20160122/Build/aarch64-suse-linux/libstdc++-v3/libsupc++' /bin/sh ../libtool --tag CC --tag disable-shared --mode=compile /opt/gcc/gcc-20160122/Build/./gcc/xgcc -B/opt/gcc/gcc-20160122/Build/./gcc/ -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 -DHAVE_CONFIG_H -I.. -I/opt/gcc/gcc-20160122/libstdc++-v3/../libiberty -I/opt/gcc/gcc-20160122/libstdc++-v3/../include -prefer-pic -D_GLIBCXX_SHARED -I/opt/gcc/gcc-20160122/Build/aarch64-suse-linux/libstdc++-v3/include/aarch64-suse-linux -I/opt/gcc/gcc-20160122/Build/aarch64-suse-linux/libstdc++-v3/include -I/opt/gcc/gcc-20160122/libstdc++-v3/libsupc++-O2 -g -DIN_GLIBCPP_V3 -Wno-error -c cp-demangle.c libtool: compile: /opt/gcc/gcc-20160122/Build/./gcc/xgcc -B/opt/gcc/gcc-20160122/Build/./gcc/ -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 -DHAVE_CONFIG_H -I.. -I/opt/gcc/gcc-20160122/libstdc++-v3/../libiberty -I/opt/gcc/gcc-20160122/libstdc++-v3/../include -D_GLIBCXX_SHARED -I/opt/gcc/gcc-20160122/Build/aarch64-suse-linux/libstdc++-v3/include/aarch64-suse-linux -I/opt/gcc/gcc-20160122/Build/aarch64-suse-linux/libstdc++-v3/include -I/opt/gcc/gcc-20160122/libstdc++-v3/libsupc++ -O2 -g -DIN_GLIBCPP_V3 -Wno-error -c cp-demangle.c -fPIC -DPIC -o cp-demangle.o cp-demangle.c: In function ‘d_type’: cp-demangle.c:2346:40: internal compiler error: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code 'mem' in set_mem_attributes_minus_bitpos, at emit-rtl.c:1833 di->expansion += ret->u.s_builtin.type->len; ^ 0x5c3077 ??? ../sysdeps/aarch64/start.S:81 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. Makefile:844: recipe for target 'cp-demangle.lo' failed make[4]: *** [cp-demangle.lo] Error 1 make[4]: Leaving directory '/opt/gcc/gcc-20160122/Build/aarch64-suse-linux/libstdc++-v3/libsupc++' Makefile:507: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/opt/gcc/gcc-20160122/Build/aarch64-suse-linux/libstdc++-v3' Makefile:414: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/opt/gcc/gcc-20160122/Build/aarch64-suse-linux/libstdc++-v3' Makefile:13324: recipe for target 'all-stage2-target-libstdc++-v3' failed make[1]: *** [all-stage2-target-libstdc++-v3] Error 2 make[1]: Leaving directory '/opt/gcc/gcc-20160122/Build' Makefile:22659: recipe for target 'stage2-bubble' failed make: *** [stage2-bubble] Error 2 07bd240ed93406c063fd6f7a42e18a533f7ae556 is the first bad commit git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@232565 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/69416] [6 Regression] Nonsense rtl checking failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||sch...@linux-m68k.org --- Comment #8 from ktkachov at gcc dot gnu.org --- *** Bug 69430 has been marked as a duplicate of this bug. ***
[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from chrbr at gcc dot gnu.org --- fixed for gcc 6.0
[Bug target/69403] [4.9/5/6 Regression] Wrong thumb2_ior_scc_strict_it insn pattern.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69403 --- Comment #5 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Jan 22 15:37:50 2016 New Revision: 232733 URL: https://gcc.gnu.org/viewcvs?rev=232733&root=gcc&view=rev Log: [ARM] Fix PR target/69403: Bug in thumb2_ior_scc_strict_it pattern Backport from mainline 2016-01-22 Kyrylo Tkachov PR target/69403 * config/arm/thumb2.md (*thumb2_ior_scc_strict_it): Convert to define_insn_and_split. Ensure operands[1] and operands[0] do not get assigned the same register. * gcc.c-torture/execute/pr69403.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr69403.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/arm/thumb2.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/69403] [4.9/5/6 Regression] Wrong thumb2_ior_scc_strict_it insn pattern.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69403 --- Comment #6 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Jan 22 15:42:30 2016 New Revision: 232734 URL: https://gcc.gnu.org/viewcvs?rev=232734&root=gcc&view=rev Log: [ARM] Fix PR target/69403: Bug in thumb2_ior_scc_strict_it pattern Backport from mainline 2016-01-22 Kyrylo Tkachov PR target/69403 * config/arm/thumb2.md (*thumb2_ior_scc_strict_it): Convert to define_insn_and_split. Ensure operands[1] and operands[0] do not get assigned the same register. * gcc.c-torture/execute/pr69403.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr69403.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/arm/thumb2.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/69403] [4.9/5/6 Regression] Wrong thumb2_ior_scc_strict_it insn pattern.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69403 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from ktkachov at gcc dot gnu.org --- Fixed on all active branches. Thanks for pinpointing the problematic pattern.
[Bug c++/69428] [6 Regression] Many libstdc++ failures on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69428 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- My patch, woops.
[Bug c/69415] -Wmisleading-indentation warns on "if (__b < __a) return __b; return __a;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69415 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- I think the people who would be generally expecting indentation to mean something would not use a one liner, but instead if (foo) stmt stmt2 and if it is a one-liner, it is just much more likely that one simply wanted to stick more stuff one a single line. Perhaps have different -Wmisleading-indentation levels and warn about this only in some non-default 2nd level, not the first one?
[Bug c++/60177] Unable to deduce template base of derived class in call to function taking a `simple-template-id`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60177 Ville Voutilainen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Ville Voutilainen --- This looks like a duplicate of a much older PR. *** This bug has been marked as a duplicate of bug 42329 ***
[Bug c++/42329] Deduction of template template argument via base class fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42329 Ville Voutilainen changed: What|Removed |Added CC||filip.roseen at gmail dot com --- Comment #1 from Ville Voutilainen --- *** Bug 60177 has been marked as a duplicate of this bug. ***
[Bug c++/42329] Deduction of template template argument via base class fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42329 --- Comment #2 from Jonathan Wakely --- A more recent EDG than Comeau 4.3 still accepts this, Clang gives the same errors as GCC.
[Bug target/69431] New: There should be builtins for PowerPC mtfsb0, mtfsb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69431 Bug ID: 69431 Summary: There should be builtins for PowerPC mtfsb0, mtfsb1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- Target: powerpc*-*-* As it is, ppu_intrinsics.h has some support for mtfsb[01], nothing else does.
[Bug lto/69394] [5.3] ICE when linking with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394 --- Comment #4 from Daniel Starke --- I see, but the output of the same GCC version should be the same regardless the host if the target is the same, right? I used the same source tree to build GCC 5.3.0 for x86_64-linux-gnu and for x86_64-w64-mingw32 host, both targeting x86_64-w64-mingw32. When I compile for example libsqlite3 on x86_64-w64-mingw32 with LTO enabled and try to link it on x86_64-linux-gnu, I get the ICE. If I compile libsqlite on x86_64-linux-gnu with the same options it works without an issue. So I guess the LTO format does not only depend on the used GCC version but also on the host. But this would be something I do not expect. Having the same GCC version (in all 3 places) and the same target should also give me the same result IMHO. Nevertheless, should I create a new PR for the problem with the non-executable result? I fail for example to run boost_1_54_0/libs/program_options/example/first.cpp on Windows, when I enable LTO on my Linux host.
[Bug c++/33911] attribute deprecated vs. templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911
Elias Pipping changed:
What|Removed |Added
CC||pipping at exherbo dot org
--- Comment #18 from Elias Pipping ---
The current status (with gcc 5.3) of these deprecation warnings is quite
surprising: from my point of view there are both false negatives and false
positives. Since clang's behaviour, additionally, differs considerably from
gcc's, it's currently almost impossible to deprecate something in a portable
fashion.
Here's an example. Let's assume I've reimplemented enable_if and want to
deprecated it.
namespace Dune {
template
struct [[deprecated]] enable_if
{};
template
struct enable_if
{
typedef T type;
};
}
This generates a warning even if enable_if is never used anywhere, simply
through the template specialisation (if I were to remove the specialisation,
the warning would go away):
% g++ -c -std=c++14 test.cc -Wall -Wextra
test.cc:7:10: warning: ‘template struct Dune::enable_if’ is
deprecated [-Wdeprecated-declarations]
struct enable_if
^
test.cc:3:25: note: declared here
struct [[deprecated]] enable_if
^
%
Clang does not emit a warning here.
Fair enough, maybe I should deprecate specialisations rather than the template.
But this does not work as expected, either. The following code surprisingly
does not emit a single warning:
#include
namespace Dune {
template
struct enable_if
{};
template
struct [[deprecated]] enable_if
{};
template
struct [[deprecated]] enable_if
{
typedef T type;
};
}
int
main()
{
using newint = Dune::enable_if::value,int>::type;
newint i = 2;
++i;
}
[Bug c/69415] -Wmisleading-indentation warns on "if (__b < __a) return __b; return __a;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69415 --- Comment #11 from David Malcolm --- Contrast with: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811591 which has lots of one-liners e.g. http://sources.debian.net/src/ifhp/3.5.20-13/src/ifhp.c/#L1348 which is: if( tempfd > 0 ) close(tempfd); tempfd = -1; Another example from this one: if( hash ) FREE_OBJ( hash ); hash = 0; All of these seem to be in the idiom of "clean up FOO if necessary; reset FOO always".
[Bug target/69416] [6 Regression] Nonsense rtl checking failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416 --- Comment #9 from Richard Henderson --- Author: rth Date: Fri Jan 22 17:21:41 2016 New Revision: 232737 URL: https://gcc.gnu.org/viewcvs?rev=232737&root=gcc&view=rev Log: PR target/69416 * config/aarch64/aarch64.md (UNSPEC_NZCV): New. (ccmp, fccmp, fccmpe): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md
[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #18 from Paolo Carlini --- Fixed then.
[Bug other/69432] New: ICE in connect_traces, at dwarf2cfi.c with -O3 -m32 -minline-stringops-dynamically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69432
Bug ID: 69432
Summary: ICE in connect_traces, at dwarf2cfi.c with -O3 -m32
-minline-stringops-dynamically
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: i686-linux
Created attachment 37434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37434&action=edit
C-reduced testcase
The attached testcase is reduced from cromfs-1.5.10.2.
On my x86_64-linux desktop, compiling with
path_to_trunk/inst/bin/g++ -O3 -m32 -minline-stringops-dynamically -S
creduced.C
leads to:
creduced.C: In function ‘void LZMADeCompress()’:
creduced.C:63:33: internal compiler error: in connect_traces, at
dwarf2cfi.c:2752
void LZMADeCompress() { F b(a); }
^
0xaa8a6a connect_traces
/home/mjambor/gcc/trunk/src/gcc/dwarf2cfi.c:2752
0xaac866 execute_dwarf2_frame
/home/mjambor/gcc/trunk/src/gcc/dwarf2cfi.c:2975
The ICE happens with trunk and branches for gcc 5 and 4.9 but does not
with 4.8.
(Please change the component if you can think of a more suitable one.
As you can see, -g is not necessary so I suspect this is an EH bug,
rather than a debug issue. I also can't tell to what extent this is a
target bug.)
[Bug lto/69254] [6 Regression] ICE in streamer_get_builtin_tree when using -fsanitize=shift on the compile side only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69254 --- Comment #14 from Jakub Jelinek --- Created attachment 37435 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37435&action=edit gcc6-pr69254-wip.patch WIP patch. This handles the merging of the -fsanitize=/-fno-sanitize= options from the various TUs, except for the first TU (we don't call merge_and_complain for that, so right now it just passes through all the -fsanitize=/-fno-sanitize=, which is undesirable, it should do what merge_and_complain does with those options and remove the others). Perhaps merge_and_complain should be called in all cases, and for the first file be told by some bool arg it is the first one. But, before handling that, I see much bigger problem, and it is not only related to -fsanitize=, but to various other options. The thing is that the linker options are appended after the options derived from the TUs. If I say have a TU that has some OpenMP code in it and compile it with -c -flto -fopenmp, and then link with -flto or -flto -fopenmp, it works fine, but if I link with -flto -fno-openmp, I get very similar ICE to this PR. So clearly there are some options that should at least in some cases override even the linker options/
[Bug c++/69315] [6 Regression] ICE in finish_function with constexpr and templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69315 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED CC||aoliva at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #2 from Alexandre Oliva --- Looking into this...
[Bug target/69416] [6 Regression] Nonsense rtl checking failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug c/69415] -Wmisleading-indentation warns on "if (__b < __a) return __b; return __a;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69415 --- Comment #12 from Jakub Jelinek --- Ok, I stand convinced.
[Bug fortran/69423] [6 Regression] Invalid optimization with deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69423 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- As the guilty party, I had better take it! Thanks for the report Paul
