--- Comment #9 from dominiq at lps dot ens dot fr 2009-10-31 17:13 ---
The '.*?' is the non greedy form of '.*'.
I have learnt regexps at a time when this was not available on all regexp
engines, so I always forget such constructs.
I think pr41890 is a duplicate of this one
--- Comment #6 from dominiq at lps dot ens dot fr 2009-10-29 14:36 ---
Without test the part '.*?' in the rerexps seems odd. Why not '.*' only? My
practice of regexp taught me that '.*' is asking for trouble and, when
possible, should be replaced by [^some pattern]*. Why not call[^Z
--- Comment #12 from dominiq at lps dot ens dot fr 2009-10-28 16:27 ---
+ ((!e-value.function.esym
is the ! at the right place? If e-value.function.esym == 0, would not
e-value.function.esym-result == e-value.function.esym
gives a bus error/segmentation fault?
--
http
--- Comment #4 from dominiq at lps dot ens dot fr 2009-10-28 21:41 ---
On i686-apple-darwin9, with the patch I get:
Running target unix
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file
--- Comment #6 from dominiq at lps dot ens dot fr 2009-10-25 13:55 ---
The patches in comment #1 and #5 seem to work as advertized (currently
regtesting).
After having looked at the f2003 standard draft, I understand that
allocate(a, source=t2(1,2))
is equivalent to
allocate(t2
--- Comment #9 from dominiq at lps dot ens dot fr 2009-10-25 15:34 ---
(In reply to comment #8)
It seems that the patch in comment #2 has been silently applied
Not exactly silently. It was pr38672
Thanks for the pointer. This PR has not been marked as a duplicate of pr38672
--- Comment #7 from dominiq at lps dot ens dot fr 2009-10-25 17:20 ---
(In reply to comment #6)
Did I missed something in the standard or is this a bug?
Probably the former!-(If I move
a%j=2
inside the type is (t2) block, the code compiles without error).
--
http://gcc.gnu.org
--- Comment #7 from dominiq at lps dot ens dot fr 2009-10-25 18:34 ---
With the patch in comment #5 I got two extra errors for my tests:
modification of pr30793 (comment #7)
pr30793_red.f90:151.10:
mshp = msh_(quality)
1
Error: Function 'msh_' at (1) has no IMPLICIT type
--- Comment #2 from dominiq at lps dot ens dot fr 2009-10-24 12:12 ---
The tests fail also on powerpc-apple-darwin9 when compiled with -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41812
--- Comment #2 from dominiq at lps dot ens dot fr 2009-10-23 07:37 ---
Reduced test case:
module abstract_gradient
implicit none
public :: vector_class
public :: inner_product_class
public :: gradient_class
private
type, abstract :: vector_class
end type vector_class
--- Comment #1 from dominiq at lps dot ens dot fr 2009-10-23 12:46 ---
The code in comment #0 gives errors with gfortran 4.4.1 and 4.5.0 (recent
patched trunk), compiles with 4.3.4, and gives an ICE with 4.2.4. Also compiles
with ifort and gives an ICE with g95.
--
http
--- Comment #7 from dominiq at lps dot ens dot fr 2009-10-23 15:01 ---
It seems that the patch in comment #2 has been silently applied (I have been
unable to find when) and that the test in comment #0 no longer gives an ICE for
gfortran 4.3.4, 4.4.1, and trunk.
Apparently the failure
--- Comment #12 from dominiq at lps dot ens dot fr 2009-10-23 19:34 ---
I propose the attached patch. It's an extended version of Paul's patch from
comment #5, plus Mikael's comment #10. It makes Salvatore's PSBLAS compile
completely (at least the version I have).
Does
--- Comment #7 from dominiq at lps dot ens dot fr 2009-10-22 14:39 ---
(In reply to comment #5)
Created an attachment (id=18865)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18865action=view) [edit]
A fix for the PR
If I add
@@ -4008,6 +4014,9 @@ load_derived_extensions (void
--- Comment #9 from dominiq at lps dot ens dot fr 2009-10-22 20:09 ---
(In reply to comment #8)
The ICEs do go away, but on Salvatore's original code I now get: ...
I get such problem now and then when using an obsolete module file and in
general it goes away after recompiling it. Now
--- Comment #1 from dominiq at lps dot ens dot fr 2009-10-19 10:23 ---
Confirmed on (i686|powerpc)-apple-darwin9 revision 152966. On
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41753
--- Comment #1 from dominiq at lps dot ens dot fr 2009-10-19 14:08 ---
Gives
pr41755.f90:2.28:
equivalence (aa,a) (bb,cc)
1
Error: Syntax error in EQUIVALENCE statement at (1)
with gfortran 4.2.4, and a bus error at compile time with 4.3.4
--- Comment #9 from dominiq at lps dot ens dot fr 2009-10-16 08:13 ---
(In reply to comment #8)
This seems to work. (Although I thought I saw once for the z4 value.)
With the following changes
program z
implicit none
integer,parameter :: k8 = selected_real_kind (precision
--- Comment #1 from dominiq at lps dot ens dot fr 2009-10-15 07:59 ---
The manual reads:
VALUES The type shall be REAL, DIMENSION(2).
where I understand REAL as REAL(4). Hence if you want to use -fdefault-real-8,
you have to avoid the promotion of the ETIME argument by using
real
--- Comment #6 from dominiq at lps dot ens dot fr 2009-10-15 09:25 ---
Note that the same problem occurs for REAL(16) on powerpc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711
--- Comment #1 from dominiq at lps dot ens dot fr 2009-10-14 08:42 ---
I don't get an ICE with the coed in comment#0. However I get one with the
following (valid?) changes:
type t0
integer :: j = 42
end type t0
type t
integer :: i
class(t0), allocatable :: foo(:)
end type t
type
--- Comment #8 from dominiq at lps dot ens dot fr 2009-10-13 17:01 ---
It would be interesting to get the opinion of Richard Maine.
watch
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/fbd60d05c9e683e4#
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41678
--- Comment #9 from dominiq at lps dot ens dot fr 2009-10-13 18:03 ---
It would be interesting to get the opinion of Richard Maine.
...
The wording in the f2003/2008 drafts I have at hand is more ambiguous:
...
Does a io-unit in C917 includes the optional characters UNIT
--- Comment #1 from dominiq at lps dot ens dot fr 2009-10-12 07:19 ---
The F95 standard says:
The F, E, EN, ES, and D edit descriptors specify the editing of real and
complex data.
An input/output list item corresponding to an F, E, EN, ES, or D edit
descriptor shall be real
--- Comment #15 from dominiq at lps dot ens dot fr 2009-10-12 07:39 ---
The polyhedron test linpk.f90 now fails with:
[ibook-dhum] lin/test% linpk
norm. resid resid machep x(1) x(n)
At line 38 of file linpk.f90 (unit = 6, file = 'stdout')
Fortran
--- Comment #3 from dominiq at lps dot ens dot fr 2009-10-12 12:46 ---
In the original test case:
real :: i
The part that is rejected incorrectly is the format label.
I assumed i was an integer. F95 says:
Constraint: If the optional characters FMT= are omitted from the format
--- Comment #5 from dominiq at lps dot ens dot fr 2009-10-12 13:00 ---
I think the problem is here (around line 706 in the last commit):
if (t == FMT_F || t == FMT_EN || t == FMT_ES || t == FMT_D
|| t == FMT_G || t == FMT_E)
{
repeat = 1
--- Comment #6 from dominiq at lps dot ens dot fr 2009-10-12 13:31 ---
Comment #5 was intended for pr38439.
ahh, I was looking at the F2003 Standard which is not as clear. However, is
this relaxation in F2003 done on purpose? I found the rejected code in the
IBM
compiler manual
--- Comment #17 from dominiq at lps dot ens dot fr 2009-10-12 13:31 ---
I think the problem is here (around line 706 in the last commit):
if (t == FMT_F || t == FMT_EN || t == FMT_ES || t == FMT_D
|| t == FMT_G || t == FMT_E)
{
repeat = 1
--- Comment #7 from dominiq at lps dot ens dot fr 2009-10-12 17:38 ---
Works for me at revision pr152662 and with the patches for pr41629 and pr41656
(latest avatars).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41685
--- Comment #4 from dominiq at lps dot ens dot fr 2009-10-10 18:08 ---
Subject: Re: FAIL: gfortran.dg/round_2.f03
I am not sure that the change will allow the compilation if k0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41612
--- Comment #6 from dominiq at lps dot ens dot fr 2009-10-08 08:43 ---
The use of common in the context of this PR badly hurts my understanding of
commons: storage arrays computed at compile time. The standard says (f2008):
5.7.2 COMMON statement
5.7.2.1 General
1 The COMMON
--- Comment #4 from dominiq at lps dot ens dot fr 2009-10-07 09:45 ---
The fix in revision 152513 has been regtested without regression. Closing as
fixed.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2009-10-07 23:57 ---
Confirmed for gfortran 4.3.4, 4.4.1, and trunk. The code compiles with gfortran
4.2.4, thus this is a regression. Reduced test:
module testmod
integer, parameter :: r8 = selected_real_kind(12)
type
: 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: powerpc-apple-darwin*
GCC host triplet: powerpc-apple-darwin*
GCC target triplet
on powerpc-
apple-darwin
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot
, at
cp/decl.c:9305
Product: gcc
Version: 4.5.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
--- Comment #11 from dominiq at lps dot ens dot fr 2009-10-01 20:18 ---
There is probably a bug with round to nearest for values below 1:
print '(RN, 4F10.3)', 0.0625, 0.1875
print '(RN, 4F10.2)', 0.125, 0.375, 1.125, 1.375
print '(RN, 4F10.1)', 0.25, 0.75, 1.25, 1.75
print '(RN
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-30 08:52 ---
Confirmed. Works with gfortran 4.2.4, but not with 4.3.4, 4.4.1, and trunk,
hence a regression.
As noted,
character(3), parameter :: parm(5) = (/'xo ','yo ','ag ','xr ','yr '/)
works.
--
http
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-27 09:59 ---
I also see it on *-apple-darwin9 gcc 4.2.4, 4.3.4, 4.4.1, and trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-27 10:04 ---
Regarding the intent(out) issue. I will defer to others.
If the issue is valid, this a [4.3/4.4/4.5 Regression]. On *-apple-darwin9 GCC
4.2.4 gives:
[ibook-dhum] f90/bug% gfc42 pr41479.f90
[ibook-dhum] f90/bug
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-27 11:44 ---
Running valgrind I got:
--77271-- /Volumes/MacBook/opt/gcc/gcc4.5w/lib/libgfortran.3.dylib:
--77271-- dSYM directory has wrong UUID; consider using --auto-run-dsymutil=yes
--77271-- /Volumes/MacBook/opt/gcc/gcc4.5w
--- Comment #6 from dominiq at lps dot ens dot fr 2009-09-27 11:45 ---
Works for me on FreeBSD.
Is anyone understanding why?
valgrind gives:
==77290== Invalid free() / delete / delete[]
==77290==at 0x167FB: free (vg_replace_malloc.c:323)
==77290==by 0x2EAE: MAIN__
--- Comment #2 from dominiq at lps dot ens dot fr 2009-09-26 12:10 ---
How's that a GCC bug?
Can you PROVE it is not? If you have a PROOF, could you be kind enough to post
it so we can fill a bug report upstream. Meanwhile the WAITING status is fine.
--
dominiq at lps dot ens dot
--- Comment #6 from dominiq at lps dot ens dot fr 2009-09-26 19:10 ---
I also see similar failures on i686-apple-darwin9 in 32-bit mode (but not with
-m64) for
gcc.dg/tree-prof/bb-reorg.c and gcc.dg/tree-prof/pr34999.c:
output is:
/var/tmp//cc3DMvjA.s:230:FATAL:Symbol _foo.eh already
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-26 22:41 ---
Same thing on powerpc-apple-darwin9 at revision 152186 with -m64. I don't see
it on i686-apple-darwin9 at revision 152156.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41474
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-25 06:34 ---
Bootstrapped successfully powerpc-apple-darwin9 at revision 152135. Thanks for
the fix. Closing as fixed.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: bootstrap
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
--- Comment #67 from dominiq at lps dot ens dot fr 2009-09-25 21:40 ---
I have opened pr41473 to track the remaining issue with dsymutil. Closing this
PR as fixed. Please reopen if you disagree.
--
dominiq at lps dot ens dot fr changed:
What|Removed
: unassigned at gcc dot gnu 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=41457
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-24 08:56 ---
Created an attachment (id=18643)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18643action=view)
c-format.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41457
--- Comment #61 from dominiq at lps dot ens dot fr 2009-09-24 09:05 ---
I have followed a path different from the one in comment #58, trying to use
-gstrict-dwarf during bootstrap. For that I have made the following changes:
diff -uN ../_gcc_clean/config/mh-intel-darwin config/mh-intel
--- Comment #2 from dominiq at lps dot ens dot fr 2009-09-24 09:10 ---
Patches should be posted to gcc-patches.
This is not a patch, it is the best way I have found to describe the PR. Would
have it be better to report
gcc/testsuite/gcc.dg/guality/example.c fails on Darwin
--- Comment #62 from dominiq at lps dot ens dot fr 2009-09-24 09:40 ---
See also http://gcc.gnu.org/ml/gcc/2009-09/msg00500.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
--- Comment #49 from dominiq at lps dot ens dot fr 2009-09-23 09:28 ---
With the patch in comment #45 I bootstrapped revision 152032 on
powerpc-apple-darwin9. I still have:
17913 - libtool: link: dsymutil .libs/libstdc++.6.dylib || :
17914 : Assertion failed: (orig_str), function
--- Comment #41 from dominiq at lps dot ens dot fr 2009-09-22 21:00 ---
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison
--- Comment #21 from dominiq at lps dot ens dot fr 2009-09-21 08:05 ---
Changed the subject to reflect the comments.
[this might not be quite enough; backing out of only 151814-151815 for trunk
version 151904 produced a working bootstrap but with still some dsymutil
fails].
I don't
--- Comment #24 from dominiq at lps dot ens dot fr 2009-09-21 12:19 ---
Patch implementing -gstrict-dwarf (darwin would need to set it to 1 unless
explicitly set on the command line). I went through all the DWARF 3 and DWARF
4 additions used by dwarf2out.c, except DW_CFA_* so far
--- Comment #13 from dominiq at lps dot ens dot fr 2009-09-20 15:24 ---
The culprit is indeed r151815. Reverting the change after having updated to
r151893 on i686-apple-darwin9 ( r151895 on powerpc-apple-darwin9) allows a
successful bootstrap (currently building the libs on powerpc
--- Comment #21 from dominiq at lps dot ens dot fr 2009-09-20 15:36 ---
In reply to comment #20
bootstrap also fails on OpenBSD/i386 when it used to work a week ago ie:
gcc version 4.5.0 20090913 (experimental) (GCC)
You may try to revert revision 151815 (see pr41405, the patch
151873 on
*-apple-darwin9
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-19 14:01 ---
Have a look at http://linux.die.net/man/l/dgetrf for the calling convention.
The following works for me:
program det_test
implicit none
integer, parameter :: p15=selected_real_kind(15)
integer :: ipiv(2
--- Comment #2 from dominiq at lps dot ens dot fr 2009-09-19 21:31 ---
this means this is a darwin bug, dsymutil abort()s. Please report to apple
instead.
What should I report to apple? gcc 4.5.0 is working probably at least up to
revision 151807 (currently building libjava
--- Comment #3 from dominiq at lps dot ens dot fr 2009-09-19 21:40 ---
When bootstrapping r151807 will finish (couple hours from now). I am planning
to bootstrap r151815.
What is the estimated likelihood that the problem is triggered by
* dwarf2out.c (loc_descriptor): Emit
--- Comment #3 from dominiq at lps dot ens dot fr 2009-09-17 10:39 ---
See also http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01511.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41385
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-17 20:08 ---
4.2.4 gives
pr41389.f90:19.20:
public :: Get_flag, Set_flag
1
Error: 'flag_' is of a PRIVATE type and cannot be a dummy argument of
'get_flag', which is PUBLIC at (1)
probably a bug fixed
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-17 20:34 ---
Between revisions 151150 (-m64 only) and 151446 (both -m32 and -m64) the test
has started to fail also in 32 bit mode with a different wrong result:
karma] f90/bug% gfc -O3 where_2.f90
[karma] f90/bug% a.out
--- Comment #5 from dominiq at lps dot ens dot fr 2009-09-17 20:54 ---
At revision 151771 the test in the test suite still fails at -m64, but passes
with the addition of the print:
--- where_2.f90 2005-07-04 08:24:26.0 +0200
+++
/opt/gcc/_gcc_clean/gcc/testsuite
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-16 08:45 ---
The test is also rejected by g95 and ifort, the latter gives:
error #7128: A derived-type-def must have at least one component-def-stmt.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41369
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-14 03:21 ---
Same failure on powerpc-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41350
--- Comment #25 from dominiq at lps dot ens dot fr 2009-09-06 09:56 ---
Dominique,
Also if you are bothering to run the test suite on i686-apple-darwin9
periodically, you might as well shoot the results over to the gcc-testresults
mailing list (since Apple has never set up
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-04 11:44 ---
On i686-apple-darwin9 my latest regtest (r151159) shows:
=== libjava tests ===
Running target unix
=== libjava Summary for unix ===
# of expected passes2574
Running
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-04 12:22 ---
The bootstrap completes normally now on x86_64-apple-darwin10 with r151394.
Same here for r151388 on powerpc-apple-darwin9 and r151393 on
i686-apple-darwin9. Apparently Vladimir's commit at r151388 (thanks!-). So
--- Comment #20 from dominiq at lps dot ens dot fr 2009-09-04 12:24 ---
this also applies to powerpc-apple-darwin8 at least at 151409
This should be fixed now (try r151388 or newer, see pr41237).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
--- Comment #22 from dominiq at lps dot ens dot fr 2009-09-04 16:41 ---
When you run ./config ..., you should see
rm: conftest.dSYM: is a directory
checking for default BUILD_CONFIG... conftest.o.g0.stripped
conftest.o.g.stripped differ: char 23, line 2
stripping off .eh_frame
--- Comment #30 from dominiq at lps dot ens dot fr 2009-09-03 07:09 ---
This is a regression from gcc 4.3.4 (gfc=trunk r151295, gfc44=4.4.1,
gfc43=4.3.4):
[ibook-dhum] test/dbg_air% gfc -S -m64 -O2 -funsafe-math-optimizations
air_db.f90
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=41237
--- Comment #31 from dominiq at lps dot ens dot fr 2009-09-03 11:20 ---
More reduced nonfunctional (invalid) test to show the problem:
IMPLICIT REAL*8(a-H,O-Z)
PARAMETER (NX=150,NY=150)
DIMENSION NPX(30), FV2(NX,NY), T(NX,NY), dtt(NX,NY)
do it = 1, 2000
--- Comment #16 from dominiq at lps dot ens dot fr 2009-09-03 16:07 ---
Is there actual differences or is the stage2 binary empty like
on x86_64-apple-darwin10?
The file I looked at (was stage2-gcc/intl.o) was empty.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
--- Comment #17 from dominiq at lps dot ens dot fr 2009-09-03 16:15 ---
If I am not mistaken, strip on darwin does not strip the DWARF stuff by default
nor with the options I have tried (including -S file.o -o out_file).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu 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=41224
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-02 13:15 ---
This is likely due to r151311, hence added Alexandre Oliva in the CC list.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2009-09-02 13:40 ---
Does this also effect i*86-apple-darwin* and x86_64-apple-darwin*?
I don't know since I did not updated trunk on my macbook. I am waiting for the
mess be sorted out before doins so.
--
http://gcc.gnu.org
--- Comment #5 from dominiq at lps dot ens dot fr 2009-09-02 15:07 ---
Would you please run:
[karma] gcc/darwin_buildw% ../_gcc_clean/contrib/compare-debug --preserve
stage2-gcc/intl.o stage3-gcc/intl.o
strip: symbols referenced by relocation entries that can't be stripped in:
/opt
--- Comment #7 from dominiq at lps dot ens dot fr 2009-09-02 16:11 ---
I had a look at contrib/compare-debug: neither 'objcopy' nor 'strip --help'
works on darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
--- Comment #10 from dominiq at lps dot ens dot fr 2009-09-02 16:39 ---
For the hello test in comment #7 of pr41228 I get:
[karma] gcc/darwin_buildw% ../_gcc_clean/contrib/compare-debug --preserve
hello-g0.o hello-g.o
hello-g0.o.stripped hello-g.o.stripped differ: char 23, line 2
--- Comment #10 from dominiq at lps dot ens dot fr 2009-09-02 20:27 ---
I wonder if this could be the same reason that the comparison of stage2
and stage3 fails on powerpc-apple-darwin9 (PR41224)?
I don't think so, strip (if it does anything) is leaving DWARF stuff in the *.o
files
--- Comment #29 from dominiq at lps dot ens dot fr 2009-09-01 09:37 ---
Does anyone understand why commenting a write can change crtl-maybe_hot_insn_p
from 1 to 0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
--- Comment #2 from dominiq at lps dot ens dot fr 2009-09-01 13:37 ---
Confirmed on (powerpc|i686)-apple-darwin9 in 32 bit mode and -O2 or above. This
is a regression: I get 1.21306131891052 with gcc 4.2.4, 4.3.4, and 4.4.1. I
also get 1.21306131891052 with recent revisions of trunk
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-01 23:52 ---
The test works on trunk. I think it is a variant (duplicate?) of pr39876 that
has been fixed on trunk. The fix could probably be backported to 4.4.2 without
too much trouble.
--
http://gcc.gnu.org/bugzilla
--- Comment #24 from dominiq at lps dot ens dot fr 2009-08-31 13:06 ---
(In reply to comment #23)
Aren't these compile lines identical?
Apparently no, -funsafe-math-optimizations turns on optimization(s) that cannot
be undone by
-fno-signed-zeros -fno-trapping-math -fno-associative
--- Comment #25 from dominiq at lps dot ens dot fr 2009-08-31 15:04 ---
If I compare the results of -fdump-tree-original for the first 2 cases of
comment #21 I get:
[ibook-dhum] test/dbg_air% gfc -m64 -O2 -funsafe-math-optimizations
-fdump-tree-original air_db.f90
[ibook-dhum] test
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: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-01 01:09 ---
From http://linux.die.net/man/3/strnlen:
...
Conforming to
This function is a GNU extension.
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41205
--- Comment #20 from dominiq at lps dot ens dot fr 2009-08-28 07:19 ---
It it helps, I get for the reduced test with the line 94:
[ibook-dhum] lin/test% gfc -m64 -O2 -funsafe-math-optimizations
-fno-signed-zeros -fno-trapping-math -fno-associative-math -fno-reciprocal-math
air_db.f90
--- Comment #21 from dominiq at lps dot ens dot fr 2009-08-28 12:01 ---
And finally the winner is -fstrict-overflow!
[ibook-dhum] lin/test% gfc -m64 -O2 -funsafe-math-optimizations air_db.f90
[ibook-dhum] lin/test% time a.out /dev/null
6.472u 0.020s 0:06.50 99.8% 0+0k 0+2io 0pf+0w
--- Comment #22 from dominiq at lps dot ens dot fr 2009-08-28 12:23 ---
For the original air.f90 I get:
[ibook-dhum] lin/test% gfc -m64 -O2 -funsafe-math-optimizations
-fno-strict-overflow air.f90
[ibook-dhum] lin/test% time a.out /dev/null
9.572u 0.055s 0:09.66 99.5% 0+0k 0+9io
--- Comment #17 from dominiq at lps dot ens dot fr 2009-08-27 21:59 ---
Created an attachment (id=18439)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18439action=view)
reduced test without any subroutine
I have attached a reduced test without any subroutine. It requires the same
--- Comment #19 from dominiq at lps dot ens dot fr 2009-08-28 05:39 ---
Why don't you go back to the original test case and see which component of
-funsafe-math-optimizations...
-fno-signed-zeros -fno-trapping-math -fassociative-math -freciprocal-math
is actually causing
--- Comment #47 from dominiq at lps dot ens dot fr 2009-08-26 10:32 ---
Created an attachment (id=18427)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18427action=view)
Self contained reduced test for pr40440
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
801 - 900 of 2212 matches
Mail list logo
