[Bug c++/33808] New: internal compiler error: in write_type, at cp/mangle.c:1651

[brakiozor at caramail dot com]

Hello,

I'm working on Dev-cpp this is the output :


Compiler: Default compiler
Building Makefile: "C:\cygwin\tmp\Makefile.win"
Executing  make...
make.exe -f "C:\cygwin\tmp\Makefile.win" all
g++.exe -c toto.cc -o toto.o -I"C:/GTK/INCLUDE"  -I"C:/GTK/INCLUDE/GTK-2.0" 
-I"C:/GTK/INCLUDE/GLIB-2.0"  -I"C:/GTK/INCLUDE/PANGO-1.0" 
-I"C:/GTK/INCLUDE/ATK-1.0"  -I"C:/GTK/INCLUDE/GTKGLEXT-1.0" 
-I"C:/GTK/LIB/GTK-2.0/INCLUDE"  -I"C:/GTK/LIB/GLIB-2.0/INCLUDE" 
-I"C:/GTK/LIB/GTKGLEXT-1.0/INCLUDE"  -I"C:/GTK/INCLUDE/LIBGLADE-2.0" 
-I"C:/GTK/INCLUDE/LIBXML2"  -v -save-temps  

Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.1.2/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=C:/MinGW --enable-threads
--disable-nls --enable-languages=c,c++ --disable-win32-registry
--disable-shared --enable-fully-dynamic-string --disable-libstdcxx-pch
Thread model: win32
gcc version 4.1.2
 c:/dev-cpp/bin/../libexec/gcc/mingw32/4.1.2/cc1plus.exe -E -quiet -v
-IC:/GTK/INCLUDE -IC:/GTK/INCLUDE/GTK-2.0 -IC:/GTK/INCLUDE/GLIB-2.0
-IC:/GTK/INCLUDE/PANGO-1.0 -IC:/GTK/INCLUDE/ATK-1.0
-IC:/GTK/INCLUDE/GTKGLEXT-1.0 -IC:/GTK/LIB/GTK-2.0/INCLUDE
-IC:/GTK/LIB/GLIB-2.0/INCLUDE -IC:/GTK/LIB/GTKGLEXT-1.0/INCLUDE
-IC:/GTK/INCLUDE/LIBGLADE-2.0 -IC:/GTK/INCLUDE/LIBXML2 -iprefix
c:\dev-cpp\bin\../lib/gcc/mingw32/4.1.2/ toto.cc -fpch-preprocess -o toto.ii

ignoring nonexistent directory
"c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/../../../../include/c++/4.1.2"
ignoring nonexistent directory
"c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/../../../../include/c++/4.1.2/mingw32"
ignoring nonexistent directory
"c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/../../../../include/c++/4.1.2/backward"
ignoring nonexistent directory
"c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/../../../../mingw32/include"
ignoring nonexistent directory
"C:/MinGW/lib/gcc/mingw32/../../../include/c++/4.1.2"
ignoring nonexistent directory
"C:/MinGW/lib/gcc/mingw32/../../../include/c++/4.1.2/mingw32"
ignoring nonexistent directory
"C:/MinGW/lib/gcc/mingw32/../../../include/c++/4.1.2/backward"
ignoring nonexistent directory "C:/MinGW/lib/gcc/mingw32/4.1.2/include"
ignoring nonexistent directory
"C:/MinGW/lib/gcc/mingw32/../../../mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/GTK/INCLUDE
 C:/GTK/INCLUDE/GTK-2.0
 C:/GTK/INCLUDE/GLIB-2.0
 C:/GTK/INCLUDE/PANGO-1.0
 C:/GTK/INCLUDE/ATK-1.0
 C:/GTK/INCLUDE/GTKGLEXT-1.0
 C:/GTK/LIB/GTK-2.0/INCLUDE
 C:/GTK/LIB/GLIB-2.0/INCLUDE
 C:/GTK/LIB/GTKGLEXT-1.0/INCLUDE
 C:/GTK/INCLUDE/LIBGLADE-2.0
 C:/GTK/INCLUDE/LIBXML2
 c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/../../../../include
 c:/dev-cpp/bin/../lib/gcc/mingw32/4.1.2/include
 C:/MinGW/lib/gcc/mingw32/../../../include
 C:/MinGW/include

 /mingw/include
End of search list.

 c:/dev-cpp/bin/../libexec/gcc/mingw32/4.1.2/cc1plus.exe -fpreprocessed toto.ii
-quiet -dumpbase toto.cc -auxbase-strip toto.o -version -o toto.s

GNU C++ version 4.1.2 (mingw32)
compiled by GNU C version 4.1.2.
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130982
Compiler executable checksum: 669e873dd1c794b0f5ddbea8fe211782
toto.cc:54: internal compiler error: in write_type, at cp/mangle.c:1651
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

make.exe: *** [toto.o] Error 1

Execution terminated


the same error occurs on cygwin (v 3.4.4) and on latest ubuntu (v 4.2?)

this is the code:

#include 

using namespace std;

template 
class X
{
public:
X() {}
};

template 
class Y
{
public:
template 
Y(const X&) {}

template 
Y& operator *=(const U&) { return *this; }
};

template 
Y operator *(X& x, const Ty& y)
{
Y res(x);
//res *= y;
return res;
}

template 
Y operator *(const Tx& x, X& y)
{
Y res(y);
//res *= x;
return res;
}

int main()
{
double a;
complex b;
X i;
X > j;

i*a;
a*i;
i*b;
b*i;

j*a;
a*j;
j*b;
b*j;
}


It's my first bug report, How can I give you the .ii file?


-- 
   Summary: internal compiler error: in write_type, at
cp/mangle.c:1651
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brakiozor at caramail dot com
 GCC build triplet: x86
  GCC host triplet: x86
GCC target triplet: x86


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

[Bug libfortran/30694] minval/maxval with +/-Inf

[fxcoudert at gcc dot gnu dot org]

--- Comment #25 from fxcoudert at gcc dot gnu dot org  2007-10-18 07:38 
---
(In reply to comment #24)
> So maybe approach the question differently.  Which element in an array of NaNs
> is the smallest one and what is its value?  If I pick any one element, its
> "value" is NaN.  It does not matter which one I select, its "value" always
> comes out NaN.

I understand your argument, but there are other arguments that are, I think, at
least equally valid and convincing. As I said, MINVAL basically ignores NaNs,
so an array containing only NaNs is equivalent to an empty array: its MINVAL is
+Huge. Note that having MINVAL = +Huge is, in itself, a telltale sign that
something is wrong, if there is no mask present.

Now, I have another question: what happens for mixed NaNs? For example, in your
scheme, what would be the value of MAXVAL((/sNaN, qNaN/))?


-- 


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

[Bug c++/33808] internal compiler error: in write_type, at cp/mangle.c:1651

[brakiozor at caramail dot com]

--- Comment #2 from brakiozor at caramail dot com  2007-10-18 07:56 ---
Created an attachment (id=14369)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14369&action=view)
.ii file


-- 


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

[Bug c++/33808] internal compiler error: in write_type, at cp/mangle.c:1651

[brakiozor at caramail dot com]

--- Comment #3 from brakiozor at caramail dot com  2007-10-18 08:06 ---
I found this bug on a more complex program and I did an epurated code.


-- 

brakiozor at caramail dot com changed:

   What|Removed |Added

 CC||brakiozor at caramail dot
   ||com


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

[Bug c++/33808] internal compiler error: in write_type, at cp/mangle.c:1651

[brakiozor at caramail dot com]

--- Comment #1 from brakiozor at caramail dot com  2007-10-18 07:55 ---
Created an attachment (id=14368)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14368&action=view)
source code

I was playing a little with template


-- 


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

[Bug tree-optimization/33804] ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize

[irar at il dot ibm dot com]

--- Comment #3 from irar at il dot ibm dot com  2007-10-18 08:33 ---
It works fine for me (and the loop gets SLPed) on powerpc-64 and x86_64.

Could you please run it with -fdump-tree-vect-details and attach the dump file?

Ira


-- 


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

[Bug c++/33808] internal compiler error: in write_type, at cp/mangle.c:1651

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-10-18 08:49 ---
As far as I understand there is no way to encode currently typeof for
templates.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics

[uros at gcc dot gnu dot org]

--- Comment #10 from uros at gcc dot gnu dot org  2007-10-18 09:12 ---
Subject: Bug 32961

Author: uros
Date: Thu Oct 18 09:12:30 2007
New Revision: 129433

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129433
Log:
PR target/32961
* config/i386/i386.c (ix86_expand_builtin) [IX86_BUILTIN_PSLLWI128,
IX86_BUILTIN_PSLLDI128, BUILTIN_PSLLQI128, IX86_BUILTIN_PSRAWI128,
IX86_BUILTIN_PSRADI128, IX86_BUILTIN_PSRLWI128,
IX86_BUILTIN_PSRLDI128, IX86_BUILTIN_PSRLQI128]: Do not require
immediate shift value.
* config/i386/emmintrin.h (_mm_slli_epi16, _mm_slli_epi32,
_mm_slli_epi64, _mm_srai_epi16, _mm_srai_epi32, _mm_srli_epi16,
_mm_srli_epi32, _mm_srli_epi64):  Enable disabled functions and
remove equivalent macro definitions.

testsuite/ChangeLog:

PR target/32961
* gcc.target/i386/pr32961.c: New testcase.


Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr32961.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/i386/emmintrin.h
branches/gcc-4_2-branch/gcc/config/i386/i386.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics

[ubizjak at gmail dot com]

--- Comment #11 from ubizjak at gmail dot com  2007-10-18 09:14 ---
Fixed for 4.2.3 and 4.3.0.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.3


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

[Bug libstdc++/33807] Incorrect ambiguous overload

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-18 09:35:14
   date||


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

[Bug c++/5645] gcc warns that pure virtual class not explicitly initialized

[nathan at codesourcery dot com]

--- Comment #5 from nathan at codesourcery dot com  2007-10-18 09:43 ---
Subject: Re:  gcc warns that pure virtual class not explicitly
 initialized

manu at gcc dot gnu dot org wrote:
> --- Comment #4 from manu at gcc dot gnu dot org  2007-10-17 11:26 ---
> Does this patch makes any sense? This needs testcases (suggestions for extra
> testcases are welcome), Changelog, bootstrap + testing and proper submission.

this patch looks reasonable.

nathan


-- 


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

[Bug libstdc++/33807] Incorrect ambiguous overload

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

   Target Milestone|--- |4.2.3


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

[Bug libstdc++/33807] Incorrect ambiguous overload

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-10-18 09:55 ---
Note, the problem - trivial, the same we had in stl_iterator.h - is latent in
the older branches, dates back to the configurable allocator.h. The fix is safe
and will go in 4_2-branch too.


-- 


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

[Bug libstdc++/33807] Incorrect ambiguous overload

[paolo at gcc dot gnu dot org]

--- Comment #2 from paolo at gcc dot gnu dot org  2007-10-18 10:00 ---
Subject: Bug 33807

Author: paolo
Date: Thu Oct 18 10:00:18 2007
New Revision: 129434

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129434
Log:
2007-10-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/33807
* include/bits/allocator.h (operator==(const allocator<_Tp>&,
const allocator<_Tp>&), operator!=(const allocator<_Tp>&,
const allocator<_Tp>&)): Add.
* testsuite/20_util/allocator/33807.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/allocator/33807.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/allocator.h


-- 


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

[Bug c/33809] New: Rounding off error in GCC 4.1.2

[satyaakam at yahoo dot co dot in]

Based on our investigation and the gcc documentation , we think there is a Bug
in GCC 4.1.2

Firstly, according to the doc and our understanding, the error caused by
rounding should be small, for instance, some systems may treat 5.000 as 4.998.
However, in our case, the difference is quit big, about 40% by compare
-0.7240616609 to -0.5413411329464. I think it can't be ignored.

Secondly, -frounding-math and -fno-rounding-math are two gcc options to control
rounding. However, using -O0, for both two options, We got the same value,
-0.7240616609. But using -O3 (or -O1), We got the same value, -0.5413411329464.
This means changing rounding option doesn't affect the result.

Thirdly, in the case, function double ahdlDoFloatDiv(double a, double) is to
return the result of a/b. If I directly use a/b, instead of function, for -O3,
the result is -0.7240616609, the same as -O0. If the issue is caused by
rounding, both two ways should have the same result. But now it is different.

Finally, we simplified the c code as below and can reproduce the problem:

#include 
#include 
#include 

double ahdlDoFloatDiv (double a, double b)
{
   return a/b;
}

// #define ahdlDoFloatDiv(a, b)  (a/b)

int main()
{
   double pow_tmp = 0;
   printf("%f\n",
   ahdlDoFloatDiv((2.7182818284590451)) +
(((ahdlDoFloatDiv-(((2.7182818284590451)) *
((1.e+00))) * 1.e+00))), 
pow_tmp = (2.7182818284590451)) * pow_tmp)) * (2.7182818284590451))
- (((ahdlDoFloatDiv(1.e+00, (2.7182818284590451)))
- 2.7182818284590451)) - (((ahdlDoFloatDiv-(((2.7182818284590451))
* ((1.e+00))) * 1.e+00))), 
pow_tmp = (2.7182818284590451)) * pow_tmp)) * (2.7182818284590451))
+ (((ahdlDoFloatDiv(1.e+00,
(2.7182818284590451,  pow_tmp = 2.7182818284590451)) -
(((ahdlDoFloatDiv(1.e+00, (2.7182818284590451 *
pow_tmp
   );
   return 0;
}

Please use gcc4.1.2 to compile it under Linux and you can reproduce the bug.
For -O3, the printed value is -0.541341, for -O0, it is -0.724062. If comment
the function ahdlDoFloatDiv  and uncomment the macro definition, both -O0 and
-O3 have the same result,  -0.724062.

This issue causes our problem to producing incorrect values, even lead to
convergence issue.


-- 
   Summary: Rounding off error in GCC 4.1.2
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in


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

[Bug c++/33810] New: gcc 4.1.2 mangles results on x86_64 in bitfield operations

[satyaakam at yahoo dot co dot in]

Run the test case on a x86_64 bit machine to see how gcc 4.1.2 mangles results
in under Linux

We have tested the test case using 3.2.3 Compiler on RHEL 3 on both 32 as well
as 64 bit OS it works well.

Compile the test case provided with the following steps

$gcc -g -I. -Wall -m64 -c bar.c
$g++ -g -I. -Wall -m64 -o foo foo.c bar.o

Actual results: once you run the program foo you will see the following result

foo: i is 3.
bar: i is 3221205968.

Expected results:

foo: i is 3.
bar: i is 3.

Additional info: Test Case follows


- bar.h -

typedef struct {

 unsigned b1:16;

 unsigned b2:16;

} foo;



#ifdef   __cplusplus

extern "C"

{

#endif



foo bar(unsigned);



#ifdef   __cplusplus

}

#endif




- bar.c -

#include 

#include 



foo bar(unsigned i)

{

 foo myfoo;

 myfoo.b1=myfoo.b2=0;

 printf("bar: i is %u.\n",i);

 return(myfoo);

}





- foo.c -

#include 
#include 

int main(void)

{

 foo myfoo;

 unsigned i = 3;

 printf("foo: i is %u.\n",i);

 myfoo = bar(i);

 return 0;

}


-- 
   Summary: gcc 4.1.2 mangles results on x86_64 in bitfield
operations
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2007-10-18 11:45 
---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-10-07 15:17:20 |2007-10-18 11:45:39
   date||


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

[Bug fortran/33811] New: Character assignment misses dependency

[pault at gcc dot gnu dot org]

This
$ cat assign_bug_3.f90
  character(1) :: a(3) = ['1','2','3']
  integer :: i = 1
  a(2:3)(i:i) = a(1:2)(i:i)
  print *, a
end

$ /irun/bin/gfortran assign_bug_3.f90; ./a
 111

is the wrong result (should be 112)

The problem lies in gfc_check_dependency, where the assumption about substrings
is wrong.  Fixing this exposes an ICE in
trans-array.c(gfc_trans_create_temp_array), which arises because the temporary
is an incomplete type.

These problems are related to PR31217 and arose in the course of fixing that
pr.

A fix for both will be posted tonight, as long as the regtesting completes OK.

Cheers

Paul


-- 
   Summary: Character assignment misses dependency
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: pault at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org
 BugsThisDependsOn: 31217


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

[Bug fortran/31217] ICE using FORALL on character substrings

[pault at gcc dot gnu dot org]

-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-03-16 15:32:12 |2007-10-18 12:03:51
   date||


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

[Bug c/33809] Rounding off error in GCC 4.1.2

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2007-10-18 12:18 ---
What about -ffloat-store?


-- 


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

[Bug fortran/33811] Character assignment misses dependency

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2007-10-18 12:23:19
   date||


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

[Bug fortran/33733] ICEs in simplify_transfer

[pault at gcc dot gnu dot org]

--- Comment #11 from pault at gcc dot gnu dot org  2007-10-18 12:44 ---
Subject: Bug 33733

Author: pault
Date: Thu Oct 18 12:44:03 2007
New Revision: 129435

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129435
Log:
2007-10-18  Paul Thomas  <[EMAIL PROTECTED]>
Dominique d'Humieres  <[EMAIL PROTECTED]>

PR fortran/33733
* simplify.c (gfc_simplify_transfer): Return null if the source
expression is EXPR_FUNCTION.

2007-10-18  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/33733
* gfortran.dg/transfer_simplify_6.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/transfer_simplify_6.f90
Modified:
trunk/gcc/fortran/simplify.c


-- 


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

[Bug fortran/33733] ICEs in simplify_transfer

[pault at gcc dot gnu dot org]

--- Comment #12 from pault at gcc dot gnu dot org  2007-10-18 12:45 ---
Subject: Bug 33733

Author: pault
Date: Thu Oct 18 12:44:57 2007
New Revision: 129436

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129436
Log:
2007-10-18  Paul Thomas  <[EMAIL PROTECTED]>
Dominique d'Humieres  <[EMAIL PROTECTED]>

PR fortran/33733
* simplify.c (gfc_simplify_transfer): Return null if the source
expression is EXPR_FUNCTION.

2007-10-18  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/33733
* gfortran.dg/transfer_simplify_6.f90: New test.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33233] Parent and contained procedure: Wrongly treated as generic procedures

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2007-10-18 12:48 ---
Subject: Bug 33233

Author: pault
Date: Thu Oct 18 12:48:37 2007
New Revision: 129437

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129437
Log:
2007-10-18  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/33233
* resolve.c (check_host_association): Check singly contained
namespaces and start search for symbol in current namespace.

2007-10-18  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/33233
* gfortran.dg/host_assoc_function_1.f90: Correct references.
* gfortran.dg/host_assoc_function_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/host_assoc_function_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/host_assoc_function_1.f90


-- 


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

[Bug middle-end/33806] [regression 4.3] gfortran.dg/cray_pointers_2.f90 give an ICE at -O3 -m64 on Darwin

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2007-10-18 12:55 ---
This regression affects also
gfortran.fortran-torture/execute/stack_varsize.f90.
A reduced test case is:

! Program to test the stack variable size limit.
program stack
   call sub1
contains

   ! Local variables larger than 32768 in byte size shall be placed in static
   ! storage area, while others be put on stack by default.
   subroutine sub1
  real b(32768/4), c(32768/4+1) 
  b = 20.0
  c = 30.0
  if ((b(1) .ne. 20.0).or.(c(1) .ne. 30.0)) call abort
   end subroutine

end
[karma] f90/bug% gfc -m64 -O3 stack_varsize_red.f90
stack_varsize_red.f90: In function 'sub1':
stack_varsize_red.f90:12: internal compiler error: in change_address_1, at
emit-rtl.c:1888

Note that array c alone is not sufficient to trigger the ICE.


-- 


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

[Bug libfortran/22423] Warnings when building libgfortran

[fxcoudert at gcc dot gnu dot org]

--- Comment #14 from fxcoudert at gcc dot gnu dot org  2007-10-18 13:22 
---
(In reply to comment #13)
> ../../../libgfortran/runtime/environ.c:312: warning: 'init_choice' defined but
> not used
> ../../../libgfortran/runtime/environ.c:339: warning: 'show_choice' defined but
> not used

These two have been removed by Ben Elliston.

> ../../../libgfortran/runtime/backtrace.c:66: warning: 'local_strcasestr'
> defined but not used

Fixed by the following:

Index: runtime/backtrace.c
===
--- runtime/backtrace.c (revision 129403)
+++ runtime/backtrace.c (working copy)
@@ -60,7 +60,18 @@ Boston, MA 02110-1301, USA.  */
 #include 


+/* Macros for common sets of capabilities: can we fork and exec, can
+   we use glibc-style backtrace functions, and can we use pipes.  */
+#define CAN_FORK (defined(HAVE_FORK) && defined(HAVE_EXECVP) \
+ && defined(HAVE_WAIT))
+#define GLIBC_BACKTRACE (defined(HAVE_BACKTRACE) \
+&& defined(HAVE_BACKTRACE_SYMBOLS))
+#define CAN_PIPE (CAN_FORK && defined(HAVE_PIPE) \
+ && defined(HAVE_DUP2) && defined(HAVE_FDOPEN) \
+ && defined(HAVE_CLOSE))

+
+#if GLIBC_BACKTRACE && CAN_PIPE
 static char *
 local_strcasestr (const char *s1, const char *s2)
 {
@@ -85,14 +96,7 @@ local_strcasestr (const char *s1, const
 }
 #endif
 }
-
-#define CAN_FORK (defined(HAVE_FORK) && defined(HAVE_EXECVP) \
- && defined(HAVE_WAIT))
-#define GLIBC_BACKTRACE (defined(HAVE_BACKTRACE) \
-&& defined(HAVE_BACKTRACE_SYMBOLS))
-#define CAN_PIPE (CAN_FORK && defined(HAVE_PIPE) \
- && defined(HAVE_DUP2) && defined(HAVE_FDOPEN) \
- && defined(HAVE_CLOSE))
+#endif


 #if GLIBC_BACKTRACE


> ../../../libgfortran/runtime/main.c:179: warning: passing argument 1 of 'free'
> discards qualifiers from pointer target type

Fixed by:

Index: runtime/main.c
===
--- runtime/main.c  (revision 129403)
+++ runtime/main.c  (working copy)
@@ -176,5 +176,5 @@ cleanup (void)
   close_units ();

   if (please_free_exe_path_when_done)
-free (exe_path);
+free ((char *) exe_path);
 }


> ../../../../libgfortran/intrinsics/signal.c:201: warning: cast to pointer from
> integer of different size
> ../../../../libgfortran/intrinsics/signal.c:208: warning: cast to pointer from
> integer of different size
> ../../../../libgfortran/intrinsics/signal.c:229: warning: cast to pointer from
> integer of different size
> ../../../../libgfortran/intrinsics/signal.c:236: warning: cast to pointer from
> integer of different size

This should be silenced by:

Index: intrinsics/signal.c
===
--- intrinsics/signal.c (revision 129403)
+++ intrinsics/signal.c (working copy)
@@ -198,14 +198,14 @@ alarm_sub_int_i4 (int *seconds, int *han
 #if defined (SIGALRM) && defined (HAVE_ALARM) && defined (HAVE_SIGNAL)
   if (status != NULL)
 {
-  if (signal (SIGALRM, (void (*)(int)) *handler) == SIG_ERR)
+  if (signal (SIGALRM, (void (*)(int)) (INTPTR_T) *handler) == SIG_ERR)
*status = -1;
   else
*status = alarm (*seconds);
 }
   else
 {
-  signal (SIGALRM, (void (*)(int)) *handler);
+  signal (SIGALRM, (void (*)(int)) (INTPTR_T) *handler);
   alarm (*seconds);
 }
 #else
@@ -226,14 +226,14 @@ alarm_sub_int_i8 (int *seconds, int *han
 #if defined (SIGALRM) && defined (HAVE_ALARM) && defined (HAVE_SIGNAL)
   if (status != NULL)
 {
-  if (signal (SIGALRM, (void (*)(int)) *handler) == SIG_ERR)
+  if (signal (SIGALRM, (void (*)(int)) (INTPTR_T) *handler) == SIG_ERR)
*status = -1;
   else
*status = alarm (*seconds);
 }
   else
 {
-  signal (SIGALRM, (void (*)(int)) *handler);
+  signal (SIGALRM, (void (*)(int)) (INTPTR_T) *handler);
   alarm (*seconds);
 }
 #else


> ../../../libgfortran/intrinsics/spread_generic.c:136: warning: format '%d'
> expects type 'int', but argument 2 has type 'long int'
> ../../../libgfortran/intrinsics/spread_generic.c:147: warning: format '%d'
> expects type 'int', but argument 2 has type 'long int'

Fixed by:

Index: intrinsics/spread_generic.c
===
--- intrinsics/spread_generic.c (revision 129403)
+++ intrinsics/spread_generic.c (working copy)
@@ -131,9 +131,9 @@ spread_internal (gfc_array_char *ret, co

  if (ret_extent != ncopies)
runtime_error("Incorrect extent in return value of SPREAD"
- " intrinsic in dimension %d: is %ld,"
- " should be %ld", n+1, (long int) ret_extent,
- (long int) ncopies);
+ " intrinsic in dimension %ld: is %ld,"
+

[Bug tree-optimization/33812] New: Vectorizer testcases fail

[irar at il dot ibm dot com]

With current trunk (r129433) vectorizer testcases fail on powerpc64:

FAIL: gcc.dg/vect/vect-64.c (internal compiler error)
FAIL: gcc.dg/vect/vect-64.c (test for excess errors)
WARNING: gcc.dg/vect/vect-64.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-68.c (internal compiler error)
FAIL: gcc.dg/vect/vect-68.c (test for excess errors)
WARNING: gcc.dg/vect/vect-68.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-70.c (internal compiler error)
FAIL: gcc.dg/vect/vect-70.c (test for excess errors)
WARNING: gcc.dg/vect/vect-70.c compilation failed to produce executable
FAIL: gcc.dg/vect/no-scevccp-slp-31.c (internal compiler error)
FAIL: gcc.dg/vect/no-scevccp-slp-31.c (test for excess errors)
WARNING: gcc.dg/vect/no-scevccp-slp-31.c compilation failed to produce
executable

The tests ICE:
vect-64.c: In function גmain1ג:
vect-64.c:75: internal compiler error: in change_address_1, at emit-rtl.c:1888
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

#0  change_address_1 (memref=0xf7e44f40, mode=SImode, addr=0xf7e44f30,
validate=1) at ../../gcc/gcc/emit-rtl.c:1888
#1  0x10179fd4 in validize_mem (ref=0xf7e44f40) at ../../gcc/gcc/explow.c:546
#2  0x101a88e8 in emit_move_insn (x=0xf7e38e00, y=0xf7e44f40) at
../../gcc/gcc/expr.c:3403
#3  0x105543e4 in rs6000_emit_epilogue (sibcall=0) at
../../gcc/gcc/config/rs6000/rs6000.c:16095
#4  0x28000488 in ?? ()
#5  0x105ec5ec in gen_epilogue () at
../../gcc/gcc/config/rs6000/rs6000.md:14476
#6  0x102242b4 in rest_of_handle_thread_prologue_and_epilogue () at
../../gcc/gcc/function.c:5298
#7  0x102a7af4 in execute_one_pass (pass=0x108f6a78) at
../../gcc/gcc/passes.c:1117
#8  0x102a7d68 in execute_pass_list (pass=0x108f6a78) at
../../gcc/gcc/passes.c:1170
#9  0x102a7d80 in execute_pass_list (pass=0x108f6ee8) at
../../gcc/gcc/passes.c:1171
#10 0x102a7d80 in execute_pass_list (pass=0x108f6eb4) at
../../gcc/gcc/passes.c:1171
#11 0x103ae68c in tree_rest_of_compilation (fndecl=0xf7dbc100) at
../../gcc/gcc/tree-optimize.c:404
#12 0x105705fc in cgraph_expand_function (node=0xf7dbc300) at
../../gcc/gcc/cgraphunit.c:1060
#13 0x105728c4 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1123
#14 0x10017914 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8077
#15 0x1033fff0 in toplev_main (argc=, argv=) at ../../gcc/gcc/toplev.c:1055
#16 0x1009e370 in main (argc=0, argv=0x0) at ../../gcc/gcc/main.c:35

This doesn't happen with r129290.

Ira


-- 
   Summary: Vectorizer testcases fail
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
 GCC build triplet: powerpc64-suse-linux
  GCC host triplet: powerpc64-suse-linux
GCC target triplet: powerpc64-suse-linux


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

[Bug fortran/29452] Keyword check for specifiers in WRITE and READ

[fxcoudert at gcc dot gnu dot org]

--- Comment #10 from fxcoudert at gcc dot gnu dot org  2007-10-18 13:39 
---
I think it's best to close this one. I only wanted to keep it open because I
thought I'd add the rest of the F2003 specifiers quickly, which didn't happen.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/33812] Vectorizer testcases fail

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2007-10-18 13:40 ---
This seems to be a duplicate of PR33806, at least the ICE occurs at the same
point.


-- 


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

[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics

[hjl at lucon dot org]

--- Comment #12 from hjl at lucon dot org  2007-10-18 13:44 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Icc generates:
> >0:   66 0f 6e cf movd   %edi,%xmm1
> >4:   66 0f f2 c1 pslld  %xmm1,%xmm0
> 
> Right, that's what icc's documentation would suggest.  But that documentation
> seems inconsistent with the assembly reference guide.  It may be that the
> assembly reference guide is the one that's wrong, or that icc intentionally
> extends it.
> 

There is nothing wrong with IA32 SDM. One intrinsic does map to one
assembly instruction, but not necessarily the same instruction every
time. Another example is _mm_cmpistrm and its friends.


-- 


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

[Bug fortran/33233] Parent and contained procedure: Wrongly treated as generic procedures

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2007-10-18 13:54 ---
Fixed on trunk.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/33809] Rounding off error in GCC 4.1.2

[satyaakam at yahoo dot co dot in]

--- Comment #2 from satyaakam at yahoo dot co dot in  2007-10-18 14:00 
---
$gcc -ffloat-store round.c
$ ./a.out
-0.724062

$gcc -O3 -ffloat-store round.c
$ ./a.out
-0.541341

$gcc -O0 -ffloat-store round.c
./a.out
-0.724062


-- 


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

[Bug fortran/33733] ICEs in simplify_transfer

[pault at gcc dot gnu dot org]

--- Comment #13 from pault at gcc dot gnu dot org  2007-10-18 13:53 ---
Fixed on trunk

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/33812] Vectorizer testcases fail

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2007-10-18 14:32 ---
The same occurs in 32 bit mode, see for instance

http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00804.html

[karma] dominiq/Desktop% gfc -O2 -ftree-vectorize -maltivec
/opt/gcc/_gcc-clean/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c
 

/opt/gcc/_gcc-clean/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c:
In function 'main1':
/opt/gcc/_gcc-clean/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c:39:
internal compiler error: in change_address_1, at emit-rtl.c:1888


-- 


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

[Bug tree-optimization/33812] Vectorizer testcases fail

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2007-10-18 14:37 ---
The PR started between revisions 129388 (works) and 129401 (does not).


-- 


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

[Bug c/33809] Rounding off error in GCC 4.1.2

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-10-18 14:46 ---
Your code is undefined.  You have multiple assignments to pow_tmp without
intervening sequence points.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/33811] Character assignment misses dependency

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2007-10-18 14:50 ---
(In reply to comment #0)

> A fix for both will be posted tonight, as long as the regtesting completes OK.
> Cheers
> Paul

This fix has been posted: http://gcc.gnu.org/ml/fortran/2007-10/msg00264.html

Paul


-- 


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

[Bug middle-end/33780] different results between O3 and O0

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2007-10-18 15:23 ---
> while we expand a constant integral power to an optimal (as of the count of
> multiplications / additions) series of multiplications and additions.

It seems the difference is coming from something else. I'll bet that with -O3
the powers are computed at compile time with some extra precision. At least it
is what I conclude from the following code:

  integer :: ia(16) = (/ 1, 1, 2, 2, 3, 3, 4, 4, 6, 5, 6, 6, 10, 7, 9, 8 /)
  real(8) :: a(16), b(16), c(16), d(16)
  real(16) :: e(16)
  real(8), parameter :: r=4.51556282882533D0
  a(1) = r
  a(2) = a(1)*a(1)
  a(3:4) = a(2)*a(1:2)
  a(5:8) = a(4)*a(1:4)
  a(9:16) = a(8)*a(1:8)
  b(1) = r
  do i = 2, 16
 b(i) = b(ia(i))*b(i-ia(i))
  end do
  e(1) = r
  e(2) = e(1)*e(1)
  e(3:4) = e(2)*e(1:2)
  e(5:8) = e(4)*e(1:4)
  e(9:16) = e(8)*e(1:8)
  d = real(e,8)
  do i=1, 16
 c(i) = r**i
  end do
  do i=1, 16
 print *, a(i)/d(i)-1.0d0, b(i)/d(i)-1.0d0, c(i)/d(i)-1.0d0
  end do
  print *
  print *, sum(abs(a/d-1.0d0)), sum(abs(b/d-1.0d0)), sum(abs(c/d-1.0d0)),
epsilon(r)
end

a stores the powers computed from the usual shift, b those computed from the
"optimal" tree (from gcc/builtins.c, c those computed from the power, and d the
values rounded from values with higher precision. At -O2 the output is:

   0.0.0. 
   0.0.0. 
   0.0.0. 
  2.22044604925031308E-016  2.22044604925031308E-016  2.22044604925031308E-016
  2.22044604925031308E-016  2.22044604925031308E-016  2.22044604925031308E-016
  2.22044604925031308E-016   0.   2.22044604925031308E-016
  2.22044604925031308E-016  2.22044604925031308E-016  2.22044604925031308E-016
  4.44089209850062616E-016  4.44089209850062616E-016  4.44089209850062616E-016
  2.22044604925031308E-016   0.   2.22044604925031308E-016
  4.44089209850062616E-016  2.22044604925031308E-016  4.44089209850062616E-016
  4.44089209850062616E-016  2.22044604925031308E-016  4.44089209850062616E-016
  4.44089209850062616E-016   0.   4.44089209850062616E-016
  4.44089209850062616E-016  4.44089209850062616E-016  4.44089209850062616E-016
  4.44089209850062616E-016  2.22044604925031308E-016  4.44089209850062616E-016
  6.66133814775093924E-016   0.   6.66133814775093924E-016
  6.66133814775093924E-016  6.66133814775093924E-016  6.66133814775093924E-016

  5.10702591327572009E-015  2.88657986402540701E-015  5.10702591327572009E-015 
2.22044604925031308E-016

a and c are equal, while at -O3 the output is

   0.0.0. 
   0.0.0. 
   0.0.0. 
  2.22044604925031308E-016  2.22044604925031308E-016   0. 
  2.22044604925031308E-016  2.22044604925031308E-016   0. 
  2.22044604925031308E-016   0.0. 
  2.22044604925031308E-016  2.22044604925031308E-016   0. 
  4.44089209850062616E-016  4.44089209850062616E-016   0. 
  2.22044604925031308E-016   0.0. 
  4.44089209850062616E-016  2.22044604925031308E-016   0. 
  4.44089209850062616E-016  2.22044604925031308E-016   0. 
  4.44089209850062616E-016   0.0. 
  4.44089209850062616E-016  4.44089209850062616E-016   0. 
  4.44089209850062616E-016  2.22044604925031308E-016   0. 
  6.66133814775093924E-016   0.0. 
  6.66133814775093924E-016  6.66133814775093924E-016   0. 

  5.10702591327572009E-015  2.88657986402540701E-015   0.  
2.22044604925031308E-016

c and d are equal. If the difference were coming only from the "optimal" tree,
c should be equal to b.


-- 


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

[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1

[bkoz at gcc dot gnu dot org]

--- Comment #4 from bkoz at gcc dot gnu dot org  2007-10-18 15:23 ---
Subject: Bug 30085

Author: bkoz
Date: Thu Oct 18 15:22:58 2007
New Revision: 129442

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129442
Log:
2007-10-18  Benjamin Kosnik  <[EMAIL PROTECTED]>

* include/ext/hash_map: To...
* include/backward/hash_map: ...here. Remove debug mode.
* include/ext/hash_set: To...
* include/backward/hash_set: ...here. Remove debug mode.
* include/ext/hash_fun.h: To...
* include/backward/hash_fun.h: ...here.
* include/ext/hashtable.h: To...
* include/backward/hashtable.h: ...here.

* include/bits/c++config: Remove __gnu_cxx namespace from debug mode.
* include/debug/debug.h: Same.

* include/debug/hash_map: Remove.
* include/debug/hash_multimap.h: Remove.
* include/debug/hash_set.h: Remove.
* include/debug/hash_set: Remove.
* include/debug/hash_multiset.h: Remove.
* include/debug/hash_map.h: Remove.

* include/Makefile.am (ext_headers): Move hash_set, hash_map to
backward.
(debug_headers): Remove hash_map, hash_set, hash_map.h,
hash_map.h, hash_multiset.h, hash_multimap.h.   
* include/Makefile.in: Regenerate.

* docs/html/debug.html: Update.
* docs/html/ext/howto.html: Same.
* docs/html/faq/index.html: Same.
* docs/doxygen/Intro.3: Same.
* docs/doxygen/user.cfg.in: Adjust includes.
* testsuite/ext/hash_map: Move to...
* testsuite/backward/hash_map: ...here.
* testsuite/ext/hash_set: Move to...
* testsuite/backward/hash_set: ...here.

2007-10-18  Benjamin Kosnik  <[EMAIL PROTECTED]>

Removal of pre-ISO C++ items from include/backwards.
* include/Makefile.am (backward_headers): Remove all but strstream,
backward_warning.h.
* include/Makefile.in: Regenerate.
* include/backward/new.h: Remove.
* include/backward/iterator.h: Same.
* include/backward/alloc.h: Same.
* include/backward/set.h: Same.
* include/backward/hashtable.h: Same.
* include/backward/hash_set.h: Same.
* include/backward/fstream.h: Same.
* include/backward/tempbuf.h: Same.
* include/backward/istream.h: Same.
* include/backward/bvector.h: Same.
* include/backward/stack.h: Same.
* include/backward/rope.h: Same.
* include/backward/complex.h: Same.
* include/backward/ostream.h: Same.
* include/backward/heap.h: Same.
* include/backward/iostream.h: Same.
* include/backward/function.h: Same.
* include/backward/multimap.h: Same.
* include/backward/pair.h: Same.
* include/backward/stream.h: Same.
* include/backward/iomanip.h: Same.
* include/backward/slist.h: Same.
* include/backward/tree.h: Same.
* include/backward/vector.h: Same.
* include/backward/deque.h: Same.
* include/backward/multiset.h: Same.
* include/backward/defalloc.h: Same.
* include/backward/list.h: Same.
* include/backward/map.h: Same.
* include/backward/algobase.h: Same.
* include/backward/hash_map.h: Same.
* include/backward/algo.h: Same.
* include/backward/queue.h: Same.
* include/backward/streambuf.h: Same.
* testsuite/backward/header_hash_set_h.cc: Same.
* testsuite/backward/header_slist_h.cc: Same.
* testsuite/backward/header_hash_map_h.cc: Same.
* testsuite/backward/header_tempbuf_h.cc: Same.
* testsuite/backward/header_deque_h.cc: Same.
* testsuite/backward/header_rope_h.cc: Same.
* testsuite/backward/header_iterator_h.cc: Same.
* testsuite/backward/header_hashtable_h.cc: Same.

2007-10-18  Benjamin Kosnik  <[EMAIL PROTECTED]>

PR libstdc++/30085
* include/debug/unordered_map: New.
* include/debug/unordered_set: New.
* include/debug/safe_association.h: New.
* include/std/unordered_map: Include debug header if _GLIBCXX_DEBUG.
* include/std/unordered_set: Same.
* include/Makefile.am (debug_headers): Add unordered_map,
unordered_set, safe_association.h.
* include/Makefile.in: Regenerate.
* testsuite/23_containers/unordered_map/requirements/debug.cc: New.
* testsuite/23_containers/unordered_multimap/requirements/
debug.cc: New.
* testsuite/23_containers/unordered_set/requirements/debug.cc: New.
* testsuite/23_containers/unordered_multiset/requirements/
debug.cc: New.

2007-10-18  Benjamin Kosnik  <[EMAIL PROTECTED]>

* testsuite/util/native_type/assoc/native_hash_multimap.hpp: Remove
hash_map include.


Added:
trunk/libstdc++-v3/include/backward/hash_fun.h
  - copied, changed from r129351, trunk/libstdc++-v3/include/ext/hash

[Bug middle-end/21718] real.c rounding not perfect

[neil at gcc dot gnu dot org]

--- Comment #6 from neil at gcc dot gnu dot org  2007-10-18 15:24 ---
(In reply to comment #5)

> I believe more than 160 bits are required to get even single-precision numbers
> right with DECIMAL_DIG digits precision and an exponent.  I'm going to try and
> prove this by finding an example.  It could be hard as I believe 160 is only
> just below the required number.

Here's an example to prove this assertion.  When compiled with GCC 4.1.2 or
4.1.3 with -std=c99, assuming a correctly-rounding libc (e.g. NetBSD's; glibc
also seems to get this correct) you get the following output:

0x1.8p-147 0x1.4p-147 8.40779078594890243e-45

So not only is it rounded incorrectly, but the number it is rounded to, when
converted back to decimal, does not even match the input number in the first
digit.

#include 
#include 

int main (void)
{
  float f1 = 7.7071415537864938e-45;
  float f2 = strtof ("7.7071415537864938e-45", NULL);

  printf( "%a %a %0.18g\n", f1, f2, f1);

  return 0;
}


-- 


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

[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1

[bkoz at gcc dot gnu dot org]

--- Comment #5 from bkoz at gcc dot gnu dot org  2007-10-18 16:04 ---

Done.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/33489] parallel v3: not default constructible issues

[bkoz at gcc dot gnu dot org]

--- Comment #11 from bkoz at gcc dot gnu dot org  2007-10-18 16:06 ---

Wolfgang, I'm going to close this as fixed, ok? We are now checking
systematically for this issue as part of the 25_algo conformance testing. If
you find any more of these, please re-open. 

best,
benjamin


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug driver/33577] Compile failing for xpdf 3.02

[cabanasg at metro dot net]

--- Comment #7 from cabanasg at metro dot net  2007-10-18 16:13 ---
Subject: RE:  Compile failing for xpdf 3.02

My problem occurs during the 'make' step, after the './configure' step.
How can I use 'g++' for linking during the 'make' step?

Thanks. 

-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 17, 2007 5:56 PM
To: Cabanas, Gilberto
Subject: [Bug driver/33577] Compile failing for xpdf 3.02



--- Comment #6 from pinskia at gcc dot gnu dot org  2007-10-18 00:56
---
>with the following error message:  (Any help will be greatly
appreciated)

>ld: 0711-317 ERROR: Undefined symbol: vtable for
__cxxabiv1::__class_type_info

Yes you are not linking with the correct libstdc++ or not linking with
it at
all.

Link with g++ and not gcc directly.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added


 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 


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

[Bug libstdc++/33490] parallel v3: std::accumulate assumes iterators have std::iterator_traits declared

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2007-10-18 16:18 ---

Current mainline in parallel mode still has this fail, for the record.

Looking at the concepts code 

From:
http://www.generic-programming.org/software/ConceptGCC/

include/bits/stl_numeric.h:

  template<_GLIBCXX_REQ_PARM(InputIterator, _Iter), 
   _GLIBCXX_REQ_PARM(CopyConstructible, _Tp)>
_GLIBCXX_WHERE(Addable<_Tp, _Iter::value_type>, 
   Assignable<_Tp, 
  Addable<_Tp, _Iter::value_type>::result_type>)
_Tp
accumulate(_Iter __first, _Iter __last, _Tp __init)
{
  __glibcxx_requires_valid_range(__first, __last);

  for (; __first != __last; ++__first)
__init = __init + *__first;
  return __init;
}

which is also assuming iterator_traits::value_type

-benjamin


-- 


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

[Bug c/33809] Rounding off error in GCC 4.1.2

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2007-10-18 16:27 ---
(In reply to comment #3)
> Your code is undefined.  You have multiple assignments to pow_tmp without
> intervening sequence points.
> 

Do you think it could be interesting to collect these kind of reports as
potential testcases for an improved Wsequence-point (PR16202)?

The only thing to be done is (apart from closing it as invalid) add it as
blocking  bug 16202.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug libstdc++/31464] Extension request: publicly visible forward-declaration headers for and all STL containers

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2007-10-18 16:27 ---

Parallel mode added bits/algorithmfwd.h.


-- 


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

[Bug libstdc++/33807] Incorrect ambiguous overload

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2007-10-18 16:29 ---

Thanks for fixing this Paolo.

-benjamin


-- 


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

[Bug libstdc++/33603] configuration failure during native build

[bkoz at gcc dot gnu dot org]

--- Comment #6 from bkoz at gcc dot gnu dot org  2007-10-18 16:31 ---

Yo Gaby. Has this been worked out? Can we close this?


-- 


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

[Bug libstdc++/33807] Incorrect ambiguous overload

[bldantes at comcast dot net]

--- Comment #4 from bldantes at comcast dot net  2007-10-18 16:40 ---
Why does adding the new libstdc++ template function:

template
inline bool operator!=(const allocator<_Tp>&, const allocator<_Tp>&);

fix the conflict between my template function:

template 
bool operator != (const T& x, const T& y);

and the existing libstdc++ template function:

template
inline bool operator!=(const allocator<_T1>&, const allocator<_T2>&);

???

Before the addition of the new template function, it seems like the conflict in
the first place is just wrong. The compiler should pick the existing one in
libstdc++ over mine because it more closely matches the type, no?


-- 


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

[Bug tree-optimization/33812] Vectorizer testcases fail

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2007-10-18 16:40 ---
May I guess revision 129400?

--- trunk/gcc/ChangeLog 2007/10/17 00:46:27 129399
+++ trunk/gcc/ChangeLog 2007/10/17 01:05:50 129400
@@ -1,3 +1,10 @@
+2007-10-17  Alan Modra  <[EMAIL PROTECTED]>
+
+   * config/rs6000/rs6000.c (rs6000_emit_epilogue): Correct
+   altivec sp_offset.  Rearrange sp_offset assignments to
+   correspond to stack adjustments.  Use frame_reg_rtx for
+   SPE register restores.  Correct SPE stack adjustment.
+
 2007-10-17  Manuel Lopez-Ibanez  <[EMAIL PROTECTED]>
* builtins.c (gimplify_va_arg_expr): Use inform for help message.


-- 


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

[Bug target/33812] [4.3 Regression] Vectorizer testcases fail

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-10-18 16:56 ---
Looks like they also appear on ppc-darwin too:

http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00818.html


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |critical
 Status|UNCONFIRMED |NEW
  Component|tree-optimization   |target
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-18 16:56:18
   date||
Summary|Vectorizer testcases fail   |[4.3 Regression] Vectorizer
   ||testcases fail
   Target Milestone|--- |4.3.0


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

[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code

[dcb314 at hotmail dot com]

--- Comment #6 from dcb314 at hotmail dot com  2007-10-18 17:33 ---
(In reply to comment #2)
> Although valgrind is correct that we are doing an uninitialized read, the code
> is actually working as designed and is correct.

I wish I had a pound for every time I've heard that ;->

> So yes we do some uninitialized accesses to the sparse array, but that's 
> ok.  

Sure ?

So absolutely *any* value is fine ?

Aren't there some machines where unaligned accesses to words fail ?

> It's also a benefit of sparseset, given that we don't
> have to memset/clear the whole sparseset data structure before using it, so
> it's fast.

I'd appreciate seeing some performance measurement numbers which 
tell us just how fast, so we can make a comparison of just how much
speed this tricky code is buying us.


-- 


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

[Bug libstdc++/33807] Incorrect ambiguous overload

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2007-10-18 17:48 ---
No, this is ADL at work. Browse the comments in stl_iterator.h for some
additional hints, or delve into the nuisances of ADL ;) Anyway, for mainline, I
will also add another fix, which avoid completely the comparison for stateless
allocators.


-- 


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

[Bug libstdc++/33807] Incorrect ambiguous overload

[paolo at gcc dot gnu dot org]

--- Comment #6 from paolo at gcc dot gnu dot org  2007-10-18 17:58 ---
Subject: Bug 33807

Author: paolo
Date: Thu Oct 18 17:58:13 2007
New Revision: 129454

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129454
Log:
2007-10-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/33807
* include/bits/allocator.h (operator==(const allocator<_Tp>&,
const allocator<_Tp>&), operator!=(const allocator<_Tp>&,
const allocator<_Tp>&)): Add.
* testsuite/20_util/memory/allocator/33807.cc: New.

Added:
   
branches/gcc-4_2-branch/libstdc++-v3/testsuite/20_util/memory/allocator/33807.cc
Modified:
branches/gcc-4_2-branch/libstdc++-v3/ChangeLog
branches/gcc-4_2-branch/libstdc++-v3/include/bits/allocator.h


-- 


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

[Bug libstdc++/33807] Incorrect ambiguous overload

[pcarlini at suse dot de]

--- Comment #7 from pcarlini at suse dot de  2007-10-18 17:58 ---
Fixed for 4.2.3.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/30694] minval/maxval with +/-Inf

[burnus at gcc dot gnu dot org]

--- Comment #26 from burnus at gcc dot gnu dot org  2007-10-18 18:22 ---
If I understand it correctly, there is a difference between
IEEE 754-1989 and the current draft of IEEE 754 (duped IEEE 754r), see also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/33055faef528c075

IEEE 754r says that all operations with NaN yield NaN except of min and max
which give only NaN if all (i.e. both) arguments are NaN.

IEEE 754-1989 had no min/max functions and thus always NaN have to be produced
for maxval( huge(x), NAN ).


-- 


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

[Bug libstdc++/33603] configuration failure during native build

[gdr at cs dot tamu dot edu]

--- Comment #7 from gdr at cs dot tamu dot edu  2007-10-18 18:46 ---
Subject: Re:  configuration failure during native build

"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| Yo Gaby. Has this been worked out? Can we close this?

As long as we document that that build on MinGW requires explicit
specification of the paths to `as' and `ld'.  

-- Gaby


-- 


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

[Bug libstdc++/33489] parallel v3: not default constructible issues

[bangerth at dealii dot org]

--- Comment #12 from bangerth at dealii dot org  2007-10-18 18:46 ---
Yes, sorry. I meant to report of course that I believe that it works now.
Thanks for your work!
W.


-- 


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

[Bug tree-optimization/33804] ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize

[falk at debian dot org]

--- Comment #4 from falk at debian dot org  2007-10-18 19:26 ---
Created an attachment (id=14370)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14370&action=view)
Vectorization dump file


-- 


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

[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown

[hjl at lucon dot org]

--- Comment #17 from hjl at lucon dot org  2007-10-18 20:55 ---
This patch:

http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01047.html

makes 437.leslie3d 10% faster on Intel Core 2 Duo 64bit. But it is still 23%
slower than gcc 4.1 Red Hat.


-- 


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

[Bug target/33774] Cygwin/mingw do not support 16 byte alignment of struct/union fields

[dannysmith at users dot sourceforge dot net]

--- Comment #2 from dannysmith at users dot sourceforge dot net  2007-10-18 
21:04 ---
The native compiler MSVC++ does not limit field alignment to 64 bits, but as
documented here 
Windows Data Alignment on IPF, x86, and x64
http://msdn2.microsoft.com/en-us/library/Aa290049(VS.71).aspx

supports at least up to 256-bit field alignment  (see Listing 5 in above
article).


-- 


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

[Bug fortran/32021] Fix,document,remove GFORTRAN_* environment variables

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-10-18 21:25 
---
Subject: Bug 32021

Author: fxcoudert
Date: Thu Oct 18 21:25:21 2007
New Revision: 129463

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129463
Log:
PR libfortran/32021
* runtime/backtrace.c (local_strcasestr): Protect by appropriate
macros.
* runtime/main.c (cleanup): Cast argument to free.
* intrinsics/spread_generic.c (spread_internal): Match runtime_error
arguments and format.
* intrinsics/signal.c (alarm_sub_int_i4, alarm_sub_int_i8): Cast
pointers to avoid warnings.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/signal.c
trunk/libgfortran/intrinsics/spread_generic.c
trunk/libgfortran/runtime/backtrace.c
trunk/libgfortran/runtime/main.c


-- 


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

[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64

[skaller at users dot sourceforge dot net]

--- Comment #14 from skaller at users dot sourceforge dot net  2007-10-19 
06:33 ---
Confirm this also with SVN as at around 15 Oct 2007,
version 4.3, a bit before revision 129472.


-- 


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

[Bug libstdc++/33815] New: tr1::uniform_int isn't uniform

[jkherciueh at gmx dot net]

Consider:

#include 
#include 
#include 
#include 

void test ( unsigned int num_buckets, unsigned int seed = 3141592 ) {
  std::cout << "using " << num_buckets << " buckets:\n";
  std::tr1::mt19937 eng(seed);
  const unsigned long range = eng.max() / 5.5;
  std::tr1::uniform_int rnd( 0, range );
  std::vector bucket ( num_buckets, 0 );
  for ( unsigned int i = 0; i < 100; ++i ) {
++bucket[ rnd(eng) / (range / num_buckets) ];
  }
  for ( unsigned int i = 0; i < num_buckets; ++i ) {
std::cout << i << ": " << bucket[i] << '\n';
  }
  std::cout << '\n';
}

int main ( void ) {
  test( 2 );
  test( 3 );
  test( 4 );
  test( 6 );
  test( 10 );
  test( 20 );
  test( 30 );
  test( 40 );
}

It yields:

using 2 buckets.
0: 545389
1: 454611

using 3 buckets.
0: 363350
1: 333829
2: 302821

using 4 buckets.
0: 272507
1: 272882
2: 227489
3: 227122

using 6 buckets.
0: 181743
1: 181607
2: 182039
3: 151790
4: 151182
5: 151639

...


This doesn't look uniform. It looks more like the buckets in the
lower half get hit significantly more often.

Credit: This strange behavior had been reported by David Benbennick
to Boost long ago and was apparently never fixed.


-- 
   Summary: tr1::uniform_int isn't uniform
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkherciueh at gmx dot net
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug fortran/33795] Environment variable GFORTRAN_UNBUFFERED_ not working

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2007-10-19 04:16 
---
Subject: Bug 33795

Author: jvdelisle
Date: Fri Oct 19 04:16:14 2007
New Revision: 129471

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129471
Log:
2007-10-18  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33795
* gfortran.texi: Document GFORTRAN_UNBUFFERED_PRECONNECTED
environment variable.  Delete mention of environment variable
GFORTRAN_UNBUFFERED_n.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi


-- 


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

[Bug fortran/33795] Environment variable GFORTRAN_UNBUFFERED_ not working

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-10-19 04:11 
---
Subject: Bug 33795

Author: jvdelisle
Date: Fri Oct 19 04:10:58 2007
New Revision: 129470

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129470
Log:
2007-10-18  Francois-Xavier Coudert  <[EMAIL PROTECTED]>
Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/33795
* libgfortran.h: Add unbuffered_preconnected.
* io/unix.c (output_stream): Set stream unbuffered flag if
options.unbuffered_preconnected has been set.
(error_stream): Ditto.
* runtime/environ.c (variable_table): Add to environment variable table
the entry: GFORTRAN_UNBUFFERED_PRECONNECTED. 

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/unix.c
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/environ.c


-- 


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

[Bug fortran/33814] New: Failure of gfortran n Mac Mini

[cbas25 at strath dot ac dot uk]

I am using gfortran on a Mac Mini, and have got the compiler by untaring the
gfortran-intel-bin.tar package.  The compilers are located in /usr/local/bin. 
I am running Mac OS X Version 10.4.10

Whenever I invoke this compiler without specifying a cource file I get the
expected error message:
gfortran: no input files
>From this I deduce that the compiler is in the correct place and is able to
detect this simplest of errors

Whenever I invoke the compiler with a valid fortran source file I get the error
message:
gfortran: error trying to exec 'f951': execvp: No such file or directive.

I detected this error while trying to compile the sources for OpenGl, and I
could not make sense of the message.  I then discovered that the error message
was the same for all the input files that I tried.

Eventually I tried compiling a program that compiled successfully with g77
using the command line:

/usr/local/bin/g77 -ffixed-form -ffixed-line-length-132
-fbounds-check-ffortran-bounds-check -w -ff90 -0 strauss strauss.f

with the command line:

/usr/local/bin/gfortran -ffixed-form -ffixed-line-length-132 -fbounds-check
-fmax-errors-0 -o strauss strauss.f

This caused the response (as before) "gfortran: error trying to exec 'f951' :
execvp"

I have searched the known bugs file for f951 without any response.

I admit that I am new to Mac systems but have experience of Linux and SGI
systems from which the
above source files are derived.

I have tried out trivially simple source programs for testing and got the same
error message in response


-- 
   Summary: Failure of gfortran n Mac Mini
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cbas25 at strath dot ac dot uk


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

[Bug target/33704] AIX runs c++ constructors in incorrect order

[bkoz at gcc dot gnu dot org]

--- Comment #22 from bkoz at gcc dot gnu dot org  2007-10-19 02:00 ---

> I believe there are other functions in libstdc++ that depend on initialization
> order. I do not have specifics.

Perhaps:
FAIL: 27_io/objects/char/6.cc execution test
FAIL: 27_io/objects/wchar_t/6.cc execution test
FAIL: ext/mt_allocator/check_new.cc execution test
FAIL: ext/pool_allocator/check_new.cc execution test

from:
http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00820.html

These are the ones I would suspect might change.

FWIW, I agree 100% with Wolfgang's venting in #8, #10. Correct __cxa_atexit
behavior is essential.

-benjamin


-- 


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

[Bug target/33704] AIX runs c++ constructors in incorrect order

[ajd at gentrack dot com]

--- Comment #21 from ajd at gentrack dot com  2007-10-19 01:44 ---
Created an attachment (id=14372)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14372&action=view)
support -blazy, add option to disable

I suggest exportinitfini_flag is enabled by default or atleast for the build of
libstdc++.a and libgcc_s.a.
It should have minimal impact/risk.

initdependents_flag has risk/impact attached. You may want to reverse the
default.

My case for having it on by default:
To use exceptions within global constructors a module needs to be linked with
initdependents_flag enabled.

I believe there are other functions in libstdc++ that depend on initialization
order. I do not have specifics.

Assuming AIX was the only OS that works this way, it allows removal of these
types of workarounds:
http://gcc.gnu.org/ml/libstdc++/2001-01/msg00369.html


-- 

ajd at gentrack dot com changed:

   What|Removed |Added

  Attachment #14327|0   |1
is obsolete||


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

[Bug fortran/33544] [4.3 only] Warning in TRANSFER intrinsic should be made optional

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2007-10-19 04:58 
---
This does the trick.  I am checking the testsuite for any side effects.


Index: simplify.c
===
--- simplify.c  (revision 129465)
+++ simplify.c  (working copy)
@@ -4065,7 +4065,7 @@ gfc_simplify_transfer (gfc_expr *source,
   result_size = result_elt_size;
 }

-  if (source_size < result_size)
+  if (gfc_option.warn_surprising && source_size < result_size)
 gfc_warning("Intrinsic TRANSFER at %L has partly undefined result: "
"source size %ld < result size %ld", &source->where,
(long) source_size, (long) result_size);


-- 


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

[Bug driver/33772] collect2 doesn't strip .sl version

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca  2007-10-18 
23:55 ---
Subject: Re:   New: collect2 doesn't strip .sl version

On Sun, 14 Oct 2007, danglin at gcc dot gnu dot org wrote:

> After recently updating libgmp, I find that shared libraries that
> were linked against the old version are broken.  For example, libtool
> links libguile.sl against libgmp.sl.7, /usr/local/lib/libltdl.sl.4,
> /usr/lib/libc.1 and /users/gcc/gcc-4.2.0/lib/libgcc_s.sl.

The reason previously installed libraries break is the dependent libraries
have hardcoded dependencies on the `*GLOBAL*' symbols used for constructors,
destructors and EH exception support (hppa2.0w-hp-hpux* currently has
its EH data in the data section).

The attached patch fixes the versioning problem.  However, we still have
a random portion in every `*GLOBAL_F*' symbol.  This can easily change
from one build to the next.  So, I'm thinking we need to bury them
in special sections similar to .init_array and .fini_array.  However,
the dynamic loader doesn't provide direct support for this, so this
it's going to take some thinking as to the best way to do this.

Dave


--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2007-10-18 
23:55 ---
Created an attachment (id=14371)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14371&action=view)


-- 


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

[Bug fortran/33795] Environment variable GFORTRAN_UNBUFFERED_ not working

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2007-10-19 04:22 
---
Fixed, closing


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/33814] Failure of gfortran n Mac Mini

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-10-19 06:40 ---
> Whenever I invoke this compiler without specifying a cource file I get the
> expected error message:
> gfortran: no input files
[...]
> Whenever I invoke the compiler with a valid fortran source file I get the 
> error
> message:
> gfortran: error trying to exec 'f951': execvp: No such file or directive.

gfortran (and gcc, g++ etc.) are wrappers around the actual compiler.

Seemingly, the wrapper "gfortran" cannot find the actual compiler; on my Linux
system they are at:

/usr/bin/gfortran
/usr/lib64/gcc/x86_64-suse-linux/4.2.2/f951

You could try '-v', e.g.
  gfortran -v -c someFortranFile.f
this gives more information, which might help.


-- 


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