[Bug fortran/17744] ice in assignment of derived type constructor
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-10-20 07:00 --- This was fixed on mainline and the 4.0 branch by the patch for PR 24440: http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00736.html Paul, do you want to add this as a testcase? -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17744
[Bug tree-optimization/24307] [4.1 regression] ICE in early_tree_profile with fortran/computed gotos
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-20 08:29 --- The patch fixes the failure I saw with compiling a FDO libgfortran. And it looks obvious btw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24307
[Bug debug/24444] [4.1 regression] invalid register in debug info
--- Comment #4 from rth at gcc dot gnu dot org 2005-10-20 08:35 --- Well, the ideal fix is to make use of the dwarf3 DW_OP_call_frame_cfa directive, and let the debugger get the CFA information from the ia64 unwind info. Similarly for the arm eabi unwind info. I'm not sure what a good short-term fix is. Perhaps, as you suggest, putting some code back for TARGET_UNWIND_INFO targets. On the other hand, both ia64 and arm are ACCUMULATE_OUTGOING_ARGS targets, which means that they don't *need* all that tracking info to find the CFA. For any function that gcc generates, the CFA starts as SP+OFFSET1 and changes exactly once to either SP+OFFSET2 or FP+OFFSET3. Which means that we could fairly easily acquire this info (plus a label of the transition point) from a target hook. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug libfortran/24383] mingw doesn't have SSIZE_MAX
--- Comment #4 from fxcoudert at gmail dot com 2005-10-20 08:53 --- This is fixed in mingw CVS. I will add the workaround with SHRT_MAX. It might not be very efficient, but at least it's garanteed to work, and I think we'd better be on the safe side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24383
[Bug tree-optimization/24225] [4.1 Regression] ICE: segmentation fault in profile.c:branch_prob
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-10-20 09:16 --- Honza, can you have a look at this (now that you appear to be back)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24225
[Bug c++/22508] [4.0/4.1 Regression] ICE after invalid operator new
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-20 10:10 --- Subject: Bug 22508 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED]2005-10-20 10:10:10 Modified files: gcc/cp : ChangeLog init.c Log message: PR c++/22508 * init.c (build_new_1): Remove misleading comment. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.247r2=1.3892.2.248 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.356.2.18r2=1.356.2.19 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22508
[Bug c++/19291] Warning cannot pass objects of non-POD type should be an error
--- Comment #2 from faure at kde dot org 2005-10-20 10:25 --- Could a -W option be added so that, if I want gcc to abort on such errors, it can be asked to do that? (without aborting on all other warnings, of course) This 'undefined behavior' does crash at runtime, so it is really important to catch such mistakes at compile time, and simple warnings often go unnoticed... -- faure at kde dot org changed: What|Removed |Added CC||faure at kde dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19291
[Bug libstdc++/24450] New: Exception safety problem in locale::_Impl::_M_replace_categories
It looks like libstdc++/12352 is not completely fixed: we have one remaining issue in _M_replace_categories -- Summary: Exception safety problem in locale::_Impl::_M_replace_categories Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24450
[Bug libstdc++/24450] Exception safety problem in locale::_Impl::_M_replace_categories
--- Comment #1 from pcarlini at suse dot de 2005-10-20 11:17 --- Created an attachment (id=10031) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10031action=view) Leaks, slowly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24450
[Bug c/24451] New: [gomp] Return out of parallel loop not rejected
The following code is accepted with -fopenmp although a return from a
parallel for loop is not allowed:
void foo()
{
int i;
#pragma omp parallel for
for ( i=0; i10; ++i )
return;
}
When a value is returned, we get an ICE instead:
int foo()
{
int i;
#pragma omp parallel for
for ( i=0; i10; ++i )
return 0;
}
bug.c: In function '__omp_fn.1':
bug.c:4: internal compiler error: in expand_expr_real_1, at expr.c:8307
Please submit a full bug report, [etc.]
The same holds for the C++ frontend; the ICE is just in a different position.
--
Summary: [gomp] Return out of parallel loop not rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, accepts-invalid, openmp
Severity: normal
Priority: P2
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=24451
[Bug c++/24452] New: [gomp] ICE in decl_jump_unsafe, at cp/decl.c:2153
The following testcase causes an ICE in the C++ frontend when compiled
with -fopenmp:
===
void foo()
{
x;
L: goto L;
}
===
bug.cc: In function 'void foo()':
bug.cc:3: error: 'x' was not declared in this scope
bug.cc:4: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in decl_jump_unsafe, at cp/decl.c:2153
Please submit a full bug report, [etc.]
--
Summary: [gomp] ICE in decl_jump_unsafe, at cp/decl.c:2153
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, openmp
Severity: normal
Priority: P2
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=24452
[Bug bootstrap/18939] [4.0/4.1 regression] spurious relink of gcov and gcov-dump with the base compiler
--- Comment #3 from cvs-commit at gcc dot gnu dot org 2005-10-20 11:54 --- Subject: Bug 18939 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-20 11:54:41 Modified files: . : ChangeLog Makefile.def Makefile.in Log message: PR bootstrap/18939 * Makefile.def (gcc) target: Fix thinko. * Makefile.in: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gccr1=1.1159r2=1.1160 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.def.diff?cvsroot=gccr1=1.60r2=1.61 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.in.diff?cvsroot=gccr1=1.281r2=1.282 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18939
[Bug bootstrap/18939] [4.0/4.1 regression] spurious relink of gcov and gcov-dump with the base compiler
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-20 11:55 --- Subject: Bug 18939 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-10-20 11:55:30 Modified files: . : ChangeLog Makefile.def Makefile.in Log message: PR bootstrap/18939 * Makefile.def (gcc) target: Fix thinko. * Makefile.in: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.1057.2.20r2=1.1057.2.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.def.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.46r2=1.46.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.254.8.1r2=1.254.8.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18939
[Bug bootstrap/18939] [4.0/4.1 regression] spurious relink of gcov and gcov-dump with the base compiler
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-10-20 11:56 --- See http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01169.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18939
[Bug target/24445] unable to find a register to spill in class 'R0_REGS
--- Comment #4 from kkojima at gcc dot gnu dot org 2005-10-20 12:11 ---
Here is a reduced testcase:
extern int bar (void) __attribute__ ((__pure__));
extern char *baz;
void foo (void)
{
baz = (char *) bar ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24445
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #21 from cvs-commit at gcc dot gnu dot org 2005-10-20 12:14 --- Subject: Bug 23585 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-20 12:14:30 Modified files: gcc: ChangeLog function.c reorg.c rtl.h rtlanal.c gcc/config/sparc: sparc.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: delay-slot-1.C Log message: PR rtl-optimization/23585 * rtlanal.c (rtx_addr_can_trap_p_1): New predicate extracted from... (rtx_addr_can_trap_p): ... here. Invoke rtx_addr_can_trap_p_1. (may_trap_p_1): New predicate extracted from... (may_trap_p): ... here. Invoke may_trap_p_1. (may_trap_or_fault_p): New predicate. * rtl.h (may_trap_or_fault_p): Declare it. * reorg.c (steal_delay_list_from_target): Use may_trap_or_fault_p instead of may_trap_p. (steal_delay_list_from_fallthrough): Likewise. (fill_simple_delay_slots): Likewise. (fill_slots_from_thread): Likewise. * function.c (pad_to_arg_alignment): Rework comment about SPARC_STACK_BOUNDARY_HACK. * config/sparc/sparc.h: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.10191r2=2.10192 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gccr1=1.646r2=1.647 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reorg.c.diff?cvsroot=gccr1=1.111r2=1.112 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtl.h.diff?cvsroot=gccr1=1.560r2=1.561 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtlanal.c.diff?cvsroot=gccr1=1.220r2=1.221 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.h.diff?cvsroot=gccr1=1.290r2=1.291 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6216r2=1.6217 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/delay-slot-1.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug target/24445] unable to find a register to spill in class 'R0_REGS
--- Comment #5 from sieb at sscd dot de 2005-10-20 12:14 --- (In reply to comment #1) I think a work around for this problem was committed on the 17th which is after the snapshot was done, Can you confirm that? I just tried cvs head (as of 2005-10-20 12:10 GMT). Same problem, unfortunately. Regards, Alexander -- sieb at sscd dot de changed: What|Removed |Added CC||sieb at sscd dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24445
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #22 from cvs-commit at gcc dot gnu dot org 2005-10-20 12:18 --- Subject: Bug 23585 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-10-20 12:18:05 Modified files: gcc: ChangeLog function.c reorg.c rtl.h rtlanal.c gcc/config/sparc: sparc.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: delay-slot-1.C Log message: PR rtl-optimization/23585 * rtlanal.c (rtx_addr_can_trap_p_1): New predicate extracted from... (rtx_addr_can_trap_p): ... here. Invoke rtx_addr_can_trap_p_1. (may_trap_p_1): New predicate extracted from... (may_trap_p): ... here. Invoke may_trap_p_1. (may_trap_or_fault_p): New predicate. * rtl.h (may_trap_or_fault_p): Declare it. * reorg.c (steal_delay_list_from_target): Use may_trap_or_fault_p instead of may_trap_p. (steal_delay_list_from_fallthrough): Likewise. (fill_simple_delay_slots): Likewise. (fill_slots_from_thread): Likewise. * function.c (pad_to_arg_alignment): Rework comment about SPARC_STACK_BOUNDARY_HACK. * config/sparc/sparc.h: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.473r2=2.7592.2.474 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.604.8.1r2=1.604.8.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reorg.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.104.8.1r2=1.104.8.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtl.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.536.4.1r2=1.536.4.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtlanal.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.211.8.2r2=1.211.8.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.273.8.3r2=1.273.8.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.474r2=1.5084.2.475 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/delay-slot-1.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2005-10-20 12:20 --- See http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00883.html Thanks for the reduced testcase. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug target/24445] unable to find a register to spill in class 'R0_REGS
--- Comment #6 from rpjday at mindspring dot com 2005-10-20 12:45 ---
(In reply to comment #4)
Here is a reduced testcase:
extern int bar (void) __attribute__ ((__pure__));
extern char *baz;
void foo (void)
{
baz = (char *) bar ();
}
OK, given the reduced test case that shows the problem, I assume there's no
need to provide any further details from the crosstool output then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24445
[Bug libstdc++/24450] Exception safety problem in locale::_Impl::_M_replace_categories
--- Comment #2 from pcarlini at suse dot de 2005-10-20 12:57 --- Created an attachment (id=10032) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10032action=view) Sorry, this one is the right testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24450
[Bug bootstrap/24438] ARM cross compile build fails with assembler errors in crtstuff.c
--- Comment #4 from newell at cei dot net 2005-10-20 13:51 --- As many of you suspected, I managed to royally FUBAR the configuration step. How embarrassing. I'm really sorry for the noise. -- newell at cei dot net changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24438
[Bug c/24387] int-float cast fails for large int values
--- Comment #2 from neff dot kevin at mayo dot edu 2005-10-20 14:01 --- Oops. floats only store 23 or 24 bits of mantissa. I guess it's a feature... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24387
[Bug c++/24439] [3.4/4.0/4.1 Regression] ICE with invert conditional containing throw
--- Comment #12 from cvs-commit at gcc dot gnu dot org 2005-10-20 15:19 --- Subject: Bug 24439 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-20 15:19:03 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/tree-ssa: pr24439.C Log message: 2005-10-20 Richard Guenther [EMAIL PROTECTED] PR c++/24439 * fold-const.c (invert_truthvalue): Handle COND_EXPR with void type operands. * g++.dg/tree-ssa/pr24439.C: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.10192r2=2.10193 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gccr1=1.628r2=1.629 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6217r2=1.6218 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr24439.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24439
[Bug c/24453] New: IMA could be sped up a little more for a lot of files (for setting type context)
set_type_context does not need to do anything on Scalar types (except for ENUMERAL_TYPE and POINTER_TYPE). I will look into this and see how much compile time it recovers from compiling PR 24446. -- Summary: IMA could be sped up a little more for a lot of files (for setting type context) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: enhancement Priority: P2 Component: c AssignedTo: pinskia at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24453
[Bug c/24453] IMA could be sped up a little more for a lot of files (for setting type context)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-20 15:35 --- I should note that I see set_type_context very high on my profile (50%) of building those files which is why I think this issue is coming up. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-20 15:35:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24453
[Bug c++/24439] [3.4/4.0 Regression] ICE with invert conditional containing throw
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-10-20 15:45 --- Fixed in mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.0.4 3.2.3 3.3.3 3.4.0 |3.0.4 3.2.3 3.3.3 3.4.0 |4.0.0 4.1.0 |4.0.0 Known to work||4.1.0 Summary|[3.4/4.0/4.1 Regression] ICE|[3.4/4.0 Regression] ICE |with invert conditional|with invert conditional |containing throw|containing throw http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24439
[Bug libstdc++/24450] Exception safety problem in locale::_Impl::_M_replace_categories
--- Comment #3 from pcarlini at suse dot de 2005-10-20 16:14 --- Unfortunately, we have problems also outside _M_replace_categories: if loc2 is removed from the testcase, small leaks are still present. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24450
[Bug java/24454] New: Floating point in GCJ does not follow spec
Eclipse's JDT/Core team was doing experiments with turning Eclipse's batch compiler into ECJ using GCJ. The goal was to provide an executable form of Eclipse's compiler. Unfortunately, the effort had to be abandoned because the resulting ECJ compiler would fail the floating point section of Java Compatibility Kit (JCK). -- Summary: Floating point in GCJ does not follow spec Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dpollock at acm dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24454
[Bug java/24454] Floating point in GCJ does not follow spec
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-20 16:34 --- Is this on x86 if so there is a known issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24454
[Bug c/24455] New: [gomp] Trouble with threadprivate and extern
Compiling the following project with -fopenmp doesn't work:
file.h:
===
extern int i;
#pragma omp threadprivate (i)
===
file1.c:
===
#include file.h
int main()
{
return i;
}
===
file2.c:
===
#include file.h
int i;
===
For file2.c I get the following error message:
file2.c:2: error: non-thread-local declaration of 'i' follows thread-local
declaration
file.h:1: error: previous declaration of 'i' was here
Compiling the files as C++ files results in a linker failure:
/usr/bin/ld: i: TLS reference in /tmp/cceZCG1l.o mismatches non-TLS
definition in /tmp/ccBzZ3av.o section .bss
/tmp/ccBzZ3av.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
I'd expect that i is threadprivate in file1.c and file2.c.
Am I misreading the OpenMP spec or is this a bug in the frontends?
--
Summary: [gomp] Trouble with threadprivate and extern
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code, rejects-valid, openmp
Severity: normal
Priority: P2
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=24455
[Bug c++/24451] [gomp] Return out of parallel loop not rejected
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-10-20 16:39 --- Hey the development is really fast on the gomp branch. The C frontend seems to be fixed now. I get a sensible error message now for both testcases: bug.c: In function '__omp_fn.1': bug.c:6: error: invalid exit from OpenMP structured block Btw, should this really be __omp_fn.1? The C++ frontend remains broken, however: I get a sgefault now for both testcases. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Component|c |c++ Keywords|accepts-invalid | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24451
Re: [Bug java/24454] New: Floating point in GCJ does not follow spec
Eclipse's JDT/Core team was doing experiments with turning Eclipse's batch compiler into ECJ using GCJ. The goal was to provide an executable form of Eclipse's compiler. Unfortunately, the effort had to be abandoned because the resulting ECJ compiler would fail the floating point section of Java Compatibility Kit (JCK). One more thing, is how did it fail? You were compiling to native, correct? Note fp is not exact unless you are using strictfp (which GCJ does not implement currently). -- Pinski
[Bug java/24454] Floating point in GCJ does not follow spec
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-20 16:40 --- Subject: Re: New: Floating point in GCJ does not follow spec Eclipse's JDT/Core team was doing experiments with turning Eclipse's batch compiler into ECJ using GCJ. The goal was to provide an executable form of Eclipse's compiler. Unfortunately, the effort had to be abandoned because the resulting ECJ compiler would fail the floating point section of Java Compatibility Kit (JCK). One more thing, is how did it fail? You were compiling to native, correct? Note fp is not exact unless you are using strictfp (which GCJ does not implement currently). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24454
Re: [Bug c/24455] New: [gomp] Trouble with threadprivate and extern
On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote: I'd expect that i is threadprivate in file1.c and file2.c. But you have to mark it so in both places. Am I misreading the OpenMP spec or is this a bug in the frontends? I think you're misreading the spec, in 2.8.2. page 69, lines 4-6: If a variable is specified in a threadprivate directive in one translation unit, it must be specified in a threadprivate directive in every translation unit in which it is declared.
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #1 from dnovillo at redhat dot com 2005-10-20 16:45 --- Subject: Re: New: [gomp] Trouble with threadprivate and extern On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote: I'd expect that i is threadprivate in file1.c and file2.c. But you have to mark it so in both places. Am I misreading the OpenMP spec or is this a bug in the frontends? I think you're misreading the spec, in 2.8.2. page 69, lines 4-6: If a variable is specified in a threadprivate directive in one translation unit, it must be specified in a threadprivate directive in every translation unit in which it is declared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-20 16:49 ---
(In reply to comment #1)
Subject: Re: New: [gomp] Trouble with threadprivate and extern
On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote:
I'd expect that i is threadprivate in file1.c and file2.c.
But you have to mark it so in both places.
Huh, to me it is marked in both TUs.
---
file1.c is equivalant to:
extern int i;
#pragma omp threadprivate (i)
int main()
{
return i;
}
---
While file2.c is equivalant to:
extern int i;
#pragma omp threadprivate (i)
int i;
---
I don't see anything wrong here at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug target/24085] internal compiler error: Segmentation fault
--- Comment #2 from rpjday at mindspring dot com 2005-10-20 16:50 --- (In reply to comment #1) it is only a problem with sh-hms; with sh-elf everything works fine not true. i just got the same error building for little-endian SH3 using the gcc snapshot gcc-4.1-20050702. i'm going to test a couple more variations to make sure i didn't mess up doing this but my error is identical. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24085
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #3 from reichelt at igpm dot rwth-aachen dot de 2005-10-20 16:50 --- Subject: Re: [gomp] Trouble with threadprivate and extern On 20 Oct, dnovillo at redhat dot com wrote: --- Comment #1 from dnovillo at redhat dot com 2005-10-20 16:45 --- Subject: Re: New: [gomp] Trouble with threadprivate and extern On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote: I'd expect that i is threadprivate in file1.c and file2.c. But you have to mark it so in both places. Am I misreading the OpenMP spec or is this a bug in the frontends? I think you're misreading the spec, in 2.8.2. page 69, lines 4-6: If a variable is specified in a threadprivate directive in one translation unit, it must be specified in a threadprivate directive in every translation unit in which it is declared. Doesn't translation unit cover the include file? But anyway. How should I mark it threadprivate in file2.c? Adding #pragma omp threadprivate (i) before or after int i; doesn't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug java/24454] GCJ does not correctly support strictfp
-- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-20 17:03:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24454
[Bug java/24454] GCJ does not correctly support strictfp
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-20 17:06 --- I think this is more of a duplicate of PR 10632. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24454
Re: [Bug c/24455] [gomp] Trouble with threadprivate and extern
On Thursday 20 October 2005 12:50, reichelt at igpm dot rwth-aachen dot de Doesn't translation unit cover the include file? But anyway. How should I mark it threadprivate in file2.c? Adding #pragma omp threadprivate (i) before or after int i; doesn't work. Indeed, sorry about that. I misread your code. I'll take a look.
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #4 from dnovillo at redhat dot com 2005-10-20 17:07 --- Subject: Re: [gomp] Trouble with threadprivate and extern On Thursday 20 October 2005 12:50, reichelt at igpm dot rwth-aachen dot de Doesn't translation unit cover the include file? But anyway. How should I mark it threadprivate in file2.c? Adding #pragma omp threadprivate (i) before or after int i; doesn't work. Indeed, sorry about that. I misread your code. I'll take a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug gcov/profile/24456] New: Help needed with gcov
Hi everyone, I have been trying to do some work with the gnu code coverage tool gcov and here are a couple of problems I am facing. 1. For all the source files .da file is not generated. 2. Even when I can see that a particular line is being executed, e.g. I can see the output for a cout command, gcov states that the particular line was never executed. I have compiled my code with the -fprofile-arcs -ftest-coverage options and the gcov version I am using is 1.5 along with gcc gcc version 2.95.3 20010315 running on a sun solaris machine. Any thoughts, Any help will be really appreciated. Thanx, Sunil. -- Summary: Help needed with gcov Product: gcc Version: 3.3.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sunilkher at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24456
[Bug fortran/23635] Argument of ichar at (1) must be of length one
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-20 17:33 --- I have a fix which I am testing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23635
[Bug c/24455] [gomp] Trouble with threadprivate and extern
--- Comment #5 from dnovillo at gcc dot gnu dot org 2005-10-20 17:52 --- The problem here is that when we are parsing the second declaration, we call start_decl before having parsed the threadprivate clause. This causes us to miss the attribute. One solution I'm considering is to look-ahead in c_parser_declaration_or_fndef and build a regular tls_model attribute instead of lazily setting DECL_TLS_MODEL when we get to the threadprivate #pragma. That seems a more natural way of setting threadprivate attributes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455
[Bug fortran/23635] [4.0/4.1 Regression] Argument of ichar at (1) must be of length one
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-20 17:59 --- This is a regression from 4.0.0, caused by PR 20879. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 4.0.1 Known to work||4.0.0 Summary|Argument of ichar at (1)|[4.0/4.1 Regression] |must be of length one |Argument of ichar at (1) ||must be of length one http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23635
[Bug c++/22618] [3.4/4.0/4.1 Regression] Template non-type arguments break class access protection
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-20 18:01 --- Subject: Bug 22618 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED]2005-10-20 18:01:54 Modified files: gcc/cp : search.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: access8.C Log message: PR c++/22618 * search.c (accessible_p): Check access in the outermost set of template parameters. PR c++/22618 * g++.dg/parse/access8.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/search.c.diff?cvsroot=gccr1=1.351r2=1.352 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4949r2=1.4950 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/access8.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6218r2=1.6219 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22618
[Bug c++/22618] [3.4/4.0/4.1 Regression] Template non-type arguments break class access protection
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-20 18:04 --- Subject: Bug 22618 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-20 18:04:39 Modified files: gcc/cp : search.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: access8.C Log message: PR c++/22618 * search.c (accessible_p): Check access in the outermost set of template parameters. PR c++/22618 * g++.dg/parse/access8.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/search.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.345r2=1.345.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.4648.2.148r2=1.4648.2.149 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/access8.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.475r2=1.5084.2.476 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22618
[Bug c++/22618] [3.4 Regression] Template non-type arguments break class access protection
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-20 18:06 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1 Regression]|[3.4 Regression] Template |Template non-type arguments |non-type arguments break |break class access |class access protection |protection | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22618
[Bug c++/22618] [3.4 Regression] Template non-type arguments break class access protection
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.4.0 4.0.0 4.1.0 |3.4.0 4.0.0 Known to work|3.3.3 |3.3.3 4.1.0 4.0.3 Target Milestone|4.0.3 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22618
[Bug fortran/24459] New: gfortran namelist regression
I don't know if this is an actual regression but using gcc-4.0.2 built with: $ ../gcc-4.0.2/configure --prefix=/opt/gcc-4.0.2 \ --enable-languages=c,c++,f95 --program-suffix=-4.0.2 the program: $ cat diag.f program diag INTEGER nd PARAMETER ( nd = 5 ) CHARACTER*(8) names(nd,nd) NAMELIST / diags / names OPEN(UNIT=20,FILE='diag.nml',STATUS='OLD') READ(20,NML=diags) WRITE(*,NML=diags) STOP END will work with: $ cat diag.nml DIAGS NAMES = 'ETAN' 'ETANSQ' 'DETADT2' 'PHIBOT' 'PHIBOTSQ' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' ''/ but fails with the message: $ ./diag At line 7 of file diag.f Fortran runtime error: Cannot match namelist object name 'etansq when reading: $ cat diag.nml diags names(1,1) = 'ETAN','ETANSQ ','DETADT2 ','PHIBOT ','PHIBOTSQ', / The reason that it appears to be a regression is that both namelist files work nicely with basically all g77 versions shipped in recent years and with a large number of both past and present commercial Fortran compilers including Intel v5--v9, PGI, IBM xlf, and Sun. In my (humble!) opinion, it would be a shame if the namelist indexing (implicit indexing?) is lost since large namelist files are more legible using it. And, existing namelist files will require a fairly substantial amount of editing to convert between the two types of formatting. -- Summary: gfortran namelist regression Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ed at eh3 dot com 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=24459
[Bug middle-end/24295] [4.1 Regression] Xorg broken, #pragma weak foo = bar no longer causes bar to be referenced
-- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-18 22:24:55 |2005-10-20 18:35:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24295
[Bug c++/24260] [4.0/4.1 Regression] stdcall attribute is ignored at static member template functions
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-20 18:37 --- Taking a whack at it. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24260
[Bug libstdc++/24450] Exception safety problem in locale::_Impl::_M_replace_categories
--- Comment #4 from pcarlini at suse dot de 2005-10-20 18:43 --- Ok, I know what's going wrong, can be fixed rather easily ;) -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-20 18:43:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24450
[Bug rtl-optimization/24460] New: [4.1 regression] Profiled bootstrap broken
The failure message is: stage1/xgcc -Bstage1/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.10/bin/ -c -g -O2 -fprofile-use -freorder-blocks-and-partition -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/eric/cvs/gcc/gcc -I/home/eric/cvs/gcc/gcc/. -I/home/eric/cvs/gcc/gcc/../include -I./../intl -I/home/eric/cvs/gcc/gcc/../libcpp/include -I/opt/build/eric/local/include -I/opt/build/eric/local/include /home/eric/cvs/gcc/gcc/attribs.c -o attribs.o /home/eric/cvs/gcc/gcc/attribs.c:332: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. gmake[2]: *** [attribs.o] Error 1 gmake[2]: Leaving directory `/opt/build/eric/gcc/gcc' gmake[1]: *** [stagefeedback_build] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc/gcc' gmake: *** [profiledbootstrap] Error 2 A bit annoying to debug as the stage1 compiler is apparently built without debug info. The bug happens with -g -fprofile-use -freorder-blocks-and-partition. -- Summary: [4.1 regression] Profiled bootstrap broken Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.* GCC host triplet: sparc-sun-solaris2.* GCC target triplet: sparc-sun-solaris2.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24460
[Bug libfortran/24416] Wrong reading following namelist reading
--- Comment #4 from pault at gcc dot gnu dot org 2005-10-20 19:08 --- This one is scary. I add Paul T to the Cc list (since he's familiar with namelist). As far as I can tell, this looks like a purely library-side problem (the code emitted by the front-end looks fine). I had totally forgotten about this horror. I encountered it whilst writing namelist and just, well, ... forgot it. Add a variable of any other kind to the namelist and the problem goes away. I'll add it to the TODO list. I will also see if Jerry is interested. He knows namelist almost as well as I do. Thanks for reporting this. One way or another we will get onto it asap. Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24416
[Bug rtl-optimization/24460] [4.1 regression] Profiled bootstrap broken
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-20 19:08 --- Stage1 should be built at -O0 -g. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, ice-on-valid-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24460
[Bug rtl-optimization/24460] [4.1 regression] Profiled bootstrap broken
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2005-10-20 19:15 --- Stage1 should be built at -O0 -g. It's probably not the regular stage1. I'm bootstrapping again to watch what is going on exactly. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24460
[Bug rtl-optimization/24460] [4.1 regression] Profiled bootstrap broken
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-20 19:24 --- Hmm: stageprofile_build: stage1_copy It is the normal stage1. If you cannot figure out the backtrace, I might be able to reproduce this by a cross compiler. Could you attach the .i file, .gcda and .gcno files? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24460
[Bug middle-end/24295] [4.1 Regression] Xorg broken, #pragma weak foo = bar no longer causes bar to be referenced
--- Comment #20 from cvs-commit at gcc dot gnu dot org 2005-10-20 19:30 --- Subject: Bug 24295 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-20 19:30:23 Modified files: gcc/testsuite : ChangeLog gcc: ChangeLog cgraphunit.c varasm.c gcc/testsuite/g++.old-deja/g++.abi: vtable2.C Added files: gcc/testsuite/gcc.dg: attr-alias-3.c gcc/testsuite/gcc.dg/weak: weak-14.c Log message: gcc/ChangeLog: PR middle-end/24295 * cgraphunit.c (cgraph_varpool_remove_unreferenced_decls): Mark alias targets. * varasm.c (find_decl_and_mark_needed): After cgraph global info is ready, stop marking functions, but still mark variables. gcc/testsuite/ChangeLog: PR middle-end/24295 * g++.old-deja/g++.abi/vtable2.C: Do not introduce external declarations with the same names as thunks' alias targets, use aliases instead. * gcc.dg/attr-alias-3.c: New test. * gcc.dg/weak/weak-14.c, gcc.dg/weak/weak-14a.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6219r2=1.6220 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.10193r2=2.10194 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cgraphunit.c.diff?cvsroot=gccr1=1.129r2=1.130 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gccr1=1.533r2=1.534 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/attr-alias-3.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/weak/weak-14.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24295
[Bug middle-end/24295] [4.1 Regression] Xorg broken, #pragma weak foo = bar no longer causes bar to be referenced
--- Comment #21 from aoliva at gcc dot gnu dot org 2005-10-20 19:32 --- Fixed. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24295
[Bug rtl-optimization/24460] [4.1 regression] Profiled bootstrap broken
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2005-10-20 19:35 --- It is the normal stage1. No, it isn't, look at the options. Normal stage1 has -g -O2 -fprofile-generate. It's very likely stage1 of stagefeedback_build. I'm replaying the bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24460
[Bug java/24461] New: array access in either GZIPInputStream, Inflater, natInflate.cc, or zlib
I hate posting bug reports without test cases, but this one is a bit beyond me - hopefully someone else will know whats up. Symptom: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int, int) (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0) at java.util.zip.GZIPInputStream.read(byte[], int, int) (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0) at java.io.FilterInputStream.read(byte[]) (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0) at net.i2p.i2ptunnel.HTTPResponseOutputStream$Pusher.run() (/home/jrandom/dev/i2p/build/libi2p.so) at java.lang.Thread.run() (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0) This occurs on EOF, the buffer passed in to GZIPInputStream is 8KB, and the length and offset fields are fine too (set by FilterInputStream as '0, buf.length'). The problem is, I believe, in the inf.getRemaining() and/or the fixed size buffer in GZIPInputStream: byte[] tmp = new byte[8]; // First copy remaining bytes from inflater input buffer. int avail = inf.getRemaining(); System.arraycopy(this.buf, this.len - avail, tmp, 0, avail); I have no idea why tmp is 8 bytes long, probably something I don't understand about zlib. inf.getRemaining() just returns 'z_streamp-avail_in', and from what I can see, that can either be set explicitly, via inflater.setInput(buf[], off, len), or implicitly, within zlib's inflate(z_streamp, Z_SYNC_FLUSH). My very cursory look into inflate(...) leads me nowhere, but InflaterInputStream.java seems to be allowing arbitrarily large setInput(buf, 0, buf.length) calls - e.g. line 157. The default buf.length is 4KB. Or, maybe is there something in the zlib format such that it will never have more than 8 bytes uninflated? FWIW, I'm on the latest zlib (1.2.3) and gcj 4.0.2 (and I haven't seen any updates on the related classes in gcj's cvsweb) =jr -- Summary: array access in either GZIPInputStream, Inflater, natInflate.cc, or zlib Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jrandom-gcc at i2p dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24461
[Bug fortran/24459] gfortran namelist regression
--- Comment #1 from ed at eh3 dot com 2005-10-20 19:53 --- The same error happens using gcc from cvs today (2005-10-20). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug c++/24452] [gomp] ICE in decl_jump_unsafe, at cp/decl.c:2153
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-20 20:14:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24452
[Bug c++/24451] [gomp] Return out of parallel loop not rejected
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-20 20:14:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24451
[Bug tree-optimization/24225] [4.1 Regression] ICE: segmentation fault in profile.c:branch_prob
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-20 21:03 --- Created an attachment (id=10035) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10035action=view) Hack that makes the test case work. Needs testing. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24225
[Bug middle-end/24462] New: packed-aligned structures are laid out differently
We have a binary incompatibility between 4.0.x and 4.1.x for:
struct B1_m_outer_p_inner {
char c;
double d;
} __attribute__ ((aligned)) __attribute__ ((packed));
Both fields are DECL_PACKED with 4.0.x:
record_type 0x2a959550d0 B1_m_outer_p_inner packed type_0 BLK
size integer_cst 0x2a95890d20 type integer_type 0x2a9589a270
bit_size_type constant invariant 128
unit size integer_cst 0x2a95890d50 type integer_type 0x2a9589a1a0 long
unsigned int constant invariant 16
user align 128 symtab 0 alias set -1
attributes tree_list 0x2a9595ec30
purpose identifier_node 0x2a95959230 packed
chain tree_list 0x2a9595ec00
purpose identifier_node 0x2a959591c0 aligned
fields field_decl 0x2a95955270 c
type integer_type 0x2a9589a4e0 char public QI
size integer_cst 0x2a95890450 constant invariant 8
unit size integer_cst 0x2a95890480 constant invariant 1
align 8 symtab 0 alias set -1 precision 8 min integer_cst
0x2a95890510 -128 max integer_cst 0x2a958905d0 127
pointer_to_this pointer_type 0x2a958b0ea0
packed QI file ../sa_x.c line 2 size integer_cst 0x2a95890450 8 unit
size integer_cst 0x2a95890480 1
align 8 offset_align 128
offset integer_cst 0x2a95890390 constant invariant 0
bit offset integer_cst 0x2a958ac3c0 constant invariant 0 context
record_type 0x2a959550d0 B1_m_outer_p_inner arguments integer_cst
0x2a95890390 0
chain field_decl 0x2a95955340 d type real_type 0x2a958add00 double
packed DF file ../sa_x.c line 3
size integer_cst 0x2a958909f0 constant invariant 64
unit size integer_cst 0x2a95890a20 constant invariant 8
align 8 offset_align 128 offset integer_cst 0x2a95890390 0 bit
offset integer_cst 0x2a95890450 8 context record_type 0x2a959550d0
B1_m_outer_p_inner arguments integer_cst 0x2a95890390 0
pointer_to_this pointer_type 0x2a95955680 chain type_decl 0x2a959551a0
D.1098
while none is with 4.1.x:
record_type 0x2a959719a0 B1_m_outer_p_inner packed type_0 BLK
size integer_cst 0x2a95891d20 type integer_type 0x2a958a20b0
bit_size_type constant invariant 128
unit size integer_cst 0x2a95891d50 type integer_type 0x2a958a2000 long
unsigned int constant invariant 16
user align 128 symtab 0 alias set -1
attributes tree_list 0x2a9597ed80
purpose identifier_node 0x2a959775b0 packed
chain tree_list 0x2a9597ed50
purpose identifier_node 0x2a95977540 aligned
fields field_decl 0x2a9597f000 c
type integer_type 0x2a958a22c0 char public QI
size integer_cst 0x2a95891450 constant invariant 8
unit size integer_cst 0x2a95891480 constant invariant 1
align 8 symtab 0 alias set -1 precision 8 min integer_cst
0x2a95891510 -128 max integer_cst 0x2a958915d0 127
pointer_to_this pointer_type 0x2a958b1d10
QI file ../sa_x.c line 2 size integer_cst 0x2a95891450 8 unit size
integer_cst 0x2a95891480 1
align 8 offset_align 128
offset integer_cst 0x2a95891390 constant invariant 0
bit offset integer_cst 0x2a958ae3c0 constant invariant 0 context
record_type 0x2a959719a0 B1_m_outer_p_inner
chain field_decl 0x2a9597f0c0 d type real_type 0x2a958b1420 double
DF file ../sa_x.c line 3
size integer_cst 0x2a958919f0 constant invariant 64
unit size integer_cst 0x2a95891a20 constant invariant 8
align 8 offset_align 128 offset integer_cst 0x2a95891390 0 bit
offset integer_cst 0x2a95891450 8 context record_type 0x2a959719a0
B1_m_outer_p_inner
pointer_to_this pointer_type 0x2a95971c60 chain type_decl 0x2a958afd00
D.1245
While the missing DECL_PACKED on the first field looks OK, DECL_PACKED on the
second field is required as the field start at bit offset 8.
--
Summary: packed-aligned structures are laid out differently
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
GCC build triplet: sparc64-*-*
GCC host triplet: sparc64-*-*
GCC target triplet: sparc64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24462
[Bug middle-end/24462] packed-aligned structures are laid out differently
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Keywords||ABI Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24462
[Bug tree-optimization/24307] [4.1 regression] ICE in early_tree_profile with fortran/computed gotos
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-11 13:44:20 |2005-10-20 21:10:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24307
[Bug tree-optimization/24307] [4.1 regression] ICE in early_tree_profile with fortran/computed gotos
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-20 21:11 --- http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01260.html Ignore the wrong bug number. This is just the same patch as the one in comment #2. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24307
[Bug other/24463] New: make install fails on AIX 5.2
AIX:doug:2 ../gcc-3.4.3/configure --srcdir=../gcc-3.4.3 --enable-languages=c,c++ --enable-threads=aix - --- make bootstrap (successful) make[8]: Nothing to be done for `all'. make[8]: Leaving directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/pthread/ppc64/libstdc++-v3/po' Making all in testsuite make[8]: Entering directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/pthread/ppc64/libstdc++-v3/testsuite' touch testsuite_wchar_t make[8]: Leaving directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/pthread/ppc64/libstdc++-v3/testsuite' make[8]: Entering directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/pthread/ppc64/libstdc++-v3' : make ; exec true AR_FLAGS=rc CC_FOR_BUILD=gcc CC_FOR_TARGET=/voltds/doug/tmp/gcc-3.4.3.aix/gcc/xgcc -B/voltds/doug/tmp/gcc-3.4.3.aix/gcc/ -B/usr/local/powerpc-ibm-aix5.2.0.0/bin/ -B/usr/local/powerpc-ibm-aix5.2.0.0/lib/ -isystem /usr/local/powerpc-ibm-aix5.2.0.0/include -isystem /usr/local/powerpc-ibm-aix5.2.0.0/sys-include CFLAGS=-O2 -g -O2 -pthread -maix64 CXXFLAGS=-g -O2 -pthread -maix64 CFLAGS_FOR_BUILD= CFLAGS_FOR_TARGET=-O2 -g -O2 INSTALL=../gcc-3.4.3/install-sh -c INSTALL_DATA=../gcc-3.4.3/install-sh -c -m 644 INSTALL_PROGRAM=../gcc-3.4.3/install-sh -c INSTALL_SCRIPT=../gcc-3.4.3/install-sh -c LDFLAGS=-pthread -maix64 LIBCFLAGS=-O2 -g -O2 -pthread -maix64 LIBCFLAGS_FOR_TARGET=-O2 -g -O2 MAKE=make MAKEINFO=/voltds/doug/tmp/gcc-3.4.3/missing makeinfo --split-size=500 --split-size=500PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh RUNTESTFLAGS= exec_prefix=/usr/local infodir=/usr/local/info libdir=/usr/local/lib includedir=/usr/local/include prefix=/usr/local tooldir=/usr/local/powerpc-ibm-aix5.2.0.0 gxx_include_dir=/usr/local/include/c++/3.4.3 AR=ar -X32_64 AS=as LD=ld LIBCFLAGS=-O2 -g -O2 -pthread -maix64 PICFLAG= RANLIB=ranlib NM=nm -B -X32_64 NM_FOR_BUILD= NM_FOR_TARGET=nm -B -X32_64 DESTDIR= WERROR= DO=all multi-do make[8]: Leaving directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/pthread/ppc64/libstdc++-v3' make[7]: Leaving directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/pthread/ppc64/libstdc++-v3' make[6]: Leaving directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/pthread/ppc64/libstdc++-v3' make[5]: Leaving directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/libstdc++-v3' make[4]: Leaving directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/libstdc++-v3' make[3]: Leaving directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/libstdc++-v3' make[2]: Leaving directory `/voltds/doug/tmp/gcc-3.4.3.aix/powerpc-ibm-aix5.2.0.0/libstdc++-v3' make[1]: Leaving directory `/voltds/doug/tmp/gcc-3.4.3.aix' --- # make install /bin/sh ../gcc-3.4.3/mkinstalldirs /usr/local /usr/local make[1]: Entering directory `/voltds/doug/tmp/gcc-3.4.3.aix/gcc' /bin/sh ../../gcc-3.4.3/gcc/mkinstalldirs /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3 mkdir -p -- /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3 /bin/sh ../../gcc-3.4.3/gcc/mkinstalldirs /usr/local/libexec/gcc/powerpc-ibm-aix5.2.0.0/3.4.3 mkdir -p -- /usr/local/libexec/gcc/powerpc-ibm-aix5.2.0.0/3.4.3 /bin/sh ../../gcc-3.4.3/gcc/mkinstalldirs /usr/local/bin /bin/sh ../../gcc-3.4.3/gcc/mkinstalldirs /usr/local/include mkdir -p -- /usr/local/include /bin/sh ../../gcc-3.4.3/gcc/mkinstalldirs /usr/local/info /bin/sh ../../gcc-3.4.3/gcc/mkinstalldirs /usr/local/lib /bin/sh ../../gcc-3.4.3/gcc/mkinstalldirs /usr/local/man/man1 /bin/sh ../../gcc-3.4.3/gcc/mkinstalldirs /usr/local/man/man7 mkdir -p -- /usr/local/man/man7 rm -f /usr/local/bin/g++ ../gcc-3.4.3/install-sh -c g++ /usr/local/bin/g++ make[1]: ../gcc-3.4.3/install-sh: Command not found make[1]: [c++.install-common] Error 127 (ignored) chmod a+x /usr/local/bin/g++ chmod: /usr/local/bin/g++: A file or directory in the path name does not exist. make[1]: [c++.install-common] Error 1 (ignored) rm -f /usr/local/bin/c++ ( cd /usr/local/bin \ ln g++ c++ ) ln: g++: A file or directory in the path name does not exist. make[1]: [c++.install-common] Error 1 (ignored) if [ -f cc1plus ] ; then \ if [ -f g++-cross ] ; then \ if [ -d /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/../../../../powerpc-ibm-aix5.2.0.0/bin/. ] ; then \ rm -f /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/../../../../powerpc-ibm-aix5.2.0.0/bin/g++; \ ../gcc-3.4.3/install-sh -c g++-cross /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/../../../../powerpc-ibm-aix5.2.0.0/bin/g++; \ rm -f /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/../../../../powerpc-ibm-aix5.2.0.0/bin/c++; \ ( cd /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/../../../../powerpc-ibm-aix5.2.0.0/bin \ ln g++ c++ ); \ else true; fi; \ else \ rm -f /usr/local/bin/powerpc-ibm-aix5.2.0.0-g++; \ ( cd /usr/local/bin \
[Bug other/24463] make install fails on AIX 5.2
--- Comment #1 from andreast at gcc dot gnu dot org 2005-10-20 21:27 --- Try configuring with an absolute path like: AIX:doug:2 ../gcc-3.4.3/configure --srcdir=../gcc-3.4.3 --enable-languages=c,c++ --enable-threads=aix /Path/to/your/gcc/source/gcc-3.4.3/configure --srcdir=/Path/to/your/gcc/source/gcc-3.4.3 --enable-languages=c,c++ --enable-threads=aix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24463
[Bug tree-optimization/24225] [4.1 Regression] ICE: segmentation fault in profile.c:branch_prob
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-20 21:40 ---
Created an attachment (id=10036)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10036action=view)
Alternate fix
As suggested by Andrew Pinski...
Put loci on the stack save and restore operations.
This gives:
f (a, b)
{
intD.0 sD.1611[0:D.1616];
voidD.35 * saved_stack.2D.1623;
voidD.35 * D.1622;
intD.0[0:D.1616] * s.1D.1621;
long unsigned intD.4 D.1620;
bit_size_type D.1619;
bit_size_type D.1618;
long unsigned intD.4 D.1617;
long unsigned intD.4 D.1616;
long intD.2 D.1615;
long intD.2 D.1614;
intD.0 b.0D.1613;
intD.0 D.1612;
# BLOCK 0, starting at line 5
# PRED: ENTRY
[t.c : 5] if ([t.c : 5] aD.1607 != 0) goto L0; else goto L1;
# SUCC: 1 2
# BLOCK 1, starting at line 6
# PRED: 0
L0:;
[t.c : 6] D.1612 = 1;
[t.c : 6] goto bb 3 (L3);
# SUCC: 3
# BLOCK 2, starting at line 8
# PRED: 0
L1:;
[t.c : 8] saved_stack.2D.1623 = __builtin_stack_save ();
[t.c : 8] b.0D.1613 = bD.1608;
[t.c : 8] D.1614 = (long intD.2) b.0D.1613;
[t.c : 8] D.1615 = D.1614 - 1;
[t.c : 8] D.1616 = (long unsigned intD.4) D.1615;
[t.c : 8] D.1617 = (long unsigned intD.4) b.0D.1613;
[t.c : 8] D.1618 = (bit_size_type) D.1617;
[t.c : 8] D.1619 = D.1618 * 32;
[t.c : 8] D.1617 = (long unsigned intD.4) b.0D.1613;
[t.c : 8] D.1620 = D.1617 * 4;
[t.c : 8] D.1617 = (long unsigned intD.4) b.0D.1613;
[t.c : 8] D.1618 = (bit_size_type) D.1617;
[t.c : 8] D.1619 = D.1618 * 32;
[t.c : 8] D.1617 = (long unsigned intD.4) b.0D.1613;
[t.c : 8] D.1620 = D.1617 * 4;
[t.c : 8] D.1622 = [t.c : 8] __builtin_alloca (D.1620);
[t.c : 8] s.1D.1621 = (intD.0[0:D.1616] *) D.1622;
[t.c : 9] D.1612 = 0;
[t.c : 9] __builtin_stack_restore (saved_stack.2D.1623);
# SUCC: 3
# BLOCK 3
# PRED: 1 2
L3:;
return D.1612;
# SUCC: EXIT
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24225
[Bug other/24463] make install fails on AIX 5.2
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-20 21:42 --- This was fixed in 3.4.4. This is a dup of bug 13993. *** This bug has been marked as a duplicate of 13993 *** -- 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=24463
[Bug bootstrap/13993] [3.4 Regression] Relative path as srcdir causes problem
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-10-20 21:42 --- *** Bug 24463 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nospampeeps at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13993
[Bug libstdc++/24450] Exception safety problem in messages/__timepunct
--- Comment #5 from pcarlini at suse dot de 2005-10-20 22:26 --- Actually, the leak is only in messages/__timepunct, I'm changing the Summary -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|Exception safety problem in |Exception safety problem in |locale::_Impl::_M_replace_ca|messages/__timepunct |tegories| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24450
[Bug libstdc++/24450] Exception safety problem in messages/__timepunct
--- Comment #6 from pcarlini at suse dot de 2005-10-20 22:27 --- Oops... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24450
[Bug tree-optimization/24225] [4.1 Regression] ICE: segmentation fault in profile.c:branch_prob
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-20 22:45 --- The second fix boostraps the compiler proper and it builds libstdc++ and libgfortran without problems. But it fails on cp-demangle.c for some reason. That's probably another case where we don't put a locus on statements in a gimplified statement list. Fixing that, who knows where else we'll discover similar problems... Therefore, at least for GCC 4.1 I'm more comfortable with my first patch. I'll bootstrap+test and profilebootstrap that patch and post it for comment if it doesn't cause any regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24225
[Bug middle-end/24446] [4.0 Regression] segfault with -Os -funit-at-a-time with IMA
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-20 23:03 ---
Hmm, this looks like invalid code.
file1.c:
int main(int argc, char **argv) { }
file2.c:
int main(int argc, char *argv[]) __attribute__ ((weak, alias (zcip_main)));
int zcip_main(int argc, char *argv[]) { }
---
I have to double check on this. 3.4.0 rejected this. 4.0.0 accepted this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|ice-on-valid-code |
Summary|segfault with -Os -funit-at-|[4.0 Regression] segfault
|a-time with IMA |with -Os -funit-at-a-time
||with IMA
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24446
[Bug middle-end/24446] [4.1 Regression] segfault with -Os -funit-at-a-time with IMA
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-20 23:14 --- I think this was already fixed by the patch for PR 24295, I am testing that theory. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||24295 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24446
[Bug c/23104] [4.1 Regression] C does not reject the same function in two different TUs with -combine
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-20 23:51 --- *** Bug 24446 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rep dot nop at aon dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
[Bug middle-end/24446] [4.1 Regression] segfault with -Os -funit-at-a-time with IMA
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-20 23:51 --- This is actually a dup of bug 23104. This is invalid code. *** This bug has been marked as a duplicate of 23104 *** -- 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=24446
[Bug debug/24444] [4.1 regression] invalid register in debug info
-- wilson at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug target/24465] New: -mminimal-toc miscompilation of __thread vars
RS6000_PIC_OFFSET_TABLE_REGNUM isn't being set up for functions that don't need
a constant pool but access __thread vars using __tls_get_addr.
/* Fails with -m64 -mminimal-toc -fPIC */
static __thread int x;
int foo (void)
{
return x;
}
This is the reason why powerpc64 has been getting lots of libjava failures
since this libjava change: 2005-09-27 Tom Tromey [EMAIL PROTECTED]
--
Summary: -mminimal-toc miscompilation of __thread vars
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: target
AssignedTo: amodra at bigpond dot net dot au
ReportedBy: amodra at bigpond dot net dot au
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24465
[Bug target/24465] [4.1 Regression] -mminimal-toc miscompilation of __thread vars
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-21 03:47 --- Confirmed, This is a latent bug but shows up as testsuite regressions which is why I am marking it as a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-10-21 03:47:35 date|| Summary|-mminimal-toc miscompilation|[4.1 Regression] -mminimal- |of __thread vars|toc miscompilation of ||__thread vars Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24465
[Bug fortran/17744] ice in assignment of derived type constructor
--- Comment #6 from paulthomas2 at wanadoo dot fr 2005-10-21 04:19 --- Subject: Re: ice in assignment of derived type constructor Paul, do you want to add this as a testcase? I was in two minds about it. Checking that a structure exists before dereferencing it is not going to break itself, is it. On the other hand, it adds to the checks of things that gfortran must do. What swings it is the opportunity to have one last go at cvs! Best regards Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17744
[Bug c/24466] New: uprgading of gcc
Hello, We are upgrading the gcc-2.95 of lynxos t0 2.95 in powerpc. we are facing some complier errors. this is the error we got NM_FOR_TARGET=nm AWK=gawk \ LIBGCC2_CFLAGS=-O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes\ INCLUDES=-I. -I. -I../../gcc-3.2.2/gcc -I../../gcc-3.2.2/gcc/. -I../../gcc-3\ CONFIG_H=config.h auto-host.h ../../gcc-3.2.2/gcc/../include/ansidecl.h ../.\ LIB1ASMSRC='' \ MAKEOVERRIDES= \ -f libgcc.mk all for d in libgcc thread libgcc/thread soft-float libgcc/soft-float altivec libgc\ if [ -d $d ]; then true; else /bin/sh ../../gcc-3.2.2/gcc/mkinstalldirs $d; f\done if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi /basav/renju/objdir/gcc/xgcc -B/basav/renju/objdir/gcc/ -B/usr/powerpc-lynx-lynocommand line:1:12: warning: system re-asserted ..: In function `|}H.|?x..?xK??..??xH!?...': ..:4489792: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. make[2]: *** [libgcc/./_divdi3.o] Error 1 make[1]: *** [stmp-multilib] Error 2 make: *** [all-gcc] Error 2 regards, Basavaraj -- Summary: uprgading of gcc Product: gcc Version: 3.2.2 Status: UNCONFIRMED Severity: critical Priority: P1 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: basavaraja_g at mindtree dot com GCC build triplet: powerpc GCC host triplet: Powerpc GCC target triplet: powerpc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24466
[Bug fortran/24440] [4.0/4.1 regression] gfortran failed to build 187.facerec
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-21 04:33 --- Subject: Bug 24440 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-21 04:33:10 Modified files: gcc/testsuite/gfortran.dg: assumed_size_dt_dummy.f90 gcc/testsuite : ChangeLog Log message: 2005-10-21 Paul Thomas [EMAIL PROTECTED] PR fortran/24440 * gfortran.dg/assumed_size_dt_dummy.f90: Add test for scalar case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assumed_size_dt_dummy.f90.diff?cvsroot=gccr1=1.1r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6223r2=1.6224 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24440
[Bug fortran/24440] [4.0/4.1 regression] gfortran failed to build 187.facerec
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-21 04:37 --- Subject: Bug 24440 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-10-21 04:37:42 Modified files: gcc/testsuite/gfortran.dg: assumed_size_dt_dummy.f90 gcc/testsuite : ChangeLog Log message: 2005-10-21 Paul Thomas [EMAIL PROTECTED] PR fortran/24440 * gfortran.dg/assumed_size_dt_dummy.f90: Add test for scalar case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assumed_size_dt_dummy.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.1.2.1r2=1.1.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.476r2=1.5084.2.477 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24440
[Bug target/24466] uprgading of gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-21 04:37 --- So does this happen when you build gcc with make boostrap instead of make all. Also please follow the instructions on the web site for installing gcc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |WAITING Component|c |target Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24466
[Bug target/24466] uprgading of gcc
--- Comment #2 from basavaraja_g at mindtree dot com 2005-10-21 04:51 --- (In reply to comment #1) So does this happen when you build gcc with make boostrap instead of make all. Also please follow the instructions on the web site for installing gcc. We have given the configuration as ../gcc-3.2.2/configure --prefix=/usr --build=powerpc-lynx-lynxos4.0 --host=powerpc-lynx-lynxos4.0 --with-gnu-as --with-gnu-ld and we gave as make all-gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24466
[Bug target/24465] [4.1 Regression] -mminimal-toc miscompilation of __thread vars
--- Comment #2 from amodra at bigpond dot net dot au 2005-10-21 05:05
---
Actually, it's not that RS6000_PIC_OFFSET_TABLE_REGNUM isn't being set up, it's
that RS6000_PIC_OFFSET_TABLE_REGNUM is wrongly being using for tls accesses.
As currently implemented by gcc, powerpc tls uses [EMAIL PROTECTED]@tlsgd and
similar. ie.
we are expecting the linker to manage allocation of tls entries in the got
rather than having gcc allocate them itself in toc sections. This means that
powerpc64 should use r2 for tls always, even when -mminimal-toc.
Testing the following fix.
Index: gcc/config/rs6000/rs6000.c
===
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
retrieving revision 1.872
diff -u -p -r1.872 rs6000.c
--- gcc/config/rs6000/rs6000.c 6 Oct 2005 22:58:59 - 1.872
+++ gcc/config/rs6000/rs6000.c 21 Oct 2005 05:02:57 -
@@ -2979,7 +2979,7 @@ rs6000_legitimize_tls_address (rtx addr,
rtx r3, got, tga, tmp1, tmp2, eqv;
if (TARGET_64BIT)
- got = gen_rtx_REG (Pmode, TOC_REGISTER);
+ got = gen_rtx_REG (Pmode, 2);
else
{
if (flag_pic == 1)
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Target Milestone|4.1.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24465
