asr.c:3444: internal compiler error: Segmentation fault: 11
=== asr (all) cc -O -pipe -funroll-loops -march=pentium3 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/IBsec/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/IBsec -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/asr/../../dev/asr/asr.c /usr/src/sys/modules/asr/../../dev/asr/asr.c: In function `ASR_queue_i': /usr/src/sys/modules/asr/../../dev/asr/asr.c:3444: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop in /usr/src/sys/modules/asr. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/IBsec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. root: uname -a FreeBSD ws3-plovdiv.digsys.bg 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Wed Mar 22 20:44:32 EET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IBsec i386 root: gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.4 [FreeBSD] 20050518 root: Best regards, Valentin ChernoZemsky __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Bug target/26765] ICE in in extract_insn with __thread and optimization
--- Comment #4 from raj dot khem at gmail dot com 2006-04-10 07:38 --- I am unable to compile glibc 2.3.6 with GCC 4.1 on all mips-linux architecture because of this ICE. -- raj dot khem at gmail dot com changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26765
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #17 from rguenther at suse dot de 2006-04-10 08:10 ---
Subject: Re: loop header should also be pulled
out of the inner loop too
On Mon, 9 Apr 2006, rakdver at gcc dot gnu dot org wrote:
(In reply to comment #14)
(In reply to comment #11)
I updated the patch for current mainline, but it still has issues for some
common uses of loops:
void foo(int *ie, int *je, double *x)
{
int i, j;
for (j=0; j*je; ++j)
for (i=0; i*ie; ++i)
x[i+j] = 0.0;
}
After loop header copying we have
if (*je 0)
for (j=0; j*je; ++j)
if (*ie 0)
for (i=0; i*ie; ++i)
x[i+j ] = 0.0;
note how in this form we see the condition *ie 0 not invariant wrt the
outer loop (because it does a memory load), but if we would run load-PRE
between loop header copying and guard hoisting we would get
actually, thinking about it again, it should suffice to teach
invariant_without_guard_p about invariant memory loads, and this should just
work.
It basically does, the only other problem is that we are not able to determine
that the outer loop is not infinite.
It that because we don't recognize the condition of the loop header?
Otherwise we know that *je 0 and the loop runs from 0 to *je (in fact,
I have loop determine the number of iterations of the loop to be *je). Of
course this is with load-PRE moving the load before the loop-header and
thus SCEV being presented with
D.xxx = *je;
if (D.xxx 0)
for (j=0; jD.xxx; ++j)
...
which it just handles fine. It looks like a chicken-and-egg problem ;)
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug bootstrap/27099] New: GCC 4.1.0 won't build under Solaris 9 - fails stage3 compare
I have configured gcc-4.1.0 with the following command: configure --enable-threads --enable-languages=c,c++ --enable-bootstrap --with-gnu-as --with-gnu-ld The system has GNU binutils 2.16 installed and when running gmake bootstrap it compiles all 3 stage but fails during the compare stage with: ... bgcc_s.so.1 ln -s libgcc_s.so.1 sparcv9/libgcc_s.so gmake[4]: Leaving directory `/tmp/gcc-4.1.0/host-sparc-sun-solaris2.9/stage3-gcc' echo timestamp stmp-multilib gmake[3]: Leaving directory `/tmp/gcc-4.1.0/host-sparc-sun-solaris2.9/stage3-gcc' gmake[2]: Leaving directory `/tmp/gcc-4.1.0' gmake compare gmake[2]: Entering directory `/tmp/gcc-4.1.0' gmake[3]: Entering directory `/tmp/gcc-4.1.0' gmake[3]: Leaving directory `/tmp/gcc-4.1.0' /bin/sh: stage3-gcc: does not exist gmake[2]: *** [compare] Error 1 gmake[2]: Leaving directory `/tmp/gcc-4.1.0' gmake[1]: *** [stage3-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-4.1.0' gmake: *** [bootstrap] Error 2 -- Summary: GCC 4.1.0 won't build under Solaris 9 - fails stage3 compare Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andy at trojanfoe dot servebeer dot com GCC build triplet: solaris2.9 GCC host triplet: sparc GCC target triplet: sun http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
[Bug bootstrap/27099] stage3 compare failure
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-04-10 08:50 --- I have configured gcc-4.1.0 with the following command: configure --enable-threads --enable-languages=c,c++ --enable-bootstrap --with-gnu-as --with-gnu-ld Do not use --enable-bootstrap, it has not been tested with 4.1; just do as usual: configure --enable-languages=c,c++ --with-gnu-as --with-gnu-ld gmake bootstrap -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|GCC 4.1.0 won't build under |stage3 compare failure |Solaris 9 - fails stage3| |compare | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
[Bug middle-end/27095] [4.1/4.2 Regression] O2 produces duplicate code
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-10 09:00 --- We go via expand_builtin_memset which expands strlen at len_rtx = expand_normal (len); but then, expand via setmem fails, so we bail out else if (!set_storage_via_setmem(dest_mem, len_rtx, val_rtx, dest_align)) return 0; and end up doing regular return expand_call (exp, target, ignore); which then expands strlen again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #12 from sebastian dot pop at cri dot ensmp dot fr 2006-04-10 09:14 --- Created an attachment (id=11235) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11235action=view) proposed fix This patch fixes the problem, but probably it is a more general optimization fix than the one described in the PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-10 10:24 --- Subject: Re: loop header should also be pulled out of the inner loop too actually, thinking about it again, it should suffice to teach invariant_without_guard_p about invariant memory loads, and this should just work. It basically does, the only other problem is that we are not able to determine that the outer loop is not infinite. It that because we don't recognize the condition of the loop header? the problem is that we use # of iterations analysis, and it tries to fully instantiate the scalar evolutions, which is impossible for *je. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug c++/27094] [4.0/4.1/4.2 Regression] tree check: expected tree_list, have omp_return in build_call
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-10 11:34
---
Confirmed. Reduced testcase
(compile with g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0):
=
struct A
{
~A();
};
struct B : A
{
B();
};
templateint struct C
{
C(const B = B());
};
C0 c;
=
The regression appeared in GCC 4.0.2.
On mainline the error message reads:
PR27094.cc: In constructor 'Canonymous ::C(const B) [with int anonymous
= 0]':
PR27094.cc:16: internal compiler error: tree check: expected tree_list, have
omp_return in build_call, at cp/call.c:329
Please submit a full bug report, [etc.]
On the 4.0 and 4.1 branch we have:
PR27094.cc: In constructor 'Canonymous ::C(const B) [with int anonymous
= 0]':
PR27094.cc:16: internal compiler error: tree check: expected tree_list, have
dl_expr in build_call, at cp/call.c:330
Please submit a full bug report, [etc.]
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||monitored
Known to fail||4.0.2 4.1.0 4.1.1 4.2.0
Known to work||3.4.6 4.0.0 4.0.1
Last reconfirmed|-00-00 00:00:00 |2006-04-10 11:34:47
date||
Summary|[4.2 Regression] tree check:|[4.0/4.1/4.2 Regression]
|expected tree_list, have|tree check: expected
|omp_return in build_call|tree_list, have omp_return
||in build_call
Target Milestone|4.2.0 |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error make[1]: *** [getpwd.o] Error 1
--- Comment #2 from sagar dot indalkar at ge dot com 2006-04-10 11:45 --- Created an attachment (id=11236) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11236action=view) Config log of gcc-4.0.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076
[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error make[1]: *** [getpwd.o] Error 1
--- Comment #3 from sagar dot indalkar at ge dot com 2006-04-10 11:46
---
Hi,
As per suggestion given, I have downloaded the gcc compiler version 4.0.3 and
uploaded to the box. When started configuring the using the command given
below.
../gcc-4.0.3/configure --prefix=/usr/bin/gcc-4.0.3
I was getting error as follows.
configure:2271: gcc -c -g conftest.c 15
configure:2261:17: gmp.h: No such file or directory
configure: In function `main':
configure:2265: `choke' undeclared (first use in this function)
configure:2265: (Each undeclared identifier is reported only once
configure:2265: for each function it appears in.)
configure:2265: parse error before me
configure: failed program was:
#line 2260 configure
#include confdefs.h
#include gmp.h
int main() {
#if __GNU_MP_VERSION 3
choke me
#endif
; return 0; }
For more details I have attached config.log file.
Thanks in advance
Regards,
Sagar
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076
[Bug tree-optimization/27085] [4.2 regression] ICE in add_virtual_operand
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-10 11:54 --- Probably related to PR 26626. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27085
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-04-10 11:56 --- So it is indeed chicken and egg ;) load-PRE does not PRE the loads if the loop is not in do-while form, and we won't hoist the loop header copies until the loads are PREd. As to comment #13, if we are able to clean the two innermost loops of a nest that is already a good improvement. Though from all the experiments it looks like it is advisable to write do-while loops with hoisted loop header copies manually rather than for loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
[Bug bootstrap/27099] stage3 compare failure
--- Comment #2 from andy at trojanfoe dot servebeer dot com 2006-04-10 12:01 --- If I configure without --enable-bootstrap I get this error quite early on during the build: config.status: creating libada-mk config.status: creating auto-host.h config.status: executing default commands Bootstrapping the compiler gmake[1]: Entering directory `/tmp/gcc-4.1.0/gcc' gmake[1]: *** No rule to make target `bootstrap'. Stop. gmake[1]: Leaving directory `/tmp/gcc-4.1.0/gcc' gmake: *** [bootstrap] Error 2 -- andy at trojanfoe dot servebeer dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
[Bug libfortran/24685] real(16) formatted input is broken for huge values
--- Comment #16 from jakub at gcc dot gnu dot org 2006-04-10 12:02 --- Subject: Bug 24685 Author: jakub Date: Mon Apr 10 12:02:55 2006 New Revision: 112819 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112819 Log: PR libgfortran/24685 * io/write.c (MIN_FIELD_WIDTH, STR, STR1): Define. (output_float): Increase buffer sizes for IEEE quad and IBM extended long double. (write_real): Output REAL(16) as 1PG43.34E4 rather than 1PG40.31E4. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug debug/27057] [4.0/4.1/4.2 Regression] ICE with -feliminate-dwarf2-dups and using namespace
--- Comment #1 from jakub at gcc dot gnu dot org 2006-04-10 13:18 --- Subject: Bug 27057 Author: jakub Date: Mon Apr 10 13:18:19 2006 New Revision: 112820 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112820 Log: PR debug/27057 * dwarf2out.c (is_symbol_die): Return true also for namespaces. * g++.dg/debug/dwarf2-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27057
[Bug debug/27057] [4.0/4.1/4.2 Regression] ICE with -feliminate-dwarf2-dups and using namespace
--- Comment #2 from jakub at gcc dot gnu dot org 2006-04-10 13:21 --- Subject: Bug 27057 Author: jakub Date: Mon Apr 10 13:21:13 2006 New Revision: 112821 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112821 Log: PR debug/27057 * dwarf2out.c (is_symbol_die): Return true also for namespaces. * g++.dg/debug/dwarf2-2.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/debug/dwarf2-2.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/dwarf2out.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27057
[Bug c++/27100] New: ICE with multiple friend declarations
The compiler segfaults on the following valid code snippet when invoked
with g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0:
struct A
{
friend void foo() {}
friend void foo();
};
The error message on mainline is:
bug.cc:4: warning: 'void foo()' is already a friend of class 'A'
bug.cc:4: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
This happens since the two command line parameters were introduced (GCC 3.3).
--
Summary: ICE with multiple friend declarations
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored, GC
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100
[Bug libgcj/27101] New: GCJ rejects valid code (for Sun's measure of valid')
This is probably a duplicate of something that has been filed before,
but my cursory search failed to turn up any similar tickets.
GCJ rejects code that both Sun and Eclipse compilers accept.
Here's the test case:
| $ cat Reluctant.java
| public class Reluctant {
| private Reluctant internalInstance = new Reluctant();
|
| public Reluctant() throws Exception {
| throw new Exception(I'm not coming out);
| }
|
| public static void main(String[] args) {
| try {
| Reluctant b = new Reluctant();
| System.out.println(Surprise!);
| } catch (Exception ex) {
| System.out.println(I told you so);
| }
| }
| }
The test comes from
http://www.javapuzzlers.com/java-puzzlers.zip
Here's what I'm using
| $ gcj -v
| Using built-in specs.
| Reading specs from /usr/lib/gcc/x86_64-redhat-linux/4.1.0/libgcj.spec
| rename spec lib to liborig
| Target: x86_64-redhat-linux
| Configured with: ../configure --prefix=/usr --mandir=/usr/share/man \
| --infodir=/usr/share/info --enable-shared --enable-threads=posix \
| --enable-checking=release --with-system-zlib --enable-__cxa_atexit \
| --disable-libunwind-exceptions --enable-libgcj-multifile \
| --enable-languages=c,c++,objc,obj-c++,java,fortran,ada \
| --enable-java-awt=gtk --disable-dssi \
| --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre \
| --with-cpu=generic --host=x86_64-redhat-linux
|
| Thread model: posix
| gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)
Here's the compilation error the above code triggers:
| $ gcj -C Reluctant.java
| Reluctant.java: In class 'Reluctant':
| Reluctant.java: In method 'finit$()':
| Reluctant.java:2: error: Exception $-1òøjava.lang.Exceptionòù can't be
thrown in initializer.
| private Reluctant internalInstance = new Reluctant();
| ^
| 1 error
Here's what the Eclipse compiler has to say:
| $ ecj -v
| Eclipse Java Compiler v_585_R31x, 3.1.2 release, Copyright IBM Corp 2000,
2006. All rights reserved.
| $ ecj Reluctant.java
| --
| 1. WARNING in Reluctant.java
| (at line 2)
| private Reluctant internalInstance = new Reluctant();
|
| The field Reluctant.internalInstance is never read locally
| --
| --
| 2. WARNING in Reluctant.java
| (at line 10)
| Reluctant b = new Reluctant();
| ^
| The local variable b is never read
| --
| 2 problems (2 warnings)
No errors.
Same with Sun's javac:
| $ javac -version 21 | head -n1
| javac 1.5.0_06
| $ javac -Xlint Reluctant.java
| $ echo $?
| 0
--
Summary: GCJ rejects valid code (for Sun's measure of valid')
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vnasardinov at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27101
[Bug c++/26660] [4.2 Regression] PCH vs -save-temps, ICE while GCing
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-10 13:58
---
Confirmed. One can also use the following for t1.cc:
=
#include t.hh
void foo() {}
=
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-04-10 13:58:10
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26660
[Bug fortran/27096] Automatic charlen pointer array result produces and ICE
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-10 14:19 --- The peculiar code turns out to be a result of the way in which I kludged my way past the ICE. In sorting the out, I found that there is a double fault: The implicit result version of the above character(10), dimension (2) :: inp inp = abcdefghij inp = join_1(inp) print *, inp contains function join_1(self) character(len=*), dimension(:) :: self character(len=len(self)), dimension(:), pointer :: join_1 allocate (join_1(2)) join_1 = self end function end compiles but hits the runtime error: Fortran runtime error: Attempt to allocate negative amount of memory. Possible integer overflow. I must check that this is not an existing PR. A double patch is on its way. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27096
[Bug fortran/25597] ICE with allocate on the return value of a function, character array with a len of an argument
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-04-10 14:35 --- (In reply to comment #5) (In reply to comment #4) A little further reduced: Actually that is a different bug. Anyways the reduced testcase looks like: FUNCTION reallocate_hnv(p,n,LEN) CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: reallocate_hnv ALLOCATE(reallocate_hnv(n)) END FUNCTION reallocate_hnv This no longer ICEs but does bomn out in runtime, as described in PR27096 Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25597
[Bug fortran/27096] Automatic charlen pointer array result produces and ICE
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-10
14:48 ---
A patch (not regtested yet, nor tested on tonto) and testcase for this and
PR25597:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(révision 112529)
+++ gcc/fortran/trans-decl.c(copie de travail)
@@ -2536,6 +2536,12 @@
{
tree result = TREE_VALUE (current_fake_result_decl);
fnbody = gfc_trans_dummy_array_bias (proc_sym, result, fnbody);
+
+ /* An automatic character length, pointer array result. */
+ if (proc_sym-ts.type == BT_CHARACTER
+TREE_CODE (proc_sym-ts.cl-backend_decl) == VAR_DECL)
+ fnbody = gfc_trans_dummy_character (proc_sym, proc_sym-ts.cl,
+ fnbody);
}
else if (proc_sym-ts.type == BT_CHARACTER)
{
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (révision 112529)
+++ gcc/fortran/trans-array.c (copie de travail)
@@ -4385,7 +4385,14 @@
/* Get the descriptor type. */
type = TREE_TYPE (sym-backend_decl);
- gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));
+ if (!GFC_DESCRIPTOR_TYPE_P (type))
+{
+ /* If the backend_decl is not a descriptor, we must have a pointer
+to one. */
+ descriptor = build_fold_indirect_ref (sym-backend_decl);
+ type = TREE_TYPE (descriptor);
+ gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));
+}
/* NULLIFY the data pointer. */
gfc_conv_descriptor_data_set (fnblock, descriptor, null_pointer_node);
! { dg-do run }
! Tests the fixes for PR25597 and PR27096.
!
! This test combines the PR testcases.
!
character(10), dimension (2) :: implicit_result
character(10), dimension (2) :: explicit_result
character(10), dimension (2) :: source
source = abcdefghij
explicit_result = join_1(source)
if (any (explicit_result .ne. source)) call abort ()
implicit_result = reallocate_hnv (source, size(source, 1), LEN (source))
if (any (implicit_result .ne. source)) call abort ()
contains
! This function would cause an ICE in gfc_trans_deferred_array.
function join_1(self) result(res)
character(len=*), dimension(:) :: self
character(len=len(self)), dimension(:), pointer :: res
allocate (res(2))
res = self
end function
! This function originally ICEd and latterly caused a runtime error.
FUNCTION reallocate_hnv(p, n, LEN)
CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: reallocate_hnv
character(*), dimension(:) :: p
ALLOCATE (reallocate_hnv(n))
reallocate_hnv = p
END FUNCTION reallocate_hnv
end
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27096
[Bug c++/27102] New: Semgmentation Fault on Template
gcc gives segmenation fault on the following code:
template class T
void T::foo() {
}
--
Summary: Semgmentation Fault on Template
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mmirzaza at cs dot uwaterloo dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c++/27102] [4.0/4.1/4.2 regression] ICE with invalid class name in function template
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-04-10 15:01 --- Confirmed. We had a similar problem with template classes in PR18731. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code, ||monitored Last reconfirmed|-00-00 00:00:00 |2006-04-10 15:01:31 date|| Summary|Semgmentation Fault on |[4.0/4.1/4.2 regression] ICE |Template|with invalid class name in ||function template Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c++/27102] [4.0/4.1/4.2 regression] ICE with invalid class name in function template
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-10 15:03 --- Btw, the ICE is a segfault on the 4.0 branch. On the 4.1 branch and mainline we get: bug.cc:2: internal compiler error: in is_ancestor, at cp/name-lookup.c: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto
--- Comment #14 from paul dot richard dot thomas at cea dot fr 2006-04-10 15:07 --- (In reply to comment #13) PR23634 does not affect this PR. So only two bugs left. I checked by commenting out the lines effecting compiling. I have submitted 2 PRs for tonto-2.2; PR25597 and PR27096. The first I have submitted a patch for and the patch for the second will be submitted tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26106
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-04-10 15:31
---
I wonder if it helps placing this between cunroll and ivopts...
void foo(int n, int m, int stridex, int stridey, int stridex2, int stridey2,
double *x, double *y)
{
for (int k=0; km; ++k)
for (int j=0; jn; ++j)
for (int i=0; i2; ++i)
x[i + stridex*j + stridex2*k] = y[i + stridey*j + stridey2*k];
}
producing better IV selection than what we get now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #24 from edmar at freescale dot com 2006-04-10 15:42 --- I am sorry, but the patches on comments 17, 18, 21, and 22 are no good without the patch on comment 5, which seems, it was never commited into the repository... Can you double check this. Thanks. Edmar -- edmar at freescale dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #14 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-10 15:53 ---
Subject: Re: IVs with the same evolution not eliminated
I wonder if it helps placing this between cunroll and ivopts...
void foo(int n, int m, int stridex, int stridey, int stridex2, int stridey2,
double *x, double *y)
{
for (int k=0; km; ++k)
for (int j=0; jn; ++j)
for (int i=0; i2; ++i)
x[i + stridex*j + stridex2*k] = y[i + stridey*j + stridey2*k];
}
producing better IV selection than what we get now.
ivopts do not care (they will recognize that the two array references
have the same offsets).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug bootstrap/27099] stage3 compare failure
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-04-10 15:55 --- config.status: creating libada-mk config.status: creating auto-host.h config.status: executing default commands Bootstrapping the compiler gmake[1]: Entering directory `/tmp/gcc-4.1.0/gcc' gmake[1]: *** No rule to make target `bootstrap'. Stop. gmake[1]: Leaving directory `/tmp/gcc-4.1.0/gcc' gmake: *** [bootstrap] Error 2 http://gcc.gnu.org/install/configure.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
[Bug c++/27094] [4.0/4.1/4.2 Regression] tree check: expected tree_list, have omp_return in build_call
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-10 16:22 ---
Here is another testcase (which was reduced from the same source and gives a
similar error message but does not have inheritance in it):
templatetypename _Tp struct allocator
{
~allocator() throw() { }
};
struct list
{
allocatorint _M_impl;
};
template int
struct stack {
stack(const list __c = list());
};
stack 1 a;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|x86_64-linux-gnu|
GCC host triplet|x86_64-linux-gnu|
GCC target triplet|x86_64-linux-gnu|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug c++/27098] throw cause terminate() instead of catch
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-10 16:28 --- *** This bug has been marked as a duplicate of 11813 *** -- 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=27098
[Bug c/11813] make -fexceptions default for c and objective-c
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-10 16:28 --- *** Bug 27098 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mlazar at kma dot zcu dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11813
[Bug java/27101] GCJ rejects valid code (for Sun's measure of valid')
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-10 16:30 --- Please next time if you going to put the testcase inline don't put stuff in front of the testcase so it can be easy to access. Anyways confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|libgcj |java Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2006-04-10 16:30:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27101
[Bug c++/27100] ICE with multiple friend declarations
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-10 16:34 --- 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 |2006-04-10 16:34:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100
[Bug tree-optimization/27085] [4.2 regression] ICE in add_virtual_operand
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-10 16:35 --- It is a dup, Daniel asked me yesterday to close it as one but I did not get around to it til today. *** This bug has been marked as a duplicate of 26626 *** -- 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=27085
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-04-10 16:35 --- *** Bug 27085 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error make[1]: *** [getpwd.o] Error 1
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-10 16:40 --- That error should not effect compiling of GCC unless you need a fortran compiler and then you need to read: http://gcc.gnu.org/install/ AND: http://gcc.gnu.org/install/prerequisites.html People build all the time on x86-linux-gnu so we know building is not broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076
[Bug fortran/27089] Module procedure with explicit result does not pass type to specification expression.
-- 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-10 16:41:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27089
[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error make[1]: *** [getpwd.o] Error 1
--- Comment #5 from sagar dot indalkar at ge dot com 2006-04-10 16:49 --- Hi, Thanks for quick response. I am not installing Fortran compiler, I am only installing the gcc compiler. After your mail I have tried running the make command. make command still giving the error. The error is as follows. gcc -c -DHAVE_CONFIG_H -g -I. -I../../gcc-4.0.3/libiberty/../include -W -Wall -Wtraditional -pedantic ../../gcc-4.0.3/libiberty/getpwd.c -o getpwd.o ../../gcc-4.0.3/libiberty/getpwd.c: In function `getpwd': ../../gcc-4.0.3/libiberty/getpwd.c:77: storage size of `dotstat' isn't known ../../gcc-4.0.3/libiberty/getpwd.c:77: storage size of `pwdstat' isn't known ../../gcc-4.0.3/libiberty/getpwd.c:81: warning: implicit declaration of function `getenv' ../../gcc-4.0.3/libiberty/getpwd.c:81: warning: assignment makes pointer from integer without a cast ../../gcc-4.0.3/libiberty/getpwd.c:83: warning: implicit declaration of function `stat' ../../gcc-4.0.3/libiberty/getpwd.c:89: warning: implicit declaration of function `getcwd' ../../gcc-4.0.3/libiberty/getpwd.c:92: warning: implicit declaration of function `free' ../../gcc-4.0.3/libiberty/getpwd.c:77: warning: unused variable `dotstat' ../../gcc-4.0.3/libiberty/getpwd.c:77: warning: unused variable `pwdstat' make[1]: *** [getpwd.o] Error 1 make[1]: Leaving directory `/var/build/gcc-4.0.3-build/libiberty' make: *** [all-libiberty] Error 2 Could you please let me know what is the problem because for gcc version 3.4.0 I was getting almost same error. Is there anyway to resolve the error? This problem is preventing my project work. Thanks in advance Regards, Sagar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076
[Bug bootstrap/26066] disable-threads causes undefined reference to pthread_kill and pthread_sigmask
--- Comment #2 from polite at itd dot nrl dot navy dot mil 2006-04-10 17:25 --- I tried the same thing with gcc 4.1.0 and I got the same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26066
[Bug java/27101] GCJ rejects valid code (for Sun's measure of valid')
--- Comment #2 from vnasardinov at gmail dot com 2006-04-10 18:12 --- Tom Fitzsimmons stopped complaining about my pipe-quoting technique after I told him about M-x delete-rectangle a.k.a. C-x r d. Takes about 5 seconds in Emacs to fix this up. One, if you type really fast :) Thanks for looking at this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27101
[Bug tree-optimization/27090] FRE does loop past previous type casts
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-10 18:12 ---
Well really more like:
int f(int *a)
{
int t = *a;
unsigned *b = (unsigned *)a;
int *c = (int*)b;
return *c + t;
}
Which should be the same as:
int f(int *a)
{
return *a * 2;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.
--- Comment #13 from sje at cup dot hp dot com 2006-04-10 18:22 --- Putting the size of pad back seems OK on IA64 in both ILP32 and LP64 modes. In ILP32 mode I get: The DTP Size of p: 136 Size of pad: 200 Size of char *: 4 Size if int: 4 In LP64 mode, both on HP-UX and Linux, I get: The DTP Size of p: 168 Size of pad: 264 Size of char *: 8 Size if int: 4 So we have space without changing the size of pad and by putting pad back to the original size I do get programs to work but the alignment problem described in comment #11 is still there waiting to hit at any time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890
[Bug java/27101] GCJ rejects valid code (for Sun's measure of valid')
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-10 18:24 --- (In reply to comment #2) Tom Fitzsimmons stopped complaining about my pipe-quoting technique after I told him about M-x delete-rectangle a.k.a. C-x r d. Takes about 5 seconds in Emacs to fix this up. One, if you type really fast :) Thanks for looking at this. Who uses emacs, I am serious, I don't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27101
[Bug tree-optimization/27103] New: ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
[ forwarded from http://bugs.debian.org/361814 ]
[EMAIL PROTECTED]:/tmp% cat test.c
typedef struct { int size; } gnutls_datum;
typedef struct gnutls_cert { gnutls_datum raw; } gnutls_cert;
typedef struct { } gnutls_privkey;
int _gnutls_log_level;
void _gnutls_log(void);
void _gnutls_write_datum24(char*, gnutls_datum);
void _gnutls_gen_x509_crt (gnutls_cert *apr_cert_list,
char *pdata) {
if (_gnutls_log_level)
_gnutls_log();
_gnutls_write_datum24(pdata, apr_cert_list-raw);
pdata += apr_cert_list-raw.size;
}
[EMAIL PROTECTED]:/tmp% gcc -c -O test.c
[EMAIL PROTECTED]:/tmp% gcc-4.1 -c -O2 test.c
[EMAIL PROTECTED]:/tmp% gcc -c -O2 test.c
test.c: In function '_gnutls_gen_x509_crt':
test.c:10: internal compiler error: tree check: expected ssa_name, have
symbol_memory_tag in verify_ssa, at tree-ssa.c:776
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Falk
--
Summary: ICE: tree check: expected ssa_name, have
symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
[Bug tree-optimization/27103] ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-10 18:43 --- Related to PR 26490. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26490 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
[Bug tree-optimization/27103] [4.2 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE: tree check: expected |[4.2 Regression] ICE: tree |ssa_name, have |check: expected ssa_name, |symbol_memory_tag in|have symbol_memory_tag in |is_old_name, at tree-into- |is_old_name, at tree-into- |ssa.c:466 |ssa.c:466 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
[Bug tree-optimization/27103] [4.2 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 18:45 --- This works with 4.2.0 20060409. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
[Bug tree-optimization/27103] [4.2 Regression] ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
--- Comment #3 from debian-gcc at lists dot debian dot org 2006-04-10 18:53 --- (In reply to comment #2) This works with 4.2.0 20060409. Hmm. I get the ICE with 4.2.0 20060407. Will try a newer one... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
[Bug libgcj/27104] New: definite assingment bug in GCJ
All of the compiler versions are the same as in bug 27101. Sun's compiler: | $ javac UnwelcomeGuest.java | UnwelcomeGuest.java:9: variable USER_ID might already have been assigned | USER_ID = GUEST_USER_ID; | ^ | 1 error The Eclipse compiler: | $ ecj UnwelcomeGuest.java | -- | 1. ERROR in UnwelcomeGuest.java | (at line 9) | USER_ID = GUEST_USER_ID; | ^^^ | The final field USER_ID may already have been assigned | -- | 1 problem (1 error) GCJ: | $ gcj -C UnwelcomeGuest.java | $ echo $? | 0 Will attach the test case momentarily. -- Summary: definite assingment bug in GCJ Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vnasardinov at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27104
[Bug libgcj/27104] definite assingment bug in GCJ
--- Comment #1 from vnasardinov at gmail dot com 2006-04-10 19:02 --- Created an attachment (id=11237) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11237action=view) the test case This comes from http://www.javapuzzlers.com/java-puzzlers.zip with minor modifications. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27104
[Bug java/27104] static final variable not being tracked as being set correctly
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 19:04 --- And I already filed this once before too :). Anyways this is a dup of bug 24835. *** This bug has been marked as a duplicate of 24835 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|libgcj |java Keywords||accepts-invalid Resolution||DUPLICATE Summary|definite assingment bug in |static final variable not |GCJ |being tracked as being set ||correctly http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27104
[Bug java/24835] gcj accepts invalid code with static final variables
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 19:04 --- *** Bug 27104 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||vnasardinov at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24835
[Bug java/27104] static final variable not being tracked as being set correctly
--- Comment #3 from vnasardinov at gmail dot com 2006-04-10 19:15 --- Thanks. It would help to have the words definite assignment and/or definitely unassigned and/or http://java.sun.com/docs/books/jls/third_edition/html/defAssign.html somewhere in the summary or comments, so people can find it before filing duplicates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27104
[Bug target/7625] gcc pessimized 64-bit % operator on hppa2.0
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-10 19:49 --- Boooiinngg... Or, is anyone working on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7625
[Bug target/26778] [4.0/4.1/4.2 regression] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-10 19:57 --- GCC 3.4 did better, said the reporter in comment #0. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|GCC4 moves the result of a |[4.0/4.1/4.2 regression] |conditional block through |GCC4 moves the result of a |inadequate registers|conditional block through ||inadequate registers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug target/7625] gcc pessimized 64-bit % operator on hppa2.0
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-04-10 20:17 --- Subject: Re: gcc pessimized 64-bit % operator on hppa2.0 Boooiinngg... Or, is anyone working on this? I'm not. Note that the HP code is using 64-bit registers and instructions in 32-bit mode for the call to $$rem2. I think doing this in GCC is going to be tricky as normal calls only save the the least significant 32-bits. Maybe we could somehow confine 64-bit register values to the call clobbered registers. Normally register pairs are used for 64-bit values. In 64-bit mode, we can probably easily benefit from using the new 64-bit millicode. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7625
[Bug target/25671] test_bit() compilation does not expand to bt instruction
--- Comment #2 from steven at gcc dot gnu dot org 2006-04-10 20:18 --- The resulting code for -march=opteron: test_bit: .LFB2: leal63(%rsi), %edx testl %esi, %esi movl%esi, %eax cmovns %esi, %edx sarl$31, %eax shrl$26, %eax sarl$6, %edx leal(%rsi,%rax), %ecx movslq %edx,%rdx andl$63, %ecx subl%eax, %ecx movl$1, %eax sall%cl, %eax cltq testq %rax, (%rdi,%rdx,8) setne %al movzbl %al, %eax ret For -march=nocona the code is even uglier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
[Bug target/25671] test_bit() compilation does not expand to bt instruction
--- Comment #3 from steven at gcc dot gnu dot org 2006-04-10 20:31 --- This is what the i386 machine description has to say about BT and friends: ;; %%% bts, btr, btc, bt. ;; In general these instructions are *slow* when applied to memory, ;; since they enforce atomic operation. When applied to registers, ;; it depends on the cpu implementation. They're never faster than ;; the corresponding and/ior/xor operations, so with 32-bit there's ;; no point. But in 64-bit, we can't hold the relevant immediates ;; within the instruction itself, so operating on bits in the high ;; 32-bits of a register becomes easier. ;; ;; These are slow on Nocona, but fast on Athlon64. We do require the use ;; of btrq and btcq for corner cases of post-reload expansion of absdf and ;; negdf respectively, so they can never be disabled entirely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
[Bug tree-optimization/27105] New: ICE with -O3 -ftree-loop-linear
I tried the last (gcc-4.2-20060408) snapshot. When I compile the preprocessed source t.ii the compiler segfaults. /usr/local/gcc42h/bin/g++42h -O3 -ftree-loop-linear -S t.ii g++42h -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.2-20060408/configure --prefix=/usr/local/gcc42h --program-suffix=42h --with-arch=opteron --enable-languages=c,c++ --enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib --enable-checking Thread model: posix gcc version 4.2.0 20060408 (experimental) using gdb I got this call stack: #0 is_gimple_min_invariant (t=0x0) at ../../gcc-4.2-20060408/gcc/tree-gimple.c:172 #1 0x005df0d8 in expr_invariant_in_loop_p (loop=0x1315790, expr=0x0) at ../../gcc-4.2-20060408/gcc/tree-ssa-loop-ivopts.c:1303 #2 0x005df15e in expr_invariant_in_loop_p (loop=0x1315790, expr=0x2a99c12690) at ../../gcc-4.2-20060408/gcc/tree-ssa-loop-ivopts.c:1321 #3 0x005df15e in expr_invariant_in_loop_p (loop=0x1315790, expr=0x2a99c12620) at ../../gcc-4.2-20060408/gcc/tree-ssa-loop-ivopts.c:1321 #4 0x005df15e in expr_invariant_in_loop_p (loop=0x1315790, expr=0x2a9ba1b300) at ../../gcc-4.2-20060408/gcc/tree-ssa-loop-ivopts.c:1321 #5 0x00989e65 in can_put_in_inner_loop (inner=0x1315790, stmt=0x2a9e90c780) at ../../gcc-4.2-20060408/gcc/lambda-code.c:2175 #6 0x0098b3d8 in can_convert_to_perfect_nest (loop=0x13156d0, loopivs=0x11eced0) at ../../gcc-4.2-20060408/gcc/lambda-code.c:2268 #7 0x0098b7d6 in perfect_nestify (loops=0xed7470, loop=0x13156d0, lbounds=0x12a8310, ubounds=0x12c5f20, steps=0x12b9760, loopivs=0x11eced0) at ../../gcc-4.2-20060408/gcc/lambda-code.c:2362 #8 0x0098d276 in gcc_loopnest_to_lambda_loopnest (currloops=0xed7470, loop_nest=0x13156d0, inductionvars=0x7fbfffe258, invariants=0x7fbfffe250, need_perfect_nest=1 '\001') at ../../gcc-4.2-20060408/gcc/lambda-code.c:1494 #9 0x00889277 in linear_transform_loops (loops=0xed7470) at ../../gcc-4.2-20060408/gcc/tree-loop-linear.c:322 #10 0x005b7345 in tree_linear_transform () at ../../gcc-4.2-20060408/gcc/tree-ssa-loop.c:228 #11 0x008843bb in execute_one_pass (pass=0xc5f660) at ../../gcc-4.2-20060408/gcc/passes.c:863 #12 0x0088452c in execute_pass_list (pass=0xc5f660) at ../../gcc-4.2-20060408/gcc/passes.c:910 #13 0x0088453e in execute_pass_list (pass=0xc5f480) at ../../gcc-4.2-20060408/gcc/passes.c:911 #14 0x0088453e in execute_pass_list (pass=0xc5eac0) at ../../gcc-4.2-20060408/gcc/passes.c:911 #15 0x0055c047 in tree_rest_of_compilation (fndecl=0x2a966e3000) at ../../gcc-4.2-20060408/gcc/tree-optimize.c:418 #16 0x004d2aa8 in expand_body (fn=0x2a966e3000) at ../../gcc-4.2-20060408/gcc/cp/semantics.c:3012 #17 0x008d34c6 in cgraph_expand_function (node=0x2a9b2596c0) at ../../gcc-4.2-20060408/gcc/cgraphunit.c:1102 #18 0x008d5bbe in cgraph_optimize () at ../../gcc-4.2-20060408/gcc/cgraphunit.c:1167 #19 0x0047f635 in cp_finish_file () at ../../gcc-4.2-20060408/gcc/cp/decl2.c:3147 #20 0x0053140a in c_common_parse_file (set_yydebug=Variable set_yydebug is not available. ) at ../../gcc-4.2-20060408/gcc/c-opts.c:1165 #21 0x00855ce8 in toplev_main (argc=Variable argc is not available. I tried to delta-debug but after removing the preprocessor comments I got: internal compiler error: verify_cgraph_node failed So I decided to attach the original preprocessed source. Michael Cieslinski -- Summary: ICE with -O3 -ftree-loop-linear Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27105
[Bug tree-optimization/27105] ICE with -O3 -ftree-loop-linear
--- Comment #1 from micis at gmx dot de 2006-04-10 20:33 --- Created an attachment (id=11238) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11238action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27105
[Bug tree-optimization/27105] ICE with -O3 -ftree-loop-linear
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-10 20:49 --- Yes, it is known that -ftree-loop-linear is buggy. There might already be a dup of this bug too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27105
[Bug bootstrap/27099] stage3 compare failure
--- Comment #4 from andy at trojanfoe dot servebeer dot com 2006-04-10 23:18 --- Thanks, I thought I had read that pretty well. Am I being stupid? Andy -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27099
[Bug libfortran/27107] New: Make dependency on io/io.h broken
When revising libgfortran/io/io.h by itself, make does not recompile source files that include io.h causing erroneous builds. To get files recompiled that depend on io.h one must 'touch' the sourcefiles. -- Summary: Make dependency on io/io.h broken Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gno http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27107
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #25 from amodra at gcc dot gnu dot org 2006-04-11 00:33 --- Subject: Bug 26459 Author: amodra Date: Tue Apr 11 00:33:29 2006 New Revision: 112843 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112843 Log: PR target/26459 * config/rs6000/e500-double.h (SUB3TARGET_OVERRIDE_OPTIONS): Test rs6000_explicit_options.float_gprs. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/e500-double.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #26 from amodra at gcc dot gnu dot org 2006-04-11 00:36 --- Subject: Bug 26459 Author: amodra Date: Tue Apr 11 00:36:50 2006 New Revision: 112844 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112844 Log: PR target/26459 * config/rs6000/e500-double.h (SUB3TARGET_OVERRIDE_OPTIONS): Test rs6000_explicit_options.float_gprs. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/e500-double.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug c/27108] New: syntax error with same-name typedef and local variable using va_arg
When compiling this (after cpp):
# 1 test.c
# 1 built-in
# 1 command line
# 1 test.c
# 1 /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/stdarg.h 1 3 4
# 43 /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/stdarg.h 3 4
typedef __builtin_va_list __gnuc_va_list;
# 105 /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/stdarg.h 3 4
typedef __gnuc_va_list va_list;
# 2 test.c 2
typedef int foo;
pathological(int a, ...) {
int foo;
va_list ap;
__builtin_va_arg(ap,foo);
}
I get this error:
test.c: In function `pathological':
test.c:9: error: parse error before foo
Removing the 'int foo' declaration in 'pathological' fixes the error. I'm not
sure what to make of this; however, I would suspect that the variable named foo
is preventing gcc from seeing the typedef named foo.
--
Summary: syntax error with same-name typedef and local variable
using va_arg
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jesuswaffle at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27108
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #27 from amodra at bigpond dot net dot au 2006-04-11 00:37 --- Sorry! My apologies for closing this bug without checking that the original problem had been fixed. I was focusing on the code generation problems. -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug c/27108] syntax error with same-name typedef and local variable using va_arg
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 01:06 --- This is not a bug as foo is now a variable decl and not a typedef one so foo a; would fail also. Now if this was C++ you could use ::foo to get the typedef version of foo but this is C and there is no way to access the other namespaces. In 4.1.0 and above the error message is now: t.c: In function 'pathological': t.c:12: error: expected specifier-qualifier-list before 'foo' -- 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=27108
[Bug tree-optimization/27090] FRE does not look past previous type casts
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug tree-optimization/27090] FRE does not look past previous type casts
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-11 01:21 --- Just a note VN.2 should really have not been created (maybe there is no way around this because it is just equivalant to VN.0). This actually gets fixed by a real tree combiner since fold is able to fix up (int*)(unsigned*)intptr (or the C++ example). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug tree-optimization/27090] FRE does not look past previous type casts
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-11 01:33 --- So I talked to Daniel about this and he said a new Number value system or the tree combiner so basicially there is nothing can be done currently. Guess maybe it is time for you Richard to stop hacking on fowardprop and start hacking on a real tree combiner :) (I don't have time to do it any more). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||15459 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
[Bug debug/21391] [3.4/4.0/4.1/4.2 Regression] referencing a type via a cast does not emit it for debug (feliminate-unused-debug-types)
--- Comment #6 from aldyh at gcc dot gnu dot org 2006-04-11 01:38 --- Patch that fixes the problem. http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00380.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21391
[Bug tree-optimization/27109] New: Simplify a - 10 150 into a 160 when range of a is known (in VRP or somewhere else)
Kinda like PR 14490 but for the -fwrapv and unsigned cases:
void bar (void);
void
foo (unsigned a)
{
if (a 100)
return;
if (200 a)
return;
if (a - 10 150)
bar ();
}
--
Summary: Simplify a - 10 150 into a 160 when range of a
is known (in VRP or somewhere else)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
[Bug tree-optimization/27109] Simplify a - 10 150 into a 160 when range of a is known (in VRP or somewhere else)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
[Bug target/18900] Don't use fp/vmx regs for mem moves without explicit use of fp/vmx
--- Comment #3 from amodra at bigpond dot net dot au 2006-04-11 02:10 --- The same issue applies to VMX (Altivec) registers. With lazy fp/vmx task switching, the first use of fp/vmx regs in a task can be expensive. -- amodra at bigpond dot net dot au changed: What|Removed |Added Summary|Should be able to not use fp|Don't use fp/vmx regs for |moves for functions that|mem moves without explicit |don't implicted use float |use of fp/vmx |point registers | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18900
[Bug c/27110] New: gcc 4.1.0 mcore-unknown-elf-gcc internal compiler error in extract_insn, at recog.c
when compiling newlib with mcore-unknown-elf-gcc (v4.1.0) I get an internal compiler error. Compiler configure line ../gcc-4.1.0/configure --target=mcore-unknown-elf --disable-libssp --enable-languages=c The command line that triggers the bug is mcore-unknown-elf-gcc -B/home/peter_jan/mcore/build-newlib/mcore-unknown-elf/big/newlib/ -isystem /home/peter_jan/mcore/build-newlib/mcore-unknown-elf/big/newlib/targ-include -isystem /home/peter_jan/mcore/newlib-1.14.0/newlib/libc/include -mbig-endian -DPACKAGE=\newlib\ -DVERSION=\1.14.0\ -I. -I../../../../../../newlib-1.14.0/newlib/libc/stdlib -O2 -fno-builtin -O2 -g -O2 -mbig-endian -c ../../../../../../newlib-1.14.0/newlib/libc/stdlib/dtoa.c --save-temps Here is the compiler output ../../../../../../newlib-1.14.0/newlib/libc/stdlib/dtoa.c: In function _dtoa_r: ../../../../../../newlib-1.14.0/newlib/libc/stdlib/dtoa.c:854: error: unrecognizable insn: (insn 167 166 168 18 ../../../../../../newlib-1.14.0/newlib/libc/stdlib/dtoa.c:287 (set (reg:SI 191) (const:SI (plus:SI (symbol_ref/f:SI (*.LC3) [flags 0x2] string_cst 0xb7c96c60) (const_int 1 [0x1] -1 (nil) (nil)) ../../../../../../newlib-1.14.0/newlib/libc/stdlib/dtoa.c:854: internal compiler error: in extract_insn, at recog.c:2084 -- Summary: gcc 4.1.0 mcore-unknown-elf-gcc internal compiler error in extract_insn, at recog.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter dot jansen at aad dot gov dot au GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: mcore-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27110
[Bug c/27110] gcc 4.1.0 mcore-unknown-elf-gcc internal compiler error in extract_insn, at recog.c
--- Comment #1 from peter dot jansen at aad dot gov dot au 2006-04-11 02:34 --- Created an attachment (id=11239) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11239action=view) Here is the preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27110
[Bug target/27110] gcc 4.1.0 mcore-unknown-elf-gcc internal compiler error in extract_insn, at recog.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-11 02:45 --- *** This bug has been marked as a duplicate of 25690 *** -- 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=27110
[Bug target/25690] error: unrecognizable insn - failed to assign a[1] if a is a struct
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-11 02:45 --- *** Bug 27110 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||peter dot jansen at aad dot ||gov dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
[Bug target/18900] Don't use fp regs for mem moves without explicit use of fp
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-11 02:49 --- Altivec can be done with -mno-altivec and it is not really a real pain because if you are going to use altivec registers in your program, you want to use them more rather than less. And for the functions you don't want explicit use of altivec, put them into a seperate file which does not compile with -maltivec (or compile that seperate file with -mno-altivec since some -mcpu=* enables altivec). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Don't use fp/vmx regs for |Don't use fp regs for mem |mem moves without explicit |moves without explicit use |use of fp/vmx |of fp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18900
[Bug c/26154] [4.2 Regression] OpenMP extensions to the C language is not documented
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-11 03:00 --- It should be something like what XLC does at: http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/topic/com.ibm.xlcpp8l.doc/compiler/ref/ruprpdir.htm#RUPRPDIR Which is actually much better than what is even in the current GCC docs which is nothing even at the toplevel of extensions that GCC supports. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-11 03:00:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
[Bug classpath/24481] SecureRandom.setSeed has no impact
--- Comment #5 from csm at gnu dot org 2006-04-11 04:21 ---
The original issue seems to be fixed; on gcj version `gcj (GCC) 4.2.0 20060410
(experimental)' I get this output from the `seed' testcase:
Byte difference in a seeded PRNG: 64
Seed data:
9c1185a5c5e9fc5461288977ee8f548b2258d3138bbc57e4cbe8b6a1d2c999ef6253e0a6e58196ae643db8559e6ba7c97214bd66197b97184d68e3b0654b
David, are you saying that if you have a program like:
import java.security.SecureRandom;
class sr
{
public static void main (String[] argv) throws Throwable
{
SecureRandom sr = new SecureRandom ();
byte[] b = new byte[64];
sr.nextBytes (b);
for (int i = 0; i b.length; i++)
{
System.out.print (b[i]);
System.out.print (' ');
}
System.out.println ();
}
}
...that you get the same output every time?
If so, this is because our default SecureRandom isn't seeded when created.
Ideally, we would try to use `/dev/random,' or some timing data to get a random
seed.
--
csm at gnu dot org changed:
What|Removed |Added
CC||david at jpackage dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
[Bug target/25690] error: unrecognizable insn - failed to assign a[1] if a is a struct
--- Comment #6 from peter dot jansen at aad dot gov dot au 2006-04-11 04:32 --- Its ok in gcc-3.4.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
[Bug classpath/24481] SecureRandom.setSeed has no impact
--- Comment #6 from david at jpackage dot org 2006-04-11 04:34 --- I was saying something slightly different, since I did not test the program across multiple runs. I did test nextBytes() within the same program run, and this produced identical bytes with each successive call to nextBytes(). Checking the javadocs, I find: ``Note that this instance of SecureRandom has not been seeded... [but] [i]f a call is not made to setSeed, the first call to the nextBytes method will force the SecureRandom object to seed itself.'' Note that even though `new SecureRandom()' does not seed itself, any attempt to extract randomness will cause it to seed itself first before returning any bytes, so I believe the GNU implementation to be incorrect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
[Bug fortran/26257] internal compiler error: Segmentation fault, on function call with assumed shape array parameter
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-11 04:40 --- Subject: Bug 26257 Author: pault Date: Tue Apr 11 04:40:33 2006 New Revision: 112848 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112848 Log: 2006-04-11 Paul Thomas [EMAIL PROTECTED] PR fortran/26257 * trans-array.c (gfc_conv_expr_descriptor): Exclude calculation of the offset and data when se-data_not_needed is set. * trans.h: Include the data_not_need bit in gfc_se. * trans-intrinsic.c (gfc_conv_intrinsic_size): Set it for SIZE. 2006-04-11 Paul Thomas [EMAIL PROTECTED] * PR fortran/26257 gfortran.dg/auto_char_len_3.f90: New test Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/auto_char_len_3.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/fortran/trans.h branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26257
[Bug fortran/26257] internal compiler error: Segmentation fault, on function call with assumed shape array parameter
--- Comment #7 from pault at gcc dot gnu dot org 2006-04-11 04:42 --- Sorry, I forgot about closing out this one on 4.1. Fixed on trunk and 4.1. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26257
[Bug fortran/27096] Automatic charlen pointer array result produces and ICE
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27096
[Bug fortran/27112] New: Rejects to call a generic procedure by argument keywords.
In the following program, generic procedure foo can be distinguished between two procedure foo1 and foo2 by keywords of arguments. But gfortran cannot compile this source code and output the same message twice. I think it is wrong behavior. $ cat test.f90 module m1 implicit none interface foo module procedure foo1 end interface contains subroutine foo1(j) integer :: j end subroutine end module module m2 implicit none interface foo module procedure foo2 end interface contains subroutine foo2(i) integer :: i end subroutine end module program test use m1 use m2 implicit none call foo(j=3) end program $ gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060129 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran test.f90 In file test.f90:24 use m1 1 Error: Ambiguous interfaces 'foo1' and 'foo2' in generic interface 'foo' at (1) In file test.f90:24 use m1 1 Error: Ambiguous interfaces 'foo1' and 'foo2' in generic interface 'foo' at (1) -- Summary: Rejects to call a generic procedure by argument keywords. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iguchi at coral dot t dot u-tokyo dot ac dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27112
[Bug fortran/27113] New: TODO: Complex array constructors in tonto-2.2
Compiling tonto-2.2 reveals that structure components cannot be used in array constructors: subroutine complex_constructor type BASIS_TYPE character(len=512) :: label end type type(BASIS_TYPE), dimension(:), pointer :: var call read_library_data_((/var%label/)) end subroutine complex_constructor emits.. complex_constructor.f90: In function complex_constructor: complex_constructor.f90:1: fatal error: gfc_todo: Not Implemented: complex character array constructors compilation terminated. I am on to it Paul -- Summary: TODO: Complex array constructors in tonto-2.2 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: pault at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27113
[Bug fortran/27112] Rejects to call a generic procedure by argument keywords.
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-04-11 05:02 --- Intel agrees with gfortran: fortcom: Error: foofoo.f90, line 25: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-spec. [FOO2] use m2 --^ fortcom: Error: foofoo.f90, line 24: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-spec. [FOO1] use m1 --^ compilation aborted for foofoo.f90 (code 1) Also Lahey checker agrees: Checking file SOURCE.F90. Checking program unit M1 at line 1. Checking program unit M2 at line 12. Checking program unit TEST at line 23. Line 25, file SOURCE.F90 use m2 | FATAL -- The arguments for procedures (FOO2) and (FOO1) allow references to the generic procedure to be ambiguous (see Procedure Interfaces in your Fortran 90 language reference). Encountered 1 error, 0 warnings in file SOURCE.F90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27112
[Bug target/18900] Don't use fp regs for mem moves without explicit use of fp
--- Comment #5 from =?ISO-8859-15?Q?=22Thomas_Bj=F6rkman_=28=C4S/EAB=29=22?= thomas dot bjorkman at ericsson dot com 2006-04-11 05:10 --- Subject: Re: Should be able to not use fp moves for functions that don't implicted use float points Hej ! How come the slogan on Bug target/18900 has changed from ppc optimization non removable to Don't use fp regs for mem moves without explicit use of fp ? When will it be corrected ? BR / Thomas Björkman -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18900
[Bug fortran/27112] Rejects to call a generic procedure by argument keywords.
--- Comment #2 from iguchi at coral dot t dot u-tokyo dot ac dot jp 2006-04-11 05:15 --- (In reply to comment #1) Intel does NOT agree with gfortran. I think such discussion is not fruitful. $ ifort --version ifort (IFORT) 9.0 20060222 Copyright (C) 1985-2006 Intel Corporation. All rights reserved. $ ifort test.f90 fortcom: Warning: test.f90, line 25: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [FOO2] use m2 --^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27112
[Bug tree-optimization/27087] [4.1/4.2 regression] ICE in merge_alias_info
--- Comment #3 from law at redhat dot com 2006-04-11 05:41 --- The problem is that may_propagate_copy and merge_alias_info are inconsistent. ie, DOM properly calls may_propagate_copy to determine if a particular copy propagation is valid. may_propagate_copy returns true indicating the copy propagation is valid. However, when the copy propagation is performed and we reach merge_alias_info, merge_alias_info has an additional sanity check that causes it to fail. This really isn't a DOM problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087
[Bug tree-optimization/27087] [4.1/4.2 regression] ICE in merge_alias_info
--- Comment #4 from law at redhat dot com 2006-04-11 05:56 --- Subject: Re: [4.1/4.2 regression] ICE in merge_alias_info On Sat, 2006-04-08 at 23:16 +, pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 23:16 --- Confirmed, the ICE is during DOM. As I mentioned in the PR notes, the problem is tree-ssa-copy.c::may_propagate_copy allows copy propagations which are rejected by merge_alias_info. Specifically it allows copy propagating when the flow-sensitive alias information is not compatible. I'm not entirely sure the compatibility check in may_propagate_copy and merge_alias_info is correct. It seems to me that we want to verify that one is a subset of the other, not just that the two objects have intersecting flow sensitive information. Someone more familiar with this code should follow-up on that issue. My patch merely makes the two routines consistent in how they handle flow-sensitive alias information for copy propagations. Bootstrapped and regression tested on i686-pc-linux-gnu. --- Comment #5 from law at redhat dot com 2006-04-11 05:56 --- Created an attachment (id=11241) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11241action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27087
