--- 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=gccview=revrev=138564
Log:
PR target/36992
* config/i386/sse.md
--- 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 #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 #5 from livubuntu at lalescu dot ro 2008-08-03 07:23 ---
(In reply to comment #4)
(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
--- Comment #4 from burnus at gcc dot gnu dot org 2008-08-03 07:23 ---
Created an attachment (id=16001)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16001action=view) [edit]
better patch
I think some of the run-time checks (with -fbounds-checks) for PR 36874 can be
best done in
--- Comment #4 from alex at ozo dot com 2008-08-03 08:33 ---
trying to compile ath9k for mips or mipsel under openwrt toolchain with
gcc-4.2.4 produces the following error:
make[3]: Entering directory `/extra3/openwrt/ar71xx/trunk/package/ath9k'
make -C
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-08-03 09:22 ---
(In reply to comment #4)
Created an attachment (id=16001)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16001action=view) [edit]
better patch
I think some of the run-time checks (with -fbounds-checks)
--- Comment #1 from ubizjak at gmail dot com 2008-08-03 09:16 ---
Stack asm constraints have some annoying properties. Please note, that in your
testcase, value in %st1 isn't popped from the stack. Also, reverse subtract can
be used to avoid fxch. I propose to rewrite your function as:
trying to compile ath9k for mips or mipsel under openwrt toolchain with
gcc-4.2.4 produces the following error:
make[3]: Entering directory `/extra3/openwrt/ar71xx/trunk/package/ath9k'
make -C /extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/linux-2.6.26
ARCH=mips
--- Comment #5 from alex at ozo dot com 2008-08-03 08:43 ---
please discard the above entry and accept my apologies as this is my first
attempt to report a bug issue using bugzilla.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
--- Comment #2 from sam at gcc dot gnu dot org 2008-08-03 12:04 ---
It appears to be fixed already in GCC 4.3.1.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sam at gcc dot gnu dot org 2008-08-03 12:07 ---
Confirmed on 4.4.0 20080803 (i686-pc-linux-gnu).
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sam at gcc dot gnu dot org 2008-08-03 12:08 ---
Confirmed on SVN trunk:
+===GNAT BUG DETECTED==+
| 4.4.0 20080803 (experimental) (i686-pc-linux-gnu) Assert_Failure
einfo.adb:2446|
| Error detected at b.ads:1:6
--- Comment #15 from andry at inbox dot ru 2008-08-03 12:18 ---
I found where the bug is:
/mingw/lib/libmsvcrt.a and /mingw/lib/libmsvcrtd.a should be Microsoft
Visual Studio v6.0 libraries. I just run gccmrt.bat attached to TDM builds of
GCC (http://www.tdragon.net/recentgcc/) and
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #3 from ubizjak at gmail dot com 2008-08-03 16:59 ---
GNU C (GCC) version 4.4.0 20080803 (experimental) is now much smarter, several
rewrites of math ops now result in:
foobar:
pushl %ebp
movl%esp, %ebp
fldsa
fmuls b
flds
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-03 17:01 ---
Please narrow down where the problem is since we don't have MacOS:
1. Turn eh-alloca-1.ii into eh-alloca-1.C by removing those
# x
2. Remove abort from eh-alloca-1.C one by one to track down
to single abort.
--- Comment #4 from ubizjak at gmail dot com 2008-08-03 17:23 ---
The testcase works OK with gcc-4.3.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2008-08-03 17:30 ---
This enhancement was implemented at least for gcc-4.3.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #6 from ubizjak at gmail dot com 2008-08-03 17:38 ---
Can we have a final word from ABI people here please?
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #8 from ubizjak at gmail dot com 2008-08-03 17:44 ---
CCing HJ for ABI issue.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-08-03
17:52 ---
The eh-alloca-1.exe always segfaults even after commenting all of the abort()
calls. I'll see if I can find one of the gcc c testsuite executions that are
failing as that may be easier to debug.
--
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-03 18:18 ---
(In reply to comment #1)
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00123.html
This patch is incorrect. The problem is between ACCUMULATE_OUTGOING_ARGS,
ix86_compute_frame_layout and
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-08-03
18:19 ---
Another of the testsuite execution tests that are failing is regparm-1.exe.
When compiled as in the testsuite run as...
gcc-4 ./regparm-1.c -Os -mstackrealign -mpreferred-stack-boundary=5 -g -fpic
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-08-03
18:22 ---
Created an attachment (id=16004)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16004action=view)
preprocessed source file for gcc.dg/torture/stackalign/regparm-1.c
--
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-08-03
18:22 ---
Created an attachment (id=16005)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16005action=view)
assembly file for gcc.dg/torture/stackalign/regparm-1.c
--
--- Comment #3 from hjl dot tools at gmail dot com 2008-08-03 18:40 ---
Joey, when we compute frame layout, we don't count the duplicated
return address pushed onto stack when DRAP is used. Also when we
push return address, shouldn't we use -UNITS_PER_WORD, instead of
-(STACK_BOUNDARY /
--- Comment #9 from hjl dot tools at gmail dot com 2008-08-03 18:48 ---
Joey, I think the problem is the usage of STACK_BOUNDARY / BITS_PER_UNIT
for stack alignment. On MacOS, STACK_BOUNDARY 128 on ia32. Shouldn't
we use UNITS_PER_WORD in some cases? Please double check all usages of
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-08-03 18:54
---
The regparm-* failures are really PR 26553.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
--- Comment #11 from hjl dot tools at gmail dot com 2008-08-03 19:26
---
Created an attachment (id=16006)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16006action=view)
A patch
Jack, can you try this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-03 20:11 ---
A run-time testcase:
bash-3.2$ cat y.c
/* PR middle-end/37010 */
/* { dg-do run { target { { i?86-*-* x86_64-*-* } ilp32 } } } */
/* { dg-options -msse2 } */
typedef __PTRDIFF_TYPE__ ptrdiff_t;
extern void abort
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-08-03
20:24 ---
HJ,
Your proposed patch eliminated all the stackalign failures in 'make -k
check-gcc' reducing the total gcc failures down to 14 unexpected. I will do a
'make -k check-g++' next but this fix looks good
--- Comment #13 from hjl dot tools at gmail dot com 2008-08-03 20:26
---
(In reply to comment #12)
HJ,
Your proposed patch eliminated all the stackalign failures in 'make -k
check-gcc' reducing the total gcc failures down to 14 unexpected. I will do a
'make -k check-g++' next
using negative numbers, like for example
(-1)%4 results in -1 instead of the right result, which is 3
--
Summary: modulo operations which use negative numbers return
unexpected results
Product: gcc
Version: 4.3.1
Status:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-03 20:32 ---
That is correct. % is not really the modulo operator but instead the remainder
operator :). So (-a) %b is the same as -(a%b).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
#include iostream
/*
Basic design concept is that WorldObject implements remote method call
functionality using the curiously recurring template pattern to enable
forwarding calls from the generic
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-03 21:47 ---
Confirmed.
SRA messing up again when there is different FIELD decls.
itemfunptrD.21695.__pfnD.21700 ={v} itemfunD.21696;
memfunD.24341 ={v} itemfunptrD.21695;
memfun$__pfnD.24346_4 =
When configuring with --enable-threads=solaris the build runs for hours and
then breaks after the libgfortran finished when configuring boehm-gc .
It would be nice if the main configure script caught this instead of the build
failing just as it was about to finish.
I am building gcc-4.2.3
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-03 23:08 ---
I really don't think using solaris threads is that well supported anymore. Is
there a reason why you are not using just --enable-threads=pthreads?
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #1 from dje at gcc dot gnu dot org 2008-08-03 23:59 ---
This is fixed in G++ 4.3, probably due to a libstdc++ fix.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2008-08-04
00:53 ---
The complete make check from the boot strap is still running but the g++
stackalign failures have been reduced down to just...
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O3 -g execution test
FAIL:
--- Comment #2 from rob1weld at aol dot com 2008-08-04 01:28 ---
Is there a reason why you are not using just --enable-threads=pthreads?
A few reasons.
1. I test _all_ of gcc's configure options, submit bug reports and email test
results - --enable-threads=solaris is a valid choice.
In this sample, which includes inline assembly code, GCC produces assembly that
uses 64-bit registers when the target is 32-bit code. The assembler complains:
foo.c: Assembler messages:
foo.c:17: Error: bad register name `%dil'
--
Summary: compiling inline assembly for ia32
--- Comment #1 from gcc at karrels dot org 2008-08-04 01:35 ---
Created an attachment (id=16007)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16007action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37018
--- Comment #2 from gcc at karrels dot org 2008-08-04 01:37 ---
Created an attachment (id=16008)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16008action=view)
Output from gcc -v -save-temps -O -c foo.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37018
--- Comment #3 from gcc at karrels dot org 2008-08-04 01:39 ---
(In reply to comment #0)
Bug only occurs with optimization turned on.
--
gcc at karrels dot org changed:
What|Removed |Added
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2008-08-04
02:32 ---
Testresults from the proposed patch are at...
http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00333.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
--- Comment #16 from hjl dot tools at gmail dot com 2008-08-04 03:26
---
(In reply to comment #14)
The complete make check from the boot strap is still running but the g++
stackalign failures have been reduced down to just...
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O3 -g
The gcc-4.2.3/libjava/configure uses grep and egrep and grep -E and
$EGGREP (but not ggrep) in a non-portable and inconsistent manner.
Examples:
1. Lines 5224, 5254, 5295, 5298, etc... use egrep but EGREP is not tested
for (to decide if we will use grep -E or egrep) until line 7315 and not set
--- Comment #5 from hjl dot tools at gmail dot com 2008-08-04 05:52 ---
It is the problem with -mno-accumulate-outgoing-args:
bash-3.2$ /export/build/gnu/gcc-avx/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -m32 -msse2 -DDEBUG
50 matches
Mail list logo
