Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: manfred99 at gmx dot ch
Target Milestone: ---
Allocating an allocatable character array, I get a malloc error
when the source argument is not properly padded:
CHARACTER*30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #25 from Manfred Schwarb ---
Same issue for MAX1 and MIN1:
88 | ff=MAX1(a, a)
| 1
Warning: Change of value in conversion from 'REAL(4)' to 'INTEGER(4)' at (1)
[-Wconversion]
Surprisingly, I could not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #24 from Manfred Schwarb ---
Sandra,
I will look into this. Probably streamlining the patch to only use *4 and *8
is appropriate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100654
--- Comment #2 from Manfred Schwarb ---
OK, then I will not report such issues in the future and
use --disable-werror per default when using non-standard flags.
Thanks.
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: manfred99 at gmx dot ch
Target Milestone: ---
linux x86_64 and i686 (GCC 7.5 as bootstrap compiler), with BOOT_CFLAGS="-O0
-g":
../../gcc-trunk-source/gcc/gcc/opts.c: In function 'void
print_filtered_help(un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
--- Comment #5 from Manfred Schwarb ---
This might have been solved by
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=ac932bfcd21e9523fa2b880ae8138aef79da7f54
, at least I don't
see it anymore in today's build. As the crash of class_61.f90 is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95687
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
--- Comment #10 from Manfred Schwarb ---
I just tried to build a compiler with "-fno-omit-frame-pointer" to
get potentially better backtraces, but then the ICE vanishes ...
Is there a way to get useful backtraces? "--enable-checking=yes,extra"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
--- Comment #9 from Manfred Schwarb ---
I sprinkled some printf's into get_unique_type_string():
XXderived->name: strlen=63;
t2345678901234567890123456789012345678901234567890123456789_123
XXdt_name: strlen=63;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
--- Comment #8 from Manfred Schwarb ---
I even tried "char tmp[2*GFC_MAX_SYMBOL_LEN+800];" but it
still fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
--- Comment #5 from Manfred Schwarb ---
gdb shows:
Program received signal SIGSEGV, Segmentation fault.
0xf7aa5162 in __strlen_sse2_bsf () from /lib/libc.so.6
#0 0xf7aa5162 in __strlen_sse2_bsf () from /lib/libc.so.6
#1 0x083e6def in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95008
--- Comment #2 from Manfred Schwarb ---
gcc.dg/analyzer/pr93382.c: Sorry, I can't reproduce, this test passes for me.
gcc.dg/two-types-6.c: My bad, I forgot to mention this failure, as this
test did not make sense to me. I could not determine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
--- Comment #9 from Manfred Schwarb ---
Patch seems to work so far. Do you need any logfiles?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
--- Comment #8 from Manfred Schwarb ---
Created attachment 48384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48384=edit
libiberty/config.log
The full logfile of libiberty. I will apply the patch now and will report back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
NCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: manfred99 at gmx dot ch
Target Milestone: ---
Current trunk (as of today 2020-01-15) does not bootstrap for me on x86_64,
with errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #19 from Manfred Schwarb ---
Created attachment 46963
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46963=edit
extended patch from comment #4 to also cover gfc_simplify_dble and
gfc_simplify_sngl
Note, I do not have neither
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #17 from Manfred Schwarb ---
Here is the documentation fallout I mentioned, previous attachment.
And probably a lot of
@multitable @columnfractions .20 .20 .20 .25
entries should be widened for the last column, as "Fortran 77 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #16 from Manfred Schwarb ---
Created attachment 46873
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46873=edit
documentation changes for conversion intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #14 from Manfred Schwarb ---
>FWIW, I briefly looked at conversions of complex variables
>and did not find any similar -Wconversion warnings for a patched compiler.
Well, I only looked at REAL,REALPART,AIMAG,IMAG,IMAGPART,DIMAG.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #13 from Manfred Schwarb ---
FWIW, I briefly looked at conversions of complex variables
and did not find any similar -Wconversion warnings for a patched compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #11 from Manfred Schwarb ---
>> !---LONG not allowed anymore in gfortran 10 (?):
>> !!ff=LONG(a)
>> !!ff=LONG(b)
>> !!ff=LONG(c)
>> !!ff=LONG(d)
>> !!ff=LONG(g)
>
>LONG was removed by by BOZ patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #9 from Manfred Schwarb ---
Hi Steve,
I tried your patch in comment 4, it is a good starting point.
However, SNGL and DBLE still throw warnings:
real*4 a,aa
real*8 b,bb
real*10 c,cc
real*16 d
integer*2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
--- Comment #7 from Manfred Schwarb ---
Hopefully this rings some bells: The warnings happen
only for parameters:
real b
double precision a,c,d
PARAMETER(a=3.1415927d0)
DATA c /3.1415927d0/
d=3.1415927d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
Manfred Schwarb changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
---
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: manfred99 at gmx dot ch
Target Milestone: ---
real b
double precision a
PARAMETER(a=3.1415927d0)
b=REAL(a)
b=REAL(a, kind=4)
end
gives
a.f:5:13:
5 | b=REAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536
--- Comment #7 from Manfred Schwarb ---
Thanks Jakub for the debug hint, and thanks Dominique for finding the
duplicate.
Indeed, my backtrace also points to simplify_ref_chain:
# gdb --quiet `/usr/local/gcc-trunk-32bit/bin/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536
--- Comment #3 from Manfred Schwarb ---
BTW, the build logs (*README.txt) are here:
http://gfortran.meteodat.ch/download/i686/nightlies/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536
--- Comment #2 from Manfred Schwarb ---
./gfortran -v output:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-trunk-32bit/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk-32bit/bin/../libexec/gcc/i686-linux/9.0.0/lto-wrapper
Target:
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: manfred99 at gmx dot ch
Target Milestone: ---
Since several weeks I get testsuite errors for the i686 target (x86_64 is OK)
which relate to the %re, %im, %len and %kind features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40196
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #29 from Manfred Schwarb ---
Here are the results from my test case from PR82938
(without the "print*,f" statement, which consumes ~1s):
1.1s for GNU Fortran (GCC) 8.0.0 20170828 (experimental) [trunk revision
251373]
3.3s for
Assignee: unassigned at gcc dot gnu.org
Reporter: manfred99 at gmx dot ch
Target Milestone: ---
#!/bin/sh
seq --format="%.1f" 1 100 > read.txt
cat > read.f </dev/null
On my box, this short program takes
2.4s for GNU Fortran (GCC) 8.0.0 20170828 (experiment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029
--- Comment #6 from Manfred Schwarb ---
Will do tomorrow.
Thanks for your patch, I hadn't seen your comments here when
I wrote my comment to bug 35339 ...
We had seemingly the same association when reading nicolas' patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35339
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: manfred99 at gmx dot ch
Target Milestone: ---
program directaccess_formatted
integer nextrec
open(10, file='directaccess_formatted.dat', form='formatted',
access='direct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66255
Manfred Schwarb manfred99 at gmx dot ch changed:
What|Removed |Added
CC||manfred99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65971
--- Comment #2 from Manfred Schwarb manfred99 at gmx dot ch ---
Hmm, that's a pretty new binutils version.
So it is not possible any more to build GCC on somewhat older
installations?
This seems not to be documented at https://gcc.gnu.org
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: manfred99 at gmx dot ch
Target Milestone: ---
Since 2015-04-17
(probably since https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=222178),
my bootstrap of trunk fails with
gold
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: manfred99 at gmx dot ch
configure: line 21572: test: =: unary operator expected
This is:
if test -x $DEFAULT_LINKER; then
gcc_cv_ld=$DEFAULT_LINKER
== elif test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168
--- Comment #1 from Manfred Schwarb manfred99 at gmx dot ch ---
The script in question is gcc/configure, not toplevel configure.
The script error location corrsponds to line 2120 in gcc/configure.ac.
The code in question was introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168
--- Comment #4 from Manfred Schwarb manfred99 at gmx dot ch ---
This does not catch all cases. There is also
yes)
if test x${default_ld} != x; then
install_gold_as_default=yes
fi
;;
which needs an else case, as far as I can see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168
--- Comment #6 from Manfred Schwarb manfred99 at gmx dot ch ---
I did the following (error present also with your recent patch):
# ../gfortran-source/gcc-5-20140817/configure --enable-languages=c,c++,fortran
--disable-nls --enable-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168
--- Comment #8 from Manfred Schwarb manfred99 at gmx dot ch ---
Works for me, the error message is gone.
I inserted a pair of set -x/set +x around the gold configure block,
and the following is the output, everything looks OK:
original:
+ test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #10 from Manfred Schwarb manfred99 at gmx dot ch ---
Dominique, you are right.
The issue is not with isl-0.12 and isl-0.13.
It is isl-0.11 that is missing these include files. So with the
above mentioned check-in, building GCC using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
--- Comment #25 from Manfred Schwarb manfred99 at gmx dot ch ---
OK, thanks Jerry and Dominique for the explanations.
It seems the correct syntax then is:
READ(lun,END=100) buffer
GOTO 101
100 BACKSPACE(lun)
101 WRITE(lun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
--- Comment #26 from Manfred Schwarb manfred99 at gmx dot ch ---
I just tested g77.
As suspected, g77 is in line with gfortran 4.5.
It happily accepts the following and does not throw an error
in the END clause case:
READ(lun,END=100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #6 from Manfred Schwarb manfred99 at gmx dot ch ---
There is ./configure --disable-isl-version-check,
but I doubt that it will help. The thing is, isl-0.13 needs
cloog-0.18.2 (or rather, cloog-0.18.1 needs isl-0.12.2 and does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
Manfred Schwarb manfred99 at gmx dot ch changed:
What|Removed |Added
CC||manfred99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #8 from Manfred Schwarb manfred99 at gmx dot ch ---
The graphite-isl-ast-to-gimple.c code reads
#ifdef HAVE_cloog
#include isl/set.h
#include isl/map.h
#include isl/union_map.h
#include isl/ast_build.h
#if defined(__cplusplus)
extern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #29 from Manfred Schwarb manfred99 at gmx dot ch ---
The regression flag was re-added by Tobias in comment 23 due to
a regression in the testcase of comment 21:
!234567
character buffer*10
integer i,j
DO j
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #22 from Manfred Schwarb manfred99 at gmx dot ch 2013-02-15
10:20:46 UTC ---
Last month I had a private communication with Jerry, whether this bug
can be closed. I decided to add a summary to the bugzilla page:
The fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029
Manfred Schwarb manfred99 at gmx dot ch changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #21 from Manfred Schwarb manfred99 at gmx dot ch 2012-04-18
09:01:46 UTC ---
This new version does fix it, timings are around 0.2s for the
above test-case (exactly as fast as the user-optimized len_trim
variant). Thanks a lot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029
Bug #: 53029
Summary: missed optimization in internal read (without
implied-do-loop)
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #16 from Manfred Schwarb manfred99 at gmx dot ch 2012-03-19
09:42:29 UTC ---
Thanks, Janne, for your patch. It does not help very much, though.
[ As expected, as the reading part is the bottleneck ]
My current timings of the second
--- Comment #7 from manfred99 at gmx dot ch 2010-04-01 07:42 ---
Thanks for the quick fix!
I can confirm that the patch works for both the (a) and the * case.
In the code, there is still some size_t reference, should
probably be gfc_offset as well:
if (u == NULL)
return
--- Comment #17 from manfred99 at gmx dot ch 2010-04-01 20:35 ---
I will test this new patch, thanks.
Meanwhile, I found that the following works, too:
size_t
PREFIX(ftell) (int * unit)
{
gfc_unit * u = find_unit (*unit);
gfc_offset ret;
if (u == NULL)
return ((size_t) -1
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
--- Comment #10 from manfred99 at gmx dot ch 2010-01-16 18:13 ---
Created an attachment (id=19625)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19625action=view)
test case 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
--- Comment #11 from manfred99 at gmx dot ch 2010-01-16 18:35 ---
With test case 2, I get
./writebug2 writebug2.txt
Interation1 : 25
Interation2 : 32
Interation3 : 39
Interation4 : 46
--- Comment #12 from manfred99 at gmx dot ch 2010-01-16 21:43 ---
To clarify, this was still with the unpatched gfortran 4.5.0,
snapshot of 20100107.
BTW, the silly, stray line anzarg2=j in writebug2.f
does not alter the result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
at fold-const.c:10033
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http
--- Comment #13 from manfred99 at gmx dot ch 2010-01-16 23:48 ---
I now built gfortran 4.5.0 (20100107) + Jerry's patch.
Patch works for me, no SIGSEGV any more. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
--- Comment #1 from manfred99 at gmx dot ch 2010-01-14 12:42 ---
Created an attachment (id=19596)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19596action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42744
--- Comment #2 from manfred99 at gmx dot ch 2010-01-14 12:43 ---
This write statement is called in a loop, and it crashes at the
second iteration.
I did first a test case with only this write statement, and it
works OK.
Then, I put a loop around it, and I catched it!
So the attached
--- Comment #2 from manfred99 at gmx dot ch 2010-01-14 12:59 ---
*** Bug 42744 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
--- Comment #3 from manfred99 at gmx dot ch 2010-01-14 12:59 ---
Sorry, I made a mess.
*** This bug has been marked as a duplicate of 42742 ***
--
manfred99 at gmx dot ch changed:
What|Removed |Added
--- Comment #3 from manfred99 at gmx dot ch 2010-01-14 13:01 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42744
for comments and test case.
Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
--- Comment #6 from manfred99 at gmx dot ch 2010-01-14 13:44 ---
fmtstr is put together at runtime, each column may (and actually does
sometimes) have different width (minimal width to save space), so
- no, your work around does not work for me
- no, this example is not contrived
, regression: I/O performance
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http
--- Comment #2 from manfred99 at gmx dot ch 2008-11-20 14:59 ---
The profiling of the second testcase gives
% cumulative self self total
time seconds secondscalls Ts/call Ts/call name
44.20 8.34 8.34 next_char
--- Comment #4 from manfred99 at gmx dot ch 2008-11-20 16:09 ---
Consider
!234567
program internalread3
implicit none
character value*10
integer i,j
DO j=1,
write(value,'(i4)') j
write(*,*) value(1:4)
read(value(1:LEN_TRIM
--- Comment #7 from manfred99 at gmx dot ch 2008-01-22 08:41 ---
Hmm,
I like the idea of being able to compile also legacy code with gfortran.
However, I really see the point Steve is making. With this patch things
get confusing.
If you consider a modified version of Steve's example
--- Comment #8 from manfred99 at gmx dot ch 2008-01-22 09:23 ---
Gaa, my example is BS, of course.
The really interesting thing is however, that g77 compiles it just fine
and happily treats 1 as continuation line.
What a can of worms!!
--
http://gcc.gnu.org/bugzilla
--- Comment #4 from manfred99 at gmx dot ch 2008-01-18 08:59 ---
I bisected it using the binaries of Tobias:
gcc-trunk-x86_64-2008-01-15-r131542.tar.gz works
gcc-trunk-x86_64-2008-01-16-r131566.tar.gz is broken
inbetween there exist mainly only 2 relevant commits:
- r131553 Th. Koenig
--- Comment #6 from manfred99 at gmx dot ch 2008-01-18 13:26 ---
Yes, PR 34817 pass (both) for me too, with your binaries as well as with
the binaries of FX.
I just checked my testcase (this PR) with the binaries of FX, it breaks
after 2008-01-15, same as with your binaries
at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
--- Comment #1 from manfred99 at gmx dot ch 2008-01-17 22:45 ---
shorter version:
Logical*1 :: bmp(1),bmpv(1)
bmp(1)=.false.
bmpv(1)=.true.
if ( ANY(bmp(1:1) .NEQV. bmpv(1:1)) ) then
print*,hello
endif
end
Logical, Logical*2 and Logical*4
--- Comment #27 from manfred99 at gmx dot ch 2007-10-12 15:28 ---
With gcc of today (patched tree-ssa-forwprop.c to make it bootstrap):
# gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gfortran-source/gcc/configure --enable-languages=fortran
--disable
--- Comment #7 from manfred99 at gmx dot ch 2007-10-05 09:36 ---
Ok, I managed to produce a testcase: a wrapper around the miscompiled
function and all the missing routines. Input data is read from a binary file,
so the program has to be run on a x86 machine (littleendian).
I attach
--- Comment #8 from manfred99 at gmx dot ch 2007-10-05 09:39 ---
Created an attachment (id=14300)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14300action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
--- Comment #5 from manfred99 at gmx dot ch 2007-10-05 09:37 ---
Created an attachment (id=14299)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14299action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
--- Comment #6 from manfred99 at gmx dot ch 2007-10-05 09:38 ---
(From update of attachment 14299)
sorry, for wrong bug
--
manfred99 at gmx dot ch changed:
What|Removed |Added
: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
--- Comment #1 from manfred99 at gmx dot ch 2007-10-03 12:46 ---
Created an attachment (id=14288)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14288action=view)
Source code of affected function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
--- Comment #2 from manfred99 at gmx dot ch 2007-10-03 12:47 ---
Created an attachment (id=14289)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14289action=view)
Assembler code of original code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
--- Comment #3 from manfred99 at gmx dot ch 2007-10-03 12:49 ---
Created an attachment (id=14290)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14290action=view)
Assembler code when commenting line 315, works
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
--- Comment #5 from manfred99 at gmx dot ch 2007-10-03 20:10 ---
Subject: Re: optimization bug: wrong code with
-fforce-addr
--- Comment #4 from ubizjak at gmail dot com 2007-10-03 15:43 ---
Please provide enough sources to create an _executable_ that shows the
failure
--- Comment #3 from manfred99 at gmx dot ch 2007-09-02 11:53 ---
Jerry, any news on this?
I have seen this pattern many times in legacy fortran77 code,
and the code authors seem to assume that ridiculously large loop
stop values do not compromize performance.
After all, in fortran77
optimization in internal read
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org
variables
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27634
--- Comment #5 from manfred99 at gmx dot ch 2005-11-04 15:32 ---
1) There is an easy way to circumvent the ICE:
if you add an explicit type conversion for IMAX, such as in
REAL:: AUX1(25000+INT(0.82*float(IMAX)))
the ICE goes away and gfortran compiles it successfully
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19589
--- Additional Comments From manfred99 at gmx dot ch 2004-12-12 21:01
---
Subject: Re: ICE with computed array declaration
This example is from the software copygb
(ftp://ftpprd.ncep.noaa.gov/pub/cpc/wd51we/copygb) which was ported
from generic Fortran95 to g95,
and thus compiles
1 - 100 of 101 matches
Mail list logo
