https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #29 from Dominik Vogt ---
Thanks!
> It's necessary to handle all cases correctly. But there is nothing wrong
> with using an efficient mechanism when it works, as long as we can correctly
> fall back to a more expensive mechanism wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #27 from ian at gcc dot gnu.org ---
Author: ian
Date: Wed Oct 8 14:03:13 2014
New Revision: 216003
URL: https://gcc.gnu.org/viewcvs?rev=216003&root=gcc&view=rev
Log:
PR go/60406
runtime: Check callers in can_recover if return ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #26 from Ian Lance Taylor ---
(In reply to Dominik Vogt from comment #23)
>
> 1) We need to call __builtin_extract_return_address(retaddr) in
> __go_set_defer_retaddr() too. (On s390 (31 bit) this is necessary to remove
> the most s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #25 from Ian Lance Taylor ---
(In reply to Dominik Vogt from comment #22)
> >> Hm, so the patch penalises platforms that cannot deal with the
> >> 16 byte window?
>
> > Yes, but, recall that on your system almost all tests pass using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #24 from Dominik Vogt ---
> --snip--
> -g->defer->__retaddr = retaddr;
> +g->defer->__retaddr = __builtin_extract_return_addr (retaddr);
> --snip--
We need to double check whether this would break Sparc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #23 from Dominik Vogt ---
Regarding the new patch:
1) We need to call __builtin_extract_return_address(retaddr) in
__go_set_defer_retaddr() too. (On s390 (31 bit) this is necessary to remove
the most significant bit of the address w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #22 from Dominik Vogt ---
>> Hm, so the patch penalises platforms that cannot deal with the
>> 16 byte window?
> Yes, but, recall that on your system almost all tests pass using the
> code that is in the tree today, before your patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #21 from Uroš Bizjak ---
(In reply to boger from comment #20)
> The latest patch worked on ppc64 for LE & BE. That is, the testcase
> recover.go now works and no new regressions were introduced.
Also works on alpha [1] without new r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #20 from boger at us dot ibm.com ---
The latest patch worked on ppc64 for LE & BE. That is, the testcase recover.go
now works and no new regressions were introduced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
Ian Lance Taylor changed:
What|Removed |Added
Attachment #33644|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #18 from Ian Lance Taylor ---
> Well, maybe it was only a problem with tail recursion,
Note that because Go programs expect predictable results from runtime.Callers
and other stack backtracing functions, the Go frontend disables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #17 from Dominik Vogt ---
>> * Wouldn't the new patch re-introduce the bug that
>>
>> func foo(n int) {
>> if (n == 0) { recover(); } else { foo(0); }
>> }
>> func main() {
>> defer foo(1)
>> panic("...")
>> }
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #16 from Ian Lance Taylor ---
>> I'm not really happy with Dominik's patch because 1) it doesn't work when
>> configuring with --enable-sjlj-exceptions;
>
> Why is that important?
It's not very important but it's still a point to con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #15 from boger at us dot ibm.com ---
The testcase recover.go continues to fail on both ppc64 LE & BE with the new
patch https://codereview.appspot.com/153950043.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #14 from Dominik Vogt ---
> I'm not really happy with Dominik's patch because 1) it doesn't work when
> configuring with --enable-sjlj-exceptions;
Why is that important?
> 2) the current code almost always works, even on S/390, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #13 from Uroš Bizjak ---
(In reply to Ian Lance Taylor from comment #12)
> Can people on systems for which the recover.go test currently fails please
> try this patch and let me know whether it fixes the problem? Thanks.
Unfortunat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #12 from Ian Lance Taylor ---
Created attachment 33644
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33644&action=edit
possible patch
I'm not really happy with Dominik's patch because 1) it doesn't work when
configuring with -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #11 from boger at us dot ibm.com ---
On ppc64 BE, the call to make_code_func_reference returns the function pointer
in the .opd and not the actual address of the function. That is what causes
the failures with this patch
https://gcc.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #10 from Peter Bergner ---
(In reply to boger from comment #9)
> On ppc64le, this works as expected but on ppc64(be) the code that is
> generated from this is not the address of the function but the address of
> the .opd entry that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #9 from boger at us dot ibm.com ---
The patch to fix the recover.go problem causes significant regression in gccgo
when built for ppc64 (BE). There are 32 unexpected failures in the gcc go
testsuite with the patch 32 unexpected failur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #8 from boger at us dot ibm.com ---
Update on my previous work:
1) My previous update referred to a build that was done with the patches that
were submitted to gcc and patches that Dominik provided me for libffi. I found
that if I on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #7 from boger at us dot ibm.com ---
I've built with Dominik's patches against trunk on ppc64le and have been trying
to run the gcc testsuite for go and libgo.
The recover.go testcase continues to fail in my build. I did some debuggin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #6 from Dominik Vogt ---
I'll submit a fix for this problem as soon as I figure out what to do with the
patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
Ian Lance Taylor changed:
What|Removed |Added
CC||boger at us dot ibm.com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #4 from Uroš Bizjak ---
Alternatively, since __go_set_defer_retaddr always returns 0, we can prevent
split of the label by enclosing it in asm volatiles:
extern int foo (void *);
extern void bar (void);
int test_1 (void)
{
__label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #3 from Uroš Bizjak ---
It looks that a hack, mentioned in Comment #0 should use asm goto instead of
goto. The following test:
--cut here--
extern void foo (void *);
int test_bad (int p1, int p2)
{
__label__ bla1;
foo (&&bla1);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
Uroš Bizjak changed:
What|Removed |Added
Summary|reflect.go:test13reflect2 |recover.go: test13reflect2
28 matches
Mail list logo
