[Bug c++/66520] bad code generated code for branches with single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520 --- Comment #7 from Fisnik fkastrati at gmail dot com --- (In reply to Eric Botcazou from comment #5) Compiler should not generate the same code, and should listen to the developer, when she/he connects predicates with single `'. I already wrote that I did benchmarks, and also mentioned a paper from a top computer science conference (which I see you didn't even bother to read it) which has all the evidence required. You're still missing the point! If the non-branchy form is the fastest, then the compiler should generate it also with the short-circuit form . And I also mentioned it that Intel's compiler is catching this very well. Nope, the Intel compiler is inconsistent here (unlike GCC and Clang). As I said, I would leave that to the developer. If I connect predicates with , the compiler should generate the non-branchy code. So this issue is definatively an optimization bug.
[Bug bootstrap/66508] Attempt to Compile gcc-6.0 on OSX 10.9.4 cause segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66508 --- Comment #5 from Fan You youfan.noey at gmail dot com --- (In reply to Iain Sandoe from comment #4) (In reply to Fan You from comment #3) (In reply to Dominique d'Humieres from comment #2) Duplicate of pr66448? Which revision are you using? Just updated and tried again, get the same result. Revision: 224410 After changing get similar error as pr66448 /Users/jieyuandai/src/gcc/gcc/dwarf2out.c:5693:1: error: ‘void check_die(dw_die_ref)’ defined but not used [-Werror=unused-function] check_die (dw_die_ref die) ^ cc1plus: all warnings being treated as errors I think that should have been fixed by 224431, and Darwin bootstrap (pr66448) should be OK as of r224451. Let us know if problems persist Fixed, Thanks.
[Bug c++/66520] bad code generated code for branches with single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520 --- Comment #4 from Fisnik fkastrati at gmail dot com --- (In reply to Eric Botcazou from comment #3) There should be at least some flag available, such that we can set such a flag and have the compiler generate only a single jump for the method with single ampersand. You missed the point though, the compiler should generate the same code in both cases. Whether or not it's the branchy form is another debate, which cannot be settled with toy examples like this one but by using real-life benchmarks. Compiler should not generate the same code, and should listen to the developer, when she/he connects predicates with single `'. I already wrote that I did benchmarks, and also mentioned a paper from a top computer science conference (which I see you didn't even bother to read it) which has all the evidence required. The branch misprediction penalty for the assembly code with two jumps is simply too severe when the selectivity of a predicate is around 0.5. And I also mentioned it that Intel's compiler is catching this very well. The example was given just to point the problem, I cannot possibly write you here 10k lines of code of my project.
[Bug c++/66520] bad code generated code for branches with single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Fisnik from comment #8) To this end, the compiler should respect the code written by the developer. As far as the C++ standard is concerned the built-in and operators for type bool are equivalent if evaluating the operands has no side-effects. C++ is not a high-level assembly language. I'm already having trouble with g++, as for the code with single , it is generating inefficient code. Or I have to remove completely the optimization flag '-O3', but then I have a very slow code Have you tried just using -O3 -fno-xxx for the relevant pass?
[Bug fortran/66385] [4.9/5/6 Regression] ICE: FORALL writing multiple elements of one array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66385 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Sun Jun 14 10:08:00 2015 New Revision: 224465 URL: https://gcc.gnu.org/viewcvs?rev=224465root=gccview=rev Log: 2015-06-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/66385 Backport from trunk * frontend-passes.c (combine_array_constructor): Return early if inside a FORALL loop. 2015-06-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/66385 * gfortran.dg/forall_17.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/forall_17.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/frontend-passes.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug ada/65102] gnat-style.texi warning from including fdl.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65102 --- Comment #3 from vries at gcc dot gnu.org --- (In reply to vries from comment #2) requested approval for fdl.texi part from docs co-maintainer: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01056.html Posted updated patch: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00975.html
[Bug c++/66520] bad code generated code for branches with single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Compiler should not generate the same code, and should listen to the developer, when she/he connects predicates with single `'. I already wrote that I did benchmarks, and also mentioned a paper from a top computer science conference (which I see you didn't even bother to read it) which has all the evidence required. You're still missing the point! If the non-branchy form is the fastest, then the compiler should generate it also with the short-circuit form . And I also mentioned it that Intel's compiler is catching this very well. Nope, the Intel compiler is inconsistent here (unlike GCC and Clang).
[Bug c++/66520] bad code generated code for branches with single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520 --- Comment #6 from Andreas Schwab sch...@linux-m68k.org --- If a and b are side-effect-free, pure-boolean expressions then `a b' and `a b' are completely equivalent and there is no reason to generate different code for them.
[Bug fortran/66534] New: Compilation error of gfortran building on YDL6.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66534
Bug ID: 66534
Summary: Compilation error of gfortran building on YDL6.2
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: textdirected at gmail dot com
Target Milestone: ---
Hello all,
When I tried to build gcc 5.0 downloaded from a mirror site, I encountered a
compilation error in building gfortran. I am working on YDL(yellow dog linux)
6.2 of an old iBook machine.
The console output is:
Checking multilib configuration for libgfortran...
make[2]: Entering directory `/home/zgzg/gcc-5.1.0/powerpc-unknown-linux
gnu/libgfortran'
make all-am
make[3]: Entering directory
`/home/zgzg/gcc-5.1.0/powerpc-unknown-linux-gnu/libgfortran'
/bin/sh ./libtool --tag=CC --mode=compile
/home/zgzg/gcc-5.1.0/host-powerpc-unknown-linux-gnu/gcc/xgcc
-B/home/zgzg/gcc-5.1.0/host-powerpc-unknown-linux-gnu/gcc/
-B/opt/powerpc-unknown-linux-gnu/bin/ -B/opt/powerpc-unknown-linux-gnu/lib/
-isystem /opt/powerpc-unknown-linux-gnu/include -isystem
/opt/powerpc-unknown-linux-gnu/sys-include-DHAVE_CONFIG_H -I.
-I../.././libgfortran -iquote../.././libgfortran/io
-I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config
-I../../host-powerpc-unknown-linux-gnu/gcc -I../.././libgfortran/../libgcc
-I../libgcc -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT string.lo -MD -MP -MF
.deps/string.Tpo -c -o string.lo `test -f 'runtime/string.c' || echo
'../.././libgfortran/'`runtime/string.c
libtool: compile: /home/zgzg/gcc-5.1.0/host-powerpc-unknown-linux-gnu/gcc/xgcc
-B/home/zgzg/gcc-5.1.0/host-powerpc-unknown-linux-gnu/gcc/
-B/opt/powerpc-unknown-linux-gnu/bin/ -B/opt/powerpc-unknown-linux-gnu/lib/
-isystem /opt/powerpc-unknown-linux-gnu/include -isystem
/opt/powerpc-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../.././libgfortran -iquote../.././libgfortran/io
-I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config
-I../../host-powerpc-unknown-linux-gnu/gcc -I../.././libgfortran/../libgcc
-I../libgcc -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT string.lo -MD -MP -MF
.deps/string.Tpo -c ../.././libgfortran/runtime/string.c -fPIC -DPIC -o
.libs/string.o
make[3]: Leaving directory
`/home/zgzg/gcc-5.1.0/powerpc-unknown-linux-gnu/libgfortran'
make[2]: Leaving directory
`/home/zgzg/gcc-5.1.0/powerpc-unknown-linux-gnu/libgfortran'
make[1]: Leaving directory `/home/zgzg/gcc-5.1.0'
../.././libgfortran/runtime/string.c:96:1: error: static declaration of
'strnlen' follows non-static declaration
strnlen (const char *s, size_t maxlen)
^
In file included from ../.././libgfortran/runtime/string.c:26:0:
/usr/include/string.h:249:15: note: previous declaration of 'strnlen' was here
extern size_t strnlen (__const char *__string, size_t __maxlen)
^
In file included from /usr/include/string.h:417:0,
from ../.././libgfortran/runtime/string.c:26:
../.././libgfortran/runtime/string.c:110:1: error: expected identifier or '('
before '__extension__'
strndup (const char *s, size_t n)
^
../.././libgfortran/runtime/string.c:96:1: warning: 'strnlen' defined but not
used [-Wunused-function]
strnlen (const char *s, size_t maxlen)
^
make[3]: *** [string.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libgfortran] Error 2
make: *** [all] Error 2
Please help me
best regards,
[Bug c++/66520] bad code generated code for branches with single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520 --- Comment #8 from Fisnik fkastrati at gmail dot com --- (In reply to Andreas Schwab from comment #6) If a and b are side-effect-free, pure-boolean expressions then `a b' and `a b' are completely equivalent and there is no reason to generate different code for them. I said it is an optimization bug. The branchy code is very expensive when the first operand has probability of around 0.5 of being true, therefore it ruins the branch prediction. Now you can imagine a much more complex scenario, such as e.g. (A B ... Z), and if all predicates have probabilities of 0.5, then I'll end here with very inefficient code (the way the g++ is generating assembly). This does not happen for e.g. with icc. To this end, the compiler should respect the code written by the developer. I'm already having trouble with g++, as for the code with single , it is generating inefficient code. Or I have to remove completely the optimization flag '-O3', but then I have a very slow code, and your comments are not helping me at all solve the problem!
[Bug fortran/66534] Compilation error of gfortran building on YDL6.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66534 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-06-14 Ever confirmed|0 |1 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- Please attach the file `/home/zgzg/gcc-5.1.0/powerpc-unknown-linux-gnu/libgfortran/config.log'.
[Bug tree-optimization/65511] transform_to_exit_first_loop looses edge probabilities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65511 --- Comment #7 from vries at gcc dot gnu.org --- pinged patches at: - https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00976.html - https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00977.html
[Bug tree-optimization/66512] PRE fails to optimize calls to pure functions in C++, ok in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Because p may throw. What we miss here is the fact that it should only matter
if p throws internally for IL consistency. Of course it still matters for
observing other side-effects if p throws and after the transform now does so
before side-effects that should be observed otherwise. Consider
for (;;)
{
printf(foo);
g(p())
}
and p throwing.
So you miss a nothrow attribute or a throw() specification here. const
does _not_ imply nothrow.
[Bug c++/65719] Link error with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65719 --- Comment #9 from Louis Dionne ldionne.2 at gmail dot com --- I can confirm that my original use case now works. Thanks a bunch!
[Bug c/29192] gcc will delete the c_source_file.c without any alarm!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29192 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added CC||yongjin.ohn at lge dot com --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- *** Bug 66532 has been marked as a duplicate of this bug. ***
[Bug c/66532] Source file deleted when we use gcc compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66532 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- dup *** This bug has been marked as a duplicate of bug 29192 ***
[Bug c++/66520] bad code generated code for branches with single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66520 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- There should be at least some flag available, such that we can set such a flag and have the compiler generate only a single jump for the method with single ampersand. You missed the point though, the compiler should generate the same code in both cases. Whether or not it's the branchy form is another debate, which cannot be settled with toy examples like this one but by using real-life benchmarks.
[Bug middle-end/66325] [6 Regression] ICE in gcc.c-torture/execute/930408-1.c, verify_type fails with --enable-checking=yes on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66325 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Sun Jun 14 07:05:03 2015 New Revision: 224463 URL: https://gcc.gnu.org/viewcvs?rev=224463root=gccview=rev Log: PR middle-end/66325 * c-decl.c (start_enum): Set TYPE_PACKED consistently among type variants. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c
[Bug c++/66533] New: ICE: in dependent_type_p, at cp/pt.c:21073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66533
Bug ID: 66533
Summary: ICE: in dependent_type_p, at cp/pt.c:21073
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
% echo auto a([](auto) - decltype((void)0) {}); | g++ -c -x c++ -std=c++14 -
stdin: In lambda function:
stdin:1:20: internal compiler error: in dependent_type_p, at cp/pt.c:21073
0x101e01e3 dependent_type_p(tree_node*)
../../gcc/gcc/cp/pt.c:21073
0x101a48a7 require_complete_types_for_parms
../../gcc/gcc/cp/decl.c:11123
0x101a48a7 check_function_type
../../gcc/gcc/cp/decl.c:13272
0x101a48a7 start_preparsed_function(tree_node*, tree_node*, int)
../../gcc/gcc/cp/decl.c:13446
0x102bf6a3 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:9498
0x102bf6a3 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:9060
0x102bf6a3 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4453
0x102ce157 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6131
0x102d19c7 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7412
0x102d2eaf cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8147
0x102d391b cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8404
0x102d3fff cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8650
0x102d55d7 cp_parser_parenthesized_expression_list
../../gcc/gcc/cp/parser.c:6880
0x102d68ab cp_parser_initializer
../../gcc/gcc/cp/parser.c:19310
0x102f7edb cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:17263
0x102fad43 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11608
0x102f26e7 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11482
0x102ffc8f cp_parser_declaration
../../gcc/gcc/cp/parser.c:11379
0x102fdc2f cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11265
0x102fe013 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4100
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/65488] parloops runs for functions it doesn't process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65488 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #3 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00971.html
[Bug c/66532] New: Source file deleted when we use gcc compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66532 Bug ID: 66532 Summary: Source file deleted when we use gcc compile Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yongjin.ohn at lge dot com Target Milestone: --- Hello guys. I'm newbie about the GCC compiler. Also, my english skill is poor, please understand it. Actually, When I compile using below command, my source are deleted. gcc -o mysource.c mysource I know this command is wrong. but I think that this is a problem. because user can make a mistake. Also user can't recover his source code everything. So, I think that If user input the like upper commend, we can change the parameter order or backup the source file. If you agree this situation, I'll try upload the patch.
[Bug debug/66535] New: segfault in gen_subprogram_die after debug-early merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66535 Bug ID: 66535 Summary: segfault in gen_subprogram_die after debug-early merge Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ebotcazou at gcc dot gnu.org CC: aldyh at gcc dot gnu.org Target Milestone: --- Created attachment 35776 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35776action=edit Testcase to be gnatchop'ed The debug-early merge has introduced a crash on the attached Ada testcase: eric@polaris:~/build/gcc/native gcc/xgcc -Bgcc -S debug4.adb -g raised STORAGE_ERROR : stack overflow or erroneous memory access Program received signal SIGSEGV, Segmentation fault. 0x00b3685c in gen_subprogram_die (decl=0x753928c0, context_die=0x0) at /home/eric/gnat/gnat-head/src/gcc/dwarf2out.c:18793 18793 || old_die-die_parent-die_tag == DW_TAG_module old_die-die_parent is NULL. The testcase can be added as-is to the gnat.dg/ testsuite: gnat.dg/debug4.adb gnat.dg/debug4_pkg.adb gnat.dg/debug4_pkg.ads
[Bug c++/58063] default arguments evaluated twice per call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063 --- Comment #12 from plokinom at gmail dot com --- I can confirm this still happens with g++ 5.1.0.
[Bug c/66527] incorrect line number in diagnostics for multiline initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66527 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-14 CC||manu at gcc dot gnu.org Component|preprocessor|c Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- This probably requires passing an explicit location to c_mark_addressable and using error_at everywhere.
[Bug ada/66242] Front-end error if exception propagation disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66242 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target|arm-eabi, | |x86_64-apple-darwin13 | Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-14 CC||ebotcazou at gcc dot gnu.org Host|x86_64-apple-darwin13 | Ever confirmed|0 |1 Severity|normal |enhancement
[Bug c++/66387] [5/6 Regression] ICE in make_decl_rtl with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66387
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Created attachment 35778
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35778action=edit
Somewhat reduced testcase
A variant that is still unfixed is attached:
trippels@gcc2-power8 example % g++ -c -std=c++14 tag_dispatching.ii
tag_dispatching.ii: In lambda function:
tag_dispatching.ii:113:38: internal compiler error: in make_decl_rtl, at
varasm.c:1313
N.times.with_index([](auto) { N - hana::size_t1; });
^
0x10a160d3 make_decl_rtl(tree_node*)
../../gcc/gcc/varasm.c:1309
0x104639eb expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:9581
0x1046d773 expand_expr
../../gcc/gcc/expr.h:254
0x1046d773 expand_expr_addr_expr_1
../../gcc/gcc/expr.c:7722
0x1046227b expand_expr_addr_expr
../../gcc/gcc/expr.c:7850
0x1046227b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10724
0x1046dd7f store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*)
../../gcc/gcc/expr.c:5385
0x1047360f expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5154
0x10351457 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3401
0x10351457 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3497
0x10357353 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5509
0x10359207 execute
../../gcc/gcc/cfgexpand.c:6127
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/66281] [C++14][Variable templates] internal compiler error: in tsubst, at cp/pt.c:12022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66281 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Here is a variant: template int int bool_; template char n auto digit(bool_n); template char, int, int y auto evaluate(digity); auto boost_hana_tmp_40 = evaluate'1', '+', '2';
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 Lisandro Damián Nicanor Pérez Meyer perezmeyer at gmail dot com changed: What|Removed |Added CC||perezmeyer at gmail dot com --- Comment #5 from Lisandro Damián Nicanor Pérez Meyer perezmeyer at gmail dot com --- A very similar problem has been described in [bug] with even a fix which I believe it's part of gcc5 [fix] [bug] http://patchwork.openembedded.org/patch/92055/ [fix] https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=212178
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 --- Comment #6 from Lisandro Damián Nicanor Pérez Meyer perezmeyer at gmail dot com --- FWIW, it seems fixed in the linaro branch.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Segher Boessenkool segher at gcc dot gnu.org changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #18 from Segher Boessenkool segher at gcc dot gnu.org ---
Another way of ignoring the unused result, friendlier on the eyes than
ugly macros or horrible casts, and even *inviting* the programmer to
write an explanatory comment, goes like
if (foo()) {
/* The return value of foo can be ignored here because X and Y. */
}
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 Thomas Preud'homme thopre01 at gcc dot gnu.org changed: What|Removed |Added CC||joseph at codesourcery dot com, ||thopre01 at gcc dot gnu.org --- Comment #7 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- Hi Joseph, It seems you already fixed this bug in trunk. Is there any plan to backport to 4.9 branch? Best regards.
[Bug c++/66536] New: [5/6 Regression] ICE in build_ctor_subob_ref, at cp/tree.c:2534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66536
Bug ID: 66536
Summary: [5/6 Regression] ICE in build_ctor_subob_ref, at
cp/tree.c:2534
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
trippels@gcc2-power8 test % cat array.ii
template typename struct make_impl;
struct Tuple;
template struct make_implTuple {};
struct A {
template typename X auto operator()(X) { return make_implTuple(); }
};
template typename A make;
template typename _Tp, int struct array { _Tp _M_elems; };
struct Tracked {
Tracked(int);
};
struct B {
Tracked tracker{0};
};
template int using ct_eq = B;
auto eq_arrays = makeTuple(arrayct_eq0, 0{});
trippels@gcc2-power8 test % clang++ -c -std=c++14 array.ii
trippels@gcc2-power8 test % c++ -c -std=c++14 array.ii
array.ii:16:50: internal compiler error: in build_ctor_subob_ref, at
cp/tree.c:2534
auto eq_arrays = makeTuple(arrayct_eq0, 0{});
^
0x1039446b build_ctor_subob_ref(tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/tree.c:2533
0x10394703 replace_placeholders_r
../../gcc/gcc/cp/tree.c:2579
0x10dbc523 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_settree_node*, default_hashset_traits*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_settree_node*, default_hashset_traits*))
../../gcc/gcc/tree.c:11176
0x10dbcd63 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_settree_node*, default_hashset_traits*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_settree_node*, default_hashset_traits*))
../../gcc/gcc/tree.c:11390
0x1039490b replace_placeholders(tree_node*, tree_node*)
../../gcc/gcc/cp/tree.c:2604
0x1024bb23 store_init_value(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, int)
../../gcc/gcc/cp/typeck2.c:841
0x10197bc7 check_initializer
../../gcc/gcc/cp/decl.c:6010
0x101c77cf cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6622
0x102f7de3 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:17316
0x102fad43 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11608
0x102f26e7 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11482
0x102ffc8f cp_parser_declaration
../../gcc/gcc/cp/parser.c:11379
0x102fdc2f cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11265
0x102fe013 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4100
0x102fe013 c_parse_file()
../../gcc/gcc/cp/parser.c:33241
0x10493d6b c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1061
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 --- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot com --- I have no backport plans for this patch.
[Bug libgomp/66429] ICE in expand_GOMP_SIMD_LAST_LANE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66429 --- Comment #3 from vries at gcc dot gnu.org --- Created attachment 35777 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35777action=edit tentative patch Using this patch, we avoid the ICE. Not sure if this is the right way to fix it.
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #4 from Paul Thomas pault at gcc dot gnu.org --- Testcase: ! Test vehicle for submodules ! 14th June 2015 ! ! Paul Thomas - check1406b.diff applies ! ! FIXED OR MOSTLY FIXED: ! Access in submodules to PROCEDURE COMPONENTS - FIXED 06/06/2015 ! MODULE FUNCTIONS - partially FIXED 10/06/15 - syntax errors give difficult to understand messages ! Salvatore's submodbug fixed 10/06/15 - module variable must remain use associated ! Name mangling of MODULE PROCEDUREs - FIXED 13/06 ! Parsing of SUBMODULE (module:parent_submodule:.) - already worked(!) tested 14/06 ! Checking characteristics between interface and submodule declaration - FIXED 14/06 ! ! TODOs: ! Clean up and comment all the new code (Partially done 14/06) ! Prepare testcases for testsuite ! Constraints as delineated in N1602.pdf or F2008 standard (will have to check what is left!) ! Restricting output of .mod file from submodules to local symbols, etc. only (not essential) ! Prepare ChangeLogs ! Submit :-) ! module foo_interface implicit none type foo character(len=15) :: greeting = Hello, world! contains procedure :: greet = say_hello procedure :: farewell = bye end type foo interface module subroutine say_hello(this) import foo class(foo), intent(in) :: this end subroutine module subroutine bye(this) import foo class(foo), intent(in) :: this end subroutine module function realf (arg) result (res) real :: arg, res end function integer module function intf (arg) integer :: arg end function real module function realg (arg) real :: arg end function integer module function intg (arg) integer :: arg end function end interface contains subroutine smurf class(foo), allocatable :: this allocate (this) print *, say_hello from SMURF --- ! Test that say_hello is effectively host associated call say_hello (this) end subroutine end module !_! SUBMODULE (foo_interface) foo_interface_son ! contains ! Test module procedure with conventional specification part for dummies module subroutine say_hello(this) class(foo), intent(in) :: this class(foo), allocatable :: that allocate (that, source = this) ! Test that components of foo are accessible print *, (say_hello), that%greeting ! call this%farewell ! NOTE WELL: This compiles and causes a crash in run-time ! due to recursion through the call to this procedure from ! say hello. end subroutine module function realf (arg) result (res) real :: arg, res res = 2*arg end function end SUBMODULE foo_interface_son !_! ! Check that multiple generations of submodules are OK SUBMODULE (foo_interface:foo_interface_son) foo_interface_grandson ! contains integer module function intf (arg) integer :: arg intf = 2*arg end function end SUBMODULE foo_interface_grandson !_! SUBMODULE (foo_interface) foo_interface_daughter ! contains ! Test module procedure with abbreviated declaration and no specification of dummies module procedure bye ! Verify the derived type foo is accessible - had problems with this because if_source != IFSRC_DECL class(foo), allocatable :: that print *, (bye) , this%greeting print *, say_hello from BYE --- call say_hello (this) allocate (that, source = this) ! Test that components of foo are accessible print *, (bye), that%greeting print *, call that%greet from BYE --- call that%greet end subroutine module procedure intg intg = 3*arg end function module procedure realg realg = 3*arg end function end SUBMODULE foo_interface_daughter !_! program try use foo_interface implicit none type(foo) :: bar call bar%greet ! typebound call ! Unnecessary tests at present ! bar%greeting = Goodbye, world! ! call bar%greet ! typebound call with changed message print *, say_hello from TRY --- call say_hello(bar) ! Checks use association of 'say_hello' call bye(bar) ! Checks use association in another submodule call smurf ! Checks host association of 'say_hello' bar%greeting = farewell call bar%farewell print *, realf(2.0) ! Check module procedure with explicit result print *, intf(2)! ditto print *, realg(3.0) ! Check module procedure with function declaration result print *, intg(3)! ditto end program
[Bug c++/66537] An explicit default constructor is accepted when initializing from empty braces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66537 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- Isn't that similar to bug 54835? As far as I remember Jason interprets the standard that the code should be valid, see his comments in above mentioned issue.
[Bug fortran/66528] [6 Regression] unbalanced IF/ENDIF with -fmax-errors=1 causes invalid free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66528 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #3) (In reply to Dominique d'Humieres from comment #2) Usual suspect r223677 (pr66082). I don't believe that a change to trans-array.c can cause a parsing failure. I would rather suspect r223614 . Yes, this is my fault. diagnostic_finish tries to free the output_buffer, but the error_buffer is statically allocated. I think this should be enough: --- error.c (revision 223651) +++ error.c (working copy) @@ -1379,12 +1379,12 @@ gfc_error_check (void) output_buffer *tmp_buffer = pp-buffer; pp-buffer = pp_error_buffer; pp_really_flush (pp); ++errorcount; gcc_assert (gfc_output_buffer_empty_p (pp_error_buffer)); - diagnostic_action_after_output (global_dc, DK_ERROR); pp-buffer = tmp_buffer; + diagnostic_action_after_output (global_dc, DK_ERROR); return true; } return false; } However, a better fix may be to make the error_buffer also dynamically allocated like the warning_buffer. Not sure why I did the change. (It would be nice to have a testcase testing this in the regression testsuite.) Here is the first error reported by valgrind: ==1154== Invalid free() / delete / delete[] / realloc() ==1154==at 0x4C28ADC: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==1154==by 0x126B11B: diagnostic_finish(diagnostic_context*) (diagnostic.c:230) ==1154==by 0x126BF11: diagnostic_action_after_output(diagnostic_context*, diagnostic_t) (diagnostic.c:566) ==1154==by 0x63FB0B: gfc_error_check() (error.c:1384) ==1154==by 0x687E47: decode_statement() (parse.c:554) ==1154==by 0x689740: next_statement() (parse.c:1048) ==1154==by 0x68BA0C: parse_executable(gfc_statement) (parse.c:4593) ==1154==by 0x68C430: parse_executable(gfc_statement) (parse.c:3519) ==1154==by 0x68CA06: parse_progunit(gfc_statement) (parse.c:4976) ==1154==by 0x68E167: gfc_parse_file() (parse.c:5424) ==1154==by 0x6CE642: gfc_be_parse_file() (f95-lang.c:215) ==1154==by 0xBCA44E: compile_file() (toplev.c:560) ==1154== Address 0x1cfefa8 is 8 bytes inside data symbol _ZL12error_buffer
[Bug c++/66537] New: An explicit default constructor is accepted when initializing from empty braces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66537
Bug ID: 66537
Summary: An explicit default constructor is accepted when
initializing from empty braces
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com
Target Milestone: ---
Test snippet:
struct Bob
{
explicit Bob() {}
};
Bob f()
{
return {}; // #1
}
void f2(Bob) {}
int main()
{
f2({}); // #2
}
gcc accepts both #1 and #2, clang rejects both.
I have submitted a patch that makes the standard library tag types
non-default-constructible, but an alternative solution to certain kinds
of ambiguity problems with tuple would be to make the tag types' default
constructors explicit rather than suppressing them. That doesn't currently
work because the front-end accepts initializations like in the example above.
[Bug c++/66537] An explicit default constructor is accepted when initializing from empty braces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66537
--- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Daniel Krügler from comment #1)
Isn't that similar to bug 54835? As far as I remember Jason interprets the
standard that the code should be valid, see his comments in above mentioned
issue.
I think there's a difference. The _temporary_ initialized from {}
is expected to not be allowed when the default constructor is explicit. What
happens after that in returning from a function or passing an argument
is separate.
Implementations disagree, so perhaps the specification needs to be clarified.
[Bug c++/66538] New: Parameter not in scope of generic lambda trailing decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66538
Bug ID: 66538
Summary: Parameter not in scope of generic lambda trailing
decltype
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code does not compile on GCC trunk:
auto f = [](auto x) - decltype((void)x) { };
The failure is
error: ‘x’ was not declared in this scope
Removing the gives an internal compiler error as a bonus:
auto f = [](auto x) - decltype((void)x) { };
The failure is
error: ‘x’ was not declared in this scope
auto f = [](auto x) - decltype((void)x) { };
^
In lambda function:
internal compiler error: in dependent_type_p, at cp/pt.c:21073
auto f = [](auto x) - decltype((void)x) { };
^
Finally, please note that the following code compiles fine:
auto f = [](auto x) - decltype(static_castvoid(x)) { };
Regards,
Louis Dionne
[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181 --- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Sun Jun 14 23:40:12 2015 New Revision: 224471 URL: https://gcc.gnu.org/viewcvs?rev=224471root=gccview=rev Log: PR ipa/66181 * lto.c (compare_tree_sccs_1): Do not compare TYPE_NO_FORCE_BLK. * lto-streamer-out.c (hash_tree): Do not hash TYPE_NO_FORCE_BLK. * tree-streamer-out.c (pack_ts_type_common_value_fields): Do not stream TYPE_NO_FORCE_BLK. * tree-streamer-in.c (unpack_ts_type_common_value_fields): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/tree-streamer-in.c trunk/gcc/tree-streamer-out.c
[Bug jit/66539] New: Missing parentheses in jit dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66539 Bug ID: 66539 Summary: Missing parentheses in jit dumps Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- See: https://gcc.gnu.org/ml/jit/2015-q2/msg00054.html
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas pault at gcc dot gnu.org --- Dear Dominique and Tobias, Whatever is the purpose of this PR, I will use it to hang my hat on :-) I have a submodule patch nearly ready to go. My plan is to submit next Saturday. Cheers Paul
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #3 from Paul Thomas pault at gcc dot gnu.org --- Created attachment 35779 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35779action=edit draft patch
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #19 from rusty at rustcorp dot com.au --- I like WUR as a sanity-check, and it is useful that more and more library authors are using it (generally quite well). As Andrew points out, this has taken 10 years! The downside is that false positives are becoming more common. For example, gnulib also includes a routine to handle this, since 2008: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/ignore-value.h;h=68521edb38f50cb2230c8560a125864be212db6a;hb=HEAD I believe that changing conditions call for a re-evaluation. And yes, I'd like to see a comment on any cast-to-void, not just for WUR. Thanks for your patience!
[Bug ada/66242] Front-end error if exception propagation disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66242 --- Comment #3 from simon at pushface dot org --- (In reply to Ramana Radhakrishnan from comment #2) Patches on mailing list please along with a testcase and stating how it was regression tested. Done.
