[Bug target/36992] Very stange code for _mm_move_epi64
--- 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 (vec_concatv2di): Add Y2 constraint to alternative 0 of operand 1. (*vec_concatv2di_rex64_sse): Ditto. (*vec_concatv2di_rex64_sse4_1): Add x constraint to alternative 0 of operand 1. (*sse2_storeq_rex64): Penalize allocation of r registers. * config/i386/mmx.md (*movmode_internal_rex64): Penalize allocation of Y2 registers to avoid SSE - MMX conversions for DImode moves. (*movv2sf_internal_rex64): Ditto. testsuite/ChangeLog: PR target/36992 * gcc.target/i386/pr36992-1.c: New test. * gcc.target/i386/pr36992-2.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/i386/pr36992-1.c trunk/gcc/testsuite/gcc.target/i386/pr36992-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mmx.md trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug bootstrap/37013] gcc-4.2.1 build breaks in fortran when using --with-mpfr=
--- 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 Status|RESOLVED|UNCONFIRMED Known to fail||4.2.1 4.2.2 4.2.3 Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37013
[Bug target/36992] Very stange code for _mm_move_epi64
--- 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|RESOLVED GCC target triplet||x86-pc-linux-gnu Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36992
[Bug c++/37008] [4.2 Regression] OOM on a big c++ file
--- 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 memory usage problems are unlikely to be fixed in a further release of GCC 4.2, but you might want to try GCC 4.3.1 or later which uses less memory than GCC 4.1 for your testcase. I tried the GCC 4.3.1, of course, but I got very very many weird warnings for the Qt included files. I tried the binary GCC 4.3.1 from Debian. A collaborator reports that he compiled successfully FET for the same Qt as mine, with GCC 4.3.1, but for 32 bit version. He obtained only a few warnings. Thank you for fast reply. I'll do some more tests with GCC 4.3.1 and maybe report bugs to Trolltech for Qt or report bugs here for GCC 4.3.1. I installed latest qt and gcc 4.3.1. Everything is fine, FET compiles OK, thank you. It is very good that I get a few warnings which did not show up in gcc 4.1.3, and I saw a few mistakes of mine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37008
[Bug libfortran/36886] misaligment for cshift of character
--- 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 libgfortran. How about including in your patch a check that the shape of ARRAY (minus dimension DIM) is conformable with the SHIFT argument? (i.e. that for every dimension SHIFT has the same number of elements as ARRAY.) I was additionally wondering whether one should change error code such as: if (which 0 || (which + 1) GFC_DESCRIPTOR_RANK (array)) into if (__builtin_expect (which 0 || (which + 1) GFC_DESCRIPTOR_RANK (array), 0)) to speed up the run time by a tiny bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36886
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- 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 /extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/linux-2.6.26 ARCH=mips CROSS_COMPILE=mips-linux-uclibc- SUBDIRS=/extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/ath9k-20080731/drivers/net/wireless/ath9k EXTRA_CFLAGS= -DCONFIG_ATH9K=1 LINUXINCLUDE=-I/extra3/openwrt/ar71xx/trunk/staging_dir/mips/usr/include/mac80211 -I/extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/linux-2.6.26/include -include linux/autoconf.h CONFIG_ATH9K=m modules make[4]: Entering directory `/extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/linux-2.6.26' CC [M] /extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/ath9k-20080731/drivers/net/wireless/ath9k/hw.o /extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/ath9k-20080731/drivers/net/wireless/ath9k/hw.c: In function 'ath9k_hw_spur_mitigate': /extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/ath9k-20080731/drivers/net/wireless/ath9k/hw.c:4906: internal compiler error: in expand_expr_real_1, at expr.c:8760 Please submit a full bug report, with preprocessed source if appropriate. a snapshot of the ath9k used is here: http://wifi.ozo.com/airo/openwrt/source/ath9k a relative ticket on the ath9k is here: https://lists.ath9k.org/pipermail/ath9k-devel/2008-August/82.html gcc-3.4.6 compiles fine for mips mipsel targets. gcc-4.2.4 also compiles fine for x86 target. -- alex at ozo dot com changed: What|Removed |Added CC||alex at ozo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug libfortran/36886] misaligment for cshift of character
--- 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) for PR 36874 can be best done in libgfortran. How about including in your patch a check that the shape of ARRAY (minus dimension DIM) is conformable with the SHIFT argument? I've done so for other intrinsics (see PR 34670), and I plan to do so for cshift as well. Not with this patch, though; I like to do one thing at a time :-) I was additionally wondering whether one should change error code such as: if (which 0 || (which + 1) GFC_DESCRIPTOR_RANK (array)) into if (__builtin_expect (which 0 || (which + 1) GFC_DESCRIPTOR_RANK (array), 0)) to speed up the run time by a tiny bit. Sure, we could do that for all of the run-time checks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36886
[Bug target/36923] Crashes with FPU inline-assembly
--- 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:
static float fraction( float _x )
{
int tmp;
asm ( fld %%st\n\t
fisttp %1\n\t
fild %1\n\t
fsubrp %%st, %%st(1)
: +t( _x ), =m( tmp )
:
: st(1) );
return( _x );
}
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36923
[Bug c/37014] New: internal compiler error: in expand_expr_real_1, at expr.c:8760
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 CROSS_COMPILE=mips-linux-uclibc- SUBDIRS=/extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/ath9k-20080731/drivers/net/wireless/ath9k EXTRA_CFLAGS= -DCONFIG_ATH9K=1 LINUXINCLUDE=-I/extra3/openwrt/ar71xx/trunk/staging_dir/mips/usr/include/mac80211 -I/extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/linux-2.6.26/include -include linux/autoconf.h CONFIG_ATH9K=m modules make[4]: Entering directory `/extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/linux-2.6.26' CC [M] /extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/ath9k-20080731/drivers/net/wireless/ath9k/hw.o /extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/ath9k-20080731/drivers/net/wireless/ath9k/hw.c: In function 'ath9k_hw_spur_mitigate': /extra3/openwrt/ar71xx/trunk/build_dir/linux-ar71xx/ath9k-20080731/drivers/net/wireless/ath9k/hw.c:4906: internal compiler error: in expand_expr_real_1, at expr.c:8760 Please submit a full bug report, with preprocessed source if appropriate. a snapshot of the ath9k used is here: http://wifi.ozo.com/airo/openwrt/source/ath9k a relative ticket on the ath9k is here: https://lists.ath9k.org/pipermail/ath9k-devel/2008-August/82.html gcc-3.4.6 compiles fine for mips mipsel targets. gcc-4.2.4 also compiles fine for x86 target. -- Summary: internal compiler error: in expand_expr_real_1, at expr.c:8760 Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alex at ozo dot com GCC build triplet: openwrt-mips toolchain GCC host triplet: core2duo x86-64 smp GCC target triplet: mips mipsel http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37014
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- 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
[Bug ada/36930] GNAT BUG DETECTED while creating object on storage pool
--- 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 CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36930
[Bug ada/36785] Segmentation fault in Gnat.Regexp
--- 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 CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-03 12:07:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36785
[Bug ada/36764] ICE with -gnatn inlining and stream attributes
--- 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 | -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-03 12:08:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36764
[Bug bootstrap/36948] cc1.exe: internal compiler error: Segmentation fault
--- 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 forgot to revert changes maded by this script back. After reverting changes back crash is disappered. But i think bug with what crash on incorrect library should be fixed or at least, warning should persists in output. -- andry at inbox dot ru changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36948
[Bug ada/36777] Protected type cannot have access taken from its body.
-- 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 | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-03 14:59:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36777
[Bug target/18766] Inefficient code with -mfpmath=387,sse
--- 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 fldsa+4 fmuls b+4 faddp %st, %st(1) popl%ebp ret So, fixed for 4.4. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18766
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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. 3. Post the final eh-alloca-1.C. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, Joey dot ye at intel ||dot com, xuepeng dot guo at ||intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug target/15827] global register %esi versus memcpy builtin
--- 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 Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15827
[Bug target/16332] feature request: x86_64 windows calling convention
--- 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 Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16332
[Bug target/19566] x86_64 - inconsistent choice of parameter passing method for 16 byte struct
--- 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 CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19566
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
--- 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||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug target/37010] -Os passes __m128 on stack with wrong alignment
--- 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 ix86_expand_prologue. Joey, what do you think? -- hjl dot tools at gmail dot com changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37010
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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 -fno-show-column -lm -o ./regparm-1.exe I get... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x1000 0x1def in check_int () (gdb) bt #0 0x1def in check_int () #1 0x1f2d in test_nested () #2 0x1f92 in main () which I narrowed down with printfs to be the line... int __attribute__ ((__noinline__, __regparm__(2))) foo (int j, int k, int l) in test_nested(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug target/37010] -Os passes __m128 on stack with wrong alignment
--- 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 / BITS_PER_UNIT))? On MacOS, STACK_BOUNDARY is 128 on ia32. Does this patch make sense? --- ./i386.c.drap 2008-08-03 09:50:05.0 -0700 +++ ./i386.c2008-08-03 11:36:40.0 -0700 @@ -7291,6 +7291,10 @@ ix86_compute_frame_layout (struct ix86_f if (stack_realign_fp) offset = (offset + stack_alignment_needed -1) -stack_alignment_needed; + /* Duplicated return address when DRAP is used. */ + if (crtl-drap_reg crtl-stack_realign_needed) +offset += UNITS_PER_WORD; + /* Register save area */ offset += frame-nregs * UNITS_PER_WORD; @@ -7692,8 +7696,7 @@ ix86_expand_prologue (void) expand_builtin_return_addr etc. */ x = crtl-drap_reg; x = gen_frame_mem (Pmode, - plus_constant (x, - -(STACK_BOUNDARY / BITS_PER_UNIT))); + plus_constant (x, -UNITS_PER_WORD)); insn = emit_insn (gen_push (x)); RTX_FRAME_RELATED_P (insn) = 1; } -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hubicka at ucw dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37010
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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 STACK_BOUNDARY / BITS_PER_UNIT in our stack alignment codes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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
[Bug target/37010] -Os passes __m128 on stack with wrong alignment
--- 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 (void);
int
__attribute__ ((noinline))
check_int (int *i, int align)
{
*i = 20;
if ptrdiff_t) i) (align - 1)) != 0)
{
abort ();
}
return *i;
}
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
typedef int aligned __attribute__((aligned(16)));
__m128 r;
void
__attribute__ ((noinline))
foo (__m128 x, __m128 y ,__m128 z ,__m128 a, int size)
{
aligned i;
if (check_int (i, __alignof__(i)) != i)
abort ();
r = a;
}
int
main (void)
{
__m128 x = { 1.0 };
foo (x, x, x, x, 5);
if (__builtin_memcmp (r, x, sizeof (r)))
abort ();
return 0;
}
bash-3.2$ make y
/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 -Os
-mpreferred-stack-boundary=2y.c -o y
bash-3.2$ ./y
Segmentation fault
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 -O
-mpreferred-stack-boundary=2y.c -o y
bash-3.2$ ./y
bash-3.2$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37010
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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 so far. Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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 but this fix looks good so far. Jack Please do a full bootstrap and make -k check. Please send your results to gcc-testresults. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c/37015] New: modulo operations which use negative numbers return unexpected results
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: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cl3m3ns at gmail dot com GCC build triplet: 4.3.1 GCC host triplet: 4.3.1 GCC target triplet: 4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37015
[Bug c/37015] modulo operations which use negative numbers return unexpected results
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37015
[Bug c++/37016] New: member function pointer failure with optimization
#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 base class that implements the transport
layer to the derived class.
The specific failure was in forwarding calls to items in a container.
This is emulated here by wrapping a single item.
In the main program there are two forms of the call. In the last
(uncommented) form the member function pointer is for clarity
assigned to a variable (itemfunptr) before making the call.
With 4.3.0 and 4.3.1 this code compiles incorrectly with -O1 or greater
to produce this warning
reproduce.cc: In function int main():
reproduce.cc:26: warning: itemfunptr.void (Container::*)(void
(Item::*)(int), int)::__pfn is used uninitialized in this function
reproduce.cc:47: note: itemfunptr.void (Container::*)(void (Item::*)(int),
int)::__pfn was declared here
and the resulting executable segvs. It works correctly with -O0.
With 4.2.3 and earlier it works correctly with optimization.
In the first (commented out) form of the call in the main program
we directly refer to desired member function. This compiles
and executes correctly with all tested versions.
*/
template class Derived
struct WorldObject {
template typename memfunT, typename arg1T, typename arg2T
void forward(memfunT memfun, arg1T arg1, arg2T arg2) {
Derived* obj = static_castDerived*(this);
(obj-*memfun)(arg1, arg2);
}
};
struct Item {
void fred(int a) {
std::cout a= a std::endl;
}
};
struct Container : public WorldObjectContainer {
Item item;
template typename itemfunT, typename arg1T
void itemfun(itemfunT itemfun, int a) {
(item.*itemfun)(a);
}
};
int main() {
typedef void (Item::*itemfun)(int);
Container t;
// This call compiles and executes correctly with all versions tested
//t.forward(Container::itemfunitemfun,int, Item::fred, 1);
// This call compiles with a warning and segvs on execution if using
// -O1 or greater with 4.3.*. 4.2.* is correct.
void (Container::*itemfunptr)(itemfun, int) =
Container::itemfunitemfun,int;
t.forward(itemfunptr, Item::fred, 1);
return 0;
}
--
Summary: member function pointer failure with optimization
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rjharrison at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37016
[Bug c++/37016] [4.3/4.4 Regression] member function pointer failure with optimization
--- 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 = memfunD.24341.__pfnD.21692;
You can see how the two different field decls are allocated. I don't know if I
want to mark this a front bug or a middle one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2008-08-03 21:47:37
date||
Summary|member function pointer |[4.3/4.4 Regression] member
|failure with optimization |function pointer failure
||with optimization
Target Milestone|--- |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37016
[Bug boehm-gc/37017] New: [4.2 regression] Using --enable-threads=solaris breaks near end of build in boehm-gc configury
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 release from: ftp://ftp.gnu.org/gnu/gcc/gcc-4.2.3/gcc-4.2.3.tar.bz2 A similar complaint is made here: Fortran and objc Hans Boehm GC build issues -- sparcv9 libs http://gcc.gnu.org/ml/gcc-help/2006-09/msg00108.html A claim that configuring with --enable-threads=solaris was fixed is made here: [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247 If you are going to build this you need to fixup the Makefiles to get --with-gmp=/opt/gnu/gmp-4.2.2 --with-mpfr=/opt/gnu/mpfr-2.3.1 to work, yet --with-libiconv-prefix=/opt/csw works fine. # gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: /aux0/gcc-4.2.3/configure --build=i386-pc-solaris2.11 --prefix=/opt/gnu/gcc --with-docdir=/opt/gnu/gcc/share/doc --with-htmldir=/opt/gnu/gcc/share/html --with-local-prefix=/opt/gnu --with-gxx-include-dir=/opt/gnu/gcc/include/c++/4.2.3 --with-as=/opt/gnu/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-gmp=/opt/gnu/gmp-4.2.2 --with-mpfr=/opt/gnu/mpfr-2.3.1 --with-libiconv-prefix=/opt/csw --enable-shared --disable-static --enable-threads=solaris --enable-parallel-mark --enable-libada --enable-libgcj-debug --enable-libgcj-multifile --enable-gather-detailed-mem-stats --enable-libssp --disable-libmudflap --enable-libgomp --enable-libstdcxx-debug --enable-local-sockets --enable-multilib --enable-nls --enable-objc-gc --enable-portable-native-sync --enable-tool-wrappers --enable-version-specific-runtime-libs --verbose --with-dwarf2 --with-stabs --with-tls --enable-decimal-float --with-x --x-includes=/usr/include/X11 --x-libraries=/usr/X11/lib --enable-gtk-cairo --enable-qt-peer --enable-gconf-peer --enable-gc-debug --enable-default-toolkit=xlib --enable-java-awt=gtk,xlib,qt,x --enable-stage1-checking=release --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ : (reconfigured) /aux0/gcc-4.2.3/configure --build=i386-pc-solaris2.11 --prefix=/opt/gnu/gcc --with-docdir=/opt/gnu/gcc/share/doc --with-htmldir=/opt/gnu/gcc/share/html --with-local-prefix=/opt/gnu --with-gxx-include-dir=/opt/gnu/gcc/include/c++/4.2.3 --with-as=/opt/gnu/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-gmp=/opt/gnu/gmp-4.2.2 --with-mpfr=/opt/gnu/mpfr-2.3.1 --with-libiconv-prefix=/opt/csw --enable-shared --disable-static --enable-threads=solaris --enable-parallel-mark --enable-libada --enable-libgcj-debug --enable-libgcj-multifile --enable-gather-detailed-mem-stats --enable-libssp --disable-libmudflap --enable-libgomp --enable-libstdcxx-debug --enable-local-sockets --enable-multilib --enable-nls --enable-objc-gc --enable-portable-native-sync --enable-tool-wrappers --enable-version-specific-runtime-libs --verbose --with-dwarf2 --with-stabs --with-tls --enable-decimal-float --with-x --x-includes=/usr/include/X11 --x-libraries=/usr/X11/lib --enable-gtk-cairo --enable-qt-peer --enable-gconf-peer --enable-gc-debug --enable-default-toolkit=xlib --enable-java-awt=gtk,xlib,qt,x --enable-stage1-checking=release --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ : (reconfigured) Thread model: solaris gcc version 4.2.3 Partial build backscroll: (cd .libs rm -f libgfortran.so.2 ln -s libgfortran.so.2.0.0 libgfortran.so.2) (cd .libs rm -f libgfortran.so ln -s libgfortran.so.2.0.0 libgfortran.so) creating libgfortran.la (cd .libs rm -f libgfortran.la ln -s ../libgfortran.la libgfortran.la) true DO=all multi-do # gmake gmake[6]: Leaving directory `/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/amd64/libgfortran' gmake[5]: Leaving directory `/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/amd64/libgfortran' gmake[4]: Leaving directory `/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/libgfortran' gmake[3]: Leaving directory `/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/libgfortran' gmake[2]: Leaving directory `/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/libgfortran' Checking multilib configuration for boehm-gc... mkdir i386-pc-solaris2.11/boehm-gc Configuring in i386-pc-solaris2.11/boehm-gc configure: creating cache ./config.cache checking build system type... i386-pc-solaris2.11 ... checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no appending configuration tag CXX to libtool checking for thread model used by GCC... solaris configure: error: thread package solaris not yet supported gmake[1]: *** [configure-target-boehm-gc] Error 1 gmake[1]: Leaving directory `/aux0/gcc-4.2.3_build' gmake: *** [all] Error 2 -- Summary: [4.2 regression] Using --enable-threads=solaris breaks near end of build in boehm-gc configury
[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury
--- 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|Removed |Added Severity|blocker |normal Summary|[4.2 regression] Using -- |Using --enable- |enable-threads=solaris |threads=solaris breaks near |breaks near end of build in |end of build in boehm-gc |boehm-gc configury |configury http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017
[Bug target/35397] Problem handling denormalized numbers under AIX
--- 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 CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Known to fail||4.0.3 4.1.1 4.2.3 Known to work||4.3.0 4.3.1 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35397
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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: g++.dg/torture/stackalign/eh-vararg-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-2.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-3.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/eh-alloca-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-1.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-2.C -O3 -g execution test FAIL: g++.dg/torture/stackalign/throw-3.C -O3 -g execution test Without your patch these failed at all optimization levels. I noticed we still have many instances of STACK_BOUNDARY / BITS_PER_UNIT in the patched sources in the gcc subdirectory... calls.c:#define STACK_BYTES (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT) calls.c: (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT - 1))); cfgexpand.c:int align = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT; cfgexpand.c: HOST_WIDE_INT align = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT; explow.c: int align = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT; explow.c: int align = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT; explow.c: % (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT))); function.c:#define STACK_BYTES (STACK_BOUNDARY / BITS_PER_UNIT) function.c: frame_alignment = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT; tree-nested.c: size += ((align/BITS_PER_UNIT) - 1) -(STACK_BOUNDARY/BITS_PER_UNIT); Shouldn't these universally be changed to be UNITS_PER_WORD instead? Jack ps All the stackalign failures in the gcc section are gone now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury
--- 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.
2. There are more features on this Operating System. With Solaris it enables
Solaris threads _and_ pthreads simultaneously.
man threads(5)
http://opensolaris.org/os/community/arc/caselog/2008/039/materials/new_man/threads-5/
Comparing APIs for Solaris Threads and POSIX Threads
http://docs.sun.com/app/docs/doc/816-5137/sthreads-96692?l=ena=view
Unique Solaris Threads Functions
http://docs.sun.com/app/docs/doc/816-5137/sthreads-49113?l=ena=view
-
Here is a quick fix to allow the build to continue. I still need to run make
-i check on this:
# gdiff -Naur /aux0/gcc-4.2.3/boehm-gc/configure_Origonal
/aux0/gcc-4.2.3/boehm-gc/configure
--- /aux0/gcc-4.2.3/boehm-gc/configure_Origonal 2007-10-07 14:23:16.0
-0700
+++ /aux0/gcc-4.2.3/boehm-gc/configure 2008-08-03 18:00:52.633231123 -0700
@@ -5500,6 +5500,13 @@
multi_os_directory=`$CC -print-multi-os-directory`
THREADLIBS=-L/usr/lib/lwp/$multi_os_directory \
-R/usr/lib/lwp/$multi_os_directory -lpthread -lthread -lrt
+
+if test ${enable_parallel_mark} = yes; then
+cat confdefs.h \_ACEOF
+#define PARALLEL_MARK 1
+_ACEOF
+ fi
+
;;
*-*-irix*)
@@ -5602,16 +5609,17 @@
_ACEOF
;;
- decosf1 | irix | mach | os2 | solaris | dce | vxworks)
+# decosf1 | irix | mach | os2 | solaris | dce | vxworks)
+ decosf1 | irix | mach | os2 | dce | vxworks)
{ { echo $as_me:$LINENO: error: thread package $THREADS not yet
supported 5
echo $as_me: error: thread package $THREADS not yet supported 2;}
{ (exit 1); exit 1; }; }
;;
- *)
-{ { echo $as_me:$LINENO: error: $THREADS is an unknown thread package
5
-echo $as_me: error: $THREADS is an unknown thread package 2;}
- { (exit 1); exit 1; }; }
-;;
+# *)
+#{ { echo $as_me:$LINENO: error: $THREADS is an unknown thread package
5
+#echo $as_me: error: $THREADS is an unknown thread package 2;}
+# { (exit 1); exit 1; }; }
+#;;
esac
-
Note: I unnecessarily added the parallel mark feature also.
--
rob1weld at aol dot com changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017
[Bug inline-asm/37018] New: compiling inline assembly for ia32 produces ia64 registers
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 produces ia64 registers Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at karrels dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37018
[Bug inline-asm/37018] compiling inline assembly for ia32 produces ia64 registers
--- 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
[Bug inline-asm/37018] compiling inline assembly for ia32 produces ia64 registers
--- 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
[Bug inline-asm/37018] compiling inline assembly for ia32 produces ia64 registers
--- 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 CC||gcc at karrels dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37018
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- 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 execution test Please provide the processed eh-alloca-1.ii if it is different from http://gcc.gnu.org/bugzilla/attachment.cgi?id=16003action=view Also provide complete command line for it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug libgcj/37019] New: [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses grep and egrep and grep -E and $EGGREP but not ggrep -- sed also is trouble
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 until line 7322. Correct usage would be to check if we need to use ggrep since on Solaris grep is NOT the GNU grep, instead ggrep is the GNU grep. A few simple commands in Solaris's grep _are_ compatable with GNU's grep but most commands are not. Solaris also has egrep and fgrep but those are also both Non-GNU programs. To use egrep or fgrep (in Solaris) you must use ggrep -E or ggrep -F. --- The other problem is that Solaris (I have the newest version) does not have a GNU sed program. Worse news. It _does_ have a sed program, but there is no command to obtain a version number. Looking at the man sed command says that the man page is dated 23 Jul 1998. In a normal installation of Solaris there is no gsed command. The GNU sed command can be tested by running sed --version and it will reply GNU sed version x.y.z. The Solaris sed command has no means to check it's version (that I am aware of -- you might ggrep the binary ;) ). If someone wants a gsed command for Solaris they must either compile sed themselves or type this (see this URL: http://www.blastwave.org/howto.html): # pkgadd -d http://www.blastwave.org/pkg_get.pkg # /opt/csw/bin/pkg-get -U # /opt/csw/bin/pkg-get -i wget # /opt/csw/bin/pkg-get -i gsed That provides a GNU sed as /opt/csw/bin/gsed. It is version 4.1.4 Elsewhere in gcc I have noticed that other configure scripts do not have this problem, they do check for the g-prefixed commands. The (correct) configury uses tests to set environment variables that are used for the program's name throughout the rest of the script. -- Summary: [4.2 Regression] Inconsistent gcc- 4.2.3/libjava/configure uses grep and egrep and grep -E and $EGGREP but not ggrep -- sed also is trouble Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019
[Bug target/37010] -mno-accumulate-outgoing-args doesn't work with stack alignment
--- 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 -mno-accumulate-outgoing-args -mpreferred-stack-boundary=2y.c -o y bash-3.2$ ./y Segmentation fault 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 -mpreferred-stack-boundary=2y.c -o y bash-3.2$ ./y bash-3.2$ -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2008- | |08/msg00123.html| Summary|-Os passes __m128 on stack |-mno-accumulate-outgoing- |with wrong alignment|args doesn't work with stack ||alignment http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37010
