I'd like to explain the rules that apply to this relicensing:
* If any text is to be licensed under both the GPL and the GFDL, there
must be copies under both licenses checked in. There may be a tool that
helps propagate changes from one copy to the other. This is the scheme we
already have w
On 02/10/2012 01:58 AM, Vladimir Makarov wrote:
On 12-02-09 5:54 PM, Tobias Grosser wrote:
On 02/09/2012 11:37 PM, Tobias Grosser wrote:
On 02/09/2012 11:05 PM, Vladimir Makarov wrote:
On 02/09/2012 07:42 AM, Tobias Grosser wrote:
== Who will do all the work? ==
After reading all the open p
I am pleased to announce that GCC finally has three
"docstring relicensing maintainers":
Joseph S. Myers
Diego Novillo
Gerald Pfeifer
This makes it possible to relicense docstrings between the GPL and
GFDL. For legal reasons this has to be approved for every change, and
these three maint
On 12-02-09 5:54 PM, Tobias Grosser wrote:
On 02/09/2012 11:37 PM, Tobias Grosser wrote:
On 02/09/2012 11:05 PM, Vladimir Makarov wrote:
On 02/09/2012 07:42 AM, Tobias Grosser wrote:
== Who will do all the work? ==
After reading all the open projects you may wander who will do all the
work?
Hi All,
I am a new joinee to this group and a C/C++ developer for around 2
yrs. What interest me most is gcc / gcov combination output. It list
the code execution details.
Is there a possibility that gcc build binaries can print file
name:line number of the code it is executing at run time.
Some
Ian Lance Taylor writes:
> Russ Allbery writes:
>> The reason, for the record, is because Debian wants to be able to
>> support multiarch with more than two architectures. The /lib32
>> vs. /lib64 distinction doesn't allow one to use the same underlying
>> machinery to easily install, say, arme
Russ Allbery writes:
> Ian Lance Taylor writes:
>> Nenad Vukicevic writes:
>
>>> Has anybody tried to build 4.7 on Ubuntu 11.10 system. I am getting the
>>> following linking problem (no special configure switches):
>>>
>>> /usr/bin/ld: cannot find crt1.o: No such file or directory
>>> /usr/bin
On 02/09/2012 11:37 PM, Tobias Grosser wrote:
On 02/09/2012 11:05 PM, Vladimir Makarov wrote:
On 02/09/2012 07:42 AM, Tobias Grosser wrote:
== Who will do all the work? ==
After reading all the open projects you may wander who will do all the
work? Unfortunately Sebastian switched jobs at the
Snapshot gcc-4.5-20120209 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120209/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 02/09/2012 11:05 PM, Vladimir Makarov wrote:
On 02/09/2012 07:42 AM, Tobias Grosser wrote:
== Who will do all the work? ==
After reading all the open projects you may wander who will do all the
work? Unfortunately Sebastian switched jobs at the end of 2011, such
that we lost one full time c
I'm porting gcc 4.6.2 to a 16 bit CPU that has four GP registers. I've
chosen to allocate R3 as the frame pointer when one is needed.
In line with GCC Internals info on FIXED_REGISTERS ("except on machines
where that can be used as a general register when no frame pointer is
needed") I have no
On 02/09/2012 07:42 AM, Tobias Grosser wrote:
== Who will do all the work? ==
After reading all the open projects you may wander who will do all the
work? Unfortunately Sebastian switched jobs at the end of 2011, such
that we lost one full time contributor. Furthermore, I am myself also
not
Ian Lance Taylor writes:
> Nenad Vukicevic writes:
>> Has anybody tried to build 4.7 on Ubuntu 11.10 system. I am getting the
>> following linking problem (no special configure switches):
>>
>> /usr/bin/ld: cannot find crt1.o: No such file or directory
>> /usr/bin/ld: cannot find crti.o: No such
On Thu, 9 Feb 2012, Geert Bosch wrote:
> I don't agree having such a libm is the ultimate goal. It could be
> a first step along the way, addressing correctness issues. This
Indeed, I think having it as a first step makes sense - with subsequent
development done in that context.
> would be grea
On Thu, 9 Feb 2012, Andrew Haley wrote:
> > No, the point of the separate project would be to be used by both glibc
> > and GCC (and possibly other GNU projects such as GSL) - because
> > cooperation among the various projects wanting such functions is the right
> > way to do things.
>
> Well,
On 02/09/2012 07:16 PM, Arnaud Charlet wrote:
Yes. Debian moved everything for some reason. It's a problem that must
be addressed somehow before gcc 4.7 is released.
It's extremely unfortunate that this will make it impossible to build
older releases of gcc on newer Debian installations.
No
On Feb 9, 2012, at 12:55, Joseph S. Myers wrote:
> No, that's not the case. Rather, the point would be that both GCC's
> library and glibc's end up being based on the new GNU project (which might
> take some code from glibc and some from elsewhere - and quite possibly
> write some from scratc
>>> Has anybody tried to build 4.7 on Ubuntu 11.10 system. I am getting the
>>> following linking problem (no special configure switches):
>>>
>>> /usr/bin/ld: cannot find crt1.o: No such file or directory
>>> /usr/bin/ld: cannot find crti.o: No such file or directory
>>> /usr/bin/ld: cannot find
On 09.02.2012 07:33, Ian Lance Taylor wrote:
Nenad Vukicevic writes:
Has anybody tried to build 4.7 on Ubuntu 11.10 system. I am getting the
following linking problem (no special configure switches):
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: N
On 02/09/2012 06:00 PM, Joseph S. Myers wrote:
> On Thu, 9 Feb 2012, Andrew Haley wrote:
>
>> On 02/09/2012 04:53 PM, Joseph S. Myers wrote:
>>> My view is that we should have a "GNU libm" project whose purpose is not
>>> to install a library directly but to provide functions for use in other
>>
On Thu, 9 Feb 2012, Andrew Haley wrote:
> On 02/09/2012 04:53 PM, Joseph S. Myers wrote:
> > My view is that we should have a "GNU libm" project whose purpose is not
> > to install a library directly but to provide functions for use in other
> > projects (much like gnulib, but the functions coul
On Thu, 9 Feb 2012, Geert Bosch wrote:
> While I think it would be great if there were a suitable
> GNU libm project that we could directly use, this seems to only
> make sense if this could be based on the current glibc math
> library. As far as I understand, it is unlikely that we
No, that's no
On 02/09/2012 04:53 PM, Joseph S. Myers wrote:
> My view is that we should have a "GNU libm" project whose purpose is not
> to install a library directly but to provide functions for use in other
> projects (much like gnulib, but the functions could presume that they were
> being built with rece
On Feb 9, 2012, at 10:28, Richard Guenther wrote:
> Yes, definitely! OTOH last time I added the toplevel libgcc-math directory
> and populated it with sources from glibc RMS objected violently and I had
> to remove it again. So we at least need to find a different source of
> math routines to st
On Thu, 9 Feb 2012, Andrew Haley wrote:
> Okay, but the crlibm algorithms could be extended to long
> doubles and, presumably, floats. Where's Vincent Lefevre
> when you need him? :-)
The crlibm approach, involving exhaustive searches for worst cases for
directed rounding, could as I understa
On Thu, 9 Feb 2012, Richard Guenther wrote:
> > Given the fact that GCC already needs to know pretty much everything
> > about these functions for optimizations and constant folding, and is
> > in the best situation to choose specific implementations (-ffast-math
> > or not, -frounding-math or not
Hi,
On Thu, 9 Feb 2012, Andrew Haley wrote:
> >>> So - do you have an idea what routines we can start off with to get
> >>> a full C99 set of routines for float, double and long double? The
> >>> last time I was exploring the idea again I was looking at the BSD
> >>> libm.
> >>
> >> I'd start
Hi,
On Thu, 9 Feb 2012, James Courtier-Dutton wrote:
> Results when compiled for 32bit x86.
> gcc -m32 -g -O0 -c -o sincos1.o sincos1.c
> gcc -m32 -static -g -o sincos1 sincos1.o -lm
>
> ./sincos1
> sin = 4.62613040764601746e-01
> sinl = 0.46261304076460176
> sincos = 4.62613040764601746e-01
> s
On 02/09/2012 03:59 PM, Richard Guenther wrote:
> On Thu, Feb 9, 2012 at 4:57 PM, Andrew Haley wrote:
>> On 02/09/2012 03:56 PM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 9 Feb 2012, Andrew Haley wrote:
>>>
On 02/09/2012 03:28 PM, Richard Guenther wrote:
> So - do you have an idea what
On Thu, Feb 9, 2012 at 4:57 PM, Andrew Haley wrote:
> On 02/09/2012 03:56 PM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 9 Feb 2012, Andrew Haley wrote:
>>
>>> On 02/09/2012 03:28 PM, Richard Guenther wrote:
So - do you have an idea what routines we can start off with to get
a full C99 set
On 02/09/2012 03:55 PM, James Courtier-Dutton wrote:
> Results for x86_64
> gcc -g -O0 -c -o sincos1.o sincos1.c
> gcc -static -g -o sincos1 sincos1.o -lm
>
> ./sincos1
> sin = -8.52200849767188795e-01(uses xmm register intructions)
> sinl = 0.46261304076460176 (uses fprem and fsin)
On 02/09/2012 03:56 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 9 Feb 2012, Andrew Haley wrote:
>
>> On 02/09/2012 03:28 PM, Richard Guenther wrote:
>>> So - do you have an idea what routines we can start off with to get
>>> a full C99 set of routines for float, double and long double? The last
>>
Hi,
On Thu, 9 Feb 2012, Andrew Haley wrote:
> On 02/09/2012 03:28 PM, Richard Guenther wrote:
> > So - do you have an idea what routines we can start off with to get
> > a full C99 set of routines for float, double and long double? The last
> > time I was exploring the idea again I was looking a
On 9 February 2012 14:51, James Courtier-Dutton wrote:
> 2012/2/9 Andrew Haley :
>> On 02/09/2012 01:38 PM, Tim Prince wrote:
>>> x87 built-ins should be a fair compromise between speed, code size, and
>>> accuracy, for long double, on most CPUs. As Richard says, it's
>>> certainly possible to do
On 02/09/2012 03:28 PM, Richard Guenther wrote:
> So - do you have an idea what routines we can start off with to get
> a full C99 set of routines for float, double and long double? The last
> time I was exploring the idea again I was looking at the BSD libm.
I'd start with INRIA's crlibm.
Andre
On Thu, Feb 9, 2012 at 4:20 PM, Geert Bosch wrote:
>
> On Feb 9, 2012, at 08:46, Andrew Haley wrote:
>> n 02/09/2012 01:38 PM, Tim Prince wrote:
>>> x87 built-ins should be a fair compromise between speed, code size, and
>>> accuracy, for long double, on most CPUs. As Richard says, it's
>>> certa
On Feb 9, 2012, at 08:46, Andrew Haley wrote:
> n 02/09/2012 01:38 PM, Tim Prince wrote:
>> x87 built-ins should be a fair compromise between speed, code size, and
>> accuracy, for long double, on most CPUs. As Richard says, it's
>> certainly possible to do better in the context of SSE, but gcc
On 02/09/2012 02:51 PM, James Courtier-Dutton wrote:
> 2012/2/9 Andrew Haley :
>> On 02/09/2012 01:38 PM, Tim Prince wrote:
>>> x87 built-ins should be a fair compromise between speed, code size, and
>>> accuracy, for long double, on most CPUs. As Richard says, it's
>>> certainly possible to do be
2012/2/9 Andrew Haley :
> On 02/09/2012 01:38 PM, Tim Prince wrote:
>> x87 built-ins should be a fair compromise between speed, code size, and
>> accuracy, for long double, on most CPUs. As Richard says, it's
>> certainly possible to do better in the context of SSE, but gcc doesn't
>> know anythin
On 02/09/2012 01:38 PM, Tim Prince wrote:
> x87 built-ins should be a fair compromise between speed, code size, and
> accuracy, for long double, on most CPUs. As Richard says, it's
> certainly possible to do better in the context of SSE, but gcc doesn't
> know anything about the quality of math
On 2/9/2012 5:55 AM, Richard Guenther wrote:
On Thu, Feb 9, 2012 at 11:35 AM, Andrew Haley wrote:
On 02/09/2012 10:20 AM, James Courtier-Dutton wrote:
From what I can see, on x86_64, the hardware fsin(x) is more accurate
than the hardware fsincos(x).
As you gradually increase the size of X fr
Hi,
it has been quiet around Graphite for a while and I think it is more
than time to give an update on Graphite.
== The Status of Graphite ==
Graphite has been around for a while in GCC. During this time a lot of
people tested Graphite and Sebastian fixed many bugs. As of today the
Graphit
On Thu, Feb 9, 2012 at 11:35 AM, Andrew Haley wrote:
> On 02/09/2012 10:20 AM, James Courtier-Dutton wrote:
>> From what I can see, on x86_64, the hardware fsin(x) is more accurate
>> than the hardware fsincos(x).
>> As you gradually increase the size of X from 0 to 10e22, fsincos(x)
>> diverges f
On 02/09/2012 10:20 AM, James Courtier-Dutton wrote:
> From what I can see, on x86_64, the hardware fsin(x) is more accurate
> than the hardware fsincos(x).
> As you gradually increase the size of X from 0 to 10e22, fsincos(x)
> diverges from the correct accurate value quicker than fsin(x) does.
>
On Thu, Feb 9, 2012 at 7:33 AM, Ian Lance Taylor wrote:
> Nenad Vukicevic writes:
>
>> Has anybody tried to build 4.7 on Ubuntu 11.10 system. I am getting the
>> following linking problem (no special configure switches):
>>
>> /usr/bin/ld: cannot find crt1.o: No such file or directory
>> /usr/bin
On 3 February 2012 21:48, Vincent Lefevre wrote:
> On 2012-02-03 17:44:21 +0100, Michael Matz wrote:
>> Hi,
>>
>> On Fri, 3 Feb 2012, Vincent Lefevre wrote:
>>
>> > > > For the glibc, I've finally reported a bug here:
>> > > >
>> > > > http://sourceware.org/bugzilla/show_bug.cgi?id=13658
>> > >
46 matches
Mail list logo
