https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82215
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=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=82216
--- Comment #3 from Andrew Pinski ---
How are you configuring GCC?
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
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=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=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=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=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=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=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
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=82141
Eric Botcazou changed:
What|Removed |Added
Summary|[8 Regression] raised |[8 regression] raised
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=81361
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |8.0
Summary|Exceptions mishan
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=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=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=81361
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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=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=82174
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=82195
Nathan Sidwell changed:
What|Removed |Added
Component|c++ |demangler
--- Comment #3 from Nathan Si
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=82209
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=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 #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=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=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=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=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=82186
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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=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=71187
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=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=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=82203
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
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=81929
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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=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=82171
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
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=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=82192
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Component|tree-optimization
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=81311
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
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=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=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=68823
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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=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=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=81314
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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=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=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=78994
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=82212
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
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=82213
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
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=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=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=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=78366
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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=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=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=81214
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=80996
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
URL|
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
--- 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=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=82210
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
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=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=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=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=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
97 matches
Mail list logo
