H.J. Lu [EMAIL PROTECTED] writes:
On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov [EMAIL PROTECTED] wrote:
1-3 days usually because gcc community and RA reviewers are very responsive.
So I don't see a big difference in using ira-merge and trunk. I'd only
recommend to apply patch
Hans-Peter Nilsson wrote:
Date: Fri, 5 Sep 2008 14:57:00 +0200
From: Hans-Peter Nilsson [EMAIL PROTECTED]
Maybe as part of a change from target macro to target hook, with
LEGITIMATE_CONSTANT_P as a default would fit, even at this
stage?
Sorry, I mean CONSTANT_P, not
Paolo Bonzini wrote:
Hans-Peter Nilsson wrote:
Date: Fri, 5 Sep 2008 14:57:00 +0200
From: Hans-Peter Nilsson [EMAIL PROTECTED]
Maybe as part of a change from target macro to target hook, with
LEGITIMATE_CONSTANT_P as a default would fit, even at this
stage?
Sorry, I mean CONSTANT_P, not
Paolo Bonzini [EMAIL PROTECTED] writes:
Index: cse.c
===
--- cse.c (revision 134435)
+++ cse.c (working copy)
@@ -3161,10 +3161,8 @@ fold_rtx (rtx x, rtx insn)
FIXME: those ports should be fixed. */
if
I'm not sure about this bit. Couldn't [snip cse.c code]
simply be replaced by:
/* We can't simplify extension ops unless we know the
original mode. */
if ((code == ZERO_EXTEND || code == SIGN_EXTEND)
mode_arg0 == VOIDmode)
break;
new =
Paolo Bonzini [EMAIL PROTECTED] writes:
I'm not sure about this bit. Couldn't [snip cse.c code]
simply be replaced by:
/* We can't simplify extension ops unless we know the
original mode. */
if ((code == ZERO_EXTEND || code == SIGN_EXTEND)
mode_arg0 == VOIDmode)
2008/9/6 Christopher Faylor [EMAIL PROTECTED]:
--- svn:log (original)
+++ svn:log Fri Sep 5 14:39:56 2008
@@ -1,19740 +1,1 @@
-Merged revisions
136194,136196,136200,136209,136215-136217,136221-136222,1=
if plus_constant _knows_ that something can be wrapped in a CONST,
simplify_binary_operation should have given us the CONST to begin with.
Also, the only cases that plus_constant can handle are CONST,
SYMBOL_REF and LABEL_REF, all of which satisfy CONSTANT_P.
So the new form ought to be dead
Date: Sat, 06 Sep 2008 12:50:18 +0200
From: Paolo Bonzini [EMAIL PROTECTED]
Still, having a new target hook for this seems overkill.
But it's better than abusing an old macro with a slightly
different use.
For example,
since ports do have to deal with complicated constants when they
In case of cris, the predicate goes into general_operand, which does
if (CONSTANT_P (op))
return ((GET_MODE (op) == VOIDmode || GET_MODE (op) == mode
|| mode == VOIDmode)
(! flag_pic || LEGITIMATE_PIC_OPERAND_P (op))
LEGITIMATE_CONSTANT_P (op));
On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov [EMAIL PROTECTED] wrote:
H.J. Lu keeps ira-branch merge more fresh than trunk. But the lag is only
I won't apply any non-IRA related patches to ira-merge branch so
that you can get a fair
On Sat, Sep 6, 2008 at 12:47 AM, Richard Sandiford
[EMAIL PROTECTED] wrote:
H.J. Lu [EMAIL PROTECTED] writes:
On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov [EMAIL PROTECTED] wrote:
1-3 days usually because gcc community and RA reviewers are very responsive.
So I don't see a big difference
On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado [EMAIL PROTECTED] wrote:
On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov [EMAIL PROTECTED] wrote:
H.J. Lu keeps ira-branch merge more fresh than trunk. But the lag is only
I won't apply any
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 2:57 PM, Andreas Tobler [EMAIL PROTECTED] wrote:
H.J. Lu wrote:
It is a temporary branch, branches/ira-merge, to track
IRA related problems.
Same issue.
Does trunk bootstrap with revision 139589?
No, gcc version 4.4.0 20080905 (experimental) [trunk
On Sat, Sep 6, 2008 at 8:30 AM, Andreas Tobler [EMAIL PROTECTED] wrote:
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 2:57 PM, Andreas Tobler [EMAIL PROTECTED]
wrote:
H.J. Lu wrote:
It is a temporary branch, branches/ira-merge, to track
IRA related problems.
Same issue.
Does trunk bootstrap
On Sat, 6 Sep 2008, Manuel López-Ibáñez wrote:
Well, that is a property change and it is surprising that the log
shows the diff of the change. Normally logs only show what has been
changed but not the diff. Neither John, nor I expected this behaviour.
Changes to *revision* properties
On Sat, 2008-09-06 at 07:49 -0700, H.J. Lu wrote:
On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado [EMAIL PROTECTED] wrote:
On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov [EMAIL PROTECTED]
wrote:
H.J. Lu keeps ira-branch merge more
On Sat, Sep 6, 2008 at 11:24 AM, Luis Machado
[EMAIL PROTECTED] wrote:
On Sat, 2008-09-06 at 07:49 -0700, H.J. Lu wrote:
On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado [EMAIL PROTECTED] wrote:
On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
On Fri, Sep 5, 2008 at 10:24 AM, Vladimir
H.J. Lu wrote:
On Sat, Sep 6, 2008 at 11:24 AM, Luis Machado
[EMAIL PROTECTED] wrote:
On Sat, 2008-09-06 at 07:49 -0700, H.J. Lu wrote:
On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado [EMAIL PROTECTED] wrote:
On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
On Fri, Sep
Feel free to edit the hook scripts to do this.
On Sat, Sep 6, 2008 at 1:26 PM, Joseph S. Myers [EMAIL PROTECTED] wrote:
On Sat, 6 Sep 2008, Manuel López-Ibáñez wrote:
Well, that is a property change and it is surprising that the log
shows the diff of the change. Normally logs only show what
--- Comment #11 from hjl dot tools at gmail dot com 2008-09-06 06:14
---
Revision 139826 is good. Revision 139827 is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
With current trunk (revision 140055):
(gdb) run -quiet -O3 ~/libimager-perl-fills.i
Starting program: /home/tbm/tmp/gcc/4.3-2008-09-06-r140055/gcc/cc1 -quiet -O3
~/libimager-perl-fills.i
Program received signal SIGSEGV, Segmentation fault.
verify_ssa (check_modified_stmt=1 '\001') at
--- Comment #1 from tbm at cyrius dot com 2008-09-06 08:44 ---
Created an attachment (id=16240)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16240action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37392
--- Comment #2 from tbm at cyrius dot com 2008-09-06 08:45 ---
Created an attachment (id=16241)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16241action=view)
Slightly reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37392
With current trunk (r140055):
(sid)1470:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2
qtpfsgui-commandline.ii
src/Common/commandline.cpp: In member function 'int
CommandLineInterfaceManager::toIntWithErrMsg(const QString)':
src/Common/commandline.cpp:490: error: EH edge 10-12 is
--- Comment #1 from tbm at cyrius dot com 2008-09-06 08:52 ---
Created an attachment (id=16242)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16242action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37393
With -O -fschedule-insns2 on current trunk (r140054):
(sid)[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -O -fschedule-insns2
pfstmo_drago03.ii
In file included from /usr/include/pfs-1.2/pfs.h:46,
from pfstmo_drago03.cpp:41:
/usr/include/pfs-1.2/array2d.h: In destructor
--- Comment #1 from tbm at cyrius dot com 2008-09-06 08:55 ---
Program received signal SIGSEGV, Segmentation fault.
0x40cf1810 in ia64_variable_issue (dump=0x203eb488,
sched_verbose=0, insn=0x22080550,
can_issue_more=15540576) at gcc/config/ia64/ia64.c:6645
--- Comment #2 from tbm at cyrius dot com 2008-09-06 08:58 ---
Created an attachment (id=16243)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16243action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37394
--- Comment #3 from tbm at cyrius dot com 2008-09-06 08:59 ---
/* Testcase by Martin Michlmayr [EMAIL PROTECTED] */
struct _Words
{
void *_M_pword;
_Words ():
_M_pword (0)
{
}
} _M_word_zero;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37394
--- Comment #9 from jv244 at cam dot ac dot uk 2008-09-06 09:09 ---
I believe this bug should be closed ? Or do you still want to add the testcase
to mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37251
--- Comment #2 from tbm at cyrius dot com 2008-09-06 10:17 ---
Created an attachment (id=16244)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16244action=view)
Slightly reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37393
With current trunk (revision 140056) I see the following bootstrap error
on mips:
/home/tbm/build/gcc-snapshot-20080906/build/./prev-gcc/xgcc
-B/home/tbm/build/gcc-snapshot-20080906/build/./prev-gcc/
-B/usr/lib/gcc-snapshot/mips-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings
--- Comment #1 from tbm at cyrius dot com 2008-09-06 11:08 ---
Configured with:
--enable-languages=c,c++ --enable-shared --with-system-zlib --disable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --disable-libssp --disable-werror
--build=mips-linux-gnu --host=mips-linux-gnu
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32913
--- Comment #16 from rsandifo at gcc dot gnu dot org 2008-09-06 11:23
---
Could you explain why max_issue() should do anything
when more_issue = 0? I'd have expected it to early-out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
--- Comment #26 from hubicka at gcc dot gnu dot org 2008-09-06 12:00
---
IRA seems to fix the remaining problem with spill in internal loop on 32bit
nicely, so we produce good scores for gzip compared to older GCC versions.
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-09-06 12:02
---
Also just noticed that offline copy of longest-match get extra move:
.L15:
movzbl 2(%eax), %edi #, tmp87
leal2(%eax), %ecx #, scan.158
movl%edi, %edx # tmp87,
--- Comment #27 from hubicka at gcc dot gnu dot org 2008-09-06 12:02
---
Also just noticed that offline copy of longest-match get extra move:
.L15:
movzbl 2(%eax), %edi #, tmp87
leal2(%eax), %ecx #, scan.158
movl%edi, %edx # tmp87,
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-09-06 12:09 ---
We eliminate functions, but we never re-scan program to see if the function has
no longer address taken.
To implement this we will need to add to cgraph list of functions/variables
taking address of each
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-09-06 12:37 ---
Hi,
the following patch fixes inlining problem:
Index: passes.c
===
--- passes.c(revision 139985)
+++ passes.c(working copy)
@@ -565,6 +565,7
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-09-06 12:56 ---
cp/lex.c:590 (copy_decl) 10176: 0.0% 0:
0.0% 578168: 0.0% 66200: 0.0% 2257
cp/lex.c:510 (build_lang_decl) 161064: 0.1% 73304:
0.0%
--- Comment #3 from vmakarov at redhat dot com 2008-09-06 13:45 ---
Function ira_emit.c::update_costs does not take into account that new allocnos
(It is very rare event. New allocnos during code emitting are created only to
break a cycle in register shuffling on the region border) got
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-09-06 13:50 ---
The frontend handling was removed in GCC-4.4 by my patches.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #45 from hubicka at gcc dot gnu dot org 2008-09-06 14:12
---
Memory footprint in TOP is about 430MB (64bit machine).
On current mainline we need 191MB before IPA. Top consumers
cfg.c:226 (connect_dest) 598696: 0.2% 180224:
0.5%3484960:
--- Comment #3 from doko at ubuntu dot com 2008-09-06 14:18 ---
So I don't know what else to say
mark as duplicate of PR 323?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37390
./xsinfo ../../sinfo.h
make[5]: *** [ada/sinfo.h] Error 134
make[5]: *** Waiting for unfinished jobs
make[5]: Leaving directory `/build/buildd/gcc-snapshot-20080906/build/gcc'
make[4]: *** [all-stage2-gcc] Error 2
make[4]: Leaving directory `/build/buildd/gcc-snapshot-20080906
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-06 15:12 ---
Subject: Bug 33229
Author: burnus
Date: Sat Sep 6 15:11:29 2008
New Revision: 140061
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140061
Log:
2008-09-06 Steven G. Kargl [EMAIL PROTECTED]
PR
--- Comment #28 from ubizjak at gmail dot com 2008-09-06 15:26 ---
(In reply to comment #27)
Also just noticed that offline copy of longest-match get extra move:
.L15:
movzbl 2(%eax), %edi #, tmp87
leal2(%eax), %ecx #, scan.158
movl%edi, %edx
--- Comment #4 from burnus at gcc dot gnu dot org 2008-09-06 15:29 ---
Subject: Bug 36153
Author: burnus
Date: Sat Sep 6 15:27:50 2008
New Revision: 140063
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140063
Log:
2008-09-06 Steven G. Kargl [EMAIL PROTECTED]
PR
On Core 2, I am using gcc 4.4 revision 139589 as baseline.
On 64bit, I compare
O2: -O2 -ffast-math
O3: -O3 -ffast-math -funroll-loops
On 32bit, I compare
O2: -O2 -msse2 -mfpmath=sse -ffast-math
O3: -O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops
--
Summary: IRA performance
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-06 15:49 ---
ira-merge banch at revision 140034 against trunk at revision 139589:
32bit O3 IRA against baseline
164.gzip 0.344353%
175.vpr -2.90615%
176.gcc
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-06 15:55 ---
FIXED on the trunk (4.4.0)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2008-09-06 15:56 ---
FIXED on the trunk (4.4.0)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2008-09-06 15:57 ---
(In reply to comment #9)
I am concerned about those *Yi/*Ym and r pairs:
IRA is much more sensitive to * constraint. We can ignore *Ym/r pairs.
But should we remove * from *Yi/r pairs?
This approach was used to keep
--- Comment #30 from ubizjak at gmail dot com 2008-09-06 16:11 ---
Current mainline (4.4.0 20080906) produces:
pushl %ebx
movl8(%ebp), %eax
movl16(%ebp), %edx
movl20(%ebp), %ecx
movl12(%ebp), %ebx
imull %eax, %ecx
--- Comment #19 from ubizjak at gmail dot com 2008-09-06 16:18 ---
Exact duplicate of PR 17236. Mainline gcc (4.4.0 20080906, IRA) generates:
pushl %ebx
movl8(%esp), %eax
movl16(%esp), %edx
movl20(%esp), %ecx
movl12(%esp), %ebx
--- Comment #31 from ubizjak at gmail dot com 2008-09-06 16:18 ---
*** Bug 6585 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
--- Comment #12 from ubizjak at gmail dot com 2008-09-06 16:25 ---
(In reply to comment #11)
of RA. Maybe this pass can even be enhanced a bit to fix PR 19389?
Eh, PR 19398.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
--- Comment #21 from ubizjak at gmail dot com 2008-09-06 16:29 ---
IMO, this enhancement request can be closed now that 4.3 is released.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2008-09-06 16:33 ---
gcc (4.4.0 20080906) still generates:
cmpl%esi, %edi
sete%al
cmpl%esi, %edi
setl%dl
orl %edx, %eax
movzbl %al, %eax
ret
--
http
--- Comment #4 from hjl at gcc dot gnu dot org 2008-09-06 16:46 ---
Subject: Bug 37333
Author: hjl
Date: Sat Sep 6 16:44:56 2008
New Revision: 140066
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140066
Log:
2008-09-06 Vladimir Makarov [EMAIL PROTECTED]
PR
--- Comment #13 from hjl dot tools at gmail dot com 2008-09-06 16:49
---
Vladimir, I will re-enable regmove on ira-merge branch to see its
impact on compile time as well as SPEC CPU 2K/2006.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
Following the fix of pr35837 by Daniel Kraft (thanks for it) I found that it
also fixed a reject-valid bug for the comment #1 in pr29389. In the process
this uncovered an accept-invalid bug as shown by the following modification of
gfortran.dg/stfunc_6.f90:
! { dg-do compile }
! Tests the fix for
--- Comment #10 from dominiq at lps dot ens dot fr 2008-09-06 16:58 ---
Note that before the patch for pr35837, the code in comment #1 was wrongly
rejected. This is now fixed by this patch. Also if the FORALL statement is this
code is uncommented, it is now accepted while it is invalid,
--- Comment #4 from hjl dot tools at gmail dot com 2008-09-06 17:07 ---
The problem is IA64 has
void
ia64_optimization_options (int level ATTRIBUTE_UNUSED,
int size ATTRIBUTE_UNUSED)
{
/* Disable the second machine independent scheduling pass and use one
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-09-06 17:11
---
Subject: Bug 14703
Author: hubicka
Date: Sat Sep 6 17:10:00 2008
New Revision: 140068
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140068
Log:
PR tree-optimization/14703
* tree-ssa-live.c
--- Comment #4 from niklaus at gmail dot com 2008-09-06 17:42 ---
On the below version of gcc on cygwin (winXP SP3) i don't have any problems
with optimization on or off. They produce consistent correct result. Why is it
a problem with linux ? or am i doing something wrong.
I tried
--- Comment #2 from daney at gcc dot gnu dot org 2008-09-06 17:50 ---
140035 seems OK:
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00503.html
I am now trying 140069.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37395
Sent from my iPhone
On Sep 6, 2008, at 10:42, niklaus at gmail dot com [EMAIL PROTECTED]
wrote:
--- Comment #4 from niklaus at gmail dot com 2008-09-06 17:42
---
On the below version of gcc on cygwin (winXP SP3) i don't have any
problems
with optimization on or off. They
--- Comment #5 from pinskia at gmail dot com 2008-09-06 17:56 ---
Subject: Re: wrong-code on i486-linux-gnu with -O[12], -O0 works
Sent from my iPhone
On Sep 6, 2008, at 10:42, niklaus at gmail dot com [EMAIL PROTECTED]
wrote:
--- Comment #4 from niklaus at gmail dot com
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-06 18:01 ---
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #122 from pinskia at gcc dot gnu dot org 2008-09-06 18:01
---
*** Bug 37390 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2008-09-06 18:02 ---
(In reply to comment #2)
CONFIRM.
Paul, as out module.c expert, do you have an idea how to solve this?
Yes, I have a fix - see the list, either tonight or tomorrow.
Cheers
Paul
--
pault at gcc dot gnu dot
On Linux/ia32, revision 140065 gave
FAIL: gfortran.dg/size_kind.f90 -O (test for excess errors)
--
Summary: gfortran.dg/size_kind.f90 doesn't work
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #1 from sgk at troutmask dot apl dot washington dot edu
2008-09-06 18:14 ---
Subject: Re: New: gfortran.dg/size_kind.f90 doesn't work
On Sat, Sep 06, 2008 at 06:10:58PM -, hjl dot tools at gmail dot com wrote:
On Linux/ia32, revision 140065 gave
FAIL:
--- Comment #1 from burnus at gcc dot gnu dot org 2008-09-06 18:15 ---
The problem seems to be that impure_stmt_fcn for st3 never checks v.
If I add some printfs, I see that impure_stmt_fcn is called twice with
sym-name == st3; once with e-symtree-n.sym = st3 and once with
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-06 18:28 ---
Subject: Bug 37399
Author: burnus
Date: Sat Sep 6 18:27:17 2008
New Revision: 140070
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140070
Log:
2008-09-06 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #7 from niklaus at gmail dot com 2008-09-06 18:28 ---
(In reply to comment #5)
Subject: Re: wrong-code on i486-linux-gnu with -O[12], -O0 works
Because on x86 gnu/Linux, the precision is set to 80bits rather than
64bit like it is on windows.
Does increasing bits
--- Comment #2 from kargl at gcc dot gnu dot org 2008-09-06 18:16 ---
Remove myself from CC list.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Extracted form
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c553e0034bab977c
(see pr34199) the following code:
module mod
implicit character(len=*,kind=kind('A')) (Q)
parameter(Q1 = 'Test Me!')
parameter(Q2 = 'Test Me Too!')
contains
subroutine
--- Comment #8 from vincent at vinc17 dot org 2008-09-06 18:42 ---
(In reply to comment #7)
Does increasing bits cause floating point errors. How could 64 bit precison
give correct result where as 80 bit give incorrect one.
You can have rounding errors whether you increase the
--- Comment #7 from dominiq at lps dot ens dot fr 2008-09-06 19:12 ---
Extracted from
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c553e0034bab977c
the following code
module bug1
use ISO_C_BINDING
implicit none
contains
subroutine sub1(x)
--- Comment #8 from dominiq at lps dot ens dot fr 2008-09-06 19:14 ---
Extracted from
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c553e0034bab977c
the following code
module bug1
use ISO_C_BINDING
implicit none
contains
subroutine sub1(x)
--- Comment #4 from burnus at gcc dot gnu dot org 2008-09-06 19:53 ---
Close as FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-09-06 20:23
---
The code quality problems are solved. Not closing the bug until IPA-reference
is fixed.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14703
--- Comment #9 from brian at dessent dot net 2008-09-06 20:31 ---
Subject: Re: wrong-code on i486-linux-gnu with -O[12], -O0
works
pinskia at gmail dot com wrote:
Because on x86 gnu/Linux, the precision is set to 80bits rather than
64bit like it is on windows.
That is only true
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-06 21:04 ---
Reduced testcase:
struct __attribute__((visibility(default))) QString {
inline ~QString();
bool isEmpty() const;
};
extern C {
extern void __error_noreturn (__const char *__format, ...) __asm__ (
error)
--- Comment #9 from dominiq at lps dot ens dot fr 2008-09-06 21:16 ---
Extracted from
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c553e0034bab977c
the following code
program bug2_transfer
use ISO_C_BINDING
implicit none
type(C_PTR) C_NULL_PTR1
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-06 21:19 ---
Reducing further.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37332
--- Comment #10 from niklaus at gmail dot com 2008-09-06 21:23 ---
(In reply to comment #8)
(In reply to comment #7)
Does increasing bits cause floating point errors. How could 64 bit precison
give correct result where as 80 bit give incorrect one.
You can have rounding errors
Compiling some of the LAPACK source code under -O1 or greater with the 64 bit
version of GNU Fortran 4.4.0 fails badly (whereas its peer 32 bit build does
not exhibit the problem).
The Windows build of gfortran is current from
http://gcc.gnu.org/wiki/GFortranBinaries as of Sep 6, 2008:
--- Comment #1 from vz-gcc at zeitlins dot org 2008-09-06 21:27 ---
I found this bug while searching for __thread-related problems and FWIW I can't
reproduce this on a very similar system with g++ 4.1.2 from Debian stable so
maybe this can be closed as fixed.
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-06 21:32 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-06 21:32 ---
*** This bug has been marked as a duplicate of 37343 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-06 21:32 ---
*** Bug 37332 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-06 21:39 ---
This code is invalid and is caused by changing C99/GNU99 extern inline to be
correct to what C99 says.
We have:
extern ssize_t pread (int __fd, void *__buf, size_t __nbytes, __off64_t
__offset) __asm__ ( pread64)
--
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
|
1 - 100 of 133 matches
Mail list logo
