--- Comment #2 from hbd_bugreports at earthlink dot net 2006-04-25 22:07
---
Subject: Re: C++ class object destructors are not called
for static class objects in a shared library when dlclose is called.
So You are telling me this is not a gcc problem but a limitation in
CYGWIN.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-25 22:14 ---
(In reply to comment #2)
> Subject: Re: C++ class object destructors are not called
> for static class objects in a shared library when dlclose is called.
> So You are telling me this is not a gcc problem but a
--- Comment #5 from pr2345 at gmail dot com 2006-04-25 23:29 ---
The man page/online manual also needs a small clarification.
It only mentions the libmudflap library and not libmudflapth. I assume
a multithreaded program should link with -lmudflapth instead of -lmudflap?
Should I crea
--- Comment #4 from hbd_bugreports at earthlink dot net 2006-04-25 23:46
---
Subject: Re: C++ class object destructors are not called
for static class objects in a shared library when dlclose is called.
pinskia at gcc dot gnu dot org wrote:
>--- Comment #3 from pinskia at gcc do
--- Comment #2 from janis at gcc dot gnu dot org 2006-04-25 23:49 ---
The patch that introduced this failure also causes the same ICE in several SPEC
CPU2000 programs on powerpc64-linux for "-O2 -fmodulo-sched" with either -m32
or -m64. I haven't tried the patch that was supposed to fix
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-04-26 00:56
---
My experiance has been that if you have gfortran installed from a distribution
such as Fedora and you build your own later version of gfortran from source and
you do not configure the later version to install in i
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-26 02:13 ---
Oh, if you had put how you involved gcc in the comments instead of in build
script, I would have seen what the problem is.
Anyways this is a dup of bug 19664.
The problem is the libstdc++'s headers don't have push
--- Comment #94 from pinskia at gcc dot gnu dot org 2006-04-26 02:13
---
*** Bug 26846 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
Test code:
long double x = __builtin_infl();
int main() {
int r = x == __builtin_infl();
return r ? 0 : 1;
}
Commands to reproduce:
gcc -mlong-double-128 tc.c
./a.out && echo ok || echo fail
No problem with -mlong-double-64.
Cause:
GCC first transforms (x ==
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-26 02:27 ---
This works in the mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27321
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-26 02:40 ---
Did I mention this fails on powerpc-darwin?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21391
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-26 02:44 ---
*** This bug has been marked as a duplicate of 10894 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-26 02:44 ---
*** Bug 27280 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from sayle at gcc dot gnu dot org 2006-04-26 03:21 ---
Subject: Bug 26961
Author: sayle
Date: Wed Apr 26 03:20:56 2006
New Revision: 113266
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113266
Log:
PR target/26961
* fold-const.c (fold): When conv
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-04-26 04:10
---
I am not sure (emphasis on not sure) I agree with this. But I can explain what
it is doing. It is correctly printing out the letter 'n' then its looking for
the first data item and finds the integer in the list,
It is gcc 4.1.0, --target=arm-elf compiled on an Intel platform and
GNU/Linux.
The following construct:
void *p;
((char *)p)++;
makes the compiler to issue an error message, namely
"invalid lvalue in increment"
The ((char *)p) construct is perfectly valid object, a char pointer which
c
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de
2006-04-26 06:22 ---
Subject: Re: gfortran: Warn/abort when format in write
does not fit passed arguments
> I wonder if this is a case of illegal code. Intel errors on "infinite
> format".
Well, current g95, ifort
--- Comment #6 from Eric dot Doenges at betty-tv dot com 2006-04-26 06:26
---
Unfortunately, removing the __asm__ ("r0") from __r0 does not circumvent the
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
101 - 118 of 118 matches
Mail list logo
