Build breakage
I am getting this failure to build from clean trunk.
In file included from ../../../../trunk/libgomp/config/linux/allocator.c:31:
../../../../trunk/libgomp/config/linux/allocator.c: In function
‘linux_memspace_alloc’:
../../../../trunk/libgomp/config/linux/allocator.c:70:26: error: format
‘%ld’ expects argument of type ‘long int’, but argument 3 has type
‘size_t’ {aka ‘unsigned int’} [-Werror=format=]
70 | gomp_debug (0, "libgomp: failed to pin %ld bytes of"
| ^
71 | " memory (ulimit too low?)\n", size);
|
| |
| size_t
{aka unsigned int}
../../../../trunk/libgomp/libgomp.h:186:29: note: in definition of macro
‘gomp_debug’
186 | (gomp_debug) ((KIND), __VA_ARGS__); \
| ^~~
../../../../trunk/libgomp/config/linux/allocator.c:70:52: note: format
string is defined here
70 | gomp_debug (0, "libgomp: failed to pin %ld bytes of"
| ~~^
||
|long int
| %d
Fwd: Hosting our gfortran MatterMost workspace
Forgot to copy the list on this. Forwarded Message Subject: Re: Hosting our gfortran MatterMost workspace Date: Fri, 5 May 2023 10:24:11 -0700 From: Jerry D To: Mark Wielaard On 4/29/23 5:36 AM, Mark Wielaard wrote: Hi, On Fri, Apr 28, 2023 at 08:55:44PM +0200, Bernhard Reutner-Fischer wrote: On 28 April 2023 18:46:07 CEST, Mark Wielaard wrote: OSUOSL already provides some machines for sourceware/gcc. If you could put a bit more technical details into that bugzilla issue, with expected usage (how many people, groups, moderation?) then we can coordinate and put it on the overseers agenda. Or you just ask Lance folks over there, but they'll need a ticket anyway. As long as there is a sensible IRC adapter I'm sure nobody would mind it. I'm not sure if anything ever happened to hosting these here, i only remember a quick poll some time ago locally. Just let us know what works best for you. If you feel it could be useful to the rest of the gcc/sourceware community we can coordinate through the overseers infrastructure ticket: https://sourceware.org/bugzilla/show_bug.cgi?id=29853 And we'll arrange a machine through Conservancy & OSUOSL. But if you are more comfortable setting something up just for the gfortran hackers and wanting to maintain it fully yourself then going directly to OSUOSL might be easier for you. Cheers, Mark I have sent an email to Lance at osuosl.org and Mark to see if we can get started on this. I am wondering how to migrate what we have now over to a new host. I will have to query the MatterMost web pages. Regards, Jerry
Hosting our gfortran MatterMost workspace
Hello all and gcc overseers, I received a notice that the MasterMost server providers decided to drop their free service. Unfortunate and understandable. I plan to contact the Open Software Lab folks at Oregon State University to see if they can host for us. If anyone else has any suggestions of possible places we can host an instance, please let me know. The software for the platform is open source many folks self host, so we can do this. I am not sure where gcc.gnu.org is hosted, but that might be a logical place. Best regards, Jerry
Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
On 1/30/23 5:46 AM, Sam James wrote: On 30 Jan 2023, at 06:27, Steve Kargl via Gcc wrote: Hi Steve, Please remove the skull and cross bones in the subject line. This is a sourceware project so I've CC'd the buildbot mailing list where we discuss these matters. Does the emoji bother you, or is it the skull and crossbones specifically (which is a recognised symbol for a hazard)? Note that this is the default upstream from the Buildbot project (we use their software) too. We haven't chosen it ourselves. Thanks, sam As long as your asking it just looks stupid, childish to think anyone needs an emoji in what we try think is a professional product. ( Too informal? ) If that's not enough, how about corny, or something for 12 year olds. Yep, it's just stupid. I don't have an issue with bots, I just don't need emojis outside of my personal chats on my phone. If it is suppose to be a notification, how about just the word "Alert" or "Notice" Regards, Jerry Jerry
Fwd: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
I had this show up today. I have no idea what this is about. Please advise. Jerry Forwarded Message Subject: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master) Date: Sun, 29 Jan 2023 19:31:23 + From: buil...@sourceware.org To: Jerry DeLisle A new failure has been detected on builder gcc-gentoo-sparc while building gcc. Full details are available at: https://builder.sourceware.org/buildbot/#builders/231/builds/210 Build state: failed configure (failure) Revision: 8011fbba7baa46947341ca8069b5a327163a68d5 Worker: gentoo-sparc-big Build Reason: (unknown) Blamelist: Jerry DeLisle Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/1/logs/stdio - 2: rm -rf gcc-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/2/logs/stdio - 3: configure ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/3/logs/stdio
Re: testsuite under wine
On 1/5/23 7:33 PM, Jacob Bachmeyer via Fortran 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*
*number* of CRs preceding each LF by the time the results reach the test
driver machine in more complex testing lab environments.
-- Jacob
Agree
Re: testsuite under wine
On 1/4/23 6:50 PM, NightStrike via Fortran 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:
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?
I have reproduced this test with C. I suspect that the 'write' function
was written to accommodate non standard behavior of windows which
expects a CR-LF. This means that POSIX compliant code is adjusted by
the C or gfortran libraries to emit a extra CR so that on Windows it
will just work ok. So the test is doing exactly what you are telling it
to do. An LF causes the run times to add a CR in front.
With libgfortran I remember implementing some of this code myself and
this is the reason, to keep applications happy on Windows.
So the gfortran tests we wrote to accept either a CR or a CR-LF, and in
the test code to only issue a normal line ending which on UNIX will be
an LF and Windows an CR-LF.
I lose track of details in between looking ta the test cases. let me
know one of them to study that is gfortran side and will see what it is
doing.
Jerry
Re: GCC GSoC 2022: Call for project ideas and mentors
Perhaps someone could work on completing and merging the shared memory (native) fortran coarrays branch. Regards, Jerry On 3/9/22 6:39 AM, Martin Jambor wrote: Hello, I am pleased that I can announce that GCC has been accepted as a mentoring organization of Google Summer of Code 2022. Contributors(*) will be applying from April 4th to April 19th but have already seen some announcing their intention to apply and asking for guidance when selecting a project and preparing their applications. Please continue helping them figure stuff out about GCC like you always do. If anyone still wants to add a project to our idea list (and sign up to be a potential mentor), now is the time to do it. I'm looking forward to another year of interesting projects, Martin (*) Contributors no longer have to be students - they should however be "new or beginner" contributors to our project with the exception that participants of GSoC 2020 or GSoC 2021 can apply. More on changes this year is in my original call for projects: https://gcc.gnu.org/pipermail/gcc/2022-January/238006.html
