[Bug tree-optimization/20474] ICE while compiling openmotif-2.2.3 with -ftree-vectorize
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-20 09:18 --- Subject: Bug 20474 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-20 09:17:57 Modified files: gcc: ChangeLog tree-vect-analyze.c Log message: PR tree-optimization/20474 * tree-vect-analyze.c (vect_analyze_pointer_ref_access): Check the size_type of the relevant pointer. Check for COMPLETE_TYPE_P. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.68r2=2.7592.2.69 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vect-analyze.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.4.6.1r2=2.4.6.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20474
[Bug libstdc++/20559] cannot link program which uses std::(vector. deque) in SuSE AMDx86_64
--- Additional Comments From pcarlini at suse dot de 2005-03-20 09:51 --- The problem persists! What can I do? As I replied privately, please clean-up your paths to the standard ones and re-install (completely, core, c++, library) you system compiler. Sorry, but I will not be able to reply further, this is not the appropriate context. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20559
[Bug target/20528] [4.0/4.1 regression] ICE in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-03-20 10:37 ---
Confirmed, reduced testcase (compile with -O2):
--
struct s
{
int a, b;
};
static int foo (struct s *u)
{
if (u-b == 0)
return 0;
foo1 (u);
u-b = 0;
return 0;
}
int bar (int j, char *fmt, struct s u)
{
int ch;
union
{
double d;
} d = { 0.0 };
if (j)
foo2 (j);
for (;;)
{
while (*fmt)
fmt += 1;
if (fmt)
if (++u.a)
if (foo (u));
if (ch)
if (d.d)
if (++u.a);
}
return 0;
}
--
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
Keywords||ice-on-valid-code
Known to fail||4.0.0 4.1.0
Known to work||3.4.4
Last reconfirmed|-00-00 00:00:00 |2005-03-20 10:37:23
date||
Summary|ICE on compiling vfprintf.c |[4.0/4.1 regression] ICE in
||reload_cse_simplify_operands
||, at postreload.c:391
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20528
[Bug middle-end/20521] ICE in cgraph.C with C++
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-03-20 11:25 --- This is with today's (Mar 17, 2005) CVS, with Richard's Guenther's patch to modify inlining heuristics. which one? please add references to all patches you installed or, better, try to reproduce ICE with clean tree by adding appropriate --param options. -- What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20521
[Bug tree-optimization/20501] gcc.dg/vect/vect-93.c fails on ia64-hpux
--- Additional Comments From dorit at il dot ibm dot com 2005-03-20 12:26 --- Thanks. This patch should fix the problem (the message Alignment of access forced using peeling should not be printed when we're not going to vectorize the loop due to unsupported unaligned access. this patch moves the printing of this message to after the check that the alignment of all accesses is supported): Index: tree-vect-analyze.c === RCS file: /cvs/gcc/gcc/gcc/tree-vect-analyze.c,v retrieving revision 2.13 diff -c -3 -p -r2.13 tree-vect-analyze.c *** tree-vect-analyze.c 17 Mar 2005 21:08:06 - 2.13 --- tree-vect-analyze.c 20 Mar 2005 12:17:39 - *** vect_enhance_data_refs_alignment (loop_v *** 1183,1190 } DR_MISALIGNMENT (dr0) = 0; - if (vect_print_dump_info (REPORT_ALIGNMENT, LOOP_LOC (loop_vinfo))) - fprintf (vect_dump, Alignment of access forced using peeling.); } } --- 1183,1188 *** vect_analyze_data_refs_alignment (loop_v *** 1260,1265 --- 1258,1266 (vect_print_dump_info (REPORT_ALIGNMENT, LOOP_LOC (loop_vinfo fprintf (vect_dump, Vectorizing an unaligned access.); } + if (LOOP_VINFO_UNALIGNED_DR (loop_vinfo) +vect_print_dump_info (REPORT_ALIGNMENT, LOOP_LOC (loop_vinfo))) + fprintf (vect_dump, Alignment of access forced using peeling.); return true; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20501
[Bug other/20564] New: gcov default behaviour changed
In gcov/g++ 3.3, if I compile with g++ test.cc -ftest-coverage -fprofile-arcs,
and then run gcov test.cc, test.cc.gcov contains 2 lines of preamble, and
then 1 line for each line of test.cc
in gcov/g++ 4.1, Extra lines are added. I can't seem to disable these, and I'm
not positive why they are there. In particular they confuse programs which use
the output of gcov..
Specific example:
Given temp.cc:
template typename T
int
foo(T t)
{
if(t==1)
return 1;
else
return 0;
}
int main(void)
{ foo(1); }
Then g++-3.3 temp.cc -ftest-coverage -fprofile-arcs; ./a.out ; gcov-3.3
temp.cc gives
-:0:Source:temp.cc
-:0:Object:temp.bb
-:1:template typename T
-:2:int
-:3:foo(T t)
-:4:{
1:5: if(t==1)
1:6:return 1;
-:7: else
#:8:return 0;
-:9:}
-: 10:
-: 11:
-: 12:int main(void)
2: 13:{ foo(1); }
Whereas g++-cvs temp.cc -ftest-coverage -fprofile-arcs ; ./a.out ; gcov-cvs
temp.cc gives
-:0:Source:temp.cc
-:0:Graph:temp.gcno
-:0:Data:temp.gcda
-:0:Runs:1
-:0:Programs:1
-:1:template typename T
-:2:int
function _Z3fooIiEiT_ called 1 returned 100% blocks executed 75%
1:3:foo(T t)
-:4:{
1:5: if(t==1)
1:6:return 1;
-:7: else
#:8:return 0;
-:9:}
-: 10:
-: 11:
function main called 1 returned 100% blocks executed 100%
1: 12:int main(void)
1: 13:{ foo(1); }
Is it possible to turn this off? Is it a regression?
--
Summary: gcov default behaviour changed
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
[Bug other/20564] gcov default behaviour changed
--- Additional Comments From chris at bubblescope dot net 2005-03-20 12:45 --- As soon as I've submitted this bug, I've found the documentation notes this change.. I would still ask is there a way to get back the earlier behaviour? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
[Bug other/20565] New: gcov default behaviour changed
In gcov/g++ 3.3, if I compile with g++ test.cc -ftest-coverage -fprofile-arcs,
and then run gcov test.cc, test.cc.gcov contains 2 lines of preamble, and
then 1 line for each line of test.cc
in gcov/g++ 4.1, Extra lines are added. I can't seem to disable these, and I'm
not positive why they are there. In particular they confuse programs which use
the output of gcov..
Specific example:
Given temp.cc:
template typename T
int
foo(T t)
{
if(t==1)
return 1;
else
return 0;
}
int main(void)
{ foo(1); }
Then g++-3.3 temp.cc -ftest-coverage -fprofile-arcs; ./a.out ; gcov-3.3
temp.cc gives
-:0:Source:temp.cc
-:0:Object:temp.bb
-:1:template typename T
-:2:int
-:3:foo(T t)
-:4:{
1:5: if(t==1)
1:6:return 1;
-:7: else
#:8:return 0;
-:9:}
-: 10:
-: 11:
-: 12:int main(void)
2: 13:{ foo(1); }
Whereas g++-cvs temp.cc -ftest-coverage -fprofile-arcs ; ./a.out ; gcov-cvs
temp.cc gives
-:0:Source:temp.cc
-:0:Graph:temp.gcno
-:0:Data:temp.gcda
-:0:Runs:1
-:0:Programs:1
-:1:template typename T
-:2:int
function _Z3fooIiEiT_ called 1 returned 100% blocks executed 75%
1:3:foo(T t)
-:4:{
1:5: if(t==1)
1:6:return 1;
-:7: else
#:8:return 0;
-:9:}
-: 10:
-: 11:
function main called 1 returned 100% blocks executed 100%
1: 12:int main(void)
1: 13:{ foo(1); }
Is it possible to turn this off? Is it a regression?
--
Summary: gcov default behaviour changed
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20565
[Bug other/20566] New: gcov default behaviour changed
In gcov/g++ 3.3, if I compile with g++ test.cc -ftest-coverage -fprofile-arcs,
and then run gcov test.cc, test.cc.gcov contains 2 lines of preamble, and
then 1 line for each line of test.cc
in gcov/g++ 4.1, Extra lines are added. I can't seem to disable these, and I'm
not positive why they are there. In particular they confuse programs which use
the output of gcov..
Specific example:
Given temp.cc:
template typename T
int
foo(T t)
{
if(t==1)
return 1;
else
return 0;
}
int main(void)
{ foo(1); }
Then g++-3.3 temp.cc -ftest-coverage -fprofile-arcs; ./a.out ; gcov-3.3
temp.cc gives
-:0:Source:temp.cc
-:0:Object:temp.bb
-:1:template typename T
-:2:int
-:3:foo(T t)
-:4:{
1:5: if(t==1)
1:6:return 1;
-:7: else
#:8:return 0;
-:9:}
-: 10:
-: 11:
-: 12:int main(void)
2: 13:{ foo(1); }
Whereas g++-cvs temp.cc -ftest-coverage -fprofile-arcs ; ./a.out ; gcov-cvs
temp.cc gives
-:0:Source:temp.cc
-:0:Graph:temp.gcno
-:0:Data:temp.gcda
-:0:Runs:1
-:0:Programs:1
-:1:template typename T
-:2:int
function _Z3fooIiEiT_ called 1 returned 100% blocks executed 75%
1:3:foo(T t)
-:4:{
1:5: if(t==1)
1:6:return 1;
-:7: else
#:8:return 0;
-:9:}
-: 10:
-: 11:
function main called 1 returned 100% blocks executed 100%
1: 12:int main(void)
1: 13:{ foo(1); }
Is it possible to turn this off? Is it a regression?
--
Summary: gcov default behaviour changed
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20566
[Bug other/20565] gcov default behaviour changed
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:02 --- Stupid webbrowser ¬_¬ *** This bug has been marked as a duplicate of 20564 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20565
[Bug other/20564] gcov default behaviour changed
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:02 --- *** Bug 20565 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
[Bug other/20566] gcov default behaviour changed
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:03 --- Stupid webbrowser ¬_¬ *** This bug has been marked as a duplicate of 20564 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20566
[Bug other/20564] gcov default behaviour changed
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:03 --- *** Bug 20566 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
[Bug testsuite/20567] New: dg-options in gcc.c-torture
Some tests in gcc.c-torture use dg-options inappropriately. gcc.c-torture/execute ignores dg-options settings, but pr7284-1.c and wchar_t-1.c use them. I think the proper fix would be to make that directory honour dg-options. If it is made to use the dg harness it might also be possible to get rid of most of the .x files in c-torture by moving them into test annotations within the testcase files. In gcc.c-torture/compile, tests 20031125-1.c, 20031125-2.c, 20031203-1.c and acc1.c specify -O2. As the point of the torture tests is to iterate over different optimization options, tests should not specify any options like -O2 which are included in that iteration; only other special options (such as -ffast-math for acc1.c). compile/981006-1.c looks like a diagnostic test and as such (a) should not use -w, (b) should better be in gcc.dg/torture/. -- Summary: dg-options in gcc.c-torture Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,janis187 at us dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20567
[Bug testsuite/19802] scan-not-hidden breaks with unknown object format
-- What|Removed |Added Component|other |testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19802
[Bug other/20564] gcov default behaviour changed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 13:55 --- gcov output is suposed to be human readable and not machine readable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
[Bug c++/20547] undefined reference to static const fields of classes
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-20 13:55 --- Here is the relevant section of the standard (TC1, section 9.4.2, paragraph 4): If a 'static' data member is of 'const' integral or 'const' enumeral type, its declaration in the class definition can specify a 'constant-initializer' which shall be an integral constant expression (5.19). In that case, the member can appear in integral constant expressions. The member shall still be defined in a namespace scope if it is used in the program and the namespace scope definition shall not contain an 'initializer'. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20547
[Bug c++/20549] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification on invalid code
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-20 14:00 --- Here is the error message: pr20549.C: In function 'void popSlot()': pr20549.C:12: internal compiler error: in resolve_overloaded_unification, at cp/pt.c:9579 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- What|Removed |Added Summary|[3.4/4.0/4.1 Regression] ICE|[3.4/4.0/4.1 Regression] ICE |on invalid code,|in ||resolve_overloaded_unificati ||on on invalid code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20549
[Bug other/17543] #pragma weak undocumented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 14:54 --- Fixed for 4.0.0 by: 2005-03-17 Richard Henderson [EMAIL PROTECTED] * doc/extend.texi (Weak Pragmas): New section. (attribute alias): Clarify that target must be in the same translation unit. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17543
[Bug target/19069] [x86][amd64] Could have better initial RTL generation for MIN/MAX
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 14:58 --- Isn't this fixed now by: 2005-03-10 Steven Bosscher [EMAIL PROTECTED] * expr.c (expand_expr_real_1): If possible, use a conditional move for expanding MIN_EXPR and MAX_EXPR. Use temp for moving around rtx-en. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19069
[Bug fortran/18899] [gfortran] ubound wrongly calculated for passed array
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 15:00 --- I get this now: Fail! lbound = 1, ubound = 2 Which is only partly more correct but still wrong. -- What|Removed |Added Last reconfirmed|2004-12-19 15:16:31 |2005-03-20 15:00:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18899
[Bug other/20564] gcov default behaviour changed
--- Additional Comments From nathan at gcc dot gnu dot org 2005-03-20 15:11 --- whilst gcov output is primarily human readable, it should be machine processable. I do not consider this a regression, because the additional lines are all tagged as line 0. filter scripts should be written to deal with line zero specially. A note should be added to gcov's documentation to the effect that a) filters should be robust to line zero changes b) line zero data is not guaranteed unchanging -- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
[Bug other/20564] gcov default behaviour changed
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-20 15:11:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
[Bug target/19069] [x86][amd64] Could have better initial RTL generation for MIN/MAX
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-20 15:12 --- Yes it is. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19069
[Bug middle-end/20521] ICE in cgraph.C with C++
--- Additional Comments From bredelin at ucla dot edu 2005-03-20 15:57 --- Subject: Re: ICE in cgraph.C with C++ belyshev at depni dot sinp dot msu dot ru wrote: --- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-03-20 11:25 --- This is with today's (Mar 17, 2005) CVS, with Richard's Guenther's patch to modify inlining heuristics. which one? please add references to all patches you installed or, better, try to reproduce ICE with clean tree by adding appropriate --param options. 1. For now, I will just include the patch: diff -r1.170 tree-inline.c 1249a1250 case TARGET_EXPR: 1250a1252,1253 if (DECL_P (x) DECL_IGNORED_P (x)) break; 1252d1254 case TARGET_EXPR: 2. However, it seems that as of Mar 18 CVS, the crash no longer occurs. This is probably because of this change: Fri Mar 18 10:00:16 2005 UTC by hubicka PR middle-end/20225 * cgraph.c (cgraph_mark_reachable_node): Assert that it is not called too late. * varasm.c (find_decl_and_mark_needed): Mark needed only when not called too late. 3. This patch might be reversed: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01869.html If the regression returns, I will try to find --param options that cause the ICE on a clean tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20521
[Bug target/19069] [x86][amd64] Could have better initial RTL generation for MIN/MAX
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19069
[Bug target/19069] Have better initial RTL generation for MIN/MAX
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-20 16:07 --- Actually the original plan was to write define_expands for x86*, but easier solution was to write a new generic expander in expr.c. As a positive side effect, other targets also profit from that patch. So let's adjust the bug summary accordingly :-) -- What|Removed |Added Summary|[x86][amd64] Could have |Have better initial RTL |better initial RTL |generation for MIN/MAX |generation for MIN/MAX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19069
[Bug middle-end/20539] [4.0/4.1 Regression] ICE in simplify_subreg, at simplify-rtx.c:3674
--- Additional Comments From roger at eyesopen dot com 2005-03-20 16:47 --- Patch here http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01871.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20539
[Bug tree-optimization/20542] [4.1 Regression] Bootstrap failure at -Os
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 16:50 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01830.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20542
[Bug pch/20568] New: [4.0/4.1 Regression] PCH failures with debugging
The following 4 PCH testcase failure on the 4.0 branch/mainline: native gcc.sum gcc.dg/pch/save-temps-1.c native gcc.sum gcc.dg/pch/static-1.c native gcc.sum gcc.dg/pch/static-2.c native gcc.sum gcc.dg/pch/static-3.c Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01762.html -- Summary: [4.0/4.1 Regression] PCH failures with debugging Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: patch, wrong-debug Severity: normal Priority: P2 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20568
[Bug pch/20568] [4.0/4.1 Regression] PCH failures with debugging
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-20 16:53:19 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20568
[Bug c++/19980] [4.0/4.1 regression] ICE on invalid template declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 17:01 --- But, that's too complicated for Stage 3. Your patch is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19980
[Bug c++/20461] [4.0/4.1 Regression] ICE at class 'C' does not have any field named 'f' error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 17:29 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01879.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20461
[Bug c/20569] New: [ gcc 3.4.3 ] glibc 2.3.4 ldconfig segv when building with -march=pentium-m
Configured with: ./gcc-3.4.3/configure --prefix=/usr --enable-shared --enable-threads --enable-languages=c,c++ --program-suffix=3.4.3 --enable-version-specific-runtime-libs Thread model: posix gcc version 3.4.3 binutils 2.15 linux 2.6.11 on pentium-m --- when building glibc-2.3.4, with CFLAGS=-O3 -march=pentium-m -mmmx -msse -msse2 -mfpmath=sse everything is built with no apparent failures but when i run the elf/ldconfig from the newly built src i get a segv in convert_options() however, if the CFLAGS have the reference to -march=pentium-m and -msse2 dropped, a rebuild does not cause elf/ldconfig to segv. is this a bug in the optimisation for pentium-m? i have tried adding back -march=pentium3 and that does not generate a ldconfig that segvs glibc that was configure to produce the error was: CFLAGS=-O3 -march=pentium-m -mmmx -msse -msse2 -mfpmath=sse \ ./glibc-2.3.4/configure --prefix=/usr --sysconfdir=/etc \ --enable-add-ons=nptl --with-tls --with-__thread --enable-bind-now -- Summary: [ gcc 3.4.3 ] glibc 2.3.4 ldconfig segv when building with -march=pentium-m Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: whatdoineed2do at yahoo dot co dot uk CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: linux ia32 GCC target triplet: linux ia32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20569
[Bug middle-end/20177] ICE in schedule-insns for -O2 -fmodulo-sched
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 17:30 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01875.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20177
[Bug target/20569] [ gcc 3.4.3 ] glibc 2.3.4 ldconfig segv when building with -march=pentium-m
-- What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20569
[Bug target/20569] [ gcc 3.4.3 ] glibc 2.3.4 ldconfig segv when building with -march=pentium-m
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 17:37 --- We need a testcase. The last time this was reported, there was no testcase, see PR 16466. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20569
[Bug target/20166] Bootstrap failure due to lack of fixinclude of pthread problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 17:39 --- (In reply to comment #12) Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01377.html Note for fixinclude patches, Bruce Korb likes to be CCed on them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
[Bug target/20569] [ gcc 3.4.3 ] glibc 2.3.4 ldconfig segv when building with -march=pentium-m
-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20569
[Bug c++/20570] New: g++ reports superfluous warning for non-virtual/protected base destructor
The warning:
t.cc:2: warning: `class A' has virtual functions but non-virtual destructor
when compiling this code with -Wall
struct A
{
virtual void test() = 0;
protected:
~A() {}
};
is superfluous:
Yes, A is obviously intended as base class for polymorphic usage since it has
virtual functions.
But in this case both a public/virtual or protected/non-virtual destructor
suffice; in the second case
there is no problem with polymorphic destruction, the case that would require a
virtual destructor to
work correctly, since it is forbidden [to any outsiders, i.e. all code that
is not part of a class derived
from A, which is ok for the general case].
Please consider updating the rule for the warning to be
Warn if the destructor of an 'obvious' base class is neither virtual nor
protected.
--
Summary: g++ reports superfluous warning for non-
virtual/protected base destructor
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at cohi dot at
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: any
GCC host triplet: any
GCC target triplet: any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20570
[Bug c/18166] top const stripped in structs for C
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20
17:45 ---
Confirmed as fixed:
(gdb) ptype xss
type = struct ss {
char *ptr;
}
(gdb) ptype xssc
type = struct ssc {
char * const ptr;
}
--
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18166
[Bug c++/20570] g++ reports superfluous warning for non-virtual/protected base destructor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 17:47 --- *** This bug has been marked as a duplicate of 7302 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20570
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 17:47 --- *** Bug 20570 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||gcc at cohi dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug testsuite/20567] dg-options in gcc.c-torture
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 17:48 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-20 17:48:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20567
[Bug c/20550] Silencing the warning: comparison is always true due to limited range of data type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 17:50 --- *** This bug has been marked as a duplicate of 12963 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20550
[Bug c++/12963] Wrong and misleading warning encourages writing non-portable code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 17:50 --- *** Bug 20550 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||qrczak at knm dot org dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
[Bug fortran/20541] ALLOCATABLE components
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-20 18:08 --- This only allowed after TR15581 which is unimplemented so far in gfortran. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-03-20 18:08:03 date|| Summary|INTEGER type declaration: |ALLOCATABLE components |ALLOCATABLE, compilation| |error | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fortran/20520] allocatable arrays used uninitialized without a warning
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-20 18:14 --- real,allocatable:: a(:),b(:) real::x a(1)=2*b(1) + x end This only gives an uninitialized warning for x, but not for a or b: [EMAIL PROTECTED] tests]$ gfortran -O -Wuninitialized pr20521.f90 pr20521.f90: In function MAIN__: pr20521.f90:3: warning: x is used uninitialized in this function So it looks like diagnostics for allocatable arrays are fairly weak. -- What|Removed |Added Summary|allocatable arrays used |allocatable arrays used |without being allocated |uninitialized without a |without a warning |warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
[Bug libfortran/20438] Reconfiguring of libgfortran fails conflicting types for int8_t
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-20 18:19 --- This happens when libgfortran is reconfigured in a directory where it's already built. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-20 18:19:01 date|| Summary|conflicting types for int8_t|Reconfiguring of libgfortran |with --enable-maintainer- |fails conflicting types for |mode|int8_t http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20438
[Bug rtl-optimization/20290] [4.0/4.1 Regression] Miscompilation on ppc/arm with -Os
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-20
18:34 ---
Subject: [PR rtl-optimization/20290] loop body doesn't run in every iteration
if exit test is the loop entry point
Tree loop optimizations transform the second loop in main() in the
attached testcase in a loop that enters through the exit test. We end
up miscomputing the final value of the original biv because we assume
the increment is executed in every iteration, but since the iteration
count is computed based on the number of times the exit test runs, the
multiplier we use is off by one.
This patch detects the situation of entering the loop through an
unconditional jump to the exit test, which I believe is a relatively
rare idiom that should probably be avoided by tree loop opts as well,
and makes sure the biv increment is marked as not executed in every
iteration. This unfortunately means the biv can't be eliminated. It
could if we kept track of two distinct properties: whether the
increment is conditional (not_every_iteration), and whether the
increment is skipped only in the last iteration (not_last_iteration).
I haven't gone as far as implementing this, since I understand the new
loop optimization infrastructure already handles this case correctly.
Bootstrapped and regtested on x86_64-linux-gnu, verified to fix the
testcase on ppc-linux by visual inspection of the assembly output. Ok
to install?
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR rtl-optimization/20290
* loop.c (for_each_insn_in_loop): Don't assume the loop body runs
in every iteration if the entry point is the exit test.
Index: gcc/loop.c
===
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.522
diff -u -p -r1.522 loop.c
--- gcc/loop.c 17 Jan 2005 08:46:15 - 1.522
+++ gcc/loop.c 20 Mar 2005 06:36:43 -
@@ -4655,12 +4655,18 @@ for_each_insn_in_loop (struct loop *loop
int not_every_iteration = 0;
int maybe_multiple = 0;
int past_loop_latch = 0;
+ bool exit_test_is_entry = false;
rtx p;
- /* If loop_scan_start points to the loop exit test, we have to be wary of
- subversive use of gotos inside expression statements. */
+ /* If loop_scan_start points to the loop exit test, the loop body
+ cannot be counted on running on every iteration, and we have to
+ be wary of subversive use of gotos inside expression
+ statements. */
if (prev_nonnote_insn (loop-scan_start) != prev_nonnote_insn (loop-start))
-maybe_multiple = back_branch_in_range_p (loop, loop-scan_start);
+{
+ exit_test_is_entry = true;
+ maybe_multiple = back_branch_in_range_p (loop, loop-scan_start);
+}
/* Scan through loop and update NOT_EVERY_ITERATION and MAYBE_MULTIPLE. */
for (p = next_insn_in_loop (loop, loop-scan_start);
@@ -4718,10 +4724,12 @@ for_each_insn_in_loop (struct loop *loop
beginning, don't set not_every_iteration for that.
This can be any kind of jump, since we want to know if insns
will be executed if the loop is executed. */
- !(JUMP_LABEL (p) == loop-top
- ((NEXT_INSN (NEXT_INSN (p)) == loop-end
-any_uncondjump_p (p))
- || (NEXT_INSN (p) == loop-end any_condjump_p (p)
+ (exit_test_is_entry
+ || !(JUMP_LABEL (p) == loop-top
+ ((NEXT_INSN (NEXT_INSN (p)) == loop-end
+any_uncondjump_p (p))
+ || (NEXT_INSN (p) == loop-end
+ any_condjump_p (p))
{
rtx label = 0;
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR rtl-optimization/20290
* gcc.c-torture/execute/loop-ivopts-2.c: New.
Index: gcc/testsuite/gcc.c-torture/execute/loop-ivopts-2.c
===
RCS file: gcc/testsuite/gcc.c-torture/execute/loop-ivopts-2.c
diff -N gcc/testsuite/gcc.c-torture/execute/loop-ivopts-2.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/gcc.c-torture/execute/loop-ivopts-2.c 20 Mar 2005 06:36:58
-
@@ -0,0 +1,50 @@
+/* PR rtl-optimization/20290 */
+
+/* We used to mis-optimize the second loop in main on at least ppc and
+ arm, because tree loop would change the loop to something like:
+
+ ivtmp.65 = l[i];
+ ivtmp.16 = 113;
+ goto bb 4 (L4);
+
+L3:;
+ *(ivtmp.65 + 4294967292B) = 9;
+ i = i + 1;
+
+L4:;
+ ivtmp.16 = ivtmp.16 - 1;
+ ivtmp.65 = ivtmp.65 + 4B;
+ if (ivtmp.16 != 0) goto L3;
+
+ We used to consider the increment of i as executed in every
+ iteration, so we'd miscompute the final value. */
+
+extern void abort (void);
+
+void
+check (unsigned int *l)
+{
+ int i;
+ for (i = 0; i 288; i++)
+if (l[i] != 7 + (i 256 || i = 280) + (i = 144 i 256))
+ abort ();
+}
+
+int
+main (void)
+{
+ int i;
+ unsigned int l[288];
+
+ for (i
[Bug middle-end/12963] Wrong and misleading warning encourages writing non-portable code
--- Additional Comments From qrczak at knm dot org dot pl 2005-03-20 19:10
---
Better than that the availability of something like
#pragma expected-warning line WARNING-NAME
might remove the warning generated by the following line labeling it as
checked,
expected and/or unavoidable.
This would not help in my case because it's a regular type-generic C macro, not
generated code. The line number of the macro definition is not stable (changes
as surrounding code evolves), and it makes no sense to mark all its invocations.
From my point of view a perfect solution would be making this obvious
workaround
working:
int test(int x) {
if ((long long)x = 0x123456789ABCLL) return 1;
else return 0;
}
There should be no warning if the lhs is cast to the wider type. GCC seems to be
inferring that the range of possible values of (long long)x is the range of int.
The runtime comparison is eliminated, which is good; this implies that the
warning should not be tied to the comparison being eliminated.
I'm not judging whether the warning should be emitted at all. Maybe it should be
removed altogether; after all, it's not guaranteed to be redundant on all
platforms. It definitely should not be emitted by default, especially without
any warning options, especially if the cast suggests that the programmer is
aware of it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
[Bug fortran/20520] allocatable arrays used uninitialized without a warning
--- Additional Comments From ebertakis at gmail dot com 2005-03-20 19:22 --- (In reply to comment #4) This case is slightly different. The compiler just warns you that you are using variable x before its value have been defined. Many programmers (that have bad programming habits :-) probably that includes myself!) take for granted that variables have an initial value equal to 0 once their memory space is reserved upon definition as e.g. real. That is not always true and is heavily dependant on the compiler that is used. Many compilers fill the variables with garbage when they are first declared. See also the Fortran FAQ (paragraph 3.2.3): http://www.faqs.org/faqs/fortran-faq/ That is why you got that warning. I believe it is not related to the array usage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
[Bug c++/15938] ICE with anonymous unions
--- Additional Comments From pcarlini at suse dot de 2005-03-20 20:13 --- Seenms doable... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15938
[Bug target/18551] wrong asm output for -mcall-prologues with g++
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-20 21:12 --- Subject: Bug 18551 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-20 21:12:09 Modified files: gcc: ChangeLog gcc/config/avr : avr.c Log message: PR target/18551 * config/avr/avr.c (avr_output_function_prologue): Do not use current_function_name() in a label, use a local label instead. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7922r2=2.7923 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.c.diff?cvsroot=gccr1=1.131r2=1.132 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18551
[Bug target/18551] wrong asm output for -mcall-prologues with g++
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-20 21:13 --- Subject: Bug 18551 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-20 21:13:13 Modified files: gcc: ChangeLog gcc/config/avr : avr.c Log message: PR target/18551 * config/avr/avr.c (avr_output_function_prologue): Do not use current_function_name() in a label, use a local label instead. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.69r2=2.7592.2.70 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.129.6.1r2=1.129.6.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18551
[Bug target/18551] wrong asm output for -mcall-prologues with g++
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-20 21:14 --- Subject: Bug 18551 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-03-20 21:14:28 Modified files: gcc: ChangeLog gcc/config/avr : avr.c Log message: PR target/18551 * config/avr/avr.c (avr_output_function_prologue): Do not use current_function_name() in a label, use a local label instead. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.823r2=2.2326.2.824 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.108.4.5r2=1.108.4.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18551
[Bug c++/20571] New: -Wswitch incorrectly outputs warning on ranges (regression from 3.4)
Test program:
enum fred
{
apple,
orange,
fruit_1,
fruit_2,
fruit_3,
};
int xx()
{
fred e;
switch (e) {
case apple:
;
case orange:
;
case fruit_1 ... fruit_3:
;
}
}
gcc 3.4 correctly accepts this code without warning.
gcc 4.0 (of Mar 17 18:06 UTC) incorrectly generates a warning.
$ /opt/gcc-3.4/bin/g++ -Wswitch -c a1.cpp
$ /opt/gcc-4.0.pre/bin/g++ -Wswitch -c a1.cpp
a1.cpp: In function 'int xx()':
a1.cpp:13: warning: enumeration value 'fruit_2' not handled in switch
a1.cpp:13: warning: enumeration value 'fruit_3' not handled in switch
--
Summary: -Wswitch incorrectly outputs warning on ranges
(regression from 3.4)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ajd at gentrack dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20571
[Bug c/20572] New: internal compiler error: in loc_descriptor_from_tree
Trying to build fontutils on FreeBSD 5.4, amd64, ran into this bug. Command line: gcc -g -I../include -I/usr/X11R6/include -c display.c Error: display.c: In function `digitize_spline': display.c:600: internal compiler error: in loc_descriptor_from_tree, at dwarf2out.c:8863 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Note remove -g and compilation seems ok. Command gcc -v -save-temps -g -I../include -I/usr/X11R6/include -c display.c Produces: Using built-in specs. Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 /usr/libexec/cc1 -E -quiet -v -I../include -I/usr/X11R6/include -D_LONGLONG display.c -fworking-directory -o display.i ignoring duplicate directory /usr/include #include ... search starts here: #include ... search starts here: ../include /usr/X11R6/include /usr/include End of search list. /usr/libexec/cc1 -fpreprocessed display.i -quiet -dumpbase display.c -auxbase display -g -version -o display.s GNU C version 3.4.2 [FreeBSD] 20040728 (amd64-fbsdproj-freebsd) compiled by GNU C version 3.4.2 [FreeBSD] 20040728. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 display.c: In function `digitize_spline': display.c:600: internal compiler error: in loc_descriptor_from_tree, at dwarf2out.c:8863 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in loc_descriptor_from_tree Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sam at kalessin dot jpl dot nasa dot gov CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20572
[Bug c/20572] internal compiler error: in loc_descriptor_from_tree
--- Additional Comments From sam at kalessin dot jpl dot nasa dot gov 2005-03-20 21:49 --- Created an attachment (id=8425) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8425action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20572
[Bug c/20562] no unused warning for static arrays
--- Additional Comments From bangerth at dealii dot org 2005-03-20 22:46 --- IIRC, this was intentional because people had a habit of writing RCS $ID: strings at the top of files and wanted to find them again in the executable to identify which files exactly were linked together. You may find relevant discussions somewhere in the archives. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20562
[Bug c/20562] no unused warning for static arrays
--- Additional Comments From mueller at kde dot org 2005-03-20 23:22 --- this is where __attribute__((unused)) kicks in.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20562
[Bug c/18715] [4.0/4.1 Regression] warning: enumeration value not handled in switch for '...' ranges
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 23:34 --- *** Bug 20571 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||ajd at gentrack dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18715
[Bug c++/20571] -Wswitch incorrectly outputs warning on ranges (regression from 3.4)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 23:34 --- *** This bug has been marked as a duplicate of 18715 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20571
[Bug debug/20572] internal compiler error: in loc_descriptor_from_tree
-- What|Removed |Added Component|c |debug Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20572
[Bug debug/20572] internal compiler error: in loc_descriptor_from_tree
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 23:43 --- This is fixed in 3.4.3 and above. This is a dup of bug 14492. *** This bug has been marked as a duplicate of 14492 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20572
[Bug debug/14492] [3.4 Regression] loc_descriptor_from_tree, in dwarf2out.c:9031
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 23:43 --- *** Bug 20572 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sam at kalessin dot jpl dot ||nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14492
[Bug target/18551] wrong asm output for -mcall-prologues with g++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-20 23:54 --- Fixed. Please as normal send the patch to [EMAIL PROTECTED] -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18551
[Bug c/20573] New: unable to use cast to suppress warning: comparison is always false due to limited range of data type
There doesn't seem to be an easy way to suppress this warning in a macro like
#define MILL(in) ((in) 100)
where the macro may be passed different sizes of ints including shorts.
I would have expected the warning to be suppressed when a cast is present
like:
#define MILL(in) ((int)(in) 100)
but it isn't.
Environment:
System: CYGWIN_NT-5.1 DHX98431 1.5.14s(0.124/4/2) 20050319 16:46:09 i686
unknown unknown Cygwin
host: i686-pc-cygwin
build: i686-pc-cygwin
target: i686-pc-cygwin
configured with: /gcc/3.4/gcc-3.4.1-1/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,f77,java,objc --enable-nls
--without-included-gettext --enable-libgcj --with-system-zlib
--enable-interpreter --enable-threads=posix --enable-java-gc=boehm
--enable-sjlj-exceptions --disable-version-specific-runtime-libs
--disable-win32-registry
How-To-Repeat:
Given warnme.c:
#define MILL(in) ((in) 100)
int foo(short s) { return MILL(s); }
int bar(short s) { return MILL((int)s); }
int baz(short s) { int i=s; return MILL(i); }
with preprocessor output warnme.i:
# 1 warnme.c
# 1 built-in
# 1 command line
# 1 warnme.c
int foo(short s) { return ((s) 100); }
int bar(short s) { return (((int)s) 100); }
int baz(short s) { int i=s; return ((i) 100); }
$ gcc -Wall -save-temps -c warnme.c
warnme.c: In function `foo':
warnme.c:2: warning: comparison is always false due to limited range of data
type
warnme.c: In function `bar':
warnme.c:3: warning: comparison is always false due to limited range of data
type
The warning in foo is expected; the warning in bar is not. baz is an ugly
workaround.
--- Additional Comments From sthoenna at efn dot org 2005-03-21 00:16
---
Fix:
An ugly workaround is to assign to a temporary variable of large enough data
type where the macro is called, and pass the temporary variable instead.
--
Summary: unable to use cast to suppress warning: comparison is
always false due to limited range of data type
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sthoenna at efn dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20573
[Bug c/20573] unable to use cast to suppress warning: comparison is always false due to limited range of data type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-21 00:24 --- A better way is to just to suppress the warning point, see PR 12963. *** This bug has been marked as a duplicate of 12963 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|unable to use cast to |unable to use cast to |suppress warning: |suppress warning: |comparison is always false |comparison is always false |due to limited range of data|due to limited range of data |type |type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20573
[Bug middle-end/12963] Wrong and misleading warning encourages writing non-portable code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-21 00:24 --- *** Bug 20573 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sthoenna at efn dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
[Bug fortran/20059] internal compiler error: Segmentation Fault - For common blocks
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-21 02:25 --- (In reply to comment #4) Can you try this patch, Andrew? The required padding should never overflow 2^32. Sorry for not replying sooner, exams got in the way. But yes this fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20059
[Bug objc/20574] New: [4.1 Regression] werid error message after a parse error
Take the following code:
@implementation A
+B
+C {}
@end
With 4.0, we got:
t.m: In function +[A B]:
t.m:3: error: syntax error before + token
But with 4.1 we get:
t.m: In function +[A B]:
t.m:3: error: expected { before + token
t.m: At top level:
t.m:3: error: redefinition of parameter self
t.m:3: error: previous definition of self was here
t.m:3: error: redefinition of parameter _cmd
t.m:3: error: previous definition of _cmd was here
The error messages about self and _cmd are not really needed (yes they are
correct really but we should
be able to do better with error recovery)
--
Summary: [4.1 Regression] werid error message after a parse error
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: minor
Priority: P2
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20574
[Bug objc/20574] [4.1 Regression] werid error message after a parse error
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20574
[Bug tree-optimization/14843] propagate a cast back to PHI
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-21 02:41 --- tree PRE now does this and has since at least the 4.0 branch was created. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14843
Extra gcc-3.3 java failures when using expect-5.43
After I upgraded to expect-5.43, I noticed that I'm getting extra java failures on the 3.3 branch on x86_64-unknown-linux-gnu. Other gcc branches do not have problems. http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01295.html I'm using an expect-5.43 binary on x86_64 that was compiled on i686 if that matters. When I back down to expect-5.42.1, the testsuite results go back to normal. Anyone else seeing this? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
[Bug middle-end/20539] [4.0/4.1 Regression] ICE in simplify_subreg, at simplify-rtx.c:3674
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-21
03:30 ---
Subject: Bug 20539
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-21 03:30:08
Modified files:
gcc: ChangeLog fold-const.c c-common.c
gcc/testsuite : ChangeLog
Added files:
gcc/testsuite/gcc.c-torture/compile: pr13066-1.c pr20539-1.c
gcc/testsuite/g++.dg/opt: pr13066-1.C
Log message:
PR middle-end/20539
* fold-const.c (fold_binary): Fix type mismatch between
TRUTH_{AND,OR,XOR}_EXPR nodes an their operands' types.
(fold_binary) TRUTH_XOR_EXPR: Avoid calling invert_truthvalue
for non-truth-valued expressions.
* c-common.c (c_common_truthvalue_conversion): Handle ERROR_MARK
and FUNCTION_DECL in the main switch.
TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR, TRUTH_AND_EXPR, TRUTH_OR_EXPR,
TRUTH_XOR_EXPR: When changing the result type of these tree nodes,
we also need to convert their operands to match.
TRUTH_NOT_EXPR: Likewise.
* gcc.c-torture/compile/pr13066-1.c: New test case.
* gcc.c-torture/compile/pr20539-1.c: Likewise.
* g++.dg/opt/pr13066-1.C: Likewise.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7927r2=2.7928
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gccr1=1.544r2=1.545
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gccr1=1.614r2=1.615
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5185r2=1.5186
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr13066-1.c.diff?cvsroot=gccr1=NONEr2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr20539-1.c.diff?cvsroot=gccr1=NONEr2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr13066-1.C.diff?cvsroot=gccr1=NONEr2=1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20539
[Bug c/20573] unable to use cast to suppress warning: comparison is always false due to limited range of data type
--- Additional Comments From sthoenna at efn dot org 2005-03-21 03:49 --- Subject: Re: unable to use cast to suppress warning: comparison is always false due to limited range of data type On Mon, Mar 21, 2005 at 12:24:32AM -, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-21 00:24 --- A better way is to just to suppress the warning point, see PR 12963. But I don't want to suppress the warning in general; it's a valuable warning. I just want to be able to have a macro that takes an arbitrarily sized int and compares it. *** This bug has been marked as a duplicate of 12963 *** Thanks. I mistakenly searched Comments containing 'comparison is always' instead of 'comparison is always' :) or I would have found that one. It's interesting to note that the apparent ending point of the discussion there is my starting point: that a cast should suppress the warning (but I would hope not the optimization). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20573
[Bug other/20510] [4.0/4.1 Regression] target libiberty multilibs built with configure --disable-multilibs
--- Additional Comments From billingd at gcc dot gnu dot org 2005-03-21 06:20 --- Operator error. The correct flag is --disable-multilib and that works. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20510
[Bug target/20051] ICE when compiling SSE intrinics
--- Additional Comments From uros at kss-loka dot si 2005-03-21 06:20 --- This is a duplicate of PR 14981. The fix is in a follow-up bug PR 19010. *** This bug has been marked as a duplicate of 14981 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20051
[Bug target/14981] [3.4/4.0 Regression] ICE in _mm_xor_pd for SSE2 with -O1
--- Additional Comments From uros at kss-loka dot si 2005-03-21 06:21 --- *** Bug 20051 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||m dot broadbent at signal ||dot qinetiq dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14981
