--- 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 #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
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
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
--- 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=
--- 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 #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 #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 #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 #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 #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. Apparen
--- 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 #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 #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 #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
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 #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.
o: 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=24774
--- Comment #1 from martin at mpa-garching dot mpg dot de 2005-11-10 12:19
---
Some more comments:
- the problem was already present before the 20051109 merge; I just
waited for the merge to see if it would go away
- I'm seeing the same problem on x86_64
--
http://gcc.gn
--- Comment #8 from martin at mpa-garching dot mpg dot de 2005-11-11 07:46
---
The bug seems to have disappeared from current mainline and is not present
on gomp branch either. Should it be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
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/bugzilla/show_bug.cgi?id=24789
other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24845
real_1
Product: gcc
Version: unknown
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: i
--- Comment #1 from martin at mpa-garching dot mpg dot de 2005-11-14 15:14
---
> gcc version 4.1.0-gomp-20050608-branch 20051109 (experimental) (merged
20051109)
BTW, it appears as if the compiler datestamp is not correctly updated on
the gomp branch (it says 20051109, but there h
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-11-15 09:07
---
Some more information:
- I didn't encounter the bug about a week ago
- on x86_64 with checking disabled, I get
[EMAIL PROTECTED]:~/martin> g++ -c -v -fopenmp test.cc
Using built-in specs.
Target
rity: 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=24875
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-11-15 21:09
---
(In reply to comment #2)
> It fails on powerpc64-linux with both -m32 and -m64 for current trunk,
> 4.0 branch, and GCC 4.0.0. Since it's Fortran 90 code it's not really
> a regression.
--- Comment #4 from martin at mpa-garching dot mpg dot de 2005-11-15 21:09
---
> The code works for me on amd64-*-freebsd. Can
> you compile the failing code with -fdump-parse-tree
> and post both mod1.mod and the parse-tree?
Will do tomorrow.
--
http://gcc.gnu.org
--- Comment #5 from martin at mpa-garching dot mpg dot de 2005-11-15 21:16
---
~/tmp>gfortran -c -fdump-parse-tree huge.f90
Namespace: A-Z: (UNKNOWN 0)
procedure name = mod1
symtree: gndp_max Ambig 0
symbol gndp_max (REAL 8)(PARAMETER UNKNOWN-INT
--- Comment #11 from martin at mpa-garching dot mpg dot de 2005-11-20
12:10 ---
(In reply to comment #4)
I reran the test with the current gfortran. This is what I get:
~/tmp>gfortran -Wunused -W -v -c -O2 bla.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured w
--- Comment #8 from martin at mpa-garching dot mpg dot de 2005-12-11 09:40
---
I re-tested today with versions 3.3.2, 4.0-branch, 4.1-branch, trunk and
gomp-branch, and could not reproduce the regression any more.
So I think this report can be closed. Thanks to the unknown patcher
fortran] ICE in gfc_conv_component_ref, at
fortran/trans-expr.c:269
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Repo
--- Comment #1 from martin at mpa-garching dot mpg dot de 2005-12-22 09:43
---
Created an attachment (id=10549)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10549&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25532
--- Comment #7 from martin at mpa-garching dot mpg dot de 2005-12-28 11:36
---
(In reply to comment #6)
> I have just submitted a patch for this, which I intend to commit tomorrow
> morning.
Great, thanks!
> Thank you for reporting the bug I hope that the inconvenience is o
--- Comment #10 from martin at mpa-garching dot mpg dot de 2005-12-29
09:12 ---
I just recompiled and everything works nicely again. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25532
NFIRMED
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 triple
--- Comment #5 from martin at mpa-garching dot mpg dot de 2006-01-04 15:15
---
(In reply to comment #4)
> (In reply to comment #3)
>
> > We really don't set __n in all cases here.
>
> And indeed we do *not* want to set __n in all cases: if for some reason the
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-01-16 11:14
---
I have re-tested today, and it seems that the problem only occurs when gfortran
is built using a self-compiled version of GMP 4.1.3. When using the system-wide
installed GMP 4.1.4 I don't get the erro
portedBy: 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=25874
--- Comment #1 from martin at mpa-garching dot mpg dot de 2006-01-20 14:41
---
Created an attachment (id=10685)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10685&action=view)
test case to reproduce the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25874
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-01-20 19:17
---
Reduced testcase:
int foo();
struct wigner_d
{
void recurse () {
int dd;
for (int j=0; j<=1; ++j) {
#pragma omp parallel
dd=5;
}
}
};
template void rotate_alm(T
--- 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 #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
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
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
--- 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
--- 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
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 #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
--- 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 #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&#
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 #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
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
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
--- 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=13071&action=view)
preprocessed, unreduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30866
--- 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
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 #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
--- 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 #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
--- Additional Comments From martin at mpa-garching dot mpg dot de
2005-03-08 12:19 ---
Here is a shorter testcase:
class foo {
public:
int f1(int);
};
template class bar: public foo {
void baz () {
&foo::f1;
}
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
--
What|Removed |Added
CC||martin at mpa-garching dot
||mpg dot de
http://gcc.gnu.org
--- Additional Comments From martin at mpa-garching dot mpg dot de
2005-03-15 13:25 ---
As far as I know, this regression is only present in mainline, but not on the
4.0 branch; but the title and "Known to fail" line of this report say the
regression is also in 4.0.
Could so
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 #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
--- 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
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 #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
--- 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
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
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
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
--- Comment #1 from martin at mpa-garching dot mpg dot de 2005-10-25 06:09
---
Would it be possible to add "gomp-branch" or something similar to the
"reported against" field in bugzilla?
--
martin at mpa-garching dot mpg dot de changed:
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-10-25 11:26
---
This patch appears to work very well, thanks!
However, later in my code I run into a problem of the following sort:
The (patched) compiler rejects the following code
void bar (int *p)
{
#pragma omp
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=24516
--- Comment #7 from martin at mpa-garching dot mpg dot de 2005-11-01 10:22
---
The regression is unfortunately still there :(
Reducing the testcase is really hard, and I have some indications
that the problem vanishes if there is less work to do in the critical loop.
If you have any
ode
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
CC: gcc-bugs at gcc d
--
What|Removed |Added
Keywords||ice-on-invalid-code
Known to fail||4.1.0
Known to work|
lity regression for complicated loop
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: pending
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mp
--- Additional Comments From martin at mpa-garching dot mpg dot de
2005-08-13 18:05 ---
Created an attachment (id=9494)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9494&action=view)
A testcase for the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
--- Additional Comments From martin at mpa-garching dot mpg dot de
2005-08-16 08:33 ---
(In reply to comment #2)
> Ouch. This badly needs reducing...
Absolutely. But since Andrew pointed out that it is probably related to PR 23302
and PR 23303 (which have nice testcases), I sugges
/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 #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
--- 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 #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 #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 #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
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 #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
--- 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 #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,
[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 #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
--- 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
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 #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
1 - 100 of 180 matches
Mail list logo
