Ranjit Mathew kirjoitti:
If I understand you correctly, you're saying that the
target runtime libraries are already created by the
cross-compiler in Phase 1, so I don't need to rebuild
them again in Phase 2 along with the crossed-native
compiler - I can get by by just building the compiler.
Y
Hello,
Is the following example legal in current GCC compilation for C
program? I thought the static array allocation can only used by a
defined constant such as char buf[MAX_SIZE], where #define MAX_SIZE 10?
void DoSomthing(int size)
{
char buf[size];
.. do something
On 24 April 2006 12:09, YH wrote:
> Hello,
>
> Is the following example legal in current GCC compilation for C
> program? I thought the static array allocation can only used by a
Not static! That's an automatic allocation on the stack.
> defined constant such as char buf[MAX_SIZE], where #
YH writes:
>
> Is the following example legal in current GCC compilation for C
> program? I thought the static array allocation can only used by a
> defined constant such as char buf[MAX_SIZE], where #define MAX_SIZE 10?
>
> void DoSomthing(int size)
> {
>char buf[size];
>
Thanks Dave. So it is safe to use variable length array in C program on
linux machine, and I suppose all GCC on linux machines conform C99
although I never switch my C compilation to C99.
Thanks and sorry for FAQ questions.
Jim
Dave Korn wrote:
On 24 April 2006 12:09, YH wrote:
Hello,
I think I may have found 2 crashes with gcc-4.1.0 ppc-linux
ppc-linux-gcc -O2 -mcpu=8548 -mfloat-gprs=double -c [xy].c
Crash 1) x.c:
double f (void) { return 0; }
I get an unrecognizable insn. Here's a fix that works for me; I'm not
completely sure about it. Can someone comment?
--- /hom
Kai Ruottu wrote:
Ranjit Mathew kirjoitti:
If I understand you correctly, you're saying that the
target runtime libraries are already created by the
cross-compiler in Phase 1, so I don't need to rebuild
them again in Phase 2 along with the crossed-native
compiler - I can get by by just building
On Wednesday 12 April 2006 15:43, Rask Ingemann Lambertsen wrote:
> On Wed, Apr 12, 2006 at 07:47:32AM +0200, Frank Riese wrote:
> > On Monday 10 April 2006 19:48, you wrote:
> > > Can it at least add (small) immediates to registers?
> >
> > Nope, sry. The only instructions that take other argument
On Monday 24 April 2006 17:59, Frank Riese wrote:
> With my limited experience I would say that this tells me that the compiler
> gradually uses up all available registers and then, instead of freeing one,
> it complains that it hasn't any left (as a reminder: registers 3-7 are my
> GENERAL_REGS wi
I have hacked gcc to add some instrumentation functionality (adding a simple
pass). It works for my C programs (because I can compile them by using
">/home/mygcc/bin/gcc myprog.c") , and now I am thinking of how to have it
work for fortran programs--as my transformation pass is done after
GIMPL
Hi all,
I'm experiencing a strange gfortran bug, i686-pc-mingw32 specific,
with options -march=pentium4 -mfpmath=sse -msse. I reproduce it below,
and post it here before filing it because I can't manage to create a C
testcase, and have no idea if this is something already known (though
my bugzilla
> I realize the gcc4.0.2 source code does not include any fortran frontend.
Yes it does.
Paul
From: Paul Brook <[EMAIL PROTECTED]>
To: gcc@gcc.gnu.org
CC: "sean yang" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: about f77/f90 and gcc
Date: Mon, 24 Apr 2006 17:56:19 +0100
> I realize the gcc4.0.2 source code does not include any fortran
frontend.
Yes it does.
It does? Here
On Mon, Apr 24, 2006 at 05:58:46PM +, sean yang wrote:
> >> I realize the gcc4.0.2 source code does not include any fortran
> >frontend.
> >
> >Yes it does.
>
> It does? Here is the executeable under my gcc directory
If you build from source, and the needed prerequisites aren't found to
buil
Try this patch: http://people.redhat.com/dj/m32c/gcc-reload1.c.patch
It might help a little, although it doesn't solve the fundamental
design flaw (not being able to restart reload after breaking a complex
insn apart).
Dave Murphy wrote:
>When a mingw gcc toolchain is built on a linux host then it cannot find
>it's headers or it's associated tools when running from a cmd shell on
>the windows host. This can be worked around by using the msys shell to
>provide a mount point identical to the configured prefix but i
Dear all,
I would like to participate in the Google Summer of Code with GCC as
the mentoring organisation working in the project described below.
This is a draft of the project proposal I am preparing to submit to
Google. Any comments and suggestions (and criticism) are welcome.
Also, if someone w
Hello,
I would like to compile files created on Windows and encoded in
"Unicode" (UTF-8 or UTF-16). Microsoft puts a little header at the
beginning of files to indicate that they are UTF-16, UTF-8, etc. I
believe that this header is standard unicode btw, not an extension!
When I try to com
Ross Ridge wrote:
Dave Murphy wrote:
When a mingw gcc toolchain is built on a linux host then it cannot find
it's headers or it's associated tools when running from a cmd shell on
the windows host. This can be worked around by using the msys shell to
provide a mount point identical to the con
On Mon, Apr 24, 2006 at 05:59:30PM +0200, Frank Riese wrote:
> However, I'm still having problems with reloading/register spilling:
>
> -
> /usr/local/src/gcc/objdir/./gcc/xgcc -B/usr/local/src/gcc/objdir/./gcc/
Ross Ridge wrote:
>MinGW GCC is a native Win32 application and is unaffected by any mounts
>you create with MSYS.
Dave Murphy wrote:
>It's affected when you run from the msys bash shell, my apologies for
>not being clear.
That makes no difference. MinGW GCC is a native Win32 application and
can'
If I try to build libssp in a combined tree with newlib and binutils,
for an embedded target, configure keeps barfing because libssp's
configury is trying (in lots of places) to build executables and/or
run them, neither of which works in for crosses in a combined tree.
And GCC_NO_EXECUTABLES jus
Ross Ridge wrote:
Ross Ridge wrote:
MinGW GCC is a native Win32 application and is unaffected by any mounts
you create with MSYS.
Dave Murphy wrote:
It's affected when you run from the msys bash shell, my apologies for
not being clear.
That makes no difference. MinGW GCC is
Ross Ridge wrote:
>That makes no difference. MinGW GCC is a native Win32 application and
>can't see any mounts you create with MSYS.
Dave Murphy wrote:
>sorry but you're most definitely wrong about that
No, I'm not. The example you gave shows how MSYS mounts have an effect on
the MSYS shell, wh
Dave Murphy wrote:
> [EMAIL PROTECTED] /e
> $ gcc /usr/local/test/test.c -o /usr/local/test/test.exe
>
> [EMAIL PROTECTED] /e
> $ /usr/local/test/test.exe
> E:\msys\local\test\test.exe
> [EMAIL PROTECTED] /e
> $
>
> As you can see the paths are translated by the shell before being passed
> to wi
Ross Ridge wrote:
Ross Ridge wrote:
That makes no difference. MinGW GCC is a native Win32 application and
can't see any mounts you create with MSYS.
Dave Murphy wrote:
sorry but you're most definitely wrong about that
No, I'm not. The example you gave shows how MSYS mounts
From: Daniel Berlin <[EMAIL PROTECTED]>
To: sean yang <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: Re: adding nodes in a tree --after GIMPLIFICATION, before SSA
Date: Wed, 19 Apr 2006 22:38:11 -0700
In fact, there are only *two* places a call can occur in GIMPLE at that
point: bare, or
27 matches
Mail list logo
