--- Comment #13 from daney at gcc dot gnu dot org 2007-05-25 08:16 ---
Created an attachment (id=13610)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13610&action=view)
Proposed patch.
I will bootstrap and test the attached patch. It allows my cross build to
complete.
--
dane
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-05-25 08:32
---
RS6000, ia64, and sh does this:
/* Mark the end of the (empty) prologue. */
emit_note (NOTE_INSN_PROLOGUE_END);
You might want to use that note also for MIPS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-25 09:31 ---
Works for me since today.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
: internal compiler error: Segmentation fault
This is with http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html
This is on x86_64-unknown-linux-gnu with gcc-Version 4.3.0 20070525.
Working with: 2007-05-17
Failing since: 2007-05-18
--
Summary: [Regression 4.3] Profil
Two problems - the second one is months old and affects 4.2.0 4.2.1 4.3.0
1) Make breaks due to "configure: error: `CXXFLAGS' has changed since the
previous run:"
This did not happen yesterday, or the day before, ...
2) When make breaks (for _any_ reason, including the prior one) while build
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-25 09:53 ---
Zdenek, I think your patch caused the ICE, could you have a look?
http://gcc.gnu.org/ml/gcc-cvs/2007-05/msg00485.html
(Maybe I'm wrong about the patch, there were some other issues around that
time, which caused gas_
--- Comment #3 from rob1weld at aol dot com 2007-05-25 09:55 ---
Ran accros this interesting post, seems we've had this a while ...
gjdoc in libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19612
After some messing with trying to access the gjdoc SVN according to the above
advice fr
It should not be possible to jump into a function try-block.
The example from the standard, clause 15/2, is rejected properly:
void f() {
goto l1; // Ill-formed
goto l2; // Ill-formed
try {
goto l1;// OK
goto l2;// Ill-formed
l1: ;
} catch (...) {
l2: ;
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-25 10:36 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
The following C++ code should not compile:
template
void foo(T) throw (int);
template<>
void
foo (short) throw (short)
{
}
The change in exception specification, the throw, is not been detected. A
simple example without templates is rejected correctly.
The C++ standard discusses this in clause
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-25 10:39 ---
This is undefined. You dereference *pp before checking if it is a NULL
pointer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-25 10:07 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-25 10:07 ---
Fixed.
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-25 10:07 ---
Subject: Bug 31982
Author: rguenth
Date: Fri May 25 09:07:29 2007
New Revision: 125058
URL: http://gcc.gnu.org/viewcvs?root=
below c code will get "false" at -O0, -O1, -O3,
and get "true" at -O2, -Os.
#include
typedef struct {
int aa;
int bb;
} test;
//test t1;
void foo (test **pp)
{
if (((*pp)->bb != 0) && (*pp))
printf ("true\n");
else
printf ("false\n");
printf ("finished.
--- Comment #27 from markus dot duft at salomon dot at 2007-05-25 10:30
---
(In reply to comment #25)
> Created an attachment (id=12808)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12808&action=view) [edit]
> patch (part 2 of 2) to fix this bug
> This patch (mh-interix.diff) and
--- Comment #1 from rob1weld at aol dot com 2007-05-25 10:49 ---
Found an additional problem.
After all the stages are done and we are building the libraries in the "target
name directory" (EG: in _my_ case the directory is called "i686-pc-linux-gnu")
we must _always_ use "xgcc" and NOT
--- Comment #4 from deknuydt at esat dot kuleuven dot be 2007-05-25 11:12
---
(In reply to comment #3)
> Unless you need 4.1 and plan to work on this bug, I would like to close it.
> What do you think?
Just close it. 4.2.0 seems okay to me.
--
http://gcc.gnu.org/bugzilla/show_bug.
ameter transfers
i = 9218868437227405312
r =+Infinity
i = 9218868437227405312
i = -4503599627370496
r =+Infinity
i = 9218868437227405312
12:11pm bhw034 73 >
The gfortran version used for testing was:
gfortran -v
Using built-in specs.
Target: i386
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-25 11:21 ---
Indeed with -fno-tree-ccp the testcase is optimized by forwprop1 to
:
D.2000_3 = i_2(D) * 4;
D.2001_4 = (int *) D.2000_3;
D.2002_5 = &b.t[i_2(D)];
*D.2002_5 = 1;
return;
and then by forwprop2 to
:
D.20
--- Comment #1 from andrew dot stubbs at st dot com 2007-05-25 11:21
---
This problem may also be observed in explicit instantiation:
template
void
foo (T) throw (int)
{
}
template
void foo (short) throw (short);
There are also similar issues with declarations of pointers to functi
--- 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_
--- 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 #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 #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 #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 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 #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 #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
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 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
--- 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 #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 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 #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 #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 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 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 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+
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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: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 #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 #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 #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 #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 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
--
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 #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
--- 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 #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 #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 #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
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
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32088
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
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
--
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
--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
-
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 #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
--
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
--
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=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=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=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=31427
1 - 100 of 120 matches
Mail list logo
