Hi,
I recently read the articles about the selective scheduling
implementation and found it quite interesting, I especially liked the
idea of how neatly software pipelining is integrated. The target I am
working on is a VLIW DSP so obviously these things are very important
for good code generation
Steve Ellcey writes:
> I do get this test to pass. But other systems are using 'byte' so of
> course I need to allow for either byte or data1. I have tried:
>
> /* { dg-final { scan-assembler-times "(byte|data1).*?0x3.*? DW_AT_inline" 3 }
> } */
>
> /* { dg-final { scan-assembler-times "(byte\
Hi,
On Tue, 27 Oct 2009, Markus L wrote:
Hi,
I recently read the articles about the selective scheduling
implementation and found it quite interesting, I especially liked the
idea of how neatly software pipelining is integrated. The target I am
working on is a VLIW DSP so obviously these thing
This means that if your GCC source tree resides in a directory, say,
~/gcc-src
you should *not* run ./configure while in ~/gcc-src. Instead, you
should create a second, empty directory
~/gcc-build
(which is not a subdirectory of ~/gcc-src), and run
../gcc-src/configure ...
while in ~/gcc-build
Hello All,
I feel that the current plugin hooks, that is the set of plugin events
enumerated in the enum plugin_event of gcc/gcc-plugin.h and the
associated API in gcc/plugin.h (e.g. register_attribute) is perhaps
still incomplete.
My feeling is that adding plugin events (at least those for
On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
wrote:
> Hello All,
>
> I feel that the current plugin hooks, that is the set of plugin events
> enumerated in the enum plugin_event of gcc/gcc-plugin.h and the associated
> API in gcc/plugin.h (e.g. register_attribute) is perhaps still incompl
Richard Guenther wrote:
On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
Adding hooks just because you think they might be useful
isn't the way to go.
Then what is the correct way to enhance the current plugin API. There
are a lot of stuff missing there.
I am not at all sure that all t
Basile STARYNKEVITCH writes:
> Richard Guenther wrote:
>> On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
>>
>> Adding hooks just because you think they might be useful
>> isn't the way to go.
>
> Then what is the correct way to enhance the current plugin API. There
> are a lot of stuff mis
Hello All,
Richard Guenther wrote:
Adding hooks just because you think they might be useful
isn't the way to go.
Basile STARYNKEVITCH writes:
Then what is the correct way to enhance the current plugin API. There
are a lot of stuff missing there.
Ian Lance Taylor wrote:
We should add
Basile STARYNKEVITCH writes:
> Ian Lance Taylor wrote:
>> We should add hooks as we find plugins that need them. Simply adding
>> a laundry list of hooks that we think might be needed will most likely
>> cause us to overdesign. We know that we can write interesting plugins
>> today, so we're no
Ian Lance Taylor wrote:
Basile STARYNKEVITCH writes:
* propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
Do this.
Will do probably tommorow or this evening!
On the other hand, skimming your list of hooks, I really question the
need for, e.g., REPLACE_PASS_MANAGER. I wo
Ian Lance Taylor wrote:
For something like PLUGIN_ADD_CPP_MACROS, the need is clear, but I
think it's an open question we should add a hook or whether the plugin
should just call cpp_define. A hook means that we promise to always
have a way to do this in case cpp_define changes. How do we deci
Charles Wilson cwilson.fastmail.fm> writes:
> > If cygwin wants to be POSIX compatible then the C locale cannot use
> > UTF-8.
Not true. POSIX has no restrictions against the C locale not being a multi-
byte charset.
>
> "The tables in Locale Definition describe the characteristics and
> beha
On Tue, Oct 27, 2009 at 4:06 PM, Basile STARYNKEVITCH
wrote:
> Ian Lance Taylor wrote:
>>
>> Basile STARYNKEVITCH writes:
>>
>>> * propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
>>
>> Do this.
>
> Will do probably tommorow or this evening!
>>
>> On the other hand, skimming yo
Richard Guenther wrote:
The fix is not to add a hook to replace the pass manager but instead
to make the GCC pass manager more flexible itself.
I leave that task to my ICI friends (in CC). They have already an
implementation, and I believe they probably did propose some patches, or
are worki
On Tue, 27 Oct 2009, Basile STARYNKEVITCH wrote:
> I (Basile) don't know much of libcpp. If a plugin can just call cpp_define,
> this is ok for me. But then, we perhaps should document how can that be
> called, and when (at plugin initialization, at PLUGIN_START_UNIT? I don't
> know!)
A plugin ca
On Tue, Oct 27, 2009 at 4:48 PM, Basile STARYNKEVITCH
wrote:
> Richard Guenther wrote:
>>
>> The fix is not to add a hook to replace the pass manager but instead
>> to make the GCC pass manager more flexible itself.
>
> I leave that task to my ICI friends (in CC). They have already an
> implementa
> I agree with H-P.
The attached patch implements that. Tested that it is ignored by cc1
and not passed to the linker. OK with a CL entry if bootstrap finishes
OK?
> --
> Daniel Jacobowitz
> CodeSourcery
>
Cheers,
--
Rafael Ávila de Espíndola
diff --git a/gcc/common.opt b/gcc/common.opt
index b
Rafael Espindola writes:
> diff --git a/gcc/common.opt b/gcc/common.opt
> index b57234a..9e4cf12 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -1391,6 +1391,11 @@ funwind-tables
> Common Report Var(flag_unwind_tables) Optimization
> Just generate unwind tables for exception handling
On Tue, 2009-10-27 at 02:09 -0400, Kaveh R. GHAZI wrote:
> On Mon, 26 Oct 2009, Steve Ellcey wrote:
>
> > I have tried:
> > /* { dg-final { scan-assembler-times "(byte|data1).*?0x3.*? DW_AT_inline" 3
> > } } */
> > /* { dg-final { scan-assembler-times "(byte\|data1).*?0x3.*? DW_AT_inline"
> > 3
Andreas Schwab writes:
> Rafael Espindola writes:
>
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index b57234a..9e4cf12 100644
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -1391,6 +1391,11 @@ funwind-tables
>> Common Report Var(flag_unwind_tables) Optimization
>> Just generate u
The regexp should not use .* in the first place, because "." also
matches the newline, and you need to use the non-capturing variant of
the grouping operator.
$ tclsh
% set fd [open "~/src/gcc/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/inline2.s" r]
file3
% set text [read $fd]
[...]
% regexp -inline -a
So it looks like the problem isn't in the pattern matching, it is in the
counting.
If I use this:
/* { dg-final { scan-assembler-times "data1.*?0x3.*? DW_AT_inline" 3 } } */
Everything works. If I change it to:
/* { dg-final { scan-assembler-times "(data1|byte).*?0x3.*? DW_AT_inline" 3 }
}
> Perhaps this should be an Undocumented option. I don't think you need a
> Var anyway.
Without the Var it fails with
cc1: internal compiler error: in common_handle_option, at opts.c:2108
The attached patch changes the option to Undocumented.
> Andreas.
>
Cheers,
--
Rafael Ávila de Espíndola
On Tue, 2009-10-27 at 17:59 +0100, Andreas Schwab wrote:
> The regexp should not use .* in the first place, because "." also
> matches the newline, and you need to use the non-capturing variant of
> the grouping operator.
I am not sure what the non-capturing variant of the grouping operator
is. I
> Without the Var it fails with
>
> cc1: internal compiler error: in common_handle_option, at opts.c:2108
Which can also be fixed by explicitly ignoring
OPT_fuse_linker_plugin. The attached patch does that. Any preferences?
Cheers,
--
Rafael Ávila de Espíndola
diff --git a/gcc/common.opt b/gcc/c
Sent from my iPhone
On Oct 27, 2009, at 10:13 AM, Rafael Espindola
wrote:
Perhaps this should be an Undocumented option. I don't think you
need a
Var anyway.
Without the Var it fails with
cc1: internal compiler error: in common_handle_option, at opts.c:2108
Then what about adding
> Then what about adding to that switch statement that it is already handled
> by the specs?
That is what the last version does.
Cheers,
--
Rafael Ávila de Espíndola
Rafael Espindola writes:
> Which can also be fixed by explicitly ignoring
> OPT_fuse_linker_plugin. The attached patch does that. Any preferences?
This version is OK with a ChangeLog entry if it bootstraps. Since
there have been several comments, please give people 24 hours to
suggest changes.
Eric Blake wrote:
> The correct workaround is indeed to specify a locale with specific charset
> encodings, rather than relying on plain "C"
Yep, I'm testing a patch to that effect.
> (hopefully cygwin will support "C.ASCII", if it does not already).
Yep, it does.
> As far as I know, the
Steve Ellcey writes:
> I am not sure what the non-capturing variant of the grouping operator
> is. Is that the '?:' ?
Yes, see re_syntax(n).
> I have never seen that used in a scan-assembler anywhere else.
None of them use grouping in first place (except for a few by accident).
Andreas.
--
On Mon, Oct 26, 2009 at 09:40:06AM -0700, Andrew Pinski wrote:
> Except (b) is correct as fold should not be modifiying the tree at
> all. That is the whole point of fold_checksum_tree. We allow some
> things to change like TYPE_VARIANTs and such but we should not allow a
The TYPE_VARIANTs case
On Fri, Oct 23, 2009 at 09:58:55PM +0800, Zhang Lin wrote:
> Hello,
> I have encountered an issue when building ACE with MinGW and GCC 4.4.1
> The following macro was not accepted by the preprocessor and it reported such
> an error: "error: operator '==' has no left operand".
>
> #if !defined (AC
On Thu, Oct 22, 2009 at 12:14:31PM -0500, Pranav Bhandarkar wrote:
> > Are you talking about the tree dead-store elimination pass or
> > the RTL one? Basically *addr = value1; cannot be removed
> > if addr does not point to local memory or if the pointed-to
> > memory escapes through a call-site t
Snapshot gcc-4.4-20091027 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091027/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Eric Blake writes:
>The correct workaround is indeed to specify a locale with specific charset
>encodings, rather than relying on plain "C" (hopefully cygwin will
>support "C.ASCII", if it does not already).
The correct fix is for GCC not to intentionally choose to rely on
implementation defined
36 matches
Mail list logo
