-garching dot mpg dot de
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=44778
--- Comment #1 from martin at mpa-garching dot mpg dot de 2010-07-02 07:33
---
Created an attachment (id=21060)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21060action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44778
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host
--- Comment #1 from martin at mpa-garching dot mpg dot de 2010-07-02 08:14
---
Created an attachment (id=21061)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21061action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44780
--- Comment #16 from martin at mpa-garching dot mpg dot de 2010-06-14
12:46 ---
(In reply to comment #15)
I have found the problem in the meantime ... it's my mistake, sorry about the
noise :(
The problem is that I did not explicitly zero the arrays in main(), so they
apparently
--- Comment #14 from martin at mpa-garching dot mpg dot de 2010-06-09
12:06 ---
SSE performance is fine again, thanks a lot!
One more question, if that's OK...
Depending on ARRSZ the testcase uses wildly varying amounts of CPU time; it's
about half a second for ARRSZ=1024, but almost
optimizing
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build
--- Comment #1 from martin at mpa-garching dot mpg dot de 2010-06-09 17:42
---
Created an attachment (id=20879)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20879action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
--- Comment #5 from martin at mpa-garching dot mpg dot de 2010-06-08 13:54
---
(In reply to comment #2)
We have (4.4):
bb 2:
va.f[0] = a-r;
va.f[1] = a-g;
va.f[2] = a-b;
va.f[3] = 0.0;
pretmp.40 = va.v;
ivtmp.61 = 0;
[...]
Could you please tell me the compiler
: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
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
--- Comment #1 from martin at mpa-garching dot mpg dot de 2010-06-05 10:18
---
Created an attachment (id=20849)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20849action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
--- Comment #7 from martin at mpa-garching dot mpg dot de 2010-01-07 15:16
---
Created an attachment (id=19499)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19499action=view)
Proposed wwwdocs patch to explain the apparent performance regression
Here is a proposed patch to gcc
--- Comment #5 from martin at mpa-garching dot mpg dot de 2009-12-17 14:12
---
GCC with -std=c99 makes sure to properly handle the i387 FPU excess precision.
With -fexcess-precision=fast the code is as fast (and non-conforming) like
with GCC 4.4. Using -std=gnu99 is also an option
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686
--- Comment #1 from martin at mpa-garching dot mpg dot de 2009-12-15 08:41
---
Created an attachment (id=19305)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19305action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
--- Comment #2 from martin at mpa-garching dot mpg dot de 2009-12-15 08:42
---
Created an attachment (id=19306)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19306action=view)
assembler generated by gcc 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
--- Comment #3 from martin at mpa-garching dot mpg dot de 2009-12-15 08:43
---
Created an attachment (id=19307)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19307action=view)
assembler generated by gcc 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40206
--- Comment #3 from martin at mpa-garching dot mpg dot de 2009-05-20 13:03
---
(In reply to comment #2)
I'd suspect this to be a related to Jakub's recent changes applied for PR39666
(i.e. r147136)? Does your testcase work for r147135?
I cannot check this quickly. However I tried
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38022
--- Comment #2 from martin at mpa-garching dot mpg dot de 2008-11-05 21:37
---
Why do you think this is a bug?
-Wshadow warns even for:
int foo;
int (*fn) (int foo);
I'm probably missing something obvious here...
The first line in your example defines an integer variable called
--- Comment #4 from martin at mpa-garching dot mpg dot de 2008-11-06 06:59
---
Thanks a lot for the explanation! I wasn't aware that things like
int func (long foo, int (*fn)(int foo, char (*bar)[sizeof (foo)]));
were even allowed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #7 from martin at mpa-garching dot mpg dot de 2008-10-20 12:48
---
I still see the crash:
/scratch/blah4/planck/LevelSgfortran -v -c -O2 testcase.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure
--prefix=/afs/mpa/data
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla
--- Comment #1 from martin at mpa-garching dot mpg dot de 2008-08-30 07:17
---
Created an attachment (id=16170)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16170action=view)
a reduced test case
to reproduce to problem, compile with -O2.
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from martin at mpa-garching dot mpg dot de 2008-05-07 09:35
---
Created an attachment (id=15590)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15590action=view)
a (not really reduced) test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36168
--- Comment #6 from martin at mpa-garching dot mpg dot de 2008-05-07 09:57
---
OK. Thanks for the clarification!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36168
--- Comment #4 from martin at mpa-garching dot mpg dot de 2008-05-07 09:51
---
It would be completely fine by me, if g++ simply emitted bogus warnings in a
consistent way. But the syntax is still confusing, and what seems quite
disconcerting to me is the fact that _both_ warnings
(and strange) warnings with -Wuninitialized
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC
in gfc_trans_assignment_1
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
--- Comment #6 from martin at mpa-garching dot mpg dot de 2007-04-27 08:02
---
I confirm that this is fixed for me on mainline.
Is the patch non-invasive enough for a backport to 4.2 (possibly after the
4.2.0 release)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25923
--- Comment #8 from martin at mpa-garching dot mpg dot de 2007-04-13 09:46
---
works for me again, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31526
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31526
--- Comment #1 from martin at mpa-garching dot mpg dot de 2007-04-10 12:54
---
Created an attachment (id=13343)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13343action=view)
unreduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31526
--- Comment #13 from martin at mpa-garching dot mpg dot de 2007-03-23
07:49 ---
Could you please have a look at this before 4.2.0 is released?
It seems (at least to me), that a lot can be gained (i.e. OpenMP
works on x86_64) by very little work. Or is the proposed workaround
: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
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
--- Comment #1 from martin at mpa-garching dot mpg dot de 2007-02-19 22:32
---
Sorry, I meant PR25874.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30866
--- Comment #2 from martin at mpa-garching dot mpg dot de 2007-02-19 22:39
---
Created an attachment (id=13071)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13071action=view)
preprocessed, unreduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30866
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30715
--- Comment #12 from martin at mpa-garching dot mpg dot de 2007-01-29
10:04 ---
Well, I just copy libgomp.spec from lib64/ to lib/ by hand after installing.
For the long term this not the right thing of course, but as a quick fix it
works.
--
http://gcc.gnu.org/bugzilla
--- Comment #13 from martin at mpa-garching dot mpg dot de 2007-01-23
16:53 ---
Could this be an enable-checking issue?
I'm only seeing the problem when configuring with --enable-checking=release,
otherwise the compiler bootstraps fine.
This is on i686-pc-linux-gnu.
(I also have
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30408
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30120
--- Comment #10 from martin at mpa-garching dot mpg dot de 2006-11-23
09:22 ---
I can still reproduce the compilation problem with today's mainline.
I'll try with the 4.2 branch as soon as possible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
ReportedBy: martin at mpa-garching dot mpg dot de
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=29567
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-10-23 19:50
---
(In reply to comment #1)
Can you try the patch in:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01168.html
?
Yes, this patch fixes the problem. Thanks for the prompt reply!
--
http://gcc.gnu.org
: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-08-25 12:57
---
Hi Paul,
sorry for the late reply, I was away for a few days.
I compiled the most recent gcc sources, and there still appears to be some
bad memory access inside gfortran, which causes the compiler
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-08-25 14:36
---
Created an attachment (id=12139)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12139action=view)
new testcase
Compile with gfortran -c lensing.f90
and with gfortran -c -I. lensing.f90
--
http
--- Comment #10 from martin at mpa-garching dot mpg dot de 2006-08-25
14:37 ---
Perhaps you can let me have an idea of the kind of code that is doing
this? Is this a continuation of the derived type problem or did it
exist prior to the patch of a week back?
I don't think
: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
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
: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
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
--- Comment #21 from martin at mpa-garching dot mpg dot de 2006-08-21
11:58 ---
(In reply to comment #20)
Fixed on trunk and 4.1
Thanks! The incorrect warnings have gone away.
However, if I provoke correct warnings now, the line numbers in the warning
messages are really confused
--- Comment #23 from martin at mpa-garching dot mpg dot de 2006-08-21
16:59 ---
(In reply to comment #22)
I have a half memory that there is already a PR for this. Could you
check first before submitting a new one, please?
If you are referring to PR21918, I think the current
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28771
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-08-03 06:22
---
(In reply to comment #3)
Andrew, I think it is a bug. The language in section 12.4.1.5 is somewhat
convoluted and the description of PRESENT() suggest that PRESENT is special.
From 12.4.1.5
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-08-03 06:40
---
(In reply to comment #8)
I just submitted a patch that appears to fix the problem.
The problem is __convert_* (ie internal gfortran functions)
are caught by the error checking.
Hmm, but my point
--- Comment #6 from martin at mpa-garching dot mpg dot de 2006-06-08 09:51
---
I have now reproduced the problem on two different x86_64 systems. Could you
please reopen the PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
--- Comment #12 from martin at mpa-garching dot mpg dot de 2006-06-06
10:10 ---
This is now open since more than a year.
Is there any hope of getting it fixed for gfortran 4.2?
Correct uninitialized warnings are a very desirable feature IMO
and have always been a stron point in gcc
--- Comment #13 from martin at mpa-garching dot mpg dot de 2006-06-06
10:11 ---
(In reply to comment #12)
Correct uninitialized warnings are a very desirable feature IMO
Sorry, I meant unused of course :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-06-06 10:14
---
Is it possible to fix this before gcc 4.2?
Whenever I see these garbled warnings I have a very bad feeling that
something completely unintended is happening inside the compiler,
and I guess that many users
--- Comment #4 from martin at mpa-garching dot mpg dot de 2006-06-05 09:25
---
I just ran into the compile time problem on x86_64 again. Apparently lib64/ is
not searched for libgomp.spec.
--
martin at mpa-garching dot mpg dot de changed:
What|Removed
--- Comment #5 from martin at mpa-garching dot mpg dot de 2006-06-05 09:45
---
I just ran into the compile time problem on x86_64 again. Apparently lib64/ is
not searched for libgomp.spec.(In reply to comment #4)
I just ran into the compile time problem on x86_64 again. Apparently
--- Comment #16 from martin at mpa-garching dot mpg dot de 2006-06-05
10:12 ---
(In reply to comment #15)
This is a P1 -- but WAITING for a testcase.
I tried to reproduce the problem with today's mainline (20060605), but it was
gone, so I think the bug can be closed. In any case I
--- Comment #12 from martin at mpa-garching dot mpg dot de 2006-05-29
08:53 ---
This bug prevents the current release of the Globus toolkit
(www.globus.org) from compiling.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
--- Comment #6 from martin at mpa-garching dot mpg dot de 2006-05-29 12:24
---
The problem appears to have gone; I cannot reproduce it any more with current
mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27322
--- Comment #14 from martin at mpa-garching dot mpg dot de 2006-05-16
12:49 ---
Even with PR 26304 fixed, the testsuite still crashes with a segfault in the
same place. I'm using FFTW 3.1.1 now, but the testing procedure is the same.
Again, the problem disappears with -fno-ivopts
--- Comment #5 from martin at mpa-garching dot mpg dot de 2006-05-03 09:46
---
(In reply to comment #4)
We still need a self contained testcase to reproduce this issue.
I tried producing one, but it seems that this would take me much more time
than I can currently afford, especially
--- Comment #8 from martin at mpa-garching dot mpg dot de 2006-05-02 10:16
---
Hmm, I'm seeing a new ICE that could be related to your patch:
function rombint()
implicit none
real :: rombint
integer :: i, j
real :: g(6), g0, g1
10i=i+1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27323
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-04-26 12:14
---
(In reply to comment #1)
Can you try disabling VRP and enable -fwrapv and -fno-strict-aliasing? (I
also
see failures in other scientific codes with mainline)
I reconfigured with
CFLAGS=-m32 -O2 -fomit
--- Comment #3 from martin at mpa-garching dot mpg dot de 2006-04-26 13:22
---
The failure appears to be connected to -march=pentium4.
The lowest optimisation setting where I could reproduce it is
CFLAGS=-O1 -march=pentium4 ./configure
The test pass with -O0 -march=pentium4
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-04-25 09:09
---
(In reply to comment #7)
@Martin: I tried to reduce your testacse a little and got a segfault in
can_throw_internal_1. So this is probably the same problem as PR26913.
However the original segfault
--- Comment #4 from martin at mpa-garching dot mpg dot de 2006-04-14 10:24
---
Hi Jakub,
with your patch, the testcase passes for me.
Unfortunately the unreduced testcase of PR26084 still causes
an ICE, but this time only with -O switched on.
[EMAIL PROTECTED]:~/Desktop g++ -m32 -c
--- Comment #16 from martin at mpa-garching dot mpg dot de 2006-03-22
14:37 ---
(In reply to comment #15)
Fixed.
Unfortunately the unreduced testcase still fails with -O:
/scratchg++ -O -v -fopenmp bug.ii
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/gcc
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #14 from martin at mpa-garching dot mpg dot de 2006-03-09
15:11 ---
(In reply to comment #13)
If it is DIRECT I/O you are doing, this is a different story and record sizes
are fixed length.
Yes, that's what I'm talking about. Consider:
PROGRAM TESTRECL
--- Comment #12 from martin at mpa-garching dot mpg dot de 2006-03-09
07:12 ---
(In reply to comment #11)
OK, after some discussion on comp.lang.fortran it is clear tha END and EOR are
not error conditions. They are there to allow for example, reading in a loop
until the end
--- Comment #8 from martin at mpa-garching dot mpg dot de 2006-03-06 12:10
---
Mainline works correctly again, thanks!
Do you plan to commit to the 4.1-branch too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26554
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-03-06 13:22
---
I just noticed another (probably related) problem:
The following Fortran code is derived from some autoconf test:
PROGRAM TESTRECL
IMPLICIT NONE
OPEN(UNIT = 10,FILE = 'conftest.rcl1
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-03-06 14:33
---
When trying to compile the Starlink sources with gfortran I stumbled across
this too. Unfortunately it seems that one of their autoconf tests called
AC_FC_RECL_UNIT relies on the jump to the ERR label when
--- Comment #11 from martin at mpa-garching dot mpg dot de 2006-03-06
14:41 ---
On Comment #9: This is not really a bug depending on how one interprets the
f95 standard. The three error families, EOR, END, and ERR are each treated
separately. EOR and END are not considered
: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
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
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-03-04 17:53
---
I hope this isn't in the 4.1 release. I don't have one lying around to test,
sorry.
However, it is on the 4.1 branch, and if it isn't in the release, it should be
very simple to locate.
--
http
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-03-03 10:11
---
I managed to narrow down the location of the problem:
The segfault occurs in libbench2/verify-lib.c, in
static void assign_conj(C *Ac, C *A, int rank, const bench_iodim *dim, int
stride);
I added
--- Comment #12 from martin at mpa-garching dot mpg dot de 2006-03-03
14:22 ---
(In reply to comment #10)
Can you try -O1 -fno-ivopts -ftree-vrp -finline-functions?
I want to see if this is an interaction between VRP and IVopts, if it is there
is a bug about this issue already
3.1
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc
--- Comment #1 from martin at mpa-garching dot mpg dot de 2006-03-02 11:00
---
I just checked that
CFLAGS=-O3 ./configure --enable-portable-binary
fails, but
CFLAGS=-O3 ./configure --enable-portable-binary
works as it should.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-03-02 11:01
---
(In reply to comment #1)
I just checked that
CFLAGS=-O3 ./configure --enable-portable-binary
fails, but
CFLAGS=-O3 ./configure --enable-portable-binary
Sorry for the typo here. I meant, of course
--- Comment #4 from martin at mpa-garching dot mpg dot de 2006-03-02 12:18
---
(In reply to comment #3)
Do you have a simple testcase?
I wish I had :(
At the moment I'm trying to find out which optimisation flags are causing the
trouble. The current minimum set of flags to reproduce
--- Comment #6 from martin at mpa-garching dot mpg dot de 2006-03-02 13:52
---
(In reply to comment #5)
Can you try -O3 -fwrapv? It might be the source have undefined code in it
for signed overflow and changes to VRP exposed it.
Bingo! Thanks for this hint, I wouldn't have found
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-03-02 14:29
---
(In reply to comment #6)
If I understand correctly, this is most likely a bug in FFTW, right? If so,
I'll report it to FFTW people.
On the other hand, gcc 4.1 also has VRP, but it seems to work fine. Has
--- Comment #13 from martin at mpa-garching dot mpg dot de 2006-03-01
12:39 ---
It appears that this bug also prevents FFTW 3.1 from compiling.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
--- Comment #5 from martin at mpa-garching dot mpg dot de 2006-02-23 09:01
---
I still see it with version 4.2.0 20060222 :(
I guess it would really nice if gfortran -v would print the SVN revision
number...
~/tmpgfortran -v -c bug.f90
Using built-in specs.
Target: i686-pc-linux-gnu
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
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
--- Comment #5 from martin at mpa-garching dot mpg dot de 2006-02-07 10:44
---
(In reply to comment #4)
I still get the segmentation fault. Probably because I configured with
--enable-checking=release...
I can confirm that I get the same error message reported Volker if I boostrap
--- Comment #4 from martin at mpa-garching dot mpg dot de 2006-02-06 11:15
---
(In reply to comment #3)
I don't get a segfault, but the error message:
bug.cc:11: internal compiler error: vector VEC(eh_region,base) index domain
error, in can_throw_internal_1 at except.c:2580
I
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-02-04 11:31
---
Reduced testcase:
template typename T struct arr {
long s;
T *d;
arr(long sz) : s(sz), d (s0 ? new T[s] : 0) {}
~arr() { delete[] d; }
T operator[] (int n) {return d[n];}
};
void map2alm
1 - 100 of 179 matches
Mail list logo
