[Bug rtl-optimization/15068] ICE in elim_reg_cond
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-04-02 06:52 --- (In reply to comment #13) > Any patch for gcc-3.4.6? No, just use 4.1.0 or 4.0.2 instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15068
[Bug rtl-optimization/15068] ICE in elim_reg_cond
--- Comment #13 from shap at eros-os dot org 2006-04-02 06:48 --- Any patch for gcc-3.4.6? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15068
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2006-04-02 06:38 --- Oops! I didn't mean to reopen it again... -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2006-04-02 06:36 --- > Does not matter, file a new bug about the testcase failing since this is only > the testcase. Please stop being so stubborn. :-) Anyway, I now hold you responsible for making sure that something is done about the problem on the 4.1 branch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-04-02 06:27 --- Does not matter, file a new bug about the testcase failing since this is only the testcase. See the thread starting at: http://gcc.gnu.org/ml/fortran/2006-03/msg00487.html The orginal bug has been fixed and there is no reason not to open a new bug report to track the testcase failing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2006-04-02 06:21
---
> We already had this discussion and yes it is not portable but that has already
> been fixed.
Andrew, you should really double-check what you say...
[EMAIL PROTECTED]:~/svn/gcc-4_1-branch/gcc/testsuite/gfortran.dg> svn update
transfer_array_intrinsic_1.f90
At revision 112621.
[EMAIL PROTECTED]:~/svn/gcc-4_1-branch/gcc/testsuite/gfortran.dg> cat
transfer_array_intrinsic_1.f90
! { dg-do run }
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug c++/26922] Compile/link failure with -frepo and g++ 4.1
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-02 06:17 --- http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01747.html That points out what caused it and how it was fixed and it was not a GCC bug after all so closing 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=26922
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-04-02 06:13 --- We already had this discussion and yes it is not portable but that has already been fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug fortran/26976] Array assignment of elemental intrinsic functions does not check conformability
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-02 06:04:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26976
[Bug inline-asm/26975] reload_cse_simplify_operands during extended asm with -O2
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-02 06:03 --- "=ebp" (ret) : "ecx" (multiplier) You are doing that all wrong. those are constaints and not registers names like you have. -- 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=26975
[Bug middle-end/26977] [4.2 regression] ICE in emit_move_insn
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26977
[Bug c++/26984] [4.2 Regression] link error with &(typeid(int)) in anonymous namespace
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nathan at gcc dot gnu dot ||org Keywords||link-failure Summary|link error with |[4.2 Regression] link error |&(typeid(int)) in anonymous |with &(typeid(int)) in |namespace |anonymous namespace Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26984
[Bug c++/26978] Friend function should not ne found.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-02 05:49 --- Fixed in 4.1.0 and above (I know this is a dup of another bug but I cannot find it right now). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26978
[Bug middle-end/25776] [4.2 Regression] ICE in cgraph after error at -O1 and above
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-02 05:36 --- *** Bug 26979 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rjpeters at klab dot caltech ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
[Bug c++/26979] ICE-on-invalid "verify_cgraph_node failed"
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-02 05:36 --- *** This bug has been marked as a duplicate of 25776 *** -- 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=26979
[Bug c++/26984] link error with &(typeid(int)) in anonymous namespace
--- Comment #1 from rjpeters at klab dot caltech dot edu 2006-04-02 05:29 --- Created an attachment (id=11183) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11183&action=view) test case exposing the link error with -fpic with 4.2/20060401 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26984
[Bug c++/26984] New: link error with &(typeid(int)) in anonymous namespace
Using g++ from 4.2.0 daily snapshot 20060401:
$ ~/local/gcc-4.2-20060401/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /lab/rjpeters/build/gcc-4.2-20060401/configure
--enable-languages=c,c++ --prefix=/lab/rjpeters/local/gcc-4.2-20060401
--enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 4.2.0 20060401 (experimental)
I get a linker error when I try to compile and link the following into a shared
library. The link error only happens when I use -fpic, and it happens only when
I take the address of typeid(int) inside an anonymous namespace; no linker
error if I take the address in the global namespace or in a named namespace.
$ cat test.C
#include
void g(const std::type_info&);
namespace { // <--- change to 'namespace X' and the error disappears
const std::type_info* t = &(typeid(int));
}
template
struct C
{
virtual void foo() const {
g(typeid(int));
}
};
C c;
$ ~/local/gcc-4.2-20060401/bin/g++ -c test.C -fpic -o test.o
$ ~/local/gcc-4.2-20060401/bin/g++ -shared test.o -o test.so
/usr/bin/ld: test.o(.gnu.linkonce.t._ZNK1CIvE3fooEv+0x14): unresolvable
relocation against symbol `typeinfo for int@@CXXABI_1.3'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
Not entirely sure which part of the toolchain this relates to, but I don't see
the error with g++ 3.4.4 or 4.1.0 so I'm guessing there's a chance it's
compiler-related.
If I compile test.C->test.o both with 3.4.4 and 4.2.0 (20060401), then diff the
outputs of 'nm test.o | c++filt', I get this:
$ diff nm-3.4.4 nm-4.2
3c3
< 003a t global constructors keyed to
_ZN35_GLOBAL__N_test.C_DFF67DD7_A20029871tE
---
> 003c t global constructors keyed to
> _ZN35_GLOBAL__N_test.C__CD2145311tE
14a15,16
> T __i686.get_pc_thunk.bx
> T __i686.get_pc_thunk.cx
Thanks,
Rob
--
Summary: link error with &(typeid(int)) in anonymous namespace
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rjpeters at klab dot caltech dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26984
[Bug middle-end/26977] [4.2 regression] ICE in emit_move_insn
--- Comment #1 from roger at eyesopen dot com 2006-04-02 03:07 --- Damn. Unfortunately, although I have four different IA-64 boxes, one none of them can I test Ada. Is it possible to attach the traceback of the failure to the bugzilla PR? Clearly the fact that y is NULL_RTX at the assertion is problematic, but I can't tell where the call to emit_move_insn is coming from. The new calls to emit_move_insn in the PR17959 fix both pass the result from simplify_gen_subreg which should never return NULL, i.e. the problematic call is probably not directly related to the change. I'll start an ia64-unknown-linux-gnu bootstrap here anyway, just to see if anything strange is happening in the testsuite. Sorry for the inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26977
[Bug ada/26983] New: Missing label in a nested function
The following program:
void
Object (void)
{
void * jmpbuf_1[6];
void P (void)
{
{
void * jmpbuf_3[6];
if (__builtin_setjmp (&jmpbuf_3)) goto nonlocal_exit_2; else (void) 0;;
__builtin_longjmp (&jmpbuf_1, 1);
nonlocal_exit_2:;;
}
}
{
if (__builtin_setjmp (&jmpbuf_1)) goto nonlocal_exit_0; else (void) 0;;
P ();
nonlocal_exit_0:;;
}
}
int
main(void)
{
Object ();
}
gives me:
../gcc-lin/prev-gcc/xgcc -B../gcc-lin/prev-gcc
mjmp2.c/tmp/cc06O64A.o(.text+0x5a): In function `P.1525':
: undefined reference to `.L8'
collect2: ld returned 1 exit status
Using gcc-4.2-20060401. The problem also shows up with gcc-4.0.2 and
gcc-4.1.0 on amd64. Also the problem shows in the output of a
cross-compiler targetting powerpc-apple-darwin7. The original problem
was discovered in GNU Pascal on powerpc-apple-darwin7 and the program
above tries to reproduce Pascal problem. The program compiles using
gcc-3.4.4.
--
Summary: Missing label in a nested function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hebisch at math dot uni dot wroc dot pl
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug testsuite/26982] New: g++.old-deja/g++.other/init19.C execution test fails
FAIL: g++.old-deja/g++.other/init19.C execution test is present on platforms including hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11, ia64-hp-hpux11.23. It looks like this test depends on __cxa_atexit being used, and so should be conditioned on an appropriate effective-target for __cxa_atexit. -- Summary: g++.old-deja/g++.other/init19.C execution test fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26982
[Bug testsuite/26981] New: g++.old-deja/g++.other/init18.C fails
FAIL: g++.old-deja/g++.other/init18.C (test for excess errors) is present on platforms including hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11, ia64-hp-hpux11.23. These platforms lack _Exit. The test should conditionally use _exit where _Exit is unavailable. -- Summary: g++.old-deja/g++.other/init18.C fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26981
[Bug target/26980] New: g++.old-deja/g++.other/init5.C execution test fails
The XFAIL has been removed from g++.old-deja/g++.other/init5.C, but we still have FAIL: g++.old-deja/g++.other/init5.C execution test on platforms including hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 and ia64-hp-hpux11.23. -- Summary: g++.old-deja/g++.other/init5.C execution test fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26980
[Bug c++/26979] ICE-on-invalid "verify_cgraph_node failed"
--- Comment #1 from rjpeters at klab dot caltech dot edu 2006-04-02 00:58 --- Created an attachment (id=11182) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11182&action=view) test case exposing the bug at -O1 with 4.2.0-20060401 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26979
[Bug c++/26979] New: ICE-on-invalid "verify_cgraph_node failed"
Using the 20060401 g++ 4.2 snapshot, built with checking enabled:
$ ~/local/gcc-4.2-20060401/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /lab/rjpeters/build/gcc-4.2-20060401/configure
--enable-languages=c,c++ --prefix=/lab/rjpeters/local/gcc-4.2-20060401
--enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 4.2.0 20060401 (experimental)
I get an ICE with the following code; the ICE is apparently triggered by the
invalid 'xxx' bogus code, but as I was whittling down the test case I found
that any number of pieces of invalid code would also trigger the bug. The ICE
appears at -O1 or greater, but not at -O0.
No ICE using 4.1.0 or 3.4.4; both just correctly report the error in the test
code.
$ cat test.ii
struct A {
A();
};
void f();
struct B {
virtual ~B() {
A a[1];
f();
}
};
struct C : B {
};
C c;
xxx // <--- this triggers the ICE
$ ~/local/gcc-4.2-20060401/bin/g++ -c test.ii -o /dev/null -O1
test.ii:18: error: expected constructor, destructor, or type conversion at end
of input
test.ii:19: error: inlined_to pointer is set but no predecesors found
virtual C::~C()/21: (inline copy in void __tcf_0(void*)/8)
availability:available(6) 35 insns (73 after inlining) tree externally_visible
finalized inlinable
called by:
calls: B::~B()/1 (inlined) void operator delete(void*)/18
test.ii:19: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ ~/local/gcc-4.2-20060401/bin/g++ -c test.ii -o /dev/null -O1
test.ii:18: error: expected constructor, destructor, or type conversion at end
of input
test.ii:19: error: inlined_to pointer is set but no predecesors found
virtual C::~C()/21: (inline copy in void __tcf_0(void*)/8)
availability:available(6) 35 insns (73 after inlining) tree externally_visible
finalized inlinable
called by:
calls: B::~B()/1 (inlined) void operator delete(void*)/18
test.ii:19: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Thanks for everyone's efforts on the compiler -- it's a great tool and I enjoy
using it.
Cheers,
Rob
--
Summary: ICE-on-invalid "verify_cgraph_node failed"
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rjpeters at klab dot caltech dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26979
[Bug pch/13675] #including a precompiled header more than once in the same unit fails
--- Comment #13 from rupert dot swarbrick at lineone dot net 2006-04-01 23:19 --- (In reply to comment #11) > The same problem stays unresolved in GCC-3.4.4 As far as I can tell, the problem is STILL unresolved with g++ 4.1, but there is a workaround for users that I post here for information. Create a "proxy" header. e.g. if there is some PCH enabled "gtk_includes.hh", create "gtk_includes_proxy.hh", which is not precompiled and just has the contents: #ifndef GTK_INCLUDES_PROXY_HEADER #define GTK_INCLUDES_PROXY_HEADER #include "gtk_includes.hh" #endif This will ensure that the actual precompiled header is only included once per module. -- rupert dot swarbrick at lineone dot net changed: What|Removed |Added CC||rupert dot swarbrick at ||lineone dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
[Bug c++/26922] Compile/link failure with -frepo and g++ 4.1
--- Comment #6 from rankincj at yahoo dot com 2006-04-01 23:00 --- Subject: Re: Compile/link failure with -frepo and g++ 4.1 --- pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > Well if you read the instructions on how to report a bug, a tar file is not > really liked :). And yet you allow tar files anyway. Regardless, according to the RedHat bugzilla, this issue has been traced(?) to a change in the binutils linker. (Although I don't know if the linker is at fault, or whether the collect2 helper application is missing a change.) Cheers, Chris ___ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26922
[Bug c++/26978] New: Friend function should not ne found.
The following piece of code is compiled successfully ( g++ -ansi -pedantic
-Wall -c p6.C):
class Test {
friend void f() {};
};
void g(const Test &t) {
f();
}
I think it shouldn't compile because there is no explicitly declared f() in the
enclosing scope.
--
Summary: Friend function should not ne found.
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eremefka at op dot pl
GCC host triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26978
[Bug libfortran/24685] real(16) formatted input is broken for huge values
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-04-01 21:35 --- Subject: Bug 24685 Author: ebotcazou Date: Sat Apr 1 21:35:34 2006 New Revision: 112612 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112612 Log: PR libfortran/24685 * gfortran.dg/large_real_kind_form_io_2.f90: XFAIL on SPARC/Solaris. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/large_real_kind_form_io_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug libfortran/24685] real(16) formatted input is broken for huge values
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-04-01 21:34 --- Subject: Bug 24685 Author: ebotcazou Date: Sat Apr 1 21:34:27 2006 New Revision: 112611 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112611 Log: PR libfortran/24685 * gfortran.dg/large_real_kind_form_io_2.f90: XFAIL on SPARC/Solaris. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/large_real_kind_form_io_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-04-01 21:26 --- (In reply to comment #13) > It seems to me that the whole #else branch of the #if __APPLE__ statement > should be removed, together with the #if statement itself. Right. I tested a bit with sqrt() SSE2 instructions, and it seems that the code enclosed in the __APPLE__ case does what is needed. I just commited this. Closing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #16 from kargl at gcc dot gnu dot org 2006-04-01 20:48 ---
(In reply to comment #15)
> > No, it isn't portable to big endian. How are you executing this
> > test.
>
> gmake -k check-fortran. :-)
>
> > I added a { target i?86-*-* x86_64-*-* } to the dg-do clause.
>
> Not on the 4.1 branch.
Whoops. I thought I had committed to both branches.
> And why? Is there anything specific to x86 in the test?
Because there isn't a { target-little-endian } dg directive.
Additionally, I knew pault was working on a general fix for
problem. I was just trying to permit big-endian system
ignore the testcase
Note, pault has submitted a new patch earlier today. I hope
to review it shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug libfortran/26735] [4.1 only] -fconvert=swap and implied open
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-04-01 20:09 --- Also fixed on 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26735
[Bug libfortran/26735] [4.1 only] -fconvert=swap and implied open
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-04-01 20:08 --- Subject: Bug 26735 Author: tkoenig Date: Sat Apr 1 20:08:39 2006 New Revision: 112609 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112609 Log: 2006-04-01 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/26735 Backport from mainline * io/transfer.c (data_transfer_init): Set u_flags.convert on an unopened unit if specified by environment variable (via get_unformatted_convert) or by compile-time option. 2006-04-01 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/26735 Backport from mainline * gfortran.dg/convert_implied_open.f90: New test case. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/convert_implied_open.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26735
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-04-01 20:05
---
> No, it isn't portable to big endian. How are you executing this
> test.
gmake -k check-fortran. :-)
> I added a { target i?86-*-* x86_64-*-* } to the dg-do clause.
Not on the 4.1 branch. And why? Is there anything specific to x86 in the
test?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug fortran/25270] gfortran.dg/array-1.f90 (and a lot of others) fails with a type mismatch
--- Comment #5 from sayle at gcc dot gnu dot org 2006-04-01 19:19 --- Subject: Bug 25270 Author: sayle Date: Sat Apr 1 19:19:22 2006 New Revision: 112608 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112608 Log: PR fortran/25270 * trans-array.c (gfc_trans_allocate_array_storage): In array index calculations use gfc_index_zero_node and gfc_index_one_node instead of integer_zero_node and integer_one_node respectively. (gfc_conv_array_transpose): Likewise. (gfc_conv_ss_startstride): Likewise. (gfc_trans_dummy_array_bias): Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25270
[Bug middle-end/26977] New: [4.2 regression] ICE in emit_move_insn
The patch for PR17959 breaks Ada on ia64. Starting program: /tmp/cvs/gcc-test-r112543/Build/gcc/gnat1 -quiet -dumpbase g-altcon.adb -O2 -W -Wall -fPIC -g -gnatpg -gnatO g-altcon.o g-altcon.adb Program received signal SIGSEGV, Segmentation fault. 0x408d8da1 in emit_move_insn (x=0x20783560, y=0x0) at ../../gcc/expr.c:3229 3229 gcc_assert (mode != BLKmode -- Summary: [4.2 regression] ICE in emit_move_insn Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: ia64-*-* OtherBugsDependingO 17959 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26977
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #14 from kargl at gcc dot gnu dot org 2006-04-01 17:24 ---
(In reply to comment #13)
> Is transfer_array_intrinsic_1.f90 portable to big-endian? It fails on SPARC.
>
No, it isn't portable to big endian. How are you executing this
test. I added a { target i?86-*-* x86_64-*-* } to the dg-do clause.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #13 from schnetter at aei dot mpg dot de 2006-04-01 17:21 --- Regarding a generic mechanism for both ppc and i386 on Darwin: I looked at the header files in /usr/include on my Darwin 8.5.2 system, which contain the architecture specific files for both ppc and i386. While the ppc headers have a file fp_regs.h, there is no such file for i386. I don't think that Darwin supports a generic architecture-independent mechanism for FPU control. The gfortran library contains explicit machine instructions in its file fpu-387.h, which seem to be used on all i386 architectures that don't have a glibc. How many architectures are that? It seems to me as if this file is broken for SSE (after this patch, it remains broken on non-Darwin architectures): The variable cw_sse has first its low 16 bits set to zero. Then some bits are set to one. Then the same bits are set to one depending on front-end flags. This is pointless. The code also uses explicit numbers to indicate the bits although perfectly nice named constants exist. It seems to me that the whole #else branch of the #if __APPLE__ statement should be removed, together with the #if statement itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-04-01 17:10 --- Is transfer_array_intrinsic_1.f90 portable to big-endian? It fails on SPARC. Reduced testcase: integer(4) :: y(4) character(4) :: ch(4) y = (/(i + ishft (i + 1, 8) + ishft (i + 2, 16) & + ishft (i + 3, 24), i = 65, 80 , 4)/) ch = "wxyz" ch = transfer (y(2:4:2), ch) if (any (ch .ne. (/"EFGH","MNOP","wxyz","wxyz"/))) call abort () end Breakpoint 1, MAIN__ () at transfer_array_intrinsic_1.f90:8 8if (any (ch .ne. (/"EFGH","MNOP","wxyz","wxyz"/))) call abort () (gdb) p ch $13 = (( 72 'H', 71 'G', 70 'F', 69 'E') ( 80 'P', 79 'O', 78 'N', 77 'M') ( 119 'w', 120 'x', 121 'y', 122 'z') ( 119 'w', 120 'x', 121 'y', 122 'z') ) -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug target/26879] LibJava not compile under alpha
--- Comment #14 from zerocool at modemsoft dot it 2006-04-01 17:07 --- (In reply to comment #13) > As you can see from the backtrace, the problem is in "gcc/java/jcf-io.c" at > line number 394 where we make a call to scandir(). I'm not an alpha-linux > hacker, but I see that there's scandir64 and dirent64 and it could be that > our assumptions about scandir/dirent in this code are not correct on > alpha-linux. Yes i had realized him. But what test could I do? Some directive about it? > Unfortunately, this means that you'll have to wait for > someone more familiar with alpha-linux to resolve this bug or try to resolve > this problem yourself given the source code. I'm sorry that I cannot help > you any further. Ok,I will wait but I will look around in the meantime me to see whether to resolve the problem. Please, if I had some idea to suggest me, i'm always to your disposition. Thanks of the whole time that you have devoted me and excuse again me for the incapability.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug middle-end/26968] HDF5 1.7.52 test segfaults with 4.1.0, fine with 4.0.2 (regression)
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-01 15:42 --- Note that you definitely need -fno-strict-aliasing from looking at hdf5 the last time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26968
[Bug c++/5247] Memory eating infinite loop on default parameter in constructor which is reference to class
--- Comment #16 from bsdfan3 at users dot sourceforge dot net 2006-04-01 13:11 --- MSVC8 also manages a sensible error message on the testcase from this bug: C:\cygwin\home\Lucas>cl /c pr5247.cc Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. pr5247.cc pr5247.cc(2) : fatal error C1202: recursive type or function dependency context too complex C:\cygwin\home\Lucas> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5247
[Bug c++/5247] Memory eating infinite loop on default parameter in constructor which is reference to class
--- Comment #15 from bsdfan3 at users dot sourceforge dot net 2006-04-01 13:07 --- (In reply to comment #14) > GCC 3.4.4 on Cygwin actually breaks. The .ii file looks normal, however, it > seems to be segfaulting...I'll try the testcase with mainline shortly. > > $ gcc --version > gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > Mainline (20060401) breaks too...same (silent) segfault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5247
[Bug c++/26660] [4.2 Regression] PCH vs -save-temps, ICE while GCing
--- Comment #8 from bsdfan3 at users dot sourceforge dot net 2006-04-01 13:05 --- GCC 3.4.4 seems to compile the testcase fine though (sorry about the linker error, nobody specified -c on the build command line): [EMAIL PROTECTED] ~ $ gcc t1.cc -save-temps --param ggc-min-expand=0 --param ggc-min-heapsize=0 /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):: undefined r eference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status [EMAIL PROTECTED] ~ $ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26660
[Bug fortran/26976] Array assignment of elemental intrinsic functions does not check conformability
--- Comment #1 from pault at gcc dot gnu dot org 2006-04-01 13:03 --- Thanks for reporting this, Dominique. As it happens (fancy that!), I will be posting a patch in the next 24hours. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26976
[Bug c++/26660] [4.2 Regression] PCH vs -save-temps, ICE while GCing
--- Comment #7 from bsdfan3 at users dot sourceforge dot net 2006-04-01 13:00 --- Still fails on mainline: $ mainline-gcc t1.cc -save-temps --param ggc-min-expand=0 --param ggc-min-heap size=0 t1.cc:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] ~ $ mainline-gcc --version mainline-gcc (GCC) 4.2.0 20060401 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Could someone please change this bug from UNCONFIRMED? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26660
[Bug fortran/26976] New: Array assignment of elemental intrinsic functions does not check conformability
Programs such as real(4) :: pi, a(2), b(3) pi = acos(-1.0) b = pi a = cos(b) a = -pi b = cos(a) print *, b end does not report errors. It should give In file conform_1.f90:4 a = cos(b) 1 Error: Array assignment at (1) has different shape on dimension 1 (2/3) In file conform_1.f90:6 b = cos(a) 1 Error: Array assignment at (1) has different shape on dimension 1 (3/2) Dominique -- Summary: Array assignment of elemental intrinsic functions does not check conformability Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26976
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-04-01 10:07 --- (In reply to comment #11) > 4.1.x is broken for i686-darwin other ways so this is not to be fixed for > there. If 4.1.x is broken, how do you explain that g95 (based on 4.0.3 or 4.1.0) is working on i686-darwin? Anyway, reopening this PR for a nicer solution, maybe one that involves a generic darwin way to do this (generic for both ppc and i686)? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug inline-asm/26975] reload_cse_simplify_operands during extended asm with -O2
--- Comment #2 from konrad at egipt-medytacje dot pl 2006-04-01 10:02 --- Created an attachment (id=11181) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11181&action=view) The full source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26975
[Bug inline-asm/26975] reload_cse_simplify_operands during extended asm with -O2
--- Comment #1 from konrad at egipt-medytacje dot pl 2006-04-01 10:01 --- Created an attachment (id=11180) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11180&action=view) That's the function triggering the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26975
[Bug inline-asm/26975] New: reload_cse_simplify_operands during extended asm with -O2
gcc40 tcnumfl_warp2.c -Wall -O2 -pipe -g -finline -o tcnumfl_warp2
tcnumfl_warp2.c: In function 'main':
tcnumfl_warp2.c:156: error: unrecognizable insn:
(insn:HI 693 1382 694 91 tcnumfl_warp2.c:399 (parallel [
(set (mem:SI (plus:SI (reg/f:SI 6 bp)
(const_int -68 [0xffbc])) [38 carry+0 S4 A8])
(asm_operands:SI ("push %%ebp
mov $num+40024, %%esi
mov -20(%%esi), %%eax
mov -16(%%esi), %%ebx
dec %%eax
lea (%%esi, %%eax, 4), %%edi
xor %%ebp, %%ebp
1:
cmp %%edi, %%esi
jg 2f
mov (%%edi), %%eax
mul %%ecx
add %%ebp, %%eax
adc $0, %%edx
div %%ebx
mov %%edx, (%%edi)
mov %%eax, %%ebp
sub $4, %%edi
jmp 1b
2:
pop %%ebp
") ("=ebp") 0 [
(reg:SI 2 cx)
]
[
(asm_input:SI ("ecx"))
] ("tcnumfl_warp2.c") 399))
(clobber (reg:QI 19 dirflag))
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
(clobber (reg:QI 1 dx))
(clobber (reg:QI 5 di))
(clobber (reg:QI 4 si))
(clobber (reg:QI 3 bx))
]) -1 (nil)
(nil))
tcnumfl_warp2.c:156: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:391
--
Summary: reload_cse_simplify_operands during extended asm with -
O2
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: konrad at egipt-medytacje dot pl
GCC build triplet: i386-portbld-freebsd6.0
GCC host triplet: x86_32-FreeBSD6.0-STABLE
GCC target triplet: i386-portbld-freebsd6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26975
[Bug libstdc++/26970] -O3 -Wformat=2 complains about floats written to ostream
--- Comment #5 from pcarlini at suse dot de 2006-04-01 09:17 --- Yes, too bad #pragma GCC system_header doesn't help here. Can somebody remind me exactly why and whether it's fixable? -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
[Bug c++/26974] hidden declarations klobber STL
--- Comment #2 from igodard at pacbell dot net 2006-04-01 08:26 --- Created an attachment (id=11179) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11179&action=view) source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/26974] hidden declarations klobber STL
--- Comment #1 from igodard at pacbell dot net 2006-04-01 08:25 --- Created an attachment (id=11178) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11178&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/26974] New: hidden declarations klobber STL
The program:
#include
#include "absParse.hh"
int main( int argc, char *argv[] )
{
std::vector v;
v.resize(1);
return 0;
}
compiles but gets a segv in the resize() call on several different g++
versions. The problem seems to have something to do with declarations of
operator,() in absParse.hh hijacking a loop in the STL where operator,() is
used to do two iterator increments: "for( ; i < last; ++i, ++j ) { ... }"
A full save-temps is attached
Ivan
--
Summary: hidden declarations klobber STL
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
