[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #8 from aaronavay62 at aaronwl dot com 2007-04-05 08:05 --- What is the status on this? I'm pretty sure this is a regression; it would be great if this fix could get into 4.2, but it might be too late for that. This is a serious problem for many/most users on Windows as it breaks COM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug target/31478] Typo in sse2_umulv2siv2di3 pattern
--- Comment #3 from ubizjak at gmail dot com 2007-04-05 08:48 --- > There is no corresponding define_expand for this pattern. Many define_insn > patterns without define_expand don't call ix86_binary_operator_ok. Will that > be a problem? Those are sse builtins and are expanded via ix86_expand_binop_builtin(). This function fixes all operands to satisfy ix86_binary_operator_ok(). Regarding call to ix86_binary_operator_ok - this check is needed only when both input operands are nonimmediate_operand (and output operand is register_operand). There is indeed a pattern without this check - sse2_pmaddwd. Due to %, it is commutative, so check for PLUS of V8HI mode would be OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31478
[Bug fortran/31474] ENTRY & procedural pointer: insert_bbt(): Duplicate key found!
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-05 08:28 --- (In reply to comment #1) > The problem seems to occur with procedure pointers to ENTRY points >From a quick look at decl.c(get_proc_name), the modifications that I added, to get module procedures with entries to work at all, ignored the possibility that there would be an existing symtree at module level. ...snip... /* Module function entries will already have a symtree in the current namespace but will need one at module level. */ if (module_fcn_entry) st = gfc_new_symtree (&gfc_current_ns->parent->sym_root, name); else st = gfc_new_symtree (&gfc_current_ns->sym_root, name); ...snip... is almost certainly the cause of the trouble. I have a build/regtest going on right now (and I should be paying attention to something else:)), so I canot do anything about it until this afternoon. However, I can see what to do and will take it on. Thank you for the report, Michael. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-04 20:47:59 |2007-04-05 08:28:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31474
[Bug target/31478] Typo in sse2_umulv2siv2di3 pattern
--- Comment #4 from ubizjak at gmail dot com 2007-04-05 09:13 --- (In reply to comment #3) > There is indeed a pattern without this check - sse2_pmaddwd. > Due to %, it is commutative, so check for PLUS of V8HI mode would be OK. Please also change operands 1 and 2 of sdot_prodv8hi expander to register_operand to avoid further suprises. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31478
[Bug fortran/31483] ICE on fortran Code
--- Comment #1 from pault at gcc dot gnu dot org 2007-04-05 09:31 --- Created an attachment (id=13330) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13330&action=view) Fix for the PR The ICE is due to a gcc_assert blocking dummy procedures from having alternate returns. The fix, gives the procedure result the appropriate type and, as a result, the following runs fine: SUBROUTINE R (i, *, *) INTEGER i RETURN i END SUBROUTINE PHLOAD (READER, i) IMPLICIT NONE EXTERNAL READER integer i CALL READER (i, *1, *2) 1print *, "one" return 2print *, "two" return END Give me a day or two to submit this one. Paul EXTERNAL R call PHLOAD (R, 1) CALL PHLOAD (R, 2) END -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31483
[Bug fortran/31465] spurious error: Implicitly typed PARAMETER doesn't match a later IMPLICIT type
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-05 09:51 --- (In reply to comment #3) > From the standard: > "5.2.9 PARAMETER statement > [...] > The named constant shall have its type, type parameters, and shape specified > in > a prior specification of the specification-part or declared implicitly (5.3). > If the named constant is typed by the implicit typing rules, its appearance in > any subsequent specification of the specification-part shall confirm this > implied > type and the values of any implied type parameters." > Thus implies gfortran does the right thing - at least for -std=f95/f2003. You are right - I will close it as invalid. Sorry, Michael, but it appears that your code is standard defying. If you disagree, please come back to us. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31465
[Bug libstdc++/31481] GCC 4.2.0 incompatible with STLport 5.1.3
--- Comment #3 from pcarlini at suse dot de 2007-04-05 10:03 --- In order to speed-up the process, can you edit ext/type_traits.h to not include and changing std::streamsize to int and report how it goes? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
[Bug c++/31484] va_list handeling different in 64bit vs 32 bit.
--- Comment #2 from Klaas dot Vantournhout at UGent dot be 2007-04-05 10:35 --- What is the difference then between 32bit and 64bit? In the 32bit it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31484
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #13 from bonzini at gnu dot org 2007-04-05 11:01 --- So this is an unstable sorting. Adding dnovillo. -- bonzini at gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug c++/31484] New: va_list handeling different in 64bit vs 32 bit.
Hi,
It seems that a va_list is messed up when doing multiple functioncalls
containing the va_list. This only occurs in the 64bit versions of g++ and does
NOT occur in the 32bit versions.
This has been seen in versions 4.1.1 and 4.1.2
Below is all the suff you need (buildparameters, testcode and output)
Regards
Klaas
64 bit version
[klaas]$ g++ -v
Using built-in specs.
Target: x86_64-mandriva-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info
--enable-checking=release
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java
--host=x86_64-mandriva-linux-gnu --with-cpu=generic --with-system-zlib
--enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo
--disable-libjava-multilib --enable-ssp --disable-libssp
Thread model: posix
gcc version 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)
The compiled code
#include
#include
void f1(int,...);
void f1b(int, ...);
void f2(va_list);
int main(void) {
std::cout << "f1" << std::endl;
f1(3,1.2,3.6,5.9);
std::cout << "f1b" << std::endl;
f1b(3,1.2,3.6,5.9);
return 0;
}
/* this function fails */
void f1(int n, ...) {
va_list va;
va_start(va, n);
for (int i = 0; i < 2; ++i)
f2(va);
va_end(va);
}
/* this is a solution */
void f1b(int n, ...) {
va_list va;
for (int i = 0; i < 2; ++i) {
va_start(va,n);
f2(va);
va_end(va);
}
}
void f2(va_list va) {
double arg1 = va_arg(va,double);
double arg2 = va_arg(va,double);
double arg3 = va_arg(va,double);
std::cout << arg1 << "\t" << arg2 << "\t" << arg3 << std::endl;
}
The 64bit output is given by
[EMAIL PROTECTED] g++ bug.cpp
[EMAIL PROTECTED] ./a.out
f1
1.2 3.6 5.9
3.95253e-3232.3528e-310 2.3528e-310
f1b
1.2 3.6 5.9
1.2 3.6 5.9
The 32 bit output is given by
[EMAIL PROTECTED] g++ bug.cpp
[EMAIL PROTECTED] ./a.out
f1
1.2 3.6 5.9
1.2 3.6 5.9
f1b
1.2 3.6 5.9
1.2 3.6 5.9
--
Summary: va_list handeling different in 64bit vs 32 bit.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Klaas dot Vantournhout at UGent dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31484
[Bug libstdc++/31481] GCC 4.2.0 incompatible with STLport 5.1.3
--- Comment #4 from pluto at agmk dot net 2007-04-05 10:42 --- (In reply to comment #3) > In order to speed-up the process, can you edit ext/type_traits.h to not > include > and changing std::streamsize to int and report how it goes? Thanks. > this change causes another error: + /usr/bin/make -C build/lib -f gcc.mak release-shared release-static CC=x86_64-pld-linux-gcc CXX=x86_64-pld-linux-g++ make: Entering directory `/home/users/pluto/rpm/BUILD/STLport-5.1.3/build/lib' x86_64-pld-linux-g++ -pthread -fexceptions -fident -fPIC -O2 -fno-strict-aliasing -fwrapv -march=x86-64 -gdwarf-2 -g2 -fuse-cxa-atexit -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -I../../stlport -c -o obj/gcc/so/dll_main.o ../../src/dll_main.cpp In file included from /usr/include/c++/4.2.0/../4.2.0/cmath:52, from ../../stlport/stl/_cmath.h:31, from ../../stlport/stl/_cstdlib.h:162, from ../../stlport/stl/_alloc.h:39, from ../../stlport/memory:32, from ../../src/dll_main.cpp:42: /usr/include/c++/4.2.0/ext/type_traits.h:184: error: 'numeric_limits' is not a member of 'std' /usr/include/c++/4.2.0/ext/type_traits.h:184: error: expected primary-expression before '>' token /usr/include/c++/4.2.0/ext/type_traits.h:184: error: '::digits' has not been declared make: *** [obj/gcc/so/dll_main.o] Error 1 -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
[Bug libstdc++/31481] GCC 4.2.0 incompatible with STLport 5.1.3
--- Comment #2 from pcarlini at suse dot de 2007-04-05 09:59 --- Yes, streamsize shouldn't be there, I noticed that as part of a large rearrangment of the headers in mainline and fixed it. I'm porting that specific bit to 4_2-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
[Bug c++/31484] va_list handeling different in 64bit vs 32 bit.
--- Comment #1 from schwab at suse dot de 2007-04-05 10:31 --- Not a bug. You must call va_start/va_end whenever you want to reuse a va_list. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31484
[Bug c++/31484] va_list handeling different in 64bit vs 32 bit.
--- Comment #3 from schwab at suse dot de 2007-04-05 10:47 --- 7.15 Variable arguments 3 [...] The object ap may be passed as an argument to another function; if that function invokes the va_arg macro with parameter ap, the value of ap in the calling function is indeterminate and shall be passed to the va_end macro prior to any further reference to ap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31484
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #12 from ubizjak at gmail dot com 2007-04-05 11:00 --- (In reply to comment #11) > with -msse compile flag. Note different variable suffixes that create > different > sort order. This is (IMO) due to fact that -msse enables lots of additional > __builtin functions (these can be seen in 001.tu dump). I forgot to add that -ffast-math simply enables more builtins, and again different sort order is introduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug fortran/31467] internal compiler error when compiling with gfortran
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-04-05 11:05 --- Could you easily test it with a 4.1 compiler? I would like to be sure it's not a regression in 4.2 with respect to 4.1, in which case we should try to fix it. If the bug was also present in 4.1, then we can close this. Merci ! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31467
[Bug fortran/31483] ICE on fortran Code
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-05 11:01 --- (In reply to comment #2) > Or even better is there any chance to get that backported to the release > branches? It seems to be a regression wrt g77, which means it's possible that it will be backported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31483
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #11 from ubizjak at gmail dot com 2007-04-05 10:58 --- (In reply to comment #10) > I would look at the lreg output, which contains the results of regclass. No, the difference is due to ssa pass that generates: # v1z_10 = PHI # v1y_9 = PHI # v1x_8 = PHI # i_7 = PHI # v3z_6 = PHI # v3y_5 = PHI # v3x_4 = PHI # v2z_3 = PHI # v2y_2 = PHI # v2x_1 = PHI without -msse and # v3z_10 = PHI # v3y_9 = PHI # v3x_8 = PHI # v2z_7 = PHI # v2y_6 = PHI # v2x_5 = PHI # v1z_4 = PHI # v1y_3 = PHI # v1x_2 = PHI # i_1 = PHI with -msse compile flag. Note different variable suffixes that create different sort order. This is (IMO) due to fact that -msse enables lots of additional __builtin functions (these can be seen in 001.tu dump). Since we don't have x87 scheduler the results became quite unpredictable, and depend on -msseX settings. It just _happens_ that second form better suits stack nature of x87. So, why does SSA pass have to interfere with computation dataflow? This interferece makes things worse and effectively takes away user's control on the flow of data. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug target/31175] isinf incorrectly expanded
--- Comment #4 from ubizjak at gmail dot com 2007-04-05 12:21 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31175
[Bug fortran/31427] TRANSFER with mold kind /= lval kind: ICE on ia64, i686; no warning
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-04-05 11:17 --- The segfault happens because we come into gfc_int2int to convert the value from TRANSFER into the integer(kind=1). But TRANSFER isn't simplified at this point, although it should have been, which leads to referencing memory that is not defined. This will be fixed when the gfc_simplify_transfer() function is implemented (Paul T. and Tobias B. are working on it). Admittedly, we should have an assert() in place to prevent this kind of segfault (and have a clean ICE instead). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug libstdc++/31481] GCC 4.2.0 incompatible with STLport 5.1.3
--- Comment #5 from pcarlini at suse dot de 2007-04-05 11:39 --- (In reply to comment #4) > (In reply to comment #3) > > In order to speed-up the process, can you edit ext/type_traits.h to not > > include > > and changing std::streamsize to int and report how it goes? Thanks. > > > > this change causes another error: You must be doing something wrong, because of course ext/type_traits.h keeps on including . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
[Bug target/29793] TESTW{W,L,Q} rCX + JZ/JE should be replaced by J{,E,R}CXZ when possible
--- Comment #4 from ubizjak at gmail dot com 2007-04-05 12:29 ---
(In reply to comment #2)
> To implement this optimization, some support from assembler is needed. When
> displacement overflows 8bit, assembler should substitute "jecxz" with
> equivalent "test/jmp rel{16,32}" sequence.
Unfortunatelly, test/jmp clobbers flags, and jecxz doesn't. Due to this, and
example in comment #3, we can't reliably generate proposed instructions.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29793
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #14 from dnovillo at gcc dot gnu dot org 2007-04-05 12:49 --- (In reply to comment #11) > So, why does SSA pass have to interfere with computation dataflow? This > interferece makes things worse and effectively takes away user's control on > the > flow of data. > Huh? How is it relevant whether PHIs are in different order? Conceptually, the ordering of PHI nodes in a basic block is completely irrelevant. Some pass is getting confused when it shouldn't. Transformations should not depend on how PHI nodes are emitted in a block as all PHI nodes are always evaluated in parallel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug target/31486] New: ICE with vector code when -mno-sse2 on amd64
Compilation of the attached code yields an ICE in certain cases.
Environment:
System: Linux chii 2.6.20 #3 SMP Sun Feb 11 23:52:47 EET 2007 x86_64 GNU/Linux
Architecture: x86_64
host: x86_64-pc-linux-gnu
build: x86_64-pc-linux-gnu
target: x86_64-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
How-To-Repeat:
Compile this code:
typedef double ss2 __attribute__((vector_size(2*sizeof(double;
ss2 b = {1,1};
extern ss2 a2(ss2 a,ss2 b);
void test2() { b = a2(b,b); }
With these commandline options:
gcc-4.1 -mno-sse2 -S -o- test3.c
The output comes as follows:
.file "test3.c"
.globl b
.data
.align 16
.type b, @object
.size b, 16
b:
.long 0
.long 1072693248
.long 0
.long 1072693248
test3.c: In function 'test2':
test3.c:6: internal compiler error: in emit_move_insn, at expr.c:3162
Please submit a full bug report,
with preprocessed source if appropriate.
(rest of output omitted for brevity)
It does not occur if "double" is changed to "float", "long double", "short",
"int" or "char".
It does occur if "double", "long int" or "long long int" is used.
It does not occur if 2 is changed to 4.
Architecture:
CPU=AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
CPU features=fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow
pni lahf_lm cmp_legacy
GCC is:
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
--
Summary: ICE with vector code when -mno-sse2 on amd64
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bisqwit at bisqwit dot iki dot fi
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31486
[Bug target/29793] TESTW{W,L,Q} rCX + JZ/JE should be replaced by J{,E,R}CXZ when possible
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-05 12:54 --- Can we compute the displacement reliable enough to say that it is smaller than some other number (e.g. 64)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29793
[Bug fortran/31483] New: ICE on fortran Code
I get an ICE with gfortran on the following code:
$ cat ice.F
SUBROUTINE PHLOAD (READER,*)
IMPLICIT NONE
EXTERNAL READER
CALL READER (*1)
1RETURN 1
END
$ gfortran -S ice.F
ice.F: In function 'phload':
ice.F:1: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:2401
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/scr/kuma/froehl/gcc-prefix
--with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib64
--with-mpfr-include=/usr/local/include --with-mpfr-lib=/usr/local/lib64
Thread model: posix
gcc version 4.3.0 20070404 (experimental)
That happens with gfortran from the gcc-4.1.{1,2} as well as with 20070404 svn
trunk version.
--
Summary: ICE on fortran Code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: M dot Froehlich at science-computing dot de
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=31483
[Bug fortran/31483] ICE on fortran Code
--- Comment #2 from M dot Froehlich at science-computing dot de 2007-04-05 10:56 --- Great! Thank you very much! ... open source projects have the fastest response times! The patch does not apply with 'patch' to gcc-4.1.2, but I could well hand patch that. Do you expect problems when I apply that small patch to a gcc-4.1.2 release? Or even better is there any chance to get that backported to the release branches? Greetings Mathias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31483
[Bug libstdc++/31481] GCC 4.2.0 incompatible with STLport 5.1.3
--- Comment #6 from pcarlini at suse dot de 2007-04-05 11:49 --- Created an attachment (id=13331) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13331&action=view) Patch This is the patch which I'm finishing testing in the branch and should be applied anyway, irrespective of this specific issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
[Bug rtl-optimization/31485] New: C complex numbers, amd64 SSE, missed optimization opportunity
Considering that "complex" turns basically any basic type into a vector type,
complex number addition and subtraction could utilize SSE instructions to
perform the operation on real and imaginary parts simultaneously. (Only applies
to addition and subtraction.)
Code:
#include
typedef float complex ss1;
typedef float ss2 __attribute__((vector_size(sizeof(ss1;
ss1 add1(ss1 a, ss1 b) { return a + b; }
ss2 add2(ss2 a, ss2 b) { return a + b; }
Produces:
add1:
movq%xmm0, -8(%rsp)
movq%xmm1, -16(%rsp)
movss -4(%rsp), %xmm0
movss -8(%rsp), %xmm1
addss -12(%rsp), %xmm0
addss -16(%rsp), %xmm1
movss %xmm0, -20(%rsp)
movss %xmm1, -24(%rsp)
movq-24(%rsp), %xmm0
ret
add2:
movlps %xmm0, -16(%rsp)
movlps %xmm1, -24(%rsp)
movaps -24(%rsp), %xmm0
addps -16(%rsp), %xmm0
movaps %xmm0, -56(%rsp)
movlps -56(%rsp), %xmm0
ret
Command line:
gcc -msse -O3 -S test2.c
(Results are same with -ffast-math)
Architecture:
CPU=AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
CPU features=fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow
pni lahf_lm cmp_legacy
GCC is:
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
--
Summary: C complex numbers, amd64 SSE, missed optimization
opportunity
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bisqwit at iki dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #15 from bonzini at gnu dot org 2007-04-05 13:03 --- Transformations do not, but out-of-SSA could. Is there a way to ensure ordering of PHI functions unlike what Uros's dumps suggest? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug fortran/29507] INDEX in an array initialization causes ICE
--- Comment #8 from patchapp at dberlin dot org 2007-04-05 13:05 --- Subject: Bug number PR29507 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00170.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29507
[Bug target/31167] ICE wnen using __int128_t on x86_64
--- Comment #7 from ubizjak at gmail dot com 2007-04-05 13:06 --- Not marked as a regression on branches, so fixed. (The patch from Comment #6 applies cleanly on all branches. It is up to RM to decide if this can still go into 4.1.2 and 4.2.) -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.1.2 4.2.0 4.3.0 |4.1.2 4.2.0 Known to work||4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167
[Bug fortran/31483] ICE on fortran Code
--- Comment #4 from patchapp at dberlin dot org 2007-04-05 13:15 --- Subject: Bug number PR31483 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00171.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31483
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #16 from dnovillo at redhat dot com 2007-04-05 13:15 --- Subject: Re: Floating point computation far slower for -mfpmath=sse bonzini at gnu dot org wrote on 04/05/07 08:03: > Is there a way to ensure ordering of PHI functions unlike what Uros's > dumps suggest? No. I also don't see how PHI ordering would affect out-of-ssa. It just emits copies. If the ordering of those copies is affecting things like register pressure, then RA should be looked at. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #11 from arcangelpip at hotmail dot com 2007-04-05 13:21
---
I'm sorry to drag this back up again, but it happened again on 4.2.
Again it is with the gettext package which seems to love me so much.
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.2/configure --prefix=/crosstools/gccwin
--target=i686-pc-mingw32 --enable-shared --enable-threads --disable-multilib
--disable-nls --enable-languages=c,c++,ada,fortran,objc,obj-c++ --enable-c99
--enable-long-long --enable-sjlj-exceptions --enable-libada --enable-boehm-gc
Thread model: win32
gcc version 4.2.0 20070403 (prerelease)
It ICEs with the following.
make[4]: Entering directory `/mnt/hd2/build/gettextbuild/gettext-tools/src'
/bin/sh ../libtool --tag=CC --mode=compile i686-pc-mingw32-gcc
-DLOCALEDIR=\"/crosstools/gccwin/share/locale\"
-DBISON_LOCALEDIR=\"/usr/share/locale\"
-DLOCALE_ALIAS_PATH=\"/crosstools/gccwin/share/locale\" -DUSEJEXE=0
-DGETTEXTJEXEDIR=\"/crosstools/gccwin/lib/gettext\"
-DGETTEXTJAR=\"/crosstools/gccwin/share/gettext/gettext.jar\"
-DLIBDIR=\"/crosstools/gccwin/lib\"
-DGETTEXTDATADIR=\"/crosstools/gccwin/share/gettext\"
-DPROJECTSDIR=\"/crosstools/gccwin/share/gettext/projects\" -DHAVE_CONFIG_H -I.
-I.. -I../../../gettext-0.16.1/gettext-tools/src -I.
-I../../../gettext-0.16.1/gettext-tools/src -I..
-I../../../gettext-0.16.1/gettext-tools
-I../../../gettext-0.16.1/gettext-tools/libgrep
-I../../../gettext-0.16.1/gettext-tools/libuniname -I../gnulib-lib
-I../../../gettext-0.16.1/gettext-tools/gnulib-lib -I../intl
-I../../../gettext-0.16.1/gettext-tools/../gettext-runtime/intl
-I/crosstools/gccwin/include -g -O2 -c -o msgl-check.lo
../../../gettext-0.16.1/gettext-tools/src/msgl-check.c
i686-pc-mingw32-gcc -DLOCALEDIR=\"/crosstools/gccwin/share/locale\"
-DBISON_LOCALEDIR=\"/usr/share/locale\"
-DLOCALE_ALIAS_PATH=\"/crosstools/gccwin/share/locale\" -DUSEJEXE=0
-DGETTEXTJEXEDIR=\"/crosstools/gccwin/lib/gettext\"
-DGETTEXTJAR=\"/crosstools/gccwin/share/gettext/gettext.jar\"
-DLIBDIR=\"/crosstools/gccwin/lib\"
-DGETTEXTDATADIR=\"/crosstools/gccwin/share/gettext\"
-DPROJECTSDIR=\"/crosstools/gccwin/share/gettext/projects\" -DHAVE_CONFIG_H -I.
-I.. -I../../../gettext-0.16.1/gettext-tools/src -I.
-I../../../gettext-0.16.1/gettext-tools/src -I..
-I../../../gettext-0.16.1/gettext-tools
-I../../../gettext-0.16.1/gettext-tools/libgrep
-I../../../gettext-0.16.1/gettext-tools/libuniname -I../gnulib-lib
-I../../../gettext-0.16.1/gettext-tools/gnulib-lib -I../intl
-I../../../gettext-0.16.1/gettext-tools/../gettext-runtime/intl
-I/crosstools/gccwin/include -g -O2 -c
../../../gettext-0.16.1/gettext-tools/src/msgl-check.c -DDLL_EXPORT -DPIC -o
.libs/msgl-check.o
../../../gettext-0.16.1/gettext-tools/src/msgl-check.c: In function
'plural_help':
../../../gettext-0.16.1/gettext-tools/src/msgl-check.c:195: error:
unrecognizable insn:
(insn 40 39 41 6 ../../../gettext-0.16.1/gettext-tools/src/msgl-check.c:180
(set (reg:SI 76)
(const:SI (plus:SI (mem:SI (symbol_ref:SI ("#i.plural_table") ) [0 S4 A8])
(const_int 4 [0x4] -1 (nil)
(nil))
../../../gettext-0.16.1/gettext-tools/src/msgl-check.c:195: internal compiler
error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
I configured gettext with
../gettext-0.16.1/configure --prefix=/crosstools/gccwin
--build=i686-pc-linux-gnu --host=i686-pc-mingw32 --disable-java
--disable-native-java --with-libiconv-prefix=/crosstools/gccwin
--disable-threads --disable-openmp
If I am doing anything wrong here I'm open to suggestions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug fortran/26227] accepts invalid fortran, different dummy types/number
--- Comment #9 from burnus at gcc dot gnu dot org 2007-04-05 13:27 --- This probably will work automatically if inter-file checking is implemented, but if not, here is an invalid example which should be rejected: - SUBROUTINE PHLOAD (READER,*) IMPLICIT NONE EXTERNAL READER CALL READER (*1) 1RETURN 1 END SUBROUTINE program test EXTERNAL R call PHLOAD (R, 1) CALL PHLOAD (R, 2) END program test - Should give the error (cf. NAG f95): Error: y.f: Argument no. 2 in reference to PHLOAD from TEST is not a label -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26227
[Bug fortran/31472] gfortran does not detect the illegal use of an access specification in a program, subroutine, or function
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-05 14:13 --- The patch is wrong since the PRIVATE/PUBLIC statement is also allowed for type: module foo type t private integer, public :: foo end type t end module foo Actually, currently gfortran also invalidly rejects the "integer, public :: foo". See NOTE 4.41 in Section 4.5.3.6 of the Fortran 2003 standard for an example. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31472
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #17 from amacleod at redhat dot com 2007-04-05 14:23 --- Is the output from .optimized different? (once the ssa versions numbers have been stripped). Those PHIs should be irrelevant, the question is whether the different versioning has any effect. The only way I can think that out-of-ssa could produce different results is if it had to choose between two same-cost coalesces, and the versioning resulted in them being in different places in the coalesce list. Check the .optimized output and if the code is equivalent, the problem is after that stage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug libstdc++/31481] GCC 4.2.0 incompatible with STLport 5.1.3
--- Comment #7 from pcarlini at suse dot de 2007-04-05 14:43 --- Can be fixed by packporting a few additional forthcoming clean-up bits from mainline... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-05 14:43:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31481
[Bug fortran/31487] New: Character array initialization in derived type: bad zero padding
Hi, here's an annoying one. Default initializing a character array in a derived type leads to zero padded strings instead of space-padded ones. E.g. ! This works correctly: character(len=16) ::tdefi(2) = (/'0z1jan','1hr '/) ! 1234567890 ! Broken in derived type: type t_ctl character(len=16) :: tdefi(2) = (/'0z1jan','1hr '/) ! 1234567890 end type t_ctl See the attached program for details. -- Summary: Character array initialization in derived type: bad zero padding Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31487
[Bug fortran/31487] Character array initialization in derived type: bad zero padding
--- Comment #1 from anlauf at gmx dot de 2007-04-05 14:51 --- Created an attachment (id=13332) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13332&action=view) Demo code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31487
[Bug fortran/31292] ICE with module procedure interface in a procedure body
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-05 15:00 --- Subject: Bug 31292 Author: pault Date: Thu Apr 5 15:00:27 2007 New Revision: 123517 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123517 Log: 2007-04-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31292 * decl.c (gfc_match_modproc): Go up to the top of the namespace tree to find the module namespace for gfc_get_symbol. 2007-04-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31292 * gfortran.dg/contained_module_proc_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/contained_module_proc_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31292
[Bug fortran/31483] ICE on fortran Code
--- Comment #5 from pault at gcc dot gnu dot org 2007-04-05 15:06 --- Subject: Bug 31483 Author: pault Date: Thu Apr 5 15:06:15 2007 New Revision: 123518 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123518 Log: 2007-04-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31483 * trans-expr.c (gfc_conv_function_call): Give a dummy procedure the correct type if it has alternate returns. 2007-04-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31483 * gfortran.dg/altreturn_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/altreturn_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31483
[Bug target/31478] Typo in sse2_umulv2siv2di3 pattern
--- Comment #5 from hjl at lucon dot org 2007-04-05 15:12 --- (In reply to comment #3) > > There is no corresponding define_expand for this pattern. Many define_insn > > patterns without define_expand don't call ix86_binary_operator_ok. Will that > > be a problem? > > Those are sse builtins and are expanded via ix86_expand_binop_builtin(). This > function fixes all operands to satisfy ix86_binary_operator_ok(). > So anothe word is those patterns are used by ix86_expand_binop_builtin() and won't be generated automatically. Will be "sse2_umulv2siv2di3" generated automatically? If yes, what makes it different from other patterns used by ix86_expand_binop_builtin() only? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31478
[Bug c++/31484] va_list handeling different in 64bit vs 32 bit.
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-05 15:34 --- note you can also use va_copy but that is c99. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31484
[Bug target/29793] TESTW{W,L,Q} rCX + JZ/JE should be replaced by J{,E,R}CXZ when possible
--- Comment #6 from ubizjak at gmail dot com 2007-04-05 16:27 --- (In reply to comment #5) > Can we compute the displacement reliable enough to say that it is smaller than > some other number (e.g. 64)? Good idea! The (untested) patch that handles SImode compares is at http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00178.html. Have fun ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29793
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #18 from ubizjak at gmail dot com 2007-04-05 16:39 --- (In reply to comment #17) > Is the output from .optimized different? (once the ssa versions numbers have > been stripped). Those PHIs should be irrelevant, the question is whether the > different versioning has any effect. > > The only way I can think that out-of-ssa could produce different results is if > it had to choose between two same-cost coalesces, and the versioning resulted > in them being in different places in the coalesce list. Check the .optimized > output and if the code is equivalent, the problem is after that stage. They are _not_ equivalent. We have: --cut here-- : __builtin_puts (&"Start?"[0]); v2x = 0.0; v2y = 1.0e+0; v2z = 0.0; i = 0; v1x = 1.0e+0; v1y = 0.0; v1z = 0.0; :; v3x = v1y * v2z - v1z * v2y; v3y = v1z * v2x - v1x * v2z; v3z = v1x * v2y - v1y * v2x; i = i + 1; v1z = v2z; v1y = v2y; v1x = v2x; v2z = v3z; v2y = v3y; v2x = v3x; if (i != 1) goto ; else goto ; :; __builtin_puts (&"Stop!"[0]); printf (&"Result = %f, %f, %f\n"[0], (double) v3x, (double) v3y, (double) v3z); return 0; --cut here-- =VS= --cut here-- : __builtin_puts (&"Start?"[0]); i = 0; v1x = 1.0e+0; v1y = 0.0; v1z = 0.0; v2x.43 = 0.0; v2y.44 = 1.0e+0; v2z.45 = 0.0; :; v3x = v1y * v2z.45 - v1z * v2y.44; v3y = v1z * v2x.43 - v1x * v2z.45; v3z = v1x * v2y.44 - v1y * v2x.43; i = i + 1; v2z = v3z; v2y = v3y; v2x = v3x; v1z = v2z.45; v1y = v2y.44; v1x = v2x.43; if (i != 1) goto ; else goto ; :; v2x.43 = v2x; v2y.44 = v2y; v2z.45 = v2z; goto (); :; __builtin_puts (&"Stop!"[0]); printf (&"Result = %f, %f, %f\n"[0], (double) v3x, (double) v3y, (double) v3z); return 0; --cut here-- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug target/25448] [4.0/4.1/4.2/4.3 Regression] Unfounded warnings from the AVR backend
--- Comment #4 from aesok at gcc dot gnu dot org 2007-04-05 16:43 --- Subject: Bug 25448 Author: aesok Date: Thu Apr 5 16:43:35 2007 New Revision: 123519 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123519 Log: PR target/25448 * config/avr/avr.c (avr_handle_fndecl_attribute): Use the DECL_ASSEMBLER_NAME, not the DECL_NAME. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25448
[Bug target/31478] Typo in sse2_umulv2siv2di3 pattern
--- Comment #6 from ubizjak at gmail dot com 2007-04-05 16:48 --- (In reply to comment #5) > So anothe word is those patterns are used by ix86_expand_binop_builtin() > and won't be generated automatically. Will be "sse2_umulv2siv2di3" > generated automatically? If yes, what makes it different from other > patterns used by ix86_expand_binop_builtin() only? No, they won't be generated automatically, because they don't have the name that is recognized by generic expander. IOW, they are not named insn pattern. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31478
[Bug target/31478] Typo in sse2_umulv2siv2di3 pattern
--- Comment #7 from hjl at lucon dot org 2007-04-05 16:54 ---
(In reply to comment #6)
> (In reply to comment #5)
>
> > So anothe word is those patterns are used by ix86_expand_binop_builtin()
> > and won't be generated automatically. Will be "sse2_umulv2siv2di3"
> > generated automatically? If yes, what makes it different from other
> > patterns used by ix86_expand_binop_builtin() only?
>
> No, they won't be generated automatically, because they don't have the name
> that is recognized by generic expander. IOW, they are not named insn pattern.
>
Since sse2_umulv2siv2di3 is used by ix86_expand_binop_builtin() and sse.md
only:
[EMAIL PROTECTED] i386]$ grep sse2_umulv2siv2di3 *.c *.md
i386.c: { MASK_SSE2, CODE_FOR_sse2_umulv2siv2di3, 0, IX86_BUILTIN_PMULUDQ128,
0, 0 },
sse.md:(define_insn "sse2_umulv2siv2di3"
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (gen_lowpart (V2DImode, t1), op1,
op2));
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (gen_lowpart (V2DImode, t4), t2,
t3));
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (t1, gen_lowpart (V4SImode, op1),
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (t4, gen_lowpart (V4SImode, op1),
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (t5, gen_lowpart (V4SImode, op2),
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (operands[0], t1, t2));
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (operands[0], t1, t2));
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (operands[0], t1, t2));
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (operands[0], t1, t2));
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (t1, operands[1], operands[2]));
sse.md: emit_insn (gen_sse2_umulv2siv2di3 (t4, t2, t3));
is ix86_binary_operator_ok in sse2_umulv2siv2di3 not used at all and really
optional?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31478
[Bug target/25448] [4.0/4.1/4.2/4.3 Regression] Unfounded warnings from the AVR backend
--- Comment #6 from aesok at gcc dot gnu dot org 2007-04-05 16:56 --- Subject: Bug 25448 Author: aesok Date: Thu Apr 5 16:56:43 2007 New Revision: 123521 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123521 Log: PR target/25448 * config/avr/avr.c (avr_handle_fndecl_attribute): Use the DECL_ASSEMBLER_NAME, not the DECL_NAME. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/avr/avr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25448
[Bug target/25448] [4.0/4.1/4.2/4.3 Regression] Unfounded warnings from the AVR backend
--- Comment #5 from aesok at gcc dot gnu dot org 2007-04-05 16:50 --- Subject: Bug 25448 Author: aesok Date: Thu Apr 5 16:50:27 2007 New Revision: 123520 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123520 Log: PR target/25448 * config/avr/avr.c (avr_handle_fndecl_attribute): Use the DECL_ASSEMBLER_NAME, not the DECL_NAME. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/avr/avr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25448
[Bug target/25448] [4.0/4.1/4.2/4.3 Regression] Unfounded warnings from the AVR backend
--- Comment #7 from aesok at gcc dot gnu dot org 2007-04-05 16:59 --- Fixsed in 4.1.3, 4.2 and 4.3. -- aesok at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25448
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #19 from amacleod at redhat dot com 2007-04-05 17:24 --- what are you using for a compiler? Im using a mainline from mid march, and with it, my .optimized files diff exactly the same, and I get the aforementioned time differences in the executables. (sse.c and sse-bad.c are same, just different names to get different output files) 2007-03-13/gcc> diff sse.c sse-bad.c 2007-03-13/gcc>./xgcc -B./ sse.c -fdump-tree-optimized -O3 -march=pentium4 -o sse 2007-03-13/gcc>./xgcc -B./ sse-bad.c -fdump-tree-optimized -O3 -march=pentium4 -mfpmath=sse -o sse-bad 2007-03-13/gcc>ls -l sse*optimized -rw-rw-r-- 1 amacleod amacleod 864 Apr 5 12:16 sse-bad.c.116t.optimized -rw-rw-r-- 1 amacleod amacleod 864 Apr 5 12:16 sse.c.116t.optimized 2007-03-13/gcc>diff sse.c.116t.optimized sse-bad.c.116t.optimized 2007-03-13/gcc>time ./sse Start? Stop! Result = 0.00, 0.00, 1.00 real0m0.630s user0m0.572s sys 0m0.000s 2007-03-13/gcc>time ./sse-bad Start? Stop! Result = 0.00, 0.00, 1.00 real0m0.883s user0m0.780s sys 0m0.000s Is this just with earlier compilers, what version are you using? It at least seems to indicate that the problem isn't before out-of-ssa since the time issue is still there with identical outputs from .optimized -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug target/31478] Typo in sse2_umulv2siv2di3 pattern
--- Comment #8 from hjl at lucon dot org 2007-04-05 17:54 --- (In reply to comment #4) > (In reply to comment #3) > > > There is indeed a pattern without this check - sse2_pmaddwd. > > Due to %, it is commutative, so check for PLUS of V8HI mode would be OK. > > Please also change operands 1 and 2 of sdot_prodv8hi expander to > register_operand to avoid further suprises. > I am not sure if there is an issue since op0 of sse2_pmaddwd must be register and it must be the same as op1 or op2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31478
[Bug preprocessor/29851] Need to strip trailing slashes on include pathnames
--- Comment #4 from eweddington at cso dot atmel dot com 2007-04-05 18:07 --- This is a duplicate of bug #22133. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29851
[Bug preprocessor/29851] Need to strip trailing slashes on include pathnames
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-05 19:15 --- *** This bug has been marked as a duplicate of 22133 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29851
[Bug c/22133] In MinGW trailling slash forward not allowed in include path
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-05 19:15 --- *** Bug 29851 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22133
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #20 from ubizjak at gmail dot com 2007-04-05 19:39 --- (In reply to comment #19) > what are you using for a compiler? Im using a mainline from mid march, and gcc version 4.3.0 20070404 (experimental) on i686-pc-linux-gnu with > it, my .optimized files diff exactly the same, and I get the aforementioned > time differences in the executables. This is because -march=pentium4 enables all sse builtins for both cases. > (sse.c and sse-bad.c are same, just different names to get different output > files) > > 2007-03-13/gcc> diff sse.c sse-bad.c > > 2007-03-13/gcc>./xgcc -B./ sse.c -fdump-tree-optimized -O3 -march=pentium4 -o > sse > > 2007-03-13/gcc>./xgcc -B./ sse-bad.c -fdump-tree-optimized -O3 -march=pentium4 > -mfpmath=sse -o sse-bad This is known effect of SFmode SSE being slower than SFmode x87. But again, you have enabled sse(2) builtins due to -march=pentium4. Please try to compile using only "-O2" and "-O2 -msse". x87 math will be used in both cases, but .optimized will show the difference. You can also try to compile with and without -ffast-math. IMO it is not acceptabe for tree dumps to depend on target compile flag in any way... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug target/31488] New: va_list considered non-POD
.../libjava/classpath/include/jvmti.h:1242: warning: can not pass objects of non-POD type 'struct va_list' through '...'; call will abort at runtime Not sure yet whether this is a target problem or not. -- Summary: va_list considered non-POD Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rth at gcc dot gnu dot org GCC target triplet: alpha* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug target/31478] Typo in sse2_umulv2siv2di3 pattern
--- Comment #9 from ubizjak at gmail dot com 2007-04-05 19:50 --- (In reply to comment #8) > > Please also change operands 1 and 2 of sdot_prodv8hi expander to > > register_operand to avoid further suprises. > > > > I am not sure if there is an issue since op0 of sse2_pmaddwd must be > register and it must be the same as op1 or op2. But only after reload. Nothing prevents gcc to generate two MEM input operands. Although reload will fix this by putting one of input operands into register (and match it with output operand), but this will be too late for any pre-reload pass to make any optimization on inputs. > is ix86_binary_operator_ok in sse2_umulv2siv2di3 not used at all and really > optional? No, it is not optional. V8HImode argument is optional, since we don't allow immediate operands. Please track code flow through ix86_b_o_ok() and you will see. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31478
[Bug middle-end/22156] [4.0/4.1/4.2/4.3 Regression] bit-field copying regressed
--- Comment #12 from aoliva at gcc dot gnu dot org 2007-04-05 19:50 --- Subject: Bug 22156 Author: aoliva Date: Thu Apr 5 19:50:34 2007 New Revision: 123524 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123524 Log: PR middle-end/22156 * tree-sra.c (struct sra_elt): Add in_bitfld_block. Remove all_no_warning. (struct sra_walk_fns): Remove use_all parameter from use. (sra_hash_tree): Handle BIT_FIELD_REFs. (sra_elt_hash): Don't hash bitfld blocks. (sra_elt_eq): Skip them in parent compares as well. Handle BIT_FIELD_REFs. (sra_walk_expr): Don't maintain or pass down use_all_p. (scan_use): Remove use_all parameter. (scalarize_use): Likewise. Re-expand assignment to BIT_FIELD_REF of gimple_reg. De-scalarize before input or output, and re-scalarize after output. Don't mark anything for no warning. (scalarize_ldst): Adjust. (scalarize_walk_gimple_modify_statement): Likewise. (build_element_name_1): Handle BIT_FIELD_REFs. (instantiate_element): Don't warn for any element whose parent is used as a whole. (instantiate_missing_elements_1): Return the sra_elt. (canon_type_for_field): New. (try_instantiate_multiple_fields): New. (instantiate_missing_elemnts): Use them. (mark_no_warning): Removed. (generate_one_element_ref): Handle BIT_FIELD_REFs. (REPLDUP, sra_build_elt_assignment): New. (generate_copy_inout): Use them. (generate_element_copy): Likewise. Handle bitfld differences. (generate_element_zero): Don't recurse for blocks. Use sra_build_elt_assignment. (generate_one_element_int): Take elt instead of var. Use sra_build_elt_assignment. (generate_element_init_1): Adjust. (scalarize_use, scalarize_copy): Use REPLDUP. (scalarize_ldst): Move assert before dereference. (dump_sra_elt_name): Handle BIT_FIELD_REFs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug target/31478] Typo in sse2_umulv2siv2di3 pattern
--- Comment #10 from hjl at lucon dot org 2007-04-05 20:05 ---
(In reply to comment #9)
> (In reply to comment #8)
>
> > > Please also change operands 1 and 2 of sdot_prodv8hi expander to
> > > register_operand to avoid further suprises.
> > >
> >
> > I am not sure if there is an issue since op0 of sse2_pmaddwd must be
> > register and it must be the same as op1 or op2.
>
> But only after reload. Nothing prevents gcc to generate two MEM input
> operands.
> Although reload will fix this by putting one of input operands into register
> (and match it with output operand), but this will be too late for any
> pre-reload pass to make any optimization on inputs.
>
Will something like
--- sse.md.pmaddwd 2007-04-04 17:44:43.0 -0700
+++ sse.md 2007-04-05 12:02:28.0 -0700
@@ -3044,7 +3044,7 @@
(match_operand:V8HI 1 "nonimmediate_operand" "")
(match_operand:V8HI 2 "nonimmediate_operand" "")
(match_operand:V4SI 3 "register_operand" "")]
- "TARGET_SSE2"
+ "TARGET_SSE && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
{
rtx t = gen_reg_rtx (V4SImode);
emit_insn (gen_sse2_pmaddwd (t, operands[1], operands[2]));
work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31478
[Bug target/31478] Typo in sse2_umulv2siv2di3 pattern
--- Comment #11 from hjl at lucon dot org 2007-04-05 20:06 ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> >
> > > > Please also change operands 1 and 2 of sdot_prodv8hi expander to
> > > > register_operand to avoid further suprises.
> > > >
> > >
> > > I am not sure if there is an issue since op0 of sse2_pmaddwd must be
> > > register and it must be the same as op1 or op2.
> >
> > But only after reload. Nothing prevents gcc to generate two MEM input
> > operands.
> > Although reload will fix this by putting one of input operands into register
> > (and match it with output operand), but this will be too late for any
> > pre-reload pass to make any optimization on inputs.
> >
>
> Will something like
>
> --- sse.md.pmaddwd 2007-04-04 17:44:43.0 -0700
> +++ sse.md 2007-04-05 12:02:28.0 -0700
> @@ -3044,7 +3044,7 @@
> (match_operand:V8HI 1 "nonimmediate_operand" "")
> (match_operand:V8HI 2 "nonimmediate_operand" "")
> (match_operand:V4SI 3 "register_operand" "")]
> - "TARGET_SSE2"
> + "TARGET_SSE && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
> {
>rtx t = gen_reg_rtx (V4SImode);
>emit_insn (gen_sse2_pmaddwd (t, operands[1], operands[2]));
>
> work?
>
It doesn't work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31478
[Bug target/31488] va_list considered non-POD
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-05 20:28 --- Most likely this is because va_list is represented as an array for alpha and a couple other targets. So maybe it might be just the warning is incorrect but it is still undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug target/31488] va_list considered non-POD
--- Comment #2 from rth at gcc dot gnu dot org 2007-04-05 21:45 --- It is *not* represented as an array on Alpha. And even if it were, it wouldn't be undefined. Passing va_list by value is non-portable, but certainly not undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug fortran/31292] ICE with module procedure interface in a procedure body
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-05 21:49 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31292
[Bug fortran/31293] Implicit character and array returning functions
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-05 21:58 --- I submitted a patch for this in: http://gcc.gnu.org/ml/fortran/2007-04/msg00016.html Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31293
[Bug fortran/31424] ICE involving transfer function, and passing function return to subroutine
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-05 21:59 --- I submitted a patch for this in: http://gcc.gnu.org/ml/fortran/2007-04/msg00016.html Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31424
[Bug fortran/31222] Rejected: implicitly-typed dummys used in initialization expressions
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-05 22:00 --- I submitted a patch for this in: http://gcc.gnu.org/ml/fortran/2007-04/msg00016.html Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31222
[Bug fortran/30872] Bogus "size of variable is too large"
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-05 22:01 --- I submitted a patch for this in: http://gcc.gnu.org/ml/fortran/2007-04/msg00016.html Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30872
[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.
--- Comment #6 from steven at gcc dot gnu dot org 2007-04-05 22:01 ---
The tree dump for the original test case now looks like this for me:
;; Function foo (foo)
foo (p)
{
:
return (unsigned int) ((BIT_FIELD_REF <*p, 8, 0> & 1) != 0);
}
;; Function bar (bar)
bar (p)
{
:
return (unsigned int) p->bit;
}
The resulting assembler output is the same, but I imagine VRP should be able to
fold away the "& 1" test. I don't know if the BIT_FIELD_REF itself should be
optimized away, but I guess so. Consider the following test case:
struct s
{
unsigned int bit:1;
};
unsigned int
foo (struct s *p)
{
if (p->bit)
return (unsigned int) (p->bit);
else
return 0;
}
This gets "optimized" at the tree level to this ugly code:
;; Function foo (foo)
foo (p)
{
unsigned int D.1979;
:
if ((BIT_FIELD_REF <*p, 8, 0> & 1) != 0) goto ; else goto ;
:;
D.1979 = 0;
goto ();
:;
D.1979 = (unsigned int) p->bit;
:;
return D.1979;
}
In summary, I don't think we can close this bug just yet.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2005-12-10 04:15:46 |2007-04-05 22:01:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
[Bug target/31478] Typo in sse2_umulv2siv2di3 pattern
--- Comment #12 from hjl at gcc dot gnu dot org 2007-04-05 22:16 --- Subject: Bug 31478 Author: hjl Date: Thu Apr 5 22:16:37 2007 New Revision: 123527 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123527 Log: 2007-04-05 Uros Bizjak <[EMAIL PROTECTED]> H.J. Lu <[EMAIL PROTECTED]> PR target/31478 * config/i386/sse.md (sse2_umulv2siv2di3): Use V4SImode instead of V8HImode when calling ix86_binary_operator_ok. (sse2_pmaddwd): Call ix86_binary_operator_ok. (sdot_prodv8hi): Operands 1 and 2 must be register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31478
[Bug middle-end/22156] [4.0/4.1/4.2 Regression] bit-field copying regressed
--- Comment #13 from aoliva at gcc dot gnu dot org 2007-04-05 23:06 --- Fixed in trunk for 4.3, not sure about backporting... -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |bit-field copying regressed |bit-field copying regressed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug tree-optimization/15596] [4.0/4.1/4.2/4.3 Regression] Missed optimization with bitfields with return value
--- Comment #12 from aoliva at gcc dot gnu dot org 2007-04-05 23:33 --- FWIW, the patch for PR 22156 does not change the generated code on ppc, although it appears to improve the x86 code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15596
[Bug middle-end/20671] Poor bit-field code generation
--- Comment #4 from aoliva at gcc dot gnu dot org 2007-04-05 23:36 --- No change with the patch for PR 22156. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20671
[Bug c++/31489] New: error says struct when it should say class
When a forward declared class is not found the error message describes it
incorrectly as a struct. See below for an example.
I'd like to submit a patch to correctly display class. Let me know if such a
patch would be considered.
$ g++ -Wall -ggdb -O0 -o t test6.cpp
test6.cpp: In function int main():
test6.cpp:8: error: invalid use of undefined type struct foobar
test6.cpp:4: error: forward declaration of struct foobar
File contains:
=
// g++ -Wall -ggdb -O0 -o t test6.cpp
class foobar;
int main()
{
foobar * o = new foobar;
}
--
Summary: error says struct when it should say class
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jg at jguk dot org
GCC build triplet: i686-gnu-linux
GCC host triplet: i686-gnu-linux
GCC target triplet: i686-gnu-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31489
[Bug target/27869] "-O -fregmove" handles SSE scalar instructions incorrectly
--- Comment #6 from echristo at apple dot com 2007-04-05 23:56 --- Actually, I'll go ahead and take this, it was reported internally as well here and I've got a patch in testing :) -- echristo at apple dot com changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |echristo at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27869
[Bug c++/31489] error says struct when it should say class
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-06 00:09 ---
I don't think this matters anyways as class == struct and can be used
interchangably for tags.
if you summit a patch, see what this shows you:
struct foobar;
int main()
{
foobar * o = new foobar;
}
Or even this:
struct foobar;
class foobar;
int main()
{
foobar * o = new foobar;
}
Since all three are the same code, so it is weird not to have struct == class
here really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31489
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-04-06 00:58 --- These testcases fail on spu-elf: +FAIL: gcc.dg/float-range-1.c (test for warnings, line 11) +FAIL: gcc.dg/float-range-1.c (test for excess errors) +FAIL: gcc.dg/float-range-3.c (test for excess errors) +FAIL: gcc.dg/float-range-4.c (test for excess errors) +FAIL: gcc.dg/float-range-5.c (test for warnings, line 9) +FAIL: gcc.dg/float-range-5.c (test for warnings, line 10) +FAIL: gcc.dg/float-range-5.c (test for excess errors) FAIL: gcc.dg/float-range-1.c (test for excess errors) Excess errors: /home/apinski/src/local/gcc/gcc/testsuite/gcc.dg/float-range-1.c:11: error: floating constant exceeds range of 'float' Excess errors: /home/apinski/src/local/gcc/gcc/testsuite/gcc.dg/float-range-3.c:10: error: 'FP_INFINITE' undeclared (first use in this function) /home/apinski/src/local/gcc/gcc/testsuite/gcc.dg/float-range-3.c:10: error: (Each undeclared identifier is reported only once /home/apinski/src/local/gcc/gcc/testsuite/gcc.dg/float-range-3.c:10: error: for each function it appears in.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug target/31490] New: Compile error section type conflict
The attached testcase does not compile for ppc64 using gcc confgured to generate ppc/ppc64 code. Attached is a reduced testcase from kernel. This error was not happening with gcc 4.2 snapshot from January. I think it is related to static inline and extern inline. compile the attached testcase gcc -m64 -c test.c test.c:51: error: __ksymtab_cpu_add_sysdev_attr_group causes a section type conflict -- Summary: Compile error section type conflict Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug target/31490] Compile error section type conflict
--- Comment #1 from raj dot khem at gmail dot com 2007-04-06 01:28 --- Created an attachment (id=1) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=1&action=view) testcase testcase to reproduce the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug target/31490] Compile error section type conflict
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-06 01:57 ---
Reduced testcase:
int cpu_ (void *attr) {}
const unsigned long _1 __attribute__((section("__"))) = (unsigned long)&cpu_ ;
const unsigned long _group __attribute__((section("__"))) = 0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug target/31490] Compile error section type conflict
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-06 01:59 --- > This error was not happening with gcc 4.2 snapshot from January. My reduced testcase shows it happens even in 4.0.2. I don't have any thing older than that right off hand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug middle-end/31448] [4.1/4.2/4.3 Regression] ICE in expand_shift with bit fields and expand inlining constants
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-06 02:58 --- Mine, I have a patch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-06 02:58:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31448
[Bug libffi/31491] New: libffi: bug in example program
In http://gcc.gnu.org/svn/gcc/trunk/libffi/README /* Initialize the argument info vectors */ args[0] = &ffi_type_uint; should be /* Initialize the argument info vectors */ args[0] = &ffi_type_pointer; The code happens to work stand-alone, but when included in a large program on x86_64, you get a nasty segfault. -- Summary: libffi: bug in example program Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alexander dot belopolsky at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31491
[Bug target/31490] Compile error section type conflict
--- Comment #4 from dtemirbulatov at gmail dot com 2007-04-06 03:18 --- looks like regression is caused by PR26090 fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug libffi/31491] libffi: bug in example program
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-06 03:21 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-06 03:21:58 date|| Summary| libffi: bug in example |libffi: bug in example |program |program http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31491
[Bug fortran/31395] Colon edit descriptor is ignored unless preceded by a comma or a slash
--- Comment #2 from patchapp at dberlin dot org 2007-04-06 07:25 --- Subject: Bug number PR31395 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00229.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31395
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #21 from ubizjak at gmail dot com 2007-04-06 07:37 --- Strange things happen. I have fully removed gcc build directory and bootstrapped gcc from scratch. To my suprise, the difference with -msse and without -msse is now gone and optimized dumps are now the same. For reference, the compiler has ident "gcc version 4.3.0 20070406 (experimental)". Regarding this bug - SSE performance vs x87 performance is clearly target procesor dependant. There is nothing gcc can do, and even without memory acces, SSE is slower than x87 on some targets (ref: Comment #5). Let's close this bug as WONTFIX, as there is nothing to fix in gcc. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
