[Bug debug/95437] New: DW_TAG_typedef for template alias missing template type parameters

Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- Currently GCC represents instantiations of alias templates using DW_TAG_typedef instead of DW_TAG_template_alias. And, while Clang

[Bug debug/95437] DW_TAG_typedef for template alias missing template type parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95437 --- Comment #1 from Pedro Alves --- > This "missing template parameters info" issue also prevents setting > breakpoints > using the alias template with GCC-built binaries. This GDB commit adds a testcase exercising this issue: https://source

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961 --- Comment #14 from Pedro Alves --- I had forgotten about this bug, and when I re-read it, the idea of letting the user refer to the parameter by name crossed my mind. Like, make it possible to write: void foo (int, const char *arg) __attrib

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961 --- Comment #15 from Pedro Alves --- Darn typos. Should be obvious that I meant: Make it possible to write: void foo (int, const char *arg) __attribute__ ((__nonnull__ (arg))); instead of this when foo is a class method: void foo (int, c

[Bug debug/94235] worse debug info with O0 than with O2 with flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94235 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #2

[Bug debug/97026] New: -flto and DW_AT_GNU_macros

Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- With: #define ZERO 0 int main () { return ZERO; } Compiled with -flto and -g3 so we emit macro debug info: $ gcc macro.c -o macro -flto -g3 Using gcc version 11.0.0 20200910, commit

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #30 from Pedro Alves --- I assume so, but do we really want to zero-initialize the buffer? T might be large, and I'd think that pessimization to quiet a warning isn't the right way to go?

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #32 from Pedro Alves --- Right, the potentially-sensitive aspect is what I mean to stress here. Usually maybe-uninit warnings point to false positives involving scalars, and initializing them is practically free. But here the size o

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #36 from Pedro Alves --- (In reply to Jason Merrill from comment #33) > (In reply to Pedro Alves from comment #32) > > Usually maybe-uninit warnings point to false positives involving scalars, > > and initializing them is practically

[Bug c/92995] New: -Wmisleading-indentation and multiline string literals

Component: c Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- clang 10 caught a misleading indentation in gdb that GCC missed: https://sourceware.org/ml/gdb-patches/2019-12/msg00733.html It appears that the issue is the line

[Bug debug/52160] gdb ignores line "bar: if(foo)goto bar;"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52160 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com

[Bug c/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #1

[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 --- Comment #3 from Pedro Alves --- hmb, could you do that? See instructions here: http://gcc.gnu.org/bugs/

[Bug other/56780] --disable-install-libiberty still installs libiberty.a

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #4

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #10

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 --- Comment #11 from Pedro Alves --- Running the testcase under valgrind and current gdb master I see: ==6118== Conditional jump or move depends on uninitialised value(s) ==6118==at 0x4C35CB0: bcmp (vg_replace_st

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 --- Comment #12 from Pedro Alves --- GDB fix posted here: https://sourceware.org/ml/gdb-patches/2018-01/msg00482.html

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 --- Comment #13 from Pedro Alves --- Fix is now in GDB's master, 8.1, and 8.0 branches.

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #16 from Pedro Alves --- (In reply to Martin Sebor from comment #15) > Zero > initializing A::i first and then setting it to the result of f() also avoids > the warning and seems like more viable solution/workaround until GCC gets > s

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #19

[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590 --- Comment #22 from Pedro Alves --- clueless suggestion triggered by you saying "throwing": does marking __constant_string_p noexcept, like: ... __constant_string_p(const _CharT* __s) noexcept ... make any difference?

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550 --- Comment #4 from Pedro Alves --- infrun: stepped into subroutine #1 infrun: inserting step-resume breakpoint at 0x5b88b8 #2 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25164] at 0x8

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550 --- Comment #6 from Pedro Alves --- I see the same thing with your reduced testcase: ~~~ infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400580 infrun: stepped into subroutine infrun: inserting step-resume breakpoint at 0x400410 infrun: resu

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550 --- Comment #10 from Pedro Alves --- It sounds that way, but I haven't verified, e.g., by trying older versions of gdb, and/or bisecting. Kevin, in addition to trying older versions of gdb with freorder-blocks-and-partition, I'm curious about wh

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #23 from Pedro Alves --- I think support in the compiler directly is likely to have better compile-time performance, and I've stated from the beginning that I'd prefer that, FWIW. OTOH, meanwhile, AFAICT, there's nothing preventing f

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #26 from Pedro Alves --- I'm confused then -- how does making __builtin_memcmp natively work on constexpr contexts address the "but then we'd have *three* versions" concern? Looking at the code, it does sound like you instead would w

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #28 from Pedro Alves --- > Looking at the code, it does sound like you instead would want to > tweak __equal_aux to end up with __simple==false when all __equal_aux's > arguments are constant. I suspect that wouldn't work, because w

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #29 from Pedro Alves --- OK, our messages crossed. Thanks for the clarification. I can't really comment on the optimizers.

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #30 from Pedro Alves --- > I suspect that wouldn't work, because we'd need to check whether the > elements the iterator range point-to are themselves constant. I would like to add that the char_traits trick handles this by doing exac

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #32 from Pedro Alves --- In that case, I think the "something something" you're looking for can be char_trait's __constant_char_array_p: + if (__constant_char_array_p(__first1, __len) + && __constant_char

[Bug c/70143] [6 Regression] false strict-aliasing warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 --- Comment #4 from Pedro Alves --- > The warning is "correct". You are accessing object *ap (a struct a) via a > pointer to struct b. I'd think that instead, we are accessing object "*&ap->i", an int, via a pointer to struct b, and I'd imag

[Bug c/70143] [6 Regression] false strict-aliasing warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 --- Comment #8 from Pedro Alves --- > Note that we then also don't warn for (...) > struct a { int i; int k; }; > return ((struct b *)&ap->k)->j; (...) > then either I see it the same as: int *ip = &ap->k; ((struct b *)ip)->j; Fine from type

[Bug c/70143] [6 Regression] false strict-aliasing warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70143 --- Comment #11 from Pedro Alves --- > That is certainly not fine from aliasing perspective, aliasing is not just > about the type of the field you access, but the whole access path, so if you > use ((struct b *)ip)->j then ip should point to an

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #1

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922 --- Comment #2 from Pedro Alves --- I noticed that this triggers with C++, but not with C. (GDB recently switched to building as C++ program by default.) With g++ 20160407 (what I have handy): $ /opt/gcc/bin/g++ parens.c -o parens -Wall -Wpar

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922 --- Comment #3 from Pedro Alves --- > I noticed that this triggers with C++, but not with C. (GDB recently > switched > to building as C++ program by default.) I've built trunk now (gcc version 7.0.0 20160503), and I now get the same warning o

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922 --- Comment #5 from Pedro Alves --- There's no ambiguous else in sight, the macro is written that way to avoid dangling if/else problems, and the indentation is correct. It very much looks like a false positive to me.

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922 --- Comment #8 from Pedro Alves --- - There's exactly the same number of ifs and elses in the macro. - The indentation of the else matches that of the if. - There's actually no "else" at all at the macro call site, making the warning look odd. S

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922 --- Comment #10 from Pedro Alves --- Sure can. But the point is discussing what makes sense for the warning.

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922 --- Comment #13 from Pedro Alves --- Should have been: if (condition) ALL_OBJFILE_OSECTIONS (o, osect) { /* do something with each o / osect */ } else return 0; So if the ALL_OBJFILE_OSECTIONS macro conta

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922 --- Comment #14 from Pedro Alves --- (In reply to Jakub Jelinek from comment #12) > The warning is about dangling else, which you have in the source. > if (cond) > for (...) > if (cond2) > ... > else > and while the C/C++ grammar

[Bug c++/70922] -Wparentheses warning should not complain about if-else from macro expansion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70922 --- Comment #16 from Pedro Alves --- (In reply to Manuel López-Ibáñez from comment #15) > But I can see that one may wrongly write: > > void bar(int x) > { > if (x) > MACRO_WITH_ELSE(x) > if(!x) >return; > } > > and no

[Bug middle-end/66110] uint8_t memory access not optimized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #16

[Bug c++/82213] New: Please warn about const rvalue reference parameters [void func(const T&&);]

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- It'd be nice if GCC would warn about const rvalue reference parameters. AFAIK, there's no good use for su

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #18 from Pedro Alves --- I sent a patch using the __builtin_constant_p idea: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00983.html

[Bug c++/80635] New: std::optional and bogus -Wmaybe-uninitilized

++ Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- GDB ran into an odd -Wmaybe-uninitialized warning in code using std::optional Well, actually with gdb::optional, but std::optional shows the exact same warning. https

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitilized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #1 from Pedro Alves --- If you uncomment the lines to use std::optional instead, you get: $ /opt/gcc/bin/g++ optional.cc -g3 -O2 -Wall -std=gnu++17 -c optional.cc: In function ‘void func()’: optional.cc:28:15: warning: ‘maybe_a.A

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #2 from Pedro Alves --- Looks like a regression at some point: There are no warnings with g++ 5.3.1, either reduced testcase, or with the obvious change to use std::experimental::optional instead of std::optional. Also no warnings w

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #4 from Pedro Alves --- Hi Marc, thanks much for taking a look. Looks like I over reduced in the minimal reproducer. std::optional has a boolean field to track whether the contained object had been fully initialized, which is checke

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #6 from Pedro Alves --- That kind of makes sense if you look at optional in isolation, but why does it _not_ warn if you remove anything related to B and leave only A? That's what's truly mystifying to me. Even this change makes the

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #9 from Pedro Alves --- > So maybe we just want to use a #pragma around the std::optional destructor to > suppress this warning. I had tried that last night, but unfortunately it couldn't get it to work, because the warning triggers

[Bug target/80777] gdb sizeof(long int)=4 but gcc sizeof(long int)=8 on x86_64-pc-cygwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80777 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #11

[Bug debug/81267] New: Missing DW_AT_type in DW_TAG_typedef of "typedef of typedef of void"

ty: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- I'm writing a GDB testcase that exercises the "whatis" command. If passed a type name, that command

[Bug debug/81267] Missing DW_AT_type in DW_TAG_typedef of "typedef of typedef of void"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81267 --- Comment #1 from Pedro Alves --- xref: https://sourceware.org/ml/gdb-patches/2017-06/msg00827.html

[Bug c/81310] New: Is __attribute__ alias on variables valid?

Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- I'm improving GDB's support for finding symbols resulting from __attribute__ alias, and while writing a test noticed something that I'd like clarification on. Whil

[Bug c/81310] Is __attribute__ alias on variables valid?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81310 --- Comment #1 from Pedro Alves --- Err, I meant "(&global1 == &global2) => false", of course.

[Bug debug/59161] GDB pretty printers: iterator->reference not printed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 --- Comment #8 from Pedro Alves --- Sounds like Paul's original patch may have introduced an undesired conflation. AFAICS, options.addressprint's exists to implement "set print address on/off", which had for original motivation, from the manual:

[Bug debug/59161] GDB pretty printers: iterator->reference not printed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 --- Comment #9 from Pedro Alves --- > Sounds like Paul's original patch may have introduced an undesired > conflation. AFAICS, options.addressprint's exists to implement "set print > address on/off", which had for original motivation, from the

[Bug libstdc++/59161] GDB pretty printers: iterator->reference not printed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 --- Comment #12 from Pedro Alves --- > So I think the libstdc++ part is fixed, Thanks. TBC, given the pointer example in comment #9, I think GDB's implicit use of options.addressprint=off for pretty printers is a clear GDB bug. I think GDB sh

[Bug fortran/78822] [cleanup] replace static char buffers by std:string

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #19

[Bug fortran/78822] [cleanup] replace static char buffers by std:string

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822 --- Comment #20 from Pedro Alves --- And in addition, since GCC is already using new/new[] to heap allocate its own classes, GCC is _already_ inconsistent with allocation failure -- if one of those currently fails, you'll end up with a C++ except

[Bug c++/79345] New: passing yet-uninitialized member as argument to base class constructor should warn (-Wunitialized)

: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- Created attachment 40653 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40653&action=ed

[Bug c++/79345] passing yet-uninitialized member as argument to base class constructor should warn (-Wunitialized)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79345 --- Comment #1 from Pedro Alves --- Note, if we add a use of gdb_disassembler::m_stream somewhere, like: gdb_disassembler_test () : gdb_disassembler (verbose == 123 ? &stream_v : &stream_q) // bug here { if (m_stream != &stream_v)

[Bug c++/60615] bad location in error from initializer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60615 --- Comment #6 from Pedro Alves --- Marek, did you ever post a patch for this?

[Bug c++/79658] New: [-Wuninitialized] referencing uninitialized field of POD struct should warn

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- In this code: template struct enum_flags { enum_flags

[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658 --- Comment #1 from Pedro Alves --- Created attachment 40797 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40797&action=edit reproducer Here's the same reproducer source.

[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658 --- Comment #3 from Pedro Alves --- > For your testcase foo () is quickly optimized to nothing given ef is unused. Shouldn't that be true for "bar ()" too then? Looks like I over reduced. I'll try again.

[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658 --- Comment #4 from Pedro Alves --- Here's a better one: template struct enum_flags { enum_flags &operator|= (E e) { m_enum_value = (E) (m_enum_value | e); return *this; } operat

[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658 --- Comment #5 from Pedro Alves --- Created attachment 40806 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40806&action=edit reproducer v2 Same code as the previous comment.

[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658 --- Comment #6 from Pedro Alves --- Created attachment 40807 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40807&action=edit reproducer v3 Slightly reduced testcase. enum_flags no longer a template, and stores/uses/converts to int instea

[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658 --- Comment #7 from Pedro Alves --- Today I remembered to try reducing the v3 reproducer by converting to C instead of C++. The resulting warnings are not exactly the same, but they're very similar. The fact that we still only get warnings for

[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658 --- Comment #8 from Pedro Alves --- Created attachment 40823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40823&action=edit reproducer v4 Same as above.

[Bug demangler/70909] Libiberty Demangler segfaults (4)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909 --- Comment #48 from Pedro Alves --- GDB is released separately from binutils though, and GDB 8.0 is going to branch very soon. IWBN to have this in the binutils-gdb repo by then.

[Bug c++/79961] New: Should diagnose when '__nonnull__' attribute is applied to implicit this argument

NCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- struct A { A (const char *arg) __attribute__ ((__nonnull__ (1))); void foo (const char *arg) __a

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961 --- Comment #2 from Pedro Alves --- Yeah, I think it's too late, and it'd cause trouble with compatibility with clang. Note that the documentation for the attribute(format)

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961 --- Comment #5 from Pedro Alves --- > We certainly should allow __attribute__((nonnull)) on methods, even when that > > includes nonnull (implicit) also for this. Yes, agreed, with implicit nonnull with no specified argument. For the case of

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961 --- Comment #6 from Pedro Alves --- I remembered to check what does G++ say when you apply the nonnull to a non-pointer argument. We get a hard error: $ /opt/gcc/bin/g++ nonnull.cc -o nonnull -c nonnull.cc:5:67: error: nonnull argument referenc

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961 --- Comment #7 from Pedro Alves --- Funny enough, clang 3.7 (don't have more recent handy), warns in that case, while it errors on the "this" arg: nonnull.cc:3:39: error: '__nonnull__' attribute is invalid for the implicit this argument A (con

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961 --- Comment #9 from Pedro Alves --- > ((A*)0)->g (p) This is undefined behavior. We forced the world to fix code like that in the GCC 6 release cycle: https://gcc.gnu.org/gcc-6/changes.html At best, I'd suggest degrading the error on implicit

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961 --- Comment #11 from Pedro Alves --- > All the interesting calls here are undefined. I meant that the one pointed out is undefined even without the nonnull attribute. I.e., it's not a use case that justifies supporting nonnull(1) on non-members

[Bug c++/79961] Should diagnose when '__nonnull__' attribute is applied to implicit this argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961 --- Comment #12 from Pedro Alves --- TBC, the reason I filed this, is because GDB had an incorrect use like that that survived for a few months: https://sourceware.org/ml/gdb-patches/2016-11/msg00933.html until someone compiled GDB with clang:

[Bug demangler/79976] long list of demangle failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79976 --- Comment #2 from Pedro Alves --- Thanks for looking at that! I'd love for that patch to me merged, but realistically, I don't know when I'd have time to champion it, and it's been almost 3 years... If someone picks it up and runs with it, it

[Bug demangler/79976] long list of demangle failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79976 --- Comment #4 from Pedro Alves --- That's a good point. Maybe a mangling/demangling hash/cache would help with that, though can't beat 0 work.

[Bug demangler/70909] Libiberty Demangler segfaults (4)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909 --- Comment #52 from Pedro Alves --- (In reply to Mark Wielaard from comment #51) > (In reply to Mark Wielaard from comment #50) > > But maybe the cplus_demangle_fill_xxx functions should do this initializing > > instead? In that case gdb only ne

[Bug debug/80263] New: gcc's internal type "sizetype" leaks out as base type name in the DWARF info

Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- In the full example below, note: ~~ <1>&

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263 --- Comment #1 from Pedro Alves --- The consequence is that that internal type's name can mask out a user-defined type with the same name. For example: $ cat sizetype2.c char array[1]; typedef struct sizetype { char c; } sizetype; sizetype sz;

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263 --- Comment #3 from Pedro Alves --- Possible solutions could be: #1 - emit the underlying type instead. #2 - emit no name. #2 seems to be valid DWARF5, which says (page 103): "A base type entry may have a DW_AT_name attribute whose value is

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263 --- Comment #6 from Pedro Alves --- Yes, agreed. I haven't investigated yet why it ends up with that "", but it's likely that the hack was incomplete and that's a red herring. Hopefully GDB won't have some hard-to-eliminate dependency on a look

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263 --- Comment #7 from Pedro Alves --- I filed a corresponding GDB bug here: Support DW_TAG_base_type with no name https://sourceware.org/bugzilla/show_bug.cgi?id=21335

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #4

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #6 from Pedro Alves --- Hmm. I'd argue that __builtin_constant_p should return true in that case, since we're in a constexpr? In any case, changing the test like this: - if (__builtin_constant_p (s)) + if (__builtin_constant_p

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #7 from Pedro Alves --- TBH, though I do think being able to use different algorithms for compile/runtime is useful and a good idea, making the __builtin_strlen etc. builtins works OOTB would of course be great. I'm merely suggesting

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #9 from Pedro Alves --- FWIW, I've tried to poke a bit more at this, to try to make it _not_ work, but couldn't. It seems to always do what we need. These all work/compile too: constexpr int

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #11 from Pedro Alves --- Ok, so s[2] is not constant, while s[0] is, in that case. AFAICS, changing constexpr_strlen to this: constexpr size_t constexpr_strlen(const char* s) { const char *p = s; while (__builtin_constant_p (*p

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #12 from Pedro Alves --- This seems to work equally well (or better): // true if the whole string is known at compile time. static inline constexpr bool constant_string(const char *s) { while (__builtin_constant_p (*s) && *s) s

[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #14 from Pedro Alves --- AFAIK, the "if constexpr()" proposal was sent back for more work [1], seems premature to support it, while I'd hope that the __builtin_constant_p approach would allow supporting constexpr char_traits in GCC7 (

[Bug c++/82594] New: Please provide better parameter / argument mismatch warnings/notes

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- While working on GDB, I came across a case where I wish GCC's diagnostics could have spared me a few greps. Here, reduced: ~~~ s

[Bug bootstrap/82610] [8 Regression] Bootstrap fails on macOS 10.13 and FreeBSD 11.1 because of abort redefinition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82610 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #4

[Bug c++/70909] Libiberty Demangler segfaults (4)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #3

[Bug other/61233] Demangler crash (GDB PR 16957)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61233 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #1

  1   2   >