--- Comment #7 from doko at gcc dot gnu dot org 2009-05-07 06:55 ---
Subject: Bug 40038
Author: doko
Date: Thu May 7 06:55:15 2009
New Revision: 147217
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147217
Log:
2009-05-07 Matthias Klose
PR libstdc++/40038
*
--- Comment #66 from lucier at math dot purdue dot edu 2009-05-07 05:27
---
Adding -frename-registers gives a significant speedup (sometimes as fast as
4.1.2 on this shared machine, i.e., it somtimes hits 108 ms instead of
132-140ms), the command line with -fforward-propagate -fno-move-
--- Comment #65 from bonzini at gnu dot org 2009-05-07 05:03 ---
Subject: Re: [4.3/4.4/4.5 Regression] 30% performance
slowdown in floating-point code caused by r118475
lucier at math dot purdue dot edu wrote:
> --- Comment #64 from lucier at math dot purdue dot edu 2009-05-06 2
--- Comment #6 from pault at gcc dot gnu dot org 2009-05-07 04:44 ---
(In reply to comment #5)
> The patch in comment #4 fixes this pr, but gives:
>
> .*: internal compiler error: in fold_convert, at fold-const.c:2551
Yes... I went to bed when the regression test started spewing out th
The testcase from PR40021:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=17800&action=view
shows a current problem in optimizing away logical operations on logical
(boolean) types, like "x | 1" --> "1". This folding is done in some contexts,
and not in others. In particular the testcase
(with -
--- Comment #5 from jack2 at cantab dot net 2009-05-06 22:31 ---
> No, from the sound of it there is an alias violation in the code.
You're right, I had thought of that but had read that Mozilla code was compiled
with -fno-strict-aliasing because of this. Looking more closely the code i
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-06 22:29 ---
Revision 138953:
http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00512.html
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00524.html
fixed a real bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40051
--- Comment #3 from jack2 at cantab dot net 2009-05-06 22:00 ---
Created an attachment (id=17815)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17815&action=view)
Patch against trunk 147188 to revert commit 138953
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40051
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-06 22:07 ---
> From the little I understand 'external' should not be set to 1 for functions
> listed as intrinsics but not f95 intrinsics.
I don't see any reason why 'erfc' should get the EXTERNAL attribute here at
all. In any ca
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-06 21:59 ---
>SVN commit 138953 introduced a bug where code compiled at -O2 and above reads a
value into a register before it is written in a function called by the
optimized code.
No, from the sound of it there is an alias viol
--- Comment #1 from jack2 at cantab dot net 2009-05-06 21:56 ---
Created an attachment (id=17814)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17814&action=view)
*.i file with which the bug is demonstrated
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40051
--- Comment #23 from matz at gcc dot gnu dot org 2009-05-06 21:56 ---
No regressions on x86_64-linux. I'm baffled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
--- Comment #22 from rguenther at suse dot de 2009-05-06 21:55 ---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 6 May 2009, matz at suse dot de wrote:
> --- Comment #21 from matz at suse dot de 2009-05-06 21:39 ---
SVN commit 138953 introduced a bug where code compiled at -O2 and above reads a
value into a register before it is written in a function called by the
optimized code.
This is demonstrated in the code for the Enigmail plugin to Mozilla Thunderbird
as discussed at https://bugs.gentoo.org/show_bug.cg
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-06 21:43 ---
The patch in comment #4 fixes this pr, but gives:
.*: internal compiler error: in fold_convert, at fold-const.c:2551
in 83 of my tests, for instance
[ibook-dhum] f90/bug% cat pr36257.f90
implicit none
character
--- Comment #21 from matz at suse dot de 2009-05-06 21:39 ---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 6 May 2009, rguenther at suse dot de wrote:
> > + tree ret;
> > + if (TYPE_PACKED (t))
> > +return t;
>
> Wal
--- Comment #3 from hjl at gcc dot gnu dot org 2009-05-06 21:33 ---
Subject: Bug 40050
Author: hjl
Date: Wed May 6 21:31:56 2009
New Revision: 147208
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147208
Log:
2009-05-06 H.J. Lu
PR testsuite/40050
* lib/plugi
--- Comment #4 from janus at gcc dot gnu dot org 2009-05-06 21:23 ---
Status: r147206 implements PPCs with NOPASS, but PASS is still missing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39630
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-06 21:17 ---
Subject: Bug 39630
Author: janus
Date: Wed May 6 21:17:16 2009
New Revision: 147206
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147206
Log:
2009-05-06 Janus Weil
Paul Thomas
PR fo
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-06 21:03 ---
Here is a patch:
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00280.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #20 from rguenther at suse dot de 2009-05-06 21:02 ---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 6 May 2009, matz at gcc dot gnu dot org wrote:
> --- Comment #19 from matz at gcc dot gnu dot org 2009-05-
--- Comment #12 from dodji at gcc dot gnu dot org 2009-05-06 20:47 ---
Fixed in 4.4 and 4.5. The patch won't apply to 4.3 as the code base has
diverged.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pault at gcc dot gnu dot org 2009-05-06 20:46 ---
This fixes it and is regtesting right now.
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 147128)
+++ gcc/fortran/trans-a
onfigure --enable-checking=release
--prefix=/pkgs/gcc-mainline --enable-languages=c
Thread model: posix
gcc version 4.5.0 20090506 (experimental) [trunk revision 147199] (GCC)
and the runtime didn't change (substantially)
132 ms cpu time (132 user, 0 system)
and the loop looks pretty
--- Comment #11 from dodji at gcc dot gnu dot org 2009-05-06 20:43 ---
Subject: Bug 17395
Author: dodji
Date: Wed May 6 20:43:41 2009
New Revision: 147202
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147202
Log:
2009-05-06 Dodji Seketeli
gcc/cp/ChangeLog:
PR c
--- Comment #10 from dodji at gcc dot gnu dot org 2009-05-06 20:42 ---
Subject: Bug 17395
Author: dodji
Date: Wed May 6 20:41:52 2009
New Revision: 147201
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147201
Log:
2009-05-06 Dodji Seketeli
gcc/cp/ChangeLog:
PR c
--- Comment #19 from matz at gcc dot gnu dot org 2009-05-06 20:39 ---
Something like this implements option 1. It's probably hopelessly inefficient
(always generating a new type for each packed field), and wrong, and generally
just a bad idea, but it does fix the testcase, execute.exp s
--- Comment #1 from joseph at codesourcery dot com 2009-05-06 20:16 ---
Subject: Re: New: plugin tests don't work with multilib
On Wed, 6 May 2009, hjl dot tools at gmail dot com wrote:
> On Linux/Intel64, I got
>
> Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgc
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-06 20:15 ---
Yep, that patch makes more sense. Please make sure to also test x86_64.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
--- Comment #5 from jan dot kratochvil at redhat dot com 2009-05-06 20:12
---
(In reply to comment #4)
> I don't know how ready GDB et al are to cope with this,
(For GDB the local definitions containing an address expression are even less
problematic than the current declarations requi
On Linux/Intel64, I got
Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -I.
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite
-I/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/../../gcc
-I/export/build/gnu/gcc/build-x86_64-linu
--- Comment #6 from meissner at linux dot vnet dot ibm dot com 2009-05-06
20:00 ---
Created an attachment (id=17813)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17813&action=view)
More targetted patch to fix the problem
This patch is much more targeted to just make sure vector
--- Comment #63 from lucier at math dot purdue dot edu 2009-05-06 19:57
---
Was the patch in comment 55 meant for me to bootstrap and test with today's
mainline? It crashes at the gcc_assert at
/* Subroutine of canon_reg. Pass *XLOC through canon_reg, and validate
the result if ne
--- Comment #4 from roland at redhat dot com 2009-05-06 19:45 ---
Hmm. I am concerned by the idea of relocs for DWARF sections in final-linked
objects. That is a hassle that consumers have not had to handle before.
(AFAIK only consumers that handle ET_REL pseudo-final objects such as
--- Comment #5 from meissner at linux dot vnet dot ibm dot com 2009-05-06
19:35 ---
Subject: Re: Incorrect tree made for vector shifted by constant on powerpc,
spu
On Wed, May 06, 2009 at 07:22:25PM -, rguenth at gcc dot gnu dot org wrote:
>
>
> --- Comment #4 from rguenth a
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-06 19:22 ---
See http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01532.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-06 19:20 ---
Wait - I patched this area exactly to avoid type verification issues on x86_64
...
(what do you mean by integer constants do not have a type? They definitely
do on the tree level)
--
http://gcc.gnu.org/bugzill
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-05-06
19:19 ---
Created an attachment (id=17812)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17812&action=view)
Simplified test case
This testcase shows the problem. Without the patch, it generates a vspltiw
(
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-06
19:08 ---
Created an attachment (id=17811)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17811&action=view)
Patch to fix vector shift by constant on machines with vector/vector shift
This patch fixes the pr
On machines with only a vector/vector shift like the powerpc and spu, the wrong
type is generated for the tree vector that is created with the constant
splat'ed to fill the vector. The problem is the code uses
get_vectype_for_scalar_type, and integer constants don't have a type. So
get_vectype_fo
--- Comment #9 from dodji at gcc dot gnu dot org 2009-05-06 18:56 ---
I have submitted a patch for this at
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00270.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17395
--- Comment #15 from hjl at gcc dot gnu dot org 2009-05-06 17:47 ---
Subject: Bug 40021
Author: hjl
Date: Wed May 6 17:45:40 2009
New Revision: 147195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06 H.J. Lu
Backport from mainline:
2009-
--- Comment #6 from hjl at gcc dot gnu dot org 2009-05-06 17:47 ---
Subject: Bug 39983
Author: hjl
Date: Wed May 6 17:45:40 2009
New Revision: 147195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06 H.J. Lu
Backport from mainline:
2009-0
--- Comment #8 from hjl at gcc dot gnu dot org 2009-05-06 17:47 ---
Subject: Bug 40023
Author: hjl
Date: Wed May 6 17:45:40 2009
New Revision: 147195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06 H.J. Lu
Backport from mainline:
2009-0
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-06 17:39 ---
(In reply to comment #3)
> The code generated for SMALL is correct, any caller that passes argument not
> aligned on 8 byte boundary (you are mistaken that it requires 16 byte
> alignment,
> try calling it with c(3)
--- Comment #5 from janis at gcc dot gnu dot org 2009-05-06 17:18 ---
This was a regression after all, release branches do not have the bug. I added
the new test case to the 4.4 and 4.3 branches.
--
janis at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from janis at gcc dot gnu dot org 2009-05-06 17:01 ---
Subject: Bug 39986
Author: janis
Date: Wed May 6 16:59:53 2009
New Revision: 147188
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147188
Log:
PR middle-end/39986
* dfp.c (encode_decimal32, de
--- Comment #14 from matz at gcc dot gnu dot org 2009-05-06 16:54 ---
Hence, fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #13 from matz at gcc dot gnu dot org 2009-05-06 16:50 ---
Subject: Bug 40021
Author: matz
Date: Wed May 6 16:49:13 2009
New Revision: 147186
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147186
Log:
PR middle-end/40021
* cfgexpand.c (maybe_cleanup_e
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-06 16:40 ---
(In reply to comment #2)
> The GDB patch now assembles the symbol name from its parent DW_TAG_module as
> `__modulename_MOD_varname'. As GDB also has to know the C++ mangling rules I
> believe this Fortran mangling i
--- Comment #5 from ppluzhnikov at google dot com 2009-05-06 16:36 ---
(In reply to comment #3)
> Note that this is likely not a problem in practice as
> memcpy (p, p, sizeof (*p)) is difficult to implement
> in a way that would make it not work.
>From Julian Seward:
JS> AIUI, POSIX
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-06 16:18 ---
Works for me on the branch head.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bgalehouse at spamcop dot net 2009-05-06 16:04 ---
Just found that it seems unrelated to c++0x features. I configured the library
to not require them, and found the 4.4.0 crashes but the system compiler works.
(both running same options, without the -std=c++0x, but ot
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-06 15:56 ---
*** Bug 40047 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-06 15:56 ---
*** This bug has been marked as a duplicate of 39958 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from bgalehouse at spamcop dot net 2009-05-06 15:53 ---
Created an attachment (id=17810)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17810&action=view)
Compressed preprocessed source to recreate.
Attached proprocessed source file, compressed to fit under bugtraq s
--- Comment #20 from matz at gcc dot gnu dot org 2009-05-06 15:48 ---
Bootstrap on AIX was already working on April 29:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02342.html
I just left this open for the other (ARM/Mips) problem. As that now moved
somewhere else, this here is fixed.
--- Comment #12 from hjl dot tools at gmail dot com 2009-05-06 15:48
---
(In reply to comment #11)
> (In reply to comment #10)
> > Yes, I'll clean this up before submission. Did it help?
> >
>
> I tried it on revision 147173 and it works on test input for
> 416.gamess and 465.tonto.
The following was produced on a gentoo x86 linux system with a pentium-m
processor, the system compiler is Gentoo 4.3.3-r2 and kernel is
linux-2.6.28-gentoo-r5.
Last night, I built gcc 4.4.0 and installed it into /home/bgalehouse/installs.
I then reconfigured a library (CGAL) to make use of c++0
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-06 15:46 ---
FIXED on the trunk (4.5). Thanks for reporting it.
Crossref: The warning was added by Daniel Franke with Rev. 126153 for PR 20373.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-06 15:45 ---
Subject: Bug 40041
Author: burnus
Date: Wed May 6 15:44:18 2009
New Revision: 147183
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147183
Log:
2009-05-06 Tobias Burnus
PR fortran/40041
*
--- Comment #7 from bonzini at gnu dot org 2009-05-06 15:35 ---
Is this reproducible with a crosscompiler and with --enable-checking=all,gcac?
You can try valgrind too.
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #19 from bonzini at gnu dot org 2009-05-06 15:33 ---
ARM moved to PR40031 (and PR39978?).
What about AIX?
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
Version|unknown |4.5.0
http://g
Compiling "libgomp.c++/task-4.C" with "g++" is successful, but compiling it
with "g++ -fopenmp" gives:
libgomp.c++/task-4.C: In function 'void foo(int, int)':
libgomp.c++/task-4.C:37: error: type mismatch in indirect reference
int[0:D.2193]
int[0:<<< error >>>]
D.2218 = &(*q.1)[0];
libgomp.c++/
--- Comment #62 from bonzini at gnu dot org 2009-05-06 15:07 ---
No, totally unrelated to PR39871
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #1 from bonzini at gnu dot org 2009-05-06 15:06 ---
With 4.5 I see
With 4.5.0 I see:
push{lr}
sub sp, sp, #12
ldr r2, [r0]
ldr r1, [r0, #4]
mov r0, sp
str r2, [sp, #4]
bl func
add
--- Comment #4 from domob at gcc dot gnu dot org 2009-05-06 15:01 ---
Yes, that sounds like a problem caused by my patch; it did change the structure
of storing the type-bounds, so maybe simply changing the if to the one shown by
Tobias was wrong.
I will look into this!
--
domob at
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-06 14:58 ---
(In reply to comment #2)
> and the interesting question is: Why is it called? There are no type-bound
> procedures (and also no components [except of t2%t].
If it's a regression it may be caused by Daniel's r146733 (
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-06 14:51 ---
(In reply to comment #1)
> I've just confirmed the bug on i686-pc-solaris2.10. It doesn't occur on
> i686-pc-solaris2.11, though, so this is indeed a Sun ld bug.
>
> I've got a few questions to resolve, though:
>
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-06 14:39 ---
Regarding the segfault, valgrind shows:
==14376== Invalid read of size 1
==14376==by 0x616A4F7: fprintf (in /lib64/libc-2.9.so)
==14376==by 0x4B4BF1: show_typebound (dump-parse-tree.c:693)
The line is:
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-06 14:31 ---
Confirmed and this is regression with repect to 4.4.0:
[karma] f90/bug% gfc -fdump-parse-tree pr40045.f90
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = MAIN__
symtr
--- Comment #3 from burnus at gcc dot gnu dot org 2009-05-06 14:28 ---
> Btw, adding "REAL ABS,MAX" doesn't help either, so it's not related to the
> function's types.
Well, exactly that should trigger the warning! Thus it shall not help silencing
the warning!
Some light testing - now
--- Comment #11 from hjl dot tools at gmail dot com 2009-05-06 14:27
---
(In reply to comment #10)
> Yes, I'll clean this up before submission. Did it help?
>
I tried it on revision 147173 and it works on test input for
416.gamess and 465.tonto. I am running reference input now. Than
There is the following line in configure script:
eval `${CC-cc} -E conftest.c | grep host_address=`
Since I have GREP_OPTIONS variable in my environment which looks like
"GREP_OPTIONS=--color=always", some color codes are generated in grep's output.
The issue is the "eval ..." does not work prope
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-06 13:52 ---
Ok, I know what happens.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
As
Segfault with -fdump-parse-tree:
type t
end type
type, extends(t) :: t2
end type t2
end
--
Summary: ICE with type extension and -fdump-parse-tree
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severi
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-06 13:24 ---
Reduced testcase:
void foo(void *);
void
MMAPGCD (int *A1, int *A2)
{
int *t;
do
{
t = A1;
A1 = A2;
A2 = t;
}
while (A2[-1]);
foo (A1-1);
foo (A2-1);
}
if you make foo take
--- Comment #6 from paolo dot carlini at oracle dot com 2009-05-06 13:20
---
Excellent. Then Matthias' suggested fix makes sense to me. Better if Benjamin
could also review it, however (lately, he touched this code, IIRC).
--
paolo dot carlini at oracle dot com changed:
--- Comment #61 from jakub at gcc dot gnu dot org 2009-05-06 13:05 ---
Also see PR39871, maybe that's related (though on ARM).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-05-06 13:04 ---
Fixed for 4.5.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-05-06 13:03 ---
Subject: Bug 40032
Author: jsm28
Date: Wed May 6 13:02:48 2009
New Revision: 147174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147174
Log:
PR c/40032
* c-decl.c (grokdeclarator): Handle in
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-06 13:02 ---
Only ceill is actually missing in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ro at gcc dot gnu dot org 2009-05-06 13:01 ---
I've just confirmed the bug on i686-pc-solaris2.10. It doesn't occur on
i686-pc-solaris2.11, though, so this is indeed a Sun ld bug.
I've got a few questions to resolve, though:
* Why does generating code for i686 inst
The following code will ICE:
template
void f(T*);
template
struct A {};
template
void g(A > *);
int main()
{
g((A >*)0);
}
--
Summary: ICE when resolves overloaded functions
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severit
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-06 12:14 ---
That just means you have no idea how a memory allocator works.
Returning all just freed pages immediately to the system is of course possible,
but terribly expensive performance wise, since often on the following mallo
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-06 12:07
---
Oh well, if valgrind is happy, definitely not a libstdc++ maintainers job.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40042
--- Comment #3 from simonracz at gmail dot com 2009-05-06 12:03 ---
(In reply to comment #2)
> By the way, valgrind, correctly, doesn't report anything, at least together
> with glibc 2.9:
You can see the difference in memory usage (after deleting) with top.
--
http://gcc.gnu.org/b
--- Comment #18 from matz at gcc dot gnu dot org 2009-05-06 11:57 ---
The structure in this testcase is not packed. One member is. Or are you
talking about some different case?
Let's suppose you are and you mean something like this:
struct S {T1 m1; T2 m2; ...} __attribute__((packed
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-05-06 11:57 ---
(In reply to comment #1)
> > The same warnings are given if the arguments of ABS/MAX are of default-real
> > kind, so this not related to implicit typing.
>
> I have to admit that I don't fully understand that sente
--- Comment #17 from rguenther at suse dot de 2009-05-06 11:45 ---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 6 May 2009, matz at gcc dot gnu dot org wrote:
> --- Comment #16 from matz at gcc dot gnu dot org 2009-05-
--- Comment #3 from rguenther at suse dot de 2009-05-06 11:41 ---
Subject: Re: [4.5 Regression] ICE during
gimplify_init_constructor
On Wed, 6 May 2009, joseph at codesourcery dot com wrote:
> Subject: Re: [4.5 Regression] ICE during gimplify_init_constructor
>
> On Tue, 5 May 2009
--- Comment #2 from paolo dot carlini at oracle dot com 2009-05-06 11:39
---
By the way, valgrind, correctly, doesn't report anything, at least together
with glibc 2.9:
==5250== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1)
==5250== malloc/free: in use at exit: 0 bytes
--- Comment #4 from paolo dot carlini at oracle dot com 2009-05-06 11:25
---
Benjamin, can you have a look?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40038
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40038
--- Comment #19 from singler at gcc dot gnu dot org 2009-05-06 11:21
---
Subject: Bug 39546
Author: singler
Date: Wed May 6 11:20:35 2009
New Revision: 147169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147169
Log:
2009-05-06 Johannes Singler
PR libstdc++/39546
--- Comment #16 from matz at gcc dot gnu dot org 2009-05-06 11:20 ---
Joseph: I'd need some advise where best starting to fix this. I see some
options, when we want to deal with such construct:
struct S { T member __attribute__((packed)); };
... struct S s; ... &s->member ...
(1) make
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
Version|unknown |4.5.0
http:/
The following valid testcase triggers an ICE on trunk when compiled with "-O":
===
struct A
{
~A();
void foo();
};
void bar()
{
A a;
try
{
A b;
try
{
b.foo();
}
catch (int) {}
}
catch (int) {}
}
===
bug.cc:
1 - 100 of 138 matches
Mail list logo
