[Bug tree-optimization/28868] [4.0/4.1/4.2/4.3 Regression] Not eliminating the PHIs which have the same arguments
--- Comment #12 from sebpop at gmail dot com 2007-11-05 06:13 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] Not elimintating the PHIs which have the same arguments > Replacing ssa names with other ssa names willy-nilly is not always a > win. We eventually ended up with heuristics to not change loop depths > of ssa names, etc. > See also PR23821, where we reach the exact same conclusion: DOM and VRP are playing the replace SSA_NAMEs game, and we're losing to this game as the substitution is done randomly... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #41 from amodra at bigpond dot net dot au 2007-11-05 04:45 --- In reply to #27, I'm reasonably happy with the idea of ld treating a zero offset into a discarded section as special. I'd also happily approve a patch that allowed relocations with addends against any local symbol (except for the section symbol) in a discarded section so long as the symbol value in the kept section was the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #39 from geoffk at geoffk dot org 2007-11-05 03:33 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 04/11/2007, at 7:01 PM, hjl at lucon dot org wrote: >> - Won't this cause the global variable to be discarded if anyone >> defines a different global variable which also references the same >> string? > > The comdat group should have both global variables defined. I'm talking about static char * some_variable = "hi there"; and in some other file static char * some_variable = "hi there"; the compiler does not know that there are two files containing 'some_variable', and they have to be different variables (someone might change one of them and the other should not change if that happens), but the two "hi there" strings should be shared. How should the compiler represent this in ELF? --- Comment #40 from geoffk at geoffk dot org 2007-11-05 03:33 --- Created an attachment (id=14485) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14485&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33969] [4.2/4.3 regression] ICE with const and function pointer
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33969
[Bug c++/33894] [4.3 Regression] pragma omp atomic broken
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33894
[Bug tree-optimization/33856] [4.3 Regression] Segfault in create_data_ref/compute_data_dependences_for_loop
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33856
gcc-bugs@gcc.gnu.org
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33836
[Bug debug/33739] [4.3 Regression] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
[Bug target/33923] [4.3 Regression] ICE in reload_cse_simplify_operands (insn does not satisfy its constraints)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33923
[Bug rtl-optimization/33732] [4.3 Regression] gcc.c-torture/execute/longlong.c execution at -O3
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33732
[Bug tree-optimization/33870] [4.3 Regression] miscompiles sqlite
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33870
[Bug bootstrap/33781] [4.3 Regression] "Arg list too long" building libgcc.a
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug c++/33984] [4.2/4.3 Regression] bit-fields, references and overloads
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33984
[Bug tree-optimization/33953] [4.3 regression] internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_operation at tree-vect-transform.c:4017
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33953
[Bug tree-optimization/33931] [4.3 Regression] ICE: tree check: expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:566
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33931
[Bug rtl-optimization/33922] [4.3 Regression] slow compilation on ia64 (postreload scheduling)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33922
[Bug middle-end/33989] Extra load/store for float with union
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-05 03:09 --- So if I have emit_move_insn not to produce: (insn 10 9 11 3 t1.c:10 (set (subreg:SF (reg/v:SI 119 [ c ]) 0) (reg:SF 123)) -1 (nil)) but instead: (insn 10 9 11 3 t1.c:10 (set (reg/v:SI 119 [ c ]) (subreg:SI (reg:SF 123) 0)) -1 (nil)) I could not get the (subreg:SI (reg:SF 123) 0) propgated into (insn 11 10 16 3 t1.c:11 (set (mem:SI (reg/v/f:DI 121 [ b ]) [3 S4 A32]) (reg/v:SI 119 [ c ])) -1 (nil)) I have not figured out why yet. Once that is done, we can have simplify_set in combine change the modes of the mem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33989
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #38 from hjl at lucon dot org 2007-11-05 03:03 --- (In reply to comment #37) > (In reply to comment #35) > > > > > > - What if the global variable references two or more strings? > > All local strings referenced by the global variable should be > in the same comdat group. > It should be "all ocal strings referenced by the global variable should be defined in either the same comdat group or a non-comdat section." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #37 from hjl at lucon dot org 2007-11-05 03:01 --- (In reply to comment #35) > > > - What if the global variable references two or more strings? All local strings referenced by the global variable should be in the same comdat group. > - Won't this cause the global variable to be discarded if anyone > defines a different global variable which also references the same > string? The comdat group should have both global variables defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33826
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #36 from hjl at lucon dot org 2007-11-05 02:50 --- The rules for the comdat group are 1. There should be no outside references to local symbols inside of the comdat group. 2. All comdat groups with the same signature should have the identical set of defined global symbols. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug tree-optimization/33763] [4.1/4.2/4.3 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
[Bug middle-end/33713] [4.3 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #35 from geoffk at geoffk dot org 2007-11-05 02:47 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 04/11/2007, at 4:22 PM, hjl at lucon dot org wrote: > --- Comment #33 from hjl at lucon dot org 2007-11-05 00:22 > --- > (In reply to comment #32) >> >> What if you want to reference this string from somewhere that should >> never be discarded, like a global variable? >> > > Since the string is local, that global variable is defined in > the same file as the string. You should put the global variable > in a section which belongs to the same comdat group as the local > string. - What if the global variable references two or more strings? - Won't this cause the global variable to be discarded if anyone defines a different global variable which also references the same string? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680
[Bug tree-optimization/33993] [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33993
[Bug c++/33977] [4.3 Regression] internal compiler error: canonical types differ for identical types const char [5] and const sal_Char [5]
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33977
[Bug c++/33838] [4.3 regresssion] ICE with invalid use of decltype
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33838
[Bug c++/33837] [4.3 regresssion] ICE with invalid use of decltype
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33837
[Bug debug/33822] [4.1/4.2/4.3 Regression] -g -O -mstrict-align causes an ICE in set_variable_part,
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33822
[Bug middle-end/33737] [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94->1 -6651
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33737
[Bug c++/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug c++/33996] C++0x: move overloading problem with move constructor and copy constructor
--- Comment #1 from pcarlini at suse dot de 2007-11-05 01:28 --- Forgot, I said "more" because maybe related to PR33235 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33996
[Bug c++/33996] New: C++0x: move overloading problem with move constructor and copy constructor
More crazy issues here, blocking meaningful work :(
Consider the below: it doesn't compile, tries to use the move constructor. If I
define bar in class then things work. Seems kind of broken optimization.
struct type
{
type() { }
type(const type&) { }
private:
type(type&&);
};
template
struct identity
{
typedef _Tp type;
};
template
inline _Tp&&
forward(typename identity<_Tp>::type&& __t)
{ return __t; }
struct vec
{
template
void
bar(_Args&& __args);
/*
{
type(forward<_Args>(__args));
}
*/
};
template
void
vec::bar(_Args&& __args)
{
type(forward<_Args>(__args));
}
int main()
{
vec v;
type c;
v.bar(c);
}
--
Summary: C++0x: move overloading problem with move constructor
and copy constructor
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33996
[Bug c/33995] C89 warning on inline keyword when using -std=c99 or -std=gnu99
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-05 01:05 --- No, what it is trying to say 4.2.x does not support fully C99 inline and that the inline keyword will change in the future to be correct with -std=c99. This has already been fixed in 4.3.0 where extern inline and inline works correctly in C99 mode. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33995
[Bug c/33995] New: C89 warning on inline keyword when using -std=c99 or -std=gnu99
Consider following trivial C program:
inline int func (int x) { return x + 3 ; }
int main (void) { return func (2) ; }
Compiling with:
gcc -std=c99 file.c -o prog
or
gcc -std=gnu99 file.c -o prog
results in the warning message:
warning: C99 inline functions are not supported; using GNU89
warning: to disable this warning use -fgnu89-inline or the gnu_inline
function attribute
The message states that inline functions are not supported using GNU89, but I
am specifically using -std of c99 and gnu99 so therefore I believe there should
be no warning.
--
Summary: C89 warning on inline keyword when using -std=c99 or -
std=gnu99
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-erikd at mega-nerd dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33995
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #34 from hjl at lucon dot org 2007-11-05 00:32 --- (In reply to comment #33) > (In reply to comment #32) > > > > What if you want to reference this string from somewhere that should > > never be discarded, like a global variable? > > > > Since the string is local, that global variable is defined in > the same file as the string. You should put the global variable > in a section which belongs to the same comdat group as the local > string. > You should also put that global variable in the same comat group in all files where that comdat group is generated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #33 from hjl at lucon dot org 2007-11-05 00:22 --- (In reply to comment #32) > > What if you want to reference this string from somewhere that should > never be discarded, like a global variable? > Since the string is local, that global variable is defined in the same file as the string. You should put the global variable in a section which belongs to the same comdat group as the local string. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #32 from geoffk at geoffk dot org 2007-11-05 00:14 --- Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in discarded section On 04/11/2007, at 6:40 AM, hjl at lucon dot org wrote: > --- Comment #31 from hjl at lucon dot org 2007-11-04 14:40 > --- > (In reply to comment #30) >> Subject: Re: [4.3 Regression] typeinfo name referenced in ... >> defined in >> discarded section >> >> On 03/11/2007, at 7:21 AM, hjl at lucon dot org wrote: >> >>> Local symbols should only be referenced within the same comdat group >>> or the linkonce section. Otherwise, it is a compiler bug. >> >> How do you represent, in ELF, a string which should be present in the >> executable only once, but which need not have a globally visible >> name? >> > > You can put it in a comdat group. But you should only reference it > from the > same comdat group. A comdat group is a set of sections which have the > same signature. What if you want to reference this string from somewhere that should never be discarded, like a global variable? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug c/29237] Failure to appropriately qualify C99 pointer decayed from array parameter
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-05 00:08 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29237
[Bug c/29237] Failure to appropriately qualify C99 pointer decayed from array parameter
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-05 00:08 --- Subject: Bug 29237 Author: pinskia Date: Mon Nov 5 00:08:04 2007 New Revision: 129888 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129888 Log: Index: ChangeLog === --- ChangeLog (revision 129887) +++ ChangeLog (working copy) @@ -6447,6 +6447,7 @@ 2007-09-02 Joseph Myers <[EMAIL PROTECTED]> + PR c/29237 PR middle-end/33272 * c-decl.c (grokdeclarator): Apply qualifiers to type of parameter decayed from array. Index: testsuite/ChangeLog === --- testsuite/ChangeLog (revision 129887) +++ testsuite/ChangeLog (working copy) @@ -3041,6 +3041,7 @@ 2007-09-02 Joseph Myers <[EMAIL PROTECTED]> + PR C/29237 PR middle-end/33272 * gcc.dg/c99-arraydecl-3.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29237
[Bug middle-end/33272] Compiler does not take advantage of restrict
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-05 00:08 --- Subject: Bug 33272 Author: pinskia Date: Mon Nov 5 00:08:04 2007 New Revision: 129888 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129888 Log: Index: ChangeLog === --- ChangeLog (revision 129887) +++ ChangeLog (working copy) @@ -6447,6 +6447,7 @@ 2007-09-02 Joseph Myers <[EMAIL PROTECTED]> + PR c/29237 PR middle-end/33272 * c-decl.c (grokdeclarator): Apply qualifiers to type of parameter decayed from array. Index: testsuite/ChangeLog === --- testsuite/ChangeLog (revision 129887) +++ testsuite/ChangeLog (working copy) @@ -3041,6 +3041,7 @@ 2007-09-02 Joseph Myers <[EMAIL PROTECTED]> + PR C/29237 PR middle-end/33272 * gcc.dg/c99-arraydecl-3.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33272
[Bug c++/33990] bug in lookup of member template conversion operator for pointer to member functions
--- Comment #1 from sutambe at yahoo dot com 2007-11-05 00:05 --- Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33990
[Bug c++/33934] access control bug in member function templates
--- Comment #1 from sutambe at yahoo dot com 2007-11-05 00:04 --- Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33934
[Bug middle-end/33970] Missed optimization using unsigned char loop variable
-- eweddington at cso dot atmel dot com changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2007-11-04 23:28:15 |2007-11-04 23:28:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33970
[Bug middle-end/33970] Missed optimization using unsigned char loop variable
--- Comment #7 from eweddington at cso dot atmel dot com 2007-11-04 23:28 --- With Mike's description in comment #6, confirmed on 4.1.2 and 4.2.2. AVR GCC 4.2.2 is worse than 4.1.2, in that even if sub2 is called with (x+1), the variable is still 16 bits. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Known to fail||4.1.2 4.2.2 Last reconfirmed|-00-00 00:00:00 |2007-11-04 23:28:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33970
[Bug ada/33994] wrong code for indexed component when index subtype has 'Size > 32
--- Comment #2 from bauhaus at futureapps dot de 2007-11-04 23:02 --- Side note: With a special command line, this program triggers a bug box with gcc 4.1.3 (Ubuntu 7.10 i686). $ gnatmake -W -S -march=x86-64 -m64 -Os too_big.adb gcc-4.1 -c -W -S -march=x86-64 -m64 -Os too_big.adb +===GNAT BUG DETECTED==+ | 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu3) (i486-pc-linux-gnu) GCC error:| | in pro_epilogue_adjust_stack, at config/i386/i386.c:5094 | | Error detected at too_big.adb:41:5 | | 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-4.1 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. too_big.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 gnatmake: "too_big.adb" compilation error I cannot currently check this with a 4.3 compiler because when I configure ... --enable-targets=all, I get make[8]: Entering directory `/home/georg/src/build/i686-pc-linux-gnu/64/libmudflap' if /bin/bash ./libtool --tag=CC --mode=compile /home/georg/src/build/./gcc/xgcc -B/home/georg/src/build/./gcc/ -B/opt/GCC/43/i686-pc-linux-gnu/bin/ -B/opt/GCC/43/i686-pc-linux-gnu/lib/ -isystem /opt/GCC/43/i686-pc-linux-gnu/include -isystem /opt/GCC/43/i686-pc-linux-gnu/sys-include -m64 -DHAVE_CONFIG_H -I. -I../../../../gcc/libmudflap -I.-Wall -ffunction-sections -fdata-sections -O2 -g -O2-m64 -MT mf-runtime.lo -MD -MP -MF ".deps/mf-runtime.Tpo" -c -o mf-runtime.lo ../../../../gcc/libmudflap/mf-runtime.c; \ then mv -f ".deps/mf-runtime.Tpo" ".deps/mf-runtime.Plo"; else rm -f ".deps/mf-runtime.Tpo"; exit 1; fi libtool: compile: /home/georg/src/build/./gcc/xgcc -B/home/georg/src/build/./gcc/ -B/opt/GCC/43/i686-pc-linux-gnu/bin/ -B/opt/GCC/43/i686-pc-linux-gnu/lib/ -isystem /opt/GCC/43/i686-pc-linux-gnu/include -isystem /opt/GCC/43/i686-pc-linux-gnu/sys-include -m64 -DHAVE_CONFIG_H -I. -I../../../../gcc/libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g -O2 -m64 -MT mf-runtime.lo -MD -MP -MF .deps/mf-runtime.Tpo -c ../../../../gcc/libmudflap/mf-runtime.c -fPIC -DPIC -o .libs/mf-runtime.o ../../../../gcc/libmudflap/mf-runtime.c:172: error: conflicting types for '__mf_lc_mask' ../../../../gcc/libmudflap/mf-runtime.h:51: error: previous declaration of '__mf_lc_mask' was here ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33994
[Bug ada/33994] wrong code for indexed component when index subtype has 'Size > 32
--- Comment #1 from bauhaus at futureapps dot de 2007-11-04 22:55 --- $ S$ uname -a Linux K72 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux $ gnatmake -save-temps -gnata -gnato -gnatwa -S too_big.adb -cargs -v -largs -v gcc -c -save-temps -gnata -gnato -gnatwa -S -v too_big.adb Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/opt/GCC/43 --enable-languages=c,ada,fortran Thread model: posix gcc version 4.3.0 20071104 (experimental) (GCC) COLLECT_GCC_OPTIONS='-c' '-save-temps' '-gnata' '-gnato' '-gnatwa' '-S' '-v' '-gnatez' '-mtune=generic' /opt/GCC/43/libexec/gcc/i686-pc-linux-gnu/4.3.0/gnat1 -quiet -dumpbase too_big.adb -gnata -gnato -gnatwa -gnatez -mtune=generic too_big.adb -o too_big.s COMPILER_PATH=/opt/GCC/43/libexec/gcc/i686-pc-linux-gnu/4.3.0/:/opt/GCC/43/libexec/gcc/i686-pc-linux-gnu/4.3.0/:/opt/GCC/43/libexec/gcc/i686-pc-linux-gnu/:/opt/GCC/43/lib/gcc/i686-pc-linux-gnu/4.3.0/:/opt/GCC/43/lib/gcc/i686-pc-linux-gnu/ LIBRARY_PATH=/opt/GCC/43/lib/gcc/i686-pc-linux-gnu/4.3.0/:/opt/GCC/43/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-c' '-save-temps' '-gnata' '-gnato' '-gnatwa' '-S' '-v' '-gnatez' '-mtune=generic' gnatbind -x too_big.ali gnatlink too_big.ali -v GNATLINK 4.3.0 20071104 (experimental) Copyright (C) 1995-2007, Free Software Foundation, Inc. gcc -c -gnatA -gnatWb -gnatiw -gnatws b~too_big.adb /opt/GCC/43/bin/gcc b~too_big.o ./too_big.o -o too_big -L./ -L/opt/GCC/43/lib/gcc/i686-pc-linux-gnu/4.3.0/adalib/ /opt/GCC/43/lib/gcc/i686-pc-linux-gnu/4.3.0/adalib/libgnat.a -static-libgcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33994
[Bug ada/33994] New: wrong code for indexed component when index subtype has 'Size > 32
The given program can be translated and run and it then produces incorrect results (details below). Indeed, some circuits from the GNAT front end seem to indicate an error (use debugging switch -gnatdF to see this). Also, using -fstack-check adds a warning that a frame is too large. The assembly listing shows -1 off %ebp for the second pair of assigments to Fst/Lst, this seems wrong. The pairs of consequtive instructions correspond to assignments in the respective blocks: movb$33, -10002(%ebp) movb$63, -2(%ebp) ... movb$33, -1(%ebp) movb$63, -1(%ebp) $ ./too_big !? ?? To reproduce, $ gnatmake -save-temps -gnata -gnato -gnatwa -S too_big.adb with Ada.Text_IO; procedure Too_Big is use Ada; type Big_Index is range 0 .. 2**50; type A is array (Big_Index range <>) of Character; begin -- output is "!?" declare X: A (Big_Index range 2**40 .. 2**40 + 10_000); Fst: Character renames X(X'First); Lst: Character renames X(X'Last); begin Fst := '!'; Lst := '?'; Text_IO.Put(Fst); Text_IO.Put(Lst); Text_IO.New_Line; end; -- output is "??" declare X: A (Big_Index range 2**40 .. 2**48); Fst: Character renames X(X'First); Lst: Character renames X(X'Last); begin Fst := '!'; Lst := '?'; pragma assert(Fst = '!'); Text_IO.Put(Fst); Text_IO.Put(Lst); Text_IO.New_Line; end; end Too_Big; -- Summary: wrong code for indexed component when index subtype has 'Size > 32 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bauhaus at futureapps dot de 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=33994
[Bug tree-optimization/33993] [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-04 22:23 ---
I think this is just a bug in the checking system:
if (!CONSTANT_CLASS_P (t) && !is_gimple_lvalue (t))
{
error ("invalid reference prefix");
return t;
}
CONSTANT_CLASS_P is going to be false for CONSTRUCTOR but this is a constant as
the elements are all constant.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33993
[Bug tree-optimization/33993] [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix)
--- Comment #2 from tbm at cyrius dot com 2007-11-04 22:05 --- Created an attachment (id=14484) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14484&action=view) vectorizer's dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33993
[Bug tree-optimization/33993] [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix)
--- Comment #1 from tbm at cyrius dot com 2007-11-04 22:03 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
void init_full (char *array, int ny)
{
int j;
char acc = 128;
for (j = 0; j < ny; j++)
*array++ = acc++;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33993
[Bug tree-optimization/33993] New: [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix)
With trunk from 20070916 and 20071030 on sparc:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 -ftree-vectorize
hdf5-hyperslab.c
hdf5-hyperslab.c: In function 'init_full':
hdf5-hyperslab.c:4: error: invalid reference prefix
{4, 4, 4, 4}
hdf5-hyperslab.c:4: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: [4.3 Regression] ICE: verify_stmts failed (invalid
reference prefix)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33993
[Bug middle-end/23848] [4.0/4.1/4.2/4.3 Regression] stack deallocation can be more efficient
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-04 21:35 ---
I'll be testing the following patch. It is quite simplistic, in that it will
give up on bb boundaries, still it should IMHO trigger in quite a lot of cases.
Each optimized out pair of __builtin_stack_save/__builtin_stack_restore will
typically save one call saved register (resp. memory slot if we run out of
them).
--- tree-ssa-ccp.c.jj10 2007-09-04 23:09:30.0 +0200
+++ tree-ssa-ccp.c 2007-11-04 22:16:03.0 +0100
@@ -2598,6 +2598,76 @@ fold_stmt_inplace (tree stmt)
return changed;
}
+/* Try to optimize out __builtin_stack_restore. Optimize it out
+ if there is another __builtin_stack_restore in the same basic
+ block and no calls or ASM_EXPRs are in between, or if this block's
+ only outgoing edge is to EXIT_BLOCK and there are no calls or
+ ASM_EXPRs after this __builtin_stack_restore. */
+
+static tree
+optimize_stack_restore (basic_block bb, tree call, block_stmt_iterator i)
+{
+ tree stack_save, stmt, callee;
+
+ if (TREE_CODE (call) != CALL_EXPR
+ || call_expr_nargs (call) != 1
+ || TREE_CODE (CALL_EXPR_ARG (call, 0)) != SSA_NAME
+ || !POINTER_TYPE_P (TREE_TYPE (CALL_EXPR_ARG (call, 0
+return NULL_TREE;
+
+ for (bsi_next (&i); !bsi_end_p (i); bsi_next (&i))
+{
+ tree stmt = bsi_stmt (i);
+ tree call;
+
+ if (TREE_CODE (stmt) == ASM_EXPR)
+ return NULL_TREE;
+ call = get_call_expr_in (stmt);
+ if (call == NULL)
+ continue;
+
+ callee = get_callee_fndecl (call);
+ if (!callee || DECL_BUILT_IN_CLASS (callee) != BUILT_IN_NORMAL)
+ return NULL_TREE;
+
+ if (DECL_FUNCTION_CODE (callee) == BUILT_IN_STACK_RESTORE)
+ break;
+}
+
+ if (bsi_end_p (i)
+ && (! single_succ_p (bb)
+ || single_succ_edge (bb)->dest != EXIT_BLOCK_PTR))
+return NULL_TREE;
+
+ stack_save = SSA_NAME_DEF_STMT (CALL_EXPR_ARG (call, 0));
+ if (TREE_CODE (stack_save) != GIMPLE_MODIFY_STMT
+ || GIMPLE_STMT_OPERAND (stack_save, 0) != CALL_EXPR_ARG (call, 0)
+ || TREE_CODE (GIMPLE_STMT_OPERAND (stack_save, 1)) != CALL_EXPR
+ || tree_could_throw_p (stack_save)
+ || !has_single_use (CALL_EXPR_ARG (call, 0)))
+return NULL_TREE;
+
+ callee = get_callee_fndecl (GIMPLE_STMT_OPERAND (stack_save, 1));
+ if (!callee
+ || DECL_BUILT_IN_CLASS (callee) != BUILT_IN_NORMAL
+ || DECL_FUNCTION_CODE (callee) != BUILT_IN_STACK_SAVE
+ || call_expr_nargs (GIMPLE_STMT_OPERAND (stack_save, 1)) != 0)
+return NULL_TREE;
+
+ stmt = stack_save;
+ push_stmt_changes (&stmt);
+ if (!set_rhs (&stmt,
+ build_int_cst (TREE_TYPE (CALL_EXPR_ARG (call, 0)), 0)))
+{
+ discard_stmt_changes (&stmt);
+ return NULL_TREE;
+}
+ gcc_assert (stmt == stack_save);
+ pop_stmt_changes (&stmt);
+
+ return integer_zero_node;
+}
+
/* Convert EXPR into a GIMPLE value suitable for substitution on the
RHS of an assignment. Insert the necessary statements before
iterator *SI_P.
@@ -2682,6 +2752,12 @@ execute_fold_all_builtins (void)
result = integer_zero_node;
break;
+ case BUILT_IN_STACK_RESTORE:
+ result = optimize_stack_restore (bb, *stmtp, i);
+ if (result)
+ break;
+ /* FALLTHRU */
+
default:
bsi_next (&i);
continue;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23848
[Bug fortran/33698] FAIL: gfortran.dg/gamma_5.f90
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-04 21:30 --- Subject: Re: FAIL: gfortran.dg/gamma_5.f90 > The main problem with the Lanczos approximation are alternating-sign > terms with nearly cancel each other, which leads to massive precision > loss. > > For z=16.5 and r=10.900511, the terms in the sum are > > 1 6425.81075191694890236249 > 2 -19919.53511610527857556008 > 3 24595.63902224190678680316 > 4 -15425.21437829293790855445 > 5 5196.45802113903846475296 > 6 -916.60901318718765651283 > 7 76.62541745991659070114 > 8 -2.45417886377221794447 > 90.01907340042601936639 > 10 -0.1080118945830201 > > and the sum is > > 33.24621718250205049117 > > so I'd expect about log2(24000/33) ~ 9.5 bits of precision loss. > Not good. I don't think this can be avoided without a huge performance hit (i.e., use long double arithmetic for the sum). Possibly, the float versions would benefit from doing the sum with doubles. That shouldn't hurt. > Some rearrangement can help here, possibly. OTOH, maybe using > straight Netlib code would be better. On systems with lgamma, it's possible to use exp (lgamma (x)) for tgamma (x). I checked and gamma_5 doesn't fail on HP-UX with this implementation. I retained the transformation for negative arguments. Float variants could easily be implemented using lgamma. I think using the system lgamma implementation might be best when it's available. Found an old fortran implementation on one of my machines! I believe that I wrote an implementation using a rational approximation (Pade?) about 35 years ago, but I couldn't find it. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) double precision function dgamma(z) c c Source for routine: J.F. Hart et al, Computer Approximations, c Wiley,1968. c This is a double precision routine for the gamma function of c real positive arguments. Values for negative arguments (non- c integral or zero) may be obtained from this program and c standard functional relations for the gamma function. c argument range method of computation c z>14 gamma(z)=dexp(ln(gamma(z)) c 3<= z <=14argument reduction z*gam(z)=gam(z+1) c 2<= z <3 rational approx. w/o argument reduction c 0< z <2 argument expansion z*gam(z)=gam(z+1) c implicit double precision (a-h,o-z) c double precision nlsqp c dimension pnum(11),qden(11),phnum(4),qhden(4) c data pnum,qden,phnum,qhden/ 1-.2983543278574342138830437659d+6, 2-.2384953970018198872468734423d+6, 3-.1170494760121780688403854445d+6, 4-.3949445048301571936421824091d+5, 5-.1046699423827521405330650531d+5, 6-.2188218110071816359394795998d+4, 7-.3805112208641734657584922631d+3, 8-.5283123755635845383718978382d+2, 9-.6128571763704498306889428212d+1, 9-.502801805441681246736419875d00, 9-.3343060322330595274515660112d-1, 1-.2983543278574342138830438524d+6, 2-.1123558608748644911342306408d+6, 3+.5332716689118142157485686311d+5, 4+.8571160498907043851961147763d+4, 5-.473486597702821170655681977d+4, 6+.1960497612885585838997039621d+3, 7+.1257733367869888645966647426d+3, 8-.2053126153100672764513929067d+2, 9+.1d1, 90.d0, 90.d0, 1+.12398282342474941538685913d0, 2+.670827838343321349614617d0, 3+.6450730291289920251389d0, 4+.29070402007526d-1, 1+.148779388109699298468156d+1, 2+.809952718948975574728214d+1, 3+.7996691123663644194772d+1, 4+.1d1/ c az=z pi=4.d0*datan(1.d0) accum=1.d0 if (az.gt.14.d0) go to 44 if (az.lt.2.d0) go to 333 if (az.lt.3.d0) go to 33 do 22 i=1,12 az=az-1.d0 accum=accum*az if (az.lt.3.d0) go to 33 22 continue 333 do 222 i=1,12 accum=accum*(1.d0/az) az=az+1.d0 if (az.ge.2.d0) go to 33 222 continue 33 az=az-2.d0 anum=0.d0 aden=0.d0 do 11 i=0,10 ii=i+1 if (i.eq.0) power=1.d0 if (i.eq.0) go to 55 power=az**i 55 anum=anum+pnum(ii)*power aden=aden+qden(ii)*power 11 continue dgamma=accum*(anum/aden) go to 999 44 anum=0.d0 aden=0.d0 do 1 i=0,3 ii=i+1 if (i.eq.0) power=1.d0 if (i.eq.0) go to 5 power=(1.d0/(az*az))**i 5 anum=anum+phnum(ii)*power aden=aden+qhden(ii)*power 1 continue riemn=anum/(aden*az) nlsqp=dlog(dsqrt(2.d0*pi)) daleg=(az-0.5d0)*dlog(az)-az+nlsqp+riemn dgamma=dexp(daleg) 999 return end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33698
[Bug libfortran/33863] backspace error on i386-pc-mingw32
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-11-04 21:25 --- OK, I have taken some time to investigate this. The problem is not MSYS specific and also occurs with Cygwin. I do not think we can fix this. Its not a gfortran bug. The code is attempting to backspace a standard input stream. You can not seek backwards on an input stream. The code happens to work in some cases because input buffering happens to still contain the relevant data. Gfortran buffering hides the stream but you can not rely on it depending on how far you have to backspace If I modify the code slightly and open the input file directly, it works without error. This tels me its not a CR-LF issue. Any other opinions? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33863
[Bug c++/33939] Rvalue references not deduced correctly in vararg function templates
--- Comment #1 from pcarlini at suse dot de 2007-11-04 20:41 ---
Gosh, this bug is horrible, the -basic- forwarding situation doesn't work with
variadic templates:
void foo(int&&);
void foo(const int&) { }
template
struct identity
{
typedef _Tp type;
};
template
inline _Tp&&
forward(typename identity<_Tp>::type&& __t)
{ return __t; }
template
void
bar(_Args&& __args)
{
foo(forward<_Args>(__args));
}
template
void
barv(_Args&&... __args)
{
foo(forward<_Args>(__args)...);
}
int main()
{
int a;
bar(a);
barv(a);
}
Doug, any chance you can have a look? Many thanks in advance!
--
pcarlini at suse dot de changed:
What|Removed |Added
CC||pcarlini at suse dot de
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-11-04 20:41:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33939
[Bug fortran/33698] FAIL: gfortran.dg/gamma_5.f90
--- Comment #18 from tkoenig at gcc dot gnu dot org 2007-11-04 19:51 --- > Looking at Pugh's paper, he shows coefficients for n = 10 and > r = 10.900511. This is the same as you are using for the double > case. However, you seem to be missing coefficient d10. Good catch, thanks! The main problem with the Lanczos approximation are alternating-sign terms with nearly cancel each other, which leads to massive precision loss. For z=16.5 and r=10.900511, the terms in the sum are 1 6425.81075191694890236249 2 -19919.53511610527857556008 3 24595.63902224190678680316 4 -15425.21437829293790855445 5 5196.45802113903846475296 6 -916.60901318718765651283 7 76.62541745991659070114 8 -2.45417886377221794447 90.01907340042601936639 10 -0.1080118945830201 and the sum is 33.24621718250205049117 so I'd expect about log2(24000/33) ~ 9.5 bits of precision loss. Not good. Some rearrangement can help here, possibly. OTOH, maybe using straight Netlib code would be better. Ouch. Maybe it's better to fall back on the Netlib code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33698
[Bug tree-optimization/28868] [4.0/4.1/4.2/4.3 Regression] Not elimintating the PHIs which have the same arguments
--- Comment #11 from dberlin at gcc dot gnu dot org 2007-11-04 19:24 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] Not elimintating the PHIs which have the same arguments On 4 Nov 2007 15:45:59 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #10 from rguenth at gcc dot gnu dot org 2007-11-04 15:45 > --- > FRE doesn't replace a SSA_NAME with another SSA_NAME Also true. It will only replace non-ssa names with ssa-names. This is to avoid lengthening the range of variables. Replacing ssa names with other ssa names willy-nilly is not always a win. We eventually ended up with heuristics to not change loop depths of ssa names, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug middle-end/32931] FORALL and WHERE give an ICE with -m64
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-11-04 19:05 --- All fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32931
[Bug middle-end/32931] FORALL and WHERE give an ICE with -m64
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-04 19:05 --- Subject: Bug 32931 Author: pinskia Date: Sun Nov 4 19:04:49 2007 New Revision: 129886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129886 Log: 2007-11-04 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/32931 * fold-const.c (fold_binary ): Convert the inner type for TRUTH_NOT_EXPR to type. 2007-11-04 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/32931 * gfortran.fortran-torture/compile/forall-1.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/forall-1.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32931
[Bug target/28102] [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #24 from samuel dot thibault at ens-lyon dot org 2007-11-04 16:42 --- It's rather the converse: Linux is much like Hurd, since they're both GNU-based, so quite logically they should share most of the configuration stuff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug tree-optimization/31914] FRE does not do const or copy propagation while it could
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-04 15:51 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-04 15:51:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31914
[Bug tree-optimization/28868] [4.0/4.1/4.2/4.3 Regression] Not elimintating the PHIs which have the same arguments
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-11-04 15:45 --- FRE doesn't replace a SSA_NAME with another SSA_NAME. So even though VN figured that e_3 == d_2 == c_1 it doesn't replace them here: SCCVN says e_3 value numbers to c_1 (VH.5) SCCVN says d_2 value numbers to c_1 (VH.5) : # e_3 = PHI # d_2 = PHI # c_1 = PHI D.1182_13 = c_1 + d_2; D.1181_14 = D.1182_13 + e_3; the next copyprop pass makes them look the same: : # e_3 = PHI # d_2 = PHI # c_1 = PHI D.1182_13 = c_1 + d_2; D.1181_14 = D.1182_13 + e_3; return D.1181_14; but that's it. See also PR31914. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org BugsThisDependsOn||31914 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug target/26290] [4.1/4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-11-04 14:53 --- Yes, I looked at i386 and i686 tuned code as well (which gets the addl), the core2 tuning has this fixed (I didn't measure on AMD CPUs). As both 4.1 and 4.2 are way into maintainance mode and the patch which fixed this has not been identified yet this indeed has only minor chances of getting fixed for 4.1 or 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug fortran/10220] attribute DW_AT_calling_convention not correct for fortran
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-04 14:46 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10220
[Bug fortran/10220] attribute DW_AT_calling_convention not correct for fortran
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-04 14:44 --- Subject: Bug 10220 Author: fxcoudert Date: Sun Nov 4 14:43:45 2007 New Revision: 129882 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129882 Log: PR fortran/10220 * dwarf2out.c (add_calling_convention_attribute): Change second argument. Set calling convention to DW_CC_program for Fortran main program. (gen_subprogram_die): Adjust to new prototype for add_calling_convention_attribute. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10220
[Bug c++/33871] [4.3 Regression] typeinfo name referenced in ... defined in discarded section
--- Comment #31 from hjl at lucon dot org 2007-11-04 14:40 --- (In reply to comment #30) > Subject: Re: [4.3 Regression] typeinfo name referenced in ... defined in > discarded section > > On 03/11/2007, at 7:21 AM, hjl at lucon dot org wrote: > > > Local symbols should only be referenced within the same comdat group > > or the linkonce section. Otherwise, it is a compiler bug. > > How do you represent, in ELF, a string which should be present in the > executable only once, but which need not have a globally visible name? > You can put it in a comdat group. But you should only reference it from the same comdat group. A comdat group is a set of sections which have the same signature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33871
[Bug target/26290] [4.1/4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #21 from t dot artem at mailcity dot com 2007-11-04 13:42 --- > I would say let's close this as fixed. Do you mean that GCC 4.1 and 4.2 will never have this bug fixed and we have to wait till 4.3 is out? Besides, have you tested this bug on architectures other that Intel core2? Originally this bug affected plain i386 code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug tree-optimization/27004] [4.1/4.2/4.3 Regression] Insane amount of memory needed at -O1 and above because of salias and large switch
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-04 13:38 --- Created an attachment (id=14483) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14483&action=view) patch Patch to limit the number of SFTs created per function. The limit of 1000 SFTs brings down memory usage to 1.3GB, a limit of 500 to 1.2GB, a limit of 100 results in 970MB, a limit of zero 954MB. So there's still something taking 400MB more memory than in 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
[Bug tree-optimization/27004] [4.1/4.2/4.3 Regression] Insane amount of memory needed at -O1 and above because of salias and large switch
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-04 13:34 --- Some numbers (-O): 4.0.4 needs 596MB peak 4.1.2 needs 2GB peak (and a lot of time) 4.2.2 same as 4.1.2 4.3.0 same as 4.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
[Bug tree-optimization/27004] [4.1/4.2/4.3 Regression] Insane amount of memory needed at -O1 and above because of salias and large switch
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-04 12:47 --- If you solve the SFT problem, DF needs lot of memory and compile-time in this testcase on the trunk. The execute() function has lots of basic blocks with a high number of incoming edges. So, I have a patch for the SFT problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-04 12:47:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
[Bug bootstrap/33992] Building libstdc++-v3: include/limits: stray '\275' in program
--- Comment #4 from lindevel at gmx dot net 2007-11-04 11:47 --- Created an attachment (id=14482) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14482&action=view) build.log ICE Building without setting CFLAGS or CXXFLAGS results in an ICE: /var/tmp/portage/sys-devel/gcc-4.3.0_pre20071103/work/gcc-4.3.0-20071103/libiberty/hashtab.c: In function ‘htab_expand’: /var/tmp/portage/sys-devel/gcc-4.3.0_pre20071103/work/gcc-4.3.0-20071103/libiberty/hashtab.c:554: internal compiler error: Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33992
[Bug target/26290] [4.1/4.2 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-11-04 11:45 --- With mainline we now get .p2align 4,,7 .p2align 3 .L6: addl$1, %eax cmpl%eax, %edi movl%eax, -20(%ebp) jle .L3 movl%eax, %ecx movl%esi, %edx .p2align 4,,7 .p2align 3 .L5: movl-4(%esi), %ebx movl(%edx), %eax cmpl%eax, %ebx jle .L4 movl%eax, -4(%esi) movl%ebx, (%edx) .L4: addl$1, %ecx addl$4, %edx cmpl%ecx, %edi jg .L5 .L3: movl-20(%ebp), %eax addl$4, %esi cmpl-16(%ebp), %eax jl .L6 which looks good, apart from the issue Andrew pointed out (but that's PR26726): lsti_11 = MEM[index: ivtmp.27_14, offset: 0x0fffc]; MEM[index: ivtmp.27_14, offset: 0x0fffc] = lstj_15; 4.0 is still faster with the original testcase, but the only difference I can spot is that mainline uses addl $1, %eax while 4.0 uses incl here. Oh, and 4.0 uses an extra induction variable(!) for the exit test (and less loop alignment): .L3: incl%eax cmpl%eax, 12(%ebp) movl%eax, -20(%ebp) jle .L4 movl12(%ebp), %edi movl%esi, %edx xorl%ebx, %ebx subl%eax, %edi .p2align 4,,15 .L6: movl-4(%esi), %ecx movl(%edx), %eax cmpl%eax, %ecx jle .L7 movl%eax, -4(%esi) movl%ecx, (%edx) .L7: incl%ebx addl$4, %edx cmpl%edi, %ebx jne .L6 .L4: movl-20(%ebp), %eax addl$4, %esi cmpl-16(%ebp), %eax jl .L3 Using -mtune=core2 on trunk get's back the incl and makes the code faster than 4.0 (on my Core CPU, that is). So the generic tuning here makes the difference for trunk. 4.2 is still broken, though. I would say let's close this as fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.4 |4.0.4 4.3.0 Last reconfirmed|2006-02-24 15:20:29 |2007-11-04 11:45:07 date|| Summary|[4.1/4.2/4.3 Regression]: |[4.1/4.2 Regression]: code |code pessimization wrt. GCC |pessimization wrt. GCC 4.0 |4.0 probably due to |probably due to |TARGET_MEM_REF |TARGET_MEM_REF http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug fortran/33408] ICE: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-11-04 11:43 --- Yet another comment: this only happens with stabs and -m64 on ppc-darwin8, and the combination of stabs and -m64 is known as widely broken there (see http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00142.html for the results of the Fortran testsuite). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
[Bug c/33991] error while compiling pthread application
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-04 11:15 --- As of comment #2 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33991
[Bug c/33991] error while compiling pthread application
--- Comment #2 from raeburn at raeburn dot org 2007-11-04 10:24 ---
Subject: Re: New: error while compiling pthread application
On Nov 3, 2007, at 18:32, bhvijaykumar at gmail dot com wrote:
> srtp_impl.c:8: error: expected expression before ?{? token
> srtp_impl.c:9: error: expected expression before ?{? token
> My function looks correct with
>
> connEntities[connid]->rcvWinFillMutex = PTHREAD_MUTEX_INITIALIZER;
No, PTHREAD_MUTEX_INITIALIZER is for static initialization only.
Depending on the OS, it's probably an aggregate initializer, and may
look something like "{ 0, SOME_FLAG_HERE, 0 }", so you can imagine
where the syntax error is coming from. This isn't a gcc bug, it's a
bug in the code.
C99 does have a syntax for compound literals that can be used as
structure values, with a slightly different syntax from what you
quote above, but the POSIX spec describing PTHREAD_MUTEX_INITIALIZER
does specifically talk about static initialization, not
initialization or assignment in general. For dynamic initialization,
you should be calling pthread_mutex_init.
(This would've been more appropriate for the gcc-help list.)
Ken
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33991
[Bug rtl-optimization/33732] [4.3 Regression] gcc.c-torture/execute/longlong.c execution at -O3
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-11-04 09:58 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-04 09:57:52 |2007-11-04 09:58:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33732
[Bug rtl-optimization/33732] [4.3 Regression] gcc.c-torture/execute/longlong.c execution at -O3
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-11-04 09:57 --- By visual inspection. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-04 09:57:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33732
