[Bug tree-optimization/71179] [7 Regression] ice fold_convert_loc, at fold-const.c:2360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71179 --- Comment #4 from kugan at gcc dot gnu.org --- Author: kugan Date: Sat May 21 07:09:16 2016 New Revision: 236554 URL: https://gcc.gnu.org/viewcvs?rev=236554&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2016-05-21 Kugan Vivekanandarajah PR middle-end/71179 * gcc.dg/tree-ssa/pr71179.c: New test. gcc/ChangeLog: 2016-05-21 Kugan Vivekanandarajah PR middle-end/71179 * tree-ssa-reassoc.c (transform_add_to_multiply): Disallow float VECTOR type. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71179.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67973 --- Comment #21 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat May 21 08:35:25 2016 New Revision: 236556 URL: https://gcc.gnu.org/viewcvs?rev=236556&root=gcc&view=rev Log: @@ -1,3 +1,22 @@ 2016-05-21 Iain Sandoe Dominique d'Humieres Backport from mainline 2015-12-17 Rainer Orth gcc: PR target/67973 * configure.ac (gcc_cv_as_stabs_directive): New test. * configure: Regenerate. * config.in: Regenerate. * config/darwin.h (DBX_DEBUGGING_INFO): Wrap in HAVE_AS_STABS_DIRECTIVE. (PREFERRED_DEBUGGING_TYPE): Likewise. * config/i386/darwin.h (PREFERRED_DEBUGGING_TYPE): Only include DBX_DEBUG if HAVE_AS_STABS_DIRECTIVE. * doc/sourcebuild.texi (Effective-Target Keywords, Environment attributes): Document stabs. gcc/testsuite: PR target/67973 * lib/target-supports.exp (check_effective_target_stabs): New proc. * g++.dg/cpp0x/alias-decl-debug-0.C: Restrict to stabs targets. * g++.dg/other/PR23205.C: Likewise. * g++.dg/other/pr23205-2.C: Likewise. * gcc.dg/20040813-1.c: Likewise. * gcc.dg/darwin-20040809-2.c: Likewise. * objc.dg/stabs-1.m: Likewise. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config.in branches/gcc-5-branch/gcc/config/darwin.h branches/gcc-5-branch/gcc/config/i386/darwin.h branches/gcc-5-branch/gcc/configure branches/gcc-5-branch/gcc/configure.ac branches/gcc-5-branch/gcc/doc/sourcebuild.texi branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C branches/gcc-5-branch/gcc/testsuite/g++.dg/other/PR23205.C branches/gcc-5-branch/gcc/testsuite/g++.dg/other/pr23205-2.C branches/gcc-5-branch/gcc/testsuite/gcc.dg/20040813-1.c branches/gcc-5-branch/gcc/testsuite/gcc.dg/darwin-20040809-2.c branches/gcc-5-branch/gcc/testsuite/lib/target-supports.exp branches/gcc-5-branch/gcc/testsuite/objc.dg/stabs-1.m
[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #15 from Dominique d'Humieres --- > Another odd thing I found is on or about scanner.c:1530 is this: > > if (c == '0' || c == ' ' || c == '\n') > > What is the significance of a zero digit in that position. ... '0' is not a continuation character.
[Bug target/71000] Wrong defines for ATMEGA328p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71000 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Georg-Johann Lay --- Target support macros and headers are realm of AVR-Libc, it is not a compiler issue. Please report at AVR-Libc's bug tracker http://savannah.nongnu.org/bugs/?group=avr-libc
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Status|UNCONFIRMED |NEW
Known to work||4.6.2
Keywords||ice-on-valid-code
Last reconfirmed||2016-05-21
CC||gjl at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||4.7.2, 4.8.0, 4.9.2, 5.2.1
Severity|major |normal
--- Comment #1 from Georg-Johann Lay ---
Confirmed for 5.2.1. At .expand we have
;; MEM[(struct ResponseStruct *)&D.1574 + 1B] = &response;
(insn 6 5 7 (set (subreg:QI (reg:PSI 42 [ D.1574 ]) 1)
(subreg:QI (symbol_ref:HI ("response") [flags 0x2] ) 0)) foo.c:11 -1
(nil))
(insn 7 6 0 (set (subreg:QI (reg:PSI 42 [ D.1574 ]) 2)
(subreg:QI (symbol_ref:HI ("response") [flags 0x2] ) 1)) foo.c:11 -1
(nil))
hence the load of HImode &response is broken into 2 QImode leaving us with
subregs of the symbol_ref. 4.6.2 does work (presumably because there was no
PSImode in <= 4.6)
[Bug target/70999] AVR: String incorrectly placed in flash instead of RAM when building with -ffunction-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70999 Georg-Johann Lay changed: What|Removed |Added Target||avr Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |DUPLICATE Severity|major |normal --- Comment #1 from Georg-Johann Lay --- Same as PR71151, more info there. *** This bug has been marked as a duplicate of bug 71151 ***
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 Georg-Johann Lay changed: What|Removed |Added CC||gigo121 at gmail dot com --- Comment #4 from Georg-Johann Lay --- *** Bug 70999 has been marked as a duplicate of this bug. ***
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #2 from denisc at gcc dot gnu.org --- Author: denisc Date: Sat May 21 10:47:27 2016 New Revision: 236558 URL: https://gcc.gnu.org/viewcvs?rev=236558&root=gcc&view=rev Log: PR target/71103 * config/avr/avr.md (define_expand "mov"): If the source operand is subreg (symbol_ref) then move the symbol ref to register. PR target/71103 * gcc.target/avr/pr71103.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/pr71103.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/testsuite/ChangeLog
[Bug target/70677] Suboptimal cond on AVR: unneeded stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70677 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization Target||avr Priority|P3 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2016-05-21 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Georg-Johann Lay --- Would you provide a test case, please? Cf. https://gcc.gnu.org/bugs/#need For example there is nothing like "panVel" in your code.
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization Target||avr Priority|P3 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2016-05-21 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Georg-Johann Lay --- You missed to add a test case, cf. https://gcc.gnu.org/bugs/#need > Can GCC in -Os really optimize only size and rollback optimizations No, GCC usually won't "rollback" optimizations, and it won't perform speculative optimizations. There are cases where avr-gcc does not optimize sibling calls. Provided you use -mrelax (or link with -Wl,--relax), the linker tries to replace [R]CALL+RET by [R]JMP instruction. If there is a label at the }, i.e. between the CALL and the RET, no optimization is possible.
[Bug target/69647] gcc build for avr-unknown-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69647 Georg-Johann Lay changed: What|Removed |Added Target||avr Status|WAITING |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Georg-Johann Lay --- Invalid bug: Read v5 Release Caveats > On AVR, support has been added for the devices ATtiny4/5/9/10/20/40. > This requires Binutils 2.25 or newer. http://gcc.gnu.org/gcc-5/changes.html
[Bug c++/71218] New: Add a warning about "new T[integer-literal]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71218 Bug ID: 71218 Summary: Add a warning about "new T[integer-literal]" Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- There is no reason anyone should ever write: T* p = new T[8]; ... delete[] p; The compiler should issue a warning telling them to stop being silly. It should probably only trigger for integer literals, because a variable or a macro might be constant in some build configurations and not in others. But an integer literal that isn't the result of macro-expansion is just silly.
[Bug c++/71218] Add a warning about "new T[integer-literal]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71218 --- Comment #1 from Marc Glisse --- Can you be more specific? Do you mean people should have written: T tab[8]; instead? What if 8 or sizeof(T) is large? If your "..." includes possible writes to p, or if p escapes and "..." may throw, I guess that cancels the warning? At some point the issue becomes similar to optimizing malloc to a stack allocation.
[Bug c++/63999] Explicit conversion operators are not considered for explicit cast using braces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63999
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Last reconfirmed|2014-11-20 00:00:00 |2016-5-21
--- Comment #2 from Jonathan Wakely ---
This breaks https://github.com/HowardHinnant/date
iso_week.h: In constructor ‘constexpr
iso_week::weekday::weekday(date::weekday)’:
iso_week.h:434:38: error: cannot convert ‘date::weekday’ to ‘unsigned int’ in
initialization
: wd_(to_iso_encoding(unsigned{wd}))
^
[Bug c/71219] New: Warn about (struct S*)malloc(n) where n < sizeof(struct S)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71219
Bug ID: 71219
Summary: Warn about (struct S*)malloc(n) where n <
sizeof(struct S)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The change in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2010 for the
ISO/IEC TS 17961:2013 secure coding guidelines for C would make sense as a GCC
warning, even if the rest of the TS isn't supported.
struct S1 {
unsigned int x;
floaty;
struct S1 *z;
};
struct S1 *f1(void) {
struct S1 *p = (struct S1*)malloc(sizeof(p)); // diagnostic required
return p;
}
The malloc call can be presumed to be for an object of type struct S1, as
implied by the cast and the variable it is used to initialize, so trying to
allocate fewer than sizeof(struct S1) bytes should be diagnosed.
This would issue a warning for some of the bugs shown in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702#c3 which are not diagnosed
by -Wsizeof-pointer-memaccess
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702 --- Comment #12 from Jonathan Wakely --- PR 71219 requests a new warning for: struct S* p = (struct S*)malloc(sizeof(p)); which would solve some of the other bugs shown in comment 3.
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702 --- Comment #13 from Jakub Jelinek --- If we add such a warning, IMNSHO it shouldn't be in -Wall, because sizeof on pointer is a perfectly valid thing, which is used in huge amounts of code, there is really nothing wrong on it.
[Bug c++/71218] Add a warning about "new T[integer-literal]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71218 --- Comment #2 from Jonathan Wakely --- (In reply to Marc Glisse from comment #1) > Can you be more specific? Do you mean people should have written: > T tab[8]; Yes, exactly. I was fixing some code earlier today that used a dynamically allocated buffer of 8 chars and deleted it at the end of the function (but failed to do so on two early return paths). There was no reason it was done that way instead of using an automatic array, probably just someone who learnt to programme in Java and didn't know better. > instead? What if 8 or sizeof(T) is large? The case I looked at was char, it would probably be OK to only warn for scalar types, and for small array lengths (for some value of small). > If your "..." includes possible > writes to p, or if p escapes and "..." may throw, I guess that cancels the > warning? At some point the issue becomes similar to optimizing malloc to a > stack allocation. Part of the problem in the code I was fixing was that the "..." certainly could throw, and the delete never happened. But maybe the escape analysis is too tricky.
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702 --- Comment #14 from Jonathan Wakely --- See PR 71219 and the TC it links to. The suggestion is to warn for (T*)malloc(n) where n < sizeof(T) i.e. when there is enough context to infer that what was intended was malloc(sizeof(T)). The occurrence of sizeof(p) in the example is not essential to the point, it's just a common way that the bug happens.
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702 --- Comment #15 from Jakub Jelinek --- Even (T*)malloc(n) where n < sizeof(T) is quite common, e.g. in GCC itself (well, we don't usually use malloc but some ggc_alloc*) - e.g. if T is a union and the code wants to allocate memory just for one of the union members, or if there is some struct at the beginning and user wants to allocate memory just for that initial struct rather than for the whole object.
[Bug c++/71205] c++14 wrong constructor resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71205 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-21 Ever confirmed|0 |1
[Bug target/71191] aarch64 and others: __atomic_load;arithmetic;__atomic_compare_exchange loops should be able to generate better code with LL/SC-type constructs than a CAS loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71191 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug c++/70735] [5/6/7 Regression] problem combining std::function, generic lambdas and static variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70735
Maurice changed:
What|Removed |Added
CC||m-ou...@m-ou.se
--- Comment #12 from Maurice ---
It even seems to make a copy of non-copyable objects:
#include
#include
int main() {
static std::mutex a;
std::cout << (void*)&a << std::endl;
void (*f)(int) = [&] (auto) { std::cout << (void*)&a << std::endl; };
f(0);
}
Gave the output:
0x600e00
0x600dc0
(gcc version 6.1.1 20160501)
[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461
--- Comment #16 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #10)
> This is a bandaid, but it works.
>
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> index 2490f856..726973a6 100644
> --- a/gcc/fortran/match.c
> +++ b/gcc/fortran/match.c
> @@ -1438,7 +1438,16 @@ gfc_match_if (gfc_statement *if_type)
>if (m == MATCH_ERROR)
> return MATCH_ERROR;
>
> - gfc_match (" if ( %e ) ", &expr);/* Guaranteed to match. */
> + m = gfc_match (" if ( %e ) ", &expr); /* Not always guaranteed to match.
> */
> +
> + if (m == MATCH_ERROR)
> +{
> + /* Under some invalid conditions like unexpected end of file, one
> +can get an error in the match. We bail out here and hope for
> +the best (the best being an error reported somewhere else. */
> + gfc_clear_error ();
> + return MATCH_YES;
> +}
>
>m = gfc_match_pointer_assignment ();
>if (m == MATCH_YES)
>
> Probably need to test some variations. I have dug around quite a bit in the
> scanner.c and other places trying to understand why this bug is only in
> fixed source. To no avail, and not sure its worth more time. I have even
> tried saving the know good locus and retoring just before the failing match
> attempt and it does not work.
I think your patch is almost correct. A better alternative would be
Index: match.c
===
--- match.c (revision 236243)
+++ match.c (working copy)
@@ -1560,7 +1560,22 @@ gfc_match_if (gfc_statement *if_type)
if (m == MATCH_ERROR)
return MATCH_ERROR;
- gfc_match (" if ( %e ) ", &expr);/* Guaranteed to match. */
+ /* This should match, but mangled fixed-form Fortran code can return
+ an allocated, but otherwise uninitialized, expr. We check for
+ MATCH_NO or MATCH_ERROR, then queue an error and return. */
+ m = gfc_match (" if ( %e ) ", &expr);
+ if (gfc_current_form == FORM_FIXED && m != MATCH_YES)
+{
+ if (expr && expr->expr_type == 0)
+ free (expr);
+ else
+gfc_free_expr (expr);
+
+ gfc_undo_symbols ();
+ gfc_current_locus = old_loc;
+ gfc_error ("Mangled fixed-form Fortran near IF-statement at %C");
+ return MATCH_ERROR;
+}
m = gfc_match_pointer_assignment ();
if (m == MATCH_YES)
[Bug target/71056] [6/7 Regression] __builtin_bswap32 NEON instruction error with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71056 --- Comment #4 from Yichao Yu --- (Sorry I'm not sure how to understand that cross link). Is the fix merged?
[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #17 from Jerry DeLisle --- Steve, I like your patch much better. I will test and commit for you with a Changelog Dominique, Do you have a version of gfortran where this does not give an ICE??? I have just one other thing to check first
[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #18 from Dominique d'Humieres --- > Dominique, Do you have a version of gfortran where this does not give an > ICE??? 4.3.1, 4.3.6, and 4.4.7 (see comment 13).
[Bug c++/71220] New: ICE on instantiation using variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71220
Bug ID: 71220
Summary: ICE on instantiation using variadic template
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rippey.e at gmail dot com
Target Milestone: ---
Running g++ 6.1.0 on the following code:
struct S1{};
template
template
using U=S1;
template
struct S2{
template>
struct S3;
S3
};
produces this error message:
a1.cpp:11:7: internal compiler error: Segmentation fault
S3
^
0xaf5d8f crash_signal
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/toplev.c:333
0x63d839 tsubst(tree_node*, tree_node*, int, tree_node*)
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/pt.c:12968
0x643f42 tsubst_template_args
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/pt.c:11221
0x644042 tsubst_template_args
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/pt.c:11181
0x63d969 tsubst(tree_node*, tree_node*, int, tree_node*)
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/pt.c:13218
0x63de32 tsubst(tree_node*, tree_node*, int, tree_node*)
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/pt.c:12841
0x643674 coerce_template_parms
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/pt.c:7687
0x643def coerce_innermost_template_parms
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/pt.c:7803
0x644849 lookup_template_class_1
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/pt.c:8294
0x644849 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/pt.c:8638
0x6db2fd finish_template_type(tree_node*, tree_node*, int)
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/semantics.c:3154
0x69a316 cp_parser_template_id
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:14914
0x69a48b cp_parser_class_name
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:21201
0x68e3b9 cp_parser_qualifying_entity
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:6237
0x68e3b9 cp_parser_nested_name_specifier_opt
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:5923
0x69bd1f cp_parser_nested_name_specifier
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:6167
0x69bd1f cp_parser_using_declaration
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:17743
0x6a67d7 cp_parser_member_declaration
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:22294
0x6892a1 cp_parser_member_specification_opt
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:22154
0x6892a1 cp_parser_class_specifier_1
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:21346
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug c++/71221] New: [concepts] ICE in tsubst_pack_expansion when expanding a sizeof... expression in a requires clause of a member function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221
Bug ID: 71221
Summary: [concepts] ICE in tsubst_pack_expansion when expanding
a sizeof... expression in a requires clause of a
member function template
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
The following test case demonstrates an internal compiler error that occurs
with gcc 7.0.0 (r236423) when expanding a sizeof... expression in a requires
clause of a member function template.
$ cat t.cpp
template
struct int_sequence {};
template
struct S {
template
requires sizeof...(Is) == N
int mf1(int_sequence);
void mf2() {
mf1(int_sequence<>{});
}
};
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236427
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236423
Last Changed Date: 2016-05-18 15:15:22 -0400 (Wed, 18 May 2016)
$ g++ --version
g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
...
$ g++ -c -std=c++1z -fconcepts t.cpp
t.cpp: In member function ‘void S::mf2()’:
t.cpp:6:20: internal compiler error: in tsubst_pack_expansion, at cp/pt.c:10967
requires sizeof...(Is) == N
^~~
0x6c758f tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc-trunk/gcc/cp/pt.c:10967
0x6b190b tsubst_copy
../../gcc-trunk/gcc/cp/pt.c:14131
0x6b525a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:17161
0x6b4beb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-trunk/gcc/cp/pt.c:16176
0x6a99ee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-trunk/gcc/cp/pt.c:15800
0x889a67 satisfy_predicate_constraint
../../gcc-trunk/gcc/cp/constraint.cc:1768
0x889a67 satisfy_constraint_1
../../gcc-trunk/gcc/cp/constraint.cc:1975
0x88a866 satisfy_constraint
../../gcc-trunk/gcc/cp/constraint.cc:2026
0x88a9bc constraints_satisfied_p(tree_node*)
../../gcc-trunk/gcc/cp/constraint.cc:2133
0x64807c add_function_candidate
../../gcc-trunk/gcc/cp/call.c:2013
0x648d9c add_template_candidate_real
../../gcc-trunk/gcc/cp/call.c:3146
0x649693 add_template_candidate
../../gcc-trunk/gcc/cp/call.c:3188
0x649693 add_candidates
../../gcc-trunk/gcc/cp/call.c:5361
0x649f2f build_new_method_call_1
../../gcc-trunk/gcc/cp/call.c:8313
0x649f2f build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc-trunk/gcc/cp/call.c:8512
0x7610f2 cp_parser_postfix_expression
../../gcc-trunk/gcc/cp/parser.c:6875
0x75ebdc cp_parser_unary_expression
../../gcc-trunk/gcc/cp/parser.c:7986
0x768db7 cp_parser_cast_expression
../../gcc-trunk/gcc/cp/parser.c:8663
0x7693a3 cp_parser_binary_expression
../../gcc-trunk/gcc/cp/parser.c:8764
0x769c94 cp_parser_assignment_expression
../../gcc-trunk/gcc/cp/parser.c:9051
...
[Bug c++/71222] New: [concepts] ill-formed code taking the address of a function concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71222
Bug ID: 71222
Summary: [concepts] ill-formed code taking the address of a
function concept not rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org
Target Milestone: ---
I believe the following code is ill-formed though I was unable to find
normative text in N4553 that explicitly makes it such. The following
non-normative note in § 7.1.7p5 [dcl.spec.concept] suggests the intent for this
code to be ill-formed:
[Note: Return type deduction requires the instantiation of the function
definition, but concept definitions are not instantiated; they are normalized
(14.10.2). — end note]
gcc 7.0.0 (r236423) currently accepts this code, though a link error occurs
when linking an executable due to the reference to the uninstantiated FC
function concept. Note that directly invoking the function concept would
produce no errors since the result is evaluated at compile time; only taking
the address and later attempting to invoke the function is ill-formed.
$ cat t.cpp
template
concept bool FC() { return true; }
int main() {
auto fc = &FC;
fc();
}
$ svn info
Path: .
Working Copy Root Path: /home/tom/src/gcc-trunk
URL: svn://gcc.gnu.org/svn/gcc/trunk
Relative URL: ^/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 236427
Node Kind: directory
Schedule: normal
Last Changed Author: uros
Last Changed Rev: 236423
Last Changed Date: 2016-05-18 15:15:22 -0400 (Wed, 18 May 2016)
$ g++ --version
g++ (GCC) 7.0.0 20160518 (experimental)
...
$ g++ -c -std=c++1z -fconcepts t.cpp; echo $?
0
$ g++ -std=c++1z -fconcepts t.o -o t
t.o: In function `main':
t.cpp:(.text+0xc): undefined reference to `bool FC()'
collect2: error: ld returned 1 exit status
[Bug c++/71221] [concepts] ICE in tsubst_pack_expansion when expanding a sizeof... expression in a requires clause of a member function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221 --- Comment #1 from Tom Honermann --- (In reply to Tom Honermann from comment #0) > $ g++ --version > g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010 Oops, I ran the above in the wrong terminal session. The correct gcc version info is: $ g++ --version g++ (GCC) 7.0.0 20160518 (experimental) ...
[Bug c++/71223] New: [fold expression] Incorrect processing a fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71223 Bug ID: 71223 Summary: [fold expression] Incorrect processing a fold expression Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sergstrukovlink at gmail dot com Target Milestone: --- Created attachment 38539 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38539&action=edit example In the attached example compiler fails to compile the following line Test2(); // emits error If I change the definition of template using AddType = TypeBox ; // int to template using AddType = int ; the error disappeares. main.cpp: In instantiation of 'struct Test2': main.cpp:41:25: required from here main.cpp:23:74: error: invalid use of pack expansion expression using IndexList = decltype( ( IndexListBox<>() + ... + AddType() ) ) ; ^ make: *** [main.o] Error 1
