[Bug libfortran/25370] Bad value for sqrt of double complex
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-04-03 06:51 --- Recently updated glibc on my i686-pc-linux-gnu box and csqrt is now working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25370
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #8 from kgardas at objectsecurity dot com 2006-04-03 06:59
---
Subject: Re: linking of C++ app fail on OpenBSD 3.9 due
POSIX threading unresolved symbols
Now if this works, then we have a problem in libstdc++ check to enable weakref
for some reason.
Could you be so kind and point me into direction where the check is made?
Anyway, greping thorough sources for weakref and thorough build
directory I've found this (in build dir):
$ find . -name 'config*' -exec grep weakref \{} \; -print
configure:13473: checking assembler for .weakref
conftest.s:1: Error: unknown pseudo-op: `.weakref'
.weakref foobar, barfnot
gcc_cv_as_weakref=no
./gcc/config.log
gcc_cv_as_weakref=${gcc_cv_as_weakref=no}
./gcc/config.cache
configure:13473: checking assembler for .weakref
conftest.s:1: Error: unknown pseudo-op: `.weakref'
.weakref foobar, barfnot
gcc_cv_as_weakref=no
./prev-gcc/config.log
gcc_cv_as_weakref=${gcc_cv_as_weakref=no}
./prev-gcc/config.cache
configure:13473: checking assembler for .weakref
conftest.s:1: Error: unknown pseudo-op: `.weakref'
.weakref foobar, barfnot
gcc_cv_as_weakref=no
./stage1-gcc/config.log
gcc_cv_as_weakref=${gcc_cv_as_weakref=no}
./stage1-gcc/config.cache
$
which seems to me .weakref is not supported by assembler. I've tried to
syntetize back the test case and got this:
$ cat /tmp/weakref.s
.weakref foobar, barfnot
$ as /tmp/weakref.s
/tmp/weakref.s: Assembler messages:
/tmp/weakref.s:1: Error: unknown pseudo-op: `.weakref'
$ as --version
GNU assembler 2.15
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `i386-unknown-openbsd3.9'.
$
It's interesting it's working in gcc then...
Karel
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-03 07:06 --- (In reply to comment #8) It's interesting it's working in gcc then... Not really as we emulate what the weakref asm op does with weak and alias. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #10 from kgardas at objectsecurity dot com 2006-04-03 07:08 --- Subject: Re: linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols Small addition to previous post. Although .weakref is not supported, .weak is: $ cat /tmp/weak-conftest.s .weak foobar $ as /tmp/weak-conftest.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug translation/26987] German translation of gcc 4.1
--- Comment #5 from stigge at antcom dot de 2006-04-03 07:12 --- It's not that we need special casing for a certain language: The TP robot is generally broken (doesn't respond to translator's requests). I reported it there several times, to no avail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26987
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-03 07:21
---
Wait a minute, libstdc++ is being built only as a static library looking at the
error message from comment #0. But that should not really.
Can you try an objective-C compiling for me to see if it is just libstdc++ that
is messed up?
The Objective-C runtime uses the same files as libstdc++ does for threading
The simple Objective-C program would be:
#include objc/Object.h
int main(void)
{
[Object new];
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug middle-end/26996] New: interpret_rhs_modify_expr calls fold_convert (vector_type, -1)
We ICE on the air Polyhedron test with -march=pentium4 -ffast-math -funroll-loops -O3 -ftree-vectorize: /space/rguenther/tramp3d/pb05/lin/source/air.f90: In function bound: /space/rguenther/tramp3d/pb05/lin/source/air.f90:1119: internal compiler error: in fold_convert, at fold-const.c:2089 #1 0x082ab8ca in fold_convert (type=0xb797d730, arg=0xb7cae7e0) at /space/rguenther/src/svn/gcc/gcc/fold-const.c:2089 2089 gcc_assert (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig))); (gdb) call debug_tree(arg) integer_cst 0xb7cae7e0 type integer_type 0xb7cbd284 int4 constant invariant -1 (gdb) call debug_tree(type) vector_type 0xb797d730 type real_type 0xb7cbd9b4 real8 DF size integer_cst 0xb7cae510 constant invariant 64 unit size integer_cst 0xb7cae528 constant invariant 8 align 64 symtab 0 alias set 4 precision 64 pointer_to_this pointer_type 0xb7cbdac8 V2DF size integer_cst 0xb7cae648 type integer_type 0xb7cbd05c bit_size_type constant invariant 128 unit size integer_cst 0xb7cae660 type integer_type 0xb7cbd000 constant invariant 16 align 128 symtab 0 alias set -1 nunits 2 (gdb) up #2 0x085ec360 in interpret_rhs_modify_expr (loop=0x8a4e110, at_stmt=0xb7983798, opnd1=0xb797eb20, type=0xb797d730) at /space/rguenther/src/svn/gcc/gcc/tree-scalar-evolution.c:1659 1658 /* TYPE may be integer, real or complex, so use fold_convert. */ 1659 res = chrec_fold_multiply (type, chrec10, 1660 fold_convert (type, integer_minus_one_node)); But we can only build a zero vector in fold_convert. -- Summary: interpret_rhs_modify_expr calls fold_convert (vector_type, -1) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end 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=26996
[Bug middle-end/26996] interpret_rhs_modify_expr calls fold_convert (vector_type, -1)
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-03 07:54 --- The simplest solution looks like to punt on vector types in interpret_rhs_modify_expr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26996
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #12 from kgardas at objectsecurity dot com 2006-04-03 08:01 --- Subject: Re: linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols Sorry, I've enabled only c++ for this build and I would prefer not to rebuild if possible, since c/c++ took about 4-5 hours to built. Anyway, I consider libstdc++ support to be quite broken on OpenBSD. You named it, shared library is missing and I've also found that other shared libs seems to be presented: $ find . -name '*.so*' ./lib/libssp.so.0.0 ./lib/libgcc-math.so.0.0 ./lib/libgomp.so.1.0 $ if possible please write me what to test/check and I will do this here on OBSD of course. If you point me to the direction of libstdc++ hacker manual (to found out which autoconf is required), I'm able to also check some configure.ac hacks for you. Anyway, if you consider ObjC test important, let me know and I will start rebuild immediatelly. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug c++/26965] Unnecessary debug info for unused consts in C++
--- Comment #3 from pluto at agmk dot net 2006-04-03 08:07 --- (In reply to comment #0) (...) This is as expected: they are not used by any actual code, so there is no need to emit debug info for them. so, what for is the -feliminate-unused-debug-symbols? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
[Bug c++/26997] New: g++ reports incorrect error message when the identifier with error occurs earlier on the same line
The program below reports the following compiler errors:
bug.cpp:17: error: expected primary-expression before '*' token
bug.cpp:17: error: expected primary-expression before ')' token
bug.cpp:17: error: expected `;' before 'malloc'
which seem to refer to the first occurence of identifier t
on the line 17. However, that is a correct occurence.
The mistake is later on the line, but the error message
of the compiler is misleading. This is not a serious issue...
$ uname -a
Linux ... 2.6.12-1-386 #1 Tue Sep 27 12:41:08 JST 2005 i686 GNU/Linux
$ g++ --version
g++ (GCC) 4.0.3 (Debian 4.0.3-1)
libc6: 2.3.6-3
libstdc++6 4.0.3-1
---
#include stdlib.h
typedef struct { int a; int b; } t;
int main()
{
t v1, *v2;
t *v3;
v2 = v1;
v1.a = 2;
// correct code:
//v3 = (t *)malloc(sizeof(t) * v2-a);
// code with a mistake:
v3 = (t *)malloc(sizeof(t) * t-a);
return 0;
}
-
--
Summary: g++ reports incorrect error message when the identifier
with error occurs earlier on the same line
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pavel dot petrovic at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26997
[Bug tree-optimization/26939] loop number of iterations analysis confused by what PRE did (PRE is doing its job)
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-04-03 09:12 --- With the patch we now can no longer figure out the number of iterations of the inner loop, because we have an exit condition of i1D.1522_6 != 2147483647 now!? Which we cannot simplify against i1D.1522_6 = 0 (I will extend my compare_conditions patch to handle this case - but I have to think about it some more). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26939] loop number of iterations analysis confused by what PRE did (PRE is doing its job)
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-04-03 09:19 --- Hmm, this cannot be simplified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26992] [4.2 Regression] Internal Compiler Error in dwarf2out.c:7607 build_polynomial_chrec
--- Comment #4 from spop at gcc dot gnu dot org 2006-04-03 09:59 --- Subject: Bug 26992 Author: spop Date: Mon Apr 3 09:59:38 2006 New Revision: 112635 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112635 Log: PR bootstrap/26992 * tree-scalar-evolution.c (compute_overall_effect_of_inner_loop, chrec_is_positive, set_nb_iterations_in_loop): Use a variable for the type of nb_iter. (instantiate_parameters_1): Convert the operands before calling chrec_fold_minus, chrec_fold_plus, or chrec_fold_multiply. * tree-data-ref.c (can_use_analyze_subscript_affine_affine): Same. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26992
[Bug bootstrap/26998] New: bootstrap failure on ia64 building libdecnumber
Bootstrap fails because we have Starting program: /abuild/rguenther/obj/prev-gcc/cc1 -quiet -v -I../../trunk/libdecnumber -I. -I../../trunk/libdecnumber -I. -iprefix /abuild/rguenther/obj/prev-gcc/../lib/gcc/ia64-unknown-linux-gnu/4.2.0/ -isystem /abuild/rguenther/obj/./prev-gcc/include ../../trunk/libdecnumber/decNumber.c -quiet -dumpbase decNumber.c -auxbase decNumber -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -version -o /tmp/ccv4gMH7.s Program received signal SIGSEGV, Segmentation fault. 0x40fa2241 in compare_values (val1=0x0, val2=0x20344b40) at ../../trunk/gcc/tree-vrp.c:432 432 gcc_assert (POINTER_TYPE_P (TREE_TYPE (val1)) (gdb) up #1 0x40fafe30 in extract_range_from_unary_expr ( vr=0x607fffa2e6c8, expr=0x207cf380) at ../../trunk/gcc/tree-vrp.c:1861 1861 cmp = compare_values (min, max); (gdb) call debug_tree(expr) negate_expr 0x207cf380 type integer_type 0x204decb0 int32_t sizes-gimplified asm_written public SI size integer_cst 0x20344ba0 constant invariant 32 unit size integer_cst 0x203446c0 constant invariant 4 align 32 symtab 3521056 alias set -1 precision 32 min integer_cst 0x20344b10 -2147483648 max integer_cst 0x20344b40 2147483647 pointer_to_this pointer_type 0x2050c420 arg 0 ssa_name 0x208c78e0 type integer_type 0x204decb0 int32_t visited var var_decl 0x207d4bb0 result def_stmt phi_node 0x2034a200 version 11 -- Summary: bootstrap failure on ia64 building libdecnumber Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: bootstrap 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=26998
[Bug bootstrap/26998] bootstrap failure on ia64 building libdecnumber
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-03 10:17 --- Created an attachment (id=11187) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11187action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug bootstrap/26998] bootstrap failure on ia64 building libdecnumber
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-03 10:17 --- Jeff messed with VRP, so I guess he may have a clue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug bootstrap/26999] New: bootstrap failure with --disable-libdecnumber
Trying to workaround the ia64 bootstrap problem with --disable-libdecnumber causes gcc -c -DUSE_LIBUNWIND_EXCEPTIONS -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber -I../libdecnumber../../trunk/gcc/dfp.c -o dfp.o In file included from ../../trunk/gcc/../libdecnumber/decNumber.h:30, from ../../trunk/gcc/../libdecnumber/decimal128.h:50, from ../../trunk/gcc/dfp.c:34: ../../trunk/gcc/../libdecnumber/decContext.h:43:50: error: gstdint.h: No such file or directory In file included from ../../trunk/gcc/../libdecnumber/decNumber.h:30, from ../../trunk/gcc/../libdecnumber/decimal128.h:50, from ../../trunk/gcc/dfp.c:34: ../../trunk/gcc/../libdecnumber/decContext.h:69: error: expected specifier-qualifier-list before uint32_t -- Summary: bootstrap failure with --disable-libdecnumber Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap 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=26999
[Bug c++/27000] New: Problems with latest visibility changes
On the testcases below GCC marks even instantiated templates with the currently pushed visibility, in case of the first testcase that's hidden (anonymous namespace) and in the third testcase hidden as well (namespace with visibility attribute). But the template really wasn't declared as hidden and making it hidden causes serious problems (e.g. depending on which order you link the .o files from the testcases together, for _ZN1SIiEC1ERKi and _ZN1SIiED1Ev wins either default or hidden visibility. If it is e.g. linked into a shared library and default visibility wins, then on x86_64 it won't even link, as first and third .o files rely on the symbols being hidden. -- Summary: Problems with latest visibility changes Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
[Bug c++/27000] Problems with latest visibility changes
--- Comment #1 from jakub at gcc dot gnu dot org 2006-04-03 11:11 --- Created an attachment (id=11188) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11188action=view) firsttest.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
[Bug c++/27000] Problems with latest visibility changes
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-03 11:11 --- Created an attachment (id=11189) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11189action=view) secondtest.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
[Bug c++/27000] Problems with latest visibility changes
--- Comment #3 from jakub at gcc dot gnu dot org 2006-04-03 11:12 --- Created an attachment (id=11190) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11190action=view) thirdtest.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
[Bug c++/27000] Problems with latest visibility changes
--- Comment #4 from jakub at gcc dot gnu dot org 2006-04-03 11:18 --- I'd say we should remember template's visibility and use that during instantiation, rather than the currently pushed visibility. The question is if we want to do that for all template instantiations, or have cases where we override it based on e.g. template arguments. Say the S template from the testcase is instantiated with T = some_type_declared_in_anonymous_namespace. In this case the template instantation can't be used from outside of current .o file (except if export is ever implemented), so perhaps we could make the template instantiation hidden too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Comment #24 from bonzini at gnu dot org 2006-04-03 11:20 --- Subject: Bug 19653 Author: bonzini Date: Mon Apr 3 11:20:07 2006 New Revision: 112637 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112637 Log: 2005-08-08 Paolo Bonzini [EMAIL PROTECTED] Dale Johannesen [EMAIL PROTECTED] PR target/19653 * regclass.c (struct reg_pref): Update documentation. (regclass): Set prefclass to NO_REGS if memory is the best option. (record_reg_classes): Cope with a prefclass set to NO_REGS. * reload.c (find_reloads): Take PREFERRED_OUTPUT_RELOAD_CLASS into account. For non-registers, equate an empty preferred reload class to a `!' in the constraint; move the if clause to do so after those that reject the insn. (push_reload): Allow PREFERRED_*_RELOAD_CLASS to liberally return NO_REGS. (find_dummy_reload): Likewise. * doc/tm.texi (Register Classes): Document what it means if PREFERRED_*_RELOAD_CLASS return NO_REGS. * config/i386/i386.c (ix86_preferred_reload_class): Force using SSE registers (and return NO_REGS for floating-point constants) if math is done with SSE. (ix86_preferred_output_reload_class): New. * config/i386/i386-protos.h (ix86_preferred_output_reload_class): New. * config/i386/i386.h (PREFERRED_OUTPUT_RELOAD_CLASS): New. * config/i386/i386.md: Remove # register preferences. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.md trunk/gcc/doc/tm.texi trunk/gcc/regclass.c trunk/gcc/reload.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Comment #25 from bonzini at gnu dot org 2006-04-03 11:20 --- fixed on mainline. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug middle-end/27001] New: ICE with -fschedule-insns -fstack-protector-all
The following code snippet causes an ICE on x86_64-unknown-linux-gnu
when compiled with -fschedule-insns -fstack-protector-all.
This happens since 4.1.0 when -fstack-protector-all was introduced.
=
int foo(int i)
{
i /= i+1;
return 0;
}
=
bug.c: In function 'foo':
bug.c:5: error: unable to find a register to spill in class 'AREG'
bug.c:5: error: this is the insn:
(insn 11 21 27 2 (parallel [
(set (reg:SI 1 dx [61])
(div:SI (reg:SI 1 dx [orig:63 i ] [63])
(reg:SI 2 cx [orig:59 D.1879 ] [59])))
(set (reg:SI 2 cx [62])
(mod:SI (reg:SI 1 dx [orig:63 i ] [63])
(reg:SI 2 cx [orig:59 D.1879 ] [59])))
(clobber (reg:CC 17 flags))
]) 277 {*divmodsi4_nocltd} (nil)
(expr_list:REG_DEAD (reg:SI 1 dx [orig:63 i ] [63])
(expr_list:REG_DEAD (reg:SI 2 cx [orig:59 D.1879 ] [59])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 2 cx [62])
(nil))
bug.c:5: internal compiler error: in spill_failure, at reload1.c:1912
Please submit a full bug report, [etc.]
--
Summary: ICE with -fschedule-insns -fstack-protector-all
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27001
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-03 11:25 --- Also fails on x86_64 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|bootstrap failure on ia64 |bootstrap failure building |building libdecnumber |libdecnumber, ICE in ||compare_values, tree- ||vrp.c:432 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-03 11:26 --- Created an attachment (id=11191) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11191action=view) patch that may be needed to trigger the problem This patch is what I am trying to bootstrap/regtest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug middle-end/27002] New: ICE with -fipa-pta when calling a function
The following Fortran code snippet causes an ICE (segfault) when compiled with -fipa-pta -O: == subroutine BAR() call FOO (0) end subroutine BAR == -- Summary: ICE with -fipa-pta when calling a function Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, monitored Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27002
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-03 11:33 ---
Note we have NEGATE_EXPR X where X has VR of
(gdb) print vr0
$4 = {type = VR_ANTI_RANGE, min = 0x2a95891b40, max = 0x2a95891b40,
equiv = 0xf73b20}
(same min/max!) Also,
if (code == NEGATE_EXPR
!TYPE_UNSIGNED (TREE_TYPE (expr)))
{
/* NEGATE_EXPR flips the range around. */
min = (vr0.max == TYPE_MAX_VALUE (TREE_TYPE (expr)) !flag_wrapv)
? TYPE_MIN_VALUE (TREE_TYPE (expr))
: fold_unary_to_constant (code, TREE_TYPE (expr), vr0.max);
max = (vr0.min == TYPE_MIN_VALUE (TREE_TYPE (expr)) !flag_wrapv)
? TYPE_MAX_VALUE (TREE_TYPE (expr))
: fold_unary_to_constant (code, TREE_TYPE (expr), vr0.min);
}
looks bogus then, as vr0.max != TYPE_MAX_VALUE (..expr) and
fold_unary_to_constant then fails to invert vr0.max because of overflow issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-03 11:35 ---
Something like
Index: tree-vrp.c
===
*** tree-vrp.c (revision 112634)
--- tree-vrp.c (working copy)
*** extract_range_from_unary_expr (value_ran
*** 1858,1863
--- 1858,1868
max = fold_unary_to_constant (code, TREE_TYPE (expr), vr0.max);
}
+ if (!min || !max)
+ {
+ set_value_range_to_varying (vr);
+ return;
+ }
cmp = compare_values (min, max);
if (cmp == -2 || cmp == 1)
{
should fix it (it lets my bootstrap continue at least).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug tree-optimization/27003] New: [4.0 Regression] ivcanon bug
unsigned int
foo (unsigned int x)
{
unsigned int r = x;
while (--x)
r *= x;
return r;
}
unsigned long long
bar (unsigned long long x)
{
unsigned long long r = x;
while (--x)
r *= x;
return r;
}
extern void abort (void);
int
main (void)
{
if (foo (5) != 120 || bar (5) != 120)
abort ();
return 0;
}
is miscompiled at -Os on i?86-linux (though, only when built with 32-bit HWI,
e.g. works just fine with x86_64-linux gcc -m32).
During ivcanon pass, induction variable is initialized to 0x40005 rather
than
5, which suggests a bug in loop handling of multi-word constants.
--
Summary: [4.0 Regression] ivcanon bug
Product: gcc
Version: 4.0.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC host triplet: i686-linux
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27003
[Bug libgcj/23682] gnu.java.nio.SelectorImpl.select(long) throws ArrayIndexOutOfBoundsException
--- Comment #3 from green at redhat dot com 2006-04-03 13:02 ---
Azureus users on FC5 see this as well (gcj 4.1.0). Here's a slightly
different stack trace.
[12:31:21.648] {stderr} DEBUG::Mon Apr 03 12:31:21 GMT
2006::com.aelitis.azureus.core.networkmanager.VirtualChannelSelector::select::-1:
[12:31:21.649] {stderr} Caught exception on selector.select() op: 3
[12:31:21.650] {stderr}
ReadController::readSelectorLoop::-1,ReadController::access$0::-1,ReadController$1::runSupport::-1,AEThread::run::-1
[12:31:21.718] {stderr} java.lang.ArrayIndexOutOfBoundsException: 3
[12:31:21.719] {stderr}at gnu.java.nio.SelectorImpl.getFDsAsArray
(libgcj.so.7)
[12:31:21.720] {stderr}at gnu.java.nio.SelectorImpl.select (libgcj.so.7)
[12:31:21.720] {stderr}at
com.aelitis.azureus.core.networkmanager.impl.VirtualChannelSelectorImpl.select
(Azureus2.jar.so)
[12:31:21.721] {stderr}at
com.aelitis.azureus.core.networkmanager.VirtualChannelSelector.select
(Azureus2.jar.so)
[12:31:21.721] {stderr}at
com.aelitis.azureus.core.networkmanager.impl.ReadController.readSelectorLoop
(Azureus2.jar.so)
[12:31:21.722] {stderr}at
com.aelitis.azureus.core.networkmanager.impl.ReadController.access$0
(Azureus2.jar.so)
[12:31:21.722] {stderr}at
com.aelitis.azureus.core.networkmanager.impl.ReadController$1.runSupport
(Azureus2.jar.so)
[12:31:21.723] {stderr}at org.gudy.azureus2.core3.util.AEThread.run
(Azureus2.jar.so)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23682
[Bug tree-optimization/26830] [4.1/4.2 Regression] Insane amount of compile-time / memory needed at -O1 and above
--- Comment #25 from bonzini at gnu dot org 2006-04-03 13:37 --- Subject: Bug 26830 Author: bonzini Date: Mon Apr 3 13:37:07 2006 New Revision: 112639 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112639 Log: 2006-04-03 Paolo Bonzini [EMAIL PROTECTED] PR tree-optimization/26830 * tree-cfg.c (tree_duplicate_sese_region): Do not update SSA. * tree-ssa-loop-ch.c (copy_loop_headers): Count successfully duplicated headers and, if there was any, update SSA at the end. Backport from mainline: 2006-03-30 Paolo Bonzini [EMAIL PROTECTED] * tree-ssa-copy.c (copy_prop_visit_assignment): Do not check loop depth. (copy_prop_visit_stmt): Remove write-only variable ann. (init_copy_prop): Check variable loop depth here. Do not simulate memory-tag and virtual operand PHIs except for store copy prop. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-cfg.c branches/gcc-4_1-branch/gcc/tree-ssa-copy.c branches/gcc-4_1-branch/gcc/tree-ssa-loop-ch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #26 from bonzini at gnu dot org 2006-04-03 13:40 --- compile-time should be fixed on 4.1 (richard, could you confirm). spinning a separate bug for the salias memory hog problems. zdenek wanted to investigate manual SSA update of real operands for 4.2 -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|bonzini at gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Keywords|alias, memory-hog | Known to work||4.0.3 4.1.1 Summary|[4.1/4.2 Regression] Insane |[4.2 Regression] Repeated |amount of compile-time /|SSA update during loop |memory needed at -O1 and|header copying |above | Version|4.1.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/27004] New: [4.1/4.2 Regression] Insane amount of memory needed at -O1 and above because of salias
spinning a separate bug from PR26830. we are creating a lot of field memory tags, each of which is present in a 900-argument phi, which causes us to use more memory than 4.0. to some extent this is unavoidable, but I wonder if we could throttle things down a bit? -- Summary: [4.1/4.2 Regression] Insane amount of memory needed at - O1 and above because of salias Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: memory-hog, alias Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gnu dot org BugsThisDependsOn: 26830 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #27 from rakdver at gcc dot gnu dot org 2006-04-03 14:16 --- With a bit simplified testcase (my computer does not have enough memory for this one), we spend 30% of compile time in rewrite_update_phi_arguments. However, only 1.6% (less then 1% of compile time) of the rewrite_update_phi_arguments calls actually changes anything, so the rest is just traversing a dominance tree and visiting the phi nodes; perhaps this could be optimized somehow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #8 from aph at gcc dot gnu dot org 2006-04-03 14:31 --- Subject: Bug 26858 Author: aph Date: Mon Apr 3 14:31:56 2006 New Revision: 112640 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112640 Log: 2006-04-03 Andrew Haley [EMAIL PROTECTED] PR java/26858 * expr.c (build_field_ref): Don't check the field offset if flag_syntax_only. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug tree-optimization/27004] [4.1/4.2 Regression] Insane amount of memory needed at -O1 and above because of salias
--- Comment #1 from dberlin at gcc dot gnu dot org 2006-04-03 14:37 --- Subject: Re: New: [4.1/4.2 Regression] Insane amount of memory needed at -O1 and above because of salias On Mon, 2006-04-03 at 13:43 +, bonzini at gnu dot org wrote: spinning a separate bug from PR26830. we are creating a lot of field memory tags, each of which is present in a 900-argument phi, which causes us to use more memory than 4.0. to some extent this is unavoidable, but I wonder if we could throttle things down a bit? Err, why do we have a 900 argument phi? Seems a bit large. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
[Bug tree-optimization/27004] [4.1/4.2 Regression] Insane amount of memory needed at -O1 and above because of salias
--- Comment #2 from rguenther at suse dot de 2006-04-03 14:39 --- Subject: Re: [4.1/4.2 Regression] Insane amount of memory needed at -O1 and above because of salias On Mon, 3 Apr 2006, dberlin at dberlin dot org wrote: On Mon, 2006-04-03 at 13:43 +, bonzini at gnu dot org wrote: spinning a separate bug from PR26830. we are creating a lot of field memory tags, each of which is present in a 900-argument phi, which causes us to use more memory than 4.0. to some extent this is unavoidable, but I wonder if we could throttle things down a bit? Err, why do we have a 900 argument phi? Seems a bit large. Because the testcase is - err - interesting. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27004
[Bug bootstrap/26999] bootstrap failure with --disable-libdecnumber
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 14:59 --- This option should not exist, try --disable-libcpp and you will get even worse. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26999
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-03 15:02 --- The patch is bogus, but the problem in the source looks still valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug c++/27000] [4.2 Regression] Problems with latest visibility changes
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-03 15:04 --- I bet you can reproduce this with using #pragma GCC visibility, without namespaces. Related to PR 26984. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26984 Summary|Problems with latest|[4.2 Regression] Problems |visibility changes |with latest visibility ||changes Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
[Bug target/27001] ICE with -fschedule-insns -fstack-protector-all
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 15:06 --- This is the normal problem of using specific registers for multiplication on x86 and x86_64 so running out of registers is easy :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target GCC target triplet||x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27001
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #9 from aph at gcc dot gnu dot org 2006-04-03 15:22 --- Subject: Bug 26858 Author: aph Date: Mon Apr 3 15:22:21 2006 New Revision: 112641 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112641 Log: 2006-04-03 Andrew Haley [EMAIL PROTECTED] PR java/26858 * expr.c (build_field_ref): Don't check the field offset if flag_syntax_only. Modified: branches/gcc-4_1-branch/gcc/java/ChangeLog branches/gcc-4_1-branch/gcc/java/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug tree-optimization/27003] [4.0 Regression] ivcanon bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 15:22 --- I still say x86 should be using HWI of 64bits anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27003
[Bug c++/26997] g++ reports misleading error message when the identifier with error occurs earlier on the same line
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 15:34 --- types are not expressions though. It is not incorrect but just misleading. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|g++ reports incorrect error |g++ reports misleading |message when the identifier |error message when the |with error occurs earlier on|identifier with error occurs |the same line |earlier on the same line http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26997
[Bug c++/26997] g++ reports misleading error message when the identifier with error occurs earlier on the same line
--- Comment #2 from pavel dot petrovic at gmail dot com 2006-04-03 16:03 --- (In reply to comment #1) types are not expressions though. sure, but I wouldn't mind that, the compiler complains about expression, not about type. isn't typecasting an expression after all? It is not incorrect but just misleading. What you mean by incorrect and what you mean by misleading? The error message produced by the compiler is definitely not correct. say you insert this line before line 17: char *x = (char *)malloc(sizeof(t) * t-a); you get the following: bug.cpp:17: error: expected primary-expression before 'char' bug.cpp:17: error: expected `)' before 'char' bug.cpp:18: error: expected primary-expression before '*' token bug.cpp:18: error: expected primary-expression before ')' token bug.cpp:18: error: expected `;' before 'malloc' why does the compiler reports problem before 'char', if the problem is far at the other end of the same line? but this also shows that it is not a problem of the same identifier at the same line occuring twice - although in that case, we also get the ';' error, which we do not get in case of (char *)...? anyhow, doesn't the behavior indicate some mix up...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26997
[Bug c++/27000] [4.2 Regression] Problems with latest visibility changes
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-03 16:16 ---
In fact this is a latent bug shown by:
/* { dg-do compile } */
/* { dg-require-visibility } */
/* { dg-final { scan-not-hidden _ZN1SIiED1Ev } } */
/* { dg-final { scan-not-hidden _ZN1SIiEC1ERKi } } */
template class T
struct S
{
S (const T );
~S ();
T t;
};
template class T
ST::S (const T x)
{
t = x;
}
template class T
ST::~S ()
{
}
#pragma GCC visibility push(hidden)
//namespace
//{
struct U
{
Sint s;
U () : s (6) { }
} u;
//}
#pragma GCC visibility pop
And really were only exposed by the visibility changes.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||link-failure, wrong-code
Last reconfirmed|-00-00 00:00:00 |2006-04-03 16:16:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #28 from rguenth at gcc dot gnu dot org 2006-04-03 16:20 --- I confirm, that with -fno-tree-salias -O1 4.1.1 is on-par with -O1 4.0.3. So all remaining compile-time/memory problems are due to extra virtual operands. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug middle-end/26968] HDF5 1.7.52 test segfaults with 4.1.0, fine with 4.0.2 (regression)
--- Comment #6 from orion at cora dot nwra dot com 2006-04-03 16:24 --- Hmm, tried adding -save-temps to my flags so that I could collect .s and .i files, but it appears that the segfault also goes away. Removing -save-temps indeed goes back to the previous behavior. Removing -pipe has no effect. Perhaps this isn't a 4.0.2 - 4.1.0 thing as much as a FC4-FC5 things. I'll try using 4.1.0 on FC4 and 4.0.2 on FC5 if possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26968
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #29 from rakdver at gcc dot gnu dot org 2006-04-03 16:31 --- (In reply to comment #27) With a bit simplified testcase (my computer does not have enough memory for this one), we spend 30% of compile time in rewrite_update_phi_arguments. However, only 1.6% (less then 1% of compile time) of the rewrite_update_phi_arguments calls actually changes anything, so the rest is just traversing a dominance tree and visiting the phi nodes; perhaps this could be optimized somehow. I have a patch that gets rewrite_update_phi_arguments below 1% of compile time (cutting the total compile time from 190 to 100s). Still, a lot of time is spent in tree SSA incremental (30%), I will have a look at that. One obvious problem is that update_ssa calls FOR_EACH_BB (and iterates for each stmt in it), thus leading to quadratic behavior if it is used too often; I think it should be possible to avoid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26763] [4.1 Regression] wrong final value of induction variable calculated
--- Comment #7 from patchapp at dberlin dot org 2006-04-03 16:45 --- Subject: Bug number PR26763 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00082.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug c++/27005] New: program hangs when compiled with -O
I am using gcc 3.4.3 on solais 10. g++ -v: Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) If I compile the code, with % g++ reduced.C and run it, it returns as expected. The output is % ./a.out -NaN If I compile it with optimization % g++ reduced.C -O and run it, it does not return! If I remove the unused function from the code, the problem disappears. If I change the functions definition to take vectordouble instead of a vectorint, the problem disappears. -- Summary: program hangs when compiled with -O Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: boris dot breidenbach at physik dot uni-erlangen dot de GCC host triplet: csl-sol210-3_4-branch+sol_rpath http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27005
[Bug c++/27005] program hangs when compiled with -O
--- Comment #1 from boris dot breidenbach at physik dot uni-erlangen dot de 2006-04-03 16:51 --- Created an attachment (id=11192) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11192action=view) buggy code with comments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27005
[Bug c++/27005] program hangs when compiled with -O
--- Comment #2 from boris dot breidenbach at physik dot uni-erlangen dot de 2006-04-03 16:52 --- Created an attachment (id=11193) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11193action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27005
[Bug tree-optimization/26763] [4.1 Regression] wrong final value of induction variable calculated
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-04-03 16:52 --- (In reply to comment #6) I believe c-common.c:pointer_int_sum is wrong in relying on pointer overflow during conversion of the integer offset to an unsigned pointer. I'm sending a patch that fixes this for comments. The patch seems a bit too conservative to me; perhaps just always comparing the offsets as signed could work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug tree-optimization/26763] [4.1 Regression] wrong final value of induction variable calculated
--- Comment #9 from rguenther at suse dot de 2006-04-03 16:59 ---
Subject: Re: [4.1 Regression] wrong final value
of induction variable calculated
On Mon, 3 Apr 2006, rakdver at gcc dot gnu dot org wrote:
(In reply to comment #6)
I believe c-common.c:pointer_int_sum is wrong in relying on pointer overflow
during conversion of the integer offset to an unsigned pointer. I'm sending
a patch that fixes this for comments.
The patch seems a bit too conservative to me; perhaps just always comparing
the
offsets as signed could work?
I'm not a language lawyer here - and as this is the second (or third)
patch to this folding to correct problems I'd rather be safe than sorry
this time. I'm sure jsm can construct a testcase where comparing offsets
as signed leads to wrong code. Maybe
char *memory = 0;
int foo(void)
{
return memory + 0x8000 memory;
}
int main()
{
if (foo())
abort ();
}
i.e. have a mapping 2Gb on a 32bit machine. A corner case, but valid I
guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug c++/27005] program hangs when compiled with -O
--- Comment #3 from boris dot breidenbach at physik dot uni-erlangen dot de 2006-04-03 17:00 --- (In reply to comment #0) Maybe I should say, that I am using an Opteron system. I ran the code on an linux-operton box and it showed the same behaviour. On gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) (intel based system) it worked as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27005
[Bug tree-optimization/26763] [4.1 Regression] wrong final value of induction variable calculated
--- Comment #10 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-03 17:22 ---
Subject: Re: [4.1 Regression] wrong final value of induction variable
calculated
(In reply to comment #6)
I believe c-common.c:pointer_int_sum is wrong in relying on pointer
overflow
during conversion of the integer offset to an unsigned pointer. I'm
sending
a patch that fixes this for comments.
The patch seems a bit too conservative to me; perhaps just always comparing
the
offsets as signed could work?
I'm not a language lawyer here - and as this is the second (or third)
patch to this folding to correct problems I'd rather be safe than sorry
this time. I'm sure jsm can construct a testcase where comparing offsets
as signed leads to wrong code. Maybe
char *memory = 0;
int foo(void)
{
return memory + 0x8000 memory;
}
int main()
{
if (foo())
abort ();
}
i.e. have a mapping 2Gb on a 32bit machine. A corner case, but valid I
guess.
no -- the result in this example is undefined. The comparisons are only
defined for pointers in the same object. I guess nothing really
prevents having an object whose size is more than half of the address
space, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug java/17819] ICE in build_java_check_indexed_type
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-03 17:28 --- I happened to try this out this weekend. I don't see an ICE in build_java_check_indexed_type (with 4.0, 4.1 and head). Now I see: + gcj -c --classpath=jakarta-poi.jar joone-engine.jar -o joone-engine.o org/joone/log/Log4JLogger.java: In class 'org.joone.log.Log4JLogger': org/joone/log/Log4JLogger.java: In method 'org.joone.log.Log4JLogger.debug(java.lang.Object)': org/joone/log/Log4JLogger.java:25: error: cannot find file for class org.apache.log4j.Logger org/joone/log/Log4JLogger.java:25: error: class 'org.apache.log4j.Logger' has no method named 'debug' matching signature '(Ljava/lang/Object;)V' org/joone/log/Log4JLogger.java: In method 'org.joone.log.Log4JLogger.debug(java.lang.Object,java.lang.Throwable)': org/joone/log/Log4JLogger.java:29: error: cannot find file for class org.apache.log4j.Logger org/joone/log/Log4JLogger.java:29: error: class 'org.apache.log4j.Logger' has no method named 'debug' matching signature '(Ljava/lang/Object;Ljava/lang/Throwable;)V' org/joone/log/Log4JLogger.java:29: internal compiler error: in expand_expr_real_1, at expr.c:6552 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17819
[Bug c++/27005] program hangs when compiled with -O
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-03 17:35 --- Fixed in 4.0.0 at least so closing as 3.4.x is not being updated anymore. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27005
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-03 17:42 --- Just a note here, we really always want to deal with a + CST and not worry about if CST is negative or not, I had a patch to do but there was a testsuite regression because of VRP, see PR 25148. In fact currently we don't optimize g++.dg/tree-ssa/pr18178.C when supplying -fwrapv even though we should be able to, and more to the point PR 18178 was created for the -fwrapv case in the first place :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug middle-end/26991] Target Help Seg Fault.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
[Bug tree-optimization/26992] [4.2 Regression] Internal Compiler Error in dwarf2out.c:7607 build_polynomial_chrec
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-03 17:45 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26992
[Bug c++/26989] [4.2 Regression] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 17:50 --- From: http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg00107.html FAIL: g++.dg/ext/visibility/anon1.C scan-hidden private_extern[ \\t_]*_?_ZN.*1fEv So we have a testsuite failure also :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989
[Bug libgcj/23829] FreeBSD 5 support for libjava
--- Comment #4 from rittle at latour dot labs dot mot dot com 2006-04-03 17:57 --- Subject: Re: FreeBSD 5 support for libjava In article [EMAIL PROTECTED], gerald at pfeifer dot com[EMAIL PROTECTED] writes: --- Comment #3 from gerald at pfeifer dot com 2006-04-03 04:58 --- Loren, is this something you could help with reviewing/approving (for 4.2 and 4.1)? The posted patch would likely be OK. The main issue is that it doesn't account for the true point of inflection. Regards, Loren -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
[Bug middle-end/26977] [4.2 regression] ICE in emit_move_insn
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-03 18:16 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26977
[Bug target/27006] New: Invalid altivec constant loading code
When compiling the following code with -O0 -maltivec:
typedef union
{
int i[4];
__attribute__((altivec(vector__))) int v;
} vec_int4;
int main (void)
{
vec_int4 i1;
i1.v = (__attribute__((altivec(vector__))) int){31, 31, 31, 31};
printf (%d\n, i1.i[0]);
return 0;
}
the output printed is 30, not 31.
The load of the vector constant is done by the following pair
of instructions:
vspltisw 0,15
vadduwm 0,0,0
which are generated by this splitter in altivec.md:
(define_split
[(set (match_operand:VI 0 altivec_register_operand )
(match_operand:VI 1 easy_vector_constant_add_self ))]
TARGET_ALTIVEC reload_completed
[(set (match_dup 0) (match_dup 3))
(set (match_dup 0) (plus:VI (match_dup 0)
(match_dup 0)))]
{
rtx dup = gen_easy_altivec_constant (operands[1]);
rtx const_vec;
/* Divide the operand of the resulting VEC_DUPLICATE, and use
simplify_rtx to make a CONST_VECTOR. */
XEXP (dup, 0) = simplify_const_binary_operation (ASHIFTRT, QImode,
XEXP (dup, 0), const1_rtx);
const_vec = simplify_rtx (dup);
if (GET_MODE (const_vec) == MODEmode)
operands[3] = const_vec;
else
operands[3] = gen_lowpart (MODEmode, const_vec);
})
Now, easy_vector_constand_add_self accepts all constants between
16 and 31, where I think it should really only be accepting *even*
constants.
The test is really implemented in rs6000.h:
#define EASY_VECTOR_15_ADD_SELF(n) (!EASY_VECTOR_15((n))\
EASY_VECTOR_15((n) 1))
and adding a condition ((n) 1) == 0 here fixes the problem.
Is this the proper solution?
--
Summary: Invalid altivec constant loading code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: powerpc-*-linux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug c/27007] New: Missed optimization of comparison with 'limited range'
This function always returns 1, but gcc misses the optimization:
int foo(unsigned char x)
{
return (x+1) != 0;
}
fold-const.c converts the comparison to x != -1, but that's it.
shorten_compare() in c-common.c would optimize it, but it doesn't get called.
fold-const.c has similar code on lines approx. 9307..9454 but is less general
(and uglier) than shorten_compare() and misses this case. tree-vrp.c says x is
varying and doesn't help out either.
An example of this construct is line 527 of libmudflap/mf-runtime.c
if (*optstr+1)
That looks like a buglet, by the way.
--
Summary: Missed optimization of comparison with 'limited range'
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug c/27008] New: Simple nested for loop generates bad code on mac in O2, O3
gcc version 3.3, Apple build 1495, ppc-darwin.
command-line: gcc -O3 file.c
output: 1 2 0 0 5 6 0 0 9 10 0 0 13 14 0 0 17 18
command-line: gcc -O0 file.c
output: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Compile and run the following file with optimization O2. The output is a list
of integers from 1--18. When compiled with = O2, the list contains holes
(the integers 3,4,7,8,11,12,15,16 display as 0).
#include stdlib.h
#include stdio.h
static void f(int in1, int *out11);
static void init(int in1, int *out1, int *out2, int *out11, int *out21);
static void dump(int *out11);
int
main()
{
int out11[18] = { 0 };
int in1 = 0;
f(in1,out11);
return 0;
}
static void f(int in1, int *out11)
{
int b_out21 = 0;
int b_out11[18] = { 0 };
int b_out5 = 0;
int b_out2 = 0;
int b_out1 = 0;
init(in1, b_out1, b_out2, (int *)b_out11, b_out21);
for(b_out2 = 0; b_out2 9; b_out2++) {
for(b_out5 = 0; b_out5 2; b_out5++) {
out11[b_out5 + (b_out2 1)] = b_out11[b_out5 + (b_out2 1)];
}
}
dump(out11);
}
static void init(int in1, int *out1, int *out2, int *out11, int *out21)
{
int i;
for(i = 0; i 18; ++i) {
out11[i] = i+1;
}
}
static void dump(int *out11)
{
int i;
for(i = 0; i 18; ++i) {
printf(%d , out11[i]);
}
printf(\n);
}
--
Summary: Simple nested for loop generates bad code on mac in O2,
O3
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot elliott at mathworks dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27008
[Bug c/27007] Missed optimization of comparison with 'limited range'
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 18:59 --- x+1 can wrap so try x be UINT_MAX. In fact x != -1 is valid for unsigned as -1 is casted to unsigned and you get UINT_MAX :). -- 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=27007
[Bug c/27008] Simple nested for loop generates bad code on mac in O2, O3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 19:02 --- Report this bug to Apple since this is Apple's GCC that has been heavly modified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27008
[Bug target/27006] [4.1/4.2 Regression] Invalid altivec constant loading code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 19:10 --- This worked in 4.0.2, by just loading the constant via memory so this is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aldyh at gcc dot gnu dot org Known to work||4.0.2 Summary|Invalid altivec constant|[4.1/4.2 Regression] Invalid |loading code|altivec constant loading ||code Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug target/27006] [4.1/4.2 Regression] Invalid altivec constant loading code
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-03 19:17 --- Confirmed, this is definitely wrong but we can do better than disabling this for odd vectors I think. Adding 1 to them should work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-03 19:17:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug c/27007] Missed optimization of comparison with 'limited range'
--- Comment #2 from joseph at codesourcery dot com 2006-04-03 19:22 --- Subject: Re: Missed optimization of comparison with 'limited range' On Mon, 3 Apr 2006, pinskia at gcc dot gnu dot org wrote: x+1 can wrap so try x be UINT_MAX. Wrong. The test uses *unsigned char*. In the normal case of int wider than unsigned char, this promotes to int, so x+1 has range [1, UCHAR_MAX+1]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug c/27007] Missed optimization of comparison with 'limited range'
--- Comment #3 from trt at acm dot org 2006-04-03 19:22 --- Since x is unsigned char, default promotions apply and x+1 will be a signed integer in the range 1..256 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug c/27007] Missed optimization of comparison with 'limited range'
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-04-03 19:44 --- Subject: Re: Missed optimization of comparison with 'limited range' On Mon, 2006-04-03 at 19:22 +, trt at acm dot org wrote: --- Comment #3 from trt at acm dot org 2006-04-03 19:22 --- Since x is unsigned char, default promotions apply and x+1 will be a signed integer in the range 1..256 In that case, VRP should be able to extract the useful ~0 range from this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug tree-optimization/26994] Scalar TRANSFER - error: invalid operand to unary operator
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-03 19:44 ---
The patch fixes the problem by bolting the context to the floor and putting
concrete on it. The first gfc_evaluate_now prevents the error and the second
gets us a consistent result.
Should I detect that the first argument is in the parent context and only fix
the values on that being the case?
Paul
PS Hmmm. I now cannot obtain the fault with an unpatched version, in spite of
provoking it today, repeatedly, on both FC3 and Cygwin Curiouser and
curiouser.
Index: gcc/fortran/trans-intrinsic.c
===
*** gcc/fortran/trans-intrinsic.c (revision 112634)
--- gcc/fortran/trans-intrinsic.c (working copy)
*** gfc_conv_intrinsic_transfer (gfc_se * se
*** 2700,2705
--- 2700,2706
gfc_se argse;
tree type;
tree ptr;
+ tree tmp;
gfc_ss *ss;
/* Get a pointer to the source. */
*** gfc_conv_intrinsic_transfer (gfc_se * se
*** 2707,2722
ss = gfc_walk_expr (arg-expr);
gfc_init_se (argse, NULL);
if (ss == gfc_ss_terminator)
! gfc_conv_expr_reference (argse, arg-expr);
else
! gfc_conv_array_parameter (argse, arg-expr, ss, 1);
gfc_add_block_to_block (se-pre, argse.pre);
gfc_add_block_to_block (se-post, argse.post);
- ptr = argse.expr;
arg = arg-next;
type = gfc_typenode_for_spec (expr-ts);
ptr = convert (build_pointer_type (type), ptr);
if (expr-ts.type == BT_CHARACTER)
{
gfc_init_se (argse, NULL);
--- 2708,2732
ss = gfc_walk_expr (arg-expr);
gfc_init_se (argse, NULL);
if (ss == gfc_ss_terminator)
! {
! gfc_conv_expr_reference (argse, arg-expr);
! tmp = build_fold_indirect_ref (argse.expr);
! tmp = gfc_evaluate_now (tmp, argse.pre);
! ptr = build_fold_addr_expr (tmp);
! }
else
! {
! gfc_conv_array_parameter (argse, arg-expr, ss, 1);
! ptr = argse.expr;
! }
!
gfc_add_block_to_block (se-pre, argse.pre);
gfc_add_block_to_block (se-post, argse.post);
arg = arg-next;
type = gfc_typenode_for_spec (expr-ts);
ptr = convert (build_pointer_type (type), ptr);
+
if (expr-ts.type == BT_CHARACTER)
{
gfc_init_se (argse, NULL);
*** gfc_conv_intrinsic_transfer (gfc_se * se
*** 2730,2735
--- 2740,2747
{
se-expr = build_fold_indirect_ref (ptr);
}
+
+ se-expr = gfc_evaluate_now (se-expr, se-pre);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26994
[Bug c/27007] Missed optimization of comparison with 'limited range'
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-04-03 19:51 --- Bug should not have been closed, reopening. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug libgcj/23829] FreeBSD 5 support for libjava
--- Comment #5 from tromey at gcc dot gnu dot org 2006-04-03 19:54 --- This patch is ok by me if someone wants to check it in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
[Bug bootstrap/26959] GCC 4.1.0 Won't build on Mingw. Complainst about no % in format
--- Comment #2 from dcorbit at connx dot com 2006-04-03 20:00 --- Subject: RE: GCC 4.1.0 Won't build on Mingw. Complainst about no % in format The attached makefile is from the gcc-4.1.0 directory. -Original Message- From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: Sunday, April 02, 2006 12:20 AM To: Dann Corbit Subject: [Bug bootstrap/26959] GCC 4.1.0 Won't build on Mingw. Complainst about no % in format --- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 08:20 - -- This makes little sense: Makefile:1277: *** target pattern contains no `%'. Stop. Can you attach the makefile? Attached. Also what options did you use to configure GCC? ./configure -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -- -- Status|UNCONFIRMED |WAITING Component|c++ |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26959 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. --- Comment #3 from dcorbit at connx dot com 2006-04-03 20:00 --- Created an attachment (id=11194) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11194action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26959
[Bug fortran/27009] New: gfc_todo: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
This is with SUSE 10.1b9's gcc-fortran-4.1.0-10 ~ gfortran -c fleur.F fleur.F: In function MAIN__: fleur.F:1: fatal error: gfc_todo: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1 compilation terminated. Stripped-down test case: - PROGRAM test IMPLICIT NONE INTEGER ir_fac REAL zksum ir_fac = size(transfer(zksum,(/1/))) END PROGRAM test - (Compiles flawlessly with the intel fortran compiler 9.0 [both test case as also full program].) -- Summary: gfc_todo: Not Implemented: Scalarization of non- elemental intrinsic: __transfer1 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27009
[Bug bootstrap/27010] New: building profiledboor
-- Summary: building profiledboor Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amonakov at gmail dot com 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=27010
[Bug bootstrap/27011] New: building profiledboort
-- Summary: building profiledboort Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amonakov at gmail dot com 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=27011
[Bug tree-optimization/26994] Scalar TRANSFER - error: invalid operand to unary operator
--- Comment #7 from pault at gcc dot gnu dot org 2006-04-03 21:00 --- PS Hmmm. I now cannot obtain the fault with an unpatched version, in spite of provoking it today, repeatedly, on both FC3 and Cygwin Curiouser and curiouser. Cancel that thought - it is still there; it just doesn't always get triggered. I believe that this is specific to 4.2. Neither 4.1 nor 4.0 seem to suffer from it. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26994
[Bug fortran/27009] gfc_todo: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 21:01 --- This was just fixed last week :). *** This bug has been marked as a duplicate of 17298 *** -- 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=27009
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-04-03 21:01 --- *** Bug 27009 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tobias dot burnus at physik ||dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug bootstrap/27010] building profiledboor
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 21:02 --- *** This bug has been marked as a duplicate of 27011 *** -- 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=27010
[Bug bootstrap/27011] building profiledboort
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-03 21:02 --- *** Bug 27010 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27011
[Bug bootstrap/27011] building profiledboort
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-03 21:05 --- So what is wrong? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27011
[Bug bootstrap/26959] GCC 4.1.0 Won't build on Mingw. Complainst about no % in format
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-03 21:08 --- I had meant the Makefile inside the gcc subdirectory :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26959
[Bug middle-end/26968] HDF5 1.7.52 test segfaults with 4.1.0, fine with 4.0.2 (regression)
--- Comment #7 from orion at cora dot nwra dot com 2006-04-03 21:13 --- Looks like adding -save-temps to the flags breaks the configure check for -fPIC, so the code be built with -save-temps that worked also did not have -fPIC (perhaps that is a clue). Trick was to remove -pipe when using -save-temps to avoid a gcc warning that was confusing configure, now I can get .i and .s from the failed 4.1.0 compile. Just is case there is something obvious, here are asm snippets of the loop in question from 4.0.2: .loc 1 2264 0 movl-2068(%ebp), %ecx #, testl %ecx, %ecx # je .L201 #, movl12(%ebp), %esi # fm, ivtmp.708 xorl%edi, %edi # u.1013 .LVL48: movl3052(%esi), %edx# variable.layout, movl%edx, -2088(%ebp) #, .L200: .loc 1 2266 0 movl-2088(%ebp), %edx #, movl20(%edx,%edi,4), %edx # variable.u.chunk.dim, movl%edx, 2524(%esi)#, variable.chunk_dim movl$0, 2528(%esi) #, variable.chunk_dim .loc 1 2269 0 movl-2028(%ebp), %ecx # dataset, movl52(%ecx), %eax # variable.shared, variable.shared movl84(%eax,%edi,4), %edx # variable.layout.u.chunk.dim, xorl%ecx, %ecx # movl%edx, -2024(%ebp) #, D.12413 movl%ecx, -2020(%ebp) #, D.12413 addl28(%esi), %edx # variable.f_dims, adcl32(%esi), %ecx # variable.f_dims, movl%edx, -2112(%ebp) #, movl%ecx, -2108(%ebp) #, addl$-1, -2112(%ebp)#, adcl$-1, -2108(%ebp)#, movl-2024(%ebp), %eax # D.12413, movl-2020(%ebp), %edx # D.12413, movl%eax, 8(%esp) #, movl%edx, 12(%esp) #, movl-2112(%ebp), %edx #, movl-2108(%ebp), %ecx #, movl%edx, (%esp)#, movl%ecx, 4(%esp) #, call[EMAIL PROTECTED] # movl%eax, 2260(%esi)# tmp302, variable.chunks movl%edx, 2264(%esi)#, variable.chunks .loc 1 2264 0 addl$1, %edi#, u.1013 addl$8, %esi#, ivtmp.708 cmpl%edi, -1996(%ebp) # u.1013, f_ndims jne .L200 #, .L201: .loc 1 2273 0 4.1.0: .loc 1 2264 0 movl-1952(%ebp), %edx # f_ndims, testl %edx, %edx # je .L241 #, .loc 1 2260 0 movl$0, -1948(%ebp) #, u .LVL83: movl12(%ebp), %eax # fm, movl3052(%eax), %eax# variable.layout, movl%eax, -2008(%ebp) #, .L246: .loc 1 2266 0 movl-1948(%ebp), %edx # u, movl12(%ebp), %ecx # fm, movl20(%ecx,%edx,4), %esi # variable.u.chunk.dim, movl%esi, 2524(%ecx,%edx,8) #, variable.chunk_dim movl$0, 2528(%ecx,%edx,8) #, variable.chunk_dim .loc 1 2269 0 movl-1980(%ebp), %edi # dataset, movl52(%edi), %eax # variable.shared, variable.shared movl-1948(%ebp), %ecx # u, movl84(%eax,%ecx,4), %edx # variable.layout.u.chunk.dim, xorl%ecx, %ecx # movl%edx, -2064(%ebp) #, D.12819 movl%ecx, -2060(%ebp) #, D.12819 movl%edx, %eax #, tmp302 movl%ecx, %edx #, movl-1948(%ebp), %esi # u, movl12(%ebp), %edi # fm, addl28(%edi,%esi,8), %eax # variable.f_dims, tmp302 adcl32(%edi,%esi,8), %edx # variable.f_dims, addl$-1, %eax #, tmp302 adcl$-1, %edx #, movl-2064(%ebp), %esi # D.12819, movl-2060(%ebp), %edi # D.12819, movl%esi, 8(%esp) #, movl%edi, 12(%esp) #, movl%eax, (%esp)# tmp302, movl%edx, 4(%esp) #, call[EMAIL PROTECTED] # movl-1948(%ebp), %edi # u, movl12(%ebp), %ecx # fm, movl%eax, 2260(%ecx,%edi,8) # tmp306, variable.chunks movl%edx, 2264(%ecx,%edi,8) #, variable.chunks .loc 1 2264 0 addl$1, %edi#, movl%edi, -1948(%ebp) #, u cmpl%edi, -1952(%ebp) #, f_ndims jne .L246 #, .LVL84: .L241: .loc 1 2273 0 I'll work on getting a self-contained testcase, but I'm afraid it will take a lot of work. It's a big library -- orion at cora dot nwra dot com changed: What|Removed |Added CC||orion at cora dot nwra dot ||com
[Bug tree-optimization/26994] [4.2 Regression] Scalar TRANSFER - error: invalid operand to unary operator
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-03 21:13 --- From looking at the debugger a little bit, the inlininer is not remapping the CONST_DECL correctly. I might look at this more if I get some time. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|Scalar TRANSFER - error:|[4.2 Regression] Scalar |invalid operand to unary|TRANSFER - error: invalid |operator|operand to unary operator Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26994
[Bug bootstrap/27011] building profiledboort
--- Comment #3 from amonakov at gmail dot com 2006-04-03 21:25 ---
(In reply to comment #2)
So what is wrong?
Oh, sorry for the mess. Shame on me.
Building profiledbootstrap with checking enabled produces ICEing compiler (make
profiledbootstrap stops trying to compile crtsuff.c)
Compiler version is 4.2.0 20060330
Configured with:
../gcc/configure --prefix=/home/alex/gcc/inst-checking/ --enable-checking
--enable-languages=c,c++
After stagefeedback compiler has been built, make runs
/home/alex/gcc/build/./gcc/xgcc -B/home/alex/gcc/build/./gcc/
-B/home/alex/gcc/inst-checking//i686-pc-linux-gnu/bin/
-B/home/alex/gcc/inst-checking//i686-pc-linux-gnu/lib/ -isystem
/home/alex/gcc/inst-checking//i686-pc-linux-gnu/include -isystem
/home/alex/gcc/inst-checking//i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2
-DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss
-fno-toplevel-reorder -fno-omit-frame-pointer \
-c ../../gcc/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
which results in
built-in:0: internal compiler error: in calculate_allocation, at vec.c:58
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Running
gdb -args /home/alex/gcc/build/./gcc/cc1 -quiet -v -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libdecnumber -I../libdecnumber -iprefix
/home/alex/gcc/build/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.0/ -isystem
/home/alex/gcc/build/./gcc/include -DIN_GCC -DCRT_BEGIN -isystem
/home/alex/gcc/inst-checking//i686-pc-linux-gnu/include -isystem
/home/alex/gcc/inst-checking//i686-pc-linux-gnu/sys-include -isystem ./include
../../gcc/gcc/crtstuff.c -quiet -dumpbase crtstuff.c -mtune=generic
-auxbase-strip crtbegin.o -g -g0 -O2 -O2 -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -o
/tmp/ccGc5pyT.s
shows that assertion in gcc/vec.c:58 (in vec_heap_o_reserve) fails:
Breakpoint 1, fancy_abort (file=0x85e2e16 ../../gcc/gcc/vec.c, line=58,
function=0x85e2e2a calculate_allocation)
at ../../gcc/gcc/diagnostic.c:641
641 {
(gdb) bt
#0 fancy_abort (file=0x85e2e16 ../../gcc/gcc/vec.c, line=58,
function=0x85e2e2a calculate_allocation)
at ../../gcc/gcc/diagnostic.c:641
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
#1 0x0840aa94 in vec_heap_o_reserve (vec=value optimized out, reserve=1,
vec_offset=8, elt_size=4)
at ../../gcc/gcc/vec.c:58
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
#2 0x0804c044 in c_register_pragma_1 (space=0x0, name=0x8555d15 pack,
handler=0x804c9fb handle_pragma_pack,
allow_expansion=0 '\0') at ../../gcc/gcc/c-pragma.c:729
#3 0x0804c153 in init_pragma () at ../../gcc/gcc/c-pragma.c:815
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
#4 0x0809f4cb in c_common_init () at ../../gcc/gcc/c-opts.c:1134
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
#5 0x080a913d in c_objc_common_init () at ../../gcc/gcc/c-objc-common.c:130
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
#6 0x083df613 in toplev_main (argc=50, argv=0xbfeb1994) at
../../gcc/gcc/toplev.c:1864
#7 0x080bfc4f in main (argc=1398167381, argv=0x8d2cec83) at
../../gcc/gcc/main.c:35
(gdb) up
#1 0x0840aa94 in vec_heap_o_reserve (vec=value optimized out, reserve=1,
vec_offset=8, elt_size=4)
at ../../gcc/gcc/vec.c:58
58gcc_assert (alloc - num (unsigned)(reserve 0 ? -reserve :
reserve));
(gdb) l
53 /* If there's no prefix, and we've not requested anything, then we
54 will create a NULL vector. */
55 return 0;
56
57/* We must have run out of room. */
58gcc_assert (alloc - num (unsigned)(reserve 0 ? -reserve :
reserve));
59
60if (reserve 0)
61 /* Exact size. */
62 alloc = num + -reserve;
When configuring with checking disabled, make profiledbootstrap finishes
successfully.
--
amonakov at gmail dot com changed:
What|Removed |Added
[Bug gcov/profile/26399] -fprofile-use fails with unnamed namespaces
--- Comment #4 from hjl at lucon dot org 2006-04-03 21:54 --- If -frandom-seed=0 is required for -fprofile-use to work correctly, why not add it automatically for -fprofile-use? -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26399
[Bug c/27012] New: visibility attribute should not be permitted on local variables
This program:
void foo(void)
{
int x __attribute__((visibility(hidden)));
}
makes no sense and should produce a compilation error.
--
Summary: visibility attribute should not be permitted on local
variables
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27012
[Bug c/27013] New: visibility attribute should not be permitted on local variables
This program:
void foo(void)
{
int x __attribute__((visibility(hidden)));
}
makes no sense and should produce a compilation error.
--
Summary: visibility attribute should not be permitted on local
variables
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: geoffk at gcc dot gnu dot org
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27013
[Bug bootstrap/27011] building profiledboort
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-03 22:05 --- This is all recorded under PR 22313. *** This bug has been marked as a duplicate of 22313 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27011
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
--- Comment #33 from pinskia at gcc dot gnu dot org 2006-04-03 22:05 --- *** Bug 27011 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||amonakov at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
