--- Comment #5 from jakub at gcc dot gnu dot org 2006-04-25 07:37 ---
Yes, it fixes it. Will regression test it on a bunch of arches and post to
gcc-patches. Thanks.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
Compiling an attached test program on AMD64 using gcc-4.1.0 with '-O
-ftree-vectorize' produces a code which segfaults, eg.
[EMAIL PROTECTED] ~ $ gcc -O -ftree-vectorize test.c -o test
[EMAIL PROTECTED] ~ $ ./test
Segmentation fault
Compiling it using any -O flags doesn't produce code which segfa
--- Comment #1 from gringo at slonko dot net 2006-04-25 08:01 ---
Created an attachment (id=11332)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11332&action=view)
Test source which produces bad code with '-O -ftree-vectorize'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=272
gcc/ada/Makefile.in selects indepsw-gnu.adb as the body for indepsw.ads on
GNU/Linux.
In contrast, gnattools/configure (generated from gnattools/configure.ac)
selects indepsw-linux.adb, which no longer exists.
The divergence occurred on 2005-07-04 in revision 101581; see
gcc/ada/Makefile.in.
Pat
--- Comment #6 from ludovic at ludovic-brenta dot org 2006-04-25 08:30
---
This appears to be the same bug as PR26678.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
inline void
foo (void *ptr, long n)
{
__asm__ __volatile__ ("" : : "m" (__extension__
({ struct { char x[n]; } *p = ptr;
*p; })));
}
void
bar (void)
{
char buf[16];
foo (buf, sizeof foo);
}
ICEs in tree_cst_low, appar
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-04-25 09:09
---
(In reply to comment #7)
> @Martin: I tried to reduce your testacse a little and got a segfault in
> can_throw_internal_1. So this is probably the same problem as PR26913.
> However the original segfault in
--- Comment #8 from jakub at gcc dot gnu dot org 2006-04-25 09:42 ---
Subject: Bug 26865
Author: jakub
Date: Tue Apr 25 09:42:41 2006
New Revision: 113242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113242
Log:
PR tree-optimization/26865
* gcc.dg/pr26865.c: Ne
--- Comment #9 from jakub at gcc dot gnu dot org 2006-04-25 09:45 ---
Subject: Bug 26865
Author: jakub
Date: Tue Apr 25 09:45:01 2006
New Revision: 113243
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113243
Log:
PR tree-optimization/26865
* tree-ssa-structalias
For the testcase
int foo(int i, int j)
{
return (i < j) == (j > i);
}
fold does not fold the expression to 1, but instead to
i < j ^ j > i
which should be done as a last resort only. fold_comparison does not
handle the original tree either, nor does operand_equal_p see that both
operands of
Sortly,
We have a global variable which is initialized to 1 and named AMLogging.
When we compile our source it does not cause any problem but when we change
AMLogging = 0;
and compile, if at run time we try to access to this variable it is causing
system to crash with a floating point exception to
--
laszlo dot szakony at philips dot com changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26846
Test case:
-
program test
implicit none
integer :: n
n = 1
write(*,'(''n'')') n
end program test
-
gfortran -Wall -o test test1.f90 [4.1.0 (SUSE Linux); 4.2.0 20060423]
Compiles without warning/error and ./test outputs "nn"
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 11:36 ---
First, gcc 3.4.3 is no longer in active maintainance, the oldest still
maintained version is 4.0.3. Second, please read the bugreporting guidelines
and provide a testcase for the problem. Third, this may be as well
Consider the following code:
typedef unsigned int UINT32;
typedef unsigned char BOOL;
#define __SWI_BIOS_ContainerUsage 1234
#define __swicall1(type,name,type1,arg1)\
static inline type name(type1 arg1) { \
register long __r0
--- Comment #6 from mueller at gcc dot gnu dot org 2006-04-25 11:46 ---
the original testcase still ICEs. however now in gimplify.c:5492
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Following code is not compiled correctly and causes never ending loop. GCC
4.0.2 from GNUARM.org distribution was used.
typedef unsigned short U16;
void * ptr = buffer;
void * end = (U16 *)buffer + num;
while (ptr != end)
{
*((U16 *&)ptr)++ = c;
}
dissasebly wit
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 11:49 ---
Confirmed. We generate
0x08048475 : movdqu (%edx),%xmm0
0x08048479 : movdqa %xmm0,(%eax)
but both %edx and %eax are unaligned:
eax0x804a021134520865
ecx0x0 0
edx
--- Comment #2 from mehmet dot ekici at alcatel dot com dot tr 2006-04-25
11:49 ---
(In reply to comment #1)
> First, gcc 3.4.3 is no longer in active maintainance, the oldest still
> maintained version is 4.0.3. Second, please read the bugreporting guidelines
> and provide a testcase
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 11:55 ---
mainline doesn't do vectorization here:
/tmp/t.c:12: note: === vect_analyze_dependences ===
/tmp/t.c:12: note: not vectorized: can't determine dependence between *src.1_24
and *dest.0_23
/tmp/t.c:12: note: bad data
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 12:07 ---
Look at the assembly output of gcc (-S) and see if there is an appropriate
alignment directive before the entry for AMLogging in the bss section. If
there
is, the assembler/linker are at fault. Otherwise please att
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:11 ---
Considering it. What happens?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:15 ---
This is not a valid testcase, or even expression. I guess it's invalid anyway
because of operator precedence.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from falk at debian dot org 2006-04-25 12:19 ---
It's a valid C++ fragment. However, this code accesses "ptr", which is of type
void*, via an lvalue of type U16*. This is undefined behavior, so there is no
gcc bug here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-25 12:20 ---
Oh, this is just an aliasing issue. Reopening...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-25 12:21 ---
.. to close as dup of PR21920.
*** This bug has been marked as a duplicate of 21920 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #93 from rguenth at gcc dot gnu dot org 2006-04-25 12:21
---
*** Bug 27306 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
Consider the following code:
typedef unsigned int UINT32;
typedef unsigned char BOOL;
#define __SWI_BIOS_ContainerUsage 1234
#define __swicall1(type,name,type1,arg1) \
static inline type name(type1 arg1) { \
register long __r0 __asm__
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 12:38 ---
*** Bug 27305 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 12:38 ---
*** This bug has been marked as a duplicate of 27308 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-25 12:49 ---
This is probably a problem with the inline asm constraints. Try removing the
__asm__("r0") from the __res variable. Also try simplifying the testcase by
storing the result of BIOS_ContainerUsage(1) to memory rather
The following invalid testcase causes an ICE since GCC 4.0.0:
=
struct A
{
int i;
A() i() {} // missing colon
};
struct B
{
A a;
};
B b;
=
bug.cc:4: error: expected ';' before 'i'
bug.cc:5: error: expected `;' before '
--- Comment #4 from falk at debian dot org 2006-04-25 13:19 ---
The standard doesn't mention set::erase with "iterator" argument, only with
"const_iterator". Maybe it is legal for g++ to allow it anyway (even if I
cannot find anything in the standard allowing it at the moment), but other
--- Comment #5 from falk at debian dot org 2006-04-25 13:20 ---
(In reply to comment #4)
> The standard doesn't mention set::erase with "iterator" argument, only with
> "const_iterator".
erm. the other way round, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-25 13:23 ---
template
class set
{
...
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 103. set::iterator is required to be modifiable,
// but this allows modification of keys.
typedef typename _Rep_type::
The following testcase causes a segfault in duplicate_eh_regions
when compiled with "-fopenmp -O":
==
struct A
{
~A();
};
struct B
{
A a1, a2;
};
void foo()
{
A x1, x2;
#pragma omp parallel
B b;
}
==
Reduced from Martin's test
--- Comment #7 from pcarlini at suse dot de 2006-04-25 13:33 ---
Yes, we are simply implementing the resolution of DR 103: set<>::iterator is a
constant iterator type
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #5 from walter dot zimmer at dlr dot de 2006-04-25 14:05
---
> The link-time wrapping of malloc is designed precisely so that other
> uninstrumented libraries that call malloc by name still get registered in the
> libmudflap runtime. That way, pointers from these libraries
--- Comment #6 from roger at eyesopen dot com 2006-04-25 14:09 ---
Paolo's fix looks good to me. The bugzilla PR shows that this is a 4.2
regression, probably due to the more aggressive RTL optimizations on mainline.
So I'll preapprove Paolo's fix for mainline (please post the version y
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-25 14:23
---
Richard, you confirmed this.
But to me this looks like the code is violating the aliasing rules
(which would mean that the PR in invalid):
*(uint64_t *)dest = *(uint64_t *)src;
but
uint8_t *dest
const
--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-04-25 14:23
---
This issue is related to PR22002. I have a patch.
A slightly-more reduced testcase is:
struct node { struct node *next; int value; };
struct node *current_node, global_list;
void
bar (void)
{
struct node *nod
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-25 14:27 ---
Yes, but the problem appears with -O1 which has -fno-strict-aliasing. Now
whether -fno-strict-aliasing makes the testcase valid is another question ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-25 14:29 ---
Changing the function to take both arguments as uint8_t* fixes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299
--- Comment #3 from Eric dot Doenges at betty-tv dot com 2006-04-25 14:37
---
Storing the result to memory generates correct code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
--- Comment #4 from Eric dot Doenges at betty-tv dot com 2006-04-25 14:43
---
Removing the __asm__ ("r0") from __res works around the bug - but then I cannot
depend on gcc
always allocating r0 for __res, can I ? I found no other way to tell gcc which
registers it must use.
I'm assuming
compiling the following
--start-code
struct X {
void g();
};
void g();
void f()
{
X x;
x.g();
g();
}
--end-code-
yields (with -O2)
subl$24, %esp
in the prologue. without the empty class only 12 bytes are subtracted,
presumably to preserve stac
--- Comment #7 from dje at watson dot ibm dot com 2006-04-25 15:21 ---
Subject: Re: [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could
not split insn
The patch may be necessary, but does not fix the testcase. The testcase
needs the patch that Andrew originally tested:
--- Comment #8 from roger at eyesopen dot com 2006-04-25 15:41 ---
Grr. David's patch is also good. Perhaps better if we follow the usual
protocol of posting patches to gcc-patches *after* bootstrap and regression
testing, for review and approval. Posting untested patch fragments to
b
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-25 15:45 ---
__res should be allocated to the same register as __r0 due to the '0'
constraint which tells gcc to use the same register as for "=r" (__res).
Whoops - I obviously meant to remove the __asm__("r0") from the __r0
var
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k <= 1000; k++) {
A[k] = B+C;
g = D[k-1] + E[k-1];
if (g > A[k]) A[k]=g; /* This is not converted to cmov*/
f += g;
}
return f;
}
In the above code, the if-then statement is not conver
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-25 15:48 ---
The empty class has a size of 1. And yes, the ABI requires to preserve stack
alignment.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from rguenth at gcc dot gnu dot org 2006-04-25 15:55
---
Created an attachment (id=11333)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11333&action=view)
updated patch
This is a cleanup of the patch by Jeff, bootstrapped and regtested on
x86_64-unknown-linux-gnu.
--- Comment #2 from avi at argo dot co dot il 2006-04-25 15:57 ---
But why 24? gcc could place the object in any of the 12 bytes needed for stack
alignment.
I don't see any reason why the empty object needs to be aligned to more than a
byte boundary.
What am I missing?
--
http://g
--- Comment #9 from dje at gcc dot gnu dot org 2006-04-25 16:09 ---
By the way, while Andrew and my patch does produce correct code, it reverts to
the original behavior of the constant propagating into the AND between life2
and lreg, not between life1 and combine. Somehow combine is abl
Red Hat Enterprise Linux WS release 3 (Taroon Update 6) on Opteron:
bar [10:08:42] /baz > cat foo.f90
program foo
end program foo
bar [10:10:01] /baz > gfortran foo.f90 -Wl,-rpath,/scr_bar/johan/local/lib -o
foo
bar [10:10:24] /baz > ./foo
./foo: error while loading shared libraries: libgfortran.
The following invalid code snippet causes an ICE when compiled with -fopenmp:
===
struct A
#pragma omp parallel
{
template void foo();
};
template void A::foo<0>();
===
bug.cc:2: error: '#pragma' is not allowed here
bug.cc:7: er
The following invalid code snippet causes an ICE when compiled with -fopenmp:
===
struct A {};
struct B : A
#pragma omp parallel
{};
struct B : A
#pragma omp parallel
{};
===
bug.cc:4: error: '#pragma' is not allowed here
bug.cc:5:
-ld=/mingw/bin/ld
--with-as=/m
ingw/bin/as --disable-werror --enable-bootstrap --enable-threads=win32
--with-wi
n32-nlsapi=unicode
Thread model: win32
gcc version 4.2.0 20060425 (experimental)
c:/program files/gfortran/bin/../libexec/gcc/i686-pc-mingw32/4.2.0/f951.exe
ch0
701.f90 -quiet -dumpbase ch0701.
--- Comment #3 from eliot at sonic dot net 2006-04-25 16:44 ---
(In reply to comment #2)
> Can you try a snapshot of 4.1.1 and/or the mainline?
>
i tried mainline. same crash.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
--- Comment #8 from aldot at gcc dot gnu dot org 2006-04-25 17:00 ---
Created an attachment (id=11334)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11334&action=view)
fix typo in errormessage in verify_cgraph_node()
Just as a sidenote.. There is a typo in the error message in com
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-04-25 17:24 ---
Post scriptum:
I actually see two bugs here:
(a) for static format strings, the test should be done at the compile time
(possibly also for c = '(''n'')'; write(*,c) n )
-> see NAG compiler
(b) f
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26846
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:25 ---
Read PR 14704.
*** This bug has been marked as a duplicate of 14704 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-25 17:25 ---
*** Bug 27276 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-25 17:28 ---
We need a testcase to go any further.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-25 17:35 ---
(In reply to comment #5)
> Yes, but the problem appears with -O1 which has -fno-strict-aliasing. Now
> whether -fno-strict-aliasing makes the testcase valid is another question ;)
Nope, unaligned access is differen
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:38 ---
Confirmed, if cvt should have a way to track if a memory write has happened.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:41 ---
This works for me and many other people.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 17:43 ---
This is the not form for support for binaries. We only support GCC which was
been compiled by your self.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
Test case:
--
module test
implicit none
interface
subroutine hello(n)
integer :: n
end subroutine hello
end interface
end module test
subroutine hello(n)
integer, intent(in) :: n
integer :: i
do i = 1,n; print *, 'hello'; end do
end subroutine hello
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:29 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:31 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27292
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.1.1
http://
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:32 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:38 ---
The other way of getting this is to have the code converted so there is only
one store instead of two:
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k,f;
for (k = 1; k <= 1000; k++) {
in
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:38 ---
You must be doing something wrong as I know this works for me and many other
people.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 18:41 ---
Confirmed, the ICE is at least a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-25 18:47 ---
Hmm, interesting, we have a TARGET_EXPR before gimplifying:
__asm__ __volatile__(""::"m" TARGET_EXPR - 1)];
} struct struct
{
char x[0:(unsigned int) ((int) SAVE_EXPR - 1)];
};
struct
{
--- Comment #3 from dwarak dot rajagopal at amd dot com 2006-04-25 19:07
---
Yes this is true. The example I posted was a simplest case where it fails.
Below mmight be a typical case where you have to do two stores.
int cmov(int* A ,int B ,int C ,int* D ,int* E ,int F ,int g) {
int k
--- Comment #7 from brett dot albertson at stratech dot com 2006-04-25
19:29 ---
(In reply to comment #6)
> Fixed.
>
After this patch was applied onto trunk, the following test started failing on
Solaris x86:
FAIL: gcc.dg/tree-prof/val-prof-2.c scan-tree-dump n \+ \-1
All the other
For C++ classes of any type, the class destructor fails to be called under the
following circumstances in the CYGWIN environment (not a problem in linux):
1) A static object of a class is declared within the body of a function which
is part of a shared library.
2) The shared library is loaded wit
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #5 from rth at gcc dot gnu dot org 2006-04-25 20:58 ---
Subject: Bug 25865
Author: rth
Date: Tue Apr 25 20:58:25 2006
New Revision: 113256
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113256
Log:
PR libgomp/25865
* configure.ac: Use GCC_CHECK_TLS.
--- Comment #6 from rth at gcc dot gnu dot org 2006-04-25 21:03 ---
Fixed, or if not, moved the point of failure out of libgomp.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from janis at gcc dot gnu dot org 2006-04-25 21:16 ---
A regression hunt of trunk on powerpc-linux using mini.c with -O2 identified:
http://gcc.gnu.org/viewcvs?view=rev&rev=109016
r109016 | bonzini | 2005-12-23 16:07:53 + (Fri, 23 Dec 2005)
--
http://gcc.gnu.or
--- Comment #7 from george dot chapman at lmco dot com 2006-04-25 21:31
---
I agree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27186
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 21:31 ---
Yes, this is a target specific issue. If the target does not support atexit,
this is what will happen.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from george dot chapman at lmco dot com 2006-04-25 21:32
---
*** This bug has been marked as a duplicate of 26678 ***
--
george dot chapman at lmco dot com changed:
What|Removed |Added
-
--- Comment #9 from george dot chapman at lmco dot com 2006-04-25 21:32
---
*** Bug 27186 has been marked as a duplicate of this bug. ***
--
george dot chapman at lmco dot com changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-25 21:32 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-04-25 21:34
---
Subject: Bug 26725
Author: rsandifo
Date: Tue Apr 25 21:34:48 2006
New Revision: 113257
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113257
Log:
gcc/
PR rtl-optimization/26725
* cfgrtl.c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-04-25 21:36
---
Patch applied to trunk.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
This ICE happens after the error message with
$ cat gen.f90
module generic
interface foo
module procedure foo_real
end interface foo
contains
subroutine foo_real(a)
real :: a
end subroutine foo_real
end module generic
program main
use generic
call foo(1)
end program main
$ gfo
1 - 100 of 118 matches
Mail list logo
