The program:
#include vector
#include absParse.hh
int main( int argc, char *argv[] )
{
std::vectorint 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
--- 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=11178action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
--- 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=11179action=view)
source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
--- 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
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 #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=11180action=view)
That's the function triggering the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26975
--- 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=11181action=view)
The full source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26975
--- 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?
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 =
,
with preprocessed source if appropriate.
See URL: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
--- 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
--- 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
(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.
Mainline (20060401) breaks too...same
--- 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\Lucascl /c pr5247.cc
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86
Copyright
--- 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 #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
--- 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 #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
--- 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-*-*
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
--- 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=gccview=revrev=112608
Log:
PR fortran/25270
* trans-array.c
--- 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 there
--- 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=gccview=revrev=112609
Log:
2006-04-01 Thomas Koenig [EMAIL PROTECTED]
PR
--- 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 #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 on the 4.1
--- 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
--- 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=gccview=revrev=112611
Log:
PR libfortran/24685
*
--- 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=gccview=revrev=112612
Log:
PR libfortran/24685
*
The following piece of code is compiled successfully ( g++ -ansi -pedantic
-Wall -c p6.C):
CODE
class Test {
friend void f() {};
};
void g(const Test t) {
f();
}
/CODE
I think it shouldn't compile because there is no explicitly declared f() in the
enclosing scope.
--
Summary:
--- 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 :).
And
--- 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
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 #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=11182action=view)
test case exposing the bug at -O1 with 4.2.0-20060401
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
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
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:
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.
--
-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 tries to reproduce Pascal problem
--- 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
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 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=11183action=view)
test case exposing the link error with -fpic with 4.2/20060401
--
http://gcc.gnu.org/bugzilla
--- 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 #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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||nathan at gcc dot gnu dot
|
--
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
--- 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
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- 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
--- 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 #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
--- 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
--- 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 #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 #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 #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
55 matches
Mail list logo
