Re: [patch] Fix PR libfortran/95177, ctype.h functions should not be called with char arguments

2021-12-16 Thread FX via Fortran
> unrelated PS: I’ve been thinking aloud and benchmarking faster integer I/O > for libgfortran at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076 > Comments are welcome on the proposed design, I think the current proposal is > a low-hanging fruit (not risky, much faster). Quick test integrati

Re: [patch] Fix PR libfortran/95177, ctype.h functions should not be called with char arguments

2021-12-16 Thread FX via Fortran
Hi Harald, I’m not on the list for now, please keep me in CC so I don’t miss replies. Thought it feels nice to be working on gfortran again :) > However, I am wondering if calling the macros safe_* gives a false > impression of what they actually do. The cases where they are used > with your p

Re: [patch] Fix PR libfortran/95177, ctype.h functions should not be called with char arguments

2021-12-16 Thread Harald Anlauf via Fortran
Hi FX, Am 16.12.21 um 21:22 schrieb FX via Fortran: Hi, Functions from should only be called on values that can be represented by unsigned char. On targets where char is a signed type, some of libgfortran calls have undefined behaviour. The solution is to cast the argument to unsigned char

[patch] Fix PR libfortran/95177, ctype.h functions should not be called with char arguments

2021-12-16 Thread FX via Fortran
Hi, Functions from should only be called on values that can be represented by unsigned char. On targets where char is a signed type, some of libgfortran calls have undefined behaviour. The solution is to cast the argument to unsigned char type. I’ve defined macros in libgfortran.h to do so, t

Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

2021-12-16 Thread FX via Fortran
Patch committed, after changing “call abort” to “stop”. Thanks for the review. FX

Re: [patch] Fix libfortran/98507, handling of timezone near year boundaries

2021-12-16 Thread FX via Fortran
> OK after fixing the above, and thanks for the patch! Patch committed, after changing “call abort” to “stop”. Thanks for the review. FX

Re: [patch] Fix libfortran/98507, handling of timezone near year boundaries

2021-12-16 Thread Harald Anlauf via Fortran
Hi FX, Am 16.12.21 um 15:17 schrieb FX via Fortran: Hi, DATE_AND_TIME can return incorrect values for non-UTC timezones, near the new year, when the local time and UTC time are in different years. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507 Attached patch fixes the issue by correcting

Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

2021-12-16 Thread Harald Anlauf via Fortran
Hi FX, we now use "STOP n" instead of "call abort" in testcases. OK with this change. Am 16.12.21 um 17:34 schrieb FX via Fortran: With correct patch attached, sorry. Hi, Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255

Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

2021-12-16 Thread FX via Fortran
With correct patch attached, sorry. Hi, Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255 Trivial fix, adding a testcase. Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit? FX pr101255.

Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

2021-12-16 Thread Harald Anlauf via Fortran
Hi FX, Am 16.12.21 um 15:49 schrieb FX via Fortran: Hi, Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255 Trivial fix, adding a testcase. it seems you attached the wrong patch (the one for pr985079). Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit

[patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

2021-12-16 Thread FX via Fortran
Hi, Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255 Trivial fix, adding a testcase. Bootstrapped and regtested on x86_64-pc-linux-gnu. OK to commit? FX pr98507.patch Description: Binary data

[patch] Fix libfortran/98507, handling of timezone near year boundaries

2021-12-16 Thread FX via Fortran
Hi, DATE_AND_TIME can return incorrect values for non-UTC timezones, near the new year, when the local time and UTC time are in different years. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507 Attached patch fixes the issue by correcting the logic to account for that wrapping of “day of the

[PATCH 40/40] openacc: Adjust testsuite to new "kernels" handling

2021-12-16 Thread Frederik Harwath
Adjust the testsuite to changed expectations with the new Graphite-based "kernels" handling. libgomp/ChangeLog: * testsuite/libgomp.oacc-c++/privatized-ref-2.C: Adjust. * testsuite/libgomp.oacc-c++/privatized-ref-3.C: Adjust. * testsuite/libgomp.oacc-c-c++-common/acc_prof