| Message ID | 20221112210535.45202-1-aldot@gcc.gnu.org |
|---|---|
| State | New |
| Headers | show |
| Series | Fortran: Remove unused declaration | expand |
Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches: > This function definition was removed years ago, remove it's prototype. > > gcc/fortran/ChangeLog: > > * gfortran.h (gfc_check_include): Remove declaration. > --- > gcc/fortran/gfortran.h | 1 - > 1 file changed, 1 deletion(-) > --- > Regtests cleanly, ok for trunk? > > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h > index c4deec0d5b8..ce3ad61bb52 100644 > --- a/gcc/fortran/gfortran.h > +++ b/gcc/fortran/gfortran.h > @@ -3208,7 +3208,6 @@ int gfc_at_eof (void); > int gfc_at_bol (void); > int gfc_at_eol (void); > void gfc_advance_line (void); > -int gfc_check_include (void); > int gfc_define_undef_line (void); > > int gfc_wide_is_printable (gfc_char_t); OK, thanks.
On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches: > > This function definition was removed years ago, remove it's prototype. > > > > gcc/fortran/ChangeLog: > > > > * gfortran.h (gfc_check_include): Remove declaration. > > --- > > gcc/fortran/gfortran.h | 1 - > > 1 file changed, 1 deletion(-) > > --- > > Regtests cleanly, ok for trunk? > > > > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h > > index c4deec0d5b8..ce3ad61bb52 100644 > > --- a/gcc/fortran/gfortran.h > > +++ b/gcc/fortran/gfortran.h > > @@ -3208,7 +3208,6 @@ int gfc_at_eof (void); > > int gfc_at_bol (void); > > int gfc_at_eol (void); > > void gfc_advance_line (void); > > -int gfc_check_include (void); > > int gfc_define_undef_line (void); > > > > int gfc_wide_is_printable (gfc_char_t); > > OK, thanks. Somehow this was applied with a CommitDate in 2021, breaking scripts that assume monotonically increasing CommitDate. Anyone know how that could have happened? Jason
Am 19.01.23 um 20:39 schrieb Jason Merrill via Gcc-patches: > On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: >> >> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches: >>> This function definition was removed years ago, remove it's prototype. >>> >>> gcc/fortran/ChangeLog: >>> >>> * gfortran.h (gfc_check_include): Remove declaration. >>> --- >>> gcc/fortran/gfortran.h | 1 - >>> 1 file changed, 1 deletion(-) >>> --- >>> Regtests cleanly, ok for trunk? >>> >>> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h >>> index c4deec0d5b8..ce3ad61bb52 100644 >>> --- a/gcc/fortran/gfortran.h >>> +++ b/gcc/fortran/gfortran.h >>> @@ -3208,7 +3208,6 @@ int gfc_at_eof (void); >>> int gfc_at_bol (void); >>> int gfc_at_eol (void); >>> void gfc_advance_line (void); >>> -int gfc_check_include (void); >>> int gfc_define_undef_line (void); >>> >>> int gfc_wide_is_printable (gfc_char_t); >> >> OK, thanks. > > Somehow this was applied with a CommitDate in 2021, breaking scripts > that assume monotonically increasing CommitDate. Anyone know how that > could have happened? It is quite unusual that the CommitDate is before the AuthorDate: % git show --pretty=fuller 7ce0cee77adf33397d0ba61e7445effd8a5d8fcc | head -5 commit 7ce0cee77adf33397d0ba61e7445effd8a5d8fcc Author: Bernhard Reutner-Fischer <aldot@gcc.gnu.org> AuthorDate: Sat Nov 6 06:51:00 2021 +0100 Commit: Bernhard Reutner-Fischer <aldot@gcc.gnu.org> CommitDate: Sat Nov 6 06:48:00 2021 +0100 Could this have prevented checks to work properly? Harald > Jason > >
On 19 January 2023 20:39:08 CET, Jason Merrill <jason@redhat.com> wrote: >On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches ><gcc-patches@gcc.gnu.org> wrote: >> >> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches: >> > This function definition was removed years ago, remove it's prototype. >> > >> > gcc/fortran/ChangeLog: >> > >> > * gfortran.h (gfc_check_include): Remove declaration. >> > --- >> > gcc/fortran/gfortran.h | 1 - >> > 1 file changed, 1 deletion(-) >> > --- >> > Regtests cleanly, ok for trunk? >> > >> > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h >> > index c4deec0d5b8..ce3ad61bb52 100644 >> > --- a/gcc/fortran/gfortran.h >> > +++ b/gcc/fortran/gfortran.h >> > @@ -3208,7 +3208,6 @@ int gfc_at_eof (void); >> > int gfc_at_bol (void); >> > int gfc_at_eol (void); >> > void gfc_advance_line (void); >> > -int gfc_check_include (void); >> > int gfc_define_undef_line (void); >> > >> > int gfc_wide_is_printable (gfc_char_t); >> >> OK, thanks. > >Somehow this was applied with a CommitDate in 2021, breaking scripts >that assume monotonically increasing CommitDate. Anyone know how that >could have happened? Sorry for that. I think i cherry-picked this commit to master before pushing it, not 100% sure though. What shall we do now?
On Thu, Jan 19, 2023 at 11:26 PM Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote: > > On 19 January 2023 20:39:08 CET, Jason Merrill <jason@redhat.com> wrote: > >On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches > ><gcc-patches@gcc.gnu.org> wrote: > >> > >> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches: > >> > This function definition was removed years ago, remove it's prototype. > >> > > >> > gcc/fortran/ChangeLog: > >> > > >> > * gfortran.h (gfc_check_include): Remove declaration. > >> > --- > >> > gcc/fortran/gfortran.h | 1 - > >> > 1 file changed, 1 deletion(-) > >> > --- > >> > Regtests cleanly, ok for trunk? > >> > > >> > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h > >> > index c4deec0d5b8..ce3ad61bb52 100644 > >> > --- a/gcc/fortran/gfortran.h > >> > +++ b/gcc/fortran/gfortran.h > >> > @@ -3208,7 +3208,6 @@ int gfc_at_eof (void); > >> > int gfc_at_bol (void); > >> > int gfc_at_eol (void); > >> > void gfc_advance_line (void); > >> > -int gfc_check_include (void); > >> > int gfc_define_undef_line (void); > >> > > >> > int gfc_wide_is_printable (gfc_char_t); > >> > >> OK, thanks. > > > >Somehow this was applied with a CommitDate in 2021, breaking scripts > >that assume monotonically increasing CommitDate. Anyone know how that > >could have happened? > > Sorry for that. > I think i cherry-picked this commit to master before pushing it, not 100% sure though. You would have also needed to override the commit date with GIT_COMMITTER_DATE. Do you remember using that environment variable at all? > What shall we do now? I don't think there's anything we can do about this commit at this point; rewriting the git history would be a bigger disruption than leaving it alone. Martin, I wonder about having the hooks reject out-of-order CommitDate in future? Jason
On 1/19/23 23:26, Bernhard Reutner-Fischer wrote: > On 19 January 2023 20:39:08 CET, Jason Merrill <jason@redhat.com> wrote: >> On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches >> <gcc-patches@gcc.gnu.org> wrote: >>> >>> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches: >>>> This function definition was removed years ago, remove it's prototype. >>>> >>>> gcc/fortran/ChangeLog: >>>> >>>> * gfortran.h (gfc_check_include): Remove declaration. >>>> --- >>>> gcc/fortran/gfortran.h | 1 - >>>> 1 file changed, 1 deletion(-) >>>> --- >>>> Regtests cleanly, ok for trunk? >>>> >>>> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h >>>> index c4deec0d5b8..ce3ad61bb52 100644 >>>> --- a/gcc/fortran/gfortran.h >>>> +++ b/gcc/fortran/gfortran.h >>>> @@ -3208,7 +3208,6 @@ int gfc_at_eof (void); >>>> int gfc_at_bol (void); >>>> int gfc_at_eol (void); >>>> void gfc_advance_line (void); >>>> -int gfc_check_include (void); >>>> int gfc_define_undef_line (void); >>>> >>>> int gfc_wide_is_printable (gfc_char_t); >>> >>> OK, thanks. >> >> Somehow this was applied with a CommitDate in 2021, breaking scripts >> that assume monotonically increasing CommitDate. Anyone know how that >> could have happened? > > Sorry for that. > I think i cherry-picked this commit to master before pushing it, not 100% sure though. > What shall we do now? I doubt a cherry-pick did this, we cherry pick often in glibc and the commit is added to the top of checkout and the commit date updated. There isn't anything we can do now. I was recently made aware that --since-as-filter= was added specifically to address this issue. https://patchwork.kernel.org/project/git/patch/YlnYDgZRzDI87b/z@vmiklos.hu/ ~~~ This is similar to --since, but it will filter out not matching commits, rather than stopping at the first not matching commit. This is useful if you e.g. want to list the commits from the last year, but one odd commit has a bad commit date and that would hide lots of earlier commits in that range. The behavior of --since is left unchanged, since it's valid to depend on its current behavior. Signed-off-by: Miklos Vajna <vmiklos@vmiklos.hu> ~~~ "but one odd commit has a bad commit date" :-) We should try to avoid commits like this because they really complicate any date-based analysis tooling, and --since-as-filter is fairly new.
On 1/20/23 18:33, Jason Merrill wrote: > Martin, I wonder about having the hooks reject out-of-order CommitDate > in future? Yes, I would do that. Looking at the last 30K commmits I see just a few violations of the order: UNIXTS hash 1668298622 30d77d49628 1630019619 5889e842ae4 1626967834 3f7a2374d31 1624564915 a0accaa9984 1620660174 0498d2d09a2 1606210175 f72175357d0 1605630503 8895913273b 1604409789 1528f34341b 1601415121 f836f3bc8f7 1593773652 9bc2c2347d5 1588873342 b9250b3cb91 1582563261 9069e9484ce Martin
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index c4deec0d5b8..ce3ad61bb52 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h @@ -3208,7 +3208,6 @@ int gfc_at_eof (void); int gfc_at_bol (void); int gfc_at_eol (void); void gfc_advance_line (void); -int gfc_check_include (void); int gfc_define_undef_line (void); int gfc_wide_is_printable (gfc_char_t);