[Bug libfortran/29866] building libgfortran fails because of kinds.h
--- Comment #2 from Jean-pierre dot vial at wanadoo dot fr 2006-11-19 08:55 --- (In reply to comment #1) > This is a bug in your instation of GMP/MPFR. It is causing gfortran to crash. > No, I found the explanation, it has nothing to do with gmp: it is a parallelism problem in the makefile. I have a multiprocessor workstation (2 dual-core opterons = 4 processors) and if I run the makefile with the option make -j4 a I usually do, the sub-make for libgfortran is started when the required new gfortran does not yet exist, so the make-kinds-h.sh shell-script fails without meaningful error message. running make in single-thread mode (without the -j4 option) solves this problem. I then fall back on bug 29867 which is completely different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29866
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #18 from kreckel at ginac dot de 2006-11-19 11:22 --- An idea: Would it help if feholdexcept, fetestexcept and all those standard functions accessing the status and control flags were implemented as builtins, not as extern libcalls? This probably wouldn't help against elimination of unused statements that nevertheless trigger side effects. But it would inhibit the worst cases of code reordering, I suppose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug fortran/29892] New: substring out of bounds: Missing variable name for variables with parameter attribute
see also: http://gcc.gnu.org/ml/fortran/2006-11/msg00511.html
With -fbounds-check, an error message is shown if the character substrings
exceed the size of the variable. This error message contains also the name of
the variable, but this piece of information is not always passed to
gfc_conv_substring.
There are two places where gfc_conv_substring is called:
a) In gfc_conv_variable
b) In gfc_conv_substring_expr, here the name is always unknown.
I checked it against the regression test suite. The result:
First case, gfc_conv_variable: None found.
Secondly, gfc_conv_substring_expr (tested by adding the following to
gfc_conv_substring_expr:
printf("ERROR: gfc_conv_substring_expr: NO NAME"
"(in file '%s', at line %d)\n", expr->where.lb->file->filename,
expr->where.lb->linenum); ):
Several matches of this kind:
- gfortran.dg/char_cshift_1.f90
a(i1, i2, i3) = 'ab'(i1:i1) // 'cde'(i2:i2) // 'fghi'(i3:i3)
=> Unsolvable as no name exists
Solvable case: gfortran.dg/pr29067.f:
character(len=16),parameter :: s = "", s2 = "1234567890123456"
print *, s(9:16)
print *, s2(9:16)
The problem is that s and s2 have the parameter type
--
Summary: substring out of bounds: Missing variable name for
variables with parameter attribute
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29892
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-11-19 12:14
---
The problem is that the division is in no ways special to optimizers. One
possibility I see would be to introduce either a builtin function or a new
tree-code to access the exception flags. Of course the fact that flags are
supposed to accumulate doesn't help to simplify things here...
It would be the frontends task to emit compound expressions. Like instead
of
D.2529 = x / y;
emit
{ D.2529 = x / y; __builtin_update_except (D.2529); }
(note that __builtin_update_except has to be subject to read/write global
memory to support exception flow across the call-graph).
I bet it's a mess to optimize this stuff correctly without some "clever"
hacks. Like
{ D.2529 = x / y; *__builtin_flags = __builtin_update_except (D.2529,
*__builtin_flags); }
where we can then make __builtin_update_except const [ideally *__builtin_flags
would just be a special alias tag used and clobbered by the various
exception functions]
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c++/29893] New: ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
Depending on the compilation flags the same ice will trigger at different
times, but I know which code line causes this, however I have not been
successful at reducing the bug. Possibly with smaller source, the bug won't
show up.
The bug seems to be triggered in class filename_pool which is at line 57241 in
the preprocessed source. In a reduced testcase the compilation simply fails
with an undefined reference to intrusive_ptr_release(filename_pool::holder*).
The line 'friend void intrusive_ptr_release(holder*);' after the nested struct
holder{}; must be moved above the declaration of holder together with a forward
declaration of holder to be able to compile again.
compilation flags: -save-temps -g -Wall
-v:
Configured with: ../gcc-4.1.1/configure --host=mingw32 --prefix=/mingw
--with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nls
--enable-languages=c,c++ --disable-win32-registry --disable-shared
--enable-sjlj-exceptions --enable-libstdcxx-debug
Thread model: win32
gcc version 4.1.1
--
Summary: ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baraclese at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29893
[Bug fortran/29892] substring out of bounds: Missing variable name for variables with parameter attribute
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-19 12:51 --- I need to do the same for array bounds checking, to identify the cases where no name is provided and see what we can do about it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-19 12:51:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29892
[Bug fortran/29892] substring out of bounds: Missing variable name for variables with parameter attribute
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-19 12:51:09 |2006-11-19 12:52:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29892
[Bug c++/29894] New: ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
Depending on the compilation flags the same ice will trigger at different
times, but I know which code line causes this, however I have not been
successful at reducing the bug. Possibly with smaller source, the bug won't
show up.
The bug seems to be triggered in class filename_pool which is at line 57241 in
the preprocessed source. In a reduced testcase the compilation simply fails
with an undefined reference to intrusive_ptr_release(filename_pool::holder*).
The line 'friend void intrusive_ptr_release(holder*);' after the nested struct
holder{}; must be moved above the declaration of holder together with a forward
declaration of holder to be able to compile again.
compilation flags: -save-temps -g -Wall
-v:
Configured with: ../gcc-4.1.1/configure --host=mingw32 --prefix=/mingw
--with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nls
--enable-languages=c,c++ --disable-win32-registry --disable-shared
--enable-sjlj-exceptions --enable-libstdcxx-debug
Thread model: win32
gcc version 4.1.1
--
Summary: ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baraclese at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29894
[Bug c/29895] New: ice for legal code
I just tried to compile Linux kernel version 2.6.18.2 with gcc-4.3-20061118 snapshot on a x86_64 box. The compiler said /home/dcb/gnu/43-20061118/results/bin/gcc -g -O3 -Wall -march=opteron -Wp,-MD,arch/x86_64/lib/.csum-partial.o.d -nostdinc -isystem /home/dcb/gnu/43-20061118/results/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -m64 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fno-omit-frame-pointer -fno-optimize-sibling-calls -fasynchronous-unwind-tables -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -funroll-loops -ffunction-sections -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(csum_partial)" -D"KBUILD_MODNAME=KBUILD_STR(csum_partial)" -c -o arch/x86_64/lib/.tmp_csum-partial.o arch/x86_64/lib/csum-partial.c arch/x86_64/lib/csum-partial.c: In function 'csum_partial': arch/x86_64/lib/csum-partial.c:138: error: verify_flow_info: Block 29 has loop_father, but there are no loops arch/x86_64/lib/csum-partial.c:138: error: verify_flow_info: Block 28 has loop_father, but there are no loops Preprocessed source code attached. Flags -Os -funroll-loops required. If it is any help, this code worked fine in gcc snapshot 4.3-2005 -- Summary: ice for legal code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64_linux_suse http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29895
[Bug c/29895] ice for legal code
--- Comment #1 from dcb314 at hotmail dot com 2006-11-19 13:37 --- Created an attachment (id=12644) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12644&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29895
[Bug c/29895] ice for legal code
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2006-11-19 13:41 --- *** This bug has been marked as a duplicate of 29879 *** -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29895
[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops
--- Comment #10 from belyshev at depni dot sinp dot msu dot ru 2006-11-19 13:41 --- *** Bug 29895 has been marked as a duplicate of this bug. *** -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879
[Bug c++/29896] New: ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
Depending on the compilation flags the same ice will trigger at different
times, but I know which code line causes this, however I have not been
successful at reducing the bug. Possibly with smaller source, the bug won't
show up.
The bug seems to be triggered in class filename_pool which is at line 57241 in
the preprocessed source. In a reduced testcase the compilation simply fails
with an undefined reference to intrusive_ptr_release(filename_pool::holder*).
The line 'friend void intrusive_ptr_release(holder*);' after the nested struct
holder{}; must be moved above the declaration of holder together with a forward
declaration of holder to be able to compile again.
compilation flags: -save-temps -g -Wall
-v:
Configured with: ../gcc-4.1.1/configure --host=mingw32 --prefix=/mingw
--with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nls
--enable-languages=c,c++ --disable-win32-registry --disable-shared
--enable-sjlj-exceptions --enable-libstdcxx-debug
Thread model: win32
gcc version 4.1.1
--
Summary: ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baraclese at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
[Bug c++/29896] ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
--- Comment #1 from baraclese at googlemail dot com 2006-11-19 13:54 --- since source is too large (~1.7MB) to attach i uploaded it for your convenience, please download it from here: http://oscc.sourceforge.net/compiler.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
[Bug c++/29893] ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
--- Comment #1 from baraclese at googlemail dot com 2006-11-19 14:02 --- *** This bug has been marked as a duplicate of 29896 *** -- baraclese at googlemail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29893
[Bug c++/29896] ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
--- Comment #2 from baraclese at googlemail dot com 2006-11-19 14:02 --- *** Bug 29893 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
[Bug c++/29894] ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
--- Comment #1 from baraclese at googlemail dot com 2006-11-19 14:02 --- *** This bug has been marked as a duplicate of 29896 *** -- baraclese at googlemail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29894
[Bug c++/29896] ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
--- Comment #3 from baraclese at googlemail dot com 2006-11-19 14:02 --- *** Bug 29894 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
[Bug c/29897] New: %s substituted withparts of sentence can not be translated correctly
In gcc/config/sh/symbian.c there is this code: warning (0, "%s %q+D %s after being referenced with dllimport linkage", TREE_CODE (decl) == VAR_DECL ? "variable" : "function", decl, (DECL_INITIAL (decl) || !DECL_EXTERNAL (decl)) ? "defined locally" : "redeclared without dllimport attribute"); The strings substituted for the two %s:es are not available for translation, so this can not be properly translated. And composed sentences like this is not in general possible to translate. I realise it has to be split up in four different messages, but that seems to be the only way to get proper translations. -- Summary: %s substituted withparts of sentence can not be translated correctly Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29897
[Bug libstdc++/29898] New: hash_map<> lacks support for long long
The following program fails to compile with every version of GCC 4.x I
tested (including current mainline) with
error: no match for call to '(const __gnu_cxx::hash) (const
long
long int&)'
snip
#include
using namespace __gnu_cxx;
typedef long long T;
void f() {
hash_set t;
t.insert(1);
t.erase(1);
}
snip
The problem is that libstdc++ fails to define hash.
--
Summary: hash_map<> lacks support for long long
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29898
[Bug libfortran/29649] Force core dump on runtime library errors
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-11-19 14:58 --- Working on this -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-31 16:01:05 |2006-11-19 14:58:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649
[Bug translation/29897] %s substituted withparts of sentence can not be translated correctly
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-19 14:59 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |translation Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-19 14:59:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29897
[Bug libstdc++/29898] hash_map<> lacks support for long long
--- Comment #1 from pcarlini at suse dot de 2006-11-19 15:06 --- Hi Gerald. The libstdc++ project already decided to not work anymore on the legacy ext/ containers (beyond serious bugs affecting existing facilities, maybe), because these days there is no reason to not move to the unordered containers in tr1 (now also in the draft of the next C++ standard). Thus we already closed similar DRs, in the past. In any case, the user can easily workaround this nuisance by providing in namespace __gnu_cxx the missing, trivial, specialization of struct hash. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29898
[Bug libstdc++/29898] hash_map<> lacks support for long long
--- Comment #2 from pcarlini at suse dot de 2006-11-19 15:12 --- PS: per the letter of TR1, the new hashing facilities in TR1 also miss specializations of struct hash for long long and unsigned long long, I'm going to add those, as a reasonable extension (anyway, long long is already accepted for C++0x). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29898
[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops
--- Comment #11 from bonzini at gnu dot org 2006-11-19 15:52 --- thanks, this patch seems ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879
[Bug tree-optimization/28888] [4.1 regression] ICE in tree check: expected cond_expr, have label_expr in simplify_using_initial_conditions, at tree-ssa-loop-niter.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-19 16:09 --- Subject: Bug 2 Author: rguenth Date: Sun Nov 19 16:09:19 2006 New Revision: 118988 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118988 Log: 2006-11-19 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2006-09-22 Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/2 * tree-if-conv.c (combine_blocks): Rewritten. * tree-cfg.c (tree_verify_flow_info): Check that edges with EDGE_TRUE/FALSE_VALUE follow COND_EXPR. * gcc.dg/pr2.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr2.c - copied unchanged from r117135, trunk/gcc/testsuite/gcc.dg/pr2.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-cfg.c branches/gcc-4_1-branch/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug c++/29896] ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
--- Comment #4 from steven at gcc dot gnu dot org 2006-11-19 16:10 --- The best way to reduce this test case is to use --param ggc-min-expand=0 -- param gcc-min-heapsize=0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
[Bug tree-optimization/28888] [4.1 regression] ICE in tree check: expected cond_expr, have label_expr in simplify_using_initial_conditions, at tree-ssa-loop-niter.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-19 16:11 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug tree-optimization/29753] [4.0/4.1/4.2/4.3 Regression] Volatile semantics ignored in some cases
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-19 16:15 --- Subject: Bug 29753 Author: rguenth Date: Sun Nov 19 16:14:49 2006 New Revision: 118989 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118989 Log: 2006-11-19 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2006-11-15 Paolo Bonzini <[EMAIL PROTECTED]> PR middle-end/29753 * gimplify.c (fold_indirect_ref_rhs): Use STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29753
[Bug tree-optimization/29753] [4.0/4.1/4.2/4.3 Regression] Volatile semantics ignored in some cases
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-11-19 16:16 --- Subject: Bug 29753 Author: rguenth Date: Sun Nov 19 16:15:47 2006 New Revision: 118990 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118990 Log: 2006-11-19 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2006-11-15 Paolo Bonzini <[EMAIL PROTECTED]> PR middle-end/29753 * gimplify.c (fold_indirect_ref_rhs): Use STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29753
[Bug tree-optimization/29753] [4.0 Regression] Volatile semantics ignored in some cases
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-11-19 16:16 --- Fixed on 4.1 and 4.2 branches. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.4 4.1.2 4.2.0 4.3.0 |4.0.4 Known to work|3.3.5 |3.3.5 4.1.2 4.2.0 4.3.0 Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0 Regression] Volatile |Volatile semantics ignored |semantics ignored in some |in some cases |cases http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29753
[Bug target/29319] ICE unrecognizable insn: offset too large for larl (breaks glibc)
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-19 16:18 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-11-19 16:18:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
[Bug fortran/29899] New: [Segfault] Fortran entry point caught from C function
Hello,
I work for a long time on a programming language and it is written in C, F77
and F90. I can build this code with all release of gcc/gfortran before the
4.1.x.
I have tried to found a bug in my code without any success, thus, I write this
bug report.
Test program:
schroedinger:[~/test] > gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)
schroedinger:[~/test] > gfortran -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)
schroedinger:[~/test] > cat a.c
#include
//#define integer4 int
typedef long int integer4;
void rluxgo_(integer4 *luxuriance, integer4 *racine, integer4 *k1,
integer4 *k2);
int main (void)
{
integer4 k1, k2, luxuriance, racine;
k1 = 0;
k2 = 0;
printf("%d\n", sizeof(k1));
luxuriance = 4;
racine = (integer4) time(NULL);
rluxgo_ (&luxuriance, &racine, &k1, &k2);
}
schroedinger:[~/test] > cat ranlux.f
subroutine RANLUX(RVEC, LENV)
implicit none
integer*4 I
integer*4 I24
integer*4 IN24
integer*4 ICONS
integer*4 IGIGA
integer*4 ILX
integer*4 INNER
integer*4 INOUT
integer*4 INS
integer*4 INSEED
integer*4 IOUTER
...
entry RLUXAT(LOUT,INOUT,K1,K2)
LOUT = LUXLEV
INOUT = INSEED
K1 = KOUNT
K2 = MKOUNT
return
entry RLUXGO(LUX,INS,K1,K2)
if (LUX.lt.0) then
LUXLEV = LXDFLT
else if (LUX.le.MAXLEV) then
LUXLEV = LUX
else if ((LUX.lt.24).or.(LUX.gt.2000)) then
LUXLEV = MAXLEV
else
LUXLEV = LUX
do ILX = 0, MAXLEV
if (LUX.eq.(NDSKIP(ILX) + 24)) then
LUXLEV = ILX
end if
end do
end if
if (LUXLEV.le.MAXLEV) then
NSKIP = NDSKIP(LUXLEV)
else
NSKIP = LUXLEV - 24
end if
IN24 = 0
...
end subroutine
schroedinger:[~/test] > gfortran a.c ranlux.f
schroedinger:[~/test] > ./a.out
4
schroedinger:[~/test] >
You can found the complete ranlux.f subroutine at
http://www.systella.fr/~bertrand/rpl2/download/rpl-4.00pre8q.tar.bz2
Calling a Fortran entry point from C seems to work. But if I call the same
entry point (or another) from the C function :
void
instruction_rand(struct_processus *s_etat_processus)
{
integer4k1;
integer4k2;
integer4luxuriance;
integer4nombre_valeurs;
integer4racine;
struct_objet*s_objet;
(*s_etat_processus).erreur_execution = d_ex;
if ((*s_etat_processus).affichage_arguments == 'Y')
{
printf("\n RAND ");
if ((*s_etat_processus).langue == 'F')
{
printf("(variable aléatoire uniforme)\n\n");
}
else
{
printf("(uniform random number)\n\n");
}
printf("-> 1: %s\n", d_REL);
return;
}
printf("Ici\n");
if (test_cfsf(s_etat_processus, 31) == d_vrai)
{
if (empilement_pile_last(s_etat_processus, 0) == d_erreur)
{
return;
}
}
printf("Là\n");
if ((*s_etat_processus).initialisation_generateur_aleatoire == d_faux)
{
k1 = 0;
k2 = 0;
printf("%d\n", sizeof(k1));
luxuriance = 4;
racine = (integer4) time(NULL);
rluxat_(&luxuriance, &racine, &k1, &k2);
printf("Encore ici\n");
...
I obtain a superb segmentation fault:
rayleigh:[~/gopher/rpl2/rpl-4.00pre8r/src] > LANG=C ./rpl -isd
+++RPL/2 version 4.00pre8r (Sunday 11/19/06, 16:46:42 CET)
+++Copyright (C) 1989 to 2005, 2006 BERTRAND Joël
+++This is a free software with absolutely no warranty.
+++For details, type 'warranty'.
+++rand
Ici
Là
4
Erreur de segmentation
rayleigh:[~/gopher/rpl2/rpl-4
[Bug c++/29896] ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-19 18:01 --- Reducing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||GC, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
[Bug fortran/29711] error_print does not support %N$X
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-19 18:19 --- I though I had replyed to my last comment, but seemingly I forget to "Commit" the comment. I tested with de and zh_TW (Zhonghua/Taiwan alias Guoyu) locale and the result is ok. [Well, in Chinese it least it looks as if it were correct.] The strings in Turkish are not part of gfortran. Also from looking at diff, this patch seems to be ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
[Bug target/29114] ICE when cross-compiling glibc for hppa on a 64bit host
--- Comment #9 from danglin at gcc dot gnu dot org 2006-11-19 18:24 --- Subject: Bug 29114 Author: danglin Date: Sun Nov 19 18:24:21 2006 New Revision: 118993 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118993 Log: PR target/29114 * pa.c (emit_move_sequence): Don't split constants with PLUS for modes larger than BITS_PER_WORD. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug target/29114] ICE when cross-compiling glibc for hppa on a 64bit host
--- Comment #10 from danglin at gcc dot gnu dot org 2006-11-19 18:27 --- Subject: Bug 29114 Author: danglin Date: Sun Nov 19 18:27:03 2006 New Revision: 118994 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118994 Log: PR target/29114 * pa.c (emit_move_sequence): Don't split constants with PLUS for modes larger than BITS_PER_WORD. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug target/29114] ICE when cross-compiling glibc for hppa on a 64bit host
--- Comment #11 from danglin at gcc dot gnu dot org 2006-11-19 19:06 --- Subject: Bug 29114 Author: danglin Date: Sun Nov 19 19:06:09 2006 New Revision: 118995 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118995 Log: PR target/29114 * pa.c (emit_move_sequence): Don't split constants with PLUS for modes larger than BITS_PER_WORD. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug target/29114] ICE when cross-compiling glibc for hppa on a 64bit host
--- Comment #12 from danglin at gcc dot gnu dot org 2006-11-19 19:09 --- Subject: Bug 29114 Author: danglin Date: Sun Nov 19 19:09:04 2006 New Revision: 118996 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118996 Log: PR target/29114 * pa.c (emit_move_sequence): Don't split constants with PLUS for modes larger than BITS_PER_WORD. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug target/29900] New: [4.3 regression]: fwprop triggers uninitialized read
This patch
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00141.html
triggers uninitialized read of stack register on x86. The testcase is
# cat foo.f90
MODULE foo
CONTAINS
SUBROUTINE SWPARA(IU, JU, IIL, JJL, XI, YJ, XALB, kts,kte)
INTEGER, INTENT(IN ) :: kts,kte
INTEGER, INTENT(IN ) :: IU, JU, IIL, JJL
REAL, INTENT(IN ) :: XI, YJ
REAL, INTENT(OUT) :: XALB
REAL, DIMENSION( 4, 5 ) :: ALBTAB
DATA ALBTAB/0.,0.,0.,0., &
69.,58.,40.,15.,&
90.,80.,70.,60.,&
94.,90.,82.,78.,&
96.,92.,85.,80./
XALB = 0.0
DO 200 K=kts,kte
ALBA=(ALBTAB(IU,JU)*(XI-IIL)*(YJ-JJL) &
+ALBTAB(IIL,JU)*(IU-XI)*(YJ-JJL) &
+ALBTAB(IU,JJL)*(XI-IIL)*(JU-YJ) &
+ALBTAB(IIL,JJL)*(IU-XI)*(JU-YJ)) &
/((IU-IIL)*(JU-JJL))
XALB = ALBA - XALB
200 CONTINUE
END SUBROUTINE SWPARA
END MODULE foo
# gfortran -O2 -S -o bad.s foo.f90 -da
shows
(insn:TI 55 147 171 3 (set (reg:SF 8 st)
(mult:SF (reg:SF 8 st)
(reg:SF 11 st(3 416 {*fop_sf_comm_i387} (nil)
(nil))
But SF 11 is never initialized.
--
Summary: [4.3 regression]: fwprop triggers uninitialized read
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29900
[Bug target/29114] ICE when cross-compiling glibc for hppa on a 64bit host
--- Comment #13 from danglin at gcc dot gnu dot org 2006-11-19 20:11 --- Fixed by patch. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29114
[Bug target/29900] [4.3 regression]: fwprop triggers uninitialized read
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-19 20:21 ---
I think this was already fixed via:
2006-11-14 Paolo Bonzini <[EMAIL PROTECTED]>
PR rtl-optimization/29798
* fwprop.c (use_killed_between): Check that DEF_INSN dominates
TARGET_INSN before any other check.
(fwprop_init): Always calculate dominators.
(fwprop_done): Always free them.
I cannot reproduce this on the mainline as of revision 118984 (with a fix to
fwprop.c for the bootstrap failure which I am about to send off but that should
not cause any differences here).
Can you show what exact version you are using?
This is what I get:
(insn:TI 141 143 41 3 (set (reg:SF 11 st(3) [orig:63 pretmp.100 ] [63])
(float:SF (mem:SI (reg/f:SI 7 sp) [0 S4 A8]))) 128 {*floatsisf2_i387}
(nil)
(nil))
(insn:TI 40 41 144 3 (set (reg:SF 11 st(3) [orig:64 pretmp.99 ] [64])
(minus:SF (reg:SF 14 st(6) [orig:90 pretmp.53 ] [90])
(reg:SF 11 st(3) [orig:63 pretmp.100 ] [63]))) 420 {*fop_sf_1_i387}
(nil)
(nil))
(insn:TI 47 49 131 3 (set (reg:SF 12 st(4) [orig:70 pretmp.92 ] [70])
(mult:SF (reg:SF 12 st(4) [orig:70 pretmp.92 ] [70])
(reg:SF 11 st(3) [orig:64 pretmp.99 ] [64]))) 417
{*fop_sf_comm_i387} (nil)
(nil))
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29900
[Bug target/29900] [4.3 regression]: fwprop triggers uninitialized read
--- Comment #2 from hjl at lucon dot org 2006-11-19 20:35 ---
Created an attachment (id=12645)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12645&action=view)
RTL stack dump
I am using:
gcc version 4.3.0 20061115 (experimental) [trunk revision 118860]
RTL stack dump still shows the problem:
(insn:TI 55 147 171 3 (set (reg:SF 8 st)
(mult:SF (reg:SF 8 st)
(reg:SF 11 st(3 603 {*fop_sf_comm_i387} (nil)
(nil))
SF 11 is never set before that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29900
[Bug c/29901] New: wrong warning with -Wstrict-aliasing/-fstrict-aliasing
$ gcc -Wstrict-aliasing -fstrict-aliasing -c test.c
test.c: In function f1:
test.c:2: warning: dereferencing type-punned pointer will break strict-aliasing
rules
$ cat test.c
void f2(char **p);
void f1(unsigned char *bits) { f2((char **)&bits); };
$
but:
the same address as an object of a different type, unless the
types are almost the same. For example, an `unsigned int' can
alias an `int', but not a `void*' or a `double'. A character type
may alias any other type.
Signed/unsigned casts or casts to char should not produce a warning according
to the documentation.
--
Summary: wrong warning with -Wstrict-aliasing/-fstrict-aliasing
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wavexx at users dot sf dot net
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29901
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-11-19 20:42 --- Created an attachment (id=12646) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12646&action=view) Latest update Here's the latest update of the patch, for reading, writing and backspace. In order to be able to test this at all, I set a maximums subrecord size of 16 (see the #ifdef). This is getting to the state where the patch could use testing by people who actually write > 2GB records (I can't do that on my home system). Volunteers, anybody? :-) Thomas -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #12609|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug c/29901] wrong warning with -Wstrict-aliasing/-fstrict-aliasing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-19 20:46 --- (In reply to comment #0) > but: > > the same address as an object of a different type, unless the > types are almost the same. For example, an `unsigned int' can > alias an `int', but not a `void*' or a `double'. A character type > may alias any other type. > > Signed/unsigned casts or casts to char should not produce a warning according > to the documentation. Except "unsigned char*" cannot alias "char *". The warning is correct. What the document is taking about is specificly the non pointers. -- 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=29901
[Bug target/29900] [4.3 regression]: fwprop triggers uninitialized read
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-19 20:47 --- This looks like a latent bug in regstack really, the dumps before regstack are ok in that reg 11 is initialized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29900
[Bug target/29900] [4.3 regression]: fwprop triggers stackreg to go wrong
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-19 20:50 --- the only thing fwprop does in this case is props the address. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-11-19 20:50:27 date|| Summary|[4.3 regression]: fwprop|[4.3 regression]: fwprop |triggers uninitialized read |triggers stackreg to go ||wrong Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29900
[Bug target/29900] [4.3 regression] stackreg to go wrongs after fwprop
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-19 21:01 ---
regstack is broken.
Before:
(insn:TI 70 69 71 3 (set (reg:SF 13 st(5) [orig:80 pretmp.77 ] [80])
(plus:SF (reg:SF 13 st(5) [orig:80 pretmp.77 ] [80])
(reg:SF 12 st(4) [orig:70 pretmp.92 ] [70]))) 417
{*fop_sf_comm_i387} (nil)
(expr_list:REG_DEAD (reg:SF 12 st(4) [orig:70 pretmp.92 ] [70])
(nil)))
(insn:TI 71 70 72 3 (set (reg:SF 13 st(5) [orig:80 pretmp.77 ] [80])
(plus:SF (reg:SF 13 st(5) [orig:80 pretmp.77 ] [80])
(reg:SF 10 st(2) [orig:76 pretmp.84 ] [76]))) 417
{*fop_sf_comm_i387} (nil)
(expr_list:REG_DEAD (reg:SF 10 st(2) [orig:76 pretmp.84 ] [76])
(nil)))
After:
(insn:TI 70 69 71 3 (set (reg:SF 9 st(1))
(plus:SF (reg:SF 9 st(1))
(reg:SF 8 st))) 417 {*fop_sf_comm_i387} (nil)
(expr_list:REG_DEAD (reg:SF 8 st)
(nil)))
(insn:TI 71 70 72 3 (set (reg:SF 11 st(3))
(plus:SF (reg:SF 11 st(3))
(reg:SF 8 st))) 417 {*fop_sf_comm_i387} (nil)
(expr_list:REG_DEAD (reg:SF 8 st)
(nil)))
See how we replace "reg:SF 13 st(5) " once with "(reg:SF 9 st(1))" but the
second time with "(reg:SF 11 st(3))"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29900
[Bug tree-optimization/22415] [4.0 Regression] ICE in coalesce_abnormal_edges
--- Comment #10 from tbm at cyrius dot com 2006-11-19 21:09 --- (In reply to comment #9) > That would fix it perfectly fine, i'll bootstrap and test it. ping -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22415
[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops
--- Comment #12 from rakdver at gcc dot gnu dot org 2006-11-19 21:10 --- (In reply to comment #9) > Created an attachment (id=12643) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12643&action=view) [edit] > New patch, the old one could cause a seg fault also during bootstrap > > I forgot when I changed loops to current_loops to check if current_loops was > NULL. It is not necessary to check whether current_loops->num > 0 (if current_loops is not null, current_loops->num is never zero); otherwise the patch looks ok to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879
[Bug fortran/22547] Fortran 2003: ISO_FORTRAN_ENV intrinsic module missing
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-11-19 21:30 --- Commited to mainline. -- 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=22547
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-19 21:55 --- Subject: Re: Shared libstdc++ fails to link On Mon, Nov 13, 2006 at 02:37:02AM -, pinskia at gcc dot gnu dot org wrote: > > This problem was introduced by this change: > That makes less sense really, because this just changes how to deal with > TREE_NOTHROW. This sounds like a latent bug really. The change does affect the EH table (diff attached). Hacking the assembler output for stdexcept, I find that it's the following reference that causes the error: .word L$FB0940 This symbol is a local alias for _ZNSt12domain_errorD0Ev. This symbol also occurs in functexcept.o which occurs earlier in the link list. So, it looks as if the linker can't handle absolute references to local code symbols in the second and subsequent instances of a function. Dave --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-19 21:55 --- Created an attachment (id=12647) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12647&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops
--- Comment #13 from dominiq at lps dot ens dot fr 2006-11-19 22:11 --- Applied to snapshot 4.3-20061118 on OSX 10.3, seems ok for me too, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879
[Bug tree-optimization/29891] [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault
--- Comment #1 from andreast at gcc dot gnu dot org 2006-11-19 22:13 --- Last working rev is 118744, the failure appears in 118746. But not clear why. Andreas -- andreast at gcc dot gnu dot org changed: What|Removed |Added CC||andreast at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
[Bug tree-optimization/29891] [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-19 22:26 --- I want to say the gen_insn part which exposed the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
[Bug tree-optimization/29902] New: [4.2/4.3 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:644
I get the following ICE with 4.2.0 20061116 with -fprefetch-loop-arrays: [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O3 libjingle0.3-xmppclient.cpp [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O -fprefetch-loop-arrays libjingle0.3-xmppclient.cpp libjingle0.3-xmppclient.cpp: In member function 'virtual buzz::SaslMechanism* buzz::PlainSaslHandler::CreateSaslMechanism(const std::string&)': libjingle0.3-xmppclient.cpp:231: internal compiler error: in coalesce_abnormal_edges, at tree-outof-ssa.c:644 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED]:~$ -- Summary: [4.2/4.3 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:644 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
[Bug tree-optimization/29902] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:644
--- Comment #1 from tbm at cyrius dot com 2006-11-19 22:31 --- Created an attachment (id=12648) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12648&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
[Bug c++/29896] ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-19 23:14 ---
Reduced testcase:
struct filename_pool
{
struct holder
{
friend void intrusive_ptr_release(holder* p){}
};
friend void intrusive_ptr_release(holder*);
};
--
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=29896
[Bug c++/29896] ice on wrong code in in ggc_set_mark, at ggc-page.c:1262
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-19 23:16 --- This is a dup of bug 27100. *** This bug has been marked as a duplicate of 27100 *** -- 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=29896
[Bug c++/27100] ICE with multiple friend declarations
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-19 23:16 --- *** Bug 29896 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||baraclese at googlemail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100
[Bug target/29900] [4.3 regression] stackreg to go wrongs after fwprop
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-19 23:23 --- Adding Roger as CC because this is a bug in regstack as far as I can tell. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sayle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29900
[Bug tree-optimization/29902] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:644
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
[Bug tree-optimization/29891] [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-20 00:22 --- Subject: Re: [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault > I want to say the gen_insn part which exposed the problem. I still have the ICE after reverting this part. Trying the reorg part. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
[Bug tree-optimization/29902] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:644
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-20 00:23 ---
Reduced testcase:
int length1();
int g(int);
void f(int capacity_, char *old_storage)
{
try {
length1();
int old_capacity = capacity_;
capacity_ *= 2;
g(capacity_);
for (int i = 1; i < old_capacity; i++)
old_storage[i] = old_storage[i - 1];
} catch (...) {
for (int i = 1; i < capacity_; i++){}
}
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-11-20 00:23:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
[Bug tree-optimization/29902] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:644
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-20 00:27 ---
I think after remove empty loops, we should add a DCE pass which should fix the
above reduced testcase but will not fix this reduced testcase:
int length1();
int g(int);
void f(int capacity_, char*old_storage)
{
try {
length1();
int old_capacity = capacity_;
capacity_ *= 2;
g(capacity_);
for (int i = 1; i < old_capacity; i++)
old_storage[i] = old_storage[i - 1];
} catch (...) {
for (int i = 1; i < capacity_; i++){old_storage[i] = 0;}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
[Bug fortran/29899] [Segfault] Fortran entry point caught from C function
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29899
[Bug debug/29903] New: FAIL: gcc.c-torture/execute/mayalias-3.c compilation, -O3 -g (internal compiler error)
Executing on host: /home/dave/gcc-4.3/objdir/gcc/xgcc -B/home/dave/gcc-4.3/objdi r/gcc/ /home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c -w -O3 -g -fno-show-column -lm -o /home/dave/gcc-4.3/objdir/gcc/testsuite/g cc/mayalias-3.x4(timeout = 300) /home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c:2: inter nal compiler error: in splice_child_die, at dwarf2out.c:5564 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c:2: inter nal compiler error: in splice_child_die, at dwarf2out.c:5564 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. FAIL: gcc.c-torture/execute/mayalias-3.c compilation, -O3 -g (internal compile r error) UNRESOLVED: gcc.c-torture/execute/mayalias-3.c execution, -O3 -g Seems to be the same failure as for mayalias-2.c. -- Summary: FAIL: gcc.c-torture/execute/mayalias-3.c compilation, - O3 -g (internal compiler error) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29903
[Bug debug/29903] FAIL: gcc.c-torture/execute/mayalias-3.c compilation, -O3 -g (internal compiler error)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-20 00:49 --- It is the same failure as mayalias-2.c as I added both, the code is only slightly different between those two. *** This bug has been marked as a duplicate of 28834 *** -- 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=29903
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-11-20 00:49 --- *** Bug 29903 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug tree-optimization/29902] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:644
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-20 00:23:35 |2006-11-20 01:01:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
[Bug c++/8586] -Wwrite-strings should be included in -Wall
--- Comment #5 from gdr at gcc dot gnu dot org 2006-11-20 01:04 ---
Subject: Bug 8586
Author: gdr
Date: Mon Nov 20 01:03:49 2006
New Revision: 119009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119009
Log:
2006-11-19 Gabriel Dos Reis <[EMAIL PROTECTED]>
PR c++/8586
* c-opts.c (c_common_handle_option): Enable -Wwrite-strings if
-Wall.
testsuite/
2006-11-19 Gabriel Dos Reis <[EMAIL PROTECTED]>
PR c++/8586
* g++.dg/warn/Wall-write-strings.C: New.
Added:
trunk/gcc/testsuite/g++.dg/warn/Wall-write-strings.C (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-opts.c
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/g++.dg/warn/Wall-write-strings.C
('svn:mime-type' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8586
