[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933 --- Comment #3 from PeteVine --- In gcc 8, -std=f2003 is required to overcome the issue but there's another failure later on: gfortran -c -O2 -std=f2003solverinterface.f90 solverinterface.f90:108:9: real*4 fpar(16) ! hint by Shibo 1 Error: GNU Extension: Nonstandard type declaration REAL*4 at (1) solverinterface.f90:153:7: fpar(1) = RTOL(VarSC) 1 Error: Unclassifiable statement at (1) solverinterface.f90:154:7: fpar(2) = ATOL(VarSC) 1 Error: Unclassifiable statement at (1) solverinterface.f90:156:7: fpar(1) = RTOL(ivar) ! relative tolerance, must be between (0, 1) 1 Error: Unclassifiable statement at (1) solverinterface.f90:157:7: fpar(2) = ATOL(ivar) ! absolute tolerance, must be positive 1 Error: Unclassifiable statement at (1) solverinterface.f90:176:1: NNZ, Alu,Jlu,Ju,Jw ) 1 Are there any gfortran switches that would enable compiling this code base as is?
[Bug fortran/81735] [6/7/8 Regression] double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735 --- Comment #11 from Paul Thomas --- Author: pault Date: Sat Nov 4 09:07:09 2017 New Revision: 254404 URL: https://gcc.gnu.org/viewcvs?rev=254404&root=gcc&view=rev Log: 2017-11-04 Paul Thomas PR fortran/81735 * trans-decl.c (gfc_trans_deferred_vars): Do a better job of a case where 'tmp' was used unititialized and remove TODO. 2017-11-04 Paul Thomas PR fortran/81735 * gfortran.dg/pr81735.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr81735.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/81735] [6/7/8 Regression] double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Paul Thomas --- Fixed on all three branches. Thanks for the report. Paul
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 81735, which changed state. Bug 81735 Summary: [6/7/8 Regression] double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81735 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/57426] Application core dumps at __gnu_cxx::__exchange_and_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57426 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > (In reply to RajaGopal from comment #5) > > > > Do you need any output from the dbx? If yes please let me know. > > Yes please, a fuller backtrace at the very least No response, closing
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- (In reply to Rainer Orth from comment #0) > > Given that I've never had any success getting even the most trivial patches > upstream and have no idea which Darwin versions are supported there, I'm > reporting this here. > > Rainer Apparently 10.6/Darwin 11 isn't supported either; see bug 82829. As I said there, it'd really be nice to have a --disable-libsanitizer configure flag for whenever upstream breaks stuff again
[Bug target/82830] New: short rotate with truncated length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82830
Bug ID: 82830
Summary: short rotate with truncated length
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
#include
unsigned short f(unsigned short x,int n){
return _rotwl(x,n&15);
}
andl$15, %ecx
rolw%cl, %ax
I believe the masking is unnecessary. We have some related things in i386.md,
but only for SWI48.
[Bug bootstrap/82831] New: [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 Bug ID: 82831 Summary: [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Profiled bootstrap is broken: [ 5356s] during RTL pass: *free_cfg [ 5356s] ../../gcc/tree-ssa-strlen.c: In member function 'virtual edge_def* strlen_dom_walker::before_dom_children(basic_block)': [ 5356s] ../../gcc/tree-ssa-strlen.c:2751:1: internal compiler error: in insert_section_boundary_note, at bb-reorder.c:2540 [ 5356s] } [ 5356s] ^ [ 5356s] 0x82c27d4 ??? [ 5356s]../sysdeps/i386/start.S:115
[Bug bootstrap/82832] New: [8 Regression] Broken PGO LTO bootstrap on x86_64 after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82832 Bug ID: 82832 Summary: [8 Regression] Broken PGO LTO bootstrap on x86_64 after r254379 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Target: x86_64-linux-gnu https://gcc.gnu.org/ml/gcc-regression/2017-11/msg00028.html
[Bug fortran/29600] [F03] MINLOC and MAXLOC take an optional KIND argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600 --- Comment #18 from Thomas Koenig --- Author: tkoenig Date: Sat Nov 4 13:20:32 2017 New Revision: 254405 URL: https://gcc.gnu.org/viewcvs?rev=254405&root=gcc&view=rev Log: 2017-11-04 Thomas Koenig PR fortran/29600 * gfortran.h (gfc_check_f): Replace fm3l with fm4l. * intrinsic.h (gfc_resolve_maxloc): Add gfc_expr * to argument list in protoytpe. (gfc_resolve_minloc): Likewise. * check.c (gfc_check_minloc_maxloc): Handle kind argument. * intrinsic.c (add_sym_3_ml): Rename to (add_sym_4_ml): and handle kind argument. (add_function): Replace add_sym_3ml with add_sym_4ml and add extra arguments for maxloc and minloc. (check_specific): Change use of check.f3ml with check.f4ml. * iresolve.c (gfc_resolve_maxloc): Handle kind argument. If the kind is smaller than the smallest library version available, use gfc_default_integer_kind and convert afterwards. (gfc_resolve_minloc): Likewise. 2017-11-04 Thomas Koenig PR fortran/29600 * gfortran.dg/minmaxloc_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/minmaxloc_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/29600] [F03] MINLOC and MAXLOC take an optional KIND argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600 --- Comment #19 from Thomas Koenig --- Fixed on trunk, closing.
[Bug fortran/70072] ICE in gfc_find_array_ref(): No ref found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70072 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- (In reply to Dominique d'Humieres from comment #3) > With gfortran 7.2.0 and trunk (8.0) I get the error > > class(t), parameter :: z(2,3) = t(1) > 1 > Error: CLASS variable 'z' at (1) cannot have the PARAMETER attribute This error is correct, isn't it?
[Bug fortran/69815] Don't always use BLOCKS for front-end optimization variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69815 Bug 69815 depends on bug 82568, which changed state. Bug 82568 Summary: [6/7/8] ICE with do-loop inside BLOCK inside omp https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82568 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/82568] [6/7/8] ICE with do-loop inside BLOCK inside omp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82568 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Thomas Koenig --- OK, so I would say this is fixed. Closing.
[Bug fortran/36854] [meta-bug] fortran front-end optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854 Bug 36854 depends on bug 82568, which changed state. Bug 82568 Summary: [6/7/8] ICE with do-loop inside BLOCK inside omp https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82568 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/70072] ICE in gfc_find_array_ref(): No ref found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70072 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dominique d'Humieres --- > This error is correct, isn't it? It is done on purpose after r241979 (pr68440 comment 5). Closing as FIXED.
[Bug fortran/70330] [5 Regression] ICE with -Wextra -Wno-unused-dummy-argument and unused optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70330 --- Comment #3 from Thomas Koenig --- Author: tkoenig Date: Sat Nov 4 13:54:27 2017 New Revision: 254406 URL: https://gcc.gnu.org/viewcvs?rev=254406&root=gcc&view=rev Log: 2017-11-04 Thomas Koenig PR fortran/70330 * gfortran.dg/pr70330.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr70330.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/70330] [5 Regression] ICE with -Wextra -Wno-unused-dummy-argument and unused optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70330 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Thomas Koenig --- Test case is committed to trunk, gcc 5 is no longer supported. Closing.
[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to PeteVine from comment #3) > In gcc 8, -std=f2003 is required to overcome the issue but there's another > failure later on: > -std=f95 works fine with the attached source code. In fact, I find % grep -i real a.f90 real node(3) REAL*4 is no where present in this code.
[Bug fortran/82796] [6/7/8 Regression] Private+equivalence in used module breaks compilation of pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82796 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Nov 4 16:41:09 2017 New Revision: 254409 URL: https://gcc.gnu.org/viewcvs?rev=254409&root=gcc&view=rev Log: 2017-11-04 Steven G. Kargl PR fortran/82796 * resolve.c (resolve_equivalence): An entity in a common block within a module cannot appear in an equivalence statement if the entity is with a pure procedure. 2017-11-04 Steven G. Kargl PR fortran/82796 * gfortran.dg/equiv_pure.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/equiv_pure.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/82796] [6/7/8 Regression] Private+equivalence in used module breaks compilation of pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82796 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Nov 4 17:16:39 2017 New Revision: 254410 URL: https://gcc.gnu.org/viewcvs?rev=254410&root=gcc&view=rev Log: 2017-11-01 Steven G. Kargl PR fortran/82796 * resolve.c (resolve_equivalence): An entity in a common block within a module cannot appear in an equivalence statement if the entity is with a pure procedure. 2017-11-01 Steven G. Kargl PR fortran/82796 * gfortran.dg/equiv_pure.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/equiv_pure.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/resolve.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug fortran/82796] [6/7/8 Regression] Private+equivalence in used module breaks compilation of pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82796 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- Fixed on trunk, branch-7, and branch-6. Closing.
[Bug fortran/69739] [6/7/8 Regression] ICE during array result, allocatable assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69739 --- Comment #7 from Paul Thomas --- (In reply to Harald Anlauf from comment #5) > You probably hit something that's just not yet implemented: > > trans-expr.c: > > (gdb) list 4083,4096 > 4083case GFC_ISYM_LBOUND: > 4084case GFC_ISYM_UBOUND: > 4085/* TODO These implementations of lbound and ubound do not > limit if > 4086 the size < 0, according to F95's 13.14.53 and 13.14.113. > */ > 4087 > 4088 if (!sym->as || sym->as->rank == 0) > 4089return false; > 4090 > 4091 if (arg2 && arg2->expr_type == EXPR_CONSTANT) > 4092d = mpz_get_si (arg2->value.integer) - 1; > 4093 else > 4094/* TODO: If the need arises, this could produce an array of > 4095 ubound/lbounds. */ > 4096gcc_unreachable (); Harald, You are quite right. Declaring 'operate' as real :: operate(1:PRODUCT([UBOUND(A,1),UBOUND(A,2),UBOUND(A,3)])) works as expected. There has to be some way to simplify this, since it happens correctly in specification expressions. On to it Cheers Paul
[Bug other/82784] Remove semicolon after "do {} while (0)" macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #5 from Andi Kleen --- Sounds like a good candidate for a new warning
[Bug c++/82833] New: [concepts] Out-of-line definition of nested class template errors with constraint (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82833
Bug ID: 82833
Summary: [concepts] Out-of-line definition of nested class
template errors with constraint (ICE)
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kjcamann.lists at gmail dot com
Target Milestone: ---
The behavior is different between gcc 7.1 and my latest gcc 8 build. gcc 7
produces an error message, whereas in gcc 8 (built from a1920064e2, around
11/3/2017) it is an ICE.
Here is the code:
```
#include
// Check that std::invoke(, )
// yields an `M` type
template
concept bool CallYieldsType = requires(T t) {
{ std::invoke(A, t) } -> M;
};
template
struct S {
struct Z;
// Declared here, but defined out of line. If defined here, this works.
template
requires CallYieldsType
struct N;
};
template
template
requires CallYieldsType::Z>
struct S::N {
Z &f(T t) {
return std::invoke(A, t);
}
};
```
This error is related to the combination of concept checking and out-of-line
definition, because if I remove either one (by removing the requires clause,
*or* by defining S::N inline) it works fine.
gcc 7.1 says:
test3.cpp:29:16: error: ‘S::N’ does not match any declaration
struct S::N {
gcc 8 says:
test3.cpp:29:16: error: ‘S::N’ does not match any declaration
struct S::N {
^
test3.cpp:29:16: internal compiler error: tree check: expected class ‘type’,
have ‘exceptional’ (error_mark) in cp_parser_class_specifier_1, at
cp/parser.c:22492
0x6868c8 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../.././gcc/tree.c:9146
0x85085c tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../.././gcc/tree.h:3211
0x85085c cp_parser_class_specifier_1
../.././gcc/cp/parser.c:22492
0x850ae1 cp_parser_class_specifier
../.././gcc/cp/parser.c:22754
0x850ae1 cp_parser_type_specifier
../.././gcc/cp/parser.c:16818
0x85fc31 cp_parser_decl_specifier_seq
../.././gcc/cp/parser.c:13684
0x864d25 cp_parser_single_declaration
../.././gcc/cp/parser.c:27131
0x8650bc cp_parser_template_declaration_after_parameters
../.././gcc/cp/parser.c:26823
0x865b4c cp_parser_explicit_template_declaration
../.././gcc/cp/parser.c:27060
0x865b4c cp_parser_template_declaration_after_export
../.././gcc/cp/parser.c:27079
0x865075 cp_parser_template_declaration_after_parameters
../.././gcc/cp/parser.c:26812
0x865b4c cp_parser_explicit_template_declaration
../.././gcc/cp/parser.c:27060
0x865b4c cp_parser_template_declaration_after_export
../.././gcc/cp/parser.c:27079
0x86bd79 cp_parser_declaration
../.././gcc/cp/parser.c:12788
0x86c0b1 cp_parser_declaration_seq_opt
../.././gcc/cp/parser.c:12715
0x86c3bf cp_parser_translation_unit
../.././gcc/cp/parser.c:4502
0x86c3bf c_parse_file()
../.././gcc/cp/parser.c:39021
0x9adff6 c_common_parse_file()
../.././gcc/c-family/c-opts.c:1124
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug driver/82834] New: Cross-compiler doesn't find correct multilib for target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82834 Bug ID: 82834 Summary: Cross-compiler doesn't find correct multilib for target Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- I have r254339, and built a cross-compiler on macOS 10.11.6 (darwin 15.6.0), newlib 2.5.0: $ arm-eabi-gcc -v Using built-in specs. COLLECT_GCC=arm-eabi-gcc COLLECT_LTO_WRAPPER=/opt/gcc-8.0.0/bin/../libexec/gcc/arm-eabi/8.0.0/lto-wrapper Target: arm-eabi Configured with: /Volumes/Miscellaneous/tmp/gcc/configure --build=x86_64-apple-darwin15 --disable-libada --disable-libcc1 --disable-libcilkrts --disable-libmudflap --disable-libsanitizer --disable-libssp --disable-nls --disable-shared --disable-lto --enable-languages=c,ada --enable-multilib --prefix=/Volumes/Miscellaneous/arm/gcc-8.0.0 --target=arm-eabi --with-bugurl=URL:mailto:si...@pushface.org --with-gnu-as --with-gnu-ld --with-newlib --with-stage1-ldflags='-static-libstdc++ -static-libgcc -Wl,-headerpad_max_install_names' --with-system-zlib --without-libiconv-prefix --with-arch=armv7 Thread model: single gcc version 8.0.0 20171102 (experimental) (GCC) This was on macOS 10.11.6 (Darwin 15.6.0) I compile my code with -mlittle-endian -mfloat-abi=hard -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb and it looks as though the compiler has added -march=armv7e-m+fp When I link (same options), the link fails because /opt/gcc-8.0.0/bin/../lib/gcc/arm-eabi/8.0.0/../../../../arm-eabi/bin/ld: error: /Users/simon/cortex-gnat-rts/test-stm32f4//testbed uses VFP register arguments, /opt/gcc-8.0.0/bin/../lib/gcc/arm-eabi/8.0.0/../../../../arm-eabi/lib/libm.a(lib_a-acosl.o) does not /opt/gcc-8.0.0/bin/../lib/gcc/arm-eabi/8.0.0/../../../../arm-eabi/bin/ld: failed to merge target specific data of file /opt/gcc-8.0.0/bin/../lib/gcc/arm-eabi/8.0.0/../../../../arm-eabi/lib/libm.a(lib_a-acosl.o) etc etc. I find that I get a successful link by adding -L/opt/gcc-8.0.0/arm-eabi/lib/thumb/autofp/v7/fpu -L/opt/gcc-8.0.0/lib/gcc/arm-eabi/8.0.0/thumb/autofp/v7/fpu
[Bug libgcc/82635] std::thread's join broken on FreeBSD with all GCCs >= 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 --- Comment #15 from Andreas Tobler --- Author: andreast Date: Sat Nov 4 19:40:23 2017 New Revision: 254411 URL: https://gcc.gnu.org/viewcvs?rev=254411&root=gcc&view=rev Log: 2017-11-04 Andreas Tobler PR libgcc/82635 * config/i386/freebsd-unwind.h (MD_FALLBACK_FRAME_STATE_FOR): Use a sysctl to determine whether we're in a trampoline. Keep the pattern matching method for systems without KERN_PROC_SIGTRAMP sysctl. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/i386/freebsd-unwind.h
[Bug c++/82835] New: [8 Regression] ICE on valid code with -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82835
Bug ID: 82835
Summary: [8 Regression] ICE on valid code with -fopenmp
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jason at gcc dot gnu.org
Target Milestone: ---
Starting from r251422, we ICE on:
$ cat ice7.ii
int a, b;
template class c {
public:
c(int = a);
};
class d {
void e();
struct {
int g;
} chtrellis;
};
void d::e() {
c f;
#pragma omp for private(f)
for (b = 0; b < chtrellis.g; b++)
;
}
$ g++ ice7.ii -fopenmp -c
during GIMPLE pass: omplower
ice7.ii: In member function ‘void d::e()’:
ice7.ii:14:9: internal compiler error: Segmentation fault
#pragma omp for private(f)
^~~
0xd9d4ff crash_signal
../../gcc/toplev.c:324
0x7b3cc5 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3201
0x7b3cc5 tsubst_default_argument(tree_node*, int, tree_node*, tree_node*, int)
../../gcc/cp/pt.c:12043
0x5fe61e convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:7320
0x666237 cxx_omp_clause_apply_fn
../../gcc/cp/cp-gimplify.c:1792
0xc9684c lower_rec_input_clauses
../../gcc/omp-low.c:4185
0xc9edd9 lower_omp_for
../../gcc/omp-low.c:6918
0xc8e1ae lower_omp_1
../../gcc/omp-low.c:8834
0xc8e1ae lower_omp
../../gcc/omp-low.c:8971
0xc8d165 lower_omp_1
../../gcc/omp-low.c:8811
0xc8d165 lower_omp
../../gcc/omp-low.c:8971
0xc8d34d lower_omp_1
../../gcc/omp-low.c:8819
0xc8d34d lower_omp
../../gcc/omp-low.c:8971
0xc9536a execute_lower_omp
../../gcc/omp-low.c:9013
0xc9536a execute
../../gcc/omp-low.c:9050
[Bug c++/82836] New: [8 Regression] ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82836 Bug ID: 82836 Summary: [8 Regression] ICE on valid code Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: nathan at gcc dot gnu.org Target Milestone: --- Created attachment 42545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42545&action=edit test-case Attached test-case ICEs from r253647: $ g++ ice4.ii ice4.ii:447:26: warning: inline variables are only available with -std=c++17 or -std=gnu++17 inline error_condition make_error_condition_wrap_class_string; ^~ cc1plus: internal compiler error: Segmentation fault 0xd9d4ff crash_signal ../../gcc/toplev.c:324 0x6ce0b5 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3087 0x6ce0b5 mangled_decl_hash::hash(tree_node*) ../../gcc/cp/decl2.c:115 0x6ce0b5 hash_table::expand() ../../gcc/hash-table.h:755 0x6ce421 hash_table::find_slot_with_hash(tree_node* const&, unsigned int, insert_option) ../../gcc/hash-table.h:879 0x6cdb99 record_mangling(tree_node*, bool) ../../gcc/cp/decl2.c:4405 0x711941 mangle_decl(tree_node*) ../../gcc/cp/mangle.c:3814 0x1068112 decl_assembler_name(tree_node*) ../../gcc/tree.c:673 0x96e5bb symbol_table::insert_to_assembler_name_hash(symtab_node*, bool) ../../gcc/symtab.c:173 0x970acc symbol_table::symtab_initialize_asm_name_hash() ../../gcc/symtab.c:265 0x98883d analyze_functions ../../gcc/cgraphunit.c:1294 0x988f52 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2690
[Bug debug/82837] New: [8 Regression] ICE in output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82837
Bug ID: 82837
Summary: [8 Regression] ICE in output_operand: invalid
expression as operand
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Host: i686-linux-gnu
Target: i686-linux-gnu
Following test-case ICEs, unfortunately can't be reproduced on
x86_64-linux-gnu:
$ cat /tmp/ice.i
static char b[100];
static int *c;
char *e;
void a(char *f, char *i) {
int d = __builtin_object_size(f, 1);
__builtin___strcpy_chk(f, i, d);
}
void g(void) {
int h;
switch (*c) {
case 8:
e = "swapgs";
break;
case 9:
e = "rdtscp";
break;
default:
return;
}
h = __builtin_strlen(b);
a(b + h - 6, e);
c++;
}
$ ./xgcc -B. /tmp/ice.i -O2 -g -fPIE
/tmp/ice.i:23:1: internal compiler error: output_operand: invalid expression as
operand
}
^
0x86bb32f output_operand_lossage(char const*, ...)
../../gcc/final.c:3442
0x86bc7cb output_addr_const(_IO_FILE*, rtx_def*)
../../gcc/final.c:4031
0x86bc426 output_addr_const(_IO_FILE*, rtx_def*)
../../gcc/final.c:3940
0x85f09a9 dw2_assemble_integer(int, rtx_def*)
../../gcc/dwarf2asm.c:56
0x85f0f86 dw2_asm_output_addr_rtx(int, rtx_def*, char const*, ...)
../../gcc/dwarf2asm.c:305
0x85ff836 output_loc_operands
../../gcc/dwarf2out.c:2197
0x85fff74 output_loc_sequence(dw_loc_descr_node*, int)
../../gcc/dwarf2out.c:2419
0x860ac7e output_loc_list
../../gcc/dwarf2out.c:9851
0x86084cf output_location_lists
../../gcc/dwarf2out.c:8451
0x8608500 output_location_lists
../../gcc/dwarf2out.c:8453
0x8608500 output_location_lists
../../gcc/dwarf2out.c:8453
0x8608500 output_location_lists
../../gcc/dwarf2out.c:8453
0x863a82b dwarf2out_finish
../../gcc/dwarf2out.c:30118
[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933 --- Comment #5 from PeteVine --- You're right, sorry for the confusion. It seems I skimmed over the wall of errors too quickly while the last one came from a different source file. According to my own results in bug #77730, I was somehow able to build the benchmark with earlier versions of gcc 6/7 using the -std=f95 flag. Could you try the following steps? wget http://www.phoronix-test-suite.com/benchmark-files/dolfyn-cfd_0.527.tgz tar xvf dolfyn-cfd_0.527.tgz cd dolfyn-cfd_0.527/src/ sed -i 's/F90FLAGS = -O2/F90FLAGS = -O2 -std=f95/' Makefile make
[Bug tree-optimization/82838] New: [8 Regression] ICE in verify_ssa failed w/ store-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82838
Bug ID: 82838
Summary: [8 Regression] ICE in verify_ssa failed w/
store-merging
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
New ICE starting from r254391:
$ cat /tmp/tmpn_t2ld0o.i
typedef struct
{
unsigned short a;
unsigned short b;
unsigned short c;
} d;
int e;
d f[10];
void g ()
{
d *a;
f[e].b = a[e].a;
f[e].c = a[e].b;
}
$ ./xgcc -B. -fno-ivopts -Os /tmp/tmpn_t2ld0o.i -c
/tmp/tmpn_t2ld0o.i: In function ‘g’:
/tmp/tmpn_t2ld0o.i:10:6: error: missing definition
void g ()
^
for SSA_NAME: _13 in statement:
# .MEM_10 = VDEF <.MEM_7(D)>
MEM[(short unsigned int *)_13 + 2B] = _14;
during GIMPLE pass: store-merging
/tmp/tmpn_t2ld0o.i:10:6: internal compiler error: verify_ssa failed
0x122dbf5 verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1188
0xe3b20b execute_function_todo
../../gcc/passes.c:2001
0xe3a19c do_per_function
../../gcc/passes.c:1659
0xe3b3b4 execute_todo
../../gcc/passes.c:2048
[Bug tree-optimization/82838] [8 Regression] ICE in verify_ssa failed w/ store-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82838 Martin Liška changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/82838] [8 Regression] ICE in verify_ssa failed w/ store-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82838 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-11-04 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 42546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42546&action=edit gcc8-pr82838.patch Untested fix.
[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933 --- Comment #6 from Steve Kargl --- On Sat, Nov 04, 2017 at 09:18:22PM +, tulipawn at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933 > > --- Comment #5 from PeteVine --- > You're right, sorry for the confusion. It seems I skimmed over the wall of > errors too quickly while the last one came from a different source file. > > According to my own results in bug #77730, I was somehow able to build the > benchmark with earlier versions of gcc 6/7 using the -std=f95 flag. Could you > try the following steps? > > wget http://www.phoronix-test-suite.com/benchmark-files/dolfyn-cfd_0.527.tgz > tar xvf dolfyn-cfd_0.527.tgz > cd dolfyn-cfd_0.527/src/ > sed -i 's/F90FLAGS = -O2/F90FLAGS = -O2 -std=f95/' Makefile > make > Please, just fix the code. If you're using sed to "fix" the Makefile, then use sed to fix the source.
[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002 --- Comment #11 from dansan at gcc dot gnu.org --- Author: dansan Date: Sat Nov 4 22:38:43 2017 New Revision: 254412 URL: https://gcc.gnu.org/viewcvs?rev=254412&root=gcc&view=rev Log: PR target/82002 Part 2: Correct non-immediate offset/invalid INSN When we are realigning the stack pointer, making an ms_abi to sysv_abi call and allocating 2GiB or more on the stack we end up with an invalid INSN due to a non-immediate offset. This occurs both with and without -mcall-ms2sysv-xlogues. Additionally, the stack allocation with -mcall-ms2sysv-xlogues is ignoring (silently disabling) stack checking, stack clash checking and probing. This patch fixes these problems by: 1. No longer allocate stack space in ix86_emit_outlined_ms2sysv_save. 2. Rearrange where we emit SSE saves or stub call: a. Before frame allocation when offset from frame to save area is >= 2GiB. b. After frame allocation when frame is < 2GiB. (Stack allocations prior to the stub call can't be combined with those afterwards, so this is better when possible.) 3. Modify choose_baseaddr to take an optional scratch_regno argument and never return rtx that cannot be used as an immediate. gcc: config/i386/i386.c (choose_basereg): Use optional scratch register and add assertion. (x86_emit_outlined_ms2sysv_save): Use scratch register when needed, and don't allocate stack. (ix86_expand_prologue): Rearrange where SSE saves/stub call is emitted, correct wrong allocation with -mcall-ms2sysv-xlogues. (ix86_emit_outlined_ms2sysv_restore): Fix non-immediate offsets. gcc/testsuite: gcc.target/i386/pr82002-2a.c: Change from xfail to fail. gcc.target/i386/pr82002-2b.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr82002-2a.c trunk/gcc/testsuite/gcc.target/i386/pr82002-2b.c
[Bug middle-end/82839] New: missing -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839
Bug ID: 82839
Summary: missing -Wmaybe-uninitialized warning
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I stumbled across a bug in the linux kernel and was surprised that gcc had not
warned about it. I manually created a reduced version:
extern void h(int *t);
extern int g(void);
void f(int *t, int b)
{
int ts;
g();
*t = ts;
switch (b) {
case 0:
h(&ts);
};
}
gcc -Wall -O2 test.c -c
No gcc version I tried (gcc-3.4 through 8.0) warned about it in any
optimization level I tried. I also tried with clang, which did warn about it
correctly. I realize that there are many other open bugs about missing
-Wuninitialized warning and many duplicates, but I could not find any that are
like this one on a non-exhaustive search.
[Bug middle-end/82839] missing -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839 --- Comment #1 from Marc Glisse --- You can simplify the function to int ts; g(); *t = ts; h(&ts); Part of the analysis is not flow-sensitive: we see that ts escapes, we deduce that g() can write to it, so ts might be initialized and we do not warn. We miss the fact that the escape cannot happen before the call to g.
[Bug c++/82840] New: call to conversion operator instead of converting constructor in c++17 during overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82840
Bug ID: 82840
Summary: call to conversion operator instead of converting
constructor in c++17 during overload resolution
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno.bugs.contact at gmail dot com
Target Milestone: ---
This code compiled by gcc trunk with std=c++17 returns 1
instead of the expected 0 since D::operator C() is called instead of the
apparently better match C::C(const D&). Compiling the code with std=c++14
make this behaviour disappear and 0 is returned as expected.
gcc 7.2 also has this behaviour but 6.4 do not.
clang trunk also has this behaviour.
Rationale for why 0 should be returned instead of 1 :
(copied from the original post on stackoverflow)
Tentative reading of the standard (latest draft N4687) :
C c(d) is a direct-initialization which is not a copy elision
([dcl.init]/17.6.1). [dcl.init]/17.6.2 tells us that applicable constructors
are enumerated and that the best one is chosen by overload resolution.
[over.match.ctor] tells us that the applicable constructors are in this case
all the constructors.
In this case : C(), C(const C&) and C(const D&) (no move ctor). C() is clearly
not viable and thus is discarded from the overload set. ([over.match.viable])
Constructors have no implicit object parameter and so C(const C&) and C(const
D&) both take exactly one parameter. ([over.match.funcs]/2)
We now go to [over.match.best]. Here we find that we need to determine which of
these two implicit conversion sequences (ICS) is better. The ICS of C(const D&)
only involves a standard conversion sequence, but the ICS of C(const C&)
involves a user-defined conversion sequence.
Therefore C(const D&) should be selected instead of C(const C&).
See the discussion on stackoverflow:
https://stackoverflow.com/questions/47110853/call-to-conversion-operator-instead-of-converting-constructor-in-c17-during-ov
static int ret;
struct D;
struct C {
C() {}
C(const C&) {}
C(const D&) {}
};
struct D {
operator C() { ret = 1; return C();}
};
int main(){
D d;
C c(d);
return ret;
}
g++ -v :
Using built-in specs.
COLLECT_GCC=/home/bruno/software/gcc-svn-install/bin/g++
COLLECT_LTO_WRAPPER=/home/bruno/software/gcc-svn-install/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-svn/configure
--prefix=/home/bruno/software/gcc-svn-install
Thread model: posix
gcc version 8.0.0 20171104 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-O0' '-g' '-std=c++17' '-Wall' '-Wextra' '-Wpedantic'
'-o' 'bug_DoperatorC_CconstDref_minimal' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/home/bruno/software/gcc-svn-install/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE
bug_DoperatorC_CconstDref_minimal.cpp -quiet -dumpbase
bug_DoperatorC_CconstDref_minimal.cpp -mtune=generic -march=x86-64 -auxbase
bug_DoperatorC_CconstDref_minimal -g -O0 -Wall -Wextra -Wpedantic -std=c++17
-version -o /tmp/cc2hfg03.s
GNU C++17 (GCC) version 8.0.0 20171104 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.0.0 20171104 (experimental), GMP version
6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/bruno/software/gcc-svn-install/lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/bruno/software/gcc-svn-install/lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0
/home/bruno/software/gcc-svn-install/lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/x86_64-pc-linux-gnu
/home/bruno/software/gcc-svn-install/lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/backward
/home/bruno/software/gcc-svn-install/lib/gcc/x86_64-pc-linux-gnu/8.0.0/include
/usr/local/include
/home/bruno/software/gcc-svn-install/include
/home/bruno/software/gcc-svn-install/lib/gcc/x86_64-pc-linux-gnu/8.0.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C++17 (GCC) version 8.0.0 20171104 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.0.0 20171104 (experimental), GMP version
6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: a6d84215658bcb7c80db361
