--- Comment #1 from domob at gcc dot gnu dot org 2008-11-15 08:30 ---
I'll take this one on. Reading quickly through the thread gives me the
impression that it is not 100% agreed upon that this should in every case be an
error (although of course nearly so). But I guess we want to
Execution testcases c-torture/execute/920929-1.c and
c-torture/execute/built-in-setjmp.c began failing on mingw32 in late August,
coincident with merge of IRA into trunk.
In both cases, the execution tests pass if -fno-ira is added to command line.
The problem appears to be in the call of the
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-15 09:42
---
To be clear, absolutely nothing changed lately in this area of the library.
Probably, it's just the well known brittleness of these ext/pb_ds testcases, or
a compiler issue.
--
--- Comment #14 from andris dot pavenis at iki dot fi 2008-11-15 09:53
---
Created an attachment (id=16681)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16681action=view)
Another C++ example to ilustrate misleading error message about missing
typename keyword
This is a short
--- Comment #8 from jakub at gcc dot gnu dot org 2008-11-15 09:54 ---
Subject: Bug 37561
Author: jakub
Date: Sat Nov 15 09:53:02 2008
New Revision: 141881
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141881
Log:
PR c++/37561
* c-typeck.c (build_unary_op): Don't
--- Comment #9 from jakub at gcc dot gnu dot org 2008-11-15 09:57 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #12 from burnus at gcc dot gnu dot org 2008-11-15 10:33 ---
(In reply to comment #11)
I tried to reduce the case.
This is probably unrelated to the original ICE though.
Looks unrelated, but still should be fixed; I think ICE from comment 8 is a
regression with
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-15 10:42 ---
It's not a bug in my program. It's a bug in NONMEM VI. That is, assuming that
/dev/tty and /dev/null are files, which they're not. They're devices.
Regardless, it's code that runs in an older version that doesn't
--- Comment #19 from ubizjak at gmail dot com 2008-11-15 10:59 ---
(In reply to comment #17)
Current gcc trunk, r141877, still fails...
Please read Comment #13 why.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
--- Comment #5 from guerby at gcc dot gnu dot org 2008-11-15 11:24 ---
Subject: Bug 37993
Author: guerby
Date: Sat Nov 15 11:22:42 2008
New Revision: 141882
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141882
Log:
2008-11-15 Laurent Guerby [EMAIL PROTECTED]
PR
--- Comment #6 from laurent at guerby dot net 2008-11-15 11:57 ---
Fixed.
--
laurent at guerby dot net changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01191.html
FAIL: cc70a01
FAIL: cxa4016
,.,. CC70A01 ACATS 2.5 08-11-14 15:14:56
CC70A01 Check that the visible part of a generic formal package
includes the first list of basic declarative items of
the
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37955
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38051
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38123
basic_string.tcc contains 'extern template basic_stringchar', which prevents
the template from being instantiated, and thus all calls to basic_string
methods remain calls even at -O3.
If I -D_GLIBCXX_DEBUG=1 _GLIBCXX_EXTERN_TEMPLATE is 0, thus it will no longer
contain 'extern template
--- Comment #1 from edwintorok at gmail dot com 2008-11-15 13:56 ---
Created an attachment (id=16682)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16682action=view)
example to illustrate
compile with g++ -O3, I get:
real0m0.130s
user0m0.100s
sys 0m0.028s
compile with
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-11-15 14:58
---
Well I managed to read that thread about 90% through without falling to sleep.
One point made there is that gfortran should not reposition the file after a
reopen as the default position= specifier should be
--- Comment #27 from pault at gcc dot gnu dot org 2008-11-15 15:20 ---
As far as I can see, all the valid testcases work on trunk and 4.3 - should we
close this one?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-11-15 15:39 ---
Subject: Bug 38051
Author: rguenth
Date: Sat Nov 15 15:37:57 2008
New Revision: 141887
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141887
Log:
2008-11-15 Richard Guenther [EMAIL PROTECTED]
PR
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-11-15 15:42
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2008-11-15 15:53 ---
Created an attachment (id=16683)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16683action=view)
A fix for the PR
Bootstraps and regtests on FC9/x86_i64
Paul
2008-11-15 Paul Thomas [EMAIL PROTECTED]
Hello,
I have a problem by compiling gcc 4.3.2.
If I use the package with all, I get the message: xgcc: Internal error: Killed
(program cc1plus)
If I use only the core-package, I get the massage: xgcc: Internal error: Killed
(program cc1).
What can I do???
Infomation:
gcc -v:
Using built-in
the attached program, a simdfied version of the tanf function, shows a 20%
performance regression from gcc-4.3 to gcc-4.4:
the compared compilers are
g++-4.3
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--- Comment #1 from tim at klingt dot org 2008-11-15 15:55 ---
Created an attachment (id=16684)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16684action=view)
compressed preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
I expect that the following program prints:
122
212
221
1000
which works with g95 and ifort, but with gfortran one gets:
11*
7211
* 721
1000
The program is a minutely modified version of the
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2008-11-15
16:01 ---
Okay. The following change allows all of the struct-layout-1 tests in gcc.dg
under i686-apple-darwin9 with current gcc trunk...
Index: gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2008-11-15
16:05 ---
Argh. My mistake. The patch should be (without typo)...
Index: gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
===
---
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-15 16:10 ---
Using
A(1:N,1:N)=reshape(A(1:0,1),(/N,N/),reshape((/1/),(/N+1/),(/2/)))
the program is a Fortran 95 program, which also works with NAG f95 and openf95.
- Blocking 32834
--
burnus at gcc dot gnu dot org changed:
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2008-11-15
16:16 ---
Revised patch submitted to gcc-patches...
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00714.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2008-11-15 16:16
---
Subject: Bug 34289
Author: ebotcazou
Date: Sat Nov 15 16:15:00 2008
New Revision: 141888
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141888
Log:
PR ada/34289
* lib.ads:
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
--- Comment #4 from jakub at gcc dot gnu dot org 2008-11-15 16:41 ---
Subject: Bug 38123
Author: jakub
Date: Sat Nov 15 16:40:24 2008
New Revision: 141889
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141889
Log:
PR target/38123
* config/i386/i386.c
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-15 16:43 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from ubizjak at gmail dot com 2008-11-15 16:46 ---
Can you try with -fno-ira?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
--- Comment #3 from tim at klingt dot org 2008-11-15 17:04 ---
i tried to run the benchmark with -fno-ira, which turned out to be about 20%
slower than without the flag.
anyway, i found, that the preprocessed source generated by gcc-4.3 cannot be
compiled with gcc-4.4 ... the specific
--- Comment #47 from howarth at nitro dot med dot uc dot edu 2008-11-15
17:15 ---
The execution failure of eh-alloca-1.C appears to only occur at -m32 with -O3
-g. At -m64 with -O3 -g, the resulting binary passes the test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
--- Comment #48 from howarth at nitro dot med dot uc dot edu 2008-11-15
17:17 ---
Created an attachment (id=16685)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16685action=view)
assembly file for g++.dg/torture/stackalign/eh-alloca-1.C at -m32 -O3 -g
--
--- Comment #49 from howarth at nitro dot med dot uc dot edu 2008-11-15
17:18 ---
Created an attachment (id=16686)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16686action=view)
assembly file for g++.dg/torture/stackalign/eh-alloca-1.C at -m32 -O3
--
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-11-15 17:19 ---
$ cat foo.f90
integer, parameter :: N = 3
integer A(N,N)
A(1:N,1:N)=reshape(A(1:0,1),(/N,N/),reshape((/1/),(/N+1/),(/2/)))
write(*,'(3i5)') A
write(*,'(4i5)') reshape([1],[N+1],[0])
end
$ gfortran -fbounds-check
--- Comment #50 from howarth at nitro dot med dot uc dot edu 2008-11-15
17:19 ---
Created an attachment (id=16687)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16687action=view)
assembly file for g++.dg/torture/stackalign/eh-alloca-1.C at -m64-O3 -g
--
--- Comment #51 from howarth at nitro dot med dot uc dot edu 2008-11-15
17:20 ---
Created an attachment (id=16688)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16688action=view)
assembly file for g++.dg/torture/stackalign/eh-alloca-1.C at -m64-O3
--
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-15
17:23 ---
Subject: Re: FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
To be clear, absolutely nothing changed lately in this area of the library.
Probably, it's just the well known brittleness of
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-15 17:27 ---
Subject: Bug 37926
Author: pault
Date: Sat Nov 15 17:26:13 2008
New Revision: 141890
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141890
Log:
2008-11-15 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from kargl at gcc dot gnu dot org 2008-11-15 17:28 ---
(In reply to comment #5)
I do believe that one could write a standard conforming layer in Fortran to
handle all of the OPs issues. Obviously one would have to get creative to do
it.
Which OP? The originator of
--- Comment #13 from pault at gcc dot gnu dot org 2008-11-15 17:40 ---
(In reply to comment #12)
I filled PR38119 for that PR.
This is probably stupid but what is the difference between the two PRs?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
Vim (at least current version vim-7.2.40) crashes on start up when compiled
with optimization option -O3 using gcc-4.3.2 (that's the default version that
comes with Ubuntu-8.10). Vim works fine when compiled with -O0, -O1 or -O2.
Narrowing it down further, compilation options -O2
--- Comment #14 from burnus at gcc dot gnu dot org 2008-11-15 18:06 ---
(In reply to comment #13)
I filled PR38119 for that PR.
This is probably stupid but what is the difference between the two PRs?
The program of comment 0 of this PR (PR 38095) gives an ICE with all gfortran
Follow up to PR 33455.
13.7.75 MERGE (TSOURCE, FSOURCE, MASK)
FSOURCE shall be of the same type and type parameters as TSOURCE.
In the following program, the string length is different. If the string length
were known at compile time, an error would have been printed, but there is no
run-time
--- Comment #28 from burnus at gcc dot gnu dot org 2008-11-15 18:41 ---
I think this PR can be closed - the ICEs are gone, the TODO item is gone and
the missing warnings are tracked in PR 33037.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
Sent from my iPhone
On Nov 15, 2008, at 10:05 AM, dominique dot pelle at gmail dot com [EMAIL PROTECTED]
wrote:
Vim (at least current version vim-7.2.40) crashes on start up when
compiled
with optimization option -O3 using gcc-4.3.2 (that's the default
version that
comes with
--- Comment #1 from pinskia at gmail dot com 2008-11-15 18:43 ---
Subject: Re: New: vim crashes on startup when compiled with -O3 but works
with -O2
Sent from my iPhone
On Nov 15, 2008, at 10:05 AM, dominique dot pelle at gmail dot com
[EMAIL PROTECTED]
wrote:
Vim (at least
--- Comment #7 from jvdelisle at verizon dot net 2008-11-15 19:13 ---
Subject: Re: file already opened in another unit error
when opening /dev/null or /dev/tty twice
Which OP? The originator of the c.l.f thread or the originator of
this bug report.
Originator of this bug report.
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-11-15 19:27
---
Subject: Bug 37294
Author: jvdelisle
Date: Sat Nov 15 19:25:35 2008
New Revision: 141892
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141892
Log:
2008-11-15 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #3 from eric dot weddington at atmel dot com 2008-11-15 19:30
---
Seems to be fixed now on HEAD. Closing bug.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-11-15 19:34
---
Subject: Bug 37294
Author: jvdelisle
Date: Sat Nov 15 19:33:07 2008
New Revision: 141893
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141893
Log:
2008-11-15 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-11-15 19:39
---
Fixed on trunk. I will open a new PR for enhancement of this to better utilize
the internal unit array by doing fewer newlines for namelists.
--
jvdelisle at gcc dot gnu dot org changed:
What
On Linux/Intel64, revision 141890 caused:
Executing on host:
/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../gfortran
-B/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/proc_decl_18.f90
-O3 -g
--- Comment #2 from ghazi at gcc dot gnu dot org 2008-11-15 20:28 ---
*** This bug has been marked as a duplicate of 37517 ***
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ghazi at gcc dot gnu dot org 2008-11-15 20:28 ---
*** Bug 36714 has been marked as a duplicate of this bug. ***
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-15 20:29 ---
You are running out of memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38133
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||x86_64-*-*-*
Keywords|
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-15 20:33 ---
Indeed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-15 20:40 ---
Note that ...
struct dictitem_S
{
typval_Tdi_tv; /* type and value of the variable */
char_u di_flags; /* flags (only used for variable) */
char_u di_key[1]; /* key
--- Comment #7 from rsandifo at gcc dot gnu dot org 2008-11-15 20:42
---
I'll try to look at this tomorrow. The code in comment #1 is certainly wrong:
the store at output_translate_vect_name+8 is supposed come after the GP addiu
at output_translate_vect_name+20. With that fixed, the
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-11-15 20:45
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from paulf at free dot fr 2008-11-15 20:51 ---
I do not agree that this is a duplicate of 6614. 6614 is a consequence of
integer promotion, and there is no possible user code change that would make it
go away (other than avoiding integral types smaller than int in
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-11-15 20:51
---
As far as I can tell, ASIS is working correctly with gfortran 4.4 and 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38122
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-15 20:56 ---
No crash or similar on my x86-64-linux, but valgrind shows:
==32084== Invalid read of size 1
==32084==at 0x4824B0: gfc_commit_symbols (symbol.c:2824)
==32084==by 0x45D94C: accept_statement (parse.c:1503)
--- Comment #4 from dominique dot pelle at gmail dot com 2008-11-15 21:21
---
I tried the suggestion of Richard Guenther in his previous comments. That is
changing vim's code as follows:
cvs diff: CVS password file /home/pel/.cvspass does not exist - creating a new
file
Index: eval.c
++ --enable-checking=all
Thread model: posix
gcc version 4.4.0 20081115 (experimental) [trunk revision 141891] (GCC)
xgcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [insn-emit.o] Error 1
make[3]: *** Waiting
I just tried to compile Suse Linux package opensc-0.11.6-4.5
with the GNU gcc version 4.4.0 snapshot 20081114
It said
asn1.c: In function 'asn1_decode':
asn1.c:1148: internal compiler error: in gimple_call_return_type, at
gimple.h:1993
Please submit a full bug report,
with preprocessed source if
--- Comment #1 from dcb314 at hotmail dot com 2008-11-15 21:37 ---
Created an attachment (id=16689)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16689action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38140
--
edwintorok at gmail dot com changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-15 21:40 ---
The argument boils down to 6.5.6/8 which restricts pointer arithmetic on
objects
and 6.7.2.1/2 which forbids structures with an incomplete array at the end to
be a member of a structure or element of an array.
4.4.0 20081115 (experimental) [trunk revision 141891]
(GCC)
xgcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [insn-emit.o] Error 1
make[3]: *** Waiting for unfinished jobs
xgcc: Internal error: Killed
--disable-multilib --disable-static
--prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ --enable-
checking=all
Thread model: posix
gcc version 4.4.0 20081115 (experimental) [trunk revision 141891]
(GCC)
xgcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to fail|
--- Comment #2 from edwintorok at gmail dot com 2008-11-15 21:59 ---
(In reply to comment #1)
Subject: Re: New: --enable-checking=all times out during bootstrap
Sent from my iPhone
On Nov 15, 2008, at 1:27 PM, edwintorok at gmail dot com
[EMAIL PROTECTED]
wrote:
I
Sent from my iPhone
On Nov 15, 2008, at 1:59 PM, edwintorok at gmail dot com [EMAIL PROTECTED]
wrote:
--- Comment #2 from edwintorok at gmail dot com 2008-11-15
21:59 ---
(In reply to comment #1)
Subject: Re: New: --enable-checking=all times out during bootstrap
Sent
--- Comment #3 from pinskia at gmail dot com 2008-11-15 22:15 ---
Subject: Re: --enable-checking=all times out during bootstrap
Sent from my iPhone
On Nov 15, 2008, at 1:59 PM, edwintorok at gmail dot com
[EMAIL PROTECTED]
wrote:
--- Comment #2 from edwintorok at gmail
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2008-11-15
22:48 ---
Results with revised patch posted at
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01311.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-15 22:59 ---
BTW, you are likely using -D_FORTIFY_SOURCE=2 and that, unlike
-D_FORTIFY_SOURCE=1 has some extra restrictions beyond the C standard.
One is that the str*/stp* functions must not cross field boundary in
structures.
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-15 23:16 ---
The source is buggy,
*(void **)(callback_func) = parm;
violates strict aliasing (with absolutely no reason, callback_func = parm;
would work perfectly).
That said, gcc shouldn't ICE on such code anyway.
--
jakub
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2008-11-15
23:59 ---
This test case fails at -m64 on i686-apple-darwin9 in current gcc trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-11-16
00:01 ---
Created an attachment (id=16690)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16690action=view)
assembly file generated for gcc.target/i386/pr32661-1.c at -m64 on
i686-apple-darwin9
--
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2008-11-16
00:01 ---
Test fails as...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081115/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20081115/darwin_objdi
r/gcc/
/sw/src/fink.build/gcc44-4.3.999
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-16 00:06 ---
(In reply to comment #3)
i tried to run the benchmark with -fno-ira, which turned out to be about 20%
slower than without the flag.
Can you try -O3 -march=core2 -mtune=generic and -O3 -march=core2
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-11-16
00:07 ---
The gcc.target/i386/pr34256.c test case fails on i686-apple-darwin9 at -m64 as
follows...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081115/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44
--- Comment #5 from hjl dot tools at gmail dot com 2008-11-16 00:08 ---
(In reply to comment #3)
anyway, i found, that the preprocessed source generated by gcc-4.3 cannot be
compiled with gcc-4.4 ... the specific file can be found here
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-11-16
00:09 ---
Created an attachment (id=16691)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16691action=view)
assembly file generated for gcc.target/i386/pr34256.c at -m64 on
i686-apple-darwin9
--
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-11-16
00:13 ---
The gcc.target/i386/pr22076.c test case fails for i686-apple-darwin9 at -m64 as
follows...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081115/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2008-11-16
00:14 ---
Created an attachment (id=16692)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16692action=view)
assembly file generated for gcc.target/i386/pr22076.c at -m64 on
i686-apple-darwin9
--
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-16 00:17 ---
It is a bug in libstdc++.
*** This bug has been marked as a duplicate of 37144 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2008-11-16 00:17 ---
*** Bug 38128 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-11-16
00:17 ---
The gcc.target/i386/pr36246.c test case fails on i686-apple-darwin9 at -m64
as...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081115/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-11-16
00:18 ---
Created an attachment (id=16693)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16693action=view)
assembly file generated for gcc.target/i386/pr36246.c at -m64 on
i686-apple-darwin9
--
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-11-16 02:42
---
*** Bug 38116 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6614
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-11-16 02:42 ---
Except assert is controlled by your libc and not GCC so this is still really PR
6614. Also 4.3 changed the definition of -Wconversion so it does not matter
any more.
*** This bug has been marked as a duplicate of
1 - 100 of 112 matches
Mail list logo
