> Indeed. I also wonder why dump_kind_p does not check if dumping is
> active at all? Thus, inside check dump_file / alternate dump_file for NULL.
I am testing a patch which includes a check for
dump_file/alternate_dump_file in dump_kind_p. This is in addition to
checking flags.
>> 2. dump_kind
> 1. OK, I understand that e.g.
>
> if (dump_file && (dump_flags & TDF_DETAILS))
>
>should be converted into:
>
> if (dump_kind_p (TDF_DETAILS))
>
>But what about current code that does not care about dump_flags?
>E.g. converting simple
>
> if (dump_file)
>
>to
>
>
Sharad Singhai schrieb:
I have enhanced the dump infrastructure in r191883, r191884. These
patches updated the tree/rtl dump facility so that passes do not
reference the dump file directly, but instead use a different (and
hopefully cleaner) API.
Instead of this
if (dump_file)
fprint
On 10/16/2012 12:45 AM, Mischa Baars wrote:
> Who will be fixing this? Macro arguments without brackets are not
> accepted by the assembler.
>
> If I can be of any help, let me know.
We still don't know what your problem is.
Provide us with an example that we can try.
You need to tell us:
Wh
On 10/16/2012 03:31 PM, Dominique Dhumieres wrote:
> Thanks for the quick answer.
>
>> That's just the way it works, so I suppose you could call it a feature.
>
> So the answer to (1) is yes and to (2) it is a poorly documented feature.
> May be the restriction to one dg-do directive should be ad
On 12-10-16 5:49 PM, Steven Bosscher wrote:
On Tue, Oct 16, 2012 at 7:20 PM, Andi Kleen wrote:
Vladimir Makarov writes:
As I remember, the performance improvement from this optimization was
very small. There were problems in reviewing IRA and I decided to
simplify this task.
May be it is wor
Sorry for the recent loop-doloop.c breakage. I did test it, but I didn't take
a day to re-test it the two hundred configurations in config-list.mk and
sift out the pre-broken ports; as i had only changed 'target-independent'
code since the last full test, I only tested in on i686-pc-linux-gnu.
Wh
Steven Bosscher writes:
>
> I suppose it's theoretically possible to make a good initial guess of
> what registers might be not-clobbered by a function even if the ABI
> says so. For instance, perhaps it's possible to assume that a function
> that doesn't touch any variables in a floating point mo
Thanks for the quick answer.
> That's just the way it works, so I suppose you could call it a feature.
So the answer to (1) is yes and to (2) it is a poorly documented feature.
May be the restriction to one dg-do directive should be added to
http://gcc.gnu.org/wiki/HowToPrepareATestcase .
In gcc
On Tue, Oct 16, 2012 at 7:20 PM, Andi Kleen wrote:
> Vladimir Makarov writes:
>>>
>> As I remember, the performance improvement from this optimization was
>> very small. There were problems in reviewing IRA and I decided to
>> simplify this task.
>>
>> May be it is worth to return to this work.
>
Vladimir Makarov writes:
>>
> As I remember, the performance improvement from this optimization was
> very small. There were problems in reviewing IRA and I decided to
> simplify this task.
>
> May be it is worth to return to this work.
... especially if you could make it work with LTO.
-Andi
On 10/16/2012 07:14 AM, Andreas Schwab wrote:
> domi...@lps.ens.fr (Dominique Dhumieres) writes:
>
>> These questions are motivated by the comments #4 to #15 of pr54407.
>>
>> The bottom line is that
>>
>> { dg-do compile targets1 }
>> { dg-do run targets2 }
>>
>> behaves as
>>
>> {dg-do run { tar
Hello Everyone,
I am trying to debug the trunk cc1 (revision 192483) and it is not
finding the line number information. I am using GDB 7.5. My OS is SuSE (not
sure if that matters). Is everyone else having this issue?
Thanks,
Balaji V. Iyer.
domi...@lps.ens.fr (Dominique Dhumieres) writes:
> These questions are motivated by the comments #4 to #15 of pr54407.
>
> The bottom line is that
>
> { dg-do compile targets1 }
> { dg-do run targets2 }
>
> behaves as
>
> {dg-do run { targets1 targets2 } }
>
> while
>
> { dg-do run targets1 }
> {
On Tue, Oct 16, 2012 at 3:41 PM, Martin Jambor wrote:
> Hi,
>
> On Tue, Oct 16, 2012 at 01:21:29AM -0700, Sharad Singhai wrote:
>> Hi,
>>
>> This is a solicitation for help in converting passes to use the new
>> dump infrastructure. More context below.
>
> thanks for the email. I hoped you'd summ
Hi,
On Tue, Oct 16, 2012 at 01:21:29AM -0700, Sharad Singhai wrote:
> Hi,
>
> This is a solicitation for help in converting passes to use the new
> dump infrastructure. More context below.
thanks for the email. I hoped you'd summarize what the long thread
about this (that I lost track of) led t
These questions are motivated by the comments #4 to #15 of pr54407.
The bottom line is that
{ dg-do compile targets1 }
{ dg-do run targets2 }
behaves as
{dg-do run { targets1 targets2 } }
while
{ dg-do run targets1 }
{ dg-do compile targets2 }
as
{ dg-do compile { targets1 targets2 } }
(1)
On Tue, Oct 16, 2012 at 10:15 AM, Sharad Singhai wrote:
> Hi,
>
> I added -fopt-info option in r191883. This option allows one to
> quickly see high-level optimization info instead of scanning several
> verbose dump files.
>
> However, -fopt-info implementation is not complete as it dumps
> info f
On 10/15/2012 07:14 PM, Ахриев Альберт wrote:
Two-three generations ago g++ was very cautious about consistency checking but
not now.
Not sure if this is true. The at() member function performs such
checking, but not operator[].
We looked at bounds checking for operator[] under -D_FORTIFY
Hi,
This is a solicitation for help in converting passes to use the new
dump infrastructure. More context below.
I have enhanced the dump infrastructure in r191883, r191884. These
patches updated the tree/rtl dump facility so that passes do not
reference the dump file directly, but instead use a
Hi,
I added -fopt-info option in r191883. This option allows one to
quickly see high-level optimization info instead of scanning several
verbose dump files.
However, -fopt-info implementation is not complete as it dumps
info from all the passes. It would be nice to add high level
pass-level filte
Hi,
Who will be fixing this? Macro arguments without brackets are not
accepted by the assembler.
If I can be of any help, let me know.
Thanks,
Mischa.
.intel_syntax noprefix
.global function
.code64
.macro A a
Hi,
Who will be fixing this? Macro arguments without brackets are not
accepted by the assembler.
If I can be of any help, let me know.
Thanks,
Mischa.
23 matches
Mail list logo
