Re: [Request for Comments] Using Rust libraries in the Rust frontend
On Mon, Jan 22, 2024, 12:31 Arthur Cohen wrote: > I am aware that this would mean restricting the Rust > GCC front-end to platforms where the official Rust compiler is also > available, which is less than ideal. However, this would only be > temporary - as soon as the Rust front-end is able to compile these > components, we would simply reuse them and compile them with gccrs as > part of our bootstrapping process. > The easiest way to make a permanent change is to make a temporary one. >
Re: [Request for Comments] Using Rust libraries in the Rust frontend
On Thu, Jan 25, 2024, 11:27 Iain Sandoe wrote: > E.g. with Ada it is possible to port to a new platform by first building a > cross-compiler and then to use that cross-compiler to build a “native > cross” (build != host == target) to provide an initial compiler on the > target platform. > And that Ada solution is awful for nontraditional systems. Ditto for D. >
Re: Aw: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20
On Thu, Apr 27, 2023 at 5:41 AM Jakub Jelinek via Gcc wrote: > > On Thu, Apr 27, 2023 at 11:35:23AM +0200, Helmut Zeisel wrote: > > >Von: "Jakub Jelinek" > > >An: "Helmut Zeisel" > > >Cc: gcc@gcc.gnu.org > > >Betreff: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20 > > >On Thu, Apr 27, 2023 at 11:09:19AM +0200, Helmut Zeisel via Gcc wrote: > > >> I compiled GCC 13.1.0 with GCC 12 and had the environment variable > > >> CXXFLAGS set to -std=c++20 > > >> This gives the error (both linux and cygin) > > >> > > >> gcc-13.1.0/libstdc++-v3/src/c++98/bitmap_allocator.cc:51:23: error: ISO > > >> C++17 does not allow dynamic exception specifications > > >> 51 | _M_get(size_t __sz) throw(std::bad_alloc) > > >> > > >> After > > >> > > >> unset CXXFLAGS > > >> > > >> compilation works > > > > >Don't do it. > > > > Dont do *what*? > > export CXXFLAGS=... ? > > Include explicit -std= settings in such exported variables, especially when > building GCC. Packages should decide themselves in which language version > they are written in, or if they are written in common subset, they should > just defer to the compiler default. > Note, doing that would break building even much older GCC versions. Maybe configure should catch that? diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac index 0dd550a4b4b..f0d998aad94 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -86,6 +86,9 @@ AH_TEMPLATE(VERSION, [Version number of package]) # -fno-builtin must be present here so that a non-conflicting form of # std::exit can be guessed by AC_PROG_CXX, and used in later tests. +AS_CASE(["$CXXFLAGS"], + [*-std=*], [AC_MSG_ERROR([don't do that])]) + save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -fno-builtin" AC_PROG_CC
Re: Anyone using FTensor to test GCC (or otherwise)?
On Tue, Feb 14, 2023 at 6:20 PM Gerald Pfeifer wrote: > Alas http://www.wlandry.net/Projects/FTensor has been down for a while, > and there does not appear to be a new location? https://wlandry.net/Projects/FTensor/ works
Re: GCC -ftime-trace
On Sat, Feb 11, 2023, 14:37 Basile Starynkevitch wrote: > Modifying the pass manager > https://gcc.gnu.org/onlinedocs/gccint/Pass-manager.html#Pass-manager to > use clock_gettime system call. See > https://man7.org/linux/man-pages/man2/clock_gettime.2.html Since we can now use c++11, std::chrono::high_resolution_clock::now() would call that without being platform specific.
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: testsuite under wine
On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer wrote:
>
> NightStrike wrote:
> > [...]
> > I did another little test to try to better understand your point. I
> > ran a linux native testsuite under a simulator that just sets SIM to "
> > ". This resulted in extra ^M's also, although many tests pass because
> > they're already looking for \r\n to accommodate windows. So I think
> > I've come around to grasp what you've been heroically re-explaining...
> >
> > So if we have to modify every test in the entire testsuite to check
> > for zero or more \r's followed by zero or more \n's, would it be
> > better to add a dg-output-line proc that does this automatically
> > everywhere?
>
> Two problems: first, you need zero-or-more \r and *one*-or-more \n.
> Second, dg-output is not defined as an anchored match, and therefore
> cannot do this automatically.
"or more" \n is valid? That would make the rust bug of \r\r\n\n pass
when I assume it shouldn't.
> > I feel like changing every output pattern test won't be
> > too maintainable. You had mentioned previously modifying ${tool}_load
> > to filter out extra \r's, but I couldn't see where or how to do that.
> >
> > For completeness, setting a random selection of tests to look for
> > \r*\n? worked (this would cover even deprecated systems that only use
> > CR as well as flagging the weird rust case of \r\r\n\n as bad).
>
> Do not worry about classic Mac OS---running DejaGnu on that platform is
> not possible, nor is it possible to run test programs remotely on that
> platform. Classic Mac OS is a pure-GUI system with no command interface
> whatsoever. Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl
> exec(n) command. Due to limitations of the platform, porting Expect to
> classic Mac OS is simply not possible. Any compatibility layer would be
> reasonably expected to translate CR<->LF, if, for example, someone wrote
> a telnet server (and associated POSIX-alike environment) for Mac OS.
>
> The later Mac OS X is a quasi-POSIX mostly compatible with the GNU
> system that uses POSIX line endings. DejaGnu should run normally there.
>
> Are there other systems that used bare CR as end-of-line? If not, the
> correct pattern is therefore {\r*\n} (here written using braces as
> quotes around the pattern).
Maybe none that matter. From
https://en.wikipedia.org/wiki/Newline#Representation:
Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80,
Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9
The article also goes on to mention that OpenVMS and RSX-11 can be
configured to use CR.
Re: testsuite under wine
On Thu, Jan 5, 2023 at 10:33 PM Jacob Bachmeyer wrote:
>
> NightStrike wrote:
> > On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer wrote:
> >
> >> NightStrike wrote:
> >>
> >>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer
> >>> wrote:
> >>>
> [...]
> >>> So at least we know for sure that this particular instance of extra
> >>> characters is coming from Wine. Maybe Wine can be smart enough to
> >>> only translate \n into \r\n instead of translating \r\n into \r\r\n.
> >>> Jacek / Eric, comments here? I'm happy to try another patch, the
> >>> first one was great.
> >>>
> >>>
> >> I doubt that Wine is doing that translation. MinGW libc produces output
> >> conformant to Windows conventions, so printf("\n") on a text handle
> >> emits "\r\n", which Wine passes along. POSIX convention is that "\n" is
> >> translated to "\r\n" in the kernel terminal driver upon output, so the
> >> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
> >> "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be
> >> prepared to discard excess carriage returns. The first CR came from
> >> MinGW libc; the second CR came from the kernel terminal driver; the LF
> >> was ultimately passed through.
> >>
> >
> > Jacek and I have been digging into this on IRC, and he's been very
> > helpful in trying to get further, but we're still stuck. We tried to
> > be more introspective, inserting strace both as "strace script wine"
> > and as "script strace wine". We tried running just "wine a.exe"
> > without any extra glue, and logging the raw SSH packets from putty.
> > After many iterations on these and other tests, Jacek finally had the
> > idea to try removing Windows entirely from the equation, and we ran
> > with a purely unix program / compiler combination:
> >
> > #include
> >
> > int main()
> > {
> > write(1, "test\r\n", 6);
> > return 0;
> > }
> >
> > (and also as "test\n", 5)
> >
> > In both versions, the following was observed:
> >
> > case 1) ./a.out | xxd
> > case 2) script -c ./a.out out; xxd out
> > case 3) enable putting logging, ./a.out
> >
> > In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an
> > extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
> >
> > So, is it possible after all of this back and forth regarding mingw,
> > wine, and others, that it's down to the write() system call that's
> > inserting extra \r's? Is this expected?
> >
>
> "This is why DejaGnu testsuites must be prepared to discard excess
> carriage returns."
>
> The write(2) system call inserts nothing and simply hands off the buffer
> to the relevant part of the kernel I/O subsystem. (The kernel in POSIX
> is *not* a monolithic black box.) When stdout for your test program is
> a pty slave, that relevant part is the kernel terminal driver. The
> kernel terminal driver is converting "\n" to "\r\n" upon output to the
> associated port, since hardware terminals typically *do* require CRLF.
> The associated port in this case is virtual and part of the kernel pty
> subsystem, which presents octets written to that port to its associated
> pty master device. The user-visible pty slave device acts just like a
> serial terminal, including all translations normally done for handling
> serial terminals.
>
> A pty is conceptually a null-modem cable connected between two
> infinitely-fast serial ports on the same machine, although the slave
> will still report an actual baud rate if queried. (Run "stty" with no
> arguments under script(1), an ssh session, or an X11 terminal emulator
> to see what a pty slave looks like on your machine.)
>
> In your case 1, the pty subsystem is not used and output is collected
> over a pipe. Using "./a.out > out; xxd out" would produce the same
> results. In cases 2 and 3, there is a pty involved, either set up by
> script(1) or by sshd (assuming you meant "enable putty logging" in case
> 3) that performs the standard terminal translations. In all cases,
> strace(1) will show the exact string written to the pty slave device,
> which will not include any extra CRs because *those* *are* *inserted*
> *by* *the* *kernel* *terminal* *driver* as the data is transferred to
> the pty master device's read queue.
>
> This insertion of carriage returns is expected and standardized behavior
> in POSIX and is the reason Unix could use bare LF as end-of-line even
> though hardware terminals always needed CRLF. CP/M (and therefore
> MS-DOS which began its existence as a cheap CP/M knockoff) did not have
> this translation layer and instead dumped the complexity of a two-octet
> end-of-line sequence on user programs, leading to much confusion even
> today. This is not a Wine issue, although the terminal escape sequences
> in your original issue *were* from Wine. Note that the number of excess
> carriage returns that a DejaGnu testsuite must be prepared to discard is
> unspecified because running tests on remote targets may result in *any*
Re: testsuite under wine
On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer wrote:
> NightStrike wrote:
> > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote:
> >> NightStrike wrote:
> >>
> >>> [...]
> >>> Second, the problems with extra \r's still remain, but I think we've
> >>> generally come to think that that part isn't Wine and is instead
> >>> either the testsuite or deja. So I'll keep those replies to Jacob's
> >>> previous message.
> >>>
> >>>
> >> Most likely, it is a combination of the MinGW libc (which emits "\r\n"
> >> for end-of-line in accordance with Windows convention) and the kernel
> >> terminal driver (which passes "\r" and translates "\n" to "\r\n" in
> >> accordance with POSIX convention). Wine, short of trying to translate
> >> "\r\n" back to "\n" in accordance with POSIX conventions (and likely
> >> making an even bigger mess---does Wine know if a handle is supposed to
> >> be text or binary?) cannot really fix this, so the testsuite needs to
> >> handle non-POSIX-standard line endings. (The Rust tests probably have
> >> an outright bug if the newlines are being duplicated.)
> >>
> >
> > You may be onto something here. I ran wine under script as `script -c
> > "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r
> > prepended to the \r\n. I was making the mistake previously of running
> > wine manually and capturing it to a file as `wine64 ./a.exe > out`,
> > which as several have pointed out in this thread, that would disable
> > the quirk, so of course it didn't reveal any problems. I'm behind,
> > but I'll catch up to you guys eventually :)
> >
>
> So close, and yet so far... script(1) /also/ uses a pty, so it is
> getting the same translations as Expect and therefore DejaGnu.
>
> > So at least we know for sure that this particular instance of extra
> > characters is coming from Wine. Maybe Wine can be smart enough to
> > only translate \n into \r\n instead of translating \r\n into \r\r\n.
> > Jacek / Eric, comments here? I'm happy to try another patch, the
> > first one was great.
> >
>
> I doubt that Wine is doing that translation. MinGW libc produces output
> conformant to Windows conventions, so printf("\n") on a text handle
> emits "\r\n", which Wine passes along. POSIX convention is that "\n" is
> translated to "\r\n" in the kernel terminal driver upon output, so the
> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
> "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be
> prepared to discard excess carriage returns. The first CR came from
> MinGW libc; the second CR came from the kernel terminal driver; the LF
> was ultimately passed through.
Jacek and I have been digging into this on IRC, and he's been very
helpful in trying to get further, but we're still stuck. We tried to
be more introspective, inserting strace both as "strace script wine"
and as "script strace wine". We tried running just "wine a.exe"
without any extra glue, and logging the raw SSH packets from putty.
After many iterations on these and other tests, Jacek finally had the
idea to try removing Windows entirely from the equation, and we ran
with a purely unix program / compiler combination:
#include
int main()
{
write(1, "test\r\n", 6);
return 0;
}
(and also as "test\n", 5)
In both versions, the following was observed:
case 1) ./a.out | xxd
case 2) script -c ./a.out out; xxd out
case 3) enable putting logging, ./a.out
In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an
extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
So, is it possible after all of this back and forth regarding mingw,
wine, and others, that it's down to the write() system call that's
inserting extra \r's? Is this expected?
Re: Document how to build PGO-optimized GCC version
On Wed, Dec 28, 2022, 00:37 Alexander Zaitsev wrote: > Hello. > > We are using GCC for our C++ projects. Our projects are huge, commit > rate is quite huge, so our CI workers are always busy (so as any other > CI workers, honestly). Since we want to increase build speed, one of the > option is to optimize the compiler itself. Sounds like a good case for PGO. > > Clang has the infrastructure for building the Clang itself with PGO: > https://llvm.org/docs/HowToBuildWithPGO.html . I have tried to find > something like that for GCC but with no success. > > My proposal is: > > * add support for building PGO-optimized GCC into the GCC build > infrastructure > * add documentation to the GCC site, how to build GCC with PGO > optimizations > * (if GCC community provides prebuilt gcc binaries) use PGO for the > prebuilt binaries. E.g. Clang and rustc already uses this approach. > > Any feedback is appreciated. > > Thanks in advance! > > -- > Best regards, > Alexander Zaitsev > I would wager that you would get more bang for your buck out of 1) building a more recent gcc yourself instead of using whatever comes packaged, and 2) building with march=native for each processor type you run on. Not that PGO won't help, of course it will since you are building the same software repeatedly, but my personal experience doing the exact same thing is that I saw a 50% performance improvement from just from that, and it's rather trivial to do if your infrastructure is homogeneous (mine was a many node compute cluster). The next biggest bottleneck for me was IO, because the project this was for when compiling was very file intensive. Anyway, just some alternative suggestions, since there's already a response giving you what you asked for. Feel free to ignore me :) >
Re: testsuite under wine
On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote: > > NightStrike wrote: > > [...] > > Second, the problems with extra \r's still remain, but I think we've > > generally come to think that that part isn't Wine and is instead > > either the testsuite or deja. So I'll keep those replies to Jacob's > > previous message. > > > > Most likely, it is a combination of the MinGW libc (which emits "\r\n" > for end-of-line in accordance with Windows convention) and the kernel > terminal driver (which passes "\r" and translates "\n" to "\r\n" in > accordance with POSIX convention). Wine, short of trying to translate > "\r\n" back to "\n" in accordance with POSIX conventions (and likely > making an even bigger mess---does Wine know if a handle is supposed to > be text or binary?) cannot really fix this, so the testsuite needs to > handle non-POSIX-standard line endings. (The Rust tests probably have > an outright bug if the newlines are being duplicated.) You may be onto something here. I ran wine under script as `script -c "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r prepended to the \r\n. I was making the mistake previously of running wine manually and capturing it to a file as `wine64 ./a.exe > out`, which as several have pointed out in this thread, that would disable the quirk, so of course it didn't reveal any problems. I'm behind, but I'll catch up to you guys eventually :) So at least we know for sure that this particular instance of extra characters is coming from Wine. Maybe Wine can be smart enough to only translate \n into \r\n instead of translating \r\n into \r\r\n. Jacek / Eric, comments here? I'm happy to try another patch, the first one was great. Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so... yeah. Could be the rust test, could be the rust frontend, could be another weird Wine interaction.
Re: testsuite under wine
On Wed, Dec 21, 2022 at 12:38 PM Jacek Caban wrote: > > Hi all, > > > I'm responsible for Wine changes that cause your problems. I'm also > CCing Eric, who is Wine console expert, maybe he has better ideas. Eric, > see [1] if you're interested in the context. > > > Recent Wine versions implement Windows pseudo-consoles, see [2] for a > bit more details. It's generally Microsoft's semi-recent API that's > intended to be more compatible with POSIX than what was present in > previous versions of Windows. In theory, with that implemented, we could > just plug tty fds that we get from Unix and have Unix consoles working > using those Windows APIs. In practice, it's not quite as good as > promised and we need some tweaks to make it work nicely. We could > improve those tweaks, but there are architectural limitations that will > come to play sooner or later. > > > > I think that the long-term solution is that Wine should properly honor > > the TERM environment variable and not produce escape codes that the > > declared terminal does not support. > > > I think that it would not be enough. The way Windows consoles work is > that we manage complete internal screen buffer and emit output that > synchronizes the buffer with Unix terminal inside conhost.exe process. > It means that its output heavily processed and may be very different > from what application writes to its console handle. While escape codes > discussed in this thread are the most prominent difference (and that > part could, in theory, be improved on our side), there are more > differences. For example, if application writes "\rA\rB\rC", conhost > will process it, update its internal buffer which changes just one > character and cursor position, and emit sequence to update it in Unix > terminal, which could be just "\rC" (or even "C" if cursor was already > at the beginning of the line). Another example would be long lines: > conhost will emit additional EOLs instead of depending on embedder to > wrap the line. I'm not really familiar with DejaGnu, but if you want to > match application output, that's probably not what you're looking for. > > > The reason the previous workaround of compiling Wine without ncurses > worked is that if made Wine treat tty stdin/stdout in a way very similar > to regular pipes, so no extra processing was performed. This was more of > a side effect than a design choice. It should be possible to provide > some way to achieve that with the new Wine architecture. I'm attaching > an example of Wine patch that would allow it. With that patch, you may > disable conhost.exe (via winecfg or WINEDLLOVERRIDES=conhost.exe=d > environment variable) and achieve something similar to previous workaround. > > > Long term, I think that it would be best to get rid of console behaviour > expectations by using Windows build of DejaGnu. My understanding is that > it requires Cygwin, so the stack would be: Windows DejaGnu on Cygwin on > Wine on Linux. This would make all similar mismatches in expectations > non-existent. Cygwin is tricky to run on Wine, there are a few known > problems like [3], but we're getting there. > > > Jacek > > > [1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html > > [2] > https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ > > [3] https://bugs.winehq.org/show_bug.cgi?id=47808 First, a big giant thank you for this patch. I confirmed that I can use this to replace the "return immediately from init_console" hack, and it applies cleanly to 7.20. Second, the problems with extra \r's still remain, but I think we've generally come to think that that part isn't Wine and is instead either the testsuite or deja. So I'll keep those replies to Jacob's previous message.
Re: testsuite under wine
On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer wrote:
>
> NightStrike wrote:
> > On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer wrote:
> >
> >> [...]
> >> This is either a testsuite problem or an environment problem. The GNU
> >> Fortran I/O module certainly has interesting behavior here. Try setting
> >> TERM=dumb in the environment while running the testsuite. If that fixes
> >> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
> >> tool init file for GNU Fortran.
> >>
> >
> > Setting TERM doesn't help. Wine tries to emulate the windows console,
> > which requires outputting this stuff. It does so any time there's a
> > pty, and I believe that Deja creates a pty when running the tests.
> >
>
> That is a bug in Wine: the escapes should be suppressed entirely if the
> terminal does not support them---and the "dumb" terminal does not
> support them.
I think it's a paradigm difference. I'm just guessing here, but Wine
runs in a terminal that doesn't know about TERM. It's mimicking the
"cmd.exe" that you'd run on a native Windows system (I think... I'd
welcome corrections from those more knowledgeable). In theory, the
effect would be the same if I set up a remote target board to ssh to a
windows system and get dropped into a cmd.exe shell (I used to run
this way... it'd take about a week to run the whole testsuite. It
sucked...)
[...snip for now, I'm working on getting reasonable output back to
you, including an example of a case that fails, and how it responds to
your suggestion. Stay tuned...]
> > For now, I modified Wine to kludge out the code that
> > creates the console, and a long term solution needs to be on the Wine
> > side. I was just hoping for a less dirty hack from the Deja side.
> >
>
> I think that the long-term solution is that Wine should properly honor
> the TERM environment variable and not produce escape codes that the
> declared terminal does not support.
Agreed, just trying to get by for now.
> > Note that there are other problems, too. It seems that when Deja is
> > matching against "\n", it doesn't handle the different line endings of
> > Windows correctly in a cross environment. Is there a way that I can
> > set how to interpret \n in a target-board file? This affects fortran
> > and other language tests also.
>
> No---problems related to line endings are bugs in the testsuite. This
> caveat is documented in *Note: (dejagnu)Writing a test case. The manual
> explains: "Note that terminal settings may result in the insertion of
> additional `\r' characters, usually translating `\n' to `\r\n'."
>
> At the terminal layer, POSIX can *also* use "\r\n" sequences, since some
> terminals historically needed them, even though the standard line ending
> *within* a POSIX system is "\n" by itself. Because a pty simply
> presents the "terminal" side of the interface to the controlling
> program, Expect can receive "\r\n" when the subprocess emits "\n"; the
> translation is performed by the kernel terminal driver and DejaGnu
> testsuites must be prepared to receive (and discard) excess carriage
> returns in the general case.
Here's one that tries to handle different line endings (most tests do
not do this):
gfortran.dg/parameter_array_dummy.f90
which uses:
! { dg-output " *1 aa(\n|\r\n|\r)" }
! { dg-output " *2 ab(\n|\r\n|\r)" }
! { dg-output " *3 aaab(\n|\r\n|\r)" }
! { dg-output " *4 abaa(\n|\r\n|\r)" }
! { dg-output " *5 ababab(\n|\r\n|\r)" }
But this results in:
FAIL: gfortran.dg/parameter_array_dummy.f90 -O0 output pattern test
Output was:
1 aa^M^M
2 ab^M^M
3 aaab^M^M
4 abaa^M^M
5 ababab^M^M
Should match:
*1 aa(
|^M
|^M) *2 ab(
|^M
|^M) *3 aaab(
|^M
|^M) *4 abaa(
|^M
|^M) *5 ababab(
|^M
|^M)
The problem being that we are getting "0x0d 0x0d 0x0a", or \r\r\n.
(Other examples fail differently, for instance there's a Rust test
that outputs \r\r\n\n... but let's start with this one).
Re: testsuite under wine
On Mon, Dec 19, 2022 at 5:43 AM Torbjorn SVENSSON wrote: > I'm not sure if this helps anyone, but I experienced something similar with > Cygwin a while back. > What I had to do in order to have expect working when testing GCC on Windows > 10 was to defined the "CYGWIN" environment variable to "disable_pcon" > (https://cygwin.com/cygwin-ug-net/using-cygwinenv.html). If I did not define > this variable, then Cygwin would inject an escape sequence that would make > all pattern checks fail on the output. > > I don't know if Cygwin might has changed this behavior, but it was an issue > in the past anyway. This is extremely helpful for when I start testing natively, thank you. I think in general the problem is the same, but Wine doesn't immediately have a comparable workaround.
Re: testsuite under wine
On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer wrote: > > NightStrike wrote: > > On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig wrote: > > > >> On 17.12.22 01:26, NightStrike wrote: > >> > >>> 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? > >>> > >> Truth is, I don't know. > >> > >> I have included the gcc mailing list in this reply, where more > >> knowledgeable people can be found :-) > >> > > > > Thanks. I'm including the dejagnu list, maybe someone there can help, too. > > > > For clarity, this is an example of what I see: > > > > Output was: > > ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[ > > ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1 > > ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M > > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ > > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M > > ^M^M > > > > Should match: > > My_R1: 78 56 34 12.* > > My_R2: 12 34 56 78.* > > Local_R1 : 78 56 34 12.* > > Local_R2 : 12 34 56 78.* > > Local_R1 : 78 56 34 12.* > > Local_R2 : 12 34 56 78.* > > Local_R1 : 78 56 34 12.* >
Re: testsuite under wine
On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig wrote: > > On 17.12.22 01:26, NightStrike wrote: > > 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? > > Truth is, I don't know. > > I have included the gcc mailing list in this reply, where more > knowledgeable people can be found :-) Thanks. I'm including the dejagnu list, maybe someone there can help, too. For clarity, this is an example of what I see: Output was: ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[ ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1 ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[ [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M ^M^M Should match: My_R1: 78 56 34 12.* My_R2: 12 34 56 78.* Local_R1 : 78 56 34 12.* Local_R2 : 12 34 56 78.* Local_R1 : 78 56 34 12.* Local_R2 : 12 34 56 78.* Local_R1 : 78 56 34 12.* Local_R2 : 12 34 56 78.*
Re: Can't build Ada
On Fri, Nov 25, 2022 at 3:09 PM Paul Koning via Gcc wrote: > But in any case, how does that relate to the error messages I got? They > don't seem to have anything to do with missing compilers, but rather with the > use of language features too new for the available (downloadable) Gnat. Generally speaking, the reason is that with a normal compiler build, where build = host = target, gcc can build itself and then run the newly built self to build the language runtimes. So if you're using gcc 5 to build gcc 12, you're actually not using gcc 5 for all that much. The new gcc 12 is used to build for instance libX. With a cross compiler, it's possible that the build != host, and so you can't use the newly built GCC in your build environment to build the language runtimes. For instance, say your cross compiler is hosted on Windows, but you are building it on Linux. You can't run the newly built gcc 12, so you have to use the original gcc 5 instead. That's why you have to start with a new native compiler, and then use that to build the cross compiler.
Re: [BUG] -Wuninitialized: initialize variable with itself
On Mon, Nov 14, 2022, 10:49 David Brown wrote: > > > On 14/11/2022 16:10, NightStrike wrote: > > > > > > On Mon, Nov 14, 2022, 04:42 David Brown via Gcc > > > > Warnings are not perfect - there is always the risk of false > positives > > and false negatives. And different people will have different ideas > > about what code is perfectly reasonable, and what code is risky and > > should trigger a warning. Thus gcc has warning flag groups (-Wall, > > -Wextra) that try to match common consensus, and individual flags for > > personal fine-tuning. > > > > Sometimes it is useful to have a simple way to override a warning in > > code, without going through "#pragma GCC diagnostic" lines (which are > > powerful, but not pretty). > > > > So if you have : > > > > int i; > > if (a == 1) i = 1; > > if (b == 1) i = 2; > > if (c == 1) i = 3; > > return i; > > > > the compiler will warn that "i" may not be initialised. But if you > > /know/ that one of the three conditions will match (or you don't care > > what "i" is if it does not match), then you know your code is fine > and > > don't want the warning. Writing "int i = i;" is a way of telling the > > compiler "I know what I am doing, even though this code looks dodgy, > > because I know more than you do". > > > > It's just like writing "while ((*p++ = *q++));", or using a cast to > > void > > to turn off an "unused parameter" warning. > > > > > > Wouldn't it be easier, faster, and more obvious to the reader to just > > use "int i = 0"? I'm curious what a real world use case is where you > > can't do the more common thing if =0. > > > > You can write "int i = 0;" if you prefer. I would not, because IMHO > doing so would be wrong, unclear to the reader, less efficient, and > harder to debug. > > In the code above, the value returned should never be 0. So why should > "i" be set to 0 at any point? That's just an extra instruction the > compiler must generate (in my line of work, my code often needs to be > efficient). More importantly, perhaps, it means that if you use > diagnostic tools such as sanitizers you are hiding bugs from them > instead of catching them - a sanitizer could catch the case of "return > i;" when "i" is not set. > > (I don't know if current sanitizers will do that or not, and haven't > tested it, but they /could/.) > > But I'm quite happy with : > > int i = i; // Self-initialise to silence warning > > I don't think there is a "perfect" solution to cases like this, and > opinions will always differ, but self-initialisation seems a good choice > to me. Regardless of the pros and cons in this particular example, the > handling of self-initialisation warnings in gcc is, AFAIUI, to allow > such code for those that want to use it. Thanks for the extended explanation, insight, and detail!
Re: [BUG] -Wuninitialized: initialize variable with itself
On Mon, Nov 14, 2022, 04:42 David Brown via Gcc wrote:
> On 13/11/2022 19:43, Alejandro Colomar via Gcc wrote:
> > Hi Andrew!
> >
> > On 11/13/22 19:41, Andrew Pinski wrote:
> >> On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski
> wrote:
> >>>
> >>> On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
> >>> wrote:
>
> Hi,
>
> While discussing some idea for a new feature, I tested the following
> example
> program:
>
>
> int main(void)
> {
> int i = i;
> return i;
> }
> >>>
> >>> This is NOT a bug but a documented way of having the warning not
> >>> being there.
> >>> See
> >>>
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Winit-self
> >>>
> >>>
> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wuninitialized
> >>>
> >>> "If you want to warn about code that uses the uninitialized value of
> >>> the variable in its own initializer, use the -Winit-self option."
> >>
> >> I should note the main reason why I Know about this is because I fixed
> >> this feature years ago (at least for C front-end)
> >> and added the option to disable the feature.
> >
> > I'm curious: what are the reasons why one would want to disable such a
> > warning?
> > Why is it not in -Wall or -Wextra?
> >
> > Thanks,
> >
> > Alex
> >
>
> Warnings are not perfect - there is always the risk of false positives
> and false negatives. And different people will have different ideas
> about what code is perfectly reasonable, and what code is risky and
> should trigger a warning. Thus gcc has warning flag groups (-Wall,
> -Wextra) that try to match common consensus, and individual flags for
> personal fine-tuning.
>
> Sometimes it is useful to have a simple way to override a warning in
> code, without going through "#pragma GCC diagnostic" lines (which are
> powerful, but not pretty).
>
> So if you have :
>
> int i;
> if (a == 1) i = 1;
> if (b == 1) i = 2;
> if (c == 1) i = 3;
> return i;
>
> the compiler will warn that "i" may not be initialised. But if you
> /know/ that one of the three conditions will match (or you don't care
> what "i" is if it does not match), then you know your code is fine and
> don't want the warning. Writing "int i = i;" is a way of telling the
> compiler "I know what I am doing, even though this code looks dodgy,
> because I know more than you do".
>
> It's just like writing "while ((*p++ = *q++));", or using a cast to void
> to turn off an "unused parameter" warning.
>
Wouldn't it be easier, faster, and more obvious to the reader to just use
"int i = 0"? I'm curious what a real world use case is where you can't do
the more common thing if =0.
>
Re: Using CMake for building GCC
On Sun, Sep 11, 2022, 10:30 Junk Trash via Gcc wrote: > Hi, > > I want to get the opinions of GCC developers regarding adding CMake as a > build system for GCC. Is it something you would like, something you are > neutral about, or something you are strongly against? > > Thanks for your valuable feedback! > > Regards, > > JT > The high level premise of autotools is to make life harder for the build system maintainer of a project and easier for a user. This makes sense on several levels, including portability and familiarity. Cmake, on the other hand, makes life somewhat easier for the build system maintainer (I suppose) and harder for the user. This works for a pet project or something without wide distribution, but I don't personally find it to be a good design principle for usable and portable software. Autotools isn't perfect (configure steps are slow, for instance), but it's robust, reliable, portable, and trivial for an end user. >
Re: [FYI] bugzilla cleanup
On Thu, Sep 16, 2021 at 11:45 AM Martin Sebor via Gcc wrote: > ice-on-invalid-code: ICE on code that is not syntactically valid. > ice-on-valid-code: ICE on code that is syntactically valid. Presumably, the distinction is there because more attention would get paid to the latter over the former. An alternative would be to just have "ice", and thus perhaps it might cause more overall bugs to get fixed in the end.
Re: Porting to gcc 11 / intrinsics
On Tue, Aug 24, 2021 at 10:21 PM Andrew Pinski wrote: > > On Tue, Aug 24, 2021 at 6:39 PM NightStrike via Gcc wrote: > > On Mon, Aug 9, 2021, 07:16 NightStrike wrote: > > > > > When porting to GCC 11, care must be taken to adjust includes of GCC > > > intrinsic headers due to this change: > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97148 > > > > > > That should be reflected in: > > > > > > https://gcc.gnu.org/gcc-11/porting_to.html > > Should I make this a bugzilla? I guess I figured that wouldn't be > > appropriate. > > I don't see a reason why this should go into porting as there was no > change needed from previous versions of GCC. > Supporting -mno-sse is a new feature even. (Fixed my top posting gaff, sorry about that) Ok. I would have found the information useful, perhaps another place would be better? In general, documentation here is lacking.
Re: Analyzer tests fail on windows
On Tue, Aug 24, 2021 at 8:48 AM David Malcolm wrote: > Thanks for working through the above. > > Do you have an account in GCC's bugzilla? If so, please can you turn > this into a bug report there. Is there a recipe for testing this via > wine? (it's been almost 20 years since I did any Windows coding...) > > Dave https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102052 The method I'm using to test this is convoluted and difficult to set up. Based on his parallel reply to this thread, Jon might have a test setup that works better (and more professionally) with an internal redhat environment (W, not Y, obvoiusly :) ) What I did, though, was all on CentOS 6, which in itself needs newer tools, but not many. 1) Build a modern native compiler with binutils installed to the same prefix. For my test I used 11.2.0 and 2.37. 2) Build the cross compiler (note: for steps c and f, I needed to include dejagnu in the source tree b/c it wasn't available for me) a) Make a new sysroot with a mingw symlink to the target x86_64-w64-mingw32 b) Build the mingw-w64 headers, install into the sysroot c) Build binutils, install into the sysroot d) Build part of gcc, use the all-gcc target e) Build the mingw-w64 crt using the result of (d), install to sysroot f) Build the rest of gcc (use the normal all target), install to sysroot 3) Use the native compiler to build a modern bison (I used 3.something) 4) Use (1), (2), and (3) to build a stripped down wine with most features disabled (like any GUI features, for instance) 5) Use a new wine prefix with debug disabled and a custom dejagnu board that uses wine as the driver So, the above sequence 1) sucks, and 2) is probably not the way smarter people would do it. But, I got it up and running in under a day, so that does meet at least some basic requirements. I put most of that in a shell script that I can send you to at least illustrate the configure options at each step, and other details. I guess I should check all this in to mingw-w64's repos. Note that there are a LOT of testsuite failures. There was a time in the 4.4 era when Kai and I (let's be honest, it was 90% him) worked it down to < 20 failures across all languages. That is no longer the case, so we are trying once again to get the failure count down. On that note, Jon (W), it's interesting to hear that you regularly run the libstdc++ testsuite under wine. I'd like to compare my results to yours to see if my environment is just completely bogus. Are your results on the testresults mailing list? I haven't started with g++ yet, though, as it's harder to run, and I figured that gcc should pass first. I have one question, though, that perhaps you can answer upfront. After you do a build, before you run make check, what do you do to make the dll's available to the testsuite? Do you set WINEPATH to include their location, do you copy them somewhere first, do you make install first, or is there maybe a RUNTESTFLAGS option? I was struggling with this part, as no fix seemed to work permanently. > I use this for running libstdc++ tests under Wine: > > Xvfb :9 -screen 0 1024x768x16 & > trap 'kill %1' EXIT > # Start wine on the dummy X server, running a simple program. > # This means that each "wine a.exe" below won't start wine again. > DISPLAY=:9.0 WINEDEBUG=fixme-all wine view.exe & > trap 'kill -INT %2 && sleep 2 && kill -INT %1' EXIT > > and then "WINEDEBUG=fixme-font wine a.exe" to run an executable a.exe > built by a mingw-w64 cross compiler. Also, note that there's a command line option to wineserver to automate backgrounding it to avoid the workaround you are using. I haven't tried it, though, but I can let you know if I can get it to work. You are right that there is non-trivial overhead in starting wine each time. For my WINEDEBUG, I use "=-all" to shut everything off. Maybe that's a bad idea. Thoughts?
Re: Porting to gcc 11 / intrinsics
Should I make this a bugzilla? I guess I figured that wouldn't be appropriate. On Mon, Aug 9, 2021, 07:16 NightStrike wrote: > When porting to GCC 11, care must be taken to adjust includes of GCC > intrinsic headers due to this change: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97148 > > That should be reflected in: > > https://gcc.gnu.org/gcc-11/porting_to.html >
Re: Analyzer tests fail on windows
On Mon, Aug 23, 2021 at 8:16 PM NightStrike wrote: > On Mon, Aug 23, 2021 at 4:09 PM David Malcolm wrote: > > Which tests are failing, specifically? Here's the full list of all 37 failures that fail for any reason: FAIL: gcc.dg/analyzer/dot-output.c dg-check-dot dot-output.c.state-purge.dot FAIL: gcc.dg/analyzer/malloc-callbacks.c (test for excess errors) FAIL: gcc.dg/analyzer/pr98969.c (test for warnings, line 17) FAIL: gcc.dg/analyzer/pr98969.c (test for excess errors) FAIL: gcc.dg/analyzer/pr99716-1.c (test for warnings, line 25) FAIL: gcc.dg/analyzer/pr99716-2.c (test for excess errors) FAIL: gcc.dg/analyzer/pr99774-1.c (test for excess errors) FAIL: gcc.dg/analyzer/sensitive-1.c (test for warnings, line 16) FAIL: gcc.dg/analyzer/sensitive-1.c warning (test for warnings, line 17) FAIL: gcc.dg/analyzer/sensitive-1.c event (test for warnings, line 17) FAIL: gcc.dg/analyzer/sensitive-1.c (test for warnings, line 23) FAIL: gcc.dg/analyzer/sensitive-1.c (test for warnings, line 24) FAIL: gcc.dg/analyzer/sensitive-1.c event (test for warnings, line 24) FAIL: gcc.dg/analyzer/sensitive-1.c (test for warnings, line 30) FAIL: gcc.dg/analyzer/sensitive-1.c warning (test for warnings, line 31) FAIL: gcc.dg/analyzer/sensitive-1.c event (test for warnings, line 31) FAIL: gcc.dg/analyzer/sensitive-1.c (test for warnings, line 44) FAIL: gcc.dg/analyzer/sensitive-1.c (test for warnings, line 50) FAIL: gcc.dg/analyzer/sensitive-1.c (test for warnings, line 55) FAIL: gcc.dg/analyzer/sensitive-1.c (test for warnings, line 60) FAIL: gcc.dg/analyzer/sensitive-1.c (test for warnings, line 61) FAIL: gcc.dg/analyzer/signal-1.c (test for warnings, line 13) FAIL: gcc.dg/analyzer/signal-1.c (test for warnings, line 25) FAIL: gcc.dg/analyzer/signal-2.c (test for warnings, line 16) FAIL: gcc.dg/analyzer/signal-2.c (test for warnings, line 28) FAIL: gcc.dg/analyzer/signal-3.c (test for warnings, line 10) FAIL: gcc.dg/analyzer/signal-3.c (test for warnings, line 21) FAIL: gcc.dg/analyzer/signal-4a.c (test for warnings, line 15) FAIL: gcc.dg/analyzer/signal-4a.c expected multiline pattern lines 33-75 not found: FAIL: gcc.dg/analyzer/signal-6.c (test for warnings, line 11) FAIL: gcc.dg/analyzer/signal-6.c (test for warnings, line 16) FAIL: gcc.dg/analyzer/signal-registration-loc.c (test for warnings, line 15) FAIL: gcc.dg/analyzer/signal-registration-loc.c (test for warnings, line 21) FAIL: gcc.dg/analyzer/strndup-1.c (test for excess errors) FAIL: gcc.dg/analyzer/zlib-5.c (test for excess errors) Of those, here is what I diagnosed so far: pr98969.c:9:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] * This fails because the function arguments are "long int", and that tries to hold a pointer. It should be uintptr_t or similar. pr98969.c:17:3: warning: double-'free' of '*((struct foo *)(long long int)i).expr' [CWE-415] [-Wanalyzer-double-free] * My guess is that the regex is not right for running under wine, because that shouldn't be an excess error. pr99716-2.c:13:30: warning: implicit declaration of function 'random'; did you mean 'rand'? [-Wimplicit-function-declaration] * The warning is probably right here. The C function is rand(). Where does random() come from? pr99774-1.c:12:14: warning: conflicting types for built-in function 'calloc'; expected 'void *(long long unsigned int, long long unsigned int)' [-Wbuiltin-declaration-mismatch] * size_t issue strndup-1.c:9:13: warning: incompatible implicit declaration of built-in function 'strndup' [-Wbuiltin-declaration-mismatch] * This function doesn't exist on windows. So, either we add it to libmingwex if it isn't already there and then link that library in to the test, or just mark it as unsupported. I'd probably prefer the former, but it's not up to me. zlib-5.c:10:15: warning: conflicting types for built-in function 'strlen'; expected 'long long unsigned int(const char *)' [-Wbuiltin-declaration-mismatch] zlib-5.c:16:14: warning: conflicting types for built-in function 'calloc'; expected 'void *(long long unsigned int, long long unsigned int)' [-Wbuiltin-declaration-mismatch] * size_t issue gcc.dg/analyzer/gzio-3.c: gcc.dg/analyzer/gzio-3a.c: * For some reason, these work. Maybe fread() isn't a builtin? Maybe there's a way to make gcc emit a warning when fread() is redefined differently.
Re: Analyzer tests fail on windows
On Mon, Aug 23, 2021 at 4:09 PM David Malcolm wrote: > > On Mon, 2021-08-23 at 09:52 -1000, NightStrike wrote: > > David, > > > > Many of the analyzer tests fail on windows because they hardcode in > > the > > typedef of size_t to be unsigned long. This is not a platform > > independent > > definition, though, and is wrong for 64 bit windows. This causes > > extra > > warnings that all of the functions using size_t arguments are wrong, > > because they need to be unsigned long long. > > > > Is their either 1) a built in type you can use, like __SIZE_T__ if > > that's > > such a thing, or 2) can you just include stddef.h instead of > > manually > > putting the typedef at the top of each test? > > Which tests are failing, specifically? > > In many analyzer tests I'm using __SIZE_TYPE__ or stddef.h, however > I've recently added various tests reduced from the Linux kernel on > x86_64 which use unsigned long - maybe I need to rethink those. At least pr99774-1.c failed, but a non-comprehensive grep shows these: gzio-3a.c:typedef long unsigned int size_t; gzio-3.c:typedef long unsigned int size_t; pr99774-1.c:typedef long unsigned int size_t; zlib-5.c:typedef long unsigned int size_t; I can look more thoroughly later today. I admit my qualification of "many" is incorrect, given how many tests use __SIZE_TYPE__.
Analyzer tests fail on windows
David, Many of the analyzer tests fail on windows because they hardcode in the typedef of size_t to be unsigned long. This is not a platform independent definition, though, and is wrong for 64 bit windows. This causes extra warnings that all of the functions using size_t arguments are wrong, because they need to be unsigned long long. Is their either 1) a built in type you can use, like __SIZE_T__ if that's such a thing, or 2) can you just include stddef.h instead of manually putting the typedef at the top of each test?
Porting to gcc 11 / intrinsics
When porting to GCC 11, care must be taken to adjust includes of GCC intrinsic headers due to this change: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97148 That should be reflected in: https://gcc.gnu.org/gcc-11/porting_to.html
Re: Update to GCC copyright assignment policy
On Mon, Jun 7, 2021, 07:36 Giacomo Tesio wrote: > Hi NightStrike, > > On June 7, 2021 5:18:13 PM UTC, NightStrike wrote: > > On Mon, Jun 7, 2021, 06:12 Giacomo Tesio wrote: > > > > > The Steering Committee can avoid all of this, now. > > > I cannot really understand why they shouldn't. > > > > > > > Likely because the primary contributor to c++ has said he will stop > > contributing unless the change is made. > > Even so I guess he would have no issues to delay the policy change after > the next major release. > > Nor to stick with the previous policy for fixes backported to the other > versions. > > I mean, I do not know what's his goal, but I guess he doesn't intend to > blackmail > the Steering Committee and the whole GCC users community to achieve it. > > > Note that I have no idea about who we are talking about, but lilely about > a reasonable professionist. > > Or maybe we are talking about the dictact of a corporation? > In such case the issue would become way more risky. > It certainly LOOKS like something coming with the corporate backing of IBM/Redhat. This is the problem with how this change came to be. The optics are poor. They indicate that a few people (or companies) that are upset with some current politics are forcing the institution of significant change as of late (the recent push to deviate from FSF website standards is yet another subtle political maneuver with no technical merit other than "I don't like the FSF"). I'm sure that the people involved will say that it's perfectly on the level, and it well could be, but it doesn't APPEAR to be. The Steering Committee should take these issues seriously, be more transparent, and have a wider, more inclusive discussion of project policy and direction. >
Re: Update to GCC copyright assignment policy
On Mon, Jun 7, 2021, 06:12 Giacomo Tesio wrote: > The Steering Committee can avoid all of this, now. > I cannot really understand why they shouldn't. > Likely because the primary contributor to c++ has said he will stop contributing unless the change is made. >
Re: A suggestion for going forward from the RMS/FSF debate
On Fri, Apr 16, 2021 at 7:23 AM Ville Voutilainen via Gcc wrote: > On the first part, other people have touched on it already, > but the fear of a dreaded non-free software vendor co-opting > GCC as a library to a non-free project has resulted in GCC > being unsuitable to be used as a library in free software > projects. This approach alone made sure that the meteoric > rise of LLVM happened; there are recorded statements > from LLVM developers trying to talk about this to RMS, > and the answer, as they phrased it, "wasn't useful", because > RMS decided that GCC shouldn't be a library to make it > harder to use it in conjunction with non-free programs. > > Congratulations, it remains hard to use in conjunction > with free programs, and everybody who wants to do something > like that looks at LLVM first. RMS made a lofty attempt to > promote copyleft software for such purposes, and failed > miserably, leading us into a situation where such problems > are not solved with copyleft software, but with LLVM instead. I was under the (likely incorrect, please enlighten me) impression that the meteoric rise of LLVM had more to do with the license allowing corporate contributors to ship derived works in binary form without sharing proprietary code. Intel, IBM, nVidia, etc. are migrating towards LLVM for this purpose. To do so using GCC would (I believe; again, please correct me) require that they share more source code than they would have to under LLVM. This licensing model makes working on LLVM more attractive to companies that wish to keep proprietary code hidden, and thus LLVM garners a lot of corporate backing. It seems to me that technical differences (easier porting, or early claims of better diagnostics, for instance) and culture differences (let's just say that LLVM developers are more friendly, although I've never encountered a mean GCC developer) are not the driving force behind such strong support. As usual in the world, follow the money. If the idea is that GCC-as-a-Library would enable Intel, for example, to use GCC for their ICX OneAPI compiler the way they are now using LLVM, with significant portions of it hidden from the user, it seems to me that not supporting this is a very consistent GNU view. Allowing derived works that don't publish the full source code seems to be against the very spirit of GNU. If the GCC project opts to distance itself from various three letter acronyms, as a user, I have to wonder what that means in the future regarding the strict adherence to software freedoms that GCC has had for a long time now. I don't think I would suggest that there would be an immediate knee jerk reaction to change everything. Instead, it seems that https://en.wikipedia.org/wiki/Creeping_normality would take place to slowly change the "Freedom first" ideology over time. Maybe I'm jaded by the recent changes to CentOS, where RedHat applied a Microsoft tactic to embrace, extend, and extinguish it (at least in the form we previously knew). That took about ten years, but I can easily see how the same thing could happen over a long period of time to GCC (note that often when this has happened in history, including outside of the computing world, it was difficult or impossible to predict how it could end poorly. Padme's "thunderous applause" cheats, in that we saw the sequels first :) ) It would be good, therefore, to address upfront how the software freedoms of GCC users would be as consistently guaranteed in the future as they are now. Would a future GCC be committed to universally blocking any hypothetical positive technical improvement that also reduced user freedom?
Re: removing toxic emailers
On Thu, Apr 15, 2021, 23:42 Iain Sandoe via Gcc wrote: > it is essential (IMO) that review of code is carried out on a fair and > technical basis without personal attack or harrassment (or > unwelcome unrelated attention). > Is this not the case on gcc-patches? >
Re: GCC optimizations with O3
On Wed, Apr 22, 2020 at 10:25 AM Jakub Jelinek via Gcc wrote: > An -O? option is not just a set of suboptions it enables Maybe it should be. I notice this come up often enough at least.
