> Can you point me at least to the section which explains this?
http://gcc.gnu.org/install/build.html
--
Eric Botcazou
www.sileorganik.comİstanbulun şirin ilçesi Şile ve köylerinden
evlerinize geliyor , unuttuğunuz o eski tatları sizlere hatırlatacağız ,
kapıda ödeme kolaylığıyla artık sizlere çok yakınız . Doğal köy yoğurdu
,köy yumurtası ,köy ekmeği ,köy peyniri www.sileorganik.com
w
Hello All
(I've found this issue with the GCC MELT branch rev 169469, but I strongly
believe it is not directly related to MELT and should happen with the trunk
also. You could run the testsuite/melt/topengpu-1.c test, a comment in that
file describes how to run the test)
First, a pass inserted b
On Tue, Feb 01, 2011 at 04:32:51PM +0100, Gerald Pfeifer wrote:
> On Tue, 1 Feb 2011, Dongsheng Song wrote:
> >> The DATESTAMP change could also be in a post-commit hook (doing
> >> nothing if the date didn't change, of course). No idea whether
> >> this is technically possible of course.
> > Yes,
On Wed, Feb 2, 2011 at 2:29 PM, Jakub Jelinek wrote:
> On Tue, Feb 01, 2011 at 04:32:51PM +0100, Gerald Pfeifer wrote:
>> On Tue, 1 Feb 2011, Dongsheng Song wrote:
>> >> The DATESTAMP change could also be in a post-commit hook (doing
>> >> nothing if the date didn't change, of course). No idea wh
On Feb 2, 2011, at 8:32 AM, Richard Guenther wrote:
> On Wed, Feb 2, 2011 at 2:29 PM, Jakub Jelinek wrote:
>> On Tue, Feb 01, 2011 at 04:32:51PM +0100, Gerald Pfeifer wrote:
>>> On Tue, 1 Feb 2011, Dongsheng Song wrote:
> The DATESTAMP change could also be in a post-commit hook (doing
>
On 02/01/2011 04:54 AM, Dave Korn wrote:
On 01/02/2011 02:33, Joel Sherrill wrote:
Should LTO work with a target not using gold?
Yes, it should, but some work is needed at the binutils end. I am testing
the attached two patches at the moment; the idea is to have fully-debugged
support for
Hi,
In the past few days, something has regressed
on the sparc. Revision 169143 only had 699 failures
and ~100 of those were LTO related. David Korn's
patch seems to have resolved those. Revision 169504
has 2231 failures.
http://www.rtems.org/pipermail/rtems-tooltestresults/2011-January/000407.
On Wed, Feb 2, 2011 at 22:00, Paul Koning wrote:
> No. Subversion specifically documents the fact that a pre-commit hook can't
> change the transaction; it can only inspect it.
>
> paul
>
Yes, here is a pilot post commit hook for bumping DATESTAMP:
post-commit |2 ++
update_da
Dongsheng Song writes:
> + echo -n ${CURR_DATE} > gcc/DATESTAMP
What's the point of -n?
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/11 07:19, Joel Sherrill wrote:
> Hi,
>
> In the past few days, something has regressed
> on the sparc. Revision 169143 only had 699 failures
> and ~100 of those were LTO related. David Korn's
> patch seems to have resolved those. Revision 16
As noticed by Peter Maydell, the EHCI device driver in Linux gets
miscompiled by some versions of arm-gcc (still need to find out which)
due to a combination of problems:
1. In include/linux/usb/ehci_def.h, struct ehci_caps is defined
with __attribute__((packed)), for no good reason. This is clear
On Wed, Feb 02, 2011 at 05:00:20PM +0100, Arnd Bergmann wrote:
> I would suggest fixing this by:
>
> 1. auditing all uses of __attribute__((packed)) in the Linux USB code
> and other drivers, removing the ones that are potentially harmful.
>
> 2. Changing the ARM MMIO functions to use inline asse
On Wed, Feb 2, 2011 at 5:00 PM, Arnd Bergmann wrote:
> As noticed by Peter Maydell, the EHCI device driver in Linux gets
> miscompiled by some versions of arm-gcc (still need to find out which)
> due to a combination of problems:
>
> 1. In include/linux/usb/ehci_def.h, struct ehci_caps is defined
On Wed, Feb 02, 2011 at 05:51:27PM +0100, Richard Guenther wrote:
> > I would suggest fixing this by:
> >
> > 1. auditing all uses of __attribute__((packed)) in the Linux USB code
> > and other drivers, removing the ones that are potentially harmful.
> >
> > 2. Changing the ARM MMIO functions to us
On Wed, 2 Feb 2011, Richard Guenther wrote:
> The pointer conversions already invoke undefined behavior as specified by the
> C standard (6.3.2.3/7).
I would say: the conversions are undefined if the pointer is
insufficiently aligned for any of the pointer types involved (source,
destination or
On Wednesday 02 February 2011 17:37:02 Russell King - ARM Linux wrote:
> We used to use inline assembly at one point, but that got chucked out.
> The problem is that using asm() for this causes GCC to generate horrid
> code.
>
> 1. there's no way to tell GCC that the inline assembly is a load
>
No new failures. Tested on x86_64.
Diego.
On Wed, Feb 2, 2011 at 10:19 AM, Diego Novillo wrote:
>
> No new failures. Tested on x86_64.
This caused a lot of svn revisions and addition to bug reports that
was not really needed.
-- Pinski
On Wed, Feb 2, 2011 at 13:30, Andrew Pinski wrote:
> This caused a lot of svn revisions and addition to bug reports that
> was not really needed.
Gah, sorry about that. The multiple svn revisions were somewhat
intentional, I was trying to keep the svn commit history, but I will
stop doing that
On Wed, Feb 2, 2011 at 10:47 AM, Diego Novillo wrote:
> On Wed, Feb 2, 2011 at 13:30, Andrew Pinski wrote:
>
>> This caused a lot of svn revisions and addition to bug reports that
>> was not really needed.
>
> Gah, sorry about that. The multiple svn revisions were somewhat
> intentional, I was t
On Wed, Feb 2, 2011 at 13:48, H.J. Lu wrote:
> Git can solve this problem for you.
It was git the cause of the problem, actually. I committed with 'git
svn dcommit' without squashing the commits into a single one.
Diego.
On Wed, Feb 2, 2011 at 10:52 AM, Diego Novillo wrote:
> On Wed, Feb 2, 2011 at 13:48, H.J. Lu wrote:
>
>> Git can solve this problem for you.
>
> It was git the cause of the problem, actually. I committed with 'git
> svn dcommit' without squashing the commits into a single one.
>
I don't use sv
I would like to apologize for all the bugzilla spam I have caused with
a recent merge I made. I was committing the merge with 'git svn',
since I was interested in keeping the commit history. I did not
realize that this would also commit the svn commit messages with the
PR numbers, causing the mas
Arnd Bergmann writes:
> On Wednesday 02 February 2011 17:37:02 Russell King - ARM Linux wrote:
>> We used to use inline assembly at one point, but that got chucked out.
>> The problem is that using asm() for this causes GCC to generate horrid
>> code.
>>
>> 1. there's no way to tell GCC that the
From: Russell King - ARM Linux
Date: Wed, 2 Feb 2011 16:37:02 +
> 1. there's no way to tell GCC that the inline assembly is a load
>instruction and therefore it needs to schedule the following
>instructions appropriately.
Just add a dummy '"m" (pointer)' asm input argument to the inl
On Wed, Feb 02, 2011 at 01:38:31PM -0800, David Miller wrote:
> From: Russell King - ARM Linux
> Date: Wed, 2 Feb 2011 16:37:02 +
>
> > 1. there's no way to tell GCC that the inline assembly is a load
> >instruction and therefore it needs to schedule the following
> >instructions appr
From: Russell King - ARM Linux
Date: Wed, 2 Feb 2011 21:45:22 +
> On Wed, Feb 02, 2011 at 01:38:31PM -0800, David Miller wrote:
>> From: Russell King - ARM Linux
>> Date: Wed, 2 Feb 2011 16:37:02 +
>>
>> > 1. there's no way to tell GCC that the inline assembly is a load
>> >instruct
From: Måns Rullgård
Date: Wed, 02 Feb 2011 23:08:01 +
> David Miller writes:
>
>> From: Russell King - ARM Linux
>> Date: Wed, 2 Feb 2011 16:37:02 +
>>
>>> 1. there's no way to tell GCC that the inline assembly is a load
>>>instruction and therefore it needs to schedule the followi
David Miller writes:
> From: Russell King - ARM Linux
> Date: Wed, 2 Feb 2011 16:37:02 +
>
>> 1. there's no way to tell GCC that the inline assembly is a load
>>instruction and therefore it needs to schedule the following
>>instructions appropriately.
>
> Just add a dummy '"m" (point
On Wed, 2 Feb 2011, Dongsheng Song wrote:
> Index: hooks/update_datestamp
> ===
> --- hooks/update_datestamp (revision 0)
> +++ hooks/update_datestamp (revision 0)
> @@ -0,0 +1,51 @@
> +#!/bin/sh
> +
> +REPOS="$1"
> +REV="$2"
-20110202/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--with-build-config=bootstrap-lto --enable-stage1-languages=c,lto
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog
On Wed, 2 Feb 2011 14:09:21 -0500
Diego Novillo wrote:
> I would like to apologize for all the bugzilla spam I have caused with
> a recent merge I made. I was committing the merge with 'git svn',
> since I was interested in keeping the commit history. I did not
> realize that this would also co
33 matches
Mail list logo
