https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
Joseph S. Myers changed:
What|Removed |Added
Target Milestone|8.0 |7.4
--- Comment #25 from Joseph S.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #24 from Joseph S. Myers ---
Author: jsm28
Date: Mon Jan 29 21:00:52 2018
New Revision: 257165
URL: https://gcc.gnu.org/viewcvs?rev=257165=gcc=rev
Log:
Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467).
PR target/68467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #23 from Jeffrey A. Law ---
I've got no objection Joseph. But I think you need to make your case to Richi
and Jakub -- I doubt they're on CC for this BZ :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #22 from joseph at codesourcery dot com ---
What do the m68k maintainers think about the suggestion of backporting to
GCC 7 (and for that matter GCC 6)? This is a regression in the sense of
"libgcc used to build for ColdFire, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #21 from Waldemar Brodkorb ---
I can confirm that this fixes the problem even for gcc 7.x.
Any chance to get it included into gcc 7 branch?
No regression found while running the uClibc-ng testsuite inside
qemu-system-m68k.
Thanks a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
Joseph S. Myers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #19 from Joseph S. Myers ---
Author: jsm28
Date: Wed Jan 24 23:36:29 2018
New Revision: 257032
URL: https://gcc.gnu.org/viewcvs?rev=257032=gcc=rev
Log:
Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467).
PR target/68467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #18 from Carlos Soto ---
(In reply to angelo from comment #17)
> Hi Carlos,
>
> maybe you can try one of these 2 toolchains i prepared years ago:
>
> http://sysam.it/toolchains.html
>
> Regads,
> Angelo
>
Hi angelo,
thanks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #17 from angelo ---
Hi Carlos,
maybe you can try one of these 2 toolchains i prepared years ago:
http://sysam.it/toolchains.html
Regads,
Angelo
On 25/06/2017 20:40, csotoalonso at gmail dot com wrote:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
Carlos Soto changed:
What|Removed |Added
CC||csotoalonso at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #15 from Waldemar Brodkorb ---
Jeffrey, seems gcc 7 is coming soon, any chance getting this resolved?
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
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #13 from Waldemar Brodkorb ---
Okay.
So what is your opinion, how we proceed here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #12 from Andreas Schwab ---
linux-atomic is independent of libc and libpthread, it implements compiler
intrinsics and only depends on the kernel support for CAS on Coldfire.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #11 from Waldemar Brodkorb ---
I talking about following change:
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.host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #10 from Andreas Schwab ---
The fact that libcalls aren't using the C ABI is likely hurting everyone.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #8 from Jeffrey A. Law ---
Unsure. I thought libstdc++ used some of the libatomic facilities under the
hood so we'd just replace one build failure with another.
It might also mess up the older 68k systems (assuming I'm wrong about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #7 from Waldemar Brodkorb ---
Can't we disable compilation of linux-atomic.c for gcc7 then?
So that at least it is possible to build a toolchain for coldfire?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #6 from Jeffrey A. Law ---
This is a bad interaction between PREFERRED_STACK_BOUNDARY and PUSH_ROUNDING,
but there's a deeper code generation issue that needs to be looked at as well.
So background. A push insn on the m68k is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #5 from Joseph S. Myers ---
Created attachment 40117
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40117=edit
preprocessed source
Preprocessed source of file causing ICE attached. Compile with: -S -g -O2
-fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
Jeffrey A. Law changed:
What|Removed |Added
CC||baker at usgs dot gov
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
24 matches
Mail list logo