Re: What's the policy for bug priorities, again
Richard Guenther wrote:
Note that all regressions from 4.4 that are visible with release
checking and valid input should be considered P1 first
I don't know, what is considered to be a showstopper,
but bad things happen inside 4.5 (x86-32/Cygwin + a
lot of SSE). In the last weekend I was able to:
a) ICE the compiler with a message SSA validation failed
or something like that;
b) in 32-bit mode generate an assembler error
~%bpl is not a recognized register when writing
to a volatile global variable;
c) to become 99.9% certain that the compiler generates
wrong code in at least one case, i.e.:
for(int i = k; i != 0;) {
if (fn(params)) {
continue;
}
gn();
}
gn() was not executed despite the fact fn() returned false.
d) 20100208 is not able to compile trunk (from yesterday),
because it gets stuck on, among other things, tree-ssa-structalias.o
I am not going to formally report these issues, as the testcases
are BIG, but IMHO there is no hurry to release 4.5, as it has
great chances to become a disaster, despite the fact of its wonderful
C++0x support.
Best regards
Piotr Wyderski
Problem in printf float values in range (-1 value 1)
Hi, We are porting gcc toolchain for a new target. Most of the functionalities are working fine as expected. However, there is one issue regarding the printf function. Issue - Float variables are prefixed by some garbage value in printf function. However, the values are generated correctly when seen through GDB. Ex:- If the expected result is 0.456 RUN OUTPUT - 0.00456 (INCORRECT) GDB OUTPUT - 0.456 (CORRECT) The above issue is observed only with the float variables less than one. i.e. error result if (-1 value 1) The values are displayed correctly if the value does not fall in above range. Ex:- If the expected result is 1.456 RUN OUTPUT - 1.456 (CORRECT) GDB OUTPUT - 1.456 (CORRECT) The above mentioned issue was not observed with gcc-3.4.4. However, on porting to gcc-4.4.1; we are observing this issue. Please let me know if there is anything missing in the port that would possibly result in above incorrect behavior. Thanks Regards, Naveen.H.S www.kpitgnutools.com
Re: What's the policy for bug priorities, again
On Thu, Feb 18, 2010 at 11:14 AM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
Richard Guenther wrote:
Note that all regressions from 4.4 that are visible with release
checking and valid input should be considered P1 first
I don't know, what is considered to be a showstopper,
but bad things happen inside 4.5 (x86-32/Cygwin + a
lot of SSE). In the last weekend I was able to:
a) ICE the compiler with a message SSA validation failed
or something like that;
b) in 32-bit mode generate an assembler error
~%bpl is not a recognized register when writing
to a volatile global variable;
c) to become 99.9% certain that the compiler generates
wrong code in at least one case, i.e.:
for(int i = k; i != 0;) {
if (fn(params)) {
continue;
}
gn();
}
gn() was not executed despite the fact fn() returned false.
d) 20100208 is not able to compile trunk (from yesterday),
because it gets stuck on, among other things, tree-ssa-structalias.o
I am not going to formally report these issues, as the testcases
are BIG, but IMHO there is no hurry to release 4.5, as it has
great chances to become a disaster, despite the fact of its wonderful
C++0x support.
If you don't report the issues nobody is going to notice them or
do something about them.
Richard.
Looking for an active mmix maintainer
Hi, I'd like to resolve one way or another an mmix issue in the library: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321 which is even marked as regression, and I need feedback / help from an active mmix maintainer, but apprently Hans-Peter Nilsson is not replying. Any hints, suggestions? Thanks, Paolo.
subscrite
i want to subscrite
Re: subscrite
On Thu, Feb 18, 2010 at 08:21, Elijah Simonov ngs.co...@gmail.com wrote: i want to subscrite Please visit http://gcc.gnu.org/lists.html#subscribe Diego.
Re: Problem in printf float values in range (-1 value 1)
On 18/02/2010 10:11, Naveen H. S wrote: Issue - Float variables are prefixed by some garbage value in printf function. However, the values are generated correctly when seen through GDB. Ex:- If the expected result is 0.456 RUN OUTPUT - 0.00456 (INCORRECT) GDB OUTPUT - 0.456 (CORRECT) The above issue is observed only with the float variables less than one. i.e. error result if (-1 value 1) The values are displayed correctly if the value does not fall in above range. Ex:- If the expected result is 1.456 RUN OUTPUT - 1.456 (CORRECT) GDB OUTPUT - 1.456 (CORRECT) The above mentioned issue was not observed with gcc-3.4.4. However, on porting to gcc-4.4.1; we are observing this issue. It's hard to imagine that this could be some kind of bug in the compiler's argument passing that was causing this effect, much more likely that there's a bug in your libc printf code, possibly some undefined behaviour that has only become a problem because of improvements to the optimisers in series 4; you'll probably have to debug your printf routine to see where it's going wrong. cheers, DaveK
Re: What's the policy for bug priorities, again
On 18/02/2010 10:20, Richard Guenther wrote: On Thu, Feb 18, 2010 at 11:14 AM, Piotr Wyderski wrote: Richard Guenther wrote: I don't know, what is considered to be a showstopper, but bad things happen inside 4.5 (x86-32/Cygwin + a lot of SSE). In the last weekend I was able to: If you don't report the issues nobody is going to notice them or do something about them. I'm currently frantically debugging as much as I can of Cygwin PRs in time for the release. I'm fixing a libjava bug right now and will be for the rest of today but haven't been noticing any major problems in the core compiler. Piotr, please do at least have a go at reducing a testcase for issue c), and maybe issue b) would be easy to produce one for as well. I'll spot d) if it shows up next time I bootstrap, but it's always possible there's something a bit odd in your build environment. cheers, DaveK
Re: No integral promotions when calling library function?
On 18/02/2010 07:17, Jie Zhang wrote: We are trying to add a 16bit integer division library function for bfin port. I just found GCC didn't do integral promotions when calling library function. Is this expected? I wasn't aware of this myself, but it kind-of makes sense given the way that macros such as FUNCTION_ARG and INIT_CUMULATIVE_ARGS don't get passed any type info in the case of libcalls; I'm guessing here, but that would imply to me that all libcalls are effectively using unnamed stdargs-style arg passing. Not sure how to check this theory without extensively reading the source though. I imagine it's done for efficiency, and there should always be libcall functions existing for the precise types you're passing? cheers, DaveK
Change x86 default arch for 4.5?
I periodically get bitten by bug 34115: a compiler configured without --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would only need to bump the default to i486 to get atomic support. Can we reconsider the default for 4.5? Jason
gcc-4.5-20100218 is now available
Snapshot gcc-4.5-20100218 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100218/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 156878 You'll find: gcc-4.5-20100218.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100218.tar.bz2 C front end and core compiler gcc-ada-4.5-20100218.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100218.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100218.tar.bz2 C++ front end and runtime gcc-java-4.5-20100218.tar.bz2 Java front end and runtime gcc-objc-4.5-20100218.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100218.tar.bz2The GCC testsuite Diffs from 4.5-20100211 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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: No integral promotions when calling library function?
On Fri, Feb 19, 2010 at 12:03 AM, Dave Korn dave.korn.cyg...@googlemail.com wrote: On 18/02/2010 07:17, Jie Zhang wrote: We are trying to add a 16bit integer division library function for bfin port. I just found GCC didn't do integral promotions when calling library function. Is this expected? I wasn't aware of this myself, but it kind-of makes sense given the way that macros such as FUNCTION_ARG and INIT_CUMULATIVE_ARGS don't get passed any type info in the case of libcalls; I'm guessing here, but that would imply to me that all libcalls are effectively using unnamed stdargs-style arg passing. Not sure how to check this theory without extensively reading the source though. I imagine it's done for efficiency, and there should always be libcall functions existing for the precise types you're passing? I'm trying to use an existing division function as a library function. This existing function does unsigned 16bit integral division and expects both arguments have been zero extended to 32bit. It's a little surprise for me that GCC does not do the promotion when calling library function even TARGET_PROMOTE_PROTOTYPES is defined. I can adjust the division function accordingly. But before I do that, I'd like to know if library functions should follow the same convention as the normal ones or not. Jie
Re: Change x86 default arch for 4.5?
On Thu, Feb 18, 2010 at 02:09:14PM -0800, Jason Merrill wrote: I periodically get bitten by bug 34115: a compiler configured without --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would only need to bump the default to i486 to get atomic support. Can we reconsider the default for 4.5? Is anyone still manufacturing x86 CPUs that don't support the atomic instructions?
Re: Change x86 default arch for 4.5?
On 02/18/2010 03:30 PM, Joe Buck wrote: On Thu, Feb 18, 2010 at 02:09:14PM -0800, Jason Merrill wrote: I periodically get bitten by bug 34115: a compiler configured without --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would only need to bump the default to i486 to get atomic support. Can we reconsider the default for 4.5? Is anyone still manufacturing x86 CPUs that don't support the atomic instructions? Should it just be a question of 'manufacturing'? Or should 'using' be a criterion for any decision? Not that I disagree with Jason's suggestion, it is probably the right choice. David Daney
Re: Change x86 default arch for 4.5?
On Thu, 18 Feb 2010, Jason Merrill wrote: I periodically get bitten by bug 34115: a compiler configured without --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would only need to bump the default to i486 to get atomic support. Can we reconsider the default for 4.5? My position remains that configuring for i686-* should default to -march=i686 rather than -mtune=i686. http://gcc.gnu.org/ml/gcc/2008-06/msg00223.html http://gcc.gnu.org/ml/gcc/2008-08/msg00445.html Perhaps someone would like to review HJ's patch to that effect? http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html This will probably break building glibc, as problems building when __i686 is a predefined macro have been known since at least 2002 but none of the many patches proposed since then have been accepted. http://sourceware.org/ml/libc-alpha/2002-10/msg00156.html ... http://sourceware.org/ml/libc-alpha/2009-07/msg00072.html -- Joseph S. Myers jos...@codesourcery.com
Re: Change x86 default arch for 4.5?
On Thu, Feb 18, 2010 at 04:31:37PM -0800, David Daney wrote: On 02/18/2010 03:30 PM, Joe Buck wrote: On Thu, Feb 18, 2010 at 02:09:14PM -0800, Jason Merrill wrote: I periodically get bitten by bug 34115: a compiler configured without --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would only need to bump the default to i486 to get atomic support. Can we reconsider the default for 4.5? Is anyone still manufacturing x86 CPUs that don't support the atomic instructions? Should it just be a question of 'manufacturing'? Or should 'using' be a criterion for any decision? Not that I disagree with Jason's suggestion, it is probably the right choice. using would be the right criterion if Jason were advocating removing support for i386 but he only proposed changing the default. But maybe I didn't ask the right question: can any x86 experts comment on recently made x86 CPUs that would not function correctly with code produced by --with-arch=i486? Are there any?
Re: Change x86 default arch for 4.5?
On 2/18/2010 4:54 PM, Joe Buck wrote: But maybe I didn't ask the right question: can any x86 experts comment on recently made x86 CPUs that would not function correctly with code produced by --with-arch=i486? Are there any? All CPUs still in production are at least SSE3 capable, unless someone can come up with one of which I'm not aware. Intel compilers made the switch last year to requiring SSE2 capability for the host, as well as in the default target options, even for 32-bit. All x86_64 or X64 CPUs for which any compiler was produced had SSE2 capability, so it is required for those 64-bit targets. -- Tim Prince
Re: Change x86 default arch for 4.5?
On 02/18/2010 07:46 PM, Joseph S. Myers wrote: On Thu, 18 Feb 2010, Jason Merrill wrote: I periodically get bitten by bug 34115: a compiler configured without --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would only need to bump the default to i486 to get atomic support. Can we reconsider the default for 4.5? My position remains that configuring for i686-* should default to -march=i686 rather than -mtune=i686. That makes sense to me. Perhaps someone would like to review HJ's patch to that effect? http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02078.html Using all the noncanonical variants as arch defaults makes me a bit nervous, but I suppose if someone actually writes $GCC/configure nocona-pc-linux-gnu that's what they would expect to get... This will probably break building glibc, as problems building when __i686 is a predefined macro have been known since at least 2002 but none of the many patches proposed since then have been accepted. I imagine changing the default would help with that...and packagers can work around it. Jason
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #25 from dominiq at lps dot ens dot fr 2010-02-18 08:00 ---
Would you mind testing the attached patch?
Apparently the patch in comment #23 does not fix the problem (incremental
update of gcc and partial test):
make -k check-gfortran RUNTESTFLAGS=dg.exp=complex*.f90
--target_board=unix'{-m32,-m64}'
Running target unix/-m32
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/dg.exp ...
=== gfortran Summary for unix/-m32 ===
# of expected passes104
Running target unix/-m64
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -fomit-frame-pointer
-funroll-loops execution test
FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
=== gfortran Summary for unix/-m64 ===
# of expected passes102
# of unexpected failures2
=== gfortran Summary ===
# of expected passes206
# of unexpected failures2
/opt/gcc/darwin_buildw/gcc/testsuite/gfortran/../../gfortran version 4.5.0
20100215 (experimental) [trunk revision 156774p2] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug inline-asm/43112] 'A' constraint's behavior not compliant with doc under x86-64
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-18 08:56 --- You just misunderstand it. You'd need a 128-bit int __attribute__((mode (TI))) value if you want it to mean a pair, because for -m64 registers are 64-bit. If you use smaller precision type, A constraint acts just as a constraint allowing both ax and dx registers and it is up to the compiler which one it chooses. rdtsc returns result in %eax and %edx, even for 64-bit code, so you need to use unsigned int low, high; =a (low), =d (high) and then combine that into a 64-bit value. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43112
[Bug fortran/43111] [4.5 Regression] No temporary produced for array pointer actual arguments
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-18 09:25 --- Why is this marked as 4.4 regression? According to my regression hunt it fails since the patch http://gcc.gnu.org/viewcvs?view=revisionrevision=156749 which has only be committed to the trunk. I just checked and the test case of comment #0 still works with a 6h old gcc-4_4-branch. - Thus I mark this as 4.5 only. * * * By the way, the Fortran 2008 standard lists in 5.3.7 CONTIGUOUS attribute 6.5.4 Simply contiguous array designators some things which are/aren't contiguous in Fortran; maybe one should browse that list just to get some more ideas (both for optimization and for avoiding over-optimization). See: ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1791.pdf -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2010-02-18 09:25:19 date|| Summary|[4.4, 4.5 regression] No|[4.5 Regression] No |temporary produced for array|temporary produced for array |pointer actual arguments|pointer actual arguments Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43111
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #17 from paolo dot carlini at oracle dot com 2010-02-18 09:36 --- (In reply to comment #16) I don't understand why all libstdc++ headers should not have #pragma GCC system_header in them. Would you please explain that? Hi Mark. For sure all the *library proper* headers should have (and afaik, have already) the pragma. If I understand correctly, the doubt is about the libsupc++ headers: at some point in the past we discussed that briefly and we came to the conclusion that if we could avoid decorating those too it would be cleaner (Gaby agreed, I'm 100% sure). But indeed, nothing set in stone, at least for 4.5.x, if we want to decorate the few user visibile headers in libsupc++, I do not object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug target/43107] [4.5 Regression] ICE: SIGSEGV with -O3 -mavx
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Component|tree-optimization |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 09:40:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43107
[Bug c++/43108] mixed complexT multiplication horribly inefficient
--- Comment #28 from paolo dot carlini at oracle dot com 2010-02-18 09:42 --- Thanks Gaby, eventually I learned something ;) Hopefully the remaining correctness issues can be fixed quickly in the C++ front-end, honestly before this PR I wasn't aware of any correctness regression in this area, that is treatment of signed zeros. Performance, that could be also a problem for some users, I think we should anyway add a note to the 4.5 changes explaining the use of -fno-signed-zeros, both for C and C++, in that case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug tree-optimization/43074] [4.4/4.5 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:3491
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-18 09:43 --- Yep. Fixed. Thanks Ira. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.4.3 Known to work||4.4.4 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43074
[Bug c++/43108] mixed complexT multiplication horribly inefficient
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-02-18 09:46 --- (In reply to comment #28) Thanks Gaby, eventually I learned something ;) Hopefully the remaining correctness issues can be fixed quickly in the C++ front-end, honestly before this PR I wasn't aware of any correctness regression in this area, that is treatment of signed zeros. Performance, that could be also a problem for some users, I think we should anyway add a note to the 4.5 changes explaining the use of -fno-signed-zeros, both for C and C++, in that case. C performance is fine. Joseph fixed it for the C frontend and the fallout is that it regressed for the C++ frontend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug target/43107] [4.5 Regression] ICE: SIGSEGV with -O3 -mavx
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-18 09:48 --- Created an attachment (id=19904) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19904action=view) gcc45-pr43107.patch Fix, tested so far just on this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43107
[Bug c++/43108] mixed complexT multiplication horribly inefficient
--- Comment #30 from paolo dot carlini at oracle dot com 2010-02-18 09:53 --- Argh, so the C front-end manages to be both correct and fast. We should definitely do something about C++... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug ada/43096] [4.5 Regression] ACATS c37105a wrong-code on arm-linux
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-02-18 09:56 --- Looking into it. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 09:56:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43096
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-18 10:00 --- Dave, what do you recommend about this issue? Does it affect cygwin too? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|loaden at gmail dot com |dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-18 10:12 --- In short, I see two conceptually separate issues: 1- We run the configure tests for those functions in GNU mode, thus if on a target an header doesn't declare some functions in ISO strict mode, the user experiences puzzling errors, like in Comment #1; 2- Specific to MingW (and Cygwin too?!?), those C99 names do not correspond to functions implementing the actual C99 semantics, arguably should indeed not be exposed in strict ISO mode. Thus, my doubt is: should we actually run those configure tests in strict ISO mode, instead of GNU mode? For Linux would not make a difference, and would avoid puzzling errors like those experienced by MingW users. However, I'm afraid some users, on other systems, could be disappointed in finding fewer functions declared in the C++ headers (in namespace std) in GNU mode (which is the default!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug fortran/43111] [4.5 Regression] No temporary produced for array pointer actual arguments
--- Comment #2 from pault at gcc dot gnu dot org 2010-02-18 10:26 --- (In reply to comment #1) Why is this marked as 4.4 regression? According to my regression hunt it fails since the patch http://gcc.gnu.org/viewcvs?view=revisionrevision=156749 which has only be committed to the trunk. I just checked and the test case of comment #0 still works with a 6h old gcc-4_4-branch. - Thus I mark this as 4.5 only. My mistake - OK! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2010-02-18 09:25:19 |2010-02-18 10:26:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43111
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #26 from bernds_cb1 at t-online dot de 2010-02-18 11:51 --- Created an attachment (id=19905) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19905action=view) A patch to help debug the problem I'll need some help since on my system a compiler targetting powerpc-apple-darwin9 produces rather different output in the dumps than what is attached to this bug. The powerpc-linux failures look unrelated as they appear even at -O0. If the problem really is in regrename, the attached patch should help debug it. If you wish to help, please follow these instructions. You'll need to use a kind of binary search using the -fdbg-cnt=rnreg:N option, where N is an integer. Start with something small, maybe even 1, then double it until the failure appears. Then do a binary search between the last number that produced a working binary, and the one that did not. You should end up with a value of N such that -fdbg-cnt=rnreg:N produces a working executable, and -fdbg-cnt=rnreg:N+1 does not. Please attach the .rnreg dumps and assembly files for both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #27 from dominiq at lps dot ens dot fr 2010-02-18 12:17 --- You'll need to use a kind of binary search using the -fdbg-cnt=rnreg:N option, where N is an integer. Start with something small, maybe even 1, then double it until the failure appears. Then do a binary search between the last number that produced a working binary, and the one that did not. Should I use '-fdbg-cnt=rnreg:N' to build gcc or only when testing complex_intrinsic_5.f90? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #28 from bernds_cb1 at t-online dot de 2010-02-18 12:21 --- Only when building the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42233] [4.3/4.4/4.5 regression] c++ builtin_expect code generation regression
--- Comment #7 from jakub at gcc dot gnu dot org 2010-02-18 12:30 --- On the 4.4 branch actually cc1 behaves differently from cc1plus. In any case, I believe the two setne's plus testb code is actually the worst of the options, and e.g. with -Os it is even much larger. Just compile the testcase on 4.5 with -Os and -Os -D'__builtin_expect(a,b)=(a)' In the former case (i.e. with __builtin_expect) if generates: cmpq%rcx, %rdx sete%dl xorl%eax, %eax cmpq%rsi, %rdi movzbl %dl, %edx sete%al testl %eax, %edx je .L2 xorl%eax, %eax jmp likely .L2: xorl%eax, %eax jmp unlikely while in the latter case generates: cmpq%rcx, %rdx jne .L2 cmpq%rsi, %rdi jne .L2 xorl%eax, %eax jmp likely .L2: xorl%eax, %eax jmp unlikely (what would be actually the best code for -O2 when __builtin_expect is used and tells that likely () is likely). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Known to work|4.1.2 4.5.0 |4.1.2 Summary|[4.3/4.4 regression] c++|[4.3/4.4/4.5 regression] c++ |builtin_expect code |builtin_expect code |generation regression |generation regression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42233
[Bug middle-end/42233] [4.3/4.4/4.5 regression] c++ builtin_expect code generation regression
--- Comment #8 from jakub at gcc dot gnu dot org 2010-02-18 12:47 --- Created an attachment (id=19906) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19906action=view) gcc45-pr42233.patch The reason why it behaves differently with __builtin_expect from normal condition is that in the latter case gimple_boolify changes the types of the comparisons etc. to _Bool, while for __builtin_expect it doesn't recurse into its first argument. The attached patch fixes that. Then we are back to the 4.3 generated code, i.e. the same as is generated without __builtin_expect. At this point the problem is described in a comment above add_reg_br_prob_note: /* Verify that there is exactly single jump instruction since last and attach REG_BR_PROB note specifying probability. ??? We really ought to pass the probability down to RTL expanders and let it re-distribute it when the conditional expands into multiple conditionals. This is however difficult to do. */ Since here there are two jumps, not one, no REG_BR_PROB note is added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42233
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #11 from davek at gcc dot gnu dot org 2010-02-18 12:54 --- (In reply to comment #9) Dave, what do you recommend about this issue? Does it affect cygwin too? This particular problem doesn't occur on cygwin, but we've had similar issues in the past with pre-c99 headers on cygwin (arising from newlib), although it was easier there, since we did actually have the functionality available, so just had to change the headers to make sure it was declared in __STRICT_ANSI__ mode. I don't know how the MinGW guys would best like to go about tackling this, but I'd certainly not suggest changing the configury for /all/ hosts. Adding a host-specific CFLAGs entry during the configure tests would be one way of handling it at the compiler end. Adding the required support in the mingw library will be the ultimate way of handling it. A third option would be for mingw to alias their current _(v)swprintf implementations to the required names as a stop-gap measure, on the grounds that since the resulting compiler/toolchain is going to be not fully conformant anyway until the functions are added, a slightly sub-spec implementation is preferable to an entirely missing one. Danny, it's your call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug target/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #12 from ramana at gcc dot gnu dot org 2010-02-18 13:13 --- Subject: Bug 40887 Author: ramana Date: Thu Feb 18 13:13:03 2010 New Revision: 156862 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156862 Log: PR target/40887 Backport from trunk. 2009-12-24 Julian Brown jul...@codesourcery.com Ramana Radhakrishnan ramana.radhakrish...@arm.com * config/arm/arm.c (output_call_mem): Remove armv5 support. * config/arm/arm.md (*call_mem): Disable for armv5. Add note. (*call_value_mem): Likewise. PR target/40887 Backport from trunk. 2009-12-24 Julian Brown jul...@codesourcery.com Ramana Radhakrishnan ramana.radhakrish...@arm.com * gcc.target/arm/pr40887.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/pr40887.c - copied unchanged from r155453, trunk/gcc/testsuite/gcc.target/arm/pr40887.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/arm/arm.c branches/gcc-4_4-branch/gcc/config/arm/arm.md branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug middle-end/42233] [4.3/4.4/4.5 regression] c++ builtin_expect code generation regression
--- Comment #9 from bonzini at gnu dot org 2010-02-18 13:17 --- I'm relieved that cond-optab is in no way related to this. :-) I'm not expert of the gimplifier but the patch makes sense and looks good. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 13:17:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42233
[Bug target/29560] [avr] Poor optimization for byte shifts
--- Comment #5 from Rudolf dot Leitgeb at gmx dot at 2010-02-18 13:28 --- Right away: I am NOT an expert in compiler or optimizer design, so please bear with me. I understand, that (((unsigned char)1) ((unsigned char)something)) may need more than 8 bits for representation and that gcc's default int size on the ATmega platform is 16 bits. But the result is assigned to an 8 bit value. I take it that there is no way to back propagate this potential optimization from the assignment to the shifting step. If you look in my assembly code, r25 is computed with great effort yet never transferred anywhere. The trick with 7 is nice but introduces another unnecessary AND operation. And it is only correct if the input numebr is guaranteed to be between 0 and 7. Am I correct that this whole optimization issue comes from the fact that ATmega is an 8 bit architecture yet gcc's int on that platform is 16 bit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29560
[Bug c++/43113] New: too long diagnostics in some cases of recursive template instantiation
testcase.cpp
template typename
struct A {
struct S;
A S ht;
};
struct B : A B {};
--
without -ftemplate-depth, it instantiates templates up do default depth, giving
760KiB of diagnostics for this simple testcase (for 4.5.0)
this is output with -ftemplate-depth-5:
$ g++ testcase.cpp -ftemplate-depth-5
testcase.cpp:4: error: template instantiation depth exceeds maximum of 5 (use
-ftemplate-depth-NN to increase the maximum) instantiating 'struct
AAB::S::S::S::S::S'
testcase.cpp:4: instantiated from 'AB::S::S::S::S'
testcase.cpp:4: instantiated from 'B::S::S::S'
testcase.cpp:4: instantiated from 'AAAB::S::S'
testcase.cpp:4: instantiated from 'AAB::S'
testcase.cpp:4: instantiated from 'AB'
testcase.cpp:7: instantiated from here
testcase.cpp:4: error: 'A template-parameter-1-1 ::ht' has incomplete type
testcase.cpp:2: error: declaration of 'struct
AAB::S::S::S::S::S'
--
all tested gcc versions behave the same - 2.95, 3.2.3, 3.3.6, 3.4.6, 4.0.4,
4.1.2, 4.2.4, 4.3.4, 4.4.3, 4.5.0 (with the exception that 2.95 bails out at
the end, and 3.2.3 and 2.95 need quite long time for even template depth 20)
--
Summary: too long diagnostics in some cases of recursive template
instantiation
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43113
[Bug target/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #13 from ramana at gcc dot gnu dot org 2010-02-18 13:34 --- Fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug c++/43114] New: GCC 4.4.1 problems with include
Overview Description: GCC version: 4.4.1 System info: 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux, Ubuntu 9.10 GCC I used was the Ubuntu 9.10 native c++ compiler, installed using Synaptic package manager. The case is the following: There are two files to be compiled: cpp and hpp. x.hpp contains only the f() function prototype. x.cpp contains the f() function implementation and main(). x.cpp file includes the x.hpp. g++ -c x.hpp - this command generates x.hpp.gch file. After this the command g++ x.cpp gives the following error: x.cpp: In function int f(): x.cpp:3: error: redefinition of int f() x.hpp:2: error: int f() previously defined here. In some cases it is not reproducible. -- Summary: GCC 4.4.1 problems with include Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nar dot martirosyan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43114
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #29 from dominiq at lps dot ens dot fr 2010-02-18 13:42 --- In order to compile gcc/regrename.c, I had to add + enum debug_counter rnreg; Is this right? Then compiling the test with gfc -fdbg-cnt=rnreg:1 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 I get the following error f951: error: Can not find a valid counter:value pair: f951: error: -fdbg-cnt=rnreg:1 f951: error: ^ What is missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #30 from steven at gcc dot gnu dot org 2010-02-18 13:53 --- It looks like there should be a patch to dbgcnt.def. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #31 from dominiq at lps dot ens dot fr 2010-02-18 14:06 --- It looks like there should be a patch to dbgcnt.def. Does this mean that I should remove the line + enum debug_counter rnreg; I have added, and add a line DEBUG_COUNTER (rnreg) in dbgcnt.def? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-18 14:10 --- Created an attachment (id=19907) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19907action=view) Draft patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-18 14:11 --- Gaby, I just attached a draft patch which essentially does what submitter requested, adds the two specializations. Shall we do this? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||gdr at integrable-solutions ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #32 from bernds_cb1 at t-online dot de 2010-02-18 14:17 --- Created an attachment (id=19908) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19908action=view) Additional patch on top of the previous one Sorry about that. Yes, you'll need to add that in dbgcnt.def, or just apply this additional patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug c++/43113] too long diagnostics in some cases of recursive template instantiation
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-18 14:18 --- *** This bug has been marked as a duplicate of 9335 *** -- 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=43113
[Bug c++/9335] Inordinately long output when maximum template depth is exceeded
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-18 14:18 --- *** Bug 43113 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||zsojka at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #33 from dominiq at lps dot ens dot fr 2010-02-18 14:22 --- Sorry about that. Yes, you'll need to add that in dbgcnt.def, or just apply this additional patch. This recompiles most of gcc!-(it will take a couple hours on my poor G5!-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug tree-optimization/43066] [4.5 Regression] ICE: SIGFPE with empty struct and va_arg
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-02-18 14:53 --- Subject: Bug 43066 Author: jamborm Date: Thu Feb 18 14:53:05 2010 New Revision: 156863 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156863 Log: 2010-02-18 Martin Jambor mjam...@suse.cz PR tree-optimization/43066 * tree-sra.c (build_ref_for_offset_1): Return false on encountering an array with zero-sized element type. * testsuite/gcc.c-torture/compile/pr43066.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr43066.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43066
[Bug middle-end/42233] [4.3/4.4/4.5 regression] c++ builtin_expect code generation regression
--- Comment #10 from jakub at gcc dot gnu dot org 2010-02-18 15:04 --- Created an attachment (id=19909) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19909action=view) gcc45-pr42233-2.patch Trunk patch that seems to fix this together with the previous patch. Going to bootstrap/regtest both now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42233
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #34 from dominiq at lps dot ens dot fr 2010-02-18 15:08 --- And the winner is N=137! [karma] f90/bug% gfc -fdbg-cnt=rnreg:137 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 dbg_cnt 'rnreg' set to 137 [karma] f90/bug% a.out [karma] f90/bug% gfc -fdbg-cnt=rnreg:138 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 dbg_cnt 'rnreg' set to 138 [karma] f90/bug% a.out check4: z=.000 + I .000 zref=1.000 + I .000 Diff: -1.000 + I*.000 eps=.23841858E-06 Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #1 from matz at gcc dot gnu dot org 2010-02-18 15:13 --- Created an attachment (id=19910) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19910action=view) candidate fix Try this. I don't know how to write guality tests, but I think it has the effects you look for, at least the debug_insn now refer to existing things. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #18 from mmitchel at gcc dot gnu dot org 2010-02-18 15:13 --- Paolo -- I think libsupc++ is just as much a system library as libstdc++. It doesn't have an ISO-standard API, of course, but that's not the point; it's just as much a part of the system/implementation as libstdc++. To the extent a program is going to use a header that we ship from libsupc++, that program certainly doesn't want to get random warnings about those headers. However, Julian Brown warns me that he's been playing with this and that it doesn't entirely solve the problem. It may be that my earlier patch to arm.c is insufficient in some cases. So, I'd like the libstdc++ maintainers to make the change to the libsupc++ headers -- unless someone can articulate a good reason not to do so of course -- but there may still be more work to do. We will continue to investigate the possible non-workingness of the patch. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #19 from paolo dot carlini at oracle dot com 2010-02-18 15:24 --- Ok, it's just an handful of files, after all. If Julian wants to add the pragmas, the change is pre-approved, otherwise, just let me know when you have the other issues under control, and I'll do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #35 from bernds_cb1 at t-online dot de 2010-02-18 15:32 --- Okay, great. Could you attach the .rnreg dumps and assembly output for both values? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #36 from dominiq at lps dot ens dot fr 2010-02-18 15:38 --- Could you attach the .rnreg dumps How do I get them? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #5 from hjl dot tools at gmail dot com 2010-02-18 15:40 --- Revision 156792: http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00375.html made ICE disappear. I don't know if it really fixes the bug or just hides it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #37 from dominiq at lps dot ens dot fr 2010-02-18 15:40 --- Created an attachment (id=19911) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19911action=view) Assembly for -fdbg-cnt=rnreg:137 Command used gfc -S -fdbg-cnt=rnreg:137 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #38 from dominiq at lps dot ens dot fr 2010-02-18 15:41 --- Created an attachment (id=19912) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19912action=view) Assembly for -fdbg-cnt=rnreg:138 Command line gfc -S -fdbg-cnt=rnreg:138 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-18 15:46 --- Created an attachment (id=19913) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19913action=view) gcc45-pr43077-test.patch Here is a guality testcase for it. Before the patch there is just lots of FAILs, with the patch most of them are gone on both x86_64-linux -m64 and -m32, though not all. Will look at those later, I have Alex have some pending patches so will also try with them. So the patch looks good, at least on this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #39 from bernds_cb1 at t-online dot de 2010-02-18 15:52 --- (In reply to comment #36) Could you attach the .rnreg dumps How do I get them? -fdump-rtl-rnreg-details -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #40 from dominiq at lps dot ens dot fr 2010-02-18 15:58 --- Created an attachment (id=19914) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19914action=view) .rnreg for -fdbg-cnt=rnreg:137 Command used fc -fdump-rtl-rnreg-details -fdbg-cnt=rnreg:137 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #41 from dominiq at lps dot ens dot fr 2010-02-18 15:59 --- Created an attachment (id=19915) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19915action=view) .rnreg for -fdbg-cnt=rnreg:138 Command line gfc -fdump-rtl-rnreg-details -fdbg-cnt=rnreg:138 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #3 from matz at gcc dot gnu dot org 2010-02-18 16:12 --- At least varb isn't printed in fn3, because dse2 (after prologue_epilogue) makes the expressions in the debug_insn be (clobber 0). Presumably because frame elimination rewrites the address-takings, but not the debug instructions, hence it thinks they are uninited stores, as they still refer to the frame pointer, not the stack pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug fortran/41209] Add full ATTRIBUTE support to gfortran (ALIGN, (WEAK)ALIAS, ...)
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-18 16:19 --- Another request for this feature: http://gcc.gnu.org/ml/fortran/2010-02/msg00144.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209
[Bug c++/43109] [4.5 Regression] ICE: SIGSEGV with unnamed namespace inside named
--- Comment #1 from jason at gcc dot gnu dot org 2010-02-18 16:27 --- Subject: Bug 43109 Author: jason Date: Thu Feb 18 16:27:07 2010 New Revision: 156864 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156864 Log: PR c++/43109 * semantics.c (begin_class_definition): Don't crash on unnamed ns. Added: trunk/gcc/testsuite/g++.dg/parse/namespace12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43109
[Bug c++/43101] [4.4/4.5 regression] Rejects template with const static data member used in return type
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-18 16:27 --- Subject: Bug 43101 Author: jason Date: Thu Feb 18 16:27:18 2010 New Revision: 156865 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156865 Log: PR c++/26261 PR c++/43101 * pt.c (tsubst_qualified_id): Do normal lookup in non-dependent scope. (maybe_update_decl_type): New fn. * parser.c (cp_parser_init_declarator): Use it. Added: trunk/gcc/testsuite/g++.dg/template/dependent-name6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43101
[Bug c++/26261] Rejects template with const static data member used in return type
--- Comment #13 from jason at gcc dot gnu dot org 2010-02-18 16:27 --- Subject: Bug 26261 Author: jason Date: Thu Feb 18 16:27:18 2010 New Revision: 156865 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156865 Log: PR c++/26261 PR c++/43101 * pt.c (tsubst_qualified_id): Do normal lookup in non-dependent scope. (maybe_update_decl_type): New fn. * parser.c (cp_parser_init_declarator): Use it. Added: trunk/gcc/testsuite/g++.dg/template/dependent-name6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug c++/43101] [4.4/4.5 regression] Rejects template with const static data member used in return type
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-18 16:28 --- *** This bug has been marked as a duplicate of 26261 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43101
[Bug c++/26261] Rejects template with const static data member used in return type
--- Comment #14 from jason at gcc dot gnu dot org 2010-02-18 16:28 --- *** Bug 43101 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug c++/26261] Rejects template with const static data member used in return type
--- Comment #15 from jason at gcc dot gnu dot org 2010-02-18 16:28 --- Fixed for 4.5. -- jason at gcc dot gnu 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=26261
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #4 from matz at gcc dot gnu dot org 2010-02-18 16:40 --- Created an attachment (id=19916) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19916action=view) do reg elimination This will fix some more of the var[bc] references by eliminating all registers in DEBUG_INSN_P. As I'm ignoring DEBUG_INSNs for effects that might change elimination results, this should not result in code changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #5 from matz at gcc dot gnu dot org 2010-02-18 16:50 --- That leaves 'c' which isn't printed, because the setup of c (a stackslot) is schedules to be part of the function call setup, the breakpoint is before that setup, and hence the location of 'c' does point to the correct one (namely its stackslot), but that one isn't initialized yet. One problem might be that there's no DEBUG_BIND insn generated for c at all. Or alternatively, once the stack slot initialization is moved down that no debug_insn is generated at it's original place to refer to the value 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug c++/43108] [4.5 regression] mixed complexT multiplication horribly inefficient
--- Comment #31 from jason at gcc dot gnu dot org 2010-02-18 16:52 --- Performance regression. -- jason at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|mixed complexT|[4.5 regression] mixed |multiplication horribly |complexT multiplication |inefficient |horribly inefficient Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug c++/9990] locale_facets.h contains invalid typedef
--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-18 16:56 --- For the record, all the compilers I have at hand, EDG based too, accept this in the most strict mode. I seriously doubt there is really something to fix here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
[Bug c++/43070] [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 17:07:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
[Bug target/43070] [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-18 17:42 --- The problem turns out to be that the patch for PR 6196 was wrong; ext/label[12].C are ill-formed, as both are trying to goto the address of an array rather than an element. -- jason at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
[Bug c++/43108] [4.5 regression] mixed complexT multiplication horribly inefficient
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 17:54:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug fortran/43115] New: bug with gfortran on Windows vista, correct on Linux
listing of the gfortran program whith the bug use iso_fortran_env implicit none integer,parameter:: mligne = 1,n2 = 10 character(len = n2 + 2):: ligne ! the bug is here : 2 is not necessary for reading essai.f95 : 10 max character per line ! character(len = n2):: ligne ! the bug is here did not work : only 8 max character per line ! character(len = n2 + 1):: ligne ! the bug is here did not work : only 9 max character per line character(len = 260):: string integer:: i,j,iosta,nligne write(output_unit,*) ' name of he file to read' read(input_unit,*) string open(unit = 7,action = 'read',file = string) do i = 1,mligne read(unit = 7,fmt = '(a)',iostat = iosta) ligne if(iosta .eq. iostat_end) go to 100 if(iosta .eq. iostat_eor) go to 200 200continue end do 100 continue close(unit = 7) nligne = i - 1 write(6,*) number of read lines = ,nligne end listing of the file not correctly read : essai.f95 : 12345 123456 1234567 12345678 123456789 1234567890 123456789 12345678 1234567 123456 12345 Because no bug on Linux : end of line : Carriage return + form feed ? -- Summary: bug with gfortran on Windows vista, correct on Linux Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cgerdy at wanadoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43115
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #42 from bernds_cb1 at t-online dot de 2010-02-18 18:13 --- Created an attachment (id=19917) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19917action=view) Another test patch that attempts to fix the problem. Could you test whether this fixes it? -- bernds_cb1 at t-online dot de changed: What|Removed |Added Attachment #19900|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug fortran/43115] bug with gfortran on Windows vista, correct on Linux
--- Comment #1 from kargl at gcc dot gnu dot org 2010-02-18 18:15 --- Please attach the files to the PR. Cut and paste from bugzilla will mangle the files; particularly, if it is a CRLF problem. Also, try removing your iostat usage and see if the the operating system generates an error, or use iomsg. Something like str = 'OK' open(unit = 7, action = 'read', file = string) do i = 1,mligne read(unit = 7, fmt = '(a)', iostat = iosta, iomsg=str) ligne print *, trim(str) On FreeBSD, I get troutmask:sgk[223] ./z name of he file to read abc OK OK OK OK OK OK OK OK OK OK OK End of file number of read lines = 11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43115
[Bug debug/43084] [4.5 Regression] ICE -fipa-struct-reorg -g (VTA)
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-18 18:31 --- (gdb) p debug_gimple_stmt (new_stmt) # DEBUG p = s This was caused by the introduction of debug statements. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Component|tree-optimization |debug GCC host triplet|x86_64-pc-linux-gnu | GCC target triplet|x86_64-pc-linux-gnu | Keywords||ice-on-valid-code Summary|[4.5 Regression] ICE: in|[4.5 Regression] ICE -fipa- |find_new_var_of_type, at|struct-reorg -g (VTA) |ipa-struct-reorg.c:604 with | |-fipa-struct-reorg -g | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43084
[Bug tree-optimization/43097] [4.5 Regression] ICE in rename_map_elt_info for Graphite, vect in 173.applu
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-18 18:36 --- Happens on x86_64-linux-gnu also even without -ftree-vectorize. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|powerpc64-linux | Last reconfirmed|-00-00 00:00:00 |2010-02-18 18:36:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43097
[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-18 18:38 --- Confirmed backtrace: #0 0x00801625 in link_block (b=0x7f9f943dcaf8, after=0x7f9f943dc138) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfg.c:153 #1 0x012b8fb6 in create_bb (h=0x0, e=0x0, after=0x7f9f943dc138) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-cfg.c:444 #2 0x00863a60 in create_basic_block (head=0x0, end=0x0, after=0x7f9f943dc138) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfghooks.c:621 #3 0x00863ac1 in create_empty_bb (after=0x7f9f943dc138) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfghooks.c:636 #4 0x012c7d00 in gimple_split_block (bb=0x7f9f943dc138, stmt=0x0) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-cfg.c:4812 #5 0x008633d7 in split_block (bb=0x7f9f943dc138, i=0x0) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfghooks.c:433 #6 0x00863510 in split_block_after_labels (bb=0x7f9f943dc138) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfghooks.c:471 #7 0x00863e00 in make_forwarder_block (bb=0x7f9f943dc138, redirect_edge_p=0x2532697 sd_region_without_exit, new_bb_cbk=0) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfghooks.c:737 #8 0x0253271e in create_single_exit_edge (region=0x47afff8) at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:965 #9 0x025329f1 in create_sese_edges (regions=0x47affd0) at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:1034 #10 0x0253338c in build_scops (scops=0x7fff14b44e20) at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:1327 #11 0x0245f015 in graphite_transform_loops () at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite.c:260 #12 0x01906459 in graphite_transforms () at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-loop.c:300 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 18:38:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-18 18:39 --- #8 0x0253271e in create_single_exit_edge (region=0x47afff8) at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:965 965 forwarder = make_forwarder_block (exit, sd_region_without_exit, NULL); (gdb) p debug_bb(exit) ;; basic block 1, loop depth 0, count 0 ;; prev block 7, next block 9 ;; pred: 7 [100.0%] 6 [100.0%] ;; succ: bb 1: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-18 18:42 --- (In reply to comment #3) #8 0x0253271e in create_single_exit_edge (region=0x47afff8) at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:965 965 forwarder = make_forwarder_block (exit, sd_region_without_exit, NULL); (gdb) p debug_bb(exit) ;; basic block 1, loop depth 0, count 0 ;; prev block 7, next block 9 ;; pred: 7 [100.0%] 6 [100.0%] ;; succ: bb 1: Well BB 1 is not supposed to have any succ anyways as it is the exit block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #43 from dominiq at lps dot ens dot fr 2010-02-18 18:44 --- The compilation of gcc/regrename.c fails with ... cc1: warnings being treated as errors ../../gcc-4.5-work/gcc/regrename.c: In function 'build_def_use': ../../gcc-4.5-work/gcc/regrename.c:1113:6: error: array subscript has type 'char' The line is has_dup[recog_data.dup_num[i]] = true; trying has_dup[(int) recog_data.dup_num[i]] = true; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-18 18:46 --- Hmm, this code is undefined first but that does not matter. The issue comes down to return statements not being combined into just one return statement. I don't know if this is supposed to happen this way or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- Comment #23 from bkoz at redhat dot com 2010-02-18 19:09 --- Subject: Re: man page errors for generated libstdc++ man pages 2010-02-17 09:36 --- So... shall we close this as fixed? Remaining item is doxygen function markup is not working for man pages. But this is an upstream (doxygen) doxygen, and this closed. I do not see any other thing to do from a libstdc++ POV. Original reporter calls? -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #44 from dominiq at lps dot ens dot fr 2010-02-18 19:10 --- The patch in comment #43 with the fix in comment #44 works for the limited tests I am able to do right now. I can do a full test with a fresh bootstrap of gcc and fortran, but it will take a full day, so I'ld prefer to do it during the week-end. Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug target/43070] [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-18 19:20 --- Subject: Bug 43070 Author: jason Date: Thu Feb 18 19:20:21 2010 New Revision: 156872 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156872 Log: PR c++/43070 * semantics.c (finish_goto_stmt): Don't call decay_conversion. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/label1.C trunk/gcc/testsuite/g++.dg/ext/label2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #20 from manu at gcc dot gnu dot org 2010-02-18 19:44 --- (In reply to comment #15) Subject: Re: warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers manu at gcc dot gnu dot org wrote: Why is this a note and not simply a warning? Because, as noted earlier, it's not reflective of any likely problem in the user's code. I think a warning is appropriate if the compiler detects something which might indicate a bug in the application, but this is just the compiler telling you about that something might go wrong if you linked with code form a different version of G++. Which is unlikely, and might go wrong for other reasons too. So it is the compiler telling you that something might go wrong and you can silence it with -Wno-psabi, which is a warning option. Moreover, as it stands now, if someone has -Werror=psabi, the compilation will not stop and they might get bitten by this. Moreover2, -w will not silence the note. I still completely fail to see why it is a note and not a warning. In any case, using diagnostic_report_warnings_p (location) should fix it. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC|manu at gcc dot gnu dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug c/41843] segfault using '-O -fipa-struct-reorg -fwhole-program'
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-18 19:46 --- Olga, is this fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
[Bug tree-optimization/41843] segfault using '-O -fipa-struct-reorg -fwhole-program'
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #21 from mark at codesourcery dot com 2010-02-18 19:47 --- Subject: Re: warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers manu at gcc dot gnu dot org wrote: In any case, using diagnostic_report_warnings_p (location) should fix it. AFAICT, this is not the case; at the point of mangling, input_location does not necessarily reflect the location at which the function was declared. Julian Brown and I are looking into this. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
