[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[ebotcazou at gcc dot gnu dot org]

--- 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

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[info at yourkit dot com]

--- 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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[info at yourkit dot com]

--- 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

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[ebotcazou at gcc dot gnu dot org]

--- 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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[info at yourkit dot com]

--- 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
a890  004f0007 R_SPARC_WDISP30    abort + 0
ab70  004f0007 R_SPARC_WDISP30    abort + 0
b234  004f0007 R_SPARC_WDISP30    abort + 0
b244  004f0007 R_SPARC_WDISP30    abort + 0
cd04  004f0007 R_SPARC_WDISP30    abort + 0
cd48  004f0007 R_SPARC_WDISP30    abort + 0
cd6c  004f0007 R_SPARC_WDISP30    abort + 0
cde4  004f0007 R_SPARC_WDISP30    abort + 0
a754  00850007 R_SPARC_WDISP30   00012a20 
_Unwind_GetTextRelBase + 0
a76c  00360007 R_SPARC_WDISP30   00012a30 
_Unwind_GetRegionStart + 0
aa38  00360007 R_SPARC_WDISP30   00012a30 
_Unwind_GetRegionStart + 0
a774  00ad0007 R_SPARC_WDISP30   00012a28 
_Unwind_GetDataRelBase + 0
acc8  008a0007 R_SPARC_WDISP30   b720 __cxa_begin_catch 
+ 0
acec  008a0007 R_SPARC_WDISP30   b720 __cxa_begin_catch 
+ 0
b1f4  008a0007 R_SPARC_WDISP30   b720 __cxa_begin_catch 
+ 0
b204  008a0007 R_SPARC_WDISP30   b720 __cxa_begin_catch 
+ 0
b23c  008a0007 R_SPARC_WDISP30   b720 __cxa_begin_catch 
+ 0
b3cc  008a0007 R_SPARC_WDISP30   b720 __cxa_begin_catch 
+ 0
b438  008a0007 R_SPARC_WDISP30   b720 __cxa_begin_catch 
+ 0
cd5c  008a0007 R_SPARC_WDISP30   b720 __cxa_begin_catch 
+ 0
cd74  008a0007 R_SPARC_WDISP30   b720 __cxa_begin_catch 
+ 0
ace4  008c0007 R_SPARC_WDISP30   b284 
_ZN10__cxxabiv112__une + 
0
b2b4  008c0007 R_SPARC_WDISP30   b284 
_ZN10__cxxabiv112__une + 
0
acf4  007a0007 R_SPARC_WDISP30   ba68 
__cxa_get_globals_fast + 0
b7d4  007a0007 R_SPARC_WDISP30   ba68 
__cxa_get_globals_fast + 0
ad6c  00920007 R_SPARC_WDISP30   b580 
__cxa_allocate_excepti + 0
ada8  00750007 R_SPARC_WDISP30   b340 __cxa_throw + 0
adb0  0057 R_SPARC_WDISP30   b7d0 __cxa_end_catch + 0
adb8  0057 R_SPARC_WDISP30   b7d0 __cxa_end_catch + 0
b214  0057 R_SPARC_WDISP30   b7d0 __cxa_end_catch + 0
b24c  0057 R_SPARC_WDISP30   b7d0 __cxa_end_catch + 0
cd64  0057 R_SPARC_WDISP30   b7d0 __cxa_end_catch + 0
cddc  0057 R_SPARC_WDISP30   b7d0 __cxa_end_catch + 0
cdec  0057 R_SPARC_WDISP30   b7d0 __cxa_end_catch + 0
adc0  005f0007 R_SPARC_WDISP30   00014828 _Unwind_Resume + 0
b21c  005f0007 R_SPARC_WDISP30   00014828 _Unwind_Resume + 0
b254  005f0007 R_SPARC_WDISP30   00014828 _Unwind_Resume + 0
b56c  005f0007 R_SPARC_WDISP30   00014828 _Unwind_Resume + 0
b70c  005f0007 R_SPARC_WDISP30   00014828 _Unwind_Resume + 0
b7bc  005f0007 R_SPARC_WDISP30   00014828 _Unwind_Resume + 0
badc  005f0007 R_SPARC_WDISP30   00014828 _Unwind_Resume + 0
bc88  005f0007 R_SPARC_WDISP30   00014828 _Unwind_Resume + 0
cdf4  005f0007 R_SPARC_WDISP30   00014828 _Unwind_Resume + 0
adc8  009d0007 R_SPARC_WDISP30   b228 
_ZN10__cxxabiv111__ter + 0
b1fc  009d0007 R_SPARC_WDISP30   b228 
_ZN10__cxxabiv111__ter + 0
b278  009d0007 R_SPARC_WDISP30   b228 
_ZN10__cxxabiv111__ter + 0
b334  009d0007 R_SPARC_WDISP30   b228 
_ZN10__cxxabiv111__ter + 0
add0  00260007 R_SPARC_WDISP30   b3e0 __cxa_rethrow + 0
cca0  00260007 R_SPARC_WDISP30   b3e0 __cxa_rethrow + 0
ccc0  00260007 R_SPARC_WDISP30   b3e0 __cxa_rethrow + 0
ae78  009c0007 R_SPARC_WDISP30   00012d74 _Unwind_SetGR + 0
ae8c  009c0007 R_SPARC_WDISP30   00012d74 _Unwind_SetGR + 0
ae9c  00760007 R_SPARC_WDISP30   00012dd0 _Unwind_SetIP + 0
af14  00890007 R_SPARC_WDISP30   00012dd8 
_Unwind_GetLanguageSpe + 
0
af58  00280007 R_SPARC_WDISP30   00012dc8 _Unwind_GetIP + 0
b1e4  00220007 R_SPARC_WDISP30   b29c _ZSt10unexpectedv 
+ 0
b1ec  00530007 R_SPARC_WDISP30   b260 _ZSt9termi

[Bug libfortran/19481] libgfortran doesn't build -- configure doesn't handle cabs() well

[fxcoudert at gcc dot gnu dot org]

--- 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

[Bug libfortran/20788] Loading libgfortran.so clobbers C redirection of stdin/stdout/stderr

[fxcoudert at gcc dot gnu dot org]

--- 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 tree as soon as it's reviewed.

-- 
   What|Removed |Added

URL||http://gcc.gnu.org/ml/fortra
   ||n/2005-05/msg8.html
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |
   Keywords||patch
   Last reconfirmed|2005-04-15 13:48:43 |2005-05-02 07:52:44
   date||
Summary|Loading libgfortran.so  |Loading libgfortran.so
   |clobbers C redirection of   |clobbers C redirection of
   |stdin   |stdin/stdout/stderr
   Target Milestone|--- |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20788

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[ebotcazou at gcc dot gnu dot org]

--- 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 not really intended (and
might cause problems for exception propagation in C++).

The fix is indeed to recompile every GCC library with -fPIC.  Try to configure
at toplevel --with-pic, but I'm not sure the option is valid there.  Otherwise
you'll need to specifically configure libstdc++-v3 --with-pic.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277

[Bug c++/15877] [3.4/4.0 Regression] valid code using templates and anonymous enums is rejected

[giovannibajo at libero dot it]

--- 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

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[info at yourkit dot com]

--- 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 C++).

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 size bigger.

Without --disable-shared we had other problems linking 64 bit code statically.

Anyway, option --disable-shared exists, and is documented. So it should either
properly work (for platforms it is supported for), or be dropped (for platforms
where it is not supported). While there's nothing said it is not supported for
Solaris, all its improper work is a bug, and nothing but a bug. Isn't it? :)

> The fix is indeed to recompile every GCC library with -fPIC.  Try to configure
at toplevel --with-pic, but I'm not sure the option is valid there.  Otherwise
you'll need to specifically configure libstdc++-v3 --with-pic.

Thank you for the suggestion. I'll try it now, and will let you know whether it
helps.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277

[Bug rtl-optimization/21329] New: optimize i386 block copy

[vda at port dot imtp dot ilyichevsk dot odessa dot ua]

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
internals at all, so take it with reasonable suspicion.

-- 
   Summary: optimize i386 block copy
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda at port dot imtp dot ilyichevsk dot odessa dot ua
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21329

[Bug rtl-optimization/21329] optimize i386 block copy

[vda at port dot imtp dot ilyichevsk dot odessa dot ua]

--- 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=8790&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21329

[Bug rtl-optimization/21329] optimize i386 block copy

[vda at port dot imtp dot ilyichevsk dot odessa dot ua]

--- 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=8791&action=view)
patch against 4.0.0


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21329

[Bug rtl-optimization/21329] optimize i386 block copy

[vda at port dot imtp dot ilyichevsk dot odessa dot ua]

--- 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$w21, %esi
cld
-   movl$2, %ecx
-   rep
+   movsl
movsl
movsb
popl%esi
@@ -55,8 +54,7 @@
movl$t22, %edi
movl$w22, %esi
cld
-   movl$2, %ecx
-   rep
+   movsl
movsl
movsw
popl%esi
@@ -75,8 +73,7 @@
movl$t23, %edi
movl$w23, %esi
cld
-   movl$2, %ecx
-   rep
+   movsl
movsl
movsw
movsb
@@ -96,8 +93,8 @@
movl$t30, %edi
movl$w30, %esi
cld
-   movl$3, %ecx
-   rep
+   movsl
+   movsl
movsl
popl%esi
popl%edi
@@ -115,8 +112,9 @@
movl$t40, %edi
movl$w40, %esi
cld
-   movl$4, %ecx
-   rep
+   movsl
+   movsl
+   movsl
movsl
popl%esi
popl%edi
@@ -169,7 +167,6 @@
movl%esp, %ebp
pushl   %edi
pushl   %esi
-   subl$24, %esp
movlw10, %eax
movl%eax, t10
movlw20, %eax
@@ -179,36 +176,34 @@
movl$t21, %edi
movl$w21, %esi
cld
-   movl$2, %ecx
-   rep
+   movsl
movsl
movsb
movl$t22, %edi
movl$w22, %esi
-   movb$2, %cl
-   rep
+   movsl
movsl
movsw
movl$t23, %edi
movl$w23, %esi
-   movb$2, %cl
-   rep
+   movsl
movsl
movsw
movsb
movl$t30, %edi
movl$w30, %esi
-   movb$3, %cl
-   rep
+   movsl
+   movsl
movsl
movl$t40, %edi
movl$w40, %esi
-   movb$4, %cl
-   rep
+   movsl
+   movsl
+   movsl
movsl
movl$t50, %edi
movl$w50, %esi
-   movb$5, %cl
+   movl$5, %ecx
rep
movsl
movl$t60, %edi
@@ -216,7 +211,6 @@
movb$6, %cl
rep
movsl
-   addl$24, %esp
popl%esi
popl%edi
leave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21329

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[ebotcazou at gcc dot gnu dot org]

--- 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 size bigger.

5 MB uncompressed for 32-bit, 6 MB uncompressed for 64-bit!

> Anyway, option --disable-shared exists, and is documented. So it should either
> properly work (for platforms it is supported for), or be dropped (forplatforms
> where it is not supported). While there's nothing said it is not supported for
> Solaris, all its improper work is a bug, and nothing but a bug. Isn't it? :)

There is nothing wrong in the current behavior of --disable-shared: it builds
static libraries the way static libraries should be built.  Your practice of
building shared libraries with a compiler configured with --disable-shared looks
far more questionable to me; if I were to change something, I'd simply reject
-shared in that case.  Note for example that a shared libgcc is required on
Solaris for exception propagation accross shared libraries.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277

[Bug rtl-optimization/21330] New: ICE in compare_and_jump_seq, at loop-unswitch.c:120

[jakub at gcc dot gnu dot org]

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;
}
   x[i]=0;
}

causes ICE in compare_and_jump_seq on powerpc-linux, with both -O3 -m32 and
-O3 -m64.

-- 
   Summary: ICE in compare_and_jump_seq, at loop-unswitch.c:120
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21330

[Bug rtl-optimization/21329] optimize i386 block copy

[vda at port dot imtp dot ilyichevsk dot odessa dot ua]

--- 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  2 11:39:40 2005
@@ -32,8 +32,8 @@
movl$t21, %edi
movl$w21, %esi
cld
-   movl$9, %ecx
-   rep
+   movsl
+   movsl
movsb
popl%esi
popl%edi
@@ -50,9 +50,9 @@
movl$t22, %edi
movl$w22, %esi
cld
-   movl$10, %ecx
-   rep
-   movsb
+   movsl
+   movsl
+   movsw
popl%esi
popl%edi
leave
@@ -68,8 +68,9 @@
movl$t23, %edi
movl$w23, %esi
cld
-   movl$11, %ecx
-   rep
+   movsl
+   movsl
+   movsw
movsb
popl%esi
popl%edi
@@ -86,9 +87,8 @@
movl$t30, %edi
movl$w30, %esi
cld
-   movl$3, %eax
-   movl%eax, %ecx
-   rep
+   movsl
+   movsl
movsl
popl%esi
popl%edi
@@ -105,9 +105,9 @@
movl$t40, %edi
movl$w40, %esi
cld
-   movl$4, %eax
-   movl%eax, %ecx
-   rep
+   movsl
+   movsl
+   movsl
movsl
popl%esi
popl%edi
@@ -168,34 +168,34 @@
movl$t21, %edi
movl$w21, %esi
cld
-   movl$9, %ecx
-   rep
+   movsl
+   movsl
movsb
movl$t22, %edi
movl$w22, %esi
cld
-   movl$10, %ecx
-   rep
-   movsb
+   movsl
+   movsl
+   movsw
movl$t23, %edi
movl$w23, %esi
cld
-   movl$11, %ecx
-   rep
+   movsl
+   movsl
+   movsw
movsb
movl$t30, %edi
movl$w30, %esi
cld
-   movl$3, %eax
-   movl%eax, %ecx
-   rep
+   movsl
+   movsl
movsl
movl$t40, %edi
movl$w40, %esi
cld
-   movl$4, %eax
-   movl%eax, %ecx
-   rep
+   movsl
+   movsl
+   movsl
movsl
movl$t50, %edi
movl$w50, %esi


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21329

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[info at yourkit dot com]

--- 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
worked for 32 bit.

> There is nothing wrong in the current behavior of --disable-shared: it builds
static libraries the way static libraries should be built.  Your practice of
building shared libraries with a compiler configured with --disable-shared looks
far more questionable to me; if I were to change something, I'd simply reject
-shared in that case.  Note for example that a shared libgcc is required on
Solaris for exception propagation accross shared libraries.

Actually, instead of --disable-shared we were successfully using gcc compiled
without this flag, specifing appropriate *.a on linking stage. --disable-shared
only makes compile [command line] more straightforward, not letting compiler
using .so's instead.

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 regard to availablity of shared
libraries, and make the library as small as possible.

The approach works fine for 32 bit on Solaris. And it is definetely a bug that
it doesn't do so for 64 bit.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[info at yourkit dot com]

--- 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

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[ebotcazou at gcc dot gnu dot org]

--- 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 regard to availablity of 
> shared libraries, and make the library as small as possible.

Indeed, except that if the static libraries are not compiled with -fPIC, your
shared library is only shared on disk, not in memory.

> The approach works fine for 32 bit on Solaris. And it is definetely a bug that
> it doesn't do so for 64 bit.

It works only by accident in 32-bit mode; it would fail if the R_SPARC_WDISP30
relocation was slightly different.  And, again, not using a shared libgcc on
Solaris means that exceptions cannot be propagated across shared libraries;
that's why g++ automatically passes -shared-libgcc on Solaris.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[ebotcazou at gcc dot gnu dot org]

--- 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 |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277

[Bug c/21331] New: Incorrect folding of comparison

[tege-gcc at swox dot com]

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 

int bar (void)
{  return -1;  }

unsigned long
foo ()
{ unsigned long retval;
  retval = bar ();
  if (retval == -1)  return 0;
  return 3;  }

main ()
{ if (foo () != 0)  abort ();
  return 0;  }

-- 
   Summary: Incorrect folding of comparison
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tege-gcc at swox dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-redhat-linux, powerpc-apple-darwin8
  GCC host triplet: ia64-redhat-linux, powerpc-apple-darwin8
GCC target triplet: ia64-redhat-linux, powerpc-apple-darwin8


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21331

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

[fxcoudert at gcc dot gnu dot org]

--- 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 on SSA right now, this could be related.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900

[Bug c/21332] New: -O2 makes a loop doesn't execute a body

[akr at m17n dot org]

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();
  long i;
  if (c > 0) {
for (i=0;i search starts here:
 /usr/local/include
 /home/src/gcc/trunk/include
 /home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0/include
 /usr/include
End of search list.
GNU C version
 4.1.0 20050502 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050502 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -V -Qy -o /tmp/cc6jWNoa.o /tmp/cc6LaTqE.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
 /home/src/gcc/trunk/libexec/gcc/i686-pc-linux-gnu/4.1.0/collect2 --eh-frame-hdr
-m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0/crtbegin.o
-L/home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0
-L/home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0/../../.. /tmp/cc6jWNoa.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /home/src/gcc/trunk/lib/gcc/i686-pc-linux-gnu/4.1.0/crtend.o
/usr/lib/crtn.o
% ./a.out   
beg 2
end 0

It works well without optimization as follows.

% gcc t.c   
% ./a.out 
beg 2
0
1
end 2

-- 
   Summary: -O2 makes a loop doesn't execute a body
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21332

[Bug rtl-optimization/21330] ICE in compare_and_jump_seq, at loop-unswitch.c:120

[jakub at gcc dot gnu dot org]

--- 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=8792&action=view)
Patch I'm about to test.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21330

[Bug c++/19666] [3.3 Regression] Trouble with prt-to-members: rejects-valid/ICE in fold_convert

[reichelt at gcc dot gnu dot org]

--- 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

   Target Milestone|3.4.3   |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[info at yourkit dot com]

--- 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++ automatically passes -shared-libgcc on Solaris.

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 successfully used it. Should there be any
problems?  By the way, all these tricks were found googling reports of other
people who wanted to link statically.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277

[Bug c++/18384] [3.3 Regression] ICE on zero-length array with empty initializer...

[reichelt at gcc dot gnu dot org]

-- 
   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 Milestone|3.3.6   |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384

[Bug libfortran/21333] New: in_pack / in_unpack alignment issues

[tkoenig at gcc dot gnu dot org]

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)
  call foo(b(5:1:-1),5)
end program main

subroutine foo(arr,n)
  complex, dimension(n) :: a
end subroutine foo

The equivalence makes sure that a and b cannot both be
aligned on an 8-byte-boundary.

The array reference gets repacked for both calls to foo:

parm.2.dtype = 545;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 5;
parm.2.dim[0].stride = -1;
parm.2.data = (complex4[0:] *) (complex4[0:] *) &equiv.0.a[4];
parm.2.offset = 0;
D.529 = _gfortran_internal_pack (&parm.2);
foo (D.529, &C.530);
if (D.529 != parm.2.data)
  {
_gfortran_internal_unpack (&parm.2, D.529);
_gfortran_internal_free (D.529);
  }

internal_pack_generic has the following code:

  size = GFC_DESCRIPTOR_SIZE (source);
  switch (size)
{
case 4:
  return internal_pack_4 ((gfc_array_i4 *)source);

case 8:
  return internal_pack_8 ((gfc_array_i8 *)source);
}

so internal_pack_8 is called.

This operates on a gfc_array_i8.

On machines where you can only align an i8 on an eight-byte-boundary,
this will fail.

I'd appreciate if somebody could run the test program on such a
machine, to see wehter I got this right :-)

Thomas

-- 
   Summary: in_pack / in_unpack alignment issues
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21333

[Bug middle-end/21331] [4.0 Regression] Incorrect folding of comparison

[pinskia at gcc dot gnu dot org]

--- 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
integer_zerop.
* tree-gimple.c (is_gimple_min_invariant): Consider overflowed
constants invariant.


-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  BugsThisDependsOn||21293
 Status|UNCONFIRMED |NEW
  Component|c   |middle-end
 Ever Confirmed||1
  GCC build triplet|ia64-redhat-linux, powerpc- |
   |apple-darwin8   |
   GCC host triplet|ia64-redhat-linux, powerpc- |
   |apple-darwin8   |
 GCC target triplet|ia64-redhat-linux, powerpc- |any 64bit target
   |apple-darwin8   |
   Keywords||wrong-code
  Known to fail||4.0.0
  Known to work||3.4.3 4.1.0
   Last reconfirmed|-00-00 00:00:00 |2005-05-02 11:40:53
   date||
Summary|Incorrect folding of|[4.0 Regression] Incorrect
   |comparison  |folding of comparison
   Target Milestone|--- |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21331

[Bug libstdc++/21334] New: Lack of Posix compliant thread safety in std::basic_string

[jkanze at cheuvreux dot com]

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 Posix is: "Applications shall
ensure that access to any memory location by more than one
thread of control (threads or processes) is restricted such that
no thread of control can read or modify a memory location while
another thread of control may be modifying it."  The obvious
extension to C++ is that of replacing "memory location" with
"object"; at the very least, of course, one can only require
something of "memory locations" which the user sees, directly or
indirectly.  The statement in the libstdc++-v3 FAQ (question
5.6) is: "All library objects are safe to use in a multithreaded
program as long as each thread carefully locks out access by any
other thread while it uses any object visible to another thread,
i.e., treat library objects like any other shared resource. In
general, this requirement includes both read and write access to
objects; unless otherwise documented as safe, do not assume that
two threads may access a shared standard library object at the
same time."  A considerably weaker guarantee than what one
normally expects under Posix.  (Note that the clause "like any
other shared resource" is simply false for those of us used to
the Posix model.  If I replace std::string with char[] in my
code below, the behavior is perfectly defined under Posix.)

The following is an example of a program which may cause
problems:

#include 
#include 
#include 
#include 

std::string g ;

extern "C" void*
thread1(
void*   lock )
{
std::string t( g ) ;
pthread_mutex_lock( static_cast< pthread_mutex_t* >( lock ) ) ;
std::cout << t << '\n' ;
pthread_mutex_unlock( static_cast< pthread_mutex_t* >( lock ) ) ;
return NULL ;
}

extern "C" void*
thread2(
void*   lock )
{
std::string t( g.begin(), g.end() ) ;
pthread_mutex_lock( static_cast< pthread_mutex_t* >( lock ) ) ;
std::cout << t << '\n' ;
pthread_mutex_unlock( static_cast< pthread_mutex_t* >( lock ) ) ;
return NULL ;
}

int
main()
{
g = "0123456789" ;
pthread_mutex_t lock ;
pthread_mutex_init( &lock, NULL ) ;
pthread_t   t1 ;
if ( pthread_create( &t1, NULL, &thread1, &lock ) != 0 ) {
std::cerr << "Could not create thread1" << std::endl ;
}
pthread_t   t2 ;
if ( pthread_create( &t2, NULL, &thread2, &lock ) != 0 ) {
std::cerr << "Could not create thread}
pthread_join( t1, NULL ) ;
pthread_join( t2, NULL ) ;
return 0 ;
}

Consider the following scenario:

 -- Thread 2 executes first.  It gets to the expression
g.begin() (which for purposes of argument, we will suppose
is called before g.end() -- the problem will occur in which
ever function is called first), and starts executing it.

At this point, the value _M_refcount in the _Rep_base is 0,
since there is only one instance, g, which shares the
representation.  The representation is not "leaked", so we
call _M_leak_hard.

_M_leak_hard calls _M_rep()->_M_is_shared(), which returns
false.

 -- Thread 1 interupts.  Thread 2 calls the copy constructor,
with g as a parameter, which ultimately calls _M_grab on the
_M_is_leaked() returns false, since the _M_refcount is still
0 in the representation.  Thread 2 thus calls _M_refcopy()
on the representation, which (atomically) increments
_M_refcount.  Thread 1 leaves the copy constructor.

 -- Now back to thread 2.   Since _M_is_shared() returned false,
thread 2 doesn't call _M_mutate -- is simply calls
_M_set_leaked() on the representation, which sets
_M_refcount to -1.

We will suppose that this modification is visible to all
other threads, despite the fact that there are no memory
barriers around it (which means that this supposition will
be false on certain platforms).

 -- And life goes on.  The second call to begin()/end() doesn't
change anything, because it finds that the representation is
already "leaked".

 -- Finally, suppose that thread 1 finishes while thread 1 is
still using its iterators.  Thread 1 calls the destructor
for its string.  It sees that _M_refcount < 0, concludes
that the representation is leaked, and deletes it.  Despite
the fact that thread 2 still holds iterators refering to it,
and despite the fact that there is still a global variable
(usable after the pthread_joins in main) which depends on
it.

The problem is, of course, that the sequence which tests whether
we have to leak, and then leaks,

[Bug bootstrap/21335] New: bootstrap fails with CFLAGS="-O3 -ftree-vectorize"

[micis at gmx dot de]

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: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micis at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21335

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[pinskia at gcc dot gnu dot org]

--- 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

[Bug tree-optimization/20122] Wrong code with gcc 4.0 tree-vectorizer

[micis at gmx dot de]

--- 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

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20122

[Bug libfortran/21324] #undef GFC_CLEAR_MEMORY causes testsuite failures

[tkoenig at gcc dot gnu dot org]

--- 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

[Bug tree-optimization/21332] [4.1 Regression] -ftree-vrp makes a loop doesn't execute a body

[pinskia at gcc dot gnu dot org]

--- 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||dnovillo at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2005-05-02 11:59:50
   date||
Summary|-O2 makes a loop doesn't|[4.1 Regression] -ftree-vrp
   |execute a body  |makes a loop doesn't execute
   ||a body
   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21332

[Bug tree-optimization/20122] Wrong code with gcc 4.0 tree-vectorizer

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20122

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[pcarlini at suse dot de]

--- 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 you? For what is worth,
in the v7-branch there is already a basic_string framework for flexible memory
management policies and I have already prototyped an additional policy not using
RC at all. I'm planning to add it the repository very soon. This is stuff that
breaks the 3.4/4.0 ABI of course, but if people want it we can envisage 
providing
it as an extension in future 4.0.x releases.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

[Bug c++/21336] New: Internal compiler error when using custom new operators

[moudekotte at khaeon dot nl]

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;

template inline void* operator new( size_t Size, _T&);
template inline void operator delete( void*, _T&);

class Abase {};
class A : public Abase {
public:
A() {}
A(int a, int b, int c, int d) {}
};

class Bbase {};
class B : public Bbase {
public:
Abase* m() {
return new(a) A(1,2,3,4);
}
A a;
};

class C {
public:
Bbase* n() {
return new B();
}
};

GCC OUTPUT:
main.cpp: In member function ‘Bbase* C::n()’:
main.cpp:29: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccUR3mvM.out file, please attach this to
your bugreport.

OTHER COMPILERS:
MSVC++ 7.0 compiles the code above without warnings.

gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3) returns this:
main.cpp: In member function `Bbase* C::n()':
main.cpp:29: error: no suitable or ambiguous `operator new' found in class `B'

-- 
   Summary: Internal compiler error when using custom new operators
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: moudekotte at khaeon dot nl
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-redhat-linux
GCC target triplet: i386-redhat-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21336

[Bug tree-optimization/21332] [4.1 Regression] -ftree-vrp makes a loop doesn't execute a body

[belyshev at depni dot sinp dot msu dot ru]

--- 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; i < c; i++)
  b = 1;
  if (!b)
abort ();
}
  return 0;
}


-- 
   What|Removed |Added

   Severity|normal  |critical


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21332

[Bug c++/21336] Internal compiler error when using custom new operators

[moudekotte at khaeon dot nl]

--- 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=8793&action=view)
Preprocessed file

Preprocessed file as mentioned in bug description

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21336

[Bug rtl-optimization/21330] [4.0/4.1 Regression] ICE in compare_and_jump_seq, at loop-unswitch.c:120

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 GCC target triplet|powerpc-linux   |powerpc-*-*
   Keywords||ice-on-valid-code
Summary|ICE in compare_and_jump_seq,|[4.0/4.1 Regression] ICE in
   |at loop-unswitch.c:120  |compare_and_jump_seq, at
   ||loop-unswitch.c:120
   Target Milestone|--- |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21330

[Bug c++/21336] [3.4/4.0/4.1 Regression] Internal compiler error when using custom new operators

[pinskia at gcc dot gnu dot org]

--- 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;
template inline void* operator new( size_t Size, _T&);
struct B {
int a;
int* m() {
return new(a) int;
}
};
B* n() {
 return new B();
}

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
  Known to fail||3.4.0 4.0.0 4.1.0
  Known to work||3.3.3
   Last reconfirmed|-00-00 00:00:00 |2005-05-02 12:21:41
   date||
Summary|Internal compiler error when|[3.4/4.0/4.1 Regression]
   |using custom new operators  |Internal compiler error when
   ||using custom new operators
   Target Milestone|--- |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21336

[Bug target/21329] optimize i386 block copy

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|rtl-optimization|target
   Keywords||missed-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21329

[Bug target/21329] [4.0/4.1 Regression] optimize i386 block copy

[pinskia at gcc dot gnu dot org]

--- 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 |NEW
 Ever Confirmed||1
  Known to fail||4.0.0 4.1.0
  Known to work||3.4.0
   Last reconfirmed|-00-00 00:00:00 |2005-05-02 12:27:23
   date||
Summary|optimize i386 block copy|[4.0/4.1 Regression]
   ||optimize i386 block copy
   Target Milestone|--- |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21329

[Bug libstdc++/21321] [4.1 regression] mmix-knuth-mmixware 27_io/basic_filebuf/seekpos/12790-3.cc execution test

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321

[Bug c++/21337] New: ICE on valid code when using boost::bind

[weary at gamebox dot net]

* 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-20050502/bin/g++ -I/usr/local/include/boost-1_32 -c -o test.o 
test.cpp

* the compiler output (error messages, warnings, etc.); and
test.cpp: In constructor `definition::definition()':
test.cpp:16: internal compiler error: in build_ptrmemfunc, at cp/typeck.c:5548
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

* the preprocessed file (*.i*) that triggers the bug
see attachment

-- 
   Summary: ICE on valid code when using boost::bind
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: weary at gamebox dot net
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21337

[Bug c++/21337] ICE on valid code when using boost::bind

[weary at gamebox dot net]

--- 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=8794&action=view)
the file that doesn't compile


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21337

[Bug ada/21338] New: gcc with -c -gnatc and -gnatt generates Stack Overflow

[karl at grebyn dot com]

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

  An_Prefix   : constant String := "An_Prefix";
  Al_Prefix   : constant String := "Al_Prefix";

end Toplevel.Intermediate;
with Toplevel.Intermediate;

package Toplevel.Midlevel is

  Al_Prefix : String renames Toplevel.Intermediate.Al_Prefix;
  An_Prefix : String renames Toplevel.Intermediate.An_Prefix;

end Toplevel.Midlevel;
package Toplevel.Midlevel.Bottom is

   function Blank return Boolean;

end Toplevel.Midlevel.Bottom;

8:23 1290 submit: mkdir /tmp/jjj
8:24 1291 submit: cat *.ads > /tmp/jjj/files
8:24 1292 submit: cd /tmp/jjj
8:24 1293 jjj: l
total 4
-rw-r--r--  1 karl karl 502 May  2 08:24 files
8:24 1294 jjj: gnatchop files
splitting files into:
   toplevel.ads
   toplevel-intermediate.ads
   toplevel-midlevel.ads
   toplevel-midlevel-bottom.ads
8:24 1295 jjj: l
total 20
-rw-r--r--  1 karl karl 502 May  2 08:24 files
-rw-r--r--  1 karl karl  35 May  2 08:24 toplevel.ads
-rw-r--r--  1 karl karl 158 May  2 08:24 toplevel-intermediate.ads
-rw-r--r--  1 karl karl 207 May  2 08:24 toplevel-midlevel.ads
-rw-r--r--  1 karl karl 102 May  2 08:24 toplevel-midlevel-bottom.ads
8:24 1296 jjj: !gcc
gcc -c -gnatc -gnatt *.ads
+===GNAT BUG DETECTED==+
| 4.0.1 20050430 (prerelease) (i686-pc-linux-gnu) Storage_Error stack overflow
(or erroneous memory access)|
| Error detected at system.ads:151:5   |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

toplevel-midlevel-bottom.ads
toplevel-midlevel.ads
toplevel.ads
toplevel-intermediate.ads

compilation abandoned
8:24 1297 jjj: . ~/.cshrc.new
8:25 1298 jjj: which gcc
/home/karl/gcc-4.1-20050501/bin/gcc
8:25 1299 jjj: !gcc
gcc -c -gnatc -gnatt *.ads
+===GNAT BUG DETECTED==+
| 4.1.0 20050501 (experimental) (i686-pc-linux-gnu) Storage_Error stack overflow
(or erroneous memory access)|
| Error detected at system.ads:152:5   |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

toplevel-midlevel-bottom.ads
toplevel-midlevel.ads
toplevel.ads
toplevel-intermediate.ads

compilation abandoned
8:25 1300 jjj: gcc -c -gnatc *.ads
8:26 1301 jjj: gcc -c *.ads
cannot generate code for file toplevel-midlevel-bottom.ads (package spec)
to check package spec for errors, use -gnatc
8:26 1302 jjj: gcc -c -gnatt *.ads
cannot generate code for file toplevel-midlevel-bottom.ads (package spec)
to check package spec for errors, use -gnatc
8:26 1303 jjj:

-- 
   Summary: gcc with -c -gnatc and -gnatt generates Stack Overflow
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: karl at grebyn dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21338

[Bug c++/21337] [3.4 Regression] ICE on valid code when using boost::bind

[pinskia at gcc dot gnu dot org]

--- 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

   Keywords||ice-on-valid-code
  Known to work||3.4.0 4.0.0 4.1.0
Summary|ICE on valid code when using|[3.4 Regression] ICE on
   |boost::bind |valid code when using
   ||boost::bind
   Target Milestone|--- |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21337

[Bug target/21297] [4.0/4.1 Regression] buf[i+i]=0 stores buf[i] when -O2

[jakub at gcc dot gnu dot org]

--- 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   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
  Component|middle-end  |target
   Last reconfirmed|2005-04-30 16:00:20 |2005-05-02 13:04:19
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21297

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[jkanze at cheuvreux dot com]

--- 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 one.  At some point, I read
somewhere that G++ didn't want to support multiple accesses
from different threads, even if there was no modification.
I'd mentionned this in various news groups, and Gabriel
Dos Reis took me to the task: he said that if there was no
modification in either thread, I should submit it as a bug.

I guess my real question is the same one with which the
previous bug ended: is this an error, or is this the intended
behavior. If it is an error in the code, then it needs correcting
not only in the code, but in the text which I cited from the library
FAQ.  (If it is the intended behavior, of course, you're going to
hear a lot of complaints from those of us used to the Posix
model:-).)

--
James

"This message, including any attachments may contain confidential and
privileged material; it is intended only for the person to whom it is
addressed. Its contents do not constitute a commitment by Credit Agricole
Cheuvreux except where provided for in a written agreement. Credit Agricole
Cheuvreux assumes no liability or responsibility for the consequences
arising out of a delay and/or loss in transit of this message, or for
corruption or other error(s) arising in its transmission and for any misuse
or fraudulent use which may be made thereof. If you are not the intended
recipient, please contact us and abstain from any disclosure, use or
dissemination. To the extent that this message contains research
information and/or recommendations, these are provided on the same basis as
Credit Agricole Cheuvreux's published research and the recipient must have
regard to all disclosures and disclaimers contained therein."






-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[gdr at integrable-solutions dot net]

--- 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 don't see much value in keeping open both.

I don't see much value in discarding either of them.  Both provide
complimentary information and analysis.  Whatever you do, do make sure
that none of them disappear.  I would have preference to keep this one
open because it raises another question regarding our documentation.

| Ok? 2- I'm not aware of any real cure for
| this kind of problems within a RC implementation. Are you?

Beside death to COW? ;->

| For what is worth,
| in the v7-branch there is already a basic_string framework for flexible memory
| management policies and I have already prototyped an additional policy not 
using
| RC at all. I'm planning to add it the repository very soon. This is stuff that
| breaks the 3.4/4.0 ABI of course, but if people want it we can envisage 
providing
| it as an extension in future 4.0.x releases.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[jkanze at cheuvreux dot com]

--- 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 case, I'd go for this one.  It mentions one of the
places where g++ documentation suggests that this shouldn't
work.  And it mentions the Posix standard as an argument as to
why it should.

|> 2- I'm not aware of any real cure for this kind of problems
|> within a RC implementation. Are you?

pthread_mutex_lock:-).  Of course, performance will take a
serious hit.

--
James Kanze  mailto:[EMAIL PROTECTED]
Conseils en informatique orientée objet/
   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

"This message, including any attachments may contain confidential and
privileged material; it is intended only for the person to whom it is
addressed. Its contents do not constitute a commitment by Credit Agricole
Cheuvreux except where provided for in a written agreement. Credit Agricole
Cheuvreux assumes no liability or responsibility for the consequences
arising out of a delay and/or loss in transit of this message, or for
corruption or other error(s) arising in its transmission and for any misuse
or fraudulent use which may be made thereof. If you are not the intended
recipient, please contact us and abstain from any disclosure, use or
dissemination. To the extent that this message contains research
information and/or recommendations, these are provided on the same basis as
Credit Agricole Cheuvreux's published research and the recipient must have
regard to all disclosures and disclaimers contained therein."






-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[pcarlini at suse dot de]

--- 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   |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-02 13:31:44
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[pcarlini at suse dot de]

--- 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

 CC||jkanze at caicheuvreuse dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

[Bug libstdc++/10350] thread-safety problem in std::string.

[pcarlini at suse dot de]

--- 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

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10350

[Bug target/21297] [4.0/4.1 Regression] buf[i+i]=0 stores buf[i] when -O2

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-05-02 13:42 
---
Patch here: 

-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21297

Gcc 4.0.0 on NCR

[Bruzzone Mirko]

 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 stamp-picdir
 
make: fatal error: don't know how to make ./../include/ansidecl.h (bu42).
*** Error code 1 (bu21)
 
make: fatal error.
 
 
Could you help me?
 
Thank you very much.
 
___
Primeur System Integration s.r.l. (Italy - Genoa)
 
Mirko Bruzzone
+390102781259
[EMAIL PROTECTED]
http://www.primeur.com
___

[Bug bootstrap/21268] [4.0/4.1 Regression] Bootstrap, configuration problem and insn-conditions.c

[pinskia at gcc dot gnu dot org]

--- 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

[Bug tree-optimization/21294] Missed removal of null pointer check

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-02 
13:54 ---
Patch posted here: .

-- 
   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||05/msg00076.html
   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21294

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[gdr at integrable-solutions dot net]

--- 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 
---
| Ok, thanks, let's keep open this one, then.
| 
| -- 
|What|Removed |Added
| 
|Severity|minor   |enhancement

Isn't this a bug as opposed to "enhancement"?  Enhancement suggests
that the behaviour is basically correct, but could be improved. 

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

[Bug c++/21339] New: [3.4 regression] ICE with pointer to member in template

[reichelt at gcc dot gnu dot org]

The testcase in PR 15875 started ICE'ing on the 3.4 branch again:

==
struct A
{
void foo();
};

template void bar()
{
typedef void (A::*fptr)();
fptr ptr = &A::foo;
}
==

bug.c: In function `void bar()':
bug.c:9: internal compiler error: in build_ptrmemfunc, at cp/typeck.c:5548
Please submit a full bug report, [etc.]

Mark, this is most probably due to the fix for PR18464.
Could you please have a look?

The testcase doesn't seem to be in the testsuite.
It should probably be added.

-- 
   Summary: [3.4 regression] ICE with pointer to member in template
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mmitchel at gcc dot gnu
dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21339

[Bug middle-end/20794] [4.0/4.1 Regression] Arrays and pointer arithmetic on __attribute ((aligned)) types permitted

[dorit at il dot ibm dot com]

--- 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

[Bug c++/21337] [3.4 Regression] ICE on valid code when using boost::bind

[pinskia at gcc dot gnu dot org]

--- 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||21339


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21337

[Bug c++/21339] [3.4 regression] ICE with pointer to member in template

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21337
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21339

[Bug c++/21339] [3.4 regression] ICE with pointer to member in template

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to work||3.4.3 4.1.0 4.0.0
   Target Milestone|--- |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21339

[Bug c++/21337] [3.4 Regression] ICE on valid code when using boost::bind

[pinskia at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21337

[Bug c++/21339] [3.4 regression] ICE with pointer to member in template

[pinskia at gcc dot gnu dot org]

--- 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

 CC||weary at gamebox dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21339

[Bug c++/21339] [3.4 regression] ICE with pointer to member in template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-02 
14:19 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-02 14:19:10
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21339

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[pcarlini at suse dot de]

--- 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

[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|REOPENED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089

[Bug libfortran/21324] #undef GFC_CLEAR_MEMORY causes testsuite failures

[tkoenig at gcc dot gnu dot org]

--- 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=8801&action=view)
Proposed patch


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21324

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[gdr at gcc dot gnu dot org]

--- 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

   Severity|enhancement |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

[Bug libfortran/18958] [4.0 only] eoshift segfaults when shifting off the end of an array

[tkoenig at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||4.0.0
  Known to work||4.1.0
Summary|eoshift segfaults when  |[4.0 only] eoshift segfaults
   |shifting off the end of an  |when shifting off the end of
   |array   |an array
   Target Milestone|--- |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18958

[Bug c++/19991] [3.4 regression] Enum not accepted in array-size

[cvs-commit at gcc dot gnu dot org]

--- 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 : ChangeLog init.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/parse: constant7.C 

Log message:
Backport:
2005-02-22  Mark Mitchell  <[EMAIL PROTECTED]>
PR c++/19991
* g++.dg/parse/constant7.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.214&r2=1.3892.2.215
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.356.2.17&r2=1.356.2.18
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.387&r2=1.3389.2.388
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/constant7.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.28.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19991

[Bug c++/19991] [3.4 regression] Enum not accepted in array-size

[mmitchel at gcc dot gnu dot org]

--- 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|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19991

[Bug bootstrap/21335] bootstrap fails with CFLAGS="-O3 -ftree-vectorize"

[dorit at il dot ibm dot com]

--- 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 error

which seems to happen during tree-if-conversion:

(gdb)
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x000cbe00 in clean_predicate_lists (loop=0x4144fda0) at ../../gcc/gcc/tree-if-
conv.c:654
654 bb[i]->aux = NULL;
(gdb) backtrace
#0  0x000cbe00 in clean_predicate_lists (loop=0x4144fda0) at ../../gcc/gcc/tree-
if-conv.c:654
#1  0x000caf0c in tree_if_conversion (loop=0x4d78b8, for_vectorizer=16 '\020') 
at ../../gcc/gcc/tree-if-conv.c:205
#2  0x000ccbf0 in main_tree_if_conversion () at ../../gcc/gcc/tree-if-
conv.c:1116
#3  0x00065874 in execute_one_pass (pass=0x17311d0) at ../../gcc/gcc/tree-
optimize.c:578
#4  0x00065958 in execute_pass_list (pass=0x4b7f2c) at ../../gcc/gcc/tree-
optimize.c:615
#5  0x00065970 in execute_pass_list (pass=0x4b7cb0) at ../../gcc/gcc/tree-
optimize.c:616
#6  0x00065970 in execute_pass_list (pass=0x4b74f0) at ../../gcc/gcc/tree-
optimize.c:616
#7  0x00065c34 in tree_rest_of_compilation (fndecl=0xb7915c) 
at ../../gcc/gcc/tree-optimize.c:728
#8  0xe60c in c_expand_body (fndecl=0xde0bc8) at ../../gcc/gcc/c-decl.c:6411
#9  0x002f7998 in cgraph_expand_function (node=0xde0bc8) 
at ../../gcc/gcc/cgraphunit.c:924
#10 0x002f7ac4 in cgraph_expand_all_functions () 
at ../../gcc/gcc/cgraphunit.c:988
#11 0x002f7e0c in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1090
#12 0x002a6ad4 in compile_file () at ../../gcc/gcc/toplev.c:1013
#13 0x002a8a80 in do_compile () at ../../gcc/gcc/toplev.c:2123
#14 0x002a8b04 in toplev_main (argc=43, argv=0xb868) 
at ../../gcc/gcc/toplev.c:2155
#15 0x1df0 in _start (argc=43, argv=0xb868, envp=0xb918) 
at /SourceCache/Csu/Csu-47/crt.c:267
#16 0x8fe1a558 in __dyld__dyld_start ()
(gdb) 


-- 
   What|Removed |Added

 CC||dpatel at apple dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21335

[Bug c++/21339] [3.4 regression] ICE with pointer to member in template

[mark at codesourcery dot com]

--- 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 probably due to the fix for PR18464.

It is indeed.

> Could you please have a look?

In progress.

> The testcase doesn't seem to be in the testsuite.
> It should probably be added.

Yes, I'll add it in the process of figuring out what to do here.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21339

[Bug c++/21339] [3.4 regression] ICE with pointer to member in template

[mmitchel at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21339

[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

[dnovillo at redhat dot com]

--- 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 applied, the Ada bootstrap failure on
> i386-pc-solaris2.10 remains unchanged, a regression from 4.0:
> 
Would you mind filing a separate PR?  This is a different
problem.  The Ada FE is emitting a seemingly always-false
predicate that is causing VRP to create an invalid range
(http://gcc.gnu.org/ml/gcc/2005-05/msg00049.html).


Thanks.  Diego.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030

[Bug bootstrap/21268] [4.0/4.1 Regression] Bootstrap, configuration problem and insn-conditions.c

[v dot haisman at sh dot cvut dot cz]

--- 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 wrote:

>
> --- 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
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21268

[Bug c++/15875] [3.4/4.0 Regression] rejects pointer to member in template

[cvs-commit 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:
gcc/testsuite/g++.dg/template: ptrmem14.C 

Log message:
PR c++/15875
* g++.dg/template/ptrmem14.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5425&r2=1.5426
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ptrmem14.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15875

[Bug c++/15875] [3.4/4.0 Regression] rejects pointer to member in template

[cvs-commit at gcc dot gnu dot org]

--- 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  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: ptrmem14.C 

Log message:
PR c++/15875
* g++.dg/template/ptrmem14.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.152&r2=1.5084.2.153
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ptrmem14.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15875

[Bug bootstrap/21268] [4.0/4.1 Regression] Bootstrap, configuration problem and insn-conditions.c

[v dot haisman at sh dot cvut dot cz]

--- 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, pinskia at gcc dot gnu dot org wrote:

>
> --- 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
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21268

[Bug target/21277] Runtime error with C++ shared library and --disable-shared

[ebotcazou at gcc dot gnu dot org]

--- 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 successfully used it. Should
> there be any problems?

Theoritically there should be exactly one EH machinery linked in the executable,
hence the need for one shared libgcc when there are other shared libraries
involved.  In practice, if only one shared library has its private EH machinery
and if others don't, that may still work.

See in the manual the section about -shared-libgcc/-static-libgcc.

> By the way, all these tricks were found googling reports of other people who
> wanted to link statically.

We should probably add links to Google in the manual. :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[rittle at latour dot waar dot labs dot mot dot com]

--- 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 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.

Firstly, POSIX says nothing about C++ thus my confusion starts here.
Secondly, it is clear that your bug report is hypothetical.  The
library maintainers do not typically deal in hypotheticals.

>For the record, the statement in Posix is: "Applications shall
>ensure that access to any memory location by more than one
>thread of control (threads or processes) is restricted such that
>no thread of control can read or modify a memory location while
>another thread of control may be modifying it."  The obvious
>extension to C++ is that of replacing "memory location" with
>"object"; at the very least, of course, one can only require
>something of "memory locations" which the user sees, directly or
>indirectly.

OK.

>The statement in the libstdc++-v3 FAQ (question
>5.6) is: "All library objects are safe to use in a multithreaded
>program as long as each thread carefully locks out access by any
>other thread while it uses any object visible to another thread,
>i.e., treat library objects like any other shared resource. In
>general, this requirement includes both read and write access to
>objects; unless otherwise documented as safe, do not assume that
>two threads may access a shared standard library object at the
>same time."

OK, I seem to recall editing that statement at one point...

>A considerably weaker guarantee than what one
>normally expects under Posix.  (Note that the clause "like any
>other shared resource" is simply false for those of us used to
>the Posix model.  If I replace std::string with char[] in my
>code below, the behavior is perfectly defined under Posix.)

No, confusion.  We are guaranteeing that if you lock the visible
accesses to global or otherwise shared objects, that no POSIX
threading rule will be violated within our own library code.  We are
saying that we guarantee that any internal shared objects (which may
not be visible to the user, thus not lockable by the user) will be
correctly handled per POSIX threading rules.

>The following is an example of a program which may cause
>problems:
>
>#include 
>#include 
>#include 
>#include 
>
>std::string g ;

Please note that g is a global object which you have shared between
two tasks.  Thus the words in the FAQ are operative unless another
guarantee is documented as operative.

>extern "C" void*
>thread1(
>void*   lock )
>{
>std::string t( g ) ;

This is read access of shared, global g thus incorrect usage according
to the general contract that we offered you.

>pthread_mutex_lock( static_cast< pthread_mutex_t* >( lock ) ) ;
>std::cout << t << '\n' ;
>pthread_mutex_unlock( static_cast< pthread_mutex_t* >( lock ) ) ;
>return NULL ;
>}
>
>extern "C" void*
>thread2(
>void*   lock )
>{
>std::string t( g.begin(), g.end() ) ;

This is read access of shared, global g thus this is incorrect usage
according to the general contract that we offered you.

There may or may not be additional documentation covering the
std::string<> implementation which implies that the above usage should
work.  In fact, I think there is such documentation.  However, you
should refer to that documentation not the general FAQ about all other
library objects.

>pthread_mutex_lock( static_cast< pthread_mutex_t* >( lock ) ) ;
>std::cout << t << '\n' ;
>pthread_mutex_unlock( static_cast< pthread_mutex_t* >( lock ) ) ;

I note that you used the correct idiom implied by the FAW to lock
shared access to the gloabl std::cout.  Why do you consider g to be
different?

>return NULL ;
>}
>
>int
>main()
>{
>g = "0123456789" ;
>pthread_mutex_t lock ;
>pthread_mutex_init( &lock, NULL ) ;
>pthread_t   t1 ;
>if ( pthread_create( &t1, NULL, &thread1, &lock ) != 0 ) {
>std::cerr << "Could not create thread1" << std::endl ;
>}
>pthread_t   t2 ;
>if ( pthread_create( &t2, NULL, &thread2, &lock ) != 0 ) {
>std::cerr << "Could not create thread}
>pthread_join( t1, NULL ) ;
>pthread_join( t2, NULL ) ;
>return 0 ;
>}
>
>Consider the following scenario:
>
> -- Thread 2 executes first.  It gets to the expression
>g.begin() (which for purposes of argument, we will suppose
>is called before g.end() -- the problem will occur in which
>ever function is called first), and starts executing 

[Bug tree-optimization/20947] [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:394 with -ftree-vectorize

[dorit at il dot ibm dot com]

--- 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?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947

[Bug c++/21274] SSA Crash, reproducable

[dorit at il dot ibm dot com]

--- 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 reproduce it with these snapshots. Maybe the problem 
had already been solved. Just FYI, I get:
"
pr21274.cc:11: note: Alignment of access forced using peeling.
pr21274.cc:11: note: LOOP VECTORIZED.

pr21274.cc:26: note: not vectorized: pointer access is not simple.
pr21274.cc:26: note: not vectorized: unhandled data ref: *D.1981_38 = 1.0e+0

pr21274.cc:21: note: vectorized 1 loops in function.
"

Which means we don't try to peel the loop in line 26 anymore (from your report 
it looks like we used to peel that loop with the snapshot you are using:
"crash-4.0.cc:26: note: Alignment of access forced using peeling.crash-4.0.cc")

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21274

[Bug libfortran/18122] [4.0 only] gfortran internal error in namelist read

[doko at cs dot tu-berlin dot de]

--- 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 namelist modifications implemented over the last week have resulted in 
> namelist io that is compliant with the standard and this bug is fixed, as of 
> GCC 4.1.0 20050423.

The bug report is titled "[4.0 only]". Are the changes backported to
the 4.0 branch?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18122

[Bug c++/21340] New: error in constructor lookup (can't find constructor with "const void**" argument)

[benoit at zeroc dot com]

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 'IteratorI::IteratorI()':
Main.cpp:31: error: no matching function for call to 'Iterator::Iterator(const 
void**)'
Main.cpp:6: note: candidates are: Iterator::Iterator()
Main.cpp:6: note: Iterator::Iterator(const Iterator&)

I don't understand why it's looking up this constructor, the code doesn't 
contain any reference to it. I'm 
also getting a segmentation fault of the compiler with similar code (see the 
code sample below). Here's 
a small test case demonstrating the problem(s):

-
class Base
{
};

class Iterator : virtual public Base
{
};
bool operator==(const Iterator&, const Iterator&);

class IteratorI : public Iterator
{
};

class Obj
{
bool operator==(const Obj&) const { return true; }
};

template 
bool dummy(const Obj& lhs, const Obj& rhs)
{
const Obj* lhsKey = &lhs;
const Obj* rhsKey = &rhs;
return *lhsKey == *rhsKey;
}

int 
main(int argc, char** argv)
{
// G++ segfault with the following line uncommented
//Iterator* it1 = new Iterator();

// error: no matching function for call to 'Iterator::Iterator(const 
void**)'
IteratorI* it2 = new IteratorI(); 
}
-

The output of 'g++ -v -save-temps Main.cpp':

-
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-threads --prefix=/opt/gcc-4.0.0
Thread model: posix
gcc version 4.0.0
 /opt/gcc-4.0.0/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -E -quiet -v 
-D_GNU_SOURCE 
Main.cpp -mtune=pentiumpro -fpch-preprocess -o Main.ii
ignoring nonexistent directory 
"/opt/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-
linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0
 
/opt/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu
 
/opt/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backward
 /usr/local/include
 /opt/gcc-4.0.0/include
 /opt/gcc-4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/include
End of search list.
 /opt/gcc-4.0.0/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -fpreprocessed 
Main.ii -quiet 
-dumpbase Main.cpp -mtune=pentiumpro -auxbase Main -version -o Main.s
GNU C++ version 4.0.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64389
Main.cpp: In constructor 'IteratorI::IteratorI()':
Main.cpp:31: error: no matching function for call to 'Iterator::Iterator(const 
void**)'
-

-- 
   Summary: error in constructor lookup (can't find constructor with
"const void**" argument)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benoit at zeroc dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21340

[Bug c++/21274] SSA Crash, reproducable

[callahan at sci dot utah dot edu]

--- 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 recommend have someone run it on a recent x86-64 and if it's not a
problem there then just close out the bug.


[EMAIL PROTECTED]:/tmp$ g++-4.0 -msse2 -O3 -ftree-vectorize
-ftree-vectorizer-verbose=5 -c testcast.o testcast.cc
g++-4.0: testcast.o: No such file or directory

testcast.cc:11: note: Alignment of access forced using peeling.
testcast.cc:11: note: LOOP VECTORIZED.
testcast.cc:26: note: not vectorized: pointer access is not simple.
testcast.cc:26: note: not vectorized: unhandled data ref: *D.1981_38 = 1.0e+0
testcast.cc:21: note: vectorized 1 loops in function.
[EMAIL PROTECTED]:/tmp$ g++-4.0 --version
g++-4.0 (GCC) 4.0.0 20050301 (prerelease) (Debian 4.0-0pre6ubuntu7)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21274

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[gdr at integrable-solutions dot net]

--- 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 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 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.
| 
| Firstly, POSIX says nothing about C++

That statement is correct.  However, we have also taken step to tell
users to specify the threading model the compiler, therefore the
library, is to be built with.  Therefore, we have created
expecttations.  We can't reasonably go and tell users that C++
standard does not say anything about threading, so we would be right
to do whatever we like.  
Either we decide to ignore threading completely, or we take the more
useful apporach (as we've done so far) and take reports seriously.
You have a long standing record to take these issues seriously and I'm
glad you're weighting in.

| Secondly, it is clear that your bug report is hypothetical.  The
| library maintainers do not typically deal in hypotheticals.

thread-safety issues are hard to debug/reproduce, so some amounts of 
reasoning "in abstract" is necessary -- I would not go far as calling
it hypotheticals.  What I told James was that it would very much
appreciated if he could give a testcase that reproduces or is likely
to reproduce the problem -- acknowledging the fact that it may be hard
to get all the circumstances right simultaneously in order to trigger
the problem.

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.  When I read similar claims from
James, I could not help but suggest that he make a PR if he found that
to be true.  Which is how we're here.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

[Bug target/21325] [4.0 Regression] libjava should be re-enabled for ppc-darwin

[mckinlay at redhat dot com]

--- 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

[Bug tree-optimization/17116] Missed jump threading/bypassing optimization with loop and % (or ands)

[law at redhat dot com]

--- 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 dot gnu dot org  2005-05-01 
> 16:29 ---
> We now get:
> main ()
> {
>   int i.8;
>   int i;
> 
> :
> Invalid sum of outgoing probabilities 0.0%
>   i = 0;
>   i.8 = i + 1;
> 
> Invalid sum of outgoing probabilities 98.9%
> :;
>   if ((i.8 & 1) != 0) goto ; else goto ;
> 
> :;
>   puts (&"hello"[0]);
> 
> Invalid sum of incoming frequencies 9813, should be 1
> :;
>   i.8 = i.8 + 1;
>   if (i.8 != 90) goto ; else goto ;
> 
> :;
>   return;
> 
> }
Right.  I mentioned earlier that what we need to figure out whether
or not we want to allow the threader to keep threading the loop backedge
over and over and over.

Conceptually we should since potentially it makes the whole loop go
away.  The problem is that doing so can result in a huge compile-time
explosion.  I've got some ideas to deal with the compile-time explosion
but I haven't tested them yet.

Jeff




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17116

[Bug libstdc++/21251] Placement into shared memory

[mronell at alumni dot upenn dot edu]

--- 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 1
  instantiates  objects  into  shared memory,  these  instantiated
  objects can not necessarily be accessed by process 2 because the
  vtable  class definitions will  not necessarily  be at  the same
  address in both processes.

So given  the assumption  above, is a  share memory allocator  for the
Standard  Template  Library  (STL)  containers  still  possible?   For
example,  let process  1 create  a vector  my_vect where  A  is a
working shared  memory allocator  and T is  a valid  class definition.
The allocator A,  is assumed to correctly allocate  and recycle memory
from an validly  open shared memory segment.  After  process 1 defines
and populates my_vect with objects  of type T, let process 2 similarly
define a  vector using  its own  allocator A, defined  the same  as in
process 1.  The allocator, A,  in process 2 accesses the shared memory
segment in exactly the same way as in process 1.  The address space of
the shared memory segment is  mapped to the same virtual address space
in  both  processes.   If  the   objects  in  the  vector  which  were
instantiated  by process  1 all  point  to process  1's vtable,  won't
process  2 have  trouble accessing  the objects  created by  process 1
because  process  2 may  again  have  its  vtable classes  defined  at
different memory addresses?  How can process 2 make use of the objects
mapped into shared memory by  process 1?  Is a shared memory allocator
for the STL  possible given that object placement  in shared memory is
not possible?  What is the difference between the two concepts and why
does one work (shared memory  allocator) and one not work (placement)?
Can you  point me to a reference  which explains this concept  as I do
not understand.

I am probably missing something obvious.

Thank you,

Marc



-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug tree-optimization/21341] New: [4.1 Regression] gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times arr_base.[^0][^\n\r]*= 0 fails

[jsm28 at gcc dot gnu dot org]

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] gcc.dg/tree-ssa/loop-4.c scan-tree-
dump-times arr_base.[^0][^\n\r]*= 0 fails
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21341

[Bug tree-optimization/20947] [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:394 with -ftree-vectorize

[janis at gcc dot gnu dot org]

--- 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

[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string

[pcarlini at suse dot de]

--- 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 memory management policies (we are
very close to that in the v7-branch and I promise further progress during
the next months) I fail to properly appreciate the actual details of this issue:
which applications are actually penalized, which are the alternatives, something
more concrete, in other terms, that a vague reference to those "position" papers
that we all know, in other terms ;) (and one of those I'd like to discuss
in detail...) Maybe James can help here. In practice, we could, for instance,
*within the current ABI*, provide a switch to disable completely reference
counting, would that be appreciated? I can implement this very quickly but I'd
like to have some evidence that a non-trivial number of users would appreciate
that short-term solution. That would be indeed, a short term solution, because
a library relying purely on a non-refcounted string has subtle issues with
memory allocation during exceptions, that definitely we don't want in a long 
term solution: if nobody has got a better idea, I'm afraid we have to implement
also a separate ref-counted mini-string for usage in exceptions.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334

[Bug tree-optimization/21293] [4.0 Regression] ICE in set_value_handle

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-02 
17:15 ---
Subject: Bug 21293

CVSROOT:/cvs/gcc
Module name:gcc
Branch: apple-local-200502-branch
Changes by: [EMAIL PROTECTED]   2005-05-02 17:15:15

Modified files:
gcc: ChangeLog.apple-ppc tree-cfg.c tree-gimple.c 
gcc/fortran: trans-intrinsic.c 

Log message:
2005-05-02  Dale Johannesen  <[EMAIL PROTECTED]>

Radar 4102133  (PR 21293, Zdenek's patch)
* tree-cfg.c (find_taken_edge_cond_expr): Use zero_p instead of
integer_zerop.
* tree-gimple.c (is_gimple_min_invariant): Consider overflowed
constants invariant.
* fortran/trans-intrinsic.c (gfc_conv_intrinsic_ishft): Convert
the argument of the shift to the unsigned type.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.apple-ppc.diff?cvsroot=gcc&only_with_tag=apple-local-200502-branch&r1=1.1.4.57&r2=1.1.4.58
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&only_with_tag=apple-local-200502-branch&r1=2.149.4.2&r2=2.149.4.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-gimple.c.diff?cvsroot=gcc&only_with_tag=apple-local-200502-branch&r1=2.35&r2=2.35.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-intrinsic.c.diff?cvsroot=gcc&only_with_tag=apple-local-200502-branch&r1=1.43.6.1&r2=1.43.6.2



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21293