https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #72 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Nov 25 21:07:43 2014
New Revision: 218062
URL: https://gcc.gnu.org/viewcvs?rev=218062&root=gcc&view=rev
Log:
Add a testcase for PR target/63534
PR target/63534
* gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Francois-Xavier Coudert changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #70 from Francois-Xavier Coudert ---
(In reply to Dominique d'Humieres from comment #69)
Apart from comment #69 (which I am not sure is related to the issue), the rest
of the PR seems now fixed by the various commits here, as well as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #69 from Dominique d'Humieres ---
On top of pr63815, r216154 is also responsible of
FAIL: gcc.target/i386/avx512f-kandnw-1.c scan-assembler-times kandnw[
t]+[^\\n]*%k[1-7] 1
FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #68 from Francois-Xavier Coudert ---
(In reply to Igor Zamyatin from comment #67)
> Posted a patch here - http://gcc.gnu.org/ml/gcc-patches/2014-10/msg03318.html
> Now discussion stop here -
> http://gcc.gnu.org/ml/gcc-patches/2014-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #67 from Igor Zamyatin ---
Posted a patch here - http://gcc.gnu.org/ml/gcc-patches/2014-10/msg03318.html
Now discussion stop here -
http://gcc.gnu.org/ml/gcc-patches/2014-11/msg00320.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #65 from Kirill Yukhin ---
Author: kyukhin
Date: Fri Nov 7 20:42:36 2014
New Revision: 217237
URL: https://gcc.gnu.org/viewcvs?rev=217237&root=gcc&view=rev
Log:
PR target/63534
gcc/
* config/i386/i386.md (builtin_setjmp_rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #64 from howarth at bromo dot med.uc.edu ---
(In reply to Dominique d'Humieres from comment #63)
> Please stop mixing the problems introduced by r216154 and r216305. While I
> agree that the first step is to fix bootstrap, there is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #63 from Dominique d'Humieres ---
> Reading through pr63622 a second time, it appears that these fortran
> regressions were never triaged. I think we should proceed with the
> bootstrap fixes and consider the test suite regression fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #62 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #61)
> (In reply to Dominique d'Humieres from comment #60)
> > > Martin,
> > >Using "make -k check-gfortran
> > > RUNTESTFLAGS="--target_board=unix'{-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #61 from howarth at bromo dot med.uc.edu ---
(In reply to Dominique d'Humieres from comment #60)
> > Martin,
> >Using "make -k check-gfortran
> > RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
> > on the build from Comment 57 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #60 from Dominique d'Humieres ---
> Martin,
>Using "make -k check-gfortran
> RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
> on the build from Comment 57 as a quick regression scan shows...
See pr63622 comment 7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #59 from howarth at bromo dot med.uc.edu ---
(In reply to Martin Liška from comment #58)
> Hello Jack.
>
> I would like to thank you for the effort you invested in testing. I'm going
> to push all IPA ICF related patches to mainline a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #57 from howarth at bromo dot med.uc.edu ---
(In reply to Stupachenko Evgeny from comment #55)
> Created attachment 33915 [details]
> patch disabling nonlocal goto receiver and fixing setjmp receiver
>
> (In reply to howarth from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #56 from Stupachenko Evgeny ---
If this does not help, then described issue is not related to this bug,
as darwin bootstrap passed with the patch applied on r216304 (along with
already committed to trunk patches from PR63618 and PR636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #55 from Stupachenko Evgeny ---
Created attachment 33915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33915&action=edit
patch disabling nonlocal goto receiver and fixing setjmp receiver
(In reply to howarth from comment #54)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
howarth at bromo dot med.uc.edu changed:
What|Removed |Added
CC||howarth at bromo dot med
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #53 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Fri Oct 31 13:30:06 2014
New Revision: 216975
URL: https://gcc.gnu.org/viewcvs?rev=216975&root=gcc&view=rev
Log:
gcc/
PR target/63534
* config/i386/i386.c (ix8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #52 from Jeffrey A. Law ---
Igor, can you post the patch from c#50 for official review? Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #51 from Dominique d'Humieres ---
> > In addition r216154 breaks a lot of asan tests with -m32: see
> >
> > https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html
>
> Could you please try following patch?
>
> diff --git a/gcc/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #50 from Igor Zamyatin ---
> In addition r216154 breaks a lot of asan tests with -m32: see
>
> https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html
Could you please try following patch?
diff --git a/gcc/cfgexpand.c b/gcc/cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #49 from Igor Zamyatin ---
Testing a patch to fix asan failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #48 from Dominique d'Humieres ---
> --- Comment #44 from Iain Sandoe ---
> (In reply to Stupachenko Evgeny from comment #43)
[...]
> there were at one point this week 4 concurrent bootstrap breaks on dariwn.
>
> this PR.
> the ipa-ic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> I'm now testing the rev before Evgeny's patch to check if that
> bootstraps on 10.10. If not, we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #46 from Jeffrey A. Law ---
Glad I'm not the only one struggling to track everything that's breaking on
Darwin!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #44 from Iain Sandoe ---
> (In reply to Stupachenko Evgeny from comment #43)
[...]
> there were at one point this week 4 concurrent bootstrap breaks on dariwn.
>
> this PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #44 from Iain Sandoe ---
(In reply to Stupachenko Evgeny from comment #43)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #42)
> > > --- Comment #41 from Stupachenko Evgeny ---
> > > (In reply to r...@cebitec.uni-bielefeld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #43 from Stupachenko Evgeny ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #42)
> > --- Comment #41 from Stupachenko Evgeny ---
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #40)
> [...]
> > That should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #41 from Stupachenko Evgeny ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #40)
[...]
> That should be not "EBX enablig" issue as pointed in comments 17 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #41 from Stupachenko Evgeny ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #40)
> > --- Comment #39 from Stupachenko Evgeny ---
> > (In reply to Rainer Orth from comment #38)
> [...]
> > You should apply patch from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #39 from Stupachenko Evgeny ---
> (In reply to Rainer Orth from comment #38)
[...]
> You should apply patch from comment 15 as well.
> It is still under review:
> https://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #39 from Stupachenko Evgeny ---
(In reply to Rainer Orth from comment #38)
> What's currently required to get Darwin/x86 to bootstrap again? I'm totally
> lost
> in this maze of PRs and patches.
>
> I've just tried r216667 plus the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #38 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #37 from iverbin at gcc dot gnu.org ---
Author: iverbin
Date: Thu Oct 23 16:52:11 2014
New Revision: 216596
URL: https://gcc.gnu.org/viewcvs?rev=216596&root=gcc&view=rev
Log:
PR target/63534
PR target/63618
gcc/
* cse.c (d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #36 from Stupachenko Evgeny ---
(In reply to Iain Sandoe from comment #35)
> (In reply to Stupachenko Evgeny from comment #33)
> > Created attachment 33769 [details]
> > patch includes 3 patches fixing darwin bootstrap
>
> > Do you h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Iain Sandoe changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comment #35 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #34 from Dominique d'Humieres ---
Bootstrap completed with the patch in comment 33 applied on top of r216304 and
configured with:
../p_work/configure --prefix=/opt/gcc/gcc4.10p-216304p1
--enable-languages=c,c++,lto,fortran,ada,objc,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #33 from Stupachenko Evgeny ---
Created attachment 33769
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33769&action=edit
patch includes 3 patches fixing darwin bootstrap
It looks like data constant LC0 generated from pushtf no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #32 from Stupachenko Evgeny ---
(In reply to Iain Sandoe from comment #30)
> FWIW, I built a stage #1 with fortran, objc and ada enabled.
>
> libgcc, libstdc++v3, libgomp, libobjc and libada build.
>
> libgfortran & libquadmath fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #31 from Stupachenko Evgeny ---
(In reply to Jeffrey A. Law from comment #29)
> I thought we had already dealt with the "hidden" GOT usages that show up
> during reload... Is it IRA that's removing the SET_GOT?
That is not EQUIV rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #30 from Iain Sandoe ---
FWIW, I built a stage #1 with fortran, objc and ada enabled.
libgcc, libstdc++v3, libgomp, libobjc and libada build.
libgfortran & libquadmath fail (errors as per Dominique's post).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #29 from Jeffrey A. Law ---
I thought we had already dealt with the "hidden" GOT usages that show up during
reload... Is it IRA that's removing the SET_GOT?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #28 from Dominique d'Humieres ---
With the patches in comments 15 and 27 applied on top of r216304, bootstrap
stil fails with
libtool: compile: /opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/
-B/opt/gcc/gcc4.10p-216304p1/x86_6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #27 from Stupachenko Evgeny ---
Created attachment 33748
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33748&action=edit
Fix SET_GOT delete
The patch fix the problem.
Can you please run darwin bootstrap with it and previous (r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #26 from Iain Sandoe ---
(In reply to Stupachenko Evgeny from comment #24)
> We are able to reproduce the bug.
> SET_GOT removed as the only use of GOT register was hidden by:
> (insn 37 34 38 6 (set (mem:TF (pre_dec:SI (reg/f:SI 7 sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #25 from Iain Sandoe ---
Created attachment 33746
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33746&action=edit
RTL dumps
This is trunk rev 216304 + change to i386.md.
-O2 -m32.
For O0/1 the output is created OK.
For O2 the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #24 from Stupachenko Evgeny ---
We are able to reproduce the bug.
SET_GOT removed as the only use of GOT register was hidden by:
(insn 37 34 38 6 (set (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0 S16 A8])
(const_double:TF 2.07691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #23 from Iain Sandoe ---
Created attachment 33741
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33741&action=edit
asm and .i
I built 216304+removing the two sections in i386.md.
A stage 1 compiler built with -O0 -g is suffien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #22 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #17)
> (In reply to Dominique d'Humieres from comment #16)
> > > Created attachment 33733 [details]
> > > patch to fix darwin bootstrap
> > >
> > > With pseudo GOT registe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #21 from Igor Zamyatin ---
(In reply to Iain Sandoe from comment #20)
>
> libtool: compile: /GCC/ml/gcc-trunk-appleas/./gcc/xgcc
> -B/GCC/ml/gcc-trunk-appleas/./gcc/
> -B/compilers/gcc-trunk/x86_64-apple-darwin12/bin/
> -B/compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #20 from Iain Sandoe ---
so I rewound to r216156 and made the change to i386.md (removed the receiver
and nonlocal label stuff).
So, that succeeds in getting to stage #3 and then fails building [m32] target
libs which is much more li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #19 from Dominique d'Humieres ---
> Can you please try more conservative patch disabling just
> nonlocal_goto_receiver split bootstrapping it from scratch?
It still get the same error/warnings as in comment 16 with the conservative
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #18 from Stupachenko Evgeny ---
Created attachment 33736
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=edit
patch disabling just nonlocal_goto_receiver split
Am I correct that this is 64 bits library link failed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #17 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #16 from Dominique d'Humieres ---
> Created attachment 33733 [details]
> patch to fix darwin bootstrap
>
> With pseudo GOT register we don't need to set GOT register after any jump,
> and therefore don't need "nonlocal_goto_receiver"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #15 from Stupachenko Evgeny ---
Created attachment 33733
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33733&action=edit
patch to fix darwin bootstrap
With pseudo GOT register we don't need to set GOT register after any jump,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Igor Zamyatin changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #13 from Dominique d'Humieres ---
Created attachment 33728
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33728&action=edit
Compressed tar of the files produced with -fdump-rtl-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #12 from Stupachenko Evgeny ---
(In reply to Dominique d'Humieres from comment #9)
> r216154 broke bootstrap on x86_64-apple-darwin13 too while building
> libstdc++-v3:
>
> libtool: compile: /opt/gcc/p_build/./gcc/xgcc -shared-libgc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #11 from Vladimir Makarov ---
(In reply to Stupachenko Evgeny from comment #10)
>
> Sounds reasonable. I also don't like 2 set_got one-by-one. However, we
> should ask Vladimir on how we can force RA allocate pseudo GOT on %ebx. I
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #10 from Stupachenko Evgeny ---
(In reply to Jakub Jelinek from comment #8)
> For -pg, at least for 32-bit -fpic, one way to handle this would be
> for !targetm.profile_before_prologue () && crtl->profile in ix86_init_pic_reg
> instea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #9 from Dominique d'Humieres ---
r216154 broke bootstrap on x86_64-apple-darwin13 too while building
libstdc++-v3:
libtool: compile: /opt/gcc/p_build/./gcc/xgcc -shared-libgcc
-B/opt/gcc/p_build/./gcc -nostdinc++
-L/opt/gcc/p_build/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #8 from Jakub Jelinek ---
For -pg, at least for 32-bit -fpic, one way to handle this would be
for !targetm.profile_before_prologue () && crtl->profile in ix86_init_pic_reg
instead of emitting set_got into the pic_offset_table_rtx emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #6 from iverbin at gcc dot gnu.org ---
Author: iverbin
Date: Tue Oct 14 16:26:57 2014
New Revision: 216208
URL: https://gcc.gnu.org/viewcvs?rev=216208&root=gcc&view=rev
Log:
PR target/63534
gcc/
* config/i386/i386.c (ix86_expa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #5 from Jakub Jelinek ---
Double set_got doesn't make sense, if you want to keep the current model, I'd
emit a set_got insn forced into %ebx before the mcount call in the prologue and
see if early after the prologue isn't a set_got in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #4 from Stupachenko Evgeny ---
Profiling implementation has hard coded "%ebx" use.
There are at least 2 quick solutions to resolve this:
1. Disable the changes for PIC profiling
Lead to different behavior with and without profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #3 from Jakub Jelinek ---
For -fsplit-stack you are right, __morestack seems to have hidden visibility,
so even if gcc emits call __morestack@plt, the linker should transform that
into
a direct call __morestack which doesn't need %ebx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Stupachenko Evgeny changed:
What|Removed |Added
CC||evstupac at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Status
72 matches
Mail list logo
