https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
--- Comment #3 from Carlos Galvez ---
Thanks for the quick response! Unfortunately we are stuck on GCC 9 for reasons
so I'll try to shuffle the code around a bit to make it work :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
Bug ID: 111714
Summary: Strange behavior when casting std::size_t to bool, UB
or compiler bug?
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=00
Bug ID: 00
Summary: Use extern "C" for __gcov_dump and related functions
in gcov.h
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561
--- Comment #5 from Carlos Galvez ---
@Andrew Pinski ping in case you missed my last message. If this were a
duplicate but, wouldn't it also happen in GCC 7.5.0?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561
--- Comment #4 from Carlos Galvez ---
To clarify, the .gcov file looks like this (correct) on GCC 7.5.0, which I
believe is newer than the duplicated bug mentioned here:
-:0:Source:main.cpp
-:0:Graph:main.gcno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561
--- Comment #3 from Carlos Galvez ---
I forgot to clarify that this bug is _not_ present on gcc 7.5.0 (from where we
are bumping), so I believe it's a regression in that regard. Do you still
believe it's a duplicate of the bug mentioned above?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561
Bug ID: 110561
Summary: gcov counts closing bracket in a function as
executable, lowering coverage statistics
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395
Bug ID: 110395
Summary: GCOV stuck in an infinite loop with large std::array
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #29 from Carlos Galvez ---
*my comment about uninitialized "ob.s.b.encoding".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #28 from Carlos Galvez ---
The proposed patch fixes the issue on our side, thank you!
I realize my comment about doesn't make sense - I was mixing unions in C (where
type punning is fine) and C++ (UB). But then I don't understand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #25 from Carlos Galvez ---
Perhaps this is a stupid comment, but isn't "ob.s.b.encoding" uninitialized?
/* inside find_fde_tail */
struct object ob;
...
ob.pc_begin = NULL;
ob.tbase = NULL;
ob.dbase = (void *) dbase;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #22 from Carlos Galvez ---
Indeed it's an uninitialized read according to valgrind:
==15475== Use of uninitialised value of size 8
==15475==at 0x1E81C2E9: base_from_object (unwind-dw2-fde.c:319)
==15475==by 0x1E81C2E9:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #18 from Carlos Galvez ---
Thanks for the investigation! To clarify: my last reproducible example does not
use gold, instead it uses the default GNU ld version 2.38.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #15 from Carlos Galvez ---
Created attachment 55261
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55261=edit
Reproducible example nvinfer
Attaching (hopefully) reproducible example as a tarball, containing:
- download.sh:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #12 from Carlos Galvez ---
I just tested latest and greatest trunk (git commit
2415024e0f81f8c09bf08f947c790b43de9d0bbc) and the problem persists. Slightly
different line numbers but essentially same backtrace:
#0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #10 from Carlos Galvez ---
Hi!
I've continued to look into this and am having a slightly different but
essentially same error with yet another Nvidia library, but this time is with a
pure shared library, "libnvinfer.so", which was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #8 from Carlos Galvez ---
Upon closer inspection, it turns out we were building with GCC 7, but then
using libgcc_s.so.1 and libstdc++.so.6 from GCC trunk at runtime (via
LD_LIBRARY_PATH). Building with GCC trunk instead solves the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #6 from Carlos Galvez ---
Hi again!
I realized there is still one more problem missing, so I suspect the linker was
not the only culprit. It does not segfault, but it gets stuck in an infinite
loop, once again when mixing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745
--- Comment #8 from Carlos Galvez ---
Thanks a lot for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745
--- Comment #1 from Carlos Galvez ---
In case it wasn't clear: the test passes also on O0 - it only fails when
increasing from O1 all the way to O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745
Bug ID: 109745
Summary: Incorrect code generated with -O1 when having a
constexpr object modifying a mutable member
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Carlos Galvez changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #4 from Carlos Galvez ---
> Does libcudart_static.a by chance contain any symbols from the libgcc runtime
I'm not sure, do you know how I could check that (I'm pretty n00b on these
things :)). What I know is that libcudart.so does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Bug ID: 109712
Summary: Segmentation fault in linear_search_fdes
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
--- Comment #5 from Carlos Galvez ---
This commit fixes all the ICEs on our side, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #8 from Carlos Galvez ---
> Please don't close bugs as FIXED
I did choose INVALID, was that not correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
--- Comment #6 from Carlos Galvez ---
Sounds great, thanks for the quick response! I believe "-Wall -Wextra" is the
"bare minimum" set of warnings for most projects so I'm afraid people might
still need to disable it via "-Wno*".
Adding some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109669
Bug ID: 109669
Summary: Internal Compiler Error when zero-initializing
std::array
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
Carlos Galvez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #2 from Carlos Galvez ---
I could reduce it to a simpler self-contained example:
struct Foo;
Foo const& foo_maker();
struct Bar
{
explicit Bar(Foo const&);
};
void baz()
{
Bar const& b{foo_maker()};
}
Godbolt:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #1 from Carlos Galvez ---
I forgot to write the actual error I'm getting:
: In function 'int main()':
:11:41: error: converting to 'const MyVector' {aka 'const
Eigen::Matrix'} from initializer list would use explicit
constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
Bug ID: 109663
Summary: False positive? Converting from initializer list would
use explicit constructor
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
--- Comment #4 from Carlos Galvez ---
While I can do that on my own code, I cannot add that suppression on
third-party code, like Eigen (which I also get a lot of false positives in
similar code), even if I include the header via -isystem -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
--- Comment #2 from Carlos Galvez ---
Is there a way to tag classes to mark them for exclusion? Currently the warning
is part of -Wall and leads to many false positives. The warning message also
says "possibly" dangling reference. In my opinion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
Bug ID: 109642
Summary: False Positive -Wdangling-reference with
std::span-like classes
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #11 from Carlos Galvez ---
Consider this more realistic example:
https://godbolt.org/z/jbbqbe8d9
The compiler has all the information available to ensure that getCount().get()
is smaller than 3, as enforced by the class invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #8 from Carlos Galvez ---
I see!
In that case may I suggest to split the diagnostic into "Warray-bounds" and
"Wmaybe-array-bounds"? That way we could enable the first and disable the
second. The way it is today, we need to disable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #6 from Carlos Galvez ---
A similar case in the real world would be this:
NumberSmallerThan3 getCount();
std::sort(data.begin(), data.begin() + static_cast(getCount()));
The "NumberSmallerThan3" class holds and checks the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #5 from Carlos Galvez ---
> is not good programming practice.
Sure. In the real world, we have asserts for this. However this is a problem
when we build for Release mode, in which asserts are disabled and thus this
warning pops up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #2 from Carlos Galvez ---
Looking deeply at the stacktrace, I see that std::sort ends up in this kind of
code:
if (__last - __first > int(_S_threshold))
{
std::__insertion_sort(__first, __first +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
Bug ID: 107699
Summary: False positive -Warray-bounds, non-existent offset
reported by GCC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677
--- Comment #5 from Carlos Galvez ---
Wow, that was mind blowing, thanks for the clarification! Such thing I'd like
to have in the docs, it's very easy to confuse with the other message:
note: at offset 48 into object '' of size 48
So one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677
--- Comment #3 from Carlos Galvez ---
The warning message is also hard to decipher. For example, what does this mean?
error: array subscript [-536870912, -1] is outside array bounds
What is a 2-dimensional subscript applied on a 1D array?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677
--- Comment #2 from Carlos Galvez ---
This is a general question which I hope can be answered without a full report.
My particular example gets a warning deep into Eigen-like code so it's not easy
to provide a minimal example.
My questions are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677
Bug ID: 107677
Summary: -Warray-bounds: unclear what exactly it's meant to
detect
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107361
--- Comment #2 from Carlos Galvez ---
I understand the motivation and I think the warning makes a lot of sense!
However I don't see how it could possibly be dangerous in the provided example.
Would it suffice to trigger the warning only when a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107361
Bug ID: 107361
Summary: Why does -Wclass-memaccess require trivial types,
instead of trivially-copyable types?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107290
Bug ID: 107290
Summary: False positive -Wuninitialized with Eigen
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106925
--- Comment #8 from Carlos Galvez ---
Awesome, thanks a lot for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107252
--- Comment #2 from Carlos Galvez ---
To clarify, even removing things from the second function has an impact on the
first function (which is where the warning comes from). Shouldn't both
functions be independent?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107252
Bug ID: 107252
Summary: False positive stringop-overflow, warning disappears
if I remove unrelated code!
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901
--- Comment #7 from Carlos Galvez ---
I understand the reasoning, but the loop _can_ executed in other cases where
the function is called with different arguments:
bar(vec, 5, 5); // Warray-bounds, loop not executed, no runtime OOB.
bar(vec,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200
Carlos Galvez changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200
--- Comment #2 from Carlos Galvez ---
Created attachment 53688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53688=edit
Preprocessed source
Attaching preprocessed source. Had to use a tarball since it exceeds the 1 MB
limit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200
Bug ID: 107200
Summary: False positive -Wdangling-pointer?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106925
--- Comment #2 from Carlos Galvez ---
Hi, is there any progress on the issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106925
Bug ID: 106925
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901
--- Comment #5 from Carlos Galvez ---
I also would like to understand why the warning is not triggered if the first
"if (size < expected_size)" is removed.
https://godbolt.org/z/7vqPxhsqo
The possibility of executing the loop and do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901
--- Comment #4 from Carlos Galvez ---
Makes sense!
Would it make sense to classify this as "maybe-array-bounds" instead? Similar
to "maybe-uninitialized" vs "uninitialized"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901
--- Comment #2 from Carlos Galvez ---
If size == 5, expected_size == 5, then the loop is not executed, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901
Bug ID: 106901
Summary: False positive -Warray-bounds with -O2 or higher?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
Carlos Galvez changed:
What|Removed |Added
CC||carlosgalvezp at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103862
--- Comment #3 from Carlos Galvez ---
Interesting, thanks for the quick reply! In case it helps, if I include the
header as a regular header, I do get the "note" referring to the system header:
# g++-11 -I include -Wold-style-cast main.cpp
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103862
--- Comment #1 from Carlos Galvez ---
The problem exists also in GCC 9.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12258
Carlos Galvez changed:
What|Removed |Added
CC||carlosgalvezp at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103862
Bug ID: 103862
Summary: Regression: -Wold-style-cast warns about system macros
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803
Carlos Galvez changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803
--- Comment #6 from Carlos Galvez ---
Hmm I don't see that in the x86 version of Ubuntu GCC:
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803
--- Comment #4 from Carlos Galvez ---
Thanks a lot for the detailed answer! That's very interesting, so it can
actually have to do with how the Ubuntu version has been built. I'll definitely
give it a try building locally.
Your output looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803
--- Comment #2 from Carlos Galvez ---
Did you read my detailed explanation and reproducible example? I took great
care and time to make the problem easy to investigate. GCC is not doing what is
supposed to do. Other compilers, like Clang, do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803
Bug ID: 102803
Summary: Bug: -no-canonical-prefixes not working
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
71 matches
Mail list logo
