[Bug libgomp/64972] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 --- Comment #2 from Rainer Emrich --- Issue exists for target x86_64-w64-mingw32 too. By the way, this is a regression. At the moment gcc doesn't build for the *-w64-mingw32 targets.
[Bug rtl-optimization/60851] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2117 with -flive-range-shrinkage -mdispatch-scheduler -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851 --- Comment #15 from uros at gcc dot gnu.org --- Author: uros Date: Tue Mar 24 07:12:03 2015 New Revision: 221617 URL: https://gcc.gnu.org/viewcvs?rev=221617&root=gcc&view=rev Log: PR rtl-optimization/60851 * recog.c (constrain_operands): Accept a pseudo register before reload for LRA enabled targets. testsuite/ChangeLog: PR rtl-optimization/60851 * gcc.target/i386/pr60851.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr60851.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/recog.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
C testcase:
struct A { int a[2]; };
struct B { double b[2]; };
struct C { double c[4][1]; };
static void inline
bar (struct B *x, double y, double z)
{
x->b[0] = y;
x->b[1] = z;
}
void baz (struct B *);
void
foo (struct C *x, struct A *y)
{
struct B d;
bar (&d, x->c[1][0] * y->a[0] + x->c[0][1] * y->a[1] + x->c[0][0] *
x->c[0][1],
x->c[0][0] * y->a[0] + x->c[0][1] * y->a[1] + x->c[0][1] * y->a[0] +
x->c[0][0]);
baz (&d);
}
[Bug middle-end/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533 --- Comment #3 from Jakub Jelinek --- Working on a patch...
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 Kai Tietz changed: What|Removed |Added Known to work||4.9.3 Known to fail||5.0 --- Comment #3 from Kai Tietz --- Issue is that libgomp uses gnu-style printf formatters without checking, if formatter is available on that platform. Due it operates on size_t, the defines provided by inttypes.h are of not much help.
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 Kai Tietz changed: What|Removed |Added Target Milestone|--- |5.0
[Bug rtl-optimization/60851] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2117 with -flive-range-shrinkage -mdispatch-scheduler -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #16 from Uroš Bizjak --- Fixed everywhere.
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 --- Comment #4 from Jakub Jelinek --- And the suggested fix is just to cast to unsigned long and use %ld or %lx instead of %zd and %zx. I can't test it on these targets, so it is better if somebody with M$ access writes and tests the patch.
[Bug ipa/65516] lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65516 --- Comment #10 from David Kredba --- Thank you, it works.
[Bug tree-optimization/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Component|middle-end |tree-optimization
[Bug tree-optimization/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 35120 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35120&action=edit gcc5-pr65533.patch Untested fix.
[Bug target/65167] ICE: in assign_by_spills, at lra-assigns.c:1383 (unable to find a register to spill) with -O -fschedule-insns -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65167 ienkovich at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ienkovich at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from ienkovich at gcc dot gnu.org --- Fixed
[Bug target/65527] ICE: in expand_builtin_with_bounds, at builtins.c:7120 with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65527 ienkovich at gcc dot gnu.org changed: What|Removed |Added CC||ienkovich at gcc dot gnu.org --- Comment #1 from ienkovich at gcc dot gnu.org --- Patch posted: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00991.html
[Bug target/65531] ICE: symtab_node::verify failed: Two symbols with same comdat_group are not linked by the same_comdat_group list. with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65531 ienkovich at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-03-24 CC||ienkovich at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ienkovich at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
--- Comment #5 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 35120 [details]
> gcc5-pr65533.patch
>
> Untested fix.
Hmm, looks basically ok, though doing
vect_free_slp_tree (child);
from the cleanup before
/* If the SLP build for operand zero failed and operand zero
and one can be commutated try that for the scalar stmts
that failed the match. */
if (i == 0
...
and simply re-allocating child with
child = vect_create_new_slp_node (oprnd_info->def_stmts);
if (!child)
{
vect_free_oprnd_info (oprnds_info);
return false;
}
might be "simpler".
Your patch is ok if it is already tested.
[Bug tree-optimization/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533 --- Comment #6 from Richard Biener --- Looks like a latent issue on the branch(es) btw.
[Bug lto/65536] [5 regression] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 Manuel López-Ibáñez changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- Even a large, but self-contained testcase would be helpful. Probably one can figure out where the problem is by detecting that an overflow is about to happen. I don't understand how linemaps are supposed to work in LTO mode. Are they exactly the same as without LTO and saved to the object file? Are they recomputed? For all input files into the same line_table or one line_table for each file separately? Linemaps are designed to encode one single main file plus files included by this main file. To encode multiple files, you will need multiple linemaps, re-encoding everything into a single linemap seems fragile. CCing Dodji, he may have a better idea where linemap may be failing.
[Bug tree-optimization/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
--- Comment #7 from Jakub Jelinek ---
(In reply to Richard Biener from comment #5)
> Hmm, looks basically ok, though doing
>
> vect_free_slp_tree (child);
>
> from the cleanup before
>
> /* If the SLP build for operand zero failed and operand zero
> and one can be commutated try that for the scalar stmts
> that failed the match. */
> if (i == 0
> ...
>
> and simply re-allocating child with
>
> child = vect_create_new_slp_node (oprnd_info->def_stmts);
> if (!child)
> {
> vect_free_oprnd_info (oprnds_info);
> return false;
> }
>
> might be "simpler".
Well, it would be more costly (having to deallocate and allocate everything
again), and not really much shorter in the source. Only if we in the future
popluate early not just the SLP_TREE_CHILDREN vector, but various further
things your version might be better from maintanance POV.
> Your patch is ok if it is already tested.
Not yet tested, but bootstraps/regtests already in progress. If you feel
strongly about this, I can surely kill those, write a new patch and redo that.
[Bug testsuite/62234] warnings/errors from LTO cannot be tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62234 Manuel López-Ibáñez changed: What|Removed |Added Blocks||61913 --- Comment #2 from Manuel López-Ibáñez --- Keep track of all the bugs that do not have tests because of this one.
[Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537
Bug ID: 65537
Summary: [5 Regression]: --with-build-config=bootstrap-lto
fails on CentOS 5.11
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
When configured with --with-build-config=bootstrap-lto, the bootstrap fails on
CentOS 5.11 in libiberty with:
/home/uros/gcc-build/./prev-gcc/gcc-ar -B/home/uros/gcc-build/./prev-gcc/ rc
./libiberty.a \
./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o
./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./d-demangle.o
./dwarfnames.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o
./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o
./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o
./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o
./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o
./vprintf-support.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o
./simple-object-elf.o ./simple-object-mach-o.o ./simple-object-xcoff.o ./sort.o
./spaces.o ./splay-tree.o ./stack-limit.o ./strerror.o ./strsignal.o
./timeval-utils.o ./unlink-if-ordinary.o ./xasprintf.o ./xatexit.o ./xexit.o
./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./xvasprintf.o
./mkstemps.o ./setproctitle.o
/usr/bin/ar: illegal option -- -
Usage: /usr/bin/ar [emulation options] [-]{dmpqrstx}[abcfilNoPsSuvV]
[member-name] [count] archive-file file...
/usr/bin/ar -M [ - read options from
emulation options:
No emulation specific options
/usr/bin/ar: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux
efi-app-ia32 elf64-little elf64-big elf32-little elf32-big srec symbolsrec
tekhex binary ihex
gmake[3]: *** [libiberty.a] Error 1
gmake[3]: Leaving directory `/home/uros/gcc-build/libiberty'
gmake[2]: *** [all-stage2-libiberty] Error 2
gmake[2]: Leaving directory `/home/uros/gcc-build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/home/uros/gcc-build'
gmake: *** [all] Error 2
The problem is with gcc-ar that unconditionally passes --plugin option to ar.
This fails on older binutils, such as:
$ ar --version
GNU ar 2.17.50.0.6-26.el5 20061020
Copyright 2005 Free Software Foundation, Inc.
LTO bootstrap worked a while ago, so this is a regression on 5.0 branch.
[Bug tree-optimization/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
--- Comment #8 from rguenther at suse dot de ---
On Tue, 24 Mar 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
>
> --- Comment #7 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #5)
> > Hmm, looks basically ok, though doing
> >
> > vect_free_slp_tree (child);
> >
> > from the cleanup before
> >
> > /* If the SLP build for operand zero failed and operand zero
> > and one can be commutated try that for the scalar stmts
> > that failed the match. */
> > if (i == 0
> > ...
> >
> > and simply re-allocating child with
> >
> > child = vect_create_new_slp_node (oprnd_info->def_stmts);
> > if (!child)
> > {
> > vect_free_oprnd_info (oprnds_info);
> > return false;
> > }
> >
> > might be "simpler".
>
> Well, it would be more costly (having to deallocate and allocate everything
> again), and not really much shorter in the source. Only if we in the future
> popluate early not just the SLP_TREE_CHILDREN vector, but various further
> things your version might be better from maintanance POV.
>
> > Your patch is ok if it is already tested.
>
> Not yet tested, but bootstraps/regtests already in progress. If you feel
> strongly about this, I can surely kill those, write a new patch and redo that.
No, I don't feel strongly about it - for clarity the function should
get some refactoring but not at this stage.
[Bug tree-optimization/65538] New: [5 Regression] Memory leak of ipa_node_params_sum elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65538 Bug ID: 65538 Summary: [5 Regression] Memory leak of ipa_node_params_sum elements Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Seen recently in valgrind output (e.g. on the pr65533.c testcase): ==19246== 216 (48 direct, 168 indirect) bytes in 1 blocks are definitely lost in loss record 501 of 594 ==19246==at 0x4A070D7: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19246==by 0xAEBAAE: function_summary::allocate_new() (symbol-summary.h:106) ==19246==by 0xAEAF20: function_summary::get(int) (symbol-summary.h:232) ==19246==by 0xAE9B97: function_summary::get(cgraph_node*) (symbol-summary.h:112) ==19246==by 0xAF9C38: ipa_analyze_node(cgraph_node*) (ipa-prop.c:2386) ==19246==by 0x15B5578: ipcp_generate_summary() (ipa-cp.c:4449) ==19246==by 0xC255AF: execute_ipa_summary_passes(ipa_opt_pass_d*) (passes.c:2154) ==19246==by 0x841202: ipa_passes() (cgraphunit.c:2179) ==19246==by 0x8415E5: symbol_table::compile() (cgraphunit.c:2295) ==19246==by 0x841907: symbol_table::finalize_compilation_unit() (cgraphunit.c:2444) ==19246==by 0x69CEB8: c_write_global_declarations() (c-decl.c:10801) ==19246==by 0xD1EBAC: compile_file() (toplev.c:608) ==19246== ==19246== 384 (192 direct, 192 indirect) bytes in 4 blocks are definitely lost in loss record 519 of 594 ==19246==at 0x4A070D7: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==19246==by 0xAEBAAE: function_summary::allocate_new() (symbol-summary.h:106) ==19246==by 0xAEAF20: function_summary::get(int) (symbol-summary.h:232) ==19246==by 0xAE9B97: function_summary::get(cgraph_node*) (symbol-summary.h:112) ==19246==by 0xAF42FC: ipa_initialize_node_params(cgraph_node*) (ipa-prop.c:293) ==19246==by 0xAE323D: estimate_function_body_sizes(cgraph_node*, bool) (ipa-inline-analysis.c:2518) ==19246==by 0xAE4F54: compute_inline_parameters(cgraph_node*, bool) (ipa-inline-analysis.c:2951) ==19246==by 0xAE5051: compute_inline_parameters_for_current() (ipa-inline-analysis.c:2978) ==19246==by 0xAE50D8: (anonymous namespace)::pass_inline_parameters::execute(function*) (ipa-inline-analysis.c:3008) ==19246==by 0xC25B24: execute_one_pass(opt_pass*) (passes.c:2328) ==19246==by 0xC25D5E: execute_pass_list_1(opt_pass*) (passes.c:2380) ==19246==by 0xC25DCC: execute_pass_list(function*, opt_pass*) (passes.c:2391) inline summaries are ggc allocated and so not a problem, but the ipa-prop summaries are not, and thus something should arrange that the ipa_node_params class objects allocated by allocate_new are destructed when m_map is destructed. So, perhaps summary_hashmap_traits needs to implement the remove template method? Though, it is unclear how it could find out if the hash_map is ggc or not. Perhaps the decision ggc vs. non-ggc should be done as function_summary template parameter or similar.
[Bug tree-optimization/65538] [5 Regression] Memory leak of ipa_node_params_sum elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65538 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |5.0
[Bug bootstrap/65537] [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- GCC bootstrap now uses slim LTO object files. LTO bootstrap with slim LTO never worked with ar that doesn't support liblto_plugin. Update your binutils? Or maybe the minimal binutils version for LTO bootstrap should be mentioned on changes.html?
[Bug tree-optimization/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519 --- Comment #8 from Richard Biener --- Created attachment 35121 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35121&action=edit patch gimple-fold works like fold - it tries to re-simplify what you feed it, but only the outermost level (so it doesn't really recurse). Still I think this bug needs changing code-generation like with the attached patch which I am testing right now. I always forget how to force SJLJ EH on x86_64-linux for ada so I didn't manage to reproduce the issue or check if the patch fixes it ...
[Bug ada/65524] gnatbind generates decrementing the unexisting elab-counter into finalize_library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65524 Arnaud Charlet changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Arnaud Charlet --- Using a custom runtime change isn't supported by GCC FSF. I suspect the fix if any would be to geenrate the _elabs routine rather than trying to patch the binder, but as you are using a customized runtime, there might be other issues at play and the simplest is for you to remove the use of a 'is null' subprogram.
[Bug bootstrap/65537] [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 --- Comment #2 from Uroš Bizjak --- (In reply to Markus Trippelsdorf from comment #1) > Update your binutils? Not an option on a production system ... > Or maybe the minimal binutils version for LTO bootstrap should be mentioned > on changes.html? I can live with this, but considering that auto-host.h correctly determines #define HAVE_LTO_PLUGIN 0 perhaps an easy fallback to use fat LTO objects ca be implemented in this case.
[Bug middle-end/65517] [5 Regression] ICE: in get_loop_body, at cfgloop.c:856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65517 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Mar 24 09:31:48 2015 New Revision: 221619 URL: https://gcc.gnu.org/viewcvs?rev=221619&root=gcc&view=rev Log: 2015-03-24 Richard Biener PR middle-end/65517 * tree-cfg.c (remove_edge_and_dominated_blocks): Mark loops for fixup if necessary. * gcc.dg/torture/pr65517.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr65517.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug middle-end/65517] [5 Regression] ICE: in get_loop_body, at cfgloop.c:856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65517 Markus Trippelsdorf changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Markus Trippelsdorf --- Fixed. BTW the testcase has DOS line-endings.
[Bug middle-end/65517] [5 Regression] ICE: in get_loop_body, at cfgloop.c:856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65517 --- Comment #6 from Richard Biener --- (In reply to Markus Trippelsdorf from comment #5) > Fixed. > BTW the testcase has DOS line-endings. Yes, cut&pasting from firefox adds those for some very stupid reason (and I can't figure out how to "fix" that).
[Bug fortran/64952] Missing temporary in assignment from elemental function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64952 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #8 from ktkachov at gcc dot gnu.org --- (In reply to Mikael Morin from comment #5) > Author: mikael > Date: Mon Mar 23 07:53:31 2015 > New Revision: 221586 > > URL: https://gcc.gnu.org/viewcvs?rev=221586&root=gcc&view=rev > Log: > 2015-03-23 Paul Thomas > Mikael Morin > > PR fortran/64952 > fortran/ > * gfortran.h (struct symbol_attribute) : New field > 'array_outer_dependency'. > * trans.h (struct gfc_ss_info): New field 'array_outer_dependency'. > * module.c (enum ab_attribute): New value AB_ARRAY_OUTER_DEPENDENCY. > (attr_bits): Append same value to initializer. > (mio_symbol_attribute): Handle 'array_outer_dependency' attr > in module read and write. > * resolve.c (update_current_proc_outer_array_dependency): New function. > (resolve_function, resolve_call): Add code to update current procedure's > 'array_outer_dependency' attribute. > (resolve_variable): Mark current procedure with attribute > array_outer_dependency if the variable is an array coming from outside > the current namespace. > (resolve_fl_procedure): Mark a procedure without body with attribute > 'array_outer_dependency'. > * trans-array.c (gfc_conv_resolve_dependencies): If any ss is > marked as 'array_outer_dependency' generate a temporary. > (gfc_walk_function_expr): If the function may reference external arrays, > mark the head gfc_ss with flag 'array_outer_dependency'. > testsuite/ > * gfortran.dg/elemental_dependency_4.f90: New. > * gfortran.dg/elemental_dependency_5.f90: New. > > > Added: > trunk/gcc/testsuite/gfortran.dg/elemental_dependency_4.f90 > trunk/gcc/testsuite/gfortran.dg/elemental_dependency_5.f90 > Modified: > trunk/gcc/fortran/ChangeLog > trunk/gcc/fortran/gfortran.h > trunk/gcc/fortran/module.c > trunk/gcc/fortran/resolve.c > trunk/gcc/fortran/trans-array.c > trunk/gcc/fortran/trans.h > trunk/gcc/testsuite/ChangeLog With this commit I can no longer build 481.wrf for aarch64. I get: module_ra_rrtm.fppized.f90:4438:33: DIMENSION H2OREF(59),CO2REF(59), ETAREF(10) 1 Error: Different shape for array assignment at (1) on dimension 1 (59 and 7) Anything that can be done?
[Bug tree-optimization/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519 Eric Botcazou changed: What|Removed |Added Attachment #35101|0 |1 is obsolete|| --- Comment #10 from Eric Botcazou --- Created attachment 35122 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35122&action=edit Reduced testcase
[Bug tree-optimization/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519 --- Comment #9 from Eric Botcazou --- > gimple-fold works like fold - it tries to re-simplify what you feed it, but > only the outermost level (so it doesn't really recurse). Still I think this > bug needs changing code-generation like with the attached patch which I am > testing right now. I see, thanks. > I always forget how to force SJLJ EH on x86_64-linux for ada so I didn't > manage to reproduce the issue or check if the patch fixes it ... In a build tree: eric@polaris:~/build/gcc/native> cp gcc/ada/rts/system.ads . Edit system.ads and change ZCX_By_Default to False. Then compile the reduced testcase: eric@polaris:~/build/gcc/native> gcc/xgcc -Bgcc -S p.ads -O2 Unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE. I.3_2(ab) and I.3_87(ab) +===GNAT BUG DETECTED==+ | 5.0.0 20150316 (experimental) [trunk revision 221457] (x86_64-suse-linux) GCC error:| | SSA corruption | | Error detected around p.ads:6:9
[Bug tree-optimization/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519 --- Comment #11 from Eric Botcazou --- > I always forget how to force SJLJ EH on x86_64-linux for ada so I didn't > manage to reproduce the issue or check if the patch fixes it ... Yes, it does.
[Bug tree-optimization/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #12 from Richard Biener ---
(In reply to Eric Botcazou from comment #11)
> > I always forget how to force SJLJ EH on x86_64-linux for ada so I didn't
> > manage to reproduce the issue or check if the patch fixes it ...
>
> Yes, it does.
Verified. I'll add
Index: gcc/testsuite/gnat.dg/opt48.adb
===
--- gcc/testsuite/gnat.dg/opt48.adb (revision 0)
+++ gcc/testsuite/gnat.dg/opt48.adb (working copy)
@@ -0,0 +1,11 @@
+-- { dg-do compile }
+-- { dg-options "-O2" }
+
+with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
+with Interfaces;use Interfaces;
+
+package Opt48 is
+
+ type Arr is array (Unsigned_32 range <>) of Unbounded_String;
+
+end P;
given that passes in my bootstrap/test run.
[Bug target/65052] ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052 --- Comment #4 from Nick Clifton --- Created attachment 35123 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35123&action=edit Disable the generation of real_jump insns This patch works around the problem by disabling the generation of the real_jump insns. I am not enough of a C6X expert to determine why these instruction patterns are not working, but they are definitely part of the problem.
[Bug tree-optimization/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #13 from Eric Botcazou ---
> I'll add
>
> Index: gcc/testsuite/gnat.dg/opt48.adb
> ===
> --- gcc/testsuite/gnat.dg/opt48.adb (revision 0)
> +++ gcc/testsuite/gnat.dg/opt48.adb (working copy)
> @@ -0,0 +1,11 @@
> +-- { dg-do compile }
> +-- { dg-options "-O2" }
> +
> +with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
> +with Interfaces;use Interfaces;
> +
> +package Opt48 is
> +
> + type Arr is array (Unsigned_32 range <>) of Unbounded_String;
> +
> +end P;
>
> given that passes in my bootstrap/test run.
Careful, it's a package spec only so it needs to have .ads extension and placed
in gnat.dg/specs.
[Bug lto/65536] [5 regression] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #2 from Richard Biener ---
The main issue with LTO is that it re-creates a combined linemap but in (most
of the time) quite awkward ordering (simply registering random-ordered
file:line:column entries by switching files/lines "appropriately").
I've argued that it would be better to stream those file:line:columns
separately so we can "sort" them before handing them over to libcpp for
linemap re-creation.
So currently we do, for each "file:line:column" location we stream in:
if (file_change)
{
if (prev_file)
linemap_add (line_table, LC_LEAVE, false, NULL, 0);
linemap_add (line_table, LC_ENTER, false, current_file, current_line);
}
else if (line_change)
linemap_line_start (line_table, current_line, current_col);
return linemap_position_for_column (line_table, current_col);
which of course puts a heavy load on the linemap encoding...
But it should definitely work (not sure what it does on line or file
"overflow").
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 Richard Biener changed: What|Removed |Added Summary|[5 regression] LTO line |LTO line number information |number information garbled |garbled --- Comment #3 from Richard Biener --- Btw, this can't be a regression in GCC 5 only (or even a regression at all?). Maybe with macro expansion locations and better column tracking we now more likely overflow tables, but well...
[Bug fortran/64952] Missing temporary in assignment from elemental function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64952 --- Comment #9 from Dominique d'Humieres --- Duplicate of pr65532?
[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-24 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- Btw, I can't see how this regressed in GCC 5 apart from maybe using some more stack space per recursion of DFS_write_tree. Even GCC 4.8 which didn't have the DFS walk recursed on these during tree writing. But yes, that DFS walk can use stack. GCC can use quite some stack during garbage collection as well. Anyway, the real fix is to re-write the DFS walk to not use recursion but a worklist.
[Bug c++/65512] Inconsistent report of uninitialized members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #6 from Paolo Carlini --- This is fixed in 5.0 indeed.
[Bug c++/65525] ICE: sorry, unimplemented: unexpected AST of kind mem_ref (-std=c++14, ICE: in potential_constant_expression_1, at cp/constexpr.c:4432)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-24 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Btw, I wonder why we sorry here instead of simply treating it as non-constant...
[Bug c++/65525] ICE: sorry, unimplemented: unexpected AST of kind mem_ref (-std=c++14, ICE: in potential_constant_expression_1, at cp/constexpr.c:4432)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525 --- Comment #2 from Richard Biener --- Run till exit from #0 0x012bf93a in build2_stat (code=MEM_REF, tt=, arg0=, arg1=) at /space/rguenther/src/svn/trunk/gcc/tree.c:4385 0x006f8b40 in build_over_call (cand=0x24f7aa0, flags=1, complain=3) at /space/rguenther/src/svn/trunk/gcc/cp/call.c:7456 7456 t = build2 (MODIFY_EXPR, void_type_node, Value returned is $9 = (tree_node *) 0x76a37758 (gdb) l 7451 array_type = build_array_type (char_type_node, 7452 build_index_type 7453 (size_binop (MINUS_EXPR, 7454arg2, size_int (1; 7455 alias_set = build_int_cst (build_pointer_type (type), 0); 7456 t = build2 (MODIFY_EXPR, void_type_node, 7457 build2 (MEM_REF, array_type, arg0, alias_set), 7458 build2 (MEM_REF, array_type, arg, alias_set)); 7459 val = build2 (COMPOUND_EXPR, TREE_TYPE (to), t, to); so the C++ FE even builds this itself.
[Bug c++/65512] Inconsistent report of uninitialized members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512 --- Comment #7 from Peter VARGA --- Due the fact some frameworks do NOT support gcc 5.0 yet I would like to know if this bug is going to be fixed in a 4.9.X version or not.
[Bug rtl-optimization/34503] Issues with constant/copy propagation implementation in gcse.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34503 Steven Bosscher changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #8 from Steven Bosscher --- Patch for comment #4 is proposed by Thomas Preud'homme with minor changes: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01048.html https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01170.html
[Bug tree-optimization/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #14 from rguenther at suse dot de ---
On Tue, 24 Mar 2015, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
>
> --- Comment #13 from Eric Botcazou ---
> > I'll add
> >
> > Index: gcc/testsuite/gnat.dg/opt48.adb
> > ===
> > --- gcc/testsuite/gnat.dg/opt48.adb (revision 0)
> > +++ gcc/testsuite/gnat.dg/opt48.adb (working copy)
> > @@ -0,0 +1,11 @@
> > +-- { dg-do compile }
> > +-- { dg-options "-O2" }
> > +
> > +with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
> > +with Interfaces;use Interfaces;
> > +
> > +package Opt48 is
> > +
> > + type Arr is array (Unsigned_32 range <>) of Unbounded_String;
> > +
> > +end P;
> >
> > given that passes in my bootstrap/test run.
>
> Careful, it's a package spec only so it needs to have .ads extension and
> placed
> in gnat.dg/specs.
Ok, moved.
[Bug c++/65513] gcc stops with "internal compiler error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513 --- Comment #4 from Paolo Carlini --- I'm adding the reduced testcase and closing the bug.
[Bug c++/65525] ICE: sorry, unimplemented: unexpected AST of kind mem_ref (-std=c++14, ICE: in potential_constant_expression_1, at cp/constexpr.c:4432)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525 --- Comment #3 from Richard Biener --- Ah, and that was me: 2011-08-12 Richard Guenther * call.c (build_over_call): Instead of memcpy use an assignment of two MEM_REFs. which implements memcpy as *(char[n])ptr1 = *(char[n])ptr2; But we ask #4 0x0097fdb9 in potential_rvalue_constant_expression ( t=) at /space/rguenther/src/svn/trunk/gcc/cp/constexpr.c:4478 (gdb) p debug_generic_expr (expression) MEM[(struct A *)&y] = MEM[(struct A *)(const struct A &) (const struct A *) &a];, y so I wonder why we look at the side-effects at all? That is, why does COMPOUND_EXPR handling not return false on side-effects early?
[Bug c++/65513] gcc stops with "internal compiler error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Mar 24 10:24:33 2015 New Revision: 221620 URL: https://gcc.gnu.org/viewcvs?rev=221620&root=gcc&view=rev Log: 2015-03-24 Paolo Carlini PR c++/65513 * g++.dg/cpp0x/constexpr-array11.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array11.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/65513] gcc stops with "internal compiler error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #6 from Paolo Carlini --- Done.
[Bug tree-optimization/65538] [5 Regression] Memory leak of ipa_node_params_sum elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65538 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-24 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787 --- Comment #4 from vehre at gcc dot gnu.org --- Author: vehre Date: Tue Mar 24 10:28:48 2015 New Revision: 221621 URL: https://gcc.gnu.org/viewcvs?rev=221621&root=gcc&view=rev Log: gcc/fortran/ChangeLog 2015-03-24 Andre Vehreschild PR fortran/64787 PR fortran/57456 PR fortran/63230 * class.c (gfc_add_component_ref): Free no longer needed ref-chains to prevent memory loss. (find_intrinsic_vtab): For deferred length char arrays or unlimited polymorphic objects, store the size in bytes of one character in the size component of the vtab. * gfortran.h: Added gfc_add_len_component () define. * trans-array.c (gfc_trans_create_temp_array): Switched to new function name for getting a class' vtab's field. (build_class_array_ref): Likewise. (gfc_array_init_size): Using the size information from allocate more consequently now, i.e., the typespec of the entity to allocate is no longer needed. This is to address the last open comment in PR fortran/57456. (gfc_array_allocate): Likewise. (structure_alloc_comps): gfc_copy_class_to_class () needs to know whether the class is unlimited polymorphic. * trans-array.h: Changed interface of gfc_array_allocate () to reflect the no longer needed typespec. * trans-expr.c (gfc_find_and_cut_at_last_class_ref): New. (gfc_reset_len): New. (gfc_get_class_array_ref): Switch to new function name for getting a class' vtab's field. (gfc_copy_class_to_class): Added flag to know whether the class to copy is unlimited polymorphic. Adding _len dependent code then, which calls ->vptr->copy () with four arguments adding the length information ->vptr->copy(from, to, from_len, to_cap). (gfc_conv_procedure_call): Switch to new function name for getting a class' vtab's field. (alloc_scalar_allocatable_for_assignment): Use the string_length as computed by gfc_conv_expr and not the statically backend_decl which may be incorrect when ref-ing. (gfc_trans_assignment_1): Use the string_length variable and not the rse.string_length. The former has been computed more generally. * trans-intrinsic.c (gfc_conv_intrinsic_sizeof): Switch to new function name for getting a class' vtab's field. (gfc_conv_intrinsic_storage_size): Likewise. (gfc_conv_intrinsic_transfer): Likewise. * trans-stmt.c (gfc_trans_allocate): Restructured to evaluate source=expr3 only once before the loop over the objects to allocate, when the objects are not arrays. Doing correct _len initialization and calling of vptr->copy () fixing PR 64787. (gfc_trans_deallocate): Reseting _len to 0, preventing future errors. * trans.c (gfc_build_array_ref): Switch to new function name for getting a class' vtab's field. (gfc_add_comp_finalizer_call): Likewise. * trans.h: Define the prototypes for the gfc_class_vtab_*_get () and gfc_vptr_*_get () functions. Added gfc_find_and_cut_at_last_class_ref () and gfc_reset_len () routine prototype. Added flag to gfc_copy_class_to_class () prototype to signal an unlimited polymorphic entity to copy. gcc/testsuite/ChangeLog 2015-03-24 Andre Vehreschild * gfortran.dg/allocate_alloc_opt_13.f90: Added tests for source= and mold= expressions functionality. * gfortran.dg/allocate_class_4.f90: New test. * gfortran.dg/unlimited_polymorphic_20.f90: Added test whether copying an unlimited polymorhpic object containing a char array to another unlimited polymorphic object respects the _len component. * gfortran.dg/unlimited_polymorphic_22.f90: Extended to check whether deferred length char array allocate works, unlimited polymorphic object allocation from a string works and if allocating an array of deferred length strings works. * gfortran.dg/unlimited_polymorphic_24.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_class_4.f90 trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_24.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_13.f90 trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_20.f90 trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_22.f90
[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230 --- Comment #6 from vehre at gcc dot gnu.org --- Author: vehre Date: Tue Mar 24 10:28:48 2015 New Revision: 221621 URL: https://gcc.gnu.org/viewcvs?rev=221621&root=gcc&view=rev Log: gcc/fortran/ChangeLog 2015-03-24 Andre Vehreschild PR fortran/64787 PR fortran/57456 PR fortran/63230 * class.c (gfc_add_component_ref): Free no longer needed ref-chains to prevent memory loss. (find_intrinsic_vtab): For deferred length char arrays or unlimited polymorphic objects, store the size in bytes of one character in the size component of the vtab. * gfortran.h: Added gfc_add_len_component () define. * trans-array.c (gfc_trans_create_temp_array): Switched to new function name for getting a class' vtab's field. (build_class_array_ref): Likewise. (gfc_array_init_size): Using the size information from allocate more consequently now, i.e., the typespec of the entity to allocate is no longer needed. This is to address the last open comment in PR fortran/57456. (gfc_array_allocate): Likewise. (structure_alloc_comps): gfc_copy_class_to_class () needs to know whether the class is unlimited polymorphic. * trans-array.h: Changed interface of gfc_array_allocate () to reflect the no longer needed typespec. * trans-expr.c (gfc_find_and_cut_at_last_class_ref): New. (gfc_reset_len): New. (gfc_get_class_array_ref): Switch to new function name for getting a class' vtab's field. (gfc_copy_class_to_class): Added flag to know whether the class to copy is unlimited polymorphic. Adding _len dependent code then, which calls ->vptr->copy () with four arguments adding the length information ->vptr->copy(from, to, from_len, to_cap). (gfc_conv_procedure_call): Switch to new function name for getting a class' vtab's field. (alloc_scalar_allocatable_for_assignment): Use the string_length as computed by gfc_conv_expr and not the statically backend_decl which may be incorrect when ref-ing. (gfc_trans_assignment_1): Use the string_length variable and not the rse.string_length. The former has been computed more generally. * trans-intrinsic.c (gfc_conv_intrinsic_sizeof): Switch to new function name for getting a class' vtab's field. (gfc_conv_intrinsic_storage_size): Likewise. (gfc_conv_intrinsic_transfer): Likewise. * trans-stmt.c (gfc_trans_allocate): Restructured to evaluate source=expr3 only once before the loop over the objects to allocate, when the objects are not arrays. Doing correct _len initialization and calling of vptr->copy () fixing PR 64787. (gfc_trans_deallocate): Reseting _len to 0, preventing future errors. * trans.c (gfc_build_array_ref): Switch to new function name for getting a class' vtab's field. (gfc_add_comp_finalizer_call): Likewise. * trans.h: Define the prototypes for the gfc_class_vtab_*_get () and gfc_vptr_*_get () functions. Added gfc_find_and_cut_at_last_class_ref () and gfc_reset_len () routine prototype. Added flag to gfc_copy_class_to_class () prototype to signal an unlimited polymorphic entity to copy. gcc/testsuite/ChangeLog 2015-03-24 Andre Vehreschild * gfortran.dg/allocate_alloc_opt_13.f90: Added tests for source= and mold= expressions functionality. * gfortran.dg/allocate_class_4.f90: New test. * gfortran.dg/unlimited_polymorphic_20.f90: Added test whether copying an unlimited polymorhpic object containing a char array to another unlimited polymorphic object respects the _len component. * gfortran.dg/unlimited_polymorphic_22.f90: Extended to check whether deferred length char array allocate works, unlimited polymorphic object allocation from a string works and if allocating an array of deferred length strings works. * gfortran.dg/unlimited_polymorphic_24.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_class_4.f90 trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_24.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_13.f90 trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_20.f90 trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_22.f90
[Bug fortran/57456] [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456 --- Comment #6 from vehre at gcc dot gnu.org --- Author: vehre Date: Tue Mar 24 10:28:48 2015 New Revision: 221621 URL: https://gcc.gnu.org/viewcvs?rev=221621&root=gcc&view=rev Log: gcc/fortran/ChangeLog 2015-03-24 Andre Vehreschild PR fortran/64787 PR fortran/57456 PR fortran/63230 * class.c (gfc_add_component_ref): Free no longer needed ref-chains to prevent memory loss. (find_intrinsic_vtab): For deferred length char arrays or unlimited polymorphic objects, store the size in bytes of one character in the size component of the vtab. * gfortran.h: Added gfc_add_len_component () define. * trans-array.c (gfc_trans_create_temp_array): Switched to new function name for getting a class' vtab's field. (build_class_array_ref): Likewise. (gfc_array_init_size): Using the size information from allocate more consequently now, i.e., the typespec of the entity to allocate is no longer needed. This is to address the last open comment in PR fortran/57456. (gfc_array_allocate): Likewise. (structure_alloc_comps): gfc_copy_class_to_class () needs to know whether the class is unlimited polymorphic. * trans-array.h: Changed interface of gfc_array_allocate () to reflect the no longer needed typespec. * trans-expr.c (gfc_find_and_cut_at_last_class_ref): New. (gfc_reset_len): New. (gfc_get_class_array_ref): Switch to new function name for getting a class' vtab's field. (gfc_copy_class_to_class): Added flag to know whether the class to copy is unlimited polymorphic. Adding _len dependent code then, which calls ->vptr->copy () with four arguments adding the length information ->vptr->copy(from, to, from_len, to_cap). (gfc_conv_procedure_call): Switch to new function name for getting a class' vtab's field. (alloc_scalar_allocatable_for_assignment): Use the string_length as computed by gfc_conv_expr and not the statically backend_decl which may be incorrect when ref-ing. (gfc_trans_assignment_1): Use the string_length variable and not the rse.string_length. The former has been computed more generally. * trans-intrinsic.c (gfc_conv_intrinsic_sizeof): Switch to new function name for getting a class' vtab's field. (gfc_conv_intrinsic_storage_size): Likewise. (gfc_conv_intrinsic_transfer): Likewise. * trans-stmt.c (gfc_trans_allocate): Restructured to evaluate source=expr3 only once before the loop over the objects to allocate, when the objects are not arrays. Doing correct _len initialization and calling of vptr->copy () fixing PR 64787. (gfc_trans_deallocate): Reseting _len to 0, preventing future errors. * trans.c (gfc_build_array_ref): Switch to new function name for getting a class' vtab's field. (gfc_add_comp_finalizer_call): Likewise. * trans.h: Define the prototypes for the gfc_class_vtab_*_get () and gfc_vptr_*_get () functions. Added gfc_find_and_cut_at_last_class_ref () and gfc_reset_len () routine prototype. Added flag to gfc_copy_class_to_class () prototype to signal an unlimited polymorphic entity to copy. gcc/testsuite/ChangeLog 2015-03-24 Andre Vehreschild * gfortran.dg/allocate_alloc_opt_13.f90: Added tests for source= and mold= expressions functionality. * gfortran.dg/allocate_class_4.f90: New test. * gfortran.dg/unlimited_polymorphic_20.f90: Added test whether copying an unlimited polymorhpic object containing a char array to another unlimited polymorphic object respects the _len component. * gfortran.dg/unlimited_polymorphic_22.f90: Extended to check whether deferred length char array allocate works, unlimited polymorphic object allocation from a string works and if allocating an array of deferred length strings works. * gfortran.dg/unlimited_polymorphic_24.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_class_4.f90 trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_24.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_13.f90 trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_20.f90 trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_22.f90
[Bug bootstrap/65537] [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 --- Comment #3 from Richard Biener --- Well, simply add a config/bootstrap-lto-fat.mk?
[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 Richard Biener changed: What|Removed |Added Keywords||documentation Target Milestone|--- |5.0 Summary|[5 Regression]: |[5 Regression] |--with-build-config=bootstr |--with-build-config=bootstr |ap-lto fails on CentOS 5.11 |ap-lto fails on CentOS 5.11
[Bug rtl-optimization/48181] [4.8/4.9 Regression] wrong code with -O -fgcse --param ira-max-conflict-table-size=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48181 Steven Bosscher changed: What|Removed |Added Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] wrong |wrong code with -O -fgcse |code with -O -fgcse --param |--param |ira-max-conflict-table-size |ira-max-conflict-table-size |=0 |=0 | --- Comment #10 from Steven Bosscher --- Not a GCC5 regression. Disabling LRA isn't possible. Anyway, if disabling LRA would make this bug resurface then it's more likely a reload (or reload<->IRA interaction) issue than something in IRA.
[Bug c++/59978] C++11 Non-Type-Template-Parameter Pack Expansion not working according to standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59978 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-24 Ever confirmed|0 |1
[Bug tree-optimization/65538] [5 Regression] Memory leak of ipa_node_params_sum elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65538 --- Comment #2 from Martin Liška --- (In reply to Jakub Jelinek from comment #0) > Seen recently in valgrind output (e.g. on the pr65533.c testcase): > > ==19246== 216 (48 direct, 168 indirect) bytes in 1 blocks are definitely > lost in loss record 501 of 594 > ==19246==at 0x4A070D7: operator new(unsigned long) (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==19246==by 0xAEBAAE: function_summary::allocate_new() > (symbol-summary.h:106) > ==19246==by 0xAEAF20: function_summary::get(int) > (symbol-summary.h:232) > ==19246==by 0xAE9B97: > function_summary::get(cgraph_node*) (symbol-summary.h:112) > ==19246==by 0xAF9C38: ipa_analyze_node(cgraph_node*) (ipa-prop.c:2386) > ==19246==by 0x15B5578: ipcp_generate_summary() (ipa-cp.c:4449) > ==19246==by 0xC255AF: execute_ipa_summary_passes(ipa_opt_pass_d*) > (passes.c:2154) > ==19246==by 0x841202: ipa_passes() (cgraphunit.c:2179) > ==19246==by 0x8415E5: symbol_table::compile() (cgraphunit.c:2295) > ==19246==by 0x841907: symbol_table::finalize_compilation_unit() > (cgraphunit.c:2444) > ==19246==by 0x69CEB8: c_write_global_declarations() (c-decl.c:10801) > ==19246==by 0xD1EBAC: compile_file() (toplev.c:608) > ==19246== > ==19246== 384 (192 direct, 192 indirect) bytes in 4 blocks are definitely > lost in loss record 519 of 594 > ==19246==at 0x4A070D7: operator new(unsigned long) (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==19246==by 0xAEBAAE: function_summary::allocate_new() > (symbol-summary.h:106) > ==19246==by 0xAEAF20: function_summary::get(int) > (symbol-summary.h:232) > ==19246==by 0xAE9B97: > function_summary::get(cgraph_node*) (symbol-summary.h:112) > ==19246==by 0xAF42FC: ipa_initialize_node_params(cgraph_node*) > (ipa-prop.c:293) > ==19246==by 0xAE323D: estimate_function_body_sizes(cgraph_node*, bool) > (ipa-inline-analysis.c:2518) > ==19246==by 0xAE4F54: compute_inline_parameters(cgraph_node*, bool) > (ipa-inline-analysis.c:2951) > ==19246==by 0xAE5051: compute_inline_parameters_for_current() > (ipa-inline-analysis.c:2978) > ==19246==by 0xAE50D8: (anonymous > namespace)::pass_inline_parameters::execute(function*) > (ipa-inline-analysis.c:3008) > ==19246==by 0xC25B24: execute_one_pass(opt_pass*) (passes.c:2328) > ==19246==by 0xC25D5E: execute_pass_list_1(opt_pass*) (passes.c:2380) > ==19246==by 0xC25DCC: execute_pass_list(function*, opt_pass*) > (passes.c:2391) > > inline summaries are ggc allocated and so not a problem, but the ipa-prop > summaries are not, and thus something should arrange that the > ipa_node_params class objects allocated by allocate_new are destructed when > m_map is destructed. > So, perhaps summary_hashmap_traits needs to implement the remove template > method? Though, it is unclear how it could find out if the hash_map is ggc > or not. Perhaps the decision ggc vs. non-ggc should be done as > function_summary template parameter or similar. I think the correct way is to traverse all items in function_summary::release (in case of GGC-based map) and delete them all. Working on the patch. Martin
[Bug fortran/64952] Missing temporary in assignment from elemental function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64952 --- Comment #10 from Mikael Morin --- (In reply to Dominique d'Humieres from comment #9) > Duplicate of pr65532? Rather cause of pr65532. Only comment #8 is a duplicate. (In reply to Mikael Morin from comment #7) > (In reply to paul.richard.tho...@gmail.com from comment #6) > > Thanks for finishing the job. > I have yet to fix 4.9 as well, as you suggested. In a week or so. > The patch isn't as safe as I thought, so I think I won't backport it after all.
[Bug c++/59988] Failing to specialize template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59988 --- Comment #5 from Paolo Carlini --- I'm adding a testcase and closing the bug. By the way, both current EDG and clang agree with GCC.
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #5 from Rainer Emrich ---
(In reply to Jakub Jelinek from comment #4)
> And the suggested fix is just to cast to unsigned long and use %ld or %lx
> instead of %zd and %zx. I can't test it on these targets, so it is better
> if somebody with M$ access writes and tests the patch.
Index: target.c
===
--- target.c(Revision 221607)
+++ target.c(Arbeitskopie)
@@ -439,8 +439,8 @@ gomp_map_vars (struct gomp_device_descr
was missing. */
size_t size = k->host_end - k->host_start;
gomp_fatal ("present clause: !acc_is_present (%p, "
- "%zd (0x%zx))", (void *) k->host_start,
- size, size);
+ "%ld (0x%lx))", (void *) k->host_start,
+ (unsigned long) size, (unsigned long) size);
}
break;
case GOMP_MAP_FORCE_DEVICEPTR:
Something like this? At least that builds on x86_64-w64-mingw32.
But there is another issue with formatters in oacc-parallel.c.
Shall I append to this bug or open a new one?
[Bug tree-optimization/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Tue Mar 24 10:45:09 2015 New Revision: 221622 URL: https://gcc.gnu.org/viewcvs?rev=221622&root=gcc&view=rev Log: PR tree-optimization/65533 * tree-vect-slp.c (vect_build_slp_tree): Before re-trying with swapped operands, call vect_free_slp_tree on SLP_TREE_CHILDREN of child and truncate the SLP_TREE_CHILDREN vector. * gcc.dg/pr65533.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr65533.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug c++/59988] Failing to specialize template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59988 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Mar 24 10:50:36 2015 New Revision: 221623 URL: https://gcc.gnu.org/viewcvs?rev=221623&root=gcc&view=rev Log: 2015-03-24 Paolo Carlini PR c++/59988 * g++.dg/cpp0x/vt-59988.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-59988.C
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #6 from Jakub Jelinek ---
(In reply to Rainer Emrich from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > And the suggested fix is just to cast to unsigned long and use %ld or %lx
> > instead of %zd and %zx. I can't test it on these targets, so it is better
> > if somebody with M$ access writes and tests the patch.
>
> Index: target.c
> ===
> --- target.c(Revision 221607)
> +++ target.c(Arbeitskopie)
> @@ -439,8 +439,8 @@ gomp_map_vars (struct gomp_device_descr
> was missing. */
> size_t size = k->host_end - k->host_start;
> gomp_fatal ("present clause: !acc_is_present (%p, "
> - "%zd (0x%zx))", (void *) k->host_start,
> - size, size);
> + "%ld (0x%lx))", (void *) k->host_start,
> + (unsigned long) size, (unsigned long)
> size);
> }
> break;
> case GOMP_MAP_FORCE_DEVICEPTR:
>
> Something like this? At least that builds on x86_64-w64-mingw32.
Yeah.
> But there is another issue with formatters in oacc-parallel.c.
> Shall I append to this bug or open a new one?
Please don't create a new bug, it is the same thing.
[Bug c++/59988] Failing to specialize template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59988 --- Comment #8 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Mar 24 10:51:38 2015 New Revision: 221624 URL: https://gcc.gnu.org/viewcvs?rev=221624&root=gcc&view=rev Log: 2015-03-24 Paolo Carlini PR c++/59988 * g++.dg/cpp0x/vt-59988.C: New. Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/59988] Failing to specialize template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59988 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Paolo Carlini --- Done.
[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 --- Comment #4 from Markus Trippelsdorf --- Or something like: diff --git a/config/bootstrap-lto.mk b/config/bootstrap-lto.mk index 9e065e1d85a0..5e93ee848727 100644 --- a/config/bootstrap-lto.mk +++ b/config/bootstrap-lto.mk @@ -1,5 +1,10 @@ # This option enables LTO for stage2 and stage3 in slim mode +#if HAVE_LTO_PLUGIN == 0 +STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects +STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects +STAGEprofile_CFLAGS += -fno-lto +#else STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 STAGEprofile_CFLAGS += -fno-lto @@ -11,3 +16,4 @@ LTO_RANLIB = $$r/$(HOST_SUBDIR)/prev-gcc/gcc-ranlib$(exeext) -B$$r/$(HOST_SUBDIR LTO_EXPORTS = AR="$(LTO_AR)"; export AR; \ RANLIB="$(LTO_RANLIB)"; export RANLIB; LTO_FLAGS_TO_PASS = AR="$(LTO_AR)" RANLIB="$(LTO_RANLIB)" +#endif
[Bug fortran/65532] [5 Regression] Unexpected error with legacy code (D1MACH)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65532 --- Comment #4 from Mikael Morin --- With r221586, procedure d1mach is resolved more than once. At the first time resolve_values is called, the problematic variables (diver, large, etc) have a NULL sym->value, which is set afterwards in resolve_data. On the second call, the value is non-null and the error is produced.
[Bug c++/60067] bogus error default template arguments may not be used in function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60067 --- Comment #1 from Paolo Carlini --- This is fixed in 4.9.1, I'm adding the testcase and closing the bug.
[Bug tree-optimization/65533] [5 Regression] 252.eon in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #7 from Rainer Emrich ---
Ok, here's the additional issue in oacc-parallel.c.
libtool: compile:
/opt/devel/SCRATCH/tmp.UotBZukqBt/gcc-5.0.0/gcc-5.0.0/./gcc/xgcc
-B/opt/devel/SCRATCH/tmp.UotBZukqBt/gcc-5.0.0/gcc-5.0.0/./gcc/
-L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/lib
-L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/mingw/lib
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/include
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/mingw/include
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/bin/
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/lib/
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/include
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.0.0/x86_64-w64-mingw32/sys-include
-DHAVE_CONFIG_H -I.
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/config/mingw32
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/config/posix
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp
-I../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/../include
-Wall -pthread -Werror -g -O2 -MT oacc-parallel.lo -MD -MP -MF
.deps/oacc-parallel.Tpo -c
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c
-DDLL_EXPORT -DPIC -o .libs/oacc-parallel.o
In file included from
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:30:0:
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:
In function 'GOACC_parallel':
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:102:18:
error: unknown conversion type character 'z' in format [-Werror=format=]
gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
(gomp_debug) ((KIND), __VA_ARGS__); \
^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:102:18:
error: format '%p' expects argument of type 'void *', but argument 4 has type
'size_t {aka long long unsigned int}' [-Werror=format=]
gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
(gomp_debug) ((KIND), __VA_ARGS__); \
^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:102:18:
error: format '%d' expects argument of type 'int', but argument 7 has type
'short unsigned int *' [-Werror=format=]
gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
(gomp_debug) ((KIND), __VA_ARGS__); \
^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:102:18:
error: too many arguments for format [-Werror=format-extra-args]
gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
(gomp_debug) ((KIND), __VA_ARGS__); \
^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:
In function 'GOACC_data_start':
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:181:18:
error: unknown conversion type character 'z' in format [-Werror=format=]
gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgomp.h:554:29: note: in
definition of macro 'gomp_debug'
(gomp_debug) ((KIND), __VA_ARGS__); \
^
../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/libgomp/oacc-parallel.c:181:18:
error: format '%p' expects argument of type 'void *', but argument 4 has type
'size_t {aka long long unsigned int}' [-Werror=format=]
gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
^
d:\opt\devel\gnu\src\gcc-mingw-w64\gcc-5.0.0\libgomp\libgo
[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- HAVE_LTO_PLUGIN is a gcc/configure macro, while you'd need that in a toplevel file...; or the check would need to be copied or moved to the toplevel configure, and somehow propagated to the bootstrap*.mk files.
[Bug target/65531] ICE: symtab_node::verify failed: Two symbols with same comdat_group are not linked by the same_comdat_group list. with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65531
ienkovich at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1 from ienkovich at gcc dot gnu.org ---
same_comdat_group verification loop looks weird.
for (s = (*entry)->same_comdat_group; s != NULL && s != node; s =
s->same_comdat_group)
if (!s || s == *entry)
The '!s' condition has no chance to work due to 's != NULL' condition. Thus
verifier doesn't catch cases when there are two nodes with the same comdat
group not actually linked with same_comdat_group. Is it expected behavior?
With a verifier patch applied I have this test failed with no
'-fcheck-pointer-bounds -mmpx':
diff --git a/gcc/symtab.c b/gcc/symtab.c
index 88e168b..395cfe4 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -1131,7 +1131,7 @@ symtab_node::verify_symtab_nodes (void)
if (!existed)
*entry = node;
else
- for (s = (*entry)->same_comdat_group; s != NULL && s != node; s =
s->same_comdat_group)
+ for (s = (*entry)->same_comdat_group; s != node; s =
s->same_comdat_group)
if (!s || s == *entry)
{
error ("Two symbols with same comdat_group are not linked by
the same_comdat_group list.");
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #8 from Rainer Emrich ---
I'm testing the following on x86_64-w64-mingw32 at the moment.
Index: oacc-parallel.c
===
--- oacc-parallel.c (Revision 221607)
+++ oacc-parallel.c (Arbeitskopie)
@@ -99,8 +99,9 @@ GOACC_parallel (int device, void (*fn) (
gomp_fatal ("num_workers (%d) different from one is not yet supported",
num_workers);
- gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
- __FUNCTION__, mapnum, hostaddrs, sizes, kinds, async);
+ gomp_debug (0, "%s: mapnum=%ld, hostaddrs=%p, sizes=%p, kinds=%p,
async=%d\n",
+ __FUNCTION__, (unsigned long) mapnum, (void *) hostaddrs,
+ sizes, kinds, (int) async);
select_acc_device (device);
@@ -178,8 +179,9 @@ GOACC_data_start (int device, size_t map
bool host_fallback = device == GOMP_DEVICE_HOST_FALLBACK;
struct target_mem_desc *tgt;
- gomp_debug (0, "%s: mapnum=%zd, hostaddrs=%p, sizes=%p, kinds=%p\n",
- __FUNCTION__, mapnum, hostaddrs, sizes, kinds);
+ gomp_debug (0, "%s: mapnum=%ld, hostaddrs=%p, sizes=%p, kinds=%p\n",
+ __FUNCTION__, (unsigned long) mapnum, (void *) hostaddrs,
+ sizes, kinds);
select_acc_device (device);
Index: target.c
===
--- target.c(Revision 221607)
+++ target.c(Arbeitskopie)
@@ -439,8 +439,8 @@ gomp_map_vars (struct gomp_device_descr
was missing. */
size_t size = k->host_end - k->host_start;
gomp_fatal ("present clause: !acc_is_present (%p, "
- "%zd (0x%zx))", (void *) k->host_start,
- size, size);
+ "%ld (0x%lx))", (void *) k->host_start,
+ (unsigned long) size, (unsigned long) size);
}
break;
case GOMP_MAP_FORCE_DEVICEPTR:
[Bug c++/60067] bogus error default template arguments may not be used in function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60067 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Mar 24 11:42:11 2015 New Revision: 221625 URL: https://gcc.gnu.org/viewcvs?rev=221625&root=gcc&view=rev Log: 2015-03-24 Paolo Carlini PR c++/60067 * g++.dg/template/defarg18.C: New. Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/60067] bogus error default template arguments may not be used in function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60067 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Mar 24 11:42:26 2015 New Revision: 221626 URL: https://gcc.gnu.org/viewcvs?rev=221626&root=gcc&view=rev Log: 2015-03-24 Paolo Carlini PR c++/60067 * g++.dg/template/defarg18.C: New. Added: trunk/gcc/testsuite/g++.dg/template/defarg18.C
[Bug c++/60067] bogus error default template arguments may not be used in function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60067 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.1, 5.0 Resolution|--- |FIXED Target Milestone|--- |4.9.1 --- Comment #4 from Paolo Carlini --- Done.
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #15 from Richard Biener ---
(In reply to Jakub Jelinek from comment #14)
> Created attachment 35073 [details]
> WIP patch
>
> So, on top of what you've committed, here is my unfinished attempt to
> disable for __bos undesirable transformations. On the:
> int
> main ()
> {
> struct A { char buf1[9]; char buf2[1]; } a;
> char *p = a.buf1;
> char *q = p + 1;
> char *r = q + 4;
> char *t = r - 1;
> strcpy (t, str1 + 5);
> return 0;
> }
> main of this PRs testcase, the match.pd snippet doesn't work (genmatch
> thinks ADDR_EXPR operand must be a SSA_NAME, where that is not valid
> gimple), we end up with
> q_2 = &a.buf1 + 1;
> t_4 = &MEM[(void *)q_2 + 3B];
that's from forwprop which runs into an ordering issue here. IMHO the
whole POINTER_PLUS_EXPR handling in that first loop is now "premature".
Disabling it yields
q_2 = &a.buf1 + 1;
r_3 = &a.buf1 + 5;
t_4 = &a.buf1 + 4;
str1.0_6 = str1;
_7 = str1.0_6 + 5;
_11 = __builtin_object_size (t_4, 1);
Note that I would have expected CCP to already do all this... it's
unfortunate that it can't consider '&a.buf1 + 1' a constant, simplifying
it along the way. But changing that is too much work at this point.
> which would be better expressed as
> t_4 = &a.buf1 + 4;
> and then FRE folds that into:
> t_4 = &MEM[(void *)&a + 4B];
Yep, and it still does that. For the same reason as CCP (make the
constant lattice work). Same awkward fix as for CCP:
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 221624)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -85,6 +85,7 @@ along with GCC; see the file COPYING3.
#include "ipa-ref.h"
#include "plugin-api.h"
#include "cgraph.h"
+#include "tree-pass.h"
/* This algorithm is based on the SCC algorithm presented by Keith
Cooper and L. Taylor Simpson in "SCC-Based Value numbering"
@@ -879,7 +880,7 @@ copy_reference_ops_from_ref (tree ref, v
trick here). */
&& (TREE_CODE (orig) != ADDR_EXPR
|| off != 0
- || cfun->after_inlining))
+ || (cfun->curr_properties & PROP_gimple_ebos)))
temp.off = off.to_shwi ();
}
}
@@ -3374,7 +3375,9 @@ simplify_binary_expression (gimple stmt)
if (code == POINTER_PLUS_EXPR
&& tree_fits_uhwi_p (op1)
&& TREE_CODE (op0) == ADDR_EXPR
- && is_gimple_min_invariant (op0))
+ && is_gimple_min_invariant (op0)
+ && (!handled_component_p (TREE_OPERAND (op0, 0))
+ || (cfun->curr_properties & PROP_gimple_ebos)))
return build_invariant_address (TREE_TYPE (op0),
TREE_OPERAND (op0, 0),
tree_to_uhwi (op1));
> so if we went this way, we'd need to change genmatch to handle ADDR_EXPRs
> specially, and FRE to avoid forwarding into &MEM if that would lose info.
I think trying to disable the pointer-plus-expr forwprop is more reasonable.
I'll see what we get as fallout from that.
So maybe we can "propagate" PROP_gimple_ebos up the cgraph in local-pure-const
to at least not pessimize functions that do not have __bos and won't get it
either via inlining (unfortunately local_pure_const is only run after
early opts, so it isn't really the suitable place to do this - cgraph build
maybe).
> Or, as discussed on IRC we can consider MEM_REFs where first operand isn't
> just
> SSA_NAME or ADDR_EXPR of a decl, but allow also ADDR_EXPR of
> handled_component_p (with base being a decl or MEM_REF with SSA_NAME first
> operand).
>
> Or add a new tree code, like OFFSETTED_ADDR_EXPR which would be like
> ADDR_EXPR, but with integer offset address to the ADDR_EXPR.
[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 --- Comment #15 from vehre at gcc dot gnu.org --- Author: vehre Date: Tue Mar 24 11:47:45 2015 New Revision: 221627 URL: https://gcc.gnu.org/viewcvs?rev=221627&root=gcc&view=rev Log: 2015-03-24 Andre Vehreschild PR fortran/55901 * trans-expr.c (gfc_conv_structure): Fixed indendation. Using integer_zero_node now instead of explicitly constructing a integer constant zero node. (gfc_conv_derived_to_class): Add handling of _len component, i.e., when the rhs has a string_length then assign that to class' _len, else assign 0. (gfc_conv_intrinsic_to_class): Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
[Bug c++/58194] [DR 1344] default argument for constructor outside of class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58194 Paolo Carlini changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #2 from Paolo Carlini --- Unsuspending, this is now C++14
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #16 from Richard Biener --- Ok, so disabling the forwprop breaks testcases like gcc.dg/tree-ssa/alias-21.c: : *r_2(D) = 0; _4 = r_2(D) + 4; *_4 = 1; _6 = *r_2(D); return _6; SCCVN isn't able to disambiguate *r_2(D) against *_4 because the alias machinery doesn't look at SSA defintions. forwprop also handles things like forwarding p + 4 into p->x.y.z or &p->x.y.z which we don't want to disable either. We do have both the address we propagate (with a suggested interface change to handle &xxx + CST without building a &MEM[]) and the tree we propagate to. So we should be able to reject / recover a pointer-plus in forward_propagate_addr_expr_1 as needed.
[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 --- Comment #6 from Uroš Bizjak --- I'm testing the following patch: --cut here-- Index: config/bootstrap-lto-noplugin.mk === --- config/bootstrap-lto-noplugin.mk(revision 0) +++ config/bootstrap-lto-noplugin.mk(revision 0) @@ -0,0 +1,6 @@ +# This option enables LTO for stage2 and stage3 on +# hosts without linker plugin support. + +STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects +STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects +STAGEprofile_CFLAGS += -fno-lto --cut here-- BTW: The documentation for bootstrap-lto is inadequate, as it does not mention any plugin support assumption or list any linker version requirement.
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #4 from Martin Liška ---
(In reply to Jan Hubicka from comment #0)
> As shown in https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01151.html
> warnings seems to come out wrong with large programs. I did not manage to
> reproduce it with small testcase. Columns tends to be 0 and line numbers
> (somewhat) off usually pointing to the begging of type definition instead of
> the field in question but sometimes they just point in further distance.
>
> This reproduce both on Fireofx and Chromium
>
> The problem goes away with:
>
> Index: lto-streamer-in.c
> ===
> --- lto-streamer-in.c (revision 221582)
> +++ lto-streamer-in.c (working copy)
> @@ -200,7 +200,7 @@ lto_input_location (struct bitpack_d *bp
>if (column_change)
> current_col = bp_unpack_var_len_unsigned (bp);
>
> - if (file_change)
> + if (file_change || 1)
> {
>if (prev_file)
> linemap_add (line_table, LC_LEAVE, false, NULL, 0);
>
> (which also quite significantly increases memory use). The warnings seems
> to be right on beggining and gets worse at end, so I suspect it is some kind
> of overflow in libcpp.
>
> The problem stays with:
>
> Index: lto-streamer-in.c
> ===
> --- lto-streamer-in.c (revision 221582)
> +++ lto-streamer-in.c (working copy)
> @@ -207,7 +207,7 @@ lto_input_location (struct bitpack_d *bp
>
>linemap_add (line_table, LC_ENTER, false, current_file, current_line);
> }
> - else if (line_change)
> + else if (line_change || 1)
> linemap_line_start (line_table, current_line, current_col);
>
>return linemap_position_for_column (line_table, current_col);
>
> One obvious thing is that linemap_line_start takes argument 3 to be max
> column hint, but we pass current_col that is not cool.
>
> I see that libcpp seems to drop the column info after some threshold (that
> is clearly too small for LTO) but why the line numbers are off?
Unfortunately, following patch causes SEGFAULT:
Program received signal SIGSEGV, Segmentation fault.
memset () at ../sysdeps/x86_64/memset.S:80
80../sysdeps/x86_64/memset.S: No such file or directory.
(gdb) bt
#0 memset () at ../sysdeps/x86_64/memset.S:80
#1 0x00ed8ebd in new_linemap (set=set@entry=0x77fee000,
reason=reason@entry=LC_ENTER) at ../../libcpp/line-map.c:265
#2 0x00ed9288 in linemap_add (set=0x77fee000,
reason=reason@entry=LC_ENTER, sysp=sysp@entry=0,
to_file=0x12d245f0 "../../ui/views/controls/image_view.h", to_line=92) at
../../libcpp/line-map.c:314
#3 0x0080d439 in lto_input_location (bp=,
data_in=) at ../../gcc/lto-streamer-in.c:208
#4 0x00a8ba06 in streamer_read_tree_bitfields
(ib=ib@entry=0x7fffd620, data_in=data_in@entry=0xc3281b0,
expr=expr@entry=0x7fff163d05e8) at ../../gcc/tree-streamer-in.c:506
#5 0x0080a572 in lto_read_tree_1 (ib=0x7fffd620,
data_in=0xc3281b0, expr=0x7fff163d05e8)
at ../../gcc/lto-streamer-in.c:1193
#6 0x0080a8e5 in lto_read_tree (hash=399977849, tag=,
data_in=0xc3281b0, ib=0x7fffd620)
at ../../gcc/lto-streamer-in.c:1230
#7 lto_input_tree_1 (ib=0x7fffd620, data_in=0xc3281b0, tag=, hash=399977849) at ../../gcc/lto-streamer-in.c:1349
#8 0x0080abe2 in lto_input_scc (ib=ib@entry=0x7fffd620,
data_in=data_in@entry=0xc3281b0, len=len@entry=0x7fffd618,
entry_len=entry_len@entry=0x7fffd61c) at
../../gcc/lto-streamer-in.c:1254
#9 0x005b39b7 in lto_read_decls
(decl_data=decl_data@entry=0x7fff1b99f000, data=data@entry=0x151de970,
resolutions=...,
resolutions@entry=...) at ../../gcc/lto/lto.c:1902
#10 0x005b52ac in lto_file_finalize (file=,
file_data=0x7fff1b99f000) at ../../gcc/lto/lto.c:2236
#11 lto_create_files_from_ids (count=,
file_data=0x7fff1b99f000, file=0xbf4b5f0) at ../../gcc/lto/lto.c:2246
#12 lto_file_read (count=, resolution_file=,
file=) at ../../gcc/lto/lto.c:2287
#13 read_cgraph_and_symbols (fnames=, nfiles=) at
../../gcc/lto/lto.c:2992
#14 lto_main () at ../../gcc/lto/lto.c:3462
#15 0x00903592 in compile_file () at ../../gcc/toplev.c:594
#16 0x0058f271 in do_compile () at ../../gcc/toplev.c:2076
#17 toplev::main (this=this@entry=0x7fffd7f0, argc=13846, argc@entry=34,
argv=0x192f9f0, argv@entry=0x7fffd8f8)
at ../../gcc/toplev.c:2174
#18 0x0058fa6a in main (argc=34, argv=0x7fffd8f8) at
../../gcc/main.c:39
More precisely, I used patched compiler just for WPA phase, should also this
set-up work?
Martin
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #2)
> The main issue with LTO is that it re-creates a combined linemap but in (most
> of the time) quite awkward ordering (simply registering random-ordered
> file:line:column entries by switching files/lines "appropriately").
>
> I've argued that it would be better to stream those file:line:columns
> separately so we can "sort" them before handing them over to libcpp for
> linemap re-creation.
If the lines or columns are out of order, then all bets are off. Line-map
locations have to be allocated incrementally. If you switch between files a
lot, then you are wasting a lot of memory unnecessarily, since switching
requires creating a new line-map.
How difficult would be to track on which file you are and simply have a
line_table per file and switch the current line_table appropriately?
> So currently we do, for each "file:line:column" location we stream in:
>
> if (file_change)
> {
> if (prev_file)
> linemap_add (line_table, LC_LEAVE, false, NULL, 0);
>
> linemap_add (line_table, LC_ENTER, false, current_file, current_line);
> }
> else if (line_change)
> linemap_line_start (line_table, current_line, current_col);
>
> return linemap_position_for_column (line_table, current_col);
>
> which of course puts a heavy load on the linemap encoding...
According to line-map.h:
/* Reason for creating a new line map with linemap_add. LC_ENTER is
when including a new file, e.g. a #include directive in C.
LC_LEAVE is when reaching a file's end. LC_RENAME is when a file
name or line number changes for neither of the above reasons
(e.g. a #line directive in C);
Thus I'm not sure the above is really correct. If a single line_table is
desirable, it probably should use LC_RENAME for different main files (as if
they were concatenated and using #line). LC_LEAVE/LC_ENTER only makes sense for
included files, which I presume are slightly different than concatenated files.
line-map.c has code to make some erroneous cases "work": I think they should be
replaced by linemap_assert_fails(), such that they trigger an assert when
checking but they try to recover gracefully otherwise.
How are the original locations stored on disk?
> But it should definitely work (not sure what it does on line or file
> "overflow").
I'm not sure lines or files can really overflow, but location_t can, and the
only "fix" is that column numbers get disabled (highest location > 0x6000),
but there is nothing stopping it from really overflowing after that.
[Bug tree-optimization/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519 --- Comment #15 from Richard Biener --- Patch needs adjustments, re-testing.
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #6 from Manuel López-Ibáñez --- (In reply to Jan Hubicka from comment #0) > One obvious thing is that linemap_line_start takes argument 3 to be max > column hint, but we pass current_col that is not cool. If I remember correctly, the column hint is only used to try to optimize memory. That is, if you provide a bad hint, then memory will be wasted (a too short hint may require additional maps for larger columns; a too large hint requires additional maps to encode the same number of lines). However, unless you pass a value of 10 or more, it should not affect the actual behavior.
[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515 --- Comment #7 from Jakub Jelinek --- Created attachment 35124 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35124&action=edit gcc5-pr65515.patch Lightly tested fix. Basically, most of DFS::DFS_write_tree is now moved into a loop in DFS::DFS, and for most worklist items we see them twice, once with NULL w.cstate (that will result in pushing further worklist items to the stack) and then again with non-NULL w.cstate (which is the part of DFS_write_tree at the end of function. The patch reorders the processing of trees embedded in a tree, we'll process the last inserted once before the earlier inserted ones for the same tree, not sure if that is a problem or not, but from the DFS POV they are all children of the same tree. If that would be a problem, it would be possible to rewrite DFS_write_tree_body to call DFS_write_tree in reverse order. But I hope it isn't a problem.
[Bug c++/65539] New: temp/ccCAfJgj.ltrans1.ltrans.o: In function `XSDFrontend::Traversal::Edge::~Edge()': /usr/include/xsd-frontend/traversal/elements.hxx:120: undef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65539 Bug ID: 65539 Summary: temp/ccCAfJgj.ltrans1.ltrans.o: In function `XSDFrontend::Traversal::Edge::~Edge()': /usr/include/xsd-frontend/traversal/elements.hxx:120: undefined reference to `VTT for XSDFrontend::Traversal::ContainsCompositor' Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nheghathivhistha at gmail dot com Both non-LTO and LTO builds of xsd fails to link. Gcc 4.9.2 was OK. How can I help in reducing this? Trunk revision 221614. gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.10.0-pre20150322/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.10.0-pre20150322/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.10.0_pre20150322/work/gcc-4.10.0-20150322/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.10.0-pre20150322 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.10.0-pre20150322/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-pre20150322 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-pre20150322/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-pre20150322/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.10.0-pre20150322/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-pre20150322/python --enable-languages=c,c++,fortran,ada --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.10.0_pre20150322' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --with-cloog --disable-isl-version-check --enable-libsanitizer Thread model: posix gcc version 4.10.0-pre20150322 20150324 (experimental) [trunk revision 221614] (Gentoo 4.10.0_pre20150322) LTO: x86_64-pc-linux-gnu-g++ -flto=4 -fuse-linker-plugin -O2 -g -pipe -march=core2 -mtune=core2 -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2 -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2 -o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/xsd /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/xsd.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/elements.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/literal-map.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/elements.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/validator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/name-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/type-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/state-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/generator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-inline.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-forward.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/impl-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/impl-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/driver-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/element-validation-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/attribute-validation-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/characters-validation-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/elements.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/validator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/counter.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/name-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/polymorphism-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/default-value.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xs
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #17 from Jakub Jelinek --- In *r_2(D) = 0; _4 = r_2(D) + 4; *_4 = 1; _6 = *r_2(D); there are no handled components, so there is no reason not to create &MEM_REF[r_2, 4]. But it shouldn't be hard to construct similar testcase where there are fields and we would regress.
[Bug tree-optimization/65492] Bad optimization in -O3 due to if-conversion and/or unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492 --- Comment #11 from Allan Jensen --- Issues with slow cmov has been seen in several bug reports: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309
[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515 --- Comment #8 from rguenther at suse dot de --- On Tue, 24 Mar 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515 > > --- Comment #7 from Jakub Jelinek --- > Created attachment 35124 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35124&action=edit > gcc5-pr65515.patch > > Lightly tested fix. Basically, most of DFS::DFS_write_tree is now moved into > a > loop in DFS::DFS, and for most worklist items we see them twice, once with > NULL > w.cstate (that will result in pushing further worklist items to the stack) and > then again with non-NULL w.cstate (which is the part of DFS_write_tree at the > end of function. > The patch reorders the processing of trees embedded in a tree, we'll process > the last inserted once before the earlier inserted ones for the same tree, not > sure if that is a problem or not, but from the DFS POV they are all children > of > the same tree. If that would be a problem, it would be possible to rewrite > DFS_write_tree_body to call DFS_write_tree in reverse order. But I hope it > isn't a problem. This shouldn't be a problem indeed.
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #18 from rguenther at suse dot de --- On Tue, 24 Mar 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 > > --- Comment #17 from Jakub Jelinek --- > In > *r_2(D) = 0; > _4 = r_2(D) + 4; > *_4 = 1; > _6 = *r_2(D); > there are no handled components, so there is no reason not to create > &MEM_REF[r_2, 4]. But it shouldn't be hard to construct similar testcase > where > there are fields and we would regress. Yes, this is also somewhat related to PR63916.
[Bug c++/65539] temp/ccCAfJgj.ltrans1.ltrans.o: In function `XSDFrontend::Traversal::Edge::~Edge()': /usr/include/xsd-frontend/traversal/elements.hxx:120: undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65539 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- /var/tmp/portage/sys-devel/gcc-4.10.0_pre20150322/ Perhaps time to change the version number you're using? 4.10.0 is dead, long live 5.0. Anyway, guess it is much easier for the non-LTO case, just build both with 4.9.x and 5.0, and attach 5.0 produced preprocessed source + command line options for: 1) one object where in 4.9.x it used to contain undefined reference to it and does so still in 5.0 2) another object where in 4.9.x it provided the symbol definition, but doesn't anymore
[Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65498 --- Comment #7 from Marek Polacek --- The problem appears to be that we're trying to use the body of the operator() function after it's been released (release_function_body). Investigating more...
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #7 from Richard Biener ---
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to Richard Biener from comment #2)
> > The main issue with LTO is that it re-creates a combined linemap but in
> > (most
> > of the time) quite awkward ordering (simply registering random-ordered
> > file:line:column entries by switching files/lines "appropriately").
> >
> > I've argued that it would be better to stream those file:line:columns
> > separately so we can "sort" them before handing them over to libcpp for
> > linemap re-creation.
>
> If the lines or columns are out of order, then all bets are off. Line-map
> locations have to be allocated incrementally. If you switch between files a
> lot, then you are wasting a lot of memory unnecessarily, since switching
> requires creating a new line-map.
>
> How difficult would be to track on which file you are and simply have a
> line_table per file and switch the current line_table appropriately?
>
> > So currently we do, for each "file:line:column" location we stream in:
> >
> > if (file_change)
> > {
> > if (prev_file)
> > linemap_add (line_table, LC_LEAVE, false, NULL, 0);
> >
> > linemap_add (line_table, LC_ENTER, false, current_file, current_line);
> > }
> > else if (line_change)
> > linemap_line_start (line_table, current_line, current_col);
> >
> > return linemap_position_for_column (line_table, current_col);
> >
> > which of course puts a heavy load on the linemap encoding...
>
> According to line-map.h:
>
> /* Reason for creating a new line map with linemap_add. LC_ENTER is
>when including a new file, e.g. a #include directive in C.
>LC_LEAVE is when reaching a file's end. LC_RENAME is when a file
>name or line number changes for neither of the above reasons
>(e.g. a #line directive in C);
>
> Thus I'm not sure the above is really correct. If a single line_table is
> desirable, it probably should use LC_RENAME for different main files (as if
> they were concatenated and using #line). LC_LEAVE/LC_ENTER only makes sense
> for included files, which I presume are slightly different than concatenated
> files.
I see. An issue is that we don't keep track of whether we entered a file
already (and after re-computing line-maps we lose any "nesting" of includes,
that is, we always have enter/leave pairs). But if LC_RENAME works even
when a file was never LC_ENTERed before then we can use it.
Not sure if it will make a difference though.
Index: gcc/lto-streamer-in.c
===
--- gcc/lto-streamer-in.c (revision 221619)
+++ gcc/lto-streamer-in.c (working copy)
@@ -182,7 +182,6 @@ lto_input_location (struct bitpack_d *bp
static int current_line;
static int current_col;
bool file_change, line_change, column_change;
- bool prev_file = current_file != NULL;
if (bp_unpack_value (bp, 1))
return UNKNOWN_LOCATION;
@@ -201,12 +200,7 @@ lto_input_location (struct bitpack_d *bp
current_col = bp_unpack_var_len_unsigned (bp);
if (file_change)
-{
- if (prev_file)
- linemap_add (line_table, LC_LEAVE, false, NULL, 0);
-
- linemap_add (line_table, LC_ENTER, false, current_file, current_line);
-}
+linemap_add (line_table, LC_RENAME, false, current_file, current_line);
else if (line_change)
linemap_line_start (line_table, current_line, current_col);
> line-map.c has code to make some erroneous cases "work": I think they should
> be replaced by linemap_assert_fails(), such that they trigger an assert when
> checking but they try to recover gracefully otherwise.
>
> How are the original locations stored on disk?
As string for file and two ints for line and column. Thus they are
stored "expanded". But they are interleaved with the trees / stmts they
are associated to.
[Bug c++/58156] bogus ambigous overload with variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58156 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-24 Ever confirmed|0 |1
[Bug c++/53628] [C++11][DR 712] Compiler requires definition of static member constants when not odr-used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53628 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0, 5.0 Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Paolo Carlini --- This works in the released 4.8.0.
[Bug fortran/65532] [5 Regression] Unexpected error with legacy code (D1MACH)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65532 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org
