https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799
--- Comment #11 from Michael Hudson-Doyle ---
Er yes, this was fixed before 4.9.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877
--- Comment #10 from Michael Hudson-Doyle ---
I've proposed a fix https://codereview.appspot.com/152840043
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877
--- Comment #6 from Michael Hudson-Doyle ---
Created attachment 33640
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33640&action=edit
my test cases
I think the patch works because when the compiler sees a call to a variadic
function, it g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877
--- Comment #4 from Michael Hudson-Doyle ---
Created attachment 33639
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33639&action=edit
proposed fix
This fix works for me. I can't find any tests of this behaviour -- casting the
result of (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877
--- Comment #3 from Michael Hudson-Doyle ---
The problem is that the call to "m.Call" at
https://gcc.gnu.org/viewcvs/gcc/trunk/libgo/go/reflect/makefunc.go?revision=212853&view=markup#l133
needs, in this case, to be a call to "m.CallSlice". I do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799
--- Comment #7 from Michael Hudson-Doyle ---
There are no additional failures with this patch (and the only additional pass
is libgo's reflect test).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799
--- Comment #6 from Michael Hudson-Doyle ---
Created attachment 31861
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31861&action=edit
Simple fix
This very simple patch (just deleting the offending lines) makes the go test
case that was fail
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.hudson at linaro dot org
It's always possible I'm totally misunderstanding something here, but it seems
that this code:
/* Arrays always
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59744
--- Comment #7 from Michael Hudson-Doyle ---
I saw the problem with Linaro GCC 4.8, but haven't tried the vanilla 4.8
branch. If the committed test case doesn't fail, I'll believe that it is not a
problem. Sorry for the noise.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59744
--- Comment #4 from Michael Hudson-Doyle ---
Hi, thanks for the super fast fix. Could it be backported to 4.8? git
cherry-pick gives a conflict in aarch64.md which is probably easy to fix if you
know how this code works:
(define_insn "*compare_
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.hudson at linaro dot org
Hi,
This slightly strangely written program (it's distilled down from
frame_offset_overflow in the gcc source itself) should print "bigger" if the
first argument is big
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714
--- Comment #4 from Michael Hudson-Doyle ---
OK, so I should stop talking about accurate and instead talk about surprising
:-)
I think it is pretty surprising that x/x != 1+0i for (I think) all x where the
ratio between the real and imaginary par
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714
--- Comment #2 from Michael Hudson-Doyle ---
Oh right. I saw that bug but didn't read enough of the comments to see that
the same thing was mentioned.
I still think fma is inappropriate for this function...
: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.hudson at linaro dot org
Hi, it seems details in the rounding of complex division are wrong:
ubuntu@arm64:~$ cat cplx.c
#include
int main(int argc, char** argv)
{
__complex double c = 1.0 + 3.0i;
printf("
14 matches
Mail list logo
