Ticket solving.

[Anders Magnusson]

Hi,

I have been traversing through and fixing tickets in Jira last days, and
now it is only some of the more peculiar tickets left.

This might indicate that there are not so many known bugs left :-)
Anyway, there are a few bugs left that I am not the best person to
solve, like fixing static linking on linux, etc. So, if someone knows
what to do in that area feel free to speak up :-)

-- Ragge

[Iain Hibbert]

Which target, please? :-)

i386

iain

[Anders Magnusson]

Which target, please? :-)

-- R

I have been traversing through and fixing tickets in Jira last days, and now
it is only some of the more peculiar tickets left.
This might indicate that there are not so many known bugs left :-)

I will find some more soon, please hang on :)
here is one.. in the last few days a regression test has failed
@@ -19,7 +19,8 @@
func002 passed
func003 passed
func004 passed
- func005 passed
+ func005 /usr/libexec/ccom terminated with
status 1
+failed
init001 passed
init002 passed
init003 passed
this is pertaining to floating point something or other, I am not sure..
regards,
iain

[Iain Hibbert]

I have been traversing through and fixing tickets in Jira last days, and now
it is only some of the more peculiar tickets left.
This might indicate that there are not so many known bugs left :-)

I will find some more soon, please hang on :)
here is one.. in the last few days a regression test has failed
@@ -19,7 +19,8 @@
func002 passed
func003 passed
func004 passed
- func005 passed
+ func005 /usr/libexec/ccom terminated with
status 1
+failed
init001 passed
init002 passed
init003 passed
this is pertaining to floating point something or other, I am not sure..

oh, I should also mention that two also now pass where they previously
failed.. :)

@@ -75,7 +76,7 @@
comments998 passed
const999 failed
const998 failed
- const997 failed
+ const997 passed
func999 passed
func998 passed
func997 failed
@@ -156,7 +157,7 @@
PCC-382 passed
PCC-383 passed
PCC-385 passed
- PCC-161 failed
+ PCC-161 passed
PCC-70 passed
PCC-159 passed


regards,
iain

[Iain Hibbert]

I have been traversing through and fixing tickets in Jira last days, and now
it is only some of the more peculiar tickets left.
This might indicate that there are not so many known bugs left :-)

I will find some more soon, please hang on :)

here is one.. in the last few days a regression test has failed

@@ -19,7 +19,8 @@
func002 passed
func003 passed
func004 passed
- func005 passed
+ func005 /usr/libexec/ccom terminated with
status 1
+failed
init001 passed
init002 passed
init003 passed

this is pertaining to floating point something or other, I am not sure..

regards,
iain

[Anders Magnusson]

I have been traversing through and fixing tickets in Jira last days, and now
it is only some of the more peculiar tickets left.
This might indicate that there are not so many known bugs left :-)

I will find some more soon, please hang on :)
here is one.. in the last few days a regression test has failed
@@ -19,7 +19,8 @@
func002 passed
func003 passed
func004 passed
- func005 passed
+ func005 /usr/libexec/ccom terminated with
status 1

This is due to the use of the "static" keyword in array declarations:

void f2(double a[restrict static 3][5]);

pcc do not really support that keyword yet, but because it needs space
allocated (which we do not) it's better to fail than just ignore it
since otherwise it may give unexpected failures. It is not an
especially useful keyword here.

This regression should have failed forever.

-- Ragge

[Iain Hibbert]

Post by Anders Magnusson

I have been traversing through and fixing tickets in Jira last days, and now
it is only some of the more peculiar tickets left.
This might indicate that there are not so many known bugs left :-)

I will find some more soon, please hang on :)
here is one.. in the last few days a regression test has failed
@@ -19,7 +19,8 @@
func002 passed
func003 passed
func004 passed
- func005 passed
+ func005 /usr/libexec/ccom terminated with
status 1

void f2(double a[restrict static 3][5]);
pcc do not really support that keyword yet, but because it needs space
allocated (which we do not) it's better to fail than just ignore it since
otherwise it may give unexpected failures. It is not an especially useful
keyword here.
This regression should have failed forever.

Hmm.. could it be the restrict instead or also? I see also a perhaps
related issue with code in binutils (2.64, though this has been there for
a long time), which has the following construct in a header <xregex2.h>


/* GCC 3.1 and later support declaring arrays as non-overlapping
using the syntax array_name[restrict] */
#ifndef __restrict_arr
# if ! (3 < __GNUC__ || (3 == __GNUC__ && 1 <= __GNUC_MINOR__)) || defined (__GNUG__)
# define __restrict_arr
# else
# define __restrict_arr __restrict
# endif
#endif

extern int regexec (const regex_t *__restrict __preg,
const char *__restrict __string, size_t __nmatch,
regmatch_t __pmatch[__restrict_arr],
int __eflags);

so basically, GCC allows something like

void foo(int a[restrict]);

though it does only succeed without warning when -std=gnu99 is given. I am
not sure if there is a difference between an array and a pointer, in the
context of a function call argument though.. is it possible to support
this syntax?

iain