--- Comment #18 from jv244 at cam dot ac dot uk 2009-06-20 17:37 ---
*** Bug 38814 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #2 from jv244 at cam dot ac dot uk 2009-06-20 17:37 ---
looks like the issue in comment #1 is really just a duplicate of PR40005
*** This bug has been marked as a duplicate of 40005 ***
--
jv244 at cam dot ac dot uk changed:
What|Removed
--- Comment #1 from jv244 at cam dot ac dot uk 2009-06-20 17:47 ---
that would be nice indeed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39624
--- Comment #9 from jv244 at cam dot ac dot uk 2009-06-20 17:56 ---
Since the corresponding binutils bug is fixed, should this PR be closed ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
--- Comment #27 from jv244 at cam dot ac dot uk 2009-06-11 07:04 ---
(In reply to comment #26)
I am going to suggest we revert
format caching from 4.4 right away
Yes, please, that gives me roughly a week to do some more testing before 4.4.1
is released.
--
http://gcc.gnu.org
--- Comment #30 from jv244 at cam dot ac dot uk 2009-06-12 05:47 ---
(In reply to comment #29)
Fixed on 4.4.1, 4.5 in review process.
great, many thanks. CP2K now passes it 1600 tests with 4.4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
--- Comment #3 from jv244 at cam dot ac dot uk 2009-06-12 05:48 ---
I would like to ping this PR... progress here seems valuable, and typical stage
1 stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
--- Comment #19 from jv244 at cam dot ac dot uk 2009-06-10 07:22 ---
(In reply to comment #18)
I was able to do a regression hunt. Going to r145209 just before the big
I/O
patch eliminates the error. I then moved forward to r145636 and confirmed
the
breakage.
Is 4.5
--- Comment #20 from jv244 at cam dot ac dot uk 2009-06-10 07:24 ---
(In reply to comment #16)
Joost, can you explain what the following means?
CP2K| condition FAILED at line 195
CP2K| Abnormal program termination, stopped by process number 0
Aborted
In this case it means
--- Comment #21 from jv244 at cam dot ac dot uk 2009-06-10 09:25 ---
reduced testcase:
MODULE M1
IMPLICIT NONE
CONTAINS
SUBROUTINE S1(I)
INTEGER :: I,K
CHARACTER(LEN=100) :: a,b
write(a,'(I0,A)') I,X
write(b,*) I
write(6,FMT='('//TRIM(a)//,a,' '), ADVANCE=NO) TRIM(b
--- Comment #23 from jv244 at cam dot ac dot uk 2009-06-10 13:18 ---
(In reply to comment #22)
Thanks for reduced test.
$ ./a.out badfile
$ xxd badfile
000: 2020 2020 2020 2020 2020 2020 2020 33203
010: 2020 2020 2020 2020 2020 2020 2020 3300
--- Comment #1 from jv244 at cam dot ac dot uk 2009-06-10 14:10 ---
this is not valid code, but a gfortran bug nevertheless.
line 5: X is not permitted in an initialisation expression
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40383
--- Comment #1 from jv244 at cam dot ac dot uk 2009-06-09 07:44 ---
I'm guessing due to :
2009-04-11 Daniel Kraft d...@domob.eu
PR fortran/37746
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #3 from jv244 at cam dot ac dot uk 2009-06-09 08:34 ---
Jakub,
the error message I get below is new with gcc 4.5, and is still present as of
revision 148276 (20090608). Is there any info I can provide (e.g. attach the
object file?) that could help in getting this resolved
--- Comment #5 from jv244 at cam dot ac dot uk 2009-06-09 08:54 ---
(In reply to comment #4)
Start with trying newer binutils.
same error with :
/data03/vondele/binutils-2.19.1/build/bin/ld: error in
/data03/vondele/clean/cp2k/src/../lib/Linux-x86-64-gfortran/sdbg/libcp2k_lib.a
--- Comment #7 from jv244 at cam dot ac dot uk 2009-06-09 10:26 ---
(In reply to comment #6)
Couldn't reproduce (just built cp2k on x86_64-linux with trunk gfortran and
.eh_frame_hdr has been created just fine). I'm using binutils 2.19.51.0.2.
Anyway, you should probably just tar
--- Comment #8 from jv244 at cam dot ac dot uk 2009-06-09 10:52 ---
(In reply to comment #6)
Anyway, you should probably just tar up the .a library and other things you
are
linking together and with that report it in binutils bugzilla.
filed this PR for binutiles,
http
--- Comment #15 from jv244 at cam dot ac dot uk 2009-06-09 22:14 ---
(In reply to comment #14)
Closing as fixed.
I'm testing now 4.4 which includes your fix, but I still see CP2K's restarts
failing. This looks like a second issue, different from what you've fixed so
far. The testcase
--- Comment #16 from jv244 at cam dot ac dot uk 2009-06-06 07:08 ---
(In reply to comment #13)
Subject: Bug 40168
Richard, this empty constructor patch was also OKed for 4.4 and has been on
mainline for a while.
http://gcc.gnu.org/ml/fortran/2009-05/msg00288.html
Do you intend
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
--- Comment #1 from jv244 at cam dot ac dot uk 2009-06-03 15:46 ---
CCed the experts
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
CC
--- Comment #3 from jv244 at cam dot ac dot uk 2009-06-03 16:08 ---
(In reply to comment #2)
Did you try 4.5?
unfortunately trunk currently fails for other reasons. I'll try to look into
that afterwards.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
--- Comment #4 from jv244 at cam dot ac dot uk 2009-06-03 16:31 ---
OK, a good hint from valgrind. The following error is present if I use 4.4.1
but not if I link against the runtime from 4.4.0:
==30712== Invalid read of size 1
==30712==at 0x4A22DF9: strncmp (mc_replace_strmem.c:314
--- Comment #5 from jv244 at cam dot ac dot uk 2009-06-03 16:47 ---
OK, now with easy testcase, as you'll notice from the output, the loop is
important:
IMPLICIT NONE
character(len=100) :: fmt1,str1,fmt2,str2
real*8 :: r(3)=0
integer :: i,iunit
fmt1=(T2,A2,
str1=a
iunit=6
DO i=1,10
--- Comment #6 from jv244 at cam dot ac dot uk 2009-06-03 16:49 ---
compiled with trunk this is also buggy (with new bugs about dwarf2):
--690-- DWARF2 CFI reader: unhandled CFI instruction 0:10
--690-- DWARF2 CFI reader: unhandled CFI instruction 0:10
--690-- DWARF2 CFI reader
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
--- Comment #2 from jv244 at cam dot ac dot uk 2009-06-03 17:14 ---
(In reply to comment #1)
What binutils version are you using? do ld --version. This might be a bug in
binutils really.
it is recent, I think:
ld -v
GNU ld (GNU Binutils; openSUSE 11.0) 2.18.50.20080409-11.1
--- Comment #11 from jv244 at cam dot ac dot uk 2009-06-04 05:16 ---
(In reply to comment #9)
Proper patch submitted.
Thanks, don't wait too long with 4.4 as this should make it in 4.4.1 which
could be released this month, and some further testing on the branch would be
good:
http
--- Comment #29 from jv244 at cam dot ac dot uk 2009-06-01 19:34 ---
(In reply to comment #28)
Created an attachment (id=17942)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17942action=view) [edit]
A progression of -fwhole-file
This patch is as far as I have got.
this seems
--- Comment #30 from jv244 at cam dot ac dot uk 2009-06-01 19:43 ---
Created an attachment (id=17944)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17944action=view)
testcase
attached is a testcase, this actually causes a segfault outside of the build
infrastructure, but consumes
--- Comment #25 from jv244 at cam dot ac dot uk 2009-05-29 16:34 ---
(In reply to comment #24)
However, there are some
problems involving ICEs dues to different backend_decls being used for derived
types that are identical
I'm not sure this is related, but note comment #8. Even
--- Comment #12 from jv244 at cam dot ac dot uk 2009-05-28 07:05 ---
(In reply to comment #5)
Subject: Re: ICE with -fipa-pta
As the person working on ipa-pta, I'm happy for you to file bug
reports against ipa-pta, but I should warn you that a lot of these
bugs are just going
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40275
--- Comment #23 from jv244 at cam dot ac dot uk 2009-05-27 17:51 ---
I've added a 'related' PR40275 on -combine not working for Fortran. I think
that as soon as the -fwhole-file patch is added (default or not yet ;-) there
would be interest in -combine doing the right thing
--- Comment #2 from jv244 at cam dot ac dot uk 2009-05-27 17:54 ---
(In reply to comment #1)
Really -combine is going away and LTO is replacing it. It might be better to
help out implementing LTO rather than wasting time on working on getting
-combine working.
unfortunately, I
: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40280
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40281
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-28 04:57 ---
Created an attachment (id=17923)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17923action=view)
testcase
compile as
gfortran -v -c -O2 -funroll-loops -fprefetch-loop-arrays PR40281.f90
--
http
: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-28 05:16 ---
Created an attachment (id=17924)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17924action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40282
--- Comment #20 from jv244 at cam dot ac dot uk 2009-05-25 06:13 ---
(In reply to comment #19)
It's good news that cp2k is now OK - did the performance improve?
I didn't check that, I suspect that, since everything is module based, it needs
the stuff for module procedure inlining first
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-25 07:48 ---
this is likely being fixed by Ira
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #3 from jv244 at cam dot ac dot uk 2009-05-25 10:04 ---
fixed on current trunk.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.5.0
Version|4.4.0 |4.5.0
http
--- Comment #4 from jv244 at cam dot ac dot uk 2009-05-21 08:34 ---
Paul, 2 years ago you had a (one liner?) patch for this one, but gfortran still
seem to unpack for intent(IN) data:
MODULE M1
CONTAINS
SUBROUTINE S1(I)
INTEGER, DIMENSION(3), INTENT(IN) :: I
END SUBROUTINE
END
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40218
--- Comment #5 from jv244 at cam dot ac dot uk 2009-05-21 08:40 ---
(In reply to comment #4)
Paul, 2 years ago you had a (one liner?) patch for this one, but gfortran
still
seem to unpack for intent(IN) data:
ugh... no. I tested with 4.3 instead of 4.5. Instead we can close
--- Comment #6 from jv244 at cam dot ac dot uk 2009-05-21 08:45 ---
fixed
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|NEW
: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-19 10:01 ---
OK, updated testcase, while the argument still holds for the previous code,
this was the intended code, and the generated code is even worse:
INTEGER FUNCTION F1()
INTEGER :: I1
INTEGER, TARGET :: I2
INTEGER
--- Comment #2 from jv244 at cam dot ac dot uk 2009-05-19 10:14 ---
the context of the report is
http://gcc.gnu.org/ml/gcc/2009-05/msg00465.html
in particular, fortran variables are often not 'addressable' in the sense that
seems to be important of the gcc optimizers
--
http
--- Comment #5 from jv244 at cam dot ac dot uk 2009-05-19 11:54 ---
(In reply to comment #3)
Does
SUBROUTINE S(I1,IP)
INTEGER,INTENT(IN) :: I1
INTEGER, POINTER :: IP
END SUBROUTINE S
allow that S stores the pointer to I1 to global memory
--- Comment #14 from jv244 at cam dot ac dot uk 2009-05-18 12:19 ---
Created an attachment (id=17886)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17886action=view)
simplified testcase for common subexpressions.
Richard,
thanks very much for the first patch. I tried to get
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-16 09:36 ---
Created an attachment (id=17883)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17883action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
--- Comment #4 from jv244 at cam dot ac dot uk 2009-05-16 11:19 ---
(In reply to comment #3)
Like so:
Index: trans-expr.c
===
--- trans-expr.c(revision 147583)
+++ trans-expr.c(working copy
--- Comment #6 from jv244 at cam dot ac dot uk 2009-05-16 11:31 ---
(In reply to comment #5)
This looks somewhat different from what I get here.
trunk without patch:
vond...@pcihopt3:/data03/vondele/contract gfortran -O3 -march=native
-ffast-math -funroll-loops -ffree-line-length-200
--- Comment #8 from jv244 at cam dot ac dot uk 2009-05-16 12:20 ---
(In reply to comment #7)
Subject: Re: missing
unrolling/scalarization/reassoc/free
so, double good news.
First, the unrelated other testcase that speeds up by 30% does this thanks to
this patch only
--- Comment #9 from jv244 at cam dot ac dot uk 2009-05-16 12:39 ---
BTW, the patch also applies to 4.4_branch and has the same positive effect...
pretty please ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
--- Comment #18 from jv244 at cam dot ac dot uk 2009-05-17 05:11 ---
the patch posted here:
http://gcc.gnu.org/ml/fortran/2009-05/msg00244.html
allows cp2k in its single source file form, 640klines as made available in
PR40005, to compile with -fwhole-file (using the ulimit -s unlimited
--- Comment #16 from jv244 at cam dot ac dot uk 2009-05-09 14:57 ---
tried once running under valgrind, but that doesn't give more info, no errors
till the point of the stack overflow:
GNU Fortran (GCC) version 4.5.0 20090509 (experimental) [trunk revision 147317]
(x86_64-unknown-linux
--- Comment #15 from jv244 at cam dot ac dot uk 2009-05-07 14:32 ---
(In reply to comment #13)
Is there a self contained (one file) source that I could use?
have you had a chance to look into the issue / is there anything I can help
with ? I'd like to get this ready for -fwhole-file
--- Comment #14 from jv244 at cam dot ac dot uk 2009-05-05 19:28 ---
(In reply to comment #13)
I have been thinking hard about type cheating - I am likely to allow it for
std-f77 and legacy, to warn with other standards and fail with -pedantic.
this sounds reasonable. Note the other
--- Comment #14 from jv244 at cam dot ac dot uk 2009-05-06 04:36 ---
(In reply to comment #13)
Is there a self contained (one file) source that I could use? Gfortran is
known
to emit a lot of blocks inside blocks and I wonder if this is the cause. And
the GC is only setup to do
--- Comment #10 from jv244 at cam dot ac dot uk 2009-05-04 07:12 ---
This is the outermost stack trace to the segfault (with default 8M stack),
shows the depth of the recursion, and the location:
#174699 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized
out) at ./gt
--- Comment #11 from jv244 at cam dot ac dot uk 2009-05-04 07:49 ---
I have a gdb session open, but I'm rather clueless. I have this:
(gdb) print (*x).generic.type
$5 = {common = {base = {code = RECORD_TYPE, side_effects_flag = 0,
constant_flag = 0, addressable_flag = 0, volatile_flag
--- Comment #8 from jv244 at cam dot ac dot uk 2009-05-05 04:18 ---
(In reply to comment #6)
opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13:
call func1(x)
1
Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to
TYPE(my_type
--- Comment #9 from jv244 at cam dot ac dot uk 2009-05-04 04:39 ---
(In reply to comment #8)
Thus, the question is what are we recursing on here? type.next_variant
if my sources are matching yours (look at gt-fortran-f95-lang.h:337).
gt_ggc_m_9tree_node ((*x
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-02 12:22 ---
not specific to 4.5, also fails with
gcc version 4.4.0 20090414 (prerelease) [gcc-4_4-branch revision 146034] (GCC)
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2009-05-02 12:43 ---
also 4.3.3. fails
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known to fail|4.4.0
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40006
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40006
--- Comment #3 from jv244 at cam dot ac dot uk 2009-05-02 13:16 ---
(In reply to comment #2)
Note that also one of the SPEC 2006 benchmark fail with -fwhole-file because
of
type cheating.
I would say that I know virtually no large F77 based project that would compile
as a single
--- Comment #3 from jv244 at cam dot ac dot uk 2009-05-02 13:44 ---
with gfortran -c -O0 --param ggc-min-heapsize=320 CP2K_2009-05-01.f90
things compile file (and need some 6Gb of memory).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #4 from jv244 at cam dot ac dot uk 2009-05-02 13:56 ---
a further case to hide behind an eventual switch
SUBROUTINE S3(a)
REAL :: a(*)
END SUBROUTINE
SUBROUTINE T3(a)
REAL, DIMENSION(:) :: a
CALL S3(a(1))
END SUBROUTINE T3
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from jv244 at cam dot ac dot uk 2009-05-02 14:26 ---
(In reply to comment #5)
If I have read correctly the ifort man, ifort does not bounds check this kind
of constructs (A(*) or A(1) in procs).
the problem is not bounds, but this:
Error: Element of assumed-shaped
--- Comment #3 from jv244 at cam dot ac dot uk 2009-04-30 18:48 ---
a bug in the code that is triggered by the option. closing as invalid.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39964
--- Comment #1 from jv244 at cam dot ac dot uk 2009-04-29 15:27 ---
Created an attachment (id=17781)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17781action=view)
source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39964
--- Comment #2 from jv244 at cam dot ac dot uk 2009-04-29 15:27 ---
GNU Fortran (GCC) version 4.4.0 20090414 (prerelease) [gcc-4_4-branch revision
146034]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39964
--- Comment #9 from jv244 at cam dot ac dot uk 2009-04-23 14:21 ---
(In reply to comment #8)
Having a shot at backporting, assigning to myself.
BTW, I only care about a backport to 4.4, which should be relatively easy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
--- Comment #6 from jv244 at cam dot ac dot uk 2009-04-18 17:11 ---
since this is a regression, what about back porting this fix to other branches
(in particular 4.4). This is the only issue that triggers running the 1600
testcases in CP2K testsuite.
--
jv244 at cam dot ac dot uk
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
--- Comment #1 from jv244 at cam dot ac dot uk 2009-04-16 07:31 ---
no valgrind errors with g95 or NAG.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
--- Comment #2 from jv244 at cam dot ac dot uk 2009-04-16 12:56 ---
seemingly works fine with 4.2.3
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Summary|[4.5/4.4/4.3 Regression] IO |[4.3/4.4/4.5 Regression] IO
|depends on uninitialised
--- Comment #2 from jv244 at cam dot ac dot uk 2009-04-15 13:21 ---
not a duplicate of PR28105. The allocate is fine (on an x86_64).
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #4 from jv244 at cam dot ac dot uk 2009-04-15 17:03 ---
But, it does not do
what you expected! Try using your allocated array in something
other than SIZE().
It's doing exactly what I expect... including the size intrinsic returning a
garbage result because it returns
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39771
--- Comment #7 from jv244 at cam dot ac dot uk 2009-04-14 20:08 ---
I'm reopening this report. -ftrapv is still documented, so can be expected to
work by users.
For the particular problem I have right now, a functional version of this
option would be a great thing to have
: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
--- Comment #3 from jv244 at cam dot ac dot uk 2009-03-23 19:26 ---
good old Fortran.. (fine with NAG as well)
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
: poor error message
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org
--- Comment #5 from jv244 at cam dot ac dot uk 2009-02-13 14:01 ---
(In reply to comment #4)
It is glibc specific, on the other hand it isn't particularly -fopenmp
related.
I guess easiest will be if glibc stops shipping libpthread.a.
but if -fopenmp automatically adds -lpthread
301 - 400 of 1178 matches
Mail list logo
