--- Additional Comments From mark at codesourcery dot com 2005-03-08 07:45
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
Alexandre Oliva wrote:
> So think of it this way: if we adopted COMPOUND_LITERAL_EXPR like
> you're inclined to do, we'd ha
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-08
07:24 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> (a) we should never use "==" to compare types, because there's
--- Additional Comments From tsandnes at atmel dot no 2005-03-08 07:07
---
Subject: Re: Overflowed address in dwarf debug line information
> I applied the GCC and binutil patches to ensure that my gcc is the same as
> that
> used in WinAVR Feb14/05 distribution. I then built libc1.
--- Additional Comments From jason at redhat dot com 2005-03-08 06:47
---
Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
On Thu, 03 Mar 2005 23:26:04 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Your reading is logical, but it depends on exactly what
--- Additional Comments From uros at kss-loka dot si 2005-03-08 06:29
---
Patch for mainline awaiting review:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00644.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17688
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
05:49 ---
(In reply to comment #5)
> Please do clarify me.
I will help you for one million US dollars.
On a more serious note, 2.96 is not supported at all by the FSF. Either pay me
or pay someone else like
redhat
--- Additional Comments From ramya dot chandar at wipro dot com 2005-03-08
05:42 ---
(In reply to comment #0)
> Environment : i686-pc-linux-gnu
> Compiler Version : GCC 2.96
> Kernel Version: 2.4.20-8 (Redhat 9)
>
> I am not able to do the installation of GCC 2.96 on Redhat 9
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-08
05:08 ---
(In reply to comment #5)
> The testcase given above is already optimizated on the mainline via some of
the aliasing code on the
> tree level but still needs to be more, witness 19905 or even the following
t
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
04:49 ---
(In reply to comment #3)
> Subject: Re: GCC 2.96 installation fails on Redhat 9 version
>
>
> Are we not supposed to use GCC 2.96 ???
No, it was a snapshot and not an official release version of GCC. Als
--- Additional Comments From ramya dot chandar at wipro dot com 2005-03-08
04:42 ---
Subject: Re: GCC 2.96 installation fails on Redhat 9 version
Are we not supposed to use GCC 2.96 ???
If we can use GCC 2.96, what is the version of autoheader needs to be
used and where will be avail
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
04:11 ---
*** Bug 20378 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20377
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
04:11 ---
*** This bug has been marked as a duplicate of 20377 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
04:11 ---
Well 2.96 is dead so closing as such, also the problem is that you are using
the wrong version of
autoheader.
--
What|Removed |Added
---
Environment : i686-pc-linux-gnu
Compiler Version : GCC 2.96
Kernel Version: 2.4.20-8 (Redhat 9)
I am not able to do the installation of GCC 2.96 on Redhat 9.
Configuration is happening successfully. But, while giving the make, it is
failing with the below given error message.
make[1]:
Environment : i686-pc-linux-gnu
Compiler Version : GCC 2.96
Kernel Version: 2.4.20-8 (Redhat 9)
I am not able to do the installation of GCC 2.96 on Redhat 9.
Configuration is happening successfully. But, while giving the make, it is
failing with the below given error message.
make[1]:
--- Additional Comments From renierm at us dot ibm dot com 2005-03-08
03:59 ---
I am experiencing the same exact problem with our project
http://openhpi.sf.net.
gcov_exit() segfaults when the project is compiled with -fprofile-arcs and
-ftest-coverage using gcc-3.4.x, and unit t
--- Additional Comments From law at redhat dot com 2005-03-08 03:49 ---
Fixed with today's checkin. I'll add a test to the testsuite too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18134
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
03:47 ---
Fixed.
--
What|Removed |Added
Target Milestone|--- |4.1.0
http:/
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
03:47 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 18134 depends on bug 18133, which changed state.
Bug 18133 Summary: computed gotos are not folded back to regular gotos when it
is found that they are not computed gotos at all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18133
What|Old Value |New Value
--
Bug 17652 depends on bug 18133, which changed state.
Bug 18133 Summary: computed gotos are not folded back to regular gotos when it
is found that they are not computed gotos at all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18133
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
03:47 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From law at redhat dot com 2005-03-08 03:44 ---
I just checked in a patch which should fix this problem.
--
What|Removed |Added
OtherBugsDependingO|
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-08
03:30 ---
Subject: Re: The missed-optimization of
general induction variables in the new rtl-level loop optimizer cause
performance degradation.
On Tue, 2005-03-08 at 03:18 +, pinskia at physics
On Tue, 2005-03-08 at 03:18 +, pinskia at physics dot uc dot edu
wrote:
> --- Additional Comments From pinskia at physics dot uc dot edu
> 2005-03-08 03:18 ---
> Subject: Re: The missed-optimization of general induction variables in the
> new rtl-level loop optimizer cause performan
--- Additional Comments From dnovillo at redhat dot com 2005-03-08 03:20
---
Subject: Re: The missed-optimization of general
induction variables in the new rtl-level loop optimizer cause performance
degradation.
Andrew Pinski wrote:
> I think you commenting on the wrong bug.
>
Inde
Andrew Pinski wrote:
I think you commenting on the wrong bug.
Indeed. I misread 20376 as 20367. Sorry about that.
--- Additional Comments From pinskia at physics dot uc dot edu 2005-03-08
03:18 ---
Subject: Re: The missed-optimization of general induction variables in the new
rtl-level loop optimizer cause performance degradation.
On Mar 7, 2005, at 10:16 PM, Diego Novillo wrote:
> pinskia at g
On Mar 7, 2005, at 10:16 PM, Diego Novillo wrote:
pinskia at gcc dot gnu dot org wrote:
Why isn't the tree level loop IV-OPTs doing this?
Because variable i is static.
I think you commenting on the wrong bug.
-- Pinski
--- Additional Comments From dnovillo at redhat dot com 2005-03-08 03:16
---
Subject: Re: The missed-optimization of general
induction variables in the new rtl-level loop optimizer cause performance
degradation.
pinskia at gcc dot gnu dot org wrote:
> Why isn't the tree level loop I
pinskia at gcc dot gnu dot org wrote:
Why isn't the tree level loop IV-OPTs doing this?
Because variable i is static.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
03:13 ---
Why isn't the tree level loop IV-OPTs doing this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20376
Induction variables are variables whose successive values form an arithmetic
progression over a loop. Induction variables are often divided into bivs
(basic induction variables), which are explicitly modified by
the same constant amount during each iteration of a loop, and gives (general
induct
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
02:32 ---
: Search converges between 2002-10-15-trunk (#105) and 2002-10-16-trunk (#106).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20209
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
02:31 ---
The diagnostic changed when the new parser was merged in (between 20021213 and
20021228).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20293
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
02:24 ---
: Search converges between 2004-03-01-trunk (#446) and 2004-04-01-trunk (#447).
: Search converges between 2004-03-15-3.4 (#3) and 2004-04-01-3.4 (#4).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2033
--- Additional Comments From tprince at computer dot org 2005-03-08 02:18
---
Subject: Re: 20021014-1.c fails on account of
unsupported build option
At 07:10 AM 3/7/2005, pinskia at gcc dot gnu dot org wrote:
>--- Additional Comments From pinskia at gcc dot gnu dot
>org 2005-
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
01:54 ---
This could either be a target bug or a middle-end bug.
I am aiming for a target bug:
/* We assume at most one partial arg, and it must be the first
argument on the stack. */
The following C++ testcase, compiled on ia64-hp-hpux11.23 with -mlp64, yields
the following ICE (a regression in 4.0/4.1 relative to 3.4). This seems
to be target-specific.
t.cc: In member function 'virtual void*& c::f(float, u, ...)':
t.cc:9: internal compiler error: in assign_parm_find_entry_rt
--- Additional Comments From dnovillo at redhat dot com 2005-03-08 01:36
---
Subject: Re: alias analysis doesn't take into
account that variables that haven't their address taken can't alias arbitrary
MEMs
pinskia at gcc dot gnu dot org wrote:
> void g();
> int
> f(int s, int *a)
>
pinskia at gcc dot gnu dot org wrote:
void g();
int
f(int s, int *a)
{
static int i;
for (i = 0; i < 800; i++)
{
g();
s += a[i];
}
return s;
}
But all of this needs to be on the tree level to be really effective.
This particular case is trivial to fix inside the tree optimizers.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
01:21 ---
The testcase given above is already optimizated on the mainline via some of the
aliasing code on the
tree level but still needs to be more, witness 19905 or even the following
testcase which is basically
--
Bug 14442 depends on bug 17671, which changed state.
Bug 17671 Summary: PHI-OPT is not smart enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17671
What|Old Value |New Value
--
Bug 17652 depends on bug 17671, which changed state.
Bug 17671 Summary: PHI-OPT is not smart enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17671
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
00:41 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-08
00:40 ---
Subject: Bug 17671
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-08 00:40:33
Modified files:
gcc: ChangeLog tree-ssa-phiopt.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
00:34 ---
*** Bug 20374 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
00:34 ---
*** This bug has been marked as a duplicate of 18452 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08
00:31 ---
(In reply to comment #3)
> I reckon this is already fixed by tree-ssa, or we'll be fixed by the incoming
> TARGET_MEM_REF work. Zdenek?
It is fixed via neither of the above but is fixed on the tree-profili
[EMAIL PROTECTED] tests]$ gfortran f2c.F90 -fno-underscoring -c
cc1: warning: command line option "-fno-underscoring" is valid for F95 but not
for C
[EMAIL PROTECTED] tests]$
Where f2c.F90 is an existing file. -v output:
[EMAIL PROTECTED] tests]$ gfortran f2c.F90 -fno-underscoring -c -v
Using b
--- Additional Comments From giovannibajo at libero dot it 2005-03-08
00:27 ---
I reckon this is already fixed by tree-ssa, or we'll be fixed by the incoming
TARGET_MEM_REF work. Zdenek?
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-08
00:21 ---
More on the latent bug that the patch for this PR uncovers:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00448.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15784
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-08 00:11
---
A remark: this doesn't lead to wrong code,
integer, intrinsic :: dsqrt
print *, dsqrt(4.d0)
end
prints the expected 2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20373
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
23:56 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
INTRINSIC dsqrt
INTEGER dsqrt
END
compiles without giving an error. This is invalid: and intrinsic always has the
type defined by 13.13 in the standard, it may only be reaffirmed but not
overwritten.
--
Summary: INTRINSIC symbols can be given the wrong type
Product: gcc
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-07 23:36
---
Also fails on hppa2.0w-hpux now the testsuite knows that platform
supports weak symbols. On that platform there's also
FAIL: gcc.dg/special/weak-1.c execution test
which could be related.
--
http://gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
23:21 ---
I can confirm this has been fixed now.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
23:16 ---
Fixed by:
2005-03-08 Earl Chew <[EMAIL PROTECTED]>
David Billinghurst <[EMAIL PROTECTED]>
* config/i386/host-cygwin.c: New file to support precompiled
headers on cyg
--- Additional Comments From dwatkins at tascsystems dot com 2005-03-07
22:50 ---
Hello,
I applied the GCC and binutil patches to ensure that my gcc is the same as that
used in WinAVR Feb14/05 distribution. I then built libc1.2.3 and clean built
my project. Loaded it all into AS4.11
--- Additional Comments From mark at codesourcery dot com 2005-03-07 22:39
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
Alexandre Oliva wrote:
> On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
>
The games that you want to play
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
22:19 ---
Here is a simplified C code which shows the problem:
int *ggg;
void f(int l1, int l2)
{
int i;
if (l1)
{
for(i=0;ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=20372
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
22:04 ---
I saw this too for some C code somewhere (but that was not a regression at
least as far as I could see).
--
What|Removed |Added
-
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-07
22:00 ---
An analysis and a patch is here:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00298.html
This patch has been used in the meantime in a 3.4 based compiler to
compile various software like Linux kernels etc.
--- Additional Comments From pthaugen at us dot ibm dot com 2005-03-07
21:59 ---
Created an attachment (id=8357)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8357&action=view)
Source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20372
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07
21:58 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>>> The games that you want to play with type-equality are just
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07
21:57 ---
Subject: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
loop attempts to eliminate a biv represented by a pseudo in favor of a
giv represented by (plus (reg) (const_int -1)). Unfortunately,
Noticed a regression relative to 4.0 on the code generated for one of the loops
in zaxpy.f of the SPEC wupwise benchark. The loop is transformed into a
branch-on-count loop, but the target on the branch is the loop exit (return in
this case) instead of the loop start. The 'bct' is immediately follo
See comments in patch
--
Summary: Some corner cases of MS bitfields don't work
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: middle-end
Assig
--
What|Removed |Added
BugsThisDependsOn||20371
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-07
21:32 ---
Created an attachment (id=8356)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8356&action=view)
proposed fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20370
dead_or_predictable calls propagate_block without checking first if there
is suddicient space in reg_n_info. That can lead to memory corruption.
--
Summary: dead_or_predictable doesn't resize reg_n_info
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
--
What|Removed |Added
BugsThisDependsOn||20370
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20355
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-07
21:12 ---
Created an attachment (id=8355)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8355&action=view)
proposed fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20369
noce_emit_move_insn calls emit_move_insn without checking that
the thus generated insn is valid.
--
Summary: noce_emit_move_insn emits invalid insns
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severit
--
What|Removed |Added
BugsThisDependsOn||20369
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
--
What|Removed |Added
Keywords||error-recovery, ice-on-
||invalid-code
http://gcc.gnu.org/bugzi
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-07
20:27 ---
Here is an example out of the google cache:
http://66.102.9.104/search?q=cache:BGnyHfyQlSYJ:gcc.gnu.org/ml/gcc-patches/2004-02/msg01638.html+unspecified_indirect_ref_node&hl=en
RFA: alias analysis for non-a
--- Additional Comments From olh at suse dot de 2005-03-07 20:10 ---
Created an attachment (id=8354)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8354&action=view)
/tmp/s_isnan.i.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20368
after some broken changes to a glibc src file:
[EMAIL PROTECTED]:~/objglibc-40-O1>
/home/abuild/install_gcc40-2-O1/libexec/gcc/powerpc64-unknown-linux-gnu/4.0.0/cc1
-fpreprocessed ~/src/glibc-mainline/math/s_isnan.i -quiet -dumpbase s_isnan.c
-mnew-mnemonics -auxbase-strip /home/abuild/objglibc
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-07
20:01 ---
Created an attachment (id=8353)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8353&action=view)
patch against 3.4
The previous patch had the problem that the non-existence of a MEM_EXPR was
taken
to m
This has been discussed here:
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03141.html
--
Summary: alias analysis doesn't take into account that variables
that haven't their address taken can't alias arbitrary
MEMs
Product: gcc
--
What|Removed |Added
BugsThisDependsOn||20367
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
--- Additional Comments From janis at gcc dot gnu dot org 2005-03-07 19:37
---
Created an attachment (id=8352)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8352&action=view)
minimized test case
This test case is minimized from ammp and gets "fatal error: internal
consistency fail
--- Additional Comments From dje at gcc dot gnu dot org 2005-03-07 19:30
---
G++ and libstdc++ on AIX currently is configured to enable _LARGE_FILE_API,
but not _LARGE_FILES. _LARGE_FILE_API exposes the 64-bit functions with
separate names off64_t and fopen64(), but does not redefine
--- Additional Comments From bojan at antonovic dot com 2005-03-07 19:21
---
Compiling the .java files directly works:
working:
gcj -o bugtest --main=BugTest *.java */*.java
gcj --main=BugTest *.java */*.java */*/*.java
Compiling the code by gcj -C first instead with javac makes no dif
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
19:21 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
Component|c++ |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
The compiler's C++ headers do not appear to work properly on AIX when
the compiler is run with -D_LARGE_FILES. This macro causes the
system headers to #define symbols like fopen, while the C++ headers
unconditionally #undef these symbols.
Environment:
System: AIX
--
What|Removed |Added
BugsThisDependsOn||20365
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
simplify_plus_minus uses an unstabilized qsort call. This makes
the perfomed optimizations dependent on the qsort implementation.
The observed problem was that a mingw hosted compiler generated
different code than a Linux/GNU hosted compiler.
A patch is here:
http://gcc.gnu.org/ml/gcc-cvs/2004-06/
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
19:02 ---
Fixed in 4.0.0 by:
http://gcc.gnu.org/ml/gcc/2004-04/msg00645.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
18:58 ---
Confirmed, here is the backtrace:
#0 0x080ef546 in init_emit () at ../../gcc/emit-rtl.c:5354
#1 0x08133b2e in prepare_function_start (fndecl=0x0) at
../../gcc/function.c:6460
#2 0x08275fef in toplev_main
--
What|Removed |Added
Severity|critical|normal
Component|c |middle-end
Keywords|
Segmentation Fault while trying to compile a file with the -Xpreprocessor
argument :
If the file specified after -Xpreprocessor , does not exist, then gcc crash.
How to reproduce the bug :
$ gcc filename.c -Xpreprocessor file_which_does_not_exist
--filename.c must exist.
Here is what it gives
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-03-07
18:40 ---
(In reply to comment #0)
> Sorry about that I was adding Michael Metcalf to the cc and it, well, went.
$ cat snafu.f90
module snafu
interface foo
subroutine really_snafu (foo)
integer, in
--
Summary: interface body has incorrect scope
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pau
--- Additional Comments From mark at codesourcery dot com 2005-03-07 18:05
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
Alexandre Oliva wrote:
> On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
>
>>Are you sure that we can use TARG
1 - 100 of 151 matches
Mail list logo
