[Bug middle-end/29887] wrong-code for errno handling on overflow/underflow
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-06 08:58 --- With overflow we end up with Inf or -Inf, with underflow we end up with 0. (or even -0.?) - but underflow doesn't seem to require a diagnostic errno setting. I don't see how this relates to PR23572 though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29887
[Bug fortran/30081] New: Interface bug overloading random_seed, random_number
Hi, here's an interface related bug I discovered which is not yet mentioned in PR 29670. % gfortran gfcbug46.f90 gfcbug46.f90:25.29: call random_number (t% x) 1 Error: There is no specific subroutine for the generic 'random_number' at (1) gfcbug46.f90:20.29: call random_seed (size=n) 1 Error: There is no specific subroutine for the generic 'random_seed' at (1) The code is standard-conforming and works with other compilers. See the attached code for details. -- Summary: Interface bug overloading random_seed, random_number Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30081
[Bug fortran/30081] Interface bug overloading random_seed, random_number
--- Comment #1 from anlauf at gmx dot de 2006-12-06 09:12 --- Created an attachment (id=12752) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12752action=view) Interface bug demo code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30081
[Bug target/30082] New: Expansion of ceil and floor could use if-conversion
- ceiling cvtss2si %xmmMM, %rNN cvtsi2ss %rNN, %xmmJJ ;; scratch ucomiss %xmmMM, %xmmJJ adc $0, %rNN - floor cvtss2si %xmmMM, %rNN cvtsi2ss %rNN, %xmmJJ ;; scratch ucomiss %xmmJJ, %xmmMM sbb $0, %rNN can be emitted directly using appropriate IF_THEN_ELSE rtx and not rely on ifcvt figuring out itself (which it doesn't in most cases). -- Summary: Expansion of ceil and floor could use if-conversion Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: rguenth at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x86_64-*-*, i?86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30082
[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-12-06 09:52 ---
Ok, so my plan is to go in small steps:
- at gimplification time change calls to sincos (x, s, c) to calls to cexp
like
_Complex __typeof__(s) tmp = cexp ( { 0., x } );
s = __imag tmp;
c = __real tmp;
- at expansion time, transform the above back to a call to sincos. This
relies
on TER to make the argument of form { 0., x } visible to the expander.
Alternatively do this back-transformation before going out-of-ssa.
2nd alternatively create a new (internal) builtin cexpi that takes the
imaginary part of the argument only, i.e. cexpi (x) would be sincos. This
at least would simplify the code.
The above two should fix PR17687 on the tree level and on the rtl level where
the target provides either a sane ABI to the sincos function (or an
alternative)
or a machine instruction (like fsincos).
- inside PRE recognize sin and cos and do insertion of cexp if necessary.
If we do it in the hackish way, simply transform sin and cos to
cexp before PRE and transform back cexp to sin or cos if only the real
or imaginary parts of the result is used after PRE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
[Bug tree-optimization/17687] sincos tree representation causes extra addressable vars
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-12-06 09:54 --- Paolo, are you working on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug tree-optimization/17687] sincos tree representation causes extra addressable vars
--- Comment #16 from paolo dot bonzini at lu dot unisi dot ch 2006-12-06 09:58 --- Subject: Re: sincos tree representation causes extra addressable vars Paolo, are you working on this? No. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug tree-optimization/17687] sincos tree representation causes extra addressable vars
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-12-06 10:04 --- So I hope you don't mind... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|bonzini at gnu dot org |rguenth at gcc dot gnu dot ||org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #29 from fxcoudert at gcc dot gnu dot org 2006-12-06 10:04 --- Created an attachment (id=12753) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12753action=view) New patch Thanks Eric for the testing the non-working previous patch. I've now had time to test it more thouroughly, after adding protos and correcting the mistakes in the floorl logic. Attached is the patch (against 4.1) that I intend to commit once testing is done. This new version also returns the correct value for -0.0L. Testing under progress on i686-linux by manually changing libgfortran/config.h As Thomas noted, we thought that the test on (n != END_BUILTINS) in the front-end got the non-C99 platforms taken care of, so once the branches bootstrap again, we'll probably need to investigate this lead. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Attachment #12735|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug target/30082] Expansion of ceil and floor could use if-conversion
--- Comment #1 from bonzini at gnu dot org 2006-12-06 10:10 ---
You might have to add a post-reload splitter for something like
(set (match_operand:SI 0 register_operand +r)
(plus (match_dup 0)
(lt:SI (match_operand:SF 1 register_operand x)
(match_operand:SF 2 register_operand xm)))
to
[(set (reg:CCFP FLAGS_REG)
(compare:CCFPU (match_dup 1) (match_dup 2)))
(parallel [(set (match_dup 0)
(plus (match_dup 0)
(ltu:SI (reg:CC FLAGS_REG) (const_int 0
(clobber (reg:CC FLAGS_REG))])]
and likewise
(set (match_operand:SI 0 register_operand +r)
(minus (match_dup 0)
(lt:SI (match_operand:SF 1 register_operand x)
(match_operand:SF 2 register_operand xm)))
to
[(set (reg:CCFP FLAGS_REG)
(compare:CCFPU (match_dup 2) (match_dup 1)))
(parallel [(set (match_dup 0)
(minus:SI (match_dup 0)
(ltu:SI (reg:CC FLAGS_REG) (const_int 0
(clobber (reg:CC FLAGS_REG))])]
The pattern for the adc and sbb are already there, but they don't match if the
immediate is zero because it gets simplified, so you need also something like
this:
(define_insn adc_carry_si
[(set (match_operand:SI 0 nonimmediate_operand =rm)
(plus:SI (match_operand:SI 1 nonimmediate_operand 0)
(match_operand:SI 2 ix86_carry_flag_operator )))
(clobber (reg:CC FLAGS_REG))]
ix86_binary_operator_ok (PLUS, SImode, operands)
adc{l}\t{$0, %0|%0, 0}
[(set_attr type alu)
(set_attr pent_pair pu)
(set_attr mode SI)])
(define_insn sub_carry_si
[(set (match_operand:SI 0 nonimmediate_operand =rm)
(minus:SI (match_operand:SI 1 nonimmediate_operand 0)
(match_operand:SI 2 ix86_carry_flag_operator )))
(clobber (reg:CC FLAGS_REG))]
ix86_binary_operator_ok (MINUS, SImode, operands)
sbb{l}\t{$0, %0|%0, 0}
[(set_attr type alu)
(set_attr pent_pair pu)
(set_attr mode SI)])
Of course in both 32-bit and 64-bit modes. Which explains why I only did the
theory, and stopped before the practice.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30082
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #30 from fxcoudert at gcc dot gnu dot org 2006-12-06 10:55 --- Subject: Bug 29810 Author: fxcoudert Date: Wed Dec 6 10:55:37 2006 New Revision: 119577 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119577 Log: PR libfortran/29810 * intrinsics/c99_functions.c (fmodf, fmodl, floorl): New functions. * c99_protos.h (fmodf, fmodl, floorl): New prototypes. * configure.ac: Check for fmodf, fmod and fmodl. * configure: Regenerate. * config.h.in: Regenerate. * aclocal.m4: Regenerate with correct autoconf version (1.9.6). * Makefile.in: Likewise. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/Makefile.in branches/gcc-4_1-branch/libgfortran/aclocal.m4 branches/gcc-4_1-branch/libgfortran/c99_protos.h branches/gcc-4_1-branch/libgfortran/config.h.in branches/gcc-4_1-branch/libgfortran/configure branches/gcc-4_1-branch/libgfortran/configure.ac branches/gcc-4_1-branch/libgfortran/intrinsics/c99_functions.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #15 from cvs-commit at developer dot classpath dot org 2006-12-06 11:37 --- Subject: Bug 29272 CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Chris Burdess dog 06/12/06 11:36:42 Modified files: . : ChangeLog gnu/xml/stream : SAXParser.java javax/xml/parsers: DocumentBuilderFactory.java Log message: 2006-12-06 Chris Burdess [EMAIL PROTECTED] Fixes PR 29272. * javax/xml/parsers/DocumentBuilderFactory.java: Fix broken Javadoc. * gnu/xml/stream/SAXParser.java: Fix file descriptor leak. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8928r2=1.8929 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/stream/SAXParser.java?cvsroot=classpathr1=1.21r2=1.22 http://cvs.savannah.gnu.org/viewcvs/classpath/javax/xml/parsers/DocumentBuilderFactory.java?cvsroot=classpathr1=1.5r2=1.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug c++/30080] incorrect code generation, possibly related to casting/aliasing
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-12-06 11:59 --- It works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30080
[Bug target/29613] static string in vararg function
--- Comment #1 from etienne_lorrain at yahoo dot fr 2006-12-06 12:47 --- Was another problem (Initialise the main stack at the top of the reserved space, without keeping two words safety linked to the calling convention, so the first call would erase the first static variable at top_stack+4) Sorry. -- etienne_lorrain at yahoo dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29613
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2006-12-06 13:13 --- I've now had time to test it more thouroughly, after adding protos and correcting the mistakes in the floorl logic. Attached is the patch (against 4.1) that I intend to commit once testing is done. This new version also returns the correct value for -0.0L. Testing under progress on i686-linux by manually changing libgfortran/config.h Thanks, committed version OK on all versions of SPARC/Solaris. You should seriously consider stopping mixing integral constants and FP code though. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Comment #36 from pluto at agmk dot net 2006-12-06 13:22 --- (In reply to comment #32) The hidden definition in main_skel.o is ignored due to COMDAT group. could you fill PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug target/30052] memory hog on x86-64
--- Comment #2 from pluto at agmk dot net 2006-12-06 13:24 --- this hog blocks xorg-xserver development/testing. -- pluto at agmk dot net changed: What|Removed |Added Severity|normal |blocker Summary|memory hog on x86 |memory hog on x86-64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug other/30083] New: double quotes in Makefile confuse solaris /bin/sh
Hello, gmake install currently fails for me on mainline on solaris 10 if I use the default /bin/sh shell. The problem is with this line of gcc/Makefile.in: SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e s,[^/]*/\.\.\/,, -e ta` this variable is used inside double quotes, and solaris /bin/sh parses `` as two strings containing a backquote (or something else, but not what you would expect anyway). I believe using single quotes in this line would help (I did not redo the whole configure+bootstrap, but I checked that solaris sh understood the modified line). -- Summary: double quotes in Makefile confuse solaris /bin/sh Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marc dot glisse at normalesup dot org GCC host triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
[Bug middle-end/30079] [4.3 regression] libgcov.c:785: ICE: in fold_convert, at fold-const.c:2034
--- Comment #5 from aldyh at gcc dot gnu dot org 2006-12-06 14:03 --- What is the actual triplet, and can you provide a .i file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30079
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Comment #37 from hjl at lucon dot org 2006-12-06 14:19 --- The updated patch is at http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00397.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug fortran/30084] New: segmentation falut when compiling certain code
gfortran crashes when compiling teh attached code (the same segmentation fault occures when compiling with 4.2.0 version of gfortran) [EMAIL PROTECTED] /tmp/gfortcrash $ gfortran -c kinds.f90 vamp_bundle.f90 vamp_bundle.f90:3166: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED] /tmp/gfortcrash $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure --prefix=/home/fxcoudert/gfortran_nightbuild/irun-20061130 --enable-languages=c,fortran --with-gmp=/home/fxcoudert/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20061130 (experimental) -- Summary: segmentation falut when compiling certain code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: trumsko at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30084
[Bug fortran/30084] segmentation falut when compiling certain code
--- Comment #1 from trumsko at yahoo dot com 2006-12-06 14:36 --- Created an attachment (id=12754) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12754action=view) source files to crash gfortran unpack and execute gfortran -c kinds.f90 vamp_bundle.f90 to reproduce segmentation violation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30084
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Comment #38 from hjl at lucon dot org 2006-12-06 14:39 --- (In reply to comment #36) (In reply to comment #32) The hidden definition in main_skel.o is ignored due to COMDAT group. could you fill PR? http://sourceware.org/bugzilla/show_bug.cgi?id=3666 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug libstdc++/30085] New: switch debug mode hash containers from ext to tr1
Currently debug mode uses ext/hash_map, ext/hash_set et. al for the basis of the ebug containers. This should be switched to tr1/unordered_map tr1/unordered_set as the older SGI hash containers are deprecated. Also, maybe these containers should be moved to backward, from ext? -- Summary: switch debug mode hash containers from ext to tr1 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085
[Bug middle-end/30079] [4.3 regression] libgcov.c:785: ICE: in fold_convert, at fold-const.c:2034
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-06 15:34 --- Subject: Re: [4.3 regression] libgcov.c:785: ICE: in fold_convert, at fold-const.c:2034 What is the actual triplet, and can you provide a .i file? Here's the .i. Dave --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-06 15:34 --- Created an attachment (id=12755) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12755action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30079
[Bug middle-end/30079] [4.3 regression] libgcov.c:785: ICE: in fold_convert, at fold-const.c:2034
--- Comment #8 from danglin at gcc dot gnu dot org 2006-12-06 16:03 --- Do you mean the following: (gdb) p debug_tree (t) bit_and_expr 7adedb90 type pointer_type 7ae77960 va_list type void_type 7adf0900 void VOID align 8 symtab 15 alias set -1 pointer_to_this pointer_type 7adf0960 sizes-gimplified unsigned SI size integer_cst 7ade12d0 constant invariant 32 unit size integer_cst 7ade1060 constant invariant 4 align 32 symtab 21 alias set -1 pointer_to_this pointer_type 7ad61c00 arg 0 minus_expr 7adedb68 type pointer_type 7ae77960 va_list arg 0 var_decl 7ad62528 ap type pointer_type 7ae77960 va_list addressable used unsigned SI file ../../gcc/gcc/libgcov.c line 775 size integer_cst 7ade12d0 32 unit size integer_cst 7ade1060 4 align 32 context function_decl 7ad5a4d0 __gcov_execl chain var_decl 7ad62580 aq arg 1 integer_cst 7ad66090 constant invariant 4 arg 1 integer_cst 7ad661c8 type pointer_type 7ae77960 va_list constant invariant -4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30079
[Bug c/30086] New: Initialize struct to avoid warnings shouldn't be needed
When compiling GDB 6.5.90 on x86 (FC5) GCC gives following warning. So it is needed to initialize tmp_obstack to avoid this warning. This isn't necessary and GCC should detect this. /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c: In function 'pascal_object_print_value_fields': /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.alloc_failed' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.maybe_empty_object' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.use_extra_arg' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.extra_arg' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.freefun' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.chunkfun' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.alignment_mask' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.temp' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.chunk_limit' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.next_free' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.object_base' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.chunk' may be used uninitialized in this function /home/user/gdb/6.5.90/gdb-6.5.90/gdb/p-valprint.c:756: warning: 'tmp_obstack.chunk_size' may be used uninitialized in this function make[2]: *** [p-valprint.o] Error 1 make[2]: Leaving directory `/home/user/gdb/6.5.90/gdb-6.5.90/build_werr/gdb' make[1]: *** [all-gdb] Error 2 make[1]: Leaving directory `/home/user/gdb/6.5.90/gdb-6.5.90/build_werr' make: *** [all] Error 2 -- Summary: Initialize struct to avoid warnings shouldn't be needed Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: midoegal at web dot de GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30086
[Bug c++/30080] incorrect code generation, possibly related to casting/aliasing
--- Comment #4 from irving at cs dot stanford dot edu 2006-12-06 16:36 --- The default version of gcc 4.1.1 from fedora works. The version that breaks is a separate build of the compiler with different configuration options. g++ -v from the fedora version follows. Do you know any way I could isolate the difference? ring:solids_3d% g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20061011 (Red Hat 4.1.1-30) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30080
[Bug tree-optimization/30087] New: regressions in the gfortran testsuite with -ftree-vectorize
Running the gfortran testsuite with -O2 -ftree-vectorize started giving a number of failures in the span of the last 3-4 days. Namely, the testcases gfortran.dg/actual_array_constructor_3.f90 gfortran.dg/array_constructor_8.f90 now lead to ICEs in the compiler. This blocks my effort to make the gfortran testsuite run with -ftree-optimize. -- Summary: regressions in the gfortran testsuite with -ftree- vectorize Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org GCC host triplet: i386-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30087
[Bug c++/30088] New: Unexpected compilation results: -O1 vs. -O1 -fstrict-aliasing
The following C++ program (preprocessed source attached) produces unexpected
results when compiled with -O1 -fstrict-aliasing (as opposed to -O1 only) or
with any higher level of optimization (-O2 or -O3). No compilation warnings
are emitted in any of the cases.
#include cassert
#include string
struct A
{
A() : _x(0.0), _y(0.0) { }
float f(const int i) { return (i == 0 ? _x : _y); }
float _x, _y;
};
struct B
{
B(const char* s) : _s(s) { }
std::string g() { return std::string(_s); }
const char* _s;
};
A h(const char* s)
{
if (s == 0)
return A();
A a;
B b(s);
if (b.g().compare(std::string()) == 0)
a.f(0) = a.f(1) = 1.0;
else if (b.g().compare(std::string()))
b.g().compare(std::string());
return a;
}
int main()
{
A a(h());
assert(a._x 0.0 a._y 0.0);
return 0;
}
Compilation results:
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../src/configure --prefix=/opt/gcc-4.1.1
Thread model: posix
gcc version 4.1.1
$ g++ -W -Wall -O1 testcase.cc
$ ./a.out
$ g++ -W -Wall -O1 -fstrict-aliasing testcase.cc
$ ./a.out
a.out: testcase.cc:34: int main(): Assertion `a._x 0.0 a._y 0.0' failed.
Aborted
The assertion ceases to fail (with -O1 -fstrict-aliasing) when adding any
(single one) of the options -fno-tree-copy-prop, -fno-tree-dce,
-fno-tree-salias or -fno-inline to the compiler command line.
--
Summary: Unexpected compilation results: -O1 vs. -O1 -fstrict-
aliasing
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heikki dot tauriainen at tkk dot fi
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30088
[Bug c++/30088] Unexpected compilation results: -O1 vs. -O1 -fstrict-aliasing
--- Comment #1 from heikki dot tauriainen at tkk dot fi 2006-12-06 17:01 --- Created an attachment (id=12757) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12757action=view) Preprocessed source of test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30088
[Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory
Two testcases will follow, build with -O2. -- Summary: Compiling FreeFem3d uses unreasonable amount of time and memory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: memory-hog, compile-time-hog Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-06 17:17 --- Created an attachment (id=12758) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12758action=view) first testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-06 17:18 --- Created an attachment (id=12759) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12759action=view) second testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-12-06 17:20 --- Before the last big regressions on the mainline the first one took 350MB and 52s to build with -O2 on x86_64, the second one 685MB and 147s. That was g++ (GCC) 4.3.0 20061122 (experimental). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug driver/30090] New: Incorrectness in `gcc.c'
gcc.c #v+ [...] Specs are strings containing lines, each of which (if not blank) is made up of a program name, and arguments separated by spaces. The program name must be exact and start from root, since no path is searched and it is unreliable to depend on the current working directory. [...] #v- On further inspection of `gcc.c' it turns out that this is not true, and instead a rather extensive method of locating the executable is used, involving hard-coded paths and also `$PATH'. #v+ $ cat specs @foo_language: printenv PATH which fortune fortune $ gcc -E -x foo_language -specs=specs /dev/null /home/cip/3/cpts2523/command:/home/cip/3/cpts2523/shared/command:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games /usr/games/fortune But, for my own part, it was Greek to me. -- William Shakespeare, Julius Caesar #v- -- Summary: Incorrectness in `gcc.c' Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tschwinge at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30090
[Bug driver/30091] New: specs file: [EMAIL PROTECTED]' not documented
It seems to me that neither in the manual nor in the commentary in `gcc.c' it is documented that one can use [EMAIL PROTECTED]' to introduce a new `LANGUAGE' to gcc when using custom specs files via `gcc -specs=FILE'. Is it advisible to have the specs syntax's documentation both in the Texinfo manual and as comments in `gcc.c'? Are they kept in sync? -- Summary: specs file: [EMAIL PROTECTED]' not documented Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tschwinge at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30091
[Bug c++/28553] [4.1 Regression] string processing -O3 optimization bug under GCC 4.1.1
--- Comment #8 from peter at chocky dot org 2006-12-06 17:37 --- And it's back, at least in this version: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr/local/gcc-4.1 --enable-languages=c,c++,java Thread model: posix gcc version 4.1.2 20061204 (prerelease) -- peter at chocky dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28553
[Bug fortran/30084] segmentation falut when compiling certain code
--- Comment #2 from kargl at gcc dot gnu dot org 2006-12-06 17:37 --- Reduced testcase: module tao_random_numbers integer, dimension(10) :: s_buffer integer :: s_last = size (s_buffer) end module tao_random_numbers module linalg contains function diag (a) result (d) real, dimension(:,:), intent(in) :: a real, dimension(min(size(a,dim=1),size(a,dim=2))) :: d integer :: i do i = 1, min(size(a, dim = 1), size(a, dim = 2)) d(i) = a(i,i) end do end function diag end module linalg module vamp_rest use tao_random_numbers use linalg end module vamp_rest -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30084
[Bug java/24938] gcj -C miscompiles gnu/CORBA/DynAn/gnuDynValue.java
-- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-11-18 23:52:34 |2006-12-06 17:39:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24938
[Bug c++/29729] [4.0/4.1/4.2/4.3 regression] ICE with template class in template function
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-12-06 17:41 --- Subject: Bug 29729 Author: mmitchel Date: Wed Dec 6 17:41:29 2006 New Revision: 119586 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119586 Log: PR c++/29729 * decl2.c (check_member_template): Move check for member templates in local classes to ... * parser.c (cp_parser_template_declaration_after_export): ... here. PR c++/29729 * g++.dg/template/crash63.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/crash63.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/decl2.c branches/gcc-4_2-branch/gcc/cp/parser.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29729
[Bug c++/29729] [4.0/4.1 regression] ICE with template class in template function
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-12-06 17:42 --- Fixed in 4.2.0, 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1 regression] ICE |ICE with template class in |with template class in |template function |template function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29729
[Bug other/30083] double quotes in Makefile confuse solaris /bin/sh
--- Comment #1 from marc dot glisse at normalesup dot org 2006-12-06 18:01 --- Actually, the problem seems to be caused by the '^' character, which is the equivalent of '|' for this shell. The solution is still the same, have single quotes (or protect the '^' with '\'). There seems to be two other occurences of an unprotected '^' line 3246 and 3856 in the same file, don't know if it may cause problems as well, but it would be safer to modify those too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
[Bug driver/30091] specs file: [EMAIL PROTECTED]' not documented
--- Comment #1 from tschwinge at gnu dot org 2006-12-06 18:22 --- It is also not documented that `#COMMENT' can be used to embed comments. And `\f' (form feed, `^L') could be added to list of white space (in the skip_whitespace function): it's convenient to separate units in hand-made specs files by form feed characters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30091
[Bug c++/29728] [4.0/4.1 regression] ICE on invalid initializer in template function
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-12-06 18:26 --- Subject: Bug 29728 Author: mmitchel Date: Wed Dec 6 18:26:44 2006 New Revision: 119588 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119588 Log: PR c++/29728 * decl.c (check_array_designated_initializer): New function. (maybe_deduce_size_from_array_init): Use it. (reshape_init_array): Likewise. PR c++/29728 * g++.dg/template/crash62.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash62.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/complit3.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29728
[Bug c++/29728] [4.0 regression] ICE on invalid initializer in template function
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-12-06 18:27 --- Fixed in 4.1.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 regression] ICE on |[4.0 regression] ICE on |invalid initializer in |invalid initializer in |template function |template function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29728
[Bug fortran/30068] Ambigous interfaces not detected
--- Comment #5 from pault at gcc dot gnu dot org 2006-12-06 18:49 --- Created an attachment (id=12760) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12760action=view) Fix and testcases. This regtests on Cygwin_NT/amd64. It is there, up to some adjustments to interpretation of the standard. -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30068
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Comment #39 from jason at redhat dot com 2006-12-06 19:14 --- Subject: Re: Can't use __attribute__ ((visibility (hidden))) to hide a symbol mmitchel at gcc dot gnu dot org wrote: Jason, are you actively working on this? (We are motivated to fix the problem, so if you're not working on it, then maybe we can help.) Not at the moment, feel free to reassign it. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug libfortran/30056] Exceeding recl on direct access
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-12-06 19:26 --- Subject: Bug 30056 Author: tkoenig Date: Wed Dec 6 19:25:44 2006 New Revision: 119592 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119592 Log: 2006-12-06 Thomas Koenig [EMAIL PROTECTED] PR libfortran/30009 PR libfortran/30056 * gfortran.dg/read_eof_4.f90: Add tests. * gfortran.dg/readwrite_unf_direct_eor_1.f90: New test. * gfortran.dg/unf_read_corrupted_1.f90: New test. 2006-12-06 Thomas Koenig [EMAIL PROTECTED] PR libfortran/30009 PR libfortran/30056 * libgfortran.h: Add ERROR_CORRUPT_FILE to error_codes. * runtime/error.c (translate_error): Add handling for ERROR_CORRUPT_FILE. * io/transfer.c (read_block_direct): Add comment about EOR for stream files. Remove test for no bytes left for direct access files. Generate an ERROR_SHORT_RECORD if the read was short. For unformatted sequential files: Check endfile condition. Remove test for no bytes left. End of file here means that the file structure has been corrupted. Pre-position the file for the next record in case of error. (write_buf): Whitespace fix. Subtract the number of bytes written from bytes_left. Added: trunk/gcc/testsuite/gfortran.dg/readwrite_unf_direct_eor_1.f90 trunk/gcc/testsuite/gfortran.dg/unf_read_corrupted_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/read_eof_4.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30056
[Bug libfortran/30009] Unformatted reads exceeding storage units gives EOF instead of ERR
--- Comment #13 from tkoenig at gcc dot gnu dot org 2006-12-06 19:26 --- Subject: Bug 30009 Author: tkoenig Date: Wed Dec 6 19:25:44 2006 New Revision: 119592 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119592 Log: 2006-12-06 Thomas Koenig [EMAIL PROTECTED] PR libfortran/30009 PR libfortran/30056 * gfortran.dg/read_eof_4.f90: Add tests. * gfortran.dg/readwrite_unf_direct_eor_1.f90: New test. * gfortran.dg/unf_read_corrupted_1.f90: New test. 2006-12-06 Thomas Koenig [EMAIL PROTECTED] PR libfortran/30009 PR libfortran/30056 * libgfortran.h: Add ERROR_CORRUPT_FILE to error_codes. * runtime/error.c (translate_error): Add handling for ERROR_CORRUPT_FILE. * io/transfer.c (read_block_direct): Add comment about EOR for stream files. Remove test for no bytes left for direct access files. Generate an ERROR_SHORT_RECORD if the read was short. For unformatted sequential files: Check endfile condition. Remove test for no bytes left. End of file here means that the file structure has been corrupted. Pre-position the file for the next record in case of error. (write_buf): Whitespace fix. Subtract the number of bytes written from bytes_left. Added: trunk/gcc/testsuite/gfortran.dg/readwrite_unf_direct_eor_1.f90 trunk/gcc/testsuite/gfortran.dg/unf_read_corrupted_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/read_eof_4.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009
[Bug java/24938] gcj -C miscompiles gnu/CORBA/DynAn/gnuDynValue.java
--- Comment #6 from tromey at gcc dot gnu dot org 2006-12-06 19:35 --- Subject: Bug 24938 Author: tromey Date: Wed Dec 6 19:35:05 2006 New Revision: 119593 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119593 Log: PR java/24938: * sources.am, Makefile.in: Rebuilt. * gnu/CORBA/DynAn/gnuDynValue.java: Removed. * gnu/CORBA/DynAn/RecordAny.java: Removed. * gnu/CORBA/DynAn/RecordAny.h: Rebuilt. Removed: branches/gcj/gcj-eclipse-merge-branch/libjava/gnu/CORBA/DynAn/RecordAny.java branches/gcj/gcj-eclipse-merge-branch/libjava/gnu/CORBA/DynAn/gnuDynValue.java Modified: branches/gcj/gcj-eclipse-merge-branch/libjava/ChangeLog branches/gcj/gcj-eclipse-merge-branch/libjava/Makefile.in branches/gcj/gcj-eclipse-merge-branch/libjava/gnu/CORBA/DynAn/RecordAny.h branches/gcj/gcj-eclipse-merge-branch/libjava/sources.am -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24938
[Bug tree-optimization/30092] New: Segmentation fault with -ftreevectorize and SQRT()
Using current SVN gcc/gfortran, the following program gives a SEGV with gfortran -ftree-vectorize -O3 -c but not if I remove the -ftree-vectorize option. The vectorization of sqrt is PR21466 / PR30032, but afterwards it was still working. Thus it is probably some interaction between the gimple work and the sqrt vectorization. -- SUBROUTINE EOS(NODES, DENS, PRES, CS, CGAMMA) IMPLICIT NONE INTEGER NODES REAL CGAMMA REAL, DIMENSION(NODES) :: DENS, PRES, CS REAL, PARAMETER :: RGAS = 8.314 CS(:NODES) = SQRT(CGAMMA*PRES(:NODES)/DENS(:NODES)) END SUBROUTINE EOS -- -- Summary: Segmentation fault with -ftreevectorize and SQRT() Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30092
[Bug tree-optimization/30093] New: vectorization of sqrt segfaults
Following testcase segfaults for x86_64 and i686 sse2 targets with -ffast-math:
double x[256];
void foo(void)
{
int i;
for (i=0; i256; ++i)
x[i] = sqrt (x[i]);
}
gcc -O2 -ftree-vectorize -ffast-math vect-sqrt.c vect-sqrt.c:
In function ‘foo’:
vect-sqrt.c:7: warning: incompatible implicit declaration of built-in function
‘sqrt’
‘
Segmentation fault
backtrace:
Analyzing compilation unit
Performing interprocedural optimizations
Assembling functions:
foo
Program received signal SIGSEGV, Segmentation fault.
0x003cefd72270 in strlen () from /lib64/libc.so.6
(gdb) bt
#0 0x003cefd72270 in strlen () from /lib64/libc.so.6
#1 0x007ff4dd in pp_base_string (pp=0xcf3d60, str=0x101040101010100
Address 0x101040101010100 out of bounds) at
../../gcc-svn/trunk/gcc/pretty-print.c:804
#2 0x0080010a in pp_base_format (pp=0xcf3d60, text=0x7f8a0fe0) at
../../gcc-svn/trunk/gcc/pretty-print.c:449
#3 0x005976d8 in diagnostic_report_diagnostic (context=0xc3d420,
diagnostic=0x7f8a0fe0) at ../../gcc-svn/trunk/gcc/diagnostic.c:404
#4 0x005978fe in internal_error (gmsgid=Variable gmsgid is not
available.
) at ../../gcc-svn/trunk/gcc/diagnostic.c:588
#5 0x007d13c9 in tree_class_check_failed (node=Variable node is not
available.
) at ../../gcc-svn/trunk/gcc/tree.c:6409
#6 0x008c103d in vectorizable_call (stmt=0x2dab2c90,
bsi=0x7f8a1210, vec_stmt=0x7f8a1250) at
../../gcc-svn/trunk/gcc/tree-vect-transform.c:1717
#7 0x008c7b4d in vect_transform_loop (loop_vinfo=0xd11ae0) at
../../gcc-svn/trunk/gcc/tree-vect-transform.c:3882
#8 0x008b4a72 in vectorize_loops () at
../../gcc-svn/trunk/gcc/tree-vectorizer.c:2189
--
Summary: vectorization of sqrt segfaults
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu, i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30093
[Bug fortran/29711] [4.2 only] error_print does not support %N$X
--- Comment #9 from burnus at gcc dot gnu dot org 2006-12-06 20:14 --- I don't know why, but I got again: Fehler: Bei L referenziertes Symbol »s« nicht im Modul »s« gefunden for Error: Symbol 'generic' referenced at (1) not found in module 'mod1' This is with the current SVN version. The string in the .po file is: msgstr Bei %2$L referenziertes Symbol »%1$s« nicht im Modul »%3$s« gefunden I currently don't understand why this happens (and I want to trace an ICE first). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
[Bug ada/30094] New: bogus use of CROSS_COMPILE in adaint.c
adaint.c contains several lines like #if defined (_WIN32) ! defined (__vxworks) ! defined (CROSS_COMPILE) which, although completely uncommented, appear to be trying to detect whether or not the system has an _tfopen function or an fopen function. The function is present on the target system independent of whether this file is being compiled on the target system or on, say, a linux system, so testing CROSS_COMPILE here is inappropriate. -- Summary: bogus use of CROSS_COMPILE in adaint.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geoffk at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30094
[Bug tree-optimization/30032] sqrt(CGAMMA*PRES[j]/DENS[j]) much slower than competing compiler
--- Comment #11 from ubizjak at gmail dot com 2006-12-06 20:31 --- The VLA - normal array for C should be a different issue, where gcc could improve. Could you open a new bug for this problem? Done: PR 30049. Thanks! I think that this bug can be closed as a duplicate of 21466. (21466 should also be closed, as the support code is now in 4.3). *** This bug has been marked as a duplicate of 21466 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30032
[Bug tree-optimization/21466] sqrt() function not vectorized
--- Comment #2 from ubizjak at gmail dot com 2006-12-06 20:31 --- *** Bug 30032 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21466
[Bug tree-optimization/21466] sqrt() function not vectorized
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-06 20:46 --- This is fixed in GCC 4.3: http://gcc.gnu.org/ml/gcc-cvs/2006-12/msg00161.html It was also working yesterday, but now I get an ICE which I think is due to a bad interaction of this patch with the gimple etc. import. - PR 21466 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21466
[Bug gcov-profile/28441] Need atomic increment of gcov counters for MP programs
--- Comment #11 from gnb at melbourne dot sgi dot com 2006-12-06 20:49 --- (In reply to comment #10) [...] the employer disclaimer, which will need to go back across the Pacific and up through some layers of corporate bureaucracy. I'm told this document was signed yesterday, so I expect the paperwork will be complete in a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28441
[Bug fortran/30095] New: [Optimization] ICE in lhd_set_decl_assembler_name, at langhooks.c:165
Hi, the attached Fortran code ICE's at -Os, -O2 and -O3 but compiles at -O0 and -O1. % gfortran -c gfcbug47.f90 -Os gfcbug47.f90: In function 'foo': gfcbug47.f90:6: internal compiler error: in lhd_set_decl_assembler_name, at lang hooks.c:165 Cheers, -ha -- Summary: [Optimization] ICE in lhd_set_decl_assembler_name, at langhooks.c:165 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30095
[Bug fortran/30095] [Optimization] ICE in lhd_set_decl_assembler_name, at langhooks.c:165
--- Comment #1 from anlauf at gmx dot de 2006-12-06 21:04 --- Created an attachment (id=12761) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12761action=view) Sample code crashing gfortran at -Os, -O2 and -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30095
[Bug c++/29729] [4.0/4.1 regression] ICE with template class in template function
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-12-06 21:05 --- Subject: Bug 29729 Author: mmitchel Date: Wed Dec 6 21:04:52 2006 New Revision: 119597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119597 Log: PR c++/29729 * decl2.c (check_member_template): Move check for member templates in local classes to ... * parser.c (cp_parser_template_declaration_after_export): ... here. PR c++/29729 * g++.dg/template/crash63.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash63.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl2.c branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29729
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #32 from fxcoudert at gcc dot gnu dot org 2006-12-06 21:17 --- Subject: Bug 29810 Author: fxcoudert Date: Wed Dec 6 21:17:35 2006 New Revision: 119598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119598 Log: PR libfortran/29810 * intrinsics/c99_functions.c (fmodf, fmodl, floorl): New functions. * c99_protos.h (fmodf, fmodl, floorl): New prototypes. * configure.ac: Check for fmodf, fmod and fmodl. * configure: Regenerate. * config.h.in: Regenerate. * aclocal.m4: Regenerate. * Makefile.in: Regenerate. Modified: branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/Makefile.in branches/gcc-4_2-branch/libgfortran/aclocal.m4 branches/gcc-4_2-branch/libgfortran/c99_protos.h branches/gcc-4_2-branch/libgfortran/config.h.in branches/gcc-4_2-branch/libgfortran/configure branches/gcc-4_2-branch/libgfortran/configure.ac branches/gcc-4_2-branch/libgfortran/intrinsics/c99_functions.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug c++/29729] [4.0 regression] ICE with template class in template function
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-12-06 21:17 --- Fixed in 4.1.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE with |with template class in |template class in template |template function |function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29729
[Bug fortran/30068] Ambigous interfaces not detected
--- Comment #6 from burnus at gcc dot gnu dot org 2006-12-06 21:30 --- Created an attachment (id=12760) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12760action=view) [edit] Fix and testcases. Thanks. It is there, up to some adjustments to interpretation of the standard. Ok, I did some reading and got an email with a quote by Malcolm Cohen and a reply to that quote by Richard Main. See: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/44aa13e0102ec83d/) The relevant part of the standard is as follows (and no, I don't want to discuss the meaning of the word is [cf. c.l.fortran]) -- Fortran 2003, Section 11.2.1; F95, Sec 11.3.2: Two or more accessible entities, other than generic interfaces or defined operators, may have the same identifier only if the identifier is not used to refer to an entity in the scoping unit. Generic interfaces and defined operators are handled as described in section 16.2.3. Except for these cases, the local identifier of any entity given accessibility by a USE statement shall differ from the local identifiers of all other entities accessible to the scoping unit through USE statements and otherwise. [plus some other places for some of the following remarks] That means (if I understand it correctly): a) Using an ambigious symbol in a program, module, procedure twice, which is ambious is forbidden. This makes the BAD8 and BAD9 of the Fortran standard invalid, if they are put in one module foo ... end module or program bar ... end program or subroutine func ... end subroutine block. Or when one is locally declared, which is imported (use) from a module. b) Importing a symbol (subroutine, variable) from two module, which are ambiguous is ok as long as they are not referred. ,only: is enough to count as referred to. c) For generic interfaces and operators the standard is ambiguous. Richard Main thinks that they are treated alike (b), Malcolm Cohn thinks they should be treated more strictly, which already makes use mod1; use mod2 of my example invalid. d) Having e.g. a variable in module and an interface/procedure in another routine is always invalid. Assuming my understanding is correct, the following cases are not correctly treated: a) BAD8 and BAD9 as already the module (module x in the patch) shouldn't compile - or give a warning. [I would go for the warning as the intel compiler does] b) May use mod1; use mod2 should also produce a warning even without , only: as there the generic interface generic is ambigious. Or not. NAG f95 (future version) produces an error, following Malcolm Cohen of NAG which is what sunf95 and g95 are doing as well; ifort accepts it without any warning and Richard Main thinks it is ok. Do either one. [Maybe a warning is not bad - it is between error (some compilers) and silence (other compilers) and we don't take sides ;-) ] c) Gfortran is a bit inconsequent with regards to , only: use mod1 use mod2,only: foo compiles without an error/warning whereas for use mod1,only: foo use mod2 it gives a warning. ifort is consequent in this regard and warns in both cases (for generic interfaces) - or in none (see d). d) Interestingly, if I have module mod1; contains; subroutine foo(); end subroutine foo; end module module mod2; contains; subroutine foo(); end subroutine foo; end module program use mod1, only: foo use mod2 end program Neither ifort nor sunf95 give error or warnings. (For generic interfaces they give a warning (ifort) or an error (sunf95).) (g95 and f95 don't count since they give currently either always an error nor never.) I don't see a reason why generic interfaces should be treated more strictly and thus go with this patch [gfortran gives then a warning]. e) Slightly related: use mod1 ! imports subroutine foo real :: foo end gives the error: Error: Symbol 'foo' at (1) cannot have a type -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30068
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #33 from fxcoudert at gcc dot gnu dot org 2006-12-06 21:50 --- Subject: Bug 29810 Author: fxcoudert Date: Wed Dec 6 21:49:55 2006 New Revision: 119599 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119599 Log: PR libfortran/29810 * intrinsics/c99_functions.c (fmodf, fmodl, floorl): New functions. * c99_protos.h (fmodf, fmodl, floorl): New prototypes. * configure.ac: Check for fmodf, fmod and fmodl. * configure: Regenerate. * config.h.in: Regenerate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/c99_protos.h trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/c99_functions.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #34 from fxcoudert at gcc dot gnu dot org 2006-12-06 21:50 --- Should be completely fixed now. Sorry again. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug fortran/30096] New: Interface bug: gfortran falsely detect ambigious interface, scoping problem?
Hi, the attached legal code fails to compile with gfortran. % gfortran gfcbug48.f90 gfcbug48.f90:30.76: use module2, only : inverse ! -- gfortran does handle this properly 1 Error: Ambiguous interfaces 'inverse_submatrix' and 'inverse_submatrix' in gener ic interface 'inverse' at (1) gfcbug48.f90:30.76: use module2, only : inverse ! -- gfortran does handle this properly 1 Error: Ambiguous interfaces 'inverse_submatrix' and 'inverse_submatrix' in gener ic interface 'inverse' at (1) -- Summary: Interface bug: gfortran falsely detect ambigious interface, scoping problem? Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30096
[Bug fortran/30096] Interface bug: gfortran falsely detect ambigious interface, scoping problem?
--- Comment #1 from anlauf at gmx dot de 2006-12-06 21:58 --- Created an attachment (id=12762) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12762action=view) Interface bug demo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30096
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #35 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-06 22:04 --- Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library Should be completely fixed now. Sorry again. No problem. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug middle-end/30079] [4.3 regression] libgcov.c:785: ICE: in fold_convert, at fold-const.c:2034
--- Comment #9 from aldyh at gcc dot gnu dot org 2006-12-06 22:10 --- Fixed here: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00425.html -- aldyh at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30079
[Bug fortran/29779] [4.3 Regression] vectorizer fortran testcases failing
--- Comment #11 from burnus at gcc dot gnu dot org 2006-12-06 22:10 --- I think this was fixed by: http://gcc.gnu.org/ml/gcc-cvs/2006-11/msg00427.html No it was not. Thanks for checking. (This was actually the PR, for which I asked yesterday on IRC whether it was commited or not.) By the way, you wrote 2006-11-17: Should be submitted this weekend Any new ETA? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
[Bug fortran/30096] Interface bug: gfortran falsely detect ambigious interface, scoping problem?
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-06 22:20 --- I think this is a doublicate of one of symbol ambiguity bugs, which confuse Paul and me the last days. [The problem is not primarily the implementation, the problem is what is right and what is wrong according to the standard. Even real Fortran standard experts cannot agree, see the link to computer.languages.fortran in PR30068, if you are interested.] In any case, it works with my current SVN and the (preliminary) patch from PR 30068 applied. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org BugsThisDependsOn||30068 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-06 22:20:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30096
[Bug fortran/29779] [4.3 Regression] vectorizer fortran testcases failing
--- Comment #12 from dorit at il dot ibm dot com 2006-12-06 22:22 --- By the way, you wrote 2006-11-17: Should be submitted this weekend Any new ETA? It was already submitted: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00110.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
[Bug fortran/30095] ICE in lhd_set_decl_assembler_name, at langhooks.c:165 with -O0
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-06 22:30 --- Confirm with x86_64-unknown-linux-gnu. Shorter test: program gfcbug47 integer, parameter :: k = size (transfer (1, (/' '/))) print *, k end program gfcbug47 #1 0x00703be0 in lhd_set_decl_assembler_name (decl=0x2ab75eae56e0) at gcc/langhooks.c:161 #2 0x0077a151 in decl_assembler_name (decl=0x2ab75eae56e0) at gcc/tree.c:306 #3 0x0079cc08 in make_decl_rtl (decl=0xa3b9b0) at gcc/varasm.c:1054 #4 0x004f447e in nonoverlapping_memrefs_p (x=0x2ab75ecc2660, y=0x2ab75ecc0c40) at gcc/alias.c:2095 #5 0x004f78b0 in true_dependence (mem=0x2ab75ecc2660, mem_mode=VOIDmode, x=0x2ab75ecc0c40, varies=0x759670 rtx_varies_p) at gcc/alias.c:2192 -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.1 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2006-12-06 22:30:10 date|| Summary|[Optimization] ICE in |ICE in |lhd_set_decl_assembler_name,|lhd_set_decl_assembler_name, |at langhooks.c:165 |at langhooks.c:165 with - ||O0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30095
[Bug c++/29980] [4.2/4.3 regression] ICE using attribute in invalid declaration
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-25 23:14:56 |2006-12-06 22:33:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29980
[Bug fortran/30084] segmentation falut when compiling certain code
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-06 22:39 --- Backtrace: 0x0043abf3 in mio_symtree_ref (stp=0xe2b070) at gcc/fortran/module.c:2199 2199 if ((*stp)-n.sym check_unique_name((*stp)-name)) #1 0x0043b526 in mio_expr (ep=0xe2b028) at gcc/fortran/module.c:2637 Even more reduced test case. Note that changing the order of use suppresses the ICE. (ICE occurs with 4.1, 4.2, 4.3) module tao_random_numbers integer, dimension(10) :: s_buffer integer :: s_last = size (s_buffer) end module tao_random_numbers module linalg contains function diag (a) result (d) real, dimension(:), intent(in) :: a real, dimension(size(a)) :: d d = 0.0 end function diag end module linalg module vamp_rest use tao_random_numbers use linalg end module vamp_rest -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.0 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2006-12-06 22:39:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30084
[Bug c++/29730] [4.0/4.1/4.2/4.3 regression] ICE on invalid declaration of template member
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-12-06 22:55 --- Subject: Bug 29730 Author: mmitchel Date: Wed Dec 6 22:54:51 2006 New Revision: 119601 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119601 Log: PR c++/29730 * parser.c (cp_parser_init_declarator): Reject initialization of functions. PR c++/29730 * g++.dg/template/crash64.C: New test. * g++.dg/parse/crash27.C: Adjust error markers. Added: trunk/gcc/testsuite/g++.dg/template/crash64.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash27.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29730
[Bug c++/29730] [4.0/4.1/4.2 regression] ICE on invalid declaration of template member
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-12-06 22:55 --- Fixed in 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1/4.2 regression] ICE |ICE on invalid declaration |on invalid declaration of |of template member |template member http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29730
[Bug fortran/29711] [4.2 only] error_print does not support %N$X
--- Comment #10 from burnus at gcc dot gnu dot org 2006-12-06 22:58 --- Ok, it is simple why it does not work. In the attached and tested patch: + while (ISDIGIT(*format)) + format++; + format++; In SVN: while (ISDIGIT(*format)) /* Skip over the dollar sign. */ format++; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
[Bug other/30083] double quotes in Makefile confuse solaris /bin/sh
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-06 23:05 --- Solaris's /bin/sh is not a POSIX shell, please read http://gcc.gnu.org/install/ and try again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
[Bug fortran/30068] Ambigous interfaces not detected
--- Comment #7 from paulthomas2 at wanadoo dot fr 2006-12-06 23:08 --- Subject: Re: Ambigous interfaces not detected Tobias, c) Gfortran is a bit inconsequent with regards to , only: use mod1 use mod2,only: foo compiles without an error/warning whereas for use mod1,only: foo use mod2 The lack of symmetry is in the setting of attr.ambiguous - I don't know why. My head is hurting and I am going to bed. The other problem is fixed. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30068
[Bug middle-end/30086] Initialize struct to avoid warnings shouldn't be needed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-06 23:14 ---
Depends how the source looks, it might be actually used uninitialized which
means the code is undefined anyways.
Can you attach the preprocessed source?
I have seen stuff like:
struct a{int t; int t1};
void f(struct a);
void g(void)
{
struct a b;
b.t = 1;
f(b);
}
(maybe a little more complex but you get the idea).
How does GCC know that not all the elements of b are not used.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30086
[Bug c++/30097] New: Access control fails on nested protected base member
Protected members of a base class are accessible in derived class if nested too
deeply:
class base_t {
protected:
unsigned x;
union {
unsigned y;
struct {
unsigned z;
};
};
};
class child_t : public base_t {
public:
void foo () {
base_t base;
base.x = 0; // access denied (ok)
base.y = 0; // access denied (ok)
base.z = 0; // access permitted (not ok)
};
};
compiling the above produces the following output:
In member function `void child_t::foo()':
4: error: `unsigned int base_t::x' is protected
19: error: within this context
6: error: `unsigned int base_t::anonymous union::y' is protected
20: error: within this context
--
Summary: Access control fails on nested protected base member
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefan dot gotz at intel dot com
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30097
[Bug c++/30097] Access control fails on nested protected base member
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-06 23:37 --- This is an issue with anonymous structs and is a dup of bug 24926. Oh and anonymous structs are extensions. *** This bug has been marked as a duplicate of 24926 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30097
[Bug c++/24926] gcc ignores access level violation for anonymous structs
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-06 23:37 --- *** Bug 30097 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||stefan dot gotz at intel dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24926
[Bug c++/29980] [4.2/4.3 regression] ICE using attribute in invalid declaration
--- Comment #2 from patchapp at dberlin dot org 2006-12-07 00:05 --- Subject: Bug number PR c++/29980 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00426.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29980
[Bug fortran/29711] [4.2 only] error_print does not support %N$X
--- Comment #11 from patchapp at dberlin dot org 2006-12-07 00:05 --- Subject: Bug number PR29711 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00430.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #17 from elizabeth dot l dot yip at boeing dot com 2006-12-07 01:37 --- Paul, I located the following binary and loaded it on my dell 670 (SUSE 9.3): gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/var/tmp/gfortran-20060627/irun --enable-languages=c,fortran Thread model: posix gcc version 4.2.0 20060627 (experimental) This versions works for the little code in bug 30025 and also works on my entire application, which involves OPENMPI and SCALAPACK and the outofcore solver based on SCALAPACK and various libraries by different authors with very different styles of coding. (I want to thank the gfortran team!!!) We are talking about the same machine and the same operating system. All the x86_64 binaries are from http://quatramaran.ens.fr/~coudert/gfortran. I am surprised you said you didn't think anything changed since January 2006. By the way, Jakub's code works on the June version without optimization. It fails if -O is used. It fails with gcc version 4.3.0 20061114 even without optimization. I understand perfectly that you need to fix the bug, and the bug involves much more than my applications, and I wouldn't feel any better if someone told me an earlier version of my code works. I just hope extra information helps. Good luck! Elizabeth -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-12-07 04:48 --- On my machine, with an unoptimized cc1plus (IE stage1), the first one, at -O2 takes 150meg of memory total, and 221 seconds, with most of the time being verifiers. This is with local PTA changes to speed up PTA TOTAL : 221.5817.76 271.63 note: tree SSA verifier : 51.90 (23%) usr 0.89 ( 5%) sys 56.19 (21%) wall 74 kB ( 0%) ggc tree STMT verifier: 40.15 (18%) usr 0.88 ( 5%) sys 41.12 (15%) wall etc The *other* case is spending all it's alias time checking for dups in add_may_alias, which diego's patch should fix. There is also a ton of time elsewhere: tree alias analysis : 71.28 (21%) usr 1.66 ( 9%) sys 114.75 (26%) wall 18776 kB ( 5%) ggc tree SSA verifier : 33.40 (10%) usr 0.43 ( 2%) sys 34.55 ( 8%) wall 259 kB ( 0%) ggc tree STMT verifier: 30.43 ( 9%) usr 0.64 ( 3%) sys 31.04 ( 7%) wall 0 kB ( 0%) ggc PRE : 64.49 (19%) usr 0.64 ( 3%) sys 75.84 (17%) wall 1086 kB ( 0%) ggc scheduling 2 : 46.21 (14%) usr 0.35 ( 2%) sys 62.71 (14%) wall 2328 kB ( 1%) ggc TOTAL : 339.0919.05 444.66 (it was in a debugger for about 100s to get some idea of what was going on). But on my machine, it still only uses 350 meg of memory On x86_64, i expect about double memory usage. I also expect if i tested bootstrapped optimized compilers, i'd get the same times you are expecting, excluding checking time This leaves a few possibilities: 1 My local PTA improvements are helping this 2 Something is very different on x86_64 3 My preprocessing using Apple G++ 4.0.1 is giving very different code to play with than mainline does 4 The regression is already fixed :) I can either send you the patch to test for 1, or you can wait a few days for me to commit it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug tree-optimization/30098] New: missed value numbering optimization
The following 2 functions should be compiled to the same thing.
This is a test from Briggs' compiler benchmarks.
void vnum_test8(int *data)
{
int i;
int stop = data[3];
int m = data[4];
int n = m;
for (i=0; istop; i++) {
int k = data[2];
data[k] = 2;
data[0] = m - n;
k = data[1];
m = m + k;
n = n + k;
}
}
void vnum_result8(int *data)
{
int i;
int stop = data[3];
for (i=0; istop; i++) {
int k = data[2];
data[k] = 2;
data[0] = 0;
}
}
--
Summary: missed value numbering optimization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30098
[Bug tree-optimization/30099] New: missed value numbering optimization (conditional-based assertions)
The following 2 functions should be compiled to the same assembly.
This is one of Briggs' compiler benchmarks.
void vnum_test10(int *data)
{
int i = data[0];
int m = i + 1;
int j = data[1];
int n = j + 1;
data[2] = m + n;
if (i == j)
data[3] = (m - n) * 21;
}
void vnum_result10(int *data)
{
int i = data[0];
int m = i + 1;
int j = data[1];
int n = j + 1;
data[2] = m + n;
if (i == j)
data[3] = 0;
}
--
Summary: missed value numbering optimization (conditional-based
assertions)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30099
[Bug tree-optimization/30100] New: missed value numbering optimization (conditional value numbers)
The following 2 functions should be compiled to the same assembly.
This is one of Briggs' compiler benchmarks.
void vnum_test11(int *data)
{
int n;
int stop = data[3];
int j = data[1];
int k = j;
int i = 1;
for (n=0; nstop; n++) {
if (j != k) i = 2;
if (i != 1) k = 2;
data[data[2]] = 2;
}
data[1] = i;
}
void vnum_result11(int *data)
{
int n;
int stop = data[3];
for (n=0; nstop; n++)
data[data[2]] = 2;
data[1] = 1;
}
--
Summary: missed value numbering optimization (conditional value
numbers)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30100
[Bug tree-optimization/30101] New: missed value numbering optimization (cprop+valnum)
The following 2 functions should be compiled to the same assembly.
This is one of Briggs' compiler benchmarks.
void vnum_test12(int *data)
{
int n;
int stop = data[3];
int j = data[1];
int k = j;
int i = 1;
for (n=0; nstop; n++) {
if (j != k) i = 2;
i = 2 - i;
if (i != 1) k = 2;
data[data[2]] = 2;
}
data[1] = i;
}
void vnum_result12(int *data)
{
int n;
int stop = data[3];
for (n=0; nstop; n++)
data[data[2]] = 2;
data[1] = 1;
}
--
Summary: missed value numbering optimization (cprop+valnum)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30101
[Bug tree-optimization/30102] New: missed strength reduction optimization (irreducible loops)
The following 2 functions should be compiled to the same assembly.
This is one of Briggs' compiler benchmarks.
void strength_test4(int *data)
{
int i;
if (data[1]) {
i = 2;
goto here;
}
i = 0;
do {
i = i + 1;
here:
data[data[2]] = 2;
} while (i * 21 data[3]);
}
void strength_result4(int *data)
{
int i;
if (data[1]) {
i = 42;
goto here;
}
i = 0;
do {
i = i + 21;
here:
data[data[2]] = 2;
} while (i data[3]);
}
--
Summary: missed strength reduction optimization (irreducible
loops)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30102
[Bug tree-optimization/30103] New: missed strength reduction optimization (test replacement)
The following 2 functions should be compiled to the same assembly.
This is one of Briggs' compiler benchmarks.
void strength_test10(int *data)
{
int stop = data[3];
int i = 0;
do {
data[data[2]] = 21 * i;
i = i + 1;
} while (i stop);
}
void strength_result10(int *data)
{
int stop = data[3] * 21;
int i = 0;
do {
data[data[2]] = i;
i = i + 21;
} while (i stop);
}
--
Summary: missed strength reduction optimization (test
replacement)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30103
[Bug tree-optimization/30104] New: missed code motion optimization (invariant control structures)
The following 2 functions should be compiled to the same assembly.
This is one of Briggs' compiler benchmarks.
void motion_test10(int *data)
{
int j;
int p = data[1];
int i = data[0];
do {
if (p)
j = 1;
else
j = 2;
i = i + j;
data[data[2]] = 2;
} while (i data[3]);
}
void motion_result10(int *data)
{
int j;
int p = data[1];
int i = data[0];
if (p)
j = 1;
else
j = 2;
do {
i = i + j;
data[data[2]] = 2;
} while (i data[3]);
}
--
Summary: missed code motion optimization (invariant control
structures)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30104
[Bug tree-optimization/30105] New: missed PRE
The following 2 functions should be compiled to the same assembly.
This is one of Briggs' compiler benchmarks.
void motion_test2(int *data)
{
int j;
int i = 1;
if (data[1]) {
data[data[2]] = 2;
j = data[0] + data[3];
i = i + j;
}
data[4] = data[0] + data[3];
data[5] = i;
}
void motion_result2(int *data)
{
int j;
int i = 1;
if (data[1]) {
data[data[2]] = 2;
j = data[0] + data[3];
i = i + j;
}
else
j = data[0] + data[3];
data[4] = j;
data[5] = i;
}
--
Summary: missed PRE
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30105
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Comment #40 from mark at codesourcery dot com 2006-12-07 06:35 --- Subject: Re: Can't use __attribute__ ((visibility (hidden))) to hide a symbol hjl at lucon dot org wrote: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00397.html I'm still not happy with the cgraph_optimize change. There's no reason for ELF to be special in this regard. The problem is that I don't think you can move process_pending_assemble_externals to the end of the compilation; on some systems the external declaration needs to appear before any reference to them. You could try just removing the call to process_pending_assemble_externals in cgraph_optimize, since there is another call at the end of compile_file -- but I'm afraid you'll break AIX and HP-UX. You would have to ask people to test on those platforms. Anyhow, with -fno-unit-at-a-time, we still call ASM_OUTPUT_EXTERNAL as we process declarations. I think we should just give up and not worry about whether or not the functions are referenced. All that will happen is that we'll get bigger .o files; the linker will rip all unreferenced functions out anyhow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug c++/30088] Unexpected compilation results: -O1 vs. -O1 -fstrict-aliasing
--- Comment #2 from bangerth at dealii dot org 2006-12-07 07:17 --- Confirmed. There are also no warnings with -Wstrict-aliasing. The code certainly seems ok, so this is either a bug in gcc or libstdc++... W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-07 07:17:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30088
