--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-19 22:10
---
Subject: Bug 26558
Author: reichelt
Date: Wed Apr 19 22:10:10 2006
New Revision: 113098
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113098
Log:
PR c++/26558
* parser.c (cp_parser_class_n
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-04-19 22:12
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
This testcase fails on these two targets because the alignment of doubles in a
struct depend on where the field is. Since the double is second in one struct
but first in the other, the alignment will be different.
--
Summary: g++.dg/ext/alignof2.C fails on powerpc-darwin (and
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-04-19 22:26
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #5 from law at gcc dot gnu dot org 2006-04-19 22:34 ---
Subject: Bug 26854
Author: law
Date: Wed Apr 19 22:34:41 2006
New Revision: 113099
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113099
Log:
PR tree-optimization/26854
* tree-ssa-dse.c (dse_opti
--- Comment #4 from kkojima at gcc dot gnu dot org 2006-04-19 22:41 ---
Thanks. I'll commit it with the ChangeLog entry below if the usual
bootstrap/regtest on sh4-unknown-linux-gnu is done successfully.
PR target/27182
* config/sh/sh.md (movsicc_true+3): Tweak conditio
Hello, this code fails:
> #include
> #include
> #define M 3
> #define N 3
>
> int
> main ()
> {
> unsigned int contador_x, contador_y, x = 0;
> unsigned int map[M][N] = { {1, 2, 3}, {4, 5, 6}, {7, 8, 9} };
> unsigned int (*m2)[M][N] = ↦
>
> /* unsigned int (*m)[][] = ↦*/
> /* void *
--- Comment #5 from paolo at gcc dot gnu dot org 2006-04-19 22:58 ---
Subject: Bug 26424
Author: paolo
Date: Wed Apr 19 22:58:23 2006
New Revision: 113100
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113100
Log:
2006-04-19 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26424
--- Comment #7 from dtemirbulatov at gmail dot com 2006-04-19 23:25 ---
this bug could be fixed my backporting this patch:
2005-12-11 Daniel Berlin <[EMAIL PROTECTED]>
* timevar.def (TV_IPA_PTA): New.
* tree-pass.h (pass_ipa_pta): New
* tree-ssa-structalias.c: In
--- Comment #7 from carlos at gcc dot gnu dot org 2006-04-20 00:21 ---
Subject: Bug 26774
Author: carlos
Date: Thu Apr 20 00:21:51 2006
New Revision: 113107
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113107
Log:
gcc/
2006-04-19 Carlos O'Donell <[EMAIL PROTECTED]>
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-04-20 01:54 ---
Subject: Bug 27182
Author: kkojima
Date: Thu Apr 20 01:54:20 2006
New Revision: 113109
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113109
Log:
PR target/27182
* config/sh/sh.md (movsicc_tr
--- Comment #3 from wszafran at users dot sourceforge dot net 2006-04-20
01:59 ---
Just confirmed that the fix works with the patched CygWin-bootstrapped compiler
as well.
Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
--- Comment #6 from kkojima at gcc dot gnu dot org 2006-04-20 02:03 ---
Subject: Bug 27182
Author: kkojima
Date: Thu Apr 20 02:03:47 2006
New Revision: 113110
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113110
Log:
PR target/27182
* config/sh/sh.md (movsicc_tr
--- Comment #6 from igodard at pacbell dot net 2006-04-20 02:43 ---
Don't know what to do then - the actual failing binary comprises 200k lines
over a hundred or so modules, all in our internal build environment.
The problem pretty clearly had something to do with overloading operator,
--- Comment #6 from amodra at bigpond dot net dot au 2006-04-20 03:04
---
Ditto on powerpc-linux, due to NULL for_stmt.
#0 extract_omp_for_data (for_stmt=0x0, fd=0xffa80d78)
at /src/gcc-current/gcc/omp-low.c:157
#1 0x10106a10 in expand_parallel_call (region=0x10792098, bb=0x40104
--- Comment #6 from lucier at math dot purdue dot edu 2006-04-20 03:18
---
Subject: Re: Inordinate compile times on large routines
Thanks a lot. Here are the timing statistics (with --disable-
checking) after your patch.
PS: I'm sorry it took 9 hours to compile on your box.
Memor
--- Comment #7 from law at redhat dot com 2006-04-20 03:28 ---
Subject: Re: Inordinate compile times on
large routines
On Thu, 2006-04-20 at 03:18 +, lucier at math dot purdue dot edu
wrote:
>
> --- Comment #6 from lucier at math dot purdue dot edu 2006-04-20 03:18
>
--- Comment #8 from lucier at math dot purdue dot edu 2006-04-20 03:39
---
Subject: Re: Inordinate compile times on large routines
On Apr 19, 2006, at 10:28 PM, law at redhat dot com wrote:
> You'll likely get radically different pain points with mainline
> as well. The RTL loop in
--- Comment #7 from bangerth at dealii dot org 2006-04-20 03:46 ---
(In reply to comment #6)
> The problem pretty clearly had something to do with overloading operator,()
> and
> a call inside the STL leaking out to an overload in our code, because it went
> away when I changed the name
--- Comment #8 from bangerth at dealii dot org 2006-04-20 04:13 ---
Thinking about it some more, I can come up with something. Take this
code here:
-
class specReg{};
template
int operator,(int i, T t) { abort(); return i; }
#include
int main()
{
std::vector v;
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-04-20 06:21
---
Created an attachment (id=11300)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11300&action=view)
tonto-1.0 input file stdin.h.uhf
With this attachment as input I get a successful output with tonto-1.0.
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-04-20 06:25
---
Created an attachment (id=11301)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11301&action=view)
tonto-1.0 output for stdin.h.uhf
Here is the output from the above patch. When I go to stdin.h2o.blyp I ge
101 - 123 of 123 matches
Mail list logo
