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
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
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
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 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
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.
--
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
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.
> 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
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
> 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
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
> 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
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 }
}
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
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
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
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, 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
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
> 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
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, 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
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
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
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
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
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:
> 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
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
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
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
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
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
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,
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
36 matches
Mail list logo
