--- Comment #19 from dominiq at lps dot ens dot fr 2007-09-11 10:44 ---
In order to avoid a too long post, I am splitting my answer in pieces.
> PS: I should note that the bug in question is a relatively minor one:
> lround(), on ppc-glibc and AIX, returns a wrong answer f
--- Comment #8 from dominiq at lps dot ens dot fr 2007-09-11 10:48 ---
Subject: Re: nearest(huge(1.0),1.0) gives an error
> (Doing so is a missed optimization, now filed as PR33387.)
When fixed, will the second test throw an error or not?
While looking for jokes about Intel, I can
--- Comment #5 from dominiq at lps dot ens dot fr 2007-09-11 15:40 ---
> Well, I think the "depending on the language being compiled" is important. I
> think the testcase is valid Fortran, and shouldn't fail whatever the
> optimization level you use.
FX, may I
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-11 15:46 ---
Is this a duplicate of PR33384?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33390
--- Comment #7 from dominiq at lps dot ens dot fr 2007-09-11 15:54 ---
> this behaviour was prohibited
which behavior: folding huge(0)+1 as -huge(0)-1? or considering huge(0)+1 as
invalid (out of range) and doing an optimization based on the fact that any
valid integer is smaller
: 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-darwin8
GCC target triplet
--- Comment #2 from dominiq at lps dot ens dot fr 2007-09-13 06:39 ---
The (spurious?) warning is also present in 4.3.
> The patch here is clearly wrong. If you don't like the warnings, you should
> work out why they are being output and fix the underlying bug, rather tha
--- Comment #1 from dominiq at lps dot ens dot fr 2007-09-15 19:47 ---
I have reduced the test to:
C* PCAPOP
SUBROUTINE PCAPOP()
DIMENSION NVA(6)
C
! P1=FLOAT(NB)/FLOAT(M1)
10IP1=P1
IF(IP1.GE.NVA(K)) GOTO 7
IF(IP2.EQ.0) GOTO 3
7 IF(K.EQ.6) GOTO 11
--- Comment #7 from dominiq at lps dot ens dot fr 2007-09-15 19:53 ---
I won't comment about the incredible activity on this bug!-(
> Lastly, if this is the same bug that is breaking the libgomp build on
> powerpc64
> linux, those testresults are now all being poste
--- Comment #2 from dominiq at lps dot ens dot fr 2007-09-15 20:28 ---
The line
SUBROUTINE PCAPOP()
is not necessary to get the failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33348
--- Comment #1 from dominiq at lps dot ens dot fr 2007-09-15 21:17 ---
see http://gcc.gnu.org/ml/fortran/2007-09/msg00247.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33446
--- Comment #9 from dominiq at lps dot ens dot fr 2007-09-16 19:55 ---
> It is impossible to get some preprocessed source from this break since it does
> not preprocess anything. It is a .class to .o compilation.
May be you could have a look at the reduced code in PR
--- Comment #11 from dominiq at lps dot ens dot fr 2007-09-17 13:59 ---
Subject: Re: [4.3 Regression] At revision 128385
Bootstraping PPC Darwin still fail in Java
Did you try to bootstrap with Java with the one line patch in:
http://gcc.gnu.org/ml/gcc-bugs/2007-09/msg01311.html
It
output
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org
--- Comment #1 from dominiq at lps dot ens dot fr 2007-09-18 09:47 ---
Created an attachment (id=14219)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14219&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33469
--- Comment #4 from dominiq at lps dot ens dot fr 2007-09-19 12:38 ---
Subject: Re: Add one digit to the default formatted output
> Dominique, what is the output of your test program on ppc-darwin?
real(4)
default 808
1PG20.61881
1PG20.7 808
1PG2
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-25 20:08 ---
On Darwin8 I get:
[karma] f90/bug% gfc -O0 -fbounds-check -fbacktrace -g pr33554.f90
[karma] f90/bug% a.out
before construct_temp, size (temp) = 2
Enter construct_temp, size (temp) = 2
Leave
--- Comment #6 from dominiq at lps dot ens dot fr 2007-09-26 07:45 ---
> Failing:
> GNU Fortran (GCC) 4.3.0 20070805 (experimental)
Did you try a more recent version? I don't see the problem with
Target: powerpc-apple-darwin8
gcc version 4.3.0 20070925 (experimental) (GCC)
--- Comment #8 from dominiq at lps dot ens dot fr 2007-09-26 08:10 ---
Now I get a bus error, but I have to use:
gfc -m64 -g pr33554.f90 -O0
with
gfc -m64 -g pr33554.f90 -fbounds-check -O0
the bus error disappear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554
--- Comment #4 from dominiq at lps dot ens dot fr 2007-09-27 13:59 ---
The patch fixes the test case on this PR, but gives ICE on several of my tests.
The simplest is:
program aint_anint_1
implicit none
real(8) :: s = 42.7D0, s1, s2
s1 = aint(s)
! s2 = aint(s, kind=4)
end
--- Comment #5 from dominiq at lps dot ens dot fr 2007-09-27 16:18 ---
With the new patch I still have an ICE on:
reala
real*8 c
print *, (nearest(0.5,-1.0)+0.5)-1.0
a = 8388609.0
print '(3(1PG26.9))', a, anint(a), anint
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
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-darwin8
GCC target triplet
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-01 15:13 ---
Subject: Re: ICE on arithmetic overflow
> What does it do with -fno-range-check?
compiles and outputs +Infinity
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-01 16:48 ---
Subject: Re: ICE on arithmetic overflow
> What does -fdump-tree-original give when you use the -fno-range-check
> option?
MAIN__ ()
{
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
_gfortran_set_o
--- Comment #7 from dominiq at lps dot ens dot fr 2007-10-02 08:29 ---
Subject: Re: Default formats for real input are not
precise enough
> Part of it is simply a libc bug. There are numbers close to 1.0 and -1.0 that
> the darwin libc can't output properly:
Nice catch!
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-02 10:05 ---
Works as advertised without regression on PPC Darwin.
However there may be room for improvements for the error message:
pr33542.f90:24.9:
USE M1
1
Error: Ambiguous interfaces 'foo2' and 'f
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-03 13:03 ---
On PPC Darwin, I get:
[karma] f90/bug% gfc pr33636.f90
[karma] f90/bug% a.out
0
[karma] f90/bug% gfc -m64 pr33636.f90
[karma] f90/bug% a.out
0
[karma] f90/bug% gfc
/opt/gcc/_gcc-clean/gcc
--- Comment #10 from dominiq at lps dot ens dot fr 2007-10-03 19:30 ---
gcc/testsuite/gfortran.dg/default_format_1.f90 passes the test if I replace
if (y /= x) res = res + 1
by
z=0.0_k
if (abs(x-y)>nearest(z,1.0_k)) res = res + 1
in the two places of test
--- Comment #11 from dominiq at lps dot ens dot fr 2007-10-03 19:34 ---
BTW I have forgotten to explain why I have to use an auxiliary variable 'z': if
I usenearest(0.0_8,1.0_8); I get
default_format_1_db.f90:70.29:
if (abs(x-y)>nearest(0.0_8,1.0_8)) print
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-03 21:32 ---
> It's me
I have warned you;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33646
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-04 13:51 ---
Works for me:
[karma] f90/bug% gfc -c -w -O pr33656.f
[karma] f90/bug% gfc -m64 -c -w -O pr33656.f
[karma] f90/bug% gfc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: ../gcc-4.3-work
--- Comment #24 from dominiq at lps dot ens dot fr 2007-10-06 21:47 ---
The patch in comment #22 fixes the 3 PR's, but cause a quite massive regression
on my tests, for instance:
INTEGER :: I
CHARACTER(LEN=100) :: data="1.0 3.0"
REAL :: C,D
READ(data,*) C,D
I=TRANSFE
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-06 22:28 ---
On Darwin I get:
/usr/bin/ld: Undefined symbols:
_gammaf
collect2: ld returned 1 exit status
Target: powerpc-apple-darwin8
Configured with: ../gcc-4.3-work/configure --prefix=/opt/gcc/gcc4.3w
--mandir=/opt/gcc
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-08 10:11 ---
works with revision 129038 (20071005).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33689
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-08 12:05 ---
You can add xlf to the (3, 1, 4, 2) list. I think this is the right answer.
The following code
PROGRAM TST
IMPLICIT NONE
INTEGER :: P(4),Q(4),I
P = (/2,4,1,3/)
FORALL(I=1:4)
Q(P(I)) = I
END FORALL
--- Comment #9 from dominiq at lps dot ens dot fr 2007-10-10 09:35 ---
Are the codes in #7 and #8 supposed to behave differently?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33686
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-10 14:38 ---
Note that the (IMHO) valid code:
program array_char
implicit none
character (len=2) :: x, y
character (len=2) :: z(2)
x = "a "
y = "cd"
z = (/y(1:len(trim(x))), x(1:len(trim(x)))/) ! causes seg
--- Comment #5 from dominiq at lps dot ens dot fr 2007-10-11 09:38 ---
After applying the patch and the one to PR33727 (thanks Paul!-), the first test
fails at runtime:
At line 6 of file pr32703_1.f90
Fortran runtime error: Different CHARACTER lengths (1/2) in array constructor
but
--- Comment #31 from dominiq at lps dot ens dot fr 2007-10-11 10:17 ---
Works as advertised without regression so far (PPC Darwin, 32 bit mode close to
complete), but for the codelets in #30.
I wonder if the code in #28 is valid: the line(s)
merge(transfer(string,"x",
--- Comment #7 from dominiq at lps dot ens dot fr 2007-10-11 12:34 ---
> This is weird, and can't really be (well, in a hypothetical world where
> only the bounds check goes wrong), as the whole array has only a single
> string length, so I would expect it to either pr
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-11 13:53 ---
The patch fixes the tests but resurect an old ICE on (was pr18769):
program gfcbug21
implicit none
type t
integer :: i
end type t
type (t), parameter :: u = t (1)
integer, parameter :: idx_list(1
--- Comment #10 from dominiq at lps dot ens dot fr 2007-10-11 14:10 ---
> ... What I menat is the following: after the
> data has been added to the array, the compiler should use the string
> length of the array, ...
I agree, this is why I posted the second code with y(1:l
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-11 14:14 ---
I don't know if this the right fix, but
--- /opt/gcc/_gcc-clean/gcc/fortran/simplify.c 2007-10-07 09:37:46.0
+0200
+++ /opt/gcc/gcc-4.3-work/gcc/fortran/simplify.c2007-10-11
16:05:57.0
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-11 17:30 ---
Works as expected: now gfortran agrees with xlf. Regtest almost finished in 32
bit mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33233
--- Comment #5 from dominiq at lps dot ens dot fr 2007-10-11 17:31 ---
> Oui, c'est bon! Merci.
Question: is this the only omission?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
uct: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin8
GCC h
--- Comment #8 from dominiq at lps dot ens dot fr 2007-10-12 06:58 ---
It works for my tests, so the simpler the better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33733
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-12 13:44 ---
> Have you tried building gcc trunk with the Xcode 2.5 Developer Preview ...?
No, I am at 2.4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-12 15:23 ---
The same on PPC Darwin: pr33749 with -m64 gives the expected result, but
pr33686 gives the same result for 32 and 64 bit modes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33749
--- Comment #11 from dominiq at lps dot ens dot fr 2007-10-12 13:47 ---
> In the case where the FORALL only fills part of the array P, yes.
If you mean, say "FORALL(I=2:3)", you are right! I overlooked this possibility.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33686
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-12 19:51 ---
> No, I am at 2.4.1.
I have installed Xcode 2.5 and rebuilt gcc and gfortran, but it did not
help!-(though I may have missed something else).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
--- Comment #33 from dominiq at lps dot ens dot fr 2007-10-12 20:31 ---
> It's an easy fix but let's do one thing at a time:-)
Sure! I have filled PR33759
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
the function, unless I am missing something.
--
Summary: Unequal character lengths in MERGE intrinsic not
detected in contained function.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-12 22:18 ---
Subject: Re: Unequal character lengths in MERGE intrinsic
not detected at run time
> scalar ("string") is conformable with any array (such as "tmp")
Yes, I missed that, so if the length of
--- Comment #5 from dominiq at lps dot ens dot fr 2007-10-13 21:52 ---
I have forgotten to say that it is a regression, the tests pass with version
4.3.0 20071004 (revision 129004) and fail at after version 4.3.0 20071005
)revision 129038).
--
dominiq at lps dot ens dot fr changed
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-15 15:51 ---
> that causes numerical results with CP2K to change going from -O0 to -O3.
If you do expect that optimization optimizes your computation, you should
expect some change of the numerical results, so put s
on Darwin
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 triplet: powerpc-app
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-18 12:55 ---
This regression affects also
gfortran.fortran-torture/execute/stack_varsize.f90.
A reduced test case is:
! Program to test the stack variable size limit.
program stack
call sub1
contains
! Local variables
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-18 13:40 ---
This seems to be a duplicate of PR33806, at least the ICE occurs at the same
point.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-18 14:32 ---
The same occurs in 32 bit mode, see for instance
http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00804.html
[karma] dominiq/Desktop% gfc -O2 -ftree-vectorize -maltivec
/opt/gcc/_gcc-clean/gcc/testsuite/gcc.dg/vect
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-18 14:37 ---
The PR started between revisions 129388 (works) and 129401 (does not).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-18 15:23 ---
> while we expand a constant integral power to an optimal (as of the count of
> multiplications / additions) series of multiplications and additions.
It seems the difference is coming from something else. I&
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-18 16:40 ---
May I guess revision 129400?
--- trunk/gcc/ChangeLog 2007/10/17 00:46:27 129399
+++ trunk/gcc/ChangeLog 2007/10/17 01:05:50 129400
@@ -1,3 +1,10 @@
+2007-10-17 Alan Modra <[EMAIL PROTEC
--- Comment #7 from dominiq at lps dot ens dot fr 2007-10-19 21:21 ---
After reverting the changes made in revision 129400 (otherwise revision 129491
+ gfortran patches), the gcc testsuite gives:
Target: powerpc-apple-darwin8
=== gcc tests ===
Schedule of variations:
unix
--- Comment #6 from dominiq at lps dot ens dot fr 2007-10-19 16:39 ---
See comment#2 of PR33806. I did not tested the gcc side.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33812
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-19 16:36 ---
I have reverted the changes made in revision 129400 and the reported errors
disappeared. Hence added Alan Modra to the cc list.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-19 15:12 ---
It is not in gcc version 4.3.0 20070713.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33818
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-19 15:07 ---
The bug is not present in 4.2.2, and appeared before revision 129038.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33818
--- Comment #14 from dominiq at lps dot ens dot fr 2007-10-21 20:05 ---
Now I understand the strange result I reported in comment #5. What is happening
is that there is a second nonprintable character. If I redirect the output to a
file I see it (in general ^@).
>From what I underst
--- Comment #7 from dominiq at lps dot ens dot fr 2008-08-08 21:50 ---
On i686-apple-darwin9, the testcase in comment #4 gives a "Bus error" at -m32
(rev. 138886).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
}
{
struct __st_parameter_dt dt_parm.6;
dt_parm.6.common.filename = &"pack_bug_red.f90"[1]{lb: 1 sz: 1};
dt_parm.6.common.line = 23;
dt_parm.6.format = &"(55L)"[1]{lb: 1 sz: 1};
dt_parm.6.format_len = 5;
dt_parm.6.common.flags = 4096;
dt_parm.6.common.unit = 6;
_gfortran_st_write (&dt_parm.6);
{
struct array1_logical(kind=4) parm.7;
integer(kind=4) D.1002;
D.1002 = i;
parm.7.dtype = 273;
parm.7.dim[0].lbound = 1;
parm.7.dim[0].ubound = 55;
parm.7.dim[0].stride = 1;
parm.7.data = (void *) &tmp[D.1002 * 55 + -55];
parm.7.offset = -56;
_gfortran_transfer_array (&dt_parm.6, &parm.7, 4, 0);
}
_gfortran_st_write_done (&dt_parm.6);
}
L.1:;
D.1013 = i == 1;
i = i + 1;
if (D.1013) goto L.2;
}
}
}
L.2:;
}
--
Summary: Wrong results when comparing a character array to a
character expression
Product: gcc
Version: 4.4.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=37099
nu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37104
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37105
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-d
--- Comment #1 from dominiq at lps dot ens dot fr 2008-08-13 12:40 ---
The strings must have more than one character to reproduce the bug:
integer, parameter :: n = 10
integer, parameter :: ilst(n) = (/(i,i=1,n)/)
character(*), parameter :: c0lst(n) = (/(char(96+i),i=1,n)/)
character
--- Comment #1 from dominiq at lps dot ens dot fr 2008-08-20 07:54 ---
Confirmed on i686-apple-darwin9 in 32-bit mode:
[ibook-dhum] lin/test% gfc -c -O2 -ftree-vectorize
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr33301.f
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect
--- Comment #4 from dominiq at lps dot ens dot fr 2008-08-21 09:15 ---
Same thing here on i686-apple-darwin9.
> Does the patch work for you?
No! I still get:
FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?
g
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: *-apple-darwin*
GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37185
--- Comment #6 from dominiq at lps dot ens dot fr 2008-08-21 15:33 ---
> But was the failures you see too introduced with r139233?
It is not in r139096, but appeared in r139293. So it is the right window, but I
don't have anything in between. From what I have seen it looks mor
--- Comment #10 from dominiq at lps dot ens dot fr 2008-08-21 19:06 ---
I have had a closer look to the failures on i686-apple-darwin9 and they are due
to the replacement of '.weak_definition' with '.indirect_symbol' in the
assembly code (the regexp problem seems
--- Comment #2 from dominiq at lps dot ens dot fr 2008-08-22 10:56 ---
Confirmed on i686-apple-darwin9 (both 32 and 64 bit modes). Compiling the test
with -fbounds-check gives at run time:
At line 18 of file pr37199.f90
Fortran runtime error: Array bound mismatch for dimension 1 of
--- Comment #15 from dominiq at lps dot ens dot fr 2008-08-22 11:48 ---
> I don't think this has anything to do with your patch.
Unfortunately it has (at least on i686-apple-darwin9). Reverting the patch for
gcc/varasm.c I have bootstrapped without any problem and the good news
--- Comment #16 from dominiq at lps dot ens dot fr 2008-08-22 11:51 ---
Note the patch in comment #12 minus the varasm.c part fixes also
FAIL: g++.dg/ext/weak2.C scan-assembler weak[^ \\t]*[ \\t]_?_Z3foov
All the results for 32-bit mode only, but I am pretty confident that they will
--- Comment #18 from dominiq at lps dot ens dot fr 2008-08-22 13:20 ---
> Could one (or both) please attach preprocessed code and command line so I can
> reproduce the ICE you see with the *whole* patch applied? I don't see it for
> neither cris-elf nor native and I don&
--- Comment #2 from dominiq at lps dot ens dot fr 2008-08-22 14:20 ---
I still see it at revision 139372. I am not yet at revision 139385 on ppc. I'll
start an update ASAP, result by tomorrow (~10 hours).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37104
--- Comment #23 from dominiq at lps dot ens dot fr 2008-08-22 14:53 ---
Here is the command line and its result from directory
/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libgcc:
[ibook-dhum] x86_64/libgcc% /opt/gcc/i686-darwin/./gcc/xgcc -v -save-temps
-B/opt/gcc/i686-darwin/./gcc
--- Comment #24 from dominiq at lps dot ens dot fr 2008-08-22 14:54 ---
Created an attachment (id=16129)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16129&action=view)
libggc2.i for i686-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
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 build triplet: *-apple-darwin*
GCC host triplet: *-apple-darwin*
GCC target triplet: *
--- Comment #2 from dominiq at lps dot ens dot fr 2008-08-22 16:17 ---
> This is a duplicate of 37170
I don't think so. Although I am bootstraping with the patch for 37170 and
cannot conclude yet, my previous attempt fixed the weak tests, but not the
visibility ones.
--
--- Comment #26 from dominiq at lps dot ens dot fr 2008-08-22 17:09 ---
Bootstrap fails at
[ibook-dhum] x86_64/libjava% /opt/gcc/i686-darwin/./gcc/xgcc -shared-libgcc
-B/opt/gcc/i686-darwin/./gcc -nostdinc++
-L/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libstdc++-v3/src
-L/opt/gcc
--- Comment #3 from dominiq at lps dot ens dot fr 2008-08-22 17:55 ---
Quick answer without a full bootstrap, the ICE is still there at rev. 139471.
Answer with a full bootstrap tomorrow morning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37104
--- Comment #2 from dominiq at lps dot ens dot fr 2008-08-24 09:17 ---
> Well, it seems that revision included enabling ipa-cp by default at -O2 ;)
May this explain the following failures (i686-apple-darwin9):
[ibook-dhum] f90/bug% gfc -O2
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran
--- Comment #4 from dominiq at lps dot ens dot fr 2008-08-24 14:13 ---
After applying the patch in comment #3, the ICE disappeared. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37185
--- Comment #33 from dominiq at lps dot ens dot fr 2008-08-24 16:46 ---
> All the results for 32-bit mode only, but I am pretty confident that they will
> hold with -m64.
This is wrong: the tests pass in 32-bit mode, but fail with -m64.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #34 from dominiq at lps dot ens dot fr 2008-08-24 16:50 ---
[ibook-dhum] f90/bug% gfc -m64 -S -fno-common
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/weak/weak-2.c
[ibook-dhum] f90/bug% grep ffoo1a weak-2.s
movq[EMAIL PROTECTED](%rip), %rax
--
http
--- Comment #2 from dominiq at lps dot ens dot fr 2008-08-25 08:53 ---
Same thing on i686-apple-darwin9 for both 32 and 64 bit modes. I have in
addition:
Running target unix/-m64
WARNING: program timed out.
FAIL: gfortran.fortran-torture/compile/logical-1.f90, -O2 -fomit-frame-pointer
--- Comment #38 from dominiq at lps dot ens dot fr 2008-08-25 09:56 ---
With the patch in comment #37 I bootstraped
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt
--- Comment #39 from dominiq at lps dot ens dot fr 2008-08-25 11:44 ---
More good news, the weak gcc tests pass now for 32 and 64 bit modes.
Also bad news, I have extra failures in the g++ tests (32-bit mode so far),
e.g.:
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite
--- Comment #40 from dominiq at lps dot ens dot fr 2008-08-25 13:35 ---
Here is the list of new g++ failures (32 and 64 bit modes, except
g++.dg/abi/empty7.C):
FAIL: g++.dg/abi/empty7.C (test for excess errors)<--- 32-bit mode only
FAIL: g++.dg/abi/layout2.C (test for exc
--- Comment #43 from dominiq at lps dot ens dot fr 2008-08-25 17:10 ---
> Patch #4 still fixes all "weak" test regressions on avr.
Did you test g++?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
401 - 500 of 2230 matches
Mail list logo
