[Bug libstdc++/115122] New: Incorrect detection of C99 support when cross-compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115122 Bug ID: 115122 Summary: Incorrect detection of C99 support when cross-compiling Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 58219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58219=edit docker file that reproduces the problem (libstdc++ doesn't use C99 complex functions which are available) When cross-compiling a native toolchain, configuration of libstdc++ incorrectly concludes that there is no C99 support (which then triggers Bug 115117). I've ran into this when building a native toolchain (to run on Windows, produce code for Windows) on a Linux machine. Configure in libstdc++ builds a test program as follows: x86_64-w64-mingw32-c++ -L/opt/gcc-mingw/native/x86_64-w64-mingw32/lib -L/opt/gcc-mingw/native/mingw/lib -isystem /opt/gcc-mingw/native/x86_64-w64-mingw32/include -isystem /opt/gcc-mingw/native/mingw/include -o conftest.exe -g -O2 -std=c++11 -fno-exceptions conftest.cpp -lm >&5 so, it tries to build the configure test using the cross-compiler, including the "-std=c++11" argument but not including "-nostdinc++". That way, C99 functions would appear not available, and the test would fail. I've attached a docker file that reproduces the problem. It ends by showing that "c++config.h" ends up with undefined _GLIBCXX11_USE_C99_COMPLEX and also copies the corresponding lines from the config.log of libstdc++. The docker file also builds a cross-compiler (to cross-compile the native compiler), so one can see that in the cross-compilation, the configure tests run as /build/gcc/build-x86_64/./gcc/xgcc -shared-libgcc -B/build/gcc/build-x86_64/./gcc -nostdinc++ -L/build/gcc/build-x86_64/x86_64-w64-mingw32/libstdc++-v3/src -L/build/gcc/build-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/build/gcc/build-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/opt/gcc-mingw/x86_64-w64-mingw32/lib -L/opt/gcc-mingw/mingw/lib -isystem /opt/gcc-mingw/x86_64-w64-mingw32/include -isystem /opt/gcc-mingw/mingw/include -B/opt/gcc-mingw/x86_64-w64-mingw32/bin/ -B/opt/gcc-mingw/x86_64-w64-mingw32/lib/ -isystem /opt/gcc-mingw/x86_64-w64-mingw32/include -isystem /opt/gcc-mingw/x86_64-w64-mingw32/sys-include-o conftest.exe -g -O2 -std=c++11 -fno-exceptions conftest.cpp -lm >&5 and succeeds. Note, it uses "-nostdinc++".
[Bug libstdc++/115117] New: std::exp(Inf) result invalid with --disable-c99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115117
Bug ID: 115117
Summary: std::exp(Inf) result invalid with --disable-c99
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
Created attachment 58218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58218=edit
Example program ("im(e^inf):" should be 0, but is not with --disable-c99)
When the C++ library is built without C99 support (e.g. via passing
--disable-c99 to configure of gcc), the result of complex std::exp(Inf) is
incorrect, the imaginary part is NaN, but it should be zero.
It seems this is caused by this code in "complex", which doesn't handle special
cases:
// 26.2.8/3 exp(__z): Returns the complex base e exponential of x
template
inline complex<_Tp>
__complex_exp(const complex<_Tp>& __z)
{ return std::polar<_Tp>(exp(__z.real()), __z.imag()); }
that calls into:
template
inline complex<_Tp>
polar(const _Tp& __rho, const _Tp& __theta)
{
__glibcxx_assert( __rho >= 0 );
return complex<_Tp>(__rho * cos(__theta), __rho * sin(__theta));
}
where __rho is Inf, so the imaginary part becomes Inf * 0.
For example, the glibc implementation handles this special case explicitly as
follows (./math/s_cexp_template.c):
else if (__glibc_likely (rcls == FP_INFINITE))
{
/* Real part is infinite. */
if (__glibc_likely (icls >= FP_ZERO))
{
/* Imaginary part is finite. */
FLOAT value = signbit (__real__ x) ? 0 : M_HUGE_VAL;
if (icls == FP_ZERO)
{
/* Imaginary part is 0.0. */
__real__ retval = value;
__imag__ retval = __imag__ x;
}
I've this problem happen via _GLIBCXX11_USE_C99_COMPLEX being disabled by
accident, which still has to be investigated, but --disable-c99 reproduces it.
Example program from Andrew Johnson is attached.
I can reproduce the problem on Windows and Linux (on Windows I get nan, on
Linux I get -nan).
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #22 from Tomas Kalibera ---
(In reply to CVS Commits from comment #21)
> The master branch has been updated by Jonathan Yong :
>
> https://gcc.gnu.org/g:966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
>
> commit r14-3334-g966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
> Author: Tomas Kalibera
> Date: Sun Aug 20 02:16:16 2023 +
>
> Fix format attribute for printf
>
> Since a long time (GCC 4.4?) GCC does support annotating functions
> with either the format attribute "gnu_printf" or "ms_printf" to
> distinguish between different format string interpretations.
>
> However, it seems like the attribute is ignored for the "printf"
> symbol; regardless what the function declaration says, GCC treats
> it as "ms_printf". This has become an issue now that mingw-w64
> supports using the UCRT instead of msvcrt.dll, and in this case
> the stdio functions are declared with the gnu_printf attribute,
> and inttypes.h uses the same format specifiers as in GNU mode.
>
> A reproducible example of the problem:
>
> $ cat format.c
> __attribute__((__format__ (gnu_printf, 1, 2))) int printf (const char
> *__format, ...);
> __attribute__((__format__ (gnu_printf, 1, 2))) int othername (const char
> *__format, ...);
>
> void function(void) {
> long long unsigned x = 42;
> othername("%llu\n", x);
> printf("%llu\n", x);
> }
> $ x86_64-w64-mingw32-gcc -c -Wformat format.c
> format.c: In function 'function':
> format.c:7:15: warning: unknown conversion type character 'l' in format
> [-Wformat=]
> 7 | printf("%llu\n", x);
> | ^
> format.c:7:12: warning: too many arguments for format
> [-Wformat-extra-args]
> 7 | printf("%llu\n", x);
> |^~~~
>
> Note how both functions, printf and othername, are declare with
> identical gnu_printf format attributes - GCC does take this into
> account for "othername" and doesn't produce a warning, but GCC
> seems to disregard the attribute in the printf declaration and
> behave as if it was declared as ms_printf.
>
> If the printf function declaration is changed into a static inline
> function, the actual attribute used is honored though.
>
> gcc/c-family/ChangeLog:
>
> PR c/95130
> * c-format.cc: skip default format for printf symbol if
> explicitly declared by prototype.
>
> Signed-off-by: Tomas Kalibera
> Signed-off-by: Jonathan Yong <10wa...@gmail.com>
Great, thanks a lot for finishing and adding this,
Tomas
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #20 from Tomas Kalibera --- (In reply to Julian Waters from comment #19) > (In reply to Tomas Kalibera from comment #17) > > (In reply to Tomas Kalibera from comment #16) > > > (In reply to Julian Waters from comment #15) > > > > It seems like the patch also doesn't fix the strftime case too, > > > > strangely > > > > enough. gcc with that patch applied still causes a compilation failure > > > > in > > > > the Windows JDK when encountering strftime with the %T specifier > > > > > > > > > I don't easily see why the patch doesn't help with %T in strftime. In > > > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so > > > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format > > > attribute is present. > > > > The older version of the patch I use with gcc 12 doesn't seem to be helping > > with %T, but the newer one (patch_master.diff) helps with %T on the current > > gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with > > MinGW-W64 11.0.1. > > If I may ask, could I have the link to patch_master.diff? It is one of the attachments of this report, https://gcc.gnu.org/bugzilla/attachment.cgi?id=53778 This patch has not been reviewed. I am not an expert on GCC internals and I cannot guarantee that adding meta-data this way to the AST is safe. So please use with care.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #17 from Tomas Kalibera --- (In reply to Tomas Kalibera from comment #16) > (In reply to Julian Waters from comment #15) > > It seems like the patch also doesn't fix the strftime case too, strangely > > enough. gcc with that patch applied still causes a compilation failure in > > the Windows JDK when encountering strftime with the %T specifier > > > I don't easily see why the patch doesn't help with %T in strftime. In > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format > attribute is present. The older version of the patch I use with gcc 12 doesn't seem to be helping with %T, but the newer one (patch_master.diff) helps with %T on the current gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with MinGW-W64 11.0.1.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #16 from Tomas Kalibera --- (In reply to Julian Waters from comment #15) > It seems like the patch also doesn't fix the strftime case too, strangely > enough. gcc with that patch applied still causes a compilation failure in > the Windows JDK when encountering strftime with the %T specifier Given that this bug hasn't attracted enough attention to get fixed, perhaps you could try reporting this as a wish for improvement of the ms_strftime format (msformat-c.c, ms_time_char_table): probably it should support %T. I don't easily see why the patch doesn't help with %T in strftime. In MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format attribute is present.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #13 from Tomas Kalibera --- Another instance of this problem is %z (to print size_t). It is supported by UCRT, but the GCC's Microsoft format warns, because it wasn't supported with MSVCRT (seen with GCC 12.2).
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 Tomas Kalibera changed: What|Removed |Added Attachment #52007|0 |1 is obsolete|| --- Comment #12 from Tomas Kalibera --- Created attachment 53778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53778=edit Draft patch to ignore built-in format attribute for a builtin, if there is another one This is a draft of an alternative patch, which addresses the concern that in theory the built in format attribute may not be the first one in the list of attributes of a built-in function. This patch puts attribute flags inside TREE_PURPOSE of the attribute, so that it can be checked later whether it is a built in attribute. I am not sure whether this is legal, but it should be easy to update it to store the flags somewhere else, if needed.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #11 from Tomas Kalibera --- (In reply to LIU Hao from comment #10) > (In reply to Tomas Kalibera from comment #7) > > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches > > mailing list in May: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html > > > > The patches still apply to current 10,11,12 and trunk. Please see the email > > linked above for more information. > > > Thanks for the patch. Updated locally. I will test it against trunk as soon > as I get a little time. Thanks. Re Jeff's comment from the mailing list: > I guess we're going to depend on the builtin-format always appearing > first in the chain? While it's probably true in practice, I doubt we > really want to depend on that. > > Is there any sensible way to distinguish between the builtin format and > one that comes from the source? I didn't find any elegant way to find out whether a format attribute is a built-in attribute in check_function_format(). So unless I overlooked something (which is very much possible), it would make the patch more intrusive. handle_format_attribute() has that information in flags (ATTR_FLAG_BUILT_IN). Maybe handle_format_attribute() could add the flags (or only a boolean whether it is a builtin attribute) to the attribute tree, so that check_function_format() can access it, e.g. similarly to how no_sanitize does it. Would this be better? And if so, is there a recommended place in the format attribute tree where it should be added to?
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #9 from Tomas Kalibera --- (In reply to Martin Storsjö from comment #8) > (In reply to Tomas Kalibera from comment #7) > > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches > > mailing list in May: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html > > > > The patches still apply to current 10,11,12 and trunk. Please see the email > > linked above for more information. > > Did you notice the review comment in July, > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/59.html? Ah, thanks, I missed it (as I wasn't on the to/cc).
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #7 from Tomas Kalibera --- I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches mailing list in May: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html The patches still apply to current 10,11,12 and trunk. Please see the email linked above for more information.
[Bug tree-optimization/105198] [9/10 Regression] Wrong code for C loop (GCC 12 -O2, GCC 11 -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198 --- Comment #11 from Tomas Kalibera --- Thanks for the very quick fix! I confirm that when R is built with the fixed version of GCC 12, the R testcase for MASS is fixed, it works with -O2.
[Bug middle-end/105198] New: Wrong code for C loop (GCC 12 -O2, GCC 11 -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198
Bug ID: 105198
Summary: Wrong code for C loop (GCC 12 -O2, GCC 11 -O3)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
Created attachment 52770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52770=edit
Reproducible example to compile and execute (see comment in file)
It seems that GCC produces wrong code for function next_set found in R package
MASS (traced down by Brian Ripley):
static void next_set(int *x, int n, int k)
{
int i, j, tmp;
j = k - 1;
tmp = x[j]++;
while(j > 0 && x[j] >= n - (k - 1 -j)) tmp = ++x[--j];
for(i = j+1; i < k; i++) x[i] = ++tmp;
}
The attached standalone example reproduces the problem on a slightly modified
and instrumented variant of the function, for one specific input, see comments
in the code.
Correct output (GCC 12 -O1, and can be seen from the C code):
n == 5, k == 3, x == 0 1 4
tmp == 2, j == 1, x == 0 2 5
Incorrect but seen on x86_64/Linux (GCC 12 -O2, GCC 11 -O3):
n == 5, k == 3, x == 0 1 4
tmp == 4, j == 2, x == 0 1 5
One can modify the example to get slightly simpler native code via writing to
the array in "main" via volatile variables.
It works with GCC 10 -O3.
[Bug target/103465] [12 regression] -freorder-blocks-and-partition broken on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #28 from Tomas Kalibera --- I've also tested the patch with GCC 10.3 (with several backports from gcc10 branch plus some minor fixes, https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/plugins/gcc10/). I've built a cross-compiler and built R using it and ran the R regression testsuite (check-all), with -O2. No issues found. The same testsuite was previously triggering Bug 103274.
[Bug target/103465] [12 regression] -freorder-blocks-and-partition broken on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #27 from Tomas Kalibera --- > > should do the job. Tomas, can you give it a try? > > Thanks, so far I tried it only on predict-22.c and it works (with a fixed > comma as below), enables the optimization. I will do more testing tomorrow. I've tested with gcc12 (6aa0859afaf28f4fb13121352225bc5877e02a44) gcc11 (a03aae8d9f5dbfe3ca3dbfe7eadc6bbe6fbbe1bc) gcc10 (48e0da239f65b7cfa0e6f51f266c2e04f5ad9bbd) I confirm that with the patch applied: * the original bug report about invalid note about '-freorder-blocks-and-partition' is fixed * the optimization is applied by default at -O3, -O2 and can be enabled at -O1 via -f * the optimization can be disabled via -fno- and via pragma * -Q --help=optimizers issue for the option goes away, so "fixed" (though as I understand from Martin other optimizations still disabled by target will incorrectly appear as enabled) So with this patch applied, I am happy for this bug report to be closed. Thanks to both of you.
[Bug target/103465] [12 regression] -freorder-blocks-and-partition broken on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #26 from Tomas Kalibera ---
> should do the job. Tomas, can you give it a try?
Thanks, so far I tried it only on predict-22.c and it works (with a fixed comma
as below), enables the optimization. I will do more testing tomorrow.
diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index 0769a78a87c..f3559373433 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretypes.h
@@ -228,15 +228,17 @@ enum stack_protector {
SPCT_FLAG_EXPLICIT = 4
};
-/* Types of unwind/exception handling info that can be generated. */
+/* Types of unwind/exception handling info that can be generated.
+ Note that a UI_TARGET (or larger) setting is considered to be
+ incompatible with -freorder-blocks-and-partition. */
enum unwind_info_type
{
UI_NONE,
UI_SJLJ,
UI_DWARF2,
- UI_TARGET,
- UI_SEH
+ UI_SEH,
+ UI_TARGET
};
/* Callgraph node profile representation. */
[Bug driver/103465] [12 regression] -freorder-blocks-and-partition broken on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #24 from Tomas Kalibera --- FWIW, predict-22.c from GCC test suite is an example for which reorder-blocks-and-partition has an effect (creates foo.cold) in GCC trunk, up to but excluding https://gcc.gnu.org/g:a187edd2b437fc9571d57f771a624963fcce08f8 The repro example I used for Bug 103274 (a.c) is not good for testing this problem in the trunk, because the optimization is not applied on that specific example already since https://gcc.gnu.org/g:cd5ae148c47c6dee05adb19acd6a523f7187be7f
[Bug c/92292] duplicate -Wformat warnings about incorrect printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292 Tomas Kalibera changed: What|Removed |Added CC||tomas.kalibera at gmail dot com --- Comment #6 from Tomas Kalibera --- For reference, Bug 95130 is an instance of the same underlying issue (yet where the formats are different), with a proposed patch.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #5 from Tomas Kalibera --- (In reply to jos...@codesourcery.com from comment #1) > See bug 92292. The extra attribute isn't ignored, it simply means the > function has multiple format attributes, which is valid, but should > probably be special-cased for this case of built-in functions. I've added a draft of a patch to address the issue in the suggested way. I've tested it in gcc 10.3.0 on the example from comment 2 (also attached). With the patch applied, only line (2) gets a warning, as it should. When deciding whether to emit a format warning for a function with multiple format attributes, it skips the first format in case it is a builtin known to have a format added by gcc. Please let me know if you have any advice how to improve (thanks to Martin Liska for helping me with identifying the builtins), or indeed feel free to adjust and add your way. Fixing this would help the R community or anyone else who uses GCC with UCRT. Thanks, Tomas
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #4 from Tomas Kalibera --- Created attachment 52008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52008=edit Example from comment 2
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 --- Comment #3 from Tomas Kalibera --- Created attachment 52007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52007=edit Patch to ignore first format for builtins that have more than one This patch for 10.3.0 instructs gcc to ignore the first format attribute for functions that have multiple format attributes and are builtins with a format attribute added by GCC.
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #14 from Tomas Kalibera --- Created attachment 51962 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51962=edit example for comment 1 and 13
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #13 from Tomas Kalibera ---
(In reply to Martin Liška from comment #12)
> > So, still, the reorder-stacks-and-partition optimization is not dropped by
> > target (though I am not claiming they should be dropped, I don't know,
> > that's only what I learned from your response to my original report).
>
> I see. Can you see the following note:
>
> "%<-freorder-blocks-and-partition%> does not work "
> "with exceptions on this architecture");
>
> w/ -freorder-blocks-and-partition option used?
Not with
x86_64-w64-mingw32-gcc -c -O3 -freorder-blocks-and-partition a.c
but I do (the variant for C) with the original example for this bug report
x86_64-w64-mingw32-gcc -c -O3 -freorder-blocks-and-partition uwi.c -Wall
uwi.c:3:9: note: '-freorder-blocks-and-partition' does not support unwind info
on this architecture
3 | #pragma GCC optimize ("unroll-loops")
| ^~~
uwi.c:5:1: note: '-freorder-blocks-and-partition' does not support unwind info
on this architecture
5 | int main(int argc, char **argv) {
| ^~~
this original example (uwi.c) has an GCC optimize pragma:
#include
#pragma GCC optimize ("unroll-loops")
int main(int argc, char **argv) {
printf("Hello 1\n");
printf("Hello 2\n");
printf("Hello 3\n");
return 0;
}
For C++ I get the note with "does not work with exceptions on this
architecture"
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #10 from Tomas Kalibera --- (In reply to Tomas Kalibera from comment #7) > (In reply to Martin Liška from comment #5) > > > However, still talking about the current master only, I see a difference > > > with -O3, when I try on the repro example from Bug 103274 and -O3: > > > > > > x86_64-w64-mingw32-gcc -c -S -O3 -fno-reorder-blocks-and-partition a.c -o > > > nropt.s > > > > > > x86_64-w64-mingw32-gcc -c -S -O3 -freorder-blocks-and-partition a.c -o > > > ropt.s > > > x86_64-w64-mingw32-gcc -c -S -O3 a.c -o noopt.s > > > > > > All of these assembler files are different (and from my non-expert > > > reading, > > > noopt.s uses the optimization and does have the invalid unwind information > > > as reported in Bug 103274). Is the optimization correctly dropped also > > > with > > > -O3 only? > > > > Hmmm, I've just tested the same with the locally built cross-compiler: > > ~/Programming/gcc/configure --enable-languages=c,c++ > > --prefix=/home/marxin/bin/gcc --disable-multilib --enable-host-shared > > --disable-libsanitizer --enable-valgrind-annotations --disable-bootstrap > > --target=x86_64-w64-mingw32 > > > > and it works fine, all 3 assembly files are identical. > It tried on the current GCC trunk as now (747380f47da0da6c11fd5262ac428bb53433ea19). ropt.s is still the same as noopt.s. The unwinding information is correct now, because Bug 103274 has been fixed in the meantime. However, indeed, the reordering optimization is applied. nropt.s has correct unwinding information without the reordering. So, still, the reorder-stacks-and-partition optimization is not dropped by target (though I am not claiming they should be dropped, I don't know, that's only what I learned from your response to my original report). For these results I've only changed the git version in the dockerfile.
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #9 from Tomas Kalibera --- Created attachment 51959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51959=edit Dockerfile for comment 7 Dockerfile to reproduce behavior in comment 7. To be placed in a fresh directory with a.c. The output files will appear in /build/out in the container. The Dockerfile is based on an earlier copy (reproducing something else) I got from Martin Storsjo.
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #8 from Tomas Kalibera --- Created attachment 51958 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51958=edit Example for comment 7. Example for Dockerfile for comment 7. To be placed in a new directory with that Dockerfile.
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #7 from Tomas Kalibera --- (In reply to Martin Liška from comment #5) > > However, still talking about the current master only, I see a difference > > with -O3, when I try on the repro example from Bug 103274 and -O3: > > > > x86_64-w64-mingw32-gcc -c -S -O3 -fno-reorder-blocks-and-partition a.c -o > > nropt.s > > > > x86_64-w64-mingw32-gcc -c -S -O3 -freorder-blocks-and-partition a.c -o > > ropt.s > > x86_64-w64-mingw32-gcc -c -S -O3 a.c -o noopt.s > > > > All of these assembler files are different (and from my non-expert reading, > > noopt.s uses the optimization and does have the invalid unwind information > > as reported in Bug 103274). Is the optimization correctly dropped also with > > -O3 only? > > Hmmm, I've just tested the same with the locally built cross-compiler: > ~/Programming/gcc/configure --enable-languages=c,c++ > --prefix=/home/marxin/bin/gcc --disable-multilib --enable-host-shared > --disable-libsanitizer --enable-valgrind-annotations --disable-bootstrap > --target=x86_64-w64-mingw32 > > and it works fine, all 3 assembly files are identical. I am uploading a Dockerfile and my copy of the example which reproduces my observation, but please note, it was for 5e5f880d0452ef2cffb94f4a686d56833c9f4215. nropt.s has (correct unwind info, no reordering) .L5: callmyerrorcall nop .seh_endproc but ropt.s is same as noopt.s (incorrect unwind info, reordering) .L5: callmyerrorcall .seh_endproc [...] dummy.cold: .L19: So, from my reading the optimization was applied at -O3, it hence wasn't dropped by target.
[Bug target/103274] [10/11/12 regression] remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 --- Comment #12 from Tomas Kalibera --- I've tested with GCC 10.3 with R. R can be built and passes its tests (without the patch, it crashes). Also, I've checked the generated assembly with an awk script looking for a call instruction immediately followed by .seh_endproc. I didn't find any (while there were many without the patch, based on one the attached example was created). Thanks for the fix.
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #4 from Tomas Kalibera ---
(In reply to Martin Liška from comment #3)
> Let's speak about the current master:
>
> > With "12.0" (5e5f880d0452ef2cffb94f4a686d56833c9f4215), the note is not
> > emitted with -fno-reorder-blocks-and-partition, however, the other problem
> > remains. The note is still not emitted when the optimization is enabled
> > implicitly via -O2.
>
> I see:
>
> /xgcc -B. /home/marxin/Programming/testcases/pr103465.c -c -O2
> -freorder-blocks-and-partition
> /home/marxin/Programming/testcases/pr103465.c:2:9: note:
> ‘-freorder-blocks-and-partition’ does not support unwind info on this
> architecture
> 2 | #pragma GCC optimize ("unroll-loops")
> | ^~~
> /home/marxin/Programming/testcases/pr103465.c:4:1: note:
> ‘-freorder-blocks-and-partition’ does not support unwind info on this
> architecture
> 4 | int main(int argc, char **argv) {
> | ^~~
>
> which seems correct to me. With only -O2 there's no note emitted and the
> flags are properly dropped (same in -freorder-blocks-and-partition):
>
> $ cat -n gcc/opts.c
> ...
> 1133if (opts->x_flag_unwind_tables
> 1134&& !targetm_common.unwind_tables_default
> 1135&& opts->x_flag_reorder_blocks_and_partition
> 1136&& (ui_except == UI_SJLJ || ui_except >= UI_TARGET))
> 1137 {
> 1138if (opts_set->x_flag_reorder_blocks_and_partition)
> 1139 inform (loc,
> 1140 "%<-freorder-blocks-and-partition%> does not support
> "
> 1141 "unwind info on this architecture");
> 1142opts->x_flag_reorder_blocks_and_partition = 0;
> 1143opts->x_flag_reorder_blocks = 1;
> 1144 }
>
> So what's wrong with that, please?
Thanks for looking into this. I didn't realize an optimization can be dropped
silently - I only checked
x86_64-w64-mingw32-gcc -O2 -Q --help=optimizers
and that said "enabled". Sorry for that.
However, still talking about the current master only, I see a difference with
-O3, when I try on the repro example from Bug 103274 and -O3:
x86_64-w64-mingw32-gcc -c -S -O3 -fno-reorder-blocks-and-partition a.c -o
nropt.s
x86_64-w64-mingw32-gcc -c -S -O3 -freorder-blocks-and-partition a.c -o ropt.s
x86_64-w64-mingw32-gcc -c -S -O3 a.c -o noopt.s
All of these assembler files are different (and from my non-expert reading,
noopt.s uses the optimization and does have the invalid unwind information as
reported in Bug 103274). Is the optimization correctly dropped also with -O3
only?
[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #2 from Tomas Kalibera --- (In reply to Martin Liška from comment #1) > I can take a look, what's the target please? Thanks, x86_64-w64-mingw32 (with UCRT as the CRT, but that probably does not matter).
[Bug rtl-optimization/103465] New: Invalid note with -fno-reorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
Bug ID: 103465
Summary: Invalid note with -fno-reorder-blocks-and-partition
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
With GCC 10.3.0 and 11.2.0, compiling this example with
-O2 -fno-reorder-blocks-and-partition
for Windows emits a note
uwi.c:3:9: note: '-freorder-blocks-and-partition' does not support unwind info
on this architecture
3 | #pragma GCC optimize ("unroll-loops")
| ^~~
uwi.c:5:1: note: '-freorder-blocks-and-partition' does not support unwind info
on this architecture
5 | int main(int argc, char **argv) {
| ^~~
(even though asking GCC to _not_ perform that optimization)
#include
#pragma GCC optimize ("unroll-loops")
int main(int argc, char **argv) {
printf("Hello 1\n");
printf("Hello 2\n");
printf("Hello 3\n");
return 0;
}
This note is emitted twice for this example and many times for bigger examples,
also for other GCC optimization options pragmas. The outputs can become large
(e.g. building R CRAN packages increased log file from about 1G to 12G).
The note is also emitted when -freorder-blocks-and-partition is given
(explicitly), which is probably intended, but it is not emitted when the
optimization is used implicitly as part of -O2.
The same problem exists with g++, except the wording of the note is "does not
work with exceptions on this architecture"
With "12.0" (5e5f880d0452ef2cffb94f4a686d56833c9f4215), the note is not emitted
with -fno-reorder-blocks-and-partition, however, the other problem remains. The
note is still not emitted when the optimization is enabled implicitly via -O2.
Related to Bug 103274; the reason for using -fno-reorder-blocks-and-partition
was to get valid unwind information for long jumps to work.
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
Tomas Kalibera changed:
What|Removed |Added
CC||tomas.kalibera at gmail dot com
--- Comment #2 from Tomas Kalibera ---
My apologies if this is obvious, but please let me note this issue means that
one cannot print(f) a 64-bit integer without a compile-time warning with UCRT
on Windows. It would be a great help if this could somehow be fixed.
In the example below, lines (1) and (2) work without a warning with MSVCRT.
But, all three issue a warning with UCRT.
#include
#include
int main(int argc, char **argv) {
long long unsigned x = 112;
printf("Hello %"PRIu64"\n", x); // 1
printf("Hello %I64u\n", x); // 2
printf("Hello %llu\n", x); // 3
return 0;
}
[Bug target/103274] Remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 --- Comment #2 from Tomas Kalibera --- (In reply to Eric Botcazou from comment #1) > > -freorder-blocks-and-partition sometimes causes a function to end right in a > > (non-returning) call, but SEH needs at least one more instruction on x86_64. > > Seen in GCC 10.3, 11.2 and git master. Maybe [1] did not cover all the > > cases? > > SEH means "Structured Exception Handling" but there is no exception handling > in this chunk of program since it's written in C and compiled without > -fexceptions, so I'm not quite sure what you're expecting here. This also causes crashes with setjmp/longjmp only (no C++ exceptions, no explicit use of C-exceptions in the C code). R triggers unwinding via long jumps (explicitly calling longjmp in C, to implement error handling in R), of the frames between setjmp and longjmp. The unwinding sometimes crashes due to the problem reported, because it does not find the unwinding information for some frames. Windows looks for a function matching a given instruction pointer, which happens to be right after the call causing the long jump. However, when the function end is marked right after such a call (such as in the example), the instruction pointer is regarded past the function end, and hence it is not matched to the function it should be. We were using workarounds to disable SEH during unwinding, via redefining setjmp to __intrinsic_setjmpex((x), NULL), so using the NULL frame argument instead of the default __builtin_frame_address(0).
[Bug target/103274] New: Remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 Bug ID: 103274 Summary: Remaining -freorder-blocks-and-partition/ glitch with Windows SEH Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 51809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51809=edit When compiled with -O3, dummy ends in a call (invalid unwind information). -freorder-blocks-and-partition sometimes causes a function to end right in a (non-returning) call, but SEH needs at least one more instruction on x86_64. Seen in GCC 10.3, 11.2 and git master. Maybe [1] did not cover all the cases? The attached compile-only example compiled with -O3 reproduces the problem. It is extracted from R, where this problem causes crashes (and where in wine, one gets an error "virtual_unwind exception data not found" and further instrumentation reveals it is because the address following the call instruction is already at the function boundary). The problem can be seen directly from the assembly: gcc -O3 -c -S ../main/a.c -o - produces dummy: [...] .L5: callmyerrorcall .seh_endproc [...] dummy.cold: For reference, R is affected by this and has been disabling SEH as a workaround, but it has been reported that the workaround causes in turns crashes with CFG. This report is with substantial help from Martin Storsjo. === [1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=15278fb2877184c75a6ee3a6def09efbb191968b;hp=9d3b9a3e70e634c7c48bb12bb35ec8219024f98b [2] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386.c;h=1bca5a7eea6ab9accbbf6953f79e8a4da61859e2;hb=4212a6a3e44f870412d9025eeb323fd4f50a61da#l29076 [3] https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86AvoidTrailingCall.cpp [4] https://bugs.r-project.org/show_bug.cgi?id=18180
[Bug driver/101238] Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101238 --- Comment #2 from Tomas Kalibera --- I started writing that email, but on the way I found that one should add -D__USE_MINGW_ACCESS also BOOT_CXXFLAGS, which I have neither done nor tested. The problem I debugged required only required adding to CXXFLAGS. In principle, one needs to add -D__USE_MINGW_ACCESS everywhere, where GCC might use "access()" to query X_OK, so it should be safe to add simply everywhere when compiling C or C++, it just must have been forgotten. I see -D__USE_MINGW_ACCESS has been added to CXXFLAGS and BOOT_CXXFLAGS in GCC 11 by a patch from Martin Storsjo, "mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables", https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567815.html And it is related to "[MinGW] Set __USE_MINGW_ACCESS for C++ as well" https://gcc.gnu.org/pipermail/gcc-patches/2019-March/518147.html (done also in GCC 10), which adds __USE_MINGW_ACCESS to STAGE*_CXXFLAGS. My testing was using an MXE-based build of GCC 10.2 (cross-compiled on Linux, for 64-bit Windows, with MinGW-w64 7). Without the change, gcc.exe did not find cc1.exe. Process monitor showed that gcc.exe called stat on cc1.exe successfully (so used the correct path already the first time), but then continued checking other locations and when it failed, tried to execute without path name (relying on system PATH). So a workaround I have been using was to have also cc1.exe on PATH, where it would be found by Windows (so the problem of access(,X_OK) did not apply there). Then the observed behavior matched the code of the driver gcc.c, which calls access(,X_OK) to check that cc1.exe is executable, and it incorrectly concludes that it isn't. Which in turn is because access on Windows does not support X_OK (and __USE_MINGW_ACCESS provides a MinGW replacement which does). I've confirmed this was what happened via adding print statements to the driver and rebuilding. And eventually I rebuilt gcc with the proposed patch and it found cc1.exe fine. Should I still send a copy of Martin Storsjo's patch to gcc-patc...@gcc.gnu.org, or is this information here now sufficient?
[Bug driver/101238] New: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101238 Bug ID: 101238 Summary: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 51070 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51070=edit Use -D__USE_MINGW_ACCESS when compiling the driver. Summary: one needs to add CXXFLAGS+=-D__USE_MINGW_ACCESS to config/mh-mingw so that the driver finds executables on Windows. This is already fixed in GCC 11, but not in GCC 10. More details: GCC 10 driver is compiled with g++ without-D__USE_MINGW_ACCESS on MinGW. That option is only added to CFLAGS, but not CXXFLAGS. Consequently, the driver will not find executables such as cc1, because access(,X_OK) will always return an error on Windows, as access() on Windows does not check for executability anymore. With __USE_MINGW_ACCESS, MinGW will use its own implementation of access() which for X_OK behaves the same as R_OK. I've tested the (trivial) attached patch and it resolved the issue on my system as expected.
