Hi!
I'd like to announce dwz-0.1, a DWARF compression tool I've spent this
April hacking on. It is currently (see below) written as standalone tool,
with minimal dependencies (though time hasn't been spent on portability
yet, so assumes glibc host), in particular just a small amount of code
in it
Hello,
If I move GIMPLE_SWITCH lowering from stmt.c to somewhere in the
GIMPLE pass pipeline, I run into an issue with SJLJ exceptions. The
problem is that except.c:sjlj_emit_dispatch_table() builts a
GIMPLE_SWITCH and calls expand_case on it. If I move all non-casesi,
non-tablejump code out of st
On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng wrote:
> Hi,
> As discussed at thread
> "http://gcc.gnu.org/ml/gcc/2012-04/msg00396.html";, I am trying a patch
> now.
> The problem here is I have to go through all basic block from
> "sink_from" to "sink_to" to check whether
> the memory might be clobbe
On Wed, Apr 18, 2012 at 10:35 AM, Steven Bosscher wrote:
> Hello,
>
> If I move GIMPLE_SWITCH lowering from stmt.c to somewhere in the
> GIMPLE pass pipeline, I run into an issue with SJLJ exceptions. The
> problem is that except.c:sjlj_emit_dispatch_table() builts a
> GIMPLE_SWITCH and calls expa
> > What is the reason why lowering for SJLJ exceptions is not done in GIMPLE?
>
> Because it completely wrecks loops because we factor the SJLJ site,
> thus
>
> fn ()
> {
> ...
> for (;;)
> {
>try { X } catch { Y }
> }
>
> becomes
>
> fn ()
> {
>if (setjmp ())
> {
>
Andrew Stubbs writes:
> On 17/04/12 18:20, Richard Sandiford wrote:
>> Andrew Stubbs writes:
>>> Hi all,
>>>
>>> I can see why copying from one pseudo-register to another would not be a
>>> reason *not* to decompose a register, but I don't understand why this is
>>> a reason to say it *should* be
Hi!
Something not addressed yet in dwz and unfortunately without
linker or compiler help not 100% addressable is debug info for
comdat functions.
Consider attached testcase with comdat foo function, seems the
current linker behavior (well, tested with 2.21.53.0.1 ld.bfd)
is that for DW_TAG_subpro
On 18/04/12 11:55, Richard Sandiford wrote:
The problem is that not all register moves are always going to be
eliminated, even when no mode changes are involved. It might make
sense to restrict that code you quoted:
case SIMPLE_PSEUDO_REG_MOVE:
if (MODES_TIEABLE_P (GET
Hi!
Sorry for following up to self, but something I forgot to add
about this:
On Wed, Apr 18, 2012 at 01:16:40PM +0200, Jakub Jelinek wrote:
> Something not addressed yet in dwz and unfortunately without
> linker or compiler help not 100% addressable is debug info for
> comdat functions.
When di
On Wed, Apr 18, 2012 at 09:49:11AM +0200, Mike Dupont wrote:
> this is exciting, thanks for sharing.
>
> I wonder what amount of data is even the same between many libraries,
Of course there is a lot of DWARF duplication in between different
libraries, or binaries, or e.g. Linux kernel modules (w
On Wed, Apr 18, 2012 at 02:26:45PM +0200, Jakub Jelinek wrote:
> Of course there is a lot of DWARF duplication in between different
> libraries, or binaries, or e.g. Linux kernel modules (which have the
> added problem that they have relocations against the sections; we could
> apply and remove the
On 04/18/2012 07:53 AM, Jakub Jelinek wrote:
Consider attached testcase with comdat foo function, seems the
current linker behavior (well, tested with 2.21.53.0.1 ld.bfd)
is that for DW_TAG_subprogram with DW_AT_low_pc/DW_AT_high_pc
having section relative relocs against comdat functions
if the c
On 04/18/2012 05:39 AM, Jan Hubicka wrote:
> Well, if SJLJ lowering happens as gimple pass somewhere near the end of gimple
> queue, this should not be problem at all. (and implementation would be
> cleaner)
If you can find a clean way of separating sjlj expansion from dw2 expansion,
please do.
On Wed, Apr 18, 2012 at 08:43:37AM -0400, Jason Merrill wrote:
> On 04/18/2012 07:53 AM, Jakub Jelinek wrote:
> >Consider attached testcase with comdat foo function, seems the
> >current linker behavior (well, tested with 2.21.53.0.1 ld.bfd)
> >is that for DW_TAG_subprogram with DW_AT_low_pc/DW_AT_
Andrew Stubbs writes:
> On 18/04/12 11:55, Richard Sandiford wrote:
>> The problem is that not all register moves are always going to be
>> eliminated, even when no mode changes are involved. It might make
>> sense to restrict that code you quoted:
>>
>> case SIMPLE_PSEUDO_REG_MOVE:
>>
On 18/04/12 16:53, Richard Sandiford wrote:
Andrew Stubbs writes:
On 18/04/12 11:55, Richard Sandiford wrote:
The problem is that not all register moves are always going to be
eliminated, even when no mode changes are involved. It might make
sense to restrict that code you quoted:
Andrew Stubbs writes:
> On 18/04/12 16:53, Richard Sandiford wrote:
>> Andrew Stubbs writes:
>>> On 18/04/12 11:55, Richard Sandiford wrote:
The problem is that not all register moves are always going to be
eliminated, even when no mode changes are involved. It might make
sense to
Hello Everyone,
Is the GIT mirror for GCC down? I tried clicking on the snapshot link
near a commit and it is timing out.
Thanks,
Balaji V. Iyer.
> This seems clearly wrong to me. A reference to a symbol in a discarded
> section should not resolve to an offset into a different section. I thought
> the linker always resolved such references to 0, and I think that is what we
> want.
Even resolving to 0 can cause problems. In the Gnu linker,
"Iyer, Balaji V" writes:
> Is the GIT mirror for GCC down? I tried clicking on the snapshot
> link near a commit and it is timing out.
It could be that generating the snapshot is taking more CPU time
than the web server is configured to permit. Consider making
your own git clone, and generate
On 04/18/2012 07:40 PM, Cary Coutant wrote:
Nice -- I've been wanting to do that for a while, but I always thought
it would be a lot harder. I see that you've based this on the
infrastructure created for -feliminate-dwarf2-dups. I don't think that
will play nice with -fdebug-types-section, though
On Wed, Apr 18, 2012 at 03:23:35PM +0200, Jakub Jelinek wrote:
> > DW_TAG_GNU_call_site wants to refer to the called function's DIE, so
> > the function die in the separate unit needs to have its own symbol.
> > Perhaps _call_site could refer to the function symbol instead? That
> > seems more cor
22 matches
Mail list logo
