[Bug tree-optimization/78413] [7 Regression] ICE in single_pred_edge, at basic-block.h:361

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment

[Bug other/78410] gen-fac.c: undefined references

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78410 Alec Ari changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/78413] [7 Regression] ICE in single_pred_edge, at basic-block.h:361

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413 --- Comment #1 from Markus Trippelsdorf --- Another testcase markus@x4 /tmp % cat test2.i struct S { _Bool bo; }; int a, b, c, d; void fn1() { do do do { struct S *e = (struct S *)1; do b = a / (e->bo ? 2

[Bug tree-optimization/78413] New: [7 Regression] ICE in single_pred_edge, at basic-block.h:361

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413 Bug ID: 78413 Summary: [7 Regression] ICE in single_pred_edge, at basic-block.h:361 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal

[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72747 Markus Trippelsdorf changed: What|Removed |Added CC||npmccallum at redhat dot com ---

[Bug c/78408] C loop initial declarations generate wrong code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394 Andrew Pinski changed: What|Removed |Added Blocks||24639 --- Comment #3 from Andrew Pinski

[Bug c++/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78391 Andrew Pinski changed: What|Removed |Added Blocks||24639 --- Comment #3 from Andrew Pinski

[Bug libgcc/78409] Segfault in classify_object_over_fdes when throwing and exception

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78409 --- Comment #1 from Andrew Pinski --- We need a testcase.

[Bug other/78410] gen-fac.c: undefined references

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78410 --- Comment #1 from Andrew Pinski --- >I've already built binutils and newlib You are building gcc against newlib; that is broken.

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78002 hs.naveen2u at gmail dot com changed: What|Removed |Added CC||hs.naveen2u at gmail dot

[Bug libfortran/78379] Processor-specific versions for matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #8 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #6) > > You may notice I was invoking the wrong executable in what I posted in > > comment #3. I did rerun the correct one several times and tried it with > > -mavx

[Bug ipa/78296] [7 regression] test case gcc.dg/ipa/vrp7.c fails starting with r242032

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78296 kugan at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c/78365] [7 Regression] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78365 --- Comment #6 from kugan at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) > IPA has to deal with argument mismatches (I think I've said this elsewhere). As I understand, this is along what you found earlier but a different

[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on m68k

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on m68k

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219 --- Comment #19 from Jeffrey A. Law --- Author: law Date: Thu Nov 17 23:54:46 2016 New Revision: 242576 URL: https://gcc.gnu.org/viewcvs?rev=242576=gcc=rev Log: PR middle-end/38219 * gcc.dg/tree-ssa/vrp47.c: Do not run on m68k.

[Bug target/47192] m68k target - gcc uses stack frame after it has been unlinked when compiling with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47192 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/47192] m68k target - gcc uses stack frame after it has been unlinked when compiling with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47192 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Thu Nov 17 23:39:08 2016 New Revision: 242575 URL: https://gcc.gnu.org/viewcvs?rev=242575=gcc=rev Log: PR target/47192 * config/m68k/m68k.c (m68k_expand_epilogue): Emit a

[Bug libfortran/78379] Processor-specific versions for matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #7 from Thomas Koenig --- And one more thing. Comparing the timing you get for the version with the target_clone and a version using just -mavx added to the relevant line in the Makefile, do you see a difference?

[Bug libfortran/78379] Processor-specific versions for matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #6 from Thomas Koenig --- > You may notice I was invoking the wrong executable in what I posted in > comment #3. I did rerun the correct one several times and tried it with > -mavx -mprefer-avx128. I get the same poor results

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #21 from Jerry DeLisle --- (In reply to Steve Kargl from comment #19) > On Thu, Nov 17, 2016 at 12:43:40AM +, kevin.b.beard at nasa dot gov > wrote: > > Many thanks to Jerry DeLisle [jvdeli...@charter.net]; he made us realize

[Bug target/47192] m68k target - gcc uses stack frame after it has been unlinked when compiling with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47192 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug libfortran/78379] Processor-specific versions for matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #5 from Jerry DeLisle --- (In reply to Uroš Bizjak from comment #4) > (In reply to Jerry DeLisle from comment #3) > > I did apply your second patch: > > > > I do not get any improvement and results are diminished from current trunk,

[Bug c++/78193] [7 regression] g++.dg/concepts/inherit-ctor3.C etc. FAIL at r241765

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78193 --- Comment #6 from Jason Merrill --- Author: jason Date: Thu Nov 17 22:40:28 2016 New Revision: 242573 URL: https://gcc.gnu.org/viewcvs?rev=242573=gcc=rev Log: PR c++/78193 - inherited ctor regressions on sparc32. * call.c

[Bug c++/78193] [7 regression] g++.dg/concepts/inherit-ctor3.C etc. FAIL at r241765

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78193 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/68377] [c++17] unary right fold fails to compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68377 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/68377] [c++17] unary right fold fails to compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68377 --- Comment #7 from Jason Merrill --- Author: jason Date: Thu Nov 17 22:27:56 2016 New Revision: 242571 URL: https://gcc.gnu.org/viewcvs?rev=242571=gcc=rev Log: PR c++/68377 - parenthesized expr in fold-expression * parser.c

[Bug c++/78193] [7 regression] g++.dg/concepts/inherit-ctor3.C etc. FAIL at r241765

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78193 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug tree-optimization/20641] Missed optimization on the tree level (malloc attribute)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20641 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug tree-optimization/20641] Missed optimization on the tree level (malloc attribute)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20641 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #2

[Bug c++/55080] -pedantic produces error: floating-point literal cannot appear in a constant-expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55080 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/78369] [7 Regression] default parameter ICEs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78369 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/55080] -pedantic produces error: floating-point literal cannot appear in a constant-expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55080 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Nov 17 21:44:05 2016 New Revision: 242565 URL: https://gcc.gnu.org/viewcvs?rev=242565=gcc=rev Log: /cp 2016-11-17 Paolo Carlini PR

[Bug c++/78124] [7 regression][c++1z] explicit inheriting constructor is ignored

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78124 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/78101] PowerPC 64-bit little endian fusion failure with -O3 -mcpu=power9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78101 --- Comment #2 from Michael Meissner --- Author: meissner Date: Thu Nov 17 21:42:13 2016 New Revision: 242564 URL: https://gcc.gnu.org/viewcvs?rev=242564=gcc=rev Log: [gcc] 2016-11-17 Michael Meissner PR

[Bug c++/78124] [7 regression][c++1z] explicit inheriting constructor is ignored

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78124 --- Comment #3 from Jason Merrill --- Author: jason Date: Thu Nov 17 21:41:09 2016 New Revision: 242563 URL: https://gcc.gnu.org/viewcvs?rev=242563=gcc=rev Log: PR c++/78124 - list-initialization and inherited ctor *

[Bug c++/78369] [7 Regression] default parameter ICEs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78369 --- Comment #4 from Jason Merrill --- Author: jason Date: Thu Nov 17 21:40:48 2016 New Revision: 242562 URL: https://gcc.gnu.org/viewcvs?rev=242562=gcc=rev Log: PR c++/78369 - {} as default argument * call.c

[Bug c++/68377] [c++17] unary right fold fails to compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68377 --- Comment #6 from Jason Merrill --- Author: jason Date: Thu Nov 17 21:40:41 2016 New Revision: 242561 URL: https://gcc.gnu.org/viewcvs?rev=242561=gcc=rev Log: PR c++/68377 - parenthesized expr in fold-expression * parser.c

[Bug middle-end/78412] New: attribute malloc ineffective

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78412 Bug ID: 78412 Summary: attribute malloc ineffective Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end

[Bug c/78408] C loop initial declarations generate wrong code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408 --- Comment #7 from joseph at codesourcery dot com --- I can't reproduce this with recent GCC 6 branch. Possibly a duplicate of bug 72747?

[Bug c/78408] C loop initial declarations generate wrong code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408 --- Comment #6 from Marc Glisse --- I don't think this is related to the loop, a = b = (struct buf) {} loses the assignment to b even if you put it alone on its line.

[Bug c/78408] C loop initial declarations generate wrong code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408 Markus Trippelsdorf changed: What|Removed |Added Summary|Aggressive optimization of |C loop initial declarations

[Bug tree-optimization/77673] [5/6/7 Regression] 4-byte load generated instead of 1-byte load, possibly reading past the end of object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77673 --- Comment #5 from Thomas Preud'homme --- Got a patch, testing it now.

[Bug c/78408] Aggressive optimization of zeroing results in incorrect behavior

- movl$0, %esi - movq%rax, %rdi - callmemset leaq-131056(%rbp), %rax leaq-65536(%rbp), %rcx movl$65520, %edx @@ -86,5 +81,5 @@ .cfi_endproc .LFE0: .size main, .-main - .ident "GCC: (GNU) 7.0.0 201

[Bug c++/78369] [7 Regression] default parameter ICEs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78369 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug middle-end/78411] New: FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411 Bug ID: 78411 Summary: FAIL: gcc.target/i386/pr45685.c scan-assembler-times cmov 6 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal

[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77933 --- Comment #6 from Thomas Preud'homme --- Author: thopre01 Date: Thu Nov 17 20:30:41 2016 New Revision: 242560 URL: https://gcc.gnu.org/viewcvs?rev=242560=gcc=rev Log: Fix PR77933: stack corruption on ARM when using high registers and LR

[Bug c/78408] Aggressive optimization of zeroing results in incorrect behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408 --- Comment #3 from Nathaniel McCallum --- Created attachment 40077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40077=edit output assembly from the test case This assembly was produced with: gcc -S test.c.

[Bug c/78408] Aggressive optimization of zeroing results in incorrect behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408 --- Comment #2 from Nathaniel McCallum --- Created attachment 40076 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40076=edit simple test case Compile with: gcc -o test test.c This is a simple echo server. It *should* echo whatever the

[Bug other/78410] New: gen-fac.c: undefined references

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78410 Bug ID: 78410 Summary: gen-fac.c: undefined references Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other

[Bug libfortran/78379] Processor-specific versions for matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #4 from Uroš Bizjak --- (In reply to Jerry DeLisle from comment #3) > I did apply your second patch: > > I do not get any improvement and results are diminished from current trunk, > so I am missing something. This is same machine I

[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77933 --- Comment #5 from Thomas Preud'homme --- Author: thopre01 Date: Thu Nov 17 20:12:13 2016 New Revision: 242559 URL: https://gcc.gnu.org/viewcvs?rev=242559=gcc=rev Log: Fix PR77933: stack corruption on ARM when using high registers and LR

[Bug libfortran/78379] Processor-specific versions for matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org ---

[Bug c/78408] Aggressive optimization of zeroing results in incorrect behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408 --- Comment #1 from Marc Glisse --- Do you think you could produce a smaller, stand-alone testcase that reproduces the issue? Or at least attach the preprocessed sources to the report?

[Bug tree-optimization/69270] DOM should exploit range information to create more equivalences

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69270 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org See

[Bug ada/48835] porting GNAT to m68k-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug libgcc/78409] New: Segfault in classify_object_over_fdes when throwing and exception

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78409 Bug ID: 78409 Summary: Segfault in classify_object_over_fdes when throwing and exception Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 Jeffrey A. Law changed: What|Removed |Added CC||baker at usgs dot gov --- Comment #4

[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c/78408] New: Aggressive optimization of zeroing results in incorrect behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408 Bug ID: 78408 Summary: Aggressive optimization of zeroing results in incorrect behavior Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal

[Bug target/77600] M68K: gcc generates rubbish with -mshort

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77600 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug target/77599] M68K: __builtin_bswap32() isn't compiled correctly with -mshort

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77599 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78395 --- Comment #6 from Chris --- > Which one do you mean exactly? Shouldn't they all use the user-defined > assignment function? Yes, that's right--they all should. Sorry, I didn't have the code up in front of me when I wrote that so I was a bit

[Bug libfortran/78379] Processor-specific versions for matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #2 from Thomas Koenig --- Here are some measurements with the AVX-enabling patch. They were done on an AVX machine, namely gcc75 from the compile farm. This was done with the command line gfortran -static-libgfortran

[Bug libfortran/78379] Processor-specific versions for matmul

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #1 from Thomas Koenig --- Created attachment 40074 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40074=edit Test program for benchmarks

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78395 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Chris from comment #4) > I tried compiling (my original example) on a different box, this one with > gfortran 6.2.0 obtained from the ubuntu-toolchain-r/test PPA. I got > > [..] > gcc

[Bug lto/78407] New: LTO breaks separate overriding of symbol aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78407 Bug ID: 78407 Summary: LTO breaks separate overriding of symbol aliases Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390 --- Comment #14 from Dominik Vogt --- With the fix I couldn't reproduce the error message in four attempts, but genattrtab still hangs. Maybe this is bad luck, but maybe the error is gone. Running a regression test without bootstrapping on

[Bug middle-end/78406] Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78406 --- Comment #2 from Artem S. Tashkinov --- (In reply to Markus Trippelsdorf from comment #1) > Artem, please don't open a new bug for every phoronix benchmark where gcc > appears to be slower than clang. > > First of all there are existing bug

[Bug middle-end/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78201 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug middle-end/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78201 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Nov 17 17:09:13 2016 New Revision: 242555 URL: https://gcc.gnu.org/viewcvs?rev=242555=gcc=rev Log: PR middle-end/78201 * varasm.c (default_use_anchors_for_symbol_p):

[Bug c/78406] Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78406 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390 --- Comment #13 from Dominik Vogt --- I'm doing this on s390x right now. Just takes some more time.

[Bug c/78406] New: Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78406 Bug ID: 78406 Summary: Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal

[Bug c/78405] New: OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC 6.2 than under Clang 3.9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78405 Bug ID: 78405 Summary: OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity:

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390 --- Comment #12 from Michael Matz --- (In reply to Andreas Schwab from comment #11) > That didn't fix the ia64 bootstrap failure. Would have been too easy I guess :-) Okay, can you try to find a testcase that regressed by not bootstrapping but

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78395 --- Comment #4 from Chris --- I tried compiling (my original example) on a different box, this one with gfortran 6.2.0 obtained from the ubuntu-toolchain-r/test PPA. I got Driving: gfortran-6 -v minimal.f90 -l gfortran -l m -shared-libgcc Using

[Bug c++/78404] New: SciMark v2.0 Sparse Matrix Multiply test is 20% slower under GCC 6.2 than under Clang 3.9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78404 Bug ID: 78404 Summary: SciMark v2.0 Sparse Matrix Multiply test is 20% slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status: UNCONFIRMED

[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 --- Comment #6 from avieira at gcc dot gnu.org --- I had a look at this and after some digging I found the bug is not due to LTO, but rather with "local" functions. If you make bar static you will end up with the same faulty behavior. After some

[Bug c++/78403] New: SciMark v2.0 Jacobi Successive Over-Relaxation test is 30% slower under GCC 6.2 than under Clang 3.9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78403 Bug ID: 78403 Summary: SciMark v2.0 Jacobi Successive Over-Relaxation test is 30% slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status:

[Bug c++/78402] New: SciMark v2.0 Dense LU Matrix Factorization test runs more than 2 times slower under GCC 6.2 than under Clang 3.9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78402 Bug ID: 78402 Summary: SciMark v2.0 Dense LU Matrix Factorization test runs more than 2 times slower under GCC 6.2 than under Clang 3.9 Product: gcc Version:

[Bug c++/78401] New: SciMark v2.0 Composite test runs 1,5 times slower under GCC 6.2 than under Clang 3.9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78401 Bug ID: 78401 Summary: SciMark v2.0 Composite test runs 1,5 times slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status: UNCONFIRMED

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390 --- Comment #11 from Andreas Schwab --- That didn't fix the ia64 bootstrap failure.

[Bug rtl-optimization/78400] New: [7 Regression] ICE: in df_refs_verify, at df-scan.c:4045 when building powerpc crosscompiler

k//binary-trunk-242552-checking-yes-rtl-df-extra-nographite-powerpc Thread model: posix gcc version 7.0.0 20161117 (experimental) (GCC) The compiler was configured with --enable-checking=yes,rtl,df,extra ; maybe df checking is needed to reproduce.

[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment

[Bug c++/78399] g++ generates sub-optimal assembler code when structs aren't explicitly aligned.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78399 --- Comment #2 from Marc Glisse --- Related to PR 50384.

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390 --- Comment #10 from Michael Matz --- (In reply to Dominik Vogt from comment #9) > On Thu, Nov 17, 2016 at 03:03:03PM +, matz at gcc dot gnu.org wrote: > > I'm just bootstrapping s390x with the fix; would you like me to > run a regression

[Bug rtl-optimization/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78355 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug rtl-optimization/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78355 --- Comment #8 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 17 16:16:38 2016 New Revision: 242554 URL: https://gcc.gnu.org/viewcvs?rev=242554=gcc=rev Log: PR rtl-optimization/78355 * doc/tm.texi.in

[Bug c++/78399] g++ generates sub-optimal assembler code when structs aren't explicitly aligned.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78399 --- Comment #1 from Luca Stoppa --- Created attachment 40071 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40071=edit Optimal code

[Bug tree-optimization/46639] [5/6 Regression] Missing optimization due to function splitting and redundant conditionals

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46639 Jeffrey A. Law changed: What|Removed |Added Summary|[5/6/7 Regression] Missing |[5/6 Regression] Missing

[Bug c++/78399] New: g++ generates sub-optimal assembler code when structs aren't explicitly aligned.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78399 Bug ID: 78399 Summary: g++ generates sub-optimal assembler code when structs aren't explicitly aligned. Product: gcc Version: 7.0 Status: UNCONFIRMED Severity:

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390 --- Comment #9 from Dominik Vogt --- On Thu, Nov 17, 2016 at 03:03:03PM +, matz at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390 > > --- Comment #8 from Michael Matz --- > The aarch64 fail is fixed by the

[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78324 --- Comment #2 from David Malcolm --- Author: dmalcolm Date: Thu Nov 17 15:55:26 2016 New Revision: 242552 URL: https://gcc.gnu.org/viewcvs?rev=242552=gcc=rev Log: Fix locations within raw strings Whilst investigating PR preprocessor/78324 I

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 Vincent Lefèvre changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78395 --- Comment #3 from janus at gcc dot gnu.org --- Somewhat reduced test case (without all the abstract stuff): module types_mod implicit none type, public :: t1 integer :: a contains procedure :: get_t2 end type type, public

[Bug target/78386] [PPC] Optimization -O2 and higher cause math inconsistency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/78386] [PPC] Optimization -O2 and higher cause math inconsistency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 --- Comment #10 from David Edelsohn --- -std=gnuXX affects IEEE 754 conformance, but that is not mentioned in the documentation, only in source code comments (c-family/c-cppbuiltin.c)

[Bug fortran/78395] [OOP] ICE for operations with polymorphic variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78395 janus at gcc dot gnu.org changed: What|Removed |Added CC||vehre at gcc dot gnu.org ---

[Bug bootstrap/78390] [7 Regression] Bootstrap failure: match.pd: cannot determine type of operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390 --- Comment #8 from Michael Matz --- The aarch64 fail is fixed by the below patch. It will take a while for me to try this on s390, so if somebody beats me to test this I won't complain. diff --git a/gcc/combine.c b/gcc/combine.c index

  1   2   >