--- Comment #6 from jason at gcc dot gnu dot org 2008-02-25 06:27 ---
Subject: Bug 33486
Author: jason
Date: Mon Feb 25 06:26:24 2008
New Revision: 132611
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132611
Log:
* gcc/cp/parser.c (cp_parser_declaration): Handle 'inline
// David Li
struct A{
int b1: 3;
int b2: 3;
int b3: 2;
int b4: 17;
}a;
void foo()
{
a.b1 = 2;
a.b2 = 3;
a.b4 = 8;
}
This requires one LOAD + one OR + one STORE, but the generate code looks like:
foo:
.LFB2:
movzbl a(%rip), %eax
andl$-64, %eax
orl
// David Li
For switch statement with very large case value range, but the number of actual
cases are not large, gcc generated code seems suboptimal: in some cases, huge
jump table is generated (with lots of duplicated entries), while in other
cases, huge concatenated ifs are generated (the number
// David Li
Gcc is solid in performing dead function elimination and dead variable
elimination for statics. It handles cases when a dead variable is referenced
(via initializer) by other dead variables pretty well. The missing
opportunities noticed is that it fails to discover dead stores to stati
// David Li
the two references in the loop are not aliased. Not optimized by gcc
struct A{
int a;
int b;
};
struct A aa[100];
void foo(int n, int i, int j)
{
int k = 0;
for (k = 0; k < n; k++)
{
aa[i].a += aa[j].b;
}
}
--
Summary: Static (base/offset/size rule) sho
Unmodified formals can not point to local variables. It is NOT treated so in
GCC:
Example:
void bar(int* );
int foo(int* p, int *q)
{
int local, i;
bar(&local);
for(i = 0; i < 100; i++)
{
*q += local;// local, *q not hoisted, *q = not sinked
}
return local;
}
--
// David Li
The issue is known and being worked on. File this bug report just to track the
problem.
One of the rules that can be derived from the basic rules is that if two
access's base types are the same, access offset and size can be used to
determine the overlapping relationships of the two a
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
//David Li
Loop peeling is special case of index splitting. Gcc has support for this
(under -O3 -funrool_loops, also -fno-tree-vectorize for the simple case), but
it does not happen for the following cases:
int a[100];
int b[1000];
void foo(int n)
{
int i;
for ( i = 0; i <= n; i++)
The following cases are not handled by gcc:
case 1:
Example 28: search loop -- yes it is silly, but exists in real program:
for (i = 0; i < n; i++)
{
if ( i == k)
a[i] = ...
}
Should eliminate the loop and generate:
if (k >= 0 && k < n)
a[k] =
case 2:
for (i
--- Comment #1 from danglin at gcc dot gnu dot org 2008-02-25 04:02 ---
I'm seeing essentially the same thing on i686-apple-darwin9:
# gnattools2
make -C ../gcc/ada/tools -f ../Makefile \
"CC=../../xgcc -B../../" "CFLAGS=-O2 -g -g -O2 " "ADAFLAGS=-gnatpg
-g
nata" "INCLUDES=-I
--- Comment #5 from jason at gcc dot gnu dot org 2008-02-25 02:03 ---
This is a compiler bug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #1 from edunlop at utvinternet dot ie 2008-02-24 22:55 ---
Inconsistent or odd "call cpu_time(x)" behaviour on the current release of
gfortran. I am using the 32 bit Mingw version of gfortran.
C:\>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../
Inconsistent or odd "call cpu_time(x)" behaviour on the current release of
gfortran. I am using the 32 bit Mingw version of gfortran.
C:\>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/FX/l
--- Comment #8 from rwild at gcc dot gnu dot org 2008-02-24 22:44 ---
Subject: Bug 15479
Author: rwild
Date: Sun Feb 24 22:44:01 2008
New Revision: 132603
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132603
Log:
PR documentation/15479
* gnat_rm.texi, gnat_ugn.texi: Where appro
--- Comment #7 from rwild at gcc dot gnu dot org 2008-02-24 22:41 ---
Subject: Bug 15479
Author: rwild
Date: Sun Feb 24 22:40:31 2008
New Revision: 132602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132602
Log:
PR documentation/15479
* gnat_rm.texi, gnat_ugn.texi: Where appro
--- Comment #6 from rwild at gcc dot gnu dot org 2008-02-24 22:38 ---
Subject: Bug 15479
Author: rwild
Date: Sun Feb 24 22:37:52 2008
New Revision: 132601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132601
Log:
PR documentation/15479
* gnat_ugn.texi (Using gnatmake in a Makef
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-op
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-24 22:03 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-24 22:02 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-24 22:01 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-24 22:00 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-24 21:59 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-24 21:57 ---
You might run into limits here. I think this restriction was removed at
some point.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-op
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-24 21:54 ---
I think this is a dup of PR23855.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-op
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-02-24 21:47
---
Could you put the breakpoint on the 'error' function rather than at line 34
and examine again the condition when it is hit? Does the problem arise if
you add -fno-delayed-branch on the command line?
--
http:
--- Comment #3 from baraclese at googlemail dot com 2008-02-24 21:22
---
Apparently an old mpfr lib was the problem.
configure did warn me about it but said it was still okay afair. I switched
from mpfr-2.2.1 to mpfr-2.3.0 now and it bootstrapped okay.
--
http://gcc.gnu.org/bugzil
--- Comment #3 from rguenther at suse dot de 2008-02-24 21:14 ---
Subject: Re: Missing Const Prop -- union fields
On Sat, 23 Feb 2008, pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 05:50
> ---
> More than just constant
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-02-24 20:49
---
Besides not truncating or even seeking, the leading NULLs in the file are very
bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
--- Comment #20 from jh at suse dot cz 2008-02-24 20:49 ---
Subject: Re: Stack not aligned at mod 16 byte boundary in x86_64 code
Hi,
what about this patch. There seems to be availablity check missing
earlier in code. This way GCC will always align calls to functions that
might be ov
--- Comment #19 from tege-gcc at swox dot com 2008-02-24 20:39 ---
I believe the "local call" optimization is triggered when compiling
__gmp_randget_mt() because its only call is to a function the compiler
determines to be local. (One can easily untrigger the optimization by
inserting a
--- Comment #5 from hp at gcc dot gnu dot org 2008-02-24 20:25 ---
The above was with 132513.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
--- Comment #4 from hp at gcc dot gnu dot org 2008-02-24 20:17 ---
Created an attachment (id=15220)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15220&action=view)
foo.txt as was output from above modified test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
--- Comment #3 from hp at gcc dot gnu dot org 2008-02-24 20:14 ---
(In reply to comment #1)
> Are you testing
> with a simulator on x86_64-unknown-linux-gnu? I am trying to understand the
> environment. :)
Hm, I thought I was clear enough with the bug report unambiguously indicating a
--- Comment #18 from matz at gcc dot gnu dot org 2008-02-24 19:52 ---
Umm sorry. I meant the __gmp_mt_recalc_buffer function is global in my last
comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
--- Comment #17 from matz at gcc dot gnu dot org 2008-02-24 19:50 ---
Honza: No recursion is involved here. I guess (Tege: correct me if I'm wrong)
that already the first call to __gmp_mt_recalc_buffer() from
__gmp_randget_mt() will segfault, as the first call obviously will end up
in t
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2008-02-24 19:45
---
Fixed on trunk, Thanks for report.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from baraclese at googlemail dot com 2008-02-24 19:41
---
> Can you post the output of /proc/cpuinfo ?
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 4
model name : AMD Athlon(tm) Processor
stepping: 2
cpu MHz
--- Comment #2 from ubizjak at gmail dot com 2008-02-24 19:24 ---
H.J, please note --with-arch=core2 in config.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35350
--- Comment #1 from ubizjak at gmail dot com 2008-02-24 19:23 ---
Confirmed.
gcc.target/i386/isa-10 was introduced by
http://gcc.gnu.org/viewcvs?view=rev&revision=132403
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2008-02-24 19:19 ---
Fixed testcase.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-02-24 19:19
---
Subject: Bug 35223
Author: jvdelisle
Date: Sun Feb 24 19:18:27 2008
New Revision: 132597
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132597
Log:
2008-02-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from uros at gcc dot gnu dot org 2008-02-24 19:18 ---
Subject: Bug 35349
Author: uros
Date: Sun Feb 24 19:17:15 2008
New Revision: 132596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132596
Log:
PR target/35349
* gcc.c-torture/execute/20050604-1.
--- Comment #1 from ubizjak at gmail dot com 2008-02-24 18:24 ---
-march=core2 implies -mmmx, so this test should be executed with -mno-mmx.
Using v4hi, or anything that is defined with vector_size (8), like:
typedef short v4hi __attribute__ ((vector_size (8)));
from the test, uses MMX
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-24 18:07 ---
>../../../libgcc/../gcc/libgcc2.c:799: internal compiler error: Illegal
>instruction
> Please submit a full bug report,
Can you post the output of /proc/cpuinfo ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-02-24 18:05
---
If you do decide to give gfortran a try from the binary you download at the
link given in comment #1, please let us know how it works for you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35348
--- Comment #2 from kargl at gcc dot gnu dot org 2008-02-24 17:42 ---
FX is correct with respect to assignment of a complex expression
to a real variable. See page 141 of the F2003 standard especially
table 7.9.
real x
complex :: z = (1,-1)
x = z
end
The 'x = z' is treated as if you
4.3.0-RC-20080222 configured with:
../configure -v --enable-languages=c,c++ --prefix=/usr/local --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --program-suffix=-4.3 --enable-__cxa_atexit
--enable-clocale=gnu --enable-libstdcxx
--- Comment #9 from dnovillo at gcc dot gnu dot org 2008-02-24 16:41
---
Subject: Bug 33738
Author: dnovillo
Date: Sun Feb 24 16:40:32 2008
New Revision: 132591
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132591
Log:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg0109
--- Comment #6 from pcarlini at suse dot de 2008-02-24 14:40 ---
sync_with_stdio(false) works, and is tested dozens of times a day in our
testsuites. And that is only half of my answer. Please understand what I said,
study the details of the ISO C++ Standard and then come back.
--
pc
--- Comment #5 from ivranos at freemail dot gr 2008-02-24 14:35 ---
sync_with_stdio (false) doesn't work. Actually it crashes the code.
Check the screenshot I have attached in the latest attachment, to see the
difference between the C++ working code and the C++ non-working code.
--
--- Comment #4 from ivranos at freemail dot gr 2008-02-24 14:23 ---
Created an attachment (id=15219)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15219&action=view)
Screenshot of the standard I/O of the working code and of the non-working code.
This screenshot shows the I/O of th
--- Comment #3 from pcarlini at suse dot de 2008-02-24 14:18 ---
Not a bug, given our implementation-defined behavior: the various cin / wcin,
streams are by default synced with stdio (per the standard requirements) and
thus not converting. You can either call sync_with_stdio(false) befo
--- Comment #2 from ivranos at freemail dot gr 2008-02-24 14:15 ---
Created an attachment (id=15218)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15218&action=view)
The produced main.s file
The main.s file produced by "g++ -v -save-temps -ansi -pedantic-errors -Wall
main.cc -o fo
--- Comment #1 from ivranos at freemail dot gr 2008-02-24 14:11 ---
Created an attachment (id=15217)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15217&action=view)
The main.ii file produced by -save-temps option
This is the file created by the
g++ -v -save-temps -ansi -pedant
The following code works:
#include
#include
#include
int main()
{
using namespace std;
char *p= setlocale( LC_ALL, "greek" );
if (!p)
cerr<< "NULL returned!\n";
wstring ws;
wcin>> ws;
wcout<< ws<< endl;
}
[EMAIL PROTECTED] src]$ ./foobar-cpp
Δοκιμαστικό
Δο
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-02-24 14:04
---
The ICE itself can be gotten rid of by setting the offset of the private field
of our ISO_C derived types:
Index: trans-types.c
===
--- trans-types.
--- Comment #5 from aparna dot upadhya at gmail dot com 2008-02-24 14:03
---
(In reply to comment #3)
> The error is emitted by the assembler, this has nothing to do with the
> preprocessor.
Hi,
This is the dupplicate of the bug "Bugzilla Bug 1070 " which is still in Open
state. Sorr
--- Comment #1 from pcarlini at suse dot de 2008-02-24 13:49 ---
You are mistaken: just have a look to the results posted to gcc-testresults,
the test XPASSes, as usual.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #8 from pcarlini at suse dot de 2008-02-24 13:45 ---
*** Bug 35351 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #1 from pcarlini at suse dot de 2008-02-24 13:45 ---
*** This bug has been marked as a duplicate of 35262 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2008-02-24 12:43
---
I cannot reproduce it with mainline on powerpc-apple-darwin9.2.0: I tried the
original testcase and the trimmed one, and varied options (-m32 and -m64,
-gstabs and -gdwarf-2), but can't get it to fail anymore.
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-02-24 12:22
---
g77 is not supported any more; starting with GCC 4.0.0, it was replaced by
gfortran. Cygwin doesn't yet offer gfortran, so you'll have to ask them to do
so and/or download unofficial binaries from
http://gcc.gnu.o
--- Comment #30 from fxcoudert at gcc dot gnu dot org 2008-02-24 12:09
---
So, this was demonstrated to not be a problem on powerpc-apple-darwin9.2.0 any
more. We thus need to establish whether this was fixed in libgfortran or
whether this was fixed in the darwin8 -> darwin9 transition.
dot pipex dot com
GCC build triplet: 4.4.0 20080224(experimental)(GCC)
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35352
-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
--with-arch=core2
Thread model: posix
gcc version 4.4.0 20080224 (experimental) (GCC)
--
Summary: FAIL: abi_check
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
--with-arch=core2
Thread model: posix
gcc version 4.4.0 20080224 (experimental) (GCC)
--
Summary: FAIL: gcc.target/i386/isa-10.c execution test
Product: gcc
Version: 4.4.0
--- Comment #29 from fxcoudert at gcc dot gnu dot org 2008-02-24 11:59
---
Subject: Bug 32841
Author: fxcoudert
Date: Sun Feb 24 11:59:09 2008
New Revision: 132587
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132587
Log:
PR libfortran/32841
* acinclude.m4: Don
--- Comment #4 from aparna dot upadhya at gmail dot com 2008-02-24 11:56
---
(In reply to comment #3)
> The error is emitted by the assembler, this has nothing to do with the
> preprocessor.
yes, but this error is not displayed by 2.95.3 GAS. I am trying to migrate from
2.95.3 to 3.4.5
--enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
--with-arch=core2
Thread model: posix
gcc version 4.4.0 20080224 (experimental) (GCC)
--
Summary: gcc.c-torture/execute/20050604-1.c fails
Product: gcc
--- Comment #3 from schwab at suse dot de 2008-02-24 11:14 ---
The error is emitted by the assembler, this has nothing to do with the
preprocessor.
--
schwab at suse dot de changed:
What|Removed |Added
--
--- Comment #2 from aparna dot upadhya at gmail dot com 2008-02-24 11:00
---
(In reply to comment #1)
> I don't think this is a bug. How are you invoking GCC?
Hi ,
Thanks for the reply. Pls find attached make output
gcc.c3.4.5-p1.ppc -mcpu=860 -ansi -nostdinc -O2 -fno-builtin -I.
Szia!
Emlékszel amikor arról beszéltem hogy meg fog nyílni Magyarország legjobb
letöltõ oldala?
Na, ha igen, akkor itt a link. Jó szorakozást! :)
http://href.hu/x/4pnj
Dear Fortrunners:
The following code has two very common errors, but complies without errors or
warnings: (1) a complex-to-real assignment without explicit REALPART(); (2) a
subroutine call with an erroneous real-array arg in place of a complex-arrray
arg.
PROGRAM TESTCMPL
IMPLICIT
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Ke
--- Comment #6 from dannysmith at gcc dot gnu dot org 2008-02-24 09:20
---
Subject: Bug 34749
Author: dannysmith
Date: Sun Feb 24 09:19:39 2008
New Revision: 132585
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132585
Log:
cp
PR c++/34749
* friend.c (do_friend)
--- Comment #4 from sam at gcc dot gnu dot org 2008-02-24 09:15 ---
Still present on trunk
+===GNAT BUG DETECTED==+
| 4.4.0 20080223 (experimental) (i686-pc-linux-gnu) Assert_Failure
atree.adb:886|
| Error detected at fp-dbs.adb:3489:3
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #3 from rwild at gcc dot gnu dot org 2008-02-24 09:06 ---
Can you post the patch to the gcc-patches list for review, including ChangeLog
entry and reference to this PR?
Note that, while I think it would be prudent if GMP did AC_MSG_WARN rather
than AC_MSG_ERROR for this, err
--- Comment #5 from rwild at gcc dot gnu dot org 2008-02-24 08:58 ---
Patch looks ok to me (but I cannot approve it), can you please post it to
gcc-patches for review?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33131
--- Comment #1 from sam at gcc dot gnu dot org 2008-02-24 08:45 ---
Fabio,
since you already have this version of PolyORB around, could you please try a
pre-release of GCC 4.3.0 and see if this bug is still present?
Sam
--
sam at gcc dot gnu dot org changed:
What|
--- Comment #2 from sam at gcc dot gnu dot org 2008-02-24 08:40 ---
This appears to be fixed in 4.3.0 already.
GNAT 4.3.0 20080202 (experimental) [trunk revision 132072]
Copyright 1992-2007, Free Software Foundation, Inc.
Compiling: xxx/tasks.adb (source file time stamp: 2008-02-24 08:
--- Comment #4 from sam at gcc dot gnu dot org 2008-02-24 08:36 ---
Confirmed with trunk, with the error signaled at another place:
+===GNAT BUG DETECTED==+
| 4.4.0 20080223 (experimental) (i686-pc-linux-gnu) GCC error: |
|
96 matches
Mail list logo
