--- Comment #12 from marcus at jet dot franken dot de 2008-02-16 08:45
---
i configure gcc with just --enable-languages=cso whatever is currently the
default.
btw, today it builds without too deep recursion again :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
--- Comment #13 from steven at gcc dot gnu dot org 2008-02-16 09:33 ---
Re. comment #8
You can't terminate the DFS before a complete SCC is found, it will break the
correctness of the SCC-VN algorithm. You'd start another DFS from a
not-yet-marked SSA name that is in the SCC's DFS
--- Comment #14 from steven at gcc dot gnu dot org 2008-02-16 09:40 ---
For those who have no idea what we're talking about, check out these links.
The first link is Tarjan's algorithm, which is what the tree-ssa-sccvn.c
SCC-finder is based on. The second link is Pearce's improved
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-16 10:54 ---
Happens only with checking enabled. Honza, can you have a look here?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-02-16 10:41
---
re comment #13 - limiting the DFS walk depth will of course only work if we
then abort SCCVN completely (like we do for the SCC size limit). But still
finding a magic number that fixes only the case where we blow
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-16 10:45 ---
Confirmed. Fails since this is a valid program.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-02-16 11:23
---
The problem with doing a non-recursive version of DFS as for GCC SCCVN is to
split the FOR_EACH_PHI_OR_STMT_USE walk. You would need to open-code this
and keep a stack of ssa_op_iters, ugly but certainly not
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-02-16 12:11
---
Created an attachment (id=15167)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15167action=view)
patch that still needs some love
Something like this?
--
rguenth at gcc dot gnu dot org changed:
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-02-16 12:49
---
Created an attachment (id=15168)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15168action=view)
patch
Patch which got some minimal testing and love.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-02-16 12:51
---
Note that while it definitely improves stack usage, the total memory usage is
likely to go up (vectors allocate some extra heap, the iters are now
addressable
and thus consume full memory) and as the ssa_op_iter
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from tuttle at sandbox dot cz 2008-02-16 14:12 ---
I think we could generalize a bit: This in fact is not bound to if-statement or
code reachability.
Tried the following with snapshot gcc-4.3-20080215 -Wextra -Wall
-Wunreachable-code.
#include stdio.h
int main()
{
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-02-16 14:10
---
Subject: Bug 34952
Author: fxcoudert
Date: Sat Feb 16 14:10:12 2008
New Revision: 132366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132366
Log:
PR fortran/34952
* gfortran.texi: Create
--- Comment #20 from dberlin at gcc dot gnu dot org 2008-02-16 14:56
---
Subject: Re: [4.3 Regression] crash by too deep recursion in DFS
tree-ssa-sccvn.c:1898
So, there are better SCC algorithms.
In particular, Nuutilla's algorithm will avoid placing a bunch of
nodes on the stack
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-02-16 14:12
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-02-16 15:22
---
The patch only avoids using the stack in favor of maintaining heap allocated
stacks. The algorithm is still recursively walking the graph.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
--- Comment #8 from manu at gcc dot gnu dot org 2008-02-16 16:29 ---
Subject: Bug 28368
Author: manu
Date: Sat Feb 16 16:29:12 2008
New Revision: 132367
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132367
Log:
2008-02-16 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
The TestClosureGC.jar execution - gij test case has regressed in gcc trunk on
i686-apple-darwin9.
set_ld_library_path_env_vars:
ld_library_path=.:/sw/src/fink.build/gcc43-4.2.999-20080215/darwin_objdir/i686-apple-darwin9/./libjava/.libs
invoke:
--- Comment #14 from nightstrike at gmail dot com 2008-02-16 17:22 ---
edited title to reflect gfortran failure, as well.
--
nightstrike at gmail dot com changed:
What|Removed |Added
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-02-16
16:55 ---
My mistake. The last tested revision without the testcase failure is actually
130547.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35217
Szia!
Emlékszel amikor arról beszéltem hogy meg fog nyílni Magyarország legjobb
letöltõ oldala?
Na, ha igen, akkor itt a link. Jó szorakozást! :)
http://href.hu/x/4pnj
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-02-16 16:46
---
There are a dozen or two places where we create local temporaries of type
gfc_typespec but we do not call gfc_clear_ts before using it. This leaves
things potentially uninitialized depending on how it is used.
--- Comment #7 from tuttle at sandbox dot cz 2008-02-16 18:09 ---
That's great, even my older gcc 4.1.3 warns for every if-body with -O1
-Wunreachable code. Shame on me I did not came with -O1 myself, sorry.
Anyway my first code line
int var1 = (1 0);
is not about the execution
--- Comment #1 from eric dot weddington at atmel dot com 2008-02-16 18:14
---
Note that this was built with unpatched FSF sources and is configured with:
../gcc-$version/configure \
--with-pkgversion=WinAVR $release \
--- Comment #9 from manu at gcc dot gnu dot org 2008-02-16 18:16 ---
Subject: Bug 28368
Author: manu
Date: Sat Feb 16 18:15:20 2008
New Revision: 132368
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132368
Log:
2008-02-16 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #8 from manu at gcc dot gnu dot org 2008-02-16 18:16 ---
Closing. Thanks for the report anyway.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from astrange at ithinksw dot com 2008-02-16 18:16 ---
Also, 'x 32 - y' can be transformed into 'x -y', since x86 only uses the
lowest 5 bits. I'm not sure about other targets.
Messing with the backend doesn't seem very popular these days. I guess I should
figure out
Hi!
The following programs are built like this:
gfortran -c zdotu.f -ggdb
g++ -c ztest.cpp -ggdb
g++ -o ztest zdotu.o ztest.o
The generated ztest segfaults on ARM on line 37 of zdotu.f with SIGSEGV, while
it is perfect on other arches.
Thanks!
Kumar
zdotu.f
---
DOUBLE COMPLEX
--- Comment #10 from manu at gcc dot gnu dot org 2008-02-16 18:20 ---
The new description in GCC 4.3 and GCC 4.2.4 should clarify this from now on.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2008-02-16 18:50
---
Thomas is right: -fcx-limited-range sets flag_complex_method to 0, but already
with flag_complex_method == 1 we have some rather good figures. Here are the
execution times of 300x300 matmul on my MacBook Pro
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-02-16 18:51
---
*** This bug has been marked as a duplicate of 35219 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-02-16 18:51
---
*** Bug 35220 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35219
--- Comment #147 from pault at gcc dot gnu dot org 2008-02-16 18:54 ---
(In reply to comment #146)
(In reply to comment #145)
current gfortran trunk seems to fail on CVS sources of CP2K with:
PR34946
Joost - can this be closed again?
Cheers
Paul
--
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2008-02-16 19:00
---
The Makefile.am part was messed up by my terminal:
Index: libgfortran/Makefile.am
===
--- libgfortran/Makefile.am (revision 132353)
+++
--- Comment #4 from skunk at iskunk dot org 2008-02-16 18:42 ---
Argh... now I see what's going on here.
$ grep glibcxx_toolexeclibdir.= alphaev56-dec-osf4.0g/libstdc++-v3/src/Makefile
glibcxx_toolexeclibdir = ${toolexecdir}/${gcc_version}$(MULTISUBDIR)
$ grep gcc_version.:=
The 4.3 20080215 snapshot fails to build for the AVR. Last weeks snapshot
20080208 builds fine for the AVR.
Make log:
cat ../../gcc-4.3-20080215/gcc/config/fp-bit.c fp-bit.c
(echo @set version-GCC 4.3.0; \
if [ experimental = experimental ]; \
then echo @set DEVELOPMENT; \
else echo @clear
--- Comment #4 from skunk at iskunk dot org 2008-02-16 18:42 ---
*** Bug 35197 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35199
--- Comment #6 from manu at gcc dot gnu dot org 2008-02-16 17:50 ---
Please do not expect a compilable testcase from me. 1) I don't know whether
this is a bug, 2) have no experience in gcc testcases.
The above is a testcase. See http://gcc.gnu.org/bugs.html#report on how to make
a
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-02-16 18:22
---
Here is the culprit:
Index: iresolve.c
===
--- iresolve.c (revision 132355)
+++ iresolve.c (working copy)
@@ -585,6 +585,7 @@ gfc_resolve_cshift
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-16 19:07 ---
cdouble zdotu_
Will never work as cdouble is a struct and the way it will returned is
different from _Complex double and fortran's complex.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Hi!
The following programs are built like this:
gfortran -c zdotu.f -ggdb
g++ -c ztest.cpp -ggdb
g++ -o ztest zdotu.o ztest.o
The generated ztest segfaults on ARM on line 37 of zdotu.f with SIGSEGV, while
it is perfect on other arches.
Thanks!
Kumar
zdotu.f
---
DOUBLE COMPLEX
--- Comment #11 from starlight at binnacle dot cx 2008-02-16 19:28 ---
Also fails with GCC 4.2.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258
--- Comment #3 from pcarlini at suse dot de 2008-02-16 19:34 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #15 from ktietz at gcc dot gnu dot org 2008-02-16 19:50 ---
(In reply to comment #10)
(In reply to comment #8)
I tested this already and it didn't solved the problem. But may +a is more
correct.
Perhaps setting RTX_FRAME_RELATED_P is needed? Or gen_blockage() at some
--
astrange at ithinksw dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32593
--
astrange at ithinksw dot com changed:
What|Removed |Added
Severity|minor |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33555
--- Comment #3 from ktietz at gcc dot gnu dot org 2008-02-16 20:46 ---
Yes, for the x86_64-pc-mingw32 the %ld printing exists, but it is for long, not
for long long. For this target long is 32-bit scalar, so the printf formatters
are wrong.
in gthr-win32.h there seems to be a more
--- Comment #1 from jb at gcc dot gnu dot org 2008-02-16 21:47 ---
CC:ing jsm to confirm this bug as people on IRC tell me you're the person that
knows about complex in C99. :)
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-02-16 21:58 ---
Actually the middle-end parts are ok for 4.4 if you add proper documentation
for
the flag. But please post it once stage1 opens.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29549
--- Comment #1 from hutchinsonandy at aim dot com 2008-02-16 22:06 ---
Created an attachment (id=15169)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15169action=view)
Patch
The attached patch allows function address expressions of the form address+k
to be correctly recognized as
--- Comment #2 from j at uriah dot heep dot sax dot de 2008-02-16 22:20
---
I've got no troubles building today's SVN snapshot.
I don't know exactly how GCC's Makefile infrastructure is working, but
maybe libiberty/Makefile.in:
TEXISRC = \
$(srcdir)/libiberty.texi \
/export/data/devel-test/gcc-svn/objdir/sparc-sun-solaris2.8/libstdc++-v3/include/parallel/types.h:74:
error: 'std::tr1' has not been declared
Most probably due to this ci:
http://gcc.gnu.org/ml/gcc-cvs/2008-02/msg00368.html
Broken on sparc-sun-solaris2.8, and at least on 32-bit and 64-bit hpux
--- Comment #10 from jb at gcc dot gnu dot org 2008-02-16 22:33 ---
Actually, we could compile the entire libgfortran with -fcx-fortran-rules as
well:
Index: Makefile.am
===
--- Makefile.am (revision 132367)
+++
--- Comment #5 from jb at gcc dot gnu dot org 2008-02-16 22:40 ---
Still occurs with
4.3.0 20080216 (experimental) [trunk revision 132367]
i.e. only the first procedure (testvectdp) vectorizes, and that only with
-ffast-math.
--
jb at gcc dot gnu dot org changed
The link command for libstdc++.sl.6.10 fails:
libtool: link: /xxx/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc
-B/xxx/gnu/gcc/objdir/./gcc -nostdinc++
-L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/src
-L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++-v3/src/.libs
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|regression |bootstrap
Keywords||build
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-16 23:18 ---
Benjamin, why this late changes shortly before the release?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from eric dot weddington at atmel dot com 2008-02-16 23:36
---
I checked and I have at-file.texi in the distributions of both 20080208 and
20080215 snapshots. Located under /libiberty.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35218
--- Comment #1 from danglin at gcc dot gnu dot org 2008-02-16 23:37 ---
Breakpoint 3, dw2_asm_output_encoded_addr_rtx (encoding=0, addr=0x7ab0fdd0,
public=0 '\000', comment=0x5792c FDE initial location)
at ../../gcc/gcc/dwarf2asm.c:841
841 if (encoding == DW_EH_PE_aligned)
--- Comment #4 from paolo at gcc dot gnu dot org 2008-02-16 23:40 ---
Subject: Bug 35209
Author: paolo
Date: Sat Feb 16 23:39:56 2008
New Revision: 132372
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132372
Log:
2008-02-17 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #5 from pcarlini at suse dot de 2008-02-16 23:41 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
hades [TEST] cat bug-ibits.f90
program main
write (*, *) ibits (-1, 0, bit_size (0))
end program main
hades [TEST] gfortran bug-ibits.f90
bug-ibits.f90:2.22:
write (*, *) ibits (-1, 0, bit_size (0))
1
Error: Result of IBITS overflows its kind at (1)
hades [TEST]
--- Comment #1 from jvdelisle at verizon dot net 2008-02-17 00:21 ---
Subject: Re: New: IBITS gives compiler error
phl at kth dot se wrote:
hades [TEST] cat bug-ibits.f90
program main
write (*, *) ibits (-1, 0, bit_size (0))
end program main
hades [TEST] gfortran
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from kargl at gcc dot gnu dot org 2008-02-17 01:08 ---
(In reply to comment #0)
hades [TEST] cat bug-ibits.f90
program main
write (*, *) ibits (-1, 0, bit_size (0))
end program main
(snip)
What result do you expect?
Compiling with g95 works fine though.
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-02-17 01:19
---
I will be working pn this and have a strat in my local experimental branch
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-17
03:29 ---
Subject: Re: [4.3 Regression] EH output contains procedure label without P'
selector
The encoding seems wrong. Expected DW_EH_PE_aligned.
Actually, the encoding is correct. The procedure label error
--- Comment #6 from pmarques at grupopie dot com 2008-02-17 03:58 ---
Created an attachment (id=15171)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15171action=view)
patch to fix testsuite breakage on 16 bit integer targets
Unfortunately, the testcase assumes 32 bit integers and
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-02-17 04:11
---
Two questions on this PR.
Is there really anything on the gfortran side we can do to make this better or
is it really a middle-end / back-end issue?
Can we close this pr or change the component to other than
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-02-17 04:44
---
I want to get this on my radar.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-02-17 05:02
---
Keep this PR in mind while doing this. PR34705
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from phl at kth dot se 2008-02-17 05:18 ---
Subject: Re: IBITS gives compiler error
--- Comment #2 from kargl at gcc dot gnu dot org 2008-02-17 01:08
---
(In reply to comment #0)
hades [TEST] cat bug-ibits.f90
program main
write (*, *) ibits (-1, 0,
--- Comment #4 from kargl at gcc dot gnu dot org 2008-02-17 06:38 ---
(In reply to comment #3)
Subject: Re: IBITS gives compiler error
--- Comment #2 from kargl at gcc dot gnu dot org 2008-02-17 01:08
---
(In reply to comment #0)
hades [TEST] cat bug-ibits.f90
For the following scalar evolution analysis fails with evolution of base is
not affine:
for (i__ = 1; i__ = i__2; ++i__)
{
a[i__] = (b[i__] + b[im1] + b[im2]) * .333f;
im2 = im1;
im1 = i__;
}
--
Summary: scalar evolution analysis fails
74 matches
Mail list logo
