https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107898
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-11-29
Component|tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #28 from Florian Weimer ---
(In reply to Peter Cordes from comment #27)
> (In reply to Alexander Monakov from comment #26)
> > Sure, the right course of action seems to be to simply document that atomic
> > types and built-ins are me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107906
Richard Biener changed:
What|Removed |Added
Keywords||ABI
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107907
Bug ID: 107907
Summary: weak integer constant not linked correctly
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336
--- Comment #3 from Helmut Grohne ---
I suppose that your changes have migrated to gcc-12 now. The problem persists
in exactly the same way. A current build failure can bee seen at:
https://crossqa.debian.net/build/gcc-12_12.2.0-9_s390x_202211101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107908
Bug ID: 107908
Summary: A null pointer dereference bug was missed by UBsan at
-O0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107906
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.1.2
Summary|Function templ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515
--- Comment #6 from Kevin Bracey ---
Retesting the Godbolt on trunk, it's now worse - every line produces multiple
not-very-informative errors:
source>:7:9: error: '_Generic' specifies two compatible types
7 | x = vmulq(x, 0.5); // ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #14 from Rama Malladi ---
This fix also improved performance of 538.imagick_r by 15%. Did you have a
similar observation? Thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107908
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107908
--- Comment #2 from Andrew Pinski ---
If you used -ftrivial-auto-var-init=zero you would get the runtime error:
/app/example.cpp:6:5: runtime error: load of null pointer of type 'int'
With -ftrivial-auto-var-init=pattern you get:
/app/example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107909
Bug ID: 107909
Summary: [powerpc64le, debug] Incorrect call site location due
to nop after call insn
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #11 from Brjd ---
Thank you.
Best regards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107553
--- Comment #5 from Brjd ---
Thank you.
Best regards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107909
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/legacy-ml/gcc-patches/2010-08/txt00153.txt for the
description of the call site dwarf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107909
--- Comment #2 from Andrew Pinski ---
Hmm, the nop is required by the ABI because the TOC might be different and
replaced with a load during linking ...
I am not 100% sure this is not just a definition of DW_TAG_GNU_call_site for
powerpc64 ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107907
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107909
--- Comment #3 from Andrew Pinski ---
Oh wait DW_TAG_call_site is now part of dwarf5. maybe the powerpc ABI can
define it that way then ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107898
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9948daa4fd0f0ea0a9d56c2fefe1bca478554d27
commit r13-4385-g9948daa4fd0f0ea0a9d56c2fefe1bca478554d27
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|ice-on-valid-co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5894a8179687b7028d093584102d204af422cfd3
commit r13-4384-g5894a8179687b7028d093584102d204af422cfd3
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107898
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Summary|[11/12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107910
Bug ID: 107910
Summary: Missed optimization of struct members with mixed sizes
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436
Florian Schanda changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107810
--- Comment #2 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:1ad898d82707376313d97bb81cf40c225b05bacf
commit r13-4386-g1ad898d82707376313d97bb81cf40c225b05bacf
Author: Eric Botcazou
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107810
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107171
Surya Kumari Jangala changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #5 from Jonathan Wakely ---
(In reply to Charles-Henri Gros from comment #4)
> Looking into it further, there may be an implicit requirement that the
> predicate does not modify its argument.
> https://eel.is/c++draft/algorithms.requ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #6 from Jonathan Wakely ---
IMHO https://cplusplus.github.io/LWG/issue3031 should have applied to these
functions too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #7 from Jonathan Wakely ---
See also https://cplusplus.github.io/LWG/issue2542 which was another change in
the same vein. Generally, we're getting stricter about rejecting predicates
like yours, because reasoning about the program be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107911
Bug ID: 107911
Summary: Remove problematic language from libtool.m4
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55899
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |libstdc++
--- Comment #5 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106995
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106995
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:063ba138eaa15ceecf23a24906e0e19be98d509d
commit r13-4388-g063ba138eaa15ceecf23a24906e0e19be98d509d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
--- Comment #6 from Jonathan Wakely ---
As Martin S. suggested a few times, it would be nice if we had an attribute or
something that could say that no members of 'this' are clobbered like that. It
would be UB for the vector's allocator (whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
--- Comment #7 from Richard Biener ---
Ontop of the patch I am testing the following fixes the diagnostics:
diff --git a/libstdc++-v3/include/bits/vector.tcc
b/libstdc++-v3/include/bits/vector.tcc
index 33faabf2eae..aab87b94882 100644
--- a/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884
--- Comment #6 from SASANO Takayoshi ---
Created attachment 53980
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53980&action=edit
rewrite int options -> int32_t options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107912
Bug ID: 107912
Summary: UBsan at -O0 missed a signed integer overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107913
Bug ID: 107913
Summary: Bogus unused variable warning if used in if constexpr
false in lambda with default capture by ref
Product: gcc
Version: unknown
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106786
--- Comment #4 from Paweł Bylica ---
Any update on this? I've identified some other similar cases where this hurting
the performance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107914
Bug ID: 107914
Summary: Finalization errors
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107914
--- Comment #1 from Paul Thomas ---
Created attachment 53982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53982&action=edit
Subsidiary program for testcase
As promised, here is the subsidiary program.
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #15 from Wilco ---
(In reply to Rama Malladi from comment #14)
> This fix also improved performance of 538.imagick_r by 15%. Did you have a
> similar observation? Thank you.
No, but I was using -mcpu=neoverse-n1 as my baseline. It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #4 from Richard Biener ---
At the point of the diagnostic we see
[local count: 1073741824]:
data._M_elems[0] = 3;
data._M_elems[1] = 2;
data._M_elems[2] = 1;
_8 = getCount ();
_1 = _8 * 4;
_2 = &data._M_elems + _1;
if (&data._M_ele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515
--- Comment #7 from Stam Markianos-Wright ---
(In reply to Kevin Bracey from comment #6)
> Retesting the Godbolt on trunk, it's now worse - every line produces
> multiple not-very-informative errors:
>
> source>:7:9: error: '_Generic' specifies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515
--- Comment #8 from Kevin Bracey ---
I'm only testing on the Linux trunk because it's what Godbolt has. If it has
bare-metal, I'm not seeing it.
Actual real development system is bare-metal using Arm's embedded GCC releases,
and I don't have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677
--- Comment #6 from Richard Biener ---
If you supply a runtime index or pointer offset GCC tries to constrain that
value. If it can constrain the index or pointer offset such that the access
would always be out of the bounds of an array that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:fd8dd6c0384969170e594be34da278a072d5eb76
commit r13-4389-gfd8dd6c0384969170e594be34da278a072d5eb76
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
--- Comment #9 from Richard Biener ---
My part is done, libstdc++ adjustment missing.
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 #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=107915
Bug ID: 107915
Summary: new test case g++.dg/contracts/contracts-tmpl-spec2.C
in r13-4160-g2efb237ffc68ec fails
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107835
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107898
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107835
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107916
Bug ID: 107916
Summary: PPC VSX code generation for OpenZFS
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107916
David Edelsohn changed:
What|Removed |Added
Last reconfirmed||2022-11-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107748
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107917
Bug ID: 107917
Summary: [13 regression?] Size of enum type doesn't match size
of enum value
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107491
--- Comment #12 from Jakub Kulik ---
One thing that is still slightly limiting is that the stack size cannot be
changed e.g. for individual tests when running the libgo test suite.
It might be nice to have some exported interface, such as the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107916
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Summary|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
--- Comment #8 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:36cabc257dfb7dd4f7625896891f6c5b195a0241
commit r13-4390-g36cabc257dfb7dd4f7625896891f6c5b195a0241
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107916
--- Comment #3 from Andrew Pinski ---
aarch64 has a similar issue too:
.L3:
add w1, w1, 1
add v0.4s, v5.4s, v2.4s
add v1.4s, v4.4s, v3.4s
mov v2.16b, v0.16b
mov v3.16b, v1.16b
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107917
--- Comment #1 from Andrew Pinski ---
C23 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107917
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
Andrew Pinski changed:
What|Removed |Added
CC||luis.machado at arm dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107917
--- Comment #3 from Luis Machado ---
Thanks for linking it Andrew.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107916
--- Comment #4 from Andrew Pinski ---
Reduced even further just compile with `-O2 -mvsx` is enough to show the issue
really:
```
typedef unsigned u32x8 __attribute__ ((vector_size (32)));
void f(int n, u32x8 *a, u32x8 *b)
{
u32x8 c = {0};
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107912
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107911
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107910
--- Comment #1 from Andrew Pinski ---
The problem is an interaction between the SLP vectorizer and store merging.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
--- Comment #15 from Jonathan Wakely ---
*** Bug 106199 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107918
Bug ID: 107918
Summary: P2468R2 and operator ambiguity
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #8 from Charles-Henri Gros ---
Thanks for all the comments. I agree that for consistency this should be
rejected, though my preference would still be to make remove_if/erase_if more
useful in practical cases (this happens dozens of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107918
--- Comment #1 from Andrew Pinski ---
/* Ambiguity between normal and reversed comparison operators
with the same parameter types. P2468 decided not to go with
this approach to resolving the ambig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107919
Bug ID: 107919
Summary: Possibly false-positive "maybe-uninitialized" with GCC
12 on complex variant-variant-tuple-unique_ptr types
Product: gcc
Version: 12.1.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
Freddie Chopin changed:
What|Removed |Added
CC||freddie_chopin at op dot pl
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #9 from Jonathan Wakely ---
The problem with side effects is not that they happen more than once, but that
they happen at all. The algorithm is called "erase_if" so it's surprising if it
actually mutates the remaining elements, rathe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107918
Cameron changed:
What|Removed |Added
CC||dacamara.cameron at gmail dot
com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106363
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107919
--- Comment #1 from Freddie Chopin ---
More possibly imporant notes:
1. The warning appears only with -O1 or -O2, with 0, s, g or 3 the warning is
gone.
2. Adding -fsanitize=undefined to compiler invocation makes the warning go away
as well - no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
--- Comment #10 from Jonathan Wakely ---
With that compiler patch for the missed-optimization one of the two bogus
warnings goes away. The second one goes away with this change:
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
Bug ID: 107920
Summary: [13 Regression] ICE in execute_todo, at passes.cc:2140
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
commit r13-4393-gcca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
commit r13-4393-gcca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
commit r13-4393-gcca06f0d6d76b08ed4ddb7667eda93e2e9f2589e
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
--- Comment #10 from Jonathan Wakely ---
(In reply to Marco Clemencic from comment #8)
> But the warning is not issued in -O0 builds, which I believe means the code
> is correct by itself,
That's not a valid assumption. -Wmaybe-uninitialized do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107921
Bug ID: 107921
Summary: Overflow warnings in libsupc++/hash_bytes.cc for
msp430-elf -mlarge
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107922
Bug ID: 107922
Summary: ICE in gfc_simplify_unpack, at
fortran/simplify.cc:8473
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #7 from rguenther at suse dot de ---
On Tue, 29 Nov 2022, carlosgalvezp at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
>
> --- Comment #5 from Carlos Galvez ---
> > is not good programming practice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107923
Bug ID: 107923
Summary: ICE in lookup_function_fuzzy_find_candidates /
check_interface0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107923
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from
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
1 - 100 of 170 matches
Mail list logo
