[Bug debug/54533] breakpoint on C-style variadic function not hit at -O0 on amd64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533 Paul Smith psmith at gnu dot org changed: What|Removed |Added CC||psmith at gnu dot org

[Bug debug/47471] [4.7/4.8/4.9 Regression] stdarg functions extraneous too-early prologue end

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471 Paul Smith psmith at gnu dot org changed: What|Removed |Added CC||psmith at gnu dot org

[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586 Paul Smith psmith at gnu dot org changed: What|Removed |Added CC||psmith at gnu dot org

[Bug c/58467] New: Documentation of the used variable attribute needs additional information

: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org The used variable attribute in the GCC documentation (gcc/doc/extend.texi, section Variable Attributes) says that it can be attached to a variable. However

[Bug other/58467] Documentation of the used variable attribute needs additional information

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467 --- Comment #1 from Paul Smith psmith at gnu dot org --- Housekeeping: it would be very nice to have a Doc component in bugzilla. As it was I picked c because it was that part of the docs. Thx!

[Bug other/58467] Documentation of the used variable attribute needs additional information

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467 --- Comment #6 from Paul Smith psmith at gnu dot org --- A minor typo: - attached to a variable with the static storage, + attached to a variable with static storage, Also, I wonder if it might be helpful to be clear that it can ONLY be applied

[Bug other/58467] Documentation of the used variable attribute needs additional information

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467 --- Comment #5 from Paul Smith psmith at gnu dot org --- Thank you!

[Bug c/40548] New: If a dir on PATH contains a directory named gcc, badness ensues

AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: psmith at gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40548

[Bug c/40548] If a dir on PATH contains a directory named gcc, badness ensues

--- Comment #2 from psmith at gnu dot org 2009-06-25 05:00 --- Ah, thanks for the pointer. I did search before I created a new bug but wasn't successful in narrowing down my search to something reasonable. It would be nice if the real bug mentioned PATH in the summary; I was trying

[Bug libgomp/36442] New: libgomp fails when using --with-build-sysroot

ReportedBy: psmith at gnu dot org GCC target triplet: i686-generic-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36442

[Bug libgomp/36442] libgomp/libssp/libmudflap builds fail when using --with-build-sysroot

--- Comment #2 from psmith at gnu dot org 2008-09-04 17:34 --- I tried this with the latest stable, GCC 4.3.2, and I still had the same failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36442

[Bug bootstrap/51935] New: Configure fails on included mpc/mpfr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51935 Bug #: 51935 Summary: Configure fails on included mpc/mpfr Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: major Priority: P3

[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 psmith at gnu dot org changed: What|Removed |Added CC||psmith at gnu dot org --- Comment

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51935 --- Comment #1 from psmith at gnu dot org 2012-01-21 18:15:24 UTC --- Created attachment 26406 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26406 Handle both old and new MPFR dir layouts Added a new patch that works with both old and new

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51935 --- Comment #2 from psmith at gnu dot org 2012-01-21 18:17:23 UTC --- BTW, this is a duplicate of bug #50461

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51935 --- Comment #5 from psmith at gnu dot org 2012-01-21 18:54:37 UTC --- It's fine to close this bug as a dup as it's later than the other, but note I've attached a fix to this bug (there's no fix attached to the other) so please don't lose the patch

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51935 --- Comment #6 from psmith at gnu dot org 2012-01-21 23:24:18 UTC --- Created attachment 26407 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26407 Fix typo

[Bug preprocessor/48957] New: GCC's handling of include-fixed does not work well with --sysroot

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48957 Summary: GCC's handling of include-fixed does not work well with --sysroot Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c/48996] New: fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996 Summary: fixincl on Red Hat EL 5 breaks sys/stat.h fstat64() Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo:

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996 --- Comment #2 from psmith at gnu dot org 2011-05-16 11:56:33 UTC --- Created attachment 24251 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24251 Un-fixed sys/stat.h Yes, sorry, it was silly not to have done that.

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996 --- Comment #4 from psmith at gnu dot org 2011-05-16 15:07:40 UTC --- I'm attaching a small test program that fails for me. I'm just running the compiler with c++ -o tstfstat.o -c tstfstat.cpp; no extra flags. After looking more carefully I can

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996 --- Comment #5 from psmith at gnu dot org 2011-05-16 15:08:35 UTC --- Created attachment 24253 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24253 Test invocation of fstat64()

[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996 --- Comment #7 from Paul Smith psmith at gnu dot org --- I haven't seen this issue in a while and don't care enough to try to reproduce it or to have it reopened, but as far as I can see the problem was pretty clearly in the fixincl tool

[Bug c++/78147] New: The -Wshadow warning is too aggressive with constructor parameters

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- Created attachment 39918 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39918=edit Simple patch disables shadow warnings for c

[Bug c++/64431] "-Wignored-qualifiers" warning gives misleading position in code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64431 Paul Smith changed: What|Removed |Added CC||psmith at gnu dot org --- Comment #6 from

[Bug c++/81932] New: Template arguments of type unsigned generate incorrect debugging information

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- I've upgraded from GCC 6.2/binutils 2.27 to GCC 7.2/binutils 2.29 (compiled myself), running on GNU/Linux on x86_64. Everything

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #3 from Paul Smith --- Created attachment 42030 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42030=edit tv.py Test case attached. To run it: $ gcc -ggdb3 -o tvtest tvtest.cpp $ gdb tvtest -ex 'br 28' -ex 'source tv.py'

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #2 from Paul Smith --- Created attachment 42029 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42029=edit tvtest.cpp

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #7 from Paul Smith --- I'm not sure what the impacts of "if (pp->flags & pp_c_flag_gnu_v3)" are; does this mean it only works if you specify -ggdb3? Is that the right thing? I don't know what the differences are between the

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #12 from Paul Smith --- Xi Ruoyao (comment #9): > This works for: Excellent.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #16 from Paul Smith --- I'm not familiar with the implementations but I'm not sure we can expect GDB to be able to handle this situation, at least not with any sort of efficiency. It's already a difficult part of GDB's job, looking

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #19 from Paul Smith --- Hi; is there a next step for this? I understand there's some concern that we should be asking GDB to improve their capabilities but in the meantime can we get GCC to emit the previous format? It would be

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #25 from Paul Smith --- > (1) Find the mangled name of the vtable of tv. > (2) Demangle the name, to be 'vtable for TreeVector::Tree'. > (3) Skip 'vtable for ' and get 'TreeVector::Tree'. > (4) Lookup this symbol.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #23 from Paul Smith --- The lookup_type() was just to show the problem more clearly: I don't do that in my actual Python code. This part (or something similar) is what I use: class tv(gdb.Function): def __init__(self):

[Bug c++/85783] New: alloc-size-larger-than fires incorrectly with new[] and can't be disabled

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- Created attachment 44131 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44131=edit sample source file GCC 8.1.0 / binut

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783 --- Comment #2 from Paul Smith --- > Did you try: -Wno-alloc-size-larger-than ? Yes. cc1plus: error: unrecognized command line option '-Wno-alloc-size-larger-than' > Also in your code, numberFields is a signed int and then casted to size_t.

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783 --- Comment #4 from Paul Smith --- Well, clearly I disagree with this conclusion and feel this is a bug. At the very least, the fact that it's impossible to disable the warning needs to be considered a bug. The statement on the mailing list

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783 --- Comment #5 from Paul Smith --- I simplified my example too much; I think this should be re-opened. In my real code, operator new[] does not invoke exit(); it invokes my own function (which is defined as noreturn, but that's not required).

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783 --- Comment #7 from Paul Smith --- Is there a way (in standard C++) to force non-inline? I'm not aware of one. So that means the only standard-conforming way to replace operator new is if it's in its own compilation unit all by itself? I

[Bug c++/85783] alloc-size-larger-than fires incorrectly with new[] and can't be disabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85783 --- Comment #9 from Paul Smith --- Sorry; Andrew's original reply seemed to say that the use-case is non-conforming so the issue was WONTFIX. I also thought your comment #6 was referring to my example in comment #5: I just wanted to clarify

[Bug c++/85965] New: G++ gives cryptic error instead of incomplete type

Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- Compiling code with GCC 8.1 / binutils 2.30 (built locally on GNU/Linux amd64) which previously compiled and worked OK with GCC 6.2 and 7.3. I received a very cryptic error

[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147 --- Comment #3 from Paul Smith --- Unfortunately not because I never had time to do more than the patch attached here: in particular I didn't hook it up to any command-line arguments, nor did I add regression tests for it. I didn't think it

[Bug libstdc++/85965] [8/9 Regression] G++ gives cryptic error instead of incomplete type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965 --- Comment #4 from Paul Smith --- Oops sorry: I guess I'm not familiar enough with the vagaries of the bug trackers :). Thanks Jonathan!

[Bug pch/90306] ICE when using precompiled headers with -MD and -fpch-deps

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90306 --- Comment #2 from Paul Smith --- Yes that seems like it would definitely solve the ICE. But then this bug report changes to say that the output of -fpch-deps is wrong (it's empty when it shouldn't be) :p :). That would potentially cause

[Bug pch/90306] New: ICE when using precompiled headers with -MD and -fpch-deps

Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- I've seen this issue both with GCC 8.1.0 and the latest GCC 9.0.1 20190430 pre-release, on GNU/Linux x86_64 with binutils 2.30 and 2.32 (not that I

[Bug middle-end/98055] __builtin_alloca should not have warn_unused_result attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055 --- Comment #2 from Paul Smith --- I see no resolution to that thread, but the current behavior of GCC in this respect is not right and Martin Sebor's arguments are missing the point: the thinking there is too GCC-centric. Whether or not

[Bug c/98055] New: __builtin_alloca should not have warn_unused_result attribute

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- Code that wants to use alloca() and still be portable will often include replacements where memory is allocated on the heap, and the user

[Bug middle-end/98055] __builtin_alloca should not have warn_unused_result attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055 --- Comment #5 from Paul Smith --- IMO that response is missing the point. This bug should be reopened and resolved by removing this attribute from the __builtin_alloca function in GCC. That's all that's needed: there's no need for more

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #32 from Paul Smith --- No movement AFAIK. It's apparently the tip of a particularly gross iceberg. It doesn't seem like partial measures appeal to people, and no one has the needed combination of time, knowledge, and contacts to

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #9 from Paul Smith --- Just to note, there are similar needs for empty directories in the GCC installation itself; for example in a GCC install of a 64bit compiler without 32bit support this directory will be created by the

[Bug bootstrap/105487] New: Sysroots without 32bit components cause mysterious errors

Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- I first reported this issue here: https://gcc.gnu.org/pipermail/gcc/2020-August/233361.html I said I would file a bug but I don't see any

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #1 from Paul Smith --- Ugh, when I wrote "doesn't contain any 32bit values" I meant "doesn't contain any 32bit files".

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #3 from Paul Smith --- There's nothing "incorrect" about a sysroot that doesn't have /usr/lib in it. If you have a 64bit system and you don't need to run 32bit binaries, then /usr/lib will be empty and everything will be in

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #6 from Paul Smith --- If it is really required, then the GCC configure script or makefile or something should detect this situation and fail. There's nothing in the current build system or documentation that says this is needed

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #7 from Paul Smith --- Just to be clear when I say "Build GCC with that directory as the sysroot" I mean something like this: ../gcc-11.3.0/configure --with-sysroot=/sysroot ...

[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78147 --- Comment #7 from Paul Smith --- I don't really think this change is related to -Wunused-private-field: at least I don't see any relationship. My personal preference would be to not even bother to create an option for this; I think that GCC

[Bug c++/109720] New: -Wmaybe-uninitialized triggering when I can see no path that would allow it

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- I recently upgraded to GCC 13.1 and when building some code that uses boost::dynamic_bitset I'm seeing the -Wmaybe-ininitialized

[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #1 from Paul Smith --- Hm, maybe it's due to the union. Maybe GCC can't grok that we ensure that we only use the dynamic_bitset leg of the union after we've initialized it? I wonder if this warning could just assume that if the

[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #3 from Paul Smith --- Created attachment 54986 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54986=edit bitset.i.gz compressed preprocessor output Hm, I did attach it when I filed the bug; I guess I forgot to click some

[Bug tree-optimization/109717] -Warray-bound error with gnu++20 and fmt library

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 --- Comment #3 from Paul Smith --- OK, well, we don't have to say "broken"; all I know is that perfectly respectable code that used to work without triggering these warnings in older versions of GCC, and with older -std=c++..., is now failing

[Bug c++/109850] ICE compiling ccache 4.8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850 Paul Smith changed: What|Removed |Added CC||psmith at gnu dot org --- Comment #1 from

[Bug c++/109850] ICE compiling ccache 4.8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850 --- Comment #2 from Paul Smith --- I don't know if this is of any use but I ran under valgrind and get this result: ==3019683== Command: /data/src/build/x86_64-linux/cc/unknown/bin/../libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus

[Bug c++/109850] New: ICE compiling ccache 4.8

++ Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- I've started working with GCC 12.3.0 I've built myself and I've gotten an ICE trying to compile ccache 4.8. The preprocessor output is attached. I'm building using a sysroot from a Rocky Linux 8.4

[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #7 from Paul Smith --- Just to note this code also throws this warning in GCC 12.3 but it doesn't complain in GCC 11.3 which is what I was using before.

[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720 --- Comment #6 from Paul Smith --- I'm happy to provide the source for DynamicBitSet (it's basically a union of a uint64_t and a boost::dynamic_bitset so that if you have <=64 bits you use the uint64_t and if you have >64 bits you use

[Bug tree-optimization/109717] -Warray-bound error with gnu++20 and fmt library

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 --- Comment #9 from Paul Smith --- > Now they're issued even when the "problem" is in a system header. Oh interesting: I have been in the habit of including all my 3rdparty library headers using -isystem to avoid worrying about warnings/errors

[Bug c++/109717] -Warray-bound error with gnu++20 and fmt library

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 --- Comment #1 from Paul Smith --- This same test case also causes spurious errors for -Wstringop-overflow :( If I use this compile line with the same source file, I get these errors: $ g++-13.1 -I/data/src/build/common/fmt/include

[Bug c++/109740] -Woverloaded-virtual is too aggressive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740 --- Comment #2 from Paul Smith --- What I'm trying to say is that it's not useful (to me) for GCC to warn about code that I could maybe write in the future but didn't actually write, and which if I did write it would generate a compiler error

[Bug c++/109740] New: -Woverloaded-virtual is too aggressive

++ Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- I understand the impetus for the -Woverloaded-virtual warning but I think it should be further constrained, or maybe broken into levels of severity that can be enabled. The issue I'm

[Bug c++/109717] New: -Warray-bound error with gnu++20 and fmt library

Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: psmith at gnu dot org Target Milestone: --- Created attachment 54983 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54983=edit fmt1.i preprocessor output (compressed) I found SO MANY issues related to -War