--- Additional Comments From info at yourkit dot com 2005-05-02 06:59
---
First of all, thank you all for the suggestions.
libstdc++'s configure contains the docs for --with-pic:
I'm sorry, I'm not a gcc configuration guru :), and all that I was doing was
building gcc via its
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
07:15 ---
I'd be happy to try if you'd tell me where to switch this option
g++ -m64 -fPIC q.cpp -shared -mimpure-text -o libq.so
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
--- Additional Comments From info at yourkit dot com 2005-05-02 07:19
---
I'd be happy to try if you'd tell me where to switch this option
g++ -m64 -fPIC q.cpp -shared -mimpure-text -o libq.so
It doesn't help -- the same problem
--
--- Additional Comments From info at yourkit dot com 2005-05-02 07:23
---
Eric, maybe you can tell me more how/where to apply this --with-pic option?
I was googling myself, but found nothing about this option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
07:27 ---
It doesn't help -- the same problem
OK. To further confirm the diagnostic, you could run readelf -r on libq.so and
find out where this R_SPARC_WDISP30 relocation comes from.
--
--- Additional Comments From info at yourkit dot com 2005-05-02 07:33
---
readelf -r libq.so | grep R_SPARC_WDISP30gives the following:
a73c 004f0007 R_SPARC_WDISP30 abort + 0
a764 004f0007 R_SPARC_WDISP30 abort + 0
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-02
07:42 ---
cabs issue is still here. Will look into it when I have time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19481
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-02
07:52 ---
The problem is that we're using mmap on the preconnected units, which confuses
subsequent C I/O on the file.
Patch here: http://gcc.gnu.org/ml/fortran/2005-05/msg8.html
Will be committed in source
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
07:57 ---
readelf -r libq.so | grep R_SPARC_WDISP30gives the following:
OK, the fundamental problem is that you're trying to build shared libraries with
a compiler configured with --disable-shared. That's
--- Additional Comments From giovannibajo at libero dot it 2005-05-02
08:04 ---
Please open a new bugreport for this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15877
--- Additional Comments From info at yourkit dot com 2005-05-02 08:15
---
OK, the fundamental problem is that you're trying to build shared libraries
with
a compiler configured with --disable-shared. That's not really intended (and
might cause problems for exception propagation in
gcc generates suboptimal i386 block copy code, like this:
movl$9, %ecx
rep
movsb
or this:
movl$2, %ecx
rep
movsl
movsw
Such short copies can be done with few movsl's instead.
Patch is attached. Note that I am not familiar with gcc
--- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa
dot ua 2005-05-02 09:00 ---
Created an attachment (id=8790)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8790action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21329
--- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa
dot ua 2005-05-02 09:02 ---
Created an attachment (id=8791)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8791action=view)
patch against 4.0.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21329
--- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa
dot ua 2005-05-02 09:04 ---
Comparison between old and new code (-O2):
--- tO2.s Mon May 2 11:49:24 2005
+++ tO2-new.s Mon May 2 11:50:03 2005
@@ -35,8 +35,7 @@
movl$t21, %edi
movl
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
09:05 ---
We must link our .so statically with all the gcc stuff to make sure it runs on
every Solaris. Shipping libstd++.so with our shared library is not very
suitable for us, because it makes product download
extern int baz (int);
int bar (void *);
void foo (void *w, char *x, bool y, bool z)
{
char c = bar (w);
int i = 0;
while (1)
{
x[i++] = c;
c = bar (w);
if (y c == '\'')
break;
if (z c == '\')
break;
if (!y !z !baz (c))
break;
--- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa
dot ua 2005-05-02 09:10 ---
BTW, see above comment: gcc -O2 allocated 24 bytes on stack
and never uset them. ?!
Now, unoptimized compilation comparison:
--- t.s Mon May 2 11:41:20 2005
+++ t-new.s Mon May
--- Additional Comments From info at yourkit dot com 2005-05-02 09:25
---
5 MB uncompressed for 32-bit, 6 MB uncompressed for 64-bit!
Of course it's not a show stopper, but given 2-3M total packed size of the
distribution, we'd prefer not to double it. Furthermore, the approach always
--- Additional Comments From info at yourkit dot com 2005-05-02 09:46
---
Adding --with-pic to the command line of gcc's configure helped.
Thanks a lot, Eric!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
09:54 ---
There's absolutely nothing illegal in static linking with a shared library
other libraries that it uses. The intention is to make resulting shared
library loadable on every target machine with no
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
09:58 ---
Adding --with-pic to the command line of gcc's configure helped.
Great, but now you know my position on this mess. :-)
Thanks a lot, Eric!
Andrew deserves them too.
--
What|Removed
On ia64:gcc -O ~/bug.c
On powerpc: gcc -O -m64 ~/bug.c
The test case hits abort.
(This case came up when trying to compile GNU MP with gcc 4.
I have yet to find a platform where gcc 4 works properly.)
This is bug.c:
#include stdlib.h
int bar (void)
{ return -1; }
unsigned long
foo ()
{
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-02
10:06 ---
Similar regressions for me (gfortran version 4.1.0 20050502 on i386-linux). Only
present at -O2 and -O3. Still very good results with -O0 and -O1 (same as
comment #47).
I understand there's heavy work
4.1.0 20050502 (experimental) seems have a problem with optimization.
The for loop in the else clause in the main doesn't execute the loop body.
% cat t.c
extern int printf (__const char *__restrict __format, ...);
int f()
{
return -2;
}
int main(int argc, char **argv)
{
int c = f
--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-02 10:38
---
Created an attachment (id=8792)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8792action=view)
Patch I'm about to test.
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-02
11:03 ---
The snippet from comment #5 crashes in gcc 3.4.3.
Really fixed in 3.4.4.
--
What|Removed |Added
--- Additional Comments From info at yourkit dot com 2005-05-02 11:10
---
Thanks a lot, Eric!
Andrew deserves them too.
No doubt :) I'm sorry.
And, again, not using a shared libgcc on
Solaris means that exceptions cannot be propagated across shared libraries;
that's why g++
--
What|Removed |Added
Known to work|3.3 3.4.0 3.4.4 4.0.0 4.1.0 |3.3 3.4.0 3.4.1 3.4.2 3.4.4
||4.0.0 4.1.0
Target
I don't have the machines to test this on, but I think
there is a chance of an alignment issue with in_pack / in_unpack.
Look at the following program:
program main
complex a(5),b(5)
equivalence(a(1),r(1)),(b(1),r(12))
real r(100)
a = (1.0, -1.0)
b = (2.0, -2.0)
call foo(a(5:1:-1),5)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
11:40 ---
Confirmed, another bug (PR 21293 is the other) fixed on the mainline by:
2005-03-14 Zdenek Dvorak [EMAIL PROTECTED]
* tree-cfg.c (find_taken_edge_cond_expr): Use zero_p instead of
I am sending this to the g++ bug list on the recommendation of
Gabriel Dos Reis. From what little I've read in the g++
documentation, I'm not convinced that the authors of the g++
library intend for it to be supported, although Posix would seem
to require it.
For the record, the statement in
The actual snapshot gcc-4.1-20050501 fails to bootstrap if -O3 -ftree-vectorize
is given as CFLAGS.
Michael Cieslinski
--
Summary: bootstrap fails with CFLAGS=-O3 -ftree-vectorize
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
11:54 ---
Is this a duplicate of bug 10350?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Additional Comments From micis at gmx dot de 2005-05-02 11:58 ---
The patch given in comment #5 seems to be included in gcc400 and in mainline.
I think this PR should be closed.
Michael Cieslinski
--
What|Removed |Added
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-02
11:58 ---
Filling allocated memory with garbage is even more fun,
this causes around 3000 testsuite failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21324
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
11:59 ---
Confirmed, this is a VRP problem.
--
What|Removed |Added
CC|
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20122
--- Additional Comments From pcarlini at suse dot de 2005-05-02 12:02
---
Two quick comments: 1- I'd like to keep open either 10350 or this one, I don't
see much value in keeping open both. Ok? 2- I'm not aware of any real cure for
this kind of problems within a RC implementation. Are
The following piece of code crashes both my custom built gcc 4.0.0 (straight
from an official mirror) and gcc 4.0.0-0.41.fc3 from Red Hat. The code is a
reconstruction of a piece of propriatary code I cannot post.
CODE:
typedef unsigned int size_t;
class A;
class B;
class C;
templateclass _T
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-02 12:06 ---
// this testcase fails also on amd64:
extern void abort (void);
int f ()
{
return -1;
}
int main ()
{
int b, c, i;
b = 0;
c = f ();
if (c = 0)
{
c = -c;
for (i = 0;
--- Additional Comments From moudekotte at khaeon dot nl 2005-05-02 12:07
---
Created an attachment (id=8793)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8793action=view)
Preprocessed file
Preprocessed file as mentioned in bug description
--
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
GCC target
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
12:21 ---
Confirmed, a 3.4 regression also.
Reduced testcase:
typedef __SIZE_TYPE__ size_t;
templateclass _T inline void* operator new( size_t Size, _T);
struct B {
int a;
int* m() {
--
What|Removed |Added
Component|rtl-optimization|target
Keywords||missed-optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
12:27 ---
Confirmed, a regression from 3.4.0.
--
What|Removed |Added
Status|UNCONFIRMED
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
* the exact version of GCC;
gcc version 3.4.4 20050502 (prerelease)
* the system type;
i686-pc-linux-gnu (rhel3)
* the options given when GCC was configured/built;
configure --prefix=/opt/gcc34-20050502 --enable-languages=c,c++
* the complete command line that triggers the bug;
/opt/gcc34
--- Additional Comments From weary at gamebox dot net 2005-05-02 12:35
---
Created an attachment (id=8794)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8794action=view)
the file that doesn't compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21337
Attached files generate Stack Overflow when compiled with -c -gnatc and -gnatt.
With only -c and either of the other two, no problems.
Problem also exists in prior 4.0 snapshot, and as I recall, in the 4.0 release
as well.
package Toplevel is
end Toplevel;
package Toplevel.Intermediate is
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
12:42 ---
This works with 3.4.4 20050429 so it has to be a recent regression.
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-02 13:04
---
This is a target bug.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-02 13:22
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
Looks like it. The example function at the user level isn't the
same, but the basic problem is.
I'd forgotten I ever sent the first
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-02 13:27 ---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| Two quick comments: 1- I'd like to keep open either 10350 or this
| one, I
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-02 13:30
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
| Two quick comments: 1- I'd like to keep open either 10350 or
| this one, I don't see much value in keeping open both. Ok?
In that
--- Additional Comments From pcarlini at suse dot de 2005-05-02 13:31
---
Ok, thanks, let's keep open this one, then.
--
What|Removed |Added
Severity|minor
--- Additional Comments From pcarlini at suse dot de 2005-05-02 13:32
---
*** Bug 10350 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-05-02 13:32
---
*** This bug has been marked as a duplicate of 21334 ***
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-02 13:42
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00073.html
--
What|Removed |Added
Goodmornig,
I have a problem when compiling the gcc 4.0.0 on NCR release 4.0 version
3.0, system UNIX_SV
The system displays some errors:
config.status: executing default commands
if [ x != x ] [ ! -d pic ]; then \
mkdir pic; \
else true; fi
touch
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
13:52 ---
CPPFLAGS='-I/usr/local/include'
Do you have CPPFLAGS set if so this is your bug and not GCC's configure bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21268
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
13:54 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00076.html.
--
What|Removed |Added
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-02 14:09 ---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| --- Additional Comments From pcarlini at suse dot de 2005-05-02 13:31
The testcase in PR 15875 started ICE'ing on the 3.4 branch again:
==
struct A
{
void foo();
};
templateint void bar()
{
typedef void (A::*fptr)();
fptr ptr = A::foo;
}
==
bug.c: In function `void bar()':
bug.c:9:
--- Additional Comments From dorit at il dot ibm dot com 2005-05-02 14:14
---
see patch: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02874.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
14:15 ---
This is most likely the same as PR 21339.
--
What|Removed |Added
BugsThisDependsOn|
--
What|Removed |Added
OtherBugsDependingO||21337
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21339
--
What|Removed |Added
Known to work||3.4.3 4.1.0 4.0.0
Target Milestone|--- |3.4.4
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
14:18 ---
Yes this is a dup of bug 21339.
*** This bug has been marked as a duplicate of 21339 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
14:18 ---
*** Bug 21337 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
14:19 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pcarlini at suse dot de 2005-05-02 14:20
---
Does the C++ standard mention multithreading and Posix threads? ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--
What|Removed |Added
Status|REOPENED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-02
14:29 ---
Created an attachment (id=8801)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8801action=view)
Proposed patch
--
What|Removed |Added
--- Additional Comments From gdr at gcc dot gnu dot org 2005-05-02 14:42
---
(In reply to comment #9)
Does the C++ standard mention multithreading and Posix threads? ;)
That is a very uninteresting question. You're quite right that the
C++ standard does not mention usability, though.
--
What|Removed |Added
Known to fail||4.0.0
Known to work||4.1.0
Summary|eoshift segfaults when
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-02
14:47 ---
Subject: Bug 19991
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-02 14:46:48
Modified files:
gcc/cp :
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-02
14:48 ---
Fixed in 3.4.4.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From dorit at il dot ibm dot com 2005-05-02 14:51
---
I get the following bootstrap failure on powerpc-apple-darwin, with -O2 -ftree-
vectorize:
../../gcc/gcc/builtins.c: In function 'fold_builtin_1':
../../gcc/gcc/builtins.c:8451: internal compiler error: Bus
--- Additional Comments From mark at codesourcery dot com 2005-05-02 14:56
---
Subject: Re: New: [3.4 regression] ICE with pointer to member
in template
reichelt at gcc dot gnu dot org wrote:
The testcase in PR 15875 started ICE'ing on the 3.4 branch again:
Mark, this is most
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--- Additional Comments From dnovillo at redhat dot com 2005-05-02 15:29
---
Subject: Re: [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
On Fri, Apr 29, 2005 at 07:57:43PM -, ro at techfak dot uni-bielefeld dot
de wrote:
Unfortunately, even with the patch
--- Additional Comments From v dot haisman at sh dot cvut dot cz
2005-05-02 15:30 ---
Subject: Re: [4.0/4.1 Regression] Bootstrap, configuration
problem and insn-conditions.c
Nope, my environment is clean wrt/ compiler flags.
On Mon, 2 May 2005, pinskia at gcc dot gnu dot org
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-02
15:38 ---
Subject: Bug 15875
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-02 15:38:38
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-02
15:40 ---
Subject: Bug 15875
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-02 15:40:25
Modified files:
gcc/testsuite :
--- Additional Comments From v dot haisman at sh dot cvut dot cz
2005-05-02 15:52 ---
Subject: Re: [4.0/4.1 Regression] Bootstrap, configuration
problem and insn-conditions.c
That I don't have it set imho can be seen from config.log:
ac_cv_env_CPPFLAGS_set=
On Mon, 2 May 2005,
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
15:53 ---
Just curious: where can I get more information about this issue? We were
linking our shared library statically with libgcc_eh.a in the past with no
problems, and many people on different machines
--- Additional Comments From rittle at latour dot waar dot labs dot mot dot
com 2005-05-02 16:02 ---
Subject: Re: New: Lack of Posix compliant thread safety in
std::basic_string
I am sending this to the g++ bug list on the recommendation of
Gabriel Dos Reis. From what little
--- Additional Comments From dorit at il dot ibm dot com 2005-05-02 16:06
---
I can't reproduce this problem - not for the testcase in comment #3 and not for
the testcase in comment #5 (I tried on i686-pc-linux-gnu and on powerpc-apple-
darwin). Does the problem still occur?
--
--- Additional Comments From dorit at il dot ibm dot com 2005-05-02 16:27
---
Thanks for the testcase.
I tried reproducing the problem on i686-pc-linux-gnu with today's snapshot of
4.1, and also with today's snapshot of 4.0 (gcc version 4.0.1 20050502
(prerelease)) - I can't
--- Additional Comments From doko at cs dot tu-berlin dot de 2005-05-02
16:29 ---
Subject: Re: [4.0 only] gfortran internal error in namelist read
pault at gcc dot gnu dot org writes:
--- Additional Comments From pault at gcc dot gnu dot org 2005-04-23
16:16 ---
The
Ice for C++ from ZeroC (http://www.zeroc.com, source code available) doesn't
compile anymore with
GCC 4.0.0 (I also tried with GCC from CVS and the result is the same). It
compiled fine with GCC 3.4.2.
I'm getting an error which looks like the following with 4.0.0:
Main.cpp: In constructor
--- Additional Comments From callahan at sci dot utah dot edu 2005-05-02
16:36 ---
I suspect that this is an x86-64 bug.
I have a different computer available to me here. I get the same result as
Dorit. Note that it appears to be the same Ubuntu beta version as the x86-64
version. I
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-02 16:40 ---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
rittle at latour dot waar dot labs dot mot dot com [EMAIL PROTECTED] writes:
| Subject: Re: New: Lack of Posix compliant
--- Additional Comments From mckinlay at redhat dot com 2005-05-02 16:44
---
It sounds like this is just a matter of testing that it really does work now.
Pinskia: If you could test/post a patch, that would be great.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21325
--- Additional Comments From law at redhat dot com 2005-05-02 16:46 ---
Subject: Re: Missed jump threading/bypassing
optimization with loop and % (or ands)
On Sun, 2005-05-01 at 16:29 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc
--- Additional Comments From mronell at alumni dot upenn dot edu
2005-05-02 16:49 ---
Apologies for my persistence, but the following is still not clear to
me. Given the last reply to this concern, I now understand:
1. Placement into shared memory is not possible. If processes
The following FAIL has appeared on mainline between 20050501 and 20050502 on
targets including i686-pc-linux-gnu and hppa64-hpux. gcc-testresults will
probably show more targets.
FAIL: gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times arr_base.[^0][^\n\r]*= 0
--
Summary: [4.1 Regression
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-02 16:53
---
The SPEC CPU2000 failures reported in 21054, on which the testcase in
comment #5 is based, stopped on 20050423.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947
--- Additional Comments From pcarlini at suse dot de 2005-05-02 17:01
---
You probably got the mail about users saying that he read on C++
newsgroups that V3-s implementation of std::string is known to be
avoided in multi-threaded programs.
Whereas I'm all for providing alternate
1 - 100 of 163 matches
Mail list logo
