--- Comment #6 from zerocool at modemsoft dot it 2006-03-30 08:19 ---
> Now run "debugx jc1 ", where ""
> was the entire command noted earlier that causes the failure.
Before i reproduce the error, after i make the command :
debugx jcl
/gcc-929a0346fb3027265ab1a9f2683e27c6/gcc-4.1-200
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-03-30 08:25
---
> I think it's a front-end problem and the argument of c35507m__charRP should be
> in the base type.
Humpf... Freeze_Enumeration_Type has this big comment:
-- Now we build the function that converts repr
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-03-30 08:32
---
So, in the end, the problem seems to be equivalent to the 'Valid stuff.
Richard, I know Robert and you have come up with a plan to address the 'Valid
problem. Is there an implementation sketch available somewhe
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-30 09:01 ---
It looks like we got a mismatch between the fndecls number of arguments and the
call site number of arguments, so we calculate the wrong saving of instruction
numbers.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #9 from patchapp at dberlin dot org 2006-03-30 09:15 ---
Subject: Bug number PR26900
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-03/msg01736.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #20 from bonzini at gnu dot org 2006-03-30 09:17 ---
Trying a naive patch that moves update_ssa from tree_duplicate_sese_region to
after all loop headers are copied...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-30 09:45 ---
I believe this has been fixed for the mainline with
2006-02-25 Juergen Weigert <[EMAIL PROTECTED]>
Richard Guenther <[EMAIL PROTECTED]>
* scan-decls.c (scan_decls): Don't fetch new statement afte
The following invalid testcase causes an ICE since GCC 3.1:
template struct A;
template struct A
{
A();
};
A<0> a;
bug.cc:1: error: previous declaration 'template, int
> struct A'
bug.cc:3: error: used 2 templa
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-sccp-details" } */
void bar(int);
void foo(int i1, int j1)
{
int i, j;
for (j=0; j<=j1; ++j)
for (i=0; i<=i1; ++i)
bar(j+1);
}
/* { dg-final { scan-tree-dump-not "set_nb_iterations_in_loop = scev_not_known"
"sccp"} } */
/* {
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-03-30 11:13
---
Even shorter testcase:
If I remove an argument of the constructor, the code compiles fine.
struct A
{
A() {}
};
struct B
{
A a;
B(A, int
The following test case fails to compile with all compiler from 4.x series. (I
didn't check with any earlier version.) Comeaue's test drive compiler does not
complain.
Changing the declaration of "a" in "struct b" into "struct a a;" makes it
compile.
8<---8<---8<---8<---
struct a {
};
struct b {
--- Comment #2 from sugioka at itonet dot co dot jp 2006-03-30 11:50
---
Thanks for the information.
I have confirmed that this is fixed on mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26936
--- Comment #13 from kenner at vlsi1 dot ultra dot nyu dot edu 2006-03-30
12:13 ---
Subject: Re: [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
Richard, I know Robert and you have come up with a plan to address the
'Valid problem. Is there an implementation sketch a
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-30 12:22 ---
Note this testcase requires the fix(es) for PR26900 to figure out the number of
iterations for the inner loop. The failure to figure out the number of
iterations of the outer loop can be reproduced with mainline. B
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-30 12:31 ---
You can see that PRE makes a mess out of it because of the copied loop header
of the inner loop. So maybe Zdeneks patch to move the loop header copy outside
of the first loop helps here. Though I'd prefer to preven
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-30 13:02
---
Reduced testcase (fails with "-O2 -m32" on x86_64-unknown-linux-gnu):
===
typedef struct { int i; } A;
typedef struct { int i; } B;
int M;
void
--- Comment #7 from rmathew at gcc dot gnu dot org 2006-03-30 13:07 ---
(In reply to comment #6)
> > Now run "debugx jc1 ", where ""
> > was the entire command noted earlier that causes the failure.
> Before i reproduce the error, after i make the command :
>
> debugx jcl
> /gcc-929a03
[EMAIL PROTECTED] tmp]# cat a.c
#include
float Q_rsqrt(float number)
{
long i;
float x2, y;
float threehalfs = 1.5f;
x2 = number * 0.5f;
y = number;
i = *(long *)&y;
i = 0x5f3759df-(i>>1);
y = *(float *)&i;
y = y * (threehalf
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-30 13:34 ---
Created an attachment (id=11164)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11164&action=view)
candidate patch
The attached patch is maybe a fix - though a better way to detect what could be
a loop header c
--- Comment #9 from bdavis at gcc dot gnu dot org 2006-03-30 13:52 ---
after the above patch, here is a profile of the last file (that takes so long
to compile):
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls
--- Comment #10 from bdavis at gcc dot gnu dot org 2006-03-30 13:58 ---
with the same patch, the aermod.f90 :
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls s/call s/call name
7.69 8.80 8.80 2972
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-03-30 14:04 ---
(In reply to comment #2)
> You can see that PRE makes a mess out of it because of the copied loop header
> of the inner loop. So maybe Zdeneks patch to move the loop header copy
> outside
> of the first loop helps
--- Comment #21 from bonzini at gnu dot org 2006-03-30 14:04 ---
Patch bootstrapped, regtesting in progress. With checking enabled I have this
which is not bad at all.
tree PHI insertion: 49.68 ( 5%)
tree SSA rewrite : 63.75 ( 7%)
tree SSA incremental : 4.75 ( 1%)
dom
--- Comment #11 from bdavis at gcc dot gnu dot org 2006-03-30 14:04 ---
if this patch gets accepted, i vote to close the PR. we are still slower than
we should be, but it is now linear and compiles in a 'reasonable time'.
--bud
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org
--- Comment #5 from aph at gcc dot gnu dot org 2006-03-30 14:24 ---
I'm testing a patch for this.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from bonzini at gnu dot org 2006-03-30 14:31 ---
Subject: Bug 26830
Author: bonzini
Date: Thu Mar 30 14:31:13 2006
New Revision: 112534
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112534
Log:
2006-03-30 Paolo Bonzini <[EMAIL PROTECTED]>
PR tree-opti
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-30 14:37 ---
Loop header copying for the inner loop is required for # of iterations analysis
- though we should move that header copy out of the outer loop, too, if
possible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26
I've found this bug while building gcc 4.1.0 (on GNU/Linux x86). In the
'rebuild with -fprofile-use' stage I get the following error:
stage1/xgcc -Bstage1/ -B/usr/i386-unknown-linux-gnu/bin/ -c -O2 -g
-fomit-frame-pointer -fprofile-use -freorder-blocks-and-partition -DIN_GCC -W
-Wall -Wwrite-strin
--- Comment #1 from clifford at clifford dot at 2006-03-30 14:43 ---
Created an attachment (id=11165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11165&action=view)
Testcase
This are the prerpocessed C input file, the .gcda and .gcno files (for
-fprofile-use) and a little shell
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-30 14:43 ---
Subject: Re: PRE confuses loop number of
iterations analysis
On Thu, 2006-03-30 at 14:37 +, rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-30
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-03-30 14:56
---
You code violates the aliasing rules in this line:
y = *(float *)&i;
Please read http://gcc.gnu.org/bugs.html
In the non-bug section you will find: "Casting does not work as expected when
optimization is t
--- Comment #89 from reichelt at gcc dot gnu dot org 2006-03-30 14:56
---
*** Bug 26941 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pcarlini at suse dot de 2006-03-30 15:06 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|---
--- Comment #7 from pcarlini at suse dot de 2006-03-30 15:07 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #3 from pcarlini at suse dot de 2006-03-30 15:08 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-30 15:11 ---
You are probably right about improving SCEV - I hope Sebastian can make it work
for this and similar cases. Wrt the loop header it is that we convert the loop
to a do-while style loop, which at least iterates once,
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot
|dot org
--- Comment #3 from pcarlini at suse dot de 2006-03-30 15:12 ---
Feedback not forthcoming.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCO
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-30 15:29 ---
Just for the record, the attached patch bootstrapped and regtested on
x86_64-unknown-linux-gnu, with the following fallout:
FAIL: gcc.dg/tree-ssa/loadpre4.c scan-tree-dump-times Eliminated: 1 1
FAIL: gcc.dg/tree-ssa
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2006-03-30 15:41
---
Subject: Bug 26734
Author: mkuvyrkov
Date: Thu Mar 30 15:41:00 2006
New Revision: 112538
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112538
Log:
2006-03-30 Maxim Kuvyrkov <[EMAIL PROTECTED]>
--- Comment #12 from mkuvyrkov at gcc dot gnu dot org 2006-03-30 15:43
---
The patch was reapplied:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01721.html
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #31 from rguenth at gcc dot gnu dot org 2006-03-30 15:48
---
How did you test the patch with OpenOffice? Are there OpenOffice modifications
necessary?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-03-30 15:49
---
Note that the regression is in 4.1, too, so we should consider backporting
changes that accumulate here to the branch after a while.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
--- Comment #32 from mckinlay at redhat dot com 2006-03-30 15:51 ---
(In reply to comment #31)
Yes, this patch should fix all the OpenOffice issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
Two problems here. The first was trying to show that we don't necessarily
honor
the requirement that all firstprivate copies are executed before the
lastprivate
assignment happens. The second is that we're not properly substituting for the
global X here within the scope of the privatization.
--
--- Comment #1 from rth at gcc dot gnu dot org 2006-03-30 15:56 ---
Created an attachment (id=11166)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11166&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
The loop from the code below is compiled to this when using gcc-4.1 -O2
.L5:
movl16(%ebp), %eax
addl%ecx, %eax
addl$1, %ecx
movl%edx, 20(%ebx,%eax,4)
leal(%edx,%ecx), %eax
cmpl%edi, %eax
jle .L5
but the code is much
--- Comment #8 from schnetter at aei dot mpg dot de 2006-03-30 16:18
---
I had the same problem. I replaced this file, ran the test cases, and sent the
results. The summary is
=== gfortran Summary ===
# of expected passes12636
# of unexpected failures
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-30 16:25 ---
Note that this may be also PRE confusing SCEV in presence of loop headers.
I.e. a sort of dup of PR26939. Confirmed though. A regression from 4.0.3,
which is also fine.
--
rguenth at gcc dot gnu dot org change
Compile attached test case with optimization causes an ICE:
$ gcc -c -O1 bug.c
bug.c: In function 'parsearguments':
bug.c:46: error: Attempt to delete prologue/epilogue insn:
(insn/f 97 96 98 0 (set (mem:SI (plus:SI (reg/f:SI 30 %r30)
(const_int -124 [0xff84])) [0 S4 A32])
--- Comment #1 from tausq at debian dot org 2006-03-30 16:28 ---
Created an attachment (id=11167)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11167&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-03-30 16:30 ---
Subject: Bug 25031
Author: tkoenig
Date: Thu Mar 30 16:30:26 2006
New Revision: 112539
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112539
Log:
2006-03-30 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #2 from tausq at debian dot org 2006-03-30 16:31 ---
The code is valid syntactically, but there is actually a bug. the longoptions
array only has 3 elements, but we try to fill in 4 entries. if we make the
longoptions array bigger than it doesn't cause the ICE.
--
http:/
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-30 16:39 ---
Subject: Bug 26042
Author: tromey
Date: Thu Mar 30 16:39:17 2006
New Revision: 112540
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112540
Log:
gcc/java
PR java/26042:
* parse.y (java_reorde
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-03-30
16:43 ---
(In reply to comment #1)
> Note that this may be also PRE confusing SCEV in presence of loop headers.
Talking about PRE, here's a maybe interesting observation in the PRE dump:
:;
pretmp.30_53 = Int_L
--- Comment #11 from tromey at gcc dot gnu dot org 2006-03-30 16:47 ---
Subject: Bug 26042
Author: tromey
Date: Thu Mar 30 16:47:23 2006
New Revision: 112541
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112541
Log:
gcc/java
PR java/26042:
* parse.y (java_reorde
--- Comment #30 from quanah at stanford dot edu 2006-03-30 16:48 ---
Here is what happens when I run it by hand:
solaris8-build:/afs/ir/src/pubsw/languages/gcc-build/sun4x_58/sparc-sun-solaris2.8/libgfortran>
/bin/ksh ../../../../gcc-4.0.3/libgfortran/mk-sik-inc.sh
'/afs/ir.stanford.edu
--- Comment #12 from tromey at gcc dot gnu dot org 2006-03-30 16:49 ---
I checked the fix into the 4.1 branch and the trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2006-03-30 16:52
---
> No errors or anything... It just spits out the broken bits.
OK. Could you then break apart the script and run the various pieces manually?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #32 from quanah at stanford dot edu 2006-03-30 17:10 ---
Okay, I created the following file (as is generated by the script):
solaris8-build:/tmp> cat /tmp/q1.f90
integer (kind=1) :: x
end
Then ran the build command on it as is done by the script:
/afs/ir.stanford.edu/
--- Comment #14 from law at redhat dot com 2006-03-30 17:15 ---
Just a note on the compile-time regressions for tramp3d...
After fixing the timevars it was pretty clear that it isn't the cprop code
itself that is slow, it is in fact very fast. THe slowdowns for tramp3d are in
operand s
--- Comment #33 from quanah at stanford dot edu 2006-03-30 17:17 ---
GDB shows:
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain condit
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2006-03-30 17:35
---
> Program received signal SIGSEGV, Segmentation fault.
> 0x0035c398 in mpfr_set_default_prec ()
> (gdb) bt
> #0 0x0035c398 in mpfr_set_default_prec ()
OK. Could you ditch MPFR 2.2.0 entirely and use the MPFR l
--- Comment #35 from quanah at stanford dot edu 2006-03-30 17:40 ---
>From the GMP 4.2 NEWS file:
Mis-features:
* mpfr is gone, and will from now on be released only separately. Please see
www.mpfr.org.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #2 from sayle at gcc dot gnu dot org 2006-03-30 17:47 ---
Subject: Bug 17959
Author: sayle
Date: Thu Mar 30 17:47:48 2006
New Revision: 112543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112543
Log:
PR target/17959
* expr.c (emit_group_store): Op
--- Comment #36 from quanah at stanford dot edu 2006-03-30 17:48 ---
Just to note, if I haven't already, I was able to build gcc 4.0.3 with GMP 4.2
and MPFR 2.2.0 on i386 and amd64 without a problem (including fortran), so this
seems to be a problem specific to Solaris 8/9.
--
http:
With the actual snapshot (gcc-4.2-20060325) I get the ICE: tree check:
expected ssa_name, have struct_field_tag in is_old_name, at tree-into-ssa.c:466
Michael Cieslinski
g++42f -O1 -msse2 -mfpmath=sse -ftree-vectorize -c in.ii -S -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configure
--- Comment #1 from micis at gmx dot de 2006-03-30 18:13 ---
Created an attachment (id=11168)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11168&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26948
Compiling the code in PR26944 with -O2 -march=pentium4 -fno-tree-ch
generates this for the loop:
.L3:
movl%esi, -4(%eax)
addl$1, %edx
addl$4, %eax
cmpl-16(%ebp), %edx <- note an extra memory access here
jle .L3
compiling for -march=i
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2006-03-30 18:48
---
> From the GMP 4.2 NEWS file:
>
> Mis-features:
> * mpfr is gone, and will from now on be released only separately. Please
> see
> www.mpfr.org.
Grumpf... Could you downgrade to 4.1.x then?
--
ht
The following should elicit an error during processing of e0's initializer:
namespace N {
const int a = 42;
enum N { e0 = N::a };
}
... because 3.4.3p1 [basic.lookup.qual] indicates that the enumeration [tag]
name N should be found during lookup in the nested-name-specifier and renders
t
--- Comment #8 from zerocool at modemsoft dot it 2006-03-30 19:28 ---
Created an attachment (id=11169)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11169&action=view)
The Gcc Build Log
It's My build log...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
--- Comment #9 from zerocool at modemsoft dot it 2006-03-30 19:31 ---
Hello Mathew,
i have tried to perform your indications, but without success; with a lot of
probability because of my little competence in matter. I would pray you,
considering that I have posted the build complete lo
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 19:55 ---
This is actually invalid code which the C++ standard says implementions don't
have to error out about.
*** This bug has been marked as a duplicate of 17353 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-30 19:55 ---
*** Bug 26940 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 19:57 ---
This has nothing to do with -fprofile-use and all to do with
-freorder-blocks-and-partition
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-30 19:59 ---
I am starting to think we should change a[outofbounds] = 1 to be an
__builtin_trap() so that we will not run into stuff like this again.
Also we should have a keyword for ice-on-undefined-code too :).
--
pinskia
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:02 ---
Hmm, Comeau C++ does not reject this code either (but that does not mean this
is not invalid code).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 20:04 ---
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-03-30 20:09 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26853
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last re
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 20:12 ---
Confirmed, just a note, all patches need to go on the mainline before even
thinking about being backported. (Yes I know how long the copyright issues are
because I am trying to get my fixed up too).
--
pinskia a
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|trivial |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26877
--- Comment #2 from widman at gimpel dot com 2006-03-30 21:06 ---
Subject: Error diagnostic not issued for unacceptable result of lookup for a
name used in a nested-name-specifier
On Mar 30, 2006, at 2:56 PM, Daveed Vandevoorde wrote:
> Hi James,
>
> On Mar 30, 2006, at 2:31 PM, Jam
--- Comment #3 from mbland at google dot com 2006-03-30 21:09 ---
Right, I've got a mainline patch now, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26857
--- Comment #38 from quanah at stanford dot edu 2006-03-30 21:18 ---
Yeah, I'll give that a shot next week (i'm now in a freeze period).
I've also been poking at MPFR. There are apparently 10 or more patches now for
2.2.0, that may resolve the issues, too. I'll look at that. I've reb
--- Comment #2 from roger at eyesopen dot com 2006-03-30 21:24 ---
This should now be fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #3 from roger at eyesopen dot com 2006-03-30 21:35 ---
This is now be fixed on mainline. With -mpowerpc64, we now generate:
_div16:
rldimi 3,4,0,32
srdi 4,3,4
srdi 3,3,36
blr
--
roger at eyesopen dot com changed:
What|Rem
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 21:46 ---
ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested
architecture
ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested
architecture
I don't think there is anything GCC can d
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 21:49 ---
Confirmed, only when CST1 == CST2 does this work based on:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01746.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 21:53 ---
Note it works correctly without the inline-asm.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-03-30 22:00
---
Subject: Bug 26712
Author: fxcoudert
Date: Thu Mar 30 22:00:21 2006
New Revision: 112546
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112546
Log:
PR libfortran/26712
* config/fpu-387.h:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-30 22:00 ---
#pragma GCC visibility push(hidden)
struct __attribute__ ((visibility ("default"))) nsINIParser
{
static void Init();
};
__attribute__ ((visibility ("default")))
void
CheckCompatibility(void)
{
nsINIParser::Ini
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-30 22:01 ---
3.4.x is no longer being updated, can you try 4.0.x or 4.1.0?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-03-30 22:04
---
Can someone confirm this issue is now fixed on trunk? I'd then apply the patch
to 4.1 as well.
And Erik, btw, the assign_2.f90 failure is PR25765.
--
fxcoudert at gcc dot gnu dot org changed:
Wha
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-30 22:04 ---
Conditional move is not always faster.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
1 - 100 of 139 matches
Mail list logo
