Compiling gfortran.dg/value_4.f90 with -fdefault-integer-8 gives the following
error:
/opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/value_4.f90:76.6:
if (delta ((3 * i), j)) call abort ()
1
Error: There is no specific function for the generic 'delta' at (1)
gcc version 4.3.0 20070731 (e
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-01 08:21
---
(In reply to comment #1)
> This should fix it.
This patch is pre-approved (as well as small variations and improvements of
it), though it might be worth opening an enhancement PR to note that if the
user code has
--- Comment #23 from rakdver at kam dot mff dot cuni dot cz 2007-08-01
09:55 ---
Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC
> Zdenek, do you have the access to a ppc64 machine to work on the bootstrap
> problem?
I do; however, I got stuck with another boo
--- Comment #22 from victork at il dot ibm dot com 2007-08-01 09:21 ---
Zdenek, do you have the access to a ppc64 machine to work on the bootstrap
problem? Can I provide an useful assistance?
-- Victor
--
victork at il dot ibm dot com changed:
What|Removed
--- Comment #24 from dorit at gcc dot gnu dot org 2007-08-01 10:08 ---
> I do; however, I got stuck with another bootstrap problem at the moment
> (vectorization changes alignment of variables, which causes a
> misscompilation of crtend.o on my machine;
I wonder if this is related to P
--- Comment #2 from patchapp at dberlin dot org 2007-08-01 11:05 ---
Subject: Bug number PR32945
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00022.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from victork at il dot ibm dot com 2007-08-01 11:24 ---
I've tried to build and run SPEC2006 403.gcc using r126903 and it did *not*
fail.
I've used following optimization flags in configuration file:
#
#
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-01 11:57 ---
Ryan, I wonder what happens if you force alignment in the source code, like so:
unsigned short count[MAXBITS+1] __attribute__ ((__aligned__(16))) ;
In this case the vectorizer does not change the alignment of the
--- Comment #4 from dorit at gcc dot gnu dot org 2007-08-01 11:36 ---
Also just for the record - the testcase for this PR is here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413#c14
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
--- Comment #16 from pluto at agmk dot net 2007-08-01 11:30 ---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > Created an attachment (id=13550)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13550&action=view) [edit]
> > > An experimental p
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-08-01 12:53 ---
Subject: Bug 32945
Author: dfranke
Date: Wed Aug 1 12:52:48 2007
New Revision: 127124
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127124
Log:
gcc/fortran:
2007-08-01 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #3 from dominiq at lps dot ens dot fr 2007-08-01 13:51 ---
The first test of PR32770, i.e.:
program main
real, dimension(2) :: a
call random_number(a)
print *,maxloc(a,mask=.true.)
end program main
with -fdefault-integer-8 and your patch, gives (PPC Darwin8):
pr32770
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-08-01 13:55 ---
Florian, thanks for the report!
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Compiling equiv_7_db.f90 with -fdefault-integer-8 gives:
/opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/equiv_7.f90:89.38:
data large(1),large(2) /2146435071,-1/
1
Error: Overlapping unequal initializers in EQUIVALENCE at (1)
/opt/gcc/gcc-4.3-work/gcc/tes
--- Comment #4 from dominiq at lps dot ens dot fr 2007-08-01 14:28 ---
gfortran.dg/minmaxloc_1.f90 gives the same error in my build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
Many failures in the test suite with -fdefault-integer-8 come from tests mixing
C and Fortran. While definitively not an expert in this area, I find pretty
obvious that changing the default integer/real type on one side and not the
other is asking for troubles. Apparently gfortran, but not the test
--- Comment #1 from kargl at gcc dot gnu dot org 2007-08-01 15:04 ---
At this point, the easiest fix is probably going to be to document
that -fdefault-integer-8 should not be used with bind(c) code. A
check of this option can be inserted at various locations during the
parsing.
--
--- Comment #1 from dominiq at lps dot ens dot fr 2007-08-01 15:10 ---
A similar problem occurs with gfortran.fortran-torture/execute/equiv_5.f which
hangs (does not stop, but no CPU time used). The following patch makes the test
pass:
[karma] f90/bug% diff
/opt/gcc/gcc-4.3-work/gcc/tes
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-1.c -std=iso9899:1999
-fno-show
-column -E -o c99-tgmath-1.i(timeout = 300)
In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-1.c:7:
/test/gnu
--- Comment #1 from ungala_le_babou at hotmail dot com 2007-08-01 15:26
---
I'm making an internship so i cannot change my version of gcc (which 4.1.1).
Since the bug is still unconfirmed, I wonder if it was fixed in the latest
version of gcc...
--
ungala_le_babou at hotmail dot com
--- Comment #5 from dominiq at lps dot ens dot fr 2007-08-01 15:36 ---
I have had a nonexpert look at the patch and I wonder if
+ ts.kind = gfc_default_logical_kind;
should not be
+ ts.kind = newkind;
???
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
My build of gcc fails with an error running msgfmt. If I do
/usr/bin/msgfmt --statistics libcpp/po/fr.po -o /dev/null
I get failure with the current gcc (rev 127119) but if I use the file fr.po
from rev 111982 the command works. Does the fix need to happen to fr.po or to
my msgfmt binary? I ha
--- Comment #4 from drow at gcc dot gnu dot org 2007-08-01 16:53 ---
Subject: Bug 32919
Author: drow
Date: Wed Aug 1 16:53:01 2007
New Revision: 127132
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127132
Log:
PR tree-optimization/32919
* tree-ssa-sccvn.c (visi
--- Comment #5 from drow at gcc dot gnu dot org 2007-08-01 16:58 ---
This is fixed now.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #16 from danglin at gcc dot gnu dot org 2007-08-01 16:30
---
A similar error appeared in revision 127096 on hppa-unknown-linux-gnu:
/home/dave/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bits/stl_algo.h: In
fu
nction '_ForwardIterator std::__search_n(_ForwardIterator, _F
--- Comment #6 from kargl at gcc dot gnu dot org 2007-08-01 17:16 ---
(In reply to comment #5)
> I have had a nonexpert look at the patch and I wonder if
>
> + ts.kind = gfc_default_logical_kind;
>
> should not be
>
> + ts.kind = newkind;
>
Yes, I believe you are correct.
--- Comment #17 from danglin at gcc dot gnu dot org 2007-08-01 17:27
---
Looking at the hpux failure, it seems
_ZSt8search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT
1_T2_ is miscompiled.
The problem is probably the same as reported in PR32878.
--
http://
--- Comment #2 from kargl at gcc dot gnu dot org 2007-08-01 17:29 ---
These two examples are the poster child for
1) Why -fdefault-integer-8 is a bad option and should only be
used by people who are prepared to have broken results.
2) Why EQUIVALENCE is a horribly abused construct.
I
--- Comment #9 from pluto at agmk dot net 2007-08-01 17:37 ---
(In reply to comment #7)
> i have tracked down module by module of the kernel
> and after all i found the module which caused the
> kernel crash - its arch/i386/kernel/i8259.c
diffing assembly dumps for these objects shows
--- Comment #7 from tkoenig at alice-dsl dot net 2007-08-01 17:46 ---
Subject: Re: mask and -fdefault-integer-8
On Wed, 2007-08-01 at 15:36 +, dominiq at lps dot ens dot fr wrote:
>
> --- Comment #5 from dominiq at lps dot ens dot fr 2007-08-01 15:36
> ---
> I have had a
Compile this:
extern void f(void);
extern void g(void) __attribute__ ((hot)) __attribute__((cold));
extern void f(void) __attribute__ ((hot));
extern void f(void) __attribute__ ((cold));
I see a warning for the conflicting attributes on 'g', but not
for 'f'. The problem here is that the attribu
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-01 17:55 ---
Subject: Bug 32936
Author: burnus
Date: Wed Aug 1 17:55:24 2007
New Revision: 127135
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127135
Log:
2007-08-01 Tobias Burnus <[EMAIL PROTECTED]>
PR fortr
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-01 18:00 ---
FIXED in GCC 4.3; as it is not regression [and no wrong-code bug either] I will
not backport it to 4.2.x or 4.1.x -> mark as fixed.
Note: GCC gfortran 4.3.0 nightly builds are e.g. available at
http://gcc.gnu.org/wik
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-01 18:39 ---
> Could somebody test the patch below, please?
Build (/= bootstrapped) and check-gfortran'ed (-m64) on x86-64-Linux.
I get an ICE (segmentation fault) for gfortran.dg/derived_comp_array_ref_1.f90:
==26501== Invalid r
I have some code that uses _mm_slli_epi32 intrinsics and some other shift ones.
This code compiles fine in GCC 4.1/4.0 and ICC 9.1.
I tried compiling it with GCC 4.2 and I get the error
testt.c:4: error: shift must be an immediate
_mm_slli_epi32 is defined as:
__m128i _mm_slli_epi32 (__m128i m,
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-08-01 18:49 ---
Even with the correction, the patch didn't pass regression-testing.
It's a good thing we do this.
I'll continue my investigations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
--- Comment #1 from mikelikespie at gmail dot com 2007-08-01 18:50 ---
I forgot to mention, I'm running the latest gentoo with amd64, and gcc (GCC)
4.2.0 (Gentoo 4.2.0 p1.4).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
--- Comment #9 from dominiq at lps dot ens dot fr 2007-08-01 19:05 ---
With the change my tests now compile (regtesting!-), but
gfortran.dg/zero_sized_1.f90 aborts.
BTW I don't understand the error:
Can't convert LOGICAL(8) to LOGICAL(8) at (1)
How can a "no operation" trigger an erro
--- Comment #10 from dominiq at lps dot ens dot fr 2007-08-01 19:08 ---
Sorry it was a "Bus error" and not an abort:
Host Name: pbook
Date/Time: 2007-08-01 20:54:37.875 +0200
OS Version: 10.4.10 (Build 8R218)
Report Version: 4
Command: a.out
Path:a.out
Parent: tcsh [
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-08-01 19:21
---
Created an attachment (id=14003)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14003&action=view)
proposed patch (second try)
This one should be better. Currently regtesting.
--
tkoenig at gcc dot gnu d
--- Comment #11 from dominiq at lps dot ens dot fr 2007-08-01 19:11 ---
The problem is with PACK. If I comment the line
call test_pack
the test pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
--- Comment #10 from axel at freakout dot de 2007-08-01 19:25 ---
Subject: Re: gcc 4.2.0 compiled vanilla kernel
2.4.34.5 crashes when VIA C3 optimized -march=c3
According to pluto at agmk dot net:
> diffing assembly dumps for these objects shows that
> 4.2 output doesn't contain comm
--- Comment #5 from falk at debian dot org 2007-08-01 20:15 ---
Actually, two lines suffice:
template static inline void f() { }
template<> inline void f<5>() { }
This also breaks inkscape.
--
falk at debian dot org changed:
What|Removed
--- Comment #13 from dominiq at lps dot ens dot fr 2007-08-01 20:17 ---
I still have the "Bus error". From the backtrace I think the culprit is
libgfortran/intrinsics/pack_generic.c. Probably around the lines:
pack_internal (gfc_array_char *ret, const gfc_array_char *array,
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-01 20:01 ---
Confirmed with 4.3.0 of today on PPC Darwin8:
original = ( 2.00 , 0.00 ) (
3.00 , 0.00 ) ( 7.00 ,
0.00 ) ( 11.0
--- Comment #1 from wirawan0 at gmail dot com 2007-08-01 20:00 ---
Created an attachment (id=14006)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14006&action=view)
Failing testcase with higher-dimensional b array
I found that the result of conjg(transpose(a)) is also wrong if b i
--- Comment #1 from sje at cup dot hp dot com 2007-08-01 19:54 ---
Created an attachment (id=14005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14005&action=view)
test program that will ICE at -O2
Attached is a Fortran test program that will ICE if compiled at -O2 on IA64.
--
--- Comment #5 from nathan at gcc dot gnu dot org 2007-08-01 19:42 ---
The standard is unclear about exactly why this is ill-defined. Does the
conversion operator take part in overload resolution (and then be rejected, if
it is selected), or is it never entered into the overload set.
I
It turns out that bug #31994
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994) has not been fully
resolved!
I found another testcase that would fail gcc 4.2.1, namely if the destination
of the expression is an allocatable array. Use the following testcase:
program testcase
complex(kind=8), al
I believe this is due to the new floating point division code that I put it in.
I am looking at changing the convert functions in div.md back to UNSPECs and I
believe this will fix the problem. I will attach a test program.
--
Summary: ICE in failed_reload, could not find a spill re
--- Comment #3 from wirawan0 at gmail dot com 2007-08-01 20:02 ---
Created an attachment (id=14007)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14007&action=view)
Magically successful testcase!
And by the way, if BOTH b and a are part of higher-dimensional arrays (see
testcase),
--- Comment #15 from tkoenig at gcc dot gnu dot org 2007-08-01 20:44
---
(In reply to comment #13)
> I still have the "Bus error". From the backtrace I think the culprit is
> libgfortran/intrinsics/pack_generic.c. Probably around the lines:
Hi Dominique,
I just committed a corrected v
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-08-01 20:27
---
Subject: Bug 32954
Author: tkoenig
Date: Wed Aug 1 20:27:27 2007
New Revision: 127137
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127137
Log:
2007-08-01 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #16 from dominiq at lps dot ens dot fr 2007-08-01 21:19 ---
As far as I can tell, I have applied correctly your latest patch. But the
following reduced test
! { dg-do run }
! Transformational functions for zero-sized array and array sections
! Contributed by Francois-Xavier
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-01 21:29 ---
(In reply to comment #5)
> Actually, two lines suffice:
I don't remember if template functions can be static. I really think they
cannot.
Which is one of the reasons why this bug was not marked as confirmed or have
Testcase:
union A
{
float a;
};
float t(float a)
{
union A a1, a2, a3;
a1.a = a;
for(int i =0;i<100;i++)
{
a2 = a1;
a2.a += a;
a1 = a2;
}
a3 = a1;
return a3.a;
}
--
We currently get on powerpc-linux-gnu in the inner loop:
.L2:
stw 0,8(1)
lfs 0,8(1)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-01 23:16 ---
Hmm, the trunk is worse than the 4.2 branch for -msse2 -mfpmath=sse.
Trunk:
.L2:
movss -4(%ebp), %xmm1
addl$1, %eax
cmpl$100, %eax
addss %xmm0, %xmm1
movss %xmm1,
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-01 23:18 ---
One should note the original testcase included a vector float and a struct
inside the union and used C++, this is just a reduced testcase of the issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
--- Comment #1 from daney at gcc dot gnu dot org 2007-08-02 00:38 ---
Still happens in: revision 127079
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32653
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-02 00:37 ---
Created an attachment (id=14008)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14008&action=view)
Patch which needs full testing still
Hi, this reverts Jeff's patch in both stmt.c and cfgexpand.c (I don't know
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-02 00:31 ---
.L4:
slwi 0,3,2
lwzx 0,9,0
add 3,3,4
addi 4,4,-1
bdnz .L4
Much better correct?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #30 from lauras at gcc dot gnu dot org 2007-08-02 01:13 ---
For the record, this was caused by obsolete awk version, please upgrade if you
experience this problem. The need to document awk prerequisite is tracked in
PR 30739.
--
lauras at gcc dot gnu dot org changed:
--- Comment #31 from lauras at gcc dot gnu dot org 2007-08-02 01:14 ---
Closing.
--
lauras at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIR
--- Comment #2 from tromey at gcc dot gnu dot org 2007-08-02 02:17 ---
Yeah -- I looked at the other bugs before filing this one.
The issue here is that the hot/cold code already checks for the conflict;
but we merge without calling the handlers, so the check is never triggered.
I didn't
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-02 02:10 ---
I have filed other bug reports about stuff like this, we currently accept
noinline and alwaysinline which are more conflicting than hot and cold.
--
pinskia at gcc dot gnu dot org changed:
What|Re
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html shows -ftree-dse as an
optimization enabled by -O / -O1, but doesn't document it below.
via http://tinyurl.com/3cdlnu
Per tree-ssa-dce.c:
A dead store is a store into a memory location which will later be
overwritten by another store without
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-08-02 02:57 ---
Subject: Bug 32668
Author: ghazi
Date: Thu Aug 2 02:57:26 2007
New Revision: 127146
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127146
Log:
gcc/cp:
PR middle-end/32668
* call.c (magic_varar
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-02 02:33 ---
Confirmed. This was listed on PR 13756.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
This:
#include
class system { system() {} };
int foo(system* p) {}
gets you:
~/ootbc/systemspec/build$ g++ foo.cc
foo.cc:4: error: 'p' was not declared in this scope
foo.cc:4: error: expected ',' or ';' before '{' token
The problem is that the function int system(...) is in scope so "system
--- Comment #1 from igodard at pacbell dot net 2007-08-02 05:32 ---
Doh! a constructor. Sorry to trouble you.
--
igodard at pacbell dot net changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-08-02 05:42 ---
Confirmed.
Paul, I'm putting you on the CC list because you fixed
PR 31994, the original conjg(transpose()) bug. Maybe
you can do something about this one :-)
Thomas
--
tkoenig at gcc dot gnu dot org changed:
71 matches
Mail list logo
