<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel about="http://blog.gmane.org/gmane.comp.gcc.devel">
    <title>gmane.comp.gcc.devel</title>
    <link>http://blog.gmane.org/gmane.comp.gcc.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101669"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101666"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101665"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101664"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101663"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101658"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101648"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101644"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101643"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101635"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101634"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101629"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101626"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101622"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101604"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101602"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101600"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101599"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101586"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.gcc.devel/101583"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101669">
    <title>adding ability to scan few local variables in GGC?</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101669</link>
    <description>Hello All,

I am sometimes wishing to be able to scan some few local variables in 
GCC garbage collector, GGC.

One could imagine, for instance, that some passes would prefer, instead 
of using static GTY-ed variables, to declare some local GTY-ed structure 
LS , and to explicitly invoke the GGC collector with a pointer to LS and 
its marking routine (as generated by gengtype).

As a fictional example, suppose some pass is building a gimple_seq 
stored in a local gs. It could perhaps call the GGC garbage collector as
ggc_collect_with_local(gs, gt_ggc_mx_gimple_seq_node_d);


So I am suggesting that we could extend the API in gcc/ggc.h with an 
additional function ggc_collect_with_local which takes a pointer to a 
single local structure (inside the call stack) and a marking routine 
(usually generated by gengtype) for this pointer and do a collection 
with marking the additional stuff. We might restrict that the passed 
pointer is on the call stack (or on the contrary in the GGC heap).

what do people think a</description>
    <dc:creator>Basile STARYNKEVITCH</dc:creator>
    <dc:date>2008-10-12T20:15:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101666">
    <title>eamonn raymona deepak</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101666</link>
    <description>camille 
laura maryam 



</description>
    <dc:creator>bryce ramana</dc:creator>
    <dc:date>2008-10-12T15:23:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101665">
    <title>Can not use correct shared lib version.</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101665</link>
    <description>Hi,

I use cross-compiler to build my code in my PC Linux environment, and put the executable binary to another hardware board ( embedded Linux in this board).
I get the message said"error while loadingshard libraries: libdl.so.0: cannot open shared object file: No such file or directory ..."
I have add library path to environment, but I still encountered this error.
Actually, my Linux only has libdl.so.2 file, not have libdl.so.0. However, if I build this code with the gcc tool chain of my PC Linux, the executable binary can be exectued in PC.

Anything I need to do?

Many thanks!!

Chiyung Liao.



      ______________________________________________________________________________________________________
付費才容量無上限？Yahoo!奇摩電子信箱2.0免費給你，信件永遠不必刪！ http://tw.mg0.mail.yahoo.com/dc/landing

</description>
    <dc:creator>廖旂湧</dc:creator>
    <dc:date>2008-10-12T16:50:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101664">
    <title>Does GCC support  segmented memory ?</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101664</link>
    <description>I'm porting for a microcontroller which support
segment memory. But I don't know how to porting GCC so
that it can understand addresses in different memory
segment.
For example, I want to create seperate code segment
and data segment.

Is it possible in GCC ? and if the answer is "yes",
how can I do that ? 

Thank you very much.


      

</description>
    <dc:creator>Dong Phuong</dc:creator>
    <dc:date>2008-10-12T16:40:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101663">
    <title>For some class F, I can declare a variable of type F::F, or F::F::F,  etc.</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101663</link>
    <description>Hi,

We come across what seems to be a bug in gcc.  If a class F has a public 
zero argument constructor, then we can declare a variable of type F::F, 
F::F::F, etc.  For example, the following source file:

   // foo.cpp
   class F {};
   F::F::F::F::F f;

compiles with out errors in g++.  The result is as if  f  is declared with

   F f;

This is the case with the stock/latest GCC in Debian GNU/Linux x86_64 
(v.4.1.2) and in Cygwin (v.3.4.4).

Is this the intended behavior?

</description>
    <dc:creator>Weiqi Gao</dc:creator>
    <dc:date>2008-10-12T13:52:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101658">
    <title>question. type long long</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101658</link>
    <description>Good afternoon.
I need some help. As from what versions your compiler understand that 
"long long" is 64 bits ?

Best regards, Alexander

P.S. Sorry for my mistakes, I know English bad.

</description>
    <dc:creator>Александр Струняшев</dc:creator>
    <dc:date>2008-10-12T08:29:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101648">
    <title>dhiraj chi-yao jasho</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101648</link>
    <description>haibo 
eladio dave 



</description>
    <dc:creator>cal chen</dc:creator>
    <dc:date>2008-10-11T08:57:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101644">
    <title>gcc-4.4-20081010 is now available</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101644</link>
    <description>Snapshot gcc-4.4-20081010 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081010/
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/trunk revision 141048

You'll find:

gcc-4.4-20081010.tar.bz2              Complete GCC (includes all of below)

gcc-core-4.4-20081010.tar.bz2         C front end and core compiler

gcc-ada-4.4-20081010.tar.bz2          Ada front end and runtime

gcc-fortran-4.4-20081010.tar.bz2      Fortran front end and runtime

gcc-g++-4.4-20081010.tar.bz2          C++ front end and runtime

gcc-java-4.4-20081010.tar.bz2         Java front end and runtime

gcc-objc-4.4-20081010.tar.bz2         Objective-C front end and runtime

gcc-testsuite-4.4-20081010.tar.bz2    The GCC testsuite

Diffs from 4.4-20081003 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated an</description>
    <dc:creator>gccadmin&lt; at &gt;gcc.gnu.org</dc:creator>
    <dc:date>2008-10-11T00:08:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101643">
    <title>Branch created for transactional memory</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101643</link>
    <description>I've created

   svn://gcc.gnu.org/svn/gcc/branches/transactional-memory/

for the development of support for transactional memory within gcc.
This branch will track mainline gcc.  There are some folks that have
already been working on this project; their page is at

   http://www.hipeac.net/node/2419

So far, I've applied their patch (which is vs 4.3) against mainline,
fixed up *.rej, and committed the result.  I've not yet gone through
their patch to convert it to tuples, or anything else that would let
it compile.  That I'll begin doing next week.

Please mark anything related to this branch with [trans-mem].

Cheers,


r~

</description>
    <dc:creator>Richard Henderson</dc:creator>
    <dc:date>2008-10-11T00:30:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101635">
    <title>install path in libgcc Makefile.in</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101635</link>
    <description>Hi,

Another problem when cross building the native mips compiler.
I.e. build=x86, host=target=mipsel
I have done some search, but haven't found any related discussion.

The install path of libgcc contains gcc version.
Currently in libgcc/Makefile.in, gcc version is get like this:
  version := $(shell $(CC) -dumpversion)

This will lead to a problem that I have only experienced when cross building
the native compiler. The problem is that crtbegin.o/crtend.o/etc. will be
installed into old gcc's path, overwrite existing ones. New gcc will have no
crtbegin.o...

There is no problem when natively building native compiler.

I don't understand why the problem only happens when cross building native
compiler. I know I need to study how gcc is built. Just want make you aware of
this problem. And I have a suggestion to this problem.

I have observed that in other components, the version is get like this:
version := $(shell cat $(srcdir)/../gcc/BASE-VER)

So what about we do the same in libgcc/Makefile.in? 
Because t</description>
    <dc:creator>Zhang Le</dc:creator>
    <dc:date>2008-10-10T19:17:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101634">
    <title>Compiler error w/ templates and default argument value</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101634</link>
    <description>Hello All,

I've run into this:

----8&lt;----8&lt;----8&lt;----
template&lt;typename F, typename A&gt;
class B
{
protected:
 static const int i = 42;
};

template&lt;typename F, typename A&gt;
class D : protected B&lt;F, A&gt;
{
public:
 D(int n_ = B&lt;F, A&gt;::i); // line 12
};
----8&lt;----8&lt;----8&lt;----

gcc-4.1 and 4.3 give the same error message:

t.cpp:12: error: expected ‘,’ or ‘...’ before ‘&gt;’ token
t.cpp:12: error: wrong number of template arguments (1, should be 2)
t.cpp:2: error: provided for ‘template&lt;class F, class A&gt; class B’
t.cpp:12: error: default argument missing for parameter 2 of ‘D&lt;F, 
A&gt;::D(int, A)’

If I write D(int n_ = (B&lt;F, A&gt;::i) ), then it compiles. Imho it should 
compile w/o the extra parentheses. VC++ 2008 Express compiled it. Wanted 
to test gcc 4.4, too, but I wasn't able to compile the 20081003 snapshot 
(/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or 
directory). I have a debian lenny/amd64 system.

Regards, P
</description>
    <dc:creator>Peter A. Felvegi</dc:creator>
    <dc:date>2008-10-10T19:16:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101629">
    <title>[graphite] Cleanup of command line parameters</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101629</link>
    <description>Hi graphities,

graphite consists of four flags "-floop-block", "-floop-interchange",
"-floop-stripmine" and "-fgraphite".

If any of these flags is set, we enable the graphite pass and we search
for SCoPs.
For every SCoP we try to apply transformations specified with
"-floop-block", "-floop-interchange" or "-floop-stripmine". But only if
we could apply a transformation, we replace the SCoP with new code
generated from the GRAPHITE data structures. Otherwise we do not touch
the GIMPLE representation.
If we only specify "-fgraphite", we never generate code for any SCoP, as
we never tried any transformation. So just using "-fgraphite" is
useless.

What is missing is a way to make GRAPHITE always generate code, even if
we did not apply any transformation.

This has two benefits:
- We can check the overhead the GIMPLE -&gt; GRAPHITE -&gt; GIMPLE
transformation costs.
- Wider test coverage, as we are able to run the code generator for
every SCoP, not only the SCoPs, we are able to transform.


Now:
----

﻿-fgraphite:</description>
    <dc:creator>Tobias Grosser</dc:creator>
    <dc:date>2008-10-10T18:26:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101626">
    <title>gcc moving memory reference across call</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101626</link>
    <description>I have some broken code, compiled from Java source.

It looks like:

    D.843 = &amp;java.text.Collator.class$$;
    _Jv_InitClass (D.843);
    D.845 = &amp;_CD_java_text_Collator;

is being turned into:

    D.843 = &amp;java.text.Collator.class$$;
    D.845 = &amp;_CD_java_text_Collator;
    _Jv_InitClass (D.843);


i.e. the memory reference is moved to before the call to _Jv_InitClass.

To get to my question: I presume that loop2 is supposed to be able
to move loads across calls, but it can only do so if the memory is
unreachable from the callee.  But how does loop2 know if the memory is
reachable?  Is there a full data flow graph computed, or does it depend
one the scope of the memory decl?

Thanks,
Andrew.



in the loop2_invariant dump we have:

(call_insn 31 30 33 3 /home/aph/gcc/classpath-098-merge-branch/libjava/java/text/Collator.java:304 (call (mem:QI (symbol_ref:DI ("_Jv_InitClass") [flags 0x41] &lt;function_decl 0x7f3030515800 _Jv_InitClass&gt;) [0 S1 A8])
        (const_int 0 [0x0])) 646 {*call_0} (expr_list:REG_DE</description>
    <dc:creator>Andrew Haley</dc:creator>
    <dc:date>2008-10-10T17:55:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101622">
    <title>Copyright notices during assignment limbo</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101622</link>
    <description>For code that we have written, what should the copyright notices read
during the period where we have given the FSF a copyright assignemnt,
but they haven't yet acknowledged that it is on file?
Obviously when we wrote the code, we've put our own copyright notices on it
because we need to have a copyright in it before we can assign it to
someone else.  Eventually, for the code that we have assigned, they should be
changed to say Copyright FSF.
But at what point in time should the Copyright notices actually be changed?

</description>
    <dc:creator>Joern Rennecke</dc:creator>
    <dc:date>2008-10-10T16:43:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101604">
    <title>G.C.C. should support more Ciphers.</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101604</link>
    <description>Hello,

how to support UNICODE with G.C.C.?
How to support e.G. XML-FILE to translate "reserved Words" in G.C.C.?

Is the only possibility to support e.g. "Umlauts" in Source-Text a Pre-Translator for the G.C.C. Translator?


For Example:

1. C-Text in Unicode
2. Own Pre-Translator that gives "G.C.C-ready" Bookstabes with no "Umlauts" or other ciphers that are not supported by G.C.C..


How many ciphers do G.C.C. already support?
Why does G.C.C. does not more ciphers support?
Where is the technical challenge in supporting more ciphers?

Does a Pre-Translator, from e.G. Unicode to G.C.C.-Ciphers already exist? Where to get this Pre-Translator?

With friendly wishes,

R. Müller





09.10.08 11:31 
Hallo zurück,

vielen Dank für die Antworten.


Mit z.B. "UNICODE" Unterstützung könnte man ja nicht nur lokalisierte Sprachversionen anbieten, sondern auch eigene "mathematische Beschreibungssprachen".

Mit z.B. xml-Karteien, die die einzelnen reservierten Wörter eigens einstellen können, könnte man dann j</description>
    <dc:creator>Rüdiger Müller</dc:creator>
    <dc:date>2008-10-10T08:32:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101602">
    <title>gcc-4.3-20081009 is now available</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101602</link>
    <description>Snapshot gcc-4.3-20081009 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20081009/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 141011

You'll find:

gcc-4.3-20081009.tar.bz2              Complete GCC (includes all of below)

gcc-core-4.3-20081009.tar.bz2         C front end and core compiler

gcc-ada-4.3-20081009.tar.bz2          Ada front end and runtime

gcc-fortran-4.3-20081009.tar.bz2      Fortran front end and runtime

gcc-g++-4.3-20081009.tar.bz2          C++ front end and runtime

gcc-java-4.3-20081009.tar.bz2         Java front end and runtime

gcc-objc-4.3-20081009.tar.bz2         Objective-C front end and runtime

gcc-testsuite-4.3-20081009.tar.bz2    The GCC testsuite

Diffs from 4.3-20081002 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
</description>
    <dc:creator>gccadmin&lt; at &gt;gcc.gnu.org</dc:creator>
    <dc:date>2008-10-09T22:44:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101600">
    <title>IRA compile time on gcc-c-torture/compile/limits-fnargs.c</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101600</link>
    <description>
Is anyone else seeing a long compile time on
gcc-c-torture/compile/limits-fnargs.c with -O2 optimization?  limits-fnargs.c
contains a single call to a function with 10,000 arguments.

There is PR 31850 which talks about compile time on limits-fnargs.c,
but this was fixed (at least on IA64, if not for spu-elf) a while back
and this new time out problem only affects IA64 when -O2 or higher
optimization is used.

I tracked the time down to the main loop in coalesce_spill_loops
in ira-colors.c.  The main IRA pass calls reload which calls
ira_sort_regnos_for_alter_reg with n = 28977.  This in turn calls
coalesce_spill_slots with num = 10061.  It is in the main loop of
coalesce_spill_slots where I seem to spend a lot of time compiling
limits-fnargs.c.

Vladimir, is this something you are aware of?  Would you like me
to submit a Bugzilla report?

Steve Ellcey
sje&lt; at &gt;cup.hp.com

</description>
    <dc:creator>sje&lt; at &gt;cup.hp.com</dc:creator>
    <dc:date>2008-10-09T21:12:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101599">
    <title>divmodsi4</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101599</link>
    <description>Hi All,
 I am having trouble distinguishing div vs mod while implementing the
divmodsi4 instruction. The gccint documentation states:
"If an instruction that just produces a quotient or just a remainder
exists and is more efficient than the instruction that produces both,
write the output routine of 'divmodm4' to call find_reg_note and look
for a REG_UNUSED note on the quotient or remainder and generate the
appropriate instruction."

 The problem is that both, the quotient and reminder, registers are
getting marked with a REG_UNUSED note:

 (insn 12 11 17 (parallel [
            (set (reg:SI 1 %r3 [33])
                (div:SI (reg:SI 1 %r3 [30])
                    (reg:SI 5 %iph [orig:31 current ] [31])))
            (set (reg:SI 5 %iph [34])
                (mod:SI (reg:SI 1 %r3 [30])
                    (reg:SI 5 %iph [orig:31 current ] [31])))
        ]) 56 {*divmodsi4} (insn_list:REG_DEP_TRUE 10
(insn_list:REG_DEP_TRUE 11 (nil)))
    (expr_list:REG_UNUSED (reg:SI 5 %iph [34])
        (expr_list:REG_UNU</description>
    <dc:creator>Omar Torres</dc:creator>
    <dc:date>2008-10-09T18:04:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101586">
    <title>Support for  NT based OS on ARM.</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101586</link>
    <description>Hi,

Would you be willing to consider supporting the PE object formats on the 
ARM based port of ReactOS?

(ReactOS is an attempt to reimplement the NT kernel architecture and API 
as free software based on publicly
available specifications and API documentation)




</description>
    <dc:creator>Farlie A</dc:creator>
    <dc:date>2008-10-09T12:56:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101583">
    <title>"UNICODE"-Unterstützung, XML-Reservierte-Wörter-Unterstützung / "UNICODE"-support, XML-FILE-WITH-RESERVED-WORDS Support</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101583</link>
    <description>Hallo zurück,

vielen Dank für die Antworten.


Mit z.B. "UNICODE" Unterstützung könnte man ja nicht nur lokalisierte Sprachversionen anbieten, sondern auch eigene "mathematische Beschreibungssprachen".

Mit z.B. xml-Karteien, die die einzelnen reservierten Wörter eigens einstellen können, könnte man dann ja auch mehrere mathematische Operatoren, wie z.B. "mathematisches UND /\" oder "mathematisches ODER \/" anstelle von "&amp;&amp;" oder "||" ersetzen.

Wie kommt man zu einer solchen (Universeller Zeichensatz) beispielsweise "UNICODE" Unterstützung des G.-C-Übersetzers?
Wie kann man xml-Karteien für "Reservierte-Wörter" Ersetzungen mit dem G.C-Übersetzer nutzen?

M.f.G.

R. Müller

----
Hello,
how to support UNICODE with G.C.C.?
How to support XML-FILE to translate "reserved Words" in G.C.C.?

R. Müller
________________________________________________________________________
Schon gehört? Bei WEB.DE gibt' s viele kostenlose Spiele:
http://games.entertainment.web.de/de/entertainment/games/free/index.h</description>
    <dc:creator>Rüdiger Müller</dc:creator>
    <dc:date>2008-10-09T09:30:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.gcc.devel/101574">
    <title>gcc-4.2-20081008 is now available</title>
    <link>http://comments.gmane.org/gmane.comp.gcc.devel/101574</link>
    <description>Snapshot gcc-4.2-20081008 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20081008/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 140989

You'll find:

gcc-4.2-20081008.tar.bz2              Complete GCC (includes all of below)

gcc-core-4.2-20081008.tar.bz2         C front end and core compiler

gcc-ada-4.2-20081008.tar.bz2          Ada front end and runtime

gcc-fortran-4.2-20081008.tar.bz2      Fortran front end and runtime

gcc-g++-4.2-20081008.tar.bz2          C++ front end and runtime

gcc-java-4.2-20081008.tar.bz2         Java front end and runtime

gcc-objc-4.2-20081008.tar.bz2         Objective-C front end and runtime

gcc-testsuite-4.2-20081008.tar.bz2    The GCC testsuite

Diffs from 4.2-20081001 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
</description>
    <dc:creator>gccadmin&lt; at &gt;gcc.gnu.org</dc:creator>
    <dc:date>2008-10-08T22:40:55</dc:date>
  </item>
  <textinput about="http://search.gmane.org/?group=$group=gmane.comp.gcc.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gcc.devel</link>
  </textinput>
</rdf:RDF>
