Discussion:
PCC -print-file-name equivalent?
Isaac Dunham
2012-09-10 06:11:13 UTC
Permalink
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
Anders Magnusson
2012-09-15 10:40:07 UTC
Permalink
I just added -print-file-name and a few similar options to pcc. Have
fun :-)

BTW what is it in complex that fails? The pcc complex support isn't the
most efficient but at least it should work.

-- Ragge
Post by Isaac Dunham
Is there an argument to pcc equivalent to gcc's -print-file-name?
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
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
Szabolcs Nagy
2012-09-15 11:04:44 UTC
Permalink
Post by Anders Magnusson
BTW what is it in complex that fails? The pcc complex support isn't
the most efficient but at least it should work.
this fails to compile:

int main(){
double _Complex z = 0.0;
double x = (double)z;
}


also see
http://pcc.ludd.ltu.se/jira/browse/PCC-331
Anders Magnusson
2012-09-15 16:08:20 UTC
Permalink
Post by Szabolcs Nagy
Post by Anders Magnusson
BTW what is it in complex that fails? The pcc complex support isn't
the most efficient but at least it should work.
int main(){
double _Complex z = 0.0;
double x = (double)z;
}
Hm, mistake by me, fixed now.
Post by Szabolcs Nagy
also see
http://pcc.ludd.ltu.se/jira/browse/PCC-331
That's a different problem; pcc currently cannot do compile-time complex
calculations.

-- Ragge
Isaac Dunham
2012-09-15 23:20:22 UTC
Permalink
On Sat, 15 Sep 2012 12:40:07 +0200
Post by Anders Magnusson
I just added -print-file-name and a few similar options to pcc. Have
fun :-)
BTW what is it in complex that fails? The pcc complex support isn't the
most efficient but at least it should work.
Here's what I reported at first:

====
The lines indicated are:

x = creal(z);
y = cimag(z);

Which should be casts from a complex number to respectively a real or
imaginary number; under ISO C99 this should mean the real or imaginary
parts of a complex number.

AFAICT, this is the only thing preventing the build of musl with CC=pcc
--when src/complex/ is removed, it compiles fine.
====
Post by Anders Magnusson
Post by Isaac Dunham
Is there an argument to pcc equivalent to gcc's -print-file-name?
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
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
--
Isaac Dunham <***@lavabit.com>
Fred J. Tydeman
2012-09-16 01:20:27 UTC
Permalink
Post by Isaac Dunham
On Sat, 15 Sep 2012 12:40:07 +0200
Post by Anders Magnusson
I just added -print-file-name and a few similar options to pcc. Have
fun :-)
BTW what is it in complex that fails? The pcc complex support isn't the
most efficient but at least it should work.
====
x = creal(z);
y = cimag(z);
Which should be casts from a complex number to respectively a real or
imaginary number; under ISO C99 this should mean the real or imaginary
parts of a complex number.
I disagree. They are not casts.

cimag(z) extracts the imaginary part of a complex number and returns that
value as a real (not imaginary) type.


---
Fred J. Tydeman Tydeman Consulting
***@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.
Anders Magnusson
2012-09-17 19:56:24 UTC
Permalink
Post by Isaac Dunham
On Sat, 15 Sep 2012 12:40:07 +0200
Post by Anders Magnusson
I just added -print-file-name and a few similar options to pcc. Have
fun :-)
BTW what is it in complex that fails? The pcc complex support isn't the
most efficient but at least it should work.
====
x = creal(z);
y = cimag(z);
Which should be casts from a complex number to respectively a real or
imaginary number; under ISO C99 this should mean the real or imaginary
parts of a complex number.
Hm, you mean that these functions are unimplemented? They are simple,
so now I've added them as builtins.

-- ragge
Szabolcs Nagy
2012-09-17 21:12:26 UTC
Permalink
Post by Anders Magnusson
Post by Isaac Dunham
x = creal(z);
y = cimag(z);
Which should be casts from a complex number to respectively a real or
imaginary number; under ISO C99 this should mean the real or imaginary
parts of a complex number.
Hm, you mean that these functions are unimplemented? They are simple,
so now I've added them as builtins.
no, they should not be builtins

they should be declared in complex.h by the libc (or libm)
(with prototype and the symbols should be available with -lm)

btw latest pcc fails at static linking here, it
adds crtbeginT.o to the ld arguments, i'm not
sure who should provide that
Thorsten Glaser
2012-09-17 21:41:54 UTC
Permalink
Post by Szabolcs Nagy
they should be declared in complex.h by the libc (or libm)
Why are you complaining then, if you are trying to compile
a C library?
Post by Szabolcs Nagy
btw latest pcc fails at static linking here, it
adds crtbeginT.o to the ld arguments, i'm not
sure who should provide that
pcc-libs probably. On MirBSD, we have workable ones for
i386 and sparc in src/lib/csu/, so… (mostly NetBSD®-derived)

bye,
//mirabilos
--
<Natureshadow> Dann mach ich git annex copy --to shore und fertig ist das
<Natureshadow> das ist ja viel cooler als ownCloud ...
<mirabilos> sag ich doch
<Natureshadow> ja wieso stimmt das denn immer was du sagst ...
Isaac Dunham
2012-09-17 23:06:27 UTC
Permalink
On Mon, 17 Sep 2012 21:41:54 +0000 (UTC)
Post by Thorsten Glaser
Post by Szabolcs Nagy
they should be declared in complex.h by the libc (or libm)
Why are you complaining then, if you are trying to compile
a C library?
They're implemented as
#define creal(x) ((double)(x))
#define cimag(x) __CIMAG(x, double)
/* similar for float & long double */

This implementation is supported by most compilers.
--
Isaac Dunham <***@lavabit.com>
Anders Magnusson
2012-09-18 07:20:58 UTC
Permalink
Post by Isaac Dunham
On Mon, 17 Sep 2012 21:41:54 +0000 (UTC)
Post by Thorsten Glaser
Post by Szabolcs Nagy
they should be declared in complex.h by the libc (or libm)
Why are you complaining then, if you are trying to compile
a C library?
They're implemented as
#define creal(x) ((double)(x))
#define cimag(x) __CIMAG(x, double)
/* similar for float & long double */
What is the __CIMAG macro defined as?

-- Ragge
Anders Magnusson
2012-09-18 07:27:09 UTC
Permalink
Post by Szabolcs Nagy
Post by Anders Magnusson
Post by Isaac Dunham
x = creal(z);
y = cimag(z);
Which should be casts from a complex number to respectively a real or
imaginary number; under ISO C99 this should mean the real or imaginary
parts of a complex number.
Hm, you mean that these functions are unimplemented? They are simple,
so now I've added them as builtins.
no, they should not be builtins
they should be declared in complex.h by the libc (or libm)
(with prototype and the symbols should be available with -lm)
There is no reason not to have them as builtins (also), and gcc does so
these days so to be gcc compatible it is needed, but they should be in
libm as well. They do not often exist there nowadays though since gcc
have them as builtins.
Post by Szabolcs Nagy
btw latest pcc fails at static linking here, it
adds crtbeginT.o to the ld arguments, i'm not
sure who should provide that
Probably a fallout of the cc changes. Which file do you want a begin
for static linking?

-- Ragge
Szabolcs Nagy
2012-09-18 08:58:33 UTC
Permalink
Post by Anders Magnusson
Post by Szabolcs Nagy
they should be declared in complex.h by the libc (or libm)
(with prototype and the symbols should be available with -lm)
There is no reason not to have them as builtins (also), and gcc does so
these days so to be gcc compatible it is needed, but they should be in
libm as well. They do not often exist there nowadays though since gcc
have them as builtins.
i see
Post by Anders Magnusson
Post by Szabolcs Nagy
btw latest pcc fails at static linking here, it
adds crtbeginT.o to the ld arguments, i'm not
sure who should provide that
Probably a fallout of the cc changes. Which file do you want a
begin for static linking?
i thought [S]crt1.o,crti.o,crtn.o are provided by the libc/system
and crtbegin[S].o,crtend[S].o are provided by the compiler

and the S version is for shared executables (position independent)

i don't know what the crtbeginT.o is for
pcc-libs provides crtbegin.o and crtend.o for linux,
but not the crtbeginT.o
Thorsten Glaser
2012-09-18 18:49:04 UTC
Permalink
Post by Szabolcs Nagy
and crtbegin[S].o,crtend[S].o are provided by the compiler
[…]
Post by Szabolcs Nagy
i don't know what the crtbeginT.o is for
Statically linked executables. Both GCC and lib/csu/ in MirBSD
provide one. I think pcc-libs thus should do that, too.

bye,
//mirabilos
--
<Natureshadow> Dann mach ich git annex copy --to shore und fertig ist das
<Natureshadow> das ist ja viel cooler als ownCloud ...
<mirabilos> sag ich doch
<Natureshadow> ja wieso stimmt das denn immer was du sagst ...
Anders Magnusson
2012-09-18 19:09:40 UTC
Permalink
Post by Thorsten Glaser
Post by Szabolcs Nagy
and crtbegin[S].o,crtend[S].o are provided by the compiler
[…]
Post by Szabolcs Nagy
i don't know what the crtbeginT.o is for
Statically linked executables. Both GCC and lib/csu/ in MirBSD
provide one. I think pcc-libs thus should do that, too.
pcc-libs needs some refreshing. I have that on my TODO list, unless
someone manages to fix it before me.

-- Ragge

Loading...