michael kapelko writes:
> Recently I found out a surprising requirement to compile own
> application with Horde3D library (http://horde3d.org/), OpenGL 3D
> graphics engine.
> Horde3D library links to shared GL library. But -lHorde3D must be
> listed *before* -lGL for any application to work corr
Hello.
Recently I found out a surprising requirement to compile own application
with Horde3D library (http://horde3d.org/), OpenGL 3D graphics engine.
Horde3D library links to shared GL library. But -lHorde3D must be listed
*before* -lGL for any application to work correctly. If I link the
appl
Daniel Jacobowitz writes:
> On Wed, Feb 03, 2010 at 06:23:19AM -0800, Ian Lance Taylor wrote:
>> fanqifei writes:
>>
>> > According to the internal manual, insn length attribute can be used to
>> > to calculate the length of emitted code chunks when verifying branch
>> > distances.
>> > Can it b
Snapshot gcc-4.4-20100209 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100209/
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
On 01/26/10 16:47, Steven Bosscher wrote:
Hello Jeff and other interested readers :-)
There is a function compute_transpout() in gcse.c and there are a
couple of things about this functions that I don't understand exactly.
First, there is this comment before the function says:
"An expression
Michael Hope wrote:
> Hi Sergio. Any luck so far?
Micheal, thanks for your inquiry. I made some progress, in fact.
I got the GO_IF_LEGITIMATE_ADDRESS() macro to detect correctly REG+IMM
addresses, and then the LEGITIMIZE_ADDRESS() macro to force them to be
pre-computed in a register.
However,
On 09.02.2010 19:39, Sebastian Pop wrote:
> On Tue, Feb 9, 2010 at 12:34, Cristianno Martins
> wrote:
>> Hi,
>>
>> Thanks for the fast reply. Only one more thing: is there some way that
>> I could force it to be signed??
>
> I guess that you should wait the fixes from Tobias and Ramakrishna to
>
Dear all,
If I consider this code
typedef struct sTestUnsignedChar {
uint64_t a:1;
}STestUnsignedChar;
uint64_t getU (STestUnsignedChar a)
{
return a.a;
}
I get this in the DCE pass :
(insn 6 3 7 2 bitfield2.c:8 (set (subreg:DI (reg:QI 75) 0)
(zero_extract:DI (reg/v:DI 73 [ a ]
On Tue, Feb 9, 2010 at 12:34, Cristianno Martins
wrote:
> Hi,
>
> Thanks for the fast reply. Only one more thing: is there some way that
> I could force it to be signed??
I guess that you should wait the fixes from Tobias and Ramakrishna to
CLooG and Graphite to have the type of the IV exposed by
Hi,
Thanks for the fast reply. Only one more thing: is there some way that
I could force it to be signed??
On Tue, Feb 9, 2010 at 3:17 PM, Richard Guenther
wrote:
> On Tue, Feb 9, 2010 at 6:01 PM, Cristianno Martins
> wrote:
>> Hi everyone,
>>
>> First of all, I already find [and fix] the probl
On Tue, Feb 9, 2010 at 6:01 PM, Cristianno Martins
wrote:
> Hi everyone,
>
> First of all, I already find [and fix] the problem that I had
> described in the last email.
> Now, I need a help with a pretty intriguing issue, described below.
>
> Well, such as I told in the last email, I'm working on
I try to patch gcc so that after a fdivd the destination register is
stored to the stack.
fdivd %f0,%f2,%f4; std %f4, [%sp]
I generate the rtl for divdf3 using a emit_insn,DONE sequence in a
define_expand pattern (see below).
In the assembler output phase I use a define_insn and write
out "fdivd
Joern Rennecke wrote:
Quoting "Paulo J. Matos" :
Hi all,
After reading the internal docs about rtx_costs I am left wondering
what they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the assembler is generat
On Tue, 2 Feb 2010, Cameron Lowell Palmer wrote:
Does Modulo Scheduling work on x86 platforms? I have tried adding in
various versions of the -fmodulo-sched option and get the exact same
output with or without. The application is a very simplistic matrix
multiply without dependencies.
No, at
> After reading the internal docs about rtx_costs I am left wondering what
> they exactly are estimating.
> - Are they estimating in the beginning of expand how many insns will be
> generated from a particular insn until the assembler is generated?
> - or Are they estimating how many assembler in
Quoting "Paulo J. Matos" :
Hi all,
After reading the internal docs about rtx_costs I am left wondering
what they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the assembler is generated?
- or Are they estim
Hi all,
After reading the internal docs about rtx_costs I am left wondering what
they exactly are estimating.
- Are they estimating in the beginning of expand how many insns will be
generated from a particular insn until the assembler is generated?
- or Are they estimating how many assembler in
Jack Howarth a écrit :
Jacob,
Apple's gcc is based on their own branch and is not the
same as FSF gcc. The first FSF gcc that is validated on
on darwin10 was gcc 4.4. However I would suggest you first
start testing against current FSF gcc trunk. There are a
number of fixes for darwin10 that ar
Hi Jeff,
Many thanks for the pointers. I will make the changes and attach the
patch to the bugzilla soon.
Cheers,
Rahul
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: 09 February 2010 00:45
To: Rahul Kharche
Cc: gcc@gcc.gnu.org; sdkteam-gnu
Subject: Re: Failure to comb
Quoting Paolo Bonzini :
I'm adding autoc...@gnu.org to the destinations, since this is a
pretty fundamental problem with AC_CHECK_DECL and C++
I've whipped up a patch with a modified version of AC_CHECK_DECLS -
I've called it AC_CHECK_PROTOS - that can optionally have argument types
for a func
I'm adding autoc...@gnu.org to the destinations, since this is a
pretty fundamental problem with AC_CHECK_DECL and C++
On Tue, Feb 9, 2010 at 02:17, Joern Rennecke
wrote:
>
>> On 02/08/2010 09:58 AM, Joern Rennecke wrote:
>>>
>>> That would only work if every program that uses libiberty uses
>>>
There's another funny thing about gcc3 behavior which I've just discovered:
$ gcc -v 2>&1 | grep version
gcc version 3.4.2
$ gcc -o mem mem.c ; ./mem
-1024
$ gcc -o mem1 mem1.c ; ./mem1
0
$ cat mem.c
#include
int main() {
char *p1, *p2;
{
char a[1024];
23 matches
Mail list logo
