--- Comment #17 from eyal at geomage dot com 2008-02-08 08:58 ---
Using malloc instead of new does generate better code and improves performance
slightly for me, admittedly not as much as we would like; the kernel becomes:
(using only -O3 -S -m64 -maltivec)
.L29:
lvx 13,7,9
--- Comment #15 from zaks at il dot ibm dot com 2008-02-08 08:49 ---
(In reply to comment #5)
(In reply to comment #3)
I think this is a dup of another bug I filed with respect of the builtin
operator new that getting the malloc attribute.
Are you refering to using malloc instead
--- Comment #16 from eyal at geomage dot com 2008-02-08 08:55 ---
Thanks a lot Ira, I appriciate it.
If you need the full test code with .vect file and makefiles,please let me
know.
thanks,
eyal
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35117
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2008-02-08 08:58
---
(In reply to comment #19)
I would not mind seeing a threaded example where
this could be tested and that confirms we need to lock internal units. :)
Me too :) I think I got confused between locking the
--- Comment #6 from manu at gcc dot gnu dot org 2008-02-08 09:01 ---
(In reply to comment #5)
As i know C++ doesn't support VLA. Please update me if i m wrong.
That is why it is an extension. There are many things that GCC supports and ISO
C++ doesn't. Read the GCC's manual for
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-08 11:26 ---
*** This bug has been marked as a duplicate of 35073 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-08 11:24 ---
works with -O3 (unrolled loop) on trunk, fails with 2.95, 3.3, 4.1 and 4.2 as
well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from markus dot heichel at comsoft dot de 2008-02-08 11:27
---
The complete output is:
gcc -c -O adr.adb
adr.adb:19:04: warning: variable A is read but never assigned
adr.adb: In function 'ADR':
adr.adb:5: error: expected an SSA_NAME object
adr.adb:5: error: in
--- Comment #25 from belyshev at depni dot sinp dot msu dot ru 2008-02-08
11:22 ---
Fixed.
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #2 from markus dot heichel at comsoft dot de 2008-02-08 11:16
---
The exception is:
TYPES.UNRECOVERABLE_ERROR : comperr.adb:398
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-08 11:11 ---
What UNRECOVERABLE_ERROR?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The example below raises an UNRECOVERABLE_ERROR when compiled with
optimization:
gcc -c -O adr.adb
This seems to be a regression in snapshot 4.3.0-20080201. It is working in
4.3.0-20080111 and older releases like 4.2.3.
adr.adb
pragma
class T
{
public:
static const int STATIC_MEMBER_A = 1;
static const int STATIC_MEMBER_B = 2;
T(int x);
private:
int t;
};
T::T(int x): t(x 0? STATIC_MEMBER_A: STATIC_MEMBER_B) {}
int main() {}
Error message:
/tmp/cc0UEe2g.o: In function `T::T(int)':
--- Comment #25 from hubicka at gcc dot gnu dot org 2008-02-08 15:39
---
-fno-tree-dominator-opts -fno-tree-copyrename solves the coalescing problem
(name is introduced by second, the actual problematic pattern by first pass),
saving roughly 1s at both -O2 and 2s at -O3, -O3 is still
--- Comment #24 from hubicka at gcc dot gnu dot org 2008-02-08 15:11
---
Hi,
the tonight runs with continue heuristics shows again improvements on 64bit
scores , but degradation on 32bit scores. Looking into the loop, the real
trouble seems to be that the main loop has 6 loop carried
The following program:
//
#includeiostream
#includelist
class sample
{
public:
double criterium;
sample(double _criterium):criterium(_criterium) {};
};
int main(){
std::listsample samples;
samples.push_back(sample(1.));
double tmp=0.;
--- Comment #19 from ubizjak at gmail dot com 2008-02-08 14:21 ---
The core of the problem is, that for profiled bootstrap, the call to
normalize() from do_multiply() is simply gone. Gone in the sense, that
normalize() is neither inlined at the call site, neither is called in
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2008-02-08 14:26
---
Reply to comment #23. With external units we have a treap structure which
holds pointers to the unit structures so that we reuse them as needed The
treap is searched first for an existing unit and returns that
--- Comment #1 from tim at klingt dot org 2008-02-08 14:01 ---
*** This bug has been marked as a duplicate of 35138 ***
--
tim at klingt dot org changed:
What|Removed |Added
--- Comment #4 from alexandre dot nunes at gmail dot com 2008-02-08 16:51
---
I suggest closing this unless reproductible on gcc 4.3.x, since at least
vanilla arm-elf-gcc 4.2.2 is correct:
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args
--- Comment #28 from jvdelisle at gcc dot gnu dot org 2008-02-08 16:33
---
pthread_mutex_destroy() fixes the problem on Cygwin including the case in
Comment #26. It regression tests OK on Linux-x86-64. I am now just reviewing
to make sure we don't try to lock after a destroy, which
--- Comment #27 from jvdelisle at gcc dot gnu dot org 2008-02-08 14:58
---
OK OK I believe you. :) What the heck was I looking at before? :) I am just
working up the closehandle patch now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
--- Comment #29 from hubicka at gcc dot gnu dot org 2008-02-08 14:54
---
Hi,
tonight results from Haydn shows 32bit scores with the loop-invariant hack
disabled.
http://www.suse.de/~gcctest/SPEC/CFP/sb-haydn-head-64-32o-32bit/index.html
There are no off noise speedups though I must
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-08 16:07 ---
This is possibly a dup of one of the various alias problems of gcc 4.1.
-fno-strict-aliasing is a workaround.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
On ARM, the following C code:
void whatever(const char *pqp)
{
volatile unsigned int *uart_thr = (typeof(uart_thr))0xE000C000;
unsigned int ch;
while((ch = *pqp++))
*uart_thr = ch;
}
Generates this assembler output (by means of -mcpu=arm7tdmi -O2):
whatever:
@ args = 0,
--- Comment #1 from steven at gcc dot gnu dot org 2008-02-08 17:27 ---
See PR31360. May be fixed for GCC 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-08 18:37 ---
Also using a volatile pointer may prevent optimization, so don't use it if
not strictly needed (or at least don't expect optimized code).
Can you try 4.3 as suggested?
--
rguenth at gcc dot gnu dot org changed:
--- Comment #5 from gilad at odinak dot com 2008-02-08 18:30 ---
Could you please tell me which standard does not allow it, and if a previous
standard does allow it.
It is the only way I found to avoid the memory allocator in my code from
colliding with the memory allocator of a library
--- Comment #3 from ghazi at gcc dot gnu dot org 2008-02-08 18:21 ---
Below is what I get from gdb with mainline on x86_64-unknown-linux-gnu. We're
aborting because the constructor for Baz's struct bar member isn't called.
(gdb) run
Starting program:
--- Comment #1 from basti at fkp dot tu-darmstadt dot de 2008-02-08 15:28
---
replacing all doubles types with size_t or int does change nothing.
the bug still exists.
--
basti at fkp dot tu-darmstadt dot de changed:
What|Removed |Added
--- Comment #20 from ubizjak at gmail dot com 2008-02-08 20:15 ---
(In reply to comment #19)
So, what upsets gcc's inliner/profiler/whatever to drop the call?
Correction, normalize() gets inlined together with lshift_significand(), but
there is something wrong with inlined version.
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-02-08 20:47
---
I will take this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from ubizjak at gmail dot com 2008-02-08 20:25 ---
Following patch that forces inlining of normalize breaks normal bootstrap in
exactly the same way, so it looks that there is something wrong with inliner.
Index: real.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-08 20:14 ---
*** Bug 27247 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rsandifo at gcc dot gnu dot org 2008-02-08 19:11
---
Patch applied. Thanks to Richard G. for the review.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rsandifo at gcc dot gnu dot org 2008-02-08 19:11
---
Subject: Bug 35051
Author: rsandifo
Date: Fri Feb 8 19:10:25 2008
New Revision: 132188
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132188
Log:
gcc/
PR bootstrap/35051
* double-int.h:
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2008-02-08 18:10
---
Created an attachment (id=15118)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15118action=view)
Proposed patch, needs testing on mingw
Here is the patch. I have tested this on Cygwin, but not mingw. It
--- Comment #3 from basti at fkp dot tu-darmstadt dot de 2008-02-08 16:32
---
One can even omit the helper class sample and directly use a listsize_t ,
bug is still there!!!
the above mentioned work-around with -fno-strict-aliasing works,
but still...
makes my kinda nervous about
--- Comment #22 from ubizjak at gmail dot com 2008-02-08 21:17 ---
Created an attachment (id=15119)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15119action=view)
Executable test that shows the failure.
This is the test that shows the inliner failure:
[EMAIL PROTECTED] ~]$ gcc
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-02-08 21:29
---
Now that we have a testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-02-08 21:40
---
How does this look :) I have a couple of other test prints in there.
$ gfc pr35132.f90
$ ./a.out
1st: 123456
2nd: abcdef
123456
ASDFef
At line 26 of file pr35132.f90 (unit = 20, file = 'foo.txt')
Fortran
--- Comment #3 from ghazi at gcc dot gnu dot org 2008-02-08 17:58 ---
Below is the info from gdb with mainline on x86_64-linux-gnu. We're aborting
because the encoding for BOOL* doesn't match the expected value.
(gdb) run
Starting program:
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-02-08 20:48
---
(In reply to comment #2)
Also using a volatile pointer may prevent optimization, so don't use it if
not strictly needed (or at least don't expect optimized code).
Sorry for lefting it in there: Tought
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-02-08 11:23
---
The exception is:
TYPES.UNRECOVERABLE_ERROR : comperr.adb:398
Please post full the error message.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-08 11:26 ---
*** Bug 35128 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-08 22:38 ---
With gcc 4.3:
_Z3fooR1XRKS_:
.LFB124:
subl$20, %esp
.LCFI0:
movl24(%esp), %eax
movl28(%esp), %edx
movq(%eax), %mm0
pxor(%edx), %mm0
movq%mm0,
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #24 from jpr at csc dot fi 2008-02-08 12:12 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
This might be desirable for other reasons, but it will not fix the problem
completely.
Yeah well, the easy way out here would be to include
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-08 22:50 ---
4.2 works for me. This is a middle-end/tree-optimization problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from jvdelisle at verizon dot net 2008-02-08 23:00 ---
Subject: Re: [Regression wrt g77] I/O leaks
handles/memory on Windows XP
mikko dot lyly at csc dot fi wrote:
--- Comment #30 from mikko dot lyly at csc dot fi 2008-02-08 22:31
---
I would appreciate
--- Comment #1 from joel at gcc dot gnu dot org 2008-02-08 23:01 ---
Created an attachment (id=15120)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15120action=view)
ACATS Log for powerpc-rtems4.9 SVN trunk rev 132186
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
g++-4.3 rejects the following code:
namespace n1 {
struct foo{};
}
namespace n2 {
struct foo{};
}
using namespace n1;
using namespace n2;
template typename tp
int run(tp const t) {
return t.foo;
}
struct bar {
int foo;
};
int main() {
bar b;
run(b);
}
the error message is:
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-08 16:11 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
g++-4.3 rejects the following code:
namespace n1 {
struct foo{};
}
namespace n2 {
struct foo{};
}
using namespace n1;
using namespace n2;
template typename tp
int run(tp const t) {
return t.foo;
}
struct bar {
int foo;
};
int main() {
bar b;
run(b);
}
the error message is:
--- Comment #9 from ghazi at gcc dot gnu dot org 2008-02-08 18:05 ---
I get the padding struct error on all three active branches (4.1, 4.2,
trunk):
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00539.html
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00540.html
--- Comment #1 from tim at klingt dot org 2008-02-08 14:01 ---
*** Bug 35139 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35138
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-08 22:15 ---
This is worse than PR32384, so either we have a fix for it or we should revert
the fix for PR32384 before 4.3.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2008-02-08 17:58 ---
Caused by my http://gcc.gnu.org/viewcvs?root=gccview=revrev=129836
This is during tentative parse, so I guess the errors should be suppressed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35138
--- Comment #4 from burnus at gcc dot gnu dot org 2008-02-08 17:54 ---
One big problem which prevents omitting the -traditional-cpp is that comments
are not ignored. Another example of this is
! /*
which is regarded as the beginning of a C/C++ comment. Thus we should add two
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-08 16:12 ---
You need to provide a definition for the static data members outside of the
class body. Like
const int T::STATIC_MEMBER_A;
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35144
--- Comment #6 from steven at gcc dot gnu dot org 2008-02-08 23:05 ---
Is it possible to create an equivalent C test case (e.g. from the initial
GIMPLE dumps before the ICE)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
--- Comment #2 from joel at gcc dot gnu dot org 2008-02-08 23:04 ---
Created an attachment (id=15121)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15121action=view)
RTEM SVN Trunk Ada Patch
Unfortunately, I have an outstanding patch that did not get reviewed in time
for inclusion
--- Comment #3 from joel at gcc dot gnu dot org 2008-02-08 23:06 ---
Created an attachment (id=15122)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15122action=view)
Same patch but against 4.2.3
Just as a sanity measure. This is the same patch but against 4.2.3. 4.2.3
works
struct A
{
int baz ();
};
typedef int (A::*P) ();
struct B
{
B ();
int foo (P x, int y = 0);
};
struct C
{
typedef int (B::*Q) (P, int);
void bar (Q x) { c = x; }
Q c;
};
extern C c;
B::B ()
{
c.bar ((C::Q) B::foo);
}
ICEs with:
internal compiler error: in generate_element_copy,
--- Comment #4 from laurent at guerby dot net 2008-02-08 23:15 ---
I looked at several FAIL and it looks like exception are raised as expected by
the tests but they are not catched.
What doesn't work seem to be exception propagation.
I think I gave you a little Ada exception test a
--- Comment #5 from joel at gcc dot gnu dot org 2008-02-08 23:19 ---
Created an attachment (id=15123)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15123action=view)
Laurent Guerby's exception test
With SVN, the output is
Raising Constraint_Error
raised CONSTRAINT_ERROR :
4.2.3: PASSED: 2309 FAILED3
Trunk: PASSED: 1623 FAILED 689
4.2.3 only failed c380004, c761007, and c953002.
I am posting the full log for the SVN trunk as an attachment. Hopefully
someone can spot a pattern and we can start to file appropriate PRs. This is a
big regression.
--
--- Comment #26 from fxcoudert at gcc dot gnu dot org 2008-02-08 14:39
---
(In reply to comment #25)
With external units we have a treap structure which
holds pointers to the unit structures so that we reuse them as needed.
I haven't looked at the source code, but I can assure you
--- Short description
Use of xmm intrinsics generates useless code: mmx registers seem to be written
back to the stack systematicaly, even when this is not needed. Maybe it's
related to already reported bug about MMX.
--- GCC version (4.2.1, prebuild version for mingw)
Bugs was seen at least
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-08 22:20 ---
Not with this testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35140
Thread model: win32
gcc version 4.3.0 20080208 (experimental) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
--- Comment #4 from bangerth at dealii dot org 2008-02-08 21:59 ---
Can this be reproduced with gcc 4.2.x or current mainline?
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #4 from bangerth at dealii dot org 2008-02-08 21:51 ---
This should get higher priority than P3...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35138
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-02-08 20:14 ---
This is a dup of bug 23681. I Need to add support to libobjc for this but I
have not yet.
*** This bug has been marked as a duplicate of 23681 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #6 from schwab at suse dot de 2008-02-09 00:20 ---
As soon as stdio.h is included fprintf becomes reserved as a function like
macro. That is independent of _FORTIFY_SOURCE, and is true for every function
defined in the standard C libaray.
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-02-09 00:21 ---
(In reply to comment #5)
The code is not buggy. printf and fprintf are not reserved words, and
occupy a separate namespace with regard to the structure name and any
global function names.
No they can be
--- Comment #5 from graeme at argyllcms dot com 2008-02-09 00:04 ---
The code is not buggy. printf and fprintf are not reserved words, and
occupy a separate namespace with regard to the structure name and any
global function names. Because macros are a pre-process and don't understand
--- Comment #19 from danglin at gcc dot gnu dot org 2008-02-09 00:31
---
Subject: Bug 34627
Author: danglin
Date: Sat Feb 9 00:30:13 2008
New Revision: 132193
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132193
Log:
PR middle-end/34627
combine.c
--- Comment #6 from manu at gcc dot gnu dot org 2008-02-09 00:23 ---
(In reply to comment #5)
Could you please tell me which standard does not allow it, and if a previous
standard does allow it.
The only thing I can tell you is that in our codebase the code is commented as:
/*
--- Comment #20 from danglin at gcc dot gnu dot org 2008-02-09 00:35
---
Subject: Bug 34627
Author: danglin
Date: Sat Feb 9 00:34:19 2008
New Revision: 132194
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132194
Log:
PR middle-end/34627
combine.c
--- Comment #21 from danglin at gcc dot gnu dot org 2008-02-09 00:37
---
Subject: Bug 34627
Author: danglin
Date: Sat Feb 9 00:37:00 2008
New Revision: 132195
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132195
Log:
PR middle-end/34627
combine.c
--- Comment #22 from danglin at gcc dot gnu dot org 2008-02-09 00:39
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
OS environment: Latest Fedora Rawhide nightly tree.
cpp-4.3.0-0.7.i386
libgcc-4.3.0-0.7.i386
libstdc++-4.3.0-0.7.i386
gcc-4.3.0-0.7.i386
gcc-c++-4.3.0-0.7.i386
Attempting to build SeaMonkey 1.1.8, which uses the same tree as stable Firefox
2.0.0.x. (The failure is in the early core components of
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-09 01:09 ---
This seriously does not sounds like a GCC bug. Note for other people who are
playing at home:
nsXPCOMObsolete.o:(.data.rel.ro+0x18): undefined reference to
`nsFileSpecImpl::Create(nsISupports*, nsID const,
--- Comment #8 from graeme at argyllcms dot com 2008-02-09 01:37 ---
I've read this section of the standard, and don't see that
it is applicable. Any function declared in a header may be additionally
implemented as a function-like macro defined in the header, so if a
library function is
gcc -v:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-02-09 01:41 ---
(In reply to comment #8)
I've read this section of the standard, and don't see that
it is applicable. Any function declared in a header may be additionally
implemented as a function-like macro defined in the
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-09 01:45 ---
This works fine on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jason at gcc dot gnu dot org 2008-02-09 03:40 ---
Subject: Bug 35116
Author: jason
Date: Sat Feb 9 03:40:14 2008
New Revision: 132197
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132197
Log:
PR c++/35116
* tree.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-09 03:55 ---
x ={v} x.2;
struct
{
B:: * __pfn;
int __delta;
} x;
struct
{
B:: * __pfn;
int __delta;
} x.2;
I think this is either an inlining issue or a C++ front-end issue (well I
thinking it is
--- Comment #7 from gilad at odinak dot com 2008-02-09 04:18 ---
Thanks by the way there's a typo in the spec locator it is not static but
sometimes std and sometimes stc see here for the original suggestion to change
the behavior
--- Comment #2 from kengert at redhat dot com 2008-02-09 05:32 ---
It appears there is some sort of visibility issue, I should have had this idea
earlier because of the hidden symbol message shown in the build output.
The mozilla build system has a configuration option to disable the
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-09 05:44 ---
Is nsDirectoryIteratorImpl::Create defined anywhere in the sources of the
shared library? How is nsDirectoryIteratorImpl declared, does it have a
visibility hidden on it? If the first one is false and the second
--- Comment #3 from pault at gcc dot gnu dot org 2008-02-09 06:14 ---
(In reply to comment #2
FX,
I think that your logic is impeccable - I am sure that is the correct fix.
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35009
--- Comment #32 from jpr at csc dot fi 2008-02-09 06:46 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
hi,
the patch looks good to me, although from the clarity point of view and
to avoid potential problem with other thread models, i'd go all the way
96 matches
Mail list logo
