4.2.0
Status: UNCONFIRMED
Severity: minor
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
Summary: missed optimization, 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
Report
--- 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(
--- 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 and
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
--- 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
n: 4.3.0
Status: UNCONFIRMED
Severity: 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=14288&action=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=14289&action=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=14290&action=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 sho
--- 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 a
--- 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=14300&action=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=14299&action=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
--- 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
nedTo: unassigned 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&qu
--- 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
--- 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 ex
--- 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.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
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&action=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
--- 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=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 wh
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=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 get_uniqu
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 #9 from Manfred Schwarb ---
I sprinkled some printf's into get_unique_type_string():
XXderived->name: strlen=63;
t2345678901234567890123456789012345678901234567890123456789_123
XXdt_name: strlen=63;
T234567890123456789012345678901234
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"
s
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=95687
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
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 b
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 in stage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #22 from Manfred Schwarb 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 of Thomas is restricted to sca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029
Manfred Schwarb changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #16 from Manfred Schwarb 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 test case:
g77: 12.41s
4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #21 from Manfred Schwarb 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!
However, I don't see why this
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
Summary: missed 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
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=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: i686-li
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 #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 -print-prog-name=f
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(a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
Manfred Schwarb changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
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
b=R
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 #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 #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 #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.
For
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&action=edit
documentation changes for conversion intrinsics
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 la
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&action=edit
extended patch from comment #4 to also cover gfc_simplify_dble and
gfc_simplify_sngl
Note, I do not have nei
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=35339
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
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.
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=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 G
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&#
Summary: Regression: wrong results with ftell
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://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
--- 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
--- 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
Severity: major
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=revision&revision=222178),
my boots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65971
--- Comment #2 from Manfred Schwarb ---
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/install/specific.html,
at lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #29 from Manfred Schwarb ---
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=1,
write(buffer,'
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=61792
--- Comment #6 from Manfred Schwarb ---
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
not build with isl-0.13), which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #8 from Manfred Schwarb ---
The graphite-isl-ast-to-gimple.c code reads
#ifdef HAVE_cloog
#include
#include
#include
#include
#if defined(__cplusplus)
extern "C" {
#endif
#include
#if defined(__cplusplus)
}
#endif
#endif
and v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #10 from Manfred Schwarb ---
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 isl-0.11 does no longer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
--- Comment #25 from Manfred Schwarb ---
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,*) "whatever"
Not that the abo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
--- Comment #26 from Manfred Schwarb ---
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) buffer
100 WRITE(lun,*) "wh
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168
--- Comment #1 from Manfred Schwarb ---
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 in revision 205392 by hjl.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168
--- Comment #4 from Manfred Schwarb ---
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.
"default_ld" is empty f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168
--- Comment #6 from Manfred Schwarb ---
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=release --disable-libmudflap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168
--- Comment #8 from Manfred Schwarb ---
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 set = set
+ :
+ enableva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66255
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42744
--- 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=19596&action=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
- in
--- 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=19625&action=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 :
--- 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_
s "-frecursive -fcheck=all"
--
Summary: ICE 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
Report
--- 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
0.0
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
MED
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=18271
--- 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
: 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_he
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.
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 pro
1 - 100 of 102 matches
Mail list logo
