Re: porting-to update request
On Tue, Mar 25, 2025 at 11:04 AM NightStrike wrote: > > Between GCC 9 and 10, the following code now errors out: > > integer function fcn(x) > implicit none > integer, intent(in) :: x > fcn = x * '0100'X > end function fcn > > Error: BOZ constant at (1) uses nonstandard postfix syntax [see > '-fno-allow-invalid-boz'] > Compiler returned: 1 > > First, the error message is wrong regarding the option to go see: > > gfortran: error: unrecognized command-line option > '-fno-allow-invalid-boz'; did you mean '-fallow-invalid-boz'? > > Second, that option doesn't protect against the aforementioned case. > > Third, and the main point of this email I guess, is that the > porting-to page should mention this: > https://www.gnu.org/software/gcc/gcc-10/porting_to.html > > It talks about argument mismatches, but it doesn't talk about BOZ > literals in expressions, which used to be (perhaps incorrectly) > accepted. There is no new command line option to accept this legacy > code, so the webpage should be updated at a minimum. Should I open a bugzilla PR about this?
Re: porting-to update request
On Fri, Mar 28, 2025 at 2:02 PM NightStrike wrote: > > On Tue, Mar 25, 2025 at 11:04 AM NightStrike wrote: > > > > Between GCC 9 and 10, the following code now errors out: > > > > integer function fcn(x) > > implicit none > > integer, intent(in) :: x > > fcn = x * '0100'X > > end function fcn > > > > Error: BOZ constant at (1) uses nonstandard postfix syntax [see > > '-fno-allow-invalid-boz'] > > Compiler returned: 1 > > > > First, the error message is wrong regarding the option to go see: > > > > gfortran: error: unrecognized command-line option > > '-fno-allow-invalid-boz'; did you mean '-fallow-invalid-boz'? > > > > Second, that option doesn't protect against the aforementioned case. > > > > Third, and the main point of this email I guess, is that the > > porting-to page should mention this: > > https://www.gnu.org/software/gcc/gcc-10/porting_to.html > > > > It talks about argument mismatches, but it doesn't talk about BOZ > > literals in expressions, which used to be (perhaps incorrectly) > > accepted. There is no new command line option to accept this legacy > > code, so the webpage should be updated at a minimum. > > Should I open a bugzilla PR about this? Is this email list still active? :)
porting-to update request
Between GCC 9 and 10, the following code now errors out: integer function fcn(x) implicit none integer, intent(in) :: x fcn = x * '0100'X end function fcn Error: BOZ constant at (1) uses nonstandard postfix syntax [see '-fno-allow-invalid-boz'] Compiler returned: 1 First, the error message is wrong regarding the option to go see: gfortran: error: unrecognized command-line option '-fno-allow-invalid-boz'; did you mean '-fallow-invalid-boz'? Second, that option doesn't protect against the aforementioned case. Third, and the main point of this email I guess, is that the porting-to page should mention this: https://www.gnu.org/software/gcc/gcc-10/porting_to.html It talks about argument mismatches, but it doesn't talk about BOZ literals in expressions, which used to be (perhaps incorrectly) accepted. There is no new command line option to accept this legacy code, so the webpage should be updated at a minimum.
testsuite under wine
When I run the testsuite under wine, I'm getting a lot of ANSI escape sequences. We had fixed this long ago, but it seems to be back. Any idea what I should change in my configuration to have this not happen? This is for build=host=x86_64-pc-linux-gnu and target=x86_64-w64-mingw32, with the testsuite running under wine64 v7.20. Example output, where you can see the output in between the escape sequences is correct: FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -Os output pattern test Output was: ^[[?25lC^[[?25h^[[?25lF^[[?25h^[[?25lI^[[?25h^[[?25l_^[[?25h^[[?25ls^[[?25h^[[?25le^[[?25h^[[?25lt^[[?25h^[[?25lp^[[?25h^[[?25lo^[[?25h^[[?25li^[[?25h^[[?25ln^[[?25h ^[[?25lt^[[?25h^[[?25le^[[?25h^[[?25lr^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lR^[[?25h^[[?25le^[[?25h^[[?25ls^[[?25h^[[?25lu^[[?25h^[[?25ll^[[?25h^[[?25l t^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25ls^[[?25h^[[?25lh^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25ll^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lb^[[?25h^[[?25le^[[?25h^[[?25 l^[[K^[[1C^[[?25h^[[?25lt^[[?25h^[[?25lh^[[?25h^[[?25le^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25ld^[[?25h^[[?25ld^[[?25h^[[?25lr^[[?25h^[[?25le^[[?25h^[[?2 5ls^[[?25h^[[?25ls^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lo^[[?25h^[[?25lf^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lC^[[?25h^[[?25l^[[K ^[[1C^[[?25h^[[?25ld^[[?25h^[[?25le^[[?25h^[[?25ls^[[?25h^[[?25lc^[[?25h^[[?25lr^[[?25h^[[?25li^[[?25h^[[?25lp^[[?25h^[[?25lt^[[?25h^[[?25lo^[[?25h^[[?25lr^[[?25h^[[ ?25l^[[K^[[1C^[[?25h^[[?25lf^[[?25h^[[?25lo^[[?25h^[[?25lr^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lF^[[?25h^[[?25lo^[[?25h^[[?25lr^ [[?25h^[[?25lt^[[?25h^[[?25lr^[[?25h^[[?25la^[[?25h^[[?25ln^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lp^[[?25h^[[?25lo^[[?25h^[[?25li^[[?25h^[[?25ln^[[?25h^[[?25lt^[[?25h^ [[?25le^[[?25h^[[?25lr^[[?25h^[[?25l.^[[?25h^M^M Should match: CFI_setpointer: Result shall be the address of a C descriptor for a Fortran pointer.
Re: testsuite under wine
On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig wrote: > > On 16.12.22 03:20, NightStrike via Fortran wrote: > > > When I run the testsuite under wine, I'm getting a lot of ANSI escape > > sequences. We had fixed this long ago, but it seems to be back. Any > > idea what I should change in my configuration to have this not happen? > > This should probably be fixed properly in some *.exp file, but you can > try setting the GCC_COLORS environment variable to an empty string > before running the test. That didn't help. It looks like this is always escape 25h to start the output and 25l to end it, which I think is turning the cursor on and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code). I apparently fixed this previously by building wine with --without-curses (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that option to wine was removed. Is there a way to hack this on the Deja side to ignore the escapes? Or to tell it to run in a way that makes wine not emit them?
Re: Adding a new thread model to GCC
On Fri, Dec 23, 2022 at 7:00 PM Jonathan Yong via Gcc-patches
wrote:
>
> On 12/22/22 12:28, i.nix...@autistici.org wrote:
> > On 2022-12-22 12:21, Jonathan Yong wrote:
> >
> > hello,
> >
> >> On 12/16/22 19:20, Eric Botcazou wrote:
> The libgcc parts look reasonable to me, but I can't approve them.
> Maybe Jonathan Yong can approve those parts as mingw-w64 target
> maintainer, or maybe a libgcc approver can do so.
> >>>
> >>> OK.
> >>>
> The libstdc++ parts are OK for trunk. IIUC they could go in
> separately, they just wouldn't be very much use without the libgcc
> changes.
> >>>
> >>> Sure thing.
> >>>
> >>
> >> Ping, need help to commit it?
> >
> > yes, it would be great if we can merge the path into gcc-13!
> >
> > I've tested it on gcc-12-branch and gcc-master for i686/x86_64 windows,
> > with msvcrt and ucrt runtime - works as it should!
> >
> > Eric ^^^
> >
> >
> >
> > best!
>
> Done, pushed to master branch. Thanks Eric.
I think this might have broken fortran. I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:
In file included from /tmp/rtmingw/mingw/include/windows.h:71,
from ../libgcc/gthr-default.h:606,
from ../../../libgfortran/../libgcc/gthr.h:148,
from ../../../libgfortran/io/io.h:33,
from ../../../libgfortran/runtime/error.c:27:
../../../libgfortran/io/io.h:298:24: error: expected identifier before
numeric constant
298 | { CC_LIST, CC_FORTRAN, CC_NONE,
|^~~
Re: Team Collaboration Considerations
On Tue, Dec 13, 2022, 03:10 Janne Blomqvist via Fortran wrote: > But in general, yes, I do think IRC is showing its age in an > increasingly multi-device and mobile world. > Tools like irccloud help here. I guess that doesn't qualify as open source though. >
Re: Team Collaboration Considerations
On Thu, Jan 19, 2023, 00:01 Benson Muite via Fortran wrote: > The GCC workflows is quite different from other open source projects > being primarily email based and not using a bug tracker. > There's a bug tracker. I think you mean there isn't a patch tracker (or at least not a system where you submit patches to a thing vs emailing them to a list and hoping someone replies). >
Re: Team Collaboration Considerations
On Thu, Jan 19, 2023 at 7:46 AM Toon Moene wrote: > > On 1/19/23 13:28, NightStrike via Fortran wrote: > > > On Thu, Jan 19, 2023, 00:01 Benson Muite via Fortran > > wrote: > > > >> The GCC workflows is quite different from other open source projects > >> being primarily email based and not using a bug tracker. > >> > > > > There's a bug tracker. I think you mean there isn't a patch tracker (or at > > least not a system where you submit patches to a thing vs emailing them to > > a list and hoping someone replies). > Well, you can put patches into Bugzilla ... You can, and people naturally do this, and I think it's great, but there's usually a response from someone saying "post that to the mailing list instead".
Re: Team Collaboration Considerations
On Thu, Jan 19, 2023, 13:33 Bernhard Reutner-Fischer wrote: > On 19 January 2023 13:52:55 CET, NightStrike via Fortran < > fortran@gcc.gnu.org> wrote: > > >You can, and people naturally do this, and I think it's great, but > >there's usually a response from someone saying "post that to the > >mailing list instead". > > The mailing list has a 20-30 year history with reasoning about what > currently is in the tree. I do think it is valuable to reason about patches > publically for others to see. And I'm aware that this might not be regarded > fancy nowadays by everyone. > > But that does not mean that using other means to collaborate should not be > used by some. Be it comp.lang.fortran, a webchat.oftc, or other means, > that's all fine of course. > > patches currently are handled differently, but I don't think that is a > problem isn't it. > Just post final patches to the list as long as that is regarded the way to > do final review and document approval. > > cheers, > The problem is that patch tracking is unsustainable. You could go the other way and have a patch tracker automatically echo messages to the mailing list. >
Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
On Sat, Jan 21, 2023, 18:59 Jerry D via Fortran wrote: > > Proposed ChangeLog entry using git gcc-commit-mklog: > > Author: Jerry DeLisle > Date: Sat Jan 21 15:47:19 2023 -0800 > > Revise the line end tests to pass on certain windows test environments > which inject spurious /r characters. Adjust (\n|\r\n|\r) to (\r*\n+). > Just to be clear, all simulators inject the spurious r's. I replicated the problem on Linux.
Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Sun, Jan 29, 2023 at 2:37 PM Jerry D via Fortran wrote: > > I had this show up today. I have no idea what this is about. > > Please advise. I assume the buildbot thinks that https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8011fbba7baa46947341ca8069b5a327163a68d5 broke the build, but I fail to see how that commit results in the error reported in the log.
Re: [patch, gfortran.dg] Allow test to pass on mingw
On Fri, Jan 20, 2023 at 10:21 PM Jerry DeLisle via Fortran wrote: > > Hi all, > > Similar to a patch I committed a while ago for Cygwin, the attached > patch allows it to pass on the mingw version of gfortran. > > It is trivial. > > Ok for trunk? > > Regards, > > Jerry ping
Re: [PATCH][stage1] Remove conditionals around free()
On Fri, Mar 3, 2023 at 10:14 PM Jerry D via Fortran wrote: > I am certainly not a C++ expert but it seems to me this all begs for > automatic finalization where one would not have to invoke free at all. > I suspect the gfortran frontend is not designed for such things. +1 for RAII
static libgfortran linker warnings
When linking with -static-libgfortran, I get warnings from ld of the form "ld: warning: -z ignore ignored" and "ld: warning: -z record ignored". I can't find those -z options documented anywhere. Why is gfortran adding them?
Re: static libgfortran linker warnings
On Wed, Apr 21, 2021 at 4:59 AM Bernhard Reutner-Fischer wrote: > On Wed, 21 Apr 2021 02:34:43 -0400 > NightStrike via Fortran wrote: > > > When linking with -static-libgfortran, I get warnings from ld of the form > > "ld: warning: -z ignore ignored" and "ld: warning: -z record ignored". I > > can't find those -z options documented anywhere. Why is gfortran adding > > them? > > -z are options to ld. > Which linker do you use, on which OS? binutils 2.32 (stock build from source) on CentOS 7. > If you use binutils, you can pass -Wl,--verbose to the compiler to > instruct the linker to dump the linker script while linking. This should > show where the -z comes from: > gfortran foo.f90 -static-libgfortran -Wl,--verbose I didn't do this per se, but I did gfortran -v, and saw that it was an option to collect2. I can try your method when the system is available again tomorrow.
Re: static libgfortran linker warnings
On Wed, Apr 21, 2021 at 6:06 AM Bernhard Reutner-Fischer
wrote:
>
> On Wed, 21 Apr 2021 05:29:28 -0400
> NightStrike wrote:
>
> > On Wed, Apr 21, 2021 at 4:59 AM Bernhard Reutner-Fischer
> > wrote:
> > > On Wed, 21 Apr 2021 02:34:43 -0400
> > > NightStrike via Fortran wrote:
> > >
> > > > When linking with -static-libgfortran, I get warnings from ld of the
> > > > form
> > > > "ld: warning: -z ignore ignored" and "ld: warning: -z record ignored". I
> > > > can't find those -z options documented anywhere. Why is gfortran adding
> > > > them?
> > >
> > > -z are options to ld.
> > > Which linker do you use, on which OS?
> >
> > binutils 2.32 (stock build from source) on CentOS 7.
> >
> > > If you use binutils, you can pass -Wl,--verbose to the compiler to
> > > instruct the linker to dump the linker script while linking. This should
> > > show where the -z comes from:
> > > gfortran foo.f90 -static-libgfortran -Wl,--verbose
> >
> > I didn't do this per se, but I did gfortran -v, and saw that it was an
> > option to collect2. I can try your method when the system is
> > available again tomorrow.
>
> gcc/configure.ac suggests that -z ignore / -z record is the native
> solaris ld parlance for --as-needed / --no-as-needed
> See "AC_CACHE_CHECK(linker --as-needed support".
>
> No idea why your gcc build thought that the ignore/record tuple is the
> correct thing to use for as-needed/no-as-needed. Maybe check your
> config.log around the '--as-needed support' checks for clues.
>
> I wouldn't suggest to hand edit your libgfortran.spec to use
> *lib: %{static-libgfortran:--as-needed} -lquadmath
> %{static-libgfortran:--no-as-needed} -lm %(libgcc) %(liborig)
> but i guess that would silence your linker warnings, too.
> HTH,
FWIW:
./ld: supported targets: elf64-x86-64 elf32-i386 elf32-iamcu
elf32-x86-64 pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little
elf64-big elf32-little elf32-big plugin srec symbolsrec verilog tekhex
binary ihex
./ld: supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu
elf_l1om elf_k1om
./ld: emulation specific options:
Re: static libgfortran linker warnings
On Wed, Apr 21, 2021 at 6:17 AM Tobias Burnus wrote:
>
>
> >> On Wed, 21 Apr 2021 02:34:43 -0400
> >> NightStrike via Fortran wrote:
> >>> When linking with -static-libgfortran, I get warnings from ld of the form
> >>> "ld: warning: -z ignore ignored" and "ld: warning: -z record ignored". I
> >>> can't find those -z options documented anywhere. Why is gfortran adding
> >>> them?
> >> -z are options to ld.
>
> libgfortran/acinclude.m4 contains:
>
> dnl Check whether -Wl,--as-needed resp. -Wl,-zignore is supported
>
> That's where -z could come from. – Could you check what is in the
> installed file libgfortran.spec? On my Linux, it has:
>
> %{static-libgfortran:--as-needed}
>
> If you have a '-z ignore' there, it would be interesting to understand
> why – and what 'libgfortran/config.log' shows.
>
> >> Which linker do you use, on which OS?
> > binutils 2.32 (stock build from source) on CentOS 7.
>
> Here: Ubuntu with binutils 2.34.
%rename lib liborig
*lib: %{static-libgfortran:-zignore} -lquadmath
%{static-libgfortran:-zrecord} -lm %(libgcc) %(liborig)
Clearly, I built it wrong. I just would like to know how I did so.
