https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107717
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107718
--- Comment #1 from Richard Biener ---
it seems to split the reduction, performing many 0.99 ** n in parallel which is
stupid itself as those compute the same result ...
I'd say the benchmark is stupid and with -ffast-math we could optimize it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107717
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:cbe313060cdcf1d857d42a9e16a1a03e5ff89fff
commit r13-4123-gcbe313060cdcf1d857d42a9e16a1a03e5ff89fff
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107717
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
Bug ID: 107732
Summary: ICE in lower_bound, at value-range.h:350
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097
--- Comment #10 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:822a0823c012b912f0108a4da257cd97cbcdb7a3
commit r13-4125-g822a0823c012b912f0108a4da257cd97cbcdb7a3
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 68097, which changed state.
Bug 68097 Summary: We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #11 from Tamar Christina ---
(In reply to Richard Biener from comment #10)
> Tamar, are the IFN_COMPLEX_FMA and IFN_COMPLEX_FMA_CONJ FP contracting
> operations as well?
Yes, they have no intermediate rounding.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #7 from Richard Biener ---
Apart from the permute issue that's maybe there the issue of the segfault is
failure to code generate the loads correctly to match the SLP analysis. We
generate loads as if we'd use a VF of 2 but use only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #12 from Tamar Christina ---
Note that the same IFN is used for integer MLA as well. We didn't split them
apart.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #13 from Richard Biener ---
Created attachment 53917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53917&action=edit
patch I am testing
OK, I'm testing the following then - can you see if that works for the complex
fmas and i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #14 from Tamar Christina ---
(In reply to Richard Biener from comment #13)
> Created attachment 53917 [details]
> patch I am testing
>
> OK, I'm testing the following then - can you see if that works for the
> complex fmas and if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107733
Bug ID: 107733
Summary: GCC - -Wanayzer-null-dereference false positive with
wrong path note "(3) 'e' is NULL" and inconsistent
behaviors
Product: gcc
Version: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #15 from Alexander Monakov ---
I'm confused about the first hunk in the attached patch:
--- a/gcc/tree-vect-slp-patterns.cc
+++ b/gcc/tree-vect-slp-patterns.cc
@@ -1035,8 +1035,10 @@ complex_mul_pattern::matches (complex_operation_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633
Arthur Cohen changed:
What|Removed |Added
CC||cohenarthur.dev at gmail dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101747
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #7 from Tamar Christina ---
(In reply to Andrew Pinski from comment #5)
> Can you try right before r13-3707-g4e4e3ffd10f53e and right afterwards?
>
> I would have assumed, the exception would not happen really.
Sadly doesn't seem t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #8 from Florian Weimer ---
(In reply to Tamar Christina from comment #4)
> /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:111
> #6 __register_frame_info (begin=, ob=0x48cfe8 ) at
> /opt/buildAgent/work/5c94c4ced6ebfcd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103930
Jan Engelhardt changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #9 from Tamar Christina ---
(In reply to Florian Weimer from comment #8)
> (In reply to Tamar Christina from comment #4)
> > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:111
> > #6 __register_frame_info (begin=, ob=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103930
--- Comment #2 from Jan Engelhardt ---
Subissue a) "the crash output is completely useless" seems to have been
addressed in the past already; I observe in gcc 12 that
Found plugin run function: 0x7fecaa0e01a0
AddressSanitizer:DEADLYSIGNAL
=
~/gcc/results.20221117.valgrind/bin/gcc -c -O2 ./gcc.target/i386/pr46051.c
==639651== Conditional jump or move depends on uninitialised value(s)
==639651==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137)
==639651==by 0x11DFAE7: gimple_simplify_122(gimple_match_op*, gimple**,
tree
_node* (*)(tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
Marco Clemencic changed:
What|Removed |Added
CC||marco.clemencic at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #1 from David Binderman ---
The valgrind problem doesn't seem to occur with git hash 05432288d4e56055,
dated 20221113, so the bug is recent.
I used git hash 2b2f2ee49a33419f for today's build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
--- Comment #4 from Marco Clemencic ---
I have a similar problem with this chunk of code:
```
#include
#include
#include
#include
#include
struct Wrapper {
using Map = std::map;
using Value = std::variant;
Wrapper(Value v) : da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
--- Comment #5 from Marco Clemencic ---
I forgot to mention that I compiled with the options:
g++ -c -Wmaybe-uninitialized -O1 -v -save-temps test.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #2 from David Binderman ---
git blame says
dc95e1e970 (Hongyu Wang 2022-01-17 13:01:51 +0800 8292)if
(!bitmap_set_bit (seen, sel[i].to_constant ()))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #3 from David Binderman ---
Another test case:
./gcc.target/i386/pr53366-2.c
==41== Conditional jump or move depends on uninitialised value(s)
==41==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137)
==41==by 0x11DFAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #16 from Richard Biener ---
(In reply to Alexander Monakov from comment #15)
> I'm confused about the first hunk in the attached patch:
>
> --- a/gcc/tree-vect-slp-patterns.cc
> +++ b/gcc/tree-vect-slp-patterns.cc
> @@ -1035,8 +1035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278
--- Comment #7 from Eric Gallager ---
(In reply to Andrew Pinski from comment #6)
> I don't think clang implements -Wfloat-equal at all, at least they didn't at
> the last time I looked a few years back.
I just checked their diagnostics referen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #4 from David Binderman ---
A third:
./gcc.target/i386/pr61403.c
==749959== Conditional jump or move depends on uninitialised value(s)
==749959==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137)
==749959==by 0x11DFAE7: gimple_sim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
--- Comment #2 from Christophe Lyon ---
Confirmed.
In test_dfp_17.c we have:
ARG(_Decimal64, 11.0dd, D0)
DOTS
ANON(struct z, a, D1)
ANON(struct z, b, STACK)
ANON(int , 5, W0)
ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #16 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #15)
> On Wed, 16 Nov 2022, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
> >
> > Andrew Macleod changed:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #17 from rguenther at suse dot de ---
On Thu, 17 Nov 2022, amacleod at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
>
> --- Comment #16 from Andrew Macleod ---
> (In reply to rguent...@suse.de from com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #8 from Richard Biener ---
Peeling for gaps also isn't a good fix here. One could envision a case with
even three iterations ahead load with
for(i = 0; i < n; i++) {
dot[0] += x[ix] * y[ix] ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #9 from bartoldeman at users dot sourceforge.net ---
I ended up using -mprefer-vector-width=128 as a workaround myself (via
__attribute__((target("prefer-vector-width=128", so there is still some AVX
vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #10 from Richard Biener ---
Interestingly the following variant of the testcase falls back to
VMAT_ELEMENTWISE but does have the same problem there fixed up by later
folding, but it will segfault when using -O2 -mavx2 -fno-vect-cost-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
Bug ID: 107735
Summary: Inconsistent error messages for std::array out of
bound
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-11-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90134
--- Comment #4 from Arseny Solokha ---
(In reply to Andrew Pinski from comment #3)
> This code is all undefined anyways .
Yes, but what about unmodified tests from libstdc++? I occasionally hit this
ICE on them too, as shown in comment 2. I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #18 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #17)
> On Thu, 17 Nov 2022, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
> >
> > --- Comment #16 from Andrew Macle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #1 from Aldy Hernandez ---
Created attachment 53920
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53920&action=edit
untested
[PR tree-optimization/107732] [range-ops] Handle attempt to abs() negatives.
The threader is creati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #2 from Andrey Alekseenko ---
@Aldy Hernandez, thank you. Can confirm that your patch fully resolves the
issue for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #3 from Aldy Hernandez ---
(In reply to Andrey Alekseenko from comment #2)
> @Aldy Hernandez, thank you. Can confirm that your patch fully resolves the
> issue for me.
No problem. Thank your for reporting and for reducing. It make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-11-17
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
--- Comment #3 from Christophe Lyon ---
and patching test_dfp_17.c like so:
- ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */
+ ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */
makes it pass on aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107714
Stam Markianos-Wright changed:
What|Removed |Added
Last reconfirmed||2022-11-17
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515
Stam Markianos-Wright changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #5 from David Binderman ---
I have reduced one of the test cases downto this code:
float val1f[][2], val2f[][2], chkf[][2];
foof_i;
foof() {
int j;
foof_i = 0;
for (; foof_i < 8; foof_i++) {
float tmp = val1f[foof_i][j] *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #6 from David Binderman ---
I am trying a bisect with git hash b4fca4fc70dc76cf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711
--- Comment #11 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f9ed1d24ee46f5ca759c35a1f51fa163d7529ea6
commit r13-4130-gf9ed1d24ee46f5ca759c35a1f51fa163d7529ea6
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711
David Malcolm changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
Andrew Pinski changed:
What|Removed |Added
Summary|valgrind error for |[13 Regression] valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #4 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:4e306222f442f8d4c6fc6da997ab756a5e43e36e
commit r13-4131-g4e306222f442f8d4c6fc6da997ab756a5e43e36e
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:ee892832ea19b21a3420ef042e582204fac852a2
commit r13-4132-gee892832ea19b21a3420ef042e582204fac852a2
Author: Andrew Pinski
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278
--- Comment #8 from Andrew Pinski ---
So clang emits one or the other warning for the code but not both.
You can defect the warning in clang by doing:
```
extern void g( int);
void f(float a)
{
double b = a;
if (b == 0.1234)
g( 1);
}
``
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
Bug ID: 107736
Summary: call to a function, generated by inline asm, is off by
one byte
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737
Bug ID: 107737
Summary: seemly looking off code in gimplify_call_expr
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
--- Comment #2 from mfarca ---
> Toplevel inline-asm will be emitted without any knowledge of the current
> section.
So this is a limitation of gcc I guess? as clang does have the knowledge on
which is which.
The main issue still persists as c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107738
Bug ID: 107738
Summary: Top-level inline-asm is not well documented
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: documentation, inline-asm
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99884
--- Comment #2 from CVS Commits ---
The master branch has been updated by Bernhard Reutner-Fischer
:
https://gcc.gnu.org/g:19be89d79ee149e812ccc6027956cefb7f3e1016
commit r13-4133-g19be89d79ee149e812ccc6027956cefb7f3e1016
Author: Bernhard Reutn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #10 from David Binderman ---
(In reply to Andrew Pinski from comment #9)
> Fixed.
Thanks for that.
Would it ok to manually check all uses of sbitmap, to make sure they initialise
bits appropriately, or would it be better to define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
--- Comment #4 from mfarca ---
Thanks for creating the issue for improving documentation.
Could you then clarify if call to the incorrect address is a bug or not?
instructions are allowed to be under `.rodata` section as this section is still
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107738
--- Comment #1 from Andrew Pinski ---
I know there are other related bugs where people mess up the top-level
inline-asm too but I can't find them right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
--- Comment #5 from Andrew Pinski ---
(In reply to mfarca from comment #4)
> Thanks for creating the issue for improving documentation.
>
> Could you then clarify if call to the incorrect address is a bug or not?
> instructions are allowed to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #11 from Andrew Pinski ---
(In reply to David Binderman from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > Fixed.
>
> Thanks for that.
>
> Would it ok to manually check all uses of sbitmap, to make sure they
> ini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106764
--- Comment #3 from Andrew Pinski ---
At the point where the CALL_EXPR is built:
Breakpoint 5, build_function_call_vec (loc=258624, arg_loc=...,
function=, params=0x0, origtypes=0x0,
orig_fundecl=) at
/home/apinski/src/upstream-gcc/gcc/gcc/c/c-t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107739
Bug ID: 107739
Summary: --enable-languages= duplicates yield odd error
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106764
--- Comment #4 from Andrew Pinski ---
Actually the fix is just check the return value of gimplify_expr to make sure
it was not GS_ERROR.
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index f06ce3cc77a..9b74f957308 100644
--- a/gcc/gimplify.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107307
--- Comment #2 from Andrew Pinski ---
Simple fix:
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index f06ce3cc77a..bd772c15bec 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3319,7 +3319,9 @@ gimplify_compound_lval (tree *expr_p, gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107307
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
Bug ID: 107740
Summary: if-to-switch conversion happens for simple predicate
function when compiled with gcc but not with g++
Product: gcc
Version: 13.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107705
--- Comment #2 from Andrew Pinski ---
diff --git a/gcc/function.cc b/gcc/function.cc
index 361aa5f7ed1..9c8773bbc59 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -2090,6 +2090,9 @@ aggregate_value_p (const_tree exp, const_tree fntype)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
--- Comment #3 from Andrew Pinski ---
>phi-opt1 is the "early phi-opt" which tries not to do it here.
Let me expand on that, it tries not to insert a cast here to do the conversion
from bool to int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985
Mark Abraham changed:
What|Removed |Added
CC||mark.j.abraham at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
--- Comment #2 from Andrew Pinski ---
I wonder if this is because doing
constexpr const int *v1 = &array[3];
is valid and well defined.
Even clang gives two different error messages:
:3:21: error: constexpr variable 'v1' must be initialized b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107739
--- Comment #1 from Andrew Pinski ---
I thought this was fixed at one point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:7b3b2f50953c5143d4b14b59d322d8a793f411dd
commit r13-4135-g7b3b2f50953c5143d4b14b59d322d8a793f411dd
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:14faa5f585f6025df1e04c8c8b34340ff5e4d494
commit r12-8916-g14faa5f585f6025df1e04c8c8b34340ff5e4d494
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:90824f6c57e1ac7b94c558b4c99721b412df75ef
commit r11-10381-g90824f6c57e1ac7b94c558b4c99721b412df75ef
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
--- Comment #3 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #2)
> I wonder if this is because doing
> constexpr const int *v1 = &array[3];
>
> is valid and well defined.
It's not, but &array.data()[3] is.
I agree that's p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:b9b78b4de3c7dcc6868c4af831b2d213fda21b04
commit r10-11087-gb9b78b4de3c7dcc6868c4af831b2d213fda21b04
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
--- Comment #4 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > I wonder if this is because doing
> > constexpr const int *v1 = &array[3];
> >
> > is valid and well defined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741
Bug ID: 107741
Summary: Missed member variable name in mangling of externally
visible lambdas used in inline initialization of
static members
Product: gcc
Versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741
--- Comment #1 from David Blaikie ---
Oh, some context - discovered while investigating a related clang bug:
https://github.com/llvm/llvm-project/issues/58819 - so don't check clang for an
example of what's right here, it has different bugs, tho
1 - 100 of 120 matches
Mail list logo
