Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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.
Yes, once being made and being thoroughly tested, any library shouldn't
be rebuilt. Doing that again only means a test for the compiler producing
the library - the result should by all sanity be identical in size and bytes
with the existing...
Definitely the cross-GCC for the $target on the $build host is the expected
compiler to produce the target libraries, not the new GCC being built for
the new $host and for the $target. In your case it could be possible to have
Wine installed and then trying to run the new MinGW-hosted native GCC
on the $build host, but this isn't the assumption, the $build-X-$target GCC
is the one producing the $target libraries, in your case the
'i686-mingw32-gcc'
(and all the stuff it uses as subprocesses, headers and libraries) or
something.
I don't know much about the internals of GCC, but what
you're saying should be possible though a bit cumbersome.
Building everything in Phase 2 (compiler and libraries)
just gives a nice bundle that I can then redeploy as I
wish (but this is precisely the thing that seems to be
broken, on MinGW at least).
I would go as far as not even producing that special "native GCC", but to
build instead a "MinGW-targeted and MinGW-hosted GCC" ! I have never
understood why the Windoze-host should cause the MinGW-targeted GCC
being in any way different from a Linux-hosted and MinGW-targeted GCC
in its install scheme... The MinGW-targeted GCC on Windoze really doesn't
need to mimic any proprietary "native 'cc'" which has its headers in
'/usr/include'
and its libraries in '/usr/lib' or something Maybe some Unix
sources could
require the X11 stuff being in its "native" places, but never that the C
headers
and libraries would be in some virtual "native" places
After one has 50 or so MinGW-hosted GCCs for all kind of targets, that
very weird "native GCC" has this far sounded being an oddball among all the
other GCCs using the "cross GCC" scheme... But this opinion of mine seems
to be opposite to the current trend: If one has 50 or so GCCs, each one of
them should use its own "native" install scheme on the cross-host, the new
"--with-sysroot" tries to enable this new bright idea
Anyway if even standardizing the $prefix for all the GCCs made by oneself,
for instance using the SVR4-like standard '/opt/gcc' as the $prefix,
one could
have quite identicallly installed GCCs on any host... Or the $prefix
could be
$host dependent, on Windoze/MinGW host for instance that '/mingw' being
the chosen $prefix for all the MinGW-hosted GCCs So when one has
only cross-GCCs everywhere and has only one standard $prefix in use
everywhere, copying becomes very easy. If one needs to copy the target
libs from '/opt/gcc/lib/gcc/i686-mingw32/3.4.6' on Linux onto just the same
place on Windoze, how this copying could be in any way cumbersome?
Ok, if the GCC configure command has for instance :
--build=i686-linux-gnu --host=i586-mingw32 --target=i686-mingw32
then the resulted GCC is a crosscompiler from 'i586-mingw32' to
'i686-mingw32'
because the $host is different from the $target And if the used
$prefix is the
same as used in the $build ('i686-linux-gnu' here) host, only the GCC
binaries
(the '.exe's for Windoze) would be different between the two MinGW-targeted
GCCs on Linux and Windoze hosts...
Generally it could be very informative to be capable to rebuild those
libraries on
more than one $build system using different $build-X-MinGW GCCs (but their
versions and the sources used to produce them being identical) and see
that the
results are really identical with identical GCC options being used in
compile. So
I really aren't against all "reinventions", only thinking that using
just the same GCC
once again for the same task isn't that "informative". But if you
really use the new
MinGW-hosted GCC for the rebuild on Linux using Wine, that could give some
new information about the quality of the new compiler...
Re: static array size
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
}
Thanks.
Jim
RE: static array size
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 #define MAX_SIZE 10?
>
> void DoSomthing(int size)
> {
>char buf[size];
>
> .. do something
>
> }
>
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Variable-Length.html#Variable-Leng
th
"Variable-length automatic arrays are allowed in ISO C99, and as an extension
GCC accepts them in C89 mode and in C++"
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: static array size
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];
>
> .. do something
>
> }
This question should have been addresses to [EMAIL PROTECTED]
Please RTFM, Section 5.13: Arrays of Variable Length
==..
..
.
Andrew.
Re: static array 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,
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 #define MAX_SIZE 10?
void DoSomthing(int size)
{
char buf[size];
.. do something
}
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Variable-Length.html#Variable-Leng
th
"Variable-length automatic arrays are allowed in ISO C99, and as an extension
GCC accepts them in C89 mode and in C++"
cheers,
DaveK
two powerpc mpc8548 crashes
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?
--- /home/eliot/gcc/gcc/config/rs6000/spe.md2006-04-20
11:04:24.0 -0700
+++ /home/eliot/teak/gcc/gcc/config/rs6000/spe.md2006-04-20
17:18:10.0 -0700
@@ -2211,11 +2211,13 @@
[(set_attr "length" "8")])
(define_insn "*frob_di_df_2"
- [(set (subreg:DF (match_operand:DI 0 "register_operand" "=&r") 0)
-(match_operand:DF 1 "register_operand" "r"))]
+ [(set (subreg:DF (match_operand:DI 0 "register_operand" "=&r,r") 0)
+(match_operand:DF 1 "input_operand" "r,m"))]
"TARGET_E500_DOUBLE"
- "evmergehi %H0,%1,%1\;evmergelo %L0,%1,%1"
- [(set_attr "length" "8")])
+ "@
+ evmergehi %H0,%1,%1\;evmergelo %L0,%1,%1
+ evldd%X1 %0,%y1"
+ [(set_attr "length" "8,4")])
(define_insn "*mov_sidf_e500_subreg0"
[(set (subreg:SI (match_operand:DF 0 "register_operand" "+r") 0)
Crash 2) y.c:
static const int init_jk[] = {2,3,4,6}; /* initial value for jk */
static const double PIo2[] = {
1.57079625129699707031e+00, /* 0x3FF921FB, 0x4000 */
7.54978941586159635335e-08, /* 0x3E74442D, 0x */
5.39030252995776476554e-15, /* 0x3CF84698, 0x8000 */
3.28200341580791294123e-22, /* 0x3B78CC51, 0x6000 */
1.27065575308067607349e-29, /* 0x39F01B83, 0x8000 */
1.2293330898328932e-36, /* 0x387A2520, 0x4000 */
2.73370053816464559624e-44, /* 0x36E38222, 0x8000 */
2.16741683877804819444e-51, /* 0x3569F31D, 0x */
};
static const double
zero = 0.0,
one= 1.0,
two24 = 1.67772160e+07, /* 0x4170, 0x */
twon24 = 5.9604644775390625e-08; /* 0x3E70, 0x */
typedef int int32_t;
int __kernel_rem_pio2(double *x, double *y, int e0, int nx, int prec,
const int32_t *ipio2)
{
int32_t jz,jx,jv,jp,jk,carry,n,iq[20],i,j,k,m,q0,ih;
double z,fw,f[20],fq[20],q[20];
/* initialize jk*/
jk = init_jk[prec];
jp = jk;
/* determine jx,jv,q0, note that 3>q0 */
jx = nx-1;
jv = (e0-3)/24; if(jv<0) jv=0;
q0 = e0-24*(jv+1);
/* set up f[0] to f[jx+jk] where f[jx+jk] = ipio2[jv+jk] */
j = jv-jx; m = jx+jk;
for(i=0;i<=m;i++,j++) f[i] = (j<0)? zero : (double) ipio2[j];
/* compute q[0],q[1],...q[jk] */
for (i=0;i<=jk;i++) {
for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j]; q[i] = fw;
}
jz = jk;
recompute:
/* compute n */
z = 0;
n = (int32_t) z;
z -= (double)n;
ih = 0;
if(q0>0) {/* need iq[jz-1] to determine n */
i = (iq[jz-1]>>(24-q0)); n += i;
iq[jz-1] -= i<<(24-q0);
ih = iq[jz-1]>>(23-q0);
}
else if(q0==0) ih = iq[jz-1]>>23;
else if(z>=0.5) ih=2;
if(ih>0) {/* q > 0.5 */
n += 1; carry = 0;
for(i=0;i0) {/* rare case: chance is 1 in 12 */
switch(q0) {
case 1:
iq[jz-1] &= 0x7f; break;
case 2:
iq[jz-1] &= 0x3f; break;
}
}
if(ih==2) {
z = one - z;
if(carry!=0) z = 0;
}
}
/* check if recomputation is needed */
if(z==zero) {
j = 0;
for (i=jz-1;i>=jk;i--) j |= iq[i];
if(j==0) { /* need recomputation */
for(k=1;iq[jk-k]==0;k++); /* k = no. of terms needed */
for(i=jz+1;i<=jz+k;i++) { /* add q[jz+1] to q[jz+k] */
f[jx+i] = (double) ipio2[jv+i];
for(j=0,fw=0.0;j<=jx;j++) fw += x[j]*f[jx+i-j];
q[i] = fw;
}
jz += k;
goto recompute;
}
}
/* compute PIo2[0,...,jp]*q[jz,...,0] */
for(i=jz;i>=0;i--) {
for(fw=0.0,k=0;k<=jp&&k<=jz-i;k++) fw += PIo2[k]*q[i+k];
fq[jz-i] = fw;
}
/* compress fq[] into y[] */
switch(prec) {
case 0:
fw = 0.0;
for (i=jz;i>=0;i--) fw += fq[i];
y[0] = (ih==0)? fw: -fw;
break;
case 1:
case 2:
fw = 0.0;
for (i=jz;i>=0;i--) fw += fq[i];
y[0] = (ih==0)? fw: -fw;
fw = fq[0]-fw;
for (i=1;i<=jz;i++) fw += fq[i];
y[1] = (ih==0)? fw: -fw;
break;
case 3:/* painful */
for (i=jz;i>0;i--) {
fw = fq[i-1]+fq[i];
fq[i] += fq[i-1]-fw;
fq[i-1] = fw;
}
for (i=jz;i>1;i--) {
fw = fq[i-1]+fq[i];
fq[i] += fq[i-1]-fw;
fq[i-1] = fw;
}
for (fw=0.0,i=jz;i>=2;i--) fw += fq[i];
if(ih==0) {
y[0] = fq[0]; y[1] = fq[1]; y[2] = fw;
} else {
y[0] = -fq[0]; y[1] = -fq[1]; y[2] = -fw;
}
}
return n&7;
}
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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 the compiler.
Yes, once being made and being thoroughly tested, any library shouldn't
be rebuilt. Doing that again only means a test for the compiler producing
the library - the result should by all sanity be identical in size and
bytes
with the existing...
Definitely the cross-GCC for the $target on the $build host is the
expected
compiler to produce the target libraries, not the new GCC being built for
the new $host and for the $target. In your case it could be possible
to have
Wine installed and then trying to run the new MinGW-hosted native GCC
on the $build host, but this isn't the assumption, the
$build-X-$target GCC
is the one producing the $target libraries, in your case the
'i686-mingw32-gcc'
(and all the stuff it uses as subprocesses, headers and libraries) or
something.
I don't know much about the internals of GCC, but what
you're saying should be possible though a bit cumbersome.
Building everything in Phase 2 (compiler and libraries)
just gives a nice bundle that I can then redeploy as I
wish (but this is precisely the thing that seems to be
broken, on MinGW at least).
I would go as far as not even producing that special "native GCC", but to
build instead a "MinGW-targeted and MinGW-hosted GCC" ! I have never
understood why the Windoze-host should cause the MinGW-targeted GCC
being in any way different from a Linux-hosted and MinGW-targeted GCC
in its install scheme... The MinGW-targeted GCC on Windoze really
doesn't
need to mimic any proprietary "native 'cc'" which has its headers in
'/usr/include'
and its libraries in '/usr/lib' or something Maybe some Unix
sources could
require the X11 stuff being in its "native" places, but never that the
C headers
and libraries would be in some virtual "native" places
[snip]
All this is very interesting but has strayed quite a bit from the
problem at hand.
Something both Ranjit and I are experiencing is that relocation of a gcc
toolchain in the 4.x.x series is broken. The problem is especially
apparent on a windows host and symptoms vary depending on whether the
toolchain was built in a linux or a windows environment.
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 isn't ideal.
Any cross gcc built using mingw on a windows machine has problems when
the toolchain is relocated. The resulting toolchain here will always
attempt to access folders in the original configured directory which
results in a dialog asking the user to insert a disk when the original
install location is a removable media drive on the host machine.
Ranjit, the attached patch stops my cross toolchains accessing the
configured location when looking for specs files and tools but does not
yet address the include problem. In theory it should at least get your
linux built toolchains finding their tools when run on a windows host.
The problem with the include paths is that update_path in prefix.c
expects set_std_prefix to have been called with the location of the
relocated toolchain. While gcc does this, neither cc1 nor cc1plus do. I
think toplev.c needs some code to call make_relative_prefix and
set_std_prefix similar to gcc.c.
Dave
--- gcc-4.1.0/gcc/gcc.c Sat Jan 21 18:29:08 2006
+++ gcc-4.1.0-arm/gcc/gcc.c Mon Apr 24 16:05:45 2006
@@ -6148,10 +6148,10 @@
/* We need to check standard_exec_prefix/just_machine_suffix/specs
for any override of as, ld and libraries. */
- specs_file = alloca (strlen (standard_exec_prefix)
+ specs_file = alloca (strlen (gcc_exec_prefix)
+ strlen (just_machine_suffix) + sizeof ("specs"));
- strcpy (specs_file, standard_exec_prefix);
+ strcpy (specs_file, gcc_exec_prefix);
strcat (specs_file, just_machine_suffix);
strcat (specs_file, "specs");
if (access (specs_file, R_OK) == 0)
--- gcc-4.1.0/gcc/prefix.c Sat Jun 25 03:02:01 2005
+++ gcc-4.1.0-arm/gcc/prefix.c Tue Apr 18 05:03:53 2006
@@ -246,13 +246,16 @@
The returned string is always malloc-ed, and the caller is
responsible for freeing it. */
+
+static const char *old_prefix = PREFIX;
+
char *
update_path (const char *path, const char *key)
{
char *result, *p;
- const int len = strlen (std_prefix);
+ const int len = strlen (old_prefix);
- if (! strncmp (path, std_prefix, len)
+ if (! strncmp (path, old_prefix, len)
&& (IS_DIR_SEPARATOR(path[len])
|| path[len] == '\0')
&& key != 0)
Re: Reloading Problems and Memory Addressing
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 arguments than registers
> > are the aforementioned LDL/LDH (load low/high), branch instructions (they
> > take a memory address) and four bit operations which can mask, invert,
> > set or delete a bit in a register.
>
> This will increase the probability of reload failures when storing through
> a pointer, because of the need for an extra register to hold the offset in
> some cases. For example
>
> int x, *p;
> p[15] = x;
> /* p not used after this */
>
> LDL R[4], 30
> LDH R[4], 0
> ADD R[3], R[3], R[4]
> STO R[3], R[2]
>
> > > #define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL) \
> > > if (REG_P (X)) \
> > > goto LABEL;
> >
> > I tried that out today. I wasn't sure about the exact contexts in which
> > this macro is used. It seems to work fine, though.
>
Rask, Dave, thanks for your answers so far!
Sry for not answering for some time but the last two weeks were pretty busy
for me and I wans't able to try out all of your suggestions until yesterday. I
also tried to read up on compilers and GCC internals the best I could before
requesting your help again - hope I don't ask any redundant questions.
I moved my code to mainline and the segmentation faults I had before
disappeared. Not making BP fixed seems to have helped with a lot of code, too.
However, I'm still having problems with reloading/register spilling:
-
/usr/local/src/gcc/objdir/./gcc/xgcc -B/usr/local/src/gcc/objdir/./gcc/
-B/usr/local/zykluno-none/bin/ -B/usr/local/zykluno-none/lib/
-isystem /usr/local/zykluno-none/include -isystem
/usr/local/zykluno-none/sys-include
-O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include -I../../gcc/../libdecnumber
-I../libdecnumber -DL_muldi3 -c ../../gcc/libgcc2.c -o libgcc/./_muldi3.o
cc1: warning: target system does not support debug output
cc1: warning: target system does not support debug output
../../gcc/libgcc2.c: In function '__muldi3':
../../gcc/libgcc2.c:520: error: unable to find a register to spill in
class 'GENERAL_REGS'
../../gcc/libgcc2.c:520: error: this is the insn:
(insn 436 435 442 6 ../../gcc/libgcc2.c:520 (set (reg/f:HI 5 R[5] [+6 ])
(mem/s/c:HI (reg/f:HI 198) [0+2 S2 A16])) 17 {movhi} (nil)
(expr_list:REG_DEAD (reg/f:HI 198)
(nil)))
../../gcc/libgcc2.c:520: internal compiler error: in spill_failure, at
reload1.c:1912
-
I looked at the offending lines in libgcc2.c and it seems to me that the only
problem with that code is that the compiler needs a lot of registers for the
structures and members and thus runs out of registers.
I followed your suggestion and dumped the *.greg of libgcc2.c
(-fdump-rtl-greg-details):
-
[...]
Using reg 2 for reload 0
Using reg 3 for reload 1
Spilling for insn 425.
Using reg 2 for reload 0
Using reg 3 for reload 1
Spilling for insn 426.
Using reg 2 for reload 0
Using reg 3 for reload 1
Spilling for insn 433.
Using reg 3 for reload 0
Spilling for insn 434.
Using reg 4 for reload 0
Spilling for insn 435.
Using reg 5 for reload 0
Spilling for insn 436.
reload failure for reload 0
Reloads for insn # 436
Reload 0: reload_in (HI) = (reg/f:HI 198)
GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1)
reload_in_reg: (reg/f:HI 198)
-
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 with BP being number 6 and SP number 7).
If that helps, here are the last few instructions before the compiler fails:
-
[...]
(note 430 426 431 6 NOTE_INSN_FUNCTION_END)
(note 431 430 433 6 ("../../gcc/libgcc2.c") 520)
(insn 433 431 434 6 ../../gcc/libgcc2.c:520 (set (reg:HI 2 R[2] [ ])
(subreg:HI (reg:DI 30 [ ]) 0)) 17 {movhi}
(insn_list:REG_DEP_TRUE 426 (nil))
(nil))
(insn 434 433 435 6 ../../gcc/libgcc2.c:520 (set (reg:HI 3 R[3] [+2 ])
(subreg:HI (reg:DI 30 [ ]) 2
Re: Reloading Problems and Memory Addressing
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 with BP being number 6 and SP number 7). > > ;; End of basic block 6, registers live: > 2 [R[2]] 3 [R[3]] 4 [R[4]] 5 [R[5]] 6 [BP] 7 [SP] > --- I meant to write that registers 2-7 are GENERAL_REGS. Frank
about f77/f90 and gcc
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 GIMPLIFICATION, this should work theoretically. i.e., I want to incorporate an f77/f90 frontend to my compiler (I imagine/guess the frontend can be combined by simply changing a script file, as changing mpicc script can redirect it to any compiler. But I may be wrong). I realize the gcc4.0.2 source code does not include any fortran frontend. Apparently, in my box, the f77 executable is in a directory that I don't have privilege to change.(I am using a Linux box administrated by my university. ) which f77 /usr/bin/f77 _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Bug with SSE on mingw32
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 searches didn't return successful results).
$ cat a.f90
real(8) :: x
x = 2._8
print *, sqrt(x)
end
$ gfortran.exe a.f90 -mfpmath=sse -msse -march=i686 -O0 && a
1.41421356237310
$ gfortran.exe a.f90 -mfpmath=sse -msse -march=pentium4 -O0 && a
[pops up a crash window, win32 equivalent of a segfault]
Debugging leads to an endless loop of:
> gdb: do_initial_child_stuff: process 2284
> gdb: kernel event for pid=2284 tid=2264 code=CREATE_PROCESS_DEBUG_EVENT)
> gdb: child_resume.SetThreadContext: thread 2284.0x8d8
> ContinueDebugEvent (cpid=2284, ctid=2264, DBG_CONTINUE);
The difference in the assembly created in both cases:
$ diff -pu a.s.working a.s.crashing
--- a.s.working Mon Apr 24 16:11:00 2006
+++ a.s.crashingMon Apr 24 16:11:12 2006
@@ -13,8 +13,8 @@ _MAIN__:
pushl %ebp
movl%esp, %ebp
subl$312, %esp
- fldlLC0
- fstpl -8(%ebp)
+ movsd LC0, %xmm0
+ movsd %xmm0, -8(%ebp)
movl$LC1, -280(%ebp)
movl$3, -276(%ebp)
movl$6, -284(%ebp)
@@ -22,9 +22,8 @@ _MAIN__:
leal-288(%ebp), %eax
movl%eax, (%esp)
call__gfortran_st_write
- fldl-8(%ebp)
- fsqrt
- fstpl -16(%ebp)
+ sqrtsd -8(%ebp), %xmm0
+ movsd %xmm0, -16(%ebp)
movl$8, 8(%esp)
leal-16(%ebp), %eax
movl%eax, 4(%esp)
I tried to make C testcases based on the generated code/original dump:
MAIN__ ()
{
real8 x;
x = 2.0e+0;
x = __builtin_sqrt (x);
}
but they all work. Does anyone have any idea why all this is happening?
Thanks,
FX
Re: about f77/f90 and gcc
> I realize the gcc4.0.2 source code does not include any fortran frontend. Yes it does. Paul
Re: about f77/f90 and gcc
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 is the executeable under my gcc directory home/mgcc/bin>ls c++ g++ gcj gjnih i686-pc-linux-gnu-g++ i686-pc-linux-gnu-gcj jv-scan cpp gcc gcjh grepjari686-pc-linux-gnu-gcc i686-pc-linux-gnu-gcjh fastjar gccbug gcov i686-pc-linux-gnu-c++ i686-pc-linux-gnu-gcc-4.0.2 jcf-dump Paul _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Re: about f77/f90 and gcc
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 build Fortran, then Fortran isn't built.
Re: Reloading Problems and Memory Addressing
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).
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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 isn't ideal. MinGW GCC is a native Win32 application and is unaffected by any mounts you create with MSYS. Ross Ridge
Google SoC Project proposal: Wcoercion option
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 wants to participate as a mentor for this project [*], please get in contact with Ian Lance Taylor and me. Thanks in advance, Manuel López-Ibáñez. [*] http://code.google.com/soc/mentorfaq.html Google Summer of Code Project Proposal Wcoercion option: warn of any implicit conversion that may change a value Manuel López-Ibáñez ([EMAIL PROTECTED]) --- Summary --- The goal of this project is to develop an option warning of any implicit conversion that may change a value. Examples of such conversions are passing a double value to a function declared to receive a float argument and setting a signed constant to an unsigned variable. The option should not warn of explicit conversions or of cases where the value cannot in fact change despite the implicit conversion. These options would be particularly useful for security auditing and scientific applications. - Rationale - In its most recent version, GCC features only a handful of warning options for potentially problematic type conversions. As explained in the GCC manual page, the option Wsign-compare warns of comparisons between signed and unsigned values that could produce an incorrect result when the signed value is converted to unsigned. In addition, the Wconversion option "warns if a prototype causes a type conversion that is different from what would happen to the same argument in the absence of such prototype". Wconversion also warns if a negative integer constant expression is implicitly converted into an unsigned type. In particular, Wconversion is frequently misused to warn about type conversions that may change a value[1]. The confusion between the documented behaviour and the intention of the user often results in numerous warnings for perfectly working code [2][3]. Moreover, there have been proposals for dividing the two different behaviours of Wconversion into two distinct options [4], and for renaming Wconversion and creating a new option[5][6]. The proposal of Joseph Myers[6] defines the basic goal of this project, which is to create a new option: Wcoercion. This new option will warn for any implicit conversion that may alter a value. Such option is common in other compilers [7] and it has been mentioned as a desirable feature in GCC [8]. --- Roadmap --- * Documentation: writing a clear description of the new option, the cases where it should apply and its expected behaviour. A short description of the option purpose would be the basis of its description in the manual of GCC. * Coding of the testcases into an example program. This program would be the basis for testing the new option. * Implementation of the option. This will be accomplished in several steps. First the basic infrastructure for the option will be added. Then, each testcase may be implemented as an individual patch. The implementation would be based on that of Wconversion and Wsign-compare. I understand that the code may not be incorporated into GCC's main development trunk during the Summer of Code 2006. Therefore, my intention is to synchronise the patch with the latest version of GCC until the code is ready to be integrated into the main development trunk, after the work developed for the Google Summer of Code. Finally, I intend to follow the guidelines of contribution to GCC [9] and any advice received from GCC developers. About me My name is Manuel López-Ibáñez, I was born in 1980 in Spain. I studied Computer Engineering (5 years degree) at the University of Granada (Spain). Currently, I am pursuing a PhD by thesis at Napier University in Edinburgh (United Kingdom). Website: http://sbe.napier.ac.uk/~manuel/ The motivation for this project arised when I misused the Wconversion option for warning about implicit conversions in a scientific library. Then, I started gathering information about the current status of Wconversion as well as the possibility and importance of a new option. I have good knowledge of both C and Subversion and I am used to working with patches and GNU tools. I am genuinely looking forward to learning from this project. I hope my relevant abilities and a little help from the community will suffice to make this project useful for everybody. [1] http://groups.google.com/group/gnu.gcc.bug/msg/1e8545e6b7e03320 [2] http://www.gnu.org/software/libc/FAQ.html#s-3.17 [3] http://gcc.gnu.org/ml/gcc-bugs/1999-08n/msg00591.html [4] http://lists.debian.org/debian-gcc/2002/12/msg00159.html [5] http://lists.debian.org/debian-gcc/2003/02/msg00079.html [6] http://www.srcf.ucam.org/~js
Windows Unicode and GCC
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 compile the most simple hello world file (included at the
end of this message) with gcc that was created in notepad and saved in
Unicode, I get the following message:
saved in UTF-8:
nicolas:~> gcc -finput-charset=UTF-8 hi-utf8.c
hi-utf8.c:1: error: stray '\239' in program
hi-utf8.c:1: error: stray '\187' in program
hi-utf8.c:1: error: stray '\191' in program
hi-utf8.c:1: error: syntax error at '#' token
hi-utf8.c:1: error: parse error before '<' token
saved in UTF-16:
nicolas:~> gcc -finput-charset=UTF-16 hi-utf16.c
hi-utf16.c:1:19: failure to convert UTF-16 to UTF-8
without specifying the codepage
nicolas:~> gcc hi-utf16.c
a ton of errors
From these results, I am lead to believe, perhaps wrongly, that there
are 2 problems:
1-CPP doesn't recognize the unicode header
2-CPP reads the source file as UTF-16, but fails to read the header file
as UTF-8, or ascii.
Presumably, CPP converts source files into UTF-8 for GCC.
I think that CPP should try to determine the encoding for each file and
not use a single encoding for every file. It should look for a unicode
header when it opens a file (original c source or any include), and if
it doesn't find one, use the default: -finput-charset, LC_CTYPE, UTF-8,
until it's done processing that file. Note that vim is reads files
saved with unicode headers without problem.
I am using cpp 3.4.3, which may be old... but I cant find what's new in
the 4 branch.
Please inform me if I am missing something, or what can be done about
this. Thank you.
Nicolas
source:
#include
int main()
{
printf("hi.\n");
return 0;
}
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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 configured prefix but isn't ideal. MinGW GCC is a native Win32 application and is unaffected by any mounts you create with MSYS It's affected when you run from the msys bash shell, my apologies for not being clear. Dave
Re: Reloading Problems and Memory Addressing
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/
> -B/usr/local/zykluno-none/bin/ -B/usr/local/zykluno-none/lib/
> -isystem /usr/local/zykluno-none/include -isystem
> /usr/local/zykluno-none/sys-include
> -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
> -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
> -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
> -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber
> -I../libdecnumber -DL_muldi3 -c ../../gcc/libgcc2.c -o libgcc/./_muldi3.o
>
> cc1: warning: target system does not support debug output
> cc1: warning: target system does not support debug output
> ../../gcc/libgcc2.c: In function '__muldi3':
> ../../gcc/libgcc2.c:520: error: unable to find a register to spill in
> class 'GENERAL_REGS'
> ../../gcc/libgcc2.c:520: error: this is the insn:
> (insn 436 435 442 6 ../../gcc/libgcc2.c:520 (set (reg/f:HI 5 R[5] [+6 ])
> (mem/s/c:HI (reg/f:HI 198) [0+2 S2 A16])) 17 {movhi} (nil)
> (expr_list:REG_DEAD (reg/f:HI 198)
> (nil)))
> ../../gcc/libgcc2.c:520: internal compiler error: in spill_failure, at
> reload1.c:1912
> -
>
> I looked at the offending lines in libgcc2.c and it seems to me that the only
> problem with that code is that the compiler needs a lot of registers for the
> structures and members and thus runs out of registers.
>
> I followed your suggestion and dumped the *.greg of libgcc2.c
> (-fdump-rtl-greg-details):
>
> -
> [...]
> Using reg 2 for reload 0
> Using reg 3 for reload 1
> Spilling for insn 425.
> Using reg 2 for reload 0
> Using reg 3 for reload 1
> Spilling for insn 426.
> Using reg 2 for reload 0
> Using reg 3 for reload 1
> Spilling for insn 433.
> Using reg 3 for reload 0
> Spilling for insn 434.
> Using reg 4 for reload 0
> Spilling for insn 435.
> Using reg 5 for reload 0
> Spilling for insn 436.
> reload failure for reload 0
>
> Reloads for insn # 436
> Reload 0: reload_in (HI) = (reg/f:HI 198)
> GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1)
> reload_in_reg: (reg/f:HI 198)
> -
I'm guessing that reg 198 is on the stack somewhere. I would have thought
that there would be more than one reload for insn 436. I think reload
should emit these insns before insn 436 (using reg 5 itself as a temporary):
(set (reg:HI 5) (const_int offset_of_reg_198)) ; movhi/4
(set (reg:HI 5) (plus:HI (reg:HI 6 BP) (reg:HI 5))) ; addhi3/1
And then insn 436 itself:
(set (reg:HI 5) (mem:HI (reg:HI 5))); movhi/2
Somehow reload fails to realize that the target register can be used to
build the address. It needs further analysis. Notice how this fails for
insns 433, 434 and 435 too, only they had a spare register that reload could
fritter away.
> If that helps, here are the last few instructions before the compiler fails:
>
> -
> [...]
> (note 430 426 431 6 NOTE_INSN_FUNCTION_END)
> (note 431 430 433 6 ("../../gcc/libgcc2.c") 520)
> (insn 433 431 434 6 ../../gcc/libgcc2.c:520 (set (reg:HI 2 R[2] [ ])
> (subreg:HI (reg:DI 30 [ ]) 0)) 17 {movhi}
> (insn_list:REG_DEP_TRUE 426 (nil))
> (nil))
> (insn 434 433 435 6 ../../gcc/libgcc2.c:520 (set (reg:HI 3 R[3] [+2 ])
> (subreg:HI (reg:DI 30 [ ]) 2)) 17 {movhi} (nil)
> (nil))
> (insn 435 434 436 6 ../../gcc/libgcc2.c:520 (set (reg:HI 4 R[4] [+4 ])
> (subreg:HI (reg:DI 30 [ ]) 4)) 17 {movhi} (nil)
> (expr_list:REG_DEAD (reg:DI 30 [ ])
> (nil)))
> (insn 436 435 442 6 ../../gcc/libgcc2.c:520 (set (reg/f:HI 5 R[5] [+6 ])
> (mem/s/c:HI (reg/f:HI 198) [0+2 S2 A16])) 17 {movhi} (nil)
> (expr_list:REG_DEAD (reg/f:HI 198)
> (nil)))
> (insn 442 436 0 6 ../../gcc/libgcc2.c:520 (use (reg/i:DI 2 R[2])) -1
> (insn_list:REG_DEP_TRUE 433 (nil))
> (nil))
> ;; End of basic block 6, registers live:
> 2 [R[2]] 3 [R[3]] 4 [R[4]] 5 [R[5]] 6 [BP] 7 [SP]
> -
Oh, interesting, you're trying to return a 64-bit result in 4 16-bit
registers. While I think it ought to work, you might at least be able to get
your compile going by telling GCC to return the value in memory instead.
I don't recall exactly how this is done - my i8086 backend returns anything
larger than 32 bits in memory - but see
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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't see any mounts you create with MSYS. Ross Ridge
is libssp native only?
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 just makes it more obvious where the problems are, but doesn't actually fix anything. I had "fixed" m32c to work around this, but I'm beginning to think that libssp is Just Plain Wrong here, because I'm tripping over it with sh-elf now too.
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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 a native Win32 application and
can't see any mounts you create with MSYS.
sorry but you're most definitely wrong about that.
[EMAIL PROTECTED] /e
$ cat /usr/local/test/test.c
#include
int main(int argc, char **argv) {
printf(argv[0]);
return 0;
}
[EMAIL PROTECTED] /e
$ gcc -v
Reading specs from e:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--disable-nls --enable-languages=c,c++,f77,ada,objc,java
--disable-win32-registry --disable-shared --enable-sjlj-exceptions
--enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
[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 windows executables.
Dave
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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, which is not a native Win32 application. The "toolchain relocation" code in MinGW GCC is unaffected by MSYS mounts you might create, and so providing "a mount point identical to the configured prefix" won't have any effect. Ross Ridge
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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 windows executables. No, you've actually just proved Ross' point correct. Gcc being a native win32 app gets the actual win32 path, not any kind of posix path that might be adjusted for MSYS mounts. If you took the above testcase and mounted /usr/local/test as /foobar and then ran /foobar/test.exe you would get identical output, E:\msys\local\test\test.exe, because that is the actual path to the binary. In other words, native win32 binaries are completely oblivious to any mounts created in MSYS, so using mounts is not a viable workaround since only MSYS apps will see a distinction. Brian
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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 have an effect on the MSYS shell, which is not a native Win32 application. The "toolchain relocation" code in MinGW GCC is unaffected by MSYS mounts you might create, and so providing "a mount point identical to the configured prefix" won't have any effect. oops, that'll teach me to think a bit more before posting :) I'm totally at a loss to explain the problems Ranjit was experiencing in this mail then. http://gcc.gnu.org/ml/gcc/2006-04/msg00247.html the part where he says " when run from within the MSYS environment, everything was hunky-dory but when run from the Windows command prompt, it used to give a "_spawnvp: No such file or directory" error when one tried to compile something." I can't say I've encountered that one locally but one of my users had this issue with win98. Dave
Re: adding nodes in a tree --(about function name mangling)
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 the RHS of a MODIFY_EXPR.
The following code will give you *all* the CALL_EXPR statements in a
function.
block_stmt_iterator bsi;
basic_block bb;
FOR_EACH_BB (bb)
{
for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
{
tree stmt = bsi_stmt (bsi);
if (TREE_CODE (stmt) == CALL_EXPR
|| (TREE_CODE (stmt) == MODIFY_EXPR && TREE_CODE (TREE_OPERAND
(stmt, 1) == CALL_EXPR))
{
/* Do your thing, make sure to use BSI_SAME flags so that
iteration will move properly. */
}
}
}
How can we get the rule of name mangling in GCC frontend?
For example, the sysbol name for foo in C is still "foo", but the sysmbol
name for foo in C++ (output of g++) is something like "_Z3foov". Futhermore,
symbol name foo in fortran is "_foo".
If I want to instrument mpi calls in a program, the three languages synopsis
(c, c++, fortran) are different.
e.g. mpi_bsend has three interface:
C++: void MPI::Comm::Bsend; C: MPI_Bsend; Fortran: MPI_BSEND
I want to insert the instrumentation code no matter from what language the
MPI subroutines are called.
I think I can take care of C and Fortran by the following (psuedo) code, but
how can i find the rule for c++ name mangling? are there many cases that I
need take care of?
if (TREE_CODE ( t ) == FUNCTION_DECL){
if (( !strncmp (IDENTIFIER_POINTER(DECL_NAME (t) , "mpi_", 4) || (
!strncmp (IDENTIFIER_POINTER(DECL_NAME (t) , "_mpi_", 5)) {
//(1) handles case of C language; (2) handle the case of Fortran
}
}
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
