From: Shaddy Baddah <lithium-cygwin@shaddybaddah.name>
To: cygwin@cygwin.com
Subject: Re: Odd hang of cc1.exe *now further isolated, potential console issues* cpp/gcc
Date: Wed, 29 Apr 2020 14:06:19 +1000 [thread overview]
Message-ID: <ccd57ee7-2679-45b4-c11d-73bd85a99744@shaddybaddah.name> (raw)
In-Reply-To: <0dc18394-6194-118a-d3f1-3055c51a352f@cs.umass.edu>
Hi Eliot,
On 28/4/20 10:46 pm, Eliot Moss wrote:
> Could it be a cygwin fork problem? Definitely possible
> in a 32-bit environment. I had to rebase all the time.
> Now that I'm mostly in the 64-bit environment it's not
> such an issue.
I suspected so and did trigger a rebaseall... it hasn't helped.
As mysterious as this problem is, I can't rule out fork issues, but I
have new information that suggests it might be something odd with
console/pty I/O???
So, if I run cc1 from bash, under a command prompt window, it will
will seemingly hang. However if I enter ctrl-d, the command resumes
and seems to run (I can't say if correct or not).
Here's what I mean:
| $ /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/cc1.exe -E -quiet -v -idirafter
/usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../lib/../include/w32api
-idirafter
/usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api
hello.c -mtune=generic -march=x86-64
<nothing happens>
<enter ctrl-d>
|
| Analyzing compilation unit
| Performing interprocedural optimizations
| <*free_lang_data> <visibility> <build_ssa_passes> <opt_local_passes>
<remove_symbols> <targetclone> <free-fnsummary> <emutls>Streaming LTO
| <whole-program> <fnsummary> <inline> <free-fnsummary>
<single-use>Assembling functions:
| <materialize-all-clones> <simdclone>
| Time variable usr sys
wall GGC
| phase setup : 0.01 (100%) 0.00 ( 0%)
0.01 ( 40%) 1224 kB ( 90%)
| phase opt and generate : 0.00 ( 0%) 0.00 ( 0%)
0.01 ( 28%) 2 kB ( 0%)
| TOTAL : 0.01 0.00
0.03 1357 kB
|
| $
If I try this in mintty, the ctrl-d isn't accepted, and the hard hang
continues. ctrl-c doesn't work, and I have to resort to killing
processes in taskmgr (haven't tried just using Cygwin kill. Can if it
makes a difference).
So, it seems like even though cc1 is probably not reading the console,
Windows things it needs events from that source for some reason??? It's
all a bit above my pay grade at the moment.
Also, for completeness, I went back to Cygwin DLL 3.0.6-1, and the
problem persisted. Mind you, until recent modifications to the desktop
(Windows updates, and whatever other agents pushed by corporate IT)
gcc/cc1 was working with 3.1 series DLLs... go figure :-(
Any ideas?
--
Regards,
Shaddy
next prev parent reply other threads:[~2020-04-29 4:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-27 6:54 Odd hang of cc1.exe, when invoking cpp/gcc Shaddy Baddah
2020-04-28 5:23 ` Odd hang of cc1.exe *now isolated somewhat* cpp/gcc Shaddy Baddah
2020-04-28 12:46 ` Eliot Moss
2020-04-29 4:06 ` Shaddy Baddah [this message]
2020-04-29 4:55 ` Odd hang of cc1.exe *now further isolated, potential console issues* cpp/gcc Marco Atzeri
2020-04-29 12:38 ` Odd hang of cc1.exe *now further isolated, back to a fork issue* cpp/gcc Shaddy Baddah
2020-05-06 14:29 ` Odd hang of cc1.exe *now isolated to /tmp weirdness* cpp/gcc Shaddy Baddah
2020-05-07 1:19 ` Doug Henderson
2020-05-07 3:44 ` Shaddy Baddah
2020-05-07 9:34 ` Odd hang of cc1.exe *resolved. /tmp/cygwin1.dll. Apologies * cpp/gcc Shaddy Baddah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ccd57ee7-2679-45b4-c11d-73bd85a99744@shaddybaddah.name \
--to=lithium-cygwin@shaddybaddah.name \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).