--- Comment #5 from rob1weld at aol dot com 2007-05-26 05:28 ---
Is this related to 31741 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32065
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-26 03:30 ---
Subject: Bug 32090
Author: pinskia
Date: Sat May 26 03:29:58 2007
New Revision: 125087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125087
Log:
2007-05-25 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-26 03:29 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
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=30690
--
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=32007
--
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=32027
--
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=31994
On Fri May 25 2007 Jerry DeLisle wrote:
> Roland Winkler wrote:
> > The (shortened) fortran-77 subroutine attached below causes a
> > segmentation fault of g77 when I execute
> >
> > $ g77 -O3 -c -funroll-loops foo.f
> >
> > No problems occur without optimization.
> >
> > $ g77 --version
> > GN
--
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=31930
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|4.0.0 |4.0.0 4.2.1
Target Milestone|--- |4.1.3
h
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|3.4.6 |3.4.6 4.2.1
Target Milestone|--- |4.1.3
h
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31022
--
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=31052
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
--
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=12963
--
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=31585
--
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=31989
--
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=31628
--
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=30486
--
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=31424
--
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=31427
--
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=31216
--
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=31194
--
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=30881
--
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=18769
--
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=32047
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2007-05-26
02:43 ---
>From http://gcc.gnu.org/viewcvs?view=rev&revision=125032, it appears that
libjava/libltdl was omitted from the regeneration as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
Roland Winkler wrote:
The (shortened) fortran-77 subroutine attached below causes a
segmentation fault of g77 when I execute
$ g77 -O3 -c -funroll-loops foo.f
No problems occur without optimization.
$ g77 --version
GNU Fortran (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright (C) 2002
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-05-26 01:05
---
I will see if i cna do something here.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
The (shortened) fortran-77 subroutine attached below causes a
segmentation fault of g77 when I execute
$ g77 -O3 -c -funroll-loops foo.f
No problems occur without optimization.
$ g77 --version
GNU Fortran (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright (C) 2002 Free Software Foundation
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-26 00:35 ---
Failure was introduced between 2007-04-04-r123491 and 2007-04-11-r123712
My guess would be that it is the following patch:
r123641 | pault | 2007-04-07 22:13:52 +0200 (Sa, 07 Apr 2007) | 14 lines
2007-04-07 Paul Th
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-25 23:39
---
This does not ice with 4.1 or 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-25 23:38 ---
I have a fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-05-25 23:36
---
Further reduced case:
subroutine dummy
contains
function quadric(a,b) result(c)
dimension a(0:3),b(0:3),c(0:9)
c(0)=1.1
end function
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32088
--- Comment #159 from ian at airs dot com 2007-05-25 23:21 ---
Created an attachment (id=13613)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13613&action=view)
Patch
This version of the patch is based on some code from Daniel Berlin. Here we
determine which pointers can potentia
--- Comment #2 from mckelvey at maskull dot com 2007-05-25 23:03 ---
Here is how I compile it:
/usr/local/bin/g++ -c -O3 -DNDEBUG -Wuninitialized -pedantic-errors -Werror
-Winline -ansi -fno-common -Wall -Wold-style-cast -Wsign-promo -Wpointer-arith
-Wundef -Wwrite-strings -Winvalid-p
--- Comment #4 from ubizjak at gmail dot com 2007-05-25 22:39 ---
Fixed on mainline.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from uros at gcc dot gnu dot org 2007-05-25 22:36 ---
Subject: Bug 32065
Author: uros
Date: Fri May 25 22:36:10 2007
New Revision: 125077
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125077
Log:
PR target/32065
* target/i386/i386.c (ix86_expand_v
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-25 22:32 ---
This is obviously caused by:
2007-05-25 Richard Guenther <[EMAIL PROTECTED]>
PR tree-optimization/31982
* tree-ssa-forwprop.c
(forward_propagate_addr_into_variable_array_index): Handle arra
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-25 22:30 ---
First the deconstructor was either defaulted to inline or marked as such.
Second what are the full options do you use?
If the call is unlikely (which it says in your case), then there is no reason
to inline it. I b
--
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=32090
C++ testcase:
struct JArray
{
int data[0];
};
int copyIntoByteArray (struct JArray *dest, int offset)
{
void *pdest = dest->data + offset;
}
- cut ---
backtrace:
#0 0x08d6a47c in integer_onep (expr=0x0) at
/home/apinski/src/gcc-fsf/bugfixes/gcc/gcc/tree.c:1311
#1 0
CircularlyReferenceable.cc:76: error: called from here
/usr/local/lib/gcc/alphaev56-unknown-linux-gnu/4.3.0/../../../../
include/c++/4.3.0/bits/stl_multiset.h:91: error:
inlining failed in call to 'std::multiset,
std::allocator >::
~multiset()': call is unlikely
CircularlyReferenceable.cc:76: err
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32088
C:\mingw\bugs>type bug.f90
subroutine dummy
contains
function quadric(a,b) result(c)
intent(in) a,b; dimension a(0:3),b(0:3),c(0:9)
c(0)=a(0)*b(0); c(1:3)=a(1:)*b(0)+a(0)*b(1:); c(4:6)=a(1:)*b(1:)
c(7:9)=(/a(1)*b(2)+b(1)*a(2),a(1)*b(3)+b(1)*a(3),a(2)*b(3)+b(2)*a(3)/)
end function
end
The following program will ICE when compiled with -O2 -fprefetch-loop-arrays on
a x86_64 box or on IA64 box (Linux and/or HP-UX in 64 bit mode).
scale_bbs_frequencies_int is called with nbbs=1, num=0, and den=0. Since we do
a division by den, the compiler aborts during the division. If we give X
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-25 21:11 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #5 from tromey at gcc dot gnu dot org 2007-05-25 21:05 ---
Thanks for your response.
Closing as fixed in 4.2.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-05-25 20:36 ---
(In reply to comment #5)
> Of course people are complaining that min/max as of IEEE does not propagate
> NaNs
> as other operations do.
We could add flags like -fpropagate-nan, -fno-propagate-nan
and -fdontcare-prop
--- Comment #4 from steven at gcc dot gnu dot org 2007-05-25 20:35 ---
Something in the backward pass increases the register pressure, inducing extra
spills. Not much can be done about this except for tuning the transformations
involved.
--
steven at gcc dot gnu dot org changed:
--- Comment #3 from simartin at gcc dot gnu dot org 2007-05-25 20:33
---
Fixed on the mainline.
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #22 from steven at gcc dot gnu dot org 2007-05-25 20:32 ---
With the current implementation of SEE it is almost impossible to make it work
on x86. You have to take into account the liveness of the flags register, and
there currently is no way to include that in the dataflow
--- Comment #2 from simartin at gcc dot gnu dot org 2007-05-25 20:27
---
Subject: Bug 31745
Author: simartin
Date: Fri May 25 20:26:36 2007
New Revision: 125070
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125070
Log:
2007-05-25 Simon Martin <[EMAIL PROTECTED]>
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2007-05-25 19:50
---
Is this still broken or can we close? I would like to fix this if possible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
--- Comment #4 from rob1weld at aol dot com 2007-05-25 19:12 ---
Tom, here are the results you requested:
...
touch resources
make[4]: Leaving directory
`/opt/gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/lib'
Making all in doc
make[4]: Entering directory
`/opt/gcc-4_3-build/i686-p
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-05-25 17:55 ---
Fixed on mainline.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-05-25 17:55 ---
Fixed on mainline.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-05-25 17:54 ---
Fixed on mainline.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-05-25 17:54 ---
Fixed on mainline.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-05-25 17:54 ---
Fixed on mainline.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-05-25 17:54 ---
Fixed on mainline.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-05-25 17:53 ---
Fixed on mainline.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-05-25 17:53 ---
Fixed on mainline.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-25 17:43
---
Closing. Added the following comment to transfer.c:
/* Master function for unformatted writes. NOTE: For kind=10 the size is 16
bytes on 64 bit machines. The unused bytes are not initialized and never
us
--- Comment #6 from pcarlini at suse dot de 2007-05-25 17:39 ---
Nevermind: that scenerio is illegal anyway, of course. I think I will just try
to implement what you suggested on libstdc++ some time ago...
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #5 from pcarlini at suse dot de 2007-05-25 17:12 ---
(In reply to comment #2)
> I don't think support for C++0x precludes support for TR1. They coexist very
> well, especially because TR1 was designed to be compatible with C++0x. For
> example, C++0x-conforming implementation
The program induct.f90 of the Polyhedron testsuite,
http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html, runs about
10% slower under 4.3 than under 4.1.3 (20070430 prerelease SUSE Linux).
A cut-down testcase "test2.f90 (attachment 13611 of PR 32084) shows the same
result. At least for
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-25 16:51 ---
First the operator delete you created is overriding the normal operator delete
(which is valid).
Second you don't know the real type when deleting void* so it is hard to figure
out if we should warn or not.
--
h
--- Comment #2 from andrew dot stubbs at st dot com 2007-05-25 16:16
---
I'm confused.
It might be the case that there is a type for which this warning is valid - I
don't know C++ well enough to confirm or deny that - but in *this* example, and
perhaps others like it, the warning is mi
--- Comment #6 from rob1weld at aol dot com 2007-05-25 15:59 ---
After winding up and down, back and forth through what seems to be a couple of
forks of discussion, I found a couple of different answers ...
The above comment means that the "References:" section at the bottom of the
post
--- Comment #5 from nathan at gcc dot gnu dot org 2007-05-25 15:40 ---
This looks like it might be the same as this one
http://sourceware.org/ml/newlib/2007/msg00425.html
Anyone able to try that patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
--- Comment #4 from rob1weld at aol dot com 2007-05-25 15:39 ---
>> Andrew Pinski 2007-05-25 15:17
>> Do either of you read the list?
I search the Internet and use the search page at http://gcc.gnu.org/bugzilla
before I post a bug. I try to avoid dupes and look for fixes.
There may we
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-25 15:37 ---
No, even then it is still undefined because you don't call the deconstructor
for non-PODs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32085
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-25 15:17 ---
Do either of you read the list?
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01665.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-25 14:54 ---
Using the GCC 4.1.3 20070430 which comes with openSUSE Factory and contains
some patches from 4.2/4.3, I get the following timings:
$ gfortran-4.1 -march=opteron -ffast-math -funroll-loops -ftree-vectorize
-ftree-loo
--- Comment #2 from ubizjak at gmail dot com 2007-05-25 14:53 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01716.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
void
operator delete(void *p)
{
}
void
foo ()
{
void *p = new int;
delete p;
}
t.cxx: In function int main():
t.cxx:13: warning: deleting void* is undefined
Oh yes it - I just defined it!
It might be nice if the compiler checked before warning :)
--
Summary: "warning: dele
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-25 14:25 ---
Created an attachment (id=13611)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13611&action=view)
test case, 395 lines; based on Polyhedron's induct.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
gfortran seemingly generates an significatly inferior internal TREE
representation than g95 as for Polyhedron's induct.f90 gfortran is 18% slower
than g95, which is based on GCC 4.0.3. (Compared with other compilers the
difference is even larger.)
(GCC 4.3 is in general faster than GCC 4.1; for in
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:16 ---
Subject: Bug 31444
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31443
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-05-25 14:16 ---
Subject: Bug 31445
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31442
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31434
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31435
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31438
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31437
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31432
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31431
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125062
Log:
2007-05-25 Douglas Gregor <[EMAIL PROTECTED]>
PR c+
--- Comment #15 from richard at codesourcery dot com 2007-05-25 14:13
---
Subject: Re: [4.3 Regression] segfault in try_split on mips during bootstrap
David, msny thanks for looking at this.
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> RS6000, ia64, and sh does this
--- Comment #2 from manu at gcc dot gnu dot org 2007-05-25 14:05 ---
(In reply to comment #0)
> While this is "trivial" we should have pride in our great compiler and the
> usually great results. Even if there are failures we should still present them
> neatly.
If it is trivial, then ju
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-05-25 13:55
---
Rev. 124497 of mainline fails to bootstrap with these patches on i686-linux:
[during stage2]
../../../trunk3/gcc/df-scan.c: In function df_ref_record:
../../../trunk3/gcc/df-scan.c:1057: error: types mismatch
--- Comment #2 from hjl at lucon dot org 2007-05-25 13:31 ---
I saw it with revision 125032 on a quad-core Linux/x86-64 with "make -j4".
--
hjl at lucon dot org changed:
What|Removed |Added
--
--- Comment #27 from paul_m_doc at hotmail dot com 2007-05-25 13:11 ---
(In reply to comment #26)
> *** Bug 32058 has been marked as a duplicate of this bug. ***
Sigh :(. The response at the October 2006 to DR 577 is enough to make any
template meta-programmer bang their head against th
--- Comment #2 from jakub at gcc dot gnu dot org 2007-05-25 12:39 ---
I'm not sure we want to work around here though. Static const variable
initialized during __static_initialization_and_destruction shouldn't have
TREE_READONLY set, because the variable isn't really unchanging.
This is
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-25 12:37 ---
This is a regression with regard to 4.2.0.
Brooks, you were looking for transfer regressions, weren't you?
(Just for completeness, 2007-05-15 r124736 is working, 2007-05-16 r124759 is
failing.)
--
burnus at gcc d
--- Comment #13 from bero at arklinux dot org 2007-05-25 12:24 ---
yes, assignment is in place, and yes, the peers are somewhat buggy. But I think
that's in part because nobody (at least in the gcj community) is testing/fixing
them because they don't build without trickery.
--
http:
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-05-25 11:45 ---
Shortened testcase to compare variable vs. parameter in tree dump:
$> cat pr32083.f90
PROGRAM TestInfinite
integer(8), parameter :: bit_pattern_NegInf_i8_p = -4503599627370496_8
integer(8) :: bit_pattern_NegInf_
1 - 100 of 120 matches
Mail list logo
