[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85906 --- Comment #8 from Jan Niklas Hasse --- Thanks! If I understand it correctly this will go into 8.1.2?
[Bug libfortran/85906] New: Conditional jump depends on uninitialized value in write_decimal / write_integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85906 Bug ID: 85906 Summary: Conditional jump depends on uninitialized value in write_decimal / write_integer Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jhasse at bixense dot com Target Milestone: --- Created attachment 44177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44177=edit Initialize f->format in write_integer r256034 modified write_integer to use write_decimal. In write_decimal (write.c:808) the following line m = f->format == FMT_G ? -1 : f->u.integer.m; checks format of the fnode struct. write_integer doesn't initialize that member which results in a valgrind error "conditional jump or move depends on uninitialized value". The attached patch simply sets f->format to FMT_NONE in write_integer.
[Bug driver/80271] Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80271 --- Comment #2 from Jan Niklas Hasse --- I guess that's because one doesn't want the build output to depend on an environment variable (most build systems won't rebuild on env variable changes)? -fdiagnostics-color doesn't affect the build output, therefore it would be a perfect fit for an env variable. Currently adding it causes an unnecessary full rebuild.
[Bug driver/80271] New: Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80271 Bug ID: 80271 Summary: Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: jhasse at bixense dot com Target Milestone: --- When piping gcc, colored output gets disabled because isatty returns false. But for many people this is the normal way of running gcc, as most build systems (e. g. ninja or Waf) and build servers (e. g. Drone or Jenkins) pipe it to print its output delayed. In these cases ANSI colors would still work though and therefore many people set -fdiagnostics-color=always (see https://github.com/KDE/extra-cmake-modules/commit/dc525a42ae70a68d67aa49d6453d4b6de4ecb561 for example). It would be nice, if there would be a better way to auto detect that case. An environment variable would be a good choice, as build tools, build servers or IDEs with ANSI escape code support can set it. The name CLICOLOR_FORCE was chosen, because it is already used by some tools and a unified naming for this would be nice. See https://bixense.com/clicolors/ (A flag like -fdiagnostics-color also has the disadvantage that changes trigger a complete rebuild in most build system although the flag doesn't influence the object code output.)
[Bug c++/77277] -fdiagnostics-color=always disabled on _WIN32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77277 Jan Niklas Hasse changed: What|Removed |Added CC||jhasse at bixense dot com --- Comment #2 from Jan Niklas Hasse --- Maybe this patch can simply be upstreamed? https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc/0017-diagnostic-color.patch I've been using GCC on Window with it for a few months and it works fine :)
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #8 from Jan Niklas Hasse --- I'm not interested in doing all this work again from scratch, especially since working with the Windows API is a pain.
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #6 from Jan Niklas Hasse --- > Yes. Okay thanks, I'll look into it. > You can't copy any code, that would be a copyright violation. It's OK to see > which Windows API functions Boost uses for a particular filesystem > operation, but if you're not sure what is covered by copyright law then it's > safer not to use another project at all. According to https://www.gnu.org/licenses/license-list.html the Boost License is GPL compatible. So when I mark the code I copied with the source, it should work, shouldn't it? > I was hoping that somebody who actually knows the Windows API would > contribute the code, so they already know what the appropriate functions are. I know the Windows API, but the details are hard to get right. Especially getting everything to be bug-free. Many man hours have already been spend on boost::filesystem and the API is similar to std::filesystem. Why should I re-invent the wheel?
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #4 from Jan Niklas Hasse --- > Great! Please read > https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html > especially the part about legal paperwork. Do you mean the part about legal paperwork in https://gcc.gnu.org/contribute.html ? > No. Just look at the existing code and figure out what the equivalent code > would be for Windows, and write an alternative implementation e.g. replace > calls to POSIX stat() with whatever Windows uses to query file properties, > and replace calls to POSIX chmod with whatever Windows uses to change file > permissions. And can I look at how boost::filesystem does this?
[Bug libstdc++/78870] Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #2 from Jan Niklas Hasse --- I'm willing to help. Is there an existing starting point for Windows? Can boost::filesystem's implementation be used?
[Bug libstdc++/78870] New: Support std::filesystem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 Bug ID: 78870 Summary: Support std::filesystem on Windows Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jhasse at bixense dot com Target Milestone: --- Currently std::experimental::filesystem / stdc++fs is missing in MSYS2 / MinGW (tested with GCC 6.2.0).
