--- 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
--- 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
--- 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=gccview=revrev=106634
Log:
PR c++/21123
* cp/method.c (use_thunk): Use
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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:
+++ 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
--- 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,
--
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
--- 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=10173action=view)
Patch to fix the ice
This patch fixes the failure for me, but...
--
--- 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.
--
--- 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
--- 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)
--- 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
--- 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
--- 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
;;
--- 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
--- 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
--
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
--- 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 =
--- 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 bits/atomic_word.h instead of
bits/atomicity.h in config/cpu/*/atomicity.h for the supported arch
--- 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:
--- 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
--- 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,
--- 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
--- 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
--- 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
The following program doesn't work correctly when compiled with -fopenmp:
==
#includecstdio
templateint void foo()
{
#pragma omp parallel
{
printf(ALL\n);
#pragma omp master
printf(MASTER\n);
}
}
int main()
{
foo0();
return
The following program doesn't work correctly when compiled with -fopenmp:
==
#includecstdio
#includeomp.h
#includeunistd.h
templateint void foo()
{
#pragma omp parallel
{
if (omp_get_thread_num()==0) sleep(1);
printf(ONE\n);
#pragma omp
--
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
--- 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?
--- 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:
--- 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
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
--- 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=10174action=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
--- 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
--- 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
--- 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
--- 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
--
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
--- 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
--- 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=gccview=revrev=106643
Log:
2005-11-08 Daniel Berlin [EMAIL PROTECTED]
Fix PR
--- 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
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;
--- 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
--- 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
--- 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
--- 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
--- 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=10175action=view)
Test Case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24737
--- 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
--- 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
--
law at redhat dot com changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
--- 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
--- 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
--- 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
--- 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
--- 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.)
--
--- 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
--- 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
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
--- 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
--- 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
--- 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=gccview=revrev=106648
Log:
2005-11-08 Wil Mahan [EMAIL PROTECTED]
PR java/23617
--- 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
--- 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=gccview=revrev=106650
Log:
PR c++/24734
* pt.c (tsubst_expr): Handle
--- 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
--- 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=gccview=revrev=106651
Log:
PR c++/24735
* semantics.c (finish_omp_barrier,
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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.
--- 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
--- 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=gccview=revrev=106653
Log:
PR tree-optimization/23115
* tree-if-conv.c
--- 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...
--- 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
--- 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?
--
--- 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=gccview=revrev=106654
Log:
PR libgcj/23763. From [EMAIL PROTECTED]
*
--- 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=gccview=revrev=106655
Log:
PR libgcj/23763. From [EMAIL PROTECTED]
*
--- 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
--- 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=gccview=revrev=106656
Log:
2005-11-08 James A. Morrison [EMAIL PROTECTED]
--
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
--- 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:
--- 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
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
--- 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
--- 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)
--- 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)
--- 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:
1 - 100 of 161 matches
Mail list logo
