G.C.C. should support more Ciphers.

2008-10-10 Thread Rüdiger Müller
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

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

2008-10-10 Thread Thomas Schwinge
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

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

2008-10-10 Thread Thomas Schwinge
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

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

2008-10-10 Thread Joseph S. Myers
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

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

2008-10-10 Thread Thorsten Glaser
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

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

2008-10-10 Thread Thomas Schwinge
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

Re: divmodsi4

2008-10-10 Thread Ian Lance Taylor
"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

Re: G.C.C. should support more Ciphers.

2008-10-10 Thread Ian Lance Taylor
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

Re: Defining a common plugin machinery

2008-10-10 Thread Hugh Leather
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

RE: Defining a common plugin machinery

2008-10-10 Thread Grigori Fursin
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

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

2008-10-10 Thread Samuel Thibault
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

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

2008-10-10 Thread Thorsten Glaser
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

Re: Support for NT based OS on ARM.

2008-10-10 Thread Paul Brook
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/

Re: Defining a common plugin machinery

2008-10-10 Thread Basile STARYNKEVITCH
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

RE: divmodsi4

2008-10-10 Thread Dave Korn
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]) >>

Re: Support for NT based OS on ARM.

2008-10-10 Thread Paul Brook
> >> 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

Re: Echte Lokaliserung der Programmbausprache/ Real Localisation of Programming Language

2008-10-10 Thread Florian Weimer
* 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

Re: Support for NT based OS on ARM.

2008-10-10 Thread Farlie A
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://

Copyright notices during assignment limbo

2008-10-10 Thread Joern Rennecke
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

Re: Copyright notices during assignment limbo

2008-10-10 Thread David Daney
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

Re: Defining a common plugin machinery

2008-10-10 Thread Cupertino Miranda
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

Re: Defining a common plugin machinery

2008-10-10 Thread Taras Glek
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

gcc moving memory reference across call

2008-10-10 Thread Andrew Haley
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

Re: gcc moving memory reference across call

2008-10-10 Thread Richard Guenther
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

Re: gcc moving memory reference across call

2008-10-10 Thread Andrew Haley
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

[graphite] Cleanup of command line parameters

2008-10-10 Thread Tobias Grosser
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

Re: [graphite] Cleanup of command line parameters

2008-10-10 Thread Manuel López-Ibáñez
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.

RE: [graphite] Cleanup of command line parameters

2008-10-10 Thread Jagasia, Harsha
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

RE: [graphite] Cleanup of command line parameters

2008-10-10 Thread Jagasia, Harsha
> >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

Re: [graphite] Cleanup of command line parameters

2008-10-10 Thread Tobias Grosser
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?

Compiler error w/ templates and default argument value

2008-10-10 Thread Peter A. Felvegi
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

install path in libgcc Makefile.in

2008-10-10 Thread Zhang Le
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

RE: [graphite] Cleanup of command line parameters

2008-10-10 Thread Tobias Grosser
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

Re: gcc moving memory reference across call

2008-10-10 Thread Andrew Pinski
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

RE: [graphite] Cleanup of command line parameters

2008-10-10 Thread Tobias Grosser
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

Re: gcc moving memory reference across call

2008-10-10 Thread Richard Henderson
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

[graphite] Add -fgraphite-identity / Solution two

2008-10-10 Thread Tobias Grosser
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

Re: [graphite] Cleanup of command line parameters

2008-10-10 Thread Albert Cohen
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

Re: gcc moving memory reference across call

2008-10-10 Thread Ian Lance Taylor
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") >

Branch created for transactional memory

2008-10-10 Thread Richard Henderson
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

gcc-4.4-20081010 is now available

2008-10-10 Thread gccadmin
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

Re: install path in libgcc Makefile.in

2008-10-10 Thread Daniel Jacobowitz
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

Re: Compiler error w/ templates and default argument value

2008-10-10 Thread James Dennett
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<