I understand you are irritated by the 1MB maximum. It’s possible we could get the admins to increase that, but it rarely is a problem in practice.
Well, that would be the best solution, isn’t it? I mean, 1MB, my desktop background-jpg is more than 1MB. I always use trunk (from the snapshot builds) and encounter ICE’s regularly. Most of them are triggered by me f’in up C++ syntax, so I let those pass [as in not report] (clang f’ed up, but so did I). But this one is clearly in the compiler-bug realm. The code compiles with VC and I don’t see any reason why it [clang] shouldn’t [compile it correctly].
Instead of creduce, I would first look at reducing the header-file overhead.
I do dual-boot my lap-top with Fedora-30 [I’m rather nix-green, though], I had a look, and they [dnf] don’t carry creduce either.
I had already reduced them to a max, but it pulls in this lib https://github.com/bluescarni/mppp , as you could see [in the issues], I raised it as an issue as well, there. The work-around is simple, but that does not take away from the fact clang-cl has one bug .
Can you reduce the number of headers in your source? Windows is particularly prone to pulling in boatloads of headers that you don’t actually need. If you do need all the headers in your original source, but you are including say <windows.h> along with everything else, there are some preprocessor symbols you can set to reduce that overhead and so (we hope) get the preprocessed source down to where you can file the bug.
If the clang project wants people to report bugs, it should not be necessary to jump through hoops. Most of the ‘volume’ of this file consists of annotations [comments] by clang itself, they are all kind of comments in fact, they seem useful, trying to get rid of them seems counter-productive.
But, since I still would like to ‘contribute’ my bug and since getting a bigger disk [to allow for bigger attachements] is not possible, I could host the files as gists on my github-account, or I could put them on paste-bin. Could that be a solution?