[Bug c++/40333] g++ does not align static variables properly
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-08-24 06:15 --- (In reply to comment #2) (In reply to comment #0) The following SSE2 code crashes because the non-static global variable breaks the alignment of the static data section. Is this fixed if you use 4.5.0? This is fixed with 4.5.0 and a recent binutils (Nick Clifton's patch to GAS was commuitted on 2008-09-03) Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40333
[Bug target/40786] Windows %I32 format confusion
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-08-24 06:20 --- Patch fixed for 4.5 at revision 151047. I would like to backport this patch to 4.4 and possibly to 4.3 branch, too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40786
[Bug c/41151] New: Gas fails to consume the assembly Error: offset too big
When compiling the test program arm-none-linux-gnueabi-gcc -march=armv7-a -O2 -c -o ltest.o ltest.i Assembler fails to assemble it and emits the error Error: offset too big If I do not use -march=armv7-a it works ok and also if I dont use O2 it compiles fine. -- Summary: Gas fails to consume the assembly Error: offset too big Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41151
[Bug c/41151] Gas fails to consume the assembly Error: offset too big
--- Comment #1 from raj dot khem at gmail dot com 2009-08-24 06:24 --- Created an attachment (id=18417) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18417action=view) preprocessed testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41151
[Bug c/41151] Gas fails to consume the assembly Error: offset too big
--- Comment #2 from ramana at gcc dot gnu dot org 2009-08-24 08:44 --- Using binutils trunk as well as r150986 I can't reproduce this with -O2 and -march=armv7-a. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|Gas fails to consume the|Gas fails to consume the |assembly Error: offset too |assembly Error: offset too |big |big http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41151
[Bug fortran/41152] New: Spurious diagnostic Extraneous characters in format
gfortran now warns for trailing characters in format statements. However, it does not properly work as the following test case (extracted from FLEUR, www.flapw.de) shows: 7182 FORMAT (a3) 1 Warning: Extraneous characters in format at (1) Due to committal: URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151021 Log: 2009-08-22 Bud Davis bdavis9...@sbcglobal.net PR fortran/28093 * io.c : added variable to store original len of fmt * io.c (check_format): Consume H items using next_char in both modes to handle consecutive single quotes. Test for extra characters in fmt, issue warning. Test case: SUBROUTINE rw_inp() CHARACTER(len=100) :: line READ(*,FMT=(4x,a)) line 7182 FORMAT (a3) 7130 FORMAT (i3) END SUBROUTINE rw_inp -- Summary: Spurious diagnostic Extraneous characters in format Product: gcc Version: 4.5.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=41152
[Bug fortran/28039] Warn when ignoring extra characters in the format specification
--- Comment #5 from burnus at gcc dot gnu dot org 2009-08-24 08:53 --- Thanks for the fix, however, it causes some bogus diagnostic - see PR 41152 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug fortran/41152] Spurious diagnostic Extraneous characters in format
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-24 09:02 --- Also the following fixed-format format looks OK to me: WRITE (6,'(//'' icorr is not correctly transferred. icorr='',i5) ') 42 END But it produces: WRITE (6,'(//'' icorr is not correctly transferred. icorr='',i5) 1 Warning: Extraneous characters in format at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41152
[Bug c/41150] segmentation fault after using __attribute__((optimize()))
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-24 09:08 --- Please provide preprocessed source that can be used to reproduce the failure. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|segmentation fault after|segmentation fault after |using |using |__attribute__((optimize())) |__attribute__((optimize())) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41150
[Bug middle-end/41149] -fdump-tree-original and procedure pointer components
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-24 09:21 ---
Seems like by design, see tree-pretty-print.c:print_call_name
Likely for printing prettier member function names. IMHO we should just
drop this function on the floor considering it prints t.w (...) for
struct
{
struct
{
funcPtr *ppc;
} w;
} t;
t.w.ppc = func;
l = t.w.ppc(Hello);
I'll happily approve a patch that passes bootstrap and testing that
reduces the function to strip an address-taking operation (note the
CALL_EXPR operand is an address of the function, so a (...) should
print as a (...) and p (...) should print as (*p) (...)).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-08-24 09:21:23
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41149
[Bug c++/41144] ice for legal code with -O2 in get_alias_set
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-24 09:26 --- Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41144
[Bug c++/41094] Erroneous optimization of pow() with -ffast-math
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-24 09:52 --- Subject: Bug 41094 Author: rguenth Date: Mon Aug 24 09:52:03 2009 New Revision: 151051 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151051 Log: 2009-08-24 Richard Guenther rguent...@suse.de PR middle-end/41094 * builtins.c (fold_builtin_pow): Fold pow(pow(x,y),z) to pow(x,y*z) only if x is nonnegative. * gcc.dg/torture/pr41094.c: New testcase. * gcc.dg/torture/builtin-power-1.c: Adjust. * gcc.dg/builtins-10.c: Likewise. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr41094.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/builtins.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/builtins-10.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/builtin-power-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41094
[Bug c++/41094] Erroneous optimization of pow() with -ffast-math
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-24 09:56 --- Subject: Bug 41094 Author: rguenth Date: Mon Aug 24 09:56:30 2009 New Revision: 151052 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151052 Log: 2009-08-24 Richard Guenther rguent...@suse.de PR middle-end/41094 * builtins.c (fold_builtin_pow): Fold pow(pow(x,y),z) to pow(x,y*z) only if x is nonnegative. * gcc.dg/torture/pr41094.c: New testcase. * gcc.dg/torture/builtin-power-1.c: Adjust. * gcc.dg/builtins-10.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr41094.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/builtins.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/builtins-10.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/builtin-power-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41094
[Bug c++/41094] Erroneous optimization of pow() with -ffast-math
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-24 10:03 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.3.4 4.4.1 Known to work||4.3.5 4.4.2 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41094
[Bug c++/41144] [4.5 Regression] ice for legal code with -O2 in get_alias_set
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-24 10:29 ---
Confirmed. Mine.
struct rgba8;
templateclass ColorT class span_gouraud {
public:
struct coord_type { };
coord_type m_coord[3];
};
templateclass ColorT class span_gouraud_rgba : public span_gouraudColorT
{
typedef ColorT color_type;
typedef span_gouraudcolor_type base_type;
typedef typename base_type::coord_type coord_type;
public:
void prepare() {
coord_type coord[3];
}
};
void the_application() {
typedef span_gouraud_rgbargba8 gouraud_span_gen_type;
gouraud_span_gen_type span_gouraud;
span_gouraud.prepare();
}
ICEs at -fstrict-aliasing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2009-08-24 10:29:36
date||
Summary|ice for legal code with -O2 |[4.5 Regression] ice for
|in get_alias_set|legal code with -O2 in
||get_alias_set
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41144
[Bug fortran/41152] Spurious diagnostic Extraneous characters in format
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-24 11:19 --- Another test case: character(100), parameter :: subchapter='(79(-),/,5(-), ,A,/,79(-),/)' write(*,subchapter) 'test' end Here the error message is: write(*,subchapter) 'test' 1 Warning: Extraneous characters in format at (1) Note that the error shows the line with the write statement, not the line containing the format string. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-24 11:19:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41152
[Bug fortran/41152] Spurious diagnostic Extraneous characters in format
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-24 11:24 --- (In reply to comment #0) Due to committal: URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151021 For me r151028 seems to work, but r151039 shows the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41152
[Bug c++/41153] New: ICE in building Qt4 src/core
tools/qdatetime.cpp: In member function 'QString QDateTimeParser::sectionText(const QString, int, int) const': tools/qdatetime.cpp:4424: warning: case label value is less than minimum value for type tools/qdatetime.cpp:4425: warning: case label value is less than minimum value for type tools/qdatetime.cpp:4426: warning: case label value is less than minimum value for type tools/qdatetime.cpp: In member function 'QString QDateTimeParser::sectionText(int) const': tools/qdatetime.cpp:4438: warning: case label value is less than minimum value for type tools/qdatetime.cpp:4439: warning: case label value is less than minimum value for type tools/qdatetime.cpp:4440: warning: case label value is less than minimum value for type In file included from ../../include/QtCore/qstring.h:1, from ../../include/QtCore/../../src/corelib/kernel/qobject.h:48, from ../../include/QtCore/qobject.h:1, from ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:45, from ../../include/QtCore/qcoreapplication.h:1, from global/qt_pch.h:58: ../../include/QtCore/../../src/corelib/tools/qstring.h: In member function 'const QChar QString::at(int) const': ../../include/QtCore/../../src/corelib/tools/qstring.h:684: internal compiler error: in tree_nrv, at tree-nrv.c:143 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [tmp/obj/release_static/qdatetime.o] Error 1 -- Summary: ICE in building Qt4 src/core Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: t7 at gmail dot com GCC host triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41153
[Bug fortran/41053] internal compiler error: in emit_swap_insn, at reg-stack.c:827
--- Comment #6 from dominiq at lps dot ens dot fr 2009-08-24 11:48 --- I just downloaded CPMD and built it under gfortran 4.4.1 and 4.5.0 (revision 151047) without trouble. Could you post the output of gfortran -v and indicate your platform. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053
[Bug fortran/41154] New: [4.5 Regression] Comma required after P descriptor
With r151053 I get an error when I compile the following line: 2000 format (1X,1P,E14.6,3E12.4,0P) 1 Error: Comma required after P descriptor in format string at (1) While I haven't checked in the standard if this is really valid, it was swallowed by gfortran until recently. It is also accepted by ifort and g95. This was certainly introduced by Jerry's r151045. -- Summary: [4.5 Regression] Comma required after P descriptor Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41154
[Bug fortran/41053] internal compiler error: in emit_swap_insn, at reg-stack.c:827
--- Comment #7 from ubizjak at gmail dot com 2009-08-24 12:40 --- Probably duplicate of PR 40587. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053
[Bug c++/41144] [4.5 Regression] ice for legal code with -O2 in get_alias_set
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-24 12:53 --- We're layouting an array with incomplete element type and get into if (!TYPE_SIZE (element)) /* We don't know the size of the underlying element type, so our alignment calculations will be wrong, forcing us to fall back on structural equality. */ SET_TYPE_STRUCTURAL_EQUALITY (type); later re-using this type when building the same array type with complete element type as the canonical variant. IMHO the above is simply bogus. To test patch: Index: stor-layout.c === --- stor-layout.c (revision 151050) +++ stor-layout.c (working copy) @@ -2020,11 +2020,6 @@ layout_type (tree type) #else TYPE_ALIGN (type) = MAX (TYPE_ALIGN (element), BITS_PER_UNIT); #endif - if (!TYPE_SIZE (element)) - /* We don't know the size of the underlying element type, so -our alignment calculations will be wrong, forcing us to -fall back on structural equality. */ - SET_TYPE_STRUCTURAL_EQUALITY (type); TYPE_USER_ALIGN (type) = TYPE_USER_ALIGN (element); SET_TYPE_MODE (type, BLKmode); if (TYPE_SIZE (type) != 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41144
[Bug fortran/41053] internal compiler error: in emit_swap_insn, at reg-stack.c:827
--- Comment #8 from dominiq at lps dot ens dot fr 2009-08-24 13:03 --- Probably duplicate of PR 40587. Could be, but the test in PR 40587 fails with 4.5 r147438: pr40587.f90: In function 'test': pr40587.f90:14: internal compiler error: in emit_swap_insn, at reg-stack.c:827 but not the test in comment #3 which compiles with the same version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053
[Bug tree-optimization/40585] [4.5 Regression] tracer duplicates blocks w/o adjusting EH tree
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-08-24 13:12 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40585
[Bug fortran/41154] [4.5 Regression] Comma required after P descriptor
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-24 13:45 --- With r151053 I get an error when I compile the following line: 2000 format (1X,1P,E14.6,3E12.4,0P) 1 Error: Comma required after P descriptor in format string at (1) That looks like a bug: There is surely no comma required at the end of the format/before a ')'. Seemingly, we missed that special case. The check is correct for fmt strings such as '(1P2E12.4)'. However, I cannot reproduce the problem with a program consisting only of: 2000 format (1X,1P,E14.6,3E12.4,0P) end In PR 41152, it was also depending on other lines. Can you re-check? This was certainly introduced by Jerry's r151045. See also PR 35754. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41154
[Bug fortran/41154] [4.5 Regression] Comma required after P descriptor
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-24 13:55 --- However, I cannot reproduce the problem with a program consisting only of: 2000 format (1X,1P,E14.6,3E12.4,0P) end Hm, funny. For me the error *does* appear already for this two-liner (at r151053). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41154
[Bug middle-end/30789] complex folding inexact
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-08-24 14:43 --- Joseph - back in comment#2, you noted that the results of infinity and zero can be ambiguous. I.e. Infinity in either part of a complex number (perhaps infinity of either sign?) is sufficient, and a pair of zeros, explicitly of either sign is also sufficient for zero. This brings up the question that it's possible for GCC to produce a compile-time result (via MPC) that is different from the runtime result (via libgcc2) where both are C99 compliant standard conforming values. Which one the user receives would depend on the context (e.g. static init) or on whether optimizations allowed GCC to fold it at compile-time. Now this happens all the time for finite values, MPFR and MPC are more exact that glibc's math library and often produce different results which are clearly better. However having GCC be more accurate than glibc (where the C library is outside out control) is different IMHO than getting two entirely different results from two parts of GCC, i.e. compile-time folding vs libgcc2. E.g. (Inf NaN) vs (0 -Inf) are both infinities per C99 Annex G. While MPC has committed to producing C99 conforming results for the special cases covered in Annex G, it is entirely possible they may come to different conclusions as to what is best where the standard leaves things ambiguous. Should I continue to pursue having GCC fold the Annex G special cases via MPC if it leads to this kind of discrepancy? Or should be seek to fold these internally, essentially dulpicating the libgcc2 algorithm using real.c functions so that both produce the same result? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug c/41155] New: Compiler internal error with -O3
gcc -v says Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4) command line gcc -O3 -fomit-frame-pointer -ffast-math -DHAVE_CONFIG_H -c Divonne.i output ./src/divonne/Explore.c: In function Explore: ./src/divonne/Explore.c:17: internal compiler error: in root_var_init, at tree-ssa-live.c:1034 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reprting instructions, see URL:file:///usr/share/doc/gcc-4.2/README.Bugs. Divonne.i is too long to be included here, please contact me for the file as you don't seem to allow uploads of files. -- Summary: Compiler internal error with -O3 Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: David dot Kosower at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41155
[Bug c/41155] Compiler internal error with -O3
--- Comment #1 from David dot Kosower at cea dot fr 2009-08-24 15:25 --- Created an attachment (id=18418) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18418action=view) File referred to in comment -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41155
[Bug lto/41079] Bootstrap comparison fails, collect2 links against lto archives
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-24 15:33 --- Subject: Bug 41079 Author: rguenth Date: Mon Aug 24 15:33:35 2009 New Revision: 151057 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151057 Log: 2009-08-24 Richard Guenther rguent...@suse.de PR lto/41079 * lto-streamer-out.c (output_gimple_stmt): Only stream needed fields. Do not stream pointer garbage. * lto-streamer-in.c (output_gimple_stmt): Adjust accordingly. Structure like output_gimple_stmt. Do not needlessly zero fields. Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/lto-streamer-in.c branches/lto/gcc/lto-streamer-out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41079
[Bug lto/41079] Bootstrap comparison fails, collect2 links against lto archives
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-24 15:34 --- The bootstrap comparison issues have all been fixed. The lto sections appearing in the final executables have been dealt with in upstream ld following what gold does. Thus, fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED GCC target triplet|i?86-*-*| Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41079
[Bug c/41155] Compiler internal error with -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-24 15:40 --- GCC 4.2.4 is no longer maintained, please update to at least GCC 4.3.4. I suggest reporting this bug to ubuntu instead. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41155
[Bug middle-end/40867] [4.5 Regression] FAIL: StackTrace2 output - source compiled test
--- Comment #9 from hjl dot tools at gmail dot com 2009-08-24 15:48 --- Fixed: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg02467.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867
[Bug target/41156] New: [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
+++ This bug was initially created as a clone of Bug #32893 +++ Gcc 4.4/4.5 can align stack properly. But it needs to assume 4 byte incoming stack alignment instead of 16byte. -- Summary: [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu BugsThisDependsOn: 32893,40838 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug middle-end/40500] [4.5 Regression] Revision 148512 failed to build binutils
--- Comment #9 from mmitchel at gcc dot gnu dot org 2009-08-24 16:10 --- I think maybe it's time for me to get a brain transplant. I had totally forgotten the previous conversation, and read through this entire issue yesterday, and then spent some time thinking about the issue, and clearly reached a totally opposite conclusion. I guess since me and anti-me have different opinions, that just comes out to a zero. I think the opinion I expressed in the previous message holds in general, though; we shouldn't treat adding a warning to -Wall as inherently bad, even though of course every new warning will break some build that uses -Wall -Werror. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40500
[Bug target/34736] [avr] optimiser does not keep interrupt disabled blocks small
--- Comment #4 from eric dot weddington at atmel dot com 2009-08-24 17:07 --- The cli() and sei() macros from avr-libc are volatile and generate inline assembly, which the compiler knows nothing about. The compiler is not aware that the load of the constant into a register can be done, and should be done, outside of your critical block. I suggest that you write this whole code snippet in inline assembly to get the shortest possible time with interrupts disabled. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34736
[Bug target/29560] [avr] Poor optimization for byte shifts
--- Comment #3 from eric dot weddington at atmel dot com 2009-08-24 17:18 --- Confirmed on 4.3.2. -- eric dot weddington at atmel dot com changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin7.9.0 | GCC host triplet|powerpc-apple-darwin7.9.0 | Keywords||missed-optimization Known to fail||4.1.1 4.3.2 Last reconfirmed|-00-00 00:00:00 |2009-08-24 17:18:30 date|| Summary|Poor optimization for |[avr] Poor optimization for |character shifts on Atmel |byte shifts |AVR | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29560
[Bug libfortran/41157] dtime not consistent in times reported
--- Comment #1 from kargl at gcc dot gnu dot org 2009-08-24 17:19 ---
(In reply to comment #0)
The following code was compiled with
gfortran -g -o test_dtime test_dtime.f
The code is given by (very similar to that given in the info file for gfortran
program test_dtime
integer(8) :: i, j, k
real, dimension(2) :: tarray
real :: result
real :: accum
call dtime(tarray, result)
print '(''tarray,result:'', 1P, 3E20.11)', tarray, result
do i=1,1 ! Just a delay
j = i * i - i
end do
call dtime(tarray, result)
print '(''tarray,result:'', 1P, 3E20.11)', tarray, result
accum = 0.e0! Should accumulate 10 times previous tarray(1)
call dtime(tarray, result)
do k=1, 10
do i=1,1! Just a delay
j = i * i - i
end do
call dtime(tarray, result)
accum = accum + tarray(1)
end do
print '(''accum ='', 1P, E20.11 )', accum
end program test_dtime
The resulting output is
tarray,result: 9.9939883E-04 9.9939883E-04 1.9987977E-03
tarray,result: 3.86941999197E-01 0.000E+00 3.86941999197E-01
accum = 1.35349416733E+01
Note that accum should be close to 10 times the value the tarray(1) above,
that
is, close to 3.8. I have no idea where the 13.5... came from.
Why should it be close to 3.8?
dtime returns the time since the start of the process?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
[Bug libfortran/41157] dtime not consistent in times reported
--- Comment #2 from fkrogh#gcc at mathalacarte dot com 2009-08-24 17:34
---
I had thought that was the case as well. But when I started getting some
negative times by subtracting the previous value from the current one in the
first location of the array I looked at the info file and found
Subsequent invocations of `DTIME' return values accumulated since
the previous invocation.
I modified the code to compute the times between invocations. The code now
looks like
program test_dtime
integer(8) :: i, j, k
real, dimension(2) :: tarray
real :: result
real :: accum, tarray1
real :: ptimes(10)
call dtime(tarray, result)
print '(''tarray,result:'', 1P, 3E20.11)', tarray, result
do i=1,1 ! Just a delay
j = i * i - i
end do
call dtime(tarray, result)
print '(''tarray,result:'', 1P, 3E20.11)', tarray, result
accum = 0.e0! Should accumulate 10 times previous tarray(1)
call dtime(tarray, result)
tarray1 = tarray(1)
do k=1, 10
do i=1,1! Just a delay
j = i * i - i
end do
call dtime(tarray, result)
ptimes(k) = tarray(1) - tarray1
tarray1 = tarray(1)
accum = accum + tarray(1)
end do
print '(''accum ='', 1P, E20.11 )', accum
print '(''ptimes ='', 1P, (3E20.11))', ptimes
end program test_dtime
And the output is
tarray,result: 0.000E+00 9.9939883E-04 9.9939883E-04
tarray,result: 3.80941987038E-01 3.0002608E-03 3.83941978216E-01
accum = 1.34219570160E+01
ptimes = 7.64882981777E-01 -3.78940939903E-01 7.60881841183E-01
-3.77939820290E-01 7.63881921768E-01 -3.80940914154E-01
7.63882875443E-01 -3.78940820694E-01 7.61881709099E-01
-3.78939628601E-01
There is a pattern here, but why? If dtime is getting overflows in times less
than a few seconds, there is a problem as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
[Bug libfortran/41157] dtime not consistent in times reported
--- Comment #3 from dominiq at lps dot ens dot fr 2009-08-24 17:45 --- dtime returns the time since the start of the process? The manual says: Subsequent invocations of DTIME return values accumulated since the previous invocation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
[Bug c++/41158] New: segfault while using PCH
Just trying PCH with a sample GTKmm application. The PCH is generated with first g++ call but the compilers crashes at the second call. Files and versions on the archive. Sorry to use achives. How to reproduce: § tar -xjf gcc_segfault_case.tar.bz2 § make Well, i don't know how to post the file, so please mail me for it. -- Summary: segfault while using PCH Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lhommev at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41158
[Bug c++/41158] segfault while using PCH
--- Comment #1 from paolo dot carlini at oracle dot com 2009-08-24 17:54 --- Please provide all the information outlined here: http://gcc.gnu.org/bugs.html -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41158
[Bug libfortran/41157] dtime not consistent in times reported
--- Comment #4 from dominiq at lps dot ens dot fr 2009-08-24 18:16 --- If I am not mistaken, the dtime behavior change between 4.2 and 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
[Bug debug/40660] [4.5 Regression] Weird break points with 4.5, works with 4.4
--- Comment #10 from jv244 at cam dot ac dot uk 2009-08-24 19:05 --- (In reply to comment #8) (Part of PR 40823 is probably a duplicate of this issue; there is another issue stated in that PR, which is not a regression (i.e. never worked correctly), but has probably a similar cause.) I tried the switch (-fdump-tree-original-lineno, noticed in Aldy's patch) on the PR40823 testcase, but there is no reference to line 2 in the output of '-fdump-tree-original-lineno', just proper reference to lines 4 and 7, so I guess the issue is elsewhere ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
[Bug debug/40823] debug info points to unexpected line
--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-24 19:06 ---
No obvious wrong line numbers in the '-fdump-tree-original-lineno' output for
the module:
s1 (integer(kind=4)[0:D.1561] * restrict a, integer(kind=4) restrict n)
{
integer(kind=8) ubound.0;
integer(kind=8) ubound.1;
integer(kind=8) stride.2;
integer(kind=8) ubound.3;
integer(kind=8) stride.4;
integer(kind=8) ubound.5;
integer(kind=8) stride.6;
integer(kind=8) offset.7;
integer(kind=8) size.8;
integer(kind=8) D.1561;
bit_size_type D.1562;
unnamed-unsigned:64 D.1563;
ubound.0 = (integer(kind=8)) [bugs.f90 : 4] *n;
stride.2 = NON_LVALUE_EXPR ubound.0;
stride.2 = MAX_EXPR stride.2, 0;
ubound.1 = (integer(kind=8)) [bugs.f90 : 4] *n;
stride.4 = stride.2 * NON_LVALUE_EXPR ubound.1;
stride.4 = MAX_EXPR stride.4, 0;
ubound.3 = (integer(kind=8)) [bugs.f90 : 4] *n;
stride.6 = stride.4 * NON_LVALUE_EXPR ubound.3;
stride.6 = MAX_EXPR stride.6, 0;
ubound.5 = (integer(kind=8)) [bugs.f90 : 4] *n;
size.8 = stride.6 * NON_LVALUE_EXPR ubound.5;
size.8 = MAX_EXPR size.8, 0;
D.1561 = size.8 + -1;
D.1562 = (bit_size_type) size.8 * 32;
D.1563 = (unnamed-unsigned:64) size.8 * 4;
offset.7 = (~NON_LVALUE_EXPR stride.2 - NON_LVALUE_EXPR stride.4) -
NON_LVALUE_EXPR stride.6;
[bugs.f90 : 7] (*a)[(((NON_LVALUE_EXPR stride.2 + 1) + NON_LVALUE_EXPR
stride.4) + NON_LVALUE_EXPR stride.6) + offset.7] = 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40823
[Bug lto/41159] New: [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225
After merging in the assert from 150592 there is a new ICE on the lto branch. $ ./xgcc -B. -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: arm-unknown-linux-gnueabi Configured with: ../configure --target=arm-unknown-linux-gnueabi --prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi --with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root --enable-languages=c,c++ --disable-multilib --with-float=soft --with-gmp=/home/ryan/x-tools/arm-unknown-linux-gnueabi --with-mpfr=/home/ryan/x-tools/arm-unknown-linux-gnueabi --disable-sjlj-exceptions --enable-__cxa_atexit --with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace Thread model: posix gcc version 4.5.0 20090824 (experimental) [lto revision 151057] (lto merged with rev 150842) $ ./xgcc -B. -c -O -fpic ~/ice.i -flto $ ./xgcc -B. -flto ice.o -shared In file included from :0:0: /home/ryan/ice.i: In function 'acos': /home/ryan/ice.i:660:9: internal compiler error: in insert_value_copy_on_edge, at tree-outof-ssa.c:225 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: ././xgcc returned 1 exit status collect2: lto-wrapper returned 1 exit status -- Summary: [LTO] ICE in insert_value_copy_on_edge, at tree-outof- ssa.c:225 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmansfield at qnx dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
[Bug fortran/40632] Support F2008's contiguous attribute
--- Comment #1 from tkoenig at gcc dot gnu dot org 2009-08-24 19:33 --- It would also be useful when assigning arrays with a single value: subroutine foo(a) integer, a(:,:) :: a a = 0 ! See PR 41137, we could use memset or subroutine foo(a) integer, a(:,:) :: a A = 42 -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||41137 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40632
[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225
--- Comment #1 from rmansfield at qnx dot com 2009-08-24 19:34 --- Created an attachment (id=18419) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18419action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
[Bug libfortran/41157] dtime not consistent in times reported
--- Comment #5 from kargl at gcc dot gnu dot org 2009-08-24 19:40 --- Confirmed. I have a patch. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-24 19:40:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
[Bug libfortran/41157] dtime not consistent in times reported
-- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-08-24 19:40:51 |2009-08-24 19:41:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
[Bug middle-end/41149] -fdump-tree-original and procedure pointer components
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-24 19:44 --- (In reply to comment #1) Seems like by design, see tree-pretty-print.c:print_call_name Thanks for pointing me at the right place. Likely for printing prettier member function names. IMHO we should just drop this function on the floor I wouldn't go as far as dropping the whole function, but at least the part concerning COMPONENT_REF seems pretty braindead to me. I'd propose to just drop this and replace it by something more sane, like here: Index: gcc/tree-pretty-print.c === --- gcc/tree-pretty-print.c (revision 151053) +++ gcc/tree-pretty-print.c (working copy) @@ -2705,19 +2705,6 @@ print_call_name (pretty_printer *buffer, dump_generic_node (buffer, TREE_OPERAND (op0, 2), 0, flags, false); break; -case COMPONENT_REF: - /* The function is a pointer contained in a structure. */ - if (TREE_CODE (TREE_OPERAND (op0, 0)) == INDIRECT_REF || - TREE_CODE (TREE_OPERAND (op0, 0)) == VAR_DECL) - dump_function_name (buffer, TREE_OPERAND (op0, 1), flags); - else - dump_generic_node (buffer, TREE_OPERAND (op0, 0), 0, flags, false); - /* else -We can have several levels of structures and a function -pointer inside. This is not implemented yet... */ - /* NIY;*/ - break; - case ARRAY_REF: if (TREE_CODE (TREE_OPERAND (op0, 0)) == VAR_DECL) dump_function_name (buffer, TREE_OPERAND (op0, 0), flags); @@ -2725,6 +2712,7 @@ print_call_name (pretty_printer *buffer, dump_generic_node (buffer, op0, 0, flags, false); break; +case COMPONENT_REF: case SSA_NAME: case OBJ_TYPE_REF: dump_generic_node (buffer, op0, 0, flags, false); This seems to do the right thing (also for multiply nested function pointers as in comment #1). Regtesting now ... -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-08-24 09:21:23 |2009-08-24 19:44:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41149
[Bug c++/41110] [4.5 regression] Wrong unused variable warning
--- Comment #3 from jason at gcc dot gnu dot org 2009-08-24 21:32 --- Subject: Bug 41110 Author: jason Date: Mon Aug 24 21:31:54 2009 New Revision: 151061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151061 Log: PR c++/41109 PR c++/41110 PR c++/41134 * cp-tree.h (DECL_ODR_USED): New macro. (struct lang_decl_base): Add odr_used flag. * decl.c (duplicate_decls): Propagate it. Use it for error. * pt.c (register_specialization): Use it for error. * decl2.c (mark_used): Use it as gating flag rather than TREE_USED. (cp_write_global_declarations): Use it for error. (tree_used_ok): Remove. * cp-tree.h: Remove tree_used_ok. * call.c (build_call_a): Don't call it. * init.c (build_offset_ref): Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/init.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41110
[Bug c++/41134] [4.5 regression] Variable flagged unused if only used in template function
--- Comment #8 from jason at gcc dot gnu dot org 2009-08-24 21:32 --- Subject: Bug 41134 Author: jason Date: Mon Aug 24 21:31:54 2009 New Revision: 151061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151061 Log: PR c++/41109 PR c++/41110 PR c++/41134 * cp-tree.h (DECL_ODR_USED): New macro. (struct lang_decl_base): Add odr_used flag. * decl.c (duplicate_decls): Propagate it. Use it for error. * pt.c (register_specialization): Use it for error. * decl2.c (mark_used): Use it as gating flag rather than TREE_USED. (cp_write_global_declarations): Use it for error. (tree_used_ok): Remove. * cp-tree.h: Remove tree_used_ok. * call.c (build_call_a): Don't call it. * init.c (build_offset_ref): Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/init.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41134
[Bug c++/41109] [4.5 regression] Argument flagged as unused despite use in sizeof()
--- Comment #4 from jason at gcc dot gnu dot org 2009-08-24 21:32 --- Subject: Bug 41109 Author: jason Date: Mon Aug 24 21:31:54 2009 New Revision: 151061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151061 Log: PR c++/41109 PR c++/41110 PR c++/41134 * cp-tree.h (DECL_ODR_USED): New macro. (struct lang_decl_base): Add odr_used flag. * decl.c (duplicate_decls): Propagate it. Use it for error. * pt.c (register_specialization): Use it for error. * decl2.c (mark_used): Use it as gating flag rather than TREE_USED. (cp_write_global_declarations): Use it for error. (tree_used_ok): Remove. * cp-tree.h: Remove tree_used_ok. * call.c (build_call_a): Don't call it. * init.c (build_offset_ref): Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/init.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41109
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #2 from dodji at gcc dot gnu dot org 2009-08-24 21:40 --- Created an attachment (id=18420) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18420action=view) WIP with test This version fixes a bug in gcc that was preventing it to emit DWARFs for a typedefs enclosed in a namespace, if said namespace contain only typedefs. As a matter of fact, the exemple accompanying the patch shows what's supported now. Find attached below the generated assembly fo the exemple in the patch. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #18404|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #3 from dodji at gcc dot gnu dot org 2009-08-24 21:42 --- Created an attachment (id=18421) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18421action=view) Generated assembly for previous test Assembly generated for the test in attachment #18420 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug fortran/37826] gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero
--- Comment #5 from steven at gcc dot gnu dot org 2009-08-24 22:35 --- IMHO we should just not put a locus on the generated code to zero out the variable at the start of the (sub-)program. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-24 22:35:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37826
[Bug target/36223] IV-opt is not optimal for mips
--- Comment #6 from sandra at codesourcery dot com 2009-08-24 22:36 --- This bug appears to be fixed in mainline HEAD now. Here's an excerpt showing the generated code for the inner loop in the example program now: addiu $21,$28,%gp_rel(AA) addiu $10,$28,%gp_rel(A) addiu $20,$28,%gp_rel(BB) addiu $9,$28,%gp_rel(B) li $19,2044# 0x7fc li $18,10 # 0xa move$2,$0 .L3: addu$8,$10,$2 addu$3,$9,$2 lw $24,0($8) addu$14,$21,$2 lw $8,0($3) addu$3,$20,$2 addiu $2,$2,4 sw $24,0($14) bne $2,$19,.L3 sw $8,0($3) All 4 gp_rel address computations pulled outside the loop, and only 5 adds inside. I'm not sure what fixed this, but it does seem fixed. -- sandra at codesourcery dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223
[Bug fortran/41154] [4.5 Regression] Comma required after P descriptor
--- Comment #3 from jvdelisle at verizon dot net 2009-08-24 23:45 --- Subject: Re: New: [4.5 Regression] Comma required after P descriptor On 08/24/2009 05:26 AM, janus at gcc dot gnu dot org wrote: With r151053 I get an error when I compile the following line: 2000 format (1X,1P,E14.6,3E12.4,0P) 1 Error: Comma required after P descriptor in format string at (1) While I haven't checked in the standard if this is really valid, it was swallowed by gfortran until recently. It is also accepted by ifort and g95. This was certainly introduced by Jerry's r151045. Thats my fault, will fix shortly. Jerry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41154
[Bug debug/40660] [4.5 Regression] Weird break points with 4.5, works with 4.4
--- Comment #11 from aldyh at gcc dot gnu dot org 2009-08-25 00:28 --- Subject: Bug 40660 Author: aldyh Date: Tue Aug 25 00:27:52 2009 New Revision: 151069 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151069 Log: fortran/ PR fortran/40660 * trans-io.c (build_dt): Pass UNKNOWN_LOCATION to build_call_expr_loc. (transfer_array_desc): Same. Added: trunk/gcc/testsuite/gfortran.dg/PR40660.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
[Bug fortran/41160] No more than one complex function in a file
--- Comment #1 from kargl at gcc dot gnu dot org 2009-08-25 00:36 --- There isn't a problem with having more than 2 complex function in a file. The problem is that your complex functions are using a nonstandard extension. REMOVE:kargl[242] cat k.f90 COMPLEX FUNCTION F0_HDEC*16(M1,M2,QSQ) RETURN END REMOVE:kargl[243] gfc4x -c k.f90 k.f90:1.30: COMPLEX FUNCTION F0_HDEC*16(M1,M2,QSQ) 1 Error: Expected formal argument list in function definition at (1) Notice is error is point at the *. I'm fairly certain that there was a previous bug report about this form, and it was decided that it would not be supported. I'll see if I can find the old bug report. Perhpas, tobias remembers the details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41160
[Bug target/36223] IV-opt is not optimal for mips
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-08-25 00:37 --- I tweaked IVOPTS a few months ago to help in similar cases on PowerPC: 2009-05-29 Eric Botcazou ebotca...@adacore.com * tree-ssa-loop-ivopts.c (strip_offset_1) MULT_EXPR: New case. (force_expr_to_var_cost) NEGATE_EXPR: Likewise. (ptr_difference_cost): Use affine combinations to compute it. (difference_cost): Likewise. (get_computation_cost_at): Compute more accurate cost for addresses if the ratio is a multiplier allowed in addresses. For non-addresses, consider that an additional offset or symbol is added only once. Maybe this helped for MIPS in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223
[Bug fortran/41160] No more than one complex function in a file
--- Comment #2 from kargl at gcc dot gnu dot org 2009-08-25 00:40 --- OK. I found it. This is probably a duplicate of PR 36234 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41160
[Bug fortran/41154] [4.5 Regression] Comma required after P descriptor
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:03
---
Patch is simple and obvious. I will commit shortly.
Index: io.c
===
--- io.c(revision 151045)
+++ io.c(working copy)
@@ -694,7 +694,7 @@
goto fail;
if (gfc_option.allow_std GFC_STD_F2003 t != FMT_COMMA
t != FMT_F t != FMT_E t != FMT_EN t != FMT_ES
- t != FMT_D t != FMT_G)
+ t != FMT_D t != FMT_G t != FMT_RPAREN)
{
error = _(Comma required after P descriptor);
goto syntax;
@@ -708,7 +708,7 @@
goto fail;
}
if (t != FMT_F t != FMT_E t != FMT_EN t != FMT_ES t !=
FMT_D
- t != FMT_G)
+ t != FMT_G t != FMT_RPAREN)
{
error = _(Comma required after P descriptor);
goto syntax;
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-08-25 01:03:20
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41154
[Bug fortran/41154] [4.5 Regression] Comma required after P descriptor
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:05 --- Subject: Bug 41154 Author: jvdelisle Date: Tue Aug 25 01:05:11 2009 New Revision: 151070 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151070 Log: 2009-08-24 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41154 * io.c (check_format): Fix to not error on right paren after P. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41154
[Bug fortran/41154] [4.5 Regression] Comma required after P descriptor
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:14 --- Subject: Bug 41154 Author: jvdelisle Date: Tue Aug 25 01:14:13 2009 New Revision: 151071 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151071 Log: 2009-08-24 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41154 * gfortran.dg/fmt_error_8.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_error_8.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41154
[Bug c++/41161] New: Hello World in C++ ISO does NOT compile
The following program which conforms to C++ ISO does NOT compile with G++
but compiles with no errors using Borland C++ 5.52 command line compiler.
#include iostream
int main()
{
std::cout Hello World! std::endl;
}
The following errors are produced:
ju...@linux-wp1w:~ g++ hello_iso.cpp
hello_iso.cpp:6:16: warning: missing terminating character
hello_iso.cpp:6: error: missing terminating character
hello_iso.cpp: In function int main():
hello_iso.cpp:8: error: expected primary-expression before } token
hello_iso.cpp:8: error: expected `;' before } token
ju...@linux-wp1w:~ g++ hello_iso.cpp error.log
hello_iso.cpp:6:16: warning: missing terminating character
hello_iso.cpp:6: error: missing terminating character
hello_iso.cpp: In function int main():
hello_iso.cpp:8: error: expected primary-expression before } token
hello_iso.cpp:8: error: expected `;' before } token
--
Summary: Hello World in C++ ISO does NOT compile
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: juliorz at bellsouth dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41161
[Bug fortran/41154] [4.5 Regression] Comma required after P descriptor
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:21 --- Closing. By all means let me know if anything else crops up. Thanks for catching this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41154
[Bug fortran/35754] -std=f95: Reject 1P2E12.4 w/o a comma after the P
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:22 --- Closing, fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35754
[Bug fortran/37446] Diagnostic of edit descriptors, esp. EN
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-08-25 01:24 --- Closing, fixed on trunk. Note to self. Have some locus clean-ups to do relative to 38439. Will pick those off next. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37446
[Bug libfortran/41157] dtime not consistent in times reported
--- Comment #7 from kargl at gcc dot gnu dot org 2009-08-25 01:47 --- Subject: Bug 41157 Author: kargl Date: Tue Aug 25 01:47:23 2009 New Revision: 151072 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151072 Log: 2009-08-24 Steven G. Kargl ka...@gcc.gnu.org PR fortran/41157 * dtime.c (dtime_sub): Fix computing time increment. * time_1.h: Add sys/types.h header. Use RUSAGE_SELF macro instead of a hardcoded 0. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/dtime.c trunk/libgfortran/intrinsics/time_1.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
[Bug fortran/41152] [4.5 Regression] Spurious diagnostic Extraneous characters in format
-- bdavis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bdavis at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-08-24 11:19:15 |2009-08-25 02:04:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41152
[Bug fortran/41160] No more than one complex function in a file
--- Comment #5 from kargl at gcc dot gnu dot org 2009-08-25 02:28 --- (In reply to comment #4) This turns out to be the exact bug that Diego reported in his recent email. He sent me the code off list. g77 compiles it fine. gfortran does this: Obviously legacy code issue. I wonder how many other cases we will bump in to. See the audit trail for PR 36234. I've compile millions of lines of code from numerous websites across the global. I've never hit this problem. hgaga.f:1.33: This file is part of http://lappweb.in2p3.fr/~muehlleitner/SUSY-HIT/ A quick inspection of the code suggests that one should steer clear of the package for one's own computation. -- steve -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41160
[Bug libfortran/41157] dtime not consistent in times reported
--- Comment #8 from kargl at gcc dot gnu dot org 2009-08-25 03:30 --- Subject: Bug 41157 Author: kargl Date: Tue Aug 25 03:30:25 2009 New Revision: 151073 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151073 Log: 2009-08-24 Steven G. Kargl ka...@gcc.gnu.org PR fortran/41157 * dtime.c (dtime_sub): Fix computing time increment. * time_1.h: Add sys/types.h header. Use RUSAGE_SELF macro instead of a hardcoded 0. Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/intrinsics/dtime.c branches/gcc-4_4-branch/libgfortran/intrinsics/time_1.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
[Bug libfortran/41157] dtime not consistent in times reported
--- Comment #9 from kargl at gcc dot gnu dot org 2009-08-25 03:33 --- Fixed on trunk and 4.4. Thanks for the bug report. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
[Bug c++/41161] Hello World in C++ ISO does NOT compile
--- Comment #1 from bangerth at gmail dot com 2009-08-25 04:12 --- It looks like your terminating double quote is not the same as the opening one. How are they encoded on your system? -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41161
[Bug c++/41073] Array of iostreams
--- Comment #1 from bangerth at gmail dot com 2009-08-25 04:21 --- This is the way C++ works. The copy constructor must be available. (The compiler doesn't have to actually call it, but it must be available.) -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41073
[Bug c++/41054] Cryptic error message when type is not defined.
--- Comment #1 from bangerth at gmail dot com 2009-08-25 04:23 --- Yes. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-25 04:23:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41054
[Bug c++/41038] [4.4/4.5 regression] Parsing error related to qualified name id
-- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-25 04:25:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41038
[Bug fortran/41162] [4.5 Regression] 416.gamess in SPEC CPU 2006 failed to build
--- Comment #1 from hjl dot tools at gmail dot com 2009-08-25 04:40 --- The complete error is chgpen.fppized.f:2107.56: * 1X,'INITIAL VALUE OF CHISQ =',1P,E17.10,0P/ 1 Error: Comma required after P descriptor in format string at (1) chgpen.fppized.f:2111.57: * 1X,'ENDING VALUE OF CHISQ =',1P,E17.10,0P/ 1 Error: Comma required after P descriptor in format string at (1) chgpen.fppized.f:1884.20: WRITE(IW,410) NV,NVA,NFLAT,ALPHA,BETA,GAMMA,CHISQ, 1 Error: FORMAT label 410 at (1) not defined chgpen.fppized.f:2075.22: WRITE(IW,1240) NF,CHISQ,(XVAL(J),J=1,NV) 1 Error: FORMAT label 1240 at (1) not defined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41162
[Bug fortran/41162] [4.5 Regression] 416.gamess in SPEC CPU 2006 failed to build
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-08-25 04:45 --- This is most likely a dup of bug 41154. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41162
[Bug fortran/41162] [4.5 Regression] 416.gamess in SPEC CPU 2006 failed to build
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-08-25 05:22 --- Subject: Bug 41162 Author: jvdelisle Date: Tue Aug 25 05:22:14 2009 New Revision: 151074 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151074 Log: 2009-08-24 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41162 * io.c (check_format): Fix to not error on slash after P. Fix some error loci. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41162
[Bug fortran/41162] [4.5 Regression] 416.gamess in SPEC CPU 2006 failed to build
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-08-25 05:24 --- Fixed. I will leave this open for a bit. At the rate I am going I will break everything by midnight. (zzz) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-25 05:24:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41162
