--- Comment #5 from rakdver at gcc dot gnu dot org 2006-02-13 00:02 ---
Subject: Bug 26225
Author: rakdver
Date: Mon Feb 13 00:02:37 2006
New Revision: 110898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110898
Log:
PR rtl-optimization/26225
* loop-invariant.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-13 00:13 ---
495 /* TODO: Don't set sym->module for result or dummy variables. */
496 gcc_assert (current_function_decl == NULL_TREE || sym->result ==
sym);
497 /* This is the declaration of a modul
Same setup as with 26232, but with the patch applied.
Another bug exposed with -fmove-loop-invariants. This time
it's strict_low_part that isn't handled. Looks like gen_move_insn
is insufficient. Or just punt on a dest that's strict_low_part
just like on cc0 setters.
Running /home/hp/combined/c
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-13 00:22 ---
We are passing the wrong symbol to gfc_finish_var_decl, we are passing the
symbol for the function and not the result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26246
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-13 00:24 ---
This is in gfc_get_fake_result_decl.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26246
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-13 00:33 ---
110653 jakub if (TREE_CODE (length) == VAR_DECL
110653 jakub && DECL_CONTEXT (length) == NULL_TREE)
110653 jakub gfc_finish_var_decl (length, sym);
--
http://gcc.gnu.org/bugzil
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-13
00:37 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c
execution, -O3 -fomit-frame-po
> > Just for sure -- does not the patch for PR 26235 fix this?
>
> I'll know in a few minutes.
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-02-13 00:41 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c
execution, -O3 -fomit-frame-pointer -funroll-loops
> > > Just for sure -- does not the patch for PR 26235 fix this
Building sh-elf with 110879 fails:
make[8]: Entering directory
`/home/hp/combined/sh-sim/sh-elf/m2a/newlib/libc/misc'
/home/hp/combined/sh-sim/./gcc/xgcc -B/home/hp/combined/sh-sim/./gcc/ -nostdinc
-B/home/hp/combined/sh-sim/sh-elf/m2a/newlib/ -is\
ystem /home/hp/combined/sh-sim/sh-elf/m2a/newlib/t
--- Comment #1 from hp at gcc dot gnu dot org 2006-02-13 01:15 ---
Created an attachment (id=10833)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10833&action=view)
hah
Exposes the bug when compiled with ./cc1 -fpreprocessed dprintf.i -quiet
-dumpbase dprintf.c -m2a -m2a -auxbase
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-13 01:19 ---
Confirmed.
here is the patch which fixes this testcase for me:
Index: trans-decl.c
===
--- trans-decl.c(revision 110867)
+++ trans-decl.c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-13 01:30 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #1 from rakdver at gcc dot gnu dot org 2006-02-13 01:32 ---
This should fix the problem:
Index: loop-invariant.c
===
*** loop-invariant.c(revision 110898)
--- loop-invariant.c(working copy)
*
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-02-13 01:34 ---
The patch for PR26247 should fix this one as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26248
On an up to date Fedora Core 4 system, with the latest update from svn today
cc1 --help segfaults.
The configure conmmand line was:
../gcc/configure --enable-languages=c --disable-checking --disable-nls
--enable-gather-detailed-mem-stats --prefix=${HOME}/build/gcc-HEAD
A gdb session:
Starting p
--- Comment #2 from hp at gcc dot gnu dot org 2006-02-13 01:47 ---
Thanks. Will test within days: machines are busy right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26247
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 01:48 ---
This is a dup of bug 25636, opts.c is being miscompiled.
*** This bug has been marked as a duplicate of 25636 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #31 from pinskia at gcc dot gnu dot org 2006-02-13 01:48
---
*** Bug 26249 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-13
01:52 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c
execution, -O3 -fomit-frame-pointe
> and adding -fno-move-loop-invariants? I have looked at the dump
> from crosscompiler, but
--- Comment #8 from sayle at gcc dot gnu dot org 2006-02-13 01:55 ---
Subject: Bug 25724
Author: sayle
Date: Mon Feb 13 01:55:37 2006
New Revision: 110906
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110906
Log:
PR middle-end/25724
* dojump.c (do_jump): Call d
Compiling the function below with -Os -march=i686 -mtune=pentiumpro
generates bigger code for 4.2 than for 4.0.
The reason seems to be that 4.2 peels off one loop iteration.
typedef unsigned Tabs [10];
void
TabZonk(Tabs tabs)
{
int i;
for (i = 0; i < 10; ++i)
tabs[i] = 0;
}
sdiff gcc-
AFAICT, the program below should run successfully to completion.
$ cat -n u.cpp && g++ u.cpp -static && ./a.out
1 #include
2 #include
3
4 struct pubbuf: std::stringbuf {
5 using std::stringbuf::eback;
6 using std::stringbuf::egptr;
7 using s
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 02:16 ---
Confirmed, this happens in the last VRP pass.
Mainly:
Threaded jump 2 --> 3 to 6
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-13 02:19 ---
This might be the reason for the slight code size increase with CSiBE:
http://www.inf.u-szeged.hu/csibe/l-sbs.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish
between the 7th a
Executing on host: /users/bin/gcc/gcc-4.1/objdir/gcc/testsuite/../gfortran
-B/us
ers/bin/gcc/gcc-4.1/objdir/gcc/testsuite/../
/users/bin/gcc/gcc-4.1/gcc/gcc/test
suite/gfortran.fortran-torture/execute/nan_inf_fmt.f90 -w -O0
-L/users/bin/g
cc/gcc-4.1/objdir/hppa1.1-hp-hpux10.20/./libgfortran/.li
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-13 02:28 ---
The difference in IV selection causes this bug to show up.
on Powerpc if I use -fno-ivopts, I can reproduce this jump threading.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26251
--- Comment #6 from sayle at gcc dot gnu dot org 2006-02-13 02:33 ---
Subject: Bug 25936
Author: sayle
Date: Mon Feb 13 02:33:37 2006
New Revision: 110908
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110908
Log:
2006-02-12 Roger Sayle <[EMAIL PROTECTED]>
John Dav
--- Comment #4 from dann at godzilla dot ics dot uci dot edu 2006-02-13
02:34 ---
Here's another testcase of what seems to be the same problem.
The 4.2 assembly contains 2 calls for TabSet, 4.0 only has 1.
(both this and the first example are function from xterm in case anybody
wonders
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #9 from patchapp at dberlin dot org 2006-02-13 03:30 ---
Subject: Bug number PR25631
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/2006-01/msg00439.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #10 from dberlin at gcc dot gnu dot org 2006-02-13 03:33
---
(In reply to comment #9)
> Subject: Bug number PR25631
>
> 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/2006-01/msg00439.htm
Executing on host: /users/bin/gcc/gcc-4.1/objdir/gcc/testsuite/../gfortran
-B/us
ers/bin/gcc/gcc-4.1/objdir/gcc/testsuite/../
/users/bin/gcc/gcc-4.1/gcc/gcc/test
suite/gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 -w -O0
-L/
users/bin/gcc/gcc-4.1/objdir/hppa1.1-hp-hpux10.20/./libg
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 03:43 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from hp at gcc dot gnu dot org 2006-02-13 04:04 ---
I haven't tested it myself, but I think Zack's fixed this one in one of his
2006-01-22 Zack Weinberg <[EMAIL PROTECTED]>
commits. I'll try and see if it works (timeline deliberately left out).
--
http://gcc.gnu.or
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 04:08 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 04:35 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-13 04:37 ---
The error message now is totally bogus:
t.cc: In function 'int main()':
t.cc:13: error: reference to 'foo' is ambiguous
t.cc:2: error: candidates are: class foo
t.cc:6: error: typedef class foo bar::f
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-13 04:40 ---
Isn't this fixed now or just worked around?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21317
On sh4-*-linux-gnu, gcc.c-torture/compile/20011109-1.c with -O1
starts to fail:
testsuite/gcc.c-torture/compile/20011109-1.c:51: error: unrecognizable insn:
(insn 26 25 232 4 (parallel [
(set (reg:SI 248)
(gt:SI (reg:DF 246)
(reg:DF 247)))
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-13 04:56 ---
Could you try the patch referenced in PR 26222?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26254
Ref: http://bugs.debian.org/352529
The attached testcase, reduced from the Debian BTS bug report, causes an ICE
bug.c: In function 'foo':
bug.c:31: error: insn does not satisfy its constraints:
(insn 156 35 37 0 (set (reg:HI 70 %fr23 [122])
(reg:HI 20 %r20)) 53 {*pa.md:2926} (nil)
(ni
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-13 05:00 ---
So it was fixed:
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00637.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26255
--- Comment #1 from tausq at debian dot org 2006-02-13 05:13 ---
I forgot to mention that this bug does not happen with the 20060104 snapshot of
gcc-4.0_branch (Debian 4.0.2-6), only with 20060128 (Debian 4.0.2-8)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26255
--- Comment #2 from kkojima at gcc dot gnu dot org 2006-02-13 05:14 ---
This case still fails with it.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Ta
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-13 05:18 ---
During that time there was a couple of HPPA patches:
2006-01-16 John David Anglin <[EMAIL PROTECTED]>
* pa.md: Disparage copies between general and floating-point registers
in 32-bit move patterns.
The code:
struct A {int* next; };
struct B {int* next; };
struct C : public A, public B { using A::next; };
void foo(C* c) { c->next = 0; }
gets you:
~/ootbc/sim$ g++ foo.cc
foo.cc: In function `void foo(C*)':
foo.cc:4: error: request for member `next' is ambiguous
foo.cc:2: error: candidates are:
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to f
Hi Guys,
There appears to be a discrepancy in the way that G++ orders its
static destructors. Given this test program:
#include
using namespace std;
class A
{
public:
int i;
A(int j) : i(j) { cout << "constructor A" << endl; }
~A() { cout << "destructor A : i = " << i << e
101 - 153 of 153 matches
Mail list logo
