https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740
Paul Smith changed:
What|Removed |Added
Version|13.1.0 |14.2.0
--- Comment #6 from Paul Smith ---
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.
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
-fprepro
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
++
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 fr
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 an
++
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&#
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
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 boost::dyn
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&action=edit
bitset.i.gz compressed preprocessor output
Hm, I did attach it when I filed the bug; I guess I forgot to click so
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 cod
: 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-ininitia
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 in
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 -std=gnu++2
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&action=edit
fmt1.i preprocessor output (compressed)
I found SO MANY issues rel
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 sh
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 installer
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 ...
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 and
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 /usr/lib
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".
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 se
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 at
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 complex
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 builtin
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 is
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 build
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 t
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!
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 woul
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
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 that
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 don't
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). T
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 fro
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.
erity: 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&action=edit
sample source fil
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.
Right, and this is
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):
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 grea
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 u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932
--- Comment #12 from Paul Smith ---
Xi Ruoyao (comment #9):
> This works for:
Excellent.
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 differen
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&action=edit
tv.py
Test case attached. To run it:
$ gcc -ggdb3 -o tvtest tvtest.cpp
$ gdb tvtest -ex 'br 28' -ex 'source tv.
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&action=edit
tvtest.cpp
: 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. Every
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&action=edit
Simple patch disables shadow warni
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996
--- Comment #7 from Paul Smith ---
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 that comes with GCC. I don't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586
Paul Smith changed:
What|Removed |Added
CC||psmith at gnu dot org
--- Comment #4 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471
Paul Smith changed:
What|Removed |Added
CC||psmith at gnu dot org
--- Comment #11 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533
Paul Smith changed:
What|Removed |Added
CC||psmith at gnu dot org
--- Comment #4 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467
--- Comment #5 from Paul Smith ---
Thank you!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467
--- Comment #6 from Paul Smith ---
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
to variables with stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467
--- Comment #1 from Paul Smith ---
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!
Severity: 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
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
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
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
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
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
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
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()
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 look
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.
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: una
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
C
--- 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 summar
Severity: normal
Priority: P3
Component: c
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
--- 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
ed at gcc dot gnu dot org
ReportedBy: psmith at gnu dot org
GCC target triplet: i686-generic-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36442
71 matches
Mail list logo
