[Bug target/19340] Compilation SEGFAULTs with -O1 -fschedule-insns2 -fsched2-use-traces on an x86 architecture.
--- Comment #7 from uros at kss-loka dot si 2005-11-08 08:12 --- Fixed on mainline and 4.0 branch. -- uros at kss-loka dot si changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|3.4.0 4.0.0 |3.4.0 Known to work||4.0.3 4.1.0 Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19340
[Bug target/24315] [3.4 Regression] amd64 fails -fpeephole2
--- Comment #15 from bonzini at gcc dot gnu dot org 2005-11-08 08:19 --- now fixed on 4.0 branch too -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.3.5 4.0.0 3.4.5 |3.3.5 4.0.2 3.4.5 Known to work|3.2.3 4.1.0 |3.2.3 4.1.0 4.0.3 Summary|[3.4/4.0 Regression] amd64 |[3.4 Regression] amd64 fails |fails -fpeephole2 |-fpeephole2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24315
[Bug c++/21123] [4.0/4.1 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #25 from jason at gcc dot gnu dot org 2005-11-08 08:32 --- Subject: Bug 21123 Author: jason Date: Tue Nov 8 08:32:26 2005 New Revision: 106634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106634 Log: PR c++/21123 * cp/method.c (use_thunk): Use build_cplus_new instead of force_target_expr. * tree.h (CALL_FROM_THUNK_P): Add CALL_EXPR_CHECK. Added: trunk/gcc/testsuite/g++.dg/inherit/thunk4.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug c/24101] [3.4/4.0/4.1 Regression] Segfault with preprocessed source
--- Comment #9 from uros at kss-loka dot si 2005-11-08 10:04 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00498.html -- uros at kss-loka dot si changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00498.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24101
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #14 from thebohemian at gmx dot net 2005-11-08 10:15 --- > But we don't need to use ffi_call here, we can just call the exception > throwing function directly. Right. That worked fine. > Then you'll realize that these functions don't need to be separate at all. Yep. I made the trampoline function the error throwing function now. > Then you'll realize that you don't need to bother setting up > the ffi_cif - all you need is the exception argument. I doubt that this is right. The ffi_prep_closure() needs to know which arguments are given to it. AFAIK the caller can cast a ffi_closure pointer to any kind of function pointer (OK, except varargs). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #10 from ahu at ds9a dot nl 2005-11-08 10:15 --- An easy solution might be to check for __gthread_active_p() in bits/basic_string before calling __exchange_and_add, and to do this locally and non-atomically otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-08 10:16 --- Note that it is too late for the inliner to come in at builtin expansion time. It may be possible to "fix" this with the SSA inliner on IPA branch, but I'm not sure if it is worth it. Maybe Honza can give some input? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #11 from pcarlini at suse dot de 2005-11-08 10:53 --- (In reply to comment #10) > An easy solution might be to check for __gthread_active_p() in > bits/basic_string before calling __exchange_and_add, and to do this locally > and > non-atomically otherwise. Yes, this solution can work. Actually, I'm hoping for something a bit cleaner. Remember that we want a single clean solution for *all* the places where the atomics are used and most are inside the built *.so. -- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|4.0.3 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24692] Atomic builtins for v3
--- Comment #10 from pcarlini at suse dot de 2005-11-08 10:58 --- Ok, apparently short-term at least, "smart" solutions using libgcc and dynamic linking will not be implemented (one blocker are systems using a static libgcc.a). Therefore this one becomes a pure libstdc++-v3 PR. Then what we can improve is rather limited: we can inline the atomics on architecture families that uniformly implement the builtins (e.g., powerpc -> ok, i?86 -> not ok). The atomics will also remain in the library, however, for ABI stability reasons. -- pcarlini at suse dot de changed: What|Removed |Added CC|rth at gcc dot gnu dot org | AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Component|other |libstdc++ Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-08 10:58:34 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-08 11:08 --- (In reply to comment #2) > In function `*_gfortrani_set_fpu':.\ > /fpu-target.h:42: warning: warning: fedisableexcept is not implemented and > will > always fail^M You're seeing this warning only for the in-pack testcase ? Can you try to compile and run another testcase (not inside the library framework) and tell us what the compiler/linker says? Since the in-pack testcase has nothing to do with the set_fpu function, I don't see how on earth this could happen... > So I guess you'd see it for targets where floating point rounding cannot be > changed (usually, no hardware support and implemented through fp-bit.c). Well, even in that case, that shouldn't happen. If I read the doc correctly, in that case the FE_* macros are supposed not to be defined, but no warning should be issued. I'll look into it (but can't promise anything, I don't have access to such target). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24342
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #12 from pcarlini at suse dot de 2005-11-08 11:30 --- In my opinion, the way to go is consistently using the macro __GTHREADS which is undefined when --enable-threads=single is passed. This is consistent with the approach already used in mt_allocator, for instance. And indeed, in mt_alloc nothing is thread-safe in that case (but much simpler and faster!). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #13 from bert dot hubert at netherlabs dot nl 2005-11-08 11:43 --- Subject: Re: __gnu_cxx::__exchange_and_add is called even for single threaded applications On Tue, Nov 08, 2005 at 11:30:46AM -, pcarlini at suse dot de wrote: > --- Comment #12 from pcarlini at suse dot de 2005-11-08 11:30 --- > In my opinion, the way to go is consistently using the macro __GTHREADS which > is undefined when --enable-threads=single is passed. This is consistent with > the approach already used in mt_allocator, for instance. And indeed, in > mt_alloc > nothing is thread-safe in that case (but much simpler and faster!). > -- __GTHREADS is fixed for libstdc++ depending on enable-threads=single|posix, --whereas __gthread_active_p() depends on if the binary was compiled with --pthread. Indeed, other parts of libstdc++ already rely on __gthread_active_p(). Using __GTHREADS would get us halfway, but nobody in his right mind (certainly no distributor) is going to compile with --enable-threads=single on a platform that does posix - you get a crippled compiler. I'd hate to have to keep two compilers around. I've verified that adding a check on __gthread_active_p() to bits/basic_string.h does the right thing. It only does so after a complete recompile of libstdc++ though, the code is indeed instantiated earlier (as you mentioned already). The sticking point is people who don't do pthreads but DO need atomic operations because they use some other threading system. There might be a need for a mechanism to make __gthread_active_p() return true in that case. Ideas? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #14 from pcarlini at suse dot de 2005-11-08 11:50 --- (In reply to comment #13) > Indeed, other parts of libstdc++ already rely on __gthread_active_p(). Sure, see mt_alloc: there is an external __GTHREADS and an internal __gthread_active_p(). > Using __GTHREADS would get us halfway, but nobody in his right mind > (certainly no distributor) is going to compile with --enable-threads=single > on a platform that does posix - you get a crippled compiler. I'd hate to > have to keep two compilers around. This is meaningless. The configure option is present and has to be used consistently in the whole library. Again, see mt_alloc. > I've verified that adding a check on __gthread_active_p() to > bits/basic_string.h does the right thing. It only does so after a complete > recompile of libstdc++ though, the code is indeed instantiated earlier (as > you mentioned already). Of course does the right thing, there is no doubt about this. But, again, it's inconsistent and ugly adding conditionals all around only in basic_string and not touching all the other places. We simply want to do the same thing that mt_alloc is already doing, centralized in one place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #15 from bert dot hubert at netherlabs dot nl 2005-11-08 11:58 --- Subject: Re: __gnu_cxx::__exchange_and_add is called even for single threaded applications On Tue, Nov 08, 2005 at 11:50:24AM -, pcarlini at suse dot de wrote: > Of course does the right thing, there is no doubt about this. But, again, > it's inconsistent and ugly adding conditionals all around only in basic_string > and not touching all the other places. We simply want to do the same thing > that mt_alloc is already doing, centralized in one place. How about we make (or I contribute) a set of 'atomic-if-needed' 'exchange-and-add' and 'add' inlineable functions? These could just replace __gnu_cxx::__exchange_and_add in all places and automatically do the right thing: lock when needed and just add otherwise. The added bonus is that for unthreaded applications, still the majority, everything is inlined anyhow, which even works on i386. My fear is that otherwise the unthreaded case is never ever going to see real use as the amount of people that will recompile their compiler or libstdc++ is going to be rather minimal. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #16 from pcarlini at suse dot de 2005-11-08 12:06 --- (In reply to comment #15) > How about we make (or I contribute) a set of 'atomic-if-needed' > 'exchange-and-add' and 'add' inlineable functions? > > These could just replace __gnu_cxx::__exchange_and_add in all places and > automatically do the right thing: lock when needed and just add otherwise. > > The added bonus is that for unthreaded applications, still the majority, > everything is inlined anyhow, which even works on i386. Indeed, that's the idea. But: 1- Do you have a copyright assignment on file? 2- Are you aware of the various binary compatibility quirks? That means that *nothing* has to to change (besides performance) wrt to exported symbols and interoperability between binaries, if the user doesn't pass any --thread-model. It's not trivial, but we can work out something for 4.2. > My fear is that otherwise the unthreaded case is never ever going to see > real use as the amount of people that will recompile their compiler or > libstdc++ is going to be rather minimal. To repeat: this is needed anyway, because we want to use consistently the --thread-model configure option. Nothing will go in not checking also and exploting the macro. Then comes everything else... And, sorry, *you* pointed out this inconsistency in the first place ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug preprocessor/215] Problem when generating depencies with -MD and -MMD
--- Comment #3 from maslowski73 at wp dot pl 2005-11-08 12:09 --- GCC version 3.3.6 and 3.3.2 have this bug either. The dependency files appear in the current directory. But, if the preprocessing fails the dependency file (although empty) remains in the right place. How to repeat: echo "#include" > test.c gcc -MD -o /tmp/test.o -c test.c ls -l /tmp/test.d cat /tmp/test.d echo "#include " > test.c gcc -MD -o /tmp/test.o -c test.c ls -l /tmp/test.d ./test.d cat /tmp/test.d cat ./test.d -- maslowski73 at wp dot pl changed: What|Removed |Added CC||maslowski73 at wp dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=215
[Bug preprocessor/24732] New: Invalid location of depency files generated with -MD and -MMD
+++ This bug was initially created as a clone of Bug #215 +++ When compiling and generating dependencies (using -MD or -MMD): and using option -o with a relative or absolute path for the resulting object file, the rule generated should reflect the correct location of the .o file Instead, the dependency file appears in the current directory. But, if the preprocessing fails the dependency file (although empty) remains in the right place. How to repeat: echo "#include" > test.c gcc -MD -o /tmp/test.o -c test.c ls -l /tmp/test.d cat /tmp/test.d echo "#include " > test.c gcc -MD -o /tmp/test.o -c test.c ls -l /tmp/test.d ./test.d cat /tmp/test.d cat ./test.d -- Summary: Invalid location of depency files generated with -MD and -MMD Product: gcc Version: 3.3.6 Status: UNCONFIRMED Severity: minor Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: maslowski73 at wp dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24732
[Bug c++/13668] thread local storage: static class member does not work
--- Comment #7 from jakub at gcc dot gnu dot org 2005-11-08 12:18 --- Why are you so sure it is not a GCC bug? It clearly is a C++ frontend bug: grep -C1 _ZN5TemplImE2_tE __thread.s __threadmain.s __thread.s- movq-16(%rbp), %rax __thread.s: movq%rax, _ZN5TemplImE2_tE(%rip) __thread.s- leave -- __thread.s- movq%rdi, -8(%rbp) __thread.s: movq_ZN5TemplImE2_tE(%rip), %rax __thread.s- leave -- __thread.s- movq(%rax), %rax __thread.s: movq$_ZN5TemplImE2_tE, (%rsp) __thread.s- movq%rdx, %r9 -- __thread.s- movq(%rax), %rax __thread.s: movq$_ZN5TemplImE2_tE, (%rsp) __thread.s- movq%rdx, %r9 -- __threadmain.s- .zero 1 __threadmain.s:.globl _ZN5TemplImE2_tE __threadmain.s- .section.tbss __threadmain.s- .align 8 __threadmain.s: .type _ZN5TemplImE2_tE, @object __threadmain.s: .size _ZN5TemplImE2_tE, 8 __threadmain.s:_ZN5TemplImE2_tE: __threadmain.s- .zero 8 As you can see, _ZN5TemplImE2_tE is correctly declared as a .tbss object in __threadmain.s, but __thread.s works with that object as if it wasn't __thread variable. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13668
[Bug c++/13668] thread local storage: static class member does not work
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED Last reconfirmed|-00-00 00:00:00 |2005-11-08 12:23:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13668
[Bug target/24265] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fmove-loop-invariants -mtune=pentiumpro
--- Comment #7 from uros at kss-loka dot si 2005-11-08 12:40 --- Created an attachment (id=10173) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10173&action=view) Patch to fix the ice This patch fixes the failure for me, but... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24265
[Bug c++/13668] thread local storage: static class member does not work
--- Comment #8 from simon dot marshall at misys dot com 2005-11-08 12:51 --- FYI, I raised this error with glibc with a slightly different attachment. http://sourceware.org/bugzilla/show_bug.cgi?id=1830 has the code Jakub refers to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13668
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-08 12:52 --- (In reply to comment #18) > Bootstrap of gcc-4.1-20051105 succeeded for c,c++,objc,obj-c++. > Testsuite still in progress. This is good enough to close this as fixed. Thanks. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug target/24265] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fmove-loop-invariants -mtune=pentiumpro
--- Comment #8 from uros at kss-loka dot si 2005-11-08 12:53 ---
> This patch fixes the failure for me, but...
... we actually gain nothing here.
>From .loop2_done, we have following sequence, where mem->reg load is pushed out
of the loop:
(insn 21 16 39 0 (set (reg:DF 64)
(mem/u/c/i:DF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S8 A64])) -1
(nil)
(nil))
;; End of basic block 0, registers live:
(nil)
(note 39 21 17 NOTE_INSN_LOOP_BEG)
;; Start of basic block 1, registers live: (nil)
(code_label 17 39 18 1 2 "" [1 uses])
(note 18 17 47 1 [bb 1] NOTE_INSN_BASIC_BLOCK)
(insn 47 18 22 1 (set (mem:DF (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A32])
(reg:DF 64)) -1 (nil)
(nil))
However, in .postreload, the insn 21 (now insn 53) is moved back _into_ the
loop (why?):
(note 21 16 39 0 NOTE_INSN_DELETED)
;; End of basic block 0, registers live:
6 [bp] 7 [sp] 16 [argp] 20 [frame] 60 64
(note 39 21 17 NOTE_INSN_LOOP_BEG)
;; Start of basic block 1, registers live: 6 [bp] 7 [sp] 59 60 64
(code_label 17 39 18 1 2 "" [1 uses])
(note 18 17 53 1 [bb 1] NOTE_INSN_BASIC_BLOCK)
(insn 53 18 47 1 (set (reg:DF 8 st)
(mem/u/c/i:DF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S8 A64])) 63
{*movdf_noin
teger} (nil)
(nil))
(insn 47 53 54 1 (set (mem:DF (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A32])
(reg:DF 8 st)) 63 {*movdf_nointeger} (nil)
(nil))
Proposed patch thus only fixes the damage. Otherwise, all this register
moving/copying doesn't gain anything, as reload fixes something on its own.
Also, REG_EQUAL notes are lost (before and after the patch). This results in
following asm:
...
movl $-1717986918, 8(%esp)
movl $1070176665, 12(%esp)
fldl -16(%ebp)
fstpl (%esp)
call dset
movl $1, %ebx
.L2:
fldl .LC0 <<< reload moves this insn back into the loop
fstpl 8(%esp)
fldl -16(%ebp)
fstpl (%esp)
call dset
incl %ebx
cmpl $4, %ebx
jne .L2
addl $36, %esp
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24265
[Bug c++/21123] [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #26 from pinskia at gcc dot gnu dot org 2005-11-08 12:54 --- Fixed at least on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.1.0 |4.0.0 4.0.3 Known to work|3.4.4 |3.4.4 4.1.0 Summary|[4.0/4.1 regression] ICE in |[4.0 regression] ICE in |cp_expr_size, at cp/cp- |cp_expr_size, at cp/cp- |objcp-common.c:101 |objcp-common.c:101 Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #15 from green at redhat dot com 2005-11-08 12:54 --- (In reply to comment #14) > > Then you'll realize that you don't need to bother setting up > > the ffi_cif - all you need is the exception argument. > I doubt that this is right. The ffi_prep_closure() needs to know which > arguments are given to it. Ah - you're right, of course. But in this case it seems like we can simply define it as zero argument function, returning void. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug rtl-optimization/22002] [4.0 Regression] internal consistency failure with -funroll-loops
--- Comment #6 from amodra at bigpond dot net dot au 2005-11-08 12:58
---
Looks like combine is not updating reg life info.
(gdb) set var dump_file=stderr
(gdb) n
(gdb)
Register 137 died unexpectedly.
(gdb)
;; basic block 6, loop depth 0, count 0
;; prev block 5, next block 7
;; pred: 5 [50.0%] (fallthru)
;; succ: 7 [100.0%] (fallthru)
;; Registers live at start: 1 [1] 31 [31] 67 [ap] 128 134 137 139 141 151
[snip]
pr22002.i.16.life
;; Start of basic block 6, registers live: 1 [1] 31 [31] 67 [ap] 128 134 137
139 141 151
(note 136 145 118 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 118 136 120 6 (set (reg:DF 127 [ D.1135 ])
(reg:DF 137)) 285 {*movdf_hardfloat64} (nil)
(expr_list:REG_DEAD (reg:DF 137)
(expr_list:REG_EQUAL (const_double:DF 2.0e+0 [0x0.8p+2])
(nil
[snip]
(insn 123 122 124 6 (set (reg:DF 141)
(mult:DF (reg:DF 127 [ D.1135 ])
(reg:DF 141))) 179 {*muldf3_fpr} (insn_list:REG_DEP_TRUE 118 (nil))
(expr_list:REG_DEAD (reg:DF 127 [ D.1135 ])
(expr_list:REG_EQUAL (const_double:DF
2.5132741228718344927983707748353481292724609375e+1 [0x0.c90fdaa22168cp+5])
(nil
== pr22002.i.17.combine
;; Start of basic block 6, registers live: 1 [1] 31 [31] 67 [ap] 128 134 137
139 141 151
(note 136 145 118 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(note 118 136 120 6 NOTE_INSN_DELETED)
[snip]
(insn 123 122 124 6 (set (reg:DF 141)
(plus:DF (reg:DF 141)
(reg:DF 141))) 177 {*adddf3_fpr} (nil)
(expr_list:REG_EQUAL (const_double:DF
2.5132741228718344927983707748353481292724609375e+1 [0x0.c90fdaa22168cp+5])
(nil)))
(note 124 123 125 6 NOTE_INSN_DELETED)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22002
[Bug c++/19450] __thread static class members
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 13:02 --- *** Bug 13668 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||simon dot marshall at misys ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19450
[Bug c++/13668] thread local storage: static class member does not work
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-08 13:02 --- *** This bug has been marked as a duplicate of 19450 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13668
[Bug c++/19450] __thread static class members
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-10-27 16:32:35 |2005-11-08 13:07:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19450
[Bug target/24265] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fmove-loop-invariants -mtune=pentiumpro
--- Comment #9 from uros at kss-loka dot si 2005-11-08 13:23 ---
Bah... set_unique_reg_note is needed:
/* If new move insn is invalid (i.e. move of const_double to
387 stack register), force constant into memory. */
if (recog_memoized (inv->insn) == -1)
{
rtx src = SET_SRC (set);
if (GET_CODE (src) == CONST_DOUBLE)
{
SET_SRC (set) = validize_mem (force_const_mem (mode, src));
set_unique_reg_note (inv->insn, REG_EQUAL, src);
}
}
to produce:
movl $1, %ebx
.L2:
movl $-1717986918, 8(%esp)
movl $1070176665, 12(%esp)
fldl -16(%ebp)
fstpl (%esp)
call dset
addl $1, %ebx
cmpl $4, %ebx
jne .L2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24265
[Bug libstdc++/24692] Atomic builtins for v3
--- Comment #11 from pcarlini at suse dot de 2005-11-08 13:37 --- Changing the declarations in include/bits/atomicity.h to inline definitions forwarding to the builtins and including instead of in config/cpu/*/atomicity.h for the supported arch families would be most of it, probably. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
[Bug target/24265] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fmove-loop-invariants -mtune=pentiumpro
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-08 13:45 --- The patch from comment #7 is wrong. The proper fix is already on the killloop-branch. You could try my patch for PR 24408, which should depend on this one. -- steven at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||24408 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24265
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #10 from dir at lanl dot gov 2005-11-08 14:18 --- The make bootstrap ends with - make bootstrap ... ... checking for .preinit_array/.init_array/.fini_array support... no checking if mkdir takes one argument... no Using `../.././gcc/config/rs6000/rs6000.c' for machine-specific logic. Using `../.././gcc/config/rs6000/rs6000.md' as machine description file. Using the following target machine macro files: ../.././gcc/config/rs6000/rs6000.h ../.././gcc/config/darwin.h ../.././gcc/config/rs6000/darwin.h ../.././gcc/config/rs6000/darwin8.h Using host-darwin.o host-ppc-darwin.o for host machine hooks. checking whether NLS is requested... yes checking for catalogs to be installed... be ca da de el es fr ja nl rw sv tr zh_CN checking what assembler to use... /usr/bin/as checking what linker to use... /usr/bin/ld checking what nm to use... /usr/bin/nm checking what objdump to use... /Users/dir/bin/bin/objdump checking assembler for .balign and .p2align... no checking assembler for .p2align with maximum skip... yes checking assembler for working .subsection -1... no checking assembler for .weak... no checking assembler for .nsubspa comdat... no checking assembler for .hidden... no checking linker for .hidden support... no checking assembler for .sleb128 and .uleb128... no checking assembler for eh_frame optimization... no checking assembler for section merging support... no checking assembler for section merging support... (cached) no checking assembler for COMDAT group support... no checking assembler for COMDAT group support... no checking assembler for thread-local storage support... no checking linker -Bstatic/-Bdynamic option... no checking assembler for .machine directive support... yes checking assembler for mfcr field support... yes checking assembler for popcntb support... no checking assembler for rel16 relocs... no checking assembler for dwarf2 debug_line support... no checking assembler for buggy dwarf2 .file directive... no checking assembler for --gdwarf2 option... no checking assembler for --gstabs option... yes checking linker read-only and read-write section mixing... unknown checking linker PT_GNU_EH_FRAME support... no checking linker position independent executable support... no checking linker --as-needed support... no checking linker --sysroot support... no Using ggc-page for garbage collection. checking whether to enable maintainer-specific portions of Makefiles... no Links are now set up to build a native compiler for powerpc-apple-darwin8.3.0. updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: creating gccbug config.status: creating mklibgcc config.status: creating libada-mk config.status: creating auto-host.h config.status: executing default commands Bootstrapping the compiler make[1]: *** No rule to make target `bootstrap'. Stop. make: *** [bootstrap] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #17 from bert dot hubert at netherlabs dot nl 2005-11-08 14:26 --- Subject: Re: __gnu_cxx::__exchange_and_add is called even for single threaded applications On Tue, Nov 08, 2005 at 12:06:02PM -, pcarlini at suse dot de wrote: > To repeat: this is needed anyway, because we want to use consistently the > --thread-model configure option. Nothing will go in not checking also and > exploting the macro. Then comes everything else... And, sorry, *you* pointed > out this inconsistency in the first place ;) True - but would #if __GTHREADS if(__gthread_active_p()) be ok? So check both? I've discussed a bit with Momchil Velikov and we feel it might be good if there were a generic way for an application or library to signal that multiple threads might be active. Momchil fakes this by defining the pthread symbol that __gthread_active_p() looks for, but that is not generic enough. This would enable libstdc++ to turn on its locking or atomic operations, but remain fast and unlocked for truly single threaded programs. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #18 from pcarlini at suse dot de 2005-11-08 14:34 --- (In reply to comment #17) > > To repeat: this is needed anyway, because we want to use consistently the > > --thread-model configure option. Nothing will go in not checking also and > > exploting the macro. Then comes everything else... And, sorry, *you* pointed > > out this inconsistency in the first place ;) > > True - but would #if __GTHREADS if(__gthread_active_p()) be ok? So check > both? Sure, this is the general idea. I'm a little bit concerned that for something apparently so elemental as an addiction (atomic, yes...) we are going to add a conditional, but probably, given the many cycles of atomics, it's ok. Any chance you can benchmark a bit that? I gather you already played with adding those checks, can you measure the overhead of the conditional alone compared to not doing nothing (i.e., non-atomic inline addition/subtraction). > I've discussed a bit with Momchil Velikov and we feel it might be good if > there were a generic way for an application or library to signal that > multiple threads might be active. Momchil fakes this by defining the pthread > symbol that __gthread_active_p() looks for, but that is not generic enough. Frankly, this is another issue. What we are going to do for *this* PR is working along the lines of mt_allocator and the rest of the library, which are largely relying on __gthread_active_p() in its present form and __GTHREAD, nothing else. If you feel something can be improved about __gthread_active_p() please submit a detailed, separate PR. Probably, it's not even a libstdc++ PR... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications
--- Comment #19 from pcarlini at suse dot de 2005-11-08 14:54 --- (In reply to comment #18) > Sure, this is the general idea. I'm a little bit concerned that for something > apparently so elemental as an addiction (atomic, yes...) we are going to add > a conditional, but probably, given the many cycles of atomics, it's ok. Any > chance you can benchmark a bit that? I gather you already played with adding > those checks, can you measure the overhead of the conditional alone compared > to not doing nothing (i.e., non-atomic inline addition/subtraction). Actually, this kind of benchmarking is not necessary, because currently we are always using the normal atomics. We have only to check that the additional __gthread_active_p() conditional is not measurable wrt the atomics itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #11 from dir at lanl dot gov 2005-11-08 15:15 ---
Down loading gfortran using svn took 40 percent longer and gave the same
results on the build -
By the way the GNU Fortran Page -
http://gcc.gnu.org/fortran/
still says to use anonymous CVS
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d'` ; \
for mlib in $MLIBS ; do \
rm -f ${mlib}/libgcc_s.10.4.dylib || exit 1 ; \
ln -s ../libgcc_s.10.4.dylib ${mlib}/libgcc_s.10.4.dylib || exit 1 ; \
done
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d' -e 's/^/_/'` ; \
for mlib in '' $MLIBS ; do \
strip -o libgcc_s.10.4.dylib_T${mlib} \
-s ../.././gcc/config/rs6000/darwin-libgcc.10.4.ver -c -u \
libgcc_s${mlib}.1.dylib || exit 1 ; \
done
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/gfortran/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d' -e 's/^/_/'` ; \
for mlib in '' $MLIBS ; do \
strip -o libgcc_s.10.5.dylib_T${mlib} \
-s ../.././gcc/config/rs6000/darwin-libgcc.10.5.ver -c -u \
libgcc_s${mlib}.1.dylib || exit 1 ; \
done
Could Not Open (-o) To Read
Could Not Open (-o) To Read
make[2]: *** [libgcc_s.10.5.dylib] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [libgcc_s.10.4.dylib] Error 1
rm cpp.pod gfortran.pod fsf-funding.pod gpl.pod gcc.pod gcov.pod gfdl.pod
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug c++/24734] New: [gomp] "#pragma omp master" doesn't work in templates
The following program doesn't work correctly when compiled with -fopenmp:
==
#include
template void foo()
{
#pragma omp parallel
{
printf("ALL\n");
#pragma omp master
printf("MASTER\n");
}
}
int main()
{
foo<0>();
return 0;
}
==
The output (with two threads) is just:
ALL
ALL
If I make foo a non-template function, I get the correct output:
ALL
ALL
MASTER
--
Summary: [gomp] "#pragma omp master" doesn't work in templates
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code, 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=24734
[Bug c++/24735] New: [gomp] "#pragma omp barrier" doesn't work in templates
The following program doesn't work correctly when compiled with -fopenmp:
==
#include
#include
#include
template void foo()
{
#pragma omp parallel
{
if (omp_get_thread_num()==0) sleep(1);
printf("ONE\n");
#pragma omp barrier
printf("TWO\n");
}
}
int main()
{
foo<0>();
return 0;
}
==
The output (with two threads) is:
ONE
TWO
ONE
TWO
If I make foo a non-template function, I get the correct output:
ONE
ONE
TWO
TWO
Maybe related to PR 24734.
--
Summary: [gomp] "#pragma omp barrier" doesn't work in templates
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code, 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=24735
[Bug c++/24734] [gomp] "#pragma omp master" doesn't work in templates
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-08 15:40:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24734
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #5 from schnetter at aei dot mpg dot de 2005-11-08 15:54 --- I would like to identify the cause of this problem. Would it help if I tracked down the patch number that caused this problem? Andrew, do you have an automated system to do that, or is someone already doing it? Otherwise I would try that with a small script. But it seems to take a long time to do that, so I wouldn't want to waste the effort. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug driver/20425] -print-search-dirs doesn't honor mutil-os/multilib settings
--- Comment #4 from bergner at vnet dot ibm dot com 2005-11-08 16:04 --- Shouldn't libtool being using -print-multi-os-directory rather than -print-search-dirs? http://www.redhat.com/archives/fedora-devel-list/2004-January/msg01027.html -- bergner at vnet dot ibm dot com changed: What|Removed |Added CC||bergner at vnet dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[Bug driver/20425] -print-search-dirs doesn't honor mutil-os/multilib settings
--- Comment #5 from schwab at suse dot de 2005-11-08 16:16 --- How do you find out where to splice the multi-os directory into the libraray path? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[Bug java/24736] New: Gcjh method inlining violates weak semantics of mingw linker
This entry is being opened as a result of discussion on the mailing list. It was discovered in 4.1.0 mainline. The root cause has existed for a very long time but the change that exposed it was commited in February 2005. This problem is almost certainly existant on cygwin builds, but this has not been verified. See discussions: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00400.html http://gcc.gnu.org/ml/java/2005-09/msg00013.html -- Summary: Gcjh method inlining violates weak semantics of mingw linker Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tj at laurenzo 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=24736
[Bug java/24736] Gcjh method inlining violates weak semantics of mingw linker
--- Comment #1 from tj at laurenzo dot org 2005-11-08 16:21 --- Created an attachment (id=10174) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10174&action=view) Patch to correct the problem for non ELF targets This patch has been applied to mainline and will be applied to the 4.0 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24736
[Bug java/24736] Gcjh method inlining violates weak semantics of mingw linker
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-08 16:22 --- I think there is a dup of this bug already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24736
[Bug java/24736] Gcjh method inlining violates weak semantics of mingw linker
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 16:25 --- *** This bug has been marked as a duplicate of 20993 *** -- 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=24736
[Bug libgcj/20993] GCC/GCJ not creating proper symbols for inline native CNI code
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-08 16:25 --- *** Bug 24736 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tj at laurenzo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20993
[Bug libgcj/20993] GCC/GCJ not creating proper symbols for inline native CNI code
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 16:26 --- Confirmed. -- 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 |2005-11-08 16:26:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20993
[Bug c++/24735] [gomp] "#pragma omp barrier" doesn't work in templates
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-08 16:27:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24735
[Bug libgcj/20993] GCC/GCJ not creating proper symbols for inline native CNI code
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-08 16:27 --- Fixed by: +2005-11-08 Terry Laurenzo <[EMAIL PROTECTED]> + + PR java/24736 + * gjavah.c (HANDLE_CODE_ATTRIBUTE): Only define for ELF Object + formats. + * gjavah.c (decompile_method): Add ATTRIBUTE_UNUSED + -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20993
[Bug tree-optimization/23382] [4.1 Regression] Does not remove the old HEAP virtual variables in clobbered
--- Comment #9 from dberlin at gcc dot gnu dot org 2005-11-08 16:34 --- Subject: Bug 23382 Author: dberlin Date: Tue Nov 8 16:34:48 2005 New Revision: 106643 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106643 Log: 2005-11-08 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/23382 * tree-ssa-alias.c (compute_may_aliases): Call delete_old_heap_vars. * tree-dfa.c (referenced_var_remove): New function. * tree-ssa.c (delete_tree_ssa): Call delete_old_heap_vars. * tree-flow.h (referenced_var_remove): Add prototype. (delete_old_heap_vars): Ditto. * tree-ssa-structalias.c (heapvars): New variable. (oldheapvars): Ditto. (get_constraint_for): Put heap vars on heapvars list. (delete_old_heap_vars): New function. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23382.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-dfa.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
[Bug tree-optimization/23382] [4.1 Regression] Does not remove the old HEAP virtual variables in clobbered
--- Comment #10 from dberlin at gcc dot gnu dot org 2005-11-08 16:36 --- Fixed -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
[Bug c++/24737] New: const bool& optimization error
When using gcc 4.0.0 or 4.0.1 on MacOS, the following code fails when
optimizations (-O1 - -O3) is turned on:
--- snip ---
bool TestFoo(const bool& trueBool) {
CFoo foo;
// bool falseBool = trueBool ? false: true;// This works!
bool falseBool = !trueBool; // This
does not work!
if (falseBool != foo.GetFalse()) {
if (!falseBool) {
// Should never be executed!
foo.DoSomething(1);
return true;
}
}
return false;
}
int main (int /*argc*/, char * const /*argv[]*/) {
bool trueBool = true;
if (TestFoo(trueBool)) {
return -1; // Error!
}
return 0;
}
--- snip ---
The code works as intended when optimizations are turned off.
It seems to be the ! operator not working with const bool&, but modifying the
code in other ways may also solve the problem. (Try putting the CFoo class in
the same module, or remove the inner if statement in TestFoo.)
--
Summary: const bool& optimization error
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fredrik dot littmarck at propellerheads dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24737
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-08 16:40 --- How did you configure gcc? From the looks of it, you are doing some thing wrong. >By the way the GNU Fortran Page - > http://gcc.gnu.org/fortran/ > still says to use anonymous CVS Yes that is a different bug and if you read the anonymous cvs page, you will see it is only taking about the web pages :). Can you give the full steps on how you configure/build GCC? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|geoffk at gcc dot gnu dot |pinskia at gcc dot gnu dot |org |org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug middle-end/24737] const bool& optimization error
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 16:43 --- I Think this has already been fixed in 4.0.2 by the patch for PR 23326. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c++ |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24737
[Bug middle-end/24737] const bool& optimization error
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-08 16:44 --- Actually on second thought, this is a dup of bug 23326. *** This bug has been marked as a duplicate of 23326 *** -- 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=24737
[Bug tree-optimization/23326] [4.0 Regression] Wrong code from forwprop
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-08 16:44 --- *** Bug 24737 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||fredrik dot littmarck at ||propellerheads dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23326
[Bug middle-end/24737] const bool& optimization error
--- Comment #3 from fredrik dot littmarck at propellerheads dot se 2005-11-08 16:45 --- Created an attachment (id=10175) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10175&action=view) Test Case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24737
[Bug middle-end/24737] const bool& optimization error
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-08 16:46 --- Note also you are using Apple's compiler and should report this to them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24737
[Bug tree-optimization/5035] Incorrectly produces '`' might be used uninitialized in this function'
--- Comment #7 from law at redhat dot com 2005-11-08 17:03 --- The SSA optimizers clean this testcase enough to no longer emit a bogus uninitialized warning. It is (of course) possible to create more complex tests which would still generate bogus uninitialized warnings. -- law at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug tree-optimization/5035] Incorrectly produces '`' might be used uninitialized in this function'
-- law at redhat dot com changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug libstdc++/24693] Deque improvements
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 17:13 --- Confirmed. -- 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 |2005-11-08 17:13:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24693
[Bug middle-end/19371] [3.4 Regression] Missing uninitialized warning with dead code (pure/const functions)
--- Comment #3 from law at redhat dot com 2005-11-08 17:18 --- No plans exist to address these issues in the 3.x series. It works as expected in GCC 4.1. -- law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|3.4.6 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19371
[Bug middle-end/20644] bogus uninitialized warning on unused variable
--- Comment #5 from law at redhat dot com 2005-11-08 17:23 --- Bogus warning no longer issued with GCC 4.1 based compilers. -- law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20644
[Bug middle-end/20644] bogus uninitialized warning on unused variable
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-08 17:25 --- (In reply to comment #5) > Bogus warning no longer issued with GCC 4.1 based compilers. Huh: gcc version 4.1.0 20051106 (experimental) ../t6.c: In function foo: ../t6.c:13: warning: j is used uninitialized in this function -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | Target Milestone|4.1.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20644
[Bug c++/19450] __thread static class members
--- Comment #4 from simon dot marshall at misys dot com 2005-11-08 17:41 --- Is there a target milestone for this? IWBI it were fixed on 3.4 as well as 4.0. (Appologies if I seem impertinent, I'm not too familiar with the way things work.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19450
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #6 from bonzini at gcc dot gnu dot org 2005-11-08 17:47 --- For now, I am trying to get the size of umf_analyze down by removing the unnecessary prototypes, beautifying the code, etc... Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug middle-end/20968] Spurious "may be used uninitialized" warning
--- Comment #4 from law at redhat dot com 2005-11-08 17:47 --- Just an interesting tidbit. This testcase exposes a much more difficult/interesting long term problem. Namely, how should we handle uninitialized warnings for variables which are exposed by optimization. ie, in this case (and probably others), we have a local variable which has had its address taken, which normally suppresses uninitialized warnings. However, inlining followed by our SSA optimizers proves that we don't need the address of the local variable. That in turn exposes the local variable and we want to be able to warn about it if its uninitialized. Similar issues probably exist for SRA optimizations. Whee fun. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968
[Bug target/24738] New: [4.0]: Message typos in i386 backend
In i386.h, there are
{ "push-args",-MASK_NO_PUSH_ARGS, \
N_("Use push instructions to save outgoing arguments") }, \
{ "no-push-args", MASK_NO_PUSH_ARGS,\
N_("Do not use push instructions to save outgoing arguments") }, \
{ "accumulate-outgoing-args", MASK_ACCUMULATE_OUTGOING_ARGS,\
N_("Use push instructions to save outgoing arguments") }, \
{ "no-accumulate-outgoing-args",-MASK_ACCUMULATE_OUTGOING_ARGS, \
N_("Do not use push instructions to save outgoing arguments") },
The messages for "accumulate-outgoing-args" and "no-accumulate-outgoing-args"
are cut-and-paste errors.
--
Summary: [4.0]: Message typos in i386 backend
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24738
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #13 from dir at lanl dot gov 2005-11-08 18:14 ---
Here is what I do -
12 9:21mkdir gfortran
13 9:21cd gfortran
14 9:25svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
15 9:56cd gcc
16 9:56configure --prefix=/Users/dir/bin --enable-languages=c,f95
17 9:57make -j 4
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/bin/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/bin/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/bin/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/bin/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d'` ; \
for mlib in $MLIBS ; do \
rm -f ${mlib}/libgcc_s.10.5.dylib || exit 1 ; \
ln -s ../libgcc_s.10.5.dylib ${mlib}/libgcc_s.10.5.dylib || exit 1 ; \
done
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/bin/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/bin/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/bin/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/bin/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d' -e 's/^/_/'` ; \
for mlib in '' $MLIBS ; do \
strip -o libgcc_s.10.4.dylib_T${mlib} \
-s ../.././gcc/config/rs6000/darwin-libgcc.10.4.ver -c -u \
libgcc_s${mlib}.1.dylib || exit 1 ; \
done
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/bin/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/bin/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/bin/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/bin/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d' -e 's/^/_/'` ; \
for mlib in '' $MLIBS ; do \
strip -o libgcc_s.10.5.dylib_T${mlib} \
-s ../.././gcc/config/rs6000/darwin-libgcc.10.5.ver -c -u \
libgcc_s${mlib}.1.dylib || exit 1 ; \
done
Could Not Open (-o) To Read
make[2]: Could Not Open (-o) To Read
*** [libgcc_s.10.4.dylib] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [libgcc_s.10.5.dylib] Error 1
rm cpp.pod gfortran.pod fsf-funding.pod gpl.pod gcc.pod gcov.pod gfdl.pod
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug fortran/24409] ICE on module name vs dummy argument name
--- Comment #6 from paulthomas2 at wanadoo dot fr 2005-11-08 18:56 --- Subject: Re: ICE on module name vs dummy argument name tobi, >--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-07 13:07 --- >(In reply to comment #3) > > >>Thank you Salvatore and Andrew. >> >>The proposed patch is about to be posted on the fortran and gcc-patches list. >>I just have a couple more minutes of testing other, completely off-the-wall >>cases before submitting. >> >> > >Did this patch ever get posted? > > What about it? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24409
[Bug java/23617] Out of memory when classpath contains jar file with zip-style comment
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-08 19:10 --- Subject: Bug 23617 Author: tromey Date: Tue Nov 8 19:10:39 2005 New Revision: 106648 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106648 Log: 2005-11-08 Wil Mahan <[EMAIL PROTECTED]> PR java/23617 * zextract.c (read_zip_archive): Fix out of memory error when reading jar files with zip-style comments. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/zextract.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23617
[Bug java/23617] Out of memory when classpath contains jar file with zip-style comment
--- Comment #7 from tromey at gcc dot gnu dot org 2005-11-08 19:11 --- Fix is on 4.0 branch and trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey 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=23617
[Bug c++/24734] [gomp] "#pragma omp master" doesn't work in templates
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-08 19:22 --- Subject: Bug 24734 Author: jakub Date: Tue Nov 8 19:22:33 2005 New Revision: 106650 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106650 Log: PR c++/24734 * pt.c (tsubst_expr): Handle OMP_MASTER and OMP_ORDERED. testsuite/ * g++.dg/gomp/tpl-master-1.C: New test. libgomp/ * testsuite/libgomp.c++/master-1.C: New test. Added: branches/gomp-20050608-branch/gcc/testsuite/g++.dg/gomp/tpl-master-1.C branches/gomp-20050608-branch/libgomp/testsuite/libgomp.c++/master-1.C Modified: branches/gomp-20050608-branch/gcc/cp/ChangeLog.gomp branches/gomp-20050608-branch/gcc/cp/pt.c branches/gomp-20050608-branch/gcc/testsuite/ChangeLog.gomp branches/gomp-20050608-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24734
[Bug java/21517] Bytecode -> native code mis-compilation
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-08 19:23 --- I agree, this looks like PR 23182. Andrew (Overholt) -- does this bug still occur for you? -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21517
[Bug c++/24735] [gomp] "#pragma omp barrier" doesn't work in templates
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-08 19:24 --- Subject: Bug 24735 Author: jakub Date: Tue Nov 8 19:24:51 2005 New Revision: 106651 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106651 Log: PR c++/24735 * semantics.c (finish_omp_barrier, finish_omp_flush): New functions. * parser.c (cp_parser_omp_barrier): Call finish_omp_barrier. (cp_parser_omp_flush): Call finish_omp_flush. * cp-tree.h (finish_omp_barrier, finish_omp_flush): New prototypes. testsuite/ * g++.dg/gomp/tpl-barrier-1.C: New test. Added: branches/gomp-20050608-branch/gcc/testsuite/g++.dg/gomp/tpl-barrier-1.C Modified: branches/gomp-20050608-branch/gcc/cp/ChangeLog.gomp branches/gomp-20050608-branch/gcc/cp/cp-tree.h branches/gomp-20050608-branch/gcc/cp/parser.c branches/gomp-20050608-branch/gcc/cp/semantics.c branches/gomp-20050608-branch/gcc/testsuite/ChangeLog.gomp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24735
[Bug c++/24734] [gomp] "#pragma omp master" doesn't work in templates
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-08 19:26 --- Fixed in CVS. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24734
[Bug c++/24735] [gomp] "#pragma omp barrier" doesn't work in templates
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-08 19:27 --- Fixed in CVS. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24735
[Bug java/21517] Bytecode -> native code mis-compilation
--- Comment #7 from overholt at redhat dot com 2005-11-08 19:31 --- (In reply to comment #6) > I agree, this looks like PR 23182. > Andrew (Overholt) -- does this bug still occur for you? No. Sorry, I should have closed this when I first realized that it was no longer occurring. Shall I close? -- overholt at redhat dot com changed: What|Removed |Added CC||overholt at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21517
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-08 19:42 --- As I asked before, can you try to build not in the src directory. Do instead: cd gcc mkdir objdir ../configure --prefix=/Users/dir/bin --enable-languages=c,f95 make -j 4 If that works then we have a regression in building in the src directory which is not a very high priority regression as building in the src directory is not recommened or that well tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug libgcj/23763] Runtime.getRuntime().exec() signalling
--- Comment #9 from tromey at gcc dot gnu dot org 2005-11-08 19:44 --- I'm handling this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-26 09:01:06 |2005-11-08 19:44:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763
[Bug libgcj/24403] --enable-java-awt=qt fails to build
--- Comment #5 from tromey at gcc dot gnu dot org 2005-11-08 20:06 --- Instead of the patch in comment #2, I think we want to simply make this loadLibrary conditional on 'Configuration.INIT_LOAD_LIBRARY'. See GtkToolkit.java for an example; FWIW this change is already in Classpath CVS. I haven't looked at the configure/Makefile additions yet. I'm sure that whatever happens here will be plenty ugly :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24403
[Bug java/21517] Bytecode -> native code mis-compilation
--- Comment #8 from tromey at gcc dot gnu dot org 2005-11-08 20:07 --- Fixed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21517
[Bug tree-optimization/23115] [4.1 Regression] -ftree-vectorize generates wrong code
--- Comment #9 from dpatel at gcc dot gnu dot org 2005-11-08 20:21 --- Subject: Bug 23115 Author: dpatel Date: Tue Nov 8 20:21:15 2005 New Revision: 106653 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106653 Log: PR tree-optimization/23115 * tree-if-conv.c (find_phi_replacement_condition): Check domninated_by relation. * gcc.dg/tree-ssa/pr23115.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23115.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23115
[Bug rtl-optimization/24408] [4.1 Regression] Invariant code no longer removed from loop when doing FDO.
--- Comment #6 from steven at gcc dot gnu dot org 2005-11-08 20:36 --- I found an extra problem with loop-invariant.c, which is that it would move expressions out of loops with calls, even if the expressions used call clobbered hard registers. I'm testing a fix for this bug now, too... -- 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-17 15:14:13 |2005-11-08 20:36:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24408
[Bug fortran/22607] Elemental character functions don't work
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-08 20:43 --- The problem seems to be return-by-reference (e.g. character) functions don't mix well with DECL_IS_PURE. Testing a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring
--- Comment #10 from tobi at gcc dot gnu dot org 2005-11-08 20:55 --- Correction: implicit types are only assigned during resolution. The issue is: why does it reject the second statement if the RHS object already exists, but not otherwise? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug libgcj/23763] Runtime.getRuntime().exec() signalling
--- Comment #10 from tromey at gcc dot gnu dot org 2005-11-08 20:59 --- Subject: Bug 23763 Author: tromey Date: Tue Nov 8 20:59:20 2005 New Revision: 106654 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106654 Log: PR libgcj/23763. From [EMAIL PROTECTED] * java/lang/natPosixProcess.cc (nativeSpawn): Unblock SIGCHLD before exec. Modified: branches/gcc-4_0-branch/libjava/ChangeLog branches/gcc-4_0-branch/libjava/java/lang/natPosixProcess.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763
[Bug libgcj/23763] Runtime.getRuntime().exec() signalling
--- Comment #11 from tromey at gcc dot gnu dot org 2005-11-08 21:00 --- Subject: Bug 23763 Author: tromey Date: Tue Nov 8 21:00:15 2005 New Revision: 106655 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106655 Log: PR libgcj/23763. From [EMAIL PROTECTED] * java/lang/natPosixProcess.cc (nativeSpawn): Unblock SIGCHLD before exec. Modified: trunk/libjava/ChangeLog trunk/libjava/java/lang/natPosixProcess.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763
[Bug libgcj/23763] Runtime.getRuntime().exec() signalling
--- Comment #12 from tromey at gcc dot gnu dot org 2005-11-08 21:01 --- Fix checked in. -- tromey 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=23763
[Bug c++/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Comment #21 from dnovillo at gcc dot gnu dot org 2005-11-08 21:09 --- Subject: Bug 23046 Author: dnovillo Date: Tue Nov 8 21:09:51 2005 New Revision: 106656 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106656 Log: 2005-11-08 James A. Morrison <[EMAIL PROTECTED]> Diego Novillo <[EMAIL PROTECTED]> PR 23046 * tree-vrp.c (register_edge_assert_for): Do not register always-false predicates. testsuite/ PR 23046 * g++.dg/tree-ssa/pr23046.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr23046.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug libgcj/24587] libgcj should set gnu.classpath.version system property
-- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-30 18:35:20 |2005-11-08 21:11:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24587
[Bug libstdc++/24712] [4.0 Regression] Accidental ABI change between 4.0.1 and 4.0.2?
--- Comment #3 from fw at deneb dot enyo dot de 2005-11-08 21:12 --- (In reply to comment #2) > I gather therefore that Debian > is building GCC passing --enable-libstdcxx-allocator=mt, something absolutely > not obvious and not trivial in its consequences. Seems to be the case: Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Does your comment mean that this configuration is strongly discouraged, or that the bug report lacked relevant information? -- fw at deneb dot enyo dot de changed: What|Removed |Added CC||fw at deneb dot enyo dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24712
[Bug c++/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Comment #22 from dnovillo at gcc dot gnu dot org 2005-11-08 21:16 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00539.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug c/24743] New: NaN or correct result after divrp with 3 FPU registers
Hello, (OS, machine and compiler info in bottom of this message). In certain sources I get a problem that a calculation with floats gives a NaN. It occurs when parens are used for the division (they are not neccessary, but it is not wrong). But when two same instructions are placed after each other there is no problem with the second one. Also when other lines are between the firs with parens and the second instruction with parens, there is no problem. The problem is unfortunately not reproducable with a short program. Still I can't reproduce the problem by means of a short program. I let three system run calculations for day's. The disassembly shows the same instructions, and here no problems at all. So I can not deliver a small program that reproduces the problem but sometimes under some conditions a NaN is the result of a calculation with normal values (we don't want high precision, and numbers are not above 5000.000) The software is also not multithreaded... I also tested with schedctl_start and stop if it has something to do with context swithing. But results where the same. Short piece of disassemby where is often goes wrong: gewenst1 = uitspit->gewenst[dosering] * batch / 100.0; <-- Works always 20e2: 8b 15 00 00 00 00 mov0x0,%edx 20e8: 8b 45 08mov0x8(%ebp),%eax 20eb: d9 84 82 6c 07 00 00flds 0x76c(%edx,%eax,4) 20f2: d8 4d f0fmuls 0xfff0(%ebp) 20f5: d9 05 78 04 00 00 flds 0x478 20fb: de f9 fdivrp %st,%st(1) 20fd: d9 9d d4 f5 ff ff fstps 0xf5d4(%ebp) gewenst2 = uitspit->gewenst[dosering] * (batch / 100.0); <-- Works NOT always, sometimes NaN!!! 2103: 8b 15 00 00 00 00 mov0x0,%edx 2109: 8b 45 08mov0x8(%ebp),%eax 210c: d9 84 82 6c 07 00 00flds 0x76c(%edx,%eax,4) 2113: d9 45 f0flds 0xfff0(%ebp) 2116: dd 05 80 04 00 00 fldl 0x480 <- opcode not in Intel manual?! 211c: de f9 fdivrp %st,%st(1) <--- opcode DE F9 belongs to fdiv 211e: de c9 fmulp %st,%st(1) 2120: d9 9d d0 f5 ff ff fstps 0xf5d0(%ebp) gewenst3 = uitspit->gewenst[dosering] * (batch / 100.0); <-- Works always 2126: 8b 15 00 00 00 00 mov0x0,%edx 212c: 8b 45 08mov0x8(%ebp),%eax 212f: d9 84 82 6c 07 00 00flds 0x76c(%edx,%eax,4) 2136: d9 45 f0flds 0xfff0(%ebp) 2139: dd 05 80 04 00 00 fldl 0x480 213f: de f9 fdivrp %st,%st(1) 2141: de c9 fmulp %st,%st(1) 2143: d9 9d cc f5 ff ff fstps 0xf5cc(%ebp) So I can desribe the problem as follows: The result of "fdivrp %st, %st1" (or fdiv) goes wrong when the FPU-stack is used (more than normal): as long as only ST(0) and ST(1) are used the results are o.k., but when ST(2) is used it goes wrong. In this calculation X = A * (B / 100.0), all 3 variables are pushed on the FPU-stack. The result is "NaN". But only the first time that this construction is used in this source! ... Is gcc producing wrong assemby? Since fdivrp is fdiv when you look at the opcode. Also the opcode of fldl is not in the Intel manual... Or is the disassember (gobjdump) wrong? When the 100.0 is used via a float, the code is different and there is no fldl used but only flds. We don't want to rewrite our complete application of roughly 300.000 lines. So it would be nice if someone knows where the problem is. Sorry if bug report not quite what's expected. But after three weeks working on this problem this is the best I can do, and hope that someone can say something wise about this. Thanks in advance. Best Regards, Stefan Raaijmakers We use Advantech hardware, with Intel Pentium 4 2.8 GHz Celeron with Solaris 10 x86 (32bit) installed. gcc -v save-temps: [EMAIL PROTECTED] */packages/dos 77 : make Checking dependencies, please wait... mdept - Dependency DosUitspit.c newer than ./DosUitspit.o `DosDiv.o' is up to date. `DosLib.o' is up to date. cc -g -Wcast-align -v save-temps -DNO_ANSI -I../../include -I/usr/pm_tools/inclu de -c DosUitspit.c cc: save-temps: No such file or directory Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix =/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --w ithout-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) /usr/sfw/libexec/gcc/i386-pc-solaris2.10/3.4.3/cc1 -quiet -v -I../../include -I /usr/pm_tools/include -DNO_ANSI DosUitspit.c -quiet -dumpbase DosUitspit.c -auxb ase DosUitspit -g -Wcast
[Bug libgcj/23758] java::lang::ConcreteProcess::nativeSpawn unsafe
--- Comment #2 from daney at gcc dot gnu dot org 2005-11-08 21:20 --- Could someone elaborate? If the child is killed, it is dead and it did not matter anyhow. The child is not going to be getting random async signals. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23758
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #3 from sje at cup dot hp dot com 2005-11-08 21:22 --- I am not convinced that this is a bug. Was there an intentional change between 3.4.* and 4.0 that made -shared imply -shared-libgcc? I can't find one but it seems like this might have happened, that in 3.4 (with C) -shared does not imply -shared-libgcc but in 4.0 it does. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24743] NaN or correct result after divrp with 3 FPU registers
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 21:23 --- Do you have a small source code which exposes the issue here? (Note I saw "So I can not deliver a small program that reproduces the problem " but we really cannot do anything about it if there is not a testcase) Another thing is that you are using a GCC provided by Sun/Codesourcery and we (FSF) really don't support that version of GCC. You really should had filed a bug report to them first. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24743
[Bug target/24738] [4.0 only]: help message typos in i386 backend
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 21:25 --- Only on the 4.0 branch: maccumulate-outgoing-args Target Report Mask(ACCUMULATE_OUTGOING_ARGS) Reserve space for outgoing arguments in the function prologue -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0]: Message typos in i386|[4.0 only]: help message |backend |typos in i386 backend Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24738
