[Bug tree-optimization/67800] [6 Regression] Missed vectorization opportunity on x86 (DOT_PROD_EXPR in non-reduction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67800 --- Comment #6 from rguenther at suse dot de --- On Tue, 1 Dec 2015, afomin.mailbox at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67800 > > --- Comment #5 from Alexander Fomin --- > Richard, are there any updates on this? > > If BB vectorization support for reductions does not fit your plans for stage3, > we'd like to fix the regression by doing a partial revert described above. I will fix this PR in stage3 by either improving vectoirzation here or partially reverting the commit. Stay tuned.
[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-02 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |6.0 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Uroš Bizjak --- I'll take this.
[Bug ipa/68331] [meta-bug] fipa-pta issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331 --- Comment #8 from rguenther at suse dot de --- On Tue, 1 Dec 2015, vries at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331 > > --- Comment #5 from vries at gcc dot gnu.org --- > Created attachment 36885 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36885&action=edit > Abort solve_graph after num_edge passes threshold > > This patch aborts solve_graph after stats.num_edges passes 4.000.000. > > Using this patch, in combination with a -fipa-pta on-by-by-default patch, I'm > able to do a no-bootstrap build and reg-test. > > Test failures: > ... > libstdc++.sum:FAIL: experimental/filesystem/path/concat/strings.cc execution > test > libstdc++.sum:FAIL: experimental/filesystem/path/construct/locale.cc execution > test > ... I think limiting the number of edges is somewhat odd. I'd rather limit the number of varinfos created initially and maybe the number of solver iterations. And add some statistics to the whole solving process. Note that in theory the solver can just coalesce more vars (and thus edges) to make the solution quicker (and more imprecise). So giving up completely (and wasting work already done) isn't necessary. Of course the result from (IPA) PTA will then be a lot less "reliable" and reducing a testcase might end up "fixing" wrong-code bugs just because the solution becomes more precise (or the other way around). One has to visualize the solving process for some moderately complex testcase as I think the cycle elimination during the solving doesn't work reliably with the solving turning complex constraint into edges (well, not sure). Having unmerged direct cycles just slows down the solving and increases the memory use for the solutions.
[Bug tree-optimization/68640] foo restrict propagated to foo._omp_fn.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68640
--- Comment #1 from Richard Biener ---
Is it used because it ends up in the static chain of the omp_fn and uses the
same (original) qualifiers? And the static chain itself is passed "by
reference"
and thus gets its fields looked at and restrict extracted.
int
foo (int *__restrict__ ap)
{
int *bp = ap;
#pragma omp parallel for
for (unsigned int idx = 0; idx < N; idx++)
ap[idx] = bp[idx];
}
I believe this testcase is invalid as you access *ap through bp which is
not based on ap.
But your point is that "based on" is not properly passed through the
OMP lowering which will split out the use into a separate function
thus violating the constraints we set for restrict in PTA (_only_
derive it from parameters because their scope is fixed).
This would mean you need to drop restrict qualifiers for any pointers
you "leak" to the static chain (in the static chain field-decls type).
Yes, if we fix visit_loadstore for
/* ??? We need to make sure 'ptr' doesn't include any of
the restrict tags we added bases for in its points-to set. */
return false;
you may be able to create a miscompile here (if you manage to create a
valid testcase in the first place)
[Bug c++/66858] [6 Regression] FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison on aarch64-none-elf, arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66858 --- Comment #2 from Andrew Pinski --- This is related to maybe_retrofit_in_chrg somehow.
[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 36888 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36888&action=edit gcc6-pr68647.patch Untested fix.
[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647 --- Comment #3 from Jakub Jelinek --- Sorry Uros, forgot to assign this to myself before I've started to work on it.
[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647 --- Comment #4 from Jakub Jelinek --- I also wonder when we have expand_doubleword_clz if we couldn't handle expand_doubleword_ctz similarly.
[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68432 --- Comment #16 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed Dec 2 09:08:49 2015 New Revision: 231161 URL: https://gcc.gnu.org/viewcvs?rev=231161&root=gcc&view=rev Log: PR 68432: Add a target hook to control size/speed optab choices The problem in the PR is that some i386 optabs FAIL when optimising for size rather than speed. The gimple level generally needs access to this information before calling the generator, so this patch adds a new hook to say whether an optab should be used when optimising for size or speed. It also has a "both" option for cases where we want code that is optimised for both size and speed. I've passed the optab to the target hook because I think in most cases that's more useful than the instruction code. We could pass both if there's a use for it though. At the moment the match-and-simplify code doesn't have direct access to the target block, so for now I've used "both" there. Tested on x86_64-linux-gnu and powerpc64-linux-gnu. gcc/ PR tree-optimization/68432 * coretypes.h (optimization_type): New enum. * doc/tm.texi.in (TARGET_OPTAB_SUPPORTED_P): New hook. * doc/tm.texi: Regenerate. * target.def (optab_supported_p): New hook. * targhooks.h (default_optab_supported_p): Declare. * targhooks.c (default_optab_supported_p): New function. * predict.h (function_optimization_type): Declare. (bb_optimization_type): Likewise. * predict.c (function_optimization_type): New function. (bb_optimization_type): Likewise. * optabs-query.h (convert_optab_handler): Define an overload that takes an optimization type. (direct_optab_handler): Likewise. * optabs-query.c (convert_optab_handler): Likewise. (direct_optab_handler): Likewise. * internal-fn.h (direct_internal_fn_supported_p): Take an optimization_type argument. * internal-fn.c (direct_optab_supported_p): Likewise. (multi_vector_optab_supported_p): Likewise. (direct_internal_fn_supported_p): Likewise. * builtins.c (replacement_internal_fn): Update call to direct_internal_fn_supported_p. * gimple-match-head.c (build_call_internal): Likewise. * tree-vect-patterns.c (vect_recog_pow_pattern): Likewise. * tree-vect-stmts.c (vectorizable_internal_function): Likewise. * tree.c (maybe_build_call_expr_loc): Likewise. * config/i386/i386.c (ix86_optab_supported_p): New function. (TARGET_OPTAB_SUPPORTED_P): Define. * config/i386/i386.md (asinxf2): Remove optimize_insn_for_size_p check. (asin2, acosxf2, acos2, log1pxf2, log1p2) (expNcorexf3, expxf2, exp2, exp10xf2, exp102, exp2xf2) (exp22, expm1xf2, expm12, ldexpxf3, ldexp3) (scalbxf3, scalb3, rint2, round2) (xf2, 2): Likewise. gcc/testsuite/ * gcc.target/i386/pr68432-1.c: New test. * gcc.target/i386/pr68432-2.c: Likewise. * gcc.target/i386/pr68432-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr68432-1.c trunk/gcc/testsuite/gcc.target/i386/pr68432-2.c trunk/gcc/testsuite/gcc.target/i386/pr68432-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/coretypes.h trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/gimple-match-head.c trunk/gcc/internal-fn.c trunk/gcc/internal-fn.h trunk/gcc/optabs-query.c trunk/gcc/optabs-query.h trunk/gcc/predict.c trunk/gcc/predict.h trunk/gcc/target.def trunk/gcc/targhooks.c trunk/gcc/targhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree.c
[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68432 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug target/68651] New: [5/6 Regression][AArch64] Missing combination of shift-by-one with other arithmetic patterns with -mcpu=cortex-a53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68651
Bug ID: 68651
Summary: [5/6 Regression][AArch64] Missing combination of
shift-by-one with other arithmetic patterns with
-mcpu=cortex-a53
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
Consider the testcases:
int
foo (int x)
{
return (x * 2) & 65535;
}
int
bar (int x, int y)
{
return (x * 2) | y;
}
With GCC 4.9 for aarch64 with -O2 -mcpu=cortex-a53 we generated:
foo:
ubfiz w0, w0, 1, 15
ret
bar:
orr w0, w1, w0, lsl 1
ret
whereas with GCC 5 and trunk we fail to combine:
foo:
add w0, w0, w0
uxthw0, w0
ret
bar:
add w0, w0, w0
orr w0, w0, w1
ret
This is because of updated costs information for cortex-a53 which leads to
x * 2 being expanded as x + x rather than x << 1 and combine can't merge the
PLUS form.
This can be fixed simply by mutating the pattern during recog_for_combine in a
similar way to change_zero_ext
[Bug target/68647] __builtin_popcountll doesn't generate popcnt instructions when targeting -mpopcnt on x86_32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68647 --- Comment #5 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #3) > Sorry Uros, forgot to assign this to myself before I've started to work on > it. Ah, nice. I have a target-dependent patch for this, but I agree that generic solution is better.
[Bug target/68648] [4.9/5/6 Regression][ARM] ICE: fail to generate BIC(immediate) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68648 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||arm Status|UNCONFIRMED |NEW Known to work||4.8.5 Version|5.1.1 |4.9.4 Keywords||ice-on-valid-code Last reconfirmed||2015-12-02 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Summary|[5/6][ARM] ICE: fail to |[4.9/5/6 Regression][ARM] |generate BIC(immediate) |ICE: fail to generate |instruction |BIC(immediate) instruction Target Milestone|--- |4.9.5 Known to fail||4.9.4, 5.2.1, 6.0 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed with 4.9, 5 and trunk. 4.8 branch doesn't ICE
[Bug ipa/68064] [6 Regression] ICE: in meet_with, at ipa-cp.c:874
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68064 --- Comment #5 from Markus Trippelsdorf --- Any update on this issue?
[Bug c++/65731] _ZSt8__fill_aIPmiEN9__gnu_cxx11__enable_ifIXsr11__is_scalarIT0_EE7__valueEvE6__typeET_S6_RKS3_ not demanglable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65731 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-02 Component|other |c++ Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- __gnu_cxx::__enable_if<__is_scalar::__value, int*>::__type std::__fill_n_a(int*, unsigned long, int const&) and __gnu_cxx::__enable_if<__is_scalar::__value, void>::__type std::__fill_a(unsigned long*, unsigned long*, int const&) would be the correct answer.
[Bug lto/65982] [5/6 Regression] ICE: in lto_output_varpool_node, at lto-cgraph.c:623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65982 --- Comment #3 from Markus Trippelsdorf --- Honza?
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-02 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- I think it is a duplicate of pr68560. > This smells like a fortran front-end issue where _gfortran_reshape_r8's decl > is created twice with two different argument types. I don't think so. I think -Wlto-type-mismatch does not know part of the Fortran syntax.
[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67778 --- Comment #12 from Segher Boessenkool --- Yes, I'm cross-compiling. The only differences I see are: * -fdwarf2-cfi-asm; this seemed promising but makes no difference. * -mtune=generic -march=x86-64; but no dice. * Very different ggc settings. * Different GMP etc. versions. The code coming in to shrink-wrap is different already. Anyway, I have reproduced the problem (on gcc20), and I know what the problem is. Will have to think a bit on how to properly solve it. And it seems I didn't read your #c5 very carefully, ugh. Sorry.
[Bug tree-optimization/68625] [6 Regression] Segmentation fault in useless_type_conversion_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68625 --- Comment #3 from Richard Biener --- Author: rguenth Date: Wed Dec 2 09:47:43 2015 New Revision: 231162 URL: https://gcc.gnu.org/viewcvs?rev=231162&root=gcc&view=rev Log: 2015-12-02 Richard Biener PR tree-optimization/68625 * tree-cfgcleanup.c (cleanup_tree_cfg_bb): Do not call cleanup_control_flow_bb. (cleanup_tree_cfg_1): First perform cleanup_control_flow_bb on all BBs, then cleanup_tree_cfg_bb and finally iterate over the worklist doing both. * gcc.dg/torture/pr68625.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr68625.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfgcleanup.c
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Joost VandeVondele changed: What|Removed |Added Status|WAITING |UNCONFIRMED Depends on||68560 Ever confirmed|1 |0 --- Comment #5 from Joost VandeVondele --- (In reply to Dominique d'Humieres from comment #4) > I think it is a duplicate of pr68560. seems certainly related, but PR68560 doesn't yield the worrying 'code may be misoptimized unless -fno-strict-aliasing is used'. I'll just add a dependency. > > > This smells like a fortran front-end issue where _gfortran_reshape_r8's decl > > is created twice with two different argument types. > > I don't think so. I think -Wlto-type-mismatch does not know part of the > Fortran syntax. I'm thinking the issue is on the Fortran FE side, LTO shouldn't know the language involved. I guess some middle end person might need to have a look however. I'm guessing it is related to the fact that _gfortran_reshape_r8 is being called with different pointer arguments (from -fdump-tree-original): struct array1_real(kind=8) parm.0; _gfortran_reshape_r8 (&parm.0, D.3433, D.3437, 0B, 0B); struct array2_real(kind=8) parm.4; _gfortran_reshape_r8 (&parm.4, D.3446, D.3450, 0B, 0B); maybe for correctness there should be some casts ? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560 [Bug 68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #16 from Alexander --- there are ld -V ld: 92453-07 linker ld HP Itanium(R) B.12.62 IPF/IPF
[Bug tree-optimization/68625] [6 Regression] Segmentation fault in useless_type_conversion_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68625 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #17 from John Buddery --- My ld is slightly older: ld: 92453-07 linker ld HP Itanium(R) B.12.42 IPF/IPF It may have been older still when I built gcc, as OS patches have been applied since then.
[Bug middle-end/68570] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68570 --- Comment #6 from Marek Polacek --- Yes, this is fixed with r231162 (PR68625 fix). I'll at least add the testcase...
[Bug target/68651] [5/6 Regression][AArch64] Missing combination of shift-by-one with other arithmetic patterns with -mcpu=cortex-a53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68651 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.4
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 --- Comment #20 from Martin Liška --- (In reply to milan.plzik from comment #19) > Created attachment 36886 [details] > Shell script, which compiles ChibiOS and indeed triggers gcc failure > > Attached script should trigger the problem when compiling ChibiOS sources. Hi. Well the script is fine, however it requires a base metal compiler. Would it be possible to run the test-case on one of there cross compilers: cross-armv6hl-gcc5 cross-armv7hl-gcc5 Or I can test it on an aarch64 machine, does it expose the failure? Problem with the issue is that it requires multiple LTO object files that eventually trigger the failure. Thanks, Martin
[Bug libfortran/68652] New: gamma function hangs on some arguments, returns NaN on other ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68652 Bug ID: 68652 Summary: gamma function hangs on some arguments, returns NaN on other ones Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: arbautjc at gmail dot com Target Milestone: --- This happens with gfortran in MinGW-W64 (precisely x86_64-4.9.3-release-win32-seh-rt_v4-rev1.7z at http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.3/threads-win32/seh/). So it may be a problem with components external to gfortran. The OS is Windows 7 Pro, 64 bits. Forgive me if it's not the right place to post the bug report. Anyway, here is what goes wrong: program bug implicit none real(4) :: x, y do read *, x y = gamma(x) print *, y end do end program With real(4), and an argument that is an integer value (in a real variable, of course): x=1 to 35: y has a finite real value, no problem x=36 to 16777218: y is Infinity, as expected x=16777219 or above: program hangs. Notice that 2^24=16777216, by the way. With real(8) x=1 to 171: finite real x=172 to 709: Infinity x=710 or above: NaN, which is not expected (it should be Infinity).
[Bug lto/68646] [6 Regression] FAIL: g++.dg/lto/20081118 cp_lto_20081118_0.o-cp_lto_20081118_1.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68646 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |6.0 Summary|FAIL: g++.dg/lto/20081118 |[6 Regression] FAIL: |cp_lto_20081118_0.o-cp_lto_ |g++.dg/lto/20081118 |20081118_1.o link |cp_lto_20081118_0.o-cp_lto_ ||20081118_1.o link --- Comment #1 from Richard Biener --- Might have been fixed recently.
[Bug c++/68645] [6 Regression] FAIL: c-c++-common/attr-simd-3.c -std=gnu++11 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68645 Richard Biener changed: What|Removed |Added Target|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, ||x86_64-linux Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-02 Host|hppa-unknown-linux-gnu | Target Milestone|--- |6.0 Summary|FAIL: |[6 Regression] FAIL: |c-c++-common/attr-simd-3.c |c-c++-common/attr-simd-3.c |-std=gnu++11 (test for |-std=gnu++11 (test for |excess errors) |excess errors) Ever confirmed|0 |1 Build|hppa-unknown-linux-gnu | --- Comment #1 from Richard Biener --- Confirmed on x86_64-linux.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #18 from Joseph John --- Alexander, You were also able to build build gcc using almost the latest linker ? My linker is nearly same as yours so I was thinking is it some linker bugs which causes issues for me as I saw some references (although old) as below: http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=pdb_na-PHSS_43584&sp4ts.oid=417289&lang=en-us&cc=us " PHSS_42043: QXCR1001112198: linktime error seen - overflow while applying PCREL21B relocation "
[Bug tree-optimization/68644] [6 Regression] FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 Summary|FAIL: |[6 Regression] FAIL: |gcc.dg/tree-ssa/ivopts-lt-2 |gcc.dg/tree-ssa/ivopts-lt-2 |.c scan-tree-dump-times |.c scan-tree-dump-times |ivopts "PHI --- Please attach ivopts-details-scev dumps.
[Bug testsuite/68643] FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler foo[._]+cold[._]+0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68643
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2015-12-02
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
/* { dg-require-effective-target freorder } */
so this is set wrongly for your target? Or rather
# Return 1 if compilation with -freorder-blocks-and-partition is error-free
# for trivial code, 0 otherwise.
proc check_effective_target_freorder {} {
return [check_no_compiler_messages freorder object {
void foo (void) { }
} "-freorder-blocks-and-partition"]
}
is not working for some reason?
[Bug middle-end/68570] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68570 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Done.
[Bug tree-optimization/68640] foo restrict propagated to foo._omp_fn.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68640
--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Is it used because it ends up in the static chain of the omp_fn and uses the
> same (original) qualifiers? And the static chain itself is passed "by
> reference"
> and thus gets its fields looked at and restrict extracted.
AFAIU, the static chain is only used for nested functions, and the omp_fn's are
not (though similar). So I guess you mean the single function argument pointing
to a struct that contains the base pointers used in omp_fns.
Yes, that argument points to a struct where the fields use the same qualifiers
as in the original function (although in some cases, there will be a pointer
indirection introduced inbetween, which will cause the restrict to have no
effect). And that argument is passed as a restrict reference and thus gets its
field looked at and restrict extracted (btw the same would happen if the
argument was a restrict pointer).
The restrict on the fields is set in install_var_field (by using the exact
type, rather than clearing some qualifiers).
> int
> foo (int *__restrict__ ap)
> {
> int *bp = ap;
> #pragma omp parallel for
> for (unsigned int idx = 0; idx < N; idx++)
> ap[idx] = bp[idx];
> }
>
> I believe this testcase is invalid as you access *ap through bp which is
> not based on ap.
>
Modifying ap to point to a copy of *ap will modify the value of bp (when done
before the copy from ap to bp), so to me it looks like bp is based on ap.
> But your point is that "based on" is not properly passed through the
> OMP lowering which will split out the use into a separate function
> thus violating the constraints we set for restrict in PTA (_only_
> derive it from parameters because their scope is fixed).
Basically we redeclare ap as restrict pointer ap in the scope foo._omp_fn.0.
And bp is not based on the redeclared ap, so this violates restrict.
It's similar to rewriting this legal example:
...
{
int *restrict ap = ...
int *bp = ap;
{
int *ap2 = ap;
*ap2 = 1;
*bp = 2;
}
}
...
into this illegal example:
...
{
int *restrict ap = ...
int *bp = ap;
{
int *restrict ap2 = ap;
*ap2 = 1;
*bp = 2;
}
}
...
It becomes illegal by adding restrict to ap2. It is illegal because bp is not
based on ap2.
> This would mean you need to drop restrict qualifiers for any pointers
> you "leak" to the static chain (in the static chain field-decls type).
>
Right, clearing the restrict qualifier on pointers in install_var_field would
fix this.
> Yes, if we fix visit_loadstore for
>
> /* ??? We need to make sure 'ptr' doesn't include any of
> the restrict tags we added bases for in its points-to set. */
> return false;
>
> you may be able to create a miscompile here (if you manage to create a
> valid testcase in the first place)
I still think the testcase is valid.
[Bug middle-end/68570] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68570 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Wed Dec 2 10:22:23 2015 New Revision: 231163 URL: https://gcc.gnu.org/viewcvs?rev=231163&root=gcc&view=rev Log: PR middle-end/68570 * gcc.dg/torture/pr68570.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr68570.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-02 CC||law at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Component|middle-end |rtl-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- This is probably caused by init-regs.c which is done conditionally on optimize > 0 only. IMHO it should be removed (this was discussed repeatedly in the past).
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 Richard Biener changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Richard Biener --- I remember bootstrapping and testing with the pass removed just works.
[Bug ipa/65654] [7 Regression] 447.dealII in SPEC CPU 2006 failed to build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654 Richard Biener changed: What|Removed |Added Target Milestone|6.0 |7.0 Summary|[6 Regression] 447.dealII |[7 Regression] 447.dealII |in SPEC CPU 2006 failed to |in SPEC CPU 2006 failed to |build with LTO |build with LTO --- Comment #7 from Richard Biener --- It was made P1 to make you fix it during stage1 of GCC 6 ;) But yes, re-targeting to GCC 7.
[Bug preprocessor/68638] [6 Regression] ICE in linemap_macro_map_lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68638 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug tree-optimization/68639] [6 Regression] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68639 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine then.
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 Eric Botcazou changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Eric Botcazou --- The whole reasoning looks fairly dubious to me, the optimizer is free to do whatever it wants on undefined behavior and requests that the generated code behaves identically at all optimization levels on it have little merit IMO.
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #4 from rguenther at suse dot de --- On Wed, 2 Dec 2015, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 > > Eric Botcazou changed: > >What|Removed |Added > >Severity|normal |enhancement > > --- Comment #3 from Eric Botcazou --- > The whole reasoning looks fairly dubious to me, the optimizer is free to do > whatever it wants on undefined behavior and requests that the generated code > behaves identically at all optimization levels on it have little merit IMO. True, just that we avoid uninitialized regs at -O1+ but not on -O0 makes this one valid. OTOH I'd just use it as an excuse to drop init-regs.c ...
[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 --- Comment #21 from milan.plzik at gmail dot com --- Unfortunately, I currently don't have dev setup for any non-MCU ARM platform. Also, ChibiOS non-MCU platforms, so I guess I would need to identify different test case, assuming it is possible to trigger this error on non-bare-metal platforms. Anyway, if this is wrong place to report problems with bare-metal gcc targets, please let me know where should this be filed :).
[Bug libfortran/68652] gamma function hangs on some arguments, returns NaN on other ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68652 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- WORKSFORME on x86_64-apple-darwin14 from 4.8 up to trunk (6.0). It looks like a system library problem. Did you ask for help upstream (MinGW)?
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #5 from Richard Biener --- See PR61810 which shows missed optimizations because of init-regs.c
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #6 from Eric Botcazou --- > OTOH I'd just use it as an excuse to drop init-regs.c ... It has a rather big comment explaining why it was needed though.
[Bug libfortran/68652] gamma function hangs on some arguments, returns NaN on other ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68652 --- Comment #2 from Jean-Claude Arbaut --- I will. I was unsure were to post the report, so I tried first here. Thanks to have checked!
[Bug tree-optimization/68522] [6 Regression] SPEC CPU2006 435.gromacs miscomparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68522 --- Comment #1 from Alexander Fomin --- We compile it using -m32 -Ofast -funroll-loops -fno-agressive-loop-optimizations option set.
[Bug c++/68653] New: [6 Regression] ICE: in nonnull_arg_p, at tree.c:13853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68653 Bug ID: 68653 Summary: [6 Regression] ICE: in nonnull_arg_p, at tree.c:13853 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: mark at gcc dot gnu.org Target Milestone: --- x4 duchain # g++ -march=amdfam10 -c declarationbuilder.ii x4 duchain # g++ -march=amdfam10 -c -Wall declarationbuilder.ii /var/tmp/portage/dev-util/kdevelop-/work/kdevelop-/languages/qmljs/duchain/declarationbuilder.cpp: In instantiation of ‘void DeclarationBuilder::declareParameters(Node*, QStringRef Node::*) [with Node = QmlJS::AST::FormalParameterList]’: /var/tmp/portage/dev-util/kdevelop-/work/kdevelop-/languages/qmljs/duchain/declarationbuilder.cpp:259:83: required from here /var/tmp/portage/dev-util/kdevelop-/work/kdevelop-/languages/qmljs/duchain/declarationbuilder.cpp:207:49: internal compiler error: in nonnull_arg_p, at tree.c:13853 Probably started with r227649. Reducing..
[Bug target/68648] [4.9/5/6 Regression][ARM] ICE: fail to generate BIC(immediate) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68648 --- Comment #2 from ktkachov at gcc dot gnu.org --- The problem is the post-reload andsi_iorsi3_notsi splitter that can generate a (not (const_int 1)) rtx rather than doing constant folding
[Bug target/68648] [4.9/5/6 Regression][ARM] ICE: fail to generate BIC(immediate) instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68648 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- I'm testing a patch.
[Bug target/61810] init-regs.c papers over issues elsewhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810
--- Comment #1 from Richard Biener ---
For
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap7.c execution test
it indeed 'makes combine happy' with enabled vs. disabled diff
***
*** 912,935
(plus:QI (reg:QI 264 [ ivtmp.50 ])
(const_int -3 [0xfffd])))
! Trying 401 -> 186:
Failed to match this instruction:
(set (pc)
! (pc))
! Successfully matched this instruction:
! (set (pc)
! (label_ref 191))
! allowing combination of insns 401 and 186
! original costs 4 + 4 = 0
! replacement cost 4
! deferring deletion of insn with uid = 401.
! modifying other_insn 187: pc=L191
! REG_BR_PROB 9996
! deferring rescan insn with uid = 187.
Trying 193 -> 197:
Failed to match this instruction:
--- 911,923
(plus:QI (reg:QI 264 [ ivtmp.50 ])
(const_int -3 [0xfffd])))
! Trying 186 -> 187:
Failed to match this instruction:
(set (pc)
! (if_then_else (eq (reg/v:QI 255 [ y ])
! (const_int 0 [0]))
! (label_ref 191)
! (pc)))
Trying 193 -> 197:
Failed to match this instruction:
where 'y' is unused and has a set to zero. But this shows an issue with
the testcase which uses uninitialized y to abort(!)
__attribute__ ((noinline)) int
main1 ()
{
int i;
s arr[N];
s *ptr = arr;
s res[N];
unsigned char u, t, s, x, y, z, w;
for (i = 0; i < N; i++)
{
arr[i].a = i;
arr[i].b = i * 2;
arr[i].c = 17;
arr[i].d = i+34;
arr[i].e = i * 3 + 5;
arr[i].f = i * 5;
arr[i].g = i - 3;
arr[i].h = 67;
if (y) /* Avoid vectorization. */
abort ();
}
probably in the others as well. I'm going to fix those.
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres --- > seems certainly related, but PR68560 doesn't yield the worrying > 'code may be misoptimized unless -fno-strict-aliasing is used'. > I'll just add a dependency. IMO these warnings are false positive (aka bogus). The minimal set of options to get the warning for the test in comment 1 is '-flto -fstrict-aliasing'. > I'm thinking the issue is on the Fortran FE side, LTO shouldn't know > the language involved. I guess some middle end person might need to have > a look however. IMO the first step is to understand why LTO is emitting these warning on valid Fortran code. Then, if this not due to a bug in LTO, it will be time to find how Fortran intrinsics have to be "decorated" to avoid the warnings.
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #7 from rguenther at suse dot de --- On Wed, 2 Dec 2015, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 > > --- Comment #6 from Eric Botcazou --- > > OTOH I'd just use it as an excuse to drop init-regs.c ... > > It has a rather big comment explaining why it was needed though. Handwaving ones w/o testcase and appearantly without making sure such uses never get re-introduced after it (and the offending un-named places)
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #8 from Joost VandeVondele --- (In reply to Eric Botcazou from comment #3) > The whole reasoning looks fairly dubious to me, the optimizer is free to do > whatever it wants on undefined behavior and requests that the generated code > behaves identically at all optimization levels on it have little merit IMO. Of course, I agree that the code has undefined behavior, and that 'all bets are off'. It just makes it more difficult for users to spot this undefined behavior, we run our testsuite every night under valgrind, but can't move from -O1 to -O0, since that would add a couple of hours to the test. Admittedly, -fsanitize=memory would be a better solution, but it is not available with gcc.
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #9 from rguenther at suse dot de --- On Wed, 2 Dec 2015, Joost.VandeVondele at mat dot ethz.ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 > > Joost VandeVondele changed: > >What|Removed |Added > > CC||Joost.VandeVondele at mat > dot ethz >||.ch > > --- Comment #8 from Joost VandeVondele ethz.ch> --- > (In reply to Eric Botcazou from comment #3) > > The whole reasoning looks fairly dubious to me, the optimizer is free to do > > whatever it wants on undefined behavior and requests that the generated code > > behaves identically at all optimization levels on it have little merit IMO. > > Of course, I agree that the code has undefined behavior, and that 'all bets > are > off'. > > It just makes it more difficult for users to spot this undefined > behavior, we run our testsuite every night under valgrind, but can't > move from -O1 to -O0, since that would add a couple of hours to the > test. Admittedly, -fsanitize=memory would be a better solution, but it > is not available with gcc. Though with the testcase you gave we warn at both -O0 and -O1: > gfortran-5 t.f90 -c -Wall -O t.f90:3:0: IF (i/=0) CALL link_error ^ Warning: ‘i’ is used uninitialized in this function [-Wuninitialized] t.f90:4:0: IF (ASSOCIATED(foo)) CALL link_error ^ Warning: ‘foo’ is used uninitialized in this function [-Wuninitialized]
[Bug rtl-optimization/68304] [6 Regression] FAIL: gcc.c-torture/compile/950612-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68304 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi John, I just tried to reproduce this using the current (r231159) sources and I could not. Ie the test compiled without problems. Perhaps this bug has already been fixed ? Cheers Nick
[Bug target/61810] init-regs.c papers over issues elsewhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810 --- Comment #2 from Richard Biener --- vect testsuite is now clean on trunk.
[Bug c++/68653] [6 Regression] ICE: in nonnull_arg_p, at tree.c:13853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68653 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #10 from Joost VandeVondele --- (In reply to rguent...@suse.de from comment #9) > Though with the testcase you gave we warn at both -O0 and -O1: yes, but unfortunately, -Wuninitialized, also warns for 'may be used uninitialized' which are too often false positives, and sometimes even compiler generated variables as in PR67679. A -Wmust-be-uninitialized (which seemingly the compiler could do as the comment on top of init-regs.c suggests) would be valuable. [I just checked that -Wuninitialized -Wno-maybe-uninitialized doesn't work]
[Bug c/68193] _Generic -Woverflow false alarm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- The problem here is that after we've parsed the selector (with warnings inhibited), we go over all the associations: process the type-name, then parse assignment-expression of the association also using c_parser_expr_no_commas, but this time without the warnings inhibited. We should probably disable warnings when processing the associations and only warn for matched_assoc. But I can't readily conceive how to do that.
[Bug preprocessor/68638] [6 Regression] ICE in linemap_macro_map_lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68638 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Martin, I tried to reproduce this problem using the latest (r231159) sources bug could not. I tried both an x86_64-pc-linux-gnu toolchain and an mep-elf toolchain. Is it possible that this bug has already been fixed ? Cheers Nick
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #11 from Marc Glisse --- (In reply to Joost VandeVondele from comment #10) > [I just checked that -Wuninitialized -Wno-maybe-uninitialized doesn't work] That sounds like a bug. It works for me on a simple C testcase.
[Bug c++/68653] [6 Regression] ICE: in nonnull_arg_p, at tree.c:13853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68653
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-12-02
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
markus@x4 tmp % cat declarationbuilder.ii
struct B;
struct A {
template void declareParameters(Node *, int Node::*);
bool visit(B *);
};
template void A::declareParameters(Node *, int Node::*p2) {
p2 ? nullptr : new int;
}
bool A::visit(B *p1) {
declareParameters(p1, (int B::*)nullptr);
return true;
}
markus@x4 tmp % g++ -c -Wall declarationbuilder.ii
declarationbuilder.ii: In instantiation of ‘void A::declareParameters(Node*,
int Node::*) [with Node = B]’:
declarationbuilder.ii:10:42: required from here
declarationbuilder.ii:7:6: internal compiler error: in nonnull_arg_p, at
tree.c:13853
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #12 from Joost VandeVondele --- (In reply to Marc Glisse from comment #11) > That sounds like a bug. It works for me on a simple C testcase. sorry, fat fingers on my side. So, yes, this works gfortran -c -Werror=uninitialized -Wno-maybe-uninitialized test.f90 I believe this would practically resolve this PR from my point of view.
[Bug tree-optimization/67800] [6 Regression] Missed vectorization opportunity on x86 (DOT_PROD_EXPR in non-reduction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67800 --- Comment #7 from Richard Biener --- Ah, so reverting these changes causes FAIL: gcc.dg/vect/slp-reduc-sad.c scan-tree-dump vect "vectorizing stmts using SLP" FAIL: gcc.dg/vect/slp-reduc-sad.c scan-tree-dump-times vect "vectorized 1 loops" 1 with similar testcases using a dot product or widening sum pattern would need to be added. Note that the above are in reduction context but only the first stmt of the reduction chain is marked as such. Thus we need to amend the check with ! STMT_VINFO_GROUP_FIRST_ELEMENT (stmt_vinfo). Testing that now.
[Bug rtl-optimization/68304] [6 Regression] FAIL: gcc.c-torture/compile/950612-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68304 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from John David Anglin --- Did not occur in last build.
[Bug tree-optimization/68654] New: [6 Regression] CoreMark Pro performance degradation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654 Bug ID: 68654 Summary: [6 Regression] CoreMark Pro performance degradation Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: afomin.mailbox at gmail dot com CC: izamyatin at gmail dot com, law at redhat dot com Target Milestone: --- Target: i686-*-* After r228668 we can see a performance degradation in CoreMark Pro benchmark compiled with -m32 -Ofast -funroll-loops for Haswell CPU.
[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654 --- Comment #1 from Alexander Fomin --- The degrading test is naturally CoreMark itself.
[Bug testsuite/68643] FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler foo[._]+cold[._]+0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68643
--- Comment #2 from dave.anglin at bell dot net ---
On 2015-12-02, at 5:22 AM, rguenth at gcc dot gnu.org wrote:
> so this is set wrongly for your target? Or rather
>
> # Return 1 if compilation with -freorder-blocks-and-partition is error-free
> # for trivial code, 0 otherwise.
>
> proc check_effective_target_freorder {} {
>return [check_no_compiler_messages freorder object {
>void foo (void) { }
>} "-freorder-blocks-and-partition"]
> }
>
> is not working for some reason?
With gcc-6, foo compiles without error. With gcc-5,
dave@mx3210:~/gnu/gcc/objdir$ gcc -freorder-blocks-and-partition -S -O2 xxx.c
xxx.c:1:0: note: -freorder-blocks-and-partition does not work on this
architecture
void foo (void) { }
^
We have in pa.c (pa_option_override):
/* Disable -freorder-blocks-and-partition as we don't support hot and
cold partitioning. */
if (flag_reorder_blocks_and_partition)
{
inform (input_location,
"-freorder-blocks-and-partition does not work "
"on this architecture");
flag_reorder_blocks_and_partition = 0;
flag_reorder_blocks = 1;
}
--
John David Anglin dave.ang...@bell.net
[Bug tree-optimization/66051] can't vectorize reductions inside an SLP group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66051
--- Comment #2 from Richard Biener ---
We now run itno
t.c:4:3: note: Build SLP failed: the number of interleaved loads is greater
than the SLP group size _15 = *_14;
which should be an irrelevant restriction in the form it makes (with only
considering gaps at the end of the group reducing the "number of interleaved
loads"). Whenever this condition triggers the load will be "permuted"
to be of proper size.
Indeed:
t.c:4:3: note: Load permutation 0 1 2 3 4 5 6 7
t.c:4:3: note: unsupported vect permute { 0 1 2 3 8 9 10 11 }
t.c:4:3: note: Build SLP failed: unsupported load permutation *_9 = _22;
which for some reason isn't supported by plain SSE2 while it should
simply able to use movlhps.
[Bug target/68655] New: SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
Bug ID: 68655
Summary: SSE2 cannot vec_perm of low and high part
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: uros at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
typedef unsigned short v8hi __attribute__((vector_size(16)));
v8hi foo (v8hi a, v8hi b)
{
return __builtin_shuffle (a, b, (v8hi) { 0, 1, 2, 3, 8, 9, 10, 11 });
}
should be able to use
movlhps %xmm0, %xmm1
ret
but ends up being lowered by vector lowering because the target says
it cannot can_vec_perm_p (V8HI, false, { 0, 1, 2, 3, 8, 9, 10, 11 })
There are also two-instruction permutes possible with movhl/lhps
like { 0, 1, 2, 3, 12, 13, 14, 15 } can use
movhlps %xmm1, %xmm1
movlhps %xmm0, %xmm1
ah, that uses shufpd. Not sure why the above doesn't use shufpd if that
is available in SSE2.
[Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67383
Renlin Li changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #7 from Renlin Li ---
Backport committed as r231177. It should fix the ICE in the particular case.
However, this is not the whole story. I just found another problem.
In the test case, there are code structure like this.
uint64_t callee (int a, int b, int c, int d);
uint64_t caller (int a, int b, int c, int d)
{
uint64_t res;
/*
single BB contains complicated data processing which requires register pair
*/
res = callee (tmp, b ,c, d);
return res;
}
CES pass in this case will extend the hard register live range across the whole
BB until the callee. In this case, r1, r2, r3 are excluded from allocatable
registers.
There are places in CES which prevents extending the hard register's live
range, for example for hard register which fullfil
small_register_classes_for_mode_p(), class_likely_spilled_p(). However,
argument registers belong to neither of them.
I tried to stop CES from extending argument registers live range. However,
later, scheduler jumps in and re-orders the instruction to reduce the pseudo
register pressure, which in effect extend the argument register live again.
[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-02 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Can you please produce a testcase from the relevant part of CoreMark?
[Bug c/68656] New: [4.8, 4.9, 5.0, 6.0 Regression] warning about disabled var-tracking uses odd location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68656 Bug ID: 68656 Summary: [4.8, 4.9, 5.0, 6.0 Regression] warning about disabled var-tracking uses odd location info Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: aldot at gcc dot gnu.org CC: dodji at gcc dot gnu.org Target Milestone: --- echo "/* This is a bugreport about using odd locations. */" > bug.c gcc -c bug.c -fvar-tracking -o /dev/null bug.c:1:0: warning: variable tracking requested, but useless unless producing debug info /* This is a bugreport about using odd locations. */ ^ on stdin this looks like expected: $ echo "/* This is a bugreport about using odd locations. */" | gcc -xc -c - -g -fvar-tracking -gtoggle -o /dev/null :1:0: warning: variable tracking requested, but useless unless producing debug info $ Known to work: 4.7.4 $ gcc-4.7 -c bug.c -fvar-tracking -o /dev/null bug.c:1:0: warning: variable tracking requested, but useless unless producing debug info [enabled by default] Fails: 4.8.5 $ gcc-4.8 -c bug.c -fvar-tracking -o /dev/null bug.c:1:0: warning: variable tracking requested, but useless unless producing debug info [enabled by default] /* This is a bugreport about using odd locations. */ ^
[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654 --- Comment #3 from Richard Biener --- Btw, that revision is unlikely a bisect, correct? It should have zero effects on code generation.
[Bug c/68656] [4.9/5/6 Regression] warning about disabled var-tracking uses odd location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68656 Richard Biener changed: What|Removed |Added Summary|[4.8, 4.9, 5.0, 6.0 |[4.9/5/6 Regression] |Regression] warning about |warning about disabled |disabled var-tracking uses |var-tracking uses odd |odd location info |location info --- Comment #1 from Richard Biener --- Which version worked ok? I think these warnings should simply not output any location (well, as we now have per-function optimization settings such warning may apply only for certain functions...)
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #8 from Dominique d'Humieres --- Compiling gfortran.dg/goacc/coarray.f95 with '-fcoarray=single -fopenacc' gives now an ICE /opt/gcc/_clean/gcc/testsuite/gfortran.dg/goacc/coarray.f95:23:0: !$acc parallel loop reduction(+:a) internal compiler error: in lower_oacc_reductions, at omp-low.c:5437 The change occurred between revisions r231086 (no ICE) and r231131 (ICE).
[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654 --- Comment #4 from Alexander Fomin --- It should, but for some reason we see a stable reproducible degradation between r228667 and r228668...
[Bug libfortran/68652] gamma function hangs on some arguments, returns NaN on other ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68652 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- Also works for me on Linux.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux and aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 Christophe Lyon changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #59 from Christophe Lyon --- I think this can be closed.
[Bug c/68657] New: [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657 Bug ID: 68657 Summary: [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Using touch test.ii test.i with gcc -Werror=sign-conversion test.i or g++ -Werror=sign-conversion test.i shows: cc1plus: error: -Werror=sign-conversion: -Wsign-conversion is not an option that controls warnings Using GCC 5 it works. In gcc/c-family/c.opt, one has: Wsign-conversion C ObjC C++ ObjC++ Var(warn_sign_conversion) LangEnabledBy(C ObjC,Wconversion) Warn for implicit type conversions between signed and unsigned integers.
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
--- Comment #1 from Richard Biener ---
typedef int v4si __attribute__((vector_size(16)));
v4si bar (v4si a, v4si b)
{
return __builtin_shuffle (a, b, (v4si) { 0, 1, 4, 5 });
}
works just fine using shufps.
It might be that the generic optabs code should try using larger element modes
if the permutation allows that. It already tries QImode as fallback.
OTOH as
v8hi baz (v8hi a, v8hi b)
{
return __builtin_shuffle (a, b, (v8hi) { 0, 1, 2, 3, 12, 13, 14, 15 });
}
works and uses shufpd the x86 backend seems to be somewhat prepared for
the above.
[Bug c/68656] [4.9/5/6 Regression] warning about disabled var-tracking uses odd location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68656 --- Comment #2 from Bernhard Reutner-Fischer --- (In reply to Richard Biener from comment #1) > Which version worked ok? I think these warnings should simply not output 4.7.4 worked ok. 4.8.5 onward behave like current trunk a.k.a 6.0 > any location (well, as we now have per-function optimization settings such > warning > may apply only for certain functions...) If it's per-function, it'd be ok to output the location, i'd say. For file-scope it doesn't make sense to me. thanks,
[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657 Tobias Burnus changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |6.0 --- Comment #1 from Tobias Burnus --- Seems as if "Warning" is missing in the second line of the *.opt. Also affected seem to be: c-family/c.opt:Wpsabi c-family/c.opt-C ObjC C++ ObjC++ LTO Var(warn_psabi) Init(1) Undocumented LangEnabledBy(C ObjC C++ ObjC++,Wabi) c-family/c.opt:Wfloat-conversion c-family/c.opt-C ObjC C++ ObjC++ Var(warn_float_conversion) LangEnabledBy(C ObjC C++ ObjC++,Wconversion) java/lang.opt:Wdeprecated java/lang.opt-Java Var(warn_deprecated) java/lang.opt:Wextraneous-semicolon java/lang.opt-Java Var(flag_extraneous_semicolon) java/lang.opt:Wout-of-date java/lang.opt-Java Var(flag_newer) Init(1) java/lang.opt:Wredundant-modifiers java/lang.opt-Java Var(flag_redundant)
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Dominique d'Humieres changed: What|Removed |Added CC||jules at gcc dot gnu.org --- Comment #9 from Dominique d'Humieres --- > The change occurred between revisions r231086 (no ICE) and r231131 (ICE). Reduced range from https://gcc.gnu.org/ml/gcc-regression/2015-12/ r231109 (no ICE), r231121 (ICE), likely r231112 or r231118.
[Bug gcov-profile/68603] [6 Regression] FAIL: g++.dg/gcov/gcov-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68603 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655 Uroš Bizjak changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Uroš Bizjak --- CC Jakub.
[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67778 Segher Boessenkool changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #13 from Segher Boessenkool --- *** Bug 68634 has been marked as a duplicate of this bug. ***
[Bug target/68634] [6 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2284 w/ -O2 -fmodulo-sched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68634 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Segher Boessenkool --- Yeah, same issue. *** This bug has been marked as a duplicate of bug 67778 ***
[Bug libstdc++/56383] error with multiple enable_shared_from_this base classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56383 Jonathan Wakely changed: What|Removed |Added Target Milestone|5.3 |4.9.4 --- Comment #3 from Jonathan Wakely --- I'm about to fix this on trunk, and will backport to the branches after 5.3 is released.
[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657 Tobias Burnus changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- Due to commit r228094 (2015-09-24), which started checking using CL_WARNING.
[Bug libstdc++/56383] error with multiple enable_shared_from_this base classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56383 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Wed Dec 2 15:08:18 2015 New Revision: 231181 URL: https://gcc.gnu.org/viewcvs?rev=231181&root=gcc&view=rev Log: Fix ambiguity with multiple enable_shared_from_this bases PR libstdc++/56383 * testsuite/20_util/enable_shared_from_this/56383.cc: New. * include/bits/shared_ptr_base.h (__enable_shared_from_this): Make friend declaration match previous declaration of __enable_shared_from_this_helper. * include/bits/shared_ptr.h (enable_shared_from_this): Likewise. Added: trunk/libstdc++-v3/testsuite/20_util/enable_shared_from_this/56383.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/shared_ptr.h trunk/libstdc++-v3/include/bits/shared_ptr_base.h
[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654 --- Comment #5 from Richard Biener --- Interesting the only effect could be different GC allocation pattern because the non-splice variant may end up re-allocating the target vector multiple times. But this alone should never change code generation. So - can you share a preprocessed file where code generation changes with this revision?
[Bug lto/68658] New: [6 Regression] LTO - bogus redefinition of warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68658
Bug ID: 68658
Summary: [6 Regression] LTO - bogus redefinition of warning
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
I have the following three-file program. Compiling it without LTO or with GCC 5
works, but with GCC 6 + LTO, I get:
g++ -O2 -flto one.cc two.cc
one.cc:3:5: error: redefinition of ‘int one::func()’
int one::func() { return 1;}
^~~
one.h:3:15: note: ‘virtual int one::func()’ previously defined here
virtual int func();
^~~~
one.cc: In function ‘int bar(one)’:
one.cc:5:5: error: redefinition of ‘int bar(one)’
int bar(class one y) {
^~~
one.h:6:5: note: ‘int bar(one)’ previously defined here
int bar(class one y);
^~~
==> one.h <==
class one {
public:
virtual int func();
};
int bar(class one y);
==> one.cc <==
#include "one.h"
int one::func() { return 1;}
int bar(class one y) {
return y.func();
}
==> two.cc <==
#include "one.h"
int main() {
class one x;
return bar(x);
}
[Bug lto/68658] [6 Regression] LTO - bogus redefinition of warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68658 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 cesar at gcc dot gnu.org changed: What|Removed |Added CC||cesar at gcc dot gnu.org --- Comment #10 from cesar at gcc dot gnu.org --- Thanks for reducing this Dominique. I'm not sure what caused the ICE yet, I don't think this test case is valid anymore. Basically, this test is trying to preform a reduction on a coarrray. Unlike openmp, openacc does not support array reductions. In fact, if you convert 'a' to a regular array, it would also cause an ICE. One of the solutions I was considering was to error if any array variables are used in as reduction variables. But I was thinking that would be too conservative. Consider 'reduction(+:var(1))'. Here var is an array, but the reduction is specifically operating on var element 1. The problem I came across here is that reductions on array elements in openmp are rejected as errors and I not sure why. I spent some time looking at it, but I kept on getting preempted by other tasks. This may be the case where the behavior of reductions in openmp diverges from openacc. With that in mind, I'm not sure why the ICE was exposed all of the sudden. My changes mostly updated the way that gang is parsed and how clauses in combined constructs are split. It looks like a sorry disappeared because the ICE occurs in omp-low.c.
[Bug c++/68653] [6 Regression] ICE: in nonnull_arg_p, at tree.c:13853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68653 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- We ICE on this assert: gcc_assert (TREE_CODE (arg) == PARM_DECL && POINTER_TYPE_P (TREE_TYPE (arg))); because the type of arg is OFFSET_TYPE. Which is--in tree.def--described as "a pointer relative to an object". So I guess we should allow OFFSET_TYPEs like this: --- gcc/tree.c +++ gcc/tree.c @@ -13850,7 +13850,9 @@ nonnull_arg_p (const_tree arg) tree t, attrs, fntype; unsigned HOST_WIDE_INT arg_num; - gcc_assert (TREE_CODE (arg) == PARM_DECL && POINTER_TYPE_P (TREE_TYPE (arg))); + gcc_assert (TREE_CODE (arg) == PARM_DECL + && (POINTER_TYPE_P (TREE_TYPE (arg)) + || TREE_CODE (TREE_TYPE (arg)) == OFFSET_TYPE)); /* The static chain decl is always non null. */ if (arg == cfun->static_chain_decl)
[Bug tree-optimization/68659] New: [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659 Bug ID: 68659 Summary: [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: amker at gcc dot gnu.org Target Milestone: --- Target: powerpc-*-* $ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c -O2 -fgraphite-identity -S -m32 -o id-pr45230-1.s ../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In function ‘main’: ../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: internal compiler error: Segmentation fault main () ^~~~ 0x106e622b crash_signal ../../gcc/toplev.c:334 0x107ec79c copy_prop_visit_phi_node ../../gcc/tree-ssa-copy.c:349 0x10868f2b simulate_stmt ../../gcc/tree-ssa-propagate.c:327 0x1086a327 simulate_block ../../gcc/tree-ssa-propagate.c:483 0x1086a327 ssa_propagate(ssa_prop_result (*)(gimple*, edge_def**, tree_node**), ssa_prop_result (*)(gphi*)) ../../gcc/tree-ssa-propagate.c:926 0x107ebbd3 execute_copy_prop ../../gcc/tree-ssa-copy.c:605 0x107ebbd3 execute ../../gcc/tree-ssa-copy.c:636 a94f1e5b00dee567897c91cdadb16dc46f3911e0 is the first bad commit git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231097 138bc75d-0d04-0410-961f-82ee72b054a4
