https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #1 from Jürgen Reuter ---
It seems that the problem is in the declaration of the following variables in
value_range.h:
template friend void gt_ggc_mx (int_range *);
template friend void gt_pch_nx (int_range *);
template frien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #2 from Jürgen Reuter ---
Most likely this was that commit:
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 150) template
friend void gt_ggc_mx (int_range *);
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 151)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96482
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-08-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #3 from Jürgen Reuter ---
Just uncommenting the declarations doesn't help because later on compilation
fails with
n file included from gtype-desc.c:52:
../../gcc/value-range.h:352:21: error: 'm_ranges' is a private member of
'int_rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96482
--- Comment #4 from Jan Hubicka ---
that patch makes ccp to actually use the bit info ipa-cp determines. Before we
used it only to detect pointer alignments if I remember correctly. So it looks
like propagation bug uncovered by the change. Small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96535
--- Comment #1 from Hongtao.liu ---
for cmdline option, it's handled in process_options which will enable
flag_cunroll_grow_size which is the real effective flag to unroll the loop in
testcase.
cut from toplev.c
---
/* Unrolling all loops impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96243
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:f098bc87dcae5646d11a351cfb55d0e1124c7f60
commit r10-8599-gf098bc87dcae5646d11a351cfb55d0e1124c7f60
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96549
Bug ID: 96549
Summary: Wrong evaluation of a comparison between long & short
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #4 from Aldy Hernandez ---
Does this patch fix the problem?
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551660.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96549
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #5 from Jürgen Reuter ---
(In reply to Aldy Hernandez from comment #4)
> Does this patch fix the problem?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551660.html
It looks like, still compiling. In the meantime I change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96541
--- Comment #1 from Jürgen Reuter ---
Sorry, this is a duplicate of #96540.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96549
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2020-08-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96549
Andrew Pinski changed:
What|Removed |Added
Summary|[10/11 Regression] Wrong|Wrong evaluation of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536
--- Comment #1 from Hongtao.liu ---
I'm testing patch like
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index b24a4557871..269c528c3ad 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -19132,15 +19132,15 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96541
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #6 from Martin Liška ---
*** Bug 96541 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536
--- Comment #2 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #1)
> I'm testing patch like
You can probably use gen_sub2_insn here.
On a related note, "@" prefix can be used for rdssp, so one can pass mode to an
expander. This would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96549
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=96549
--- Comment #2 from Jakub Jelinek ---
Created attachment 49033
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49033&action=edit
gcc11-pr96549.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
--- Comment #3 from Jonathan Wakely ---
FWIW I opened https://cplusplus.github.io/LWG/issue3430 to say string_view
should be usable directly.
It makes absolutely no sense for construction from a string_view to convert to
filesystem::path just to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536
--- Comment #3 from Hongtao.liu ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Hongtao.liu from comment #1)
> > I'm testing patch like
>
> You can probably use gen_sub2_insn here.
>
> On a related note, "@" prefix can be used for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |SUSPENDED
Summary|filesyste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92139
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96543
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96537
--- Comment #3 from Jonathan Wakely ---
FWIW the change was implemented for GCC 6.0 by r225189
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96537
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #2 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
--- Comment #2 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> In bar, this is optimized, because fold_binary_op_with_conditional_arg
> optimizes
> 255 >> (x ? 1 : 0) into x ? 127 : 255 and when multiplied by two in unsigned
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96537
--- Comment #5 from Jonathan Wakely ---
(In reply to Tom de Vries from comment #0)
> std::unordered_map> m;
> m.emplace (1, new A(1));
This code isn't exception-safe anyway. If allocating a new node in the map
throws an exception your pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96537
--- Comment #4 from Tom de Vries ---
(In reply to Jonathan Wakely from comment #2)
> Not a bug. C++11 and C++14 said for the relevant pair(U&&, V&&) constructor:
>
> Remarks: If U is not implicitly convertible to first_type or V is not
> implici
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96454
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96537
--- Comment #6 from Jonathan Wakely ---
(In reply to Tom de Vries from comment #4)
> Thanks for the comment. Still, if this is a language version issue, I used
> -std=c++11 with 7.5.0, shouldn't I then get the same behaviour as with gcc
> 4.8.5?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96537
--- Comment #7 from Jonathan Wakely ---
... warts and all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96466
--- Comment #2 from Martin Liška ---
Started with my r11-1445-g502d63b6d6141597.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96453
--- Comment #2 from Martin Liška ---
Started with my r11-1445-g502d63b6d6141597.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96545
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=96542
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
--- Comment #4 from Jakub Jelinek ---
As for COND_EXPR, if we do it that way, it should be rather keyed on a range
with only two possible values in the range.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433
--- Comment #7 from CVS Commits ---
The master branch has been updated by Marc Glisse :
https://gcc.gnu.org/g:287522613d661b4c5ba8403b051eb470c1674cba
commit r11-2629-g287522613d661b4c5ba8403b051eb470c1674cba
Author: Marc Glisse
Date: Mon Au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95235
Gabriel Ravier changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95749
--- Comment #1 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:b5cc5c95664347082100a504710f5ca0467306a5
commit r10-8600-gb5cc5c95664347082100a504710f5ca0467306a5
Author: Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95749
--- Comment #2 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:caac3ee7008286404323c4aa93ee0e1c4753c4c2
commit r9-8800-gcaac3ee7008286404323c4aa93ee0e1c4753c4c2
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95749
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95749
--- Comment #4 from Jonathan Wakely ---
Also fixed on master by g:9939be5758b52ed2fe1a7e56b94ce6d0f4d81580 but I'm not
sure why that didn't get added here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
Bug ID: 96550
Summary: gcc is smart in figuring out a non-returning function.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #1 from Marc Glisse ---
Does -fno-delete-null-pointer-checks help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #2 from Jakub Jelinek ---
If FAIL is defined, your myfunc will always trigger undefined behavior if
called, and as such anything can happen.
Derefencing NULL is UB.
If you are on an embedded system where there is memory mapped, you ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93904
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #3 from Jonathan Wakely ---
(In reply to Roger Wolff from comment #0)
> So... without saying anything the compiler decided that my function will
> never return. It might be right about that (That's not true: This is on an
> embedded s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
Jonathan Wakely changed:
What|Removed |Added
Version|unknown |9.3.1
--- Comment #4 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96453
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96466
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96539
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #5 from Roger Wolff ---
Guys, The compiler found a bug in my code, but it didn't tell me. Like the if
(a = 3) situation, the compiler is correct when it compiles the code according
to the C rules.
I like to compile my code with -Wal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #6 from Roger Wolff ---
So, I've added "-Wall" to my Makefile to get ALL warnings, giving me the
biggest chance of finding bugs through the compiler telling me you have a bug
on line X of file Y.
So IMHO -Wnull-dereference should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #7 from Jakub Jelinek ---
The compiler can't diagnose this as an error (unless -Werror* is used), because
it is only an error if such code is ever called at runtime, which the compiler
can't determine at compile time.
That is why it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96552
Bug ID: 96552
Summary: GCC accepts "alignas(auto)" in function parameter list
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96551
Bug ID: 96551
Summary: [10 Regression] FAIL: gcc.target/i386/vectorize8.c
(internal compiler error)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96553
Bug ID: 96553
Summary: ICE in unexpected expression ‘__alignof__ (auto:1)’ of
kind alignof_expr
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: error-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94681
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:90f7636bf8df50940e0f749af60a6b374a8f09b4
commit r11-2633-g90f7636bf8df50940e0f749af60a6b374a8f09b4
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94681
--- Comment #4 from Jonathan Wakely ---
Only fixed on master so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #8 from Roger Wolff ---
Please, start to read what is written. Please.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #9 from Jonathan Wakely ---
(In reply to Roger Wolff from comment #6)
> So, I've added "-Wall" to my Makefile to get ALL warnings,
It doesn't enable ALL warnings, as documented in the manual.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #7 from Jürgen Reuter ---
(In reply to Aldy Hernandez from comment #4)
> Does this patch fix the problem?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551660.html
Yes, with that fix (as anticipated by you) build and boo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554
Bug ID: 96554
Summary: -Wall does not include -Wnull-dereference
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #10 from Roger Wolff ---
Technically correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #11 from Roger Wolff ---
Just FYI: I added -Wnull-dereference to my makefile of my real project. It
doesn't trigger a warning in my project when I revert to the buggy code. The
compiler does detect and act upon the null dereference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96519
Christophe Lyon changed:
What|Removed |Added
Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96543
--- Comment #2 from Vlad Petric ---
Got it, should I refile/change this bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
Roger Wolff changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554
--- Comment #2 from Roger Wolff ---
In my case it promotes a function I didn't declare as into
one that and thereby it caused 80% of my code to become
"dead". It'd be nice to differentiate between the case where a simple
optimization removes a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554
--- Comment #3 from Andreas Schwab ---
*** Bug 96550 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #13 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #14 from Jonathan Wakely ---
(In reply to Roger Wolff from comment #11)
> Just FYI: I added -Wnull-dereference to my makefile of my real project. It
> doesn't trigger a warning in my project when I revert to the buggy code. The
> com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554
--- Comment #4 from Roger Wolff ---
Update: LTO messes with the warning. When LTO is enabled, the warning from
-Wnull-dreference is suppressed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #15 from Roger Wolff ---
I marked it as "resolved', the system then told me to type a message and I did,
but then it had added the "FIXED" tag. Not my idea.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96548
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96494
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> AFAICT, from the point of view of the PTX isa, there's no reason why we
> couldn't support this.
>
> So, unless a testsuite run points to some problem, we should e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96494
--- Comment #2 from Tom de Vries ---
FTR, we could fix this by just mapping onto a nonatomic insn for .local (and
I'm not really sure why ptx doesn't).
But since we have generic pointers, we only known runtime whether something is
local (using i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83812
--- Comment #1 from Tom de Vries ---
See PR 96494.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96523
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
--- Comment #5 from Andrew Macleod ---
I think this all goes away when multi-range is enabled.
The original testcase produces:
=== BB 2
x_4(D) unsigned int VARYING
:
tmp_5 = x_4(D) != 0;
_1 = (int) tmp_5;
_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96482
--- Comment #5 from Yevhenii Kolesnikov ---
(In reply to Martin Liška from comment #3)
> Thank you for the report, I can take a look.
> Can you please provide steps how to build Mesa with -O3 and -flto?
mesa is configured with meson. LTO can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94681
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
--- Comment #6 from Andrew Macleod ---
Likewise, for
unsigned
baz (unsigned int x)
{
if (x >= 4) return 32;
return (-1U >> x) * 16;
}
=== BB 2
x_3(D) unsigned int VARYING
_4 UNDEFINED
:
if (x_3(D) > 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93671
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #3 from ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96555
Bug ID: 96555
Summary: "template argument involves template parameter(s)"
with dot or arrow operator in partial specialization
Product: gcc
Version: 11.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
Bug ID: 96556
Summary: [11.0 regression] ICE via segmentation violation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
--- Comment #1 from Jürgen Reuter ---
Created attachment 49036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49036&action=edit
First reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Last reconfir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96497
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5c64df80df274c753bfc8415bd902e1180e76f6a
commit r11-2635-g5c64df80df274c753bfc8415bd902e1180e76f6a
Author: Jakub Jelinek
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
--- Comment #2 from Jürgen Reuter ---
Created attachment 49037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49037&action=edit
2nd reproducer, single file, shortening further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94681
--- Comment #6 from Jonathan Wakely ---
Thanks, I thought this might reveal some new issues :-)
I'll fix it asap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96543
--- Comment #3 from Jonathan Wakely ---
No, it's fine. I've categorized it as a diagnostic bug, i.e. a bug in a
warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #16 from Jonathan Wakely ---
When you choose RESOLVED you can pick various types of resolution, FIXED,
INVALID, DUPLICATE, MOVED, WORKSFORME etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96557
Bug ID: 96557
Summary: Diagnostics: Can you tell me why it's not a constant
expression?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96101
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Domi
1 - 100 of 137 matches
Mail list logo
