https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
Bug ID: 82210
Summary: Having _Alignas in a struct with VLAs causes writing
to one array to overwrite another
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81631
--- Comment #3 from Tobias Jordan ---
Hi,
thanks for taking a look, and thanks for your explanation. As far as I
understand it, it's somewhat intuitive that the qualifiers apply to array
elements and not the array type itself. What bugs me is th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81325
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Thu Sep 14 08:07:30 2017
New Revision: 252752
URL: https://gcc.gnu.org/viewcvs?rev=252752&root=gcc&view=rev
Log:
PR target/81325
* cfgbuild.c (find_bb_boundaries): Ignore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82211
Bug ID: 82211
Summary: [8 Regression] ICE error: non-cold basic block 32
reachable only by paths crossing the cold partition
Product: gcc
Version: unknown
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82211
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346
--- Comment #17 from Gergö Barany ---
Thanks for fixing this. I did notice a small thing that might be considered a
tiny regression due to the fix.
If the divisor is a small power of 2, as in the following example:
int fn1(char p1) {
long a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80996
--- Comment #1 from Rainer Orth ---
Author: ro
Date: Thu Sep 14 09:20:18 2017
New Revision: 252754
URL: https://gcc.gnu.org/viewcvs?rev=252754&root=gcc&view=rev
Log:
Don't xfail gcc.dg/vect/vect-multitypes-12.c on 32-bit SPARC (PR
tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170
--- Comment #7 from Jakub Jelinek ---
More complete testcase:
extern inline int f1 (long long n) { return -__INT_MAX__ - 1 <= n && n <=
__INT_MAX__; }
extern inline int f2 (long long n) { return n == (int) n; }
extern inline int f3 (unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80996
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81829
--- Comment #7 from Martin Liška ---
Created attachment 42168
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42168&action=edit
Patch candidate
So I eventually decided to remove the smartness in wrappers, let's make it
simple. I've been tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81346
--- Comment #18 from Marc Glisse ---
(In reply to Gergö Barany from comment #17)
> the division used to be replaced by a shift that updated the condition code
> register (again, on ARM; r250337):
(just my opinion)
At a high level (gimple), (unsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82163
amker at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81214
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82212
Bug ID: 82212
Summary: libstdc++ makes (integer|index)_sequence available
with -std=c++11, but they're C++14 features
Product: gcc
Version: unknown
URL: https://bugzil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32911
--- Comment #5 from Philip Withnall ---
Bug filed against Clang with the same request here:
https://bugs.llvm.org/show_bug.cgi?id=34600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170
--- Comment #8 from Jakub Jelinek ---
To summarize IRC discussions about this, the first step should be to introduce
SEXT_EXPR (split from Prathamesh's patch, improve), then add match.pd
canonicalization of these range testing to SEXT_EXPR + EQ_E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
--- Comment #11 from Iain Sandoe ---
(In reply to Richard Biener from comment #4)
> The gcc-6 backport is ok (if you want to go ahead).
Is (a suitably modified) version also OK for gcc-5?
(I checked the posted one on Darwin and Linux and it see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82213
Bug ID: 82213
Summary: Please warn about const rvalue reference parameters
[void func(const T&&);]
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78366
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #10 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80481
--- Comment #1 from Andrew Senkevich ---
Reload phase adds insn 1817 (1)
(insn 856 855 1817 136 (set (reg:V16SI 22 xmm1 [orig:985 vect__72.36 ] [985])
(unspec:V16SI [
(mem:V16SI (plus:DI (reg/f:DI 39 r10 [orig:206 vectp.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80832
--- Comment #2 from Jakub Jelinek ---
Why it should be so fine-grained?
As for caret, it is documented what it is elsewhere in the documentation (the ^
character pointing at the source location below the source line), but it
actually changed in l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79622
Richard Biener changed:
What|Removed |Added
CC||spop at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82213
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82212
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82212
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
--- Comment #12 from Richard Biener ---
(In reply to Iain Sandoe from comment #11)
> (In reply to Richard Biener from comment #4)
> > The gcc-6 backport is ok (if you want to go ahead).
>
> Is (a suitably modified) version also OK for gcc-5?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78994
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81314
--- Comment #2 from Jakub Jelinek ---
Testcase without STL:
// { dg-do link }
template
struct S {
S () { s = 0; }
S (const S &x) { s = x.s; }
~S () {}
int s;
};
void
foo (S<2> &x)
{
#pragma omp taskloop
for (int i = 0; i < 100; ++i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82141
--- Comment #36 from simon at pushface dot org ---
(In reply to simon from comment #28)
> For the Darwin 15 build (+ patch to darwin.h from PR80556) was
> configured with
>
> --prefix=/Volumes/Miscellaneous/tmp/opt/gcc-8.0.0
> --without-libicon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170
Segher Boessenkool changed:
What|Removed |Added
Target|x86_64-*-* |x86_64-*-*, powerpc*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81314
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #13 from Richard Biener ---
We apply blocking on
int a[256][256];
void foo (void)
{
int *p = &a[4][7];
for (int i = 0; i < 256; ++i)
for (int j = 0; j < 256; ++j)
a[j][i] = a[j][i] * (*(int(*)[1])p)[0];
}
but not when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Richard Biener ---
[...]
>> Why does Solaris ld output warnings by default? Does it have an
>> option to suppress them? It doesn't seem that it considers them
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82192
--- Comment #11 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #10)
> Does the oddity that shifts truncate on x86, but bit operations do not come
> into play here?
x86 doesn't define SHIFT_COUNT_TRUNCATED (though in this testcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82195
--- Comment #2 from Nathan Sidwell ---
Created attachment 42171
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42171&action=edit
Further simplified
Further simplification removes the inner lambda. The key problem is needing to
name object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796
--- Comment #22 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #17)
> Not all cases work though, nullptr cannot be caught as a pointer to member
> function, and fixing that is difficult, so I'm keeping this open.
That was fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81311
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82174
--- Comment #2 from David Malcolm ---
The entry with the NULL name comes from this line in sanitizer.def:
/* This has to come before all the sanitizer builtins. */
DEF_BUILTIN_STUB(BEGIN_SANITIZER_BUILTINS, (const char *)0)
There's also th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82192
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Component|tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947
--- Comment #3 from Avi Kivity ---
A gentle ping, in the unlikely case that this bug was forgotten.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic, visibility
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82171
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
--- Comment #26 from Segher Boessenkool ---
I still can't reproduce the problem, and I don't see where the null
pointer is coming from either. Someone who can reproduce the problem
will have to do some debugging. Sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81068
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81929
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81268
--- Comment #7 from Georg-Johann Lay ---
(In reply to Aldy Hernandez from comment #6)
> Author: aldyh
> Date: Wed Sep 13 16:56:35 2017
> New Revision: 252421
>
> URL: https://gcc.gnu.org/viewcvs?rev=252421&root=gcc&view=rev
> Log:
> gcc/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82203
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Jakub Jelinek changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #80 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 82203, which changed state.
Bug 82203 Summary: [5/6/7/8 regression] missing -Wmaybe-uninitialized warning
with tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82203
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82186
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71187
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82192
--- Comment #12 from Segher Boessenkool ---
As far as I know this is undefined; combine should avoid making such
out-of-range patterns (unless the existing insns are already like that,
it will happily make even bigger garbage then).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82192
--- Comment #13 from Jakub Jelinek ---
So like this (untested) or somewhere else?
--- gcc/combine.c.jj2017-09-14 10:04:56.0 +0200
+++ gcc/combine.c 2017-09-14 16:59:28.529783572 +0200
@@ -7444,7 +7444,14 @@ make_extraction (mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82186
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81945
--- Comment #3 from amker at gcc dot gnu.org ---
Don't know transformation done by graphite. In this case, graphite0 has an
additional function dump:
;; Function at._loopfn.1 (at._loopfn.1, funcdef_no=2, decl_uid=1951,
cgraph_uid=1, symbol_order=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82214
Bug ID: 82214
Summary: [AArch64] Incorrect checking of LDP/STP offsets in
aarch64_print_operand
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71187
--- Comment #3 from Eric Niebler ---
I suppose, but I doubt it would matter much. add_rvalue_reference is not used
nearly as frequently as declval (except in the current implementation of
declval).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82192
--- Comment #14 from Segher Boessenkool ---
I'll check if this patch regresses code quality on any target. Looks
good though, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947
--- Comment #5 from Vlad Zolotarov ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Vlad Zolotarov from comment #1)
> > Created attachment 41472 [details]
> > an ii value generated by g++-6
>
> This is a URL not a preprocessed fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947
--- Comment #6 from Jonathan Wakely ---
(In reply to Vlad Zolotarov from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > (In reply to Vlad Zolotarov from comment #1)
> > > Created attachment 41472 [details]
> > > an ii value gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947
--- Comment #7 from Jonathan Wakely ---
Wow bugzilla really does suggest that. How stupid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82209
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81268
--- Comment #8 from Eric Gallager ---
(In reply to Georg-Johann Lay from comment #7)
> (In reply to Aldy Hernandez from comment #6)
> > Author: aldyh
> > Date: Wed Sep 13 16:56:35 2017
> > New Revision: 252421
> >
> > URL: https://gcc.gnu.org/vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82195
Nathan Sidwell changed:
What|Removed |Added
Component|c++ |demangler
--- Comment #3 from Nathan Si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #15 from Sebastian Pop ---
> when DR_NUM_DIMENSIONS (dr1->dr) != DR_NUM_DIMENSIONS (dr2->dr) better "FAIL"?
Yes.
The patch looks good to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947
--- Comment #8 from Vlad Zolotarov ---
(In reply to Jonathan Wakely from comment #7)
> Wow bugzilla really does suggest that. How stupid.
And the (In reply to Jonathan Wakely from comment #6)
> (In reply to Vlad Zolotarov from comment #5)
> > (I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82174
--- Comment #3 from David Malcolm ---
Author: dmalcolm
Date: Thu Sep 14 19:30:26 2017
New Revision: 252769
URL: https://gcc.gnu.org/viewcvs?rev=252769&root=gcc&view=rev
Log:
Fix crash accessing builtins in sanitizer.def and after (PR jit/82174)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82174
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947
--- Comment #9 from Jonathan Wakely ---
It says not to attach an archive containing the things we don't want (e.g.
sources without includes). And a .gz file is not an archive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81361
--- Comment #3 from Eric Botcazou ---
As of today, once PR ada/82141 is worked around, I get:
=== acats Summary ===
# of expected passes2263
# of unexpected failures57
Native configuration is x86_64-apple-darw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81361
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947
--- Comment #10 from Vlad Zolotarov ---
(In reply to Jonathan Wakely from comment #9)
> It says not to attach an archive containing the things we don't want (e.g.
> sources without includes). And a .gz file is not an archive.
"Please avoid post
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81314
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Thu Sep 14 20:18:17 2017
New Revision: 252770
URL: https://gcc.gnu.org/viewcvs?rev=252770&root=gcc&view=rev
Log:
PR c++/81314
* cp-gimplify.c (omp_var_to_track): Look thro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81647
Steve Ellcey changed:
What|Removed |Added
CC||sje at gcc dot gnu.org
--- Comment #5 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81361
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |8.0
Summary|Exceptions mishan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82141
--- Comment #37 from Eric Botcazou ---
Created attachment 42173
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42173&action=edit
Reduced testcase
To be compiled at -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82141
Eric Botcazou changed:
What|Removed |Added
Summary|[8 Regression] raised |[8 regression] raised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82215
Bug ID: 82215
Summary: Feature request to better support two pass compiling
with gfortran
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82209
--- Comment #2 from Jeffrey Walton ---
(In reply to Eric Gallager from comment #1)
> Do you have a complete standalone testcase we could use to reproduce?
Thanks Eric.
We were not able to reduce it to a minimal test case. That was part of the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82215
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82158
--- Comment #3 from Peter Cordes ---
(In reply to jos...@codesourcery.com from comment #2)
> Falling off a noreturn function sounds like it could be another case to
> insert __builtin_trap (), as we do in various cases of undefined behavior.
gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82209
--- Comment #3 from Eric Gallager ---
(In reply to Jeffrey Walton from comment #2)
> (In reply to Eric Gallager from comment #1)
> > Do you have a complete standalone testcase we could use to reproduce?
>
> Thanks Eric.
>
> We were not able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82215
--- Comment #2 from Lee Busby ---
(In reply to kargl from comment #1)
> It sound like you are looking for Fortran 2008's SUBMODULE feature.
> See for example
>
> https://software.intel.com/en-us/blogs/2015/07/07/doctor-fortran-in-we-all-
> live-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79622
--- Comment #4 from Sebastian Pop ---
Yes, that phi node looks like a reduction. We need to handle the phi as a
write to expose the loop carried reduction variable to the dependence analysis.
I think your change goes in the right direction. Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82216
Bug ID: 82216
Summary: internal compiler error: Illegal instruction
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82216
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82216
--- Comment #2 from Dendi Suhubdy ---
1) Did you compile gcc-7.2 yourself?
Yes
2) Did you compile GMP separately from GCC?
No, I did the `./contrib/download_prerequisites`
3) Are you running GCC on a different machine than you compiled GMP?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82216
--- Comment #3 from Andrew Pinski ---
How are you configuring GCC?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82208
--- Comment #2 from martin ---
Created attachment 42175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42175&action=edit
make log
make log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82217
Bug ID: 82217
Summary: ICE on valid code at -O1 and above: in visit_phi, at
tree-ssa-sccvn.c:3908
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82218
Bug ID: 82218
Summary: [C++1x] constexpr on static member function causes
segfault
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82218
--- Comment #1 from Emil Fresk ---
Moreover, if one changes so Params... type-pack is not void it also compiles
fine. The use of void seems to be the part causing the problem.
This can be tested by changing void(void) to void(int) on line 134, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82215
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
97 matches
Mail list logo
