[Bug bootstrap/27133] Fails to build because of funny version of makeinfo
--- Comment #7 from P dot Schaffnit at access dot rwth-aachen dot de 2006-10-27 07:03 --- Here's what I get: makeinfo -v --split-size=500 --split-size=500 --split-size=500 -I /USER/philippe/Irix/Gcc_Sources/gcc/doc/include -I /USER/philippe/Irix/Gcc_Sources/gcc/fortran -o doc/gfortran.info ; echo $? makeinfo: missing file argument. Try `makeinfo --help' for more information. 1 The whole thing probably happens because of: makeinfo --version makeinfo (GNU texinfo) 4.5 If configure could warn about it, it would be nice... (Obviously, I have no idea how complicated it would be...). Also a switch to disable it could be handy (same remark...). Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27133
[Bug fortran/29578] inquire(...) returns formatted==YES for unreadable and unformatted files
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-27 08:06 --- Close as invalid then. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
[Bug bootstrap/27133] Fails to build because of funny version of makeinfo
--- Comment #8 from aldot at gcc dot gnu dot org 2006-10-27 08:58 --- I forgot the texi file.. makeinfo -v --split-size=500 --split-size=500 --split-size=500 -I /USER/philippe/Irix/Gcc_Sources/gcc/doc/include -I /USER/philippe/Irix/Gcc_Sources/gcc/fortran -o doc/gfortran.info \ /USER/philippe/Irix/Gcc_Sources/gcc/fortran/gfortran.texi; echo $? Please retry. Also a switch to disable it could be handy (same remark...). You should be able to pass MAKEINFO=/bin/false to configure to make it explicit that makeinfo is not available on your machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27133
[Bug c++/29596] overloaded function not found
--- Comment #7 from again at gmx dot de 2006-10-27 09:04 --- Created an attachment (id=12500) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12500action=view) test2.cpp (sample program that does not compile) I managed to simplify the program. -- again at gmx dot de changed: What|Removed |Added Attachment #12493|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29596] overloaded function not found
--- Comment #8 from again at gmx dot de 2006-10-27 09:05 --- Created an attachment (id=12501) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12501action=view) output of 'g++ test2.cpp -o test2' -- again at gmx dot de changed: What|Removed |Added Attachment #12494|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29596] overloaded function not found
--- Comment #9 from again at gmx dot de 2006-10-27 09:06 --- Created an attachment (id=12502) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12502action=view) output of compiler shipped with MS Visual C++ 2005 Express Edition and program output -- again at gmx dot de changed: What|Removed |Added Attachment #12495|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29596] overloaded function not found
--- Comment #10 from again at gmx dot de 2006-10-27 09:06 --- test2.ii produced by `g++ -v -save-temps test2.cpp -o test2' is to big for bugzilla -- you can find it here: http://schlotter.org/pub/test2.ii (1.1MB) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/28553] [4.1 Regression] string processing -O3 optimization bug under GCC 4.1.1
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-27 09:41 --- I cannot reproduce this with 4.1.2 20061024 anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28553
[Bug c++/29106] [4.0/4.1 Regression] sizeof(*var) in expression drops entire line of code out of compile
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-27 09:46 --- Janis, can you hunt this? The 4.1 branch doesn't print anything while 4.2 prints size of thingy is 4. Thanks! -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106
[Bug middle-end/28970] [4.1 Regression] Wrong code for simple loop test case
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-27 09:50 --- Janis, can you hunt which path introduced this regression relative from 4.0.0 which seems to work? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org Known to work|4.0.0 |4.0.0 4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28970
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Comment #15 from yuecelm at ee dot ethz dot ch 2006-10-27 10:31 --- Found an important hint: If the switch instruction is replaced with else ifs, the file is also compilable with the -Os option. It seems that the avr-gcc 4.0 can only optimize a limited number of cases (the file usart.i has 33 cases in one switch statement). -- yuecelm at ee dot ethz dot ch changed: What|Removed |Added CC||yuecelm at ee dot ethz dot ||ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug c++/29596] overloaded function not found
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-27 11:04 --- I believe the testcase is invalid. EDG says: test.cpp(5824): error: no instance of overloaded function boost::lambda::lambda_functorT::operator() [with T=boost::lambda::placeholder1] matches the argument list argument types are: (std::pairint, int) object type is: boost::lambda::placeholder1_type std::cout (boost::lambda::_1)(std::make_pair(a, b)) std::endl; ^ compilation aborted for test.cpp (code 2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c++/29596] overloaded function not found
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-10-27 11:05 --- Created an attachment (id=12503) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12503action=view) unincluded testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
[Bug c/29613] New: static string in vararg function
When executing that on a target:
#include stdarg.h
void bug_vsprintf( char *pString, const char *format, va_list ap)
{
char c;
char *str = 0;
int str_cnt = 0;
while((c = *format++) != '\0')
{
if (c == '%')
{
if (*format++ == 's')
{
str = va_arg(ap, char *);
if (str == 0) str = (null);
for (str_cnt = 0; str[str_cnt] != '\0'
str_cnt = 5; str_cnt++)
continue;
if (str_cnt 5) {
static char errmsg[32] = (invalid %s
ptr);
//char errmsg[32] = (invalid %s ptr);
// no bug
str = errmsg;
str_cnt = sizeof((invalid %s ptr)) -
1;
}
}
while(str_cnt)
{
*pString++ = (*str++);
str_cnt--;
}
}
else
*pString++ = c;
}
*pString = '\0';
}
void bug_sprintf( char *pString, const char *format, ...)
{
va_list argptr;
va_start( argptr, format );
bug_vsprintf( pString, format, argptr );
va_end( argptr );
}
void triggerbug(void)
{
char buffer[50];
bug_sprintf(buffer, %s, 123456789);
printf (buggy buffer: %s i.e. 0x%X 0x%X 0x%X ...\r\n, buffer,
buffer[0], buffer[1], buffer[2]);
}
(first include stdio.h for printf)
Compilation switch:
powerpc-eabi-gcc -Wall -W -O2 -fno-strict-aliasing -ffunction-sections
-std=gnu99 -Xassembler -mregnames bug.c
I get the line:
buggy buffer: À i.e. 0xC0 0x0 0x57 ...
If I remove the static (in static char errmsg), I get what I want:
buggy buffer: (invalid %s ptr) i.e. 0x28 0x69 0x6E ...
--
Summary: static string in vararg function
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
GCC host triplet: cygwin-ia32
GCC target triplet: powerpc-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29613
[Bug bootstrap/26814] Bootstrapping with a non default ABI (-m64 on ppc-darwin or on ppc-linux with a compiler defaulting to 32 and now defaulting to 64)
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2006-10-27 12:33 --- The use of... cd gfortran aclocal -I ../config autoconf eliminated the build problems on a G4 for libgfortran. However it moved the problems on to boehm-gc. I suspect we need to regenerate the aclocal.m4 and configure for the libgfortran, boehm-gc, libffi and libjava subdirectories. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
[Bug debug/29614] New: DWARF information for function static variable is missing after unrelated code addition
A bunch of tests in the gdb testsuite dealing with static variables inside
function scopes have started failing recently with the latest development gcc.
I simplified the test case down to a small program that shows that simply
adding a small bit of unrelated code causes the DWARF information to disappear.
Here is a typescript:
Script started on Tue 24 Oct 2006 08:58:44 PM MST
$ cat b.c
int bar ()
{
static int funclocal = 4; /* In data section */
return funclocal;
}
int foo ()
{
static int funclocal = 3; /* In Data section */
return funclocal;
}
#ifdef EXPOSEBUG
void bell ()
{
static int usedval;
}
#endif
main ()
{
extern void exit (int);
exit (bar() + foo());
}
$ gcc -g -o b b.c
$ readelf --debug-dump b | grep funclocal
DW_AT_name: (indirect string, offset: 0x0): funclocal
DW_AT_name: (indirect string, offset: 0x0): funclocal
DW_AT_name: (indirect string, offset: 0x0): funclocal
0x 66756e63 6c6f6361 6c00 funclocal.
$ gcc -DEXPOSEBUG -g -o b b.c
$ readelf --debug-dump b | grep funclocal
DW_AT_name: funclocal
$ gdb b
GNU gdb 6.5.50.20060923-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i686-pc-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) br foo
Breakpoint 1 at 0x8048361: file b.c, line 10.
(gdb) br bar
Breakpoint 2 at 0x8048357: file b.c, line 4.
(gdb) run
Starting program:
/media/backups/new/build/specifix/experimental/i686-pc-linux-gnu/gdb/gdb/testsuite/b
Breakpoint 2, bar () at b.c:4
4 return funclocal;
(gdb) p funclocal
No symbol funclocal in current context.
(gdb) c
Continuing.
Breakpoint 1, foo () at b.c:10
10return funclocal;
(gdb) p funclocal
$1 = 3
(gdb) quit
The program is running. Exit anyway? (y or n) y
$ exit
Script done on Tue 24 Oct 2006 08:59:51 PM MST
--
Summary: DWARF information for function static variable is
missing after unrelated code addition
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fnf at specifixinc dot com
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=29614
[Bug libstdc++/29426] [4.2 Regression] static __recursive_mutex init vs __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-10-27 13:31 --- Benjamin's patch totally broke the C++ compiler on Solaris 2.6 and probably damaged it on Solaris 7, 8 and 9 too. This is again PR target/24071. At least I now have a strong incentive to tackle the problem. :-) -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
[Bug fortran/29267] different length non-constant strings in array constructors ICE
--- Comment #13 from tobi at gcc dot gnu dot org 2006-10-27 13:33 --- Thanks for the pointer to the other PR. Do g95 and ifort also compile the original testcase and do The Right Thing? I didn't have time to fix this after I assigned myself to it, so unassigining. -- tobi at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27998 AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug c++/29615] New: Class can't be friends of itself?
The following simple C++ file:
test.cpp
class A
{
friend class A;
};
int main() { return 0; }
/test.cpp
results in the following error when I try to compile it with g++:
$ ~/gcc-build-4.2-20061007/gcc/g++ -o test test.cpp
test.cpp:3: error: class 'A' is implicitly friends with itself
I was using a snapshot (GCC 4.2 2006/10/07), but I got the same behaviour with
several 4.1.x and 4.0.x builds on both Linux and Windows 2000 (Cygwin).
I agree that it's pointless to make a class a friend of itself (which is why I
used severity 'minor'), but I haven't found anything in my C++ spec (ISO/IEC
14882) that say it is not allowed. Please point my to the relevant section in
case I missed anything.
By the way: all other compilers I've tried accept this file without a problem.
These include Visual Studio .NET 2003, CodeWarrior 8.3, CodeWarrior 9.6 and the
online test drive for Comeau. Comeau does exactly what I'd expect:
Your Comeau C/C++ test results are as follows:
Comeau C/C++ 4.3.8 (Aug 19 2006 13:36:48) for ONLINE_EVALUATION_Alpha1
Copyright 1988-2006 Comeau Computing. All rights reserved.
MODE:strict errors C++
ComeauTest.c, line 3: warning: pointless friend declaration
friend class A;
^
Not a big issue, but I thought it might be a good idea to log this anyway,
since a search didn't result in relevant hits :-)
--
Summary: Class can't be friends of itself?
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danny dot boelens at artwork-systems dot com
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=29615
[Bug fortran/29315] error passing an array derived from type element
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-27 14:37 --- I am sorry but I realised on looking at this again that the stride has nothing to do with this one - the patch below regtests but has not been checked for correct-in-all-cases logic. Since the original was incorrect, give me a couple more days to get home and give this some clear thought... or what goes for clear thought. Paul Index: gcc/fortran/trans-expr.c === *** gcc/fortran/trans-expr.c(revision 117860) --- gcc/fortran/trans-expr.c(working copy) *** is_aliased_array (gfc_expr * e) *** 1840,1846 if (ref-type == REF_ARRAY) seen_array = true; ! if (ref-next == NULL ref-type != REF_ARRAY) return seen_array; } --- 1845,1851 if (ref-type == REF_ARRAY) seen_array = true; ! if (seen_array ref-type != REF_ARRAY) return seen_array; } -- 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|2006-10-02 03:07:51 |2006-10-27 14:37:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29315
[Bug fortran/29616] New: Run-time check using nullified pointers
I think there are essentially two problems possible with pointers: (a) Uninitialized pointer (i.e. neither NULL nor associated) (b) Using an unassociated pointer I think checking (a) is not easily doable as one would need to pass this status (has been initialized? yes/no) on to subroutines. (NAG f95 does so, but one needs to compile all parts of the program with this option as the variable status is passed on to the subroutines. This -C=uninitialized options is still great to find uninitialized variables, esp. those (e.g. integer) which can not be pre-autoinitialized by NaN.) Thus this is a request for enhancement for the second type. Example: program pointtest implicit none real, pointer :: r nullify(r) call foo(r) ! Error one r = 5.0 ! Error two contains subroutine foo(bar) real, target, intent(in) :: bar ! The error occures already here and not in the next line! print *, bar end subroutine foo end program pointtest Both are caught by NAG f95 with -C=pointer and by ifort with -check pointer: Reference to disassociated POINTER R and forrtl: severe (408): fort: (7): Attempt to use pointer R when it is not associated with a target However, the error analysis could be improved for both: Ifort gives a trace, but even with -g it does not show where. NAG at least coredumps and thus one can find out where it crashes: gdb - bt ... #3 0x2af4962e5e1a in __NAGf90_badptr1 () from /opt/nag/lib/libf98.so.1 #4 0x00403338 in main (argc=1, argv=0x7fff14a00578) at pointest.f90:6 We should try to find something, which is easily debuggable (e.g. spitting out the file and line number?). If we say that the user should use gdb himself [as we used to with boundary check], then we should at least tell, were to set the break point [unless we coredump, the one can use bt]. At least I didn't found it obvious to set a break point at exit__ (or something like that), which was also in a library not loaded when loading the program in gdb. Well, fortunally -fbounds-check now prints file and line :-) (The two pointer tests of Polyhedron's diagnotic check, by the way, only the first type.) -- Summary: Run-time check using nullified pointers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29616
[Bug fortran/29617] New: [4.3 regression] gfortran testsuite failure
This problem happens only on 4.3, and only with target gnualtivec... First noticed on snapshot of Oct 23 I have 4000+ gfortran tests failing because of a warning message from the compiler. Here is an example: /temp/gnu_toolchain/build_area/gcc-trunk/obj_gcc-trunk_7450/gcc/testsuite/gfortran/../../gfortran -B/temp/gnu_toolchain/build_area/gcc-trunk/obj_gcc-trunk_7450/gcc/testsuite/gfortran/../../ /temp/gnu_toolchain/build_area/gcc-trunk/gcc-trunk/gcc/testsuite/gfortran.dg/char_unpack_2.f90 -O3 -fomit-frame-pointer -funroll-loops -pedantic-errors -c /temp/gnu_toolchain/build_area/gcc-trunk/gcc-trunk/gcc/testsuite/gfortran.dg/char_unpack_2.f90:0: warning: 'const' attribute directive ignored 4.2 does not have this problem, other 4.3 powerpc targets does not either... (*-*-gnu, and *-*-gnuspe) The compiler was configured with: /temp/gnu_toolchain/build_area/gcc-trunk/obj_gcc-trunk_7450/gcc/testsuite/gfortran/../../gfortran -v Using built-in specs. Target: powerpc-unknown-linux-gnualtivec Configured with: ../gcc-trunk/configure --prefix=/temp/gnu_toolchain/install_area/gcc-trunk/gcc-trunk-20061026-7450 --with-local-prefix=/temp/gnu_toolchain/install_area/gcc-trunk/gcc-trunk-20061026-7450 --enable-languages=c,c++,fortran --enable-threads --target=powerpc-unknown-linux-gnualtivec --with-gmp=/proj/ppc/sysperf/sw/gnu_toolchain/gcc_support/linuxAMD64 --with-mpfr=/proj/ppc/sysperf/sw/gnu_toolchain/gcc_support/linuxAMD64 --disable-linux-futex Thread model: posix gcc version 4.3.0 20061026 (experimental) -- Summary: [4.3 regression] gfortran testsuite failure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edmar at freescale dot com GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnualtivec http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29617
[Bug c++/29618] New: argument dependent lookup: what about built-in types?
Hello,
Consider the following piece of C++ code:
-
#include boost/functional/hash.hpp
#include cstddef
struct A {
int n;
};
size_t hash_value(A v)
{
return boost::hash_value(v.n);
}
size_t hash_value(long long int v)
{
size_t seed = 0;
boost::hash_combine(seed, static_castlong int(v 0x));
boost::hash_combine(seed, static_castlong int(v 32));
return seed;
}
templateclass T
size_t calc_hash(T v)
{
size_t seed = 0;
boost::hash_combine(seed, v);
return seed;
}
template size_t calc_hash(A);
template size_t calc_hash(long long int);
-
Now, calc_hash() for some type simply calls hash_combine() for it, which will
internally resolve to calling hash_value() for the type (I can provide a
minimal version with no dependence on the Boost include files if someone thinks
that's a problem). So the compiler needs to find the proper definition of
hash_value() for that type.
Earlier versions of g++ (say, 3.2 which I have handy here) didn't quite
conform to the standard, so the way to make the above code work was to declare
the above hash_value() functions inside the boost namespace. But these days g++
has ADL, which means that hash_value() instead has to be declared in the same
namespace as the type. In the code I'm posting above, this works fine for A;
even if I move it inside some namespace, as long as I also move hash_value(A)
inside the same namespace, the code will compile.
But what about long long int? When I try to compile the above with g++ 4.1, I
get:
error: call of overloaded 'hash_value(const long long int)' is ambiguous
followed by a list of candidate functions, which includes all the ones declared
in the header file, but not the one declared in this file. Again, in g++ 3.2
this compiles as long as hash_value(long long) is declared inside the boost
namespace too. But with 4.1 I can't seem to be able to make it compile at all.
So is this a bug, or am I doing something wrong here?
Thanks,
Vasilis
--
Summary: argument dependent lookup: what about built-in types?
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: v dot vasaitis at sms dot ed dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29618
[Bug c++/29618] argument dependent lookup: what about built-in types?
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-27 16:07 --- There is an open Defect report against the C++ standard about ADL and builtin types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29618
[Bug middle-end/28970] [4.1 Regression] Wrong code for simple loop test case
--- Comment #5 from janis at gcc dot gnu dot org 2006-10-27 16:40 --- The regression hunt results in comment #2 are from mainline during development of 4.1. Is there some other hunt that would be useful as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28970
[Bug middle-end/29610] [4.1 Regression] ICE when compiling c++ code with -O2 -funswitch-loops
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-27 17:46 ---
Confirmed, reduced testcase:
struct __normal_iterator
{
typedef int*const *_Iterator;
int*const * _M_current;
__normal_iterator(const _Iterator __i) : _M_current(__i){}
const _Iterator base() const {}
};
struct string { ~string(){} };
struct vector
{
int** _M_finish;
__normal_iterator end() const { return __normal_iterator (_M_finish); }
int size() const { return end().base() - end().base(); }
};
class Painter
{
int redraw_window(void);
typedef int (Painter::* SliceWindowFunc)(void);
int for_each(vector, SliceWindowFunc);
void tcl_command(void);
};
inline int Painter::for_each(vector layout, SliceWindowFunc func)
{
for (unsigned int window = 0; window layout.size();++window)
(this-*func)();
}
int t;
int Painter::redraw_window(void) {t = 1;}
string t2(int);
vector *g(const string);
void Painter::tcl_command(void)
{
for_each(*g(t2(2)), Painter::redraw_window);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.1.2
Known to work||4.3.0
Last reconfirmed|-00-00 00:00:00 |2006-10-27 17:46:37
date||
Summary|ICE when compiling c++ code |[4.1 Regression] ICE when
||compiling c++ code with -O2
||-funswitch-loops
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29610
[Bug bootstrap/26814] Bootstrapping with a non default ABI (-m64 on ppc-darwin or on ppc-linux with a compiler defaulting to 32 and now defaulting to 64)
--- Comment #14 from fang at csl dot cornell dot edu 2006-10-27 18:14 --- Perhaps other directories need regen., according to Mike, the following are outdated (as of 4.2-20061024): http://gcc.gnu.org/ml/gcc/2006-10/msg00578.html libdecnumber/aclocal.m4 zlib/aclocal.m4 intl/aclocal.m4 libgfortran/configure libgfortran/config.h.in libgfortran/aclocal.m4 libmudflap/configure libmudflap/aclocal.m4 boehm-gc/configure boehm-gc/aclocal.m4 libffi/aclocal.m4 libjava/configure BTW, this report is against 4.1, but we've been discussing 4.2. Should this be addressed in a new report? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
[Bug bootstrap/29620] New: can not build libgcc.a on stage 1
./xgcc -B./ \ # ... -DL__gcc_bcmp -c SHARED_DIR/gcc-4.1.1/gcc/libgcc2.c -o libgcc/./__gcc_bcmp.o /var/tmp//ccBzKd2Z.s: Assembler messages: /var/tmp//ccBzKd2Z.s:690: Error: misaligned data make[3]: *** [libgcc/./_divdi3.o] Error 1 The same for targets: libgcc/./_udivdi3.o libgcc/./_umoddi3.o libgcc/./_udivmoddi4.o libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde.o libgcc/./gthr-gnat.o libgcc/./unwind-c.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o Eventually make[2]: *** [libgcc.a] Error 2 make[1]: *** [stage1_build] Error 2 make: *** [bootstrap] Error 2 Will post `xgcc' output for assembler or other details on request. Environment: System: SunOS redsun 5.5 Generic sun4m sparc SUNW,SPARCstation-10 Architecture: sun4 Old compiler is gcc (GCC) 4.0.2 installed with its own prefix. The only installed assembler is GNU assembler version 2.7 (sparc-sun-solaris2.5), using BFD version 2.7 Worked with 4.0.2. If too old for this one, please note so in `NEWS', and tell which oldest binutils version should be used. host: sparc-sun-solaris2.5 build: sparc-sun-solaris2.5 target: sparc-sun-solaris2.5 configured with: SHARED_DIR/gcc-4.1.1/configure --prefix=NEW_DIR --disable-nls --disable-libgcj --enable-languages=c,c++,objc How-To-Repeat: make bootstrap -- Summary: can not build libgcc.a on stage 1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gin at mo dot msk dot ru GCC build triplet: sparc-sun-solaris2.5 GCC host triplet: sparc-sun-solaris2.5 GCC target triplet: sparc-sun-solaris2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29620
[Bug fortran/29621] New: lapack runs into infinite loop with -03
Steps to reproduce:
0. Download lapack (blas source included) from:
http://www.netlib.org/lapack/lapack.tgz.
1. Build blas:
gfortran -c BLAS_SRC\*.f -O3
ar -r libblas.a *.o
2. Build lapack:
gfortran -c LAPACK_SRC\*.f -O3
ar -r liblapack.a *.o
3. Run following testcase (testcase.f):
-- code -
PROGRAM TESTCASE
IMPLICIT NONE
REAL A(3,3)
REAL X(3)
REAL WORK(9)
INTEGER INFO
A(1,1)= 1.
A(2,1)= 0.
A(3,1)= 0.
A(1,2)= 0.
A(2,2)= 1.
A(3,2)= 0.
A(1,3)= 0.
A(2,3)= 0.
A(3,3)= 1.
CALL DSYEV('N','L',3,A,3,X,WORK,3*3,INFO);
END PROGRAM
-- end code -
build with
gfortran -c testcase.f -O3
gfortran testcase.o -L. -llapack -lblas
Result: a.exe runs into an infinite loop.
Builds are on Win32 XP with gFortran 4.3.0 20061021 (experimental). Same occurs
with previous versions of gFortran.
F.E. Karaoulanis (www.nemesis-project.org)
--
Summary: lapack runs into infinite loop with -03
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fkar at nemesis-project dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug bootstrap/29620] can not build libgcc.a on stage 1
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-27 19:16 --- http://gcc.gnu.org/install/specific.html#x-x-solaris2 All releases of GNU binutils prior to 2.11.2 have known bugs on this platform. We recommend the use of GNU binutils 2.11.2 or later, or the vendor tools (Sun as, Sun ld). Note that your mileage may vary if you use a combination of the GNU tools and the Sun tools: while the combination GNU as + Sun ld should reasonably work, the reverse combination Sun as + GNU ld is known to cause memory corruption at runtime in some cases for C++ programs. Read the installation documention which is located at: http://gcc.gnu.org/install/ -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29620
[Bug bootstrap/29622] New: broken anchor name in html
`gcc-4.1.1/INSTALL/specific.html' specifies `#sparc-sun-solaris2' link for `sparc-sun-solaris2*' item, but there is no such anchor in the document. Instead, this item is anchored with `sparc_002dsun_002dsolaris2'. How-To-Repeat: Point browser to the file, try to follow the link in the document. -- Summary: broken anchor name in html Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gin at mo dot msk dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29622
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-27 19:33 --- DSYEV is expecting double precision arrays. You are giving it default real kind arrays. This is a bug in your code. If you want gfortran to detect this type of problem, use LAPACK95. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug other/29622] broken anchor name in html
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-27 20:09 --- This was a bug in texinfo (or what ever was used to convert .texi to html) IIRC. This is fixed already correctly anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|bootstrap |other Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29622
[Bug other/29622] broken anchor name in html
--- Comment #2 from gin at mo dot msk dot ru 2006-10-27 20:18 --- Subject: Re: broken anchor name in html Confirming that anchor names are consistent in http://gcc.gnu.org/install/specific.html Hope that the updated version will get in next gcc release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29622
[Bug bootstrap/29620] can not build libgcc.a on stage 1
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-10-27 20:42 --- Note also that SPARC/Solaris 2.5 is not supported, only SPARC/Solaris 2.5.1 is. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Version|unknown |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29620
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2006-10-27 20:47 --- Subject: Bug 27954 Author: jvdelisle Date: Fri Oct 27 20:47:28 2006 New Revision: 118084 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118084 Log: 2006-10-27 Jerry DeLisle [EMAIL PROTECTED] PR fortran/27954 * decl.c (gfc_free_data_all): New function to free all data structures after errors in DATA statements and declarations. (top_var_list): Use new function.(top_val_list): Use new function. (gfc_match_data_decl): Use new function. * misc.c (gfc_typename): Fixed incorrect function name in error text. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/misc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug ada/29623] New: Assert_Failure sinfo.adb:649 in task allocator
(Forwarding Debian bug #395406): Subject: gnat-4.1: Assert_Failure sinfo.adb:649 Package: gnat-4.1 Version: 4.1.1-16 Severity: normal *** Please type your report below this line *** Trying to compile an Ada program, I have this bug with gnatmake : $ gnatmake -gnat05 rv.adb gcc-4.1 -c -gnat05 rv.adb +===GNAT BUG DETECTED==+ | 4.1.2 20061007 (prerelease) (Debian 4.1.1-16) (i486-pc-linux-gnu)| | Assert_Failure sinfo.adb:649 | | Error detected at rv.adb:83:26 | My source code : rv.adb with text_io; use text_io; procedure rv is p : constant integer := 6; -- nombre de tâches processus nb_rv : constant integer := 2; -- nombre de rendez-vous successifs subtype indice_processus is integer range 1..p; typeetat_processus is (run, wait); variables partagées -- à compléter - etat : array(indice_processus) of etat_processus := (others = run); - - Tache serveur - - task serveur is entry rendez_vous; entry photo; end serveur ; task body serveur is begin loop select accept rendez_vous; or accept photo do for i in etat'Range loop if etat(i) = run then put(| ); else put(+ ); end if; end loop; put(Natural'Image(rendez_vous'Count)); new_line(1); end photo; end select; end loop; end serveur ; --- - Tache processus - --- task type processus (numero : indice_processus); task body processus is begin serveur.rendez_vous; end processus; --- - Tache trace - --- task trace; task body trace is begin serveur.photo; end trace ; begin -- affiche en-tête de la trace --- new_line(1); put_line(integer'image(p) processus se donnent integer'image(nb_rv) rendez-vous ); new_line(1); put_line(Les processus s'executent : | , ou attendent : +) ; new_line(1); -- le header --put( ); for i in 1..p loop put(p integer'image(i)(2..3) ); end loop ; put(rendez_vous'count); new_line(1) ; -- les processus declare taches : array(1..p) of access processus; begin for i in indice_processus loop taches(i) := new processus(i); -- line 83 end loop; end; end rv; -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages gnat-4.1 depends on: ii gcc-4.1 4.1.1-13The GNU C compiler ii gnat-4.1-base4.1.1-16The GNU Compiler Collection (gnat ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libc6-dev2.3.6.ds1-4 GNU C Library: Development Librari ii libgcc1 1:4.1.1-13 GCC support library ii libgnat-4.1 4.1.1-16Runtime library for GNU Ada applic ii libgnatprj4.14.1.1-16GNU Ada Project Manager ii libgnatvsn4.14.1.1-16GNU Ada compiler version library gnat-4.1 recommends no packages. (sinfo.adb is not patched in Debian). -- Summary: Assert_Failure sinfo.adb:649 in task allocator Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29623
[Bug fortran/29563] Internal read loses data.
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-10-27 20:50 --- Subject: Bug 29563 Author: jvdelisle Date: Fri Oct 27 20:50:15 2006 New Revision: 118085 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118085 Log: 2006-10-27 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/29563 * gfortran.dg/error_recovery_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/error_recovery_2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29563
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2006-10-27 20:55 --- Subject: Bug 27954 Author: jvdelisle Date: Fri Oct 27 20:54:54 2006 New Revision: 118086 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118086 Log: 2006-10-27 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/27954 Fix type in changelog, pr number * gfortran.dg/error_recovery_2.f90: New test. Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/29563] Internal read loses data.
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-10-27 20:57 --- Ignore comment 11. Had the wrong PR number in ChangeLog entry when committing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29563
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2006-10-27 20:58 --- Fixed on 4.3 Only -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #2 from fkar at nemesis-project dot org 2006-10-27 21:14
---
I just tried to submit a reduced test case. Please reconsider this bug with
these two cases (one linking with a Fortran program and one with a C/C++ one):
===
Test case #1 [Fortran with DOUBLE PRECISION]
===
PROGRAM TESTCASE
IMPLICIT NONE
DOUBLE PRECISION A(3,3)
DOUBLE PRECISION X(3)
DOUBLE PRECISION WORK(9)
INTEGER INFO
A(1,1)= 1.
A(2,1)= 0.
A(3,1)= 0.
A(1,2)= 0.
A(2,2)= 1.
A(3,2)= 0.
A(1,3)= 0.
A(2,3)= 0.
A(3,3)= 1.
CALL DSYEV('N','L',3,A,3,X,WORK,3*3,INFO);
END PROGRAM
===
Test case #2 [C/C++]
===
extern C void dsyev_(char* JOBZ,char* UPLO,int* N,double* A,int* LDA,
double* W,double* WORK,int* LWORK,int* INFO);
int main()
{
int N=3;
double x[3];
double a[3*3];
a[0] = 1; a[3] = 0; a[6] = 0;
a[1] = 0; a[4] = 1; a[7] = 0;
a[2] = 0; a[5] = 0; a[8] = 1;
char JOBZ='N';
char UPLO='L';
int LDA=N;
int LWORK=3*3;
double WORK[LWORK];
int INFO;
dsyev_(JOBZ,UPLO,N,a[0],LDA,x[0],WORK[0],LWORK,INFO);
return 0;
}
The result is in both cases identical: an infinite loop.
Kind regards,
F.E. Karaoulanis (www.nemesis-project.org)
--
fkar at nemesis-project dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29563] Internal read loses data.
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-10-27 21:41 --- Subject: Bug 29563 Author: jvdelisle Date: Fri Oct 27 21:40:54 2006 New Revision: 118087 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118087 Log: 2006-10-27 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/29563 * io/io.h (st_parameter_dt): Add new flag at_eof. * io/list_read.c (next_char): Set flag when EOF and return '\n' to signal EOR. Check flag on next call and jump out. * io/unit.c (get_internal_unit): Initialize new flag. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/io.h branches/gcc-4_1-branch/libgfortran/io/list_read.c branches/gcc-4_1-branch/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29563
[Bug fortran/29563] Internal read loses data.
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-27 21:42 --- Subject: Bug 29563 Author: jvdelisle Date: Fri Oct 27 21:42:40 2006 New Revision: 118088 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118088 Log: 2006-10-27 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/29563 * gfortran.dg/arrayio_9.f90: New test. * gfortran.dg/arrayio_19.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/arrayio_10.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/arrayio_9.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29563
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-10-27 21:44 --- Let me check this out and see if I can duplicate the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-27 21:47 --- What compiler option did you use to compile BLAS and LAPACK? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #5 from fkar at nemesis-project dot org 2006-10-27 21:51 --- (In reply to comment #4) What compiler option did you use to compile BLAS and LAPACK? It is mentioned on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621#c0: 1. Build blas: gfortran -c BLAS_SRC\*.f -O3 ar -r libblas.a *.o 2. Build lapack: gfortran -c LAPACK_SRC\*.f -O3 ar -r liblapack.a *.o ... which means the (default) optimization options as provided by -O3 only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #6 from kargl at gcc dot gnu dot org 2006-10-27 22:07 --- I can't make this go into an infinite loop on FreeBSD. Can you rebuild blas and lapack with -O1 and see if the problem still occurs? I'm not sure if this is an optimization problem or a target problem (cygwin or mingW?) -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-10-27 22:13 --- Using gfortran: I get AOK, no infinite loop. See information that follows. Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc43/configure --prefix=/home/jerry/gcc/usr --enable-languages=c,fortran --disable-libmudflap --enable-libgomp --enable-maintainer-mode Thread model: posix gcc version 4.3.0 20061025 (experimental) I built blas and lapack at -O3 I compiled testcase.f with -O3 I used the link line used in Comment #1. The test program compiled, linked, and executed AOK on i686-linux I am using ranlib 2.17 and ar 2.17 The next questionis what tool versions are you using. I also used the make script from the lapack distribution with make.inc as follows: # LAPACK make include file. # # LAPACK, Version 3.0 # # June 30, 1999 # # SHELL = /bin/sh # # The machine (platform) identifier to append to the library names # PLAT = _gfc # # Modify the FORTRAN and OPTS definitions to refer to the # compiler and desired compiler options for your machine. NOOPT # refers to the compiler options desired when NO OPTIMIZATION is # selected. Define LOADER and LOADOPTS to refer to the loader and # desired load options for your machine. # FORTRAN = gfc OPTS = -O3 DRVOPTS = $(OPTS) NOOPT= LOADER = gfc LOADOPTS = # # The archiver and the flag(s) to use when building archive (library) # If you system has no ranlib, set RANLIB = echo. # ARCH = ar ARCHFLAGS= cr RANLIB = ranlib # # The location of the libraries to which you will link. (The # machine-specific, optimized BLAS library should be used whenever # possible.) # BLASLIB = ../../blas$(PLAT).a LAPACKLIB= lapack$(PLAT).a TMGLIB = tmglib$(PLAT).a EIGSRCLIB= eigsrc$(PLAT).a LINSRCLIB= linsrc$(PLAT).a I copied the resulting libraries to libraries matching the names you used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-27 22:15 --- What platform are you using that has the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #9 from fkar at nemesis-project dot org 2006-10-27 22:29 --- I confirm that the same problem exists with -O1. It might be a target problem (gfortran used comes from a mingw build, dated 2006-10-21 and linked as an installer in http://gcc.gnu.org/wiki/GFortranBinaries). As mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621#c0 the platform is Win32. Anyway, just to mention that other LAPACK routines tested (DGESV, DSPSV, DGBSV just to name some) run perfectly fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug c++/29618] argument dependent lookup: what about built-in types?
--- Comment #2 from bangerth at dealii dot org 2006-10-27 22:47 --- Built-in types are not associated with any namespace. ADL therefore doesn't apply to them -- name lookup proceeds from the present scope outward and stops once a suitable name is found. This results in you getting all the overloaded versions of the functions inside the boost namespace, because this is the first namespace where the name is found. It never gets to the global scope. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29618
[Bug fortran/29624] New: Fortran 2003: Support intent for pointers
(Belongs to the features already implemented in several compilers, including ifort, g95, NAG f95, absoft) The INTENT applies to the value of the pointer, not the thing being pointed to. Main points (from 5.1.2.7): The INTENT (IN) attribute for a pointer dummy argument specifies that during the execution of the procedure its association shall not be changed except that it may become undefined if the target is deallocated other than through the pointer. The INTENT (OUT) attribute for a pointer dummy argument specifies that on invocation of the procedure the pointer association status of the dummy argument becomes undefined. Any actual argument associated with such a pointer dummy shall be a pointer variable. The INTENT (INOUT) attribute for a pointer dummy argument specifies that it is intended for use both to receive a pointer association from and to return a pointer association to the invoking scoping unit. Any actual argument associated with such a pointer dummy shall be a pointer variable. If a dummy argument is a derived-type object with a pointer component, then the pointer as a pointer is a subobject of the dummy argument, but the target of the pointer is not. Therefore, the restrictions on subobjects of the dummy object apply to the pointer in contexts where it is used as a pointer, but not in contexts where it is dereferenced to indicate its target. Similarly, the INTENT restrictions on pointer dummy arguments apply only to the association of the dummy argument; they do not restrict the operations allowed on its target. A pointer object with the INTENT (IN) attribute shall not appear as (1) A pointer-object in a nullify-stmt, (2) A data-pointer-object or proc-pointer-object in a pointer-assignment-stmt, (3) An allocate-object in an allocate-stmt or deallocate-stmt, or (4) An actual argument in a reference to a procedure if the associated dummy argument is a pointer with the INTENT (OUT) or INTENT (INOUT) attribute. -- Summary: Fortran 2003: Support intent for pointers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29624
[Bug c++/29615] Class can't be friends of itself?
--- Comment #1 from bangerth at dealii dot org 2006-10-27 22:57 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-27 22:57:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29615
[Bug fortran/29606] Internal Error: Derived type I/O should have been handled via the frontend
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-27 23:05 --- Daniel, This is a general problem for gfortran. A pointer to a component of an array of derived types cannot, at the moment be represented. Some brave soul need to come up with a proposal as to how to do it and then to change every single client for array descriptors in gfortran. I periodically contemplate how to do it and recoil in horror at the size of the job. Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-27 23:05:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29606
[Bug c++/29106] [4.0/4.1 Regression] sizeof(*var) in expression drops entire line of code out of compile
--- Comment #6 from janis at gcc dot gnu dot org 2006-10-27 23:16 --- A regression hunt on the gcc-4_1-branch identified the following patch where the failure starts: http://gcc.gnu.org/viewcvs?view=revrev=111231 r111231 | mmitchel | 2006-02-18 08:37:34 + (Sat, 18 Feb 2006) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29106
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #10 from fkar at nemesis-project dot org 2006-10-27 23:39 --- Starting from http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options I compiled both BLAS/LAPACK using the following compiler flags: -fdefer-pop -fguess-branch-probability -fcprop-registers -fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra -ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time -fmerge-constants -fthread-jumps -fcrossjumping -foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks -fgcse -fgcse-lm -fexpensive-optimizations -frerun-cse-after-loop -fcaller-saves -fpeephole2 -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fregmove -fstrict-aliasing -fdelete-null-pointer-checks -freorder-blocks -freorder-functions -falign-functions -falign-jumps -falign-loops -falign-labels -ftree-vrp -ftree-pre -finline-functions -funswitch-loops -fgcse-after-reload which (including -fdelayed-branch which I deliberately ommited since I got complaints for not being supported on my platform), are set to be the default flags turned on by -O3. No infinitely looping was observed now for the above test cases, which means that the bug(?) exists in some other flag(s) triggerred by -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29625] New: Octal edit descriptors allow real variables, even with -std=f95
(Fortran version: GNU Fortran 95 (GCC) 4.2.0 20061015 (experimental)) Consider the following program: ~/temp/gfortran cat trans1.f90 program trans1 real :: a a = 1. write (*,(10x, f9.5) ) a write (*,( 1x, o20) ) transfer(a, 0) write (*,( 1x, o20) ) a end According to the Fortran 95 standard (section 10.5.1.1), the output list item corresponding to an O edit descriptor shall be of integer type. Although allowing real items is a perfectly reasonable extension when strict standard-conformance is not requested, when strict standard conformance is requested, the last of these write statements should produce an error. However, it does not: ~/temp/gfortran gfortran -std=f95 -Wall trans1.f90 -o trans1.exe ~/temp/gfortran ./trans1 1.0 774000 774000 -- Summary: Octal edit descriptors allow real variables, even with - std=f95 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29625
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-10-28 00:47 --- I built the libraries and the test program with two different builds on my XP box. One is more or less a default cygwin build, th eother is a mingw build I downloaded. They are dated about 10/11/2006 (10/10/2006). In both cases I get a clean execution of the resulting program. I wonder if you have a mingw or cygwin installation problem. Regarding your comment on optimization flags. -O3 is know to do some things not covered by the flags documented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #12 from fkar at nemesis-project dot org 2006-10-28 01:34 --- I used (on three different XP boxes) the source code as provided by netlib http://www.netlib.org/lapack/lapack.tgz, the latest gfortran binaries, namely http://quatramaran.ens.fr/~coudert/gfortran/gfortran-windows.exe, posted on http://gcc.gnu.org/wiki/GFortranBinaries, and dated 2006-10-21 (mingw build), and I followed the (fairly) straightforward instructions given in the description. I also used g77 (included in mingw 3.4.2., now dropped from the gcc mainline) always ending up in the same result, reproducible by anyone but me, hence I do not think that this should be filed then as a bug. I appreciate your time very much. Kind regards, F.E. Karaoulanis._ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2006-10-28 01:40 --- Subject: Re: lapack runs into infinite loop with -03 On Sat, Oct 28, 2006 at 01:34:48AM -, fkar at nemesis-project dot org wrote: I used (on three different XP boxes) the source code as provided by netlib http://www.netlib.org/lapack/lapack.tgz, the latest gfortran binaries, namely http://quatramaran.ens.fr/~coudert/gfortran/gfortran-windows.exe, posted on http://gcc.gnu.org/wiki/GFortranBinaries, and dated 2006-10-21 (mingw build), and I followed the (fairly) straightforward instructions given in the description. I also used g77 (included in mingw 3.4.2., now dropped from the gcc mainline) always ending up in the same result, reproducible by anyone but me, hence I do not think that this should be filed then as a bug. I appreciate your time very much. Are you building slamch.f and dlamch.f with -O3 or even -O1? Don't. These files try to determine machine values (e.g., epsilon). Optimization can give some really strange answers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #14 from fkar at nemesis-project dot org 2006-10-28 02:07 --- (In reply to comment #13) Are you building slamch.f and dlamch.f with -O3 or even -O1? Don't. These files try to determine machine values (e.g., epsilon). Optimization can give some really strange answers. Thank you!!! That totally solved the problem and now the program executes fine. Is this a bug after all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/28224] gfortran should support namelist (nml) for internal file units
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-10-28 02:34 --- There was a recent glibc update that came through on the distros that fixed that particular test case. I am unassigning myself since Tobias has got a good go at this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28224
[Bug c++/29618] argument dependent lookup: what about built-in types?
--- Comment #3 from v dot vasaitis at sms dot ed dot ac dot uk 2006-10-28 02:37 --- Interesting analysis. However, wouldn't this imply that the example I posted could be made to work if hash_value(long long) were put inside the boost namespace? Because it doesn't really; and in fact I can't find any way to make it work, and I'd be grateful if you could point one out to me. Which is the original purpose of this report I guess: Even if the standard isn't really clear about how situations like this should be handled, it'd be nice if g++ had at least one way to make them work, instead of none. Thanks, Vasilis -- v dot vasaitis at sms dot ed dot ac dot uk changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29618
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #15 from sgk at troutmask dot apl dot washington dot edu 2006-10-28 02:59 --- Subject: Re: lapack runs into infinite loop with -03 On Sat, Oct 28, 2006 at 02:07:00AM -, fkar at nemesis-project dot org wrote: Are you building slamch.f and dlamch.f with -O3 or even -O1? Don't. These files try to determine machine values (e.g., epsilon). Optimization can give some really strange answers. Thank you!!! That totally solved the problem and now the program executes fine. Is this a bug after all? No. It is very old Fortran code that tries to be clever. Unfortunately, aggressive optimization will break the cleverness. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #16 from kargl at gcc dot gnu dot org 2006-10-28 03:07 --- One final note. This behavior is described in the lapack FAQ. http://www.netlib.org/lapack/faq.html#1.25 -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug c++/29618] argument dependent lookup: what about built-in types?
--- Comment #4 from gdr at integrable-solutions dot net 2006-10-28 03:19 --- Subject: Re: argument dependent lookup: what about built-in types? v dot vasaitis at sms dot ed dot ac dot uk [EMAIL PROTECTED] writes: | Interesting analysis. However, wouldn't this imply that the example I posted | could be made to work if hash_value(long long) were put inside the boost | namespace? I don't see why. | Because it doesn't really; and in fact I can't find any way to make | it work, and I'd be grateful if you could point one out to me. the bugdatabase is about defects in the compiler suite, not about asking help to fix your programs. Please do not reopen bugs for the sole purpose of getting answers to questions that are best sent to appropriate newgroups. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29618
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #16 from ghazi at gcc dot gnu dot org 2006-10-28 03:20 ---
I'm getting wierd NaN results when I hook up __builtin_lgamma to mpfr_lngamma.
I can expose the problem using a standlone C program calling mpfr like so.
Results are first, C testcase is second. Now I know lgamma/mpfr_lngamma are
both documented to barf on negative integers. But as you can see, I'm passing
x.5 in every case. Seems like any time x is an even number I get a NaN. I
wonder if this is a bug in mpfr, or my mistake? (I tried mpfr-2.2.0 with and
without the cumulative patch. I got the problem in both cases.) Can anyone
else reproduce this?
lgamma(-4.50) = -2.813084
mpfr_lngamma(-4.50) = @NaN@
lgamma(-3.50) = -1.309007
mpfr_lngamma(-3.50) = -1.3090066849930420
lgamma(-2.50) = -0.056244
mpfr_lngamma(-2.50) = @NaN@
lgamma(-1.50) = 0.860047
mpfr_lngamma(-1.50) = 8.6004701537648098e-1
lgamma(-0.50) = 1.265512
mpfr_lngamma(-0.50) = @NaN@
#include stdio.h
#include math.h
#include gmp.h
#include mpfr.h
#define TESTIT(X) do { \
printf (lgamma(%.2f) = %f\n, (X), gamma(X)); \
mpfr_set_d(m, (X), GMP_RNDN); \
mpfr_lngamma(m, m, GMP_RNDN); \
printf (mpfr_lngamma(%.2f) = , (X)); \
mpfr_out_str (stdout, 10, 0, m, GMP_RNDN); \
putc ('\n', stdout); \
putc ('\n', stdout); \
} while (0)
int main()
{
mpfr_t m;
mpfr_init2(m, 53);
TESTIT(-4.5);
TESTIT(-3.5);
TESTIT(-2.5);
TESTIT(-1.5);
TESTIT(-0.5);
mpfr_clear(m);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #17 from sgk at troutmask dot apl dot washington dot edu 2006-10-28 03:48 --- Subject: Re: transcendental functions with constant arguments should be resolved at compile-time On Sat, Oct 28, 2006 at 03:20:11AM -, ghazi at gcc dot gnu dot org wrote: --- Comment #16 from ghazi at gcc dot gnu dot org 2006-10-28 03:20 --- I'm getting wierd NaN results when I hook up __builtin_lgamma to mpfr_lngamma. I can expose the problem using a standlone C program calling mpfr like so. Results are first, C testcase is second. Now I know lgamma/mpfr_lngamma are both documented to barf on negative integers. But as you can see, I'm passing x.5 in every case. Seems like any time x is an even number I get a NaN. I wonder if this is a bug in mpfr, or my mistake? (I tried mpfr-2.2.0 with and without the cumulative patch. I got the problem in both cases.) Can anyone else reproduce this? lgamma(-4.50) = -2.813084 mpfr_lngamma(-4.50) = @NaN@ Yes, I can reproduce the NaN. In fact, any negative value gives a NaN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug c++/29618] argument dependent lookup: what about built-in types?
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-28 03:56 --- This is DR 225 against the C++ standard about ADL and fundamental types. Here is what it says: In discussing issue 197, the question arose as to whether the handling of fundamental types in argument-dependent lookup is actually what is desired. This question needs further discussion. We already have a PR about that so this bug as invalid. -- 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=29618
[Bug target/24071] __gthread_active_p vs __gthread_once
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-10-28 05:36 --- About to submit a patch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at libertysurf dot| |fr | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-01 18:45:54 |2006-10-28 05:36:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071
