My open source application FET compiles OK with g++ 4.1.3. But with 4.2.3 it
crashes on a bigger file named rules.cpp. My FET program is available at
http://lalescu.ro/liviu/fet/
I have 1 GB of RAM, AMD dual core 4000+
The g++ version:
[EMAIL PROTECTED]:~/t/fet-5.6.1$ gcc -v
Using built-in
--- Comment #1 from livubuntu at lalescu dot ro 2008-08-02 07:30 ---
Created an attachment (id=15996)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15996action=view)
The .ii file (archived with zip)
The .ii file obtained by -save-temps command to g++ (archived with zip)
--
--- Comment #6 from jh at suse dot cz 2008-08-02 10:49 ---
Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64
UNIX
If you provide a preprocessed testcase maybe he can. Otherwise patches
welcome
I guess.
Done. Unfortunately, I won't be available for
--- Comment #7 from andry at inbox dot ru 2008-08-02 11:10 ---
(In reply to comment #6)
This kind of path
'--prefix=/c/_GccBuilds/gcc-4.3.1-install/mingw-32-i686' may be understood by
But this is Mingw compatible path, isn't it?
--
--- Comment #7 from jh at suse dot cz 2008-08-02 11:31 ---
Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64
UNIX
Looks like Aplha is not tuplified yet?
../../gcc/config/alpha/alpha.c: In function 'va_list_skip_additions':
../../gcc/config/alpha/alpha.c:5815:
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-02 11:47 ---
g++: Internal error: Killed (program cc1plus)
this means your system ran out of memory and the operating system decided
to kill the compiler. Note that memory usage problems are unlikely to be
fixed in a further
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-02 11:48 ---
Created an attachment (id=15997)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15997action=view)
unincluded testcase
Testcase that works with either -m32/-m64 and all libstdc++ versions.
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Crash bug on a big c++ file |[4.2 Regression] OOM on a
|
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-02 11:50 ---
Confirmed by the dup.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2008-08-02 11:53 ---
Created an attachment (id=15998)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15998action=view)
disable-asserts.patch
Quick hack to disable asserts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
--- Comment #6 from jakub at gcc dot gnu dot org 2008-08-02 11:57 ---
Created an attachment (id=15999)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15999action=view)
sp=reg.patch
Untested patch to set args_size to 0 when encountering (set (reg sp) (reg di))
etc.
I'll be offline
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-08-02 12:06 ---
Subject: Bug 35252
Author: rguenth
Date: Sat Aug 2 12:05:47 2008
New Revision: 138553
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138553
Log:
2008-08-02 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from livubuntu at lalescu dot ro 2008-08-02 12:21 ---
(In reply to comment #2)
g++: Internal error: Killed (program cc1plus)
this means your system ran out of memory and the operating system decided
to kill the compiler. Note that memory usage problems are unlikely
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-02 12:21 ---
Operations in loops should now be vectorized. The original testcase is
probably not worth vectorizing due to calling convention problems (_Complex T
is not passed as a vector).
Complex lowering could generate
--- Comment #4 from ubizjak at gmail dot com 2008-08-02 13:00 ---
(In reply to comment #3)
Operations in loops should now be vectorized. The original testcase is
probably not worth vectorizing due to calling convention problems (_Complex T
is not passed as a vector).
Not really.
--- Comment #9 from ubizjak at gmail dot com 2008-08-02 13:08 ---
Hm, IA-32 Intel® Architecture Software Developer’s Manual says about movq:
Operation
MOVQ instruction when operating on MMX technology registers and memory
locations:
DEST #8592; SRC;
MOVQ instruction when source and
--- Comment #10 from ubizjak at gmail dot com 2008-08-02 13:10 ---
#8592; in my previous post represents left pointing arrow, .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-08-02 13:18 ---
Doh, this is indeed completely broken ;) I'll experiment with lowering
complex operations to vectorized form a bit.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from ubizjak at gmail dot com 2008-08-02 13:22 ---
Uh, clearing of top bits is explicitly stated in latest Software Developer's
Manual for both movq and movd. I'll fix these patterns.
--
ubizjak at gmail dot com changed:
What|Removed
)
callfoo
movl$0, %eax
leave
ret
.size bar, .-bar
.section.rodata
.align 16
.LC0:
.long 1065353216
.long 0
.long 0
.long 0
.ident GCC: (GNU) 4.4.0 20080802 (experimental) [stack
--- Comment #7 from kkojima at gcc dot gnu dot org 2008-08-02 15:02 ---
I've tested the 2nd patch on sh4, but it doesn't fix the ICE
on sh4. Perhaps the problem is slightly different from that
for i586. Here is a reduced test case for the sh-elf compiler
with the option '-m4 -O
--- Comment #12 from ubizjak at gmail dot com 2008-08-02 15:07 ---
Patch in testing:
Index: testsuite/gcc.target/i386/pr36992.c
===
--- testsuite/gcc.target/i386/pr36992.c (revision 0)
+++
--- Comment #8 from jakub at gcc dot gnu dot org 2008-08-02 15:17 ---
If a label is reachable from different args_size levels, that's a severe bug
and should be fixed wherever that is created, likely expander.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
--- Comment #13 from hjl dot tools at gmail dot com 2008-08-02 15:19
---
We should also test -O0. This code:
extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_movpi64_epi64 (__m64 __A)
{
return _mm_set_epi64 ((__m64)0LL, __A);
}
extern
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-02 15:28 ---
AFAIK, the error is a request of the c++0x standard and it seems -0.02435L does
not fit exactly in a float while -0.25L does, so the message is correct and I
thus I don't think there is a bug here.
Perhaps it should
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-08-02 15:49
---
Untested patch to set args_size to 0 when encountering (set (reg sp) (reg di))
etc.
OK on i586-linux (C/C++/Ada) on both the mainline and the 4.3 branch.
--
ebotcazou at gcc dot gnu dot org changed:
--- Comment #14 from ubizjak at gmail dot com 2008-08-02 16:01 ---
(In reply to comment #13)
We should also test -O0.
Usage of MMX regs with -O0 is fixed by following patch:
Index: config/i386/mmx.md
===
---
--- Comment #8 from brian at dessent dot net 2008-08-02 16:56 ---
Subject: Re: cc1.exe: internal compiler error: Segmentation
fault
It's a valid MinGW path only if you have created a physical directory
named c at the root of the current drive, i.e. X:\c\_GccBuilds\...
--
-Os passes __m128 on stack with wrong alignment:
bash-3.2$ cat x.c
#include emmintrin.h
extern void foo (__m128 x, __m128 y ,__m128 z ,__m128 a, int size);
void
bar (void)
{
__m128 x = { 1.0 };
foo (x, x, x, x, 5);
}
bash-3.2$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
--- Comment #9 from andry at inbox dot ru 2008-08-02 18:01 ---
(In reply to comment #8)
It's a valid MinGW path only if you have created a physical directory
named c at the root of the current drive, i.e. X:\c\_GccBuilds\...
From /msys/1.0/doc/MSYS_VS_CYGWIN:
/cygdrive: There is no
--- Comment #23 from mkuvyrkov at gcc dot gnu dot org 2008-08-02 18:15
---
(In reply to comment #22)
Maxim, have you had time to look at this bug? Given that it is generating bad
code and is in 4.3.0 and 4.3.1 I was wondering if it will be fixed for 4.3.2.
Sorry for the delay. I
--- Comment #2 from chris dot fairles at gmail dot com 2008-08-02 18:41
---
(In reply to comment #1)
AFAIK, the error is a request of the c++0x standard and it seems -0.02435L
does
not fit exactly in a float while -0.25L does, so the message is correct and I
thus I don't think
--- Comment #15 from ubizjak at gmail dot com 2008-08-02 18:43 ---
Complete patch at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00116.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-02 19:02 ---
OK. Invalid then.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2008-08-02 19:03 ---
INVALID (not FIXED).
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2008-08-02 19:03 ---
Wrong bug (argh!).
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-02 19:04 ---
Reopened...
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-02 19:05 ---
... to close as INVALID.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from brian at dessent dot net 2008-08-02 19:24 ---
Subject: Re: cc1.exe: internal compiler error: Segmentation
fault
/c/foo/bar is valid for *MSYS* apps. But we're talking about gcc which
is NOT a MSYS app, it is a MinGW app, i.e. native win32. /c/foo/bar is
*not*
--- Comment #11 from andry at inbox dot ru 2008-08-02 20:41 ---
/c/foo/bar is valid for *MSYS* apps. But we're talking about gcc which
is NOT a MSYS app, it is a MinGW app, i.e. native win32. /c/foo/bar is
*not* valid for such an app.
Not true, for example, Mingw GCC 3.4.4
--- Comment #12 from brian at dessent dot net 2008-08-02 21:02 ---
Subject: Re: cc1.exe: internal compiler error: Segmentation
fault
You're not really testing what you think you are, because MSYS
translates everything on the command line, so saying that gcc
-I/foo/bar works just
--- Comment #10 from kkojima at gcc dot gnu dot org 2008-08-02 22:12
---
(In reply to comment #8)
If a label is reachable from different args_size levels, that's a severe bug
and should be fixed wherever that is created, likely expander.
It seems that arg_size is reset with (set
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-08-02 23:43 ---
Created an attachment (id=16000)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16000action=view)
proposed patch for cshift0
Here's something that works for cshift0.
cshift1 still to do...
--
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-08-02 23:49 ---
Created an attachment (id=16001)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16001action=view)
better patch
This one is better :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
F2003, sec. 4.5.1 (derived type definition): EXTENDS is an attribute that can
not be specified more than once. Currently (20080803), gfortran accepts:
TYPE :: b
INTEGER :: i
END TYPE
TYPE, EXTENDS(b), EXTENDS(b) :: d
INTEGER :: j
END TYPE
--
Summary: F2003, type extension:
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-03 00:37 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00123.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-03 00:54 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00124.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #13 from andry at inbox dot ru 2008-08-03 01:50 ---
(In reply to comment #12)
You're not really testing what you think you are
Ok, i found that Msys console converts all application arguments and
environment variables before run any application. So, i missed out that in
--- Comment #14 from andry at inbox dot ru 2008-08-03 02:42 ---
(In reply to comment #12)
MinGW apps like gcc have *no* way of interpreting anything but Win32 paths.
It is, i found that Msys bash shell (not console) converts all this stuff with
Msys paths. So xgcc already gothering
--- Comment #6 from jason at gcc dot gnu dot org 2008-08-03 03:01 ---
There is an open issue about this problem which should be addressed at the next
meeting. I'm quite sure this will not be invalid C++0x when the standard is
finished.
--
jason at gcc dot gnu dot org changed:
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
Current gcc trunk exhibits a number of stackalign execution related testsuite
failures on i686-apple-darwin9...
http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00184.html
One example is g++.dg/torture/stackalign/eh-alloca-1.C which fails in the
execution tests at all optimization levels. In
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-08-03
04:27 ---
Created an attachment (id=16002)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16002action=view)
assembly file for g++.dg/torture/stackalign/eh-alloca-1.C
--
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-08-03
04:28 ---
Created an attachment (id=16003)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16003action=view)
preprocessed source file for g++.dg/torture/stackalign/eh-alloca-1.C
--
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-08-03
04:30 ---
This testcase is compiled with...
/sw/src/fink.build/gcc44-4.3.999-20080801/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc44-4.3.999-20080801/darwin_objdir/gcc/testsuite/g++/../../
OpenSolaris is available free from: http://opensolaris.org/
I am building gcc-4.2.1 release from:
ftp://ftp.gnu.org/gnu/gcc/gcc-4.2.1/gcc-4.2.1.tar.bz2
When building gcc on Solaris operating systems it is required (by Sun) that you
use --prefix=..., --with-gmp=..., --with-mpfr=..., (and
--- Comment #1 from kargl at gcc dot gnu dot org 2008-08-03 04:58 ---
what happens with gcc versions 4.2.2, 4.2.3, 4.2.4, 4.3.0, and 4.3.1?
In other words, 4.2.1 is history and is completely and utterly
unsupported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37013
--- Comment #2 from rob1weld at aol dot com 2008-08-03 05:12 ---
4.2.1 is history and is completely and utterly unsupported.
OK.
Directory ftp://ftp.gnu.org/gnu/gcc/ says the date is 07/20/07 so it is barely
over one year old. I desire to build a 4.2.x series so I'll move up one
58 matches
Mail list logo
