--- Comment #13 from burnus at gcc dot gnu dot org 2010-04-26 06:11 ---
Kai, what about the GetTempPath? Cf. the rough draft in attachment 20460 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-04-26 07:55 ---
Well, or just use some default name of the unit ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41584
--- Comment #7 from dannysmith at users dot sourceforge dot net 2010-04-26
08:19 ---
This is fixed in 4.5.0 release.
http://gcc.gnu.org/viewcvs?view=revisionrevision=148199
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed
--- Comment #35 from dominiq at lps dot ens dot fr 2010-04-26 08:23 ---
The testsuite completed cleanly, without any failures. Paul, if you agree that
this patch is ok, I can commit it tomorrow.
Confirmed without any problem on my own test.
--
--- Comment #5 from carrot at google dot com 2010-04-26 08:30 ---
Yes, it looks much better for this case. The number of instructions is reduced
from 49 to 39. All problems described have gone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43216
--- Comment #6 from ramana at gcc dot gnu dot org 2010-04-26 08:47 ---
Fixed now.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #36 from janus at gcc dot gnu dot org 2010-04-26 09:08 ---
Subject: Bug 42274
Author: janus
Date: Mon Apr 26 09:07:26 2010
New Revision: 158721
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158721
Log:
2010-04-26 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-26 09:13 ---
Subject: Bug 42425
Author: rguenth
Date: Mon Apr 26 09:13:00 2010
New Revision: 158722
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158722
Log:
2010-04-26 Richard Guenther rguent...@suse.de
PR
--- Comment #6 from dominiq at lps dot ens dot fr 2010-04-26 09:16 ---
This PR is likely due to revision 158639:
Author: bernds
Date: Thu Apr 22 10:42:21 2010 UTC (3 days, 22 hours ago)
Changed paths: 4
Log Message:
* ifcvt.c (dead_or_predicable): Use
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-26 09:17 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-26 09:19 ---
Subject: Bug 43080
Author: rguenth
Date: Mon Apr 26 09:19:24 2010
New Revision: 158723
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158723
Log:
2010-04-26 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-26 09:25 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-26 09:30 ---
possibly caused by the changes for Bug 25811
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fabien dot chene at gmail dot com 2010-04-26 09:58
---
(In reply to comment #1)
possibly caused by the changes for Bug 25811
Confirmed, please assigned me on this regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43890
--- Comment #2 from Denis dot Excoffier at airbus dot com 2010-04-26 09:58
---
I tried this morning to reproduce this bug with GCC 4.4.3 and GCC 4.5.0 and i
didn't succeed (that is: the GCC 4.4.0 bug is gone).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39883
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-26 10:36 ---
(In reply to comment #7)
Subject: Re: [4.4/4.5/4.6 Regression] Performance
degradation for simple fibonacci numbers calculation due to extra
stack alignment
The slowdown also happens on
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.6/4.5 Regression]: mmix- |[4.5/4.6 Regression]: mmix-
|knuth-mmixware gcc.c-
--- Comment #37 from pault at gcc dot gnu dot org 2010-04-26 10:57 ---
I think that we can mark this as closed.
Thanks, first to Salvatore for the report and second to Janus for the fix.
Salvatore, to repeat Janus's request, could you please check that there are no
further
--- Comment #3 from jiez at gcc dot gnu dot org 2010-04-26 10:59 ---
Subject: Bug 43833
Author: jiez
Date: Mon Apr 26 10:59:34 2010
New Revision: 158727
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158727
Log:
PR tree-optimization/43833
* tree-vrp.c
--- Comment #4 from jiez at gcc dot gnu dot org 2010-04-26 11:00 ---
Subject: Bug 43833
Author: jiez
Date: Mon Apr 26 10:59:48 2010
New Revision: 158728
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158728
Log:
PR tree-optimization/43833
* tree-vrp.c
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fabien dot chene at gmail
|dot org
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-26 11:06 ---
I have been trying to reduce more, but this is the smallest so far, seems like
it needs the derived types, the 2D arrays, the pointers. I've reduced this with
4.5.1, using '-O2 -funswitch-loops'
MODULE M1
IMPLICIT
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-26 11:22 ---
Testcase #1 no longer fails on the branch or the trunk.
Testcase #3 is a dup of PR43455, testcase #2 is related.
I'll open a new clarified bug for #2.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #11 from redi at gcc dot gnu dot org 2010-04-26 11:23 ---
This is fixed for equality operators but not relational operators
enum class E { Foo, Bar };
bool b2 = E::Foo E::Bar;
--
redi at gcc dot gnu dot org changed:
What|Removed
For
1.c
--
extern float f(void);
int main(void)
{
return f();
}
2.c
--
int f(void)
{
return 0;
}
we ICE when building with -O2 -fwhopr because we inline f() and the
return value compatibility check does not trigger there (see comment
in fixed PR43455).
When inlining we use a
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-26 11:28 ---
Confirmed. This is a type-merging issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-26 11:32 ---
The problem no longer occurs.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-26 11:42 ---
Confirmed. Huh.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-26 11:59 ---
b) has been fixed on the trunk.
a) is caused by using -fshort-double and LTO streamer interaction with
pre-recorded types and their merging. Testcase:
int main() { return 0; }
gcc-4.5 -o dc empty.c -flto
--- Comment #7 from bernds at codesourcery dot com 2010-04-26 12:11 ---
What happens if you replace the new call to df_simulate_find_noclobber_defs in
ifcvt.c with a call to df_simulate_find_defs? If that fixes the bootstrap, can
you find a testcase where this changes code generation?
--- Comment #8 from dominiq at lps dot ens dot fr 2010-04-26 12:28 ---
What happens if you replace the new call to df_simulate_find_noclobber_defs in
ifcvt.c with a call to df_simulate_find_defs?
Bootstrapping with the change (crossing my finger that I won't have to remove
the
--- Comment #9 from jakub at gcc dot gnu dot org 2010-04-26 12:40 ---
In the leaf_function_p sense it is non-leaf. For the stack alignment it of
course would be possible to change the stack alignment requirements of the
function if it calls itself, doesn't call other functions (nor
--- Comment #7 from hubicka at gcc dot gnu dot org 2010-04-26 12:41 ---
-fwhopr and -flto are intended to be interchangeable at link time. So it does
not matter with what flag you build the .o objects.
The problem was fixed by the clone streaming fix I submitted last week.
Honza
--
--- Comment #9 from bernds at codesourcery dot com 2010-04-26 12:56 ---
One thing that would help would be to build just a stage1 compiler and target
libraries, then run the testsuite. That might give us a smaller testcase to
look at.
--
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-26 13:15 ---
Subject: Re: [4.6 Regression] Bootstrap failure for
powerpc-apple-darwin9: cannot compute suffix of object files
One thing that would help would be to build just a stage1 compiler and target
libraries, then run
--- Comment #11 from bernds at codesourcery dot com 2010-04-26 13:19
---
(In reply to comment #10)
Subject: Re: [4.6 Regression] Bootstrap failure for
powerpc-apple-darwin9: cannot compute suffix of object files
One thing that would help would be to build just a stage1 compiler
PowerPC suboptimal add with carry optimization
Environment:
System: Linux gentoo-jocke 2.6.31-gentoo-r6 #1 SMP PREEMPT Sun Feb 28 22:54:53
CET 2010 i686 Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz GenuineIntel GNU/Linux
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-26 13:39 ---
config/rs6000/rs6000.md would need to add a addmodecc expander and handle
this, then if-conversion can do the rest of the work like it does on i?86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #10 from hjl dot tools at gmail dot com 2010-04-26 13:44
---
(In reply to comment #9)
In the leaf_function_p sense it is non-leaf. For the stack alignment it of
course would be possible to change the stack alignment requirements of the
function if it calls itself,
--- Comment #3 from dje at gcc dot gnu dot org 2010-04-26 13:52 ---
As Jakub mentioned, i386.md implements the addcc named pattern and rs6000.md
does not provide that named pattern yet.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-26 13:57 ---
Tail call needs to consider incoming alignment requirements of the target
function (which is often in other CU). In this case it is not a tail call, but
non-tail recursion (tail-recursion would be handled by
--- Comment #4 from joakim dot tjernlund at transmode dot se 2010-04-26
13:58 ---
Subject: Re: PowerPC suboptimal add with carry optimization
dje at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote on 2010/04/26
15:53:01:
--- Comment #3 from dje at gcc dot gnu dot org
templateuint32_t otherCOLS
MatrixROWS, otherCOLS, T operator* (const MatrixCOLS, otherCOLS, T o)
const throw()
{
MatrixROWS, otherCOLS, T res;
float sum;
uint32_t i, j, k;
116:#pragma omp parallel for private(i,j,k, sum)
117:for (i = 0; i ROWS; ++i)
118:{
for (j
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-26 14:22 ---
Ugh, this is slightly non-trivial. The C++ cloning does not properly clone
DECL_VALUE_EXPR because we do not bother to do this from copy_body_r.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43880
#include iostream
#include map
int main()
{
std::mapint,int dummy;
for(int i=0;i5;i++) dummy[i*2] = (100-i);
#ifdef BUG
for(auto itr=dummy.begin(),int i=0;itr!=dummy.end();++itr,++i)
--- Comment #12 from hubicka at ucw dot cz 2010-04-26 14:27 ---
Subject: Re: [4.4/4.5/4.6 Regression] Performance
degradation for simple fibonacci numbers calculation due to extra
stack alignment
That is true. For tail call, we only need to align outgoing stack to
The attached code produces the subject message, but only with optimization; at
-O0 it works.
-- behaviour --
[sfili...@localhost bug14]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/local/gnudev/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-26 14:33 ---
This isn't self-contained testcase. Please either provide a preprocessed
source, or some small testcase that can be actually compiled. See
http://gcc.gnu.org/bugs.html for details.
templateint N void foo (void)
{
--- Comment #1 from sfilippone at uniroma2 dot it 2010-04-26 14:34 ---
Created an attachment (id=20491)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20491action=view)
test-case
Funny thing: if I change the declaration
type(d_sparse_mat)
into
class(d_sparse_mat)
then it
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-26 14:38 ---
smells like DECL_VALUE_EXPR
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-26 14:43 ---
(In reply to comment #4)
Subject: Re: PowerPC suboptimal add with carry optimization
dje at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote on 2010/04/26
15:53:01:
--- Comment #3 from dje at gcc dot
--- Comment #13 from hjl dot tools at gmail dot com 2010-04-26 14:47
---
(In reply to comment #12)
Subject: Re: [4.4/4.5/4.6 Regression] Performance
degradation for simple fibonacci numbers calculation due to extra
stack alignment
That is true. For tail call, we
--- Comment #8 from mrs at gcc dot gnu dot org 2010-04-26 14:49 ---
One open question for me would be, are 16 bytes of an arbitrary named
section/segment enough? It you carve out a slice, say lto_%d, that leaves just
12 bytes for the `name', if this big enough?
--
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-26 14:56 ---
Note: There is another OOP PR which fails only with optimization: PR41753.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
--- Comment #4 from janus at gcc dot gnu dot org 2010-04-26 15:04 ---
Confirmed.
It seems this fails already with the 4.5 release as well as with current trunk,
which means that it's not specific to the fortran-dev branch.
--
janus at gcc dot gnu dot org changed:
What
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-26 15:13 ---
I don't think this is valid, it's equivalent to
typedef std::mapint,int::iterator Iter;
for (Iter itr = dummy.begin(), int i=0; i5; i++)
which is invalid because you cannot declare two different types in a
--- Comment #2 from e0600347 at student dot tuwien dot ac dot at
2010-04-26 15:17 ---
Created an attachment (id=20492)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20492action=view)
Preprocessed testcase source
Compiled with:
g++ -std=gnu++0x -fopenmp -save-temps -o test
--- Comment #6 from joakim dot tjernlund at transmode dot se 2010-04-26
15:18 ---
Subject: Re: PowerPC suboptimal add with carry optimization
rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote on 2010/04/26
16:43:04:
Will that also address the loop optimization? I don't
--- Comment #3 from e0600347 at student dot tuwien dot ac dot at
2010-04-26 15:22 ---
Exact error message with testcase:
testcase.cpp: In member function MatrixROWS, otherCOLS, T MatrixROWS, COLS,
T::operator*(const MatrixCOLS, otherCOLS, T) const [with unsigned int
otherCOLS = 1u,
--- Comment #5 from sfilippone at uniroma2 dot it 2010-04-26 15:32 ---
(In reply to comment #0)
The attached code produces the subject message, but only with optimization; at
-O0 it works.
-- behaviour --
[sfili...@localhost bug14]$ gfortran -O1 -c bug14.f90
/opt/gfortran/bin/gfortran -c m_rotation_matrix.f03 m_vector.f03
m_vector.f03: In function rotation_matrix_times_vector:
m_vector.f03:382:0: internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:551
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #1 from fmartinez at gmv dot com 2010-04-26 15:35 ---
Created an attachment (id=20493)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20493action=view)
Just a module, with a type and associated methods. Needed by the one causing
the error.
--
--- Comment #2 from fmartinez at gmv dot com 2010-04-26 15:36 ---
Created an attachment (id=20494)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20494action=view)
The file causing the error during compilation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
--- Comment #5 from wilson at gcc dot gnu dot org 2010-04-26 15:46 ---
Created an attachment (id=20495)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20495action=view)
initial patch
This patch fixes gcc.c-torture/compile/920625-1.c, but unfortunately doesn't
fix any of the 3
I noticed this while looking at dependency violations that occur during a gcc
bootstrap. We get two in the libgcc build, both are due to the same problem.
Here is a testcase extracted from libgcc/soft-float/fixunstfti.c.
int
sub (int i)
{
float tmp;
if (i)
__asm__ __volatile__ (frcpa.s0
--- Comment #9 from stevenb dot gcc at gmail dot com 2010-04-26 16:06
---
Subject: Re: Mach-O LTO support needed for darwin
Mach-O section names are too short, but I have solved this with a
separate section with section names in a strings table. This is
similar to the solution from
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-26 16:24 ---
What happens if you replace the new call to df_simulate_find_noclobber_defs
in
ifcvt.c with a call to df_simulate_find_defs?
Bootstrapping with the change (crossing my finger that I won't have to remove
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-26 16:34 ---
as stated above
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from paul dot shaklan at solipsys dot com 2010-04-26 16:56
---
Exactly the same results with libfoo.so is built with fPIC
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-26 17:21 ---
Regression from GCC 4.3, which still had libcall notes.
--- t.s.434 2010-04-26 10:21:18.0 -0700
+++ t.s.442 2010-04-26 10:21:36.0 -0700
@@ -2,6 +2,7 @@
.pred.safe_across_calls
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-26 17:33 ---
Confirmed. The ICE happens with 4.5, trunk and fortran-dev.
Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2010-04-26 17:38 ---
Confirmed with 4.5.0 and 4.6.0.
At least NAG f95 thinks that the current code is invalid; it writes for the
second file:
Error: m_vector.f03, line 394: Reference via operator * to impure
--- Comment #4 from jakub at gcc dot gnu dot org 2010-04-26 17:39 ---
Created an attachment (id=20496)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20496action=view)
gcc46-pr43893.patch
Fix I'm going to test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893
With -flto -g, the following source will bail out with an internal compiler
error:
void bug() {
struct Class {
Class(int a) {}
virtual void f() {}
};
Class a(0);
}
Command line: g++-4.5 -g -flto bug.cxx
Error message:
bug.cxx: In member function 'bug()::Class::f()':
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-04-26 17:50
---
(In reply to comment #11)
This is fixed for equality operators but not relational operators
enum class E { Foo, Bar };
bool b2 = E::Foo E::Bar;
Is that even allowed for normal enums?
--
--- Comment #5 from ve3wwg at gmail dot com 2010-04-26 17:51 ---
I've also encountered this bug today, under 4.3.4:
gnatmake -g -O0 -fno-tree-sra -gnat05 -Wall -gnatwl -gnata -gnatVa -gnatf
-gnatwr z9.adb
gcc -c -g -O0 -fno-tree-sra -gnat05 -Wall -gnatwl -gnata -gnatVa -gnatf -gnatwr
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4e34a377097524f2
gfortran gives a -Wall warning for a variable which is only used via namelists:
character(4) :: nml_string
1
Warning: Unused variable 'nml_string' declared at (1)
For:
I get an ICE in dbxout.c building a cross compiler from i686-pc-mingw32 to
i686-w64-mingw32.
i686-pc-mingw32-gcc -c -g -O2 -D__USE_MINGW_ACCESS -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat
--- Comment #1 from rainer at emrich-ebersheim dot de 2010-04-26 18:27
---
I'm still analyzing, what's going wrong here, it's a strange thing. I tried the
build three times with a parallel make resulting in the above ICE. But can't
reproduce it by compiling dbxout.c on the command
--- Comment #10 from davek at gcc dot gnu dot org 2010-04-26 18:39 ---
(In reply to comment #1)
I don't speak Mach-O, but yes, the approach should work. You'd start by
saying lto_binary_reader=lto-mach-o in config.gcc and adding a new
lto/lto-mach-o.c with the same handful of
--- Comment #14 from hjl dot tools at gmail dot com 2010-04-26 18:54
---
It is caused by revision 131576:
http://gcc.gnu.org/ml/gcc-cvs/2008-01/msg00337.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-04-26 19:05
---
Well in a sense it is unused. Regardless, adding a warning for the truncated
string, the real issue, is straightforward and I will do so.
--
jvdelisle at gcc dot gnu dot org changed:
What
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-26 19:10 ---
(In reply to comment #3)
The ICE happens with 4.5, trunk and fortran-dev.
Actually this is only half-true. With fortran-dev one already gets an ICE on
the first file, which is different from the one reported in
On Linux/ia32, revision 158720 gave
FAIL: gcc.c-torture/compile/pr42196-2.c -O3 -fomit-frame-pointer (internal
compiler error)
FAIL: gcc.c-torture/compile/pr42196-2.c -O3 -fomit-frame-pointer (test for
excess errors)
FAIL: gcc.c-torture/compile/pr42196-2.c -O3 -g (internal compiler error)
--- Comment #6 from janus at gcc dot gnu dot org 2010-04-26 19:33 ---
Here is a reduced test case for the fortran-dev failure, which turns out to be
pretty trivial. All it takes is an array-valued TBP (wonder if we don't have
such a thing in the testsuite already):
module
--- Comment #2 from rainer at emrich-ebersheim dot de 2010-04-26 19:53
---
As it turns out, the ICE only manifests in a parallel build. I tried make -j 8,
my default and make -j 3.
For an ordinary make there is no issue. So, I'm curious how to handle this.
Any thoughts?
Rainer
--
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-26 20:07 ---
Subject: Bug 43893
Author: jakub
Date: Mon Apr 26 20:07:10 2010
New Revision: 158745
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158745
Log:
PR c/43893
* c-omp.c (c_finish_omp_for): Handle
This testcase
int array1[100], array2[100];
long long
sub (int max)
{
int k;
long long total = 0;
for (k = 0; k max; k++)
total += (long long)array1[k] * (long long)array2[k];
return total;
}
Generates a macc instruction with gcc-3.4.5 when compiled with -O2
-march=sr71000
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-26 20:11 ---
Subject: Bug 43893
Author: jakub
Date: Mon Apr 26 20:11:01 2010
New Revision: 158746
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158746
Log:
PR c/43893
* c-omp.c (c_finish_omp_for): Handle
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-26 20:16 ---
(In reply to comment #1)
Well in a sense it is unused.
Well, but only in a sense - in the example a value is assigned to and then
printed ...
Regardless, adding a warning for the truncated
string, the real
--- Comment #7 from mrs at gcc dot gnu dot org 2010-04-26 20:34 ---
Subject: Bug 43715
Author: mrs
Date: Mon Apr 26 20:33:49 2010
New Revision: 158747
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158747
Log:
2010-04-21 Jack Howarth howa...@bromo.med.uc.edu
PR 43715
--- Comment #7 from fmartinez at gmv dot com 2010-04-26 20:34 ---
Actually both ROTATION_MATRIX_TIMES_VECTOR are pure; the one in m_vector is
elemental, therefore pure, and the one in m_rotation_matrix is pure.
I have changed the one in m_rotation_matrix to ROTATION_MATRIX_TIMES_ARRAY
--- Comment #8 from janus at gcc dot gnu dot org 2010-04-26 20:40 ---
Ok, here is a preliminary patch which fixes the fortran-dev problem:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 158741)
--- Comment #8 from mrs at gcc dot gnu dot org 2010-04-26 20:48 ---
Subject: Bug 43715
Author: mrs
Date: Mon Apr 26 20:48:35 2010
New Revision: 158748
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158748
Log:
2010-04-26 Jack Howarth howa...@bromo.med.uc.edu
PR 43715
--- Comment #9 from mrs at gcc dot gnu dot org 2010-04-26 20:55 ---
Trunk fixed, leaving open for 4.5.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
1 - 100 of 136 matches
Mail list logo
