Menu
▾
▴
#853 MinGW-w64 8.0.0 fails with printf format errors in libgomp/target.c and libgomp/oacc-parallel.c
I'm just tried to build GCC 10.2.0 against MinGW-w64 8.0.0 (in MSYS2 shell on Windows 10) and got errors about printf format using these definitions in inttypes.h:
#if defined(_UCRT) || __USE_MINGW_ANSI_STDIO
#define PRId64 "lld"
#define PRIi64 "lli"
#define PRIo64 "llo"
#define PRIu64 "llu"
#define PRIx64 "llx"
#define PRIX64 "llX"
#else
#define PRId64 "I64d"
#define PRIi64 "I64i"
#define PRIo64 "I64o"
#define PRIu64 "I64u"
#define PRIx64 "I64x"
#define PRIX64 "I64X"
#endif
It appears the definition from the first block were used, while it should have been the second block.
I was able to work around this by editing libgomp/target.c and libgomp/oacc-parallel.c replacing # include <inttypes.h> with # undef HAVE_INTTYPES_H.
I know this is a workaround, not a solution, but it does allow me to build the entire gcc toolchain.
So probably a better fix is required.
Related
Similar issues building win64 build of pkg-config.
There I got it to build by adding
#define __USE_MINGW_ANSI_STDIO 0at the top ofglib/glib/gslice.c.Did something change to the definition of
__USE_MINGW_ANSI_STDIOin MinGW-w64 v8.0.0?It looks to me like the relevant change was bfd33f6c0ec5e652cc9911857dd1492ece8d8383 (later modified by 8649bf9ef600e78da2396a99a0c6e2941a82d809).
I wonder if
__MSVCRT_VERSION__ < 0xE00should be
__MSVCRT_VERSION__ >= 0xE00See https://sourceforge.net/p/mingw-w64/mingw-w64/ci/8649bf9ef600e78da2396a99a0c6e2941a82d809/
Last edit: mark 2020-09-20
Hello,
Sorry for telling you, but your assumptions about passing va_list as
argument, and how it behalfs is plain wrong. So your test-code is
invalid. Why you assume that a local variable va is modified under
the hood by a different function? As long as you don't pass reference
to it, you are not able to modify its contents for an outer function.
int foo(va_list argp)
{
return va_arg(argp, int);
}
void zoo(const char *fmt, ...)
{
va_list argp;
argp=va_start(argp, fmt);
fprintf(stderr, fmt, foo(argp), foo(argp));
}
int main()
{
zoo("%d", 12, 64);
return 0;
}
will of course display 24, and not - as you were assuming - 76. Btw
it is absolutely irrelevant how many subs you are putting here
inbetween of zoo and foo ...
Cheers,
Kai
Am So., 20. Sept. 2020 um 13:17 Uhr schrieb mark
mabrand@users.sourceforge.net:
Related
Bugs: #853
@ktietz70 I'm sorry, but I'm not following where you think this wrong assumtion was made. Is this in both gcc and pkg-config source code? Or are you referring to some other code?
Hmm, sorry. I mixed your report up. There was another report with
code sample, which claimed that va_list would be broken.
Sorry about that. Nevertheless you should report this to gcc people
too. As it is more a target-library issue in gcc AFAICS.
Regards,
Kai
Am Mo., 28. Sept. 2020 um 15:27 Uhr schrieb Brecht Sanders
brechtsanders@users.sourceforge.net:
Related
Bugs: #853
Is there any progress on this issue?
Seems that this is a bug in libgomp/gcc project as it incorrectly uses printf format attribute. There is already patch for it:
https://github.com/msys2/MINGW-packages-dev/blob/master/mingw-w64-gcc-git/0020-libgomp-Don-t-hard-code-MS-printf-attributes.patch