--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-25 06:59 ---
Here is another testcase, this time Fortran:
SUBROUTINE PG3CL9 (NUMSEG)
PARAMETER (NPMAX = 5000,
+NDMAX = 5000)
LOGICAL*4 INT
+ Z(NPMAX)
+ , INT(NPMAX)
--- Comment #11 from bonzini at gnu dot org 2006-08-25 07:09 ---
Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testing
for __sync_fetch_and_add support) that the compiler should provide it as a
preprocessor symbol.
If you move cpu/generic/atomicity_{builtins,mutex
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-25 07:14 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-25 07:14 ---
Fixed.
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-25 07:14
---
Subject: Bug 28807
Author: pinskia
Date: Fri Aug 25 07:13:48 2006
New Revision: 116393
URL: http://gcc.gnu.org/viewcvs?roo
--- Comment #13 from bonzini at gnu dot org 2006-08-25 07:47 ---
PRE is eliminating
char *d.0_6;
d.0_6 = (char *) d_1;
by turning it into
char * prephitmp.24;
d.0_6 = prephitmp.24_14;
I think that not all casts should not be subject to PRE.
--
bonzini at gnu dot org chang
--- Comment #14 from bonzini at gnu dot org 2006-08-25 07:48 ---
Sorry, by turning it into
char * prephitmp.24;
# prephitmp.24_14 = PHI <1B(5), 2B(3)>;
d.0_6 = prephitmp.24_14;
I think that not all casts should be subject to PRE.
--
bonzini at gnu dot org changed:
--- Comment #12 from pcarlini at suse dot de 2006-08-25 08:08 ---
(In reply to comment #11)
> Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testing
> for __sync_fetch_and_add support) that the compiler should provide it as a
> preprocessor symbol.
Yes, and a patch
--- Comment #3 from guillaume dot melquiond at ens-lyon dot fr 2006-08-25
08:34 ---
> Which looks ok if we are passing via value but since we need to pass by
> reference, the middle-end thinks we need a new stack space for it because it
> does not know that D.1992 is not used after the
--- Comment #3 from S dot Sangwine at IEEE dot org 2006-08-25 08:39 ---
120 is outside the range of Three, but not outside the range of Three'Base,
which in my case is an 8-bit signed type with range -128 .. 127. So the correct
explanation of the problem is that the multiplication of 2 b
--- Comment #5 from kurkov at gorodok dot net 2006-08-25 08:50 ---
(In reply to comment #4)
> Where did you get your list of symbol names and demangled strings?
My program uses C standard I/O routines instead of iostreams, to support
new-ABI C++ compilers that do not have complete C++ st
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-08-25 09:01
---
Mine. This "regression" was introduced at the time we got rid of
flag_fast_math and changed it to either flag_unsafe_math_optimizations or
flag_trapping_math.
+2001-03-07 Brad Lucier <[EMAIL PROTECTED]>
+
+
We were discussing some hashtable stuff in OOo recently, part of the outcome
was...
---
From: Herbert Duerr <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject:Optimization for empty hashtables
Date: Fri, 25 Aug 2006 11:15:50 +0200 (10:15 IST)
While analyzing the performance of O
--- Comment #1 from caolanm at redhat dot com 2006-08-25 09:50 ---
Created an attachment (id=12137)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12137&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28844
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org
--- Comment #2 from pcarlini at suse dot de 2006-08-25 10:05 ---
Thanks a lot, I think we can certainly apply the patch. Are you willing to
check how are we doing in the tr1::unordered_ containers? I suspect there is
the same opportunity for improvement and frankly, at this point, we car
--- Comment #3 from caolanm at redhat dot com 2006-08-25 10:15 ---
Created an attachment (id=12138)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12138&action=view)
and add some smaller primes to the start of the list
An additional part to this puzzle...
From: Herbert Duerr <[E
--- Comment #4 from caolanm at redhat dot com 2006-08-25 10:19 ---
On a brief inspection the trl hashtable doesn't look like it really suffers
from these problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28844
--- Comment #5 from pcarlini at suse dot de 2006-08-25 10:21 ---
Indeed, I was about to post similar considerations: in tr1::unordered_ the
table starts from *2* and I think it's fine. I'm not so happy about changing
now the table of the legacy ext containers, minimally maintained but re
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-08-25 10:32 ---
Subject: Bug 28829
Author: rguenth
Date: Fri Aug 25 10:32:03 2006
New Revision: 116395
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116395
Log:
2006-08-25 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #6 from caolanm at redhat dot com 2006-08-25 10:32 ---
Sure, up to you, but I'd say you'd still be pretty safe adding two smaller
starting hash sizes.
This doesn't actually affect most OOos (at least for 95% of OOo's which exist)
which are normally built against stlport for
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-08-25 10:32 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #7 from pcarlini at suse dot de 2006-08-25 10:36 ---
(In reply to comment #6)
> Sure, up to you, but I'd say you'd still be pretty safe adding two smaller
> starting hash sizes.
Then, let's go with the minimal fix. Really, we decided time ago to only
minimally maintain those
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-08-25 10:39 ---
We now have gcc.c-torture/execute/mayalias-2.c which crashes this way on x86_64
at -O3 -g.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
--- Comment #8 from kkojima at gcc dot gnu dot org 2006-08-25 10:56 ---
> And when the other code to handle abnormal edges is fixed, we should not
> even try to insert a mode set on an abnormal edge, so the above code can
> be changed into
> gcc_assert (! (eg_flags & EDGE_A
--- Comment #8 from pcarlini at suse dot de 2006-08-25 11:04 ---
The minimal fix is not correct: the implementation of find assumes a number of
buckets > 0, try:
hash_set hs(0);
hs.find(1);
it leads to a float exception. Sorry, we are not going to do anything for this
issue.
--
--- Comment #3 from cyan+gcc at compsoc dot nuigalway dot ie 2006-08-25
11:06 ---
(In reply to comment #2)
> the Fortran program
> is not calling a var-args C function,
I don't understand what you mean. The fortran code calls the test function,
which is written in C (called test_ due t
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-08-25 11:07 ---
(In reply to comment #8)
> Do you mean the patch like this?
Yes, indeed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-08-25 11:14 ---
Working on a fix.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #2 from jsm28 at gcc dot gnu dot org 2006-08-25 11:15 ---
Working on a fix.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #2 from jsm28 at gcc dot gnu dot org 2006-08-25 11:15 ---
Working on a fix.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #10 from kkojima at gcc dot gnu dot org 2006-08-25 11:25
---
I've confirmed that it fixes the build failure on sh4-linux. I'll
send it to gcc-patches after the test on i686-linux is completed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
--- Comment #7 from falk at debian dot org 2006-08-25 12:07 ---
Can you still reproduce this? As Andrew points out, it is probably fixed...
--
falk at debian dot org changed:
What|Removed |Added
-
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-08-25 12:57
---
Hi Paul,
sorry for the late reply, I was away for a few days.
I compiled the most recent gcc sources, and there still appears to be some
bad memory access inside gfortran, which causes the compiler to someti
--
shinwell at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |shinwell at gcc dot gnu dot
|dot org
--
shinwell at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |shinwell at gcc dot gnu dot
|dot org
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-08-25 13:25 ---
Subject: Re: [gfortran: 4.1, 4.2 regression] ICE on valid
code
martin,
>--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-08-25
>12:57 ---
>Hi Paul,
>
>sorry for the late reply, I was away f
--
shinwell at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |shinwell at gcc dot gnu dot
|dot org
--- Comment #11 from bonzini at gnu dot org 2006-08-25 13:43 ---
This potentially affects i686-pc-linux-gnu as it also uses the mode switching
code. I think this should go in.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #12 from dje at gcc dot gnu dot org 2006-08-25 13:54 ---
Subject: Bug 28753
Author: dje
Date: Fri Aug 25 13:53:39 2006
New Revision: 116400
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116400
Log:
PR target/28753
* config/rs6000/rs6000.md (movcc_int
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-25 14:08 ---
(In reply to comment #3)
> (In reply to comment #2)
> > the Fortran program
> > is not calling a var-args C function,
>
> I don't understand what you mean. The fortran code calls the test function,
> which is writte
--- Comment #13 from dje at gcc dot gnu dot org 2006-08-25 14:09 ---
Patch applied.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Configured
with: ../configure --target=sparc-sun-solaris2.9
--prefix=/local/devel/toolchain41/sparc-sun-solaris2.9
--libdir=/local/devel/toolchain41/sparc-sun-solaris2.9/lib
--libexecdir=/local/devel/toolchain41/sparc-sun-solaris2.9/lib
--with-slibdir=/local/devel/toolchain41/sparc-sun-solaris2.9/l
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 14:18 ---
Solaris is not one of the targets that supports -rdynamic.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from amylaar at gcc dot gnu dot org 2006-08-25 14:33
---
(In reply to comment #11)
> This potentially affects i686-pc-linux-gnu as it also uses the mode switching
> code. I think this should go in.
As far as I can see, the i387 mode switching is already completely brok
--- Comment #6 from drow at gcc dot gnu dot org 2006-08-25 14:35 ---
We're pruning excessively; I'll track down why.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
---
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |drow at gcc dot gnu dot org
|dot org
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-08-25 14:36
---
Created an attachment (id=12139)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12139&action=view)
new testcase
Compile with "gfortran -c lensing.f90"
and with "gfortran -c -I. lensing.f90"
--
http
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|drow at gcc dot gnu dot org |unassigned at gcc dot gnu
|
--- Comment #10 from martin at mpa-garching dot mpg dot de 2006-08-25
14:37 ---
> Perhaps you can let me have an idea of the kind of code that is doing
> this? Is this a continuation of the derived type problem or did it
> exist prior to the patch of a week back?
I don't think it ex
--- Comment #2 from pluto at agmk dot net 2006-08-25 14:38 ---
really?
please look at this.
[1] cross build on linux machine:
sparc-sun-solaris2.9-g++ backtracexx.cpp -o libbacktracexx.so -shared -ldl
-Wall -Werror -pedantic \
-O3 -fpic -funwind-tables -fno-exceptions -fno-rtti
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-25 14:43 ---
So read the docs, solaris does not support the option.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
hosking at cs dot purdue dot edu wrote:
> --- Comment #13 from hosking at cs dot purdue dot edu 2006-08-24 15:27
> ---
> Is this enough?
>
> Here is the dump output, followed by stack traces at the resize and remove
> points (the remove goes on to fail).
So, this edge can't exist.
Note
--- Comment #14 from dberlin at gcc dot gnu dot org 2006-08-25 15:19
---
Subject: Re: remove_phi_node attempts removal
of a phi node resized by resize_phi_node
hosking at cs dot purdue dot edu wrote:
> --- Comment #13 from hosking at cs dot purdue dot edu 2006-08-24 15:27
> ---
--- Comment #7 from jsm28 at gcc dot gnu dot org 2006-08-25 15:44 ---
I see no evidence for HOST_WIDE_INT dependence or for this still being present
in 4.2 on any platform. It looks like it was fixed by
2006-04-20 Jakub Jelinek <[EMAIL PROTECTED]>
* c-pretty-print.c (pp_c_di
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot
|dot org
--- Comment #13 from amylaar at gcc dot gnu dot org 2006-08-25 16:33
---
(In reply to comment #12)
> As far as I can see, the i387 mode switching is already completely broken,
> because it treats the different modes of a single mode-switchable entity
> as separate entities.
On second t
--- Comment #14 from bonzini at gnu dot org 2006-08-25 16:36 ---
> On second thought, this can work with the current implementation of
> mode-switching using pre_edge_lcm, since it will never insert a computation
> in a path if it hasn't been there before.
Yes, and that's why I think th
--- Comment #5 from kargl at gcc dot gnu dot org 2006-08-25 16:38 ---
> I don't understand what you mean. The fortran code calls the test function,
> which is written in C (called test_ due to name mangling). test_ is indeed a
> variable-args function:
> void test_(int *test, ...).
For
--- Comment #6 from nathan at gcc dot gnu dot org 2006-08-25 16:52 ---
2006-08-25 Nathan Sidwell <[EMAIL PROTECTED]>
PR c++/27787
* decl.c (make_typename_type): Only try and resolve it when
context is not dependent. Refactor.
* decl2.c (check_classfn):
--- Comment #7 from nathan at gcc dot gnu dot org 2006-08-25 16:56 ---
Subject: Bug 27787
Author: nathan
Date: Fri Aug 25 16:56:07 2006
New Revision: 116409
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116409
Log:
cp/
PR c++/27787
* decl.c (make_typename_type):
--- Comment #15 from amylaar at gcc dot gnu dot org 2006-08-25 17:01
---
(In reply to comment #13)
> For any transparent sub-graph, considering the expression anticipatable
> in this graph is beneficial if the sum of the frequencies of outgoing edges
> on which the expression is anticip
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-08-25 17:03
---
Subject: Bug 28056
Author: mmitchel
Date: Fri Aug 25 17:03:50 2006
New Revision: 116410
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116410
Log:
PR c++/28056
* decl.c (grokdeclarator): Di
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-08-25 17:04
---
Subject: Bug 28056
Author: mmitchel
Date: Fri Aug 25 17:04:35 2006
New Revision: 116411
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116411
Log:
PR c++/28056
* g++.dg/parse/local1.C: New
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-08-25 17:05
---
Subject: Bug 28056
Author: mmitchel
Date: Fri Aug 25 17:05:30 2006
New Revision: 116412
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116412
Log:
PR c++/28056
* decl.c (grokdeclarator): Di
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-08-25 17:05
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-08-25 17:09
---
On x86-64 linux:
(gdb) set args ' as free form.
.file ""
In file :598
use ModelParams
1
Error: The derived type 'p' at (1) is of type 'pp', which has not been defined.
In file :415
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org
--- Comment #5 from pcarlini at suse dot de 2006-08-25 17:18 ---
I'm looking a bit into this: one puzzling thing is that the corresponding leak
as reported by valgrind amounts to *zero* bytes... It may well be that
something is wrong in the testing machinery / internal leak detection cod
--- Comment #7 from drow at gcc dot gnu dot org 2006-08-25 17:27 ---
Testing a fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017
gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)
g++ wants a Moo(const Moo&) in this code:
class Moo
{
Moo() { }
Moo(const Moo&) { }
public:
Moo(int) { }
};
void xyz(const Moo &)
{
}
int main()
{
xyz(Moo(0));
return 0;
}
test.cpp:5: error: 'Mo
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 17:41 ---
Actually the standard as written requires this behavior, even though the copy
constructor is not called. Anyways the standard has changed with DR 391 so
this is a dup of bug 25950.
*** This bug has been marked as a
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-08-25 17:41
---
*** Bug 28846 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #16 from amylaar at gcc dot gnu dot org 2006-08-25 18:52
---
Subject: Bug 16876
Author: amylaar
Date: Fri Aug 25 18:51:57 2006
New Revision: 116424
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116424
Log:
gcc:
PR tree-optimization/16876
* c-typeck.
--- Comment #17 from dje at gcc dot gnu dot org 2006-08-25 18:56 ---
Subject: Bug 27075
Author: dje
Date: Fri Aug 25 18:56:08 2006
New Revision: 116425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116425
Log:
PR target/27075
* config/rs6000/rs6000.c (print_oper
--- Comment #18 from dje at gcc dot gnu dot org 2006-08-25 18:56 ---
patch committed.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #15 from drow at gcc dot gnu dot org 2006-08-25 18:57 ---
I don't think I can sort this one out. I think the easiest solution will be to
check when marking a function as reachable whether it has an abstract origin,
and if so set a flag in the abstract origin preventing its b
--- Comment #12 from tbm at cyrius dot com 2006-08-25 19:05 ---
Update: mzero6.c fails because of this ICE too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
--- Comment #19 from dje at gcc dot gnu dot org 2006-08-25 19:06 ---
Subject: Bug 27075
Author: dje
Date: Fri Aug 25 19:06:18 2006
New Revision: 116426
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116426
Log:
PR target/27075
* config/rs6000/rs6000.c (print_oper
gcc: Internal error: Segmentation fault (program as)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
This is waht gcc gives me when I compile with
clear; gcc asciiFractal3.c -masm=intel -o asciiFra
gcc.dg/noncompile/pr16876 should actually compile with a warning, rather
than fail with an error.
Some work on related issues has been done before in:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00772.html
I suppose in this code:
case ic_argpass:
case ic_argpass_nonproto:
/* ??? Th
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |target
http:
--- Comment #1 from ulvinge at gmail dot com 2006-08-25 19:13 ---
I fogot to mention, that the line that caused the bug is this line
"\n lea ebx, ebx+buffer"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28847
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 19:15 ---
This is not a GCC issue really but a bug in as, yes we should not report to
file a bug here but that is PR 2252.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ulvinge at gmail dot com 2006-08-25 19:27 ---
OK, but what is PR 2252 ?
Nevermind, it was easy to fix...
just change
lea ebx, ebx+buffer
to
lea ebx, buffer+ebx
Simple, but it's still a bug.
I wont care.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28847
--- Comment #7 from kazu at gcc dot gnu dot org 2006-08-25 19:31 ---
Reproduced. Looking at this now.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tbm at cyrius dot com 2006-08-25 19:38 ---
FWIW, I cannot reproduce this with gcc 4.0.4 20060730 on hppa-linux-gnu, nor
with current 4.1 or 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21122
--- Comment #11 from drow at gcc dot gnu dot org 2006-08-25 19:57 ---
I am looking at this.
The difference between those two compilers in t16.ssa is:
- # blist_1 = PHI ;
+ # blist_1 = PHI ;
The difference in t17.alias1 is that, plus:
-Variable: list, UID 2, int[31], is addressable,
--- Comment #13 from tbm at cyrius dot com 2006-08-25 20:09 ---
Reduced testcase:
double copysign (double x, double y);
double GetDouble();
double a = copysign (1.0, GetDouble());
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
The assignment of a RESHAPE()d array does not trigger
a run-time error with bounds-checking turned on.
% gfortran -O0 -g -fbounds-check gfcbug39_bounds_check.f90 && ./a.out
Assignments with correct shapes after RESHAPE...
a(:,1) = 1.00
b(:,1) = 1.00 2.00
...and wi
$ cat fake_bomber.cpp
struct bomber
{
bomber() : bum( false ) { }
~bomber() { if ( bum ) throw 0; } // this will never throw
private:
bool bum;
};
void zoo() { }
void bar( void ( *f )() )
{
#ifndef CALL2JMP
bomber b; // fake bomber
#endif
f();
}
void foo
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-08-25 20:40 ---
Subject: Bug 28621
Author: pbrook
Date: Fri Aug 25 20:39:48 2006
New Revision: 116431
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116431
Log:
2006-08-25 Jan Hubicka <[EMAIL PROTECTED]>
PR target
--- Comment #1 from anlauf at gmx dot de 2006-08-25 20:40 ---
Created an attachment (id=12140)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12140&action=view)
Sample RESHAPE with missed array bounds violation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
--- Comment #26 from kazu at gcc dot gnu dot org 2006-08-25 20:41 ---
I'm going to test the patch in Comment #25.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from drow at gcc dot gnu dot org 2006-08-25 20:50 ---
Created an attachment (id=12141)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12141&action=view)
Aliasing fix.
Thank you Janis for the reghunt! Not too hard to track down given that.
I haven't tested this pat
--- Comment #13 from drow at gcc dot gnu dot org 2006-08-25 20:57 ---
Unfortunately Diego's gone and rewritten a bunch of aliasing code since that
revision. And there's no code corresponding to where the fix went 21 months
ago. So, congratulations: we've broken this testcase twice!
I
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-25 21:09 ---
(In reply to comment #3)
> OK, but what is PR 2252 ?
Try http://gcc.gnu.org/PR2252.
> Simple, but it's still a bug.
Yes but not a GCC one; it is a binutils bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #3 from jsm28 at gcc dot gnu dot org 2006-08-25 21:11 ---
Subject: Bug 28299
Author: jsm28
Date: Fri Aug 25 21:11:46 2006
New Revision: 116435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116435
Log:
PR c/28299
* c-decl.c (start_function): Don't try
--- Comment #7 from jsm28 at gcc dot gnu dot org 2006-08-25 21:14 ---
Subject: Bug 28418
Author: jsm28
Date: Fri Aug 25 21:14:24 2006
New Revision: 116436
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116436
Log:
2006-08-25 Fariborz Jahanian <[EMAIL PROTECTED]>
PR c/
--- Comment #8 from fjahanian at apple dot com 2006-08-25 21:36 ---
I was about to sub mit the patch. Thank you for this patch.
- Fariborz
> Subject: Bug 28418
>
> Author: jsm28
> Date: Fri Aug 25 21:14:24 2006
> New Revision: 116436
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=
1 - 100 of 162 matches
Mail list logo
