Hello all,
I am highly interestd in implementing C compiler for EFI Byte Code in
gcc and participate in Google Summer Code.
EFI is a much larger, more complex,OS-like replacement for the older BIOS
firmware interface present in all IBM PC-compatible personal computers.
and the EFI specificat
On Tue, Mar 2, 2010 at 4:18 PM, Laurent GUERBY wrote:
> Hi,
>
> I'm trying to build a fully 32 bits GCC on a x86_64-linux 64 bits debian
> system which has all the 32 bits libraries installed (this is for the
> GCC compile farm testers).
>
> I've played with various things including --with-ld= and
On Wed, 3 Mar 2010, Laurent GUERBY wrote:
> $ ../trunk/configure --prefix=/n/100/guerby/install-trunk
> --enable-languages=c --enable-__cxa_atexit --disable-nls
> --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.2-32
> --with-gmp=/opt/cfarm/gmp-4.2.4-32 --with-mpc=/opt/cfarm/mpc-0.8-32
> --b
Hi,
I'm trying to build a fully 32 bits GCC on a x86_64-linux 64 bits debian
system which has all the 32 bits libraries installed (this is for the
GCC compile farm testers).
I've played with various things including --with-ld= and putting a fake
"ld" script in PATH but something is hardcoding "/u
Snapshot gcc-4.4-20100302 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100302/
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/branches
A GCC front-end (and runtime) for UPC (Unified Parallel C) is available
via the following GCC branch: svn://svn/gcc/branches/gupc.
The GUPC project is described here: http://gcc.gnu.org/projects/gupc.html.
Over the course of this year, we plan to work with the GCC
development community with the g
On Tue, 2010-03-02 at 12:26 +0100, Richard Guenther wrote:
> On Tue, Mar 2, 2010 at 12:00 PM, Pjotr Kourzanov
> wrote:
> > On Tue, 2010-03-02 at 10:47 +, Andrew Haley wrote:
> >> On 03/02/2010 10:34 AM, Pjotr Kourzanov wrote:
> >>
> >> >> int duff4_fails(char * dst,const char * src,const size
Hi,
On Thu, Feb 25, 2010 at 11:48:44AM +0100, Richard Guenther wrote:
> I've been using the attached in debug sessions a lot (and I have
> similar patch for the cgraph).
I'd be interested in that, can you post it as well?
I meant to write something like that for myself a few times but in the
en
On Tue, Mar 2, 2010 at 12:00 PM, Pjotr Kourzanov
wrote:
> On Tue, 2010-03-02 at 10:47 +, Andrew Haley wrote:
>> On 03/02/2010 10:34 AM, Pjotr Kourzanov wrote:
>>
>> >> int duff4_fails(char * dst,const char * src,const size_t n)
>> >> {
>> >> const size_t rem=n % 4, a=rem + (!rem)*4;
>> >>
On Tue, 2010-03-02 at 10:47 +, Andrew Haley wrote:
> On 03/02/2010 10:34 AM, Pjotr Kourzanov wrote:
>
> >> int duff4_fails(char * dst,const char * src,const size_t n)
> >> {
> >> const size_t rem=n % 4, a=rem + (!rem)*4;
> >> char * d=dst+=a;
> >> const char * s=src+=a;
> >> /* gcc bu
Peter Kourzanov writes:
> I think the compiler is generating wrong code for duff4_fails() when
> 'case 0' labels the for-loop. It somehow skips the first for-loop
> expression,
If rem != 0 you jump over the init expression, so it is never executed.
Andreas.
--
Andreas Schwab, sch...@redhat.
On 03/02/2010 10:34 AM, Pjotr Kourzanov wrote:
>> int duff4_fails(char * dst,const char * src,const size_t n)
>> {
>> const size_t rem=n % 4, a=rem + (!rem)*4;
>> char * d=dst+=a;
>> const char * s=src+=a;
>> /* gcc bug? dst+=n; */
>>
>> switch (rem) {
>> case 0: for(dst+=n;d>
On Tue, Mar 2, 2010 at 10:55 AM, Andrew Haley wrote:
> On 03/02/2010 08:55 AM, Alain Ketterlin wrote:
>>
>> It looks like gcc sometimes produces "useless" conditional branches.
>> I've found code like this:
>>
>> xor %edx,%edx
>> ; code with no effect on edx (see full code below)
>> test
On Tue, 2010-03-02 at 11:27 +0100, Richard Guenther wrote:
> On Tue, Mar 2, 2010 at 10:38 AM, Peter Kourzanov
> wrote:
> >
> > Hi guys,
> >
> > I have the following variation on Duff's device that seems to
> > mis-compile on all GCC versions I can access within a minute (that
> > is gcc-3.{3,4},
Andrew Haley wrote:
On 03/02/2010 08:55 AM, Alain Ketterlin wrote:
It looks like gcc sometimes produces "useless" conditional branches.
I've found code like this:
xor%edx,%edx
; code with no effect on edx (see full code below)
test %edx,%edx
jne
The branch on the last line is
On Tue, 2010-03-02 at 10:24 +, Andrew Haley wrote:
> On 03/02/2010 09:38 AM, Peter Kourzanov wrote:
>
> > I have the following variation on Duff's device that seems to
> > mis-compile on all GCC versions I can access within a minute (that
> > is gcc-3.{3,4}, gcc-4.{1,2,3,4} on x86 and gcc
On Tue, Mar 2, 2010 at 10:38 AM, Peter Kourzanov
wrote:
>
> Hi guys,
>
> I have the following variation on Duff's device that seems to
> mis-compile on all GCC versions I can access within a minute (that
> is gcc-3.{3,4}, gcc-4.{1,2,3,4} on x86 and gcc-4.3.2 on x86_64). The
> symptoms are as foll
On 03/02/2010 09:38 AM, Peter Kourzanov wrote:
> I have the following variation on Duff's device that seems to
> mis-compile on all GCC versions I can access within a minute (that
> is gcc-3.{3,4}, gcc-4.{1,2,3,4} on x86 and gcc-4.3.2 on x86_64). The
> symptoms are as follows:
>
> $ gcc-4.4
On 03/02/2010 08:55 AM, Alain Ketterlin wrote:
>
> It looks like gcc sometimes produces "useless" conditional branches.
> I've found code like this:
>
> xor%edx,%edx
> ; code with no effect on edx (see full code below)
> test %edx,%edx
> jne
>
> The branch on the last line is n
Alain Ketterlin wrote:
> I've found code like this:
>
> xor %edx,%edx
> ; code with no effect on edx (see full code below)
> test %edx,%edx
> jne
I have experienced similar sequences where your
"code with no effect" was a lot of SSE instructions,
so I can confirm that the problem exi
Hi guys,
I have the following variation on Duff's device that seems to
mis-compile on all GCC versions I can access within a minute (that
is gcc-3.{3,4}, gcc-4.{1,2,3,4} on x86 and gcc-4.3.2 on x86_64). The
symptoms are as follows:
$ gcc-4.4 -o duffbug duffbug.c ; ./duffbug
{ he��3)
{ hello
It looks like gcc sometimes produces "useless" conditional branches.
I've found code like this:
xor%edx,%edx
; code with no effect on edx (see full code below)
test %edx,%edx
jne
The branch on the last line is never taken. Why does gcc generate such
code sequences? Is this pat
22 matches
Mail list logo
