gmane.comp.compilers.pcc

amd64: Add more xasm constraint registers

Felix Janda — 2013-05-05T07:27:52

Hello,

so far pcc implemented only some of the r** xasm registers in the amd64
architecture. (I wonder why.) The attached patch adds all missing from
macdefs.h.

They are for example used in musl's syscall interface.

-Felix

Re: pcc broken on x86_64 linux (was Re: pcc 1.1 alpha release any time soon?)

Anders Magnusson — 2013-04-18T18:44:27

Yep, but I do not have even remotely any time to get deeper into it for 
a while.

Re: SuSE RPM for pcc nightlies?

Guido Berhoerster — 2013-04-18T17:57:59

* Irek Szczesniak <iszczesniak< at >gmail.com> [2013-04-18 19:38]:

No, but if you really want it you could easily branch
devel:tools:compiler/pcc on OBS and update it to a current
snapshot, it shouldn't involve much more than swapping out the
tarballs and updating the version number.
Depending on how far the next release is away I might update it
to a snapshot some time, but it needs to be at least in a
working condition which it currently is not, as pointed out in
the other thread.

Re: pcc 1.1 alpha release any time soon?

Irek Szczesniak — 2013-04-18T17:32:26

On Mon, Apr 8, 2013 at 7:51 PM, Susi Lehtola
<jussilehtola< at >fedoraproject.org> wrote:

Thank you for your help!

Irek

Re: pcc broken on x86_64 linux (was Re: pcc 1.1 alpha release any time soon?)

Irek Szczesniak — 2013-04-18T17:33:46

On Thu, Apr 11, 2013 at 3:18 PM, Susi Lehtola
<jussilehtola< at >fedoraproject.org> wrote:

Anders, have you looked at Susi's feedback?

Irek

SuSE RPM for pcc nightlies?

Irek Szczesniak — 2013-04-18T17:31:55

Is there a SuSE RPM for pcc nightlies?

Irek

pcc broken on x86_64 linux (was Re: pcc 1.1 alpha release any time soon?)

Susi Lehtola — 2013-04-11T13:18:20

Quoting Susi Lehtola <jussilehtola< at >fedoraproject.org>:

I have now done the bisection, and here are its results. The procedure
is:
1. download pcc and pcc-libs tarballs of the chosen date
2. compile pcc and pcc-libs with gcc
3. recompile pcc and pcc-libs with pcc (compiled with gcc)
4. recompile pcc and pcc-libs with pcc (compiled with pcc)

Results:

20120210 works
20120710 works

20120711 major internal compiler error, cc.c line 1422
20120713 major internal compiler error
20120717 major internal compiler error
20120725 major internal compiler error
20120801 major internal compiler error
20120804 major internal compiler error

20120806 ar: softfloat.o: No such file or directory

20120807 configure: error: cannot run C compiled programs.
20120808 fail
20120810 fail

20120910 fail,
pcc -I. -DTARGET_LITTLE_ENDIAN=1 -Dos_linux -isystem ../libpcc/include  
-Iamd64 -Ilinux -I. -g -c cmpdi2.c
quad.h, line 134: redeclaration of __ashldi3
quad.h, line 135: redeclaration of __ashrdi3
quad.h, line 147: redeclaration of __lshrdi3
/usr/libexec/ccom terminated with status 1

20120110 fail
20121216 fail


So it would seem that the problem was introduced either in the
rework between 20120710 and 20120711, or in the fix of the resulting
compiler error.

When the compiler starts to work again in 20120807, configure fails
because the binaries produced by pcc (compiled with gcc) give out a
wrong error code - return 0 ends up returning something like 96...
--
Susi Lehtola
Fedora Project Contributor
jussilehtola< at >fedoraproject.org

Re: How to change subscription address?

Anders Magnusson — 2013-04-11T11:32:56


Up now.

Either do as it is written there or mail me.

Re: pcc web server down

Anders Magnusson — 2013-04-11T11:31:46

...and now at last I have managed to get down and restarted the machine...

Have fun!

Re: pcc 1.1 alpha release any time soon?

Susi Lehtola — 2013-04-08T17:51:43

On Mon, 8 Apr 2013 19:39:21 +0200
Irek Szczesniak <iszczesniak< at >gmail.com> wrote:

I can't compile pcc with pcc itself since pcc compiled with gcc.

I'll try bisecting as soon as the www server gets back up.

Re: pcc 1.1 alpha release any time soon?

Irek Szczesniak — 2013-04-08T17:39:21

On Mon, Apr 8, 2013 at 7:00 PM, Susi Lehtola
<jussilehtola< at >fedoraproject.org> wrote:

Does this happen for pcc binaries compiled with pcc itself? Does gcc
report any suspicious warnings? Does valgrind report anything? Can you
bisect the source repository commits to narrow down the commit which
caused the break?

Irek

Re: pcc 1.1 alpha release any time soon?

Susi Lehtola — 2013-04-08T17:00:24

On Mon, 8 Apr 2013 16:59:40 +0200
Irek Szczesniak <iszczesniak< at >gmail.com> wrote:


First of all, pcc in Fedora is from November 2011.

Secondly, before a pcc 1.1 release I would like to get pcc working on
linux once again. As I reported in December, for some reason binaries
compiled with current versions of gcc don't return the right value -
return 0 ends up returning 96.

Re: pcc 1.1 alpha release any time soon?

Irek Szczesniak — 2013-04-08T14:59:40

On Mon, Apr 8, 2013 at 3:24 PM, ольга крыжановская
<olga.kryzhanovska< at >gmail.com> wrote:

+1 on the alpha idea

Also a big -100000 on the current pcc1.0 in Suse and Fedora. Both is
IMO a pain. I think everyone here will agree with that in 2013 (pcc
1.0 was great in April 2011 but time moved on).

Irek

Re: pcc web server down

ольга крыжановская — 2013-04-08T13:22:31

Anders, thank you!

Olga

On Mon, Apr 8, 2013 at 3:21 PM, Anders Magnusson <ragge< at >ludd.ltu.se> wrote:

Re: pcc web server down

Anders Magnusson — 2013-04-08T13:21:08

The machine is unresponsive.  I'll try to fix it later today.

pcc web server down

ольга крыжановская — 2013-04-08T13:01:22

The pcc web server seems to be down, again. Can any one resurrect it, please?

Olga

pcc 1.1 alpha release any time soon?

ольга крыжановская — 2013-04-08T13:24:06

I have a request: given the huge process pcc has made, since the 1.0
release, can you release an *alpha* release of pcc 1.1, so the Linux
distributions pick that up, please? OpenSUSE12.3 still ships with
pcc1.0, which is a pain.

Olga

Re: Type lost while reducing [Was: ICE: how to debug?]

Iain Hibbert — 2013-03-01T18:49:32


btw this ICE also happens on i386, so I guess it is there too..

iain

Re: Type lost while reducing [Was: ICE: how to debug?]

Anders Magnusson — 2013-03-01T17:28:44

Hi,

nice digging into pcc :-)  Comments below:

On 03/01/2013 04:56 PM, Antoine Leca wrote:
Well, zapleft did zap the left node back in time.  It still do the same 
thing
but no need to supply it with the left node; now it zaps the current 
node :-)

Anyway, your findings are correct, but there is more to be aware of:
optim is always called with a type-correct tree, therefore adding a
cast this late shall not be needed.  The problem occurs earlier, since
all casts are inserted when the tree is parsed.

A quick search shows that the bug is in amd64/local.c in the statement
around line 379, where an SCONV is removed even if it should not be :-)

You may note that bugs almost always are in the target-specific code,
the machine-independent code seems to be quite good quality now.

Type lost while reducing [Was: ICE: how to debug?]

Antoine Leca — 2013-03-01T15:56:53

<snip>

So I went down digging a bit more, comparing with a slightly similar
case (>>1) which compiles OK. I found that -Xe are identical, while at
-Ze there is a difference, with >>1 the left part of the % node receive
a >> operation with type "int", while with >>0 it receives a U*
operation with type "unsigned": clearly, the reduction from >> to U*
lose the (int) type cast.

So I searched a bit into the code, and determined it happens in optim.c
I first found that function zapleft() is pretty misnamed, since it
really zap the node and its right subnode, and keep the left one ;-)
Fortunately there is a label named 'zapright:' around lines 325, which
does pretty much the same operations (zapping the node and its right),
just it _also_ calls makety() to pass the type information from the
to-be-deleted node, to the to-be-kept, formerly left (and is followed by
a call to clocal() to align locals); the effect of such code in cases
like this one is to transform the deleted operation into a cast, if
there is a type change: right the case at hand!

So I changed the calls to the function into goto's to the more complete
code, and my bug went away :-) However I am not completely sure this
does not introduce other bugs down the line.
I also added comments in the places where I believe there could be
similar pitfalls (and I renamed the function.)


Antoine
diff --git a/cc/ccom/optim.c b/cc/ccom/optim.c
index 1f852e9..c35d2a9 100644
--- a/cc/ccom/optim.c
+++ b/cc/ccom/optim.c
< at >< at > -43,14 +43,15 < at >< at >
 # define LO(p) p->n_left->n_op
 # define LV(p) p->n_left->n_lval
 
-/* remove left node */
+/* remove right node */
 static NODE *
-zapleft(NODE *p)
+zapright(NODE *p)
 {
 NODE *q;
 
 q = p->n_left;
 nfree(p->n_right);
+/* XXX CHECKME: type information of node *p is lost here... */
 nfree(p);
 return q;
 }
< at >< at > -167,14 +168,14 < at >< at > again:o = p->n_op;
     (RV(p) + RV(p->n_left)) < sz) {
 /* two right-shift  by constants */
 RV(p) += RV(p->n_left);
-p->n_left = zapleft(p->n_left);
+p->n_left = zapright(p->n_left);
 }
 #if 0
   else if (LO(p) == LS && RCON(p->n_left) && RCON(p)) {
 RV(p) -= RV(p->n_left);
 if (RV(p) < 0)
 o = p->n_op = LS, RV(p) = -RV(p);
-p->n_left = zapleft(p->n_left);
+p->n_left = zapright(p->n_left);
 }
 #endif
 if (RO(p) == ICON) {
< at >< at > -196,7 +197,8 < at >< at > again:o = p->n_op;
 if (RV(p) >= sz)
 werror("shift larger than type");
 if (RV(p) == 0)
-p = zapleft(p);
+/* p = zapright(p); */
+goto zapright;
 }
 break;
 
< at >< at > -209,12 +211,12 < at >< at > again:o = p->n_op;
 if (LO(p) == LS && RCON(p->n_left) && RCON(p)) {
 /* two left-shift  by constants */
 RV(p) += RV(p->n_left);
-p->n_left = zapleft(p->n_left);
+p->n_left = zapright(p->n_left);
 }
 #if 0
   else if (LO(p) == RS && RCON(p->n_left) && RCON(p)) {
 RV(p) -= RV(p->n_left);
-p->n_left = zapleft(p->n_left);
+p->n_left = zapright(p->n_left);
 }
 #endif
 if (RO(p) == ICON) {
< at >< at > -235,7 +237,8 < at >< at > again:o = p->n_op;
 if (RV(p) >= sz)
 werror("shift larger than type");
 if (RV(p) == 0)  
-p = zapleft(p);
+/* p = zapright(p); */
+goto zapright;
 }
 break;
 
< at >< at > -281,8 +284,9 < at >< at > again:o = p->n_op;
     q->n_right->n_type == PTR+STRTY &&
     strmemb(q->n_left->n_ap) ==
     strmemb(q->n_right->n_ap)) {
-p = zapleft(p);
-p = zapleft(p);
+p = zapright(p);
+/* XXX consider replacing with goto zapright; */
+p = zapright(p);
 }
 }
 /* FALLTHROUGH */
< at >< at > -314,6 +318,7 < at >< at > again:o = p->n_op;
 
 q = p->n_left->n_left;
 nfree(p->n_left->n_right);
+/* XXX CHECKME: type information of node *p->n_left is lost here... */
 nfree(p->n_left);
 p->n_left = q;
 }

Re: ICE: how to debug?

Antoine Leca — 2013-03-01T12:19:54

<snip very good stuff>

Thanks ragge! That is exactly the information I needed!


Antoine