https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104343
--- Comment #7 from Frank Heckenbach ---
#3 points out "Also, GCC 7 has been unsupported for a couple of years." My new
"duplicate" report shows that the problem still exists with current versions.
You might want to update the version number to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114362
Bug ID: 114362
Summary: wrong error message "too many arguments" with
overloaded function
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114248
Bug ID: 114248
Summary: invalid "scalar object" error
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114113
Bug ID: 114113
Summary: bogus -Walloc-zero warning
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114110
Bug ID: 114110
Summary: unhelpful message about non-movable types
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113854
--- Comment #4 from Frank Heckenbach ---
(In reply to Jonathan Wakely from comment #1 and #2)
> [...] than to get errors deep inside an instantiation stack.
But they are deep in the stack; maybe not an instantiation stack, but a
requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113854
Bug ID: 113854
Summary: the expression 'is_invocable_v ... evaluated to
'false'
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113839
--- Comment #3 from Frank Heckenbach ---
> Except C++ parsing does not allow for that because C++ parsing requires
> unlimited look ahead.
While that's true in general, I think in specific cases (including most
real-world cases), the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113839
Bug ID: 113839
Summary: misleading syntax error message
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111301
Bug ID: 111301
Summary: misleading messages about missing "inline"
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111281
--- Comment #8 from Frank Heckenbach ---
I don't suggest to get rid of the warning. As I said in #3, if it's hard to
track, a more inclusive wording seems fine to me.
But my main grief about this message is the lack of context, i.e. the really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111281
--- Comment #4 from Frank Heckenbach ---
FWIW, as stated, the lack of context in the message made it hard to find the
actual location of the bug in my code -- in the end even harder than I had
expected since it was well hidden.
Fortunately I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111281
--- Comment #3 from Frank Heckenbach ---
Thanks for the additional info. I still think it would be useful if the message
told me that, rather than you. ;)
- 'nonnull' is a GCC attribute, and quoting it makes it look like it refers to
that,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111281
Bug ID: 111281
Summary: unhelpful warning output ('nonnull' argument 'v'
compared to NULL)
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40
Bug ID: 40
Summary: wrong error message
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110312
--- Comment #2 from Frank Heckenbach ---
(In reply to Andrew Pinski from comment #1)
> The decl has the increased alignment but the type does not in this case.
>
> So I think the warning is still correct.
So there's no way around it other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110312
Bug ID: 110312
Summary: -Wcast-align=strict warning despite alignas
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92707
Frank Heckenbach changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109571
--- Comment #3 from Frank Heckenbach ---
Thanks for the explanation, that was really helpful.
If I understand it correctly, since B has a vtable and A doesn't, upcasting
means to add some offset to the pointer, but of course not if it's null.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109571
Bug ID: 109571
Summary: potential null pointer dereference
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
--- Comment #6 from Frank Heckenbach ---
(In reply to Frank Heckenbach from comment #4)
> Thanks.
>
> I just got another similar one, this time with string.insert. But I guess
> it's pointless to dissect this one, or do you need more examples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
--- Comment #4 from Frank Heckenbach ---
Thanks.
I just got another similar one, this time with string.insert. But I guess it's
pointless to dissect this one, or do you need more examples for your test
suite?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
--- Comment #5 from Frank Heckenbach ---
> Agreed, but you asked for it with that option.
Nope, I asked for warnings about signed integer overflow.
> So you shouldn't have to care about begin(c) < end(c) either, it has to be
> true. But you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
--- Comment #1 from Frank Heckenbach ---
At least I found a work-around (for now): Moving, rather than copying the
(emtpy) shared_ptr parameter to the (unused) shared_ptr member avoids the
warning.
Still, I'd like to know if this is an actual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109569
Bug ID: 109569
Summary: warning: ‘void* __builtin_memmove(void*, const void*,
long unsigned int)’ writing 1 or more bytes into a
region of size 0 overflows the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
--- Comment #2 from Frank Heckenbach ---
Maybe technically correct, but not useful to the user.
The user's code doesn't involve pointers at all. It makes two queries about a
span object. As the user, I don't even (and shouldn't have to) care
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
Bug ID: 109565
Summary: -Wstrict-overflow false positive
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
--- Comment #2 from Frank Heckenbach ---
Since I can't easily upgrade to trunk, I need to know if the warning is bogus
in 12.2 and I can safely disable it, or do I need to worry about the generated
code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
Bug ID: 109563
Summary: accessing 9223372036854775810 or more bytes at offsets
[2, 9223372036854775807] and 1 may overlap up to
9223372036854775813 bytes at offset -3 [-Wrestrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109561
Bug ID: 109561
Summary: -Wmaybe-uninitialized false positive false positive
false positive false positive false positive
Product: gcc
Version: 12.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109550
--- Comment #2 from Frank Heckenbach ---
It might be useful then to actually say to in the warning, e.g. "p[...] may be
used uninitialized". This might have saved me some debugging effort.
But actually, that's not all. This code still gives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109550
Bug ID: 109550
Summary: warning: "p" may be used uninitialized
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508
--- Comment #6 from Frank Heckenbach ---
Yet ironically, char8_t and char16_t are meant to be used with a certain
encoding (UTF-8 and UTF-16, respectively) which is locale-independent, whereas
char is very much locale-dependent (with even EBCDIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508
--- Comment #4 from Frank Heckenbach ---
(In reply to Jonathan Wakely from comment #3)
I don't think my description is "completely wrong". I'm basically saying the
same as you, in plain English.
char8_t was introduced as the preferred type for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508
Frank Heckenbach changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109367
--- Comment #2 from Frank Heckenbach ---
My full testcase consists of many includes files, libraries etc.
The type declarations (corresponding to the first two lines of the
stripped-down example) are in a header to be called from other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109367
Bug ID: 109367
Summary: bogus -Wunused-function warning
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104577
--- Comment #3 from Frank Heckenbach ---
(In reply to mail from comment #2)
> I looked a bit further into this and into what the standard says. GCC does
> partially the correct thing in this case, whereas several other compilers do
> the wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106774
--- Comment #6 from Frank Heckenbach ---
> --- Comment #4 from Eric Gallager ---
> (In reply to Richard Biener from comment #3)
> > that's more coding style though?
>
> Yeah I personally prefer the more explicit way of writing it with both
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106774
--- Comment #2 from Frank Heckenbach ---
This should cover all cases mentioned:
void t (bool a, int i, float e, double f)
{
// Boolean literal comparisons
if (a == true) // better: if (a)
return;
if (a == false) // better: if (!a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106774
Bug ID: 106774
Summary: warning about comparison to true/false
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523
Frank Heckenbach changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97165
--- Comment #8 from Frank Heckenbach ---
Actually not infinite, just very many, see 106549.
(Can the title be changed? It's why I didn't see this as a possible duplicate.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106549
Bug ID: 106549
Summary: excessive error messages with nested undefined
template
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103724
--- Comment #7 from Frank Heckenbach ---
(In reply to Richard Biener from comment #6)
> (In reply to Frank Heckenbach from comment #5)
> > (In reply to Richard Biener from comment #4)
> > > One thing we could do is annotate struct loop * with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104577
Bug ID: 104577
Summary: needs copy constructor to call method of class
non-type template parameter
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
--- Comment #10 from Frank Heckenbach ---
If it was me, it wasn't intentional, sorry.
The select box on the web form defaults to "FIXED" for me even on reload (F5).
I had to click on the link to itself to get a clean form (set to "DUPLICATE").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
Frank Heckenbach changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #7 from Frank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
--- Comment #5 from Frank Heckenbach ---
As I replacement, I'll use the following code. It's a simple double-checked
lock, probably not as efficient as the original, but seems to work.
Posted here as RFC and for anyone else who encounters the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
--- Comment #4 from Frank Heckenbach ---
Indeed, it has 2.31.
2.34 is only just in Debian experimental, and apparently not available as a
backport.
Since I need my code to run on various systems and I can't realistically
compile a new glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
--- Comment #2 from Frank Heckenbach ---
% g++ -print-multiarch
x86_64-linux-gnu
Debian 11.2, Linux 5.10.0-9-amd64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104495
Bug ID: 104495
Summary: call_once hangs in call after exceptional call
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104494
Bug ID: 104494
Summary: -Wsuggest-attribute=noreturn catch 22
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104231
Bug ID: 104231
Summary: private ignored in non-type template parameter
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69818
Frank Heckenbach changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103724
--- Comment #5 from Frank Heckenbach ---
(In reply to Richard Biener from comment #4)
> One thing we could do is annotate struct loop * with the (high level)
> optimizations we've applied so that when we emit this warning we could say
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061
--- Comment #3 from Frank Heckenbach ---
(In reply to Patrick Palka from comment #2)
> How do you define it? It works if we define it as
>
> auto operator <=> (const B& b) const {
> return A::operator<=>(b);
> }
>
> but not if it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061
Frank Heckenbach changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103947
Bug ID: 103947
Summary: wishlist: warning if explicitly defaulted (spaceship)
operator is deleted
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103725
Bug ID: 103725
Summary: warning: assuming signed overflow does not occur when
simplifying conditional to constant
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103724
Frank Heckenbach changed:
What|Removed |Added
Summary|warning |invalid warning: iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103724
Bug ID: 103724
Summary: warning
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103703
Bug ID: 103703
Summary: ICE with -Wmismatched-tags
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103098
--- Comment #2 from Frank Heckenbach ---
https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103098
Bug ID: 103098
Summary: bogus error: the last argument must be an 8-bit
immediate
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102921
--- Comment #1 from Frank Heckenbach ---
The following program, compiled with "-std=c++20" gives this error message; I
don't even understand what it's trying to tell me:
error: modification of '' is not a constant expression
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102921
Bug ID: 102921
Summary: error: modification of '' is not a constant
expression
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
67 matches
Mail list logo
