[Bug middle-end/42180] compiling induct.f90 with -ffast-math -O2 -fgraphite-identity ICEs gfortran
--- Comment #6 from spop at gcc dot gnu dot org 2009-12-18 08:29 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42180
[Bug middle-end/42180] compiling induct.f90 with -ffast-math -O2 -fgraphite-identity ICEs gfortran
--- Comment #5 from spop at gcc dot gnu dot org 2009-12-18 08:29 --- Subject: Bug 42180 Author: spop Date: Fri Dec 18 08:28:45 2009 New Revision: 155339 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155339 Log: Fix PR42180. 2009-12-18 Sebastian Pop sebastian@amd.com PR middle-end/42180 * graphite-sese-to-poly.c (follow_ssa_with_commutative_ops): Handle GIMPLE_CALL. * testsuite/gfortran.dg/graphite/pr42180.f90: Add compile flags. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite-sese-to-poly.c branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr42180.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42180
[Bug bootstrap/42424] New: in-tree GMP/MPFR/MPC bootstrap fails.
155320 configure: error: libgmp not found or uses a different ABI. make[2]: *** [configure-stage1-mpc] Error 1 make[1]: *** [stage1-bubble] Error 2 make: *** [bootstrap] Error 2 NOTE; in-tree mpc works if gmp/mpfr are installed referenced with --with-gmp/--with-mpfr. -- Summary: in-tree GMP/MPFR/MPC bootstrap fails. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: developer at sandoe-acoustics dot co dot uk GCC build triplet: *-apple-darwin9, i686-pc-linux-gnu GCC host triplet: *-apple-darwin9, i686-pc-linux-gnu GCC target triplet: *-apple-darwin9, i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
[Bug c++/31665] %s substituted with built-in/library can't be properly translated
--- Comment #1 from pzhao at gcc dot gnu dot org 2009-12-18 08:50 --- Subject: Bug 31665 Author: pzhao Date: Fri Dec 18 08:50:24 2009 New Revision: 155340 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155340 Log: cp/ 2009-12-16 Shujing Zhao pearly.z...@oracle.com PR c++/31665 * decl.c (duplicate_decls, grokdeclarator): Put the diagnostics in full sentences for easy translation and wrapped into G_(). * typeck.c (build_x_unary_op): Likewise. testsuite/ 2009-12-16 Shujing Zhao pearly.z...@oracle.com * g++.old-deja/g++.brendan/misc6.C: Make expected dg-error strings explicit. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.brendan/misc6.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31665
[Bug libfortran/42420] libgfortran fails to open large files on MINGW32
--- Comment #5 from burnus at gcc dot gnu dot org 2009-12-18 08:51 --- Confirm. The bug report looks valid and the patch sensible. Cf. for fstat/fstati64 the page: http://msdn.microsoft.com/en-us/library/aa246905%28VS.60%29.aspx Kai agrees that the patch looks OK and he checked that _fstati64 exists both for MinGW(.org) and MinGW64. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-18 08:51:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42420
[Bug c++/31665] %s substituted with built-in/library can't be properly translated
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-18 09:35 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31665
[Bug libstdc++/40088] Creating a std::ostringstream object locks a global mutex
--- Comment #11 from paolo at gcc dot gnu dot org 2009-12-18 09:41 --- Subject: Bug 40088 Author: paolo Date: Fri Dec 18 09:41:03 2009 New Revision: 155342 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155342 Log: 2009-12-18 Jimmy Guo j...@yahoo-inc.com PR libstdc++/40088 * src/locale_init.cc (locale::locale()): Optimize the common case where _S_global still points to _S_classic. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/condition_variable trunk/libstdc++-v3/src/locale_init.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable/cons/assign_neg.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable/cons/copy_neg.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/1.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/2.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/cons/assign_neg.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/cons/copy_neg.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088
[Bug libstdc++/40088] Creating a std::ostringstream object locks a global mutex
--- Comment #12 from paolo dot carlini at oracle dot com 2009-12-18 09:51 --- David, I committed a patch which should alleviate the problem, any chance you can tell us whether you are seeing an improvement? More tweaks (within the C++0x model still) are possible, but seems hard to implement without breaking the (generalized) ABI compatibility: http://gcc.gnu.org/ml/libstdc++/2009-12/msg00067.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #12 from burnus at gcc dot gnu dot org 2009-12-18 09:56 --- With the upcoming release of 4.5, I think it would be nice to fix/improve the translation related bugs now, i.e. this, PR38573 and PR40489. As I have no idea how to reproduce/check/whatever this kind of PR, could somebody be so kind to add a step-by-step description of the commands that need to be invoked to do so? No real step-by step introduction, but a) Reading gcc/ABOUT-GCC-NLS b) Modifying gcc/po/exgettext In the latter, one takes care that %e... get properly tagged; see the function keyword_option which tags them as c-format / no-c-format / gcc-internal-format. See also http://www.gnu.org/software/hello/manual/gettext/xgettext-Invocation.html and http://www.gnu.org/software/hello/manual/gettext/c_002dformat-Flag.html As blunt solution, one could simply do what as proposed in comment 5: Add the --keyword= lines to gcc/po/exgettext to the invocation of $xgettext. A more advanced solution is to do what has been suggested in comment 6; however, that does not fit the current use of messages in gfortran. What has been done there is described in gcc/ABOUT-GCC-NLS. For instance one calls in gcc: error (register name not specified for %q+D, decl); The function prototype is: void error (const char *gmsgid, ...) Here, msgid triggers the the matching in exgettext and g indicates that it is not a default C format string but a special one (cf. description in ABOUT-GCC-NLS). Seemingly we already ue msgid, but not with the proper prefix: gfc_notify_std (int std, const char *nocmsgid, ...) nocmsgid is currently translated to no-c-format but we want to have gcc-internal-format or gfc-internal-format. The current matches are (gcc/po/exgettext's function keyword_option): if (args ~ /g$/) format=gcc-internal-format else if (args ~ /noc$/) format=no-c-format else if (args ~ /c$/) format=c-format Thus gmsgid would be one solution or gfcmsgid another with adding a else if (args ~ /gfc$/) format=gfc-internal-format Thus, fixing error.c and possibly editing gcc/po/exgettext should be enough. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-18 09:56:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug libstdc++/40088] Creating a std::ostringstream object locks a global mutex
--- Comment #13 from paolo dot carlini at oracle dot com 2009-12-18 09:57 --- I meant C++03, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- Comment #11 from rainer at emrich-ebersheim dot de 2009-12-18 10:02 --- (In reply to comment #10) Should be fixed in SVN now. Rainer, please verify when you get a chance. Today I will try to build a complete tool chain with shared libstdc++ enabled. I will report back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug fortran/42422] Error in Fortran list directed input
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-18 10:07 --- Hmm, I cannot reproduce this with newer gfortran version. Using 4.2.1 I also get: 1 2 3 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 however, already with 4.3.4 [gcc-4_3-branch revision 152973] I get: 1 2 3 5 5 5 5 0 0 0 0 0 0 0 0 0 0 0 0 0 which looks OK. Can you try a newer GCC version? Current stable version is 4.4.2; previous stable version is 4.3.4 (which is slightly but sufficiently newer than your 4.3.2). And the current developer version is 4.5, which is currently in stage 4 (only regression fixes) and will be released beginning next year. [Personal educated guess: end of February.] See also http://gcc.gnu.org/wiki/GFortranBinaries for obtaining a new binary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42422
[Bug debug/42425] New: ICE declaring local class
The following valid code snippet triggers an ICE on trunk when compiled
with -flto -g:
==
struct A
{
virtual ~A();
};
void foo()
{
struct B : A {};
B b;
}
==
bug.cc: In member function 'B':
bug.cc:8:16: internal compiler error: tree check: expected class 'type', have
'declaration' (function_decl) in gen_type_die_with_usage, at dwarf2out.c:18739
Please submit a full bug report, [etc.]
--
Summary: ICE declaring local class
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, lto
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42425
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-18 11:20
---
Confirmed with r155343 on x86_64-linux. Seems a serious regression to me.
Note the snippet is missing a semicolon, fixed like this:
class A {
void f();
};
void A::f() {
A::A();
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-12-18 11:20:30
date||
Summary|Bad assembly generated for |[4.5 Regression] Bad
|constructor call|assembly generated for
||constructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-18 11:48 --- ... but indeed could well be invalid, thus a diagnostic issue only: in practice some other compilers I have at hand disagree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug lto/42426] New: ICE in get_resolution (lto)
GCC (version 4.5.0 20091217) crashes when building binutils with message: lto1: internal compiler error: in get_resolution, at lto-streamer-in.c:1524. -- Summary: ICE in get_resolution (lto) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42426
[Bug lto/42426] ICE in get_resolution (lto)
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-12-18 11:49 --- Created an attachment (id=19343) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19343action=view) Preprocessed sources Compile with `gcc src/* -flto -fuse-linker-plugin' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42426
[Bug lto/42426] ICE in get_resolution (lto)
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-12-18 11:50 --- Created an attachment (id=19344) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19344action=view) Backtrace -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42426
[Bug libffi/42423] Core dumps while executing ctypes test cases of python-2.5.1 in AIX 5.3
--- Comment #1 from swamy dot sangamesh at gmail dot com 2009-12-18 12:30 --- Created an attachment (id=19345) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19345action=view) stack-trace -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42423
[Bug middle-end/42393] [4.5 Regression] [graphite] internal compiler error: in check_loop_closed_ssa_use
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-18 12:39 --- Reopen. Still a 4.5 regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42393
[Bug debug/42186] [4.5 Regression] [graphite] internal compiler error: verify_ssa failed
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-18 12:40 --- Re-open. Still a 4.5 regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42186
[Bug tree-optimization/42205] [4.5 Regression] [graphite] internal compiler error: verify_ssa failed with -ffast-math -floop-interchange
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-12-18 12:40 --- Re-open. Still a 4.5 regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42205
[Bug tree-optimization/42221] [4.5 Regression] ICE from '-Os -fgraphite-identity'
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-18 12:41 --- Re-open. Still a 4.5 regression (please close bugs only when they are fixed where reported). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42221
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to work||4.4.2 Priority|P2 |P1 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug preprocessor/42407] Detect non-unique header file names.
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-18 12:48 --- Confirmed. It'll be interesting on how this should interact with #include_next -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-18 12:48:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42407
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-18 13:10 --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=154403 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug other/41255] [4.5 Regression] Release notes: Advice to use GDB later than 6.8
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-18 13:38 --- Note added to gcc-4.5/changes.html (Caveats section). -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41255
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
--- Comment #5 from jason at gcc dot gnu dot org 2009-12-18 14:06 --- The testcase is ill-formed. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Keywords|wrong-code |accepts-invalid Last reconfirmed|2009-12-18 11:20:30 |2009-12-18 14:06:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-18 14:14 --- EDG and GCC 4.4 accept it. Can we do so as well with -fpermissive at least? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug fortran/40165] Excessive warnings for REAL DO loops
--- Comment #4 from pault at gcc dot gnu dot org 2009-12-18 14:30 --- What shall we do with this, gents? A WONTFIX? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40165
[Bug fortran/40168] missing unrolling/scalarization/reassoc/free
--- Comment #19 from pault at gcc dot gnu dot org 2009-12-18 14:32 --- Can this now be closed or has it transmogrified itself into something else? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
[Bug fortran/40218] incorrect location for error message
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-18 14:35 --- Joost, The name of the error message is clearly marked by the '1'. I frankly do not see any need to spend time on this one, so I am marking it as a WONTFIX. If you want to revive it at another time, please do. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Summary|incorrect location for error|incorrect location for error |message |message http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40218
[Bug fortran/40276] Matching GENERIC procedure: Wrong INTENT should give directly an error message
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-18 14:37:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40276
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #14 from pault at gcc dot gnu dot org 2009-12-18 14:42 --- Hi guys! Do you want to suspend this PR or to junk it? Let's get it out of the unconfirmed list. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug tree-optimization/40168] missing unrolling/scalarization/reassoc/free
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-12-18 14:45 --- There is still the issue about the 2nd testcase. It needs to be re-analyzed and possibly simplified. But it's now a pure optimization issue, not a frontend issue anymore. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-18 14:45:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
[Bug libfortran/40319] write (*,'(A1)') 65 should generate an error/warning
--- Comment #2 from pault at gcc dot gnu dot org 2009-12-18 14:45 --- Hmmm! What shall we do with this? IMHO we should issue a WONTFIX. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40319
[Bug libfortran/40344] O32 libgfortran.so fails to link on IRIX 6.5
--- Comment #4 from pault at gcc dot gnu dot org 2009-12-18 14:48 --- I cannot see any point in retaining this PR against the gfortran target. I am marking it, especially in light of Rainer's remarks, as WONTFIX. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40344
[Bug fortran/40453] Enhanced argument checking:
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-18 14:49:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40453
[Bug fortran/40165] Excessive warnings for REAL DO loops
--- Comment #5 from burnus at gcc dot gnu dot org 2009-12-18 14:43 --- I would like to see an option to silence gfortran in this regard - having it as default warning is fine, but maybe some -Wno-deleted option could be added then? Or like g95 and ifort have (gcc/g++ as well?) a fine tuning of the warning to disable such warnings. Having only one warning (and skipping the others if one has been printed) is just one option to reduce the clutter of default warnings if one compiles a legacy program, which one does not want to rewrite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40165
[Bug fortran/40581] Missed optimization in scalar operators on arrays
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-18 14:53 --- What do you want to do with this, Tobias? Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-18 14:53:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40581
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-12-18 14:54 --- I noticed that in libjava/sysdep/arm/backtrace.h, arm has its own definition of _Unwind_FindEnclosingFunction. Could we use the same approach for darwin10 to override the default _Unwind_FindEnclosingFunction in darwin10? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
--- Comment #7 from jason at gcc dot gnu dot org 2009-12-18 15:20 --- EDG accepts it in G++ mode, but not by default. The patch I'm testing accepts it with -fpermissive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- Comment #12 from rainer at emrich-ebersheim dot de 2009-12-18 15:29 --- (In reply to comment #11) (In reply to comment #10) Should be fixed in SVN now. Rainer, please verify when you get a chance. Today I will try to build a complete tool chain with shared libstdc++ enabled. I will report back. Seems to work now! Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug libfortran/40319] write (*,'(A1)') 65 should generate an error/warning
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-12-18 15:38 --- I agree, closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40319
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-12-18 15:43 --- Created an attachment (id=19346) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19346action=view) patch to fix SCCVN issue This patch fixes the SCCVN issue, I'm giving it more testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #15 from sgk at troutmask dot apl dot washington dot edu 2009-12-18 15:52 --- Subject: Re: Complex division by zero in gfortran returns wrong results On Fri, Dec 18, 2009 at 02:42:15PM -, pault at gcc dot gnu dot org wrote: Do you want to suspend this PR or to junk it? Let's get it out of the unconfirmed list. Now that MPC is required by gcc, I'll take a look at making gfortran give a consistent result when comparing its constant folding with generated code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug objc/42293] Can't build ObjC runtime library with GC for W32 target
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-12-18 15:53 --- In mingw-w64 headers we do the following #if !defined(__OBJC__) !defined(__OBJC_BOOL) !defined(__objc_INCLUDE_GNU) #define BOOL WINBOOL #endif For local build for obj-c we use a patched objc.h defining __OBJC_BOOL. This worked for use building it. Maybe this is a general solution for this? Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42293
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
--- Comment #8 from jason at gcc dot gnu dot org 2009-12-18 16:13 --- Subject: Bug 42415 Author: jason Date: Fri Dec 18 16:12:50 2009 New Revision: 155347 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155347 Log: PR c++/42415 * call.c (build_new_method_call): Complain about calling the constructor directly. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tc1/dr147.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
--- Comment #9 from jason at gcc dot gnu dot org 2009-12-18 16:16 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug preprocessor/42407] Detect non-unique header file names.
--- Comment #2 from don at drexel dot edu 2009-12-18 16:21 --- Thanks for confirming this bug. I suspect that this issue may generate a bit of discussion before an implementation plan is created. Interactions with fixincludes may also need to be worked out. For reference I have written a short blog post describing the use case which led me to file this bug report: http://www.donpellegrino.com/blog/?p=27 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42407
[Bug c++/28300] In-class partial specialization of class accepted
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-08-31 03:20:42 |2009-12-18 16:21:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28300
[Bug c++/42062] [4.3/4.4/4.5 Regression] Trouble with invalid template specialization
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-27 11:20:05 |2009-12-18 16:24:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42062
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #16 from ghazi at gcc dot gnu dot org 2009-12-18 17:16 --- (In reply to comment #15) Now that MPC is required by gcc, I'll take a look at making gfortran give a consistent result when comparing its constant folding with generated code. BTW, I put in some special-case code in arith.c:gfc_arith_divide() to ensure we still got the old fortran divide behavior. You probably want to remove it if you're working on this PR. See note #3 from this patch: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01368.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug target/42427] New: invalid assembly code for 301.apsi for -fnon-call-exceptions
GCC trunk gets a ICE when building SPEC CPU2000 test 301.apsi with -O2
-fnon-call-exceptions -fpeel-loops -fexceptions, as demonstrated by this
minimized testcase:
SUBROUTINE TEST(HELP,WM,NZ)
IMPLICIT REAL*8 (A-H, O-Z)
REAL*8 HELP(NZ)
COMPLEX*16 WM(NZ)
DO K=1,NZ
ZNEW=ABS(WM(K))
ZOLD=HELP(K)
HELP(K)=ZNEW
ENDDO
RETURN
END
elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gfortran -c -O2 -fexceptions
-fnon-call-exceptions -fpeel-loops bug.f
/tmp/ccZKTZkM.s: Assembler messages:
/tmp/ccZKTZkM.s:38: Error: syntax error; found `,' but expected `('
/tmp/ccZKTZkM.s:38: Error: junk at end of line: `,3
The assembly code here is:
lwz 4,4(9)
lwz 3,9,3 line 38
lwz 5,8(9)
lwz 6,12(9)
bl cabs
The failure begins with this patch:
http://gcc.gnu.org/viewcvs?view=revrev=154688
r154688 | bernds | 2009-11-26 21:41:42 + (Thu, 26 Nov 2009)
I ran into this by running CPU2000 with a number of sets of options generated
by a tool called allpairs.
--
Summary: invalid assembly code for 301.apsi for -fnon-call-
exceptions
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42427
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-12-18 18:27 --- Tobias, thanks for your description. I'm still a bit hazy on the details, but I changed my tree according to what I picked up. Question is, how do I verify that the issue described in the initial report is fixed? Currently rebuilding with maintainer-mode and nls enabled ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org GCC build triplet|pa...@gcc.gnu.org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug fortran/42428] New: String parameter error when optional parameter missing
Using gfortran 4.4.1, a string parameter passed to a subroutine is mangled when an optional parameter is missing. I enclose a simplified example below. In the original 2000+ line program, the string passed was the required string plus the string from the following error checking call. In this simplified example this does not happen but AMPLITUDE gets truncated to A. === program test_error c c program to try and regenerate gfortran error c call oc5select_name(AMPLITUDE) c call oc5error_test(Error message) end subroutine oc5select_name(dname, report) IMPLICIT none c CHARACTER (LEN=*), INTENT(IN) :: dname LOGICAL, OPTIONAL, INTENT(IN) :: report LOGICAL:: verbose c verbose = .false. if(present(report)) verbose = .true. print *, dname = ,dname return end === Correct output : AMPLITUDE Output from gfortran -o test_error test_error.F is: A When subroutine call is changed to: call oc5select_name(AMPLITUDE,.true.) output is: AMPLITUDE Regards, David Webb. As appears to be requested in one of the bug pages I enclose the output from gfortran -v -save-temps = ~/test gfortran -v -save-temps -o test_error test_error.F Driving: gfortran -v -save-temps -o test_error test_error.F -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.4 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test_error' '-shared-libgcc' '-mtune=generic' /usr/lib64/gcc/x86_64-suse-linux/4.4/f951 test_error.F -ffixed-form -cpp test_error.f90 -quiet -v test_error.F -quiet -dumpbase test_error.F -mtune=generic -auxbase test_error -version -fintrinsic-modules-path /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude -o test_error.s #include ... search starts here: #include ... search starts here: /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude /usr/local/include /usr/lib64/gcc/x86_64-suse-linux/4.4/include /usr/lib64/gcc/x86_64-suse-linux/4.4/include-fixed /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/include /usr/include End of search list. GNU Fortran (SUSE Linux) version 4.4.1 [gcc-4_4-branch revision 150839] (x86_64-suse-linux) compiled by GNU C version 4.4.1 [gcc-4_4-branch revision 150839], GMP version 4.3.1, MPFR version 2.4.1-p5. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test_error' '-shared-libgcc' '-mtune=generic' /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/as -V -Qy -o test_error.o test_error.s GNU assembler version 2.19.51 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE 11.2) 2.19.51.20090527-10.26.4 COMPILER_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.4/:/usr/lib64/gcc/x86_64-suse-linux/4.4/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/4.4/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/ LIBRARY_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.4/:/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/lib/:/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test_error' '-shared-libgcc' '-mtune=generic' /usr/lib64/gcc/x86_64-suse-linux/4.4/collect2 --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test_error /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../lib64/crt1.o /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-suse-linux/4.4/crtbegin.o -L/usr/lib64/gcc/x86_64-suse-linux/4.4 -L/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.4/../../.. test_error.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib64/gcc/x86_64-suse-linux/4.4/crtend.o
[Bug fortran/42428] String parameter error when optional parameter missing
--- Comment #1 from kargl at gcc dot gnu dot org 2009-12-18 19:39 --- Your program is non-conforming. You need to have an explicit interface for the subroutine with an optional argument. Put your main program in one file and the subroutine in another. When you compile the main program, how is the compiler suppose to know that the subroutine has an optional argument? Try something like the following or use a module. program test_error interface subroutine oc5select_name(dname, report) CHARACTER (LEN=*), INTENT(IN) :: dname LOGICAL, OPTIONAL, INTENT(IN) :: report end subroutine oc5select_name end interface c program to try and regenerate gfortran error c call oc5select_name(AMPLITUDE) c call oc5error_test(Error message) end -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42428
[Bug c++/42062] [4.3/4.4/4.5 Regression] Trouble with invalid template specialization
--- Comment #4 from jason at gcc dot gnu dot org 2009-12-18 20:50 --- Subject: Bug 42062 Author: jason Date: Fri Dec 18 20:49:58 2009 New Revision: 155349 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155349 Log: PR c++/28300 PR c++/42062 * pt.c (check_specialization_namespace): Complain about specialization at non-namespace scope. Added: trunk/gcc/testsuite/g++.dg/template/spec37.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42062
[Bug c++/28300] In-class partial specialization of class accepted
--- Comment #3 from jason at gcc dot gnu dot org 2009-12-18 20:50 --- Subject: Bug 28300 Author: jason Date: Fri Dec 18 20:49:58 2009 New Revision: 155349 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155349 Log: PR c++/28300 PR c++/42062 * pt.c (check_specialization_namespace): Complain about specialization at non-namespace scope. Added: trunk/gcc/testsuite/g++.dg/template/spec37.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28300
[Bug c++/42415] [4.5 Regression] Bad assembly generated for constructor call
--- Comment #10 from jason at gcc dot gnu dot org 2009-12-18 20:50 --- Subject: Bug 42415 Author: jason Date: Fri Dec 18 20:50:08 2009 New Revision: 155350 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155350 Log: PR c++/42415 * g++.old-deja/g++.jason/temporary5.C: Adjust. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.jason/temporary5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #39 from dominiq at lps dot ens dot fr 2009-12-18 21:04 --- The patch in comment #38 does not fix the speed issue: the code with the inner loop is still 4 times slower than the code with the loop manually unrolled. Note that the included test regtests successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #40 from matz at gcc dot gnu dot org 2009-12-18 21:40 --- That's expected. There are three problems and the patch in comment #38 hacks around only one of them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug rtl-optimization/42429] New: Miscompilation of 2fish on s390
The testcase I'm going to attach is miscompiled with -m31 -O2 -fno-inline -march=z9-109 -mtune=z10 (-march=z990 instead of -march=z9-109 too), aborts in that case. With sed 's/schedule-insns/no-schedule-insns/' works fine. Fails on current branches/gcc-4_4-branch as well as redhat/gcc-4_4-branch, when compiled with a x86_64-linux - s390x-linux cross or natively. -- Summary: Miscompilation of 2fish on s390 Product: gcc Version: 4.4.2 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: s390x-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429
[Bug rtl-optimization/42429] Miscompilation of 2fish on s390
--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-18 22:08 --- Created an attachment (id=19347) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19347action=view) 2fish.c Simplified testcase from twofish's test. The optimize attribute is of course not needed to reproduce it, is just included to show that -fno-schedule-insns on that one huge routine alone cures it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429
[Bug lto/42430] New: error: non-trivial conversion at assignment when linking with -flto/-fwhopr
Command line: g++ A.cpp B.cpp -fPIC -shared -O1 -flto or g++ A.cpp B.cpp -fPIC -shared -O1 -fwhopr Tested revisions: r155256, with checking - crash r155248, with checking - crash r155248, without checking - OK r154830, with checking - crash Output: $ /mnt/svn/gcc-trunk/binary-155256-lto/bin/g++ A.cpp B.cpp -fPIC -shared -O1 -flto In file included from :0:0: A.cpp: In function #8216;GetA#8217;: A.cpp:11:11: error: non-trivial conversion at assignment struct A * struct B * D.2058_1 = D.2059_6(D); A.cpp:11:11: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /mnt/svn/gcc-trunk/binary-155256-lto/bin/g++ returned 1 exit status collect2: lto-wrapper returned 1 exit status -- Summary: error: non-trivial conversion at assignment when linking with -flto/-fwhopr Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42430
[Bug lto/42430] error: non-trivial conversion at assignment when linking with -flto/-fwhopr
--- Comment #1 from zsojka at seznam dot cz 2009-12-18 22:12 --- Created an attachment (id=19348) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19348action=view) A.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42430
[Bug lto/42430] error: non-trivial conversion at assignment when linking with -flto/-fwhopr
--- Comment #2 from zsojka at seznam dot cz 2009-12-18 22:12 --- Created an attachment (id=19349) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19349action=view) B.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42430
[Bug lto/42430] error: non-trivial conversion at assignment when linking with -flto/-fwhopr
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-18 22:27 --- This code is invalid C++ code as it is a violation of the one definition rule. That is Pool::Get returns two different types in the two different translation units. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42430
[Bug target/42431] New: wrong code for 200.sixtrack with vectorization and -fdata-sections
When compiled with current trunk and options -m64 -O2 -ftree-vectorize -maltivec -fdata-sections, CPU2000 test 200.sixtrack gets wrong results and segfaults before finishing. I've reproduced the failure on POWER6 and POWER7 hardware. The source file that is miscompiled is midbloc6.f. If I add this line: if (icount1.eq.187) write (*,*) ' howdy' to any two of the DO loops associated with labels 20, 40, 50, 110, 200, 210, 220, 260, and 280 then the test runs to completion and gets the expected output. The test passes with these options with GCC 4.4.0. I don't currently have a reg hunt setup on a machine with AltiVec but can do that it if would be useful. -- Summary: wrong code for 200.sixtrack with vectorization and - fdata-sections Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
[Bug target/42431] wrong code for 200.sixtrack with vectorization and -fdata-sections
--- Comment #1 from janis at gcc dot gnu dot org 2009-12-18 23:03 --- Oh yeah, 176.gcc fails with the same options. With test input it runs for a few minutes instead of a couple of seconds, and the results are wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
[Bug target/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|wrong code for 200.sixtrack |[4.5 Regression] wrong code |with vectorization and -|for 200.sixtrack with |fdata-sections |vectorization and -fdata- ||sections Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
[Bug c++/42062] [4.3/4.4/4.5 Regression] Trouble with invalid template specialization
--- Comment #5 from jason at gcc dot gnu dot org 2009-12-18 23:14 --- Fixed for 4.5, not backporting invalid-code changes. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42062
[Bug lto/42430] error: non-trivial conversion at assignment when linking with -flto/-fwhopr
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-18 23:15 --- We could diagnose this, but the C++ standard doesn't require a diagnostic (and with functions it unfortunately happens too common and would be very noisy). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42430
[Bug rtl-optimization/42429] Miscompilation of 2fish on s390
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-18 23:17 --- Btw, we have similar issues with the SLES11 gcc 4.3 compiler and openssl. See https://bugzilla.novell.com/show_bug.cgi?id=457410 -- 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=42429
[Bug target/42427] [4.5 Regression] invalid assembly code for 301.apsi for -fnon-call-exceptions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|invalid assembly code for |[4.5 Regression] invalid |301.apsi for -fnon-call-|assembly code for 301.apsi |exceptions |for -fnon-call-exceptions Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42427
[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression
--- Comment #41 from rguenth at gcc dot gnu dot org 2009-12-18 23:44 --- Indeed. The PRE issue could be fixed by fixing PR38819 not in the way it is done now but properly detect the invalid situations during ANTIC computation and simply never mark trapping expressions so. At the current point its hard to tell if the insertion is valid because the original expression is always executed if the insertion point is - simply because we no longer know where the original expression was. Thus, the proper place (err, I think at least) is during translating ANTIC_OUT through the basic-block to ANTIC_IN (thus, in clean()). It might be a bit expensive, though pre-computing if a basic-block possibly exits the CFG could speed this up significantly. Another proper place would be to add fake edges to exit for each such point in the CFG (basically split blocks at each possibly noreturn call and add an edge to exit). But that might be even more expensive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #38 from howarth at nitro dot med dot uc dot edu 2009-12-19 00:35 --- I've confirmed that both the WalkerTest failures and the gcj compiler crashes on java code are eliminated on darwin10 if I duplicate the code for _Unwind_FindEnclosingFunction() as _darwin10_Unwind_FindEnclosingFunction() and export that via the versioned libgcc_ext. So the entire problem is that darwin10's _Unwind_FindEnclosingFunction() is non-functional (and just calls abort()). Fortunately, since FSF gcc builds on darwin10 without compact unwind we still have access to a functional _Unwind_Find_FDE(). We just need to find some approach short of adding a new symbol to libgcc that will provide an alternate means of accessing the code for _Unwind_FindEnclosingFunction() on darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug lto/42401] wrong-code with -flto
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-19 00:41 ---
The following seems to fix it for some reason.
Index: lto-streamer-out.c
===
--- lto-streamer-out.c (revision 155347)
+++ lto-streamer-out.c (working copy)
@@ -638,7 +638,8 @@ tree_is_indexable (tree t)
{
if (TREE_CODE (t) == PARM_DECL)
return false;
- else if (TREE_CODE (t) == VAR_DECL decl_function_context (t))
+ else if (TREE_CODE (t) == VAR_DECL decl_function_context (t)
+ !TREE_STATIC (t))
return false;
else
return (TYPE_P (t) || DECL_P (t) || TREE_CODE (t) == SSA_NAME);
@@ -694,7 +695,8 @@ lto_output_tree_ref (struct output_block
case VAR_DECL:
case DEBUG_EXPR_DECL:
- gcc_assert (decl_function_context (expr) == NULL);
+ gcc_assert (decl_function_context (expr) == NULL
+ || TREE_STATIC (expr));
output_record_start (ob, LTO_global_decl_ref);
lto_output_var_decl_index (ob-decl_state, ob-main_stream, expr);
break;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42401
[Bug lto/42401] wrong-code with -flto
--- Comment #5 from matz at gcc dot gnu dot org 2009-12-19 01:19 --- To explain: the miscompilation is a result of the cloner (when cloning for the find() call) creating a new tree for a local static variable (the 'm' in main). After inlining we have: if ( mD.2293._M_tD.2062._M_implD.2039._M_headerD.2043 != mD.2303._M_tD.2062._M_implD.2039._M_headerD.2043) note the different UIDs for 'm'. fold will say true to the unequality, as references to static vars are unequal if the base VAR_DECL is different. The reason for all this is because the LTO reader/writer of jump_functions create the new tree already. The input for the LTO writer contains the same tree node for the decl in main and the jump_function (val.constant), but as it uses a different output_block (hence unshared cache) it can't find the tree and emits a new copy. For whatever reason richis patch makes this work, but I can't see why it does ... ;-/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42401
[Bug preprocessor/42407] Detect non-unique header file names.
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-12-19 01:20 --- I guess this option should have a few warning levels. For example, -Wcovered-headers (or -Wcovered-headers=1, which is the same) will not warn about fixed and GCC's private include files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42407
[Bug lto/42401] wrong-code with -flto
--- Comment #6 from matz at gcc dot gnu dot org 2009-12-19 02:33 --- Ah, because the references to trees are not handled via the write_cache hashtable, but via the per-kind stream (in output_block.decl_state), which is not realloced on create_output_block, but only on lto_push/pop_out_decl_state. Unintuitive :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42401
[Bug c/42432] New: accessing a field via two pointers to structures that share a common prefix
In ISO C99 6.5.2.3 paragraph 5, it is mentioned that:
``One special guarantee is made in order to simplify the use of unions: if a
union contains several structures that share a common initial sequence (see
below), and if the union object currently contains one of these structures, it
is permitted to inspect the common initial part of any of them anywhere that a
declaration of the complete type of the union is visible.''
The code in the two files below shows that function f is over-optimized (when
compiled with -O3) w.r.t (my reading of) the above paragraph. Putting the
definition of f right after main does not show the problem (perhaps due to
overall constant propagation and inlining). The problem is also prevented by
telling -fno-strict-aliasing to gcc, but IMO the code is conforming to ISO C99
and should not need this flag to compile properly.
// file prog.c
typedef struct A { int i; int j; double d; } A;
typedef struct B { int i; int j; char *pc; } B;
typedef union U { A a; B b; } U;
extern int f(A *, B *);
int main(void)
{
U u = { { 1, 1, 0 } };
return f(u.a, u.b);
}
// file f.c
typedef struct A { int i; int j; double d; } A;
typedef struct B { int i; int j; char *pc; } B;
typedef union U { A a; B b; } U; // union visible before definition of f
extern int f(A *, B *);
int f(A *pa, B *pb)
{
pa-j += 2;
pb-j += 3; // hence, this should be known as a possible alias for pa-j
return pa-j;
}
// Compilation (no warnings issued)
gcc -Wall -Wextra --std=gnu99 -O3 prog.c f.c -o prog
// Expected return value: 6
// gcc-4.4.1 -O3: 3
// gcc-4.4.1 -O3 -fno-strict-aliasing: 6
// gcc-4.4.1 all code in one file: 6
// gcc-3.4.6: 6
Regards,
--
Daniel Villeneuve
Kronos
--
Summary: accessing a field via two pointers to structures that
share a common prefix
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dvilleneuve at kronos dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42432
[Bug c/42432] accessing a field via two pointers to structures that share a common prefix
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-19 03:45 --- *** This bug has been marked as a duplicate of 14319 *** -- 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=42432
[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-12-19 03:45 --- *** Bug 42432 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dvilleneuve at kronos dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319
