[Bug target/24623] [4.1 Regression] internal compiler error: in propagate_one_insn, at flow.c:1702
--- Comment #5 from krebbel1 at de dot ibm dot com 2005-11-04 08:02 --- The problem occurs when a landing pad is optimized away but the special code in s390_regs_ever_clobbered insists on saving all eh registers. The special code in that function exists because the eh regs may be read in a function (inside the landing pad) without beeing set before. In that case s390_regs_ever_clobbered would not consider them to be saved. With the attached patch the eh regs for a landing pad are only saved if regs_ever_live is true for them. I will not post the patch until I have decided how to fix PR 24624. It is possible that 24624 can only be fixed by reverting my patch introducing regs_ever_clobbered. If that patch gets reverted this fix is obsolete of course. That fixes the testcase in the PR. Bootstrapped on s390 and s390x - no testsuite regressions. OK for mainline? Bye, -Andreas- 2005-11-03 Andreas Krebbel [EMAIL PROTECTED] * config/s390/s390.c (s390_regs_ever_clobbered): Only save LIVE eh regs for a function containing a landing pad. Index: gcc/config/s390/s390.c === RCS file: /cvs/gcc/gcc/gcc/config/s390/s390.c,v retrieving revision 1.257 diff -p -c -r1.257 s390.c *** gcc/config/s390/s390.c 30 Sep 2005 15:36:15 - 1.257 --- gcc/config/s390/s390.c 3 Nov 2005 12:56:06 - *** s390_regs_ever_clobbered (int *regs_ever *** 5874,5880 deal with this automatically. */ if (current_function_calls_eh_return || cfun-machine-has_landing_pad_p) for (i = 0; EH_RETURN_DATA_REGNO (i) != INVALID_REGNUM ; i++) ! regs_ever_clobbered[EH_RETURN_DATA_REGNO (i)] = 1; /* For nonlocal gotos all call-saved registers have to be saved. This flag is also set for the unwinding code in libgcc. --- 5874,5883 deal with this automatically. */ if (current_function_calls_eh_return || cfun-machine-has_landing_pad_p) for (i = 0; EH_RETURN_DATA_REGNO (i) != INVALID_REGNUM ; i++) ! if (current_function_calls_eh_return ! || (cfun-machine-has_landing_pad_p ! regs_ever_live [EH_RETURN_DATA_REGNO (i)])) ! regs_ever_clobbered[EH_RETURN_DATA_REGNO (i)] = 1; /* For nonlocal gotos all call-saved registers have to be saved. This flag is also set for the unwinding code in libgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24623
[Bug fortran/18452] Fortran options induces warning for fortran that needs preprocessing
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:29 --- Subject: Bug 18452 Author: fxcoudert Date: Fri Nov 4 08:29:16 2005 New Revision: 106483 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106483 Log: PR fortran/18452 * gcc/fortran/lang-specs.h: Pass -lang-fortran to the preprocessor. * gcc/c.opt: Add a -lang-fortran option. * gcc/c-opts.c: Add a lang_fortran flag. (c_common_init_options): Handling the -lang-fortran option. (c_common_handle_option): Add a case for Fortran options in preprocessing. Remove cases for -ffixed-form and -ffixed-line-length. Add a case for -lang-fortran. Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/gcc/c.opt trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/lang-specs.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug fortran/18452] Fortran options induces warning for fortran that needs preprocessing
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:31 --- Hurray, hurray, this bug is fixed! Now, could we get libgfortran building with -Werror? :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED GCC host triplet|i686-gnu-linux | Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18452
[Bug libfortran/22298] libgfortran init() constructor isn't called if executable is statically linked
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:44 --- Subject: Bug 22298 Author: fxcoudert Date: Fri Nov 4 08:44:29 2005 New Revision: 106484 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106484 Log: PR libfortran/22298 * runtime/main.c (stupid_function_name_for_static_linking): New function. * runtime/error.c (internal_error): Call stupid_function_name_for_static_linking. * libgfortran.h: Add prototype for stupid_function_name_for_static_linking. * gcc/testsuite/lib/target-supports.exp (check_effective_target_static_libgfortran): New static_libgfortran effective target. * gcc/testsuite/gfortran.dg/static_linking_1.f: New test. * gcc/testsuite/gfortran.dg/static_linking_1.c: New file. Added: trunk/gcc/testsuite/gfortran.dg/static_linking_1.c trunk/gcc/testsuite/gfortran.dg/static_linking_1.f Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp trunk/libgfortran/ChangeLog trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22298
[Bug libfortran/22298] libgfortran init() constructor isn't called if executable is statically linked
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:49 --- Subject: Bug 22298 Author: fxcoudert Date: Fri Nov 4 08:49:18 2005 New Revision: 106485 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106485 Log: PR libfortran/22298 * runtime/main.c (stupid_function_name_for_static_linking): New function. * runtime/error.c (internal_error): Call stupid_function_name_for_static_linking. * libgfortran.h: Add prototype for stupid_function_name_for_static_linking. * gcc/testsuite/lib/target-supports.exp (check_effective_target_static_libgfortran): New static_libgfortran effective target. * gcc/testsuite/gfortran.dg/static_linking_1.f: New test. * gcc/testsuite/gfortran.dg/static_linking_1.c: New file. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/static_linking_1.c - copied unchanged from r106484, trunk/gcc/testsuite/gfortran.dg/static_linking_1.c branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/static_linking_1.f - copied unchanged from r106484, trunk/gcc/testsuite/gfortran.dg/static_linking_1.f Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/lib/target-supports.exp branches/gcc-4_0-branch/libgfortran/ChangeLog branches/gcc-4_0-branch/libgfortran/libgfortran.h branches/gcc-4_0-branch/libgfortran/runtime/error.c branches/gcc-4_0-branch/libgfortran/runtime/main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22298
[Bug libfortran/22298] libgfortran init() constructor isn't called if executable is statically linked
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-11-04 08:50 --- Fixed on both 4.0 and 4.1. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22298
[Bug debug/24634] DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world
--- Comment #5 from mlynarik at decef dot elf dot stuba dot sk 2005-11-04 09:03 --- Created an attachment (id=10141) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10141action=view) Assembler source of comiled example2-32.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
[Bug debug/24634] DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world
--- Comment #6 from mlynarik at decef dot elf dot stuba dot sk 2005-11-04 09:04 --- Created an attachment (id=10142) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10142action=view) Assembler source from compilation of example2-64.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
[Bug tree-optimization/24669] New: Loop index variable has offset of 1
A simple loop:
void foo (int *a, int *b)
{
int i;
for (i = 0; i 4; i++)
b[i] = a[i];
}
gets compiled to (gcc -O2 -fomit-frame-pointer):
pushl %ebx
movl$1, %edx index starts with 1
movl8(%esp), %ebx
movl12(%esp), %ecx
.p2align 4,,15
.L2:
movl-4(%ebx,%edx,4), %eax it is compensated by -4 here
movl%eax, -4(%ecx,%edx,4) and here
incl%edx
cmpl$5, %edxcompare with N+1
jne .L2
popl%ebx
ret
The problem is, that index variable has offset of 1 and it has to be
compensated by appropriate negative offset in the address.
The optimized tree dump shows:
bb 0:
ivtmp.33 = 1;
L0:;
D.1347 = (int *) ivtmp.33;
MEM[base: b, index: D.1347, step: 4B, offset: -4B] = MEM[base: a, index:
D.1347, step: 4B, offset
: -4B];
ivtmp.33 = ivtmp.33 + 1;
if (ivtmp.33 != 5) goto L0; else goto L2;
L2:;
return;
One would expect the index to start with 0 as this enables use of xor for
initialization. Perhaps non-zero address offset also disables some
optimizations.
--
Summary: Loop index variable has offset of 1
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug libfortran/21547] Unable to build libfortran library
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-04 09:11 --- Patch proposed: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00244.html -- 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 URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00244.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-05-31 16:52:32 |2005-11-04 09:11:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547
[Bug debug/24634] DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world
--- Comment #7 from mlynarik at decef dot elf dot stuba dot sk 2005-11-04 09:12 --- We have created the assembler sources with the parameters -dA. You can see that there are no differences between the 32bit and 64bit versions except the length of the fields (4bytes and 8bytes). So I think there souldn't be a difference between these two versions concerning these attributes in the .o files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
[Bug libfortran/23138] [mingw32] real values are printed incorrectly
--- Comment #9 from dannysmith at users dot sourceforge dot net 2005-11-04 09:15 --- Hello, mingw has an implementation of _IO_ldtoa() and _IO_ldtostr(), based on Stephen Moshier's ioldoubl package, that could be used. Currently, the ldtoa function is not exposed, but there is no reason why it couldn't be. newlib provides a ldtoa() )also based on S Moshier's package that could be used on cygwin and other newlib targets. Would a ldtoa alternative to sprintf be acceptable? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23138
[Bug tree-optimization/24669] Loop index variable has offset of 1
--- Comment #1 from uros at kss-loka dot si 2005-11-04 09:20 --- -fno-ivopts produces: movl16(%esp), %edi movl20(%esp), %esi xorl%ebx, %ebx movl$4, %ecx index starts with 1 .L2: leal(%ebx,%ebx), %edx movl(%edi,%edx,2), %eax movl%eax, (%esi,%edx,2) addl$1, %ebx subl$1, %ecx no compare! jne .L2 Hm, why isn't produced something like: movl8(%esp), %ebx movl12(%esp), %ecx movl$4, %edx .L2: movl(%ebx,%edx,4), %eax movl%eax, (%ecx,%edx,4) dec %edx jne .L2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug target/22209] [4.1 regression] libgfortran unresolvable symbols on irix6.5
--- Comment #4 from rsandifo at gcc dot gnu dot org 2005-11-04 09:22 --- I think TImode has to be a workable mode for IRIX 6. Long double is TFmode, and it would certainly seem odd to support TImode and not TFmode. (I seem to remember the s390 folks having to add TImode support exactly because they had TFmode support. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22209
[Bug libfortran/23138] [mingw32] real values are printed incorrectly
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2005-11-04 09:27 --- (In reply to comment #9) Would a ldtoa alternative to sprintf be acceptable? Yes, it would be very nice to have and we could use it in gfortran. Please keep us (bugzilla) posted of new developments on this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23138
[Bug c++/22487] C++ front-end produces mis-match types in EQ_EXPR (array constructor)
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-04 09:46 --- Subject: Bug 22487 Author: rguenth Date: Fri Nov 4 09:46:43 2005 New Revision: 106487 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106487 Log: 2005-11-04 Richard Guenther [EMAIL PROTECTED] PR c++/22487 * init.c (build_vec_init): Build comparison of matching types. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22487
[Bug c++/22487] C++ front-end produces mis-match types in EQ_EXPR (array constructor)
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-11-04 09:47 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22487
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #20 from rakdver at gcc dot gnu dot org 2005-11-04 10:04 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00246.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug tree-optimization/24669] Loop index variable has offset of 1
--- Comment #2 from rakdver at gcc dot gnu dot org 2005-11-04 10:35 ---
There are two reasons we do not produce the code as in the comment #1:
1) This would require reversing the loop, which is currently implemented in
mainline only in old loop optimizer, in a very weak fashion. More powerful
implementation is in killloop branch and should appear in 4.2.
2) Nevertheless, in this particular example we cannot reverse the loop at all
(i.e., the proposed code is incorrect) -- it would cause misscompilations for
example if foo is called as foo(p + 1, p). If p = {1,2,3,4,5}, the original
code sets it to {1,1,1,1,1}, while the new one to {1,1,2,3,4}.
The fact that the index variable is chosen to start with 1 instead of zero is
more interesting. It does not really matter that much, since both
possibilities have exactly the same cost. But the reason is that target
description pretends that the more complicated addressing mode is in fact
cheaper, thus misguiding ivopts to prefer it to the simpler one, if everything
else is equal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug rtl-optimization/23567] [3.4/4.0/4.1 regression] if-conversion causes wrong code
--- Comment #8 from jakub at gcc dot gnu dot org 2005-11-04 10:52 --- Sorry, haven't touched this for a while. Testing a new patch, there have been other problems in noce_process_if_block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
[Bug target/23775] [4.1 Regression] wrong code in argument passing
-- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
[Bug tree-optimization/24670] New: VRP ICE in compare_name_with_value
This ICE occured during a compile of libfloat with mainline.
Attached is a delta reduced test that produces the ICE when compiled with -O2.
softfloat/bits64/softfloat.c: In function float128_rem:
softfloat/bits64/softfloat.c:4483: internal compiler error: in
compare_name_with_value, at tree-vrp.c:3064
__inline__ void
shift128Right (int count, long long int *z1Ptr)
{
long long int z1;
if (count == 0);
else if (count 64);
else
z1 = (count 64) ? count : 0;
*z1Ptr = z1;
}
float128_rem ()
{
signed int expDiff;
long long int aSig1;
long long int sigMean1;
if (-64 expDiff)
shift128Right (-expDiff, aSig1);
add128 (sigMean1);
}
--
Summary: VRP ICE in compare_name_with_value
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot pop at cri dot ensmp dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug c++/24668] visibility attributes on namespaces
--- Comment #1 from pluto at agmk dot net 2005-11-04 11:06 --- what about PR21764 (linked in PR19664)? duplication? -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24668
[Bug ada/20753] ACATS ce3810b segfaults at runtime
--- Comment #8 from christian dot joensson at gmail dot com 2005-11-04 11:24 --- Just a ping here... are there any progress on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20753
[Bug c++/24671] New: [4.0/4.1 regression] ICE with zero-sized arrays
The following testcase causes an ICE:
==
templatetypename struct A
{
typedef int X;
static const int i = 0;
};
templatetypename struct B
{
typedef typename Achar[AB::i]::X Y;
templatetypename T B(T, Y);
};
Bint b(0,0);
==
dPR19208B.cc:10: internal compiler error: in push_access_scope, at cp/pt.c:176
Please submit a full bug report, [etc.]
The testcase crashed since at least gcc 2.95.3, but was fixed with the
patch for PR19208. The problem reappeared on the 3.4 branch and mainline
with Josh's patch for PR 19989.
I think the code should be accepted at least with -fpermissive,
but rejected with -pedantic.
--
Summary: [4.0/4.1 regression] ICE with zero-sized arrays
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Keywords: ice-on-valid-code, ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 19208,19989
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24671
[Bug target/24672] New: ICE on missing parentheses for constructor
The following invalid code snippet (which is similar to PR 22257)
causes an ICE on x86-64:
=
struct A
{
int i, j;
A : i(), j() {}
};
=
bug.cc:4: error: 'A::i' cannot appear in a constant-expression
bug.cc:4: error: a function call cannot appear in a constant-expression
bug.cc:4: error: name 'A' has incomplete type
bug.cc:4: error: declaration of 'A A::j()'
bug.cc:3: error: conflicts with previous declaration 'int A::j'
bug.cc: In member function 'A A::j()':
bug.cc:4: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in classify_argument, at config/i386/i386.c:2653
Please submit a full bug report, [etc.]
Since classify_argument is a x86_64-specific function, the ICE doesn't
appear on i686. So it's target dependent.
OTOH it might be a frontend bug that we end up in classify_argument at all
with invalid data.
--
Summary: ICE on missing parentheses for constructor
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
BugsThisDependsOn: 19964,22257
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24672
[Bug middle-end/24635] Wrong statement reordering
--- Comment #3 from worm at arrakis dot es 2005-11-04 12:13 --- Created an attachment (id=10143) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10143action=view) This one triggers the bug The new file definitely triggers the problem with statement reordering if compiled with (-O2), but after a second read of the standard, I am not sure whether arguments of a function are implicitely declared volatile or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug tree-optimization/24669] Loop index variable has offset of 1
--- Comment #3 from uros at kss-loka dot si 2005-11-04 12:19 --- Following patch to ix86_address_cost: --- i386.c (revision 106482) +++ i386.c (working copy) @@ -5396,8 +5396,12 @@ if (parts.index GET_CODE (parts.index) == SUBREG) parts.index = SUBREG_REG (parts.index); + /* Penalize displacements a bit. */ + if (parts.disp parts.disp != const0_rtx) +cost++; + /* More complex memory references are better. */ - if (parts.disp parts.disp != const0_rtx) + if (parts.scale) cost--; if (parts.seg != SEG_DEFAULT) cost--; generates: pushl %ebx movl8(%esp), %ebx movl12(%esp), %ecx xorl%edx, %edx .L2: movl(%ebx,%edx,4), %eax movl%eax, (%ecx,%edx,4) addl$1, %edx cmpl$4, %edx jne .L2 popl%ebx ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug c++/24668] visibility attributes on namespaces
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-04 13:05 --- This is a dup of bug 21764 as far as I can see. *** This bug has been marked as a duplicate of 21764 *** -- 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=24668
[Bug c++/21764] visibility attributes on namespace scope
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-04 13:05 --- *** Bug 24668 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764
[Bug debug/24634] DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 13:10 --- What you are seing is either an assmebler bug or just dwarfdump not supporting relocations for 64bit. I want to say the latter. This is not a GCC bug. -- 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=24634
[Bug tree-optimization/24670] [4.1 Regression] VRP ICE in compare_name_with_value
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Keywords||ice-on-valid-code Summary|VRP ICE in |[4.1 Regression] VRP ICE in |compare_name_with_value |compare_name_with_value Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug tree-optimization/24670] [4.1 Regression] VRP ICE in compare_name_with_value
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:16 --- Confirmed. -- 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 |2005-11-04 13:16:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug c++/24671] [4.0/4.1 regression] ICE with zero-sized arrays
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:19 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-04 13:19:06 date|| Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24671
[Bug middle-end/24635] Wrong statement reordering
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-04 13:25 --- I still cannot reproduce it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug tree-optimization/24670] [4.1 Regression] VRP ICE in compare_name_with_value
-- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC|dnovillo at redhat dot com | AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug target/24672] ICE on missing parentheses for constructor
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 13:28 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||error-recovery Last reconfirmed|-00-00 00:00:00 |2005-11-04 13:28:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24672
[Bug middle-end/24635] Wrong statement reordering
--- Comment #5 from worm at arrakis dot es 2005-11-04 13:35 --- Sorry for my stupidity -- the jet-lag after a long trip seems to affect me --. Remove the volatile statement from the arguments list of L1foo. Then the assignments to the variable V1 are moved after the call to cl_throw() and are never executed. I am not sure whether this conforms to the standard or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug tree-optimization/24599] [4.0 regression] segv after overflow detection
--- Comment #4 from rakdver at gcc dot gnu dot org 2005-11-04 13:39 --- Nevertheless, the fact that boolean_true_node has overflow flag set is wrong, this should not happen -- shared constants should not be modified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug tree-optimization/24599] [4.0 regression] segv after overflow detection
--- Comment #5 from rakdver at gcc dot gnu dot org 2005-11-04 14:02 ---
This happens in c-typeck.c:build_c_cast:
value = convert (type, value);
/* Ignore any integer overflow caused by the cast. */
if (TREE_CODE (value) == INTEGER_CST)
{
/* If OVALUE had overflow set, then so will VALUE, so it
is safe to overwrite. */
if (CONSTANT_CLASS_P (ovalue))
{
TREE_OVERFLOW (value) = TREE_OVERFLOW (ovalue);
/* Similarly, constant_overflow cannot have become cleared. */
TREE_CONSTANT_OVERFLOW (value) = TREE_CONSTANT_OVERFLOW (ovalue);
}
build_c_cast assumes that convert will not return non-overflowed constant if it
received an overflowed one. This however is not true, since
convert (boolean_type_node, ...) will sometimes return shared
boolean_{true,false}_node constants.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug middle-end/24635] Wrong statement reordering
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 14:05 --- Removing volatile will change the semantics of the program and therefor not a bug. GCC docs mention with (I cannot find right now as I am at a Kiosk and it is hard to find anything) longjmp, volatile is required. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug fortran/24673] New: internal compiler error in fold_convert, at fold-const.c:2028
Hi, This bug seems not very different from bug #20244 but happens at a different line in the same function. during compilation of my code I get the following error mesage: [EMAIL PROTECTED] 5common]$ /usr/local/bin/gfortran -c ../../../src/5common/funcofrho_tfw.F90 ../../../src/5common/funcofrho_tfw.F90: In function init_eneofrho_tfw: ../../../src/5common/funcofrho_tfw.F90:82: internal compiler error: in fold_convert, at fold-const.c:2028 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Sorry but I can't reduce the code more than that. It's in three files of which onlys the first result in an error: FUNCOFRHO_TFW.F90: module funcofrho_tfw use defs_basis use defs_datatypes implicit none !! common variables copied from input integer :: ngfft(18),nfftf real(dp):: ucvol type(MPI_type) :: mpi_enreg real(dp),allocatable::deltaW(:,:) real(dp),allocatable::lavnlfft(:,:) real(dp),allocatable::vtrial(:,:) !! common variables computed logical :: ok=.false. integer :: nfftot real(dp):: alpha !! initialisation routine contains !!---!! !! initialisation subroutine !!---!! subroutine init_eneofrho_tfw(ngfft_in,nfftf_in,mpi_enreg_in,ucvol_in,deltaW_in, lavnlfft_in,vtrial_in ) use defs_basis use defs_datatypes implicit none !Arguments integer,intent(in) :: ngfft_in(18),nfftf_in type(MPI_type),intent(in) :: mpi_enreg_in real(dp),intent(in):: ucvol_in real(dp),dimension(:,:),intent(in)::deltaW_in(:,:) real(dp),dimension(:,:),intent(in)::lavnlfft_in(:,:) real(dp),dimension(:,:),intent(in)::vtrial_in(:,:) !Local variables--- !!allocation and array transfer allocate(deltaW(size(deltaW_in,1),size(deltaW_in,2)), lavnlfft(size(lavnlfft_in,1),size(lavnlfft_in,2)), vtrial(size(vtrial_in,1),size(vtrial_in,2))) deltaW=deltaW_in lavnlfft=lavnlfft_in vtrial=vtrial_in ngfft=ngfft_in nfftf=nfftf_in ucvol=ucvol_in mpi_enreg=mpi_enreg_in !! set ok to 1 which allow using eneofrho_tfw ok = .true. !! alpha is a constant factor used many times in the tfw calculation of energy alpha=(3._dp*pi*pi)**two_thirds !!total number of grid point (from energy.F90) nfftot=ngfft(1)*ngfft(2)*ngfft(3) end subroutine init_eneofrho_tfw end module funcofrho_tfw DEFS_BASIS.F90 module defs_basis implicit none integer, parameter :: i1b=selected_int_kind(2) integer, parameter :: i2b=selected_int_kind(4) integer, parameter :: i4b=selected_int_kind(9) integer, parameter :: dp=kind(1.0d0) integer, parameter :: dpc=kind((1.0d0,1.0d0)) integer, parameter :: lgt=kind(.true.) integer, parameter :: fnlen=132! maximum length of file name variables integer, parameter :: strlen=32000 ! maximum length of input string integer, parameter :: integer_not_used=0 logical, parameter :: logical_not_used=.true. integer, parameter :: std_in=5,ab_in=5 integer, parameter :: std_out=6 integer, parameter :: ab_out=7 integer, parameter :: tmp_unit=9,tmp_unit2=10 real(dp), parameter :: zero=0._dp real(dp), parameter :: one=1._dp real(dp), parameter :: two=2._dp real(dp), parameter :: three=3._dp real(dp), parameter :: four=4._dp real(dp), parameter :: five=5._dp real(dp), parameter :: six=6._dp real(dp), parameter :: seven=7._dp real(dp), parameter :: eight=8._dp real(dp), parameter :: nine=9._dp real(dp), parameter :: ten=10._dp !Fractionary real constants real(dp), parameter :: half=0.50_dp real(dp), parameter :: third=one/three real(dp), parameter :: quarter=0.25_dp real(dp), parameter :: fifth=0.20_dp real(dp), parameter :: sixth=one/six real(dp), parameter :: seventh=one/seven real(dp), parameter :: eighth=0.125_dp real(dp), parameter :: ninth=one/nine real(dp), parameter :: two_thirds=two*third real(dp), parameter :: four_thirds=four*third real(dp), parameter :: five_thirds=five*third real(dp), parameter :: three_quarters=0.75_dp real(dp), parameter :: three_fifth=three/five !Real constants derived from pi real(dp), parameter :: gold=1.618033988749894848204586834365638117720309179_dp real(dp), parameter :: goldenratio=two-gold real(dp), parameter :: pi=3.141592653589793238462643383279502884197_dp real(dp), parameter :: two_pi=two*pi real(dp), parameter :: four_pi=four*pi real(dp), parameter :: piinv=one/pi end module defs_basis DEFS_DATATYPES.F90 module defs_datatypes use defs_basis #if defined MPIO include 'mpif.h' #endif implicit none !-- !!t* defs_datatypes/MPI_type !! NAME !! MPI_type !! !! FUNCTION !! The MPI_type structured datatype gather different information !! about the MPI
[Bug tree-optimization/24670] [4.1 Regression] VRP ICE in compare_name_with_value
--- Comment #2 from dnovillo at gcc dot gnu dot org 2005-11-04 14:19 --- testing fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24670
[Bug fortran/24673] internal compiler error in fold_convert, at fold-const.c:2028
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 14:26 --- It is the same as PR 20244, the line number changed because fold-const.c has changed and addded code. *** This bug has been marked as a duplicate of 20244 *** -- 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=24673
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-04 14:26 --- *** Bug 24673 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||anglade at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug ada/20753] ACATS ce3810b segfaults at runtime
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-04 14:27 --- Subject: Re: ACATS ce3810b segfaults at runtime --- Comment #8 from christian dot joensson at gmail dot com 2005-11-04 11:24 --- Just a ping here... are there any progress on this? No, I haven't had time to investigate further. The status is still the same. See http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00124.html. The majority of the Ada failures are caused by this problem. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20753
[Bug c++/24667] [4.0/4.1 Regression] -Wcast-qual fails to reject offending cast for a old style cast
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-04 14:33 --- Hmm, old (C) style casts are weird, IIRC they act as either a static_cast, a reinterpret_cast, or a const_cast. In this case they are acting like a const_cast which is what is normally goes and gets rid of a qualifier. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Summary|-Wcast-qual fails to reject |[4.0/4.1 Regression] -Wcast- |offending cast |qual fails to reject ||offending cast for a old ||style cast Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24667
[Bug libstdc++/21072] base allocator change shared object issues
--- Comment #5 from matz at suse dot de 2005-11-04 14:45 --- While 4.0 had this fixed, trunk still uses the 'mt' allocator by default on linux, and hence is incompatible with 3.4 and 4.0 by default. Is that really intended, or shouldn't also trunk default back to the 'new' allocator? -- matz at suse dot de changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
Re: arm-elf-nm --print-size fails on static variables
2005/11/3, Daniel Jacobowitz [EMAIL PROTECTED]: On Thu, Nov 03, 2005 at 02:15:27PM -0700, Shaun Jackman wrote: When an object file is compiled by arm-elf-gcc 4.0.2, nm -S 2.16.* isn't printing the size of static variables. I'd very much appreciate a fix or workaround, if one is out there. Check what the file really says, using readelf. If the sizes are unset, check a CVS version of GCC or report the bug to GCC's bugzilla. That's more likely than an nm bug. It certainly appears to be a GCC bug. Cheers, Shaun $ cat foo.c int foo; static int static_foo; $ arm-elf-gcc -c foo.c $ arm-elf-readelf -s foo.o | grep foo 1: 0 FILELOCAL DEFAULT ABS foo.c 6: 0 NOTYPE LOCAL DEFAULT3 static_foo 8: 0004 4 OBJECT GLOBAL DEFAULT COM foo $ gcc -c foo.c $ readelf -s foo.o | grep foo 1: 0 FILELOCAL DEFAULT ABS foo.c 5: 4 OBJECT LOCAL DEFAULT3 static_foo 8: 0004 4 OBJECT GLOBAL DEFAULT COM foo $ arm-elf-gcc --version | head -1 arm-elf-gcc (GCC) 4.0.2 $ arm-elf-readelf --version | head -1 GNU readelf 2.16.91 20051103 $ gcc --version | head -1 gcc (GCC) 4.0.2 (Debian 4.0.2-2) $ readelf --version | head -1 GNU readelf 2.16.1-multiarch Debian GNU/Linux
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #4 from anglade at gmail dot com 2005-11-04 14:54 --- Hi all, Looking at the examples of failure due to this bug, I've observed that they are due to user defined datatype. The function fold_convert seems to handle only intrinsic datatypes while the examples were using user defined one. If user-defined datatypes are removed, the compilation just go through fine. This feeling about datatype is confirmed by a meer look at fold-const.c. Which is switch/casing the datatypes. Unfortunately I'm not a gcc expert and really don't know how this should be bug-fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-04 14:58 --- (In reply to comment #4) Unfortunately I'm not a gcc expert and really don't know how this should be bug-fixed. The way this bug needs to be fixed is one of the following: 1. the types generated need to be in the exact location 2. The types need to be declared as TYPE variants of one another. 3. The fortran front-end needs to say that these types are compatible. All of the above need to be fixed in the front-end and not in the middle-end where fold_convert resides. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 14:59 --- (In reply to comment #5) Oh and one more thing, the use of fold_convert is not the incorrect thing to do here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug c/24675] New: Stack corruption in ARM arch. if 64bit variable is passed to a function of which the low 32 use the register and the up 32 use the stack
Reproducable: Very easy to reproduce with the sample code
application provided. PLEASE COMPILE the code with -O2 option.
Product: GCC for ARMV5L
Component: C
Version: 3.2.1. (Reported also in ARM Linux community to
be see with gcc 3.3.4, gcc 3.4.2)
Host Platform: x86 Linux 2.4.x
Target Platform: Intel Xscale 80315 (ARMV5L) running Linux 2.4.28.
Issue should be seen with most of the ARM target.
Description:
Stack corruption is seen in ARM arch. when many variables
are passed to a function AND
if one of the variable is long long AND
if that long long variable is passed by its lower-32 use the
register and the upper-32 use the stack (a case when r0, r1,
r2 is already used by other passed variables)
Values are not correctly passed to the function.
Sample Code (PLEASE COMPILE with -O2 option):
#include stdio.h
typedef unsigned char u8;
typedef unsigned int u32;
typedef unsigned long long u64;
void testfunction (void *buffer1, void *buffer2, u8 count, u64 startsector);
void calledfunction1(void *buffer, u64 startsector, u32 count, u8
opcode, u32 sign);
main()
{
testfunction (NULL, NULL, 8, 0x700ULL);
}
void testfunction (void *buffer1, void *buffer2, u8 count, u64 startsector)
{
calledfunction1 (NULL, startsector, 0x55, 0x20, 0x3a3a3a3a);
}
void calledfunction1 (void *buffer, u64 startsector, u32 count,
u8 opcode, u32 sign)
{
if(opcode == 0x3a)
printf( opcode now is 0x3a\n);
printf (opcode: %x, , opcode);
printf( sign:%x\n,sign);
return;
}
Output of the Sample Code:
opcode now is 0x3a
opcode: 3a, sign:40039420
Expected Output of the Sample Code:
opcode: 20, sign:3a3a3a3a
--
Summary: Stack corruption in ARM arch. if 64bit variable is
passed to a function of which the low 32 use the
register and the up 32 use the stack
Product: gcc
Version: 3.2.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bill dot thompsons at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24675
[Bug target/24675] Stack corruption in ARM arch. if 64bit variable is passed to a function of which the low 32 use the register and the up 32 use the stack
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 15:08 --- 3.2.1 is an old compiler and the 3.2 series is no longer being updated, can you try either a 3.3.6 (note the 3.3 series is not being updated either) or a 3.4.4 or a 4.0.2 GCC? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24675
[Bug libgcj/14358] Selection of default encoding is not sufficient with EUC-JP on FreeBSD
--- Comment #5 from tromey at gcc dot gnu dot org 2005-11-04 15:08 --- Subject: Bug 14358 Author: tromey Date: Fri Nov 4 15:08:18 2005 New Revision: 106490 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106490 Log: PR libgcj/14358, libgcj/24552: * gnu/gcj/convert/IOConverter.java: Regenerate aliases. Add aliases for 'euc_jp' and 'eucjp'. * scripts/encodings.pl: Recognize 'none', not 'NONE'. Include canonical names in output. (%map): Added UnicodeLittle and UnicodeBig. Modified: trunk/libjava/ChangeLog trunk/libjava/gnu/gcj/convert/IOConverter.java trunk/libjava/scripts/encodings.pl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14358
[Bug libgcj/14358] Selection of default encoding is not sufficient with EUC-JP on FreeBSD
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-04 15:09 --- Fix is on 4.0 branch and trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14358
[Bug libgcj/24552] Encoding alias EUC_JP missing
--- Comment #5 from tromey at gcc dot gnu dot org 2005-11-04 15:09 --- Fix is on 4.0 branch and trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24552
[Bug middle-end/24635] Wrong statement reordering
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-04 15:24 --- Woops, that should have been ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2005-11-04 15:24:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug middle-end/24635] Wrong statement reordering
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 15:24 --- Woops, that should have been ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug middle-end/24635] Wrong statement reordering
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-04 15:25 --- Closed as invalid. -- 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=24635
[Bug c/24599] [4.0/4.1 regression] Overflow for true value
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-04 15:28 ---
Here is a testcase which is better representive of the issue (compile with
-std=c99 -pedantic-errors):
#include stdbool.h
int
main (int argc, char **argv)
{
if ((bool)((1527719483 + 1477819644))) {
}
return 0;
}
bool t1 = true;
--
t.c: In function main:
t.c:6: warning: integer overflow in expression
t.c: At top level:
t.c:12: error: overflow in constant expression
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |c
Keywords||diagnostic, rejects-valid
Known to fail|4.0.3 |4.0.3 4.1.0
Known to work|4.1.0 3.4.0 |3.4.0
Summary|[4.0 regression] segv after |[4.0/4.1 regression]
|overflow detection |Overflow for true value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24599
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #7 from anglade at gmail dot com 2005-11-04 15:31 --- I've simplified to it's (almost) simplest expression the test case: module mtyp type t1 integer::a end type t1 end module mtyp module atest use mtyp type(t1)::ze contains subroutine test(ze_in ) use mtyp implicit none type(t1)::ze_in ze=ze_in end subroutine test end module atest I've try to backtrace the call up to the front-end. But I'm not able to do that since I really don't know the structure of gcc (and since ddd/gdb keeps busying me with stupid error message). I'd be glade to fix the bug if someone can introduce me a little bit more to the code. (any link for gcc beginners??) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug target/19340] Compilation SEGFAULTs with -O1 -fschedule-insns2 -fsched2-use-traces on an x86 architecture.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-04 15:32 --- Fails on the mainline for me. t.c: In function g: t.c:23: internal compiler error: in move_for_stack_reg, at reg-stack.c:1062 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.0 | Last reconfirmed|2005-01-08 23:59:22 |2005-11-04 15:32:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19340
[Bug fortran/18271] ICE with computed array declaration
--- Comment #5 from manfred99 at gmx dot ch 2005-11-04 15:32 --- 1) There is an easy way to circumvent the ICE: if you add an explicit type conversion for IMAX, such as in REAL:: AUX1(25000+INT(0.82*float(IMAX))) the ICE goes away and gfortran compiles it successfully and without warnings, even with -std=f95. 2) WRT invalid code: I checked the code with the Lahey Source Check, ifort, SUN f95 and g95: -- Lahey/Fujitsu Fortran 95 (lf95): no errors, no warnings -- Lahey Fortran 90 (lf90): error at INT expression Line 5, file SOURCE.F90 REAL:: AUX1(25000+INT(0.82*IMAX)) | FATAL -- Specification expression required. -- Intel ifort 8.1: no errors, no warnings with -warn all -stand f90 -- SUN Workshop f95 6.2: no errors, no warnings with -w4 -- g95: no errors, no warnings with -std=f95 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18271
[Bug middle-end/8081] ICE with variably sized types and nested functions
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-11-04 15:33 --- Still fails on the mainline: t.c: In function main: t.c:15: internal compiler error: in assign_stack_temp_for_type, at function.c:595 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.4.5 4.0.2 |3.4.5 4.0.2 4.1.0 Known to work|4.1.0 | Last reconfirmed|2005-05-04 02:30:45 |2005-11-04 15:33:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
[Bug tree-optimization/19703] [4.0 Regression] Poor optimisation of loop test, DOM causing unsigned to int and missing combine compares
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-04 15:36 --- Since this is only a missed optimization, closing as fixed for 4.1.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.3 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19703
[Bug tree-optimization/18576] [3.4/4.0 Regression] missing jump threading because of type changes
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-11-04 15:37 --- Since this is only a missed optimization (and this was my bug) closing as fixed for 4.1.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.3 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
[Bug fortran/18271] ICE with computed array declaration
--- Comment #6 from anlauf at gmx dot de 2005-11-04 15:56 --- (In reply to comment #2) This is invalid code, INT is not allowed in a specification expression. I'm not a language lawyer, but if I read it correctly, then INT is a standard intrinsic function and thus allowed in a restricted expression (F2003 draft standard, 7.1.6, R729, C710 (8)) Am I missing something? -- anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18271
[Bug middle-end/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #14 from ian at airs dot com 2005-11-04 16:09 --- gcc is free to copy non-volatile variables. It does this in many places and for many reasons, particularly in the new SSA optimizers in 4.0 and later. I don't know the details of where it decided to copy the register in this test case, but presumably it seemed profitable to some heuristic. I expect that it could happen if the usage is in a loop, or used on both branches of an if conditional, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug c++/21764] visibility attributes on namespace scope
--- Comment #5 from bkoz at gcc dot gnu dot org 2005-11-04 17:05 ---
In addition to the current ability to put visibility attributes on file and
class scope, the ability to put visibility attributes on namespace scope is
desired.
The syntax is straight forward extension of existing visibility attribute
options.
namespace test __attribute__ ((visibility(hidden)))
{
struct c1
{
static int s;
virtual void foo() { }
};
int c1::s;
}
Is an example.
What does this mean? For definitions within namespace scope, set the symbol
visibility to the nearest enclosing namespace attribute. Declarations are
unaffected.
Nested namespaces have the same semantics as nested classes. Ie, enclosing
scope. Therefore:
#define VIS_default __attribute__ ((visibility(default)))
#define VIS_hidden __attribute__ ((visibility(hidden)))
struct c1
{
static int s;
virtual void foo() { }
struct c2
{
static int s;
virtual void foo() { }
} VIS_default;
} VIS_hidden;
namespace test1 VIS_hidden
{
struct c1
{
static int s;
virtual void foo() { }
};
int c1::s;
namespace test2 VIS_default
{
struct c2
{
static int s;
virtual void foo() { }
};
int c2::s;
}
}
In the above, struct c2 and test1::test2::c2 both have default visibility,
whereas c1 and test1::c1 both have hidden visibility.
Interactions between file, namespace, and class scope are handled sanely. Ie,
the same deal, nearest enclosing scope.
ie:
#pragma GCC visibility push(hidden)
namespace test1 VIS_default
{
struct c1
{
static int s;
virtual void foo() { }
};
int c1::s;
struct c2
{
static int s;
virtual void foo() { }
} VIS_hidden;
int c2::s;
}
#pragma GCC visibility pop
In the above, c1 would be default, c2 would be hidden.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764
[Bug c++/24668] visibility attributes on namespaces
--- Comment #3 from bkoz at gcc dot gnu dot org 2005-11-04 17:06 --- Agh. Sorry, I had not realized that I'd filed this six months ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24668
[Bug fortran/20811] gfortran include problem (regression from g77)
--- Comment #4 from mesmith dot 15507218 at bloglines dot com 2005-11-04 17:22 --- Created an attachment (id=10145) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10145action=view) Source in gcc/fortran from FC4 4.0.1 with patches -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20811
[Bug fortran/20811] gfortran include problem (regression from g77)
--- Comment #5 from mesmith dot 15507218 at bloglines dot com 2005-11-04 17:24 --- Created an attachment (id=10146) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10146action=view) Source in gcc/libgfortran from FC4 gcc 4.0.1 with patches -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20811
[Bug fortran/20811] gfortran include problem (regression from g77)
--- Comment #6 from mesmith dot 15507218 at bloglines dot com 2005-11-04 17:30 --- The two attached files will change the behavior so that included files are processed as described in comment #2. I have not checked the results extensively. -- mesmith dot 15507218 at bloglines dot com changed: What|Removed |Added CC||mesmith dot 15507218 at ||bloglines dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20811
[Bug middle-end/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #15 from bergner at vnet dot ibm dot com 2005-11-04 17:38
---
For completeness, here is a minimal test case that shows the problem we are
having:
[EMAIL PROTECTED]:~/olaf/PR24644-4 cat bar.c
register struct paca_struct * local_paca asm(r13);
struct paca_struct { volatile long state; };
extern void foo(void);
int migration_thread(void)
{
local_paca-state = 1;
foo();
local_paca-state = 0;
return 0;
}
[EMAIL PROTECTED]:~/olaf/PR24644-4 ~/gcc/dataflow-base/bin/gcc -m64 -O1 -S
bar.c
The code we get looks like:
.migration_thread:
mflr 0
std 29,-24(1)
std 0,16(1)
stdu 1,-144(1)
mr 29,13
li 0,1
std 0,0(13)
bl .foo
nop
li 0,0
std 0,0(29)
li 3,0
addi 1,1,144
ld 0,16(1)
mtlr 0
ld 29,-24(1)
blr
This looks like gcc thinks r13 will be trashed by the call to foo() so it
copies it to a non volatile register for use after the call. Strange that this
didn't happen before the patch found by Olaf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug libstdc++/21072] base allocator change shared object issues
--- Comment #6 from bkoz at gcc dot gnu dot org 2005-11-04 17:41 --- In general, we make no claims as to ABI compliance wrt development/trunk versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
[Bug fortran/18496] Build fails with libgmp.so.6 not found error
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-04 17:55 --- This was never confirmed with this exact error, and I've done quite some testing/debuging and did not experience that particular bug. I think this bug was superseded by PR21547, which I am currently fixing. Closing this one as WORKSFORME. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18496
[Bug c++/24667] [4.0/4.1 Regression] -Wcast-qual fails to reject offending cast for a old style cast
--- Comment #3 from fang at csl dot cornell dot edu 2005-11-04 17:56 --- Am I correct in expecting that const_cast... should pass -Wcast-qual without warning? That's the way I use it (in the few and rare cases that demand it) and it's met my expectations thus far. I'm kind of surprised I haven't tripped this bug myself, but that's because I stopped using C-style casts long ago, enforced by -Wold-style-cast -Werror. Adding -Wold-style-cast does trip a warning about old casts with the posted code, but nothing further about discarding qualifiers (gcc4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24667
[Bug middle-end/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-04 18:00 --- (In reply to comment #15) This looks like gcc thinks r13 will be trashed by the call to foo() so it copies it to a non volatile register for use after the call. Strange that this didn't happen before the patch found by Olaf. Actually it is the opposite way. GCC thinks that r13 will not trash (clobber) it, so it copies it. I wonder why this happens as I think it should be marked as call clobber. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug middle-end/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-04 18:06 --- Variable: local_paca, UID 1270, struct paca_struct *, is global, call clobbered, default def: local_paca_1 But we get: # TMT.6_8 = V_MAY_DEF TMT.6_7; # VUSE local_paca_1; foo (); I don't understand why because to me r13 should be able to change in foo so we should get V_MAY_DEF there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug tree-optimization/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-11-04 18:07 --- That testcase shows that we have a big problem, as local_paca (aka r13) should be marked as call clobbered. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Component|middle-end |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug tree-optimization/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-04 18:21 --- The problem is that ipa-static is looking at the variable because the front-end marked it as a static variable. Daniel Berlin has sugggested a fix, and I will test it with the reduced test case and then if you could test it with the full kernel that would be nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug tree-optimization/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #20 from pinskia at gcc dot gnu dot org 2005-11-04 18:33 --- Created an attachment (id=10147) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10147action=view) Patch to try This patch should fix the issue in the reduced testcase but I don't know if it fixes it fully, Can one of you two test it with the kernel? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug libstdc++/22203] std::numeric_limitsint::traps is wrong on PPC
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-04 18:35:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22203
[Bug tree-optimization/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #21 from olh at suse dot de 2005-11-04 19:15 --- yes, this patch helps. tested with r106499. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug ada/22533] [4.1 regression] ICE in get_base_var
--- Comment #23 from laurent at guerby dot net 2005-11-04 19:29 --- Add mips and mips64, for reference, workaround patch from Andreas Schwab here: http://gcc.gnu.org/ml/gcc/2005-11/msg00239.html Index: ipa-utils.c === --- ipa-utils.c (revision 106486) +++ ipa-utils.c (working copy) @@ -217,6 +217,7 @@ get_base_var (tree t) while (!SSA_VAR_P (t) (!CONSTANT_CLASS_P (t)) + TREE_CODE (t) != CONSTRUCTOR TREE_CODE (t) != LABEL_DECL TREE_CODE (t) != FUNCTION_DECL TREE_CODE (t) != CONST_DECL) -- laurent at guerby dot net changed: What|Removed |Added GCC target triplet|powerpc-*-*,s390-*-*|powerpc-*-*,s390-*-*, mips- ||*-*, mips64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug libfortran/16339] Unformatted i/o on large arrays inefficient
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-04 19:50 --- With array size=2000, timings are: g77: 2.30 s gfortran-4.0 (without commited patch): 17.0 gfortran-mainline: 2.66 s intel: 3.15 s I think we can close this PR. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |RESOLVED Known to fail||4.0.2 Known to work||4.1.0 Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16339
[Bug tree-optimization/24627] [4.1 Regression] xntp miscompiled
--- Comment #17 from dnovillo at gcc dot gnu dot org 2005-11-04 19:56 --- Subject: Bug 24627 Author: dnovillo Date: Fri Nov 4 19:56:28 2005 New Revision: 106502 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106502 Log: PR 24627 * tree-ssa-dce.c (pass_dce, pass_dce_loop, pass_cd_dce): Use TODO_update_ssa instead of TODO_update_ssa_no_phi. testsuite/ PR 24627 * gcc.dg/tree-ssa/pr24627.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr24627.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dce.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
[Bug tree-optimization/24627] [4.1 Regression] xntp miscompiled
--- Comment #18 from dnovillo at gcc dot gnu dot org 2005-11-04 19:57 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00239.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
[Bug tree-optimization/21883] [4.1 Regression] jump threading causing excessive code duplication
--- Comment #8 from law at redhat dot com 2005-11-04 20:10 --- Subject: Re: [4.1 Regression] jump threading causing excessive code duplication On Mon, 2005-10-31 at 18:56 -0700, Jeffrey A Law wrote: On Mon, 2005-10-31 at 03:43 +, mmitchel at gcc dot gnu dot org wrote: --- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 03:43 --- Downgraded to P2. Important, but not a showstopper. We really should have some kind of throttle, even if it's a bit simplistic. We could easily put in a trivial throttle.If there's more than N statements + phis, then the block is considered not threadable. Choose N and it'll take about 5 minutes of work (and 3 hours to test :-) I'll throw out 50 as a very very very conservative number. If we're OK with that number, then let's do it. We might be better around 10, but 50 ought to catch the pathological cases without impacting much of anything. Here's what I actually checked in. This should be enough to allow us to delay final resolution of this PR till 4.2 (probably using Steven's prototype, which I like better). Bootstrapped and regression tested on i686-pc-linux-gnu. --- Comment #9 from law at redhat dot com 2005-11-04 20:10 --- Created an attachment (id=10148) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10148action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21883
[Bug tree-optimization/21883] [4.1 Regression] jump threading causing excessive code duplication
--- Comment #10 from law at redhat dot com 2005-11-04 20:11 --- Band-aid applied for 4.1; Steven's prototype patch may be a better solution as it only simulates those statements which affect the conditional and doesn't count those statements (they're likely going to disappear in addition to the conditional) Evaluation of Steven's patch should occur after 4.1 is branched. -- law at redhat dot com changed: What|Removed |Added Target Milestone|4.1.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21883
[Bug tree-optimization/24665] [4.0/4.1 Regression] internal compiler error: get_indirect_ref_operands
--- Comment #2 from janis at gcc dot gnu dot org 2005-11-04 20:19 --- A regression hunt identified the following patch: http://gcc.gnu.org/viewcvs?view=revrev=89280 r89280 | rth | 2004-10-19 17:24:46 + (Tue, 19 Oct 2004) | 4 lines PR middle-end/17885 * tree.c (recompute_tree_invarant_for_addr_expr): Always poll address of INDIRECT_REF. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24665
[Bug c++/24667] [4.0/4.1 Regression] -Wcast-qual fails to reject offending cast for a old style cast
--- Comment #4 from janis at gcc dot gnu dot org 2005-11-04 21:18 --- A regression test identified the following patch to change handling of C-style casts for PR c++/14035: http://gcc.gnu.org/viewcvs?view=revrev=89300 r89300 | mmitchel | 2004-10-19 23:24:20 + (Tue, 19 Oct 2004) | 35 lines -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24667
[Bug target/23424] cris.md rtl canonicalization bug
--- Comment #5 from hp at gcc dot gnu dot org 2005-11-04 21:20 --- Subject: Bug 23424 Author: hp Date: Fri Nov 4 21:20:24 2005 New Revision: 106506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106506 Log: PR target/23424 * config/cris/predicates.md (cris_bdap_sign_extend_operand): Disable. Modified: trunk/gcc/ChangeLog trunk/gcc/config/cris/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23424
[Bug c/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #22 from pinskia at gcc dot gnu dot org 2005-11-04 21:21 --- Hmm, my patch is not fully correct but the C++ front-end gets this correct. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug target/23424] cris.md rtl canonicalization bug
--- Comment #6 from hp at gcc dot gnu dot org 2005-11-04 21:24 --- Subject: Bug 23424 Author: hp Date: Fri Nov 4 21:24:20 2005 New Revision: 106507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106507 Log: PR target/23424 * gcc.dg/torture/pr23424-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr23424-1.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23424
[Bug fortran/24636] gfortran: STOP without stop-code too noisy, regression w.r.t. g77
--- Comment #3 from kargl at gcc dot gnu dot org 2005-11-04 22:18 --- Subject: Bug 24636 Author: kargl Date: Fri Nov 4 22:18:22 2005 New Revision: 106509 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106509 Log: PR fortran/24636 * match.c (gfc_match_stopcode): Set stop_code = -1. * runtime/stop.c (stop_numeric): Use stop_code = -1. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/stop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24636
[Bug fortran/24679] New: internal compiler error: Segmentation fault
The following on screen description happened: jacin04 PHITS/src gcc -v -save-temps -O4 -c mars00.f Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.0.1/configure --prefix=/usr/common/usg/gcc/4.0.1 --with-mpfr-dir=/usr/common/usg/gmp/src/gmp-4.1.4/mpfr/ --with-mpfr=/usr/common/usg/gmp/4.1.4/lib --with-gmp=/usr/common/usg/gmp/4.1.4 --with-gmp_dir=/usr/common/usg/gmp/src/gmp-4.1.4 --disable-multilib Thread model: posix gcc version 4.0.1 /usr/common/usg/gcc/4.0.1/libexec/gcc/x86_64-unknown-linux-gnu/4.0.1/f951 mars00.f -ffixed-form -quiet -dumpbase mars00.f -mtune=k8 -auxbase mars00 -O4 -version -o mars00.s GNU F95 version 4.0.1 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.0.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=65536 In file mars00.f:838 if (iii-2) 570,510,540 1 Warning: Obsolete: arithmetic IF statement at (1) mars00.f: In function 'fidas': mars00.f:927: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The subroutine that generated the error is as follows: subroutine fidas (d,ld,lld,ll2,j3,n5,n6) external fidcom c c *** data array modification c### c caudit trail information c c date the module was last permanently updated: 93/09/20 c time the module was last permanently updated: 07:31:12 c programmer name: l.m.petrie c module name: s7fidas c current archiving level number: 00020 c current number of permanent updates: 00020 c date of last access by librarian: 93/09/20 c dataset name: x4s.scale4.master c c### dimension in(37),k(37),v(37),ld(*),vmt(18),w(12), * d(*),lld(*) common /fidasc/ iprtrg dimension prt(3) equivalence (bb,lbb) dimension vs(74) equivalence (v(1),vs(1)) double precision v,vv,vu,del,delt,dif character*1 k,lbb,ldl,ls,lr1,li,lt,lss,lf,la,lap,lpl,lmi,lz,lv,lu character*1 bb,lq,lm,ln,le,lli,lki,lo,lc,lsls,ldb,lhl,lb character*4 prt,vmt dimension dv(2),vi(2) equivalence (dv(1),delt),(vi(1),vv) data ldl,ls,lr1,li,lt,lss/'$','*','r','i','t','s'/ data lf,la,lap,lpl,lmi/'f','a','','+','-'/ data lz,lv,lu,bb/'z','v','u',' '/ data lq,lm,ln/'q','m','n'/,le/'e'/,lli/'l'/ data lki/'k'/ data lo,lc,prt(1),prt(2),prt(3)/'o','c','off ','prt ','on '/ data lsls /'/'/ data ldb/'#'/, lhl/'h'/ kdbl = 0 ldbl = 0 j = 0 j3 = 0 iii= 0 ivmt = 0 ncount = 0 100 call ffread(in,k,v,nf,n5,n6,iprtrg) do 120 i=1,nf if (k(i).ne.lpl.and.k(i).ne.lap.and.k(i).ne.lmi) go to 120 c *** exponentiation (,+,-) l = in(i) if (l.eq.0) go to 120 e = 10.0**l if (k(i).eq.lmi) go to 110 v(i) = v(i)*e go to 120 110v(i) = v(i)/e 120continue i = 1 130 continue if (iii.eq.0) go to 140 if (iii-2) 570,510,540 140iii= 0 if (k(i).eq.lbb) go to 370 if (k(i).eq.lhl) go to 370 if (k(i).eq.ldl) go to 200 if (k(i).eq.ls) go to 190 if (k(i).eq.ldb) go to 180 if (k(i).eq.lr1) go to 400 if (k(i).eq.li) go to 560 if (k(i).eq.lt) go to 150 if (k(i).eq.lss) go to 340 if (k(i).eq.lf) go to 290 if (k(i).eq.la) go to 330 if (k(i).eq.lz) go to 390 if (k(i).eq.le) go to 320 if (k(i).eq.lq) go to 420 if (k(i).eq.lm.or.k(i).eq.ln) go to 460 if (k(i).eq.lu) go to 160 if (k(i).eq.lv) go to 170 if (k(i).eq.lli) go to 500 if (k(i).eq.lki) go to 530 if (k(i).eq.lo) go to 350 if (k(i).eq.lc) go to 360 if (k(i).eq.lsls) go to 210 go to 370 c *** terminate (t) 150j2 = 0 itest = in(i) kdbl = ldbl if (j.eq.0) go to 250 go to 220 c *** variable format control (u,v) 160read(n5,10900)vmt 170ivmt = 1 go to 190 c*** begin new array (*,$,#) 180kdbl = ldbl cshr ldbl = 1 cshr clng cldbl = 0 clng
[Bug target/23775] [4.1 Regression] wrong code in argument passing
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-04 22:56 --- For the record, Jakub has apparently dropped this bug from his list to put this bug back into unassigned state. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
[Bug fortran/24679] internal compiler error: Segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-04 22:58 --- Fixed in 4.0.2 and above at least. Most likely a dup of bug 15966. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24679
