--- Comment #7 from dominiq at lps dot ens dot fr 2007-07-31 07:59 ---
> And here is a patch which fixes the ICE:
Confirmed and regtested on PPC Darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32935
Bootstraping is failing for me on i686-pc-linux-gnu. At 23.07.2007
bootstrapping was successfull, but yesterday and today it fails
configure flags:
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++,treelang
--with-mpfr=/usr/local
Here is the error message:
make[5]: Leaving directory
`/data/
I have reduced the failure for intrinsic_rrspacing.f90 to:
integer i
real x
x = 3.0
print *, exponent (x)
i = exponent (x)
print *, i
end
which gives with -fdefault-integer-8
8589934720
2
cat intrinsic_rrspacing_red.f90.003t.original gives:
MAIN__ ()
This test is difficult to reduce further. The ICE disappears if the line
if (.not. associated (ptr, a)) call abort
is commented. Removing .not. in the above line does not change ICE. The test
pass with -m64.
gdb session:
(gdb) run -fdefault-integer-8 char_associated_1_db.f90
The program
Karamursel / KOCAELi - YALOVA arasinda, yalova-izmit otoyoluna 150 metre
mesafede ACELE SATILIK 700 metre kare arsa uzerinde 300 metre kare uzerine
kurulu 4 katli bina.
6 daire, 2 dukkan, catida 2 oda ve teras, deniz ve dag manzarali, otel,
pansiyon, yurt, hastane icin elverisli, depr
Hello,
Kérlek támogass egy rászoruló kislányt. Minden nap ha rákattintasz erre a
linkre 100ft-ott adnak a kislánynak és így megmenthetjük az
életveszélytől.link: http://belepes.puresms.hu
Kérlek kattints teis rá legalább egyszer és lépj be az oldalon. Erre azért van
szükség .h a rensdszer t
--- Comment #21 from victork at il dot ibm dot com 2007-07-31 11:57 ---
Just to be sure that the problem on ppc64 is not related to a problem with
passing -mabi during bootstrap I've tried to build with the patch from
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02159.html
but it didn't
#include
#include
class CString{
public:
CString(){value = NULL;}
CString(char *initValue){
if(initValue != NULL) value = NULL;
else strcpy((value = new char[strlen(initValue)+1]),initValue);
}
~CString(){if(value != NULL) delete [
--- Comment #1 from pcarlini at suse dot de 2007-07-31 12:37 ---
The compiler is right: operator+ returns a *temporary* CString and you have an
assignment operator taking a *non const* reference. Just change the latter to
take a const reference.
--
pcarlini at suse dot de changed:
--- Comment #3 from dominiq at lps dot ens dot fr 2007-07-31 13:01 ---
> A patch for this bug has been added to the patch tracker.
Regtested on PPC Darwin8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32936
--- Comment #1 from schwab at suse dot de 2007-07-31 13:32 ---
The difference is created during the tree-eh pass, when try/finally is lowered.
--
schwab at suse dot de changed:
What|Removed |Added
---
--- Comment #2 from schwab at suse dot de 2007-07-31 14:08 ---
The problem is that the goto queue is sorted by address and the cont_stmt of
the first queue element is used for the final branch out. This makes the used
goto expr dependent on tree addresses.
--
http://gcc.gnu.org/bug
--- Comment #16 from patchapp at dberlin dot org 2007-07-31 14:15 ---
Subject: Bug number PR31609
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-07/msg02177.html
--
http://gcc.gnu.org/bugzilla/s
$> cat ice.f90
MODULE EGOPS_Utilities
CONTAINS
FUNCTION dirname(fullfilename)
Character(LEN=*), Intent(In):: fullfilename
Character(LEN=LEN(fullfilename)) :: dirname
dirname = ''
END FUNCTION
END MODULE EGOPS_Utilities
MODULE AtmoIono
CHARACTER(LEN=10), PARAMETER :: ComputeD
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-31 14:42 ---
Regtesting:
Index: expr.c
===
--- expr.c (revision 127062)
+++ expr.c (working copy)
@@ -693,6 +693,10 @@ static match
check_specification_f
consider the following code:
module mo
contains
subroutine sub(epstab)
implicit none
real epstab(52)
integer i,ib,ib2,ie
do i = 1, ie
ib2 = ib+2
epstab(ib) = epstab(ib2)
ib = ib2
end do
end subroutine sub
end module mo
this fails with an ICE (segm
--- Comment #11 from aph at gcc dot gnu dot org 2007-07-31 15:06 ---
Subject: Bug 32843
Author: aph
Date: Tue Jul 31 15:05:52 2007
New Revision: 127093
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127093
Log:
2007-07-30 Andrew Haley <[EMAIL PROTECTED]>
PR testsuite/
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-31 15:10 ---
I can this reproduce on x86-64-linux (20070731, rev127091), however, only with
the option "-m32"; using "-m64" I don't get a crash and valgrind shows no
problems.
For "-m32 -O1 -fpredic
--- Comment #21 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-31
15:30 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> --- Comment #20 from hjl at lucon dot org 2007-07-30 20:41 ---
> Is this related to PR32921? Can you try the patch in commen
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-31 15:39 ---
Actually this is an user visible regressions as -O3 now ICEs while before it
did not.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from danglin at gcc dot gnu dot org 2007-07-31 15:46 ---
Subject: Bug 32847
Author: danglin
Date: Tue Jul 31 15:46:19 2007
New Revision: 127096
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127096
Log:
PR target/32847
* pa.md (casesi32): Use match
--- Comment #2 from danglin at gcc dot gnu dot org 2007-07-31 16:16 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
When invoking Java methods from C++ code through the CNI, everything works well
for simple method. However, those that contain calls to a DOM factory
instantiator fail. The reason might be that it tries to look for suitable Java
XML libraries and fails to do so (although the example works fine in p
--- Comment #3 from ammonton at cc dot helsinki dot fi 2007-07-31 16:25
---
I checked the last few release tarballs, and neither the 4.2.0 or 4.2.1
packages come with pregenerated installation instructions. The older releases I
checked (back to 4.0.1) had the instructions in the INSTALL
--- Comment #1 from danglin at gcc dot gnu dot org 2007-07-31 16:30 ---
Suggest using HP ld and GNU as. This combination is tested regularly
and known to work.
You don't need to specify CFLAGS. The assembler code generated for
all hppa64 targets is always PA 2.0w.
--
http://gcc.g
I just tried to bootstrap the GNU C compiler version 4.3 snapshot 20070720
with the Intel C compiler.
The Intel compiler said
../../../src/gcc-4.3-20070720/fixincludes/fixincl.c(1049): remark #593:
variable "name_len" was set but never used
../../src/gcc-4.3-20070720/gcc/c-decl.c(4708): remark #
When compiling with -O2
void foo(int N, int k, int di, double x[N])
{
long i;
for (i = 0; k; k--, i += di)
x[i] = 0;
}
GCC produces for x86_64:
.L9:
movq$0, (%rcx)
addq%rax, %rcx
subl$1, %esi
jne .L9
and for ia64:
.L10:
Hi,
the -O1 and -O2 options cause an internal compiler error in my newly compiled
g++ 4.2.1. Omitting this option compiles without any apparent problems and the
ubuntu 06/10 g++, i.e. gcc version 4.1.2 20060928 (prerelease) (Ubuntu
4.1.1-13ubuntu5), also compiles it fine, with and without the -O2
--- Comment #1 from Max dot Moorkamp at gmx dot net 2007-07-31 17:57
---
Created an attachment (id=14000)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14000&action=view)
the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
--- Comment #1 from kargl at gcc dot gnu dot org 2007-07-31 18:04 ---
(In reply to comment #0)
> I have reduced the failure for intrinsic_rrspacing.f90 to:
>
> integer i
> real x
> x = 3.0
> print *, exponent (x)
> i = exponent (x)
> print *, i
> end
>
> which gives with -fdefault-inte
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-31 18:05 ---
This works on the trunk on i386-apple-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-31 18:24 ---
Confirmed, PR 32573 is related (I think they are the same issue really).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pluto at agmk dot net 2007-07-31 18:29 ---
(In reply to comment #13)
> Created an attachment (id=13550)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13550&action=view) [edit]
> An experimental patch
>
> This patch works for the testcase.
i've applied this pa
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-31 18:38 ---
Confirmed, reduced a lot:
int zip_find_end_of_central_dir(void *in, long long *len)
{
char buf[256];
int i = 0;
long long filelen;
long long filepos;
int maxread;
int totalread = 0;
int f
#include
typedef char const* __attribute__((aligned(16))) aligned_byte_buffer;
__m128i load_1( aligned_byte_buffer buf )
{
return *((__m128i*)buf);
}
__m128i load_2( aligned_byte_buffer buf )
{
__m128i m;
__builtin_memcpy( &m, buf, sizeof( m ) );
return m;
}
gcc
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2007-07-31 18:40 ---
Subject: Re: Wrong code with with -fdefault-integer-8
On Tue, Jul 31, 2007 at 06:04:02PM -, kargl at gcc dot gnu dot org wrote:
>
> > I have reduced the failure for intrinsic_rrspacing.f90 to
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-31 18:46 ---
(insn 7 6 8 t.c:15 (set (reg:DI 61)
(mem:DI (reg/v/f:DI 59 [ buf ]) [0 S8 A8])) -1 (nil))
See A8.
So the aligned attribute so not applying where you think it should be.
This is how you get the correct alig
--- Comment #7 from axel at freakout dot de 2007-07-31 18:55 ---
Subject: Re: 03.5: gcc 4.2.0 compiled vanilla
kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
According to pinskia at gcc dot gnu dot org:
> Testcase?
>
i have tracked down module by module of the kernel
and af
--- Comment #3 from dominiq at lps dot ens dot fr 2007-07-31 18:56 ---
Subject: Re: Wrong code with with -fdefault-integer-8
> So, we need to review every unilateral use of gfc_default_integer_kind
> in the frontend to determine if the promotion of 4 to 8 via
> -fdefault-integer-8
> i
convert, @function
convert:
movl%edi, -4(%rsp)
movss -4(%rsp), %xmm0
ret
.size convert, .-convert
.p2align 4,,15
.globl load
.type load, @function
load:
movzwl (%rdi), %eax
ret
.size load, .-load
.ident &quo
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu
2007-07-31 19:37 ---
Subject: Re: Wrong code with with -fdefault-integer-8
On Tue, Jul 31, 2007 at 06:56:33PM -, dominiq at lps dot ens dot fr wrote:
>
> > So, we need to review every unilateral use of gfc_defaul
--- Comment #5 from kargl at gcc dot gnu dot org 2007-07-31 19:39 ---
I have a patch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unas
--- Comment #6 from dominiq at lps dot ens dot fr 2007-07-31 20:21 ---
Subject: Re: Wrong code with with -fdefault-integer-8
> That appears to work.
Confirmed, we have now:
_gfortran_st_write (&dt_parm.1);
{
int8 D.961;
D.961 = (int8) _gfortran_exponent_r4 (x);
--- Comment #7 from dominiq at lps dot ens dot fr 2007-07-31 20:32 ---
Subject: Re: Wrong code with with -fdefault-integer-8
This part of the problem for intrinsic_rrspacing.f90 now works, but there
is another one with rrspacing(x):
program test_rrspacing
real x
x = 3.0
x = rrsp
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-07-31 20:41
---
Minimal reproducer (at -O1, without -fdefault-integer-8):
subroutine r (*)
integer(kind=8) :: i
return i
end
Mismatch type, fixed by:
Index: trans-stmt.c
===
--- Comment #8 from kargl at gcc dot gnu dot org 2007-07-31 20:48 ---
Subject: Bug 32942
Author: kargl
Date: Tue Jul 31 20:48:21 2007
New Revision: 127105
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127105
Log:
2007-07-31 Steven G. Kargl <[EMAIL PROTECTED]>
PR fort
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu
2007-07-31 20:50 ---
Subject: Re: Wrong code with with -fdefault-integer-8
On Tue, Jul 31, 2007 at 08:32:56PM -, dominiq at lps dot ens dot fr wrote:
>
>
> --- Comment #7 from dominiq at lps dot ens dot fr
--- Comment #10 from kargl at gcc dot gnu dot org 2007-07-31 20:51 ---
Fixed on trunk. No back port to 4.2 branch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-07-31 20:54
---
(In reply to comment #0)
> $ gfortran -fdefault-integer-8 nan_6.f90
But there's no integer *at all* in the testcase! How come?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-31 20:58 ---
(In reply to comment #1)
> But there's no integer *at all* in the testcase! How come?
But there is, internally with __builtin_isnan.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-07-31 21:16
---
Subject: Bug 32938
Author: fxcoudert
Date: Tue Jul 31 21:15:45 2007
New Revision: 127106
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127106
Log:
PR fortran/32938
* trans-stmt.c (gfc_tra
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-07-31 21:17
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #3 from kargl at gcc dot gnu dot org 2007-07-31 21:20 ---
The testcase is illegal code because a is never assigned a value.
I also do not see where __builtin_isnan is supposely coming into
play here?
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from fang at csl dot cornell dot edu 2007-07-31 21:32
---
Try compiling with -Woverloaded-virtual (C++ only). That catches the situation
you describe. (I don't think it's enabled by -Wall or -Wextra.)
--
fang at csl dot cornell dot edu changed:
What|
--- Comment #11 from dominiq at lps dot ens dot fr 2007-07-31 21:39 ---
Subject: Re: Wrong code with with -fdefault-integer-8
> The rrspacing problem is something besides -fdefault-integer-8
> because I get the expected results on my system.
Is your system big or little endian? If it
--- Comment #4 from CyrusOmega at gmail dot com 2007-07-31 21:41 ---
Subject: Re: No warning when creating a non const derived function from a
const virtual function
Wow, thanks. I thought that -Wall was ALL warnings. grumble grumble...
Andrew
On 31 Jul 2007 21:32:32 -, fang at c
--- Comment #12 from sgk at troutmask dot apl dot washington dot edu
2007-07-31 21:48 ---
Subject: Re: Wrong code with with -fdefault-integer-8
On Tue, Jul 31, 2007 at 09:39:28PM -, dominiq at lps dot ens dot fr wrote:
>
> > The rrspacing problem is something besides -fdefault-in
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-31 21:49 ---
http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Warning-Options.html
-Wall
All of the above `-W' options combined. This enables all the warnings about
constructions that some users consider questionable, and that are
--- Comment #13 from dominiq at lps dot ens dot fr 2007-07-31 22:04 ---
Subject: Re: Wrong code with with -fdefault-integer-8
> It is an opteron, so little endian.
So rrspacing is another instance of PR32770
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32942
--- Comment #18 from pault at gcc dot gnu dot org 2007-07-31 22:28 ---
Fixed on trunk - this is clearly related to pr31214 so, hey ho, off to work
we go!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #17 from pault at gcc dot gnu dot org 2007-07-31 22:14 ---
Subject: Bug 31609
Author: pault
Date: Tue Jul 31 22:14:29 2007
New Revision: 127108
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127108
Log:
2007-08-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #14 from sgk at troutmask dot apl dot washington dot edu
2007-07-31 22:29 ---
Subject: Re: Wrong code with with -fdefault-integer-8
On Tue, Jul 31, 2007 at 10:04:55PM -, dominiq at lps dot ens dot fr wrote:
>
> > It is an opteron, so little endian.
>
> So rrspacing i
The f77 compiler seems to have a BUG what makes - for me - it impossible to
use seriously
I have a lot of very big old f77 progs, what I want to revise, and put open.
f77 DONT PRODUCE A COMPILING LIST FILE, i.e. listing the source-code with line
number and errors/warnings after each line
--- Comment #2 from Dallas at ekkySoftware dot com 2007-08-01 00:14 ---
The reason I was passing the reference and not the value is because is some
circumstances I can change the value of the parameter. Using the const keyword
prevents me from calling methods that can change the value
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-01 00:24 ---
You need to change the operator= to:
CString& operator=(const CString& newValue){
Otherwise you cannot bind a rvalue to the reference as it will only bind to a
lvalue and returned from operator+ is a rvalue.
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-01 00:25 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #11 from stevenj at alum dot mit dot edu 2007-08-01 01:01
---
Given that there seems to be no progress, or even any prospect of progress, on
Roger's "un-CSE" suggestion, isn't there a simpler fix?
The basic issue here seems to be the abovementioned 2004-02-07 patch identifi
all
Thread model: posix
gcc version 4.3.0 20070731 (experimental)
[test]$ gcc-svn -std=gnu99 -Wformat=2 bar.c
bar.c: In function 'main':
bar.c:6: warning: zero-length printf format string
The format string is not zero-length, it's unterminated. The fix is simple.
I've got a pat
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-08-01 05:52 ---
Created an attachment (id=14002)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14002&action=view)
proposed patch
This should fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
This bug is for the mask issues with -fdefault-integer-8,
which cause (among others) the failures in minmaxloc etc.
--
Summary: mask and -fdefault-integer-8
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Sever
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-08-01 06:00 ---
Setting to "enhancement", as we now detect the error
at runtime.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
72 matches
Mail list logo
