--- Comment #14 from pinskia at gcc dot gnu dot org 2006-04-02 06:52
---
(In reply to comment #13)
> Any patch for gcc-3.4.6?
No, just use 4.1.0 or 4.0.2 instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15068
--- Comment #13 from shap at eros-os dot org 2006-04-02 06:48 ---
Any patch for gcc-3.4.6?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15068
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2006-04-02 06:38
---
Oops! I didn't mean to reopen it again...
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2006-04-02 06:36
---
> Does not matter, file a new bug about the testcase failing since this is only
> the testcase.
Please stop being so stubborn. :-) Anyway, I now hold you responsible for
making sure that something is done about
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-04-02 06:27
---
Does not matter, file a new bug about the testcase failing since this is only
the testcase.
See the thread starting at:
http://gcc.gnu.org/ml/fortran/2006-03/msg00487.html
The orginal bug has been fixed and ther
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2006-04-02 06:21
---
> We already had this discussion and yes it is not portable but that has already
> been fixed.
Andrew, you should really double-check what you say...
[EMAIL PROTECTED]:~/svn/gcc-4_1-branch/gcc/testsuite/gfortra
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-02 06:17 ---
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01747.html
That points out what caused it and how it was fixed and it was not a GCC bug
after all so closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-04-02 06:13
---
We already had this discussion and yes it is not portable but that has already
been fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last re
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-02 06:03 ---
"=ebp" (ret) : "ecx" (multiplier)
You are doing that all wrong.
those are constaints and not registers names like you have.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26977
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||nathan at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 05:49 ---
Fixed in 4.1.0 and above (I know this is a dup of another bug but I cannot find
it right now).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-02 05:36 ---
*** Bug 26979 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-02 05:36 ---
*** This bug has been marked as a duplicate of 25776 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rjpeters at klab dot caltech dot edu 2006-04-02 05:29
---
Created an attachment (id=11183)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11183&action=view)
test case exposing the link error with -fpic with 4.2/20060401
--
http://gcc.gnu.org/b
Using g++ from 4.2.0 daily snapshot 20060401:
$ ~/local/gcc-4.2-20060401/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /lab/rjpeters/build/gcc-4.2-20060401/configure
--enable-languages=c,c++ --prefix=/lab/rjpeters/local/gcc-4.2-20060401
--enable-shared --enable
--- Comment #1 from roger at eyesopen dot com 2006-04-02 03:07 ---
Damn. Unfortunately, although I have four different IA-64 boxes, one none
of them can I test Ada. Is it possible to attach the traceback of the
failure to the bugzilla PR? Clearly the fact that y is NULL_RTX at the
ass
exit status
Using gcc-4.2-20060401. The problem also shows up with gcc-4.0.2 and
gcc-4.1.0 on amd64. Also the problem shows in the output of a
cross-compiler targetting powerpc-apple-darwin7. The original problem
was discovered in GNU Pascal on powerpc-apple-darwin7 and the program
above tri
FAIL: g++.old-deja/g++.other/init19.C execution test
is present on platforms including hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11,
ia64-hp-hpux11.23. It looks like this test depends on __cxa_atexit being used,
and so should be conditioned on an appropriate effective-target for
__cxa_atexit.
--
FAIL: g++.old-deja/g++.other/init18.C (test for excess errors)
is present on platforms including hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11,
ia64-hp-hpux11.23. These platforms lack _Exit. The test should conditionally
use _exit where _Exit is unavailable.
--
Summary: g++.old-deja/g
The XFAIL has been removed from g++.old-deja/g++.other/init5.C, but we still
have
FAIL: g++.old-deja/g++.other/init5.C execution test
on platforms including hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 and
ia64-hp-hpux11.23.
--
Summary: g++.old-deja/g++.other/init5.C execution test fa
--- Comment #1 from rjpeters at klab dot caltech dot edu 2006-04-02 00:58
---
Created an attachment (id=11182)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11182&action=view)
test case exposing the bug at -O1 with 4.2.0-20060401
--
http://gcc.gnu.org/bugzilla/show_
Using the 20060401 g++ 4.2 snapshot, built with checking enabled:
$ ~/local/gcc-4.2-20060401/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /lab/rjpeters/build/gcc-4.2-20060401/configure
--enable-languages=c,c++ --prefix=/lab/rjpeters/local/gcc-4.2-20060401
--enable
--- Comment #13 from rupert dot swarbrick at lineone dot net 2006-04-01
23:19 ---
(In reply to comment #11)
> The same problem stays unresolved in GCC-3.4.4
As far as I can tell, the problem is STILL unresolved with g++ 4.1, but there
is a workaround for users that I post here for in
--- Comment #6 from rankincj at yahoo dot com 2006-04-01 23:00 ---
Subject: Re: Compile/link failure with -frepo and g++ 4.1
--- pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote:
> Well if you read the instructions on how to report a bug, a tar file is not
> really liked :).
A
The following piece of code is compiled successfully ( g++ -ansi -pedantic
-Wall -c p6.C):
class Test {
friend void f() {};
};
void g(const Test &t) {
f();
}
I think it shouldn't compile because there is no explicitly declared f() in the
enclosing scope.
--
Summary: Friend func
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-04-01 21:35
---
Subject: Bug 24685
Author: ebotcazou
Date: Sat Apr 1 21:35:34 2006
New Revision: 112612
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112612
Log:
PR libfortran/24685
* gfortran.dg/large
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-04-01 21:34
---
Subject: Bug 24685
Author: ebotcazou
Date: Sat Apr 1 21:34:27 2006
New Revision: 112611
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112611
Log:
PR libfortran/24685
* gfortran.dg/large
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-04-01 21:26
---
(In reply to comment #13)
> It seems to me that the whole #else branch of the #if __APPLE__ statement
> should be removed, together with the #if statement itself.
Right. I tested a bit with sqrt() SSE2 instructi
--- Comment #16 from kargl at gcc dot gnu dot org 2006-04-01 20:48 ---
(In reply to comment #15)
> > No, it isn't portable to big endian. How are you executing this
> > test.
>
> gmake -k check-fortran. :-)
>
> > I added a { target i?86-*-* x86_64-*-* } to the dg-do clause.
>
> Not
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-04-01 20:09 ---
Also fixed on 4.1. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-04-01 20:08 ---
Subject: Bug 26735
Author: tkoenig
Date: Sat Apr 1 20:08:39 2006
New Revision: 112609
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112609
Log:
2006-04-01 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-04-01 20:05
---
> No, it isn't portable to big endian. How are you executing this
> test.
gmake -k check-fortran. :-)
> I added a { target i?86-*-* x86_64-*-* } to the dg-do clause.
Not on the 4.1 branch. And why? Is ther
--- Comment #5 from sayle at gcc dot gnu dot org 2006-04-01 19:19 ---
Subject: Bug 25270
Author: sayle
Date: Sat Apr 1 19:19:22 2006
New Revision: 112608
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112608
Log:
PR fortran/25270
* trans-array.c (gfc_trans_allo
The patch for PR17959 breaks Ada on ia64.
Starting program: /tmp/cvs/gcc-test-r112543/Build/gcc/gnat1 -quiet -dumpbase
g-altcon.adb -O2 -W -Wall -fPIC -g -gnatpg -gnatO g-altcon.o g-altcon.adb
Program received signal SIGSEGV, Segmentation fault.
0x408d8da1 in emit_move_insn (x=0x2
--- Comment #14 from kargl at gcc dot gnu dot org 2006-04-01 17:24 ---
(In reply to comment #13)
> Is transfer_array_intrinsic_1.f90 portable to big-endian? It fails on SPARC.
>
No, it isn't portable to big endian. How are you executing this
test. I added a { target i?86-*-* x86_64-
--- Comment #13 from schnetter at aei dot mpg dot de 2006-04-01 17:21
---
Regarding a generic mechanism for both ppc and i386 on Darwin:
I looked at the header files in /usr/include on my Darwin 8.5.2 system, which
contain the architecture specific files for both ppc and i386. While t
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-04-01 17:10
---
Is transfer_array_intrinsic_1.f90 portable to big-endian? It fails on SPARC.
Reduced testcase:
integer(4) :: y(4)
character(4) :: ch(4)
y = (/(i + ishft (i + 1, 8) + ishft (i + 2, 16) &
--- Comment #14 from zerocool at modemsoft dot it 2006-04-01 17:07 ---
(In reply to comment #13)
> As you can see from the backtrace, the problem is in "gcc/java/jcf-io.c" at
> line number 394 where we make a call to scandir(). I'm not an alpha-linux
> hacker, but I see that there's scan
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-01 15:42 ---
Note that you definitely need -fno-strict-aliasing from looking at hdf5 the
last time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26968
--- Comment #16 from bsdfan3 at users dot sourceforge dot net 2006-04-01
13:11 ---
MSVC8 also manages a sensible error message on the testcase from this bug:
C:\cygwin\home\Lucas>cl /c pr5247.cc
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86
Copyright (C
; $ gcc --version
> gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
&
--- Comment #8 from bsdfan3 at users dot sourceforge dot net 2006-04-01
13:05 ---
GCC 3.4.4 seems to compile the testcase fine though (sorry about the linker
error, nobody specified -c on the build command line):
[EMAIL PROTECTED] ~
$ gcc t1.cc -save-temps --param ggc-min-expand=0 --par
--- Comment #1 from pault at gcc dot gnu dot org 2006-04-01 13:03 ---
Thanks for reporting this, Dominique. As it happens (fancy that!), I will be
posting a patch in the next 24hours.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Ad
preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED] ~
$ mainline-gcc --version
mainline-gcc (GCC) 4.2.0 20060401 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. Th
Programs such as
real(4) :: pi, a(2), b(3)
pi = acos(-1.0)
b = pi
a = cos(b)
a = -pi
b = cos(a)
print *, b
end
does not report errors. It should give
In file conform_1.f90:4
a = cos(b)
1
Error: Array assignment at (1) has different shape on dimension 1 (2/3)
In file conform_1.f90:6
b =
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-04-01 10:07
---
(In reply to comment #11)
> 4.1.x is broken for i686-darwin other ways so this is not to be fixed for
> there.
If 4.1.x is broken, how do you explain that g95 (based on 4.0.3 or 4.1.0) is
working on i686-darwin?
--- Comment #2 from konrad at egipt-medytacje dot pl 2006-04-01 10:02
---
Created an attachment (id=11181)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11181&action=view)
The full source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26975
--- Comment #1 from konrad at egipt-medytacje dot pl 2006-04-01 10:01
---
Created an attachment (id=11180)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11180&action=view)
That's the function triggering the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26975
gcc40 tcnumfl_warp2.c -Wall -O2 -pipe -g -finline -o tcnumfl_warp2
tcnumfl_warp2.c: In function 'main':
tcnumfl_warp2.c:156: error: unrecognizable insn:
(insn:HI 693 1382 694 91 tcnumfl_warp2.c:399 (parallel [
(set (mem:SI (plus:SI (reg/f:SI 6 bp)
(const_int -68
--- Comment #5 from pcarlini at suse dot de 2006-04-01 09:17 ---
Yes, too bad #pragma GCC system_header doesn't help here. Can somebody remind
me exactly why and whether it's fixable?
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from igodard at pacbell dot net 2006-04-01 08:26 ---
Created an attachment (id=11179)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11179&action=view)
source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
--- Comment #1 from igodard at pacbell dot net 2006-04-01 08:25 ---
Created an attachment (id=11178)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11178&action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
The program:
#include
#include "absParse.hh"
int main( int argc, char *argv[] )
{
std::vector v;
v.resize(1);
return 0;
}
compiles but gets a segv in the resize() call on several different g++
versions. The problem seems to have something to do with declarations of
operator,() in absParse
55 matches
Mail list logo
