How to access structure information from pass_vectorize
We are writing a GIMPLE pass and would like to use some information computed in pass_vectorize. However, we are not able to use the data structures which gets populated in pass_vectorize because the information is not made available across passes. In particular, we wish to access the structures stmt_vec_info and data_reference. How do we access this information? Should we invoke pass_vectorize as a sub-pass of our pass? Should we explicitly call the execute function of pass_vectorize in our pass? Or should we modify pass_vectorize code and make a deep copy in a global variable? Is there any other way of getting this information?
bootstrap broken for '-O3'
High, since trunk revision 206525 I'm unable to bootstrap gcc with '-O3' as optimisation. No problem until revision 2065250. From the diff-output it looks like this entry from ChangeLog is the only candidate: --- diff -urN -x.svn gcc-head-206520/LAST_UPDATED gcc-head-206525/LAST_UPDATED --- gcc-head-206520/LAST_UPDATED2014-01-19 17:54:07.053340903 +0100 +++ gcc-head-206525/LAST_UPDATED2014-01-19 18:58:54.049008110 +0100 @@ -1,2 +1,2 @@ -Sun Jan 19 17:54:07 CET 2014 -Sun Jan 19 16:54:07 UTC 2014 (revision 206520) +Sun Jan 19 18:58:54 CET 2014 +Sun Jan 19 17:58:54 UTC 2014 (revision 206525) diff -urN -x.svn gcc-head-206520/gcc/ChangeLog gcc-head-206525/gcc/ChangeLog --- gcc-head-206520/gcc/ChangeLog 2014-01-19 17:54:03.620441749 +0100 +++ gcc-head-206525/gcc/ChangeLog 2014-01-19 18:58:51.113097157 +0100 @@ -1,3 +1,15 @@ +2014-01-10 Richard Biener rguent...@suse.de + + PR tree-optimization/59374 + * tree-vect-slp.c (vect_slp_analyze_bb_1): Move dependence + checking after SLP discovery. Mark stmts not participating + in any SLP instance properly. + +2014-01-10 Kyrylo Tkachov kyrylo.tkac...@arm.com + + * config/arm/arm.c (arm_new_rtx_costs): Use destination mode + when handling a SET rtx. + 2014-01-10 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/arm/arm-cores.def (cortex-a53): Specify FL_CRC32. --- gcc is built with the following commands: --- CFLAGS=-O3; export CFLAGS CXXFLAGS=$CFLAGS; export CXXFLAGS CFLAGS=$CFLAGS CXXFLAGS=$CFLAGS XCFLAGS=$CFLAGS TCFLAGS=$CFLAGS \ ../gcc-head-206525/configure --enable-shared --prefix=/usr --enable-multilib=no --enable-checking=release --enable-werror=no --enable-languages='c,c++' configure.out make -j6 BOOT_CFLAGS=-O3 make.out || exit 1 --- and results in the following error: -- # make compare Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/bitmap.o differs gcc/bt-load.o differs gcc/emit-rtl.o differs libiberty/pic/md5.o differs libiberty/md5.o differs Makefile:20642: recipe for target 'compare' failed make: *** [compare] Error 1 -- I've verified the behaviour on opensuse 13.1 too to ensure it's not caused by local tool-chain. regards winfried
gcc-4.9-20140119 is now available
Snapshot gcc-4.9-20140119 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140119/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 206783 You'll find: gcc-4.9-20140119.tar.bz2 Complete GCC MD5=dbb12aba57d88ea1dfd8c1e940f5cf25 SHA1=c1db7a1970fe0e9bf695ff6444b71a979b94900b Diffs from 4.9-20140112 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Update MAINTAINERS (Re: Remove spam in GCC mailing list)
On Sun, 22 Dec 2013, Tae Wong wrote: It will be better if you have enabled the Launchpad account seotaewong40. This account has been suspended for renaming an answer title multiple times. The GCC team has nothing to do with Launchpad. There's also an ordering error on the GCC maintainer list: On the write after approval section, Xinliang David Li comes between H.J. Lu and Christophe Lyon: please fix the sort order so his name appears between Kriang Lerdsuwanakij and Jiangning Liu. Thanks for pointing this out. Fixed per the patch below. On the way I noticed (well, strictly speaking my editor did, and transparently so) that the MAINTAINERS file was ISO 8859, so I did the conversation to UTF-8 as well. It's 2014 after all. Gerald * MAINTAINERS: Convert to UTF-8. Properly sort Xinliang David Li's entry. Index: MAINTAINERS === --- MAINTAINERS (revision 206770) +++ MAINTAINERS (working copy) @@ -276,11 +276,11 @@ FortranErik Edelmann erik.edelm...@iki.fi FortranDaniel Franke franke.dan...@gmail.com FortranSteven G. Kargl s...@troutmask.apl.washington.edu -FortranThomas K?ig tkoe...@gcc.gnu.org +FortranThomas Königtkoe...@gcc.gnu.org FortranDaniel Kraftd...@domob.eu FortranToon Moene t...@moene.org FortranMikael Morinmikael.mo...@sfr.fr -FortranTobias Schl?er tobias.schlue...@physik.uni-muenchen.de +FortranTobias Schlüter tobias.schlue...@physik.uni-muenchen.de FortranPaul Thomas pa...@gcc.gnu.org FortranJanus Weil ja...@gcc.gnu.org gengtype/GTY Laurynas Biveinis laurynas.bivei...@gmail.com @@ -346,7 +346,7 @@ Stephane Carrezstcar...@nerim.fr Gabriel Charette gch...@google.com Chandra Chavva ccha...@redhat.com -Fabien Ch?efab...@gcc.gnu.org +Fabien Chêne fab...@gcc.gnu.org Bin Cheng bin.ch...@arm.com Harshit Chopra hars...@google.com William Cohen wco...@redhat.com @@ -353,7 +353,7 @@ Josh Connerjcon...@apple.com R. Kelley Cook kc...@gcc.gnu.org Christian Cornelssen cc...@cs.tu-berlin.de -Fran?is-Xavier Coudert fxcoud...@gcc.gnu.org +François-Xavier Coudertfxcoud...@gcc.gnu.org Cary Coutant ccout...@google.com Lawrence Crowl cr...@google.com Ian Dall i...@beware.dropbear.id.au @@ -361,7 +361,7 @@ Bud Davis jmda...@link.com Chris Demetriouc...@google.com Sameera Deshpande sameera.deshpa...@arm.com -Fran?is Dumont fdum...@gcc.gnu.org +François Dumontfdum...@gcc.gnu.org Benoit Dupont de Dinechin benoit.dupont-de-dinec...@st.com Michael Eager ea...@eagercon.com Bernd Edlinger bernd.edlin...@hotmail.de @@ -369,7 +369,7 @@ Mohan Embargnust...@thisiscool.com Revital Eres e...@il.ibm.com Marc Espie es...@cvs.openbsd.org -Rafael ?vila de Esp?dola espind...@google.com +Rafael Ávila de Espíndola espind...@google.com Ansgar Esztermann ans...@thphy.uni-duesseldorf.de Doug Evans d...@google.com Chris Fairles cfair...@gcc.gnu.org @@ -448,15 +448,15 @@ Marc Lehmann p...@goof.com James Lemkejwle...@codesourcery.com Kriang Lerdsuwanakij lerds...@users.sourceforge.net +Xinliang David Li davi...@google.com Jiangning Liu jiangning@arm.com Sa Liu sa...@de.ibm.com Ralph Loader r...@ihug.co.nz Gabor Loki l...@inf.u-szeged.hu Sandra Loosemore
[Bug libstdc++/59876] New: _Rb_tree move constructor invokes _M_copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59876
Bug ID: 59876
Summary: _Rb_tree move constructor invokes _M_copy
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: drahflow at gmx dot de
#include map
#include memory
using namespace std;
int main(void) {
mapint, unique_ptrint m1;
mapint, unique_ptrint m2(move(m1));
}
fails to compile under 4.9 (but works fine with 4.7 and 4.8).
A change was introduced in 4.9 after which the move constructor of _Rb_tree
invokes _M_copy on a range of elements (which might not be copy-constructible).
Cursory analysis suggests the problem is at
/usr/include/c++/4.9/bits/stl_tree.h line 1021.
[Bug tree-optimization/59875] Missed unrolling opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-19 Summary|Weak symbols in glibc |Missed unrolling |prevent optimizations |opportunity Ever confirmed|0 |1 Severity|trivial |normal --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- (note that your new/delete prototypes are the C++03 ones, you should change them for C++11) I don't think it has anything to do with glibc or weak. If I patch tree-ssa-loop-ivcanon.c (couldn't find a sufficient option or parameter) to convince the compiler that it is ok to unroll the loop although it isn't an inner loop and it contains calls on the hot path, it manages to optimize foo to nothing. gcc-4.4 (if we tweak the example so it compiles) did unroll the loop, but only optimized away the test for the last element of the array. It would also be possible for the compiler to notice that all array elements are the same and thus any access (in range) will yield the same value, but that seems more specialized.
[Bug c++/57926] Atomic functions broken with C++ but not C?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57926 --- Comment #11 from lailavrazda1979 at gmail dot com --- I don't mean to be a bother, but this hasn't been updated in a while. Has it been fixed?
[Bug bootstrap/59864] [4.9 regression] RTL check: expected code 'reg', have 'ne' in rhs_regno, at rtl.h:1125
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59864 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Patch has been installed.
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #18 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to H.J. Lu from comment #17) I prefer first patch. It splits all LEAs, where ix86_avoid_lea_for_addr is true. Then we should avoid the extra (set (reg:DI) (zero_extend:DI (reg:SI))) ree pass, located just after post-reload split, should handle this extra zero-extend insn. Based on this fact, we can just slap a zero-extend insn at the end of sequence with: --cut here-- Index: config/i386/i386.md === --- config/i386/i386.md (revision 206753) +++ config/i386/i386.md (working copy) @@ -5428,12 +5428,17 @@ operands[0] = SET_DEST (pat); operands[1] = SET_SRC (pat); - /* Emit all operations in SImode for zero-extended addresses. Recall - that x86_64 inheretly zero-extends SImode operations to DImode. */ + /* Emit all operations in SImode for zero-extended addresses. */ if (SImode_address_operand (operands[1], VOIDmode)) mode = SImode; ix86_split_lea_for_addr (curr_insn, operands, mode); + + /* Zero-extend return register to DImode for zero-extended addresses. */ + if (mode != MODEmode) +emit_insn (gen_zero_extendsidi2 + (operands[0], gen_lowpart ((mode), operands[0]))); + DONE; } [(set_attr type lea) --cut here-- I have checked that this patch with the testcase from Comment #9, using -O -march=corei7 -mtune=slm compile options. The resulting binary worked OK.
[Bug c++/59867] Template string literal loses first symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- Tuesday works for me ;) Seriously, thanks for looking into this.
[Bug fortran/34547] [4.8/4.9 regression] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||janus at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #12 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #11) Fixed by Paul's patch at http://gcc.gnu.org/ml/fortran/2013-11/msg00203.html ... which has been committed to trunk as r205565. Backport pending.
[Bug c++/59877] New: Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59877 Bug ID: 59877 Summary: Internal compiler error: Error reporting routines re-entered. Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hawran.diskuse at gmail dot com Created attachment 31889 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31889action=edit A preprocessed source. An error has occurred when compilling: == g++ -Wall -pedantic -g -std=c++11 main.cpp -o main ‘ Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Preprocessed source stored into /tmp/ccvp7WyF.out file, please attach this to your bugreport. Additional info: lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 13.04 Release:13.04 Codename: raring --- uname -a Linux ... 3.8.0-35-generic #50-Ubuntu SMP Tue Dec 3 01:24:59 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux --- gcc --version gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/59877] Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59877 --- Comment #1 from hawran.diskuse hawran.diskuse at gmail dot com --- Created attachment 31890 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31890action=edit A bug file and fixed file (I hope it could help)
[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766 --- Comment #1 from lucdanton at free dot fr --- Happens too with GCC 4.9 (20140105), as well as when using decltype(auto).
[Bug tree-optimization/59875] Missed unrolling opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875 --- Comment #2 from josephlawrie at hotmail dot com --- (In reply to Marc Glisse from comment #1) I don't think it has anything to do with glibc or weak. If I patch tree-ssa-loop-ivcanon.c (couldn't find a sufficient option or parameter) to convince the compiler that it is ok to unroll the loop although it isn't an inner loop and it contains calls on the hot path, it manages to optimize foo to nothing. Am I correct in understanding this would not be possible without -fno-weak or when linking dynamically? In those cases, the function of delete could not be know when optimizingm, surely?
[Bug fortran/57129] [4.7/4.8/4.9 Regression] ICE (segfault) in check_extended_derived_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #7) So r202823 is likely to have fixed this PR. I can confirm that r202823 has fixed the ICE: Reverting that revision reintroduces the ICE. I can also confirm that the ICE is gone on all recent versions of trunk, 4.8 and 4.7. However, the error message is now different from before for the test case in comment 0 and this reduction: subroutine t type t end type end With 4.6 one correctly gets: type t 1 Error: PROCEDURE attribute of 't' conflicts with DERIVED attribute at (1) while the recent versions now give: type t 1 Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 't' at (1) This is surprising, since the FUNCTION attribute is not specified anywhere in the test case. Apparently this is also due to Tobias' constructor patch (r181425).
[Bug fortran/34547] [4.8/4.9 regression] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 --- Comment #13 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Sun Jan 19 11:28:44 2014 New Revision: 206772 URL: http://gcc.gnu.org/viewcvs?rev=206772root=gccview=rev Log: 2014-01-19 Paul Thomas pa...@gcc.gnu.org PR fortran/34547 * resolve.c (resolve_transfer): EXPR_NULL is always in an invalid context in a transfer statement. 2014-01-19 Paul Thomas pa...@gcc.gnu.org PR fortran/34547 * gfortran.dg/null_5.f90 : Include new error. * gfortran.dg/null_6.f90 : Include new error. Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/resolve.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/null_5.f90 branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/null_6.f90
[Bug fortran/34547] [4.8/4.9 regression] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Paul Thomas pault at gcc dot gnu.org --- Finally backported to 4.8! Thanks for the report Paul
[Bug fortran/20585] [meta-bug] Fortran 2003 support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 34547, which changed state. Bug 34547 Summary: [4.8/4.9 regression] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/52125] Problems with LO16 asm operands on MIPS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52125 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Testing a patch.
[Bug bootstrap/59878] New: [4.9 Regression] ISL from cloog does not work with trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878
Bug ID: 59878
Summary: [4.9 Regression] ISL from cloog does not work with
trunk
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
How to reproduce:
- Get isl from infrastructure directory
- configure
- install by default (installs in /usr/local)
- Get cloog from the infrastructure directory
- configure without any options
- install
- configure using
VER=../trunk/configure test -e $VER rm -rf * $VER --prefix=$HOME
--with-isl=/usr/local --with-cloog=/usr/local --enable-languages=c,fortran,c++
make -j6 make install
Result then is
checking for the correct version of the gmp/mpfr/mpc libraries... yes
checking for version 0.10 of ISL... no
checking for version 0.11 of ISL... no
checking for version 0.12 of ISL... no
configure: error: Unable to find a usable ISL. See config.log for details.
The reason for this is shown in the modified test program:
ig25@linux-fd1f:/tmp cat isl.c
#include isl/version.h
#include stdio.h
int
main ()
{
printf(%s, isl_version ());
}
ig25@linux-fd1f:/tmp gcc isl.c -lisl
ig25@linux-fd1f:/tmp ./a.out
UNKNOWN
It is necessary to configure cloog with --with-isl=system go get around that,
which is not documented anywhere.
[Bug libstdc++/59876] _Rb_tree move constructor invokes _M_copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59876 --- Comment #1 from Jens-Wolfhard Schicke drahflow at gmx dot de --- Sorry, I forgot. ~ % gcc-4.9 --version gcc-4.9 (Debian 4.9-20140116-1) 4.9.0 20140116 (experimental) [trunk revision 206688] ~ % dpkg -l libstdc++-4.9-dev:amd64 ||/ Name Version Architecture Description +++-==---= ii libstdc++-4.9- 4.9-20140116 amd64GNU Standard C++ Library v3 (deve
[Bug bootstrap/59878] [4.9 Regression] ISL from cloog does not work with trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- See http://gcc.gnu.org/install/prerequisites.html.
[Bug tree-optimization/59875] Missed unrolling opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to josephlawrie from comment #2)
(In reply to Marc Glisse from comment #1)
Am I correct in understanding this would not be possible without -fno-weak
or when linking dynamically? In those cases, the function of delete could
not be know when optimizingm, surely?
My comments were for the version where you uncomment the definitions of new and
delete:
#include array
#include cassert
#include cstdlib
struct P {
P() : _value(0) {}
~P() { if(_value) free(_value); }
char *_value;
};
int main() {
if(std::arrayP, 4().size() != 4)
assert(false);
}
You can look at what happens if you change the size of the array to 1, which
removes the unrolling issue. After unrolling, you get either 4 calls to
operator delete(0), or nothing if you provided your definition of delete.
To let the compiler know that you want the standard operator delete (which does
nothing on 0), I am not sure what should be done. It is a different issue,
which you would need to ask about in a separate PR. The easiest is probably to
use -flto (it has to be used all the way, in particular when building
libsupc++). I think libstdc++ should provide an option to get inline
definitions of those functions (I know the standard forbids them to be inline),
possibly even omitting the new_handler code.
[Bug fortran/55172] [4.7 Regression] [OOP] gfc_variable_attr(): Bad array reference in SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55172 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas pault at gcc dot gnu.org --- I think that it is best to leave this unfixed for 4.7 - see comment #5 I have therefore marked the PR as resolved. Thanks for the report Paul
[Bug fortran/59414] [4.8/4.9 Regression] [OOP] ICE in in gfc_conv_expr_descriptor on ALLOCATE inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 --- Comment #12 from Paul Thomas pault at gcc dot gnu.org --- (In reply to janus from comment #3) snip module ObjectLists implicit none type :: t end type type Object_array_pointer class(t), pointer :: p(:) end type contains subroutine AddArray (P, Pt) class(t) :: P(:) class(Object_array_pointer) :: Pt select type (Pt) class is (Object_array_pointer) ICE disappears with type is (Object_array_pointer) allocate(Pt%P(1:SIZE(P)), source=P) end select end subroutine end module Paul
[Bug libstdc++/59876] _Rb_tree move constructor invokes _M_copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59876 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- isn't this a duplicate of PR 59872?
[Bug libstdc++/59872] [4.9 Regression] Cannot move std::map with move-only mapped_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-19 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|Cannot move std::map with |[4.9 Regression] Cannot |move-only mapped_type |move std::map with ||move-only mapped_type Ever confirmed|0 |1
[Bug libstdc++/59872] [4.9 Regression] Cannot move std::map with move-only mapped_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- I don't want to use SFINAE here, I'll fix it the same way it's done in the other containers, tag dispatching using std::integral_constantbool, _Alloc_Traits::_S_always_Equal()
[Bug libstdc++/59872] [4.9 Regression] Cannot move std::map with move-only mapped_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872 --- Comment #7 from David Krauss potswa at mac dot com --- That's a better factoring. I was just avoiding creating a new, named function. Thanks!
[Bug tree-optimization/59875] Missed unrolling opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875 --- Comment #4 from josephlawrie at hotmail dot com --- To let the compiler know that you want the standard operator delete (which does nothing on 0), I am not sure what should be done. It is a different issue, which you would need to ask about in a separate PR. I think libstdc++ should provide an option to get inline definitions of those functions (I know the standard forbids them to be inline), possibly even omitting the new_handler code. Thank you - I realise I was originally very unclear, but being able to get an inline version was the intention of posting this hear. Basically link time optimization (inconvienient) or static linking (also inconvenient) are the only correct solitions, as others would make the functions non-replacable. My concern was that being unable to specify default delete could prevent optimization in some cases (even when building statically), but according to you this is not the case in the example, as it is the loop unrolling that prevents the optimization here. Thank you.
[Bug c++/59879] New: arrays in return statements or default arguments decay too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59879
Bug ID: 59879
Summary: arrays in return statements or default arguments decay
too early
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: st at quanttec dot com
g++ seems to decay arrays in return statements or default arguments too early.
The following sample fails to compile with 4.8.2 and the current GIT master
version of gcc but compiles cleanly in clang:
--
struct Test {
template int N
Test(const char (array)[N]) {}
};
Test test() {
return test;
}
void test2(Test arg = test) {}
int main() {
test();
test2();
}
--
g++ test.cpp
test.cpp: In function ‘Test test()’:
test.cpp:8:10: error: could not convert ‘(const char*)test’ from ‘const
char*’ to ‘Test’
return test;
^
test.cpp: In function ‘int main()’:
test.cpp:15:9: error: could not convert ‘(const char*)test’ from ‘const
char*’ to ‘Test’
test2();
^
[Bug libstdc++/59872] [4.9 Regression] Cannot move std::map with move-only mapped_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||drahflow at gmx dot de --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 59876 has been marked as a duplicate of this bug. ***
[Bug libstdc++/59876] _Rb_tree move constructor invokes _M_copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59876 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- dup *** This bug has been marked as a duplicate of bug 59872 ***
[Bug other/59862] Code does not compile with 4.8.1 tarball release but compiles with 4.8.1 SVN release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) I have downloaded the two releases. Comparing gcc/fortran, the only difference is Only in gcc-4.8.1/gcc/fortran/: gfortran.info in wget http://ftp.gnu.org/gnu/gcc/gcc-4.8.1/gcc-4.8.1.tar.gz Comparing gcc, the only difference is Only in gcc-4.8.1/gcc/: gengtype-lex.c I don't know if the presence or not of gengtype-lex.c can explain what you report. IMO this is a packaging issue not a gfortran one. I'ld like to close it as WONTFIX, but I am CCing release managers for advice. The release tarball contain generated files so you don't need tools like flex or makeinfo to build GCC. Those are not present in SVN, so this is definitely not a packaging bug.
[Bug fortran/57129] [4.7/4.8/4.9 Regression] Improve error message for conflicts between PROCEDURE and DERIVED.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords|error-recovery, |diagnostic |ice-on-invalid-code | Priority|P4 |P5 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8/4.9 Regression] |ICE (segfault) in |Improve error message for |check_extended_derived_type |conflicts between PROCEDURE ||and DERIVED. Severity|normal |minor --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- However, the error message is now different from before for the test case in comment 0 and this reduction: ... Confirmed. AFAICT the error message with 4.6 comes from gcc/fortran/symbol.c while the present one comes from gcc/fortran/dec.c. I have changed the summary to reflect the present situation. Should we keep the regression flags?
[Bug other/59862] Code does not compile with 4.8.1 tarball release but compiles with 4.8.1 SVN release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- The release tarball contain generated files so you don't need tools like flex or makeinfo to build GCC. Those are not present in SVN, so this is definitely not a packaging bug. Not sure to understand: gcc/gengtype-lex.c is in the tarball, but not in SVN. From the above I understand that gcc/gengtype-lex.c should also not be in the tarball. Is this correct? What could be the effect of gcc/gengtype-lex.c?
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379
--- Comment #19 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Uroš Bizjak from comment #18)
I have checked that this patch with the testcase from Comment #9, using -O
-march=corei7 -mtune=slm compile options. The resulting binary worked OK.
Yes, the resulting GCC works correctly. However, we generate
extra
(set (reg:DI) (zero_extend:DI (reg:SI)))
It is because we generate
(set (reg:SI) (reg:SI)
(set (reg:DI) (zero_extend:DI (reg:SI)))
REE pass doesn't know
(set (reg:SI) (reg:SI)
has an implicit ZERO_EXTEND. Here is a testcase:
---foo.c---
extern __thread unsigned int __bid_IDEC_glbflags;
typedef unsigned long long UINT64;
typedef __attribute__ ((aligned(16))) struct
{
UINT64 w[2];
} UINT128;
extern UINT64 __bid64_from_uint64 (UINT64);
extern void __bid_round64_2_18 (int q,
int x,
UINT64 C,
UINT64 * ptr_Cstar,
int *delta_exp,
int *ptr_is_midpoint_lt_even,
int *ptr_is_midpoint_gt_even,
int *ptr_is_inexact_lt_midpoint,
int *ptr_is_inexact_gt_midpoint);
extern void __bid_round128_19_38 (int q,
int x,
UINT128 C,
UINT128 * ptr_Cstar,
int *delta_exp,
int *ptr_is_midpoint_lt_even,
int *ptr_is_midpoint_gt_even,
int *ptr_is_inexact_lt_midpoint,
int *ptr_is_inexact_gt_midpoint);
UINT64
__bid64_from_uint64 (UINT64 x)
{
UINT64 res;
UINT128 x128, res128;
unsigned int q, ind;
int incr_exp = 0;
int is_midpoint_lt_even = 0, is_midpoint_gt_even = 0;
int is_inexact_lt_midpoint = 0, is_inexact_gt_midpoint = 0;
if (x = 0x002386F26FC0ull) {
if (x 0x0020ull) {
res = 0x31c0ull | x;
} else {
res = 0x6c70ull | (x 0x0007ull);
}
}
else
{
if (x 0x16345785d8aull) {
q = 17;
ind = 1;
} else if (x 0xde0b6b3a764ull) {
q = 18;
ind = 2;
} else if (x 0x8ac7230489e8ull) {
q = 19;
ind = 3;
} else {
q = 20;
ind = 4;
}
if (q = 19) {
__bid_round64_2_18 (
q, ind, x, res, incr_exp,
is_midpoint_lt_even, is_midpoint_gt_even,
is_inexact_lt_midpoint, is_inexact_gt_midpoint);
}
else {
x128.w[1] = 0x0;
x128.w[0] = x;
__bid_round128_19_38 (q, ind, x128, res128, incr_exp,
is_midpoint_lt_even, is_midpoint_gt_even,
is_inexact_lt_midpoint, is_inexact_gt_midpoint);
res = res128.w[0];
}
if (incr_exp)
ind++;
if (is_inexact_lt_midpoint || is_inexact_gt_midpoint ||
is_midpoint_lt_even || is_midpoint_gt_even)
*__bid_IDEC_glbflags |= 0x0020;
if (res 0x0020ull) {
res = (((UINT64) ind + 398) 53) | res;
} else
{
res = 0x6000ull | (((UINT64) ind + 398) 51) |
(res 0x0007ull);
}
}
return(res);;
}
---
Compiling with -fPIC -O2, the differences between your patch and mine
are
--- bad.s2014-01-19 06:10:28.006570325 -0800
+++ foo.s2014-01-19 06:11:46.117754696 -0800
@@ -84,19 +84,18 @@ __bid64_from_uint64:
movabsq$9007199254740991, %rax
cmpq%rax, %rbx
jbe.L23
-movl%ebp, %edx
leaq88(%rsp), %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
movabsq$2251799813685247, %rax
-movl%edx, %edx
+movl%ebp, %edx
andq%rbx, %rax
-movabsq$6917529027641081856, %rcx
popq%rbx
.cfi_def_cfa_offset 16
+movabsq$6917529027641081856, %rcx
addq$398, %rdx
-orq%rcx, %rax
salq$51, %rdx
+orq%rcx, %rax
popq%rbp
.cfi_def_cfa_offset 8
orq%rdx, %rax
@@ -154,7 +153,6 @@ __bid64_from_uint64:
leaq88(%rsp), %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
-movl%eax, %eax
addq$398, %rax
salq$53, %rax
orq%rbx, %rax
My patch removes 2 extra
(set (reg:DI) (zero_extend:DI (reg:SI)))
[Bug other/59862] Code does not compile with 4.8.1 tarball release but compiles with 4.8.1 SVN release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de --- On Sun, 19 Jan 2014, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- The release tarball contain generated files so you don't need tools like flex or makeinfo to build GCC. Those are not present in SVN, so this is definitely not a packaging bug. Not sure to understand: gcc/gengtype-lex.c is in the tarball, but not in SVN. From the above I understand that gcc/gengtype-lex.c should also not be in the tarball. No, it is in the tarball so building does not require the tools to build it. Is this correct? What could be the effect of gcc/gengtype-lex.c? That local flex is not used to build gengtype-lex.c from gengtype-lex.l
[Bug tree-optimization/59860] [4.8/4.9 Regression] ICE in compute_may_aliases, at tree-ssa-structalias.c:6843
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59860 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- The issue is that after folding strcat_chk - strcat - strcpy (dst + strlen, ...) we do gimplify_and_update_call_from_tree which as part of gimplification folds the builtins again, which enters update_call_from_tree which tries to preserve virtual operands (which are not yet there) and finally calls gsi_replace which does update_stmt (). That causes virtual operands to be marked for renaming even if the outer folding routines happily update virtual operands correctly. So the issue is that we re-enter the builtin folding machinery via gimplification and that is able to fold things further than builtins.c folding which recurses to the tree foldings. I'm inclined to disable that if ctx-into_ssa, or add a new flag, -fold_calls. [in the end we want to remove all stmt folding from the gimplifier and maybe have one strategical place where we fold all stmts once] Or, less intrusive, remove that strcat folding from GENERIC folding (builtins.c) as we have tree-ssa-strlen.c now which optimizes it for the interesting case of an already available string length - generally folding strcat to strcpy (dst + strlen (dst), src) isn't profitable. That also gets rid of that odd optimize_insn_for_speed_p call in builtins.c [I've skimmed through other calls we generate in builtins.c and decided the above is the only case where we can recurse into gimple call folding]
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Sun Jan 19 15:30:22 2014 New Revision: 206773 URL: http://gcc.gnu.org/viewcvs?rev=206773root=gccview=rev Log: PR rtl-optimization/57763 * bb-reorder.c (fix_crossing_unconditional_branches): Set JUMP_LABEL on the new indirect jump_insn and increment LABEL_NUSES (label). Modified: trunk/gcc/ChangeLog trunk/gcc/bb-reorder.c
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #20 from uros at gcc dot gnu.org --- Author: uros Date: Sun Jan 19 15:48:14 2014 New Revision: 206774 URL: http://gcc.gnu.org/viewcvs?rev=206774root=gccview=rev Log: PR target/59379 * config/i386/i386.md (*leamode): Zero-extend return register to DImode for zero-extended addresses. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug rtl-optimization/59880] New: Improve REE for implicit SI-DI zero-extend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880
Bug ID: 59880
Summary: Improve REE for implicit SI-DI zero-extend
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
After r206774, on Linux/x86-64, the following code
---foo.c---
extern __thread unsigned int __bid_IDEC_glbflags;
typedef unsigned long long UINT64;
typedef __attribute__ ((aligned(16))) struct
{
UINT64 w[2];
} UINT128;
extern UINT64 __bid64_from_uint64 (UINT64);
extern void __bid_round64_2_18 (int q,
int x,
UINT64 C,
UINT64 * ptr_Cstar,
int *delta_exp,
int *ptr_is_midpoint_lt_even,
int *ptr_is_midpoint_gt_even,
int *ptr_is_inexact_lt_midpoint,
int *ptr_is_inexact_gt_midpoint);
extern void __bid_round128_19_38 (int q,
int x,
UINT128 C,
UINT128 * ptr_Cstar,
int *delta_exp,
int *ptr_is_midpoint_lt_even,
int *ptr_is_midpoint_gt_even,
int *ptr_is_inexact_lt_midpoint,
int *ptr_is_inexact_gt_midpoint);
UINT64
__bid64_from_uint64 (UINT64 x)
{
UINT64 res;
UINT128 x128, res128;
unsigned int q, ind;
int incr_exp = 0;
int is_midpoint_lt_even = 0, is_midpoint_gt_even = 0;
int is_inexact_lt_midpoint = 0, is_inexact_gt_midpoint = 0;
if (x = 0x002386F26FC0ull) {
if (x 0x0020ull) {
res = 0x31c0ull | x;
} else {
res = 0x6c70ull | (x 0x0007ull);
}
}
else
{
if (x 0x16345785d8aull) {
q = 17;
ind = 1;
} else if (x 0xde0b6b3a764ull) {
q = 18;
ind = 2;
} else if (x 0x8ac7230489e8ull) {
q = 19;
ind = 3;
} else {
q = 20;
ind = 4;
}
if (q = 19) {
__bid_round64_2_18 (
q, ind, x, res, incr_exp,
is_midpoint_lt_even, is_midpoint_gt_even,
is_inexact_lt_midpoint, is_inexact_gt_midpoint);
}
else {
x128.w[1] = 0x0;
x128.w[0] = x;
__bid_round128_19_38 (q, ind, x128, res128, incr_exp,
is_midpoint_lt_even, is_midpoint_gt_even,
is_inexact_lt_midpoint, is_inexact_gt_midpoint);
res = res128.w[0];
}
if (incr_exp)
ind++;
if (is_inexact_lt_midpoint || is_inexact_gt_midpoint ||
is_midpoint_lt_even || is_midpoint_gt_even)
*__bid_IDEC_glbflags |= 0x0020;
if (res 0x0020ull) {
res = (((UINT64) ind + 398) 53) | res;
} else
{
res = 0x6000ull | (((UINT64) ind + 398) 51) |
(res 0x0007ull);
}
}
return(res);;
}
---
contains 2 extra SI-DI zero-extend when compiled with
-O2 -march=corei7 -mtune=slm -fPIC
movl%ebp, %edx # 311 *movsi_internal/1 [length = 2]
^^^ Implicit SI-DI zero-extend
leaq88(%rsp), %rsp # 267 pro_epilogue_adjust_stack_di_add/1
[length = 5]
.cfi_remember_state
.cfi_def_cfa_offset 24
movabsq $2251799813685247, %rax # 101 *movdi_internal/5 [length
= 10]
movl%edx, %edx # 312 *zero_extendsidi2/4 [length = 2]
^^^ Unnecessary
movl%ebp, %eax # 308 *movsi_internal/1 [length = 2]
^^^ Implicit SI-DI zero-extend
leaq88(%rsp), %rsp # 287 pro_epilogue_adjust_stack_di_add/1
[length = 5]
.cfi_remember_state
.cfi_def_cfa_offset 24
movl%eax, %eax # 309 *zero_extendsidi2/4 [length = 2]
Unnecessary
REE pass should remove them.
[Bug c++/59867] Template string literal loses first symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867 --- Comment #10 from Ed Smith-Rowland 3dw4rd at verizon dot net --- Right now, -std=c++1y means anything after c++11. Does anyone have an idea about what happens when C++14 and these other TSen actually come out? I guess I was thinking as far as this extension is concerned: 1) It is left *on* for c++1y and gnu++1y for backward compatibility. Sigh. 2) It is *on* with gnu++14 as an extension. 3) It is *off* with c++14 for strict ANSI compatibility. 4) It is maybe on for c++17 and gnu++17 when if it ever gets in. We seem to have dynamically sized array (VLA) in this category as well.
[Bug rtl-optimization/59880] Improve REE for implicit SI-DI zero-extend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
But REE does the right thing here:
In *.split2 before REE we have:
(insn 218 92 219 16 (set (reg:SI 0 ax [orig:123 D.1966 ] [123])
(reg/v:SI 6 bp [orig:85 ind ] [85])) pr59880.c:77 90 {*movsi_internal}
(nil))
(insn 219 218 94 16 (set (reg:DI 0 ax [orig:123 D.1966 ] [123])
(zero_extend:DI (reg:SI 0 ax [orig:123 D.1966 ] [123]))) pr59880.c:77
132 {*zero_extendsidi2}
(nil))
and REE turns that into:
(insn 218 92 94 16 (set (reg:DI 0 ax)
(zero_extend:DI (reg/v:SI 6 bp [orig:85 ind ] [85]))) pr59880.c:77 132
{*zero_extendsidi2}
(nil))
Then split4 splits that again into:
(insn 308 92 309 21 (set (reg:SI 0 ax)
(reg/v:SI 6 bp [orig:85 ind ] [85])) pr59880.c:77 90 {*movsi_internal}
(nil))
(insn 309 308 94 21 (set (reg:DI 0 ax)
(zero_extend:DI (reg:SI 0 ax))) pr59880.c:77 132 {*zero_extendsidi2}
(nil))
and finally sched2 moves those 2 insns appart. So, this is clearly a backend
issue.
[Bug fortran/59881] New: Memory corruption with allocatable arrays in polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881 Bug ID: 59881 Summary: Memory corruption with allocatable arrays in polymorphic types Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Created attachment 31891 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31891action=edit Tar ball that produces code triggering the memory corruption. The code attached (unpack, do make, make run) triggers the memory leak. Sorry for not being able/having time to reduce the case further. The propgram ./seg_prod reads in the file structure_5.sin specifying a scan over integer and real values that is steered in commands.f90 via the type range_t. First there is some test output (the internal tree-like syntax structure we use),the trivial examples pass, the final example with a multi-component range fails. The example works with gfortran 4.8.x and 4.9.0, but fails with all 4.7.x. Sometimes the values are forgotten, sometimes a memory leak appears. We were able to program around this, but nevertheless wanted to file a bug report. Here in our svn commit you can see how we basically removed one layer of polymorphism for the type range_t: https://whizard.hepforge.org/trac/changeset/5096 Furthermore, the finalizer range_final then worked again. Hope, you can boil this down to the essential part.
[Bug other/59882] New: dev-cpp/xsd: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59882
Bug ID: 59882
Summary: dev-cpp/xsd: internal compiler error: Segmentation
fault
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: nheghathivhistha at gmail dot com
Created attachment 31892
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31892action=edit
Preprocessed source file - not reduced
Current trunk segfaults:
x86_64-pc-linux-gnu-g++
-I/var/tmp/portage/dev-cpp/xsd-3.3.0-r1/work/xsd-3.3.0/xsd -save-temps -fPIC
-O2 -ggdb -march=native -mtune=native -mno-avx -mno-sse4.2 -mno-3dnow -o
/var/tmp/portage/dev-cpp/xsd-3.3.0-r1/work/xsd-3.3.0/xsd/cxx/parser/driver-source.o
-c
/var/tmp/portage/dev-cpp/xsd-3.3.0-r1/work/xsd-3.3.0/xsd/cxx/parser/driver-source.cxx
/var/tmp/portage/dev-cpp/xsd-3.3.0-r1/work/xsd-3.3.0/xsd/cxx/parser/driver-source.cxx:
In member function ‘virtual Cult::Types::Fundamental::Void
CXX::Parser::{anonymous}::ArgList::traverse(XSDFrontend::SemanticGraph::Complex)’:
/var/tmp/portage/dev-cpp/xsd-3.3.0-r1/work/xsd-3.3.0/xsd/cxx/parser/driver-source.cxx:520:9:
internal compiler error: Neoprávněný přístup do paměti (SIGSEGV)
traverse (SemanticGraph::Complex c)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.gentoo.org/ for instructions.
I am c-reducing a test case with -O2 -ggdb -fPIC.
[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-19 CC||uros at gcc dot gnu.org Summary|Improve REE for implicit|ix86_avoid_lea_for_addr is |SI-DI zero-extend |buggy Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Ah, indeed, it is split because of the: (define_insn_and_split *leamode [(set (match_operand:SWI48 0 register_operand =r) (match_operand:SWI48 1 address_no_seg_operand Ts))] splitter. I'd say it is a bug in ix86_avoid_lea_for_addr, that shouldn't have returned true in this case, where the second operand is (zero_extend:DI (reg:SI)).
[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jakub Jelinek from comment #2) Ah, indeed, it is split because of the: (define_insn_and_split *leamode [(set (match_operand:SWI48 0 register_operand =r) (match_operand:SWI48 1 address_no_seg_operand Ts))] splitter. I'd say it is a bug in ix86_avoid_lea_for_addr, that shouldn't have returned true in this case, where the second operand is (zero_extend:DI (reg:SI)). My patch for PR 59379: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01166.html doesn't have this problem Should we consider my patch instead?
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Can't reproduce anymore with 4.7/4.8/4.9 (but with 4.6 I can), thus hopefully fixed.
[Bug fortran/58410] [4.8/4.9 Regression] Bogus uninitialized variable warning for allocatable derived type array function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410 --- Comment #6 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Sun Jan 19 18:04:22 2014 New Revision: 206778 URL: http://gcc.gnu.org/viewcvs?rev=206778root=gccview=rev Log: 2014-01-19 Paul Thomas pa...@gcc.gnu.org PR fortran/58410 * trans-array.c (gfc_alloc_allocatable_for_assignment): Do not use the array bounds of an unallocated array but set its size to zero instead. Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-array.c
[Bug fortran/58410] [4.8/4.9 Regression] Bogus uninitialized variable warning for allocatable derived type array function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas pault at gcc dot gnu.org --- Fixed on trunk and 4.8. Thanks for the report Paul
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 58410, which changed state. Bug 58410 Summary: [4.8/4.9 Regression] Bogus uninitialized variable warning for allocatable derived type array function result http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #2) Ah, indeed, it is split because of the: (define_insn_and_split *leamode [(set (match_operand:SWI48 0 register_operand =r) (match_operand:SWI48 1 address_no_seg_operand Ts))] splitter. I'd say it is a bug in ix86_avoid_lea_for_addr, that shouldn't have returned true in this case, where the second operand is (zero_extend:DI (reg:SI)). It shouldn't split this RTX, ix86_avoid_lea_for_addr has: /* There should be at least two components in the address. */ if ((parts.base != NULL_RTX) + (parts.index != NULL_RTX) + (parts.disp != NULL_RTX) + (parts.scale 1) 2) return false;
[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31893 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31893action=edit gcc49-pr59880.patch Untested fix. The reason for the problem is that if it is just a (zero-extended SI-DI or normal) move from %r13, %rbp or (for k6 %esi), then decomposition sets parts.disp to const0_rtx and thus we count it as two parts, even when we wouldn't emit it as a lea insn originally.
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 eggert at gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #9 from eggert at gnu dot org --- (In reply to Marek Polacek from comment #8) Can't reproduce anymore with 4.7/4.8/4.9 (but with 4.6 I can), thus hopefully fixed. Thanks, but which test case did you use, and which version of 4.8? I can reproduce the bug with the first test case (u.i) with the GCC 4.8.2 that is shipped with Fedora 20 (it says it is gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7)). That is, the bug with the second test case is fixed with 4.8.2, but the bug with the first test case remains.
[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #5) Created attachment 31893 [details] gcc49-pr59880.patch Untested fix. The reason for the problem is that if it is just a (zero-extended SI-DI or normal) move from %r13, %rbp or (for k6 %esi), then decomposition sets parts.disp to const0_rtx and thus we count it as two parts, even when we wouldn't emit it as a lea insn originally. True. However, can you put new test before costly call to ix86_ok_to_clobber_flags and ix86_decompose_address?
[Bug c++/57172] [C++11][DR 1164] Template overload resolution ambiguous for T versus T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||leonid at volnitsky dot com --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- *** Bug 54425 has been marked as a duplicate of this bug. ***
[Bug c++/54425] Rvalue/Lvalue overload resolution of templated function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54425 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||glisse at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- Already fixed on trunk. *** This bug has been marked as a duplicate of bug 57172 ***
[Bug c++/59883] New: Missed C++ front-end devirtualizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59883
Bug ID: 59883
Summary: Missed C++ front-end devirtualizations
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
I believe the following testcase:
struct A
{
virtual int foo (void) {return foo();}
};
struct B {
struct A a;
};
struct A a[7];
int test(void)
{
return a[3].foo();
}
int test2(struct B *b)
{
return b-a.foo();
}
ought to get devirtualized by C++ FE based on the fact that the object is
contained within an structure or array. (this is related to PR46507)
In the following testcase:
namespace {
struct A
{
virtual int foo (void) {return 42;}
};
}
int test(void)
{
struct A a, *b=a;
return b-foo();
}
We can now probably use ipa-devirt's type inheritance graph to work out right
away that A is a final class.
And finally:
struct A
{
virtual int foo (void) {return foo();}
};
IMO allows devirtualization of self recursive functions
[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-19 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The example works with gfortran 4.8.x and 4.9.0, but fails with all 4.7.x. I have built and ran the test without problem with 4.8.2 and almost latest trunk without problem (few runs) and got random problems with 4.7.4. I'll try to do some bisection to see it is known issue that has been fixed between 4.7 and 4.8, but don't expect a quick answer. I would be nice if you can reduce your test further.
[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Sure, will do. Thought about that as well, just didn't change it before attaching ;)
[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-19 Ever confirmed|0 |1 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Ah, on u.i I can see it, too. Sorry, I thought the testcases are equivalent.
[Bug fortran/59414] [4.8/4.9 Regression] [OOP] ICE in in gfc_conv_expr_descriptor on ALLOCATE inside SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #13 from Paul Thomas pault at gcc dot gnu.org --- Created attachment 31894 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31894action=edit Patch for the PR This patch bootstraps and regtests on trunk. The resulting behaviour is identical to ifort. I'll submit tomorrow or Tuesday. Cheers Paul
[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881 --- Comment #2 from Jürgen Reuter juergen.reuter at desy dot de --- Created attachment 31895 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31895action=edit bit smaller test case This is a bit smaller test case. The main program is basically a call, and one module has been eliminated. Also, no input file is needed any more. The module ifile defines internal files used for carrying information, lexer.f90 defines the lexer, parser.f90 the parser, syntax_rules.f90 the corresponding syntax_rules. The scan command now only has one line which triggers the problems.
[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- When the executable is run under valgrind I see a lot of ==981== Invalid write of size 8 ==981==at 0x100020B99: __parser_MOD_token_assign_real (in ./seg_prod) ==981==by 0x10001ED21: __parser_MOD_parse_node_set_value (in ./seg_prod) ==981==by 0x100058249: __commands_MOD_range_real_set_value (in ./seg_prod) ==981==by 0x1000543C2: __commands_MOD_cmd_scan_execute (in ./seg_prod) ==981==by 0x100053EC9: __commands_MOD_command_list_execute (in ./seg_prod) ==981==by 0x10005E495: __whizard_MOD_whizard_process_stream (in ./seg_prod) ==981==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in ./seg_prod) ==981==by 0x10006191E: MAIN__ (in ./seg_prod) ==981==by 0x10006204E: main (in ./seg_prod) ==981== Address 0x100f0400d is 829 bytes inside a block of size 1,024 free'd ==981==at 0x10009252D: free (vg_replace_malloc.c:430) ==981==by 0x1A624: __iso_varying_string_MOD_op_eq_vs_vs (in ./seg_prod) ==981==by 0x10002830D: __variables_MOD_var_list_get_var_ptr (in ./seg_prod) ==981==by 0x10002839D: __variables_MOD_var_list_get_var_ptr (in ./seg_prod) ==981==by 0x100024DE2: __variables_MOD_var_list_check_user_var (in ./seg_prod) ==981==by 0x10005C9E0: __commands_MOD_cmd_var_compile (in ./seg_prod) ==981==by 0x100053F86: __commands_MOD_command_list_compile (in ./seg_prod) ==981==by 0x10005B43E: __commands_MOD_build_alt_setup (in ./seg_prod) ==981==by 0x10005450A: __commands_MOD_cmd_scan_execute (in ./seg_prod) ==981==by 0x100053EC9: __commands_MOD_command_list_execute (in ./seg_prod) ==981==by 0x10005E495: __whizard_MOD_whizard_process_stream (in ./seg_prod) ==981==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in ./seg_prod) when compiled with r194897 (2013-01-04). These invalid write/read disappear with r195140 (2013-01-14). However I see a lot leak ... =65053== 40,519 (7,344 direct, 33,175 indirect) bytes in 51 blocks are definitely lost in loss record 126 of 128 ==65053==at 0x100092679: malloc (vg_replace_malloc.c:266) ==65053==by 0x10001E6F0: __parser_MOD_parse_node_replace_last_sub (in ./seg_prod) ==65053==by 0x100057270: __commands_MOD_cmd_scan_compile (in ./seg_prod) ==65053==by 0x100053F5E: __commands_MOD_command_list_compile (in ./seg_prod) ==65053==by 0x10005E465: __whizard_MOD_whizard_process_stream (in ./seg_prod) ==65053==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in ./seg_prod) ==65053==by 0x10006191E: MAIN__ (in ./seg_prod) ==65053==by 0x10006204E: main (in ./seg_prod) ==65053== ==65053== 54,812 (8,432 direct, 46,380 indirect) bytes in 28 blocks are definitely lost in loss record 127 of 128 ==65053==at 0x100092679: malloc (vg_replace_malloc.c:266) ==65053==by 0x100056A16: __commands_MOD_cmd_scan_compile (in ./seg_prod) ==65053==by 0x100053F5E: __commands_MOD_command_list_compile (in ./seg_prod) ==65053==by 0x10005E465: __whizard_MOD_whizard_process_stream (in ./seg_prod) ==65053==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in ./seg_prod) ==65053==by 0x10006191E: MAIN__ (in ./seg_prod) ==65053==by 0x10006204E: main (in ./seg_prod) ==65053== ==65053== 218,271 (144 direct, 218,127 indirect) bytes in 1 blocks are definitely lost in loss record 128 of 128 ==65053==at 0x100092679: malloc (vg_replace_malloc.c:266) ==65053==by 0x10001EBC3: __parser_MOD_parse_node_create_branch (in ./seg_prod) ==65053==by 0x10001D271: parse_sequence.2386 (in ./seg_prod) ==65053==by 0x10001DD29: parse_node_match_rule.2402 (in ./seg_prod) ==65053==by 0x10001CD3B: __parser_MOD_parse_tree_init (in ./seg_prod) ==65053==by 0x10005E3FD: __whizard_MOD_whizard_process_stream (in ./seg_prod) ==65053==by 0x10005EB3B: __whizard_MOD_whizard_process_stdin (in ./seg_prod) ==65053==by 0x10006191E: MAIN__ (in ./seg_prod) ==65053==by 0x10006204E: main (in ./seg_prod) ==65053== ==65053== LEAK SUMMARY: ==65053==definitely lost: 79,291 bytes in 763 blocks ==65053==indirectly lost: 330,636 bytes in 3,687 blocks ==65053== possibly lost: 0 bytes in 0 blocks ==65053==still reachable: 556 bytes in 12 blocks ==65053== suppressed: 88 bytes in 1 blocks ==65053== ==65053== For counts of detected and suppressed errors, rerun with: -v ==65053== ERROR SUMMARY: 19 errors from 19 contexts (suppressed: 0 from 0) Note that on trunk I also get a lot of invalid write/read (114).
[Bug rtl-optimization/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jakub Jelinek from comment #7) Sure, will do. Thought about that as well, just didn't change it before attaching ;) Please use long long and target ! ia32 on testcase so that it will be tested for x32.
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 --- Comment #8 from David Binderman dcb314 at hotmail dot com --- (In reply to Richard Biener from comment #7) Fixed. The results I can report are for trunk dated 20130119 [dcb@zippy4 foundBugs]$ time ../results/bin/gcc -c bug129.cc real0m8.076s user0m5.925s sys0m0.131s [dcb@zippy4 foundBugs]$ time ../results/bin/gcc -c -O2 bug129.cc real1m0.706s user0m57.884s sys0m0.402s [dcb@zippy4 foundBugs]$ time ../results/bin/gcc -c -O3 bug129.cc real5m45.982s user5m42.793s sys0m0.457s while the first time is trivial, the -O2 time is down by about 60% and the -O3 time is down by about 30%. Good work !
[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org --- Just a bit shorter (without unstable_t type): module decays implicit none type :: decay_term_t type(decay_t), pointer :: unstable_product end type type :: decay_gen_t type(decay_term_t), allocatable :: term procedure(), nopass, pointer :: obs1_int end type type :: rng_t end type type, extends (decay_gen_t) :: decay_t class(rng_t), allocatable :: rng end type class(decay_t), pointer :: object end
[Bug other/59882] dev-cpp/xsd: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59882 --- Comment #1 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 31896 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31896action=edit C-reduced test case - first run
[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Jan 19 23:17:43 2014 New Revision: 206785 URL: http://gcc.gnu.org/viewcvs?rev=206785root=gccview=rev Log: 2014-01-19 Jerry DeLisle jvdeli...@gcc.gnu Dominique d'Humieres domi...@lps.ens.fr PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * io/write_float.def (output_float): Fix wrong handling of the Fw.0 format. (output_float_FMT_G_): Fixes rounding issues with -m32. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #14 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Jan 19 23:17:43 2014 New Revision: 206785 URL: http://gcc.gnu.org/viewcvs?rev=206785root=gccview=rev Log: 2014-01-19 Jerry DeLisle jvdeli...@gcc.gnu Dominique d'Humieres domi...@lps.ens.fr PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * io/write_float.def (output_float): Fix wrong handling of the Fw.0 format. (output_float_FMT_G_): Fixes rounding issues with -m32. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug libfortran/59771] Cleanup handling of Gw.0 and Gw.0Ee format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Jan 19 23:17:43 2014 New Revision: 206785 URL: http://gcc.gnu.org/viewcvs?rev=206785root=gccview=rev Log: 2014-01-19 Jerry DeLisle jvdeli...@gcc.gnu Dominique d'Humieres domi...@lps.ens.fr PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * io/write_float.def (output_float): Fix wrong handling of the Fw.0 format. (output_float_FMT_G_): Fixes rounding issues with -m32. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #15 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Jan 19 23:21:10 2014 New Revision: 206786 URL: http://gcc.gnu.org/viewcvs?rev=206786root=gccview=rev Log: 2014-01-19 Steven G. Kargl ka...@gcc.gnu.org PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * gfortran.dg/round_3.f08: New cases added. * gfortran.dg/fmt_g_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_g_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/round_3.f08
[Bug libfortran/59771] Cleanup handling of Gw.0 and Gw.0Ee format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Jan 19 23:21:10 2014 New Revision: 206786 URL: http://gcc.gnu.org/viewcvs?rev=206786root=gccview=rev Log: 2014-01-19 Steven G. Kargl ka...@gcc.gnu.org PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * gfortran.dg/round_3.f08: New cases added. * gfortran.dg/fmt_g_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_g_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/round_3.f08
[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Jan 19 23:21:10 2014 New Revision: 206786 URL: http://gcc.gnu.org/viewcvs?rev=206786root=gccview=rev Log: 2014-01-19 Steven G. Kargl ka...@gcc.gnu.org PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * gfortran.dg/round_3.f08: New cases added. * gfortran.dg/fmt_g_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_g_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/round_3.f08
[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 --- Comment #8 from Wesley J. Landaker wjl at icecavern dot net --- Just as an additional point, L'\u' also yields a wchar_t with the value of 1. (If that is an illegal construct, it is not warned about when using -Wall -Wextra -Werror).
[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 --- Comment #9 from Wesley J. Landaker wjl at icecavern dot net --- This also happens in strings, e.g.: static_assert(U\u[0] == 1, this passes); static_assert(U\u[0] == 0, this fails);
[Bug other/59882] dev-cpp/xsd: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59882
--- Comment #2 from David Kredba nheghathivhistha at gmail dot com ---
c-reduce at --sllooww
namespace std
{
template class, class struct pair;
template typename _Iterator struct iterator_traits
{
typedef typename _Iterator::value_type value_type;
};
template typename class allocator
{
public:
template typename struct rebind
{
typedef allocator other;
};
};
template typename struct less
{
};
template typename struct _Select1st;
}
namespace __gnu_cxx
{
template typename _Alloc struct __alloc_traits
{
template typename _Tp struct rebind
{
typedef typename _Alloc::template rebind _Tp ::other other;
};
};
}
namespace std
{
template typename struct _Rb_tree_node;
template typename, typename _Val, typename, typename _Compare,
typename _Alloc = allocator _Val class _Rb_tree
{
typedef typename __gnu_cxx::__alloc_traits _Alloc ::template rebind
_Rb_tree_node _Val ::other _Node_allocator;
typedef _Alloc allocator_type;
template typename _Key_compare struct _Rb_tree_impl
{
_Rb_tree_impl (_Key_compare, _Node_allocator);
};
_Rb_tree_impl _Compare _M_impl;
public:
_Rb_tree (_Compare __comp, allocator_type __a):_M_impl (__comp,
__a)
{
}
};
template typename _Key, typename _Tp, typename _Compare =
less _Key , typename _Alloc =
allocator pair _Key, _Tp class map
{
public:
typedef _Key key_type;
typedef pair _Key, _Tp value_type;
typedef _Compare key_compare;
typedef _Alloc allocator_type;
typedef _Rb_tree key_type, value_type, _Select1st value_type ,
key_compare _Rep_type;
_Rep_type _M_t;
map (_Compare __comp, allocator_type __a = allocator_type ()):_M_t (__comp,
__a)
{
}
};
template typename _Tp struct _List_iterator
{
typedef _Tp value_type;
};
template typename _Tp class list
{
public:
typedef _List_iterator _Tp iterator;
};
}
namespace Cult
{
namespace Types
{
namespace Fundamental
{
typedef void Void;
typedef int WideChar;
} using Fundamental::Void;
using Fundamental::WideChar;
} namespace
{
template typename I class IteratorAdapter
{
public:
typedef typename std::iterator_traits
I ::value_type Value;
};
} namespace Types
{
template typename class StringTemplate;
typedef StringTemplate WideChar WideString;
} namespace Containers
{
template typename K, typename T class Map:std::map K, T
{
typedef std::map K, T Base;
typedef typename Base::key_compare Compare;
public:
Map (Compare comp = Compare ()):Base (comp)
{
}
};
template typename T class List
{
typedef std::list T Base;
public:
typedef IteratorAdapter typename Base::iterator
Iterator;
};
}
}
namespace
{
using namespace Cult::Types;
}
namespace XSDFrontend
{
namespace SemanticGraph
{
namespace Bits
{
template typename struct strip_pointer;
template typename X struct strip_pointer X *
{
typedef X Type;
};
template typename I struct PointerIterator
{
typedef typename strip_pointer typename I::Value ::Type Reference;
Reference operator* ();
};
} class Edge
{
};
class Node;
class Names:public Edge
{
};
class Scope
{
typedef Cult::Containers::List Names * NamesList;
public:
typedef Bits::PointerIterator NamesList::Iterator
NamesIterator;
};
class Type;
class Complex:public Scope
{
};
}
}
namespace FrontendElements
{
namespace Traversal
{
template typename class TraverserBase
{
};
template typename X class DispatcherBase
{
public:
virtual Void dispatch (X);
};
template typename X class Dispatcher:public DispatcherBase X
{
};
}
}
namespace XSDFrontend
{
namespace Traversal
{
namespace Bits
{
using FrontendElements::Traversal::TraverserBase;
using FrontendElements::Traversal::DispatcherBase;
using FrontendElements::Traversal::Dispatcher;
} typedef Bits::DispatcherBase SemanticGraph::Edge EdgeDispatcherBase;
struct EdgeBase:virtual Bits::Dispatcher SemanticGraph::Edge ,
Bits::Dispatcher SemanticGraph::Node
{
};
template typename struct Edge:Bits::TraverserBase
SemanticGraph::Edge , EdgeBase
{
};
struct Names:Edge Names
{
};
template typename T struct ScopeTemplate
{
template typename Void names (T, EdgeDispatcherBase d)
{
typename T::NamesIterator b;
d.dispatch (*b);
} Void names (T s, EdgeDispatcherBase d)
{
names ScopeTemplate (s, d);
}
};
struct Complex:ScopeTemplate SemanticGraph::Complex
{
};
} typedef WideString String;
class Context
{
};
namespace Parser
{
namespace
{
typedef Cult::Containers::Map SemanticGraph::Type,
String TypeInstanceMap;
struct BaseType
{
BaseType (Context);
};
struct ArgList:Traversal::Complex
{
ArgList (Context, TypeInstanceMap)
{
} virtual Void traverse (SemanticGraph::Complex c)
{
names (c, names_);
} TypeInstanceMap map_;
[Bug other/36150] colorize output of gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150 bluetooth.developer at gmail dot com changed: What|Removed |Added CC||bluetooth.developer at gmail dot c ||om --- Comment #17 from bluetooth.developer at gmail dot com --- Alternatively you could use GilCC which is a tool to colorize GCC output in real time. Just in case you cannot use GGC version 4.9 you still can use GilCC. here is the download link: http://www.onlysolutionssoftware.com/gilcc/
[Bug c/59884] New: Unexpected warning pragma GCC target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884
Bug ID: 59884
Summary: Unexpected warning pragma GCC target
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: joey.ye at arm dot com
Affected target: arm. (x86/x86_64 passes)
Affected version: trunk 20140109, 4.8, 4.7
~/cases/pragma $ cat p.c
#pragma GCC push_options
#pragma GCC optimize(O2)
int foo(int a){
return a+1;
}
#pragma GCC pop_options
~/cases/pragma $ arm-none-eabi-gcc p.c -c
p.c:6:9: warning: #pragma GCC target is not supported for this machine
[-Wpragmas]
#pragma GCC pop_options
[Bug target/59884] Unexpected warning pragma GCC target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Component|c |target
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
Comes from:
if (p-target_binary != target_option_current_node)
{
(void) targetm.target_option.pragma_parse (NULL_TREE, p-target_binary);
target_option_current_node = p-target_binary;
}
The front-end expects the target always to implement these target hooks it
seems rather than the default.
Really I think the arm back-end should implement them so that thumb2 code can
be in the same source file as arm32 code and would help out LTO when people mix
and match them.
[Bug target/59884] Unexpected warning pragma GCC target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884
--- Comment #2 from Joey Ye joey.ye at arm dot com ---
(In reply to Andrew Pinski from comment #1)
Comes from:
if (p-target_binary != target_option_current_node)
{
(void) targetm.target_option.pragma_parse (NULL_TREE,
p-target_binary);
target_option_current_node = p-target_binary;
}
The front-end expects the target always to implement these target hooks it
seems rather than the default.
Really I think the arm back-end should implement them so that thumb2 code
can be in the same source file as arm32 code and would help out LTO when
people mix and match them.
It is a useful feature on ARM. I don't know why it isn't support now.
But this warning still need to be fixed as there are always some targets not
supportting this pragma.
[Bug ipa/59882] [4.9 Regression] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59882
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||ice-on-valid-code
Last reconfirmed||2014-01-20
Component|other |ipa
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
Summary|dev-cpp/xsd: internal |[4.9 Regression] internal
|compiler error: |compiler error:
|Segmentation fault |Segmentation fault
Target Milestone|--- |4.9.0
--- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Confirmed. Another devirtualization issue.
markus@x4 tmp % cat test.ii
class A;
class B {};
struct C {
virtual void dispatch();
int traversal_map_;
};
template typename class F : public virtual C {};
struct I : FA, Fint {};
struct J : B, I {};
class D {};
struct L {
L(D , int p2) : map_(p2) {}
virtual void traverse(int p1) {
int s = p1;
namesL(s, names_);
}
int map_;
J names_;
template typename void names(int , C p2) { p2.dispatch(); }
};
struct G : D {
G(D , int p2) : map_(p2) { L(*this, map_); }
int map_;
};
int a;
void fn1(D p1) { G(p1, a); }
markus@x4 tmp % g++ -c -O2 test.ii
test.ii: In member function ‘virtual void L::traverse(int)’:
test.ii:29:29: internal compiler error: Segmentation fault
void fn1(D p1) { G(p1, a); }
^
0xb541af crash_signal
../../gcc/gcc/toplev.c:337
0x98e5eb tree_check
../../gcc/gcc/tree.h:2708
0x98e5eb gimple_get_virt_method_for_binfo(long, tree_node*)
../../gcc/gcc/gimple-fold.c:3242
0x9d35a9 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**)
../../gcc/gcc/ipa-devirt.c:1312
0x9902ab possible_polymorphic_call_targets(tree_node*, bool*, void**)
../../gcc/gcc/ipa-utils.h:135
0x98d4a6 gimple_fold_call
../../gcc/gcc/gimple-fold.c:1185
0x98d4a6 fold_stmt_1
../../gcc/gcc/gimple-fold.c:1298
0xbaacb9 fold_marked_statements
../../gcc/gcc/tree-inline.c:4511
0xbb8374 optimize_inline_calls(tree_node*)
../../gcc/gcc/tree-inline.c:4592
0x1058409 early_inliner
../../gcc/gcc/ipa-inline.c:2272
0x1058409 execute
../../gcc/gcc/ipa-inline.c:2335
Please submit a full bug report,
[Bug lto/55113] ICE with LTO and -fshort-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Summary|ICE in |ICE with LTO and |emit_library_call_value_1, |-fshort-double |at calls.c:3757 | --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- -fshort-double is what is causing the issue. Why are you using that option in the first place? It changes the ABI. With 4.7.0 (and checking enabled), I get the following ICE on all targets with -flto -fshort-double -Os: t7.c: In function ‘main’: t7.c:3:5: error: non-trivial conversion at assignment float double # .MEM_2 = VDEF .MEM_1(D) f = 1.0e+0;
[Bug target/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Component|rtl-optimization|target Target Milestone|--- |4.7.4 Severity|enhancement |normal
[Bug target/58945] Improve atomic_compare_and_swap*_doubleword pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58945 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED
Re: Fix compute_reloc_for_constant
On 19 January 2014 03:12:56 Jan Hubicka hubi...@ucw.cz wrote: Hi, while comparing LTO and non-LTO builds I noticed that with LTO we produce a lot more vtables in datal.rel.ro rather than data.rel.ro.local This is because of partitioning promoting more symbols global. For RTL we make section decisions based on SYMBOL_REF_LOCAL_FLAG that is set based on decl_binds_local_p. For variables we use TREE_PUBLIC check that is overly conservative. Honza, Would you (or anybody else for that matter) mind looking into PR32219 while there? See http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00665.html and other discussion of that bug on the ML last year. TIA, Bernhard Bootstrapped/regtested x86_64-linux, OK? * varasm.c (compute_reloc_for_constant): Use targetm.binds_local_p instead of TREE_PUBLIC to determine if reference will be local within given DSO or not. Index: varasm.c === --- varasm.c(revision 206684) +++ varasm.c(working copy) @@ -4060,7 +4060,7 @@ break; } - if (TREE_PUBLIC (tem)) + if (!targetm.binds_local_p (tem)) reloc |= 2; else reloc |= 1; Sent with AquaMail for Android http://www.aqua-mail.com
[PATCH] libgcc: use linker script for libgcc_s.so on xtensa
The xtensa port uses __xtensa_libgcc_window_spill in libgcc to implement __builtin_frame_address. This symbol is local/hidden in libgcc. This is not a problem when linking against static libgcc. But g++ defaults to -shared-libgcc, thus breaking link against C++ shared libraries that are using __builtin_frame_address as follows: ld: test: hidden symbol `__xtensa_libgcc_window_spill' in .../libgcc.a(lib2funcs.o) is referenced by DSO Make libgcc_s.so a linker script that links in unresolved symbols from the static libgcc, similar to the ARM and PowerPC ports. libgcc/ * config.host (tmake_file): add t-slibgcc-libgcc for xtensa*-*-linux*. --- libgcc/config.host | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config.host b/libgcc/config.host index 75a17e3..178f6d9 100644 --- a/libgcc/config.host +++ b/libgcc/config.host @@ -1181,7 +1181,7 @@ xtensa*-*-elf*) extra_parts=$extra_parts crti.o crtn.o ;; xtensa*-*-linux*) - tmake_file=$tmake_file xtensa/t-xtensa xtensa/t-linux + tmake_file=$tmake_file xtensa/t-xtensa xtensa/t-linux t-slibgcc-libgcc md_unwind_header=xtensa/linux-unwind.h ;; am33_2.0-*-linux*) -- 1.8.5.2
Re: PATCH: PR target/59379: [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
On Sat, Jan 18, 2014 at 9:15 PM, H.J. Lu hjl.to...@gmail.com wrote: For LEA operation with SImode_address_operand, which zero-extends SImode to DImode, ix86_split_lea_for_addr turns (set (reg:DI) ...) into (set (reg:SI) ...) We need to do (set (reg:DI) (zero_extend:DI (reg:SI))) at the end. If the LEA operation is (set (reg:DI) (zero_extend:DI (reg:SI))) ree pass should remove these. However, we can just emit zero-extend insn at the end of sequence, and ree (which is located after post-reload split) should handle it: --cut here-- Index: config/i386/i386.md === --- config/i386/i386.md (revision 206753) +++ config/i386/i386.md (working copy) @@ -5428,12 +5428,17 @@ operands[0] = SET_DEST (pat); operands[1] = SET_SRC (pat); - /* Emit all operations in SImode for zero-extended addresses. Recall - that x86_64 inheretly zero-extends SImode operations to DImode. */ + /* Emit all operations in SImode for zero-extended addresses. */ if (SImode_address_operand (operands[1], VOIDmode)) mode = SImode; ix86_split_lea_for_addr (curr_insn, operands, mode); + + /* Zero-extend return register to DImode for zero-extended addresses. */ + if (mode != MODEmode) +emit_insn (gen_zero_extendsidi2 + (operands[0], gen_lowpart ((mode), operands[0]))); + DONE; } [(set_attr type lea) --cut here-- The patch was tested with a testcase from Comment #9 of the PR using -O --march=corei7 -mtune=slm, and resulting binary runs without problems. Uros.
[committed] Fix vect_intness in a few tests
One test tests for integer vectorisation so requires vect_int. Two others
already had the dg-require-effective-target, but it was before the dg-do
rather than after.
Tested on mips64-linux-gnu, where it fixes the vect.exp failures.
Applied as obvious.
Thanks,
Richard
gcc/testsuite/
* gcc.dg/vect/pr57705.c: Require vect_int.
* gcc.dg/vect/pr58508.c: Fix order of dg-require-effective-target line.
* gcc.dg/vect/vect-alias-check.c: Likewise.
Index: gcc/testsuite/gcc.dg/vect/pr57705.c
===
--- gcc/testsuite/gcc.dg/vect/pr57705.c 2014-01-19 09:52:07.761437971 +
+++ gcc/testsuite/gcc.dg/vect/pr57705.c 2014-01-19 09:52:07.973439322 +
@@ -1,4 +1,5 @@
/* { dg-do run } */
+/* { dg-require-effective-target vect_int } */
#include tree-vect.h
Index: gcc/testsuite/gcc.dg/vect/pr58508.c
===
--- gcc/testsuite/gcc.dg/vect/pr58508.c 2014-01-19 09:52:07.776438067 +
+++ gcc/testsuite/gcc.dg/vect/pr58508.c 2014-01-19 09:52:07.973439322 +
@@ -1,5 +1,5 @@
-/* { dg-require-effective-target vect_int } */
/* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
/* The GCC vectorizer generates loop versioning for the following loop
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check.c
===
--- gcc/testsuite/gcc.dg/vect/vect-alias-check.c2014-01-19
09:52:07.776438067 +
+++ gcc/testsuite/gcc.dg/vect/vect-alias-check.c2014-01-19
09:52:07.974439329 +
@@ -1,5 +1,5 @@
-/* { dg-require-effective-target vect_int } */
/* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
/* { dg-additional-options --param=vect-max-version-for-alias-checks=2 } */
/* A test case showing four potential alias checks between a[i] and b[0], b[1],
Re: [Patch] Fix regex multiple consecutive quantifiers bug.
Hi, On 01/19/2014 06:52 AM, Tim Shen wrote: Regex like a** will throw an unexpected exception. Now fixed (but currently no optimizations on it). Booted and tested with -m64 and -m32 respectively. Ok. Please remove 2013 as copyright year for the tescase. I also think you can avoid the auxiliary includes. Thanks! Paolo.
Re: Fix compute_reloc_for_constant
On Sun, Jan 19, 2014 at 3:12 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi, while comparing LTO and non-LTO builds I noticed that with LTO we produce a lot more vtables in datal.rel.ro rather than data.rel.ro.local This is because of partitioning promoting more symbols global. For RTL we make section decisions based on SYMBOL_REF_LOCAL_FLAG that is set based on decl_binds_local_p. For variables we use TREE_PUBLIC check that is overly conservative. Bootstrapped/regtested x86_64-linux, OK? Ok. Thanks, Richard. * varasm.c (compute_reloc_for_constant): Use targetm.binds_local_p instead of TREE_PUBLIC to determine if reference will be local within given DSO or not. Index: varasm.c === --- varasm.c(revision 206684) +++ varasm.c(working copy) @@ -4060,7 +4060,7 @@ break; } - if (TREE_PUBLIC (tem)) + if (!targetm.binds_local_p (tem)) reloc |= 2; else reloc |= 1;
Re: PATCH: PR target/59379: [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
On Sun, Jan 19, 2014 at 1:55 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sat, Jan 18, 2014 at 9:15 PM, H.J. Lu hjl.to...@gmail.com wrote:
For LEA operation with SImode_address_operand, which zero-extends SImode
to DImode, ix86_split_lea_for_addr turns
(set (reg:DI) ...)
into
(set (reg:SI) ...)
We need to do
(set (reg:DI) (zero_extend:DI (reg:SI)))
at the end. If the LEA operation is
(set (reg:DI) (zero_extend:DI (reg:SI)))
ree pass should remove these. However, we can just emit zero-extend
insn at the end of sequence, and ree (which is located after
post-reload split) should handle it:
--cut here--
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 206753)
+++ config/i386/i386.md (working copy)
@@ -5428,12 +5428,17 @@
operands[0] = SET_DEST (pat);
operands[1] = SET_SRC (pat);
- /* Emit all operations in SImode for zero-extended addresses. Recall
- that x86_64 inheretly zero-extends SImode operations to DImode. */
+ /* Emit all operations in SImode for zero-extended addresses. */
if (SImode_address_operand (operands[1], VOIDmode))
mode = SImode;
ix86_split_lea_for_addr (curr_insn, operands, mode);
+
+ /* Zero-extend return register to DImode for zero-extended addresses. */
+ if (mode != MODEmode)
+emit_insn (gen_zero_extendsidi2
+ (operands[0], gen_lowpart ((mode), operands[0])));
+
DONE;
}
[(set_attr type lea)
--cut here--
The patch was tested with a testcase from Comment #9 of the PR using
-O --march=corei7 -mtune=slm, and resulting binary runs without
problems.
Yes, the resulting GCC works correctly. However, we generate
extra
(set (reg:DI) (zero_extend:DI (reg:SI)))
It is because we generate
(set (reg:SI) (reg:SI)
(set (reg:DI) (zero_extend:DI (reg:SI)))
REE pass doesn't know
(set (reg:SI) (reg:SI)
has an implicit ZERO_EXTEND. Here is a testcase:
---foo.c---
extern __thread unsigned int __bid_IDEC_glbflags;
typedef unsigned long long UINT64;
typedef __attribute__ ((aligned(16))) struct
{
UINT64 w[2];
} UINT128;
extern UINT64 __bid64_from_uint64 (UINT64);
extern void __bid_round64_2_18 (int q,
int x,
UINT64 C,
UINT64 * ptr_Cstar,
int *delta_exp,
int *ptr_is_midpoint_lt_even,
int *ptr_is_midpoint_gt_even,
int *ptr_is_inexact_lt_midpoint,
int *ptr_is_inexact_gt_midpoint);
extern void __bid_round128_19_38 (int q,
int x,
UINT128 C,
UINT128 * ptr_Cstar,
int *delta_exp,
int *ptr_is_midpoint_lt_even,
int *ptr_is_midpoint_gt_even,
int *ptr_is_inexact_lt_midpoint,
int *ptr_is_inexact_gt_midpoint);
UINT64
__bid64_from_uint64 (UINT64 x)
{
UINT64 res;
UINT128 x128, res128;
unsigned int q, ind;
int incr_exp = 0;
int is_midpoint_lt_even = 0, is_midpoint_gt_even = 0;
int is_inexact_lt_midpoint = 0, is_inexact_gt_midpoint = 0;
if (x = 0x002386F26FC0ull) {
if (x 0x0020ull) {
res = 0x31c0ull | x;
} else {
res = 0x6c70ull | (x 0x0007ull);
}
}
else
{
if (x 0x16345785d8aull) {
q = 17;
ind = 1;
} else if (x 0xde0b6b3a764ull) {
q = 18;
ind = 2;
} else if (x 0x8ac7230489e8ull) {
q = 19;
ind = 3;
} else {
q = 20;
ind = 4;
}
if (q = 19) {
__bid_round64_2_18 (
q, ind, x, res, incr_exp,
is_midpoint_lt_even, is_midpoint_gt_even,
is_inexact_lt_midpoint, is_inexact_gt_midpoint);
}
else {
x128.w[1] = 0x0;
x128.w[0] = x;
__bid_round128_19_38 (q, ind, x128, res128, incr_exp,
is_midpoint_lt_even, is_midpoint_gt_even,
is_inexact_lt_midpoint, is_inexact_gt_midpoint);
res = res128.w[0];
}
if (incr_exp)
ind++;
if (is_inexact_lt_midpoint || is_inexact_gt_midpoint ||
is_midpoint_lt_even || is_midpoint_gt_even)
*__bid_IDEC_glbflags |= 0x0020;
if (res 0x0020ull) {
res = (((UINT64) ind + 398) 53) | res;
} else
{
res = 0x6000ull | (((UINT64) ind + 398) 51) |
(res 0x0007ull);
}
}
return(res);;
}
---
Compiling with -fPIC -O2, the differences between your patch and mine
are
--- bad.s 2014-01-19 06:10:28.006570325 -0800
+++ foo.s 2014-01-19 06:11:46.117754696 -0800
@@ -84,19 +84,18 @@ __bid64_from_uint64:
movabsq $9007199254740991, %rax
cmpq %rax, %rbx
jbe .L23
- movl %ebp, %edx
leaq 88(%rsp), %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
movabsq $2251799813685247, %rax
- movl %edx, %edx
+ movl %ebp, %edx
andq %rbx, %rax
- movabsq $6917529027641081856, %rcx
popq %rbx
.cfi_def_cfa_offset 16
+ movabsq $6917529027641081856, %rcx
addq $398, %rdx
- orq %rcx, %rax
salq $51, %rdx
+ orq %rcx, %rax
popq %rbp
.cfi_def_cfa_offset 8
orq %rdx, %rax
@@ -154,7 +153,6 @@ __bid64_from_uint64:
leaq 88(%rsp), %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
- movl %eax, %eax
addq $398, %rax
salq $53, %rax
orq %rbx, %rax
My patch removes 2 extra
(set
[Patch, libgfortran] PR59771, PR59774, and PR59836 Bugs in FORMATs Fw.0, Gw.0, and Gw.d
The attached patch fixes these bugs and adds the tests. See the PRs for = the rationale of the changes. Regression tested on x86_64-apple-darwin13 and powerpc-apple-darwin9. OK for trunk, 4.8.3, and 4.7.4 (after testing)? Regards, Dominique CL Description: Binary data patch-59774t Description: Binary data
Re: PATCH: PR target/59379: [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
On Sun, Jan 19, 2014 at 3:20 PM, H.J. Lu hjl.to...@gmail.com wrote: For LEA operation with SImode_address_operand, which zero-extends SImode to DImode, ix86_split_lea_for_addr turns (set (reg:DI) ...) into (set (reg:SI) ...) We need to do (set (reg:DI) (zero_extend:DI (reg:SI))) at the end. If the LEA operation is (set (reg:DI) (zero_extend:DI (reg:SI))) ree pass should remove these. However, we can just emit zero-extend insn at the end of sequence, and ree (which is located after post-reload split) should handle it: --cut here-- Index: config/i386/i386.md === --- config/i386/i386.md (revision 206753) +++ config/i386/i386.md (working copy) @@ -5428,12 +5428,17 @@ operands[0] = SET_DEST (pat); operands[1] = SET_SRC (pat); - /* Emit all operations in SImode for zero-extended addresses. Recall - that x86_64 inheretly zero-extends SImode operations to DImode. */ + /* Emit all operations in SImode for zero-extended addresses. */ if (SImode_address_operand (operands[1], VOIDmode)) mode = SImode; ix86_split_lea_for_addr (curr_insn, operands, mode); + + /* Zero-extend return register to DImode for zero-extended addresses. */ + if (mode != MODEmode) +emit_insn (gen_zero_extendsidi2 + (operands[0], gen_lowpart ((mode), operands[0]))); + DONE; } [(set_attr type lea) --cut here-- The patch was tested with a testcase from Comment #9 of the PR using -O --march=corei7 -mtune=slm, and resulting binary runs without problems. Yes, the resulting GCC works correctly. However, we generate extra (set (reg:DI) (zero_extend:DI (reg:SI))) It is because we generate (set (reg:SI) (reg:SI) (set (reg:DI) (zero_extend:DI (reg:SI))) REE pass doesn't know (set (reg:SI) (reg:SI) has an implicit ZERO_EXTEND. Here is a testcase: This is the correct sequence,and REE pass should be improved to handle this situation. Note, that the problem was that we assumed SImode operations (including move) have implicit DImode zero-extend, but in fact we haven't communicate this to the compiler in a proper way. So, I propose we go with my patch and file an enhancement PR for the REE pass. Uros.
Re: PATCH: PR target/59379: [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
On Sun, Jan 19, 2014 at 6:24 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sun, Jan 19, 2014 at 3:20 PM, H.J. Lu hjl.to...@gmail.com wrote: For LEA operation with SImode_address_operand, which zero-extends SImode to DImode, ix86_split_lea_for_addr turns (set (reg:DI) ...) into (set (reg:SI) ...) We need to do (set (reg:DI) (zero_extend:DI (reg:SI))) at the end. If the LEA operation is (set (reg:DI) (zero_extend:DI (reg:SI))) ree pass should remove these. However, we can just emit zero-extend insn at the end of sequence, and ree (which is located after post-reload split) should handle it: --cut here-- Index: config/i386/i386.md === --- config/i386/i386.md (revision 206753) +++ config/i386/i386.md (working copy) @@ -5428,12 +5428,17 @@ operands[0] = SET_DEST (pat); operands[1] = SET_SRC (pat); - /* Emit all operations in SImode for zero-extended addresses. Recall - that x86_64 inheretly zero-extends SImode operations to DImode. */ + /* Emit all operations in SImode for zero-extended addresses. */ if (SImode_address_operand (operands[1], VOIDmode)) mode = SImode; ix86_split_lea_for_addr (curr_insn, operands, mode); + + /* Zero-extend return register to DImode for zero-extended addresses. */ + if (mode != MODEmode) +emit_insn (gen_zero_extendsidi2 + (operands[0], gen_lowpart ((mode), operands[0]))); + DONE; } [(set_attr type lea) --cut here-- The patch was tested with a testcase from Comment #9 of the PR using -O --march=corei7 -mtune=slm, and resulting binary runs without problems. Yes, the resulting GCC works correctly. However, we generate extra (set (reg:DI) (zero_extend:DI (reg:SI))) It is because we generate (set (reg:SI) (reg:SI) (set (reg:DI) (zero_extend:DI (reg:SI))) REE pass doesn't know (set (reg:SI) (reg:SI) has an implicit ZERO_EXTEND. Here is a testcase: This is the correct sequence,and REE pass should be improved to handle this situation. Note, that the problem was that we assumed SImode operations (including move) have implicit DImode zero-extend, but in fact we haven't communicate this to the compiler in a proper way. So, I propose we go with my patch and file an enhancement PR for the REE pass. That is fine with me. Please install it on all affected branches and close the PR. I will open a new PR for REE pass. Thanks. -- H.J.
Re: PATCH: PR target/59379: [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
On Sun, Jan 19, 2014 at 3:30 PM, H.J. Lu hjl.to...@gmail.com wrote: For LEA operation with SImode_address_operand, which zero-extends SImode to DImode, ix86_split_lea_for_addr turns (set (reg:DI) ...) into (set (reg:SI) ...) We need to do (set (reg:DI) (zero_extend:DI (reg:SI))) at the end. If the LEA operation is (set (reg:DI) (zero_extend:DI (reg:SI))) ree pass should remove these. However, we can just emit zero-extend insn at the end of sequence, and ree (which is located after post-reload split) should handle it: --cut here-- Index: config/i386/i386.md === --- config/i386/i386.md (revision 206753) +++ config/i386/i386.md (working copy) @@ -5428,12 +5428,17 @@ operands[0] = SET_DEST (pat); operands[1] = SET_SRC (pat); - /* Emit all operations in SImode for zero-extended addresses. Recall - that x86_64 inheretly zero-extends SImode operations to DImode. */ + /* Emit all operations in SImode for zero-extended addresses. */ if (SImode_address_operand (operands[1], VOIDmode)) mode = SImode; ix86_split_lea_for_addr (curr_insn, operands, mode); + + /* Zero-extend return register to DImode for zero-extended addresses. */ + if (mode != MODEmode) +emit_insn (gen_zero_extendsidi2 + (operands[0], gen_lowpart ((mode), operands[0]))); + DONE; } [(set_attr type lea) --cut here-- The patch was tested with a testcase from Comment #9 of the PR using -O --march=corei7 -mtune=slm, and resulting binary runs without problems. Yes, the resulting GCC works correctly. However, we generate extra (set (reg:DI) (zero_extend:DI (reg:SI))) It is because we generate (set (reg:SI) (reg:SI) (set (reg:DI) (zero_extend:DI (reg:SI))) REE pass doesn't know (set (reg:SI) (reg:SI) has an implicit ZERO_EXTEND. Here is a testcase: This is the correct sequence,and REE pass should be improved to handle this situation. Note, that the problem was that we assumed SImode operations (including move) have implicit DImode zero-extend, but in fact we haven't communicate this to the compiler in a proper way. So, I propose we go with my patch and file an enhancement PR for the REE pass. That is fine with me. Please install it on all affected branches and close the PR. I will open a new PR for REE pass. Installed with following ChangeLog: 2014-01-18 Uros Bizjak ubiz...@gmail.com H.J. Lu hongjiu...@intel.com PR target/59379 * config/i386/i386.md (*leamode): Zero-extend return register to DImode for zero-extended addresses. Bootstrapped and regression tested on x86_64-pc-linux-gnu, will backport in a couple of days. Uros.
[MIPS, committed] Add -ffat-lto-objects to pr54240.c
Add -ffat-lto-objects to pr54240.c to fix an UNRESOLVED on the scan-tree-dump.
Tested on mips64-linux-gnu and applied.
There's a similar failure for octeon2-pipe-1.c but I'm going to fix that
in a different way.
Thanks,
Richard
gcc/testsuite/
* gcc.target/mips/pr54240.c: Add -ffat-lto-objects.
Index: gcc/testsuite/gcc.target/mips/pr54240.c
===
--- gcc/testsuite/gcc.target/mips/pr54240.c 2012-08-27 17:31:40.0
+0100
+++ gcc/testsuite/gcc.target/mips/pr54240.c 2014-01-19 10:22:21.167152052
+
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -fdump-tree-phiopt-details isa=4 } */
+/* { dg-options -fdump-tree-phiopt-details -ffat-lto-objects isa=4 } */
/* { dg-skip-if code quality test { *-*-* } { -O0 -O1 } { } } */
typedef struct s {
