--- 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=21061&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44780
d to g++) does not produce the warning
- the warning is only given for the case with the SSE2 type, not for the other
case with the more "conventional" types.
gcc/g++ 4.4.2 and 4.5.* do not issue warnings.
--
Summary: [4.6 regression] Bogus set-but-not-used variable warning
Pr
--- 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=21060&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44778
Summary: [4.6 regression?] Behaviour change with pointers to
members
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 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 #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
appar
--- 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=20879&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
[4.6 regression] gcc consumes all available memory when
optimizing
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
Repo
--- 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,
--- 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):
>
> :
> 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;
--- 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=20849&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
ts this regression.
Another observation: if I change ARRSZ in the testcase to 20 instead of 1024,
all executables run even more slowly (by about another factor of five); I have
absolutely no explanation for this :-/
--
Summary: [4.5/4.6] Massive performance regression in SSE code
--- 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=19499&action=view)
Proposed wwwdocs patch to explain the apparent performance regression
Here is a proposed patch
--- 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 i
--- 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=19307&action=view)
assembler generated by gcc 4.4
--
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=19306&action=view)
assembler generated by gcc 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
--- 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=19305&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/../../.. perf.o -lm
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/crtend.o
/usr/lib/crtn.o
I attach the test case and the two generated assembler files.
--
--- 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.
gcc
Version: 4.5.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 triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40206
--- 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.c
--- 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
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-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzil
--- Comment #7 from martin at mpa-garching dot mpg dot de 2008-10-20 12:48
---
I still see the crash:
/scratch/blah4/planck/LevelS>gfortran -v -c -O2 testcase.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure
--prefix=/afs/mpa/d
--- 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=16170&action=view)
a reduced test case
to reproduce to problem, compile with -O2.
--
http://gcc.gnu.org/b
ion: 4.4.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 triplet: i686-pc-linux-gn
--- 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
--- 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=15590&action=view)
a (not really reduced) test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36168
back to (at least) 4.2, but
did not open a PR about it before, since I wasn't able to provide a good
testcase. I hope the attached one is not completely useless ...
--
Summary: Incorrect (and strange) warnings with -Wuninitialized
Product: gcc
Version: 4.4.0
mary: ICE-on-invalid in gfc_conv_descriptor_dtype
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
Summary: [gfortran, regression] ICE 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
Reporte
--- 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
--- 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=13343&action=view)
unreduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31526
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=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
--- 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=13071&action=view)
preprocessed, unreduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30866
--- 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
ry: [4.3 regression] Another ICE in calc_dfs_tree()
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg do
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 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
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/show_bug.cgi?id=30408
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=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
--- 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://gc
cc 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=29567
Product: 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-g
--- 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&#
--- 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=12139&action=view)
new testcase
Compile with "gfortran -c lensing.f90"
and with "gfort
--- 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 to
mal
Priority: 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
h
--- 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 c
--- 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 confu
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: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown
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=28771
--- 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.
>
Hm
--- 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.
>
> F
--- 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 #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 #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 #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 po
--- 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 an
--- 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. Apparen
--- 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 #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 #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 #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 "-
--- 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, especia
--- 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
10
--- 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
--- 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=
riority: 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-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
ion: 4.2.0
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 targ
--- 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 se
--- 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&
--- 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:
/scratch>g++ -O -v -fopenmp bug.ii
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /s
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/bugz
--- 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:
--- 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 t
--- 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 consi
--- 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 #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
--- 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 #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 locat
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: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-g
--- 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 i
--- 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 the
--- 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 t
--- 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,
--- 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 r
--- 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
--- 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/bugz
2 regression] gcc miscompiles FFTW 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 do
--- 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...
~/tmp>gfortran -v -c bug.f90
Using built-in specs.
Target:
ponent: 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.
--- 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 Volke
--- 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
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-02-04 11:31
---
Reduced testcase:
template struct arr {
long s;
T *d;
arr(long sz) : s(sz), d (s>0 ? new T[s] : 0) {}
~arr() { delete[] d; }
T &operator[] (int n) {return d[n];}
};
void map2alm
1 - 100 of 180 matches
Mail list logo
