--- Comment #8 from uros at gcc dot gnu dot org 2006-06-07 07:02 ---
Subject: Bug 27790
Author: uros
Date: Wed Jun 7 07:01:49 2006
New Revision: 114460
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114460
Log:
PR target/27790
* config/i386/i386.c (ix86_expand_i
--- Comment #9 from uros at kss-loka dot si 2006-06-07 07:05 ---
Fixed on 4.1 branch.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-07 07:20 ---
Subject: Bug 25090
Author: pault
Date: Wed Jun 7 07:20:39 2006
New Revision: 114461
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114461
Log:
2006-06-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2006-06-07 07:20 ---
Subject: Bug 24168
Author: pault
Date: Wed Jun 7 07:20:39 2006
New Revision: 114461
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114461
Log:
2006-06-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-07 07:20 ---
Subject: Bug 25058
Author: pault
Date: Wed Jun 7 07:20:39 2006
New Revision: 114461
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114461
Log:
2006-06-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #11 from pault at gcc dot gnu dot org 2006-06-07 07:20 ---
Subject: Bug 23091
Author: pault
Date: Wed Jun 7 07:20:39 2006
New Revision: 114461
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114461
Log:
2006-06-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #9 from patchapp at dberlin dot org 2006-06-07 07:46 ---
Subject: Bug number PR c++/27601
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-06/msg00347.html
--
http://gcc.gnu.org/bugzil
DEAR Sir : GNU
I am writing to you regarding bug report
about under this code
aaa(int bbb) {
char *ccc[bbb]
}
gcc response no error. but memory error occured.
Sincerely yours,
EISUKE HAYASHI
--- Comment #1 from falk at debian dot org 2006-06-07 08:12 ---
Confirmed with 4.2.0 20060606. Cleaned up test case:
struct fann_neuron {
double value;
} __attribute__ ((packed));
void fann_run (struct fann_neuron **last_neuron) {
while (1)
(*last_neuron)->value = 1;
}
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-06-07 09:12
---
I wasn't aware of the existence of this PR. I think the problem is a least
partly fixed by my recent patch. Are there other runtime errors where we don't
issue a source location?
--
fxcoudert at gcc dot gnu do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
c++ -o nsAccessible.o -c -DMOZILLA_INTERNAL_API -DOSTYPE=\"FreeBSD6\"
- -DOSARCH=\"FreeBSD\" -DBUILD_ID=00 -I. -I./../html -I./../xul
- -I./../../../layout/generic -I./../../../layout/xul/base/src -I./../atk
~ -I../../../dist/include/command
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-07 09:58 ---
At the same time the so version needs to change, as this is an ABI change in
the library.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27919
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-06-07 10:55
---
The extra variable is generated from the call to gfc_evaluate_now around line
1970 of trans-array.c (the call is "indexse.expr = gfc_evaluate_now
(indexse.expr, &se->pre)").
I'm not sure yet if it's the right sol
--- Comment #6 from gerald at pfeifer dot com 2006-06-07 11:18 ---
(In reply to comment #5)
> Created an attachment (id=11596)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11596&action=view) [edit]
>
> can anybody test this?
Hi Paolo, I cannot test this myself at the moment, but
--- Comment #7 from bonzini at gnu dot org 2006-06-07 12:01 ---
Created an attachment (id=11623)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11623&action=view)
updated libdecnumber configure script
try this. don't forget to not include fortran because it includes stdint.m4
too.
--- Comment #15 from bonzini at gnu dot org 2006-06-07 12:08 ---
Subject: Bug 27390
Author: bonzini
Date: Wed Jun 7 12:07:24 2006
New Revision: 114462
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114462
Log:
2006-06-07 Paolo Bonzini <[EMAIL PROTECTED]>
PR target/27
--- Comment #16 from bonzini at gnu dot org 2006-06-07 12:08 ---
fixed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from hubicka at ucw dot cz 2006-06-07 12:18 ---
Subject: Re: [4.2 regression] segfault in ipa-inline.c, if
(e->callee->local.disregard_inline_limits
>
>
> --- Comment #12 from pinskia at gcc dot gnu dot org 2006-06-07 06:00
> ---
> Wait in tree-inline.c, we
Hi Hayashi-san,
I am writing to you regarding bug report
about under this code
aaa(int bbb) {
char *ccc[bbb]
}
gcc response no error. but memory error occured.
GCC accepts this as an extension to the ISO C 90 and ISO C++
languages by default. The extension is called Variable Lengt
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-06-07 12:30
---
None seems to be experiencing this bug any more, and I myself tried to trigger
it on mainline, with no success. I'm closing it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-06-07 12:55 ---
Via this change:
http://gcc.gnu.org/viewcvs/trunk/configure.in?r1=114048&r2=114435
we now have Boehm-GC also added to the things that are unnecessarily
disabled for MinGW.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-06-07 13:43 ---
Recursive inlining causes memory usage to grow exponentially. The current
default limit is
DEFPARAM (PARAM_MAX_INLINE_RECURSIVE_DEPTH_AUTO,
"max-inline-recursive-depth-auto",
"The maximum depth
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-06-07 13:49 ---
That was with recursion depth 3. With depth 2 we have 63 temporaries, with
depth 1 there are 3. Now guess what would be the number for a depth of 4.
Note this problem is fixed in 4.2. Anyone remembers which patch
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-07
13:53 ---
Subject: Re: [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for
excess errors)
> Oops, I didn't pay close enough attention. The patch may provide
> some improvement. Without the change, w
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-06-07 14:01 ---
I'm checking if it was fixed by
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109379
Log:
2006-01-05 Richard Guenther <[EMAIL PROTECTED]>
Diego Novillo <[EMAIL PROTECTED]>
* tree-pass
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-07 14:23 ---
No, it wasn't. Janis, can you hunt this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-06-07 14:35
---
This is only on 4.0, and with non-default options, so I'm closing this as
WONTFIX. gfortran is helplessly broken on 4.0 anyway.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
A memory leak happens when std::ios::sync_with_stdio(false);
valgrind:
...
==13644==
==13644== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==13644== malloc/free: in use at exit: 122,880 bytes in 6 blocks.
==13644== malloc/free: 6 allocs, 0 frees, 122,880 bytes allocated.
==136
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-06-07 14:52 ---
Also fails with 4.1.2. Janis, can you look what introduced this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-06-07 14:54
---
Note the problem is possibly at least latent on the 4.1 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27882
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-06-07 15:03 ---
Fails for me with the 4.1 branch, too, as of r114465.
./cc1plus -quiet t.c
t.c:2: internal compiler error: tree check: expected function_decl, have
dl_expr in cgraph_finalize_compilation_unit, at cgraphunit.c:971
Pl
the attached test case produces,
[EMAIL PROTECTED]:147>m68k-elf-gcc -c struct.c
struct.c: In function 'Baz':
struct.c:13: error: address of register variable 'u' requested
I see no explicit attempt to take the address of u. Notice, v can be passed
with impunity.
--
Summary: bogus er
--- Comment #1 from nathan at gcc dot gnu dot org 2006-06-07 15:20 ---
Created an attachment (id=11627)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11627&action=view)
culled from gdb testsuite -- gdb.base/store.c line 204
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27932
--- Comment #14 from sje at cup dot hp dot com 2006-06-07 15:24 ---
This is odd. In Monday nights run on hppa1.1-hp-hpux11.11 (r114420) I only see
pr24626-2.c failing. On Tuesday nights run (r114457) I see -1, -2, -and -3
failing like in comment #13.
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2006-06-07 15:29
---
(In reply to comment #2)
> I bet a beer that this was caused by:
> 2006-03-16 Maxim Kuvyrkov <[EMAIL PROTECTED]>
>
> * target.h (struct spec_info_def): New opaque declaration.
>
>
Nope. This one
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-07 15:38 ---
*** This bug has been marked as a duplicate of 26004 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-06-07 15:38
---
*** Bug 27932 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-06-07 15:42
---
I'm going to do it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #13 from patchapp at dberlin dot org 2006-06-07 15:45 ---
Subject: Bug number PR27116
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-06/msg00363.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #5 from hjl at lucon dot org 2006-06-07 15:51 ---
This testcase doesn't use -Os on SSE registers:
[EMAIL PROTECTED] stack]$ cat m.c
#include
extern char *e1 (void);
int
main ()
{
printf ("%s\n", e1 ());
return 0;
}
[EMAIL PROTECTED] stack]$ cat x.c
#include
extern char
--- Comment #6 from patchapp at dberlin dot org 2006-06-07 15:51 ---
Subject: Bug number PR c++/27508
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-06/msg00366.html
--
http://gcc.gnu.org/bugzil
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-07 15:53 ---
Can you read:
http://gcc.gnu.org/onlinedocs/libstdc++/debug.html#mem
And try with those options?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27931
--- Comment #6 from dirk dot behme at googlemail dot com 2006-06-07 15:52
---
Created an attachment (id=11628)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11628&action=view)
.i file of pcm_native.c and .s files for -Os, -O1 and -O2
Attached the .i and .s for -Os & -O2 (failing
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-06-07 16:08
---
Subject: Bug 27601
Author: reichelt
Date: Wed Jun 7 16:08:30 2006
New Revision: 114469
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114469
Log:
PR c++/27601
* cp-tree.h (finish_offsetof
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2006-06-07 16:09
---
(In reply to comment #2)
The problem is that while ripping off notes before scheduling we don't adjust
bb boundaries. The patch will soon be posted.
--
mkuvyrkov at gcc dot gnu dot org changed:
Wh
--- Comment #16 from tbm at cyrius dot com 2006-06-07 16:12 ---
I just got this segfault with when compiling another application. Should I
attach the preprocessed source to this PR or do you have enough information
already to fix it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #11 from reichelt at gcc dot gnu dot org 2006-06-07 16:15
---
Subject: Bug 27601
Author: reichelt
Date: Wed Jun 7 16:12:55 2006
New Revision: 114470
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114470
Log:
PR c++/27601
* cp-tree.h (finish_offsetof
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-06-07 16:18
---
Subject: Bug 27601
Author: reichelt
Date: Wed Jun 7 16:18:06 2006
New Revision: 114471
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114471
Log:
PR c++/27601
* cp-tree.h (finish_offsetof
--- Comment #13 from reichelt at gcc dot gnu dot org 2006-06-07 16:20
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
The following invalid code snippet triggers an ICE since GCC 3.4.0:
===
template struct A
{
int i;
A() { using i; }
};
A<0> b;
===
bug.cc: In constructor 'A< >::A()':
bug.cc:4: error: expected nested-name-specifier before 'i'
bug.cc
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
Version|unknown |4.2.0
http:/
The following code (taken from §12.5 "Free Store" of the C++ Standards, with
some simplifications) fails to compile:
struct B
{
virtual ~B() { } // line 5
void operator delete(void*, size_t);
};
test.cpp:5: error: no suitable 'operator delete' for 'B'
(The code taken directly from the C+
--- Comment #1 from patchapp at dberlin dot org 2006-06-07 16:35 ---
Subject: Bug number PR c++/27933
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-06/msg00368.html
--
http://gcc.gnu.org/bugzil
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-07 16:44 ---
A full testcase:
struct a
{
void operator delete (void*, unsigned int);
~a();
};
void g(a *b)
{
delete b;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-07 16:47 ---
Actually my testcase is invalid as "unsigned int" is not always size_t. In
fact if I change it to "unsigned long" for x86_64 and PPC-darwin, it passes in
4.1.0 20060208 and 4.2.0 20060507.
--
http://gcc.gnu.org
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-07 16:50 ---
It also works in 4.1.2 20060529 and in 4.2.0 20060604.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-07 16:54 ---
This works for me so closing as invalid. And yes I changed ~a to virtual ~a
also and it still works.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from mirko dot maischberger at gmail dot com 2006-06-07
17:43 ---
Subject: Re: valgrind reports memleak when std::ios:sync_with_stdio(false)
#include
#include
extern "C" void __libc_freeres(void);
int main(void)
{
atexit(__libc_freeres);
std::ios::sync_with_stdi
--- Comment #4 from mirko dot maischberger at gmail dot com 2006-06-07
17:51 ---
Subject: Re: valgrind reports memleak when std::ios:sync_with_stdio(false)
And even with GLIBCXX_FORCE_NEW
#include
#include
extern "C" void __libc_freeres(void);
int main(void)
{
atexit(__libc_fr
Bootstrapping current mainline with Ada included fails on Tru64 UNIX V5.1B
when linking gnatbind:
/vol/gccsrc/obj/gcc-4.2.0-20060606/5.1b-gcc/./prev-gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060606/5.1b-gcc/./prev-gcc/
-B/vol/gcc/alpha-dec-osf5.1b/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings
-W
--- Comment #2 from ro at gcc dot gnu dot org 2006-06-07 18:04 ---
I forgot to mention: this is a regression from the 4.1 branch.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mckinlay at redhat dot com 2006-06-07 18:06 ---
*** This bug has been marked as a duplicate of 19870 ***
--
mckinlay at redhat dot com changed:
What|Removed |Added
--
--- Comment #20 from mckinlay at redhat dot com 2006-06-07 18:06 ---
*** Bug 27925 has been marked as a duplicate of this bug. ***
--
mckinlay at redhat dot com changed:
What|Removed |Added
--
Bootstrapping mainline on Solaris 10/x86 (configured for
i686-pc-solaris2.10 to work around the still unfixed PR target/26146) fails
compiling several Ada files:
/vol/gccsrc/obj/gcc-4.2.0-20060606/10-gcc-gas-amd64/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060606/10-gcc-gas-amd64/./gcc/
-B/vol/gcc/
--- Comment #5 from janis at gcc dot gnu dot org 2006-06-07 18:23 ---
A regression hunt on powerpc-linux with the testcase in comment #3 identified
this mainline patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=112709
r112709 | rguenth | 2006-04-05 15:41:18 + (Wed, 05 Apr 200
Recently, gij was changed to re-exec itself after resetting its own
LD_LIBRARY_PATH.
This change almost doubles the time needed to execute "Hello World", from 0.13s
to 0.25s on my system (and compared to 0.08s for the Sun VM).
The reason is that since gij is linked against libgcj.so, the linker's
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-06-07 19:16
---
Oh, btw. the transformation is implemented correctly. Just we fold -1-a to ~a
(ok), and then negate_expr_p says it can easily negate ~a and negate_expr
negates it as a+1, which introduces the overflow. So, I'll p
After killing Eclipse, for example to avoid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27027 , starting it again
deadlocks. The main window is initally drawn but then hangs so that the window
contents are never updated again. This seems like a race condition that causes
a deadlock because it doe
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-06-07 19:32 ---
Yes, this would be useful.
Confirmed as an enhancement.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-07 19:51 ---
I guess the patch uncovered a latent problem due to different inlining. I will
have a look though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27830
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-06-07 20:21
---
The patch I proposed is wrong. We need to call gfc_evaluate_now. The question
is to know why, in this precise case, the block of code we're building
(se->pre) seems to be dropped later on (both the call that sets
--- Comment #5 from Woebbeking at web dot de 2006-06-07 20:30 ---
FYI, it doesn't work in
gcc version 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-06-07 20:37 ---
I have a fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #5 from victork at il dot ibm dot com 2006-06-07 20:47 ---
This happens because (vect_do_peeling_for_alignment) was designed in an
assumption that latch is empty. Thus it doesn't handle PHIs in latches.
(vect_analyze_loop_form) checks the latch is empty, but doesn't check tha
--- Comment #14 from ramana dot radhakrishnan at codito dot com 2006-06-07
21:20 ---
Add self to CC.
--
ramana dot radhakrishnan at codito dot com changed:
What|Removed |Added
--
--- Comment #6 from victork at il dot ibm dot com 2006-06-07 21:29 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00376.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #8 from gerald at pfeifer dot com 2006-06-07 21:37 ---
I got feedback from volunteers who were able to test the proposed patch:
Looks good, bootstrap succeeds!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26188
--- Comment #16 from dje at gcc dot gnu dot org 2006-06-07 21:39 ---
I checked with the IBM XLC team and they speculatively increase the alignment
of variables that could be auto-vectorized, so that gives another vote for that
method. They did mention that whole-program IPA allows them
--- Comment #2 from janis at gcc dot gnu dot org 2006-06-07 21:52 ---
A regression hunt using an alpha-linux cross compiler on powerpc-linux with the
first testcase from comment #1 identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=110912
r110912 | rakdver | 2006-02
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #1 from mckinlay at redhat dot com 2006-06-07 21:58 ---
No longer neccessary, since Tom has changed gij to not re-exec itself:
http://gcc.gnu.org/ml/java-patches/2006-q2/msg00330.html
--
mckinlay at redhat dot com changed:
What|Removed
--
bangerth at dealii dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-07 22:12 ---
Bangerth, why did you change the Priority? That is the job of the Release
manager.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from bangerth at math dot tamu dot edu 2006-06-07 22:28
---
Subject: Re: [4.0/4.1 Regression] ICE in copy_to_mode_reg
> Bangerth, why did you change the Priority? That is the job of the Release
> manager.
Fair enough -- I'll defer to his judgment if he would like to
--- Comment #13 from whaley at cs dot utsa dot edu 2006-06-07 22:28 ---
Subject: Re: gcc 4 produces worse x87 code on all platforms than gcc 3
Guys,
Just got access to a CoreDuo machine, and tested things there. I had to
do some hand-translation of assemblies, as I didn't have access
When working on an old code base, porting from Windows to Linux, using gcc
version 4.1.0 20060304 (Red Hat 4.1.0-3) on my Fedora system, I got a series of
warning from a header file which uses offsetof in several places - here's an
example:
PROM800.h: In member function void ATPromInfo8C::UpdateV
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-07 22:43 ---
Both goo and foo are non PODs once you define a constructor which causes the
offsetof to be invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from janis at gcc dot gnu dot org 2006-06-07 22:44 ---
A regression hunt on powerpc-linux using the testcase in the description with
"ulimit -v 50" identified this patch as the start of the failures:
http://gcc.gnu.org/viewcvs?view=rev&rev=102521
r102521 | hu
union unaligned
{
void *ptr;
} __attribute__((__packed__));
void *foo (void *p)
{
return (((union unaligned *) p)->ptr);
}
is compiled to an aligned word access on sh64-*. It was compiled
to an unaligned access before the patch
r114364 | echristo | 2006-06-05 04:50:48 +0900 (Mon, 05 Jun 200
--- Comment #6 from mark dot woollard at macrovision dot com 2006-06-07
23:13 ---
I have come across this issue too. It seems that if the exception being thrown
is passed back across a function call then the rethrow will cause a segfault.
If the catch and rethrow are in the same functio
union unaligned
{
void *ptr;
} __attribute__((__packed__));
void *foo (void *p)
{
return (((union unaligned *) p)->ptr);
}
is compiled to an aligned word access on sh64-*. It was compiled
to an unaligned access before the patch
r114364 | echristo | 2006-06-05 04:50:48 +0900 (Mon, 05 Jun 200
--- Comment #8 from janis at gcc dot gnu dot org 2006-06-07 23:19 ---
The failures stop on mainline with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=109580
r109580 | hubicka | 2006-01-11 13:13:37 + (Wed, 11 Jan 2006)
--
janis at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-08 00:01 ---
*** Bug 27943 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27942
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-08 00:01 ---
*** This bug has been marked as a duplicate of 27942 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||echristo at gcc dot gnu dot
|
--- Comment #3 from kargl at gcc dot gnu dot org 2006-06-08 00:05 ---
(In reply to comment #2)
> I would like to work on this one. The range check is only looking for
> ARITH_OK
> when it could also see ARITH_UNDERFLOW or ARITH_OVERFLOW.
>
Jerry,
There is another PR about allowing "
--- Comment #2 from echristo at apple dot com 2006-06-08 00:10 ---
Since you're using the MS abi then for sh64 you'll need to dig up where I'm
doing something wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27942
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-06-08 00:26
---
Janis could you do a regression hunt on this bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-08 00:33 ---
(In reply to comment #5)
> gcc version 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)
Can you provide a source which cause does not error out because size_t?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from pcarlini at suse dot de 2006-06-08 00:54 ---
This behavior started with this patch:
http://gcc.gnu.org/ml/libstdc++/2003-04/msg00427.html
when Pétur pointed out that, according to 27.3, p2, the standard streams are
*never* destroyed.
The ""leak"" appears only wit
1 - 100 of 123 matches
Mail list logo
