Re: [fpc-devel] duplicate internal error numbers

2020-10-08 Thread Marģers . via fpc-devel
- Reply to message -
Subject: Re: [fpc-devel] duplicate internal error numbers
Date: ceturtd., 8 okt. 2020, 19:39
From:  Sven Barth via fpc-devel 
To:  FPC developers' list 
> Marģers . via fpc-devel  schrieb am Do., 8. 
> Okt. 2020, 12:39:
> > > I would advise against an automated change in case it changes too many
> > > internal error numbers and when a third party raises an issue where the
> > > compiler has triggered one, we can no longer identify where in the code
> > > base that the state has gone bad because none of the numbers match any 
> > > more.

> > It is not that much problem. Most of internal errors would not be triggered 
> > by end users.
> Opened new ticket in bug tracer https://bugs.freepascal.org/view.php?id=37888

> That is kinda the point. They *should* not be triggered, but when they are 
> triggered they should be found. This is 
> especially important as most users are using release versions while we are 
> working on trunk. 

There are 555 internal error numbers changed of 4300+. It's about 13%. What's 
the probability that one of changed number will be triggered until next 
release. One or two in a year (or none). As i see it, it's just decision to 
make to accept or reject  the patch. 
I was curios how much duplicate internal error are there. A lot. Now you know 
that as well.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] duplicate internal error numbers

2020-10-08 Thread Sven Barth via fpc-devel
Marģers . via fpc-devel  schrieb am Do., 8.
Okt. 2020, 12:39:

> > I would advise against an automated change in case it changes too many
> > internal error numbers and when a third party raises an issue where the
> > compiler has triggered one, we can no longer identify where in the code
> > base that the state has gone bad because none of the numbers match any
> more.
>
> It is not that much problem. Most of internal errors would not be
> triggered by end users.
> Opened new ticket in bug tracer
> https://bugs.freepascal.org/view.php?id=37888


That is kinda the point. They *should* not be triggered, but when they are
triggered they should be found. This is especially important as most users
are using release versions while we are working on trunk.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] duplicate internal error numbers

2020-10-08 Thread Marģers . via fpc-devel
- Reply to message -
Subject: Re: [fpc-devel] duplicate internal error numbers
Date: trešd., 7 okt. 2020, 16:40
From:  J. Gareth Moreton via fpc-devel 
To:  

> When two different programmers write code on the same day in different
> parts of the compiler, there's bound to be a clash eventually.  

good example was z80 and xtensa

> I would advise against an automated change in case it changes too many
> internal error numbers and when a third party raises an issue where the
> compiler has triggered one, we can no longer identify where in the code
> base that the state has gone bad because none of the numbers match any more.

It is not that much problem. Most of internal errors would not be triggered by 
end users.
Opened new ticket in bug tracer https://bugs.freepascal.org/view.php?id=37888

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] duplicate internal error numbers

2020-10-07 Thread J. Gareth Moreton via fpc-devel
Normally internal error numbers need to be unique so it's easier to 
identify where the compiler's internal state went bad.  I have submitted 
a few patches of my own to rectify number clashes, but these are only in 
cases where they clash on the same platform (e.g. between two 
platform-specific routines or a platform-specific and a 
platform-agnostic routine).


To help minimise clashes when writing code, I format the numbers as 
follows: mmddij, where , mm and dd represent the year, month and 
day that I wrote the code segment respectively, i is an index that I 
generally keep constant within a routine (so different routines that I 
write on the same day have differing indices) and j is a secondary index 
used to differentiate individual internal errors wthin the same 
routine.  The indices aren't set in stone though.


When two different programmers write code on the same day in different 
parts of the compiler, there's bound to be a clash eventually.  Usually 
though I only submit a patch to change them if I run into a clash during 
development that either I think could cause confusion, or already has 
(i.e. I've triggered the internal error and I can't identify which 
routine is at fault).  Long story short, I only change an individual 
clash during these instances.


I would advise against an automated change in case it changes too many 
internal error numbers and when a third party raises an issue where the 
compiler has triggered one, we can no longer identify where in the code 
base that the state has gone bad because none of the numbers match any more.


Sorry - I probably went off on a bit of a tangent there.

Gareth aka. Kit

On 07/10/2020 14:18, Marģers . via fpc-devel wrote:

- Reply to message -
Subject: Re: [fpc-devel] duplicate internal error numbers
Date: trešd., 7 okt. 2020, 14:16
From:  Jonas Maebe via fpc-devel 
To:  

On 07/10/2020 13:02, Marģers . via fpc-devel wrote:

found total 4300+
1001 error number has to be changed to make all error number unique

as there are so huge number of changes to make i have question
1) would it be desirable to change all (or most) duplicate error
numbers in one single big patch?
2) selective amount of changes in multiple patches?
3) leave it as is? not broken don't fix or do nothing is a choice.

How many of these are part of different code generators? We only support
one architecture per compiler binary _and_ code generators for new
architectures often start as (partial) copies of existing code
generators, so it's normal that they have a lot of duplicate internal
errors, but it doesn't matter.
OTOH, I'm sure there are also still duplicates in generic code and
within single architectures, but to find those you have to look
exclusively at the generic files in combination with those for a single
architecture (which may be in multiple directories, e.g. compiler/x86
and compiler/i386 for the i386 target).

It's still plenty potential duplicates. Got 339 unique cases to investigate. A 
lot manual labor. As i understand that automated changes are not welcomed.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] duplicate internal error numbers

2020-10-07 Thread Marģers . via fpc-devel
- Reply to message -
Subject: Re: [fpc-devel] duplicate internal error numbers
Date: trešd., 7 okt. 2020, 14:16
From:  Jonas Maebe via fpc-devel 
To:  
> On 07/10/2020 13:02, Marģers . via fpc-devel wrote:
> > found total 4300+
> > 1001 error number has to be changed to make all error number unique
> >
> > as there are so huge number of changes to make i have question
> > 1) would it be desirable to change all (or most) duplicate error 
> > numbers in one single big patch?
> > 2) selective amount of changes in multiple patches?
> > 3) leave it as is? not broken don't fix or do nothing is a choice.

> How many of these are part of different code generators? We only support
> one architecture per compiler binary _and_ code generators for new
> architectures often start as (partial) copies of existing code
> generators, so it's normal that they have a lot of duplicate internal
> errors, but it doesn't matter.

> OTOH, I'm sure there are also still duplicates in generic code and
> within single architectures, but to find those you have to look
> exclusively at the generic files in combination with those for a single
> architecture (which may be in multiple directories, e.g. compiler/x86
> and compiler/i386 for the i386 target).

It's still plenty potential duplicates. Got 339 unique cases to investigate. A 
lot manual labor. As i understand that automated changes are not welcomed.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] duplicate internal error numbers

2020-10-07 Thread Jonas Maebe via fpc-devel
On 07/10/2020 13:02, Marģers . via fpc-devel wrote:
> found total 4300+
> 1001 error number has to be changed to make all error number unique
> 
> as there are so huge number of changes to make i have question
> 1) would it be desirable to change all (or most) duplicate error 
> numbers in one single big patch?
> 2) selective amount of changes in multiple patches?
> 3) leave it as is? not broken don't fix or do nothing is a choice.

How many of these are part of different code generators? We only support
one architecture per compiler binary _and_ code generators for new
architectures often start as (partial) copies of existing code
generators, so it's normal that they have a lot of duplicate internal
errors, but it doesn't matter.

OTOH, I'm sure there are also still duplicates in generic code and
within single architectures, but to find those you have to look
exclusively at the generic files in combination with those for a single
architecture (which may be in multiple directories, e.g. compiler/x86
and compiler/i386 for the i386 target).


Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel