Re: at exit alternative for AIX
On Aug 18, 2012, at 7:48 PM, Perry Smith wrote: Hi Gang, I'm having an unforeseen issue. Hopefully I'm just doing something wrong. I'm on gcc 4.5.2. I started with a fresh build tree. I'm passing in --enable-__cxa_atexit: configure \ --with-gmp=${PUBLIC_BASE} \ --with-mpfr=${PUBLIC_BASE} \ --with-mpc=${PUBLIC_BASE} \ --disable-nls \ --enable-threads=aix \ --with-libiconv-prefix=/usr \ --enable-__cxa_atexit \ --enable-languages=c,c++ Well... found where I'm going wrong... fgrep cxa_atexit ../../logs/gcc-4.5.2/Make | grep target __cxa_atexit can't be enabled on this target __cxa_atexit can't be enabled on this target __cxa_atexit can't be enabled on this target I guess I need to convince gcc/configure that I've added cxa_atexit
Re: at exit alternative for AIX
On Sat, Aug 18, 2012 at 5:48 PM, Perry Smith pedz...@gmail.com wrote: I'm on gcc 4.5.2. I started with a fresh build tree. I'm passing in --enable-__cxa_atexit: configure \ --with-gmp=${PUBLIC_BASE} \ --with-mpfr=${PUBLIC_BASE} \ --with-mpc=${PUBLIC_BASE} \ --disable-nls \ --enable-threads=aix \ --with-libiconv-prefix=/usr \ --enable-__cxa_atexit \ --enable-languages=c,c++ config.log confirms this: $ /usr/work/src/gcc-4.5.2/configure --prefix=/gsa/ausgsa/projects/r/ruby --with-gmp=/gsa/ausgsa/projects/r/ruby --with-mpfr=/gsa/ausgsa/projects/r/ruby --with-mpc=/gsa/ausgsa/projects/r/ruby --disable-nls --enable-threads=aix --with-libiconv-prefix=/usr --enable-__cxa_atexit --enable-languages=c,c++ But when I look at nm -Bx powerpc-ibm-aix6.1.0.0/pthread/libstdc++-v3/src/.libs/future.o There is still a reference to atexit. mt_allocator.o also has a reference to atexit. It is coming from the destructor. .line 60 bl .__cxa_guard_release nop lwz 3,LC..20(2) bl .atexit nop If I explicitly add the -fuse-cxa-atexit, then it uses cxa_atexit. I got the idea (perhaps mistaken) that the config time option flipped the default. Look closely at the output from gcc/configure. Does it include the line __cxa_atexit can't be enabled on this target? That will be displayed if the configure script determines that your target does not provide a __cxa_atexit function, and will override --enable-__cxa_atexit. Ian
Re: at exit alternative for AIX
On Sun, Aug 19, 2012 at 11:28 AM, Ian Lance Taylor i...@google.com wrote: Look closely at the output from gcc/configure. Does it include the line __cxa_atexit can't be enabled on this target? That will be displayed if the configure script determines that your target does not provide a __cxa_atexit function, and will override --enable-__cxa_atexit. Oh, sorry, I see that you figured that out. To fix it, look for the relevant string in gcc/configure.ac and add a special case as appropriate. Ian
Problem running the libgomp testsuite
Hello, I tried to run make check-c++ from the top directory of the source code. During the run, all of the libgomp tests run by it failed. From the log file, you can see that the gcc from the system (rather than the gcc currently built) was run: Executing on host: gcc -B/mnt/extras/src/gcc2/i686-pc-linux-gnu/libgomp/ -B/mnt/extras/src ... ... gcc: error: unrecognized command line option '-fno-diagnostics-show-caret' Other tests (like libstdc++) correctly use the currently built gcc: Executing on host: /mnt/extras/src/gcc2/host-i686-pc-linux-gnu/gcc/g++ -shared-libgcc ... ^^^ Any ideas how this could be fixed? Regards Jiri Palecek
gcc-4.8-20120819 is now available
Snapshot gcc-4.8-20120819 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120819/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 190518 You'll find: gcc-4.8-20120819.tar.bz2 Complete GCC MD5=632c7dddc6b701fb190e8da0a847140b SHA1=210e2af10e7b8d9c957f414861d69f36bfe2 Diffs from 4.8-20120812 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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.
internal compiler error in find_costs_and_classes
Hi, I did some iwmmxt intrinsic test for mainline gcc with this check-in r190511 | nickc | 2012-08-19 15:11:35 +0800 (Sun, 19 Aug 2012) | 3 lines PR target/54306 * config/arm/mmintrin.h: Remove spurious #endif. and encountered an internal compiler error for this simple case, with option -march=iwmmxt2 -S #includemmintrin.h __m64 foo(__m64 r, int i) { r = _mm_slli_si64(r, i); return r; } internal compiler error: in find_costs_and_classes, at ira-costs.c:1711 While with -O, compiling could pass. File a bug? Tnahks, Xinyu
[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306 --- Comment #1 from Nick Clifton nickc at redhat dot com 2012-08-19 07:10:01 UTC --- Created attachment 28049 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28049 Remove offending #endif
[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306 --- Comment #2 from Nick Clifton nickc at gcc dot gnu.org 2012-08-19 07:11:42 UTC --- Author: nickc Date: Sun Aug 19 07:11:35 2012 New Revision: 190511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190511 Log: PR target/54306 * config/arm/mmintrin.h: Remove spurious #endif. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/mmintrin.h
[Bug libstdc++/54320] New: [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 Bug #: 54320 Summary: [c++11] range access to VLA Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincenzo.innoce...@cern.ch is range access to VLA supported? I get compilation error for c++ -O3 -std=gnu++11 -c vla.cpp -DVLA with #includealgorithm #ifdef VLA int foo(int N) { int v[N]; auto a = std::begin(v); return *a; } #endif int bar() { int v[10]; auto a = std::begin(v); return *a; }
[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306 --- Comment #3 from Nick Clifton nickc at redhat dot com 2012-08-19 07:13:25 UTC --- Hi Daniel, Thanks for catching this. It was a snafu, corrected with the obvious fix you suggested. Cheers Nick
[Bug libstdc++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-19 07:17:04 UTC --- I don't think they can ever be as std::begin is defined as a template with one of the template arguments being the size of the array.
[Bug libstdc++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-19 07:18:25 UTC --- See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5435
[Bug libstdc++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 --- Comment #3 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-08-19 07:24:52 UTC --- int foo2(int N) { int v[N]; for ( auto a : v) if (a) return a; return 0; } works, though was similar to std::begin(v) std::end(v)
[Bug c++/54319] Assignment to rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-08-19 07:30:30 UTC --- Just for the record: This problem does no longer exist in gcc 4.8 (tested for 4.8.0 20120729 (experimental))
[Bug target/54246] Bytemark FOURIER 54% slower with glibc 2.16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54246 wbrana wbrana at gmail dot com changed: What|Removed |Added Summary|Bytemark FOURIER 54% slower |Bytemark FOURIER 54% slower |in X32 chroot |with glibc 2.16 --- Comment #2 from wbrana wbrana at gmail dot com 2012-08-19 08:20:06 UTC --- It isn't related to X32, but glibc 2.16. Bug submitted: http://sourceware.org/bugzilla/show_bug.cgi?id=14496
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-19 10:54:13 UTC --- Gcc cannot alter results of an SQL query, it's a bug in your program. This is the wrong place to get help debugging your code.
[Bug c/54321] New: ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 Bug #: 54321 Summary: ice in tree_low_cst at -O3 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 28050 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28050 C source code I just tried to compile the package fcron-3.0.6-5 on gcc-4.8 trunk dated 20120819 on an AMD x86_64 box. The compiler said fileconf.c: In function 'read_period': fileconf.c:1317:1: internal compiler error: in tree_low_cst, at tree.c:6546 read_period(char *ptr, cf_t *cf) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required.
[Bug c/54321] ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-08-19 11:08:45 UTC --- typedef struct { char cl_mins[0]; } cl_t; cl_t *a; void fn1 () { char *b = a-cl_mins; int c = 0; b[0] = 0; while (++c 9) b[c] = 255; }
[Bug libstdc++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 11:29:15 UTC --- Would be an extension requiring front-end support. I don't think we want it.
[Bug libstdc++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added Severity|normal |enhancement --- Comment #5 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-08-19 11:34:06 UTC --- a good candidate for c++17 then!
[Bug c++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org Component|libstdc++ |c++ --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 11:47:25 UTC --- In case we wanted to support this, it would essentially boil down to the C++ front-end bits introspecting the size. Let's ask Jason in CC, if it would make sense.
[Bug c++/54319] Assignment to rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|aschepler at gmail dot com | --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 11:55:16 UTC --- Daniel can you double check? Did we regress between the end of July and now or what? Because with today's mainline the static_assert for X fires for me.
[Bug c++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 12:05:57 UTC --- Frankly I'm also not sure about the signature of the begin and end overloads themselves, is it even possible to tell apart VLAs??
[Bug c++/54276] Lambda in a Template Function Undefined Reference to local static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|travis at gockelhut dot com | --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 12:09:54 UTC --- Daniel can you please double check this one too? Today I'm definitely seeing the undefined reference.
[Bug c++/54319] Assignment to rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-08-19 12:13:32 UTC --- (In reply to comment #2) Daniel can you double check? Good that you ask. There must by some problem with my gcc installation, because I get different results from different contexts calling gcc. I can confirm that gcc 4.8 invoked from my command line also fires the static assertion. I apologize for any confusion.
[Bug c++/54276] Lambda in a Template Function Undefined Reference to local static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-08-19 12:14:53 UTC --- (In reply to comment #2) Daniel can you please double check this one too? Today I'm definitely seeing the undefined reference. It seems that I need to fix my gcc installation as described in bug 54319 - my apologies.
[Bug c++/54319] Assignment to rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 12:43:25 UTC --- No problem, let's confirm these two bugs and, hey, privately maybe let me know how it goes, maybe we can ask the help of a mingw maintainer, or something.
[Bug c++/54276] Lambda in a Template Function Undefined Reference to local static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1
[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488 Jiří Paleček jpalecek at web dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #10 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:04:34 UTC --- I found a similar preceding bugreport 52026. Therefore, I'm marking as duplicate. *** This bug has been marked as a duplicate of bug 52026 ***
[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026 --- Comment #5 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:04:34 UTC --- *** Bug 53488 has been marked as a duplicate of this bug. ***
[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488 --- Comment #11 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:11:22 UTC --- BTW I have proposed a patch that fixes this problem here: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01252.html. Please take a look at it.
[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026 --- Comment #6 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:13:44 UTC --- BTW I have proposed a patch that fixes this problem here: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01252.html. Please take a look at it.
[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 14:38:36 UTC --- Do you have a copyright assignment on file?
[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54298 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 15:05:49 UTC --- Author: tkoenig Date: Sun Aug 19 15:05:41 2012 New Revision: 190516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190516 Log: 2012-08-19 Thomas König tkoe...@gcc.gnu.org PR fortran/54298 * gfortran.h (struct gfc_option_t): Add warn_compare_reals. * lang.opt: Add Wcompare-reals. * invoke.texi: Document -Wcompare-reals. * resolve.c (resolve_operator): If -Wcompare-reals is in effect, warn about equality/inequality comparisions for REAL and COMPLEX. * options.c (gfc_init_options): Set warn_compare_reals. (set_Wall): Include warn_compare_reals in Wall. (gfc_handle_option): Handle Wcompare_reals. 2012-08-19 Thomas König tkoe...@gcc.gnu.org PR fortran/54298 * gfortran.dg/real_compare_1.f90: New test case. * gfortran.dg/bessel_5.f90 Add -Wno-compare-reals to options. Added: trunk/gcc/testsuite/gfortran.dg/real_compare_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bessel_5.f90
[Bug fortran/54322] New: [OOP] Wrong TARGET-attribute handling with CLASS IS/TYPE IS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54322 Bug #: 54322 Summary: [OOP] Wrong TARGET-attribute handling with CLASS IS/TYPE IS Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Reported at comp.lang.fortran, https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/11t7gAgUGD4 The following piece of the program is invalid if PC_ALLOC is not a TARGET, however, gfortran accepts it: select type ( AN = pc_alloc ) type is ( POINT_3D ) p3d_poi=AN Note that this possibly not only affects pointer assignment but also passing as actual argument to an INTENT(IN) pointer dummy, and possibly other cases. !- LONG TEST CASE --- module mymod type POINT real :: X, Y contains procedure :: s1 = sub1 end type POINT type, extends(POINT) :: POINT_3D real :: Z end type POINT_3D type, extends(POINT) :: COLOR_POINT integer :: COLOR end type COLOR_POINT contains subroutine sub1(this) class(POINT) :: this end subroutine sub1 end module mymod ! program hello use mymod implicit none type(POINT), target :: P type(POINT_3D), target :: P3D type(COLOR_POINT), target :: CP class(POINT), pointer :: P_OR_CP class(POINT),allocatable::pc_alloc !NO TARGET class(POINT_3D),pointer ::p3d_poi P_OR_CP= CP allocate (POINT_3D :: pc_alloc) pc_alloc%X=1. pc_alloc%Y=2. select type ( AN = pc_alloc ) class is ( POINT ) ! print *, AN%X, AN%Y type is ( POINT_3D ) AN%Z=3. p3d_poi=AN ! INVALID if PC_ALLOC is not a TARGET end select print *, p3d_poi%X, p3d_poi%Y, p3d_poi%Z end program
[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026 --- Comment #8 from Jiří Paleček jpalecek at web dot de 2012-08-19 15:38:33 UTC --- (In reply to comment #7) Do you have a copyright assignment on file? I don't know what you're talking about, so probably no. (BTW which file?)
[Bug c++/54323] New: Friend function declaration not correctly identified with CRTP + enable_if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54323 Bug #: 54323 Summary: Friend function declaration not correctly identified with CRTP + enable_if Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vince@gmail.com Created attachment 28051 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28051 .cpp bug example The following example involving a friend function in a Curiously Recurring Template Pattern base class with an enable_if default template argument is not working : // #include type_traits // Base class definition templatetemplatetypename class CRTP, typename T class Base { // Friend function declaration public: templatetemplatetypename class CRTP0, typename T0, class friend int func(const BaseCRTP0, T0 rhs); // Protected test variable protected: int n; }; // Friend function definition templatetemplatetypename class CRTP0, typename T0, class = typename std::enable_iftrue::type int func(const BaseCRTP0, T0 rhs) { return rhs.n; } // Derived class definition templatetypename T class Derived : public BaseDerived, T {}; // Main int main() { Derivedint x; func(x); return 0; } // g++ (tested with 4.6.1, 4.6.2 and 4.7.1) seems not to be able to match the definition with the declaration of the function and return the following error : int BaseDerived, int::n' is protected
[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54298 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 16:08:37 UTC --- Fixed on trunk, closing.
[Bug fortran/54302] Add optional warning when declaring a identifier in a nested scope, which matches on otherwise available one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54302 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 17:01:37 UTC --- In other words, implement -Wshadow in gfortran. Makes sense. Confirmed.
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 17:10:28 UTC --- (In reply to comment #3) Given the potential badness, I still think one should warn for (a) to (d). Though, one probably should think of not warning if the target has the SAVE attribute. If the target has the SAVE attribute or is allocatable, we shouldn't warn. The other question is whether the warning should be enabled by -Wall or not. (I would enable it with -Wall.) At least. Because the behavior is very likely to lead to difficult to detect bugs, I would even consider warning by default.
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-19 17:27:14 UTC --- (In reply to comment #4) (In reply to comment #3) If the target has the SAVE attribute or is allocatable, we shouldn't warn. Why shouldn't one warn for ALLOCATABLE? See first example in comment 2 for a code for which I would like to warn! Submitted patch: http://gcc.gnu.org/ml/fortran/2012-08/msg00094.html
[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Component|c |middle-end Target Milestone|--- |4.8.0 Summary|ice in tree_low_cst at -O3 |[4.8 Regression] ice in ||tree_low_cst at -O3
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 --- Comment #19 from Denis Kolesnik lirex.software at gmail dot com 2012-08-19 18:15:49 UTC --- (In reply to comment #18) Gcc cannot alter results of an SQL query, it's a bug in your program. This is the wrong place to get help debugging your code. You are right: I consider now, that it is a PostgreSQL SQL bug. limit 1 offset ... order byt str_last_name filters data wrong...
[Bug other/54324] New: GCC install document does not list minimum required g++ versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 Bug #: 54324 Summary: GCC install document does not list minimum required g++ versions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com Ref: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01223.html Currently, install.texi states: @heading Tools/packages necessary for building GCC @table @asis @item ISO C90 compiler Necessary to bootstrap GCC, although versions of GCC prior to 3.4 also allow bootstrapping with a traditional (KR) C compiler. To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions. This appears to be out-of-date with respect to new GCC 4.8 C++ stage 1 build requirement.
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 --- Comment #20 from Denis Kolesnik lirex.software at gmail dot com 2012-08-19 18:21:08 UTC --- sure: I found, that the bug is if I use limit 1 clause. It is surelly a bug.
[Bug c++/54325] New: C++11 uniform initialization syntax for argument-less abstract base class constructor fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54325 Bug #: 54325 Summary: C++11 uniform initialization syntax for argument-less abstract base class constructor fails Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mor...@bunkus.org Using {} syntax for base class initialization fails with cannot allocate an object of abstract type 'Base' for abstract base classes with argument-less constructors. I'll include two code samples. The first one does work with g++ 4.6.1 (Ubuntu 11.10), g++ 4.6.3 (Ubuntu 12.04) and clang 3.1 but does NOT work with g++ 4.7.0 (Ubuntu 12.04) and g++ 4.7.1 (self-compiled). The second one works with 4.7.0 and 4.7.1 as well. Example code that does NOT work with 4.7.x but does with older versions/other compilers: class Base { public: Base() {}; virtual ~Base() {}; virtual void do_stuff() = 0; }; class Derived: public Base { public: Derived() : Base{} {}; virtual ~Derived() {}; virtual void do_stuff() {}; }; int main() { Derived d; return 0; } Changing Base's constructor to take an additional argument lets it work suddenly: class Base { public: int m_dummy; Base(int dummy): m_dummy{dummy} {}; virtual ~Base() {}; virtual void do_stuff() = 0; }; class Derived: public Base { public: Derived() : Base{42} {}; virtual ~Derived() {}; virtual void do_stuff() {}; }; int main() { Derived d; return 0; } $ ~/opt/gcc/4.7.1/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/mosu/opt/gcc/4.7.1/bin/g++ COLLECT_LTO_WRAPPER=/home/mosu/opt/gcc/4.7.1/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-checking=release --enable-languages=c,c++ --prefix=/home/mosu/opt/gcc/4.7.1 Thread model: posix gcc version 4.7.1 (GCC) Actual error message: $ ~/opt/gcc/4.7.1/bin/g++ -std=c++11 -o fails fails.cpp fails.cpp: In constructor ‘Derived::Derived()’: fails.cpp:11:20: error: cannot allocate an object of abstract type ‘Base’ fails.cpp:1:7: note: because the following virtual functions are pure within ‘Base’: fails.cpp:6:16: note: virtual void Base::do_stuff()
[Bug target/54308] [4.8 regression] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308 --- Comment #7 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-08-19 18:29:27 UTC --- (In reply to comment #6) I was unable to build 4.1.2-27.fc7 from the SRPM. I'm not sure it would have helped, seeing as the breakage was in rs6000-specific parts. So, I've given up on finding the lowest supported compiler. Ok, but see comment 4; try just removing the inline there. If necessary, the inline can be wrapped in some #ifdef construct. It depends on the maintainer to deem it acceptable of course.
[Bug other/54326] New: GCC does not build with G++ version 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 Bug #: 54326 Summary: GCC does not build with G++ version 3.4.0 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com Ref: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01223.html See also: Bug #54324 (install documentation does not list the minimum required g++ version) Paul Hargrove noted the following build failure on an older x86-32 Linux (Redhat 8.0) system. The g++ version is: g++ (GCC) 3.4.0 g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/build -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../include -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libcpp/include -I/usr/local/pkg/gmp-4.2.4/include -I/usr/local/pkg/mpfr-2.4.2/include -I/usr/local/pkg/mpc-0.8/include -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber/bid -I../libdecnumber\ -o build/genoutput.o /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c: In function `void note_constraint(rtx_def*, int)': /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c:1178: error: reinterpret_cast from type `const char (*)[1]' to type `char*' casts away constness make[2]: *** [build/genoutput.o] Error 1 make[2]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld/gcc' make[1]: *** [all-gcc] Error 2
[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-08-19 18:53:56 UTC --- It is caused by revision 188232: http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00142.html
[Bug c/54327] New: Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 Bug #: 54327 Summary: Segmentation fault in init_ggc Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com I just tried to compile the package httrack-3.43.9-5 on gcc-4.8 trunk dated 20120819 on an AMD x86_64 box. The compiler said htslib.c: In function 'treathead': htslib.c:1246:6: internal compiler error: Segmentation fault void treathead(t_cookie* cookie,char* adr,char* fil,htsblk* retour,char* rcvd) { ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Here is valgrind with some more details ==13706== Invalid read of size 4 ==13706==at 0xD4FF90: linemap_location_from_macro_expansion_p(line_maps*, un signed int) (line-map.c:796) ==13706==by 0xD4FFCF: linemap_lookup(line_maps*, unsigned int) (line-map.c:5 12) ==13706==by 0x8E6534: virt_loc_aware_diagnostic_finalizer(diagnostic_context *, diagnostic_info*) (tree-diagnostic.c:113) ==13706==by 0xD3A263: diagnostic_report_diagnostic(diagnostic_context*, diag nostic_info*) (diagnostic.c:652) ==13706==by 0xD3B03F: internal_error(char const*, ...) (diagnostic.c:957) ==13706==by 0x8B800F: crash_signal(int) (toplev.c:335) ==13706==by 0x3809C3599F: ??? (in /usr/lib64/libc-2.15.so) ==13706==by 0x5A7625: init_ggc() (hwint.h:264) ==13706==by 0x8B967F: toplev_main(int, char**) (toplev.c:1137) ==13706==by 0x3809C21734: (below main) (in /usr/lib64/libc-2.15.so) ==13706== Address 0x24 is not stack'd, malloc'd or (recently) free'd ==13706== Preprocessed source code attached. Flag -O2 required.
[Bug c/54327] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 --- Comment #1 from David Binderman dcb314 at hotmail dot com 2012-08-19 20:14:08 UTC --- Created attachment 28052 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28052 gzipped C source code
[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-08-19 20:22:39 UTC --- Created attachment 28053 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28053 gcc48-pr54321.patch The bug is pretty much obvious, val2 is first checked for host_integerp (val2, 0) but then tree_low_cst (val2, 1) is used. As the middle argument to memset is int, we should use tree_low_cst (val2, 0). I'll bootstrap/regtest this momentarily.
[Bug other/54326] GCC does not build with G++ version 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 --- Comment #1 from Gary Funck gary at intrepid dot com 2012-08-19 20:54:51 UTC --- Don't know if this is relevant, but a recent thread on the clang-dev list explored the differences between GCC and clang in the handling of const and constexpr. clang vs GCC error case: both ‘const’ and ‘constexpr’ cannot be used here http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-August/023565.html
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||kkojima at gcc dot gnu.org --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2012-08-19 20:56:19 UTC --- The problem started with the PR27942 fix in r114552: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00569.html http://gcc.gnu.org/ml/gcc-cvs/2006-06/msg00268.html and it affects gcc-4.2.0 up to current trunk. The problem isn't mingw-specific, it can be reproduced natively on e.g. x86_64-linux. Take this C test case, reduced from #c1: struct A { short s; struct { int i; } x; } __attribute__((__packed__)); struct C { struct { int i; } x; short s; } __attribute__((__packed__)); int foo(void) { return sizeof(struct A) == sizeof(struct C); } Compiling this with -mno-ms-bitfields makes foo() return 1, but compiling with -mms-bitfields makes foo() return 0 because sizeof(struct A) then is 8 while sizeof(struct C) still is 6.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28048|0 |1 is obsolete|| --- Comment #18 from Larry Baker baker at usgs dot gov 2012-08-19 21:18:23 UTC --- Created attachment 28054 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28054 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md Change 16-bit word offset (the default) Bcc .+6 instruction to 8-bit short offset Bcc.S .+4 instruction (saves 2 bytes in every procedure prologue).
[Bug c/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Target Milestone|--- |4.8.0 Summary|Segmentation fault in |[4.8 Regression] |init_ggc|Segmentation fault in ||init_ggc Ever Confirmed|0 |1
[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Component|c |middle-end --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-08-19 23:22:32 UTC --- It is caused by revision 189915: http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00820.html
[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-08-20 03:40:24 UTC --- Small testcase: #include string.h #include stdlib.h void treathead () { char *a = ';' == '\0' ? : 0; if (*a == '=') { while (*a == (*a == 0) || *a == '\'') a++; if (strlen (a) 2) abort (); } }
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-20 05:47:55 UTC --- Author: burnus Date: Mon Aug 20 05:47:46 2012 New Revision: 190522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190522 Log: 2012-08-20 Tobias Burnus bur...@net-b.de PR fortran/54301 * expr.c (gfc_check_pointer_assign): Warn when the pointer might outlive its target. * gfortran.h (struct gfc_option_t): Add warn_target_lifetime. * options.c (gfc_init_options, set_wall, gfc_handle_option): handle it. * invoke.texi (-Wtarget-lifetime): Document it. (-Wall): Implied it. * lang.opt (-Wtarget-lifetime): New flag. 2012-08-20 Tobias Burnus bur...@net-b.de PR fortran/54301 * gfortran.dg/warn_target_lifetime_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_target_lifetime_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-20 05:52:31 UTC --- FIXED on the 4.8 trunk.
Re: [PATCH] Fix AVR fallout
2012/8/18 Jan-Benedict Glaw jbg...@lug-owl.de: Hi! I see these warnings/errors right now: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../../../gcc/gcc/config/avr/avr-log.c cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wold-style-definition’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wc++-compat’ is valid for C/ObjC but not for C++ [enabled by default] ../../../../gcc/gcc/config/avr/avr-log.c: In function ‘void avr_log_vadump(FILE*, const char*, va_list)’: ../../../../gcc/gcc/config/avr/avr-log.c:287:22: warning: ‘machine_mode’ is promoted to ‘int’ when passed through ‘...’ [enabled by default] ../../../../gcc/gcc/config/avr/avr-log.c:287:22: note: (so you should pass ‘int’ not ‘machine_mode’ to ‘va_arg’) ../../../../gcc/gcc/config/avr/avr-log.c:287:22: note: if this code is reached, the program will abort ../../../../gcc/gcc/config/avr/avr-log.c:291:31: warning: ‘rtx_code’ is promoted to ‘int’ when passed through ‘...’ [enabled by default] ../../../../gcc/gcc/config/avr/avr-log.c:291:31: note: if this code is reached, the program will abort ../../../../gcc/gcc/config/avr/avr-log.c:295:38: warning: ‘reg_class’ is promoted to ‘int’ when passed through ‘...’ [enabled by default] ../../../../gcc/gcc/config/avr/avr-log.c:295:38: note: if this code is reached, the program will abort [...] g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c -o gen-avr-mmcu-texi cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wold-style-definition’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wc++-compat’ is valid for C/ObjC but not for C++ [enabled by default] ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c: In function ‘int main()’: ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c:53:24: error: invalid conversion from ‘int’ to ‘avr_arch’ [-fpermissive] ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c:75:23: error: invalid conversion from ‘int’ to ‘avr_arch’ [-fpermissive] make[3]: *** [gen-avr-mmcu-texi] Error 1 make[3]: Leaving directory `/mnt/devel/src/linux/build/avr/gcc-stage1/gcc' make[2]: *** [all-gcc] Error 2 make[2]: Leaving directory `/mnt/devel/src/linux/build/avr/gcc-stage1' I suggest this patch. Okay? 2012-08-17 Jan-Benedict Glaw jbg...@lug-owl.de gcc/Changelog: * config/avr/avr-log.c (avr_log_vadump): Properly use int-promoted enum values. * config/avr/avr.h (struct mcu_type_s): Change `arch' from int to enum avr_arch. * config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer. Thank you for the fix. Committed. Denis.
[PATCH, Committed] Fix ChangeLog (was: [PATCH] Fix AVR fallout)
On Sun, 2012-08-19 10:19:37 +0400, Denis Chertykov cherty...@gmail.com wrote: 2012/8/18 Jan-Benedict Glaw jbg...@lug-owl.de: [...] gcc/Changelog: * config/avr/avr-log.c (avr_log_vadump): Properly use int-promoted enum values. * config/avr/avr.h (struct mcu_type_s): Change `arch' from int to enum avr_arch. * config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer. Thank you for the fix. Committed. I fixed ChangeLog's whitespace (probably cut'n'paste error), committed as obvious. 2012-08-19 Jan-Benedict Glaw jbg...@lug-owl.de * ChangeLog: Fix whitespace. Index: ChangeLog === --- ChangeLog (revision 190511) +++ ChangeLog (working copy) @@ -5,11 +5,11 @@ 2012-08-18 Jan-Benedict Glaw jbg...@lug-owl.de -* config/avr/avr-log.c (avr_log_vadump): Properly use -int-promoted enum values. -* config/avr/avr.h (struct mcu_type_s): Change `arch' from -int to enum avr_arch. -* config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer. + * config/avr/avr-log.c (avr_log_vadump): Properly use + int-promoted enum values. + * config/avr/avr.h (struct mcu_type_s): Change `arch' from + int to enum avr_arch. + * config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer. 2012-08-18 Jan Hubicka j...@suse.cz -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Zensur im Internet? Nein danke! the second : signature.asc Description: Digital signature
Re: [bootstrap] Tentative fix for PR 54281
[Sorry for the delay] So, I had failed to include Ada in my testing and my patch breaks it. In several ada/*.c files, we forcefully include system.h as a C header: #ifdef __cplusplus extern C { #endif ... #include system.h ... #ifdef __cplusplus } #endif Eric, is this really needed now? We are including gmp.h from system.h due to PR 54281. This is causing Ada builds to fail. Would it be OK to remove all the '#ifdef __cplusplus' conditionals from ada/*.c or is there something I'm missing? The conditionals cannot be removed for the time being because the foreign language interface of the Ada part of the compiler is hardcoded for C. Barring a massive switch to the Ada language for the GNU project, we would need to switch the foreign language interface to C++, which might introduce various maintenance issues in the short term (Arno CCed). -- Eric Botcazou
[committed] cp/Make-lang.in typo fix
Hello, this is outside my area of maintainership, but I thought it was obvious enough. Mikael Index: Make-lang.in === --- Make-lang.in (révision 190512) +++ Make-lang.in (révision 190513) @@ -337,7 +337,7 @@ cp/mangle.o: cp/mangle.c $(CXX_TREE_H) $(TM_H) $(R gt-cp-mangle.h $(TARGET_H) $(TM_P_H) $(CGRAPH_H) cp/parser.o: cp/parser.c $(CXX_TREE_H) $(TM_H) $(DIAGNOSTIC_CORE_H) \ gt-cp-parser.h $(TARGET_H) $(PLUGIN_H) intl.h \ - c-family/c-objc.h tree-pretty-print.h $(CXX_PARSER_H) $(TIMEVAR.H) + c-family/c-objc.h tree-pretty-print.h $(CXX_PARSER_H) $(TIMEVAR_H) cp/cp-gimplify.o: cp/cp-gimplify.c $(CXX_TREE_H) $(C_COMMON_H) \ $(TM_H) coretypes.h pointer-set.h tree-iterator.h $(SPLAY_TREE_H) Index: ChangeLog === --- ChangeLog (révision 190512) +++ ChangeLog (révision 190513) @@ -1,3 +1,7 @@ +2012-08-19 Mikael Morin mik...@gcc.gnu.org + + * Make-lang.in: Fix typo. + 2012-08-17 Jakub Jelinek ja...@redhat.com * cp-tree.def (SIZEOF_EXPR): Move to c-common.def.
[patch, fortran] Warning for feal / complex equality / inequality comparisons
Hello world, the attached patch warns about comparisions for equality and inequality of real and complex values if -Wcompare-reals is given. The new compiler option is included in -Wall. Regression-tested, tested with make info and make dvi. OK for trunk? Thomas 2012-08-19 Thomas König tkoe...@gcc.gnu.org PR fortran/54298 * gfortran.h (struct gfc_option_t): Add warn_compare_reals. * lang.opt: Add Wcompare-reals. * invoke.texi: Document -Wcompare-reals. * resolve.c (resolve_operator): If -Wcompare-reals is in effect, warn about equality/inequality comparisions for REAL and COMPLEX. * options.c (gfc_init_options): Set warn_compare_reals. (set_Wall): Include warn_compare_reals in Wall. (gfc_handle_option): Handle Wcompare_reals. 2012-08-19 Thomas König tkoe...@gcc.gnu.org PR fortran/54298 * gfortran.dg/real_compare_1.f90: New test case. * gfortran.dg/bessel_5.f90 Add -Wno-compare-reals to options. Index: testsuite/gfortran.dg/bessel_5.f90 === --- testsuite/gfortran.dg/bessel_5.f90 (Revision 190442) +++ testsuite/gfortran.dg/bessel_5.f90 (Arbeitskopie) @@ -1,5 +1,5 @@ ! { dg-do run } -! { dg-options -Wall -fno-range-check } +! { dg-options -Wall -fno-range-check -Wno-compare-reals } ! ! PR fortran/36158 - Transformational BESSEL_JN/YN ! PR fortran/33197 - F2008 math functions Index: fortran/gfortran.h === --- fortran/gfortran.h (Revision 190442) +++ fortran/gfortran.h (Arbeitskopie) @@ -2225,6 +2225,7 @@ typedef struct int warn_unused_dummy_argument; int warn_realloc_lhs; int warn_realloc_lhs_all; + int warn_compare_reals; int max_errors; int flag_all_intrinsics; Index: fortran/lang.opt === --- fortran/lang.opt (Revision 190442) +++ fortran/lang.opt (Arbeitskopie) @@ -218,6 +218,10 @@ Wcharacter-truncation Fortran Warning Warn about truncated character expressions +Wcompare-reals +Fortran Warning +Warn about equality comparisons involving REAL or COMPLEX expressions + Wconversion Fortran Warning ; Documented in C Index: fortran/invoke.texi === --- fortran/invoke.texi (Revision 190442) +++ fortran/invoke.texi (Arbeitskopie) @@ -726,10 +726,11 @@ warnings. @cindex warnings, all Enables commonly used warning options pertaining to usage that we recommend avoiding and that we believe are easy to avoid. -This currently includes @option{-Waliasing}, @option{-Wampersand}, -@option{-Wconversion}, @option{-Wsurprising}, @option{-Wintrinsics-std}, -@option{-Wno-tabs}, @option{-Wintrinsic-shadow}, @option{-Wline-truncation}, -@option{-Wreal-q-constant} and @option{-Wunused}. +This currently includes @option{-Waliasing}, @option{-Wampersand}, +@option{-Wconversion}, @option{-Wcompare-reals}, @option{-Wsurprising}, +@option{-Wintrinsics-std}, @option{-Wno-tabs}, @option{-Wintrinsic-shadow}, +@option{-Wline-truncation}, @option{-Wreal-q-constant} and +@option{-Wunused}. @item -Waliasing @opindex @code{Waliasing} @@ -935,6 +936,11 @@ a scalar. See also @option{-frealloc-lhs}. Warn when the compiler inserts code to for allocation or reallocation of an allocatable variable; this includes scalars and derived types. +@item -Wcompare-reals +@opindex @code{Wcompare-reals} +Warn when comparing real or complex types for equality or inequality. +Enabled by @option{-Wall}. + @item -Werror @opindex @code{Werror} @cindex warnings, to errors Index: fortran/resolve.c === --- fortran/resolve.c (Revision 190442) +++ fortran/resolve.c (Arbeitskopie) @@ -4034,6 +4034,27 @@ resolve_operator (gfc_expr *e) e-ts.type = BT_LOGICAL; e-ts.kind = gfc_default_logical_kind; + + if (gfc_option.warn_compare_reals) + { + gfc_intrinsic_op op = e-value.op.op; + + if ((op1-ts.type == BT_REAL || op1-ts.type == BT_COMPLEX) + (op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS + || op == INTRINSIC_NE || op == INTRINSIC_NE_OS)) + { + bool equality; + + equality = op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS; + + /* Type conversion has made sure that the types + of op1 and op2 agree. */ + gfc_warning (%s comparison for %s at %L, + equality ? Equality : Inequality, + gfc_typename (op1-ts), op1-where); + } + } + break; } Index: fortran/options.c === --- fortran/options.c (Revision 190442) +++ fortran/options.c (Arbeitskopie) @@ -113,6 +113,7 @@ gfc_init_options (unsigned int decoded_options_cou gfc_option.warn_unused_dummy_argument = 0; gfc_option.warn_realloc_lhs = 0; gfc_option.warn_realloc_lhs_all = 0; +
Re: [bootstrap] Tentative fix for PR 54281
The conditionals cannot be removed for the time being because the foreign language interface of the Ada part of the compiler is hardcoded for C. Barring a massive switch to the Ada language for the GNU project, we would need to switch the foreign language interface to C++, which might introduce various maintenance issues in the short term (Arno CCed). Yes, that would be a large hearthquake for both the compiler and the run-time, which is unwanted at this stage. I guess the solution for now is to more selectively export the various symbols as C symbols and include header files as is. Arno
Re: [patch, fortran] Warning for feal / complex equality / inequality comparisons
Thomas Koenig wrote: the attached patch warns about comparisions for equality and inequality of real and complex values if -Wcompare-reals is given. The new compiler option is included in -Wall. Regression-tested, tested with make info and make dvi. OK for trunk? Thanks for the patch. It's okay, after fixing the nits below. + if (gfc_option.warn_compare_reals) + { + gfc_intrinsic_op op = e-value.op.op; + + if ((op1-ts.type == BT_REAL || op1-ts.type == BT_COMPLEX) + (op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS + || op == INTRINSIC_NE || op == INTRINSIC_NE_OS)) + { + bool equality; + + equality = op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS; + + /* Type conversion has made sure that the types +of op1 and op2 agree. */ + gfc_warning (%s comparison for %s at %L, + equality ? Equality : Inequality, + gfc_typename (op1-ts), op1-where); Can you move up the comment before the (op1-ts.type? When reading the patch, I stumbled over that, before reading 8 lines later that checking op1 is sufficient. Additionally, your gfc_warning is rather unfriendly to translators (try yourself to translate it, taking into account that the Equality string might be re-used elsewhere). I think it is better to have two separate strings, one for equality and one for inequality. Tobias
[Ada] Fix temporary incorrectly-typed COMPONENT_REF
We generate a temporary incorrectly-typed COMPONENT_REF in gigi when building a derived tagged type with discriminant. That's essentially harmless, but breaks the invariant that the type of the first operand of COMPONENT_REF is aggregate. Tested on x86_64-suse-linux, applied on the mainline. 2012-08-19 Eric Botcazou ebotca...@adacore.com * gcc-interface/decl.c (gnat_to_gnu_entity) E_Record_Type: Use proper dummy type for the temporary COMPONENT_REF built for a derived tagged type with discriminant. -- Eric Botcazou Index: gcc-interface/decl.c === --- gcc-interface/decl.c (revision 190510) +++ gcc-interface/decl.c (working copy) @@ -2988,6 +2988,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit if (Present (Parent_Subtype (gnat_entity))) { Entity_Id gnat_parent = Parent_Subtype (gnat_entity); + tree gnu_dummy_parent_type = make_node (RECORD_TYPE); tree gnu_parent; /* A major complexity here is that the parent subtype will @@ -2999,11 +3000,11 @@ gnat_to_gnu_entity (Entity_Id gnat_entit each of those discriminants to a COMPONENT_REF of the above dummy parent referencing the corresponding discriminant of the base type of the parent subtype. */ - gnu_get_parent = build3 (COMPONENT_REF, void_type_node, + gnu_get_parent = build3 (COMPONENT_REF, gnu_dummy_parent_type, build0 (PLACEHOLDER_EXPR, gnu_type), build_decl (input_location, FIELD_DECL, NULL_TREE, - void_type_node), + gnu_dummy_parent_type), NULL_TREE); if (has_discr)
[Ada] Avoid unnecessarily overaligned access types
This changes the default alignment of all access types to that of access types with standard size (Standard'Address_Size) on non-strict-alignment platforms. This in particular means that access-to-unconstrained-array types, whose size is twice as large as that of regular access types, are not overaligned by default anymore and therefore don't cause unnecessary padding in record types. The following program must run quietly on these platforms: procedure P is type Array_T is array (Positive range ) of Integer; type Access_Array_T is access Array_T; type Thin_Access_Array_T is access Array_T; for Thin_Access_Array_T'Size use Standard'Address_Size; begin if Access_Array_T'Alignment /= Thin_Access_Array_T'Alignment then raise Program_Error; end if; end; Tested on x86_64-suse-linux, applied on the mainline. 2012-08-19 Eric Botcazou ebotca...@adacore.com * layout.adb (Set_Elem_Alignment): Cap the alignment of access types to that of a regular access type for non-strict-alignment platforms. * gcc-interface/utils.c (finish_fat_pointer_type): Do not set the alignment for non-strict-alignment platforms. -- Eric Botcazou Index: layout.adb === --- layout.adb (revision 190510) +++ layout.adb (working copy) @@ -3118,6 +3118,19 @@ package body Layout is if Esize (E) / SSU Ttypes.Maximum_Alignment then S := Ttypes.Maximum_Alignment; + + -- If this is an access type and the target doesn't have strict + -- alignment and we are not doing front end layout, then cap the + -- alignment to that of a regular access type. This will avoid + -- giving fat pointers twice the usual alignment for no practical + -- benefit since the misalignment doesn't really matter. + + elsif Is_Access_Type (E) + and then not Target_Strict_Alignment + and then not Frontend_Layout_On_Target + then +S := System_Address_Size / SSU; + else S := UI_To_Int (Esize (E)) / SSU; end if; Index: gcc-interface/utils.c === --- gcc-interface/utils.c (revision 190510) +++ gcc-interface/utils.c (working copy) @@ -1369,7 +1369,8 @@ void finish_fat_pointer_type (tree record_type, tree field_list) { /* Make sure we can put it into a register. */ - TYPE_ALIGN (record_type) = MIN (BIGGEST_ALIGNMENT, 2 * POINTER_SIZE); + if (STRICT_ALIGNMENT) +TYPE_ALIGN (record_type) = MIN (BIGGEST_ALIGNMENT, 2 * POINTER_SIZE); /* Show what it really is. */ TYPE_FAT_POINTER_P (record_type) = 1;
[Patch, Fortran] PR54301 - add warning for pointer might outlive its target
As suggested in the draft Fortran appendix to ISO/IEC Technical Report 24772 Guidance for Avoiding Vulnerabilities through Language Selection and Use* Future standardization efforts should consider: ... * Requiring that processors have the ability to detect and report the occurrence within a submitted program unit of pointer assignment of a pointer whose lifetime is known to be longer than the lifetime of the target. The new flag -Wtarget-lifetime implements this; it is enabled by -Wall. (Well, at least kind of; the suggested requirement is only implementable by a complicated run-time check. However, the attached compile-time warning is a good approximation, which should help to find real bugs with only few false positives.) Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias * See http://gcc.gnu.org/wiki/GFortranStandards#ISO.2BAC8-IEC_Project_22.24772:_Guidance_for_Avoiding_Vulnerabilities_through_Language_Selection_and_Use 2012-08-19 Tobias Burnus bur...@net-b.de PR fortran/54301 * expr.c (gfc_check_pointer_assign): Warn when the pointer might outlive its target. * gfortran.h (struct gfc_option_t): Add warn_target_lifetime. * options.c (gfc_init_options, set_wall, gfc_handle_option): handle it. * invoke.texi (-Wtarget-lifetime): Document it. (-Wall): Implied it. * lang.opt (-Wtarget-lifetime): New flag. 2012-08-19 Tobias Burnus bur...@net-b.de PR fortran/54301 * gfortran.dg/warn_target_lifetime_1.f90: New. diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c index 7d74528..d94afb7 100644 --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -3659,6 +3659,37 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue) } } + /* Warn if it is the LHS pointer may lives longer than the RHS target. */ + if (gfc_option.warn_target_lifetime + rvalue-expr_type == EXPR_VARIABLE + !rvalue-symtree-n.sym-attr.save + !attr.pointer !rvalue-symtree-n.sym-attr.host_assoc + !rvalue-symtree-n.sym-attr.in_common + !rvalue-symtree-n.sym-attr.use_assoc + !rvalue-symtree-n.sym-attr.dummy) +{ + bool warn; + gfc_namespace *ns; + + warn = lvalue-symtree-n.sym-attr.dummy + || lvalue-symtree-n.sym-attr.result + || lvalue-symtree-n.sym-attr.host_assoc + || lvalue-symtree-n.sym-attr.use_assoc + || lvalue-symtree-n.sym-attr.in_common; + + if (rvalue-symtree-n.sym-ns-proc_name + rvalue-symtree-n.sym-ns-proc_name-attr.flavor != FL_PROCEDURE) + for (ns = rvalue-symtree-n.sym-ns; + ns-proc_name ns-proc_name-attr.flavor != FL_PROCEDURE; + ns = ns-parent) + if (ns-parent == lvalue-symtree-n.sym-ns) + warn = true; + + if (warn) + gfc_warning (Pointer at %L in pointer assignment might outlive the + pointer target, lvalue-where); +} + return SUCCESS; } diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h index 7c4c0a4..308dbc1 100644 --- a/gcc/fortran/gfortran.h +++ b/gcc/fortran/gfortran.h unsigned select_type_temporary:1; @@ -2225,6 +2226,7 @@ typedef struct int warn_unused_dummy_argument; int warn_realloc_lhs; int warn_realloc_lhs_all; + int warn_target_lifetime; int max_errors; int flag_all_intrinsics; diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi index 658ed23..edd9183 100644 --- a/gcc/fortran/invoke.texi +++ b/gcc/fortran/invoke.texi @@ -147,7 +147,7 @@ and warnings}. -Wimplicit-procedure -Wintrinsic-shadow -Wintrinsics-std @gol -Wline-truncation -Wno-align-commons -Wno-tabs -Wreal-q-constant @gol -Wsurprising -Wunderflow -Wunused-parameter -Wrealloc-lhs Wrealloc-lhs-all @gol --fmax-errors=@var{n} -fsyntax-only -pedantic -pedantic-errors +-Wtarget-lifetime -fmax-errors=@var{n} -fsyntax-only -pedantic -pedantic-errors } @item Debugging Options @@ -729,7 +729,7 @@ we recommend avoiding and that we believe are easy to avoid. This currently includes @option{-Waliasing}, @option{-Wampersand}, @option{-Wconversion}, @option{-Wsurprising}, @option{-Wintrinsics-std}, @option{-Wno-tabs}, @option{-Wintrinsic-shadow}, @option{-Wline-truncation}, -@option{-Wreal-q-constant} and @option{-Wunused}. +@option{-Wreal-q-constant}, @option{-Wtarget-lifetime} and @option{-Wunused}. @item -Waliasing @opindex @code{Waliasing} @@ -935,6 +935,11 @@ a scalar. See also @option{-frealloc-lhs}. Warn when the compiler inserts code to for allocation or reallocation of an allocatable variable; this includes scalars and derived types. +@item -Wtarget-lifetime +@opindex @code{Wtargt-lifetime} +Warn if the pointer in a pointer assignment might be longer than the its +target. This option is implied by @option{-Wall}. + @item -Werror @opindex @code{Werror} @cindex warnings, to errors diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt index 3b9d29b..a721187 100644 --- a/gcc/fortran/lang.opt +++ b/gcc/fortran/lang.opt @@ -258,6 +258,10 @@ Wrealloc-lhs-all Fortran Warning Warn when a left-hand-side variable is
Re: [graphds.h] Allocate graph from obstack
On Sat, Aug 18, 2012 at 8:10 PM, Dimitrios Apostolou ji...@gmx.net wrote: Initially I had one obstack per struct graph, which was better than using XNEW for every edge, but still obstack_init() called from new_graph() was too frequent. So in this iteration of the patch the obstack is static global, initialised once and never freed. Please advise on whether this is acceptable, and also where I should initialise the obstack once, and avoid checking if it's NULL in every use. Minor speed gains (couple of ms), tested with pre-C++ conversion snapshot, I'll retest soon and post update. Either an obstack per graph or the ability to specify an obstack for allocation. A global obstack with global lifetime is bad IMHO. Richard. Thanks, Dimitris
Re: [PATCH/MIPS] Use ins/dins instruction when written manually
Andrew Pinski andrew.pin...@caviumnetworks.com writes: Right now we only produce ins when a zero_extract is used on the right hand side. We can do better by adding some patterns which combine for the ins instruction. This patch adds those patterns and a testcase which shows a simple example where the code is improved. Sorry for the delay in reviewing this. Had you thought about trying to teach combine.c about this instead? It doesn't look like any of the patterns are really providing more information about the underlying instruction. At the moment the patch has things like: +(define_insn *insvmode_internal1 + [(set (match_operand:GPR 0 register_operand =d) +(ior:GPR (and:GPR (match_operand:GPR 1 register_operand 0) + (match_operand:GPR 2 const_int_operand i)) + (and:GPR (match_operand:GPR 3 register_operand d) + (match_operand:GPR 4 const_int_operand i] + ISA_HAS_EXT_INS mips_bottom_bitmask_p (INTVAL (operands[4])) +INTVAL(operands[2]) == ~INTVAL(operands[4]) +{ + int len, pos; + pos = mips_bitmask (INTVAL (operands[4]), len, MODEmode); + operands[2] = GEN_INT (pos); + operands[4] = GEN_INT (len); + return dins\t%0,%3,%2,%4; +} + [(set_attr type arith) + (set_attr mode MODE)]) but AFAIK there's nothing to guarantee that the bottom bitmask will be operand 2 rather than operand 4, so if we really do need do this via patterns, I think we'd need both orderrs. But if we do it this way, I assume every backend that provides an insv pattern will need to cut--paste these patterns too. Richard
Re: [wwwdocs] SH 4.8 changes update
On Sun, 19 Aug 2012, Oleg Endo wrote: This is what has been done so far on the SH side for 4.8. I hope it's OK. Wow, that is quite impressive (and a nice write-up also)! I see this was already approved, but allow me to suggest some minor editorial comments... Index: htdocs/gcc-4.8/changes.html === +liThe default alignment settings have been reduced to be less aggresive. aggressive + liMinor tweaks for code around software atomic sequences that are + enabled by code-msoft-atomic/code./li code for? Not sure... + liA new option code-menable-tas/code will make the compiler + generate the codetas.b/code instruction for the + code__atomic_test_and_set/code built-in function./li A naive question: Why is this not on by default? Or is it under certain circumstances? +liThe codefmac/code instruction will now be emitted by the +codefmaf/code standard and built-in function./li built-in standard function, perhaps? +liThe code-mfused-madd/code option has been depricated in favor of deprecated +liAdded new options code-mfsrra/code and code-mfsca/code to allow +the compiler using the codefsrra/code and codefsca/code +instructions on CPUs other than SH4A./li How about adding ...SH4A (where they are already on by default) or similar? Gerald
Re: [PATCH, MIPS] add new peephole for 74k dspr2
Sandra Loosemore san...@codesourcery.com writes: This patch adds a peephole optimization to use a clever trick to zero-initialize the two halves of an accumulator register with one instruction instead of a mtlo/mthi pair. OK to check in? -Sandra 2012-08-16 Sandra Loosemore san...@codesourcery.com Julian Brown jul...@codesourcery.com MIPS Technologies, Inc. gcc/ * config/mips/mips-dspr2.md (UNSPEC_ACC_INIT): Declare. (mult peephole2): Add peephole that converts mtlo $ac[1-3],$0; mthi $ac[1-3],$0 into mult $ac[1-3],$0,$0. (*mips_acc_init): New insn for above. Not sure whether a peephole is the right choice here. In practice, I'd imagine these opportunities would only come from a DImode move of $0 into a doubleword register, so we could simply emit the pattern in mips_split_doubleword_move. That would also allow us to use it for plain HI and LO. It wasn't obvious from the patch why it was restricted to the DSP extension registers. Please also add a scan-assembler test. Richard
Re: Commit: BFIN: Fix use of VEC_last macro in bfin.c
On Fri, 17 Aug 2012, Diego Novillo wrote: Thanks. We need a much better mechanism for documenting and advertising the stuff in contrib/. I see that contrib/ does not even have a README file. How about starting one with your contributions at least (and of course what- ever else you'd like to mention, though I don't want to sign you up for everything already there)? And we'll take it from there? Or is it something else you have in mind? Gerald
Re: [PING][PATCH,dejagnu] Allow dg-skip-if to use compiler flags specified through set_board_info cflags
Hello On Sat, Aug 11, 2012 at 11:09:03PM +0530, Senthil Kumar Selvaraj wrote: This patch allows cflags set in board config files using set_board_info cflags to be used in the selectors of dg-skip-if and other dejagnu commands that use the check-flags proc. The code merely adds cflags to compiler_flags in the check-flags proc, exactly the same way as multilib_flags is added. Regards Senthil * lib/target-supports-dg.exp (check-flags): Add cflags from board config to compiler_flags diff --git a/gcc/testsuite/lib/target-supports-dg.exp b/gcc/testsuite/lib/target-supports-dg.exp index 2f6c4c2..bdf7476 100644 --- a/gcc/testsuite/lib/target-supports-dg.exp +++ b/gcc/testsuite/lib/target-supports-dg.exp @@ -304,6 +304,9 @@ proc check-flags { args } { # If running a subset of the test suite, $TEST_ALWAYS_FLAGS may not exist. catch {append compiler_flags $TEST_ALWAYS_FLAGS } set dest [target_info name] +if [board_info $dest exists cflags] { +append compiler_flags [board_info $dest cflags] +} if [board_info $dest exists multilib_flags] { append compiler_flags [board_info $dest multilib_flags] } Does the patch look ok? Regards Senthil
Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine
Dear all, attached is a slightly updated patch: * Call finalizers of nonallocatable, nonpointer components * Generate FINAL wrapper for abstract types which have a finalizer. (The allocatable components are deallocated in the first type (abstract or not) which has a finalizer, i.e. abstract + finalizer or first nonabstract type.) I had to disable some resolve warning; I did so by introducing an attr.artificial. I used it to also fix PR 51632, where we errored out for __def_init and __copy where there were coarray components. Build and regtested on x86-64-linux. OK for the trunk? Tobias 2012-08-19 Alessandro Fanfarillo fanfarillo@gmail.com Tobias Burnus bur...@net-b.de PR fortran/37336 * gfortran.h (symbol_attribute): Add artifical and final_comp. * parse.c (parse_derived): Set final_comp. * module.c (mio_symbol_attribute): Handle final.comp. * class.c (gfc_build_class_symbol): Defer creation of the vtab if the DT has finalizers, mark generated symbols as attr.artificial. (finalize_component, finalization_scalarizer, generate_finalization_wrapper): New static functions. (gfc_find_derived_vtab): Add _final component and call generate_finalization_wrapper. * dump-parse-tree.c (show_f2k_derived): Use resolved proc_tree-n.sym rather than unresolved proc_sym. * resolve.c (gfc_resolve_finalizers): Remove not-implemented error and ensure that the vtab exists. (resolve_fl_derived): Resolve finalizers before generating the vtab. (resolve_symbol): Also allow assumed-rank arrays with CONTIGUOUS; skip artificial symbols. (resolve_fl_derived0): Skip artificial symbols. 2012-08-19 Alessandro Fanfarillo fanfarillo@gmail.com Tobias Burnus bur...@net-b.de PR fortran/51632 * gfortran.dg/coarray_class_1.f90: New. PR fortran/37336 * gfortran.dg/coarray_poly_3.f90: Update dg-error. * gfortran.dg/auto_dealloc_2.f90: Update scan-tree-dump-times. * gfortran.dg/class_19.f03: Ditto. * gfortran.dg/finalize_4.f03: Remove dg-excess-errors for not implemented. * gfortran.dg/finalize_5.f03: Ditto. * gfortran.dg/finalize_7.f03: Ditto. diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 21a91ba..122cc43 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -34,7 +34,7 @@ along with GCC; see the file COPYING3. If not see declared type of the class variable and its attributes (pointer/allocatable/dimension/...). * _vptr: A pointer to the vtable entry (see below) of the dynamic type. - + For each derived type we set up a vtable entry, i.e. a structure with the following fields: * _hash: A hash value serving as a unique identifier for this type. @@ -42,6 +42,9 @@ along with GCC; see the file COPYING3. If not see * _extends: A pointer to the vtable entry of the parent derived type. * _def_init: A pointer to a default initialized variable of this type. * _copy: A procedure pointer to a copying procedure. +* _final:A procedure pointer to a wrapper function, which frees + allocatable components and calls FINAL subroutines. + After these follow procedure pointer components for the specific type-bound procedures. */ @@ -572,7 +575,9 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr, if (gfc_add_component (fclass, _vptr, c) == FAILURE) return FAILURE; c-ts.type = BT_DERIVED; - if (delayed_vtab) + if (delayed_vtab + || (ts-u.derived-f2k_derived + ts-u.derived-f2k_derived-finalizers)) c-ts.u.derived = NULL; else { @@ -689,6 +694,672 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_symbol *vtype) } +/* Call DEALLOCATE for the passed component if it is allocatable, if it is + neither allocatable nor a pointer but has a finalizer, call it. If it + is a nonpointer component with allocatable or finalizes components, walk + them. Either of the is required; other nonallocatables and pointers aren't + handled gracefully. + Note: The DEALLOCATE handling takes care of finalizers, coarray + deregistering and allocatable components of the allocatable. */ + +void +finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp, + gfc_expr *stat, gfc_code **code) +{ + gfc_expr *e; + e = gfc_copy_expr (expr); + e-ref = gfc_get_ref (); + e-ref-type = REF_COMPONENT; + e-ref-u.c.sym = derived; + e-ref-u.c.component = comp; + e-ts = comp-ts; + + if (comp-attr.dimension + || (comp-ts.type == BT_CLASS CLASS_DATA (comp) + CLASS_DATA (comp)-attr.dimension)) +{ + e-ref-next = gfc_get_ref (); + e-ref-next-type = REF_ARRAY; + e-ref-next-u.ar.type = AR_FULL; + e-ref-next-u.ar.dimen = 0; + e-ref-next-u.ar.as = comp-ts.type == BT_CLASS ? CLASS_DATA (comp)-as + : comp-as; + e-rank = e-ref-next-u.ar.as-rank; +} + + if (comp-attr.allocatable + || (comp-ts.type == BT_CLASS CLASS_DATA (comp) + CLASS_DATA
Re: Inheritance of gfc_symbol / gfc_component
On 18/08/2012 19:25, Tobias Schlüter wrote: I thought I could work around this problem without introducing a constructor by: 1) using 0 instead of -1 as value for this fake label (which is also not a valid value for a label, so it can't collide 2) setting ST_LABEL_FORMAT = 0 and then 3) not initializing at all, assuming that as for a C struct format_asterisk would end up in .bss and thus be zero initialized. Initialization doesn't seem to be that important after all as only the address of the variable is used. It would be safer, I think, to define the variable as a pointer with invalid (non-NULL) value. The benefit over the STL's map or a hashtable (which is better suited) is that we can traverse a tree in defined order. We use this property to write reproducible module files. Indeed. Could you post the not-yet-finished patch? Please find it attached. Note that two void* remain: gfc_{insert|delete}_bbt still need it, and I don't think there's a way around this without templates and without significantly changing the code. As I said before, I think a change needs to have a benefit. I'm disappointed by this outcome, but think this patch fails this requirement mainly because of the format_asterisk issue. I'm not so much concerned about format_asterisk (see above). My main concern is this: the increased type safety by changing the (void*) - (gfc_bbt*) change is balanced by the reduced type safety for all the types inherited from gfc_bbt as the left and right pointer have now gfc_bbt type instead of the derived type. And we better have type safety for gfc_symtree which is used all over the place. After digging some information on the web about C++ and casts, I'm not even sure the casts are correct because of the following quote from the standard: The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. This tells me we shouldn't rely on the gfc_symtree, pointer_info, etc having the same address as the corresponding gfc_bbt they derive from (unless the explicit casts add/substract the necessary offset if needed though). We're probably safe with single inheritance, but still... Mikael
Re: [wwwdocs] SH 4.8 changes update
On Sun, 2012-08-19 at 19:20 +0200, Gerald Pfeifer wrote: On Sun, 19 Aug 2012, Oleg Endo wrote: This is what has been done so far on the SH side for 4.8. I hope it's OK. Wow, that is quite impressive (and a nice write-up also)! Thanks. Let's hope that I can squeeze in some more stuff while stage 1 lasts. :T I see this was already approved, but allow me to suggest some minor editorial comments... Thanks for those! Since I've just committed the thing as it was, please find the correcting patch in the attachments. Index: htdocs/gcc-4.8/changes.html === +liThe default alignment settings have been reduced to be less aggresive. aggressive Fixed. + liMinor tweaks for code around software atomic sequences that are + enabled by code-msoft-atomic/code./li code for? Not sure... Rephrased. + liA new option code-menable-tas/code will make the compiler + generate the codetas.b/code instruction for the + code__atomic_test_and_set/code built-in function./li A naive question: Why is this not on by default? Or is it under certain circumstances? SH's tas.b insn can potentially confuse caches under certain HW configurations and result in data corruption. Moreover, it flushes the operand cache line for the variable in question and then does its thing. There might be problems when it's used together with other ways of doing atomics, so maybe it's better not to surprise people by enabling it by default. But now that you mention it, maybe it would be better to rename the '-menable-tas' option to '-mtas', since other instruction related options do not have 'enabled' in the name. +liThe codefmac/code instruction will now be emitted by the +codefmaf/code standard and built-in function./li built-in standard function, perhaps? Clarified. +liThe code-mfused-madd/code option has been depricated in favor of deprecated Fixed. +liAdded new options code-mfsrra/code and code-mfsca/code to allow +the compiler using the codefsrra/code and codefsca/code +instructions on CPUs other than SH4A./li How about adding ...SH4A (where they are already on by default) or similar? Added. OK to install? Cheers, Oleg Index: htdocs/gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.14 diff -u -r1.14 changes.html --- htdocs/gcc-4.8/changes.html 19 Aug 2012 17:16:04 - 1.14 +++ htdocs/gcc-4.8/changes.html 19 Aug 2012 18:07:37 - @@ -159,14 +159,14 @@ h3SH/h3 ul -liThe default alignment settings have been reduced to be less aggresive. +liThe default alignment settings have been reduced to be less aggressive. This results in more compact code for optimization levels other than code-Os/code./li liImproved support for the code__atomic/code built-in functions: ul - liMinor tweaks for code around software atomic sequences that are - enabled by code-msoft-atomic/code./li + liMinor improvements to code generated for software atomic sequences + that are enabled by code-msoft-atomic/code./li liA new option code-menable-tas/code will make the compiler generate the codetas.b/code instruction for the @@ -197,9 +197,10 @@ code__builtin_prefetch/code built-in function for SH3./li liThe codefmac/code instruction will now be emitted by the -codefmaf/code standard and built-in function./li +codefmaf/code standard function and the code__builtin_fmaf/code +built-in function./li -liThe code-mfused-madd/code option has been depricated in favor of +liThe code-mfused-madd/code option has been deprecated in favor of the machine-independent code-ffp-contract/code option. Notice that the codefmac/code instruction will now be generated by default for expressions like codea * b + c/code. This is due to the compiler @@ -207,7 +208,8 @@ liAdded new options code-mfsrra/code and code-mfsca/code to allow the compiler using the codefsrra/code and codefsca/code -instructions on CPUs other than SH4A./li +instructions on CPUs other than SH4A (where they are already enabled by +default)./li liAdded support for the code__builtin_bswap32/code built-in function. It is now expanded as a sequence of codeswap.b/code and
Re: Inheritance of gfc_symbol / gfc_component
Hi Mikael, On 2012-08-19 19:57, Mikael Morin wrote: My main concern is this: the increased type safety by changing the (void*) - (gfc_bbt*) change is balanced by the reduced type safety for all the types inherited from gfc_bbt as the left and right pointer have now gfc_bbt type instead of the derived type. And we better have type safety for gfc_symtree which is used all over the place. An interesting and valid point. I don't think there's a way around this without using templates (or macros). In a way, inheriting from gfc_bbt is also not really the purpose of inheritance, which is meant to express an any A is also a B relationship. An object that can be stored in a tree is not the same as the tree itself. This distinction is not made by my patch. Since my interest was purely to get an equivalent alternative to the macro magic and void*'s, I wasn't too worried about this, but it's another wart. After digging some information on the web about C++ and casts, I'm not even sure the casts are correct because of the following quote from the standard: The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. This tells me we shouldn't rely on the gfc_symtree, pointer_info, etc having the same address as the corresponding gfc_bbt they derive from (unless the explicit casts add/substract the necessary offset if needed though). We're probably safe with single inheritance, but still... To my knowledge it's perfectly valid to cast from a base class to a derived class, even though 'static_cast' would be the preferred C++ operator for the conversion. The resulting pointer may only be dereferenced if the types of the objects in memory are correct, though. The cast can take care of the issues with different offsets, multiple inheritance and so on because the compiler knows the whole class hierarchy. Anyway, all this is academic, as the patch brings no benefit IMO. Cheers, - Tobi
obstack for equiv_class_label, more vectors on stack
2012-08-19 Dimitrios Apostolou ji...@gmx.net * gcc/tree-ssa-structalias.c: Change declaration of ce_s type vector from heap to stack. Update all relevant functions to VEC_alloc() such vector upfront with enough (32) slots so that malloc() calls are mostly avoided. (equiv_class_obstack) New global static obstack for allocating struct equiv_class_label. (equiv_class_add): Use the above instead of malloc(). (perform_var_substitution): Don't allow entries of location_equiv_class_table to be freed, because they are free'd... (free_var_substitution_info): ...here by freeing the obstack. * gcc/vecir.h: Add declaration of stack allocated tree type vector. * gcc/tree-ssa-sccvn.c (vn_phi_insert, print_scc, compare_ops) (sort_scc, copy_reference, extract_and_process_scc_for_name): Use it, instead of heap allocated vector. Not all of these places are hot on the profiler, but since I changed a few I had to change them all to remove complete the heap ce_s vector. Passes tests and offers small gains (couple of ms), but expect a more thorough report and testing against a new snapshot by next week. Thanks, Dimitris2012-08-19 Dimitrios Apostolou ji...@gmx.net * gcc/tree-ssa-structalias.c: Change declaration of ce_s type vector from heap to stack. Update all relevant functions to VEC_alloc() such vector upfront with enough (32) slots so that malloc() calls are mostly avoided. (equiv_class_obstack) New global static obstack for allocating struct equiv_class_label. (equiv_class_add): Use the above instead of malloc(). (perform_var_substitution): Don't allow entries of location_equiv_class_table to be freed, because they are free'd... (free_var_substitution_info): ...here by freeing the obstack. * gcc/vecir.h: Add declaration of stack allocated tree type vector. * gcc/tree-ssa-sccvn.c (vn_phi_insert, print_scc, compare_ops) (sort_scc, copy_reference, extract_and_process_scc_for_name): Use it, instead of heap allocated vector. === modified file 'gcc/tree-ssa-structalias.c' --- gcc/tree-ssa-structalias.c 2012-08-16 14:27:51 + +++ gcc/tree-ssa-structalias.c 2012-08-18 16:43:02 + @@ -472,11 +472,14 @@ struct constraint_expr typedef struct constraint_expr ce_s; DEF_VEC_O(ce_s); -DEF_VEC_ALLOC_O(ce_s, heap); -static void get_constraint_for_1 (tree, VEC(ce_s, heap) **, bool, bool); -static void get_constraint_for (tree, VEC(ce_s, heap) **); -static void get_constraint_for_rhs (tree, VEC(ce_s, heap) **); -static void do_deref (VEC (ce_s, heap) **); +DEF_VEC_ALLOC_O_STACK(ce_s); +#define VEC_ce_s_stack_alloc(alloc) \ + VEC_stack_alloc (ce_s, alloc) + +static void get_constraint_for_1 (tree, VEC(ce_s, stack) **, bool, bool); +static void get_constraint_for (tree, VEC(ce_s, stack) **); +static void get_constraint_for_rhs (tree, VEC(ce_s, stack) **); +static void do_deref (VEC (ce_s, stack) **); /* Our set constraints are made up of two constraint expressions, one LHS, and one RHS. @@ -1893,6 +1896,9 @@ static htab_t pointer_equiv_class_table; classes. */ static htab_t location_equiv_class_table; +/* Pool of memory for storing the above */ +static struct obstack equiv_class_obstack; + /* Hash function for a equiv_class_label_t */ static hashval_t @@ -1942,7 +1948,7 @@ equiv_class_add (htab_t table, unsigned bitmap labels) { void **slot; - equiv_class_label_t ecl = XNEW (struct equiv_class_label); + equiv_class_label_t ecl = XOBNEW (equiv_class_obstack, struct equiv_class_label); ecl-labels = labels; ecl-equivalence_class = equivalence_class; @@ -2153,10 +2159,12 @@ perform_var_substitution (constraint_gra struct scc_info *si = init_scc_info (size); bitmap_obstack_initialize (iteration_obstack); + gcc_obstack_init (equiv_class_obstack); + /* NULL free function, we'll free the whole pool at the end of the pass. */ pointer_equiv_class_table = htab_create (511, equiv_class_label_hash, - equiv_class_label_eq, free); + equiv_class_label_eq, NULL); location_equiv_class_table = htab_create (511, equiv_class_label_hash, - equiv_class_label_eq, free); + equiv_class_label_eq, NULL); pointer_equiv_class = 1; location_equiv_class = 1; @@ -2263,6 +2271,7 @@ free_var_substitution_info (struct scc_i sbitmap_free (graph-direct_nodes); htab_delete (pointer_equiv_class_table); htab_delete (location_equiv_class_table); + obstack_free (equiv_class_obstack, NULL); bitmap_obstack_release (iteration_obstack); } @@ -2741,7 +2750,7 @@ new_scalar_tmp_constraint_exp (const cha If address_p is true, the result will be taken its address of. */ static
alloc_pool for tree-ssa-pre.c:phi_translate_table
2012-08-19 Dimitrios Apostolou ji...@gmx.net * gcc/tree-ssa-pre.c (phi_translate_pool): New static global alloc_pool, used for allocating struct expr_pred_trans_d for phi_translate_table. (phi_trans_add, init_pre, fini_pre): Use it, avoids thousand of malloc() and free() calls. This avoids lots of malloc/free calls and slow iterations during numerous htab_delete() in fini_pre(). Tested on pre C++-snapshot, will update info as soon as a post C++ one is available. Thanks, Dimitris2012-08-19 Dimitrios Apostolou ji...@gmx.net * gcc/tree-ssa-pre.c (phi_translate_pool): New static global alloc_pool, used for allocating struct expr_pred_trans_d for phi_translate_table. (phi_trans_add, init_pre, fini_pre): Use it, avoids thousand of malloc() and free() calls. === modified file 'gcc/tree-ssa-pre.c' --- gcc/tree-ssa-pre.c 2012-08-17 08:03:54 + +++ gcc/tree-ssa-pre.c 2012-08-18 16:43:02 + @@ -486,7 +486,7 @@ static bitmap need_ab_cleanup; /* A three tuple {e, pred, v} used to cache phi translations in the phi_translate_table. */ -typedef struct expr_pred_trans_d : typed_free_removeexpr_pred_trans_d +typedef struct expr_pred_trans_d : typed_noop_removeexpr_pred_trans_d { /* The expression. */ pre_expr e; @@ -508,6 +508,12 @@ typedef struct expr_pred_trans_d : typed } *expr_pred_trans_t; typedef const struct expr_pred_trans_d *const_expr_pred_trans_t; +/* Pool of memory for the above */ + +static alloc_pool phi_translate_pool; + +/* Return the hash value for a phi translation table entry. */ + inline hashval_t expr_pred_trans_d::hash (const expr_pred_trans_d *e) { @@ -561,7 +567,8 @@ static inline void phi_trans_add (pre_expr e, pre_expr v, basic_block pred) { expr_pred_trans_t *slot; - expr_pred_trans_t new_pair = XNEW (struct expr_pred_trans_d); + expr_pred_trans_t new_pair = +(expr_pred_trans_t) pool_alloc (phi_translate_pool); new_pair-e = e; new_pair-pred = pred; new_pair-v = v; @@ -570,7 +577,8 @@ phi_trans_add (pre_expr e, pre_expr v, b slot = phi_translate_table.find_slot_with_hash (new_pair, new_pair-hashcode, INSERT); - free (*slot); + if (*slot) +pool_free (phi_translate_pool, *slot); *slot = new_pair; } @@ -4798,6 +4806,9 @@ init_pre (bool do_fre) calculate_dominance_info (CDI_DOMINATORS); bitmap_obstack_initialize (grand_bitmap_obstack); + phi_translate_pool = create_alloc_pool (phi_translate_table, + sizeof (struct expr_pred_trans_d), + 512); phi_translate_table.create (5110); expression_to_id.create (num_ssa_names * 3); bitmap_set_pool = create_alloc_pool (Bitmap sets, @@ -4832,6 +4843,7 @@ fini_pre (bool do_fre) free_alloc_pool (bitmap_set_pool); free_alloc_pool (pre_expr_pool); phi_translate_table.dispose (); + free_alloc_pool (phi_translate_pool); expression_to_id.dispose (); VEC_free (unsigned, heap, name_to_id);
enlarge hot allocation pools
Hello, 2012-08-19 Dimitrios Apostolou ji...@gmx.net * gcc/cselib.c (cselib_init): Make allocation pools larger since they are too hot and show to expand often on the profiler. * gcc/df-problems.c (df_chain_alloc): Same. * gcc/et-forest.c (et_new_occ, et_new_tree): Same. * gcc/tree-ssa-pre.c (init_pre): Same These allocation pools are the ones that I've noticed calling malloc() too often, for expanding their size. Also I don't like the way the pools are created in et_new_{occ,tree}() but couldn't find a single point to move the initialisation either. Any ideas on this one? Thanks, Dimitris2012-08-19 Dimitrios Apostolou ji...@gmx.net * gcc/cselib.c (cselib_init): Make allocation pools larger since they are too hot and show to expand often on the profiler. * gcc/df-problems.c (df_chain_alloc): Same. * gcc/et-forest.c (et_new_occ, et_new_tree): Same. * gcc/tree-ssa-pre.c (init_pre): Same === modified file 'gcc/cselib.c' --- gcc/cselib.c2012-08-02 22:39:57 + +++ gcc/cselib.c2012-08-19 15:13:28 + @@ -2659,12 +2659,12 @@ void cselib_init (int record_what) { elt_list_pool = create_alloc_pool (elt_list, -sizeof (struct elt_list), 10); +sizeof (struct elt_list), 128); elt_loc_list_pool = create_alloc_pool (elt_loc_list, -sizeof (struct elt_loc_list), 10); +sizeof (struct elt_loc_list), 128); cselib_val_pool = create_alloc_pool (cselib_val_list, - sizeof (cselib_val), 10); - value_pool = create_alloc_pool (value, RTX_CODE_SIZE (VALUE), 100); + sizeof (cselib_val), 128); + value_pool = create_alloc_pool (value, RTX_CODE_SIZE (VALUE), 128); cselib_record_memory = record_what CSELIB_RECORD_MEMORY; cselib_preserve_constants = record_what CSELIB_PRESERVE_CONSTANTS; cselib_any_perm_equivs = false; === modified file 'gcc/df-problems.c' --- gcc/df-problems.c 2012-08-17 09:42:06 + +++ gcc/df-problems.c 2012-08-19 15:29:37 + @@ -1993,7 +1993,7 @@ df_chain_alloc (bitmap all_blocks ATTRIB { df_chain_remove_problem (); df_chain-block_pool = create_alloc_pool (df_chain_block pool, -sizeof (struct df_link), 50); +sizeof (struct df_link), 128); df_chain-optional_p = true; } === modified file 'gcc/et-forest.c' --- gcc/et-forest.c 2012-05-31 16:43:31 + +++ gcc/et-forest.c 2012-08-19 15:50:25 + @@ -444,8 +444,8 @@ et_new_occ (struct et_node *node) { struct et_occ *nw; - if (!et_occurrences) -et_occurrences = create_alloc_pool (et_occ pool, sizeof (struct et_occ), 300); + if (!et_occurrences) +et_occurrences = create_alloc_pool (et_occ pool, sizeof (struct et_occ), 1024); nw = (struct et_occ *) pool_alloc (et_occurrences); nw-of = node; @@ -467,8 +467,8 @@ et_new_tree (void *data) { struct et_node *nw; - if (!et_nodes) -et_nodes = create_alloc_pool (et_node pool, sizeof (struct et_node), 300); + if (!et_nodes) +et_nodes = create_alloc_pool (et_node pool, sizeof (struct et_node), 512); nw = (struct et_node *) pool_alloc (et_nodes); nw-data = data; === modified file 'gcc/tree-ssa-pre.c' --- gcc/tree-ssa-pre.c 2012-08-18 06:31:26 + +++ gcc/tree-ssa-pre.c 2012-08-19 15:28:21 + @@ -4812,9 +4812,9 @@ init_pre (bool do_fre) phi_translate_table.create (5110); expression_to_id.create (num_ssa_names * 3); bitmap_set_pool = create_alloc_pool (Bitmap sets, - sizeof (struct bitmap_set), 30); + sizeof (struct bitmap_set), 128); pre_expr_pool = create_alloc_pool (pre_expr nodes, -sizeof (struct pre_expr_d), 30); +sizeof (struct pre_expr_d), 32); FOR_ALL_BB (bb) { EXP_GEN (bb) = bitmap_set_new ();
Re: CXX conversion: min g++ version pre-requisite?
I filed two bug reports: GCC install document does not list minimum required g++ version http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 GCC does not build with G++ version 3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 Re: the latter bug report (54326), it might be further divided into two bug reports: one documenting the failure to build with g++ 3.4.0 and the other having to do with the use of casts in genoutput.c. Let me know if you recommend that I separate the bug reports. - Gary
Re: [PATCH][RFC] Extend memset recognition
On Tue, Jun 5, 2012 at 2:21 AM, Richard Guenther rguent...@suse.de wrote: On Thu, 31 May 2012, Richard Guenther wrote: On Wed, 30 May 2012, Richard Guenther wrote: The patch below extents memset recognition to cover a few more non-byte-size store loops and all byte-size store loops. This exposes issues with our builtins.exp testsuite which has custom memset routines like void * my_memset (void *d, int c, size_t n) { char *dst = (char *) d; while (n--) *dst++ = c; return (char *) d; } Now, for LTO we have papered over similar issues by attaching the used attribute to the functions. But the general question is - when can we be sure the function we are dealing with are not the actual implementation for the builtin call we want to generate? A few things come to my mind: 1) the function already calls the function we want to generate (well, it might be a tail-recursive memset implementation ...) 2) the function availability is AVAIL_LOCAL 3) ... ? For sure 2) would work, but it would severely restrict the transform (do we care?). We have a similar issue with sin/cos - sincos transform and a trivial sincos implementation. Any ideas? Bootstrapped (with memset recognition enabled by default) and tested on x86_64-unknown-linux-gnu with the aforementioned issues. The following fixes it by simply always adding -fno-tree-loop-distribute-patterns to builtins.exp. Bootstrapped and tested on x86_64-unknown-linux-gnu. If there are no further comments I'll go with the local advise from Micha who says who cares. Now done with the much simpler patch below (after all the loop distribution TLC). Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2012-06-05 Richard Guenther rguent...@suse.de PR tree-optimization/53081 * tree-loop-distribution.c (generate_memset_builtin): Handle all kinds of byte-sized stores. (classify_partition): Likewise. (tree_loop_distribution): Adjust seed statements used for !flag_tree_loop_distribution. * gcc.dg/tree-ssa/ldist-19.c: New testcase. * gcc.c-torture/execute/builtins/builtins.exp: Always pass -fno-tree-loop-distribute-patterns. This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 -- H.J.
Re: [PATCH, Committed] Fix ChangeLog (was: [PATCH] Fix AVR fallout)
On Sun, Aug 19, 2012 at 1:34 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote: I fixed ChangeLog's whitespace (probably cut'n'paste error), committed as obvious. 2012-08-19 Jan-Benedict Glaw jbg...@lug-owl.de * ChangeLog: Fix whitespace. Note that fixes to the ChangeLog files do not themselves get ChangeLog entries. Ian
Re: [PATCH, Committed] Fix ChangeLog (was: [PATCH] Fix AVR fallout)
On Sun, 2012-08-19 11:58:49 -0700, Ian Lance Taylor i...@google.com wrote: On Sun, Aug 19, 2012 at 1:34 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote: I fixed ChangeLog's whitespace (probably cut'n'paste error), committed as obvious. 2012-08-19 Jan-Benedict Glaw jbg...@lug-owl.de * ChangeLog: Fix whitespace. Note that fixes to the ChangeLog files do not themselves get ChangeLog entries. Fixed. Thanks for the notice, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: http://perl.plover.com/Questions.html the second : signature.asc Description: Digital signature
Re: [Patch, Fortran] PR54301 - add warning for pointer might outlive its target
Hi Tobias, Build and regtested on x86-64-gnu-linux. OK for the trunk? I would exclude pointers on the lhs of the pointer assignment, to make sure that warnings for code such as program main integer :: i integer, pointer :: ip block integer, pointer :: jp allocate (jp) jp = 3 ip = jp end block i = ip print *,i end program main are not emitted. Thomas
Re: [Patch, Fortran] PR54301 - add warning for pointer might outlive its target
Am 19.08.2012 21:19, schrieb Thomas Koenig: Build and regtested on x86-64-gnu-linux. OK for the trunk? I would exclude pointers on the lhs of the pointer assignment, I assume you mean RHS – excluding LHS pointers in pointer assignments is kind of difficult ;-) RHS pointers are excluded via: + if (gfc_option.warn_target_lifetime + rvalue-expr_type == EXPR_VARIABLE + !rvalue-symtree-n.sym-attr.save + !attr.pointer !rvalue-symtree-n.sym-attr.host_assoc the attr is set via: attr = gfc_expr_attr (rvalue); to make sure that warnings for code such as are not emitted. There is no warning with the patch. Tobias
Re: [wwwdocs] SH 4.8 changes update
On Sun, 19 Aug 2012, Oleg Endo wrote: Thanks. Let's hope that I can squeeze in some more stuff while stage 1 lasts. :T You know that for backend-specific changes (especially for smaller ports) you actually have some more leeway? But now that you mention it, maybe it would be better to rename the '-menable-tas' option to '-mtas', since other instruction related options do not have 'enabled' in the name. Now still would be time to do so without worrying about compatibility. ;-) OK to install? Oh, yes. Thanks! Gerald
Re: enlarge hot allocation pools
On Sun, Aug 19, 2012 at 8:31 PM, Dimitrios Apostolou ji...@gmx.net wrote: Hello, 2012-08-19 Dimitrios Apostolou ji...@gmx.net * gcc/cselib.c (cselib_init): Make allocation pools larger since they are too hot and show to expand often on the profiler. * gcc/df-problems.c (df_chain_alloc): Same. * gcc/et-forest.c (et_new_occ, et_new_tree): Same. * gcc/tree-ssa-pre.c (init_pre): Same These allocation pools are the ones that I've noticed calling malloc() too often, for expanding their size. I don't like the way these pools are sized with a seemingly arbitrary initial size. They're there to hold something, and they grow because there are more somethings than initially guessed. I think you should look at what the pools hold and choose an initial size based on some representative measure. E.g. if a pool holds some kind of expressions, then you should be able to make an initial guess of the size of the pool based on the number of pseudos or ssa names. Ideally you'd simply derive the initial pool size by a regression analysis of the final pool size and some potential representative measures (# of regs, basic blocks, edges, whatever). Also I don't like the way the pools are created in et_new_{occ,tree}() but couldn't find a single point to move the initialisation either. Any ideas on this one? Just create a new function to initialize (destroy) the pools and call it from calculate_dominance_info (free_dominance_info). Ciao! Steven
Re: [Patch, Fortran] PR54301 - add warning for pointer might outlive its target
Hi Tobias, Am 19.08.2012 21:19, schrieb Thomas Koenig: Build and regtested on x86-64-gnu-linux. OK for the trunk? I would exclude pointers on the lhs of the pointer assignment, I assume you mean RHS – excluding LHS pointers in pointer assignments is kind of difficult ;-) Sometimes I have a weak right-left weakness :-) RHS pointers are excluded via: ... There is no warning with the patch. OK for trunk then. You'll find your patch no longer applies cleanly, because I have changed the same spot(s) in invoke.texi and gfortran.h with my recent commit, but I think you'll manage :-) Thomas
[SH] PR 51244 - Use more zero displacement branches
Hello, This adds two new patterns to undo an optimization that is done by ifcvt and is not beneficial if zero displacement branches are available on SH. Tested on rev 190459 with make -k check RUNTESTFLAGS=--target_board=sh-sim \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb} and no new failures. OK? Cheers, Oleg ChangeLog: PR target/51244 * config/sh/sh.md (*cset_zero): New insns. testsuite/ChangeLog: PR target/51244 * gcc.target/sh/pr51244-11.c: New. Index: gcc/config/sh/sh.md === --- gcc/config/sh/sh.md (revision 190459) +++ gcc/config/sh/sh.md (working copy) @@ -10409,6 +10409,41 @@ operands[0] = gen_reg_rtx (SImode); }) +;; The *cset_zero patterns convert optimizations such as +;; if (test) x = 0; to x = -(test == 0); +;; back to conditional branch sequences if zero-displacement branches +;; are enabled. +;; FIXME: These patterns can be removed when conditional execution patterns +;; are implemented, since ifcvt will not perform these optimizations if +;; conditional execution is supported. +(define_insn *cset_zero + [(set (match_operand:SI 0 arith_reg_dest =r) + (and:SI (plus:SI (match_operand:SI 1 t_reg_operand) + (const_int -1)) + (match_operand:SI 2 arith_reg_operand 0)))] + TARGET_SH1 TARGET_ZDCBRANCH +{ + return bf 0f \n + mov #0,%0 \n + 0:; +} + [(set_attr type arith) ;; poor approximation + (set_attr length 4)]) + +(define_insn *cset_zero + [(set (match_operand:SI 0 arith_reg_dest =r) + (if_then_else:SI (match_operand:SI 1 t_reg_operand) + (match_operand:SI 2 arith_reg_operand 0) + (const_int 0)))] + TARGET_SH1 TARGET_ZDCBRANCH +{ + return bt 0f \n + mov #0,%0 \n + 0:; +} + [(set_attr type arith) ;; poor approximation + (set_attr length 4)]) + (define_expand cstoresf4 [(set (match_operand:SI 0 register_operand =r) (match_operator:SI 1 sh_float_comparison_operator Index: gcc/testsuite/gcc.target/sh/pr51244-11.c === --- gcc/testsuite/gcc.target/sh/pr51244-11.c (revision 0) +++ gcc/testsuite/gcc.target/sh/pr51244-11.c (revision 0) @@ -0,0 +1,24 @@ +/* Check that zero-displacement branches are used instead of branch-free + execution patterns. */ +/* { dg-do compile { target sh*-*-* } } */ +/* { dg-options -O1 -mzdcbranch } */ +/* { dg-skip-if { sh*-*-* } { -m5* } { } } */ +/* { dg-final { scan-assembler-not subc|and } } */ + +int* +test_00 (int* s) +{ + if (s[0] == 0) +if (!s[3]) + s = 0; + return s; +} + +int* +test_01 (int* s) +{ + if (s[0] == 0) +if (s[3]) + s = 0; + return s; +}
[SH] PR 54089 - Add support for rotcr insn
Hello, This adds support for SH's rotcr insn. Tested on rev 190459 with make -k check RUNTESTFLAGS=--target_board=sh-sim \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb} and no new failures. OK? Cheers, Oleg ChangeLog: PR target/50489 * config/sh/sh.md (rotcr, *rotcr, shar, shlr): New insns and splits. (ashrdi3_k, lshrdi3_k): Rewrite as insn_and_split. * config/sh/sh.c (sh_lshrsi_clobbers_t_reg_p): New function. * config/sh/sh-protos.h (sh_lshrsi_clobbers_t_reg_p): Declare it. testsuite/ChangeLog: PR target/50489 * gcc.target/sh/pr54089-1.c: New. Index: gcc/config/sh/sh.md === --- gcc/config/sh/sh.md (revision 190459) +++ gcc/config/sh/sh.md (working copy) @@ -3827,6 +3827,100 @@ FAIL; }) +;; The rotcr insn is used primarily in DImode right shifts (arithmetic +;; and logical). It can also be used to implement things like +;; bool t = a == b; +;; int x = (y 1) | (t 31); +(define_insn rotcr + [(set (match_operand:SI 0 arith_reg_dest =r) + (ior:SI (lshiftrt:SI (match_operand:SI 1 arith_reg_operand 0) + (const_int 1)) + (ashift:SI (match_operand:SI 2 t_reg_operand) + (const_int 31 + (set (reg:SI T_REG) + (and:SI (match_dup 1) (const_int 1)))] + TARGET_SH1 + rotcr %0 + [(set_attr type arith)]) + +;; Simplified rotcr version for combine, which allows arbitrary shift +;; amounts for the reg. If the shift amount is '1' rotcr can be used +;; directly. Otherwise we have to insert a shift in between. +(define_insn_and_split *rotcr + [(set (match_operand:SI 0 arith_reg_dest) + (ior:SI (lshiftrt:SI (match_operand:SI 1 arith_reg_operand) + (match_operand:SI 2 const_int_operand)) + (ashift:SI (match_operand:SI 3 t_reg_operand) + (const_int 31 + (clobber (reg:SI T_REG))] + TARGET_SH1 + # + can_create_pseudo_p () + [(const_int 0)] +{ + if (INTVAL (operands[2]) 1) +{ + /* use plus_constant function ?? */ + const int shift_count = INTVAL (operands[2]) - 1; + const rtx shift_count_rtx = GEN_INT (shift_count); + rtx shift_res = gen_reg_rtx (SImode); + + rtx prev_set_t_insn = NULL_RTX; + rtx tmp_t_reg = NULL_RTX; + + /* If we're going to emit a shift sequence that clobbers the T_REG, + try to find the previous insn that sets the T_REG and emit the + shift insn before that insn, to remove the T_REG dependency. + If the insn that sets the T_REG cannot be found, store the T_REG + in a temporary reg and restore it after the shift. */ + if (sh_lshrsi_clobbers_t_reg_p (shift_count_rtx) + ! sh_dynamicalize_shift_p (shift_count_rtx)) + { + prev_set_t_insn = prev_nonnote_insn_bb (curr_insn); + if (! (prev_set_t_insn != NULL_RTX + reg_set_p (get_t_reg_rtx (), prev_set_t_insn) + ! reg_referenced_p (get_t_reg_rtx (), + PATTERN (prev_set_t_insn + { + prev_set_t_insn = NULL_RTX; + tmp_t_reg = gen_reg_rtx (SImode); + emit_insn (gen_move_insn (tmp_t_reg, get_t_reg_rtx ())); + } + } + + rtx shift_rtx = gen_lshrsi3 (shift_res, operands[1], shift_count_rtx); + operands[1] = shift_res; + + /* Emit the shift insn before the insn that sets T_REG, if possible. */ + if (prev_set_t_insn != NULL_RTX) + emit_insn_before (shift_rtx, prev_set_t_insn); + else + emit_insn (shift_rtx); + + /* Restore T_REG if it has been saved before. */ + if (tmp_t_reg != NULL_RTX) + emit_insn (gen_cmpgtsi_t (tmp_t_reg, const0_rtx)); +} + + emit_insn (gen_rotcr (operands[0], operands[1], operands[3])); + DONE; +}) + +;; rotcr combine bridge pattern which will make combine try out more +;; complex patterns. +(define_insn_and_split *rotcr + [(set (match_operand:SI 0 arith_reg_dest) + (ashift:SI (match_operand:SI 1 t_reg_operand) (const_int 31)))] + TARGET_SH1 + # + 1 + [(set (match_dup 0) (match_dup 1)) + (parallel [(set (match_dup 0) + (ior:SI (lshiftrt:SI (match_dup 0) (const_int 1)) + (ashift:SI (match_dup 1) (const_int 31 + (set (reg:SI T_REG) + (and:SI (match_dup 0) (const_int 1)))])]) + ;; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ;; SImode shift left @@ -4146,6 +4240,16 @@ FAIL; }) +(define_insn shar + [(set (match_operand:SI 0 arith_reg_dest =r) + (ashiftrt:SI (match_operand:SI 1 arith_reg_operand 0) + (const_int 1))) + (set (reg:SI T_REG) + (and:SI (match_dup 1) (const_int 1)))] + TARGET_SH1 + shar %0 + [(set_attr type arith)]) + (define_insn ashrsi3_k [(set (match_operand:SI 0 arith_reg_dest =r) (ashiftrt:SI (match_operand:SI 1 arith_reg_operand 0) @@ -4233,16 +4337,22 @@ FAIL; }) -;; This should be a define_insn_and_split -(define_insn ashrdi3_k +(define_insn_and_split ashrdi3_k [(set (match_operand:DI 0 arith_reg_dest =r) (ashiftrt:DI (match_operand:DI 1 arith_reg_operand 0)
Re: [PATCH][3/n] into-SSA TLC
On Fri, Jul 27, 2012 at 5:16 AM, Richard Guenther rguent...@suse.de wrote: This tries to more clearly separate per-SSA name held information from per-DECL held information during update-ssa. We already have a global array of SSA name informations so it is pointless to have a hashtable mapping SSA names to yet another piece of information (a bitmap). This patch simply puts the bitmap into that SSA name auxiliar vector. Lifetime is managed by using a separate obstack and the aux vector age. Bootstrap and regtest pending on x86_64-unknown-linux-gnu. Richard. 2012-07-27 Richard Guenther rguent...@suse.de * tree-cfg.c (gimple_can_merge_blocks_p): Do more fine-grained check whether SSA form is not up-to-date. * tree-flow.h (name_mappings_registered_p): Remove. * tree-into-ssa.c (struct repl_map_d): Remove. (repl_tbl): Likewise. (struct ssa_name_info): Add repl_set member. (update_ssa_obstack): New static global. (get_ssa_name_ann): Initialize repl_set. (clear_ssa_name_info): Assert age did not wrap. (repl_map_hash, repl_map_eq, repl_map_free): Remove. (names_replaced_by): Adjust. (add_to_repl_tbl): Likewise. (dump_tree_ssa_stats): Likewise. (init_update_ssa): Initialize update_ssa_obstack. (delete_update_ssa): Free update_ssa_obstack. (name_mappings_registered_p): Remove. (update_ssa): Adjust. This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 -- H.J.
Re: [wwwdocs] SH 4.8 changes update
On Sun, 2012-08-19 at 21:43 +0200, Gerald Pfeifer wrote: On Sun, 19 Aug 2012, Oleg Endo wrote: Thanks. Let's hope that I can squeeze in some more stuff while stage 1 lasts. :T You know that for backend-specific changes (especially for smaller ports) you actually have some more leeway? You mean, since SH is neither a primary nor a secondary platform, there are no particular release criteria for it? What does that actually mean? But now that you mention it, maybe it would be better to rename the '-menable-tas' option to '-mtas', since other instruction related options do not have 'enabled' in the name. Now still would be time to do so without worrying about compatibility. ;-) True. Cheers, Oleg
Re: [PATCH] Combine location with block using block_locations
ping Thanks, Dehao On Tue, Aug 14, 2012 at 10:13 AM, Dehao Chen de...@google.com wrote: Hi, Dodji, Thanks for the review. I've fixed all the addressed issues. I'm attaching the related changes: Thanks, Dehao libcpp/ChangeLog: 2012-08-01 Dehao Chen de...@google.com * include/line-map.h (MAX_SOURCE_LOCATION): New value. (location_adhoc_data_init): New. (location_adhoc_data_fini): New. (get_combined_adhoc_loc): New. (get_data_from_adhoc_loc): New. (get_location_from_adhoc_loc): New. (COMBINE_LOCATION_DATA): New. (IS_ADHOC_LOC): New. (expanded_location): New field. * line-map.c (location_adhoc_data): New. (location_adhoc_data_htab): New. (curr_adhoc_loc): New. (location_adhoc_data): New. (allocated_location_adhoc_data): New. (location_adhoc_data_hash): New. (location_adhoc_data_eq): New. (location_adhoc_data_update): New. (get_combined_adhoc_loc): New. (get_data_from_adhoc_loc): New. (get_location_from_adhoc_loc): New. (location_adhoc_data_init): New. (location_adhoc_data_fini): New. (linemap_lookup): Change to use new location. (linemap_ordinary_map_lookup): Likewise. (linemap_macro_map_lookup): Likewise. (linemap_macro_map_loc_to_def_point): Likewise. (linemap_macro_map_loc_unwind_toward_spel): Likewise. (linemap_get_expansion_line): Likewise. (linemap_get_expansion_filename): Likewise. (linemap_location_in_system_header_p): Likewise. (linemap_location_from_macro_expansion_p): Likewise. (linemap_macro_loc_to_spelling_point): Likewise. (linemap_macro_loc_to_def_point): Likewise. (linemap_macro_loc_to_exp_point): Likewise. (linemap_resolve_location): Likewise. (linemap_unwind_toward_expansion): Likewise. (linemap_unwind_to_first_non_reserved_loc): Likewise. (linemap_expand_location): Likewise. (linemap_dump_location): Likewise. Index: libcpp/line-map.c === --- libcpp/line-map.c (revision 190209) +++ libcpp/line-map.c (working copy) @@ -25,6 +25,7 @@ #include line-map.h #include cpplib.h #include internal.h +#include hashtab.h static void trace_include (const struct line_maps *, const struct line_map *); static const struct line_map * linemap_ordinary_map_lookup (struct line_maps *, @@ -50,6 +51,135 @@ extern unsigned num_expanded_macros_counter; extern unsigned num_macro_tokens_counter; +/* Data structure to associate an arbitrary data to a source location. */ +struct location_adhoc_data { + source_location locus; + void *data; +}; + +/* The following data structure encodes a location with some adhoc data + and maps it to a new unsigned integer (called an adhoc location) + that replaces the original location to represent the mapping. + + The new adhoc_loc uses the highest bit as the enabling bit, i.e. if the + highest bit is 1, then the number is adhoc_loc. Otherwise, it serves as + the original location. Once identified as the adhoc_loc, the lower 31 + bits of the integer is used to index the location_adhoc_data array, + in which the locus and associated data is stored. */ + +static htab_t location_adhoc_data_htab; +static source_location curr_adhoc_loc; +static struct location_adhoc_data *location_adhoc_data; +static unsigned int allocated_location_adhoc_data; + +/* Hash function for location_adhoc_data hashtable. */ + +static hashval_t +location_adhoc_data_hash (const void *l) +{ + const struct location_adhoc_data *lb = + (const struct location_adhoc_data *) l; + return (hashval_t) lb-locus + (size_t) lb-data; +} + +/* Compare function for location_adhoc_data hashtable. */ + +static int +location_adhoc_data_eq (const void *l1, const void *l2) +{ + const struct location_adhoc_data *lb1 = + (const struct location_adhoc_data *) l1; + const struct location_adhoc_data *lb2 = + (const struct location_adhoc_data *) l2; + return lb1-locus == lb2-locus lb1-data == lb2-data; +} + +/* Update the hashtable when location_adhoc_data is reallocated. */ + +static int +location_adhoc_data_update (void **slot, void *data) +{ + *((char **) slot) += ((char *) location_adhoc_data - (char *) data); + return 1; +} + +/* Combine LOCUS and DATA to a combined adhoc loc. */ + +source_location +get_combined_adhoc_loc (source_location locus, void *data) +{ + struct location_adhoc_data lb; + struct location_adhoc_data **slot; + + linemap_assert (data); + + if (IS_ADHOC_LOC (locus)) +locus = location_adhoc_data[locus MAX_SOURCE_LOCATION].locus; + if (locus == 0 data == NULL) +return 0; + lb.locus = locus; + lb.data = data; + slot = (struct
Re: enlarge hot allocation pools
Hi Steven, On Sun, 19 Aug 2012, Steven Bosscher wrote: On Sun, Aug 19, 2012 at 8:31 PM, Dimitrios Apostolou ji...@gmx.net wrote: Hello, 2012-08-19 Dimitrios Apostolou ji...@gmx.net * gcc/cselib.c (cselib_init): Make allocation pools larger since they are too hot and show to expand often on the profiler. * gcc/df-problems.c (df_chain_alloc): Same. * gcc/et-forest.c (et_new_occ, et_new_tree): Same. * gcc/tree-ssa-pre.c (init_pre): Same These allocation pools are the ones that I've noticed calling malloc() too often, for expanding their size. I don't like the way these pools are sized with a seemingly arbitrary initial size. They're there to hold something, and they grow because there are more somethings than initially guessed. I think you should look at what the pools hold and choose an initial size based on some representative measure. E.g. if a pool holds some kind of expressions, then you should be able to make an initial guess of the size of the pool based on the number of pseudos or ssa names. Ideally you'd simply derive the initial pool size by a regression analysis of the final pool size and some potential representative measures (# of regs, basic blocks, edges, whatever). Some time ago I tried changing the pool allocator growth strategy from linear to exponential, doubling the size of the pool chunk every time it needed another chunk. It was for the exact same reason, to set the pool size according to their contents. Unfortunately I remember it didn't make a difference so I dumped it and only manually changed the important pools, which made a small difference. I'll now try deducing information on the size at runtime, thanks for the tip. Dimitris
Re: [PATCH] Fix PR 52631 (VN does not use simplified expression for lookup)
On Wed, Jul 25, 2012 at 4:39 AM, Richard Guenther richard.guent...@gmail.com wrote: On Tue, Jul 24, 2012 at 5:50 PM, Andrew Pinski andrew.pin...@caviumnetworks.com wrote: Hi, Before tuples was introduced, VN used to lookup the simplified expression to see if it was available already and use that instead of the non simplified one. This patch adds the support back to VN to do exactly that. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. I think this should be done for all RHS and SSA name LHS, not only for UNARY/BINARY/TERNARY - because even for SINGLE rhs we can end up simplifying (for REALPART_EXPR for example which we handle as nary, too). I think we constrain try_to_simplify enough so that + /* First try to lookup the simplified expression. */ + if (simplified valid_gimple_rhs_p (simplified)) + { + tree result = vn_nary_op_lookup (simplified, NULL); + if (result) + { + changed = set_ssa_val_to (lhs, result); + goto done; + } + changed = set_ssa_val_to (lhs, lhs); + vn_nary_op_insert (simplified, lhs); + } switch (get_gimple_rhs_class (code)) { case GIMPLE_UNARY_RHS: case GIMPLE_BINARY_RHS: ... should work. As you also insert the simplified variant I think we really (finally) want to have a valid_nary_op routine rather than relying on valid_gimple_rhs_p which is way too generic. I don't see valid_gimple_rhs_p being that generic as it checks to make sure the operands of the gimple are valid. Maybe I am missing something here though. Thanks, Andrew Pinski Thanks, Richard. Thanks, Andrew Pinski ChangeLog: * tree-ssa-sccvn.c (visit_use): Look up the simplified expression before visting the original one. * gcc.dg/tree-ssa/ssa-fre-9.c: Update the number of eliminatations that happen.
Re: [PATCH] Add working-set size and hotness information to fdo summary (issue6465057)
On Sat, Aug 18, 2012 at 1:19 AM, Jan Hubicka hubi...@ucw.cz wrote: +{ + cs_prg-num = cs_tprg-num; + /* Allocate the working set array for the merged summary. */ + if (ws_cnt) +{ + cs_prg-working_set_count = ws_cnt; + cs_prg-working_sets = (gcov_ws_info_t *) malloc ( + ws_cnt * sizeof (gcov_ws_info_t)); +} +} + else if (cs_prg-num != cs_tprg-num + || ws_cnt != cs_prg-working_set_count) +goto read_mismatch; + /* Copy over this run's working set information if either this is + the first run, the total size of the profile (sum_all) is much + (50%) larger for this run (need to check this before updating + cs_prg-sum_all below), or this run has a larger working + set in the largest (99.99% of sum_all) bucket. */ + if (ws_cnt + (cs_prg-runs == 1 + || (cs_tprg-sum_all + (cs_prg-sum_all + cs_prg-sum_all / 2)) + || (cs_tprg-working_sets[ws_cnt - 1].num_counters + cs_prg-working_sets[ws_cnt - 1].num_counters))) +memcpy (cs_prg-working_sets, +cs_tprg-working_sets, +ws_cnt * sizeof (gcov_ws_info_t)); cs_prg-sum_all += cs_tprg-sum_all; Hmm, when you run i.e. gcc bootstrap where the program is run couple hundred times, this will end up really inaccurate, since it will probably just store the histogram of insn-attrtab compilation, right? Well, it should store the largest working set in BBs, or one that came from a much longer run. But I see the issue you are pointing out. The num_counters (the number of hot bbs) should be reasonable, as the total number of BBs is the same between all runs, and I want to show the largest or more dominant working set in terms of the number of hot bbs. But the min_bb_counter will become more and more inaccurate as the number of runs increases, since the counter values are accumulated. I typed up a detailed email below on why getting this right would be difficult, but then I realized there might be a fairly simple accurate solution, which I'll describe first: The only way I see to do this completely accurately is to take two passes through the existing gcda files that we are merging into, one to read in all the counter values and merge them into all the counter values in the arrays from the current run (after which we can do the histogramming/working set computation accurately from the merged counters), and the second to rewrite them. In libgcov this doesn't seem like it would be too difficult to do, although it is a little bit of restructuring of the main merging loop and needs some special handling for buffered functions (which could increase the memory footprint a bit if there are many of these since they will all need to be buffered across the iteration over all the gcda files). The summary merging in coverage.c confuses me a bit as it seems to be handling the case when there are multiple program summaries in a single gcda file. When would this happen? It looks like the merge handling in libgcov should always produce a single program summary per gcda file. Why you don't simply write the histogram into gcov file and don't merge the values here (i.e. doing the cummulation loop in GCC instead of within libgcov)? That doesn't completely solve the problem, unfortunately. The reason is that you don't know which histogram entry contains a particular block each run, and therefore you don't know how to compute the new combined histogram value and index for that bb counter. For example, a particular histogram index may have 5 counters (bbs) in it for one run and 2 counters (bbs) in it for a second run, so the question is how to compute the new entry for all of those bb counters, as the 5 bbs from the first run may or may not be a superset of the 2 from the second run. You could assume that the bbs have the same relative order of hotness between runs, and combine the bb counters accordingly, but there is still some trickiness because you have to apportion the cumulative counter sum stored in the histogram entry between new entries. For example, assume the highest indexed non-zero entries (the histogram buckets containing the largest counter values) in the two incoming histograms are: histogram 1: index 100: 4 counters, cumulative value X, min counter value minx ... histogram 2: index 100: 2 counters, cumulative value Y, min counter value miny index 99: 3 counters, cumulative value W, min counter value minw ... To merge, you could assume something like 2 counters with a new cumulative value (Y +