On Thu, Feb 9, 2012 at 8:16 PM, Geert Bosch wrote:
>
> 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
Russ Allbery writes:
> For example, suppose I'm doing development on an amd64 box targeting armel
> and I want to use Kerberos libraries in my armel application. I'd like to
> be able to install the armel Kerberos libraries on my Debian system using
> regular package management commands, just li
On 02/10/2012 10:15 AM, Andreas Schwab wrote:
> Russ Allbery writes:
>
>> For example, suppose I'm doing development on an amd64 box targeting armel
>> and I want to use Kerberos libraries in my armel application. I'd like to
>> be able to install the armel Kerberos libraries on my Debian system
On 02/10/2012 10:07 AM, Richard Guenther wrote:
>
> The issue with libm in glibc here is that Drepper absolutely does
> not want new ABIs in libm - he believes that for example vectorized
> routines do not belong there (nor the SSE calling-convention variants
> for i686 I tried to push once).
Tha
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 10 February 2012 10:42, Andrew Haley wrote:
> On 02/10/2012 10:07 AM, Richard Guenther wrote:
>>
>> The issue with libm in glibc here is that Drepper absolutely does
>> not want new ABIs in libm - he believes that for example vectorized
>> routines do not belong there (nor the SSE calling-conve
On Fri, 10 Feb 2012, Richard Guenther wrote:
> I don't buy the argument that inlining math routines (apart from those
> we already handle) would improve performance. What will improve
> performance is to have separate entry points to the routines
> to skip errno handling, NaN/Inf checking or roun
[Including libc-alpha on discussion starting on the gcc list.]
On Fri, 10 Feb 2012, James Courtier-Dutton wrote:
> I think a starting point would be at least documenting correctly the
> accuracy of the current libm, because what is currently in the
> documents is obviously wrong.
To the extent t
On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
> On 10 February 2012 10:42, Andrew Haley wrote:
>
> I think a starting point would be at least documenting correctly the
> accuracy of the current libm, because what is currently in the
> documents is obviously wrong.
> It certainly does not d
On 10 February 2012 14:05, Andrew Haley wrote:
> On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
>> On 10 February 2012 10:42, Andrew Haley wrote:
>>
>> I think a starting point would be at least documenting correctly the
>> accuracy of the current libm, because what is currently in the
>> d
On 02/10/2012 02:24 PM, James Courtier-Dutton wrote:
> On 10 February 2012 14:05, Andrew Haley wrote:
>> On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
>>> On 10 February 2012 10:42, Andrew Haley wrote:
>>>
>>> I think a starting point would be at least documenting correctly the
>>> accurac
On 10 February 2012 14:36, Andrew Haley wrote:
> On 02/10/2012 02:24 PM, James Courtier-Dutton wrote:
>> On 10 February 2012 14:05, Andrew Haley wrote:
>>> On 02/10/2012 01:30 PM, James Courtier-Dutton wrote:
On 10 February 2012 10:42, Andrew Haley wrote:
I think a starting point
I've merged trunk rev 183972 into the pph branch.
Diego.
On Thu, 2012-02-09 at 15:52 -0800, Satya Prakash Prasad wrote:
> 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 c
On Feb 9, 2012, at 15:33, Joseph S. Myers wrote:
> For a few, yes, inline support (such as already exists for some functions
> on some targets) makes sense. But for some more complicated cases it
> seems plausible that LTO information in a library might be an appropriate
> way of inlining whil
On Feb 10, 2012, at 05:07, Richard Guenther wrote:
> On Thu, Feb 9, 2012 at 8:16 PM, 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
>> would be great progress, but does not remove the nee
Hi,
I just noticed something strange with my iorqi3 rule.
I have the following:
(define_insn "iorqi3"
[(set (match_operand:QI 0 "register_operand" "=c")
(ior:QI (match_operand:QI 1 "register_operand" "%0")
(match_operand:QI 2 "general_operand" "cwmi")))
(clobber (reg
On Fri, 10 Feb 2012, Geert Bosch wrote:
> On Feb 9, 2012, at 15:33, Joseph S. Myers wrote:
> > For a few, yes, inline support (such as already exists for some functions
> > on some targets) makes sense. But for some more complicated cases it
> > seems plausible that LTO information in a library
On Fri, 10 Feb 2012 16:57:48 +, Paulo J. Matos wrote:
> However, duplicating the instructions and inverting operand order seems
> to defeat the purpose of '%'. So, what's the catch? Or is it a genuine
> bug?
I just understood my miss understanding above. '%' is part of constraints
which a
On Friday 10 of February 2012 13:30:25 James Courtier-Dutton wrote:
> On 10 February 2012 10:42, Andrew Haley wrote:
> > On 02/10/2012 10:07 AM, Richard Guenther wrote:
> >>
> >> The issue with libm in glibc here is that Drepper absolutely does
> >> not want new ABIs in libm - he believes that for
On Fri, 10 Feb 2012, Geert Bosch wrote:
> Right. I even understand where he is coming from. Adding new interfaces
> is indeed a big deal as they'll pretty much have to stay around forever.
And: even if the interface is a known, public, standard, stable interface,
glibc may still not be the right
On 02/10/2012 05:31 PM, Paweł Sikora wrote:
> it would be also nice to see functions for reducing argument range in public
> api.
> finally the end-user can use e.g. sin(reduce(x)) to get the best precision
> with some declared cpu overhead.
Hmm. I'm not sure this is such a terrific idea: each f
On Friday 10 of February 2012 17:41:49 Andrew Haley wrote:
> On 02/10/2012 05:31 PM, Paweł Sikora wrote:
> > it would be also nice to see functions for reducing argument range in
> > public api.
> > finally the end-user can use e.g. sin(reduce(x)) to get the best precision
> > with some declared c
Andreas Schwab writes:
> Russ Allbery writes:
>> For example, suppose I'm doing development on an amd64 box targeting
>> armel and I want to use Kerberos libraries in my armel application.
>> I'd like to be able to install the armel Kerberos libraries on my
>> Debian system using regular package
On 02/10/2012 08:57 AM, Paulo J. Matos wrote:
> However, there's a failure to combine looking like:
> (parallel [
> (set (reg:QI 1 AL)
> (ior:QI (mem/c/i:QI (reg/f:QI 4 AP) [2 y+0 S1 A16])
> (reg:QI 30 [ x+1 ])))
> (clobber (reg:CC 13 CC))
> ])
Why d
On 02/03/2012 12:00 PM, Linus Torvalds wrote:
>do {
> load-link %r,%m
> if (r == value)
> return 0;
> add
>} while (store-conditional %r,%m)
>return 1;
>
> and it is used to implement two *very* common (and critical)
> reference-counting use cases:
>
> - decre
Thanks for the info Dave. I downloaded the tar ball but facing issues
while building it:
prompt:>~/shared_scripts/bin/gcc-py-plugin/gcc-python-plugin-6f960cf 1020> make
python generate-config-h.py -o autogenerated-config.h --gcc=gcc
Traceback (most recent call last):
File "generate-config-h.py",
On 02/10/2012 07:02 PM, Russ Allbery wrote:
Anyway, I'll stop discussing this here, as it's not really on topic. I
just wanted to provide some background, since I realize on the surface
it's a somewhat puzzling decision.
Thanks for the explanation. Is there a rationale document (and a design
On Fri, 2012-02-10 at 12:14 -0800, Satya Prakash Prasad wrote:
> Thanks for the info Dave. I downloaded the tar ball but facing issues
> while building it:
This is probably more appropriate for the plugin's mailing list:
https://fedorahosted.org/mailman/listinfo/gcc-python-plugin
rather than the
Toon Moene writes:
> Thanks for the explanation. Is there a rationale document (and a design
> document that explains what we have to expect from this change)
> somewhere on the Debian web site ?
> I couldn't find it, but perhaps I didn't search it right.
The documentation that I'm aware of is
On Thu, Feb 09, 2012 at 04:59:55PM +0100, 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:
> >> On Thu, 9 Feb 2012, Andrew Haley wrote:
> >>
> >>> On 02/09/2012 03:28 PM, Richard Guenther wrote:
> So - do you have an
Snapshot gcc-4.6-20120210 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120210/
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
32 matches
Mail list logo
