[Bug tree-optimization/61906] failed to build gcc 4.9.1 on debian wheezy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61906 Dmitry Igrishin changed: What|Removed |Added CC||dmitigr at gmail dot com --- Comment #2 from Dmitry Igrishin --- Oops, it was a hardware (RAM) error. I've changed it and the problem is gone. Sorry for noise.
[Bug c/61906] New: failed to build gcc 4.9.1 on debian wheezy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61906 Bug ID: 61906 Summary: failed to build gcc 4.9.1 on debian wheezy Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dmitigr at gmail dot com the compiler: gcc (Debian 4.7.2-5) 4.7.2 the system type: Linux y470 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux the options given when GCC was configured/built: ../configure -v --enable-languages=c,c++ --prefix=/usr/local/gcc --enable-shared --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu the compiler output (error messages, warnings, etc.): In file included from ./config.h:8:0, from ../../gcc/tree-ssa-forwprop.c:20: ../../gcc/../include/ansidecl.h:150:55: internal compiler error: Segmentation fault # define ATTRIBUTE_UNUSED __attribute__ ((__unused__)) ^ ../../gcc/../include/ansidecl.h:159:32: note: in expansion of macro ‘ATTRIBUTE_UNUSED’ # define ARG_UNUSED(NAME) NAME ATTRIBUTE_UNUSED ^ ./insn-flags.h:4765:52: note: in expansion of macro ‘ARG_UNUSED’ gen_fma_fmadd_v8sf_maskz_1(rtx ARG_UNUSED (a), rtx ARG_UNUSED (b), rtx ARG_UNUSED (c), rtx ARG_UNUSED (d), rtx ARG_UNUSED (e), rtx ARG_UNUSED (f)) ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [tree-ssa-forwprop.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcc.pod make[3]: Leaving directory `/unencrypted/build/gcc-4.9.1/build/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/unencrypted/build/gcc-4.9.1/build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/unencrypted/build/gcc-4.9.1/build' make: *** [all] Error 2
[Bug c++/69218] New: File input streams states inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69218 Bug ID: 69218 Summary: File input streams states inconsistency Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dmitigr at gmail dot com Target Milestone: --- Created attachment 37296 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37296&action=edit The test case and example text file which doesn't ends with the newline character. When EOF reached while reading a text file *which doesn't ends with newline character* the stream's state becomes "not good" and "eof" but remains "not fail".
[Bug c++/69218] File input streams states inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69218 --- Comment #3 from Dmitry Igrishin --- (In reply to Jonathan Wakely from comment #2) > This is the correct behaviour required by the C++ standard, your assertion > is incorrect, that is not guaranteed to always be true. > > When reading the last word of the file (which in your test is "character") > the compiler keeps reading while there are non-whitespace characters. > Because there are no non-whitespace characters after the word "character" it > stops reading and sets eofbit, but doesn't set failbit because reading > succeeded. > > If you have a newline at the end then reading the word "character" does not > reach EOF, but on the next time round the loop it fails to read any > non-whitespace characters, so sets failbit. > > This is why you should write "while (in >> w)" instead of checking for EOF. I just didn't find this requirement in the standard. (Got lost here.) Sorry for noise.
[Bug c++/69218] File input streams states inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69218 --- Comment #4 from Dmitry Igrishin --- (In reply to Jonathan Wakely from comment #2) > This is the correct behaviour required by the C++ standard, your assertion > is incorrect, that is not guaranteed to always be true. > > When reading the last word of the file (which in your test is "character") > the compiler keeps reading while there are non-whitespace characters. > Because there are no non-whitespace characters after the word "character" it > stops reading and sets eofbit, but doesn't set failbit because reading > succeeded. > > If you have a newline at the end then reading the word "character" does not > reach EOF, but on the next time round the loop it fails to read any > non-whitespace characters, so sets failbit. > > This is why you should write "while (in >> w)" instead of checking for EOF. And thank you for explanation, Jonathan!
