[Bug other/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622
--- Comment #4 from Markus Trippelsdorf ---
Further reduced:
markus@x4 tmp % cat test.ii
namespace {
class A {
public:
virtual int *m_fn1();
int *m_fn2() { return m_fn1(); }
};
A a;
int b = *a.m_fn2();
}
markus@x4 tmp % g++ -O2 -c /var/tmp/test.ii
/var/tmp/test.ii: In member function ‘int* {anonymous}::A::m_fn2()’:
/var/tmp/test.ii:5:8: error: LHS in noreturn call
int *m_fn2() { return m_fn1(); }
^
D.2269 = __builtin_unreachable (this);
/var/tmp/test.ii:5:8: internal compiler error: verify_gimple failed
0xb74c4f verify_gimple_in_seq(gimple_statement_base*)
../../gcc/gcc/tree-cfg.c:4521
0x99ffe1 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:8599
0x9a0399 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:8684
0x82eb97 analyze_function
../../gcc/gcc/cgraphunit.c:649
0x82fe4b analyze_functions
../../gcc/gcc/cgraphunit.c:1017
0x831475 finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2271
0x62a57e cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4431
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
markus@x4 tmp % clang++ -c /var/tmp/test.ii
/var/tmp/test.ii:4:16: warning: function '::A::m_fn1' has
internal linkage but is not defined [-Wundefined-internal]
virtual int *m_fn1();
^
/var/tmp/test.ii:5:25: note: used here
int *m_fn2() { return m_fn1(); }
^
1 warning generated.
markus@x4 tmp %
[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 --- Comment #43 from Hin-Tak Leung --- (In reply to r...@cebitec.uni-bielefeld.de from comment #40) > Please try this on your system and tell us how you end up with > bootstrap-debug instead of none. Hmm, sorry, redherring. I think I found the difference - it depends on which strip I am using - the one in /usr/local/bin/ gives bootstrap-debug, while the one in /sbin/ gives none. (problem of having some GNU variety of utilities in /usr/local/bin, and whethe that's in front of $PATH).
[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959
--- Comment #42 from Hin-Tak Leung ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #40)
> if GNU cmp is installed. compare-debug doesn't take this into account,
> so if I manually run this code snippet from configure
>
> if echo "int f (void) { return 0; }" > conftest.c &&
>${CC} -c conftest.c &&
>mv conftest.o conftest.o.g0 &&
>${CC} -c -g conftest.c &&
>mv conftest.o conftest.o.g &&
>${srcdir}/contrib/compare-debug conftest.o.g0 conftest.o.g
> then
> echo bootstrap-debug
> else
> echo none
> fi
>
> with CC and srcdir set appropriately, I get none for CC=gcc-4.4 and CC=cc.
>
> Please try this on your system and tell us how you end up with
> bootstrap-debug instead of none.
I did export CC="gcc" and srcdir="/home/htl10/tmp-build/gcc-4.6.4" and cut and
paste the above code interactively into the console, and found that it was
prompting me for overwriting:
overwrite conftest.o.g0?
overwrite conftest.o.g?
(obviously that depends on configure being re-run twice, or doing it in a
directory previously had configure run once). Does configure re-run itself?
Anyway, if this is the problem, this probably explain how I managed to build
4.6.1 once. My user account doesn't have a bashrc, but the root account alias
mv to:
--
mv () {
command mv -i $@;
}
--
[Bug c/59615] "asm goto" output or at least clobbered operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615 --- Comment #5 from H. Peter Anvin --- Please don't get hung up on the specific example; I just picked one that was small and self-contained. The biggest reason we can't use gcc's native bits in the kernel are items where we have to use the kernel's "alternative" feature, where the code is dynamically patched.
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #3 from PaX Team --- small correction: tree-flow.h and tree-flow-inline.h seem to be removed however here's an additional list of headers that i needed to copy over manually to get some plugins to compile: fold-const.h gimple-ssa.h tree-ssanames.h context.h print-tree.h gimple-iterator.h varasm.h
[Bug c++/59624] New: bizarre warning about 'assigned but unused parameter' in ctor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59624
Bug ID: 59624
Summary: bizarre warning about 'assigned but unused parameter'
in ctor
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mw_triad at users dot sourceforge.net
Created attachment 31538
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31538&action=edit
SSCCE showing the bug
Consider the following code:
// foo is a class, rc is an enum class
foo::foo(rc c) : v{static_cast(c)} {}
g++ with -std=c++11 -Wall -Wextra warns:
foo.cpp:8:3: warning: parameter ‘c’ set but not used
[-Wunused-but-set-parameter]
...but there is no assignment occurring?!
I suspect under the covers this is due to C++ DR1288 (i.e. see bug #50025 of
which this is possibly either a duplicate or just goes away if that is fixed,
but will let someone else make that call), but for otherwise-warning-free code
it's quite obnoxious, as there does not appear to be anything wrong with the
code.
Goes away if ()'s are used instead of {}'s for the initialization.
(Full SSCCE is attached.)
[Bug c/59618] internal compiler error: Killed (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59618 --- Comment #7 from inmarket --- Thank-you. Insufficient RAM. A message to that effect from the compiler would be useful. Thanks for your good work and for casting your eyes on the problem. It is appreciated. -Original Message- From: manu at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Sunday, 29 December 2013 9:07 PM To: andr...@inmarket.com.au Subject: [Bug c/59618] internal compiler error: Killed (program as) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59618 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- Perhaps you ran out of memory? If not, this can be useful: http://gcc.gnu.org/bugs/minimize.html
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 PaX Team changed: What|Removed |Added CC||pageexec at gmail dot com --- Comment #2 from PaX Team --- there're some more missing headers for plugins on amd64 at least: gimplify.h tree-flow.h tree-flow-inline.h config/i386/x86-tune.def
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564
Manuel López-Ibáñez changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org
--- Comment #21 from Manuel López-Ibáñez ---
> Still, making the "error: template instantiation depth exceeds maximum" a
> fatal error seems a good idea to me.
One issue face when implementing this is that the instantiation context is
printed after the whole error is given:
if (TREE_CODE (d) == TREE_LIST)
error ("template instantiation depth exceeds maximum of %d (use "
"-ftemplate-depth= to increase the maximum) substituting %qS",
max_tinst_depth, d);
else
error ("template instantiation depth exceeds maximum of %d (use "
"-ftemplate-depth= to increase the maximum) instantiating %qD",
max_tinst_depth, d);
print_instantiation_context ();
If we convert the error to a fatal error, that information is lost. There
should be a way to tell a diagnostic function to call
print_instantiation_context (). We could override the diagnostic_finalizer like
we do for macro expansion, but it seems ugly to do this just here. I think it
would be better if there was some way to pass down flags to the finalizer to
control what to print.
Dodji, what do you think?
[Bug target/58158] [4.8/4.9 Regression] ICE with conditional moves on GPRs with a floating point conditional on mipsel with loongson2f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58158 Andrew Pinski changed: What|Removed |Added CC||biergaizi2009 at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 59620 has been marked as a duplicate of this bug. ***
[Bug c/59620] gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59620 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 58158. The problem is the MIPS back-end is not correctly handling what conditional moves that loongson has. *** This bug has been marked as a duplicate of bug 58158 ***
[Bug c/59619] gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59619 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 59620 ***
[Bug c/59620] gstaudiotestsrc.c:479:1: error: unrecognizable insn: DEFINE_SQUARE (int16, 32767.0);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59620 --- Comment #3 from Andrew Pinski --- *** Bug 59619 has been marked as a duplicate of this bug. ***
[Bug c/59618] internal compiler error: Killed (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59618 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- (In reply to Manuel López-Ibáñez from comment #5) > Perhaps you ran out of memory? Also since this is the assembler which is being killed, it is better to file a bug to binutils project with the .s file.
[Bug other/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 Markus Trippelsdorf changed: What|Removed |Added CC||hubicka at ucw dot cz, ||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf --- Started with r206042.
[Bug fortran/59612] iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612
--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> Does -fdump-fortran-optimized actually do anything?
The reason why I did not get any output from it is of course that it is only in
effect if -ffrontend-optimize is given in addition. Maybe it would be worth to
mention this in the documentation, e.g. like this:
Index: invoke.texi
===
--- invoke.texi(revision 206237)
+++ invoke.texi(working copy)
@@ -991,8 +991,9 @@
@item -fdump-fortran-optimized
@opindex @code{fdump-fortran-optimized}
-Output the parse tree after front-end optimization. Only really
-useful for debugging the GNU Fortran compiler itself.
+Output the parse tree after front-end optimization (if enabled via
+@option{-ffrontend-optimize}). Only really useful for debugging the GNU
+Fortran compiler itself.
@item -fdump-parse-tree
@opindex @code{fdump-parse-tree}
[Bug fortran/59612] iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612 --- Comment #6 from janus at gcc dot gnu.org --- The patches of comment 1 and 2 have been applied in r206237, so that the original problem is fixed by now.
[Bug c++/59621] wrong caret / lineno for wrong ctor field initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59621 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-29 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- The difficulty is that g++ parses all the initializers first and then does the conversions and by that time the individual locations are gone. At the point of the error, there is nothing that tells us the location of 'ap' or the location 'i'. Passing down those locations does not seem obvious to me due to the way the C++ parser works. If someone wishes to experiment, this is the backtrace: #0 permerror (location=526, gmsgid=0x1716960 "invalid conversion from %qT to %qT") at /home/manuel/test1/src/gcc/diagnostic.c:1024 #1 0x005db814 in convert_like_real (convs=0x2087e10, expr=, fn=, argnum=0, inner=0, issue_conversion_warnings=true, c_cast_p=false, co\ mplain=3) at /home/manuel/test1/src/gcc/cp/call.c:5910 #2 0x005e8efc in perform_implicit_conversion_flags (type=, expr=, complain=3, flags=1) at /home/manuel/test1/src/gc\ c/cp/call.c:9022 #3 0x00774e9c in convert_for_assignment (type=, rhs=, errtype=ICR_INIT, fndecl=, parmnum=0, complain=3, f\ lags=1) at /home/manuel/test1/src/gcc/cp/typeck.c:8112 #4 0x00775400 in convert_for_initialization (exp=, type=, rhs=, flags=1, errtype=ICR_\ INIT, fndecl=, parmnum=0, complain=3) at /home/manuel/test1/src/gcc/cp/typeck.c:8203 #5 0x0077329e in cp_build_modify_expr (lhs=, modifycode=INIT_EXPR, rhs=, complain=3) at /home/manuel/test1/src/gcc\ /cp/typeck.c:7480 #6 0x00789116 in perform_member_init (member=, init=) at /home/manuel/test1/src/gcc/cp/init.c:732 #7 0x0078aa18 in emit_mem_initializers (mem_inits=) at /home/manuel/test1/src/gcc/cp/init.c:1097 #8 0x007b2b40 in finish_mem_initializers (mem_inits=) at /home/manuel/test1/src/gcc/cp/semantics.c:1528 #9 0x00721e21 in cp_parser_mem_initializer_list (parser=0x77054000) at /home/manuel/test1/src/gcc/cp/parser.c:12237 #10 0x00721963 in cp_parser_ctor_initializer_opt (parser=0x77054000) at /home/manuel/test1/src/gcc/cp/parser.c:12148 #11 0x0072ca70 in cp_parser_ctor_initializer_opt_and_function_body (parser=0x77054000, in_function_try_block=false) at /home/manuel/test1/src/gcc/cp/parser.c:18561 #12 0x00734301 in cp_parser_function_definition_after_declarator (parser=0x77054000, inline_p=true) at /home/manuel/test1/src/gcc/cp/parser.c:22608 #13 0x007365f9 in cp_parser_late_parsing_for_member (parser=0x77054000, member_function=) at /home/manuel/test1/src/gcc/cp/parser.c:23280 #14 0x0072e70f in cp_parser_class_specifier_1 (parser=0x77054000) at /home/manuel/test1/src/gcc/cp/parser.c:19312 #15 0x0072e7ea in cp_parser_class_specifier (parser=0x77054000) at /home/manuel/test1/src/gcc/cp/parser.c:19336 #16 0x00724d4b in cp_parser_type_specifier (parser=0x77054000, flags=1, decl_specs=0x7fffe210, is_declaration=true, declares_class_or_enum=0x7fffe190, is_cv_qual\ ifier=0x7fffe18f) at /home/manuel/test1/src/gcc/cp/parser.c:14230 #17 0x00720ab1 in cp_parser_decl_specifier_seq (parser=0x77054000, flags=1, decl_specs=0x7fffe210, declares_class_or_enum=0x7fffe2a0) at /home/manuel/test1/src/g\ cc/cp/parser.c:11475 #18 0x007201d9 in cp_parser_simple_declaration (parser=0x77054000, function_definition_allowed_p=true, maybe_range_for_decl=0x0) at /home/manuel/test1/src/gcc/cp/parser.\ c:11065 #19 0x00720174 in cp_parser_block_declaration (parser=0x77054000, statement_p=false) at /home/manuel/test1/src/gcc/cp/parser.c:11014 #20 0x0071feef in cp_parser_declaration (parser=0x77054000) at /home/manuel/test1/src/gcc/cp/parser.c:10911 #21 0x0071fa69 in cp_parser_declaration_seq_opt (parser=0x77054000) at /home/manuel/test1/src/gcc/cp/parser.c:10797 #22 0x00713e85 in cp_parser_translation_unit (parser=0x77054000) at /home/manuel/test1/src/gcc/cp/parser.c:4018 #23 0x007484d4 in c_parse_file () at /home/manuel/test1/src/gcc/cp/parser.c:31259 #24 0x008abfdd in c_common_parse_file () at /home/manuel/test1/src/gcc/c-family/c-opts.c:1055 #25 0x00d9abdb in compile_file () at /home/manuel/test1/src/gcc/toplev.c:547 #26 0x00d9cc7b in do_compile () at /home/manuel/test1/src/gcc/toplev.c:1893 #27 0x00d9cdea in toplev_main (argc=2, argv=0x7fffe5c8) at /home/manuel/test1/src/gcc/toplev.c:1969 #28 0x01535ebc in main (argc=2, argv=0x7fffe5c8) at /home/manuel/test1/src/gcc/main.c:36
[Bug fortran/59612] iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612 --- Comment #5 from janus at gcc dot gnu.org --- Author: janus Date: Sun Dec 29 17:20:50 2013 New Revision: 206237 URL: http://gcc.gnu.org/viewcvs?rev=206237&root=gcc&view=rev Log: 2013-12-29 Janus Weil PR fortran/59612 * dump-parse-tree.c (show_typespec): Check for charlen. * invoke.texi: Fix documentation of -fdump-fortran-optimized and -fdump-parse-tree. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/invoke.texi
[Bug other/59622] [4.9 Regression] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-29 Target Milestone|--- |4.9.0 Summary|trunk gcc-4.9.0:internal|[4.9 Regression] internal |compiler error: |compiler error: |verify_gimple failed|verify_gimple failed Ever confirmed|0 |1 --- Comment #2 from Marc Glisse --- Seems related to OBJ_TYPE_REF. -O2 is sufficient.
[Bug other/59622] trunk gcc-4.9.0:internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622 --- Comment #1 from David Kredba --- Created attachment 31536 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31536&action=edit More c-reduced (--slow)
[Bug c++/59623] New: Segmentation fault, cc1plus, relative path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59623 Bug ID: 59623 Summary: Segmentation fault, cc1plus, relative path Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: millibit at gmail dot com Created attachment 31537 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31537&action=edit Source code and post-processed file. Compiling C++ source fails when code in located in parent directory. Command line: $ g++ -O0 -g3 -Wall -Wextra -c -fmessage-length=0 -save-temps -o BinaryFile.o "../BinaryFile.cpp" g++: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. Changing directory and compiling: $ cd .. $ g++ -O0 -g3 -Wall -Wextra -c -save-temps -o BinaryFile.o "BinaryFile.cpp" ... compiles without warnings, etc. Exact same code worked with previous versions of gcc. OS/system is Windows 7, 64-bit, cygwin-64bit. Windows is fully updated. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-cygwin/4.8.2/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-1/src/gcc-4.8.2/configure --srcdir=/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-1/src/gcc-4.8.2 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/gcc -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib Thread model: posix gcc version 4.8.2 (GCC)
[Bug other/59622] New: trung gcc-4.9.0:internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622
Bug ID: 59622
Summary: trung gcc-4.9.0:internal compiler error: verify_gimple
failed
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: nheghathivhistha at gmail dot com
Created attachment 31535
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31535&action=edit
Reduced precompiled source file
Gcc 4.9.0 trunk from 2013-12-28 ICEs while compiling Gentoo LLVM-3.3-r2:
x86_64-pc-linux-gnu-g++ -m32 -fvisibility-inlines-hidden -fno-exceptions -fPIC
-O2 -ggdb -pipe -march=native -mtune=native -flto=4 -pedantic -c
./testcase.i./testcase.i: In member function ‘llvm::Value*
{anonymous}::LibCallOptimization::OptimizeCall(llvm::CallInst*,
llvm::DataLayout*, llvm::TargetLibraryInfo*, llvm::IRBuilder<>&)’:
./testcase.i:225:12: error: LHS in noreturn call
Value *OptimizeCall (CallInst * CI, DataLayout *, TargetLibraryInfo *,
^
D.2995 = __builtin_unreachable (this, D.2998, 0B, MEM[(const struct IRBuilder
&)B]);
./testcase.i:225:12: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to janus from comment #7) > I propose the following patch: ... which regtests cleanly.
[Bug rtl-optimization/52714] [4.7/4.8/4.9 regression] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714
--- Comment #11 from Andreas Schwab ---
try_combine is called with
i1 = (insn 14 13 16 2 (set (reg/v/f:SI 34 [ stack ])
(reg/f:SI 15 %sp)) pr52714.c:9 38 {*movsi_m68k2}
(nil))
i2 = (insn 16 14 17 2 (set (cc0)
(compare (reg/v/f:SI 34 [ stack ])
(const_int 0 [0]))) pr52714.c:10 4 {*tstsi_internal_68020_cf}
(nil))
i3 = (jump_insn 17 16 18 2 (set (pc)
(if_then_else (eq (cc0)
(const_int 0 [0]))
(label_ref 40)
(pc))) pr52714.c:10 390 {beq}
(int_list:REG_BR_PROB 1014 (nil))
-> 40)
This is then combined into
newpat = (parallel [
(set (pc)
(pc))
(set (reg/v/f:SI 34 [ stack ])
(reg/f:SI 15 %sp))
])
This isn't a recognized insn, and it needs to be split. In the 4.5
version the condition "use_crosses_set_p (SET_SRC (XVECEXP (newpat, 0,
1)), DF_INSN_LUID (i2))" (which returns 1 due to PUSH_ROUNDING) prevents
this from being done, so the whole try fails.
In the post-4.5 version the condition is used to select which of the parts to
put first. The result are the two insn
(insn 16 14 17 2 (set (pc)
(pc)) pr52714.c:10 2147483647 {NOOP_MOVE}
(nil))
(jump_insn 17 16 18 2 (set (reg/v/f:SI 34 [ stack ])
(reg/f:SI 15 %sp)) pr52714.c:10 38 {*movsi_m68k2}
(int_list:REG_BR_PROB 1014 (nil))
-> 40)
This is obviously bogus, since the latter is no longer a valid jump_insn.
[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-29 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- On x86_64-apple-darwin10, I don't get any ICE with the releases I have tested, except 4.8.2 with -w. On x86_64-apple-darwin13, I get the ICE for 4.8.2 and 4.8.3 (r206161) and all 4.9 versions I have tested with -w, but not for 4.7.4 (r206161). May be a 4.8/4.9 regression. For 4.8.3, the ICE is f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3461
[Bug fortran/47485] gfortran -M output is incorrect when -MT option is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47485 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-29 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Still present at r206227.
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #7 from janus at gcc dot gnu.org ---
I propose the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 206231)
+++ gcc/fortran/resolve.c(working copy)
@@ -12732,7 +12732,8 @@ resolve_symbol (gfc_symbol *sym)
if (sym->attr.flavor == FL_UNKNOWN
|| (sym->attr.flavor == FL_PROCEDURE && !sym->attr.intrinsic
&& !sym->attr.generic && !sym->attr.external
- && sym->attr.if_source == IFSRC_UNKNOWN))
+ && sym->attr.if_source == IFSRC_UNKNOWN
+ && sym->ts.type == BT_UNKNOWN))
{
/* If we find that a flavorless symbol is an interface in one of the
[Bug fortran/47720] problems with makefile dependency generation using -M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47720 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-29 Ever confirmed|0 |1 --- Comment #7 from Dominique d'Humieres --- The duplicate module names are still there at r206227. Is it really a problem? Should it be documented?
[Bug preprocessor/44526] libcpp should avoid circular dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44526 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-29 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Still present at r206227.
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > The changed appeared between r185913 (2012-03-28, no error) and r186417 > (2012-04-13, error). Thanks for narrowing it down so sharply, Dominique. That was very helpful.
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) > The most suspicious commit I can see in that range is r186318, which was > Tobias' fix for PR52729. Indeed reverting this commit makes the error go away for comment 0 and 1.
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > The changed appeared between r185913 (2012-03-28, no error) and r186417 > (2012-04-13, error). The most suspicious commit I can see in that range is r186318, which was Tobias' fix for PR52729.
[Bug fortran/49111] Unnecessary warning for private interfaces having the BIND(C) attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111 Dominique d'Humieres changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-29 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #4 from Dominique d'Humieres --- Still present at r206227.
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998 --- Comment #3 from janus at gcc dot gnu.org --- According to the c.l.f. discussion, the 'iargc' reference inside the function 'iargc_8' does not refer to the generic interface, but to an external function.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #33 from Denis Kolesnik --- I found where an error in my code, corrected it and till yet it functions normally. Sorry for my misunderstanding. On alone I could not find an error in my code. I know, that you say it is not the place to report a bug, but I was sure my code is correct.
[Bug fortran/45426] Fixed-form: END may not be continued
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45426 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-29 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Still present at r206227.
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2013-12-28 00:00:00 |2013-12-29 Ever confirmed|0 |1
[Bug fortran/54221] [4.8/4.9 Regression] Explicit private access specifier signals "unexpected defined but not used [-Wunused-function]" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54221 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-29 Ever confirmed|0 |1 --- Comment #9 from Dominique d'Humieres --- > I mark this now as regression in the Fortran front-end to keep better track > of PR middle-end/54224: It seems as if part of the fix has to be done > in the Fortran front-end. > > In this PR, the issue of having a different result with PRIVATE vs. > "PRIVATE :: entry_name" is now fixed. I don't see the point to keep this PR open in addition of pr54224 (only one issue left AFAIU). Also I don't think this is any longer a regression.
[Bug fortran/58998] [4.8/4.9 Regression] Generic interface problem with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-29 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- The changed appeared between r185913 (2012-03-28, no error) and r186417 (2012-04-13, error).
[Bug fortran/53379] [4.7/4.8/4.9 Regression] No backtrace generated for array bounds violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-29 Ever confirmed|0 |1 --- Comment #13 from Dominique d'Humieres --- If it is a regression (and it is), it should be marked as NEW. Any plans about this PR?
[Bug tree-optimization/33761] tree-copyrename and tree-dominators pessimizes gzip SPEC score
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33761 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #32 from Richard Biener --- Not sure - at least the subject is highly misleading, same for the component. Looking at gzip history on our testers (AMD only, K8 and K10, only K8 going back to 4.[123]) gzip scores don't vary a lot but they have bumps up and down. Now it would be interesting to produce reportable runs for actual FSF releases as well. Let's close this bug as fixed.
[Bug c++/59621] New: wrong caret / lineno for wrong ctor field initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59621
Bug ID: 59621
Summary: wrong caret / lineno for wrong ctor field initializer
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
CC: dodji at gcc dot gnu.org
Target: x86_64-unknown-linux-gnu
class C {
public:
void *ap,*bp;
C(int i,void *p):ap(i)
,bp(p)
{}
};
g++ -c cxxctor.C -Wall -g
FAIL: gcc (GCC) 4.8.3 20131023 (prerelease)
FAIL: gcc (GCC) 4.9.0 20131119 (experimental)
FAIL: gcc-c++-4.8.2-7.fc19.x86_64
cxxctor.C: In constructor ‘C::C(int, void*)’:
cxxctor.C:5:8: error: invalid conversion from ‘int’ to ‘void*’ [-fpermissive]
,bp(p)
^
PASS: clang-3.3-3.fc19.x86_64
cxxctor.C:4:20: error: cannot initialize a member subobject of type 'void *'
with an lvalue of type 'int'
C(int i,void *p):ap(i)
^ ~
1 error generated.
The error may be really confusing for many non-trivial ctor parameters.
[Bug c/59618] internal compiler error: Killed (program as)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59618 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- Perhaps you ran out of memory? If not, this can be useful: http://gcc.gnu.org/bugs/minimize.html
[Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #19 from Markus Trippelsdorf --- This also happens a number of times when running the boost testsuite. All ICEs turned out to be PCH related. For example (checking=release compiler): ... ==17975== Invalid read of size 8 ==17975==at 0x504951: lookup_page_table_entry(void const*) [clone .lto_priv.3354] (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0xAEEE89: ggc_set_mark(void const*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x12438A1: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1246A78: gt_ggc_mx_tree_statement_list_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1244EAE: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1243A5A: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1243A5A: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1243A5A: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1244EE9: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1244F29: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1243D11: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1246353: gt_ggc_mx_lang_decl(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== Address 0x80 is not stack'd, malloc'd or (recently) free'd ==17975== In file included from ../boost/throw_exception.hpp:39:0, from ../boost/smart_ptr/shared_ptr.hpp:31, from ../boost/shared_ptr.hpp:17, from ../boost/test/tools/assertion_result.hpp:24, from ../boost/test/tools/old/impl.hpp:20, from ../boost/test/test_tools.hpp:32, from ../boost/math/tools/test.hpp:16, from ../libs/math/test/pch_light.hpp:10: ../boost/exception/exception.hpp: In member function ‘void boost::exception_detail::clone_impl::rethrow() const [with T = boost::exception_detail::error_info_injector]’: ../boost/exception/exception.hpp:473:17: internal compiler error: Segmentation fault } ^ Please submit a full bug report, with preprocessed source if appropriate
[Bug c++/58627] [4.9 Regression] crash during compilation of boost testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 Markus Trippelsdorf changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Markus Trippelsdorf --- Ah, I see PR59436 is more appropriate.
[Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436 Bug 59436 depends on bug 58627, which changed state. Bug 58627 Summary: [4.9 Regression] crash during compilation of boost testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug c++/58627] [4.9 Regression] crash during compilation of boost testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|REOPENED CC||trippels at gcc dot gnu.org Resolution|FIXED |--- --- Comment #9 from Markus Trippelsdorf --- I've re-run the boost-testsuite today and there were a number of new ICEs. All turned out to be PCH related. For example (checking=release compiler): ... ==17975== Invalid read of size 8 ==17975==at 0x504951: lookup_page_table_entry(void const*) [clone .lto_priv.3354] (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0xAEEE89: ggc_set_mark(void const*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x12438A1: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1246A78: gt_ggc_mx_tree_statement_list_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1244EAE: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1243A5A: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1243A5A: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1243A5A: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1244EE9: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1244F29: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1243D11: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975==by 0x1246353: gt_ggc_mx_lang_decl(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== Address 0x80 is not stack'd, malloc'd or (recently) free'd ==17975== In file included from ../boost/throw_exception.hpp:39:0, from ../boost/smart_ptr/shared_ptr.hpp:31, from ../boost/shared_ptr.hpp:17, from ../boost/test/tools/assertion_result.hpp:24, from ../boost/test/tools/old/impl.hpp:20, from ../boost/test/test_tools.hpp:32, from ../boost/math/tools/test.hpp:16, from ../libs/math/test/pch_light.hpp:10: ../boost/exception/exception.hpp: In member function ‘void boost::exception_detail::clone_impl::rethrow() const [with T = boost::exception_detail::error_info_injector]’: ../boost/exception/exception.hpp:473:17: internal compiler error: Segmentation fault } ^ Please submit a full bug report, with preprocessed source if appropriate
[Bug libstdc++/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436 Bug 59436 depends on bug 58627, which changed state. Bug 58627 Summary: [4.9 Regression] crash during compilation of boost testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
