[Bug java/20495] [4.0/4.1/4.2/4.3 Regression] building gcj hangs on gcj-dbtool
--- Comment #6 from aph at gcc dot gnu dot org 2007-02-27 09:34 --- I think we're going to have to change this to a WONTFIX for the 4.1 branch. If we can get a 4.3 backtrace that will be interesting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20495
[Bug tree-optimization/30978] New: Does not propagate comparison results
int foo(int a)
{
unsigned int b = a 0;
char c = b;
return c;
}
is not optimized to
int foo(int a)
{
return a 0;
}
at the tree level. Forwprop has code to do this if the final propagation
result is in a COND_EXPR.
I have a patch.
--
Summary: Does not propagate comparison results
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: rguenth at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30978
[Bug fortran/30979] New: internal compiler error -ff2c
gcc version 4.1.0 (SUSE Linux) Trivial file fails to compile with -ff2c: gcc orient.f -ff2c -c -O -Wall -o orient.o orient.f: In function 'angnrm': orient.f:1: internal compiler error: in emit_move_insn, at expr.c:3158 Please submit a full bug report, with preprocessed source if appropriate. Omitting the -ff2c compiles the file. A different machine compiles this fine: gcc version 4.0.2 20050901 (prerelease) (SUSE Linux) - although the output code differs depending on the -ff2c option. -- Summary: internal compiler error -ff2c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tim dot bevan at 1spatial dot com GCC host triplet: i586-suse-linux GCC target triplet: i586-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30979
[Bug fortran/30979] internal compiler error -ff2c
--- Comment #1 from tim dot bevan at 1spatial dot com 2007-02-27 12:21 --- Created an attachment (id=13119) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13119action=view) trimmed down source file Just the ont function that provokes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30979
[Bug c++/30980] New: [4.3 Regression] Recent complex miscompilation
Recently (~10 days ago), 26_numerics/complex/13450.cc started failing for
*many* targets, among which powerpc-darwin. On the latter I'm seeing a
miscompilation at -O1 and above of this reduced C++ snippet:
#include math.h
#include stdio.h
int main()
{
__complex__ double x;
__real__ x = -1.0;
__imag__ x = 0.0;
__complex__ double t = __builtin_clog(x);
double tmp = 0.5 * (__imag__ t);
printf(%g %g\n, cos(tmp), sin(tmp));
}
/
Note how the output changes at -O1 and above. Also note that the very same
snippet, as C is fine, thus I'm categorizing as C++, not as middle-end or
something else.
--
Summary: [4.3 Regression] Recent complex miscompilation
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
GCC target triplet: powerpc-apple-darwin8.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug fortran/30979] internal compiler error -ff2c
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-02-27 13:11 --- Works, in terms of compiles, with gfortran-4.3 (svn version, 20070220). Did you try the latest 4.1.2 release? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Summary|internal compiler error - |internal compiler error - |ff2c|ff2c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30979
[Bug c++/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #1 from pcarlini at suse dot de 2007-02-27 13:20 --- Looking at testresults, it seems 26_numerics/complex/13450.cc started failing on powerpc-apple-darwin8.5.0 between 122031 and 122067. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug fortran/30981] New: Program Hangs
If a has a value of +Infinity, then a program will hang (run forever) when b = x**a is executed. The traceback shows that this occurs in the library routine pow_r4_i4 uname -a Linux devlop 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux gfortran -v === Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /e_source/gcc-4.1.1/configure --prefix=/add/linux64/gcc4.1.1 Thread model: posix gcc version 4.1.1 -- Summary: Program Hangs Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-27 13:27 --- As I cannot reproduce this on any linux target I guess the following change did it: +2007-02-16 Geoffrey Keating [EMAIL PROTECTED] + + * config/darwin.h (LINK_SPEC): Always pass -macosx_version_min + to linker. + (DARWIN_EXTRA_SPECS): Add %(darwin_minversion). + * config/rs6000/darwin.h (SUBTARGET_OVERRIDE_OPTIONS): Just call + darwin_rs6000_override_options. + (C_COMMON_OVERRIDE_OPTIONS): Expect + darwin_macosx_version_min to be non-NULL always. + (TARGET_C99_FUNCTIONS): Likewise. + (CC1_SPEC): Always pass -mmacosx-version-min to cc1*. + (DARWIN_MINVERSION_SPEC): New. + * config/rs6000/rs6000.c (darwin_rs6000_override_options): New. + * config/i386/darwin.h (CC1_SPEC): Always pass -mmacosx-version-min + to cc1*. + (DARWIN_MINVERSION_SPEC): New. + * config/darwin.opt (mmacosx-version-min): Initialize to non-NULL + value. + * config/darwin-c.c (darwin_cpp_builtins): Expect + darwin_macosx_version_min to be non-NULL always. + + * config/rs6000/rs6000.c: Clean up trailing whitespace. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||geoffk at gcc dot gnu dot ||org Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #3 from pcarlini at suse dot de 2007-02-27 13:30 --- Yes, I can confirm it cannot be reproduced on linux targets. Anyway, we can easily nail down between 122051 and 122067 (from testresults). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #4 from pcarlini at suse dot de 2007-02-27 13:39 --- Note, however, that per Kaveh' reports, around the same dates (between 2007-02-14 and 2007-02-19) it started failing also on sparc-sun-solaris2.10... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #5 from pcarlini at suse dot de 2007-02-27 13:41 --- I'm adding Eric too, maybe he wants to investigate the sparc version of the issue. -- pcarlini at suse dot de changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug fortran/30979] internal compiler error -ff2c
--- Comment #3 from tim dot bevan at 1spatial dot com 2007-02-27 13:51 --- Unfortunately it is not possible to test that here at the moment. This is not critical as I can avoid needing this code. Not sure if we do actually need to specify the -ff2c flag anyway, I have a report that we needed it to compile other code with the earlier compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30979
[Bug c++/29993] typdef declaration of cv-qualified function in class
--- Comment #4 from patchapp at dberlin dot org 2007-02-27 14:20 --- Subject: Bug number PR c++/29993 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01828.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29993
[Bug fortran/30979] internal compiler error -ff2c
--- Comment #4 from tim dot bevan at 1spatial dot com 2007-02-27 15:03 --- Having got gcc 4.1.3 (which supplied 4.1.2 prerelease) and some newer version of the GMP library installed. gcc --version gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux) The problem still occurs gcc orient.f -ff2c -c -O -Wall -o orient.o orient.f: In function 'angnrm': orient.f:1: internal compiler error: in emit_move_insn, at expr.c:3162 Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30979
[Bug c++/30982] New: Junk in diagnostic message
Maybe this is a known issue, but I just noticed that many meaningless words are
output for this wrong snippet:
class base
{
public:
typedef int vvv;
};
templatetypename T
class derived : public base
{ };
templatetypename T
void
f(const derivedT)
{
typedef typename derivedT::base base;
/* typename */ base::vvv uuu;
}
int main()
{
derivedfloat dd;
f(dd);
}
paolo:~/Work g++ reduced.cc
reduced.cc: In function 'void f(const derivedT)':
reduced.cc:16: error: expected `;' before 'uuu'
reduced.cc: In function 'void f(const derivedT) [with T = float]':
reduced.cc:22: instantiated from here
reduced.cc:16: error: dependent-name 'derived::#'typename_type' not supported
by pp_cxx_unqualified_id#::vvv' is parsed as a non-type, but instantiation
yields a type
reduced.cc:16: note: say 'typename derived::#'typename_type' not supported by
pp_cxx_unqualified_id#::vvv' if a type is meant
--
Summary: Junk in diagnostic message
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30982
[Bug c++/30982] Junk in diagnostic message
--- Comment #1 from gdr at cs dot tamu dot edu 2007-02-27 15:17 --- Subject: Re: New: Junk in diagnostic message pcarlini at suse dot de [EMAIL PROTECTED] writes: | Maybe this is a known issue, but I just noticed that many meaningless words are | output for this wrong snippet: this is weird. I'll look into it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30982
[Bug fortran/30979] internal compiler error -ff2c
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-27 15:28 --- *** This bug has been marked as a duplicate of 25392 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30979
[Bug fortran/25392] ICEs with -ff2c
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-02-27 15:28 --- *** Bug 30979 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tim dot bevan at 1spatial ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
[Bug fortran/30929] -pedantic-error produced only warnings and no errors
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-27 15:33 --- The same is true for -Werror. Warnings still give an exit status code of zero. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
[Bug fortran/30968] Bogus warning with continued lines of concatenated strings
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-26 17:11:29 |2007-02-27 15:36:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30968
[Bug middle-end/30969] [4.3 Regression] The polyhedron test 'fatigue.f90' is no longer working.
--- Comment #6 from dominiq at lps dot ens dot fr 2007-02-27 15:36 --- I don't know if this reduced test account for all the problem, but it exhibits at least one bug: module perdida_m implicit none contains subroutine perdida (dt, strain_tensor) real (kind = 8), intent(in) :: dt real (kind = 8), dimension(:,:), intent(in) :: strain_tensor end subroutine perdida end module perdida_m program iztaccihuatl use perdida_m implicit none real (kind = 8) :: dt, time, coefficient real (kind = 8), dimension(3,3,10) :: strain_tensor dt = 5.556D-006 strain_tensor = 0.0_8 time = dt coefficient = sin(time) print *, coefficient coefficient = cos(time) call perdida (dt, strain_tensor(:,:,1)) end program iztaccihuatl gives 1.947453947074031E-314 If I comment the line 'call perdida (dt, strain_tensor(:,:,1))', I get 5.5526978E-006 As far as I can tell, all the ingredients in this test case are necessary to trigger the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
[Bug middle-end/30969] [4.3 Regression] The polyhedron test 'fatigue.f90' is no longer working.
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-27 15:41 --- Related to PR30980. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30980 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-27 15:42 --- PR 30969 is related. The reduced fortran looks like the reduced C++. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-27 15:47 --- I'm adding Eric too, maybe he wants to investigate the sparc version of the issue. The patch which I was worried about causing a regression with respect of calling complex functions is: 2007-02-18 Sandra Loosemore [EMAIL PROTECTED] * calls.c (initialize_argument_information): Pass original EXP and STRUCT_VALUE_ADDR_VALUE instead of a list of arguments. Move code to split complex arguments here, as part of initializing the ARGS array. (expand_call): Remove code that builds a list of arguments and inserts implicit arguments into it. Instead, just count how many implicit arguments there will be so we can determine the size of the ARGS array, and let initialize_argument_information do the work. (split_complex_values): Delete unused function. Now I don't know if that patch caused the sparc regression or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug fortran/25392] ICEs with -ff2c
--- Comment #13 from tobi at gcc dot gnu dot org 2007-02-27 16:10 --- Should I backport this to 4.1? I guess it makes sense since this can be considered a regressions WRT g77. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
[Bug tree-optimization/30978] Does not propagate comparison results
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-27 16:15 --- Patch posted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||02/msg02123.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30978
[Bug fortran/25392] ICEs with -ff2c
--- Comment #14 from jakub at gcc dot gnu dot org 2007-02-27 16:21 --- Created an attachment (id=13120) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13120action=view) gcc41-pr25392.patch Yes, I think so. Attached is what we have in Red Hat gcc 4.1.x tree for a few days already (and have been bootstrapped/regtested several times). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
[Bug c++/30536] [4.1 regression] ICE with __thread and register
--- Comment #4 from jakub at gcc dot gnu dot org 2007-02-27 16:26 --- Fixed on 4.1 branch as well. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30536
[Bug middle-end/30473] [4.1 Regression] Internal Compiler Error with a sprintf with few arguments for format %s
--- Comment #8 from jakub at gcc dot gnu dot org 2007-02-27 16:27 --- Fixed on 4.1 branch as well. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30473
[Bug fortran/30981] Program Hangs
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-27 17:07 --- Could you post an example? pow_r4_i4 means that you have x**a = real(4)**integer(4) I don't see how the exponent a can be infinity if it is an integer(4). And the following program executes in 4 ms with gfortran 4.3.0 20070227 and 4.1.3 20070218 (prerelease) (SUSE Linux). You might want to try an newer GCC (4.1.2 or 4.2 or 4.3). Nightly builds of the latter two are available from: http://gcc.gnu.org/wiki/GFortranBinaries#GNU/Linux -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #8 from geoffk at gcc dot gnu dot org 2007-02-27 17:25 --- I'm confident that my patch could not possibly have affected targets other than Darwin, and should not have significantly affected code generation even there. Complex arithmetic testcases will fail for other reasons on Darwin (like PR 24577). -- geoffk at gcc dot gnu dot org changed: What|Removed |Added CC|geoffk at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug fortran/30973] undetected name conflict: variables may be named like modules
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-27 17:44 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02134.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-26 16:47:56 |2007-02-27 17:44:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30973
[Bug fortran/30973] undetected name conflict: variables may be named like modules
--- Comment #5 from patchapp at dberlin dot org 2007-02-27 17:46 --- Subject: Bug number PR30973 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02134.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30973
[Bug fortran/30865] [4.1, 4.2 only] optional argument passed on to size(...,dim=)
--- Comment #11 from burnus at gcc dot gnu dot org 2007-02-27 17:46 --- The following additional patch needs to be applied when backporting: http://gcc.gnu.org/ml/fortran/2007-02/msg00620.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30865
[Bug libstdc++/28080] header dependencies
--- Comment #17 from paolo at gcc dot gnu dot org 2007-02-27 17:48 --- Subject: Bug 28080 Author: paolo Date: Tue Feb 27 17:48:09 2007 New Revision: 122380 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122380 Log: 2007-02-27 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28080 (partial) * include/std/bitset: Do not include ios, iosfwd is enough. (operator(std::basic_istream, bitset)): Tweak, refer to ios_base as a base of basic_istream. * include/std/iomanip: Do not include ios, iosfwd + bits/ios_base.h is enough. * include/std/iosfwd: Do not include cctype here... * include/bits/locale_facets.h: ... do it here, when needed. * include/bits/ostream.tcc: Clean up, do not include locale here... * include/std/ostream: ... here instead. * include/bits/istream.tcc: Likewise for locale and ostream... * include/std/istream: ... here. * include/bits/sstream.tcc: Do not include sstream. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/istream.tcc trunk/libstdc++-v3/include/bits/locale_facets.h trunk/libstdc++-v3/include/bits/ostream.tcc trunk/libstdc++-v3/include/bits/sstream.tcc trunk/libstdc++-v3/include/std/bitset trunk/libstdc++-v3/include/std/iomanip trunk/libstdc++-v3/include/std/iosfwd trunk/libstdc++-v3/include/std/istream trunk/libstdc++-v3/include/std/ostream -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug fortran/30981] Program Hangs
--- Comment #2 from ray at ultramarine dot com 2007-02-27 18:00 --- Subject: Re: Program Hangs On Tue, 27 Feb 2007, burnus at gcc dot gnu dot org wrote: --- Comment #1 from burnus at gcc dot gnu dot org 2007-02-27 17:07 --- Could you post an example? pow_r4_i4 means that you have x**a = real(4)**integer(4) I don't see how the exponent a can be infinity if it is an integer(4). subroutine num_normalize(sigfig,number, n_normal,exponent) c c@@@ c@@@ c@@@ c c --- num_normalize --- c c Copyright Ultramarine,inc. c August 1997 c c.D c.D NAME=num_normalize c.D Routine to crack NUMBER to characters in ARRAY c.D OUTPUT c.D ARRAY = Character array of NUMBER c.D NPLACE = Integer*4 Number of Characters used c.Dif NPLACE 0 then could not convert c.D c c@@@ c@@@ c@@@ c c c c* no implicit c implicit none c c* externals c c c* global variables c include '$(where)/amos/include/essential.ecm' c c* local variables c TYPE_INTEGER exponent,sigfig,pow TYPE_REAL number,temp,n_normal,eps parameter (eps = 1e-6) c c* initialize c temp = abs(number) if( temp .lt. r_tiny_n) then exponent = 0. n_normal = 0. else exponent = log10(temp) c hangs after here. temp = temp / (10.**exponent) pow = max(sigfig,(exponent+1)) n_normal = temp + 5./10.**pow endif c c* fix? c if ( n_normal .ge. 10.-eps .and. n_normal .le. 10+eps ) then exponent = 0 n_normal = 10 - eps elseif( n_normal .ge. 10. ) then exponent = exponent + 1 temp = temp * .1 pow = max(sigfig,(exponent+1)) n_normal = temp + 5./10.**pow elseif( n_normal.lt. 1.) then exponent = exponent - 1 temp = temp * 10. pow = max(sigfig,(exponent+1)) n_normal = temp + 5./10.**pow endif c c* all done c return c end And the following program executes in 4 ms with gfortran 4.3.0 20070227 and 4.1.3 20070218 (prerelease) (SUSE Linux). You might want to try an newer GCC (4.1.2 or 4.2 or 4.3). Nightly builds of the latter two are available from: http://gcc.gnu.org/wiki/GFortranBinaries#GNU/Linux Thanks, I know about the newer versions, but what I have here is basically working. I just reported this because I hate hangs even when I have a bug and generate infinity and then try to convert it to a string. Thanks again, Ray PS. Notice the eps in the last segment of code. This is really a bug also. It originally was If ( n_normal .eq. 10. ) then But in some cases it missed the proper branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
r122342 ICE tree check at tree-cfg.c:2042
$ avr-gcc -mmcu=atmega64 -g -O2 -Wall -Wextra -Werror -Os -I.. -I. -MMD -DBOOTLOADER -DF_CPU=1600 -c -o fs.o ../fs.c ../fs.c: In function 'fs_exec': ../fs.c:35: internal compiler error: tree check: expected class 'expression', have 'constant' (integer_cst) in find_taken_edge, at tree-cfg.c:2042 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ avr-gcc --version |head -1 avr-gcc (GCC) 4.3.0 20070226 (experimental) Thanks, Shaun fs.i Description: Binary data
[Bug middle-end/30984] New: ICE with computed goto and constants
int fs_exec(int ino)
{
void *src = 0;
if (ino)
src = (void*)0xe000;
goto *src;
}
Reduced from http://gcc.gnu.org/ml/gcc-bugs/2007-02/msg02973.html.
--
Summary: ICE with computed goto and constants
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
Re: r122342 ICE tree check at tree-cfg.c:2042
On 2/27/07, Shaun Jackman [EMAIL PROTECTED] wrote: $ avr-gcc -mmcu=atmega64 -g -O2 -Wall -Wextra -Werror -Os -I.. -I. I submitted http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984 for this bug. It is a generic issue. Thanks, Andrew Pinski
[Bug fortran/25392] ICEs with -ff2c
--- Comment #15 from tobi at gcc dot gnu dot org 2007-02-27 19:20 --- Subject: Bug 25392 Author: tobi Date: Tue Feb 27 19:20:21 2007 New Revision: 122382 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122382 Log: 2006-12-29 Tobias Schlueter [EMAIL PROTECTED] PR fortran/25392 * trans-types.c (gfc_sym_type): Don't return early for functions. Remove special handling for -ff2c. (gfc_get_function_type): Add special handling for -ff2c. * trans-decl.c (gfc_create_function_decl): Fix comment formatting. (gfc_get_fake_result_decl): Make sure we get the right type for functions. (gfc_generate_function_code): Convert type of result variable to type of function. * gfortran.dg/f2c_8.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/f2c_8.f90 - copied unchanged from r120099, trunk/gcc/testsuite/gfortran.dg/f2c_8.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/fortran/trans-types.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
[Bug fortran/25392] ICEs with -ff2c
--- Comment #16 from tobi at gcc dot gnu dot org 2007-02-27 19:21 --- The patch has moved into its new home on the 4.1 branch. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
[Bug fortran/30981] a ** exp fails for integer exponents if exp is -huge()-1 (endless loop)
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-27 19:35 ---
Hi,
Could you post an example?
With example I mean something which actually compiles and runs. Here, I have
two problems:
include '$(where)/amos/include/essential.ecm'
is missing as well as the main program which calls the routine. And as always:
The smaller the better.
In addition, please attach such long files, they clutter the bug report page
quite a bit if they are put into the comment field.
if ( n_normal .ge. 10.-eps .and. n_normal .le. 10+eps ) then
PS. Notice the eps in the last segment of code. This is
really a bug also. It originally was
If ( n_normal .eq. 10. ) then
But in some cases it missed the proper branch.
If you do:
n_normal = 10.0
then if(n_normal == 10.0) should work. If you do
n_normal = 500.0/100.0*2.0
then it might not work due to rounding errors and representation problems of a
decimal number as binary number. Therefore, one should almost always use
something like if ( abs(n_normal - 10.0) eps), where eps is sensibly
chosen, it could be e.g. eps = epsilon(n_normal), but this might be even too
small. For irrational numbers such as 3.14159 it is more obvious that one
should use, e.g. (abs(myNumber - 3.14159) 1e-4) instead of if (myNumber ==
3.14159).
Back to the problem:
The calculation goes only into an endless loop if the exponent is
-huge(integer)-1.
Test case:
program test
implicit none
print *, 5.0**(-huge(i)-1)
end program
The problem is that in pow_r4_i4 the following operation is done:
if (n 0)
{
n = -n;
The problem is: For n == -huge(n) - 1 exists no positive number. Thus
n == -n == -2147483648 (for integer(4))
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2007-02-27 19:35:04
date||
Summary|Program Hangs |a ** exp fails for integer
||exponents if exp is -
||huge()-1 (endless loop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #38 from xyzzy at speakeasy dot org 2007-02-27 19:36 --- (In reply to comment #37) now if there is a unwritten rule that m operands and variations of them cannot be copied anywhere, then it would be very desireable to have a asm constraint like m without this restriction this would resolve this and several other bugs also it would be very nice if such a dont copy restriction on m if it does exist could be documented Copying m operands onto the stack might not be such a great thing to wish for. Imagine if you used asm(movaps %xmm0, %0: =m(x[i])); If x[i] is only 32-bits, and gcc copied it onto the stack, then writing 16 bytes with movaps wouldn't also write to x[i+1] to x[i+3] as intended. I know there is a plenty of asm code in ffmpeg that overwrites or overreads memory operands and will fail if gcc tried to move them onto the stack. There is also alignment. movaps requires an aligned address, and maybe you have chosen x and i in such a way that it will be aligned. But when gcc copies the value onto the stack, how is it supposed to know what alignment it needs? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug fortran/30981] a ** exp fails for integer exponents if exp is -huge()-1 (endless loop)
--- Comment #4 from ray at ultramarine dot com 2007-02-27 19:52 ---
Subject: Re: a ** exp fails for integer exponents if exp
is -huge()-1 (endless loop)
On Tue, 27 Feb 2007, burnus at gcc dot gnu dot org wrote:
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-27 19:35
---
Hi,
Could you post an example?
With example I mean something which actually compiles and runs. Here, I have
two problems:
include '$(where)/amos/include/essential.ecm'
is missing as well as the main program which calls the routine. And as always:
The smaller the better.
I really try to do this, but I am an old fortran programer and
I do not know how to set +Infinity. Yes, of course, I have a case
that computes it and then hangs, but my code is over 500,000 lines
long and I did not think it is appropriate.
In addition, please attach such long files, they clutter the bug report page
quite a bit if they are put into the comment field.
if ( n_normal .ge. 10.-eps .and. n_normal .le. 10+eps ) then
PS. Notice the eps in the last segment of code. This is
really a bug also. It originally was
If ( n_normal .eq. 10. ) then
But in some cases it missed the proper branch.
If you do:
n_normal = 10.0
then if(n_normal == 10.0) should work. If you do
n_normal = 500.0/100.0*2.0
then it might not work due to rounding errors and representation problems of a
decimal number as binary number. Therefore, one should almost always use
something like if ( abs(n_normal - 10.0) eps), where eps is sensibly
chosen, it could be e.g. eps = epsilon(n_normal), but this might be even too
small. For irrational numbers such as 3.14159 it is more obvious that one
should use, e.g. (abs(myNumber - 3.14159) 1e-4) instead of if (myNumber ==
3.14159).
This is not as silly as it sounds. All I care about is to handle
the special case of 10 (exactly). I have seen cases where the
equality fails, but the number is really 10. It probably has
something to do with how this is done. I never could get a
small case to fail.
Back to the problem:
The calculation goes only into an endless loop if the exponent is
-huge(integer)-1.
Test case:
program test
implicit none
print *, 5.0**(-huge(i)-1)
end program
The problem is that in pow_r4_i4 the following operation is done:
if (n 0)
{
n = -n;
The problem is: For n == -huge(n) - 1 exists no positive number. Thus
n == -n == -2147483648 (for integer(4))
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2007-02-27 19:35:04
date||
Summary|Program Hangs |a ** exp fails for integer
||exponents if exp is -
||huge()-1 (endless loop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
---+ Spam Scoring Results +
Content analysis details: (-2.6 hits, 5.0 required)
-2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
[score: 0.0033]
---+ End Spam Scoring Results +---
Ultramarine, Inc.
http://www.ultramarine.com
Phone: 713-975-8146
Fax: 713-975-8179
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug fortran/30981] a ** exp fails for integer exponents if exp is -huge()-1 (endless loop)
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-27 19:54 --- Also isn't -huge()-1 undefined code for Fortran? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug fortran/30981] a ** exp fails for integer exponents if exp is -huge()-1 (endless loop)
--- Comment #6 from ray at ultramarine dot com 2007-02-27 19:57 --- Subject: Re: a ** exp fails for integer exponents if exp is -huge()-1 (endless loop) On Tue, 27 Feb 2007, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-27 19:54 --- Also isn't -huge()-1 undefined code for Fortran? -- I am not familiar with the new standards, but it was in the past. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug rtl-optimization/30931] [4.1 regression] infinite loop with -O1 -fstrength-reduce
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-02-27 20:21 --- Subject: Bug 30931 Author: ebotcazou Date: Tue Feb 27 20:21:17 2007 New Revision: 122383 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122383 Log: PR rtl-optimization/30931 * loop.c (combine_givs_p): Return false if either GIV is not always executed. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20070227-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/loop.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug rtl-optimization/30931] [4.1 regression] infinite loop with -O1 -fstrength-reduce
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2007-02-27 20:23 --- Fixed on 4.1 branch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||02/msg02159.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
[Bug fortran/30985] New: Misleading error message for -huge(integer)-1
If one inputs a variable which is (-huge(i)-1), gfortran outputs: i = -2147483648 1 Error: Integer too big for its kind at (1) This can be very irritating as the number is representable hardware wise, even if it is not a Fortran number (symmetrically around the zero). I had a program, which didn't work (PR30981) and thus I used print *, i which showed: -2147483648. It is then very counterintuitive that one cannot enter the number directly. Maybe a more explicit error message should be given for (-huge(i)-1). In addition, maybe one could point to -fno-range-check? I know we don't point to compiler options in error messages so far, but for this case it might make sense. (Analogously for data x/too-big-BOZ, overflowing on purpose/.) [For some errors, I'd also like to see a pointer to -std=legacy as I often don't realize that it is allowed there.] -- Summary: Misleading error message for -huge(integer)-1 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30985
[Bug fortran/30981] a ** exp fails for integer exponents if exp is -huge()-1 (endless loop)
--- Comment #7 from kargl at gcc dot gnu dot org 2007-02-27 20:46 --- (In reply to comment #5) Also isn't -huge()-1 undefined code for Fortran? -huge()-1 can be defined in Fortran. The problem comes when one tries to use that value in, e.g., IABS() because the standard prohibits calling an intrinsic that must return a value outside of its defined range. I'll also note that -pedantic will reject -huge()-1 as being outside the symmetric range of the model numbers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug fortran/30985] Misleading error message for -huge(integer)-1
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-27 20:49 --- This is a bogus PR. The are no negative numbers. This is a unary minus operation and 2147483648 is too big for INTEGER(4). The only method to get the most negative value is -HUGE() - 1. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30985
[Bug target/30970] Register zeroing by xor N,N should be moved out of loop
--- Comment #4 from uros at gcc dot gnu dot org 2007-02-27 21:27 --- Subject: Bug 30970 Author: uros Date: Tue Feb 27 21:27:27 2007 New Revision: 122387 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122387 Log: PR target/30970 * config/i386/sse.md (*movmode_internal, *movv4sf_internal, *movv2df_internal): Enable pattern only for valid operand combinations. * config/i386/i386.c (ix86_modes_tieable_p): For SSE registers, tie only 128bit modes. For MMX registers, tie only 64bit modes. testsuite/ChangeLog: PR target/30970 * gcc.target/i386/gfortran.dg/pr30970.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr30970.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30970
[Bug debug/30986] New: [4.0/4.1/4.2/4.3 regression] ICE in splice_child_die
The test gcc.c-torture/execute/mayalias-2.c is causing an ICE when compiled with -g. The failure can be reproduced as far back as gcc 4.0, but gcc-3.3 works. $ ./xgcc -B./ -g -c ../../gcc/testsuite/gcc.c-torture/execute/mayalias-2.c ../../gcc/testsuite/gcc.c-torture/execute/mayalias-2.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5589 -- Summary: [4.0/4.1/4.2/4.3 regression] ICE in splice_child_die Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: ia64-*-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30986
[Bug debug/30986] [4.0/4.1/4.2/4.3 regression] ICE in splice_child_die
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-27 21:48 --- I don't know how many times I have to mark this as a dup. *** This bug has been marked as a duplicate of 28834 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30986
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-02-27 21:48 --- *** Bug 30986 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug fortran/30985] Misleading error message for -huge(integer)-1
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-27 21:50 --- *** This bug has been marked as a duplicate of 29580 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30985
[Bug fortran/29580] integer -2147483648 out of range: bug or feature?
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-27 21:50 --- *** Bug 30985 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
Re: r122342 ICE tree check at tree-cfg.c:2042
On 2/27/07, Andrew Pinski [EMAIL PROTECTED] wrote: On 2/27/07, Shaun Jackman [EMAIL PROTECTED] wrote: $ avr-gcc -mmcu=atmega64 -g -O2 -Wall -Wextra -Werror -Os -I.. -I. I submitted http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984 for this bug. It is a generic issue. Thanks, Andrew! I'd like to know the revision where this bug was created, if someone happens to discover it. Cheers, Shaun
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs
--- Comment #24 from schwab at suse dot de 2007-02-27 21:54 --- ICE's with every optimization level. -- schwab at suse dot de changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2/4.3 Regression] |-O3 -g crashes sometimes|-g crashes sometimes when |when using may_alias and|using may_alias and structs |structs | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug fortran/30981] a ** exp fails for integer exponents if exp is -huge()-1 (endless loop)
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-27 22:04 --- Also isn't -huge()-1 undefined code for Fortran? -huge()-1 can be defined in Fortran. [...] I'll also note that -pedantic will reject -huge()-1 Just for completeness: In the original example (the very long, incomplete F77 code) the problem was due to an overflow of: integer :: exponent ! temp very large or +INF exponent = log10(temp) Thus as long as such -huge()-1 and (for floating point numbers) INF, NAN and denormal numbers exists, the intrinsics have to deal with it somehow. (In reply to comment #4) With example I mean something which actually compiles and runs. Here, I have two problems: include '$(where)/amos/include/essential.ecm' is missing as well as the main program which calls the routine. I really try to do this, but I am an old fortran programer and I do not know how to set +Infinity. Yes, of course, I have a case that computes it and then hangs, but my code is over 500,000 lines long and I did not think it is appropriate. Well, given that you have 500,000+ lines, it was already quite short and I was able to reproduce the problem even without the essential.ecm file. (Actually, reproducing was easier than I initially feared.) In any case: Thanks for reporting this bug. [Comparison with 10.0] This is not as silly as it sounds. All I care about is to handle the special case of 10 (exactly). I have seen cases where the equality fails, but the number is really 10. I'm sure that the two numbers are then not exactly the same (bitwise) though; nonetheless I'm not good at predicting when an operation will cause an off-by-one (bit) and when not. I also failed to cook up a small example for 10.0 To create infinity etc. one can simply do: real :: zero, r zero = 0.0 r = 1.0/zero ! = +INF r = zero/zero ! = NaN r = -1.0/zero ! = -INF -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug target/30987] New: Problem while compiling gcc for score
Hello, there seems to be a gcc problem with the target 'score': /home/mstein/sim/score-elf/build/./gcc/xgcc -B/home/mstein/sim/score-elf/build/./gcc/ -nostdinc -B/home/mstein/sim/score-elf/build/score-elf/newlib/ -isystem /home/mstein/sim/score-elf/build/score-elf/newlib/targ-include -isystem /n/07/mstein/combined-trunk/newlib/libc/include -B/n/07/mstein/cross-local/score-elf-new/score-elf/bin/ -B/n/07/mstein/cross-local/score-elf-new/score-elf/lib/ -isystem /n/07/mstein/cross-local/score-elf-new/score-elf/include -isystem /n/07/mstein/cross-local/score-elf-new/score-elf/sys-include -L/home/mstein/sim/score-elf/build/./ld -O2 -g -O2 -mmac -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -G 0 -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/n/07/mstein/combined-trunk/libgcc -I/n/07/mstein/combined-trunk/libgcc/. -I/n/07/mstein/combined-trunk/libgcc/../gcc -I/n/07/mstein/combined-trunk/libgcc/../include -I/n/07/mstein/combined-trunk/libgcc/../libdecnumber -I../../../libdecnumber -o _floatdisf.o -MT _floatdisf.o -MD -MP -MF _floatdisf.dep -DL_floatdisf -c /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c \ In file included from ../../.././gcc/tm.h:8, from /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c:35: /n/07/mstein/combined-trunk/libgcc/../gcc/config/score/score.h:776:1: warning: ASM_OUTPUT_EXTERNAL redefined In file included from ../../.././gcc/tm.h:6, from /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c:35: /n/07/mstein/combined-trunk/libgcc/../gcc/config/elfos.h:514:1: warning: this is the location of the previous definition /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c: In function '__floatdisf': /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c:1526: internal compiler error: in decompose_multiword_subregs, at lower-subreg.c:1140 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [_floatdisf.o] Error 1 -- Summary: Problem while compiling gcc for score Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: score-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30987
[Bug c++/30988] New: Incorrect no return statement warning with __attribute__ ((noreturn)) and __FUNCTION__
The following code incorrectly warns that the function g is missing a return
statement. The warning goes away if __FUNCTION__ is replaced by
(const char*)__FUNCTION__.
BEGIN CODE ==
void f(const char*) __attribute__ ((noreturn));
templateclass T
class A
{
int g()
{
f(__FUNCTION__);
//f((const char*)__FUNCTION__);
}
};
template class Aint;
END code
wedge:scratch% g++ -O3 -Wall -c -v noreturn.cpp
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1plus -quiet -v -D_GNU_SOURCE
noreturn.cpp -quiet -dumpbase noreturn.cpp -mtune=generic -auxbase noreturn -O3
-Wall -version -o /tmp/ccVj3EZ3.s
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../x86_64-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../include/c++/4.1.1
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../include/c++/4.1.1/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../include/c++/4.1.1/backward
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/include
/usr/include
End of search list.
GNU C++ version 4.1.1 20060525 (Red Hat 4.1.1-1) (x86_64-redhat-linux)
compiled by GNU C version 4.1.1 20060525 (Red Hat 4.1.1-1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 56236c31509b2b0d4a3c4ac0327da7d9
noreturn.cpp: In member function int AT::g():
noreturn.cpp:10: warning: no return statement in function returning non-void
as -V -Qy -o noreturn.o /tmp/ccVj3EZ3.s
GNU assembler version 2.16.91.0.6 (x86_64-redhat-linux) using BFD version
2.16.91.0.6 20060212
--
Summary: Incorrect no return statement warning with
__attribute__ ((noreturn)) and __FUNCTION__
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irving at cs dot stanford dot edu
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988
[Bug rtl-optimization/30987] [4.3 Regression] Problem while compiling gcc for score
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-27 22:24 --- Can you do two things for me, first supply what is the date on 4.3.0 you are trying to compile? Second, can you attach the preprocessed source found by recompiling the source which is failing with -save-temps? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, ian at gcc dot gnu dot ||org Component|target |rtl-optimization Summary|Problem while compiling gcc |[4.3 Regression] Problem |for score |while compiling gcc for ||score Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30987
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #39 from michaelni at gmx dot at 2007-02-27 22:50 --- (In reply to comment #38) (In reply to comment #37) now if there is a unwritten rule that m operands and variations of them cannot be copied anywhere, then it would be very desireable to have a asm constraint like m without this restriction this would resolve this and several other bugs also it would be very nice if such a dont copy restriction on m if it does exist could be documented Copying m operands onto the stack might not be such a great thing to wish for. Imagine if you used asm(movaps %xmm0, %0: =m(x[i])); If x[i] is only 32-bits, and gcc copied it onto the stack, then writing 16 bytes with movaps wouldn't also write to x[i+1] to x[i+3] as intended. I know there is a plenty of asm code in ffmpeg that overwrites or overreads memory operands and will fail if gcc tried to move them onto the stack. There is also alignment. movaps requires an aligned address, and maybe you have chosen x and i in such a way that it will be aligned. But when gcc copies the value onto the stack, how is it supposed to know what alignment it needs? well the data type used in m() must of course be correct, that is here a 128bit type, alignment can be handled like with all other types, double also gets aligned if the architecture needs it, so a uint128_t or sse128 or whatever can as well, the example you show is a fairly obscure special case in respect to moving m to the stack, in the end theres a need for a m like constraint which must not be moveable and a m like constraint which should be moveable (to the stack for example) the exact letters used are irrelevant -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug fortran/30929] -pedantic-error produced only warnings and no errors
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-27 23:33 --- The same is true for -Werror. I have to correct myself: -Werror gives a non-zero exit status, but still writes Warning:. I think gfortran should follow gcc by changing also the label from Warning: to Error: for -Werror. -pedantic-errors seems to be difficult as it is hard to divide -Wall warnings from -pedantic warnings. The easiest way is probably to imply -Wall by -pedantic_errors (defined in flags.h as flag_pedantic_errors). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|-pedantic-error produced |-pedantic-error produced |only warnings and no errors |only warnings and no errors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
[Bug c/30992] New: Scaling error in decimal floating-point arithmetic blows conversions to integers
The function DFP_TO_INT() in gcc/config/dfp-bit.c has the job of converting decimal floating point values to integers. It does this by calling the decNumberFromString() function from the IBM decnumber library, but with an incorrect argument. Fortunately, the patch is just one character: % diff -c gcc-4.3-20070209/gcc/config/dfp-bit.c /local/build/gcc/gcc-4.3-20070209/gcc/config *** gcc-4.3-20070209/gcc/config/dfp-bit.c Mon Jan 29 16:01:35 2007 --- /local/build/gcc/gcc-4.3-20070209/gcc/config/dfp-bit.c Thu Feb 15 12:41:12 2007 *** *** 450,456 /* Rescale if the exponent is less than zero. */ decNumberToIntegralValue (n2, n1, context); /* Get a value to use for the quantize call. */ ! decNumberFromString (qval, (char *) 1.0, context); /* Force the exponent to zero. */ decNumberQuantize (n1, n2, qval, context); /* Get a string, which at this point will not include an exponent. */ --- 450,456 /* Rescale if the exponent is less than zero. */ decNumberToIntegralValue (n2, n1, context); /* Get a value to use for the quantize call. */ ! decNumberFromString (qval, (char *) 1., context); /* Force the exponent to zero. */ decNumberQuantize (n1, n2, qval, context); /* Get a string, which at this point will not include an exponent. */ Without this patch, the range of numbers that can be correctly converted to integers is sharply reduced: most conversions of large values are wrong. For example, the value x = 1048576.0DF is exactly representable as a _Decimal32 value and as a 32-bit int, but the bad code converts it to an int value of 2147483647, and a long int value of 9223372036854775807. With the patch, integer conversions are now correct for all floating-point values for which exact integer counterparts exist. The bug exists in all versions of dfp-bit.c in gcc-4.2 and gcc-4.3 distributions. As an aside, I now have a complete C99 library for decimal arithmetic working under gcc-4.2 and gcc-4.3 on AMD64, thanks to the prototype support for decimal arithmetic in gcc. I look forward to the decimal support working on other platforms. -- Summary: Scaling error in decimal floating-point arithmetic blows conversions to integers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: beebe at math dot utah dot edu GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30992
[Bug c++/30993] New: Incorrect no return statement warning with __attribute__ ((noreturn)) and __FUNCTION__
The following code incorrectly warns that the function g is missing a return
statement. The warning goes away if __FUNCTION__ is replaced by
(const char*)__FUNCTION__.
BEGIN CODE ==
void f(const char*) __attribute__ ((noreturn));
templateclass T
class A
{
int g()
{
f(__FUNCTION__);
//f((const char*)__FUNCTION__);
}
};
template class Aint;
END code
wedge:scratch% g++ -O3 -Wall -c -v noreturn.cpp
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
/usr/libexec/gcc/x86_64-redhat-linux/4.1.1/cc1plus -quiet -v -D_GNU_SOURCE
noreturn.cpp -quiet -dumpbase noreturn.cpp -mtune=generic -auxbase noreturn -O3
-Wall -version -o /tmp/ccVj3EZ3.s
ignoring nonexistent directory
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../x86_64-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../include/c++/4.1.1
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../include/c++/4.1.1/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../include/c++/4.1.1/backward
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/include
/usr/include
End of search list.
GNU C++ version 4.1.1 20060525 (Red Hat 4.1.1-1) (x86_64-redhat-linux)
compiled by GNU C version 4.1.1 20060525 (Red Hat 4.1.1-1).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 56236c31509b2b0d4a3c4ac0327da7d9
noreturn.cpp: In member function int AT::g():
noreturn.cpp:10: warning: no return statement in function returning non-void
as -V -Qy -o noreturn.o /tmp/ccVj3EZ3.s
GNU assembler version 2.16.91.0.6 (x86_64-redhat-linux) using BFD version
2.16.91.0.6 20060212
--
Summary: Incorrect no return statement warning with
__attribute__ ((noreturn)) and __FUNCTION__
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irving at cs dot stanford dot edu
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30993
[Bug c++/30993] Incorrect no return statement warning with __attribute__ ((noreturn)) and __FUNCTION__
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-28 00:26 --- *** This bug has been marked as a duplicate of 30988 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30993
[Bug c++/30988] Incorrect no return statement warning with __attribute__ ((noreturn)) and __FUNCTION__
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-28 00:26 --- *** Bug 30993 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #21 from manu at gcc dot gnu dot org 2007-02-28 00:31 --- (In reply to comment #20) Created an attachment (id=13003) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13003action=view) [edit] preliminary patch This patch only works for fortran and C front-ends. ObjC and C++ need to have their respective objc.exp and g++.exp patched. I would prefer to have a global setting that is overridden by fortran and whoever else needs a special treatment. Also, the regexp produced by this patch looks like warning:[^\n]* $expmsg. I think that 'concat' introduces the spurious space character. Thus, -set expmsg [concat $msgprefix\[^\n]* $expmsg] +set expmsg $msgprefix\[^\n]*$expmsg (This is mostly a note to myself.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug rtl-optimization/30987] [4.3 Regression] Problem while compiling gcc for score
--- Comment #2 from ian at airs dot com 2007-02-28 02:24 --- The problem is that the bitset_c insn comes before the iorsi3 insn in the MD files. It matches the ior:SI insn with one added clobber. Unfortunately, the added clobber is of a hard reg, and so this is rejected by insn_invalid_p in recog.c. I don't understand how bitset_c will ever be used in practice. Nothing generates it explicitly. Typical ior:SI insns get passed to recog_memoized which does not add clobbers. I can fix the problem easily enough by moving (include misc.md) and (include mac.md) to the end of score.md. I'm not sure how to really test that fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30987
[Bug target/30987] [4.3 Regression] Problem while compiling gcc for score
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-28 04:42 --- And I think the pattern is incorrect anyways, lets look at it: (define_insn bitset_c [(set (match_operand:SI 0 register_operand =e,d) (ior:SI (match_operand:SI 1 register_operand 0,d) (match_operand:SI 2 const_pow2))) (clobber (reg:CC CC_REGNUM))] No constraints on the operand 2, that is bad news for after reload. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30987
[Bug c++/30895] [4.1/4.2/4.3 regression] ICE with complex values in template parameter
--- Comment #2 from patchapp at dberlin dot org 2007-02-28 06:55 --- Subject: Bug number PR c++/30895 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02193.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30895
