Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
There is no way to silence the warning without making a type non-aggregate.
A simplified case from Boost.Proto:
#pragma GCC diagnostic push
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
#include
boost::optional get()
{
return {};
}
boost::optional foo()
{
return get();
}
// g++ -O3 -Wall
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
inline void swap(int &x, int &y)
{
int tmp = x;
x = y;
y = tmp;
}
void bar(int (&x)[2])
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
inline void swap(int &x, int &y)
{
int tmp = x;
x = y;
y = tmp;
}
void foo(in
: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/UAc5tq
struct base
{
base() { }
base(const base&) { }
: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
The wording is in [class.union]/1 and [class.mem]/25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92399
Nikita Kniazev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
template
void foo(void(*f)() noexcept(b));
void f();
void bar()
{
foo(&f);
}
g++ foo.cpp -std=c++17
: In function 'v
: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
template
struct S {};
struct X
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
static bool
ischar(int ch)
{
return (0 == (ch & ~0xff) || ~0 == (ch | 0xff)) != 0;
}
static bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92434
--- Comment #5 from Nikita Kniazev ---
> but does [temp.deduct] actually require that this works?
Judging by CWG 2355 it does not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56665
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Target: x86_64
#include
float rsqrtf_a(float x) {
return _mm_cvtss_f32
-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Target: x86_64
GCC generates/fails to optimize unnecessary sign
verity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Proof https://rise4fun.com/Alive/Xr3
unsigned foo(unsigned x)
{
if (x > 31) __builtin_un
: diagnostic, needs-reduction, rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
For some reason `bar` makes `foo` not copy-constructible. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Host: x86_64
Target: x86_64
Hello,
The -Wuninitialized warning comes from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89733
--- Comment #2 from Nikita Kniazev ---
Created attachment 45990
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45990&action=edit
preprocessed repro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86912
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Host: x86_64
Target: x86_64
#include
#include
: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Clang optimizes it perfectly, while GCC does byte-per-byte assemble
-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Host: x86_64
Target: x86_64
I was expecting that fixed-size
: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Host: x86_64
Target: x86_64/ARM/ARM64
Created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89733
--- Comment #4 from Nikita Kniazev ---
So the warning triggers intentionally in copy/move even if the value actually
not read anywhere in the user code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89733
--- Comment #6 from Nikita Kniazev ---
I understand. I though that -Wuninitialized should not produce false positives
and that's a main difference between it and -Wno-maybe-uninitialized.
The warning does not go away and does not change to -Wno-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86525
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment
: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
// case 1 - https://godbolt.org/z/02zu_3
struct X
{
int x, y;
X() : y(0) {}
};
X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89733
Nikita Kniazev changed:
What|Removed |Added
Summary|[7/8/9 Regression] False|[7/8/9 Regression]
|p
mal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Target: x86_64,AArch64
int foo(int x)
{
return x < 0 ? x - INT_MIN : x;
}
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Target: Intel x86
Originally I filed a bug report to LLVM about
int foo(int x)
{
return (x << 1) | 1;
}
But got an answered that 3 ops LEA is intenti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90088
--- Comment #2 from Nikita Kniazev ---
> I could see it being useful for -Os case.
Yes, and I also was confirmed that it is a bug that Clang with -Os avoids it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875
--- Comment #6 from Nikita Kniazev ---
> Those pragmas are all extensions, so the standard doesn't cover them.
There was a Clang bug report recently with a pretty much same code I had posted
previously and Clang developers said that it is ill-fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976
--- Comment #2 from Nikita Kniazev ---
The same warning as when the object is constructed inside the main function:
int main()
{
XorYorZ x;
return x.x;
}
Also, the warning is not triggered in C++17+ mode with:
XorYorZ foo()
{
retur
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
The regression appeared after 7.3.0 and not later than 8.1.0. I do not have
8.0.0 to test it.
https://godbolt.org
-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
MWE:
template
using limit_argnum = T;
template
struct tuple
{
template
tuple
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
template struct X {};
template X foo();
g++ -Wconversion -Werror src.cpp
:2:22: error: conversion from 'long unsigned int' to
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 [-Werror=conversion
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
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
CC: jason at redhat dot com, mpolacek at gcc dot gnu.org
Target Milestone: ---
template struct
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
//#include
namespace std
{
template
constexpr const _Tp&
clamp(const _Tp& __val, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100021
Nikita Kniazev changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
// g++-10 -std=c++2a
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93721
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
bool foo(char c)
{
return c >= '0' && c <= '9';
}
bool bar(char c)
{
return c != &#x
Version: 10.3.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
template class X
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
void bar(int);
void foo(bool f)
{
if (f) {
bar(1);
}
else {
bar(2);
}
}
; GCC
foo(bool
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
void bar();
int foo(bool f)
{
if (f) {
bar();
return 1;
}
else {
bar
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 f
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+.
: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
There are two
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 do
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 co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
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%]
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 pl
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
#include
#include
using opts = boost::optional;
struct foo
{
foo(opts x) : b(x), c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101923
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93016
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
IRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Target: *-w64-mingw32
#define ATTRIBUTE_PRINTF
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
there](
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 for
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114775
Nikita Kniazev changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
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:
> https://learn.microsoft.com/en-us/cpp/c-r
68 matches
Mail list logo
