--- Comment #16 from rakdver at gcc dot gnu dot org 2007-06-17 06:38
---
(In reply to comment #12)
So this is now an enhancement request for sccp to honor loop roll count or
basic-block frequency and cost of the replacement.
we used to take the cost of the replacement into account.
--- Comment #2 from jb at gcc dot gnu dot org 2007-06-17 06:39 ---
Assigning to myself, this should be easy to fix.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-17 06:54 ---
Size of the compilers, efficiency of both compiler and generated code are
clearly secondary
Do you even know why I added POINTER_PLUS_EXPR? Did you even read my reply to
Jeff Law on why I started working on this
I'm getting the following ICE with trunk on x86_64. It compiles fine
on ia64 and powerpc.
(sid)2653:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2
mplayer-mpegvideo.c
mplayer-mpegvideo.c: In function 'MPV_encode_init':
mplayer-mpegvideo.c:21: internal compiler error: in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from rask at sygehus dot dk 2007-06-17 08:43 ---
I agree that the insn is invalid. It probably should be something like this:
(parallel [
(set (reg:PSI 7 fb)
(mem:PSI (reg:PSI 7 fb) [0 S4 A8]))
(set (reg:PSI 8 sp)
--- Comment #3 from ubizjak at gmail dot com 2007-06-17 08:53 ---
(In reply to comment #2)
i'm wondering if this could be related to a problem we're seeing with
segfaults
caused by misaligned movdqa instructions in zlib compiled with
-ftree-vectorize.
Please open a new bug for
--- Comment #4 from ubizjak at gmail dot com 2007-06-17 11:34 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01171.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from patchapp at dberlin dot org 2007-06-17 11:40 ---
Subject: Bug number PR32239
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/2007-06/msg01172.html
--
--- Comment #9 from spop at gcc dot gnu dot org 2007-06-17 13:38 ---
Subject: Re: [4.3 Regression] internal compiler error: in
build_polynomial_chrec, at tree-chrec.h:113
{{BinomialCoefficients[0], +, 4}_1, +, {0, +, 4}_1}_1
does not look good: the left part should be invariant in
--- Comment #2 from zadeck at naturalbridge dot com 2007-06-17 13:51
---
Subject: Re: [4.3 Regression] ICE in df_refs_verify
with -O2 -fmodulo-sched for spec tests
This patch fixes the df issues with modulo scheduling. It simply never
worked and was not tested because there is no
--- Comment #6 from zadeck at naturalbridge dot com 2007-06-17 14:01
---
Subject: Re: libgcc build failure, ICE in cselib_record_set,
at cselib.c:1508
rask at sygehus dot dk wrote:
--- Comment #5 from rask at sygehus dot dk 2007-06-17 08:43 ---
I agree that the insn is
gfortran -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -c k90.f90
Shows missed vectorization at source lines 125,332,380, 638
These problems appear to be associated with the EQUIVALENCE (source line 92),
which names one or more of the arrays involved.
--
Summary: not vectorized:
--- Comment #17 from rob1weld at aol dot com 2007-06-17 14:07 ---
Due to the bugs in mpfr ( http://www.mpfr.org/mpfr-2.2.1/#bugs ) we should
probably _require_ a recent version.
It would be kind of someone else to make that patch - I am kinda busy at the
moment. The section File:
--- Comment #1 from tprince at computer dot org 2007-06-17 14:11 ---
Created an attachment (id=13718)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13718action=view)
source code which reproduces problem with equivalence
This source code is derived from the public version posted at
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2007-06-17
14:14 ---
Subject: Re: [4.3 Regression] ICE in df_refs_verify
with -O2 -fmodulo-sched for spec tests
ok to commit?
Yes.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349
Current mainline GCC ICEs when compiling attached testcase:
g++ -O2 037.cpp
037.cpp: In function void unix_parse_conf_file(FILE*, const char*, bool):
037.cpp:58: error: insn does not satisfy its constraints:
(insn 50 45 10 2 (set (reg/f:DI 54 virtual-stack-vars)
(reg:DI 0 ax)) 82
--- Comment #1 from ubizjak at gmail dot com 2007-06-17 14:50 ---
Created an attachment (id=13719)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13719action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s414a.f
The source and destination sections of aa(:,:) do not overlap, unless there is
a subscript over-run. Even that case could be taken care of by loop reversal.
This is a simplification of a case from:
--- Comment #1 from tprince at computer dot org 2007-06-17 15:04 ---
Created an attachment (id=13720)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13720action=view)
source code test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32375
The original case from
http://www.netlib.org/benchmark/vectors
is split into 2 array assignments which should be easily vectorizable. The
first assignment, which starts at the base of the arrays, is vectorized. The
second assignment, which begins where the first left off, is not vectorized.
--
--- Comment #1 from tprince at computer dot org 2007-06-17 15:15 ---
Created an attachment (id=13721)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13721action=view)
source code test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32376
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s243.f
The first array assignment is vectorized. The second, which involves overlap
between source and destination, should be no problem to vectorize as long as
the loop is not reversed. Significant advantage should be gained by
--- Comment #1 from tprince at computer dot org 2007-06-17 15:26 ---
Created an attachment (id=13722)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13722action=view)
source code test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
--- Comment #5 from patchapp at dberlin dot org 2007-06-17 15:35 ---
Subject: Bug number PR32236
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/2007-06/msg01185.html
--
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s174.f
The two sections of the array are clearly distinct, so it should be vectorized.
--
Summary: can't determine dependence (distinct sections of an
array)
Product: gcc
--- Comment #1 from tprince at computer dot org 2007-06-17 15:36 ---
Created an attachment (id=13723)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13723action=view)
source code test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s112.f
The case could be vectorized by taking the array elements in reverse order (as
specified in the source).
ifort vectorizes by creating a temporary array (when the reversal is removed
from the source), losing performance.
--
--- Comment #1 from tprince at computer dot org 2007-06-17 15:45 ---
Created an attachment (id=13724)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13724action=view)
source code test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32379
gfortran -O2 -fcray-pointer -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v
unal.f
There are several reports of unsupported unaligned store or can't determine
dependence between .. The loops which report unaligned store vectorize OK
when taken in isolation.
The reports of can't determine
--- Comment #1 from tprince at computer dot org 2007-06-17 16:29 ---
Created an attachment (id=13725)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13725action=view)
source code test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32380
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-17 17:12
---
This is fixed somehow:
$ gfc pr25079.f90
pr25079.f90:5.5:
a=T0(1)
1
Error: The element in the derived type constructor at (1), for pointer
component 'i' should be a POINTER or a TARGET
--
jvdelisle at
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-17 17:32
---
{{BinomialCoefficients[0], +, 4}_1, +, {0, +, 4}_1}_1
does not look good: the left part should be invariant in loop_1.
It's most certainly the code in scev analysis that is in fault here.
I'll have a look.
--- Comment #4 from zadeck at gcc dot gnu dot org 2007-06-17 17:51 ---
Subject: Bug 32349
Author: zadeck
Date: Sun Jun 17 17:51:25 2007
New Revision: 125776
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125776
Log:
2007-06-17 Kenneth Zadeck [EMAIL PROTECTED]
PR
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-17 17:52
---
Subject: Re: [4.3 Regression] ICE in df_refs_verify
with -O2 -fmodulo-sched for spec tests
committed as revision 125776
Kenneth Zadeck wrote:
This patch fixes the df issues with modulo scheduling. It simply
--- Comment #6 from zadeck at naturalbridge dot com 2007-06-17 17:53
---
fixed as committed.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
--- Comment #14 from pault at gcc dot gnu dot org 2007-06-17 17:54 ---
A slight modification of the example in comment #2:
MODULE TEST
CONTAINS
FUNCTION s2a_3(s1) RESULT(a)
CHARACTER(LEN=*), INTENT(IN) :: s1
CHARACTER(LEN=LEN(s1)) :: a(3)
a(1)=s1
END FUNCTION
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-17 18:00 ---
Reduced testcase:
typedef long unsigned int size_t;
extern int *stderr;
void f(int *, const char *, ...);
void g (const char *conf_name)
{
typedef struct
{
const char *label;
--- Comment #9 from malitzke at metronets dot com 2007-06-17 18:01 ---
Thank you for your very informative post.
What we have between us is really a philosophical difference.
To me C is a portable assembler and my extensive review of Ritchie's writings
and acceptance speech for the
--- Comment #11 from spop at gcc dot gnu dot org 2007-06-17 19:13 ---
Subject: Re: [4.3 Regression] internal compiler error: in
build_polynomial_chrec, at tree-chrec.h:113
The ptrplus patch contains the following code:
*** interpret_rhs_modify_stmt (struct loop *
***
--- Comment #12 from spop at gcc dot gnu dot org 2007-06-17 19:16 ---
Subject: Re: [4.3 Regression] internal compiler error: in
build_polynomial_chrec, at tree-chrec.h:113
Ok, thanks. Just to let people know, {{BinomialCoefficients[0], +, 4}_1, +,
{0, +, 4}_1}_1 was also showing up
--- Comment #5 from uros at gcc dot gnu dot org 2007-06-17 19:23 ---
Subject: Bug 32366
Author: uros
Date: Sun Jun 17 19:23:30 2007
New Revision: 125777
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125777
Log:
PR rtl-optimization/32366
* simplify-rtx.c
This bug has been introduced by Paul Brook on 29/12/2005.
See the diffs here :
http://gcc.gnu.org/viewcvs/branches/gcc-4_2-branch/gcc/config/m68k/lb1sf68.asm?r1=109143r2=109145diff_format=h
It occurs when building some executables on m68k targets where
__USER_LABEL_PREFIX__ is not defined or not
--- Comment #1 from vincent dot riviere at freesbee dot fr 2007-06-17
20:03 ---
Created an attachment (id=13726)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13726action=view)
Correct call to SYM (__cmpsf2_internal)
The attached patch fixes this problem.
--
--- Comment #1 from zadeck at naturalbridge dot com 2007-06-17 20:13
---
Subject: Re: [4.3 Regression] ICE in df_lr_verify_transfer_functions,
at df-problems.c:1924
There are possibly two problems here. Fixing the first one fixes this ice.
The first problem is that after a call to
--- Comment #18 from rob1weld at aol dot com 2007-06-17 20:46 ---
Page: http://gcc.gnu.org/install/prerequisites.html says:
MPFR Library version 2.2.1 (or later)
Necessary to build GCC. It can be downloaded from http://www.mpfr.org/. The
version of MPFR that is bundled with GMP 4.1.x
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-17 20:47
---
I will explore this a bit. Its interesting.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from rob1weld at aol dot com 2007-06-17 20:52 ---
http://gcc.gnu.org/gcc-4.3/changes.html#mpfropts
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
This is a followup to BUG 32257.
Above Bug has been resolved as invalid, but how comes that
the loop variable i has the value 101 at the end of the read?
consider
C234567
program internalread
implicit none
integer m
CC parameter(m=100)
parameter(m=100)
--- Comment #12 from dfranke at gcc dot gnu dot org 2007-06-17 21:26
---
Forget the attempt to correct this given in comment #4.
Got something more useful :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-06-17 21:40
---
We have an extra:
(insn 39 38 40 t.f90:7 (parallel [
(set (reg:SI 73)
(ashift:SI (reg:SI 68 [ _s1 ])
(const_int 2 [0x2])))
(clobber (reg:CC 17 flags))
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-06-17 21:45
---
I was wrong in marking this as a middle-end issue.
We have:
char[0:D.1026][1:4] * __result.0;
char * temp.87;
...
temp.87 = (*__result.0)[0];
__builtin_memset (temp.87 + (unnamed-unsigned:32) _s1, 32, 4 -
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-06-17 22:08
---
Here is the fix which I am testing, basically instead of creating
(typeof(array[0] *)array we create array[lb]:
Index: trans.c
===
--- trans.c
The following code snippet triggers an ICE on mainline when compiled with
g++ -O -ffast-math:
=
struct A
{
~A();
};
double foo();
inline void bar (double d) { foo() /= d; }
void baz()
{
A a;
bar(2);
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32383
The following valid code snippet is rejected since GCC 3.4.0:
=
templatetypename struct A
{
typedef int T;
T foo();
A() { foo().~T(); }
};
Aint a;
=
The error message is:
bug.cc: In
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32384
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-06-17 23:21
---
Btw., the error message is:
bug.cc: In function 'void baz()':
bug.cc:10: internal compiler error: tree check: expected ssa_name, have
real_cst in execute_cse_reciprocals, at tree-ssa-math-opts.c:510
Please submit
The following code snippet triggers a segfault since GCC 4.0.0:
=
struct A
{
templateint void foo(int = ((struct { int i; }) {0}).i);
};
=
bug.cc:3: error: template
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3 regression] ICE with |[4.1/4.2/4.3 regression] ICE
|struct in default
--- Comment #10 from malitzke at metronets dot com 2007-06-17 23:29 ---
Let me reiterate: I am not admitted to the bar in any USA state, nor
the District of Columbia. Hence, I can not and I am not offering
any legal advice. For legal advice see a lawyer admitted to the bar.
Yes, I have
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-17 23:34
---
Actually no it does not, anyways the exception was written by lawyers. If you
want to change the exception, go talk to the FSF (and RMS) and not us as we
don't control the license.
--
pinskia at gcc dot gnu
--- Comment #7 from dannysmith at users dot sourceforge dot net 2007-06-17
23:40 ---
Fixed by:
2007-06-09 Vladimir Prus [EMAIL PROTECTED]
* files.c (open_file): Account for the
fact that on windows, opening a directory gives
EACCES.
--
dannysmith at users
--- Comment #12 from reichelt at gcc dot gnu dot org 2007-06-17 23:40
---
Andrew, Gaby's testcase from comment #4 gets an even worse diagnostic
since the merge of the ptr_plus stuff:
=
struct A
{
void foo();
};
struct B : virtual A
{
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-17 23:42
---
Would you mind having a look?
I was going to fix the pretty printing of pointer_plus_expr for C++ after I
returned from Japan. I already have a testcase which is better than the one
here.
--
--- Comment #12 from malitzke at metronets dot com 2007-06-18 00:06 ---
Did you even read comment 9?
--
malitzke at metronets dot com changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-18 00:26
---
Altivec and SSE really produce benefits in a relatively small corner of the
overal picture
Why do you think that? It is not true.
This is all getting offtopic from the original issue. The original question
The following program seems to me to be valid Fortran 95, because the f95
standard 5.1.1.5 and 7.1.6.2 say a CHARACTER(n) declaration is OK if n is a
scalar integer restricted expression, in which each primary is a constant,
the intrinsic LEN is allowed, and so are pure functions that are not
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-18 01:00
---
Not saying whether this is valid or not. However Intel ifort says:
fortcom: Error: john.f90, line 13: An automatic object is invalid in a main
program. [STRINGB]
CHARACTER(len(halfit(stringa))) :: stringb
--- Comment #2 from tprince at computer dot org 2007-06-18 01:36 ---
Performance change due to complete vectorization is not significant on Core 2
Duo. My apologies for submitting at normal priority.
--
tprince at computer dot org changed:
What|Removed
--- Comment #7 from jwakely dot gcc at gmail dot com 2007-06-18 01:36
---
Confirmed on x86-linux, sparc-solaris and ppc-AIX so I've removed the Target.
Also verified that valgrind shows the uninitialised memory reads.
This bug breaks common idioms like:
template typename A, typename
--- Comment #2 from tprince at computer dot org 2007-06-18 01:39 ---
Performance change for full vectorization is not significant on Core 2 Duo;
suggest reduced ;priority, apologies for submitting at normal severity
--
tprince at computer dot org changed:
What
--- Comment #2 from kargl at gcc dot gnu dot org 2007-06-18 01:46 ---
According to Lahey, the code is invalid.
Lahey/Fujitsu Fortran 95 Source Check Output
Compiling program unit halvestring at line 1:
Compiling program unit testspec at line 9:
2049-S: SOURCE.F90, line 13: Automatic
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2007-06-18 01:49
---
Patch tested OK on x86-64-Gnu-Linux.
I am also able to compile and run cp2k where before I was getting a segfault.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
Taking the exceptional backport of TPA to gcc-4.2.x I request studying the
possibility of doing the same for POINTER_PLUS.
--
Summary: back port POINTER_PLUS to gcc-4.2.1 on an exceptional
basis
Product: gcc
Version: 4.2.1
Status:
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-18 01:57 ---
delete_trivially_dead_insns is gone now that the dataflow branch has been
merged in. So closing as won't fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #36 from pinskia at gcc dot gnu dot org 2007-06-18 02:03
---
Just removing patch keyword as the patch is no longer applies after the
dataflow branch merge.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-18 02:05 ---
Any news on this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24429
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-18 02:16 ---
This has been working since 4.3.0 20070122 so closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-18 02:18 ---
This has been working since 4.3.0 20070131 so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-18 02:22 ---
I almost think we can declare this one as fixed. Richard, what do you think?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30175
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-18 02:24 ---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-18 02:27 ---
Unlike the TPA backport, pointer plus does not fix any regression (except from
3.4.0). Also it is a huge patch which is still going through some bug fixes
(C++ one and IV-OPTS one, and a SCEV one).
--
pinskia
--- Comment #3 from John dot Harper at mcs dot vuw dot ac dot nz
2007-06-18 02:42 ---
Subject: Re: Pure function not allowed in specification
expression
On Mon, 18 Jun 2007, jvdelisle at gcc dot gnu dot org wrote:
Date: 18 Jun 2007 01:00:47 -
From: jvdelisle at gcc dot gnu
--- Comment #4 from John dot Harper at mcs dot vuw dot ac dot nz
2007-06-18 02:44 ---
Subject: Re: Pure function not allowed in specification
expression
On Mon, 18 Jun 2007, kargl at gcc dot gnu dot org wrote:
Date: 18 Jun 2007 01:46:09 -
From: kargl at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-18 02:45 ---
t.f:10: note: not vectorized: possible dependence between data-refs
(*a_54(D))[S.13_17] and (*a_54(D))[D.1376_50]
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from malitzke at metronets dot com 2007-06-18 02:47 ---
I am not making this request lightheartedly.
POINTER_PLUS was developed on a branch and went in very cleanly.
I always stressed to my students that that A good theory is a most practical
thing I just happen to to a
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-18 02:50 ---
No pointer plus will make it worse. It changes so many non tested parts of GCC
it is not funny. I added like 5 testcases to the testsuite because we were not
testing those parts. The reason why 4.2 was bad is not
--- Comment #4 from malitzke at metronets dot com 2007-06-18 02:53 ---
I realize that good things do not come easy.
I also believe there is over-reliance on regression among the gcc-insiders.
Enhancement has a priority below trivial and I am jut requesting a study of an
enhancement.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-18 03:09 ---
The problem with the first one is that we don't pull out the load of spaces.n
from the loop which is dealing with common blocks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32373
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-18 03:13 ---
I think some of this is related to PR 32075.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from malitzke at metronets dot com 2007-06-18 03:15 ---
Hey, more good news about POINTER_PLUS. It might help smoke out bugs in other
parts of GCC. I hope these can be labeled as so called regressions so that
people will be forced to work on them.
Concerning
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-18 03:15 ---
I think some of this is related to PR 32075. (Looking into IR tells you that).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-18 03:19 ---
First you are crazy even in suggesting a back port. 4.2.x is feature frozen.
If you don't like that, use 4.3.0 (trunk) instead.
Yes it might show up other bugs in other places but that is the reason why they
are
The following Fortran 95 program gives the compile-time output below it:
[EMAIL PROTECTED] test system: ~/Jfh/Test 60 cat testdpconst.f90
PROGRAM testdpconst ! initialization sometimes /= assignment
INTEGER,PARAMETER :: long = selected_int_kind(15)
DOUBLE PRECISION :: dx = 2d0
PRINT
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-18 03:48 ---
Part of the problem is related to PR 32075. (Looking into IR tells you that).
The other part is loop reversal which I think still needs 32075 to be able to
reverse the loop.
We could do the loop reversal in the
--- Comment #1 from kargl at gcc dot gnu dot org 2007-06-18 03:50 ---
John,
This works for me with both a 4.2 and 4.3 (aka trunk, bleeding edge)
compilers. I think you'll find a much more pleasant gfortran
experience if you upgrade from 4.1.1..
--
kargl at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-18 03:56 ---
I see this in 4.1.2 but this has been fixed already in 4.2.0.
So closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-18 04:12
---
From Fortran 95/2003 Explained, Metcalf. Reid, and Cohen
Page 101:
The other way that automatic objects arise is through varying character
length. The variable word2 in
Subroutine example(word1)
1 - 100 of 112 matches
Mail list logo
