--- Comment #17 from ubizjak at gmail dot com 2008-08-03 06:49 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rob1weld at aol dot com 2008-08-03 06:29 ---
Reopened - Broken in 4.2.2 and 4.2.3 also.
--
rob1weld at aol dot com changed:
What|Removed |Added
--- Comment #16 from uros at gcc dot gnu dot org 2008-08-03 06:14 ---
Subject: Bug 36992
Author: uros
Date: Sun Aug 3 06:13:04 2008
New Revision: 138564
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138564
Log:
PR target/36992
* config/i386/sse.md (vec_concatv2
--- 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 minor
--- 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
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 #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++/../../
/sw/
--- 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=16003&action=view)
preprocessed source file for g++.dg/torture/stackalign/eh-alloca-1.C
--
http://gcc.gnu.org/bugzil
--- 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=16002&action=view)
assembly file for g++.dg/torture/stackalign/eh-alloca-1.C
--
http://gcc.gnu.org/bugzilla/show_bug
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 gdb,
--
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
--- 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:
--- 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 pat
--- 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
Win
--- 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 #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
---
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: multi
--- 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=16001&action=view)
better patch
This one is better :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
--- 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=16000&action=view)
proposed patch for cshift0
Here's something that works for cshift0.
cshift1 still to do...
--
http://gcc.
--- 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 (r
--- 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 me
--- 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 perfec
--- 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* v
--- 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
Stat
--- 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 #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
Status|RES
--- 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
Status|N
--- 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
Status|UNCO
--- 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 #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 #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 #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: Ther
-Os passes __m128 on stack with wrong alignment:
bash-3.2$ cat x.c
#include
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
-B/export/build/gnu/g
--- 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\...
--
http:
--- 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
===
--- config/i386/
--- 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 #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 #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 #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 #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)
+++ testsuite/gcc.target/i386/pr36992.
--- 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 -fasync
m0, 8(%esp)
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 (exper
--- 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
--- 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 |Ad
--- Comment #10 from ubizjak at gmail dot com 2008-08-02 13:10 ---
"←" in my previous post represents left pointing arrow, <.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
--- Comment #9 from ubizjak at gmail dot com 2008-08-02 13:08 ---
Hm, IA-32 Intel® Architecture Software Developers Manual says about movq:
Operation
MOVQ instruction when operating on MMX technology registers and memory
locations:
DEST ← SRC;
MOVQ instruction when source and destin
--- 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 #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 vecto
--- 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 unlike
--- 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=gcc&view=rev&rev=138553
Log:
2008-08-02 Richard Guenther <[EMAIL PROTECTED]>
PR
--- 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=15999&action=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 #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=15998&action=view)
disable-asserts.patch
Quick hack to disable asserts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
--- 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
S
--
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 #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=15997&action=view)
unincluded testcase
Testcase that works with either -m32/-m64 and all libstdc++ versions.
--
http://gcc.gn
--- 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 re
--- 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 #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?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=369
--- 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 availab
--- 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=15996&action=view)
The .ii file (archived with zip)
The .ii file obtained by -save-temps command to g++ (archived with zip)
--
h
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 spec
61 matches
Mail list logo
