Konuşun Artık.

2012-01-13 Thread Sevim Tuba GÜRLE
Merhaba Yeni Dönem Kayıtlarımız Başladı ( Özel Ders Ortamımız sizi bekliyor) 2011 - 2012 öğretim yılı indirimli kayıt dönemi başladı hemen kayıt yaptırın erken kayıt avantajlarından faydalanarak özel ders imkanından sizde yararlanın. KANADA KÜLTÜR MERKEZİ 0212 252 90 35-36 se...@kanadakulturn

gcc-4.6-20120113 is now available

2012-01-13 Thread gccadmin
Snapshot gcc-4.6-20120113 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120113/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: Go in gcc 4.7

2012-01-13 Thread Ian Lance Taylor
Andreas Schwab writes: >> I suspect that the error of using "int" is one of the reasons why >> makecontext has been removed from POSIX. Thought I don't know why it >> was not replaced with a proper version. > > See >

Re: Go in gcc 4.7

2012-01-13 Thread Andreas Schwab
Ian Lance Taylor writes: > Andreas Schwab writes: > >> Dennis Clarke writes: >> >>> for (argno = 0; argno < argc; argno++) { >>> if (argno < 6) >>> *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long); >>> else >>> *tsp++ = va_arg(a

Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]

2012-01-13 Thread Benjamin Kosnik
> > Note that one of the objectives of this email is to try and get > > maintainers from thinking there is going to be "a perfect time" to > > switch. Development history tells us there will always be more > > changes. We've been sitting on ABI-breaking changes since 2003. > > e.g. http://gcc.gnu

Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]

2012-01-13 Thread Jonathan Wakely
On 13 January 2012 17:45, Benjamin Kosnik wrote: > > Note that one of the objectives of this email is to try and get > maintainers from thinking there is going to be "a perfect time" to > switch. Development history tells us there will always be more changes. > We've been sitting on ABI-breaking ch

Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]

2012-01-13 Thread Benjamin Kosnik
> My concern is specifically about options for changing the default > language version, not options for changing the libstdc++ ABI. More > generally, about configure options affecting the semantics of code > passed to GCC, as opposed to non-semantic configure options such as > choosing the proces

Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]

2012-01-13 Thread Benjamin Kosnik
> > As it turns out, the mangling changes don't really impact the > > explicit instantiations compiled in to libstdc++.so. So, it seems > > possible to say > > Right, so people can use -fabi-version=0 and still use the installed > libstdc++. > > > I think a compelling case could be made to ship

Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]

2012-01-13 Thread Joseph S. Myers
On Fri, 13 Jan 2012, Benjamin Kosnik wrote: > A canonical method for doing the ABI switch seems entirely appropriate. My concern is specifically about options for changing the default language version, not options for changing the libstdc++ ABI. More generally, about configure options affectin

Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]

2012-01-13 Thread Benjamin Kosnik
> I like the idea, but not very strongly. I can live with having to say > -std=c++11 (which I do via shell functions or scripts) Well, the actual C++11 compile/runtime environment is going to be more than just -std=c++11. It's looking something like -std=c++11 -fabi-version=7 + versioned names

Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]

2012-01-13 Thread Benjamin Kosnik
> I think that's a bad idea; having too many ways to configure things > will cause undue confusion. Seems like the train has already left the station WRT gcc configure options. If you feel this is a real issue, then it could be solved the same way that thread support was solved, by adding a "Th

Re: Go in gcc 4.7

2012-01-13 Thread Ian Lance Taylor
Andreas Schwab writes: > Dennis Clarke writes: > >> for (argno = 0; argno < argc; argno++) { >> if (argno < 6) >> *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long); >> else >> *tsp++ = va_arg(ap, long); > > This is broken. T

[Patch] Tentative fix for PR51374: combine.c reorders volatile memory accesses

2012-01-13 Thread Georg-Johann Lay
This is a tentative patch to fix combine.c so that it no more reorders volatile memory accesses. Even reading volatile memory can change other (volatile) memory as explained in the patch. This also applies to volatile memory that is not wired to hardware that changes by magic when reading: An ISR

Re: Go in gcc 4.7

2012-01-13 Thread Jonathan Wakely
On 13 January 2012 11:51, Dennis Clarke wrote: > >> Dennis Clarke writes: >> >>>      for (argno = 0; argno < argc; argno++) { >>>              if (argno < 6) >>>                      *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long); >>>              else >>>                      *tsp++ = va_arg(ap

Re: question on inconsistent generated codes for builtin calls

2012-01-13 Thread Amker.Cheng
On Fri, Jan 13, 2012 at 5:33 PM, Richard Guenther wrote: > > No, I think the check is superfluous and should be removed.  I also wonder > why we exempt BUILT_IN_FREE here ... can you dig in SVN history a bit? > For both things? Thanks for clarifying. I will look into it. -- Best Regards.

Re: Go in gcc 4.7

2012-01-13 Thread Dennis Clarke
> Dennis Clarke writes: > >> for (argno = 0; argno < argc; argno++) { >> if (argno < 6) >> *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long); >> else >> *tsp++ = va_arg(ap, long); > > This is broken. The arguments are of type

Re: question on inconsistent generated codes for builtin calls

2012-01-13 Thread Richard Guenther
On Fri, Jan 13, 2012 at 9:04 AM, Amker.Cheng wrote: > Hi, > I noticed gcc generates inconsistent codes for same function for builtin > calls. > > compile following program: > -- > #include > int a(float x) { >      return sqrtf(x); > } > int b(float x)

Re: Go in gcc 4.7

2012-01-13 Thread Andreas Schwab
Dennis Clarke writes: > for (argno = 0; argno < argc; argno++) { > if (argno < 6) > *tsp++ = reg[REG_O0 + argno] = va_arg(ap, long); > else > *tsp++ = va_arg(ap, long); This is broken. The arguments are of type int, n

question on inconsistent generated codes for builtin calls

2012-01-13 Thread Amker.Cheng
Hi, I noticed gcc generates inconsistent codes for same function for builtin calls. compile following program: -- #include int a(float x) { return sqrtf(x); } int b(float x) { return sqrtf(x); } With command: arm-none-eabi-gcc -mthumb -mhar