Hi,
Consider the 2 for loops given below.
for (i = 0; i N ; i++)
{
a[i]= 1;
}
for (i = 0; i N ; i++)
{
j = j+a[i];
}
The headers of these 2 loops are bb_3, bb_6 respectively. They are as follows.
bb_3 (preds = {bb_4 bb_2 }, succs = {bb_4 bb_5 })
{
bb 3:
#
On Thu, Apr 17, 2008 at 05:58:26PM -0700, Diego Novillo wrote:
So, I see a couple different scenarios that we may want to consider:
1- Push back and tell us to come back at the next stage 1. This is
certainly the easiest for everyone else, and will create a few
challenges for us on
Hi,
I have some problems with an assert in purge_dead_edges in
cfgrtl.c:2319. I use gcc version 4.2.2. and I add a new function to
the callgraph with cgraph_add_new_function.
My new function body is obtained by current_function body using
move_sese_region_to_fn and all seems go well but when the
On Fri, Apr 18, 2008 at 9:34 AM, Sandeep Maram [EMAIL PROTECTED] wrote:
Hi,
Consider the 2 for loops given below.
for (i = 0; i N ; i++)
{
a[i]= 1;
}
for (i = 0; i N ; i++)
{
j = j+a[i];
}
The headers of these 2 loops are bb_3, bb_6 respectively.
Daniel == Daniel Berlin [EMAIL PROTECTED] writes:
Daniel I put my version of the gcc conversion (which has all branches
Daniel but no tags) at git://gcc.gnu.org/git/gcc.git and set a script
Daniel up to update it appropriately.
Daniel,
how is the GIT repository synced? Is there a hook which
Ian,
Thanks. My pointer type is 32-bit. But when I tried the ARM target, GCC
4.3.0 does produce simpler code. It is likely my porting has some issue.
Bingfneg
-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
Sent: 17 April 2008 18:31
To: Bingfeng Mei
Cc:
Kunal Parmar [EMAIL PROTECTED] writes:
Is this correct :
ret_label = gen_label_rtx ();
emit_move_insn (gen_rtx_REG (HImode, 7),
gen_rtx_LABEL_REF (VOIDmode,
ret_label));
emit_call_insn (gen_brc_call_simulate (addr, args_size));
On Fri, Apr 18, 2008 at 6:31 AM, Samuel Tardieu [EMAIL PROTECTED] wrote:
Daniel == Daniel Berlin [EMAIL PROTECTED] writes:
Daniel I put my version of the gcc conversion (which has all branches
Daniel but no tags) at git://gcc.gnu.org/git/gcc.git and set a script
Daniel up to update it
Some changes I have committed already or plan to commit shortly, but
there are some where I'd appreciate some help.
Sure.
As a consequence of the restructuring of the libstdc++ documentation,
the following prominent links are broken. Do you have current
replacements for these?
On Fri, Apr 18, 2008 at 12:15 PM, Samuel Tardieu [EMAIL PROTECTED] wrote:
On 18/04, Daniel Berlin wrote:
| how is the GIT repository synced? Is there a hook which updates it
| after a svn commit?
|
| No.
| It is synced every 30 minutes.
|
|
| I'm about to switch from
On 18/04, Daniel Berlin wrote:
| However, having it synced periodically rather than after every commit is
| an annoyance.
|
| True, but it won't change anytime soon because it would place more
| load, and require more locking (since there is no guarantee a git sync
| will finish before the
Hi all,
I've tried to take into account the remarks from Joseph and Ian,
here's an updated patch. I welcome comments, ideas on how to best add
testcases in the testsuite (for example, comparing Fortran
information and C headers). After that, I will submit the complete
patch + testcases +
On Fri, 18 Apr 2008, FX wrote:
I've tried to take into account the remarks from Joseph and Ian, here's an
updated patch. I welcome comments, ideas on how to best add testcases in the
testsuite (for example, comparing Fortran information and C headers). After
that, I will submit the complete
-trivial conversion at assignment
const struct string___XUB *
struct string___XUB *
_init-reference.P_BOUNDS = ada__strings__unbounded__null_string.F.BOUNDS
+===GNAT BUG DETECTED==+
| 4.4.0 20080418 (experimental) (sparc-unknown-rtems4.9) GCC error
= ada__strings__unbounded__null_string.F.BOUNDS
+===GNAT BUG DETECTED==+
| 4.4.0 20080418 (experimental) (sparc-unknown-rtems4.9) GCC error:|
| verify_gimple failed |
That appears to be caused by this change:
2008-04-17 Eric
On Fri, Apr 18, 2008 at 1:40 PM, Samuel Tardieu [EMAIL PROTECTED] wrote:
On 18/04, Daniel Berlin wrote:
| However, having it synced periodically rather than after every commit is
| an annoyance.
|
| True, but it won't change anytime soon because it would place more
| load, and
Kunal Parmar wrote:
But my return label is getting optimized away. Could you please tell
me how to avoid this.
You may also need to add a (USE (REG RA)) to the call pattern. Gcc will
see that you set a register to the value of the return label, but it
won't see any code that uses that
On 18/04, Daniel Berlin wrote:
| I know you think this is personal, as per your email below, but it really
isn't.
| I had it set up to do it after every commit, and it drove our load
| average up a noticeable amount.
| As such, I stopped doing it and set it to run every 30 minutes.
|
| I know
On Fri, Apr 18, 2008 at 3:07 PM, Samuel Tardieu [EMAIL PROTECTED] wrote:
On 18/04, Daniel Berlin wrote:
I think the mistake is to have them (git hg) hosted on the same
machine as svn. Having them on hg.gcc.gnu.org and git.gcc.gnu.org
would allow to split the load between machines (even
That appears to be caused by this change:
2008-04-17 Eric Botcazou [EMAIL PROTECTED]
* decl.c (gnat_to_gnu_entity) object: Promote the alignment of
objects by default.
* fe.h (Debug_Flag_Dot_A): Delete.
* debug.adb (-gnatd.a): Update documentation.
On which
Hi Jim,
But my return label is getting optimized away. Could you please tell
me how to avoid this.
You may also need to add a (USE (REG RA)) to the call pattern. Gcc
will see that you set a register to the value of the
return label, but it won't see any code that uses that register, so it
Eric Botcazou [EMAIL PROTECTED] writes:
That appears to be caused by this change:
2008-04-17 Eric Botcazou [EMAIL PROTECTED]
* decl.c (gnat_to_gnu_entity) object: Promote the alignment of
objects by default.
* fe.h (Debug_Flag_Dot_A): Delete.
* debug.adb (-gnatd.a):
Also, I think the conclusion was that the compiler should not claim
any knowledge of these types unless specifically configured for a
particular target - that is, defaults.h should not contain any default
definitions.
My strong preference is to just predefine:
__INT8_T__
__INT16_T__
I think the mistake is to have them (git hg) hosted on the
same machine as svn. Having them on hg.gcc.gnu.org and
git.gcc.gnu.org would allow to split the load between machines
(even if hg.gcc.gnu.org and git.gcc.gnu.org are the same
machines originally).
This would
My strong preference is to just predefine:
__INT8_T__
[...]
Along with all the rest of the predefined bits here:
I think that would defeat the purpose of knowing these types in the
Fortran front-end.
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
On Fri, Apr 18, 2008 at 3:57 PM, Alfred M. Szmidt [EMAIL PROTECTED] wrote:
I think the mistake is to have them (git hg) hosted on the
same machine as svn. Having them on hg.gcc.gnu.org and
git.gcc.gnu.org would allow to split the load between machines
(even if
On Fri, 18 Apr 2008, Benjamin Kosnik wrote:
My strong preference is to just predefine:
First the compiler needs to know all the types, in a way consistent with
existing headers (including the choice between long and int where they
have the same size, etc.) for any system which has such
I think the mistake is to have them (git hg) hosted on
the same machine as svn. Having them on hg.gcc.gnu.org
and git.gcc.gnu.org would allow to split the load between
machines (even if hg.gcc.gnu.org and git.gcc.gnu.org
are the same machines
Hi,
I switched to x86 Fedora to PowerPC and got farther.
There were some changes which did not get
reflected into the RTEMS specific files again but I
am past those and now have this failure which does
not appear to be RTEMS related. Remember .. I am
using a native compiler built from the trunk
Snapshot gcc-4.4-20080418 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080418/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Hi,
The first attempt at this one isn't showing up in the archives. :(
I switched to x86 Fedora to PowerPC and got farther.
There were some changes which did not get
reflected into the RTEMS specific files again but I
am past those and now have this failure which does
not appear to be RTEMS
BTW,
It occurs to me that the optimisation is just as likely (if not more
likely) to remove security holes as it is to introduce them.
If someone writes comparison involving 'buf+len' because they
incorrectly ignored a possibility of 'buf+len' wrapping, then
the optimisation fixes, not breaks,
Hi,
I'm am the proprietor of a gcc compiler for the PDP10 architecture.
(This is a compiler previously worked on by Lars Brinkhoff who left XKL
some while before I joined XKL. It's possible some of you may have been
familiar with him or the compiler from that time.)
The compiler is
Fails here on ia64.
OK, this should be fixed everywhere now.
--
Eric Botcazou
gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I.
-I/home/joel/work-gnat/svn/gcc/gcc/ada gnatmake --GCC=gcc -g -O2 -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-fno-common -gnatpg -gnata
Looks
Martin,
I did a port of GCC to the Analog Devices SHARC chip. I ended up
supporting 3 kinds of pointers for this chip (two for address
spaces and one for byte pointers - the chip itself is only word
addressable (although words can be from 16 to 48 bits in size
depending on what memory is
--- Comment #10 from rwild at gcc dot gnu dot org 2008-04-18 07:10 ---
Can you check whether this is a duplicate of PR 35169?
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from michael dot baudin at gmail dot com 2008-04-18 08:13
---
Subject: Re: Recursive function with allocatable array
Hi Paul,
The generic source code that you sent to me is interesting
and you analysis is very clear. Thank you for taking the time
to fix this.
But I
From comp.lang.fortran: ICE on the following code
module funcs
implicit none
! Interface block for function program fptr will invoke
! to get the C_FUNPTR
interface
function get_proc(mess) bind(C,name='BlAh')
use ISO_C_BINDING
implicit none
--- Comment #7 from bonzini at gnu dot org 2008-04-18 10:12 ---
I have a patch, it will take a short while before I commit it because I have to
regenerate all the configures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35457
--- Comment #9 from bonzini at gnu dot org 2008-04-18 10:58 ---
Subject: Bug 35457
Author: bonzini
Date: Fri Apr 18 10:57:44 2008
New Revision: 134435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134435
Log:
2008-04-18 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #8 from bonzini at gnu dot org 2008-04-18 10:29 ---
Subject: Bug 35457
Author: bonzini
Date: Fri Apr 18 10:28:53 2008
New Revision: 134434
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134434
Log:
2008-04-18 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #10 from bonzini at gnu dot org 2008-04-18 11:35 ---
*not* fixed until newlib configures are regenerated
(see the end of http://snipurl.com/24vbq [sourceware.org])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35457
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-04-18 12:24
---
With the patch in comment #14 we have
=== g++ tests ===
Running target unix
FAIL: g++.dg/init/bitfield1.C (test for excess errors)
FAIL: g++.dg/gomp/atomic-1.C (test for excess errors)
FAIL:
--- Comment #42 from aldot at gcc dot gnu dot org 2008-04-18 14:03 ---
Isn't this fixed now?
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-04-18 14:04
---
Reply to: But I wonder how you produced this source (which have many in common
with C),
The intermediate code can be listed using the -fdump-tree-original compiler
flag. It will be placed in a file with the word
struct Loc {
int x[3];
};
int foo (int i, int j, int k, int b)
{
struct Loc IND;
if (b)
{
IND.x[0] = i;
IND.x[1] = j;
IND.x[2] = k-1;
}
else
{
IND.x[0] = i;
IND.x[1] = j;
IND.x[2] = k;
}
return IND.x[0] + IND.x[1] + IND.x[2];
}
used
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-18 14:12 ---
Mine (from tramp3d).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jsm28 at gcc dot gnu dot org 2008-04-18 14:15 ---
When GCC knows about these types on a target, CHAR16_TYPE and CHAR32_TYPE
should be defined to be the same as uint_least16_t and uint_least32_t.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-18 14:22 ---
Shorter testcase:
struct Loc { int x[2]; };
int foo (int i, int b)
{
struct Loc IND;
if (b)
{
IND.x[0] = i;
IND.x[1] = 0;
}
else
{
IND.x[0] = i;
IND.x[1] = 1;
}
--- Comment #5 from michael dot baudin at gmail dot com 2008-04-18 14:11
---
Subject: Re: Recursive function with allocatable array
Thank you very much.
I will try immediately.
On Fri, Apr 18, 2008 at 4:04 PM, jvdelisle at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-18 14:34 ---
Huhm. This is just because PRE and SCCVN are disconnected and use their own
IL.
Maybe finally time to fix this...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35972
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-04-18 14:41
---
Here is another attempt using valgrind:
==4137== 184 bytes in 23 blocks are definitely lost in loss record 2 of 13
==4137==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==4137==by 0x3FDCC07EF8:
--- Comment #4 from pthaugen at gcc dot gnu dot org 2008-04-18 14:47
---
Is the workaround still appropriate, and if so, can it go in 4.3 and trunk now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34976
--- Comment #43 from rguenth at gcc dot gnu dot org 2008-04-18 15:06
---
Not in 4.2 or 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
--- Comment #6 from michael dot baudin at gmail dot com 2008-04-18 15:07
---
Subject: Re: Recursive function with allocatable array
I used the -fdump-tree-original option to compare the version produced on this
source code with allocatable and pointer.
Only the allocatable contains
--- Comment #1 from manu at gcc dot gnu dot org 2008-04-18 15:08 ---
The C/C++ front-end plays games for bitwise operators, so it may drop the casts
but then use the original type or surround the whole operation by a conversion
to int. Part of the problem is fixed in mainline. However,
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-04-18 15:09
---
Some more info:
$ gfc -fno-range-check -fbounds-check pr35892.f
pr35892.f: In function f12_integrals_jinv:
pr35892.f:1397: internal compiler error: in convert_move, at expr.c:371
--
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-04-18 16:23
---
Regression hunt complete. The offending patch is:
Revision 133801 - (view) (download) - [select for diffs]
Modified Tue Apr 1 21:23:36 2008 UTC (2 weeks, 2 days ago) by george
File length: 35842 byte(s)
Diff to
This bug exists in various forms in multiple versions of gcc:
$ cat gccbug.c
struct sel {
const char *name;
unsigned int enabled;
};
int selog_on(struct sel *);
#define selog_on(sel) \
(sel.enabled == 0 \
? selog_on(sel) \
: sel.enabled
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
|
--- Comment #7 from kargl at gcc dot gnu dot org 2008-04-18 17:12 ---
(In reply to comment #6)
Regression hunt complete. The offending patch is:
Revision 133801 - (view) (download) - [select for diffs]
Modified Tue Apr 1 21:23:36 2008 UTC (2 weeks, 2 days ago) by george
File
--- Comment #3 from tromey at gcc dot gnu dot org 2008-04-18 17:27 ---
I think this is a duplicate of PR 34866 (fixed on the trunk).
*** This bug has been marked as a duplicate of 34866 ***
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from tromey at gcc dot gnu dot org 2008-04-18 17:27 ---
*** Bug 32564 has been marked as a duplicate of this bug. ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-04-18 17:44
---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35154.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
--- Comment #7 from tromey at gcc dot gnu dot org 2008-04-18 17:45 ---
Testing a documentation patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tromey at gcc dot gnu dot org 2008-04-18 17:54 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #9 from tromey at gcc dot gnu dot org 2008-04-18 17:54 ---
Subject: Bug 15500
Author: tromey
Date: Fri Apr 18 17:53:34 2008
New Revision: 134441
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134441
Log:
PR libcpp/15500:
* doc/cpp.texi
--- Comment #4 from aldot at gcc dot gnu dot org 2008-04-18 18:00 ---
While not really useful, i dare to state that SCC(N)-VN unfortunately misses a
lot of what it is ment to serve (IMHO), generally:
1) PR11832
testcase from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11832#c0
Needs
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-04-18 18:41
---
Subject: Bug 35724
Author: jvdelisle
Date: Fri Apr 18 18:40:22 2008
New Revision: 13
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=13
Log:
2008-04-18 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-04-18 18:48
---
Subject: Bug 35724
Author: jvdelisle
Date: Fri Apr 18 18:48:07 2008
New Revision: 134445
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134445
Log:
2008-04-18 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-04-18 18:49
---
Fixed now, closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from jakub at gcc dot gnu dot org 2008-04-18 19:12 ---
Subject: Bug 35907
Author: jakub
Date: Fri Apr 18 19:11:57 2008
New Revision: 134447
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134447
Log:
PR target/35907
* gcc.target/powerpc/pr35907.c:
--- Comment #24 from jakub at gcc dot gnu dot org 2008-04-18 19:14 ---
Subject: Bug 35907
Author: jakub
Date: Fri Apr 18 19:13:35 2008
New Revision: 134448
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134448
Log:
PR target/35907
* gcc.target/powerpc/pr35907.c:
--- Comment #9 from kargl at gcc dot gnu dot org 2008-04-18 19:48 ---
(In reply to comment #8)
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35154.
This does not contain the patch nor a pointer to the patch
that contains the offending code in comment #7.
--
--- Comment #10 from jason at gcc dot gnu dot org 2008-04-18 19:57 ---
Subject: Bug 33486
Author: jason
Date: Fri Apr 18 19:56:55 2008
New Revision: 134450
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134450
Log:
PR c++/33486
* name-lookup.c
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
The following invalid code is accepted by G++:
void f() { typedef int T; T(); }
Comeau 4.3.9 rejects the code with an error: invalid type conversion
diagnostic.
--
Summary: Invalid argumentless functional explicit type conversion
to reference type not
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-04-18 20:58
---
Agree, that bad hunk is not in the approved patch. Since it obviously breaks
gfortran in a bad way, I am going to revert it and see what happens for
followup.
--
--- Comment #5 from pault at gcc dot gnu dot org 2008-04-18 21:02 ---
(In reply to comment #4)
Please note off-by one in the last index.
Uros,
Indeed:) I'm snooping round trying to understand why the scalarizer has taken
to doing that. Not only is the offset wrong, but the size
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-04-18 21:31
---
Reverting the patch breaks two test cases:
pr35154-dwarf2.f
pr35154-stabs.f
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
/*
Ryan Flynn
[EMAIL PROTECTED] (remove dashes)
Wed Apr 18 05:00:01 EDT 2008
*/
typedef int tym;
void a(tym *sym) { tym *x; } /* no problems here */
typedef int sym;
void b(sym *sym) { sym *y; } /* 'y undeclared'(?!) */
int main(void) { return 0; }
/*
Seems to be something wrong with types
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-18 23:21 ---
typedef int sym;
void b(sym *sym) { sym *y; } /* 'y undeclared'(?!) */
sym *y is a multiple and not a variable definition so y is undeclared here and
the error is correct since the variable sym shadows (and is in
--- Comment #12 from kargl at gcc dot gnu dot org 2008-04-18 22:14 ---
(In reply to comment #11)
Reverting the patch breaks two test cases:
pr35154-dwarf2.f
pr35154-stabs.f
These are part of the patch that broke the compiler, so I
would certainly expect them to fail.
--
--- Comment #1 from fang at csl dot cornell dot edu 2008-04-18 21:48
---
opinion
While the upcoming standard does support '' to double-close template
arguments, I would still recommend to anyone to separate them for clarity and
compatibility with less forgiving compilers.
/opinion
--- Comment #3 from yuri at tsoft dot com 2008-04-18 23:30 ---
Closing it completely
--
yuri at tsoft dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #2 from yuri at tsoft dot com 2008-04-18 23:29 ---
Problem was because of the mixup of gcc libaries.
Executable was built with one compiler and during the run different shared
libraries were used.
--
yuri at tsoft dot com changed:
What|Removed
--- Comment #4 from yuri at tsoft dot com 2008-04-19 01:07 ---
Reopening this PR.
Same testcase with gcc-4.3.0 on FreeBSD-7.0-STABLE aborts:
Abort trap: 6
ldd executable output:
libstdc++.so.6 = /usr/local/gcc/4.3.0/lib/libstdc++.so.6 (0x2807d000)
libm.so.5 =
--- Comment #5 from yuri at tsoft dot com 2008-04-19 01:09 ---
The only broken version is 4.3.0, all 4.2.X throw exceptions ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876
Regression in cris-elf results; worked with 134437 started failing with 134440:
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ...
FAIL: gcc.dg/tree-ssa/forwprop-3.c scan-tree-dump forwprop1 Replaced .p_.
q_.. with .1.
Nothing interesting in gcc.log, but the whole
--- Comment #5 from rguenther at suse dot de 2008-04-19 01:50 ---
Subject: Re: [4.4 Regression] load-PRE missed
opportunities without SFTs
On Fri, 18 Apr 2008, aldot at gcc dot gnu dot org wrote:
--- Comment #4 from aldot at gcc dot gnu dot org 2008-04-18 18:00 ---
While
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|---
--- Comment #1 from ian at gcc dot gnu dot org 2008-04-19 04:20 ---
Subject: Bug 35977
Author: ian
Date: Sat Apr 19 04:18:31 2008
New Revision: 134463
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134463
Log:
PR tree-optimization/35977
*
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-19 04:25 ---
How does strict overflow interfear with debuggablity?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35977
--- Comment #3 from ian at airs dot com 2008-04-19 05:56 ---
Strict overflow should not have any effect on debuggability that I can see.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #4 from ian at airs dot com 2008-04-19 05:56 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|UNCONFIRMED
96 matches
Mail list logo
