--- 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
--- 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
--- 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
--- 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:
--- 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
--- 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:
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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 == '%')
{
--- 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
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
--- 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.
--- 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
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
--- 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,
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
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:
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;
--- 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
--- 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
--- 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 {}
};
--- 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
./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
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
--- 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
`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.
--- 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
--- 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
--- 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.
--
--- 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
--- 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
(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 :
$
--- 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
--- 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
--- 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
--- 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
--- 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):
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
(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
--- Comment #1 from bangerth at dealii dot org 2006-10-27 22:57 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- 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
--- 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
--- 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
(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
--- 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
--- 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
--- 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
--- 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.
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 #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
--- 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
71 matches
Mail list logo
