Re: Parma Polyhedra Library 0.11.1
On 02/22/2011 06:04 AM, Dongsheng Song wrote:
When I build on i686-w64-mingw32 target:
libtool: compile: i686-w64-mingw32-g++ -DHAVE_CONFIG_H -I.
-I/home/oracle/src/ppl-0.11.1/src -I.. -I..
-I/home/oracle/src/ppl-0.11.1/src
-I/home/oracle/tmp/gcc-4.5-windows-obj/misc//include -g -O2
-frounding-math -march=x86-64 -O2 -flto -pipe -D_WIN32 -W -Wall -MT
fpu-ia32.lo -MD -MP -MF .deps/fpu-ia32.Tpo -c
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc -DDLL_EXPORT -DPIC -o
.libs/fpu-ia32.o
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc: In function 'void
Parma_Polyhedra_Library::detect_sse_unit()':
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc:52:7: error: 'NULL' was
not declared in this scope
make[3]: *** [fpu-ia32.lo] Error 1
make[3]: Leaving directory `/tmp/x/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/x/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/x'
make: *** [all] Error 2
Here is my patch:
$ git diff src/fpu-ia32.cc
diff --git a/src/fpu-ia32.cc b/src/fpu-ia32.cc
index d361411..8a2a6a2 100644
--- a/src/fpu-ia32.cc
+++ b/src/fpu-ia32.cc
@@ -30,6 +30,7 @@ site: http://www.cs.unipr.it/ppl/ . */
#include fpu.defs.hh
#includecsetjmp
#includecsignal
+#includecstddef
namespace {
Hi Dongsheng,
I don't see any occurrences of NULL in fpu-ia32.cc.
Perhaps this is a bug in the csetjmp or related header file
in your system?
And I'm doubt the assumption GMP does not support exception when cross
compiling:
$ git diff m4/ac_check_gmp.m4
diff --git a/m4/ac_check_gmp.m4 b/m4/ac_check_gmp.m4
index c5dd1c9..8c2af74 100644
--- a/m4/ac_check_gmp.m4
+++ b/m4/ac_check_gmp.m4
@@ -181,8 +181,8 @@ int main() {
ac_cv_gmp_supports_exceptions=yes,
AC_MSG_RESULT(no)
ac_cv_gmp_supports_exceptions=no,
- AC_MSG_RESULT([assuming not])
- ac_cv_gmp_supports_exceptions=no)
+ AC_MSG_RESULT([assuming yes])
+ ac_cv_gmp_supports_exceptions=yes)
gmp_supports_exceptions=${ac_cv_gmp_supports_exceptions}
if test x$gmp_supports_exceptions = xyes
How does this affect you? I mean, that setting only affects
the PPL testsuite and if you are cross-compiling you are
not using it.
All the best,
Roberto
--
Prof. Roberto Bagnara CEO CTO
Applied Formal Methods Laboratory BUGSENG srl
Department of Mathematics Parco Area delle Scienze 53/A
University of Parma, ItalyI-43124 Parma, Italy
http://www.cs.unipr.it/~bagnara/ http://bugseng.com/
mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
Re: [PPL-devel] Parma Polyhedra Library 0.11.1
On 02/22/2011 03:00 AM, Jack Howarth wrote: The problems seems to stem from the absence of pre-generated files for... ppl-user-java-interface-0.11.1-html.tar.gz ppl-user-java-interface-0.11.1.pdf ppl-user-java-interface-0.11.1.ps.gz in the doc directory of the source tarball. The fink ppl9 package builds using --with-java=$JAVA_HOME so that those missing files are autogenerated by make install. Can you post a new tarball with those missing files added? Hi Jack. You are right: this is indeed the problem. I have uploaded the missing files to the PPL 0.11 release directory. Please let us know if you have further problems. Cheers, Roberto -- Prof. Roberto Bagnara CEO CTO Applied Formal Methods Laboratory BUGSENG srl Department of Mathematics Parco Area delle Scienze 53/A University of Parma, ItalyI-43124 Parma, Italy http://www.cs.unipr.it/~bagnara/ http://bugseng.com/ mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
Re: Triplet for ARM Linux HardFP ABI, again
Guillem Jover writes: On Mon, 2011-02-21 at 17:59:06 +, Joseph S. Myers wrote: On Mon, 21 Feb 2011, Guillem Jover wrote: if you'd consider accepting something ressembling the attached patch A pre-existing condition, but in general where the code you're changing hardcodes gnu that's wrong - arm*-*-linux-uclibceabi is also meant to be valid. So if you allow a suffix here, the general form to accept consistently would be arm*-*-linux-*eabi*. Ok, so something like the attached then (again completely untested)? I've changed the ada part to just match on arm% linux% in the same way the other targets do, as there didn't seem anything GNU EABI specific in commit 8f0372dd2b828c0a0ee05dee4496a021da9cee40 (r155808). Incorrect, the ARM Ada support (which I contributed) is emphatically only for linux-gnueabi. Ada on OABI is known to have non-trivial problems (or did last time I bootstrapped it before gcc-4.4), so that combination is unsupported. Besides, OABI is obsolete.
Re: [PPL-devel] Parma Polyhedra Library 0.11.1
Great, thanks for providing these! Fang On 02/22/2011 03:00 AM, Jack Howarth wrote: The problems seems to stem from the absence of pre-generated files for... ppl-user-java-interface-0.11.1-html.tar.gz ppl-user-java-interface-0.11.1.pdf ppl-user-java-interface-0.11.1.ps.gz in the doc directory of the source tarball. The fink ppl9 package builds using --with-java=$JAVA_HOME so that those missing files are autogenerated by make install. Can you post a new tarball with those missing files added? Hi Jack. You are right: this is indeed the problem. I have uploaded the missing files to the PPL 0.11 release directory. Please let us know if you have further problems. Cheers, Roberto David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
What is __gxx_personality_sj0?
I'm trying to compile a program with a library downloaded from internet (Regular Expression implementation). I compile both my code and the library with mingw gcc 4.4.3 with no problem. When I try to link the library with my app `ld' complains about undefined references to `__gxx_personality_sj0' , `std::allocatorchar ::basic_string(std::string const)', `_Unwind_SjLj_Unregister' and some others. The error messages are many (probably hundreds). According to what I have found in the Internet these errors come when attempting to link object files compiled with different versions of gcc. But I compiled them with only one and I used the `ld' that comes with mingw.
Re: testsuite question
On Mon, Feb 21, 2011 at 10:26 PM, Christian Grössler ch...@groessler.org wrote: On 19.02.11 23:01, Richard Guenther wrote: On Sat, Feb 19, 2011 at 10:53 PM, Christian Grössler ch...@groessler.org wrote: The failures come from the assembler which complains about the out of range shift counts. Should I disable them or is there any reason unknown to me that these tests make sense? You need to make sure that the tests only invoke undefined behavior at runtime, thus emit valid assembly from your target description. Thanks. So I can simply mask the shift count to be in the supported range, or even generate a nops for the instructions, correct? Yes. Other targets simply truncate the shift count (which is usually what CPUs do when the shift count is a register). Richard. chris
Re: gcc 4.5.2 configuration issues
On 22 February 2011 06:31, Gururaj, Rao wrote: Hi, Hi, Your question is off-topic for this list, please send requests for help using or building gcc to gcc-h...@gcc.gnu.org. Please take any follow-up questions to that list, thanks. Is there any standalone gcc 4.5.2 build without the support of gmp, mpfr and mpc. I don't understand your question. Are you asking if it's possible to build gcc without those libraries? Or are you asking if there are binary builds available whichinclude those libraries? The answer to the first question is no, the answer to the second depends on which OS you are using. It is possible to build GCC so that those libraries are linked in statically, so the gcc executables don't depend on shared libraries for gmp, mpfr and mpc. Pls. let me know what features are integrated using gcc 4.5.2 to incorporate for any builds. I don't understand this question either. You can see a list of features in the 4.5 releases at http://gcc.gnu.org/gcc-4.5/changes.html (and for previous releases at http://gcc.gnu.org/gcc-4.4/changes.html and http://gcc.gnu.org/gcc-4.3/changes.html etc.)
Re: What is __gxx_personality_sj0?
On 22 February 2011 10:02, Tihomir Mitkov wrote: I'm trying to compile a program with a library downloaded from internet (Regular Expression implementation). I compile both my code and the library with mingw gcc 4.4.3 with no problem. When I try to link the library with my app `ld' complains about undefined references to `__gxx_personality_sj0' , `std::allocatorchar ::basic_string(std::string const)', `_Unwind_SjLj_Unregister' and some others. The error messages are many (probably hundreds). Your question is off-topic for this list, please send requests for help using or building gcc to gcc-h...@gcc.gnu.org. Please take any follow-up questions to that list, thanks. According to what I have found in the Internet these errors come when attempting to link object files compiled with different versions of gcc. But I compiled them with only one and I used the `ld' that comes with mingw. No, it sounds as though you're trying to use the 'gcc' program to build C++ code. That will compile the code, but will not link to the C++ runtime library, which causes the linker errors you're getting. This is documented in the manual, which you should read: http://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Invoking-G_002b_002b.html The easiest solution to your problem is probably to use 'g++' for C++ programs instead of 'gcc'
Re: Parma Polyhedra Library 0.11.1
On Tue, Feb 22, 2011 at 17:05, Roberto Bagnara bagn...@cs.unipr.it wrote:
And I'm doubt the assumption GMP does not support exception when cross
compiling:
$ git diff m4/ac_check_gmp.m4
diff --git a/m4/ac_check_gmp.m4 b/m4/ac_check_gmp.m4
index c5dd1c9..8c2af74 100644
--- a/m4/ac_check_gmp.m4
+++ b/m4/ac_check_gmp.m4
@@ -181,8 +181,8 @@ int main() {
ac_cv_gmp_supports_exceptions=yes,
AC_MSG_RESULT(no)
ac_cv_gmp_supports_exceptions=no,
- AC_MSG_RESULT([assuming not])
- ac_cv_gmp_supports_exceptions=no)
+ AC_MSG_RESULT([assuming yes])
+ ac_cv_gmp_supports_exceptions=yes)
gmp_supports_exceptions=${ac_cv_gmp_supports_exceptions}
if test x$gmp_supports_exceptions = xyes
How does this affect you? I mean, that setting only affects
the PPL testsuite and if you are cross-compiling you are
not using it.
But after the configure script done, I got the following warning:
...
config.status: executing libtool commands
configure: WARNING: CANNOT PROPAGATE EXCEPTIONS BACK FROM GMP:
*** MEMORY EXHAUSTION MAY RESULT IN ABRUPT TERMINATION.
*** This is OK, if you do not plan to use the bounded memory capabilities
*** offered by the PPL. Otherwise, if you are using GCC or the Intel C/C++
*** compiler, please make sure you use a version of GMP compiled with the
*** `-fexceptions' compiler option.
*** To build such a version, you can configure GMP as follows:
*** CPPFLAGS=-fexceptions ./configure --enable-cxx --prefix=/usr/local
Since the most gcc distro already support exceptions at default, so I think
we had better assume gmp support exceptions at default.
--
Dongsheng
Re: Parma Polyhedra Library 0.11.1
On Tue, Feb 22, 2011 at 17:05, Roberto Bagnara bagn...@cs.unipr.it wrote:
On 02/22/2011 06:04 AM, Dongsheng Song wrote:
When I build on i686-w64-mingw32 target:
libtool: compile: i686-w64-mingw32-g++ -DHAVE_CONFIG_H -I.
-I/home/oracle/src/ppl-0.11.1/src -I.. -I..
-I/home/oracle/src/ppl-0.11.1/src
-I/home/oracle/tmp/gcc-4.5-windows-obj/misc//include -g -O2
-frounding-math -march=x86-64 -O2 -flto -pipe -D_WIN32 -W -Wall -MT
fpu-ia32.lo -MD -MP -MF .deps/fpu-ia32.Tpo -c
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc -DDLL_EXPORT -DPIC -o
.libs/fpu-ia32.o
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc: In function 'void
Parma_Polyhedra_Library::detect_sse_unit()':
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc:52:7: error: 'NULL' was
not declared in this scope
make[3]: *** [fpu-ia32.lo] Error 1
make[3]: Leaving directory `/tmp/x/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/x/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/x'
make: *** [all] Error 2
Here is my patch:
$ git diff src/fpu-ia32.cc
diff --git a/src/fpu-ia32.cc b/src/fpu-ia32.cc
index d361411..8a2a6a2 100644
--- a/src/fpu-ia32.cc
+++ b/src/fpu-ia32.cc
@@ -30,6 +30,7 @@ site: http://www.cs.unipr.it/ppl/ . */
#include fpu.defs.hh
#includecsetjmp
#includecsignal
+#includecstddef
namespace {
Hi Dongsheng,
I don't see any occurrences of NULL in fpu-ia32.cc.
Perhaps this is a bug in the csetjmp or related header file
in your system?
When I use gcc 4.5 (version 4.5.3 20110221) with mingw-w64 trunk,
after preprocessing, setjmp(env) extend to _setjmp3((env), NULL) .
When I use gcc 4.6 (version 4.6.0 20110221) with mingw-w64 trunk,
after preprocessing, setjmp(env) extend to _setjmp3((env), __null) .
So gcc 4.5 run into trouble, but gcc 4.6 OK.
I don't know why and how to fix in GCC or mingw-w64, but just add
one line '#includecstddef' in the source is the simplest way.
--
Dongsheng
Can You Put Comments Into GCC Compiler Options Files?
GNU Compiler Collection Free Software Foundation 51 Franklin Street, Suite 500 Boston, MA 02110-1335 Everyone: I would like to start using the GNU Compiler Collection (GCC), particularly GFortran. Given the number of compiler and linker options that there are, it makes a lot of sense to put the commonly used compiler options into an options file. I read the description of the @file options file on page 28 of the manual, Using the GNU Compiler Collection 4.6.0. However, I could not find any information on whether comments are allowed in options files and, if so, how comments are designated so that the compiler does not attempt to treat them as compiler or linker options. Please let me know whether or not programmers can put comments into compiler options files. If so, please let me know how to designate comments. I am looking forward to hearing from you soon. Sincerely, Craig T. Dedo 17130 W. Burleigh Place P. O. Box 423 Mobile Phone: (414) 412-5869 Brookfield, WI 53008-0423 E-mail: cr...@ctdedo.com USA Linked-In: http://www.linkedin.com/in/craigdedo
glibc 2.13-4 causing kdesktop.kcrash (x86_64 only); 2.13-3 OK - right place to report?
Guys, I have stumbled onto a strange issue with glibc 2.13-4 issue on Arch Linux that only effects the Trinity desktop build on x86_64 boxes. I have confirmed this behavior on 3 different x86_64 boxes. i686 does not exhibit this behavior and downgrading to 2.13-3 fixes it. I have built glibc and libxcb with CFLAGS=$CFLAGS -g and the basic crash error I get is: #5 0x7fc401274655 in raise () from /lib/libc.so.6 #6 0x7fc401275ad6 in abort () from /lib/libc.so.6 #7 0x7fc4012ae7eb in ?? () from /lib/libc.so.6 #8 0x7fc4012b3b96 in ?? () from /lib/libc.so.6 #9 0x7fc4012b64ad in ?? () from /lib/libc.so.6 #10 0x7fc4012b8460 in malloc () from /lib/libc.so.6 #11 0x7fc3fd7fa91a in _xcb_in_read () from /usr/lib/libxcb.so.1 #12 0x7fc3fd7f8bfa in _xcb_conn_wait () from /usr/lib/libxcb.so.1 #13 0x7fc3fd7fa1af in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #14 0x7fc401b07afd in _XReply () from /usr/lib/libX11.so.6 #15 0x7fc401af1714 in XInternAtom () from /usr/lib/libX11.so.6 Full kcrash file here: http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64/kdesktop-libxcb+glibc-debug.kcrash I isolated this to glibc 2.13-4 when I started an older Arch install that still had 2.13-3 on it and there was no kdesktop crash. I then updated that Arch install to 2.13-4 and got the crash on reboot/restart of the box and Trinity. The relevant files updated on the box were: [2011-02-22 11:13] upgraded glibc (2.13-3 - 2.13-4) snip [2011-02-22 11:17] upgraded kernel26 (2.6.37-6 - 2.6.37.1-1) [2011-02-22 11:17] upgraded kernel26-headers (2.6.37-6 - 2.6.37.1-1) snip [2011-02-22 11:18] upgraded trinity-kdelibs (1220926-1 - 1222098-1) [2011-02-22 11:18] upgraded trinity-kdebase (1221507-1 - 1221588-1) I hadn't rebuilt glibc with debug on this box, so the kcrash info is a bit more sparse: http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64/kdesktop-alchemy.kcrash So then I downgraded glibc (2.13-4 - 2.13-3), restarted Trinity - perfect! No kdesktop,kcrash at all and everything was working as it should. From my first gcc bug reported, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47723, I learned it wasn't gcc at all, but an intentional change in gcc = 4.5 that required the class constructors in Trinity to be updated. Before filing, I wanted to check here to see: (1) if this is the right place for the glibc issue; and (2) if you think it is something that should be filed or whether the error points to a packaging problem or a problem with the Trinity source. With my limited glibc bug identifying knowledge, if updating glibc breaks it, downgrading glibc fixes it -- it looks like a glibc issue to me. But I know I could be completely wrong here, that's why I'm asking :p Let me know what you guys think. If you need/want anything else and I'll get it for you. Thanks. -- David C. Rankin, J.D.,P.E.
Re: glibc 2.13-4 causing kdesktop.kcrash (x86_64 only); 2.13-3 OK - right place to report?
On 02/22/2011 01:25 PM, David C. Rankin wrote: Guys, I have stumbled onto a strange issue with glibc 2.13-4 issue on Arch Linux that only effects the Trinity desktop build on x86_64 boxes. snip Let me know what you guys think. If you need/want anything else and I'll get it for you. Thanks. This is looking more like a packaging issue and not a glibc issue. (Unless you use the Fedora branch :) quote glibc 2.13-4 introduced a patch from the Fedora glibc branch that is not included in mainline glibc and fixes issues with prelink [1]. Obviously, this has some side effects. Seems like it requires some more investigation. [1] https://bugs.archlinux.org/task/22656 /quote -- David C. Rankin, J.D.,P.E.
gcc-4.4-20110222 is now available
Snapshot gcc-4.4-20110222 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110222/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 170417 You'll find: gcc-4.4-20110222.tar.bz2 Complete GCC (includes all of below) MD5=534a69bf7d77eb050943a87ffc692254 SHA1=ef90963ee5c7957d44e652eb321471bd60c547d3 gcc-core-4.4-20110222.tar.bz2C front end and core compiler MD5=3877df2a53c61243d1cf57893c50a216 SHA1=e9b7c869f4872ba4cb97d9534127200b1368a424 gcc-ada-4.4-20110222.tar.bz2 Ada front end and runtime MD5=2b34dc9e0983ac0fd4efebc71d61ddec SHA1=764351c82a0923666fcd74f6b703b8bcf91825e5 gcc-fortran-4.4-20110222.tar.bz2 Fortran front end and runtime MD5=676b9d63fb63131ac96bb442eaa01269 SHA1=1f8d5fcc42af1a56b1d4361f3c25d0c7f43f7ce6 gcc-g++-4.4-20110222.tar.bz2 C++ front end and runtime MD5=66099c5543e2c85eb671a5f31ddac2c5 SHA1=05ee578ddefcebdf23c37fa2e6b2d5ee64ad6e9a gcc-go-4.4-20110222.tar.bz2 Go front end and runtime MD5=fda710c4b19dfb661d268c1ec380735f SHA1=2e6bec1d085c3308986af015ba510357e7b15d02 gcc-java-4.4-20110222.tar.bz2Java front end and runtime MD5=85a67b3cc6e57d51c37468303fca48ad SHA1=eac1dcdbfd9fef4f552b53b83a8ac0c3f59839a7 gcc-objc-4.4-20110222.tar.bz2Objective-C front end and runtime MD5=e2721a7f0765bcf5afca3a5a5aad617e SHA1=fb84b7a84ceaf807d822c73172b2db7edc80b46d gcc-testsuite-4.4-20110222.tar.bz2 The GCC testsuite MD5=6e6b361434b159eb029a7f6894852e9e SHA1=f646663ee2a4cf0d9ae38f5f54fc0d0190a9bb1e Diffs from 4.4-20110215 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
Re: glibc 2.13-4 causing kdesktop.kcrash (x86_64 only); 2.13-3 OK - right place to report?
On 23/02/11 05:25, David C. Rankin wrote: (1) if this is the right place for the glibc issue; and No. This list is for the development of gcc. (2) if you think it is something that should be filed or whether the error points to a packaging problem or a problem with the Trinity source. Given downgrading the distributions glibc package fixed the issue, the first point of call should be me on the Arch Linux bug tracker. Allan
Re: Target deprecations for 4.6
On Mon, Feb 14, 2011 at 09:41:50AM -0800, Nathan Froyd wrote: Patch for adding score-* and crx-* to obsolete ports below. Last contact for SCORE and current crx maintainer CC'd. I have committed this patch. The crx maintainer (Pompapathi Gadad) contacted me via private mail and indicated it would be OK to obsolete the crx port. Following David and Joseph's comments, along with the lack of activity for SCORE targets for the past several years[*], I think the SCORE port is overdue. I will commit a patch to the website shortly. -Nathan [*] Though I think some of the other backends might qualify under the inactivity criterion. We can save those battles for 4.7, though...
Re: Can You Put Comments Into GCC Compiler Options Files?
Craig Dedo cr...@ctdedo.com writes: I would like to start using the GNU Compiler Collection (GCC), particularly GFortran. Given the number of compiler and linker options that there are, it makes a lot of sense to put the commonly used compiler options into an options file. I read the description of the @file options file on page 28 of the manual, Using the GNU Compiler Collection 4.6.0. However, I could not find any information on whether comments are allowed in options files and, if so, how comments are designated so that the compiler does not attempt to treat them as compiler or linker options. Please let me know whether or not programmers can put comments into compiler options files. If so, please let me know how to designate comments. This question is not appropriate for the mailing lists gcc@gcc.gnu.org or fort...@gcc.gnu.org. Please take any followups only to gcc-h...@gcc.gnu.org. In the future, please avoid cross-posting to both gcc@gcc.gnu.org and gcc-h...@gcc.gnu.org. Thanks. No comments are permitted in the contents of options files read using the @file syntax. The contents of the file are simply interpreted as command line arguments separated by whitespace. Double quotes, single quotes, and backslashes may be used in the usual way to add whitespace to arguments. Ian
Re: Can You Put Comments Into GCC Compiler Options Files?
On Tue, 22 Feb 2011 18:09:40 -0800
Ian Lance Taylor i...@google.com wrote:
No comments are permitted in the contents of options files read using
the @file syntax. The contents of the file are simply interpreted as
command line arguments separated by whitespace. Double quotes, single
quotes, and backslashes may be used in the usual way to add whitespace
to arguments.
Maybe we should change that. Do people find such a change useful for 4.7?
If yes, with what comment lexical syntax? A leading # on a line?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
[Bug lto/47841] [4.6 Regression] New guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47841 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-22 08:08:08 UTC --- And in case of FAIL: gcc.dg/guality/sra-1.c -O2 line 43 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O3 -fomit-frame-pointer line 43 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O3 -g line 43 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -Os line 43 a.j == 14 +FAIL: gcc.dg/guality/sra-1.c -O2 -flto -flto-partition=none line 43 a.j == 14 +FAIL: gcc.dg/guality/sra-1.c -O2 -flto line 43 a.j == 14 it is obviously a good thing that sra-1.c fails the same way with -flto as it does without -flto, that means -flto is less buggier wrt. -g.
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #13 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-22 08:37:13 UTC --- FWIW here's a glibc PR wrt overflowing the 26 byte limit: http://sourceware.org/bugzilla/show_bug.cgi?id=1460 This was fixed in 2005, which is a while ago, but not long enough so it's completely unimaginable that someone would want to run gfortran on such a platform. For this particular glibc issue, a workaround is to make sure the buffer is at least 33 bytes. In any case, I'm thinking that Dave's suggestion to use strftime could work. Also, in addition to the autoconf manual recommending to avoid ctime/ctime_r, POSIX 2008 also marks those as obsolescent and recommends strftime instead. strftime appears to have well defined behavior for all kinds of time input and string lengths. And, using it would obviously also solve the problem of non-standard ctime_r implementations. strftime needs localtime_r, but we have already used that one without problems for quite a while (in the implementation of the DATE_AND_TIME intrinsic) so it shouldn't cause any further portability problems. The caveat is that if using a non-default locale the output is different. In practice, (lib)gfortran never calls setlocale so unless the application explicitly calls it a gfortran program runs in the C locale, in which case a suitable choice of format string guarantees identical output as ctime(). And, if the applications does call setlocale, outputting a localized string could be seen as a feature. (In reply to comment #6) I guess the question we need to ask is how important are these routines and should we be issuing warnings when they are used, much like is done with gets. If we don't need them, I'd much prefer to see them go away as they're a rats nest of security issues. Standard Fortran, as of Fortran 2008, supports 3 time related intrinsics; DATE_AND_TIME, SYSTEM_CLOCK, and CPU_TIME. Every other time intrinsic in gfortran is due to legacy g77 support, or some other widely used extension. If one compiles with one of the standards conformance options (-std=f) these other intrinsics are not available. Personally, I'd be happy to get rid of all the nonstandard time intrinsics, but some of our users might disagree..
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-22 09:26:50 UTC --- Well, if you don't want to localize, you can as well do it yourself, call localtime_r and then simple: char result[26]; int n = snprintf (result, sizeof (result), %3.3s %3.3s%3d %.2d:%.2d:%.2d %d\n, SunMonTueWedThuFriSat + tm-tm_wday * 3, JanFebMarAprMayJunJulAugSepOctNovDec + tm-tm_mon * 3, tm-tm_mday, tm-tm_hour, tm-tm_min, tm-tm_sec, 1900 + tm-tm_year); if ((size_t) n = sizeof (result)) result[0] = '\0'; /* The result didn't fit into 26 bytes. */ (or use larger buffer, perhaps you can just snprintf into the caller provided buffer instead and depending on return value from snprintf just memset to ' ' the rest of the string if there are still any bytes left in it.
[Bug fortran/47846] New: Deferred-string length: Length is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47846
Summary: Deferred-string length: Length is wrong
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org
The test case allocate_deferred_char_scalar_1.f03 fails if one applies the
following patch. It abort in line 178:
if(len(a) /= 50) call abort()
On my system len(a) is 0
--- a/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
+++ b/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
@@ -1,4 +1,4 @@
-! { dg-do run}
+! { dg-do run }
!
! Automatic reallocate on assignment, deferred length parameter for char
!
[Bug target/47847] New: PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47847 Summary: PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: sebastian.hu...@embedded-brains.de Target: powerpc-rtems4.11-gcc Created attachment 23432 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23432 Sample code. Using the embedded 64-bit floating-point unit causes an internal compiler error in combination with the small data area: powerpc-rtems4.11-gcc -c paranoia.i -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double -mabi=spe /home/sh/rtems-sync/c/src/../../testsuites/samples/paranoia/paranoia.c: In function 'paranoia': /home/sh/rtems-sync/c/src/../../testsuites/samples/paranoia/paranoia.c:1955:1: internal compiler error: output_operand: invalid %y value, try using the 'Z' constraint
[Bug target/40959] [4.3/4.4/4.5/4.6 regression] FreeBSD/ia64 build fails: No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959 --- Comment #24 from Anton Shterenlikht mexas at bristol dot ac.uk 2011-02-22 09:41:48 UTC --- The error now is: libtool: compile: /usr/ports/lang/gcc46/work/build/./gcc/xgcc -B/usr/ports/lang/gcc46/work/build/./ gcc/ -B/usr/local/ia64-portbld-freebsd9.0/bin/ -B/usr/local/ia64-portbld-freebsd9.0/lib/ -isystem /u sr/local/ia64-portbld-freebsd9.0/include -isystem /usr/local/ia64-portbld-freebsd9.0/sys-include -DH AVE_CONFIG_H -I. -I../.././../gcc-4.6-20110212/libgfortran -iquote../.././../gcc-4.6-20110212/libgfo rtran/io -I../.././../gcc-4.6-20110212/libgfortran/../gcc -I../.././../gcc-4.6-20110212/libgfortran/ ../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-section s -g -O2 -pipe -I/usr/local/include -fno-strict-aliasing -MT backtrace.lo -MD -MP -MF .deps/backtrac e.Tpo -c ../.././../gcc-4.6-20110212/libgfortran/runtime/backtrace.c -fPIC -DPIC -o .libs/backtrace .o In file included from ../.././../gcc-4.6-20110212/libgfortran/fmain.c:4:0: ../.././../gcc-4.6-20110212/libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such f ile or directory compilation terminated. In file included from ../.././../gcc-4.6-20110212/libgfortran/runtime/backtrace.c:25:0: ../.././../gcc-4.6-20110212/libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such f ile or directory compilation terminated. gmake[3]: *** [fmain.lo] Error 1 gmake[3]: *** Waiting for unfinished jobs gmake[3]: *** [backtrace.lo] Error 1 gmake[3]: Leaving directory `/usr/ports/lang/gcc46/work/build/ia64-portbld-freebsd9.0/libgfortran' Please see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47648
[Bug c++/47488] [4.4/4.5/4.6 Regression] (sizeof|decltype) + template + string literals: ICE in write_template_arg_literal, at cp/mangle.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47488 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/47705] [4.5/4.6 Regression] internal compiler error: in convert_nontype_argument, at cp/pt.c:5006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47705 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org
[Bug middle-end/47735] [4.5/4.6 Regression] Unnecessary adjustments to stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47735 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org
[Bug lto/47841] [4.6 Regression] New guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47841 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-22 09:51:26 UTC --- Indeed. Also compare to -fwhole-file (non-LTO) guality.
[Bug middle-end/47691] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1138 with -fgraphite-identity -ffast-math -fno-tree-scev-cprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47691 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org
[Bug lto/47841] [4.6 Regression] New guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47841 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug target/40959] [4.3/4.4/4.5/4.6 regression] FreeBSD/ia64 build fails: No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959 --- Comment #25 from Gerald Pfeifer gerald at pfeifer dot com 2011-02-22 10:09:23 UTC --- (In reply to comment #24) The error now is: That's a different one, Anton. You'll need to wait for it to be resolved before we can proceed with the issue on HEAD. (I'll update lang/gcc46 in the next hours in case you are waiting for that to kick off new testing.)
[Bug fortran/47846] Deferred-string length: Length is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47846
--- Comment #1 from paul.richard.thomas at gmail dot com paul.richard.thomas
at gmail dot com 2011-02-22 10:09:57 UTC ---
Jerry,
You are not the only one :-)
Tobias, I'll take a look-see tonight.
Cheers
Paul
On Tue, Feb 22, 2011 at 10:31 AM, burnus at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47846
Summary: Deferred-string length: Length is wrong
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org
The test case allocate_deferred_char_scalar_1.f03 fails if one applies the
following patch. It abort in line 178:
if(len(a) /= 50) call abort()
On my system len(a) is 0
--- a/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
+++ b/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
@@ -1,4 +1,4 @@
-! { dg-do run}
+! { dg-do run }
!
! Automatic reallocate on assignment, deferred length parameter for char
!
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug fortran/41359] Wrong line numbers for debugging/profiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41359 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-22 10:23:17 UTC --- Author: burnus Date: Tue Feb 22 10:23:14 2011 New Revision: 170394 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170394 Log: 2011-02-22 Tobias Burnus bur...@net-b.de PR fortran/41359 * trans-stmt.c (gfc_trans_if_1): Use correct line for expressions in the if condition. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c
[Bug fortran/41359] Wrong line numbers for debugging/profiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41359 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-22 10:26:23 UTC --- FIXED on the trunk (4.6). Thanks for the report, Edouard, and sorry for needing one and a half years for fixing it.
[Bug target/40959] [4.3/4.4/4.5/4.6 regression] FreeBSD/ia64 build fails: No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959 --- Comment #26 from Anton Shterenlikht mexas at bristol dot ac.uk 2011-02-22 10:30:43 UTC --- yes, I lost track of various issues and versions.. I'll test it when you are ready. At present I'm particularly keen on testing Fortran 2003 IEEE exception handling. Many thanks for your support, Gerald.
[Bug fortran/41359] Wrong line numbers for debugging/profiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41359 --- Comment #12 from Edouard.Canot at irisa dot fr 2011-02-22 10:36:41 UTC --- On Tuesday 22 February 2011 11:26:53 you wrote: (quoting burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41359 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-22 10:26:23 UTC --- FIXED on the trunk (4.6). Thanks for the report, Edouard, and sorry for needing one and a half years for fixing it. Thanks for you, too. You are welcome. Regards, Édouard Canot
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #22 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-22 10:44:47 UTC --- At revision 170376 (comment #21), the fix of revision 170339 (comment #6) seems no longer needed on powerpc-apple-darwin9 and x86_64-apple-darwin10, i.e., after reverting revision 170339 on r170376, the tests in gcc.c-torture/execute/builtins/ and gfortran.dg/lto/ pass without failures. Thanks for the fix.
[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.22 10:47:01 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-22 10:47:01 UTC --- I think the difference is because of different initial IL from gimplification (BRANCH_COST). On x86 we have D.2701 = x != 4; D.2702 = x != 6; D.2703 = D.2701 D.2702; if (D.2703 != 0) goto D.2699; else goto D.2704; D.2704: D.2705 = x == 2; D.2706 = x == 6; D.2707 = D.2705 || D.2706; if (D.2707 != 0) goto D.2699; else goto D.2700; this is really a missed optimization in ifcombine, possibly fixed by later jump-threading for your target. The result on x86 is bb 2: D.2701_3 = x_2(D) != 4; D.2702_4 = x_2(D) != 6; D.2703_5 = D.2701_3 D.2702_4; D.2705_6 = x_2(D) == 2; D.2706_7 = x_2(D) == 6; D.2707_8 = D.2705_6 | D.2706_7; if (x_2(D) != 4) goto bb 4; else goto bb 3; bb 3: Invalid sum of incoming frequencies 400, should be 244 bb 4: Invalid sum of incoming frequencies 9844, should be 1 # D.2708_1 = PHI 1(2), -1(3) return D.2708_1; Consider XFAILing the test for your target(s).
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-22 10:51:58 UTC --- Created attachment 23433 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23433 gcc46-pr46790.patch The last mentioned variant, which instead of doing configury puts stuff into .gcc_except_table.startup.main, .gcc_except_table.exit.foo, .gcc_except_table.unlikely.bar or .gcc_except_table.hot.baz style sections. Briefly tested with the old and new linker that the testcase is fixed.
[Bug tree-optimization/47838] FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized fundamentals..0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47838
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.02.22 10:56:25
Ever Confirmed|0 |1
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-22
10:56:25 UTC ---
IVOPTs chooses (again) some unfortunate IV that is enough to confuse the
tree-dump scan.
ivtmp.6_6 = (long unsigned int) fundamentals[1];
vs.
ivtmp.6_6 = (long unsigned int) fundamentals[0];
The folding that is tested for should happen at loop header copying time.
Can you check if
Index: testsuite/gcc.dg/tree-ssa/foldconst-2.c
===
--- testsuite/gcc.dg/tree-ssa/foldconst-2.c (revision 170359)
+++ testsuite/gcc.dg/tree-ssa/foldconst-2.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 -fdump-tree-optimized } */
+/* { dg-options -O2 -fdump-tree-ch } */
typedef union tree_node *tree;
enum tree_code
{
@@ -54,5 +54,5 @@ emit_support_tinfos (void)
}
/* We should copy loop header to fundamentals[0] and then fold it way into
known value. */
-/* { dg-final { scan-tree-dump-not fundamentals.0 optimized} } */
-/* { dg-final { cleanup-tree-dump optimized } } */
+/* { dg-final { scan-tree-dump-not fundamentals.0 ch} } */
+/* { dg-final { cleanup-tree-dump ch } } */
works for you (it does for me) and commit it if so?
Thanks.
[Bug fortran/47648] libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such file or directory - FreeBSD ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47648 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-22 10:57:48 UTC --- STATUS: - libgfortran uses the same check as libquadmath; thus, there should be no build issue anymore as libquadmath support is disabled for libgfortran. (The Fortran FE still can generate calls for REAL(16).) - The issue that on FreeBSD libquadmath is not supported remains unsolved. The problem is that some support (_U_Q*) is missing. The support could come either from FreeBSD's libc or from libgcc. Cf. bug 47649 comment 5.
[Bug target/47842] gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.22 10:58:29 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-22 10:58:29 UTC --- forces? GCC re-aligns the stack if it thinks it is a good idea for performance. Or do you mean something else? Please be more specific.
[Bug target/47842] gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2011-02-22 11:06:41 UTC --- A 16-byte aligned stack is still word aligned.
[Bug target/47751] Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe -Os on PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47751 --- Comment #3 from Sebastian Huber sebastian.hu...@embedded-brains.de 2011-02-22 11:18:29 UTC --- (In reply to comment #2) -mfloat-gprs=double or -mspe without -mabi=spe does not correspond to any standard ABI variant and is very likely to be broken. Thanks for the hint. Adding the -mabi=spe option fixed the problem. A notice in the -mfloat-gprs description of the documentation would be nice.
[Bug fortran/47839] ICE in dwarf2out.c:add_AT_specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47839
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-22
11:46:04 UTC ---
I think this also hints at possible DECL issues with imported vars. You can
see how the C frontend handles the function/block local externs around
c-decl.c:1206
else if (VAR_OR_FUNCTION_DECL_P (p))
{
/* For block local externs add a special
DECL_EXTERNAL decl for debug info generation. */
tree extp = copy_node (p);
...
The following fixes the testcase for me (not further tested):
Index: gcc/fortran/f95-lang.c
===
--- gcc/fortran/f95-lang.c (revision 170359)
+++ gcc/fortran/f95-lang.c (working copy)
@@ -498,13 +498,20 @@ poplevel (int keep, int reverse, int fun
tree
pushdecl (tree decl)
{
- /* External objects aren't nested, other objects may be. */
- if (DECL_EXTERNAL (decl))
-DECL_CONTEXT (decl) = NULL_TREE;
- else if (global_bindings_p ())
+ if (global_bindings_p ())
DECL_CONTEXT (decl) = current_translation_unit;
else
-DECL_CONTEXT (decl) = current_function_decl;
+{
+ /* External objects aren't nested. For debug info insert a copy
+ of the decl into the binding level. */
+ if (DECL_EXTERNAL (decl))
+ {
+ tree orig = decl;
+ decl = copy_node (decl);
+ DECL_CONTEXT (orig) = NULL_TREE;
+ }
+ DECL_CONTEXT (decl) = current_function_decl;
+}
/* Put the declaration on the list. The list of declarations is in reverse
order. The list will be reversed later if necessary. This needs to be
there might be still multiple backend-decls for USE associated vars in
different subroutines (they should share a single global one).
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #23 from Mike Stump mikestump at comcast dot net 2011-02-22 11:53:56 UTC --- I am confused, both Iain and myself still see failures on ppc even with my patch. Iain said they were dying on BUILT_IN_SQRTL. I can't debug, as I'm using rosetta, and apparently debugging no longer works. :-( Odd. [ long pause ] Truly, odd, I just updated and removed that hunk from comment #6, and presto, the testcase that failed for me earlier, now works. I did do a restrap this time to try and avoid more uncleanliness.
[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47822 --- Comment #24 from Mike Stump mikestump at comcast dot net 2011-02-22 11:56:37 UTC --- Iain reports it is fixed for him as well... :-)
[Bug fortran/47839] ICE in dwarf2out.c:add_AT_specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47839
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-debug
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-22
12:01:03 UTC ---
With the patch and
MODULE PEC_mod
CONTAINS
SUBROUTINE PECapply(Ex)
USE globalvar_mod, ONLY : xstop
real(kind=8), dimension(1:xstop), intent(inout) :: Ex
write(*,*) xstop
END SUBROUTINE PECapply
SUBROUTINE PECapply2(Ex)
USE globalvar_mod, ONLY : xstop
real(kind=8), dimension(1:xstop), intent(inout) :: Ex
write(*,*) xstop
END SUBROUTINE PECapply2
END MODULE PEC_mod
you see
pecapply2 (real(kind=8)[0:] * restrict ex)
{
extern integer(kind=4)D.8 xstopD.1540;
{
struct __st_parameter_dt dt_parm.0D.1539;
dt_parm.0D.1539.commonD.1458.filenameD.1355 = t.f90[1]{lb: 1 sz: 1};
dt_parm.0D.1539.commonD.1458.lineD.1356 = 11;
dt_parm.0D.1539.commonD.1458.flagsD.1353 = 128;
dt_parm.0D.1539.commonD.1458.unitD.1354 = 6;
_gfortran_st_write (dt_parm.0D.1539);
_gfortran_transfer_integer_write (dt_parm.0D.1539, xstopD.1538, 4);
_gfortran_st_write_done (dt_parm.0D.1539);
}
}
pecapply (real(kind=8)[0:] * restrict ex)
{
{
struct __st_parameter_dt dt_parm.1D.1543;
dt_parm.1D.1543.commonD.1458.filenameD.1355 = t.f90[1]{lb: 1 sz: 1};
dt_parm.1D.1543.commonD.1458.lineD.1356 = 6;
dt_parm.1D.1543.commonD.1458.flagsD.1353 = 128;
dt_parm.1D.1543.commonD.1458.unitD.1354 = 6;
_gfortran_st_write (dt_parm.1D.1543);
_gfortran_transfer_integer_write (dt_parm.1D.1543, xstopD.1538, 4);
_gfortran_st_write_done (dt_parm.1D.1543);
}
}
which is half-way sane (same backend-decl used for the actual USE
associated variable). But still the 2nd function misses the copy
in its BLOCK tree, so I guess if that function would be nested
in another that has a local of the same name gdb would confuse
references to the USE associated vars with that of the local
parent function decl like with
MODULE PEC_mod
CONTAINS
SUBROUTINE test
integer :: xstop,xbar
write(*,*) xstop
CONTAINS
SUBROUTINE PECapply(Ex)
USE globalvar_mod, ONLY : xstop
real(kind=8), dimension(1:xstop), intent(inout) :: Ex
write(*,*) xstop,xbar
END SUBROUTINE PECapply
END SUBROUTINE test
SUBROUTINE PECapply2(Ex)
USE globalvar_mod, ONLY : xstop
real(kind=8), dimension(1:xstop), intent(inout) :: Ex
write(*,*) xstop
END SUBROUTINE PECapply2
END MODULE PEC_mod
remains to a more Fortran affine person to verify the above wrong-debug
idea with gdb. The key is
pecapply (real(kind=8)[0:] * restrict ex)
{
{
struct __st_parameter_dt dt_parm.1D.1545;
dt_parm.1D.1545.commonD.1458.filenameD.1355 = t.f90[1]{lb: 1 sz: 1};
dt_parm.1D.1545.commonD.1458.lineD.1356 = 10;
dt_parm.1D.1545.commonD.1458.flagsD.1353 = 128;
dt_parm.1D.1545.commonD.1458.unitD.1354 = 6;
_gfortran_st_write (dt_parm.1D.1545);
_gfortran_transfer_integer_write (dt_parm.1D.1545, xstopD.1535, 4);
_gfortran_transfer_integer_write (dt_parm.1D.1545, xbarD.1546, 4);
_gfortran_st_write_done (dt_parm.1D.1545);
}
}
(no extern integer(kind=4)D.8 xstopD.1537; here) and in the parent:
test ()
{
integer(kind=4)D.8 xbarD.1546;
integer(kind=4)D.8 xstopD.1547;
static voidD.27 pecapplyD.1541 (real(kind=8)D.18[0:] * restrict);
{
struct __st_parameter_dt dt_parm.2D.1548;
dt_parm.2D.1548.commonD.1458.filenameD.1355 = t.f90[1]{lb: 1 sz: 1};
dt_parm.2D.1548.commonD.1458.lineD.1356 = 5;
dt_parm.2D.1548.commonD.1458.flagsD.1353 = 128;
dt_parm.2D.1548.commonD.1458.unitD.1354 = 6;
_gfortran_st_write (dt_parm.2D.1548);
_gfortran_transfer_integer_write (dt_parm.2D.1548, xstopD.1547, 4);
_gfortran_st_write_done (dt_parm.2D.1548);
}
}
we have integer(kind=4)D.8 xstopD.1547 which shadows the global xstop
from the module.
[Bug libfortran/47830] errors in intrinsics/c99_functions.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47830 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-22 12:37:16 UTC --- Author: burnus Date: Tue Feb 22 12:37:12 2011 New Revision: 170396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170396 Log: 2011-02-22 Tobias Burnus bur...@net-b.de Kai-Uwe Eckhardt kue...@gmx.de PR libfortran/47830 * intrinsics/c99_functions.c (roundl): Make C valid for HAVE_NEXTAFTERL. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/c99_functions.c
[Bug libfortran/47830] errors in intrinsics/c99_functions.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47830 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-22 12:41:57 UTC --- Author: burnus Date: Tue Feb 22 12:41:54 2011 New Revision: 170397 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170397 Log: 2011-02-22 Tobias Burnus bur...@net-b.de Kai-Uwe Eckhardt kue...@gmx.de PR libfortran/47830 * intrinsics/c99_functions.c (roundl): Make C valid for HAVE_NEXTAFTERL. Modified: branches/gcc-4_5-branch/libgfortran/ChangeLog branches/gcc-4_5-branch/libgfortran/intrinsics/c99_functions.c
[Bug libfortran/47830] errors in intrinsics/c99_functions.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47830 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-22 12:43:42 UTC --- Author: burnus Date: Tue Feb 22 12:43:38 2011 New Revision: 170398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170398 Log: 2011-02-22 Tobias Burnus bur...@net-b.de Kai-Uwe Eckhardt kue...@gmx.de PR libfortran/47830 * intrinsics/c99_functions.c (roundl): Make C valid for HAVE_NEXTAFTERL. Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/intrinsics/c99_functions.c
[Bug libfortran/47830] errors in intrinsics/c99_functions.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47830 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 2011-02-22 12:44:20 UTC --- FIXED on the trunk (4.6) and on the 4.4 and 4.5 branches. Thanks for the report!
[Bug fortran/47845] [OOP] Polymorphic deferred function: Not matched class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47845 --- Comment #2 from KePu Kdx1999 at gmail dot com 2011-02-22 12:54:10 UTC --- Thank you for respond this issue, I have modified the definition of vec:). But it seems that only the first argument can be set to subclass of vec, the other must be strictly set to vec, so the additional coordinate z can't be used in newly overriding procedures.
[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-22 12:55:45 UTC --- Created attachment 23434 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23434 gcc46-pr47835.patch I guess instead of XFAILing it is better just to check the end result, whether tree passes optimized this into x != 4 test in the end or not. And they actually do (with the exception of x86_64/i686 and maybe other targets before PR46909 fix). For ppc ifcombine only optimizes x != 6 || x == 2 into x != 6 (that's why it reports that it optimized two comparisons into x != 6), the reason why it doesn't optimize further is that x == 6 check has two preds, one is x != 4 x != 6 and the other one is !(x != 4) (one edge has moved from x == 2 check to x == 6 during vrp1). dom manages to optimize it though.
[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-22 12:56:54 UTC --- I've tested this patch on x86_64, i686, ppc and ppc64 linux with PR46909 gimple-fold.c change reverted and with vanilla gimple-fold, with the fix reverted expectedly x86_64 and i686 gcc.dg/pr46909.c test failed.
[Bug middle-end/45819] [4.5 Regression] unexpected unaligned access to volatile int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45819 --- Comment #7 from Atsushi Nemoto anemo at mba dot ocn.ne.jp 2011-02-22 13:04:10 UTC --- (In reply to comment #5) arm-linux-gnueabi-gcc-4.6.0-20101124 works fine (generates ldr instruction), It seems that was a side-effect of -fstrict-volatile-bitfields which was enabled by default on ARM EABI. With -fno-strict-volatile-bitfields, arm-linux-gnueabi-gcc-4.6.0-20110222 generates four ldrb instructions.
[Bug target/39570] cabs and cabsf are named differently on NetBSD 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||cato at df dot lth.se
--- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-22
13:25:53 UTC ---
I just checked
CC the one of the two NetBSD maintainers who has been last active...
* * *
CVS_RSH=ssh cvs -d anon...@anoncvs.netbsd.org:/cvsroot co src/lib/libm/
and libm/compat contains only compat_cabsf and compat_cabs.c, which use a
struct instead of complex. That those are the only math-related changes, one
sees if on greps for __RENAME in
CVS_RSH=ssh cvs -d anon...@anoncvs.netbsd.org:/cvsroot co src/include/
i.e. complex.h contains:
#ifndef __LIBM0_SOURCE__
/* avoid conflict with historical cabs(struct complex) */
double cabs(double complex) __RENAME(__c99_cabs);
float cabsf(float complex) __RENAME(__c99_cabsf);
#endif
* * *
Regarding the patch (cf. comment 3): Darwin has the files darwin.c in
./gcc/config/, which is included via ./gcc/config.gcc's
tm_p_file=${tm_p_file} darwin-protos.h
target_gtfiles=\$(srcdir)/config/darwin.c
extra_objs=darwin.o
One probably needs to do likewise for *-*-netbsd*).
In darwin.c, see darwin_patch_builtins and darwin_patch_builtin.
Those are used via SUBTARGET_INIT_BUILTINS in some ./gcc/config/* files.
[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-22 13:40:27 UTC --- Author: jakub Date: Tue Feb 22 13:40:24 2011 New Revision: 170399 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170399 Log: PR tree-optimization/47835 * gcc.dg/pr46909.c: Check optimized dump instead of ifcombine. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr46909.c
[Bug tree-optimization/47835] FAIL: gcc.dg/pr46909.c scan-tree-dump ifcombine optimizing two comparisons to x_[0-9]+\(D\) != 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47835 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-22 13:41:53 UTC --- Should be fixed now.
[Bug middle-end/47663] Very simple wrapper not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47663 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-22 13:47:18 UTC --- Author: rguenth Date: Tue Feb 22 13:47:15 2011 New Revision: 170400 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170400 Log: 2011-02-22 Richard Guenther rguent...@suse.de PR tree-optimization/47663 * cgraph.h (struct cgraph_edge): Add call_stmt_size and call_stmt_time fields. (cgraph_edge_inlinable_p): Declare. (cgraph_edge_recursive_p): New inline function. * cgraph.c (cgraph_create_edge_1): Initialize call_stmt_size. (cgraph_clone_edge): Copy it. * ipa-inline.c (cgraph_estimate_edge_time): New function. Account for call stmt time. (cgraph_estimate_time_after_inlining): Take edge argument. (cgraph_estimate_edge_growth): Account call stmt size. (cgraph_estimate_size_after_inlining): Take edge argument. (cgraph_mark_inline_edge): Adjust. (cgraph_check_inline_limits): Likewise. (cgraph_recursive_inlining_p): Remove. (cgraph_edge_badness): Use cgraph_edge_recursive_p. (cgraph_decide_recursive_inlining): Take edge argument and adjust. (cgraph_decide_inlining_of_small_functions): Do not avoid diags for recursive inlining here. (cgraph_flatten): Adjust. (cgraph_decide_inlining_incrementally): Likewise. (estimate_function_body_sizes): Remove call cost handling. (compute_inline_parameters): Initialize caller edge call costs. * tree-inline.c (estimate_num_insns): Only account for call return value if it is used. (expand_call_inline): Avoid diagnostics on recursive inline functions here. * lto-cgraph.c (lto_output_edge): Output edge call costs. (input_edge): Input edge call costs. * gcc.dg/tree-ssa/inline-8.c: New testcase. 2011-02-22 Richard Guenther rguent...@suse.de * ipa-inline.c (cgraph_estimate_edge_growth): New function. (cgraph_estimate_growth): Use it. (cgraph_edge_badness): Likewise. (cgraph_check_inline_limits): Take an edge argument. (cgraph_decide_inlining_of_small_functions): Adjust. (cgraph_decide_inlining): Likewise. Added: branches/pretty-ipa/gcc/testsuite/ChangeLog.pretty-ipa branches/pretty-ipa/gcc/testsuite/gcc.dg/tree-ssa/inline-8.c Modified: branches/pretty-ipa/gcc/ChangeLog.pretty-ipa branches/pretty-ipa/gcc/cgraph.c branches/pretty-ipa/gcc/cgraph.h branches/pretty-ipa/gcc/ipa-inline.c branches/pretty-ipa/gcc/lto-cgraph.c branches/pretty-ipa/gcc/tree-inline.c
[Bug fortran/47845] [OOP] Polymorphic deferred function: Not matched class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47845 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-22 13:50:24 UTC --- (In reply to comment #2) Thank you for respond this issue, I have modified the definition of vec:). But it seems that only the first argument can be set to subclass of vec, the other must be strictly set to vec, so the additional coordinate z can't be used in newly overriding procedures. You could use GENERIC to generate different versions of vec - and make the two argument version set z == 0. (Similar to GENERIC :: OPERATOR(+) but for type-bound procedures.) Are there other issues in the bug report? From comment 0 it is a bit unclear to me what the issue is - besides the non-issue mentioned in comment 1. If there is no issue left, I would like to close this problem report (PR). * * * For general Fortran questions, I would recommend the comp.lang.fortran news group which is available on *any* (net) news server. It is also available via Google, but they do not filter spam - thus, your university's or ISP's server should be preferred. Cf. also http://groups.google.com/group/comp.lang.fortran/ For specific gfortran question, the fortran mailing list at http://gcc.gnu.org/lists.html
[Bug web/47848] New: invalid -ftree-loop-if-convert-memory-writes flag is mentioned at two places (instead of -ftree-loop-if-convert-stores)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47848 Summary: invalid -ftree-loop-if-convert-memory-writes flag is mentioned at two places (instead of -ftree-loop-if-convert-stores) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: s...@gcc.gnu.org It seems -ftree-loop-if-convert-memory-writes was renamed to -ftree-loop-if-convert-stores short before the commit, but -ftree-loop-if-convert-memory-writes is still mentioned at: gcc/doc/invoke.texi (only in the summary) http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html (is this auto-generated?)
[Bug fortran/47844] I/O: data transfer statement: Array stride ignored for pointer-valued function results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47844
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Summary|Pointer-valued function:|I/O: data transfer
|Provide wrong result when |statement: Array stride
|dereferenced automatically |ignored for pointer-valued
|after list-write|function results
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-22
14:45:42 UTC ---
Paul, I added you as you are a tad more familiar with the scalarizer than I am.
* * *
Slightly simplified test case:
integer, target :: tgt(5) = [1,2,3,4,5]
integer, pointer :: ptr(:)
print *, f(tgt)
contains
function f(x)
integer, target :: x(:)
integer, pointer :: f(:)
f = x(::2)
end function f
end
While f correctly sets the stride, it is ignored by the PRINT statement;
-fdump-tree-original shows:
f (atmp.8, D.1566);
[...]
D.1579 = (*(integer(kind=4)[0:] * restrict) atmp.8.data)[S.9];
_gfortran_transfer_integer_write (dt_parm.5, D.1579, 4);
}
S.9 = S.9 + 1;
The last line should be S.9 = S.9 + atmp.8.stride, which gets correctly set by
f().
Thus, one needs to teach the scalarizer that the stride does not have to be
always 1 for SS_FUNCTION, though the only case I currently can come up with are
array-valued pointer-returning functions. I think one should consider adding a
is_pointer_result:1 to gfc_ss, which could be set in gfc_walk_function_expr.
The scalarizers are set up via gfc_trans_transfer. The 1 setting seems to
happen in gfc_conv_ss_startstride:
case GFC_SS_CONSTRUCTOR:
case GFC_SS_FUNCTION:
for (n = 0; n ss-data.info.dimen; n++)
{
ss-data.info.start[n] = gfc_index_zero_node;
ss-data.info.end[n] = gfc_index_zero_node;
ss-data.info.stride[n] = gfc_index_one_node;
}
break;
At some point, it needs to be modified for array-pointer-returning functions; I
think that should happen in gfc_conv_loop_setup
[Bug target/47831] avoid if-convertion if the conditional instructions and following conditional branch has the same condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47831 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.22 14:50:03 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.6.0 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-22 14:50:03 UTC --- Confirmed on r170278 of trunk. The better sequence that Carrot mentions comes from having if-conversion disabled (-fno-if-conversion2). I expect Basic Block Reordering might be able to help out in the case where if-conversion is enabled, but I think it is still disabled for -Os, as it can sometimes lead to larger code. That is a separate issue though. To tackle this properly, the if-conversion heuristic would need to be enhanced to detect cases where the codesize will likely increase and pessimise against those cases when using -Os.
[Bug fortran/47552] CTIME: Valgrind warning depends on uninitialised value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47552 --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-22 15:34:57 UTC --- This seems to be because the libgfortran implementation uses gfc_charlen_type for the length of the string, but the frontend passes the address of an integer(8) variable. As a quick and dirty test, changing the libgfortran implementation to use long removes the valgrind errors on x86_64. Though the correct fix is to change the frontend to create a variable of the correct type. If not before, perhaps something to fix when/if we change to use size_t for string lengths, see http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
[Bug target/47847] PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47847 --- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de 2011-02-22 15:55:29 UTC --- Adding the -mspe (in addition to -mabi=spe) option helped. It seems that only few combinations of the -mcpu=8520, -mfloat-gprs=*, -mspe, and -mabi=spe flags are well tested in GCC. The following combinations worked: (1) -mcpu=8540 -msoft-float (2) -mcpu=8540 -mspe -mabi=spe -mfloat-gprs=single (3) -mcpu=8540 -mspe -mabi=spe -mfloat-gprs=double
[Bug tree-optimization/47849] New: ICE: SIGSEGV in find_edge (cfganal.c:491) with -ftree-loop-if-convert -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47849 Summary: ICE: SIGSEGV in find_edge (cfganal.c:491) with -ftree-loop-if-convert -fno-tree-reassoc Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: s...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23435 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23435 reduced testcase Compiler output: $ gcc -O2 -ftree-loop-if-convert -fno-tree-reassoc testcase.ctestcase.c: In function 'foo': testcase.c:2:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 find_edge (pred=0x75bf2138, succ=0x0) at /mnt/svn/gcc-trunk/gcc/cfganal.c:491 #1 0x00986bd1 in remove_dead_stmt (i=0x7fffd6a0, bb=0x75bf2138) at /mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1102 #2 0x009870f9 in eliminate_unnecessary_stmts () at /mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1203 #3 0x0098957f in perform_tree_ssa_dce (aggressive=1 '\001') at /mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1450 #4 0x007f6e86 in execute_one_pass (pass=0x178ee30) at /mnt/svn/gcc-trunk/gcc/passes.c:1556 #5 0x007f7185 in execute_pass_list (pass=0x178ee30) at /mnt/svn/gcc-trunk/gcc/passes.c:1611 #6 0x007f7197 in execute_pass_list (pass=0x163bd80) at /mnt/svn/gcc-trunk/gcc/passes.c:1612 #7 0x00939fd6 in tree_rest_of_compilation (fndecl=0x75b86f00) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #8 0x00b01e82 in cgraph_expand_function (node=0x75ba6000) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1576 #9 0x00b045ca in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1635 #10 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1899 #11 0x00b04b4a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1096 #12 0x0050974c in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9872 #13 0x008e2f78 in compile_file (argc=15, argv=0x7fffda68) at /mnt/svn/gcc-trunk/gcc/toplev.c:591 #14 do_compile (argc=15, argv=0x7fffda68) at /mnt/svn/gcc-trunk/gcc/toplev.c:1900 #15 toplev_main (argc=15, argv=0x7fffda68) at /mnt/svn/gcc-trunk/gcc/toplev.c:1963 #16 0x76446bbd in __libc_start_main () from /lib/libc.so.6 #17 0x004f02fd in _start () Tested revisions: r170398 - crash
[Bug c++/45383] [4.5 Regression] Implicit conversion to pointer does no longer automatically generate operator== and operator!=.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45383 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Summary|[4.5/4.6 Regression]|[4.5 Regression] Implicit |Implicit conversion to |conversion to pointer does |pointer does no longer |no longer automatically |automatically generate |generate operator== and |operator== and operator!=. |operator!=. --- Comment #8 from Dodji Seketeli dodji at gcc dot gnu.org 2011-02-22 16:14:59 UTC --- Fixed in 4.6
[Bug tree-optimization/47849] ICE: SIGSEGV in find_edge (cfganal.c:491) with -ftree-loop-if-convert -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47849 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.6.0 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2011-02-22 16:17:09 UTC --- Originally, it failed with: (testcase is testsuite/gcc.target/i386/avx-vpcmpistri-1.c) $ gcc -O2 -mavx -ftree-loop-if-convert -fno-tree-reassoc avx-vpcmpistri-1.i avx-vpcmpistri-1.i: In function 'cmp_flags.constprop.1': avx-vpcmpistri-1.i:5573:1: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1064 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x117f638 /mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c, line=1064, function=0x117fd60 forward_edge_to_pdom) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892 #1 0x00986ec6 in forward_edge_to_pdom (i=0x7fffd670, bb=0x77f32548) at /mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1064 #2 remove_dead_stmt (i=0x7fffd670, bb=0x77f32548) at /mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1113 #3 0x009870f9 in eliminate_unnecessary_stmts () at /mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1203 #4 0x0098957f in perform_tree_ssa_dce (aggressive=1 '\001') at /mnt/svn/gcc-trunk/gcc/tree-ssa-dce.c:1450 #5 0x007f6e86 in execute_one_pass (pass=0x178ee30) at /mnt/svn/gcc-trunk/gcc/passes.c:1556 #6 0x007f7185 in execute_pass_list (pass=0x178ee30) at /mnt/svn/gcc-trunk/gcc/passes.c:1611 #7 0x007f7197 in execute_pass_list (pass=0x163bd80) at /mnt/svn/gcc-trunk/gcc/passes.c:1612 #8 0x00939fd6 in tree_rest_of_compilation (fndecl=0x75819e00) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:422 #9 0x00b01e82 in cgraph_expand_function (node=0x75916b00) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1576 #10 0x00b045ca in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1635 #11 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1899 #12 0x00b04b4a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1096 #13 0x0050974c in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9872 #14 0x008e2f78 in compile_file (argc=16, argv=0x7fffda38) at /mnt/svn/gcc-trunk/gcc/toplev.c:591 #15 do_compile (argc=16, argv=0x7fffda38) at /mnt/svn/gcc-trunk/gcc/toplev.c:1900 #16 toplev_main (argc=16, argv=0x7fffda38) at /mnt/svn/gcc-trunk/gcc/toplev.c:1963 #17 0x76446bbd in __libc_start_main () from /lib/libc.so.6 #18 0x004f02fd in _start () The backtrace is very similiar, so it is probably the same problem. Apart from that, running testsuite with -ftree-loop-if-convert -fno-tree-reassoc resulted in ~177 exec failures - it is probably already reported as PR47770.
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-02/msg01453.htm ||l Last reconfirmed||2011.02.22 16:21:09 AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #15 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-22 16:21:09 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01453.html
[Bug other/44032] internals documentation is not legally safe to use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032 --- Comment #2 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-02-22 16:33:34 UTC --- Joern, since the GFDL says: If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software. it ought not be controversial to add a statement that examples of code in the internals manual are also released under the GPL. I'd advise preparing a patch adding a statement to the effect that You can redistribute and/or modify examples of program code in this manual under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version. and sending the patch to RMS for legal review as well as gcc-patches for technical review.
[Bug other/44035] internals documentation cannot be fixed without new GFDL license grants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44035 --- Comment #1 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-02-22 16:41:27 UTC --- Joern, after discussion with Mark and Richi my advice at this point on the GFDL issue is that you should prepare a concrete patch that moves all the text you want from both code and documentation to its ideal places in target.def, and send that patch - including the changes to the generated file tm.texi - to RMS for legal review (asking explicitly for approval of GFDL licensing of the changes to tm.texi and of GPL licensing for the changes to target.def) as well as to gcc-patches for technical review. That way at least RMS is faced with questions relating to licensing of fixed bodies of text under existing licenses - though the exercise would need repeating in future (maybe once per major release) after more target macros become hooks - rather than general abstract questions needing new dual-licensing notices. And in the past it's been much easier to get him to approve changes in concrete cases (e.g. licensing of longlong.h). It may be worth pointing out in the mail to RMS that the text describing macros in tm.texi (pre-GFDL, under a non-GPL copyleft) used to be routinely duplicated in comments (GPL) on individual definitions of those macros, so having this sort of text under the GPL as well as a documentation license is nothing new.
[Bug fortran/47850] New: [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850
Summary: [4.6 Regression] ICE in gfc_conv_array_initializer
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
The following program is based on James' program at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/625faf82578e9af8
The only difference is that I replaced (*) by the bounds as otherwise one
cannot compile it with 4.5.
$ gfortran-4.5 test.f90 ./a.out
SENSOR_CHANNEL = 10, 12, 17, 20, 22, 30, 33, 34
NLTE_CHANNEL = 20, 22, 34
N_NLTE_CHANNELS = 3
N_CHANNELS =8
C_INDEX = 0, 0, 0, 1, 2, 0, 0, 3
$ gfortran-4.6 test.f90 ./a.out
test.f90: In function ‘cindex’:
test.f90:23:0: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:4576
That's gfc_conv_array_initializer's
switch (expr-expr_type)
{
[...]
default:
gcc_unreachable ();
Where:
(gdb) p expr-expr_type
$1 = EXPR_FUNCTION
(gdb) p expr-value.function.isym-name
$4 = 0x2ab42858 unpack
Thus, for some reason the unpack has not been simplified in 4.6.
program Cindex
implicit none
integer,parameter :: SENSOR_CHANNEL(8) =
[10,12,17,20,22,30,33,34]
integer,parameter :: NLTE_CHANNEL(3) = [20,22,34]
integer,parameter :: N_NLTE_CHANNELS = size(NLTE_CHANNEL)
integer,parameter :: N_CHANNELS = size(SENSOR_CHANNEL)
integer i
integer,parameter :: C_INDEX(8) = unpack(
vector = [(i,i=1,size(SENSOR_CHANNEL))],
mask = [(any(SENSOR_CHANNEL(i) == NLTE_CHANNEL),
i=lbound(SENSOR_CHANNEL,1),ubound(SENSOR_CHANNEL,1))],
field = 0)
character(20) fmt
write(fmt,'(a,i0,a)') '(a,t19,',size(SENSOR_CHANNEL),'(i3:,))'
write(*,fmt) 'SENSOR_CHANNEL = ',SENSOR_CHANNEL
write(fmt,'(a,i0,a)') '(a,t19,',size(NLTE_CHANNEL),'(i3:,))'
write(*,fmt) 'NLTE_CHANNEL = ',NLTE_CHANNEL
write(*,'(a,t19,i3)') 'N_NLTE_CHANNELS = ',N_NLTE_CHANNELS
write(*,'(a,t19,i3)') 'N_CHANNELS = ',N_CHANNELS
write(fmt,'(a,i0,a)') '(a,t19,',size(C_INDEX),'(i3:,))'
write(*,fmt) 'C_INDEX = ',C_INDEX
end program Cindex
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.6.0
[Bug middle-end/47790] [4.5/4.6 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47790
--- Comment #2 from Jeffrey A. Law law at redhat dot com 2011-02-22 17:09:36
UTC ---
A couple early comments.
First, it appears that it's never possible to get into this code via the old
path where SRC is a binary operation of some sort. This is presumably an
artifact of how we handle expansion.
If I understand your change correctly, you're walking the use-def chain when
SRC is an SSA_NAME in the hopes of finding a suitable binary operation to set
SRC. After that, you can just let the original code from
optimize_bitfield_assignment_op do its thing.
I found this fragment somewhat odd, what's its purpose?
+ if (TREE_CODE (op0) == SSA_NAME)
+{
+ gimple op0stmt = get_gimple_for_ssa_name (op0);
+ if (!op0stmt || !is_gimple_assign (op0stmt) || gimple_assign_rhs_code
(op0stmt) != TREE_CODE (to) )
+return false;
+ op0 = gimple_assign_rhs1 (op0stmt);
+}
At this point OP0 is the RHS1 of the statement which set SRC via binary
operator.
Second, the original code stripped nops from OP0. Is there some reason you
don't do that? It probably doesn't matter, but you might be missing some
optimization opportunities as a result.
From peeking at the testcase, if we could handle the case where SRC is a
typecast which is fed by a binary operation, we might have many more
opportunities to optimize. I guess that should be considered extra credit.
[Bug web/47848] invalid -ftree-loop-if-convert-memory-writes flag is mentioned at two places (instead of -ftree-loop-if-convert-stores)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47848 --- Comment #1 from Sebastian Pop spop at gcc dot gnu.org 2011-02-22 17:36:38 UTC --- Author: spop Date: Tue Feb 22 17:36:34 2011 New Revision: 170411 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170411 Log: Fix PR47848: Do not mention -ftree-loop-if-convert-memory-writes. 2011-02-22 Sebastian Pop sebastian@amd.com PR doc/47848 * doc/invoke.texi: Do not mention -ftree-loop-if-convert-memory-writes. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug web/47848] invalid -ftree-loop-if-convert-memory-writes flag is mentioned at two places (instead of -ftree-loop-if-convert-stores)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47848 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Sebastian Pop spop at gcc dot gnu.org 2011-02-22 17:38:12 UTC --- Fixed.
[Bug c++/47851] New: [4.6 Regression] [C++0x] Incorrect decltype result for conditional operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47851
Summary: [4.6 Regression] [C++0x] Incorrect decltype result for
conditional operator
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mimomo...@gmail.com
Created attachment 23436
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23436
Test case
Suppose we have a code
struct Type {};
typedef Type const ConstType;
struct ConvertibleToType {
operator Type() { return *reinterpret_castType*(this); }
};
Then expression `true ? ConvertibleToType() : ConstType()` has type `Type`.
But `decltype(true ? ConvertibleToType() : ConstType())` is `Type const`.
Note that, in gcc 4.5, both the type of the expression and its `decltype` are
`Type`.
(In clang TOT, both are `Type const`.)
[Bug c++/47851] [4.6 Regression] [C++0x] Incorrect decltype result for conditional operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47851 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-22 18:04:47 UTC --- Let's ask Jason to have a look.
[Bug objc/47832] [4.6 Regression] ObjC errors on structures with flexible data members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47832 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2011-02-22 18:31:43 UTC --- Resolved in trunk (4.6). Thanks
[Bug fortran/45743] [4.6 Regression] gfortran.dg/whole_file_3.f90 ICE: verify_stmts failed: invalid conversion in gimple call with -finline-small-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45743 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | --- Comment #3 from Paul Thomas pault at gcc dot gnu.org 2011-02-22 19:17:43 UTC --- Created attachment 23437 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23437 A fix for the PR This has already been submitted to the list. Cheers Paul
[Bug target/47842] gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 --- Comment #3 from Yuri yuri at tsoft dot com 2011-02-22 19:23:45 UTC --- If gcc would only set 16 byte alignment this wouldn't be that bad since, as you mentioned, it is still word aligned. The problem is that gcc assumes that stack is 16 aligned and creates code based on this. For example it places instruction like this 'movdqa %xmm0, 0x10(%esp)' which assumes 16 byte alignment. As a result, gcc compiled procedure crashes when called by ABI compliant code. gcc can't assume 16 byte alignment.
[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836 --- Comment #2 from th.r.klein at web dot de 2011-02-22 19:39:27 UTC --- For example a microcontroller do not need to have any kind of standard C-Library files or its header files. So it is not possible to build e.g. zlib or libiberty for this target platforms. Additional I might to take a decision not to build this library, even if it is possible to build it. The build process failed here.
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #16 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-22 19:43:10 UTC --- Patch using the fbuf_getc approach: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01475.html
[Bug c++/47666] [4.6 Regression] ICE in dfs_walk_once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47666 --- Comment #3 from Dodji Seketeli dodji at gcc dot gnu.org 2011-02-22 19:53:16 UTC --- Author: dodji Date: Tue Feb 22 19:53:13 2011 New Revision: 170413 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170413 Log: Fix PR c++/47666 gcc/cp/ PR c++/47666 * class.c (dfs_declare_virt_assop_and_dtor) (declare_virt_assop_and_dtor): New static functions. (add_implicitly_declared_members): Use declare_virt_assop_and_dtor. gcc/testsuite/ PR c++/47666 * g++.dg/inherit/virtual7.C: New test. Added: trunk/gcc/testsuite/g++.dg/inherit/virtual7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47666] [4.6 Regression] ICE in dfs_walk_once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47666 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Dodji Seketeli dodji at gcc dot gnu.org 2011-02-22 19:59:01 UTC --- Fixed in trunk (4.6).
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #16 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-22 20:24:13 UTC --- Patch which should hopefully fix the getpwuid_r issue on HP-UX 10.2: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01478.html
[Bug fortran/45743] [4.6 Regression] gfortran.dg/whole_file_3.f90 ICE: verify_stmts failed: invalid conversion in gimple call with -finline-small-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45743 --- Comment #4 from Paul Thomas pault at gcc dot gnu.org 2011-02-22 20:33:48 UTC --- Author: pault Date: Tue Feb 22 20:33:45 2011 New Revision: 170414 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170414 Log: 2011-02-22 Paul Thomas pa...@gcc.gnu.org PR fortran/45743 * trans-decl.c (gfc_get_extern_function_decl): Don't use the gsymbol backend_decl if the procedure has a formal argument that is a procedure. 2011-02-22 Paul Thomas pa...@gcc.gnu.org PR fortran/45743 * gfortran.dg/whole_file_32.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_32.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug driver/47852] New: crash with g++ -lpthread on irix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47852
Summary: crash with g++ -lpthread on irix
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bugzilla-...@thewrittenword.com
CC: r...@cebitec.uni-bielefeld.de
Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
Build: mips-sgi-irix6.5
gcc-4.4.5 on IRIX 6.5 produces an executable that crashes at runtime if
-lpthread appears before -lstdc++ on the link line.
% echo 'int main() {}' a.cpp
% g++ a.cpp -lpthread -pthread; ./a.out; echo $?
zsh: segmentation fault (core dumped) ./a.out
139
See also the discussion here:
http://gcc.gnu.org/ml/gcc-help/2011-02/msg00335.html
http://gcc.gnu.org/ml/gcc-help/2011-02/msg00368.html
[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.22 22:28:10 Ever Confirmed|0 |1 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-02-22 22:28:10 UTC --- I meant how does it fail? For example a microcontroller do not need to have any kind of standard C-Library files or its header files. I don't think that is true. Most targets even microcontrollers one have a standard C library. Also how are you configuring GCC? If you really only want GCC and libgcc, the easiest way to do that is: make all-gcc make all-target-libgcc make install-gcc make install-target-libgcc
[Bug fortran/47853] New: Assignment of integer to pointer compiles, and a.out segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47853 Summary: Assignment of integer to pointer compiles, and a.out segfaults Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: this...@gmail.com Created attachment 23438 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23438 Source code to trigger the error Shell trace: % gfortran -v test.f08 Driving: gfortran -mmacosx-version-min=10.6.6 -v test.f08 -lgfortran -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.1/lto-wrapper Target: x86_64-apple-darwin10.3.0 Configured with: ../gcc-4_5-branch/configure --prefix=/usr/local/gfortran --enable-languages=c,c++,fortran --with-gmp=/Users/fx/devel/gcc/ibin45/../irun45 --enable-bootstrap --with-included-gettext --with-arch=nocona --with-tune=generic Thread model: posix gcc version 4.5.1 20100506 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-shared-libgcc' '-mtune=generic' '-march=nocona' /usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.1/f951 test.f08 -fPIC -quiet -dumpbase test.f08 -mmacosx-version-min=10.6.6 -mtune=generic -march=nocona -auxbase test -version -fintrinsic-modules-path /usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1/finclude -o /var/folders/9P/9PFGWXR+FHWaXgjuUM4v5U+++TU/-Tmp-//ccQWPLn5.s GNU Fortran (GCC) version 4.5.1 20100506 (prerelease) (x86_64-apple-darwin10.3.0) compiled by GNU C version 4.5.1 20100506 (prerelease), GMP version 4.3.1, MPFR version 2.4.2-p2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.5.1 20100506 (prerelease) (x86_64-apple-darwin10.3.0) compiled by GNU C version 4.5.1 20100506 (prerelease), GMP version 4.3.1, MPFR version 2.4.2-p2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-shared-libgcc' '-mtune=generic' '-march=nocona' as -arch x86_64 -force_cpusubtype_ALL -o /var/folders/9P/9PFGWXR+FHWaXgjuUM4v5U+++TU/-Tmp-//cca9YzEf.o /var/folders/9P/9PFGWXR+FHWaXgjuUM4v5U+++TU/-Tmp-//ccQWPLn5.s COMPILER_PATH=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.1/:/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.1/:/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/ LIBRARY_PATH=/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1/:/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1/../../../:/usr/lib/ COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-shared-libgcc' '-mtune=generic' '-march=nocona' /usr/local/gfortran/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.6.6 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.5.o -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1 -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin10.3.0/4.5.1/../../.. /var/folders/9P/9PFGWXR+FHWaXgjuUM4v5U+++TU/-Tmp-//cca9YzEf.o -lgfortran -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-shared-libgcc' '-mtune=generic' '-march=nocona' % ./a.out 21766: signal: sys: segmentation violation
[Bug fortran/47853] Assignment of integer to pointer compiles, and a.out segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47853 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-02-22 22:57:15 UTC --- Basically you are accessing p before pointing it to anything.
[Bug fortran/47853] Assignment of integer to pointer compiles, and a.out segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47853 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #2 from Harald Anlauf anlauf at gmx dot de 2011-02-22 23:01:49 UTC --- You need to allocate p before use to get a valid program. Like: integer, target :: a integer, pointer :: p = NULL () allocate (p) p = a ! should be = p = 1 end Regarding the assignment p = a, please read an introduction to Fortran. It is valid code when p is associated.
[Bug fortran/47853] Assignment of integer to pointer compiles, and a.out segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47853 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||INVALID --- Comment #3 from kargl at gcc dot gnu.org 2011-02-22 23:13:22 UTC --- This is a programming mistake on the programmer. A fortran compiler is not required to diagnose such errors. Try compiling your code with -Wall. It shows a warning (well actually two warnings because the program contains a tab character where a space is expected), which should give enough information to be concerned.
[Bug fortran/47853] Assignment of integer to pointer compiles, and a.out segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47853 --- Comment #4 from rodneyp at physics dot uq.edu.au 2011-02-22 23:52:01 UTC --- Sorry - you're right. In the original code, p and a were arrays. The assignment p = a was still legal, but less obviously.
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #11 from Jie Zhang jiez at gcc dot gnu.org 2011-02-23 00:25:38 UTC --- Author: jiez Date: Wed Feb 23 00:25:34 2011 New Revision: 170422 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170422 Log: PR rtl-optimization/47763 * web.c (web_main): Ignore naked clobber when replacing register. testsuite/ PR rtl-optimization/47763 * gcc.dg/pr47763.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr47763.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/web.c
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 Jie Zhang jiez at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #12 from Jie Zhang jiez at gcc dot gnu.org 2011-02-23 00:27:15 UTC --- Fixed.
[Bug c++/47242] [C++0x] ICE: tree check: expected field_decl, have error_mark in build_lambda_object, at cp/semantics.c:7604 on invalid lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47242 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-02-23 00:37:46 UTC --- Author: paolo Date: Wed Feb 23 00:37:43 2011 New Revision: 170423 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170423 Log: /cp 2011-02-22 Paolo Carlini paolo.carl...@oracle.com PR c++/47242 * semantics.c (build_lambda_object): Bail out if a field is error_mark_node. /testsuite 2011-02-22 Paolo Carlini paolo.carl...@oracle.com PR c++/47242 * g++.dg/cpp0x/lambda/lambda-ice4.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug debug/47106] -fcompare-debug failure (length) with -fpartial-inlining -flto -fconserve-stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47106 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #18 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-02-23 00:37:50 UTC --- Fixed
[Bug c++/47242] [C++0x] ICE: tree check: expected field_decl, have error_mark in build_lambda_object, at cp/semantics.c:7604 on invalid lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47242 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-23 00:38:52 UTC --- Fixed.
