Re: question on bitmap_set_subtract unction in pre
On Sun, Feb 5, 2012 at 10:56 AM, Amker.Cheng wrote:
> Hi,
> In PRE, function compute_antic_aux uses bitmap_set_subtract to compute
> value/expression set subtraction.
>
> The comment of bitmap_set_subtract says it subtracts all the values
> and expressions contained in ORIG from DEST.
>
> But the implementation as following
> ---
> static bitmap_set_t
> bitmap_set_subtract (bitmap_set_t dest, bitmap_set_t orig)
> {
> bitmap_set_t result = bitmap_set_new ();
> bitmap_iterator bi;
> unsigned int i;
>
> bitmap_and_compl (&result->expressions, &dest->expressions,
> &orig->expressions);
>
> FOR_EACH_EXPR_ID_IN_SET (result, i, bi)
> {
> pre_expr expr = expression_for_id (i);
> unsigned int value_id = get_expr_value_id (expr);
> bitmap_set_bit (&result->values, value_id);
> }
>
> return result;
> }
>
> Does it just subtract the expressions, rather than values. And It
> resets values according to the resulting expression.
>
> I am a little confused here. Any explanation?
It's probably to have the SET in some canonical form - the resulting
values are simply re-computed from the expression subtraction
(multiple expressions may have the same value, so in
{ a, b } { 0 } - { a } { 0 } you need to either compute { } { } or { b } { 0 }
neither which you can reach by simply subtracting both bitmaps.
The function should probably be named bitmap_set_subtract_expressions
though, complement to bitmap_set_subtract_values.
Richard.
> Thanks very much.
> --
> Best Regards.
Re: weird optimization in sin+cos, x86 backend
On Sat, Feb 4, 2012 at 11:20 AM, James Courtier-Dutton
wrote:
> On 4 February 2012 00:06, Vincent Lefevre wrote:
>> On 2012-02-03 17:40:05 +0100, Dominique Dhumieres wrote:
>>> While I fail to see how the "correct value" of
>>> cos(4.47460300787e+182)+sin(4.47460300787e+182)
>>> can be defined in the 'double' world, cos^2(x)+sin^2(x)=1 and
>>> sin(2*x)=2*sin(x)*cos(x) seems to be verified (at least for this value)
>>> even if the actual values of sin and cos depends on the optimisation level.
>>
>> Actually this depends on the context. It is even worse: the value
>> of sin(some_value) depends on the context. Consider the following
>> program:
>>
>> #include
>> #include
>>
>> int main (void)
>> {
>> double x, c, s;
>> volatile double v;
>>
>> x = 1.0e22;
>> s = sin (x);
>> printf ("sin(%.17g) = %.17g\n", x, s);
>>
>> v = x;
>> x = v;
>> c = cos (x);
>> s = sin (x);
>> printf ("sin(%.17g) = %.17g\n", x, s);
>>
>> return c == 0;
>> }
>>
>> With "gcc -O" on x86_64 with glibc 2.13, one gets:
>>
>> sin(1e+22) = -0.85220084976718879
>> sin(1e+22) = 0.46261304076460175
>>
>> In the program, you can replace 1.0e22 by 4.47460300787e+182 or
>> whatever large constant you want. You'll get the same problem.
>>
>
> Ok, so the value -0.85... seems to be the correct value.
>
> If you convert all the doubles into long doubles.
> You get:
> gcc -O0 -c -o sincos.o sincos.c
> gcc sincos.o -lm
> sinl(100.0) = 0.46261304076460176
> sinl(100.0) = 0.46261304076460176
> gcc sincos.o -lm
> gcc -O2 -c -o sincos.o sincos.c
> sin(100.0) = -0.85220084976718880
> sin(100.0) = 0.46261304076460176
>
> So, I agree with Vincent Lefevre, my earlier statements are wrong.
> There is definitely something going wrong either in gcc or libm.
Note that you are comparing a constant folded sin() result against sincos()
(or sin() and cos()). Use
#include
#include
int main (void)
{
double x, c, s;
volatile double v;
x = 1.0e22;
v = x;
x = v;
s = sin (x);
printf ("sin(%.17g) = %.17g\n", x, s);
v = x;
x = v;
c = cos (x);
s = sin (x);
printf ("sin(%.17g) = %.17g\n", x, s);
return c == 0;
}
to compare libm sin against sincos. Works for me, btw. Note that I remember
that at some point sincos() was just fsincos even on x86_64 (ugh).
Richard.
Re: weird optimization in sin+cos, x86 backend
On 2012-02-06 12:54:09 +0100, Richard Guenther wrote:
> Note that you are comparing a constant folded sin() result against
> sincos() (or sin() and cos()). Use
>
> #include
> #include
>
> int main (void)
> {
> double x, c, s;
> volatile double v;
>
> x = 1.0e22;
> v = x;
> x = v;
> s = sin (x);
> printf ("sin(%.17g) = %.17g\n", x, s);
>
> v = x;
> x = v;
> c = cos (x);
> s = sin (x);
> printf ("sin(%.17g) = %.17g\n", x, s);
>
> return c == 0;
> }
>
> to compare libm sin against sincos. Works for me, btw. Note that I remember
> that at some point sincos() was just fsincos even on x86_64 (ugh).
This is unfortunately still true under Debian/unstable, which has
glibc 2.13, and that's why I get (with -O, so that glibc's sincos
is used):
sin(1e+22) = -0.85220084976718879
sin(1e+22) = 0.46261304076460175
What do you mean by "Works for me"? i.e. you get the same value or
you can reproduce the bug? If the former, has this changed in later
glibc versions or has glibc been built with some specific option on
your machine?
--
Vincent Lefèvre - Web:
Re: weird optimization in sin+cos, x86 backend
On Mon, Feb 6, 2012 at 1:29 PM, Vincent Lefevre wrote:
> On 2012-02-06 12:54:09 +0100, Richard Guenther wrote:
>> Note that you are comparing a constant folded sin() result against
>> sincos() (or sin() and cos()). Use
>>
>> #include
>> #include
>>
>> int main (void)
>> {
>> double x, c, s;
>> volatile double v;
>>
>> x = 1.0e22;
>> v = x;
>> x = v;
>> s = sin (x);
>> printf ("sin(%.17g) = %.17g\n", x, s);
>>
>> v = x;
>> x = v;
>> c = cos (x);
>> s = sin (x);
>> printf ("sin(%.17g) = %.17g\n", x, s);
>>
>> return c == 0;
>> }
>>
>> to compare libm sin against sincos. Works for me, btw. Note that I remember
>> that at some point sincos() was just fsincos even on x86_64 (ugh).
>
> This is unfortunately still true under Debian/unstable, which has
> glibc 2.13, and that's why I get (with -O, so that glibc's sincos
> is used):
>
> sin(1e+22) = -0.85220084976718879
> sin(1e+22) = 0.46261304076460175
>
> What do you mean by "Works for me"? i.e. you get the same value or
> you can reproduce the bug? If the former, has this changed in later
> glibc versions or has glibc been built with some specific option on
> your machine?
glibc for openSUSE or SLE carries patches to replace all x86_64 libm
routines and does not suffer from the above problem. Note that the
issue in glibc is that sin/cos use a software implementation while sincos
uses the hardware fsincos. sinl/cosl use hardware fsin/fcos, similar to
sincosl so those should be not prone to the error (and sinf/cosf/sincosf
consistently use a software implementation).
Richard.
Re: Memory corruption due to word sharing
On Fri, 2012-02-03 at 12:00 -0800, Linus Torvalds wrote:
> Of course, it you expose some intrinsic for the whole "ll/sc" model
> (and you then turn it into cmpxchg on demand), we could literally
> open-code it.
>
> That is likely the most *flexible* approach for a compiler. I think
> pretty much everything the kernel needs (except for cmpxchg_double)
> can be very naturally written as a "ll/sc" sequence, and if the
> compiler then just does the right thing with peephole optimizations,
> that's fine.
>
> IOW, we don't really need "atomic_add()" or anything like that. If we can do
>
> do {
> val = __load_linked(mem);
> val++;
> } while (__store_conditional(val, mem));
>
> and the compiler just automagically turns that into "lock add" on x86,
> that's perfectly fine.
>
> It might not be too hard, because you really don't need to recognize
> very many patterns, and any pattern you don't recognize could be
> turned into a cmpxchg loop.
>
> NOTE NOTE NOTE! The "turned into a cmpxchg loop" is not the true
> correct translation of load-linked/store-conditional, since it allows
> the memory to be modified as long as it's modified *back* before the
> store-conditional, and that actually matters for a few algorithms. But
> if you document the fact that it's not a "true" ll/sc (and maybe have
> some compile-time way to detect when it isn't), it would be very
> flexible.
>
> Of course, the syntax could be something completely different. Maybe
> you'd want to do it as
>
>__builtin_ll_sc(&var, update-expression, return-expression,
> failure-expression)
>
> rather than an explicit loop.
>
> But it doesn't sound like the internal gcc model is based on some
> generic ll/sc model.
No, and I don't think it's beneficial overall to do this. Sure, an
LL/SC or CAS loop is universal, but in turn programmers would have to
make sure that they hit the patterns that the compiler can actually
recognize and turn into the more efficient forms.
The custom atomic operations also provide different progress guarantees.
While a single CAS/cmpxchg is wait-free, the full loop isn't
necessarily. Same for the bit operations. So, I think it makes sense
to offer them separately. The split between weak- and strong-progress
compare-and-exchange in C++11 is related.
> I realize that people have bad memories of the x86 bit instructions,
> but especially in their locked form, the fact that they take a few
> extra cycles or decode in only one pipeline etc is *not* relevant.
> They are small and "fast", because the true cost tends to be not the
> instruction cost, but the locking overhead and the cache effects.
And the semantics of the operation is known immediately (without trying
to recover the actual atomic op from some surrounding cmpxchg loop).
That allows potential optimizations like combining (but I'm not a HW
expert, so I don't know whether HW actually does this internally).
Torvald
diff file for da.po
I have attached a diff-file for the Danish gettext translation file. I
have not sent in a copyright form for gcc (I have previously submitted
one for the auctex project). If this is needed (I consider it a small
contribution), please let me know.
--
Med Venlig Hilsen / Kind Regards,
Mads Jensen
Rubinsteinsvej 31,st.th
DK-2450 Kbh. SV
Denmark
+45 6168 8518
"hippopotomonstrosesquipedaliophobia": fear of long words ...
--- da.po 2012-02-06 18:36:16.0 +0100
+++ da.po2 2012-02-06 19:11:42.0 +0100
@@ -202,7 +202,7 @@
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<)%>"
-msgstr "';' forventet"
+msgstr "forventet %<)%>"
#: c-parser.c:3095 c-parser.c:3904 c-parser.c:3938 c-parser.c:5224
#: c-parser.c:6491 c-parser.c:6755 c-parser.c:6861 c-parser.c:10623
@@ -210,24 +210,24 @@
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<]%>"
-msgstr "';' forventet"
+msgstr "forventet %<]%>""
#: c-parser.c:3271
msgid "expected %<;%>, %<,%> or %<)%>"
-msgstr ""
+msgstr "forventet &<;%>, %<,%> eller %<)%>"
#: c-parser.c:3767 c-parser.c:9771 cp/parser.c:22204 cp/parser.c:24021
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<}%>"
-msgstr "';' forventet"
+msgstr "forventet %<}%>"""
#: c-parser.c:4057 c-parser.c:7931 c-parser.c:10217 c-parser.c:2318
#: c-parser.c:2521 c-parser.c:7485 cp/parser.c:14416 cp/parser.c:22207
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<{%>"
-msgstr "';' forventet"
+msgstr "forventet %<{%>"
#: c-parser.c:4276 c-parser.c:4285 c-parser.c:5128 c-parser.c:5469
#: c-parser.c:7696 c-parser.c:8071 c-parser.c:8128 c-parser.c:9143
@@ -235,18 +235,18 @@
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<:%>"
-msgstr "';' forventet"
+msgstr "forventet ';'"
#: c-parser.c:4824 cp/parser.c:22134
#, gcc-internal-format
msgid "expected %"
-msgstr ""
+msgstr "forventet %"
#: c-parser.c:6279
#, fuzzy
#| msgid "';' expected"
msgid "expected %<.%>"
-msgstr "';' forventet"
+msgstr "forventet %<.%>"
#: c-parser.c:7156 c-parser.c:7188 c-parser.c:7428 cp/parser.c:23805
#: cp/parser.c:23879
@@ -259,12 +259,12 @@
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<>%>"
-msgstr "';' forventet"
+msgstr "forventet %<>%>"
#: c-parser.c:9241 cp/parser.c:22249
#, gcc-internal-format
msgid "expected %<,%> or %<)%>"
-msgstr ""
+msgstr "forventet %<,%> eller %<)%>"
#: c-parser.c:9494 c-parser.c:9525 c-parser.c:9761 c-parser.c:9913
#: c-parser.c:3961 cp/parser.c:8
@@ -276,7 +276,7 @@
#: c-parser.c:10274 c-parser.c:10264 cp/parser.c:26658
#, gcc-internal-format
msgid "expected %<#pragma omp section%> or %<}%>"
-msgstr ""
+msgstr "forventet %<#pragma omp section%> eller %<}%>"
#: c-parser.c:10611 cp/parser.c:22213
#, fuzzy, gcc-internal-format
@@ -1442,7 +1442,7 @@
#: lto-wrapper.c:247
#, c-format
msgid "deleting LTRANS file %s"
-msgstr ""
+msgstr "sletter LTRANS fil %s"
#: lto-wrapper.c:269
#, fuzzy, c-format
@@ -1486,11 +1486,11 @@
#: opts.c:1028
msgid "[default]"
-msgstr ""
+msgstr "[default]"
#: opts.c:1039
msgid "[enabled]"
-msgstr ""
+msgstr "[slået til]"
#: opts.c:1039
#, fuzzy
@@ -1501,7 +1501,7 @@
#: opts.c:1058
#, c-format
msgid " No options with the desired characteristics were found\n"
-msgstr ""
+msgstr "Ingen options med den efterspurgte karaktistik blev fundet\n"
#: opts.c:1067
#, c-format
@@ -1616,7 +1616,7 @@
#: reload1.c:8653
msgid "failure trying to reload:"
-msgstr ""
+msgstr "fejl ved forsøg på at genindlæse:"
#: rtl-error.c:118
msgid "unrecognizable insn:"
@@ -1768,12 +1768,12 @@
#: cif-code.def:67
msgid "--param inline-unit-growth limit reached"
-msgstr ""
+msgstr "--param inline-unit-growth grænse nået"
#. Recursive inlining.
#: cif-code.def:70
msgid "recursive inlining"
-msgstr ""
+msgstr "rekursiv inlining"
#. Call is unlikely.
#: cif-code.def:73
@@ -2324,11 +2324,11 @@
#: params.def:631
msgid "Minimal distance between possibly conflicting store and load"
-msgstr ""
+msgstr "Minimal afstand mellem modstridende store og load"
#: params.def:636
msgid "The maximum number of RTL nodes that can be recorded as combiner's last value"
-msgstr ""
+msgstr "Det maksimale antal af RTL noder der kan "
#: params.def:644
#, fuzzy
@@ -3669,7 +3669,7 @@
#, fuzzy, c-format
#| msgid "pointer"
msgid "null pointer"
-msgstr "henvisning"
+msgstr "nul-henvisning"
#: config/microblaze/microblaze.c:1778
#, fuzzy, c-format
@@ -3714,7 +3714,7 @@
#: config/mips/mips.c:7964
msgid "mips_debugger_offset called with non stack/frame/arg pointer"
-msgstr ""
+msgstr "mips_debugger_offset blev ikke kaldt med en stack/frame/arg pointer"
#: config/mmix/mmix.c:1611 config/mmix/mmix.c:1741
msgid "MMIX Internal: Expected a CONST_INT, not this"
@@ -3984,7 +3984,7 @@
#: config/s390/s390.c:5338
#, c-format
msgid "register or memory expression expected for 'M' output
ANN: gcc-python-plugin 0.9
gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the CPython interpreter within GCC, allowing you to write new compiler warnings in Python, generate code visualizations, etc. It ships with "gcc-with-cpychecker", which implements static analysis passes for GCC aimed at finding bugs in CPython extensions. In particular, it can automatically detect reference-counting errors: http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html This release (0.9) is mostly about internal fixes: * support for gcc 4.7 prereleases * the plugin is now properly integrated with GCC's garbage collector, fixing segfaults that could happen when compiling large files (the Python wrapper objects no longer have their underlying GCC objects swept away from under them) * gcc-with-cpychecker's analysis logic has been reworked, fixing numerous bugs, and extending the scope of the checker enough to find 8 previously-missed memory-leak bugs when run upon itself. There are many other improvements. Detailed release notes can be seen at: http://gcc-python-plugin.readthedocs.org/en/latest/0.9.html Tarball releases are available at: https://fedorahosted.org/releases/g/c/gcc-python-plugin/ Prebuilt-documentation can be seen at: http://gcc-python-plugin.readthedocs.org/en/latest/index.html The project's homepage is: https://fedorahosted.org/gcc-python-plugin/ The plugin and checker are Free Software, licensed under the GPLv3 or later. Enjoy! Dave Malcolm
Fwd: [Announce] Google Summer of Code 2012
Google just announced GSoC 2012. If you are a GCC maintainer and would like to mentor a student in this year's program, please announce it to potential candidates and get in touch with me. As a mentoring organization, we (GCC) have to apply to the program between 27-Feb-2012 and 9-Mar-2012. We do not need to have all student applications ready by then, but we will need to have an idea of how many students we would be able to host. Thank you. Diego. Original Message Subject:[Announce] Google Summer of Code 2012 Date: Sat, 4 Feb 2012 10:53:57 -0800 From: Carol Smith To: Google Summer of Code Mentors List Hi GSoC mentors and org admins, We've announced that we're doing Google Summer of Code 2012 [1]. Yay! If you would like to help spread the word about GSoC, we have presentations [2], logos [3], and flyers [4] for you all to use this year. Please host meetups, tell your friends and colleagues about the program, go to conferences, talk to people about the program, and just generally do all the awesome word-of-mouth stuff you do every year to promote the program. We rely on you for your help, so thank you in advance for all the work you do! Please consider translating the presentations and/or flyers into your native language and submitting them directly to me to post on the wiki. Localization for our material is integral to reaching the widest possible audience around the world. Please remember to take pictures at your meetup and write up a blog post for our blog [4]. We love highlighting the GSoC community on our blog! Please also considering translating the flyer or the presentation (or both) into your native language and submitting it to me. The more languages our resources are in, the better. If you need goodies for a meetup you're holding in your area, please contact me directly and let me know. I'd be happy to send along some promotional items. Please let me know when you decide on a date, time, and location for a meetup so I can put it on the calendar. The GSoC calendar has been updated with this year's dates, so please refer to that as well for important dates and deadlines. Please consider applying to participate as an organization again this year or maybe joining as a mentor for your favorite organization if they are selected this year. [1] - http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html [2] - http://code.google.com/p/google-summer-of-code/wiki/ProgramPresentations [3] - http://code.google.com/p/google-summer-of-code/wiki/GsocLogos [4] - http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers Cheers, Carol -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Mentors List" group. To post to this group, send email to google-summer-of-code-mentors-l...@googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-mentors-list+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en.
Re: libgcc maintainer
Zoltán Kócsi writes: > Who'd be the best person to contact regarding to libgcc for ARM 4T, 6M and 7M > targets? The "arm port" maintainers listed in the top-level MAINTAINERS file. Ian
Template Handling in G++
Hello Everyone, Can someone please tell me the entry point function (and stage) where the template functions are separated for different data types? Please CC me when responding to this message. Thanks, Balaji V. Iyer.
da.po.diff
I realized there were a few errors in the submitted patch, so I'm
resubmitting it.
--
Med Venlig Hilsen / Kind Regards,
Mads Jensen
Rubinsteinsvej 31,st.th
DK-2450 Kbh. SV
Denmark
+45 6168 8518
"hippopotomonstrosesquipedaliophobia": fear of long words ...
--- da.po 2012-02-06 18:36:16.0 +0100
+++ da.po2 2012-02-06 21:23:53.0 +0100
@@ -202,7 +202,7 @@
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<)%>"
-msgstr "';' forventet"
+msgstr "forventet %<)%>"
#: c-parser.c:3095 c-parser.c:3904 c-parser.c:3938 c-parser.c:5224
#: c-parser.c:6491 c-parser.c:6755 c-parser.c:6861 c-parser.c:10623
@@ -210,24 +210,24 @@
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<]%>"
-msgstr "';' forventet"
+msgstr "forventet %<]%>""
#: c-parser.c:3271
msgid "expected %<;%>, %<,%> or %<)%>"
-msgstr ""
+msgstr "forventet &<;%>, %<,%> eller %<)%>"
#: c-parser.c:3767 c-parser.c:9771 cp/parser.c:22204 cp/parser.c:24021
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<}%>"
-msgstr "';' forventet"
+msgstr "forventet %<}%>"""
#: c-parser.c:4057 c-parser.c:7931 c-parser.c:10217 c-parser.c:2318
#: c-parser.c:2521 c-parser.c:7485 cp/parser.c:14416 cp/parser.c:22207
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<{%>"
-msgstr "';' forventet"
+msgstr "forventet %<{%>"
#: c-parser.c:4276 c-parser.c:4285 c-parser.c:5128 c-parser.c:5469
#: c-parser.c:7696 c-parser.c:8071 c-parser.c:8128 c-parser.c:9143
@@ -235,18 +235,18 @@
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<:%>"
-msgstr "';' forventet"
+msgstr "forventet ';'"
#: c-parser.c:4824 cp/parser.c:22134
#, gcc-internal-format
msgid "expected %"
-msgstr ""
+msgstr "forventet %"
#: c-parser.c:6279
#, fuzzy
#| msgid "';' expected"
msgid "expected %<.%>"
-msgstr "';' forventet"
+msgstr "forventet %<.%>"
#: c-parser.c:7156 c-parser.c:7188 c-parser.c:7428 cp/parser.c:23805
#: cp/parser.c:23879
@@ -259,12 +259,12 @@
#, fuzzy, gcc-internal-format
#| msgid "';' expected"
msgid "expected %<>%>"
-msgstr "';' forventet"
+msgstr "forventet %<>%>"
#: c-parser.c:9241 cp/parser.c:22249
#, gcc-internal-format
msgid "expected %<,%> or %<)%>"
-msgstr ""
+msgstr "forventet %<,%> eller %<)%>"
#: c-parser.c:9494 c-parser.c:9525 c-parser.c:9761 c-parser.c:9913
#: c-parser.c:3961 cp/parser.c:8
@@ -276,7 +276,7 @@
#: c-parser.c:10274 c-parser.c:10264 cp/parser.c:26658
#, gcc-internal-format
msgid "expected %<#pragma omp section%> or %<}%>"
-msgstr ""
+msgstr "forventet %<#pragma omp section%> eller %<}%>"
#: c-parser.c:10611 cp/parser.c:22213
#, fuzzy, gcc-internal-format
@@ -1442,7 +1442,7 @@
#: lto-wrapper.c:247
#, c-format
msgid "deleting LTRANS file %s"
-msgstr ""
+msgstr "sletter LTRANS fil %s"
#: lto-wrapper.c:269
#, fuzzy, c-format
@@ -1486,11 +1486,11 @@
#: opts.c:1028
msgid "[default]"
-msgstr ""
+msgstr "[default]"
#: opts.c:1039
msgid "[enabled]"
-msgstr ""
+msgstr "[slået til]"
#: opts.c:1039
#, fuzzy
@@ -1501,7 +1501,7 @@
#: opts.c:1058
#, c-format
msgid " No options with the desired characteristics were found\n"
-msgstr ""
+msgstr "Ingen options med den efterspurgte karaktistik blev fundet\n"
#: opts.c:1067
#, c-format
@@ -1616,7 +1616,7 @@
#: reload1.c:8653
msgid "failure trying to reload:"
-msgstr ""
+msgstr "fejl ved forsøg på at genindlæse:"
#: rtl-error.c:118
msgid "unrecognizable insn:"
@@ -1768,12 +1768,12 @@
#: cif-code.def:67
msgid "--param inline-unit-growth limit reached"
-msgstr ""
+msgstr "--param inline-unit-growth grænse nået"
#. Recursive inlining.
#: cif-code.def:70
msgid "recursive inlining"
-msgstr ""
+msgstr "rekursiv inlining"
#. Call is unlikely.
#: cif-code.def:73
@@ -2324,11 +2324,11 @@
#: params.def:631
msgid "Minimal distance between possibly conflicting store and load"
-msgstr ""
+msgstr "Minimal afstand mellem modstridende store og load"
#: params.def:636
msgid "The maximum number of RTL nodes that can be recorded as combiner's last value"
-msgstr ""
+msgstr "Det maksimale antal af RTL noder der kan "
#: params.def:644
#, fuzzy
@@ -3669,7 +3669,7 @@
#, fuzzy, c-format
#| msgid "pointer"
msgid "null pointer"
-msgstr "henvisning"
+msgstr "nul-henvisning"
#: config/microblaze/microblaze.c:1778
#, fuzzy, c-format
@@ -3714,7 +3714,7 @@
#: config/mips/mips.c:7964
msgid "mips_debugger_offset called with non stack/frame/arg pointer"
-msgstr ""
+msgstr "mips_debugger_offset blev ikke kaldt med en stack/frame/arg pointer"
#: config/mmix/mmix.c:1611 config/mmix/mmix.c:1741
msgid "MMIX Internal: Expected a CONST_INT, not this"
@@ -3984,7 +3984,7 @@
#: config/s390/s390.c:5338
#, c-format
msgid "register or memory expression expected for 'M' output modifier"
-msgstr ""
+msgstr "register eller hukommelses-udtryk forventet for 'M' output modifikator"
#: config/s390/s390.c:5403
#, fuzzy, c-format
@@ -4327,7
RE: Size of enum
Okay, I am sorry for not knowing that there is an option to make enum types as short as possible. Anyway, I think it should be a default option. Do you agree?
Re: Size of enum
2012/2/6 Alexandre Almeida : > > Okay, I am sorry for not knowing that there is an option to make enum types > as short as possible. Anyway, I think it should be a default option. Do you > agree? No I don't agree because that would cause an ABI change. Note some targets (arm-eabi though not arm-linux-eabi) already enable it by default as it is required by the ABI. Thanks, Andrew Pinski
Re: diff file for da.po
On Mon, 6 Feb 2012, Mads Jensen wrote: > I have attached a diff-file for the Danish gettext translation file. I > have not sent in a copyright form for gcc (I have previously submitted > one for the auctex project). If this is needed (I consider it a small > contribution), please let me know. We update the translations exclusively from the Translation Project site. Thus, if the Danish translation team submits your changes to the TP, then they will be included in GCC. -- Joseph S. Myers jos...@codesourcery.com
[gccint-zh] GCC Internals Chinese Translation Project
Hello, We (gccint-zh contributors) started to translate GCC internals document into Chinese several years ago. The project has been put on svn (http://code.google.com/p/gccint-zh), which is based on GCC internals ".texi" files, and can be browsed online (http://www.hellogcc.org/gccint). So far, most of the contents have been translated, and the work is still in process. We are planning to merge the document from GCC trunk and update the translation regularly. I'm wondering whether an introduction of this project with a link can be put on GCC wiki, so that more people can know it and join us. Thanks. Regards, Mingjie
Re: [gccint-zh] GCC Internals Chinese Translation Project
2012/2/7 Mingjie Xing : > I'm wondering whether an introduction of this project with a link can > be put on GCC wiki, so that more people can know it and join us. > Thanks. Now, around 80% is translated. We are still translating the rest and periodically sync from official gcc tree. This project is quite useful to GCC hackers whose mother language is Chinese, even they can read English. Finally, it is beneficial to gcc community. I propose that 1) add a link on GCC wiki to http://www.hellogcc.org/gccint, 2) put our compiled gccint-zh htmls to gcc.gnu.org, and update it periodically. What do you think? Note that we translate gccint as a hobby in weekend, and will never use this Chinese version of gccint for any commercial purpose. Thanks, Mingjie
