https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #71 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #70)
>
> powerpc64 darwin is *much* less tested than the 32b variant.
>
> I don't have any access to my ppc64 machine for the next week but... it
> looks like our gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #70 from Iain Sandoe ---
(In reply to Douglas Mencken from comment #69)
> (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
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
>
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 #67 from Iain Sandoe ---
Author: iains
Date: Sun Oct 28 10:02:06 2018
New Revision: 265569
URL: https://gcc.gnu.org/viewcvs?rev=265569=gcc=rev
Log:
darwin - fix powerpc-darwin stack alignment issue
2018-10-28 Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #66 from Iain Sandoe ---
Author: iains
Date: Sun Oct 28 09:25:43 2018
New Revision: 265568
URL: https://gcc.gnu.org/viewcvs?rev=265568=gcc=rev
Log:
darwin - fix powerpc-darwin stack alignments
2018-10-28 Iain Sandoe
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #65 from Segher Boessenkool ---
Iain: This is fine for trunk and all open branches you want it on. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #64 from Iain Sandoe
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Iain Sandoe changed:
What|Removed |Added
Attachment #44901|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #60 from Iain Sandoe ---
(In reply to Douglas Mencken from comment #59)
> (In reply to Segher Boessenkool from comment #58)
>
> > This patch
> > (https://gcc.gnu.org/ml/gcc-testresults/2017-01/txtNTsImfm9sQ.txt) is okay
> > for
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #58 from Segher Boessenkool ---
(In reply to Iain Sandoe from comment #53)
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #57 from Segher Boessenkool ---
The blrl thing ("skip a return") doesn't kill the return stack; all CPUs
with a return stack can recover it here afaik. Recovery of course takes
a little time still. Newer CPUs predict BL+4 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #56 from Wilco ---
(In reply to Douglas Mencken from comment #55)
> (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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #53 from Iain Sandoe ---
(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 #52 from Wilco ---
(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 solved for other targets before; a patch for Darwin is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #51 from Wilco ---
(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 to do tricks
> > like that
>
> No, we don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #50 from Segher Boessenkool ---
The generic code rounded up the allocation size twice, and that isn't needed.
The problem has been solved for other targets before; a patch for Darwin is
at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #49 from Segher Boessenkool ---
(In reply to Douglas Mencken from comment #46)
> Yeah, PowerPC doesn’t have addressing via PC, thus it requires to do tricks
> like that
No, we don't have to do such strange code. The usual way is to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #48 from Wilco ---
(In reply to Douglas Mencken from comment #44)
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #47 from Wilco ---
(In reply to Douglas Mencken from comment #45)
> (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
>
>
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #43 from Wilco ---
(In reply to Douglas Mencken from comment #42)
> (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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #41 from Wilco ---
(In reply to Douglas Mencken from comment #40)
> To build it, I patched its sources with fix_gcc8_build.patch reversion
> together with changes from comment #16
So what is the disassembly now? The 2nd diff still
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #38 from Wilco ---
(In reply to Douglas Mencken from comment #37)
> And some more in my wish list. May GCC don’t generate these
>
> .align2
>
> in text section? Any, each and every powerpc instruction is 32bit-wide, no
>
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
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
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=edit
8.2vanilla-pr78468.s
And there’s assembly produced by *vanilla* (id est with Wilco’s r251713 causing
the fail in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #33 from Wilco ---
(In reply to Iain Sandoe from comment #30)
> From "Mac_OS_X_ABI_Function_Calls.pdf"
>
> m32 calling convention
>
> Prologs and Epilogs
> The called function is responsible for allocating its own stack frame,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #32 from Wilco ---
(In reply to Segher Boessenkool from comment #29)
> It aligns the stack to 16:
>
> # r3 is size, at entry
> addi r3,r3,18
> ...
> rlwinm r3,r3,0,0,27
> ...
> neg r3,r3
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #31 from Iain Sandoe ---
(In reply to Douglas Mencken from comment #4)
> (In reply to Richard Biener from comment #3)
> > How did you configure?
>
> As always
>
> ../gcc-8.1.0/configure \
> --build=powerpc-unknown-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #30 from Iain Sandoe ---
(In reply to Segher Boessenkool from comment #27)
> The stack is always 16B-aligned on Darwin as far as I know. Cc:ing Iain, he
> will know for sure (I cannot find the docs, &^%*&^$#*&%)
I actually thought
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #29 from Segher Boessenkool ---
It aligns the stack to 16:
# r3 is size, at entry
addi r3,r3,18
...
rlwinm r3,r3,0,0,27
...
neg r3,r3
...
lwz r2,0(r1)
...
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=edit
8.2patched-pr78468.s
Assembly produced by patched 8.2’s stage1 xgcc compiled using
prev-gcc/xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Segher Boessenkool changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #26 from Wilco ---
(In reply to Douglas Mencken from comment #25)
> (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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #24 from Wilco ---
(In reply to Douglas Mencken from comment #22)
> (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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #21 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #20 from Segher Boessenkool ---
This is
#define SUPPORTS_STACK_ALIGNMENT (MAX_STACK_ALIGNMENT > STACK_BOUNDARY)
and
#define MAX_STACK_ALIGNMENT STACK_BOUNDARY
so that seems normal.
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
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 #17 from Wilco ---
(In reply to Douglas Mencken from comment #16)
> Like this?
>
> --- a/gcc/config/rs6000/darwin.h
> +++ b/gcc/config/rs6000/darwin.h
> @@ -150,13 +150,12 @@
>
> #undef RS6000_STARTING_FRAME_OFFSET
> #define
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 #15 from Wilco ---
> This will correctly align the outgoing arguments to fails to align the
> outgoing arguments. The STACK_DYNAMIC_OFFSET definitions in rs6000.h and
> aix.h are correct.
Note RS6000_STARTING_FRAME_OFFSET also needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #14 from Wilco ---
Since DEFAULT_ABI == ABI_DARWIN, the save area is 24 bytes:
#define RS6000_SAVE_AREA \
((DEFAULT_ABI == ABI_V4 ? 8 : DEFAULT_ABI == ABI_ELFv2 ? 16 : 24) \
<< (TARGET_64BIT ? 1 : 0))
STACK_BOUNDARY is 128
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #10 from Segher Boessenkool ---
Thanks Douglas, no that is fine of course :-) What I wanted to know is, does
it fail for the newest versions as well. So it appears it does. Which Ryan
already said but I have trouble reading
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #8 from Segher Boessenkool ---
Is this on all (PowerPC) Darwin? Only one some versions? Which, then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Ryan Schmidt changed:
What|Removed |Added
CC||gcc at ryandesign dot com
--- Comment #6
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
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 \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
Richard Biener changed:
What|Removed |Added
Keywords||build
Component|regression
69 matches
Mail list logo
