[Bug libgomp/65993] [6 Regression] Numerous libgomp.oacc failures seen in r222712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65993 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Keywords||openacc CC||jnorris at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org --- Comment #1 from Thomas Schwinge tschwinge at gcc dot gnu.org --- A regression exposed by the PR65205 commit r222620: looks like an issue with the %p format specifier printing a 0x prefix vs. not doing that.
[Bug tree-optimization/66002] New: paq8p benchmark 50% slower than clang on sandybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66002 Bug ID: 66002 Summary: paq8p benchmark 50% slower than clang on sandybridge Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Created attachment 35451 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35451action=edit testcase On sandybridge I get: trippels@gcc75 ~ % g++ -O3 -march=native paq8p.ii -o paq8p trippels@gcc75 ~ % time ./paq8p -4 file1.in Creating archive with 1 file(s)... file1.in 262144 - 262371 262144 - 262400 Extracting 1 file(s) from archive -4 Comparing file1.in 262144 - identical ./paq8p -4 file1.in 61.82s user 0.08s system 100% cpu 1:01.90 total trippels@gcc75 ~ % clang++ -w -O3 -march=native paq8p.ii -o paq8p trippels@gcc75 ~ % time ./paq8p -4 file1.in ... ./paq8p -4 file1.in 29.60s user 0.12s system 100% cpu 29.715 total Intel compiler: ./paq8p -4 file1.in 22.00s user 0.09s system 99% cpu 22.092 total
[Bug c++/66001] [5/6 regression] ICE when NSDMI in a literal class uses a destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66001 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-04 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |5.2 Summary|[5.1/6 regression] ICE when |[5/6 regression] ICE when |NSDMI in a literal class|NSDMI in a literal class |uses a destructor |uses a destructor Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r217664.
[Bug fortran/48890] [F95] Wrong length of a character component of named constant derived-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48890 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Francois-Xavier Coudert from comment #3) It's a Fortran 95-only issue! See the variant below: Why? I don't see ad hoc anything which makes this a F95-only bug. It looks to me like a general (g)Fortran bug (F90, F95, F2003, F2008, F2018).
[Bug tree-optimization/66003] New: missed cse opportunity in addr expressions because of tree pre/lim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66003
Bug ID: 66003
Summary: missed cse opportunity in addr expressions because of
tree pre/lim
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Target Milestone: ---
Below simple case is reduced from spec,
typedef struct
{
int x;
int y;
} coord;
extern unsigned short **org;
extern coord *c;
void bar (unsigned short *ptr);
void foo (int s, int n)
{
unsigned short arr[256], *ptr = arr;
int x, y;
for (y = c-y; y c-y + 16; y++)
for (x = c-x; x c-x + 16; x++)
*ptr++ = org [y][x];
bar (ptr);
}
When compiling with below two command lines
A: $gcc -Ofast -S test.c -o x.S
B: $gcc -Ofast -S test.c -o y.S -fno-tree-pre -fno-tree-loop-im
The assembly difference is as below:
$ diff x.S y.S
12,14c12,34
subq$520, %rsp
.cfi_def_cfa_offset 528
movqc(%rip), %rdx
---
pushq %r15
.cfi_def_cfa_offset 16
.cfi_offset 15, -16
pushq %r14
.cfi_def_cfa_offset 24
.cfi_offset 14, -24
pushq %r13
.cfi_def_cfa_offset 32
.cfi_offset 13, -32
pushq %r12
.cfi_def_cfa_offset 40
.cfi_offset 12, -40
pushq %rbp
.cfi_def_cfa_offset 48
.cfi_offset 6, -48
pushq %rbx
.cfi_def_cfa_offset 56
.cfi_offset 3, -56
subq$568, %rsp
.cfi_def_cfa_offset 624
movqc(%rip), %rax
movslq (%rax), %rsi
movslq 4(%rax), %rdx
16,20c36,58
movslq 4(%rdx), %rcx
leaq(%rax,%rcx,8), %rsi
movslq (%rdx), %rcx
movq%rsp, %rax
addq%rcx, %rcx
---
addq%rsi, %rsi
leaq24(%rsi), %rcx
leaq22(%rsi), %rdi
leaq2(%rsi), %r15
leaq4(%rsi), %r14
leaq6(%rsi), %r13
leaq8(%rsi), %r12
movq%rcx, 8(%rsp)
leaq26(%rsi), %rcx
leaq10(%rsi), %rbp
leaq12(%rsi), %rbx
leaq14(%rsi), %r11
leaq16(%rsi), %r10
movq%rcx, 16(%rsp)
leaq28(%rsi), %rcx
leaq18(%rsi), %r9
leaq20(%rsi), %r8
movq%rdi, 40(%rsp)
movq%rcx, 24(%rsp)
leaq30(%rsi), %rcx
movq%rcx, 32(%rsp)
leaq(%rax,%rdx,8), %rcx
leaq48(%rsp), %rax
24c62
movq(%rsi), %rdx
---
movq(%rcx), %rdx
26,27c64,65
addq$8, %rsi
movzwl (%rdx,%rcx), %edi
---
addq$8, %rcx
movzwl (%rdx,%rsi), %edi
29c67
movzwl 2(%rdx,%rcx), %edi
---
movzwl (%rdx,%r15), %edi
31c69
movzwl 4(%rdx,%rcx), %edi
---
movzwl (%rdx,%r14), %edi
33c71
movzwl 6(%rdx,%rcx), %edi
---
movzwl (%rdx,%r13), %edi
35c73
movzwl 8(%rdx,%rcx), %edi
---
movzwl (%rdx,%r12), %edi
37c75
movzwl 10(%rdx,%rcx), %edi
---
movzwl (%rdx,%rbp), %edi
39c77
movzwl 12(%rdx,%rcx), %edi
---
movzwl (%rdx,%rbx), %edi
41c79
movzwl 14(%rdx,%rcx), %edi
---
movzwl (%rdx,%r11), %edi
43c81
movzwl 16(%rdx,%rcx), %edi
---
movzwl (%rdx,%r10), %edi
45c83
movzwl 18(%rdx,%rcx), %edi
---
movzwl (%rdx,%r9), %edi
47c85
movzwl 20(%rdx,%rcx), %edi
---
movzwl (%rdx,%r8), %edi
49c87,88
movzwl 22(%rdx,%rcx), %edi
---
movq40(%rsp), %rdi
movzwl (%rdx,%rdi), %edi
51c90,91
movzwl 24(%rdx,%rcx), %edi
---
movq8(%rsp), %rdi
movzwl (%rdx,%rdi), %edi
53c93,94
movzwl 26(%rdx,%rcx), %edi
---
movq16(%rsp), %rdi
movzwl (%rdx,%rdi), %edi
55c96,97
movzwl 28(%rdx,%rcx), %edi
---
movq24(%rsp), %rdi
movzwl (%rdx,%rdi), %edi
57c99,100
movzwl 30(%rdx,%rcx), %edx
---
movq32(%rsp), %rdi
movzwl (%rdx,%rdi), %edx
59c102
leaq512(%rsp), %rdx
---
leaq560(%rsp), %rdx
64c107,119
addq$520, %rsp
---
addq$568, %rsp
.cfi_def_cfa_offset 56
popq%rbx
.cfi_def_cfa_offset 48
popq%rbp
.cfi_def_cfa_offset 40
popq%r12
.cfi_def_cfa_offset 32
popq%r13
.cfi_def_cfa_offset 24
popq%r14
.cfi_def_cfa_offset 16
popq%r15
The tree-pre dump is as below:
bb 2:
c.0_8 = c;
y_9 = c.0_8-y;
_47 = y_9 + 15;
pretmp_112 = c.0_8-x;
pretmp_128 = org;
pretmp_144 = (long unsigned int) pretmp_112;
pretmp_159 = pretmp_144 * 2;
pretmp_160 = pretmp_112 + 1;
pretmp_175 = (long unsigned int) pretmp_160;
pretmp_176 = pretmp_175 * 2;
pretmp_191 = pretmp_112 + 2;
pretmp_192 = (long unsigned int) pretmp_191;
pretmp_207 = pretmp_192 * 2;
pretmp_208 = pretmp_112 + 3;
[Bug libgomp/65993] [6 Regression] Numerous libgomp.oacc failures seen in r222712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65993 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-04 Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Patch posted: http://news.gmane.org/find-root.php?message_id=%3C87pp6gvj3v.fsf%40kepler.schwinge.homeip.net%3E.
[Bug fortran/65996] [5 Regression] gfortran ICE with -dH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65996 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-04 CC||burnus at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |5.2 Summary|[5.1 Regression] gfortran |[5 Regression] gfortran ICE |ICE with -dH|with -dH Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Most likely started with r217600.
[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835 --- Comment #7 from chrbr at gcc dot gnu.org --- aarch64: Seems to exhibit the same problem than x86: override_options_after_change doesn't restore the align flags. ia64: will check, chances that this exhibits the same latent bug.
[Bug tree-optimization/65935] [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65935
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
Testcase that also fails with -m64.
/* { dg-do run } */
/* { dg-additional-options -O3 } */
/* { dg-require-effective-target vect_double } */
#include tree-vect.h
extern void abort (void);
extern void *malloc (__SIZE_TYPE__);
struct site {
struct {
struct {
double real;
double imag;
} e[3][3];
} link[32];
double phase[32];
} *lattice;
int sites_on_node;
void rephase (void)
{
int i,j,k,dir;
struct site *s;
for(i=0,s=lattice;isites_on_node;i++,s++)
for(dir=0;dir32;dir++)
for(j=0;j3;j++)for(k=0;k3;k++)
{
s-link[dir].e[j][k].real *= s-phase[dir];
s-link[dir].e[j][k].imag *= s-phase[dir];
}
}
int main()
{
int i,j,k;
check_vect ();
sites_on_node = 1;
lattice = malloc (sizeof (struct site) * sites_on_node);
for (i = 0; i 32; ++i)
{
lattice-phase[i] = i;
for (j = 0; j 3; ++j)
for (k = 0; k 3; ++k)
{
lattice-link[i].e[j][k].real = 1.0;
lattice-link[i].e[j][k].imag = 1.0;
__asm__ volatile ( : : : memory);
}
}
rephase ();
for (i = 0; i 32; ++i)
for (j = 0; j 3; ++j)
for (k = 0; k 3; ++k)
if (lattice-link[i].e[j][k].real != i
|| lattice-link[i].e[j][k].imag != i)
abort ();
return 0;
}
/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 slp1 } } */
/* { dg-final { cleanup-tree-dump slp1 } } */
/* { dg-final { cleanup-tree-dump vect } } */
[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65990 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-04 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Not a regression, seems to have started with r201645 when the option has been introduced.
[Bug fortran/48890] [F95] Wrong length of a character component of named constant derived-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48890 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #4) (In reply to Francois-Xavier Coudert from comment #3) It's a Fortran 95-only issue! See the variant below: Why? I don't see ad hoc anything which makes this a F95-only bug. It looks to me like a general (g)Fortran bug (F90, F95, F2003, F2008, F2018). This means that this is a bug that is exposed by using only F95 features. These should receive high priority because we can not yet claim conformance to a standard F95.
[Bug fortran/50537] explicit interface required (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50537 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Severity|normal |enhancement
[Bug fortran/65996] [5 Regression] gfortran ICE with -dH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65996 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- The following test (from pr58334) program foo implicit none character(len=16) :: a,b,c a=XXX b= XXX c=XXX XXX write(0,*) 'a=',a,' b=',b,' c=',c endprogram foo shows the same behavior. BTW what -dH is supposed to do (I did not find it in the manual)?
[Bug fortran/65996] [5 Regression] gfortran ICE with -dH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65996 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Though, looking at the implementation and documentation of -dH, it sounds like it is intentional. -dH is supposed to stand for abort the compiler after issuing an error. That is not an internal compiler error, but just abort requested by the user. So NOTABUG IMHO.
[Bug fortran/50537] explicit interface required (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50537 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Since gcc version 4.9.2 and up to trunk (6.0) I now get pr50537_db.f90:5:24: character(len=2) f 1 Error: Explicit interface required for 'f' at (1): result with non-constant character length Does it mean that this PR is now fixed?
[Bug tree-optimization/65935] [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65935 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Testing a fix. The issue is latent with at least constant operands - but it's probably impossible(?) to get bogus operand order on those. In theory if the loads from phase were just in a different BB the issue would reproduce as well. OTOH then GCC 5 swaps in vect_get_and_check_slp_defs which already does swap operands in the IL...
[Bug middle-end/65984] [4.9/5/6 Regression] ICE: definition in block 4 does not dominate use in block 2 with -fnon-call-exceptions -fsanitize=enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65984 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-04 CC||jakub at gcc dot gnu.org Summary|ICE: definition in block 4 |[4.9/5/6 Regression] ICE: |does not dominate use in|definition in block 4 does |block 2 with|not dominate use in block 2 |-fnon-call-exceptions |with -fnon-call-exceptions |-fsanitize=enum |-fsanitize=enum Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r217755 (on the trunk) and r218151 (on 4.9 branch). Will have a look.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #35 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Mon May 4 10:16:23 2015 New Revision: 222759 URL: https://gcc.gnu.org/viewcvs?rev=222759root=gccview=rev Log: PR target/65559 * lto-wrapper.c (run_gcc): Open filename with in binary-mode. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-wrapper.c
[Bug fortran/65996] [5 Regression] gfortran ICE with -dH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65996 Melven.Roehrig-Zoellner at DLR dot de changed: What|Removed |Added Severity|normal |minor --- Comment #4 from Melven.Roehrig-Zoellner at DLR dot de --- man gcc | grep -- -dH -dH Produce a core dump whenever an error occurs. (This refers to a *compiler error* - so I should only need/use it to report a gcc bug.) But this flag shouldn't trigger an error when there is none without it or am I missing something here?
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #36 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Mon May 4 10:23:55 2015 New Revision: 222761 URL: https://gcc.gnu.org/viewcvs?rev=222761root=gccview=rev Log: Backmerge from trunk. PR lto/65559 * lto-wrapper.c (run_gcc): Open filename in binary-mode. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/lto-wrapper.c
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #37 from Kai Tietz ktietz at gcc dot gnu.org --- Fixed on trunk and on 5-branch.
[Bug c++/65992] Internal compiler error: in gimple_expand_cfg, at cfgexpand.c:5658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65992
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Started with r202605. Before:
/opt/notnfs/polacek/x.ii: In lambda function:
/opt/notnfs/polacek/x.ii:37:30: error: ‘const’ qualifiers cannot be applied to
‘const gen::CMembers’
[=] { [] { auto dummy = {(bs, 0)...}; }; };
^
/opt/notnfs/polacek/x.ii:37:36: error: expansion pattern ‘(bs, 0)’ contains no
argument packs
[=] { [] { auto dummy = {(bs, 0)...}; }; };
^
/opt/notnfs/polacek/x.ii: In instantiation of ‘struct gen::build(GenT, const
gen::CMembers ...) [with T = Foobarint; Members = {void
(Foobarint::*)(), void (Foobarint::*)(), int Foobarint::*}]::lambda()’:
/opt/notnfs/polacek/x.ii:37:3: required from ‘void gen::build(GenT, const
gen::CMembers ...) [with T = Foobarint; Members = {void
(Foobarint::*)(), void (Foobarint::*)(), int Foobarint::*}]’
/opt/notnfs/polacek/x.ii:48:37: required from here
/opt/notnfs/polacek/x.ii:37:30: sorry, unimplemented: use of
‘type_pack_expansion’ in template
[=] { [] { auto dummy = {(bs, 0)...}; }; };
^
/opt/notnfs/polacek/x.ii:37:30: error: using invalid field ‘gen::build(GenT,
const gen::CMembers ...)::lambda()::bs capture’
[Bug c++/65985] compiler segfault with assert() in constexpr constructor body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-04 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r217663.
[Bug c++/65985] [5/6 Regression] compiler segfault with assert() in constexpr constructor body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2 Summary|compiler segfault with |[5/6 Regression] compiler |assert() in constexpr |segfault with assert() in |constructor body|constexpr constructor body
[Bug fortran/65996] [5 Regression] gfortran ICE with -dH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65996 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- I don't have mpi installed, so it is hard to find out if you get an error or not - your testcase is clearly not self-contained; I certainly do get an error and correct abort after that.
[Bug ipa/65972] ICE after applying a patch to enable verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Can you attach preprocessed source for unwind-arm.c?
[Bug middle-end/65965] Straight-line memcpy/memset not vectorized when equivalent loop is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65965 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-04 Blocks||53947 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- It's because you don't init a[4]. Let me fix that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug fortran/65996] [5 Regression] gfortran ICE with -dH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65996 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- I don't have mpi installed, so it is hard to find out if you get an error or not - your testcase is clearly not self-contained; I certainly do get an error and correct abort after that. Self contained test in comment 2.
[Bug c++/65973] segmentation fault when compiling C++14 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65973 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r217663.
[Bug c++/65985] [5/6 Regression] compiler segfault with assert() in constexpr constructor body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Actually I think it's a dup. *** This bug has been marked as a duplicate of bug 65973 ***
[Bug c++/65973] segmentation fault when compiling C++14 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65973 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||rhalbersma at gmail dot com --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 65985 has been marked as a duplicate of this bug. ***
[Bug fortran/65996] [5 Regression] gfortran ICE with -dH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65996 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- So supposedly gfc_error needs to for buffered_p case also save and temporarily clear global_dc-abort_on_error. Maybe various other changes needed for that. Wonder what is -dH good for, don't really see when it would be really useful.
[Bug tree-optimization/65961] [6 Regression] ice in vect_is_simple_use_1 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r222514.
[Bug middle-end/61828] gcc.dg/strlenopt-8.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61828 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|5.2 |5.0 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- Long fixed.
[Bug middle-end/65984] [4.9/5/6 Regression] ICE: definition in block 4 does not dominate use in block 2 with -fnon-call-exceptions -fsanitize=enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65984 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.3
[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-05-04 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- It might be that this bug is a duplicate of pr/65559. Could you please check if with current trunk (or 5-branch) problem still exists?
[Bug middle-end/65963] Missed vectorization of loads strided with when equivalent * succeeds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65963 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-04 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. That's because SCEV interpret_rhs_expr doesn't handle LSHIFT_EXPR (it does handle MULT_EXPR). More places would need to handle LSHIFT_EXPR though, also in tree-chrec.c.
[Bug middle-end/65962] Missed vectorization of strided stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65962 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-04 CC||matz at gcc dot gnu.org Blocks||53947 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I believe Micha has patches for this? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/65961] [6 Regression] ice in vect_is_simple_use_1 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug target/65983] [6 Regression] ICE: SIGSEGV in mark_label_nuses (emit-rtl.c:3618) with -fsanitize=thread -mavx512ifma -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65983 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-04 CC||jakub at gcc dot gnu.org, ||tocarip at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r222470.
[Bug tree-optimization/65957] Loop with if-statement yields different results for -O3 vs -O3 -fno-tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65957 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |WAITING Last reconfirmed||2015-05-04 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- As you said the testcase doesn't reproduce the issue. And no - that means it's too hard to guess what goes wrong here. Thus waiting for some way to reproduce the issue.
[Bug c++/65985] [5/6 Regression] compiler segfault with assert() in constexpr constructor body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985 --- Comment #4 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Marek Polacek from comment #3) Actually I think it's a dup. Can we nonetheless ensure that the assert example would become a test case?
[Bug c++/65973] [5/6 Regression] segmentation fault when compiling C++14 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65973 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- When fixing this, remember to also add the testcase in PR65985.
[Bug rtl-optimization/65980] [6 Regression] -fcompare-debug failure building Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65980 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Component|debug |rtl-optimization --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- The noted difference appears in 244r.jump2, not really my area of expertise. diff -u a/t.c.243r.csa b/t.c.243r.csa | grep code_label -(code_label 13 78 14 5 8 [1 uses]) +(code_label 13 87 14 5 8 [1 uses]) -(code_label 79 82 26 8 17 [1 uses]) +(code_label 88 91 28 8 17 [1 uses]) -(code_label 37 85 38 11 9 [1 uses]) +(code_label 41 94 42 11 9 [1 uses]) -(code_label 42 39 43 12 7 [7 uses]) +(code_label 48 45 49 12 7 [7 uses]) -(code_label 47 88 48 13 12 (cc_label) [1 uses]) +(code_label 53 97 54 13 12 (cc_label) [1 uses]) -(code_label 54 90 55 14 14 (cc_label) [1 uses]) +(code_label 61 99 62 14 14 (cc_label) [1 uses]) -(code_label 61 92 62 15 16 (cc_label) [1 uses]) +(code_label 69 101 70 15 16 (cc_label) [1 uses]) -(code_label 86 94 69 16 18 [1 uses]) +(code_label 95 103 78 16 18 [1 uses]) diff -u a/t.c.244r.jump2 b/t.c.244r.jump2 | grep code_label -(code_label 13 78 14 5 8 [1 uses]) +(code_label 13 87 14 5 8 [1 uses]) -(code_label 79 117 26 8 17 [1 uses]) +(code_label 88 121 28 8 17 [1 uses]) -(code_label 111 28 32 9 20 [2 uses]) +(code_label 41 30 42 11 9 [2 uses]) -(code_label 42 33 43 12 7 [3 uses]) +(code_label 48 45 49 12 7 [3 uses]) -(code_label 61 54 62 15 16 (cc_label) [1 uses]) +(code_label 69 61 70 15 16 (cc_label) [1 uses]) -(code_label 86 94 69 16 18 [1 uses]) +(code_label 95 103 78 16 18 [1 uses])
[Bug lto/65982] [5/6 Regression] ICE: in lto_output_varpool_node, at lto-cgraph.c:623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65982 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.2
[Bug target/65987] [6 Regression] [SH] Wrong jump generated for gcc.dg/tree-prof/va-arg-pack-1.c with -fprofile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65987 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug libgomp/65993] [6 Regression] Numerous libgomp.oacc failures seen in r222712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65993 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Version|5.0 |6.0 Target Milestone|--- |6.0
[Bug tree-optimization/66003] missed cse opportunity in addr expressions because of tree pre/lim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66003 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Hmm, I think IVOPTs should be able to undo this code motion?
[Bug c++/66001] [5/6 regression] ICE when NSDMI in a literal class uses a destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66001 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #3 from Mikhail Maltsev maltsevm at gmail dot com --- The second testcase is similar to PR65966 (same error message and it is also caused by implicitly constexpr constructor in a class with non-constexpr-NSDMI)
[Bug fortran/65996] [5/6 Regression] gfortran ICE with -dH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65996 --- Comment #8 from Melven.Roehrig-Zoellner at DLR dot de --- Thanks for the quick replies and the discussion about the not-so-usefulness of the -dH switch (at least for our project). We most probably used this switch by mistake - you might possibly improve the documentation by adding -dH Produce a core dump whenever a *compilation* error occurs. to prevent further misunderstandings for people who don't read the full paragraph.
[Bug go/61303] gccgo: segfault, regression since 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61303
--- Comment #8 from Maciej Bliziński maciej at opencsw dot org ---
Here's my attempt to get some information:
experimental10s 14:35:13 ~/src/opencsw-gar/v2/go $ gcc -v
Reading specs from /opt/csw/lib/gcc/sparc-sun-solaris2.10/5.1.0/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/csw/libexec/gcc/sparc-sun-solaris2.10/5.1.0/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with:
/home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.1.0/configure
--prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin
--sbindir=/opt/csw/sbin --libexs
Thread model: posix
gcc version 5.1.0 (GCC)
experimental10s 14:31:43 ~/src/opencsw-gar/v2/go $ export CFLAGS=-g
experimental10s 14:31:55 ~/src/opencsw-gar/v2/go $ gmake bin/package-gar-status
gccgo -o src/opencsw/diskformat/diskformat.o -g -c
src/opencsw/diskformat/diskformat.go
ginstall -m 755 src/opencsw/diskformat/diskformat.o opencsw/diskformat.o
gccgo -o src/opencsw/mantis/mantis.o -g -c src/opencsw/mantis/mantis.go
# ginstall
cp src/opencsw/mantis/mantis.o opencsw/mantis.o
gccgo -g -o bin/package-gar-status src/package-gar-status/package-gar-status.go
opencsw/diskformat.o opencsw/mantis.o
experimental10s 14:32:15 ~/src/opencsw-gar/v2/go $ # bin/package-gar-status
-output-file=foo.md
experimental10s 14:32:29 ~/src/opencsw-gar/v2/go $ gdb bin/package-gar-status
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as sparc-sun-solaris2.10.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from bin/package-gar-status...done.
(gdb) run -output-file=foo.md
Starting program: /home/maciej/src/opencsw-gar/v2/go/bin/package-gar-status
-output-file=foo.md
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
[New LWP2]
[New LWP3]
2015/05/04 14:33:05 Program start
2015/05/04 14:33:05 Looking at catalog {unstable i386 SunOS5.10} only.
2015/05/04 14:33:05 Making a request to
http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/i386/SunOS5.10/for-generation/as-dicts/
[New LWP4]
[New LWP5]
[New Thread 4 (LWP 4)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4 (LWP 4)]
0xfe3c0d88 in memcpy () from
/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1
(gdb) where
#0 0xfe3c0d88 in memcpy () from
/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1
#1 0xfe9453d0 in runtime_netpoll (block=block@entry=1 '\001') at
/home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.1.0/libgo/runtime/netpoll_select.c:163
#2 0xfe94a794 in findrunnable () at
/home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.1.0/libgo/runtime/proc.c:1667
#3 schedule () at
/home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.1.0/libgo/runtime/proc.c:1765
#4 0xfe94aad8 in runtime_mstart (mp=0xde315c00) at
/home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.1.0/libgo/runtime/proc.c:1000
#5 0xff1baec8 in _lwp_start () from /lib/libc.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[Bug libstdc++/66004] New: [6 Regression]: performance of 26_numerics/random/negative_binomial_distribution/operators/values.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66004 Bug ID: 66004 Summary: [6 Regression]: performance of 26_numerics/random/negative_binomial_distribution/oper ators/values.cc Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: cris-elf For r221618, this test took 34633750695 basic clock cycles in the CRIS simulator. For r222742 (aka. now), it takes 40111446541 (same unit). This is a performance regression of about 16% in less than 1.5 month! I noticed because the test started to fail on my autotester machine during times of load, when it has been previously silent. The cris-elf is a 32-bit soft-float target. Note that the situation is the opposite of that in PR65093. I'm listing the libstdc++ component as the cause, will update as my (low-intensity) investigation (which I guess will be mostly bisecting) continues. It is also a likely culprit, with the recent work alluded to in PR65093 (either further work or another side of the coin, of changes there improving performance). My first reaction, before checking for regression, was the test can and should be split up as in PR65093. I still think it should, after the regression is fixed. (Revision r221618 happens to be the last regression-free revision for cris-elf; after that no components outside the gcc repo have been updated.) Relative performance numbers for other platforms at svn revisions near those above would be interesting.
[Bug tree-optimization/66002] paq8p benchmark 50% slower than clang on sandybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66002 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- gprof tells me Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 67.13 25.4025.40 2097192 0.00 0.00 contextModel2() 18.08 32.24 6.84 18874735 0.00 0.00 ContextMap::mix1(Mixer, int, int, int, int) 9.46 35.82 3.58 2097192 0.00 0.00 Mixer::p() 2.72 36.85 1.03 14680344 0.00 0.00 APM1::p(int, int, int) 0.53 37.05 0.20 2097192 0.00 0.00 dmcModel(Mixer) probably not too interesting (inlining). I wonder if you can run clang++ with vectorization disabled?
[Bug tree-optimization/66002] paq8p benchmark 50% slower than clang on sandybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66002 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- clang without -vectorize-loops -vectorize-slp: ./paq8p -4 file1.in 54.82s user 0.08s system 100% cpu 54.891 total
[Bug testsuite/65767] Test pr65276 failed on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2015-05-04 CC||ro at gcc dot gnu.org Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #6 from Rainer Orth ro at gcc dot gnu.org --- Unfortunately, the fix broke the test completely on Solaris with /bin/ld: Undefined first referenced symbol in file std2::exception::~exception() cp_lto_pr65276_1.o std2::exception::~exception() cp_lto_pr65276_1.o std2::exception::~exception() cp_lto_pr65276_1.o ld: fatal: symbol referencing errors collect2: error: ld returned 1 exit status Rainer
[Bug lto/52159] ICE when building qemu with GCC 4.7 trunk: cannot read LTO decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52159 Steffen Hau steffen at hauihau dot de changed: What|Removed |Added CC||steffen at hauihau dot de --- Comment #3 from Steffen Hau steffen at hauihau dot de --- I don't know wether this is a GCC issue, but I have recompiled all my packages on Gentoo with GCC 5.1.0 and LD Gold from binutils 2.25 and ran into the same error for Qemu 2.3.0: x86_64-pc-linux-gnu-g++ -I/usr/include/pixman-1 -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/libpng16 -I/usr/include/libusb-1.0 -I/home/gentoo/tmp/portage/app-emulation/qemu-2.3.0/work/qemu-2.3.0/tests -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin -Wl,-z,relro -Wl,-z,now -pie -m64 -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin -Wl,-znow -Wl,--sort-common -Wl,--hash-style=gnu -Wl,--enable-new-dtags -o qemu-img qemu-img.o async.o thread-pool.o nbd.o block.o blockjob.o main-loop.o iohandler.o qemu-timer.o aio-posix.o qemu-io-cmds.o qemu-coroutine.o qemu-coroutine-lock.o qemu-coroutine-io.o qemu-coroutine-sleep.o coroutine-ucontext.o block/raw_bsd.o block/qcow.o block/vdi.o block/vmdk.o block/cloop.o block/dmg.o block/bochs.o block/vpc.o block/vvfat.o block/qcow2.o block/qcow2-refcount.o block/qcow2-cluster.o block/qcow2-snapshot.o block/qcow2-cache.o block/qed.o block/qed-gencb.o block/qed-l2-cache.o block/qed-table.o block/qed-cluster.o block/qed-check.o block/vhdx.o block/vhdx-endian.o block/vhdx-log.o block/parallels.o block/blkdebug.o block/blkverify.o block/block-backend.o block/snapshot.o block/qapi.o block/raw-posix.o block/linux-aio.o block/null.o block/mirror.o block/nbd.o block/nbd-client.o block/sheepdog.o block/accounting.o block/write-threshold.o block/curl.o libqemuutil.a libqemustub.a -lz -lbz2 -laio -lcurl -lm -lgthread-2.0 -pthread -lglib-2.0 -lz -lrt -lz -lcap-ng -luuid -lutil lto1: error: two or more sections for .gnu.lto_fprintf.bea14a90a0409768 (null):0: confused by earlier errors, bailing out make: *** [/tmp/ccPpXBxT.ltrans11.ltrans.o] Error 1 make: *** Waiting for unfinished jobs lto-wrapper: fatal error: make returned 2 exit status compilation terminated. /usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status The same happens with LD BFD. Only workaround is to disable LTO. GCC 4.9.2 doesn't show this error and compiles the code. I was able to break down the Object List to three files which reproduce the error reliably. I compiled the files with the --save-temps switch, but I'm not able, to reproduce the error with the resulting .i files because of other compiler errors like 'abc' does not name a type or error: 'xyz' was not declared in this scope. I'll attach the preprocessed sources as well as the commandline options I've used to compile and link. Please let me know if I need to provide further information. gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.1.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/gentoo/tmp/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.1.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.1.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.1.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.1.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/include/g++-v5 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.1.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.1.0 p1.0, pie-0.6.3' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
[Bug libstdc++/66004] [6 Regression]: performance of 26_numerics/random/negative_binomial_distribution/operators/values.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66004 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Version|unknown |6.0 Target Milestone|--- |6.0
[Bug lto/52159] ICE when building qemu with GCC 4.7 trunk: cannot read LTO decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52159 --- Comment #4 from Steffen Hau steffen at hauihau dot de --- Created attachment 35452 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35452action=edit preprocessed sources and minimal build script
[Bug other/51153] OpenACC implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51153 Bug 51153 depends on bug 64950, which changed state. Bug 64950 Summary: postpone expanding va_arg till pass_stdarg https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug tree-optimization/64950] postpone expanding va_arg till pass_stdarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Resolution|FIXED |--- --- Comment #11 from Rainer Orth ro at gcc dot gnu.org --- Unfortunately, the gcc.dg/tree-ssa/stdarg-2.c part of the patch is wrong: the test now FAILs on i686-unknown-linux-gnu, i686-apple-darwin, and i386-pc-solaris with -m64: both dumps (i.e. -m32 and -m64) contain m32/stdarg-2.c.084t.stdarg:f15: va_list escapes 1, needs to save all GPR units and all FPR units. m64/stdarg-2.c.084t.stdarg:f15: va_list escapes 1, needs to save all GPR units and all FPR units. Rainer
[Bug target/41089] [4.8/4.9/5/6 Regression] stdarg pass produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089 Bug 41089 depends on bug 64950, which changed state. Bug 64950 Summary: postpone expanding va_arg till pass_stdarg https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug target/65983] [6 Regression] ICE: SIGSEGV in mark_label_nuses (emit-rtl.c:3618) with -fsanitize=thread -mavx512ifma -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65983 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Depends on||65915 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Related to (or maybe dup of) PR65915. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65915 [Bug 65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)
[Bug libgomp/65993] [6 Regression] Numerous libgomp.oacc failures seen in r222712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65993 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11, ||*-*-solaris2.* CC||ro at gcc dot gnu.org Host|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11, ||*-*-solaris2.* Build|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11, ||*-*-solaris2.* --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- Solaris has the same issue.
[Bug tree-optimization/65935] [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65935 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon May 4 13:31:02 2015 New Revision: 222764 URL: https://gcc.gnu.org/viewcvs?rev=222764root=gccview=rev Log: 2015-05-04 Richard Biener rguent...@suse.de PR tree-optimization/65935 * tree-vect-slp.c (vect_build_slp_tree): If we swapped operands then make sure to apply that swapping to the IL. * gcc.dg/vect/bb-slp-pr65935.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/bb-slp-pr65935.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/65935] [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65935 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug libgomp/66005] New: libgomp make check time is excessive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 Bug ID: 66005 Summary: libgomp make check time is excessive Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jakub at gcc dot gnu.org, tschwinge at gcc dot gnu.org Target Milestone: --- With all those OpenACC tests having been added to the libgomp testsuite, make check times have skyrocketed on the gcc 5 branch and mainline: On a reasonably fast x86 machine, it takes 4286 seconds: Test Run By ro on Sat May 2 00:56:49 2015 runtest completed at Sat May 2 02:08:15 2015 while e.g. on slower sparc boxes we're at 29406 seconds: Test Run By ro on Fri May 1 18:38:07 2015 runtest completed at Sat May 2 02:48:13 2015 while for 4.9 we had only 7825 seconds: Test Run By ro on Sat May 2 17:20:23 2015 runtest completed at Sat May 2 19:30:48 2015 Being sequential, the libgomp testsuite is the last to finish, slowing down the whole test. Rainer
[Bug tree-optimization/66002] paq8p benchmark 50% slower than clang on sandybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66002
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
high up in the profile are functions train() and dot_product(), also
ContextMap::mix1 and Mixer::p. But
void train(short *t, short *w, int n, int err) {
n=(n+7)-8;
for (int i=0; in; ++i) {
int wt=w[i]+((t[i]*err*216)+11);
if (wt-32768) wt=-32768;
if (wt32767) wt=32767;
w[i]=wt;
}
}
seems to be the hottest function.
t.c:4:5: note: not vectorized: relevant stmt not supported: prephitmp_61 = _53
= 65535 ? pretmp_60 : -32768;
t.c:4:5: note: bad operation or unsupported loop bound.
t.c:1:6: note: vectorized 0 loops in function.
bb 5:
# i_33 = PHI 0(4), i_28(7)
_9 = (long unsigned int) i_33;
_10 = _9 * 2;
_12 = w_11(D) + _10;
_13 = *_12;
_14 = (int) _13;
_16 = t_15(D) + _10;
_17 = *_16;
_18 = (int) _17;
_20 = _18 * err_19(D);
_21 = _20 * 2;
_22 = _21 16;
_23 = _22 + 1;
_24 = _23 1;
wt_25 = _14 + _24;
pretmp_60 = (short int) wt_25;
_31 = (unsigned int) wt_25;
_53 = _31 + 32768;
prephitmp_61 = _53 = 65535 ? pretmp_60 : -32768;
_32 = _53 = 65535;
_52 = wt_25 -32768;
_51 = _32 | _52;
prephitmp_59 = _51 ? prephitmp_61 : 32767;
*_12 = prephitmp_59;
i_28 = i_33 + 1;
if (n_7 i_28)
goto bb 7;
else
goto bb 6;
bb 7:
goto bb 5;
[Bug tree-optimization/66002] paq8p benchmark 50% slower than clang on sandybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66002
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-04
Blocks||53947
Ever confirmed|0 |1
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
prephitmp_61 = _53 = 65535 ? pretmp_60 : -32768;
is
unsigned int = 65535 ? short int : short int;
pushing the condition to a separate stmt might get us to support this
narrowing conversion.
Of course ifcvt does a pretty poor job on this as well...
We do vectorize
for (int i=0; in; ++i) {
int wt=w[i]+((t[i]*err*216)+11);
if (wt-32768) wt=-32768;
// if (wt32767) wt=32767;
w[i]=wt;
}
as if (wt-32768) wt=-32768; becomes a MAX_EXPR. Also if I change it to
for (int i=0; in; ++i) {
int wt=w[i]+((t[i]*err*216)+11);
if (wt-32768) wt=-32768;
else if (wt32767) wt=32767;
w[i]=wt;
}
we vectorize it as MIN/MAX_EXPRs.
Maybe you can perform this source change manually and see what it does
to performance.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/66002] paq8p benchmark 50% slower than clang on sandybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66002 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- VRP performs jump-threading to else-if style but phiopt doesn't handle the min-max case with split PHIs if (wt_25 -32768) goto bb 5; else goto bb 4; bb 4: if (wt_25 32767) goto bb 6; else goto bb 5; bb 5: # wt_31 = PHI wt_25(4), -32768(3) bb 6: # wt_3 = PHI wt_31(5), 32767(4) _26 = (short int) wt_3; vs. if (wt_24 -32768) goto bb 6; else goto bb 4; bb 4: if (wt_24 32767) goto bb 6; else goto bb 5; bb 5: bb 6: # wt_2 = PHI -32768(3), wt_24(5), 32767(4) _25 = (short int) wt_2; so it looks like phiopt depends on mergephi (I always wondered what pass that is useful for...). Currently that pass runs right before VRP which definitely does _not_ depend on it. I'd move it right before ifcombine which is the first pass that might care.
[Bug libstdc++/66006] New: [6 regression] abi_check FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66006 Bug ID: 66006 Summary: [6 regression] abi_check FAILs Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* Within the last few days, the libstdc++-v3 abi_check started to FAIL on Solaris: libstdc++.log has 2 incompatible symbols 0 _ZNSt7__cxx1115basic_stringbufIwSt11char_traitsIwESaIwEED2Ev std::__cxx11::basic_stringbufwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::~basic_stringbuf() version status: incompatible GLIBCXX_3.4.21 type: function status: added 1 _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED2Ev std::__cxx11::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::~basic_stringbuf() version status: incompatible GLIBCXX_3.4.21 type: function status: added I have no idea what's going on here: those symbols are in the gcc 5 libstdc++.so already, no idea why they are considered incompatible. Rainer
[Bug libstdc++/66006] [6 regression] abi_check FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66006 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug tree-optimization/66002] paq8p benchmark 50% slower than clang on sandybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66002
--- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
prephitmp_61 = _53 = 65535 ? pretmp_60 : -32768;
is
unsigned int = 65535 ? short int : short int;
pushing the condition to a separate stmt might get us to support this
narrowing conversion.
Of course ifcvt does a pretty poor job on this as well...
We do vectorize
for (int i=0; in; ++i) {
int wt=w[i]+((t[i]*err*216)+11);
if (wt-32768) wt=-32768;
// if (wt32767) wt=32767;
w[i]=wt;
}
as if (wt-32768) wt=-32768; becomes a MAX_EXPR. Also if I change it to
for (int i=0; in; ++i) {
int wt=w[i]+((t[i]*err*216)+11);
if (wt-32768) wt=-32768;
else if (wt32767) wt=32767;
w[i]=wt;
}
we vectorize it as MIN/MAX_EXPRs.
Maybe you can perform this source change manually and see what it does
to performance.
With the else added gcc beats clang:
./paq8p -4 file1.in 24.81s user 0.10s system 100% cpu 24.902 total
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394
Steffen Hau steffen at hauihau dot de changed:
What|Removed |Added
CC||steffen at hauihau dot de
--- Comment #30 from Steffen Hau steffen at hauihau dot de ---
Hey Jan,
I'm not able to successfully compile LO (4.4.2.2) with GCC 5.1.0. I'm getting
segmentation faults when gengal.bin is executed:
/bin/sh: line 1: 5682 Segmentation fault SAL_USE_VCLPLUGIN=svp
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/ure/lib:$I/program
$I/program/gengal.bin -env:BRAND_BASE_DIR=file://$S/instdir
-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry
-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
file://$W/ComponentTarget/comphelper/util/comphelp.component
file://$W/ComponentTarget/configmgr/source/configmgr.component
file://$W/ComponentTarget/drawinglayer/drawinglayer.component
file://$W/ComponentTarget/framework/util/fwk.component
file://$W/ComponentTarget/i18npool/util/i18npool.component
file://$W/ComponentTarget/package/source/xstor/xstor.component
file://$W/ComponentTarget/package/util/package2.component
file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component
file://$W/ComponentTarget/sfx2/util/sfx.component
file://$W/ComponentTarget/svgio/svgio.component
file://$W/ComponentTarget/svx/util/svx.component
file://$W/ComponentTarget/svx/util/svxcore.component
file://$W/ComponentTarget/ucb/source/core/ucb1.component
file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component
file://$W/ComponentTarget/unoxml/source/service/unoxml.component
-env:UNO_TYPES= file://$I/program/types/offapi.rdb
file://$I/ure/share/misc/types.rdb -env:URE_INTERNAL_LIB_DIR=file://$I/ure/lib
-env:LO_LIB_DIR=file://$I/program --build-tree --destdir
file://$S/extras/source/gallery --name arrows --path $W/Gallery/arrows
--filenames file://$RESPONSEFILE
/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/solenv/gbuild/Gallery.mk:72:
recipe for target
'/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done'
failed
make[1]: ***
[/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done]
Error 139
make[1]: *** Waiting for unfinished jobs
Any ideas?
[Bug c++/66007] New: [5 Regression] Narrowing conversion inside { } results in all zero elements in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66007
Bug ID: 66007
Summary: [5 Regression] Narrowing conversion inside { } results
in all zero elements in C++11 mode
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: evangelos at foutrelis dot com
Target Milestone: ---
Created attachment 35453
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35453action=edit
Different narrowing behavior between GCC 4.9 and GCC 5
This is related to PR c++/65801 which allowed -Wno-narrowing to be used to
silence narrowing errors in C++11 mode.
Compiling something like int foo[] = { 1, 0x, 3 }; with -std=c++11
-Wno-error=narrowing will initialize foo to {0, 0, 0}, whereas GCC 4.9 would
initialize it to {1, -1, 3}. (Attached is the assembler code generated by both
GCC versions.)
(This change in behavior causes at least one crash in Chromium; when using the
search box on the settings page, the tab will crash.)
[Bug lto/52159] ICE when building qemu with GCC 4.7 trunk: cannot read LTO decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52159 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Steffen Hau from comment #3) The same happens with LD BFD. Only workaround is to disable LTO. GCC 4.9.2 doesn't show this error and compiles the code. I was able to break down the Object List to three files which reproduce the error reliably. I compiled the files with the --save-temps switch, but I'm not able, to reproduce the error with the resulting .i files because of other compiler errors like 'abc' does not name a type or error: 'xyz' was not declared in this scope. This happens because you use gcc for compiling and g++ for linking in your build script.
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 Evangelos Foutras evangelos at foutrelis dot com changed: What|Removed |Added CC||evangelos at foutrelis dot com --- Comment #23 from Evangelos Foutras evangelos at foutrelis dot com --- Please note that narrowing conversions don't seem to work the same way they did in GCC 4.9; I've filed PR c++/66007 for this change in behavior.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 65965, which changed state. Bug 65965 Summary: Straight-line memcpy/memset not vectorized when equivalent loop is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65965 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/65965] Straight-line memcpy/memset not vectorized when equivalent loop is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65965 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon May 4 14:24:49 2015 New Revision: 222765 URL: https://gcc.gnu.org/viewcvs?rev=222765root=gccview=rev Log: 2015-05-04 Richard Biener rguent...@suse.de PR tree-optimization/65965 * tree-vect-data-refs.c (vect_analyze_data_ref_accesses): Split store groups at gaps. * gcc.dg/vect/bb-slp-33.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/bb-slp-33.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug middle-end/65965] Straight-line memcpy/memset not vectorized when equivalent loop is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65965 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed for GCC 6.
[Bug fortran/44735] ICE on FORALL with character array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44735 --- Comment #8 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Mon May 4 14:27:14 2015 New Revision: 222766 URL: https://gcc.gnu.org/viewcvs?rev=222766root=gccview=rev Log: PR fortran/44735 * gfortran.dg/pr44735.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr44735.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/44735] ICE on FORALL with character array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44735 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #9 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Testcase committed, closing as FIXED.
[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834 Bug 32834 depends on bug 44735, which changed state. Bug 44735 Summary: ICE on FORALL with character array pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44735 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276 Bug 19276 depends on bug 44735, which changed state. Bug 44735 Summary: ICE on FORALL with character array pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44735 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/66007] [5 Regression] Narrowing conversion inside { } results in all zero elements in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66007
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
I cannot reproduce this on today's 5 branch:
markus@x4 tmp % echo 'int foo[] = { 1, 0x, 3 };' | g++ -S -x c++ - -o -
-std=c++11 -Wno-narrowing
.file
.globl foo
.data
.align 8
.type foo, @object
.size foo, 12
foo:
.long 1
.long -1
.long 3
.ident GCC: (GNU) 5.1.1
.section.note.GNU-stack,,@progbits
[Bug fortran/65428] ICE on nest array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65428 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2015-03-15 00:00:00 |2015-5-4 --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- The original example is Fortran 2003 (array constructor with type specification). Here is a pure Fortran 95 example, which is also an ice-on-valid-code: integer :: i print *, (/ (/ (i, i=1,0) /) /) end Surprisingly, this constructor works OK when used as initializer: integer :: i integer, parameter :: x(0) = (/ (/ (i, i=1,0) /) /) print *, x print *, (/ x /) end
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 62283, which changed state. Bug 62283 Summary: basic-block vectorization fails https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug fortran/62283] basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 --- Comment #24 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 35454 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35454action=edit bb-slp-14.c.141t.slp2 dump
[Bug fortran/62283] basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #23 from Rainer Orth ro at gcc dot gnu.org --- The bb-slp-14.c testcase now FAILs on Solaris/SPARC. Attaching the dump. Rainer
[Bug rtl-optimization/53533] [4.8/4.9/5/6 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #28 from Mikhail Maltsev maltsevm at gmail dot com --- Created attachment 35455 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35455action=edit testcase, inlining This testcase marks some functions with __attribute__((always_inline/noinline)) when -DINLINE_MANUALLY is defined.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Resolution|FIXED |--- --- Comment #22 from Rainer Orth ro at gcc dot gnu.org --- I suspect the change to gcc.dg/vect/bb-slp-32.c caused the test to XPASS on Solaris/SPARC. Attaching the dump. Rainer
[Bug c++/66007] [5 Regression] Narrowing conversion inside { } results in all zero elements in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66007 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Closing as fixed.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 --- Comment #23 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 35456 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35456action=edit bb-slp-32.c.141t.slp2 dump
[Bug rtl-optimization/53533] [4.8/4.9/5/6 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #29 from Mikhail Maltsev maltsevm at gmail dot com --- Results for attached testcase: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz (Haswell) g++ -O3 -march=native -mtune=native 1 iterations Clang 3.7 Total absolute time for int32_t for loop unrolling: 0.99 sec Total absolute time for int32_t do loop unrolling: 1.00 sec Total absolute time for double for loop unrolling: 1.37 sec Total absolute time for double do loop unrolling: 1.37 sec GCC 4.7.4 Total absolute time for int32_t for loop unrolling: 5.88 sec Total absolute time for int32_t do loop unrolling: 7.57 sec Total absolute time for double for loop unrolling: 2.29 sec Total absolute time for double do loop unrolling: 2.45 sec GCC 4.8.4 Total absolute time for int32_t for loop unrolling: 3.12 sec Total absolute time for int32_t do loop unrolling: 3.29 sec Total absolute time for double for loop unrolling: 1.13 sec Total absolute time for double do loop unrolling: 1.14 sec GCC 4.9.2 Total absolute time for int32_t for loop unrolling: 3.02 sec Total absolute time for int32_t do loop unrolling: 3.29 sec Total absolute time for double for loop unrolling: 1.10 sec Total absolute time for double do loop unrolling: 1.13 sec GCC 6 Total absolute time for int32_t for loop unrolling: 5.95 sec Total absolute time for int32_t do loop unrolling: 6.95 sec Total absolute time for double for loop unrolling: 2.39 sec Total absolute time for double do loop unrolling: 2.39 sec g++ -DINLINE_MANUALLY -O3 -march=native -mtune=native 5 iterations Clang 3.7 Total absolute time for int32_t for loop unrolling: 2.43 sec Total absolute time for int32_t do loop unrolling: 2.32 sec Total absolute time for double for loop unrolling: 6.38 sec Total absolute time for double do loop unrolling: 6.38 sec GCC 4.9.2 Total absolute time for int32_t for loop unrolling: 10.17 sec Total absolute time for int32_t do loop unrolling: 10.16 sec Total absolute time for double for loop unrolling: 3.89 sec Total absolute time for double do loop unrolling: 3.90 sec GCC 6 Total absolute time for int32_t for loop unrolling: 10.10 sec Total absolute time for int32_t do loop unrolling: 10.12 sec Total absolute time for double for loop unrolling: 3.90 sec Total absolute time for double do loop unrolling: 3.89 sec g++ -DINLINE_MANUALLY -Ofast -march=native -mtune=native GCC 6 Total absolute time for int32_t for loop unrolling: 10.11 sec Total absolute time for int32_t do loop unrolling: 10.11 sec Total absolute time for double for loop unrolling: 1.14 sec Total absolute time for double do loop unrolling: 1.15 sec So, IMHO there is no regression here (at least w.r.t. vectorization). Floating point loop gets constant-folded, if reassociation is allowed. Also, GCC6 is able to infer that for and while tests are semantically equivalent and unifies them.
[Bug ipa/65972] ICE after applying a patch to enable verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972 --- Comment #3 from AK hiraditya at msn dot com --- Created attachment 35457 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35457action=edit Preprocesed unwind-arm.i
[Bug fortran/64674] [OOP] ICE in ASSOCIATE with class array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64674 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||vehre at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
[Bug fortran/64674] [OOP] ICE in ASSOCIATE with class array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64674 --- Comment #4 from vehre at gcc dot gnu.org --- First patch available at: https://gcc.gnu.org/ml/fortran/2015-05/msg00011.html
[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 vehre at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from vehre at gcc dot gnu.org --- No complaints since commit r222478. I therefore close this pr.
[Bug fortran/47359] Recursive functions of intrinsic names generates invalid assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47359 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2011-05-23 09:58:19 |2015-5-4 CC||fxcoudert at gcc dot gnu.org --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Still fails. Somewhat reduced/reworked testcase: program test external max print *, max(42, 1) end recursive function max(a, b) result(k) integer a, b, k if (b 0) then k = max(a, b-1) else k = 0 end if end function where you can see that generated code for function max does not call itself, as it should. The output of that program is 42, while it should be 0. Providing an explicit interface for max is also not working: program test interface recursive function max(a, b) result(k) integer a, b, k end function end interface print *, max(42, 1) end recursive function max(a, b) result(k) integer a, b, k if (b 0) then k = max(a, b-1) else k = 0 end if end function
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org --- I believe that the resolution of DR 1630 clarifies that value-initialization can invoke an explicit constructor even in copy-list-initialization context, so I should revert my change for this PR.
[Bug c++/65854] [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65854 --- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com --- Confirmed. Parsing a type requirement that names an alias template was giving back a declaration, which wasn't being instantiated correctly. r222769 unwraps the type from the declaration and will correctly reject the test case.
