[Bug target/114775] on mingw __attribute__ ((__format__ (__printf__, ...))) doesn't recognize C99 specifiers

2024-04-18 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775 --- Comment #13 from Nikita Kniazev --- (In reply to Andrew Pinski from comment #12) > The reality is ms_printf most likely should just include z and ll support > instead since they are supported now: >

[Bug target/114775] on mingw __attribute__ ((__format__ (__printf__, ...))) doesn't recognize C99 specifiers

2024-04-18 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775 Nikita Kniazev changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED

[Bug target/114775] on mingw __attribute__ ((__format__ (__printf__, ...))) doesn't recognize C99 specifiers

2024-04-18 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775 --- Comment #9 from Nikita Kniazev --- Ok, is there at least an option to build GCC so it defaults __printf__ to gnu_printf? Defaulting __printf__ to ms_printf on UCRT is wrong (every OS without UCRT is already EOL).

[Bug target/114775] on mingw __attribute__ ((__format__ (__printf__, ...))) doesn't recognize C99 specifiers

2024-04-18 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775 --- Comment #7 from Nikita Kniazev --- (In reply to Andrew Pinski from comment #6) > (In reply to Nikita Kniazev from comment #5) > > > So there is mingw_printf and gnu_printf attributes for mingw because at > > > one point %ll didn't exist

[Bug target/114775] on mingw __attribute__ ((__format__ (__printf__, ...))) doesn't recognize C99 specifiers

2024-04-18 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775 --- Comment #5 from Nikita Kniazev --- > So there is mingw_printf and gnu_printf attributes for mingw because at one > point %ll didn't exist for mingw and nobody has updated it since then. Do you mean that binutils and [other code out

[Bug target/114775] New: on mingw __attribute__ ((__format__ (__printf__, ...))) doesn't recognize C99 specifiers

2024-04-18 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775 Bug ID: 114775 Summary: on mingw __attribute__ ((__format__ (__printf__, ...))) doesn't recognize C99 specifiers Product: gcc Version: 13.2.0 Status: UNCONFIRMED

[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null

2023-03-19 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 Nikita Kniazev changed: What|Removed |Added CC||nok.raven at gmail dot com ---

[Bug c++/93016] erroneous new (nothrow_t) still throws an exception

2023-03-19 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93016 Nikita Kniazev changed: What|Removed |Added CC||nok.raven at gmail dot com --- Comment

[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong

2023-03-02 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997 --- Comment #3 from Nikita Kniazev --- For cond == 789 if (cond_2(D) == 789) goto ; [20.24%] else goto ; [79.76%] For cond != 789 if (cond_2(D) != 789) goto ; [48.88%] else goto ; [51.12%]

[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong

2023-03-02 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997 Nikita Kniazev changed: What|Removed |Added CC||nok.raven at gmail dot com ---

[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch

2023-03-02 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 --- Comment #6 from Nikita Kniazev --- > Did you see this in real code or you just noticed this while looking at code > generation? If you mean do I have any benchmark - unfortunately no. I noticed it for a while by poking different code to

[Bug rtl-optimization/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch

2023-03-02 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 --- Comment #2 from Nikita Kniazev --- > Why do you think this is a bug? > I don't see anything wrong with the newer versions of gcc. > Duplicating the basic blocks is done on purpose for speed reasons. I understand that removing diamonds is

[Bug rtl-optimization/108992] New: Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch

2023-03-02 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 Bug ID: 108992 Summary: Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch Product: gcc

[Bug c++/92145] -Wdeprecated-copy false-positive when inheriting base assignment operators

2021-11-24 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92145 --- Comment #3 from Nikita Kniazev --- (In reply to Marek Polacek from comment #2) > Fixed? It is fixed on trunk but still presented in every release (since the fix landed 9.4 and 11.2 were released). I assume it was not backported, could you

[Bug libstdc++/101923] std::function's move ctor is slower than the copy one for empty source objects

2021-08-15 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101923 Nikita Kniazev changed: What|Removed |Added CC||nok.raven at gmail dot com ---

[Bug c++/101537] -Wconversion false positive in ternary

2021-08-08 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537 Nikita Kniazev changed: What|Removed |Added CC||nok.raven at gmail dot com ---

[Bug ipa/101813] New: -O3 does worse at constant folding than -O2

2021-08-07 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101813 Bug ID: 101813 Summary: -O3 does worse at constant folding than -O2 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal

[Bug c++/94492] no way to silence -Wdeprecated-copy for aggregates

2021-06-02 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94492 --- Comment #2 from Nikita Kniazev --- Could this be backported? The issue affects every release with -Wdeprecated-copy, which are GCC 9+.

[Bug tree-optimization/100858] Simple common code hoisting is not performed

2021-06-02 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100858 --- Comment #2 from Nikita Kniazev --- (In reply to Richard Biener from comment #1) > That's really a duplicate of 100858 - this case can be handled by sinking as > well > since we "sink" the return. Make it > > void bar(); > > int foo(bool

[Bug tree-optimization/100858] New: Simple common code hoisting is not performed

2021-06-01 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100858 Bug ID: 100858 Summary: Simple common code hoisting is not performed Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal

[Bug tree-optimization/100857] New: Simple common code sinking is not performed

2021-06-01 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100857 Bug ID: 100857 Summary: Simple common code sinking is not performed Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal

[Bug c++/100608] New: [10/11/12 Regression] -Wshadow=compatible-local false positive: function local type declaration shadows variable of different type

2021-05-14 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100608 Bug ID: 100608 Summary: [10/11/12 Regression] -Wshadow=compatible-local false positive: function local type declaration shadows variable of different type Product: gcc

[Bug libstdc++/100243] New: [10 Regression] invalid use of incomplete type 'std::__detail::__iter_traits >' {aka 'struct std::indirectly_readable_traits'}

2021-04-23 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100243 Bug ID: 100243 Summary: [10 Regression] invalid use of incomplete type 'std::__detail::__iter_traits >' {aka 'struct std::indirectly_readable_traits'} Product: gcc

[Bug target/100021] [9/10/11 Regression] std::clamp unprofitable vectorization on -march=nehalem/.../broadwell

2021-04-12 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100021 Nikita Kniazev changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING

[Bug target/100021] New: [9/10/11 Regression] std::clamp unprofitable vectorization on -march=nehalem/.../broadwell

2021-04-10 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100021 Bug ID: 100021 Summary: [9/10/11 Regression] std::clamp unprofitable vectorization on -march=nehalem/.../broadwell Product: gcc Version: 11.0 Status: UNCONFIRMED

[Bug c++/99795] New: -Wnarrowing/-Woverflow false-negative in constant expression in undeduced context

2021-03-26 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99795 Bug ID: 99795 Summary: -Wnarrowing/-Woverflow false-negative in constant expression in undeduced context Product: gcc Version: 11.0 Status: UNCONFIRMED

[Bug c++/99331] [8/9/10 Regression] -Wconversion false-positive in immediate context

2021-03-26 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331 --- Comment #7 from Nikita Kniazev --- The fix silenced the true warning (though it was saying 'may') in these: template struct X {}; template X foo(); int x = sizeof(foo()); template struct X {}; template struct foo { using t = X; }; foo

[Bug c++/99331] [8/9/10/11 Regression] -Wconversion false-positive in immediate context

2021-03-01 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331 --- Comment #3 from Nikita Kniazev --- This one most likely has the same root problem: template struct X {}; template struct foo { using t = X; }; :3:26: error: conversion from 'long unsigned int' to 'int' may change value

[Bug c++/99331] New: -Wconversion false-positive in immidiate context

2021-03-01 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331 Bug ID: 99331 Summary: -Wconversion false-positive in immidiate context Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal

[Bug rtl-optimization/99305] New: [11 Regression] range condition simplification after inlining

2021-02-27 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99305 Bug ID: 99305 Summary: [11 Regression] range condition simplification after inlining Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall

2021-02-25 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 Nikita Kniazev changed: What|Removed |Added CC||nok.raven at gmail dot com --- Comment

[Bug tree-optimization/93721] swapping adjacent scalars could be more efficient

2021-02-13 Thread nok.raven at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93721 Nikita Kniazev changed: What|Removed |Added CC||nok.raven at gmail dot com --- Comment