--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-10-22 06:45
---
> The test case that has been attached shows a FORTRAN and Ada program that are
> equivalent (within their matrix multiply loop). The Ada one runs about 2x
> slower with about 3x the number of machine instructions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-22 05:40 ---
This is invalid code as the operator++ in B hides both operator++.
In the same way, the following code is also invalid:
struct A {
const A& f(int) { return *this; }
virtual const A& f() = 0;
};
struc
an error occur when mixing non virtual post increment operator
with virtual pre increment operator
$ cat test.cpp
struct A {
const A& operator ++ (int) { return *this; }
virtual const A& operator++() = 0;
};
struct B : public A {
virtual const A& operator++() { return *th
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-22 05:01 ---
I have a general fix, in place of that of #1, more or less working. It'll be a
day or two yet before it's ready for exposure.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-10-22 04:59
---
Technically, I think it would be feasible to backport the patch. However,
because that patch eliminates a GNU extension we would change the set of
programs accepted on the 4.1 branch. I'm not sure that's a good
--- Comment #14 from pault at gcc dot gnu dot org 2006-10-22 04:47 ---
> (from PR29489)
>
Thanks FX, I forgot all about it.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
--- Comment #6 from daney at gcc dot gnu dot org 2006-10-22 04:11 ---
Created an attachment (id=12474)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12474&action=view)
Potential fix.
As per Richard's analysis, I am testing this patch. It seems to fix the
testcase. I will bootstr
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-22 03:01 ---
I am going to fix it via the configure option, for the mainline I am going to
recommend to also add rtl checking for stage1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-22 02:40 ---
I think there are two ways of fixing this is do --enable-checking=yes for
stage1 gcc configuring or the way 4.1 does it via CFLAGS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29544
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-22 02:29 ---
In 4.2 and above:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
Target Milestone|---
In 4.1 (and maybe even 4.0), we used to build with checking enable in stage1 to
check some bugs but now with the toplevel bootstrap, this no longer happens.
--
Summary: [4.2 Regression] Not building with checking in stage1
Product: gcc
Version: 4.2.0
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-22 02:23 ---
But the real problem is that IV-opts does not know how to handle non-constant
array sizes and bounds.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-22 02:20 ---
Well actually Fortran front-end flattens the arrays which causes the
difference. In fact the Fortran front-end is incorrect in flattening it for
reasons of debugging.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from jeff at thecreems dot com 2006-10-22 02:02 ---
Created an attachment (id=12473)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12473&action=view)
Source code and very simple build script for Ada and FORTRAN code capable of
showing poor tree and runtime performanc
I understand comparing very very small benchmarks like this can be misleading
but I believe I've looked at this enough to have a sense that it is
demonstrating a basic truth and not a narrow performance issue.
The test case that has been attached shows a FORTRAN and Ada program that are
equivalent
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-10-22 00:09
---
Created an attachment (id=12472)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12472&action=view)
A prelimary patch as one concept for handling this
This patch gives a good result for error messages. Howev
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 23:04 ---
Your code is incorrect, you cannot bind a rvalue to a (non-const) reference.
The way to fix it is do:
friend ostream &operator <<(ostream &, const test &);
ostream &operator <<(ostream &out,
--
#include
using namespace std;
class test
{
friend ostream &operator <<(ostream &, test &);
friend test operator ++(test &, int);
public:
test(
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 22:07 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-21 22:04 ---
First, I agree there is a bug because gfortran should not have an
ICE. However, I believe the code is invalid. The Fortran 95
standard specifically mentions "named common blocks" in the
description of "block data".
--- Comment #7 from tromey at gcc dot gnu dot org 2006-10-21 21:49 ---
I'm going to close this as fixed.
Thanks Gerald.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-21 21:34 ---
Mine, this bug is easy to fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-21 21:26 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 21:25 ---
Confirmed.
There was talking about this on the mailing list but I cannot find it right
now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-10-21 21:24
---
(In reply to comment #18)
> I think we can declare this as fixed and open a new bug about 128bit long
> double and soft fp.
And the new bug is PR 29541.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25864
This is just a reminder that soft float and IBM long double support don't get
along on powerpc. This is a split off from PR 25864 really.
--
Summary: Enable IBM long double format in PowerPC Linux soft
float
Product: gcc
Version: 4.0.4
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-10-21 21:19
---
I think we can declare this as fixed and open a new bug about 128bit long
double and soft fp.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from igodard at pacbell dot net 2006-10-21 21:16 ---
Please forgive my naive understanding of the standard, but it was my impression
that the return type of a function never participated in overload resolution.
That is, for any given set of overloads and a call, the retu
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-10-21 21:03
---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-21 20:58 ---
*** This bug has been marked as a duplicate of 29512 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-10-21 20:58
---
*** Bug 24308 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-21 20:39 ---
Comeau online has the same issue:
"ComeauTest.c", line 3: error: name followed by "::" must be a class or
namespace
name... Wild guess: Did you #include the right header?
typedef typename TT::value_type
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-21 20:36 ---
My reduced testcase, you get the following error:
t.cc: In instantiation of a:
t.cc:11: instantiated from here
t.cc:3: error: float is not a class, struct, or union type
I don't see how this is the incorrect
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-21 20:27
---
It's convert.c:convert_to_real which does this. Should be easy to fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-21 20:24 ---
Fixed for 3.4.3 as reported in comment #4.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-21 20:23 ---
(In reply to comment #3)
> For the testcase in comment #2, on the mainline, we get a different error
> message:
That is the correct error so closing as fixed for 4.2.0 as friends don't inject
at all.
--
pinskia
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-21 20:21 ---
Confirmed, we should not be reordering unary minus with -frounding-math but we
are, even on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-21 20:17 ---
*** Bug 29538 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-21 20:17 ---
Though minus cannot change the rounding but the rounding mode can be different
for rounding from double to float in that we could have a negative number with
round towards zero which causes us to get different answer
--- Comment #4 from uros at gcc dot gnu dot org 2006-10-21 20:05 ---
Subject: Bug 28252
Author: uros
Date: Sat Oct 21 20:05:35 2006
New Revision: 117937
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117937
Log:
2006-10-21 Uros Bizjak <[EMAIL PROTECTED]>
PR middle-end
--- Comment #11 from uros at gcc dot gnu dot org 2006-10-21 19:27 ---
Subject: Bug 19398
Author: uros
Date: Sat Oct 21 19:27:02 2006
New Revision: 117935
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117935
Log:
PR target/19398
* config/i386/i386.md (fix_trunc?f
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot
|dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |normal
Target Milestone|4.2.0 |---
http://g
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|ice-on-invalid-code |
Target Milestone|--- |4.2.0
http://gcc.gnu
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29539
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-10-21 18:44
---
The wrapping check was added by:
http://gcc.gnu.org/ml/gcc-patches/2002-10/msg00360.html
I think this check is wrong for exactly the reason seen here;
without type information, and without context, there's no
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 18:41 ---
Those were not regressions at all. They were patches which had been approved
for 4.3 but Richard forgot to mark the bugs as blocking the 4.3 pending patches
bug.
--
pinskia at gcc dot gnu dot org changed:
With Mark Mitchel branching 4.2.0 of from trunk on 2006-10-20 it appears that
some regression patches, dated 2006-10-21 andreally destined for 4.2.0, ended
up in trunk only (e.g. six from Richard Guenther).
Perhaps administratively they could be back-ported from trunk to the 4.2.0
branch as they
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-21 18:19 ---
Unary negation does not affect rounding, so I fail to see how it shall matter
what type the negation is done on.
It is true that for x87 math the -(float)x sequence is slower:
g:
pushl %ebp
movl
According to lahey's web checker, this is legal code:
$ cat foo.f90
! { dg-compile }
! { dg-options "-W -Wall" }
block data
common /c/ d(5)
data d /5*1./
type c_t
sequence
integer i
end type c_t
type (c_t) :: cc ! bugger
end
end
It ICEs with 4.1.2 20060901 (prerelease).
bt w
--- Comment #3 from aldot at gcc dot gnu dot org 2006-10-21 18:05 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Shorter testcase:
> > $ egrep -v "(^\!|^$)" foo2.f90
> > block data
> > common c
> > end
> >
> According to lahey's checker, this code is valid. Still it ICEs
Testcase:
void f(float);
void g(double x) { f(-x); }
Using -fdump-tree-original shows that GCC understands the above code as
"f(-(float)x)", although it should really be "f((float)(-x))". As a
consequence, the generated code is not efficient (on x86), as GCC will have to
store x to memory as a flo
--- Comment #2 from aldot at gcc dot gnu dot org 2006-10-21 18:04 ---
(In reply to comment #1)
> Shorter testcase:
> $ egrep -v "(^\!|^$)" foo2.f90
> block data
> common c
> end
>
According to lahey's checker, this code is valid. Still it ICEs
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #1 from aldot at gcc dot gnu dot org 2006-10-21 17:42 ---
Shorter testcase:
$ egrep -v "(^\!|^$)" foo2.f90
block data
common c
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29537
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-21 17:39
---
Thomas, isn't the 4.3 branching a good time to work on this? Would you have
time for that?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from steven at gcc dot gnu dot org 2006-10-21 17:32 ---
Since this is not a regression in GCC 4.1, and because it will work in GCC 4.2,
I'm closing this as WONTFIX.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
$ cat foo.f90
! { dg-compile }
! { dg-options "-W -Wall" }
type a_t
sequence
integer i
end type a_t
block data bd
sequence
common c
type c_t
sequence
integer i
end type c_t
end block data bd
common /a_t/ c
end
$ gfortran-4.1 --version
GNU Fortran 95 (GCC) 4.1.2 20060901 (pre
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-21 17:30
---
It's an enhancement (and actually, it's being worked on).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-21 14:58 ---
Reduced testcase:
template struct SetRegion2D
{
struct FloodFillControl
{
struct Allocator{};
};
};
template
struct MotionSearcher {
typedef SetRegion2D Region_t;
MotionSearcher (typename Region_t::Fl
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-21 14:38 ---
Add
public:
typedef int Allocator;
to the SetRegion2D::FloodFillControl definition and it becomes
valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29535
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-21 14:34 ---
Created an attachment (id=12470)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12470&action=view)
unreduced testcase from mjpegtools
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29535
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-21 14:31 ---
The code provided here is not valid code at all.
With 4.0.4 and 4.2.0 before the patch I get:
t.cc: In instantiation of MotionSearcher::MatchThrottleFloodFillControl:
t.cc:58: instantiated from MotionSearcher
t
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-21 14:19 ---
Fixed right before the branch of 4.2 by:
2006-10-20 Daniel Berlin <[EMAIL PROTECTED]>
* tree.h (DECL_PTA_ARTIFICIAL): Remove.
(tree_decl_with_vis): Remove artificial_pta_var flag.
* tree-fl
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-21 13:50 ---
Caused by
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117695
Log:
PR c++/28506
* parser.c (function_declarator_p): New function.
(cp_parser_init_declarator): Use it.
(cp_par
./../.././gcc/gcjh -d . -classpath '' -bootclasspath classpath/lib $name
gnu/CORBA/DynAn/gnuDynAny.java: In class 'gnu.CORBA.DynAn.gnuDynAny':
gnu/CORBA/DynAn/gnuDynAny.java: In method
'gnu.CORBA.DynAn.gnuDynAny.get_any()':
gnu/CORBA/DynAn/gnuDynAny.java:0: internal compiler error: Segmentation fau
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-21 13:23 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-21 13:23 ---
Subject: Bug 3511
Author: rguenth
Date: Sat Oct 21 13:23:41 2006
New Revision: 117932
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117932
Log:
2006-10-21 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-21 13:21 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-21 13:21 ---
Subject: Bug 26898
Author: rguenth
Date: Sat Oct 21 13:21:06 2006
New Revision: 117931
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117931
Log:
2006-10-21 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-10-21 12:12 ---
Confirmed. Works with 4.2.
We endlessly fold
#5 0x08206aa1 in fold_unary (code=NEGATE_EXPR, type=0xb7c5c284,
op0=0xb7cd3258) at /home/richard/src/gcc-4_1-branch/gcc/fold-const.c:6876
#6 0x08212e3e in fold_bu
--- Comment #6 from gerald at pfeifer dot com 2006-10-21 11:28 ---
Thanks, Tom! I updated some packages I maintain and verified that this
indeed nicely fixes the problem.
As for GCC 4.1, as you say, I don't think it's strictly needed, though it
could be useful for some (using GCC 4.0 a
For the following testcase
typedef long unsigned int size_t;
typedef int int16_t __attribute__ ((__mode__ (__HI__)));
typedef int int32_t __attribute__ ((__mode__ (__SI__)));
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
template class Ident { };
template class Less { };
te
bash$ cat bug.c
int foo(int arr[]) {
int i = 2;
while (arr[--i]) ;
return i;
}
bash$ gcc -O -ftrapv -c bug.c
gcc: Internal error: Segmentation fault (program cc1)
bash$ g++ -O -ftrapv -c bug.c
g++: Internal error: Segmentation fault (program cc1plus)
Compilation succeeds if -O is removed. O
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-10-21 10:42
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-21 10:41
---
Subject: Bug 19116
Author: rguenth
Date: Sat Oct 21 10:40:57 2006
New Revision: 117930
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117930
Log:
2006-10-21 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-10-21 10:13
---
Subject: Bug 28796
Author: rguenth
Date: Sat Oct 21 10:13:13 2006
New Revision: 117928
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117928
Log:
2006-10-21 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-10-21 10:09
---
Fixed for 4.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-21 10:05
---
Subject: Bug 29512
Author: rguenth
Date: Sat Oct 21 10:05:21 2006
New Revision: 117927
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117927
Log:
2006-10-21 Richard Guenther <[EMAIL PROTECTED]>
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC|ebotcazou at gcc dot gnu dot|
|org |
Assigned
81 matches
Mail list logo
