[Bug libstdc++/69191] Wrong equality comparison between error_code and error_condition + segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69191 --- Comment #16 from Chip Salzenberg --- Still happening in 7.2
[Bug c/83559] [8 regression] -Wsuggest-attribute=const conflicts with -Wattributes warning about const attribute on function returning void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83559 Martin Sebor changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg4.html
[Bug tree-optimization/83603] [8 Regression] ICE in builtin_memref at gcc/gimple-ssa-warn-restrict.c:238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83603 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #6 from Martin Sebor --- Minimal patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg5.html
[Bug tree-optimization/83648] New: missing -Wsuggest-attribute=malloc on a trivial malloc-like function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83648
Bug ID: 83648
Summary: missing -Wsuggest-attribute=malloc on a trivial
malloc-like function
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The malloc() function returns a non-null pointer on success and null on
failure. Thus, a function that returns the result of malloc can be consider
"malloc-like." Likewise, a function the either returns the result of malloc or
a null pointer is itself also trivially malloc-like.
The -Wsuggest-attribute=malloc option is supposed to issue warnings for
malloc-like functions that would benefit from being declared with attribute
malloc. The following test case shows that GCC issues the warning for the
first kind of function but not for the second. The second kind is likely to be
defined to avoid the non-portable/underspecified malloc behavior with a zero
argument (malloc can return either a non-derefernceable pointer to a distinct
object or null).
$ cat a.c && gcc -O2 -S -Wall -Wsuggest-attribute=malloc a.c
void* f (unsigned n) // -Wsuggest-attribute=malloc (good)
{
return __builtin_malloc (n);
}
void* g (unsigned n) // missing -Wsuggest-attribute=malloc
{
return n ? __builtin_malloc (n) : 0;
}
a.c: In function ‘f’:
a.c:1:7: warning: function might be candidate for attribute ‘malloc’ if it is
known to return normally [-Wsuggest-attribute=malloc]
void* f (unsigned n) // -Wsuggest-attribute=malloc (good)
^
[Bug tree-optimization/83642] excessive strlen range after a strcat of non-empty string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83642 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization, patch Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-01 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg3.html
[Bug tree-optimization/83640] [8 Regression] ICE in generic_overlap, at gimple-ssa-warn-restrict.c:814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83640 Martin Sebor changed: What|Removed |Added Keywords||patch Summary|ice in generic_overlap, at |[8 Regression] ICE in |gimple-ssa-warn-restrict.c: |generic_overlap, at |814 |gimple-ssa-warn-restrict.c: ||814 --- Comment #6 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg2.html
[Bug java/83647] add x86_64 Windows support to GCJ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83647 --- Comment #2 from Yale Zhang --- (In reply to Andrew Pinski from comment #1) > GCC 6 is in regression only fixes due to it being a release branch. > > Won't fix as Java was removed from GCC 7. There are other open source Java > implementations including but not limited to OpenJDK. I was afraid of that, but I want to compile to native code and AFAIK, GCJ is the only one or if not, the only robust one. I think this change can be useful to others and shouldn't be lost just because GCC 6 is limited to regression fixes only. Is there a non-release branch that this can checked into?
[Bug java/83647] add x86_64 Windows support to GCJ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83647 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- GCC 6 is in regression only fixes due to it being a release branch. Won't fix as Java was removed from GCC 7. There are other open source Java implementations including but not limited to OpenJDK.
[Bug java/83647] New: add x86_64 Windows support to GCJ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83647 Bug ID: 83647 Summary: add x86_64 Windows support to GCJ Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: yzhang1985 at gmail dot com Target Milestone: --- Created attachment 43002 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43002&action=edit The changes to natVMConsole.cc are only for MingW. Probably these changes don't need to be in GCC and can be downstream GCJ currently doesn't support x86_64 Windows, specifically x86_64-w64-mingw32. I have made a patch that supports it. I know GCJ has been removed from GCC 7, but I'm hoping this can still make it into GCC 6. The changes were mostly to change 32bit ints to pointer sized ints. Specifically, unsigned long -> uintptr_t jint -> jlong Changing jint -> jlong is probably not right because that would change 32bit builds. I wanted to change those jint to jsize and change jsize from int to intptr_t, but wasn't sure of the effects. The other big change was I had to replace boehm-gc with a newer version (7.2e, 7.2g crashes). GCC seems to have an out of date, custom version that doesn't support x86_64 windows, and that only builds a static lib. I didn't include that in the patch, but you can simply plant the newer version into the source code.
[Bug libgomp/82428] Builtins for openacc gang/worker/vector id/size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82428 --- Comment #3 from Tom de Vries --- (In reply to Tom de Vries from comment #2) > Created attachment 43000 [details] > Updated tentative patch > > Updated tentative patch, tested with nvptx accelerator. Bootstrap and reg-test on x86_64 also went ok.
[Bug fortran/83646] (PDT) Use statement with PDTs excludes the specific instances.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83646 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-01 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > with > use m, only : pdtt, t, sub > > it compiles just fine. AFAICT it compiles also with use m, only : t,pdtt, sub but not with use m, only : t, sub
[Bug c/83559] [8 regression] -Wsuggest-attribute=const conflicts with -Wattributes warning about const attribute on function returning void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83559 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-01 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- The new -Wattributes warning is the (deliberate) result of r255469. The only meaningful effect a call can have to a function that's declared with the const attribute is return a value. Calls to such functions that ignore the returned value are eliminated (and diagnosed with -Wunused-value). Likewise, calls to const functions that return void are eliminated (though without a warning, which seems like an omission). As a result, it makes little sense to declare a function to be both const and return void, and -Wsuggest-attribute=const should not be issued for const functions.
[Bug rtl-optimization/83645] ICE: in get_insn_template, at final.c:2100 with -gstatement-frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83645
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
The problem is that during the final pass the cfg is not available anymore, so
using
FOR_EACH_BB_FN (bb, cfun)
{
FOR_BB_INSNS_SAFE (bb, insn, next)
in delete_vta_debug_insns is incorrect at that point.
Instead at that point we need to walk insns from get_insns () up to the very
last insn in the chain.
[Bug fortran/83646] New: (PDT) Use statement with PDTs excludes the specific instances.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83646 Bug ID: 83646 Summary: (PDT) Use statement with PDTs excludes the specific instances. Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: pault at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Blocks: 82173 Target Milestone: --- As reported on clf https://groups.google.com/forum/#!topic/comp.lang.fortran/NDE6JKTFbNU [pault@pc30 pdt]$ cat f*2.f90 module m type :: t(ell) integer, len :: ell integer :: i(ell) end type contains subroutine sub( a ) type(t(ell=*)), intent(inout) :: a end end module m ! main program use m, only : t,pdtt, sub type(t(ell=42)) :: foo call sub( foo ) end [pault@pc30 pdt]$ ~/irun/bin/gfortran -static-libgfortran f*2.f90 -fdump-tree-original -g -fopenmp fortranfan2.f90:20:18: call sub( foo ) 1 Error: Type mismatch in argument ‘a’ at (1); passed TYPE(Pdtt) to TYPE(pdtt) with use m, only : pdtt, t, sub it compiles just fine. Paul Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 [Bug 82173] [meta-bug] Parameterized derived type errors
[Bug fortran/83076] [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83076 --- Comment #11 from Paul Thomas --- Author: pault Date: Mon Jan 1 17:36:41 2018 New Revision: 256065 URL: https://gcc.gnu.org/viewcvs?rev=256065&root=gcc&view=rev Log: 2018-01-01 Paul Thomas PR fortran/83076 * resolve.c (resolve_fl_derived0): Add caf_token fields for allocatable and pointer scalars, when -fcoarray selected. * trans-types.c (gfc_copy_dt_decls_ifequal): Copy the token field as well as the backend_decl. (gfc_get_derived_type): Flag GFC_FCOARRAY_LIB for module derived types that are not vtypes. Components with caf_token attribute are pvoid types. For a component requiring it, find the caf_token field and have the component token field point to its backend_decl. PR fortran/83319 *trans-types.c (gfc_get_array_descriptor_base): Add the token field to the descriptor even when codimen not set. 2018-01-01 Paul Thomas PR fortran/83076 * gfortran.dg/coarray_45.f90 : New test. PR fortran/83319 * gfortran.dg/coarray_46.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/coarray_45.f90 trunk/gcc/testsuite/gfortran.dg/coarray_46.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83319] [7/8 Regression] ICE on use of allocatable component in derived type coarray defined in module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83319 --- Comment #3 from Paul Thomas --- Author: pault Date: Mon Jan 1 17:36:41 2018 New Revision: 256065 URL: https://gcc.gnu.org/viewcvs?rev=256065&root=gcc&view=rev Log: 2018-01-01 Paul Thomas PR fortran/83076 * resolve.c (resolve_fl_derived0): Add caf_token fields for allocatable and pointer scalars, when -fcoarray selected. * trans-types.c (gfc_copy_dt_decls_ifequal): Copy the token field as well as the backend_decl. (gfc_get_derived_type): Flag GFC_FCOARRAY_LIB for module derived types that are not vtypes. Components with caf_token attribute are pvoid types. For a component requiring it, find the caf_token field and have the component token field point to its backend_decl. PR fortran/83319 *trans-types.c (gfc_get_array_descriptor_base): Add the token field to the descriptor even when codimen not set. 2018-01-01 Paul Thomas PR fortran/83076 * gfortran.dg/coarray_45.f90 : New test. PR fortran/83319 * gfortran.dg/coarray_46.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/coarray_45.f90 trunk/gcc/testsuite/gfortran.dg/coarray_46.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/83645] New: ICE: in get_insn_template, at final.c:2100 with -gstatement-frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83645 Bug ID: 83645 Summary: ICE: in get_insn_template, at final.c:2100 with -gstatement-frontiers Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: aoliva at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 43001 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43001&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -gstatement-frontiers testcase.c during RTL pass: final testcase.c: In function 'foo': testcase.c:7:1: internal compiler error: in get_insn_template, at final.c:2100 } ^ 0x9a8f96 get_insn_template(int, rtx_def*) /repo/gcc-trunk/gcc/final.c:2100 0x9ac10f final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) /repo/gcc-trunk/gcc/final.c:3029 0x9addb1 final(rtx_insn*, _IO_FILE*, int) /repo/gcc-trunk/gcc/final.c:2065 0x9ae7e1 rest_of_handle_final /repo/gcc-trunk/gcc/final.c:4551 0x9ae7e1 execute /repo/gcc-trunk/gcc/final.c:4625 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-256059-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-256059-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix gcc version 8.0.0 20180101 (experimental) (GCC)
[Bug c/83559] [8 regression] -Wsuggest-attribute=const conflicts with -Wattributes warning about const attribute on function returning void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83559 Eric Gallager changed: What|Removed |Added Known to work||7.2.0 Target Milestone|--- |8.0 Summary|-Wsuggest-attribute=const |[8 regression] |conflicts with -Wattributes |-Wsuggest-attribute=const |warning about const |conflicts with -Wattributes |attribute on function |warning about const |returning void |attribute on function ||returning void Known to fail||8.0
[Bug libgomp/82428] Builtins for openacc gang/worker/vector id/size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82428 Tom de Vries changed: What|Removed |Added Attachment #42991|0 |1 is obsolete|| --- Comment #2 from Tom de Vries --- Created attachment 43000 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43000&action=edit Updated tentative patch Updated tentative patch, tested with nvptx accelerator. todo: Test fortran variant.
[Bug other/82383] Some new toplevel directories are not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82383 --- Comment #2 from Eric Gallager --- libcilkrts can be removed from the list of directories to document, since it no longer exists in trunk.
[Bug fortran/20520] allocatable arrays used uninitialized without a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520 Dominique d'Humieres changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #19 from Dominique d'Humieres --- *** Bug 46182 has been marked as a duplicate of this bug. ***
[Bug libfortran/46182] Run time check for invalid use of unallocated allocatable variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46182 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Dominique d'Humieres --- Another variant of pr20520. *** This bug has been marked as a duplicate of bug 20520 ***
[Bug target/83641] -fstack-clash-protection generates incorrect CFI on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83641 Florian Weimer changed: What|Removed |Added Attachment #42995|0 |1 is obsolete|| --- Comment #1 from Florian Weimer --- Created attachment 42999 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42999&action=edit cfi.c Reduced test case. Compile with -O2 -fstack-clash-protection. f3: .LFB0: .cfi_startproc pushl %esi .cfi_def_cfa_offset 8 .cfi_offset 6, -8 pushl %ebx .cfi_def_cfa_offset 12 .cfi_offset 3, -12 pushl %esi .cfi_def_cfa_offset 16 .cfi_offset 6, -16 popl%esi .cfi_restore 6 .cfi_def_cfa_offset 12 subl$4, %esp .cfi_def_cfa_offset 16 movlx0, %ebx movlx1, %esi It looks related to the probing for noreturn functions. The noreturn attribute can even be removed as long as the infinite loop at the end is present (which I added to suppress the warning).
[Bug fortran/64229] internal compiler error when assigning allocatable arrays of character(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64229 --- Comment #2 from Dominique d'Humieres --- > Dup. > > *** This bug has been marked as a duplicate of bug 54070 *** This is rather a duplicate of pr20520 once the ICE has been fixed in pr54070 (obvious if I replace character(:) with character(10)). Compiling the test with -Wuninitialized gives the warnings /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:2:0: character(:), allocatable :: x(:), y(:) Warning: '.x' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:2:0: Warning: '.y' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: x = y Warning: 'y.offset' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: Warning: 'y.dim[0].lbound' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: Warning: 'y.dim[0].ubound' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: Warning: 'x.offset' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: Warning: 'x.dim[0].lbound' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: Warning: 'x.dim[0].ubound' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: x = y Warning: 'y.dim[0].ubound' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: Warning: 'y.dim[0].lbound' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: Warning: 'y.dim[0].lbound' may be used uninitialized in this function [-Wmaybe-uninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: Warning: 'y.dim[0].ubound' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: Warning: 'y.dim[0].lbound' is used uninitialized in this function [-Wuninitialized] /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/pr64229.f90:3:0: Warning: 'y.dim[0].lbound' may be used uninitialized in this function [-Wmaybe-uninitialized] *** This bug has been marked as a duplicate of bug 20520 ***
[Bug fortran/20520] allocatable arrays used uninitialized without a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520 Dominique d'Humieres changed: What|Removed |Added CC||ondrej.certik at gmail dot com --- Comment #18 from Dominique d'Humieres --- *** Bug 64229 has been marked as a duplicate of this bug. ***
[Bug c++/81917] [6/7/8 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81917 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |6.5 Summary|internal compiler error: in |[6/7/8 Regression] internal |finish_member_declaration, |compiler error: in |at cp/semantics.c:3004 |finish_member_declaration, ||at cp/semantics.c:3004
[Bug rtl-optimization/83608] [7/8 Regression] ICE in convert_move, at expr.c:229 in GIMPLE store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83608 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|unknown |8.0 Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed for 7.3+.
[Bug tree-optimization/83609] [7/8 Regression] ICE in read_complex_part at gcc/expr.c:3202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83609 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed for 7.3+.
[Bug rtl-optimization/83608] [7/8 Regression] ICE in convert_move, at expr.c:229 in GIMPLE store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83608 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Jan 1 11:30:28 2018 New Revision: 256063 URL: https://gcc.gnu.org/viewcvs?rev=256063&root=gcc&view=rev Log: PR middle-end/83608 * expr.c (store_expr_with_bounds): Use simplify_gen_subreg instead of convert_modes if target mode has the right side, but different mode class. * g++.dg/opt/pr83608.C: New test. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/opt/pr83608.C Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/83609] [7/8 Regression] ICE in read_complex_part at gcc/expr.c:3202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83609 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Jan 1 11:28:57 2018 New Revision: 256062 URL: https://gcc.gnu.org/viewcvs?rev=256062&root=gcc&view=rev Log: PR middle-end/83609 * expr.c (expand_assignment): Fix up a typo in simplify_gen_subreg last argument when extracting from CONCAT. If either from_real or from_imag is NULL, use expansion through memory. If result is not a CONCAT and simplify_gen_subreg fails, try to simplify_gen_subreg the parts directly to inner mode, if even that fails, use expansion through memory. * gcc.dg/pr83609.c: New test. * g++.dg/opt/pr83609.C: New test. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/opt/pr83609.C branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr83609.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/83623] [8 Regression] ICE: in convert_move, at expr.c:248 with -march=knl and 16bit vector bswap/rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83623 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Mon Jan 1 11:27:17 2018 New Revision: 256061 URL: https://gcc.gnu.org/viewcvs?rev=256061&root=gcc&view=rev Log: PR middle-end/83623 * expmed.c (expand_shift_1): For 2-byte rotates by BITS_PER_UNIT, check for bswap in mode rather than HImode and use that in expand_unop too. * gcc.dg/pr83623.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr83623.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/expmed.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/83623] [8 Regression] ICE: in convert_move, at expr.c:248 with -march=knl and 16bit vector bswap/rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83623 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c/83595] [8 Regression] ICE: in linemap_macro_map_lookup, at libcpp/line-map.c:1008 on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83595 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE --- >> --- Comment #33 from rguenther at suse dot de --- > [...] >>>* Invalid sh_info: >>> >>>FAIL: g++.dg/lto/pr42987 cp_lto_pr42987_0.o-cp_lto_pr42987_1.o link, >>>-flto >>>-flto-partition=none -g >>>FAIL: g++.dg/lto/pr42987 cp_lto_pr42987_0.o-cp_lto_pr42987_1.o link, >>>-flto -g >>> >>>ld: fatal: file /var/tmp//ccXwdzGddebugobjtem: section >>>[6].rel.gnu.debuglto_.debug_info: has invalid sh_info: 9 >>>ld: fatal: file /var/tmp//ccuVJOVbdebugobjtem: section >>>[6].rel.gnu.debuglto_.debug_info: has invalid sh_info: 8 >>> >>> seen during the ld -r -o ccrIZb_ddebugobj ccSerOuddebugobjtem >>> cc5b3Arcdebugobjtem step: >>> >>>ccSerOuddebugobjtem: .rel.gnu.debuglto_.debug_info: sh_info: 9: does >>>not point >>>to a valid section >>> >>>Section Header[6]: sh_name: .rel.gnu.debuglto_.debug_info >>>sh_addr: 0 sh_flags: 0 >>>sh_size: 0x8 sh_type:[ SHT_REL ] >>>sh_offset:0x11c8 sh_entsize: 0x8 (1 entry) >>>sh_link: 5 sh_info:9 >>>sh_addralign: 0x4 >>> >>> But there's no section 9 any longer. >> >> I fixed that in the posted patch for the hpux issue(s). > > Good: I'll try to merge the two after the christmas holidays. I've used the attached patch, with mixed results: * No changes on SPARC (which wasn't affected by this issue in the first place). * On x86, of the previous 32 ld: fatal: has invalid sh_info errors, 16 are now gone. However, I've many (1284 in g++.log) instances of ld: warning: symbol .symtab[2] has invalid section index; ignored: (file /var/tmp//ccyttLYbdebugobjtem value=9); Those links end with ld: fatal: file /var/tmp//ccyttLYbdebugobjtem: section [6].rel.gnu.debuglto_.debug_info: has invalid sh_info: 9 and ld SEGVing, again in the ld -r step. The warnings are from symtab entries like Symbol Table Section: .symtab index value size type bind oth ver shndx name [0] 00 NOTY LOCL D0 UNDEF [1] 00 FILE LOCL D0 ABS pr42987_0.C [2] 00 NOTY LOCL D0 9 and section 9 doesn't exist, where the input object (cp_lto_pr42987_0.o) has Section Header[9]: sh_name: .gnu.debuglto_.debug_info sh_addr: 0 sh_flags: 0 sh_size: 0x3d4 sh_type:[ SHT_PROGBITS ] sh_offset:0x7fb sh_entsize: 0 sh_link: 0 sh_info:0 sh_addralign: 0x1 Symbol Table Section: .symtab index value size type bind oth ver shndx / name [0] 00 NOTY LOCL D0 UNDEF [1] 00 FILE LOCL D0 ABSpr42987_0.C [2] 00 SECT LOCL D0 .text [3] 00 SECT LOCL D0 .gnu.debuglto_.debug_info Rainer
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #37 from Rainer Orth --- Created attachment 42998 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42998&action=edit Merged patches for PRs pr81968 and 83452
[Bug c++/83644] ICE using type alias from recursive decltype in noexcept or return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83644 --- Comment #1 from Björn Fahller --- Created attachment 42997 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42997&action=edit Preprocessed source
[Bug c++/83644] New: ICE using type alias from recursive decltype in noexcept or return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83644
Bug ID: 83644
Summary: ICE using type alias from recursive decltype in
noexcept or return type
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugbjorn at fahller dot se
Target Milestone: ---
Created attachment 42996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42996&action=edit
Source of failing program
The program (attached, and on https://godbolt.org/g/N6nHKk) ICEs as follows:
bf@rahonavis /tmp> g++ -std=c++17 t.cpp
t.cpp: In instantiation of 'compose(F&&, Fs&& ...)::
[with auto:1 = {int}; F = f()::; Fs =
{f()::}]':
t.cpp:32:72: required from here
t.cpp:20:39: internal compiler error: Segmentation fault
using tail_type = decltype(compose(std::forward(fs)...));
~~~^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
To make it not fail, use the macro instead of the type alias, or comment out
both the trailing return type and the noexcept.
