Jason suggested keeping it in the branch since it doesn't fix any regressions,
so it's living there for now.
AldyOn Jan 8, 2015 4:24 AM, Richard Biener wrote:
>
> On Sat, Dec 20, 2014 at 5:49 AM, Aldy Hernandez wrote:
> > On 12/19/14 11:03, Jason Merrill wrote:
> >
> > First of all, my bad R
On Sat, Dec 20, 2014 at 5:49 AM, Aldy Hernandez wrote:
> On 12/19/14 11:03, Jason Merrill wrote:
>
> First of all, my bad Richard. I vaguely remember you mentioning something
> about Java, but it was early enough in the project that I had no idea what
> you were talking about. Thanks for your pa
On 12/19/14 11:03, Jason Merrill wrote:
First of all, my bad Richard. I vaguely remember you mentioning
something about Java, but it was early enough in the project that I had
no idea what you were talking about. Thanks for your patience.
It looks like java aliases are still using assemble
> It looks like java aliases are still using assemble_alias directly;
assemble_alias dispatch to code adding alias pair to callgarph, so that should
be safe. My understanding is that Aldys concern is that creating the aliases
early leads to undefined symbol because we produce aliases that never g
It looks like java aliases are still using assemble_alias directly;
switching to using same_body aliases like thunks and such should handle
the issue.
Jason
On 12/19/14 10:53, Jan Hubicka wrote:
Yeah, I've told you that this is a major blocker I couldn't resolve the last
time I tried to move things.
IMHO this Java method aliases needs to be made cgraph-aware somehow,
thus we need to build the aliases as proper aliases during candidate
collection bu
On 12/19/14 10:58, Jan Hubicka wrote:
Yeah, I've told you that this is a major blocker I couldn't resolve the last
time I tried to move things.
IMHO this Java method aliases needs to be made cgraph-aware somehow,
thus we need to build the aliases as proper aliases during candidate
collection bu
> >
> > Yeah, I've told you that this is a major blocker I couldn't resolve the last
> > time I tried to move things.
> >
> > IMHO this Java method aliases needs to be made cgraph-aware somehow,
> > thus we need to build the aliases as proper aliases during candidate
> > collection but somehow ma
>
> Yeah, I've told you that this is a major blocker I couldn't resolve the last
> time I tried to move things.
>
> IMHO this Java method aliases needs to be made cgraph-aware somehow,
> thus we need to build the aliases as proper aliases during candidate
> collection but somehow mark them reclai
On Thu, Dec 18, 2014 at 8:23 PM, Aldy Hernandez wrote:
> Hi Jason.
>
> It's embarrassing that I just got to this now. I hope you don't repay the
> favor and take as long responding to me :(.
>
> On 09/12/14 08:15, Jason Merrill wrote:
>>
>> On 09/11/2014 08:51 PM, Aldy Hernandez wrote:
>
>
>>>
Hi Jason.
It's embarrassing that I just got to this now. I hope you don't repay
the favor and take as long responding to me :(.
On 09/12/14 08:15, Jason Merrill wrote:
On 09/11/2014 08:51 PM, Aldy Hernandez wrote:
/* Generate hidden aliases for Java. */
- if (candidates)
+ if (java_
On 09/12/14 10:56, Jason Merrill wrote:
On 09/12/2014 01:48 PM, Aldy Hernandez wrote:
Unless I'm misunderstanding something, validate_phases() verifies that
the numbers add up by looking at the actual string name of the phase,
irregardless of if you timevar_push/pop'ed it:
Yes, but why wouldn'
On 09/15/2014 05:32 AM, Richard Biener wrote:
Btw, if the VTV stuff really needs to come afterwards how does VTV
work with LTO then?
It's conservatively correct: it emits information for all the vtables
that are actually generated for the TU. If LTO optimizes some of them
away, the VTV infor
On Fri, Sep 12, 2014 at 7:10 PM, Aldy Hernandez wrote:
> On 09/12/14 08:15, Jason Merrill wrote:
>>
>> On 09/11/2014 08:51 PM, Aldy Hernandez wrote:
>>>
>>> - timevar_start (TV_PHASE_DEFERRED);
>>
>>
>>> - timevar_stop (TV_PHASE_DEFERRED);
>>> - timevar_start (TV_PHASE_OPT_GEN);
>>
>>
>> Why?
>
On 09/12/2014 01:48 PM, Aldy Hernandez wrote:
Unless I'm misunderstanding something, validate_phases() verifies that
the numbers add up by looking at the actual string name of the phase,
irregardless of if you timevar_push/pop'ed it:
Yes, but why wouldn't the numbers add up? The comment for
t
On 09/12/14 10:33, Jason Merrill wrote:
On 09/12/2014 01:10 PM, Aldy Hernandez wrote:
TV_PHASE_DEFERRED, on the other hand, is a bit problematic because it
was originally wrapping the code inside LANG_HOOKS_WRITE_GLOBALS, which
will now reside inside the parser (and is thus included in
TV_PHASE_
On 09/12/2014 01:10 PM, Aldy Hernandez wrote:
TV_PHASE_DEFERRED, on the other hand, is a bit problematic because it
was originally wrapping the code inside LANG_HOOKS_WRITE_GLOBALS, which
will now reside inside the parser (and is thus included in
TV_PHASE_PARSING now). Originally it was mutually
On 09/12/14 08:15, Jason Merrill wrote:
On 09/11/2014 08:51 PM, Aldy Hernandez wrote:
- timevar_start (TV_PHASE_DEFERRED);
- timevar_stop (TV_PHASE_DEFERRED);
- timevar_start (TV_PHASE_OPT_GEN);
Why?
TV_PHASE_OPT_GEN is now in compile_file(), where we call
finalize_compilation_unit di
On 09/11/2014 08:51 PM, Aldy Hernandez wrote:
- timevar_start (TV_PHASE_DEFERRED);
- timevar_stop (TV_PHASE_DEFERRED);
- timevar_start (TV_PHASE_OPT_GEN);
Why?
/* Generate hidden aliases for Java. */
- if (candidates)
+ if (java_hidden_aliases)
{
- build_java_method_alia
On Fri, Sep 12, 2014 at 2:51 AM, Aldy Hernandez wrote:
> On 09/09/14 02:16, Richard Biener wrote:
>>
>> On Tue, Sep 9, 2014 at 2:00 AM, Aldy Hernandez wrote:
>>>
>>> On 09/05/14 02:00, Richard Biener wrote:
>
>
>>> What I have in mind is:
>>>
>>> 1. Move the FE specific things that come before th
On 09/09/14 02:16, Richard Biener wrote:
On Tue, Sep 9, 2014 at 2:00 AM, Aldy Hernandez wrote:
On 09/05/14 02:00, Richard Biener wrote:
What I have in mind is:
1. Move the FE specific things that come before the call to
finalize_compilation_unit currently in each LANG_HOOKS_WRITE_GLOBALS, i
On Tue, Sep 9, 2014 at 2:00 AM, Aldy Hernandez wrote:
> On 09/05/14 02:00, Richard Biener wrote:
>
> [jason: C++ questions throughout.]
>
>> On Fri, Sep 5, 2014 at 4:38 AM, Aldy Hernandez wrote:
>>>
>>> On 09/04/14 03:42, Richard Biener wrote:
On Wed, Sep 3, 2014 at 7:54 PM, Aldy H
On 09/05/14 02:00, Richard Biener wrote:
[jason: C++ questions throughout.]
On Fri, Sep 5, 2014 at 4:38 AM, Aldy Hernandez wrote:
On 09/04/14 03:42, Richard Biener wrote:
On Wed, Sep 3, 2014 at 7:54 PM, Aldy Hernandez wrote:
I meant that LATE_WRITE_GLOBALS shouldn't be a langhook
at all
On Fri, Sep 5, 2014 at 4:38 AM, Aldy Hernandez wrote:
> On 09/04/14 03:42, Richard Biener wrote:
>>
>> On Wed, Sep 3, 2014 at 7:54 PM, Aldy Hernandez wrote:
>
>
>> Flow-wise I still want to move hand-off to the cgraph code to toplev.c,
>> out from the FEs final_write_gloabals hook:
>>
>>/* Th
On 09/04/14 03:42, Richard Biener wrote:
On Wed, Sep 3, 2014 at 7:54 PM, Aldy Hernandez wrote:
Flow-wise I still want to move hand-off to the cgraph code to toplev.c,
out from the FEs final_write_gloabals hook:
/* This must also call finalize_compilation_unit. */
lang_hooks.decls.fina
On Thu, 2014-09-04 11:34:57 -0700, Aldy Hernandez wrote:
> On 09/04/14 11:23, Richard Biener wrote:
> > On September 4, 2014 7:54:14 PM CEST, Aldy Hernandez
> > wrote:
> > > > I think this merge caused bootstrap failure on Linux/i686
> > > > https://gcc.gnu.org/ml/gcc-regression/2014-09/msg00010
Hi, FWIW I saw the same problem on arm* and aarch64 targets.
On 4 September 2014 20:34, Aldy Hernandez wrote:
> On 09/04/14 11:23, Richard Biener wrote:
>>
>> On September 4, 2014 7:54:14 PM CEST, Aldy Hernandez
>> wrote:
>>>
>>>
I think this merge caused bootstrap failure on Linux/i686
>
On 09/04/14 11:23, Richard Biener wrote:
On September 4, 2014 7:54:14 PM CEST, Aldy Hernandez wrote:
I think this merge caused bootstrap failure on Linux/i686
https://gcc.gnu.org/ml/gcc-regression/2014-09/msg00010.html
I incorrectly pushed my branch onto trunk. It's being reverted.
To
On September 4, 2014 7:54:14 PM CEST, Aldy Hernandez wrote:
>
>> I think this merge caused bootstrap failure on Linux/i686
>>
>> https://gcc.gnu.org/ml/gcc-regression/2014-09/msg00010.html
>>
>>
>
>I incorrectly pushed my branch onto trunk. It's being reverted.
Too bad!
;)
Richard.
I think this merge caused bootstrap failure on Linux/i686
https://gcc.gnu.org/ml/gcc-regression/2014-09/msg00010.html
I incorrectly pushed my branch onto trunk. It's being reverted.
On Wed, Sep 3, 2014 at 10:54 AM, Aldy Hernandez wrote:
> [Jason, Richard]: Is it useful for my patches to contain ChangeLog entries?
> I find them mildly annoying for something that will inevitably be rewritten
> multiple times, but if it aids in reviewing my WIP, I am more than happy to
> continu
On Wed, Sep 3, 2014 at 7:54 PM, Aldy Hernandez wrote:
> [Jason, Richard]: Is it useful for my patches to contain ChangeLog entries?
> I find them mildly annoying for something that will inevitably be rewritten
> multiple times, but if it aids in reviewing my WIP, I am more than happy to
> continue
[Jason, Richard]: Is it useful for my patches to contain ChangeLog
entries? I find them mildly annoying for something that will inevitably
be rewritten multiple times, but if it aids in reviewing my WIP, I am
more than happy to continue including them.
On 08/28/14 11:01, Jason Merrill wrote:
On Thu, Aug 28, 2014 at 10:14 PM, Jason Merrill wrote:
> On 08/28/2014 03:13 PM, Richard Biener wrote:
knowledge of scopes and such, only available in the FE. Is there a
generic way of determining if a DECL is in global scope?
>>
>>
>> Via DECL_CONTEXT and the global scope macro pr
On 08/28/2014 03:13 PM, Richard Biener wrote:
knowledge of scopes and such, only available in the FE. Is there a
generic way of determining if a DECL is in global scope?
Via DECL_CONTEXT and the global scope macro predicate. Eventually not enough
to detect class scope statics.
!decl_functi
On August 28, 2014 8:01:05 PM CEST, Jason Merrill wrote:
>On 08/28/2014 01:34 PM, Aldy Hernandez wrote:
>> I wonder if instead of early dumping of all the DECLs, we could only
>> dump the toplevel scoped DECLs, and let inheritance set the proper
>> contexts.
>
>Yes, I think this makes a lot more s
On 08/28/2014 01:34 PM, Aldy Hernandez wrote:
I wonder if instead of early dumping of all the DECLs, we could only
dump the toplevel scoped DECLs, and let inheritance set the proper
contexts.
Yes, I think this makes a lot more sense; do it at a well-defined point
in compilation rather than as
On 08/28/14 06:58, Richard Biener wrote:
On Wed, Aug 27, 2014 at 4:42 AM, Aldy Hernandez wrote:
This patch fixes a bunch of guality failures. With it I get 144 guality.exp
failures vs. 163 for "make check-gcc RUNTESTFLAGS=guality.exp". A lot
better than 100% fail rate ;-).
Variable DIEs were
On Wed, Aug 27, 2014 at 4:42 AM, Aldy Hernandez wrote:
> This patch fixes a bunch of guality failures. With it I get 144 guality.exp
> failures vs. 163 for "make check-gcc RUNTESTFLAGS=guality.exp". A lot
> better than 100% fail rate ;-).
>
> Variable DIEs were not being reused. Instead, variab
This patch fixes a bunch of guality failures. With it I get 144
guality.exp failures vs. 163 for "make check-gcc
RUNTESTFLAGS=guality.exp". A lot better than 100% fail rate ;-).
Variable DIEs were not being reused. Instead, variable DIEs even had
the wrong context (unilaterally the compilat
40 matches
Mail list logo
