http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56554
Bug #: 56554
Summary: stage2 ./intl: error: C compiler cannot create
executables
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56554
--- Comment #1 from Douglas Mencken 2013-03-06
23:15:46 UTC ---
Created attachment 29602
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29602
readelf of /usr/lib/libgcc_s.so.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56554
--- Comment #2 from Douglas Mencken 2013-03-06
23:16:36 UTC ---
Created attachment 29603
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29603
readelf of _gcc_bootstrap/./prev-gcc/libgcc_s.so.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56554
--- Comment #3 from Douglas Mencken 2013-03-06
23:20:51 UTC ---
Created attachment 29604
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29604
Attaching intl/config.log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56554
Douglas Mencken changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54459
Bug #: 54459
Summary: [4.8 regression] Bootstrap fails with "aliased to
undefined symbol"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54453
--- Comment #4 from Douglas Mencken 2012-09-02
18:13:40 UTC ---
Yes, looks like my bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54459
I can add that snapshot
ftp://ftp.fu-berlin.de/unix/languages/gcc/snapshots/4.8-20120826/gcc-4.8-20120826.ta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54453
--- Comment #5 from Douglas Mencken 2012-09-03
02:12:01 UTC ---
Successfully bootstrapped with ``Revert a few Makefile.am regexps'' patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54453
--- Comment #8 from Douglas Mencken 2012-09-03
15:45:09 UTC ---
Why the ``Revert a few Makefile.am regexps'' is still not committed? This sed
gotcha is not about single architecture, not about bit-wideness (32- or
64-bit), it's very common. And t
In function '__popcountsi2'
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougmencken at gmail dot com
GCC host triplet:
--- Comment #2 from dougmencken at gmail dot com 2009-10-04 18:55 ---
Subject: Re: libgcc2.c: internal compiler error: Illegal
instruction In function '__popcountsi2'
Host compiler:
$ gcc --version
gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
Copyright (C) 2009 Fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47885
Summary: "find: unrecognized: -follow"
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassig...@gcc.gnu.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46263
--- Comment #1 from Douglas Mencken 2011-03-04
20:05:27 UTC ---
With the following patch commands:
http://ftp.osuosl.org/pub/manulix/scripts/build-scripts/PATCHCMDS/patchcmds-gcc
GCC v 4.6.0 builds fine (snapshot 20110226).
For those of you, who
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46263
--- Comment #2 from Douglas Mencken 2011-03-04
20:15:08 UTC ---
Oops. Sorry. Wrong bug report. The correct one is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47885 (i.e.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26694). Sorry again, but the
cor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49740
--- Comment #5 from Douglas Mencken 2011-10-12
20:03:14 UTC ---
(In reply to comment #4)
Yep, it's still broken (gcc-4.7-20111008).
Configure line:
./gcc-v4.7-20111008.sourcedir/configure --prefix=/usr --sysconfdir=/etc
--mandir=/usr/share/man
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49740
Douglas Mencken changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46311
Douglas Mencken changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|MOVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49740
Douglas Mencken changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51787
Bug #: 51787
Summary: [4.7.0 Regression] internal compiler error: in
inline_small_functions, at ipa-inline.c:1410
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51787
--- Comment #1 from Douglas Mencken 2012-01-07
20:48:15 UTC ---
Created attachment 26268
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26268
pre-processed output of last failed operation (compressed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51787
--- Comment #3 from Douglas Mencken 2012-01-09
17:43:20 UTC ---
I can re-confirm that snapshots 4.7-20111231, 4.7-20120107 do fail (can't enter
this into "Known to fail" field, because despite that
http://gcc.gnu.org/bugzilla/page.cgi?id=fields.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51787
--- Comment #5 from Douglas Mencken 2012-01-11
03:33:40 UTC ---
Fixed PR51801 fixes this issue too. Current checkout bootstraps successfully.
: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: dougmencken at gmail dot com
Target Milestone: ---
I’m building gcc 8.1 release, and got
build/gencheck >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #1 from Douglas Mencken ---
May this https://patchwork.ozlabs.org/patch/838856/ is related?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #2 from Douglas Mencken ---
reverting of Michael’s patch gives
/Developer/GCC/7.3p/PowerPC/32bit/bin/g++ -std=gnu++98 -fno-PIE -c
-DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -mdynamic-no-pic -DIN_GCC
-fno-exceptions -fno-rtti -fasync
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #4 from Douglas Mencken ---
(In reply to Richard Biener from comment #3)
> How did you configure?
As always
../gcc-8.1.0/configure \
--build=powerpc-unknown-darwin --host=powerpc-unknown-darwin
--target=powerpc-unknown-darwin \
--pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #5 from Douglas Mencken ---
Bisecting is hard, because commits before
15adae8bbeb4579910eadf636e3b06f3dae4a342 “ PR bootstrap/82939
* line-map.c (linemap_init): Avoid broken value-init when compiling with GCC
4.2 ”
segfault on genmatc
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dougmencken at gmail dot com
Target Milestone: ---
Created attachment 43277
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43277&action=e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #1 from Douglas Mencken ---
ah yep, it’s at first stage
$ cat stage_current
stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #3 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #2)
> You cut away the most interesting part: the insn pattern that does not exist.
> Could you show us?
Sure, but how?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
Douglas Mencken changed:
What|Removed |Added
Known to fail||7.1.0, 7.2.0
--- Comment #6 from Dougl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
Douglas Mencken changed:
What|Removed |Added
Known to work||6.4.0
--- Comment #7 from Douglas Menc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #8 from Douglas Mencken ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Segher Boessenkool from comment #2)
> > You cut away the most interesting part: the insn pattern that does not
> > exist.
> > Could you show us?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #10 from Douglas Mencken ---
(In reply to Jakub Jelinek from comment #9)
> Because powerpc*-darwin* is neither a primary nor secondary platform, see
> http://gcc/gnu.org/gcc-8/criteria.html , and therefore bugs in such a port
> are no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #12 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #11)
> It will be fixed. But not many people have access to powerpc-darwin systems
> to test on.
I prefer “would” before “will”, and I may give an access to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #14 from Douglas Mencken ---
(In reply to Jakub Jelinek from comment #13)
> No, it means anybody can fix it, just the release will not be blocked if it
> is not fixed.
Well, nice. May I fix it? What happened between 6.4 and 7.1? Wher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #15 from Douglas Mencken ---
another question: what is so special with "darwin" (besides that long story
when apple ditched gcc due to gpl v3 and created llvm'n'stuff which is still
unavail for powerpc) to have all these libgcc/config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #17 from Douglas Mencken ---
diff of libgcc/unwind-dw2.c between 6.4 and 7.1
--- a/libgcc/unwind-dw2.c
+++ b/libgcc/unwind-dw2.c
@@ -1,5 +1,5 @@
/* DWARF2 exception handling and frame unwind runtime interface routines.
- Copyright
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #18 from Douglas Mencken ---
(In reply to Douglas Mencken from comment #17)
> diff of libgcc/unwind-dw2.c between 6.4 and 7.1
>
Reverting this file doesn’t help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #19 from Douglas Mencken ---
I got repo from git://gcc.gnu.org/git/gcc.git and begun to bisect it to find
the cause of regression
"good" here means reaching build of libstdc++-v3 after than problem libgcc
$ git bisect start
$ git bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #20 from Douglas Mencken ---
$ git bisect good
good: [270b838d816f8a2c372eac0121adcdf570feccfa] Regenerate .pot files.
Bisecting: 90 revisions left to test after this (roughly 7 steps)
[6f2116bed6e87668a914dc27fff34c7a68576d4e] P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #21 from Douglas Mencken ---
Created attachment 43334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43334&action=edit
Reverting patch
I fully reverted that commit on top of gcc-7_3_0-release, and build succeeds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #22 from Douglas Mencken ---
So yet I have fully workin’
$ /Developer/GCC/7.3patched/PowerPC/32bit/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/Developer/GCC/7.3patched/PowerPC/32bit/bin/gcc
COLLECT_LTO_WRAPPER=/Developer/GCC/7.3pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #24 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #23)
> GCC 7 was released more than nine months ago, and yet no one has noticed
> that it does not build at all on powerpc-darwin. We cannot do magic.
Well, y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #26 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #25)
> Please test https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtnZhWiDkC4z.txt
Okay, and as I got it, it is supposed to apply upon fresh GCC with that “Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #28 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #27)
> Yes.
Wow, it compiles
So I suggest to push patch
https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtnZhWiDkC4z.txt after checking
on other rs6000 system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865
Douglas Mencken changed:
What|Removed |Added
CC||dougmencken at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #30 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #29)
> The patch has never been sent to gcc-patches. It also still never was
> properly tested. Can you do that?
Like doing ‘make check’ after it completes 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #31 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #29)
> The patch has never been sent to gcc-patches. It also still never was
> properly tested. Can you do that?
Or you’re bout sending it to “gcc-patches” b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #33 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #32)
> Yes, run "make -k check" (add -jN to taste if you have multiple CPUs).
> And then run contrib/test_summary. See if that is as expected (compare
> it to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #34 from Douglas Mencken ---
And this https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00181.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #35 from Douglas Mencken ---
(In reply to Douglas Mencken from comment #34)
> And this https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00181.html
By merging that patch this issue is okay to close as resolved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #37 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #36)
> I'll take care of it.
Fine. I published my build here https://ftp.osuosl.org/pub/manulix/other/GCC/
And they’re on “rs6000” too (;
manulix@ftp-osl ~]$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #9 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #8)
> Is this on all (PowerPC) Darwin? Only one some versions? Which, then?
I am really not going to check it on OS X 10.0 or OS X Beta, or even OS X 10.2.
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #11 from Douglas Mencken ---
I’m bisecting yet
CC="ccache /Developer/GCC/7.3p/PowerPC/32bit/bin/gcc" \
CXX="ccache /Developer/GCC/7.3p/PowerPC/32bit/bin/g++" \
../gcc-build/configure \
--build=powerpc-unknown-darwin --host=powerpc-un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #12 from Douglas Mencken ---
I finished it
git bisect start
git bisect good gcc-7_3_0-release # r257041
git bisect bad gcc-8_1_0-release # r259829
git bisect good 7369309777f6d6e630fb7763bcd08a0317727e36 # r247015 merge parent
git bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #13 from Douglas Mencken ---
Current repo which HEAD is
commit b75be89021ca1da066f892d9a26329009432654c
Author: meissner
Date: Wed Oct 24 20:16:31 2018 +
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@265471
138bc75d-0d04-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #16 from Douglas Mencken ---
Like this?
--- a/gcc/config/rs6000/darwin.h
+++ b/gcc/config/rs6000/darwin.h
@@ -150,13 +150,12 @@
#undef RS6000_STARTING_FRAME_OFFSET
#define RS6000_STARTING_FRAME_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #18 from Douglas Mencken ---
(In reply to Wilco from comment #17)
> Yes that should work.
Oops, but it doesn’t. I just tested it with patched 8.2. Same messages, same
breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #19 from Douglas Mencken ---
I dunno are such warnings related or not
echo timestamp > s-gtype
ccache /Developer/GCC/7.3p/PowerPC/32bit/bin/g++ -std=gnu++98 -fno-PIE -c -g
-mdynamic-no-pic -DIN_GCC -fno-exceptions -fno-rtti
-fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #22 from Douglas Mencken ---
(In reply to Wilco from comment #21)
> That's odd. The stack pointer is definitely 16-byte aligned in all cases
> right?
As I know, PowerPC has no special “stack pointer”, it is just one of general
purp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #23 from Douglas Mencken ---
Created attachment 44901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44901&action=edit
fix_gcc8_build.patch
Reversion of r251713, updated for patching sources of 8.2 release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #25 from Douglas Mencken ---
(In reply to Wilco from comment #24)
> Yes the stage1 compiler would be fine or alternatively use
> --disable-bootstrap to get an installed compiler.
I’m yet at libstdc++ of stage2 (which means that it s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #28 from Douglas Mencken ---
Created attachment 44902
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44902&action=edit
8.2patched-pr78468.s
Assembly produced by patched 8.2’s stage1 xgcc compiled using
prev-gcc/xgcc -B/Volumes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #34 from Douglas Mencken ---
Created attachment 44903
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44903&action=edit
8.2vanilla-pr78468.s
And there’s assembly produced by *vanilla* (id est with Wilco’s r251713 causing
the fai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #35 from Douglas Mencken ---
(In reply to Wilco from comment #33)
> So functions must preserve 16-byte alignment, but can they rely on the stack
> being always 16-byte aligned on entry?
I bet yes when it’s not some hardcoded-by-hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #36 from Douglas Mencken ---
(In reply to Iain Sandoe from comment #31)
> * please could you use
> --build=powerpc-apple-darwin9 --host=powerpc-apple-darwin9
> --target=powerpc-apple-darwin9 (or leave these off - which will cause it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #37 from Douglas Mencken ---
And some more in my wish list. May GCC don’t generate these
.align 2
in text section? Any, each and every powerpc instruction is 32bit-wide, no and
never more, no and never less, so these aligns are red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #39 from Douglas Mencken ---
(In reply to Wilco from comment #38)
> You can have data in text sections, including bytes and half words. Even if
> instructions aligned automatically, the function label might be unaligned if
> it was p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #40 from Douglas Mencken ---
Yet I got what I wanted ~ the working GCC 8.2
$ /Developer/GCC/8.2p/PowerPC/32bit/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/Developer/GCC/8.2p/PowerPC/32bit/bin/gcc
COLLECT_LTO_WRAPPER=/Developer/GCC/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #42 from Douglas Mencken ---
(In reply to Wilco from comment #41)
> So what is the disassembly now?
$ /Developer/GCC/8.2p/PowerPC/32bit/bin/gcc -O2 -fno-inline pr78468.c
-save-temps
$ mv pr78468.s ~/
$ diff -u ~/8.2patched-pr78468.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #44 from Douglas Mencken ---
I got assembly of pr78468.c from various versions of GCC
• 7.3 produces absolutely the same as patched 8.2
• 6.4 produces slightly different assembly with stmw & lmw and different
sequence of instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #45 from Douglas Mencken ---
(In reply to self from comment #44)
> I can’t get where is the value of STACK_DYNAMIC_OFFSET in published assembly
> and why do you think it is wrong
Most likely this value is shown as 96 in “addi r1,r30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #46 from Douglas Mencken ---
(In reply to Wilco from comment #38)
> You can have data in text sections, including bytes and half words. Even if
> instructions aligned automatically, the function label might be unaligned if
> it was p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #54 from Douglas Mencken ---
(In reply to Wilco from comment 51)
> (In reply to Segher Boessenkool from comment 49)
> > (In reply to Douglas Mencken from comment 46)
> > > Yeah, PowerPC doesn’t have addressing via PC, thus it requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #55 from Douglas Mencken ---
(In reply to Wilco from comment #52)
> (In reply to Segher Boessenkool from comment #50)
> > The generic code rounded up the allocation size twice, and that isn't
> > needed.
> >
> > The problem has been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #59 from Douglas Mencken ---
(In reply to Segher Boessenkool from comment #58)
> This patch
> (https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtNTsImfm9sQ.txt) is okay
> for trunk and all open branches, btw.
It needs some update, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #62 from Douglas Mencken ---
(In reply to Iain Sandoe from comment #61)
> Created attachment 44908 [details]
> Proposed 8.x patch
>
> here is the revised patch for the post wi::int_traits world. Works For Me(tm)
>
> Please confirm f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Douglas Mencken changed:
What|Removed |Added
Attachment #44902|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Douglas Mencken changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #69 from Douglas Mencken ---
(In reply to Iain Sandoe from comment #64)
> so all languages, m32/m64, --enable-checking=all,rtl,tree trunk bootstrap
> completed without error (with the patch above + one to enable Ada to work on
> Darwi
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dougmencken at gmail dot com
Target Milestone: ---
When I try to cross-compile GCC from powerpc-darwin to powerpc64-darwin, it
fails at the beginning of libgcc
configure:3665: checking for suffix of object files
configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87891
--- Comment #1 from Douglas Mencken ---
Created attachment 44960
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44960&action=edit
assembly of conftest.c
It really can’t assemble main() { return 0; }
$ /Volumes/hfsplushd/Development/gcc-to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87891
--- Comment #3 from Douglas Mencken ---
When I change
ORIGINAL_AS_FOR_TARGET=""
to
ORIGINAL_AS_FOR_TARGET="as"
inside gcc/as shell script, it succeeds, but not for long
/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/xgcc
-B/Volume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87891
--- Comment #4 from Douglas Mencken ---
(In reply to Jonathan Wakely from comment #2)
> Do you have an assembler for the cross-target installed?
The same system’s `as` eats both of ppc and ppc64 assembly. It looks like that
build machinery of GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87891
--- Comment #5 from Douglas Mencken ---
Then when I do
# header search path is -isystem ./include
ln -s /usr/include/sys ./gcc/include/sys
ln -s /usr/include/machine ./gcc/include/machine
ln -s /usr/include/ppc ./gcc/include/ppc
ln -s /usr/inclu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87891
Douglas Mencken changed:
What|Removed |Added
Component|c |bootstrap
--- Comment #6 from Douglas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87891
--- Comment #7 from Douglas Mencken ---
So it’s not enough to just softlink ranlib, which is nothing more than alias to
libtool, and libtool sees it is invoked as ranlib, and fails to work as
"ranlib" when it’s powerpc64-unknown-darwin-ranlib
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87891
--- Comment #8 from Douglas Mencken ---
I found that I can add to configure line
AS_FOR_TARGET=as \
AR_FOR_TARGET=ar \
LD_FOR_TARGET=ld \
NM_FOR_TARGET=nm \
RANLIB_FOR_TARGET=ranlib \
LIPO_FOR_TARGET=lipo \
STRIP_FOR_TARGET=strip \
OBJDUMP_FOR_T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87891
--- Comment #9 from Douglas Mencken ---
(In reply to self from comment 8)
> I found that I can add to configure line
>
> AS_FOR_TARGET=as \
> AR_FOR_TARGET=ar \
> LD_FOR_TARGET=ld \
> NM_FOR_TARGET=nm \
> RANLIB_FOR_TARGET=ranlib \
> LIPO_FOR_TA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87891
--- Comment #10 from Douglas Mencken ---
And this one is beyond my understanding
/bin/sh ../../../gcc-8.2.0/libgcc/../mkinstalldirs .
/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/xgcc
-B/Volumes/hfsplushd/Development/gcc-toolchain/_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87891
--- Comment #11 from Douglas Mencken ---
That’s what I did
sudo ln -s /usr/bin/as /usr/bin/powerpc64-unknown-darwin-as
sudo ln -s /usr/bin/ld /usr/bin/powerpc64-unknown-darwin-ld
sudo ln -s /usr/bin/ar /usr/bin/powerpc64-unknown-darwin-ar
sud
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55273
Bug #: 55273
Summary: [4.8.0 regression] ICE in iv_number_of_iterations, at
loop-iv.c:2819
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55273
--- Comment #1 from Douglas Mencken 2012-11-11
19:58:14 UTC ---
Created attachment 28659
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28659
Original C source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55273
--- Comment #2 from Douglas Mencken 2012-11-11
19:58:43 UTC ---
Created attachment 28660
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28660
Assembly source
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougmencken at gmail dot com
GCC build triplet: powerpc-gnu-linux-uclibc
GCC host triplet: powerpc-gnu-linux-uclibc
GCC target triplet: powerpc-gnu-linux-uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43911
--- Comment #11 from dougmencken at gmail dot com 2010-04-27 17:07 ---
GCC 4.5.0 bootstraps without --disable-checking (Configured with: ./configure
--prefix=/usr --sysconfdir=/etc
--mandir=/usr/share/man --build=powerpc-gnu-linux-uclibc
--host=powerpc-gnu-linux-uclibc --target=powerpc
--- Comment #3 from dougmencken at gmail dot com 2010-04-27 17:18 ---
I do not compile c++ sources with gcc. Yes, I mistyped gcc instead of g++ in
the first message, sorry.
$ g++ test.c\+\+
/usr/lib/gcc/powerpc-gnu-linux-uclibc/4.5.0/../../../libstdc++.so: undefined
reference to
--- Comment #4 from dougmencken at gmail dot com 2010-04-27 17:20 ---
$ g++ -v test.c\+\+
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-gnu-linux-uclibc/4.5.0/lto-wrapper
Target: powerpc-gnu-linux-uclibc
Configured with: ./configure --prefix=/usr
--- Comment #5 from dougmencken at gmail dot com 2010-04-27 17:28 ---
$ find / -name libgcc_s.so
/usr/lib/libgcc_s.so
$ objdump -x /usr/lib/libgcc_s.so
objdump: /usr/lib/libgcc_s.so: File format not recognized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43911
1 - 100 of 167 matches
Mail list logo
