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
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 #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 #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 #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
Douglas Mencken changed:
What|Removed |Added
Component|c |bootstrap
--- Comment #6 from Douglas
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
--- 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 #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 #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
: 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=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
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
Douglas Mencken changed:
What|Removed |Added
Attachment #44902|0 |1
is obsolete|
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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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 #1 from Douglas Mencken ---
May this https://patchwork.ozlabs.org/patch/838856/ is related?
: 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=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=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 #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 #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 #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 #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=80865
Douglas Mencken changed:
What|Removed |Added
CC||dougmencken at gmail dot com
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=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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
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
--- 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
--- Comment #1 from Douglas Mencken ---
ah yep, it’s at first stage
$ cat stage_current
stage1
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=61759
--- Comment #6 from Douglas Mencken ---
Looks like I found the root of the issue ~
GCC ICEs when it meets C++ exception handling (try+catch)
$ cat main.mm
#include
#include
int main (void)
{
try {
throw 0;
} ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #29 from Douglas Mencken ---
Vanilla GCC 5.2 bootstraps perfectly (without --disable-checking) on my side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57607
--- Comment #3 from Douglas Mencken ---
(In reply to Jonathan Wakely from comment #2)
> Seems to be fixed in GCC 5 though:
Yep, 5.2 works:
$ g++-5.2 -std=gnu++11 -framework CoreFoundation -lobjc test.mm && ./a.out
Hello world!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57607
Douglas Mencken changed:
What|Removed |Added
CC||dougmencken at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #22 from Douglas Mencken ---
Created attachment 35619
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35619&action=edit
pre-processed source of genmatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #20 from Douglas Mencken ---
I'm lost. “Vanilla” 5.1.0 configured without --disable-checking went thru
stage2 w/o any issue...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #18 from Douglas Mencken ---
> try without --disable-checking
Okay, doing it now.
Meanwhile. Why ``sizeof (hashval_t) * CHAR_BIT'' cannot be checked at configure
time, not at buildtime nor runtime?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #15 from Douglas Mencken ---
I'm going to surround calls to gcc_[checking_]assert (in gcc/hash-table.*) with
#ifdef ENABLE_CHECKING {--disable-checking is in my config already}. Let's see
where it lands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #14 from Douglas Mencken ---
sizeof(hashval_t) = 4, CHAR_BIT = 8
Just checked it manually. Built with patch subset, genmatch problem is here
again. It isn't related to changes in hash_table_mod1 & hash_table_mod2.
What's left? abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #11 from Douglas Mencken ---
Causing commit found.
It is r218976 (e2afa5c10fd41fe708959121f373fcb5435ef5d6). With reverse-applied
r218976's patch, 5.1.0 even reaches "Bootstrap comparison failure!‘‘ ;)
Maybe patch's author [ Author
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #10 from Douglas Mencken ---
No, ``ld warning: atom sorting error'' has nothing to do with this issue.
For example, commit 2e723940b6a1e61dfb20e03b30fba89dd204b72d (2014-12-19),
genmatch@stage2 works fine while building:
(...)
/Deve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #9 from Douglas Mencken ---
I decided to use git bisect to figure out.
Working genmatch@stage2:
commit 852fa94e29ebd44814054f4657b7385788b0321b (2014-12-16)
$ prev-gcc/build/genmatch --gimple ../gcc-git/gcc/match.pd >../o1
$ gcc/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #8 from Douglas Mencken ---
Created attachment 35546
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35546&action=edit
linker output for genmatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #7 from Douglas Mencken ---
$ ls -l /usr/bin/ld
-rwxr-xr-x 1 root wheel 2622416 Jul 12 2008 /usr/bin/ld
$ /usr/bin/ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1
LLVM version 3.5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #5 from Douglas Mencken ---
(In reply to rguent...@suse.de from comment #4)
> Can you build stage2 with debuginfo? (--without-build-config at
> configure)
>
> That should imrpove the backtrace.
>
> Thanks,
> Richard.
Sure I can.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #3 from Douglas Mencken ---
(In reply to Richard Biener from comment #2)
> I think you may run into a host compiler issue? (ISTR a similar bug for
> darwin)
>
> What is your host compiler? I suppose ppc-darwin still uses gcc 4.2.x,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #1 from Douglas Mencken ---
$ prev-gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=prev-gcc/xgcc
Target: powerpc-unknown-darwin
Configured with: ../gcc-5.1.0/configure --build=powerpc-unknown-darwin
--host=powerpc-unknown-darwin --targe
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dougmencken at gmail dot com
Target Milestone: ---
Created attachment 35481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35481&action=edit
remake log
I want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61763
--- Comment #9 from Douglas Mencken ---
>How do you actually compile with -O3?
../../flags_O2_to_O3.sh
sed -i '/ CFLAGS_FOR_TARGET=/{n;N;N;N;N;N;N;N;d}' ./configure.ac
sed -i '/ CXXFLAGS_FOR_TARGET=/{n;N;N;N;N;N;N;N;d}' ./configure.ac
sed -i 's/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703
--- Comment #3 from Douglas Mencken ---
Same error when configuring 4.9.2 exactly as host compiler:
../gcc-4.9.2/configure \
--build=powerpc-unknown-darwin --host=powerpc-unknown-darwin
--target=powerpc-unknown-darwin \
--prefix=/usr --sysconfdi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703
--- Comment #2 from Douglas Mencken ---
stage0 ("host") compiler:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-unknown-darwin/4.9.1/lto-wrapper
Target: powerpc-unknown-darwin
Configured with: ../gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703
--- Comment #1 from Douglas Mencken ---
$ gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: powerpc-unknown-darwin
Configured with: ../gcc-4.9.2/configure --build=powerpc-unknown-darwin
--host=powerpc-unknown-darwin --target=powerpc-
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dougmencken at gmail dot com
At stage1 of bootstrapping 4.9.2, I got libgcc configure error (from
powerpc-unknown-darwin/libgcc/config.log):
configure:3389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759
--- Comment #5 from Douglas Mencken ---
Now I know it's question about non-well-supported NeXT Objective C ABIs.
Will try -fgnu-runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759
--- Comment #4 from Douglas Mencken ---
In 4.9.1, it's not :2792 but :2793 ---
vcl/osx/a11yselectionwrapper.cxx:31:61: internal compiler error: in
objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.c:2793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61763
--- Comment #5 from Douglas Mencken ---
Re-tried without forcing -O3, and with default -O2 4.9.1 doesn't complain on
stages 2&3 comparison.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61763
--- Comment #4 from Douglas Mencken ---
(In reply to Jakub Jelinek from comment #3)
> GCC 4.9.1 has been released.
With 4.9.1 release I got:
...
rm -f stage_current
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61763
--- Comment #2 from Douglas Mencken ---
(In reply to Richard Biener from comment #1)
> Can you check a recent 4.9.1 snapshot?
Just did it. gcc-4.9-20140709 snapshot.
...
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/
ty: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dougmencken at gmail dot com
I tried to bootstrap gcc-4.9.0 release on OS X 10.5 (darwin9).
My host compiler is currently gcc-4.8.3.
That's what I've got:
make &quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759
--- Comment #3 from Douglas Mencken ---
Created attachment 33095
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33095&action=edit
preprocessed builder.cxx
Attaching preprocessed builder.cxx (builder.mii)
1 - 100 of 167 matches
Mail list logo
