On Thursday 04 August 2005 19:12, Jan Hubicka wrote:
Hi,
I've branches the IPA branch yesterday and re-directed current SPEC
testers running tree-profiling branch (now officially retired ;) to it.
( http://www.suse.de/~aj/SPEC/amd64 ).
The branch should be used for interprocedural
On 8/4/05, Shaun Jackman [EMAIL PROTECTED] wrote:
Are you using an x86 host and an arm target?
Actually no, my major concern at the time was the large quantity of
legacy code with packed structures that we have on an embedded linux
x86 system. I was just testing that we didn't have an issue
I haven't bootstrapped gcc on cygwin for a while now... but, using gcc cvs trunk
LAST_UPDATED: Fri Aug 5 09:05:37 UTC 2005, I get comparison warnings...:
warning: ./cc1-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1plus-checksum.o differs
what does that mean?? the
In PR 23046 we ICE inside tree-vrp.c because fold() does not
realize that for
enum enumtype { ENUM1, ENUM2 } x;
the predicate 'if (x 1)' is always false. This causes VRP to
create the impossible range [2, 1] for that predicate.
While it would be trivial for VRP to paper over this problem, the
On Fri, 5 Aug 2005, Jan Hubicka wrote:
I guess the web pages should be updated with something like the attached?
Yes...
This looks fine to me. Thanks! Perhaps even cvs.html should mention
that tree-profiling was almost fully merged and retired?
...and, yes. ;-)
Minor comments for the
Hallo,
what must I do for becomming the GNU Fortran Compiler?
Sincerely, Hans.
BEGIN:VCARD
VERSION:2.1
N:Karl;Hans-Volker;;;
FN:Hans-Volker Karl
BDAY:1955-11-30
ORG:Paris-Lodron-Universität Salzburg;
NOTE:Dipl. Phil. Dr. rer. nat. Präparator f. Geowissenschaften u. Medizin;
On Fri, Aug 05, 2005 at 05:52:20PM +0200, [EMAIL PROTECTED] wrote:
what must I do for becomming the GNU Fortran Compiler?
If you are running a recent Linux distribution that includes GCC
4, you should already have it. Try 'gfortran'.
If not, you can find binaries at
Original Message
From: [EMAIL PROTECTED]
Sent: 05 August 2005 16:52
Hallo,
what must I do for becomming the GNU Fortran Compiler?
Sincerely, Hans.
zenTo become the compiler, you must _think_ like the compiler./zen
cheers,
DaveK
--
Can't think of a witty .sigline
On 8/5/05, Carl Whitwell [EMAIL PROTECTED] wrote:
On 8/4/05, Shaun Jackman [EMAIL PROTECTED] wrote:
Are you using an x86 host and an arm target?
Actually no, my major concern at the time was the large quantity of
legacy code with packed structures that we have on an embedded linux
x86
On Fri, 5 Aug 2005, Dave Korn wrote:
Hallo,
what must I do for becomming the GNU Fortran Compiler?
Sincerely, Hans.
zenTo become the compiler, you must _think_ like the compiler./zen
It's an easy mistake to make for Germans speaking English, because the
German verb bekommen means to get,
Original Message
From: Nicholas Nethercote
Sent: 05 August 2005 17:15
On Fri, 5 Aug 2005, Dave Korn wrote:
Hallo,
what must I do for becomming the GNU Fortran Compiler?
Sincerely, Hans.
zenTo become the compiler, you must _think_ like the compiler./zen
It's an easy mistake to
Debian GNU/Linux 3.1 using a custom-built 2.4.27 smp kernel and glibc
2.3.2.ds1-22:
$ config.guess
alphaev68-unknown-linux-gnu
$ gcc -v
Using built-in specs.
Target: alphaev68-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure --prefix=/opt/gcc-4.0.1
Thread model: posix
gcc version
On Fri, 2005-08-05 at 09:59 -0400, Diego Novillo wrote:
In PR 23046 we ICE inside tree-vrp.c because fold() does not
realize that for
enum enumtype { ENUM1, ENUM2 } x;
the predicate 'if (x 1)' is always false. This causes VRP to
create the impossible range [2, 1] for that predicate.
Hi all,
Something about GCC's instantiation stack messages seems curious to
me: for a given stack layer, the location in the message is not that
of the template instance name that appears in the same message, but
instead the point of instantiation of a template instance named in
the
On Aug 5, 2005, at 2:22 PM, James Widman wrote:
Hi all,
Something about GCC's instantiation stack messages seems curious to
me: for a given stack layer, the location in the message is not
that of the template instance name that appears in the same
message, but instead the point of
On Fri, Aug 05, 2005 at 11:57:45AM -0600, Jeffrey A Law wrote:
IIRC the C standard does not guarantee that an object stay within
the bounds of its enumerated type. You'll have to do some digging
in the relevant standards.
For the record, I believe we've addressed these issues sometime
within
The TYPE_MIN/MAX_VALUE for an enum should be set to the range truely
required by the relevant language standards (different between C and
C++).
I don't know for a fact that Ada has been adjusted for this though.
But if an Ada developer can verify that enumerations are
* Richard Henderson:
For the record, I believe we've addressed these issues sometime
within the last year or two. The TYPE_MIN/MAX_VALUE for an enum
should be set to the range truely required by the relevant language
standards (different between C and C++).
I don't know for a fact that Ada
* Richard Kenner:
This is wrong (as discussed before) and is likely the cause of PR21573
(not VRP-related, the expanders for SWITCH_EXPR look at these
attributes, too). I'm not sure if it is safe to delete these
assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE
This is simply not true for Ada. Look at the definition of the 'Valid
attribute in the standard:
3. X'Valid
Yields True if and only if the object denoted by X is normal
and has a valid representation. The value of this attribute
is of the
* Richard Kenner:
This is simply not true for Ada. Look at the definition of the 'Valid
attribute in the standard:
3. X'Valid
Yields True if and only if the object denoted by X is normal
and has a valid representation. The value of this attribute
Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity
Checking) require that such reads are NOT erroneous.
It depends what such reads mean. 13.9.1(12) clearly says that the
result of an Unchecked_Conversion is erroneous if it isn't a valid
representation. There are some
Christian Joensson wrote:
warning: ./cc1-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1plus-checksum.o differs
what does that mean?? the compare passes... and the build continues...
The checksums are used for PCH validatation. We generate md5 checksums
for each cc1
We observed that certain large C++ applications perform worse
in gcc-3.x and gcc-4.x than they did in gcc-2.95.3.
On the theory that at least some of the cause
would show up in microbenchmarks, we tried running
bench++ with both old and new toolchains.
Because we suspect that part of the
I finally got 4.0.1 built in msys. I must have screwed up my msys/gcc
setup because a clean install of msys and gcc-3.4.1 worked. I started
with a simple test:
main.cpp:
~~
#include iostream
int main()
{
cout Hello\n;
return 0;
}
then I try and build
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-05 06:08
---
This is amusing.
integer o(4), b, c
COMMON /IBM/ o
EQUIVALENCE (o(1),b),(C,o(4))
o(3)=1
CALL MYSUB1
CALL MYSUB2
END
subroutine MYSUB1
integer o
--- Additional Comments From chris at bubblescope dot net 2005-08-05 08:29
---
While it doesn't fix your bug, if you want a hash_map I'd advise looking at
tr1/unordered_map, which
I'd expect to work better. I think however you'll find that all implementations
of hash_map strictly
building glibc-2.3.5 on ix86 linux with gcc 4.0.1 fails complaining that
'isinf' aliased to undefined symbol '__isinf'
however, on the same box, using the same config options but using gcc 3.4.3 the
build is successful with no issues
have been using:
binutils 2.16.1
linux 2.6.11
--- Additional Comments From nathan at gcc dot gnu dot org 2005-08-05
09:12 ---
stealing from Richard -- thanks for your investigation. If it turns out your
patch is best, I'll let you know :)
--
What|Removed |Added
When nesting a function that returns an array result within a call to
a subroutine I get either segmentation or double free errors with gfortran.
I am using gfortran 4.0.1 on Fedora Core 4
$ gfortran -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr
# gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.0-beta20050730
--- Additional Comments From zlynx at acm dot org 2005-08-05 10:45 ---
Created an attachment (id=9435)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9435action=view)
code to reproduce ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23247
When nesting a function that returns an array result within a call to
a subroutine I get either segmentation or double free errors with gfortran.
I am using gfortran 4.0.1 on Fedora Core 4
$ gfortran -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr
--- Additional Comments From f dot a dot akeroyd at rl dot ac dot uk
2005-08-05 10:56 ---
Sorry for double submission - my session timed out and i didn't think bug
23246 had actually been submitted.
*** This bug has been marked as a duplicate of 23246 ***
--
What
--- Additional Comments From f dot a dot akeroyd at rl dot ac dot uk
2005-08-05 10:57 ---
*** Bug 23248 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23246
--- Additional Comments From gcc at derived-software dot ltd dot uk
2005-08-05 12:01 ---
Ok, I've tried to configure with:
../gcc-4.1-20050730/configure --prefix=/usr \
--libexecdir=/usr/libexec/gcc/i686-pc-linux-gnu/4.1.0-beta20050730 \
--- Additional Comments From christian dot joensson at gmail dot com
2005-08-05 12:21 ---
Phython, Do you have any idea of this?
--
What|Removed |Added
CC|
--- Additional Comments From christian dot joensson at gmail dot com
2005-08-05 12:23 ---
BTW, this happens on mainline, 4.0 branch, and also 3.4 branch, see, e.g.,
http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00196.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23072
--- Additional Comments From bangerth at dealii dot org 2005-08-05 13:10
---
I fail to see how James' quote has any significance for this PR at all. It
talks about overload resolution, which is not the question here at all.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-05
13:30 ---
Can't reproduce with mainline as of 2005-08-04. Could you try again?
--
What|Removed |Added
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-05
13:36 ---
Bah. My compiler had checking disabled. Sorry about that.
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|REOPENED
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-05
14:28 ---
Testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-05
14:47 ---
It seems to work find. In both cases you have two results for treelang.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23072
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-05
14:49 ---
I patched fold to change if (FOO TYPE_MAX) or if (FOO TYPE_MIN) to if (0)
and this fixes the ice. I'll mail the patch when I get back from work tonight.
--
--- Additional Comments From christian dot joensson at gmail dot com
2005-08-05 15:01 ---
hmm, a recent run on i686-linux givs me this:
PASS: treelang/execute/static.tree execution test
testcase /usr/local/src/trunk/gcc/gcc/testsuite/treelang/execute/execute.exp
co\mpleted in 1 seconds
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
15:27 ---
glibc see PR 20652 which references the glibc patch which fixes it there.
*** This bug has been marked as a duplicate of 20652 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
15:27 ---
*** Bug 23245 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-05
15:28 ---
For the record: The bug from comment #6 is tracked in PR23118.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
--
What|Removed |Added
Component|c |tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23247
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-05
15:43 ---
Testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22010
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
16:06 ---
Subject: Bug 23135
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-05 16:06:35
Modified files:
gcc: ChangeLog reload.c
Log message:
The older version of gcc produces corret code e.g.:
arm-elf-gcc-3.4.4 -g -Os -fPIC -mthumb -mlittle-endian -mapcs \
-march=armv4t -mcallee-super-interworking \
-c progWord.c -o 3_4_4_thumb.o
3_4_4_thumb.o: file format elf32-littlearm
Disassembly of section .text:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
16:12 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23250
--- Additional Comments From jconner at apple dot com 2005-08-05 16:14
---
Subject: Re: [3.4/4.0/4.1 Regression] Invalid code generated for comparison of
uchar to 255
Right. The annoying thing is that it is in 3.3.6 too so I think
someone should
fix the typo on the 3.3 branch
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-05
16:35 ---
Confirmed. Note, you can work around the problem by passing -mthumb-interwork
in addition to -mcallee-super-interworking.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
16:42 ---
Confirmed, reduced testcase:
typedef struct {
unsigned int mask[4];
} SE_PRIV;
static const SE_PRIV se_priv_all = { { 0x, 0x, 0x,
0x } };
typedef struct sid_info
{
SE_PRIV
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
16:43 ---
cfg.c:135 (alloc_block) 5933016: 0.5% 0:
0.0% 0: 0.0%1561320: 0.6%
39033
bitmap.c:137 (bitmap_element_allocate) 35842644: 2.8%
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-05
16:46 ---
(In reply to comment #14)
I patched fold to change if (FOO TYPE_MAX) or if (FOO TYPE_MIN) to if (0)
and this fixes the ice. I'll mail the patch when I get back from work
tonight.
That was my idea
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
16:50 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
16:51 ---
Hmm, does this work now after PR 23135 was fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23240
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-05
17:27 ---
I see what you mean. I'll look at the treelang bugs on the weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23072
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-05
17:38 ---
Richard's patch indeed does not fix the shorter testcase
==
templateint struct AX {};
struct A {};
==
which leads to a segfault in
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-05
17:39 ---
James has a potential fix for fold. If that doesn't work, a simple change to
extract_range_from_assert_expr should provide a similar effect. However, the
real problem in this PR is fold() not doing its
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
17:51 ---
Subject: Bug 21562
CVSROOT:/cvs/gcc
Module name:gcc
Branch: apple-local-200502-branch
Changes by: [EMAIL PROTECTED] 2005-08-05 17:51:14
Modified files:
gcc
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-05
17:52 ---
Even shorter testcase:
==
templateint struct A a;
struct A {};
==
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23219
This is a darwin specific flag that is passed to the linker and should be
present.
// Begin myTest.cpp
#include cstdio
int main(inst argc, char *argv[])
{
printf(Hello World\n);
return 0;
}
// End myTest.cpp
//
// Begin myLog.txt
jrevans%
jrevans% /usr/bin/g++ -o
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
18:36 ---
Fixed in 4.0.0 and above.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
18:38 ---
By:
2004-03-03 Mike Stump [EMAIL PROTECTED]
Add framework support for darwin.
* c-incpath.c: Include target.h and machmode.h.
(add_path): Use a consistent style for cpp_dir.
--- Additional Comments From dje at gcc dot gnu dot org 2005-08-05 18:56
---
The PowerPC string instruction requires an indirect address, so the base does
not explicitly reference virtual-incoming-args, which breaks the tests that
check_sibcall_argument_overlap to notice overlap. For
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-05
19:38 ---
Testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-05
20:17 ---
At least it's caught at runtime with -fbounds-check:
$ gfortran -fbounds-check conform.f90
$ ./a.out
Fortran runtime error: Array bound mismatch
I agree that a compile-time check would be better.
--
/usr/local/bin/gcc --version
gcc (GCC) 3.4.4
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This should be 2005, shouldn't it?
--
--
What|Removed |Added
Summary|copyright year still at 2004|[3.4 only] copyright year
||still at 2004
Target
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-08-05
20:28 ---
Sorry guys, I messed up with the other patches needed to build on mingw32.
--
What|Removed |Added
--
Bug 23138 depends on bug 23210, which changed state.
Bug 23210 Summary: i686-pc-mingw32/libssp: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23210
What|Old Value |New Value
While testing some FORTRAN 90 code under Fedora Core 4,
I found problem initializing COMPLEX PARAMETERs with other
parameters that have + or - in front of the variable name.
The following .f90 test code will illustrate the problem.
All lines should compile fine.
The lines that fail are commented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
20:35 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
20:39 ---
Subject: Bug 21529
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-05 20:39:05
Modified files:
gcc:
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 20:39
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu
||dot org
Status|ASSIGNED
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 20:43
---
Then it'll stay broken at -O0 until we completely rewrite rtl expansion.
There are really very few ways around this problem...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
20:45 ---
If we add more bit-fields, that is now fixed in 4.0.2 and 4.1.0 by:
2005-08-04 Richard Henderson [EMAIL PROTECTED]
PR 21529
* params.def (PARAM_SRA_MAX_STRUCTURE_COUNT): New.
*
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
21:01 ---
Subject: Bug 19063
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-05 21:01:47
Modified files:
gcc/cp : ChangeLog name-lookup.c
Log
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-08-05
21:04 ---
Reopending to mark as duplicate of PR 19063.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-08-05
21:04 ---
*** This bug has been marked as a duplicate of 19063 ***
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-08-05
21:04 ---
*** Bug 13268 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From fw at deneb dot enyo dot de 2005-08-05 21:43
---
(In reply to comment #5)
(In reply to comment #4)
What about permitting this as a GNU extension? It seems quite useful for
template code.
With this you mean omitting the definition? Well, it saves
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-08-05
22:01 ---
Patched tested and submitted to review
(http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00338.html).
--
What|Removed |Added
While using gcc-3.3.3 to bootstrap gcc-3.3.6 on arm,
the build fails with an ICE near the end of stage2:
./xgcc -B./
-B/home/mikpe/pkgs/linux-armv5b/gcc-3.3.6/armv5b-unknown-linux-gnu/bin/ -isystem
/home/mikpe/pkgs/linux-armv5b/gcc-3.3.6/armv5b-unknown-linux-gnu/include
-isystem
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-05 22:52
---
The code appears to be illegal. Lahey reports
Compiling program unit consts_test at line 1:
1034-S: SOURCE.F90, line 10: Right parenthesis missing or position of right
parenthesis invalid.
1034-S:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
23:02 ---
Subject: Bug 21728
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-05 23:01:54
Modified files:
gcc: ChangeLog tree-cfg.c
Added files:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
23:02 ---
Subject: Bug 21728
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-05 23:02:41
Modified files:
gcc:
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 23:08
---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21728
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 23:13
---
Problem occurs between user and keyboard.
--
What|Removed |Added
Status|ASSIGNED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 23:38
---
Front end bug.
error (return type %q#T is incomplete, TREE_TYPE (fntype));
/* Make it return void instead, but don't change the
type of the DECL_RESULT, in case we have a named return
1 - 100 of 108 matches
Mail list logo
