[Bug c++/5520] Add a warning to detect empty body of if statements (like in the C frontend)
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-01-20 09:30 --- Subject: Bug 5520 Author: rguenth Date: Fri Jan 20 09:30:22 2006 New Revision: 110019 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110019 Log: 2006-01-20 Dirk Mueller <[EMAIL PROTECTED]> PR c++/5520 * c-parser.c (c_parser_if_body): Use build_empty_stmt() instead of a special NOP marker. * c-typeck.c (c_finish_if_stmt): Remove obsoleted special NOP marker handling. * c-common.h (empty_body_warning): Add forward declaration. * c-common.c (empty_body_warning): Add (from c_finish_if_stmt). Now uses IS_EMPTY_STMT() instead of special NOP markers. * semantics.c (finish_if_stmt): Call empty_body_warning. * parser.c (cp_parser_implicitly_scoped_statement): Mark empty statement with an empty stmt. * g++.dg/warn/empty-body.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/empty-body.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-parser.c trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5520
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
--- Comment #61 from rguenth at gcc dot gnu dot org 2006-01-20 09:39 --- Subject: Bug 24626 Author: rguenth Date: Fri Jan 20 09:38:56 2006 New Revision: 110020 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110020 Log: 2006-01-20 Richard Guenther <[EMAIL PROTECTED]> Steven Bosscher <[EMAIL PROTECTED]> PR rtl-optimization/24626 * cfgloopmanip.c (lv_adjust_loop_entry_edge): Don't set EDGE_TRUE_VALUE if in RTL mode. Revert 2005-03-30 Mostafa Hagog <[EMAIL PROTECTED]> * cfgrtl.c (rtl_verify_flow_info_1): Fix. * gcc.dg/torture/pr24626-1.c: New testcase. * gcc.dg/torture/pr24626-2.c: Likewise. * gcc.dg/torture/pr24626-3.c: Likewise. * gcc.dg/torture/pr24626-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr24626-1.c trunk/gcc/testsuite/gcc.dg/torture/pr24626-2.c trunk/gcc/testsuite/gcc.dg/torture/pr24626-3.c trunk/gcc/testsuite/gcc.dg/torture/pr24626-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloopmanip.c trunk/gcc/cfgrtl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug rtl-optimization/24626] [4.1 Regression] internal compiler error: verify_flow_info failed
--- Comment #62 from rguenth at gcc dot gnu dot org 2006-01-20 09:44 --- Done. Let the flames come down to the two of us. :/ (I agree on the "obviousness" of the patch, but the part reverting Mostafas "fix" and four testcases made the patch somewhat big). So, fixed on mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.3.3 |3.3.3 4.2.0 Summary|[4.1/4.2 Regression]|[4.1 Regression] internal |internal compiler error:|compiler error: |verify_flow_info failed |verify_flow_info failed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug c++/5520] Add a warning to detect empty body of if statements (like in the C frontend)
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-01-20 10:11 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5520
[Bug c++/25868] [3.4/4.0/4.1/4.2 Regression] Multiple templates and typedefs cause function prototype not to match
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-20 10:19 --- Confirmed. I can't see anything wrong with the testcase. EDG accepts it in -strict_ansi mode, as does the old C++ parser. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||rejects-valid Known to fail||3.4.5 4.0.3 4.1.0 4.2.0 Known to work||3.3.6 Last reconfirmed|-00-00 00:00:00 |2006-01-20 10:19:41 date|| Summary|Multiple templates and |[3.4/4.0/4.1/4.2 Regression] |typedefs cause function |Multiple templates and |prototype not to match |typedefs cause function ||prototype not to match http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
[Bug tree-optimization/25860] [4.2 Regression] ice with -g -O2 -fPIC
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-20 10:31 --- Crashes in PRE: #0 fancy_abort ( file=0x8706c14 "../../../src/svn/gcc/gcc/tree-ssa-operands.c", line=1563, function=0x870743d "add_stmt_operand") at diagnostic.c:602 #1 0x0815126d in add_stmt_operand (var_p=0x40194670, s_ann=0x40225ea0, flags=3) at tree-ssa-operands.c:1563 #2 0x0814d55f in get_expr_operands (stmt=0x40194654, expr_p=0x40194670, flags=3) at tree-ssa-operands.c:1065 #3 0x0814b451 in parse_ssa_operands (stmt=0x40194654) at tree-ssa-operands.c:739 #4 0x0814b8f6 in build_ssa_operands (stmt=0x40194654) at tree-ssa-operands.c:801 #5 0x0814c014 in update_stmt_operands (stmt=0x40194654) at tree-ssa-operands.c:842 #6 0x080fd835 in update_stmt (t=0x40194654) at tree-flow-inline.h:280 #7 0x080fd744 in mark_new_vars_to_rename (stmt=0x40194654) at tree-dfa.c:824 #8 0x085fe621 in create_expression_by_pieces (block=0x401952d0, expr=0x887cbc8, stmts=0x40224f18) at tree-ssa-pre.c:2181 #9 0x085fd87c in find_or_generate_expression (block=0x401952d0, expr=0x40192780, stmts=0x40224f18) at tree-ssa-pre.c:2029 #10 0x085fdc75 in create_expression_by_pieces (block=0x401952d0, expr=0x887c1f8, stmts=0x40224f18) at tree-ssa-pre.c:2080 #11 0x085fedfe in insert_into_preds_of_block (block=0x40195370, node=0x887d58c, avail=0x8868710) at tree-ssa-pre.c:2286 #12 0x085ff51a in insert_aux (block=0x40195370) at tree-ssa-pre.c:2490 #13 0x085ff633 in insert_aux (block=0x401952d0) at tree-ssa-pre.c:2522 #14 0x085ff633 in insert_aux (block=0x40195230) at tree-ssa-pre.c:2522 #15 0x085ff6f6 in insert () at tree-ssa-pre.c:2544 #16 0x08603f24 in execute_pre (do_fre=0 '\0') at tree-ssa-pre.c:3597 #2 0x0814d55f in get_expr_operands (stmt=0x40194654, expr_p=0x40194670, flags=3) at tree-ssa-operands.c:1065 1065 class = TREE_CODE_CLASS (code); (gdb) call debug_generic_expr (stmt) pretmp.22D.1557_3 = *NoteD.1526_5 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
[Bug c++/25873] New: [gomp] ICE in verify_eh_throw_stmt_node
The following code crashes the C++ frontend gomp-branch as of today
(yesterdays version worked fine):
void foo()
{
#pragma omp parallel
foo();
}
bug.cc: In function 'void foo()':
bug.cc:1: internal compiler error: in verify_eh_throw_stmt_node, at
tree-eh.c:2085
Please submit a full bug report, [etc.]
--
Summary: [gomp] ICE in verify_eh_throw_stmt_node
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: monitored, openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25873
[Bug rtl-optimization/24626] [4.1 Regression] internal compiler error: verify_flow_info failed
--- Comment #63 from steven at gcc dot gnu dot org 2006-01-20 12:05 --- I still think there should be a comment in cfgloopmanip explaining the use of ir_type there, but I'll take care of that with the additional-checking patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #36 from matz at suse dot de 2006-01-20 14:01 --- Yes. Should be done shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/25869] [4.2 regression] MMIX broken: ICE compiling __divti3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25869
[Bug pending/25870] GCC 3.4.5 java compiler bootstrap failure.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-20 14:06 --- This is a bug in your installation (distro's problem) of GNU/Linux. Use --disable-mulitlib unless you need a 32bit gcj and if you do please report the issue to slackware as it is an issue there and not in GCC. -- 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=25870
[Bug target/25871] TRAMPOLINE_TEMPLATE uses 32bit moves on 64bit code
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-20 14:10 --- Conifmred but this is actually not a regression from any versions of GCC (after the EGCS split) that I can tell from as the source has not changed that much. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-20 14:10:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25871
[Bug c++/25868] [3.4/4.0/4.1/4.2 Regression] Multiple templates and typedefs cause function prototype not to match
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #19 from danglin at gcc dot gnu dot org 2006-01-20 14:30 --- Subject: Bug 24533 Author: danglin Date: Fri Jan 20 14:30:33 2006 New Revision: 110025 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110025 Log: PR ada/24533 * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-linux-hppa.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #20 from danglin at gcc dot gnu dot org 2006-01-20 14:32 --- Subject: Bug 24533 Author: danglin Date: Fri Jan 20 14:32:10 2006 New Revision: 110026 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110026 Log: PR ada/24533 * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. Modified: branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/s-osinte-linux-hppa.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #21 from danglin at gcc dot gnu dot org 2006-01-20 14:34 --- Subject: Bug 24533 Author: danglin Date: Fri Jan 20 14:34:29 2006 New Revision: 110027 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110027 Log: PR ada/24533 * s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8. Modified: branches/gcc-4_0-branch/gcc/ada/ChangeLog branches/gcc-4_0-branch/gcc/ada/s-osinte-linux-hppa.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug c++/25874] New: [gomp branch] ICE in calc_dfs_tree()
Current g++ from the gomp branch ICEs on the attached test case, but only when -O and -fopenmp is specified: ~/data/planck/LevelS>g++ -v -O -fopenmp -c bug.ii Using built-in specs. Target: i686-pc-linux-gnu Configured with: /scratch/gompcc/configure --quiet --prefix=/scratch/ugccgomp --enable-languages=c++,fortran --with-gmp=/usr/local/appl/gmp-4.1.4 --enable-checking=release Thread model: posix gcc version 4.2.0-gomp-20050608-branch 20060119 (experimental) (merged 20060119) /scratch/ugccgomp/libexec/gcc/i686-pc-linux-gnu/4.2.0-gomp-20050608-branch/cc1plus -fpreprocessed bug.ii -quiet -dumpbase bug.ii -mtune=generic -auxbase bug -O -version -fopenmp -o /tmp/ccpzsCty.s GNU C++ version 4.2.0-gomp-20050608-branch 20060119 (experimental) (merged 20060119) (i686-pc-linux-gnu) compiled by GNU C version 4.2.0-gomp-20050608-branch 20060119 (experimental) (merged 20060119). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: e3aef40c574c8b69824cf08633defc10 Healpix_cxx/alm_powspec_tools.cc: In function 'void rotate_alm(Alm >&, double, double, double) [with T = double]': Healpix_cxx/alm_powspec_tools.cc:396: internal compiler error: in calc_dfs_tree, at dominance.c:373 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. This problem did not exist a few days ago. Sorry for the long test case; I hope I can reduce it over the weekend. -- Summary: [gomp branch] ICE in calc_dfs_tree() Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg 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=25874
[Bug c++/25874] [gomp branch] ICE in calc_dfs_tree()
--- Comment #1 from martin at mpa-garching dot mpg dot de 2006-01-20 14:41 --- Created an attachment (id=10685) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10685&action=view) test case to reproduce the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25874
[Bug c/25875] New: [4.1/4.2 Regression] ICE: segmentation fault
ICEs with 4.1 and 4.2 (but not 4.0):
typedef union {
} ktime_t;
static inline ktime_t ktime_set(const long secs, const unsigned long nsecs)
{
return (ktime_t) { .tv = { .sec = (s32)ts.tv_sec,
.nsec = (s32)ts.tv_nsec } };
--
Summary: [4.1/4.2 Regression] ICE: segmentation fault
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25875
[Bug c/25875] [4.1/4.2 Regression] ICE: segmentation fault
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Keywords||error-recovery Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25875
[Bug c/25875] [4.1/4.2 Regression] ICE: segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 14:51 --- backtrace: #0 0x00052510 in digest_init (type=0x42ca5960, init=0x0, strict_string=1 '\001', require_constant=0) at /Users/pinskia/src/gcc/alias/gcc/gcc/c-typeck.c:4497 #1 0x00050ef0 in store_init_value (decl=0x42ca5ae0, init=0x0) at /Users/pinskia/src/gcc/alias/gcc/gcc/c-typeck.c:4260 #2 0x0001ac88 in build_compound_literal (type=0x42ca5960, init=0x0) at /Users/pinskia/src/gcc/alias/gcc/gcc/c-decl.c:3674 #3 0x000c6f78 in c_parser_postfix_expression_after_paren_type (parser=0x42c13090, type_name=0x4201116c) at /Users/pinskia/src/gcc/alias/gcc/gcc/c-parser.c:5390 #4 0x000c4fa4 in c_parser_cast_expression (parser=0x42c13090, after=0x0) at /Users/pinskia/src/gcc/alias/gcc/gcc/c-parser.c:4664 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-20 14:51:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25875
[Bug tree-optimization/25860] [4.2 Regression] ice with -g -O2 -fPIC
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-01-20 14:59 --- Subject: Re: [4.2 Regression] ice with -g -O2 -fPIC Yes, this is an easy bug to fix. What happens is PRE things it can PRE anything that is just a bunch of indirect_ref's, but in reality, there is one case of that it can't handle. Which is this. When the INDIRECT_REF's type is an aggregate, it will try to create an expression that is invalid GIMPLE. This one is actually not a trivial problem to fix ATM (in this case, eliminate would need to be changed as well), so it would be best to just change the can_PRE_operation to have something like: || (TREE_CODE (op) == INDIRECT_REF && !AGGREGATE_TYPE_P (TREE_TYPE (op If someone wants to bootstrap and test that fix before i get to it in the next week or so, that's fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
[Bug bootstrap/25859] gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot open
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-20 15:08 --- Subject: Re: gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot open > Indeed, gnatmake has to be handled specially. > > So I guess the gnatmake rule needs to use $(GCC_LINK) > one way or another (although there should be no difference between > trubk and 4.1 in that respect). It's not possible to use $(GCC_LINK) directly because of the quotes in the define of GCC_LINK. It might be best to remove them and modify each use as necessary. However, the following change is less invasive and fixes the problem. Thoughts. Dave --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-20 15:08 --- Created an attachment (id=10686) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10686&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25859
[Bug libgomp/25877] New: team.c:269: warning: implicit declaration of function 'alloca'
/mnt/gnu/gcc-3.3/objdir/./gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgomp -I. -I../../../gcc/libgomp/config/posix -I../../../gcc/libgomp -Wall -pthread -Werror -O2 -g -O2 -MT team.lo -MD -MP -MF .deps/team.Tpo - c ../../../gcc/libgomp/team.c -fPIC -DPIC -o .libs/team.o cc1: warnings being treated as errors ../../../gcc/libgomp/team.c: In function 'gomp_team_start': ../../../gcc/libgomp/team.c:269: warning: implicit declaration of function 'alloca' ../../../gcc/libgomp/team.c:269: warning: incompatible implicit declaration of built-in function 'alloca' make[4]: *** [team.lo] Error 1 make[4]: Leaving directory `/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libgomp' -- Summary: team.c:269: warning: implicit declaration of function 'alloca' Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25877
[Bug c++/25878] New: Excessive memory and compile-time with std::map init sequence
The attached testcase needs an excessive amount of memory and compile-time to build with -O2. 500MB max. virtual memory and 1m10s compile-time on a x86_64 machine. The problem is inlining causes the CodeMaps::CodeMaps constructor to explode in CFG size (also due to exception handling). -- Summary: Excessive memory and compile-time with std::map init sequence Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: memory-hog Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug libgomp/25877] [4.2 Regression] team.c:269: warning: implicit declaration of function 'alloca'
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 15:21 --- Also happens on solaris. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|hppa2.0w-hp-hpux11.11 | GCC host triplet|hppa2.0w-hp-hpux11.11 | GCC target triplet|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11, ||solaris Keywords||build Last reconfirmed|-00-00 00:00:00 |2006-01-20 15:21:06 date|| Summary|team.c:269: warning:|[4.2 Regression] team.c:269: |implicit declaration of |warning: implicit |function 'alloca' |declaration of function ||'alloca' Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25877
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-20 15:23 --- Created an attachment (id=10688) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10688&action=view) testcase Preprocessed testcase, preprocessed with gcc 4.1 on a SuSE 10.1 beta x86_64. I minimized it for topformflat level 0 and 0 with namespaces expanded. Minimizing for level 1 minimized too far. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug tree-optimization/25879] New: [4.2 Regression] TDF_CHAIN makes -fdump-tree-all-all useless
A simple example like:
ypedef int nl_item;
extern char *nl_langinfo (nl_item __item) __attribute__ ((__nothrow__));
char *
xtermEnvEncoding(void)
{
static char *result;
if (result == 0) {
result = nl_langinfo(1);
;
}
return result;
}
---
and compile with -O2 -fdump-tree-pre-all makes the dump look like:
xtermEnvEncoding ()
{
static charD.1 long intD.2 unsigned intD.3 long unsigned intD.4 long long
intD.5 long long unsigned intD.6 short intD.7 short unsigned intD.8 signed
charD.9 unsigned charD.10 D.11 D.12 D.13 D.14 D.15 D.16 D.17 D.18 D.19 D.20
floatD.21 doubleD.22 long doubleD.23 _Decimal32D.24 _Decimal64D.25
_Decimal128D.26 complex intD.27 complex floatD.28 complex doubleD.29 complex
long doubleD.30 voidD.31 __builtin_va_listD.32 ..
Cut off for Bugzilla.
That junk makes -fdump-tree-all-all useless now.
--
Summary: [4.2 Regression] TDF_CHAIN makes -fdump-tree-all-all
useless
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25879
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-20 15:26 ---
Basically, the initialization sequence expands to a sequence of (.03.gimple):
__comp_ctor (&D.68628);
try
{
__comp_ctor (&D.68629, &"ab"[0], &D.68628);
try
{
D.70658 = &this->iso639_1;
D.70666 = operator[] (D.70658, &D.68629);
D.70667 = operator= (D.70666, &"Abkhazian"[0]);
__comp_ctor (&D.68625);
try
{
__comp_ctor (&D.68626, &"abk"[0], &D.68625);
try
{
D.70659 = &this->iso639_2;
D.70668 = operator[] (D.70659, &D.68626);
operator= (D.70668, D.70667);
}
}
finally
{
__comp_dtor (&D.68626);
}
}
finally
{
__comp_dtor (&D.68625);
}
}
finally
{
__comp_dtor (&D.68629);
}
}
finally
{
__comp_dtor (&D.68628);
}
Now do this 472 times and you're screwed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug tree-optimization/25879] [4.2 Regression] TDF_CHAIN makes -fdump-tree-all-all useless
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 15:34 --- Created an attachment (id=10689) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10689&action=view) patch which removes TDF_CHAIN and changes debug_tree_chain to debug_decl_chain This patch removes TDF_CHAIN and it also changes debug_tree_chain to debug_decl_chain for the correct meaning of the function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25879
[Bug tree-optimization/25879] [4.2 Regression] TDF_CHAIN makes -fdump-tree-all-all useless
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25879
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-20 15:37 --- This is all due to recursive inlining IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug rtl-optimization/15792] missed subreg optimization
--- Comment #4 from tony dot linthicum at amd dot com 2006-01-20 15:48
---
I've been looking at this a bit, and tried the patch. It does indeed fix the
problem in test1 above, but it does not appear to be the complete solution.
The load of 'x' in test1 is actually split fairly early, and from what I can
tell, the superfluous move is actually the result of the register allocator
doing a poor job of live range analysis when confronted with subregs. I
suspect this is why most things (i.e. those things other than branches) are not
split into subregs until after reload. Unfortunately, the subreg lowering
won't touch a subreg if it's seen a reference to the "inner" register so we get
the same unnecessary move if the code looks like:
foo(long long y, long long z)
{
unsigned long long x;
x = y + z;
if (x) gh();
}
I'm going to experiment with moving where the subreg lowering code occurs and
moving up the splitting into subregs and see if I can get the desired results.
I'm pretty new to GCC, so if any of the above seems like I'm off in the weeds
then please let me know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-20 15:48 --- This is all caused by C++ and temporary variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-20 15:50 --- At .ssa we have for the posted fragment the following loads of basic blocks and exception objects: : D.68636_176 = &this_1->iso639_1; D.68641_177 = operator[] (D.68636_176, &D.68639); : this_230 = (struct basic_string,std::allocator > * const) D.68641_177; __s_231 = &"Abkhazian"[0]; this_232 = this_230; __s_233 = __s_231; __s_234 = __s_233; D.76438_235 = strlen (__s_234); D.76432_236 = D.76438_235; D.76433_237 = assign (this_232, __s_233, D.76432_236); : D.76434_238 = D.76433_237; D.76435_239 = D.76434_238; D.76436_240 = D.76435_239; D.68642_241 = D.76436_240; this.146_242 = (struct new_allocator *) &D.68644; this_243 = (struct new_allocator * const) this.146_242; __comp_ctor (&D.68643, &"abk"[0], &D.68644); : D.68637_248 = &this_1->iso639_2; D.68645_249 = operator[] (D.68637_248, &D.68643); : this_302 = (struct basic_string,std::allocator > * const) D.68645_249; __str_303 = (struct basic_string,std::allocator > &) D.68642_241; D.76444_304 = assign (this_302, __str_303); : D.76445_305 = D.76444_304; D.76443_306 = D.76445_305; this_307 = (struct basic_string,std::allocator > * const) &D.68643; this_308 = (struct basic_string,std::allocator > * const) this_307; D.76520_309 = &D.76510; D.76521_310 = &this_308->_M_dataplus; D.76522_311 = (struct allocator *) D.76521_310; this_312 = (struct allocator * const) D.76520_309; __a_313 = (struct allocator &) D.76522_311; __a.148_314 = (struct new_allocator *) __a_313; this.149_315 = (struct new_allocator *) this_312; this_316 = (struct new_allocator * const) this.149_315; D.76525_317 = (struct new_allocator &) __a.148_314; this_318 = (struct basic_string,std::allocator > * const) this_307; this_319 = this_318; D.76534_320 = this_319->_M_dataplus._M_p; D.76530_321 = D.76534_320; D.76531_322 = (struct _Rep *) D.76530_321; D.76532_323 = D.76531_322 + -24B; D.76511_324 = D.76532_323; this_325 = (struct _Rep * const) D.76511_324; __a_326 = (struct allocator &) &D.76510; __p_327 = &_S_empty_rep_storage; D.76549_328 = (struct _Rep *) __p_327; D.76537_329 = D.76549_328; D.76538_330 = D.76537_329 != this_325; D.76539_331 = __builtin_expect (D.76538_330, 0); retval.156_332 = D.76539_331 != 0; if (retval.156_332) goto ; else goto ; :; save_filt.202_250 = <<>>; save_eptr.201_251 = <<>>; this_252 = (struct basic_string,std::allocator > * const) &D.68643; this_253 = (struct basic_string,std::allocator > * const) this_252; D.76459_254 = &D.76449; D.76460_255 = &this_253->_M_dataplus; D.76461_256 = (struct allocator *) D.76460_255; this_257 = (struct allocator * const) D.76459_254; __a_258 = (struct allocator &) D.76461_256; __a.148_259 = (struct new_allocator *) __a_258; this.149_260 = (struct new_allocator *) this_257; this_261 = (struct new_allocator * const) this.149_260; D.76464_262 = (struct new_allocator &) __a.148_259; this_263 = (struct basic_string,std::allocator > * const) this_252; this_264 = this_263; D.76473_265 = this_264->_M_dataplus._M_p; D.76469_266 = D.76473_265; D.76470_267 = (struct _Rep *) D.76469_266; D.76471_268 = D.76470_267 + -24B; D.76450_269 = D.76471_268; this_270 = (struct _Rep * const) D.76450_269; __a_271 = (struct allocator &) &D.76449; __p_272 = &_S_empty_rep_storage; D.76488_273 = (struct _Rep *) __p_272; D.76476_274 = D.76488_273; D.76477_275 = D.76476_274 != this_270; D.76478_276 = __builtin_expect (D.76477_275, 0); retval.156_277 = D.76478_276 != 0; if (retval.156_277) goto ; else goto ; :; D.76482_286 = &this_270->D.16095._M_refcount; D.76483_287 = (volatile _Atomic_word *) D.76482_286; D.76484_288 = __exchange_and_add (D.76483_287, -1); : retval.157_301 = D.76484_288 <= 0; if (retval.157_301) goto ; else goto ; :; _M_destroy (this_270, __a_271); goto (); :; save_filt.198_289 = <<>>; save_eptr.197_290 = <<>>; this.147_291 = (struct new_allocator *) &D.76449; this_292 = (struct new_allocator * const) this.147_291; <<>> = save_eptr.197_290; <<>> = save_filt.198_289; resx; :; this.147_278 = (struct new_allocator *) &D.76449; this_279 = (struct new_allocator * const) this.147_278; D.76454_280 = &this_252->_M_dataplus; this_281 = (struct _Alloc_hider * const) D.76454_280; this.150_282 = (struct allocator *) this_281; this_283 = (struct allocator * const) this.150_282; this.147_284 = (struct new_allocator *) this_283; this_285 = (struct new_allocator * const) this.147_284; <<>> = save_eptr.201_251; <<>> = save_filt.202_250; resx; :; save_filt.200_293 = <<>>; save_eptr.199_294 = <<>>; D.76454_295 = &this_252->_M_dataplus; this_296 = (struct _Alloc_hider * const) D.76454_295; this.150_297 = (struct allocator *) this_296; this_298 = (struct allocator * const) this.150_297; this.147_299 = (struct new_allocator *) this_298; this_300 =
[Bug rtl-optimization/15792] missed subreg optimization
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-20 15:52 --- (In reply to comment #4) > I'm going to experiment with moving where the subreg lowering code occurs and > moving up the splitting into subregs and see if I can get the desired > results. > I'm pretty new to GCC, so if any of the above seems like I'm off in the weeds > then please let me know. This seems right but the other issue is that register allocator allocates DI as two consecutive register as one (that might be only part of the cause). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tony dot linthicum at amd ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-01-20 15:53 --- And we can hope that the SSA inliner will do better on the temporaries, but I guess the resulting CFG will be unchanged. Penaltizing try/finally in estimate_num_insn_1 instead of declaring them "/* Containers have no cost. */" will maybe make inlining sane here again (possibly conditional on -fexceptions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 15:55 --- The other thing which might help here is trying to find more functions which can have nothrow on them which should help compile time. I had a patch which did this at the tree level but never finished it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug c/25880] New: suggestion: a special warning for discarding the ``const'' qualifier
The current gcc warning for discarded qualifiers cannot be easily understood by
beginners:
$ cat const.c
int main(void)
{
const char *pcc;
char *pc;
pcc = "hello, world";
pc = pcc;
return 0;
}
$ gcc -Wall -W const.c
const.c: In function `main':
const.c:7: warning: assignment discards qualifiers from pointer target type
This warning doesn't give any hint to a programmer not familiar with the ISO
standard's wording. Therefore I suggest to make a special case warning if the
only qualifier that's discarded is ``const''. It would then show up like this:
$ ~/pkg/gcc3/bin/gcc -Wall -W const.c
const.c: In function `main':
const.c:7: warning: assignment discards ``const'' qualifier from pointer target
type
--
Summary: suggestion: a special warning for discarding the
``const'' qualifier
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland dot illig at gmx dot de
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug c/25880] suggestion: a special warning for discarding the ``const'' qualifier
--- Comment #1 from roland dot illig at gmx dot de 2006-01-20 15:59 --- Created an attachment (id=10690) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10690&action=view) Special warning for ``const''. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug c/25880] suggestion: a special warning for discarding the ``const'' qualifier
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-20 16:04 --- Patches should go to [EMAIL PROTECTED] The correct quoting style is "%" as %< and %> gets translated to the corect quote for the person. You might just say all the Quals which are discarded, there are only 3, restrict, const and volatile. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-01-20 16:04:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 15:57 --- Patch which might help: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00881.html It is not a complete patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug tree-optimization/25860] [4.2 Regression] ice with -g -O2 -fPIC
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 16:14 --- (In reply to comment #6) > This one is actually not a trivial problem to fix ATM (in this case, > eliminate would need to be changed as well), so it would be best to just > change the can_PRE_operation to have something like: > > || (TREE_CODE (op) == INDIRECT_REF && !AGGREGATE_TYPE_P (TREE_TYPE > (op > > > If someone wants to bootstrap and test that fix before i get to it in > the next week or so, that's fine. That did not work, we get a different ICE: t.cc: In function 'savewav': t.cc:11: internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:2029 Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #37 from matz at suse dot de 2006-01-20 16:36 ---
Hmpf. One more difficulty. x86 uses the ADJUST_FIELD_ALIGN macro
to further fiddle with alignments of fields. On x86 this is used to
adjust the alignment of long long to 4 (instead of the natural 8).
This is used only when the field is not DECL_PACKED (makes sense).
This has the funny side-effect that a struct containing a long long zero-width
bitfield aligns to 4 for unpacked and to 8 for packed structs, i.e. the
packed struct actually is _larger_ than the unpacked struct. E.g. the
running example with UINT being long long:
typedef int BOOL;
typedef unsigned long long UINT;
#pragma pack(1)
typedef struct {
BOOL fFullPathTitle:1;
BOOL fSaveLocalView:1;
BOOL fNotShell:1;
BOOL fSimpleDefault:1;
BOOL fDontShowDescBar:1;
BOOL fNewWindowMode:1;
BOOL fShowCompColor:1;
BOOL fDontPrettyNames:1;
BOOL fAdminsCreateCommonGroups:1;
UINT fUnusedFlags:7;
UINT :0;
UINT fMenuEnumFilter;
} CABINETSTATE;
This struct being unpacked (only influenced by #pragma) has size 12 after
my patch on i686, and size 16 (!) when being packed via attribute.
What's even more ugly is that pre-3.4 GCC had a size of 16 for both
cases (pragma or attribute packed) on i686 :-(
So, how would we like to handle this? Doing as pre 3.4 did is probably
possible but not trivially done. Basically the code doing this is:
if (! DECL_USER_ALIGN (decl) && ! DECL_PACKED (decl))
{
#ifdef ADJUST_FIELD_ALIGN
DECL_ALIGN (decl) = ADJUST_FIELD_ALIGN (decl, DECL_ALIGN (decl));
#endif
}
Now, I could just ignore DECL_PACKED for zero-width bitfields, then the
adjustment would be done for both cases and we had a size of 12 with
attribute or pragma, i.e. not the same as pre 3.4 in both. I also
could never adjust zero-width bitfields, so that they would get their
natural alignment even when the target wanted something else. Then both
cases would have size 16, being the same as pre 3.4.
I'm leaning towards not doing field adjustments for zero-width bitfields
at all, having the effect that a zero-width bitfield has a user-alignment
set explicitely (of it's base type). I think if one understands zero-width
bitfields purely as alignment constraints than this implicit DECL_USER_ALIGN
behaviour seems sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/23488] [4.1/4.2 Regression] GCSE load PRE does not work with non sets
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-01-20 16:42 --- Changing GVN PRE for adding decl as references is harder than I thought. :(. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug tree-optimization/25860] [4.2 Regression] ice with -g -O2 -fPIC
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 17:03 ---
This patch worked though:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 110017)
+++ tree-ssa-pre.c (working copy)
@@ -1159,7 +1159,7 @@ phi_translate (tree expr, value_set_t se
VEC (tree, gc) * oldvuses = NULL;
VEC (tree, gc) * newvuses = NULL;
- if (TREE_CODE (expr) != INDIRECT_REF)
+ if (TREE_CODE (expr) != INDIRECT_REF && !AGGREGATE_TYPE_P (TREE_TYPE
(expr)))
return NULL;
newop1 = phi_translate (find_leader (set, oldop1),
@@ -1989,7 +1989,7 @@ can_PRE_operation (tree op)
return UNARY_CLASS_P (op)
|| BINARY_CLASS_P (op)
|| COMPARISON_CLASS_P (op)
-|| TREE_CODE (op) == INDIRECT_REF
+|| (TREE_CODE (op) == INDIRECT_REF)
|| TREE_CODE (op) == CALL_EXPR;
}
@@ -2650,7 +2650,7 @@ create_value_expr_from (tree expr, basic
/* Recursively value-numberize reference ops. */
- if (REFERENCE_CLASS_P (TREE_VALUE (vexpr)))
+ if (REFERENCE_CLASS_P (TREE_VALUE (vexpr)) && !AGGREGATE_TYPE_P
(TREE_TYPE (TREE_VALUE (vexpr
{
tree tempop;
op = TREE_VALUE (vexpr);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
[Bug tree-optimization/25881] New: unsigned int loop indices are not accepted by the vectorizer
void vector_add(int n,
double * __restrict__ r,
double * __restrict__ a,
double * __restrict__ b) {
int i;
for(i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=25881
[Bug bootstrap/25790] make clean fails
--- Comment #2 from aoliva at gcc dot gnu dot org 2006-01-20 17:16 --- If you mean make -k for sub-makes, yes. But `make clean && make && make check' ought to work, and not stop after make clean because it looks like it failed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25790
[Bug c++/25878] Excessive memory and compile-time with std::map init sequence
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-20 17:19:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
[Bug bootstrap/25790] make clean fails
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2006-01-20 17:21 --- Subject: Re: make clean fails aoliva at gcc dot gnu dot org wrote: >--- Comment #2 from aoliva at gcc dot gnu dot org 2006-01-20 17:16 --- >If you mean make -k for sub-makes, yes. But `make clean && make && make check' >ought to work, and not stop after make clean because it looks like it failed. > > Yes. In this case, anyway, the problem is that for a pasto I left out a "; \" in r104978. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25790
[Bug tree-optimization/25881] unsigned int loop indices are not accepted by the vectorizer
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu|64bits targets http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25881
[Bug c/25882] New: libgcov.c:577: ICE: Segmentation fault
/home/dave/gnu/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.2/objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc- 4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -DELF=1 -DLINUX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc/gcc -I. ./../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber -DL_gcov -c ../../gcc/gcc/libgcov.c -o libgcc/./_gcov.o ../../gcc/gcc/libgcov.c: In function '__gcov_init': ../../gcc/gcc/libgcov.c:577: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: *** [libgcc/./_gcov.o] Error 1 -- Summary: libgcov.c:577: ICE: Segmentation fault Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25882
[Bug middle-end/25882] libgcov.c:577: ICE: Segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 17:38 --- *** This bug has been marked as a duplicate of 25869 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25882
[Bug middle-end/25869] [4.2 regression] MMIX broken: ICE compiling __divti3
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-20 17:38 --- *** Bug 25882 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25869
[Bug libfortran/25835] Segfault or Bad Address error on unformatted sequential READ
--- Comment #2 from jb at gcc dot gnu dot org 2006-01-20 17:57 --- Confirmed. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-20 17:57:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25835
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #38 from mark at codesourcery dot com 2006-01-20 18:02 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
matz at suse dot de wrote:
> --- Comment #37 from matz at suse dot de 2006-01-20 16:36 ---
> Hmpf. One more difficulty. x86 uses the ADJUST_FIELD_ALIGN macro
> to further fiddle with alignments of fields. On x86 this is used to
> adjust the alignment of long long to 4 (instead of the natural 8).
> This is used only when the field is not DECL_PACKED (makes sense).
> This has the funny side-effect that a struct containing a long long zero-width
> bitfield aligns to 4 for unpacked and to 8 for packed structs
Ugh. I think we can all agree that these issues had not been well
thought through previously. :-)
> if (! DECL_USER_ALIGN (decl) && ! DECL_PACKED (decl))
> {
> #ifdef ADJUST_FIELD_ALIGN
> DECL_ALIGN (decl) = ADJUST_FIELD_ALIGN (decl, DECL_ALIGN (decl));
> #endif
> }
>
> Now, I could just ignore DECL_PACKED for zero-width bitfields, then the
> adjustment would be done for both cases and we had a size of 12 with
> attribute or pragma, i.e. not the same as pre 3.4 in both.
I don't think a zero-width bitfield should ever be DECL_PACKED. (In
this case, it's DECL_PACKED because the structure is in the scope of
#pragma pack(1).)
In other words, I think a zero-width bitfield should always be subject
to ADJUST_FIELD_ALIGN; the meaning of a zero-width bitfield of type T
(for PCC_BITFIELD_TYPE_MATTERS) should be "align the next field as you
would a field of type T".
> I'm leaning towards not doing field adjustments for zero-width bitfields
> at all, having the effect that a zero-width bitfield has a user-alignment
> set explicitely (of it's base type).
Careful! That would be an ABI change even in the non-packed case, which
we don't want to do.
I think the best change would be just not to mark zero-width bitfields
as DECL_PACKED in the first place; a second choice, if easier, would be
to disregard the DECL_PACKED setting in stor-layout.c. Please add a
test case for this new oddity you discovered, if you would.
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug libgomp/25883] New: libgomp call pthread functions directly
libgomp (like all other target libraries in GCC) should not be calling pthread functions directly but instead using the gthr-* files in gcc. This makes libgomp more portable. -- Summary: libgomp call pthread functions directly Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25883
[Bug libgomp/25884] New: libgomp should not require perl to compile
Like all other target libraries, libgomp should not require perl to compile. This is either a documention failure as the docs say perl is not required or this is a bug in libgomp for requiring perl. -- Summary: libgomp should not require perl to compile Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25884
[Bug libgomp/25877] [4.2 Regression] team.c:269: warning: implicit declaration of function 'alloca'
--- Comment #2 from sje at gcc dot gnu dot org 2006-01-20 18:17 --- Subject: Bug 25877 Author: sje Date: Fri Jan 20 18:17:28 2006 New Revision: 110031 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110031 Log: PR libgomp/25877 * team.c: Add include of alloca.h. * configure.ac: Add check for alloca.h. * configure: Regenerate. * config.h.in: Regenerate. Modified: trunk/libgomp/ChangeLog trunk/libgomp/config.h.in trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/team.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25877
[Bug middle-end/25882] libgcov.c:577: ICE: Segmentation fault
--- Comment #2 from danglin at gcc dot gnu dot org 2006-01-20 18:19 --- This appears fixed by r110130. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25882
[Bug testsuite/24962] gcc.target/ia64/20030811-1.c (test for excess errors) fails with -milp32
--- Comment #1 from sje at gcc dot gnu dot org 2006-01-20 18:29 --- Subject: Bug 24962 Author: sje Date: Fri Jan 20 18:29:44 2006 New Revision: 110034 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110034 Log: PR testsuite/24962 * gcc.target/ia64/20030811-1.c: Change 'long' to 'long long'. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/ia64/20030811-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24962
[Bug tree-optimization/25860] [4.2 Regression] ice with -g -O2 -fPIC
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-01-20 18:30 --- Subject: Re: [4.2 Regression] ice with -g -O2 -fPIC On Fri, 2006-01-20 at 17:03 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 17:03 > --- > This patch worked though: > Index: tree-ssa-pre.c > === > --- tree-ssa-pre.c (revision 110017) > +++ tree-ssa-pre.c (working copy) > @@ -1159,7 +1159,7 @@ phi_translate (tree expr, value_set_t se > VEC (tree, gc) * oldvuses = NULL; > VEC (tree, gc) * newvuses = NULL; > > - if (TREE_CODE (expr) != INDIRECT_REF) > + if (TREE_CODE (expr) != INDIRECT_REF && !AGGREGATE_TYPE_P (TREE_TYPE > (expr))) > return NULL; > Changing this to "|| AGGREGATE_TYPE_P " should also be enough to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25860
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #14 from uweigand at gcc dot gnu dot org 2006-01-20 18:39 --- Some additional details about the s390x failure. This is caused by a miscompile of the fdd2a00__write__2 support routine: lg %r4,168(%r15) # 35*movdi_64/8 [length = 6] lg %r3,160(%r15) # 36*movdi_64/8 [length = 6] cgr %r4,%r3 # 37*cmpdi_ccs/1[length = 4] stg %r2,168(%r15) # 33*movdi_64/9 [length = 6] Note how insn 35 reads a stack slot that is uninitialized because insn 33 has been scheduled later. This is apparently caused by an alias set issue. The code at the .t97.final_cleanup level reads: A.63 = system__arith_64__add_with_ovflo_check (D.1421, D.1426); R38b = (ada__streams__Tstream_element_offsetB *) &A.63; where the data type of A.63 is system__arith_64__int64. This gets expanded into (insn 32 31 33 3 (set (reg:DI 60) (reg:DI 2 %r2)) -1 (nil) (nil)) (insn 33 32 34 3 (set (mem/c/i:DI (plus:DI (reg/f:DI 39 virtual-stack-vars) (const_int -8 [0xfff8])) [26 A.63+0 S8 A64]) (reg:DI 60)) -1 (nil) (nil)) (insn 34 33 35 3 (parallel [ (set (reg:DI 43 [ R38b ]) (plus:DI (reg/f:DI 39 virtual-stack-vars) (const_int -8 [0xfff8]))) (clobber (reg:CC 33 %cc)) ]) -1 (nil) (nil)) (insn 35 34 36 3 (set (reg:DI 48 [ D.1430 ]) (mem:DI (reg:DI 43 [ R38b ]) [27 S8 A64])) -1 (nil) (nil)) Note alias set 26 in insn 33 vs. alias set 27 in insn 35. Any ideas why this would be the case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug ada/25885] New: gnatpp won't compile
Hello Trying to compile gnatpp I get the a "GNAT BUG DETECTED" box which I like to share with you all: gnatmake "-Ptools/gnatpp/gnatpp" "-XBLD=prod" "-XOPSYS=default_Unix" gcc -c -gnatf -gnatwu -gnaty -O2 -I- -gnatA /work/martin/asis/tools/gnatpp/gnatpp-comments.adb +===GNAT BUG DETECTED==+ | 4.0.2 (x86_64-suse-linux-gnu) in create_tmp_var, bei gimplify.c:368 | | Error detected at gnatpp-comments.adb:950:8 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. /work/martin/asis/tools/gnatpp/gnatpp-comments.adb ./gnatpp-comments.ads ./gnatpp.ads ../../asis/asis.ads ../../asis/a4g.ads ../../asis/a4g-a_types.ads ../../asis/a4g-int_knds.ads /work/martin/asis/gnat/types.ads ../../asis/asis-text.ads ./gnatpp-common.ads /work/martin/asis/gnat/table.ads ./gnatpp-source_line_buffer.ads ./gnatpp-state.ads ../../asis/asis-extensions.ads ../../asis/asis-extensions-flat_kinds.ads ./gnatpp-general_traversal_stacks.ads ./gnatpp-stacs.ads ./gnatpp-layout.ads ./gnatpp-options.ads ./gnatpp-pp_output.ads ./gnatpp-output.ads ./gnatpp-source_table.ads ./gnatpp-paragraphs.ads compilation abandoned gnatmake: "/work/martin/asis/tools/gnatpp/gnatpp-comments.adb" compilation error Martin -- Summary: gnatpp won't compile Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: krischik at users dot sourceforge dot net GCC build triplet: x86_64-suse-linux-gnu GCC host triplet: x86_64-suse-linux-gnu GCC target triplet: x86_64-suse-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug ada/25885] gnatpp won't compile
--- Comment #1 from krischik at users dot sourceforge dot net 2006-01-20 19:04 --- Created an attachment (id=10691) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10691&action=view) The GNAT chop as whiched -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug ada/25885] gnatpp won't compile
--- Comment #2 from krischik at users dot sourceforge dot net 2006-01-20 19:07 --- Almost forgot, you want a gcc -v >gcc -v Es werden eingebaute Spezifikationen verwendet. Ziel: x86_64-suse-linux Konfiguriert mit: ../gcc-4.0.2/configure --with-gcc --with-gnu-ld --with-gnu-as --enable-alloca=yes --enable-mpfr --enable-libada --enable-libgcj --enable-multilib --enable-java-gc=boehm --enable-c99 --enable-threads=yes --enable-interpreter --enable-hash-synchronization --enable-shared --prefix=/opt/gnat/gcc --enable-languages=c,ada,c++,f95,java,objc x86_64-suse-linux Thread-Modell: posix gcc-Version 4.0.2 --- Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug middle-end/25886] New: almost to 256 tree codes for Objective-C++
Objective-C++ uses 256 tree codes and yes it uses all of them. So Objective-C++ fails. -- Summary: almost to 256 tree codes for Objective-C++ Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25886
[Bug c++/25874] [gomp branch] ICE in calc_dfs_tree()
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-01-20 19:17
---
Reduced testcase:
int foo();
struct wigner_d
{
void recurse () {
int dd;
for (int j=0; j<=1; ++j) {
#pragma omp parallel
dd=5;
}
}
};
template void rotate_alm(T arg)
{
wigner_d rec;
rec.recurse();
#pragma omp parallel
foo();
}
template void rotate_alm(float arg);
template void rotate_alm(double arg);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25874
[Bug middle-end/25886] [4.2 Regression] up to 256 tree codes for Objective-C++
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 19:26 --- Caused by: 2006-01-19 Diego Novillo <[EMAIL PROTECTED]> * tree.def (BLOCK): Remove documentation about BLOCK_TYPE_TAGS. (OMP_PARALLEL): Add 3 operands. (OMP_SECTIONS): Add 1 operand. (OMP_RETURN_EXPR): Define. That last define caused this regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Keywords||build Summary|almost to 256 tree codes for|[4.2 Regression] up to 256 |Objective-C++ |tree codes for Objective-C++ Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25886
[Bug libgomp/25884] libgomp should not require perl to compile
--- Comment #1 from bonzini at gnu dot org 2006-01-20 19:56 --- Created an attachment (id=10692) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10692&action=view) prototype patch This is a prototype patch to fix the bug using autoconf to compute the necessary sizes/alignments Note that I'm *not* going to test and submit this patch any further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25884
[Bug bootstrap/25259] [4.2 Regression] bootstrap failures on non-C99 platforms
--- Comment #15 from bonzini at gnu dot org 2006-01-20 19:58 --- libgomp should use GCC_HEADER_STDINT too. See the patch for PR25884 which does so. -- bonzini at gnu dot org changed: What|Removed |Added BugsThisDependsOn||25884 Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25259
[Bug libgomp/25259] [4.2 Regression] bootstrap failures on non-C99 platforms
-- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|bonzini at gnu dot org |unassigned at gcc dot gnu ||dot org Status|REOPENED|NEW Component|bootstrap |libgomp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25259
[Bug ada/25885] Ada ICE have nop_expr in int_const_binop on x86_64-linux
--- Comment #3 from laurent at guerby dot net 2006-01-20 20:01 --- Note this works on i686 with 4.0.2. Confirmed on 4.0.2, also present in 4.1 and 4.2 $ gcc -c -O2 gnatpp-comments.adb +===GNAT BUG DETECTED==+ | 4.1.0 20060112 (prerelease) (x86_64-unknown-linux-gnu) GCC error:| | tree check: expected integer_cst, have nop_expr in int_const_binop, | |at fold-const.c:1330 | | Error detected at gnatpp-comments.adb:944:17 | $ gcc -c -O2 gnatpp-comments.adb +===GNAT BUG DETECTED==+ | 4.2.0 20060115 (experimental) (x86_64-unknown-linux-gnu) GCC error: | | tree check: expected integer_cst, have nop_expr in int_const_binop, | |at fold-const.c:1369 | | Error detected at gnatpp-comments.adb:944:17 | -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-01-20 20:01:27 date|| Summary|gnatpp won't compile|Ada ICE have nop_expr in ||int_const_binop on x86_64- ||linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug ada/25885] [4.0/4.1/4.2 Regression] Tree checking failure on ASIS
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-01-20 20:14 --- > Confirmed on 4.0.2, also present in 4.1 and 4.2 > > $ gcc -c -O2 gnatpp-comments.adb > +===GNAT BUG DETECTED==+ > | 4.1.0 20060112 (prerelease) (x86_64-unknown-linux-gnu) GCC error:| > | tree check: expected integer_cst, have nop_expr in int_const_binop, | > |at fold-const.c:1330 | > | Error detected at gnatpp-comments.adb:944:17 | > > $ gcc -c -O2 gnatpp-comments.adb > +===GNAT BUG DETECTED==+ > | 4.2.0 20060115 (experimental) (x86_64-unknown-linux-gnu) GCC error: | > | tree check: expected integer_cst, have nop_expr in int_const_binop, | > |at fold-const.c:1369 | > | Error detected at gnatpp-comments.adb:944:17 | Yes, an annoying problem, regression from 3.x. -- 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 GCC build triplet|x86_64-suse-linux-gnu |*-*-* GCC host triplet|x86_64-suse-linux-gnu |*-*-* GCC target triplet|x86_64-suse-linux-gnu |*-*-* Last reconfirmed|2006-01-20 20:01:27 |2006-01-20 20:14:09 date|| Summary|Ada ICE have nop_expr in|[4.0/4.1/4.2 Regression] |int_const_binop on x86_64- |Tree checking failure on |linux |ASIS http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug ada/25885] [4.0/4.1/4.2 Regression] Tree checking failure on ASIS
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25885
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-20 20:37 --- (In reply to comment #15) > Any chance of getting the fix into 4.1? Yes if someone approves the patch. Which was posted: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00785.html I don't know enough of this code to approve it though. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg00785.html Status|NEW |ASSIGNED Keywords||ice-on-valid-code, patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug tree-optimization/25881] unsigned int loop indices don't optimize as good as int or __SIZE_TYPE__ for 64bit targets
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 20:43 ---
Confirmed, I thought I had saw another bug about this but no luck, anyways
confirmed.
Hmm, using unsigned short on 32bit targets cause the same issue:
void vector_add(unsigned short n,
double * __restrict__ r,
double * __restrict__ a,
double * __restrict__ b) {
unsigned short i;
for(i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=25881
[Bug bootstrap/25887] New: segfault on mingw32
I can't get GCC trunk to compile on mingw32. The build dies with the following segfault: /home/coudert/ibin/./gcc/xgcc -B/home/coudert/ibin/./gcc/ -B/mingw/i686-pc-mingw32/bin/ -B/mingw/i686-pc-mingw32/lib/ -isystem /mingw/i686-pc-mingw32/include -isystem /mingw/i686-pc-mingw32/sys-include -O2 -I../../gcc/gcc/../winsup/w32api/include -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/coudert/local/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber -DL__main -c ../../gcc/gcc/libgcc2.c -o libgcc/./__main.o ../../gcc/gcc/libgcc2.c: In function '__do_global_ctors': ../../gcc/gcc/libgcc2.c:2109: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: *** [libgcc/./__main.o] Error 1 make[4]: Leaving directory `/home/coudert/ibin/gcc' make[3]: *** [libgcc.a] Error 2 make[3]: Leaving directory `/home/coudert/ibin/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/coudert/ibin' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/coudert/ibin' make: *** [all] Error 2 The gdb backtrace of the segfault is Program received signal SIGSEGV, Segmentation fault. 0x00a7068f in df_chain_unlink (dflow=0x1857c38, ref=0x184d4d8, link=0x184e1f8) at ../../gcc/gcc/df-problems.c:110 110 chain = chain->next; (gdb) where #0 0x00a7068f in df_chain_unlink (dflow=0x1857c38, ref=0x184d4d8, link=0x184e1f8) at ../../gcc/gcc/df-problems.c:110 #1 0x00a706d8 in df_chain_unlink (dflow=0x1857c38, ref=0x184d418, link=0x0) at ../../gcc/gcc/df-problems.c:125 #2 0x00ab9cd4 in df_reg_chain_unlink (dflow=0x189d700, ref=0x184d418) at ../../gcc/gcc/df-scan.c:635 #3 0x00ab9fdd in df_insn_refs_delete (dflow=0x189d700, insn=0x18c5348) at ../../gcc/gcc/df-scan.c:743 #4 0x00aba0b7 in df_bb_refs_delete (dflow=0x189d700, bb_index=5) at ../../gcc/gcc/df-scan.c:768 #5 0x00ab903b in df_scan_free_bb_info (dflow=0x189d700, bb=0x18ab7d0, vbb_info=0x164fae0) at ../../gcc/gcc/df-scan.c:189 #6 0x00a6e3f9 in df_set_blocks (df=0x176a118, blocks=0x164f83c) at ../../gcc/gcc/df-core.c:373 During symbol reading, struct/union type gets multiply defined: union tree_node. During symbol reading, struct/union type gets multiply defined: struct basic_block_def. During symbol reading, struct/union type gets multiply defined: union tree_node. During symbol reading, struct/union type gets multiply defined: union tree_node. During symbol reading, struct/union type gets multiply defined: struct rtx_def. #7 0x008991d6 in iv_analysis_loop_init (loop=) at ../../gcc/gcc/loop-iv.c:267 #8 0x0087e321 in predict_loops (loops_info=0x22fd40, rtlsimpleloops=1 '\001') at ../../gcc/gcc/predict.c:618 #9 0x0087ebb6 in estimate_probability (loops_info=0x22fd40) at ../../gcc/gcc/predict.c:842 #10 0x007b1f12 in rest_of_handle_branch_prob () at ../../gcc/gcc/profile.c:1363 #11 0x006d4e23 in execute_one_pass (pass=0xafc6b0) at ../../gcc/gcc/passes.c:849 #12 0x006d4ede in execute_pass_list (pass=0xafc6b0) at ../../gcc/gcc/passes.c:881 #13 0x006d4ef9 in execute_pass_list (pass=0xafb370) at ../../gcc/gcc/passes.c:882 #14 0x006d27ce in tree_rest_of_compilation (fndecl=0x1897a00) at ../../gcc/gcc/tree-optimize.c:412 #15 0x0041f8fd in c_expand_body (fndecl=0x1897a00) at ../../gcc/gcc/c-decl.c:6689 #16 0x006cb06c in cgraph_expand_function (node=0x1897c80) at ../../gcc/gcc/cgraphunit.c:1098 #17 0x006cb2ef in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1164 #18 0x006cbd27 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1431 #19 0x00422621 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7804 #20 0x0065b9cb in compile_file () at ../../gcc/gcc/toplev.c:1003 #21 0x0065d125 in do_compile () at ../../gcc/gcc/toplev.c:1948 #22 0x0065d188 in toplev_main (argc=49, argv=0x3d48c0) at ../../gcc/gcc/toplev.c:1980 #23 0x004a53ec in main (argc=49, argv=0x3d48c0) at ../../gcc/gcc/main.c:35 -- Summary: segfault on mingw32 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25887
[Bug bootstrap/25887] segfault on mingw32
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 20:45 --- *** This bug has been marked as a duplicate of 25869 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25887
[Bug middle-end/25869] [4.2 regression] MMIX broken: ICE compiling __divti3
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-20 20:45 --- *** Bug 25887 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25869
[Bug middle-end/25869] [4.2 regression] MMIX broken: ICE compiling __divti3
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 20:46 --- Worked around so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25869
[Bug middle-end/23631] construct to memory and memcpy instead of memset
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-20 20:51 --- PR 23477 was fixed in 4.1.0 and not 4.0.3. This is still a dup of that bug. *** This bug has been marked as a duplicate of 23477 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
[Bug middle-end/23477] [4.1 Regression] default-initializing array new expression uses makes stack usage go way up
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 20:51 --- *** Bug 23631 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477
[Bug fortran/24875] [gfortran, 4.1.0 regression] Arithmetic overflow during compilation
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 20:56 --- I am going to declare this is GMP bug as I can reproduce it on two out of three of my machines. The one with the newest GMP, it works. These three machines are all different targets, powerpc, x86 and x86-64. So closing as worksforme. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
[Bug libstdc++/25524] libstdc++ headers should go in multilib directories
--- Comment #8 from jsm28 at gcc dot gnu dot org 2006-01-20 21:00 --- Subject: Bug 25524 Author: jsm28 Date: Fri Jan 20 21:00:03 2006 New Revision: 110037 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110037 Log: PR libstdc++/25524 * cppdefault.h (struct default_include): Add multilib flag. * cppdefault.c (cpp_include_defaults): Set it. * c.opt (-imultilib): New option. * c-opts.c (imultilib): New. (c_common_handle_option): Handle -imultilib. (c_common_post_options): Likewise. * c-incpath.c (add_standard_paths, register_include_chains): Likewise. * c-incpath.h (register_include_chains): Add extra parameter. * gcc.c (do_spec_1): Generate -imultilib option. (The Specs Language): Update %I description. (process_command): Update copyright notice. * doc/cppopts.texi (-imultilib): Document. * doc/invoke.texi (-imultilib): Include in option summary. (%I): Update specs documentation. libstdc++-v3: * include/Makefile.am: Install host-specific headers in multilib subdirectory. * include/Makefile.in: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/c-incpath.c trunk/gcc/c-incpath.h trunk/gcc/c-opts.c trunk/gcc/c.opt trunk/gcc/cppdefault.c trunk/gcc/cppdefault.h trunk/gcc/doc/cppopts.texi trunk/gcc/doc/invoke.texi trunk/gcc/gcc.c trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25524
[Bug libstdc++/25524] libstdc++ headers should go in multilib directories
--- Comment #9 from jsm28 at gcc dot gnu dot org 2006-01-20 21:00 --- Subject: Bug 25524 Author: jsm28 Date: Fri Jan 20 21:00:52 2006 New Revision: 110038 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110038 Log: PR libstdc++/25524 * gcc/cppdefault.h (struct default_include): Add multilib flag. * gcc/cppdefault.c (cpp_include_defaults): Set it. * gcc/c.opt (-imultilib): New option. * gcc/c-opts.c (imultilib): New. (c_common_handle_option): Handle -imultilib. (c_common_post_options): Likewise. * gcc/c-incpath.c (add_standard_paths, register_include_chains): Likewise. * gcc/c-incpath.h (register_include_chains): Add extra parameter. * gcc/gcc.c (do_spec_1): Generate -imultilib option. (The Specs Language): Update %I description. (process_command): Update copyright notice. * gcc/doc/cppopts.texi (-imultilib): Document. * gcc/doc/invoke.texi (-imultilib): Include in option summary. (%I): Update specs documentation. * libstdc++-v3/include/Makefile.am: Install host-specific headers in multilib subdirectory. * libstdc++-v3/include/Makefile.in: Regenerate. Modified: branches/csl/sourcerygxx-4_1/ChangeLog.csl branches/csl/sourcerygxx-4_1/gcc/c-incpath.c branches/csl/sourcerygxx-4_1/gcc/c-incpath.h branches/csl/sourcerygxx-4_1/gcc/c-opts.c branches/csl/sourcerygxx-4_1/gcc/c.opt branches/csl/sourcerygxx-4_1/gcc/cppdefault.c branches/csl/sourcerygxx-4_1/gcc/cppdefault.h branches/csl/sourcerygxx-4_1/gcc/doc/cppopts.texi branches/csl/sourcerygxx-4_1/gcc/doc/invoke.texi branches/csl/sourcerygxx-4_1/gcc/gcc.c branches/csl/sourcerygxx-4_1/libstdc++-v3/include/Makefile.am branches/csl/sourcerygxx-4_1/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25524
[Bug bootstrap/25888] New: make[2]: *** No rule to make target `../../gcc/gcc/gthr-gnat.c'
mkinstalldirs='/usr/local/bin/bash ../../gcc/gcc/../mkinstalldirs' \ /usr/local/bin/bash mklibgcc > tmp-libgcc.mk mv tmp-libgcc.mk libgcc.mk TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET USE_COLLECT2" \ /usr/local/bin/bash ../../gcc/gcc/mkconfig.sh tconfig.h make[2]: *** No rule to make target `../../gcc/gcc/gthr-gnat.c', needed by `stmp-multilib'. Stop. make[2]: Leaving directory `/users/bin/gcc/gcc-4.1/objdir/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/users/bin/gcc/gcc-4.1/objdir/gcc' make: *** [bootstrap] Error 2 Fri Jan 20 15:52:00 EST 2006 -- Summary: make[2]: *** No rule to make target `../../gcc/gcc/gthr- gnat.c' Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hp10.20 GCC host triplet: hppa1.1-hp-hp10.20 GCC target triplet: hppa1.1-hp-hp10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25888
[Bug bootstrap/25888] make[2]: *** No rule to make target `../../gcc/gcc/gthr-gnat.c'
--- Comment #1 from danglin at gcc dot gnu dot org 2006-01-20 21:44 --- I accidently deleted the file. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25888
[Bug fortran/25091] Results do not conform at different entries
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 21:51 --- Confirmed, this is obviously wrong as there is no way for different entries to have different return types. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2006-01-20 21:51:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25091
[Bug fortran/25092] Result lengths different at different entries
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 21:51 --- Confirmed, related to PR 25091. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25091 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2006-01-20 21:51:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25092
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-01-20 22:37 --- RTH's comments are here: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01390.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug target/25668] libgcc2.c __floattisf code quality regression
--- Comment #1 from amodra at bigpond dot net dot au 2006-01-20 22:51 --- Author: amodra Date: Fri Jan 20 00:42:29 2006 New Revision: 110004 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110004 Log: * libgcc2.c (__floatdisf, __floatdidf): Don't use IBM Extended Double TFmode. (__floatundisf, __floatundidf): Likewise. * libgcc2.h (IS_IBM_EXTENDED): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/libgcc2.c trunk/gcc/libgcc2.h -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25668
[Bug target/25758] gcc.c-torture/compile/20030921-1.c fails at -O0
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-20 23:49 --- I am testing the patch that RTH suggested on x86_64-linux-gnu to make sure that it works there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-01-20 23:56 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01424.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||01/msg01424.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug tree-optimization/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-21 00:27 --- This also fails on powerpc-darwin. >From Alan M.: [19:14] < alanm> bje, use of an uninitialised pseudo in catch blocks [19:14] < pinskia> alanm: I had that problem before (int a = a; was my issue) [19:15] < alanm> i see the following in 00.expand [19:15] < alanm> (insn 154 153 155 17 (set (reg:DI 150 [ D.31560 ]) [19:15] < alanm> (plus:DI (reg:DI 129 [ mergephitmp.3472 ]) [19:15] < alanm> (reg:DI 201))) -1 (nil) [19:15] < alanm> (nil)) [19:16] < alanm> reg 129 isn't set anywhere. [19:16] < pinskia> hmm, you must be using 4.2 because mergephitmp IIRC is not in 4.1 [19:16] < alanm> must be a tree problem somewhere, but i'm not familiar with reading tree dumps [19:16] < alanm> yes [19:16] < alanm> this is mainline [19:17] < pinskia> alanm: tree dumps is like reading C except for some cases like eh [19:17] * bje ([EMAIL PROTECTED]) has quit IRC (Quit: big blue room) [19:17] < pinskia> alanm: do you have a simple example where this is a problem, I can look at it [19:18] < pinskia> alanm: this is only at -O2 or also at -O1? [19:19] < alanm> no, i haven't simplified. the failing function was ostream-inst.cc:_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c [19:20] < pinskia> ok, I will try to take a look later [19:21] < alanm> a quick look at generated code at -O1 says it is OK. so bug is at -O2 before rtl generation [19:22] < pinskia> I want to say it is related to PRE only because of it is mergephitmp there (but don't quote me on that because DannyB will get on my back) [19:26] < pinskia> alanm: is this from the test 9555-oc.cc? [19:26] < alanm> yes, it causes that failure Looking more into, once my build gets to building libstdc++. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |tree-optimization GCC host triplet|i686-pc-linux-gnu, x86_64- | |unknown-linux-gnu | GCC target triplet|cris-axis-linux-gnu | Keywords||EH http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25315
[Bug tree-optimization/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec
--- Comment #6 from amodra at bigpond dot net dot au 2006-01-21 00:31 --- Fails powerpc64-linux, where I was poking at this bug. -- amodra at bigpond dot net dot au changed: What|Removed |Added CC||amodra at bigpond dot net ||dot au Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-21 00:31:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25315
[Bug middle-end/25890] New: [4.2 regression] testsuite failure: gcc.c-torture/compile/20051228-1.c
Last known to work with: "Tue Jan 17 02:44:03 UTC 2006 (revision 109801M)". Known to fail with: "Fri Jan 20 05:17:46 UTC 2006 (revision 110008M)". Running /home/hp/combined/combined/gcc/testsuite/gcc.c-torture/compile/compile.exp ... FAIL: gcc.c-torture/compile/20051228-1.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -Os (test for excess errors) With the message in the .log being for all: x/combined/gcc/testsuite/gcc.c-torture/compile/20051228-1.c: In function 'foo':^M x/combined/gcc/testsuite/gcc.c-torture/compile/20051228-1.c:10: internal compiler error: in expand_compound_opera\ tion, at combine.c:5644^M -- Summary: [4.2 regression] testsuite failure: gcc.c- torture/compile/20051228-1.c Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: mmix-knuth-mmixware http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25890
[Bug rtl-optimization/25890] [4.2 regression] testsuite failure: gcc.c-torture/compile/20051228-1.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |rtl-optimization Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25890
[Bug testsuite/25891] New: gomp tests run on non-libgomp (non-thread) ports, failing all
Errors in the log look like (for mmix-knuth-mmixware): Running /home/hp/combined/combined/gcc/testsuite/gcc.dg/gomp/gomp.exp ... Executing on host: /home/hp/combined/mmixware-sim/gcc/xgcc -B/home/hp/combined/mmixware-sim/gcc/ /home/hp/combined/combined/gcc/t\ estsuite/gcc.dg/gomp/appendix-a/a.1.1.c -fopenmp -fno-show-column -S -isystem /home/hp/combined/mmixware-sim/mmix-knuth-mmixwa\ re/./newlib/targ-include -isystem /home/hp/combined/combined/newlib/libc/include -o a.1.1.s(timeout = 300) xgcc: unrecognized option '-pthread'^M There was some IRC discussion which misattributed the errors to libgomp wrongly being built, but libgomp isn't built for targets where this was noticed: mmix-knuth-mmixware, cris-axis-elf. A simple gating test in gomp.exp, testing error-free compilation of trivial code with -fopenmp should do it. -- Summary: gomp tests run on non-libgomp (non-thread) ports, failing all Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25891
[Bug tree-optimization/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25315
