* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
@ 2013-02-07 10:52 ` rguenth at gcc dot gnu.org
2013-02-07 13:54 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-07 10:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |lto
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2013-02-07
CC| |rguenth at gcc dot gnu.org,
| |tromey at redhat dot com
Ever Confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-07 10:52:15 UTC ---
Hmm, I'm not sure how the include stack works. I suppose the reason may be
that we use
if (file_change)
{
if (prev_file)
linemap_add (line_table, LC_LEAVE, false, NULL, 0);
linemap_add (line_table, LC_ENTER, false, data_in->current_file,
data_in->current_line);
}
instead of LC_RENAME (but I'm quite positive we can't detect
"the #include directive" or "the end of the file" in any meaningful way).
Tom, can you shed some light on this? Can we simply always use LC_RENAME?
Matt, can you try
Index: gcc/lto-streamer-in.c
===================================================================
--- gcc/lto-streamer-in.c (revision 195841)
+++ gcc/lto-streamer-in.c (working copy)
@@ -164,13 +164,8 @@ lto_input_location (struct bitpack_d *bp
data_in->current_col = bp_unpack_var_len_unsigned (bp);
if (file_change)
- {
- if (prev_file)
- linemap_add (line_table, LC_LEAVE, false, NULL, 0);
-
- linemap_add (line_table, LC_ENTER, false, data_in->current_file,
- data_in->current_line);
- }
+ linemap_add (line_table, LC_RENAME, false, data_in->current_file,
+ data_in->current_line);
else if (line_change)
linemap_line_start (line_table, data_in->current_line,
data_in->current_col);
?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
2013-02-07 10:52 ` [Bug middle-end/56231] " rguenth at gcc dot gnu.org
@ 2013-02-07 13:54 ` rguenth at gcc dot gnu.org
2013-02-07 14:02 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-07 13:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-07 13:54:20 UTC ---
To clarify, we are also switching between different translation-units main
filenames - but I don't think we can easily distinguish this from #includes.
Well, maybe we can, if at compile-time we can identify the "main" source
via libcpp.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
2013-02-07 10:52 ` [Bug middle-end/56231] " rguenth at gcc dot gnu.org
2013-02-07 13:54 ` rguenth at gcc dot gnu.org
@ 2013-02-07 14:02 ` rguenth at gcc dot gnu.org
2013-02-07 14:35 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-07 14:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-07 14:01:50 UTC ---
(In reply to comment #1)
> Index: gcc/lto-streamer-in.c
> ===================================================================
> --- gcc/lto-streamer-in.c (revision 195841)
> +++ gcc/lto-streamer-in.c (working copy)
> @@ -164,13 +164,8 @@ lto_input_location (struct bitpack_d *bp
> data_in->current_col = bp_unpack_var_len_unsigned (bp);
>
> if (file_change)
> - {
> - if (prev_file)
> - linemap_add (line_table, LC_LEAVE, false, NULL, 0);
> -
> - linemap_add (line_table, LC_ENTER, false, data_in->current_file,
> - data_in->current_line);
> - }
> + linemap_add (line_table, LC_RENAME, false, data_in->current_file,
> + data_in->current_line);
> else if (line_change)
> linemap_line_start (line_table, data_in->current_line,
> data_in->current_col);
Does not work because of
const struct line_map *
linemap_add (struct line_maps *set, enum lc_reason reason,
unsigned int sysp, const char *to_file, linenum_type to_line)
{
...
/* When we enter the file for the first time reason cannot be
LC_RENAME. */
linemap_assert (!(set->depth == 0 && reason == LC_RENAME));
trying
Index: gcc/lto-streamer-in.c
===================================================================
--- gcc/lto-streamer-in.c (revision 195846)
+++ gcc/lto-streamer-in.c (working copy)
@@ -165,11 +165,12 @@ lto_input_location (struct bitpack_d *bp
if (file_change)
{
- if (prev_file)
- linemap_add (line_table, LC_LEAVE, false, NULL, 0);
-
- linemap_add (line_table, LC_ENTER, false, data_in->current_file,
- data_in->current_line);
+ if (!prev_file)
+ linemap_add (line_table, LC_ENTER, false, data_in->current_file,
+ data_in->current_line);
+ else
+ linemap_add (line_table, LC_RENAME, false, data_in->current_file,
+ data_in->current_line);
}
else if (line_change)
linemap_line_start (line_table, data_in->current_line,
data_in->current_col);
we'll still eventually enter a file multiple times that way. But let's see
if it makes a difference...
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
` (2 preceding siblings ...)
2013-02-07 14:02 ` rguenth at gcc dot gnu.org
@ 2013-02-07 14:35 ` rguenth at gcc dot gnu.org
2013-02-07 19:10 ` manu at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-07 14:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-07 14:35:24 UTC ---
(In reply to comment #3)
> (In reply to comment #1)
> > Index: gcc/lto-streamer-in.c
> > ===================================================================
> > --- gcc/lto-streamer-in.c (revision 195841)
> > +++ gcc/lto-streamer-in.c (working copy)
> > @@ -164,13 +164,8 @@ lto_input_location (struct bitpack_d *bp
> > data_in->current_col = bp_unpack_var_len_unsigned (bp);
> >
> > if (file_change)
> > - {
> > - if (prev_file)
> > - linemap_add (line_table, LC_LEAVE, false, NULL, 0);
> > -
> > - linemap_add (line_table, LC_ENTER, false, data_in->current_file,
> > - data_in->current_line);
> > - }
> > + linemap_add (line_table, LC_RENAME, false, data_in->current_file,
> > + data_in->current_line);
> > else if (line_change)
> > linemap_line_start (line_table, data_in->current_line,
> > data_in->current_col);
>
> Does not work because of
>
> const struct line_map *
> linemap_add (struct line_maps *set, enum lc_reason reason,
> unsigned int sysp, const char *to_file, linenum_type to_line)
> {
> ...
> /* When we enter the file for the first time reason cannot be
> LC_RENAME. */
> linemap_assert (!(set->depth == 0 && reason == LC_RENAME));
>
> trying
>
> Index: gcc/lto-streamer-in.c
> ===================================================================
> --- gcc/lto-streamer-in.c (revision 195846)
> +++ gcc/lto-streamer-in.c (working copy)
> @@ -165,11 +165,12 @@ lto_input_location (struct bitpack_d *bp
>
> if (file_change)
> {
> - if (prev_file)
> - linemap_add (line_table, LC_LEAVE, false, NULL, 0);
> -
> - linemap_add (line_table, LC_ENTER, false, data_in->current_file,
> - data_in->current_line);
> + if (!prev_file)
> + linemap_add (line_table, LC_ENTER, false, data_in->current_file,
> + data_in->current_line);
> + else
> + linemap_add (line_table, LC_RENAME, false, data_in->current_file,
> + data_in->current_line);
> }
> else if (line_change)
> linemap_line_start (line_table, data_in->current_line,
> data_in->current_col);
>
> we'll still eventually enter a file multiple times that way. But let's see
> if it makes a difference...
Doesn't make a difference.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
` (3 preceding siblings ...)
2013-02-07 14:35 ` rguenth at gcc dot gnu.org
@ 2013-02-07 19:10 ` manu at gcc dot gnu.org
2013-02-08 9:07 ` rguenther at suse dot de
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: manu at gcc dot gnu.org @ 2013-02-07 19:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu.org
--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-02-07 19:10:17 UTC ---
/* Reason for creating a new line map with linemap_add. LC_ENTER is
when including a new file, e.g. a #include directive in C.
LC_LEAVE is when reaching a file's end. LC_RENAME is when a file
name or line number changes for neither of the above reasons
(e.g. a #line directive in C); LC_RENAME_VERBATIM is like LC_RENAME
but a filename of "" is not specially interpreted as standard
input. LC_ENTER_MACRO is when a macro expansion is about to start. */
So perhaps the secret is to use just LC_ENTER?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
` (4 preceding siblings ...)
2013-02-07 19:10 ` manu at gcc dot gnu.org
@ 2013-02-08 9:07 ` rguenther at suse dot de
2013-02-08 10:10 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2013-02-08 9:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> 2013-02-08 09:07:09 UTC ---
On Thu, 7 Feb 2013, manu at gcc dot gnu.org wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
>
> Manuel L?pez-Ib??ez <manu at gcc dot gnu.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |manu at gcc dot gnu.org
>
> --- Comment #5 from Manuel L?pez-Ib??ez <manu at gcc dot gnu.org> 2013-02-07 19:10:17 UTC ---
> /* Reason for creating a new line map with linemap_add. LC_ENTER is
> when including a new file, e.g. a #include directive in C.
> LC_LEAVE is when reaching a file's end. LC_RENAME is when a file
> name or line number changes for neither of the above reasons
> (e.g. a #line directive in C); LC_RENAME_VERBATIM is like LC_RENAME
> but a filename of "" is not specially interpreted as standard
> input. LC_ENTER_MACRO is when a macro expansion is about to start. */
>
> So perhaps the secret is to use just LC_ENTER?
Hmm, I guessed that eventually the "included from" stuff is
built by nesting LC_ENTER w/o LC_LEAVE, so that probably makes it worse.
At least I see we do an initial
linemap_add (line_table, LC_ENTER, 0, NULL, 0);
which might explain the single "included from" with bogus info.
But ISTR other frontends do sth similar. Though now I'm curious
what breaks if we remove the above from lto/lto-lang.c
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
` (5 preceding siblings ...)
2013-02-08 9:07 ` rguenther at suse dot de
@ 2013-02-08 10:10 ` rguenth at gcc dot gnu.org
2013-02-08 10:55 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-08 10:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-08 10:10:14 UTC ---
Testcase:
t.c:
----
volatile int b;
int foo (int *);
int main ()
{
int a;
b = foo (&a);
return 0;
}
t2.c:
-----
int foo (int *a)
{
return *a;
}
> gcc t.c t2.c -O -Wuninitialized
In file included from t.c:1:0,
from :2:
t.c: In function 'main':
t.c:6:5: warning: 'a' is used uninitialized in this function [-Wuninitialized]
b = foo (&a);
^
In file included from t.c:1:0,
from :2:
t.c:5:7: note: 'a' was declared here
int a;
^
with the last proposed change:
> gcc t.c t2.c -O -Wuninitialized
In file included from t.c:1:0:
t.c: In function 'main':
t.c:6:5: warning: 'a' is used uninitialized in this function [-Wuninitialized]
b = foo (&a);
^
In file included from t.c:1:0:
t.c:5:7: note: 'a' was declared here
int a;
^
that's still odd (the included from thing), but slightly better.
I suppose with LC_LEAVE/LC_ENTER on each file change we see we mess up
the include stack completely anyway. So the question is if we can
suppress printing of the include stack completely from within LTO?
I don't see how we can possibly save the stack without great cost,
as we basically stream locations in random order. The only way to
preserve it is to be able to re-construct (at compile-time where we
still have a single TU) the order in which locations were generated
and stream that info so we can replicate location construction in
exactly the same way (though we might not stream all location transitions).
But I suppose it's not worth all the trouble - the include stack is
only used for late diagnostics.
So - how do we "enter" a toplevel file correctly? It seems that
In file included from t.c:1:0:
t.c:5:7: note: 'a' was declared here
int a;
^
is because of the LC_ENTER? Should we simply not bother about
LC_ENTER/LEAVE at all?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
` (6 preceding siblings ...)
2013-02-08 10:10 ` rguenth at gcc dot gnu.org
@ 2013-02-08 10:55 ` rguenth at gcc dot gnu.org
2013-02-08 12:55 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-08 10:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-08 10:54:30 UTC ---
Similar (same testcase) with using
> gcc -include t.c t2.c -O2 -Wuninitialized
In file included from <command-line>:0:0:
./t.c: In function 'main':
./t.c:6:5: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
> gcc -include t2.c t.c -O2 -Wuninitialized
t.c: In function 'main':
t.c:6:5: warning: 'a' is used uninitialized in this function [-Wuninitialized]
but I wonder how LTO manages to get the "included from t.c" ...
tracing includes shows
t.c
. t2.c
t.c
t2.c
t.c
. t2.c
. t.c
In file included from t.c:1:0:
...
Ah, of couse - cross-LTO file we wreck tracking of current file/line/column.
I have a fix!
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
` (7 preceding siblings ...)
2013-02-08 10:55 ` rguenth at gcc dot gnu.org
@ 2013-02-08 12:55 ` rguenth at gcc dot gnu.org
2013-02-08 12:56 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-08 12:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-08 12:55:19 UTC ---
Author: rguenth
Date: Fri Feb 8 12:55:13 2013
New Revision: 195884
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195884
Log:
2013-02-08 Richard Biener <rguenther@suse.de>
PR lto/56231
* lto-streamer.h (struct data_in): Remove current_file, current_line
and current_col members.
* lto-streamer-out.c (lto_output_location): Stream changed bits
en-block for efficiency.
* lto-streamer-in.c (clear_line_info): Remove.
(lto_input_location): Cache current file, line and column
globally via local statics. Read changed bits en-block.
(input_function): Do not call clear_line_info.
(lto_read_body): Likewise.
(lto_input_toplevel_asms): Likewise.
lto/
* lto-lang.c (lto_init): Do not enter a dummy file.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/lto-streamer.h
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
` (8 preceding siblings ...)
2013-02-08 12:55 ` rguenth at gcc dot gnu.org
@ 2013-02-08 12:56 ` rguenth at gcc dot gnu.org
2013-02-12 1:55 ` matt at use dot net
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-08 12:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
Target Milestone|--- |4.8.0
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-08 12:55:58 UTC ---
Fixed.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
` (9 preceding siblings ...)
2013-02-08 12:56 ` rguenth at gcc dot gnu.org
@ 2013-02-12 1:55 ` matt at use dot net
2013-02-12 2:02 ` matt at use dot net
2013-02-12 11:11 ` rguenther at suse dot de
12 siblings, 0 replies; 14+ messages in thread
From: matt at use dot net @ 2013-02-12 1:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #11 from Matt Hargett <matt at use dot net> 2013-02-12 01:55:28 UTC ---
can you add the reduced test case you came up with to the testsuite? I've seen
these issues come and go at various points.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
` (10 preceding siblings ...)
2013-02-12 1:55 ` matt at use dot net
@ 2013-02-12 2:02 ` matt at use dot net
2013-02-12 11:11 ` rguenther at suse dot de
12 siblings, 0 replies; 14+ messages in thread
From: matt at use dot net @ 2013-02-12 2:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #12 from Matt Hargett <matt at use dot net> 2013-02-12 02:02:33 UTC ---
looking at the patch for merging elsewhere, I noticed that
location_t
lto_input_location (struct bitpack_d *bp, struct data_in *data_in)
{
+ static const char *current_file;
+ static int current_line;
+ static int current_col;
bool file_change, line_change, column_change;
unsigned len;
- bool prev_file = data_in->current_file != NULL;
+ bool prev_file = current_file != NULL;
current_file is potentially of unknown value on the comparison in the last
line, right? or is there some static const initialization rule that implicitly
initializes it to 0?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug middle-end/56231] warning traces have bogus line information when using LTO
2013-02-06 21:56 [Bug middle-end/56231] New: warning traces have bogus line information when using LTO matt at use dot net
` (11 preceding siblings ...)
2013-02-12 2:02 ` matt at use dot net
@ 2013-02-12 11:11 ` rguenther at suse dot de
12 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2013-02-12 11:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> 2013-02-12 11:11:11 UTC ---
On Tue, 12 Feb 2013, matt at use dot net wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
>
> --- Comment #12 from Matt Hargett <matt at use dot net> 2013-02-12 02:02:33 UTC ---
> looking at the patch for merging elsewhere, I noticed that
>
> location_t
> lto_input_location (struct bitpack_d *bp, struct data_in *data_in)
> {
> + static const char *current_file;
> + static int current_line;
> + static int current_col;
> bool file_change, line_change, column_change;
> unsigned len;
> - bool prev_file = data_in->current_file != NULL;
> + bool prev_file = current_file != NULL;
>
>
> current_file is potentially of unknown value on the comparison in the last
> line, right? or is there some static const initialization rule that implicitly
> initializes it to 0?
Yes, all statics are zero-initialized.
As for the testcase, the LTO testsuite harness does not support
dg-warning and friends so it's not possible to add a meaningful
testcase.
^ permalink raw reply [flat|nested] 14+ messages in thread