[Bug c/44695] New: ice in simplify_subreg, at simplify-rtx.c:5117
reg...@john-home:~/volatile/bugs/tmp319$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r161425-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r161425-install
--program-prefix=r161425- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100626 (experimental) (GCC)
reg...@john-home:~/volatile/bugs/tmp319$ current-gcc -O2 small.c -c
small.c: In function int81:
small.c:20:1: internal compiler error: in simplify_subreg, at
simplify-rtx.c:5117
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
reg...@john-home:~/volatile/bugs/tmp319$ cat small.c
typedef int int32_t;
typedef unsigned char uint8_t;
static uint8_t
safe_div_func_uint8_t_u_u (uint8_t ui1, uint8_t ui2)
{
return ui2 ? : (ui1 / ui2);
}
int safe (int);
int func_51 (int);
void
int81 (void)
{
int32_t l_219 = 8L;
if (safe (safe_div_func_uint8_t_u_u (1 || 0, l_219 func_51 (0
{
}
}
--
Summary: ice in simplify_subreg, at simplify-rtx.c:5117
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
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=44695
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #17 from paul dot richard dot thomas at gmail dot com 2010-06-28 06:47 --- Subject: Re: gfortran generates wrong results due to wrong ABI in function with array return OK, I have regtested a submittable version this morning. I will do the business tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug middle-end/44671] [4.6 Regression] Partial inlining breaks C++
--- Comment #4 from hp at gcc dot gnu dot org 2010-06-28 07:45 --- (In reply to comment #2) On Linux/ia32, I also see: FAIL: 23_containers/unordered_map/erase/1.cc execution test FAIL: 23_containers/unordered_map/erase/24061-map.cc execution test FAIL: 23_containers/unordered_map/insert/array_syntax.cc execution test FAIL: 23_containers/unordered_map/insert/map_range.cc execution test (etc) Revision 161428 doesn't fix them. I see those too, for cris-elf; assert failures (49 of them; regress-5 - regress-54). They are *not* gone as of r161481. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
[Bug tree-optimization/44688] [4.6 Regression] Excessive code-size growth at -O3
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-06-28 07:46 --- It really seems that both patches (prefetching and partial inlining) are responsible for some of the regressions. I've now comited the patch to reduce autoinlining from 50 to 40. It solves size issues at least with -O3 non-FDO/LTO SPECint2000 build. Unfortunately the tester also shows some regressions that might turn out to be offnoise. Lets see how the other benchmarks go. I've also switched FDO tester to native testing and plan to enable prefetching with FDO and -O2 once this change is tested. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688
Re: [Bug middle-end/44671] [4.6 Regression] Partial inlining breaks C++
I see those too, for cris-elf; assert failures (49 of them; regress-5 - regress-54). They are *not* gone as of r161481. In that case I guess I really need some way to reproduce them. If this is glibc version specific, can I possibly have preprocessed file for one of the testcases at x86? Thanks a lot! Honza
[Bug middle-end/44671] [4.6 Regression] Partial inlining breaks C++
--- Comment #5 from hubicka at ucw dot cz 2010-06-28 08:27 --- Subject: Re: [4.6 Regression] Partial inlining breaks C++ I see those too, for cris-elf; assert failures (49 of them; regress-5 - regress-54). They are *not* gone as of r161481. In that case I guess I really need some way to reproduce them. If this is glibc version specific, can I possibly have preprocessed file for one of the testcases at x86? Thanks a lot! Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
[Bug tree-optimization/44635] [4.6 Regression] ICE with tree tailcall and ipa-cp
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-28 08:30 --- Yes. I notified honza about that problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44635
[Bug fortran/44662] unitialized memory on testcases abstract_type_6.f03 and typebound_call_4.f03
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-28 08:48 --- This is likely the cause of recent failures for gfortran on ppc, see http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg02876.html http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg02871.html The patch in comment #2 fixes the regression for gfortran.dg/typebound_call_4.f03 on powerpc-apple-darwin9 without new failure. Is not the patch qualifying for obvious? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44662
[Bug c++/44682] [4.6 Regression] warning: variable �x� set but not used
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-28 08:54 --- Created an attachment (id=21021) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21021action=view) gcc46-pr44682.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44682
[Bug rtl-optimization/44691] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'plus' in rhs_regno, at rtl.h:1050
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44691
[Bug libfortran/43298] fortran library does not read in NaN -Inf or Inf
--- Comment #8 from burnus at gcc dot gnu dot org 2010-06-28 09:09 --- Created an attachment (id=21022) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21022action=view) Draft patch for reading NaN(alphanum) in list-directed I/O While INF/NAN were already supported in list-directed I/O (cf. PR fortran/34319 and PR 34427), NAN(alpanum) was not. Attached is a draft patch to handle it. That's a separate but related issue to the patch in comment 7 which is about format-based I/O. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43298
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-28 09:13 --- Confirmed. At -O2 -g we get for 4.4.x variable tracking : 0.26 ( 1%) usr 0.00 ( 0%) sys 0.24 ( 1%) wall 1870 kB ( 1%) ggc TOTAL : 26.74 1.1929.62 282737 kB while for the current 4.5 branch we have variable tracking : 392.60 (96%) usr 2.69 (73%) sys 397.72 (96%) wall 30099 kB (11%) ggc TOTAL : 409.66 3.69 415.97 279266 kB -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||compile-time-hog Last reconfirmed|-00-00 00:00:00 |2010-06-28 09:13:08 date|| Summary|[4.4 4.5 regression] Long |[4.5/4.6 Regression] Long |var tracking compile time of|var tracking compile time of |GiNaC tests |GiNaC tests Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-28 09:13 --- Created an attachment (id=21023) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21023action=view) unincluded testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug tree-optimization/44686] [4.5 Regression] ICE: in gimple_op, at gimple.h:1664 with -fipa-pta -fprofile-generate
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-28 09:14 --- Fixed on trunk sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.6.0 Summary|[4.5/4.6 Regression] ICE: in|[4.5 Regression] ICE: in |gimple_op, at gimple.h:1664 |gimple_op, at gimple.h:1664 |with -fipa-pta -fprofile- |with -fipa-pta -fprofile- |generate|generate http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44686
[Bug rtl-optimization/44695] [4.6 Regression] ice in simplify_subreg, at simplify-rtx.c:5117
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-28 09:17 --- Confirmed. A recent regression. #2 0x009ad621 in simplify_subreg (outermode=HImode, op=0x77facd40, innermode=QImode, byte=0) at /space/rguenther/src/svn/trunk/gcc/simplify-rtx.c:5116 5116 gcc_assert (GET_MODE (op) == innermode 5117 || GET_MODE (op) == VOIDmode); (gdb) call debug_rtx (op) (reg:HI 68) during combine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |rtl-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-28 09:17:18 date|| Summary|ice in simplify_subreg, at |[4.6 Regression] ice in |simplify-rtx.c:5117 |simplify_subreg, at ||simplify-rtx.c:5117 Target Milestone|--- |4.6.0 Version|unknown |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44695
[Bug fortran/43829] Scalarization of reductions
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-06-28 09:35 --- (In reply to comment #21) With the patch in comment #19, the test suite pass with -m32 and -m64, but for gfortran.dg/transpose_2.f90 which needs an adjustment of the dg-error. AFAICT the SUM of the different tests are scalarized (it would be interesting to have some timings before and after the patch for 465.tonto). Estimated Estimated Base Base BasePeak Peak Peak Benchmarks Ref. Run Time Ratio Ref. Run Time Ratio -- -- - --- - - 465.tonto9840390 25.2 S9840361 27.3 S 465.tonto9840391 25.2 S9840361 27.3 * 465.tonto9840390 25.2 *9840362 27.2 S == 465.tonto9840390 25.2 *9840361 27.3 * base is trunk r161367, peak is trunk r161367 + the patch from comment #19. Flags are -O3 -ffast-math -funroll-loops -march=core2, executed on an iCore7 @ 3.3GHz. Thus your patch improves performance by 7.5% which is very nice and even above what I expected (compared to manual source manipulation of the hottest SUM). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug c++/33990] bug in lookup of member template conversion operator for pointer to member functions
--- Comment #6 from pluto at agmk dot net 2010-06-28 09:47 --- (In reply to comment #5) N.B. nullptr is a keyword in c++0x, and proper nullptr support has been added to 4.6 anyway, but those covnersions should still work gcc = 4.4 rejects only operator!=(pmf,nullptr): $ g++44 t.cpp -Wall -c -std=c++0x t.cpp: In function 'int main()': t.cpp:21: error: no match for 'operator!=' in 'pmf != nullptr' gcc = 4.5 rejects also operator!=(p,nullptr): $ g++45 t.cpp -Wall -c -std=c++0x t.cpp: In function 'int main()': t.cpp:21:19: error: no match for 'operator!=' in 'p != nullptr' t.cpp:21:41: error: no match for 'operator!=' in 'pmf != nullptr' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33990
[Bug c++/4131] The C++ compiler don't place a const class object to .rodata section with non trivial constructor
--- Comment #24 from jakub at gcc dot gnu dot org 2010-06-28 11:05 ---
On:
extern C void abort ();
struct S
{
int x;
int y;
};
struct T
{
int x;
int y;
T (int u, int v) : x (u), y (v) {}
};
extern const S s;
extern const T t, u;
int sx = s.x;
int tx = t.x;
const S s = { 1, 2 };
const T t (1, 2);
const T u (1, 2);
int ux = u.x;
int
main ()
{
if (sx != 1 || tx != 0 || ux != 1)
abort ();
if (s.x != 1 || s.y != 2)
abort ();
if (t.x != 1 || t.y != 2)
abort ();
if (u.x != 1 || u.y != 2)
abort ();
return 0;
}
it is easy to spot whether this optimization would be possible or not by
looking at TREE_USED of the decl at check_initializer time. It is set for t
(and s), but cleared for u.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug tree-optimization/44357] [4.6 Regression] internal compiler error: in cgraph_decide_inlining_of_small_functions
--- Comment #5 from baldrick at gcc dot gnu dot org 2010-06-28 11:13 --- I'm hitting the same thing when building LLVM. It needs -fPIC and -O3 to fire on my x86-64 linux box: $ g++-4.6 -fPIC -O3 DwarfException.ii DwarfException.ii:56:89: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1047 I reduced a 56 line test case using delta (will attach in a moment). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44357
[Bug tree-optimization/44357] [4.6 Regression] internal compiler error: in cgraph_decide_inlining_of_small_functions
--- Comment #6 from baldrick at gcc dot gnu dot org 2010-06-28 11:14 --- Created an attachment (id=21024) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21024action=view) Reduced testcase -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Attachment #20788|0 |1 is obsolete|| Attachment #20789|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44357
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #49 from gcc at breakpoint dot cc 2010-06-28 11:18 --- Modified: trunk/gcc/ChangeLog trunk/gcc/caller-save.c trunk/gcc/config/rs6000/e500.h Is it possible to get this into the 4.4 and 4.5 branch as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug c++/4131] The C++ compiler don't place a const class object to .rodata section with non trivial constructor
--- Comment #25 from jakub at gcc dot gnu dot org 2010-06-28 11:22 --- I guess best would be to wait for the constexpr work, then use that as an infrastructure to discover ctors that aren't marked as constexpr, but they could be and use that at bit together with !TREE_USED during check_initializer to do this optimization. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug tree-optimization/43781] [4.6 Regression] ice: verify_ssa failed
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-28 11:53 --- I can no longer reproduce this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43781
[Bug c++/44650] internal compiler error: in ei_container, at basic-block.h:687
--- Comment #4 from morandini at aero dot polimi dot it 2010-06-28 11:58 --- Created an attachment (id=21025) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21025action=view) Reduced testcase -- morandini at aero dot polimi dot it changed: What|Removed |Added Attachment #20988|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44650
[Bug tree-optimization/44357] [4.6 Regression] internal compiler error: in cgraph_decide_inlining_of_small_functions
--- Comment #7 from hubicka at gcc dot gnu dot org 2010-06-28 12:58 --- Mine. THanks a lot for testcase! -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-28 12:58:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44357
[Bug c++/44039] [4.5/4.6 regression] ICE: Segmentation fault on error recovery
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-28 13:08
---
I'm still working on this, but this kind of situation is certainly part of the
problem, if not all of it, it ICES.
Jason, does it look familiar to you? I'm asking because I think you implemented
the recent changes to reject locale::locale() below...
struct locale { };
templateclass charT
void
foo()
{ locale::locale(); }
void
bar()
{ foochar(); }
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||paolo dot carlini at oracle
||dot com, jason at gcc dot
||gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44039
[Bug fortran/44696] New: Associated() doesn't work in subroutine
program rte1 implicit none type::node_type class(node_type),pointer::parent,child integer::id end type node_type type(node_type),target::root allocate(root%child) root%child%parent=root root%id=1 root%child%id=2 print *,root%child%id, is child of ,root%id,: print *,root%child%parent%id,root%id,associated(root%child%parent,root) call check(root%child,root) contains subroutine check(this,that) class(node_type),intent(in),target :: this class(node_type),intent(in),target :: that print *,this%id, is child of ,that%id,: print *,this%parent%id,that%id,associated(this%parent,that) end subroutine check end program rte1 -- This is two times the same code: inside the program and as subroutine. The result (GNU Fortran (GCC) 4.6.0 20100627) is different: 2 is child of1 : 1 1 T 2 is child of1 : 1 1 F -- Summary: Associated() doesn't work in subroutine Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: boschmann at tp1 dot physik dot uni-siegen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44696
[Bug fortran/44696] Associated() doesn't work in subroutine
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-28 14:42 --- Confirmed. For the record: Works with the NAG, Intel, and Cray compiler. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-06-28 14:42:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44696
[Bug middle-end/44671] [4.6 Regression] Partial inlining breaks C++
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-28 14:43 --- (In reply to comment #5) Subject: Re: [4.6 Regression] Partial inlining breaks C++ I see those too, for cris-elf; assert failures (49 of them; regress-5 - regress-54). They are *not* gone as of r161481. In that case I guess I really need some way to reproduce them. If this is glibc version specific, can I possibly have preprocessed file for one of the testcases at x86? I don't know if it is glibc specific. I saw them with glibc 2.5, 2.11 and 2.12. Which test do you prefer for preprocessed file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
[Bug rtl-optimization/44691] [4.6 Regression] ICE: RTL check: expected code 'reg', have 'plus' in rhs_regno, at rtl.h:1050
--- Comment #1 from abel at gcc dot gnu dot org 2010-06-28 15:07 --- Confirmed. This is because we see an insn (set (reg:SI 1 dx [237]) (subreg:SI (plus:DI (reg:DI 2 cx [orig:135 imaj ] [135]) (const_int -1 [0x])) 0)) generated by the recently added split for lea. I thought the scheduler would see only a reg as the first operand of a subreg, thus we hit an ICE when we assume that SUBREG_REG is actually a REG. This however seems to be legal as several backends use fancy subreg expressions. I will recheck and then will fix this. -- abel at gcc dot gnu dot org changed: What|Removed |Added CC|abel at ispras dot ru |abel at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |abel at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-28 15:07:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44691
[Bug tree-optimization/44357] [4.6 Regression] internal compiler error: in cgraph_decide_inlining_of_small_functions
--- Comment #8 from hubicka at gcc dot gnu dot org 2010-06-28 15:12 --- Subject: Bug 44357 Author: hubicka Date: Mon Jun 28 15:12:11 2010 New Revision: 161495 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161495 Log: PR tree-optimization/44357 * ipa-inline.c (add_new_edges_to_heap): Do not add edges to uninlinable functions. PR tree-optimization/44357 * g++.dg/torture/pr44357.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr44357.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44357
[Bug middle-end/44592] [4.5/4.6 Regression] wrong code at -O3
--- Comment #5 from matz at gcc dot gnu dot org 2010-06-28 15:14 --- Subject: Bug 44592 Author: matz Date: Mon Jun 28 15:14:31 2010 New Revision: 161496 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161496 Log: PR middle-end/44592 * gimple-fold.c (gimplify_and_update_call_from_tree): Maintain proper VDEF chain for intermediate stores in the sequence. testsuite/ PR middle-end/44592 * gfortran.dg/pr44592.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr44592.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592
[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.
--- Comment #14 from edmar at freescale dot com 2010-06-28 15:15 --- I am attaching new patches. One for gcc-4.4 and the other for gcc-4.5 and gcc-4.6. All three branches were bootstrapped and regression tested for both 32 bits powerpc (603e) and 64 bit powerpc (970) with no regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
[Bug middle-end/44592] [4.5 Regression] wrong code at -O3
--- Comment #6 from matz at gcc dot gnu dot org 2010-06-28 15:16 --- Fixed for 4.6, waiting a bit for 4.5. -- matz at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5/4.6 Regression] wrong |[4.5 Regression] wrong code |code at -O3 |at -O3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592
[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.
--- Comment #15 from edmar at freescale dot com 2010-06-28 15:17 --- Created an attachment (id=21026) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21026action=view) Alternative patch that affects powerpc only -- edmar at freescale dot com changed: What|Removed |Added Attachment #20968|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.
--- Comment #16 from edmar at freescale dot com 2010-06-28 15:18 --- Created an attachment (id=21027) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21027action=view) Alternative patch for 4.5 and trunk -- edmar at freescale dot com changed: What|Removed |Added Attachment #20967|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
[Bug target/44618] Arguments are not passed correctly to out-of-line restore functions.
--- Comment #17 from edmar at freescale dot com 2010-06-28 15:19 --- Created an attachment (id=21028) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21028action=view) Changelog for alternative patches -- edmar at freescale dot com changed: What|Removed |Added Attachment #20969|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
[Bug c++/44039] [4.5/4.6 regression] ICE: Segmentation fault on error recovery
--- Comment #7 from paolo dot carlini at oracle dot com 2010-06-28 15:20 --- I'm now pretty sure that the issue with locale::locale() is all there is to this PR. I also checked that the below patchlet avoids the ICE both for the original testcase and my snippet (it also passes the testsuite, but I'm not sure whether we could catch the problem earlier): Index: pt.c === --- pt.c(revision 161491) +++ pt.c(working copy) @@ -10695,6 +10695,8 @@ tsubst_baselink (tree baselink, tree object_type, if (IDENTIFIER_TYPENAME_P (name)) name = mangle_conv_op_name_for_type (optype); baselink = lookup_fnfields (qualifying_scope, name, /*protect=*/1); +if (!baselink) + return error_mark_node; /* If lookup found a single function, mark it as used at this point. (If it lookup found multiple functions the one selected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44039
[Bug middle-end/44671] [4.6 Regression] Partial inlining breaks C++
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-28 15:33 --- Created an attachment (id=21029) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21029action=view) 23_containers/unordered_map/insert/map_single.cc This is the 32bit preprocessed 23_containers/unordered_map/insert/map_single.cc with glibc 2.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
[Bug c++/44535] [4.6 Regression] g++ -O[ 23] generates undefined symbol
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-06-28 15:42 --- Subject: Bug 44535 Author: jamborm Date: Mon Jun 28 15:42:01 2010 New Revision: 161498 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161498 Log: 2010-06-28 Martin Jambor mjam...@suse.cz PR c++/44535 * gimple-fold.c (get_first_base_binfo_with_virtuals): New function. (gimple_get_relevant_ref_binfo): Use get_first_base_binfo_with_virtuals instead of BINFO_BASE_BINFO. * testsuite/g++.dg/torture/pr44535.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr44535.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44535
[Bug target/44072] Use 'add r0, 1' to replace 'cmp r0, -1' in thumb2
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44072
[Bug tree-optimization/44687] [4.6 Regression] ICE: in tree_nrv, at tree-nrv.c:155 with -fprofile-generate
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-06-28 15:51 --- Subject: Bug 44687 Author: hubicka Date: Mon Jun 28 15:51:25 2010 New Revision: 161500 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161500 Log: PR tree-optimization/44687 * gcc.c-torture/compile/pr44687.c PR tree-optimization/44687 * ipa-split.c (split_function): Use DECL_RESULT to store return value. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr44687.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44687
[Bug c++/44040] [4.5/4.6 Regression] ICE: cc1plus segmentation fault
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-28 16:00 --- It looks like PR44039 is the same issue, my patchlet there fixes this one too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44040
[Bug c++/44587] [4.4/4.5/4.6 Regression] ICE in instantiate_decl
-- 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|2010-06-24 21:45:08 |2010-06-28 16:00:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44587
[Bug libstdc++/44679] [4.5/4.6 regression] 30_threads/condition_variable_any/cons/1.cc fails with -fstack-protector (built with 4.4, run with 4.5)
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-28 16:03 --- (In reply to comment #2) condition_variable_any was completely broken in 4.4 and its ABi changed when we implemented it for real. Obviously we can't preserve ABI between a broken, incomplete implementation and a working one, so I'm not really worried about this bug. If anyone was able to use the condition_variable_any in 4.4 I'd like to know how they did it! We should avoid exporting symbols for something that is broken or supposed to change its ABI. I think this is what was done in the past, why wasn't it done here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44679
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-28 16:12 --- Seems the problem here is extremely long loc_chain lists (the longest one in insert_into_intersection has 3740 entries), so e.g. insert_into_intersection is extremely time consuming. Most of the locations in the long lists are of the form (plus:DI (value:DI ...) (const_int ...)) with different values and offsets. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug libstdc++/44679] [4.5/4.6 regression] 30_threads/condition_variable_any/cons/1.cc fails with -fstack-protector (built with 4.4, run with 4.5)
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-28 16:12 --- A (small) mistake? I think the hope at the time was that Chris Fairles would soon contribute the rest of the work and the complete facility shipped the next major release series. That didn't happen, unfortunately, and instead of reverting all the first changes, we shipped just very few unusable bits, among which a couple exported. Finally, 4.6 will be fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44679
[Bug libstdc++/44679] [4.5/4.6 regression] 30_threads/condition_variable_any/cons/1.cc fails with -fstack-protector (built with 4.4, run with 4.5)
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-28 16:14 --- Actually 4.5 is fine too ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44679
[Bug fortran/44697] New: I/O testsuite failures: \r\n vs \n - gfortran.dg/ftell_3.f90
As reported by Kai Tietz, the testsuite fails under MinGW64 due to the \r\n vs. \n line breaks: Possible patch for ftell_3.f90 (created for PR 43605): Index: ftell_3.f90 === --- ftell_3.f90 (revision 161500) +++ ftell_3.f90 (working copy) @@ -15,3 +15,4 @@ program ftell_3 call ftell(10, i) - if(i /= 7) then +! Expected: On '\n' systems: 7, on \r\n systems: 8 + if(i /= 7 .and. i /= 8) then call abort() @@ -23,3 +24,4 @@ program ftell_3 call ftell(10,i) - if (i /= 11) then +! Expected: On '\n' systems: 11, on \r\n systems: 13 + if (i /= 11 .and. i /= 13) then call abort() -- Summary: I/O testsuite failures: \r\n vs \n - gfortran.dg/ftell_3.f90 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44697
[Bug c++/44535] [4.6 Regression] g++ -O[ 23] generates undefined symbol
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-06-28 17:00 --- Fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44535
[Bug fortran/44698] New: I/O: FLUSH does not actually flush the buffer?
Kai Tietz reported that inquire_size.f90 fails on MinGW as inquire(...
size=size) returns 0 instead of 3000.
Question 1: Why does gfortran always use stat. Wouldn't it be better to use
for open files:
save = ftell(s)
seek(s, 0, SEEK_END)
size = ftell(s)
seek (s, save, SEEK_SET
Question 2: I fail to see how FLUSH actually works. It seems to work most of
the time, but I probably miss something. I somehow had expected to see a call
to fflush - but I only see this for STDIN/STDOUT/STDERR. For the others, I
find:
raw_flush == return 0;
buf_flush: Some action, including lseek and raw_write (= unistd.h's write)
The function is called via sflush. And the FLUSH statement is file_pos.c's
st_flush:
library_start (fpp-common);
u = find_unit (fpp-common.unit);
if (u != NULL)
{
if (u-flags.form == FORM_FORMATTED)
fbuf_flush (u, u-mode);
sflush (u-s);
unlock_unit (u);
} [...]
library_end ();
Thus: I fail to see any fflush call for non-std(out/err/in) units. Did I miss
something?
--
Summary: I/O: FLUSH does not actually flush the buffer?
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44698
[Bug bootstrap/44699] New: [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
At revision 161501, bootstrapping fails at stage 2 on x86_64-apple-darwin10 with: ... /opt/gcc/build_w/./prev-gcc/xgcc -B/opt/gcc/build_w/./prev-gcc/ -B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/ -B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/ -B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/lib/ -isystem /opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/include -isystem /opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/sys-include-c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../work/gcc -I../../work/gcc/build -I../../work/gcc/../include -I../../work/gcc/../libcpp/include -I/opt/sw64/include -I../../work/gcc/../libdecnumber -I../../work/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/sw64/include -DCLOOG_PPL_BACKEND -I/opt/sw64/include \ -o build/genmodes.o ../../work/gcc/genmodes.c ../../work/gcc/genmodes.c: In function 'new_mode': ../../work/gcc/genmodes.c:153:1: internal compiler error: Segmentation fault The backtrace of run -O2 genmodes.i is Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0141e4413800 0x000100387be1 in bitmap_clear () (gdb) bt #0 0x000100387be1 in bitmap_clear () #1 0x000100387f43 in bitmap_obstack_free () #2 0x000100b3bcfa in vrp_finalize () #3 0x000100b3be34 in execute_vrp () #4 0x0001007e1dba in execute_one_pass () #5 0x0001007e21ab in execute_pass_list () #6 0x0001007e21c9 in execute_pass_list () #7 0x000100995e9f in tree_rest_of_compilation () #8 0x000100c2aa3e in cgraph_expand_function () #9 0x000100c2acd5 in cgraph_expand_all_functions () #10 0x000100c2b3a7 in cgraph_optimize () #11 0x000100c28a31 in cgraph_finalize_compilation_unit () #12 0x00010002e330 in c_write_global_declarations () #13 0x0001008fb619 in compile_file () #14 0x0001008fe0c5 in do_compile () #15 0x0001008fe18f in toplev_main () #16 0x00010010c7e8 in main () -- Summary: [4.6 Regression] Bootstrap failure for x86_64-apple- darwin10: ICE while compiling genmodes.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug fortran/40158] Misleading error message for passing a scalar to an array
--- Comment #4 from pault at gcc dot gnu dot org 2010-06-28 17:16 --- Subject: Bug 40158 Author: pault Date: Mon Jun 28 17:16:06 2010 New Revision: 161504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161504 Log: 2010-06-28 Paul Thomas pa...@gcc.gnu.org PR fortran/40158 * interface.c (argument_rank_mismatch): New function. (compare_parameter): Call new function instead of generating the error directly. 2010-06-28 Paul Thomas pa...@gcc.gnu.org PR fortran/40158 * gfortran.dg/actual_rank_check_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/actual_rank_check_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40158
[Bug fortran/44698] I/O: FLUSH does not actually flush the buffer?
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-28 17:16 --- For Windows (MinGW64), Kai reports that adding the following to buf_flush helps: @@ -404,6 +407,9 @@ s-ndirty -= writelen; if (s-ndirty != 0) return -1; +#ifdef _WIN32 + _commit (s-fd); +#endif return 0; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44698
[Bug c/44700] New: Internal error (case derived from netpbm)
I've experienced an internal compiler error attempting to compile
netpbm-10.35.75 under -Os optimization. I've reduced the problem file
(pamscale.c) down to a minimal example:
Script started on Mon Jun 28 10:15:13 2010
bash-4.1$ cat break-gcc.i
extern int bar(void);
int foo(float f, int i)
{
return f * 2 i || bar();
}
bash-4.1$ gcc -c -Os -ffast-math break-gcc.i
break-gcc.i: In function 'foo':
break-gcc.i:6:1: error: unrecognizable insn:
(jump_insn 39 41 12 2 break-gcc.i:5 (set (pc)
(if_then_else (lt (reg:CCFP 17 flags)
(const_int 0 [0x0]))
(label_ref:SI 18)
(pc))) -1 (expr_list:REG_BR_PROB (const_int 6102 [0x17d6])
(nil))
- 18)
break-gcc.i:6:1: internal compiler error: in extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
bash-4.1$ exit
exit
Script done on Mon Jun 28 10:15:35 2010
-Os and -ffast-math are both essential to trigger the bug.
--
Summary: Internal error (case derived from netpbm)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael at talamasca dot ocis dot net
GCC build triplet: i386-pc-linux-uclibc
GCC host triplet: i386-pc-linux-uclibc
GCC target triplet: i386-pc-linux-uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44700
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-28 17:21 --- Last successful bootstrap at revision 161470. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug tree-optimization/43781] [4.6 Regression] ice: verify_ssa failed
--- Comment #4 from hjl at gcc dot gnu dot org 2010-06-28 17:26 --- Subject: Bug 43781 Author: hjl Date: Mon Jun 28 17:25:49 2010 New Revision: 161505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161505 Log: Add a testcase for PR tree-optimization/43781. 2010-06-28 H.J. Lu hongjiu...@intel.com PR tree-optimization/43781 * gcc.dg/torture/pr43781.c: New. Added: trunk/gcc/testsuite/gcc.dg/torture/pr43781.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43781
[Bug fortran/44698] I/O: FLUSH does not actually flush the buffer?
--- Comment #2 from jb at gcc dot gnu dot org 2010-06-28 17:27 ---
(In reply to comment #0)
Question 1: Why does gfortran always use stat. Wouldn't it be better to use
for open files:
save = ftell(s)
seek(s, 0, SEEK_END)
size = ftell(s)
seek (s, save, SEEK_SET
Yes, this would work, and we actually already have an implementation for this
(see unix.c:file_length() ), and it might be better because one doesn't need to
flush the buffer which one does need to do in order to get correct size results
from stat(). That being said, I don't think inquiring for file size is such a
common operation that flushing the buffers when this happens is an issue to
worry about.
Question 2: I fail to see how FLUSH actually works. It seems to work most of
the time, but I probably miss something. I somehow had expected to see a call
to fflush - but I only see this for STDIN/STDOUT/STDERR. For the others, I
find:
raw_flush == return 0;
buf_flush: Some action, including lseek and raw_write (= unistd.h's write)
The function is called via sflush. And the FLUSH statement is file_pos.c's
st_flush:
library_start (fpp-common);
u = find_unit (fpp-common.unit);
if (u != NULL)
{
if (u-flags.form == FORM_FORMATTED)
fbuf_flush (u, u-mode);
sflush (u-s);
unlock_unit (u);
} [...]
library_end ();
Thus: I fail to see any fflush call for non-std(out/err/in) units. Did I miss
something?
See unix.c:buf_flush(). Called via the sflush() inline function/function
pointer thingy. libgfortran does not use C stdio
(fread/fwrite/fflush/fseek/...), but rather the lower level unbuffered POSIX IO
(read/write/lseek), with its own buffering implementation in
libgfortran/io/unix.c, see the buf_* functions.
I suspect the fflush() calls are there so that programs which mix Fortran and C
I/O to stdio/our/err work correctly (or well, hopefully at least better). But
the fflush() calls are not needed for pure gfortran IO per se.
As to the original issue, I have no idea why it fails on MinGW, and I don't
have a windows installation to test on either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44698
[Bug fortran/44698] I/O: FLUSH does not actually flush the buffer?
--- Comment #3 from ktietz at gcc dot gnu dot org 2010-06-28 17:27 --- Created an attachment (id=21030) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21030action=view) Patch for mingw x86/x64 targets This patch fixes for me the problem by calling in raw_flush and in buf_flush the '_commit' crt function. It takes care that internal file-data gets written, so that afterwards fstat will get the proper size. PS: Sorry for the whitespace changes, but my editor removes trailing whitespaces automatically (if wished I can remove them for final patch) Regards, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44698
[Bug testsuite/44701] New: [4.6 regression] PR44492 fix broke gcc.target/powerpc/asm-es-2.c
PR44492 was fixed in r161328. This revision changed the generated code for
asm-es-2.c as follows:
--- asm-es-2.s-ok
+++ asm-es-2.s-bad
@@ -23,9 +23,10 @@
f2:
.p2align 4,,15
.L3:
+ addi 3,3,16
#APP
# 14 gcc-4.6-20100626/gcc/testsuite/gcc.target/powerpc/asm-es-2.c 1
- asm2u 16(3)
+ asm2 0(3)
# 0 2
#NO_APP
b .L3
Since asm-es-2.c contains
/* { dg-final { scan-assembler asm2u 16\\(3\\) } } */
the code doesn't match causing the test case to now FAIL.
--
Summary: [4.6 regression] PR44492 fix broke
gcc.target/powerpc/asm-es-2.c
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44701
[Bug target/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-06-28 17:39 --- *** Bug 44700 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||michael at talamasca dot ||ocis dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug target/44700] Internal error (case derived from netpbm)
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-28 17:39 --- *** This bug has been marked as a duplicate of 44546 *** -- 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=44700
[Bug rtl-optimization/25130] [4.1/4.2 Regression] miscompilation in GCSE
--- Comment #21 from bernds at gcc dot gnu dot org 2010-06-28 17:50 --- The patch that was committed (especially the cse.c exp_equiv_p part) seems like a big hammer, and it does cause missed optimization opportunities. Reverting it on gcc-4.1-branch, and instead applying the patch for PR41033, also gives a compiler that correctly compiles this testcase. PR41033 adds a test for flag_strict_aliasing to nonverlapping_component_refs_p, which corrects the return value for canon_true_dependence mentioned in comment #9. Steven, are you certain that this patch is necessary in light of this? -- bernds at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25130
[Bug fortran/44697] I/O testsuite failures: \r\n vs \n - gfortran.dg/ftell_3.f90
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-06-28 17:59 --- Yes, suggested patch works fine for me -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44697
[Bug fortran/43954] gfortran-4.4 does not support -Wp, -MD for *.F (4.3 - 4.4 regression, needed for auto-dependencies)
--- Comment #9 from kirr at landau dot phys dot spbu dot ru 2010-06-28 18:04 --- REOPEN Daniel, thanks for working on this. Because dropping support for -MD was initially spot as 4.3 - 4.4 regression, and you committed the fix to 4.6 only, I think it would be good to apply your patch to 4.4 and 4.5 branches as well. I've backported it on top of today's gcc-4_4-branch and gcc-4_5-branch. Tested on i686-pc-linux-gnu OK for 4.4 and OK for check-fortran for 4.5 (*). Two patches for 4.4 4.5 will be next attached. Please apply and thanks, Kirill (*) as of today, gcc-4_5-branch does not pass all tests on i686-pc-linux-gnu. Look e.g. here http://gcc.gnu.org/ml/gcc-testresults/2010-06/ -- kirr at landau dot phys dot spbu dot ru changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug fortran/43954] gfortran-4.4 does not support -Wp, -MD for *.F (4.3 - 4.4 regression, needed for auto-dependencies)
--- Comment #10 from kirr at landau dot phys dot spbu dot ru 2010-06-28 18:05 --- Created an attachment (id=21031) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21031action=view) gfortran-4.4-MD.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug fortran/43954] gfortran-4.4 does not support -Wp, -MD for *.F (4.3 - 4.4 regression, needed for auto-dependencies)
--- Comment #11 from kirr at landau dot phys dot spbu dot ru 2010-06-28 18:06 --- Created an attachment (id=21032) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21032action=view) gfortran-4.5-MD.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug fortran/44702] New: ISO_C_BINDING does not allow multiple USE, ONLY local names.
A USE, ... ONLY: statement is allowed to define more than one local name for the same module entity. This is broken for the ISO_C_BINDING module (and perhaps for other intrinsic modules). For example, the following does not work: program bug_program use ISO_C_Binding, only: C_ptr, C_char_ptr=C_ptr type(C_ptr) :: p1 end program bug_program It only remembers the last local-name given. This construct does work if the the ISO_C_BINDING module is USEed indirectly by USEing a normal module that USEs ISO_C_BINDING. SO, it seems likely an intrinsic-module issue. -- Summary: ISO_C_BINDING does not allow multiple USE, ONLY local names. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44702
[Bug c++/44703] New: List initialization fail if parameter is typedef name for the std::initializer_list
List initialization fail if parameter is typedef-name of the
std::initializer_list.
#include initializer_list
typedef std::initializer_listint type ;
void f(type) {}
int main()
{
// error: could not convert '{1, 2, 3}' to 'type'
f({1,2,3}) ;
}
--
Summary: List initialization fail if parameter is typedef name
for the std::initializer_list
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44703
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-28 18:55 --- This is caused by revision 161496: Author: matz Date: Mon Jun 28 15:14:31 2010 UTC (2 hours, 52 minutes ago) Changed paths: 4 Log Message: PR middle-end/44592 * gimple-fold.c (gimplify_and_update_call_from_tree): Maintain proper VDEF chain for intermediate stores in the sequence. testsuite/ PR middle-end/44592 * gfortran.dg/pr44592.f90: New test. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug libfortran/43298] fortran library does not read in NaN -Inf or Inf
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-06-28 19:15 --- Tobias, Your patch is approved. Also, I managed to get all your comments addressd for the read_f patch including signs on Inf last night and will resubmit tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43298
[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128
--- Comment #10 from hjl dot tools at gmail dot com 2010-06-28 19:17 --- Here is a small testcase: [...@gnu-6 44551]$ cat c.s .file c.c .text .p2align 4,,15 .globl foo .type foo, @function foo: .LFB798: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 vinsertf128 $0x1, %xmm1, %ymm0, %ymm0 movq%rsp, %rbp .cfi_offset 6, -16 .cfi_def_cfa_register 6 vextractf128$0x1, %ymm0, %xmm0 leave .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE798: .size foo, .-foo .ident GCC: (GNU) 4.6.0 20100625 (experimental) .section.note.GNU-stack,,@progbits [...@gnu-6 44551]$ The optimize code is vmovaps %xmm1, %xmm0 ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551
[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-28 19:17
---
Testcase is
[...@gnu-6 44551]$ cat c.c
#include immintrin.h
__m128i
foo (__m256i x, __m128i y)
{
__m256i r = _mm256_insertf128_si256(x, y, 1);
__m128i a = _mm256_extractf128_si256(r, 1);
return a;
}
[...@gnu-6 44551]$ make c.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mavx -O2 -S c.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551
[Bug fortran/44698] I/O: FLUSH does not actually flush the buffer?
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-28 19:29 --- (In reply to comment #2) See unix.c:buf_flush(). Called via the sflush() inline function/function pointer thingy. libgfortran does not use C stdio (fread/fwrite/fflush/fseek/...), but rather the lower level unbuffered POSIX IO (read/write/lseek) Seemingly, I mixed this up with O_NONBLOCK; thus, indeed the POSIX I/O should be unbuffered. Thus, the question is why does MinGW buffer? Cf. http://www.opengroup.org/onlinepubs/95399/functions/write.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44698
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #14 from danglin at gcc dot gnu dot org 2010-06-28 19:31 --- I still see it as of 161474 (both head and 4.5). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug fortran/44702] ISO_C_BINDING does not allow multiple USE, ONLY local names.
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2010-06-28 19:31:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44702
[Bug fortran/44696] [OOP] Associated() doesn't work in subroutine
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-28 19:35 --- -fdump-tree-original shows that the ASSOCIATED statement inside the subroutine does not do the right thing: D.1556 = this-$data-parent.$data == (struct class$node_type *) that this-$data-parent.$data != 0B; that should be that-$data. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44696
[Bug fortran/44696] [OOP] ASSOCIATED fails on polymorphic variables
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-28 19:46 --- The following variant also fails (without the ASSOCIATED statement being inside a subroutine): program rte1 implicit none type::node_type class(node_type),pointer::parent,child integer::id end type node_type class(node_type),pointer::root allocate(root) allocate(root%child) root%child%parent=root root%id=1 root%child%id=2 print *,root%child%id, is child of ,root%id,: print *,root%child%parent%id,root%id,associated(root%child%parent,root) end program rte1 -- janus at gcc dot gnu dot org changed: What|Removed |Added Summary|[OOP] Associated() doesn't |[OOP] ASSOCIATED fails on |work in subroutine |polymorphic variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44696
[Bug fortran/44696] [OOP] ASSOCIATED fails on polymorphic variables
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-28 20:02 ---
The fix for this bug turns out to be totally trivial:
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (revision 161504)
+++ gcc/fortran/trans-intrinsic.c (working copy)
@@ -4416,6 +4416,8 @@ gfc_conv_associated (gfc_se *se, gfc_expr *expr)
else
{
/* An optional target. */
+ if (arg2-expr-ts.type == BT_CLASS)
+ gfc_add_component_ref (arg2-expr, $data);
ss2 = gfc_walk_expr (arg2-expr);
nonzero_charlen = NULL_TREE;
The first argument of ASSOCIATED being polymorphic was already handled
correctly, but not so for the second one.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2010-06-28 14:42:05 |2010-06-28 20:02:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44696
[Bug libfortran/43298] fortran library does not read in NaN -Inf or Inf
--- Comment #10 from burnus at gcc dot gnu dot org 2010-06-28 20:05 --- Subject: Bug 43298 Author: burnus Date: Mon Jun 28 20:04:40 2010 New Revision: 161510 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161510 Log: 2010-06-28 Tobias Burnus bur...@net-b.de PR fortran/43298 * list_read.c (parse_real, read_real): Support NAN(alphanum). 2010-06-28 Tobias Burnus bur...@net-b.de PR fortran/43298 * gfortran.dg/nan_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/nan_6.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43298
[Bug c++/44682] [4.6 Regression] warning: variable �x� set but not used
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-28 20:13 --- Subject: Bug 44682 Author: jakub Date: Mon Jun 28 20:12:31 2010 New Revision: 161511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161511 Log: PR c++/44682 * class.c (build_base_path): If want_pointer, call mark_rvalue_use on expr. * g++.dg/warn/Wunused-var-14.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-var-14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44682
[Bug middle-end/44592] [4.5 Regression] wrong code at -O3
--- Comment #7 from dominiq at lps dot ens dot fr 2010-06-28 20:42 --- Fixed for 4.6, waiting a bit for 4.5. Revision 161496 caused pr44699. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592
[Bug middle-end/44671] [4.6 Regression] Partial inlining breaks C++
--- Comment #8 from hubicka at gcc dot gnu dot org 2010-06-28 21:16 --- Subject: Bug 44671 Author: hubicka Date: Mon Jun 28 21:16:25 2010 New Revision: 161514 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161514 Log: PR middle-end/44671 * ipa-split.c (test_nonssa_use, mark_nonssa_use): Check also uses of RESULT_DECL. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
[Bug rtl-optimization/44695] [4.6 Regression] ice in simplify_subreg, at simplify-rtx.c:5117
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-28 21:57 --- I think it is a latent bug exposed by revision 161329. Now x86 backend may generate: (ior:HI (ashift:HI (zero_extend:HI (umod:QI (reg:HI 68) (reg:QI 61 [ D.2750 ]))) (const_int 8 [0x8])) (zero_extend:HI (udiv:QI (reg:HI 68) (reg:QI 61 [ D.2750 ] Combine ran into trouble: (gdb) bt #0 fancy_abort ( file=0x11e5860 /export/gnu/import/git/gcc/gcc/simplify-rtx.c, line=5117, function=0x11e6be0 simplify_subreg) at /export/gnu/import/git/gcc/gcc/diagnostic.c:879 #1 0x009d76ad in simplify_subreg (outermode=HImode, op=0x71d04f00, innermode=QImode, byte=0) at /export/gnu/import/git/gcc/gcc/simplify-rtx.c:5116 #2 0x009d87e6 in simplify_gen_subreg (outermode=HImode, op=0x71d04f00, innermode=QImode, byte=0) at /export/gnu/import/git/gcc/gcc/simplify-rtx.c:5426 #3 0x00fcc60a in if_then_else_cond (x=0x71b6d390, ptrue=0x7fffd448, pfalse=0x7fffd438) at /export/gnu/import/git/gcc/gcc/combine.c:8219 #4 0x00fcbf66 in if_then_else_cond (x=0x71b6d3a8, ptrue=0x7fffd4d0, pfalse=0x7fffd4c8) at /export/gnu/import/git/gcc/gcc/combine.c:8103 #5 0x00fc305a in combine_simplify_rtx (x=0x71b6d3a8, op0_mode=VOIDmode, in_dest=0) at /export/gnu/import/git/gcc/gcc/combine.c:4864 #6 0x00fc2def in subst (x=0x71b6d3a8, from=0x71c170c0, to=0x71c170c0, in_dest=0, unique_copy=0) at /export/gnu/import/git/gcc/gcc/combine.c:4803 #7 0x00fc2ba7 in subst (x=0x71b64720, from=0x71c170c0, ---Type return to continue, or q return to quit--- to=0x71c170c0, in_dest=0, unique_copy=0) at /export/gnu/import/git/gcc/gcc/combine.c:4741 #8 0x00fc2ba7 in subst (x=0x71b64738, from=0x71c170c0, to=0x71c170c0, in_dest=0, unique_copy=0) at /export/gnu/import/git/gcc/gcc/combine.c:4741 #9 0x00fbd20b in try_combine (i3=0x71b0a870, i2=0x71b0a798, i1=0x0, new_direct_jump_p=0x7fffdaf4) at /export/gnu/import/git/gcc/gcc/combine.c:2885 #10 0x00fb911e in combine_instructions (f=0x71c227c0, nregs=70) at /export/gnu/import/git/gcc/gcc/combine.c:1152 #11 0x00fd898f in rest_of_handle_combine () at /export/gnu/import/git/gcc/gcc/combine.c:13342 -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44695
[Bug middle-end/44671] [4.6 Regression] Partial inlining breaks C++
--- Comment #9 from paolo dot carlini at oracle dot com 2010-06-28 22:27 --- Confirmed fixed, thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
[Bug rtl-optimization/44695] [4.6 Regression] ice in simplify_subreg, at simplify-rtx.c:5117
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-28 23:21 --- Created an attachment (id=21033) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21033action=view) A patch This patch avoids ICE. But it probably isn't the right fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44695
[Bug middle-end/44576] [4.5/4.6 Regression] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling
--- Comment #11 from changpeng dot fang at amd dot com 2010-06-29 00:07 --- I have a patch that partially fixes the problem: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02956.html Note that for this test case, the compile time doubled even though I don't compute the miss rate at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
[Bug c/44704] New: gobject-introspection Error
Information about my system: FreeBSD i386-undermydesk-freebsd GCC version 4.2.1 20070719 [FreeBSD] Don't know the options; I guess they may be default(?) I got it from running portupgrade gobject-introspection as root. It eventually displays gmake[2]: Leaving directory '/usr/port/devel/gobject-introspection/work/gobject-introspection-0.6.14/tools' Making all in gir gmake[2]: Entering directory '/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.6.14/gir' CC libgirrepository_everything_1_0_la_everything.lo everything.c: In function 'test_array_gtype_in': everything.c:588: internal compiler error: in stmt_ann, at tree-flow-inline.h:174 Please submit a full bug report, with preprocessed source if appropriate. I don't know if this is really a big deal or not, but it told me to report it, so I tried. I apologize for not having the .i files as described in the guide as I do not know where they are or how to get them. Thank you for your time. -- Summary: gobject-introspection Error Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hibba42 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44704
[Bug tree-optimization/44704] gobject-introspection Error
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-29 00:29 --- A few things. We need the preprocessed source as requested by http://gcc.gnu.org/bugs.html. Next I notice you are using a GCC provided by freebsd, you should report this bug to them really. Not to mention 4.2.x is no longer supported, you might want to try a newer version first to see if it has already been fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |tree-optimization Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44704
[Bug middle-end/44576] [4.5/4.6 Regression] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling
--- Comment #12 from changpeng dot fang at amd dot com 2010-06-29 00:49 --- Created an attachment (id=21034) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21034action=view) Early return in miss rate computation The attached patch improves the computation of miss rate. We can stop computing if the total misses has always exceeds the given acceptable threshold. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
[Bug tree-optimization/44705] New: FAIL: gcc.dg/pr44674.c (internal compiler error)
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr44674.c -O -fprofile-generate -S -o
pr4
4674.s(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr44674.c: In function 'jumpfunc':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr44674.c:10:1: error: insn does not
sati
sfy its constraints:
(insn 38 30 32 2 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr44674.c:9 (set
(reg:QI
28 %r28 [orig:112 jumplabel ] [112])
(mem/c/i:QI (label_ref:SI [22 deleted]) [0 jumplabel+0 S1 A8])) 58
{*pa.
md:2936} (nil))
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr44674.c:10:1: internal compiler error:
in reload_cse_simplify_operands, at postreload.c:395
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
compiler exited with status 1
Also seen on trunk.
--
Summary: FAIL: gcc.dg/pr44674.c (internal compiler error)
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa2.0w-hp-hpux11.11
GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44705
[Bug middle-end/44706] New: [4.6 regression] Failed to build 483.xalancbmk in SPEC CPU 2006
On Linux/x86-64, revision 161503 gave [...@gnu-27 build_base_o3.]$ /export/gnu/import/svn/gcc-test/usr/bin/gcc -DSPEC_CPU -DNDEBUG -DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl -Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory -Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -O2 -ffast-math-DSPEC_CPU_LP64 -DSPEC_CPU_LINUX DTDAttDefList.cpp -S DTDAttDefList.cpp: In member function \u2018virtual xercesc_2_5::XMLAttDef xercesc_2_5::DTDAttDefList::getAttDef(unsigned int)\u2019: DTDAttDefList.cpp:206:12: internal compiler error: tree check: expected var_decl or parm_decl, have result_decl in expand_one_var, at cfgexpand.c:967 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [...@gnu-27 build_base_o3.]$ Revision 161485 is OK. -- Summary: [4.6 regression] Failed to build 483.xalancbmk in SPEC CPU 2006 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44706
[Bug middle-end/44706] [4.6 regression] Failed to build 483.xalancbmk in SPEC CPU 2006
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-29 04:39 --- This is caused by revision 161500: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01418.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44706
[Bug middle-end/44706] [4.6 regression] Failed to build 483.xalancbmk in SPEC CPU 2006
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-29 05:23 ---
[...@gnu-34 delta]$ cat testcase.cc
class MemoryManager;
class XMLExcepts {
public :
enum Codes {
AttrList_BadIndex
};
};
class XMLException {
public:
XMLException(const char* const srcFile, const unsigned int srcLine,
MemoryManager* const memoryManager = 0);
};
class ArrayIndexOutOfBoundsException : public XMLException {
public:
ArrayIndexOutOfBoundsException(const char* const srcFile , const unsigned
int srcLine , const XMLExcepts::Codes toThrow , MemoryManager* memoryManager =
0) : XMLException(srcFile, srcLine, memoryManager) {
}
};
class XMLAttDef {
bool fExternalAttribute;
};
class XMLAttDefList {
public:
MemoryManager* getMemoryManager() const;
};
class DTDAttDef : public XMLAttDef {
};
class DTDAttDefList : public XMLAttDefList {
virtual const XMLAttDef getAttDef(unsigned int index) const ;
DTDAttDef** fArray;
unsigned int fCount;
};
const XMLAttDef DTDAttDefList::getAttDef(unsigned int index) const {
if(index = fCount)
throw ArrayIndexOutOfBoundsException(foo.cpp, 0,
XMLExcepts::AttrList_BadIndex, getMemoryManager());
return *(fArray[index]);
}
[...@gnu-34 delta]$ /export/build/gnu/gcc/release/usr/gcc-4.6.0/bin/gcc -S -O2
testcase.cc
testcase.cc: In member function \u2018virtual const XMLAttDef
DTDAttDefList::getAttDef(unsigned int) const\u2019:
testcase.cc:31:18: internal compiler error: tree check: expected var_decl or
parm_decl, have result_decl in expand_one_var, at cfgexpand.c:967
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[...@gnu-34 delta]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44706
[Bug fortran/44698] I/O: FLUSH does not actually flush the buffer?
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-06-29 05:32 --- One possible cause of this problem is that in configuration there could be something going wrong with stat functions returning 32-bit vs 64-bit values. I found one thread where C++ code was using 32-bit versions of calls even though LARGE_FILE support had been enabled. In inquire.c (filesize) we are casting to a 64-bit result. return (GFC_IO_INT) statbuf.st_size; Another possibility is that according to this: http://msdn.microsoft.com/en-us/library/14h5k7ff%28VS.71%29.aspx The required header when using stati64 as we are in io/unix.c for mingw is: sys/types.h followed by sys/stat.h I do not see sys/types.h included. Is it implied by windows.h? Maybe we need to fix this here: /* Unix stream I/O module */ #include io.h #include unix.h #include stdlib.h #include limits.h #include unistd.h #include sys/stat.h #include fcntl.h #include assert.h #include string.h #include errno.h /* For mingw, we don't identify files by their inode number, but by a 64-bit identifier created from a BY_HANDLE_FILE_INFORMATION. */ #ifdef __MINGW32__ #define WIN32_LEAN_AND_MEAN #include windows.h #define lseek _lseeki64 #define fstat _fstati64 #define stat _stati64 typedef struct _stati64 gfstat_t; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44698
