[Bug tree-optimization/31797] gcc-4.2.0 racing
--- Comment #7 from joel at oarcorp dot com 2007-05-06 17:00 --- It is definitely a regression against 4.1.2. It is probably a regession against 4.0. We have been compiling this code with the same compile options since September 2006 using the latest gcc releases possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
[Bug ada/32640] New: Binding for pthread_sigmask not same as other ports
The Ada run-time has changed its expectation for the prototype of pthread_sigmask. The RTEMS specific file does not compile. This small patch fixes it. 2007-07-05 Joel Sherrill <[EMAIL PROTECTED]> * s-osinte-rtems.ads: Correct prototype of pthread_sigmask. -- Summary: Binding for pthread_sigmask not same as other ports Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at oarcorp dot com GCC build triplet: any GCC host triplet: any GCC target triplet: *-*-*rtems* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32640
[Bug ada/32640] Binding for pthread_sigmask not same as other ports
--- Comment #1 from joel at oarcorp dot com 2007-07-05 18:30 --- Created an attachment (id=13853) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13853&action=view) Patch to make this file compile With this patch, I have been able to successfully compile GNAT for 7 target architectures supported by RTEMS, run the ACATS on two of them and an Ada hello world on most of them. Could someone please apply this to the head and 4.2 branch before 4.2.1 freezes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32640
[Bug target/19421] [4.0/4.1 regression] ICE with soft-float on m68k
--- Additional Comments From joel at oarcorp dot com 2005-08-19 16:02 --- Subject: Re: [4.0/4.1 regression] ICE with soft-float on m68k Why did you turn this from m68k-* to m68k-rtems? It was reported against m68k-rtems but would have be duplicated on at least m68k-elf if not any other m68k target. Even the fix is clearly not RTEMS specific. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From joel at oarcorp dot com 2005-05-16 14:00 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org wrote: > --- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14 > 08:33 --- > (In reply to comment #16) > >>Subject: Re: Segfault while compiling > > libgfortran/intrinsics/selected_int_kind.f90 > >> >>On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: >> >> >>>* f95 disqualifies ifselves from several embedded targets, if it can >>>not be >>>built/used on targets not supporting REAL8. IIRC, there even exist >>>variants of >>>major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. >>>IMO, this is a design flaw, which should be in your interest to be >>>circumvented. >> >>Huh, PPC soft float supports REAL 8 still. > > > Joel, do you recall the target in RTEMS which has 4-byte floats only? > (We recently had an issue with it floating point context sizes related to it? > IIRC, it had been a powerpc variant and we were forced to drop it because GCC > doesn't support it. I don't know of any specific models. The code in RTEMS was based upon an early (mid-90's) version of the PowerPC Programming Environments Manual. I recall that version of the manual as being clear that a single precision PowerPC was possible within the architectural definition. I just downloaded the current one from FreeScale and I see no hint that this architectural option is allowed anymore. > BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't > have 8byte floats. RTEMS doesn't support them, so I've never tried to build > fortran for then. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug ada/21247] Cross-building gnat-4.0.0 requires native gnat-4.0.0
--- Additional Comments From joel at oarcorp dot com 2005-05-18 13:23 --- Subject: Re: Cross-building gnat-4.0.0 requires native gnat-4.0.0 charlet at gcc dot gnu dot org wrote: > --- Additional Comments From charlet at gcc dot gnu dot org 2005-05-18 > 07:43 --- > Right, this is a requirement to first build a native GNAT version x.y to > build a cross GNAT x.y I was pretty sure someone told me that a LONG time ago and I made it a personal rule. When on a new machine, I use the AdaCore binary to build a native, then use that to build crosses. After that, I just keep building natives from the latest native I have installed. Could you suggest a patch for install.texi which corrects the tool requirements for building GNAT both natively and cross? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21247
[Bug target/19663] LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS
--- Additional Comments From joel at oarcorp dot com 2005-01-28 12:24 --- Subject: Re: LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS ebotcazou at gcc dot gnu dot org wrote: > --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28 > 08:16 --- > >>IMO, sparc.h's LINK_GCC_C_SEQUENCE_SPEC probably is specific to solaris and >>not >>generally applicable. May-be, it's an historic artefact. > > > As I already said, it is generally applicable and not specific to Solaris, in > that it should be the default behaviour for a generic linker. > > And it is not an historic artifact either (it was added relatively recently, > see > the link I already pointed at). We agreed with you and the patch doesn't impact any target beside RTEMS. Our link rules are not those of Solaris. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19663
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-01-31 15:23 --- Subject: Re: gnat tools not buildable cross neroden at gcc dot gnu dot org wrote: > --- Additional Comments From neroden at gcc dot gnu dot org 2005-01-29 > 22:19 --- > >>You may try adding a gnattools directory, whose makefile and configury is > > based > >>on libada's, but which is a host module rather than a target module. > > > Correct (dammit). :-) > > I've already done this on the libada-gnattools-branch, > but I've also done some other things there, which wouldn't be suitable for > stage 3. Please try a snapshot of the libada-gnattools-branch from... hmm, > let's see... December 1, 2004. Where are these snapshots? Or exactly how do you want it checked out from CVS. > If it works correctly (and I know it works correctly for native tools), > it's safe enough to merge to mainline even in stage 3. I would have done so > already, but without a bug report, it wasn't stage-3-suitable. There is now a bug report against 4.x and there was at least a lot of whining for 3.3 and 3.4. :) > If it doesn't, come back to me; I expect that there's some incremental change > on top of it which should sort out any remaining problems. Great. Point me in the right direction and I will be happy to test. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-01-31 15:24 --- Subject: Re: gnat tools not buildable cross charlet at adacore dot com wrote: > --- Additional Comments From charlet at adacore dot com 2005-01-31 09:21 > --- > Subject: Re: gnat tools not buildable cross > > >>Since it is clearly a regression (vs 3.2 cross RTEMS/Ada capabilities), would >>you mind proposing a patch to current 4.0 libada? I've included Arnaud in CC. If he can prepare a patch vs 4.0 CVS, I am willing to test it. > There must be a simpler way to fix this regression. I am not even convinced > that this change would fix this particular bug anyway, so we first need this > info before proceeding. Agreed. If it doesn't work on the libada branch, there there is no fix at hand. Even if it does, then a patch against 4.0 would have to be evaluated. > Such major addition is not suitable for stage 3 in my opinion (but very > welcome for stage 1), we want a much more localized change, which is certainly > possible here. That's what the RM is for. Let's get a solution first and then see if it meets the criteria. No point saying it doesn't without knowing. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-02-01 00:46 --- Subject: Re: gnat tools not buildable cross charlet at adacore dot com wrote: > --- Additional Comments From charlet at adacore dot com 2005-01-31 16:38 > --- > Subject: Re: gnat tools not buildable cross > > >>I don't think so. When you get into the libada directory, >>CC="$(CC_FOR_TARGET)" >>and all hope is lost of having the tools work in a cross configuration. > > > That is wrong, ada/Makefile.in is designed to support this configuration, > and use the native gnat bootstrap compiler instead of $(CC) to build the > tools in the case of cross compilation. FWIW I get the same error on the gcc-libada-gnattools-branch. Nathaniel are there any special instructions for cross Ada or is it just supported to work? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-02-03 12:24 --- Subject: Re: gnat tools not buildable cross neroden at gcc dot gnu dot org wrote: > --- Additional Comments From neroden at gcc dot gnu dot org 2005-02-03 > 00:57 --- > Joel, I'm suspicious that the result you got on the branch should also be > happening on mainline; it's happening in a code section which I haven't > touched. There's a suspicious-looking difference between Arnaud's configure > output for the GCC subdir and yours: > Arnauds: > checking for .preinit_array/.init_array/.fini_array support... yes > Yours: > checking for .preinit_array/.init_array/.fini_array support... no What is this checking? Host, target? My host compiler is: bash-2.05$ type gcc gcc is /opt/gcc-40-CVS/bin/gcc bash-2.05$ type gnatmake gnatmake is /opt/gcc-40-CVS/bin/gnatmake bash-2.05$ gcc --version gcc (GCC) 4.0.0 20050113 (experimental) Same version for gnatmake. Some targets do see to fail with errors indicating different exception models. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-02-07 22:41 --- Subject: Re: gnat tools not buildable cross laurent at guerby dot net wrote: > --- Additional Comments From laurent at guerby dot net 2005-02-06 10:02 > --- > (In reply to comment #19) > > Nathanel I confirm your small patch (+autoconf) restores Ada cross x86 to > powerpc-rtems build, and I've even been able to powerpc-rtems-gnatmake Ada > examples and run them on gdb psim. It also does not break native bootstrap as > far as I can tell, so all looks good for commit testing wise. > > Thanks for helping! Is everything in CVS? I can't reproduce this yet. I had trouble with previously installed cross toolsets getting in the way but removed them and got past that. I checked my procedure versus Laurent's revised instructions and end with this. checking for gcc... /usr3/ftp_archive/gnu/gcc/ss/b-head/b-powerpc-rtems4.7/gcc/xgcc -B/usr3/ftp_archive/gnu/gcc/ss/b-head/b-powerpc-rtems4.7/gcc/ -nostdinc -B/usr3/ftp_archive/gnu/gcc/ss/b-head/b-powerpc-rtems4.7/powerpc-rtems4.7/newlib/ -isystem /usr3/ftp_archive/gnu/gcc/ss/b-head/b-powerpc-rtems4.7/powerpc-rtems4.7/newlib/targ-include -isystem /usr3/ftp_archive/gnu/gcc/ss/b-head/gcc-libada-gnattools-branch/newlib/libc/include -B/opt/rtems-test/powerpc-rtems4.7/bin/ -B/opt/rtems-test/powerpc-rtems4.7/lib/ -isystem /opt/rtems-test/powerpc-rtems4.7/include -isystem /opt/rtems-test/powerpc-rtems4.7/sys-include checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-02-08 00:01 --- Subject: Re: gnat tools not buildable cross neroden at gcc dot gnu dot org wrote: > --- Additional Comments From neroden at gcc dot gnu dot org 2005-02-07 > 23:15 --- > Closing. Laurent, I may ask you to test my alternate solution later (when > it's ready) though, OK? Is a fix likely to get into 4.0? FYI Once I am able to build, the next issue is that the Ada libraries do not look into newlib's headers and do not have a way to let a target add specific include directories. See gcc/config/t-rtems for the OS specific newlib include directory we need. With that resolved, I think it could build in a single pass. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-02-08 19:16 --- Subject: Re: gnat tools not buildable cross neroden at gcc dot gnu dot org wrote: > --- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 > 18:30 --- > >>Is a fix likely to get into 4.0? > > Yes, the hackish fix is in. I hope to get the cleaner fix in, but who knows. > > >>FYI Once I am able to build, the next issue is that the Ada libraries >>do not look into newlib's headers and do not have a way to let a >>target add specific include directories. See gcc/config/t-rtems for >>the OS specific newlib include directory we need. With that resolved, >>I think it could build in a single pass. > > I wouldn't want to touch this until substantially more of the branch went in, > so that's probably a 4.1 issue. I need to get to test this first but I think the mistake in the gcc/ada/Makefile.in is actually quite simple. It has this: GNATLIBCFLAGS_FOR_C = $(GNATLIBCFLAGS) $(TARGET_LIBGCC2_CFLAGS) -fexceptions \ -DIN_RTS $(TARGET_LIBGCC2_CFLAGS) is not sufficient to find all the newlib headers. But the gcc/Makefile.in also uses $(LIBGCC2_INCLUDES) which is target specific when compiling libgcc2. LIBGCC2_INCLUDES is primarily set by RTEMS, VxWorks, and Cygwin. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-02-09 12:44 --- Subject: Re: gnat tools not buildable cross neroden at twcny dot rr dot com wrote: > --- Additional Comments From neroden at twcny dot rr dot com 2005-02-09 > 07:13 --- > Subject: Re: gnat tools not buildable cross > > joel at oarcorp dot com wrote: > >>--- Additional Comments From joel at oarcorp dot com 2005-02-08 19:16 >>--- >>Subject: Re: gnat tools not buildable cross >> >>neroden at gcc dot gnu dot org wrote: >> >> >>>--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 >>>18:30 --- >>> >>> >>> >>>>Is a fix likely to get into 4.0? >>> >>>Yes, the hackish fix is in. I hope to get the cleaner fix in, but who >>>knows. >>> >>> >>> >>> >>>>FYI Once I am able to build, the next issue is that the Ada libraries >>>>do not look into newlib's headers and do not have a way to let a >>>>target add specific include directories. See gcc/config/t-rtems for >>>>the OS specific newlib include directory we need. With that resolved, >>>>I think it could build in a single pass. >>> >>>I wouldn't want to touch this until substantially more of the branch went >>>in, >>>so that's probably a 4.1 issue. >> >> >>I need to get to test this first but I think the mistake in the >>gcc/ada/Makefile.in is actually quite simple. It has this: >> >> >>GNATLIBCFLAGS_FOR_C = $(GNATLIBCFLAGS) $(TARGET_LIBGCC2_CFLAGS) >>-fexceptions \ >> -DIN_RTS >> >> >>$(TARGET_LIBGCC2_CFLAGS) is not sufficient to find all the newlib >>headers. But the gcc/Makefile.in also uses $(LIBGCC2_INCLUDES) which is >>target specific when compiling libgcc2. LIBGCC2_INCLUDES is primarily >>set by RTEMS, VxWorks, and Cygwin. >> >>What do you think? > > > Hmm. You could be right. :-) > > The trouble is that there's several layers of Makefiles and Makefile > fragments and configures and configure fragments taking bits from each > other, and so it's not as absolutely trivial to get LIBGCC2_INCLUDES in > the right places cleanly -- without misapplying it in cross cases -- as > it ought to be. This, of course, is what my cleanups are designed to > fix; it *should* be trivial to get it in the right places. :-) I played with this overnight and the variable missing in ada/Makefile.in is FLAGS_FOR_TARGET. It shoudl be included in GNATLIBCFLAGS_FOR_C and I can't seem to get it from the top level configure all the way down. Do you have any idea how to get it down that far? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From joel at oarcorp dot com 2004-11-03 21:09 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h bkoz at gcc dot gnu dot org wrote: > --- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-03 00:12 > --- > > Joel, you might want to talk to the m68k maintainers. > > Take your pick: > m68hc11 portStephane Carrez [EMAIL PROTECTED] > m68k port (?) Jeff Law[EMAIL PROTECTED] > m68k-motorola-sysv port Philippe De Muyter [EMAIL PROTECTED] > > Since you are the rtems maintainer, I'm expecting you to be on top of fixing > this, since it's currently seen as a m68k-rtems bug. > > This bug hasn't been framed in a clear manner, IMHO. There's no test case, no > patch file. If it's a generic m68k problem with 68060 and libstdc++ atomicity, > it should be marked as such (and not rtems-specific.) If this has nothing to do > with libstdc++, but instead has something to do with gcc or rtems, well, the > category on this bug should reflect this. > > Hope this helps. It does and just reiterates what shuold have been done when it was reported. Chris is going to try to put together a test case. What we are concerned about is that it is more than likely a generic problem. Very few problems are RTEMS specific at this level. Chris believes that a 16-bit variable may be allocated on the stack and this would result in it being misaligned. This is likely the issue. The MC68060 can't do misaligned accesses for the instruction in question. On a MC68060 without software emulation of missing instructions, then you get a fault. So the concern is that this is a generic m680x0 issue with letting the stack get misaligned and it just gets caught in this one very complex C++ scenario. Don't close it yet and give Chris a chance to give a test case. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From joel at oarcorp dot com 2004-11-03 22:56 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h schwab at suse dot de wrote: > --- Additional Comments From schwab at suse dot de 2004-11-03 22:25 --- > On the m68k the biggest alignment has traditionally only been 2 bytes > (inherited from the Sun compiler, AFAIK), and it's only overridden on NetBSD > (and previously on some configurations that are removed now) or when using > -malign-int. So unless you change that (which of course changes the ABI) > you'll continue to get unaligned long words somewhere. Then I think the m68060 breaks that rule by not supporting a number of m68040 integer and FP instructions. They provide software to handle traps for unimplemented instructions but for performance reasons it is best to avoid generating them in the first place. This is similar to how the 68040's reduced FP capabilities relative to the 68881/2 was handled. http://www.freescale.com/files/product/doc/MC68060AR_D.pdf (hand-typed .. sorry) describes the differences between a 68040 and 68040. On page 5, it specifically mentions that the CAS and CAS2 "Unlike the MC68040, the MC68060 supports the CAS instruction with misaligned operands, and all CAS2 variants, only via software emulation." Table 7 on page 11, gives a full list of unimplemented integer instructions. Off the cuff, one possible solution is that _Atomic_word does not have a required alignment. I know it is possible to force alignment on a variable. Can the same be done with a type? T Or is the solution to do as Andreas suggests and turn on the -malign-int option by default on the MC68060? I wouldn't think that making the alignment 4 bytes on the MC68060 target would be a huge impact since those should be relatively large memory targets board configurations anyway. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From joel at oarcorp dot com 2004-11-03 23:25 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h cjohns at cybertec dot com dot au wrote: > --- Additional Comments From cjohns at cybertec dot com dot au 2004-11-03 23:05 > --- > Does this mean the instruction in question (cas) in atomicity.h cannot be used > on the 68060 if the stack can be aligned to a 2 byte boundary ? Not if the memory to be swapped is on the stack. The memory could be in global memory and be properly aligned. Grrr... I forgot you can do this with GCC: typedef unsigned int _Atomic_word __attribute__ ((aligned (4))); Wouldn't changing the definition for the m68k to the above fix this? > Would a stack aligned this way cause a slow down if the call/ret address being > pushed and popped is not aligned to a 32bit boundary ? I suspect it would but don't know the MC68060 enough to state that authoritatively. > I do not full understand the ABI issues hence my next question. RTEMS + > application is built as a single executable, typically all with the same tool > set, so does an ABI issue exist in our case ? If you can find something in a FreeScale document showing improved performance for aligned accesses on the MC68060, that would tell me that for RTEMS, we want mc68060 to imply stricter alignment. I would bet that others would as well if a performance increase is obtained. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From joel at oarcorp dot com 2004-11-04 14:56 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h schwab at suse dot de wrote: > --- Additional Comments From schwab at suse dot de 2004-11-03 23:44 --- > Even the 68020 should already show slight improvement when using 4 byte > aligment due to the 32 bit data bus (the 68000/010 only have a 16 bit data > bus). > > Adding an aligned attribute to the _Atomic_int type doesn't help for automatic > variables as gcc limits the alignment to STACK_BOUNDARY. But it will work for > static variables. > > About the ABI change you are of course safe if everything is using the changed > aligment (including the interface to the RTEMS kernel). > That is certainly an option for RTEMS but I am still not sure since I believe this is a problem across more targets. At least, m68k-elf and m68k-coff have the same issue and I am willing to argue that this could show up on a Linux or BSD system. I started with the documentation for -m68060 which implies that the intent is to not generate instructions which have to be emulated. But here we are looking at a piece of manually written code that violates that assumpion since m68060 does not also imply tighter alignment. `-m68060' Generate output for a 68060. This is the default when the compiler is configured for 68060-based systems. This option inhibits the use of 68020 and 68881/68882 instructions that have to be emulated by software on the 68060. Use this option if your 68060 does not have code to emulate those instructions. There is a m68020-60 option which allows the use of emulated instructions. So GCC claims to be making a distinctions. And G... I just found in the MC68060 Programmer's Guide that the unaligned CAS instructions aren't in the emulation package for the 68060. So this is broken whether or not you are using the emulation package. It just isn't there on the 68060. Can _Atomic_word actually be a byte? Does CAS.B work? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From joel at oarcorp dot com 2004-11-04 16:37 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h schwab at suse dot de wrote: > --- Additional Comments From schwab at suse dot de 2004-11-04 15:12 --- > My copy of the 68060 user manual says that the MC68060ISP does contain an > emulation for unaligned CAS. > OK. Likely yours is newer and they fixed that. So this is back to being primarily an embedded systems issues. I still wonder if since the -m68060 flag says it avoids emulated instructions, if that switch should imply stricter alignment while the -m68020-60 should not. What about that? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From joel at oarcorp dot com 2004-11-04 19:11 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h schwab at suse dot de wrote: > --- Additional Comments From schwab at suse dot de 2004-11-04 16:53 --- > You can't just increase the alignment as that would break the ABI. Are we stuck with requiring the 68060 ISP package even when -m68060 is specified and it says no emulated instructions are used? GCC ALMOST meets the no ISP requirement with the -m68060 argument but can't do it completely without breaking the ABI. Grrr.. I hate to suggest this but is it possible to add a -m68060-noisp option to increase the alignment and avoid the rest of the issues. I don't want to change the code generation rules/ABI for the -m68060 argument, so I think we are stuck clarifying the documentation to include that it maintains ABI compatability and in doing so may generate code which violates strict alignment requirements. To support these edge conditions you must have the ISP. Any other thoughts? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug target/18542] [3.4 only] ICE: output_operand: invalid expression as operand
--- Additional Comments From joel at oarcorp dot com 2004-11-18 14:13 --- Subject: Re: [3.4 only] ICE: output_operand: invalid expression as operand corsepiu at gcc dot gnu dot org wrote: > --- Additional Comments From corsepiu at gcc dot gnu dot org 2004-11-18 > 13:14 --- > The same ICE occurs for avr-rtems* and h8300-rtems* toolchains having been > built > from the same sources. > > I have 3.2.3 and 3.3.5 RTEMS tools installed and tried this for the m68k. It looks OK there. So it must be a 3.4.x specific issue. What other targets/versions do you want to try? + /opt/rtems-4.6/bin/m68k-rtems-gcc --version m68k-rtems-gcc (GCC) 3.2.3 (OAR Corporation gcc-3.2.3-20040420/newlib-1.11.0-20030605-4) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + /opt/rtems-4.6/bin/m68k-rtems-gcc -O1 -c cpuboot.c + /opt/rtems-4.7/bin/m68k-rtems4.7-gcc --version m68k-rtems4.7-gcc (GCC) 3.3.5 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + /opt/rtems-4.7/bin/m68k-rtems4.7-gcc -O1 -c cpuboot.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542
[Bug target/18542] [3.4 only] ICE: output_operand: invalid expression as operand
--- Additional Comments From joel at oarcorp dot com 2004-11-18 14:26 --- Subject: Re: [3.4 only] ICE: output_operand: invalid expression as operand corsepiu at gcc dot gnu dot org wrote: > --- Additional Comments From corsepiu at gcc dot gnu dot org 2004-11-18 > 13:14 --- > The same ICE occurs for avr-rtems* and h8300-rtems* toolchains having been > built > from the same sources. > > A bit more follow up. Again the 4.6 tools are gcc 3.2.3 based and the 4.7 are gcc 3.3.5. + /opt/rtems-4.6/bin/arm-rtems-gcc -O1 -c cpuboot.c + /opt/rtems-4.6/bin/h8300-rtems-gcc -O1 -c cpuboot.c + /opt/rtems-4.6/bin/i386-rtems-gcc -O1 -c cpuboot.c + /opt/rtems-4.6/bin/i960-rtems-gcc -O1 -c cpuboot.c + /opt/rtems-4.6/bin/m68k-rtems-gcc -O1 -c cpuboot.c + /opt/rtems-4.6/bin/mips-rtems-gcc -O1 -c cpuboot.c + /opt/rtems-4.6/bin/powerpc-rtems-gcc -O1 -c cpuboot.c + /opt/rtems-4.6/bin/sh-rtemself-gcc -O1 -c cpuboot.c + /opt/rtems-4.6/bin/sh-rtems-gcc -O1 -c cpuboot.c + /opt/rtems-4.6/bin/sparc-rtems-gcc -O1 -c cpuboot.c + /opt/rtems-4.7/bin/arm-rtems4.7-gcc -O1 -c cpuboot.c + /opt/rtems-4.7/bin/i386-rtems4.7-gcc -O1 -c cpuboot.c + /opt/rtems-4.7/bin/m68k-rtems4.7-gcc -O1 -c cpuboot.c + /opt/rtems-4.7/bin/mips64-rtems4.7-gcc -O1 -c cpuboot.c + /opt/rtems-4.7/bin/mips-rtems4.7-gcc -O1 -c cpuboot.c + /opt/rtems-4.7/bin/powerpc-rtems4.7-gcc -O1 -c cpuboot.c + /opt/rtems-4.7/bin/sh-rtemself4.7-gcc -O1 -c cpuboot.c + /opt/rtems-4.7/bin/sparc-rtems4.7-gcc -O1 -c cpuboot.c I tried it again at -O4 and it all compiled fine. I think it is pretty safe to assume at this point that the problem is specific to 3.4. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542
[Bug regression/18643] [3.4 Regression] fixincludes breaks RTEMS
--- Additional Comments From joel at oarcorp dot com 2004-11-24 15:50 --- Subject: Re: [3.4 Regression] fixincludes breaks RTEMS corsepiu at gcc dot gnu dot org wrote: > --- Additional Comments From corsepiu at gcc dot gnu dot org 2004-11-24 > 15:02 --- > (In reply to comment #1) > >>Nothing in fixincludes look wrong. The new fixincludes do not apply to > > limits.h at all. > > But the old one probably did. The limits.h gcc-3.4 < 2004-11-17 produced, > contains fragments of limitx.h, which I presume to be having been added by > fixincludes and friends. > > >>Does this work on the mainline, > > I don't know, it's been a while since mainline built successfully for me. > Yesterday's mainline did not build at all. > > >>I assume so as HP could build MMIX just recently, earlier today. >>Are you sure that this is not a newlib bug but then again HP built MMIX with > > the combined tree. > > I would not want to exclude this possibility. Throughout the years, there > repeatedly had been issues with RTEMS/newlib's limits.h. > > Also, note: RTEMS limits.h-machinery is not identical with generic newlib's > limits.h machinery. RTEMS has custom limits.h and syslimits.h in newlib's > sources. > > Furthermore, diffing the gcc-sources didn't reveal anything obivous. > > However, I noticed the following when diffing my build-logs: > > @@ -10319,7 +10327,7 @@ > chmod a+r include/syslimits.h) > Fixing headers into > /users/rtems/src/rpms/BUILD/rtems-4.7-avr-rtems4.7-gcc-newlib-gcc3.4.4newlib1.12.0/build/gcc/include > for avr-unknown-rtems4.7 target > echo timestamp > stmp-fixinc > -if true ; then \ > +if [ -f > /opt/rtems-4.7/lib/gcc/avr-rtems4.7/3.4.4/../../../../avr-rtems4.7/sys-include/limits.h > ] ; then \ >cat ../../gcc-3.4.4/gcc/limitx.h ../../gcc-3.4.4/gcc/glimits.h > ../../gcc-3.4.4/gcc/limity.h > tmp-xlimits.h; \ > else \ >cat ../../gcc-3.4.4/gcc/glimits.h > tmp-xlimits.h; \ > > So the actual question is: > What has set LIMITS_H_TEST to "true" before, and why isn't it set true > anymore? gcc/config/t-rtems in gcc 3.3.5 and the version on the 3.4 branch are the same example the 3.3.5 version has this: # RTEMS uses newlib which does not require prototype fixing STMP_FIXPROTO = There was a patch about 15 months ago moving that logic to config.gcc. Is fixproto being set to yes somehow in config.gcc for avr-rtems? Do you have a special stanza in your config.gcc for that target that is not checked in? The checked in source only has avr-*-* and ends up setting fixproto=yes. That would explain this. Does this happen on other targets? --joel > I am seeing further substancial differences in the build-log, but the diff > above > seems to be the origin of this breakdown. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18643
