[Bug target/47998] ICE of -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47998 --- Comment #1 from Yoshinori Sato ysato at users dot sourceforge.jp 2011-03-06 08:11:08 UTC --- Created attachment 23557 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23557 proposal fix It mismatch of restriction rule.
[Bug target/47998] ICE of -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47998 Yoshinori Sato ysato at users dot sourceforge.jp changed: What|Removed |Added Attachment #23557|0 |1 is obsolete|| --- Comment #2 from Yoshinori Sato ysato at users dot sourceforge.jp 2011-03-06 08:55:28 UTC --- Created attachment 23558 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23558 proposal fix Sorry. I mistake. Update changes.
[Bug bootstrap/48000] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.06 09:26:02 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-03-06 09:26:02 UTC --- Confirmed. Most porbably fallout from Zdenek's patch. The loop body size is wrong. Honza (gdb) bt #0 fancy_abort (file=0x310ef83 ../../gcc/cfganal.c, line=1209, function=0x310f1a0 dfs_enumerate_from) at ../../gcc/diagnostic.c:893 #1 0x0087e887 in dfs_enumerate_from (bb=0x76619618, reverse=1, predicate=0x924030 glb_enum_p, rslt=0x466d2a0, rslt_max=1, data=0x769a0880) at ../../gcc/cfganal.c:1209 #2 0x009240c1 in get_loop_body_with_size (loop=0x769a0880, body=0x466d2a0, max_size=1) at ../../gcc/cfgloop.c:800 #3 0x00924202 in get_loop_body (loop=0x769a0880) at ../../gcc/cfgloop.c:829 #4 0x00924b6f in get_loop_exit_edges (loop=0x769a0880) at ../../gcc/cfgloop.c:1146 #5 0x00962c3b in fix_loop_placement (loop=0x769a0880) at ../../gcc/cfgloopmanip.c:129 #6 0x00962eb8 in fix_bb_placements (from=0x76619618, irred_invalidated=0x7fffe10f ) at ../../gcc/cfgloopmanip.c:215 #7 0x0096350a in remove_path (e=0x76870840) at ../../gcc/cfgloopmanip.c:383 #8 0x0106b1d2 in unswitch_loop (loop=0x77361990, unswitch_on=0x7660d7b8, cond=0x764feba0, cinsn=0x0) at ../../gcc/loop-unswitch.c:458 #9 0x0106a6d6 in unswitch_single_loop (loop=0x77361990, cond_checked=0x0, num=0) at ../../gcc/loop-unswitch.c:370 #10 0x01069c75 in unswitch_loops () at ../../gcc/loop-unswitch.c:150 #11 0x01007332 in rtl_unswitch () at ../../gcc/loop-init.c:285 #12 0x0121f258 in execute_one_pass (pass=0x43cfe20) at ../../gcc/passes.c:1556 #13 0x0121f432 in execute_pass_list (pass=0x43cfe20) at ../../gcc/passes.c:1611 #14 0x0121f450 in execute_pass_list (pass=0x43cfca0) at ../../gcc/passes.c:1612 #15 0x0121f450 in execute_pass_list (pass=0x43d00c0) at ../../gcc/passes.c:1612 #16 0x019a333b in tree_rest_of_compilation (fndecl=0x77007300) at ../../gcc/tree-optimize.c:422 #17 0x025a1146 in cgraph_expand_function (node=0x769a86e0) at ../../gcc/cgraphunit.c:1576 #18 0x025a12f6 in cgraph_expand_all_functions () at ../../gcc/cgraphunit.c:1635 #19 0x025a1943 in cgraph_optimize () at ../../gcc/cgraphunit.c:1899 #20 0x0259f575 in cgraph_finalize_compilation_unit () at ../../gcc/cgraphunit.c:1096 #21 0x004fd529 in c_write_global_declarations () at ../../gcc/c-decl.c:9872 #22 0x01644bfd in compile_file () at ../../gcc/toplev.c:591 #23 0x01646e94 in do_compile () at ../../gcc/toplev.c:1900 #24 0x01646fbf in toplev_main (argc=4, argv=0x7fffe7c8) at ../../gcc/toplev.c:1963 #25 0x007109ff in main (argc=4, argv=0x7fffe7c8) at ../../gcc/main.c:36
[Bug bootstrap/48000] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000 --- Comment #4 from Zdenek Dvorak rakdver at gcc dot gnu.org 2011-03-06 10:43:41 UTC --- Created attachment 23559 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23559 A proposed patch This fixes the problem uncovered by the previous fix. In fix_bb_placements, we restrict the placement changes to the basic blocks that originally were in the base loop (the loop containing the FROM basic block). This is achieved by marking the header of the loop visited, so that we never enter it to the processing queue. However, if FROM itself is the header of the loop, this fails, as we enter FROM to the queue unconditionally. Fixed by ending immediatelly if FROM is a loop header.
[Bug ada/48002] New: internal error on calling inherited, overloaded and abstract subprograms with string literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48002 Summary: internal error on calling inherited, overloaded and abstract subprograms with string literal Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: demoon...@panathenaia.halfmoon.jp Created attachment 23560 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23560 minimal bug triggering source code gcc-4.5.1 and 4.5.2 crash with internal error. 1. declare a type (named A.T) and primitive subprogram (named A.F) having a String parameter. 2. declare new type (named B.T) derived from A.T, this type has inherited subprogram B.F from A.F. 3. re-declare B.F as abstract to hide. 4. overload B.F having a Wide_String parameter. 5. call Wide_String version of B.F with string literal. minimal source: procedure overload_str is package A is type T is new Integer; procedure F (X : T; Y : String) is null; end A; package B is type T is new A.T; procedure F (X : T; Y : Wide_String) is null; procedure F (X : T; Y : String) is abstract; -- hide inherited F end B; begin B.F (B.T'(0), ABC); -- compiler may crash B.F (B.T'(0), Wide_String'(ABC)); -- OK end overload_str; % gnatmake overload_str gcc -c overload_str.adb +===GNAT BUG DETECTED==+ | 4.5.2 (i686-apple-darwin9) Assert_Failure einfo.adb:1698 | | Error detected at overload_str.adb:12:10 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). overload_str.adb compilation abandoned gnatmake: overload_str.adb compilation error
[Bug c++/48003] New: Regression in Template Constants from 4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48003 Summary: Regression in Template Constants from 4.5.2 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: swest...@gmail.com The following code compiles cleanly under g++ 4.5.2, but fails to compile under g++ 4.6.0: #include climits #include boost/mpl/int.hpp boost::mpl::int_INT_MIN foo; It produces the errors: /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of ‘mpl_::int_-0x08000’: test_test.cpp:8:27: instantiated from here /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: ‘2147483647’ is not a valid template argument for type ‘int’ because it is a non-constant expression /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: overflow in constant expression [-fpermissive] I tested this using Boost 1.46 on a Debian AMD_64 SID system running with a 2.6.36 kernel.
[Bug c++/48003] Regression in Template Constants from 4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48003
Philipp s...@s-e-f-i.de changed:
What|Removed |Added
CC||s...@s-e-f-i.de
--- Comment #1 from Philipp s...@s-e-f-i.de 2011-03-06 12:29:29 UTC ---
Small testcase.
#include climits
templateint N
struct test
{
typedef testN - 1 prior;
};
typedef testINT_MIN foo;
foo f;
int main()
{
}
Of course INT_MIN - 1 is undefined but should gcc really evaluate it here?
[Bug pch/48004] New: doesn't work with randomize_va_space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48004 Summary: doesn't work with randomize_va_space Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassig...@gcc.gnu.org ReportedBy: wbr...@gmail.com If address space randomization is enabled echo 1 /proc/sys/kernel/randomize_va_space pch isn't used - warning: had text segment at different address
[Bug debug/47881] [4.6 Regression] -fcompare-debug failure (length) with -O -fno-dce -funroll-loops -fno-web
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47881 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.06 13:55:09 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c++/48003] Regression in Template Constants from 4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48003 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-06 14:05:42 UTC --- Apparently what used to be a warning not is an hard error. Let's ask Jason, can be a regression.
[Bug lto/48005] New: program using libgloss fails to link when built with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48005 Summary: program using libgloss fails to link when built with -flto Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: gr...@moxielogic.com All of the -flto tests are failing for the moxie-elf port because the linker fails to include the libgloss library (libsim.a, in this case). libsim.a is forced into the link by a linker script we pass to gcc (-Tsim.ld). It looks like it is probably identical or related to this: http://sourceware.org/ml/binutils/2011-01/msg00108.html
[Bug c++/48003] Regression in Template Constants from 4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48003 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-06 14:21:12 UTC --- EDG rejects it, clang doesn't
[Bug c/48006] New: Inefficient optimization depends on builtin integer type of same size.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48006
Summary: Inefficient optimization depends on builtin integer
type of same size.
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ca...@gcc.gnu.org
Created attachment 23561
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23561
The test file used.
Working on M4RI, I found that changing a typedef from unsigned long long to
unsigned long caused one of the bench marks to become 50% slower. This is
peculiar since I'm on a 64-bit box where the size of both is 8 byte.
After investigation I ended up with the following function that is the cause
for at least 25% slow down, so a good case to investigate this (compiler) bug
(assuming you're willing to call not-optimal compiled code a bug).
===Start of File=
#define RADIX 64
typedef unsigned long word;
typedef unsigned long size_t;
typedef struct _mm_block {
size_t size;
void *data;
} mmb_t;
typedef struct {
mmb_t *blocks;
size_t nrows;
size_t ncols;
size_t width;
size_t offset;
word** rows;
} mzd_t;
typedef unsigned char BIT;
#define ONE ((word)1)
#define GET_BIT(w, spot) (((w) (RADIX - 1 - (spot))) ONE)
static inline BIT mzd_read_bit(const mzd_t *M, const size_t row, const size_t
col ) {
return GET_BIT(M-rows[row][(col+M-offset)/RADIX], (col+M-offset) % RADIX);
}
void foo(mzd_t* DST, mzd_t const* A, int i, int eol)
{
#ifdef OLDCODE
unsigned long long* temp = (unsigned long long*)DST-rows[i];
for (int j = 0; j eol; j += RADIX, ++temp)
for (int k = RADIX - 1; k = 0; --k)
*temp |= ((unsigned long long)mzd_read_bit(A, j+k,
i+A-offset))(RADIX-1-k);
#else
word* temp = DST-rows[i];
for (int j = 0; j eol; j += RADIX, ++temp)
for (int k = RADIX - 1; k = 0; --k)
*temp |= ((word)mzd_read_bit(A, j+k, i+A-offset))(RADIX-1-k);
#endif
}
===END OF FILE
Compile this with on a x86_64 machine with:
gcc -std=gnu99 -O2 -c transposebody.c -fPIC -DPIC -o transposebody.o -DOLDCODE
-save-temps
one with and without the -DOLDCODE will show a remarkable difference in the
resulting assembly code, using more registers and a lot more instructions when
OLDCODE is not defined.
Note that the only difference is that with OLDCODE defined we cast the unsigned
char returned from mzd_read_bit to an unsigned long long instead of to an
unsigned long, and the type of temp is unsigned long long* instead of unsigned
long*.
$ uname -a
Linux hikaru 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64
GNU/Linux
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 --- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-06 14:59:05 UTC --- Info: Does not fix it but why this behavior with the test case? Index: expr.c === --- expr.c(revision 170543) +++ expr.c(working copy) @@ -946,6 +946,7 @@ gfc_is_constant_expr (gfc_expr *e) return 1; case EXPR_ARRAY: + /* return 1 here and it works. */ return gfc_constant_ac (e); default:
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 --- Comment #12 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-06 15:16:46 UTC --- Passes: case EXPR_ARRAY: /* return 1 here and it works. */ /* gfc_constant_ac (e); */ return 1; Fails: case EXPR_ARRAY: /* return 1 here and it works. */ gfc_constant_ac (e); return 1;
[Bug other/48007] New: Unwind library doesn't work with UNITS_PER_WORD sizeof (void *)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48007
Summary: Unwind library doesn't work with UNITS_PER_WORD
sizeof (void *)
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
unwind-dw2.c has
/* This is the register and unwind state for a particular frame. This
provides the information necessary to unwind up past a frame and return
to its caller. */
struct _Unwind_Context
{
void *reg[DWARF_FRAME_REGISTERS+1];
void *cfa;
void *ra;
void *lsda;
struct dwarf_eh_bases bases;
/* Signal frame context. */
#define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 1) + 1)
/* Context which has version/args_size/by_value fields. */
#define EXTENDED_CONTEXT_BIT ((~(_Unwind_Word) 0 2) + 1)
_Unwind_Word flags;
/* 0 for now, can be increased when further fields are added to
struct _Unwind_Context. */
_Unwind_Word version;
_Unwind_Word args_size;
char by_value[DWARF_FRAME_REGISTERS+1];
};
We can't save an integer register in void * if its size size of
void *.
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 --- Comment #13 from Paul Thomas pault at gcc dot gnu.org 2011-03-06 16:19:02 UTC --- (In reply to comment #12) Jerry, Based in this and comment #11, I noted that the place where this was failing was iterator-free EXPR_ARRAYs. I then leapt to the following patch, which is just now regtesting (it's up to typebound_generic_4.f03): Index: /svn/trunk/gcc/fortran/expr.c === *** /svn/trunk/gcc/fortran/expr.c(revision 170337) --- /svn/trunk/gcc/fortran/expr.c(working copy) *** gfc_is_constant_expr (gfc_expr *e) *** 937,952 return e-ref == NULL || (gfc_is_constant_expr (e-ref-u.ss.start) gfc_is_constant_expr (e-ref-u.ss.end)); case EXPR_STRUCTURE: ! for (c = gfc_constructor_first (e-value.constructor); !c; c = gfc_constructor_next (c)) if (!gfc_is_constant_expr (c-expr)) return 0; return 1; - case EXPR_ARRAY: - return gfc_constant_ac (e); default: gfc_internal_error (gfc_is_constant_expr(): Unknown expression type); --- 937,954 return e-ref == NULL || (gfc_is_constant_expr (e-ref-u.ss.start) gfc_is_constant_expr (e-ref-u.ss.end)); + case EXPR_ARRAY: case EXPR_STRUCTURE: ! c = gfc_constructor_first (e-value.constructor); ! if ((e-expr_type == EXPR_ARRAY) c c-iterator) ! return gfc_constant_ac (e); ! ! for (; c; c = gfc_constructor_next (c)) if (!gfc_is_constant_expr (c-expr)) return 0; return 1; default: gfc_internal_error (gfc_is_constant_expr(): Unknown expression type); Cheers Paul
[Bug other/48007] Unwind library doesn't work with UNITS_PER_WORD sizeof (void *)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48007 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-03-06 17:20:01 UTC --- Author: hjl Date: Sun Mar 6 17:19:57 2011 New Revision: 170716 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170716 Log: Save call frame hard registers as _Unwind_Word. 2011-03-06 H.J. Lu hongjiu...@intel.com PR other/48007 * unwind-dw2.c (_Unwind_Context): Save call frame hard registers as _Unwind_Word. (_Unwind_GetGR): Get GR value as _Unwind_Word. (_Unwind_SetGR): Set GR value as _Unwind_Word. (_Unwind_SetGRValue): Likewise. (_Unwind_GetGRPtr): Cast return to void *. (_Unwind_SetGRPtr): Cast pointer to _Unwind_Word. (uw_install_context_1): Cast pointer to void *. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/unwind-dw2.c
[Bug c++/48008] New: [4.6 Regression] libstdc++-v3/testsuite/20_util/function/43397.cc fails to assemble with -fabi-version=5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48008 Summary: [4.6 Regression] libstdc++-v3/testsuite/20_util/function/43397.cc fails to assemble with -fabi-version=5 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz I am not sure if this is a bug, but as there were commits to the ABI code, and the release is probably near, I opened this PR without more analysing... I am sorry if it renders invalid. This is the compiler output: $ g++ testcase2.C -std=c++0x -fabi-version=5 -c /tmp/cclBTCq8.s: Assembler messages: /tmp/cclBTCq8.s:314: Error: symbol `_ZSt6mem_fnIFiOiE3FooESt7_Mem_fnIMT0_T_ES6_' is already defined /tmp/cclBTCq8.s:352: Error: symbol `_ZSt6mem_fnIFiOiE3FooESt7_Mem_fnIMT0_T_ES6_' is already defined /tmp/cclBTCq8.s:390: Error: symbol `_ZSt6mem_fnIFiOiE3FooESt7_Mem_fnIMT0_T_ES6_' is already defined $ echo _ZSt6mem_fnIFiOiE3FooESt7_Mem_fnIMT0_T_ES6_ | c++filt std::_Mem_fnint (Foo::*)(int) std::mem_fnint ()(int), Foo(int (Foo::*)(int)) With -fabi-version=1 (or gcc 4.5), the following symbols are generated: $ echo _ZSt6mem_fnIFiOiE3FooESt7_Mem_fnIMT0_T_ES6_ | c++filt std::_Mem_fnint (Foo::*)(int) std::mem_fnint ()(int), Foo(int (Foo::*)(int)) $ echo _ZSt6mem_fnIKFiOiE3FooESt7_Mem_fnIMT0_T_ES7_ | c++filt std::_Mem_fnint ( const Foo::*)(int) std::mem_fnint ( const)(int), Foo(int ( const Foo::*)(int)) $ echo _ZSt6mem_fnIVFiOiE3FooESt7_Mem_fnIMT0_T_ES7_ | c++filt std::_Mem_fnint ( volatile Foo::*)(int) std::mem_fnint ( volatile)(int), Foo(int ( volatile Foo::*)(int)) $ echo _ZSt6mem_fnIVKFiOiE3FooESt7_Mem_fnIMT0_T_ES7_ | c++filt std::_Mem_fnint ( const volatile Foo::*)(int) std::mem_fnint ( const volatile)(int), Foo(int ( const volatile Foo::*)(int))
[Bug c++/48008] [4.6 Regression] libstdc++-v3/testsuite/20_util/function/43397.cc fails to assemble with -fabi-version=5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48008 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2011-03-06 17:32:33 UTC --- Created attachment 23562 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23562 reduced testcase Reduced from libstdc++-v3/testsuite/20_util/function/43397.cc Also, it compiles with 4.5 (compared to original testcase).
[Bug bootstrap/48000] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-06 17:38:11 UTC --- (In reply to comment #4) Created attachment 23559 [details] A proposed patch This fixes the problem uncovered by the previous fix. In fix_bb_placements, we restrict the placement changes to the basic blocks that originally were in the base loop (the loop containing the FROM basic block). This is achieved by marking the header of the loop visited, so that we never enter it to the processing queue. However, if FROM itself is the header of the loop, this fails, as we enter FROM to the queue unconditionally. Fixed by ending immediatelly if FROM is a loop header. Successfully bootstrapped/regtested on x86_64-linux and i686-linux as well as successfully profiledbootstrapped/regtested on those two targets (the latter is what was failing before), no regressions.
[Bug rtl-optimization/47866] [4.5/4.6 Regression] gcc.dg/torture/vector-2.c fails on IA64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47866 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.06 19:07:33 Target Milestone|--- |4.5.3 Summary|gcc.dg/torture/vector-2.c |[4.5/4.6 Regression] |fails on IA64 |gcc.dg/torture/vector-2.c ||fails on IA64 Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-03-06 19:07:33 UTC --- Confirmed, a regression due to the failure in the testsuite.
[Bug bootstrap/48009] New: Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 Summary: Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*' Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Host: powerpc-ibm-aix4.3.2.0 Target: powerpc-ibm-aix4.3.2.0 Build: powerpc-ibm-aix4.3.2.0 After working around bug #47907, bootstrapping GCC 4.5.2 on this AIX 4.3 system fails with ln -s /home/src/gcc-4.5.2/libstdc++-v3/config/locale/generic/c_locale.cc ./c++locale.cc || true [...] libtool: compile: /tmp/gcc-4.5.2-build/./gcc/xgcc -shared-libgcc -B/tmp/gcc-4.5.2-build/./gcc -nostdinc++ -L/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src -L/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src/.libs -B/opt/tg/powerpc-ibm-aix4.3.2.0/bin/ -B/opt/tg/powerpc-ibm-aix4.3.2.0/lib/ -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/include -isystem /opt/tg/powerpc-ibm-aix4.3.2.0/sys-include -I/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include/powerpc-ibm-aix4.3.2.0 -I/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/include -I/home/src/gcc-4.5.2/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -c c++locale.cc -DPIC -o c++locale.o c++locale.cc: In function 'void std::__convert_to_v(const char*, _Tp, std::ios_base::iostate, int* const) [with _Tp = float, std::ios_base::iostate = std::_Ios_Iostate, int* = int*]': c++locale.cc:66:34: error: invalid conversion from 'const char*' to 'char*' c++locale.cc:66:34: error: initializing argument 1 of 'float strtof(char*, char**)' make[4]: *** [c++locale.lo] Error 1 make[4]: Leaving directory `/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/tmp/gcc-4.5.2-build/powerpc-ibm-aix4.3.2.0/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/tmp/gcc-4.5.2-build' make: *** [bootstrap-lean] Error 2 Sure enough, % grep strtof /usr/include/*.h /usr/include/stdlib.h: extern floatstrtof(); /usr/include/stdlib.h: extern floatstrtof(char *, char **); This is the same as bug #26297, except with newer versions of AIX and GCC. I will attempt adding the const keyword to the strtof() prototype in GCC's copy of the system stdlib.h.
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 --- Comment #14 from Paul Thomas pault at gcc dot gnu.org 2011-03-06 20:15:42 UTC --- Author: pault Date: Sun Mar 6 20:15:38 2011 New Revision: 170720 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170720 Log: 2011-03-06 Paul Thomas pa...@gcc.gnu.org Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/47850 * expr.c (gfc_is_constant_expr): Only use gfc_constant_ac if the expression has an iterator. Otherwise, iterate through the array, checking for constant expressions for each element. 2011-03-06 Paul Thomas pa...@gcc.gnu.org Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/47850 * gfortran.dg/array_constructor_37.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_37.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #15 from Paul Thomas pault at gcc dot gnu.org 2011-03-06 20:20:31 UTC --- Fixed on trunk. Thanks for the report. Paul
[Bug c++/48010] New: typedef redefinitions are allowed if the redefined type is a nested class type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48010
Summary: typedef redefinitions are allowed if the redefined
type is a nested class type
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: fab...@gcc.gnu.org
ReportedBy: fab...@gcc.gnu.org
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
struct A
{
struct type {};
typedef int type;
};
[Bug c++/48010] typedef redefinitions are allowed if the redefined type is a nested class type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48010 fabien at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.06 20:42:33 Ever Confirmed|0 |1 Known to fail||4.1.2, 4.2.4, 4.3.5, 4.4.5, ||4.5.2 --- Comment #1 from fabien at gcc dot gnu.org 2011-03-06 20:42:33 UTC --- Jason confirmed it while discussing about PR 26256. Mine.
[Bug pch/48004] doesn't work with randomize_va_space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48004 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-03-06 21:07:04 UTC --- Which host is this on?
[Bug pch/48004] doesn't work with randomize_va_space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48004 wbrana wbrana at gmail dot com changed: What|Removed |Added Host||x86_64-pc-linux-gnu --- Comment #2 from wbrana wbrana at gmail dot com 2011-03-06 21:11:50 UTC --- x86_64-pc-linux-gnu
[Bug other/48007] Unwind library doesn't work with UNITS_PER_WORD sizeof (void *)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48007 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-03-06 21:12:55 UTC --- Does it matter for the propose of unwinding as all we care about is pointers to get back to frame before? Your commit might change the ABI for some targets.
[Bug fortran/42189] gfc_is_constant_expr has unacceptable side effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42189 --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-06 21:17:26 UTC --- I believe the fix to PR47850 has resolved this issue. I suggest we close this one.
[Bug other/48007] Unwind library doesn't work with UNITS_PER_WORD sizeof (void *)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48007 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-03-06 21:21:03 UTC --- X32 glibc force unwind calls _Unwind_SetGRValue to restore a 64bit register value.
[Bug fortran/48011] New: internal compiler error:tree check: expected function_type or method_type, have pointer_type in gimplify_call_expr at gimplify.c:2355
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48011 Summary: internal compiler error:tree check: expected function_type or method_type, have pointer_type in gimplify_call_expr at gimplify.c:2355 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dominique.pellet...@polymtl.ca Created attachment 23563 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23563 code from D Rouson from Sandia. uses som abstract data type... i got the attached Fortran 2003 program from Damien Rouson at Sandia. it compiled and executed correctly with IBM xlf compiler and the CRAY compile. with gfortran i got the following error message from the compiler: in function 'integrate': ex1.f0:72:0: internal compiler error: tree check: expected function_type or method_type, have pointer_type in gimplify_call_expr at gimplify.c:2355 Thank you for you help Dominique Pelletier
[Bug fortran/48011] internal compiler error:tree check: expected function_type or method_type, have pointer_type in gimplify_call_expr at gimplify.c:2355
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48011 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-06 22:20:46 UTC --- This looks like a duplicate of pr46262 (cc Janus).
[Bug bootstrap/47907] Bootstrap failure: libiberty/hashtab.c: error: conflicting types for 'int_fast16_t'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47907
--- Comment #2 from Daniel Richard G. skunk at iskunk dot org 2011-03-06
22:28:42 UTC ---
I've managed to work around this issue with the following steps:
1. Create a site configuration file with the following:
ac_cv_header_stdint_h=no
gcc_cv_header_stdint_h=no
glibcxx_cv_c99_stdint_tr1=no
gt_cv_header_stdint_h=no
jm_ac_cv_header_stdint_h=no
2. Set the environment variable CONFIG_SITE to the path to this file.
3. /path/to/gcc-4.5.2/configure --yadda --yadda --whatever
4. Edit the top-level Makefile to replace all lines of the form
CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
with e.g.
XXX_CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
(That is, so CONFIG_SITE is not overridden at any point.)
5. Bootstrap GCC.
The problem appears to be that GCC's stdint.h (which in this case is really
gcc-4.5.2/gcc/ginclude/stdint-gcc.h, because the system has no stdint.h of its
own) is incompatible with the system's inttypes.h. Blacklisting inttypes.h
doesn't work, because the system's sys/types.h #includes it. Blacklisting GCC's
stdint.h, however, allows the bootstrap to complete (modulo bug #48009).
[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 --- Comment #1 from Daniel Richard G. skunk at iskunk dot org 2011-03-06 22:33:42 UTC --- Editing the strtof() prototype in $top_builddir/gcc/include-fixed/stdlib.h allows the bootstrap to complete successfully. Looks like all this needs is a tweak to fixincludes.
[Bug fortran/47778] reading two arrays of structures from namelist fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47778 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-07 02:06:32 UTC --- Author: jvdelisle Date: Mon Mar 7 02:06:27 2011 New Revision: 170726 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170726 Log: 2011-03-06 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/47778 * io/list_read.c (namelist_read): Intialize the error string buffere. If pprev_nl was used during the previous namelist read and the rank was zero, reset the pointer to NULL for the next namelist read. Modified: branches/gcc-4_5-branch/libgfortran/ChangeLog branches/gcc-4_5-branch/libgfortran/io/list_read.c
[Bug fortran/47778] reading two arrays of structures from namelist fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47778 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-07 02:12:01 UTC --- Author: jvdelisle Date: Mon Mar 7 02:11:56 2011 New Revision: 170727 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170727 Log: 2011-03-06 Jerry DeLisle jvdeli...@gcc.gnu.org Backport from mainline PR libgfortran/47778 * gfortran.dg/namelist_71.f90: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/namelist_71.f90 Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug fortran/47778] reading two arrays of structures from namelist fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47778 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-07 02:16:16 UTC --- Fixed on 4.5 and 4.6. Closing
[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #28 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-07 03:08:12 UTC --- Author: jvdelisle Date: Mon Mar 7 03:08:08 2011 New Revision: 170732 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170732 Log: 2011-03-06 Jakub Jelinek ja...@redhat.com Backport from mainline PR fortran/47878 * io/transfer.c (read_sf): Call fbuf_getptr only at the end, and subtract n, dtp-u.p.sf_seen_eor and seen_comma from it. 2011-03-06 Janne Blomqvist j...@gcc.gnu.org Jerry DeLislejvdeli...@gcc.gnu.org Backport from mainline PR libfortran/47694 * io/io.h (fbuf_getptr): New inline function. * io/transfer.c (read_sf): Use fbuf_getptr and fbuf_getc to scan through the string instead of fbuf_read. Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/io.h branches/gcc-4_4-branch/libgfortran/io/transfer.c
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #28 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-07 03:08:12 UTC --- Author: jvdelisle Date: Mon Mar 7 03:08:08 2011 New Revision: 170732 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170732 Log: 2011-03-06 Jakub Jelinek ja...@redhat.com Backport from mainline PR fortran/47878 * io/transfer.c (read_sf): Call fbuf_getptr only at the end, and subtract n, dtp-u.p.sf_seen_eor and seen_comma from it. 2011-03-06 Janne Blomqvist j...@gcc.gnu.org Jerry DeLislejvdeli...@gcc.gnu.org Backport from mainline PR libfortran/47694 * io/io.h (fbuf_getptr): New inline function. * io/transfer.c (read_sf): Use fbuf_getptr and fbuf_getc to scan through the string instead of fbuf_read. Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/io.h branches/gcc-4_4-branch/libgfortran/io/transfer.c
[Bug fortran/47878] [4.6 Regression] 187.facerec miscompares
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47878 --- Comment #29 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-07 03:14:03 UTC --- Author: jvdelisle Date: Mon Mar 7 03:14:00 2011 New Revision: 170733 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170733 Log: 2011-03-06 Jerry DeLisle jvdeli...@gcc.gnu.org Backport from mainline PR libgfortran/47878 * gfortran.dg/pr47878.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr47878.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #29 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-07 03:16:33 UTC --- Fixed on 4.4, 4.5, and 4.6. Closing
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #30 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-07 03:17:17 UTC --- Closing
[Bug fortran/48011] internal compiler error:tree check: expected function_type or method_type, have pointer_type in gimplify_call_expr at gimplify.c:2355
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48011 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org Severity|blocker |normal --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-07 03:21:36 UTC --- Fortran bugs are never considered blocker which refers to blocking gcc itself
[Bug fortran/47984] Pointer dummy argument mismatch not detected by Fortran compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47984 --- Comment #6 from Thomas Henlich thenlich at users dot sourceforge.net 2011-03-07 06:26:24 UTC --- RTFM, I should have. Thank you for your help.
[Bug ada/48012] New: The executable file hangs up by combination of controlled-type, generic, renames and Inline_Always
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48012 Summary: The executable file hangs up by combination of controlled-type, generic, renames and Inline_Always Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: demoon...@panathenaia.halfmoon.jp Created attachment 23564 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23564 minimal bug triggering source code My application hangs up conpilied with gcc-4.5.2. 1. declare a controlled-type (named T) as private. 2. declare a generic function (named G) return T. 3. instantiate G. 4. declare a function (named F) renames it, and write pramga Inline_Always. 5. call F, it may hang up! Probably, an object of T is attached to a finalization list, twice. -- iacm.adb with iact; with iacp; procedure iacm is X : iact.T := iacp.F; -- hang up !! begin null; end iacm; -- iact.ads with Ada.Finalization; package iact is type T is private; -- hidden controll type generic function G return T; private type T is new Ada.Finalization.Controlled with null record; end iact; -- iact.adb package body iact is function G return T is begin return (Ada.Finalization.Controlled with null record); end G; end iact; -- iacp.ads with iact; package iacp is function F return iact.T; pragma Inline_Always (F); -- this pragma causes hang up private function G is new iact.G; function F return iact.T renames G; end iacp; % gnatmake iacm gcc -c iacm.adb gcc -c iacp.ads gcc -c iact.adb gnatbind -x iacm.ali gnatlink iacm.ali % ./iacm ( hang up !! )
