--- Comment #3 from johnzhang at tencent dot com 2006-04-28 06:36 ---
Ok, you are right. it would be nice if g++ 4.1.0 acts as what g++ 3.3.4 does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257
--- Comment #3 from mark at codesourcery dot com 2006-04-28 05:02 ---
Subject: Re: gcc/Makefile.in:s-macro_list sed fails
with make 3.81 due to POSIX support changes
debian-gcc at lists dot debian dot org wrote:
> --- Comment #1 from debian-gcc at lists dot debian dot org 2006-04
--- Comment #9 from amodra at gcc dot gnu dot org 2006-04-28 03:41 ---
Subject: Bug 27260
Author: amodra
Date: Fri Apr 28 03:41:34 2006
New Revision: 113341
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113341
Log:
gcc/
PR middle-end/27260
* builtins.c (expand_b
--- Comment #9 from amodra at gcc dot gnu dot org 2006-04-28 03:36 ---
Subject: Bug 27095
Author: amodra
Date: Fri Apr 28 03:36:15 2006
New Revision: 113340
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113340
Log:
PR middle-end/27095
* gcc.dg/pr27095.c: New.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-28 03:31 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-04-28 02:42
---
Fixed in 4.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-04-28 02:41
---
Subject: Bug 27292
Author: mmitchel
Date: Fri Apr 28 02:40:58 2006
New Revision: 113339
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113339
Log:
PR c++/27292
* tree.c (rvalue): Convert bi
--- Comment #71 from pinskia at gcc dot gnu dot org 2006-04-28 00:00
---
*** Bug 27344 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-28 00:00 ---
(five * 2 * five.neg());
This is equivlant to:
(five * 2) * (five.neg())
but the C and C++ standard do not specify which expression is evulated first.
In that (five * 2) might be evulated first or five.neg(). five.
Here is the version and system info:
% g++ -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atex
--- Comment #3 from andreast at gcc dot gnu dot org 2006-04-27 22:33
---
I'll submit the patch tommorow. It has been in my queue for a longer time.
Index: configure.ac
===
--- configure.ac(revision 113320)
+++ conf
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-04-27 22:21 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01058.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from malitzke at metronets dot com 2006-04-27 22:03 ---
Further:
I started the gcc-4.1.1 bootstrap with a different gcc (atually now a earlier
4.2.0) and it come up with the same "else label does not match edge." The
xgcc now was generated by a different version of gcc
--- Comment #7 from steven at gcc dot gnu dot org 2006-04-27 21:32 ---
Yes, BIT_IOR_EXPR is also not handled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
--- Comment #4 from malitzke at metronets dot com 2006-04-27 21:25 ---
Well, Andy, not so fast. Doing:
./xgcc -B./ -c libgcov,i
I get no message and a get a "libgcov,o"
Anyhow that machine is a four processor server with 2G error corrected memory.
Also I have about 13 other commands pro
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-27 21:14 ---
(In reply to comment #5)
> So I asked myself, why are we not catching this in vrp? I know we can derive
> ranges from types, so why don't we derive a [0,1] range from the bitfield
> load?
> D.1883_4: [0, 1] EQUIVA
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-27 21:02 ---
if you run the preprocessed source again, do you run into the segfault/error?
If so then this is a hardware problem with your machine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from malitzke at metronets dot com 2006-04-27 20:49 ---
I got it once and did a svn update to 113320 for good measure but still got
apparently the same segmentation fault. However, libgcov.c is processed about
14 times with a different -DLgcove_xxx each time and the error
--- Comment #5 from steven at gcc dot gnu dot org 2006-04-27 20:46 ---
So I asked myself, why are we not catching this in vrp? I know we can derive
ranges from types, so why don't we derive a [0,1] range from the bitfield load?
It turns out that we make _all_ loads VARYING right away,
--- Comment #1 from malitzke at metronets dot com 2006-04-27 20:40 ---
Created an attachment (id=11341)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11341&action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27342
disable-werror --with-gnu-ld --enable-libgcc-math
--with-mpfr-dir=/l3/mpfr-2.2.0 --with-mpfr=/usr/lib --with-gmp-dir=/l3/gmp-4.2
--with-gmp=/usr/lib --enable-languages=c,c++,fortran,java,objc
--with-cpu=pentium3 --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 20060427 (prerelease)
./cc1 -E
--- Comment #15 from amacleod at redhat dot com 2006-04-27 20:22 ---
Subject: Bug 26854
Author: amacleod
Date: Thu Apr 27 20:22:17 2006
New Revision: 113321
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113321
Log:
Implement new immediate use iterators.
2006-04-27 Andrew MacL
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |normal
Keywords||rejects-valid
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-27 19:17 ---
And this is fully complex types related, the ICE comes right after cplxlower,
most likely caused by the complex type getting split up into two different
loads. (I have not checked that theory yet).
--
http://gc
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-27 19:14 ---
Note fixing the prototype of zgemm_ to:
void zgemm_ (const double*, const int*);
We Still ICE (I had messed the order up before).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-27 19:11 ---
Confirmed, since this is a reducetion from PR 26626 #13.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
Reduced testcase (-O2 to invoke the ICE):
void zgemm_ (const int*, const double*);
extern void matmul_c8 (_Complex double * dest)
{
const int ldc = 0;
const double zero = 0;
zgemm_ ( &zero, &ldc);
dest[1] += 1 ;
}
-
Unlike PR26626, the co
--- Comment #2 from steven at gcc dot gnu dot org 2006-04-27 19:10 ---
Patches addressing some of the issues:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00969.html
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01049.html
I'm linking them from here for reference.
--
http://gcc.gnu.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-27 19:07 ---
Both libc and libstdc++ are considered part of the implementation which means
both are valid to use this name space.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-04-27 19:06
---
The problem in Comment #9 has been resolved in 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-04-27 19:03
---
Subject: Bug 27102
Author: mmitchel
Date: Thu Apr 27 19:02:54 2006
New Revision: 113320
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113320
Log:
PR c++/27102
* typeck2.c (cxx_incomplete_
valarray defines structs with names like __cos, __sin, etc. It is often the
case (glibc, solaris) that the libc declares functions with those same names.
In the current situation we are lucky because the structs are in namespace std
and the functions in the global namespace. But playing around with
<[EMAIL PROTECTED]> writes:
| On 26 Apr 2006, Gabriel Dos Reis wrote:
|
| > <[EMAIL PROTECTED]> writes:
| >
| > | It is gcc 4.1.0, --target=arm-elf compiled on an Intel platform and
| > | GNU/Linux.
| > |
| > | The following construct:
| > |
| > | void *p;
| > |
| > | ((char *)p)++;
| > |
| > |
--- Comment #5 from rakdver at gcc dot gnu dot org 2006-04-27 17:42 ---
This is more or less dup of PR23434 (the fix for it is not quite correct). I am
testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-04-27 17:08
---
Happens with -O -quiet t.c -dumpbase t.c -fdump-tree-alias1-vops
-fstrict-aliasing -fno-tree-fre -fno-tree-ccp -fdump-tree-all -fno-tree-dce
-fno-tree-copyrename -fno-tree-salias and manually disabled forwprop.
S
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-04-27 16:56
---
This one ICEs the same way, already during the first copyprop pass:
typedef union {
int d;
} U;
int rv;
void breakme()
{
U *rv0;
U *pretmp = (U*)&rv;
rv0 = pretmp;
rv0->d = 42;
}
--
http:
--- Comment #18 from dberlin at gcc dot gnu dot org 2006-04-27 16:55
---
Subject: Re: [4.2 Regression] ICE in in
add_virtual_operand
On Thu, 2006-04-27 at 16:43 +, rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #17 from rguenth at gcc dot gnu dot org 2006-04-2
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-04-27 16:43
---
Subject: Bug 25514
Author: rsandifo
Date: Thu Apr 27 16:43:10 2006
New Revision: 113313
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113313
Log:
PR rtl-optimization/25514
* combine.c (rep
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-04-27 16:43
---
As followup to comment #9, copyprop propagates pretmp.23_2 into rv.0_1->d, and
in
may_propagate_copy we see that rv.0_1 has both an SMT and NMT associated with,
while pretmp.23_2 has none of the two.
--
http:/
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-04-27 16:41
---
Subject: Bug 25514
Author: rsandifo
Date: Thu Apr 27 16:41:51 2006
New Revision: 113312
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113312
Log:
PR rtl-optimization/25514
* combine.c (rep
Following code does not compile with gcc 4.1.
It compiles with gcc 3.4.0 and gcc 4.0.2 and comeau online.
=
class A
{
private:
enum private_enum {a};
template // OK
struct B
{
void bm();
};
public:
void am()
{
B instance; //OK
instance
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-27 16:26 ---
This works for me and many other people. Make sure you don't have bad memory
or hardware.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27333
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-27 16:11 ---
I should note that this is not a regression and maybe someone over at GNU make
should have tested building GCC. Note also this is going to be another
poltical mess.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #10 from rguenther at suse dot de 2006-04-27 16:09 ---
Subject: Re: -fivopts producing out of bounds
array refs
On Thu, 27 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> > Stripping useless type conversions during biv discovery and folding after
>
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-27 16:02 ---
Subject: Re: -fivopts producing out of bounds array refs
> One thing is, that find_interesting_uses_address () produces bases that look
> like &(&a[0])->s. I.e. they are not folded during IV
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-27 15:59 ---
The offset causes the assembler to be sub-optimal:
.LCFI2:
leal-12(%ebp), %eax
leal4(%ebp), %edx
.p2align 4,,7
.L2:
movl$1, -4(%eax)
addl$4, %eax
cmpl
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-27 15:47 ---
One thing is, that find_interesting_uses_address () produces bases that look
like &(&a[0])->s. I.e. they are not folded during IV base insertion via
if (!for_each_index (&base, idx_find_step, &ifs_ivopts_data
--- Comment #16 from dberlin at gcc dot gnu dot org 2006-04-27 15:39
---
Subject: Re: [4.2 Regression] ICE in in
add_virtual_operand
> What's the status on this? It makes libgfortran build crash with a patch I'd
> like to submit.
Uh, okay, so, until someone debugs the other
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-27 15:38 ---
This is not specific to goto, any OMP structured block which the initial cfg
pass proves it will never return is a problem. In that case, the corresponding
OMP_RETURN is optimized out as unreachable. The first ICE is
--- Comment #10 from amylaar at gcc dot gnu dot org 2006-04-27 15:35
---
(In reply to comment #6)
> Created an attachment (id=11305)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11305&action=view) [edit]
> proposed patch for 4.1
>
The assignment
inner = max_align;
mus
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-04-27 15:00 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01044.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-27 14:26 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-27 14:25 ---
Subject: Bug 26685
Author: rguenth
Date: Thu Apr 27 14:25:49 2006
New Revision: 113300
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113300
Log:
2006-04-27 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-27 14:24 ---
Subject: Bug 26685
Author: rguenth
Date: Thu Apr 27 14:24:15 2006
New Revision: 113299
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113299
Log:
2006-04-27 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-27 13:53
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-27 13:52 ---
Subject: Bug 25148
Author: rguenth
Date: Thu Apr 27 13:52:44 2006
New Revision: 113298
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113298
Log:
2006-04-27 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #2 from paul dot thomas at jet dot uk 2006-04-27 13:24 ---
Holmes was wrong - it was a one piper.
The symbol for the module equivalence was being scrubbed for the lack of a
gfc_commit_symbols. Interchanging lines 1061 and 1064 in trans-common.c does
the job. Thus:
/* Tran
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-04-27 13:14
---
(In reply to comment #11)
> The only solution in these cases it to remove the assert and let it
> generate bad code, but I want to fix other issues first before removing
> the assert.
What's the status on this?
According to http://gcc.gnu.org/projects/mipso64-abi.html
"if the first and second arguments floating-point arguments
to a function are 32-bit values, they are passed in $f12
and $f14". The assembler file obtained as a result of
compilation with mips64-none-elf-gcc-4.1.0 of the following
file (o
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-27 13:10 ---
Confirmed. The frontend needs to tell the middle-end that the argument is
non-NULL. Like by making the methods __attribute__((nonnull(1))).
--
rguenth at gcc dot gnu dot org changed:
What|Remove
--- Comment #3 from Klaas dot Vantournhout at UGent dot be 2006-04-27
13:09 ---
The first test case gives me the same error when using the flags -fopenmp -c.
When I don't use -fopenmp, the code will compile.
The second test case gives me an other ICE.
code2.c: In function S foo():
co
--- Comment #2 from patchapp at dberlin dot org 2006-04-27 12:55 ---
Subject: Bug number PR26685
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01035.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #9 from jv244 at cam dot ac dot uk 2006-04-27 12:53 ---
> [Adding Joost in CC list]
Thanks. Any idea if it runs properly with the patch in place (have a look at
the script cp2k/tools/do_regtest for setting up a testing run) ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #7 from patchapp at dberlin dot org 2006-04-27 12:50 ---
Subject: Bug number PR27151
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01034.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-27 12:36
---
I cannot reproduce this anymore on 4.1 or mainline. (I can however see the
const duplication by PRE)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-27 12:22 ---
OMP gimplification and lowering needs to handle RESULT_DECLs.
Simplified testcases e.g.:
struct S
{
S ();
~S ();
double &operator* () const;
};
S
foo ()
{
int i;
S ret;
#pragma omp parallel for
for (i = 0
--- Comment #1 from Klaas dot Vantournhout at UGent dot be 2006-04-27
12:19 ---
I forgot to state that in the FC5 version gcc (GCC) 4.1.0 20060304
(Red Hat 4.1.0-3) the ICE appears in expand_expr_real_1, at expr.c:6694.
Klaas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27337
--
gnu_andrew at member dot fsf dot org changed:
What|Removed |Added
Target Milestone|--- |0.91
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26688
--
gnu_andrew at member dot fsf dot org changed:
What|Removed |Added
Target Milestone|--- |0.91
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26707
--
gnu_andrew at member dot fsf dot org changed:
What|Removed |Added
Target Milestone|--- |0.91
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24632
Hi,
I have obtained an ICE in expand_expr_real_1, at expr.c:6814 when trying to
build my code using OpenMP. I am using gcc version "4.2.0 20060422
(experimental)" on target x86_64-unknown-linux-gnu.
The problem appears also in the FC5 gcc4.1.0 version "gcc (GCC) 4.1.0 20060304
(Red Hat 4.1.0-3)"
--
gnu_andrew at member dot fsf dot org changed:
What|Removed |Added
Target Milestone|--- |0.91
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27111
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-04-27 11:50
---
Patch (at least partial) submitted for approval. The patch allows CP2K to
compile.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from patchapp at dberlin dot org 2006-04-27 11:50 ---
Subject: Bug number PR fortran/25681
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01033.html
--
http://gcc.gnu.org/bu
--
gnu_andrew at member dot fsf dot org changed:
What|Removed |Added
Target Milestone|--- |0.91
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22163
I noticed that GCC tends to litter the assembly code with null checks and jumps
(especially for dynamic casts) even when the pointer cannot be null. This is
especially true for "this": unless I am mistaken, calling a nonstatic member
with "this" not pointing to an object of the correct type (or a d
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-27 11:23 ---
Still happens.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-04-27 11:21
---
This is fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-27 11:05 ---
slpeel_update_phis_for_duplicate_loop does not do its job properly. It fails
to
update the PHI nodes of at least the new loops latch block:
(gdb) call debug_bb (new_loop->latch)
;; basic block 14, loop depth 1, cou
--- Comment #1 from paul dot thomas at jet dot uk 2006-04-27 10:44 ---
This one is marvelous - it's one of Sherlock Holme's "three pipers".
If the initialization is removed, all works correctly. If the module is
compiled separately and the object file linked with the main program, it w
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-27 10:38 ---
We ICE in rename_use_op on
if (TREE_CODE (USE_FROM_PTR (op_p)) != SSA_NAME)
return;
because *op_p->use is NULL and the stmt is broken:
(gdb) call debug_generic_expr(op_p->stmt)
SMT.6D.1867_40 = PHI <(13)>;
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-27 10:16 ---
The vectorizer doesn't seem to handle differing types for COND_EXPRs. So
something along
*** tree-vect-transform.c (revision 113296)
--- tree-vect-transform.c (working copy)
*** vectorizable
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-27 09:58
---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
As
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-04-27 09:49
---
(In reply to comment #5)
> This bug is one of the issues preventing cp2k from compiling. I get this error
> in timings.f90:335.
This bug is still there. With mainline, on i686-linux, it seems to be the only
remai
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-27 09:44 ---
Note that loop information looks corrupt:
(gdb) print *loop
$2 = {num = 144085752, header = 0xb7fbb178, latch = 0xb7e4c3c0,
lpt_decision = {decision = LPT_NONE, times = 0}, ninsns = 0, av_ninsns = 0,
num_nodes
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-27 09:38 ---
Confirmed. Also with -O -funroll-loops (or -fpeel-loops, or -fprofile-use).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
extern void bar () __attribute__ ((noreturn));
inline double
baz (double *x, unsigned int y)
{
if (y >= 6)
bar ();
return x[y];
}
double *a, *b;
void
foo ()
{
unsigned int r, s, t;
for (r = 0; r < 2; r++)
for (t = 0; t < 2; t++)
{
for (s = 0; s < 3; s++)
--- Comment #8 from patchapp at dberlin dot org 2006-04-27 08:40 ---
Subject: Bug number PR25148
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01030.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #8 from burnus at net-b dot de 2006-04-27 08:09 ---
Subject: Re: gfortran: Warn/abort when format in write
does not fit passed arguments
(In reply to comment #7)
> Tobias, I hope this is what you were looking for. I don't really
think we need
> a compile time check. That
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-04-27
07:33 ---
thanks for pointing that out, my mistake to check that in. Mark, ok keep that
change and document that change in the existing changelog entry?
* Makefile.in (s-macro_list): Conform to POSIX rules in singl
92 matches
Mail list logo
