Re: Problem while configuring gcc3.2
2009/12/28 Pardis Beikzadeh: Hi, This question should be asked on the gcc-help mailing list, not this one. I'm having a problem while installing gcc3.2. I'm trying to install gcc3.2 for my installation of cygwin because anything higher than that won't work if I try to compile mex files for Matlab. Unfortunately when I try to configure gcc3.2 (before getting to the bootstrap step), I get an error because no proper cc is found. This is of course because I uninstalled my gcc3.4 in order to install gcc3.2 from scratch according to the suggestion in the email below from the gcc mailing list. Could you please tell me how to solve this problem? I don't see any suggestion in the mail you quoted that says to uninstall gcc3.4 I suggest you don't uninstall gcc3.4 and instead configure gcc3.2 so it installs to a different path. That way you will have two versions installed in separate locations. Where can I get an installation of cc that will work with gcc3.2? It seems like I'm stuck with a chicken and egg problem because it seems like I need gcc before I can install gcc. Also 'make bootstrap' doesn't work without running configure, so I'm not sure what the recommended way mentioned in the email below means. It means following the usual installation instructions given on the gcc website, which say to run configure first. Once you've configured you can run 'make bootstrap'
Re: AVR gives weird error with LTO
Andrew Hutchinson wrote: When AVR target is built, without explicitly disabling LTO, it will produce 1000's of testsuite failures of -LTO -WHOPR tests with this compilation error: ld: -f may not be used without -shared Any idea what is wrong or how to make LTO work correctly here? The standard way to be proceed would be: add -v to the command-line in the PR; find out what is actually getting passed to ld; figure out what kind of specs-processing accident (most likely) is causing ld to receive a -f option. cheers, DaveK
Re: AVR gives weird error with LTO
I used v and progressed a little The problem seems to be that linker is called with -fwhopr or -flto as command line option. ld -fwhopr . Linker find '-f' and complains. I assume this is not a valid option for ld? Or is my linker wrong version or something? Note this is cross compile toolchain. Andy Dave Korn wrote: Andrew Hutchinson wrote: When AVR target is built, without explicitly disabling LTO, it will produce 1000's of testsuite failures of -LTO -WHOPR tests with this compilation error: ld: -f may not be used without -shared Any idea what is wrong or how to make LTO work correctly here? The standard way to be proceed would be: add -v to the command-line in the PR; find out what is actually getting passed to ld; figure out what kind of specs-processing accident (most likely) is causing ld to receive a -f option. cheers, DaveK
Re: AVR gives weird error with LTO
Andrew Hutchinson wrote: I used v and progressed a little The problem seems to be that linker is called with -fwhopr or -flto as command line option. ld -fwhopr . Linker find '-f' and complains. I assume this is not a valid option for ld? Or is my linker wrong version or something? It's not a valid option for ld. It *is* a valid option for the collect2 driver/wrapper executable that gcc uses to invoke ld, which suggests to me that the AVR port must be configured not to build collect2, but that it is going to need to do so if it wants to use LTO/WHOPR. See use_collect2 in gcc/config.gcc cheers, DaveK
Re: target hooks / plugins
On Thu, Dec 24, 2009 at 1:32 AM, Joern Rennecke amyl...@spamcop.net wrote: Quoting Joern Rennecke amyl...@spamcop.net: Right now, to make a new target hook, you have to add a new field in target.h, define a new default in target-def.h, place the new macro in exactly the right position there of the right initializer macro, describe the new hook in tm.texi, and if you need a new function with a bunch of parameters returning a constant, you have to add this to hooks.c . I would like to be able to do all this by adding a single entry in a new definition file; and the information should also be usable by plugin sources so that they can automatically make wrappers for all function-type hooks. I've attached what I have so far. There is an issue that the struct gcc_target member names don't always agree with the TARGET_* macro names. Should I rather change one or the other to make them agree, or add an extra parameter in the definition file macros to specify these names independently? I didn't look at the patch yet but I'd simply change one or the other to make the names consistent. Richard.
Re: ping^2 [rfc][patch] Document RETURN_EXPR better
On Sat, Dec 26, 2009 at 1:14 AM, Jerry Quinn jlqu...@optonline.net wrote: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00690.html [cc'ing gcc since it might be the better forum for this] Ok. Thanks, Richard.
Re: Unnecessary PRE optimization
On Sat, Dec 26, 2009 at 2:07 AM, Daniel Berlin dber...@dberlin.org wrote: In general it will be tricky for latter passes to clean up the messes. The fundamental problem is that the address computation is exposed to PRE prematurely (for a given target ) at GIMPLE level. Yeah, i'm not sure PRE can really do anything different here. I also think you would have a very hard time trying to stop everything from moving invariant computations around at the tree level. Might make more sense to finish the tree level with a global code motion pass that is target sensitive or something. And you also need to deal with the case where the address computation is already commoned in the original source. Btw, a optimization option to trigger fwprop and initializing it differently for different targets would work for me as a temporary workaround (not that this address cost issue is new ...) Richard.
Re: AVR gives weird error with LTO
It's not a valid option for ld. It *is* a valid option for the collect2 driver/wrapper executable that gcc uses to invoke ld, which suggests to me that the AVR port must be configured not to build collect2, but that it is going to need to do so if it wants to use LTO/WHOPR. See use_collect2 in gcc/config.gcc Or you could port gold to AVR and use the plugin :-) cheers, DaveK Cheers, -- Rafael Ávila de Espíndola
Re: AVR gives weird error with LTO
Rafael Espindola wrote: It's not a valid option for ld. It *is* a valid option for the collect2 driver/wrapper executable that gcc uses to invoke ld, which suggests to me that the AVR port must be configured not to build collect2, but that it is going to need to do so if it wants to use LTO/WHOPR. See use_collect2 in gcc/config.gcc Or you could port gold to AVR and use the plugin :-) I hadn't checked, but yeah, since AVR is an ELF platform, that's a nice solution too. There might still be reason to build a collect2, for interop with older binutils. cheers, DaveK
Re: AVR gives weird error with LTO
Dave Korn wrote: Rafael Espindola wrote: It's not a valid option for ld. It *is* a valid option for the collect2 driver/wrapper executable that gcc uses to invoke ld, which suggests to me that the AVR port must be configured not to build collect2, but that it is going to need to do so if it wants to use LTO/WHOPR. See use_collect2 in gcc/config.gcc Or you could port gold to AVR and use the plugin :-) I hadn't checked, but yeah, since AVR is an ELF platform, that's a nice solution too. There might still be reason to build a collect2, for interop with older binutils. cheers, DaveK Thank you David and Rafel I will dig further into collect2. I had noted that avr.h has the following: /* This is undefined macro for collect2 disabling */ #define LINKER_NAME ld Also, the MINGW host is the most significant for the AVR target - and problems with collect2 may be related to maintaining compatibility to that. Andy
Re: AVR gives weird error with LTO
On Thu, Dec 31, 2009 at 12:04 AM, Andrew Hutchinson andrewhutchin...@cox.net wrote: Dave Korn wrote: Rafael Espindola wrote: It's not a valid option for ld. It *is* a valid option for the collect2 driver/wrapper executable that gcc uses to invoke ld, which suggests to me that the AVR port must be configured not to build collect2, but that it is going to need to do so if it wants to use LTO/WHOPR. See use_collect2 in gcc/config.gcc Or you could port gold to AVR and use the plugin :-) I hadn't checked, but yeah, since AVR is an ELF platform, that's a nice solution too. There might still be reason to build a collect2, for interop with older binutils. cheers, DaveK Thank you David and Rafel I will dig further into collect2. I had noted that avr.h has the following: /* This is undefined macro for collect2 disabling */ #define LINKER_NAME ld That's indeed going to break LTO. Richard. Also, the MINGW host is the most significant for the AVR target - and problems with collect2 may be related to maintaining compatibility to that. Andy
Re: AVR gives weird error with LTO
Thank you David and Rafel I will dig further into collect2. I had noted that avr.h has the following: /* This is undefined macro for collect2 disabling */ #define LINKER_NAME ld That's indeed going to break LTO. Richard. That seems to be the key issue. Without #define LINKER_NAME, AVR is running LTO/WHOPR tests ok ! (No idea if it does anything useful though) Now to figure out why it was added in 2000 (rth). Hopefully Eric Weddington or Denis might have some idea and perhaps know if it still has a purpose. Andy
RE: AVR gives weird error with LTO
-Original Message- From: Andrew Hutchinson [mailto:andrewhutchin...@cox.net] Sent: Wednesday, December 30, 2009 4:34 PM To: Richard Guenther Cc: Dave Korn; Rafael Espindola; GCC Development; Weddington, Eric; Denis Chertykov Subject: Re: AVR gives weird error with LTO Thank you David and Rafel I will dig further into collect2. I had noted that avr.h has the following: /* This is undefined macro for collect2 disabling */ #define LINKER_NAME ld That's indeed going to break LTO. Richard. That seems to be the key issue. Without #define LINKER_NAME, AVR is running LTO/WHOPR tests ok ! (No idea if it does anything useful though) Now to figure out why it was added in 2000 (rth). Hopefully Eric Weddington or Denis might have some idea and perhaps know if it still has a purpose. That was before my time. I didn't get involved (peripherally) until 2002. So it's either Denis Chertykov or Marek Michalkiewicz (CCed). Eric Weddington
RE: target hooks / plugins
Hi Joseph, cTuning-discussions is an open public mailing list - I have been moderating lots of spam there recently and mixed up some settings but it is fixed now ... Cheers, Grigori -Original Message- From: Joseph Myers [mailto:jos...@codesourcery.com] Sent: Thursday, December 24, 2009 1:26 PM To: Joern Rennecke Cc: 'GCC Mailing List'; Grigori Fursin; 'Yuanjie Huang'; 'Liang Peng'; 'Zbigniew Chamski'; 'Yuri Kashnikoff'; 'Diego Novillo' Subject: Re: target hooks / plugins It appears you CC:ed your message to a closed mailing list ctuning-discussi...@googlegroups.com that bounces messages from non-subscribers. Please avoid doing this; messages to public lists should not be CC:ed to any list that will send bounces or other automatic replies to non-subscribers. You are free to forward GCC list messages manually to such a list, of course. -- Joseph S. Myers jos...@codesourcery.com
[Bug middle-end/42099] Error in 64-bit division for 32-bit target
--- Comment #6 from jakub at gcc dot gnu dot org 2009-12-30 09:02 --- IMHO such a wrong-code should be fixed also on 4.4/4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #22 from nospamname at web dot de 2009-12-30 09:39 ---
There is no m68k-amigaos support in
FSF GCC and I don't think there ever has been.
There is support for m68k-amigaos in FSF GCC.
search in gcc source for name amigaos and on changelog.lib you find this
Wed Sep 10 15:14:20 1997 Jeffrey A Law (l...@cygnus.com)
* config.sub: Use amigaos instread of amigados. Still
recognize amigados for backward compatibility.
Sun Sep 7 23:18:32 1997 Fred Fish f...@ninemoons.com
* INSTALL: Change 'amigados' to 'amigaos' to match current usage.
* install.texi (Configurations): Likewise.
* config.sub: Likewise.
In file configure you find more.
Now seem m68k-amigaos should remove, where is decicde if a target is remove or
not ?
---
But its true that amigaos cant build without changes from FSF GCC
configfiles.But there are no C or C++ source changes need.
I fear to submit the changes, not that m68k-amigaos get remove, because the
amiga OS change offical to PPC CPU since 7 years, but the PPC amigaos is not on
FSF GCC and they have only old compilers
m68k-amigaos is still used today and new programs are written with GCC 4.5.0
and there are users that use it
See here the uploads of the last 14 days.The yellow Symbol is m68k-amigaos
http://aminet.net/
To get m68k-amigaos compile is very easy, so i compile actual compiler and when
a problem occur we try to find it near and report it.We verify very carefully,
because we know a wrong bugreport increase the risc that m68k-amigaos os maybe
remove.
To get amigaos compile i have a small readme text file, that explain the steps
what lines must add to the configure files of Gcc and the platform specific
files that need copy and work always because of the GGC backend API
add in gcc-x.x.x/gcc/config.gcc
(search for m68k)
m68k-*-amigaos*)
tmake_file=m68k/t-amigaos
tm_file=${tm_file} m68k/amigaos.h
tm_p_file=${tm_p_file} m68k/amigaos-protos.h
tm_defines=TARGET_AMIGAOS TARGET_DEFAULT=0 # 68040
extra_objs=amigaos.o
gnu_ld=yes
;;
in gcc-x.x.x/gcc/config/m68k dir add files (from the 4.3.2 source)
amigaos.h
amigaos.c
t-amigaos
x-amigaos
xm-amigaos.h
amigaos-protos.h
host-amigaos.c
in dir gcc-x.x.x//gcc add file
amigacollect2.c
thats enough to build the gcc.more steps are need, to build the libs, libgcc
libstdc++ when you want new
to build libgcc: add in libgcc/config.host 68k cpu and later amigaos.see file
from 4.3.2 or use same.
the dir amigaos must add in libstdc++-v3/config (see 4.3.2 source)
now you can compile all.
when you get assembler error in atomicity.h change line with the cas so that,
the \n is last char.
cas.l %0 , %1 , %2 \n
for build libstdc++ with the crosscompilers you need do this steps too
in libstdc++/configure
after (search for GLIBCXX_IS_NATIVE=true)
if test $hostos = $targetos -o $targetos = darwin ; then
GLIBCXX_IS_NATIVE=true
fi
;;
add this lines
*-*-amigaos*)
LDFLAGS=${LDFLAGS-ld} -noixemul
;;
search for Base decisions on target environment
# Base decisions on target environment.
case ${host} in
add this lines
m68k-*-amigaos*)
#os_include_dir=usr/local/amiga/m68k-amigaos/include
;;
in gccx.x.x/libiberty/configure
after this lines
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.
_ACEOF
fi
add this line
LDFLAGS=${LDFLAGS-ld} -noixemul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug middle-end/41956] Segfault in vectorizer
--- Comment #7 from irar at il dot ibm dot com 2009-12-30 10:16 --- The bug is in SLP load permutation analysis. I am testing a patch. -- irar at il dot ibm dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-12-29 17:42:02 |2009-12-30 10:16:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41956
[Bug other/42537] [PATCH] misc spelling fixes
--- Comment #5 from paolo at gcc dot gnu dot org 2009-12-30 10:53 --- Subject: Bug 42537 Author: paolo Date: Wed Dec 30 10:53:31 2009 New Revision: 155518 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155518 Log: /gcc 2009-12-30 Robert Millan rmh@aybabtu.com PR other/42537 * errors.c: Fix typo in comment. * graphite-sese-to-poly.c: Likewise. * profile.c (is_inconsistent): Fix typo in string. /libjava 2009-12-30 Robert Millan rmh@aybabtu.com PR other/42537 * classpath/java/rmi/activation/Activatable.java: Fix typos in comment. Modified: trunk/gcc/ChangeLog trunk/gcc/ChangeLog-2002 trunk/gcc/ChangeLog-2005 trunk/gcc/ChangeLog-2006 trunk/gcc/cp/ChangeLog-2004 trunk/gcc/errors.c trunk/gcc/graphite-sese-to-poly.c trunk/gcc/profile.c trunk/libjava/ChangeLog trunk/libjava/classpath/java/rmi/activation/Activatable.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42537
[Bug other/42537] [PATCH] misc spelling fixes
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-30 10:54 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42537
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #23 from bonzini at gnu dot org 2009-12-30 10:56 --- You need a proper patch, not instructions. However, it's clear from the bugreport and the patches required to fix it, that it is not important whether the target is m68k-amigaos or another OS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug target/42549] Incorrect 3DNow! code generated
--- Comment #1 from ubizjak at gmail dot com 2009-12-30 10:57 --- Confirmed, I have a patch. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-30 10:57:27 date|| Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42549
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #37 from bonzini at gnu dot org 2009-12-30 10:59 --- The bootstrap failure is fixed, please reconfirm and reopen bugs for other failures or other targets. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug target/42549] Incorrect 3DNow! code generated
--- Comment #2 from uros at gcc dot gnu dot org 2009-12-30 11:07 --- Subject: Bug 42549 Author: uros Date: Wed Dec 30 11:07:12 2009 New Revision: 155519 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155519 Log: PR target/42549 * config/i386/mmx.md (*mmx_subv2sf3): Fix insn operand number for alternative 1. testsuite/ChangeLog: PR target/42549 * gcc.target/i386/mmx-3dnow-check.h: New file. * gcc.target/i386/pr42549.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/mmx-3dnow-check.h trunk/gcc/testsuite/gcc.target/i386/pr42549.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mmx.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42549
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #38 from bonzini at gnu dot org 2009-12-30 11:09 ---
Andreas, for s390-linux I get this jumpless code:
f:
xr %r2,%r3
lpr %r2,%r2
ahi %r2,-1
srl %r2,31
br %r14
for this testcase:
int f(int a, int b)
{
return (a == b);
}
at -O1 or above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug other/28322] GCC new warnings and compatibility
--- Comment #29 from debian-gcc at lists dot debian dot org 2009-12-30 11:13 --- yes, sorry, you are right. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
[Bug other/28322] GCC new warnings and compatibility
--- Comment #30 from manu at gcc dot gnu dot org 2009-12-30 11:19 --- No problem. This was implemented in GCC 4.4 and mentioned in the changes.html page. We haven't received any complaints so far, so closing as FIXED. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
[Bug c++/34772] [4.3/4.4/4.5 Regression] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)
--- Comment #14 from manu at gcc dot gnu dot org 2009-12-30 11:29 --- *** Bug 42238 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||ext at sidvind dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34772
[Bug middle-end/42238] Missing warning about uninitialized variable
--- Comment #2 from manu at gcc dot gnu dot org 2009-12-30 11:29 --- -Winit-self is broken in C++ *** This bug has been marked as a duplicate of 34772 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42238
[Bug target/42549] Incorrect 3DNow! code generated
--- Comment #3 from uros at gcc dot gnu dot org 2009-12-30 11:35 --- Subject: Bug 42549 Author: uros Date: Wed Dec 30 11:34:57 2009 New Revision: 155521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155521 Log: PR target/42549 * config/i386/mmx.md (*mmx_subv2sf3): Fix insn operand number for alternative 1. testsuite/ChangeLog: PR target/42549 * gcc.target/i386/mmx-3dnow-check.h: New file. * gcc.target/i386/pr42549.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/mmx-3dnow-check.h branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42549.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/mmx.md branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42549
[Bug target/42549] Incorrect 3DNow! code generated
--- Comment #4 from uros at gcc dot gnu dot org 2009-12-30 11:47 --- Subject: Bug 42549 Author: uros Date: Wed Dec 30 11:47:30 2009 New Revision: 155522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155522 Log: PR target/42549 * config/i386/mmx.md (*mmx_subv2sf3): Fix insn operand number for alternative 1. testsuite/ChangeLog: PR target/42549 * gcc.target/i386/mmx-3dnow-check.h: New file. * gcc.target/i386/pr42549.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/mmx-3dnow-check.h branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr42549.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/mmx.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42549
[Bug target/42549] Incorrect 3DNow! code generated
--- Comment #5 from ubizjak at gmail dot com 2009-12-30 11:49 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||12/msg01205.html Status|ASSIGNED|RESOLVED Keywords||ssemmx Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42549
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #24 from nospamname at web dot de 2009-12-30 12:06 ---
(In reply to comment #23)
You need a proper patch, not instructions.
However, it's clear from the bugreport and the patches required to fix it,
that
it is not important whether the target is m68k-amigaos or another OS.
Yes i know, and i can do a diff, but are there chances that this changes are
add or is m68k-amigaos going to remove complete in 4.6 ?
Wy can not the code stay in as long it work well ?
m68k-amigaos is a m68k bsd a.out Build that use sjlj Exception Handling on C++.
So there is no special support Code for AOS need and it work well with newest
compilers.
The only that need add to compile GCC and g++ is this.
add in gcc-x.x.x/gcc/config.gcc
(search for m68k)
m68k-*-amigaos*)
tmake_file=m68k/t-amigaos
tm_file=${tm_file} m68k/amigaos.h
tm_p_file=${tm_p_file} m68k/amigaos-protos.h
tm_defines=TARGET_AMIGAOS TARGET_DEFAULT=0 # 68040
extra_objs=amigaos.o
gnu_ld=yes
;;
more add in config files is only need for libgcc and libstdc++
When report a Bug, we can also compare the asm Code with a better support 68k
Target, thats no Problem, but we thought because of same C Code all work same.
But i like know what 68k target Andreas or other GCC Developer for 68k use and
what configure Options they use so i can build a cygwin Version for this
compilers.
Or is there a binary build for cygwin and these 68k Compilers here ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #25 from bonzini at gnu dot org 2009-12-30 12:22 --- Adding target support without at least libgcc makes little sense. The small part in config.guess/config.sub is not going to be removed, since those files are just imported in GCC and are handled as a separate project. People use m68k-elf or m68k-uclinux to build cross compilers. The former can be built easily using a combined tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug libstdc++/42552] New: std::wcerr followed by std::cerr lacks std:cerr output
forwarding, seen with current branches and trunk
Matthias
#include iostream
int main()
{
std::wcerr LHello, world! std::endl;
std::cerr !dlrow ,olleH std::endl;
}
when compiled, will only output Hello, world!, and the subsequent string will
not be output.
However,
#include iostream
int main()
{
std::cerr Foobar std::endl;
std::wcerr LHello, world! std::endl;
std::cerr !dlrow ,olleH std::endl;
}
works as expected, printing out all three strings.
--
Summary: std::wcerr followed by std::cerr lacks std:cerr output
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42552
[Bug libstdc++/37557] mixing wide and plain streams causes stream-errors (g++ 4.1.0 also affected)
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-30 12:51 --- *** Bug 42552 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37557
[Bug libstdc++/42552] std::wcerr followed by std::cerr lacks std:cerr output
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-30 12:51 --- If you are looking for a totally unsupported (can go away at any moment) workaround (it's a bug that it does what you want), see PR11705 *** This bug has been marked as a duplicate of 37557 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42552
[Bug c++/40355] ICE in prop_phis, at tree-loop-distribution.c:357
--- Comment #3 from mironov dot ivan at gmail dot com 2009-12-30 12:52 --- I can also reproduce this problem: $ g++ -m32 -ftree-loop-distribution -O2 posix_proactor.ii -c ../../../../dep/ACE_wrappers/ace/POSIX_Proactor.cpp: In member function 'int ACE_POSIX_AIOCB_Proactor::create_result_aiocb_list()': ../../../../dep/ACE_wrappers/ace/POSIX_Proactor.cpp:857: internal compiler error: in prop_phis, at tree-loop-distribution.c:357 Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. Preprocessed source stored into /tmp/ccQ9Zk5X.out file, please attach this to your bugreport. $ gcc -dumpversion 4.4.2 $ rpm -qi gcc Name: gcc Relocations: (not relocatable) Version : 4.4.2 Vendor: Fedora Project Release : 20.fc12 Build Date: Tue Dec 22 20:17:19 2009 Install Date: Wed Dec 30 08:51:40 2009 Build Host: localhost Group : Development/Languages Source RPM: gcc-4.4.2-20.fc12.src.rpm Size: 19335236 License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions Signature : RSA/8, Tue Dec 22 22:42:01 2009, Key ID 9d1cc34857bbccba Packager: Fedora Project URL : http://gcc.gnu.org Summary : Various compilers (C, C++, Objective-C, Java, ...) Description : The gcc package contains the GNU Compiler Collection version 4.4. You'll need this package in order to compile C code. -- mironov dot ivan at gmail dot com changed: What|Removed |Added CC||mironov dot ivan at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40355
[Bug tree-optimization/41956] Segfault in vectorizer
--- Comment #8 from irar at gcc dot gnu dot org 2009-12-30 12:53 --- Subject: Bug 41956 Author: irar Date: Wed Dec 30 12:53:18 2009 New Revision: 155523 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155523 Log: PR tree-optimization/41956 * tree-vect-slp.c (vect_supported_load_permutation_p): Add check that the load indices differ. Added: trunk/gcc/testsuite/gcc.dg/vect/pr41956.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41956
[Bug target/42553] New: wrong code with -O1
current trunk/branches on x86_64-linux-gnu. return values with different
compilers and different optimizations:
-O0 -O1 -O2 -O3
gcc-4.1 0222
gcc-4.3 0222
gcc-4.4 2000
gcc-4.5 0100
Matthias
#include stdbool.h
#include stdio.h
static bool atomic_test_and_reset_bit(unsigned long *v,unsigned long bit) {
bool res;
__asm__ __volatile__( btr %2,%1\n
adc $0,%0\n
:=r(res), =m(*v)
:r(bit), r(0)) ;
return res ? 1 : 0;
}
int main(void)
{
unsigned long flags = 0;
int j;
j = atomic_test_and_reset_bit(flags, 2);
printf(%d\n, j);
return 0;
}
--
Summary: wrong code with -O1
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42553
Re: [Bug target/42553] New: wrong code with -O1
Sent from my iPhone
On Dec 30, 2009, at 7:56 AM, debian-gcc at lists dot debian dot org gcc-bugzi...@gcc.gnu.org
wrote:
current trunk/branches on x86_64-linux-gnu. return values with
different
compilers and different optimizations:
-O0 -O1 -O2 -O3
gcc-4.1 0222
gcc-4.3 0222
gcc-4.4 2000
gcc-4.5 0100
Matthias
#include stdbool.h
#include stdio.h
static bool atomic_test_and_reset_bit(unsigned long *v,unsigned long
bit) {
bool res;
__asm__ __volatile__( btr %2,%1\n
adc $0,%0\n
:=r(res), =m(*v)
:r(bit), r(0)) ;
return res ? 1 : 0;
This inline-asm looks wrong. Because it says *v is always overriden.
So if that function is inlined, flags down below does not have to be
set before it.
}
int main(void)
{
unsigned long flags = 0;
int j;
j = atomic_test_and_reset_bit(flags, 2);
printf(%d\n, j);
return 0;
}
--
Summary: wrong code with -O1
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42553
[Bug target/42553] wrong code with -O1
--- Comment #1 from pinskia at gmail dot com 2009-12-30 13:14 ---
Subject: Re: New: wrong code with -O1
Sent from my iPhone
On Dec 30, 2009, at 7:56 AM, debian-gcc at lists dot debian dot org
gcc-bugzi...@gcc.gnu.org
wrote:
current trunk/branches on x86_64-linux-gnu. return values with
different
compilers and different optimizations:
-O0 -O1 -O2 -O3
gcc-4.1 0222
gcc-4.3 0222
gcc-4.4 2000
gcc-4.5 0100
Matthias
#include stdbool.h
#include stdio.h
static bool atomic_test_and_reset_bit(unsigned long *v,unsigned long
bit) {
bool res;
__asm__ __volatile__( btr %2,%1\n
adc $0,%0\n
:=r(res), =m(*v)
:r(bit), r(0)) ;
return res ? 1 : 0;
This inline-asm looks wrong. Because it says *v is always overriden.
So if that function is inlined, flags down below does not have to be
set before it.
}
int main(void)
{
unsigned long flags = 0;
int j;
j = atomic_test_and_reset_bit(flags, 2);
printf(%d\n, j);
return 0;
}
--
Summary: wrong code with -O1
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42553
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42553
[Bug target/42553] wrong code with -O1
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-30 14:33 ---
The inline-asm is totally incorrect here is the corrected version of the
function (note res should be set):
static bool atomic_test_and_reset_bit(unsigned long *v,unsigned long bit) {
bool res = 0;
__asm__ __volatile__( btr %2,%1\n
adc $0,%0\n
:+r(res): m(*v)
,r(bit), r(0): flags) ;
return res ? 1 : 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42553
[Bug target/42465] internal compiler error: in extract_insn, at recog.c:2001
--- Comment #7 from gccbugzilla at taggedtype dot net 2009-12-30 15:24 --- Ok, I ran the delta program for a few days and got this message: Died at /home/s.somani/thirdparty/delta-2006.08.03/delta line 123, line 64641 Doh! I'll try and see if I can get another test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42465
[Bug target/42465] internal compiler error: in extract_insn, at recog.c:2001
--- Comment #8 from gccbugzilla at taggedtype dot net 2009-12-30 15:39
---
Aha, found a small test case:
int main()
{
long double d;
bool b = static_castlong double(0) == d;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42465
[Bug target/42465] internal compiler error: in extract_insn, at recog.c:2001
--- Comment #9 from gccbugzilla at taggedtype dot net 2009-12-30 15:41 --- I've narrowed it down to this invocation: g++ -o octonion_test.o -c -mxl-compat ld_break.cpp So it's caused by some interaction with -mxl-compat -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42465
[Bug target/42542] Vectorizer produces incorrect results on max of signed intergers
--- Comment #11 from hjl dot tools at gmail dot com 2009-12-30 15:50 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01208.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||12/msg01208.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
[Bug middle-end/19154] miss-optimization of (x pow2C) avr conditionals returning bool equivalent values
--- Comment #9 from hutchinsonandy at gcc dot gnu dot org 2009-12-30 16:14 --- Fixed on 4.5 - or at least significantly better enough to warrant closure. -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19154
[Bug target/42312] config/mep/mep.c:2856: (error) Uninitialized variable: frame_size
--- Comment #2 from manu at gcc dot gnu dot org 2009-12-30 16:26 --- This seems FIXED per DJ's commit. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||dj at gcc dot gnu dot org, ||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42312
[Bug middle-end/42290] strange 'warning: ISRA.2 may be used uninitialized in this function'
--- Comment #6 from manu at gcc dot gnu dot org 2009-12-30 16:29 --- Once PR42508 is fixed, this should be reevaluated and probably won't warn anymore or can be closed as INVALID, since the warning was valid. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org BugsThisDependsOn||42508 Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42290
[Bug lto/42531] FAIL: gcc.c-torture/compile/20011119-1.c
--- Comment #2 from davek at gcc dot gnu dot org 2009-12-30 16:37 --- Test runs all finished. Before: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02081.html After: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02582.html No new fails. Sending patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42531
[Bug target/27440] [4.3/4.4 regression] code quality regression due to ivopts
--- Comment #15 from steven at gcc dot gnu dot org 2009-12-30 16:39 --- With GCC: (GNU) 4.5.0 20091228 (experimental) [trunk revision 155486] I get identical code at -O2 with and without -fno-ivopts for i686: .L3: movl%ebx, (%ecx,%eax,4) addl$1, %eax cmpl%edx, %eax jb .L3 For x86_64 at -O2, there is still the extra mov. The extra mov is not there with -Os (with and without -fno-ivopts). Since the mov on x86_64 is essentially free, I consider this fixed for GCC 4.5.0. -- steven at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.6 |3.4.6 4.5.0 Summary|[4.3/4.4/4.5 regression]|[4.3/4.4 regression] code |code quality regression due |quality regression due to |to ivopts |ivopts http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
[Bug middle-end/42099] Error in 64-bit division for 32-bit target
--- Comment #7 from mikpe at it dot uu dot se 2009-12-30 16:45 --- FWIW, Ian's fix backports trivially to 4.4 and 4.3 and fixes this test case there with no test suite regressions (all default languages) on i686-linux. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug regression/42145] Incorrect may be used uninitialized warning for a very specific test case
--- Comment #3 from manu at gcc dot gnu dot org 2009-12-30 16:59 --- This would need conditional PHIs, so a duplicate of PR20968. GCC never detects that ret is always initialized, it doesn't warn because at low optimization levels we do not warn for PHIs or because CCP (PR18501) just initializes the variable (probably to 1 or 10). There is some differences between the dumps of -O1 and -O2 in the way the logical or is transformed int bitwise-or and how dom1 deals with each of them, but I cannot tell if there is some missing optimization involved. *** This bug has been marked as a duplicate of 20968 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42145
[Bug middle-end/20968] spurious may be used uninitialized warning (conditional PHIs)
--- Comment #7 from manu at gcc dot gnu dot org 2009-12-30 16:59 --- *** Bug 42145 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||colin at reactos dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968
[Bug tree-optimization/42508] wrong code with -O1 -fipa-sra
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-30 17:33:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42508
[Bug rtl-optimization/42497] Generate conditional tail calls .
--- Comment #1 from ramana at gcc dot gnu dot org 2009-12-30 17:32 ---
The problem here essentially appears to be that GCC can't seem to generate
conditional tail-calls (or conditional calls for that matter in this case) with
-fno-optimize-sibling-calls . I don't read this as a problem with
builtin_expect per-se but that of GCC not being able to generate a conditional
tail-call / call.
A simpler test is essentially the following.
void foo (int x)
{
if (x)
bar ();
else
baz ();
}
This is also not just a target problem but probably one for the RTL optimizers
rather any where else..
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Component|target |rtl-optimization
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-12-30 17:32:59
date||
Summary|GCC can do less work in the |Generate conditional tail
|frequently executed path|calls .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42497
[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #17 from janus at gcc dot gnu dot org 2009-12-30 17:34 --- Reopening. As reported in http://gcc.gnu.org/ml/fortran/2009-12/msg00215.html, the patch in comment #15 introduced several regressions on the fortran-dev branch. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[OOP] Bogus Error: Name |[fortran-dev] Bogus Error: |'vtype$...' at (1) is an|Name 'vtype$...' at (1) is |ambiguous reference ... |an ambiguous reference ... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
[Bug fortran/42527] Fortran FORMAT descriptor X generates nulls instead of blanks for ACCESS='stream files
--- Comment #6 from urbanjost at comcast dot net 2009-12-30 17:51 --- Subject: Re: Fortran FORMAT descriptor X generates nulls instead of blanks for ACCESS='stream files I could not initially get the Mingw or straight CygWin install to work; but I was also having problems with X11 Windows and the file(1) command and there was a new xinit release; after I upgraded CygWin (and reinstalled the Base group in CygWin) the new gfortran install began working and with version 4.5.0 20091119 (experimental) [trunk revision 152402] everything looks fixed compared to my original bug report (output attached). Thanks; sorry I didn't get a newer version tested sooner but I had tried several times; after my last Cygwin install the problem with the new version went away automagically; I am running 4.5.0 from the same directory that was failing previously (/usr/local/gfortran). (And, my X11 Windows are coming up again) Thanks again! 1 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.0010.0011.0012.0013.0014.0015.0016.00 17.0018.0019.0020.0021.0022.0023.00 1 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.0010.0011.0012.0013.0014.0015.0016.00 17.0018.0019.0020.0021.0022.0023.00 == cat: missouri.i: No such file or directory == CYGWIN_NT-6.0 urbanjs-PC 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin == Driving: gfortran -v missouri.f -o missouri -lgfortran Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ../trunk/configure --prefix=/usr/local/gfortran --enable-languages=c,c++,fortran --disable-bootstrap --enable-threads=posix --enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls --disable-libmudflap --disable-shared --disable-win32-registry --with-system-zlib --enable-checking=release --enable-werror --without-included-gettext --without-x --enable-libgomp Thread model: posix gcc version 4.5.0 20091119 (experimental) [trunk revision 152402] (GCC) COLLECT_GCC_OPTIONS='-v' '-o' 'missouri.exe' '-mtune=generic' /usr/local/gfortran/libexec/gcc/i686-pc-cygwin/4.5.0/f951.exe missouri.f -ffixed-form -quiet -dumpbase missouri.f -mtune=generic -auxbase missouri -version -fintrinsic-modules-path /usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0/finclude -o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccSSpJov.s GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402] (i686-pc-cygwin) compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.5.0 20091119 (experimental) [trunk revision 152402] (i686-pc-cygwin) compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-o' 'missouri.exe' '-mtune=generic' as -o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccGVQpz0.o /cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccSSpJov.s COMPILER_PATH=/usr/local/gfortran/libexec/gcc/i686-pc-cygwin/4.5.0/:/usr/local/gfortran/libexec/gcc/i686-pc-cygwin/4.5.0/:/usr/local/gfortran/libexec/gcc/i686-pc-cygwin/:/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0/:/usr/local/gfortran/lib/gcc/i686-pc-cygwin/ LIBRARY_PATH=/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0/:/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-o' 'missouri.exe' '-mtune=generic' /usr/local/gfortran/libexec/gcc/i686-pc-cygwin/4.5.0/collect2.exe -Bdynamic --dll-search-prefix=cyg -tsaware -o missouri.exe /lib/crt0.o /usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0/crtbegin.o -L/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0 -L/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0/../../.. /cygdrive/c/Users/urbanjs/AppData/Local/Temp/ccGVQpz0.o -lgfortran -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc /usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0/crtend.o == END - Original Message - From: burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org To: urbanj...@comcast.net Sent: Tuesday, December 29, 2009 7:46 PM Subject: [Bug fortran/42527] Fortran FORMAT descriptor X generates nulls instead of blanks for ACCESS='stream files --- Comment #5 from burnus at gcc dot gnu dot org 2009-12-30 00:46 --- (In reply to comment #4) No, I didn't build this compiler version; this is what I got when I reinstalled CygWin from scratch on 11/29/2009. I tried to install
[Bug ada/42554] New: Can't build gnatlink, gnatmake
While building gnatlink gnatmake for both i386 and x86_64, get ld: duplicate symbol _system__secondary_stack__mark_idIP in ../rts/libgnat.a(s-secsta.o) and s-secsta.o (and, after fixing this, s-exctab.o). I suppose this is because of a change in Snow Leopard where an object can't be both explicitly present on the command line and in a static library? Though there are other objects explicitly mentioned, eg s-stalib.o, which don't have to be removed. Anyway, editing gcc/ada/gcc-interface/Makefile.in to remove s-exctab.o and s-secsta.o from GNATLINK_OBJS and GNATMAKE_OBJS does the trick, see attached patch. -- Summary: Can't build gnatlink, gnatmake Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: simon at pushface dot org GCC build triplet: *86*-apple-darwin10.2.0 GCC host triplet: *86*-apple-darwin10.2.0 GCC target triplet: *86*-apple-darwin10.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554
[Bug ada/42554] Can't build gnatlink, gnatmake
--- Comment #1 from simon at pushface dot org 2009-12-30 18:27 --- Created an attachment (id=19424) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19424action=view) Patch to gcc/ada/gcc-interface/Makefile.in [Some] objects that are in the RTS archive mustn't be explicitly mentioned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #10 from simon at pushface dot org 2009-12-30 18:29 ---
I've done as Eric suggests in #8 (though it looks to me as though the build
system is very close to supporting just --build= in this case!).
Situation now is that something in gcc/ada/gcc-interface/Makefile is selecting
system-darwin-ppc.ads to copy into gcc/ada/rts/system.ads (bizarre! I can't see
how this happens, it doesn't happen with the i386 build) which is a 32-bit
system, hence the reported failure.
Replace with the correct system-darwin-x86_64.ads, delete gcc/ada/rts/*.{o,ali}
and continue with the make, the RTS build continues OK (other problems later,
see #42554)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug c++/42555] New: 4.5 regression: 16-byte aligned double is disallowed only in templates
The following line of code is accepted: typedef double AlignedDoubleType __attribute__((aligned(16))); However, if I replace 'double' with a template parameter inside a template function, then I get the following error message: error: alignment of array elements is greater than element size I think that the template version of the typedef should be allowed also, as it is in 4.4. -- Summary: 4.5 regression: 16-byte aligned double is disallowed only in templates Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bredelin at ucla dot edu GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42555
[Bug c++/42555] 4.5 regression: 16-byte aligned double is disallowed only in templates
--- Comment #1 from bredelin at ucla dot edu 2009-12-30 19:00 --- Created an attachment (id=19425) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19425action=view) A testcase. To reproduce the error, compile the file (test5.C) with this command line: % g++-4.5 -c test5.C -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42555
[Bug c++/42555] 4.5 regression: 16-byte aligned double is disallowed only in templates
--- Comment #2 from bredelin at ucla dot edu 2009-12-30 19:03 --- Also, I just noticed that the error occurs only if -ftree-vectorize is turned on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42555
[Bug c++/42556] New: Unnecessary generation of a zero initializer for array with C++
This is distilled from PR42500. The same testcase doesn't show a problem if
compiled with a C compiler only.
Why does the gimple for the following testcase contain ?
extern C void foo(int a[4]);
extern C void bar(int a, int b, int c, int d)
{
int v[4] = { a, b, c, d};
foo(v);
foo(v);
}
in .004t.gimple
void bar(int, int, int, int) (int a, int b, int c, int d)
{
int v[4];
v = {};
v[0] = a;
v[1] = b;
v[2] = c;
v[3] = d;
foo (v[0]);
foo (v[0]);
}
even when all members of the array have been initialized in your original
testcase. I wonder if this can be eliminated as a part of the lowering process
to GIMPLE in the C++ frontend rather than any other place.
At -O2 the RTL optimizers remove 2 of the stores but there are unnecessary
stores of 0 to memory locations at [sp+8] , [sp+12] and the code generated is
as follows. (Instructions marked A and B below).
bar:
stmfd sp!, {r4, lr}
.save {r4, lr}
.LCFI0:
.pad #16
sub sp, sp, #16
.LCFI1:
mov lr, #0
add ip, sp, #8
str lr, [ip], #4 // A
str r0, [sp, #0]
mov r0, sp
str lr, [ip, #0] // B
stmib sp, {r1, r2, r3}@ phole stm
bl foo
mov r0, sp
mov r4, sp
bl foo
add sp, sp, #16
ldmfd sp!, {r4, lr}
bx lr
At -Os because the zero initializer is in the form of a memset - the RTL
optimizers don't remove anything and the code generated is as follows.
bar:
.fnstart
.LFB0:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, lr}
.save {r0, r1, r2, r3, r4, r5, r6, r7, r8, lr}
.LCFI0:
mov r6, r0
mov r5, r1
mov r4, r2
mov r1, #0
mov r2, #16
mov r0, sp
mov r8, r3
bl memset
mov r0, sp
str r6, [sp, #0]
str r5, [sp, #4]
mov r7, sp
str r4, [sp, #8]
str r8, [sp, #12]
bl foo
mov r0, sp
bl foo
ldmfd sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, pc}
If I change the testcase to use the extended initializer list in c++0x and
gnu++0x . There is an unnecessary move from sp to r4 but that is the subject of
PR42500.
void foo(int a[4]);
void bar(int a, int b, int c, int d)
{
int v[4] ;
v = { a, b, c, d};
foo(v);
foo(v);
}
bar:
.fnstart
.LFB0:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r0, r1, r2, r3, r4, lr}
.save {r0, r1, r2, r3, r4, lr}
.LCFI0:
str r0, [sp, #0]
mov r0, sp
stmib sp, {r1, r2, r3}@ phole stm
bl foo
mov r0, sp
mov r4, sp
bl foo
ldmfd sp!, {r0, r1, r2, r3, r4, pc}
.LFE0:
.fnend
cheers
Ramana
--
Summary: Unnecessary generation of a zero initializer for array
with C++
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
GCC host triplet: x86_64 linux gnu
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42556
[Bug c++/42500] Unnecessary call to memset to initialize array at Os
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-30 19:14 --- Ok (In reply to comment #3) My complete command line: /home/carrot/compiler/armobj/gcc/cc1plus -fpreprocessed testH.ii -quiet -dumpbase testH.cpp -auxbase-strip obj/./testH.o -Os -o testH.s Please compile it as C++ program. When I compiled it as C program, I got the same result as yours. Ok that is a subject of a separate bug report that has been filed at PR42556. Let this remain about just the redundant move of sp into r4. Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|target |c++ Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-30 19:14:49 date|| Summary|unnecessary register move |Unnecessary call to memset ||to initialize array at Os http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42500
[Bug tree-optimization/42139] [4.5 regression] Compiling firefox trunk with 4.5 fails with 'out of memory allocating 4072 bytes after a total of xxx bytes'
--- Comment #4 from jason at gcc dot gnu dot org 2009-12-30 19:28 --- Confirmed, marking as P1 regression. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-12-30 19:28:46 date|| Summary|Compiling firefox trunk with|[4.5 regression] Compiling |4.5 fails with 'out of |firefox trunk with 4.5 fails |memory allocating 4072 bytes|with 'out of memory |after a total of xxx bytes' |allocating 4072 bytes after ||a total of xxx bytes' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139
[Bug c++/42514] [4.3/4.4 Regression] Invalid Destructor Name of A Template Class Is Accepted
--- Comment #2 from jason at gcc dot gnu dot org 2009-12-30 19:35 --- 4.5 already says wa.C:8:11: error: declaration of ~typename BaseT::BaseTypo as member of BaseT for this testcase. Closing as fixed, as backporting the fix seems a little risky for an invalid code bug. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.3.3 4.4.2 4.5.0 |4.3.3 4.4.2 Known to work|4.2.5 |4.2.5 4.5.0 Resolution||FIXED Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] Invalid |Invalid Destructor Name of A|Destructor Name of A |Template Class Is Accepted |Template Class Is Accepted Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42514
[Bug c++/42447] [4.5 Regression] ICE during processing complex templates
--- Comment #16 from jason at gcc dot gnu dot org 2009-12-30 19:36 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug middle-end/42099] Error in 64-bit division for 32-bit target
--- Comment #8 from ian at gcc dot gnu dot org 2009-12-30 19:42 --- Subject: Bug 42099 Author: ian Date: Wed Dec 30 19:42:03 2009 New Revision: 155524 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155524 Log: gcc/: PR middle-end/42099 * expmed.c (expand_divmod): Don't shift HOST_WIDE_INT value more than HOST_BITS_PER_WIDE_INT. gcc/testsuite/: PR middle-end/42099 * gcc.c-torture/execute/20091229-1.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/20091229-1.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/expmed.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug c++/40355] ICE in prop_phis, at tree-loop-distribution.c:357
--- Comment #4 from fierevere at ya dot ru 2009-12-30 19:42 --- ICE does not happen on x86_64-linux-gnu platform, so its only 32-bit x86 linux-gnu specific -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40355
[Bug c++/42556] Unnecessary generation of a zero initializer for array with C++
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-30 19:47 ---
The front-end already changed it into being = {};, a[0] = ...
cleanup_point int v[4] = {};;
cleanup_point Unknown tree: expr_stmt
Unknown tree: expr_stmt
v[0] = a
;
Unknown tree: expr_stmt
v[1] = b
;
Unknown tree: expr_stmt
v[2] = c
;
Unknown tree: expr_stmt
v[3] = d
;
;
I thought there was a duplicate of this bug somewhere.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2009-12-30 19:47:23
date||
Summary|Unnecessary generation of a |Unnecessary generation of a
|zero initializer for array |zero initializer for array
|with C++|with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42556
[Bug middle-end/42099] Error in 64-bit division for 32-bit target
--- Comment #9 from ian at gcc dot gnu dot org 2009-12-30 19:50 --- Subject: Bug 42099 Author: ian Date: Wed Dec 30 19:50:24 2009 New Revision: 155525 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155525 Log: gcc/: PR middle-end/42099 * expmed.c (expand_divmod): Don't shift HOST_WIDE_INT value more than HOST_BITS_PER_WIDE_INT. gcc/testsuite/: PR middle-end/42099 * gcc.c-torture/execute/20091229-1.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/20091229-1.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/expmed.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug middle-end/42099] Error in 64-bit division for 32-bit target
--- Comment #10 from ian at airs dot com 2009-12-30 19:59 --- I backported the patch and testsuite to the 4.3 and 4.4 branches. -- ian at airs dot com changed: What|Removed |Added Target Milestone|4.5.0 |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug tree-optimization/42139] [4.5 regression] Compiling firefox trunk with 4.5 fails with 'out of memory allocating 4072 bytes after a total of xxx bytes'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139
[Bug ada/42518] Alignment issue prevents building 64 bit RTS on Snow Leopard
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-12-30 20:50 --- Please try an svn pull of current gcc-4_4-branch. Assuming that you have EMT64 capable hardware and want to build the native x86_64 version of the FSF gcc compilers, the new config.guess should properly detect the triplet as x86_64-apple-darwin10 without any additional --build/--host/--target flags. You might also try gcc trunk to make sure that there aren't changes that need to be backported. This could be the case as I don't see... 2009-04-09 Nicolas Setton set...@adacore.com * s-osinte-darwin.ads: (Pad_Type): Make this an array of unsigned_long, to match layout of siginfo_t in sys/signal.h. * gcc-interface/Makefile.in: Add section for x86_64 darwin. in gcc-4_4-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
[Bug fortran/41872] wrong-code: Issues with allocatable scalars
--- Comment #8 from burnus at gcc dot gnu dot org 2009-12-30 20:50 ---
TODO:
- SAVED local variables are (probably) mishandled
- Check whether other things such as allocatable scalar components,
(absent/present) optional dummys etc. work.
- allocatable-scalar returning functions as actual argument
- character-returning actual arguments
Check whether the following patch is needed or nonsense:
--- gcc/fortran/trans-expr.c(Revision 155510)
+++ gcc/fortran/trans-expr.c
@@ -1905,7 +1905,7 @@ gfc_add_interface_mapping (gfc_interface
{
tmp = gfc_get_character_type_len (sym-ts.kind, NULL);
tmp = build_pointer_type (tmp);
- if (sym-attr.pointer)
+ if (sym-attr.pointer || sym-attr.allocatable)
value = build_fold_indirect_ref_loc (input_location,
se-expr);
else
@@ -4478,10 +4479,12 @@ gfc_conv_expr_reference (gfc_se * se, gf
if (expr-expr_type == EXPR_FUNCTION
((expr-value.function.esym
- expr-value.function.esym-result-attr.pointer
+ (expr-value.function.esym-result-attr.pointer
+ || expr-value.function.esym-result-attr.allocatable)
!expr-value.function.esym-result-attr.dimension)
|| (!expr-value.function.esym
- expr-symtree-n.sym-attr.pointer
+ (expr-symtree-n.sym-attr.pointer
+ || expr-symtree-n.sym-attr.allocatable)
!expr-symtree-n.sym-attr.dimension)))
{
se-want_pointer = 1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41872
[Bug c/42557] New: gcc no compile for m68k(coff/elf)
I tried to compile gcc (4.4.1 and 4.4.2) for m68k-coff for Linux. I'm using Ubuntu 9.10 AMD64. However, I get an error stating that gas is not supported for the version of binutils (2.20) used: ... Configuring in ./gas configure: creating cache ./config.cache checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... m68k-unknown-coff checking for x86_64-unknown-linux-gnu-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for library containing strerror... none required checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... mawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for x86_64-unknown-linux-gnu-gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for a sed that does not truncate output... /bin/sed checking for fgrep... /bin/grep -F checking for ld used by gcc... ld checking if the linker (ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... nm checking the name lister (nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 3458764513820540925 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking for ld option to reload object files... -r checking for x86_64-unknown-linux-gnu-objdump... objdump checking how to recognize dependent libraries... pass_all checking for x86_64-unknown-linux-gnu-ar... ar checking for x86_64-unknown-linux-gnu-strip... no checking for strip... strip checking for x86_64-unknown-linux-gnu-ranlib... ranlib checking command to parse nm output from gcc object... ok checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror checking whether byte ordering is bigendian... no This target is no longer supported in gas make[1]: *** [configure-gas] Error 1 make[1]: Leaving directory `/home/miltoncsl/Documents/coldfire/binutils-2.20' make: *** [all] Error 2 $ When compiling m68k-elf the process went smoothly and I can install (m68k-elf-as, m68k-elf-ar, etc.). But this time I can not compile gcc 4.4.1 or 4.4.2 (m68k-elf-gcc) because I get an error stating problems with libgcc.mvars: configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... no checking for mawk... mawk checking build system type... x86_64-unknown-linux-gnu checking host system type... m68k-unknown-elf checking for m68k-elf-ar... /usr/m68k-elf/bin/ar checking for m68k-elf-lipo... m68k-elf-lipo checking for m68k-elf-nm...
[Bug driver/42442] [4.5 Regression] -march=native doesn't apply to multiple files
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42442
[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Component|c++ |middle-end Keywords||ice-checking, ice-on-valid- ||code Summary|another GCC 4.5 ICE on C++ |[4.5 Regression] another GCC |templated code |4.5 ICE on C++ templated ||code Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug debug/42455] [4.5 Regression] -fcompare-debug failure at -O2 in 'recent' builds
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-30 20:57 --- I'll have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-12-22 01:52:36 |2009-12-30 20:57:19 date|| Summary|-fcompare-debug failure at|[4.5 Regression] -fcompare- |-O2 in 'recent' builds |debug failure at -O2 in ||'recent' builds Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42455
[Bug middle-end/42558] New: [4.5 Regression] miscompilation related to -floop-block
The attached testcase miscompiles as: gfortran -floop-block-O2 -funroll-loops -ffast-math bug.f90 ./a.out 4. gfortran -O2 -funroll-loops -ffast-math bug.f90 ./a.out 1. gfortran bug.f90 ./a.out 1. 4.4 works fine, 4.5 miscompiles -- Summary: [4.5 Regression] miscompilation related to -floop-block Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42558
[Bug middle-end/42558] [4.5 Regression] miscompilation related to -floop-block
--- Comment #1 from jv244 at cam dot ac dot uk 2009-12-30 21:08 --- Created an attachment (id=19426) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19426action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42558
[Bug middle-end/42558] [4.5 Regression] miscompilation related to -floop-block
--- Comment #2 from jv244 at cam dot ac dot uk 2009-12-30 21:10 --- full version details: gfortran -v -floop-block-O2 -funroll-loops -ffast-math bug.f90 Driving: gfortran -v -floop-block -O2 -funroll-loops -ffast-math bug.f90 -lgfortran -lm -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ --with-libelf=/data03/vondele/libelf-0.8.12/build/ --enable-gold --enable-lto --enable-plugins Thread model: posix gcc version 4.5.0 20091229 (experimental) [trunk revision 155502] (GCC) COLLECT_GCC_OPTIONS='-v' '-floop-block' '-O2' '-funroll-loops' '-ffast-math' '-shared-libgcc' '-mtune=generic' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 bug.f90 -quiet -dumpbase bug.f90 -mtune=generic -auxbase bug -O2 -version -floop-block -funroll-loops -ffast-math -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/ccVuGyWl.s GNU Fortran (GCC) version 4.5.0 20091229 (experimental) [trunk revision 155502] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036], GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.5.0 20091229 (experimental) [trunk revision 155502] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036], GMP version 4.2.4, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-v' '-floop-block' '-O2' '-funroll-loops' '-ffast-math' '-shared-libgcc' '-mtune=generic' as -V -Qy -o /tmp/cc84OG4d.o /tmp/ccVuGyWl.s GNU assembler version 2.18.50 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE 11.0) 2.18.50.20080409-11.1 COMPILER_PATH=/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/:/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/:/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/:/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/:/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/:/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-floop-block' '-O2' '-funroll-loops' '-ffast-math' '-shared-libgcc' '-mtune=generic' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtbegin.o -L/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0 -L/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../.. /tmp/cc84OG4d.o -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtfastmath.o /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtend.o /usr/lib/../lib64/crtn.o -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||spop at gcc dot gnu dot org Priority|P3 |P2 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42558
[Bug c/42439] Linux kernel BUILD_BUG_ON() broke
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-12-30 21:28 --- Subject: Bug 42439 Author: jsm28 Date: Wed Dec 30 21:28:45 2009 New Revision: 155526 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155526 Log: PR c/42439 * c-decl.c (check_bitfield_type_and_width): Only pedwarn if pedantic for bit-field width not an integer constant expression but folding to one. testsuite: * gcc.dg/bitfld-19.c, gcc.dg/bitfld-20.c, gcc.dg/bitfld-21.c: New tests. Added: trunk/gcc/testsuite/gcc.dg/bitfld-19.c trunk/gcc/testsuite/gcc.dg/bitfld-20.c trunk/gcc/testsuite/gcc.dg/bitfld-21.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439
[Bug c/42439] Linux kernel BUILD_BUG_ON() broke
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-12-30 21:30 --- Fixed for 4.5 (allowing this dubious code with a pedwarn-if-pedantic, since this is done in several similar cases). -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439
[Bug middle-end/42099] Error in 64-bit division for 32-bit target
--- Comment #11 from jakub at gcc dot gnu dot org 2009-12-30 21:32 --- Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42099
[Bug middle-end/42558] [4.5 Regression] miscompilation related to -floop-block
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-30 21:34 --- It is caused by revision 155418: http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00562.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42558
[Bug c/42559] New: ice in emit_block_move_hints with -O2
I just tried to compile the package libhugetlbfs-2.5 with the GNU C compiler version 4.5 snapshot 20091224 and the compiler said n file included from /usr/include/string.h:640:0, from icache-hygiene.c:37: /usr/include/bits/string3.h: In function 'jumpfunc': /usr/include/bits/string3.h:52:3: internal compiler error: in emit_block_move_hints, at expr.c:1197 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O2 required. -- Summary: ice in emit_block_move_hints with -O2 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42559
[Bug c/42559] ice in emit_block_move_hints with -O2
--- Comment #1 from dcb314 at hotmail dot com 2009-12-30 22:23 --- Created an attachment (id=19427) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19427action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42559
[Bug c/42557] gcc no compile for m68k(coff/elf)
--- Comment #1 from mikpe at it dot uu dot se 2009-12-30 22:40 --- (In reply to comment #0) I tried to compile gcc (4.4.1 and 4.4.2) for m68k-coff for Linux. I'm using Ubuntu 9.10 AMD64. However, I get an error stating that gas is not supported for the version of binutils (2.20) used: ... Configuring in ./gas ... This target is no longer supported in gas make[1]: *** [configure-gas] Error 1 make[1]: Leaving directory `/home/miltoncsl/Documents/coldfire/binutils-2.20' make: *** [all] Error 2 Confirmed, but this is a binutils problem so you should report it to them not us. binutils-2.16.1 does build for m68k-unknown-coff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42557
[Bug tree-optimization/42508] [4.5 Regression] wrong code with -O1 -fipa-sra
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org Keywords||wrong-code Summary|wrong code with -O1 -fipa- |[4.5 Regression] wrong code |sra|with -O1 -fipa-sra Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42508
[Bug target/42516] [m68k] Suboptimal halfword swap on coldfire
--- Comment #3 from schwab at gcc dot gnu dot org 2009-12-30 23:03 --- Subject: Bug 42516 Author: schwab Date: Wed Dec 30 23:03:46 2009 New Revision: 155527 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155527 Log: PR target/42516 * config/m68k/m68k.md (rotlsi_16): New insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42516
[Bug target/42516] [m68k] Suboptimal halfword swap on coldfire
--- Comment #4 from schwab at linux-m68k dot org 2009-12-30 23:04 --- Fixed. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42516
[Bug rtl-optimization/42258] [4.5 Regression] redundant register move around mul instruction
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|regression |rtl-optimization Keywords||missed-optimization, ra Summary|[4.5 only] redundant|[4.5 Regression] redundant |register move around mul|register move around mul |instruction |instruction Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
[Bug driver/41564] -fdump-tree-all for lto does not work as expected
--- Comment #9 from rguenther at suse dot de 2009-12-30 23:16 --- Subject: Re: -fdump-tree-all for lto does not work as expected On Wed, 23 Dec 2009, hjl dot tools at gmail dot com wrote: --- Comment #8 from hjl dot tools at gmail dot com 2009-12-23 21:01 --- Since LTO tree dump is quite different, can't we give it a different command line option, something like -fdump-tree-lto-all, instead of enabling it with -fdump-tree-all? It isn't really different. This is a driver issue, the dumps use possibly temporary file names as bases. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
[Bug lto/42531] FAIL: gcc.c-torture/compile/20011119-1.c
--- Comment #3 from davek at gcc dot gnu dot org 2009-12-30 23:21 --- Subject: Bug 42531 Author: davek Date: Wed Dec 30 23:20:55 2009 New Revision: 155528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155528 Log: PR lto/42531 * lto-streamer-out.c (produce_asm): Skip any leading asterisk when using DECL_ASSEMBLER_NAME to generate a section name. (copy_function): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42531
[Bug tree-optimization/42494] [4.4 Regression] Missed dead-code-elimination
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
[Bug driver/41564] -fdump-tree-all for lto does not work as expected
--- Comment #10 from hjl dot tools at gmail dot com 2009-12-30 23:27 --- (In reply to comment #9) Subject: Re: -fdump-tree-all for lto does not work as expected On Wed, 23 Dec 2009, hjl dot tools at gmail dot com wrote: --- Comment #8 from hjl dot tools at gmail dot com 2009-12-23 21:01 --- Since LTO tree dump is quite different, can't we give it a different command line option, something like -fdump-tree-lto-all, instead of enabling it with -fdump-tree-all? It isn't really different. This is a driver issue, the dumps use possibly temporary file names as bases. By different, I meant that LTO tree dumps are in a different directory and have different file name suffix that the normal tree dumps. You can't easily tell which tree dumps in the temporary directory are the ones generated by -fdump-tree-all you just ran. It is even worse when -fdump-tree-all -flto is run a few times by the same or different person. I don't think -fdump-tree-all should dump LTO tree by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
[Bug tree-optimization/42494] [4.4 Regression] Missed dead-code-elimination
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-30 23:34 --- The issue is that we do not do predicated value-numbering so we need multiple invocations of it. Which all of FRE, DOM and PRE do - but PRE is not run at -Os in 4.4. And yes, the optimization done by 4.5 is correct. You could say fixed in 4.5 - or wait for someone to implement predicated value-numbering to also fix a testcase with one more if (outcnt == 1) func (); -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
