[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 --- Comment #14 from Larry Baker --- (In reply to Waldemar Brodkorb from comment #11) > diff -Nur gcc.orig/libgcc/config.host gcc/libgcc/config.host > --- gcc.orig/libgcc/config.host 2016-02-26 21:02:28.0 +0100 > +++ gcc/libgcc/config.host2016-04-29 09:18:40.377989160 +0200 > @@ -812,7 +812,7 @@ > m68k*-*-openbsd*) > ;; > m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux with uClibc > - tmake_file="$tmake_file m68k/t-floatlib m68k/t-linux" > + tmake_file="$tmake_file m68k/t-floatlib" > md_unwind_header=m68k/linux-unwind.h > ;; > m68k-*-linux*) # Motorola m68k's running GNU/Linux This is exactly the same patch I was referring to in Comment #9 that I used to work around the problem for gcc 4.7 and 4.8 in 2012 (see Bug 53833).
[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 --- Comment #9 from Larry Baker --- To answer Waldemar's question, that is exactly how I worked around the problem for gcc 4.7 and 4.8 in 2012 (see Bug 53833). That enabled me to have a functioning gcc for ColdFire. I used it to fix broken stack limit checking for ColdFire processors. I never tried to use it for building any system components, such as Jeff describes.
[Bug fortran/58276] New: make install-host gfortran is not functional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276 Bug ID: 58276 Summary: make install-host gfortran is not functional Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: baker at usgs dot gov Background I am using the Open Embedded/Yocto Project bitbake machinery to build an embedded system. I actually use a derivative, called ELDK, from DENX. The git download and a sample build procedure are at http://www.denx.de/wiki/view/ELDK-5/EldkBuilding. The build procedure creates both a cross toolchain on the development host and a custom rootfs image for the target device. By default, GNU 4.7.2 C and C++ cross compilers are created and used to create the rootfs image. I also need Fortran for my application, so I enable the bitbake GCC build recipe to include fortran in the --enable-languages= configure option. Problem The build procedure produces all three cross compilers I need: gcc, g++, and gfortran. gcc and g++ are functional. However, gfortran fails in the link step with the error: arm-linux-gnueabi-gfortran: error: libgfortran.spec: No such file or directory. This is true; there is no libgfortran.spec in the cross compilers directory tree. Diagnosis When I have built my own gfortran ARM cross compilers, I do not have this problem. And, there are many libgfortran.* files in the gfortran cross compiler directory in addition to libgfortran.spec. I use make install as the last step when I made my own gfortran. However, I found the bitbake GCC build recipe uses make install-host. The difference is, the bitbake GCC build recipe leaves off the make install-target step. I experimented with various make install commands using my own gfortran ARM cross compiler build. I verified that libgfortran.spec is not created by make install-host, but is created by make install-target. (See http://lists.denx.de/pipermail/eldk/2013-August/002356.html for a detailed explanation of of my diagnosis.) I Think This Is a Bug I am not sure what my expectation should be after a make install-host. I cannot find any documentation of the differences between make install, make install-host, and make install-target. Given that the bitbake GCC build recipes use make install-host, I assume make install-host is intended to install functional cross compilers on a development host. That is my expectation. Indeed, as I mentioned, the gcc and g++ cross compilers work fine. If that is true, then make install-gcc is broken when it leaves out libgfortran.spec, and any other libgfortran.* files that are required for cross compilations, as part of the gfortran install step. At a minimum, I would think an empty libgfortran.spec should be created (assuming the compiler will accept that), which should then be replaced by the proper libgfortran.spec when a make install-libgfortran is executed. Thank you. Larry Baker US Geological Survey
[Bug fortran/58276] make install-host gfortran is not functional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276 --- Comment #2 from Larry Baker baker at usgs dot gov --- Andrew, On 29 Aug 2013, at 4:31 PM, pinskia at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- libgfortran.spec is part of the target library libgfortran so you need to install the target libraries. If the build mechanism for Yocto/OE does not do that, then it a bug there and not in GCC. Yes, this is exactly what I described in my post. The question I have is, what is the intended behavior of a GCC make install-host with regard to the functioning of the compilers. gcc and g++ are functional; gfortran is not. Is that what the GCC maintainers expect? Is that what the gfortran maintainers expect? Where can I read about the distinction between make install, make install-host, and make install-target? Is make install-host supposed to install usable compilers? -- You are receiving this mail because: You reported the bug. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov
[Bug fortran/58276] make install-host gfortran is not functional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276 --- Comment #4 from Larry Baker baker at usgs dot gov --- I suppose a different way of asking whether this should be considered a bug is to ask what should gfortran's behavior be when libgfortran.spec is missing? Is the correct behavior to continue with the link step as though libgfortran.spec were empty? Which, I assume, would require the link command to specify all its libraries explicitly. Do you think this is really just gfortran being overly picky? Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov On 29 Aug 2013, at 4:43 PM, Larry Baker wrote: Andrew, On 29 Aug 2013, at 4:31 PM, pinskia at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- libgfortran.spec is part of the target library libgfortran so you need to install the target libraries. If the build mechanism for Yocto/OE does not do that, then it a bug there and not in GCC. Yes, this is exactly what I described in my post. The question I have is, what is the intended behavior of a GCC make install-host with regard to the functioning of the compilers. gcc and g++ are functional; gfortran is not. Is that what the GCC maintainers expect? Is that what the gfortran maintainers expect? Where can I read about the distinction between make install, make install-host, and make install-target? Is make install-host supposed to install usable compilers? -- You are receiving this mail because: You reported the bug. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov
[Bug fortran/58276] make install-host gfortran is not functional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
--- Comment #6 from Larry Baker baker at usgs dot gov ---
Andrew,
On 29 Aug 2013, at 4:50 PM, pinskia at gcc dot gnu.org wrote:
I think the bitbake build builds the compiler twice, once to build glibc and
then again to build the target libraries. The second time it uses make
install
rather than make install-host.
That is what I thought too, but it is not the case, as far as I can tell.
There are recipes for the initial gcc cross and the final gcc cross, and a gcc
for an SDK system and the target. The make install step is done in the
package recipes. They all use make install-host:
# find /mnt/opt/git/eldk -name gcc\*package\* -exec grep oe_runmake {} ';' -ls
oe_runmake 'DESTDIR=${D}' install-host
11824964 -rw-rw-r-- 1 500 500 1915 Aug 18 22:58
/mnt/opt/git/eldk/meta/recipes-devtools/gcc/gcc-package-cross.inc
oe_runmake 'DESTDIR=${D}' install-host
11824984 -rw-rw-r-- 1 500 500 2336 Aug 18 22:58
/mnt/opt/git/eldk/meta/recipes-devtools/gcc/gcc-package-sdk.inc
oe_runmake 'DESTDIR=${D}' install-host
11824994 -rw-rw-r-- 1 500 500 3837 Aug 18 22:58
/mnt/opt/git/eldk/meta/recipes-devtools/gcc/gcc-package-target.inc
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
[Bug fortran/58276] make install-host gfortran is not functional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276 --- Comment #7 from Larry Baker baker at usgs dot gov --- Andrew, On 29 Aug 2013, at 4:50 PM, pinskia at gcc dot gnu.org wrote: Where can I read about the distinction between make install, make install-host, and make install-target? Is make install-host supposed to install usable compilers? Define usable compiler? A compiler which can be used to compile the target libraries (including glibc)? Then yes install-host is enough for that. If you define it as usable for full cross compiling, then no it is not enough. I know about the need to build a gcc twice for a cross development tool chain: once to build the minimal compiler to build the target libraries, and the final build for the tool chain. bitbake generates full cross development tool chains. From your description, make install-host is not sufficient; make install would be. When I have made my own gfortran ARM cross compiler, I have always done a make install, so it has been functional. I will investigate, but I think it is likely that the bitbake build system does the library installs in a separate recipe, and gcc and g++ support libraries are enabled by default. That would explain why their gcc and g++ cross compilers are functional and gfortran is not. I did not request a separate library installation step for libgfortran, since I never had to do that with my own build. Now that I know there are separate make installs, I think I can make progress. Thank you for your help. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov
[Bug inline-asm/58234] New: In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234
Bug ID: 58234
Summary: In-line asm version of __FD_ZERO in
/usr/include/bits/select.h
Product: gcc
Version: 4.4.7
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: baker at usgs dot gov
I encountered a run-time error using the -check=uninit Intel icc compiler
option on Linux:
Run-Time Check Failure: The variable '__d1' is being used without being
initialized
I tracked the problem to the FD_ZERO macro, which is ultimately expanded using
the __FD_ZERO macro in /usr/include/bits/select.h. A very simple program will
trigger the run-time failure:
#include sys/select.h
int main( void ) {
fd_set rfds;
FD_ZERO( rfds );
return 0;
}
Compiled with:
# icc -check=uninit intel.c
The fix is to disable the in-line asm code for __FD_ZERO; -no-gcc will suffice:
# icc -no-gcc -check=uninit intel.c
That is fine for this case. But the code I am working with needs other GNUC
header options that also get disabled when -no-gcc is used. If I add -no-gcc,
I get lots of compilation errors.
I realize this is not technically a GCC library/headers error. I think the
Intel icc compiler does not properly account for in-line asm side-effects in
its uninitialized variable tracking.
However, I decided to see if I could make the __FD_ZERO macro asm work. I was
able to rearrange the in-line asm for a workaround in this case. I think this
is an improvement, and also cures a subtle flaw in the original that (luckily)
makes absolutely no difference.
The original __FD_ZERO macro definition (in /usr/include/bits/select.h) is:
# define __FD_ZERO(fdsp) \
do { \
int __d0, __d1; \
__asm__ __volatile__ (cld; rep; __FD_ZERO_STOS \
: =c (__d0), =D (__d1) \
: a (0), 0 (sizeof (fd_set) \
/ sizeof (__fd_mask)), \
1 (__FDS_BITS (fdsp)[0]) \
: memory); \
} while (0)
I cannot tell exactly where in the expansion the Intel run-time error occurs --
gdb shows ?? for the backtrace beyond the Intel __intel_rtc_uninit_use()
service routine (compiled with -g):
(gdb) bt
#0 0x00130430 in __kernel_vsyscall ()
#1 0x001a3b11 in raise () from /lib/libc.so.6
#2 0x001a53ea in abort () from /lib/libc.so.6
#3 0x080489e1 in __intel_rtc_uninit_use ()
#4 0x0001 in ?? ()
#5 0x in ?? ()
The assembly language generated by gcc -O0 (-m32 or -m64) always includes a
store into __d0 and __d1 after the execution of the stosl/stosq instruction.
Maybe it is that store which is tripping up the Intel code.
I rewrote the asm to remove __d0 and __d1, since they go out-of-scope anyway
after the asm executes:
# define __FD_ZERO(fdsp) \
do {\
__asm__ __volatile__ (cld; rep; __FD_ZERO_STOS \
: \
: a (0), \
c (sizeof (fd_set) / sizeof (__fd_mask)), \
D (__FDS_BITS (fdsp)[0]) \
: memory);\
} while (0)
This generated slightly different code, which I believe is correct.
Here is the original assembly output for gcc -m32 and gcc -m64:
Original __FD_ZERO, gcc -m32
.filejunk.c
.text
.globl main
.typemain, @function
main:
pushl%ebp
movl%esp, %ebp
pushl%edi
subl$144, %esp
movl$0, %eax
movl$32, %ecx
leal-140(%ebp), %edx
movl%edx, %edi
#APP
# 45 junk.c 1
cld; rep; stosl
# 0 2
#NO_APP
movl%edi, %edx
movl%ecx, -12(%ebp)
movl%edx, -8(%ebp)
movl$0, %eax
addl$144, %esp
popl%edi
popl%ebp
ret
.sizemain, .-main
.identGCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-3)
.section.note.GNU-stack,,@progbits
Original __FD_ZERO, gcc -m64
.filejunk.c
.text
.globl main
.typemain, @function
main:
.LFB0:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
pushq%rbx
subq$32, %rsp
movl$0, %eax
movl$16, %edx
leaq-160(%rbp), %rbx
.cfi_offset 3, -24
movq%rdx, %rcx
movq%rbx, %rdi
#APP
# 45 junk.c 1
cld; rep; stosq
# 0 2
#NO_APP
movl%edi, %eax
movl%ecx, %edx
movl%edx, -24(%rbp)
movl%eax, -20(%rbp)
movl$0, %eax
[Bug inline-asm/58234] In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234 --- Comment #2 from Larry Baker baker at usgs dot gov --- Andrew, Thank you for your prompt reply. Fair enough. Can you direct me to where glibc bugs are reported? I have already filed a bug report with Intel. The in-line asm is not quite correct. But the flaw is benign. I would like to repair my replacement asm. The issue you raised is exactly what I am concerned about. Can you tell me how it is possible to specify the clobber side effects without requiring output constraints? Is it legal to specify output constraints without variables? I tried following the example 4 in the GCC-Inline-Assembly-HOWTO.html, which looks extremely similar to what I want. But, I received the error I wrote about. Thanks for your time. Larry Baker US Geological Survey
[Bug inline-asm/58234] In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234 --- Comment #4 from Larry Baker baker at usgs dot gov --- Actually, there is: the useless movl instead of a movq of the updated address pointer into __d1 on x86_64. But, that is a benign flaw. Can you answer either of my questions?
[Bug inline-asm/58234] In-line asm version of __FD_ZERO in /usr/include/bits/select.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234 --- Comment #6 from Larry Baker baker at usgs dot gov --- Thank you. The example I found (mov_blk) that does not use output constraints, but specifies that the input registers are clobbered, is from a 2003 document. It too fails using today's gcc. I appreciate your time.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #19 from Larry Baker baker at usgs dot gov 2012-11-26 19:44:21 UTC --- (In reply to comment #18) Ian, You can also add linker options via the configure options --with-stage1-ldflags and --with-boot-ldflags, q.v. So, I read what the GCC configure notes had to say about --with-boot-ldflags=flags, and it sounds like exactly what Sourceery was trying to do with --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'. That is, the default is to statically link the C and C++ run-time libraries. --with-boot-ldflags=flags This option may be used to set linker flags to be used when linking stage 2 and later when bootstrapping GCC. If neither –with-boot-libs nor –with-host-libstdcxx is set to a value, then the default is `-static-libstdc++ -static-libgcc'. Although it is not documented specifically for GCC, you can also set LDFLAGS when running make, as you can for all GNU programs. I might have already tried this and it fails. (I can't remember exactly.) Take a look at my Comment 6 from 2012-09-21 20:34:41. You'll see that the GCC build machinery overrides CFLAGS and LDFLAGS with CFLAGS_FOR_BUILD and LDFLAGS_FOR_BUILD, respectively. I think your first suggestion is definitely the best solution. The next time I work on this, I'll check the results of the link of the cross gcc to see if the default stage 2 build really does eliminate the dependencies on the shared C and C++ run-time libraries. Thanks.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #17 from Larry Baker baker at usgs dot gov 2012-11-21 21:37:26 UTC --- Jonathan, Yes, I should have said link with a C++ driver instead of link with a C++ compiler. No, it's not equivalent, -static-libstdcxx does not imply -lstdc++, which is why you get missing symbols. -static-libstdcxx has nothing to do with why I get the missing symbols. I get the missing symbols because the LINKER changed from $(CC) to $(CXX). Why not just use the Sourcery configuration that works? Why change the LINKER for a C++ program from $(CXX) to $(CC)? That is what causes the link to fail. The g++ driver may have any number of built-in ld options that differ from the gcc driver. Why should I care? The point of using the g++ driver for a C++ program is that it takes care of all that for me. If I get everything working for my cross compiler without using --with-host-libstdcxx, then the LINKER is $(CXX), which implies -lstdc++. Now, suppose I want to eliminate the dependencies of my cross compiler on the libc and llibc++ shared libraries that happen to be on my Linux system, so that my cross compiler will run on many Linux systems with possibly different libc's and libc++'s. In that case, I do not want to select different library (e.g., a debug variant), I want to select the .a variant in place of the .so variant. If I were writing my own link command, I would use g++ to do the linking with the options -static-libgcc -static-libstdc++. So, how to do the same when building a GCC cross compiler? The GCC installation notes, http://gcc.gnu.org/install/configure.html, offer only one method to add linker options to build GCC: --with-host-libstdcxx. The example given there is `-Wl,-Bstatic,-lstdc++,-Bdynamic -lm', which is equivalent to g++ -static-libstdc++ (plus -lm, which I have no idea why it is there). (As far as I can tell, Sourcery copied this example verbatim, including the unnecessary -lm.) This example was likely written before the g++ -static-libstdc++ options existed, and certainly was written before the GCC implementation language was changed from C to C++. What is not mentioned is the side effect that the LINKER will change from $(CXX) to ($CC). To allow fine-tuning the libs, you need the additional libs to not be used, which implies not linking with g++. Then they should specify CXX=gcc (since there is no way to specify the LINKER directly). All this will be moot, I think, when others start bumping into GCC builds that fail as more of GCC is implemented in C++.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #13 from Larry Baker baker at usgs dot gov 2012-11-20 19:57:41 UTC --- Jakub, The root of the problem is because GCC required a C++ linker, but the logic in gcc/Makefile forces the linker to be $(CC) when HOST_LIBS are specified: # The name of the compiler to use. COMPILER = $(CXX) COMPILER_FLAGS = $(CXXFLAGS) # If HOST_LIBS is set, then the user is controlling the libraries to # link against. In that case, link with $(CC) so that the -lstdc++ # library is not introduced. If HOST_LIBS is not set, link with # $(CXX) to pick up -lstdc++. ifeq ($(HOST_LIBS),) LINKER = $(CXX) LINKER_FLAGS = $(CXXFLAGS) else LINKER = $(CC) LINKER_FLAGS = $(CFLAGS) endif Since GCC from now on will be implemented in C++, we can expect there will be C++-only features (local statics, as you say). This, in turn, implies to me that GCC should be linked with a C++ compiler, not a C compiler. Maybe this Makefile should just honor what the user specifies, instead of switching to $(CC). E.g., if the user requires gcc, then they can define CXX=gcc. This also means that HOST_LIBS can use g++ syntax when CXX=g++. Thus, HOST_LIBS='-static-libgcc -static-libstdc++' will work as expected. I hope someone will look at the cause of this error and think about whether the Makefile behavior really makes sense the way it is. I think not.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #15 from Larry Baker baker at usgs dot gov 2012-11-20 22:24:46 UTC --- Jakub, I undertand the reason for the --with-host-libstdcxx option. The documentation for --with-host-libstdcxx doesn't say anything about the side effect of changing the LINKER from $(CXX) to $(CC). It is that effect that I believe is undesirable, especially given the change of GCC's implementation language from C to C++.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #43 from Larry Baker baker at usgs dot gov 2012-10-04 19:14:44
UTC ---
Those of you that use the uClinux elf2flt toolchain will find that
__stack_start is not correctly defined. This is due to a bug in the elf2flt.ld
linker script. Edit either/both elf2flt.ld (from a binary distribution) or
elf2flt.ld.in (from the source distribution) to output the .stack section to
the flatmem memory image:
From
.stack : {
. = ALIGN(0x4);
__stack_start = .;
}
To
.stack : {
. = ALIGN(0x4);
__stack_start = .;
} flatmem
See http://mailman.uclinux.org/pipermail/uclinux-dev/2012-October/052176.html.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #41 from Larry Baker baker at usgs dot gov 2012-09-25 18:43:05 UTC --- Created attachment 28276 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28276 Build patched GNU GCC 4.8.0 experimental for ColdFire uClinux Notes to download, patch, and build GNU GCC 4.8.0 experimental for ColdFire uClinux target on Mac OS X and Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #42 from Larry Baker baker at usgs dot gov 2012-09-25 20:39:10 UTC --- Change log for patches here. The patches here implement GCC stack limit checking for Freescale ColdFire processors (bug no. 28896) and fix the issues identified in the existing GCC source code (bug nos. 53833 and 54584). GCC version 4.6 and later (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896): • gcc/config/m68k/m68k.md – Modify the expansion of movsi pseudo instructions that require PIC relocation to use the destination register for all cases when a pseudo register cannot be created (vs. only when reload_in_progress is set). • gcc/config/m68k/m68k.md – Implement a code generator for the generic conditional trap instruction pattern (*conditional_trap) for all M68000-family processors. Rename the M68020 processor-specific conditional trap instruction pattern (from *conditional_trap to *conditional_trap_68020). • gcc/config/m68k/m68k.md – Remove the M68020 processor-specific filter on the conditional trap pseudo instructions ctrapdi4, ctrapsi4, ctraphi4, and ctrapqi4. • gcc/config/m68k/m68k.c – Compare the stack limit with the stack frame size (fsize_with_regs) after it has been adjusted for the additional stack space used by ColdFire processors (vs. the unadjusted current_frame.size). • gcc/config/m68k/m68k.c – Use a temporary Global Offset Table (GOT) pointer register, a0, for PIC code. • gcc/config/m68k/m68k.c – Change the temporary register used for the stack limit check to address register a0 (vs. data register d0) to enable the code generator to emit a load effective address (lea) instruction. • gcc/config/m68k/m68k.c – Check a stack limit register value before the stack is allocated (vs. after). • gcc/config/m68k/m68k.c – Move the implementation of stack limit checking from the prologue pseudo instruction code generator, m68k_expand_prologue, to a new TARGET_ASM_FUNCTION_PROLOGUE compiler hook function, m68k_function_prologue. (Eliminates the need to save/restore the GOT pointer register, a5, if done in m68k_expand_prologue.) • gcc/opts-global.c and gcc/config/m68k/m68k.c – Reject the use of a floating-point registers (fpn), a volatile registers (d0, d1, a0, a1), or the stack pointer (sp) as the stack limit register. GCC version 4.7 and later (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833) • libgcc/config.host – Disable atomics for ColdFire processors (internal compiler error). GCC version 4.7 and later (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584) • gcc/config/m68k/uclinux.h – Disable Transactional Memory for uClinux (-msep-data/-fPIC -elf2flt final link failure).
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #9 from Larry Baker baker at usgs dot gov 2012-09-25 01:53:01 UTC
---
The build on Linux i386 works fine without --with-host-libstdcxx. I believe
g++ is used for linking.
I tried using a native Linux i386 GCC 4.7.1 to build a cross GCC 4.8.0, with
--with-host-libstdcxx='-static-libgcc -static-libstdc++'. That fails with the
same error I encountered before: undefined references to __cxa_guard_acquire
and __cxa_guard_release in the link step. I am sure this is because gcc was
used and libstdc++ was not searched because I did not include -lstdc++ in
--with-host-libstdcxx.
Lastly, I hacked gcc/Makefile.in to always use g++ for the linker:
# Libraries to use on the host.
HOST_LIBS = @HOST_LIBS@
# The name of the compiler to use.
COMPILER = $(CXX)
COMPILER_FLAGS = $(CXXFLAGS)
# If HOST_LIBS is set, then the user is controlling the libraries to
# link against. In that case, link with $(CC) so that the -lstdc++
# library is not introduced. If HOST_LIBS is not set, link with
# $(CXX) to pick up -lstdc++.
#--- ifeq ($(HOST_LIBS),)
LINKER = $(CXX)
LINKER_FLAGS = $(CXXFLAGS)
#--- else
#--- LINKER = $(CC)
#--- LINKER_FLAGS = $(CFLAGS)
#--- endif
# ( cd cross-gcc-4.8.0-experimental ;
PATH=/usr/local/gcc-4.7.1/bin:${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/}
CC_FOR_BUILD=gcc CC=gcc CXX=g++ AR=ar RANLIB=ranlib
AS_FOR_TARGET=m68k-uclinux-as LD_FOR_TARGET=m68k-uclinux-ld
AR_FOR_TARGET=m68k-uclinux-ar RANLIB_FOR_TARGET=m68k-uclinux-ranlib
NM_FOR_TARGET=m68k-uclinux-nm OBJDUMP_FOR_TARGET=m68k-uclinux-objdump
STRIP_FOR_TARGET=m68k-uclinux-strip ${PWD}/../gcc-4.8.0-experimental/configure
--disable-decimal-float --disable-fixed-point --disable-libffi
--disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libstdcxx-pch --disable-nls --disable-shared --enable-languages=c,c++
--enable-lto --enable-poison-system-directories --enable-threads
--prefix=/usr/local/gcc-4.8.0 --program-prefix=m68k-uclinux-
--target=m68k-uclinux --with-arch=cf --with-gnu-as --with-gnu-ld
--with-build-time-tools=${PWD}/../freescale-coldfire-2011.09/m68k-uclinux/bin
--with-host-libstdcxx='-static-libgcc -static-libstdc++'
--with-sysroot=${PWD}/../freescale-coldfire-2011.09/m68k-uclinux/libc )
# ( cd cross-gcc-4.8.0-experimental ;
PATH=/usr/local/gcc-4.7.1/bin:${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/}
make -j4 )
# ( cd cross-gcc-4.8.0-experimental ;
PATH=/usr/local/gcc-4.7.1/bin:${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/}
make install )
This works fine. This is as close as I could get to supplying
LDFLAGS_FOR_BUILD='-static-libgcc -static-libstdc++' to the link step without
causing LINKER=gcc.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #4 from Larry Baker baker at usgs dot gov 2012-09-21 18:56:20 UTC --- Richard, On both Mac OS X and Linux, the link step uses gcc. On Mac OS X, the link succeed; on Linux, the link fails. The LINKER is selected by the following logic in the gcc/Makefile: # The name of the compiler to use. COMPILER = $(CXX) COMPILER_FLAGS = $(CXXFLAGS) # If HOST_LIBS is set, then the user is controlling the libraries to # link against. In that case, link with $(CC) so that the -lstdc++ # library is not introduced. If HOST_LIBS is not set, link with # $(CXX) to pick up -lstdc++. ifeq ($(HOST_LIBS),) LINKER = $(CXX) LINKER_FLAGS = $(CXXFLAGS) else LINKER = $(CC) LINKER_FLAGS = $(CFLAGS) endif The reason LINKER is set to gcc on both systems is I use the configure --with-host-libstdcxx option: Mac OS X: --with-host-libstdcxx='-lstdc++ -lm' Linux: --with-host-libstdcxx='-static-libgcc -static-libstdc++ -lm' (I don't know why the -lm is there; I copied that from Sourcery's ColdFire uClinux SDK build script.) which defines HOST_LIBS in gcc/Makefile: # Libraries to use on the host. Mac OS X: HOST_LIBS = -lstdc++ -lm Linux: HOST_LIBS = -static-libgcc -static-libstdc++ -lm The original --with-host-libstdcxx from Sourcery (Mentor Graphics) ColdFire uClinux SDK build scripts was: --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' I guess Sourcery used '-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' so that the cross compilers would not have system library dependencies, and could be delivered in a tarball that would work on many Linux systems without introducing a shared-llibrary dependency. I altered that to use the more recent gcc option -static-libstdc++ in place of -Wl,-Bstatic,-lstdc++,-Bdynamic. I'm thinking a couple things are happening: • On Mac OS X, the link works because I do not use static libraries (Mac OS X does not support them), and -lstdc++ brings in the O/S version of guard.cc. • On CentOS Linux 6.3, gcc is too old to recognize -static-libstdc++. (I'm assuming a more recent gcc driver recognizes it; it may be that it is only recognized by the g++ driver.) I'll try to make a more recent HOST gcc that supports -static-libstdc++. (Anyone know which release added it?) However, I do not understand the logic of selecting gcc in the first place. --with-host-libstdcxx is described at http://gcc.gnu.org/install/configure.html: --with-host-libstdcxx=linker-args If you are linking with a static copy of PPL, you can use this option to specify how the linker should find the standard C++ library used internally by PPL. Typical values of linker-args might be `-lstdc++' or `-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'. If you are linking with a shared copy of PPL, you probably do not need this option; shared library dependencies will cause the linker to search for the standard C++ library automatically. This implies two things to me: 1) This is the only way to pass linker args (that I could find) 2) This is for c++ (...-libstdcxx means c++, right?) The linker-args get turned into HOST_LIBS in gcc/Makefile, used to define LIBS and BACKENDLIBS: # How to link with both our special library facilities # and the system's installed libraries. LIBS = libcommon.a $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBIBERTY) \ $(LIBDECNUMBER) $(HOST_LIBS) BACKENDLIBS = $(CLOOGLIBS) $(GMPLIBS) $(PLUGINLIBS) $(HOST_LIBS) \ $(ZLIB) which, to me, means something different than linker-args. It seems to me that a main program compiled by g++ should be linked by g++. Linker args are a separate matter. In any case, the web page should probably be updated to warn that --with-host-libstdcxx causes ALL linking (at least for the compilers) to use gcc instead of g++. This matters now because GCC's implementation language changes from C to C++ with release 4.8.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #5 from Larry Baker baker at usgs dot gov 2012-09-21 19:16:50 UTC --- From what I can tell from the GCC Link Options web page (http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-static_002dlibgcc-1032), -static-libstdc++ is only a g++ driver option: -static-libstdc++ When the g++ program is used to link a C++ program, it normally automatically links against libstdc++. If libstdc++ is available as a shared library, and the -static option is not used, then this links against the shared version of libstdc++. That is normally fine. However, it is sometimes useful to freeze the version of libstdc++ used by the program without going all the way to a fully static link. The -static-libstdc++ option directs the g++ driver to link libstdc++ statically, without necessarily linking other libraries statically. There appears to be no way to pass -static-libstdc++ to the g++ driver for linking. --with-host-libstdcxx=-static-libstdc++ will cause gcc/Makefile to use gcc for the LINKER, instead of just passing the -static-libstdc++ option to the g++ driver.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #6 from Larry Baker baker at usgs dot gov 2012-09-21 20:34:41 UTC --- I'm looking at CFLAGS_FOR_BUILD and CXXFLAGS_FOR_BUILD as a way to pass -static-libgcc and -static-libstdc++ to the linker, respectively. In the top-level generated Makefile, I noticed that CXXFLAGS_FOR_BUILD is not included in the list of variables in BASE_FLAGS_TO_PASS: # Flags to pass down to all sub-makes. BASE_FLAGS_TO_PASS = \ : Whereas, CC_FOR_BUILD, CFLAGS_FOR_BUILD, and CXX_FOR_BUILD are included. Is this an oversight? And, the description of EXTRA_BUILD_FLAGS makes it sound like it should also include the CXX variants: # These variables must be set on the make command line for directories # built for the build system to override those in BASE_FLAGS_TO_PASSS. EXTRA_BUILD_FLAGS = \ CFLAGS=$(CFLAGS_FOR_BUILD) \ LDFLAGS=$(LDFLAGS_FOR_BUILD) (P.S. BASE_FLAGS_TO_PASSS is misspelled.)
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #7 from Larry Baker baker at usgs dot gov 2012-09-22 01:13:54 UTC --- I'm kind of stumped at the moment to find an alternative method to pass down linker flags without using --with-host-libstdcxx. I tried setting CFLAGS_FOR_BUILD=-x c -x none \ CXXFLAGS_FOR_BUILD=-x c++ -x none \ LDFLAGS_FOR_BUILD=-x none \ in the configure step. I also hacked Makefile.in to pass CXXFLAGS_FOR_BUILD in BASE_FLAGS_TO_PASS. The CFLAGS_FOR_BUILD=-x c -x none show up in the gcc compile commands (the make gcc screen output), but I'm not sure it is used in every gcc command. The CXXFLAGS_FOR_BUILD=-x c++ -x none and LDFLAGS_FOR_BUILD=-x none never show up. I don't really care that much about static linking myself. But, I can understand why a vendor or package developer might want to have the capability.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #8 from Larry Baker baker at usgs dot gov 2012-09-22 01:45:31 UTC --- After changing --with-host-libstdcxx back to --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' the build succeeds for Linux i386. I am sure LINKER was set to gcc in this case. I am rebuilding without --with-host-libstdcxx to verify that the cross compiler can be built when LINKER is set to g++ for Linux i386. After that, I'll try to use a newer GCC on CentoS Linux i386 and try again with --with-host-libstdcxx='-static-libgcc -static-libstdc++ -lm'. This seems to be the more modern equivalent on more recent gcc/g++ compilers. I found 4.6 and 4.7 compilers include both -static-libgcc and -static-libstdc++ (strings host-gcc/g++-compiler | grep [-]static[-]). You can probably reclassify this case from a bug to a feature request.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #36 from Larry Baker baker at usgs dot gov 2012-09-20 17:47:38 UTC --- Created attachment 28231 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28231 Build patched GNU GCC 4.6.4 prerelease for ColdFire uClinux Notes to download, patch, and build GNU GCC 4.6.4 prerelease for ColdFire uClinux target on Mac OS X and Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #37 from Larry Baker baker at usgs dot gov 2012-09-20 17:51:28 UTC --- Created attachment 28234 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28234 Makefile to build GCC cross compiler and binutils for ColdFire uClinux Makefile used to build Mac OS X and Linux i386 cross compiler and binutils for ColdFire uClinux. (For the notes in the previous attachment.)
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #38 from Larry Baker baker at usgs dot gov 2012-09-20 17:54:41 UTC --- Created attachment 28236 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28236 Patches for GCC 4.7.2 (prerelease) Patches to fix stack limit checking for GCC 4.7.2 (prerelease) (2012-09-15 snapshot from http://fossies.org) for FreeScale Coldfire uClinux.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #39 from Larry Baker baker at usgs dot gov 2012-09-20 17:57:32 UTC --- Created attachment 28237 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28237 Build patched GNU GCC 4.7.2 prerelease for ColdFire uClinux Notes to download, patch, and build GNU GCC 4.7.2 prerelease for ColdFire uClinux target on Mac OS X and Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #40 from Larry Baker baker at usgs dot gov 2012-09-20 18:58:01 UTC --- Created attachment 28238 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28238 Patches for GCC 4.8.0 (experimental) Patches to fix stack limit checking for GCC 4.8.0 (experimental) (2012-09-16 snapshot from http://fossies.org) for FreeScale Coldfire uClinux.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #2 from Larry Baker baker at usgs dot gov 2012-09-20 20:28:08 UTC --- This bug also occurs when --enable-languages=c,c++. I am building a cross compiler for ColdFire uClinux, TARGET=m68k-uclinux. On Mac OS X HOST=BUILD=x86_64-apple-darwin10.8.0, there are no errors. On Linux i386 HOST=BUILD=i686-pc-linux-gnu, I get the undefined references to __cxa_guard_acquire and __cxa_guard_release. The bug is due to the link step for cc1, lto1 (maybe more) using gcc; it should be using g++ (see below). I don't know which Makefile(s) to fix. It also looks like the command emitted depends on the HOST or BUILD platform. CentOS Linux has such an old gcc, it does not recognize -static-libstdc++ # cat /etc/redhat-release CentOS release 6.3 (Final) # gcc -v Using built-in specs. Target: i686-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i686 --build=i686-redhat-linux Thread model: posix gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) From the build directory # pwd /tmp/freescale-coldfile-xgcc/cross-gcc-4.8.0-experimental/gcc This is the (first) make command that fails (I did a make -j4, so the link of lto1 also failed) # gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o tree-mudflap.o default-c.o \ cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -static-libgcc -static-libstdc++ -lm -lmpc -lmpfr -lgmp -rdynamic -ldl -static-libgcc -static-libstdc++ -lm -L../zlib -lz gcc: unrecognized option '-static-libstdc++' gcc: unrecognized option '-static-libstdc++' libbackend.a(tree-ssa-coalesce.o): In function `coalesce_ssa_name()': /tmp/freescale-coldfile-xgcc/cross-gcc-4.8.0-experimental/../gcc-4.8.0-experimental/gcc/tree-ssa-coalesce.c:1294: undefined reference to `__cxa_guard_acquire' /tmp/freescale-coldfile-xgcc/cross-gcc-4.8.0-experimental/../gcc-4.8.0-experimental/gcc/tree-ssa-coalesce.c:1294: undefined reference to `__cxa_guard_release' collect2: ld returned 1 exit status Using g++ instead of gcc cures the problem # g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o tree-mudflap.o default-c.o cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -static-libgcc -static-libstdc++ -lm -lmpc -lmpfr -lgmp -rdynamic -ldl -static-libgcc -static-libstdc++ -lm -L../zlib -lz g++: unrecognized option '-static-libstdc++' g++: unrecognized option '-static-libstdc++'
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #3 from Larry Baker baker at usgs dot gov 2012-09-20 20:30:29 UTC
---
Richard,
Wrong track ... I found the problem (which also occurs when
--enable-languages=c,c++). See my posting.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 20 Sep 2012, at 4:37 AM, rguenth at gcc dot gnu.org wrote:
build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
Date: Thu, 20 Sep 2012 11:37:04 +
X-Bugzilla-Reason: Reporter
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords:
X-Bugzilla-Severity: blocker
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.0
X-Bugzilla-Changed-Fields: Status Last reconfirmed Component CC Ever
Confirmed Summary Target Milestone
Message-ID: bug-54630-22003-vriywvw...@http.gcc.gnu.org/bugzilla/
In-Reply-To: bug-54630-22...@http.gcc.gnu.org/bugzilla/
References: bug-54630-22...@http.gcc.gnu.org/bugzilla/
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset=UTF-8
MIME-Version: 1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-09-20
Component|libstdc++ |middle-end
CC||crowl at gcc dot gnu.org,
||dnovillo at gcc dot
||gnu.org, rguenth at gcc dot
||gnu.org
Ever Confirmed|0 |1
Summary|GCC 4.8 |[4.8 Regression] GCC 4.8
|--enable-languages=c build |--enable-languages=c build
|fails: Undefined symbols: |fails: Undefined symbols:
|___cxa_guard_acquire and|___cxa_guard_acquire and
|___cxa_guard_release|___cxa_guard_release
Target Milestone|--- |4.8.0
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-20
11:37:04 UTC ---
Ick. Now
static hash_table ssa_name_var_hash ssa_name_hash;
appearantly has a guarded init!?
D.38548 = __cxa_guard_acquire (_ZGVZ17coalesce_ssa_namevE13ssa_name_hash);
retval.1 = D.38548 != 0;
if (retval.1 != 0) goto D.38549; else goto D.38550;
D.38549:
D.38265 = 0;
try
{
hash_tablessa_name_var_hash::hash_table (ssa_name_hash);
D.38265 = 1;
__cxa_guard_release (_ZGVZ17coalesce_ssa_namevE13ssa_name_hash);
}
catch
{
if (D.38265 != 0) goto D.38551; else goto D.38552;
D.38551:
goto D.38553;
D.38552:
__cxa_guard_abort (_ZGVZ17coalesce_ssa_namevE13ssa_name_hash);
D.38553:
}
I suppose easiest is to remove the 'static' keyword here.
Larry, can you test that?
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.
[Bug libstdc++/54630] New: GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 Bug #: 54630 Summary: GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ba...@usgs.gov Created attachment 28222 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28222 Download, configure, and build gcc 4.8 for ColdFire uClinux Build of 4.8 20120909 snapshot (http://fossies.org/unix/misc/gcc-4.8-20120909.tar.gz) fails for --enable-languages=c: g++ -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc -I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc/. -I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc/../include -I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc/../libcpp/include -I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc/../libdecnumber -I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc/../libdecnumber/dpd -I../libdecnumbercc1-checksum.c -o cc1-checksum.o gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o tree-mudflap.o default-c.o \ cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -static-libgcc -static-libstdc++ -lm -lmpc -lmpfr -lgmp -static-libgcc -static-libstdc++ -lm -L../zlib -lz Undefined symbols: ___cxa_guard_acquire, referenced from: coalesce_ssa_name() in libbackend.a(tree-ssa-coalesce.o) ___cxa_guard_release, referenced from: coalesce_ssa_name() in libbackend.a(tree-ssa-coalesce.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [cc1] Error 1 make[1]: *** [all-gcc] Error 2 make: *** [all] Error 2 It looks to me like: now that GCC is implemented in C++, certain libstdc++ functions are needed, but are not compiled when --enable-languages=c. Attached are instructions to replicate my build.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #34 from Larry Baker baker at usgs dot gov 2012-09-20 00:49:30 UTC --- Created attachment 28223 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28223 Build patched GNU GCC 4.7.1 for ColdFire uClinux Shell script to download, patch, and build GNU GCC 4.7.1 for ColdFire uClinux target on Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #35 from Larry Baker baker at usgs dot gov 2012-09-20 00:56:02 UTC --- Created attachment 28224 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28224 Patches for GCC 4.6.4 (prerelease) Patches to fix stack limit checking for GCC 4.6.4 (prerelease) (2012-09-14 snapshot from http://fossies.org) for FreeScale Coldfire uClinux.
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584 --- Comment #3 from Larry Baker baker at usgs dot gov 2012-09-18 21:43:32 UTC --- I don't know how to attach gdb to the ld.real called by collect2. So, I added a bunch of debugging output to bfd/elflink.c to find out where the failure occurs. (I'll attach my hacked version.) Here's the link without -elf2flt and with -elf2flt. The object files/libraries are the same, yet the program sections that ld.real sees are quite different. $ COMPILER_PATH=/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/:/usr/local/gcc-4.7.1/m68k-uclinux/bin/:/usr/local/gcc-4.7.1/m68k-uclinux/lib/ /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/collect2 --sysroot=/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data --eh-frame-hdr -o conftest -t /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crt1.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crti.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtbegin.o -L/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data -L/usr/local/gcc-4.7.1/m68k-uclinux/lib/msep-data -L/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc -L/usr/local/gcc-4.7.1/m68k-uclinux/bin -L/usr/local/gcc-4.7.1/m68k-uclinux/lib -L/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib conftest.o -lgcc -lc -lgcc /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtend.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crtn.o /usr/local/gcc-4.7.1/m68k-uclinux/bin/ld.real: mode m68kelf /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crt1.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crti.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtbegin.o conftest.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)__uClibc_main.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)strrchr.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)exit.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)_exit.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)__errno_location.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)strchr.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)errno.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtend.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crtn.o --- ldwrite: pid = 81433 --- ldwrite: lang_for_each_statement() --- ldwrite: bfd_final_link() --- bfd_elf_final_link: --- bfd_elf_final_link: remove input section .init --- bfd_elf_final_link: remove input section .text --- bfd_elf_final_link: remove input section .fini --- bfd_elf_final_link: remove input section .rodata --- bfd_elf_final_link: remove input section .eh_frame --- bfd_elf_final_link: remove input section .ctors --- bfd_elf_final_link: remove input section .dtors --- bfd_elf_final_link: remove input section .jcr --- bfd_elf_final_link: remove input section .got --- bfd_elf_final_link: remove input section .data --- bfd_elf_final_link: remove input section .bss --- bfd_elf_final_link: remove input section .comment --- bfd_elf_final_link: count relocations for section .init --- bfd_elf_final_link: count relocations for section .text --- bfd_elf_final_link: count relocations for section .fini --- bfd_elf_final_link: count relocations for section .rodata --- bfd_elf_final_link: count relocations for section .eh_frame --- bfd_elf_final_link: count relocations for section .ctors --- bfd_elf_final_link: count relocations for section .dtors --- bfd_elf_final_link: count relocations for section .jcr --- bfd_elf_final_link: count relocations for section .got --- bfd_elf_final_link: count relocations for section .data --- bfd_elf_final_link: count relocations for section .bss --- bfd_elf_final_link: count relocations for section .comment --- bfd_elf_final_link: set size, file position for section .init --- bfd_elf_final_link: set size, file position for section .text --- bfd_elf_final_link: set size, file position for section .fini --- bfd_elf_final_link: set size, file position for section .rodata --- bfd_elf_final_link: set size, file position for section .eh_frame --- bfd_elf_final_link: set size, file position for section .ctors --- bfd_elf_final_link: set size, file position for section .dtors --- bfd_elf_final_link: set size, file position for section .jcr --- bfd_elf_final_link: set size, file position for section .got --- bfd_elf_final_link: set size
[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833 --- Comment #3 from Larry Baker baker at usgs dot gov 2012-09-18 21:45:23 UTC --- Created attachment 28217 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28217 Hacked binutils 1.22 bfd/elflink.c I added a bunch of debugging output to bfd/elflink.c to find out where the link failure occurs.
[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833 --- Comment #4 from Larry Baker baker at usgs dot gov 2012-09-18 21:51:36 UTC --- (In reply to comment #3) Created attachment 28217 [details] Hacked binutils 1.22 bfd/elflink.c I added a bunch of debugging output to bfd/elflink.c to find out where the link failure occurs. This doesn't belong here -- it is for Bug no. 54584. Will the moderator please remove it? Sorry.
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584 --- Comment #4 from Larry Baker baker at usgs dot gov 2012-09-18 21:53:03 UTC --- Created attachment 28218 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28218 Hacked binutils 1.22 bfd/elflink.c I added a bunch of debugging output to bfd/elflink.c to find out where the link failure occurs.
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584 --- Comment #6 from Larry Baker baker at usgs dot gov 2012-09-19 00:05:38 UTC --- Hans-Peter, Thanks for looking at this. This seems a bit more complicated than just a problem with flawed elf2flt linker placement of orphaned sections since elf2flt/ld.real work fine when creating flat binaries for cases other than -msep-data/-fPIC. That implies that they must be handling the orphaned .tm_clone_table section for those cases (a bunch of different -mcpu's). I don't know where to look to find out how -msep-data/-fPIC are handled differently, and thus, why those fail. FYI: For the latest tests I ran, I used a vanilla binutils 1.22 distribution -- no uClinux linker patches. I also used the latest elf2flt from www.uclinux.org. I also cannot find where -elf2flt is recognized/handled by collect2. I have no idea what collect2 does. I tracked down the location of the error to ld.real, which is the binutils ld, renamed to ld.real by the elf2flt package make install. When I read about TM support, it sounded like it might be preferable to pthreads. If that is so, then I expect uClinux would be a good candidate for TM. I will take a look at your fix. The details of how to write ld scripts and such are beyond my current understanding of the process. I learn what I have to when I encounter a problem. I was hoping someone that knows what to look for would see what I have provided and instantly figure out what the problem is. :) Larry Baker
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584 --- Comment #7 from Larry Baker baker at usgs dot gov 2012-09-19 00:15:22 UTC --- (In reply to comment #6) FYI: For the latest tests I ran, I used a vanilla binutils 1.22 distribution -- no uClinux linker patches. I also used the latest elf2flt from www.uclinux.org. binutils 1.22 is a typo -- I meant to say binutils 2.22.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #33 from Larry Baker baker at usgs dot gov 2012-09-19 01:02:31 UTC --- Created attachment 28220 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28220 Patches for GCC 4.7.1 Patches to fix stack limit checking for GCC 4.7.1 for FreeScale Coldfire uClinux. Also includes patches to disable atomics (internal compiler error) for ColdFire processors (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833) and to disable Transactional Memory (linker failure) for uClinux (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584). These two features were introduced in GCC 4.7.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #30 from Larry Baker baker at usgs dot gov 2012-09-17 19:28:19 UTC --- Created attachment 28205 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28205 Build patched Sourcery (Mentor Graphics) CodeBench Lite GCC 4.6-2011.09-23 for ColdFire uClinux Shell script to download, patch, and build Sourcery (Mentor Graphics) CodeBench Lite GCC 4.6-2011.09-23 for ColdFire uClinux target on Linux i386 host.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #31 from Larry Baker baker at usgs dot gov 2012-09-17 21:44:34 UTC --- Created attachment 28206 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28206 Patches for GCC 4.6.3 Patches to fix stack limit checking for GCC 4.6.3 for FreeScale Coldfire uClinux. These patches are also good for the GCC 4.6.4 development trunk (fossies.org 20120907 snapshot).
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #32 from Larry Baker baker at usgs dot gov 2012-09-18 02:16:32 UTC --- Created attachment 28208 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28208 Build patched GNU GCC 4.6.3 for ColdFire uClinux Shell script to download, patch, and build GNU GCC 4.6.3 for ColdFire uClinux target on Linux i386 host.
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584 --- Comment #2 from Larry Baker baker at usgs dot gov 2012-09-18 02:44:43 UTC --- The Sourcery (Mentor Graphics) ColdFire uClinux SDK I use uses binutils-1.21. I installed binutils-2.22 and the latest uClinux elf2flt (downloaded 20120730). $ /usr/local/gcc-4.7.1/bin/m68k-uclinux-ld -V -v GNU ld (GNU Binutils) 2.22 Supported emulations: m68kelf GNU ld (GNU Binutils) 2.22 The error message is the same (Nonrepresentable section on output). I am able to issue the failing command (collect2) outside of make gcc: $ COMPILER_PATH=/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/:/usr/local/gcc-4.7.1/m68k-uclinux/bin/:/usr/local/gcc-4.7.1/m68k-uclinux/lib/ \ /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/collect2 --sysroot=/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data --eh-frame-hdr -elf2flt -o conftest -t /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crt1.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crti.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtbegin.o -L/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data -L/usr/local/gcc-4.7.1/m68k-uclinux/lib/msep-data -L/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc -L/usr/local/gcc-4.7.1/m68k-uclinux/bin -L/usr/local/gcc-4.7.1/m68k-uclinux/lib -L/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib conftest.o -lgcc -lc -lgcc /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtend.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crtn.o /usr/local/gcc-4.7.1/m68k-uclinux/bin/ld.real: mode m68kelf /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crt1.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crti.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtbegin.o conftest.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)__uClibc_main.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)strrchr.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)exit.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)_exit.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)__errno_location.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)strchr.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)errno.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtend.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crtn.o /usr/local/gcc-4.7.1/m68k-uclinux/bin/ld.real: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status If I remove the -elf2flt option, the error goes away: $ COMPILER_PATH=/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/:/usr/local/gcc-4.7.1/m68k-uclinux/bin/:/usr/local/gcc-4.7.1/m68k-uclinux/lib/ \ /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/collect2 --sysroot=/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data --eh-frame-hdr -o conftest -t /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crt1.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crti.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtbegin.o -L/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data -L/usr/local/gcc-4.7.1/m68k-uclinux/lib/msep-data -L/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc -L/usr/local/gcc-4.7.1/m68k-uclinux/bin -L/usr/local/gcc-4.7.1/m68k-uclinux/lib -L/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib conftest.o -lgcc -lc -lgcc /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtend.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crtn.o /usr/local/gcc-4.7.1/m68k-uclinux/bin/ld.real: mode m68kelf /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crt1.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crti.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtbegin.o conftest.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)__uClibc_main.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)strrchr.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)exit.o (/tmp
[Bug target/54584] New: m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584
Bug #: 54584
Summary: m68k-uclinux error: Link tests are not allowed after
GCC_NO_EXECUTABLES
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ba...@usgs.gov
Created attachment 28193
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28193
Make m68k-uclinux-gcc/g++ cross compilers
Host: i686-pc-linux (also x86_64-apple-darwin10.8.0)
Target: m68k-uclinux (Coldfire)
Build of msep-data/libstdc++-v3 fails for FreeScale Coldfire uClinux target
(complete configure and build commands are attached):
:
Running configure in multilib subdir msep-data
:
checking command to parse
/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/nm output from
/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/xgcc
-B/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/
-B/usr/local/gcc-4.7-20120908/m68k-uclinux/bin/
-B/usr/local/gcc-4.7-20120908/m68k-uclinux/lib/ -isystem
/usr/local/gcc-4.7-20120908/m68k-uclinux/include -isystem
/usr/local/gcc-4.7-20120908/m68k-uclinux/sys-include -msep-data -Wa,-mno-mac
object... failed
:
checking for shl_load... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[2]: *** [configure-target-libstdc++-v3] Error 1
In msep-data/libstdc++-v3/config.log there is an earlier link failure which
causes gcc_no_link=yes:
configure:3885: /tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/xgcc
-B/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/
-B/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/../freescale-coldfire-gcc-4.7-20120908/m68k-uclinux/bin/
-B/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/../freescale-coldfire-gcc-4.7-20120908/m68k-uclinux/lib/
-isystem
/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/../freescale-coldfire-gcc-4.7-20120908/m68k-uclinux/include
-isystem
/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/../freescale-coldfire-gcc-4.7-20120908/m68k-uclinux/sys-include
-msep-data -Wa,-mno-mac -o conftest -g -O2 conftest.c 5
/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/bin/ld.real:
final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
configure:11284: checking for shl_load
configure:11284: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
I extracted the failed command and showed that the link fails for both
msep-data and -fPIC (implied by -msep-data):
$ cat conftest.c
/* confdefs.h */
#define PACKAGE_NAME package-unused
#define PACKAGE_TARNAME libstdc++
#define PACKAGE_VERSION version-unused
#define PACKAGE_STRING package-unused version-unused
#define PACKAGE_BUGREPORT
#define PACKAGE_URL
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
# Failed link from libstdc++-v3/configure:
/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/xgcc -t
-B/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/
-B/usr/local/gcc-4.7-20120908/m68k-uclinux/bin/
-B/usr/local/gcc-4.7-20120908/m68k-uclinux/lib/ -isystem
/usr/local/gcc-4.7-20120908/m68k-uclinux/include -isystem
/usr/local/gcc-4.7-20120908/m68k-uclinux/sys-include -msep-data -Wa,-mno-mac -o
conftest conftest.o
# /usr/local/gcc-4.7-20120908/m68k-uclinux/bin/ld.real: final link failed:
Nonrepresentable section on output
# collect2: error: ld returned 1 exit status
# The problem is actually with -fPIC (implied by -msep-data):
/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/xgcc -t
-B/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/
-B/usr/local/gcc-4.7-20120908/m68k-uclinux/bin/
-B/usr/local/gcc-4.7-20120908/m68k-uclinux/lib/ -isystem
/usr/local/gcc-4.7-20120908/m68k-uclinux/include -isystem
/usr/local/gcc-4.7-20120908/m68k-uclinux/sys-include -fPIC -Wa,-mno-mac -o
conftest conftest.o
# /usr/local/gcc-4.7-20120908/m68k-uclinux/bin/ld.real: final link failed:
Nonrepresentable section on output
# collect2: error: ld returned 1 exit status
The link does not fail when the GCC 4.6 crtbegin.o/crtend.o binaries are used:
# Linking with the 4.6 crtbegin/crtend binaries makes the problem go away:
\mv cross-gcc-4.7-20120908/gcc/msep-data/crtbegin{,-4.7}.o
\mv cross-gcc-4.7-20120908/gcc/msep-data/crtend{,-4.7}.o
\cp cross-gcc-{4.6-20120907,4.7-20120908}/gcc/msep-data/crtbegin.o
\cp cross-gcc-{4.6-20120907,4.7-20120908}/gcc/msep-data/crtend.o
/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/xgcc -t
-B/tmp/freescale-coldfile-xgcc/cross-gcc-4.7-20120908/./gcc/
-B/usr/local/gcc-4.7-20120908/m68k-uclinux/bin/
-B/usr/local/gcc-4.7-20120908/m68k-uclinux/lib/ -isystem
/usr/local/gcc-4.7-20120908/m68k-uclinux/include -isystem
/usr/local/gcc-4.7-20120908/m68k-uclinux/sys-include -msep-data -Wa,-mno-mac -o
conftest conftest.o
\mv
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #28 from Larry Baker baker at usgs dot gov 2012-09-14 20:52:14 UTC --- Created attachment 28194 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28194 Patch for trunk version 2012-09-09 of gcc/config/m68k/uclinux.h To fix the same bug reported for GCC 4.7 at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584.
[Bug other/54586] New: Help diagnosing error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54586
Bug #: 54586
Summary: Help diagnosing error: Link tests are not allowed
after GCC_NO_EXECUTABLES
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ba...@usgs.gov
This is not a bug report, but a feature request.
I have been struggling with building GCC cross compilers. When I unexpectedly
encounter error: Link tests are not allowed after GCC_NO_EXECUTABLES, what I
really need to do is find out which previous configure step broke and set
gcc_no_link=yes. The Link tests... error is a consequence of the true error,
which is not identified as having set gcc_no_link=yes.
I have taken to hand editing configure files when this happens and inserting my
own diagnostic output when either gcc_no_link=no or gcc_no_link=yes is
executed, e.g., in libiberty/configure:
# FIXME: Cleanup?
if { { eval echo \\$as_me\:${as_lineno-$LINENO}: \$ac_link\; } 5
(eval $ac_link) 25
ac_status=$?
$as_echo $as_me:${as_lineno-$LINENO}: \$? = $ac_status 5
test $ac_status = 0; }; then :
$as_echo $as_me:${as_lineno-$LINENO}: --- gcc_no_link=no 5
gcc_no_link=no
else
$as_echo $as_me:${as_lineno-$LINENO}: --- gcc_no_link=yes 5
gcc_no_link=yes
fi
It would be really useful if all GCC configure files would emit such a message,
at least when setting gcc_no_link=yes. It would make it a lot easier to
trouble shoot Link tests... errors.
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584 --- Comment #1 from Larry Baker baker at usgs dot gov 2012-09-15 00:39:14 UTC --- I found that the -msep-data link would succeed if program section .tm_clone_table has a non-zero length. I changed __JCR_LIST__[] and __TMC_LIST__[] to __JCR_LIST__[1] and __TMC_LIST__[1], respectively, in gcc-4.7-20120908/libgcc/crtstuff.c. The program sections in the original crtbegin.o have 0 length for program section .tm_clone_table: # freescale-coldfire-2011.09/bin/m68k-uclinux-objdump -h cross-gcc-4.7-20120908/gcc/msep-data/crtbegin.o cross-gcc-4.7-20120908/gcc/msep-data/crtbegin.o: file format elf32-m68k Sections: Idx Name Size VMA LMA File off Algn 0 .text 0136 0034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 0004 016c 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 001e 0170 2**2 ALLOC 3 .ctors0004 0170 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .dtors0004 0174 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .eh_frame 0178 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .jcr 0178 2**2 CONTENTS, ALLOC, LOAD, DATA 7 .tm_clone_table 0178 2**2 CONTENTS, ALLOC, LOAD, DATA 8 .fini 0006 0178 2**0 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 9 .init 0006 017e 2**0 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 10 .comment 0028 0184 2**0 CONTENTS, READONLY 11 .note.GNU-stack 01ac 2**0 CONTENTS, READONLY The new one has length 4: # freescale-coldfire-2011.09/bin/m68k-uclinux-objdump -h cross-gcc-4.7-20120908/gcc/msep-data/crtbegin.o cross-gcc-4.7-20120908/gcc/msep-data/crtbegin.o: file format elf32-m68k Sections: Idx Name Size VMA LMA File off Algn 0 .text 0136 0034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 0004 016c 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 001e 0170 2**2 ALLOC 3 .ctors0004 0170 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .dtors0004 0174 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .eh_frame 0178 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .jcr 0004 0178 2**2 CONTENTS, ALLOC, LOAD, DATA 7 .tm_clone_table 0004 017c 2**2 CONTENTS, ALLOC, LOAD, DATA 8 .fini 0006 0180 2**0 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 9 .init 0006 0186 2**0 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 10 .comment 0028 018c 2**0 CONTENTS, READONLY 11 .note.GNU-stack 01b4 2**0 CONTENTS, READONLY I do not know if this results in a correctly allocated or populated .tm_clone_table. All I know is that the zero length allocation caused the link failure. Is this due to the ALLOC attribute with 0 length? Is this a consequence of __attribute__((used))?
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #29 from Larry Baker baker at usgs dot gov 2012-09-15 05:41:24 UTC --- Created attachment 28196 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28196 Patches for Sourcery (Mentor Graphics) CodeBench Lite GCC 4.6-2011.09-23 Patches to fix stack limit checking for Sourcery (Mentor Graphics) CodeBench Lite GCC 4.6-2011.09-23 for FreeScale Coldfire uClinux.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #27 from Larry Baker baker at usgs dot gov 2012-09-12 20:42:22 UTC --- Created attachment 28178 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28178 Patch for trunk version 2012-09-09 of libgcc/config.host To fix the same bug reported for GCC 4.7 at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833.
[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833 --- Comment #2 from Larry Baker baker at usgs dot gov 2012-09-12 20:55:00 UTC --- Same bug occurs fo GCC 4.8. Here's the patch I used to build a GCC 4.8 cross-compiler: --- gcc-4.8-20120909/libgcc/config.host +++ gcc-4.8-20120909-patched/libgcc/config.host @@ -704,3 +704,3 @@ m68k-*-uclinux*)# Motorola m68k/ColdFire running uClinux with uClibc -tmake_file=$tmake_file m68k/t-floatlib m68k/t-linux +tmake_file=$tmake_file m68k/t-floatlib md_unwind_header=m68k/linux-unwind.h
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28165|0 |1 is obsolete|| --- Comment #26 from Larry Baker baker at usgs dot gov 2012-09-11 21:33:55 UTC --- Created attachment 28174 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28174 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.c Missed second LEGITIMATE_CONSTANT_P; should be m68k_legitimate_constant_p.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28054|0 |1 is obsolete|| --- Comment #21 from Larry Baker baker at usgs dot gov 2012-09-10 21:27:25 UTC --- Created attachment 28162 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28162 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28081|0 |1 is obsolete|| --- Comment #22 from Larry Baker baker at usgs dot gov 2012-09-10 21:28:46 UTC --- Created attachment 28164 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28164 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.c
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28164|0 |1 is obsolete|| --- Comment #23 from Larry Baker baker at usgs dot gov 2012-09-10 21:31:32 UTC --- Created attachment 28165 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28165 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.c Left out Pmode in plus_constant() again. Sorry.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #24 from Larry Baker baker at usgs dot gov 2012-09-10 21:36:24 UTC --- Created attachment 28166 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28166 Patch for trunk version 2012-09-10 of gcc/opts-global.c Reject the pseudo argument pointer register as a -fstack-limit-register.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #25 from Larry Baker baker at usgs dot gov 2012-09-10 21:52:34
UTC ---
Created attachment 28167
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28167
Patches for Sourcery GCC-4.6-2011.09-23 for ColdFire uClinux
These are the patches I am testing. They are for the Mentor Graphics Sourcery
CodeBench Lite Edition C/C++ compilers for ColdFire uClinux. The generated
code seems to be fine.
Unfortunately, my test system is not. And, my assumption that __stack_start
was a good choice for detecting stack overflow does not seem to be working out.
For my test uClinux executable, stack-overflow.c:
#include stdio.h
void overflow( int i ) {
/* Allocate automatic array j[256] so stack limit checking works. */
int j[256];
/* Stack limit checking tests only whether the stack is large enough for */
/* the initial stack allocation: saved registers and automatic variables. */
/* Stack limit checking does not test for stack overflow in the body of a */
/* function. That is what happens when j[] is not present. When j[] is */
/* too large, the program will abnormally terminate on its own (illegal */
/* instruction trap?). j[256] works. */
i++;
printf( i = %i\n, i );
overflow( i );
}
int main() {
overflow( 0 );
return 0;
}
the stack is allocated 4K (0x1000). When I hacked the .s file to print out the
stack pointer and __stack start, it shows that there is more than 4K between
the value in the stack pointer and __stack_start:
%sp = 0x405f3ee4
__stack_start = 0x405f08b4
That is not what I was expecting.
Here are the instructions for creating the patched GCC I am using:
$ wget --no-check-certificate
https://sourcery.mentor.com/GNUToolchain/package9493/public/m68k-uclinux/freescale-coldfire-2011.09-23-m68k-uclinux-i686-pc-linux-gnu.tar.bz2
$ tar -xjf freescale-coldfire-2011.09-23-m68k-uclinux-i686-pc-linux-gnu.tar.bz2
$ wget --no-check-certificate
https://sourcery.mentor.com/GNUToolchain/package9493/public/m68k-uclinux/freescale-coldfire-2011.09-23-m68k-uclinux.src.tar.bz2
$ tar -xjf freescale-coldfire-2011.09-23-m68k-uclinux.src.tar.bz2 -O
freescale-coldfire-2011.09-23-m68k-uclinux/gcc-2011.09-23.tar.bz2 | tar -xjf -
$ cd gcc-4.6-2011.09
$ patch -b -p 1 ../gcc-4.6-2011.09-23.patch
$ cd ..
$ ( cd cross-gcc-4.6-2011.09 ; \
PATH=${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/} \
CC_FOR_BUILD=gcc \
CC=gcc \
CXX=g++ \
AR=ar \
RANLIB=ranlib \
AS_FOR_TARGET=m68k-uclinux-as \
LD_FOR_TARGET=m68k-uclinux-ld \
AR_FOR_TARGET=m68k-uclinux-ar \
RANLIB_FOR_TARGET=m68k-uclinux-ranlib \
NM_FOR_TARGET=m68k-uclinux-nm \
OBJDUMP_FOR_TARGET=m68k-uclinux-objdump \
STRIP_FOR_TARGET=m68k-uclinux-strip \
${PWD}/../gcc-4.6-2011.09/configure \
--disable-decimal-float \
--disable-fixed-point \
--disable-libffi \
--disable-libgomp \
--disable-libmudflap \
--disable-libquadmath \
--disable-libssp \
--disable-libstdcxx-pch \
--disable-nls \
--disable-shared \
--enable-languages=c,c++ \
--enable-lto \
--enable-poison-system-directories \
--enable-threads \
--prefix=${PWD}/../freescale-coldfire-2011.09 \
--program-prefix=m68k-uclinux- \
--target=m68k-uclinux \
--with-arch=cf \
--with-gnu-as \
--with-gnu-ld \
--with-build-time-tools=${PWD}/../freescale-coldfire-2011.09/m68k-uclinux/bin \
--with-host-libstdcxx='-static-libgcc -static-libstdc++ -lm' \
--with-sysroot=${PWD}/../freescale-coldfire-2011.09/m68k-uclinux/libc )
$ ( cd cross-gcc-4.6-2011.09 ; \
PATH=${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/} \
make -j4 )
$ ( cd cross-gcc-4.6-2011.09 ; \
PATH=${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/} \
make install )
$ toolchains/freescale-coldfire-2011.09-patched/bin/m68k-uclinux-gcc -mcpu=5208
-fomit-frame-pointer -fno-common -fno-builtin -fno-dwarf2-cfi-asm -msep-data
-fstack-limit-symbol=__stack_start -o check-stack-overflow stack-overflow.c
Larry Baker
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #19 from Larry Baker baker at usgs dot gov 2012-08-25 00:28:56 UTC --- I plan to start testing my patches on a ColdFire uClinux system on Monday. In the mean time, I am unsure whether my code is correct for the -fPIC -mno-sep-data case. I do not know if a5 is a volatile register, or if, instead, it must be saved/restored. It is possible (as shown by my example) that a5 might otherwise not be needed by the code in a procedure. In that case, my code is not enabling the save/restore of a5, which would be wrong if a5 is not volatile. This is not a problem for -msep-data (implies -fPIC), since a5 already has the correct value, and is not altered by my code. I will investigate whether a5 is volatile. If anyone knows the answer already, please add a comment. If anyone can recommend what has to be called or modified to force a5 to be saved/restored, I would appreciate hearing about that as well. Thank you, Larry Baker
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #27998|0 |1 is obsolete|| --- Comment #20 from Larry Baker baker at usgs dot gov 2012-08-25 02:22:30 UTC --- Created attachment 28081 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28081 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.c Correct call to plus_constant() (Pmode was missing). Change 4 to INCOMING_FRAME_SP_OFFSET in call to plus_constant(). (I am assuming the hard-coded 4 is the symbolic constant INCOMING_FRAME_SP_OFFSET. Please let me know if that is wrong.)
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28048|0 |1 is obsolete|| --- Comment #18 from Larry Baker baker at usgs dot gov 2012-08-19 21:18:23 UTC --- Created attachment 28054 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28054 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md Change 16-bit word offset (the default) Bcc .+6 instruction to 8-bit short offset Bcc.S .+4 instruction (saves 2 bytes in every procedure prologue).
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28024|0 |1 is obsolete|| --- Comment #17 from Larry Baker baker at usgs dot gov 2012-08-19 03:24:24 UTC --- Created attachment 28048 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28048 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md Change Bcc branch target from .+2 to .+6.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #16 from Larry Baker baker at usgs dot gov 2012-08-17 16:45:22
UTC ---
Here are some notes about the patches I made.
1. An alternative to my m68k.md patch:
- rtx temp = reload_in_progress ? operands[0] : gen_reg_rtx (Pmode);
+ rtx temp = can_create_pseudo_p() ? gen_reg_rtx (Pmode) : operands[0];
might be the approach taken by m68k_output_mi_thunk() in m68k.c:
/* Pretend to be a post-reload pass while generating rtl. */
reload_completed = 1;
:
if (!TARGET_SEP_DATA)
{
/* Use the static chain register as a temporary (call-clobbered)
GOT pointer for this function. We can use the static chain
register because it isn't live on entry to the thunk. */
SET_REGNO (pic_offset_table_rtx, STATIC_CHAIN_REGNUM);
emit_insn (gen_load_got (pic_offset_table_rtx));
}
:
/* Clean up the vars set above. */
reload_completed = 0;
/* Restore the original PIC register. */
if (flag_pic)
SET_REGNO (pic_offset_table_rtx, PIC_REG);
This fools the compiler by pretending to run post-reload pass (reload_completed
= 1). That might have been for the same reason I made the one-line patch above
to m68k.md. I am not sure the approach taken in m68k_output_mi_thunk() would
be correct in m68k_expand_prologue() in m68k.c:
• The alternative code does not undo the effects of an instruction that sets
crtl-uses_pic_offset_table while the temporary PIC offset table register is
being used. That might cause an unnecessary load of the true PIC offset table
register (emit_insn (gen_load_got (pic_offset_table_rtx)) at the end of
m68k_expand_prologue()).
• I do not know if the prerequisite holds that the static chain register is
available in m68k_expand_prologue().
• I do not know if a pseudo register could be created in the stack check code
but never be assigned to an actual register since the reload pass has already
been run.
I decided the patch I made to m68k.md was safe since it followed the intent of
the existing conditional that decided whether or not to call gen_reg_rtx() and
it did not try to use any registers designated for other purposes or not yet
saved. All I did was move the code as-is from before to after the code that
set up the PIC offset table register, and, only when that was required
(!TARGET_SEP_DATA crtl-uses_pic_offset_table).
2. From what I understand of the GCC Internal Manual, the define_expand
TARGET_M68020 condition on ctrapdi4, ctrapsi4, ctraphi4, and ctrapqi4 is
ignored by the time those expansions are inserted into the RTL list (by the
define_expand prologue pattern). In fact, my implementation of a conditional
trap pattern for the other architectures would not have been invoked if it had
been otherwise. The correct insn's for conditional_traps will be selected when
the define_insn patterns are matched and expanded. I concluded it is correct
to remove the TARGET_M68020 condition on ctrapdi4, ctrapsi4, ctraphi4, and
ctrapqi4 in m68k.md.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #27999|0 |1 is obsolete|| --- Comment #14 from Larry Baker baker at usgs dot gov 2012-08-15 21:38:16 UTC --- Created attachment 28024 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28024 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md Removes TARGET_M68020 condition on ctrapdi4, ctrapsi4, ctraphi4, and ctrapqi4.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #11 from Larry Baker baker at usgs dot gov 2012-08-12 21:24:31
UTC ---
Andreas,
I have patched the Code Sourcery gcc 4.6.1+ ColdFire cross-compiler to fix the
bugs I found for -m68020 -fPIC -fstack-limit-symbol and to implement
-fstack-limit-symbol for non-68020 processors.
The correct code is now generated for -mcpu=68020 -fPIC
-fstack-limit-symbol=__stack_start. The PIC offset table register, A5, is now
loaded before it is referenced by the stack check code:
Larrys-MacBook-Air:gcc baker$
/usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=68020 -fPIC
-fstack-limit-symbol=__stack_start -o junk.s junk.c
junk
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups whole-program
inlineAssembling functions:
junk
Execution times (seconds)
tree gimplify : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (25%) wall
0 kB ( 0%) ggc
unaccounted todo : 0.00 ( 0%) usr 0.01 (100%) sys 0.01 (25%) wall
0 kB ( 0%) ggc
TOTAL : 0.00 0.01 0.04
1090 kB
Larrys-MacBook-Air:gcc baker$ cat junk.s
#NO_APP
.filejunk.c
.text
.align2
.globljunk
.typejunk, @function
junk:
link.w %fp,#0
lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5
move.l __stack_start@GOT(%a5),%d0
addq.l #4,%d0
cmp.l %sp,%d0
traphi
unlk %fp
rts
.sizejunk, .-junk
.identGCC: (GNU) 4.6.1
.section.note.GNU-stack,,@progbits
This required patches to m68k.c and m68k.md. I also moved the calculation of
current_function_static_stack_size and limit to account for the stack size
increase on ColdFire processors (use fsize_with_regs in place of
current_frame.size).
RTL is now defined to generate code for -fstack-limit-symbol for non-68020
processors:
Larrys-MacBook-Air:gcc baker$
/usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=5208 -fPIC
-fstack-limit-symbol=__stack_start -o junk.s junk.c
junk
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups whole-program
inlineAssembling functions:
junk
Execution times (seconds)
unaccounted todo : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (100%) wall
0 kB ( 0%) ggc
TOTAL : 0.00 0.00 0.01
1089 kB
Larrys-MacBook-Air:gcc baker$ cat junk.s#NO_APP
.filejunk.c
.text
.align2
.globljunk
.typejunk, @function
junk:
link.w %fp,#0
move.l #_GLOBAL_OFFSET_TABLE_@GOTPC, %a5
lea (-6, %pc, %a5), %a5
move.l __stack_start@GOT(%a5),%d0
addq.l #4,%d0
cmp.l %sp,%d0
bls .+2
trap #7
unlk %fp
rts
.sizejunk, .-junk
.identGCC: (GNU) 4.6.1
.section.note.GNU-stack,,@progbits
This required patches to m68k.md. I implemented the *conditional_trap
pattern for non-68020 processors and renamed *conditional_trap to
*conditional_trap_68020 for 68020 processors.
Compilation, linking, and conversion to uClinux Flat Binary format now works
for ColdFire processors (but does not for 32-bit 68020, which is okay):
Larrys-MacBook-Air:gcc baker$ /usr/local/gcc-4.6-2011.09/bin/m68k-uclinux-gcc
-mcpu=68020 -fPIC -fstack-limit-symbol=__stack_start -o junk main.c junk.c
/usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: reloc type
R_68K_GOT32O is not supported
/usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: reloc type
R_68K_GOT32O is not supported
/usr/local/gcc-4.6-2011.09/m68k-uclinux/bin/elf2flt: error: 2 bad relocs
collect2: ld returned 1 exit status
Larrys-MacBook-Air:gcc baker$ /usr/local/gcc-4.6-2011.09/bin/m68k-uclinux-gcc
-mcpu=5206 -fPIC -fstack-limit-symbol=__stack_start -o junk main.c junk.c
Please review my patches, m68k.{c,md}.trunk.patch. (I have to figure out how
to attach them.) I do not understand, for example, how the TARGET_68020 in
define_expand ctrapsi4 works. It seems not to be a problem to get to the
patterns for generating the correct conditional trap code for non-68020
processors. (Does that mean they are not necessary?) I have not tested real
code yet using the patched Code Sourcery gcc 4.6.1+ ColdFire cross-compiler. I
am on vacation at the moment. I will get back to that next week.
Larry Baker
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #12 from Larry Baker baker at usgs dot gov 2012-08-12 21:28:39 UTC --- Created attachment 27998 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27998 Patch for trunk version 2012-08-12 of gcc/config/m68k.m68k.c
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #13 from Larry Baker baker at usgs dot gov 2012-08-12 21:29:58 UTC --- Created attachment 27999 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27999 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #9 from Larry Baker baker at usgs dot gov 2012-08-09 02:06:27 UTC
---
(In reply to comment #6)
Fixed in 4.8.
Andreas,
My application uses a 4.6.1+ compiler from Code Sourcery for ColdFire uClinux
(no longer being sponsored by Freescale). So, I have been working with those
sources for the moment.
I encounter two gcc ICEs when I request -mcpu=5208
-fstack-limit-symbol=_stack_start:
• With-msep-data: internal compiler error: in gen_reg_rtx, at emit-rtl.c
• Without -msep-data: internal compiler error: in extract_insn, at recog.c
Your fix of bug target 53834/28896 fixes the second ICE, by requiring at least
-mcpu=68020. However, it did not cure the first ICE.
I traced the second ICE to the -fPIC flag, which is implied by -msep-data. The
simplest function, junk.c:
void junk() {}
will demonstrate the ICE, which occurs in cc1. The simplest cc1 command that
will cause the ICE is:
$ /usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=68020
-fPIC -fstack-limit-symbol=_stack_start -o junk.s junk.c
I put a breakpoint at fancy_abort. Here is the backtrace as far the function
prologue code being generated to check the stack pointer in
m68k_expand_prologue() at m68k.c:1078:
#0 fancy_abort (file=0x10064a588
/Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/emit-rtl.c, line=883,
function=0x10064a865 gen_reg_rtx) at
/Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/diagnostic.c:893
#1 0x0001001fdbb8 in gen_reg_rtx (mode=SImode) at
/Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/emit-rtl.c:883
#2 0x0001000ea32a in gen_movsi (operand0=0x1418dd2c0,
operand1=0x1418a9b50) at m68k.md:913
#3 0x00010021ae03 in emit_move_insn_1 (x=0x1418dd2c0, y=0x1418a9b50) at
/Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/expr.c:3311
#4 0x00010021b2c8 in emit_move_insn (x=0x1418dd2c0, y=0x1418a9b50) at
/Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/expr.c:3420
#5 0x000100561c98 in m68k_expand_prologue () at
/Users/baker/Desktop/Software/gcc/gcc-4.6-2011.09/gcc/config/m68k/m68k.c:1078
:
The ICE occurs because of the -fPIC conditional code surrounding m68k.md:913:
else if (flag_pic !TARGET_PCREL symbolic_operand (operands[1], SImode))
{
/* The source is an address which requires PIC relocation.
Call legitimize_pic_address with the source, mode, and a relocation
register (a new pseudo, or the final destination if reload_in_progress
is set). Then fall through normally */
rtx temp = reload_in_progress ? operands[0] : gen_reg_rtx (Pmode);
operands[1] = legitimize_pic_address (operands[1], SImode, temp);
}
I see the same code in the current gcc source tree.
From my reading of the comments, it is preferable to allocate a new pseudo
register. If that is not possible, the destination register is used. I
believe the bug is caused by the insufficient test for whether a pseudo
register can be allocated.
I fixed the test to use can_create_pseudo_p():
/*rtx temp = reload_in_progress ? operands[0] : gen_reg_rtx (Pmode); */
rtx temp = can_create_pseudo_p() ? gen_reg_rtx (Pmode) : operands[0];
That cures the ICE caused by -fPIC -fstack-limit-symbol=_stack_start.
However, I think the generated code is wrong. The reason is that the stack
check code relies on %a5 being valid, but that code is executed before the
prologue code which sets up %a5 to point to the GLOBAL_OFFSET_TABLE (see
below).
Here's my results:
$ /usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=68020
-fPIC -fstack-limit-symbol=_stack_start -o junk.s junk.c
$ cat junk.s
#NO_APP
.filejunk.c
.text
.align2
.globljunk
.typejunk, @function
junk:
move.l _stack_start@GOT(%a5),%d0
addq.l #4,%d0
cmp.l %sp,%d0
traphi
link.w %fp,#0
lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5
unlk %fp
rts
.sizejunk, .-junk
.identGCC: (GNU) 4.6.1
.section.note.GNU-stack,,@progbits
Without -fPIC, I get:
$ /usr/local/gcc-4.6-2011.09/libexec/gcc/m68k-uclinux/4.6.1/cc1 -mcpu=68020
-fstack-limit-symbol=_stack_start -o junk.s junk.c
$ cat junk.s
#NO_APP
.filejunk.c
.text
.align2
.globljunk
.typejunk, @function
junk:
move.l #_stack_start,%d0
addq.l #4,%d0
cmp.l %sp,%d0
traphi
link.w %fp,#0
unlk %fp
rts
.sizejunk, .-junk
.identGCC: (GNU) 4.6.1
.section.note.GNU-stack,,@progbits
Next I will look for the prologue code which sets up %a5 for -fPIC code (in
m68k_expand_prologue() in m68k.c?).
Larry Baker
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #10 from Larry Baker baker at usgs dot gov 2012-08-09 02:16:27 UTC --- (In reply to comment #9) I traced the second ICE to the -fPIC flag, ... should be I traced the first ICE to the -fPIC flag, ... Larry Baker
[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833 --- Comment #1 from Larry Baker baker at usgs dot gov 2012-07-05 18:07:48 UTC --- I didn't try to figure out why the code in libgcc/config/m68k/linux-atomic.c is causing the GCC 4.7.1 xgcc cross compiler to fail. I just patched libgcc/config.host to disable atomic builtins when compiling for Motorola m68k/ColdFire running uClinux with uClibc: --- gcc-4.7.1/libgcc/config.host.orig2012-04-30 10:39:57.0 -0700 +++ gcc-4.7.1/libgcc/config.host2012-07-05 00:01:17.0 -0700 @@ -710,3 +710,3 @@ m68k-*-uclinux*)# Motorola m68k/ColdFire running uClinux with uClibc -tmake_file=$tmake_file m68k/t-floatlib m68k/t-linux +tmake_file=$tmake_file m68k/t-floatlib md_unwind_header=m68k/linux-unwind.h Someone still needs to figure out why the implementation fails for m68k-uclinux --with-arch=cf.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #7 from Larry Baker baker at usgs dot gov 2012-07-03 23:43:46 UTC --- (In reply to comment #6) Fixed in 4.8. Refer to bug 53834 (duplicate of this bug) for original report. Changing -mcpu=5208 to -mcpu=68020 resolves only the -fstack-limit-reg= ICE (conditional traps not supported by M5208 processor); the -fstack-limit-symbol= ICE still occurs for a supported processor. # sh -v make_ntpq.sh #!/bin/sh ( cd linux/user/ntp/builddir/ntpq ; \ PATH=/usr/local/src/gcc-xgcc-4.7.1/gcc:$PATH \ ucfront-gcc xgcc -mcpu=68020 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -fno-dwarf2-cfi-asm -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -DHAVE_CONFIG_H -I. -I../../ntpq -I.. -I../../include -I../../libopts -DCONFIG_FILE=\/etc/config/ntp.conf\ -MT ntpq.o -MD -MP -MF .deps/ntpq.Tpo -c -o new_ntpq.o ../../ntpq/ntpq.c \ ) ../../ntpq/ntpq.c: In function 'decodeint': ../../ntpq/ntpq.c:1978:7: warning: pointer targets in passing argument 2 of 'hextoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:73:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c:1979:3: warning: pointer targets in passing argument 2 of 'octtoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:91:12: note: expected 'u_long *' but argument is of type 'long int *' ( cd linux/user/ntp/builddir/ntpq ; \ PATH=/usr/local/src/gcc-xgcc-4.7.1/gcc:$PATH \ ucfront-gcc xgcc -mcpu=68020 -DCONFIG_COLDFIRE -Os -g -fstack-limit-symbol=_stack_start -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -fno-dwarf2-cfi-asm -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -DHAVE_CONFIG_H -I. -I../../ntpq -I.. -I../../include -I../../libopts -DCONFIG_FILE=\/etc/config/ntp.conf\ -MT ntpq.o -MD -MP -MF .deps/ntpq.Tpo -c -o new_ntpq.o ../../ntpq/ntpq.c \ ) ../../ntpq/ntpq.c: In function 'decodeint': ../../ntpq/ntpq.c:1978:7: warning: pointer targets in passing argument 2 of 'hextoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:73:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c:1979:3: warning: pointer targets in passing argument 2 of 'octtoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:91:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c: In function 'assoccmp': ../../ntpq/ntpq.c:3279:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:859 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. ( cd linux/user/ntp/builddir/ntpq ; \ PATH=/usr/local/src/gcc-xgcc-4.7.1/gcc:$PATH \ ucfront-gcc xgcc -mcpu=68020 -DCONFIG_COLDFIRE -Os -g -fstack-limit-register=a5 -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -fno-dwarf2-cfi-asm -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -DHAVE_CONFIG_H -I. -I../../ntpq -I.. -I../../include -I../../libopts -DCONFIG_FILE=\/etc/config/ntp.conf\ -MT ntpq.o -MD -MP -MF .deps/ntpq.Tpo -c -o new_ntpq.o ../../ntpq/ntpq.c \ ) ../../ntpq/ntpq.c: In function 'decodeint': ../../ntpq/ntpq.c:1978:7: warning: pointer targets in passing argument 2 of 'hextoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:73:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c:1979:3: warning: pointer targets in passing argument 2 of 'octtoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:91:12: note: expected 'u_long *' but argument is of type 'long int *'
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #8 from Larry Baker baker at usgs dot gov 2012-07-04 01:40:23 UTC
---
Andreas,
I posted my negative findings that -mcpu=68020 still causes the
-fstack-limit-symbol code path to fail. I believe the fundamental problem
there is the allocation of two different rtx registers that should actually
refer to the same rtx register. Consider the code in gcc/config/m68k/m68k.c:
/* If the stack limit is a symbol, we can check it here,
before actually allocating the space. */
if (crtl-limit_stack
GET_CODE (stack_limit_rtx) == SYMBOL_REF)
{
limit = plus_constant (stack_limit_rtx, current_frame.size + 4);
if (!m68k_legitimate_constant_p (Pmode, limit))
{
emit_move_insn (gen_rtx_REG (Pmode, D0_REG), limit);
limit = gen_rtx_REG (Pmode, D0_REG);
}
emit_insn (gen_ctrapsi4 (gen_rtx_LTU (VOIDmode,
stack_pointer_rtx, limit),
stack_pointer_rtx, limit,
const1_rtx));
}
fsize_with_regs = current_frame.size;
My analysis is (I am NOT a compiler developer, so I could be way off base here)
that gen_rtx_REG returns an rtx register reference to an unlimited pool of rtx
registers. Somehow, later, the binding of the physical register D0_REG takes
place -- I guess in the code generator. The emit_move_insn copies the limit
rtx expression into an unnamed rtx register. That rtx register is valid, i.e.,
has a value. The next line seems to be intended to modify limit to refer to
the rtx register containing the original limit value for use in emit_insn( trap
). However, the rtx expression assigned to limit is not the rtx register that
has been set up; it is a new rtx register that is not valid, i.e., has no
value.
This code gets skipped if the limit rtx expression is already a valid constant.
Which, I assume means it is a numeric constant, not a symbolic constant.
I think the proper code should name the rtx register allocated for the
emit_move_insn and then copy the value of that name into the limit rtx
expression:
{
rtx d0reg = gen_rtx_REG (Pmode, D0_REG);
emit_move_insn (d0reg, limit);
limit =d0reg;
}
What do you think?
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 3 Jul 2012, at 2:47 AM, sch...@linux-m68k.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
Andreas Schwab sch...@linux-m68k.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.8.0
--- Comment #6 from Andreas Schwab sch...@linux-m68k.org 2012-07-03
09:47:41 UTC ---
Fixed in 4.8.
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug target/53833] New: m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833 Bug #: 53833 Summary: m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146) Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ba...@usgs.gov Created attachment 27732 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27732 Make m68k-uclinux cross compiler Host: i686-pc-linux (also x86_64-apple-darwin10.8.0) Target: m68k-uclinux (Coldfire) I have been able to create native and cross compilers on CentOS Linux i386 for gcc 4.6.1 and 4.6.3. However, all attempts to make a cross compiler for gcc 4.7 fail when the new xgcc compiles linux-atomic.c for libgcc (which did not exist in the gcc 4.6 versions). I have been compiling the cross compiler with the same version of the native compiler. Same thing happens when I compile a 4.7 cross compiler with a 4.6 native compiler. (No surprise, because the compiler that fails is the new xgcc.) Same result from my Mac OS X 10.6.8 (using a native gcc 4.7.1 compiler I compiled; 10.6.8 still defaults to a gcc compiler which I used to compile the native gcc 4.7.1). Same result using the gcc-4.7-20120630.tar.gz (1 Jul 00:48, 102365191 Bytes) gcc 4.7 trunk tarball I found at http://fossies.org/unix/misc/. (I saw there was a slight change in gcc/config/m68k/sync.md; didn't help.) I suspect the new atomic builtins are no good for a Coldfire processor. But, I don't know how the cross compiler is being told which flavor of M68000 it is. The error message (i686-pc-linux to m68k-uclinux) is at: /usr/local/src/gcc/./gcc/xgcc -B/usr/local/src/gcc/./gcc/ -B/opt/lantronix/sdk/toolchains/freescale-coldfire-2011.09/m68k-uclinux/bin/ -B/opt/lantronix/sdk/toolchains/freescale-coldfire-2011.09/m68k-uclinux/lib/ -isystem /opt/lantronix/sdk/toolchains/freescale-coldfire-2011.09/m68k-uclinux/include -isystem /opt/lantronix/sdk/toolchains/freescale-coldfire-2011.09/m68k-uclinux/sys-include --sysroot=/opt/lantronix/sdk/toolchains/freescale-coldfire-2011.09/m68k-uclinux/libc -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc -I../../../gcc-4.7.1/libgcc -I../../../gcc-4.7.1/libgcc/. -I../../../gcc-4.7.1/libgcc/../gcc -I../../../gcc-4.7.1/libgcc/../include -DHAVE_CC_TLS -o unwind-dw2-fde.o -MT unwind-dw2-fde.o -MD -MP -MF unwind-dw2-fde.dep -fexceptions -c ../../../gcc-4.7.1/libgcc/unwind-dw2-fde.c ../../../gcc-4.7.1/libgcc/config/m68k/linux-atomic.c: In function '__sync_bool_compare_and_swap_1': ../../../gcc-4.7.1/libgcc/config/m68k/linux-atomic.c:203:1: internal compiler error: in emit_library_call_value_1, at calls.c:4146 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I have attached the make file I use. (It has a bunch of lines at the bottom that are disabled from the CodeSourcery shell script I used as a template, from https://sourcery.mentor.com/GNUToolchain/package9493/public/m68k-uclinux/freescale-coldfire-2011.09-23-m68k-uclinux.src.tar.bz2. They have their own source for their 4.6.1 compiler. The reason I'm doing this is that all the CodeSourcery cross compilers and the GNU 4.6.1 and 4.6.3 cross compilers fail with an ICE when I use -fstack-limit-symbol=_stack_start. I'm trying to figure out if that is fixed in the 4.7 compilers before I file a bug report.) Thank you in advance for your assistance.
[Bug target/53834] New: ICE with -fstack-limit-symbol=_stack_start for m68k-uclinux ColdFire cross compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53834 Bug #: 53834 Summary: ICE with -fstack-limit-symbol=_stack_start for m68k-uclinux ColdFire cross compiler Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ba...@usgs.gov This might be caused by the same bug as 28896, though it looks to me like the remedy suggested there has already been applied. CodeSourcery gcc 4.6.1 (ColdFire uClinux release 2011.09-23 at http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/) and GNU gcc 4.6.1, 4.6.3, and 4.7.1 all fail when cross compiling for m68k-uclinux ColdFire (-mcpu=5208) when I use the -fstack-limit-symbol=_stack_start option. An internal compiler assertion fails in gen_reg_rtx, at emit-rtl.c:859. For example, below is the output from xgcc 4.7.1 when compiling the ntpq program from ntp.org. (xgcc comes from the partial build of a gcc 4.7.1 cross compiler. My make of a gcc 4.7.1 cross compiler failed making libgcc, but the xgcc cross compiler seems okay. Reported in bug 53833.) I also tried -fstack-limit-register=d0 and -fstack-limit-register=a5 (guesses for legal register names). Those attempts fail with an IDE as well, but at a different location: in extract_insn, at recog.c:2123. They also seem to be for a different reason, relating to code generation, not an internal compiler assertion failure. # sh -v make_ntpq.sh #!/bin/sh ( cd linux/user/ntp/builddir/ntpq ; \ PATH=/usr/local/src/gcc-xgcc-4.7.1/gcc:$PATH \ ucfront-gcc xgcc -mcpu=5208 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -fno-dwarf2-cfi-asm -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -DHAVE_CONFIG_H -I. -I../../ntpq -I.. -I../../include -I../../libopts -DCONFIG_FILE=\/etc/config/ntp.conf\ -MT ntpq.o -MD -MP -MF .deps/ntpq.Tpo -c -o new_ntpq.o ../../ntpq/ntpq.c \ ) ../../ntpq/ntpq.c: In function 'decodeint': ../../ntpq/ntpq.c:1978:7: warning: pointer targets in passing argument 2 of 'hextoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:73:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c:1979:3: warning: pointer targets in passing argument 2 of 'octtoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:91:12: note: expected 'u_long *' but argument is of type 'long int *' ( cd linux/user/ntp/builddir/ntpq ; \ PATH=/usr/local/src/gcc-xgcc-4.7.1/gcc:$PATH \ ucfront-gcc xgcc -mcpu=5208 -DCONFIG_COLDFIRE -Os -g -fstack-limit-symbol=_stack_start -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -fno-dwarf2-cfi-asm -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -DHAVE_CONFIG_H -I. -I../../ntpq -I.. -I../../include -I../../libopts -DCONFIG_FILE=\/etc/config/ntp.conf\ -MT ntpq.o -MD -MP -MF .deps/ntpq.Tpo -c -o new_ntpq.o ../../ntpq/ntpq.c \ ) ../../ntpq/ntpq.c: In function 'decodeint': ../../ntpq/ntpq.c:1978:7: warning: pointer targets in passing argument 2 of 'hextoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:73:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c:1979:3: warning: pointer targets in passing argument 2 of 'octtoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:91:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c: In function 'assoccmp': ../../ntpq/ntpq.c:3279:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:859 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. ( cd linux/user/ntp/builddir/ntpq ; \ PATH=/usr/local/src/gcc-xgcc-4.7.1/gcc:$PATH \ ucfront-gcc xgcc -mcpu=5208 -DCONFIG_COLDFIRE -Os -g -fstack-limit-register=a5 -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DEMBED -fno-dwarf2-cfi-asm -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -DHAVE_CONFIG_H -I. -I../../ntpq -I.. -I../../include -I../../libopts -DCONFIG_FILE=\/etc/config/ntp.conf\ -MT ntpq.o -MD -MP -MF .deps/ntpq.Tpo -c -o new_ntpq.o ../../ntpq/ntpq.c \ ) ../../ntpq/ntpq.c: In function 'decodeint': ../../ntpq/ntpq.c:1978:7: warning: pointer targets in passing argument 2 of 'hextoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0: ../../include/ntp_stdlib.h:73:12: note: expected 'u_long *' but argument is of type 'long int *' ../../ntpq/ntpq.c:1979:3: warning: pointer targets in passing argument 2 of 'octtoint' differ in signedness [-Wpointer-sign] In file included from ../../ntpq/ntpq.c:18:0:
