RE: Trying to build crosscompiler for Sparc Solaris 8 -> SparcSolaris 10 (& others)...
Original Message >From: Aaron Gaudio >Sent: 05 April 2005 21:05 > (CCing this to [EMAIL PROTECTED] due to potential build bugs...) > I have already installed binutils 2.15 and gcc 3.4.5 native Solaris 8 > verisons in the prefix /vobs/java/gnu and added this directory to my > path, so that those are the tools being used for building the cross- > compiler environment. Two things to check: 1) Try specifying an absolute rather than relative path to the gcc configure script; I think this has been known to be a source of problems on solaris platforms in the past, but I don't know if it's still relevant now. It can't hurt to try. 2) If what you say above is *literally* correct, then the reason the wrong assembler is being found is because you've added $prefix to your $PATH, when you should have added $prefix/bin! cheers, DaveK -- Can't think of a witty .sigline today
Re: Obsoleting c4x last minute for 4.0
On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote: > Joe Buck wrote: > > > > But if it won't even build, then users should be warned. > > I suppose -- but we have relatively many configurations that probably > won't build, at least if you start combining various options, and > including langauges beyond just C and C++. > > I'd be content with a patch that issued a warning, but declaring a port > obsolete has often been contentions, and I'd hate to rush into it. Maybe we need a third category - 'at risk'. Such a port will typically have no active maintainer, some likely serious bugs and might at some future date be obsoleted if no maintainer steps forward. We could put several ports into that category and it shouldn't have the negative stigma that obsolete seems to have. R.
Re: [BUG mm] "fixed" i386 memcpy inlining buggy
On Tuesday 05 April 2005 19:34, Christophe Saout wrote:
> Hi Denis,
>
> the new i386 memcpy macro is a ticking timebomb.
>
> I've been debugging a new mISDN crash, just to find out that a memcpy
> was not inlined correctly.
>
> Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed).
>
> This source code:
>
> mISDN_pid_t pid;
> [...]
> memcpy(&st->mgr->pid, &pid, sizeof(mISDN_pid_t));
>
> was compiled as:
>
> lea0xffa4(%ebp),%esi< %esi is loaded
> ( add$0x10,%ebx )
> ( mov%ebx,%eax ) something else
> ( call 1613 ) %esi preserved
> mov0xffa0(%ebp),%edx
> mov0x74(%edx),%edi < %edi is loaded
> add$0x20,%edi offset in structure added
> ! mov$0x14,%esi!! < %esi overwritten!
> mov%esi,%ecx< %ecx loaded
> repz movsl %ds:(%esi),%es:(%edi)
>
> Apparently the compiled decided that the value 0x14 could be reused
> afterwards (which it does for an inlined memset of the same size some
> instructions below) and clobbers %esi.
>
> Looking at the macro:
>
> __asm__ __volatile__(
> ""
> : "=&D" (edi), "=&S" (esi)
> : "0" ((long) to),"1" ((long) from)
> : "memory"
> );
> }
> if (n >= 5*4) {
> /* large block: use rep prefix */
> int ecx;
> __asm__ __volatile__(
> "rep ; movsl"
> : "=&c" (ecx)
>
> it seems obvious that the compiled assumes it can reuse %esi and %edi
> for something else between the two __asm__ sections. These should
> probably be merged.
Oh shit. I was trying to be too clever. I still run with this patch,
so it must be happening very rarely.
Does this one compile ok?
static inline void * __constant_memcpy(void * to, const void * from, size_t n)
{
long esi, edi;
#if 1 /* want to do small copies with non-string ops? */
switch (n) {
case 0: return to;
case 1: *(char*)to = *(char*)from; return to;
case 2: *(short*)to = *(short*)from; return to;
case 4: *(int*)to = *(int*)from; return to;
#if 1 /* including those doable with two moves? */
case 3: *(short*)to = *(short*)from;
*((char*)to+2) = *((char*)from+2); return to;
case 5: *(int*)to = *(int*)from;
*((char*)to+4) = *((char*)from+4); return to;
case 6: *(int*)to = *(int*)from;
*((short*)to+2) = *((short*)from+2); return to;
case 8: *(int*)to = *(int*)from;
*((int*)to+1) = *((int*)from+1); return to;
#endif
}
#else
if (!n) return to;
#endif
{
/* load esi/edi */
__asm__ __volatile__(
""
: "=&D" (edi), "=&S" (esi)
: "0" ((long) to),"1" ((long) from)
: "memory"
);
}
if (n >= 5*4) {
/* large block: use rep prefix */
int ecx;
__asm__ __volatile__(
"rep ; movsl"
: "=&c" (ecx), "=&D" (edi), "=&S" (esi)
: "0" (n/4), "1" (edi),"2" (esi)
: "memory"
);
} else {
/* small block: don't clobber ecx + smaller code */
if (n >= 4*4) __asm__
__volatile__("movsl":"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
if (n >= 3*4) __asm__
__volatile__("movsl":"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
if (n >= 2*4) __asm__
__volatile__("movsl":"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
if (n >= 1*4) __asm__
__volatile__("movsl":"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
}
switch (n % 4) {
/* tail */
case 0: return to;
case 1: __asm__
__volatile__("movsb":"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory"); return
to;
case 2: __asm__
__volatile__("movsw":"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory"); return
to;
default: __asm__
__volatile__("movsw\n\tmovsb":"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
return to;
}
}
--
vda
Re: Obsoleting c4x last minute for 4.0
On Wed, 6 Apr 2005, Richard Earnshaw wrote: > Maybe we need a third category - 'at risk'. Such a port will typically > have no active maintainer, some likely serious bugs and might at some > future date be obsoleted if no maintainer steps forward. > > We could put several ports into that category and it shouldn't have the > negative stigma that obsolete seems to have. One possible way of assessing activity would be to say that after 4.1 maintained CPU ports should have test results for mainline regularly sent to gcc-testresults and monitored for regressions, though this rather depends on the willingness of maintainers of embedded ports to do this testing; ports without such testing and regression monitoring could be considered at risk. Only the following ports seem to have had results for 4.1.0-mainline (i.e. mainline since 4.0 branched) sent to gcc-testresults: alpha, arm, hppa, i?86/x86_64, ia64, mips, powerpc, s390, sh, sparc, although cris and mmix are evidently monitored for regressions even though they don't get test results to gcc-testresults. (If test results for a port are so bad that though sent to gcc-testresults they exceed the message size limit, and this remains the case for a prolonged period such as ever since 4.0 branched, that also indicates lack of active maintenance.) -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
RE: [BUG mm] "fixed" i386 memcpy inlining buggy
Original Message
>From: Denis Vlasenko
>Sent: 06 April 2005 11:14
Is this someone's idea of an April Fool's joke? Because if it is, I've
suffered a serious sense-of-humour failure.
> Oh shit. I was trying to be too clever. I still run with this patch,
> so it must be happening very rarely.
The kernel is way too important for cross-your-fingers-and-hope
engineering techniques to be applied. This patch should never have been
permitted. How on earth could anything like this hope to make it through a
strict review?
> Does this one compile ok?
> {
> /* load esi/edi */
> __asm__ __volatile__(
> ""
> : "=&D" (edi), "=&S" (esi)
> : "0" ((long) to),"1" ((long) from)
> : "memory"
> );
> }
> if (n >= 5*4) {
> /* large block: use rep prefix */
> int ecx;
> __asm__ __volatile__(
> "rep ; movsl"
> : "=&c" (ecx), "=&D" (edi), "=&S" (esi)
> : "0" (n/4), "1" (edi),"2" (esi)
> : "memory"
> );
It doesn't matter if it compiles or not, it's still *utterly* invalid.
You can NOT make assumptions about registers keeping their values between
one asm block and another. Immediately after the closing quote of the first
asm, the compiler can do ANYTHING IT WANTS and to just _hope_ that it won't
use the registers you want is voodoo programming. Even if it works when you
try it once, there are zero guarantees that another version or revision of
the compiler or even just a tiny change to the source that affects the
behaviour of the scheduler when compiling the function won't produce
something completely different, meaning that this code is appallingly
fragile. This code should be completely discarded and rewritten properly.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: [BUG mm] "fixed" i386 memcpy inlining buggy
Original Message >From: Dave Korn >Sent: 06 April 2005 12:06 Me and my big mouth. OK, that one does work. Sorry for the outburst. cheers, DaveK -- Can't think of a witty .sigline today
Re: Obsoleting c4x last minute for 4.0
Richard Earnshaw wrote: On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote: Joe Buck wrote: But if it won't even build, then users should be warned. I suppose -- but we have relatively many configurations that probably won't build, at least if you start combining various options, and including langauges beyond just C and C++. I'd be content with a patch that issued a warning, but declaring a port obsolete has often been contentions, and I'd hate to rush into it. Maybe we need a third category - 'at risk'. Such a port will typically have no active maintainer, some likely serious bugs and might at some future date be obsoleted if no maintainer steps forward. We could put several ports into that category and it shouldn't have the negative stigma that obsolete seems to have. The RTEMS community has been interested in the c4x port for a long time but we don't have anyone who can fix things at the level this one is broken. We keep trying it and reporting on it. It gets a little better, then it gets a little worse. Ignoring the technically interesting bit that the c4x is not byte addressable, this port suffers from its original developers having largely moved on by the time it was merged. Not an excuse, just a statement that there was not a clean handoff to a new maintainer. I recall that the original port being using binutils 2.7 so that gives a timeframe. R. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
RE: [BUG mm] "fixed" i386 memcpy inlining buggy
Original Message >From: Dave Korn >Sent: 06 April 2005 12:13 > Original Message >> From: Dave Korn >> Sent: 06 April 2005 12:06 > > > Me and my big mouth. > > OK, that one does work. > > Sorry for the outburst. > well, actually, maybe it doesn't after all. What's that uninitialised variable ecx doing there eh? cheers, DaveK -- Can't think of a witty .sigline today
RE: [BUG mm] "fixed" i386 memcpy inlining buggy
Original Message >From: Dave Korn >Sent: 06 April 2005 12:53 > Original Message >> From: Dave Korn >> Sent: 06 April 2005 12:13 > >> Original Message >>> From: Dave Korn >>> Sent: 06 April 2005 12:06 >> >> >> Me and my big mouth. >> >> OK, that one does work. >> >> Sorry for the outburst. >> > > > well, actually, maybe it doesn't after all. > > > What's that uninitialised variable ecx doing there eh? Oh, I see, it's there as an output so it can be matched as an input by the "0" constraint. Ok, guess it does. cheers, DaveK -- Can't think of a witty .sigline today
Input and print statements for Front End?
Hi All, I'm developing a front end for a simple programming language as part of a project. I have looked through the GCC Internals Manual, the Toy front end language and Treelang. I can't seem to find any info regarding an input or print statement, so i can read integers(my language only deals with integers) from the stdio and return integer results to stdio. I see that the Toy language has to be compiled with a C program to achieve the above. Is this the best or even only solution? Thanks _ Send an animated 'wink' to someone special - download MSN Messenger, FREE! http://messenger.msn.co.uk/Beta/Default.aspx
Re: gcc4, static array, SSE & alignement
On Apr 6, 2005 3:18 AM, James E Wilson <[EMAIL PROTECTED]> wrote: > I would guess a limitation of cygwin binutils support, or perhaps of > Windows itself. Binutils, perhaps. Windows certainly not as msvc2k3 & icc8.1 don't have such issue with the same code. > This seems to work fine on linux. If I compile a simple example using > __alignof__, I see that the compiler is assuming 16-byte alignment. If > I compile with -S, I see that the compiler is giving them 32-byte > alignment (probably for better cache alignment). If I run objdump -x on > the a.out file, I see that .bss section has 2**5 (32-byte) alignment. > All is as it should be. Sections: Idx Name Size VMA LMA File off Algn 0 .text 0003e754 00401000 00401000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 4634 0044 0044 0003ec00 2**4 CONTENTS, ALLOC, LOAD, DATA 2 .rdata4884 00445000 00445000 00043400 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .bss 8fc0 0044a000 0044a000 2**4 ALLOC 4 .idata1984 00453000 00453000 00047e00 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .stab 00169908 00455000 00455000 00049800 2**2 CONTENTS, READONLY, DEBUGGING, NEVER_LOAD, EXCLUDE 6 .stabstr 001c39e1 005bf000 005bf000 001b3200 2**0 CONTENTS, READONLY, DEBUGGING, NEVER_LOAD, EXCLUDE Gcc & the toolchain used to have lots of issues wrt alignement, but i thought they were a thing of the past. As far as i can see, everything is fine regarding section alignements. > A real bug report, as per > http://gcc.gnu.org/bugs.html > would be useful here, so we can check. In particular, a testcase to > reproduce the problem, and exactly what you believe is wrong with the > output. Yep, but i was testing the water. I mean i have lots of other 16 bytes aligned data (static, extern, const or not and whatnot) in there and the only problematic one is this semi large static. So, because that's the largest, i thought i've crossed some magic size threshold. I'll try to pinpoint the problem a bit better.
Re: [BUG mm] "fixed" i386 memcpy inlining buggy
Am Mittwoch, den 06.04.2005, 13:14 +0300 schrieb Denis Vlasenko: > Oh shit. I was trying to be too clever. I still run with this patch, > so it must be happening very rarely. Yes, that's right, it happened with code that's not in the mainline tree but could have happened anywhere. > Does this one compile ok? Yes, the case that failed is now okay. I changed it slightly to assign esi and edi directy on top of the functions, no asm section needed here. The compiler will make sure that they have the correct values when needed. In the case above the compiler now uses %ebx to save the loop counter instead of %esi. In drivers/cdrom/cdrom.c I'm observing one very strange thing though. It appears that the compiler decided to put the local variable edi on the stack for some unexplicable reason (or possibly there is?). Since the asm sections are memory barriers the compiler then saves the value of %edi on the stack before entering the next assembler section. 1f1c: a5 movsl %ds:(%esi),%es:(%edi) 1f1d: 89 7d 84mov%edi,0xff84(%ebp) 1f20: a5 movsl %ds:(%esi),%es:(%edi) 1f21: 89 7d 84mov%edi,0xff84(%ebp) 1f24: 66 a5 movsw %ds:(%esi),%es:(%edi) (this is a constant 10 byte memcpy) The only thing that would avoid this is to either tell the compiler to never put esi/edi in memory (which I think is not possibly across different versions of gcc) or to always generate a single asm section for all the different cases. signature.asc Description: This is a digitally signed message part
Re: gcc4, static array, SSE & alignement
On Apr 6, 2005 2:08 PM, tbp <[EMAIL PROTECTED]> wrote: > I'll try to pinpoint the problem a bit better. Alas, since the other day the code using that static array has changed a bit and i can't reproduce the bug. So, after all, it really was gcc's fault. I'll try to dig up the original version.
Re: Input and print statements for Front End?
On Wednesday 06 April 2005 13:00, Harry Goulding wrote: > Hi All, > > I'm developing a front end for a simple programming language as part of a > project. > > I have looked through the GCC Internals Manual, the Toy front end language > and Treelang. > > I can't seem to find any info regarding an input or print statement, so i > can read integers(my language only deals with integers) from the stdio and > return integer results to stdio. Interfacing with the OS is the resposibility of your language runtime library, not the compiler itself.. You might want to look at how the fortran intrinsic functions an IO routines are handled. Basically the language define IO constructs are turned into a sequence of function calls. Paul
Re: [BUG mm] "fixed" i386 memcpy inlining buggy
I'm having a little difficulty understanding what this is for. Is it that gcc's builtin memcpy expander generates bad code, or that older versions of gcc generate bad code, or what? gcc generates too much code? Andrew.
HEAD regression: All java tests are failing with an ICE when optimized
HEAD, clean build this morning. i686-linux-gnu. With the libgcj "make check", there are many identical failures. These are of the form PR4766.java: In class 'PR4766': PR4766.java: In method 'PR4766.myfunction()': PR4766.java:0: internal compiler error: in hash_scan_set, at postreload-gcse.c:741 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 And the ICE is always in hash_scan_set. I do not believe that this is a Java FE bug. Has anyone else seen this? Andrew.
Re: HEAD regression: All java tests are failing with an ICE when optimized
On Wed, Apr 06, 2005 at 01:56:48PM +0100, Andrew Haley wrote: > Has anyone else seen this? > Yes. At first I thought it was my patch, but it only happens on i686 and libjava was working fine the day before. Diego.
Re: http://gcc.gnu.org/install/specific.html#*-*-solaris2*
Now I now (and understand) that you changed the mangling of filenames, but where does the "g_t" come from, and why? Catering to XHTML's stupidity. I mentioned it in: http://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#HTML-Xref-Link-Basics viz. One exception: the algorithm for node name expansion prefixes the string `g_t' when the node name begins with a non-letter. This kludge (due to XHTML rules) is not necessary for filenames, and is therefore omitted. Sorry ...
RE: [BUG mm] "fixed" i386 memcpy inlining buggy
Attached is inline ix86 memcpy() plus test code that tests its
corner-cases. The in-line code makes no jumps, but uses longword
copies, word copies and any spare byte copy. It works at all
offsets, doesn't require alignment but would work fastest if
both source and destination were longword aligned.
On Wed, 6 Apr 2005, Dave Korn wrote:
Original Message
From: Dave Korn
Sent: 06 April 2005 12:13
Original Message
From: Dave Korn
Sent: 06 April 2005 12:06
Me and my big mouth.
OK, that one does work.
Sorry for the outburst.
well, actually, maybe it doesn't after all.
What's that uninitialised variable ecx doing there eh?
cheers,
DaveK
--
Can't think of a witty .sigline today
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
#include
#include
//
// Inline ix86 memcpy() that contains no jumps. Not copied from
// anybody.Contributed by [EMAIL PROTECTED]
//
static __inline__ void *memcpy(void *dst, void *src, size_t len) {
void *ret = dst;
__asm__ __volatile__( \
"cld\n" \
"shr $1, %%ecx\n" \
"pushf\n" \
"shr $1, %%ecx\n" \
"pushf\n" \
"rep\n" \
"movsl\n" \
"popf\n"\
"adcl %%ecx, %%ecx\n" \
"rep\n" \
"movsw\n" \
"popf\n"\
"adcl %%ecx, %%ecx\n" \
"rep\n" \
"movsb\n" \
: "=D" (dst), "=S" (src), "=c"(len)
: "0" (dst), "1" (src), "2" (len)
: "memory" );
return ret;
}
const char tester[]="0123456789"
"0123456789"
"0123456789"
"0123456789"
"0123456789"
"0123456789"
"0123456789"
"0123456789";
char allocated[0x1000];
int main()
{
size_t i;
char buf[0x1000];
memset(buf, 0x00, sizeof(buf));
for(i=0; i< sizeof(buf); i++)
puts(memcpy(buf, (char *)tester, i));
memset(buf, 0x00, sizeof(buf));
for(i=0; i< sizeof(buf)-1; i++)
puts(memcpy(&buf[1], (char *)tester, i));
memset(buf, 0x00, sizeof(buf));
for(i=0; i< sizeof(buf)-2; i++)
puts(memcpy(&buf[2], (char *)tester, i));
memset(buf, 0x00, sizeof(buf));
for(i=0; i< sizeof(buf)-3; i++)
puts(memcpy(&buf[3], (char *)tester, i));
return 0;
}
Re: HEAD regression: All java tests are failing with an ICE when optimized
Andrew Haley wrote: > HEAD, clean build this morning. i686-linux-gnu. > > With the libgcj "make check", there are many identical failures. > > These are of the form > > PR4766.java: In class 'PR4766': > PR4766.java: In method 'PR4766.myfunction()': > PR4766.java:0: internal compiler error: in hash_scan_set, at > postreload-gcse.c:741 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > compiler exited with status 1 > > And the ICE is always in hash_scan_set. > > I do not believe that this is a Java FE bug. > > Has anyone else seen this? First off, I didn't when I ran my regular bootstrap + libjava_check cycle. That's because I use "--disable-checking". Second, it's most likely caused by Nathan's assertifying patch to gcc/p*.c: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00227.html Note that the "#ifdef ENABLE_CHECKING" guard in postreload-gcse.c (around line #741) was *misspelt* before: - #ifdef ENABLE_CHEKCING and was thus never being executed before. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
RE: Trying to build crosscompiler for Sparc Solaris 8 -> SparcSolaris 10 (& others)...
On Wed, 2005-04-06 at 10:28 +0100, Dave Korn wrote: > Original Message > >From: Aaron Gaudio > >Sent: 05 April 2005 21:05 > > > (CCing this to [EMAIL PROTECTED] due to potential build bugs...) > > > I have already installed binutils 2.15 and gcc 3.4.5 native Solaris 8 > > verisons in the prefix /vobs/java/gnu and added this directory to my > > path, so that those are the tools being used for building the cross- > > compiler environment. > > Two things to check: > > 1) Try specifying an absolute rather than relative path to the gcc > configure script; I think this has been known to be a source of problems on > solaris platforms in the past, but I don't know if it's still relevant now. > It can't hurt to try. > > 2) If what you say above is *literally* correct, then the reason the wrong > assembler is being found is because you've added $prefix to your $PATH, when > you should have added $prefix/bin! > > Thanks for your attention, Dave. I checked the script I'm using to build and I actually am using an absolute path to gcc's configure, despite what I wrote in my original mailnote. As for the prefix... you're right, I should be adding $prefix/bin to my path. I was adding $prefix in my script, but lo, I had already added $prefix/bin to my path in my shell. I'll fix my script, but that won't have any impact on the problems I'm facing. You see, the 'as' being called was in fact the one in $prefix/bin, but the problem is that $prefix is a holding place for binaries with multiple targets. $prefix/bin/as is a Sparc Solaris 8 binary with a Sparc Solaris 8 target (eg --version "This assembler was configured for a target of `sparc-sun- solaris2.8'."). However, $prefix/bin/i586-sun-solaris2.10-as is a Sparc Solaris 8 binary with an i586 Solaris 10 target (--version "This assembler was configured for a target of `i586-sun-solaris2.10'."). It seems like either Makefile should be using $AS_FOR_TARGET (which would expand to 'i586-sun-solaris2.10-as'), instead of $AS (which is just 'as') OR the .s file being assembled should be using Sparc assembly instructions instead of x86. I assumed the former was the case, and that let me get further in the build, so that's what I've stuck with for now... -- Aaron Gaudio agaudio @ eng.mc.xerox.com 585-422-6876 madcap @ irc://rockhopper.eng.mc.xerox.com OpenPGP fingerprint: 74B3 1018 08EB 1B3F E7C7 B944 11B1 E0C3 949C 8906 "Every man is a mob, a chain gang of idiots." - Jonathan Nolan, /Memento Mori/ signature.asc Description: This is a digitally signed message part
Re: Obsoleting c4x last minute for 4.0
Joel Sherrill <[EMAIL PROTECTED]> wrote: Richard Earnshaw wrote: On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote: Joe Buck wrote: But if it won't even build, then users should be warned. I suppose -- but we have relatively many configurations that probably won't build, at least if you start combining various options, and including langauges beyond just C and C++. I'd be content with a patch that issued a warning, but declaring a port obsolete has often been contentions, and I'd hate to rush into it. Maybe we need a third category - 'at risk'. Such a port will typically have no active maintainer, some likely serious bugs and might at some future date be obsoleted if no maintainer steps forward. We could put several ports into that category and it shouldn't have the negative stigma that obsolete seems to have. The RTEMS community has been interested in the c4x port for a long time but we don't have anyone who can fix things at the level this one is broken. We keep trying it and reporting on it. It gets a little better, then it gets a little worse. I have been reminded by an RTEMS user that the c4x port actually did successfully build C for 3.4. This makes it a recent regression. -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Obsoleting c4x last minute for 4.0
Joseph S. Myers wrote: One possible way of assessing activity would be to say that after 4.1 maintained CPU ports should have test results for mainline regularly sent to gcc-testresults and monitored for regressions, though this rather depends on the willingness of maintainers of embedded ports to do this testing; ports without such testing and regression monitoring could be considered at risk. Only the following ports seem to have had results for 4.1.0-mainline (i.e. mainline since 4.0 branched) sent to gcc-testresults: alpha, arm, hppa, i?86/x86_64, ia64, mips, powerpc, s390, sh, sparc, although cris and mmix are evidently monitored for regressions even though they don't get test results to gcc-testresults. Add the AVR to the list of ports that (so far) haven't had test results sent to gcc-testresults. It's only been recently that the GCC test suite has been able to run for the AVR using an outside simulator. Hopefully in the future this will change; there's a lot of work being done on the AVR port. I would also venture to say that the 68HC11/12 port is active as well. Though I don't know the status of testing on that port. Eric
RE: Question regarding MIPS_GPREL_16 relocation
Hello all First I want to thanks a lot for Your advices. I changed as You told to me MULTILIB_OPTIONS = G0 mlong-calls msoft-float EL/EB mips32/mips64 MULTILIB_DIRNAMES = G0 mlong-calls soft-float el eb mips32 mips64 after rebuilding and installing gcc I got needed libraries. I will start test this and I want to thanks again for Your efforts. Best regards Mile -Original Message- From: Richard Sandiford [mailto:[EMAIL PROTECTED] Sent: Monday, April 04, 2005 10:00 PM To: [EMAIL PROTECTED] Cc: 'Eric Christopher'; gcc@gcc.gnu.org Subject: Re: Question regarding MIPS_GPREL_16 relocation "Mile Davidovic" <[EMAIL PROTECTED]> writes: > But problem is passing G0 option, if I simple put MULTILIB_OPTIONS = > G0 mlong-calls msoft-float EL/EB mips32/mips64 building library fail. If you add something to MULTILIB_OPTIONS, you need to add an entry to MULTILIB_DIRNAMES as well. (Sorry if you already knew and did that, but in that case, how did building the library fail?) Richard
Re: [BUG mm] "fixed" i386 memcpy inlining buggy
The only thing that would avoid this is to either tell the compiler to
never put esi/edi in memory (which I think is not possibly across
different versions of gcc) or to always generate a single asm section
for all the different cases.
Use __asm__ ("%esi") and __asm__ ("%edi"). It is not guaranteed that
they access the registers always (you can still have copy propagation
etcetera); but, if your __asm__ statement constraints match the register
you specify, then you can be reasonably sure that good code is produced.
Paolo
3.4.3 on Solaris9, boehm-gc probs.
I've STW for this but can't see others with the same problem. I'm
getting:
[...]
/bin/bash ./libtool --mode=compile /export/home/Scratch/hgs/gcc-build/gcc/xgcc
-B/export/home/Scratch/hgs/gcc-build/gcc/
-B/usr/local/sparc-sun-solaris2.9/bin/ -B/usr/local/sparc-sun-solaris2.9/lib/
-isystem /usr/local/sparc-sun-solaris2.9/include -isystem
/usr/local/sparc-sun-solaris2.9/sys-include -DGC_SOLARIS_THREADS=1
-DGC_SOLARIS_PTHREADS=1 -DSILENT=1 -DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1
-DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -I.
-I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc
-I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/include -O2 -mcpu=v9
-fexceptions -I././targ-include
-I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/./libc/include -O2 -mcpu=v9 -c
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c
/export/home/Scratch/hgs/gcc-build/gcc/xgcc
-B/export/home/Scratch/hgs/gcc-build/gcc/
-B/usr/local/sparc-sun-solaris2.9/bin/ -B/usr/local/sparc-sun-solaris2.9/lib/
-isystem /usr/local/sparc-sun-solaris2.9/include -isystem
/usr/local/sparc-sun-solaris2.9/sys-include -DGC_SOLARIS_THREADS=1
-DGC_SOLARIS_PTHREADS=1 -DSILENT=1 -DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1
-DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -I.
-I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc
-I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/include -O2 -mcpu=v9 -fexceptions
-I././targ-include -I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/./libc/include
-O2 -mcpu=v9 -c /export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c -fPIC
-DPIC -o .libs/dyn_load.o
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c: In function
`GC_FirstDLOpenedLinkMap':
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:110: error: syntax error before
"_DYNAMIC"
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error: `Elf32_Dyn'
undeclared (first use in this function)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error: (Each
undeclared identifier is reported only once
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error: for each
function it appears in.)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error: `dp'
undeclared (first use in this function)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:114: error: syntax error
before '*' token
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:127: error:
`dynStructureAddr' undeclared (first use in this function)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:127: error: `_DYNAMIC'
undeclared (first use in this function)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:135: error: parse error
before ')' token
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:136: error: `DT_DEBUG'
undeclared (first use in this function)
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:139: error:
dereferencing pointer to incomplete type
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c: In function
`GC_register_dynamic_libraries':
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:209: error:
dereferencing pointer to incomplete type
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:227: error:
dereferencing pointer to incomplete type
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:229: error:
dereferencing pointer to incomplete type
gmake[3]: *** [dyn_load.lo] Error 1
gmake[3]: Leaving directory
`/export/home/Scratch/hgs/gcc-build/sparc-sun-solaris2.9/boehm-gc'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/export/home/Scratch/hgs/gcc-build/sparc-sun-solaris2.9/boehm-gc'
gmake[1]: *** [all-target-boehm-gc] Error 2
gmake[1]: Leaving directory `/export/home/Scratch/hgs/gcc-build'
gmake: *** [bootstrap-lean] Error 2
You have mail in /var/mail/hgs
bash-2.05$
when using
gcc (GCC) 3.4.1
GNU assembler 2.14 20030612
GNU ld version 2.14 20030612
GNU Make 3.80
ltmain.sh (GNU libtool) 1.5.14 (1.1220.2.195 2005/02/12 12:12:33)
GNU bash, version 2.05.0(1)-release (sparc-sun-solaris2.9)
and a build script of
#!/bin/bash -x
PATH=/bin:/usr/sbin:/usr/ccs/bin:/etc:/usr/local/bin:/opt/sfw/bin:/usr/openwin/bin
export PATH
CONFIG_SHELL=/bin/bash
export CONFIG_SHELL
BUILDINGVER=3.4.3
BUILD_DIR=/export/home/Scratch/hgs/gcc-build
GCC_SOURCE_DIR=/export/home/Scratch/hgs/gcc-${BUILDINGVER}
# CC="/progs/SUNWspro/bin/cc -xildoff -xarch=v9" options only needed
# for 64 bit...
# CC="/progs/SUNWspro/bin/cc"
CC=gcc
export CC
CXX=g++
export CXX
MAKE=/usr/local/bin/gmake
export MAKE
ASOPT="--with-as=/usr/local/bin/as"
LDOPT="--with-ld=/usr/local/bin/ld"
LANGOPT="--enable-languages=c,c++,f77,java,objc"
cd $BUILD_DIR
/bin/rm -rf ./*
${GCC_SOURCE_DIR}/configure $ASOPT $LDOPT $LANGOPTS --disable-nls && \
# gmake --jobs=5 bootstrap-lean &&
gmake bootstrap-lean && \
gmake check
Is there anything I have missed?
Thank you,
Hugh
Re: Obsoleting c4x last minute for 4.0
Richard Earnshaw wrote: On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote: Joe Buck wrote: But if it won't even build, then users should be warned. I suppose -- but we have relatively many configurations that probably won't build, at least if you start combining various options, and including langauges beyond just C and C++. I'd be content with a patch that issued a warning, but declaring a port obsolete has often been contentions, and I'd hate to rush into it. Maybe we need a third category - 'at risk'. Such a port will typically have no active maintainer, some likely serious bugs and might at some future date be obsoleted if no maintainer steps forward. That seems eminently reasonable. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
RE: Trying to build crosscompiler for Sparc Solaris 8 ->SparcSolaris 10 (& others)...
Original Message
>From: Aaron Gaudio
>Sent: 06 April 2005 14:25
> Thanks for your attention, Dave. I checked the script I'm using to build
> and I actually am using an absolute path to gcc's configure, despite
> what I wrote in my original mailnote.
Oh well, so much for that one. This is why you should cut and paste the
real output from builds that go wrong when you're making a bug report,
rather than faking it: you gave me false information about your problem.
This is not very constructive.
> As for the prefix... you're right, I should be adding $prefix/bin to my
> path. I was adding $prefix in my script, but lo, I had already added
> $prefix/bin to my path in my shell. I'll fix my script, but that won't
> have any impact on the problems I'm facing. You see, the 'as' being
> called was in fact the one in $prefix/bin, but the problem is that
> $prefix is a holding place for binaries with multiple targets.
Yes indeed, but that isn't a problem. When you're doing a cross-compile,
the make process is in fact looking out for ${target}-as. If you've
configured gcc for "i586-sun-solaris2.10", and there is a
"i586-sun-solaris2.10-as" in your $PATH, the make process should find it.
It's only after completely failing to find ${target}-as that the make
process will fall back as a last resort to just trying to use the first 'as'
it can find.
> $prefix/bin/as is a Sparc Solaris 8 binary with a Sparc Solaris 8 target
> (eg --version "This assembler was configured for a target of `sparc-sun-
> solaris2.8'."). However, $prefix/bin/i586-sun-solaris2.10-as is a Sparc
> Solaris 8 binary with an i586 Solaris 10 target (--version "This
> assembler was configured for a target of `i586-sun-solaris2.10'.").
Well, it *absolutely* should have found and used that one. Assuming you
really did configure gcc for that target, of course.
> It seems like either Makefile should be using $AS_FOR_TARGET (which
> would expand to 'i586-sun-solaris2.10-as'), instead of $AS (which is
> just 'as') OR the .s file being assembled should be using Sparc assembly
> instructions instead of x86. I assumed the former was the case, and that
> let me get further in the build, so that's what I've stuck with for
> now...
No, no, no, you are definitely wrong. Leave the makefile alone: it works
fine for every other kind of cross-compile, there's nothing wrong with it,
gcc 3.4.3 has been out for a while now and people would have noticed if it
was so badly broken!
There is an unbreakable rule when making cross toolchains: you must use
the EXACT same arguments for --prefix and for --target when you configure
gcc as you used when you configured binutils. You appear to have broken
that rule. If the makefile is using $AS instead of $AS_FOR_TARGET, then you
have gotten a bad configure somehow, and autoconf has made you a makefile
suitable for a host-native compiler. Did you try reconfiguring in the same
object directory you had previously used for the sparc-sun-solaris2.8
target?
I think you should blow away your object directory, create a new one,
freshly configure and try again. If it still doesn't work, show me the REAL
configure commands you've been using. Don't post forged output in a bug
report!
BTW, there's a list called the crossgcc mailing list
(http://sources.redhat.com/ml/crossgcc/), which is more suitable to this
sort of problem than the main gcc or gcc-help lists, but since we're here
now, we may as well try and sort this one out here; I'm just letting you
know for future reference.
cheers,
DaveK
--
Can't think of a witty .sigline today
gcc-3.4-20050401 BUG? generates illegal instruction in X11R6.4.2/mkfontscale/freetype macro
Hello, gcc-list!
Hello, Melchior!
Well, about a year ago, we/you have had problems when building X11
that mkfontscale crashes with an illegal instruction or an segmentation
fault on powerpc. Maybe some of you remember.
Here is the old mail:
[Devel] [BUG] freetype2 CVS/HEAD: crash in FT_Get_Name_Index (ftobjs.c:2407)
http://lists.gnu.org/archive/html/freetype-devel/2004-04/msg00051.html
I am running into the same problems again (and several others did).
Even with a pretty new toolchain:
gcc-3.4-20050401 (3.4.4)
X11R6.4.2
glibc-2.3.4
binutils-2.15.96
freetype-2.1.9
to reproduce the problem:
install freetype-2.1.9
./configure
make
make install
compile X
make World
everything fine
make install
when mkfontscale tries to
+ ../../../exports/bin/mkfontscale /usr/X11R6/lib/X11/fonts/Type1
make[4]: *** [install] Error 132
(Illegal instruction)
I ran into the same problem again and again. This only happens
with the Type1 fonts... the others build fine!
My host is a embedded PowerPC from Freescale (MPC8540, e500 core, no fpu)
I've applied your patch for the macro. (inserting a dummy printf("");)
But this doesn't fix the problem on my platform.
What is the real background that mkfontscale breaks?
A compiler error or a bug in freetype?
Are there any good news that the problem is really fixed?
Well... and how? Any suggestions to track down that problem?
Best greets
Clemens Koller
___
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Re: [BUG mm] "fixed" i386 memcpy inlining buggy
On Tuesday 05 April 2005 19:34, Christophe Saout wrote:
> the new i386 memcpy macro is a ticking timebomb.
>
> I've been debugging a new mISDN crash, just to find out that a memcpy
> was not inlined correctly.
>
> Andrew, you should drop the fix-i386-memcpy.patch (or have it fixed).
Updated patch against 2.6.11 follows. This one, like the original
patch, is run tested too.
This time I took no chances, esi/edi contents are
explicitly propagated from one asm() block to another.
I didn't do it before, not expecting that gcc can be
s incredibly clever. Sorry.
Christophe does this one look/compile ok?
--
vda
--- linux-2.6.11.src/include/asm-i386/string.h.orig Thu Mar 3 09:31:08 2005
+++ linux-2.6.11.src/include/asm-i386/string.h Wed Apr 6 19:08:39 2005
@@ -198,47 +198,80 @@ static inline void * __memcpy(void * to,
int d0, d1, d2;
__asm__ __volatile__(
"rep ; movsl\n\t"
- "testb $2,%b4\n\t"
- "je 1f\n\t"
- "movsw\n"
- "1:\ttestb $1,%b4\n\t"
- "je 2f\n\t"
- "movsb\n"
- "2:"
+ "movl %4,%%ecx\n\t"
+ "andl $3,%%ecx\n\t"
+#if 1 /* want to pay 2 byte penalty for a chance to skip microcoded rep? */
+ "jz 1f\n\t"
+#endif
+ "rep ; movsb\n\t"
+ "1:"
: "=&c" (d0), "=&D" (d1), "=&S" (d2)
- :"0" (n/4), "q" (n),"1" ((long) to),"2" ((long) from)
+ : "0" (n/4), "g" (n), "1" ((long) to), "2" ((long) from)
: "memory");
return (to);
}
/*
- * This looks horribly ugly, but the compiler can optimize it totally,
+ * This looks ugly, but the compiler can optimize it totally,
* as the count is constant.
*/
static inline void * __constant_memcpy(void * to, const void * from, size_t n)
{
- if (n <= 128)
- return __builtin_memcpy(to, from, n);
-
-#define COMMON(x) \
-__asm__ __volatile__( \
- "rep ; movsl" \
- x \
- : "=&c" (d0), "=&D" (d1), "=&S" (d2) \
- : "0" (n/4),"1" ((long) to),"2" ((long) from) \
- : "memory");
-{
- int d0, d1, d2;
+ long esi, edi;
+ if (!n) return to;
+#if 1 /* want to do small copies with non-string ops? */
+ switch (n) {
+ case 1: *(char*)to = *(char*)from; return to;
+ case 2: *(short*)to = *(short*)from; return to;
+ case 4: *(int*)to = *(int*)from; return to;
+#if 1 /* including those doable with two moves? */
+ case 3: *(short*)to = *(short*)from;
+ *((char*)to+2) = *((char*)from+2); return to;
+ case 5: *(int*)to = *(int*)from;
+ *((char*)to+4) = *((char*)from+4); return to;
+ case 6: *(int*)to = *(int*)from;
+ *((short*)to+2) = *((short*)from+2); return to;
+ case 8: *(int*)to = *(int*)from;
+ *((int*)to+1) = *((int*)from+1); return to;
+#endif
+ }
+#endif
+ esi = (long) from;
+ edi = (long) to;
+ if (n >= 5*4) {
+ /* large block: use rep prefix */
+ int ecx;
+ __asm__ __volatile__(
+ "rep ; movsl"
+ : "=&c" (ecx), "=&D" (edi), "=&S" (esi)
+ : "0" (n/4), "1" (edi),"2" (esi)
+ : "memory"
+ );
+ } else {
+ /* small block: don't clobber ecx + smaller code */
+ if (n >= 4*4) __asm__ __volatile__("movsl"
+ :"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
+ if (n >= 3*4) __asm__ __volatile__("movsl"
+ :"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
+ if (n >= 2*4) __asm__ __volatile__("movsl"
+ :"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
+ if (n >= 1*4) __asm__ __volatile__("movsl"
+ :"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
+ }
switch (n % 4) {
- case 0: COMMON(""); return to;
- case 1: COMMON("\n\tmovsb"); return to;
- case 2: COMMON("\n\tmovsw"); return to;
- default: COMMON("\n\tmovsw\n\tmovsb"); return to;
+ /* tail */
+ case 0: return to;
+ case 1: __asm__ __volatile__("movsb"
+ :"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
+ return to;
+ case 2: __asm__ __volatile__("movsw"
+ :"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
+ return to;
+ default: __asm__ __volatile__("movsw\n\tmovsb"
+ :"=&D"(edi),"=&S"(esi):"0"(edi),"1"(esi):"memory");
+ return to;
}
}
-
-#undef COMMON
-}
#define __HAVE_ARCH_MEMCPY
Re: [gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF
> Toon Moene writes: Toon> We (the GNU Fortran folk) are in trouble too: We're awaiting Toon> affirmation of the receipt of Thomas Koenig's papers (sent from Germany Toon> on the 19th of March). He has quite a few patches to gfortran in the Toon> queue and GCC 4.0 (the first GCC release to contain gfortran) is Toon> scheduled for the 15th of April. Toon> Please help. The FSF has advised that we can accept Thomas's patches while the paperwork catches up. David
Illegal promotion of bool to int....
Greetings. I am running up against an interesting compiler bug whereby a bool is being promoted to an int. I found a Bugzilla entry and a message on the mailing list that I thought was similar to what I am seeing: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15484 http://gcc.gnu.org/ml/gcc/2004-05/msg00752.html Usage of the patch does not help for gcc-3.3 or 3.4 compilers on PPC. I tried a fresh checkout of 4.1.0, but it failed to cross-build for i686-linux hosted and powerpc-linux target. I am building my cross toolchains with 'crosstool'. Here is the output from my compile: powerpc-7450-linux-gnu-g++ -I../common -O2 -Wall -Wno-uninitialized -mtune=7450 -maltivec -g -c ../modify/transform.cpp -o transform.o ../modify/transform.cpp:109: error: prototype for `analysis::analysis(int, resolution, sample_allocator*, float, roi_node*, int)' does not match any in class `analysis' ../common/sample_processing.h:768: error: candidates are: analysis::analysis(const analysis&) ../common/sample_processing.h:781: error: analysis::analysis(resolution, sample_allocator*, bool, float, roi_node*) ../modify/transform.cpp:125: error: prototype for `sub_analysis::sub_analysis(resolution, sample_allocator*, int, float, roi_node*)' does not match any in class `sub_analysis' ../modify/analysis_local.h:49: error: candidates are: sub_analysis::sub_analysis(const sub_analysis&) ../modify/analysis_local.h:53: error: sub_analysis::sub_analysis(resolution, sample_allocator*, bool, float, roi_node*) ../modify/transform.cpp:309: error: prototype for `void sub_analysis::push(line_buf&, int)' does not match any in class `sub_analysis' ../modify/analysis_local.h:56: error: candidate is: virtual void sub_analysis::push(line_buf&, bool) make: *** [transform.o] Error 1 Does anyone have some insight on this? Thanks. -Steve
specs file
I as sorry I repeat my appeal, but if really nobody works on Sparc or PowerPC processors and nobody wants to send me 'specs' file from directory > " /usr/lib/gcc-lib/name_of_compiler/lib/version/specs " or similar ??? One more time, thank you for help! Nie dzwon do Londynu... zanim nie sprawdzisz HALO.interia.pl Tutaj: http://link.interia.pl/f1870
Re: Illegal promotion of bool to int....
On Wed, Apr 06, 2005 at 12:14:04PM -0500, [EMAIL PROTECTED] wrote: > I am running up against an interesting compiler bug whereby a bool is > being promoted to an int. I found a Bugzilla entry and a message on the > mailing list that I thought was similar to what I am seeing: > ... > Does anyone have some insight on this? Thanks. Sorry, it's not possible to help you figure out a bug from such a vague description. A testcase would be needed. If the bug is in code that you cannot publish, you can try to cut it down to a small example that you can reveal.
Re: specs file
> I as sorry I repeat my appeal, but if really nobody works on Sparc > or PowerPC processors and nobody wants to send me 'specs' file from > directory > " /usr/lib/gcc-lib/name_of_compiler/lib/version/specs " > or similar ??? You probably don't need this file. If you do, you can get it for yourself using gcc -dumpspecs. What are you really trying to do? zw
Re: 3.4.3 on Solaris9, boehm-gc probs.
> /usr/local/sparc-sun-solaris2.9/sys-include -DGC_SOLARIS_THREADS=1
> -DGC_SOLARIS_PTHREADS=1 -DSILENT=1 -DNO_SIGNALS=1 -DALL_INTERIOR_POINTERS=1
> -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -I.
> -I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc
> -I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/include -O2 -mcpu=v9
> -fexceptions -I././targ-include
> -I/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/./libc/include -O2 -mcpu=v9
> -c /export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c -fPIC -DPIC -o
> .libs/dyn_load.o /export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c: In
> function `GC_FirstDLOpenedLinkMap':
> /export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:110: error: syntax
> error before "_DYNAMIC"
> /export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error:
> `Elf32_Dyn' undeclared (first use in this function)
Elf32_Dyn is supposed to be defined in /usr/include/sys/link.h:
typedef struct {
Elf32_Sword d_tag; /* how to interpret value */
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
Elf32_Off d_off;
} d_un;
} Elf32_Dyn;
Here's what I get with -H:
. /opt/build/eric/gcc-3_4-branch/gcc/include/sys/types.h
.. /usr/include/sys/isa_defs.h
.. /usr/include/sys/feature_tests.h
.. /usr/include/sys/machtypes.h
.. /usr/include/sys/int_types.h
.. /usr/include/sys/select.h
... /usr/include/sys/time.h
/opt/build/eric/gcc-3_4-branch/gcc/include/sys/types.h
/usr/include/time.h
. /usr/include/iso/time_iso.h
. /usr/include/sys/time_impl.h
/usr/include/sys/select.h
. /home/eric/cvs/gcc-3_4-branch/boehm-gc/include/private/gc_priv.h
.. /home/eric/cvs/gcc-3_4-branch/boehm-gc/include/private/../gc.h
... /home/eric/cvs/gcc-3_4-branch/boehm-gc/include/private/../gc_config_macros.h
/opt/build/eric/gcc-3_4-branch/gcc/include/stddef.h
...
/home/eric/cvs/gcc-3_4-branch/boehm-gc/include/private/../gc_pthread_redirects.h
/usr/include/thread.h
. /opt/build/eric/gcc-3_4-branch/gcc/include/sys/signal.h
.. /usr/include/sys/iso/signal_iso.h
... /usr/include/sys/unistd.h
.. /usr/include/sys/siginfo.h
... /usr/include/sys/machsig.h
. /usr/include/synch.h
.. /usr/include/sys/machlock.h
... /usr/include/v7/sys/privregs.h
/usr/include/v7/sys/psr.h
/usr/include/sys/fsr.h
.. /usr/include/sys/synch.h
/usr/include/pthread.h
. /usr/include/sched.h
/usr/include/signal.h
. /usr/include/iso/signal_iso.h
. /usr/include/sys/procset.h
.. /home/eric/cvs/gcc-3_4-branch/boehm-gc/include/private/../gc_mark.h
... /home/eric/cvs/gcc-3_4-branch/boehm-gc/include/private/../gc.h
.. /home/eric/cvs/gcc-3_4-branch/boehm-gc/include/private/gcconfig.h
... /usr/include/errno.h
/usr/include/sys/errno.h
... /usr/include/sys/vmparam.h
... /usr/include/unistd.h
.. /home/eric/cvs/gcc-3_4-branch/boehm-gc/include/private/gc_hdrs.h
.. /usr/include/stdlib.h
... /usr/include/iso/stdlib_iso.h
.. /opt/build/eric/gcc-3_4-branch/gcc/include/stddef.h
.. /home/eric/cvs/gcc-3_4-branch/boehm-gc/include/private/gc_locks.h
.. /usr/include/string.h
... /usr/include/iso/string_iso.h
. /opt/build/eric/gcc-3_4-branch/gcc/include/stdio.h
.. /opt/build/eric/gcc-3_4-branch/gcc/include/stdarg.h
.. /usr/include/iso/stdio_iso.h
... /usr/include/sys/va_list.h
... /opt/build/eric/gcc-3_4-branch/gcc/include/stdio_tag.h
... /usr/include/stdio_impl.h
. /usr/include/sys/elf.h
.. /usr/include/sys/elftypes.h
. /usr/include/dlfcn.h
. /usr/include/link.h
.. /usr/include/sys/link.h
.. /usr/include/libelf.h
--
Eric Botcazou
Re: [gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF
David Edelsohn wrote: Toon Moene writes: Toon> We (the GNU Fortran folk) are in trouble too: We're awaiting Toon> affirmation of the receipt of Thomas Koenig's papers (sent from Germany Toon> on the 19th of March). He has quite a few patches to gfortran in the Toon> queue and GCC 4.0 (the first GCC release to contain gfortran) is Toon> scheduled for the 15th of April. Toon> Please help. The FSF has advised that we can accept Thomas's patches while the paperwork catches up. David Thanks, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
use of extended asm on ppc for long long data types
Is there anyway to specify a long long data type as a constraint to extended asm for powerpc32. If so, how does one specify the registers that would have the upper and lower bits - kumar
Re: use of extended asm on ppc for long long data types
> Kumar Gala writes: Kumar> Is there anyway to specify a long long data type as a constraint to Kumar> extended asm for powerpc32. If so, how does one specify the registers Kumar> that would have the upper and lower bits The rs6000.md machine description has examples of patterns implementing 64-bit (DImode) operations in 32-bit mode. The constraint is a normal "r" or "b" GPR constraint. GCC allocates pairs of consecutive registers to hold the 64-bit value in 32-bit mode. When operating in big-endian, the MSB is in the first register and the LSB is the second register (R+1); in little-endian mode, the two registers are reversed. The PowerPC port defines a special print_operand modifier %L to refer to R+1, e.g., for operand 0, one would write assembly code referring to %0 and %L0. David
Re: use of extended asm on ppc for long long data types
On Apr 6, 2005, at 2:11 PM, David Edelsohn wrote: > Kumar Gala writes: Kumar> Is there anyway to specify a long long data type as a constraint to Kumar> extended asm for powerpc32. If so, how does one specify the registers Kumar> that would have the upper and lower bits The rs6000.md machine description has examples of patterns implementing 64-bit (DImode) operations in 32-bit mode. The constraint is a normal "r" or "b" GPR constraint. GCC allocates pairs of consecutive registers to hold the 64-bit value in 32-bit mode. When operating in big-endian, the MSB is in the first register and the LSB is the second register (R+1); in little-endian mode, the two registers are reversed. The PowerPC port defines a special print_operand modifier %L to refer to R+1, e.g., for operand 0, one would write assembly code referring to %0 and %L0. This is great, can I beg of you to update the gcc docs to include this note for the rs6000 extended asm section. thanks - kumar
Re: Question about "#pragma pack(n)"
On Tue, 2005-04-05 at 21:20, feng qiu wrote: > In c-pragma.c file, #pragma pack(n) set the value of > "maximum_field_alignment". > And in opts.c file,-fpack-struct set "flag_pack_struct = 1" . > But I don't known the relation between them. Try using grep, as in "grep flag_pack_struct *.c" and "grep maximum_field_alignment *.c". > It seems that they relate to the four ariablesââ > DECL_ALIGN,DECL_PACKED,TYPE_PACKED,and TYPE_ALIGN in stor-layout.c file,but > what is the difference in them?Should I modify this file? If you really want to modify files, and submit a patch, you have to use current mainline sources. This stuff works differently on mainline than it does in the older sources you are looking at. We can't accept a patch based off of an older release. Yes, you are looking in the right place. TYPE_PACKED and maximum_field_alignment are the important ones for this particular problem. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: 3.4.3 on Solaris9, boehm-gc probs.
On Wed, 6 Apr 2005, Eric Botcazou wrote:
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:110: error: syntax
error before "_DYNAMIC"
/export/home/Scratch/hgs/gcc-3.4.3/boehm-gc/dyn_load.c:111: error:
`Elf32_Dyn' undeclared (first use in this function)
Elf32_Dyn is supposed to be defined in /usr/include/sys/link.h:
Grep -C 5 gives me:
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
Elf32_Off d_off;
} d_un;
} Elf32_Dyn;
#if (defined(_LP64) || ((__STDC__ - 0 == 0) && (!defined(_NO_LONGLONG
typedef struct {
Elf64_Xword d_tag; /* how to interpret value */
union {
--
unsigned long l_addr; /* address at which object is mapped */
char*l_name;/* full name of loaded object */
#ifdef _LP64
Elf64_Dyn *l_ld; /* dynamic structure of object */
#else
Elf32_Dyn *l_ld; /* dynamic structure of object */
#endif
Link_map * l_next; /* next link object */
Link_map * l_prev; /* previous link object */
char*l_refname; /* filters reference name */
};
typedef struct {
Elf32_Sword d_tag; /* how to interpret value */
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
Elf32_Off d_off;
} d_un;
} Elf32_Dyn;
Here's what I get with -H:
Sorry? -H applied to what command?
[...]
--
Eric Botcazou
Thank you,
Hugh
Re: 3.4.3 on Solaris9, boehm-gc probs.
> > Here's what I get with -H: > > Sorry? -H applied to what command? The GCC command line you pasted. -- Eric Botcazou
re: gcc-3.4-20050401 BUG? generates illegal instruction in X11R6.4.2/mkfontscale/freetypemacro
Clemens Koller wrote: + ../../../exports/bin/mkfontscale /usr/X11R6/lib/X11/fonts/Type1 make[4]: *** [install] Error 132 Can you try to produce a standalone test case that doesn't require building all of X? e.g. can you save the preprocessor output from the mkfontscale compiler run, compile that on a different system, and reproduce the problem, preferably with a single known font file? - Dan
gcc-3.3-20050406 is now available
Snapshot gcc-3.3-20050406 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050406/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.3 CVS branch with the following options: -rgcc-ss-3_3-20050406 You'll find: gcc-3.3-20050406.tar.bz2 Complete GCC (includes all of below) gcc-core-3.3-20050406.tar.bz2 C front end and core compiler gcc-ada-3.3-20050406.tar.bz2 Ada front end and runtime gcc-g++-3.3-20050406.tar.bz2 C++ front end and runtime gcc-g77-3.3-20050406.tar.bz2 Fortran 77 front end and runtime gcc-java-3.3-20050406.tar.bz2 Java front end and runtime gcc-objc-3.3-20050406.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.3-20050406.tar.bz2The GCC testsuite Diffs from 3.3-20050330 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
