[Bug fortran/78331] New: Misleading error message from submodule when module has no module procedures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78331 Bug ID: 78331 Summary: Misleading error message from submodule when module has no module procedures. Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- As noted in https://groups.google.com/forum/#!topic/comp.lang.fortran/NFCF9brKksg MODULE MainModule END MODULE MainModule SUBMODULE (MainModule) MySub1 IMPLICIT NONE INTEGER, PARAMETER :: a = 17 END SUBMODULE MySub1 PROGRAM MyProg USE MainModule WRITE(*,*) a END PROGRAM MyProg produces the error message. module.f90:5:24: SUBMODULE (MainModule) MySub1 1 Fatal Error: Can't open module file ‘mainmodule.smod’ for reading at (1): No such file or directory compilation terminated. This comes about because the submodule is expecting to find and .smod file, which is only generated when there are module procedures in the parent module. A bit of logic juggling in module.c should suppress the error. Paul
[Bug fortran/78331] Misleading error message from submodule when module has no module procedures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78331 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-12 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paul Thomas --- I will take it :-)
[Bug fortran/77903] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77903 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #7 from Paul Thomas --- It's mine! Paul
[Bug fortran/78331] Misleading error message from submodule when module has no module procedures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78331 Paul Thomas changed: What|Removed |Added CC||damian at sourceryinstitute dot or ||g --- Comment #2 from Paul Thomas --- Adding Damian in CC. Paul
[Bug tree-optimization/78332] New: [ARM] Negative costs of ivopts groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78332
Bug ID: 78332
Summary: [ARM] Negative costs of ivopts groups
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ka6ash at gmail dot com
CC: amker.cheng at gmail dot com
Target Milestone: ---
For the following code GCC generates six induction variables for each use
arr[{0-1}][{0-2}][k].
I think the problem is negative costs. The negative costs is appeared in the
following part of the function determine_group_iv_cost_address:
sum_cost = cost;
if (!sum_cost.infinite_cost_p () && cand->ainc_use == use)
{
if (can_autoinc)
sum_cost -= cand->cost_step;
/* If we generated the candidate solely for exploiting autoincrement
opportunities, and it turns out it can't be used, set the cost to
infinity to make sure we ignore it. */
else if (cand->pos == IP_AFTER_USE || cand->pos == IP_BEFORE_USE)
sum_cost = infinite_cost;
}
If we have a zero cost and autoinc is possible, we obtain the negative cost.
This situation is a little bit confusing because we also can have candidates
with a zero cost of casting and they are less preferable than candidates with
autoinc. It seems that there is a preference to use autoinc candidates. But the
testcase shows the preference could increase register pressure without any
reason.
I hotfixed it by zeroing negative costs and GCC started to use two iv.
So, are negative costs a part of the cost model and if it is, is it something
wrong with six ivs?
gcc btc.c -O2 -S -march=armv7-a -mcpu=cortex-a9
void foo(int amount, double arr[2][3][amount])
{
int k;
for (k = 1; k < amount; k++)
{
arr[0][0][k] = 1.0;
arr[0][1][k] = 1.0;
arr[0][2][k] = 1.0;
arr[1][0][k] = 1.0;
arr[1][1][k] = 1.0;
arr[1][2][k] = 1.0;
}
}
:
Group 0:
cand costcompl. inv.ex. depends on
0 10 2 1
...
5 0 1
6 -4 0
7 -4 0
...
Group 1:
cand costcompl. inv.ex. depends on
0 10 2 8
...
9 0 1
10-4 0
11-4 0
...
[Bug target/78227] ICE: unrecognizable insn: in extract_insn, at recog.c:2311 with -mavx512bw and vector comare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78227 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug fortran/77501] [F03] ICE in gfc_match_generic, at fortran/decl.c:9429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77501 --- Comment #4 from janus at gcc dot gnu.org --- Author: janus Date: Sat Nov 12 09:25:47 2016 New Revision: 242335 URL: https://gcc.gnu.org/viewcvs?rev=242335&root=gcc&view=rev Log: 2016-11-12 Janus Weil PR fortran/77501 * class.c (gfc_find_typebound_intrinsic_op): Remove an unnecessary assert and nullification. * decl.c (gfc_match_decl_type_spec): Use gfc_get_tbp_symtree, fix indentation. (gfc_match_generic): Remove an unnecessary assert. Use gfc_get_tbp_symtree to avoid ICE. 2016-11-12 Janus Weil PR fortran/77501 * gfortran.dg/typebound_generic_16.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/typebound_generic_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77501] [F03] ICE in gfc_match_generic, at fortran/decl.c:9429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77501 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from janus at gcc dot gnu.org --- Fixed with r242335. Closing.
[Bug libstdc++/64735] std::future broken on armel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735 Matthias Klose changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #10 from Matthias Klose --- > I'm finally having an working armv5te build is this supposed to work for armv4t as well?
[Bug rtl-optimization/78232] [7 Regression] FAIL: gcc.dg/torture/pr48124-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78232 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Segher Boessenkool --- Fixed.
C optimization bug? Os optimized away useless (and expensive) call, O3 didn't. significant runtime difference
(i'm new here, i don't know the norms, if i'm doing it all wrong, sorry) tested on gcc 6.2.0 and 5.4.0, amd64, same results. code: http://paste.debian.net/plain/894930 in here, method1 is significantly slower than the others, and called twice in the loop. i believe that Os (correctly) concluded that the 2nd call to method1 was useless, and optimized it away. O3 (and O2) didn't optimize it away. as a result, Os is much faster than O2/O3. average run times on my system: -O2 and -O3: 1.3 seconds -O3 -ffast-math: 1.7 seconds (no idea why, but a noticeable difference) -Os: 0.7 seconds i guess this is an optimization bug. optimizing away useless calls isn't just a size thing (which Os specialize in), its most definitely a performance thing too (which is, if i remember correctly, O3's specialty)
[Bug c++/67631] brace initialization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631
Paul Dreik changed:
What|Removed |Added
CC||gcc at pauldreik dot se
--- Comment #2 from Paul Dreik ---
This is still present in 6.2 (as packaged by Debian)
#67631.cpp is the code in Howard Hinnants comment 2015-09-18 20:51:59 UTC
paul@debian-stretch:~$ g++ -std=c++14 67631.cpp
67631.cpp: In instantiation of 'void test(const U&) [with T = unsigned int; U =
X]':
67631.cpp:34:24: required from here
67631.cpp:10:7: error: cannot convert 'const X' to 'unsigned int' in
initialization
t = T{uo};
~~^~~
paul@debian-stretch:~$ g++ --version
g++ (Debian 6.2.0-10) 6.2.0 20161027
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug sanitizer/78294] -fsanitize=thread broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294 --- Comment #10 from Markus Trippelsdorf --- It might make sense to add -fuse-ld=bfd to the AM_CXXFLAGS for now. (lld is also broken.)
[Bug target/77957] [6/7 Regression] Undefined .LCTOC0 with -fstack-protector-strong -mminimal-toc -O0 on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77957 --- Comment #5 from Segher Boessenkool --- Author: segher Date: Sat Nov 12 15:13:14 2016 New Revision: 242336 URL: https://gcc.gnu.org/viewcvs?rev=242336&root=gcc&view=rev Log: rs6000: Don't forget to initialize the TOC (PR77957) The code generating traceback tables mistakenly does an early return if !optional_tbtab, which causes it to miss the code generating the TOC section. This only matters if the TOC will be empty since otherwise the section is created elsewhere. This patch fixes it. PR target/77957 * config/rs6000/rs6000.c (rs6000_output_function_epilogue): Don't return early if !optional_tbtab. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/77957] [5/6 Regression] Undefined .LCTOC0 with -fstack-protector-strong -mminimal-toc -O0 on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77957 Segher Boessenkool changed: What|Removed |Added Summary|[6/7 Regression] Undefined |[5/6 Regression] Undefined |.LCTOC0 with|.LCTOC0 with |-fstack-protector-strong|-fstack-protector-strong |-mminimal-toc -O0 on ppc64 |-mminimal-toc -O0 on ppc64 --- Comment #6 from Segher Boessenkool --- Fixed on trunk, 5 and 6 branches pending.
[Bug fortran/45516] [F08] allocatable compontents of recursive type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45516 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #9 from janus at gcc dot gnu.org --- Paul, can we close this PR, or is there anything left to do?
[Bug c++/67631] brace initialization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631 --- Comment #3 from Paul Dreik --- This is still present in trunk, rev 242335 g++-trunk (GCC) 7.0.0 20161112 (experimental)
[Bug fortran/43366] [OOP][F08] Intrinsic assign to polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |7.0
[Bug middle-end/78225] [7 Regression] FAIL: gcc.dg/gomp/pr27573.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78225 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from John David Anglin --- Gone in r242332.
[Bug fortran/60952] [F03] Problem using "end" as a type bound procedure and contained procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60952 janus at gcc dot gnu.org changed: What|Removed |Added Summary|Problem using "end" as a|[F03] Problem using "end" |type bound procedure and|as a type bound procedure |contained procedures|and contained procedures --- Comment #2 from janus at gcc dot gnu.org --- Here is another variant which is rejected with the same error: module m implicit none type A contains procedure, nopass :: e => end end type contains subroutine s1 contains subroutine s2 end end integer function end() end end Here is what I suspect is happening: 1) After parsing the type declaration, we know that there's a symbol called 'end'. 2) During the parsing of the two subroutines, it somehow happens that the symbol 'end' is wrongly identified as a variable. 3) When parsing the function, we get an error due to the conflict of the VARIABLE and PROCEDURE attributes. The first thing we need to find out is how exactly 'end' obtains the attribute VARIABLE.
[Bug fortran/60952] [F03] Problem using "end" as a type bound procedure and contained procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60952 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) > The first thing we need to find out is how exactly 'end' obtains the > attribute VARIABLE. That probably happens in 'match_variable', which is called during the parsing process (along with many other routines, which try all sorts of matching). In fact the only thing that's missing is to flag the symbol 'end' as a PROCEDURE when parsing the type declaration. The following patch does just that and fixes the errors on all three variants of the example code: Index: gcc/fortran/decl.c === --- gcc/fortran/decl.c (Revision 242341) +++ gcc/fortran/decl.c (Arbeitskopie) @@ -9615,6 +9615,8 @@ match_procedure_in_type (void) false)) return MATCH_ERROR; gfc_set_sym_referenced (stree->n.tb->u.specific->n.sym); + gfc_add_flavor(&stree->n.tb->u.specific->n.sym->attr, FL_PROCEDURE, +target, &stree->n.tb->u.specific->n.sym->declared_at); if (gfc_match_eos () == MATCH_YES) return MATCH_YES;
[Bug fortran/60952] [F03] Problem using "end" as a type bound procedure and contained procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60952 --- Comment #4 from janus at gcc dot gnu.org --- The patch in comment #3 regtests cleanly. Will commit as obvious.
[Bug ipa/78333] New: Intrinsics lack no_instrument_function attribute and thus breaks -finstrument-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78333
Bug ID: 78333
Summary: Intrinsics lack no_instrument_function attribute and
thus breaks -finstrument-functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: cube2killfield at gmail dot com
Target Milestone: ---
When using option -finstrument-functions, compiler-provided intrinsics cannot
be used. Intrinsics are not functions, so when the compiler tries to evaluate
the address of them for the caller argument of __cyg_profile_func_{enter,exit}
the symbol cannot be resolved by the linker as the function doesn't actually
exist.
A minimal test case is provided below:
/* gcc -std=c99 -finstrument-functions t.c */
#include
void __cyg_profile_func_enter (void *, void *)
__attribute__((no_instrument_function));
void __cyg_profile_func_exit (void *, void *)
__attribute__((no_instrument_function));
void __cyg_profile_func_enter (void *a, void *b) { }
void __cyg_profile_func_exit (void *a, void *b) { }
int main() {
volatile __m128 x = _mm_set1_ps(1.0f);
}
This code will only compile for hosts that support SSE. Though you can trigger
the same issue with any intrinsic header (AVX, NEON, AltiVec, etc.)
One way to fix it would be to add the no_instrument_function attribute to all
of the intrinsics. I think a more general solution should be applied, i.e
ignore generating the instrumentation when the function is an intrinsic.
I've tested on multiple versions of GCC and the bug appears to exist in both
GCC 4, 5 and 6.
[Bug c++/78334] New: unpacking constexpr char array as template parameters list inside constexpr lambda failed when passed as auto non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78334
Bug ID: 78334
Summary: unpacking constexpr char array as template parameters
list inside constexpr lambda failed when passed as
auto non-type template parameter
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tomilovanatoliy at yandex dot ru
Target Milestone: ---
Created attachment 40031
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40031&action=edit
source file
I tried to unpack constexpr char array to template parameters list using
constexpr lambda (see attached code) and gives internal compiler error
described below.
Technically I can do it, if I use `template< std::size_t size, char const (&
value)[size] >` template parameter pack for variable template. I.e. the problem
triggered namely by `auto const &` template non-type parameter.
Version:
7.0.0 20161112
System type:
x86_64-pc-linux-gnu
Command line:
$ g++ prog.cc -Wall -Wextra -v -I/usr/local/boost-1.62.0/include -std=gnu++1z
-pedantic "-Wall" "-Wextra"
Output of the compiler:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 7.0.0 20161112 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-I' '/usr/local/boost-sml/include' '-I'
'/usr/local/range-v3/include' '-Wpedantic' '-std=gnu++1z' '-I'
'/usr/local/boost-1.62.0/include' '-L/usr/local/boost-1.62.0/lib' '-v' '-Wall'
'-Wextra' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1plus -quiet -v -I
/usr/local/boost-sml/include -I /usr/local/range-v3/include -I
/usr/local/boost-1.62.0/include -imultiarch x86_64-linux-gnu -D_GNU_SOURCE
prog.cc -quiet -dumpbase prog.cc -mtune=generic -march=x86-64 -auxbase prog
-Wpedantic -Wall -Wextra -std=gnu++1z -version -o /tmp/ccZUTC1X.s
GNU C++14 (GCC) version 7.0.0 20161112 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.0 20161112 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1, isl version none
warning: GMP header version 5.1.2 differs from library version 5.0.2.
warning: MPFR header version 3.1.2 differs from library version 3.1.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc-head/lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/boost-sml/include
/usr/local/range-v3/include
/usr/local/boost-1.62.0/include
/usr/local/gcc-head/lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../include/c++/7.0.0
/usr/local/gcc-head/lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../include/c++/7.0.0/x86_64-pc-linux-gnu
/usr/local/gcc-head/lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../include/c++/7.0.0/backward
/usr/local/gcc-head/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include
/usr/local/include
/usr/local/gcc-head/include
/usr/local/gcc-head/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C++14 (GCC) version 7.0.0 20161112 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.0 20161112 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1, isl version none
warning: GMP header version 5.1.2 differs from library version 5.0.2.
warning: MPFR header version 3.1.2 differs from library version 3.1.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ceca72188b7a96c7095801870930d855
prog.cc: In instantiation of 'struct':
prog.cc:51:64: required from 'constexpr const auto constexpr_string'
prog.cc:59:44: required from here
prog.cc:51:80: internal compiler error: Segmentation fault
constexpr auto constexpr_string = iterate< std::size(value) >{}([] (auto... i)
constexpr { return std::integer_sequence< char_type, value[i]... >{}; });
^
0xaf5f3f crash_signal
/home/heads/gcc/gcc-source/gcc/toplev.c:338
0x604f00 te
[Bug lto/56840] a.out aborts instead of catching exception with -flto and -static-libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56840 --- Comment #4 from Jason Merrill --- Author: jason Date: Sun Nov 13 06:51:23 2016 New Revision: 242348 URL: https://gcc.gnu.org/viewcvs?rev=242348&root=gcc&view=rev Log: DR 374 - specialization in outer namespace PR c++/56840 * pt.c (check_specialization_namespace): Allow any enclosing namespace. (check_unqualified_spec_or_inst): New. (check_explicit_specialization): Call it. * parser.c (cp_parser_elaborated_type_specifier) (cp_parser_class_head): Call it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/explicit-inst1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/template/spec17.C trunk/gcc/testsuite/g++.dg/template/spec25.C trunk/gcc/testsuite/g++.dg/template/spec36.C trunk/gcc/testsuite/g++.old-deja/g++.ns/template13.C trunk/gcc/testsuite/g++.old-deja/g++.pt/explicit73.C trunk/gcc/testsuite/g++.old-deja/g++.pt/lookup10.C trunk/libstdc++-v3/testsuite/30_threads/future/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/30_threads/promise/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/ext/numeric_traits/numeric_traits.cc trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/enable_shared_from_this/requirements/explicit_instantiation/1.cc trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/requirements/explicit_instantiation/1.cc trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/requirements/explicit_instantiation/2.cc trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/weak_ptr/requirements/explicit_instantiation/1.cc trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/weak_ptr/requirements/explicit_instantiation/2.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/hash/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered_map/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered_multimap/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered_multiset/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered_set/requirements/explicit_instantiation.cc
[Bug c++/78334] [7 Regression] [C++1z] P0127R2 related ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78334
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-11-13
CC||jason at gcc dot gnu.org,
||trippels at gcc dot gnu.org
Summary|unpacking constexpr char|[7 Regression] [C++1z]
|array as template |P0127R2 related ICE:
|parameters list inside |Segmentation fault
|constexpr lambda failed |
|when passed as auto |
|non-type template parameter |
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
markus@x4 /tmp % cat lam.ii
template auto constexpr_string([](auto) {});
void foo() { constexpr_string<0>(0); };
markus@x4 /tmp % clang++ -c -std=c++1z lam.ii
markus@x4 /tmp % /var/tmp/gcc_test/usr/local/bin/g++ -c -std=c++1z lam.ii
lam.ii: In instantiation of ‘struct’:
lam.ii:1:22: required from ‘auto constexpr_string<0>’
lam.ii:2:14: required from here
lam.ii:1:46: internal compiler error: Segmentation fault
[Bug c++/78334] [7 Regression] [C++1z] P0127R2 related ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78334
--- Comment #2 from Anatoliy Tomilov ---
(In reply to Markus Trippelsdorf from comment #1)
> markus@x4 /tmp % cat lam.ii
> template auto constexpr_string([](auto) {});
> void foo() { constexpr_string<0>(0); };
>
> markus@x4 /tmp % clang++ -c -std=c++1z lam.ii
> markus@x4 /tmp % /var/tmp/gcc_test/usr/local/bin/g++ -c -std=c++1z lam.ii
> lam.ii: In instantiation of ‘struct’:
> lam.ii:1:22: required from ‘auto constexpr_string<0>’
> lam.ii:2:14: required from here
> lam.ii:1:46: internal compiler error: Segmentation fault
Why clang++? I sure this bug tracker is about g++.
[Bug c++/78334] [7 Regression] [C++1z] P0127R2 related ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78334
--- Comment #3 from Markus Trippelsdorf ---
(In reply to Anatoliy Tomilov from comment #2)
> (In reply to Markus Trippelsdorf from comment #1)
> > markus@x4 /tmp % cat lam.ii
> > template auto constexpr_string([](auto) {});
> > void foo() { constexpr_string<0>(0); };
> >
> > markus@x4 /tmp % clang++ -c -std=c++1z lam.ii
> > markus@x4 /tmp % /var/tmp/gcc_test/usr/local/bin/g++ -c -std=c++1z lam.ii
> > lam.ii: In instantiation of ‘struct’:
> > lam.ii:1:22: required from ‘auto constexpr_string<0>’
> > lam.ii:2:14: required from here
> > lam.ii:1:46: internal compiler error: Segmentation fault
>
> Why clang++? I sure this bug tracker is about g++.
It just demonstrates that clang accepts the code.
[Bug c++/78334] [7 Regression] [C++1z] P0127R2 related ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78334 --- Comment #4 from Anatoliy Tomilov --- Now I see it. My mistake.
