[Bug tree-optimization/70956] [6/7 Regression] ICE in build_cross_bb_scalars_def, at graphite-scop-detection.c:1725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70956 --- Comment #4 from vries at gcc dot gnu.org --- Author: vries Date: Sat May 7 07:02:36 2016 New Revision: 235995 URL: https://gcc.gnu.org/viewcvs?rev=235995&root=gcc&view=rev Log: backport "Handle NULL def in build_cross_bb_scalars_def" 2016-05-07 Tom de Vries backport: 2016-05-07 Tom de Vries PR tree-optimization/70956 * graphite-scop-detection.c (build_cross_bb_scalars_def): Handle NULL def. * gcc.dg/graphite/pr70956.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/graphite/pr70956.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/graphite-scop-detection.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/70992] New: Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70992 Bug ID: 70992 Summary: Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- 1. Deep recursion between fold_binary_loc() and fold_build2_stat_loc() causes cc1 to ICE on the following reduced testcase when compiling w/ -fwrapv: unsigned int *od; int wy = (0 % 0 + 1) * *od * 2; % x86_64-unknown-linux-gnu-gcc-7.0.0-alpha20160501 -c -fwrapv zrcoshfy.c zrcoshfy.c:2:13: warning: division by zero [-Wdiv-by-zero] int wy = (0 % 0 + 1) * *od * 2; ^ x86_64-unknown-linux-gnu-gcc-7.0.0-alpha20160501: internal compiler error: Segmentation fault (program cc1) #0 0x008a2d24 in operand_equal_p(tree_node const*, tree_node const*, unsigned int) () #1 0x008a2be0 in operand_equal_p(tree_node const*, tree_node const*, unsigned int) () #2 0x00fbb046 in generic_simplify_PLUS_EXPR(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) [clone .isra.217] () #3 0x00fdf25e in generic_simplify(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #4 0x008b44bc in fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #5 0x008c05cb in fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #6 0x005a2d82 in fold_plusminus_mult_expr(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #7 0x008b6184 in fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #8 0x008c05cb in fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #9 0x008cf9d0 in extract_muldiv(tree_node*, tree_node*, tree_code, tree_node*, bool*) () #10 0x008b9d69 in fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #11 0x008c05cb in fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #12 0x008b6184 in fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #13 0x008c05cb in fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #14 0x008cf9d0 in extract_muldiv(tree_node*, tree_node*, tree_code, tree_node*, bool*) () #15 0x008d022e in extract_muldiv(tree_node*, tree_node*, tree_code, tree_node*, bool*) () #16 0x008b9d69 in fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #17 0x008c05cb in fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () <…> #190618 0x008b6f03 in fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #190619 0x008c05cb in fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #190620 0x008d01e1 in extract_muldiv(tree_node*, tree_node*, tree_code, tree_node*, bool*) () #190621 0x008b9d69 in fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #190622 0x008c05cb in fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #190623 0x008c0fa0 in fold_build2_initializer_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) () #190624 0x006ad649 in c_fully_fold_internal(tree_node*, bool, bool*, bool*, bool) () #190625 0x006b0a2c in c_fully_fold(tree_node*, bool, bool*) () #190626 0x0065a1ac in digest_init(unsigned int, tree_node*, tree_node*, tree_node*, bool, bool, int) () #190627 0x0065c8d8 in store_init_value(unsigned int, tree_node*, tree_node*, tree_node*) () #190628 0x006321e9 in finish_decl(tree_node*, unsigned int, tree_node*, tree_node*, tree_node*) () #190629 0x00696fda in c_parser_declaration_or_fndef(c_parser*, bool, bool, bool, bool, bool, tree_node**, vec, tree_node*) () #190630 0x006a3837 in c_parser_external_declaration(c_parser*) () #190631 0x006a42b3 in c_parse_file() () #190632 0x00707f73 in c_common_parse_file() () #190633 0x00b9cd1e in compile_file() () #190634 0x006173f3 in toplev::main(int, char**) () #190635 0x00619637 in main () 2. Changing "0 % 0" to "1 % 0" leads to a slightly different trace: #0 0x00e9e9f0 in wi::mul_internal(long*, long const*, unsigned int, long const*, unsigned int, unsigned int, signop, bool*, bool) () #1 0x008af916 in int_const_binop_1(tree_code, tree_node const*, tree_node const*, int) () #2 0x008c4a38 in const_binop(tree_code, tree_node*, tree_node*) () #3 0x008cfb71 in extract_muldiv(tree_node*, tr
[Bug tree-optimization/70956] [6/7 Regression] ICE in build_cross_bb_scalars_def, at graphite-scop-detection.c:1725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70956 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org --- Comment #5 from vries at gcc dot gnu.org --- Patch with test-case committed to trunk, backported to 6 branch. Marking resolved-fixed.
[Bug target/70989] [SH] Further improve utilization of zero-displacement conditional branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70989 --- Comment #1 from Oleg Endo --- Another case from bzlib.c: .L820: bt .L823 mov.l r0,@r7 .L823: tst r11,r11 bt/s.L824 <<< convert to zero-displacement cbranch mov #0,r1 <<< move common insn from successor bb to this bb mov.l r1,@r11 .L824: tst r12,r12 bt/s.L825 mov #0,r1 <<< likewise mov.l r1,@r12 .L825: result (1): .L820: bt .L823 mov.l r0,@r7 .L823: tst r11,r11 mov #0,r1 <<< now r1 can be propagated into successor blocks bt .L824 mov.l r1,@r11 .L824: mov #0,r1 tst r12,r12 bt .L825 mov.l r1,@r12 .L825: result (2): .L820: bt .L823 mov.l r0,@r7 .L823: tst r11,r11 mov #0,r1 bt .L824 mov.l r1,@r11 .L824: tst r12,r12 bt .L825 mov.l r1,@r12 .L825:
[Bug fortran/70937] [7 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937 --- Comment #14 from Dominique d'Humieres --- The patch in comment 13 fixes the regression without creating new one.
[Bug c++/70977] [6/7 Regression] Out of memory during compilation of facebook/wangle (flag c++0x works, flag c++14 fails).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70977
--- Comment #7 from Markus Trippelsdorf ---
markus@x4 tmp % cat Acceptor-c++14.ii
namespace __gnu_cxx {
namespace __ops {
struct _Iter_less_iter {
template
constexpr int operator()(_Iterator1, _Iterator2 __it2) {
return *__it2;
}
};
constexpr _Iter_less_iter __iter_less_iter() { return _Iter_less_iter(); }
}
}
namespace std {
template struct initializer_list {
typedef int *const_iterator;
int *_M_array;
unsigned long size;
constexpr const_iterator begin() { return _M_array; }
constexpr const_iterator end() { return 0; }
};
template constexpr _FIter max_element(_FIter, _FIter);
template constexpr _Tp max(initializer_list<_Tp> __l) {
max_element(__l.begin(), __l.end());
}
template
constexpr _ForwardIterator __max_element(_ForwardIterator __first,
_ForwardIterator, _Compare __comp) {
__comp(0, __first);
}
template
constexpr _ForwardIterator max_element(_ForwardIterator __first,
_ForwardIterator __last) {
__max_element(__first, __last, __gnu_cxx::__ops::__iter_less_iter());
}
template void estimateSpaceNeeded() {
const int kMaxPositiveSpace = max({0});
}
}
markus@x4 tmp % g++ -c Acceptor-c++14.ii
<>
[Bug gcov-profile/70993] New: ICE with gcov and lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70993
Bug ID: 70993
Summary: ICE with gcov and lto
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
Target Milestone: ---
with gcc version 7.0.0 20160506 (experimental) [trunk revision 235977] (GCC)
cat main.cpp
int main() { return 0;}
c++ -O2 main.cpp
perf record -e
cpu/event=0xc4,umask=0x20,name=br_inst_retired_near_taken,period=49/ -o
perf.data ./a.out
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.016 MB perf.data (1 samples) ]
create_gcov --binary=./a.out --profile=perf.data --gcov=fbdata.afdo
-gcov_version 1
c++ -O2 main.cpp -fauto-profile -flto
lto1: internal compiler error: in compute_working_sets, at gcov-io.c:1006
0x6fee03 compute_working_sets(gcov_ctr_summary const*, gcov_working_set_info*)
../../gcc-trunk/gcc/gcov-io.c:1006
0xa1a72d get_working_sets()
../../gcc-trunk/gcc/profile.c:226
0x97cd1a input_symtab()
../../gcc-trunk/gcc/lto-cgraph.c:1869
0x6634a7 read_cgraph_and_symbols
../../gcc-trunk/gcc/lto/lto.c:2856
0x6634a7 lto_main()
../../gcc-trunk/gcc/lto/lto.c:3305
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
lto-wrapper: fatal error: c++ returned 1 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug fortran/70994] New: gfortran: -fcheck=all implied do loop confusing messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70994 Bug ID: 70994 Summary: gfortran: -fcheck=all implied do loop confusing messages Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: physiker at toast2 dot net Target Milestone: --- Compiling the file f.90 with the command line option -fcheck=all active, causes the "Warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]". When the -fcheck=all option is removed, there is no warning. Executing the compiled code causes an error termination. gfortran-6: At line 8 of file f.f90 Fortran runtime error: Substring out of bounds: upper bound (32767) of 'name' exceeds string length (22) gfortran-5: At line 8 of file f.f90 Fortran runtime error: Substring out of bounds: lower bound (0) of 'name' is less than one When the variable i is initialized,e.g. i=1, there is no runtime error message. f.f90 subroutine f(name) implicit none character(len=*), intent(in) :: name character, dimension(512) :: cname integer:: i cname(1:len_trim(name)+1) = (/ ( name(i:i), i = 1,len_trim(name) ), char(0) /) end subroutine f program t implicit none character(len=22) :: name name = 'abcdefghijklmnopqr' call f(name) end program t LANG=C gfortran-fsf-6 -v -W -Wall -fcheck=all f.f90 Driving: gfortran-fsf-6 -v -W -Wall -fcheck=all f.f90 -mmacosx-version-min=10.9.4 -l gfortran -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran-fsf-6 COLLECT_LTO_WRAPPER=/sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/6.1.0/lto-wrapper Target: x86_64-apple-darwin13.4.0 Configured with: ../gcc-6.1.0/configure --prefix=/sw --prefix=/sw/lib/gcc6 --mandir=/sw/share/man --infodir=/sw/lib/gcc6/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib --program-suffix=-fsf-6 Thread model: posix gcc version 6.1.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fcheck=all' '-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2' /sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/6.1.0/f951 f.f90 -fPIC -quiet -dumpbase f.f90 -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase f -Wextra -Wall -version -fcheck=all -fintrinsic-modules-path /sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/finclude -o /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccD8RIOC.s GNU Fortran (GCC) version 6.1.0 (x86_64-apple-darwin13.4.0) compiled by GNU C version 6.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 6.1.0 (x86_64-apple-darwin13.4.0) compiled by GNU C version 6.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 f.f90:8:0: cname(1:len_trim(name)+1) = (/ ( name(i:i), i = 1,len_trim(name) ), char(0) /) Warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized] COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fcheck=all' '-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2' as -arch x86_64 -force_cpusubtype_ALL -o /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//cc66pKlk.o /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccD8RIOC.s Reading specs from /sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/../../../libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fcheck=all' '-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2' COMPILER_PATH=/sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/6.1.0/:/sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/6.1.0/:/sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/:/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/:/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/ LIBRARY_PATH=/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/:/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/../../../ COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fcheck=all' '-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2' /sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/6.1.0/collect2 -dynamic -arch x86_64 -macosx_version_min 10.9.4 -weak_reference_mismatches non-weak -o a.out -L/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0 -L/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/../../.. /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//cc66pKlk.o -lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v collect2 version 6.1.0 /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.9.4 -weak_reference_mismatches non-weak -o a.out -L/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.
[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70853 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-07 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.6 up to trunk (7.0). Before 4.6 compiling the first test in comment 0 gives the following error Error: Pointer bounds remapping at (1) is not yet implemented in gfortran
[Bug target/70995] New: [SH] rotcl usage results in bloaty code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70995
Bug ID: 70995
Summary: [SH] rotcl usage results in bloaty code
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
While the following:
unsigned int
test_14 (unsigned int a, int b, int c)
{
bool r = b == c;
return (a << 9) | r;
}
compiles to a minimal sequence (-m4 -O2):
cmp/eq r6,r5
shll8 r4
mov r4,r0
rts
rotcl r0
changing the input values a little:
unsigned int
test_15 (unsigned int a, int b, int c)
{
bool r = b != c;
return (a << 11) | r;
}
results in (-m4 -O2):
cmp/eq r6,r5
movtr1
shll8 r4
tst r1,r1
shll2 r4
mov r4,r0
rts
rotcl r0
and on SH2A (has nott insn):
shll8 r4
cmp/eq r6,r5
shll2 r4
mov r4,r0
nott
rts
rotcl r0
It seems for certain parameters it's better to not use the rotcl insn if the
nott insn is not available, as it saves one insn:
shll8 r4
cmp/eq r6,r5
shll2 r4
mov #-1,r0
negcr0,r0
rts
or r4,r0
[Bug fortran/70994] gfortran: -fcheck=all implied do loop confusing messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70994 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.5 up to trunk (7.0). Note that the code compiled with 4.4.7 and '-Wall -fbounds-check' executes without error. Work-around subroutine f(name) implicit none character(len=*), intent(in) :: name character, dimension(512) :: cname integer:: i, l l = len_trim(name) i = l cname(1:len_trim(name)+1) = (/ ( name(i:i), i = 1,len_trim(name) ), char(0) /) end subroutine f program t implicit none character(len=22) :: name name = 'abcdefghijklmnopqr' call f(name) end program t
[Bug c++/70996] New: deadlock on compilation sequence of operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70996 Bug ID: 70996 Summary: deadlock on compilation sequence of operator<< Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: magum1977 at gmail dot com Target Milestone: --- Created attachment 38434 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38434&action=edit compilation of this src is endless Code like below error() << "call() wrong id got:" << hex << (unsigned)op2() << " expect:" << (unsigned)op3() << '\n' << dec << " toSend op: " << (unsigned)op() << '\n' << " response msgid:" << (unsigned)op2() << '\n' << " response len: " << (unsigned)op3() << '\n' << " response op: " << op4() << '\n' << endl; with logger class which implement several overrided operator<< leads to infinite compilation. during infinite compilation cc1plus takes about 8% CPU. see src example in attach i compile it in c++98 mode with following options: g++ -pipe -c -msse2 -m64 -MD -Wno-trigraphs -Wno-multichar -Wformat -Wno-format-extra-args -ffunction-sections -fdata-sections -fno-omit-frame-pointer -ffast-math -ffinite-math-only -minline-all-stringops -std=c++98 -fconserve-space -Wno-invalid-offsetof -I /usr/include -g -fstack-protector -fexceptions -Wreturn-type -Werror -pthread -o message_port.o ../../prog/3rdPartyLibs/mongo-cxx-driver/mongo/util/net/message_port_test.cpp % gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 6.1.1 20160501 (GCC)
[Bug c++/70996] deadlock on compilation sequence of operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70996 --- Comment #1 from Alexander --- Created attachment 38435 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38435&action=edit actually only this src leads inifinite compilation. src before finished with error after 5 minutes actually only this src leads inifinite compilation. src before finished with error after 5 minutes error (which occured after 5 mins): g++ -pipe -c -msse2 -m64 -MD -Wno-trigraphs -Wno-multichar -Wformat -Wno-format-extra-args -ffunction-sections -fdata-sections -fno-omit-frame-pointer -ffast-math -ffinite-math-only -minline-all-stringops -std=c++98 -fconserve-space -Wno-invalid-offsetof -I /usr/include -g -fstack-protector -fexceptions -Wreturn-type -Werror -pthread -o message_port.o ../../prog/3rdPartyLibs/mongo-cxx-driver/mongo/util/net/message_port_test.cpp ../../prog/3rdPartyLibs/mongo-cxx-driver/mongo/util/net/message_port_test.cpp: In instantiation of 'Nullstream& Nullstream::operator<<(T*) [with T = std::ios_base&(std::ios_base&)]': ../../prog/3rdPartyLibs/mongo-cxx-driver/mongo/util/net/message_port_test.cpp:46:50: required from here ../../prog/3rdPartyLibs/mongo-cxx-driver/mongo/util/net/message_port_test.cpp:23:32: error: invalid static_cast from type 'std::ios_base& (*)(std::ios_base&)' to type 'void*' return operator<<( static_cast( t ) );
[Bug c++/70996] deadlock on compilation sequence of operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70996 --- Comment #2 from Alexander --- std-98 is not affect to result
[Bug bootstrap/70997] New: [7 Regression] bootstrap broken on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70997 Bug ID: 70997 Summary: [7 Regression] bootstrap broken on s390x-linux-gnu Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with 20160506 on s390x-linux-gnu /<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/ -B/usr/lib/gcc-snapshot/s390x-linux-gnu/bin/ -nostdinc++ -B/<>/build/prev-s390x-linux-gnu/libstdc++-v3/src/.libs -B/<>/build/prev-s390x-linux-gnu/libstdc++-v3/libsupc++/.libs -I/<>/build/prev-s390x-linux-gnu/libstdc++-v3/include/s390x-linux-gnu -I/<>/build/prev-s390x-linux-gnu/libstdc++-v3/include -I/<>/src/libstdc++-v3/libsupc++ -L/<>/build/prev-s390x-linux-gnu/libstdc++-v3/src/.libs -L/<>/build/prev-s390x-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber -I../../src/gcc/../libbacktrace -o cfganal.o -MT cfganal.o -MMD -MP -MF ./.deps/cfganal.TPo ../../src/gcc/cfganal.c ../../src/gcc/cfganal.c: In function 'edge_def* find_edge(basic_block, basic_block)': ../../src/gcc/cfganal.c:500:1: internal compiler error: in redirect_jump, at jump.c:1560 } ^ 0x80cfcefd redirect_jump(rtx_jump_insn*, rtx_def*, int) ../../src/gcc/jump.c:1560 0x81877341 try_optimize_cfg ../../src/gcc/cfgcleanup.c:2899 0x81877df1 cleanup_cfg(int) ../../src/gcc/cfgcleanup.c:3150 0x818781bd execute ../../src/gcc/cfgcleanup.c:3279 Please submit a full bug report, with preprocessed source if appropriate. configured with // Target: s390x-linux-gnu // Configured with: ../src/configure -v --with-pkgversion='Ubuntu 20160506-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libsanitizer --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-7-snap-s390x/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-7-snap-s390x --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-7-snap-s390x --with-arch-directory=s390x --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch=zEC12 --with-long-double-128 --enable-multilib --enable-checking=yes --build=s390x-linux-gnu --host=s390x-linux-gnu --target=s390x-linux-gnu full build log https://launchpadlibrarian.net/258248825/buildlog_ubuntu-yakkety-s390x.gcc-snapshot_20160506-1ubuntu1_BUILDING.txt.gz
[Bug c++/70996] regression - infinite compilation of sequence overrided operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70996 Alexander changed: What|Removed |Added Summary|infinite compilation of |regression - infinite |sequence overrided |compilation of sequence |operator<< |overrided operator<< --- Comment #3 from Alexander --- gcc 5.3 have no any problems with such code
[Bug fortran/66328] Wrong initialization of derived-type DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66328 physiker at toast2 dot net changed: What|Removed |Added CC||physiker at toast2 dot net --- Comment #1 from physiker at toast2 dot net --- It seems that the bug is fixed. When the code is compiled with gfortran 6.1, the binary produces the expected output when run (see below). bash-3.2$ LANG=C gfortran-fsf-6 -v ddata.f90 Driving: gfortran-fsf-6 -v ddata.f90 -mmacosx-version-min=10.9.4 -l gfortran -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran-fsf-6 COLLECT_LTO_WRAPPER=/sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/6.1.0/lto-wrapper Target: x86_64-apple-darwin13.4.0 Configured with: ../gcc-6.1.0/configure --prefix=/sw --prefix=/sw/lib/gcc6 --mandir=/sw/share/man --infodir=/sw/lib/gcc6/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib --program-suffix=-fsf-6 Thread model: posix gcc version 6.1.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2' /sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/6.1.0/f951 ddata.f90 -fPIC -quiet -dumpbase ddata.f90 -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase ddata -version -fintrinsic-modules-path /sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/finclude -o /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccxnGIeX.s GNU Fortran (GCC) version 6.1.0 (x86_64-apple-darwin13.4.0) compiled by GNU C version 6.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 6.1.0 (x86_64-apple-darwin13.4.0) compiled by GNU C version 6.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2' as -arch x86_64 -force_cpusubtype_ALL -o /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccpWyVcF.o /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccxnGIeX.s Reading specs from /sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/../../../libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2' COMPILER_PATH=/sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/6.1.0/:/sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/6.1.0/:/sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/:/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/:/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/ LIBRARY_PATH=/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/:/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/../../../ COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2' /sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin13.4.0/6.1.0/collect2 -dynamic -arch x86_64 -macosx_version_min 10.9.4 -weak_reference_mismatches non-weak -o a.out -L/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0 -L/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/../../.. /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccpWyVcF.o -lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v collect2 version 6.1.0 /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.9.4 -weak_reference_mismatches non-weak -o a.out -L/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0 -L/sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0/../../.. /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccpWyVcF.o -lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v @(#)PROGRAM:ld PROJECT:ld64-241.9 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7m armv7em Library search paths: /sw/lib/gcc6/lib/gcc/x86_64-apple-darwin13.4.0/6.1.0 /sw/lib/gcc6/lib /usr/lib /usr/local/lib Framework search paths: /Library/Frameworks/ /System/Library/Frameworks/ /usr/bin/nm -n /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccpWyVcF.o bash-3.2$ ./a.out 1. 1. 1. 1. bash-3.2$
[Bug rtl-optimization/70998] New: [7 Regression]: ICE in pre_and_rev_post_order_compute, at cfganal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70998 Bug ID: 70998 Summary: [7 Regression]: ICE in pre_and_rev_post_order_compute, at cfganal.c Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- Recent commit caused following regression in the testsuite for x86_64-linux-gnu target: FAIL: g++.dg/pr62079.C (internal compiler error) FAIL: g++.dg/pr62079.C (test for excess errors) cc1plus -quiet -std=c++11 -O2 -fnon-call-exceptions pr62079.C pr62079.C: In function ‘int main()’: pr62079.C:78:1: internal compiler error: in pre_and_rev_post_order_compute, at cfganal.c:1056 } ^ 0x936c5d pre_and_rev_post_order_compute(int*, int*, bool) /home/uros/gcc-svn/trunk/gcc/cfganal.c:1055 0x901f8f init_alias_analysis() /home/uros/gcc-svn/trunk/gcc/alias.c:3252 0x13d0d5e sched_init() /home/uros/gcc-svn/trunk/gcc/haifa-sched.c:7369 0x13d23cd haifa_sched_init() /home/uros/gcc-svn/trunk/gcc/haifa-sched.c:7406 0xcf8d79 schedule_insns() /home/uros/gcc-svn/trunk/gcc/sched-rgn.c:3504 0xcf959d schedule_insns() /home/uros/gcc-svn/trunk/gcc/sched-rgn.c:3498 0xcf959d rest_of_handle_sched2 /home/uros/gcc-svn/trunk/gcc/sched-rgn.c:3737 0xcf959d execute /home/uros/gcc-svn/trunk/gcc/sched-rgn.c:3873 Please submit a full bug report, ... (gdb) bt #0 internal_error (gmsgid=gmsgid@entry=0x1beef58 "in %s, at %s:%d") at /home/uros/gcc-svn/trunk/gcc/diagnostic.c:1251 #1 0x0149f494 in fancy_abort (file=file@entry=0x1602c78 "/home/uros/gcc-svn/trunk/gcc/cfganal.c", line=line@entry=1056, function=function@entry=0x1602df0 "pre_and_rev_post_order_compute") at /home/uros/gcc-svn/trunk/gcc/diagnostic.c:1327 #2 0x00936c5e in pre_and_rev_post_order_compute (pre_order=pre_order@entry=0x0, rev_post_order=rev_post_order@entry=0x21ed630, include_entry_exit=include_entry_exit@entry=false) at /home/uros/gcc-svn/trunk/gcc/cfganal.c:1055 #3 0x00901f90 in init_alias_analysis () at /home/uros/gcc-svn/trunk/gcc/alias.c:3252 #4 0x013d0d5f in sched_init () at /home/uros/gcc-svn/trunk/gcc/haifa-sched.c:7369 #5 0x013d23ce in haifa_sched_init () at /home/uros/gcc-svn/trunk/gcc/haifa-sched.c:7406 #6 0x00cf8d7a in schedule_insns () at /home/uros/gcc-svn/trunk/gcc/sched-rgn.c:3504 #7 0x00cf959e in schedule_insns () at /home/uros/gcc-svn/trunk/gcc/sched-rgn.c:3498 #8 rest_of_handle_sched2 () at /home/uros/gcc-svn/trunk/gcc/sched-rgn.c:3737 #9 (anonymous namespace)::pass_sched2::execute (this=) at /home/uros/gcc-svn/trunk/gcc/sched-rgn.c:3873 #10 0x00c85a04 in execute_one_pass (pass=pass@entry=0x21bb200) at /home/uros/gcc-svn/trunk/gcc/passes.c:2344 #11 0x00c85fd8 in execute_pass_list_1 (pass=0x21bb200) at /home/uros/gcc-svn/trunk/gcc/passes.c:2428 #12 0x00c85fea in execute_pass_list_1 (pass=0x21ba9c0) at /home/uros/gcc-svn/trunk/gcc/passes.c:2429 #13 0x00c85fea in execute_pass_list_1 (pass=0x21b98e0) at /home/uros/gcc-svn/trunk/gcc/passes.c:2429 #14 0x00c86035 in execute_pass_list (fn=, pass=) at /home/uros/gcc-svn/trunk/gcc/passes.c:2439 #15 0x0097c9c4 in cgraph_node::expand (this=this@entry=0x7fffeffb7730) at /home/uros/gcc-svn/trunk/gcc/cgraphunit.c:1982 #16 0x0097e268 in expand_all_functions () at /home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2118 #17 symbol_table::compile (this=this@entry=0x7fffefe0c0a8) at /home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2474 #18 0x00980623 in symbol_table::compile (this=0x7fffefe0c0a8) at /home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2538 #19 symbol_table::finalize_compilation_unit (this=0x7fffefe0c0a8) at /home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2564 #20 0x00d4c458 in compile_file () at /home/uros/gcc-svn/trunk/gcc/toplev.c:488 #21 0x0062d9a4 in do_compile () at /home/uros/gcc-svn/trunk/gcc/toplev.c:1987 #22 toplev::main (this=this@entry=0x7fffdb90, argc=, argc@entry=6, argv=, argv@entry=0x7fffdc98) at /home/uros/gcc-svn/trunk/gcc/toplev.c:2095 #23 0x0062fb87 in main (argc=6, argv=0x7fffdc98) at /home/uros/gcc-svn/trunk/gcc/main.c:39 (gdb) f 2 #2 0x00936c5e in pre_and_rev_post_order_compute (pre_order=pre_order@entry=0x0, rev_post_order=rev_post_order@entry=0x21ed630, include_entry_exit=include_entry_exit@entry=false) at /home/uros/gcc-svn/trunk/gcc/cfganal.c:1055 1055gcc_assert (pre_order_num (gdb) list 1050/* The number of nodes visited should be the number of blocks. */ 1051gcc_assert (pre_order_num == n_basic_blocks_for_fn (cfun)); 1052 else 1053/* The number of nodes visited should be the number of blocks minus 1054 the entry and exit blocks whic
[Bug rtl-optimization/70998] [7 Regression]: ICE in pre_and_rev_post_order_compute, at cfganal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70998 Uroš Bizjak changed: What|Removed |Added Keywords||alias Target||x86_64-linux-gnu Target Milestone|--- |7.0
[Bug target/70999] New: String incorrectly placed in flash instead of RAM when building with -ffunction-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70999
Bug ID: 70999
Summary: String incorrectly placed in flash instead of RAM when
building with -ffunction-sections
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gigo121 at gmail dot com
Target Milestone: ---
Created attachment 38436
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38436&action=edit
Test source code
When building with AVR-GCC 6.1.0, -ffunction-sections and any optimization
level other than -O0 then strings that are passed as a parameter to a function
like puts("whatever") will be stored in flash instead of RAM.
However, this will correctly store myString in RAM with -ffunction-sections:
static const char myString[] = "whatever";
puts(myString);
avr-gcc -mmcu=atmega328 -Wall -Wextra -O1 -ffunction-sections main.c
[Bug rtl-optimization/70998] [7 Regression]: ICE in pre_and_rev_post_order_compute, at cfganal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70998 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-07 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It was triggered by r235906.
[Bug rtl-optimization/70998] [7 Regression]: ICE in pre_and_rev_post_order_compute, at cfganal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70998 --- Comment #2 from Uroš Bizjak --- sse2_cvtsd2ss pattern is wrong. This pattern is written as: (define_insn "sse2_cvtsd2ss" [(set (match_operand:V4SF 0 "register_operand" "=x,x,v") (vec_merge:V4SF (vec_duplicate:V4SF (float_truncate:V2SF (match_operand:V2DF 2 "nonimmediate_operand" "x,m,"))) (match_operand:V4SF 1 "register_operand" "0,0,v") (const_int 1)))] This implies V2DF load from memory, which is not the case. The pattern should be similar to e.g. cvtsi2ss pattern: (define_insn "sse_cvtsi2ss" [(set (match_operand:V4SF 0 "register_operand" "=x,x,v") (vec_merge:V4SF (vec_duplicate:V4SF (float:SF (match_operand:SI 2 "" "r,m,"))) (match_operand:V4SF 1 "register_operand" "0,0,v") (const_int 1)))] This is correct scalar memory load.
[Bug target/70998] [7 Regression]: ICE in pre_and_rev_post_order_compute, at cfganal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70998 Uroš Bizjak changed: What|Removed |Added Component|rtl-optimization|target --- Comment #3 from Uroš Bizjak --- Target issue. BTW: several SSE scalar conversion patterns are wrong.
[Bug fortran/66328] Wrong initialization of derived-type DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66328 Dominique d'Humieres changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from Dominique d'Humieres --- This PR has been "fixed" between revisions r230421 (2015-11-16, wrong-code) and r230500+patch for pr59910 (2015-11-17), likely by r230580 (pr59910). Steve, could you please check that this is right?
[Bug target/71000] New: Wrong defines for ATMEGA328p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71000 Bug ID: 71000 Summary: Wrong defines for ATMEGA328p Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: soltan.gris at gmx dot net Target Milestone: --- Target: AVR In the iom328p.h are the defines for the Portpins PORTyx while in the other .h files is it Pyx. Where y is the Port and x the pin number. iom328p.h : #define PORTB _SFR_IO8(0x05) #define PORTB0 0 #define PORTB1 1 #define PORTB2 2 #define PORTB3 3 #define PORTB4 4 #define PORTB5 5 #define PORTB6 6 #define PORTB7 7 iotn2313.h /* Data Register, Port B PORTB[7:0] */ #define PORTB _SFR_IO8(0x18) #define PB7 7 #define PB6 6 #define PB5 5 #define PB4 4 #define PB3 3 #define PB2 2 #define PB1 1 #define PB0 0 iomxx4.h #define PORTB _SFR_IO8(0x05) #define PB7 7 #define PB6 6 #define PB5 5 #define PB4 4 #define PB3 3 #define PB2 2 #define PB1 1 #define PB0 0 Kind regards
[Bug tree-optimization/70985] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70985 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-07 CC||jakub at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ICE on valid code at -O3 on |[7 Regression] ICE on valid |x86_64-linux-gnu: |code at -O3 on |verify_gimple failed|x86_64-linux-gnu: ||verify_gimple failed Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r235871.
[Bug tree-optimization/70985] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70985 --- Comment #2 from Jakub Jelinek --- BIT_FIELD_REF allows non-is_gimple_val first operand, but when it is transformed into a cast, obviously it needs to be forced into gimple val first.
[Bug c++/70991] Uninitialized class allowed if it came from self-assignment, or a member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70991 --- Comment #2 from bennet brauer --- By the way, this bug mentions classes specifically, because the same idea but with a simple "int" assignment generates a warning: error: ‘foo’ is used uninitialized in this function [-Werror=uninitialized] int foo = foo; // Unintialized direct assignment. ^
[Bug other/71001] New: cross build native: fixincludes searches host path on build system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71001 Bug ID: 71001 Summary: cross build native: fixincludes searches host path on build system Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: daniel.c.klauer at web dot de Target Milestone: --- Created attachment 38437 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38437&action=edit example to reproduce the problem Hello, I have encountered an issue when cross-compiling a native gcc for i686-w64-mingw32 on a GNU/Linux system. The build tries to access a host path on the build system, which makes no sense when cross-compiling. In this case it is "/mingw/include", which is supposed to exist on i686-w64-mingw32 but of course not on the GNU/Linux that's used as build system, thus the build fails (perhaps luckily even -- if it was a more common path like /usr/include, I imagine the problem would go unnoticed). $ uname -m -o x86_64 GNU/Linux $ ../gcc-6.1.0/configure \ --build=x86_64-pc-linux-gnu \ --host=i686-w64-mingw32 \ --target=i686-w64-mingw32 \ --prefix=/usr \ --enable-languages=c \ --with-gmp="$sysroot"/usr \ --with-mpfr="$sysroot"/usr \ --with-mpc="$sysroot"/usr ... $ make ... The directory that should contain system headers does not exist: /mingw/include Makefile:2907: recipe for target 'stmp-fixinc' failed ... It appears that using --with-sysroot to specify a i686-w64-mingw32 sysroot fixes it, but it also encodes the sysroot path into the newly built compiler for use at runtime, which I don't want since it is a build-system-specific path. And this isn't building a cross-compiler anyways (which is where --with-sysroot makes sense). So I looked at --with-build-sysroot instead. If I understood correctly, --with-build-sysroot is meant for specifying the target sysroot for use during the gcc build process only, and not later at runtime. But the fixincludes step does not respect --with-build-sysroot. Maybe fixincludes should use --with-build-sysroot if that's set, and be disabled otherwise (when cross-compiling and no sysroot is given). I found an old posting about this issue here, though it wasn't answered: https://gcc.gnu.org/ml/gcc-help/2006-04/msg00191.html
[Bug middle-end/71002] New: [6 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
Bug ID: 71002
Summary: [6 Regression] -fstrict-aliasing breaks Boost's short
string optimization implementation
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
Created attachment 38438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38438&action=edit
Reduced test case
(This is the miscompilation I reported seeing in PR70054. I have a reduced
test case for it now.)
Since GCC 6, the following simple use of boost::container::string is broken:
$ cat foo.cpp
#include
#include
#include
using boost::container::string;
struct foo
{
__attribute__((noinline))
foo(string str)
: m_str{std::move(str)},
m_len{m_str.length()}
{ }
string m_str;
std::size_t m_len;
};
int main() {
foo f{"the quick brown fox jumps over the lazy dog"};
if (f.m_len == 0) {
std::abort();
}
return 0;
}
$ g++ -O2 -Wall foo.cpp -o foo && ./foo
[1]12277 abort (core dumped) ./foo
It works with -fno-strict-aliasing. I reduced the problem to the attached
standalone test case. Boost's code doesn't seem to be 100% compliant, but the
worst thing it does is access a non-active union member (the is_short
bitfield). As far as I know, GCC permits that as an extension.
[Bug c++/33041] g++ incorrectly resolves an identically named templated struct in a super class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33041
Martin Sebor changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-05-07
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||4.5.3, 4.8.3, 4.9.3, 5.3.0,
||6.1.0
--- Comment #5 from Martin Sebor ---
Confirming for the compilation error mentioned in comment #4. The latest trunk
(7.0) fails to compile the test case with the errors below. (Both Clang and
the EDG front end accept the code.)
$ cat x.cpp && gcc -Wall -Wextra -Wpedantic x.cpp
struct bar {
typedef bar type;
template
struct foo { static const int value = 2; };
};
template
struct foo: bar { static const int value = 1; };
int main() {
// foo is the foo struct at namespace level, foo
// should be the foo struct within bar, but it is not in g++
__builtin_printf ("%i\n", foo::foo::value);
// foo is again the foo struct at namespace level,
// ::type explicitly takes its superclass so foo is
// the foo struct within bar.
__builtin_printf ("%i\n", foo::type::foo::value);
}
x.cpp: In function ‘int main()’:
x.cpp:14:43: error: expected primary-expression before ‘double’
__builtin_printf ("%i\n", foo::foo::value);
^~
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #20 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat May 7 23:16:23 2016 New Revision: 235999 URL: https://gcc.gnu.org/viewcvs?rev=235999&root=gcc&view=rev Log: 2016-05-07 Fritz Reese PR fortran/56226 * module.c (dt_upper_string): Rename to gfc_dt_upper_string (dt_lower_string): Likewise. * gfortran.h: Make new gfc_dt_upper/lower_string global. * class.c: Use gfc_dt_upper_string. * decl.c: Likewise. * symbol.c: Likewise. * resolve.c (resolve_component): New function. (resolve_fl_derived0): Move component loop code to resolve_component. * parse.c (check_component): New function. (parse_derived): Move loop code to check_component. * lang.opt, invoke.texi, options.c : New option -fdec-structure. * libgfortran.h (bt): New basic type BT_UNION. * gfortran.h (gfc_option): New option -fdec-structure. (gfc_get_union_type, gfc_compare_union_types): New prototypes. (gfc_bt_struct, gfc_fl_struct, case_bt_struct, case_fl_struct): New macros. (gfc_find_component): Change prototype. * match.h (gfc_match_member_sep, gfc_match_map, gfc_match_union, gfc_match_structure_decl): New prototypes. * parse.h (gfc_comp_struct): New macro. * symbol.c (gfc_find_component): Search for components in nested unions * class.c (insert_component_ref, gfc_add_component_ref, add_proc_comp, copy_vtab_proc_comps): Update calls to gfc_find_component. * primary.c (gfc_convert_to_structure_constructor): Likewise. * symbol.c (gfc_add_component): Likewise. * resolve.c (resolve_typebound_function, resolve_typebound_subroutine, resolve_typebound_procedure, resolve_component, resolve_fl_derived): Likewise. * expr.c (get_union_init, component_init): New functions. * decl.c (match_clist_expr, match_record_decl, get_struct_decl, gfc_match_map, gfc_match_union, gfc_match_structure_decl): Likewise. * interface.c (compare_components, gfc_compare_union_types): Likewise. * match.c (gfc_match_member_sep): Likewise. * parse.c (check_component, parse_union, parse_struct_map): Likewise. * resolve.c (resolve_fl_struct): Likewise. * symbol.c (find_union_component): Likewise. * trans-types.c (gfc_get_union_type): Likewise. * parse.c (parse_derived): Use new functions. * interface.c (gfc_compare_derived_types, gfc_compare_types): Likewise. * expr.c (gfc_default_initializer): Likewise. * gfortran.texi: Support for DEC structures, unions, and maps. * gfortran.h (gfc_statement, sym_flavor): Likewise. * check.c (gfc_check_kill_sub): Likewise. * expr.c (gfc_copy_expr, simplify_const_ref, gfc_has_default_initializer): Likewise. * decl.c (build_sym, match_data_constant, add_init_expr_to_sym, match_pointer_init, build_struct, variable_decl, gfc_match_decl_type_spec, gfc_mach_data-decl, gfc_match_entry, gfc_match_end, gfc_match_derived_decl): Likewise. * interface.c (check_interface0, check_interface1, gfc_search_interface): Likewise. * misc.c (gfc_basic_typename, gfc_typename): Likewise. * module.c (add_true_name, build_tnt, bt_types, mio_typespec, fix_mio_expr, load_needed, mio_symbol, read_module, write_symbol, gfc_get_module_backend_decl): Likewise. * parse.h (gfc_compile_state): Likewise. * parse.c (decode_specification_statement, decode_statement, gfc_ascii_statement, verify_st_order, parse_spec): Likewise. * primary.c (gfc_match_varspec, gfc_match_structure_constructor, gfc_match_rvalue, match_variable): Likewise. * resolve.c (find_arglists, resolve_structure_cons, is_illegal_recursion, resolve_generic_f, get_declared_from_expr, resolve_typebound_subroutine, resolve_allocate_expr, nonscalar_typebound_assign, generate_component_assignments, resolve_fl_variable_derived, check_defined_assignments, resolve_component, resolve_symbol, resolve_equivalence_derived): Likewise. * symbol.c (flavors, check_conflict, gfc_add_flavor, gfc_use_derived, gfc_restore_last_undo_checkpoint, gfc_type_compatible, gfc_find_dt_in_generic): Likewise. * trans-decl.c (gfc_get_module_backend_decl, create_function_arglist, gfc_create_module_variable, check_constant_initializer): Likewise. * trans-expr.c (gfc_conv_component_ref, gfc_conv_initializer, gfc_trans_alloc_subarray_assign, gfc_trans_subcomponent_assign, gfc_conv_structure, gfc_trans_scalar_assign, copyable_array_p): Likewise. * trans-io.c (transfer_namelist_element, transfer_expr, gfc_trans_transfer): Likewise. * trans-stmt.c (gfc_tran
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #21 from kargl at gcc dot gnu.org --- Created attachment 38439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38439&action=edit fortran/ChangeLog diff
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #22 from kargl at gcc dot gnu.org --- Created attachment 38440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38440&action=edit gcc/testsuite/ChangeLog diff
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #23 from kargl at gcc dot gnu.org --- Created attachment 38441 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38441&action=edit diff for revision 235999
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #24 from kargl at gcc dot gnu.org --- I have attached the diffs for fortran/ChangeLog, testsuite/ChangeLog, and code changes for revision 235999. This is now in trunk. I'll commit to the 6-branch next weekend. Please keep an eye open for bug reports.
[Bug c++/58601] [meta-bug] alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58601 Bug 58601 depends on bug 34747, which changed state. Bug 34747 Summary: __attribute__((aligned(x)))+__alignof != correct behaviour https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34747 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/10179] alignment attributes are not inherited correctly with empty classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10179 Martin Sebor changed: What|Removed |Added CC||andry at inbox dot ru --- Comment #7 from Martin Sebor --- *** Bug 34747 has been marked as a duplicate of this bug. ***
[Bug c++/34747] __attribute__((aligned(x)))+__alignof != correct behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34747 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Blocks||58601 Resolution|--- |DUPLICATE --- Comment #5 from Martin Sebor --- When compiled with the current trunk (7.0), the test produces the output below (same as in comment #4). After reviewing the tests I believe all the failures are false positives. The failing tests assume that a #pragma pack directive doesn't affect the alignment of struct members. However, according to GCC documentation for attribute packed: "Specifying this attribute [packed] for struct and union types is equivalent to specifying the packed attribute on each of the structure or union members." And specifying the attribute on a member reduces its alignment to the one specified. So test5, for instance, expects the alignment of a struct defined just following #pragma pack not to be affected by the #pragma. Similarly for all the other failing tests. Since the valid tests pass (fixed by PR 10179) I'll go ahead and close this report as a duplicate of that bug. (Based on the summary of this I'm assuming the expectation is that #pragma pack have the same effect as attribute packed and not something else.) FAILED: test5 FAILED: test7 FAILED: test20 FAILED: test21 FAILED: test25 FAILED: test26 FAILED: test37 FAILED: test46 FAILED: test47 FAILED: test48 10 tests failed! *** This bug has been marked as a duplicate of bug 10179 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58601 [Bug 58601] [meta-bug] alignas
[Bug c++/71003] New: __extension__ silences pedwarn for "\e" in C but not in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71003 Bug ID: 71003 Summary: __extension__ silences pedwarn for "\e" in C but not in C++ Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: egall at gwmail dot gwu.edu Target Milestone: --- Host: i386-apple-darwin9.8.0 Target: i386-apple-darwin9.8.0 Build: i386-apple-darwin9.8.0 Say I have the following file: $ cat __extension__.c const char *str0 = "\e"; const char *str1 = __extension__ "\e"; When I try to compile it with gcc, everything works as expected: $ /usr/local/bin/gcc -pedantic -c __extension__.c __extension__.c:1:20: warning: non-ISO-standard escape sequence, '\e' const char *str0 = "\e"; ^~~~ i.e., it only warns on the string where I left off the __extension__. However, when I try to compile it with g++, it warns on both strings: $ /usr/local/bin/g++ -pedantic -c __extension__.c __extension__.c:1:20: warning: non-ISO-standard escape sequence, '\e' const char *str0 = "\e"; ^~~~ __extension__.c:2:34: warning: non-ISO-standard escape sequence, '\e' const char *str1 = __extension__ "\e"; ^~~~ This behavior is inconsistent. I would expect the warning for the string with __extension__ to be silenced in both cases, not just in C. g++ version info: $ /usr/local/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/local/bin/g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper Target: i386-apple-darwin9.8.0 Configured with: ../configure --disable-werror --enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C --with-system-libunwind --enable-secureplt --enable-frame-pointer --enable-version-specific-runtime-libs --enable-assert --enable-fat --enable-portable-binary --enable-browser-plugin --enable-gconf-peer --enable-libgcj-debug --enable-gc-debug --enable-interpreter --enable-aot-compile-rpm --enable-java-home --with-x --enable-collections --enable-gstreamer-peer --enable-xmlj --enable-qt-peer --enable-debug --enable-local-sockets --without-isl --enable-objc-gc --enable-maintainer-mode --enable-host-shared CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf AUTOHEADER=/usr/local/bin/autoheader AUTOM4TE=/usr/local/bin/autom4te AUTORECONF=/usr/local/bin/autoreconf AUTOSCAN=/usr/local/bin/autoscan AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames Thread model: posix gcc version 7.0.0 20160426 (experimental) (GCC)
[Bug libstdc++/71004] New: recursive_directory_iterator does not have a user-provided default ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71004
Bug ID: 71004
Summary: recursive_directory_iterator does not have a
user-provided default ctor
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric at efcs dot ca
Target Milestone: ---
Hi Jonathan,
The default ctor provided for recursive_directory_iterator won't allow it to it
to be constructed as const.
// reproducer.cpp
#include
int main() {
using namespace std::experimental::filesystem;
const recursive_directory_iterator endIt2;
}
[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71004
--- Comment #1 from Eric Fiselier ---
Additionally this seems to be affecting the value returned from
"recursion_pending()". The following code compiles and runs without asserting
on my machine.
#include
#include
using namespace std::experimental::filesystem;
int main() {
recursive_directory_iterator it;
assert(it.recursion_pending() == false);
assert(it.recursion_pending() == true);
}
[Bug libstdc++/71005] New: recursive_directory_iterator::operator++(int) incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71005
Bug ID: 71005
Summary: recursive_directory_iterator::operator++(int)
incorrectly implemented
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric at efcs dot ca
Target Milestone: ---
Hi Jonathan,
The postfix increment operator returns the incremented value of the iterator,
not the previous one.
For example:
directory_iterator it(".");
path elem = *it;
path elem2 = *it++;
assert(elem == elem2); // fires
[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-08 CC||dje at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
