[Bug rtl-optimization/20600] New: failure for pass.c on x86_64-pc-linux-gnu
This is caused by subregs not being allowed in addresses. The splitter generates something that is not recognized as a *lea_1_rex64 pattern. More on this at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02072.html Paolo -- Summary: failure for pass.c on x86_64-pc-linux-gnu Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, patch Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: bonzini at gcc dot gnu dot org ReportedBy: bonzini at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20600
about 4.0 swing modulo schedule
the application swim from the spec2000 can`t be scheduled, function calc1 can`t be scheduled, while i tries larger sms-max-ii-factor, it still can`t.
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From giovannibajo at libero dot it 2005-03-23 10:51 --- The first non-trivial issue is that, in order to print std::vectorint instead of std::vectorint, std::allocatorint , we need to do the template substitution at error printing time, and check if the resulting substitution match. Either that, or I need to mark template arguments with a flag if they come from the template-id. Also, should we skip default arguments also in lines like this: test.cc: In member function `void AT, N, X::foo() [with T = int, int N = 0, int X = 1]': We would be left with something like : test.cc: In member function `void AT, N, X::foo() [with T = int]': I assume that sounds about right, even if it might be surprising at first why the with clause does not show all the parameters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/20513] [4.0/4.1 Regression] ICE when compiling with debug info and embedded using
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-17 07:26:12 |2005-03-23 10:54:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20513
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From giovannibajo at libero dot it 2005-03-23 11:01 --- or maybe: test.cc: In member function `void AT, N, X::foo() [with T = int, int N = default, int X = default]': -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug fortran/17123] Assertion fail in trans-const.c
--- Additional Comments From refson dot temp at ntlworld dot com 2005-03-23 11:16 --- This bug is a complete showstopper, but has been sitting unresolved for 6 months. Is there any way to increase the priority and actually have it assigned to anyone? There is no way to even test that the rest of our code compiles until this is fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17123
[Bug tree-optimization/20601] New: [4.0 Regression] PRE related miscompilation
extern void abort (void);
extern void exit (int);
struct T
{
char *t1;
char t2[4096];
char **t3;
};
int a[5];
int b;
char **c;
int d;
char **e;
struct T t;
char *f[16];
char *g[] = { a, -u, b, c };
__attribute__ ((__noreturn__)) void
foo (void)
{
while (1);
}
__attribute__ ((noinline)) char *
bar (char *x, unsigned int y)
{
return 0;
}
static inline char *
baz (char *x, unsigned int y)
{
if (sizeof (t.t2) != (unsigned int) -1 y sizeof (t.t2))
foo ();
return bar (x, y);
}
static inline int
setup1 (int x)
{
char *p;
int rval;
if (!baz (t.t2, sizeof (t.t2)))
baz (t.t2, sizeof (t.t2));
if (x 0x200)
{
char **h, **i = e;
++d;
e = f;
if (t.t1 *t.t1)
e[0] = t.t1;
else
abort ();
for (h = e + 1; (*h = *i); ++i, ++h)
;
}
return 1;
}
static inline int
setup2 (void)
{
int j = 1;
e = c + 1;
d = b - 1;
while (d 0 e[0][0] == '-')
{
if (e[0][1] != '\0' e[0][2] != '\0')
abort ();
switch (e[0][1])
{
case 'u':
if (!e[1])
abort ();
t.t3 = e[1];
d--;
e++;
break;
case 'P':
j |= 0x1000;
break;
case '-':
d--;
e++;
if (j == 1)
j |= 0x600;
return j;
}
d--;
e++;
}
if (d 0 !(j 1))
abort ();
return j;
}
int
main (void)
{
int x;
c = g;
b = 4;
x = setup2 ();
t.t1 = /bin/sh;
setup1 (x);
if ((x 0x400) !a[4])
abort ();
exit (0);
}
is miscompiled on at least i386, x86_64 and ppc32 at -O2 (but e.g. on ppc64
is not). The bug goes away with -O2 -fno-tree-pre.
At *.crited there is still:
xD.1586_12 = PHI 1537(10), xD.1586_61(38), xD.1586_2(28), xD.1586_128(27);
later on used by
x.0D.1645_38 = (unsigned intD.3) xD.1586_12;
...
D.1589_46 = x.0D.1645_38 10;
D.1590_47 = (intD.0) D.1589_46;
D.1591_48 = D.1590_47 1;
if (D.1591_48 != 0) goto L40; else goto L66;
1537 == 0x601 is one of the possible values for x, if g contained say --
as second argument, but it is certainly not the only one (x should be 1 with
the g array provided in the testcase).
Yet PRE decides to use 0x601, so the
if ((x 0x400) !a[4])
abort ();
test aborts.
--
Summary: [4.0 Regression] PRE related miscompilation
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
GCC target triplet: i386-linux, x86_64-linux, ppc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20601
[Bug tree-optimization/20601] [4.0 Regression] PRE related miscompilation
-- What|Removed |Added CC||gnu-bugzilla at linuxnetz ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20601
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From caolanm at redhat dot com 2005-03-23 11:53 --- The workaround is trivial. But I'm still confused as to what exactly causes gcc to treat unnamed enums so much differently that named ones. It would be great if I could get some clarity on this. I have a handful of cases like this in the openoffice.org code base and OOo is reluctant to take the patches to fix unless sure it's currently invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug ada/20596] Bug Box, combination of Ada 2005, dotted notation, Hash_Maps, and Unbounded_String
--- Additional Comments From laurent at guerby dot net 2005-03-23 11:55 --- Could you try the patch from PR ada/20593 and report? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20593 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20596
[Bug ada/20593] [4.0/4.1 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC
--- Additional Comments From laurent at guerby dot net 2005-03-23 11:54 --- I confirm the patch solves the problem, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20593
[Bug rtl-optimization/20532] [4.0/4.1 Regression] Bad code for DImode left shifts by 31 and then 1
--- Additional Comments From macro at linux-mips dot org 2005-03-23 12:15 --- + (v * (((HOST_WIDE_ITN)1 31) + ((HOST_WIDE_INT)1 31))) ^^^ There is a typo above. Thanks for your fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20532
[Bug c++/20602] New: gcc crashes and asks to submit a bug.
Hi,
g++ crashes and asks me to submit a bug on the following program fragment:
The command is:
g++-3.2 -c -Wreturn-type -pedantic -pedantic-errors -Wundef testing.cpp -o
testing.o
The OS:
Linux 2.4.26.1.p4 #1 i686
(and also on 2.4.21.4)
The code (file testing.cpp) is:
#include vector
#include iostream
template class D class union_find;
template class D class union_findD :: index;
template class D
std::ostream operator ( std::ostream ,
const union_find D );
int main( unsigned int nrarguments, char arguments [] )
{
std::cout have a nice day without crashes!\n;
}
--
Summary: gcc crashes and asks to submit a bug.
Product: gcc
Version: 3.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nivelle at mpi-sb dot mpg dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20602
[Bug c++/14912] Do not print default template arguments in error messages
--- Additional Comments From dave at boost-consulting dot com 2005-03-23 12:55 --- Doesn't sound right to me. I think you should either show vectorT or include A in the with clause of vectorT,A. I'm sort of inclined to the former; Don't forget that parameter names are not always so short. Another related issue is that with clauses are sometimes unhelpful, as in the case you cite. vectorint is much, much clearer. GCC ought to have a heuristic based on the lengths of the version with the with clause and the version with a full argument substitution, to decide whether to use with or just substitute the arguments in-line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug tree-optimization/20598] [4.1 regression] gcc.c-torture/unsorted/uuarg.c, -O3
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-23 13:29 --- Also happens on hppa-unknown-linux-gnu. -- What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20598
[Bug tree-optimization/20598] [4.1 regression] gcc.c-torture/unsorted/uuarg.c, -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 13:59 --- On powerpc-darwin, so I am going to assume now this is target independent. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC target triplet|cris-* mmix-* | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20598
[Bug tree-optimization/20601] [4.0/4.1 Regression] PRE related miscompilation
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-23 14:02 --- Confirmed, i have a patch coming. I missed an early exit condition in constification during PRE. This also occurs in 4.1. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-23 14:02:13 date|| Summary|[4.0 Regression] PRE related|[4.0/4.1 Regression] PRE |miscompilation |related miscompilation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20601
[Bug tree-optimization/20601] [4.0/4.1 Regression] PRE related miscompilation
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20601
[Bug target/20603] New: SPEC ICE's on powerpc-darwin compiling with -fprofile-arcs -O2 -mpowerpc64
I've been seeing the following SPEC ICEs on powerpc-darwin when compiling with -fprofile-arcs -O2 -mpowerpc64: == SPEC's gap: gcc -c -o system.o -DSYS_IS_BSD -DSYS_HAS_IOCTL_PROTO -DSYS_HAS_TIME_PROTO - DSYS_HAS_SIGNAL_PROTO -DSYS_HAS_ANSI -DSYS_HAS_CALLOC_PROTO - DSYS_HAS_STDIO_PROTO -fprofile-arcs -O2 -mpowerpc64 system.c system.c: In function 'SyFopen': system.c:688: internal compiler error: in schedule_insns, at sched-rgn.c:2549 == SPEC's gcc: gcc -c -o c-decl.o -DHOST_WORDS_BIG_ENDIAN -fno-inline-functions -fprofile- arcs -O3 -mpowerpc64 c-decl.c c-decl.c: In function 'duplicate_decls': c-decl.c:1860: warning: incompatible implicit declaration of built-in function 'memcpy' c-decl.c: In function 'layout_array_type': c-decl.c:5761: error: unrecognizable insn: (insn 61 0 0 (set (reg:SI 3 r3 [ t ]) (reg:DI 3 r3)) -1 (nil) (nil)) c-decl.c:5761: internal compiler error: in extract_insn, at recog.c:2042 == SPEC's crafty: gcc -c -o swap.o -DLINUX_SPARC -DSPEC_CPU2000 -fprofile-arcs -O3 -mpowerpc64 swap.c swap.c: In function 'Swap': swap.c:151: error: unrecognizable insn: (insn 1033 0 0 (set (reg:SI 5 r5 [ source ]) (reg:DI 2 r2)) -1 (nil) (nil)) swap.c:151: internal compiler error: in extract_insn, at recog.c:2042 The extract_insn error also shows up in other SPEC benchmarks. I think this problem was introduced between Feb. 3rd to Feb. 15th. This might be a duplicate of PR20203? -- Summary: SPEC ICE's on powerpc-darwin compiling with -fprofile- arcs -O2 -mpowerpc64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.7.0 GCC host triplet: powerpc-apple-darwin7.7.0 GCC target triplet: powerpc-apple-darwin7.7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20603
[Bug target/20603] SPEC ICE's on powerpc-darwin compiling with -fprofile-arcs -O2 -mpowerpc64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 14:24 --- This might be a duplicate of PR20203? no but it is a dup of PR 20249 which has a patch (which was approved but not applied yet). *** This bug has been marked as a duplicate of 20249 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20603
[Bug rtl-optimization/20249] [4.0/4.1 Regression] ICE with -fprofile-arcs on ppc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 14:25 --- *** Bug 20603 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dorit at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20249
[Bug c++/20602] gcc crashes and asks to submit a bug.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 14:33 --- Fixed already in 3.2.3. Confirmed in 3.2.2. Also this is invalid code but only rejected in 3.4.0 and above. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||ice-on-invalid-code Known to fail||3.2.2 Known to work||3.4.0 4.0.0 4.1.0 Resolution||FIXED Target Milestone|--- |3.1.x/3.2.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20602
[Bug treelang/20604] New: treelang does not get passed -fPIC by default on *-darwin
You can tell that it does not get passed -fPIC by the following failure in the testsuite: Executing on host: /Users/pinskia/src/new-fold/gcc/objdir/gcc/xgcc -B/Users/pinskia/src/new-fold/ gcc/objdir/gcc/ /Users/pinskia/src/new-fold/gcc/gcc/testsuite/treelang/execute/funccall.tree -lm -o ./funccall.exe(timeout = 300) /usr/bin/ld: /var/tmp//ccbSoNBy.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:^M _abort^M _exit^M collect2: ld returned 1 exit status^M compiler exited with status 1 output is: /usr/bin/ld: /var/tmp//ccbSoNBy.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:^M_abort^M _exit^M collect2: ld returned 1 exit status^M FAIL: treelang/execute/funccall.tree (test for excess errors) Excess errors: /usr/bin/ld: /var/tmp//ccbSoNBy.o has external relocation entries in non-writable section (__TEXT,__text) for symbols: _abort _exit With -v I get: /Users/pinskia/src/new-fold/gcc/objdir/gcc/tree1 -quiet -dumpbase funccall.tree -v -o /var/tmp// ccLOPtCF.s /Users/pinskia/src/new-fold/gcc/gcc/testsuite/treelang/execute/funccall.tree -- Summary: treelang does not get passed -fPIC by default on *- darwin Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: treelang AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20604
[Bug fortran/20587] gcc-4_0 from head does not build on Panther
--- Additional Comments From fca at mail dot cern dot ch 2005-03-23 15:08 --- Subject: Re: gcc-4_0 from head does not build on Panther Hello, this bug should be closed, it was my error and I apologise for that. I had the gnu intl lib in /usr/local/lib. Apparently configure was probing this one, finding the libintl_XXX entries. At link time it was the library in /sw/lib that was picked up. One may argue that there is some inconsistency in configure, but my system was a bit messy too. Best regards, Federico On Tue, 22 Mar 2005, Federico Carminati wrote: What kills the build is not the duplicate entry, but the fact that libintl_dgettext libintl_bindtextdomain are undefined. The reference is generated inside gcc, exactly in the file intl/libgnuintl.h at lines 142 and 265. On Mac gnu internationalisation routines are created without the libintl_ prefix. Somehow the configure should find this out and act correspondingly. Fed On Tue, 22 Mar 2005, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-22 16:40 --- Just remove the intl library, or set the DYLD_LIBRARY_PATH to include /sw/lib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20587
[Bug c++/20595] compilation gives garbage file instead of valid .o
-- What|Removed |Added CC||gcc-bugs at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20595
[Bug c++/20595] compilation gives garbage file instead of valid .o
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 15:12 --- (In reply to comment #1) it's related to the system i'm working with, gcc -S and then running as on it produced working files sorry for bothering you with this... This means it is your machine is haivng problems. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20595
[Bug c++/20599] variadic template support
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 15:13 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-23 15:13:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
[Bug target/8972] [arc-7-elf] the c code ' x i' causes infinite loop when i = 0
--- Additional Comments From saurabh dot verma at codito dot com 2005-03-23 15:24 --- Filed a patch on gcc-patches to fix this. When optimizations are enabled, the arc backend generates a single instruction loop for such code. The loop count register is checked only at the end of the loop for termination, and so starting with a zero loop count, we have spurious code. The patch (http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02171.html) fixes this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8972
[Bug tree-optimization/20501] gcc.dg/vect/vect-93.c fails on ia64-hpux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 15:53 --- Subject: Bug 20501 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-23 15:53:05 Modified files: gcc: ChangeLog tree-vect-analyze.c Log message: PR tree-optimization/20501 * tree-vect-analyze.c (vect_enhance_data_refs_alignment): Debug print reporting that peeling for alignment is applied moved to... * (vect_analyze_data_refs_alignment): Here. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7975r2=2.7976 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vect-analyze.c.diff?cvsroot=gccr1=2.13r2=2.14 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20501
[Bug c++/20133] [4.0/4.1 Regression] internal compiler error: in import_export_decl, at cp/decl2.c:1726
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-02-22 00:30:53 |2005-03-23 16:23:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20133
[Bug tree-optimization/20605] New: gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times iter 0 fails
gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times iter 0 has started failing on mainline between 20050321 and 20030323, on hppa64-hpux and ia64-hpux (-mlp64 only) but not on hppa2.0w-hpux or ia64-hpux -lilp32. Results on gcc-testresults also show it failing on ia64-linux. -- Summary: gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times iter 0 fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20605
[Bug tree-optimization/20605] gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times iter 0 fails
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-23 16:36 --- That should of course be 20050323 (not 20030323). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20605
[Bug c++/20513] [4.0/4.1 Regression] ICE when compiling with debug info and embedded using
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 16:46 --- Woops this is a dup of bug 19406. I had some how missed that for some reason. *** This bug has been marked as a duplicate of 19406 *** -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20513
[Bug debug/19406] [4.0/4.1 Regression] ICE: in force_decl_die, at dwarf2out.c:12442
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 16:46 --- *** Bug 20513 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||lenz at cs dot wisc dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19406
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 16:57 --- (In reply to comment #4) The workaround is trivial. But I'm still confused as to what exactly causes gcc to treat unnamed enums so much differently that named ones. It would be great if I could get some clarity on this. I have a handful of cases like this in the openoffice.org code base and OOo is reluctant to take the patches to fix unless sure it's currently invalid. Because the standard treats them differently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug target/20583] [4.0/4.1 regression] ICE in output_operand: invalid expression as operand
--- Additional Comments From dank at kegel dot com 2005-03-23 17:06 --- That's the same one I mentioned in http://gcc.gnu.org/ml/gcc/2005-03/msg00991.html I was going to report it, but you beat me to it, and you did a better job of minimizing the test case thank I did. Thanks! What does it take to confirm the bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug target/20583] [4.0/4.1 regression] ICE in output_operand: invalid expression as operand
-- What|Removed |Added CC||dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20583
[Bug tree-optimization/20601] [4.0/4.1 Regression] PRE related miscompilation
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 18:14 --- Subject: Bug 20601 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-23 18:14:13 Modified files: gcc: ChangeLog tree-ssa-pre.c Added files: gcc/testsuite/gcc.dg/tree-ssa: pr20601.c Log message: 2005-03-23 Daniel Berlin [EMAIL PROTECTED] Fix PR tree-optimization/20601 * tree-ssa-pre.c (insert_aux): Add missing condition to constification. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.80r2=2.7592.2.81 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.65r2=2.65.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr20601.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20601
[Bug tree-optimization/20601] [4.0/4.1 Regression] PRE related miscompilation
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 18:15 --- Subject: Bug 20601 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-23 18:14:52 Modified files: gcc: ChangeLog tree-ssa-pre.c Added files: gcc/testsuite/gcc.dg/tree-ssa: pr20601.c Log message: 2005-03-23 Daniel Berlin [EMAIL PROTECTED] Fix PR tree-optimization/20601 * tree-ssa-pre.c (insert_aux): Add missing condition to constification. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7977r2=2.7978 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gccr1=2.71r2=2.72 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr20601.c.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20601
[Bug tree-optimization/20601] [4.0/4.1 Regression] PRE related miscompilation
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-23 18:17 --- El fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20601
[Bug java/20606] New: ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
Toggling line 17 of the (soon to be) attached source file allows the compilation to proceed. Bryce can duplicate this error with his build from head. $ gcj --version gcj (GCC) 4.0.0 20050320 (Red Hat 4.0.0-0.35) $ wget http://people.redhat.com/~overholt/Main.java $ javac Main.java $ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o Main-noO2.so Main.class $ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -O2 -o Main-withO2.so Main.class Main.java: In class 'Main': Main.java: In method 'Main.buildLocation(java.lang.String,java.net.URL,java.lang.String)': Main.java:0: internal compiler error: in make_edges, at cfgbuild.c:327 -- Summary: ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: overholt at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug java/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
--- Additional Comments From overholt at redhat dot com 2005-03-23 18:25 --- Created an attachment (id=8435) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8435action=view) Test case Toggling the comment on line 17 affects things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|java|middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug java/20522] ICE in update_aliases, at java/decl.c:163
--- Additional Comments From aph at gcc dot gnu dot org 2005-03-23 18:46 --- . -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20522
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
-- What|Removed |Added Attachment #8435|application/octet-stream|text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From bangerth at dealii dot org 2005-03-23 18:53 --- Intuitively, C++ treats unnamed enums differently than named ones, because in templates the function/class name has to be mangled, and will contain the name of the template arguments. If the template argument doesn't have a name, then the compiler can't do its job, so the standard chose to disallow unnamed enums as template arguments. For more legalese, this is specified in section 14.3.1/2 of the standard, which says: 2 A local type, a type with no linkage, an unnamed type or a type compounded from any of these types shall not be used as a template- argument for a template type-parameter. [Example: ... Regards Wolfgang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
-- What|Removed |Added GCC target triplet||x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug c++/20607] New: -fstrict-aliasing causes incorrect scheduling on Sparc Solaris
On Sparc Solaris, the attached code leads to the following assembly sequence being produced at the beginning of a function. Stack slot %fp-32 is read before it is written. Turning off either -fstrict-aliasing or -fsched-insns causes the problem to go away. I'm relying on the GCC extension that allows type punning via unions, and assuming a big endian layout of all the datatypes. As specified by the -fstrict-aliasing documentation, I'm copying the value out of the union rather than taking an address of a union member. 0: 9d e3 bf 80 save %sp, -128, %sp 4: d6 07 bf e4 ld [ %fp + -28 ], %o3 8: c2 07 bf e0 ld [ %fp + -32 ], %g1 c: c2 27 bf e8 st %g1, [ %fp + -24 ] 10: 19 00 00 20 sethi %hi(0x8000), %o4 14: 1b 3f ff ff sethi %hi(0xfc00), %o5 18: 9a 13 63 ff or %o5, 0x3ff, %o5 ! main+0xffa3 1c: d8 3f bf e0 std %o4, [ %fp + -32 ] g++-3_4_3 -v -save-temps -O1 -c -o u64solrs.o u64solrs.c -fschedule-insns -fstrict-aliasing Reading specs from /arm/eda/tools/gnu/gcc/3_4_3/solaris_2_9-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.3/specs Configured with: ./configure --prefix=/arm/eda/tools/gnu/gcc/3_4_3 --exec-prefix=/arm/eda/tools/gnu/gcc/3_4_3/solaris_2_9-sparc --program-suffix=-3_4_3 --enable-languages=c,c++ -v --with-dwarf2 --enable-version-specific-runtime-libs --with-gnu-as --with-as=/arm/eda/tools/gnu/binutils/2_15/solaris_2_9-sparc/bin/as-2_15 --with-gnu-ld --with-ld=/arm/eda/tools/gnu/binutils/2_15/solaris_2_9-sparc/bin/ld-2_15 Thread model: posix gcc version 3.4.3 /arm/eda/tools/gnu/gcc/3_4_3/solaris_2_9-sparc/libexec/gcc/sparc-sun-solaris2.9/3.4.3/cc1plus -E -quiet -v u64solrs.c -mcpu=v7 -fschedule-insns -fstrict-aliasing -O1 -o u64solrs.ii ignoring nonexistent directory /arm/eda/tools/gnu/gcc/3_4_3/solaris_2_9-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.3/../../../../sparc-sun-solaris2.9/include #include ... search starts here: #include ... search starts here: /arm/eda/tools/gnu/gcc/3_4_3/solaris_2_9-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.3/include/c++ /arm/eda/tools/gnu/gcc/3_4_3/solaris_2_9-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.3/include/c++/sparc-sun-solaris2.9 /arm/eda/tools/gnu/gcc/3_4_3/solaris_2_9-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.3/include/c++/backward /usr/local/include /arm/eda/tools/gnu/gcc/3_4_3/include /arm/eda/tools/gnu/gcc/3_4_3/solaris_2_9-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.3/include /usr/include End of search list. /arm/eda/tools/gnu/gcc/3_4_3/solaris_2_9-sparc/libexec/gcc/sparc-sun-solaris2.9/3.4.3/cc1plus -fpreprocessed u64solrs.ii -quiet -dumpbase u64solrs.c -mcpu=v7 -auxbase-strip u64solrs.o -O1 -version -fschedule-insns -fstrict-aliasing -o u64solrs.s GNU C++ version 3.4.3 (sparc-sun-solaris2.9) compiled by GNU C version 3.4.3. GGC heuristics: --param ggc-min-expand=65 --param ggc-min-heapsize=65536 /arm/eda/tools/gnu/binutils/2_15/solaris_2_9-sparc/bin/as-2_15 -V -Qy -s -xarch=v8 -o u64solrs.o u64solrs.s GNU assembler version 2.15 (sparc-sun-solaris2.9) using BFD version 2.15 -- Summary: -fstrict-aliasing causes incorrect scheduling on Sparc Solaris Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ganesh dot Sittampalam at arm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20607
[Bug c++/20607] -fstrict-aliasing causes incorrect scheduling on Sparc Solaris
--- Additional Comments From Ganesh dot Sittampalam at arm dot com 2005-03-23 19:04 --- Created an attachment (id=8436) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8436action=view) Source code for bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20607
[Bug c++/20607] -fstrict-aliasing causes incorrect scheduling on Sparc Solaris
--- Additional Comments From Ganesh dot Sittampalam at arm dot com 2005-03-23 19:05 --- Created an attachment (id=8437) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8437action=view) gcc -v -save-temps output for bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20607
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From caolanm at redhat dot com 2005-03-23 19:12 --- Sounds reasonable, but it's not the case that the compiler should just silently not consider anonymous enums as candidates for template argument matching ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From bangerth at dealii dot org 2005-03-23 19:24 --- That has been subject to discussion (i.e. whether the attempt to use an unnamed enum as a template argument should just silently fail as a substitution failure). However, it has been decided that this is a hard error, not only a substitution failure. I am presently not quite sure about the reasoning, and I believe that there was a DR or something still pending. Mark, do you remember the details? I think this came up in a different PR before... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From mark at codesourcery dot com 2005-03-23 19:28 --- Subject: Re: error: 'anonymous enum' is/uses anonymous type' bangerth at dealii dot org wrote: --- Additional Comments From bangerth at dealii dot org 2005-03-23 19:24 --- That has been subject to discussion (i.e. whether the attempt to use an unnamed enum as a template argument should just silently fail as a substitution failure). However, it has been decided that this is a hard error, not only a substitution failure. I am presently not quite sure about the reasoning, and I believe that there was a DR or something still pending. Mark, do you remember the details? I think this came up in a different PR before... It's swapped out of my brain, but there was another PR, and I did raise the issue for Steve Adamczyk, to be added to the core issue list. The basic point is that the SFINAE rules simply do not cover this case; they precisely describe a set of situations in which no error should be issued, and trying to use an anonymous type as a template parameter is not among them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23
19:29 ---
Hmm, we are dying because of the following instruction:
(jump_insn 169 168 170 19 (set (pc)
(reg/f:DI 66 [ #ref#6#19 ])) 515 {*indirect_jump_rtx64} (nil)
(expr_list:REG_DEAD (reg/f:DI 66 [ #ref#6#19 ])
(nil)))
But that does not make sense since this is a computed goto.
Why is computed_jump_p (insn) not returning true?
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-03-23 19:29:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23
19:38 ---
(In reply to comment #2)
Why is computed_jump_p (insn) not returning true?
Actually it is the following insn:
(jump_insn 169 222 170 19 (set (pc)
(reg:DI 0 ax)) 515 {*indirect_jump_rtx64} (nil)
(insn_list:REG_LABEL 172 (nil)))
Which is a computed goto but at this point we have a REG_LABEL which causes
computed_jump_p to
return false.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23
19:46 ---
Hmm, I think this is a reload or a recognizing problem.
inside reload (when adding the LABEL_REG), we have the following instruction:
(jump_insn 169 222 170 19 (set (pc)
(label_ref:DI 172)) 515 {*indirect_jump_rtx64} (nil)
(expr_list:REG_DEAD (reg/f:DI 66 [ #ref#6#19 ])
(nil)))
But this is not an indirect_jump_rtx64 at this point but instead just a jump.
I cannot debug it further than this sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug tree-optimization/19659] GCC does not remove an if statement that never triggers.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 19:59 --- Hmm, the example in comment #3 is fixed on the mainline but the orginal one is just as bad when removing const now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19659
[Bug tree-optimization/17141] *a-b is not folded
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23
20:10 ---
And here is a testcase for a missed optimization on the TREE level:
void abort (void);
struct a
{
int i;
} *a;
int f(void)
{
int *ii = a-i;
void *l;
a-i = 1;
if (*ii)
l = l1;
else
l = l2;
goto *l;
l1:
return 0;
l2:
abort ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17141
[Bug regression/20608] New: regression - Bus Error - union of structures
/*
% gcc-3.4.3 -m64 -o foo foo.c
% foo
0
here
0
%
% gcc-4.0 -m64 -o foo foo.c
% foo
0
here
Bus Error (core dumped)
%
% uname -a
SunOS portia 5.8 Generic_117350-18 sun4u sparc SUNW,Sun-Blade-100
%
% gcc-4.0 -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /home/kate/gcc-4.0-20050319/src/gcc-4.0-20050319/configure
--enable-languages=c --prefix=/home/kate/gcc-4.0-20050319/sparc-SunOS
Thread model: posix
gcc version 4.0.0 20050319 (prerelease)
%
% gcc-3.4.3 -v
Reading specs from
/usr/local/gcc-3.4.3/sparc-SunOS/lib/gcc/sparc-sun-solaris2.8/3.4.3/specs
Configured with: /usr/local/gcc-3.4.3/src/gcc-3.4.3/configure
--enable-languages=c --prefix=/usr/local/gcc-3.4.3/sparc-SunOS
Thread model: posix
gcc version 3.4.3
%
*/
#include stdio.h
typedef struct
{
int a;
int b;
int c;
} t_m;
typedef struct
{
int *f;
} t_g;
typedef union
{
t_m m;
t_g g;
} t_u;
void bar(t_u *u)
{
printf(here\n);
printf(%lx\n, *u);
}
main()
{
t_m u;
printf(%lx\n, u);
bar( (t_u *)u );
}
--
Summary: regression - Bus Error - union of structures
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kminola at eng dot umd dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20608
[Bug target/20608] regression - Bus Error - union of structures
-- What|Removed |Added Component|regression |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20608
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 20:30 --- We are missing some jump threading opertinutes on the tree level: prephitmp.107 = 0B; goto bb 16 (*.LJpc=79); . *.LJpc=79:; if (prephitmp.107 == 0B) goto *.LJpc=99; else goto L13; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug c/20609] New: install-sh not found
I keep getting a install-sh not found when trying to install gcc on a Solaris 9 box. The problem is when there is no compatible BSD install program in the current path, configure defaults to using install-sh supplied in the top level dir of the src. However either configure or the Makefile it generates is not setting the relative path to install-sh in the Makefiles of the subdirectories. The work around is to either install a BSD compatible install program like ginstall and make sure the binary is in your current path. Or to uncompress the gcc source, run configure as normal, then edit the top level Makefile and set INSTALL to the absolute path of install-sh. -- Summary: install-sh not found Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hip at cs dot okstate dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20609
[Bug c/20609] install-sh not found
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 20:35 --- or configure with an relative path. Anyways this is fixed in 3.4.4. This is a dup of bug 13993. *** This bug has been marked as a duplicate of 13993 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20609
[Bug bootstrap/13993] [3.4 Regression] Relative path as srcdir causes problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 20:35 --- *** Bug 20609 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||hip at cs dot okstate dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13993
[Bug java/20526] gij -X reports no options are recognized, while -Xmx and -Xms seem to be
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23 20:51 --- FWIW, we do support -ms and -mx, but not -Xms and -Xmx. Those are just ignored. However, we ought to recognize those. I'm leaving the PR open for now, for that reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20526
[Bug middle-end/20610] New: Real by complex multiplications perform unnecessary operations
When doing real by complex multiplications in C++ using std::complexdouble,
the multiplication is transformed to a complex by complex multiplication, even
though the imaginary part is zero for one of the arguments.
This is similar to TR 19953, however there is still a problem even though it is
supposed to be fixed.
Here is a small test program:
#include complex
std::complexdouble a, b;
double c;
void f()
{
a = b * c;
}
When compiled with g++ -O3 -march=pentium4 -mfpmath=sse -S -c test.C, the
following is produced (from test.s):
_Z1fv:
.LFB1857:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
movsd b+8, %xmm3
movsd b, %xmm2
movsd c, %xmm4
pxor %xmm5, %xmm5
movapd %xmm2, %xmm0
mulsd %xmm5, %xmm0
movapd %xmm4, %xmm1
mulsd %xmm3, %xmm1
addsd %xmm1, %xmm0
movsd %xmm0, a+8
mulsd %xmm4, %xmm2
mulsd %xmm5, %xmm3
subsd %xmm3, %xmm2
movsd %xmm2, a
popl %ebp
ret
I.e, the real value c is still converted to a complex value and a full
multiplication is done.
I'm using the following version of gcc:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0-20050312/configure --prefix=/home/fredrik/gcc
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.0 20050312 (prerelease)
--
Summary: Real by complex multiplications perform unnecessary
operations
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fredrik dot huss at home dot se
CC: gcc-bugs at gcc dot gnu 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=20610
[Bug middle-end/20610] Real by complex multiplications perform unnecessary operations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 21:11 --- Because C99 is different from C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20610
[Bug libgcj/18083] Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add().
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:26 --- Subject: Bug 18083 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-23 21:26:00 Modified files: libjava: ChangeLog libjava/java/text: SimpleDateFormat.java libjava/java/util: Calendar.java GregorianCalendar.java Log message: 2005-03-23 Sven de Marothy [EMAIL PROTECTED] PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3431r2=1.3432 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gccr1=1.32r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gccr1=1.27r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gccr1=1.26r2=1.27 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18083
[Bug libgcj/14892] Issues with TimerTask/Calendar
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:26 --- Subject: Bug 14892 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-23 21:26:00 Modified files: libjava: ChangeLog libjava/java/text: SimpleDateFormat.java libjava/java/util: Calendar.java GregorianCalendar.java Log message: 2005-03-23 Sven de Marothy [EMAIL PROTECTED] PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3431r2=1.3432 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gccr1=1.32r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gccr1=1.27r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gccr1=1.26r2=1.27 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14892
[Bug libgcj/9854] GregorianCalendar does not validate months correctly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:26 --- Subject: Bug 9854 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-23 21:26:00 Modified files: libjava: ChangeLog libjava/java/text: SimpleDateFormat.java libjava/java/util: Calendar.java GregorianCalendar.java Log message: 2005-03-23 Sven de Marothy [EMAIL PROTECTED] PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3431r2=1.3432 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gccr1=1.32r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gccr1=1.27r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gccr1=1.26r2=1.27 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9854
[Bug libgcj/2641] Calendar and GregorianCalendar have serious problems
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:26 --- Subject: Bug 2641 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-23 21:26:00 Modified files: libjava: ChangeLog libjava/java/text: SimpleDateFormat.java libjava/java/util: Calendar.java GregorianCalendar.java Log message: 2005-03-23 Sven de Marothy [EMAIL PROTECTED] PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3431r2=1.3432 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gccr1=1.32r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gccr1=1.27r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gccr1=1.26r2=1.27 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2641
[Bug libgcj/11085] SimpleDateFormat fails to parse valid dates
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:26 --- Subject: Bug 11085 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-23 21:26:00 Modified files: libjava: ChangeLog libjava/java/text: SimpleDateFormat.java libjava/java/util: Calendar.java GregorianCalendar.java Log message: 2005-03-23 Sven de Marothy [EMAIL PROTECTED] PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3431r2=1.3432 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gccr1=1.32r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gccr1=1.27r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gccr1=1.26r2=1.27 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11085
[Bug libgcj/9854] GregorianCalendar does not validate months correctly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:36 --- Subject: Bug 9854 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-23 21:36:25 Modified files: libjava: ChangeLog libjava/java/util: Calendar.java GregorianCalendar.java libjava/java/text: SimpleDateFormat.java Log message: 2005-03-23 Sven de Marothy [EMAIL PROTECTED] PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.22r2=1.3391.2.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.27r2=1.27.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.26r2=1.26.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.32r2=1.32.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9854
[Bug libgcj/2641] Calendar and GregorianCalendar have serious problems
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:36 --- Subject: Bug 2641 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-23 21:36:25 Modified files: libjava: ChangeLog libjava/java/util: Calendar.java GregorianCalendar.java libjava/java/text: SimpleDateFormat.java Log message: 2005-03-23 Sven de Marothy [EMAIL PROTECTED] PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.22r2=1.3391.2.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.27r2=1.27.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.26r2=1.26.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.32r2=1.32.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2641
[Bug libgcj/18083] Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add().
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:36 --- Subject: Bug 18083 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-23 21:36:25 Modified files: libjava: ChangeLog libjava/java/util: Calendar.java GregorianCalendar.java libjava/java/text: SimpleDateFormat.java Log message: 2005-03-23 Sven de Marothy [EMAIL PROTECTED] PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.22r2=1.3391.2.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.27r2=1.27.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.26r2=1.26.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.32r2=1.32.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18083
[Bug libgcj/11085] SimpleDateFormat fails to parse valid dates
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:36 --- Subject: Bug 11085 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-23 21:36:25 Modified files: libjava: ChangeLog libjava/java/util: Calendar.java GregorianCalendar.java libjava/java/text: SimpleDateFormat.java Log message: 2005-03-23 Sven de Marothy [EMAIL PROTECTED] PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.22r2=1.3391.2.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.27r2=1.27.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.26r2=1.26.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.32r2=1.32.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11085
[Bug libgcj/14892] Issues with TimerTask/Calendar
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:36 --- Subject: Bug 14892 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-23 21:36:25 Modified files: libjava: ChangeLog libjava/java/util: Calendar.java GregorianCalendar.java libjava/java/text: SimpleDateFormat.java Log message: 2005-03-23 Sven de Marothy [EMAIL PROTECTED] PR libgcj/2641, PR libgcj/9854, PR libgcj/14892, PR libgcj/18083, PR libgcj/11085: * java/util/Calendar.java (set): Use starting day of week when one is needed if none is given. * java/text/SimpleDateFormat.java (parse): Handle 1-12 and 1-24 timestamps correctly. * java/util/GregorianCalendar.java (computeTime, computeFields): HOUR should be in 0-11 format. (nonLeniencyCheck): Adjust leniency checking to that fact. (getLinearDay): Should be private. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.22r2=1.3391.2.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/Calendar.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.27r2=1.27.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/GregorianCalendar.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.26r2=1.26.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/SimpleDateFormat.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.32r2=1.32.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14892
[Bug libgcj/2641] Calendar and GregorianCalendar have serious problems
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23 21:37 --- Fix checked in. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2641
[Bug libgcj/14892] Issues with TimerTask/Calendar
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23 21:37 --- Fix checked in. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14892
[Bug libgcj/18083] Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add().
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23 21:38 --- Fix checked in. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18083
[Bug libgcj/11085] SimpleDateFormat fails to parse valid dates
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23 21:38 --- Fix checked in. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11085
[Bug libgcj/9854] GregorianCalendar does not validate months correctly
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23 21:39 --- Fix checked in. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9854
[Bug libfortran/18025] libgfortran: format, incompatible minimum width edit descriptor
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:42 --- Subject: Bug 18025 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-23 21:42:11 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : write.c Added files: gcc/testsuite/gfortran.dg: pr18025.f90 Log message: PR libfortran/18025 * write.c (output_float): Handling the F0.d format similarly as commercial compilers. * pr18025.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5204r2=1.5205 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr18025.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.173r2=1.174 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gccr1=1.28r2=1.29 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18025
[Bug libfortran/18025] libgfortran: format, incompatible minimum width edit descriptor
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-23 21:46 --- Subject: Bug 18025 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-23 21:46:01 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : write.c Added files: gcc/testsuite/gfortran.dg: pr18025.f90 Log message: PR libfortran/18025 * write.c (output_float): Handling the F0.d format similarly as commercial compilers. * pr18025.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.65r2=1.5084.2.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr18025.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.7r2=1.163.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.23.2.4r2=1.23.2.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18025
[Bug c++/20607] -fstrict-aliasing causes incorrect scheduling on Sparc Solaris
-- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20607
[Bug target/20608] Bus Error - union of structures
-- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Summary|regression - Bus Error -|Bus Error - union of |union of structures |structures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20608
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From bangerth at dealii dot org 2005-03-23 21:56 --- Related PRs are: PR 19404, and in particular PR 17413. The latter is the one I was thinking of. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
gcc and as bug
I have encountered what seems to be an error of unforgiving nature when
attempting to compile a device driver for the parallel port. I also
attempted to compile the example given in Riku Saikkonen's HOW TO on I/O
port programming using options 0-6 with the same result.
The error is centered on the use of inb and outb (macros I understand)
in my C program (and Saikkonen's). When removed it compiles.
The error is: Error: suffix or operands invalid for 'in' { also for 'out'}.
My configuration is: glibc=2.3.2, gcc=3.2.3, as=2.14.90.0.6 20030820,
kernel 2.4.22, vendor Slackware 9.1, motherboard=KT4V-L, CPU=AMD 2200+,
circa 1.8GHz, FSB=133 MHz.
If you could point me to the resolution, as I am sure I am not the
first, I would appreciate it as this has been ongoing for 10 days now
and are not able to find a
solution on the web.
Thanks,
Ron Riese [EMAIL PROTECTED]
[Bug libfortran/18025] libgfortran: format, incompatible minimum width edit descriptor
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-03-23 22:18 --- Fixed on both 4.0 and mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18025
[Bug libfortran/18025] libgfortran: format, incompatible minimum width edit descriptor
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18025
[Bug libfortran/20236] runtime error reading float
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-03-23 22:58 --- Using testcase from comment #2, I don't get a runtime error but the program hangs out forever: Program received signal SIGINT, Interrupt. 0x0806b971 in memset () Current language: auto; currently asm (gdb) where #0 0x0806b971 in memset () #1 0x08048ba1 in *_gfortrani_read_block (length=0xb7a4) at ../../../gcc/libgfortran/io/transfer.c:153 #2 0x080529b8 in *_gfortrani_read_x (f=0x0) at ../../../gcc/libgfortran/io/read.c:726 #3 0x08049b72 in formatted_transfer (type=BT_CHARACTER, p=0xb8e4, len=16) at ../../../gcc/libgfortran/io/transfer.c:684 #4 0x08048f77 in *_gfortran_transfer_character (p=0xb8d4, len=16) at ../../../gcc/libgfortran/io/transfer.c:820 #5 0x080482e9 in MAIN__ () #6 0x080483b8 in main (argc=1, argv=0xbb54) at ../../../gcc/libgfortran/fmain.c:18 This behavior is, I think, due to the T edit descriptor. From what I have seen, T and TL descriptors are incorrectly handled in library (see PR16436). -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2005-02-27 18:41:12 |2005-03-23 22:58:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20236
[Bug target/20611] New: duplicate label for inlined function referencing TLS
PAPI fails to build on powerpc-linux with -O3 -fPIC due to multiple symbols of the same name in assembler output. The minimized test case demonstrates the problem. The failure occurs on the 3.4 branch (the FSF version in which TLS is first supported for powerpc-linux) and on the hammer-3.3 and 3.4-rhl branches, but not on mainline or the 4.0 branch. There is not a problem with 64-bit compilation. I'll run a regression hunt to determine when the fix was added and hope that it's something smaller than the tree-ssa merge. -- Summary: duplicate label for inlined function referencing TLS Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug target/20611] duplicate label for inlined function referencing TLS
--- Additional Comments From janis at gcc dot gnu dot org 2005-03-23 23:08 --- Created an attachment (id=8438) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8438action=view) minimized test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug target/20611] duplicate label for inlined function referencing TLS
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug rtl-optimization/20600] [4.1 regression] failure for pass.c on x86_64-pc-linux-gnu
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-23 23:29:29 date|| Summary|failure for pass.c on |[4.1 regression] failure for |x86_64-pc-linux-gnu |pass.c on x86_64-pc-linux- ||gnu Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20600
[Bug target/20611] duplicate label for inlined function referencing TLS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 23:44 --- .LTLS0: Confirmed, I really doubt it was fixed by the tree-ssa merge. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-23 23:45:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug target/20611] duplicate label for inlined function referencing TLS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-23 23:46 --- Though the code which generates the label is the same so it might be the tree-ssa merge after all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug target/20286] [3.3 only] gcc panic with __thread attribute
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-24 00:09 --- That patch that fixed this in gcc-3.4 is too large to backport, particularly when considering that it depends on other stuff (such as default_encode_section_info) which is not already present in gcc-3.3. However, it can be fixed with a simpler patch. The underlying problem is that a variable changes state from TLS_MODEL_INTIAL_EXEC (extern) to TLS_MODEL_LOCAL_EXEC (static). This is an allowable transition. This unfortunately triggers an abort in the ia64.c backend in ia64_encode_section_info. The comment next to the abort makes it clear that this is checking for transitions between thread data and small data. So the fix is to tighten the conditions under which we call the abort to match the conditions documented in the comments. The same INITIAL_EXEC to LOCAL_EXEC transition happens in gcc-3.4, there just isn't a corresponding abort in default_encode_section_info. Technically, this isn't a regression, as gcc-3.2 did not have TLS support, and gcc-3.3 is only open for regression fixes, so there is the question of whether this patch is OK to install on the branch. A strict interpretation of the rules says this is not OK, at least not without approval of the branch maintainer, Gaby. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-02 16:48:16 |2005-03-24 00:09:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20286
[Bug middle-end/20610] Real by complex multiplications perform unnecessary operations
--- Additional Comments From pcarlini at suse dot de 2005-03-24 00:19 --- But, isn't 19953 about -ffast-math? Or you really want the same code *without* that switch?!? We are talking about completely different issues, IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20610
[Bug target/20611] duplicate label for inlined function referencing TLS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-24 00:23 --- Ok, what is happening here is we are committing too early to a label name. There should be an easy way of fixing this. Note the problem shows up in .31.bbro which duplicates the BBs. This must likely can be shown still on the mainline/4.0 branch but it is harder to find an example where we do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
