On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/2/07, Paul Brook [EMAIL PROTECTED] wrote:
That said, second, my understanding of restrict, from reading the c99
standard, is that it is perfectly valid for restrict pointers to alias
each other during *loads*.. IE you can
Matt,
I just started working on pipeline description and I'm confused one thing in
your description.
For integer, your cpu have a 1-cycle latency, but with 3 units stages
issue,iu,wb. What does that mean? My understanding is that the number of
units seperated by , should be equal to latency.
On Sun, 2 Sep 2007, Mark Mitchell wrote:
Daniel Berlin wrote:
Again, I'd love to just ignore this and say we don't care.
Ugh. I think you're right that the standard says that we only get to
assume non-aliasing when the pointed-to memory is modified, so
all-parameters-restrict is
Matt Lee wrote:
Hi,
I am working with GCC-4.1.1 on a simple 5-pipe stage simple scalar
RISC processors with the following description for loads and stores,
(define_insn_reservation integer 1
(eq_attr type branch,jump,call,arith,darith,icmp,nop)
issue,iu,wb)
(define_insn_reservation load 3
Zdenek's patch here -
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02291.html - solved the
problem.
Kenny, Zdenek - many thanks for solving this issue!
dorit
Seongbae Park (박성배, 朴成培) [EMAIL PROTECTED] wrote on
29/08/2007 01:01:42:
On 8/28/07, Zdenek Dvorak [EMAIL PROTECTED] wrote:
...
We set has_volatile_ops on all(?) memory references during early
optimization because we don't have alias information. But we
do it inconsistently for loads. For example I see
D.2574_23 = *D.2573_22;
(no volatile) and
D.2565_28 ={v} tab[D.2560_27].__delta;
(volatile). Because for
Hi, I am working on gcc-4.1.1 and Itanium architecture. Current now I
have finished instrumenting ld and st instructions before the second
scheduling pass by reserving two global registers at backend. However,
in order to enhance the performance (e.g. make the scheduling better),
I choose to
Joseph S. Myers wrote:
The rules that unmodified memory may alias were a deliberate change in the
FDIS relative to the previous public draft; see
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n866.htm:
That explains why I had no memory of this, despite having researched
restrict pretty
In any case, I guess we should consider my patch withdrawn. Although,
if the new meaning of restrict matches standard Fortran semantics,
then our Fortran handling must be wrong, since all my patch did was make
us match our current Fortran semantics.
In Fortran the pointers are not exposed at
Mark Mitchell wrote:
Joseph S. Myers wrote:
The rules that unmodified memory may alias were a deliberate change in the
FDIS relative to the previous public draft; see
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n866.htm:
That explains why I had no memory of this, despite having
On 9/3/07, Richard Guenther [EMAIL PROTECTED] wrote:
On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/2/07, Paul Brook [EMAIL PROTECTED] wrote:
That said, second, my understanding of restrict, from reading the c99
standard, is that it is perfectly valid for restrict pointers to
On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/3/07, Richard Guenther [EMAIL PROTECTED] wrote:
On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/2/07, Paul Brook [EMAIL PROTECTED] wrote:
That said, second, my understanding of restrict, from reading the
c99
Snapshot gcc-4.1-20070903 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070903/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
gfortran 4.1.2/4.2.0/4.3.0 segfaults when compiling the following program:
program initbug
integer,parameter :: n0 = 3, n = 5
real(kind=8),parameter :: x0(n0) = (/ 0.0d0, 0.0d0, 0.0d0 /)
real(kind=8),parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) /) + 1.0d0
end program initbug
Valgrind
--- Comment #1 from dominiq at lps dot ens dot fr 2007-09-03 07:39 ---
I don't see the ICE on PPC Darwin8, revision 128037, but the following modifed
code gives a wrong answer:
program initbug
integer,parameter :: n0 = 3, n = 5
real(kind=8),parameter :: x0(n0) = (/ 2.0d0,
typedef __SIZE_TYPE__ size_t;
extern C int __sprintf_chk (char *__restrict, int, size_t, const char *, ...)
throw ();
extern C int __sprintf_chk (char *__restrict, int, size_t, const char *, ...)
throw ();
fails to compile with:
/tmp/4.C:3: error: declaration of 'int __sprintf_chk(char*, int,
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-03 09:34 ---
I don't see the ICE on PPC Darwin8, revision 128037, but the following modifed
code gives a wrong answer:
For me (4.3.0 20070903, r128037, x86_64-unknown-linux-gnu) both examples cause
a segmentation fault
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-03 09:43 ---
If I try to regtestify the code (uncomment the commented line):
program initbug
integer,parameter :: n0 = 3, n = 5
real(kind=8),parameter :: x0(n0) = (/ 2.0d0, 2.0d0, 2.0d0 /)
real(kind=8),parameter
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:04
---
(In reply to comment #3)
A) I see that you and others put a number of patches and regenerations. Do you
want me to rebootstrap and then do it?
I don't think we've touched anything who should affect this since
--- Comment #5 from joerg dot richter at gedas dot de 2007-09-03 10:05
---
Subject: AW: [SPAM Verdacht] - gfortran 4.3.0 doesn't
work on Windows Vista. - Bayesian Filter detected spam
Dear Sir,
I am sending You the output generated by gfortran 4.3.0 (Version
20070813)using
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-03 10:12 ---
The following does not ICE for me and produces the right result (note the extra
+0.0):
real,parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) + 0.0 /) +1.0
analogously for (note extra (...)):
real,parameter ::
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:25
---
The output you posted shows that you have gfortran-4.3.0 in your path but you
also have a f951 binary coming from a G95 installation (it says: G95 Fortran
95 version 4.0.3 (g95 0.90!) Jul 27 2006). What happens
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:40
---
(In reply to comment #0)
I'm trying to run gfortran under Windows Vista.
Do you compile yourself or use pre-made binaries (and which binaries)? What
version of gfortran do you use? If you build the compiler
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:42
---
Unless this is a regression, won't be fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:44
---
The Fortran part has its PR, I saw a PR for some C problem also, so I'm closing
this. If other you experience other powerpc regressions, please open new PRs.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #5 from dominiq at lps dot ens dot fr 2007-09-03 11:01 ---
I confirm that
program initbug
integer,parameter :: n0 = 3, n = 5
real(kind=8),parameter :: x0(n0) = (/ 2.0d0, 2.0d0, 2.0d0 /)
real(kind=8),parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) + 0.0d0 /) + 1.0d0
+++ This bug was initially created as a clone of Bug #33283 +++
[18:22] apinski
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:5:
error: could not split insn^M
[18:22] apinski new failure
[18:23] apinski on ppc-linux-gnu
[18:23] apinski between 127935 and 128000
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-03 11:17 ---
Closing as offtopic stuff was added again.
Maybe I should mention something about 4.2.x, gentoo also decided to use it :).
And it is not a bad release, 4.2.1 is much better. If glibc does not build
with 4.2.1,
I triggered this is the inner loop of the CPU emulation code of openMSX
(http://openmsx.sf.net/). I tried to reduce the code. Below is the smallest
code I could come with up that still shows the problem:
---
struct Clock {
void f();
void add(unsigned n) {
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-03 11:28 ---
# VUSE tab_56, SMT.9_58, SMT.10_60
D.2581_35 = this_2(D)-D.2503.a;
D.2582_36 = (unsigned int) D.2581_35;
D.2583_37 = D.2582_36 + 2;
D.2584_38 = (int) D.2583_37;
# tab_76 = VDEF tab_56
# SMT.9_77 = VDEF
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-03 11:31
---
(In reply to comment #4)
Seemingly, the array range x0(n0-1:1:-1) does not get properly simplified and
thus -value.real points to the nirvana.
Nope. I get an ICE for the following testcase:
real, parameter
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-03 12:01 ---
The problem is that forwprop doesn't propagate addr_exprs to memory reference
stmts in early optimization anymore (due to the volatile issues) and
value numbering cannot deal with the different (but same)
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-09-03 12:04
---
Created an attachment (id=14152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14152action=view)
Proposed patch
It was indeed my fault, sorry. When doing a 32x32-64 multiplication,
CONST_INTs are
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-03 12:04 ---
That is, rtl level DSE removes the dead store:
_ZN3CPU7executeEv:
.LFB5:
pushq %rbx
.LCFI0:
movq%rdi, %rbx
leaq8(%rdi), %rdi
call_ZN5Clock1fEv
.p2align 4,,10
--- Comment #7 from pcarlini at suse dot de 2007-09-03 12:09 ---
Fixing the second ICE.
--
pcarlini at suse dot de changed:
What|Removed |Added
the optimizer skips a function call that should not be skipped.
--
Summary: optimizer optimizes out a piece of code
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
--- Comment #1 from nicolas at dyalog dot com 2007-09-03 12:26 ---
Created an attachment (id=14153)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14153action=view)
preprocessed source of a repro
Sorry guys the repro is a bit complicated but i could NOT narrow it down any
further.
--- Comment #2 from andreast at gcc dot gnu dot org 2007-09-03 13:05
---
Looks ok on PowerPC Darwin. 16 passes. I tested on top of 128028.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-03 13:10 ---
The test case works:
[karma] gcc/darwin_buildw% ../gcc4.3w/bin/gcc -O
../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c
../gcc-4.3-work/gcc/testsuite/gcc.c-torture/execute/930921-1.c: In function
--- Comment #3 from chrbr at gcc dot gnu dot org 2007-09-03 13:24 ---
this report is quite old, but worth to pop :
We found similar problems with implicit memory block copying when using struct
copying by value. (frequent in C++ )
Softfloat architectures making a very extensive use of
--- Comment #8 from jakub at gcc dot gnu dot org 2007-09-03 13:43 ---
It is not bogus. -fprofile-arcs is one way of introducing .ctors stuff.
When building crtstuff, if it is supposed to work, you must avoid all options
that generate such stuff, whether it is -fprofile-arcs,
--- Comment #5 from michelin60 at gmail dot com 2007-09-03 13:49 ---
(gcc a.c -lm -W -Wall; try with -O0 and -O1, I expect it will fail only at
-O0).
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does
--- Comment #2 from nicolas at dyalog dot com 2007-09-03 14:07 ---
after a bit more work it seems optimized out because diff64() doesn't observe
strict aliasing...
that was tricky because it was not the diff64() code that was snipped out but
TimeValToFileTime()...
I think the compiler
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-03 14:09
---
(In reply to comment #5)
Let me start off by saying that today is a holiday and that tomoorow I am back
at work and traveling, I am not allowed to use __any__ business assets for GCC
connected activity.
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-03 14:11
---
And please stop CCing people! I'm taking care of this bug, and there really is
no need to bother other people by sending them copies of all
comments/investigation we exchange on the issue.
--
fxcoudert at gcc
--- Comment #8 from burnus at gcc dot gnu dot org 2007-09-03 14:25 ---
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND,
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-03 14:36 ---
I have a patch that makes it work apart from the tree level DSE issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #119 from rguenth at gcc dot gnu dot org 2007-09-03 15:20
---
*** Bug 33292 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-03 15:20 ---
The cast to (void *) disables the alias warning. This was done on purpose, so
it's unfortunate that this in some cases makes debugging harder.
*** This bug has been marked as a duplicate of 21920 ***
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0
Known to work||4.2.1
# of expected failures 169
# of untested testcases 35
# of unsupported tests 412
/opt/gcc/darwin_buildw/gcc/xgcc version 4.3.0 20070903 (experimental) (GCC)
That's the normal unexpected failures/successes on Darwin8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33290
--- Comment #5 from rsandifo at gcc dot gnu dot org 2007-09-03 15:36
---
Subject: Bug 33290
Author: rsandifo
Date: Mon Sep 3 15:35:52 2007
New Revision: 128048
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128048
Log:
gcc/
PR middle-end/33290
* optabs.c
--- Comment #6 from rsandifo at gcc dot gnu dot org 2007-09-03 15:36
---
Thanks to Andreas and Dominique for the testing. Now applied to 4.3.
Sorry to everyone for the breakage.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from mec at google dot com 2007-09-03 15:47 ---
DR 354 has been in state WP since October 2005. Is that good enough to
unsuspend this issue?
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#354
--
mec at google dot com changed:
What
--- Comment #4 from nicolas at dyalog dot com 2007-09-03 16:08 ---
That's what I feared I have lots of those in my code...
Thanks for the quick reply anyway =)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-03 16:24 ---
I see.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2007-09-03 16:35 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-03 16:44
---
Subject: Bug 31675
Author: fxcoudert
Date: Mon Sep 3 16:44:15 2007
New Revision: 128050
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128050
Log:
PR fortran/31675
* libgfortran.h: New
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-03 16:47
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
I use std::inner_product() to do the vector multiplication when performing
matrix multiplication. This involves calling std::inner_product() within 2
nested loops (one across all rows, one across all columns). Unfortunately,
g++-4.1.2 will not, it seems, inline the call even at -O5. If I
--- Comment #2 from simon dot marshall at misys dot com 2007-09-03 16:54
---
This is also true of 4.2.1. Sorry if I have missed something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31955
--- Comment #1 from pcarlini at suse dot de 2007-09-03 17:20 ---
Note, in GCC any -Ox, x 3 is identical to -O3.
Anyway, I think we can safely add inline to std::accumulate and
std::inner_product.
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-09-03 17:29 ---
DR 354 has been in state WP since October 2005. Is that good enough to
unsuspend this issue?
Yes.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Compile with -O2 -fno-strict-aliasing, fails on amd64 and alpha at least.
Doesn't fail with -fno-tree-vrp. Seems to be related to bug 32575. Breaks
linux kernel in many places (this asm is used with prefetch instruction).
struct T { void *p; } *t;
int main (void)
{
struct T *a;
a = t;
--- Comment #2 from paolo at gcc dot gnu dot org 2007-09-03 17:48 ---
Subject: Bug 33293
Author: paolo
Date: Mon Sep 3 17:48:31 2007
New Revision: 128053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128053
Log:
2007-09-03 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from pcarlini at suse dot de 2007-09-03 17:50 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
The following code produces the error
internal compiler error: in fold_convert, at fold-const.c:2626
when compiled with GCC trunk rev. 128037:
module A
type A_type
real comp
end type
end module A
module B
contains
function initA()
use A
implicit none
type(A_type)::
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-03 18:05 ---
Yes and this correct.
Though the error was wrong.
On the trunk we get:
t.cc:12: error: 'namespace C1 { }' redeclared as different kind of symbol
t.cc:2: error: previous declaration of 'class C1'
--
--- Comment #1 from jaydub66 at gmail dot com 2007-09-03 18:05 ---
The error is also killed by
A_var = initA()
Sorry. The error is killed by *removing* this line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
--- Comment #2 from fang at csl dot cornell dot edu 2007-09-03 18:11
---
Subject: Re: namespace hides class definition
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-03 18:05
---
Yes and this correct.
Though the error was wrong.
On the trunk we get:
--- Comment #1 from belyshev at depni dot sinp dot msu dot ru 2007-09-03
18:13 ---
This bug is invalid because asm() does NULL pointer dereference, thus
triggering undefined behavior.
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed
--- Comment #3 from ilgb at livius dot net 2007-09-03 18:15 ---
it looks we are talking about different bugs, the error I get is different:
../src/a.cpp:26: error: 'C1' does not name a type
where the line 26 is the following:
C1 c;
--
--- Comment #4 from fang at csl dot cornell dot edu 2007-09-03 18:19
---
Subject: Re: namespace hides class definition
--- Comment #3 from ilgb at livius dot net 2007-09-03 18:15 ---
it looks we are talking about different bugs, the error I get is different:
--- Comment #4 from patchapp at dberlin dot org 2007-09-03 19:05 ---
Subject: Bug number PR33253
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/2007-09/msg00153.html
--
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-09-03 19:27
---
Subject: Bug 33253
Author: jvdelisle
Date: Mon Sep 3 19:27:48 2007
New Revision: 128056
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128056
Log:
2007-09-03 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-09-03 19:29
---
Subject: Bug 33253
Author: jvdelisle
Date: Mon Sep 3 19:29:17 2007
New Revision: 128057
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128057
Log:
2007-09-03 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-09-03 19:32
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from ubizjak at gmail dot com 2007-09-03 20:07 ---
Confirmed on x86_64 (-O0), RECORD_TYPE is entering fold_convert() from
gfc_trans_scalar_assign():
(gdb) bt
#0 fancy_abort (file=0xb322f0 ../../gcc-svn/trunk/gcc/fold-const.c,
line=2626,
function=0xb321d2
--- Comment #2 from aesok at gcc dot gnu dot org 2007-09-03 20:35 ---
Subject: Bug 28902
Author: aesok
Date: Mon Sep 3 20:35:10 2007
New Revision: 128059
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128059
Log:
PR target/28902
* config/avr/avr.h
--- Comment #3 from aesok at gcc dot gnu dot org 2007-09-03 21:04 ---
Subject: Bug 28902
Author: aesok
Date: Mon Sep 3 21:03:50 2007
New Revision: 128060
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128060
Log:
PR target/28902
* config/avr/avr.h
--- Comment #6 from eweddington at cso dot atmel dot com 2007-09-04 03:37
---
(In reply to comment #5)
Patch to document AVR progmem attribute:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01832.html
Now committed:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00159.html
This bug
--- Comment #13 from eweddington at cso dot atmel dot com 2007-09-04 03:46
---
Seems to be fixed in 4.2.1, at least. I haven't tried earlier releases.
Changing target milestone and closing bug.
--
eweddington at cso dot atmel dot com changed:
What|Removed
--- Comment #5 from eweddington at cso dot atmel dot com 2007-09-04 04:02
---
(In reply to comment #1)
Yes and this correct.
Andrew,
Are you saying that this bug is invalid? If so, then it needs to be closed as
such.
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33287
-__cxa_atexit --disable-jvmpi
Thread model: posix
gcc version 4.3.0 20070903 (experimental) [trunk revision 128061] (GCC)
COLLECT_GCC_OPTIONS='-B/home/ddaney/gccsvn/trunk-build/gcc/' '-v' '-S'
'-mabi=64' '-msym32' '-mno-abicalls' '-O2' '-march=sb1' '-mno-shared'
/home/ddaney/gccsvn/trunk-build/gcc
--- Comment #6 from daney at gcc dot gnu dot org 2007-09-04 04:27 ---
OK I can reproduce with my mips64-linux cross compiler. I wonder if it is
big-endian related...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-09-04 04:47
---
Found the problem. I will submit the update patch against this PR
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-09-04 04:49
---
Changed title to reflect what this is, not really a regression at this point.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from dominiq at lps dot ens dot fr 2007-09-04 04:58 ---
Did you also have a look to the other problem:
print *, nearest(huge(1.0),1.0), nearest(-huge(1.0),-1.0), nearest(huge(1.0d0)
1
Error: Result of NEAREST overflows its kind at (1)
?
--
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-09-04 05:39
---
Yes, I also checked the huge testcase and its all clean now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
--- Comment #16 from patchapp at dberlin dot org 2007-09-04 05:40 ---
Subject: Bug number PR33225
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/2007-09/msg00176.html
--
The following code:
real x
x = nearest(huge(1.0),1.0)
end
gives
x = nearest(huge(1.0),1.0)
1
Error: Result of NEAREST overflows its kind at (1)
instead of setting x to +Inf. This bug is also present in GNU F95 version
4.2.1.
--
Summary: nearest(huge(1.0),1.0) gives an
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2007-09-04 05:44
---
Dominique: The problem in comment 14 is not fixed and I do not think its
related. I will check further though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
--- Comment #7 from daney at gcc dot gnu dot org 2007-09-04 05:46 ---
Here is what is happening:
The value of avenrun[0] is being passed to a function that takes an 32 bit int
parameter. Since avenrun is an array of 64 bit unsigned long, the conversion
to int can be done by loading an
--- Comment #18 from dominiq at lps dot ens dot fr 2007-09-04 05:47 ---
I do not think its related.
I just realized that and I filled PR33296.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
100 matches
Mail list logo
