Hi All,
Is this a known problem:
After upgrading to gcc 4.3.1, I can no longer compile a function whose
source code is 0.7 Megabyte before preprocessing and 3.5 Megabyte after
preprocessing.
The function (named testsuite) is just a long list of statements
essentially of form
On Mon, 8 Sep 2008, Andrew Haley wrote:
Klaus Grue wrote:
Is this a known problem:
After upgrading to gcc 4.3.1, I can no longer compile a function whose
source code is 0.7 Megabyte before preprocessing and 3.5 Megabyte after
preprocessing.
The function (named testsuite) is just a long list
On Mon, Sep 8, 2008 at 12:56 PM, Klaus Grue [EMAIL PROTECTED] wrote:
On Mon, 8 Sep 2008, Andrew Haley wrote:
Klaus Grue wrote:
Is this a known problem:
After upgrading to gcc 4.3.1, I can no longer compile a function whose
source code is 0.7 Megabyte before preprocessing and 3.5 Megabyte
Klaus Grue wrote:
Is this a known problem:
After upgrading to gcc 4.3.1, I can no longer compile a function whose
source code is 0.7 Megabyte before preprocessing and 3.5 Megabyte after
preprocessing.
The function (named testsuite) is just a long list of statements
essentially of form
I'm testing IRA on m68k (with IRA_COVER_CLASSES defined to {
GENERAL_REGS, FP_REGS, LIM_REG_CLASSES }) and get a crash in
process_regs_for_copy. It is called with
(insn 22 17 28 4 /cvs/gcc/libgcc/../gcc/libgcc2.c:169 (set (reg/i:SI 0 %d0)
(subreg:SI (reg/v:DI 30 [ w ]) 4)) 36
Jeff Law wrote:
H.J. Lu wrote:
My understanding is PowerPC is quite sensitive to choice of register
as shown in PR 28690. IRA merge may make fixes for PR 28690
ineffective. There are a few small testcases in PR 28690. You can
check if those problems in PR 28690 come back due to IRA merge.
Also,
Hello All,
I am correct in assuming that pretty printing debug dumping in GCC
tend to go thru the pretty printer abstraction of gcc/pretty-printer.h
hence that the old way of printing directly to a file (like e.g. dump_bb
or debug_bb in gcc/cfg.c for printing basic_block-s) is deprecated,
On Mon, Sep 8, 2008 at 10:13, Basile STARYNKEVITCH
[EMAIL PROTECTED] wrote:
Hello All,
I am correct in assuming that pretty printing debug dumping in GCC tend to
go thru the pretty printer abstraction of gcc/pretty-printer.h hence that
the old way of printing directly to a file (like e.g.
Diego Novillo wrote:
[EMAIL PROTECTED] wrote:
I am correct in assuming that pretty printing debug dumping in GCC tend to
go thru the pretty printer abstraction of gcc/pretty-printer.h hence that
the old way of printing directly to a file (like e.g. dump_bb or debug_bb in
gcc/cfg.c for
Eric Botcazou writes:
Confirmed (on Solaris 9). Would you mind opening a PR? There is already one
for Linux (37344) but the failure is a little different. Thanks in advance.
Sure, done: PR bootstrap/37424.
Rainer
On Mon, Sep 8, 2008 at 11:04, Basile STARYNKEVITCH
[EMAIL PROTECTED] wrote:
Do you mean that the trend is to have both dump_* routines (writing to
FILE*) and prettyprinting routines? Except of course the historical
existence of code, I don't understand why both are needed (unless dumping is
Diego Novillo wrote:
On Mon, Sep 8, 2008 at 11:04, Basile STARYNKEVITCH
[EMAIL PROTECTED] wrote:
I understood that all prettyprinting is systematically using an obstack as a
buffer (actually, I renamed the FILE* field to something else, and it does
not appear a lot).
I wouldn't oppose a
Hi,
Is there a way to order the compiler to output only virtual registers
within the assembly code ? (pointers to GCC code sections in back-end or
in MD files are welcome) Hence the result assembly code would not have a
conventional register allocation. It would be using an unlimited number
Thomas A.M. Bernard wrote:
Hi,
Is there a way to order the compiler to output only virtual registers
within the assembly code ? (pointers to GCC code sections in back-end or
in MD files are welcome) Hence the result assembly code would not have a
conventional register allocation. It would
Hi Paolo,
On Thu, Aug 21, 2008 at 04:29:26PM +0200, Paolo Bonzini wrote:
Peter O'Gorman wrote:
On Mon, Aug 11, 2008 at 03:02:05PM -0500, Peter O'Gorman wrote:
Yes, I tried it also -
http://pogma.com/misc/gcc-libtool-git20080810.patch (Slight change to
ltgcc.m4, otherwise git libtool +
Well, libtool-2.2.6 is finally released (twice even).
Actual approval depends on your answer to this question, but the patch is
technically okay. Can you commit it to the src repository too? There is
some regeneration to do there too.
I know that GCC is now in stage 3, and that we
From: Rainer Orth [EMAIL PROTECTED]
Date: Mon, 8 Sep 2008 17:18:50 +0200 (MEST)
Eric Botcazou writes:
Confirmed (on Solaris 9). Would you mind opening a PR? There is already
one
for Linux (37344) but the failure is a little different. Thanks in advance.
Sure, done: PR
On Mon, Sep 08, 2008 at 08:29:37PM +0200, Paolo Bonzini wrote:
Well, libtool-2.2.6 is finally released (twice even).
Actual approval depends on your answer to this question, but the patch is
technically okay. Can you commit it to the src repository too? There is
some regeneration
Jeff Law [EMAIL PROTECTED] writes:
Andreas Schwab wrote:
I'm testing IRA on m68k (with IRA_COVER_CLASSES defined to {
GENERAL_REGS, FP_REGS, LIM_REG_CLASSES }) and get a crash in
process_regs_for_copy. It is called with
(insn 22 17 28 4 /cvs/gcc/libgcc/../gcc/libgcc2.c:169 (set (reg/i:SI 0
Andreas Schwab wrote:
Jeff Law [EMAIL PROTECTED] writes:
Andreas Schwab wrote:
I'm testing IRA on m68k (with IRA_COVER_CLASSES defined to {
GENERAL_REGS, FP_REGS, LIM_REG_CLASSES }) and get a crash in
process_regs_for_copy. It is called with
(insn 22 17 28 4
Jeff Law [EMAIL PROTECTED] writes:
Strange as I didn't trip this at all. I wonder if I've got something
out-of-date in my tree
I've only seen the crash during native testing. Since it's accessing an
array beyond its bounds it depends on the surrounding data on how the
error manifests.
On Sun, Sep 7, 2008 at 15:27, Basile STARYNKEVITCH
[EMAIL PROTECTED] wrote:
Given that passes are central to the middle end in GCC, shouldn't we want
each of them (without exception!) be described by at least a simple
paragraph. I'm sure that is a small effort for each pass writer (he/she
Andreas Schwab wrote:
Jeff Law [EMAIL PROTECTED] writes:
Strange as I didn't trip this at all. I wonder if I've got something
out-of-date in my tree
I've only seen the crash during native testing. Since it's accessing an
array beyond its bounds it depends on the surrounding
Diego Novillo wrote:
On Sun, Sep 7, 2008 at 15:27, Basile STARYNKEVITCH
[EMAIL PROTECTED] wrote:
Yes, absolutely. The problem, as usual, is lack of time. Our
standards for internal documentation are pretty bad and the set of
people writing the documentation is always different than the set
Peter O'Gorman wrote:
On Mon, Sep 08, 2008 at 08:29:37PM +0200, Paolo Bonzini wrote:
Well, libtool-2.2.6 is finally released (twice even).
Actual approval depends on your answer to this question, but the patch is
technically okay. Can you commit it to the src repository too? There is
some
I just got back from vacation and I see the HPPA bootstrap is failing
with:
cc1: warnings being treated as errors
/proj/opensrc/nightly/src/trunk/gcc/c-common.c: In function
'c_warn_unused_result':
/proj/opensrc/nightly/src/trunk/gcc/c-common.c:7540: error: 'i.745.ptr' is used
uninitialized in
On Mon, Sep 8, 2008 at 2:00 PM, [EMAIL PROTECTED] wrote:
I just got back from vacation and I see the HPPA bootstrap is failing
with:
cc1: warnings being treated as errors
/proj/opensrc/nightly/src/trunk/gcc/c-common.c: In function
'c_warn_unused_result':
This doesn't look HPPA specific but I haven't seen anything in the
mailing lists. HPPA is/was having other problems but this doesn't seem
to be related to them. Is anyone else seeing these messages?
This was reported as PR 37380.
As a work around, revert this change:
2008-09-03
Richard Guenther [EMAIL PROTECTED] writes:
to its language tree.def and gimplify this. Before I embark on
this I'd like to ask whether using
__builtin_longjmp/__builtin_setjmp is definitely the wrong way to
go?
Definitely. You will be not able to handle/throw exceptions from
other
Klaus:
Perhaps your problem is related to PR 26854:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
See in particular comment 70, which has some statistics.
If you're building your own gcc, configure gcc with --enable-gather-
detailed-mem-stats and compile your program with -ftime-report
Maybe it's not a proper place to put this message. I just noticed a
mistake when I read the paper of gcc summit 2003 named The finite
state automaton based pipeline hazard recognizer and instruction
scheduler in GCC. The first cycle multi-pass instruction scheduling
algorithm:
...
if n 0 ||
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-08 06:36 ---
IIRC, this behaviour is due to a patch I submitted some time ago. Maybe I
could change this warning into an error even for non-standard conforming mode
in case the length or a kind parameter differs. What do you
For the loop in testcase of pr36630:
void
foo (unsigned char *x, short y)
{
short i;
i = 2;
while (i y)
{
x[i - 1] = x[i];
i = i + 1;
}
}
we used to get
# of iterations (short unsigned int) y_3(D) + 65533, bounded by 32764
and now we get scev_not_known.
Also
--- Comment #1 from ubizjak at gmail dot com 2008-09-08 06:50 ---
Confirmed:
Program received signal SIGSEGV, Segmentation fault.
0x082ac655 in optimize_function_for_speed_p (fun=0x0) at
../../gcc-svn/trunk/gcc/predict.c:205
/home/uros/gcc-svn/trunk/gcc/predict.c:205:6178:beg:0x82ac655
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-08 06:51 ---
Given http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00370.html
I think we can safely close this now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from abel at ispras dot ru 2008-09-08 07:19 ---
(In reply to comment #16)
Could you explain why max_issue() should do anything
when more_issue = 0? I'd have expected it to early-out.
But the whole point of the patch is that we _can_ actually issue more insns
even
--- Comment #5 from burnus at gcc dot gnu dot org 2008-09-08 07:21 ---
Subject: Bug 37400
Author: burnus
Date: Mon Sep 8 07:19:46 2008
New Revision: 140100
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140100
Log:
2008-09-07 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #15 from pault at gcc dot gnu dot org 2008-09-08 07:22 ---
Jack,
I've remarked this as a 4.3 regression and have taken out the major from the
summary. However, since it appears in posted benchmarks, I have moarked it as
confirmed.
Thanks for the report.
Best regards
--- Comment #6 from burnus at gcc dot gnu dot org 2008-09-08 07:38 ---
FIXED on the trunk (4.4.0).
(I'm not sure whether it fully works with 4.3.x - I get a segmentation fault
after the third line is correctly printed. The cause that it was failing on 4.4
was the patch for PR 36476;
--- Comment #13 from irar at il dot ibm dot com 2008-09-08 07:44 ---
(In reply to comment #9)
Subject: Re: [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer
Another thing, 4.4 does not vectorize this loop anymore (and, therefore,
there
is no ICE), because of
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-08 07:57 ---
Subject: Bug 37099
Author: domob
Date: Mon Sep 8 07:55:49 2008
New Revision: 140101
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140101
Log:
2008-09-04 Daniel Kraft [EMAIL PROTECTED]
* PR
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-08 07:57 ---
Fixed on trunk and 4.3
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from tehila at il dot ibm dot com 2008-09-08 08:21 ---
(In reply to comment #11)
(In reply to comment #10)
I'm bootstraping and testing it on x86 now.
Bootstrap fails (at least on x86_64) (with ICE).
Tehila.
It fails at tree-ssa-loop-manip.c:424 (+-, I've changed
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-08 08:28 ---
Dominique reported that my pending patch for PR 37199 fixes this problem, too,
and a test confirms this for me. Reading the commets, it seems quite plausible
to me that the ICE here is caused because of the missing
With current trunk (revision 140100):
(sid)2294:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c
-finline-limit=1048576
-O3 gutenprint-mxml-file.i
*** glibc detected ***
/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.4.0/cc1: malloc(): memory
corruption (fast): 0x01da1890
--- Comment #2 from tbm at cyrius dot com 2008-09-08 08:53 ---
Created an attachment (id=16251)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16251action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37417
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-08 09:56 ---
I don't see how SRA can affect 004.gimple output, but the gimplification looks
wrong. For
size_t width = cvt.width;
you should see
D.6101 = cvt.width;
width = (size_t) D.6101;
--
--- Comment #4 from amonakov at gcc dot gnu dot org 2008-09-08 10:38
---
Scheduling of instructions dependent on speculative loads was implemented a
bit differently on sel-sched branch and on trunk (before the merge). Since
ia64.c changes were not checked in, a discrepancy appeared,
With current trunk (revision 140100):
(sid)1092:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c
dovecot-failures.i
failures.c: In function 'i_set_panic_handler':
failures.c:242: error: type mismatch in address expression
void (*T678) (const char *, struct *)
void (*Tab6) (const char *,
--- Comment #1 from tbm at cyrius dot com 2008-09-08 08:48 ---
Forgot to mention that this also happens with -O0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37417
--- Comment #7 from jwakely dot gcc at gmail dot com 2008-09-08 10:36
---
I've got result_of working but am also fixing up reference_wrapper and
__invoke() to forward correctly using rvalue-references.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37351
--- Comment #1 from tbm at cyrius dot com 2008-09-08 08:53 ---
Created an attachment (id=16252)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16252action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37418
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-08 12:40 ---
Subject: Bug 37415
Author: jakub
Date: Mon Sep 8 12:39:28 2008
New Revision: 140105
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140105
Log:
PR middle-end/37415
* opts.c
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-09-08 09:26 ---
There used to be a message in fortran-format, not a middle end message.
See PR24784.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37420
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-08 12:42 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-08 12:21 ---
ANTIC_OUT[4] := { {view_convert_expr ,integer_cst 0} (0005) }
ANTIC_IN[4] := { {view_convert_expr ,integer_cst 0} (0005) }
S[4] := { {view_convert_expr ,integer_cst 0} (0005) }
so a quick look suggests we fail to
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-08 09:18 ---
Subject: Bug 37199
Author: domob
Date: Mon Sep 8 09:17:27 2008
New Revision: 140102
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140102
Log:
2008-09-08 Daniel Kraft [EMAIL PROTECTED]
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-08 09:23 ---
Created an attachment (id=16254)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16254action=view)
Regtested patch, including test case
The same as patch. However, I'm not sure the fix is right.
a) Why is sym-as
--- Comment #16 from dominiq at lps dot ens dot fr 2008-09-08 09:00 ---
A few personal comments.
2) The problem doesn't occur on powerpc-apple-darwin9.
This is normal. REAL(8) are not vectorized on ppc since they are not part of
altivec. IBM has preferred to add a second FPU.
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-08 09:46 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2008-09-08 09:02 ---
All tests work OK with a cross from linux to x86_64-pc-mingw32 as of version
GNU Fortran (GCC) version 4.4.0 20080908 (experimental) [trunk revision 140099]
(x86_64-pc-mingw32)
Please ask gfortran community to provide
Consider the following Fortran code:
subroutine s(x)
real :: x
integer :: i
end subroutine
Compiling this with gfortran-4.3 -Wunused-variable triggered two warnings:
Warning: Unused variable 'i' declared at (1)
Warning: Unused dummy argument 'x' at (1)
With recent trunk builds the first
--- Comment #3 from tbm at cyrius dot com 2008-09-08 10:08 ---
/* Testcase by Martin Michlmayr [EMAIL PROTECTED] */
class tplasma
{
public: int maxx;
};
tplasma plasma;
void init (void)
{
new (char[plasma.maxx]);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37417
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-08 12:16 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
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
--- Comment #4 from dominiq at lps dot ens dot fr 2008-09-08 09:46 ---
I am not 100% sure, but I somehow got the impression that the patch for pr37199
also fixed this pr. Could you check if this is the case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37411
Found with this test case. Still have not analyzed it, so I'm not quite sure
where we're getting confused:
#include stdio.h
#include string.h
inline int
bci (const float source)
{
int dest;
memcpy (dest, source, sizeof (dest));
return dest;
}
inline float
bcf (const int source)
{
float
--- Comment #1 from tbm at cyrius dot com 2008-09-08 08:54 ---
Created an attachment (id=16253)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16253action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37419
--- Comment #6 from erik dot moller at cycos dot com 2008-09-08 10:54
---
bug is still in 4.3.2
--
erik dot moller at cycos dot com changed:
What|Removed |Added
With current trunk (revision 140100):
(sid)1089:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2
asc-edgen.ii
./../../edgen.cpp: In member function 'void tmapgenerator::init()':
./../../edgen.cpp:71: error: type mismatch in binary expression
long unsigned int
long unsigned int
int
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-08 13:52 ---
Subject: Bug 36167
Author: domob
Date: Mon Sep 8 13:51:26 2008
New Revision: 140107
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140107
Log:
2008-09-08 Daniel Kraft [EMAIL PROTECTED]
PR
--- Comment #5 from dominiq at lps dot ens dot fr 2008-09-08 13:53 ---
I have reverted the patch in comment #3 on intel/Darwin9 and updated to r140104
on ppc/Darwin9 and in both cases the original test compiles without error. Is
it another fix due to the one for pr37199?
Anyway, it
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-08 13:54 ---
This was apparently really fixed by my patch for PR 37199, I committed the
test-case attached to trunk. Marking fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed
Immediately after the IRA merge, i386-pc-solaris2.10 doesn't bootstrap any
longer:
In stage3, libgcc doesn't configure:
checking for suffix of object files... configure: error: in
`/vol/gccsrc/obj/gcc-4.4.0-20080903/10-gcc/i386-pc-solaris2.10/libgcc':
configure: error: cannot compute suffix of
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
In the current implementation of Fortran 2003 type-bound procedures, DEFERRED
bindings are not yet implemented. The DEFERRED type attribute will be parsed
but results in an immediate error.
--
Summary: Fortran 2003 DEFERRED bindings not yet implemented
Product: gcc
Immediately after the IRA merge, sparc-sun-solaris2.11 bootstrap is broken:
stage2 libgcc fails to configure:
checking for suffix of object files... configure: error: in
`/vol/gccsrc/obj/reghunt/89389/sparc-sun-solaris2.11/libgcc':
configure: error: cannot compute suffix of object files: cannot
--- Comment #11 from vmakarov at redhat dot com 2008-09-08 14:11 ---
Eric, thanks a lot for your analysis. It was very helpful. I've reproduced the
bug.
IRA uses live ranges to find conflicts for spill slots during reload. Live
ranges for r376 were wrong after IR flattening. We have
GENERIC type-bound procedures are currently implemented in gfortran, but only
by name and not as operators as in the following example (the polymorphic
passed-object problem included):
MODULE m
IMPLICIT NONE
TYPE :: t
INTEGER :: i
CONTAINS
PROCEDURE :: assign_t_from_int
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [build/gengtype-lex.o] Error 1
This might be identical to PR rtl-optimization/37333. I'm currently running
a mainline bootstrap as of 20080908 to check
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-08 14:56 ---
I have a (good on its own) patch to hide the issue, but I'll try to investigate
the issue some more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37421
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-08 15:08 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
As polymorphic entities are not implemented in gfortran, the handling of
passed-object dummy arguments allows (or requires) them to be declared
non-polymorphic (TYPE(t)) while they should in fact be CLASS(t):
MODULE m
TYPE :: t
CONTAINS
PROCEDURE :: proc
END TYPE t
CONTAINS
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37427
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-08 15:14 ---
It actually is the correct fix. We valueize expressions in-place, and
copy visiting doesn't follow the chain up until a constant. So we have
a = 0;
= VIEW_CONVERT_EXPR a;
b = a;
= VIEW_CONVERT_EXPR b;
we
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-09-08 15:25
---
Eric, thanks a lot for your analysis. It was very helpful.
You're welcome!
IRA uses live ranges to find conflicts for spill slots during reload. Live
ranges for r376 were wrong after IR flattening. We
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-09-08 15:32
---
Yep. I'll try to debug later today.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-08 16:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-09-08 16:33 ---
Subject: Bug 37421
Author: rguenth
Date: Mon Sep 8 16:31:43 2008
New Revision: 140111
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140111
Log:
2008-09-08 Richard Guenther [EMAIL PROTECTED]
PR
This is a GNU extension to C99:
void foo(int n)
{
struct S { int x[n]; };
}
It is not mentioned in the C Extensions section of the manual.
--
Summary: GNU VLA-in-structure extension is undocumented
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-08 17:31 ---
Unrelated. Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
It seems that code like
a = obj%func () ! PROCEDURE, NOPASS :: func = target_func
misses some checks (for instance, that a and the result of func have the same
rank) that are performed for the equivalent
a = target_func ()
The attached test program not only misses a diagnostic for this, but
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-08 17:59 ---
Created an attachment (id=16255)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16255action=view)
ICE'ing invalid test
This is the ICE'ing test. I will investigate this bug, as it seems to be a
problem with
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-09-08 18:22 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-09-08 18:29 ---
(In reply to comment #0)
I would like a method to override
the default buffering at runtime.
What about calling FLUSH in critical places?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37355
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-08 18:37 ---
Reading the comments, this sounds really like the problem fixed for PR 37199
(sym-as wrongly NULL after interface-remapping). I agree that adding the
test and gcc_assert sounds like a good idea for me.
I will work
Laurent indicated this is spurious on other targets but it is 100% regular on
rtems so I thought I would give a backtrace.
It is calling pthread_kill(SIGABORT). This is the backtrace.
,.,. C974013 ACATS 2.5 88-01-01 00:00:00
C974013 Asynchronous Select: Trigger is delay_until which
--- Comment #1 from joel at gcc dot gnu dot org 2008-09-08 19:05 ---
Worked on SVN trunk as of this report
http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg02355.html
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 173 matches
Mail list logo
