* Re: RFC on PR77828 and internal units
@ 2016-10-05 14:17 Dominique d'Humières
0 siblings, 0 replies; 6+ messages in thread
From: Dominique d'Humières @ 2016-10-05 14:17 UTC (permalink / raw)
To: Andre Vehreschild; +Cc: fortran
Dear Andre,
> But do you by chance have a list of PRs, that require API version change,
> you can point out, even if incomplete?
An outstanding PR is pr36825: [F2008] Rank > 7 arrays [will break library ABI] libgfortran I/O+intrinsics.
You can also have a look at pr37577.
See also https://gcc.gnu.org/wiki/LibgfortranAbiCleanup and https://gcc.gnu.org/wiki/ArrayDescriptorUpdate.
Note that Paul has resurrected fortran-dev, but I doubt it will make it for gcc-7.
Good luck,
Dominique
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC on PR77828 and internal units
2016-10-04 9:16 ` Andre Vehreschild
@ 2016-10-04 16:57 ` Steve Kargl
0 siblings, 0 replies; 6+ messages in thread
From: Steve Kargl @ 2016-10-04 16:57 UTC (permalink / raw)
To: Andre Vehreschild; +Cc: Jerry DeLisle, gfortran
On Tue, Oct 04, 2016 at 11:15:50AM +0200, Andre Vehreschild wrote:
>
> On Mon, 3 Oct 2016 15:40:01 -0700
> Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
>
> > On Mon, Oct 03, 2016 at 01:29:25PM -0700, Jerry DeLisle wrote:
> > > Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77828
> > >
> > > The patch I posted clearly breaks ABI in the sense that it renames
> > > st_read and st_write to avoid calling a wrong library with the code
> > > compiled with Trunk (7.0)
> > >
> > > Personally I am OK with this because it is a solid line in the sand.
> > >
> >
> > There are a number of PR's that require breaking the
> > library's ABI. We've always punted the decision down the
> > road, but at some point the ABI is going to get broken.
> > I thought that a meta-bug report tracked the ABI breakage
> > PR's. A quick scan of bugzilla titles did not have one
> > jump out at me.
> >
> > Personally, I think we should bump the library's major
> > version number and start to introduce the long delayed
> > PR's.
> >
> > Of course, I have little to no time to actuall fix
> > anything. :)
> >
>
> But do you by chance have a list of PRs, that require API version change, you
> can point out, even if incomplete?
>
> Then I volunteer to introduce the meta-bug and collect them there.
>
I finally remembered where to look. Check
https://gcc.gnu.org/wiki/LibgfortranAbiCleanup
I believe that the cleanup is waiting on
https://gcc.gnu.org/wiki/ArrayDescriptorUpdate
Much of the array descriptor work has been done in the
fortran-dev branch (by pault and tobias?). Tobias merged
trunk into fortran-dev 13 days ago. It is my understanding
that 90 to 95% of the work is completed. The last 5-10%
is the hard part.
--
Steve
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC on PR77828 and internal units
2016-10-03 22:40 ` Steve Kargl
@ 2016-10-04 9:16 ` Andre Vehreschild
2016-10-04 16:57 ` Steve Kargl
0 siblings, 1 reply; 6+ messages in thread
From: Andre Vehreschild @ 2016-10-04 9:16 UTC (permalink / raw)
To: Steve Kargl; +Cc: Jerry DeLisle, gfortran
On Mon, 3 Oct 2016 15:40:01 -0700
Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> On Mon, Oct 03, 2016 at 01:29:25PM -0700, Jerry DeLisle wrote:
> > Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77828
> >
> > The patch I posted clearly breaks ABI in the sense that it renames
> > st_read and st_write to avoid calling a wrong library with the code
> > compiled with Trunk (7.0)
> >
> > Personally I am OK with this because it is a solid line in the sand.
> >
>
> There are a number of PR's that require breaking the
> library's ABI. We've always punted the decision down the
> road, but at some point the ABI is going to get broken.
> I thought that a meta-bug report tracked the ABI breakage
> PR's. A quick scan of bugzilla titles did not have one
> jump out at me.
>
> Personally, I think we should bump the library's major
> version number and start to introduce the long delayed
> PR's.
>
> Of course, I have little to no time to actuall fix
> anything. :)
>
But do you by chance have a list of PRs, that require API version change, you
can point out, even if incomplete?
Then I volunteer to introduce the meta-bug and collect them there.
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC on PR77828 and internal units
2016-10-03 20:29 Jerry DeLisle
2016-10-03 22:40 ` Steve Kargl
@ 2016-10-04 9:13 ` Andre Vehreschild
1 sibling, 0 replies; 6+ messages in thread
From: Andre Vehreschild @ 2016-10-04 9:13 UTC (permalink / raw)
To: Jerry DeLisle; +Cc: gfortran
Hi Jerry, hi all,
> The patch I posted clearly breaks ABI in the sense that it renames st_read and
> st_write to avoid calling a wrong library with the code compiled with Trunk
> (7.0)
>
> Personally I am OK with this because it is a solid line in the sand.
>
> Another approach would be to call a dummy function say
> "check_library_version_7 in the library initialization code and that would
> also catch the problem.
Sure, but this would not scale, when one has to check for say,
check_library_version_7_3_53p9 and so on. Furthermore was library version
numbering invented to exactly solve the problem at hand.
> Either way, the new library is not 100% compatible with the old.
>
> We can also do some things to be "more" compatible with internal units from
> previous versions, but that gets trickier and I was hoping to not go down that
> road. (back to the drawing board)
>
> Regardless of my opinion, what do others think?
Therefore, my vote for bumping the version number. Folks using computers and
especially those using a compiler will now what to do, when such an error
occurs.
Regards and thanks for so quickly resolving the issue,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC on PR77828 and internal units
2016-10-03 20:29 Jerry DeLisle
@ 2016-10-03 22:40 ` Steve Kargl
2016-10-04 9:16 ` Andre Vehreschild
2016-10-04 9:13 ` Andre Vehreschild
1 sibling, 1 reply; 6+ messages in thread
From: Steve Kargl @ 2016-10-03 22:40 UTC (permalink / raw)
To: Jerry DeLisle; +Cc: gfortran
On Mon, Oct 03, 2016 at 01:29:25PM -0700, Jerry DeLisle wrote:
> Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77828
>
> The patch I posted clearly breaks ABI in the sense that it renames
> st_read and st_write to avoid calling a wrong library with the code
> compiled with Trunk (7.0)
>
> Personally I am OK with this because it is a solid line in the sand.
>
There are a number of PR's that require breaking the
library's ABI. We've always punted the decision down the
road, but at some point the ABI is going to get broken.
I thought that a meta-bug report tracked the ABI breakage
PR's. A quick scan of bugzilla titles did not have one
jump out at me.
Personally, I think we should bump the library's major
version number and start to introduce the long delayed
PR's.
Of course, I have little to no time to actuall fix
anything. :)
--
Steve
^ permalink raw reply [flat|nested] 6+ messages in thread
* RFC on PR77828 and internal units
@ 2016-10-03 20:29 Jerry DeLisle
2016-10-03 22:40 ` Steve Kargl
2016-10-04 9:13 ` Andre Vehreschild
0 siblings, 2 replies; 6+ messages in thread
From: Jerry DeLisle @ 2016-10-03 20:29 UTC (permalink / raw)
To: gfortran
Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77828
The patch I posted clearly breaks ABI in the sense that it renames st_read and
st_write to avoid calling a wrong library with the code compiled with Trunk (7.0)
Personally I am OK with this because it is a solid line in the sand.
Another approach would be to call a dummy function say "check_library_version_7
in the library initialization code and that would also catch the problem.
Either way, the new library is not 100% compatible with the old.
We can also do some things to be "more" compatible with internal units from
previous versions, but that gets trickier and I was hoping to not go down that
road. (back to the drawing board)
Regardless of my opinion, what do others think?
Jerry
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-05 14:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-05 14:17 RFC on PR77828 and internal units Dominique d'Humières
-- strict thread matches above, loose matches on Subject: below --
2016-10-03 20:29 Jerry DeLisle
2016-10-03 22:40 ` Steve Kargl
2016-10-04 9:16 ` Andre Vehreschild
2016-10-04 16:57 ` Steve Kargl
2016-10-04 9:13 ` Andre Vehreschild
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).