[Bug libstdc++/79433] __has_include does not conform to SD-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 --- Comment #11 from Marc Mutz --- Fair enough. Sorry for filing it under the wrong component.
[Bug c++/79435] [7 Regression] ICE on invalid C++ code (with member access into an incomplete type) on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79435 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Version|unknown |7.0 Target Milestone|--- |7.0
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug c/79431] [6/7 Regression] ICE in get, at cgraph.h:397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79431 Richard Biener changed: What|Removed |Added Keywords||openmp Priority|P3 |P2 Target Milestone|--- |6.4
[Bug c++/79429] [6/7 Regression] ICE in add_stmt, at cp/semantics.c:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79429 Richard Biener changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4 Target Milestone|--- |6.4
[Bug c/79428] [6/7 Regression] ICE in c_parser_consume_token, at c/c-parser.c:770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug rtl-optimization/79438] [7 Regression] ICE during RA w/ -O3 (or -Ofast) -funroll-loops for 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79438 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/79432] [7 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79432 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|c |tree-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.0 Summary|[Regression 7] ICE: |[7 Regression] ICE: |verify_ssa failed |verify_ssa failed --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/69823] [6 Regression] internal compiler error: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69823 Richard Biener changed: What|Removed |Added Known to work||7.0.1 Summary|[6/7 Regression] internal |[6 Regression] internal |compiler error: in |compiler error: in |create_pw_aff_from_tree, at |create_pw_aff_from_tree, at |graphite-sese-to-poly.c:445 |graphite-sese-to-poly.c:445 --- Comment #10 from Richard Biener --- Fixed on trunk sofar.
[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436 --- Comment #6 from Freddie Chopin --- > On a newer Intel (or AMD) machine, add -march=naitve and you will > see the same behavior. You are right, adding that switch causes the assert to appear... > VFMA is not just multiply and accumulate but rather fused multiply and add. > The multiplication is done in infinite precision and then the add is done > in that same infinite precision and then a round happens down to double. > Instead of what happens with -ffp-contract=off which is not to used the > fused multiple add instruction which means round between the multiply and > addition. I've read that info already, but in my (limited) understanding subtracting two identical numbers still gives 0 at infinite precision, no matter how you round the result ); But I get your point - somehow after re-arranging the whole sequence, the result got inexact (from my point of view). Any advice how to handle this problem in this particular code? I'd prefer not to just set "-ffp-contract=off" for my whole project, as the toolchain libraries are compiled with contracting enabled anyway (I see A LOT of VFMA in functions like sinf() or cosf()), so that "solution" would be partial at best. Is there any "generic" way to write code that would allow the result to be "correct", possibly by also allowing optimizations which don't change accuracy?
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-09 Ever confirmed|0 |1 --- Comment #31 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #24) > Created attachment 40693 [details] > gcc7-pr79341.patch > > Does the attached patch work for you? Only tested on s390x-linux (64-bit). > The intent is that while __tls_get_addr_internal is intercepted, both > __tls_get_offset and __tls_get_addr_internal interceptors actually call > original real __tls_get_offset, so it should work both with old and new > glibc. I've now filed that patch upstream: https://reviews.llvm.org/D29735 Feel free to comment on it there (especially if you'll be able to test it).
[Bug tree-optimization/79432] [7 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79432
--- Comment #3 from Richard Biener ---
We gimplify this to
fn2 ()
{
int a;
_1 = fn1 ();
_2 = vfork ();
a = _1 + _2;
}
and at CFG construction time try to "fixup" via
fn2 ()
{
int D.1803;
int D.1802;
int a;
[0.00%]:
D.1802 = fn1 ();
[0.00%]:
_1 = D.1802;
[0.00%]:
D.1803 = vfork ();
goto ; [0.00%]
[0.00%]:
ABNORMAL_DISPATCHER (0);
[0.00%]:
_2 = D.1803;
a = _1 + _2;
return;
}
this deals with the abnormal outgoing edges but not the abnormal incoming
edges. That is, we do not replace _1 with D.1802 everywhere but just
adjust it across the call/result set split. Note that before into-SSA
we do not have SSA operands set up and thus can't easily walk immediate
uses of _1.
I believe the issue does not only exist for LHS of stmts that can do abnormal
control flow but any SSA defs that have uses live across such calls. So
a more sustainable fix than
r146168 | rguenth | 2009-04-16 12:45:18 +0200 (Thu, 16 Apr 2009) | 6 lines
2009-04-16 Richard Guenther
PR middle-end/39625
* tree-cfg.c (make_blocks): Split statements with to-be
abnormal SSA names on the lhs.
might be to deal with the situation in into-SSA...
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 Bijan Chokoufe changed: What|Removed |Added CC||bijan at chokoufe dot com --- Comment #18 from Bijan Chokoufe --- Let me point out an idiosyncrasy of our configure script. When no FCFLAGS are defined, it automatically puts FCFLAGS='-O2 -g'. When FCFLAGS are defined, those are taken. This means that the disappearance of the problem with FCFLAGS=-Wall or FCFLAGS=-fno-inline is likely due to the removal of -O2. Valgrind runs are underway...
[Bug c/79431] [6/7 Regression] ICE in get, at cgraph.h:397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79431 --- Comment #2 from Jakub Jelinek --- Obviously it doesn't make any sense to mark automatic variables this way, but sadly OpenMP 4.5 doesn't prohibit that.
[Bug c/79431] [6/7 Regression] ICE in get, at cgraph.h:397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79431 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 40702 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40702&action=edit gcc7-pr79431.patch Untested fix.
[Bug testsuite/79427] g++.dg/tls/thread_local-order2.C fails starting with r245249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427 --- Comment #3 from Dominik Vogt --- The xfail was removed from the test because it caused an XPASS on many systems.
[Bug tree-optimization/79432] [7 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79432 --- Comment #4 from Richard Biener --- I guess the fix will be in the gimplifier instead.
[Bug c++/79429] [6/7 Regression] ICE in add_stmt, at cp/semantics.c:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79429 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 40703 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40703&action=edit gcc7-pr79429.patch Untested fix.
[Bug testsuite/79427] g++.dg/tls/thread_local-order2.C fails starting with r245249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427 --- Comment #4 from Dominik Vogt --- See here for discussion of this bug report: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00666.html And here for discussion of the patch: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00446.html
[Bug c/79428] [6/7 Regression] ICE in c_parser_consume_token, at c/c-parser.c:770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428
--- Comment #5 from Jakub Jelinek ---
The weird thing is that this occurs for many pragmas, but only #pragma omp
ordered seems to ICE:
for i in pr79428-*.c; do echo ===$i===; cat $i; done
===pr79428-1.c===
/* { dg-options "-fopenacc" } */
void
foo ()
{
#pragma acc routine
===pr79428-2.c===
/* { dg-options "-fopenmp" } */
void
foo ()
{
#pragma omp sections
#pragma omp section
===pr79428-3.c===
int i;
#pragma GCC pch_preprocess
===pr79428-4.c===
/* { dg-options "-fcilkplus" } */
#pragma cilk grainsize
===pr79428-5.c===
/* { dg-options "-fopenmp" } */
#pragma omp ordered
===pr79428-6.c===
/* { dg-options "-fopenmp" } */
#pragma omp target
===pr79428-7.c===
/* { dg-options "-fcilkplus" } */
#pragma simd
[Bug rtl-optimization/79437] Redundant move instruction when getting sign bit of double on 32-bit architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79437 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Even -mno-stv doesn't help here, the problem is that for the shift we don't lower DImode operations here until too late (split2) and so EDX:EAX is used for the 64-bit value.
[Bug rtl-optimization/79438] [7 Regression] ICE during RA w/ -O3 (or -Ofast) -funroll-loops for 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79438 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Can't reproduce on powerpc64-linux with -m32, must be SPE specific.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #19 from Bijan Chokoufe --- So in the build with '-O2 -g' (default), valgrind tells us ==8214== Conditional jump or move depends on uninitialised value(s) ==8214==at 0x5300201: __shower_core_MOD_shower_generate_next_isr_branching (shower_core.f90:3089) ==8214==by 0x5306A90: __shower_core_MOD_shower_generate_emissions (shower_core.f90:316) ==8214==by 0x52D3CE6: __shower_MOD_evt_shower_generate_weighted.part.2 (shower.f90:238) ==8214==by 0x52B0BBF: __event_transforms_MOD_evt_generate_unweighted (event_transforms.f90:203) ==8214==by 0x52DCEA5: __events_MOD_event_evaluate_transforms (events.f90:520) ==8214==by 0x52DC247: __events_MOD_event_generate (events.f90:751) ==8214==by 0x5260A2F: __simulations_MOD_simulation_generate (simulations.f90:1639) ==8214==by 0x5285A35: __commands_MOD_cmd_simulate_execute (commands.f90:4501) ==8214==by 0x5267A08: __commands_MOD_command_list_execute (commands.f90:5835) ==8214==by 0x52A84A5: __whizard_MOD_whizard_process_stream (whizard.f90:348) ==8214==by 0x52A7C25: __whizard_MOD_whizard_process_file (whizard.f90:323) ==8214==by 0x4E3EF61: MAIN__ (main.f90:415) ==8214== which is exactely the problematic point we also identified with print debugging, mentioned in the description of this ticket. In the build with '-O0 -g', valgrind does not show this error! So it seems as if the call to integral_over_z_part_isr is optimized away although it is needed to set the variables used in the conditional. The variables are declared as intent(inout) therein.
[Bug testsuite/79356] XPASS in attr-alloc_size-11.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED CC||segher at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #4 from Segher Boessenkool --- I have a patch.
[Bug rtl-optimization/79438] [7 Regression] ICE during RA w/ -O3 (or -Ofast) -funroll-loops for 32-bit BE powerpc target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79438 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 --- Comment #2 from Jakub Jelinek --- powerpc-e500v2-linux-gnuspe is not primary/secondary target -> P4.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #20 from Dominique d'Humieres --- Is this really a regression? I have run 'make check -k' with gfortran 5.4.0, 6.3.0, and a patched trunk at revision r245279. I see respectively 258, 259, and 199 FAILs, and mlm_matching_isr is always failing.
[Bug target/79439] New: Missing nop instruction after recursive call corrupts TOC register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439
Bug ID: 79439
Summary: Missing nop instruction after recursive call corrupts
TOC register
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: ppc64le-redhat-linux
Consider this test case:
int f (void);
void
g (void)
{
}
void
rec (int a)
{
if (f ())
rec (a + 1);
rec (a);
g ();
}
GCC 6.3.1 generates the following code on ppc64le-redhat-linux (Fedora 25):
rec:
.LCF1:
0: addis 2,12,.TOC.-.LCF1@ha
addi 2,2,.TOC.-.LCF1@l
.localentry rec,.-rec
mflr 0
std 31,-8(1)
mr 31,3
std 0,16(1)
stdu 1,-48(1)
bl f
nop
cmpdi 7,3,0
beq 7,.L3
addi 3,31,1
extsw 3,3
bl rec
.L3:
mr 3,31
bl rec
bl g
nop
addi 1,1,48
ld 0,16(1)
ld 31,-8(1)
mtlr 0
blr
.long 0
.byte 0,0,0,1,128,1,0,0
That is, there is no nop instruction the after the “bl rec” instructions. The
ELF v2 ABI requires the presence of this instruction, so that the static linker
can replace it with a load of the saved TOC pointer to restore the original
value of the TOC pointer register.
Apparently, GCC assumes that the call is always to a function in the same
module, so the TOC pointer restore is never needed. But “rec” can be
interposed from another translation unit and the original function definition
can be access through dlsym and executed, so this assumption is incorrect. The
missing TOC pointer restore means that the PLT stubs supplied by the static
linker will not work, and subsequent function calls can crash.
This was originally reported as a glibc bug:
The test case is LAPACK, which is apparently written in Fortran, but I expect
that this is a target issue which exists independent of the front end.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #21 from Jürgen Reuter --- (In reply to Dominique d'Humieres from comment #20) > Is this really a regression? > > I have run 'make check -k' with gfortran 5.4.0, 6.3.0, and a patched trunk > at revision r245279. I see respectively 258, 259, and 199 FAILs, and > mlm_matching_isr is always failing. With make -k you continue irrespective of the fact that some targets could not have made. Do you have OCaml installed? This is needed for that test. Can you post the test results e.g. for the smtest_1 test?
[Bug c/79413] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79413 --- Comment #5 from Jakub Jelinek --- The DECL_EXPR is there, the problem is that gimplify_type_sizes doesn't do anything about it, because is_gimple_sizepos says it is ok: 101 return (expr == NULL_TREE 102 || TREE_CONSTANT (expr) 103 || TREE_CODE (expr) == VAR_DECL 104 || CONTAINS_PLACEHOLDER_P (expr)); and (sizetype) (1 / 0) * 4 has TREE_CONSTANT set on it. Wonder if is_gimple_sizepos shouldn't use is_gimple_min_invariant instead of TREE_CONSTANT or something similar.
[Bug rtl-optimization/75964] insn combiner removes comparison after ABS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=75964 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- > After pass .combine, the 2nd comparison is missing, presumably because > combiner invokes signed overflow on ABS which does not apply because all > computations are performed as unsigned. Then you should have a warning with -Wstrict-overflow; this possibly comes from simplify-rtx.c:simplify_const_relational_operation in this case.
[Bug c/79428] [6/7 Regression] ICE in c_parser_consume_token, at c/c-parser.c:770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428 --- Comment #7 from Marek Polacek --- So should I fix the one spot and add the testcases?
[Bug c/79428] [6/7 Regression] ICE in c_parser_consume_token, at c/c-parser.c:770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428 --- Comment #6 from Marek Polacek --- I think that's because in c_parser_omp_ordered we ate the pragma with c_parser_consume_pragma, so the next token is CPP_PRAGMA_EOL, but e.g. in c_parser_pragma the pragma tokens have not been eaten yet.
[Bug c/79428] [6/7 Regression] ICE in c_parser_consume_token, at c/c-parser.c:770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428 --- Comment #8 from Jakub Jelinek --- Yes. Please add them to c-c++-common where possible (and test on top of the PR79429 patch, because otherwise #pragma omp ordered will fail in C++ for a different reason).
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #22 from Dominique d'Humieres --- > With make -k you continue irrespective of the fact that some targets could > not have made. Without '-k' 'make check' stops at make[5]: *** No rule to make target `test_omega95.f90', needed by `test_omega95.o'. Stop. > Do you have OCaml installed? This is needed for that test. Yes, The OCaml toplevel, version 4.03.0. > Can you post the test results e.g. for the smtest_1 test? Running script ./smtest_1.run ** ** *** FATAL ERROR: Option '--logfile' needs a value ** ** WHIZARD run aborted. ... With no FILE, read standard input. 1,91d0 < ?openmp_logging = false < ?vis_history = false < ?integration_timer = false < seed = 0 < phs_off_shell = 1 < phs_t_channel = 2 < | Process library 'smtest_1_lib': recorded process 'smtest_1_nnh' ...
[Bug c/79413] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79413 --- Comment #6 from Jakub Jelinek --- Created attachment 40704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40704&action=edit gcc7-pr79413.patch Untested fix. Let's see what Ada will say to this.
[Bug fortran/79440] New: internal compiler error: in fold_convert_loc, at fold-const.c:2373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79440 Bug ID: 79440 Summary: internal compiler error: in fold_convert_loc, at fold-const.c:2373 Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: for2008 at web dot de Target Milestone: --- Created attachment 40705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40705&action=edit Each module was originally in a separate file. The program is planned to by used for a finite element program. There a groups, that contain elements. Each element has a material. Hi, the example shows a problem with the constructor of a derived class in line 180 in connection with line 168. If I change in line 168 from type(CMaterial) to class(CMaterial), the program works. The attached version with type(CMaterial) crashes with internal compiler error. Programm compiles with no errors, but executable is not created. I'm not sure what the Fortran standard requires, but an internal compiler error shouldn't happen. Tested with, both behave the same: Ubuntu 16.10 with gfortran 6.2.0 windows 10, MSYS2, mingw64, gfortran 6.3.0 By the way: programm runs with no errors with Intel ifort. Full error message: internal compiler error: in fold_convert_loc, at fold-const.c:2373 libbacktrace could not find executable to open Please submit a full bug report Thanks
[Bug fortran/79434] [submodules] separate module procedure breaks encapsulation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79434 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-09 CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paul Thomas --- It's mine! I'll put it in my schedule for some time next week, after Tuesday. Thanks for the report. Paul
[Bug tree-optimization/69675] [6/7 Regression] [graphite] ICE: verify_ssa failed (definition in block 42 does not dominate use in block 34)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675
--- Comment #9 from Richard Biener ---
Yeah, seems to be gone with ISL 0.18 here as well... (but with 0.16.1 I can
still reproduce it). ISL 0.18 doesn't do anything to the loop. ISL 0.16.1
just did some IV transforms it seems:
[scheduler] original ast:
for (int c0 = 0; c0 <= -P_14; c0 += 1)
for (int c1 = 0; c1 <= 3; c1 += 1) {
S_5(c0, c1);
if (c1 <= 2)
S_6(c0, c1);
}
[scheduler] AST generated by isl:
for (int c0 = 0; c0 <= -P_14; c0 += 1)
for (int c1 = 3 * c0; c1 <= 3 * c0 + 3; c1 += 1) {
S_5(c0, -3 * c0 + c1);
if (3 * c0 + 2 >= c1)
S_6(c0, -3 * c0 + c1);
}
and with ISL 0.18 we have
[scheduler] isl optimized schedule is identical to the original schedule.
for (int c0 = 0; c0 <= -P_14; c0 += 1)
for (int c1 = 0; c1 <= 3; c1 += 1) {
S_5(c0, c1);
if (c1 <= 2)
S_6(c0, c1);
}
and eventually code generation is not happy with the changed form
(-fgraphite-identity is fine).
Sebastian, any comment? I think we could still for example require current ISL
for GCC 6 (0.18 or maybe 0.17.1). Or at least drop support for the current
legacy.
[Bug tree-optimization/69728] [6/7 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728 --- Comment #8 from Richard Biener --- removing the assert doesn't fix it (ISL complains). This is all ISL stuff I don't understand, somebody else needs to look at this - the SCOP is quite regular. Confirmed with ISL 0.18.
[Bug tree-optimization/70390] [6 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70390 Richard Biener changed: What|Removed |Added Known to work||7.0.1 Summary|[6/7 Regression] internal |[6 Regression] internal |compiler error: in |compiler error: in |copy_loop_close_phi_args, |copy_loop_close_phi_args, |at |at |graphite-isl-ast-to-gimple. |graphite-isl-ast-to-gimple. |c:2114 |c:2114 --- Comment #9 from Richard Biener --- Latent on trunk I guess.
[Bug ada/79403] Installation of Ada compiler gets permissions wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-02-09 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- > "make install" of the Ada compiler installs the contests of the adainclude > and adalib directories with incorrect permissions. The installed compiler is > only usable by the user who installed it: I'm a little skeptical, nothing has changed for years and this apparently works for everyone else. What are the permissions in the build tree? > For some reason, world read access is removed by the installation routines. The only thing they do in to remove the 'w' and 'x' permissions.
[Bug target/79439] Missing nop instruction after recursive call corrupts TOC register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439 --- Comment #1 from Segher Boessenkool --- What command line options does this need? I get different assembly (also with GCC 6), since GCC recognises that rec can never return: .globl rec .type rec, @function rec: .LCF1: 0: addis 2,12,.TOC.-.LCF1@ha addi 2,2,.TOC.-.LCF1@l .localentry rec,.-rec mflr 0 std 31,-8(1) mr 31,3 std 0,16(1) stdu 1,-48(1) .p2align 4,,15 .L3: bl f nop cmpdi 7,3,0 beq 7,.L3 addi 3,31,1 extsw 3,3 bl rec .long 0 .byte 0,0,0,1,128,1,0,0
[Bug c/79413] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79413 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #7 from Eric Botcazou --- > Untested fix. Let's see what Ada will say to this. Presumably nothing, many tests like this on TREE_CONSTANT are bogus and want to test for _CST nodes instead.
[Bug target/79439] Missing nop instruction after recursive call corrupts TOC register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439 --- Comment #2 from Florian Weimer --- (In reply to Segher Boessenkool from comment #1) > What command line options does this need? Sorry, I used -O2 -fpic. Indeed, GCC seems to perform target-independent optimizations based on an assumption that the recursive call calls the same function as defined in the translation unit. If this is the desired behavior, the proper fix would be to use a local reference for the recursive call. This would make those optimizations consistent, and interposition would work to some extent. Of course, the recursive calls wouldn't be interposed anymore, but the TOC corruption would at least be gone.
[Bug target/79439] Missing nop instruction after recursive call corrupts TOC register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439 --- Comment #3 from Segher Boessenkool --- -fpic does the trick. Confirmed.
[Bug tree-optimization/71351] [7 Regression] ICE: Segmentation fault (graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71351 Richard Biener changed: What|Removed |Added CC||spop at gcc dot gnu.org --- Comment #8 from Richard Biener --- Also ICEs with -fgraphite-identity. The issue seems to be that ISL creates a new loop guard but the loop has a loop-close PHI node and we fail to generate/know the value to use on the edge that skips the loop. The condition we try to insert is _19 > 0 (that's trivially true by means of a dominating condition). Not sure how this is supposed to work for reductions when the orginal loops guard is not in the SESE region. That guard looks like _19 = *nc_18(D); if (_19 <= 0) ... so the BB is rejected because _19 = *nc_18(D) isn't a valid stmt. So for this case it might help if we'd split that block... Anyway, it looks like we have to fail code generation here somehow... (no good idea how).
[Bug ada/79421] gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-09 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > What is the purpose of the test case, what does a failure mean and what can > be done to determine its cause? The purpose is to check that pointer-to-nested-functions no longer use stack trampolines in Ada, which then force it to be made executable; the failure means that they still use it. The cause is a missing definition of: -- Target Hook: int TARGET_CUSTOM_FUNCTION_DESCRIPTORS This hook should be defined to a power of 2 if the target will benefit from the use of custom descriptors for nested functions instead of the standard trampolines. Such descriptors are created at run time on the stack and made up of data only, but they are non-standard so the generated code must be prepared to deal with them. This hook should be defined to 0 if the target uses function descriptors for its standard calling sequence, like for example HP-PA or IA-64. Using descriptors for nested functions eliminates the need for trampolines that reside on the stack and require it to be made executable. The value of the macro is used to parameterize the run-time identification scheme implemented to distinguish descriptors from function addresses: it gives the number of bytes by which their address is misaligned compared with function addresses. The value of 1 will generally work, unless it is already reserved by the target for another purpose, like for example on ARM.
[Bug tree-optimization/79432] [7 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79432
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Richard Biener ---
Similar testcase a patch I have for the first doesn't fix:
int fn1 (void);
int __attribute__((returns_twice)) vfork (void);
void fn2 ()
{
int a;
a = fn1() + 1 + vfork();
}
That patch:
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 245299)
+++ gcc/gimplify.c (working copy)
@@ -12150,7 +12150,15 @@ gimplify_expr (tree *expr_p, gimple_seq
TMP. First, make sure that the expression has a type so that
it can be assigned into a temporary. */
gcc_assert (!VOID_TYPE_P (TREE_TYPE (*expr_p)));
- *expr_p = get_formal_tmp_var (*expr_p, pre_p);
+ /* If we assign the result of a call if that call can make an abnormal
+ goto we can't use an SSA name for the result as uses may not
+dominate the definition in this case. */
+ if (gimplify_ctxp->into_ssa
+ && TREE_CODE (*expr_p) == CALL_EXPR
+ && ! (call_expr_flags (*expr_p) & (ECF_LEAF | ECF_CONST | ECF_PURE)))
+ *expr_p = get_initialized_tmp_var (*expr_p, pre_p, NULL, false);
+ else
+ *expr_p = get_formal_tmp_var (*expr_p, pre_p);
}
else
{
but it's not enough to look at calls as with the above testcase and the patch
we still have
[0.00%]:
D.1804 = fn1 ();
[0.00%]:
D.1802 = D.1804;
_1 = D.1802 + 1;
[0.00%]:
D.1805 = vfork ();
goto ; [0.00%]
[0.00%]:
D.1803 = D.1805;
a = D.1803 + _1;
return;
so it's really about having _any_ abnormal edge receiver inside an expression.
The idea with SSA at gimplification was that we know we only have single uses
and this use is in the same BB as the definition. All user var sets do not
get SSA vars.
Eventually looking at calls _is_ enough if we can emit them first, thus,
reorder the GIMPLE from
D.1802 = fn1 ();
_1 = D.1802 + 1;
D.1803 = vfork ();
a = D.1803 + _1;
to
D.1802 = fn1 ();
D.1803 = vfork ();
_1 = D.1802 + 1;
a = D.1803 + _1;
...
[Bug target/79439] Missing nop instruction after recursive call corrupts TOC register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-09 Ever confirmed|0 |1 --- Comment #4 from Segher Boessenkool --- We have (in rs6000/predicates.md): ;; Return 1 if the operand is a SYMBOL_REF for a function known to be in ;; this file. (define_predicate "current_file_function_operand" (and (match_code "symbol_ref") (match_test "(DEFAULT_ABI != ABI_AIX || SYMBOL_REF_FUNCTION_P (op)) && (SYMBOL_REF_LOCAL_P (op) || op == XEXP (DECL_RTL (current_function_decl), 0)) && !((DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2) && (SYMBOL_REF_EXTERNAL_P (op) || SYMBOL_REF_WEAK (op)))"))) so this seems to be on purpose.
[Bug tree-optimization/79411] [5/6/7 Regression] ICE: SSA corruption (fail_abnormal_edge_coalesce)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79411 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 40706 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40706&action=edit gcc7-pr79411.patch Untested fix. In the future we could revert it after making sure all the spots that can move some SSA_NAME uses would be adjusted and covered by testcases (create non-(ab) SSA_NAME set to the (ab) one at the original use point and use it elsewhere), but for now it seems too much work for something rarely used.
[Bug target/79439] Missing nop instruction after recursive call corrupts TOC register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439 --- Comment #5 from David Edelsohn --- current_file_function_operand probably needs to add a test for flag_semantic_interposition when the ABI mandates interpolation.
[Bug target/79439] Missing nop instruction after recursive call corrupts TOC register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439 --- Comment #6 from Jakub Jelinek --- (In reply to David Edelsohn from comment #5) > current_file_function_operand probably needs to add a test for > flag_semantic_interposition when the ABI mandates interpolation. Maybe better just call decl_replaceable_p (current_function_decl) if not SYMBOL_REF_LOCAL_P (or something similar).
[Bug ada/79441] New: gnat.dg/pack9.adb fails since r 236279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79441 Bug ID: 79441 Summary: gnat.dg/pack9.adb fails since r 236279 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com CC: ebotcazou at gcc dot gnu.org, krebbel at gcc dot gnu.org Target Milestone: --- Host: s390x Target: s390x On s390x, the test gnat.dg/pack9.adb fails on s390x (--with-arch=zEC12) since this commit: -- Author: ebotcazou AuthorDate: Mon May 16 11:08:53 2016 + Commit: ebotcazou CommitDate: Mon May 16 11:08:53 2016 + * doc/gnat_rm/implementation_defined_attributes.rst (Scalar_Storage_Order): Adjust restriction for packed array types. * einfo.ads (Is_Bit_Packed_Array): Adjust description. (Is_Packed): Likewise. (Is_Packed_Array_Impl_Type): Likewise. (Packed_Array_Impl_Type): Likewise. * exp_ch4.adb (Expand_N_Indexed_Component): Do not do anything special if the prefix is not a packed array implemented specially. * exp_ch6.adb (Expand_Actuals): Expand indexed components only for bit-packed array types. * exp_pakd.adb (Install_PAT): Set Is_Packed_Array_Impl_Type flag on the PAT before analyzing its declaration. (Create_Packed_Array_Impl_Type): Remove redundant statements. * freeze.adb (Check_Component_Storage_Order): Reject packed array components only if they are bit packed. (Freeze_Array_Type): Fix logic detecting bit packing and do not bit pack for composite types whose size is multiple of a byte. Create the implementation type for packed array types only when it is needed, i.e. bit packing or packing because of holes in index types. Make sure the Has_Non_Standard_Rep and Is_Packed flags agree. * gcc-interface/gigi.h (make_packable_type): Add MAX_ALIGN parameter. * gcc-interface/decl.c (gnat_to_gnu_entity) : Call maybe_pad_type instead of building the padding type manually. (gnat_to_gnu_entity) : Do not assert that Packed_Array_Impl_Type is present for packed arrays. (gnat_to_gnu_component_type): Also handle known alignment for packed types by passing it to make_packable_type. * gcc-interface/utils.c (make_packable_type): Add MAX_ALIGN parameter and deal with it in the array case. Adjust recursive call. Simplify computation of new size and cap the alignment to BIGGEST_ALIGNMENT. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236279 138bc75d-0d04-0410-96 -- with FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized "gnat_rcheck" (The string "gnat_rcheck" appear in the .s file.) The test was build with $ ~/build/gcc/gnatmake --GCC=~/build/gcc/xgcc --GNATBIND=~/build/gcc/gnatbind --GNATLINK=~/build/gcc/gnatlink -cargs -B~/build/gcc -largs --GCC=~/build/gcc/xgcc -B~/build/gcc -m64 -margs --RTS=~/build/s390x-ibm-linux-gnu/./libada -q -f ~/gcc/gcc/testsuite/gnat.dg/pack9.adb -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -gnatp -fdump-tree-optimized -c -u -S -m64 -o pack9.s
[Bug ada/79403] Installation of Ada compiler gets permissions wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403 --- Comment #3 from Dominik Vogt --- The files are symlinks in the build tree, mode 640 in the source tree (like everything else) and are installed with "cp -p" which explains the broken permissions. Most other things are installed "install -m 644". > I'm a little skeptical, nothing has changed for years and this apparently > works for everyone else. Perhaps because few people install a system Ada compiler from sources.
[Bug fortran/79440] internal compiler error: in fold_convert_loc, at fold-const.c:2373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79440 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.9.3 up to trunk (7.0). Compiling the test with 4.8.5 gives the error allocate( mygroup(1)%el(10), source=CBTHII( 12, 1, mymaterial, 1.5) ) 1 Error: Can't convert TYPE(cmaterial) to CLASS(cmaterial) at (1) The change occurred between revisions r201266 (2013-07-26, error) and r201631 (2013-08-09, ICE). Backtrace is frame #11: 0x000100700c38 f951`fold_convert_loc(loc=0, type=0x0001445f13f0, arg=) + 1544 at fold-const.c:2361 frame #12: 0x00010011a6fc f951`::gfc_trans_subcomponent_assign(dest=0x000144600a20, cm=0x00014263be20, expr=0x000142650f90, sym=, init=) + 892 at trans-expr.c:7399 frame #13: 0x00010011b506 f951`gfc_trans_structure_assign(dest=0x000144600990, expr=0x000142658890, init=false, coarray=false) + 262 at trans-expr.c:7578 frame #14: 0x00010011ad5b f951`::gfc_trans_subcomponent_assign(dest=0x000144600990, cm=0x00014264ee00, expr=0x000142658890, sym=0x00014264ce60, init=) + 2523 at trans-expr.c:7416 frame #15: 0x00010011b506 f951`gfc_trans_structure_assign(dest=0x0001445f5ea0, expr=0x000142651110, init=true, coarray=false) + 262 at trans-expr.c:7578 frame #16: 0x00010011c1cd f951`gfc_conv_structure(se=0x7fff5fbfedc0, expr=0x000142651110, init=0) + 621 at trans-expr.c:7645 frame #17: 0x00010011c78b f951`gfc_conv_expr_reference(se=0x7fff5fbfedc0, expr=0x000142651110) + 107 at trans-expr.c:7928 frame #18: 0x000100156475 f951`gfc_trans_allocate(code=0x0001426511d0) + 7173 at trans-stmt.c:5642 frame #19: 0x0001000e09f8 f951`::trans_code(code=0x0001426511d0, cond=0x) + 1496 at trans.c:1965 frame #20: 0x0001001098c5 f951`gfc_generate_function_code(ns=) + 949 at trans-decl.c:6296 frame #21: 0x000100094eac f951`gfc_parse_file() + 1788 at parse.c:6051 frame #22: 0x0001000dcdf7 f951`::gfc_be_parse_file() + 71 at f95-lang.c:204 frame #23: 0x000100a3214a f951`::compile_file() + 58 at toplev.c:463 frame #24: 0x000100e5f1e3 f951`toplev::main(this=0x7fff5fbff290, argc=, argv=) + 3763 at toplev.c:1983 frame #25: 0x000100e60709 f951`main(argc=2, argv=0x7fff5fbff2d8) + 41 at main.c:39 The ICE occurs at default: if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (orig)) return fold_build1_loc (loc, NOP_EXPR, type, arg); gcc_unreachable ();
[Bug target/79436] [ARM Cortex-M4F] VFMA used in place of subtraction gives inexact results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #7 from Richard Earnshaw ---
double __attribute__((optimize("fp-contract=off"))) x (double a, double b,
double c)
{
return a*b + c;
}
You might also need to mark the function as no-inline to prevent it being
inlined into functions where the default still applies.
[Bug ada/79421] gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 --- Comment #2 from Dominik Vogt --- And on a target not using function descriptors otherwise, #define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 affects only Ada?
[Bug c/79431] [6/7 Regression] ICE in get, at cgraph.h:397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79431 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Feb 9 14:01:44 2017 New Revision: 245302 URL: https://gcc.gnu.org/viewcvs?rev=245302&root=gcc&view=rev Log: PR c/79431 * gimplify.c (gimplify_adjust_omp_clauses): Ignore "omp declare target link" attribute unless is_global_var. * omp-offload.c (find_link_var_op): Likewise. c/ * c-parser.c (c_parser_omp_declare_target): Don't invoke symtab_node::get on automatic variables. cp/ * parser.c (cp_parser_oacc_declare): Formatting fix. (cp_parser_omp_declare_target): Don't invoke symtab_node::get on automatic variables. testsuite/ * c-c++-common/gomp/pr79431.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr79431.c Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/gimplify.c trunk/gcc/omp-offload.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/79432] [7 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79432
--- Comment #6 from Richard Biener ---
int fn1 (void);
int __attribute__((returns_twice)) vfork (void);
void fn2 ()
{
int a;
a = fn1() + 2 + (vfork() + 1 + vfork());
}
live over two vfork calls.
[Bug c++/79429] [6/7 Regression] ICE in add_stmt, at cp/semantics.c:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79429 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Feb 9 14:06:58 2017 New Revision: 245303 URL: https://gcc.gnu.org/viewcvs?rev=245303&root=gcc&view=rev Log: PR c++/79429 * parser.c (cp_parser_omp_ordered): Don't check for non-pragma_stmt non-pragma_compound context here. (cp_parser_omp_target): Likewise. (cp_parser_pragma): Don't call push_omp_privatization_clauses and parsing for ordered and target omp pragmas in non-pragma_stmt non-pragma_compound contexts. * c-c++-common/gomp/pr79429.c: New test. * g++.dg/gomp/pr79429.C: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr79429.c trunk/gcc/testsuite/g++.dg/gomp/pr79429.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c/79413] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79413 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Thu Feb 9 14:26:40 2017 New Revision: 245304 URL: https://gcc.gnu.org/viewcvs?rev=245304&root=gcc&view=rev Log: PR c/79413 * gimplify.h (is_gimple_sizepos): Only test for INTEGER_CST constants, not arbitrary TREE_CONSTANT. * gcc.c-torture/compile/pr79413.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr79413.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.h trunk/gcc/testsuite/ChangeLog
[Bug c++/79429] [6 Regression] ICE in add_stmt, at cp/semantics.c:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79429 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression] ICE in |[6 Regression] ICE in |add_stmt, at|add_stmt, at |cp/semantics.c:385 |cp/semantics.c:385 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/79431] [6 Regression] ICE in get, at cgraph.h:397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79431 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression] ICE in |[6 Regression] ICE in get, |get, at cgraph.h:397|at cgraph.h:397 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/79413] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79413 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug fortran/79230] [7 Regression] [OOP] Run time error: double free or corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230 --- Comment #28 from Jürgen Reuter --- (In reply to vehre from comment #27) > Waiting on week for regression reports before closing. From our side this is ok. No regression, except for the special problem in PR79430 most likely unrelated to this.
[Bug c++/79442] New: GCC 5.4 does not fully support N3652 (Relaxing constraints on constexpr functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79442
Bug ID: 79442
Summary: GCC 5.4 does not fully support N3652 (Relaxing
constraints on constexpr functions)
Product: gcc
Version: 5.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zuverliantellabrach at hotmail dot com
Target Milestone: ---
GCC 5 is supposed to provide full support for N3652, but the code below does
not compile under GCC 5.4 (it does, however, compile under GCC 6.1).
#include
template
constexpr bool allTrue(Ts... ts) {
const bool bs[]={ts...};
for(size_t i=0; i
struct S {S() {std::cout<{};
return 0;
}
[Bug tree-optimization/69675] [6/7 Regression] [graphite] ICE: verify_ssa failed (definition in block 42 does not dominate use in block 34)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675
--- Comment #10 from Sebastian Pop ---
(In reply to Richard Biener from comment #9)
> Yeah, seems to be gone with ISL 0.18 here as well... (but with 0.16.1 I can
> still reproduce it). ISL 0.18 doesn't do anything to the loop. ISL 0.16.1
> just did some IV transforms it seems:
>
> [scheduler] original ast:
> for (int c0 = 0; c0 <= -P_14; c0 += 1)
> for (int c1 = 0; c1 <= 3; c1 += 1) {
> S_5(c0, c1);
> if (c1 <= 2)
> S_6(c0, c1);
> }
>
> [scheduler] AST generated by isl:
> for (int c0 = 0; c0 <= -P_14; c0 += 1)
> for (int c1 = 3 * c0; c1 <= 3 * c0 + 3; c1 += 1) {
> S_5(c0, -3 * c0 + c1);
I don't know why isl started the inner loop at 3*c0:
In the end we have the identity for the array subscript: 3*c0 - 3*c0 = 0
Could be a bug in the older isl.
> if (3 * c0 + 2 >= c1)
> S_6(c0, -3 * c0 + c1);
> }
>
> and with ISL 0.18 we have
>
> [scheduler] isl optimized schedule is identical to the original schedule.
> for (int c0 = 0; c0 <= -P_14; c0 += 1)
> for (int c1 = 0; c1 <= 3; c1 += 1) {
> S_5(c0, c1);
> if (c1 <= 2)
> S_6(c0, c1);
> }
>
> and eventually code generation is not happy with the changed form
> (-fgraphite-identity is fine).
>
> Sebastian, any comment? I think we could still for example require current
> ISL
> for GCC 6 (0.18 or maybe 0.17.1). Or at least drop support for the current
> legacy.
I would like moving away from the older isl versions: newer isl have fewer
bugs, and people also worked on making isl faster.
Moving to a newer isl would allow to also clean up the #ifdef's from the
graphite-*.c files which will make the code easier to read.
[Bug c++/79442] GCC 5.4 does not fully support N3652 (Relaxing constraints on constexpr functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79442 --- Comment #1 from Ose Pedro --- To be more precise, it does not work under GCC 5.4.0, but does work under GCC 6.1.0. I haven't been able to find a GCC cloud service that provides 5.4.1, so haven't been able to test that version.
[Bug target/79439] Missing nop instruction after recursive call corrupts TOC register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #7 from Alexander Monakov --- Note that there's also a bug in the middle-end since gcc makes an assumption that such calls are always self-recursive on any target; see comments 6-9 in bug 56727.
[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727 --- Comment #10 from Jakub Jelinek --- (In reply to Yuri Gribov from comment #9) > (In reply to Alexander Monakov from comment #8) > > Well, if my argument is correct, then GCC generates wrong code for the very > > first example in comment #0. > > I believe it does (see my #5, most probly author of some pass failed to > check for interposition). Note that simple recursive factorial is expanded > to loop too which is a more impressive instance of this bug. > > > To my knowledge, that > > is the sole instance where optimization doesn't fully honor ELF > > interposition possibility. > > +1 Don't we also inline any beneficial inline functions at -O3 even if they could be interposed (definitely not suggesting we stop doing that, that would totally kill compiler performance)? I'd say we shouldn't care about the semantic interposition for self-recursion either, just make sure we don't crash on such code.
[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727 --- Comment #11 from Florian Weimer --- (In reply to Jakub Jelinek from comment #10) > Don't we also inline any beneficial inline functions at -O3 even if they > could be interposed (definitely not suggesting we stop doing that, that > would totally kill compiler performance)? I'd say we shouldn't care about > the semantic interposition for self-recursion either, just make sure we > don't crash on such code. At least we should make things consistent and use direct calls for all local locals which could potentially be subject to inlining. Otherwise, interposition could break with apparently unrelated code changes.
[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727 --- Comment #12 from Yuri Gribov --- (In reply to Jakub Jelinek from comment #10) > (In reply to Yuri Gribov from comment #9) > > (In reply to Alexander Monakov from comment #8) > > > Well, if my argument is correct, then GCC generates wrong code for the > > > very > > > first example in comment #0. > > > > I believe it does (see my #5, most probly author of some pass failed to > > check for interposition). Note that simple recursive factorial is expanded > > to loop too which is a more impressive instance of this bug. > > > > > To my knowledge, that > > > is the sole instance where optimization doesn't fully honor ELF > > > interposition possibility. > > > > +1 > > Don't we also inline any beneficial inline functions at -O3 even if they > could be interposed (definitely not suggesting we stop doing that, that > would totally kill compiler performance)? Inlining inline functions is fine due to ODR rule.
[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727 --- Comment #13 from Jakub Jelinek --- (In reply to Yuri Gribov from comment #12) > Inlining inline functions is fine due to ODR rule. ODR doesn't apply just to inline functions. So all semantic interposition, except for the case when both functions do the very same thing, is ODR violation. But many programs and libraries rely on it heavily.
[Bug middle-end/56727] Recursive call goes through the PLT unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
--- Comment #14 from Jan Hubicka ---
For the draft patch you need to check for aliases. If global symbol is indeed
the only way to reach the function, then the transformation is IMO valid.
As for tailcall, we have recursive_call_p predicate that uses
symtab_node::semantically_equivalent_p which returns true, because it is called
for t and t. It is valid for testcase as written, because we know there is no
alias.
However
void f(int b)
{
f(0);
}
void g(int b) __attribute__((alias(("f";
is indeed misopitmized and the bug is that recursive_call_p needs to check all
aliases of the function being semantically equivalent to function itself. I
will fix that.
For the optimization redirecting to noninterposable aliases, I would be fine
with the patch if it was extended by the check verifying that there is at most
one externally visible symbol aliasing the definition or that they are all
non-interposable.
Honza
[Bug go/79443] New: libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443 Bug ID: 79443 Summary: libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX) Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: vogt at linux dot vnet.ibm.com CC: cmang at google dot com, krebbel at gcc dot gnu.org Target Milestone: --- Host: s390x Target: s390x Currently (r245298) there are some libgo/math test failures on s390x: -- var CoshNoVec = cosh ^ export_s390x_test.go:12:17: error: reference to undefined name 'sinh' var SinhNoVec = sinh ^ export_s390x_test.go:13:17: error: reference to undefined name 'tanh' var TanhNoVec = tanh ^ export_s390x_test.go:14:13: error: reference to undefined name 'hasVX' var HasVX = hasVX ^ --
[Bug ada/79441] [7 regression] gnat.dg/pack9.adb fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79441 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-09 Host|s390x | Target Milestone|--- |7.0 Summary|gnat.dg/pack9.adb fails |[7 regression] |since r 236279 |gnat.dg/pack9.adb fails Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Confirmed, only a missed optimization but needs to fixed at some point.
[Bug ada/79441] [7 regression] gnat.dg/pack9.adb fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79441 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Investigating.
[Bug debug/79444] New: Inconsistent use of DW_OP_piece for vector registers on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79444
Bug ID: 79444
Summary: Inconsistent use of DW_OP_piece for vector registers
on s390x
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: arnez at linux dot vnet.ibm.com
Target Milestone: ---
GCC emits DW_OP_piece for vector registers on s390x in (at least) two
different incompatible ways:
(1) When describing a float field in a structure that was optimized into a
floating-point register:
extern void do_something (float a, float b, float s, float p);
void foo (float a, float b)
{
struct { float a; float b; } s = { a, b };
do_something (a, b, s.a + s.b, s.a * s.b);
}
Compiling the above with "gcc -march=z13 -O3 -g" yields a location list
for foo's variable 's' with an entry like this:
(DW_OP_reg16 (f0); DW_OP_piece: 4; DW_OP_reg17 (f2); DW_OP_piece: 4)
Here the piece operations refer to the *upper* bytes of the floating-point
registers f0 and f2 (aka v0 and v2).
(2) When describing an __int128 bit field that was optimized into a vector
register:
extern void do_something (__int128);
void foo (__int128 x, __int128 y)
{
struct {
unsigned __int128 p: 32;
unsigned __int128 a: 96;
} w = {0, x};
do_something (w.a + y);
}
Compiling the above code with "gcc -march=z13 -O3 -g" yields a location
list for foo's variable 'w' with an entry like this:
(DW_OP_lit0; DW_OP_stack_value; DW_OP_piece: 4; DW_OP_reg16 (f0);
DW_OP_piece: 12)
And here the latter piece operation refers to the *lower* bytes of the vector
register v0.
[Bug go/79443] libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443 --- Comment #1 from Ian Lance Taylor --- Created attachment 40707 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40707&action=edit Possible patch Can you check whether this patch fixes the problem? Thanks.
[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 --- Comment #6 from Jan Hubicka --- This is all bit about luck. We have big_speedup hack that lets us to bypass inline-insns-auto when we know the combination caller+callee improve by given precentage. Because we inline more, caller is now bigger and slower and because we early optimize better callee is faster, so overall speedup is smaller. There are two extra issues with propagating. I will simply fix them and drop the big speedup percentage from 10% to 8%. Honza
[Bug c/79428] [6/7 Regression] ICE in c_parser_consume_token, at c/c-parser.c:770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Thu Feb 9 17:07:26 2017 New Revision: 245309 URL: https://gcc.gnu.org/viewcvs?rev=245309&root=gcc&view=rev Log: PR c/79428 * c-parser.c (c_parser_omp_ordered): Call c_parser_skip_to_pragma_eol instead of c_parser_skip_until_found. * c-c++-common/cilk-plus/CK/pr79428-4.c: New test. * c-c++-common/cilk-plus/CK/pr79428-7.c: New test. * c-c++-common/goacc/pr79428-1.c: New test. * c-c++-common/gomp/pr79428-2.c: New test. * c-c++-common/gomp/pr79428-5.c: New test. * c-c++-common/gomp/pr79428-6.c: New test. * c-c++-common/pr79428-3.c: New test. Added: trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr79428-4.c trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr79428-7.c trunk/gcc/testsuite/c-c++-common/goacc/pr79428-1.c trunk/gcc/testsuite/c-c++-common/gomp/pr79428-2.c trunk/gcc/testsuite/c-c++-common/gomp/pr79428-5.c trunk/gcc/testsuite/c-c++-common/gomp/pr79428-6.c trunk/gcc/testsuite/c-c++-common/pr79428-3.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/testsuite/ChangeLog
[Bug c/79428] [6 Regression] ICE in c_parser_consume_token, at c/c-parser.c:770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79428 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[6/7 Regression] ICE in |[6 Regression] ICE in |c_parser_consume_token, at |c_parser_consume_token, at |c/c-parser.c:770|c/c-parser.c:770 --- Comment #10 from Marek Polacek --- Fixed.
[Bug ada/79421] gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 --- Comment #3 from Eric Botcazou --- > And on a target not using function descriptors otherwise, > > #define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 > > affects only Ada? It affects languages defining LANG_HOOKS_CUSTOM_FUNCTION_DESCRIPTORS to true, which indeed boils down to Ada as of yet.
[Bug ada/79445] New: Address clause on named number gives Assert_Failure in the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79445 Bug ID: 79445 Summary: Address clause on named number gives Assert_Failure in the compiler Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: georggcc at googlemail dot com Target Milestone: --- procedure Address_Clause_on_Named_Number is C : constant := 5 with Address => Anything; begin null; end ; $ gcc -c -gnatl -gnatwa -gnatd.n address_clause_on_named_number.adb /home/bauhaus/opt/gcc-7/lib/gcc/x86_64-pc-linux-gnu/7.0.0/adainclude/system.ads GNAT 7.0.0 20161104 (experimental) [trunk revision 241862] Copyright 1992-2016, Free Software Foundation, Inc. address_clause_on_named_number.adb +===GNAT BUG DETECTED==+ | 7.0.0 20161104 (experimental) [trunk revision 241862] (x86_64-pc-linux-gnu) | | Assert_Failure aspects.adb:647 | | Error detected at address_clause_on_named_number.adb:2:39| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). address_clause_on_named_number.adb raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : namet.adb:146
[Bug go/79443] libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443
--- Comment #2 from Dominik Vogt ---
Yes, that fixes it. Now there's another one in crypto/sha256. Do you want me
to open another bug report for that?
--
fallback_test.go:19:5: error: reference to undefined name 'useAsm'
if useAsm == false {
^
fallback_test.go:22:2: error: reference to undefined name 'useAsm'
useAsm = false
^
fallback_test.go:23:17: error: reference to undefined name 'useAsm'
defer func() { useAsm = true }()
^
FAIL: crypto/sha256
--
[Bug libstdc++/79433] __has_include does not conform to SD-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement --- Comment #12 from Jonathan Wakely --- (In reply to Marc Mutz from comment #9) > __has_include these days is defined by SD-6, Nope, it's defined normatively in the C++17 draft not SD-6, and it says a "has-include-expression evaluates to 1 if the search for the source file succeeds, and to 0 if the search fails." That is very clear, and we do exactly that. The intended use case in SD-6 is not relevant, the C++ draft standard is clear, and we conform to it.
[Bug c++/79442] GCC 5.4 does not fully support N3652 (Relaxing constraints on constexpr functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79442 --- Comment #2 from Jonathan Wakely --- It's true that C++14 support is incomplete in GCC 5, but this is very unlikely to change. In other words, this bug should be closed as RESOLVED FIXED by GCC 6.
[Bug c++/79442] GCC 5.4 does not fully support N3652 (Relaxing constraints on constexpr functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79442 --- Comment #3 from Ose Pedro --- (In reply to Jonathan Wakely from comment #2) > It's true that C++14 support is incomplete in GCC 5, but this is very > unlikely to change. In other words, this bug should be closed as RESOLVED > FIXED by GCC 6. Oh ok. In that case, the "C++ Language Features" table on https://gcc.gnu.org/projects/cxx-status.html#cxx14 should be updated to reflect this. Is this the right bug tracker for GCC website change requests?
[Bug go/79443] libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443 --- Comment #3 from Ian Lance Taylor --- Created attachment 40708 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40708&action=edit crypto patch This patch may fix the crypto/sha256 problem. Any other problems? `make check-target-libgo` should show all of them. No need to open separate bugs for each one.
[Bug c++/79442] GCC 5.4 does not fully support N3652 (Relaxing constraints on constexpr functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79442 --- Comment #4 from Jonathan Wakely --- (In reply to Ose Pedro from comment #0) > GCC 5 is supposed to provide full support for N3652, but the code below does > not compile under GCC 5.4 (it does, however, compile under GCC 6.1). It compiles fine using any 5.x release, even 5.1.0, what error do you get? You need to use -std=gnu++14 or -std=c++14, because N3652 is a C++14 feature. I don't see a problem with the C++ status page.
[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-09 Summary|__has_include does not |__has_include() |conform to SD-6 |is true but #include gives #error when ||-std=old Ever confirmed|0 |1 --- Comment #13 from Jonathan Wakely --- Even SD-6 has a similar specification: The has-include-expression is replaced by the pp-number 1 if the search for the source file succeeds, and by the pp-number 0 if the search fails. It says nothing about whether inclusion would succeed, only whether the search for the file succeeds. It's implementation-defined how the search for source files is done. I'll confirm this as an enhancement for libstdc++, but insisting it's not conforming is simply wrong.
[Bug ada/79421] gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 --- Comment #4 from Dominik Vogt --- Okay, that change fixes it without regressions. I'll post a patch.
[Bug c++/79442] GCC 5.4 does not fully support N3652 (Relaxing constraints on constexpr functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79442 Ose Pedro changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Ose Pedro --- (In reply to Jonathan Wakely from comment #4) > (In reply to Ose Pedro from comment #0) > > GCC 5 is supposed to provide full support for N3652, but the code below does > > not compile under GCC 5.4 (it does, however, compile under GCC 6.1). > > It compiles fine using any 5.x release, even 5.1.0, what error do you get? > > You need to use -std=gnu++14 or -std=c++14, because N3652 is a C++14 feature. > > I don't see a problem with the C++ status page. Oh sorry, my mistake - I was using an online compiler, and I wrongly assumed that it had enabled c++14.
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #60 from Aldy Hernandez --- Proposed all-inclusive patch for this PR. https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00691.html
[Bug ipa/70795] [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70795 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jan Hubicka --- Fixed.
[Bug ipa/70795] [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70795 --- Comment #15 from Jan Hubicka --- Author: hubicka Date: Thu Feb 9 18:16:00 2017 New Revision: 245312 URL: https://gcc.gnu.org/viewcvs?rev=245312&root=gcc&view=rev Log: PR ipa/70795 * cgraphunit.c (cgraph_node::add_new_function): Set externally_visible flag if needed. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c
[Bug ada/79421] gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 --- Comment #5 from Dominik Vogt --- Patch available here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 The bug can be closed when the patch is applied.
[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 --- Comment #14 from Marc Mutz --- You can hide behind the letter of the standard, but you cannot escape the simple fact that __has_include is the intended mechanism to check for library features that added a new header. Proof: You need to include that header to get at the __cpp_lib macro, if any. If you can't use __has_include for that, because the header stabs you in the back, then that intended mechanism is broken. Call it conforming if you want, but it simply isn't.
[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 --- Comment #15 from Andrew Pinski --- (In reply to Marc Mutz from comment #14) > You can hide behind the letter of the standard, but you cannot escape the > simple fact that __has_include is the intended mechanism to check for > library features that added a new header. Proof: You need to include that > header to get at the __cpp_lib macro, if any. If you can't use __has_include > for that, because the header stabs you in the back, then that intended > mechanism is broken. Call it conforming if you want, but it simply isn't. Isn't it the same is true for any header that someone could create and not just about standard headers?
[Bug fortran/79446] New: Passing internal procedure as argument causes segfault at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79446 Bug ID: 79446 Summary: Passing internal procedure as argument causes segfault at runtime Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- Created attachment 40709 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40709&action=edit Example program Attached program demonstrates my problem. Compiling with: gfortran -std=f2008 -g -o test_mem test_mem.f90 Running on RHEL (2.6.32-642.13.1.el6.x86_64), I get the following segfault: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x14E10ED8FBB7 #1 0x14E10ED8EDB0 #2 0x354523269F #3 0x7FFC67EF9B00 Segmentation fault (core dumped) In gdb: (gdb) where #0 0x7ffe250e7390 in ?? () #1 0x00400865 in test_mem_m::do (a=3, theirproc=0x7ffe250e7390) at test_mem.f90:17 #2 0x00400928 in test_mem () at test_mem.f90:29 #3 0x0040095f in main (argc=1, argv=0x7ffe250e9110) at test_mem.f90:25 #4 0x00354521ed5d in __libc_start_main () from /lib64/libc.so.6 #5 0x00400709 in _start () If I change the internal procedure to a non-internal one, the segfault goes away. Also, I don't experience the segfault on other Linux distros (e.g., Gentoo/3.16.5) or Mac OS. cheers, Rich
