--- Comment #7 from cnstar9988 at gmail dot com 2009-02-03 08:43 ---
4.3.3 on Linux has the same problem.
Target Milestone: 4.3.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35923
--- Comment #5 from pault at gcc dot gnu dot org 2009-02-03 08:55 ---
(In reply to comment #4)
I would have said that the value of the integer component after the first
assignment is, at best, ill-defined. If L_TO_T assigns a value to it, gfortran
gives the same result as any other
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-03 09:08 ---
The testcase lays the way to proof that whatever PTA ends up putting in
the ESCAPED solution (which includes all globals) TBAA disambiguation
on these is invalid. This basically means that TBAA is nearly useless,
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-03 09:17 ---
Yes, but as the store to y is via *x and x points to { ANYTHING } (via the
non-pointer (int ***)q) only (as x already includes ANYTHING we do not add
a for the second constraint), so for *x = i we fail to add a to
--- Comment #10 from bonzini at gnu dot org 2009-02-03 09:45 ---
How is it now?
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #10 from bonzini at gnu dot org 2009-02-03 09:47 ---
Can you try the patch of PR38824?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #14 from bonzini at gnu dot org 2009-02-03 09:49 ---
What about canonicalizing to a *positive* number?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-03 10:06 ---
Similarly
__typeof (0r)
foo (void)
{
return 0r;
}
ICEs on x86-64 and so does
_Fract foo (void)
{
return 0r;
}
(the last one just as error-recovery ICE). I'd say for
!targetm.fixed_point_supported_p () we should
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-03 09:55 ---
Created an attachment (id=17230)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17230action=view)
unincluded testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
--- Comment #2 from ubizjak at gmail dot com 2009-02-03 10:52 ---
libjava testsuite works OK on 4.3.4 branch for hppa-linux-gnu [1] and alpha
[2].
The remaining java failures on alpha are due to testsuite problem (dg ?/ expect
?/tcl ?), described in PR 33263.
[1]
--- Comment #6 from ubizjak at gmail dot com 2009-02-03 11:04 ---
(In reply to comment #2)
Note: ada on alpha bootstrap fine on trunk.
And on 4.3 branch [1]:
[1] http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00280.html
--
ubizjak at gmail dot com changed:
What
--- Comment #5 from bonzini at gnu dot org 2009-02-03 11:11 ---
caused by r90059 (convert_nontype_argument rewrite). Giovanni, do you have
time to see if the patch I made makes sense?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #12 from bonzini at gnu dot org 2009-02-03 11:17 ---
What if we forbid altogether memory operands and we *synthesize* them with a
peephole2? Anyway, it seems safe to me to declare this a dup of PR38824?
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #6 from ubizjak at gmail dot com 2009-02-03 11:18 ---
Can someone check if this still fails on latest 4.3 branch?
4.4 works OK.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2009-02-03 11:10 ---
Not a GCC bug.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from ubizjak at gmail dot com 2009-02-03 12:24 ---
Current trunk produces:
f:
.frame $30,0,$26,0
.prologue 0
and $16,4,$3
lda $6,64($31)
bis $31,$31,$2
cmpult $31,$3,$3
beq $3,$L3
stl $31,0($16)
lda
--- Comment #9 from ubizjak at gmail dot com 2009-02-03 12:25 ---
Together with the patch for PR 8603:
f:
.frame $30,0,$26,0
.prologue 0
and $16,4,$4
lda $1,64($31)
bis $31,$31,$2
cmpult $31,$4,$4
beq $4,$L3
stl $31,0($16)
--- Comment #10 from ubizjak at gmail dot com 2009-02-03 12:31 ---
By changing the test to:
--cut here--
unsigned int p[64];
int f(void) {
for (int i = 0; i 64; ++i)
p[i] = 0;
}
--cut here--
gcc -O2 -ftree-vectorize -mcpu=ev67 -std=c99
f:
.frame $30,0,$26,0
--- Comment #18 from paolo dot carlini at oracle dot com 2009-02-03 13:16
---
(In reply to comment #17)
+ if (TREE_CODE (t1) == TYPENAME_TYPE)
+t1 = resolve_typename_type (t2, /*only_current_p=*/true);
But I suppose you want consistently t1 here ;)
--
--- Comment #11 from ubizjak at gmail dot com 2009-02-03 10:36 ---
(In reply to comment #10)
Can you try the patch of PR38824?
I have tried with a similar peephole2 recognizer. The problem is, that there is
no spare x register to allocate as a temporary, so peephole2 is ineffective
in
--- Comment #2 from kkojima at gcc dot gnu dot org 2009-02-03 13:31 ---
It seems that the move insn in problem is generated when reloading
but has no insn definition matched.
The patch
--- ORIG/trunk/gcc/config/sh/predicates.md 2008-04-05 09:19:14.0
+0900
+++
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-03 10:20 ---
Subject: Bug 38049
Author: rguenth
Date: Tue Feb 3 10:20:20 2009
New Revision: 143890
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143890
Log:
2009-02-03 Richard Guenther rguent...@suse.de
PR
--- Comment #6 from bonzini at gnu dot org 2009-02-03 13:58 ---
News?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37437
--- Comment #2 from bonzini at gnu dot org 2009-02-03 14:00 ---
Is this a regression? I don't see anything in the patches or in their
description that would prevent a backport to 4.4.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #34 from bonzini at gnu dot org 2009-02-03 14:02 ---
Is this still a 4.4 regression?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #13 from bonzini at gnu dot org 2009-02-03 14:23 ---
Adjusting subject, the testcase from comment #2 still produces suboptimal code.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenther at suse dot de 2009-02-03 14:24 ---
Subject: Re: PTA constraint processing for *x
= y is wrong
On Tue, 3 Feb 2009, dberlin at dberlin dot org wrote:
Subject: Re: PTA constraint processing for *x =
y is wrong
There used to be a *ANYTHING =
--- Comment #14 from bonzini at gnu dot org 2009-02-03 14:30 ---
what remains is a dup of 22141.
*** This bug has been marked as a duplicate of 22141 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from bonzini at gnu dot org 2009-02-03 14:30 ---
*** Bug 37135 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
bonzini at gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39084
--- Comment #11 from vmakarov at redhat dot com 2009-02-03 14:48 ---
I have a patch (a new spill heuristic) which makes facerec even faster with IRA
on power6. The patch is in
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00368.html
Unfortunately the new spill heuristic results in
--- Comment #12 from bonzini at gnu dot org 2009-02-03 14:56 ---
Maybe we can approach the problem from the other side, for example marking I/O
functions as cold, or marking I/O functions as cold so that
PRED_FLAG_FIRST_MATCH hits in predict.def?
--
bonzini at gnu dot org changed:
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
On an Arm9 processor running Debian the following program gives the results
indicated...
#include stdio.h
#include stdlib.h
#include math.h
int main()
{
double in, out;
in = 2.0;
out = sqrt(in);
printf(%f\n, out); // 2.
printf(%f\n, sqrt(in)); // 1.414214
printf(%f\n, sqrt(2.0));
--- Comment #7 from vmakarov at redhat dot com 2009-02-03 15:06 ---
I don't see anymore code difference (only a bit different hard registers are
used) on mentioned functions for code generated with the old RA and IRA.
Probably it was fixed with a fix in regmove which was submitted as a
When compiling test 27_io/basic_istream/requirements/explicit_instantiation.cc
from the libstc++ testsuite and adding the -fno-tree-sra flag, I get
the following error:
--
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-02-03 15:09 ---
Created an attachment (id=17232)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17232action=view)
Preprocessed source
Enough to compile with -O2 -g -fno-tree-sra explicit_instantiation.ii
--
--- Comment #8 from bonzini at gnu dot org 2009-02-03 15:09 ---
Great.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from bonzini at gnu dot org 2009-02-03 15:15 ---
No, the patch does not fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
--- Comment #12 from bonzini at gnu dot org 2009-02-03 15:19 ---
But at least it gets cc1 to call rtx_addr_can_trap_p_1. Mine
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-03 15:30 ---
Not too useful, that preprocessed source includes PCHs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||error-recovery
Priority|P3 |P4
--- Comment #3 from tony_eckert at umsl dot edu 2009-02-03 15:38 ---
Created an attachment (id=17233)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17233action=view)
autoconf log of failed stage 3 build
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
I have noticed that in some cases - especially calculating Mandelbrot Fractals
there is a severe performance penalty if the COMPLEX data type is used instead
of plain variables.
It's nothing wrong with the calculation, but it shall be noted that it can mean
a severe performance penalty if the
Sent from my iPhone
On Feb 3, 2009, at 5:56 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #7 from bonzini at gnu dot org 2009-02-03 13:56
---
ping?
The patch was just approved last night and I will be applying it when
I get into work today.
--- Comment #8 from pinskia at gmail dot com 2009-02-03 15:44 ---
Subject: Re: [4.3/4.4 Regression] Incorrect type diagnostic on substracting
casted char pointers
Sent from my iPhone
On Feb 3, 2009, at 5:56 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
---
--- Comment #13 from bonzini at gnu dot org 2009-02-03 15:48 ---
Created an attachment (id=17235)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17235action=view)
patch to be tested
The patch fixes the bug. As a follow up (see PR38921 audit trail)
MTP_AFTER_MOVE and
--- Comment #2 from m4341 at abc dot se 2009-02-03 15:50 ---
Notice that the test cases have been executed on a Pentium III computer with
dual 866MHz processors.
The 'depth' variable in the example code has been set to produce comfortable
execution times for the forementioned computer.
Following emits a warning about potential use of uninitialized variable,
even though the variable initialization and it's use are guarded by the
same predicate.
int f (void);
int g (int a)
{
int b;
if (a) b = f ();
asm volatile (#);
if (a) return b;
return 1;
}
$ gcc -O
--- Comment #6 from bonzini at gnu dot org 2009-02-03 15:56 ---
Subject: Bug 36897
Author: bonzini
Date: Tue Feb 3 15:56:05 2009
New Revision: 143896
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143896
Log:
gcc/cp:
2009-02-03 Paolo Bonzini bonz...@gnu.org
PR
--- Comment #20 from bonzini at gnu dot org 2009-02-03 15:56 ---
Subject: Bug 37314
Author: bonzini
Date: Tue Feb 3 15:56:05 2009
New Revision: 143896
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143896
Log:
gcc/cp:
2009-02-03 Paolo Bonzini bonz...@gnu.org
PR
--- Comment #3 from s dot neumann at phase-zero dot de 2009-02-03 16:14
---
The code in flac that triggered the problem does also make gcc crash with -O3
-funroll-loops. I've also tested -O1 and -O2, same problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-03 16:15 ---
Use -ffast-math.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39087
--- Comment #32 from bonzini at gnu dot org 2009-02-03 16:16 ---
The patch for partial memory writes was committed.
How are we doing on this benchmark now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #7 from bonzini at gnu dot org 2009-02-03 16:20 ---
fixed on 4.3/4.4, still needs backporting to 4.2
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #21 from bonzini at gnu dot org 2009-02-03 16:21 ---
fixed on 4.3/4.4, still needs backporting to 4.2
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #8 from paolo dot carlini at oracle dot com 2009-02-03 16:22
---
Did you really commit it to mainline? I don't see it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
--- Comment #22 from paolo dot carlini at oracle dot com 2009-02-03 16:22
---
Likewise... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
--- Comment #12 from bonzini at gnu dot org 2009-02-03 16:25 ---
When generating 64-bit code we produce good induction variables either with or
without ivopts, but with an extra mov.
For 32-bit code the situation is the same as reported originally.
--
bonzini at gnu dot org
--- Comment #9 from bonzini at gnu dot org 2009-02-03 16:26 ---
Subject: Re: [4.2 Regression] ICE with function pointer
template parameter
Did you really commit it to mainline? I don't see it.
I was doing it. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
--- Comment #9 from bonzini at gnu dot org 2009-02-03 16:26 ---
Subject: Re: [4.2 Regression] ICE with function pointer
template parameter
Did you really commit it to mainline? I don't see it.
I was doing it. :-)
--- Comment #10 from bonzini at gnu dot org 2009-02-03
--- Comment #23 from bonzini at gnu dot org 2009-02-03 16:26 ---
Subject: Bug 37314
Author: bonzini
Date: Tue Feb 3 16:26:28 2009
New Revision: 143898
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143898
Log:
gcc/cp:
2009-02-03 Paolo Bonzini bonz...@gnu.org
PR
--- Comment #8 from bonzini at gnu dot org 2009-02-03 16:28 ---
changing summary, inlining _is_ the right thing to do.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #1 from m4341 at abc dot se 2009-02-03 15:46 ---
Created an attachment (id=17234)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17234action=view)
Test cases for demonstrating performance impact.
The attached file contains code that is in it's current state requiring
--- Comment #68 from bonzini at gnu dot org 2009-02-03 16:32 ---
This was fixed on trunk (see comment #65).
Open another bug for long-term solutions, this is cluttering the 4.4
regressions. :-)
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #14 from hp at gcc dot gnu dot org 2009-02-03 16:34 ---
(In reply to comment #11)
No, the patch does not fix it.
Yes, I found that out too ;) but haven't had time to follow up.
FWIW, I have an overlapping patch for PR38921 that does fold the code as
suggested. It doesn't
--- Comment #17 from etienne_lorrain at yahoo dot fr 2009-02-03 16:38
---
(In reply to comment #15)
The advantage of such a RTL pass (or just adding such optimization to another
RTL pass) would be that it would handle also say: ...
Why only limit that pass to constants, and only to
--- Comment #15 from bonzini at gnu dot org 2009-02-03 16:40 ---
Subject: Re: [4.3/4.4 Regression] SEGV,
conditional execution proactively executed the false arm.
Yes, I found that out too ;) but haven't had time to follow up.
FWIW, I have an overlapping patch for PR38921
--- Comment #13 from bonzini at gnu dot org 2009-02-03 16:40 ---
I agree that the patch is correct *without* the -1, so... ping :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
--- Comment #4 from bonzini at gnu dot org 2009-02-03 16:52 ---
more precisely, without -ffast-math gcc is not able to change abs(z) 2 to
r*r+i*i 4 and computes a square root on every iteration.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #4 from bonzini at gnu dot org 2009-02-03 16:56 ---
no he's not.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-02-03 16:56 ---
Created an attachment (id=17236)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17236action=view)
Preprocessed source
OK, this one is hopefully without any precompiled headers.
--
jamborm at gcc dot gnu
--- Comment #28 from bonzini at gnu dot org 2009-02-03 09:54 ---
Am I right that the bug is just at -O, not at -O2? 4.4 -O2 is worse than 4.4
-O2 -fno-strict-aliasing, but are they better than 4.3 -O2 or worse?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
--- Comment #77 from bonzini at gnu dot org 2009-02-03 17:10 ---
Can't the library just #undef try/catch at the end of each file that includes
exception_defines.h?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #78 from paolo dot carlini at oracle dot com 2009-02-03 17:14
---
Nope, we never do that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #6 from bonzini at gnu dot org 2009-02-03 17:15 ---
Only fails on 64-bit targets.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #79 from bonzini at gnu dot org 2009-02-03 17:15 ---
Yeah, but it seems better than uglifying __try/__catch all over the place...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #80 from paolo dot carlini at oracle dot com 2009-02-03 17:20
---
Many solutions are better, in principle, but really this issue is too old.
After all we are uglifying also in other cases. Let's do that and be done with
it. Unless there are objections (or, better,
--- Comment #7 from bonzini at gnu dot org 2009-02-03 17:21 ---
Interesting: we actually propagate *more* on 64-bit targets, and end up with
__builtin___memcpy_chk (buf, valbuf_7(D), 16, 8);
while on 32-bit we get
__builtin___memcpy_chk (buf, valbuf_7(D), D.1293_2, 8);
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-03 17:23 ---
Subject: Bug 39056
Author: jakub
Date: Tue Feb 3 17:23:11 2009
New Revision: 143899
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143899
Log:
PR c++/39056
* typeck2.c (digest_init_r): Don't
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-03 17:26 ---
Subject: Bug 39059
Author: jakub
Date: Tue Feb 3 17:26:28 2009
New Revision: 143900
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143900
Log:
PR inline-asm/39059
* c-parser.c
--- Comment #8 from jakub at gcc dot gnu dot org 2009-02-03 17:28 ---
Subject: Bug 35318
Author: jakub
Date: Tue Feb 3 17:27:45 2009
New Revision: 143901
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143901
Log:
PR target/35318
* function.c
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-02-03 17:38 ---
Working on a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hp at gcc dot gnu dot org 2009-02-03 17:46 ---
Created an attachment (id=17237)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17237action=view)
Proposed fix
Also folds may_trap_after_code_motion_p into may_trap_or_fault_p, as being the
original semantics.
--
--- Comment #16 from hp at gcc dot gnu dot org 2009-02-03 17:54 ---
(In reply to comment #15)
If you submit it, I'll happily take care of the conflicts.
I've put it in the PR, though it's not a proper submit yet.
Also, only regtested for cris-elf on the 4.3 branch and
--- Comment #4 from burnus at gcc dot gnu dot org 2009-02-03 10:02 ---
I believe gfortran is correct as far as giving an error. The last logical
value does not begin with a T(t) or F(f).
That was my impression in comment 0 (maybe wontfix), which was confirmed by
the standard
--- Comment #13 from ubizjak at gmail dot com 2009-02-03 11:34 ---
(In reply to comment #12)
What if we forbid altogether memory operands and we *synthesize* them with a
peephole2? Anyway, it seems safe to me to declare this a dup of PR38824?
I think that we will hit PR 19398
--- Comment #15 from jakub at gcc dot gnu dot org 2009-02-03 09:56 ---
I really think either GCSE should be trying to decrease the number of floating
point constants used by a function by getting rid of constants for which
negated constants is also used and it can be negated at no cost
g++ 4.3.3 emits warnings for every statement in the following function when the
code is built this way:
/gcc43/bin/g++ -c -Wall -Wconversion test.cpp
void func(unsigned char a, unsigned char b, unsigned char *out)
{
*out = a | b;
*out = out[0] 0x20;
out[0] = 0x20;
}
I'd expect
--- Comment #17 from bonzini at gnu dot org 2009-02-03 17:57 ---
Thanks, I'll merge it with mine, bootstrap/regtest i686-pc-linux-gnu and submit
it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
With GCC: (GNU) 4.4.0 20090116 (experimental) [trunk revision 143437]
Consider this program (bug1900.c):
---8---
unsigned long long bar()
{
unsigned long long rv;
asm volatile (rdhwr %0, $30 : =d (rv));
return rv;
}
--- Comment #1 from oleg dot smolsky at riverbed dot com 2009-02-03 17:58
---
Created an attachment (id=17238)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17238action=view)
The test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39089
--- Comment #5 from dberlin at gcc dot gnu dot org 2009-02-03 14:16 ---
Subject: Re: PTA constraint processing for *x =
y is wrong
There used to be a *ANYTHING = ANYTHING constraint + ANYTHING
containing all the variables pointing to ANYTHING that would have
taken care of
--- Comment #5 from mikael dot morin at tele2 dot fr 2009-02-03 18:00
---
/export/home/eckerta/Desktop/objdir/./gcc/gfortran
-B/export/home/eckerta/Desktop/objdir/./gcc/
-B/usr/local/gcc-4.3.3/i686-pc-linux-gnu/bin/
-B/usr/local/gcc-4.3.3/i686-pc-linux-gnu/lib/ -isystem
--- Comment #6 from mikael dot morin at tele2 dot fr 2009-02-03 18:01
---
(In reply to comment #1)
Only departure from defaults is --prefix
No, -prefix ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
--- Comment #17 from bonzini at gnu dot org 2009-02-03 12:51 ---
The failure happens because structural_comptypes calls resolve_typename_type,
while merge_types does not. Maybe it should as in this patch?
Index: ../../peak-gcc-src/gcc/cp/typeck.c
I believe this is a genuine GCC compiler bug (in both GCC 4.1.1 and GCC
4.2.4). I hope this report is of value, and certainly hope it can be
corrected.
Forgive me for not logging a bug via http://gcc.gnu.org/bugzilla/ - I don't
want to mess around with your system due to unfamiliarity with
--- Comment #2 from gerald at pfeifer dot com 2009-02-03 10:03 ---
Latest testruns confirm this as fixed:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00249.html
Only four failures remain, and these are different from what has been
reported here:
=== libgomp tests
1 - 100 of 148 matches
Mail list logo
