--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-06-08
06:54 ---
Where did this one go to? Can we close it?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
--- Comment #16 from guillaume dot melquiond at ens-lyon dot fr 2006-06-08
06:35 ---
Sorry if I'm misunderstanding your patch (I didn't try it), but it seems to me
that GCC will still generate wrong code if the testcase is compiled with
-fwrapv -fno-trapv.
--
http://gcc.gnu.org/bug
--- Comment #6 from agner at agner dot org 2006-06-08 06:27 ---
Comment #5 From hjl confirms my point: The error can occur in an optimized part
of the program that uses XMM registers when some other, noncritical, part of
the program is compiled with -Os
We need a comment from the ABI pe
--- Comment #10 from bonzini at gnu dot org 2006-06-08 06:20 ---
Created an attachment (id=11631)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11631&action=view)
really a different patch
Sorry, I attached the wrong patch again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #9 from bonzini at gnu dot org 2006-06-08 06:10 ---
Created an attachment (id=11630)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11630&action=view)
a supposedly correct patch
No, the patch was wrong. Also the original proposed patch was right that some
messages mist
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-08 05:00 ---
Yara is worse as it uses the CTR register.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16796
Testcase:
void f(double a, double *b)
{
long long c = a;
*b = c;
}
-
We currently get:
_f:
fctidz f1,f1
fcfid f0,f1
stfd f1,-16(r1) ; <--- not needed
stfd f0,0(r4)
blr
On the Yara branch we get:
fctidz f0,f1
fcfid f0,f0
--- Comment #2 from jb at gcc dot gnu dot org 2006-06-08 04:52 ---
(In reply to comment #1)
> At the same time the so version needs to change, as this is an ABI change in
> the library.
>
Yes. However, I think a single so version increase is enough for 4.1->4.2, and
I plan to increase
--- Comment #3 from alpt at freaknet dot org 2006-06-08 03:14 ---
You're right. on 3.4.x I get wrong results too.
The only positive result I get is on 3.3.6.
~> You should note this is extension even on top of C99 so it might be correct
~> to change it.
Yep, but it is a very elegant e
DEAR Sir : GNU
I am writing to you regarding bug report
under this code
#include
#include
void subroutine(int n)
{
int buf[n];
fprintf(stderr, "%d (%d)\n", (int)sizeof(buf), (unsigned long)buf);
}
int main( int argc, char **argv)
{
int i, value[] = {0, 1, -1, INT_MAX, 1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-08 03:00 ---
> On a x86 with gcc-3.4.x/3.3.6 it prints:
> pkt 65, foo 65
> pktII 65, bar 65
> (this is the right output)
I don't get 65 with 3.4.0, I get 68 like 4.0.0 and above.
earth:~>~/ia32_linux_gcc3_4/bin/gcc -O2 t.c
earth
--- Comment #15 from patchapp at dberlin dot org 2006-06-08 02:52 ---
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/msg00378.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #7 from patchapp at dberlin dot org 2006-06-08 02:48 ---
Subject: Bug number PR tree-optimizations/26969
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/msg00376.html
--
http://gcc
--- Comment #1 from alpt at freaknet dot org 2006-06-08 02:33 ---
On gcc 4.0.2, PIII:
pkt 68, foo 68
pktII 68, bar 68
--
alpt at freaknet dot org changed:
What|Removed |Added
-
Consider this test: http://hinezumilabs.org/alpt/test-pack.c
#define _PACKED_ __attribute__ ((__packed__))
int func(int levels)
{
struct foo {
u_char a;
int32_t b[levels];
struct timeval _PACKED_ c[levels];
u
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-06-08 01:50 ---
It seems that r114364 adds the extra alignment for non bit-field
fields always for the ms_bitfield_layout_p case. It looks the packed
attribute should be taken into account, though I'm unsure whether
it's the way of
--- Comment #5 from kargl at gcc dot gnu dot org 2006-06-08 01:26 ---
(In reply to comment #4)
>
> I think the patch will be straight forward including updating the appropriate
> texi. The -fallow-inf-nan can be applied to range_check in simplify.c and
> that
> will cover most if not
--- Comment #1 from danglin at gcc dot gnu dot org 2006-06-08 01:24 ---
Probably introduced by the following change:
2005-09-01 Arnaud Charlet <[EMAIL PROTECTED]>
* s-taprop-mingw.adb, s-taprop-vms.adb, s-taprop-solaris.adb,
s-taprop-os2.adb, s-taprop-irix-athread.adb
--- Comment #18 from amacleod at redhat dot com 2006-06-08 01:18 ---
Subject: Bug 27793
Author: amacleod
Date: Thu Jun 8 01:18:16 2006
New Revision: 114480
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114480
Log:
2006-06-07 Andrew MacLeod <[EMAIL PROTECTED]>
PR mi
/xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/
-B/opt/gnu/gcc/gcc-4
.2.0/hppa1.1-hp-hpux10.20/bin/
-B/opt/gnu/gcc/gcc-4.2.0/hppa1.1-hp-hpux10.20/lib
/ -isystem /opt/gnu/gcc/gcc-4.2.0/hppa1.1-hp-hpux10.20/include -isystem
/opt/gnu
/gcc/gcc-4.2.0/hppa1.1-hp-hpux10.20/sys-include -c -g -O
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-06-08 01:10
---
This bug is related to 19310
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-06-08 01:04
---
Steve,
I was just about to post an RFC to the list because this PR is requesting a
change of philosophy regarding compile time vs runtime behavior. Your comment
about -fallow-inf-nan answers my question. I can
--- 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
--- 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 #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 #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 #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 "
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||echristo at gcc dot gnu dot
|
--- 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
--
--- 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 #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:
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 #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
--- 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
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 #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
--- 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 #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
-
--
bangerth at dealii dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
--- 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
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- 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
--- 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 #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 #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 #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 #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 #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 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 #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 #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 #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
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 #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
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 #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
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 #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
--
--- 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 #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
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 #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
--- 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 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 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 #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 #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 #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
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+
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
Version|unknown |4.2.0
http:/
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
--- 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
--
--- 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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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
---
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 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
--- 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 #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 #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
1 - 100 of 123 matches
Mail list logo
