[Bug bootstrap/21335] [meta-bug] bootstrap fails with -ftree-vectorize
--- Comment #3 from dpatel at apple dot com 2006-09-05 16:44 --- I know this is a bootstrap failure, however is there a small reproducible test case for this crash ? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21335
[Bug bootstrap/21335] [meta-bug] bootstrap fails with -ftree-vectorize
--- Comment #5 from dpatel at apple dot com 2006-09-05 17:01 --- I'd already verified that. How about -O3 -ftree-vectorize bootstrap failure ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21335
[Bug debug/28834] [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #10 from dpatel at apple dot com 2006-08-30 07:47 --- Pinski, Please do not reinsert my email address in CC list, again (and learn to not jump to conclusion based on biased views) May be it is not a good idea to ask dwarf generator to handle a case where two shallow copy of same struct refers same field ? May be equate_decl_number_to_die() should handle it properly ? May be it is appropriate to have one field be a member of multiple structures ? -- dpatel at apple dot com changed: What|Removed |Added CC|dpatel at apple dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug c++/26216] New: deprecated function warning is emitted twice
deprecated function warning is emitted twice
For example,
--- a.cc ---
int f() __attribute__((deprecated));
int f() { return 0; }
int main()
{
return f();
}
---
$ /Volumes/src/clean/gcc.trunk.install/bin/gcc -c a.cc
a.cc: In function 'int main()':
a.cc:7: warning: 'f' is deprecated (declared at a.cc:3)
a.cc:7: warning: 'f' is deprecated (declared at a.cc:3)
--
Summary: deprecated function warning is emitted twice
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26216
[Bug target/24220] gcc.dg/i386-sse-vect-types.c (test for errors, line 17) fails
--- Comment #2 from dpatel at apple dot com 2005-12-06 22:19 --- This is already fixed. -- dpatel at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24220
[Bug debug/19523] [4.0/4.1/4.2 Regression] DBX_USE_BINCL support broken in the C++ compiler
--- Comment #5 from dpatel at apple dot com 2005-12-06 22:23 --- Created an attachment (id=10430) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10430action=view) zem's patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
[Bug tree-optimization/23115] [4.1 Regression] -ftree-vectorize generates wrong code
--- Comment #8 from dpatel at apple dot com 2005-11-08 02:22 --- tree if-conversion was expecting perfect dimond, but it is not always true after tree-cleanup-branch work. I've started overnight patch test run. Hopefully, I'll send patch tomorrow for review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23115
[Bug debug/19523] [4.0/4.1 Regression] DBX_USE_BINCL support broken in the C++ compiler
--- Comment #3 from dpatel at apple dot com 2005-10-05 17:02 --- Subject: Re: [4.0/4.1 Regression] DBX_USE_BINCL support broken in the C++ compiler AFAIK, It is not about compile time issue. There is another patch available which is better than what is in apple branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
[Bug tree-optimization/23115] [4.1 Regression] -ftree-vectorize generates wrong code
--- Additional Comments From dpatel at apple dot com 2005-09-30 23:52 --- Assign this bug to me. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23115
[Bug debug/20998] [3.4/4.0/4.1 Regression] GCC does not emit debug info for variables in anonymous unions
--- Additional Comments From dpatel at apple dot com 2005-09-09 18:01 --- Subject: Re: [3.4/4.0/4.1 Regression] GCC does not emit debug info for variables in anonymous unions It does not fix gdb.cp/anon-union.exp (from GDB testsuite) failures using darwin GDB. If you do not get any other feedback/info then I'll try to get back to this next week. - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
[Bug tree-optimization/23048] [4.1 Regression] ICE in get_loop_body with -O1 -ftree-vectorize on 4.1.x
--- Additional Comments From dpatel at apple dot com 2005-08-11 19:38 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00612.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048
[Bug tree-optimization/23048] [4.1 Regression] ICE in get_loop_body with -O1 -ftree-vectorize on 4.1.x
--- Additional Comments From dpatel at apple dot com 2005-08-09 18:58 --- Yup. This happens when tree-if-conversion pass is given cfg with one loop structure to represent nested loop. May be this is happenning because inner loop is infinite loop ? Anyway, please assign this bug to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048
[Bug debug/23190] [4.0/4.1 Regression] debug info omitted for uninitialized variables (stabs)
--- Additional Comments From dpatel at apple dot com 2005-08-02 16:52 --- Subject: Re: [4.0/4.1 Regression] debug info omitted for uninitialized variables (stabs) On Aug 1, 2005, at 8:25 PM, mark at codesourcery dot com wrote: In any case, the problem is now either in the C front end or in the DBX generator. Since the DWARF-2 generators do something reasonable, AFAICT, I would guess the problem is in either the DBX generator, or the GDB reader for STABS, or in the STABS format itself. This does not look like STABS or DWARF-2 specific. Right now it does work even in DWARF-2 mode also. With the attached patch it DWARF-2 also works. GCC Mainline === Using stabs === Reading symbols for shared libraries .. done Breakpoint 1 at 0x1d9c: file /tmp/t.c, line 6. type = unknown type type = unknown type $1 = unknown type $2 = unknown type Using DWARF === Reading symbols for shared libraries .. done Breakpoint 1 at 0x2d04: file /tmp/t.c, line 6. type = unknown type type = int $1 = unknown type $2 = 0 GCC Mainline with fix=== Using stabs === Reading symbols for shared libraries .. done Breakpoint 1 at 0x1d9c: file /tmp/t.c, line 6. type = int type = int $1 = 0 $2 = 0 Using DWARF === Reading symbols for shared libraries .. done Breakpoint 1 at 0x2d04: file /tmp/t.c, line 6. type = int type = int $1 = 0 $2 = 0 - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23190
[Bug debug/23190] [4.0/4.1 Regression] debug info omitted for uninitialized variables (stabs)
--- Additional Comments From dpatel at apple dot com 2005-08-02 17:12 --- Subject: Re: [4.0/4.1 Regression] debug info omitted for uninitialized variables (stabs) On Aug 2, 2005, at 10:00 AM, mmitchel at gcc dot gnu dot org wrote: --- Additional Comments From mmitchel at gcc dot gnu dot org 2005-08-02 17:00 --- Devang -- The DWARF-2 information looks correct to me, from the section of DWARF-2 code that you posted in the original report for this bug. I know GDB doesn't print the variable, but I don't think that's the compiler's fault; the information looks OK. Is there something wrong with the DWARF-2 generated, or is this just a GDB bug? Without the patch, GCC does not emit DW_OP_addr and DW_AT_location. I'm not oppposed to making the kind of change you're proposing for the C front end; I suggested the same thing. But, it is a complex change; as you've noted, there are regressions when you try it. There is only one regression. One way to avoid it is to split wrapup_global... in two halves. One to emit code and second to generate debug info. This allows C front end to put cgraph_optimize() after writing globals but before generating debug info. thoughts ? - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23190
[Bug debug/23190] [4.0/4.1 Regression] debug info omitted for uninitialized variables (stabs)
--- Additional Comments From dpatel at apple dot com 2005-08-02 17:21 --- Subject: Re: [4.0/4.1 Regression] debug info omitted for uninitialized variables (stabs) On Aug 2, 2005, at 10:16 AM, mark at codesourcery dot com wrote: It sounds sensible enough, but I really haven't studied how the C front end does things well enough to know for sure. I would ask Joseph and RTH. OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23190
[Bug debug/23205] New: [C++] debug info omitted for global variables
GCC does not emit debug info for variable 'j' in following example, when stabs
debugging format is
used.
const int j = 4;
int foo ()
{
return j + 1;
}
int main()
{
int i;
i = foo();
return i;
}
--
Summary: [C++] debug info omitted for global variables
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23205
[Bug c++/23205] [4.0/4.1 Regression] [C++/unit-at-a-time] debug info omitted for global const variables
--- Additional Comments From dpatel at apple dot com 2005-08-02 19:00 --- Subject: Re: [4.0/4.1 Regression] [C++] debug info omitted for global const variables On Aug 2, 2005, at 11:57 AM, pinskia at gcc dot gnu dot org wrote: You know what is better is just move to dwarf-2 instead for ppc- darwin. :). It works in DWARF mode is not a good excuse to ignore stabs while making various changes in the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23205
[Bug debug/23190] New: debug info omitted for uninitialized variables
$ cat t.c
static int foo;
int bar;
int main(void)
{
foo += 3;
bar *= 5;
return 0;
}
$ xgcc -g -O2 -o t t.c
$ cat gdbcmds
b main
ptype foo
ptype bar
p foo
p bar
$ gdb --batch -x gdbcmds t
Reading symbols for shared libraries ... done
Breakpoint 1 at 0x2d14: file t.c, line 6.
type = unknown type
type = unknown type
$1 = unknown type
$2 = unknown type
[ This was discussed in PR 21828 ]
On Jul 22, 2005, at 4:43 PM, mark at codesourcery dot com wrote:
First, your example was not the one in the original bug report.
Second, you're using STABS, not DWARF-2. I suspect the stabs debug
generator, or the GDB stabs reader is not as good as DWARF.
On GNU/Linux, GDB knows that bar has type int. It still doesn't
know the type of foo; apparently too much of the debug information is
optimized away. But, that's some other problem -- perhaps in GDB
itself. The information is clearly there for it:
.uleb128 0x2# (DIE (0x2d) DW_TAG_variable)
.ascii foo\0 # DW_AT_name
.byte 0x1 # DW_AT_decl_file
.byte 0x1 # DW_AT_decl_line
.long 0x38# DW_AT_type
.uleb128 0x3# (DIE (0x38) DW_TAG_base_type)
.ascii int\0 # DW_AT_name
.byte 0x4 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
It seems this is related to order of cgraph_optimize() and writing globals. If
globals are wrapped up
before emitting code then debug info. is not emitted for uninitialized globals,
because DECL_RTL is not
set. C++ FE writes globals before doing cgraph_optimize(), but C FE optimizes
first. This is why this is
C specific only. This patch fixes this but it causes varpool-1.c test failure.
With this patch, GDB know
about foo as well as bar when DWARF is used.
Index: c-decl.c
===
RCS file: /cvs/gcc/gcc/gcc/c-decl.c,v
retrieving revision 1.677
diff -Idpatel.pbxuser -c -3 -p -r1.677 c-decl.c
*** c-decl.c19 Jul 2005 20:19:09 - 1.677
--- c-decl.c28 Jul 2005 19:22:47 -
*** tree c_cont_label;
*** 131,136
--- 131,139
static GTY(()) tree all_translation_units;
+ /* Outermost block. */
+ static GTY(()) tree ext_block;
+
/* A list of decls to be made automatically visible in each file scope. */
static GTY(()) tree visible_builtins;
*** c_write_global_declarations_1 (tree glob
*** 7570,7576
void
c_write_global_declarations (void)
{
! tree ext_block, t;
/* We don't want to do this if generating a PCH. */
if (pch_file)
--- 7573,7579
void
c_write_global_declarations (void)
{
! tree t;
/* We don't want to do this if generating a PCH. */
if (pch_file)
*** c_write_global_declarations (void)
*** 7586,7591
--- 7589,7598
external_scope = 0;
gcc_assert (!current_scope);
+ /* We're done parsing; proceed to optimize and emit assembly.
+ FIXME: shouldn't be the front end's responsibility to call this. */
+ cgraph_optimize ();
+
/* Process all file scopes in this compilation, and the external_scope,
through wrapup_global_declarations and check_global_declarations. */
for (t = all_translation_units; t; t = TREE_CHAIN (t))
*** c_write_global_declarations (void)
*** 7608,7617
functions have magic names which are detected by collect2. */
build_cdtor ('I', static_ctors); static_ctors = 0;
build_cdtor ('D', static_dtors); static_dtors = 0;
-
- /* We're done parsing; proceed to optimize and emit assembly.
- FIXME: shouldn't be the front end's responsibility to call this. */
- cgraph_optimize ();
}
#include gt-c-decl.h
--- 7615,7620
--
Summary: debug info omitted for uninitialized variables
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23190
[Bug debug/21828] [4.0 Regression] debug info omitted for uninitialized variables
--- Additional Comments From dpatel at apple dot com 2005-07-22 23:29
---
Subject: Re: [4.0 Regression] debug info omitted for uninitialized variables
On Jul 22, 2005, at 12:33 PM, cvs-commit at gcc dot gnu dot org wrote:
--- Additional Comments From cvs-commit at gcc dot gnu dot org
2005-07-22 19:33 ---
Subject: Bug 21828
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by:[EMAIL PROTECTED]2005-07-22 19:33:16
Modified files:
gcc: ChangeLog toplev.c varasm.c
gcc/testsuite : ChangeLog
Added files:
gcc/testsuite/gcc.dg/debug/dwarf2: dwarf-uninit.c
Log message:
PR debug/21828
* toplev.c (check_global_declarations): Do not mark undefined
variables as DECL_IGNORED_P.
* varasm.c (first_global_object_name): GTY it.
(weak_global_object_name): Likewise.
(notice_global_symbol): Use ggc_strdup, not xstrdup, when creating
a string to go into {weak,first}_global_object_name.
PR debug/21828
* gcc.dg/debug/dwarf2/dwarf-uninit.c: New test.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?
cvsroot=gcconly_with_tag=gcc-4_0-
branchr1=2.7592.2.327r2=2.7592.2.328
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?
cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.944.2.4r2=1.944.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?
cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.477.6.12r2=1.477.6.13
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/
ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-
branchr1=1.5084.2.293r2=1.5084.2.294
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/
debug/dwarf2/dwarf-uninit.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-
branchr1=NONEr2=1.1.2.1
After this check-in :
$ cat t.c
static int foo;
int bar;
int main(void)
{
foo += 3;
bar *= 5;
return 0;
}
$ xgcc -g -O2 -o t t.c
$ cat gdbcmds
b main
ptype foo
ptype bar
p foo
p bar
$ gdb --batch -x gdbcmds t
Reading symbols for shared libraries ... done
Breakpoint 1 at 0x2d14: file t.c, line 6.
type = unknown type
type = unknown type
$1 = unknown type
$2 = unknown type
This is on powerpc-darwin. I expected this patch to fix this. Am I
missing something ?
Thanks,
-
Devang
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug debug/21828] [4.0/4.1 Regression] debug info omitted for uninitialized variables
--- Additional Comments From dpatel at apple dot com 2005-07-19 22:22 --- No activity in last few days. Mark, would it be possible for you to take a look at this again! Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug tree-optimization/21272] SSA_NAME def follows use with -ftree-vectorize
--- Additional Comments From dpatel at apple dot com 2005-04-29 00:45 --- Subject: Re: New: SSA_NAME def follows use with -ftree-vectorize It's my think-o. Try this, Index: tree-if-conv.c === RCS file: /cvs/gcc/gcc/gcc/tree-if-conv.c,v retrieving revision 2.38 diff -Idpatel.pbxuser -c -3 -p -r2.38 tree-if-conv.c *** tree-if-conv.c 21 Apr 2005 17:02:15 - 2.38 --- tree-if-conv.c 29 Apr 2005 00:44:04 - *** find_phi_replacement_condition (struct l *** 701,707 basic_block tmp_bb; tmp_bb = first_bb; first_bb = second_bb; ! second_bb = first_bb; } /* Check if FIRST_BB is loop header or not. */ --- 701,707 basic_block tmp_bb; tmp_bb = first_bb; first_bb = second_bb; ! second_bb = tmp_bb; } /* Check if FIRST_BB is loop header or not. */ - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21272
[Bug java/21164] New: libjava tests uses absolute paths
libjava tests uses absolute paths e.g. bytecompile /Volumes/SandBox/rt/src/gcc/libjava/testsuite/libjava.jni/noclass.java bytecompile /Volumes/SandBox/rt/src/gcc/libjava/testsuite/libjava.jni/overload.java bytecompile /Volumes/SandBox/rt/src/gcc/libjava/testsuite/libjava.jni/pr11951.java This is very inconvenient to compare tests agains known base results. -- Summary: libjava tests uses absolute paths Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dpatel at apple dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21164
[Bug preprocessor/20907] [4.0/4.1 Regression] long comments throw off line numbers
--- Additional Comments From dpatel at apple dot com 2005-04-21 17:26 --- Subject: Re: [4.0/4.1 Regression] long comments throw off line numbers Would it be possible for you to add one test case also ? Thanks, - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20907
[Bug tree-optimization/20994] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From dpatel at apple dot com 2005-04-18 17:23 --- Subject: Re: [4.1 regression] ICE with -ftree-vectorize This is because invert_truthvalue() does not return valid GIMPLE expr. I've a patch, once it passes usual test cycle, I'll post patch. - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20994
[Bug debug/20998] New: GCC does not emit debug info for variables in anonymous unions
Here is the simple C++ program :
int main()
{
union {
int z;
unsigned int w;
}; w = 0;
}
--
Summary: GCC does not emit debug info for variables in anonymous
unions
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
[Bug debug/20998] GCC does not emit debug info for variables in anonymous unions
--- Additional Comments From dpatel at apple dot com 2005-04-13 18:19 --- Subject: Re: GCC does not emit debug info for variables in anonymous unions It is because of ALIAS_DECL -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
[Bug tree-optimization/21010] New gcc.dg/vect tests fail
--- Additional Comments From dpatel at apple dot com 2005-04-13 22:47
---
Subject: Re: New: New gcc.dg/vect tests fail
But all of them require
/* { dg-require-effective-target vect_condition } */
So, why they fail on other platforms ?
-
Devang
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21010
[Bug testsuite/21010] New gcc.dg/vect tests fail
--- Additional Comments From dpatel at apple dot com 2005-04-14 00:44 --- Subject: Re: New gcc.dg/vect tests fail Thanks everyone! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21010
[Bug preprocessor/20907] New: long comments throw off line numbers
It seems that long comment blocks can throw off gcc's notion of the source line
number. Here is a
sample test case (also attached in case the line breaks get messed up pasting
in):
/*
This is a really long comment. This is a really long comment. This is a really
long comment. This is a
really long comment. This is a really long comment. This is a really long
comment. This is a really long
comment. This is a really long comment. This is a really long comment. This is
a really long comment.
This is a really long comment. This is a really long comment. This is a really
long comment. This is a
really long comment. This is a really long comment. This is a really long
comment.
*/
#warning test warning
#include stdio.h
int main(int argc, char *argv)
{
printf(This is line %d\n, __LINE__);
}
--
Summary: long comments throw off line numbers
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20907
[Bug debug/20253] [3.4/4.0/4.1 regression]: Macro debug info broken due to lexer change
--- Additional Comments From dpatel at apple dot com 2005-03-01 18:18 --- Subject: Re: [3.4/4.0/4.1 regression]: Macro debug info broken due to lexer change On Mar 1, 2005, at 10:00 AM, dberlin at gcc dot gnu dot org wrote: I'll fix this bug if someone can test the fix on a stabs machine for me. I can run gdb test suite on powerpc-darwin. Note: FSF gdb does not have darwin port so darwin gdb is not similar to the one used by other stabs platform. - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20253
[Bug debug/20253] [3.4/4.0/4.1 regression]: Macro debug info broken due to lexer change
--- Additional Comments From dpatel at apple dot com 2005-02-28 20:48 --- Subject: Re: [3.4/4.0/4.1 regression]: Macro debug info broken due to lexer change I extensively tested my patch using GDB tests suites on two target with STABS as well as DWARF. But if, we need to have a start_source_file for the main source file then we we also need to have end_source_file for main source file. I was just trying to balance BINCL/EINCL counts. And nobody noticed this until now. Andrew, would it be possible for you to try this? Thanks, - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20253
[Bug tree-optimization/19952] ICE: tree check: expected class 'declaration', have 'statement' (label_expr) in tree_verify_flow_info, at tree-cfg.c:3709
--- Additional Comments From dpatel at apple dot com 2005-02-18 19:02 --- Subject: Re: ICE: tree check: expected class 'declaration', have 'statement' (label_expr) in tree_verify_flow_info, at tree-cfg.c:3709 ok - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19952
[Bug driver/19180] New: How to Add New GCC option
This is an enhancement request to document step-by-step How to Add New GCC options guide. Another request : Need Documentation component in Bugzilla. Reference : http://gcc.gnu.org/ml/gcc/2004-12/msg01147.html -- Summary: How to Add New GCC option Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dpatel at apple dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19180
[Bug tree-optimization/19067] ICE in tree-if-conv
--- Additional Comments From dpatel at apple dot com 2004-12-20 20:05 --- Subject: Re: ICE in tree-if-conv I'll verify whether TCB patch works here or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19067
[Bug tree-optimization/19067] ICE in tree-if-conv
--- Additional Comments From dpatel at apple dot com 2004-12-20 20:32 --- Subject: Re: ICE in tree-if-conv On Dec 18, 2004, at 10:28 AM, pinskia at gcc dot gnu dot org wrote: I don't know but could possible the patch in here: http://gcc.gnu.org/ml/gcc-patches/2004-12/ msg00514.html which is already on the tcb branch help here? Yes, this patch helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19067
[Bug preprocessor/19040] New: #elif token1 token2 doesn't produce a diagnostic
GCC emits diagnostics for following...
$ cat a.c
int foo()
{
#ifdef FOO
return 1;
#elif BAR FOO
return 0;
#endif
}
$ cc a.c -c
a.c:6:11: error: missing binary operator before token FOO
$
However, it does not emit diagnostics for following ...
$ cat a.c
#define FOO 1
int foo()
{
#ifdef FOO
return 1;
#elif BAR FOO
return 0;
#endif
}
--
Summary: #elif token1 token2 doesn't produce a diagnostic
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19040
[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic
--- Additional Comments From dpatel at apple dot com 2004-12-16 21:07 --- Subject: Re: #elif token1 token2 doesn't produce a diagnostic On Dec 16, 2004, at 1:01 PM, bangerth at dealii dot org wrote: That's because it doesn't have to evaluate the #elif condition any more, since it has already taken the #ifdef branch. But that's the point. My reading of C99 standard does not give preprocessor this freedom. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19040
[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic
--- Additional Comments From dpatel at apple dot com 2004-12-16 22:54 --- Subject: Re: #elif token1 token2 doesn't produce a diagnostic Neil, Would it be possible to quote standard here? We encountered this while running Plum Hall tests, so I just wanted to make sure. Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19040
[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic
--- Additional Comments From dpatel at apple dot com 2004-12-17 01:04 --- Subject: Re: #elif token1 token2 doesn't produce a diagnostic Never mind, someone led me to believe that this is a Plum Hall test failure. It is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19040
[Bug tree-optimization/18441] Vectorizer: add a command line for simple vectorizer report
--- Additional Comments From dpatel at apple dot com 2004-12-13 20:16 --- Try -fdump-tree-vect-stats. It produces more user friendly output compared to -details. I am not fan of putting such diagnostics as part of warnings/info/errors. IMO, we should enhance/ update -fdump-tree-vect-stats to meet user's requirements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18441
[Bug tree-optimization/18815] Tree if-conversion screws up cfg very badly
--- Additional Comments From dpatel at apple dot com 2004-12-04 03:23 --- Indeed. Lack of exit edge is causing this. Please assign this PR to me. Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18815
[Bug driver/18760] New: gcc 4.0 doesn't emit debug info for one of the files if two files are given on the same compile line
Following command line does not generate debug info for bar.c gcc -gfull -O0 foo.c bar.c -o foobar -gfull is a Darwin specific compiler option. -- Summary: gcc 4.0 doesn't emit debug info for one of the files if two files are given on the same compile line Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dpatel at apple dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-darwin GCC host triplet: powerpc-darwin GCC target triplet: powerpc-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18760
[Bug target/18760] gcc 4.0 doesn't emit debug info for one of the files if two files are given on the same compile line
--- Additional Comments From dpatel at apple dot com 2004-12-01 18:43 --- Subject: Re: gcc 4.0 doesn't emit debug info for one of the files if two files are given on the same compile line Yes :). I have the patch to fix it. Once bootstrap and make check finishes, I will post it for review/approval. - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18760
[Bug driver/15690] [4.0 Regression] compilation stops after the first file with errors
--- Additional Comments From dpatel at apple dot com 2004-11-30 22:12 --- Subject: Re: [4.0 Regression] compilation stops after the first file with errors I am testing patch to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15690
[Bug driver/18732] New: Compiler will not compile two source files if first has error or is unreadable
$echo 'int foo([EMAIL PROTECTED])' bad.c
$echo 'int foo(void) { return 0; }' good.c
$
$gcc-4.0 -c bad.c good.c
Earlier compiler will generate good.o
--
Summary: Compiler will not compile two source files if first has
error or is unreadable
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18732
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From dpatel at apple dot com 2004-11-18 19:09 --- Subject: Re: ICE in do_jump, at dojump.c:274 On Nov 18, 2004, at 12:03 AM, paolo dot bonzini at lu dot unisi dot ch wrote: While I can work on a fix, those COND_EXPR were *not* valid GIMPLE at the time the patch was written. I agree with you. While cleanup this stuff, you even cc'ed us and left some stuff around. May be we can update rewrite_outof_ssa()? See example I included above. - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18308
[Bug other/18555] Need a command line switch to control gcc's include and libary finding mechanism
--- Additional Comments From dpatel at apple dot com 2004-11-19 01:21 --- It seems -isysroot may do the task here. I see its implementation in c-opts.c, but unfortunetly 1) it is not documented in cppopts.texi and 2) driver has one bug that causes it to eat isysroot argument. I will investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18555
[Bug other/18555] Need a command line switch to control gcc's include and libary finding mechanism
--- Additional Comments From dpatel at apple dot com 2004-11-19 01:59 --- Patch to fix driver, http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01534.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18555
[Bug tree-optimization/17635] [4.0 regression] ICE in verify_ssa: type mismatch
--- Additional Comments From dpatel at apple dot com 2004-11-17 22:13 --- Subject: Re: [4.0 regression] ICE in verify_ssa: type mismatch On Nov 13, 2004, at 5:55 AM, reichelt at gcc dot gnu dot org wrote: --- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-13 13:54 --- Devang, your patch http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00591.html is responsible for the new ICE. I've fixed this one. But it seems, I am not out of wood yet. - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17635
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From dpatel at apple dot com 2004-11-18 01:27 --- Bigger issue is : if-convert COND_EXPR is not vectorized and do_jump() does not aborts(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18308
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From dpatel at apple dot com 2004-11-18 01:28 --- I meant, Bigger issue is : if-convert COND_EXPR is not vectorized and do_jump() does not handle it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18308
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From dpatel at apple dot com 2004-11-18 02:26
---
After I update tree-level if-conversion to force gimple operands appropriately,
rewrite_out_of_ssa() is
converting following ...
bar()
{
_Bool _ifc_.3;
_Bool _ifc_.2;
_Bool D.1339;
_Bool D.1336;
_Bool D.1337;
_Bool D.1338;
_Bool _ifc_.1;
unsigned int ivtmp.0;
int k;
int j;
int i;
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
k_21 = j_6 != 0 ? 2 : 0;
k_5 = j_6 == 0 ? k_21 : 2;
if (k_5 != 0) goto L5; else goto L6;
# SUCC: 1 [46.5%] (true,exec) 2 [53.5%] (false,exec)
# BLOCK 1
# PRED: 0 [46.5%] (true,exec)
L5:;
# .GLOBAL_VAR_10 = V_MAY_DEF .GLOBAL_VAR_9;
foo () [tail call];
# SUCC: 2 [100.0%] (fallthru,exec)
# BLOCK 2
# PRED: 0 [53.5%] (false,exec) 1 [100.0%] (fallthru,exec)
L6:;
return;
# SUCC: EXIT [100.0
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From dpatel at apple dot com 2004-11-18 02:33
---
Subject: Re: ICE in do_jump, at dojump.c:274
Andrew,
You can try following to fix tree level if-conversion. I have not
tested it completely yet.
-
Devang
Index: tree-if-conv.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-if-conv.c,v
retrieving revision 2.19
diff -Idpatel.pbxuser -c -3 -p -r2.19 tree-if-conv.c
*** tree-if-conv.c 16 Nov 2004 20:02:48 - 2.19
--- tree-if-conv.c 18 Nov 2004 02:32:03 -
*** add_to_dst_predicate_list (struct loop *
*** 639,645
new_cond = unshare_expr (cond);
else
{
! tree tmp_stmt;
/* new_cond == prev_cond AND cond */
tree tmp = build (TRUTH_AND_EXPR, boolean_type_node,
unshare_expr (prev_cond), cond);
--- 639,655
new_cond = unshare_expr (cond);
else
{
! tree tmp_stmt = NULL_TREE;
! tree tmp_stmts1 = NULL_TREE;
! tree tmp_stmts2 = NULL_TREE;
! prev_cond = force_gimple_operand (unshare_expr (prev_cond),
tmp_stmts1, true, NULL);
! if (tmp_stmts1)
! bsi_insert_before (bsi, tmp_stmts1, BSI_SAME_STMT);
!
! cond = force_gimple_operand (unshare_expr (cond), tmp_stmts2,
true, NULL);
! if (tmp_stmts2)
! bsi_insert_before (bsi, tmp_stmts2, BSI_SAME_STMT);
!
/* new_cond == prev_cond AND cond */
tree tmp = build (TRUTH_AND_EXPR, boolean_type_node,
unshare_expr (prev_cond), cond);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18308
