Joseph S. Myers wrote:
> To be clear, gettext tools are used in two ways in building new releases:
>
> * xgettext is run to update gcc.pot and cpplib.pot.
>
> * GCC is built with --enable-generated-files-in-srcdir, which uses msgfmt
> to create .gmo files and copy them into the source directory
On Wed, 21 Jun 2006, Bruno Haible wrote:
> Can you please proceed to step 2: ensure that the gettext-0.14.6 tools
> are used for building gcc-4.1.2 and newer?
To be clear, gettext tools are used in two ways in building new releases:
* xgettext is run to update gcc.pot and cpplib.pot.
* GCC is b
Hi,
In gcc 4.1.0 the syntax of gcc-internal format strings - as defined in
pretty-print.c - has been extended to support reordering of arguments
(through the %n$ syntax). Now the Swedish translator of gcc.pot would
like to make use of this feature, but the infrastructure is not yet in
place. Curre
Janis Johnson wrote:
> Support in GCC 4.2 for decimal floating types is based on drafts of
> ISO/IEC WDTR 23732, which continues to change. There are some
> differences between the most recent draft N1176 and what GCC implements,
> and some other things that should probably change or at least be
>
Hi ,
I have compiled binutils successfully with the target i686-unknown-winnt.
But the make for gcc fails. It says target not supported. I think i
can workaround it using i686-unknown-mingw32.
Few questions
1) Is it a known feature or a bug or something that i am doing wrong ?
2) Do we have som
Hi,
On Wed, 7 Jun 2006, Daniel Jacobowitz wrote:
> On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
> > And string does not answer localization issue, however for numbers at least
> > there is one precedent to follow.
>
> I think this discussion has gotten totally sidetracked. When
On 20 Jun 2006 09:10:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > Should I file a bug report?
>
> Yes, please. Thanks.
Done. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126
---
Atsushi Nemoto
Diego Novillo wrote:
> Eric Botcazou wrote on 06/21/06 10:05:
>
>> It seems to me that the volatility should be accounted for in the
>> VALUE_HANDLE
>> itself only, not in (de)references to it.
>>
> As Richard and Andrew pointed out, the bug is that we try to compute the
> value number of a stat
Eric Botcazou wrote on 06/21/06 10:05:
> It seems to me that the volatility should be accounted for in the
> VALUE_HANDLE
> itself only, not in (de)references to it.
>
As Richard and Andrew pointed out, the bug is that we try to compute the
value number of a statement with volatile references i
> What do you mean by "in the VALUE_HANDLE itself"?
Returning a different VALUE_HANDLE for each instance of a volatile expression.
> I think we should not bother value-numbering volatile mem-accesses at all.
I guess that would be even better. :-)
Thanks for the quick feedback.
--
Eric Botcazo
On Jun 21, 2006, at 7:05 AM, Eric Botcazou wrote:
Hi,
We're experiencing a memory explosion during PRE on several ACATS
tests with
mainline (+1 local patch, but it's very likely the same issue as PR
27937).
The VN should not have been created and stmt_ann (stmt)-
>has_volatile_ops shoul
On 6/21/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
Hi,
We're experiencing a memory explosion during PRE on several ACATS tests with
mainline (+1 local patch, but it's very likely the same issue as PR 27937).
Excerpt from .067t.pre:
Created value VH.26 for (struct cd5012i__genproc__cell *vola
Hi,
We're experiencing a memory explosion during PRE on several ACATS tests with
mainline (+1 local patch, but it's very likely the same issue as PR 27937).
Excerpt from .067t.pre:
Created value VH.26 for (struct cd5012i__genproc__cell *volatile & {ref-all})
VH.25
Created value VH.33 for *VH.2
13 matches
Mail list logo
