--- Comment #5 from jakub at gcc dot gnu dot org 2006-10-02 06:11 ---
Subject: Bug 29154
Author: jakub
Date: Mon Oct 2 06:11:49 2006
New Revision: 117366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117366
Log:
PR c/29154
* gimplify.c (gimplify_self_mod_expr):
--- Comment #6 from jakub at gcc dot gnu dot org 2006-10-02 06:23 ---
Subject: Bug 29154
Author: jakub
Date: Mon Oct 2 06:23:48 2006
New Revision: 117367
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117367
Log:
PR c/29154
* gimplify.c (gimplify_self_mod_expr):
--
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 #1 from ebotcazou at gcc dot gnu dot org 2006-10-02 06:37
---
With mainline:
poog% gcc/xgcc -Bgcc -c pr29314.c -mvis -mcpu=ultrasparc -O2
/usr/ccs/bin/as: /var/tmp//ccPi3BER.s, line 12: error: invalid (misaligned)
register
/usr/ccs/bin/as: /var/tmp//ccPi3BER.s, line 14:
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:10
---
Patch submitted here: http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:11
---
Patch submitted here: http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from sfilippone at uniroma2 dot it 2006-10-02 07:21 ---
For the record: my test application runs to completion with good results
snapshot 20060930 + alloc_comps0929.diff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-02 07:31 ---
Hmm, the sizeof expression causes use to create the expression:
(cast)NON_LVALUE_EXPRSAVE_EXPR(cast)(w)*4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29226
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:34
---
I'll do it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-02 07:39
---
Further reduced testcase (no need for a module):
implicit none
integer i
i = len(123)
call sub(len)
end
When the len in call sub(len) is resolved, it is never given its correct
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-10-02
08:09 ---
(In reply to comment #2)
Confirmed, we don't set the stride correctly as far as I can tell.
This comes about because of the admitted kludge in the mechanism for passing
components of derived type
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-02 08:11
---
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (revision 116798)
+++ gcc/fortran/primary.c (working copy)
@@ -1084,6
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:21
---
Subject: Bug 29210
Author: fxcoudert
Date: Mon Oct 2 09:21:45 2006
New Revision: 117368
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117368
Log:
PR fortran/29210
* primary.c
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.2.0 4.1.2 |4.1.2
Known to work||4.2.0
--- Comment #16 from mrs at apple dot com 2006-10-02 09:32 ---
The dynamic type of the object at i is indeed float and has the value 7.0 (iff
align and sizes work out). We permitted this so that can can do:
class C { ... };
char buf[1024];
new (buf[n]) C
and have the dynamic
gfortran.dg/exponent_1.f90 is failing at all optimization levels on
x86_64-linux (see http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00081.html).
Here is the problem:
$ cat exponent_1.f90
real, parameter :: one = 1.0
print *, exponent(one)
if (exponent(one) /= 1.0) call abort
end
$
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:37
---
Subject: Bug 18791
Author: fxcoudert
Date: Mon Oct 2 09:37:09 2006
New Revision: 117369
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117369
Log:
PR fortran/18791
*
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:38
---
Fixed on both 4.2 and 4.1
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from fxcoudert at gcc dot gnu dot org 2006-10-02 09:41
---
The only g77 intrinsic now missing to gfortran is FSEEK (and this is PR 22359).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-10-02 10:05 ---
Thanks Andrew. I agree, this is not permitted by the standard as the enclosing
class is not specialized.
What a bummer. I suppose I can work around this by making a more convoluted
inheritance chain.
This would have
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-10-02 10:06 ---
s/to/two
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29298
The following invalid code causes an ICE.
$ cat foo.cpp
#include typeinfo
int main()
{
int i = 5;
int va[i];
const std::type_info info(typeid(va));
return 0;
}
$ g++ foo.cpp
foo.cpp: In function 'int main()':
foo.cpp:7: internal compiler error: Segmentation fault
Please submit a full
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:09
---
If it's a regression wrt g77, then it's not an enhancement, it's a bug.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
This happens on the 4.1 branch, not on 4.2/trunk, but it's also latent there:
% cat large-ofs.c
static char l_info[100];
void bug1 (unsigned long tag)
{
char *info = l_info;
info[tag - 0x1 + 1] = 1;
}
void bug2 (unsigned long tag)
{
char *info = l_info;
info[tag - 0x7 + 2]
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:23
---
Confirmed and marked as an enhancement. After all, it's working :)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from matz at gcc dot gnu dot org 2006-10-02 11:24 ---
Created an attachment (id=12369)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12369action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:35
---
That one is annoying. Reduced testcase is:
FUNCTION X()
ENTRY X1
IF (X .GT. 0) CALL FOO(X)
END
The error message is:
a.f: In function master.0.x:
a.f:3: error: invalid operand to
--- Comment #2 from matz at gcc dot gnu dot org 2006-10-02 11:35 ---
Note that with this patch solves the bug for this testcase, but it still
doesn't help with the general case. With this slightly changed testcase:
% cat large-ofs2.c
static char l_info[100];
void bug1 (unsigned long
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:37
---
Closing this. We'd need a more precise definition to be able to do anything
about that, although I don't see a reason why shared libraries wouldn't work on
cygwin.
--
fxcoudert at gcc dot gnu dot org changed:
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-02 11:59
---
Confirmed, as Intel, Portland and other compilers accept this. Marked as an
enhancement, though, as g77 didn't support that anyway.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
GCC seems to have more problems with use clauses (see also bug #26529).
gcc: Internal error: Segmentation fault (program gnat1)
The compiler has been compiled from source by:
configure --prefix=/opt/gcc-4.1.1 --enable-languages=ada,c
make bootstrap
make install
The problem can be reproduced
Compilation of functions/subroutines with optional derived type arguments
gives segmentation fault.
a.F90: In function 'func':
a.F90:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html
--- Comment #4 from amacleod at redhat dot com 2006-10-02 13:56 ---
This is not something out of ssa can resolve on its own.
given this sequence:
# s_2 = PHI s_5(0), s_9(1);
# d_1 = PHI d_6(0), d_10(1);
L0:;
D.1287_8 = MEM[base: d_1];
s_9 = s_2 + D.1287_8; --- s_2 and
--- Comment #5 from amacleod at redhat dot com 2006-10-02 14:01 ---
I guess you can flatten the goto slightly.
this is still something that is not really in the scope of out of ssa. part of
the root of this problem is that the PHI is really just a copy, but the fact
that it remains a
--- Comment #6 from yuanfei8077 at gmail dot com 2006-10-02 14:19 ---
Subject: Re: Rule that binding rvalue to a refernce need a copy ctor don't
work
Thank you Andrew, appreciate your help on this topic.
-Kelvin
On 1 Oct 2006 20:33:33 -, pinskia at gcc dot gnu dot org
[EMAIL
--- Comment #1 from sgk at troutmask dot apl dot washington dot edu
2006-10-02 14:22 ---
Subject: Re: New: gfortran.dg/exponent_1.f90 failure
On Mon, Oct 02, 2006 at 09:32:55AM -, fxcoudert at gcc dot gnu dot org
wrote:
gfortran.dg/exponent_1.f90 is failing at all optimization
--- Comment #2 from Francois-Xavier dot Coudert at ens dot fr 2006-10-02
14:27 ---
Subject: Re: gfortran.dg/exponent_1.f90 failure
If you have a good mpfr, then the problem may be similar to the one
with nearest_1.f90 where the extra precision in the registers is bad
(ie., add
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-10-02
14:32 ---
(In reply to comment #1)
The problem occurs on i386-*-freebsd
Noting that adding a dummy to the first of the subroutine declarations allows
the compiler to detect that there are two subroutines of the
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2006-10-02 15:00 ---
Subject: Re: gfortran.dg/exponent_1.f90 failure
On Mon, Oct 02, 2006 at 02:27:47PM -, Francois-Xavier dot Coudert at ens
dot fr wrote:
--- Comment #2 from Francois-Xavier dot Coudert
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-02 15:15 ---
From Francois-Xavier Coudert 2006-06-08
I'm writing a patch to add substring bounds checking. I hope to post it in the
next few days.
What is the status? If you have something, I'd save my time
$ cat u.f90
if (isscan () /= 0) call abort
contains
integer function isscan (substr)
character(*), optional :: substr
if (.not.present(substr)) isscan = myscan (foo, over)
end function isscan
end
$ gfortran u.f90
u.f90: In function MAIN__:
u.f90:5: internal compiler error:
--- Comment #4 from Francois-Xavier dot Coudert at ens dot fr 2006-10-02
15:32 ---
Subject: Re: -fbounds-check should catch substring out of range accesses
I'm writing a patch to add substring bounds checking. I hope to post it in the
next few days.
Great!
What is the status? If
If a function definition is present, except.c:set_nothrow_function_flags marks
functions as nothrow depending on analysis of the function definition.
This is incorrect when the function does not bind locally (compare with
other function analysis in PR tree-optimization/27781).
--
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-10-02 16:09 ---
Created an attachment (id=12370)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12370action=view)
test case - main file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-10-02 16:10 ---
Created an attachment (id=12371)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12371action=view)
test case - actual definition of function foo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
--- Comment #7 from jconner at apple dot com 2006-10-02 16:44 ---
(In reply to comment #6)
Shouldn't this bug be marked as closed now?
Perhaps - however, it's not been fixed on the 4.0 or 4.1 branches...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25376
--- Comment #8 from kargl at gcc dot gnu dot org 2006-10-02 16:47 ---
Remove reject-valid keyword, again!
Return this to enhancement.
This is NOT a bug. g77 compatibility and the Fortran 95 standard
have a conflict, and so IMNSHO the Fortran 95 standard wins.
See comment #3. The
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 16:47 ---
Confirmed. 3.0.4 and above ICE so this is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-02 16:51 ---
(In reply to comment #7)
Perhaps - however, it's not been fixed on the 4.0 or 4.1 branches...
But this is not a regression so closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29321
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 17:04 ---
Confirmed, a regression. Looks related to PR 29284.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-10-02 17:07 ---
While except.c:set_nothrow_function_flags analyzes rtl, the DECL_NOTHROW flag
it computes is a tree bit. via calls.c:flags_from_decl_or_type -
calls.c:call_expr_flags - tree-eh.c:tree_could_throw_p makes this
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-02 17:28 ---
Confirmed, further reduced testcase:
struct StructB
{
bool val_;
};
struct ClassF
{
virtual void MetG(StructB value) = 0;
};
ClassF* MetJ ();
void MetN (StructB const x)
{
ClassF *VarI = MetJ();
VarI-MetG ( x);
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-02 17:46 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 17:47 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-10-02 17:48
---
I disagree with Mike's analysis. I certainly understand the goals of placement
new, but I don't think that anyone intended this code:
int i;
*(float *)i = 7.0;
to be valid. I don't even think people
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 17:50 ---
Confirmed, I think this is a dup of bug 29284, well it is at least related.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-02 17:51 ---
I suspect we should put the version number, or at least major.minor,
into the name. So, libgcj-4.1.pc, libgcj-4.2.pc, etc.
What do you think of this?
--
tromey at gcc dot gnu dot org changed:
What
Currently libgcj assumes it can waitpid(-1,...).
This interacts poorly with other libraries which may
want to interact with subprocesses; for instance glib
has an API for spawning and waiting for children, and
frysk has to work around this problem (by disallowing
the use of Process).
libgcj ought
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 18:35 ---
Hmnm, is this really a bug, waitpid is used only in the reaper thread.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29324
--- Comment #2 from tromey at gcc dot gnu dot org 2006-10-02 18:39 ---
Yes, it really is a bug.
libgcj can reap a child process started by some other library.
This means it is hard to use libgcj in conjunction with other libraries
which may want to do their own subprocess bookkeeping.
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu
2006-10-02 19:08 ---
Subject: Re: New: gfortran.dg/exponent_1.f90 failure
On Mon, Oct 02, 2006 at 09:32:55AM -, fxcoudert at gcc dot gnu dot org
wrote:
gfortran.dg/exponent_1.f90 is failing at all optimization
--- Comment #4 from eplondke at gmail dot com 2006-10-02 19:16 ---
(In reply to comment #3)
Actually this case should not be using post modify at all except how many bits
does ARM have to use for an offset? I thought 16bits which means you don't
need
that at all and GCC should
--- Comment #5 from sebor at roguewave dot com 2006-10-02 19:19 ---
Interesting. The vanilla EDG front end rejects it as expected. I wonder why
Intel
accepts it when neither EDG nor gcc does. Maybe we should open a bug with them
to
find out ;-)
--
--- Comment #24 from wilson at gcc dot gnu dot org 2006-10-02 19:23 ---
Created an attachment (id=12372)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12372action=view)
improved patch for inline warning
Works for simple testcases. Needs full bootstrap regression test.
--
--- Comment #25 from wilson at tuliptree dot org 2006-10-02 19:25 ---
Subject: Re: [4.0/4.1/4.2 Regression] -Winline does
not respect -fno-default-inline
On Sat, 2006-09-30 at 12:36 +, lopezibanez at gmail dot com wrote:
I think I found out what is going on, although I
--- Comment #18 from mrs at apple dot com 2006-10-02 19:28 ---
What is your position based upon? Mine is based upon having been in the room
when we decided what the C rules probably were, what the C++ rules could be and
the up side and down side of each choice and where we decided what
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-02 19:39 ---
The gimplifier is going wrong.
It first uses the value-expr and then forgets that can be addressable or maybe
even worse we don't mark the result as addressable.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-02 20:13
---
I think the following can workaround the middle-end problem:
Index: trans-decl.c
===
--- trans-decl.c(revision 117368)
+++ trans-decl.c
--- Comment #32 from hacksaw at hacksaw dot org 2006-10-02 20:15 ---
Is the 3.3.x tree closed? If that is the case, should someone mark this bug
WONTFIX, and those who care can move on patching their gcc or moving to a
higher one?
Has anyone reproduced this bug with a higher compiler
--- Comment #6 from pcarlini at suse dot de 2006-10-02 20:51 ---
(In reply to comment #5)
Interesting. The vanilla EDG front end rejects it as expected. I wonder why
Intel accepts it when neither EDG nor gcc does.
Sorry about the trivial question: Intel in *strict* mode?
--
--- Comment #3 from danp57 at optonline dot net 2006-10-02 21:02 ---
Subject: Re: configure produces strange gmp, mpfr lib directories.
There are multiple logs --
1) I switched to static libraries, but tried both static and shared
(the static libs are more standard, and less likely
--- Comment #26 from lopezibanez at gmail dot com 2006-10-02 21:03 ---
(In reply to comment #25)
If you look at Comment #19, you will see that I have already provided a
solution. However, I see that I failed to add the patch I wrote to the
bug report. I will do that now. My work
--- Comment #9 from anlauf at gmx dot de 2006-10-02 21:35 ---
(In reply to comment #8)
This is NOT a bug. g77 compatibility and the Fortran 95 standard
have a conflict, and so IMNSHO the Fortran 95 standard wins.
Gfortran unfortunately does not have a switch to compile legacy code
--- Comment #6 from steven at gcc dot gnu dot org 2006-10-02 21:46 ---
Re comment #5: A quick pass to look for these cases and transform those PHIs
into copies at the appropriate place would accomplish the same thing.
That is exactly what I'd expect the out-of-ssa pass to take care of.
--- Comment #32 from pault at gcc dot gnu dot org 2006-10-02 21:54 ---
Created an attachment (id=12373)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12373action=view)
A patch that fixes test_ab9.f90
You will see the modification in trans-types.c. This is the first bit of the
--- Comment #7 from amacleod at redhat dot com 2006-10-02 22:13 ---
Its not that you are expecting too much, just in the wrong place from my point
of view :-) Changing the out of ssa algorithm or implementation isnt going to
change this code. It requires changing the code out of ssa
--- Comment #9 from patchapp at dberlin dot org 2006-10-02 22:15 ---
Subject: Bug number PR 27478
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-10/msg00098.html
--
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-10-02 22:21
---
Subject: Bug 29226
Author: mmitchel
Date: Mon Oct 2 22:21:02 2006
New Revision: 117375
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117375
Log:
PR c++/29226
* typeck.c
__builtin_trap is mentioned on
http://gcc.gnu.org/onlinedocs/gcc/Standards.html
But it is not documented on:
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
--
Summary: __builtin_trap is not documented
Product: gcc
Version: 4.2.0
Status:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-02 23:27 ---
If I get a chance I will post a patch sometime this week or next.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29326
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-10-02 23:42
---
Subject: Bug 29226
Author: mmitchel
Date: Mon Oct 2 23:41:59 2006
New Revision: 117377
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117377
Log:
PR c++/29226
* typeck.c
--- Comment #2 from ian at airs dot com 2006-10-02 23:52 ---
I believe this is happening because if the format is unrecognized, the
test-demangle program does not go on to see that the --no-params option was
used. When --no-params is used, it needs to skip an additional line.
I see no
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
Executing on host:
/home/dave/gnu/gcc-4.2/objdir/gcc/testsuite/gfortran/../../gf
ortran -B/home/dave/gnu/gcc-4.2/objdir/gcc/testsuite/gfortran/../../
/home/dave/
gnu/gcc-4.2/gcc/gcc/testsuite/gfortran.dg/specifics_1.f90 -O0 -ff2c
-L/home/
dave/gnu/gcc-4.2/objdir/hppa-linux/./libgfortran/.libs
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu
2006-10-03 01:48 ---
Subject: Re: boz initialization of REALs fails
On Mon, Oct 02, 2006 at 09:35:11PM -, anlauf at gmx dot de wrote:
This is NOT a bug. g77 compatibility and the Fortran 95 standard
have
--- Comment #2 from tromey at gcc dot gnu dot org 2006-10-03 02:12 ---
I can't reproduce this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from danglin at gcc dot gnu dot org 2006-10-03 02:12 ---
The gfortran.dg/exponent_1.f90 and gfortran.dg/nearest_1.f90 are falling
on hppa2.0w-hp-hpux11.11. I updated to mpfr 2.2.0 and the tests are still
failing. Possibly, I need a complete rebuild.
--
danglin at
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-03 02:17
---
Yes, make sure you do a complete clean rebuild. You may also need this for the
PR29327.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29317
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2006-10-03 02:27 ---
Subject: Re: gfortran.dg/exponent_1.f90 failure
On Tue, Oct 03, 2006 at 02:12:55AM -, danglin at gcc dot gnu dot org wrote:
The gfortran.dg/exponent_1.f90 and gfortran.dg/nearest_1.f90 are
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-03 02:41 ---
http://gcc.gnu.org/ml/fortran/2006-09/msg00468.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29327
--- Comment #17 from bergner at vnet dot ibm dot com 2006-10-03 03:30
---
Created an attachment (id=12375)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12375action=view)
Patch to swap_commutative_operands_p and gen_addr_rtx to force base pointers
into rA position of indexed
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-03 03:58
---
Subject: Bug 19260
Author: jvdelisle
Date: Tue Oct 3 03:58:20 2006
New Revision: 117384
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117384
Log:
2006-10-02 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-03 03:58
---
Subject: Bug 19262
Author: jvdelisle
Date: Tue Oct 3 03:58:20 2006
New Revision: 117384
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117384
Log:
2006-10-02 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:10
---
Subject: Bug 19260
Author: jvdelisle
Date: Tue Oct 3 04:09:49 2006
New Revision: 117385
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117385
Log:
2006-10-02 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:10
---
Subject: Bug 19262
Author: jvdelisle
Date: Tue Oct 3 04:09:49 2006
New Revision: 117385
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117385
Log:
2006-10-02 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:11
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-03 04:12
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 103 matches
Mail list logo
