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.
