So that cproc -MD -c a.c -o obj/a.o produces obj/a.d instead of a.d.

A weird edge case is cproc -MD a.c b.c -o bin, which will create a bin.d
containing the deps for a.c, then overwrite it with the deps for only
b.c. Turns out that GCC and Clang behave the same way.
---
 driver.c | 43 +++++++++++++++++++++++++++++++++++++------
 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/driver.c b/driver.c
index 4f82644..32533cf 100644
--- a/driver.c
+++ b/driver.c
@@ -104,6 +104,17 @@ detectfiletype(const char *name)
[message trimmed]

When multiple of -E, -M, -emit-qbe, -S and -c are specified, always
select the one corresponding to the earliest build stage. This matches
GCC and Clang behavior, and makes it impossible to get the driver to
pass -M output to the compiler. Well, except for -MD -MF -, but the only
thing that could reasonably be done about that is displaying a better
error message, and cproc will eventually stop using an external
preprocessor anyway.
---
 driver.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/driver.c b/driver.c
index 853c20e..4f82644 100644
--- a/driver.c
[message trimmed]

---
Obtaining line contents in a very stupid way, but also probably the best
we can do given preprocessor shenanigans. Apart from the lack of special
handling for stdin / fake file names. _That said_,

$ gcc -xc -
x
<stdin>:1:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ at end of input
$ echo x > '<stdin>'
$ gcc -xc -
x
<stdin>:1:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ at end of input
    1 | x
      | ^
[message trimmed]

---
 cproc.1  | 2 +-
 driver.c | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/cproc.1 b/cproc.1
index 83e9fec..f3618c7 100644
--- a/cproc.1
+++ b/cproc.1
@@ -115,7 +115,7 @@ Do not search default compiler include paths when compiling.
 .It Fl pthread
 This is a short hand of
 .Fl lpthread .
-.It Fl g , Fl O , Fl pipe , Fl pedantic
[message trimmed]

Fixes e.g. cproc -lm -S a.c -o a.
---
v2: Dumb mistake in the commit message - the bug needs an explicit
output.

 driver.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/driver.c b/driver.c
index 2ead711..255903a 100644
--- a/driver.c
+++ b/driver.c
@@ -564,6 +564,16 @@ main(int argc, char *argv[])
 		stages[i].cmdbase = stages[i].cmd.len;
[message trimmed]

---
 cproc.1  | 2 +-
 driver.c | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/cproc.1 b/cproc.1
index 83e9fec..f3618c7 100644
--- a/cproc.1
+++ b/cproc.1
@@ -115,7 +115,7 @@ Do not search default compiler include paths when compiling.
 .It Fl pthread
 This is a short hand of
 .Fl lpthread .
-.It Fl g , Fl O , Fl pipe , Fl pedantic
[message trimmed]

Fixes e.g. cproc -lm -S a.c.
---
 driver.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/driver.c b/driver.c
index 2ead711..255903a 100644
--- a/driver.c
+++ b/driver.c
@@ -564,6 +564,16 @@ main(int argc, char *argv[])
 		stages[i].cmdbase = stages[i].cmd.len;
 	if (inputs.len == 0)
 		usage(NULL);
+	i = 0;
[message trimmed]

---
This is the quick and dirty implementation I came up with having not
looked at the code before. It could make sense to try to move the
pointer arithmetic logic from expr.c to qbe.c, since repurposing
EXPRSIZEOF for this feels weird. The caching in calcvla should
nonetheless ensure the length gets evaluated (only) at the right time.

Assuming that calling calcvla(e->type) at the top of funcexpr is correct
to begin with, that is. The relevant paragraphs in C23 are 6.5.4.5 and
6.8.4. The latter says:

> A full expression is an expression that is not part of another
> expression, nor part of a declarator or abstract declarator. There is
> also an implicit full expression in which the non-constant size
[message trimmed]

> > Also, this will break runtime array expansion, since harec abuses
> > memcpy for that.
> as of the state of the code in this patch, it doesn't break -- the end
> result of word-memcpy is identical to byte-memcpy for overlapping
> *aligned* regions:

Ah, you're probably right. However,

- Unaligned copies are rather common in I/O, etc, so doing those fast
  only 1/4 of the time is kind of lame. Most CPUs can do unaligned word
  copies just fine. Those cases will use memmove most of the time though,
  so I suppose memcpy could stay the way it is. :/ And if we intend to
  have arch-specific optimized memfuncs anyway, this can work fine as a
  lowest common denominator.

Also, this will break runtime array expansion, since harec abuses
memcpy for that.