Hi Ian,
On Sat, Mar 29, 2008 at 07:28:19PM -0700, Ian Lance Taylor wrote:
Robert Millan [EMAIL PROTECTED] writes:
I know it's a bit late, but I just thought that it'd be really nice if GCC
had a C# frontend. I don't have time to do this myself right now (although
I'm willing to work on
Ok, so we all have dozens of these EP93xx ARM SoCs on cheap boards,
with unusable floating point hardware.
What do we have to do to get the best-working GCC support for Maverick
Crunch FPU?
Suggest: make open-source project with objective:.to get the
best-working GCC support for Maverick Crunch
Hi there. I'm a long mailing-list lurker, and I use GCC quite a bit for
embedded software development.
Most of the stuff I write is performance critical, and I always find
myself in the same situation: I spend counter less hours to unswitch
loops by hand because the built-in loop unswitcher
Robert == Robert Millan [EMAIL PROTECTED] writes:
Robert I know it's a bit late, but I just thought that it'd be really
Robert nice if GCC had a C# frontend.
FWIW there is an incomplete CIL front end on a branch. See:
http://gcc.gnu.org/projects/cli.html
Based on experience with gcj I
On Sun, Mar 30, 2008 at 08:47:05AM -0600, Tom Tromey wrote:
Robert == Robert Millan [EMAIL PROTECTED] writes:
Robert I know it's a bit late, but I just thought that it'd be really
Robert nice if GCC had a C# frontend.
FWIW there is an incomplete CIL front end on a branch. See:
On Sat, 29 Mar 2008 12:39:13 +0600, Alexey Salmin
[EMAIL PROTECTED] wrote:
Hello, here's my application. Please, leave your comments as I still
have two days to fix it if something is wrong :)
Project
I want to make some improvements in the Lexer/cpplib area:
1) Change the way of file
As some of you know, Cirrus is now out of the ARM business,. Officially
April 1st. (No joke). We still have however arm.cirrus.com.
The forum will be locked, but remain for the information in it.
The site will remain. I am now doing Linux ALSA/SoC work for our low
power audio codecs. I have
Nils Pipenbrinck [EMAIL PROTECTED] writes:
Most of the stuff I write is performance critical, and I always find
myself in the same situation: I spend counter less hours to unswitch
loops by hand because the built-in loop unswitcher is not always smart
when multiple variables can be
Robert Millan wrote:
Hi Ian,
On Sat, Mar 29, 2008 at 07:28:19PM -0700, Ian Lance Taylor wrote:
However, I think a C# frontend would be too much work for one student
during the summer.
Do you think it can be broken down? My understanding of compilers is very
narrow (although I
On 3/30/08, Brian Austin [EMAIL PROTECTED] wrote:
I am now doing Linux ALSA/SoC work for our low power audio codecs.
Good luck, look forward to using them... :)
I have been given the freedom with this new
position to allow access to this machine for outside people to
contribute whatever
There are issues of Garbage Collection from libgcc or Boehms's GC
that you possibly can't use another allocators that these defaults,
unless you have control of the manager of the whole memory,
and it's too complex due to the gigant size of the project.
[EMAIL PROTECTED]:~/gcc/src/include$
On Sat, Mar 29, 2008 at 11:35:18PM +0900, zio wrote:
Dear GCC developers:
Hi, My name is Jiho Chu. I had ported ZARAM compact DSP16(www.zaram.com)
architecture to the GCC 3.4.5.
I added some machine description files, and modified several source codes in
gcc/ folder.
I think that these
On Fri, Mar 28, 2008 at 7:17 AM, Kai Tietz [EMAIL PROTECTED] wrote:
Hello,
This testcase seems to be broken, because it will fail everytime for the
static variable x. gcc detects, that this static variable has no reference
and will produce a warning.
gcc.c-torture/compile is compiled with
There are issues of Garbage Collection from libgcc or Boehms's GC
Two mistakes in one line. Congratulations J.C. for confusing a
prospective GSoC contributor.
So far your messages were just useless and decreasing signal-to-noise
ratio. Now you've escalated to actually damaging activity.
On Sun, 30 Mar 2008 13:45:30 +0100, Martin Guy [EMAIL PROTECTED]
said:
Ok, so we all have dozens of these EP93xx ARM SoCs on cheap boards,
with unusable floating point hardware.
What do we have to do to get the best-working GCC support for Maverick
Crunch FPU?
Suggest: make open-source
--- Comment #53 from ebotcazou at gcc dot gnu dot org 2008-03-30 09:15
---
I should have been more careful, there are wrong premises:
Yes. Amazing, isn't it ;) The important thing to keep in mind is that
all target variables must be in the range 10..20, and all source
variables
--- Comment #3 from pcarlini at suse dot de 2008-03-30 09:24 ---
This is tightly coupled to libstdc++/35353: in the current design, when
sync_with_stdio is false (by default), the stream is non-converting and synced
with C stdio, simply forwards to stdio functions. Unfortunately, the
--- Comment #3 from pcarlini at suse dot de 2008-03-30 09:27 ---
Really, this is a WORKSFORME, code in Comment #2 is fine everywhere.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2008-03-30 12:40 ---
This one should be straightforward, if lengthy to correct:
gfc_trans_where_2 is completely correct, as can be verified by doubling up the
line making the assignment in the WHERE block. ie:
WHERE (LDA)
As I understand the gfortran docs, the -ff2c/-fno-f2c switches change how
functions returning complex numbers are implemented:
-ff2c: the return value is returned in an additional argument as g77 and other
fortran compilers do it (can be seen e. g. in
http://www.pgroup.com/doc/pvfug.pdf, chapter
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-30 13:34
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-30 13:40 ---
CLOSED AS INVALID.
return type of complex functions not C compatible
While (with the default options) Fortran should be compatible with C in this
case, the proper way would be to use Fortran 2003's BIND(C)
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-30 13:51 ---
-ff2c: the return value is returned in an additional argument as g77 and other
fortran compilers do it
I want to point out that all? modern compiler use the -fno-f2c scheme which is
compatible with the default
In C++, when theres a class with multiple inheritance and one wants to cast a
pointer to it to the type of a base class which is not the first in the list,
like in this code:
class D: public B1, B2 { . . . };
D* d = get_some_D_possibly_NULL();
B2* b = d;
the pointer must be offset according to
--- Comment #4 from pault at gcc dot gnu dot org 2008-03-30 14:14 ---
Subject: Bug 35740
Author: pault
Date: Sun Mar 30 14:13:21 2008
New Revision: 133729
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133729
Log:
2008-03-30 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #54 from baldrick at gcc dot gnu dot org 2008-03-30 14:14
---
Here's a test that VRP is not eliminating
validity checks. abort should be called
if either X or Y is = 0. With Richard's
latest patch (from the gcc mailing list)
applied, everything is fine: the tests are
--- Comment #55 from baldrick at gcc dot gnu dot org 2008-03-30 14:18
---
And here's a testcase that was supposed to check that
VRP is not removing checks that array accesses are in
range. Instead it shows that the Ada f-e is failing
to generate checks at all!
function Overflow (X :
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-30 14:23 ---
Subject: Bug 35740
Author: pault
Date: Sun Mar 30 14:23:10 2008
New Revision: 133730
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133730
Log:
2008-03-30 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-30 14:25 ---
Fixed on trunk and 4.3. Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #56 from baldrick at free dot fr 2008-03-30 14:26 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
What does must be in the range mean? Firstly, the program behaviour is
undefined if a variable is outside its range.
That's not true. The reference
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-30 14:45
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #57 from rguenther at suse dot de 2008-03-30 14:52 ---
Subject: Re: VRP fails to eliminate range checks
in Ada code
On Sun, 30 Mar 2008, baldrick at gcc dot gnu dot org wrote:
--- Comment #55 from baldrick at gcc dot gnu dot org 2008-03-30 14:18
---
And
--- Comment #58 from rguenth at gcc dot gnu dot org 2008-03-30 14:55
---
Btw, can we have those testcases in gnat.dg/ with a name I can remember
(bounds-N.adb or similar)? Looking for testcases in acats is no fun ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-30 14:57 ---
Subject: Bug 31023
Author: rguenth
Date: Sun Mar 30 14:56:28 2008
New Revision: 133731
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133731
Log:
2008-03-30 Richard Guenther [EMAIL PROTECTED]
PR
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #59 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:03
---
And here's a testcase that was supposed to check that
VRP is not removing checks that array accesses are in
range. Instead it shows that the Ada f-e is failing
to generate checks at all!
Even with -gnato?
--- Comment #60 from rguenth at gcc dot gnu dot org 2008-03-30 15:09
---
function overflow (x : positive) return integer is
y : positive;
a : static array (1 .. 16#7FFF_#) of integer;
pragma import (ada, a);
begin
R4b : constant long_long_integer := long_long_integer?(a
--- Comment #61 from baldrick at free dot fr 2008-03-30 15:16 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
And here's a testcase that was supposed to check that
VRP is not removing checks that array accesses are in
range. Instead it shows that the Ada f-e is
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 15:33 ---
I also see this failure on powerpc-darwin after changing MOVE_RATIO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
--- Comment #62 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:45
---
Yes, even with -gnato. With -gnato it checks that the
addition doesn't overflow.
Oh, sorry, I thought we were talking about the overflow check...
But there are no checks on the array access. It looks like
--- Comment #63 from rguenther at suse dot de 2008-03-30 15:56 ---
Subject: Re: VRP fails to eliminate range checks
in Ada code
On Sun, 30 Mar 2008, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #62 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:45
---
Yes,
--- Comment #64 from baldrick at free dot fr 2008-03-30 16:02 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
But there are no checks on the array access. It looks like the f-e
doesn't generate them in the first place (as opposed to fold or gigi
making a
--- Comment #65 from ebotcazou at gcc dot gnu dot org 2008-03-30 16:15
---
So even GNAT assumes parameter values are in-range? Wouldn't that
cause an bounded error to become an unbounded error if it were
out-of-range?
GNAT considers that it's an unbounded error in a few specific
--- Comment #66 from ebotcazou at gcc dot gnu dot org 2008-03-30 16:18
---
Consider the following test case:
procedure Overflow (X : Positive) return Integer is
A : array (Positive) of Integer;
pragma Import (Ada, A);
begin
A (X) := X;
end;
(for which no checks are
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-03-30 16:36 ---
Related program, which also fails (I thought we fixed this; this seems to be a
libgfortran problem):
integer xda(20)
integer, volatile :: n
n = 1
print *, size(XDA(n:2:-3)) ! should
bash-3.2$ cat x.c
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
__m128 __attribute__((noinline))
iszero (__m128 x)
{
return x;
}
typedef __m128 __attribute__((aligned(1))) unaligned;
__m128 __attribute__((noinline))
foo (__m128 a1, __m128 a2, __m128 a3, __m128
--- Comment #67 from baldrick at free dot fr 2008-03-30 17:03 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
Try first to compile it. :-)
I did! I didn't notice the compile error
after the -gnatG output. Indeed, when fixed
thusly
procedure Overflow (X :
This is the cutest web site I've ever seen. It has puppies, miniature
schnauzers!
If you like dogs, take a look at this site. I'm posting this web site to
this group for my friends to get. Sorry if you got it and didn't want it.
I'm trying to get my friend in Germany this web site.
Executing on host: /home/dave/gnu/gcc-4.4/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4.4/objdir/gcc/ -O0 -w -fno-show-column -c -o
20010226-1.o /home/dave/gnu/gcc
-4.4/gcc/gcc/testsuite/gcc.c-torture/compile/20010226-1.c(timeout = 300)
--- Comment #14 from dje at gcc dot gnu dot org 2008-03-30 19:31 ---
Any progress on the regressions caused by the patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-30 20:00 ---
No feedback in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2005-09-24 17:07:47 |2008-03-30
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-30 20:04 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-30 20:04 ---
This works for me and many others so closing as worksforme.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35019
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.2 |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 20:12 ---
This works for me with 4.2.0, 4.3.0 and the trunk on i686-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35676
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:12 ---
I see them also on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-30 20:19 ---
Using a sysroot or setting --prefix for both the newlib build and the GCC build
is the easiest way of getting a cross build to work.
Anyways here are the options I use to build a cross build for spu:
stage1
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:23 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-03-30 20:26
---
Closing as invalid. Just like any other linking of shared libraries, you need
the correct LD_LIBRARY_PATH set or use static library versions.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-30 20:28 ---
What do you mean by preprocessed source.?
Please http://gcc.gnu.org/bugs.html which explains that.
Also it might be best if you try a newer version of GCC since 3.4.x is no
longer being maintained.
--
pinskia
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35706
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35714
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-03-30 20:42 ---
I'd expect the warning to be muted in one of the calls, depending on
-f{un}signed-char.
No, char is a seperate type from signed char and unsigned char so they are
always incompatiable when it comes to pointers to
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-03-30 20:45 ---
With -Wextra (aka -W), we get a warning now:
t.cc:1: warning: type qualifiers ignored on function return type
So closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
The following (silly) program gives an incorrect error message.
There is only one assignment to each diagonal element of
the array. I don't feel strongly about this because FORALL
is sort of a junk feature and this is an unlikely programming
style. But, to be correct you should downgrade from
--- Comment #3 from Georg dot Baum at post dot rwth-aachen dot de
2008-03-30 20:48 ---
Thanks for the quick reply. You where right, I mixed up the FF2C macro in the
test case. Unfortunately this was not the real problem. The problem I had in my
code was that calling BLAS zdotc from C++
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:50 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:52 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:54 ---
Confirmed, it has been failing since at least 4.2.0 20061019 .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:56 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:57 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 21:08 ---
Confirmed, as noted by Uros, you should submit the patch to [EMAIL PROTECTED]
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The program gives an error message when the internal
function has an apparent character type due to the implicit
statement. Commenting out the implicit fixes it. This
looks similar to 34784 to me.
program SA0021
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35611
--- Comment #3 from hjl at gcc dot gnu dot org 2008-03-30 21:14 ---
Subject: Bug 35757
Author: hjl
Date: Sun Mar 30 21:13:33 2008
New Revision: 133736
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133736
Log:
gcc/
2008-03-30 H.J. Lu [EMAIL PROTECTED]
PR target/35757
--- Comment #4 from burnus at gcc dot gnu dot org 2008-03-30 21:18 ---
Not all. I gave two counter examples: pvf and ifort.
Well at least ifort 9.1, 10.0 and 10.1 on Linux do not use the f2c calling
convention. Neither does NAG f95. But I agree that _ vs __ and different
calling
--- Comment #3 from petrosyan at gmail dot com 2008-03-30 21:23 ---
I posted the patch to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01639.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35614
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-30 21:27 ---
Confirm. I agree that it is valid (although bad style) code.
I think there should be no warning printed if a index-name is used in the
scalar-mask-expr. Otherwise, if it is neither used in the scalar-mask-expr nor
--- Comment #5 from hjl dot tools at gmail dot com 2008-03-30 21:28 ---
The updated patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01916.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-30 21:38 ---
(In reply to comment #1)
Note: PR 34784 contains a failure which was missed.
Actually, the test case in PR 34784, comment 8 now passes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35770
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-30 21:34 ---
Confirm. Implicit typing is too fast. It is quite similar to PR 34784.
Note: PR 34784 contains a failure which was missed.
A procedure question. Is this the One True Way to add additional
comments or tests
--- Comment #9 from burnus at gcc dot gnu dot org 2008-03-30 21:37 ---
(reply to comment #8)
I have another example of what might be the same problem, although the
symptoms are a little different.
This test case seems to work meanwhile (both in gfortran 4.3.0 and 4.4.0, it
fails in
--- Comment #10 from kst at mib dot org 2008-03-30 21:49 ---
(In reply to comment #9)
I'd expect the warning to be muted in one of the calls, depending on
-f{un}signed-char.
No, char is a seperate type from signed char and unsigned char so they are
always incompatiable when it
--- Comment #6 from schwab at suse dot de 2008-03-30 21:58 ---
Fixed.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-30 21:59
---
Subject: Bug 35748
Author: reichelt
Date: Sun Mar 30 21:58:43 2008
New Revision: 133737
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133737
Log:
PR c/35748
* c-typeck.c (build_c_cast):
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-03-30 22:02
---
Subject: Bug 35578
Author: reichelt
Date: Sun Mar 30 22:02:06 2008
New Revision: 133738
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133738
Log:
PR c++/35578
* parser.c
--- Comment #4 from hjl dot tools at gmail dot com 2008-03-30 22:04 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-03-30 22:08
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-03-30 22:09
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Call expander ignores type alignment. But caller honors type alignment.
It usually isn't a problem until the argument is passed via stack. We
have a mismatch between caller and callee:
bash-3.2$ cat x.c
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
__m128
GCC compiles the code below without any error:
//--
class A {
protected:
virtual void foo() const = 0;
};
// Defining pure virtual functions should not be allowed.
void A::foo() const
{
}
//--
--
Summary: GCC allows
--- Comment #3 from yuriry at gmail dot com 2008-03-30 22:29 ---
I believe that the main problem here is that GCC allows defining pure virtual
functions. The compiler should report an error when these two functions are
defined:
//
void
--- Comment #3 from schwab at suse dot de 2008-03-30 22:36 ---
Not a bug.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #15 from eric dot weddington at atmel dot com 2008-03-30 22:40
---
FWIW, test case passes for avr-*-* target version 4.3.0 -O[0123s]
-frtl-abstract-sequences
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #2 from schwab at suse dot de 2008-03-30 22:41 ---
Not reproducible, assuming fixed.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2008-03-30 22:44 ---
*** Bug 35454 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
1 - 100 of 115 matches
Mail list logo