Issue Details (XML | Word | Printable)

Key: PCC-433
Type: New Feature New Feature
Status: In Progress In Progress
Priority: Major Major
Assignee: Anders Magnusson
Reporter: Iain Hibbert
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
pcc

recent commit causes a difference in output depending on compiler

Created: 27/May/14 12:33 PM   Updated: 28/May/14 06:29 PM
Component/s: C frontend, i386 target
Affects Version/s: None
Fix Version/s: None

File Attachments: 1. File builtins.i (49 kB)
2. File ccom.init (850 kB)
3. File ccom.pcc1 (339 kB)

Environment: NetBSD/i386


 Description  « Hide
following from a previous email.. a recent commit (to fix the final part of PCC-432) caused a difficult to pin down issue, which is that the output of ccom depends on the compiler used to build it.

if I build ccom with gcc4.8 then it produces one output

if I build ccom with pcc (the one that gcc4.8 built, above) then it produces a different output, which should not happen.

I have pinned down the build difference but not what causes it. The files attached are

1. ccom.init .. this is the ccom which was built with gcc4.8

2. ccom.pcc1 .. this is the ccom which was built using file #1 above

3. builtins.i .. this is the PCC builtins.c file, which has been preprocessed to remove environmental considerations and had as much unrelated code removed that I could find.

so, the following commands show the difference in the output for the builtin_check() function

% ccom.init -xtemps -xinline builtins.i builtins.init
% ccom.pcc1 -xtemps -xinline builtins.i builtins.pcc1
% diff -u builtins.init builtins.pcc1
@@ -11,6 +11,7 @@
        pushl $0
        movl (%eax),%eax
        call *%eax
+ addl $4, %esp
 .L435:
        leave
        ret

note that editing the builtins.i file further to remove anything (even a line marker) seems to make this difference disappear.

I am not sure that this particular difference is significant in the general scheme of things (this is taken care of by the "leave", right?) but I think it is worrying that it occurs

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Iain Hibbert added a comment - 27/May/14 07:26 PM
ragge suggests that this patch

--- local2.c 27 May 2014 15:48:57 -0000 1.174
+++ local2.c 27 May 2014 17:25:10 -0000
@@ -450,8 +450,10 @@ zzzcode(NODE *p, int c)
                break;
 
        case 'C': /* remove from stack after subroutine call */
+#ifdef notyet
                if (p->n_left->n_flags & FSTDCALL)
                        break;
+#endif
                pr = p->n_qual;
                if (p->n_flags & FFPPOP)
                        printf(" fstp %%st(0)\n");

would fix it, though it breaks stdcall in the meantime.. I can confirm that the difference goes away with this patch