Re: Design a microcontroller for gcc
Hans-Peter Nilsson wrote: > On Thu, 16 Feb 2006, Sylvain Munaut wrote: > >>Move/Load/Store without flag is no problem. But for add, to allow >>multiword add, carry is needed and I can't make it optionnal. > > > As I hinted, perhaps you can have the multiword carry a separate > one from the flags carry, perhaps moved over with a separate > instruction? Yes, two set of flags look good. One for arith operations (shift thru carry, multiword add, ...) and the other only for compare operations. With either a bit to select which set of flag to use during conditionnal jumps or a way to copy one set into the other (I'll see what's the easier to implement, but i'd like the first possibility better). >>Also, I could make the address given a word address or a byte address >>(but then I would just drop the LSB since i don't support unaligned >>access ... and the immediate in load/store would be each even between >>-32 and 30). > > Stick with byte addresses. Really, really really. Word > addresses used to be somehow supported, but there are many bugs > and no other working port does it. Having the imm4 be bits 5..1 > and bit 0 constant 0 is certainly the right thing to do for > 16-bit-wide accesses. Ok, so be it then. Sylvain
Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00
Mark Mitchell wrote: > > Mark, is it ok for Olivier to apply the patch mentioned here on > > 4.1? > Yes, thanks. I have been away for a couple of days and see that the patch has been committed to the various branches. Thanks :)
Re: [RFH] Fixing -fsection-anchors on powerpc-darwin
Andrew Pinski <[EMAIL PROTECTED]> writes: > Now I run into another problem: > /Users/pinskia/src/gcc/local/gcc/objdir.objc/./prev-gcc/xgcc > -B/Users/pinskia/src/gcc/local/gcc/objdir.objc/./prev-gcc/ > -B/Volumes/temp/gcc/local.objc/powerpc-apple-darwin7.9.0/bin/ -c -g > -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long > -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition > -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. > -I. -I/Users/pinskia/src/gcc/local/gcc/gcc > -I/Users/pinskia/src/gcc/local/gcc/gcc/. > -I/Users/pinskia/src/gcc/local/gcc/gcc/../include -I./../intl > -I/Users/pinskia/src/gcc/local/gcc/gcc/../libcpp/include > -I/Users/pinskia/src/gcc/local/gcc/gcc/../libdecnumber > -I../libdecnumber-I. -I. -I/Users/pinskia/src/gcc/local/gcc/gcc > -I/Users/pinskia/src/gcc/local/gcc/gcc/. > -I/Users/pinskia/src/gcc/local/gcc/gcc/../include -I./../intl > -I/Users/pinskia/src/gcc/local/gcc/gcc/../libcpp/include > -I/Users/pinskia/src/gcc/local/gcc/gcc/../libdecnumber > -I../libdecnumber > /Users/pinskia/src/gcc/local/gcc/gcc/config/host-darwin.c > /var/tmp//ccBWaqmT.s:130:Fixup of 1073745640 too large for field width > of 26 bits Heh, that's quite some stress test ;) It sounds like you know what needs be changed, but out of interest, what are these fixups against? An address of the form "anchor + big_offset"? If so, why is the address in memory, and what does it look like without section anchors? Could you send me the -fno-section-anchors and -fsection-anchors versions of the .s file? I just want to make sure that -fsection-anchors is doing what I expected in this case. > PS Attached is my current patch: Looks good to me FWIW. Richard
Re: GCC 4.1.0 RC1
Mark Mitchell wrote: > Please download, build, and test. Please use these tarballs, rather > than the current SVN branch, so that we test packaging, and other > similar issues. Here it looks good so far on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01036.html Regards Greg
Fwd: trees: function declaration
No help? :-)
BTW Is there any documenation on machine?
I am looking at this one:
http://www.mhatt.aps.anl.gov/dohn/programming/gcc/gccint.html#SEC_Top
it might have been something else?
Thank you.
- Forwarded message from [EMAIL PROTECTED] -
Date: Wed, 08 Feb 2006 08:02:20 -0600
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: trees: function declaration
To: GCC Development
Gentlemen.
I need some kind of assistance. I am trying to substitute function name during
the compilation procedure.
In order to do that I am:
1. creating new identifier with my name, like this:
t = get_identifier("Myfuction__ml_stub");
2. setting this name:
DECL_NAME(funcition) = t;
function is the parameter of build_function_call (tree function, tree params)
3. changing assembler name:
SET_DECL_ASSEMBLER_NAME(funcition, t);
What I have:
My sample app:
#include
extern int Myfunction();
/*
int Myfunction()
{
printf("asd");
}
*/
int main()
{
Myfunction();
return 0;
}
in case the body of Myfunction is commented out, everything looks fine:
the dump:
@1 function_declname: @2 mngl: @3 type: @4
srcp: test.c:3undefined
extern
@2 string_cst strg: myfunction__ml_stub lngt: 20
@3 identifier_node strg: myfunction__ml_stub lngt: 19
@4 function_typesize: @5 algn: 8retn: @6
@5 integer_cst type: @7 low : 8
@6 integer_type name: @8 size: @9 algn: 32
prec: 32 min : @10 max : @11
@7 integer_type name: @12 unql: @13 size: @14
algn: 64 prec: 36 unsigned
min : @15 max : @16
@8 type_declname: @17 type: @6 srcp: :0
@9 integer_cst type: @7 low : 32
@10 integer_cst type: @6 high: -1 low : -2147483648
@11 integer_cst type: @6 low : 2147483647
@12 identifier_node strg: bit_size_type lngt: 13
@13 integer_type name: @12 size: @14 algn: 64
prec: 36
@14 integer_cst type: @7 low : 64
@15 integer_cst type: @7 low : 0
@16 integer_cst type: @7 high: 15 low : -1
@17 identifier_node strg: int lngt: 3
asm:
.file "test.c"
.text
.globl main
.type main, @function
main:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
andl$-16, %esp
movl$0, %eax
addl$15, %eax
addl$15, %eax
shrl$4, %eax
sall$4, %eax
subl%eax, %esp
callMyfunction__ml_stub
movl$0, %eax
leave
ret
.size main, .-main
.ident "GCC: (GNU) 4.0.2"
.section.note.GNU-stack,"",@progbits
so it works.
yet when the function body is not commented:
#include
extern int Myfunction();
int Myfunction()
{
printf("asd");
}
int main()
{
Myfunction();
return 0;
}
I have:
@1 function_declname: @2 type: @3 srcp: stdio.h:0
undefined extern
@2 identifier_node strg: printf__ml_stub lngt: 15
@3 function_typesize: @4 algn: 8retn: @5
prms: @6
@4 integer_cst type: @7 low : 8
@5 integer_type name: @8 size: @9 algn: 32
prec: 32 min : @10 max : @11
@6 tree_listvalu: @12
@7 integer_type name: @13 unql: @14 size: @15
algn: 64 prec: 36 unsigned
min : @16 max : @17
@8 type_declname: @18 type: @5 srcp: :0
@9 integer_cst type: @7 low : 32
@10 integer_cst type: @5 high: -1 low : -2147483648
@11 integer_cst type: @5 low : 2147483647
@12 pointer_type qual: r unql: @19 size: @9
algn: 32 ptd : @20
@13 identifier_node strg: bit_size_type lngt: 13
@14 integer_type name: @13 size: @15 algn: 64
prec: 36
@15 integer_cst type: @7 low : 64
@16 integer_cst type: @7 low : 0
@17 integer_cst type: @7 high: 15 low : -1
@18 identifier_node strg: int lngt: 3
@19 pointer_type size: @9 algn: 32 ptd : @20
@20 integer_type qual: cname: @21 unql: @22
size: @4 algn: 8prec: 8
min : @23 max : @24
@21 type_declname: @25 type: @22 srcp: :0
@22 integer_type name: @21 size: @4 algn: 8
prec: 8min : @23 max : @24
@2
Re: gcc build / test times on multi-core hosts?
Andrew Haley wrote: As a comparison point, I get real73m39.275s user113m19.549s sys 15m26.010s for the bootstrap: that's 1h14 elapsed time. That's on a "AMD Athlon(tm) 64 X2 Dual Core Processor 4800+" (2.4 GHz) with make -j3. That's 129min of CPU time in 74min of elapsed time, a pretty good processor utilization ratio of 1.75 : 2. Is that using the i686 or amd64 instruction set? If the latter, does it use 32 or 64 bit pointers? How much RAM dos this machine have, and how fast is it? Has anybody any figures what impact the choice of CAS 2 / CAS 2.5 / CAS3 NON-ECC / ECC memory has on system performance when doing gcc builds / regression tests?
Re: gcc build / test times on multi-core hosts?
Joern RENNECKE writes: > Andrew Haley wrote: > > > > >As a comparison point, I get > > > >real73m39.275s > >user113m19.549s > >sys 15m26.010s > > > >for the bootstrap: that's 1h14 elapsed time. That's on a "AMD > >Athlon(tm) 64 X2 Dual Core Processor 4800+" (2.4 GHz) with make -j3. > >That's 129min of CPU time in 74min of elapsed time, a pretty good > >processor utilization ratio of 1.75 : 2. > > > > > Is that using the i686 or amd64 instruction set? If the latter, does it > use 32 or 64 bit pointers? The latter. Yes. > How much RAM dos this machine have, and how fast is it? 2G. DDR400 3-3-3-8 (TWINX2048-3200PRO) This RAM also has flashing LEDs to make it go faster. (Something to do with photonics, I think.) Andrew.
Re: gcc build / test times on multi-core hosts?
Andrew Haley wrote: > Is that using the i686 or amd64 instruction set? If the latter, does it > use 32 or 64 bit pointers? The latter. Yes. So which pointer size does the host compiler use, and which pointer size is used in the gcc that is bootstrapped? This RAM also has flashing LEDs to make it go faster. (Something to do with photonics, I think.) :-)
Re: gcc build / test times on multi-core hosts?
Joern RENNECKE writes: > Andrew Haley wrote: > > > > Is that using the i686 or amd64 instruction set? If the latter, does it > > > use 32 or 64 bit pointers? > > > >The latter. Yes. > > > > > So which pointer size does the host compiler use, and which pointer size > is used in > the gcc that is bootstrapped? 64. 64. Andrew.
Re: Upated memory hog patch for make
On Wed, 1 Feb 2006, H. J. Lu wrote: > My memory hog patch for make has 2 typos. This patch fixes them. Thanks, H. J. What's the upstream status of your patches? Did you submit your updated patch there as well? (As long as this patch, or a similar change, has not become part of a released version of GNU make, some distributions like SUSE will carry your patch and thus reduce the overall pain point to address the problem in libgcj itself, whereas many users will still run into the problem.) Gerald
.cvsignore in libjava/classpath
In libjava/classpath there are two .cvsignore files which haven't been deleted yet: native/jni/midi-alsa/.cvsignore native/jni/midi-dssi/.cvsignore Should they go, too? They are also in GCC 4.1.0 RC1. Regards, Volker
Re: .cvsignore in libjava/classpath
> > In libjava/classpath there are two .cvsignore files which haven't been > deleted yet: > > native/jni/midi-alsa/.cvsignore > native/jni/midi-dssi/.cvsignore > > Should they go, too? > They are also in GCC 4.1.0 RC1. They are imported from upstream :). -- Pinski
software floating point host triplet?
Hello, I have the interesting and somewhat taunting task of providing a toolchain that assumes -msoft-float unless told otherwise. Obviously, this can be arranged with appropriate changes to the specs, however I'd like to integrate this in a way that would benefit everybody. The general idea would be to have a common header file defining specs fragments for FP handling for the "arch does not have any FP at all" and the "arch has optional FP" cases, which can be included by the arch-specific headers (those archs with differing FP implementations, i.e. those that not only differentiate between "hard" and "soft" will still need special handling in their respective subdirs). For that to work, there should be a sane way to specify soft FP, either in the host triplet (but I haven't found a non-ugly way to do this; for example arm920t-linux-gcc could very well compile code for the arm926 core, although its name would probably suggest otherwise), or as a configure option (which would mean that there can be compilers with different defaults for the same host triplet), so I would be interested in opinions on how a user could indicate the request for soft fp as default. That is phase 1. Phase 3 is profit. Simon signature.asc Description: OpenPGP digital signature
Re: software floating point host triplet?
On Mon, Feb 20, 2006 at 06:54:07PM +0100, Simon Richter wrote: > Hello, > > I have the interesting and somewhat taunting task of providing a > toolchain that assumes -msoft-float unless told otherwise. Obviously, > this can be arranged with appropriate changes to the specs, however I'd > like to integrate this in a way that would benefit everybody. Have you tried --with-float=soft, which works on several different architectures already? -- Daniel Jacobowitz CodeSourcery
Re: .cvsignore in libjava/classpath
Andrew Pinski writes: > > > > In libjava/classpath there are two .cvsignore files which haven't been > > deleted yet: > > > > native/jni/midi-alsa/.cvsignore > > native/jni/midi-dssi/.cvsignore > > > > Should they go, too? > > They are also in GCC 4.1.0 RC1. > > They are imported from upstream :). Yeah. Don't delete *anything* in libjava/classpath: instead go to :ext:cvs.savannah.gnu.org:/sources/classpath. Andrew.
RE: GCC 4.1.0 RC1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bootstrap failure in libjava on ia64-unknown-linux-gnu. Failure in building jv-convert: /bin/sh ./libtool --tag=GCJ --mode=link /disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/gcc/gcj - -B/disk1/SCRATCH/gcc-build/Linux/ia64-unknown - -linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/ia64-unknown-linux-gnu/libjava/ - -B/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/gcc/ - -L/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/ia64-unknown-linux-gnu/libjava - -funwind-tables -g -O2 -o jv-convert --main=gnu.gcj.convert.Convert -rpath /SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/lib -shared-libgcc - -L/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/ia64-unknown-linux-gnu/libjava/.libs libgcj.la /disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/gcc/gcj - -B/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/ia64-unknown-linux-gnu/libjava/ - -B/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/gcc/ - -funwind-tables -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert - -shared-libgcc - -L/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/ia64-unknown-linux-gnu/libjava - -L/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/ia64-unknown-linux-gnu/libjava/.libs ./.libs/libgcj.so - -L/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/ia64-unknown-linux-gnu/libstdc++-v3/src - -L/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/ia64-unknown-linux-gnu/libstdc++-v3/src/ .libs -lpthread -ldl - -L/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/./gcc - -L/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/ia64-unknown-linux-gnu/bin - -L/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/ia64-unknown-linux-gnu/lib - -L/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/lib/../ia64-unknown-linux-gnu/lib - -L/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/lib -lgcc_s -lunwind - -lc -lgcc_s -lunwind -Wl,--rpath - -Wl,/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/lib /SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/ld: unrecognized option '-Wl,-rpath' /SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status gmake[4]: *** [jv-convert] Error 1 gmake[4]: Leaving directory `/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.0-RC1/gcc-4.1.0-RC1/ia64-unknown-linux-gnu/libjava' configure options: /raid/tecosim/it/devel/projects/develtools/src/gcc-4.1.0-RC1/configure - --prefix=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install --with-gnu-as - --with-as=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/as - --with-gnu-ld - --with-ld=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/ld - --enable-threads=posix --enable-shared --enable-__cxa_atexit - --with-libiconv-prefix=/appl/shared/gnu/Linux/ia64-unknown-linux-gnu - --enable-checking=release - --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang - --with-gmp=/appl/shared/gnu/Linux/ia64-unknown-linux-gnu - --with-mpfr=/appl/shared/gnu/Linux/ia64-unknown-linux-gnu binutils-2.16.1 gcc for build gcc-4.0.2 Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD+gWS3s6elE6CYeURAjD+AJ4tVqRnwldZmNwNUq6ErI3TfzfHcwCgnrU5 MtTZ2niEp46iW3hu3YoXIf8= =FPxt -END PGP SIGNATURE-
label formats in gcc 3.4 for arm-vxworks
Hello, Working on an arm-vxworks port for Ada, we noticed that both NO_DOT_IN_LABEL and NO_DOLLAR_IN_LABEL are defined, the former from config/vxworks.h and the latter from arm/aout.h. Is it really intended this way ? NO_DOT_IN_LABEL is actually #undef'ed from config/vxworks.h, but the arm/aout.h overrules it because tm_file="... vxworks.h arm/elf.h arm/aout.h ... arm/vxworks.h" This is causing labels for nested functions to be formatted by # define ASM_PN_FORMAT "__%s_%lu" ... causing some troubles to the debugger, which fails to reconstruct the proper user level name. Before investigating possible debugger adjustments, we wanted to check whether the compiler configuration was as intented. Thanks in advance for your help, Olivier
Re: Upated memory hog patch for make
Gerald wrote: >On Wed, 1 Feb 2006, H. J. Lu wrote: >> My memory hog patch for make has 2 typos. This patch fixes them. >Thanks, H. J. What's the upstream status of your patches? I think they're in upstream (hopefully H.J. will confirm that). I know that the O(N^2) bug that Jeff Evarts found and fixed is in upstream. If you want to try, there's a release candidate out now: > From: [EMAIL PROTECTED] > Sent: 20 February 2006 04:25 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: GNU make 3.81rc1 released -- please test. > > Please find the first release candidate for GNU make 3.81, 3.81rc1, > available now for download from ftp://alpha.gnu.org/gnu/make: > > c907a044ebe7dff19f56f8dbb829cd3f > ftp://alpha.gnu.org/gnu/make/make-3.81rc1.tar.bz2 - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Upated memory hog patch for make
On Mon, Feb 20, 2006 at 10:51:13AM -0800, Dan Kegel wrote: > Gerald wrote: > >On Wed, 1 Feb 2006, H. J. Lu wrote: > >> My memory hog patch for make has 2 typos. This patch fixes them. > >Thanks, H. J. What's the upstream status of your patches? > > I think they're in upstream (hopefully H.J. will confirm that). > I know that the O(N^2) bug that Jeff Evarts found and fixed > is in upstream. > > > Sent: 20 February 2006 04:25 > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: GNU make 3.81rc1 released -- please test. > > > > Please find the first release candidate for GNU make 3.81, 3.81rc1, > > available now for download from ftp://alpha.gnu.org/gnu/make: > > > > c907a044ebe7dff19f56f8dbb829cd3f > > ftp://alpha.gnu.org/gnu/make/make-3.81rc1.tar.bz2 3.81rc1 works much better than 3.80. But my patch for 3.80 no longer applies cleanly. Paul is aware of the libjava build problem and is working on it. H.J.
Re: gcc build / test times on multi-core hosts?
DJ Delorie wrote: There's not much difference between multi-core and multi-cpu, and I've been building multi-cpu for years. Some multi-core processors come with less L2 cache than their multi-CPU counterparts. Also, multi-cpu itself comes in different varieties, with Intels Xeons going for the classic SMP design with a single shared memory bus providing uniform memory access (UMA), but also a causing a bootleneck as you add more processors; whereas the Opterons have non-uniform memory access (NUMA), with each processor having separate memory busses. So theat removes the bottleneck of a shared memory bus, but the operating system must allocate most memory locally to each CPU to avoid a bottleneck in the cross-connect of the processors. The Athlon X2 and Opteron dual core processors use internally a cross-bar switch to connect the two cores to the memory and inter-processor interconnect, so they have slightly higher memory latencies, but better communication between the two cores inside the processor and the attached memory than between separate Opterons processors with their attached memory. I wonder: what does the Linux (or insert your favourite BSD here) kernel do with dual-core Opterons? Does it keep processor-affinity for physical memory local to the two cores it is attached to? Dual processor Dual-core Opterons seem like a very cost effective way to get a 4-way machine, and two cores each share two memory busses (if the memory is appropriately installed), so memory bandwidth should also be good. But is there a penalty to pay because this machine is not quite classical SMP nor quite NUMA? If the kernel pretends it's a fully NUMA machine, that would halve the local memory available per CPU - i.e. builds that see largely assymetric memory usage could get slower, since when the kernel runs out of what it thinks is the memory local to one core, it has a good chance (2/3 if you assume random distribution) of grabbing memory that is indeed not local to that core. If it pretends the machine is a classic SMP machine with uniform memory access, it's even worse, since then irrespective of the size of the working set, it will tend to grab memory from the wrong place half of the time. At a previous job where we were very interested in build times, our rule of thumb was N+1 jobs for N cpus with local disk, or 2N+1 jobs for N cpus with nfs-mounted disk. That was for build farms working on a 12 hour C++ compile. Was that UMA or NUMA, and how far up could you scale N usefully? Do you know if software RAID (not so much R as A of ID) is effective at avoiding I/O bottlenecks, e.g. will two disks for four cores work as well as one disk for two?
Re: Name mangling issue with HP, Sun, Tru64 UNIX C++ but not GCC
On Wed, Feb 01, 2006 at 01:21:03PM -0500, Andrew Pinski wrote:
> >
> > We ran into a problem building KDE on HP-UX 11.23/IA with the HP C++
> > compiler. The compiler mangled a function name in a .cpp file though
> > it was declared extern "C" in the .h file. After a post to the HP C++
> > developers list, we were told this behavior is correct. GCC 4.0.2 does
> > not do this so I'd like to get your opinion.
> >
> > $ cat mangle-1.cc
> > typedef enum {
> > XSLDBG_MSG_THREAD_NOTUSED,
> > XSLDBG_MSG_THREAD_INIT
> > } XsldbgMessageEnum;
> >
> > extern "C" {
> > void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
> > const void *data));
> > }
> >
> > static int (*notifyXsldbgAppFuncPtr) (XsldbgMessageEnum type,
> > const void *data) = 0;
> >
> > void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
> >const void *data))
> > {
> > notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
> > }
>
> This is most likely very related to PR 2316 where GCC does not use language
> as the overloaded part.
Is there some place in the C++ standard I can look up to determine
what the correct behavior for the above code should be?
--
albert chin ([EMAIL PROTECTED])
Re: Extended Asm Constraint problem (probably missing feature)
On Feb 17, 2006, at 8:04 PM, Serge Dundich wrote:
I need to define the constant memory address/offset in i386 gcc
inline asm,
i.e. immediate value without $ prefix, so I can use it as a
constant offset for
some memory address statement.
Is there any way to do that?
Sure, the manual describes how do this and other neat things...
Roughly:
void foo() {
register char *ebx asm ("%ebx");
register int esi asm ("%esi");
asm ("blabla %0" : : "m" (*(ebx+esi+23)));
}
I think you're working to hard to constrain gcc, you don't have to do
that. Instead, pull it up into the C layer and just use it. It can
and will optimize as appropriate. If you have a specific question on
how to make something happen where writing it higher doesn't work,
ask that specific question.
PS: I wasn't sure what mailing list this message is the most
appropriate for.
So I posted it both here and in "gcc-help".
Please don't do that, it is always wrong to do that. gcc-help is a
list for people that need help using gcc. gcc is a list for people
writing gcc.
Now, if you really, really must do this:
#define S(s) #s
void foo() {
asm ("blabla " S(12));
}
is another way to do this.
Re: gcc build / test times on multi-core hosts?
On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote: > the bottleneck of a shared memory bus, but the operating system must > allocate > most memory locally to each CPU to avoid a bottleneck in the cross-connect > of the processors. > Linux kernel 2.6.16-rc1 and above supports percpu_pagelist_fraction This is the fraction of pages at most (high mark pcp->high) in each zone that are allocated for each per cpu page list. The min value for this is 8. It means that we don't allow more than 1/8th of pages in each zone to be allocated in any single per_cpu_pagelist. This entry only changes the value of hot per cpu pagelists. User can specify a number like 100 to allocate 1/100th of each zone to each per cpu page list. The batch value of each per cpu pagelist is also updated as a result. It is set to pcp->high/4. The upper limit of batch is (PAGE_SHIFT * 8) The initial value is zero. Kernel does not use this value at boot time to set the high water marks for each per cpu page list. The optimal percpu_pagelist_fraction value depends on your configuation. H.J.
Re: gcc build / test times on multi-core hosts?
H. J. Lu wrote: On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote: the bottleneck of a shared memory bus, but the operating system must allocate most memory locally to each CPU to avoid a bottleneck in the cross-connect of the processors. Linux kernel 2.6.16-rc1 and above supports percpu_pagelist_fraction Is this per cpu (which might contain multiple cores) or per core? This is the fraction of pages at most (high mark pcp->high) in each zone that are allocated for each per cpu page list. The min value for this is 8. It means that we don't allow more than 1/8th of pages in each zone to be allocated in any single per_cpu_pagelist. Do I understand this correctly that in a dual opteron single core system with 2 GB memory, only up to 256 MB per processor could be specifically allocated in local memory? Whereas in an 8-way opteron machine with equal amounts of memory attached to each processor, all the local memory could be allocated to its processor?
Re: gcc build / test times on multi-core hosts?
Laurent GUERBY wrote: On a Pentium III 1GHz, bootstrap is 5h55 and check 5h30 (on an older version of the tree), Was this before top-level bootstrap?
Re: gcc build / test times on multi-core hosts?
On Mon, Feb 20, 2006 at 07:58:35PM +, Joern RENNECKE wrote: > H. J. Lu wrote: > > >On Mon, Feb 20, 2006 at 07:30:41PM +, Joern RENNECKE wrote: > > > > > >>the bottleneck of a shared memory bus, but the operating system must > >>allocate > >>most memory locally to each CPU to avoid a bottleneck in the > >>cross-connect > >>of the processors. > >> > >> > >> > > > >Linux kernel 2.6.16-rc1 and above supports > > > >percpu_pagelist_fraction > > > > > Is this per cpu (which might contain multiple cores) or per core? I think it is per core. But I don't know if a HT cpu counts here or not. > > >This is the fraction of pages at most (high mark pcp->high) in each zone > >that > >are allocated for each per cpu page list. The min value for this is 8. > >It > >means that we don't allow more than 1/8th of pages in each zone to be > >allocated in any single per_cpu_pagelist. > > > Do I understand this correctly that in a dual opteron single core system > with 2 GB > memory, only up to 256 MB per processor could be specifically allocated > in local > memory? > Whereas in an 8-way opteron machine with equal amounts of memory > attached to each > processor, all the local memory could be allocated to its processor? I don't know the answer. You may ask it on the Linux kernel mailing list. H.J.
Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)
On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote: > On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote: > > "Second, for a given integer type (such as > > natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE > > and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647. > > ie, the type of an integer constant should be the same as the type of > > its min/max values." > > > > No, the type of the bounds of a subtype should be the *base type*. That's > > how the tree has always looked, as far back as I can remember. > > This is because intermediate computations can produce results > outside the subtype range but within the base type range (RM 3.5(6)), > right? > > type T1 is range 0 .. 127; > -- Compiler will choose some type for T'Base, likely to be -128..127 > -- but could be Integer (implementation dependant) > subtype T is T1 range 0 .. 100; > R : T := 100+X-X; > -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First Which leaves us with a very fundamental issue. Namely that we can not use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges. That's lame, incredibly lame. This nonsense really should be isolated within the Ada front-end. In the mean time, what is the safe way to determine the full set of values any particular object may have, taking into consideration this Ada braindamage? jeff
Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)
On 2/20/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote: > On Sun, 2006-02-19 at 20:43 +0100, Laurent GUERBY wrote: > > On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote: > > > "Second, for a given integer type (such as > > > natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE > > > and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647. > > > ie, the type of an integer constant should be the same as the type of > > > its min/max values." > > > > > > No, the type of the bounds of a subtype should be the *base type*. That's > > > how the tree has always looked, as far back as I can remember. > > > > This is because intermediate computations can produce results > > outside the subtype range but within the base type range (RM 3.5(6)), > > right? > > > > type T1 is range 0 .. 127; > > -- Compiler will choose some type for T'Base, likely to be -128..127 > > -- but could be Integer (implementation dependant) > > subtype T is T1 range 0 .. 100; > > R : T := 100+X-X; > > -- guaranteed work as long 100+X<=T'Base'Last and 100-X>=T'Base'First > Which leaves us with a very fundamental issue. Namely that we can not > use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges. That's lame, > incredibly lame. This nonsense really should be isolated within the > Ada front-end. Indeed. Ada should in this case generate R = (T)( (basetype)100 + (basetype)X - (basetype)X ) i.e. carry out all arithmetic explicitly in the basetype and only for stores and loads use the subtype. Otherwise we might as well get rid of TYPE_MIN_VALUE and TYPE_MAX_VALUE (for Ada). Richard.
Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)
Which leaves us with a very fundamental issue. Namely that we can not use TYPE_MIN_VALUE or TYPE_MAX_VALUE for ranges. The point is that it *is* supposed to be usable in general. If it can't be used in a specific case, let's address that specific case and understand what needs fixing. The intent is for it to be useful and usable information..
Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)
Indeed. Ada should in this case generate R = (T)( (basetype)100 + (basetype)X - (basetype)X ) i.e. carry out all arithmetic explicitly in the basetype and only for stores and loads use the subtype. That is indeed required by the language and what is normally generated. It would be valuable to see exactly who generated the bogus operation.
Re: gcc build / test times on multi-core hosts?
> Some multi-core processors come with less L2 cache than their multi-CPU > counterparts. This, and your other arguments, while valid, apply independently of the CPU. There are a lot of factors that determine compile speed. FYI SGIs tend to have crossbars. > Was that UMA or NUMA, and how far up could you scale N usefully? UMA I think. We generally had just 1 and 2 CPU machines. > Do you know if software RAID (not so much R as A of ID) is effective > at avoiding I/O bottlenecks, e.g. will two disks for four cores work > as well as one disk for two? Disk is so much slower that CPU that I don't think it matters. Software RAID is already faster than hardware RAID for common uniprocessor systems, assuming you don't introduce I/O bottlenecks (like 33MHz PCI bus). For example, my server here is a dual opteron, with an 8-sata controller. It works because the PCI bus is a 133MHz 64 bit bus, which I calculated was sufficient to host all eight drives. I was able to benchmark a 7-disk RAID array at 250MB/s sustained.
Re: Ada subtypes and base types (was: Bootstrap failure on trunk: x86_64-linux-gnu)
On 2/20/06, Richard Kenner <[EMAIL PROTECTED]> wrote: > Indeed. Ada should in this case generate > >R = (T)( (basetype)100 + (basetype)X - (basetype)X ) > > i.e. carry out all arithmetic explicitly in the basetype and only for > stores and loads use the subtype. > > That is indeed required by the language and what is normally generated. > It would be valuable to see exactly who generated the bogus operation. > Indeed - I can very well imagine fold or ccp stripping off such type conversions in some case, which would lead to wrong code by VRP. Richard.
Re: GCC 4.1.0 RC1
On Mon, 2006-02-20 at 19:40 +1100, Greg Schafer wrote: > Mark Mitchell wrote: > > > Please download, build, and test. Please use these tarballs, rather > > than the current SVN branch, so that we test packaging, and other > > similar issues. > > Here it looks good so far on i686-pc-linux-gnu > > http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01036.html Ada is clear as well on x86 and amd64-linux: x86 http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01086.html amd64 http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01085.html But I have lots of libmudflag failures you aren't seeing and one libstdc++ amd64 FAIL: FAIL: abi_check Any idea of what I'm doing wrong? I'm not alone it seems: http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01089.html also has tons of libmudflap FAIL. Laurent
Re: GCC 4.1.0 RC1
On Feb 20, 2006, at 6:30 PM, Laurent GUERBY wrote: one libstdc++ amd64 FAIL: FAIL: abi_check That is because you did not supply --enable-__cxa_atexit to configure. This has been mentioned so many times it might as well enabled it by default for GNU/Linux. -- Pinski
Re: GCC 4.1.0 RC1
Mark Mitchell wrote: > GCC 4.1.0 RC1 is here: > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060219 Looking fine on s390-ibm-linux and s390x-ibm-linux: http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01094.html http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01095.html except for the recently introduced test case FAIL: gcc.dg/20060218-1.c (test for errors, line 6) FAIL: gcc.dg/20060218-1.c (test for excess errors) which is failing because of the issue you mention here: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01577.html It would be nice if this were fixed, but as this is simply a broken test case it's just a cosmetic issue at this point ... Bye, Ulrich -- Dr. Ulrich Weigand Linux on zSeries Development [EMAIL PROTECTED]
Re: GCC 4.1.0 RC1
On Mon, 2006-02-20 at 18:34 -0500, Andrew Pinski wrote: > On Feb 20, 2006, at 6:30 PM, Laurent GUERBY wrote: > > > one libstdc++ amd64 FAIL: > > > > FAIL: abi_check > > That is because you did not supply --enable-__cxa_atexit > to configure. This has been mentioned so many times it > might as well enabled it by default for GNU/Linux. I did supply it: configure flags: --prefix=/home/guerby/tmp/install --enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib --enable-languages=c,ada,c++,fortran,java,objc,treelang Laurent
Re: GCC 4.1.0 RC1
> http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01095.html FAIL: cc1010b Artifact or real failure? -- Eric Botcazou
Re: GCC 4.1.0 RC1
Eric Botcazou <[EMAIL PROTECTED]> wrote on 21.02.2006 01:10:58: > > http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01095.html > > FAIL: cc1010b > > Artifact or real failure? One of the usual artifacts ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand GNU compiler/toolchain for Linux on zSeries and Cell IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED]
Re: GCC 4.1.0 RC1
> One of the usual artifacts ... Thanks. I've personally got them on Linux only, never ever on Solaris. -- Eric Botcazou
Build failed on trunk
[EMAIL PROTECTED] trunk]$ ../trunk/configure --enable-languages=c,fortran
--prefix=/home/wf/local
[EMAIL PROTECTED] trunk]$ make
[snip]
make[3]: Entering directory `/home/wf/svngcc/trunkbld/libiberty'
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -g -I. -I../../trunk/libiberty/../include -W -Wall
-pe
dantic -Wwrite-strings -Wstrict-prototypes ../../trunk/libiberty/pexecute.c -o
pic/pexecute.o; \
else true; fi
gcc -c -DHAVE_CONFIG_H -g -I. -I../../trunk/libiberty/../include -W -Wall
-peda
ntic -Wwrite-strings -Wstrict-prototypes ../../trunk/libiberty/pexecute.c -o
pex
ecute.o
../../trunk/libiberty/pexecute.c: In function `pwait':
../../trunk/libiberty/pexecute.c:106: parse error before "return"
make[3]: *** [pexecute.o] Error 1
make[3]: Leaving directory `/home/wf/svngcc/trunkbld/libiberty'
make[2]: *** [all-stage1-libiberty] Error 2
make[2]: Leaving directory `/home/wf/svngcc/trunkbld'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/wf/svngcc/trunkbld'
make: *** [all] Error 2
I think this is caused by a typos error in libiberty/pexecute.c. Doesn't anyone
else see it?
The patch:
Index: libiberty/pexecute.c
===
--- libiberty/pexecute.c(revision 111325)
+++ libiberty/pexecute.c(working copy)
@@ -102,7 +102,7 @@ pwait (int pid, int *status, int flags A
vector = XNEWVEC (int, idx);
if (!pex_get_status (pex, idx, vector))
{
- free (vector)
+ free (vector);
return -1;
}
*status = vector[pid];
Best Regards,
Feng Wang
--
Creative Compiler Research Group,
National University of Defense Technology, China.
___
雅虎1G免费邮箱百分百防垃圾信
http://cn.mail.yahoo.com/
Re: Build failed on trunk
> I think this is caused by a typos error in libiberty/pexecute.c. Doesn't > anyone > else see it? Already fixed.
回复： Re: Build failed on trunk
--- DJ Delorie <[EMAIL PROTECTED]>写道: > > > I think this is caused by a typos error in libiberty/pexecute.c. Doesn't > anyone > > else see it? > > Already fixed. > OK. Thanks. Feng Wang ___ 雅虎1G免费邮箱百分百防垃圾信 http://cn.mail.yahoo.com/
gcc 4.1 RC1 and SPEC CPU 2000
Hi, I've been testing gcc-4.1 RC1 on x86-linux-gnu with SPEC CPU 2000. There are two main reasons I did this: a) gcc is used for research experimentation and many research folks rely on SPECCPU2000 b) I, in particular, need SPEC CPU 2000 to work with profile driven feedback. I provide a matrix which shows gcc-4.1-RC1 on SPECPU 2000 w/wo profile driven optimizations. I'm using -fprofile-generate for the training run compile and -fprofile-use for the profile driven compilation. I'm using -O3 for both compiles. I enclose a small matrix below of what does and what does not work: The error legend code is as follows: OK = everything works C = compilation failure C1 program source not accepted C2 gcda counter information not found error eg. cfftb.f90: In function passb5: cfftb.f90:387: note: file cfftb.gcda not found, execution counts estimated cfftf.f90: In function passf5: cfftf.f90:387: note: file cfftf.gcda not found, execution counts estimated Vt = Failure of verification of benchmarks output for `test' workload. Benchmark Plain compile Profile Driven Compile 168.wupwise Vt C2,Vt 172.mgridVt C2,Vt 177.mesaOK OK 179.art OK OK 187.facerec Vt C2,Vt 189.lucas OKC2,Vt 200.sixtrack Vt C2,Vt 171.swim Vt C2,Vt 173.applu OKC2,Vt 178.galgel C1 C1 183.equake OK OK 188.ammpOK OK 191.fma3dVt C2,Vt 301.apsi Vt C2,Vt 164.gzipOK OK 175.vpr OK OK 176.gcc C1 (reorg.c) C1 (reorg.c) 181.mcf OK OK 186.crafty OK OK 197.parser OK OK 252.eon OK OK 253.perlbmk OK OK 254.gap OK OK 255.vortex OK Vt 256.bzip2 OK OK 300.twolf OK OK I haven't tried the `ref' workloads yet. This looks a smidge grim. David.
Re: gcc 4.1 RC1 and SPEC CPU 2000
On Feb 20, 2006, at 11:54 PM, [EMAIL PROTECTED] wrote: Hi, I've been testing gcc-4.1 RC1 on x86-linux-gnu with SPEC CPU 2000. Benchmark Plain compile Profile Driven Compile 168.wupwise Vt C2,Vt 172.mgridVt C2,Vt 177.mesaOK OK 179.art OK OK 187.facerec Vt C2,Vt 189.lucas OKC2,Vt 200.sixtrack Vt C2,Vt 171.swim Vt C2,Vt 173.applu OKC2,Vt 178.galgel C1 C1 This is because galgel is written in fixed form, you have to supply -ffixed-form to the compiler. 183.equake OK OK 188.ammpOK OK 191.fma3dVt C2,Vt 301.apsi Vt C2,Vt These are all Fortran tests that are failing. Are you sure that you are not doing something wrong? Like not copying the right files? Anyways this is not enough information to go on to figure out what is going on. If you supply the .log file, it might be useful but then again it might not. Just saying they fail is going to be enough. 176.gcc C1 (reorg.c) C1 (reorg.c) You need the alliterative source for this test. Also these all work on the mainline at -O3 with no troubles and I know feedback works correctly also, at least for powerpc-linux. Thanks, Andrew Pinski
Re: gcc 4.1 RC1 and SPEC CPU 2000
On Feb 21, 2006, at 12:05 AM, Andrew Pinski wrote: You need the alliterative source for this test. s/alliterative/alternative/ -- Pinski
What is the MIPS Constraints 'c' and 'j'
Hi, While I read the mips.md, I find there are some constraints used in function call templates, such as 'c' and 'j'. But these two constraints seem not be defined and I can't find their explanation both in source files and gcc internal. Well, aren't there anywhere I missed? Otherwise, how can they work? Thanks. Eric
Re: What is the MIPS Constraints 'c' and 'j'
"Eric Fisher" <[EMAIL PROTECTED]> writes: > While I read the mips.md, I find there are some constraints used in > function call templates, such as 'c' and 'j'. But these two > constraints seem not be defined and I can't find their explanation > both in source files and gcc internal. Well, aren't there anywhere I > missed? Otherwise, how can they work? 'c' and 'j' are register classes. They are defined by REG_CLASS_FROM_LETTER, is defined to use the array mips_char_to_class, which is initialized in override_options in mips.c. 'c' is the register class used to hold the address of a function when calling a function via a register. 'j' is the register class used to hold the address of a function when calling a function using the SVR4 calling convention, aka -mabicalls. In fact 'c' and 'j' are the same register class if -mabicalls is in effect, the class PIC_FN_ADDR_REG, which contains one register, $25. Ian
Re: GCC 4.1.0 RC1
On Tue, Feb 21, 2006 at 12:45:15AM +0100, Ulrich Weigand wrote: > except for the recently introduced test case > FAIL: gcc.dg/20060218-1.c (test for errors, line 6) > FAIL: gcc.dg/20060218-1.c (test for excess errors) This one should be already fixed on gcc-4_1-branch (after RC1 was released I committed the svn mv gcc.dg/20060218-1.c gcc.target/i386/20060218-1.c change). Jakub
