--- Comment #4 from mlazar at kma dot zcu dot cz 2006-04-10 04:15 ---
I observed that if the c source is compiled with "-foptimize-sibling-calls -O"
options (on i686 in gcc 4.0.3), the exception is catched.
So in this case, the terminate() function call:
gcc -c helper.c
g++ helper.o mai
--- Comment #3 from mlazar at kma dot zcu dot cz 2006-04-10 03:41 ---
Created an attachment (id=11234)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11234&action=view)
Compiler versions and configurations
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27098
--- Comment #2 from mlazar at kma dot zcu dot cz 2006-04-10 03:38 ---
Created an attachment (id=11233)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11233&action=view)
c part of bug-demonstration program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27098
--- Comment #1 from mlazar at kma dot zcu dot cz 2006-04-10 03:37 ---
Created an attachment (id=11232)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11232&action=view)
c++ part of bug-demonstration program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27098
I have two files. One in c compiled with gcc, and other in c++ compiled with
g++. From c++ is called helper function in c with pointer to error handler as
parameter. Error handler (in c++) execute throw, but it is not catched as I
expected. Instead is called default terminate() function.
I observe
--- Comment #16 from rakdver at gcc dot gnu dot org 2006-04-10 00:03
---
Created an attachment (id=11231)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11231&action=view)
Updated version of the patch, also handling invariant memory references
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-04-09 23:51
---
(In reply to comment #14)
> (In reply to comment #11)
> > I updated the patch for current mainline, but it still has issues for some
> > common uses of loops:
> >
> > void foo(int *ie, int *je, double *x)
> > {
>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-09 22:03 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
As part of the continuing crusade to get tonto compiled:
character(10), dimension (2) :: inp
inp = "abcdefghij"
inp = join_1(inp)
print *, inp
contains
function join_1(self) result(res)
character(len=*), dimension(:) :: self
character(len=len(self)), dimension(:), pointer :: res
allocate (res(2))
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-09 21:49 ---
Confirmed, also happens on powerpc-darwin and on the mainline still.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hi,
#include
void fill(char *s, int i)
{
memset(s, i, strlen(s));
}
4.1 produces two strlen calls
fill:
mflr 0
stwu 1,-32(1)
stw 0,36(1)
stw 28,16(1)
mr 28,4
stw 29,20(1)
mr 29,3
bl strlen
mr 3,29
bl strle
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-09 21:40 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-09 21:38 ---
I could not reproduce this with the default gc params for checking but could
with:
--param ggc-min-expand=0 --param ggc-min-heapsize=0
Which means this is a GC issue.
--
pinskia at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|tree check: expected|[4.2 Regression] tree check:
|tree_list, have omp_r
--- Comment #9 from danglin at gcc dot gnu dot org 2006-04-09 21:10 ---
Why did you use the HP assembler? GAS is well tested. The HP
assembler is never tested and has serious limitations with anything
but C.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26872
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-04-09 21:03 ---
Created an attachment (id=11230)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11230&action=view)
This one actually works :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-04-09
21:01 ---
Created an attachment (id=11229)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11229&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[ forwarded from http://bugs.debian.org/361407 ]
[EMAIL PROTECTED]:/tmp% g++ -c maria.tab.ii
maria.y: In constructor 'std::stack<_Tp, _Sequence>::stack(const _Sequence&)
[with _Tp = std::pair, _Sequence =
std::list, std::allocator > >]':
maria.y:157: internal compiler error: tree check: expected t
--- Comment #25 from danglin at gcc dot gnu dot org 2006-04-09 20:39
---
This should now be fixed on trunk and 4.1. Note however, that the
dwarf2 EH support is broken with GNU ld. libgfortran doesn't build.
There are a few testsuite fails beyond that with HP ld.
--
danglin at gcc
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-04-09 19:37 ---
Created an attachment (id=11228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11228&action=view)
patch
This patch should do the trick.
--
tkoenig at gcc dot gnu dot org changed:
What|Remov
--- Comment #24 from danglin at gcc dot gnu dot org 2006-04-09 18:56
---
Subject: Bug 26508
Author: danglin
Date: Sun Apr 9 18:56:23 2006
New Revision: 112808
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112808
Log:
PR target/26508
* config.gcc (hppa*64*-*-hp
--- Comment #23 from danglin at gcc dot gnu dot org 2006-04-09 18:32
---
Subject: Bug 26508
Author: danglin
Date: Sun Apr 9 18:32:16 2006
New Revision: 112807
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112807
Log:
PR target/27034
PR target/26508
* c
--- Comment #2 from danglin at gcc dot gnu dot org 2006-04-09 18:32 ---
Subject: Bug 27034
Author: danglin
Date: Sun Apr 9 18:32:16 2006
New Revision: 112807
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112807
Log:
PR target/27034
PR target/26508
* con
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-09 17:50 ---
Confirmed, this is a regression. There might be already a dup of this but I
don't have time to find it right now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-09 17:45 ---
Can you try 4.0.3 since 3.4.x is no longer being updated?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27092
--- Comment #13 from danglin at gcc dot gnu dot org 2006-04-09 17:45
---
Fixed on trunk (hopefully).
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from danglin at gcc dot gnu dot org 2006-04-09 17:43 ---
Fixed on trunk (hopefully).
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from danglin at gcc dot gnu dot org 2006-04-09 17:42 ---
Fixed on trunk (hopefully).
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-09 17:40 ---
Actually this testcase comes down to:
int f(int *a)
{
*a = 1;
unsigned *b = (unsigned *)a;
int *c = (int*)b;
return *c;
}
And this is caught correctly at the RTL level.
--
pinskia at gcc dot gnu do
--- Comment #5 from danglin at gcc dot gnu dot org 2006-04-09 17:19 ---
Subject: Bug 26743
Author: danglin
Date: Sun Apr 9 17:19:42 2006
New Revision: 112805
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112805
Log:
PR target/26743
PR target/11254
PR ta
--- Comment #12 from danglin at gcc dot gnu dot org 2006-04-09 17:19
---
Subject: Bug 10274
Author: danglin
Date: Sun Apr 9 17:19:42 2006
New Revision: 112805
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112805
Log:
PR target/26743
PR target/11254
PR
--- Comment #8 from danglin at gcc dot gnu dot org 2006-04-09 17:19 ---
Subject: Bug 11254
Author: danglin
Date: Sun Apr 9 17:19:42 2006
New Revision: 112805
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112805
Log:
PR target/26743
PR target/11254
PR ta
--- Comment #2 from patchapp at dberlin dot org 2006-04-09 16:55 ---
Subject: Bug number PR27089
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00322.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from danglin at gcc dot gnu dot org 2006-04-09 16:54 ---
A typo "shatic' was introduced into the LIB_SPEC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27034
[ forwarded from http://bugs.debian.org/361591 ]
[EMAIL PROTECTED]:/tmp% cat 309.c
struct mark_entry { int num; };
void *t1(void);
int t2(int*);
void t3(int);
void g(void);
static void *f(void) {
if (t1())
return 0;
void *seen_numbers = 0;
int bytes_left;
if
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-04-09 13:53
---
*** Bug 25595 has been marked as a duplicate of this bug. ***
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rsandifo at gcc dot gnu dot org 2006-04-09 13:53
---
*** This bug has been marked as a duplicate of 27073 ***
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from amodra at bigpond dot net dot au 2006-04-09 13:51
---
This horrible hack should cure the problem, I think. The rationale is that
spe.md uses %y only for evldd and evstdd insns, which load or store 8 bytes.
The lock insns use %y for 4 byte quantities (e500 doesn't su
NOTE: Defaulting component because reported component no longer exists
When compile with gcc-3.4 -O1 -fgcse -c -o qemu-bug.o qemu-bug.c,
there will be the error:
[EMAIL PROTECTED]:~/src/qemu-bug$ gcc-3.4 -O1 -fgcse -c -o qemu-bug.o qemu-bug.c
qemu-bug.c: In function `main':
qemu-bug.c:2: error: in
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-04-09
10:10 ---
Seems to occur quite frequently, here's another test case:
struct GdkColor {
unsigned long pixel;
unsigned short red;
};
struct GtkStyle {
struct GdkColor bg;
};
struct GtkStyle *gtk_style_new
--- Comment #2 from rsandifo at gcc dot gnu dot org 2006-04-09 10:09
---
Fixed on mainline and not known to be a regression
for a specific testcase.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rsandifo at gcc dot gnu dot org 2006-04-09 10:06
---
Subject: Bug 27073
Author: rsandifo
Date: Sun Apr 9 10:06:20 2006
New Revision: 112803
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112803
Log:
PR rtl-optimization/27073
* gcse.c (try_re
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-09 09:03 ---
A quick look at VN doesn't tell me an obvious place where to fix this. We have
Created value VH.0 for f_1
Created value VH.1 for (struct Bar *) VH.0
Created value VH.2 for (struct Foo *) VH.1
where (struct Foo *)
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-04-09 09:00 ---
Subject: Bug 25031
Author: tkoenig
Date: Sun Apr 9 09:00:49 2006
New Revision: 112802
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112802
Log:
2006-04-09 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-09 08:41 ---
And of course I again have hacked forwprop to do the transformation for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
Extracted from tramp3d:
template
struct Bar
{
int get() { return static_cast(this)->get2(); }
};
struct Foo : public Bar
{
int get2() { return x; }
int x;
};
int foo(Foo& f)
{
return f.get();
}
We end up with
int foo(Foo&) (f)
{
struct Foo * this.1;
int D.20
--- Comment #5 from sakovacs at freemail dot hu 2006-04-09 07:26 ---
Ok, please close this thread as non-bug/nothing to do, I still have an issue
but I will raise it on the appropriate forum, it has nothing to do with
GCC/libstdc++.
Just for the record: the problem roots in the malloc
47 matches
Mail list logo
