> > Hi all, Jakub,
> >
> > On 09/07/2013 01:16 PM, Jakub Jelinek wrote:
> > >As I wrote in the PR, IMHO mangle_decl should
> > > location_t save_location = input_location;
> > > input_location = DECL_SOURCE_LOCATION (decl);
> > >...
> > > input_location = save_location;
> > >around the call,
> Hi all, Jakub,
>
> On 09/07/2013 01:16 PM, Jakub Jelinek wrote:
> >As I wrote in the PR, IMHO mangle_decl should
> > location_t save_location = input_location;
> > input_location = DECL_SOURCE_LOCATION (decl);
> >...
> > input_location = save_location;
> >around the call,
> I had a look an
Hi all, Jakub,
On 09/07/2013 01:16 PM, Jakub Jelinek wrote:
As I wrote in the PR, IMHO mangle_decl should
location_t save_location = input_location;
input_location = DECL_SOURCE_LOCATION (decl);
...
input_location = save_location;
around the call,
I had a look and I'm afraid this is alr
On 09/07/2013 06:13 AM, Paolo Carlini wrote:
Actually this kind of change makes a lot of sense to me (cmp clang too): since at that point we do
*not* really know the location of the "required from" bit, just plainly admit it. Would
it be possible in such cases to have a conditional in the diagn
On Sat, Sep 07, 2013 at 11:00:22AM +0200, Paolo Carlini wrote:
> and thanks for the analysis, now I understand the issue a little more.
>
> On 09/07/2013 10:28 AM, Jan Hubicka wrote:
> >So it is just an accident that the line info is output sanely (if
> >line 9 is sane, I don't exactly know)
> I w
Hi
>What I can think of is to hide the stale source location when it no
>longer have
>defined meaning:
>Index: cgraphunit.c
>===
>--- cgraphunit.c(revision 202352)
>+++ cgraphunit.c(working copy)
>@@ -913,6 +913,7 @@
> Hi Honza,
>
> and thanks for the analysis, now I understand the issue a little more.
>
> On 09/07/2013 10:28 AM, Jan Hubicka wrote:
> >So it is just an accident that the line info is output sanely (if
> >line 9 is sane, I don't exactly know)
> I would say that in general it's definitely sane, b
Hi Honza,
and thanks for the analysis, now I understand the issue a little more.
On 09/07/2013 10:28 AM, Jan Hubicka wrote:
So it is just an accident that the line info is output sanely (if line
9 is sane, I don't exactly know)
I would say that in general it's definitely sane, because that is t
> > >+ 2013-09-04 Jan Hubicka
> > >+
> > >+ PR middle-end/58201
> > >+ * cgraphunit.c (analyze_functions): Clear AUX fields
> > >+ after processing; initialize assembler name has.
> > >+
> > I checked and double checked and with this commit a C++ test regressed:
> >
> > FAIL: g++.dg/template
> >+ 2013-09-04 Jan Hubicka
> >+
> >+PR middle-end/58201
> >+* cgraphunit.c (analyze_functions): Clear AUX fields
> >+after processing; initialize assembler name has.
> >+
> I checked and double checked and with this commit a C++ test regressed:
>
> FAIL: g++.dg/template/cond2.C -st
Hi Honza,
On 09/06/2013 01:05 AM, Jan Hubicka wrote:
Hi,
this is the patch I commited after testing on x86_64-linux.
Honza
Index: ChangeLog
===
*** ChangeLog (revision 202271)
--- ChangeLog (working copy)
***
*** 1
Hi,
this is the patch I commited after testing on x86_64-linux.
Honza
Index: ChangeLog
===
*** ChangeLog (revision 202271)
--- ChangeLog (working copy)
***
*** 1,3
--- 1,9
+ 2013-09-04 Jan Hubicka
+
+
> On 09/04/2013 10:49 AM, Bernd Schmidt wrote:
> >On 09/04/2013 06:04 PM, Jan Hubicka wrote:
> >>this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for
> >>functions w/o
> >>bodies I did not really anticipate.
> >[...]
> >>I would like to basically ask if it seems to make sens
Jan Hubicka wrote:
>> On 09/04/2013 06:04 PM, Jan Hubicka wrote:
>> > this is third fallout of my change to remove
>DECL_ARGUMENTS/DECL_RESULT for functions w/o
>> > bodies I did not really anticipate.
>> [...]
>> > I would like to basically ask if it seems to make sense to go this
>route and
>> >
On 09/04/2013 10:49 AM, Bernd Schmidt wrote:
On 09/04/2013 06:04 PM, Jan Hubicka wrote:
this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for
functions w/o
bodies I did not really anticipate.
[...]
I would like to basically ask if it seems to make sense to go this route
On 09/04/2013 07:09 PM, Jan Hubicka wrote:
> How do you support K&R functions here? My basic idea was that TYPE_ARG_TYPES
> should give enough information about external function calling convention
> anyone will ever need. I would hope that this will be sufficient for your
> use, too, despite the
> On 09/04/2013 06:04 PM, Jan Hubicka wrote:
> > this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for
> > functions w/o
> > bodies I did not really anticipate.
> [...]
> > I would like to basically ask if it seems to make sense to go this route and
> > try to get rid of thos
On 09/04/2013 06:04 PM, Jan Hubicka wrote:
> this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for
> functions w/o
> bodies I did not really anticipate.
[...]
> I would like to basically ask if it seems to make sense to go this route and
> try to get rid of those declarations
On Wed, Sep 04, 2013 at 06:04:09PM +0200, Jan Hubicka wrote:
> * cgraphunit.c (analyze_functions): Populate assembler names once done
> with early unreachable function removal.
Please add some of the testcases from the PRs and mention the PRs in the
ChangeLog entry.
> --- cgraphunit.c
19 matches
Mail list logo
