--- Comment #11 from dominiq at lps dot ens dot fr 2008-10-14 10:14 ---
> I confirm the opt-1/opt-2 failures on i686-linix and x86_64-linux when using
> -fpic or -fPIC:
> ...
> The issue is not darwin-specific.
Digging the archives the failures on x86_64-linux when using -f
--- Comment #7 from dominiq at lps dot ens dot fr 2008-10-15 14:33 ---
The patch on comment #6 works as advertised without regression
(i686-apple-darwin9).
Thanks for the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37723
--- Comment #14 from dominiq at lps dot ens dot fr 2008-10-15 18:54 ---
> ... I don't know how to do that ...
What I do is to edit the file gcc/DATESTAMP to have
[revision number] date
instead of just
date
The minor drawback is that there is a conflict with svn update each
--- Comment #15 from dominiq at lps dot ens dot fr 2008-10-15 18:58 ---
I have forgotten to say that I also put the revision numbers in the name of the
logs of the tests so I can grep the files for some pattern and have the list of
the revisions for which it appears.
--
http
--- Comment #3 from dominiq at lps dot ens dot fr 2008-10-16 13:17 ---
gfortran 4.3.2 and 4.4.0 give the following error:
pr37848.f90:32.23:
!$OMP PRIVATE(l,ni,M,N)
1
Error: Object 'g_junct' is not a variable at (1)
The program compiles (and execu
--- Comment #1 from dominiq at lps dot ens dot fr 2008-10-16 14:39 ---
> ... so I guess I'm the only one impacted. ...
Which revision? I don't have gfortran regression at r141150 on
i686-apple-darwin9 and r141139 powerpc-apple-darwin9.
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from dominiq at lps dot ens dot fr 2008-10-16 15:16 ---
> Somehow my compiler can't manage it.
Could you try a more recent version: 4.3.2 or 4.4.0: as I said in comment #3,
the ICE has ben replaced by an error (I am not fluent enough with openmp to say
if it is
--- Comment #4 from dominiq at lps dot ens dot fr 2008-10-16 15:32 ---
> I want to add padding but only in 32 bit mode and only on some platforms.
Are not these information provided by the config steps, hence available when
building gfortran?
--
http://gcc.gnu.org/bugzi
--- Comment #1 from dominiq at lps dot ens dot fr 2008-10-16 15:49 ---
Fails also on PPC/Intel Darwin9, 32 and 64 bit modes. The first time I see the
failure is for r137631 (Intel).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
--- Comment #4 from dominiq at lps dot ens dot fr 2008-10-17 12:54 ---
Looks like pr37808, supposed to be fixed at r 14178.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850
--- Comment #8 from dominiq at lps dot ens dot fr 2008-10-18 09:31 ---
(In reply to comment #7)
> This prints "2 2" at the moment, which seems quite reasonable to me; or does
> the standard enforce it should print "2 1"?
ifort returns "2 2" and g9
--- Comment #7 from dominiq at lps dot ens dot fr 2008-10-20 08:56 ---
With ifort (IFORT) 10.1 20070913, I get:
fortcom: Error: pr35971_red.f90, line 11: Syntax error, found IDENTIFIER
'INTERFACE' when expecting one of: => = . ( : %
abstract interface
^
f
--- Comment #3 from dominiq at lps dot ens dot fr 2008-10-22 14:24 ---
I am not 100% sure that the following is due to the patch in comment #1, but
the following code segfaults (at the write) after having applied it:
integer :: i(1) = 1
integer :: foo(3)
foo = 17
print *, i
at
revision 141303
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
--- Comment #2 from dominiq at lps dot ens dot fr 2008-10-23 20:30 ---
> Modified code from a comment for PR36091
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091#c3
First the code came from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610#c16
Second, if I change the lower
--- Comment #5 from dominiq at lps dot ens dot fr 2008-10-23 20:34 ---
> As a side note I'm really impressed by how fast you found a not-working
> case to my slowly and laboriously prepared code.
Don't worry, it is always much easier to find (others') bugs
--- Comment #5 from dominiq at lps dot ens dot fr 2008-10-24 05:48 ---
> Quickfix (understand: not regression tested): ...
With the patch the temporary has the right size, but there is one regression:
FAIL: gfortran.dg/array_constructor_15.f90 -O scan-tree-dump-times original
&q
--- Comment #6 from dominiq at lps dot ens dot fr 2008-10-27 19:24 ---
For the record, the patch in comment #1 conflicts with the patch in
http://gcc.gnu.org/ml/fortran/2008-10/msg00256.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091
--- Comment #5 from dominiq at lps dot ens dot fr 2008-10-28 13:30 ---
On *-Darwin9 I get:
i = transfer(-1,1.0)
1
Error: Arithmetic overflow converting REAL(4) to INTEGER(4) at (1). This check
can be disabled with the option -fno-range-check
If I use the option -fno
--- Comment #7 from dominiq at lps dot ens dot fr 2008-10-28 14:36 ---
> What does ... print?
NaN on both ppc/intel-Darwin9.
> My patch simply fixes the ICE in gfortran.
I think the conversion of NaN to int is buggy since the behavior is
platform/option dependent. Your patc
--- Comment #9 from dominiq at lps dot ens dot fr 2008-10-28 17:18 ---
The patch in comment #8 works as expected on my tests and regtest without
regression but conflicts with the patch for pr35681 in
http://gcc.gnu.org/ml/fortran/2008-10/msg00256.html.
Some synchronization seems needed
--- Comment #12 from dominiq at lps dot ens dot fr 2008-10-28 17:51 ---
(In reply to comment #8)
> i = NaN is an assignment not a bitwise copy. This isn't platform
> dependent nor option dependent. You simply can't assign a NaN to
> an INTEGER.
Before the assi
--- Comment #22 from dominiq at lps dot ens dot fr 2008-10-31 12:52 ---
> One can argue that a NaN real(4)->real(8) conversion is OK or that it is
> invalid - I think one can find arguments for both; in any case NaN can be
> unambiguously converted from one real/complex to
--- Comment #18 from dominiq at lps dot ens dot fr 2008-11-01 12:32 ---
I have run the tests in comment #1 and main.bad main.init still fail on
i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
--- Comment #7 from dominiq at lps dot ens dot fr 2008-11-01 20:13 ---
With the patch in comment #6 the following code gives an ICE:
subroutine sub(x)
abstract interface
character function abs_fun()
end function
end interface
procedure(abs_fun):: x
end subroutine
end
--- Comment #4 from dominiq at lps dot ens dot fr 2008-11-03 08:21 ---
> Isn't this just a user error though?
I am just running the tests.
> Are you configuring gcc with a cell arch eventhough your assembler lacks
> that support?
I use:
../gcc-4.4-work/configure --p
--- Comment #5 from dominiq at lps dot ens dot fr 2008-11-03 11:02 ---
The patch in comment #4 generate a lot of bus errors in my tests. Looking at
it, I think there is something missing: gfc_current_ns->old_cl_list is only set
to NULL, it should likely be set to gfc_current_ns->c
--- Comment #7 from dominiq at lps dot ens dot fr 2008-11-03 17:31 ---
> Updated patch with also target-supports posted.
With the updated patch I now get only three failures for the powerpc directory
FAIL: gcc.target/powerpc/ppc64-abi-1.c (test for excess errors) <
--- Comment #7 from dominiq at lps dot ens dot fr 2008-11-03 17:33 ---
The failures disappear with the patch in comment #5.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
--- Comment #1 from dominiq at lps dot ens dot fr 2008-11-05 12:01 ---
This PR seems to have been fixed with a revision before r137480. So I close it
as fixed.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #11 from dominiq at lps dot ens dot fr 2008-11-05 13:29 ---
Could somebody check if the following changes are OK?
diff -u ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-14.c
gcc/testsuite/gcc.dg/visibility-14.c
--- ../_gcc_clean/gcc/testsuite/gcc.dg/visibility-14.c 2008-08
--- Comment #9 from dominiq at lps dot ens dot fr 2008-11-05 22:29 ---
The patch in http://gcc.gnu.org/ml/fortran/2008-11/msg00032.html works as
advertised without regression on i686-apple-darwin9 (note that it is not a
review!-).
Note also that there are other similar instances for
--- Comment #11 from dominiq at lps dot ens dot fr 2008-11-06 14:03 ---
Now that the patch in http://gcc.gnu.org/ml/fortran/2008-11/msg00022.html has
been committed I get in 32 bit mode on powerpc-apple-darwin9:
XPASS: gfortran.dg/f2003_io_1.f03 -O0 execution test
...
XPASS
: 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: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target triplet: i686
Summary: FAIL: g++.dg/other/anon5.C
Product: gcc
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
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-17 17:49 ---
>From comment #4:
+ if (ts->kind != -1)
+ts->kind = 0;
I think this has been removed in the commit. However if you had it, it is not
removed by svn update
(I had to remove it manually).
-
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-17 22:53 ---
Confirmed and this is a regression as the code works with gfortran 4.3.0
20080102.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-18 20:52 ---
On i686-apple-darwin9, I get:
pr34856.c: In function 'f1':
pr34856.c:16: error: invalid reference prefix
{(unsigned int) &g[16]}
pr34856.c:16: internal compiler error: verify_stmts failed
--
http
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-18 23:32 ---
Confirmed on i686-apple-darwin9, rev. 131629 (trunk) and gfortran 4.2.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-18 23:36 ---
Works for me on i686-apple-darwin9 (Intel Core2Duo OSX 10.5.1), rev. 131629
(trunk) and gfortran 4.2.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34860
fortran
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 triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34858
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-19 11:34 ---
Confirmed on darwin9 (ppc/intel) with adifferent error:
pr34868.f90: In function 'f':
pr34868.f90:5: internal compiler error: in gimplify_expr, at gimplify.c:6285
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-19 17:21 ---
Some debuging (this as fas as I can go on my own):
note the line
5: csym->value = (struct gfc_expr *) warning: Got an error handling event:
"Cannot access memory at
for the case that does not crash.
(
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-19 18:42 ---
Is really "SIZE(IDA2,NF3)" done on purpose? or is this a typo for
"SIZE(IDA2,3)"? It does not change the ICE AFAICT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-19 19:47 ---
Further debug:
Breakpoint 2, resolve_common_blocks (common_root=0x40d02c50) at
../../gcc-4.3-work/gcc/fortran/resolve.c:692
692 {
(gdb) c
Continuing.
Breakpoint 3, resolve_common_vars (sym=0x40d06f50
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-20 10:52 ---
Fails also at '-O2 -funroll-loops', but not if I add
return
10 print *, i, j, k, values (last)
before
end subroutine test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-20 10:35 ---
Confirmed and it is a wierd regression: the test pass with '-O3' alone, but not
with '-O3 -funroll-loops'. In addition if I replace the line
if (values (last) .ne. j + k * k) call abo
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-20 11:31 ---
The failure comes in the first call of 'test()' at i=order, j=2. The values
tested in the k loop seems to be:
5.000 10.000 3.000 6.000 11.00
4.000
--- Comment #4 from dominiq at lps dot ens dot fr 2008-01-20 12:04 ---
Worked with rev. 131669, fails with 131671. Rev. 131670 seems the most likely,
added Kenneth Zadeck to the cc list.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-20 13:19 ---
The test and its variants pass on powerpc-apple-darwin9 rev. 131676.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-20 14:56 ---
I am trying to proceed backward. I have reached the following point:
Breakpoint 8, gfc_parse_file () at ../../gcc-4.3-work/gcc/fortran/parse.c:3460
3460{
(gdb) s
gfc_parse_file () at ../../gcc-4.3-work/gcc
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-20 14:39 ---
> I need a more info to reproduce this bug.
I have tried to give all the info I have been able to gather on my own. My
config is:
Configured with: ../gcc-4.3-work/configure --prefix=/opt/gcc/gcc4.3w
--mandir=/
--- Comment #35 from dominiq at lps dot ens dot fr 2008-01-20 15:16 ---
Note that the test gcc.dg/struct/wo_prof_mult_field_peeling.c pass for 32 and
64 bit modes on i686-apple-darwin9, so I am not sure that what follows will
help.
For the code in comment #34 the assembly code is
--- Comment #11 from dominiq at lps dot ens dot fr 2008-01-20 15:47 ---
I have put the results of the compilation with -da with the patch at
http://www.lps.ens.fr/~dominiq/gcc/tmp_fresh.tar.bz2
All the files will be in a directory tmp_fresh. Do you still need the same
without the
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-20 15:30 ---
> you are building on a mac "darwin" box
Yes indeed, but the bug is also present for i686-pc-linux-gnu, see for
instance:
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00914.html
--
http:
--- Comment #37 from dominiq at lps dot ens dot fr 2008-01-20 18:09 ---
(In reply to comment #36)
> ... And, if I understand correctly the comment #32, with 64 bits mode it does
> fails with wo_prof_mult_fields_peeling.c. Please fix me if I am wrong.
Yes, you are right. I did no
--- Comment #38 from dominiq at lps dot ens dot fr 2008-01-20 20:47 ---
With patch form comments #11 and #31, the executable for
gcc.dg/struct/wo_prof_mult_field_peeling.c segfault with -m64. I have used the
32 bit mode for -fprofile-generate, run the executable, and use -m64 for
--- Comment #40 from dominiq at lps dot ens dot fr 2008-01-21 14:09 ---
> Why are you running wo_prof_mult_field_peeling.c with profiling?
My best guess is because I have reused some previous command line(s) with it
(from gcc.dg/struct/w_prof_global_array.c for instance) with
--- Comment #24 from dominiq at lps dot ens dot fr 2008-01-21 14:39 ---
Side note for the record: the polyhedron test mdbx.f90 also fails in 32 bit
mode with rev. 131689 on i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--- Comment #41 from dominiq at lps dot ens dot fr 2008-01-21 14:54 ---
Sorry I missed the second question:
> The other question is whether the failing tests that should run *with*
> profiling, like w_prof_gloval_var.c and w_prof_local_var.c, fail after
> compilation with
--- Comment #43 from dominiq at lps dot ens dot fr 2008-01-21 19:09 ---
>> They failed with -fprofile-generate (BTW they fail without -fprofile-*).
without! sorry
> If I understand you correctly, the executable of w_prof_global_var.c, compiled
&
--- Comment #45 from dominiq at lps dot ens dot fr 2008-01-21 20:26 ---
> Sorry pursuing this issue, but let me completely understand it: when you run
> *with* profiling, there are two compilations and two executions. If you
> compile
> first with:
>
> -O3 -fipa-t
--- Comment #47 from dominiq at lps dot ens dot fr 2008-01-21 20:55 ---
> If you run the executable generated by:
> -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate
> w_prof_global_var.c -m64
>
> is it fail or not?
It does not fail:
[ibook-dhum] bug/d
--- Comment #50 from dominiq at lps dot ens dot fr 2008-01-22 22:47 ---
> I wonder what it will be if we use -fno-unroll-loops in compilation
It does change the segfault:
[ibook-dhum] f90/bug% /opt/gcc/gcc4.3w/bin/gcc -O3 -fno-unroll-loops
-fipa-struct-reorg -fipa-type-escape -fwh
--- Comment #52 from dominiq at lps dot ens dot fr 2008-01-22 23:25 ---
> You mean does not, right?
Yes indeed! sorry for skipping the negation. The assembly follows. Comparing it
to the assembly for wo_prof_mult_field_peeling_db.c in comment #35, the
striking difference is that
--- Comment #8 from dominiq at lps dot ens dot fr 2008-01-22 23:50 ---
On i686-apple-darwin9, testsuite/gcc.c-torture/compile/pr34856.c gives an ICE
at -O3 with trunk rev.131745:
[ibook-dhum] f90/bug% /opt/gcc/w1-gcc4.3w/bin/gcc -O3
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture
middle-end
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=34930
Severity: normal
Priority: P3
Component: middle-end
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=34929
--- Comment #11 from dominiq at lps dot ens dot fr 2008-01-23 09:28 ---
> The tree-cfg.c hunk was supposed to fix this.
Additional info: on i686-apple-darwin9 the failures disappear with -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-24 10:17 ---
> IMO, take the notes from g77 and be done with it.
I fully agree. ENCODE/DECODE have standard conforming equivalents and are not
difficult to replace by the latter.
I'll go a step further by replacing
--- Comment #53 from dominiq at lps dot ens dot fr 2008-01-24 12:58 ---
On i686-apple-darwin9 the patch from
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01081.html (now commited in
trunk) solves all the failures in gcc.dg/struct/*, both in 32 and 64 bit modes.
I have even an XPASS
--- Comment #28 from dominiq at lps dot ens dot fr 2008-01-24 14:01 ---
Some remarks from powerpc-apple-darwin9:
(1) the title is misleading: formatted inputs are not broken, formatted outputs
are.
(2) they seem broken for constants nearest from bellow any power of two, as
shown by
--- Comment #21 from dominiq at lps dot ens dot fr 2008-01-24 14:57 ---
Prliminary tests show that the patch in #20 fix the problem on
i686-apple-darwin9, regtesting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856
--- Comment #8 from dominiq at lps dot ens dot fr 2008-01-24 15:41 ---
> When did this last work?
The reduced test case is compiled by 4.2.2, but not by 4.3.0 20071125
(experimental).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34946
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-24 15:55 ---
Confirmed on i686-apple-darwin9 on both 32 and 64 bit modes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
--- Comment #10 from dominiq at lps dot ens dot fr 2008-01-24 16:00 ---
> What is the date on the 4.2.2?
>From gcc.gnu.org:pub/gcc/releases, I'ld guess 2007 Oct 8:
drwxrwsr-x 3 ftp ftp 4096 Oct 8 22:07 gcc-4.2.2
--
http://gcc.gnu.org/bugzilla/show
--- Comment #22 from dominiq at lps dot ens dot fr 2008-01-24 16:33 ---
I get the following summary for the gcc regression testsuite (32/64 bit modes)
with the patch in #20:
=== gcc Summary for unix/-m64 ===
# of expected passes47421
# of unexpected
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-24 16:46 ---
Subject: Re: [4.3 Regression] ICE on invalid depending of
the length of the source name
Preliminary tests show that my test cases are fixed by the
patch. I'll launch regtesting.
Thanks for the patch.
--
--- Comment #10 from dominiq at lps dot ens dot fr 2008-01-24 19:57 ---
The patch regtested fine on intel darwin9. I'll port it ot ppc, but I'll got
the results only tomorrow morning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34858
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-24 23:00 ---
This test case appeared in revision 122315 and failed on powerpc-apple-darwin
from revision 122323 (see
http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg01022.html) up to now.
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-26 00:05 ---
> This should have been fixed by 30572.
I was thinking to this one. This is why I asked to check there was some files
/libgcc_s*, just in case the package installed it.
I don't understand the problem: I
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-25 17:43 ---
What architecture are you using? and what gives
ls -l /usr/local/gfortran/lib/libgcc_s*
ls -l /libgcc_s*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34957
--- Comment #4 from dominiq at lps dot ens dot fr 2008-01-25 13:38 ---
Worked on rev. 131628.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34930
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-25 15:47 ---
Where did you get "the prepackaged gfortran binaries"?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34957
--- Comment #27 from dominiq at lps dot ens dot fr 2008-01-25 15:39 ---
See also pr24685.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
--- Comment #29 from dominiq at lps dot ens dot fr 2008-01-25 15:40 ---
see also pr32841.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-25 22:40 ---
I have also
[ibook-dhum] f90/bug% ll /opt/gcc/gcc4.3w/lib/libgcc_s*
-rw-r--r-- 1 dominiq staff 204080 Jan 25 17:26
/opt/gcc/gcc4.3w/lib/libgcc_s.1.dylib
-rw-r--r-- 1 dominiq staff 17380 Jan 25 17:26
/opt/gcc
--- Comment #19 from dominiq at lps dot ens dot fr 2008-01-26 14:41 ---
I confirm that the ICEs are gone, however the original test case and the one in
comment #3 ouput garbage: '[EMAIL PROTECTED]@^@@[EMAIL PROTECTED]@[EMAIL
PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@
--- Comment #12 from dominiq at lps dot ens dot fr 2008-01-27 10:32 ---
It seems that this patch breaks the original test case of pr33998:
pr33998.f90: In function 'my_string':
pr33998.f90:7: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:842
b
--- Comment #13 from dominiq at lps dot ens dot fr 2008-01-27 10:41 ---
Following comment #12, I also see an ICE for pr34897:
pr34897.f90: In function 'my_string':
pr34897.f90:1: warning: Function does not return a value
pr34897.f90:4: internal compiler error: in gfc_typenod
--- Comment #14 from dominiq at lps dot ens dot fr 2008-01-27 11:26 ---
Note that I am not sure to blame the right patch. What I can tell for sure is
that pr33998.f90 started to fail between the 19th (working, rev. 131656) and
the 20th (ICE, rev. 131679), and pr34897.f90 between the
--- Comment #15 from dominiq at lps dot ens dot fr 2008-01-27 12:02 ---
> Note that I am not sure to blame the right patch.
I was correct, pr33998.f90 started to fail after rev. 131676 and pr34897.f90
after rev. 131679.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34848
.c:842
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 build triplet: powerpc/i686-ap
--- Comment #14 from dominiq at lps dot ens dot fr 2008-01-28 09:20 ---
At rev. 131891, the test gives the same ICE on ppc/Intel Darwin9, 32 and 64
modes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-28 09:09 ---
> Without the patch gfortran gives correct results on x86-64 and segfaults on
> compilation on ppc64.
Without the patch, gfortran compiles gfortran.dg/parameter_array_init_3.f90
and gives the correct resul
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-28 12:25 ---
My tests have not been as exhaustive as the Tobias' ones, but the patch worked
as advertised without regression on ppc/intel Darwin9, 32 and 64 bit modes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34975
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-28 14:33 ---
The polyhedron test "aermod.f90" fails with:
aermod.f90: In function 'wake_dfsn2':
aermod.f90:37741: error: unrecognizable insn:
(insn 574 3142 575 38 (parallel [
(set (reg:V4SF 1
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-28 17:21 ---
I always wonder if a hard error is really necessary for such cases? would not a
warning be sufficient? I think there is a flag to change warnings to errors if
necessary (-Werror?).
--
http://gcc.gnu.org/bugzilla
pple-darwin9/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.2w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.2w/i686-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.2w/i686-apple-darwin9/include -isystem
/opt/gcc/gcc4.2w/i686-apple-darwin9/sys-include" "LD=ld" "LIBCFLAGS=" "NM="
"
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-30 08:08 ---
> Did this happen with the 4.2.2 release?
I just checked on darwin9 and the answer is yes. Nevertheless could someone
have a look to the problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35012
601 - 700 of 2230 matches
Mail list logo
