[Bug c/48070] New: Application fails assertion when compiled with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48070 Summary: Application fails assertion when compiled with optimizations Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: shadow7...@gmail.com Created attachment 23625 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23625 Source code which triggers the bug I have run into a problem where my application will fail assertions when compiled with optimizations that it would pass when compiled without them. The code compiles without any warnings or errors. I am running Ubuntu 10.10 (AMD64) on an Intel Core 2 Duo P8600. I am compiling the code with -Wall -Werror -std=c99. The code I have attached is the full source to my raytracer, and I have coded in a scene which renders quickly (5 seconds) and triggers the bug when compiled with optimizations. The executable produced takes no arguments and produces a output bitmap image. Note, the makefile included in the attached source is set to build without optimizations, so the code produced initially should run successfully to completion.
[Bug c/48070] Application fails assertion when compiled with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48070 Brad Shadow7789 at gmail dot com changed: What|Removed |Added Severity|normal |major
[Bug ada/37430] [4.4/4.5/4.6 Regression] C974013 gives exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37430 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|4.4.6 |4.6.0 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-11 08:49:28 UTC --- Reopen if not.
[Bug c/48070] Target application fails when compiled with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48070 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2011-03-11 09:25:54 UTC --- Even at -O0, valgrind complains about using uninitialised value: (tested with gcc 4.4.5, x86_64-linux) $ valgrind -q --track-origins=yes ./src-O0.exe ==11384== Conditional jump or move depends on uninitialised value(s) ==11384==at 0x40A9A6: scene_trace (scene.c:27) ==11384==by 0x40ABAE: reflect (shading.c:38) ==11384==by 0x40AE2B: lightingAndReflectiveShading (shading.c:75) ==11384==by 0x40AF47: computeHitColor (shading.c:93) ==11384==by 0x4030D3: lenscamera_dof (camera.c:247) ==11384==by 0x40329F: lenscamera_render (camera.c:272) ==11384==by 0x403533: camera_render (camera.c:355) ==11384==by 0x40A8E4: rayFlush (ray.c:763) ==11384==by 0x4064E7: main (main.c:114) ==11384== Uninitialised value was created by a stack allocation ==11384==at 0x40AAE7: reflect (shading.c:27) ==11384== With -O1, there is further warning: ==28521== Conditional jump or move depends on uninitialised value(s) ==28521==at 0x402AF8: ray_setShadowRay (eyeray.c:24) ==28521==by 0x403799: light_nonAmbient (light.c:132) ==28521==by 0x403B1F: light_calculateLighting (light.c:236) ==28521==by 0x407938: computeHitColor (shading.c:22) ==28521==by 0x4077F0: reflect (shading.c:39) ==28521==by 0x4079C0: computeHitColor (shading.c:75) ==28521==by 0x40259F: lenscamera_dof (camera.c:247) ==28521==by 0x402699: lenscamera_render (camera.c:272) ==28521==by 0x4026CC: camera_render (camera.c:355) ==28521==by 0x406261: rayFlush (ray.c:763) ==28521==by 0x4045CC: main (main.c:114) ==28521== Uninitialised value was created by a stack allocation ==28521==at 0x404023: objectpointerlist_intersect (list.c:109) ==28521== src.exe: eyeray.c:24: ray_setShadowRay: Assertion `vector_isPoint( o )' failed.
[Bug c/48070] Target application fails when compiled with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48070 --- Comment #2 from Brad Shadow7789 at gmail dot com 2011-03-11 09:40:27 UTC --- (In reply to comment #1) Even at -O0, valgrind complains about using uninitialised value: (tested with gcc 4.4.5, x86_64-linux) This is likely an unintelligent question, but does that output from valgrind seem to indicate a code error or a compiler error?
[Bug c/48070] Target application fails when compiled with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48070 --- Comment #3 from Zdenek Sojka zsojka at seznam dot cz 2011-03-11 09:44:15 UTC --- (In reply to comment #2) This is likely an unintelligent question, but does that output from valgrind seem to indicate a code error or a compiler error? It can be either (in all cases, compiler error is very unlikely), but it gives a clue where you should have a look. Simple patch: struct Ray reflected; + reflected.shadowRay = 0; vector_copy( hit-worldHit, reflected.origin ); fixes the problem for me.
[Bug c/48070] Target application fails when compiled with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48070 Brad Shadow7789 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Severity|major |normal --- Comment #4 from Brad Shadow7789 at gmail dot com 2011-03-11 09:55:53 UTC --- You're definitely pinned it down. I was using an uninitialized value.
[Bug tree-optimization/48063] [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48063 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.11 09:58:50 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 09:58:50 UTC --- Yep. Patch is ok if it bootstraps tests ok.
[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48065 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking, lto Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.11 10:03:26 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 10:03:26 UTC --- Hum, this checking that triggers is somewhat bogus as at least with LTO we end up rejecting some inlines late in expand_call_inline. With the inliner reorg we should try to avoid this more consistently.
[Bug tree-optimization/48063] [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48063 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 10:04:33 UTC --- Author: jakub Date: Fri Mar 11 10:04:30 2011 New Revision: 170867 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170867 Log: PR tree-optimization/48063 * ipa-inline.c (cgraph_decide_inlining): Don't try to inline functions called once if !tree_can_inline_p (node-callers). * gcc.dg/torture/pr48063.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr48063.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/48063] [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48063 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 10:05:39 UTC --- Fixed.
[Bug c++/46824] [4.6 Regression] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1 Known to work||3.4.6, 4.1.2, 4.5.2 Target Milestone|--- |4.6.0 Summary|chromium-compile failed |[4.6 Regression] |because error: no match for |chromium-compile failed |‘operator*’ in |because error: no match for ||‘operator*’ in --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 10:05:59 UTC --- Works with 4.5.2 and earlier releases and EDG.
[Bug tree-optimization/48052] loop not vectorized if index is unsigned int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-03-11 10:16:37 UTC --- what's the probablity to have this fixed? We depend on a third party matrix library that is fully templated and uses everywhere unsigned int I made a test with a sed -i 's/unsigned int/unsigned long long/g' and it MAKES a difference (up to a factor 2 in speed). This modification (although trivial) changes the type of templated vector and matrix, the signature of functions and also affects user code. It is neither transparent nor backward compatible. I think we cannot afford the change in production: much easier to change compiler version! Thanks for any effort dedicated to solve this issue, Vincenzo On 10 Mar, 2011, at 12:22 PM, paolo.carlini at oracle dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-10 11:22:26 UTC --- Vincenzo, if I understand correctly, maybe Sebastian can also tell us more, the issue seems that, at some stage, the logic is fully general only assuming the widest unsigned type (*), doesn't cope with smaller types. Thus, if my theory is correct, unsigned char, unsigned short, etc, all should cause problems. On the other hand, on x86_64, unsigned long, unsigned long long, size_t, are all the same size, and all work (**) (*) I don't consider int128, I don't think is relevant for loop optimization. (**) On x86, however, unsigned int (aka unsigned long) appears to work, hum. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. -- Il est bon de suivre sa pente, pourvu que ce soit en montant. A.G. http://www.flickr.com/photos/vin60/1320965757/
[Bug tree-optimization/48067] [4.6 Regression] FMA with no add operand produced by convert_mul_to_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48067 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target|powerpc64-linux |powerpc64-linux, x86_64-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.11 10:17:47 Host|powerpc64-linux | AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 Summary|FMA with no add operand |[4.6 Regression] FMA with |produced by |no add operand produced by |convert_mul_to_fma |convert_mul_to_fma Ever Confirmed|0 |1 Build|powerpc64-linux | --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 10:17:47 UTC --- Reproduces on trunk/x86_64 with -O2 -ffast-math -mfma4 -fno-tree-forwprop -fno-tree-reassoc on trunk both forwprop and reassoc change d12_8 = -c12_7; D.745_11 = c12_7 - d12_8; to D.745_11 = c12_7 + c_12_7; making the issue latent.
[Bug tree-optimization/48052] loop not vectorized if index is unsigned int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #8 from rguenther at suse dot de rguenther at suse dot de 2011-03-11 10:26:47 UTC --- On Fri, 11 Mar 2011, vincenzo.innocente at cern dot ch wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-03-11 10:16:37 UTC --- what's the probablity to have this fixed? A fix for this is quite involved (and honestly its on my TODO list for at least two years - but I chickened out repeatedly because of all the issues). I'm not sure if a SCEV local fix is possible, Sebastian will probably comment on this. Richard.
[Bug c++/47808] [4.6 Regression][C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47808 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 10:29:49 UTC --- I think it isn't the ?: arms here, but the condition on which convert_like_real is called. fold_nondependent_expr on the COND_EXPR called from compute_array_index_type results in tsubst_copy_and_build on the CALL_EXPR to abs overload, which then eventually calls convert_like_real.
[Bug c++/47808] [4.6 Regression][C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47808 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 10:35:17 UTC --- build_aggr_init_expr isn't called at all here BTW, I just don't see too many similarities with PR46003.
[Bug c++/48069] [4.6 Regression] FAIL: g++.old-deja/g++.pt/spec26.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48069 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1
[Bug tree-optimization/47278] [4.3/4.4 Regression] hidden weak function not handled properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47278 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 10:43:35 UTC --- Author: rguenth Date: Fri Mar 11 10:43:31 2011 New Revision: 170868 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170868 Log: 2011-03-11 Richard Guenther rguent...@suse.de PR tree-optimization/47278 * gcc.dg/torture/pr47278-1.c: Require visibility support. * gcc.dg/torture/pr47278-2.c: Likewise. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr47278-1.c branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr47278-2.c
[Bug tree-optimization/47278] [4.3/4.4 Regression] hidden weak function not handled properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47278 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 10:45:59 UTC --- Author: rguenth Date: Fri Mar 11 10:45:54 2011 New Revision: 170869 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170869 Log: 2011-03-11 Richard Guenther rguent...@suse.de PR tree-optimization/47278 * gcc.dg/torture/pr47278-1.c: New testcase. * gcc.dg/torture/pr47278-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr47278-1.c trunk/gcc/testsuite/gcc.dg/torture/pr47278-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/47779] Problem cross-compiling trunk for bfin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47779 --- Comment #4 from Stu Stuart.Henderson at analog dot com 2011-03-11 11:26:04 UTC --- (In reply to comment #3) Maybe ucontext.h should only define these context ifdef __USE_GNU? That's what i386 and x86_64 appear to do. Hi Bernd, Unfortunately __USE_GNU is defined at this point, so that doesn't appear to be what's preventing the problem there. i386 seems to use REG_x in gcc and x_REG in uClibc, which avoids it.
[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48066
--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-11
11:28:57 UTC ---
Draft patch:
--- a/libgfortran/m4/ifunction.m4
+++ b/libgfortran/m4/ifunction.m4
@@ -132,7 +132,10 @@ name`'rtype_qual`_'atype_code (rtype * const restrict
retarray,
')dnl
define(START_ARRAY_BLOCK,
` if (len = 0)
- *dest = '$1`;
+ {
+ if (dest)
+ *dest = '$1`;
+ }
else
{
for (n = 0; n len; n++, src += delta)
@@ -313,7 +316,10 @@ void
')dnl
define(START_MASKED_ARRAY_BLOCK,
` if (len = 0)
- *dest = '$1`;
+ {
+ if (dest)
+ *dest = '$1`;
+ }
else
{
for (n = 0; n len; n++, src += delta, msrc += mdelta)
--- a/libgfortran/m4/ifunction_logical.m4
+++ b/libgfortran/m4/ifunction_logical.m4
@@ -159,7 +159,10 @@ name`'rtype_qual`_'atype_code (rtype * const restrict
retarray,
')dnl
define(START_ARRAY_BLOCK,
`if (len = 0)
- *dest = '$1`;
+ {
+ if (dest)
+ *dest = '$1`;
+ }
else
{
for (n = 0; n len; n++, src += delta)
[Bug c++/46824] [4.6 Regression] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-11 11:58:15 UTC --- (In reply to comment #10) Works with [...] EDG. The reduced versions don't work with Comeau online, does a different EDG-based compiler accept them?
[Bug target/47951] [4.6 Regression] web.c:union_match_dups segmentation fault for bfin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47951 --- Comment #1 from Stu Stuart.Henderson at analog dot com 2011-03-11 12:16:40 UTC --- Created attachment 23626 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23626 First attempt to fix seg fault The attached patch fixes the problem and my testing hasn't shown any problems, but i currently don't have much confidence in it. Could someone take a look and give me some pointers? thanks, Stu
[Bug bootstrap/44768] arm-linux bootstrap broken on expmed.c:157:3: warning ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44768 Emmanuel Blot eblot.ml at gmail dot com changed: What|Removed |Added CC||eblot.ml at gmail dot com --- Comment #9 from Emmanuel Blot eblot.ml at gmail dot com 2011-03-11 12:26:58 UTC --- This issue seems to occur on 4.5.x series. I've just got bitten with a similar issue with 4.5.2: a regular static function wrongly recognized as a no-return function: .typenl_upt_process_download_done.clone.0, %function nl_upt_process_download_done.clone.0: @ Function supports interworking. @ Volatile: function does not return. and context is not restored on return Ubuntu team seem to have encounter the same issue with 4.5.1: https://bugs.launchpad.net/bugs/674146 Is there an official fix ongoing for 4.5.3?
[Bug driver/48071] New: Blank line after 'all warnings being treated as errors'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48071 Summary: Blank line after 'all warnings being treated as errors' Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: dnovi...@gcc.gnu.org After -Werror is triggered, we are now emitting an extra blank line that we were not emitting before. $ cat a.cc char c = 257; $ g++-4.4.3 -c -o /dev/null -Werror a.cc cc1plus: warnings being treated as errors a.cc:1: error: overflow in implicit constant conversion $ But with trunk, I get: $ ~/gcc-trunk/native/bin/g++ -c -o /dev/null -Werror a.cc a.cc:1:10: error: overflow in implicit constant conversion [-Werror=overflow] cc1plus: all warnings being treated as errors [... extra blank line ...] $
[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #6 from Michael Matz matz at gcc dot gnu.org 2011-03-11 13:35:04 UTC --- Without the assert it tries to generate this code: struct __class_a_module_B_type * D.1572; D.1572 = (struct __class_a_module_B_type *) this; D.1574 = D.1572-_data-length; It's the forming of _data-length that is wrong. That is because _data is of type b_type, and that one doesn't have a 'length' member. It only has a a_type member, and _that_ one has length. So, what it should have generated is: D.1574 = D.1572-_data-a_type.length; I think the inputs to conv_parent_component_references are already wrong. From the caller of that function (gfc_conv_variable): 755 case REF_COMPONENT: 756 if (ref-u.c.sym-attr.extension) 757 conv_parent_component_references (se, ref); 758 759 gfc_conv_component_ref (se, ref); (gdb) p debug_generic_expr(se-expr) *D.1572 (That's the b_type variable) (gdb) p ref-u.c.sym-name $55 = 0x77f47b28 __class_a_module_A_type (gdb) p ref-u.c.component-name $56 = 0x77e7ffa0 length So, it wants to get at the a_type.length member, but applies the whole thing to a b_type'd variable. That's not what conv_parent_component_references is supposed to fix up. I don't know enough about fortrans OOP implementation to suggest where this is supposed to be fixed up.
[Bug tree-optimization/48072] New: Function with __attribute__((used)) is not inlined at -O1 level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48072 Summary: Function with __attribute__((used)) is not inlined at -O1 level Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 23627 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23627 Testcase
[Bug middle-end/48044] [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:875
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48044 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 13:45:00 UTC --- Created attachment 23628 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23628 gcc46-pr48044.patch This fixed it and passed bootstrap/regtest.
[Bug tree-optimization/48072] Function with __attribute__((used)) is not inlined at -O1 level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48072 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 13:47:27 UTC --- Why should it be? Because of the used attribute it can't be considered as called just once, so -finline-functions-called-once doesn't apply. And it isn't declared inline either.
[Bug fortran/47768] ICE: printing a derived-type variable with proc-pointer components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47768 --- Comment #7 from janus at gcc dot gnu.org 2011-03-11 14:13:52 UTC --- Author: janus Date: Fri Mar 11 14:13:49 2011 New Revision: 170871 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170871 Log: 2011-03-11 Janus Weil ja...@gcc.gnu.org PR fortran/47768 * module.c (ab_attribute,attr_bits): Add AB_PROC_POINTER_COMP. (mio_symbol_attribute): Handle attribute 'proc_pointer_comp'. 2011-03-11 Janus Weil ja...@gcc.gnu.org PR fortran/47768 * gfortran.dg/proc_ptr_comp_31.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_31.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48073] New: ICE with -flto in templated C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48073 Summary: ICE with -flto in templated C++ code Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: tux...@googlemail.com The following code produces an ICE if compiled with -flto on g++-4.6.0 SVN revision 170867 $$$ g++ -flto zombie_coldatoms.cpp zombie_coldatoms.cpp:48:1: internal compiler error: tree check: did not expect class ‘type’, have ‘type’ (record_type) in contains_placeholder_p, at tree.c:2820 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Replacing the default constructor DDQMC(); in line 36 by the automatic default constructor (i.e. removing the corresponding code) makes the code compile. The problem does not occur with g++-4.5.1
[Bug c++/48073] ICE with -flto in templated C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48073 --- Comment #1 from tux008 at googlemail dot com 2011-03-11 14:19:51 UTC --- Created attachment 23629 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23629 preprocessed code
[Bug c++/48073] ICE with -flto in templated C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48073 --- Comment #2 from tux008 at googlemail dot com 2011-03-11 14:20:49 UTC --- Created attachment 23630 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23630 (almost empty) assembly code file produced by g++-4.6.0 r170867
[Bug c++/46824] [4.6 Regression] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 14:21:26 UTC --- I checked comment #5 with ICC 12.0 in -strict_ansi mode.
[Bug tree-optimization/48072] Function with __attribute__((used)) is not inlined at -O1 level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48072 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 14:22:35 UTC --- Yep. Works as designed.
[Bug c++/48073] ICE with -flto in templated C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48073
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||lto
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.03.11 14:35:00
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11
14:35:00 UTC ---
Confirmed. We're in
4318static inline void
4319free_lang_data_in_one_sizepos (tree *expr_p)
4320{
4321 tree expr = *expr_p;
4322 if (CONTAINS_PLACEHOLDER_P (expr))
4323*expr_p = build0 (PLACEHOLDER_EXPR, TREE_TYPE (expr));
4324}
for
minus_expr 0x77ff91f8
type integer_type 0x77ee9000 long unsigned int public unsigned
sizetype DI
size integer_cst 0x77ed37a8 constant 64
unit size integer_cst 0x77ed37d0 constant 8
align 64 symtab 0 alias set -1 canonical type 0x77ee9000 precision
64 min integer_cst 0x77ed37f8 0 max integer_cst 0x77ed3e88 -1
arg 0 scope_ref 0x77ff91c0
arg 0 record_type 0x75b909d8 TListLength type_0 type_5 type_6 VOID
align 8 symtab 0 alias set -1 canonical type 0x75b7ec78 context
translation_unit_decl 0x77edf958 D.1
full-name struct TListLengthMoves
no-binfo use_template=1 interface-unknown
chain type_decl 0x75b917e8 TListLength
arg 1 identifier_node 0x75b8d108 Ret
bindings (nil)
local bindings (nil)
arg 1 integer_cst 0x77efc000 type integer_type 0x77ee9498 int
constant 1
which is the max-value of
integer_type 0x75b90a80
type integer_type 0x77ee9000 long unsigned int public unsigned
sizetype DI
size integer_cst 0x77ed37a8 constant 64
unit size integer_cst 0x77ed37d0 constant 8
align 64 symtab 0 alias set -1 canonical type 0x77ee9000 precision
64 min integer_cst 0x77ed37f8 0 max integer_cst 0x77ed3e88 -1
type_0 type_6 DI size integer_cst 0x77ed37a8 64 unit size
integer_cst 0x77ed37d0 8
align 64 symtab 0 alias set -1 structural equality precision 64 min
integer_cst 0x77ed3410 0 max minus_expr 0x77ff91f8
which is in TYPE_DOMAIN of an array-type of a field-decl of DDQMC which
is the type of an IDENTIFIER_NODE.
I have a patch.
[Bug c++/47198] [4.5 Regression] [C++0x] ICE: tree check: expected var_decl or function_decl, have template_decl in check_bases_and_members, at cp/class.c:4654 on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47198 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|4.5.3 |4.6.0 Summary|[4.5/4.6 Regression]|[4.5 Regression] [C++0x] |[C++0x] ICE: tree check:|ICE: tree check: expected |expected var_decl or|var_decl or function_decl, |function_decl, have |have template_decl in |template_decl in|check_bases_and_members, at |check_bases_and_members, at |cp/class.c:4654 on invalid |cp/class.c:4654 on invalid |code |code| --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 14:35:41 UTC --- Fixed for 4.6.0. Not worth backporting fix for ICE after correct error.
[Bug c++/48069] [4.6 Regression] FAIL: g++.old-deja/g++.pt/spec26.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48069 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 14:37:36 UTC --- Weird, I wonder how my testing missed that.
[Bug c++/48069] [4.6 Regression] FAIL: g++.old-deja/g++.pt/spec26.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48069 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 14:44:53 UTC --- Author: jason Date: Fri Mar 11 14:44:49 2011 New Revision: 170872 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170872 Log: PR c++/48069 * tree.c (type_hash_eq): Use COMPLETE_TYPE_P, not COMPLETE_OR_UNBOUND_ARRAY_TYPE_P. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c
[Bug c++/47808] [4.6 Regression][C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47808 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 --- Comment #7 from janus at gcc dot gnu.org 2011-03-11 14:45:22 UTC --- (In reply to comment #6) I think the inputs to conv_parent_component_references are already wrong. From the caller of that function (gfc_conv_variable): 755 case REF_COMPONENT: 756 if (ref-u.c.sym-attr.extension) 757 conv_parent_component_references (se, ref); 758 759 gfc_conv_component_ref (se, ref); (gdb) p debug_generic_expr(se-expr) *D.1572 (That's the b_type variable) (gdb) p ref-u.c.sym-name $55 = 0x77f47b28 __class_a_module_A_type (gdb) p ref-u.c.component-name $56 = 0x77e7ffa0 length So, it wants to get at the a_type.length member, but applies the whole thing to a b_type'd variable. Yes, the base type in the reference is wrong. And the reason for this seems to be that it is not corrected in the interface mapping. I think we need to extend 'gfc_apply_interface_mapping_to_ref' to set the correct base type for polymorphic arguments.
[Bug c++/48069] [4.6 Regression] FAIL: g++.old-deja/g++.pt/spec26.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48069 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 14:46:12 UTC --- Fixed.
[Bug middle-end/48044] [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:875
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48044 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug c++/48035] [4.4/4.5/4.6 Regression] Mismatch on size of class when initializing hierarchy involving virtual inheritance and empty base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48035 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/48044] [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:875
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48044 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 14:47:29 UTC --- Author: jakub Date: Fri Mar 11 14:47:26 2011 New Revision: 170873 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170873 Log: PR middle-end/48044 * ipa.c (cgraph_remove_unreachable_nodes): Enqueue all vnode-force_output nodes as needed. * gcc.dg/torture/pr48044.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr48044.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/48067] [4.6 Regression] FMA with no add operand produced by convert_mul_to_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48067
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11
14:50:13 UTC ---
(In reply to comment #2)
Reproduces on trunk/x86_64 with
-O2 -ffast-math -mfma4 -fno-tree-forwprop -fno-tree-reassoc
on trunk both forwprop and reassoc change
d12_8 = -c12_7;
D.745_11 = c12_7 - d12_8;
to
D.745_11 = c12_7 + c_12_7;
making the issue latent.
C testcase with the above flags:
float
foo (float x, float cim)
{
float c = x * cim;
float d = -c;
return c - d;
}
[Bug middle-end/48044] [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:875
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48044 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 14:52:27 UTC --- Fixed.
[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299 --- Comment #11 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2011-03-11 15:15:16 UTC --- (In reply to comment #10) If you don't want this warning, please contribute a testcase to gcc-patc...@gcc.gnu.org, so this warning won't reappear in the future: Done: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00624.html
[Bug c++/48074] New: [trans-mem] regular function used instead of clone in a transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48074 Summary: [trans-mem] regular function used instead of clone in a transaction Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23631 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23631 not so big testcase. In a relaxed transaction, some functions (stl? template?) in an transaction doesn't call the clone version (not in an irrevocable mode: neither attribute doesGoIrrevocable nor ITM_changeTransactionMode). You can verify this in the function stepDestroyBuildings (_ZL20stepDestroyBuildingsi) in Team.cpp (from glob2, kind of testcase attached), the function _ZNSt4listIP8BuildingSaIS1_EE5beginEv is called directly (not the clone, no changeTransactionMode) even if in a transaction. I had a quick look and the clone function exists but the call seems not be replaced. It seems to happen when one transaction is followed by another one (at least related). Patrick Marlier.
[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #8 from janus at gcc dot gnu.org 2011-03-11 15:39:20 UTC --- (In reply to comment #7) So, it wants to get at the a_type.length member, but applies the whole thing to a b_type'd variable. Yes, the base type in the reference is wrong. And the reason for this seems to be that it is not corrected in the interface mapping. I think we need to extend 'gfc_apply_interface_mapping_to_ref' to set the correct base type for polymorphic arguments. The following seems to do the trick (not regtested yet): Index: trans-expr.c === --- trans-expr.c(revision 170870) +++ trans-expr.c(working copy) @@ -2247,6 +2247,9 @@ gfc_apply_interface_mapping_to_expr (gfc_interface expr-symtree = sym-new_sym; else if (sym-expr) gfc_replace_expr (expr, gfc_copy_expr (sym-expr)); + /* Replace base type for polymorphic arguments. */ + if (expr-ref expr-ref-type == REF_COMPONENT sym-expr) + expr-ref-u.c.sym = sym-expr-ts.u.derived; } /* ...and to subexpressions in expr-value. */
[Bug c++/48075] New: [trans-mem] infinite loop when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48075 Summary: [trans-mem] infinite loop when compiling Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23632 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23632 infinite calls testcase. An infinite loop happens with the attached testcase. Maybe not related to trans-mem specifically... Here the backtrace: #10225 0x0050b680 in instantiate_class_template (type=0x76b20e70) at ../../transactional-memory/gcc/cp/pt.c:7965 #10226 0x005740b7 in complete_type (type=0x76b20e70) at ../../transactional-memory/gcc/cp/typeck.c:130 #10227 0x004de334 in tsubst_decl (t=0x76bd31e0, args=0x76b1f090, complain=3) at ../../transactional-memory/gcc/cp/pt.c:9533 #10228 0x004e96d0 in tsubst (t=0x76bd31e0, args=0x76b1f090, complain=3, in_decl=0x0) at ../../transactional-memory/gcc/cp/pt.c:9912 #10229 0x0050b680 in instantiate_class_template (type=0x76b200a8) at ../../transactional-memory/gcc/cp/pt.c:7965 #10230 0x005740b7 in complete_type (type=0x76b200a8) at ../../transactional-memory/gcc/cp/typeck.c:130 #10231 0x004de334 in tsubst_decl (t=0x76bd31e0, args=0x76b1c4b0, complain=3) at ../../transactional-memory/gcc/cp/pt.c:9533 #10232 0x004e96d0 in tsubst (t=0x76bd31e0, args=0x76b1c4b0, complain=3, in_decl=0x0) at ../../transactional-memory/gcc/cp/pt.c:9912 #10233 0x0050b680 in instantiate_class_template (type=0x76b1b2a0) at ../../transactional-memory/gcc/cp/pt.c:7965 #10234 0x005740b7 in complete_type (type=0x76b1b2a0) at ../../transactional-memory/gcc/cp/typeck.c:130 #10235 0x004de334 in tsubst_decl (t=0x76bd31e0, args=0x76b198d0, complain=3) at ../../transactional-memory/gcc/cp/pt.c:9533 #10236 0x004e96d0 in tsubst (t=0x76bd31e0, args=0x76b198d0, complain=3, in_decl=0x0) at ../../transactional-memory/gcc/cp/pt.c:9912 ... Patrick Marlier.
[Bug c++/48035] [4.4/4.5/4.6 Regression] Mismatch on size of class when initializing hierarchy involving virtual inheritance and empty base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48035 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 15:43:42 UTC --- Author: jakub Date: Fri Mar 11 15:43:37 2011 New Revision: 170874 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170874 Log: PR c++/48035 * init.c (build_zero_init_1): Extracted from build_zero_init. Add FIELD_SIZE argument, if non-NULL and field bit_position as not smaller than that, don't add that field's initializer. Pass DECL_SIZE as last argument to build_zero_init_1 for DECL_FIELD_IS_BASE fields. (build_zero_init): Use build_zero_init_1. * g++.dg/inherit/virtual8.C: New test. Added: trunk/gcc/testsuite/g++.dg/inherit/virtual8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #78 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-11 15:44:59 UTC --- --- Comment #77 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-08 11:19:03 UTC --- Great Rainer. As soon as 4.6.0 branches I guess we should ask Marc to present on the libstdc++ mailing list a concise summary of the various options, I encourage you to follow this discussion, in the light of which we'll be able to make a decision. In general, I think we should try to be minimally invasive for Please put me on the Cc: when it starts: I'm not subscribed to libstdc++. non-Solaris, where everything works pretty well already, thus the fixincludes solution looks indeed very attractive. But at the outset I'm also open to more invasive changes, in particular if they can be shown to offer further advantages in terms of clarity or ability to solve other problems, for 4.7.0 we can afford that. I've started to analyse the failures caused by having a proper __cplusplus value, but there seem to be several headers and solutions involved. This isn't a problem per se, especially if they also apply to Solaris 8 and up, which might be the case with only small variations to the fixes. Once I have an idea what it takes to make the Solaris headers work with __cplusplus 199711L, I'll also engage the Solaris engineers to try and get this stuff (and other fixincludes changes, while we're at it) integrated. Rainer
[Bug c++/47808] [4.6 Regression][C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47808 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 15:45:58 UTC --- (In reply to comment #11) I think it isn't the ?: arms here, but the condition on which convert_like_real is called. Same principle applies. fold_nondependent_expr on the COND_EXPR called from compute_array_index_type results in tsubst_copy_and_build on the CALL_EXPR to abs overload, which then eventually calls convert_like_real. The problem comes when we try to tsubst_copy_and_build the result of the convert_like_real called at template definition time. build_aggr_init_expr isn't called at all here BTW, I just don't see too many similarities with PR46003. My point in discussing 46003 has been that the problem is build_conditional_expr calling convert_like_real; build_aggr_init_expr isn't the key.
[Bug c++/48035] [4.4/4.5 Regression] Mismatch on size of class when initializing hierarchy involving virtual inheritance and empty base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48035 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 Summary|[4.4/4.5/4.6 Regression]|[4.4/4.5 Regression] |Mismatch on size of class |Mismatch on size of class |when initializing hierarchy |when initializing hierarchy |involving virtual |involving virtual |inheritance and empty base |inheritance and empty base |classes |classes Known to fail|4.6.0 | --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 15:45:04 UTC --- Fixed on the trunk so far.
[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 --- Comment #9 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com 2011-03-11 15:51:31 UTC --- Janus, That looks like the right way to go. Do you understand how this can be a regression, whilst the correct interface mapping was previously not present :-) ? Cheers Paul On Fri, Mar 11, 2011 at 4:39 PM, janus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 janus at gcc dot gnu.org changed: What |Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #8 from janus at gcc dot gnu.org 2011-03-11 15:39:20 UTC --- (In reply to comment #7) So, it wants to get at the a_type.length member, but applies the whole thing to a b_type'd variable. Yes, the base type in the reference is wrong. And the reason for this seems to be that it is not corrected in the interface mapping. I think we need to extend 'gfc_apply_interface_mapping_to_ref' to set the correct base type for polymorphic arguments. The following seems to do the trick (not regtested yet): Index: trans-expr.c === --- trans-expr.c (revision 170870) +++ trans-expr.c (working copy) @@ -2247,6 +2247,9 @@ gfc_apply_interface_mapping_to_expr (gfc_interface expr-symtree = sym-new_sym; else if (sym-expr) gfc_replace_expr (expr, gfc_copy_expr (sym-expr)); + /* Replace base type for polymorphic arguments. */ + if (expr-ref expr-ref-type == REF_COMPONENT sym-expr) + expr-ref-u.c.sym = sym-expr-ts.u.derived; } /* ...and to subexpressions in expr-value. */ -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 --- Comment #10 from janus at gcc dot gnu.org 2011-03-11 15:57:47 UTC --- (In reply to comment #9) That looks like the right way to go. Do you understand how this can be a regression, whilst the correct interface mapping was previously not present :-) ? Well, I think gfortran 4.5 just silently produced wrong code, and then Michael's patch triggered the ICE (uncovering a bug that had been there before). The dump with my patch shows D.1574 = D.1572-_data-a_type.length; while 4.5 gives: D.1565 = D.1563-$data-length; (missing the a_type parent reference).
[Bug c++/47808] [4.6 Regression][C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47808 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #14 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 15:59:18 UTC --- OK, I see what Jakub means now. build_conditional_expr isn't actually the problem in this testcase.
[Bug c++/48073] ICE with -flto in templated C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48073 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 15:59:47 UTC --- Author: rguenth Date: Fri Mar 11 15:59:42 2011 New Revision: 170875 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170875 Log: 2011-03-11 Richard Guenther rguent...@suse.de PR lto/48073 * tree.c (find_decls_types_r): Do not walk types only reachable from IDENTIFIER_NODEs. * g++.dg/lto/20110311-1_0.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/20110311-1_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug c++/48073] ICE with -flto in templated C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48073 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 16:00:07 UTC --- Fixed.
[Bug middle-end/48076] New: Unsafe double checked locking in __emutls_get_address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076
Summary: Unsafe double checked locking in __emutls_get_address
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eugeni.stepa...@gmail.com
The following piece of code around emutls.c:138 uses double checked locking to
initialize a tls offset to the next available value.
pointer offset = obj-loc.offset;
if (__builtin_expect (offset == 0, 0))
{
static __gthread_once_t once = __GTHREAD_ONCE_INIT;
__gthread_once (once, emutls_init);
__gthread_mutex_lock (emutls_mutex);
offset = obj-loc.offset;
if (offset == 0)
{
offset = ++emutls_size;
obj-loc.offset = offset;
}
__gthread_mutex_unlock (emutls_mutex);
}
struct __emutls_array *arr = __gthread_getspecific (emutls_key);
This code needs more barriers to be correct. For example, it is entirely
possible for emutls_key value used in the last line of the code snippet to be
prefetched before obj-loc.offset is loaded, and, consequently, before
emutls_init is called. In short, there needs to be a happens-before
relationship between obj-loc.offset assignment and the unprotected read at the
first line.
This looks unlikely on x86, but it may be a much bigger deal on ARM.
This was detected with ThreadSanitizer
(http://code.google.com/p/data-race-test/wiki/ThreadSanitizer) on an Android
device.
==822== WARNING: Possible data race during read of size 4 at 0x44B74: {{{
==822==T14 (L{}):
==822== #0 0xB7E0: __emutls_get_address gcc/emutls.c:138
==822== #1 0x1BFD5: NegativeTests_PerThreadTest::RealWorker()
unittest/racecheck_unittest.cc:5665
==822== #2 0x80107324: ThreadSanitizerStartThread
tsan/ts_valgrind_intercepts.c:679
==822== Concurrent write(s) happened at (OR AFTER) these points:
==822==T12 (L{L312}):
==822== #0 0xB80C: __emutls_get_address gcc/emutls.c:145
==822== #1 0x1BFD5: NegativeTests_PerThreadTest::RealWorker()
unittest/racecheck_unittest.cc:5665
==822== #2 0x80107324: ThreadSanitizerStartThread
tsan/ts_valgrind_intercepts.c:679
==822== Address 0x44B74 is 8 bytes inside data symbol
__emutls_v._ZN27NegativeTests_PerThreadTestL17per_thread_globalE
==822== Locks involved in this report (reporting last lock sites): {L312}
==822==L312 (0x44C18)
==822== #0 0x80108084: pthread_mutex_lock
tsan/ts_valgrind_intercepts.c:934
==822== #1 0xB808: __emutls_get_address gcc/gthr-posix.h:768
==822== #2 0x1BFD5: NegativeTests_PerThreadTest::RealWorker()
unittest/racecheck_unittest.cc:5665
==822== #3 0x80107324: ThreadSanitizerStartThread
tsan/ts_valgrind_intercepts.c:679
==822==Race verifier data: 0xB7E0,0xB80C
==822== }}}
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #79 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-11 16:09:23 UTC --- (In reply to comment #70) - needs to remove the overloads on linkage (like bsearch, qsort) in the solaris headers because g++ is broken there. So it's linked to from here, this is PR 2316
[Bug middle-end/48076] Unsafe double checked locking in __emutls_get_address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-03-11 16:33:49 UTC --- This looks unlikely on x86, but it may be a much bigger deal on ARM. This code should not be used on GNU/Linux on most targets anyways. ARM Linux supports TLS natively. I am not saying this is not a bug but I think you should figure out why native TLS is not be used for arm for your code.
[Bug tree-optimization/48067] [4.6 Regression] FMA with no add operand produced by convert_mul_to_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48067 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 16:36:35 UTC --- Fixed.
[Bug tree-optimization/48067] [4.6 Regression] FMA with no add operand produced by convert_mul_to_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48067 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-11 16:36:22 UTC --- Author: rguenth Date: Fri Mar 11 16:36:16 2011 New Revision: 170877 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170877 Log: 2011-03-11 Richard Guenther rguent...@suse.de PR tree-optimization/48067 * tree-ssa-math-opts.c (convert_mult_to_fma): Verify the multiplication result will be only used once on the target stmt. * gcc.dg/pr48067.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr48067.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug rtl-optimization/48077] New: [Code Improvement] Use multiplication by magic number for integer division by constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48077
Summary: [Code Improvement] Use multiplication by magic number
for integer division by constant
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wschm...@gcc.gnu.org
CC: berg...@gcc.gnu.org, pthau...@gcc.gnu.org,
meiss...@gcc.gnu.org, dje@gmail.com,
wschm...@gcc.gnu.org
Target: powerpc64-linux, others
We noticed a significant performance difference between gcc and xlc at all
optimization levels for a small application that repeatedly takes a value
modulo an integer constant. Gcc expands division by a constant into a sequence
of shifts, adds, and subtracts. Xlc converts division by a constant into
multiplication by a corresponding magic number. See H.S. Warren's _Hacker's
Delight_ for details. See http://www.hackersdelight.org/magic.htm for a magic
number calculator.
A small test case shows the difference:
-
int *values;
int *hash_table;
int demonstrate (int i)
{
return hash_table [values [i] % 1000];
}
-
On powerpc64-linux, xlc -c -S -O3 -q32 test.c produces:
demonstrate:
addis r4,r0,values@ha
rlwinm r3,r3,2,0,29
addis r6,r0,hash_table@ha
addis r5,r0,4194
addi r0,r5,19923
lwzr4,values@l(r4)
lwzr5,hash_table@l(r6)
lwzx r3,r4,r3
rlwinm r4,r3,1,31,31
mulhw r0,r3,r0
srawi r0,r0,6
addr6,r0,r4
rlwinm r0,r6,10,0,21
rlwinm r4,r6,5,0,26
subf r0,r4,r0
rlwinm r6,r6,3,0,28
addr4,r0,r6
subf r0,r4,r3
rlwinm r3,r0,2,0,29
lwzx r3,r5,r3
bclr BO_ALWAYS,CR0_LT
Note the multiply by 274877907, built by:
addis r5,r0,4194
addi r0,r5,19923
If you plug 1000 into the magic number calculator at the website above, that's
the magic number produced.
By contrast, gcc -c -S -O3 -m32 test.c produces:
.L.demonstrate:
addis 9,2,.LC0@toc@ha
ld 9,.LC0@toc@l(9)
sldi 3,3,2
addis 11,2,.LC1@toc@ha
ld 9,0(9)
ld 10,.LC1@toc@l(11)
lwzx 9,9,3
extsw 0,9
sldi 8,0,7
sldi 11,0,9
add 11,8,11
subf 11,0,11
sldi 11,11,3
add 11,11,0
sldi 8,11,2
add 11,11,8
sldi 11,11,2
add 11,11,0
sldi 11,11,3
add 11,11,0
sldi 8,11,3
subf 11,11,8
sldi 11,11,4
add 0,11,0
sldi 11,0,2
subf 0,0,11
srdi 0,0,32
srawi 11,9,31
srawi 0,0,6
subf 0,11,0
slwi 8,0,7
slwi 11,0,2
subf 11,11,8
add 0,11,0
ld 11,0(10)
slwi 0,0,3
subf 9,0,9
extsw 9,9
sldi 9,9,2
lwax 3,11,9
blr
Note the long string of dependencies in the gcc code; not only is the code
quite a bit larger, but there is very little ILP.
Consider converting integer division to multiplication by a magic number when
appropriate for the target machine.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-11 16:45:31 UTC --- That being said, I'd prefer to postpone this fix to stage 1 due to - I'm currently moving flats so my stuff is all over and I'm very busy - AFAIU 4.6 release is imminent? - I lack the ability to test all weird and wonderful targets. - This close to release I'd very much like to avoid regressions in primary or secondary targets. - As can be seen in the reopening of this PR, for less used targets there might anyway be a month latency between something landing in trunk and getting test reports. Not really: the delay was caused because the test system broke and it took me quite some time to get myself a replacement. Normally, I bootstrap everywhere once a week and analyse results. Thus, I'd suggest fixing this in stage 1, then, after getting reports that the fix works, backport hopefully in time for 4.6.1. Of course, the above is only my own justifications and constraints; if someone else wants to fix it ASAP, go right ahead. I'd really like to see this fixed before 4.6.0: it is a regression from 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively minor gain on other platforms. If all else fails, I'd go as far as advocating to revert the patch that introduced clock_gettime (and quite late in the release cycle, I might say). Sorry for being so late to reply: I've been totally swamped this week. Thanks. Rainer
[Bug c++/47808] [4.6 Regression][C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47808 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 16:49:46 UTC --- Author: jason Date: Fri Mar 11 16:49:41 2011 New Revision: 170878 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170878 Log: PR c++/47808 * decl.c (compute_array_index_type): Discard folding if it didn't produce a constant. Added: trunk/gcc/testsuite/g++.dg/cpp0x/regress/array1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47808] [4.6 Regression][C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47808 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Depends on|46003 | Resolution||FIXED --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 17:05:35 UTC --- Fixed, thanks.
[Bug target/48053] ICE in in build_int_cst_wide, when building cpu2000 galgel/equake/ammp/fma3d/sixtrack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48053 --- Comment #2 from Peter Bergner bergner at gcc dot gnu.org 2011-03-11 17:08:33 UTC --- Created attachment 23633 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23633 A related but different test case. Attached is another test case that tweaks a similar bug that Pat's test case exposes. In this case, it is not dependent on Mike's patch. The problem for both starts in rs6000_expand_vector_init(). In Pat's test case, we attempt to load the same constant into each V2DFmode half, with this test case, we attempt to load different values, one being a constant and the other a var which leads to a different ICE: pr48053-2.c: In function ‘foo’: pr48053-2.c:29:14: internal compiler error: in int_mode_for_mode, at stor-layout.c:490 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug rtl-optimization/48077] [Code Improvement] Use multiplication by magic number for integer division by constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48077 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-03-11 17:11:25 UTC --- Actually GCC is expanding the division by a constant into a multiplication but using shifts and adds to do the multiplication based on the cost.
[Bug c++/48029] [4.5 Regression] ICE in finish_member_declaration() with --param ggc-min-expand=0 --param ggc-min-heapsize=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48029 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 17:20:36 UTC --- Author: jason Date: Fri Mar 11 17:20:27 2011 New Revision: 170880 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170880 Log: PR c++/48029 * stor-layout.c (layout_type): Don't set structural equality on arrays of incomplete type. * tree.c (type_hash_eq): Handle comparing them properly. * cp/pt.c (iterative_hash_template_arg): Remove special case for ARRAY_TYPE. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/array22.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/pt.c branches/gcc-4_5-branch/gcc/stor-layout.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree.c
[Bug c++/48078] New: gcc accepts-invalid: taking address of private member function from template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078
Summary: gcc accepts-invalid: taking address of private member
function from template function
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: c...@google.com
test case (created by Bill Clarke):
class A {
public:
A() {}
private:
void APrivateMethod() { }
};
// Enable this to get a (correct) compiler error.
#if 0
void CallAPrivateMethod() {
void (A::*fn)() = A::APrivateMethod;
A a;
(a.*fn)();
}
#endif
template typename T
void CallAPrivateMethodTemplate() {
void (A::*fn)() = A::APrivateMethod;
A a;
(a.*fn)();
}
void CallAPrivateMethodViaTemplate() {
CallAPrivateMethodTemplateint();
}
compiles successfully (incorrectly AFAIU) with pre-4.6 (4.6.0 20110311)
(I tested some versions of GCC back to 4.2.x, same problem. They had local
mods, but none that should have caused a difference in this regard.)
FYI, clang C++ front-end flags an error as expected:
devtools/cpp_tests/x.cc:22:24: error: 'APrivateMethod' is a private member of
'A'
void (A::*fn)() = A::APrivateMethod;
^
devtools/cpp_tests/x.cc:8:7: note: declared private here
void APrivateMethod() { }
^
1 error generated.
[Bug c++/48078] gcc accepts-invalid: taking address of private member function from template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-11 17:38:17 UTC --- Access checking inside templates seems to be completely broken, see PR 47346 and the bugs I listed there, this could be a dup of one of them
[Bug c++/45383] [4.5 Regression] Implicit conversion to pointer does no longer automatically generate operator== and operator!=.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45383 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 17:44:15 UTC --- Is this still broken in 4.5?
[Bug c++/46564] [4.6 Regression] ICE: in decl_constant_var_p, at cp/decl2.c:3562 on invalid recursive initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46564 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||WORKSFORME --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 17:47:19 UTC --- This seems to have been fixed by a patch for another PR.
[Bug c++/47346] access control for nested type is ignored in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.11 18:04:41 Ever Confirmed|0 |1
[Bug c++/48078] gcc accepts-invalid: taking address of private member function from template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.11 18:07:13 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-11 18:07:13 UTC --- I think this is different enough from any of those others to count as a distinct bug - confirmed
[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 --- Comment #11 from janus at gcc dot gnu.org 2011-03-11 18:24:01 UTC --- The patch in comment #8 induced a regression in module_read_2.f90, which is fixed by the following update (we must only replace the base type, if the actual argument is polymorphic!): Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 170879) +++ gcc/fortran/trans-expr.c(working copy) @@ -2247,6 +2247,10 @@ gfc_apply_interface_mapping_to_expr (gfc_interface expr-symtree = sym-new_sym; else if (sym-expr) gfc_replace_expr (expr, gfc_copy_expr (sym-expr)); +/* Replace base type for polymorphic arguments. */ +if (expr-ref expr-ref-type == REF_COMPONENT + sym-expr sym-expr-ts.type == BT_CLASS) + expr-ref-u.c.sym = sym-expr-ts.u.derived; } /* ...and to subexpressions in expr-value. */ In this form the patch is free of testsuite regressions (on x86_64-unknown-linux-gnu). Ok for trunk?
[Bug rtl-optimization/48077] [Code Improvement] Use multiplication by magic number for integer division by constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48077 --- Comment #2 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-03-11 18:34:41 UTC --- OK, interesting, thanks for the information. It seems the analysis of the cost is not particularly good here. I'll dig into where the expansion is occurring.
[Bug tree-optimization/48067] [4.6 Regression] FMA with no add operand produced by convert_mul_to_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48067 --- Comment #6 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-03-11 18:46:27 UTC --- Author: wschmidt Date: Fri Mar 11 18:46:24 2011 New Revision: 170882 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170882 Log: Backport PR tree-optimization/48067 from mainline Added: branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr48067.c Modified: branches/ibm/gcc-4_5-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_5-branch/gcc/tree-ssa-math-opts.c
[Bug libfortran/48047] Incorrect output rounding of double precision numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-11 18:49:30 UTC --- Regression tested OK. Can I get a release manager OK for this? If not, it can wait for 4.7.
[Bug tree-optimization/48067] [4.6 Regression] FMA with no add operand produced by convert_mul_to_fma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48067 --- Comment #7 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-03-11 18:52:45 UTC --- I verified this on branches/ibm/gcc-4_5-branch, and it regtests successfully there as well. Thanks for the quick turnaround!
[Bug target/48053] ICE in in build_int_cst_wide, when building cpu2000 galgel/equake/ammp/fma3d/sixtrack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48053 --- Comment #3 from Peter Bergner bergner at gcc dot gnu.org 2011-03-11 19:06:17 UTC --- Author: bergner Date: Fri Mar 11 19:06:14 2011 New Revision: 170883 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170883 Log: gcc/ PR target/48053 * config/rs6000/predicates.md (easy_vector_constant_add_self, easy_vector_constant_msb): Do not handle V2DImode and V2DFmode. * config/rs6000/rs6000.c (const_vector_elt_as_int): Add assert that mode is not V2DImode or V2DFmode. (vspltis_constant): Do not handle V2DImode and V2DFmode. (rs6000_expand_vector_init): Replace copy_to_reg with copy_to_mode_reg. * config/rs6000/rs6000.md (movdi_internal32): Allow setting VSX registers to 0. (movdi_internal64): Likewise. gcc/testsuite/ PR target/48053 * gcc/testsuite/gcc.target/powerpc/pr48053-1.c: New test. * gcc/testsuite/gcc.target/powerpc/pr48053-2.c: Likewise. Added: branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/pr48053-1.c branches/ibm/gcc-4_5-branch/gcc/testsuite/gcc.target/powerpc/pr48053-2.c Modified: branches/ibm/gcc-4_5-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_5-branch/gcc/config/rs6000/predicates.md branches/ibm/gcc-4_5-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_5-branch/gcc/config/rs6000/rs6000.md branches/ibm/gcc-4_5-branch/gcc/testsuite/ChangeLog.ibm
[Bug libfortran/48047] Incorrect output rounding of double precision numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-11 19:12:36 UTC --- (In reply to comment #8) Regression tested OK. Can I get a release manager OK for this? If not, it can wait for 4.7. This is fine for 4.6.
[Bug target/48077] [Code Improvement] Poor expansion of multiply on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48077 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Target|powerpc64-linux, others |powerpc64-linux Component|rtl-optimization|target Summary|[Code Improvement] Use |[Code Improvement] Poor |multiplication by magic |expansion of multiply on |number for integer division |powerpc64-linux |by constant | --- Comment #3 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-03-11 19:22:06 UTC --- Changing this to a target issue. Confirmed that gcc is producing the correct magic number multiply, which survives till final assembly output, when the poor expansion takes place.
[Bug c++/46803] [4.6 Regression] libstdc++ build errors on invalid OpenBSD system header attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46803 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/44623] [4.6 Regression] ICE on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44623 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||WORKSFORME --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 19:51:41 UTC --- This seems to have gotten fixed.
[Bug c++/48078] gcc accepts-invalid: taking address of private member function from template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078 --- Comment #3 from Chris Demetriou cgd at google dot com 2011-03-11 19:59:40 UTC --- (In reply to comment #2) I think this is different enough from any of those others to count as a distinct bug - confirmed I hadn't seen them when i filed this (didn't match the searches that I did), but yeah, looking at them I agree. (BTW, re: the test case: Bill Clarke works for Google so it should be adequately assigned to the FSF already.) Thanks!
[Bug target/48077] [Code Improvement] Poor expansion of multiply on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48077 --- Comment #4 from Michael Meissner meissner at gcc dot gnu.org 2011-03-11 20:43:20 UTC --- It depends on what the default cpu is for the system. If you say -mcpu=power4, -mcpu=power5, or -mcpu=power7, it generates code similar to what XLC generates with mulhw to get the recrip. and a mulli: demonstrate: lis 9,values@ha slwi 3,3,2 lwz 11,values@l(9) lis 0,0x1062 ori 0,0,19923 lwzx 9,11,3 lis 11,hash_table@ha lwz 8,hash_table@l(11) mulhw 0,9,0 srawi 10,9,31 srawi 0,0,6 subf 0,10,0 mulli 0,0,1000 subf 9,0,9 slwi 9,9,2 lwzx 3,8,9 blr If you say -mcpu=power6 the mulli is replaced by shifts and adds, similar to what XLC generates. demonstrate: lis 11,values@ha slwi 3,3,2 lwz 9,values@l(11) lis 11,hash_table@ha add 9,9,3 lwz 8,hash_table@l(11) lwz 10,0(9) lis 9,0x1062 ori 9,9,19923 mulhw 9,10,9 srawi 0,10,31 srawi 9,9,6 subf 9,0,9 slwi 11,9,2 slwi 0,9,7 subf 0,11,0 add 0,0,9 slwi 0,0,3 subf 10,0,10 slwi 10,10,2 add 8,8,10 lwz 3,0(8) blr
[Bug c++/47125] [4.5/4.6 Regression] ICE occurs in combination with partial specialization and invalid template function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47125 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug target/47446] [x32] .quad instead of .long is used for address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47446
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-03-11 21:24:44
UTC ---
Another one:
/usr/gcc-4.6.0-x32/bin/gcc -S -o x.s -mx32 -funroll-all-loops -O3 -dp x.i
/usr/gcc-4.6.0-x32/bin/gcc -mx32 -funroll-all-loops -O3 -dp -c -o x.o x.s
x.s: Assembler messages:
x.s:25: Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
make: *** [x.o] Error 1
gnu-6:pts/3[86] bash ~/bugs/gcc/ilp32-30
[hjl@gnu-6 ilp32-30]$ cat x.i
extern char inbuf[];
extern char outbuf[];
extern unsigned insize;
extern unsigned inptr;
static int max_len;
static int peek_bits;
void build_tree() {
int len;
char *prefixp;
max_len = inbuf[inptr++];
peek_bits = ((max_len) = (12) ? (max_len) : (12));
prefixp = outbuf[1peek_bits];
for (len = 1;
len = peek_bits;
len++) {
}
while (prefixp outbuf) *--prefixp = 0;
}
[hjl@gnu-6 ilp32-30]$ make
/usr/gcc-4.6.0-x32/bin/gcc -mx32 -funroll-all-loops -O3 -dp -c -o x.o x.s
x.s: Assembler messages:
x.s:25: Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
make: *** [x.o] Error 1
[hjl@gnu-6 ilp32-30]$
[Bug tree-optimization/47944] Several graphite tests SEGV on Solaris 10/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47944 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Sebastian Pop spop at gcc dot gnu.org 2011-03-11 21:24:36 UTC --- Dup of PR47127. Thanks for the useful backtraces and comments in this PR. I have a patch to fix this. *** This bug has been marked as a duplicate of bug 47127 ***
[Bug middle-end/47127] gcc.dg/graphite/id-14.c ICEs with cloog-parma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47127 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #5 from Sebastian Pop spop at gcc dot gnu.org 2011-03-11 21:24:36 UTC --- *** Bug 47944 has been marked as a duplicate of this bug. ***
[Bug target/48077] [Code Improvement] Poor expansion of multiply on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48077 --- Comment #5 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-03-11 21:27:25 UTC --- BTW, I mis-entered the optimization level before. The code generation was at -O2 when the mulhw was expanded into shifts/adds with the default P6 tuning. At -O3 and up, the mulhw is intact. This is all explained by the default tuning model in place during testing, since Power6 had a poorer performing integer multiply than the other machine models.
[Bug fortran/47552] CTIME: Valgrind warning depends on uninitialised value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47552 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Keywords||patch CC||fxcoudert at gcc dot ||gnu.org --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2011-03-11 21:32:33 UTC --- (In reply to comment #2) This seems to be because the libgfortran implementation uses gfc_charlen_type for the length of the string, Which is the correct thing the do! but the frontend passes the address of an integer(8) variable Which is wrong. This is fixed by the patch: Index: trans-intrinsic.c === --- trans-intrinsic.c(revision 170612) +++ trans-intrinsic.c(working copy) @@ -1501,7 +1501,7 @@ args = XALLOCAVEC (tree, num_args); var = gfc_create_var (pchar_type_node, pstr); - len = gfc_create_var (gfc_get_int_type (8), len); + len = gfc_create_var (gfc_charlen_type_node, len); gfc_conv_intrinsic_function_args (se, expr, args[2], num_args - 2); args[0] = gfc_build_addr_expr (NULL_TREE, var); If not before, perhaps something to fix when/if we change to use size_t for string lengths, see http://gcc.gnu.org/wiki/LibgfortranAbiCleanup Just as a remark: you're not going to use size_t, but the signed ssize_t, right?
[Bug c++/46803] [4.6 Regression] libstdc++ build errors on invalid OpenBSD system header attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46803 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 21:36:04 UTC --- Author: jason Date: Fri Mar 11 21:36:02 2011 New Revision: 170885 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170885 Log: PR c++/46803 * c-common.c (attribute_takes_identifier_p): Assume that an unknown attribute takes an identifier. Added: trunk/gcc/testsuite/g++.dg/ext/attrib40.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug c++/46803] [4.6 Regression] libstdc++ build errors on invalid OpenBSD system header attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46803 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2011-03-11 21:37:04 UTC --- Fixed.
[Bug middle-end/47127] gcc.dg/graphite/id-14.c ICEs with cloog-parma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47127 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.11 21:41:26 AssignedTo|unassigned at gcc dot |spop at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #6 from Sebastian Pop spop at gcc dot gnu.org 2011-03-11 21:41:26 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00658.html
