https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154
--- Comment #8 from Carlos Galvez ---
Actually in the patch that would address this issue for Clang
(https://reviews.llvm.org/D53860), they mentioned 2277:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0968r0.html#2227
With emphasi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117046
--- Comment #8 from Carlos Galvez ---
Sorry, I commented on the wrong bug, could some admin please delete my last
comment? Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117046
--- Comment #7 from Carlos Galvez ---
Actually in the patch that would address this issue for Clang
(https://reviews.llvm.org/D53860), they mentioned 2277:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0968r0.html#2227
With emphasi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154
--- Comment #7 from Carlos Galvez ---
Hi! I had another look at this an have some follow-up questions:
> it looks like GCC already implements the suggested resolution.
This does not seem to be the case? The related bug is
https://gcc.gnu.org/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154
--- Comment #6 from Carlos Galvez ---
Alright reading Richard's comment I now understand he's not implying current
behavior is correct, but rather explaining why it happens. I take it then that
this is a bug in Clang then. Thanks for the clarifi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154
--- Comment #3 from Carlos Galvez ---
Please note that this ticket is about protected *destructor*. For protected
*constructor*, clang has same behavior as GCC.
CWG 2244 does not appear to consider this case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154
Bug ID: 117154
Summary: Aggregate initialization with protected destructor in
Base class: GCC vs Clang difference
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117046
--- Comment #6 from Carlos Galvez ---
Ah, that might explain it. It would be great to document the additional logic
to avoid confusion.
It may also help the LLVM folks implementing the same warning with consistent
behavior to GCC:
https://gith
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117046
--- Comment #2 from Carlos Galvez ---
I also don't understand why the warning fires at all in this case. Even if we
pass &bytes, we are passing an object of type 'std::array' which is
trivially-copyable (and even trivial?), so I don't see why it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117046
Bug ID: 117046
Summary: -Wclass-memaccess provides misleading diagnostics on
std::memcpy
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95701
Carlos Galvez changed:
What|Removed |Added
CC||carlosgalvezp at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106294
Carlos Galvez changed:
What|Removed |Added
CC||carlosgalvezp at gmail dot com
--- Comm
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: normal
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
Se
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
Compo
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 wh
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: linea
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&action=edit
Reproducible example nvinfer
Attaching (hopefully) reproducible example as a tarball, containing:
- download
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 linear_search_fde
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 c
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 s
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 exceptions
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 n
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
P
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://go
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 'Ei
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
Severi
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 - sinc
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 w
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 W
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 invarian
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 + int(_S_thres
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 offs
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
Pri
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
S
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
Severit
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, 5
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&action=edit
Preprocessed source
Attaching preprocessed source. Had to use a tarball since it exceeds the 1 MB
limit. Alter
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 out-of-bo
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
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
Carlos Galvez changed:
What|Removed |Added
CC||carlosgalvezp at gmail dot com
--- Comme
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 f
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
--- Comme
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
C
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
--enable-lan
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 lik
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 act
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: drive
83 matches
Mail list logo
