[Bug libgcc/85967] New: [ARM] No unwinding support for division functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85967
Bug ID: 85967
Summary: [ARM] No unwinding support for division functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: la...@linux-mips.org
Target Milestone: ---
__aeabi_idiv is missing unwinding info, so backtrace stops there not providing
information where division by zero happened. Tested with gcc-5.4.0 and
gcc-7.3.1, but given the fact libgcc/config/arm/lib1funcs.S is not receiving
any updates, all gcc versions are affected.
Test case compiled with gcc-5.4.0:
$ arm-v7a-linux-gnueabi-gcc -o test -g -rdynamic -funwind-tables
-fasynchronous-unwind-tables -fno-omit-frame-pointer sigfpe_div0_bt.c
./test
Stack trace:
/lib/libc.so.6(+0x16a66) [0xb6e39a66]
/lib/libc.so.6(gsignal+0x23) [0xb6e47600]
The same test case using gcc-7.3.1 on x86_64:
$ gcc -o test -g -rdynamic -funwind-tables -fasynchronous-unwind-tables
-fno-omit-frame-pointer sigfpe_div0_bt.c
$ ./test
Stack trace:
./test(baz+0x16) [0x55ef13367dd0]
./test(bar+0x15) [0x55ef13367dfe]
./test(foo+0x15) [0x55ef13367e16]
./test(main+0xb8) [0x55ef13367ed1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7ff3e4402a87]
./test(_start+0x2a) [0x55ef13367b5a]
Using following naive patch in attachment makes things better...
--- a/libgcc/config/arm/lib1funcs.S 2018-05-29 01:20:17.816878829 +0200
+++ b/libgcc/config/arm/lib1funcs.S 2018-05-29 01:28:04.697491881 +0200
@@ -1344,7 +1344,9 @@
ARM_FUNC_START div0
#endif
+ .fnstart
do_push {r1, lr}
+ .save {r1, lr}
mov r0, #SIGFPE
bl SYM(raise) __PLT__
RETLDM r1
@@ -1355,6 +1357,7 @@
#else
FUNC_END div0
#endif
+ .fnend
#endif /* L_dvmd_lnx */
#ifdef L_clear_cache
Stack trace:
/lib/libc.so.6(+0x16a66) [0xb6e19a66]
/lib/libc.so.6(gsignal+0x23) [0xb6e27600]
./test() [0x10eea]
./test(baz+0x13) [0x10b64]
I would welcome if ARM could unwind in this situation too as it makes
backtraces more meaningful given limited environment of typical arm embedded
board.
[Bug libgcc/85967] [ARM] No unwinding support for division functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85967 --- Comment #1 from Ladislav Michl --- Created attachment 44205 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44205&action=edit SIGFPE test case
[Bug target/85950] Unsafe-math-optimizations regresses optimization using SSE4.1 roundss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85950 --- Comment #4 from Allan Jensen --- Btw, I found this while trying to figure out why std::round() wasn't also optimized to a single roundss instruction, is that just a missing optimization or is there a quirk about that that makes them not fit? I noticed the definition of the ROUND enum in i386.md is even missing the entry to for normal rounding (0 AFAIK)
[Bug c++/85958] Make const qualifier error clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85958 --- Comment #1 from Jonny Grant --- My idea of what would be clearest is :- Cannot pass ‘const int‘ as ‘int&‘ (non const)
[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85759 --- Comment #18 from Stefan Talpalaru --- Another clue emerged: the ICE appears only when the same source file is compiled multiple times. When building the extensions, Python replaces the boring Makefile with its own "distutils" build tool that fails to do conditional compilation based on the source and target modification times. Since "timemodule.c" is used by 3 different extensions, it's being compiled 3 times in the profile generation phase and this somehow corrupts the corresponding .gcda file. Once this silly build tool is fixed so it compiles it a single time, the ICE disappears.
[Bug c++/85739] [8/9 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85739 Paolo Carlini changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 CC||paolo.carlini at oracle dot com
[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85759 --- Comment #20 from Martin Liška --- Patch candidate: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01608.html
[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85759 --- Comment #19 from Martin Liška --- (In reply to Stefan Talpalaru from comment #18) > Another clue emerged: the ICE appears only when the same source file is > compiled multiple times. > > When building the extensions, Python replaces the boring Makefile with its > own "distutils" build tool that fails to do conditional compilation based on > the source and target modification times. > > Since "timemodule.c" is used by 3 different extensions, it's being compiled > 3 times in the profile generation phase and this somehow corrupts the > corresponding .gcda file. Once this silly build tool is fixed so it compiles > it a single time, the ICE disappears. Yes, I've noticed that as well. Just wanted to inform you. I've cooked a patch for that prints following: ... gcc -pthread -fPIC -fno-strict-aliasing -O3 -march=native -pipe -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fprofile-generate -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -I. -IInclude -I./Include -I/usr/local/include -I/home/marxin/Programming/testcases/python-lto-ice-v2/playground/cpython-2.7.15/Include -I/home/marxin/Programming/testcases/python-lto-ice-v2/playground/cpython-2.7.15 -c /home/marxin/Programming/testcases/python-lto-ice-v2/playground/cpython-2.7.15/Modules/itertoolsmodule.c -o build/temp.linux-x86_64-2.7/home/marxin/Programming/testcases/python-lto-ice-v2/playground/cpython-2.7.15/Modules/itertoolsmodule.o profiling:/home/marxin/Programming/testcases/python-lto-ice-v2/playground/cpython-2.7.15/build/temp.linux-x86_64-2.7/home/marxin/Programming/testcases/python-lto-ice-v2/playground/cpython-2.7.15/Modules/timemodule.gcda:overwriting an existing profile data with a different timestamp profiling:exiting after an error profiling:/home/marxin/Programming/testcases/python-lto-ice-v2/playground/cpython-2.7.15/build/temp.linux-x86_64-2.7/home/marxin/Programming/testcases/python-lto-ice-v2/playground/cpython-2.7.15/Modules/timemodule.gcda:overwriting an existing profile data with a different timestamp profiling:exiting after an error ... Note I also introduced GCOV_EXIT_AT_ERROR env. variable that should be handy for package builds.
[Bug c/85955] ICE in fold_convert_loc, at fold-const.c:2408
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85955 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.1.0, 9.0 --- Comment #1 from Martin Liška --- Confirmed, it's very old, started with GCC 4.6.0.
[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 CC||ebotcazou at gcc dot gnu.org, ||law at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started when we introduced GCC unroll pragma: r255973. Changing 128 to 32, then it takes ~5s on a Haswell machine. time report: time gcc pr85954.c -c -ftracer -fno-guess-branch-probability -O3 -ftime-report Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 1247 kB ( 6%) phase opt and generate : 5.42 (100%) 0.02 (100%) 5.44 (100%) 21204 kB ( 94%) phase finalize : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) CFG verifier : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) tree CFG cleanup : 3.40 ( 63%) 0.00 ( 0%) 3.43 ( 63%) 773 kB ( 3%) tree VRP : 0.01 ( 0%) 0.00 ( 0%) 0.03 ( 1%) 1605 kB ( 7%) tree copy propagation : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 23 kB ( 0%) tree PTA : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) tree SSA rewrite : 0.02 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) tree SSA incremental : 0.17 ( 3%) 0.00 ( 0%) 0.16 ( 3%) 2336 kB ( 10%) tree operand scan : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 645 kB ( 3%) dominator optimization : 0.07 ( 1%) 0.01 ( 50%) 0.06 ( 1%) 1834 kB ( 8%) backwards jump threading : 1.49 ( 27%) 0.00 ( 0%) 1.49 ( 27%) 0 kB ( 0%) tree FRE : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 2 kB ( 0%) tree loop invariant motion : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) complete unrolling : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 2741 kB ( 12%) tree vectorization : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 1412 kB ( 6%) tree SSA verifier : 0.03 ( 1%) 0.00 ( 0%) 0.04 ( 1%) 0 kB ( 0%) tree STMT verifier : 0.03 ( 1%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) tree strlen optimization : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) dominance frontiers: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) dominance computation : 0.02 ( 0%) 0.01 ( 50%) 0.01 ( 0%) 0 kB ( 0%) loop init : 0.04 ( 1%) 0.00 ( 0%) 0.02 ( 0%) 128 kB ( 1%) CPROP : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 20 kB ( 0%) tracer : 0.03 ( 1%) 0.00 ( 0%) 0.02 ( 0%) 7352 kB ( 33%) combiner : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 105 kB ( 0%) tree loop if-conversion: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 663 kB ( 3%) rest of compilation: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 387 kB ( 2%) repair loop structures : 0.01 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) TOTAL : 5.43 0.02 5.45 22612 kB Extra diagnostic checks enabled; compiler may run slowly. Configure with --enable-checking=release to disable checks. real0m5.468s user0m5.441s sys 0m0.027s Perf report: # Overhead Command Shared Object Symbol # ... ... # 31.15% cc1 cc1 [.] et_splay 13.65% cc1 cc1 [.] fsm_find_thread_path 8.80% cc1 cc1 [.] iterate_fix_dominators 4.75% cc1 cc1 [.] hash_table, xcallocator>::find_empty_slot_for_expand 3.38% cc1 cc1 [.] thread_jumps::handle_phi 2.78% cc1 cc1 [.] thread_jumps::fsm_find_control_statement_thread_paths 2.70% cc1 cc1 [.] bitmap_set_bit 2.47% cc1 cc1 [.] graphds_dfs 2.33% cc1 cc1 [.] et_root
[Bug middle-end/85956] [9 Regression] ICE in wide_int_to_tree_1, at tree.c:1549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85956 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||9.0 Ever confirmed|0 |1 Known to fail||8.1.0 --- Comment #1 from Martin Liška --- Confirmed, started with r260156.
[Bug fortran/85954] [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85954 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||8.1.0, 9.0 --- Comment #2 from Martin Liška --- Confirmed, started with r253400.
[Bug fortran/85953] [6/7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85953 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 Target Milestone|--- |6.5
[Bug fortran/85953] [6/7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85953 --- Comment #2 from Martin Liška --- Confirmed, started with r228368.
[Bug fortran/85954] [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85954 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.2 --- Comment #3 from Richard Biener --- Another case of a missing DECL_EXPR for a variable-size type.
[Bug target/85950] Unsafe-math-optimizations regresses optimization using SSE4.1 roundss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85950 --- Comment #5 from Uroš Bizjak --- (In reply to Allan Jensen from comment #4) > Btw, I found this while trying to figure out why std::round() wasn't also > optimized to a single roundss instruction, is that just a missing > optimization or is there a quirk about that that makes them not fit? > > I noticed the definition of the ROUND enum in i386.md is even missing the > entry to for normal rounding (0 AFAIK) round() rounds half away from zero, while roundss/roundsd (using normal rounding) rounds half to even.
[Bug middle-end/85955] ICE in fold_convert_loc, at fold-const.c:2408
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85955 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Component|c |middle-end Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine as well. We are gimplifying 3791 if (!update_call_from_tree (gsi, result)) 3792gimplify_and_update_call_from_tree (gsi, result); 3793 return true; (gdb) p debug_generic_expr (result) *sinx_3(D) = IMAGPART_EXPR >;, *cosx_4(D) = REALPART_EXPR >; and as part of that failing the store because of the arg mismatch. This is because gimple_builtin_call_types_compatible_p uses useless_type_conversion_p and double * and double ** do not require a conversion in GIMPLE.
[Bug middle-end/85956] [8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1549
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85956 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |8.2 Summary|[9 Regression] ICE in |[8/9 Regression] ICE in |wide_int_to_tree_1, at |wide_int_to_tree_1, at |tree.c:1549 |tree.c:1549 --- Comment #2 from Jakub Jelinek --- It actually started with r254830 if you drop the default(none) so that you don't hit the bug r260156 was fixing. Not really sure if it is desirable to slow down code at runtime for warnings though, by forcing passing around array lengths for the cases of pointers to VLA, even when nothing in the code refers to those temporaries. The problem is in: warning_at (location, OPT_Warray_bounds, "array subscript %E is below array bounds of %qT", low_sub, artype); where we've checked that low_bound is INTEGER_CST, but up_bound is error_mark_node (what the temporary VAR_DECL that doesn't get passed to the parallel region is replaced with). So, either we shouldn't try to print %qT in this case, at least when up_bound is error_mark_node, or the type printing should handle the case of error_mark_node bounds gracefully (say print it as [] rather than crash), or perhaps omp expansion could just try to replace these error_mark_node array bounds with NULLs somewhere (no idea if that is actually possible though).
[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964
--- Comment #2 from Arseny Solokha ---
The original testcase looked like this:
int t8;
void
il (void)
{
int uu = 8;
do
{
int yq = 8;
do
{
t8 /= (t8 < 2) ? 1 : 3;
--yq;
}
while (yq > 0);
--uu;
}
while (uu > 0);
}
int
px (int t8)
{
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
il (); il (); il (); il (); il (); il (); il (); il ();
}
I've only replaced 128 distinct function calls w/ to-be-unrolled loop to save
some space. And gcc 8 and 9 still take much more time to compile this one than
earlier gcc branches.
[Bug ipa/85960] -fipa-pta and ifunc are incompatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85960 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-05-29 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Please specify the GCC version and architecture you are using. I cannot reproduce this on x86_64-linux with 4.8.5, 4.9.4, 5.5, 6.4, 7.3, 8.1 or current trunk.
[Bug fortran/85953] [6/7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85953 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 Known to work||5.5.0 Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.1.0, 9.0
[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.2 --- Comment #3 from Richard Biener --- Maintaining dominators is costly. diff --git a/gcc/dominance.c b/gcc/dominance.c index 20671983f98..5ba765c82be 100644 --- a/gcc/dominance.c +++ b/gcc/dominance.c @@ -1475,6 +1475,8 @@ iterate_fix_dominators (enum cdi_direction dir, vec bbs, return; } + timevar_push (TV_DOMINANCE); + /* Construct the graph G. */ hash_map map (251); FOR_EACH_VEC_ELT (bbs, i, bb) @@ -1537,6 +1539,8 @@ iterate_fix_dominators (enum cdi_direction dir, vec bbs, free (parent); free_graph (g); + + timevar_pop (TV_DOMINANCE); } void shows backwards jump threading : 9.02 ( 37%) 0.00 ( 0%) 9.01 ( 37%) 0 kB ( 0%) dominance computation : 9.89 ( 40%) 0.01 ( 33%) 10.02 ( 41%) 0 kB ( 0%) so there are two offenders. The dominance one is from CFG cleanup as -ftime-report-details shows: tree CFG cleanup : 3.52 ( 14%) 0.01 ( 25%) 3.43 ( 14%) 773 kB ( 3%) `- dominance computation : 9.66 ( 39%) 0.01 ( 25%) 9.77 ( 39%) 0 kB ( 0%) `- tree operand scan : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- CFG verifier: 0.04 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%)
[Bug c++/85958] Make const qualifier error clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85958 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53281 --- Comment #2 from Jonathan Wakely --- (In reply to Jonny Grant from comment #1) > My idea of what would be clearest is :- > > Cannot pass ‘const int‘ as ‘int&‘ (non const) I don't think that's an improvement at all. But "... discards const qualifier" or "... discards volatile qualifier" or "...discards const and volatile qualifiers" might be OK. Or saying "as reference of non-const type 'int&'" similar to my proposed fix for PR 53281.
[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|NEW |ASSIGNED
CC||rguenth at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
And the regression is likely for when I added
static bool
cleanup_tree_cfg_noloop (void)
{
...
/* Ensure that we have single entries into loop headers. Otherwise
if one of the entries is becoming a latch due to CFG cleanup
(from formerly being part of an irreducible region) then we mess
up loop fixup and associate the old loop with a different region
which makes niter upper bounds invalid. See for example PR80549.
This needs to be done before we remove trivially dead edges as
we need to capture the dominance state before the pending transform. */
if (current_loops)
{
...
/* If we have more than one entry to the loop header
create a forwarder. */
if (found_latch && ! any_abnormal && n > 1)
{
edge fallthru = make_forwarder_block (bb, mfb_keep_latches,
NULL);
because make_forwarder_block adds a new block which in turn uses
iterate_fix_dominators to fix dominators. We use dominators to find
latches but we could split the analysis from the transform part and
decide to throw away and re-compute dominators based on some threshold.
Not sure if it is possible to estimate the work of iterate_fix_dominators
up-front.
[Bug target/85961] scratch register rsi used after function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85961 Richard Biener changed: What|Removed |Added Keywords||ra Target||x86_64-*-*, i?86-*-* --- Comment #1 from Richard Biener --- To me it shoulds you are messing with the ABI behind GCCs back. We use IPA register allocation to do this kind of transform that of course doesn't work if you do this. So - does -fno-ipa-ra fix this for you?
[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83009 avieira at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from avieira at gcc dot gnu.org --- I believe my patch fixes this.
[Bug target/85961] scratch register rsi used after function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85961 --- Comment #2 from bki at hacon dot de --- (In reply to Richard Biener from comment #1) > To me it shoulds you are messing with the ABI behind GCCs back. True. I'd still argue that the SysV-ABI suggests that a caller would need to save and restore %rsi before/after a normal function call. But you are right in that the function _ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6lengthEv.isra.0 is not 'normal' in this case but completely in the hands of the compiler (who does not clobber rsi). I could rework my messing with the ABI to change fewer registers but since that is very performance sensitive code, I'd like to understand better if it is really necessary. > We use IPA > register allocation to do this kind of transform that of course doesn't work > if you do this. > > So - does -fno-ipa-ra fix this for you? No, I get the same instruction sequence with '-fno-ipa-ra'
[Bug target/85968] New: gcc/config/arc/arc.c:9805: bad test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85968 Bug ID: 85968 Summary: gcc/config/arc/arc.c:9805: bad test ? Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- gcc/trunk/gcc/config/arc/arc.c:9805:65: warning: bitwise comparison always evaluates to true [-Wtautological-compare] Source code is 250266claziss if (((fn_type & ARC_FUNCTION_ILINK1) | ARC_FUNCTION_FIRQ) != 0) 250266claziss regno = ILINK1_REGNUM; 250266claziss else if ((fn_type & ARC_FUNCTION_ILINK2) != 0) 250266claziss regno = ILINK2_REGNUM; 250266claziss else 250266claziss gcc_unreachable (); but /* Fast interrupt is only available on ARCv2 processors. */ ARC_FUNCTION_FIRQ= 1 << 3, so regno only ever gets set to ILINK1_REGNUM.
[Bug c++/85965] G++ gives cryptic error instead of incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965 --- Comment #1 from Jonathan Wakely --- There's nothing that can be done here. The error comes from the library (not the compiler) and there's no way the compiler can possibly say "the static assertion would have passed if the __is_invocable trait had been true, which might have happened if the type was complete so that a conversion sequence from const Biz* to const Bar* might be possible". The is_invocable trait asks if that function object can be called with those arguments, and when Biz is incomplete the answer is no. I think sadly I have to remove that static_assertion, or just make it happen later when the comparison function is used (by which point either the call works, or you get an error anyway and the static assertion doesn't add any value).
[Bug target/85969] New: avr/gen-avr-mmcu-specs.c:56: unused function ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85969
Bug ID: 85969
Summary: avr/gen-avr-mmcu-specs.c:56: unused function ?
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
config/avr/gen-avr-mmcu-specs.c:56:1: warning: ‘bool str_prefix_p(const char*,
const char*)’ defined but not used [-Wunused-function]
Source code is
221141gjl /* Return true iff STR starts with PREFIX. */
221141gjl
221141gjl static bool
221141gjl str_prefix_p (const char *str, const char *prefix)
221141gjl {
255831 jakub return strncmp (str, prefix, strlen (prefix)) == 0;
221141gjl }
$ fgrep str_prefix_p /home/dcb/gcc/trunk/gcc/config/avr/gen-avr-mmcu-specs.c
str_prefix_p (const char *str, const char *prefix)
$
[Bug target/85918] Conversions to/from [unsigned] long long are not vectorized for AVX512DQ target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85918
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue May 29 11:58:24 2018
New Revision: 260893
URL: https://gcc.gnu.org/viewcvs?rev=260893&root=gcc&view=rev
Log:
PR target/85918
* tree.def (VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR,
VEC_PACK_FLOAT_EXPR): New tree codes.
* tree-pretty-print.c (op_code_prio): Handle
VEC_UNPACK_FIX_TRUNC_HI_EXPR and VEC_UNPACK_FIX_TRUNC_LO_EXPR.
(dump_generic_node): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR,
VEC_UNPACK_FIX_TRUNC_LO_EXPR and VEC_PACK_FLOAT_EXPR.
* tree-inline.c (estimate_operator_cost): Likewise.
* gimple-pretty-print.c (dump_binary_rhs): Handle VEC_PACK_FLOAT_EXPR.
* fold-const.c (const_binop): Likewise.
(const_unop): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR and
VEC_UNPACK_FIX_TRUNC_LO_EXPR.
* tree-cfg.c (verify_gimple_assign_unary): Likewise.
(verify_gimple_assign_binary): Handle VEC_PACK_FLOAT_EXPR.
* cfgexpand.c (expand_debug_expr): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR,
VEC_UNPACK_FIX_TRUNC_LO_EXPR and VEC_PACK_FLOAT_EXPR.
* expr.c (expand_expr_real_2): Likewise.
* optabs.def (vec_packs_float_optab, vec_packu_float_optab,
vec_unpack_sfix_trunc_hi_optab, vec_unpack_sfix_trunc_lo_optab,
vec_unpack_ufix_trunc_hi_optab, vec_unpack_ufix_trunc_lo_optab): New
optabs.
* optabs.c (expand_widen_pattern_expr): For
VEC_UNPACK_FIX_TRUNC_HI_EXPR and VEC_UNPACK_FIX_TRUNC_LO_EXPR use
sign from result type rather than operand's type.
(expand_binop_directly): For vec_packu_float_optab and
vec_packs_float_optab allow result type to be different from operand's
type.
* optabs-tree.c (optab_for_tree_code): Handle
VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR and
VEC_PACK_FLOAT_EXPR. Formatting fixes.
* tree-vect-generic.c (expand_vector_operations_1): Handle
VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR and
VEC_PACK_FLOAT_EXPR.
* tree-vect-stmts.c (supportable_widening_operation): Handle
FIX_TRUNC_EXPR.
(supportable_narrowing_operation): Handle FLOAT_EXPR.
* config/i386/i386.md (fixprefix, floatprefix): New code attributes.
* config/i386/sse.md (*floatv2div2sf2): Rename to ...
(floatv2div2sf2): ... this. Formatting fix.
(vpckfloat_concat_mode, vpckfloat_temp_mode, vpckfloat_op_mode): New
mode attributes.
(vec_pack_float_): New expander.
(vunpckfixt_mode, vunpckfixt_model, vunpckfixt_extract_mode): New mode
attributes.
(vec_unpack_fix_trunc_lo_,
vec_unpack_fix_trunc_hi_): New expanders.
* doc/md.texi (vec_packs_float_@var{m}, vec_packu_float_@var{m},
vec_unpack_sfix_trunc_hi_@var{m}, vec_unpack_sfix_trunc_lo_@var{m},
vec_unpack_ufix_trunc_hi_@var{m}, vec_unpack_ufix_trunc_lo_@var{m}):
Document.
* doc/generic.texi (VEC_UNPACK_FLOAT_HI_EXPR,
VEC_UNPACK_FLOAT_LO_EXPR): Fix pasto in description.
(VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR,
VEC_PACK_FLOAT_EXPR): Document.
* gcc.target/i386/avx512dq-pr85918.c: Add -mprefer-vector-width=512
and -fno-vect-cost-model options. Add aligned(64) attribute to the
arrays. Add suffix 1 to all functions and use 4 iterations rather
than N. Add functions with conversions to and from float.
Add new set of functions with 8 iterations and another one
with 16 iterations, expect 24 vectorized loops instead of just 4.
* gcc.target/i386/avx512dq-pr85918-2.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/avx512dq-pr85918-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/sse.md
trunk/gcc/doc/generic.texi
trunk/gcc/doc/md.texi
trunk/gcc/expr.c
trunk/gcc/fold-const.c
trunk/gcc/gimple-pretty-print.c
trunk/gcc/optabs-tree.c
trunk/gcc/optabs.c
trunk/gcc/optabs.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx512dq-pr85918.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-inline.c
trunk/gcc/tree-pretty-print.c
trunk/gcc/tree-vect-generic.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree.def
[Bug c++/85970] New: Cannot move a std::unique_ptr to insert into a map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85970
Bug ID: 85970
Summary: Cannot move a std::unique_ptr to insert into a map
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.dapena at lge dot com
Target Milestone: ---
Created attachment 44206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44206&action=edit
Test case
Trying to insert to an std::map with value type std::unique_ptr using a move to
the initializer list fails:
std::map> map;
std::string str = "a";
std::unique_ptr a = std::make_unique();
// This fails
map.insert({str, std::move(a)});
But, if instead of this we do:
map.insert(std::pair>(str, std::move(a)));
It works.
This is working in LLVM libc++.
The error we get is related to trying to use the copy contructor of std::pair
and std::unique_ptr:
/usr/include/c++/7/ext/new_allocator.h:136:4: error: use of deleted function
‘std::pair<_T1, _T2>::pair(const std::pair<_T1, _T2>&) [with _T1 = const
std::__cxx11::basic_string; _T2 = std::unique_ptr]’
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
^~
In file included from /usr/include/c++/7/bits/stl_algobase.h:64:0,
from /usr/include/c++/7/bits/stl_tree.h:63,
from /usr/include/c++/7/map:60,
from main.cc:1:
/usr/include/c++/7/bits/stl_pair.h:292:17: note: ‘std::pair<_T1,
_T2>::pair(const std::pair<_T1, _T2>&) [with _T1 = const
std::__cxx11::basic_string; _T2 = std::unique_ptr]’ is implicitly
deleted because the default definition would be ill-formed:
constexpr pair(const pair&) = default;
^~~~
/usr/include/c++/7/bits/stl_pair.h:292:17: error: use of deleted function
‘std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with
_Tp = A; _Dp = std::default_delete]’
In file included from /usr/include/c++/7/memory:80:0,
from main.cc:2:
/usr/include/c++/7/bits/unique_ptr.h:388:7: note: declared here
unique_ptr(const unique_ptr&) = delete;
^~
[Bug libstdc++/85970] Cannot move a std::unique_ptr to insert into a map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85970 Jose Dapena Paz changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Jose Dapena Paz --- Though I reported to gcc, it seems it is actually related to the libstdc++ library. GCC properly compiles this code using LLVM libc++.
[Bug tree-optimization/85971] New: Really Simple "If" with one function call inside is not optimized efficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85971
Bug ID: 85971
Summary: Really Simple "If" with one function call inside is
not optimized efficiently
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
GCC: 8 or 9/trunk
Optimization: O3 or Ofast
Code:
```
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod) {
if (isTestNet == 0) {
*mod = PolyMod(5);
} else {
*mod = PolyMod(9);
}
}
```
It is optimized very inefficiently. The
assembly has one branch.
However, if the compiler was as smart as the
people who develop it, he'd transform the code into
this:
```
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod) {
int a;
if (isTestNet == 0) {
a = 5;
} else {
a = 9;
}
*mod = PolyMod(a);
}
```
which compiles to assembly with zero branches.
Another way to reach the same efficient assembly would be
```
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod) {
*mod = PolyMod(isTestNet == 0 ? 5 : 9);
}
```
So, the compiler has problems seeing little powerful
argument optimizations.
[Bug target/85972] New: cr16/predicates.md:163: bad if test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85972 Bug ID: 85972 Summary: cr16/predicates.md:163: bad if test ? Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- runk/gcc/config/cr16/predicates.md:163:17: warning: logical ‘or’ of collectively exhaustive tests is always true [-Wlogical -op] Source code is return (IN_RAN(INTVAL (op), 0, 15) && ((INTVAL (op) != 9) || (INTVAL (op) != 11))) ? 1 : 0 ; Maybe better code return (IN_RAN(INTVAL (op), 0, 15) && ((INTVAL (op) != 9) && (INTVAL (op) != 11))) ? 1 : 0 ;
[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85759 --- Comment #21 from Martin Liška --- Author: marxin Date: Tue May 29 12:11:21 2018 New Revision: 260895 URL: https://gcc.gnu.org/viewcvs?rev=260895&root=gcc&view=rev Log: libgcov: report about a different timestamp (PR gcov-profile/85759). 2018-05-29 Martin Liska PR gcov-profile/85759 * doc/gcov.texi: Document GCOV_ERROR_FILE and GCOV_EXIT_AT_ERROR env variables. 2018-05-29 Martin Liska PR gcov-profile/85759 * libgcov-driver-system.c (gcov_error): Introduce usage of GCOV_EXIT_AT_ERROR env. variable. * libgcov-driver.c (merge_one_data): Print error that we overwrite a gcov file with a different timestamp. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/gcov.texi trunk/libgcc/ChangeLog trunk/libgcc/libgcov-driver-system.c trunk/libgcc/libgcov-driver.c
[Bug tree-optimization/85971] Really Simple "If" with one function call inside is not optimized efficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85971 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug libstdc++/85970] Cannot move a std::unique_ptr to insert into a map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85970 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- This was a defect in the standard, not GCC, and is already fixed in GCC 7.3.0 *** This bug has been marked as a duplicate of bug 82522 ***
[Bug libstdc++/82522] std::map::insert(value_type &&) not selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82522 Jonathan Wakely changed: What|Removed |Added CC||jose.dapena at lge dot com --- Comment #10 from Jonathan Wakely --- *** Bug 85970 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964 --- Comment #5 from Richard Biener --- Ok, it's not this part of CFG cleanup but the remove_edge_and_domiated_blocks call in cleanup_control_expr_graph. With the reduced testcase we call it around 2000 times. The FSM thing of course is separate, looks like some quadraticness. I will see if I can somehow improve CFG cleanup (given it is called remove_edge_and_dominated_blocks avoiding dominators sounds hard...).
[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964 --- Comment #6 from Richard Biener --- For the FSM part since we walk the whole function for _each_ control stmt name this analysis part, find_jump_threads_backwards (basic_block bb, bool speed_p), is quadratic in the number of BBs. There's limiting via PARAM_FSM_MAXIMUM_PHI_ARGUMENTS but I guess it should instead limit itself on the maximum length of a jump threading path and do that already during analysis rather than only later throwing away non-profitable ones.
[Bug c++/85973] New: [[nodiscard]] shall emit a warning for unused anonymous variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85973
Bug ID: 85973
Summary: [[nodiscard]] shall emit a warning for unused
anonymous variable
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I would to know if the following (currently not implemented) behaviour of
[[nodiscard]] would be useful or not. I am raising this since we have just hit
this case in a real codebase.
Currently a class can be annotated [[nodiscard]] in which case you can't ignore
returned values of this class. However no warning is emitted when an anonymous
and apparently unused instance of this class is created.
It will be clearer with the following snippet:
class [[nodiscard]] A
{
public:
A(void* someArgument) { /* Get some RAII resources */}
~A() { /* Release some RAII resources */}
A(A&&) = default;
A& operator=(A&&) = default;
private:
A(const A&) = delete;
A& operator=(const A&) = delete;
};
A f();
void someStatement();
void g()
{
f(); // Here ignored A result is correctly warned
{
A(nullptr); // Here the anonymous A created does not yield any warning
// while one might expect to (ie we should write: A a(nullptr); using a
// non anonymous variable, which changes the semantic of the program.)
someStatement(); // statement using the fact that we use RAII resource
locking.
}
}
Typically A could be std::lock_guard.
As you can see in godbolt https://godbolt.org/g/AdxJMY only the call to f()
raises the warning, but not the anonymous A(nullptr). One (actually I) would
expect also a warning on the line A(nullptr). Is this improvement welcome or
not ?
Cheers,
Romain
[Bug ipa/85960] -fipa-pta and ifunc are incompatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85960 --- Comment #2 from Gianni Tedesco --- Both gcc-7.3 and gcc-8 from ubuntu on x86-64: gcc version 8.0.1 20180414 (experimental) [trunk revision 259383] (Ubuntu 8-20180414-1ubuntu2) gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
[Bug ipa/85960] -fipa-pta and ifunc are incompatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85960 --- Comment #3 from Gianni Tedesco --- Both gcc-7.3 and gcc-8 from ubuntu on x86-64: gcc version 8.0.1 20180414 (experimental) [trunk revision 259383] (Ubuntu 8-20180414-1ubuntu2) gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)
[Bug libstdc++/85970] Cannot move a std::unique_ptr to insert into a map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85970 Jose Dapena Paz changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #3 from Jose Dapena Paz --- Confirmed it is already fixed in 7.3.0. Also, the original bug report addresses the same problem. Thanks!
[Bug ipa/85960] -fipa-pta and ifunc are incompatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85960 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Confirmed with: $ gcc pr85960.c -O2 -Wall -fipa-pta && ./a.out 2 Let me take a look.
[Bug c/85974] New: Failure to optimize difference of two pointers into a compile time constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85974 Bug ID: 85974 Summary: Failure to optimize difference of two pointers into a compile time constant Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pkoning at gcc dot gnu.org Target Milestone: --- This issue is exposed by test case testsuite/gcc.c-torture/compile/930326-1.c, on platforms where ptrdiff_t is not "long" (such as pdp11). In that case, the last line: long i = s.f-&s.b; fails with "error: initializer element is not computable at load time". It's not a target bug; the problem can be reproduced for other targets by changing the "long" to "char" in that statement.
[Bug target/85950] Unsafe-math-optimizations regresses optimization using SSE4.1 roundss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85950 --- Comment #6 from Allan Jensen --- Btw, I have tested and the patch works for my cases.
[Bug c/85974] Failure to optimize difference of two pointers into a compile time constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85974 --- Comment #1 from Marc Glisse --- In match.pd (simplify - (pointer_diff (convert?@2 @0) (convert?@3 ADDR_EXPR@1)) + (pointer_diff (convert?@2 @0) (convert1?@3 ADDR_EXPR@1)) (that is, we can have only one cast, not just 0 or 2) and similarly for the adjacent transformation. I didn't check if that requires any other adjustment, just pointing out a likely place for a patch.
[Bug libfortran/85975] New: Incorrect size for spread array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85975 Bug ID: 85975 Summary: Incorrect size for spread array Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: stephan.kramer at imperial dot ac.uk Target Milestone: --- With the following program program foo implicit none call bar(2, 3, 5, 7) contains subroutine bar(k, l, m, n) integer, intent(in) :: k, l, m, n real, dimension(k) :: a real, dimension(k,l):: b real, dimension(k,l,m):: c real, dimension(k,l,m,n):: d print *, size(spread(A, 1, 1)) print *, size(spread(b, 1, 1)) print *, size(spread(c, 1, 1)) print *, size(spread(d, 1, 1)) end subroutine end program I get the following result: $ gfortran test2.f90 skramer@gyre:~/tst/gfortran8$ ./a.out 2 6 0 210 skramer@gyre:~/tst/gfortran8$ ./a.out 0 6 754395868 210 i.e. the results for the A and c arrrays are incorrect (and vary between subsequent reruns). After some digging in the libfortran source I think this is due to a bug in the GFC_DTYPE_COPY_SETRANK macro introduced in https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00369.html, where line 421 of libgfortran/libgfortran.h changed from (a)->dtype = (((b)->dtype & ~GFC_DTYPE_RANK_MASK) | n ); \ to (a)->dtype.rank = ((b)->dtype.rank | n ); \ The thing is that the "| n" makes sense in the previous case where the relevant bits that store the previous rank have been zeroed out first. Now that rank is a separate field, I think it should just be: (a)->dtype.rank = n Note that in the example above the even ranked arrays (B and D) do get the correct result. This is because in those cases it happens to be that new_rank==(old_rank | new_rank) (3 == 2 | 3 and 5 == 4 | 5). In the case of arrays A and C however, we get 1 | 2 == 3 and 3 | 4 == 7, so that the rank of the resulting spread array is too big, and the size calculations uses spurious uninitialised array extents. I have found, what I think are, related issues, when passing the result of spread of a rank-3 array into a subroutine, where in the "internal pack" routine would sometimes try to allocate a temporary that is way too big and cause an out of memory error (similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85816). Unfortunately this one seems a little harder to reproduce in a small program.
[Bug c++/85976] New: ICE in cp_tree_equal when building Blitz. May be nested templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85976 Bug ID: 85976 Summary: ICE in cp_tree_equal when building Blitz. May be nested templates. Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: matthew.hambley at metoffice dot gov.uk Target Milestone: --- When compiling https://github.com/blitzpp/blitz v1.0.1 an ICE is generated. This does not happen with GCC 6.4.0 or 7.1.0. Processed source file attached. g++ -v -save-temps -DHAVE_CONFIG_H -I../../blitz-1.0.1/testsuite -I../../blitz-1.0.1 -I.. -I.../gcc/8.1.0/include -g -DBZ_DEBUG -DBZ_DEBUG -MT expression-slicing.o -MD -MP -MF .deps/expression-slicing.Tpo -c -o expression-slicing.o ../../blitz-1.0.1/testsuite/expression-slicing.cpp Using built-in specs. COLLECT_GCC=g++ Target: x86_64-pc-linux-gnu Configured with: ../gcc-8.1.0/configure --prefix=.../gcc/8.1.0 --disable-multilib Thread model: posix gcc version 8.1.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'HAVE_CONFIG_H' '-I' '../../blitz-1.0.1/testsuite' '-I' '../../blitz-1.0.1' '-I' '..' '-I' '.../gcc/8.1.0/include' '-g' '-D' 'BZ_DEBUG' '-D' 'BZ_DEBUG' '-MT' 'expression-slicing.o' '-MD' '-MP' '-MF' '.deps/expression-slicing.Tpo' '-c' '-o' 'expression-slicing.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64' .../gcc/8.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.1.0/cc1plus -E -quiet -v -I ../../blitz-1.0.1/testsuite -I ../../blitz-1.0.1 -I .. -I .../gcc/8.1.0/include -iprefix .../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/ -MD expression-slicing.d -MF .deps/expression-slicing.Tpo -MP -MT expression-slicing.o -D_GNU_SOURCE -D HAVE_CONFIG_H -D BZ_DEBUG -D BZ_DEBUG ../../blitz-1.0.1/testsuite/expression-slicing.cpp -mtune=generic -march=x86-64 -g -fworking-directory -fpch-preprocess -o expression-slicing.ii ignoring nonexistent directory ".../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../x86_64-pc-linux-gnu/include" ignoring duplicate directory ".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0" ignoring duplicate directory ".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0/x86_64-pc-linux-gnu" ignoring duplicate directory ".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0/backward" ignoring duplicate directory ".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/include" ignoring duplicate directory ".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/include-fixed" ignoring nonexistent directory ".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../x86_64-pc-linux-gnu/include" ignoring duplicate directory ".../gcc/8.1.0/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: ../../blitz-1.0.1/testsuite ../../blitz-1.0.1 .. .../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0 .../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0/x86_64-pc-linux-gnu .../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0/backward .../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/include .../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/include-fixed /usr/local/include .../gcc/8.1.0/bin/../lib/gcc/../../include /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'HAVE_CONFIG_H' '-I' '../../blitz-1.0.1/testsuite' '-I' '../../blitz-1.0.1' '-I' '..' '-I' '.../gcc/8.1.0/include' '-g' '-D' 'BZ_DEBUG' '-D' 'BZ_DEBUG' '-MT' 'expression-slicing.o' '-MD' '-MP' '-MF' '.deps/expression-slicing.Tpo' '-c' '-o' 'expression-slicing.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64' .../gcc/8.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.1.0/cc1plus -fpreprocessed expression-slicing.ii -quiet -dumpbase expression-slicing.cpp -mtune=generic -march=x86-64 -auxbase-strip expression-slicing.o -g -version -o expression-slicing.s GNU C++14 (GCC) version 8.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++14 (GCC) version 8.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 70ca2263e1163415e5052b440bbed5d9 In file included from ../../blitz-1.0.1/blitz/array/stencil-et.h:398, from ../../blitz-1.0.1/testsuite/expression-slicing.cpp:3: ../../blitz-1.0.1/blitz/a
[Bug c++/85976] ICE in cp_tree_equal when building Blitz. May be nested templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85976 --- Comment #1 from matthew.hambley at metoffice dot gov.uk --- Created attachment 44207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44207&action=edit Processed source file
[Bug c++/85977] New: Incorrect handling of array reference size deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85977
Bug ID: 85977
Summary: Incorrect handling of array reference size deduction
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremy at jeremyms dot com
Target Milestone: ---
This code should compile, but does not.
template
void foo(const long (&arr)[N]) {}
void bar() {
foo({1,2,3});
}
See discussion here:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/FS5lNgf9_pQ
[Bug target/85978] New: config/frv/frv.c: 3 * iffy code in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85978
Bug ID: 85978
Summary: config/frv/frv.c: 3 * iffy code in switch
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Target: frv
gcc/config/frv/frv.c:6715:7: warning: this statement may fall through
[-Wimplicit-fallthrough=]
gcc/config/frv/frv.c:6741:7: warning: this statement may fall through
[-Wimplicit-fallthrough=]
gcc/config/frv/frv.c:6766:7: warning: this statement may fall through
[-Wimplicit-fallthrough=]
Source code for the first one is
switch (to)
{
default:
break;
Instead merely carrying on with the code after the switch,
and going into the next case for the outer switch,
perhaps better code would flag up in some way the unexpected
value of "to" ?
[Bug tree-optimization/85793] [8/9 Regression][AARCH64] ICE in verify_gimple during GIMPLE pass vect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85793 bin cheng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from bin cheng --- Should be fixed.
[Bug c++/85979] New: Diagnostic says "__alignof" when the source says "alignof"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85979
Bug ID: 85979
Summary: Diagnostic says "__alignof" when the source says
"alignof"
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
int f() { return alignof(f); }
m.cc: In function 'int f()':
m.cc:1:27: error: ISO C++ forbids applying '__alignof' to an expression of
function type [-fpermissive]
int f() { return alignof(f); }
^
[Bug c/85931] -Wsizeof-pointer-memaccess for strncpy with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85931 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-05-29 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Testing a patch.
[Bug c++/85952] Bogus -Wunused-but-set-variable warning with array structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85952 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue May 29 17:07:57 2018 New Revision: 260899 URL: https://gcc.gnu.org/viewcvs?rev=260899&root=gcc&view=rev Log: PR c++/85952 * init.c (build_aggr_init): For structured binding initialized from array call mark_rvalue_use on the initializer. * g++.dg/warn/Wunused-var-33.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-var-33.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
[Bug c++/85963] [8/9 Regression] false positive "set but not used" warning [-Wunused-but-set-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85963 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 Target Milestone|--- |8.2 Summary|false positive "set but not |[8/9 Regression] false |used" warning |positive "set but not used" |[-Wunused-but-set-variable] |warning ||[-Wunused-but-set-variable] Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253266, Jason, can you please have a look?
[Bug c/85957] i686: Integers appear to be different, but compare as equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2018-05-29
CC||amonakov at gcc dot gnu.org
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #7 from Alexander Monakov ---
Reopening, the issue here is way more subtle than bug 323 and points to a
possible issue in DOM. Hopefully Richi can have a look and comment.
It appears dom2 pass performs something like jump threading based on
compile-time-evaluated floating-point expression values without also
substituting those expressions in IR. At run time, they are evaluated to
different values, leading to an inconsistency. Namely, dom2 creates bb 10:
:
# iftmp.1_1 = PHI <"true"(7), "false"(8), "true"(10)>
printf ("(a6 == b6) = %s\n", iftmp.1_1);
return 0;
:
_24 = __n2_13 * 1.0e+6;
b6_25 = (guint64) _24;
printf ("a6 = %llu\n", 1);
printf ("b6 = %llu\n", b6_25);
goto ;
where jump to bb 9 implies that _24 evaluates to 1.0 and b6_25 to 1, but they
are not substituted as such, and at run time evaluate to 0.99... and 0 due to
excess precision.
The following reduced testcase demonstrates the same issue, but requires
-fdisable-tree-dom3 (on gcc-6 at least, as otherwise dom3 substitutes results
of compile-time evaluation).
__attribute__((noinline,noclone))
static double f(void)
{
return 1e-6;
}
int main(void)
{
double a = 1e-6, b = f();
if (a != b) __builtin_printf("uneq");
unsigned long long ia = a * 1e6, ib = b * 1e6;
__builtin_printf("%lld %s %lld\n", ia, ia == ib ? "==" : "!=", ib);
}
[Bug c++/53281] poor error message for calling a non-const method from a const object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281 --- Comment #9 from Jonathan Wakely --- N.B. comment 6 is the subject of PR 85958 which is really a different bug to this one. This is about invalid member function calls on cv-qualified objects, and 85958 is about invalid attempts to bind references to cv-qualified objects.
[Bug c++/85883] class template argument deduction fails in new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85883 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Tue May 29 17:44:07 2018 New Revision: 260901 URL: https://gcc.gnu.org/viewcvs?rev=260901&root=gcc&view=rev Log: PR c++/85883 * init.c (build_new): Handle deducing a class with new with more than one argument. * g++.dg/cpp1z/class-deduction55.C: New test. * g++.dg/cpp1z/class-deduction56.C: New test. * g++.dg/cpp1z/class-deduction57.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction55.C trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction56.C trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction57.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
[Bug c++/85883] class template argument deduction fails in new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85883 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed for GCC 9.
[Bug target/85961] scratch register rsi used after function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85961 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- You'd need to disable IPA-RA after forcing -O2 with the pragma, i.e.: #pragma GCC optimize "O2" #pragma GCC optimize "no-ipa-ra" We already have logic to disable IPA-RA when instrumentation/profiling is active, but it's done once in toplev.c. Here the pragma re-enables IPA-RA after toplev.c:process_options() has disabled it. Do we want to adjust it given that "pragma optimized" is documented as "not suitable for production use"?
[Bug c++/85976] ICE in cp_tree_equal when building Blitz. May be nested templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85976 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed.
[Bug c++/85976] ICE in cp_tree_equal when building Blitz. May be nested templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85976 --- Comment #3 from Marek Polacek --- Started with r251438.
[Bug c++/85977] Incorrect handling of array reference size deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85977
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-05-29
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed. We get:
85977.C: In function ‘void bar()’:
85977.C:4:13: error: no matching function for call to ‘foo()’
foo({1,2,3});
^
85977.C:2:6: note: candidate: ‘template void foo(const long int (&)[N])’
void foo(const long (&arr)[N]) {}
^~~
85977.C:2:6: note: template argument deduction/substitution failed:
85977.C:4:13: note: mismatched types ‘long int’ and ‘int’
foo({1,2,3});
^
[Bug middle-end/85980] New: suboptimal code for strncmp for powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85980
Bug ID: 85980
Summary: suboptimal code for strncmp for powerpc64
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As discussed in https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01514.html, for
the following test case and the powerpc64le target, GCC emits the code below:
int f (__SIZE_TYPE__ i)
{
return __builtin_strncmp ("1234", "123", i < 3 ? i : 3);
}
f:
.LFB0:
.cfi_startproc
.LCF0:
0: addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry f,.-f
mflr 0
cmpldi 7,3,3
li 5,3
std 0,16(1)
stdu 1,-32(1)
.cfi_def_cfa_offset 32
.cfi_offset 65, 16
bgt 7,.L5
cmpdi 7,3,4 << unnecessary
mr 5,3 <<
ble 7,.L5<<
li 5,4 <<
.L5:
addis 4,2,.LC1@toc@ha
addis 3,2,.LC0@toc@ha
addi 4,4,.LC1@toc@l
addi 3,3,.LC0@toc@l
bl strncmp
nop
addi 1,1,32
.cfi_def_cfa_offset 0
ld 0,16(1)
mtlr 0
.cfi_restore 65
blr
The comparison and the subsequent branch are helpful when strncmp is expanded
inline but do not benefit the library version of strncmp and only bloat and
slow down the caller. (The origins of the code are tracked down in
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01406.html). The following
simple patch is enough to improve the generated code:
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 841c1ef..5b9085b 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -4708,12 +4708,7 @@ expand_builtin_strncmp (tree exp, ATTRIBUTE_UNUSED rtx
target,
return target;
}
- /* Expand the library call ourselves using a stabilized argument
- list to avoid re-evaluating the function's arguments twice. */
- tree fn = build_call_nofold_loc (loc, fndecl, 3, arg1, arg2, len);
- gcc_assert (TREE_CODE (fn) == CALL_EXPR);
- CALL_EXPR_TAILCALL (fn) = CALL_EXPR_TAILCALL (exp);
- return expand_call (fn, target, target == const0_rtx);
+ return expand_call (exp, target, target == const0_rtx);
}
/* Expand a call to __builtin_saveregs, generating the result in TARGET,
[Bug c++/85889] lambda expression can capture structured bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug testsuite/85888] [9 Regression] New test case c-c++-common/attr-nonstring-6.c from r260541 fails with excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85888 --- Comment #6 from Martin Sebor --- Author: msebor Date: Tue May 29 18:29:04 2018 New Revision: 260902 URL: https://gcc.gnu.org/viewcvs?rev=260902&root=gcc&view=rev Log: PR middle-end/85888 - New test case c-c++-common/attr-nonstring-6.c from r260541 fails with excess errors 2018-05-29 Martin Sebor Richard Biener PR testsuite/85888 * calls.c (get_size_range): Call determine_value_range instead of get_value_range.. * tree-vrp.h (determine_value_range): Declared new function. * tree-vrp.c (determine_value_range_1, determine_value_range): New. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/tree-vrp.c trunk/gcc/tree-vrp.h
[Bug testsuite/85888] [9 Regression] New test case c-c++-common/attr-nonstring-6.c from r260541 fails with excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85888 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Sebor --- Fixed via r260902.
[Bug fortran/85981] New: ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85981 Bug ID: 85981 Summary: ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Down to at least 4.8 : $ cat z1.f90 program p integer, allocatable :: arr(:) integer :: stat character(len=128, kind=4) :: errmsg = ' ' allocate (arr(3), stat=stat, errmsg=errmsg) print *, allocated(arr), stat, trim(errmsg) end $ gfortran-9-20180527 -c z1.f90 z1.f90:5:0: allocate (arr(3), stat=stat, errmsg=errmsg) internal compiler error: in gfc_trans_string_copy, at fortran/trans-expr.c:6539 0x7782cf gfc_trans_string_copy(stmtblock_t*, tree_node*, tree_node*, int, tree_node*, tree_node*, int) ../../gcc/fortran/trans-expr.c:6539 0x7bb884 gfc_trans_allocate(gfc_code*) ../../gcc/fortran/trans-stmt.c:6708 0x74acf7 trans_code ../../gcc/fortran/trans.c:1996 0x772269 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6507 0x701040 translate_all_program_units ../../gcc/fortran/parse.c:6121 0x701040 gfc_parse_file() ../../gcc/fortran/parse.c:6324 0x7480ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85981 --- Comment #1 from G. Steinmetz --- Works with character(kind=1) : $ cat z2.f90 program p integer, allocatable :: arr(:) integer :: stat character(len=128, kind=1) :: errmsg = ' ' allocate (arr(3), stat=stat, errmsg=errmsg) print *, allocated(arr), stat, trim(errmsg) end $ gfortran-9-20180527 z2.f90 -static-libgfortran $ a.out T 0
[Bug target/85950] Unsafe-math-optimizations regresses optimization using SSE4.1 roundss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85950
--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May 29 18:35:34 2018
New Revision: 260903
URL: https://gcc.gnu.org/viewcvs?rev=260903&root=gcc&view=rev
Log:
PR target/85950
* config/i386/i386.md (l2):
Enable for TARGET_SSE4_1 and generate rounds{s,d} and cvtts{s,d}2si{,q}
sequence.
(sse4_1_round2): Use nonimmediate_operand
for operand 1 predicate.
testsuite/ChangeLog:
PR target/85950
* gcc.target/i386/pr85950.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr85950.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
[Bug fortran/85982] New: ICE in resolve_component, at fortran/resolve.c:13696
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85982 Bug ID: 85982 Summary: ICE in resolve_component, at fortran/resolve.c:13696 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Needs option -fdec or -fdec-structure : $ cat z1.f90 program p structure /s/ integer :: a integer, external, pointer :: b end structure end $ gfortran-9-20180527 -c z1.f90 -fdec f951: internal compiler error: Segmentation fault 0xba072f crash_signal ../../gcc/toplev.c:325 0x71d62c resolve_component ../../gcc/fortran/resolve.c:13696 0x71e812 resolve_fl_struct ../../gcc/fortran/resolve.c:14012 0x718d77 resolve_symbol ../../gcc/fortran/resolve.c:14568 0x73595b do_traverse_symtree ../../gcc/fortran/symbol.c:4153 0x71c0da resolve_types ../../gcc/fortran/resolve.c:16472 0x71794c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16586 0x700e6a resolve_all_program_units ../../gcc/fortran/parse.c:6060 0x700e6a gfc_parse_file() ../../gcc/fortran/parse.c:6310 0x7480ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/85982] ICE in resolve_component, at fortran/resolve.c:13696
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85982 --- Comment #1 from G. Steinmetz --- Comparison sample : $ cat z2.f90 program p type t integer :: a integer, external, pointer :: b end type end $ gfortran-9-20180527 -c z2.f90 z2.f90:4:23: integer, external, pointer :: b 1 Error: Attribute at (1) is not allowed in a TYPE definition
[Bug fortran/85983] New: ICE in check_dtio_interface1, at fortran/interface.c:4748
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85983 Bug ID: 85983 Summary: ICE in check_dtio_interface1, at fortran/interface.c:4748 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With incomplete or invalid dummy argument lists : $ cat z1.f90 module m type t contains procedure :: s1 procedure :: s2 generic :: write(formatted) => s1 generic :: write(formatted) => s2 end type contains subroutine s1 (dtv) class(t), intent(in) :: dtv end subroutine s2 (dtv, unit) class(t), intent(in) :: dtv integer, intent(in) :: unit end end $ cat z2.f90 module m type t contains procedure :: s1 procedure :: s2 generic :: write(formatted) => s1 generic :: write(formatted) => s2 end type contains subroutine s1 (dtv, iomsg) class(t), intent(in) :: dtv character(*), intent(inout) :: iomsg end subroutine s2 (dtv, unit) class(t), intent(in) :: dtv integer, intent(in) :: unit end end $ gfortran-9-20180527 -c z1.f90 f951: internal compiler error: in check_dtio_interface1, at fortran/interface.c:4748 0x6b1478 check_dtio_interface1 ../../gcc/fortran/interface.c:4748 0x6b8f05 gfc_check_dtio_interfaces(gfc_symbol*) ../../gcc/fortran/interface.c:4900 0x73595b do_traverse_symtree ../../gcc/fortran/symbol.c:4153 0x71c570 resolve_types ../../gcc/fortran/resolve.c:16513 0x71794c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16586 0x701394 gfc_parse_file() ../../gcc/fortran/parse.c:6262 0x7480ef gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85981 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #1) > Works with character(kind=1) : > > > $ cat z2.f90 > program p >integer, allocatable :: arr(:) >integer :: stat >character(len=128, kind=1) :: errmsg = ' ' >allocate (arr(3), stat=stat, errmsg=errmsg) >print *, allocated(arr), stat, trim(errmsg) > end > > > $ gfortran-9-20180527 z2.f90 -static-libgfortran > $ a.out > T 0 It ought to work with kind=1. For the original code, and error message should be issued as kind=4 is not default character kind. R928 alloc-opt is ERRMSG = errmsg-variable R930 errmsg-variable is scalar-default-char-variable R906 default-char-variable is variable C906 default-char-variable shall be default character.
[Bug c/85984] New: ICE in create_pseudo_cfg, at dwarf2cfi.c:2874
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85984
Bug ID: 85984
Summary: ICE in create_pseudo_cfg, at dwarf2cfi.c:2874
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions 8/9 at -O[23] (no better example found).
Changed between 20170723 and 20170820.
$ cat z1.c
int fn1 (void);
void __attribute__((naked))
fn2 (void)
{
if (!fn1())
abort ();
}
void fn3 (void)
{
fn2 ();
}
$ gcc-9-20180527 -c z1.c -O2
z1.c: In function 'fn2':
z1.c:6:5: warning: implicit declaration of function 'abort'
[-Wimplicit-function-declaration]
abort ();
^
z1.c:6:5: warning: incompatible implicit declaration of built-in function
'abort'
z1.c:6:5: note: include '' or provide a declaration of 'abort'
z1.c:1:1:
+#include
int fn1 (void);
z1.c:6:5:
abort ();
^
during RTL pass: dwarf2
z1.c:7:1: internal compiler error: in create_pseudo_cfg, at dwarf2cfi.c:2874
}
^
0x7cb7a7 create_pseudo_cfg
../../gcc/dwarf2cfi.c:2874
0x7cb7a7 execute_dwarf2_frame
../../gcc/dwarf2cfi.c:3049
0x7cb7a7 execute
../../gcc/dwarf2cfi.c:3540
[Bug c++/85889] lambda expression can capture structured bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/85961] scratch register rsi used after function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85961 --- Comment #4 from bki at hacon dot de --- (In reply to Alexander Monakov from comment #3) > You'd need to disable IPA-RA after forcing -O2 with the pragma, i.e.: > > #pragma GCC optimize "O2" > #pragma GCC optimize "no-ipa-ra" Yes, this changes the problematic instruction sequence to: 7e: 48 89 c5 mov%rax,%rbp 81: e8 7a ff ff ffcallq 0 <_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6lengthEv.isra.0> 86: 48 8d 54 05 00lea0x0(%rbp,%rax,1),%rdx Which is better, since rbp is not a scratch register. > [...]. Do we want to adjust it given that "pragma optimized" is documented as > "not suitable for production use"? I appreciate the explanation which makes sense to me. In the original context, I did introduce the pragma to reduce compilation times like this: #pragma GCC optimize "-fno-var-tracking", "-fno-var-tracking-assignments" So, with instrumentation but without the optimize pragma, scratch registers will always be considered changed across a function call? This would then both fix my issue and more general doubts on the feasibility of my ABI messing. I also agree that the pragma is clearly documented as not fit for production use and would remove it accordingly. I think I can manage to pass these options on the command line somehow.
[Bug c/85985] New: GCC >= 5.6 unaligned movaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85985
Bug ID: 85985
Summary: GCC >= 5.6 unaligned movaps
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: valentinp at mellanox dot com
Target Milestone: ---
Test case:
#include
#include
#include
struct aaa {
void *a1;
void *a2;
struct {
void* a3
#if defined(USE_ALIGN) && USE_ALIGN > 0
__attribute__((aligned(64)))
#endif
;
};
};
struct bbb {
volatile int b;
struct aaa A;
};
static void print_A(struct aaa *A) {
printf("a1: %p, %%8=%lu %%16=%lu %%32=%lu\na2: %p, %%8=%lu %%16=%lu
%%32=%lu\n",
&A->a1, ((uint64_t)(&A->a1)) % 8, ((uint64_t)(&A->a1)) % 16,
((uint64_t)(&A->a1)) % 32,
&A->a2, ((uint64_t)(&A->a2)) % 8, ((uint64_t)(&A->a2)) % 16,
((uint64_t)(&A->a2)) % 32);
}
static void __attribute__ ((noinline)) B_init(struct bbb *B) {
B->A.a2 = NULL;
B->A.a1 = NULL;
}
int main(int argc, char *argv[])
{
struct bbb *B;
void *storage = malloc(sizeof(struct bbb)*32);
B = (struct bbb*)((char*)storage + 8);
print_A(&B->A);
B_init(B);
free(storage);
return 0;
}
ASM:
.file "compiler2.c"
.text
.p2align 4,,15
.type B_init, @function
B_init:
.LFB42:
.cfi_startproc
pxor%xmm0, %xmm0
movaps %xmm0, 64(%rdi)
ret
.cfi_endproc
.LFE42:
.size B_init, .-B_init
.section.rodata.str1.8,"aMS",@progbits,1
.align 8
.LC0:
.string "a1: %p, %%8=%lu %%16=%lu %%32=%lu\na2: %p, %%8=%lu %%16=%lu
%%32=%lu\n"
.section.text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB43:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$6144, %edi
callmalloc@PLT
leaq74(%rax), %rdx
movq%rax, %rbx
leaq82(%rax), %rax
leaq.LC0(%rip), %rsi
movl$1, %edi
movq%rax, %rcx
movq%rdx, %r9
movq%rdx, %r8
andl$31, %ecx
andl$31, %r9d
andl$15, %r8d
pushq %rcx
.cfi_def_cfa_offset 24
movq%rax, %rcx
andl$15, %ecx
pushq %rcx
.cfi_def_cfa_offset 32
pushq $2
.cfi_def_cfa_offset 40
movl$2, %ecx
pushq %rax
.cfi_def_cfa_offset 48
xorl%eax, %eax
call__printf_chk@PLT
leaq10(%rbx), %rdi
addq$32, %rsp
.cfi_def_cfa_offset 16
callB_init
movq%rbx, %rdi
callfree@PLT
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE43:
.size main, .-main
.ident "GCC: (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0"
.section.note.GNU-stack,"",@progbits
gcc --version
gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
compile:
gcc -v --save-temps -O3 -o ccc -DUSE_ALIGN=1 -Wall -Wextra compiler2.c
Description:
test always works with GCC 4.6
test works with GCC >= 5.6 and -DUSE_ALIGN=0
test segv on unaligned movaps with GCC >= 5.6 (latest tested GCC 7.2) and
-DUSE_ALIGN=1
This may be a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84525
but the test case here is different. Am I violating the spec with this test?
[Bug c/85985] GCC >= 5.6 unaligned movaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85985 --- Comment #1 from Andrew Pinski --- The alignment requirement for struct bbb is 64bytes but you cast a non aligned data to that type. This is undefined code since the type has an alignment requirement.
[Bug c/85985] GCC >= 5.6 unaligned movaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85985 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- .
[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85981 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- I have a patch.
[Bug c/85985] GCC >= 5.6 unaligned movaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85985 --- Comment #3 from Valentin Petrov --- Thanks, just to clarify. Do I understand correctly that the alignment requirement for bbb comes from __attribute__ (aligned) in aaa ?? (attribute makes a3 to be aligned, which makes aaa to be 64b aligned, which makes bbb 64b aligned) ? Is this correct logic?
[Bug c/85985] GCC >= 5.6 unaligned movaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85985 --- Comment #4 from Andrew Pinski --- (In reply to Valentin Petrov from comment #3) > Thanks, just to clarify. Do I understand correctly that the alignment > requirement for bbb comes from __attribute__ (aligned) in aaa ?? (attribute > makes a3 to be aligned, which makes aaa to be 64b aligned, which makes bbb > 64b aligned) ? > > Is this correct logic? YES. C11 added _Alignof to see what the alignment is required.
[Bug c++/67445] New warning: returning std::initializer_list bound to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67445 --- Comment #2 from Jason Merrill --- Author: jason Date: Tue May 29 20:04:52 2018 New Revision: 260905 URL: https://gcc.gnu.org/viewcvs?rev=260905&root=gcc&view=rev Log: PR c++/67445 - returning temporary initializer_list. PR c++/67711 - assigning from temporary initializer_list. PR c++/48562 - new initializer_list. * typeck.c (maybe_warn_about_returning_address_of_local): Also warn about returning local initializer_list. * cp-tree.h (AUTO_TEMP_NAME, TEMP_NAME_P): Remove. * call.c (build_over_call): Warn about assignment from temporary init_list. * init.c (build_new_1): Warn about 'new std::initializer_list'. (find_list_begin, maybe_warn_list_ctor): New. (perform_member_init): Use maybe_warn_list_ctor. Added: trunk/gcc/testsuite/g++.dg/warn/Winit-list1.C trunk/gcc/testsuite/g++.dg/warn/Winit-list2.C trunk/gcc/testsuite/g++.dg/warn/Winit-list3.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/cp/typeck.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/c-c++-common/pr43395.c trunk/gcc/testsuite/g++.dg/cpp1y/pr77591.C trunk/gcc/testsuite/g++.dg/warn/Wreturn-local-addr.C trunk/gcc/testsuite/g++.dg/warn/return-reference2.C trunk/gcc/testsuite/g++.old-deja/g++.bob/array1.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash55.C trunk/libstdc++-v3/testsuite/util/testsuite_random.h
[Bug c++/48562] [C++0x] warn about uses of initializer_list that will lead to dangling pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562 --- Comment #11 from Jason Merrill --- Author: jason Date: Tue May 29 20:04:52 2018 New Revision: 260905 URL: https://gcc.gnu.org/viewcvs?rev=260905&root=gcc&view=rev Log: PR c++/67445 - returning temporary initializer_list. PR c++/67711 - assigning from temporary initializer_list. PR c++/48562 - new initializer_list. * typeck.c (maybe_warn_about_returning_address_of_local): Also warn about returning local initializer_list. * cp-tree.h (AUTO_TEMP_NAME, TEMP_NAME_P): Remove. * call.c (build_over_call): Warn about assignment from temporary init_list. * init.c (build_new_1): Warn about 'new std::initializer_list'. (find_list_begin, maybe_warn_list_ctor): New. (perform_member_init): Use maybe_warn_list_ctor. Added: trunk/gcc/testsuite/g++.dg/warn/Winit-list1.C trunk/gcc/testsuite/g++.dg/warn/Winit-list2.C trunk/gcc/testsuite/g++.dg/warn/Winit-list3.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/cp/typeck.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/c-c++-common/pr43395.c trunk/gcc/testsuite/g++.dg/cpp1y/pr77591.C trunk/gcc/testsuite/g++.dg/warn/Wreturn-local-addr.C trunk/gcc/testsuite/g++.dg/warn/return-reference2.C trunk/gcc/testsuite/g++.old-deja/g++.bob/array1.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash55.C trunk/libstdc++-v3/testsuite/util/testsuite_random.h
[Bug c++/67711] Memory corruption when reassigning value to initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67711 --- Comment #2 from Jason Merrill --- Author: jason Date: Tue May 29 20:04:52 2018 New Revision: 260905 URL: https://gcc.gnu.org/viewcvs?rev=260905&root=gcc&view=rev Log: PR c++/67445 - returning temporary initializer_list. PR c++/67711 - assigning from temporary initializer_list. PR c++/48562 - new initializer_list. * typeck.c (maybe_warn_about_returning_address_of_local): Also warn about returning local initializer_list. * cp-tree.h (AUTO_TEMP_NAME, TEMP_NAME_P): Remove. * call.c (build_over_call): Warn about assignment from temporary init_list. * init.c (build_new_1): Warn about 'new std::initializer_list'. (find_list_begin, maybe_warn_list_ctor): New. (perform_member_init): Use maybe_warn_list_ctor. Added: trunk/gcc/testsuite/g++.dg/warn/Winit-list1.C trunk/gcc/testsuite/g++.dg/warn/Winit-list2.C trunk/gcc/testsuite/g++.dg/warn/Winit-list3.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/cp/typeck.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/c-c++-common/pr43395.c trunk/gcc/testsuite/g++.dg/cpp1y/pr77591.C trunk/gcc/testsuite/g++.dg/warn/Wreturn-local-addr.C trunk/gcc/testsuite/g++.dg/warn/return-reference2.C trunk/gcc/testsuite/g++.old-deja/g++.bob/array1.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash55.C trunk/libstdc++-v3/testsuite/util/testsuite_random.h
[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85981 --- Comment #4 from Steve Kargl --- On Tue, May 29, 2018 at 07:53:33PM +, kargl at gcc dot gnu.org wrote: > > I have a patch. > I have new patch.
[Bug c++/85976] ICE in cp_tree_equal when building Blitz. May be nested templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85976 --- Comment #4 from Marek Polacek --- Perhaps cp_tree_equal should just handle USING_DECL like other DECLs.
[Bug libfortran/85975] Incorrect size for spread array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85975 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-29 CC||kargl at gcc dot gnu.org, ||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- Stephan, I tried the simply patch suggested in your analysis and it does fix the problem. I need to extend the patch to fix the m4 files that utilize the macro as the 'b' parameter is no longer needed. I've also Paul to the CC list. He finished and sheparded the array descriptor reform into the tree. Paul, does Stephan's analysis look correct?
[Bug target/85984] ICE in create_pseudo_cfg, at dwarf2cfi.c:2874
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85984 Andrew Pinski changed: What|Removed |Added Target||x86_64-*-* Component|c |target --- Comment #1 from Andrew Pinski --- This code is undefined at runtime due to the use of naked and C code.
[Bug target/85986] New: config/rl78/rl78.c:984: bad test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85986 Bug ID: 85986 Summary: config/rl78/rl78.c:984: bad test ? Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Target: rl78 rl78/rl78.c:984:4: warning: logical ‘and’ of mutually exclusive tests is always false [-Wlogical-op] Source code is if (GET_CODE (XEXP (x, 0)) == SYMBOL_REF && GET_CODE (XEXP (x, 0)) == CONST_INT) Maybe better code if (GET_CODE (XEXP (x, 0)) == SYMBOL_REF || GET_CODE (XEXP (x, 0)) == CONST_INT)
[Bug tree-optimization/85987] New: cstore does not work with a store in one of the branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85987
Bug ID: 85987
Summary: cstore does not work with a store in one of the
branches
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod, int *t) {
if (isTestNet == 0) {
*t += 1;
*mod = (5);
} else {
*mod = (9);
}
}
Cstore does not work here and commonize the store to mod.
[Bug tree-optimization/85971] Really Simple "If" with one function call inside is not optimized efficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85971 Andrew Pinski changed: What|Removed |Added Depends on||85987 Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- I think this is actually two different bugs. One where cstore is not working when there is a function call inbetween. If I add an argument to CreateChecksum and change the first PolyMod to + t and the second PolyMod to * t. the cstore optimization work. This is recorded now as PR 85987. The second one is the lowering of common function calls with slightly different arguments. I thought I saw one asking for this one but I can't find it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85987 [Bug 85987] cstore does not work with a store in one of the branches
[Bug target/85986] config/rl78/rl78.c:984: bad test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85986 David Binderman changed: What|Removed |Added CC||dj at gcc dot gnu.org --- Comment #1 from David Binderman --- svn blame says 181819 dj if (GET_CODE (XEXP (x, 0)) == SYMBOL_REF 181819 dj && GET_CODE (XEXP (x, 0)) == CONST_INT)
[Bug c++/53281] poor error message for calling a non-const method from a const object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281 --- Comment #10 from Jonathan Wakely --- My patch fails to account for ref-qualifiers on the member function, so needs some improvement.
[Bug tree-optimization/85964] compile time hog w/ -O3 -ftracer -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85964 Eric Botcazou changed: What|Removed |Added Summary|[8/9 Regression] Compile|compile time hog w/ -O3 |time hog w/ -O3 -ftracer|-ftracer |-fno-guess-branch-probabili |-fno-guess-branch-probabili |ty |ty --- Comment #7 from Eric Botcazou --- Not a regression since #pragma GCC unroll is new.
