I've finished my set of patches which fix -Wc++-compat to check for enum
conversions which are valid in C++. Adding those checks forced a lot of
changes in mainline to compile cleanly with -Wc++-compat. I have merged
those changes over to the gcc-in-cxx branch. In the gcc directory
itself,
On Wed, Apr 29, 2009 at 9:39 AM, Ian Lance Taylor i...@google.com wrote:
I've finished my set of patches which fix -Wc++-compat to check for enum
conversions which are valid in C++. Adding those checks forced a lot of
changes in mainline to compile cleanly with -Wc++-compat. I have merged
On Tue, 2009-04-28 at 14:52 -0700, Doug Kwan (關振德) wrote:
I would like to run the testsuite using qemu as the gdb simulator does
not support newer ARMs. However, there does not seems to be any good
documents on that topic. Could someone give me a pointer or two?
At least on a linux system,
HI there. I'm working on porting gcc to a new architecture which only
does indirect addressing - there is no indirect with displacement.
The problem is with spill locations in GCC 4.4.0. The elimination
code correctly elimates the frame and args pointer and replaces it
with register X. The
In order to be able to use namespaces in my endeavour to
support gcc with multiple targets, I've first done a merge
from the gcc-in-cxx branch.
For my initial implementation, I choose as configuration
--target=m32r-elf --with-extra-target-list='sh64-elf arc-elf32' .
I've found some issues with
On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
* The C++ frontend warns about while (true); when there is no
whitespace between the ')' and the ';'. The C frontend does not. I'm
not sure how to best handle this. It doesn't make much sense to warn
about this with -Wc++-compat. Should
On Wed, 29 Apr 2009, Joern Rennecke wrote:
What are your thoughts on using gcc extensions for gcc-in-cxx ?
I believe we agreed in a previous discussion to aim for building with the
intersection of C++98/C++03 and C++ as supported by GCC 3.4 (including
making sure at an appropriate point that
Quoting Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Joern Rennecke wrote:
What are your thoughts on using gcc extensions for gcc-in-cxx ?
I believe we agreed in a previous discussion to aim for building with the
intersection of C++98/C++03 and C++ as supported by GCC 3.4
2009/4/29 Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
* The C++ frontend warns about while (true); when there is no
whitespace between the ')' and the ';'. The C frontend does not. I'm
not sure how to best handle this. It doesn't make much
On Wed, 29 Apr 2009, Joern Rennecke wrote:
Quoting Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Joern Rennecke wrote:
What are your thoughts on using gcc extensions for gcc-in-cxx ?
I believe we agreed in a previous discussion to aim for building with the
On Wed, 2009-04-29 at 13:21 +, Joseph S. Myers wrote:
On Wed, 29 Apr 2009, Joern Rennecke wrote:
Quoting Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Joern Rennecke wrote:
What are your thoughts on using gcc extensions for gcc-in-cxx ?
I believe we
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
2009/4/29 Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
* The C++ frontend warns about while (true); when there is no
whitespace between the ')' and the ';'. The C frontend does not. I'm
not
On Wed, 29 Apr 2009, Richard Earnshaw wrote:
The question is not just one for bootstrapping a native compiler but also
one of what compiler can be used to build a cross compiler (such as that
with multiple targets), which is not bootstrapped in the usual GCC sense.
There we presently
2009/4/29 Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
I don't know the rationale for this warning. Is it to do with the C++0x
specification that certain loops may be assumed to terminate?
I guess the rationale is that there is little use for
Joseph S. Myers wrote:
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
2009/4/29 Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
* The C++ frontend warns about while (true); when there is no
whitespace between the ')' and the ';'.
2009/4/29 Sebastian Redl sebastian.r...@getdesigned.at:
So MSC will warn about this construct, but GCC will not, due to its
whitespace rule:
I think we should just remove the whitespace rule and implement the
warning in C.
Cheers,
Manuel.
Richard Guenther richard.guent...@gmail.com writes:
* The C++ frontend emits some warnings on code which is known to be
never executed, which the C frontend does not. This leads to some
warnings compiling code in gcc. I think it is reasonable to fix this
in the C++ frontend.
Or just
Joern Rennecke amyl...@spamcop.net writes:
I've found some issues with gcc-in-cxx both specific to these
targets, and specific to (parts of) compiler passes that are
only compiled for a subset of all tagets, which include one or
more of the above mentioned three.
I'd be happy to see and
Attached is a shortened test report with the following lines removed:
excellent, now we have a benchmark/comparison to look at. Well done,
excellent work.
What did you use to build libgmp and mpfr ? I am curious because most
people that try wwith Sun Studio Express or Sun Studio 12 fail
Michael Hope micha...@juju.net.nz writes:
HI there. I'm working on porting gcc to a new architecture which only
does indirect addressing - there is no indirect with displacement.
The problem is with spill locations in GCC 4.4.0. The elimination
code correctly elimates the frame and args
Manuel López-Ibáñez lopeziba...@gmail.com writes:
2009/4/29 Sebastian Redl sebastian.r...@getdesigned.at:
So MSC will warn about this construct, but GCC will not, due to its
whitespace rule:
I think we should just remove the whitespace rule and implement the
warning in C.
Actually it
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
BTW, why is this warned about?
I imagine because in C it is not conventional to use extern when
defining something, only on a declaration that is not a definition.
But may it lead to some confusion or subtle error? It seems overly
On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
(I'm not personally convinced that a multi-targeted gcc is particularly
useful, though I don't object if there is a general desire to support
it.)
I think the cleanups involved in using the target vector / class more, and
other cleanups involved
2009/4/29 Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
BTW, why is this warned about?
I imagine because in C it is not conventional to use extern when
defining something, only on a declaration that is not a definition.
But may it lead to some
On Wed, Apr 29, 2009 at 9:29 AM, Dennis Clarke dcla...@blastwave.org wrote:
Attached is a shortened test report with the following lines removed:
excellent, now we have a benchmark/comparison to look at. Well done,
excellent work.
What did you use to build libgmp and mpfr ? I am curious
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
2009/4/29 Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
BTW, why is this warned about?
I imagine because in C it is not conventional to use extern when
defining something, only on a
2009/4/29 Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
2009/4/29 Joseph S. Myers jos...@codesourcery.com:
On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
BTW, why is this warned about?
I imagine because in C it is not conventional to use
On Wed, 29 Apr 2009, Joseph S. Myers wrote:
On Wed, 29 Apr 2009, Richard Earnshaw wrote:
If you are building a non-C front end without bootstrapping you need at
least 2.95:
To build all languages in a cross-compiler or other configuration where
3-stage bootstrap is not performed,
Quoting Ian Lance Taylor i...@google.com:
I'm not sure why you are singling me out.
You seemed to be actively working on the branch, and the c++ enum type
checks provide a motivation to make changes. Also, this issue should
be considered in general when people change their coding habits in
Quoting Joseph S. Myers jos...@codesourcery.com:
I think the cleanups involved in using the target vector / class more, and
other cleanups involved in the natural approach to multi-target GCC of
which the target vector is a part, are more useful than the end result
(for which compiling large
On Wednesday 29 April 2009 12:47:04 Joern Rennecke wrote:
Something which I miss in C++ is a way to declare that a function uses
an integral type to pass an enum value (in arguments or return value),
and then at function definition time only check that the integral type
is sufficently large to
Hi,
this program SEGFAULTs
#include algorithm
int main() {
int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
const std::size_t nn = sizeof(numbers)/sizeof(int);
int sum = 0;
int f = 5;
std::for_each(numbers[0], numbers[nn], [] (int n) {
sum += n * f;
});
}
Now, my assembly
I have updated
http://gcc.gnu.org/wiki/SvnBranch
with information on how to use svn 1.5.0 to maintain branches.
Please review, comment, edit etc. - especially in the places marked
untested :)
Thanks,
--
Laurynas
Hi gcc developers, hi graphities
here are some notes from our weekly phone call. Unfortunately I missed
to send out the notes from the last two phone calls, but I hope to get
them out more regulary. Believe in me! ;-)
http://gcc.gnu.org/wiki/Graphite_Phone_Call/2009_04_29
Attendees: Li, Jan,
On Wed, Apr 29, 2009 at 11:34 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
Hi gcc developers, hi graphities
here are some notes from our weekly phone call. Unfortunately I missed
to send out the notes from the last two phone calls, but I hope to get
them out more regulary. Believe in
On Wed, 2009-04-29 at 23:57 +0200, Richard Guenther wrote:
On Wed, Apr 29, 2009 at 11:34 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
Hi gcc developers, hi graphities
here are some notes from our weekly phone call. Unfortunately I missed
to send out the notes from the last two
On Wed, Apr 29, 2009 at 16:57, Richard Guenther
richard.guent...@gmail.com wrote:
* Reductions: Diego OK with going out of SSA.
You will loose all points-to information. I think going out of SSA is
a very bad idea.
There is no loss of information: we go out of SSA only for scalar phi
On Thu, Apr 30, 2009 at 12:06 AM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
On Wed, 2009-04-29 at 23:57 +0200, Richard Guenther wrote:
On Wed, Apr 29, 2009 at 11:34 PM, Tobias Grosser
gros...@fim.uni-passau.de wrote:
Hi gcc developers, hi graphities
here are some notes from our
On Thu, Apr 30, 2009 at 12:15 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Well, the challenge is to retain the per SSA name information across
Graphite. At some point we need to stop re-computing points-to
information because we cannot do so with retaining IPA results.
Not to
On Wed, 2009-04-29 at 08:56 -0500, Tom Browder wrote:
Attached is a shortened test report with the following lines removed:
XFAIL
PASS
UNSUPPORTED
The preferred way to post test results is by running the script
$SRC/contrib/test_summary from within the build directory. It
produces a
On Wednesday 29 April 2009 12:47:04 Joern Rennecke wrote:
Something which I miss in C++ is a way to declare that a function uses
an integral type to pass an enum value (in arguments or return value),
and then at function definition time only check that the integral type
is sufficently large to
Michael Hope wrote:
HI there. I'm working on porting gcc to a new architecture which only
does indirect addressing - there is no indirect with displacement.
The IA-64 target also has only indirect addressing. Well, it has some
auto-increment addressing modes too, but that isn't relevant
Esben Mose Hansen k...@mosehansen.dk writes:
this program SEGFAULTs
#include algorithm
int main() {
int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
const std::size_t nn = sizeof(numbers)/sizeof(int);
int sum = 0;
int f = 5;
std::for_each(numbers[0], numbers[nn], [] (int n) {
On Wed, Apr 29, 2009 at 6:19 PM, Steven Bosscher stevenb@gmail.com wrote:
On Thu, Apr 30, 2009 at 12:15 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Well, the challenge is to retain the per SSA name information across
Graphite. At some point we need to stop re-computing
Does anyone understand why Apple's gcc-4.2 compiler in
Xcode 3.1.2 accepts the following code...
typedef const struct __CFString * CFStringRef;
typedef struct __CFBundle *CFBundleRef;
extern
CFStringRef CFBundleCopyLocalizedString(CFBundleRef bundle, CFStringRef key,
CFStringRef value,
On Apr 29, 2009, at 9:58 PM, Jack Howarth wrote:
Does anyone understand why Apple's gcc-4.2 compiler in
Xcode 3.1.2 accepts the following code...
typedef const struct __CFString * CFStringRef;
typedef struct __CFBundle *CFBundleRef;
extern
CFStringRef
--- Comment #2 from simon at pushface dot org 2009-04-29 06:00 ---
(In reply to comment #1)
The Ada make files don't use GNU libtool to build the shared libraries.
GNAT Pro 6.2.1 on Darwin uses -rpath/@rpath, presumably AdaCore will fold this
in at a future date.
--
Access to private types in a class from another instantiated template class is
not getting the expected type is private error from gcc compiler.
$gcc -c -v inp4.cpp
Using built-in specs.
Target: hppa1.1-hp-hpux11.11
Configured with: /tmp/gcc-4.3.1.tar.gz/gcc-4.3.1/configure
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Keywords|
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-29 07:05 ---
*** This bug has been marked as a duplicate of 16617 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-29 07:05 ---
*** This bug has been marked as a duplicate of 16617 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from pinskia at gcc dot gnu dot org 2009-04-29 07:09
---
*** Bug 39956 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-29
07:29 ---
The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
libssp-x.dll, etc) that are built as part of gcc
Danny
--
dannysmith at users dot sourceforge dot net changed:
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-29 07:38 ---
(In reply to comment #2)
The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
libssp-x.dll, etc) that are built as part of gcc
Danny
That's correct. We have to find a way to install
--- Comment #11 from vvv at ru dot ru 2009-04-29 07:46 ---
(In reply to comment #8)
From config/i386/i386.c:
/* AMD Athlon works faster
when RET is not destination of conditional jump or directly preceded
by other jump instruction. We avoid the penalty by inserting NOP just
--- Comment #12 from vvv at ru dot ru 2009-04-29 07:55 ---
(In reply to comment #9)
So that explains it, Use -Os or attribute cold if you want NOPs to be gone.
But my measurements on Core 2 Duo P8600 show that
push %ebp
mov %esp,%ebp
leave
ret
_faster_ then
push %ebp
mov
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-29 08:34 ---
Subject: Bug 39565
Author: rguenth
Date: Wed Apr 29 08:34:21 2009
New Revision: 146928
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146928
Log:
2009-04-29 Anmol P. Paralkar an...@freescale.com
PR
--- Comment #4 from jon_y at users dot sourceforge dot net 2009-04-29
08:37 ---
(In reply to comment #3)
(In reply to comment #2)
The same problem will occur for all dll's (libstdc++-x,dll,
libgfortran-x.dll,
libssp-x.dll, etc) that are built as part of gcc
Danny
That's
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-04-29 08:58
---
Shorter testcase, which still includes map, though.
It crashes with -O and above:
==
#includemap
struct A
{
virtual ~A() {}
};
struct B : A
{
virtual ~B() {
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-29 09:17
---
Jon, patch looks generally good to me, can you please send it to the mailing
list for higher visibility? Then we can commit it and close this annoying issue
once and for all ;)
--
--- Comment #4 from matz at gcc dot gnu dot org 2009-04-29 09:22 ---
I didn't enable it explicitely, but Janis neither (according to the
testresults post), so it's probably default. But I did not use some
other options, in particular the --with-cpu=default32, so I'm rechecking
with
--- Comment #13 from jakub at gcc dot gnu dot org 2009-04-29 09:32 ---
You are benchmarking something completely unrelated.
What really matters is how code that has 4 branches/calls in one 16-byte block
is able to predict all those branches. And Core2 similarly to various AMD CPUs
is
--- Comment #14 from jakub at gcc dot gnu dot org 2009-04-29 10:12 ---
Also, couldn't we use the information computed by compute_alignments and
assume CODE_LABELs are aligned?
Probably would need to add label_to_max_skip (rtx) function to final.c,
so that not just label_to_alignment,
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-29 10:39 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-29 10:39 ---
Subject: Bug 39941
Author: rguenth
Date: Wed Apr 29 10:39:26 2009
New Revision: 146948
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146948
Log:
2009-04-29 Richard Guenther rguent...@suse.de
PR
--- Comment #10 from joseph at codesourcery dot com 2009-04-29 11:33
---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 29 Apr 2009, matz at gcc dot gnu dot org wrote:
The user should have the possibility to announce the
--- Comment #11 from matz at gcc dot gnu dot org 2009-04-29 11:38 ---
Thanks for the clarification. So there indeed is only one issue, that the
temporary has an aligned type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-29 11:52 ---
In C:
int foo (int i)
{
int j;
switch (i)
{
case -__INT_MAX__ - 1 ... -1:
j = 6;
break;
case 0:
j = 5;
break;
case 1 ... __INT_MAX__:
j = 4;
break;
}
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-04-29 12:33
---
Confirmed. Reduced testcase (crashes with -O):
==
struct A
{
virtual ~A() {}
};
struct B : A
{
virtual ~B() { foo(); }
void foo();
};
struct C : B
{
C(const C c) :
--- Comment #10 from bangerth at gmail dot com 2009-04-29 12:51 ---
There is really nothing much that can be done within the current C++
standard. In C, NULL is defined as
(void*)0
which can be converted to any other pointer and so is clearly marked
as a pointer. The compiler can
--- Comment #4 from manu at gcc dot gnu dot org 2009-04-29 13:16 ---
(In reply to comment #3)
Note that getInt is completely inlined and there is no location involving
that function available anymore :/ The difficulties of C++ and late
diagnostics ...
I wonder what Clang+LLVM
--- Comment #1 from manu at gcc dot gnu dot org 2009-04-29 13:21 ---
Confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #11 from l dot lunak at suse dot cz 2009-04-29 13:21 ---
(In reply to comment #10)
As a consequence, since NULL can not in an obvious way be a pointer, there is
no obvious warning that can be generated.
Of course there is. NULL with gcc is not 0, 0L or (void*)0, it is
--- Comment #1 from manu at gcc dot gnu dot org 2009-04-29 13:23 ---
Confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from ramana at gcc dot gnu dot org 2009-04-29 13:48 ---
4.2.x is now closed. Since this appears to work on 4.3.1, could you confirm if
this is still a problem with an eabi toolchain of more recent vintage ?
--
ramana at gcc dot gnu dot org changed:
What
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-29 13:50 ---
(In reply to comment #5)
Pff, I still can't reproduce the testsuite failures, but I can reproduce the
ICE on the testcase from the initial comment. rs6000.c needs to handle
SSA_NAMEs now. I'm currently
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-29 13:54 ---
Created an attachment (id=17778)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17778action=view)
gcc44-pr39666.patch
Fix I'm going to bootstrap/regtest soon.
--
jakub at gcc dot gnu dot org changed:
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-29 13:58 ---
Could you check with a version of more recent vintage and provide more
information like the svn revision number ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-04-29 14:04 ---
That's by design.
Obviously there are so many possible combinations that you can't exhaustively
test them all, that's why this test randomly chooses some.
You can pass -n count to the generator to generate more (or
--- Comment #8 from hjl dot tools at gmail dot com 2009-04-29 14:04 ---
On Linux/x86-64, I got
gcc -c -o pp_sort.o -DSPEC_CPU -DNDEBUG -DPERL_CORE -O3 -ffast-math
-funroll-loops -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64 pp_sort.c
pp_sort.c: In function 'S_qsortsv':
--- Comment #9 from hjl dot tools at gmail dot com 2009-04-29 14:06 ---
(In reply to comment #8)
On Linux/x86-64, I got
gcc -c -o pp_sort.o -DSPEC_CPU -DNDEBUG -DPERL_CORE -O3 -ffast-math
-funroll-loops -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64 pp_sort.c
pp_sort.c: In
--- Comment #10 from rguenther at suse dot de 2009-04-29 14:06 ---
Subject: Re: [4.5 Regression] Revision 146831 failed
SPEC CPU 2006
On Wed, 29 Apr 2009, hjl dot tools at gmail dot com wrote:
--- Comment #8 from hjl dot tools at gmail dot com 2009-04-29 14:04
---
On
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-29 14:07 ---
This is a regression from 3.4.x to 4.0.x BTW.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hjl dot tools at gmail dot com 2009-04-29 14:10
---
(In reply to comment #10)
2009-04-28 Richard Guenther rguent...@suse.de
* tree-vect-loop.c (get_initial_def_for_induction): Use
correct types for pointer increment.
That is before and
--- Comment #12 from rguenther at suse dot de 2009-04-29 14:12 ---
Subject: Re: [4.5 Regression] Revision 146831 failed
SPEC CPU 2006
On Wed, 29 Apr 2009, hjl dot tools at gmail dot com wrote:
--- Comment #11 from hjl dot tools at gmail dot com 2009-04-29 14:10
---
(In
--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-29 14:12 ---
I wonder if this not a duplicate of pr36683.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39286
gcc 4.5 r146933
gcc -std=gnu99 -O2 -floop-block -c matmul_c4.c
/svn/compilers/gcc/libgfortran/generated/matmul_c4.c: In function 'matmul_c4':
/svn/compilers/gcc/libgfortran/generated/matmul_c4.c:79: internal compiler
error: in expand_scalar_variables_expr, at graphite.c:4262
Please submit a
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-29 14:17 ---
With -O2 VRP should (since 4.4) fix this as well. That said, newer GCC
no longer need a default label.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
--- Comment #3 from dominiq at lps dot ens dot fr 2009-04-29 14:19 ---
I have modified the code referenced in pr36683 as:
PROGRAM calls
IMPLICIT NONE
INTEGER :: a(2), b(3), c(6), n , i
c = myfunc(a,b)
WRITE(*,*) c:,c!! gives c: 1 2 3 4 5 6
n = 5
c = 0
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-29 14:20 ---
The only expected fails left should now be
FAIL: gcc.dg/pr34989-1.c (internal compiler error)
FAIL: gcc.dg/pr34989-1.c (internal compiler error)
FAIL: gcc.dg/pr34989-1.c (test for excess errors)
FAIL:
--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-29 14:20 ---
pr39286 is a duplicate of this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36683
--- Comment #1 from linuxl4 at sohu dot com 2009-04-29 14:21 ---
Created an attachment (id=17779)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17779action=view)
the source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39957
FAIL: libgomp.c++/task-4.C -O (internal compiler error)
FAIL: libgomp.c++/task-4.C -O (internal compiler error)
FAIL: libgomp.c++/task-4.C -O (test for excess errors)
FAIL: libgomp.c++/task-4.C -O (test for excess errors)
FAIL: gcc.dg/pr34989-1.c (internal compiler error)
FAIL: gcc.dg/pr34989-1.c (internal compiler error)
FAIL: gcc.dg/pr34989-1.c (test for excess errors)
FAIL: gcc.dg/pr34989-1.c (test for excess errors)
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr34989-2.c: In function
'syslogd_main':^M
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (internal compiler error)
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (internal compiler error)
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (test for excess errors)
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (test for excess errors)
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-04-29 14:27
---
Three actually.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39958
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
Fixed.
--
rguenth at gcc dot gnu dot org
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39958
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
--- Comment #10 from dominiq at lps dot ens dot fr 2009-04-29 14:28 ---
This may be a duplicate of PR36683(?).
It is not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
1 - 100 of 222 matches
Mail list logo
