Discussion:
Wrapping up for a PCC 1.1 release.
Anders Magnusson
2014-09-22 20:15:29 UTC
Permalink
Hi,

it feels like it's time to start thinking about branching for a new release.

It may be reasonable to do it in a few weeks, unless some really nasty
bugs reveals itself and takes time to fix :-)

Comments?

-- Ragge
Iain Hibbert
2014-09-23 18:00:54 UTC
Permalink
Post by Anders Magnusson
it feels like it's time to start thinking about branching for a new release.
It may be reasonable to do it in a few weeks, unless some really nasty bugs
reveals itself and takes time to fix :-)
Comments?
I have not much in the way of pending issues, mostly because you have been
fixing things faster than I can generate them (I think the record was 40
mins from me creating the issue on JIRA :)

I think a PCC 1.1 would be good at this stage

iain
u***@aetey.se
2014-09-25 16:56:42 UTC
Permalink
Post by Anders Magnusson
it feels like it's time to start thinking about branching for a new release.
This would be nice - pcc has progressed a lot indeed.
Post by Anders Magnusson
It may be reasonable to do it in a few weeks, unless some really nasty bugs
reveals itself and takes time to fix :-)
It would be helpful to get shared libs into a reliable shape.
I am looking forward to test Richs upcoming patch. Hopefully
this will not cause a remarkable delay.

Rune
Steve Kargl
2014-09-25 21:00:26 UTC
Permalink
Post by Anders Magnusson
it feels like it's time to start thinking about branching for a new release.
It may be reasonable to do it in a few weeks, unless some really nasty
bugs reveals itself and takes time to fix :-)
Comments?
With cvs sources from today, I get

% ~/work/bin/pcc -version
pcc 1.1.0.DEVEL 20140925 for x86_64-unknown-freebsd11.0
error: no input files
% ~/work/bin/pcc -c a.c
a.c, line 7: syntax error
error: /home/sgk/work/libexec/ccom terminated with status 1
% cat a.c
#include <math.h>

double
foo(double x)
{
double y = 0;
if (isnan(x)) y = 42;
return (y);
}

Line 7 is the line with isnan(x). If I grab the code from math.h
that effects the compilatation of isnan, the example becomes

% ~/work/bin/pcc -c a.c
a.c:1: error: syntax error
error: /home/sgk/work/libexec/cpp terminated with status 1

The self contained code follows my sig.
--
Steve


#if (__STDC_VERSION__ >= 201112L && defined(__clang__)) || \
__has_extension(c_generic_selections)
#define __fp_type_select(x, f, d, ld) _Generic((x), \
float: f(x), \
double: d(x), \
long double: ld(x), \
volatile float: f(x), \
volatile double: d(x), \
volatile long double: ld(x), \
volatile const float: f(x), \
volatile const double: d(x), \
volatile const long double: ld(x), \
const float: f(x), \
const double: d(x), \
const long double: ld(x))
#elif __GNUC_PREREQ__(3, 1) && !defined(__cplusplus)
#define __fp_type_select(x, f, d, ld) __builtin_choose_expr( \
__builtin_types_compatible_p(__typeof(x), long double), ld(x), \
__builtin_choose_expr( \
__builtin_types_compatible_p(__typeof(x), double), d(x), \
__builtin_choose_expr( \
__builtin_types_compatible_p(__typeof(x), float), f(x), (void)0)))
#else
#define __fp_type_select(x, f, d, ld) \
((sizeof(x) == sizeof(float)) ? f(x) \
: (sizeof(x) == sizeof(double)) ? d(x) \
: ld(x))
#endif

#define isnan(x) \
__fp_type_select(x, __inline_isnanf, __inline_isnan, __inline_isnanl)

double
foo(double x)
{
double y = 0;
if (isnan(x)) y = 42;
return (y);
}
Anders Magnusson
2014-09-26 10:32:08 UTC
Permalink
Post by Steve Kargl
Post by Anders Magnusson
it feels like it's time to start thinking about branching for a new release.
It may be reasonable to do it in a few weeks, unless some really nasty
bugs reveals itself and takes time to fix :-)
Comments?
With cvs sources from today, I get
% ~/work/bin/pcc -version
pcc 1.1.0.DEVEL 20140925 for x86_64-unknown-freebsd11.0
error: no input files
% ~/work/bin/pcc -c a.c
a.c, line 7: syntax error
error: /home/sgk/work/libexec/ccom terminated with status 1
It was the builtins __builtin_choose_expr and
__builtin_types_compatible_p that were missing.
Now implemented, thanks!

-- Ragge
Steve Kargl
2014-09-26 14:57:40 UTC
Permalink
Post by Anders Magnusson
Post by Steve Kargl
Post by Anders Magnusson
it feels like it's time to start thinking about branching for a new release.
It may be reasonable to do it in a few weeks, unless some really nasty
bugs reveals itself and takes time to fix :-)
Comments?
With cvs sources from today, I get
% ~/work/bin/pcc -version
pcc 1.1.0.DEVEL 20140925 for x86_64-unknown-freebsd11.0
error: no input files
% ~/work/bin/pcc -c a.c
a.c, line 7: syntax error
error: /home/sgk/work/libexec/ccom terminated with status 1
It was the builtins __builtin_choose_expr and
__builtin_types_compatible_p that were missing.
Now implemented, thanks!
Thanks. That got me 1 step closer to compiling FreeBSD's libm.
Unfortunately, I'm now hitting

/home/kargl/../sgk/work/bin/pcc -O2 -pipe -march=opteron -I/usr/home/kargl/trunk/math/libm/msun/x86 -I/usr/home/kargl/trunk/math/libm/msun/ld80 -I/usr/home/kargl/trunk/math/libm/msun/src -I/usr/home/kargl/trunk/math/libm/msun/../libc/include -I/usr/home/kargl/trunk/math/libm/msun/../libc/amd64 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/home/kargl/trunk/math/libm/msun/src/e_scalb.c -o e_scalb.o
/usr/home/kargl/trunk/math/libm/msun/src/e_scalb.c, line 47: compiler error: internal label 420 not defined
error: /home/sgk/work/libexec/ccom terminated with status 1
*** Error code 1

I haven't been able to isolate this one, yet. :(
Stop.
make: stopped in /usr/home/kargl/trunk/math/libm/msun
--
Steve
Steve Kargl
2014-09-26 16:53:29 UTC
Permalink
Post by Steve Kargl
Thanks. That got me 1 step closer to compiling FreeBSD's libm.
Unfortunately, I'm now hitting
/home/kargl/../sgk/work/bin/pcc -O2 -pipe -march=opteron -I/usr/home/kargl/trunk/math/libm/msun/x86 -I/usr/home/kargl/trunk/math/libm/msun/ld80 -I/usr/home/kargl/trunk/math/libm/msun/src -I/usr/home/kargl/trunk/math/libm/msun/../libc/include -I/usr/home/kargl/trunk/math/libm/msun/../libc/amd64 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/home/kargl/trunk/math/libm/msun/src/e_scalb.c -o e_scalb.o
/usr/home/kargl/trunk/math/libm/msun/src/e_scalb.c, line 47: compiler error: internal label 420 not defined
error: /home/sgk/work/libexec/ccom terminated with status 1
*** Error code 1
I haven't been able to isolate this one, yet. :(
Stop.
This is an optimization bug (at least of FreeBSD).

~/work/bin/pcc -c d.c (compiles fine)
~/work/bin/pcc -c -O d.c
d.c, line 90: compiler error: internal lable 174 not defined
error: /home/sgk/work/libexec/ccom terminted with status 1

d.c follows sig.
--
Steve

typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef short __int16_t;
typedef unsigned short __uint16_t;
typedef int __int32_t;
typedef unsigned int __uint32_t;
typedef long __int64_t;
typedef unsigned long __uint64_t;

extern const union __infinity_un {
unsigned char __uc[8];
double __ud;
} __infinity;

extern const union __nan_un {
unsigned char __uc[sizeof(float)];
float __uf;
} __nan;

int __fpclassifyd(double) __attribute__((__const__));
int __fpclassifyf(float) __attribute__((__const__));
int __fpclassifyl(long double) __attribute__((__const__));
int __isfinitef(float) __attribute__((__const__));
int __isfinite(double) __attribute__((__const__));
int __isfinitel(long double) __attribute__((__const__));
int __isinff(float) __attribute__((__const__));
int __isinf(double) __attribute__((__const__));
int __isinfl(long double) __attribute__((__const__));
int __isnormalf(float) __attribute__((__const__));
int __isnormal(double) __attribute__((__const__));
int __isnormall(long double) __attribute__((__const__));
int __signbit(double) __attribute__((__const__));
int __signbitf(float) __attribute__((__const__));
int __signbitl(long double) __attribute__((__const__));

static __inline int
__inline_isnan(const double __x)
{

return (__x != __x);
}

static __inline int
__inline_isnanf(const float __x)
{

return (__x != __x);
}

static __inline int
__inline_isnanl(const long double __x)
{

return (__x != __x);
}

typedef __uint8_t u_int8_t;
typedef __uint16_t u_int16_t;
typedef __uint32_t u_int32_t;
typedef __uint64_t u_int64_t;

typedef union
{
double value;
struct
{
u_int32_t lsw;
u_int32_t msw;
} parts;
struct
{
u_int64_t w;
} xparts;
} ieee_double_shape_type;

double
scalb(double x, double fn)
{

if (__builtin_choose_expr( __builtin_types_compatible_p(__typeof(x), long double), __inline_isnanl(x), __builtin_choose_expr( __builtin_types_compatible_p(__typeof(x), double), __inline_isnan(x), __builtin_choose_expr( __builtin_types_compatible_p(__typeof(x), float), __inline_isnanf(x), (void)0)))||__builtin_choose_expr( __builtin_types_compatible_p(__typeof(fn), long double), __inline_isnanl(fn), __builtin_choose_expr( __builtin_types_compatible_p(__typeof(fn), double), __inline_isnan(fn), __builtin_choose_expr( __builtin_types_compatible_p(__typeof(fn), float), __inline_isnanf(fn), (void)0)))) return x*fn;
if (!finite(fn)) {
if(fn>0.0) return x*fn;
else return x/(-fn);
}
if (rint(fn)!=fn) return (fn-fn)/(fn-fn);
if ( fn > 65000.0) return scalbn(x, 65000);
if (-fn > 65000.0) return scalbn(x,-65000);
return scalbn(x,(int)fn);

}
Anders Magnusson
2014-09-26 20:28:42 UTC
Permalink
Post by Steve Kargl
Post by Steve Kargl
Thanks. That got me 1 step closer to compiling FreeBSD's libm.
Unfortunately, I'm now hitting
/home/kargl/../sgk/work/bin/pcc -O2 -pipe -march=opteron -I/usr/home/kargl/trunk/math/libm/msun/x86 -I/usr/home/kargl/trunk/math/libm/msun/ld80 -I/usr/home/kargl/trunk/math/libm/msun/src -I/usr/home/kargl/trunk/math/libm/msun/../libc/include -I/usr/home/kargl/trunk/math/libm/msun/../libc/amd64 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/home/kargl/trunk/math/libm/msun/src/e_scalb.c -o e_scalb.o
/usr/home/kargl/trunk/math/libm/msun/src/e_scalb.c, line 47: compiler error: internal label 420 not defined
error: /home/sgk/work/libexec/ccom terminated with status 1
*** Error code 1
I haven't been able to isolate this one, yet. :(
Stop.
This is an optimization bug (at least of FreeBSD).
~/work/bin/pcc -c d.c (compiles fine)
~/work/bin/pcc -c -O d.c
d.c, line 90: compiler error: internal lable 174 not defined
error: /home/sgk/work/libexec/ccom terminted with status 1
d.c follows sig.
Hm, interesting:

% pcc -O -c d.c
% nm d.o
00000180 t __inline_isnan
00000160 t __inline_isnanf
00000140 t __inline_isnanl
U finite
U rint
00000000 T scalb
U scalbn

This was on NetBSD, but the OS should not affect the result.
Hm, I'm wonder how to proceed with this.

-- Ragge
Steve Kargl
2014-09-26 21:20:49 UTC
Permalink
Post by Anders Magnusson
Post by Steve Kargl
~/work/bin/pcc -c d.c (compiles fine)
~/work/bin/pcc -c -O d.c
d.c, line 90: compiler error: internal lable 174 not defined
error: /home/sgk/work/libexec/ccom terminted with status 1
d.c follows sig.
% pcc -O -c d.c
% nm d.o
00000180 t __inline_isnan
00000160 t __inline_isnanf
00000140 t __inline_isnanl
U finite
U rint
00000000 T scalb
U scalbn
This was on NetBSD, but the OS should not affect the result.
Hm, I'm wonder how to proceed with this.
I'm not sure. It's been a long time since I last looked at pcc source code.
FWIW, the error occurs on amd64 hardware. I have FreeBSD running on my ia32
laptop. I'll install pcc on it and see if it is arch specific.
--
Steve
Anders Magnusson
2014-09-27 08:58:06 UTC
Permalink
Post by Steve Kargl
Post by Anders Magnusson
Post by Steve Kargl
~/work/bin/pcc -c d.c (compiles fine)
~/work/bin/pcc -c -O d.c
d.c, line 90: compiler error: internal lable 174 not defined
error: /home/sgk/work/libexec/ccom terminted with status 1
d.c follows sig.
% pcc -O -c d.c
% nm d.o
00000180 t __inline_isnan
00000160 t __inline_isnanf
00000140 t __inline_isnanl
U finite
U rint
00000000 T scalb
U scalbn
This was on NetBSD, but the OS should not affect the result.
Hm, I'm wonder how to proceed with this.
I'm not sure. It's been a long time since I last looked at pcc source code.
FWIW, the error occurs on amd64 hardware. I have FreeBSD running on my ia32
laptop. I'll install pcc on it and see if it is arch specific.
I installed FBSD10/amd64 and tested and got the error.
So now it's just to fix it :-)

-- Ragge
Anders Magnusson
2014-09-27 09:21:46 UTC
Permalink
Post by Anders Magnusson
Post by Steve Kargl
Post by Anders Magnusson
Post by Steve Kargl
~/work/bin/pcc -c d.c (compiles fine)
~/work/bin/pcc -c -O d.c
d.c, line 90: compiler error: internal lable 174 not defined
error: /home/sgk/work/libexec/ccom terminted with status 1
d.c follows sig.
% pcc -O -c d.c
% nm d.o
00000180 t __inline_isnan
00000160 t __inline_isnanf
00000140 t __inline_isnanl
U finite
U rint
00000000 T scalb
U scalbn
This was on NetBSD, but the OS should not affect the result.
Hm, I'm wonder how to proceed with this.
I'm not sure. It's been a long time since I last looked at pcc source code.
FWIW, the error occurs on amd64 hardware. I have FreeBSD running on my ia32
laptop. I'll install pcc on it and see if it is arch specific.
I installed FBSD10/amd64 and tested and got the error.
So now it's just to fix it :-)
Problem found. It is never-reached code that contains a goto to an
unexisting label.
This may occur in inlined functions when ?: is used. Have to think
about how to solve
it though.

-- Ragge
Anders Magnusson
2014-09-28 15:41:11 UTC
Permalink
Post by Steve Kargl
Post by Anders Magnusson
Post by Steve Kargl
Post by Anders Magnusson
it feels like it's time to start thinking about branching for a new release.
It may be reasonable to do it in a few weeks, unless some really nasty
bugs reveals itself and takes time to fix :-)
Comments?
With cvs sources from today, I get
% ~/work/bin/pcc -version
pcc 1.1.0.DEVEL 20140925 for x86_64-unknown-freebsd11.0
error: no input files
% ~/work/bin/pcc -c a.c
a.c, line 7: syntax error
error: /home/sgk/work/libexec/ccom terminated with status 1
It was the builtins __builtin_choose_expr and
__builtin_types_compatible_p that were missing.
Now implemented, thanks!
Thanks. That got me 1 step closer to compiling FreeBSD's libm.
Unfortunately, I'm now hitting
/home/kargl/../sgk/work/bin/pcc -O2 -pipe -march=opteron -I/usr/home/kargl/trunk/math/libm/msun/x86 -I/usr/home/kargl/trunk/math/libm/msun/ld80 -I/usr/home/kargl/trunk/math/libm/msun/src -I/usr/home/kargl/trunk/math/libm/msun/../libc/include -I/usr/home/kargl/trunk/math/libm/msun/../libc/amd64 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/home/kargl/trunk/math/libm/msun/src/e_scalb.c -o e_scalb.o
/usr/home/kargl/trunk/math/libm/msun/src/e_scalb.c, line 47: compiler error: internal label 420 not defined
error: /home/sgk/work/libexec/ccom terminated with status 1
*** Error code 1
It should be fixed now. I solved it by emitting labels that are
unreached when inlining, they will be removed later in pass2.

-- Ragge
Steve Kargl
2014-09-28 17:47:00 UTC
Permalink
Post by Anders Magnusson
Post by Steve Kargl
/home/kargl/../sgk/work/bin/pcc -O2 -pipe -march=opteron -I/usr/home/kargl/trunk/math/libm/msun/x86 -I/usr/home/kargl/trunk/math/libm/msun/ld80 -I/usr/home/kargl/trunk/math/libm/msun/src -I/usr/home/kargl/trunk/math/libm/msun/../libc/include -I/usr/home/kargl/trunk/math/libm/msun/../libc/amd64 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/home/kargl/trunk/math/libm/msun/src/e_scalb.c -o e_scalb.o
/usr/home/kargl/trunk/math/libm/msun/src/e_scalb.c, line 47: compiler error: internal label 420 not defined
error: /home/sgk/work/libexec/ccom terminated with status 1
*** Error code 1
It should be fixed now. I solved it by emitting labels that are
unreached when inlining, they will be removed later in pass2.
The good news is that e_scalb.c now compiles.

Now the bad news. On x86_64 (aka amd64), src/e_coshl.c, src/e_sinhl.c,
ld80/s_expl.c, and src/s_tanhl.c fail to compile. On i386, src/catrigf.c,
src/s_ccoshf.c, src/s_csinhf.c, and src/s_ctanhf.c faile to compile.
The errors are of the form

/home/kargl/work/bin/pcc -O2 -pipe -march=core2 \
-I/usr/home/kargl/trunk/math/libm/msun/x86 \
-I/usr/home/kargl/trunk/math/libm/msun/ld80 \
-I/usr/home/kargl/trunk/math/libm/msun/src \
-I/usr/home/kargl/trunk/math/libm/msun/../libc/include \
-I/usr/home/kargl/trunk/math/libm/msun/../libc/i386 -std=gnu99 \
-fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign \
-c /usr/home/kargl/trunk/math/libm/msun/src/s_ctanhf.c -o s_ctanhf.o
*** Error code 1 (continuing)

That is, no error code is emitted. This might take awhile to unravel.
--
Steve
Steve Kargl
2014-09-28 18:09:07 UTC
Permalink
Post by Steve Kargl
Now the bad news. On x86_64 (aka amd64), src/e_coshl.c, src/e_sinhl.c,
ld80/s_expl.c, and src/s_tanhl.c fail to compile. On i386, src/catrigf.c,
src/s_ccoshf.c, src/s_csinhf.c, and src/s_ctanhf.c faile to compile.
The errors are of the form
/home/kargl/work/bin/pcc -O2 -pipe -march=core2 \
-I/usr/home/kargl/trunk/math/libm/msun/x86 \
-I/usr/home/kargl/trunk/math/libm/msun/ld80 \
-I/usr/home/kargl/trunk/math/libm/msun/src \
-I/usr/home/kargl/trunk/math/libm/msun/../libc/include \
-I/usr/home/kargl/trunk/math/libm/msun/../libc/i386 -std=gnu99 \
-fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign \
-c /usr/home/kargl/trunk/math/libm/msun/src/s_ctanhf.c -o s_ctanhf.o
Started to dig into the i386 errors by simplifying the command line

/home/kargl/work/bin/pcc \
-I./x86 -I./ld80 -I./src -I../libc/include -I../libc/i386 \
-c src/catrigf.c

yields

src/catrigf.c, line 0: compiler error: bad STCALL hidden reg
error: /home/kargl/work/libexec/ccom terminated with status 1
--
Steve
Steve Kargl
2014-09-28 19:03:49 UTC
Permalink
Post by Steve Kargl
Post by Steve Kargl
Now the bad news. On x86_64 (aka amd64), src/e_coshl.c, src/e_sinhl.c,
ld80/s_expl.c, and src/s_tanhl.c fail to compile. On i386, src/catrigf.c,
src/s_ccoshf.c, src/s_csinhf.c, and src/s_ctanhf.c faile to compile.
The errors are of the form
/home/kargl/work/bin/pcc -O2 -pipe -march=core2 \
-I/usr/home/kargl/trunk/math/libm/msun/x86 \
-I/usr/home/kargl/trunk/math/libm/msun/ld80 \
-I/usr/home/kargl/trunk/math/libm/msun/src \
-I/usr/home/kargl/trunk/math/libm/msun/../libc/include \
-I/usr/home/kargl/trunk/math/libm/msun/../libc/i386 -std=gnu99 \
-fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign \
-c /usr/home/kargl/trunk/math/libm/msun/src/s_ctanhf.c -o s_ctanhf.o
Started to dig into the i386 errors by simplifying the command line
/home/kargl/work/bin/pcc \
-I./x86 -I./ld80 -I./src -I../libc/include -I../libc/i386 \
-c src/catrigf.c
yields
src/catrigf.c, line 0: compiler error: bad STCALL hidden reg
error: /home/kargl/work/libexec/ccom terminated with status 1
I've narrowed this down to the testcase that follows my sig.

% ~/work/bin/pcc -c z.c
z.c, line 0: compiler error: bad STCALL hidden reg
error: /home/kargl/work/libexec/ccom terminated with status 1

If I comment out the marked line, the code compiles. There
appears to be problem with a return type of "float _Complex".
--
Steve


float cimagf(float _Complex) __attribute__((__const__));
float crealf(float _Complex) __attribute__((__const__));

typedef union {
float _Complex f;
float a[2];
} float_complex;

static __inline float _Complex
cpackf(float x, float y)
{
float_complex z;
((z).a[0]) = x;
((z).a[1]) = y;
return (z.f);
}

float _Complex clog_for_large_values(float _Complex z);

float _Complex
casinhf(float _Complex z)
{
float x, y;
float _Complex w;
x = crealf(z);
y = cimagf(z);
/* Comment out the next line allows code to compile. */
w = clog_for_large_values(z) + 1;
return (cpackf(1.f, 1.f));
}
Anders Magnusson
2014-09-29 16:15:50 UTC
Permalink
Post by Steve Kargl
Post by Steve Kargl
Post by Steve Kargl
Now the bad news. On x86_64 (aka amd64), src/e_coshl.c, src/e_sinhl.c,
ld80/s_expl.c, and src/s_tanhl.c fail to compile. On i386, src/catrigf.c,
src/s_ccoshf.c, src/s_csinhf.c, and src/s_ctanhf.c faile to compile.
The errors are of the form
/home/kargl/work/bin/pcc -O2 -pipe -march=core2 \
-I/usr/home/kargl/trunk/math/libm/msun/x86 \
-I/usr/home/kargl/trunk/math/libm/msun/ld80 \
-I/usr/home/kargl/trunk/math/libm/msun/src \
-I/usr/home/kargl/trunk/math/libm/msun/../libc/include \
-I/usr/home/kargl/trunk/math/libm/msun/../libc/i386 -std=gnu99 \
-fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign \
-c /usr/home/kargl/trunk/math/libm/msun/src/s_ctanhf.c -o s_ctanhf.o
Started to dig into the i386 errors by simplifying the command line
/home/kargl/work/bin/pcc \
-I./x86 -I./ld80 -I./src -I../libc/include -I../libc/i386 \
-c src/catrigf.c
yields
src/catrigf.c, line 0: compiler error: bad STCALL hidden reg
error: /home/kargl/work/libexec/ccom terminated with status 1
I've narrowed this down to the testcase that follows my sig.
% ~/work/bin/pcc -c z.c
z.c, line 0: compiler error: bad STCALL hidden reg
error: /home/kargl/work/libexec/ccom terminated with status 1
If I comment out the marked line, the code compiles. There
appears to be problem with a return type of "float _Complex".
Yep, that was it. Return of float complex on i386 is done by putting
the floats in eax/edx instead of handling it as a struct. The bug
was because no hidden arg could be added for the non-existing
return struct :-)

Now fixed, thanks.

-- Ragge
Steve Kargl
2014-09-29 16:27:01 UTC
Permalink
Post by Anders Magnusson
Post by Steve Kargl
If I comment out the marked line, the code compiles. There
appears to be problem with a return type of "float _Complex".
Yep, that was it. Return of float complex on i386 is done by putting
the floats in eax/edx instead of handling it as a struct. The bug
was because no hidden arg could be added for the non-existing
return struct :-)
Now fixed, thanks.
Thanks. I won't be able to test this until tonight (which is
about 10 hours from now).
--
Steve
Steve Kargl
2014-09-28 20:57:08 UTC
Permalink
Post by Steve Kargl
Now the bad news. On x86_64 (aka amd64), src/e_coshl.c, src/e_sinhl.c,
ld80/s_expl.c, and src/s_tanhl.c fail to compile.
I've reduced the amd64 failure to an issue with inlining a
function.

% ~/../sgk/work/bin/pcc -I./x86 -I./ld80 -I./src -I../libc/include \
-I../libc/amd64 -c src/e_coshl.c
major internal compiler error: src/e_coshl.c, line 130
error: /home/sgk/work/libexec/ccom terminated with status 1

After preprocessing the code into z.c and reducing the
code that follows my sig.,

% ~/../sgk/work/bin/pcc -c z.c
major internal compiler error: z.c, line 74
error: /home/sgk/work/libexec/ccom terminated with status 1

If I change the line 'n = irintl(fn);' to simply 'n = fn'
the code compiles.
--
Steve


typedef unsigned short __uint16_t;
typedef unsigned int __uint32_t;
typedef unsigned long __uint64_t;
typedef __uint16_t uint16_t;
typedef __uint32_t uint32_t;
typedef __uint64_t uint64_t;
typedef __uint32_t u_int32_t;
typedef __uint64_t u_int64_t;

union IEEEl2bits {
long double e;
struct {
unsigned int manl :32;
unsigned int manh :32;
unsigned int exp :15;
unsigned int sign :1;
unsigned int junkl :16;
unsigned int junkh :32;
} bits;
struct {
unsigned long man :64;
unsigned int expsign :16;
unsigned long junk :48;
} xbits;
};

static __inline int
irintl(long double x)
{
int n;
asm("fistl %0" : "=m" (n) : "t" (x));
return (n);
}

static inline void
__k_expl(long double x, long double *hip, long double *lop, int *kp)
{
long double fn, q, r, r1, r2, t, z;
int n, n2;
fn = x;
r = x;
n = irintl(fn);
n2 = (unsigned)n % 128;
*kp = n >> 7;
r1 = x - fn;
r2 = fn;
z = r * r;
q = 0;
t = 0;
*hip = 1.;
*lop = 1.;
}

static inline void
k_hexpl(long double x, long double *hip, long double *lop)
{
int k;
__k_expl(x, hip, lop, &k);
*hip *= 1;
*lop *= 1;
}

long double
coshl(long double x)
{
long double hi,lo;
uint16_t ix;
union IEEEl2bits ge_u;
ge_u.e = x;
ix = ge_u.xbits.expsign;
ix &= 0x7fff;
k_hexpl(fabsl(x), &hi, &lo);
return (1.L);
}
Anders Magnusson
2014-09-29 19:59:27 UTC
Permalink
Post by Steve Kargl
Post by Steve Kargl
Now the bad news. On x86_64 (aka amd64), src/e_coshl.c, src/e_sinhl.c,
ld80/s_expl.c, and src/s_tanhl.c fail to compile.
I've reduced the amd64 failure to an issue with inlining a
function.
% ~/../sgk/work/bin/pcc -I./x86 -I./ld80 -I./src -I../libc/include \
-I../libc/amd64 -c src/e_coshl.c
major internal compiler error: src/e_coshl.c, line 130
error: /home/sgk/work/libexec/ccom terminated with status 1
After preprocessing the code into z.c and reducing the
code that follows my sig.,
% ~/../sgk/work/bin/pcc -c z.c
major internal compiler error: z.c, line 74
error: /home/sgk/work/libexec/ccom terminated with status 1
If I change the line 'n = irintl(fn);' to simply 'n = fn'
the code compiles.
The 't' xasm constraint were not handled correctly (not at all) and
therefore the argument to the inline function were never put in
register (or, actually, on the x87 stack).
Now fixed.

-- Ragge
Steve Kargl
2014-09-29 20:38:12 UTC
Permalink
Post by Anders Magnusson
Post by Steve Kargl
Post by Steve Kargl
Now the bad news. On x86_64 (aka amd64), src/e_coshl.c, src/e_sinhl.c,
ld80/s_expl.c, and src/s_tanhl.c fail to compile.
I've reduced the amd64 failure to an issue with inlining a
function.
% ~/../sgk/work/bin/pcc -I./x86 -I./ld80 -I./src -I../libc/include \
-I../libc/amd64 -c src/e_coshl.c
major internal compiler error: src/e_coshl.c, line 130
error: /home/sgk/work/libexec/ccom terminated with status 1
After preprocessing the code into z.c and reducing the
code that follows my sig.,
% ~/../sgk/work/bin/pcc -c z.c
major internal compiler error: z.c, line 74
error: /home/sgk/work/libexec/ccom terminated with status 1
If I change the line 'n = irintl(fn);' to simply 'n = fn'
the code compiles.
The 't' xasm constraint were not handled correctly (not at all) and
therefore the argument to the inline function were never put in
register (or, actually, on the x87 stack).
Now fixed.
I can confirm that this fixes the last issue I had with building
libm on x86_64 FreeBSD. Initial testing of my lgamma[fl]_r()
code suggests that pcc even generates the correct results. ;-)
--
Steve
Anders Magnusson
2014-09-30 06:31:34 UTC
Permalink
Post by Steve Kargl
Post by Anders Magnusson
Post by Steve Kargl
Post by Steve Kargl
Now the bad news. On x86_64 (aka amd64), src/e_coshl.c, src/e_sinhl.c,
ld80/s_expl.c, and src/s_tanhl.c fail to compile.
I've reduced the amd64 failure to an issue with inlining a
function.
% ~/../sgk/work/bin/pcc -I./x86 -I./ld80 -I./src -I../libc/include \
-I../libc/amd64 -c src/e_coshl.c
major internal compiler error: src/e_coshl.c, line 130
error: /home/sgk/work/libexec/ccom terminated with status 1
After preprocessing the code into z.c and reducing the
code that follows my sig.,
% ~/../sgk/work/bin/pcc -c z.c
major internal compiler error: z.c, line 74
error: /home/sgk/work/libexec/ccom terminated with status 1
If I change the line 'n = irintl(fn);' to simply 'n = fn'
the code compiles.
The 't' xasm constraint were not handled correctly (not at all) and
therefore the argument to the inline function were never put in
register (or, actually, on the x87 stack).
Now fixed.
I can confirm that this fixes the last issue I had with building
libm on x86_64 FreeBSD. Initial testing of my lgamma[fl]_r()
code suggests that pcc even generates the correct results. ;-)
Nice! Ok, thanks, one step closer to a 1.1 release :-)

-- Ragge

Irek Szczesniak
2014-09-26 11:47:42 UTC
Permalink
Post by Anders Magnusson
Hi,
it feels like it's time to start thinking about branching for a new release.
It may be reasonable to do it in a few weeks, unless some really nasty bugs
reveals itself and takes time to fix :-)
Could you please test whether ast-ksh aka ksh93 builds and runs with
the upcoming release? All previous releases either produced build
failures or unuseable executables on Linux (Suse and RHEL).

Irek
Thorsten Glaser
2014-09-26 11:58:30 UTC
Permalink
Post by Irek Szczesniak
Could you please test whether ast-ksh aka ksh93 builds and runs with
And mksh of course, which has proven to be a decent compiler,
toolchain, libc and kernel testsuite ☺

I’ll have a look at pcc on MirBSD and possibly MidnightBSD
myself, but constant during-development testing should probably
include '(mkdir tmp; cd tmp; CC=pcc sh /path/to/mksh/Build.sh -r && \
./test.sh -v) >mksh.log 2>&1' on your side.

bye,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Anders Magnusson
2014-09-26 20:30:15 UTC
Permalink
Post by Irek Szczesniak
Post by Anders Magnusson
Hi,
it feels like it's time to start thinking about branching for a new release.
It may be reasonable to do it in a few weeks, unless some really nasty bugs
reveals itself and takes time to fix :-)
Could you please test whether ast-ksh aka ksh93 builds and runs with
the upcoming release? All previous releases either produced build
failures or unuseable executables on Linux (Suse and RHEL).
Is there a simple way to test it? I looked at the web pages but it
seems as it
would take a little too much time to understand how to try this.

-- Ragge
Loading...