--- Comment #16 from dominiq at lps dot ens dot fr 2007-03-21 15:36 ---
> The recommended way is to post a message to gcc@gcc.gnu.org or
> [EMAIL PROTECTED]
I'll follow your advice, but before I'ld like some feedback about what follows.
I have applied the following pa
--- Comment #18 from dominiq at lps dot ens dot fr 2007-03-21 16:09 ---
> It would be nice to know whether darwin does not implement cexp in an optimal
> way ...
I have forgotten to mention that I did some (quick) profiling: cexp seens
trivially implemented.
It calls sin, cos a
--- Comment #15 from dominiq at lps dot ens dot fr 2007-03-22 16:22 ---
Note that the drawback of the optimization replacing sin+cos by cexpi on PPC
Darwin has been dissected in PR31249.
In comment #16, I proposed a patch. Before applying it, it would be nice to
test if the other
--- Comment #1 from dominiq at lps dot ens dot fr 2007-03-24 22:28 ---
xlf yields a bus error without optimization and -O, and abort with -O3.
g95 gives the following errors:
In file pointer_intent_1.f90:39
nullify(t%point)
1
Error: Cannot NULLIFY the INTENT(IN
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-29 18:50 ---
This bug reminds me PR30980 and PR31161, though they were reported only for g++
and gfortran (they were fixed on 2007-03-16). Could you look at them to see if
the bug you have reported is not a duplicate? If yes, you
--- Comment #4 from dominiq at lps dot ens dot fr 2007-03-30 21:56 ---
> I suppose that makes it a duplicate of PR30980.
It would have been better to check it directly before updating. PR30980 was
related to g++ and gfortran and not gcc, so it seems that your platform
(i386
gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
oring the daily regression tests on
Darwin 8.5?
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domin
--- Comment #27 from dominiq at lps dot ens dot fr 2007-04-24 13:03 ---
> Please define "fixed".
For me "fixed"=="no hanging" period.
> You run an invalid program,
Yes, I know, repeating that won't help!
> all you need is change your
--- Comment #29 from dominiq at lps dot ens dot fr 2007-04-24 15:59 ---
> It is hanging on undefined, I think there is a difference here, a big
> difference.
What is the difference for you?
Just as a side note, that's not me who classed the PR as invalid and so far I
di
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32837
riority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
--- Comment #2 from dominiq at lps dot ens dot fr 2007-07-20 21:00 ---
Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on
Darwin8
> Can you test with a C program to see if indeed this is the problem?
My knowledge of C it very limited, you know!-(
Could you send me some canvas
--- Comment #4 from dominiq at lps dot ens dot fr 2007-07-20 21:20 ---
Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on
Darwin8
I don't know if the following code is correct, but it returns 1:
#include
#include
int main()
{
double x
--- Comment #6 from dominiq at lps dot ens dot fr 2007-07-20 22:08 ---
Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on
Darwin8
> Try this: ...
I get
1.79769313486231570814527423731704356798070567526e+308
isfinite = 1
isfinite = 0
There is something I don't unders
--- Comment #8 from dominiq at lps dot ens dot fr 2007-07-20 22:28 ---
Subject: Re: FAIL: gfortran.dg/edit_real_1.f90 on
Darwin8
> Can you post the config.h file from your build directory?
Unfortunately, it is gone (fink install) and I'll be away for two days.
So not befor
--- Comment #9 from dominiq at lps dot ens dot fr 2007-07-23 14:53 ---
Created an attachment (id=13954)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13954&action=view)
darwin_objdir/powerpc-apple-darwin8/libgfortran/config.h
> Can you post the config.h file from
--- Comment #10 from dominiq at lps dot ens dot fr 2007-07-23 15:03 ---
This a regression from 4.2. The following code
real(8) x, y
real(8) down, up
x = huge(x)
y = down(x)
print *, y, up(y)-x, up(up(y))-x, up(up(x))-x
y = up(y)
print *, x, y
end
real(8) function up(x)
real(8) x
up
--- Comment #11 from dominiq at lps dot ens dot fr 2007-07-24 09:31 ---
The regression occured between revisions 123612 and 123624, see:
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00300.html
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00311.html
The most likely candidate is
--- Comment #14 from dominiq at lps dot ens dot fr 2007-07-25 06:38 ---
Subject: Re: [4.3 regression] HUGE(1.0d0) is written a
+Infinity on Darwin8
> There were two modifications between these revs:
> 123620 format.c
> 123623 write.c
Yes, but the first one is very shor
--- Comment #15 from dominiq at lps dot ens dot fr 2007-07-25 06:41 ---
Subject: Re: [4.3 regression] HUGE(1.0d0) is written a
+Infinity on Darwin8
Forgot to say in my previous mail that libgfortran/config.h for
gcc4.2.1 contains:
...
/* Define if fpclassify is broken. */
/* #undef
--- Comment #17 from dominiq at lps dot ens dot fr 2007-07-27 05:56 ---
Subject: Re: [4.3 regression] HUGE(1.0d0) is written a
+Infinity on Darwin8
> Maybe you could try to delete the conditional defines that redefine isfinite
> so
> that the native calls are used and s
--- Comment #19 from dominiq at lps dot ens dot fr 2007-07-27 19:34 ---
Subject: Re: [4.3 regression] HUGE(1.0d0) output as
+Infinity on ppc-darwin8
> Hum, I don't see anything in rev. 123623
> (http://gcc.gnu.org/viewcvs?view=rev&revision=123623) that looks too
>
--- Comment #21 from dominiq at lps dot ens dot fr 2007-07-27 21:43 ---
Subject: Re: [4.3 regression] HUGE(1.0d0) output as
+Infinity on ppc-darwin8
> Your idea on the order of #defines is probably on the right track.
As I said, this is the quickest way to hide the problem.
I h
--- Comment #2 from dominiq at lps dot ens dot fr 2007-07-28 13:27 ---
> I fixed the same kind of problems with MVBITS (it was PR32357). Maybe we
> should
> ask to Dominique Dhumières to test on ppc-darwin? (like, running the testsuite
> with -fdefault-integer-8)
I have lo
--- Comment #4 from dominiq at lps dot ens dot fr 2007-07-28 14:18 ---
> (Full doc is available at http://gcc.gnu.org/install/test.html)
I have read it, but I got confused by:
"In order to run sets of tests selectively, there are targets `make check-gcc'
and `make chec
--- Comment #5 from dominiq at lps dot ens dot fr 2007-07-29 08:01 ---
If you were expecting to be kept buzzy, you'll be glad! The summary is:
=== gfortran Summary for unix/-fdefault-integer-8//-m32 ===
# of expected passes18575
# of unexpected failures750
--- Comment #7 from dominiq at lps dot ens dot fr 2007-07-29 08:59 ---
Created an attachment (id=13996)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13996&action=view)
log and sum files for the tests with -fdefault-integer-8
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #8 from dominiq at lps dot ens dot fr 2007-07-29 09:24 ---
Considering the number of failures to analyse, I think there is need to avoid
duplicate efforts. What is the best way to proceed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
--- Comment #11 from dominiq at lps dot ens dot fr 2007-07-29 11:09 ---
The following test cases fail only with -m64, but not, or differently, with
-m32.
FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O0 execution test
FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O1 execution
--- Comment #12 from dominiq at lps dot ens dot fr 2007-07-29 11:11 ---
Created an attachment (id=13998)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13998&action=view)
test case failing with -m32, but not, or differently, with -m64
--
http://gcc.gnu.org/b
--- Comment #10 from dominiq at lps dot ens dot fr 2007-07-29 11:08 ---
Created an attachment (id=13997)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13997&action=view)
Failures on PPC Darwin8 common to -m32 and -m64
I attached the reduced list of the test cases faili
--- Comment #14 from dominiq at lps dot ens dot fr 2007-07-29 11:44 ---
I have already started to investigate gfortran.dg/forall_4.f90. With -m32 it
does not ICE but abort due to the line
forall (i=1:n, .not. s(i)) a(i) = i
the '.not.' seems to be the problem (the co
--- Comment #15 from dominiq at lps dot ens dot fr 2007-07-29 12:21 ---
gfortran.dg/associated_2.f90
gfortran.fortran-torture/execute/intrinsic_associated.f90
gfortran.fortran-torture/execute/intrinsic_associated_2.f90
ICE with the same kind of error (cannot get any backtrace
--- Comment #16 from dominiq at lps dot ens dot fr 2007-07-29 12:33 ---
gfortran.dg/bounds_check_5.f90
gfortran.dg/char_associated_1.f90
gfortran.dg/der_array_1.f90
gfortran.dg/ret_pointer_1.f90
ICE as associated_2_db:
bounds_check_5_db.f90:16: internal compiler error: in
--- Comment #18 from dominiq at lps dot ens dot fr 2007-07-29 12:59 ---
> You need to backtrace f951
Yes indeed: I did
gdb /opt/gcc/gcc4.3l/libexec/gcc/powerpc-apple-darwin8/4.3.0/f951
I have also noticed that I don't have any entry for today
in~/Library/Logs/CrashReporter/,
--- Comment #20 from dominiq at lps dot ens dot fr 2007-07-29 13:26 ---
> And did you set a breakpoint on fancy_abort?
If it has to be done explicitely, the answer is no. Doing it I get:
(gdb) break fancy_abort
Breakpoint 1 at 0xbf4ec: file ../../gcc-4.3-20070727/gcc/diagnosti
at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32931
--- Comment #1 from dominiq at lps dot ens dot fr 2007-07-29 19:35 ---
Note that the ICEs with -m64 diasppear with -O3, but then both tests fail to
execute.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32931
--- Comment #1 from dominiq at lps dot ens dot fr 2007-07-30 11:52 ---
Confirmed on PPC Darwin8, ICE on 4.3, pass on 4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32935
--- Comment #1 from dominiq at lps dot ens dot fr 2007-07-30 20:24 ---
> The problem appears to be that the first argument to gfortani_compare_string
> is pushed as an 8-byte integer, which messes things up.
The test passes for me with -m64, without it the backtrace is (on D
--- Comment #7 from dominiq at lps dot ens dot fr 2007-07-31 07:59 ---
> And here is a patch which fixes the ICE:
Confirmed and regtested on PPC Darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32935
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32942
red.f90 gives an ICE with -fdefault-
integer-8
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32943
--- Comment #3 from dominiq at lps dot ens dot fr 2007-07-31 13:01 ---
> A patch for this bug has been added to the patch tracker.
Regtested on PPC Darwin8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32936
--- Comment #3 from dominiq at lps dot ens dot fr 2007-07-31 18:56 ---
Subject: Re: Wrong code with with -fdefault-integer-8
> So, we need to review every unilateral use of gfc_default_integer_kind
> in the frontend to determine if the promotion of 4 to 8 via
> -fdefault-
--- Comment #6 from dominiq at lps dot ens dot fr 2007-07-31 20:21 ---
Subject: Re: Wrong code with with -fdefault-integer-8
> That appears to work.
Confirmed, we have now:
_gfortran_st_write (&dt_parm.1);
{
int8 D.961;
D.961 = (int8) _gfortran_exponen
--- Comment #7 from dominiq at lps dot ens dot fr 2007-07-31 20:32 ---
Subject: Re: Wrong code with with -fdefault-integer-8
This part of the problem for intrinsic_rrspacing.f90 now works, but there
is another one with rrspacing(x):
program test_rrspacing
real x
x = 3.0
x
--- Comment #11 from dominiq at lps dot ens dot fr 2007-07-31 21:39 ---
Subject: Re: Wrong code with with -fdefault-integer-8
> The rrspacing problem is something besides -fdefault-integer-8
> because I get the expected results on my system.
Is your system big or little endian?
--- Comment #13 from dominiq at lps dot ens dot fr 2007-07-31 22:04 ---
Subject: Re: Wrong code with with -fdefault-integer-8
> It is an opteron, so little endian.
So rrspacing is another instance of PR32770
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32942
t: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32955
--- Comment #3 from dominiq at lps dot ens dot fr 2007-08-01 13:51 ---
The first test of PR32770, i.e.:
program main
real, dimension(2) :: a
call random_number(a)
print *,maxloc(a,mask=.true.)
end program main
with -fdefault-integer-8 and your patch, gives (PPC Darwin8
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32956
--- Comment #4 from dominiq at lps dot ens dot fr 2007-08-01 14:28 ---
gfortran.dg/minmaxloc_1.f90 gives the same error in my build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32957
--- Comment #1 from dominiq at lps dot ens dot fr 2007-08-01 15:10 ---
A similar problem occurs with gfortran.fortran-torture/execute/equiv_5.f which
hangs (does not stop, but no CPU time used). The following patch makes the test
pass:
[karma] f90/bug% diff
/opt/gcc/gcc-4.3-work/gcc
--- Comment #5 from dominiq at lps dot ens dot fr 2007-08-01 15:36 ---
I have had a nonexpert look at the patch and I wonder if
+ ts.kind = gfc_default_logical_kind;
should not be
+ ts.kind = newkind;
???
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
--- Comment #9 from dominiq at lps dot ens dot fr 2007-08-01 19:05 ---
With the change my tests now compile (regtesting!-), but
gfortran.dg/zero_sized_1.f90 aborts.
BTW I don't understand the error:
Can't convert LOGICAL(8) to LOGICAL(8) at (1)
How can a "no operat
--- Comment #10 from dominiq at lps dot ens dot fr 2007-08-01 19:08 ---
Sorry it was a "Bus error" and not an abort:
Host Name: pbook
Date/Time: 2007-08-01 20:54:37.875 +0200
OS Version: 10.4.10 (Build 8R218)
Report Version: 4
Command: a.out
Path:a.out
Par
--- Comment #11 from dominiq at lps dot ens dot fr 2007-08-01 19:11 ---
The problem is with PACK. If I comment the line
call test_pack
the test pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
--- Comment #13 from dominiq at lps dot ens dot fr 2007-08-01 20:17 ---
I still have the "Bus error". From the backtrace I think the culprit is
libgfortran/intrinsics/pack_generic.c. Probably around the lines:
pack_internal (gfc_array_char *ret, const gfc_array_c
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-01 20:01 ---
Confirmed with 4.3.0 of today on PPC Darwin8:
original = ( 2.00 , 0.00 ) (
3.00 , 0.00 ) ( 7.00 ,
0.00
--- Comment #16 from dominiq at lps dot ens dot fr 2007-08-01 21:19 ---
As far as I can tell, I have applied correctly your latest patch. But the
following reduced test
! { dg-do run }
! Transformational functions for zero-sized array and array sections
! Contributed by Francois-Xavier
--- Comment #17 from dominiq at lps dot ens dot fr 2007-08-02 08:06 ---
The following reduced cas:
integer,allocatable :: foo(:,:)
allocate(foo(0,1:7))
print *, pack(foo(:,1),foo(:,1)==0,(/1,2/))
deallocate(foo)
end
gives a "Bus error" when run. It works if I replac
--- Comment #18 from dominiq at lps dot ens dot fr 2007-08-02 09:53 ---
The test of #17 pass on AMD64 with gfortran 4.3.0 20070713, but fails on PPC
Darwin8 with gfortran 4.3.0 20070802.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
--- Comment #19 from dominiq at lps dot ens dot fr 2007-08-02 15:49 ---
Created an attachment (id=14009)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14009&action=view)
gdb session from entering pack_internal to the crash
I have also had a look to the results of -fdu
--- Comment #23 from dominiq at lps dot ens dot fr 2007-08-02 16:03 ---
Revision 127147, plus unconditional
#undef isfinite
plus patches from A Pinski:
http://gcc.gnu.org/ml/gcc-bugs/2007-07/msg02997.html
from FX coudert:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02206.html
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32969
--- Comment #3 from dominiq at lps dot ens dot fr 2007-08-02 16:37 ---
Subject: Re: Compiling equiv_7_db.f90 gives an error
with -fdefault-integer-8
> These two examples are the poster child for
> 1) Why -fdefault-integer-8 is a bad option and should only be
>used by p
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-02 17:08 ---
Subject: Re: C/Fortran interoperability and
-fdefault-integer-8
> A check of this option can be inserted at various locations during
> the parsing.
Certainly, but this will give a very interesting exerc
--- Comment #21 from dominiq at lps dot ens dot fr 2007-08-02 17:42 ---
Created an attachment (id=14011)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14011&action=view)
new gdb session with 'watch sptr'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-02 20:55 ---
Subject: Re: selected_(int|real)_kind fail with
-fdefault-integer-8
Steve,
I applied your patch, but on PPC Darwin I get 10 times 1 for int, instead of:
1
1
2
2
--- Comment #4 from dominiq at lps dot ens dot fr 2007-08-02 21:17 ---
Subject: Re: selected_(int|real)_kind fail with
-fdefault-integer-8
> What is the -fdump-tree-original for
without:
{
int4 D.966;
D.966 = _gfortran_selected_int_kind
--- Comment #8 from dominiq at lps dot ens dot fr 2007-08-02 23:02 ---
Subject: Re: selected_(int|real)_kind fail with
-fdefault-integer-8
> Can you try the attached patch?
It fixes the problem for -fdefault-integer-8, but without it,
it gives on your test (and others)
--- Comment #12 from dominiq at lps dot ens dot fr 2007-08-03 00:17 ---
Subject: Re: selected_(int|real)_kind fail with
-fdefault-integer-8
> I think that we may be converging on a patch. Can you test
> the attached diff?
I have converged in the same direction (modulo the
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
--- Comment #1 from dominiq at lps dot ens dot fr 2007-08-29 19:29 ---
Note that the problem disappears on Darwin with -m64 (excepted the problem
Error: Result of NEAREST overflows its kind at (1)).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-29 22:18 ---
I have run the NIST test suite and I got:
...
6 runtime errors
FM111 has NIST regression.
FM406 has NIST regression.
FM903 has NIST regression.
FM907 has NIST regression.
FM909 has NIST regression.
FM912 has NIST
--- Comment #4 from dominiq at lps dot ens dot fr 2007-08-29 23:02 ---
Subject: Re: [4.3 regression] Missing last digit is
some formatted output
> Actually this is expected if you did not supply -fno-sign-zero ...
You are right!-) I have added the option in the script I am using
--- Comment #7 from dominiq at lps dot ens dot fr 2007-08-30 07:03 ---
Subject: Re: [4.3 regression] Missing last digit is
some formatted output
> gives the output
>
> 1.797693134862316E+30^@ 2.225073858507201E-30^@
^@ is binary 0 and is not display on my terminal. If I
--- Comment #9 from dominiq at lps dot ens dot fr 2007-08-30 21:04 ---
The following code:
real x
x = 1.0
print '(3E20.2e2)', x, x/10.0, x/100.0
print '(3E20.2e3)', x, x/10.0, x/100.0
print '(3E20.2e4)', x, x/10.0, x/100.0
print '(3E20.2e5)', x,
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-02 13:42 ---
> [18:23] < apinski> between 127935 and 128000
Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from
"regress", it can be narrowed between 127961 (working) and 127997 (non
w
--- 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) = (/
--- 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)
--- 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
--- 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 #4 from dominiq at lps dot ens dot fr 2007-09-03 15:32 ---
Test Run By dominiq on Mon Sep 3 15:14:54 2007
Native configuration is powerpc-apple-darwin8
=== gcc tests ===
Schedule of variations:
unix
XPASS: gcc.dg/20020103-1.c scan-assembler-not LC[0-9
--- 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)
?
--
http
error
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc
--- 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
at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33300
--- Comment #2 from dominiq at lps dot ens dot fr 2007-09-04 12:05 ---
I don't think the PR is invalid:
(1) at least it should go the "enhancement" with the addition of " This check
can be disabled with the option -fno-range-check" as in
prin
--- Comment #21 from dominiq at lps dot ens dot fr 2007-09-05 09:19 ---
Subject: Re: Missing last digit in some formatted
output (on 32bit targets), per kind write_float
If I am not mistaken, the test case did not go through.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
--- Comment #18 from dominiq at lps dot ens dot fr 2007-09-07 13:49 ---
FX,
Please don't take my comment on the test suite personally.
I think the PR should be resolved as WONTFIX for the reasons you explain and
the test case should fail on the platform on which it fails.
Fo
--- Comment #16 from dominiq at lps dot ens dot fr 2007-09-07 11:42 ---
This way to fix the problem shakes the (little) confidence I have in the test
suite!
Would not it be better to let the tests fail for the mentionned platforms until
a (real) fix is found (as it is done for
inlining problem
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build trip
--- Comment #4 from dominiq at lps dot ens dot fr 2007-09-07 08:45 ---
> I think the standard is very clear on that. Quoting F2003 13.7:
> "A program is prohibited from invoking an intrinsic procedure under
> circumstances where a value to be returned in a subrouti
: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin8
GCC host triplet: powerpc-apple
--- Comment #6 from dominiq at lps dot ens dot fr 2007-09-11 08:47 ---
> If this is case 2 ...
Yes
> then the answers are ...
> Yes.
Why? more precisely what are the rules behind this yes?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33296
301 - 400 of 2230 matches
Mail list logo
