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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850
Bug ID: 109850
Summary: ICE compiling ccache 4.8
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740
Bug ID: 109740
Summary: -Woverloaded-virtual is too aggressive
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
Bug ID: 109720
Summary: -Wmaybe-uninitialized triggering when I can see no
path that would allow it
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717
Bug ID: 109717
Summary: -Warray-bound error with gnu++20 and fmt library
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
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
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
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
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".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487
Bug ID: 105487
Summary: Sysroots without 32bit components cause mysterious
errors
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98055
Bug ID: 98055
Summary: __builtin_alloca should not have warn_unused_result
attribute
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
25 matches
Mail list logo
