https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #60 from Roger Orr ---
Thanks; I can now confirm that a full build of our application with distcc
works without problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
Bernd Schmidt changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #58 from Bernd Schmidt ---
Author: bernds
Date: Wed Apr 13 11:40:37 2016
New Revision: 234932
URL: https://gcc.gnu.org/viewcvs?rev=234932=gcc=rev
Log:
Patch from Roger Orr
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #57 from Roger Orr ---
Created attachment 38232
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38232=edit
Stripped down intermediate file
I've managed to reproduce the problem without including any proprietary code -
code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
Bernd Schmidt changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #55 from Roger Orr ---
Note - I should have added that I am not at all sure the fix above is
*correct*, simply that it prevents accessing the freed entry.
I don't know enough about how the code works to know whether the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #54 from Roger Orr ---
Unfortunately the patch does not help: the cached 'from' pointer is a pointer
into the old maps entry -- the one which has now been deallocated.
The first test, main_file_p, now (correctly) fails.
The second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #53 from Bernd Schmidt ---
Hmm. Something got reallocated perhaps? It's not entirely obvious to me where
that would happen. Does the following help at all?
Index: directives.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #52 from Roger Orr ---
Ah - added print of *pfile->line_table at line 978 and compared with the value
when we error.
978 struct line_maps *line_table = pfile->line_table;
$3702 = {info_ordinary = {maps = 0x7fffec65d000,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #51 from Roger Orr ---
Thanks, I hope to try that on Monday.
The function gets called multiple times, so I need to identify the last time.
The memory must have changed *during* the call to do_linemarker as the new_file
variable is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #50 from Bernd Schmidt ---
The 0xa5 bytes probably come from ggc-page, which tries to poison freed memory.
This does suggest that there's a use-after-free issue here.
At the step after "p map", try "watch -l map->to_file" followed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #49 from Roger Orr ---
Alas, valgrind finds nothing untoward.
make MAKEINFO=true STAGE1_CXXFLAGS="-g -O0" clean-stage1
make MAKEINFO=true STAGE1_CXXFLAGS="-g -O0" all-stage1
valgrind /var/tmp/gcc-trunk-234481/build/gcc/cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #48 from Bernd Schmidt ---
Try running cc1plus with valgrind to see whether that detects anything
untoward.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #47 from Roger Orr ---
Sorry, I wasn't clear enough. I'm unfortunately not at present able to post the
whole source file.
The file I posted *only* contains the line directives, so people can confirm
whether there were any problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #46 from Bernd Schmidt ---
I tried compiling this file, with C or C++, with or without -fpreprocessed, all
sorts of options including -std=c++14 -O3, and did not get a compilation
failure.
Can anyone else reproduce this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #45 from Roger Orr ---
While investigating the problem I am experiencing I have found it is stable
across g++ builds - I have tried a build using revision 234741 which has the
identical diagnostic output from the compilation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #44 from Roger Orr ---
Created attachment 38218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38218=edit
Intermediate file
I am as yet unable to upload the code for an example.
However, I've attached a file containing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #43 from Bernd Schmidt ---
I suspect the message Roger quoted was from the earlier version with the
printf; that one didn't give a location.
I advocate no action until we have a reproducer so we can know what's going on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #42 from Manuel López-Ibáñez ---
(In reply to Roger Orr from comment #41)
> I have seen the message before: for example from a build with revision
>
> line-map.c: file "/usr/include/asm/sockios.h" left but not entered
You can also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #41 from Roger Orr ---
I have seen the message before: for example from a build with revision
line-map.c: file "/usr/include/asm/sockios.h" left but not entered
I've only noticed it with builds from gcc-trunk, which I tested with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #40 from Bernd Schmidt ---
The message previously was a plain printf, not a warning or error so it would
not have interrupted compilation. Did you get the message with earlier
compilers, or did it start to appear recently?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #39 from Roger Orr ---
The resolution of this issue causes a problem for me as it results in
compilation errors in our build.
We are compiling with distcc which AIUI distributes the pre-processed
intermediate output.
With revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #37 from Jeffrey A. Law ---
Author: law
Date: Fri Mar 25 16:15:39 2016
New Revision: 234481
URL: https://gcc.gnu.org/viewcvs?rev=234481=gcc=rev
Log:
PR lto/69650
* directives.c (do_linemarker): Test for file left but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #36 from Manuel López-Ibáñez ---
(In reply to Bernd Schmidt from comment #35)
> I don't think guesswork will be very helpful in practice with a corrupted
> #line structure, and errors of this nature shouldn't really occur anyway
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #35 from Bernd Schmidt ---
I don't think guesswork will be very helpful in practice with a corrupted #line
structure, and errors of this nature shouldn't really occur anyway outside of
artificial testcases. I'm leaning towards either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #34 from Manuel López-Ibáñez ---
(In reply to Bernd Schmidt from comment #33)
> It does mean LC_LEAVE, but AFAICT the filename is the file being returned to.
>
> Including a file called "t.h" from "v.c" gives this after -E:
>
> # 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #33 from Bernd Schmidt ---
It does mean LC_LEAVE, but AFAICT the filename is the file being returned to.
Including a file called "t.h" from "v.c" gives this after -E:
# 1 "t.h" 1
int t;
# 2 "v.c" 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #32 from Manuel López-Ibáñez ---
(In reply to David Malcolm from comment #31)
> I may have been wrong in my earlier question on the mailing list; doesn't
> the flag value of 2 mean "LC_LEAVE"? (is the filename meant to refer to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #31 from David Malcolm ---
(In reply to Bernd Schmidt from comment #30)
> I'm just using CPP_W_NONE in the patch I'm testing and that seems to work.
>
> Regarding the error message, here's what we'll get:
>
> 69650.c:4:55: warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #30 from Bernd Schmidt ---
I'm just using CPP_W_NONE in the patch I'm testing and that seems to work.
Regarding the error message, here's what we'll get:
69650.c:4:55: warning: file "fish" left but not entered
# 9 "fish" 2 /* {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #29 from Manuel López-Ibáñez ---
(In reply to Bernd Schmidt from comment #26)
> Also, let's keep in mind the issue David found - "left but not entered"
> seems like a misleading message, something like "unexpectedly reentered"
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #28 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #25)
> Yes, Bernd's patch still works then. I'd prefer this at this stage.
> There doesn't seem to be any CPP_W_* that fits though.
Do you need one? Perhaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #27 from rguenther at suse dot de ---
On Wed, 23 Mar 2016, bernds at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
>
> --- Comment #26 from Bernd Schmidt ---
> Also, let's keep in mind the issue David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #26 from Bernd Schmidt ---
Also, let's keep in mind the issue David found - "left but not entered" seems
like a misleading message, something like "unexpectedly reentered" seems to fit
better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |bernds at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #24 from Richard Biener ---
Created attachment 38071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38071=edit
alternate patch
Good question - I attached mine and will check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #23 from Manuel López-Ibáñez ---
(In reply to rguent...@suse.de from comment #22)
> Maybe we can put the error under some new flag though.
Does Bernd's patch still work if we just warn instead of error? I still think
doing this in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #22 from rguenther at suse dot de ---
On Wed, 23 Mar 2016, manu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
>
> --- Comment #20 from Manuel López-Ibáñez ---
> (In reply to David Malcolm from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #20 from Manuel López-Ibáñez ---
(In reply to David Malcolm from comment #18)
> FWIW Bernd posted a different patch for this, here:
> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00598.html
FWIW, if that works for all testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #21 from rguenther at suse dot de ---
On Wed, 23 Mar 2016, manu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
>
> --- Comment #19 from Manuel López-Ibáñez ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #19 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #17)
> "caused" by r44789 which introduced this path (initially with error ||
> to_file == NULL) with a description of just
>
>(add_line_map): Return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #18 from David Malcolm ---
FWIW Bernd posted a different patch for this, here:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00598.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #17 from Richard Biener ---
"caused" by r44789 which introduced this path (initially with error || to_file
== NULL) with a description of just
(add_line_map): Return pointer to const. When passed NULL to_file
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #16 from rguenther at suse dot de ---
On Wed, 23 Mar 2016, manu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
>
> --- Comment #15 from Manuel López-Ibáñez ---
> (In reply to Manuel López-Ibáñez
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #15 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #14)
> (In reply to rguent...@suse.de from comment #12)
> > > This is an invalid linemarker. libcpp should ignore it completely and
> > > behave as
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #14 from Manuel López-Ibáñez ---
(In reply to rguent...@suse.de from comment #12)
> > This is an invalid linemarker. libcpp should ignore it completely and
> > behave as
> > if it was not present. It seems it is not doing that for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #10)
> Not sure who's familiar with the C/C++ FE interfacing to libcpp and if
> those "bogus" locations should simply never be assigned to input_location...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #12 from rguenther at suse dot de ---
On Wed, 23 Mar 2016, manu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
>
> --- Comment #11 from Manuel López-Ibáñez ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #11 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #10)
> maybe this location isn't supposed to be expanded?
>
> Or nothing is ever supposed to get this location?
>
> For example changing the testcase to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic, lto
Priority|P3
52 matches
Mail list logo