--- Comment #17 from dominiq at lps dot ens dot fr 2010-04-27 15:27 ---
Created an attachment (id=20499)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20499action=view)
bziped tar file containing the *.i and *.s files
The *_f.* files corresponds to the failing bootstrap
--- Comment #13 from dominiq at lps dot ens dot fr 2010-04-27 20:08 ---
As pointed out in comment #10 pr38471 is a duplicate of this one, as well as
pr42851 (see comment #1 of pr43091). They all give the same backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory
--- Comment #35 from dominiq at lps dot ens dot fr 2010-04-26 08:23 ---
The testsuite completed cleanly, without any failures. Paul, if you agree that
this patch is ok, I can commit it tomorrow.
Confirmed without any problem on my own test.
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from dominiq at lps dot ens dot fr 2010-04-26 09:16 ---
This PR is likely due to revision 158639:
Author: bernds
Date: Thu Apr 22 10:42:21 2010 UTC (3 days, 22 hours ago)
Changed paths: 4
Log Message:
* ifcvt.c (dead_or_predicable): Use
--- Comment #8 from dominiq at lps dot ens dot fr 2010-04-26 12:28 ---
What happens if you replace the new call to df_simulate_find_noclobber_defs in
ifcvt.c with a call to df_simulate_find_defs?
Bootstrapping with the change (crossing my finger that I won't have to remove
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-26 13:15 ---
Subject: Re: [4.6 Regression] Bootstrap failure for
powerpc-apple-darwin9: cannot compute suffix of object files
One thing that would help would be to build just a stage1 compiler and target
libraries, then run
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-26 16:24 ---
What happens if you replace the new call to df_simulate_find_noclobber_defs
in
ifcvt.c with a call to df_simulate_find_defs?
Bootstrapping with the change (crossing my finger that I won't have to remove
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-25 14:31 ---
can you provide a backtrace of this crash ?
Putting a breakpoint at fancy_abort is not enough to get a backtrace:
[karma] gcc/darwin_buildw% gdb /opt/gcc/darwin_buildw/./gcc/xgcc
GNU gdb 6.3.50-20050815 (Apple
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-25 15:39 ---
Because you aren't debugging the right executable (xgcc instead of cc1). Pass
-v to the driver to get the command line involving cc1 and feed it to cc1
directly.
Thanks for the tip. The backtrace is
Program
--- Comment #21 from dominiq at lps dot ens dot fr 2010-04-25 16:38 ---
Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #18. The remaining regressions are:
* dynamic_dispatch_{1-3}.f03
I also have
[macbook] f90/bug% gfc
/opt/gcc/work/gcc
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-23 22:07 ---
It looks similar to pr43858.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43873
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-23 22:08 ---
PR 43873 looks similar to this pr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-22 11:51 ---
Same thing on x86_64-apple-darwin10: bootstrap fails at revision 158642 with
...
/opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/
-B/opt/gcc/gcc4.6p/x86_64-apple-darwin10/bin/
-B/opt/gcc/gcc4.6p/x86_64-apple
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=43858
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-21 17:09 ---
thanks for the reminder, Dominique
You're welcome!-)
Just another one: modulo spaces(?)
gcc/testsuite/gfortran.dg/dynamic_dispatch_7.f03 in trunk and
gcc/testsuite/gfortran.dg/dynamic_dispatch_9.f03 in fortran
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-21 20:48 ---
Confirmed. The test fails with gfortran from at least 4.2.3 up to trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43841
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-21 21:49 ---
It looks like a duplicate of PR 43841.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43843
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-21 21:51 ---
PR43843 looks like a duplicate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43841
--- Comment #24 from dominiq at lps dot ens dot fr 2010-04-20 09:18 ---
The patch in comment #23 works fine on my tests. Thanks for it.
Also included is the fix for PR43266, which was first posted on March 27 and
is
very 'obvious'.
Note for the record that it gives an additional
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-20 12:21 ---
Technically this PR, fixed on trunk but not on fortran-dev, is now a
[fortran-dev Regression]. Could it be marked that way?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
--- Comment #7 from dominiq at lps dot ens dot fr 2010-04-20 19:17 ---
Thanks for the heads up on this - I had completely forgotten this PR.
I was suspecting something like that;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-19 08:52 ---
Confirmed, probably introduced/uncovered between revisions 158215 (no ICE) and
158486 (ICE).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-19 09:17 ---
Also seen on powerpc64-unknown-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01669.html ).
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-19 09:30 ---
Dominique, you should ask for 'bug zilla confirmation rights' which will allow
to touch the 'Confirm' fields etc...
Do you WHO I should ask for 'bug zilla confirmation rights'?
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from dominiq at lps dot ens dot fr 2010-04-19 09:56 ---
If you have svn write access you have full bugzilla rights if you use
a bugzilla account with your @gcc.gnu.org address.
Indeed I don't have svn write access and I am not planning to ask for it in a
near future
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-19 10:56 ---
Confirmed on trunk with '-O[23] -m32 -fcheck=bounds' (compiles with '-O[01s]').
Works for me with 4.5 revision 157991 and 4.4.2 (with '-fbounds-check' instead
of '-fcheck=bounds'), hence at least a 4.6 regression
--- Comment #11 from dominiq at lps dot ens dot fr 2010-04-19 11:25 ---
Should not this PR closed as fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42517
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-19 12:33 ---
I decided to take a look at this during lunchtime today. The source that I
had
to hand is the 20091203 4.5.0 snapshot. To my astonishment, this does not
show
the problem. I have had a quick look
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-19 13:06 ---
When searching for the origin of the regression, one should use the test case
in comment #3 and look at the 4.5 trunk.
I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision
147438, 20090512
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-19 13:54 ---
I just checked r150724, which also fails. This means that both my guesses were
wrong. But at least it bring us down to the range 147438:150724 (which is
still
three months of development).
I don't have access
--- Comment #19 from dominiq at lps dot ens dot fr 2010-04-19 20:13 ---
Note that the patch in comment #7 fixes the test in comment #3 when the 'type
t_string' block is uncommented. But there is still a Segmentation fault when
the line
! procedure(string_to_char),pointer :: char2
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-18 11:48 ---
Marked as a 4.5/4.6 regression.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #28 from dominiq at lps dot ens dot fr 2010-04-18 13:55 ---
I am still getting the message:
Me too with a clean fortran-dev r158481.
Note that the patch in comment #25 fixes it without regression for the test
suite and my own tests.
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-18 15:04 ---
Confirmed for gcc version 4.4.2, but this pr seems to be fixed for 4.5 (at
least since revision 154654) and trunk. Unless someone is able to point when it
has been fixed and want to backport the fix to 4.4, this pr
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-18 15:28 ---
Both the bogus error and the ICE (also with std=f95) are still there. The PR
should be marked NEW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40728
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-18 15:37 ---
Confirmed. Note that between 4.4 and 4.5 the error from the second test of
comment #0 has changed from:
MODULE PROCEDURE myplus
1
Error: Intrinsic operator interface at (1) must
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-18 15:42 ---
Confirmed with trunk, fixed with fortran-dev.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41829
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-18 15:49 ---
Still there on trunk - should be marked as NEW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40994
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-18 15:56 ---
I cannot reproduce the error at
http://gcc.gnu.org/ml/fortran/2009-09/msg00298.html neither with trunk nor with
fortran-dev. Could this PR be more explicit about the problem?
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-18 16:18 ---
What about pr42274? Is it a duplicate or not?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-18 16:24 ---
The tests in comments #0 and #1 give a Segmentation fault with trunk or
fortran-dev.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41600
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-18 16:44 ---
Confirmed. Related to pr24978. Should probably be marked as blocking pr31392
and pr33056.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41922
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-18 16:47 ---
Currently, only the run-time version is implemented.
So could the pr marked as NEW?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41580
--- Comment #23 from dominiq at lps dot ens dot fr 2010-04-16 12:07 ---
PS This will block any direct or first attempt to build gcc by Mac owners
unless they try builds of intermediate versions of gcc.
Except for the funny state of my macbook before my last reboot, the failure
--- Comment #26 from dominiq at lps dot ens dot fr 2010-04-16 14:34 ---
First a Note for Ralf Wildenhues: I have seen somewhere that libgomp have been
added to stage2 starting from some revision, but I am unable to find where. Do
you have a better memory?
I think it is after 4.4 (so
--- Comment #9 from dominiq at lps dot ens dot fr 2010-04-16 17:38 ---
The run time error for
i = 0
a(i:1) = b(0:4)
is
At line 9 of file pr31538_db_2.f90
Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of
array 'a' (2/5)
for
i = 0
a(i:1) = f(b
--- Comment #9 from dominiq at lps dot ens dot fr 2010-04-16 20:15 ---
When compiled with -O2 -Wuninitialized, the reduced test of comment #3 gives
...
pr42169.f90: In function 'moment':
pr42169.f90:15:0: warning: 'lx' may be used uninitialized in this function
pr42169.f90:16:0
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=43758
Severity: normal
Priority: P3
Component: testsuite
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=43759
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-15 14:41 ---
... we can just default darwin to build plugin support as well.
I think the problem should be addressed (i.e., skip the tests) for any build
with plugins not enabled, even if --enable-plugin is the default
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-15 22:15 ---
This is a duplicate of pr43170.
A couple of questions:
(1) have you use the terminal for a long time with multiple windows/tabs?
(2) can you test gcc.c-torture/compile/limits-structnest.c -O2? It should take
--- Comment #17 from dominiq at lps dot ens dot fr 2010-04-15 22:16 ---
pr43761 is a duplicate of this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
--- Comment #17 from dominiq at lps dot ens dot fr 2010-04-14 09:55 ---
Well, it indeed looks invalid if there is NaNs involved and you use
-ffinite-math-only.
The NaN appears in the miscompiled executable. Note that I am not the author of
the doduc test, but it has been compiled
--- Comment #19 from dominiq at lps dot ens dot fr 2010-04-14 10:25 ---
Can you track where the NaN comes from and if it is indeed unexpected
even with -ffast-math -ffinite-math-only?
First '-ffast-math' implies '-funsafe-math-optimizations -ffinite-math-only'.
To reach
--- Comment #20 from dominiq at lps dot ens dot fr 2010-04-14 13:06 ---
I have been able to get the following values before the crash:
DEBav =
0.59252398402327489 1.58848116996742547E-002 2.31157896165751706E-002
8.33002598145726886E-002 9.03564427292446321E-002
--- Comment #7 from dominiq at lps dot ens dot fr 2010-04-14 13:26 ---
After revision 158291 I get
[macbook] f90/bug% time gfc pr19925_1.f90
pr19925_1.f90:2.27:
INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/)
1
Error: The number of elements in the array
--- Comment #8 from dominiq at lps dot ens dot fr 2010-04-14 17:34 ---
Iain,
Are you speaking of gcc/testsuite/gcc.dg/pr43058.c?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43753
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-13 14:09 ---
A few additional notes:
(1) with revision 158105 reverted, the test gcc.dg/tree-ssa/reassoc-19.c fails
with -m32, but passes with -m64.
(2) revision 158265 with/without revision 158105 reverted (after some surgery
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: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple
--- Comment #46 from dominiq at lps dot ens dot fr 2010-04-13 16:29 ---
Did anyone ever file a radar bug report on the inaccurate complex math from
http://compiler-rt.llvm.org/?
I did not see anything along this line in their bugzilla. However there is
comment #25
I've filed radr
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-13 20:45 ---
(In reply to comment #13)
Here we have index `i1' calculated from fp values and then casted to int.
Segmentation fault occurs in `y1 = y(i1)' with i1 equal to
0x800c.
This is in function S00061
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-11 08:11 ---
With the patch in comment #9 applied to the fortran-exp branch, the timing for
the original test is slightly slower than trunk ~250s compared to ~240s.
Note that the procedure node_copy_and_append should be deleted
--- Comment #11 from dominiq at lps dot ens dot fr 2010-04-11 08:26 ---
+ /* If we can successfully get an array element at the max array size then
s/can/cannot/ ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34554
--- Comment #41 from dominiq at lps dot ens dot fr 2010-04-11 15:36 ---
Has the issue in Comment 33/38 been reported on radar?
No. If you want to do it, be my guest!-(You got answer to my last one I did not
get, not even an acknowledgement).
--
http://gcc.gnu.org/bugzilla
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from dominiq at lps dot ens dot fr 2010-04-10 16:36 ---
Created an attachment (id=20354)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20354action=view)
Fortran source for subroutine S33022
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-10 16:38 ---
Created an attachment (id=20355)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20355action=view)
Fortran source for doduc.f90 with subroutine S33022 commented
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-10 16:39 ---
Created an attachment (id=20356)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20356action=view)
Working assembly for subroutine S33022
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #4 from dominiq at lps dot ens dot fr 2010-04-10 16:42 ---
Created an attachment (id=20357)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20357action=view)
Miscompiled assembly for subroutine S3302
The diff between the working (-) and miscompiled (+) assembly files
--- Comment #6 from dominiq at lps dot ens dot fr 2010-04-10 18:41 ---
Created an attachment (id=20358)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20358action=view)
doduc.in
Using built-in specs.
COLLECT_GCC=gfcp
COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple
--- Comment #7 from dominiq at lps dot ens dot fr 2010-04-10 18:49 ---
The problem seems to occur within these lines:
tt = -t*rmp/rm
z1at = -Dalb - Dalt
z2at = drg*(alt-2.*al) + drf*(alb-2.*al) + rg*Dalt +
rf*Dalb
--- Comment #9 from dominiq at lps dot ens dot fr 2010-04-10 19:32 ---
Created an attachment (id=20359)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20359action=view)
bzipped tar file with the outputs of -fdump-tree-reassoc
reassoc.tar.bz2 contains the files s33022_
--- Comment #33 from dominiq at lps dot ens dot fr 2010-04-09 20:56 ---
(In reply to comment #32)
Note that when using the patch in comment #22 triggers pr43254: another side
effect of -lm is to prevent the run of dsymutil even with -g.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-08 07:48 ---
With the patch in comment #14, the test in comment #1 compiles and gives:
evt= 234, flv= 1, col= 2, hel= 3, -0.122E-13 + i* 0.675E-14 ~ 0.267E-02
evt= 234, flv= 1, col= 2, hel= 6, -0.122E-13 + i*-0.675E
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-08 21:24 ---
Note there is no ICE with fortran-dev.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43696
.
--
Summary: FAIL: c-c++-common/raw-string-1.c
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
--- Comment #2 from dominiq at lps dot ens dot fr 2010-04-04 19:42 ---
Fails on sparc64-unknown-linux-gnu too (see
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00295.html ).
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2010-04-04 21:03 ---
Fails on hppa-unknown-linux-gnu too (see
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00313.html ).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43642
--- Comment #23 from dominiq at lps dot ens dot fr 2010-04-03 20:03 ---
The patch in comment #22 works as advertised without new regression (see
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00243.html).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
--- Comment #7 from dominiq at lps dot ens dot fr 2010-04-01 12:17 ---
(In reply to comment #6)
What is invaild about the code is that t1%p1() and t2%p2() are not
initialization expressions. Everthing works fine, when the tables are
allocatable.
That was the origin of my question
--- Comment #11 from dominiq at lps dot ens dot fr 2010-04-01 15:57 ---
The patch in comment #8 fixes the ICEs for the various reduced tests, however
for the original code I get
ward.f90:405.19:
end module ward_lib
1
Internal Error at (1):
gfc_is_constant_expr
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-01 16:43 ---
The following test
integer i
character*99 buffer
open(10,FILE=telltest.txt)
call ftell(10,i)
print*,i
read(10,'(a)') buffer
print *, ',trim(buffer),'
call ftell(10,i
--- Comment #18 from dominiq at lps dot ens dot fr 2010-04-01 20:47 ---
Patch, take 2: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00072.html
The patch fixes the test in comment #12 (with 11 instead of 10, my count
probably forgot an EOR) and the ftell_*.f90 regtest without
--- Comment #7 from dominiq at lps dot ens dot fr 2010-03-31 20:40 ---
+ assert (!targetm.have_tls TREE_CODE (decl) == VAR_DECL
+ DECL_THREAD_LOCAL_P (decl));
s/assert/gcc_assert/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
--- Comment #8 from dominiq at lps dot ens dot fr 2010-03-31 20:54 ---
With the patch in comment #6, I get:
[macbook] f90/bug% gcc45 -fprofile-generate -O3
/opt/gcc/work/gcc/testsuite/gcc.dg/matrix/transpose-1.c
gcc45: Internal error: Segmentation fault (program cc1)
Program received
--- Comment #6 from dominiq at lps dot ens dot fr 2010-03-30 16:48 ---
I do not get any ICE with the different 4.5 versions I have tried (oldest is
r156618). Could someone check that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
--- Comment #2 from dominiq at lps dot ens dot fr 2010-03-30 17:13 ---
... . I guess that we could tag every line for errors but this would need a
bigger change to error.c than I am prepared to embark on.
I understand that! Although there is no emergency to clean up the error
--- Comment #8 from dominiq at lps dot ens dot fr 2010-03-30 17:24 ---
I get the ICE with 4.4.2 (intel/ppc), 4.3.4, and 4.2.4 (ppc), but not on
trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
--- Comment #3 from dominiq at lps dot ens dot fr 2010-03-30 18:29 ---
Reduced test:
module ward_lib
implicit none
type omega_procedures
procedure(number_particles_out), nopass, pointer :: number_particles_out
= NULL()
procedure(number_flavor_states), nopass, pointer
--- Comment #4 from dominiq at lps dot ens dot fr 2010-03-30 19:55 ---
Further reduced test that does not give an ICE, but several errors:
[macbook] f90/bug% cat pr43591_red_1.f90
module ward_lib
implicit none
type omega_procedures
procedure(number_particles_out), nopass
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-30 20:00 ---
Confirmed:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x0001000674c8 in parse_spec (st=ST_INTERFACE) at
../../p_work/gcc/fortran
--- Comment #11 from dominiq at lps dot ens dot fr 2010-03-26 12:45 ---
Closing as fixed. Thanks for the work.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #9 from dominiq at lps dot ens dot fr 2010-03-26 13:29 ---
Following revision 157731 the number of failures for the objc and obj-c++
testsuite on *-apple-darwin* has drastically decreased. Iain, thanks a lot for
the hard work.
Should I close this PR as fixed, leaving people
--- Comment #10 from dominiq at lps dot ens dot fr 2010-03-26 13:35 ---
Is there any plan to backport the patches to 4.4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
--- Comment #24 from dominiq at lps dot ens dot fr 2010-03-26 13:38 ---
The result of regression testing for all languages but ADA on
powerpc-apple-darwin9 with -m32 and -m64 with the patch committed on trunk at
revision 148568 posted at
http://gcc.gnu.org/ml/gcc-testresults/2010-03
, at
fortran/trans-types.c:995
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
--- Comment #13 from dominiq at lps dot ens dot fr 2010-03-26 13:53 ---
(In reply to comment #12)
Is there any plan to backport the patches to 4.4?
I'll look at that in the next couple of weeks.
If this a sort of yes, I am leaving the PR open. If at some point you decide
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-26 20:35 ---
Reduced test
program sizetest1
use ISO_C_BINDING
implicit none
type contains_pointer
integer data
type(contains_pointer), pointer :: next
end type contains_pointer
type
--- Comment #6 from dominiq at lps dot ens dot fr 2010-03-25 07:45 ---
So, please find out what the difference actually is. The intended difference
is just that the whole __i686.get_pc_thunk.* snippet is moved from the end of
the
file to before .debug_frame/.debug_info and .LF
--- Comment #8 from dominiq at lps dot ens dot fr 2010-03-25 08:58 ---
Created an attachment (id=20194)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20194action=view)
diff between the assemblies for working and nonworking cases
The attachment is the result of the following
401 - 500 of 2212 matches
Mail list logo
