https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82939
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |msebor at gcc dot gnu.org
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note the function shouldn't ever be called since the call is guarded by:
if (set->trace_includes)
trace_include (set, map);
and the linemap should have set->trace_includes set to false. So
it would be interesting to look at (in the failing case) the assembly
of line-map.o:linemap_init which does
void
linemap_init (struct line_maps *set,
source_location builtin_location)
{
*set = line_maps ();
thus default-constructs line_maps and does an aggregate assignment.
Maybe sth goes wrong here and we can work around the bug by providing
a constructor initializing all members instead of relying on value-init.
Just in case you want to investigate some more ;)
Note that on the GCC 7 branch we instead do
linemap_init (struct line_maps *set,
source_location builtin_location)
{
memset (set, 0, sizeof (struct line_maps));
Martin - you changed this to assignment from default-construction. Was there
any good reason to do so?
Quickly checking compilers with the followign testcase shows
struct line_maps {
~line_maps ();
bool trace_includes;
};
void foo (line_maps *m)
{
*m = line_maps ();
}
GCC 4.2.4:
<<cleanup_point <<< Unknown tree: expr_stmt
(void) (*NON_LVALUE_EXPR <m> = *(struct line_maps &) (struct line_maps *)
&TARGET_EXPR <D.2350, {.trace_includes=0}>) >>>
GCC 4.2.3:
;; Function line_maps::line_maps() (_ZN9line_mapsC1Ev *INTERNAL* )
;; enabled by -tree-original
{
}
;; Function void foo(line_maps*) (_Z3fooP9line_maps)
;; enabled by -tree-original
<<cleanup_point <<< Unknown tree: expr_stmt
(void) (*NON_LVALUE_EXPR <m> = *(struct line_maps &) (struct line_maps *)
&TARGET_EXPR <D.2368, <<< Unknown tree: aggr_init_expr
__comp_ctor
0B
D.2368 >>>
>) >>>
>>;
so GCC 4.2.3 doesn't properly value-initialize for this expression (but 4.2.4
does). GCC 4.3.0 looks fine as well, so does 4.1.2 and 4.1.0 but not
4.2.{0,1,2} either.
Not sure what to suggest here but _not_ use unfixed 4.2.{0,1,2,3} as
host-compiler...
I suppose Apple isn't going to fix their GCC 4.2.x based compiler (IIRC
that's even gone for newer OS-X / XCode).
Eric - can you check Apple G++ on the above small testcase?
