[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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 subtree, but you won't find the comoplete SCC. I have no idea exactly what would happen, but I'm sure it would be something bad ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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 algorithm. Ref. 6 from that paper is also of interest. http://en.wikipedia.org/wiki/Tarjan's_strongly_connected_components_algorithm http://www.mcs.vuw.ac.nz/~djp/files/P05.pdf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35215] ICE: verify_histograms failed with -fprofile-use
--- 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 CC||hubicka at gcc dot gnu dot ||org Component|tree-optimization |middle-end Keywords||ice-checking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35215
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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 the stack is hard ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug libstdc++/35209] __gnu_cxx::stdio_sync_filebuf constructor isn't exported by the DSO
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.6 Last reconfirmed|-00-00 00:00:00 |2008-02-16 10:45:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35209
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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 impossible. Steven, did you try something along this route? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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=15167&action=view) patch that still needs some love Something like this? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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=15168&action=view) patch Patch which got some minimal testing and love. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #15167|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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 is now pinned to memory it is likely the algorithm is slower as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug fortran/35156] [patch] Deprecate -M
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-16 14:28:39 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35156
[Bug middle-end/35188] Missing a warning: inherently false expressions
--- 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
int main()
{
int var1 = (1 && 0); /* does not warn */
printf("var1 = %d\n", var1); /* outputs: var1 = 0 */
if ( 0 && 1 )
printf("FIRST\n"); /* warns ok: printf unreachable */
if ( 0 && (var1 == 10) )
printf("SECOND\n"); /* warns ok: printf unreachable */
if ( (var1 == 10) && (var1 == 20) )
printf("THIRD\n"); /* does not warn */
return 0;
}
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.
I just tried to provide an idea.
With deep respect,
Vlada Macek
--
tuttle at sandbox dot cz changed:
What|Removed |Added
Summary|Missing a warning: if- |Missing a warning:
|condition is inherently |inherently false expressions
|blocking the if-body|
Version|4.1.3 |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35188
[Bug fortran/34952] Document lack of support for ENCODE/DECODE
--- 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=gcc&view=rev&rev=132366 Log: PR fortran/34952 * gfortran.texi: Create new section for unimplemented extensions. Add "STRUCTURE and RECORD" and "ENCODE and DECODE statements". Remove "smaller projects" list. Fix a few typos. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34952
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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 (pearce's is a modification of this). This is what structalias uses. You can also certainly make the algorithm non-recursive, but it is a bunch of work. See http://www.cise.ufl.edu/research/sparse/btf/BTF/Source/btf_strongcomp.c for an example of a non-recursive SCC finder. In essence, you have to keep stacks for each variable. On 16 Feb 2008 12:51:44 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- 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 is now pinned to memory > it is likely the algorithm is slower as well. > > > -- > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug fortran/34952] Document lack of support for ENCODE/DECODE
--- 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 |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34952
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- 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
[Bug c/28368] -std=c89 doesn't warn about gcc's "?:" extension
--- 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=gcc&view=rev&rev=132367 Log: 2008-02-16 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR c/28368 * doc/invoke.texi (-std): Clarify description of -std= and -ansi. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28368
[Bug java/35217] New: TestClosureGC.jar execution - gij test regression on i686-apple-darwin9
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: /sw/src/fink.build/gcc43-4.2.999-20080215/darwin_objdir/i686-apple-darwin9/./libjava/gij -jar /sw/src/fink.build/gcc43-4.2.999-20080215/gcc-4.3-20080215/libjava/testsuite/libjava.ja r/TestClosureGC.jar Setting LD_LIBRARY_PATH to .:/sw/src/fink.build/gcc43-4.2.999-20080215/darwin_objdir/i686-apple-darwin9/./libjava/.libs:.:/sw/src/fink.build/gcc43-4.2.999-20080215/darwin_objdir/i686-apple-darwin9/./libjava/.libs:/usr/local/NMRPipe/xview/mac/lib:/usr/openwin/lib:/usr/local/NMRPipe/nmrbin.mac/lib:/usr/local/lib FAIL: /sw/src/fink.build/gcc43-4.2.999-20080215/gcc-4.3-20080215/libjava/testsuite/libjava.jar/TestClosureGC.jar execution - gij test UNTESTED: /sw/src/fink.build/gcc43-4.2.999-20080215/gcc-4.3-20080215/libjava/testsuite/libjava.jar/TestClosureGC.jar output - gij test Last tested good revision was 130748. Test case fails by revision 130775. -- Summary: TestClosureGC.jar execution - gij test regression on i686-apple-darwin9 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35217
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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 Summary|g++ inoperable with no error|g++ and gfortran inoperable |message |with no error message http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug java/35217] TestClosureGC.jar execution - gij test regression on i686-apple-darwin9
--- 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
iNGYEN LETOLTES!
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
[Bug fortran/34907] valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec
--- 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. We should probably just go through and initialize them all for good measure. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-21 23:26:50 |2008-02-16 16:46:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34907
[Bug middle-end/35188] Missing a warning: inherently false expressions
--- 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 reachability. It may be considered as a simplest form of inherently false expressions such as ( (var==10) && (var==20) ) that I would consider good to produce warnings. But that would AFAIK need a completely new kind of warnings (as well as checking code?). Sorry for bugging everybody with such minor thing. Feel free to close the bug. VM -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35188
[Bug regression/35218] [4.3 regression] 4.3 20080215 snapshot build failure
--- 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" \ --with-bugurl="URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse"; \ --enable-win32-registry=WinAVR-$release \ --with-gmp=/usr/local \ --with-mpfr=/usr/local \ --prefix=$installdir \ --target=$target \ --enable-languages=$lang \ --with-dwarf2 \ --disable-nls \ --enable-doc \ --disable-shared \ --disable-libada \ --disable-libssp \ 2>&1 | tee $package-configure.log $lang in this case was just "c". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35218
[Bug c/28368] -std=c89 doesn't warn about gcc's "?:" extension
--- 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=gcc&view=rev&rev=132368 Log: 2008-02-16 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR c/28368 * doc/invoke.texi (-std): Clarify description of -std= and -ansi. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28368
[Bug middle-end/35188] Missing a warning: inherently false expressions
--- 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 Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35188
[Bug target/32593] Missed optimization of 'y = constant - x' operation
--- 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 how those parts work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32593
[Bug fortran/35219] New: zdotu (copy of BLAS version) works in x86, x86_64, segfaults in arm.
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 FUNCTION ZDOTU(N,ZX,INCX,ZY,INCY)
* .. Scalar Arguments ..
INTEGER INCX,INCY,N
* ..
* .. Array Arguments ..
DOUBLE COMPLEX ZX(*),ZY(*)
* ..
*
* Purpose
* ===
*
* ZDOTU forms the dot product of two vectors.
*
* Further Details
* ===
*
* jack dongarra, 3/11/78.
* modified 12/3/93, array(1) declarations changed to array(*)
*
* .. Local Scalars ..
DOUBLE COMPLEX ZTEMP
INTEGER I,IX,IY
* ..
ZTEMP = (0.0d0,0.0d0)
ZDOTU = (0.0d0,0.0d0)
IF (N.LE.0) RETURN
IF (INCX.EQ.1 .AND. INCY.EQ.1) GO TO 20
*
*code for unequal increments or equal increments
* not equal to 1
*
IX = 1
IY = 1
IF (INCX.LT.0) IX = (-N+1)*INCX + 1
IF (INCY.LT.0) IY = (-N+1)*INCY + 1
DO 10 I = 1,N
ZTEMP = ZTEMP + ZX(IX)*ZY(IY)
IX = IX + INCX
IY = IY + INCY
10 CONTINUE
ZDOTU = ZTEMP
RETURN
*
*code for both increments equal to 1
*
20 DO 30 I = 1,N
ZTEMP = ZTEMP + ZX(I)*ZY(I)
30 CONTINUE
ZDOTU = ZTEMP
RETURN
END
ztest.cpp
-
#include
typedef std::complex cdouble;
extern "C" {
cdouble zdotu_(const int *, const cdouble *, const int *,
const cdouble *, const int *);
}
int main() {
int incr = 1;
int size = 6;
cdouble a[] = {cdouble( 0.7219, 0.8871), cdouble( 0.7073,-0.7953),
cdouble( 0.2610, 0.4325), cdouble(-0.0565,-0.0719),
cdouble( 0.7277,-0.9754), cdouble(-0.3780, 1.0718)};
cdouble b[] = {cdouble(-0.0821,+0.8410), cdouble(-0.0749, 0.0729),
cdouble(-0.6094,-0.2975), cdouble( 0.2106,-0.2026),
cdouble( 0.1043,-0.8300), cdouble( 0.0806, 0.3698)};
cdouble x_ref(-2.01767031,-0.45861365);
cdouble x = zdotu_(&size, a, &incr, b, &incr);
return (std::abs(x - x_ref) < 1e-6) ? 0 : 1;
}
--
Summary: zdotu (copy of BLAS version) works in x86, x86_64,
segfaults in arm.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akumar at ee dot iitm dot ac dot in
GCC build triplet: arm-linux-gnu
GCC host triplet: arm-linux-gnu
GCC target triplet: arm-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35219
[Bug c/28368] -std=c89 doesn't warn about gcc's "?:" extension
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28368
[Bug fortran/29549] matmul slow for complex matrices
--- 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 (i386-apple-darwin8.11.1): - a home-made triple do loop in Fortran (Janne's comment #2) is 0.1876 sec - unpatched matmul is 0.5499 sec - matmul compiled with flag_complex_method == 1 is 0.1448 sec The following patch is what I used to benchmark: it creates a -fcx-fortran-rules (of course, we do know that Fortran actually rules, but hiding it in an option name is a clever way for people to slowly start realizing it) option that sets flag_complex_method to 1, and uses it to compile libgfortran's matmul routines. Index: gcc/toplev.c === --- gcc/toplev.c(revision 132353) +++ gcc/toplev.c(working copy) @@ -2001,6 +2001,10 @@ if (flag_cx_limited_range) flag_complex_method = 0; + /* With -fcx-fortran-rules, we do something in-between cheap and C99. */ + if (flag_cx_fortran_rules) +flag_complex_method = 1; + /* Targets must be able to place spill slots at lower addresses. If the target already uses a soft frame pointer, the transition is trivial. */ if (!FRAME_GROWS_DOWNWARD && flag_stack_protect) Index: gcc/common.opt === --- gcc/common.opt (revision 132353) +++ gcc/common.opt (working copy) @@ -390,6 +390,10 @@ Common Report Var(flag_cx_limited_range) Optimization Omit range reduction step when performing complex division +fcx-fortran-rules +Common Report Var(flag_cx_fortran_rules) Optimization +Complex multiplication and division follow Fortran rules + fdata-sections Common Report Var(flag_data_sections) Optimization Place data items into their own section Index: libgfortran/Makefile.am === --- libgfortran/Makefile.am (revision 132353) +++ libgfortran/Makefile.am (working copy) @@ -636,7 +636,7 @@ install-pdf: # Turn on vectorization and loop unrolling for matmul. -$(patsubst %.c,%.lo,$(notdir $(i_matmul_c))): AM_CFLAGS += -ftree-vectorize -fs +$(patsubst %.c,%.lo,$(notdir $(i_matmul_c))): AM_CFLAGS += -ftree-vectorize -fs # Logical matmul doesn't vectorize. $(patsubst %.c,%.lo,$(notdir $(i_matmull_c))): AM_CFLAGS += -funroll-loops -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29549
[Bug fortran/35220] zdotu (copy of BLAS version) works in x86, x86_64, segfaults in arm.
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35220
[Bug fortran/35219] zdotu (copy of BLAS version) works in x86, x86_64, segfaults in arm.
--- 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
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29549] matmul slow for complex matrices
--- 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) +++ libgfortran/Makefile.am (working copy) @@ -636,7 +636,7 @@ install-pdf: # Turn on vectorization and loop unrolling for matmul. -$(patsubst %.c,%.lo,$(notdir $(i_matmul_c))): AM_CFLAGS += -ftree-vectorize -funroll-loops +$(patsubst %.c,%.lo,$(notdir $(i_matmul_c))): AM_CFLAGS += -ftree-vectorize -funroll-loops -fcx-fortran-rules # Logical matmul doesn't vectorize. $(patsubst %.c,%.lo,$(notdir $(i_matmull_c))): AM_CFLAGS += -funroll-loops -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29549
[Bug libstdc++/35197] Native linker can't locate file for -lstdc++ with --enable-version-specific-runtime-libs
--- 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.:= alphaev56-dec-osf4.0g/libstdc++-v3/src/Makefile
gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
This is another manifestation of bug #35199. I'll update my patch to cover this
instance of $(shell cat /path/to/BASE-VER), and any others in the tree.
Sorry for the trouble, gentlemen.
*** This bug has been marked as a duplicate of 35199 ***
--
skunk at iskunk dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35197
[Bug regression/35218] New: [4.3 regression] 4.3 20080215 snapshot build failure
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 DEVELOPMENT"; \
fi) > gcc-vers.texiT
echo "@set srcdir /c/avrdev/gcc/build/gcc/../../gcc-4.3-20080215/gcc" >>
gcc-vers.texiT
if [ -n "(WinAVR 20080222) " ]; then \
echo "@set VERSION_PACKAGE (WinAVR 20080222) " >> gcc-vers.texiT; \
fi
echo "@set BUGURL
@uref{URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse}";
>> gcc-vers.texiT; \
mv -f gcc-vers.texiT gcc-vers.texi
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500 --no-split -I . -I
../../gcc-4.3-20080215/gcc/doc \
-I ../../gcc-4.3-20080215/gcc/doc/include -o doc/cpp.info
../../gcc-4.3-20080215/gcc/doc/cpp.texi; \
fi
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500 --no-split -I . -I
../../gcc-4.3-20080215/gcc/doc \
-I ../../gcc-4.3-20080215/gcc/doc/include -o doc/gcc.info
../../gcc-4.3-20080215/gcc/doc/gcc.texi; \
fi
../../gcc-4.3-20080215/gcc/doc//invoke.texi:1243: @include
`/c/avrdev/gcc/build/gcc/../../gcc-4.3-20080215/gcc/../libiberty/at-file.texi':
No such file or directory.
makeinfo: Removing output file `doc/gcc.info' due to errors; use --force to
preserve.
make[2]: *** [doc/gcc.info] Error 2
make[2]: Leaving directory `/c/avrdev/gcc/build/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/c/avrdev/gcc/build'
make: *** [all] Error 2
--
Summary: [4.3 regression] 4.3 20080215 snapshot build failure
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot weddington at atmel dot com
GCC host triplet: mingw
GCC target triplet: avr-*.*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35218
[Bug bootstrap/35199] [PATCH] Check for valid value of BASEVER
--- 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
[Bug middle-end/35188] Missing a warning: inherently false expressions
--- 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 good report.
A more self-contained and complete testcase follows:
extern void abort(void);
void foo(int var2)
{
int var1 = 0;
if (0 && 1)
abort ();
if (0 && var1 == 10)
abort ();
if (var1 == 10 && var1 == 20)
abort ();
if (var1 == 10)
if (var1 == 20)
abort ();
if (var2 == 10 && var2 == 20)
abort ();
if (var2 == 10)
if (var2 == 20)
abort ();
}
The above gives with -Wunreachable-code -O0
/home/manuel/src/pr35188.c:8: warning: will never be executed
/home/manuel/src/pr35188.c:11: warning: will never be executed
And with -Wunreachable-code -O1
/home/manuel/src/pr35188.c: In function foo:
/home/manuel/src/pr35188.c:8: warning: will never be executed
/home/manuel/src/pr35188.c:11: warning: will never be executed
/home/manuel/src/pr35188.c:14: warning: will never be executed
/home/manuel/src/pr35188.c:21: warning: will never be executed
Performing interprocedural optimizations
/home/manuel/src/pr35188.c:17: warning: will never be executed
/home/manuel/src/pr35188.c:18: warning: will never be executed
Assembling functions:
foo
/home/manuel/src/pr35188.c: In function foo:
/home/manuel/src/pr35188.c:25: warning: will never be executed
So, it is jut that without optimizations enabled, GCC does not know that (var
== 1 && var == 2) is always false and hence it does not consider the code
unreachable.
I am inclined to close this as WONTFIX.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35188
[Bug fortran/34907] valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec
--- 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 (gfc_expr *f, gfc_exp
if (shift->ts.kind < m)
{
gfc_typespec ts;
+ gfc_clear_ts (&ts);
ts.type = BT_INTEGER;
ts.kind = m;
gfc_convert_type_warn (shift, &ts, 2, 0);
This fixes it. There are a bunch of these in iresolve.c I will fix them all
for 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34907
[Bug fortran/35219] zdotu (copy of BLAS version) works in x86, x86_64, segfaults in arm.
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35219
[Bug fortran/35220] New: zdotu (copy of BLAS version) works in x86, x86_64, segfaults in arm.
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 FUNCTION ZDOTU(N,ZX,INCX,ZY,INCY)
* .. Scalar Arguments ..
INTEGER INCX,INCY,N
* ..
* .. Array Arguments ..
DOUBLE COMPLEX ZX(*),ZY(*)
* ..
*
* Purpose
* ===
*
* ZDOTU forms the dot product of two vectors.
*
* Further Details
* ===
*
* jack dongarra, 3/11/78.
* modified 12/3/93, array(1) declarations changed to array(*)
*
* .. Local Scalars ..
DOUBLE COMPLEX ZTEMP
INTEGER I,IX,IY
* ..
ZTEMP = (0.0d0,0.0d0)
ZDOTU = (0.0d0,0.0d0)
IF (N.LE.0) RETURN
IF (INCX.EQ.1 .AND. INCY.EQ.1) GO TO 20
*
*code for unequal increments or equal increments
* not equal to 1
*
IX = 1
IY = 1
IF (INCX.LT.0) IX = (-N+1)*INCX + 1
IF (INCY.LT.0) IY = (-N+1)*INCY + 1
DO 10 I = 1,N
ZTEMP = ZTEMP + ZX(IX)*ZY(IY)
IX = IX + INCX
IY = IY + INCY
10 CONTINUE
ZDOTU = ZTEMP
RETURN
*
*code for both increments equal to 1
*
20 DO 30 I = 1,N
ZTEMP = ZTEMP + ZX(I)*ZY(I)
30 CONTINUE
ZDOTU = ZTEMP
RETURN
END
ztest.cpp
-
#include
typedef std::complex cdouble;
extern "C" {
cdouble zdotu_(const int *, const cdouble *, const int *,
const cdouble *, const int *);
}
int main() {
int incr = 1;
int size = 6;
cdouble a[] = {cdouble( 0.7219, 0.8871), cdouble( 0.7073,-0.7953),
cdouble( 0.2610, 0.4325), cdouble(-0.0565,-0.0719),
cdouble( 0.7277,-0.9754), cdouble(-0.3780, 1.0718)};
cdouble b[] = {cdouble(-0.0821,+0.8410), cdouble(-0.0749, 0.0729),
cdouble(-0.6094,-0.2975), cdouble( 0.2106,-0.2026),
cdouble( 0.1043,-0.8300), cdouble( 0.0806, 0.3698)};
cdouble x_ref(-2.01767031,-0.45861365);
cdouble x = zdotu_(&size, a, &incr, b, &incr);
return (std::abs(x - x_ref) < 1e-6) ? 0 : 1;
}
--
Summary: zdotu (copy of BLAS version) works in x86, x86_64,
segfaults in arm.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akumar at ee dot iitm dot ac dot in
GCC build triplet: arm-linux-gnu
GCC host triplet: arm-linux-gnu
GCC target triplet: arm-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35220
[Bug c++/14258] typename in a using declaration not supported
--- 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
[Bug libstdc++/35209] __gnu_cxx::stdio_sync_filebuf constructor isn't exported by the DSO
--- 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 gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35209
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- 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 > point? As far as I saw there is a bug in ix86_expand_prologue, but it hasn't to do something with this problem. The code expansion for inlined static methods, seems to be broken. If I write small test programs using alloca (and so indirect ___chkstk) every thing works fine and the assembly is proven correct. But if the methods getting more complex like in cp/pt.c the code gets broken. If I use the target by disabling the stack probing most problems are gone, but still there seems to be a stack corruption in c++ and fortan compiler. These compilers make more use of stack allocation method alloca. For the stack probing I am certain, that if the a linux x86_64 would enable it, things get here broken, too. But there seems to be a issue with inline expansion in general. So for this bug may it the best to disable for now the stack probing at all. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug target/32593] Missed optimization of 'y = constant - x' operation
-- astrange at ithinksw dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32593
[Bug target/33555] x86 missed opportunity for sbb
-- astrange at ithinksw dot com changed: What|Removed |Added Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33555
[Bug libobjc/34315] libobjc warnings with Win64 target=x86_64-pc-mingw32
--- 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 serious bug. The cast of an integer with less size to a pointer can be seriously wrong. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34315
[Bug c/35162] Documentation incorrect for -fcx-limited-range
--- 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 CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35162
[Bug fortran/29549] matmul slow for complex matrices
--- 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
[Bug target/35013] Incomplete check in RTL for "pm()" annotation
--- 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=15169&action=view) Patch The attached patch allows function address expressions of the form address+k to be correctly recognized as program memory addresses and thus force use of pm() assembler syntax. This has not been extensively tested but assembler appears to be correct for this bugs testcase and a similar issue found in: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192 Note, odd addresses will be accepted by C and only cause linker warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35013
[Bug regression/35218] [4.3 regression] 4.3 20080215 snapshot build failure
--- 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 \ $(srcdir)/copying-lib.texi \ $(srcdir)/obstacks.texi \ $(srcdir)/functions.texi should get at-file.texi added so it will be included in the distribution tarballs? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35218
[Bug libstdc++/35221] New: libstdc++ broken
/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 pa. You can retarget the severity, but for me this smells blocking. -- Summary: libstdc++ broken Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andreast at gcc dot gnu dot org GCC build triplet: hppa*-hp-hpux11.11, sparc-sun-solaris2.8 GCC host triplet: hppa*-hp-hpux11.11, sparc-sun-solaris2.8 GCC target triplet: hppa*-hp-hpux11.11, sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35221
[Bug fortran/29549] matmul slow for complex matrices
--- 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) +++ Makefile.am (working copy) @@ -28,6 +28,9 @@ AM_CPPFLAGS = -iquote$(srcdir)/io -I$(sr -I$(srcdir)/$(MULTISRCTOP)../gcc/config \ -I$(MULTIBUILDTOP)../../$(host_subdir)/gcc -D_GNU_SOURCE +# Fortran rules for complex multiplication and division +AM_CFLAGS += -fcx-fortran-rules + gfor_io_src= \ io/close.c \ io/file_pos.c \ Regtested on i686-pc-linux-gnu. This might benefit other intrinsics using complex multiplication and division as well, e.g. PRODUCT. I'll go ahead and write some documentation as well, and submit the entire thing once 4.4 opens; assigning to myself. -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-11-04 14:15:02 |2008-02-16 22:33:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29549
[Bug middle-end/31738] Fortran dot product vectorization is restricted
--- 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: What|Removed |Added Last reconfirmed|2007-04-28 22:04:58 |2008-02-16 22:40:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31738
[Bug target/35222] New: [4.3 Regression] EH output contains procedure label without P' selector
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 -B/opt/gnu/gcc/gcc-4.3.0/hppa1.1-hp-hpux10.20/bin/ -B/opt/gnu/gcc/gcc-4.3.0/hppa1.1-hp-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.3.0/hppa1.1-hp-hpux10.20/include -isystem /opt/gnu/gcc/gcc-4.3.0/hppa1.1-hp-hpux10.20/sys-include -threads -shared -nostdlib -fPIC -Wl,+h -Wl,libstdc++.sl.6 -Wl,+b -Wl,/opt/gnu/gcc/gcc-4.3.0/lib/threads -o .libs/libstdc++.sl.6.10 .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/functexcept.o .libs/hash.o .libs/hash_c++0x.o .libs/globals_io.o .libs/hashtable.o .libs/hashtable_c++0x.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/debug_list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/system_error.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o .libs/libstdc++.lax/libmath.a/stubs.o .libs/libstdc++.lax/libmath.a/signbit.o .libs/libstdc++.lax/libmath.a/signbitf.o .libs/libstdc++.lax/libsupc++convenience.a/array_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/atexit_arm.o .libs/libstdc++.lax/libsupc++convenience.a/bad_cast.o .libs/libstdc++.lax/libsupc++convenience.a/bad_typeid.o .libs/libstdc++.lax/libsupc++convenience.a/class_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/del_op.o .libs/libstdc++.lax/libsupc++convenience.a/del_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/del_opv.o .libs/libstdc++.lax/libsupc++convenience.a/del_opvnt.o .libs/libstdc++.lax/libsupc++convenience.a/dyncast.o .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o .libs/libstdc++.lax/libsupc++convenience.a/eh_arm.o .libs/libstdc++.lax/libsupc++convenience.a/eh_aux_runtime.o .libs/libstdc++.lax/libsupc++convenience.a/eh_call.o .libs/libstdc++.lax/libsupc++convenience.a/eh_catch.o .libs/libstdc++.lax/libsupc++convenience.a/eh_exception.o .libs/libstdc++.lax/libsupc++convenience.a/eh_globals.o .libs/libstdc++.lax/libsupc++convenience.a/eh_personality.o .libs/libstdc++.lax/libsupc++convenience.a/eh_term_handler.o .libs/libstdc++.lax/libsupc++convenience.a/eh_terminate.o .libs/libstdc++.lax/libsupc++convenience.a/eh_throw.o .libs/libstdc++.lax/libsupc++convenience.a/eh_type.o .libs/libstdc++.lax/libsupc++convenience.a/eh_unex_handler.o .libs/libstdc++.lax/libsupc++convenience.a/enum_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/function_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/fundamental_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/guard.o .libs/libstdc++.lax/libsupc++convenience.a/new_handler.o .libs/libstdc++.lax/libsupc++convenience.a/new_op.o .libs/libstdc++.lax/libsupc++convenience.a/new_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/new_opv.o .libs/libstdc++.lax/libsupc++convenience.a/new_opvnt.o .libs/libstdc++.lax/libsupc++convenience.a/pbase_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/pmem_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/pointer_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/pure.o .libs/libstdc++.lax/libsupc++convenience.a/si_class_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/tinfo.o .libs/libstdc++.lax/libsupc++convenience.a/tinfo2.o .libs/libstdc++.lax/libsupc++convenience.a/vec.o .libs/libstdc++.lax/libsupc++convenience.a/vmi_class_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o .libs/libstdc++.lax/libsupc++convenience.a/cp-demangle.o -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 -lm -L/xxx/gnu/gcc/objdir/./gcc/threads -L/xxx/gnu/gcc/objdir/./gcc -L/usr/ccs/lib -L/opt/langtools/lib -lgcc_s -threads -threads -threads -threads -threads -threads /usr/ccs/bin/ld: Procedure labels require the P' selector - use the P' selector on code symbol "$CODE$" in file .libs/pool_allocator.o collect2: ld returned 1 exit status make[8]: *** [libstdc++.la] Error 1 Looking at the assembler output for pool_allocator.cc, I see the following: .SPACE $PRIVATE$ .SUBSPA $DATA$ .align 4 .EXPORT
[Bug bootstrap/35218] [4.3 regression] 4.3 20080215 snapshot build failure
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|regression |bootstrap Keywords||build Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35218
[Bug libstdc++/35221] [4.3 Regression] libstdc++ broken
--- 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 Keywords||build Priority|P3 |P1 Summary|libstdc++ broken|[4.3 Regression] libstdc++ ||broken Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35221
[Bug bootstrap/35218] [4.3 regression] 4.3 20080215 snapshot build failure
--- 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
[Bug target/35222] [4.3 Regression] EH output contains procedure label without P' selector
--- 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)
(gdb) p debug_rtx (addr)
(symbol_ref:SI ("*L$FB0098") [flags 0x2])
The encoding seems wrong. Expected DW_EH_PE_aligned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35222
[Bug libstdc++/35209] __gnu_cxx::stdio_sync_filebuf constructor isn't exported by the DSO
--- 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=gcc&view=rev&rev=132372 Log: 2008-02-17 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/35209 * config/abi/pre/gnu.ver: Export stdio_sync_filebuf symbols. * testsuite/ext/stdio_sync_filebuf/char/35209.cc: New. * testsuite/ext/stdio_sync_filebuf/wchar_t/35209.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/ext/stdio_sync_filebuf/char/35209.cc trunk/libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/35209.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35209
[Bug libstdc++/35209] __gnu_cxx::stdio_sync_filebuf constructor isn't exported by the DSO
--- 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|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35209
[Bug fortran/35223] New: IBITS gives compiler error
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] gfortran --version GNU Fortran (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) Copyright (C) 2007 Free Software Foundation, Inc. Of course, compiling with my mac-version of gfortran gives the same result: epsilon [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) epsilon [TEST] gfortran --version GNU Fortran (GCC) 4.3.0 20071017 (experimental) [trunk revision 129405] Copyright (C) 2007 Free Software Foundation, Inc. Compiling with g95 works fine though. Sincerely PHL -- Summary: IBITS gives compiler error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: phl at kth dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223
[Bug fortran/35223] IBITS gives compiler error
--- 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 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) Use -fno-range-check when you compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223
[Bug target/35222] [4.3 Regression] EH output contains procedure label without P' selector
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35222
[Bug fortran/35223] 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, bit_size (0)) > end program main > (snip) What result do you expect? > Compiling with g95 works fine though. Appears g95 may have a bug. See Sec. 13.3, 13.4, and most importantly 13.7 in the 'Final Committee Draft J3/03-007R2' of the Fortran 2003 standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223
[Bug fortran/25829] [F2003] Asynchronous IO support
--- 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 AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-17 23:33:35 |2008-02-17 01:19:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug target/35222] [4.3 Regression] EH output contains procedure label without P' selector
--- 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 only occurs is the symbol is an unsat. This might might occur if we have EH data for a function that has been eliminated. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35222
[Bug middle-end/35163] [4.1/4.2 Regression] folding comparison loses cast
--- 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=15171&action=view) patch to fix testsuite breakage on 16 bit integer targets Unfortunately, the testcase assumes 32 bit integers and fails on the avr target. The attached patch makes the expected type sizes explicit, so that it doesn't depend on the natural integer size of the target. The patch was tested for te avr target and it works as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35163
[Bug fortran/30388] gfortran42 is slower than g77 3.4 about 10%
--- 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 fortran? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30388
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- 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 AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-02 16:33:54 |2008-02-17 04:44:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/25829] [F2003] Asynchronous IO support
--- 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 BugsThisDependsOn||34705 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug fortran/35223] IBITS gives compiler error
--- 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, bit_size (0)) >> end program main >> > > (snip) > > What result do you expect? In this case I expect a running program to print "-1". > >> Compiling with g95 works fine though. > > Appears g95 may have a bug. See Sec. 13.3, 13.4, and most importantly > 13.7 in the 'Final Committee Draft J3/03-007R2' of the Fortran 2003 > standard. In that case a lot of compilers have the same bug. :-) Appears more likely gfortran has a bug. Pasting from the f90-standard: "13.13.42 IBITS (I, POS, LEN) Description. Extracts a sequence of bits. Class. Elemental function. Arguments. I must be of type integer. POS must be of type integer. It must be nonnegative and POS + LEN must be less than or equal to BIT_SIZE (I). LEN must be of type integer and nonnegative. Result Type and Type Parameter. Same as I. Result Value. The result has the value of the sequence of LEN bits in I beginning at bit POS right- adjusted and with all other bits zero. The model for the interpretation of an integer value as a sequence of bits is in 13.5.7. Example. IBITS (14, 1, 3) has the value 7." To conclude, the error message is incorrect. Regards PHL -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223
[Bug fortran/35223] IBITS gives compiler error
--- 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 > >> program main > >> write (*, *) ibits (-1, 0, bit_size (0)) > >> end program main > >> > > > > (snip) > > > > What result do you expect? > > > In this case I expect a running program to print "-1". > > > > > >> Compiling with g95 works fine though. > > > > Appears g95 may have a bug. See Sec. 13.3, 13.4, and most importantly > > 13.7 in the 'Final Committee Draft J3/03-007R2' of the Fortran 2003 > > standard. > > In that case a lot of compilers have the same bug. :-) > Appears more likely gfortran has a bug. > Pasting from the f90-standard: > > "13.13.42 IBITS (I, POS, LEN) Description. I know what 13.13.42 says. I also know what 13.5.7 in the F95 standard says about the model numbers that are used by IBITS: Effectively, this model defines an integer object to consist of z bits in sequence numbered from right to left from 0 to z - 1 . This model is valid only in the context of the use of such an object as the argument or result of one of the bit manipulation procedures. In all other contexts, the model defined for an integer in 13.7.1 applies. and 13.14 from the Fortran 95 standard says This section contains detailed specifications of the generic intrinsic procedures in alphabetical order. The types and type parameters of intrinsic procedure arguments and function results are determined by these specifications. A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters. Read that last sentence carefully. You, as the programmer, are prohibited from calling an intrinsic procedure if it will return a value outside the representable range. Now, go read about the model numbers for the bit intrinsics and for integers. The bit intrinsic model numbers do not have a sign bit, and you're asking IBITS to return 2**32, which is outside of the range for gfortran's default integer kind. Also note, that a compiler is not required to detect the programming error. It can in fact do anything including what you expect as well as report an error. > > To conclude, the error message is incorrect. > You conclusion is wrong. Jerry already told you how to disable the error with -fno-range-check option. But, you should probably think about fixing your program. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223
[Bug tree-optimization/35224] New: scalar evolution analysis fails with "evolution of base is not affine"
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 with "evolution of base
is not affine"
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35224
