--- Comment #1 from doko at ubuntu dot com 2008-10-13 05:13 ---
seen as well with a powerpc biarch compiler, defaulting to powerpc-linux-gnu.
reverting this patch lets the build continue, but fails later with:
/build/buildd/gcc-snapshot-20081012/build/./prev-gcc/xgcc
-B/build/buildd
seen with r141079 on the trunk, not with r141071
/build/buildd/gcc-snapshot-20081012/build/./gcc/xgcc
-B/build/buildd/gcc-snapshot-20081012/build/./gcc/
-B/usr/lib/gcc-snapshot/sparc-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/sparc-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/sparc-linux-gnu/include
Compile the below (cut-down) testcase with:
m68k-elf-gcc -c fptest.c -mcpu=5282 -fomit-frame-pointer -O
(gcc 4.3.2) and you will get:
-=-=-=-=-=-
fptest.c: In function do_test:
fptest.c:21: error: insn does not satisfy its constraints:
(insn 31 114 32 2 fptest.c:11 (set (reg:SI 8 %a0 [62])
--- Comment #1 from hp at gcc dot gnu dot org 2008-10-13 00:16 ---
Created an attachment (id=16487)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16487&action=view)
Preprocessed and reduced test-case
- Configure with --target=crisv32-axis-elf --enable-languages=c (the latter
optio
With the IRA_COVER_CLASSES in cris.h changed as follows (exposing one of the
GENERAL_REGS that has special properties as a singleton class), build fails
compiling libgcc:
/home/hp/combw/crisv32-obj/./gcc/xgcc -B/home/hp/combw/crisv32-obj/./gcc/
-nostdinc -B/home/hp/combw/crisv32-obj/crisv32-elf/ne
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-10-12 23:27
---
Patch submitted for approval:
http://gcc.gnu.org/ml/fortran/2008-10/msg00098.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37083
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-10-12 23:08
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-12 23:05 ---
Basically Apple's as does not have support for this instruction, I could use
.long if really needed for this test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
Since revision 140892 (r140513 works) the following tests fail in both 32 and
64 bit modes:
FAIL: gcc.target/powerpc/altivec-1.c (test for excess errors)
WARNING: gcc.target/powerpc/altivec-1.c compilation failed to produce
executable
FAIL: gcc.target/powerpc/altivec-12.c (test for excess errors)
--- Comment #4 from dje at gcc dot gnu dot org 2008-10-12 22:42 ---
This probably is the data segment overflow that occurred on mainline with the
additional dfa descriptions. For some reason AIX 5.2 is hitting it sooner and
on GCC itself. You probably need to add -Wl,-bmaxdata:0x20
--- Comment #10 from hjl at gcc dot gnu dot org 2008-10-12 21:45 ---
Subject: Bug 37447
Author: hjl
Date: Sun Oct 12 21:44:33 2008
New Revision: 141079
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141079
Log:
2008-10-12 H.J. Lu <[EMAIL PROTECTED]>
Backport from main
--- Comment #12 from zadeck at naturalbridge dot com 2008-10-12 21:22
---
fixed with the above patch.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #11 from zadeck at naturalbridge dot com 2008-10-12 21:19
---
Subject: Re: [4.4 Regression]: Revision 141067 breaks Linux/x86
Richard Guenther wrote:
> On Sun, Oct 12, 2008 at 11:12 PM, Kenneth Zadeck
> <[EMAIL PROTECTED]> wrote:
>
>> andreast at gcc dot gnu dot org wro
--- Comment #10 from zadeck at gcc dot gnu dot org 2008-10-12 21:18 ---
Subject: Bug 37808
Author: zadeck
Date: Sun Oct 12 21:16:57 2008
New Revision: 141078
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141078
Log:
2008-10-12 Kenneth Zadeck <[EMAIL PROTECTED]>
PR mid
--- Comment #9 from richard dot guenther at gmail dot com 2008-10-12 21:17
---
Subject: Re: [4.4 Regression]: Revision 141067 breaks Linux/x86
On Sun, Oct 12, 2008 at 11:12 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
> andreast at gcc dot gnu dot org wrote:
>> --- Comment #7 fro
--- Comment #8 from zadeck at naturalbridge dot com 2008-10-12 21:13
---
Subject: Re: [4.4 Regression]: Revision 141067 breaks Linux/x86
andreast at gcc dot gnu dot org wrote:
> --- Comment #7 from andreast at gcc dot gnu dot org 2008-10-12 20:31
> ---
> I see a failure on s
--- Comment #6 from rguenther at suse dot de 2008-10-12 20:51 ---
Subject: Re: if-combine doesn't optimize !=
after >= test
On Sun, 12 Oct 2008, pinskia at gmail dot com wrote:
> --- Comment #5 from pinskia at gmail dot com 2008-10-12 20:47 ---
> Subject: Re: if-combine doe
--- Comment #5 from pinskia at gmail dot com 2008-10-12 20:47 ---
Subject: Re: if-combine doesn't optimize != after >= test
On Sun, Oct 12, 2008 at 1:40 PM, rguenther at suse dot de
<[EMAIL PROTECTED]> wrote:
> No. ifcombine only combines on the CFG, in PR28685 we are dealing
> with a
On Sun, Oct 12, 2008 at 1:40 PM, rguenther at suse dot de
<[EMAIL PROTECTED]> wrote:
> No. ifcombine only combines on the CFG, in PR28685 we are dealing
> with a CFG-less opportunity.
Well it depends really. As on some targets it has a CFG based ||/&&
depending on BRANCH_COST.
Thanks,
Andrew Pi
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-12 20:45 ---
Another similar, but yet different case:
int test(int a, int b)
{
int lt = a < b;
int eq = a == b;
if (lt)
return 1;
return eq;
}
this is what we "optimize" it to:
test (int a, int b)
{
int eq;
:
--- Comment #4 from rguenther at suse dot de 2008-10-12 20:40 ---
Subject: Re: if-combine doesn't optimize !=
after >= test
On Sun, 12 Oct 2008, ubizjak at gmail dot com wrote:
> Does this patch also solve PR 28685?
No. ifcombine only combines on the CFG, in PR28685 we are dealing
--- Comment #7 from andreast at gcc dot gnu dot org 2008-10-12 20:31
---
I see a failure on sparc-solaris8/10 too. Configury of stage2 fails.
Applying the mentioned patch cures compilation.
My sparc config is with multilib. 32-bit/64-bit.
--
andreast at gcc dot gnu dot org changed:
--- Comment #9 from rth at gcc dot gnu dot org 2008-10-12 20:27 ---
Subject: Bug 37447
Author: rth
Date: Sun Oct 12 20:26:24 2008
New Revision: 141077
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141077
Log:
PR middle-end/37447
* Makefile.in (reload1.o): Depend
--- Comment #8 from rth at gcc dot gnu dot org 2008-10-12 20:27 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from aran at 100acres dot us 2008-10-12 20:24 ---
I got the same error at a different point.
/home/aran/projects/gcc/current/build/./gcc/xgcc
-B/home/aran/projects/gcc/current/build/./gcc/
-B/usr/local/opt/gcc-4.4/i386-unknown-netbsdelf4.99.72/bin/
-B/usr/local/opt/gcc-4.4
--- Comment #3 from ubizjak at gmail dot com 2008-10-12 20:19 ---
Does this patch also solve PR 28685?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37795
--- Comment #22 from lthode at mail dot unomaha dot edu 2008-10-12 19:57
---
amacleod: ping?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-10-12 19:47
---
> This works for me with GCC 4.4.0 20081011 + GAS 2.18.92 + Sun ld on Solaris 9.
([EMAIL PROTECTED]) ~ $ gcc -v
Using built-in specs.
Target: sparc64-sun-solaris2.9
Configured with: /nile.build/botcazou/gcc-head/
--- Comment #6 from geoffk at gcc dot gnu dot org 2008-10-12 19:44 ---
Confirmed, the regression tester sees it too.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from ubizjak at gmail dot com 2008-10-12 19:00 ---
Mine.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
This code:
#include
class Foo {
public:
voidF(int i) {}
voidG(int& i) {}
voidH(int* i) {}
};
voidbar () {
Foo f;
Foo* fs;
std::mem_fun(&Foo::F);
std::mem_fun(&Foo::G);
std::mem_fun(&Foo::H);
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-12 18:51 ---
Queued for 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #5 from dominiq at lps dot ens dot fr 2008-10-12 17:50 ---
(In reply to comment #4)
> I too had this ICE. The patch seems to make it work nicely.
Same thing here on i686-apple-darwin9. The test suite (all languages but ada)
passed without regression.
--
http://gcc.gnu.
--- Comment #4 from gcc-bugzilla at daryl dot haresign dot com 2008-10-12
16:57 ---
(In reply to comment #3)
> Created an attachment (id=16485)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16485&action=view) [edit]
> possible patch to fix the problem
>
> I am pretty sure that th
--- Comment #2 from paolo dot carlini at oracle dot com 2008-10-12 16:16
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedT
--- Comment #4 from carlo at gcc dot gnu dot org 2008-10-12 15:32 ---
Note that the original code was:
A& operator++(void)
{
++n;
if (__builtin_expect(n == m, false))
g();
return *this;
}
but g++ fails to optimize that by decrementing m outside
the loop (so I'm
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-12 15:29 ---
It looks like the testcase in comment #2 should be fixed by SSUPRE? We have
*p = ...;
if ()
foo();
where foo() is an "implicit" store to *p. Still store sinking should be
applied
to the subloop.
--
rg
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-12 15:25 ---
The original testcase (from an IRC discussion) reduced to a C testcase is:
struct A {
int n;
int m;
};
void g();
void test (struct A* iter)
{
struct A end = { 0, 0 };
while (iter->n != end.n)
{
i
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-12 15:20 ---
store-sinking doesn't do its job because it thinks that
Memory reference 0: iter_1(D)->n
Memory reference 1: iter_1(D)->m
...
Querying dependencies of ref 0 in loop 1: dependent
--
rguenth at gcc dot gnu dot org
The following code snippet:
void g();
struct A {
int n;
int m;
A& operator++(void)
{
if (__builtin_expect(n == m, false))
g();
else
++n;
return *this;
}
A() : n(0), m(0) { }
friend bool operator!=(A const& a1, A const& a2) { return a1.n != a2.n; }
};
void
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-10-12 12:09 ---
The front end obligingly fills out the descriptor for
the libray with an extent of 3:
atmp.5.dim[1].stride = 5;
atmp.5.dim[1].lbound = 0;
atmp.5.dim[1].ubound = 2;
atmp.5.data = (void *) &A.6;
atm
--- Comment #17 from mikael dot morin at tele2 dot fr 2008-10-12 11:47
---
(In reply to comment #16)
> Mikael, are you still with us? Your approach was fine.
>
Yep, I'm not dead yet.
I was waiting for my copyright assignment form.
Now it's on the way back, I will post to gcc-patches
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-10-12 11:33 ---
Confirm, updated subject, blocks bounds-checking meta-bug.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-10-12 11:30 ---
Paul, I'd like to draw your attention to this one. If you have any cycles to
spare right now...
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from domob at gcc dot gnu dot org 2008-10-12 10:53 ---
Fixed as suggested, thus basic arithmetic expressions are now also allowed even
containing untyped symbols as long as legacy (gnu) mode is enabled.
--
domob at gcc dot gnu dot org changed:
What|Remo
--- Comment #2 from domob at gcc dot gnu dot org 2008-10-12 10:52 ---
Subject: Bug 37688
Author: domob
Date: Sun Oct 12 10:51:11 2008
New Revision: 141074
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141074
Log:
2008-10-12 Daniel Kraft <[EMAIL PROTECTED]>
PR fortran
--- Comment #2 from pault at gcc dot gnu dot org 2008-10-12 10:49 ---
Since I fixed in on trunk already
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pault at gcc dot gnu dot org 2008-10-12 10:47 ---
Subject: Bug 37787
Author: pault
Date: Sun Oct 12 10:46:14 2008
New Revision: 141073
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141073
Log:
2008-10-12 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #4 from martinwguy at yahoo dot it 2008-10-12 10:46 ---
... but those patches simply disable all conditionally-executed instructions,
which is no good for mainline. What is needed is a new CC mode, as discussed in
http://gcc.gnu.org/ml/gcc/2007-06/msg00938.html
--
http:/
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-12 10:35 ---
Confirmed. Works on i686. Worked with 4.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-10-12 10:29
---
Note that we stopped documenting most of the x86 specific SSE/MMX builtins
because you should use the SSE/MMX intrinsics instead (the x86 specific
builtins can go away or change without further notice between relea
--- Comment #2 from pault at gcc dot gnu dot org 2008-10-12 09:39 ---
Subject: Bug 37792
Author: pault
Date: Sun Oct 12 09:38:18 2008
New Revision: 141072
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141072
Log:
2008-10-12 Steven G. Kargl <[EMAIL PROTECTED]>
PR fort
--- Comment #5 from doko at ubuntu dot com 2008-10-12 09:04 ---
closing. works for me with current 4.3.2
--
doko at ubuntu dot com changed:
What|Removed |Added
53 matches
Mail list logo
