https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90034
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90034
--- Comment #7 from Todd Freed ---
Submitted a bug report to bug-bi...@gnu.org, as this seems to be a recent
behavior change in bison. It did not used to produce an output which induced
the hang when invoked like,
bison -o /dev/stdout parser.y |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90034
--- Comment #6 from David Malcolm ---
(In reply to Andreas Schwab from comment #4)
> You get the resolve part for free by opening it.
Thanks.
I'm wondering what the best cross-platform test ought to be.
Maybe something like this to input.c's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90034
--- Comment #5 from David Malcolm ---
(gdb) call fileno(c->fp)
$3 = 4
(gdb) info inferior
Num Description Executable
* 1process 35251 /home/david/coding-3/gcc-git-bugfixing/build/gcc/cc1
(gdb) shell ls -al /proc/35251/fd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90034
--- Comment #4 from Andreas Schwab ---
You get the resolve part for free by opening it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90034
--- Comment #3 from David Malcolm ---
(In reply to Richard Biener from comment #2)
[...]
>
> Smaller testcase that will hang:
>
> #line 1 "/dev/stdout"
> #def xy
Presumably we're blocked, waiting on ourselves to write something to our
stdout s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90034
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
