[Bug c++/78425] New: Atrtibute warning message location incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78425 Bug ID: 78425 Summary: Atrtibute warning message location incorrect Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/68180] [ICE] at cp/constexpr.c:2768 in initializing __vector in a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68180 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Nov 18 23:51:30 2016 New Revision: 242610 URL: https://gcc.gnu.org/viewcvs?rev=242610=gcc=rev Log: PR c++/68180 * g++.dg/cpp1y/pr68180.C: Add -Wno-psabi as

[Bug middle-end/78419] ICE with target_clone on invalid target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78419 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Nov 18 22:21:31 2016 New Revision: 242608 URL: https://gcc.gnu.org/viewcvs?rev=242608=gcc=rev Log: PR middle-end/78419 * multiple_target.c (get_attr_len): Start with

[Bug other/78424] New: intl reincludes sysroot into searching for ld

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78424 Bug ID: 78424 Summary: intl reincludes sysroot into searching for ld Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/77285] [5/6/7 Regression] extern thread_local linkage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77285 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Nov 18 21:56:50 2016 New Revision: 242607 URL: https://gcc.gnu.org/viewcvs?rev=242607=gcc=rev Log: PR c++/77285 * mangle.c (mangle_tls_init_fn,

[Bug debug/78191] [7 regression] ICE in calc_die_sizes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78191 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Nov 18 21:55:46 2016 New Revision: 242606 URL: https://gcc.gnu.org/viewcvs?rev=242606=gcc=rev Log: * dwarf2out.c (size_of_discr_list): Fix typo in function comment.

[Bug target/25112] [m68k] Suboptimal equality comparisons with small integers

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

[Bug target/25112] [m68k] Suboptimal equality comparisons with small integers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25112 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Fri Nov 18 21:52:32 2016 New Revision: 242605 URL: https://gcc.gnu.org/viewcvs?rev=242605=gcc=rev Log: PR target/25112 * config/m68k/m68k.c (moveq feeding equality

[Bug libstdc++/78420] std::less<T*> is not a total order with -O2 enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 Jason Merrill changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #8 from Jason

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #7 from Tomasz Kamiński --- > No, it's very much allowed to do that. But I'm skeptical that it's allowed > to turn !(a(b,a) being false, when std::less{}(a,b) and

[Bug tree-optimization/77536] Vectorizer not maintaining relationship of relative block frequencies in absence of real profile data

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77536 --- Comment #3 from Pat Haugen --- pr78116 contains a couple testcases that showed degradation on x86 caused by spill inside a vectorized loop due to messed up BB frequencies.

[Bug c++/67631] brace initialization bug

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631 --- Comment #10 from Howard Hinnant --- Thanks much Jason!

[Bug c++/67631] brace initialization bug

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

[Bug c++/67631] brace initialization bug

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631 --- Comment #8 from Jason Merrill --- Author: jason Date: Fri Nov 18 20:27:41 2016 New Revision: 242604 URL: https://gcc.gnu.org/viewcvs?rev=242604=gcc=rev Log: PR c++/67631 - list-init and explicit conversions * semantics.c

[Bug c++/67631] brace initialization bug

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631 --- Comment #7 from Jason Merrill --- Author: jason Date: Fri Nov 18 20:27:26 2016 New Revision: 242603 URL: https://gcc.gnu.org/viewcvs?rev=242603=gcc=rev Log: PR c++/67631 - list-init and explicit conversions * semantics.c

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116 Pat Haugen changed: What|Removed |Added Depends on||77536 --- Comment #8 from Pat Haugen ---

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #6 from Jason Merrill --- (In reply to Tomasz Kamiński from comment #4) > Oh, you mean that compiler is not allowed to turn comparison of p == b into > false at compile time, using 5.10 [expr.eq] p2.1? No, it's very much allowed to

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #5 from Andrew Pinski --- I think this deserves a Defect report to the C++ committee because even though std::less requires total order, < and <= usage are undefined if used with two different arrays.

[Bug libstdc++/78423] [c+11] error: use of deleted function 'std::basic_ostringstream

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78423 --- Comment #2 from Jonathan Wakely --- (In reply to Bharath from comment #0) > Due to project constraints we are not supposed to upgrade our gcc to version > 5 & above.Can you please guide is there any other way we can fix above > errors

[Bug libstdc++/78423] [c+11] error: use of deleted function 'std::basic_ostringstream

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78423 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/54316] [C++11] move constructor for stringstream

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316 Andrew Pinski changed: What|Removed |Added CC||snbraj at sasken dot com --- Comment

[Bug libstdc++/78423] New: [c+11] error: use of deleted function 'std::basic_ostringstream

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78423 Bug ID: 78423 Summary: [c+11] error: use of deleted function 'std::basic_ostringstream Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411 --- Comment #5 from Jakub Jelinek --- Yeah, I've also noticed that in my working-directory gcc build (-O0, reconfigured hundreds of times, ...) the test fails, while in my cleanly bootstrapped one it succeeds, with the same -march=/-mtune=

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411 --- Comment #4 from Martin Sebor --- The test fails for me as well (that's how I noticed it). This is on trunk, with a straightforward build with -mtune=generic and -march=x86-64 passed by the driver. But it only fails on one of my machines

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411 --- Comment #3 from H.J. Lu --- I tried r242601 with -mtune=generic -march=x86-64. There is no cmov at all.

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723 --- Comment #8 from Walter Spector --- Hi Janus, The ifort compiler has no problem with your example in Comment #5. That example should be Standard Fortran 90. The newer F2008 data pointer initialization stuff is largely in §4.5.4.6,

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78392 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) > Related to pr42122? Don't think so.

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78392 --- Comment #5 from Dominique d'Humieres --- > As an alternative to removing the assert, one could possibly prevent SAVEd > variables in the main PROGRAM from being declared as "static" (which might > also cure the performance regressions that

[Bug fortran/54613] [F03] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613 --- Comment #3 from Dominique d'Humieres --- At https://gcc.gnu.org/ml/fortran/2016-11/msg00179.html I wrote pr54613, sixth and eighth tests, Actually the tests were extracted from

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2

[Bug middle-end/68360] GCC bitfield processing code is very inefficient

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org ---

[Bug target/25112] [m68k] Suboptimal equality comparisons with small integers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25112 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #2

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #11 from Jerry DeLisle --- One could consider running a reference matrix multiply of size 32 in a loop and do timing tests to determine whether to use -mprefer-avx128. 0n this machine from comment 8 mavx = 1.276 mavx

[Bug rtl-optimization/78422] FAIL: gcc.c-torture/execute/cbrt.c execution failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78422 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #10 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #9) > Next question - what happens if you add > > -mvzeroupper -mavx > > to the line in the Makefile? Does that make a difference in speed? -mvzeroupper slows all

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #5 from nsz at gcc dot gnu.org --- i plan to backport the fix, but it seems my fix is not correct and broke the ieee_8.fp90 test.

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to Walter Spector from comment #6) > Your test case in Comment #5 is fine - because it is not attempting to > initialize the pointer at compile time. Initializing a pointer at compile >

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9

[Bug fortran/68717] [6/7 Regression] New (bogus?) warnings when compiling some gfortran.dg tests with -flto after r231239

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68717 --- Comment #6 from Dominique d'Humieres --- Is this PR (and pr68649) related to pr33097, pr40976, pr42122, and/or pr44471?

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723 --- Comment #6 from Walter Spector --- Hi Janus, Your test case in Comment #5 is fine - because it is not attempting to initialize the pointer at compile time. Initializing a pointer at compile time is a F2008 feature. I was testing this

[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 #26 from Andreas Schwab --- Note that the patch in comment 8 is already included in r242526.

[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 #25 from Dominik Vogt --- A quick regression test with both patches; s390x with just -m64 and -languages=c has only two failures left: +FAIL: gcc.target/s390/risbg-ll-1.c scan-assembler f43:\\n\\trisbg\\t%r2,%r2,32,128+61,64-12

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #9 from Thomas Koenig --- Next question - what happens if you add -mvzeroupper -mavx to the line in the Makefile? Does that make a difference in speed?

[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 #5 from Bill Schmidt --- Patch submitted here: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01951.html

[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 #24 from Andreas Schwab --- This also fixes bootstrap on ia64.

[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 #23 from Michael Matz --- (In reply to Dominik Vogt from comment #22) > Does this patch replace the one in comment 8 or should they both be used? I checked it in isolation, but the former one does fix a bug as well, so probably use

[Bug middle-end/78416] wrong code for division by (u128)~INT64_MAX at -O0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78416 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #4 from Dominique d'Humieres --- Any plan to back-port the fix? If no, could you please close the PR?

[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 amker at gcc dot gnu.org changed: What|Removed |Added Target||arm-none-eabi

[Bug rtl-optimization/78422] New: FAIL: gcc.c-torture/execute/cbrt.c execution failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78422 Bug ID: 78422 Summary: FAIL: gcc.c-torture/execute/cbrt.c execution failure Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3

[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 #3 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01942.html

[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 #22 from Dominik Vogt --- Does this patch replace the one in comment 8 or should they both be used?

[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 #21 from Dominik Vogt --- (In reply to Michael Matz from comment #16) > Uhh: > > Successfully matched this instruction: > (set (subreg:DI (reg:SI 73) 0) > -(lshiftrt:DI (reg/v:DI 63 [ X ]) > -(const_int 56 [0x38]))) >

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #4 from Tomasz Kamiński --- Oh, you mean that compiler is not allowed to turn comparison of p == b into false at compile time, using 5.10 [expr.eq] p2.1? Some reference from clang: https://llvm.org/bugs/show_bug.cgi?id=13507. Note

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #3 from Tomasz Kamiński --- > I don't see this as prohibiting the transformation. The standard seems to be > saying that they might or might not compare as equal, which presumably > depends on how variables are laid out in memory.

[Bug c++/67631] brace initialization bug

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

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78400 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[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 #20 from Michael Matz --- The below patch fixes at least the gcc.c-torture/execute/20030408-1.c testcase. Checking others as well, perhaps I manage to bootstrap later. But if Dominik is faster... :) diff --git a/gcc/combine.c

[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #23 from Andreas Krebbel --- Author: krebbel Date: Fri Nov 18 14:44:54 2016 New Revision: 242590 URL: https://gcc.gnu.org/viewcvs?rev=242590=gcc=rev Log: Re-apply: Drop excess size used for run time allocated stack variables. The

[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 #19 from Dominik Vogt --- (In reply to Segher Boessenkool from comment #17) > Combine should probably not try to generate this extract, I wonder if it > can exist on any target. So where is it coming from? > > Of course the target

[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 #18 from Michael Matz --- (In reply to Segher Boessenkool from comment #17) > Combine should probably not try to generate this extract, I wonder if it > can exist on any target. So where is it coming from? Easy: (subreg:SI

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

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

[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307 --- Comment #9 from Maxim Ostapenko --- Can we close this?

[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 --- Comment #22 from Andreas Krebbel --- Author: krebbel Date: Fri Nov 18 14:28:49 2016 New Revision: 242589 URL: https://gcc.gnu.org/viewcvs?rev=242589=gcc=rev Log: RS6000: Fix PR 77359: Properly align local variables in functions calling

[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Walter Spector from comment #0) > > type(data_t), pointer :: data > integer, pointer :: idata => data%i Thinking about it some more, I'm actually not sure why this should be

[Bug testsuite/78421] [7 Regression] vect-strided-a-u8-i2-gap.c fails on armeb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78421 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target

[Bug fortran/51652] Allocate with type-spec and source-expr: check whether length type-parameter is the same is lacking

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51652 --- Comment #8 from Dominique d'Humieres --- AFAICT this PR is mostly fixed since gcc-5. However I see a remaining glitch with the following variant of the original test module settings type keyword ! character(60), allocatable :: c(:) !

[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 #17 from Segher Boessenkool --- Combine should probably not try to generate this extract, I wonder if it can exist on any target. So where is it coming from? Of course the target should not "successfully" match it ;-)

[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 Bill Schmidt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |wschmidt 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 #16 from Michael Matz --- Uhh: Successfully matched this instruction: (set (subreg:DI (reg:SI 73) 0) -(lshiftrt:DI (reg/v:DI 63 [ X ]) -(const_int 56 [0x38]))) +(zero_extract:DI (reg/v:DI 63 [ X ]) +

[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 #15 from Michael Matz --- (In reply to Dominik Vogt from comment #14) > 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.

[Bug fortran/78395] [OOP] error on polymorphic assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78395 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug middle-end/78419] ICE with target_clone on invalid target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78419 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug c++/78420] std::less<T*> is not an total order with optimization enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #1 from Tomasz Kamiński --- This is probably effect on changing !lt(a,b) && !lt(b, a) into !(a

[Bug testsuite/78421] New: vect-strided-a-u8-i2-gap.c fails on armeb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78421 Bug ID: 78421 Summary: vect-strided-a-u8-i2-gap.c fails on armeb Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/78420] New: std::less<T*> is not an total order with optimization enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 Bug ID: 78420 Summary: std::less is not an total order with optimization enabled Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78392 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug other/78419] ICE with target_clone on invalid target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78419 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 Iain Sandoe changed: What|Removed |Added Target||*darwin* Status|UNCONFIRMED

[Bug other/78419] ICE with target_clone on invalid target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78419 --- Comment #1 from Thomas Koenig --- Valgrind has some more info: ig25@linux-fd1f:~/Krempel/Target> valgrind /home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1 t2.c ==23596== Memcheck, a memory error detector ==23596== Copyright (C) 2002-2013,

[Bug other/78419] New: ICE with target_clone on invalid target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78419 Bug ID: 78419 Summary: ICE with target_clone on invalid target Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other

[Bug fortran/78398] missing warnings and inconsistencies with -Wuninitialized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78398 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug objc++/78418] [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78418 Iain Sandoe changed: What|Removed |Added Target|x86_64-apple-darwin16 |x86_64-apple-darwin*

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78392 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/78392] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78392 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) > As an alternative to removing the assert, one could possibly prevent SAVEd > variables in the main PROGRAM from being declared as "static" (which might > also

[Bug objc++/78418] [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78418 --- Comment #2 from Dominique d'Humieres --- Created attachment 40082 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40082=edit Reference results for the obj-c++ test suite before r242377 Note that due to pr63651 I am using the 10.9 SDK

[Bug objc++/78418] [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78418 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug objc++/78418] [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78418 --- Comment #1 from Dominique d'Humieres --- Created attachment 40081 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40081=edit Results for the obj-c++ test suite after r242377

[Bug objc++/78418] New: [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78418 Bug ID: 78418 Summary: [7 Regression] Several failures in the obj-c++ test suite after revision r242377 on x86_64-apple-darwin16 Product: gcc Version: 7.0 Status:

[Bug rtl-optimization/78416] New: wrong code for division by (u128)~INT64_MAX at -O0

unk//binary-trunk-242583-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64 Thread model: posix gcc version 7.0.0 20161118 (experimental) (GCC) All tested 64bit targets seem to be affected: aarch64-unknown-linux-gnu powerpc64-unknown-linux-gnu sparc64-unknown-linux-gnu x86_64-pc-linux-gnu x86_64

[Bug target/78417] New: target_clones default for powerpc64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78417 Bug ID: 78417 Summary: target_clones default for powerpc64 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug middle-end/68360] GCC bitfield processing code is very inefficient

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360 Roman Perepelitsa changed: What|Removed |Added CC||roman.perepelitsa at gmail dot com

[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 Rainer Orth changed: What|Removed |Added Target|x86_64-apple-darwin16 |x86_64-apple-darwin1[4-6]

[Bug fortran/78395] [OOP] error on polymorphic assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78395 --- Comment #7 from vehre at gcc dot gnu.org --- (In reply to janus from comment #2) > (In reply to janus from comment #1) > > gfortran 6.2.0 says: > > > >v6 = 3 * v4%get_t2() ! This line is the one which causes ICE > > 1 > > Error:

[Bug libquadmath/78415] New: sqrtq does not round correctly when round mode is upward

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78415 Bug ID: 78415 Summary: sqrtq does not round correctly when round mode is upward Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug libquadmath/78414] libquamath converts (long double) INFINITY to NAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78414 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libgcc/77265] Casting an extended precision long double "inf" to __float128 results in "nan"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77265 Uroš Bizjak changed: What|Removed |Added CC||walter.mascarenhas at gmail dot co

[Bug libquadmath/78414] New: libquamath converts (long double) INFINITY to NAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78414 Bug ID: 78414 Summary: libquamath converts (long double) INFINITY to NAN Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78400 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||segher at gcc dot gnu.org

  1   2   >