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
Hello!
On Fri, Oct 10, 2008 at 09:48:02AM +, Thorsten Glaser wrote:
> Thomas Schwinge dixit:
> >Ideally, IMO, this test (for stack-smashing-protection support in glibc)
> >should not be done by grepping through SYSROOT's features.h, but instead
> >by using the CPP for doing that.
>
> Why not
Hello!
On Fri, Oct 10, 2008 at 01:25:52PM +0200, Samuel Thibault wrote:
> Thomas Schwinge, le Fri 10 Oct 2008 10:37:50 +0200, a écrit :
> > Ideally, IMO, this test (for stack-smashing-protection support in glibc)
> > should not be done by grepping through SYSROOT's features.h, but instead
> > by u
On Fri, 10 Oct 2008, Thorsten Glaser wrote:
> Thomas Schwinge dixit:
>
> >Ideally, IMO, this test (for stack-smashing-protection support in glibc)
> >should not be done by grepping through SYSROOT's features.h, but instead
> >by using the CPP for doing that.
>
> Why not just autoconf?
>
> Check
Thomas Schwinge dixit:
>Ideally, IMO, this test (for stack-smashing-protection support in glibc)
>should not be done by grepping through SYSROOT's features.h, but instead
>by using the CPP for doing that.
Why not just autoconf?
Check for the presence of __stack_smash_handler() in libc… or am I m
Hello!
On Thu, Oct 09, 2008 at 11:49:06AM +0200, Paolo Bonzini wrote:
> > Unfortunately, NATIVE_SYSTEM_HEADER_DIR is a Makefile variable (see
> > gcc/config/t-gnu). It is being used only in three places:
> > gcc/config/t-gnu, gcc/config/t-gnu and gcc/config/i386/t-mingw32. What
That list was bo
"Omar Torres" <[EMAIL PROTECTED]> writes:
> 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:S
Rüdiger Müller <[EMAIL PROTECTED]> writes:
> Is the only possibility to support e.g. "Umlauts" in Source-Text a
> Pre-Translator for the G.C.C. Translator?
Look at the documentation for the -finput-charset option.
> How many ciphers do G.C.C. already support?
GCC just uses iconv.
Ian
Aye up,
I like the idea of signals. The chaining code can be automatically
generated by FFI - the code to do it is pretty trivial.
Also, if instead of having a single struct with all the signals in,
you could have a hashtable of signals referenced by a string id, then
plugins could defi
I currently don't have any preference for a specific way to deal with data
marshaling
since currently it's enough for the MILEPOST project just to return void*
pointer,
but just wanted to mention that last year Cupertino Miranda tried to introduce
an intermediate data layer to ICI to separate pro
Thomas Schwinge, le Fri 10 Oct 2008 10:37:50 +0200, a écrit :
> Ideally, IMO, this test (for stack-smashing-protection support in glibc)
> should not be done by grepping through SYSROOT's features.h, but instead
> by using the CPP for doing that. The problem is that CPP has not yet
> been bulit at
Joseph S. Myers dixit:
>It's desirable to be able to configure GCC correctly in the presence of
>installed headers and only a dummy libc.so, so as to get a GCC that can be
>used to build the full glibc.
Ah, right, the GNU case. Sorry, I totally did not have that one in mind,
even though I know
On Thursday 09 October 2008, Farlie A wrote:
> Hi,
>
> Would you be willing to consider supporting the PE object formats on the
> ARM based port of ReactOS?
I'd really rather not. You should be using an EABI based target and a
postlinker, like SymbianOS does.
See
http://infocenter.arm.com/help/
Hello All,
(I'm replying to Grigori & CC to gcc@ - I suppose every person
interested in plugins is reading the gcc@ list)
Grigori Fursin wrote:
http://gcc-ici.sourceforge.net/papers/mfpp2007.pdf
Thanks for the reference.
By the way, if I am correct, GCC MELT (developed by Basile)
also at
Ian Lance Taylor wrote on 10 October 2008 15:53:
> "Omar Torres" <[EMAIL PROTECTED]> writes:
>
>> 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])
>>
> >> Would you be willing to consider supporting the PE object formats on the
> >> ARM based port of ReactOS?
> >
> > I'd really rather not. You should be using an EABI based target and a
> > postlinker, like SymbianOS does.
> >
> > See
> > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.do
* Dave Korn:
> You're not the first person to come up with this idea, and you probably
> won't be the last, but it's a misbegotten idea, and there's a very good reason
> why it hasn't been done before, and that's not just "because nobody's thought
> of it before you", but because it would basica
Paul Brook wrote:
On Thursday 09 October 2008, Farlie A wrote:
Hi,
Would you be willing to consider supporting the PE object formats on the
ARM based port of ReactOS?
I'd really rather not. You should be using an EABI based target and a
postlinker, like SymbianOS does.
See
http://
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 cop
Joern Rennecke wrote:
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
becau
Hi all,
As Grigori says, and well, the project is frozen (for around one year)
since there was no expectations on it, specially since future of
plugins by that time was really unclear.
In fact the idea by the time I stopped working in it was to extend
gengtype (Garbage Collector's structure
Cupertino Miranda wrote:
Hi all,
As Grigori says, and well, the project is frozen (for around one year)
since there was no expectations on it, specially since future of
plugins by that time was really unclear.
In fact the idea by the time I stopped working in it was to extend
gengtype (Garbag
I have some broken code, compiled from Java source.
It looks like:
D.843 = &java.text.Collator.class$$;
_Jv_InitClass (D.843);
D.845 = &_CD_java_text_Collator;
is being turned into:
D.843 = &java.text.Collator.class$$;
D.845 = &_CD_java_text_Collator;
_Jv_InitClass (D.84
On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> I have some broken code, compiled from Java source.
>
> It looks like:
>
>D.843 = &java.text.Collator.class$$;
>_Jv_InitClass (D.843);
>D.845 = &_CD_java_text_Collator;
>
> is being turned into:
>
>D.843 = &j
Richard Guenther wrote:
> On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> I have some broken code, compiled from Java source.
>>
>> It looks like:
>>
>>D.843 = &java.text.Collator.class$$;
>>_Jv_InitClass (D.843);
>>D.845 = &_CD_java_text_Collator;
>>
>> is b
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-interc
2008/10/10 Tobias Grosser <[EMAIL PROTECTED]>:
>
> Now:
>
>
> -fgraphite: Do nothing.
> -floop-block, -floop-interchange, -floop-stripmine: Try these
> transformations.
This only applies to the branch, does it? There is no do-nothing
command-line option in trunk, is there?
Cheers,
Manuel.
Hi Tobias,
>
>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-in
>
>Hi Tobias,
>>
>>graphite consists of four flags "-floop-block", "-floop-interchange",
>>"-floop-stripmine" and "-fgraphite".
In fact I also think that we should not expose "-floop-stripmine" as a
flag because by itself it is never profitable.
Thanks,
Harsha
On Fri, 2008-10-10 at 20:35 +0200, Manuel López-Ibáñez wrote:
> 2008/10/10 Tobias Grosser <[EMAIL PROTECTED]>:
> >
> > Now:
> >
> >
> > -fgraphite: Do nothing.
> > -floop-block, -floop-interchange, -floop-stripmine: Try these
> > transformations.
>
> This only applies to the branch, does it?
Hello All,
I've run into this:
8<8<8<
template
class B
{
protected:
static const int i = 42;
};
template
class D : protected B
{
public:
D(int n_ = B::i); // line 12
};
8<8<8<
gcc-4.1 and 4.3 give the same error message:
t.cpp:12: error: expecte
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 := $(sh
On Fri, 2008-10-10 at 13:49 -0500, Jagasia, Harsha wrote:
> Hi Tobias,
> >
> >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
On Fri, Oct 10, 2008 at 11:14 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>> On Fri, Oct 10, 2008 at 7:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>>> I have some broken code, compiled from Java source.
>>>
>>> It looks like:
>>>
>>>D.843 = &java.text.Collator.class
On Fri, 2008-10-10 at 13:51 -0500, Jagasia, Harsha wrote:
> >
> >Hi Tobias,
> >>
> >>graphite consists of four flags "-floop-block", "-floop-interchange",
> >>"-floop-stripmine" and "-fgraphite".
>
> In fact I also think that we should not expose "-floop-stripmine" as a
> flag because by itself it
Andrew Haley wrote:
D.843 = &java.text.Collator.class$$;
D.845 = &_CD_java_text_Collator;
_Jv_InitClass (D.843);
This is always a valid transformation.
i.e. the memory reference is moved to before the call to _Jv_InitClass.
There is no memory reference in the above case, it seems jus
Hi,
I would like to add a new command line parameter for graphite. It will
allow us to test graphite without any transformation like loop blocking,
but only using a simple GIMPLE->GRAPHITE->GIMPLE identity
transformation.
Buy adding this command line option, we do not change the behavior of
any o
Tobias Grosser wrote
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
Andrew Haley <[EMAIL PROTECTED]> writes:
> In the RTL code it moves the mem ref, not just the address:
>
> (call (mem:QI (symbol_ref:DI ("_Jv_InitClass") [flags 0x41]
>
> (set (reg/f:DI 95 [ #ref#8#1 ])
> (mem/s/u/f/j:DI (const:DI (plus:DI (symbol_ref:DI
> ("_CD_java_text_Collator")
>
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/24
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
On Sat, Oct 11, 2008 at 03:17:31AM +0800, Zhang Le wrote:
> 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.
> Curren
2008/10/10 Peter A. Felvegi <[EMAIL PROTECTED]>
>
> Hello All,
>
> I've run into this:
>
> 8<8<8<
> template
> class B
> {
> protected:
>static const int i = 42;
> };
>
> template
> class D : protected B
> {
> public:
>D(int n_ = B::i); // line 12
> };
> 8<8<
43 matches
Mail list logo