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

SuSE RPM for pcc nightlies?

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

Is there a SuSE RPM for pcc nightlies?

Irek

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

ICE: how to debug?

Antoine Leca — 2013-02-26T09:24:20

Hi guys,

I got an ICE with new pcc (something which was OK previously), and I
wondered how I can go further in the debugging (ie how to search with -X
and -Z about the problem).

I simplified the offending input as
void f(unsigned u) { int i=(int)( u >> 0) % 5; }
<stdin>, line 2: compiler error: Cannot generate code, node 03571A0 op %

What is the next step? ccom -Ze seems a good starting point, but I do
not know where to search for the faulty node. Can someone help?


Antoine
___
PS: I know >>0 is useless, and using >>1 does not raise the problem; yet
it comes from de-macrofied code where the >>0 makes sense, and I do not
see why such code cannot be translated.

Error on C++ grammar; problem with bison's version?

Antoine Leca — 2013-02-21T18:18:23

Hi guys,

While I am trying to get the building process back in order with
Windows, I got an error with the C++ grammar:


C>bison --version
GNU Bison version 1.28

C>bison -y -t -d --no-lines cc\cxxcom\cgram.y
cc\cxxcom\cgram.y:318: type clash (`' `strp') on default action
cc\cxxcom\cgram.y:319: type clash (`' `strp') on default action

C>type DATESTAMP
20130217


I know that version is _very_ old, yet it served us faithfully until
now, and it does not complain on the C grammar. However I know next to
nothing to yacc (read: I am too lazy to dig into 2500 lines of yacc) so
I am completely unable to decide if there is a bug in the grammar, if it
is just a limit of my version, or if we are indeed requiring some
not-too-old version of bison (in which case we should check that with
autoconf...)

Any ideas?

Antoine

No activity on PCC for 1.5 months?

Mike — 2013-02-12T19:28:14

Hi,

Seems like no releases and no changes since 2013-01-01?  Has development 
totally stopped?

-Mike

daily cvs snapshots for pcc-libs?

minux — 2012-12-28T20:51:50

Hi,

    I've been maintaining an unofficial daily-updated git mirror [1] for
pcc for some time, as I
prefer working with git than with cvs.

    I recently got a issue report regarding the same for pcc-libs [2], I
searched for cvs snapshots
tarballs for pcc-libs but found none on the pcc ftp [3], and found that
there were daily snapshots
of cvs checkout, but no cvs repository snapshot, so I can't setup a git
mirror. Could you please
consider releasing a daily cvs repository snapshot of pcc-libs just like
pcc proper?

     Thanks.

[1] https://bitbucket.org/minux/pcc
[2] https://bitbucket.org/minux/pcc/issue/1/luddltuse-down
[3] http://pcc.ludd.ltu.se/ftp/pub/pcc/


Cheers,
minux

pcc and Fedora Linux

Fred J. Tydeman — 2012-11-30T22:50:53

Any idea when a current version of pcc will be released
as an official Fedora Linux software to install?  The
one there now is dated 2011/12/16.

---
Fred J. Tydeman        Tydeman Consulting
tydeman< at >tybor.com      Testing, numerics, programming
+1 (775) 287-5904      Vice-chair of PL22.11 (ANSI "C")
Sample C99+FPCE tests: http://www.tybor.com
Savers sleep well, investors eat well, spenders work forever.

FTBFS with mips as target

Isaac Dunham — 2012-11-30T19:37:46

I've been building pcc with a local patch I'm experimenting with; it changes config.sub & configure to add -DLD_MUSL and changes the linker when I use linux-musl as ostype, but otherwise acts like Linux.

The patched version builds when x86 is the target.

When I tried building with mips as target; it failed to build with:
===> cc/ccom
make[2]: Entering directory `/mnt/mesa/src/musl/loc/cvs/pcc/cc/ccom'
/opt/musl/bin/musl-gcc -static -Bstatic -static builtins.o cgram.o code.o common.o compat.o external.o gcc_compat.o init.o inline.o local.o local2.o main.o match.o optim.o optim2.o order.o pftn.o reader.o regs.o scan.o stabs.o symtabs.o table.o trees.o -o mips-muslin-linux-musl-ccom 
builtins.o:(.rodata+0x5b8): undefined reference to `builtin_cfa'
builtins.o:(.rodata+0x5cc): undefined reference to `builtin_frame_address'
builtins.o:(.rodata+0x5e0): undefined reference to `builtin_return_address'
collect2: ld returned 1 exit status
make[2]: *** [mips-muslin-linux-musl-ccom] Error 1
make[2]: Leaving directory `/mnt/mesa/src/musl/loc/cvs/pcc/cc/ccom'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/mnt/mesa/src/musl/loc/cvs/pcc/cc'
make: *** [all] Error 2

grep suggests that builtin_cfa is available on x86(64) and vax, possibly meaning that everything else will break if you try targeting it...

"lint" frontend for pcc ?

Roland Mainz — 2012-10-22T19:25:38

Hi!

----

Are there any plans to provide a "lint" frontend for pcc ? Main usage
of course would be code checking... but it would also be nice to have
a way to create "lint libraries", e.g. some kind of "condensed" code
which is shipped with compiled shared libraries and can be used for
type&&argument checking etc. etc. (for example see
http://docs.oracle.com/cd/E19205-01/819-5265/bjaiq/index.html).

----

Bye,
Roland

Buggy support for visibility=hidden, arrays don't decay to pointers in inline asm (aka why musl didn't work)

Isaac Dunham — 2012-10-14T04:44:23

Rich Felker and I recently took a look at why musl[1] was segfaulting when built with pcc. There were a few issues, which he's worked around for the time being:

1. PCC's support for __attribute__(visibility("hidden")) is buggy.
The workaround [2] is suboptimal, although it runs.

2. With gcc, arrays decay to pointers when used as arguments to inline asm. PCC is incompatible on this point. See [3] for an example.

3. Minor issue 1: -fPIC usually defines __PIC__, which pcc doesn't do.
This can be circumvented via -D__PIC__

4. Minor issue 2: pcc-libs is built without -fPIC; on some Linux systems/libcs (musl being one; I think any system with PaX may be affected as well), this can break linking with shared libraries.  Additionally, 
/configure doesn't honor CFLAGS. The workaround is
make CFLAGS="-fPIC" (or similar) when building pcc-libs.

Also, would it be possible for PCC to handle -march=* or at least -march=i*86 (=ld -melf_i386)? The current lack of handling means that the makefiles need some manual adjustment.

Thanks,
Isaac Dunham <idunham< at >lavabit.com>

[1] http://musl-libc.org
[2] http://git.musl-libc.org/cgit/musl/commit/?id=e23d358fd6254d88c85750a23cd1234855c3292c
and
http://git.musl-libc.org/cgit/musl/commit/?id=36be5284c2a79406778ac489928c6deb05857329
[3] http://git.musl-libc.org/cgit/musl/commit/?id=185a97707429aacfa1e8db62fc9fdb2188539d86

Assorted fixes

Thorsten Glaser — 2012-09-22T19:25:08

Hi,

hereby I submit a few patches I made during Debian packaging
of pcc-current (not yet complete due to the previous issue):

- branding.diff
Allow packagers to specify the version pcc reports
itself as, originally from MirPorts, already submitted
earlier; this patch is rebased against pcc CVS HEAD

- fix-buildsystem.diff
Part of an earlier submitted patch that was not yet
committed: add support code for cross-compiling pcc,
i.e. using host compiler for things like mkext (not
yet tested; LDFLAGS_FOR_BUILD added recently), rebased
against pcc CVS HEAD

- fix-crt1.diff
NEW: Let pcc on Linux with glibc find crt1.o again

There are more patches upcoming and/or planned:

- Add support for Multi-Arch (things like /lib/i386-linux-gnu/)
- Possibly add support for µClibc on Linux (tested with OpenADK
  on MIPS last year already)
- More bugfixes?

Note that Linux/PowerPC /lib/ld-linux.so.2 is almost certainly
wrong; the Debian porterbox has /lib/ld.so.1 as non-multiarch
compatibility symlink in place but no ld-linux or something.

Have ARM and HPPA just never been tested on Linux systems, or
will they not work (as in, known)? Which ARM, anyway?

bye,
//mirabilos

[REGRESSION] Support for 'pcc -E -dD -' missing

Thorsten Glaser — 2012-09-22T19:16:42

First, an older pcc where it worked:

tg< at >blau:~ $ /usr/mpkg/bin/pcc -v
pcc 1.1.0.DEVEL 20110422 for i386-ecce-mirbsd10, MirPorts:pcc-1.0.999-20110422-0
no input files
8|tg< at >blau:~ $ (:|/usr/mpkg/bin/pcc -E -dD -; echo >&2 ${PIPESTATUS[*]}) | tail -1
0 0
# 1 "<stdin>"

Now, in current pcc, it fails:

tg< at >blau:~ $ /opt/pcc/bin/pcc -v
pcc 1.1.0.DEVEL 20120921 for i386-ecce-mirbsd10
no input files
8|tg< at >blau:~ $ (:|/opt/pcc/bin/pcc -E -dD -; echo >&2 ${PIPESTATUS[*]}) | tail -1
warning: unknown option '-dD'
0 0

That was a rather important option (plus, the exit status is
all wrong), and this regression is bad. Please fix.

Thanks,
//mirabilos

pcc-libs FTFBS on linux-amd64 with pcc itself

Thorsten Glaser — 2012-09-22T19:13:03

Hi,

I’m running into:

<=== libsoftfloat
===> libpcc
make[2]: Entering directory `/home/tg/pcc-1.1.0~DEVEL+20120922/builddir/amd64/libs/libpcc'
/home/tg/pcc-1.1.0~DEVEL+20120922/builddir/amd64/comp/cc/cc/pcc -O -I/home/tg/pcc-1.1.0~DEVEL+20120922/libs/libpc
c -DTARGET_LITTLE_ENDIAN=1 -Dos_linux -isystem /home/tg/pcc-1.1.0~DEVEL+20120922/libs/libpcc/include -O -g -c /ho
me/tg/pcc-1.1.0~DEVEL+20120922/libs/libpcc/cmpdi2.c
/home/tg/pcc-1.1.0~DEVEL+20120922/libs/libpcc/quad.h, line 134: redeclaration of __ashldi3
/home/tg/pcc-1.1.0~DEVEL+20120922/libs/libpcc/quad.h, line 135: redeclaration of __ashrdi3
/home/tg/pcc-1.1.0~DEVEL+20120922/libs/libpcc/quad.h, line 147: redeclaration of __lshrdi3
/home/tg/pcc-1.1.0~DEVEL+20120922/builddir/amd64/tmp/usr/lib/pcc/x86_64-pc-linux-gnu/1.1.0.DEVEL/libexec/ccom terminated with status 1
make[2]: *** [cmpdi2.o] Error 1

Even if I patch out the declarations from "quad.h", the definitions
in the files themselves yield a compile error:

/home/tg/pcc-1.1.0~DEVEL+20120922/builddir/amd64/comp/cc/cc/pcc -O -DDEB_TARGET_MULTIARCH="" -I/home/tg/pcc-1.1.0~DEVEL+20120922/libs/libpcc -DTARGET_LITTLE_ENDIAN=1 -Dos_linux -isystem /home/tg/pcc-1.1.0~DEVEL+20120922/libs/libpcc/include -O -g -c /home/tg/pcc-1.1.0~DEVEL+20120922/libs/libpcc/ashldi3.c
/home/tg/pcc-1.1.0~DEVEL+20120922/libs/libpcc/ashldi3.c, line 45: redeclaration of __ashldi3
/home/tg/pcc-1.1.0~DEVEL+20120922/builddir/amd64/tmp/usr/lib/pcc/x86_64-pc-linux-gnu/1.1.0.DEVEL/libexec/ccom terminated with status 1
make[2]: *** [ashldi3.o] Error 1

I cannot continue like this. Are these built in? GCC doesn’t yell
about them being redefined, and pcc doesn’t tell me where a previous
declaration is, plus, the implementation should still be possible.

Thanks in advance for fixing,
//mirabilos

driver changes: verbosity

Thorsten Glaser — 2012-09-21T20:16:14

Hi,

why was this done?

pcc/cc/cc/cc.c (lines 864f. in rev 1.254)

1.226        (ragge    05-Aug-12):              if (ninput > 1 && !Eflag)
1.226        (ragge    05-Aug-12):                      printf("%s:\n", ifile);

In:

revision 1.226
date: 2012/08/05 10:28:42;  author: ragge;  state: Exp;  lines: +543 -649
Change the rest of cc to Joerg's driver code, while trying to not break
too many targets.

I don’t like this:

(excerpt from log building pcc with pcc)

[…]
/opt/pcc/bin/pcc  cc.o compat.o strlist.o xalloc.o -o pcc
cc.o:
compat.o:
strlist.o:
xalloc.o:
<=== cc/cc
[…]

On the positive side, 3-stage bootstrapping of pcc plus building
and testing mksh, on i386-mirbsd, works still.

bye,
//mirabilos

regression with current pcc

Michael Shalayeff — 2012-09-18T13:48:09

re
this code:

double cimag(double _Complex);

double
cimag(double _Complex z)
{
return __imag__ z;
}

now produces:
c.c, line 6: redeclaration of cimag

it is from libc and used to compile fine
cu

PCC -print-file-name equivalent?

Isaac Dunham — 2012-09-10T06:11:13

Is there an argument to pcc equivalent to gcc's -print-file-name?

Background:
I sometimes use pcc with musl libc; while I haven't checked really
recently, pcc built everything except src/complex about a month ago.
(Workaround: mkdir nobild; mv src/complex nobild/ ; mv
include/complex.h nobild/)
But, linking properly requires hacking the Makefile--mainly to properly
locate libpcc: 
it must be built with -ffreestanding, but some symbols from libpcc are
required.  The path to libpcc is not passed to ld when -ffreestanding
is passed, so it must be manually added to the linker parameters.

There is a configure script to handle things like this, but to handle
PCC requires having some way to automatically locate libpcc.a.

Thanks,
Isaac Dunham

About functions used etc...

Anders Magnusson — 2012-09-06T11:24:32

Just to wrap up this discussion; here is my view on it:

there are a bunch of functions/attributes/whatever used on 
$MY_FAVOURITE_OS that may cause complaints on stuff in different parts 
of the compiler.  This is a problem with the world we are living in and 
my view is that it's best to try to avoid these complaints even if the 
constructions are legal and correct.

It do not look nice for someone that fetches pcc and tries to compile it 
but it bails out due to some system settings they cannot do anything 
about, even if the construction is legal and correct.

strcpy() on OpenBSD, is one example, Ubuntu complains about that the 
return value from write() is not used, flex > 2.5.31 gets a shadowed 
bdebug etc.  It exists everywhere...

So, the best thing is to try to avoid these constructions, to make the 
end users happy :-)

test -z "" || mkdir

Iain Hibbert — 2012-08-30T10:43:07

Hi

was looking at (various) Makefile.in; this construct in the "install"
target

  test -z "$(DESTDIR)$(bindir)" || mkdir -p "$(DESTDIR)$(bindir)"

seems wrong.. surely it should just be

  test -z "$(bindir)" || mkdir -p "$(DESTDIR)$(bindir)"

?

similarly with

  test -z "$(DESTDIR)$(mandir)/man1" || mkdir -p "$(DESTDIR)$(mandir)/man1"

since that test can never be false anyway.. what are we testing for?

regards,
iain

partially unbreak OpenBSD targets with pcc cvs

Jonathan Gray — 2012-08-22T15:47:44

The following diff stops pcc trying to link libpcc which isn't
installed at least, however I still need to comment

              strap(&middle_linker_flags, &crtdirs, CRTI, 'p');
              strap(&late_linker_flags, &crtdirs, CRTN, 'a');

in cc/cc/cc.c setup_ld_flags() otherwise pcc looks for these
files in the current directory and errors.

This was added in:
revision 1.226
date: 2012/08/05 10:28:42;  author: ragge;  state: Exp;  lines: +543 -649
Change the rest of cc to Joerg's driver code, while trying to not break
too many targets.

The amount of target specific ifdefs in cc.c is rather scary

Index: ccconfig.h
===================================================================
RCS file: /cvsroot/pcc/os/openbsd/ccconfig.h,v
retrieving revision 1.11
diff -u -p -r1.11 ccconfig.h
--- ccconfig.h5 Aug 2012 14:35:00 -00001.11
+++ ccconfig.h22 Aug 2012 15:29:26 -0000
< at >< at > -37,16 +37,39 < at >< at >
 #define F77LIBLIST { "-L/usr/local/lib", "-lF77", "-lI77", "-lm", "-lc", NULL };
 #endif
 
+#define CRTO0
+#define CRTN0
+
+#define DEFLIBS{ "-lc", NULL }
+#define DEFPROFLIBS{ "-lc_p", NULL }
+#define DEFCXXLIBS{ "-lp++", "-lc", NULL }
+
 #if defined(mach_amd64)
-#defineCPPMDADD { "-D__amd64__", NULL, }
+#define CPPMDADD \
+{ "-D__x86_64__", "-D__x86_64", "-D__amd64__", "-D__amd64", \
+  "-D__LP64__", "-D_LP64", NULL, }
+#elif defined(mach_arm)
+#define CPPMDADD { "-D__arm__", NULL, }
+#elif defined(mach_hppa)
+#define CPPMDADD { "-D__hppa__", NULL, }
 #elif defined(mach_i386)
-#defineCPPMDADD { "-D__i386__", NULL, }
-#elif defined(mach_vax)
-#define CPPMDADD { "-D__vax__", NULL, } 
+#define CPPMDADD { "-D__i386__", NULL, }
 #elif defined(mach_powerpc)
-#define CPPMDADD { "-D__powerpc__", NULL }
+#define CPPMDADD { "-D__powerpc__", NULL, }
+#elif defined(mach_vax)
+#define CPPMDADD { "-D__vax__", NULL, }
 #elif defined(mach_sparc64)
-#define CPPMDADD { "-D__sparc64__", NULL }
+#define CPPMDADD { "-D__sparc64__", NULL, }
 #else
 #error defines for arch missing
 #endif
+
+#ifndefPCC_WINT_TYPE
+#definePCC_WINT_TYPE"int"
+#endif
+#ifndefPCC_SIZE_TYPE
+#definePCC_SIZE_TYPE"unsigned long"
+#endif
+#ifndefPCC_PTRDIFF_TYPE
+#definePCC_PTRDIFF_TYPE"long"
+#endif