--- Comment #3 from pcarlini at suse dot de 2006-01-01 11:33 ---
Similarly to middle-end/25315, these failures too go away (on x86-linux, at
least) if the library is built less optimized, e.g., passing -O1 or -O0 in
CXXFLAGS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25308
The following is not optimised (I tested current 4.2) with -ffast-math -O2 (or
any of the other options I tried):
SUBROUTINE S41(a,b,c,N)
IMPLICIT NONE
integer :: N
real*8 :: a(N),b(N),c(N)
integer :: i
c=0.0D0
DO i=1,N
b(i)=b(i)+a(i)**(4.0D0/3.0D0)
c(i)=c(i)+a(i)**(2.0D0/3.0D0)
ENDD
The following doesn't run as fast as the 'hand-optimised' routine provided as
well (using current 4.2 on an opteron) using -ffast-math -O2 (makes a factor of
2 difference here). I've tried a number of further switches, but didn't manage
to find a case where the simply loop was as fast as the other.
A number of new fails have arisen on this target:
WARNING: gfortran.dg/namelist_11.f -O0 compilation failed to produce
executabl
e
WARNING: gfortran.dg/namelist_11.f -O1 compilation failed to produce
executabl
e
WARNING: gfortran.dg/namelist_11.f -O2 compilation failed to produce
executabl
e
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-01 17:00 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2006-01/msg00017.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25617
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-01 17:08 ---
Hmm, there really has not been any change in libgfortran which could have
caused this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25622
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-01
17:11 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
I've looked at the failure of a85013b.adb.
The problem seems to be that "new" is applying a kind of rounding
to
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-01 17:31 ---
What happens if you use -funroll-loops? It should get about the same
improvement.
Also your two loops not equal if N is old.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
Testcase:
SUBROUTINE S42(a,b,c,N)
IMPLICIT NONE
integer :: N
real*8 :: a(N),b(N),c(N),tmp,tmp2,tmp4
real*8, parameter :: p=1.0D0/3.0D0
integer :: i
c=0.0D0
DO i=1,N
tmp=a(i)**p ! could even be done with a cube root
tmp2=tmp*tmp
tmp4=tmp2*tmp2
b(i)=b(i)+tmp4
c(i)=c(i)+tmp2
EN
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-01 17:37 ---
I posted a patch that addresses the gcse.c part of the problem.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-01
17:39 ---
Subject: Re: undefined reference to `_gfortran_st_set_nml_var_dim'
> Hmm, there really has not been any change in libgfortran which could have
> caused this.
Agreed. Looking at transfer.o, we seem to som
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-01
17:44 ---
Subject: Re: undefined reference to `_gfortran_st_set_nml_var_dim'
> Agreed. Looking at transfer.o, we seem to somehow have lost the
> "_gfortran_" prefix:
>
> 3a48 T st_set_nml_var
> 3c0c T st_s
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-01 17:58 ---
Please open a new bug and instead of pasting into the bug, attach the
preprocessed source file.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
Compiling with the attached testcase:
$ g++ -frepo -c test.cc
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of
âmpl_::integral_câ:
/usr/include/boost/type_traits/integral_constant.hpp:21: instantiated from
âboost::integral_constantâ
/usr/include/boost/type_traits/ali
--- Comment #1 from rleigh at debian dot org 2006-01-01 18:00 ---
Created an attachment (id=10573)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10573&action=view)
Testcase
This requires the Boost format library (Boost.Format).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #2 from rleigh at debian dot org 2006-01-01 18:03 ---
Created an attachment (id=10574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10574&action=view)
Preprocessed source
This is the result of running
g++ -frepo -save-temps -c test.cc
--
http://gcc.gnu.org/bugzi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from jv244 at cam dot ac dot uk 2006-01-01 18:14 ---
(In reply to comment #1)
> What happens if you use -funroll-loops? It should get about the same
> improvement.
I have the following timings (for N=1024, calling these subroutines a number of
times+some external initial
--- Comment #3 from rleigh at debian dot org 2006-01-01 18:16 ---
This is the original report, in Debian Bug #345550:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345550
This contains all the information already filed here, so this is just for the
record.
--
rleigh at debian dot
Just to make sure we don't forget about this rather serious issue:
http://gcc.gnu.org/ml/gcc/2005-12/msg00250.html
http://gcc.gnu.org/ml/libstdc++/2005-12/msg00084.html
--
Summary: Valarray vs non-POD
Product: gcc
Version: 4.1.0
Status: UNCONFIRM
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-01 18:33 ---
Reduced testcase:
template< typename T, T N > struct integral_c {
static const T value = N;
typedef integral_c< T, value + 1 > next;
};
template< typename T, T N > T const integral_c< T, N >::value;
integral_c a;
--- Comment #3 from seidl at fel dot cvut dot cz 2006-01-01 18:38 ---
Subject: Re: wrong-code unless -fno-sched-interblock
The problem was detected with gcc-3.4.3 and gcc-3.4.4. I not tested the older
gcc versions. I tested gcc-4.0.1, and the problem on the small sample of code
was not
A number of new fails have arisen on this target:
WARNING: gfortran.dg/namelist_11.f -O0 compilation failed to produce
executabl
e
WARNING: gfortran.dg/namelist_11.f -O1 compilation failed to produce
executabl
e
WARNING: gfortran.dg/namelist_11.f -O2 compilation failed to produce
executabl
e
--- Comment #1 from danglin at gcc dot gnu dot org 2006-01-01 18:44 ---
*** This bug has been marked as a duplicate of 25622 ***
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from danglin at gcc dot gnu dot org 2006-01-01 18:44 ---
*** Bug 25627 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25622
$ cat bug.f90
module foo
implicit none
integer :: strlength = 20
contains
subroutine bar()
character(len=strlength) :: str
write (str, *) 0
end subroutine bar
end module foo
program test_foo
use foo
implicit none
strlength = 10
call bar()
en
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-01 18:49 ---
Adding Nick to the CC list, because he is the listed v850 port maintainer.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-01
18:54 ---
Subject: Re: undefined reference to `_gfortran_st_set_nml_var_dim'
> > Hmm, there really has not been any change in libgfortran which could have
> > caused this.
>
> Agreed. Looking at transfer.o, we see
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-01 19:07 ---
Is this really a bug, changing the subroutine to:
subroutine bar()
character(len=10) :: str
write (str, *) 0
end subroutine bar
Also cause the problem, if I increase the size by a couple, it
--- Comment #2 from eedelman at gcc dot gnu dot org 2006-01-01 19:27
---
(In reply to comment #1)
> Is this really a bug, changing the subroutine to:
> subroutine bar()
> character(len=10) :: str
> write (str, *) 0
> end subroutine bar
>
> Also cause the problem
(up to) gcc-3.4.3 -mcpu=601 compiled code uses the MQ register
(at least) gcc-4.0.1 -mcpu=601 compiled code doesn't use MQ any more
tested with:
simple function which calculates remainder
int mod(int a, int b) {
return a % b;
}
Why is that?
--
Summary: -mcpu=601 doesn't use MQ r
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-01 20:15 ---
This is most likely a cost issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25629
darwin-ppc gets the alignment of nested structs wrong if they contain long long
or double members.
The apple compiler, gcc version 4.0.1 (Apple Computer, Inc. build 5247)
does it 'correctly'.
Here an example for a wrong alignment:
struct A {long long a; unsigned char b;};
struct D {unsigned char
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-01 20:36 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23084
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.0.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=263
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24047
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24957
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24953
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-01 21:06 ---
Actually the patch was never committed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from joseph at codesourcery dot com 2006-01-01 22:18
---
Subject: Re: New: too agressive printf optimization
On Fri, 30 Dec 2005, drepper at redhat dot com wrote:
> There should at least be a mode in which gcc does not perform the
> transformation if it cannot be sur
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org
--- Comment #8 from joseph at codesourcery dot com 2006-01-01 22:24 ---
Subject: Re: Request for gcc-cvs-patches list
On Wed, 28 Dec 2005, pinskia at gcc dot gnu dot org wrote:
> Do we need this any more after svn as svn automatically does patch sets and
> doing a diff for a patch set
--- Comment #5 from rleigh at debian dot org 2006-01-02 00:06 ---
I've tested on hppa-linux-gnu and ia64-linux-gnu in addition to
powerpc-linux-gnu. All show identical behaviour, so this doesn't look
arch-specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-02 02:42 ---
Actually the reduced testcase is:
l = LEN((/'atan '/))
End
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 03:08 ---
If we make a tempary variable to hold the array, it works:
subroutine option_stopwatch_s(default_clock)
character(len=2), intent(in) :: default_clock
character(len=2), dimension(1) :: a
a = (/default_clock/)
call
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-02 03:11 ---
Another testcase:
subroutine option_stopwatch_s(n)
integer :: n
character(len=1) :: default_clock
call option_stopwatch_a((/default_clock/))
end subroutine option_stopwatch_s
--
pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-02 03:12 ---
(In reply to comment #3)
> Another testcase:
Ignore that one.
The correct one is:
subroutine option_stopwatch_s(n)
integer :: n
character(len=n) :: default_clock
call option_stopwatch_a((/default_clock/))
end subr
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-02 03:13 ---
the variable does not have to be a "dummy" variable either to reproduce this.
subroutine option_stopwatch_s()
character(len=1) :: default_clock
call option_stopwatch_a((/default_clock/))
end subroutine option_stop
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-02 03:31 ---
formal->sym->as is null in:
1606 f = (formal != NULL)
1607 && !formal->sym->attr.pointer
1608 && formal->sym->as->type != AS_ASSUMED_SHAPE;
1609
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-02 03:42 ---
D.784 = __result_foo > 1.8e+2f;
D.786 = __result_foo - 3.6e+2f;
D.788 = __result_foo <= -1.8e+2f;
D.790 = __result_foo + 3.6e+2f;
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-02 03:50 ---
Related to PR 17298.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDepen
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-02 03:59 ---
Reduced testcase which shows that the outer function does not have to return an
array to get the ICE:
FUNCTION dawson_v()
IMPLICIT NONE
REAL :: dawson_v
CONTAINS
FUNCTION dawsonseries_v()
IMPLICIT NO
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-02 04:00 ---
Also the following source fails in a slightly different way, an ICE in
fold_convert:
FUNCTION dawson_v()
IMPLICIT NONE
REAL :: dawson_v
dawson_v = 1.0
CONTAINS
FUNCTION dawsonseries_v()
IMPLICIT N
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-02 04:40 ---
I have a fix which I need to test.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kkojima at gcc dot gnu dot org 2006-01-02 05:13 ---
It looks an SH target specific problem.
CONSTRAINT_LEN in config/sh/sh.h of 3.4/4.0 checks the wrong
constraints and returns -1 for them. This causes an infinite
loop in parse_input_constraint whick has a loop like:
While studying some test cases for pr24268 I discovered this:
program tl
real x
character*13 line
x = 12.34
write(line,20) x
20 format(tr2,tl2,g11.4)
print *, "123456789012345"
print *, ">",line,"<"
end
The tl2 is not getting processed so the num
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-02 06:57 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-02 07:10 ---
We now get:
In file t.f90:1
10: a=10
1
Error: Too many digits in statement label at (1)
Is this okay or should we change it to be a diagnostic problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24640
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-02 07:16 ---
(In reply to comment #6)
> I will close this tonight
This never happened so I am closing it right now as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last re
62 matches
Mail list logo
