https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
--- Comment #34 from Konstantin Kharlamov ---
> which is a problem, because it which is a problem, because it the actual
> situation
whoops, sorry, not sure what happened to that part, it's supposed to be "which
is a problem, because it contrad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
--- Comment #33 from Konstantin Kharlamov ---
@Richard Biener: thank you for the change! If I may point out though, the new
text still says:
> […]-Og should be the optimization level of choice for the standard
> edit-compile-debug cycle, offerin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #10 from Konstantin Kharlamov ---
(In reply to Alejandro Colomar from comment #7)
> (In reply to Konstantin Kharlamov from comment #5)
> > So basically -Wc++-compat warns about every heap memory allocation, of which
> > there are doz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #5 from Konstantin Kharlamov ---
(In reply to Konstantin Kharlamov from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > It is included in -Wc++-compat .
>
> Cool, thanks! I'll add the warning to the list we compile the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115684
--- Comment #1 from Konstantin Kharlamov ---
FWIW, IRL these cases happen during refactoring, when you factor out a code to
a smaller function, and some variables from the original function become
pointers. I honestly never even check the parame
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
Comparing an enum field with a pointer produces no warnings (while comparing an
int to a pointer produces them). We just had a regression due to this missing
check, such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Andrew Pinski from comment #2)
> It is included in -Wc++-compat .
Cool, thanks! I'll add the warning to the list we compile the project with,
thank you!
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
It's a common pattern to have some `enum Foo { one, two, three }`, and then
some 2-dimensinal array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
--- Comment #12 from Konstantin Kharlamov ---
(In reply to Martin Uecker from comment #11)
> A conforming C compiler has to diagnose all violations of constraints with
> the same correct type of x in all branches (not the type it would have in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
--- Comment #10 from Konstantin Kharlamov ---
(In reply to uecker from comment #9)
> Some warnings are then even required to be standard compliant.
I just searched through the C standard and no warnings seem to be required by
it. The only place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
--- Comment #8 from Konstantin Kharlamov ---
(In reply to uecker from comment #7)
> Fundamentally, the program is that _Generic is not ideally designed for this
> use case.
Why?
> One could consider an extension
>
> _Generic(x, int i: f(i), l
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
When a switch-case has a "fallthrough" case that is surrounded by an `#ifdef`
and is not compiled in, GCC does not rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92559
--- Comment #5 from Konstantin Kharlamov ---
(In reply to Konstantin Kharlamov from comment #4)
> By the way, FTR: I don't have the code anymore, but initially the problem
> came from a real-life algorithm involving lots of state, which looked ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92559
--- Comment #4 from Konstantin Kharlamov ---
By the way, FTR: I don't have the code anymore, but initially the problem came
from a real-life algorithm involving lots of state, which looked barely
readable when implemented in iterative way (i.e. a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92559
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Andrew Pinski from comment #2)
> I don't think this can ever be optimized. Mainly because there are copies
> happening due to passing via value and returning by value.
Please correct me
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
Created attachment 51176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51176&action=edit
preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92718
--- Comment #9 from Konstantin Kharlamov ---
Omg, I am sorry, please ignore my comment. For some incomprehensible reason
bugzilla circles through bug entries upon sending a comment. My comment here
was supposed for another report, but then appare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92718
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93437
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
The following code, exploiting tail-recursion, does not get optimized into a
loop with -O3 option, so it crashes if you try to run it.
#include
using MyMap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48363
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761
--- Comment #6 from Konstantin Kharlamov ---
Thanks, okay, so, for the record: comment #3 seems no longer relevant, since
the function `find_tail_calls()`, when analyzing g(), gets executed till its
end. No early returns anywhere. Tested with: GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91515
--- Comment #2 from Konstantin Kharlamov ---
I think this is a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92474
--- Comment #2 from Konstantin Kharlamov ---
(In reply to Jakub Jelinek from comment #1)
> Note, starting with r273603, the trunk doesn't tail call optimize this
> either even without -fsanitize=, unless -fno-tree-sra.
Is there a report for this
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #7 from Konstantin Kharlamov ---
@Jonathan Wakely I think you accidentally closed the report, would you mind to
reopen it (I'm not seeing why would it be "invalid", people even confirmed that
more support for std containers is being a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #6 from Konstantin Kharlamov ---
(In reply to Jonathan Wakely from comment #5)
> No, that's not how undefined behaviour works. You are wrong to expect a crash
No, in context of the report I'm not. You're correct this is not how UB w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #4 from Konstantin Kharlamov ---
(In reply to Marc Glisse from comment #3)
> -D_GLIBCXX_DEBUG is the current way to add many checks to libstdc++, and it
> detects this.
Oh, cool, I'll make use of it, thanks for the hint!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91878
--- Comment #1 from Konstantin Kharlamov ---
Btw, worth noting that clang 8.0.1 does not handle it either.
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777
--- Comment #5 from Konstantin Kharlamov ---
(In reply to Martin Liška from comment #4)
> (In reply to Konstantin Kharlamov from comment #3)
> > (In reply to Martin Liška from comment #2)
> > > I can see a ASAN error:
> >
> > Correct. You set th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Martin Liška from comment #2)
> I can see a ASAN error:
Correct. You set the report status to WAITING: do you expect some answer from
me, or was it accidental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91777
--- Comment #1 from Konstantin Kharlamov ---
FTR, on IRC was referenced the following paper that may be interesting for
implementors
https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
The testcase below would've worked if instead of `return {l,…` was used `return
{move(l),…`. But it wasn't, and due to lack of borrow-semantics in C++ language
such mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91751
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Jonathan Wakely from comment #2)
> The advantage of showing the location of the constructor is that you can see
> which object is being destroyed. If the location was shown as the end of t
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
As the title says. I'm not aware of a way to get backtrace with gcc builtins,
so I'm using gdb in testcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91436
--- Comment #6 from Konstantin Kharlamov ---
Thank you!
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
When the reason for an undefined function is too low c++ standard, g++ still
suggests to include the header where it's supposed to be. As a result, when in
a project you're not fam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91311
Konstantin Kharlamov changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91311
--- Comment #1 from Konstantin Kharlamov ---
Created attachment 46652
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46652&action=edit
rr record for the testcase, results in stack-use-after-scope
I'm also attaching the `rr` record for the
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86050
--- Comment #7 from Konstantin Kharlamov ---
(In reply to Aso Renji from comment #6)
> (In reply to Konstantin Kharlamov from comment #5)
> > Just tested with 8.3.0 version on the other PC, same there, i.e. stack space
> > does not increase when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86071
--- Comment #2 from Konstantin Kharlamov ---
(In reply to Alexander Monakov from comment #1)
> In GCC there's no way to selectively enable a few optimizations with their
> -f flags at -O0 level: -O0 means that optimizations are completely disable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86050
--- Comment #5 from Konstantin Kharlamov ---
(In reply to Konstantin Kharlamov from comment #4)
> Works for me on gcc 9.1.0. I compile it as:
>
> $ g++ test.cpp -o a -O2
>
> And then running `./a` results in a bunch of:
>
> Consumed 80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86050
--- Comment #4 from Konstantin Kharlamov ---
Works for me on gcc 9.1.0. I compile it as:
$ g++ test.cpp -o a -O2
And then running `./a` results in a bunch of:
Consumed 80 bytes
Consumed 80 bytes
Consumed 80 bytes
Consumed 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77433
Konstantin Kharlamov changed:
What|Removed |Added
CC||Hi-Angel at yandex dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89326
--- Comment #2 from Konstantin Kharlamov ---
Btw, I just occasionally noted: godbolt site adds their own highlight to GCC
output, in particular they highlight the whole line with "required from here"
with blue. Maybe something can be borrowed fro
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
Compile-errors of constructors and templates can give a lot of output. Usually
the first thing in debugging is to figure out where the
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
# Steps to reproduce (in terms of terminal commands):
$ cat test.cpp
#include
struct MyS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89147
--- Comment #2 from Konstantin Kharlamov ---
(In reply to Andrew Pinski from comment #1)
> >Possible workarounds are welcome.
>
> Use -ffat-lto-objects or use a .s file.
Thank you for reply!
Adding a `-ffat-lto-objects` to the command above di
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
CC: marxin at gcc dot gnu.org
Target Milestone: ---
This came up while researching why -flto build of Mesa fails with linking
errors. The asm snippet below is from an auto-generated code
erity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
In most projects a definite pattern that's unlikely to be executed is a
PRINT_ERR macro which is basically a wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87057
--- Comment #6 from Konstantin Kharlamov ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Konstantin Kharlamov from comment #2)
> > As far as such trivial optimizations concerned, I'd prefer to rely on the
> > compiler figuring th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87057
--- Comment #3 from Konstantin Kharlamov ---
(In reply to Konstantin Kharlamov from comment #2)
> Thanks, I prefer the `{x}` to just `x` because in the latter I'm being
*"in the former", sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87057
--- Comment #2 from Konstantin Kharlamov ---
(In reply to Jonathan Wakely from comment #1)
> That would require a lot of special-casing just for std::variant.
Well, I think, in place of std::variant there could be any struct-wrapper; but
I get i
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
When, in a code, a copy-constructor deleted but used, GCC issues an absolutely
unhelpful message that it couldn't convert the arg
onent: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
# Steps to reproduce:
$ cat test.cpp
struct Node {
Node* chi
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
Steps to reproduce:
$ cat test.cpp
int ret_int() { return -1; }
int main() {
unsigned foo = ret_int();
(void)foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83161
--- Comment #1 from Constantine Kharlamov ---
Just another data point I forgot to mention:
https://stackoverflow.com/questions/3311182/linux-c-easy-pretty-dump-printout-of-structs-like-in-gdb-from-source-co
7k views. Author of this one went as fa
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
It's very useful for debugging to pretty-print an entire struct. Typically
people firing up gdb for this, but sometimes it's
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Hi-Angel at yandex dot ru
Target Milestone: ---
This code used to work prior to gcc-7.1 (it worked on 4.x, and — I just tested
— 6.3 works too, with a warning though):
struct DataPacket
64 matches
Mail list logo
