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.
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 stac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
--- Comment #7 from Larry Baker ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
--- Comment #6 from Larry Baker ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
--- Comment #4 from Larry Baker ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58276
--- Comment #2 from Larry Baker ---
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 changed:
>
> What|Removed |Added
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
downloa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234
--- Comment #6 from Larry Baker ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234
--- Comment #4 from Larry Baker ---
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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58234
--- Comment #2 from Larry Baker ---
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
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 us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #19 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #17 from Larry Baker 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++,
> whi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #15 from Larry Baker 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 LIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #13 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #43 from Larry Baker 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/bot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #42 from Larry Baker 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
so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #41 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #9 from Larry Baker 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, wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #8 from Larry Baker 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 wa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #7 from Larry Baker 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" \
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #6 from Larry Baker 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 n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #5 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #4 from Larry Baker 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/Makefil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #3 from Larry Baker 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.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #2 from Larry Baker 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, t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #40 from Larry Baker 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 (expe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #39 from Larry Baker 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 bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #38 from Larry Baker 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 (prerel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #37 from Larry Baker 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 buil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #36 from Larry Baker 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 bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #35 from Larry Baker 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 (prerel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #34 from Larry Baker 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #33 from Larry Baker 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
uClinu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584
--- Comment #7 from Larry Baker 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.ucl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584
--- Comment #6 from Larry Baker 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 fin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584
--- Comment #4 from Larry Baker 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 wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833
--- Comment #4 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833
--- Comment #3 from Larry Baker 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 wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584
--- Comment #3 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584
--- Comment #2 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #32 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #31 from Larry Baker 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
uClinu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #30 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #29 from Larry Baker 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 c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584
--- Comment #1 from Larry Baker 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__[
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: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #28 from Larry Baker 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
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: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833
--- Comment #2 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #27 from Larry Baker 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=28896
Larry Baker changed:
What|Removed |Added
Attachment #28165|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #25 from Larry Baker 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. The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #24 from Larry Baker 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 a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
Larry Baker changed:
What|Removed |Added
Attachment #28164|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
Larry Baker changed:
What|Removed |Added
Attachment #28081|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
Larry Baker changed:
What|Removed |Added
Attachment #28054|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
Larry Baker changed:
What|Removed |Added
Attachment #27998|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #19 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
Larry Baker changed:
What|Removed |Added
Attachment #28048|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
Larry Baker changed:
What|Removed |Added
Attachment #28024|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #16 from Larry Baker 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_cr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
Larry Baker changed:
What|Removed |Added
Attachment #27999|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #13 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #12 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #11 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #10 from Larry Baker 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #9 from Larry Baker 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 be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833
--- Comment #1 from Larry Baker 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 bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #8 from Larry Baker 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 differ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896
--- Comment #7 from Larry Baker 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
(co
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
Sta
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
Prod
74 matches
Mail list logo
