[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 Dave Malcolm dmalcolm at redhat dot com changed: What|Removed |Added CC||dmalcolm at redhat dot com --- Comment #1 from Dave Malcolm dmalcolm at redhat dot com --- The crash in find_dead_or_set_registers is the one discussed in: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02619.html and I introduced it in r214693 (aka patch #225) The crash in follow_jumps is similar to it, and occurs here: new_thread = follow_jumps (JUMP_LABEL_AS_INSN (new_thread), insn, crossing); where JUMP_LABEL_AS_INSN erroneously tries to coerce JUMP_LABEL (new_thread) to be an insn, but it's a RETURN. I introduced this one in r214684 (aka patch #218) Sorry; am working on a fix.
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 --- Comment #3 from Dave Malcolm dmalcolm at redhat dot com --- Do you have preprocessed source handy for the reorg.c crash?
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 --- Comment #4 from Dave Malcolm dmalcolm at redhat dot com --- (In reply to Dave Malcolm from comment #3) Do you have preprocessed source handy for the reorg.c crash? No need; I've reproduced it locally now.
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 --- Comment #5 from Dave Malcolm dmalcolm at redhat dot com --- Created attachment 33416 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33416action=edit Candidate patch. Bootstrapped on x86_64; seems to work on stage1 cris and sparc
[Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62300 --- Comment #3 from Dave Malcolm dmalcolm at redhat dot com --- Created attachment 33414 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33414action=edit Candidate fix, only lightly tested so far
[Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62300 --- Comment #4 from Dave Malcolm dmalcolm at redhat dot com --- Sorry about this. The issue is here: 3042insn = as_a rtx_insn * ( 3043 gen_extend_insn (op0, t, promoted_nominal_mode, 3044 data-passed_mode, unsignedp)); which I mistakenly introduced in r214698. The result of the gen_extend_insn is a SET, not an insn: (set (reg/v:DI 151 [ ptrres ]) (zero_extend:DI (mem/f/c:SI (reg/f:SI 77 virtual-incoming-args) [8 ptrres+0 S4 A64]))) hence the as_a rtx_insn * fails. Am attaching a patch which appears to fix it.
[Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62300 --- Comment #6 from Dave Malcolm dmalcolm at redhat dot com --- Fix committed as r214714.
[Bug c/62203] arm-rtems ICE compiling libgcc/fixed-bit.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203 --- Comment #2 from Dave Malcolm dmalcolm at redhat dot com --- Sorry about this; I believe I introduced this in r214197, and fixed it in r214207.
[Bug c/62203] arm-rtems ICE compiling libgcc/fixed-bit.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62203 --- Comment #4 from Dave Malcolm dmalcolm at redhat dot com --- (In reply to Joel Sherrill from comment #3) Could your change have impacted multiple targets? I see ICE on i386, nios2, powerpc, and sh. Yes. Sorry again. I would be happy to learn I just started a sweep at an unfortunate point. I have updated my gcc tree and will start another one. If ok, I will then close this.
[Bug c++/61990] New: Incorrect caret location for type mismatches in function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61990
Bug ID: 61990
Summary: Incorrect caret location for type mismatches in
function calls
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at redhat dot com
Given the following test.cc:
---
class foo {};
class bar {};
extern void some_fn (foo *, foo *, bar *, foo *, foo *);
void test(foo *f)
{
some_fn (f, f, f, f, f);
}
---
GCC trunk as of 2014-05-29 r211061 reports:
/tmp/test.cc:9:25: error: cannot convert ‘foo*’ to ‘bar*’ for argument ‘3’ to
‘void some_fn(foo*, foo*, bar*, foo*, foo*)’
some_fn (f, f, f, f, f);
^
It manages to report the arg num, but the caret is in the wrong place, on the
end paren; the caret should indicate the location of the bogus arg instead:
some_fn (f, f, f, f, f);
^
(Ideally, the whole of the bogus subexpression should be underlined, though I
appreciate that's a more involved fix architecturally).
[Bug target/61287] New: error: ‘nios2_fpu_insn_enabled’ was not declared in this scope when building with ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61287 Bug ID: 61287 Summary: error: ‘nios2_fpu_insn_enabled’ was not declared in this scope when building with ada Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at redhat dot com Attempting to build using config-list.mk, with: ../../gcc/configure --target=nios2-elf --with-mpc=/opt/cfarm/mpc --enable-languages=all,ada,go leads to this error: g++ -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Iada -I../../../gcc/gcc -I../../../gcc/gcc/ada -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-o ada/trans.o -MT ada/trans.o -MMD -MP -MF ada/.deps/trans.TPo ../../../gcc/gcc/ada/gcc-interface/trans.c In file included from ./tm.h:22:0, from ../../../gcc/gcc/ada/gcc-interface/trans.c:29: ../../../gcc/gcc/ada/gcc-interface/trans.c: In function ‘tree_node* convert_with_check(Entity_Id, tree, bool, bool, bool, Node_Id)’: ./insn-flags.h:88:63: error: ‘nios2_fpu_insn_enabled’ was not declared in this scope #define HAVE_extendsfdf2 (nios2_fpu_insn_enabled (n2fpu_fextsd)) ^ ../../../gcc/gcc/ada/gcc-interface/trans.c:85:28: note: in expansion of macro ‘HAVE_extendsfdf2’ #define FP_ARITH_MAY_WIDEN HAVE_extendsfdf2 ^ ../../../gcc/gcc/ada/gcc-interface/trans.c:8677:4: note: in expansion of macro ‘FP_ARITH_MAY_WIDEN’ = FP_ARITH_MAY_WIDEN ? longest_float_type_node : gnu_in_basetype; ^ make[2]: *** [ada/trans.o] Error 1 nios2_fpu_insn_enabled is declared in nios2-protos.h, though the decl is guarded by #ifdef RTX_CODE
[Bug target/61287] error: ‘nios2_fpu_insn_enabled’ was not declared in this scope when building with ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61287 --- Comment #1 from Dave Malcolm dmalcolm at redhat dot com --- Also seen with --target=nios2-linux-gnu
[Bug c/56370] RFE: warn on 'foo = realloc(foo, …)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56370 Dave Malcolm dmalcolm at redhat dot com changed: What|Removed |Added CC||dmalcolm at redhat dot com --- Comment #2 from Dave Malcolm dmalcolm at redhat dot com 2013-02-18 17:25:22 UTC --- [FWIW cppcheck has a warning about this specific issue http://cppcheck.sourceforge.net/ ]
[Bug plugins/54959] New: current_pass == NULL during invocation of pass-gate within execute_ipa_summary_passes()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54959
Bug #: 54959
Summary: current_pass == NULL during invocation of pass-gate
within execute_ipa_summary_passes()
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dmalc...@redhat.com
In my gcc-python-plugin I allow users to create custom passes.
(FWIW see
http://gcc-python-plugin.readthedocs.org/en/latest/passes.html#creating-new-optimization-passes
for what this looks like from the user's perspective).
In particular, I've been supporting a gate() method, mirroring that of the
underlying opt_pass.
I have a single impl_gate() handler that's shared by all such user-created
passes, which I then dispatch to appropriate python code. Given that the
gate() callback takes no arguments, I've been looking up the relevant opt_pass*
by looking at the current_pass global.
This works for GIMPLE_PASS passes, but not for those of kind IPA_PASS.
Specifically, within gcc-4.7.0:gcc/passes.c:
1875void
1876execute_ipa_summary_passes (struct ipa_opt_pass_d *ipa_pass)
1877{
1878 while (ipa_pass)
1879{
1880 struct opt_pass *pass = ipa_pass-pass;
1881
1882 /* Execute all of the IPA_PASSes in the list. */
1883 if (ipa_pass-pass.type == IPA_PASS
1884 (!pass-gate || pass-gate ())
1885 ipa_pass-generate_summary)
1886{
at line 1884, pass-gate() is called, but current_pass is NULL, so I don't see
to have a way of figuring out which opt_pass* the gate() callback was called
on.
Is it possible to set current_pass in this loop before calling gate()?
Alternatively, all such callbacks could gain an argument, passing in pass
(though that would be an API change).
Hope the above makes sense
[Bug plugins/54959] current_pass == NULL during invocation of pass-gate within execute_ipa_summary_passes()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54959 --- Comment #2 from Dave Malcolm dmalcolm at redhat dot com 2012-10-17 20:00:05 UTC --- The impl_gate is implemented in C, the gate functions in Python. If I need multiple impl_gate functions, I somehow need to generate machine code at runtime that curry the relevant arguments. I guess I could use libffi to do this, perhaps, but it seems ugly and fragile.
[Bug lto/54962] New: Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54962
Bug #: 54962
Summary: Strange-looking diagnostics from
diagnostic_report_current_module() from warnings
emitted during LTO
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dmalc...@redhat.com
I'm working on a whole-program static analyzer that runs from a gcc plugin
during lto1 when invoked via
-flto -flto-partition=none
as an IPA_PASS registered before whole-program.
I'm currently emitting errors using error_at() with inform() to give extra
information on the (possibly interprocedural) execution path taken to reach the
error. This works, but leads to unusual-looking output.
For example, with:
$ gcc -flto -flto-partition=none [...various plugin args...] input-f.c
input-g.c input-h.c
my code detects a double-free involving an execution path between input-h.c and
input-g.c and calls
error_at(double-free of r)
on a location_t from input-h.c and gets this strange output on stderr:
In file included from test.h:1:0,
from /usr/include/stdlib.h:489,
from input-f.c:14,
from :3:
input-h.c:13:9: error: double-free of r
it then calls
inform(q passed to free())
on a location_t from input-g.c (to show the location of the 1st free call) and
gets this on stderr:
In file included from test.h:1:0,
from /usr/include/stdlib.h:489,
from input-f.c:14,
from :3:
input-g.c:11:7: note: q passed to free()
In both cases, the In file included from hierarchies look bogus: the files
are being directly compiled, not included.
Debugging, it comes from gcc/diagnostic.c:diagnostic_report_current_module()
where I see this code:
275 if (map diagnostic_last_module_changed (context, map))
276{
277 diagnostic_set_last_module (context, map);
278 if (! MAIN_FILE_P (map))
279{
280 map = INCLUDED_FROM (line_table, map);
281 if (context-show_column)
282pp_verbatim (context-printer,
283 In file included from %s:%d:%d,
284 LINEMAP_FILE (map),
285 LAST_SOURCE_LINE (map), LAST_SOURCE_COLUMN (map));
286 else
287pp_verbatim (context-printer,
288 In file included from %s:%d,
289 LINEMAP_FILE (map), LAST_SOURCE_LINE (map));
290 while (! MAIN_FILE_P (map))
291{
292 map = INCLUDED_FROM (line_table, map);
This code appears to assume (via MAIN_FILE_P) that there is a concept of a main
file, and that everything else is included from it. However in the context of
diagnostics emitted during LTO it's not clear that this concept makes sense (or
maybe I'm missing something? I also wonder if by attempting to issue
diagnostics from within lto1 if I'm in unexplored territory here?)
This is called by default_tree_diagnostic_starter FWIW; perhaps lto1 needs its
own implementation of this?
