--- Comment #10 from ktietz at gcc dot gnu dot org 2008-12-14 07:50 ---
(In reply to comment #9)
> (In reply to comment #5)
> > Reasoned by the fact, that this patch will solve our build failures for
> > w64, it
> > is really more to be treated as regression.
> >
> > NightStrike, when
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-12-14 07:01
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-12-14 07:00
---
Subject: Bug 38504
Author: jvdelisle
Date: Sun Dec 14 06:58:38 2008
New Revision: 142748
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142748
Log:
2008-12-13 Jerry DeLisle
PR libfortran/3850
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-12-14 06:52
---
Subject: Bug 38504
Author: jvdelisle
Date: Sun Dec 14 06:50:53 2008
New Revision: 142747
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142747
Log:
2008-12-13 Jerry DeLisle
PR libfortran/3850
--- Comment #9 from dannysmith at users dot sourceforge dot net 2008-12-14
05:54 ---
(In reply to comment #5)
> Reasoned by the fact, that this patch will solve our build failures for w64,
> it
> is really more to be treated as regression.
>
> NightStrike, when all tests you are doing
int main(int, char**)
{
char i = 1;
char j = 2;
i ^= j;
i |= j;
i &= j;
return 0;
}
---
g++ -Wconversion main.cpp -o main
---
main.cpp: In function âint main(int, char**)â:
main.cpp
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2008-12-14
00:43 ---
Should really be XFAIL'ing this test on targets that don't use glibc? We have
been seeing...
XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test
XPASS: 21_strings/basic_string/eleme
--- Comment #1 from k dot kosciuszkiewicz+gcc at gmail dot com 2008-12-14
00:10 ---
My mistake, ICALL & IJMP instructions take word (not byte) addresses. Therefore
the generated code is correct.
Sorry for the noise.
--
k dot kosciuszkiewicz+gcc at gmail dot com changed:
--- Comment #8 from nightstrike at gmail dot com 2008-12-14 00:11 ---
To complete this patch, we need to make multilib not be the default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-12-13 23:54
---
Let's try this again. I need verification that I am interpreting the comments
correctly. With this:
! { dg-do compile }
! { dg-options "-std=f2008" }
! PR36725 Compile time error for g0 edit descriptor
write(*,
--- Comment #2 from bernard at brenda-arkle dot me dot uk 2008-12-13 23:53
---
I'm not sure what 'now' means. It's still true for release 4.3.2!
I'm prepared to test with the live sources, but do you want me to?
Do you believe that the problem has been understood and addressed,
or are
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-12-13
23:10 ---
Only the capacita and protein benchmarks are compiled with wrong code at -O2
-fgraphite on i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38520
I'm currently writing a small kernel, and gcc asked me to file a bug report.
I've scrapped the file from anything not directly related to the bug, which
makes it quite small.
I'm aware the assembly syntax is most likely wrong.
Hope this is useful.
Command line :
##
gcc -v -save-temps
--- Comment #7 from nightstrike at gmail dot com 2008-12-13 23:01 ---
Tested and verified on win64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
--- Comment #1 from dominiq at lps dot ens dot fr 2008-12-13 22:46 ---
Apparently fixed without regression at revision 142742. Closing.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--
At revision 142742 some tests in the polyhedron suite are miscompiled with
-O3 and some other graphite options (-fgraphite-identity with/without
-fgraphite: first table, with all possible (?) options: second table,
the third table is given as reference).
I don't know how many of the failures are
--- Comment #5 from rwgk at yahoo dot com 2008-12-13 22:09 ---
The bug is still present in svn revsion 140355 from last night.
I ran an automatic search through the svn history. The result is that
revision 129269 (svn log below) introduced the bug.
Could someone please confirm the bug
Works fine in SVN versions obtained 20081123 and earlier. On SVN version
obtained 20081213:
This is what happens:
../configure --target=avr --prefix=/usr/local/avr --disable-nls
--enable-languages=c --disable-libssp
make (builds for a while and then) --
make[2]: Entering directory
--- Comment #6 from nightstrike at gmail dot com 2008-12-13 21:59 ---
Created an attachment (id=16906)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16906&action=view)
Third attempt
There were a few lines in t-mingw32 that were commented out and shouldn't have
been there. Fixed i
--- Comment #5 from ktietz at gcc dot gnu dot org 2008-12-13 21:46 ---
Reasoned by the fact, that this patch will solve our build failures for w64, it
is really more to be treated as regression.
NightStrike, when all tests you are doing at the moment are passing, I'll sent
it tomorrow t
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-12-13
21:43 ---
Using r142742, '-O1 -fgraphite-identity' now compiles Matrix.c, however '-O2
-fgraphite-identity' still has the compile time errors...
Matrix.c: In function pymol_rg_:
Matrix.c:3059: error: edge from 509
--- Comment #4 from nightstrike at gmail dot com 2008-12-13 21:19 ---
As per jakub, it is space separated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-13 21:19
---
Disregard comment #2, I found the relevant text describing this that I needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38398
--- Comment #7 from leonid at volnitsky dot com 2008-12-13 21:15 ---
Found error cause.
By changing line:
const static unsigned long N = 10;
to
const static unsigned long N = 1;
I was able to compile. I recall that I’ve seen this error in the past
t
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-12-13 21:08
---
Please confirm. Is the output for this correct?
write(*, '(g0.3)') 0.1
write(*, '(g0.9)') 1.0
write(*, '(g0.5)') 29.23
write(*, '(g0.8)') -28.4
write(*, '(g0.8)') -0.0001
write(*, '(a,g10.4,a)') ">",3.45,"<"
wri
--- Comment #6 from leonid at volnitsky dot com 2008-12-13 20:54 ---
I see same error on Gentoo x86_64, with gcc-4.4 and 4.3.2
Project page: http://volnitsky/project/lvvlib
Source: http://github.com/lvv/lvvlib
b-array.ii.gz attached.
---
--- Comment #5 from leonid at volnitsky dot com 2008-12-13 20:46 ---
Created an attachment (id=16905)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16905&action=view)
*.ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21307
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-12-13 19:55 ---
Has this been fixed in the meantime?
Uros, you wrote in
http://gcc.gnu.org/ml/gcc/2008-12/msg00228.html that bootstrap works
on Alpha...
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from spop at gcc dot gnu dot org 2008-12-13 19:54 ---
Fixed commit problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38409
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-13 19:50 ---
On 2.66GHz Cor2 Quad running Fedora 9/x86-64, gcc 4.4 revision 142740 gave:
lake:pts/1[9]> time ./xgcc -B./ -O3 /tmp/bug48.c -S
./xgcc -B./ -O3 /tmp/bug48.c -S 94.39s user 0.98s system 99% cpu 1:35.51 total
lake:pt
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-12-13 19:34
---
Testing this.
Index: write.c
===
--- write.c (revision 142574)
+++ write.c (working copy)
@@ -600,9 +600,16 @@ write_decimal (st_parameter_
--- Comment #11 from ubizjak at gmail dot com 2008-12-13 19:29 ---
(In reply to comment #10)
> FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 4
PR 37364
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34256
--- Comment #2 from hal at oz dot net 2008-12-13 19:01 ---
Can you suggest some way of testing that hypothesis? Or some way of figuring
out why that build broke when the previous one did not break? What changed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38414
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2008-12-13
18:38 ---
On i686-apple-darwin9, I have been using...
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.4-20081213/configure --prefix=/sw
--prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man
--- Comment #83 from schwab at suse dot de 2008-12-13 18:26 ---
*** Bug 38516 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2008-12-13 18:26 ---
*** This bug has been marked as a duplicate of 11751 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #1 from dcb314 at hotmail dot com 2008-12-13 18:18 ---
Created an attachment (id=16904)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16904&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518
I just tried to compile the package fceu-0.98.25-1.7
with the GNU C++ compiler version 4.4 snapshot 20081212.
The compiler appears to get into a long or possibly infinite loop.
I tried compiling with flag -O2 and that took 40 seconds or so.
With flag -O3, compilation did not finish in over seven m
--- Comment #6 from danglin at gcc dot gnu dot org 2008-12-13 17:51 ---
Need to backport change from PR 35665.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38062
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-13
17:47 ---
Subject: Re: FAIL: gfortran.dg/include_2.f90 -O (test
for excess errors): error: stray '#' in program
On Tue, 09 Dec 2008, mikael at gcc dot gnu dot org wrote:
> > Is there a way to capture the
int& i; //ok
--
Summary: At definition of the empty reference the error is not
output.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
host:
/sw/src/fink.build/gcc44-4.3.999-20081213/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20081213/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20081213/gcc-4.4-20081213/gcc/testsuite/gcc.
dg/graphite/pr38409.c -O2 -floop-block -S -m32 -o pr38409.s(timeout =
300)
/sw/src
--- Comment #9 from dfranke at gcc dot gnu dot org 2008-12-13 17:04 ---
Glad it that works now :)
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from marbertone at gmail dot com 2008-12-13 16:59 ---
Thanks for the 'shot in the dark' suggestion: it worked!
Great, man!
;)
Thank you
Mario Alberto
(In reply to comment #7)
> $> gcc --version
> shows the same as gfortran?
> My only data point is, that I have see
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-12-13 16:28
---
I have isolated the problem to gfc_itoa. gfc_itoa returns a string. The number
of digits is determined from the strlen of that string. At -m32, that string
length (digits, see below) is off by one. I instrumente
--- Comment #32 from hjl dot tools at gmail dot com 2008-12-13 15:55
---
(In reply to comment #31)
> Created an attachment (id=16902)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16902&action=view) [edit]
> A patch to add -D_GLIBCXX_DEBUG to dg-options
>
> I am testing this patc
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-12-13 15:42
---
Reduced test case. Fails at -m32
program IntAdtest
integer, parameter :: i8_ = Selected_Int_Kind(18) ! = integer*8
integer(i8_) :: value
value = -9223372036854775807_i8_ -1
write(*, '(i22)') value
end
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-12-13 15:32
---
I have also found on pr38472 some odd behaviour at -m32. That we see this with
an integer output has my concern level up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38504
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-12-13 15:29
---
I am trying not to lose sight of the original problem in comment zero.
However, the decimal output alignment problem fixed in comment 9 still exists
with -m32 on x86-64 and I can see it with 32 bit windows as we
--
calliari at gmail dot com changed:
What|Removed |Added
Severity|normal |major
Known to work||3.3.6
Su
X-Bugzilla-Reason: CC
*** working on gcc version 3.3.6
A swap operation between two integers doesn't works for class members.
i ^= j ^= i ^= j;
after the operation above, "i" will value 0 (zero), if i and j are class
members.
--
Summary: Binary operator ^= doesn't work well for c
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-13 14:29 ---
Both the warning and the temporary creation depend on the same dependency
checking code.
While it makes sense in the case of pointers to assume the worst (and create a
temporary, even if it's actually not needed), a
--- Comment #6 from burnus at gcc dot gnu dot org 2008-12-13 11:19 ---
For completeness, on my x86-64-linux system I get with 4.4.0, 4.3.0 and with
openSUSE binaries (4.1, 4.2, 4.3, 4.4) always a single "-".
Hmm, OK found something: With -m32 I get "--" but with -m64 (default) I get
"-"
--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-13 11:18 ---
(In reply to comment #3)
> Fixed.
>
This still fails here:
gfortran -v -O2 -g -ffree-form -fgraphite -fgraphite-identity -cpp -D__FFTSG
PR38492.f90
gcc version 4.4.0 20081110 (experimental) [graphite revision 142738
--disable-ppl and --without-ppl are accepted, but still ./configure searches
for PPL/CLOOG, finds them and enables them.
Expected: One can build 4.4 also without PPL/CLOOG even if they are installed.
--
Summary: Disabling PPL/CLOOG with configure does not work
Product: gcc
--- Comment #11 from jv244 at cam dot ac dot uk 2008-12-13 08:39 ---
(In reply to comment #10)
> (In reply to comment #9)
> > Unfortunately, '-fgraphite -fgraphite-identity -floop-block
> > -floop-strip-mine
> > -floop-interchang' goes generate an executable, but it is miscompiled and
>
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-13 08:10 ---
User error. If you compile with -fopenmp, you also need to link with -fopenmp,
otherwise -lgomp isn't linked in.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
57 matches
Mail list logo
