--- Comment #3 from b3timmons at speedymail dot org 2009-10-31 05:57
---
Created an attachment (id=18941)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18941&action=view)
bzip2ed preprocessed source triggering failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41889
--- Comment #2 from b3timmons at speedymail dot org 2009-10-31 05:51
---
Created an attachment (id=18940)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18940&action=view)
gzipped preprocessed source triggering failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41889
--- Comment #1 from b3timmons at speedymail dot org 2009-10-31 05:49
---
Created an attachment (id=18939)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18939&action=view)
gzipped preprocessed source triggering failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41889
gcc -B. -r -nostdlib dispatch.i -v -Wall -Wextra -O2 -fno-omit-frame-pointer
-ftracer -fsched2-use-superblocks
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/b3po/bui
--- Comment #1 from b3timmons at speedymail dot org 2009-10-31 05:39
---
Created an attachment (id=18938)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18938&action=view)
gzipped preprocessed source triggering failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41888
gcc -B. -r -nostdlib edid.i -v -Wall -Wextra -O -ftree-loop-distribution
-fgraphite-identity -g
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/b3po/build/gcc/gcc/conf
--- Comment #1 from b3timmons at speedymail dot org 2009-10-31 05:38
---
Created an attachment (id=18937)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18937&action=view)
preprocessed source triggering failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41887
gcc -B. -r -nostdlib edid.i -v -Wall -Wextra -O -ftree-loop-distribution
-fgraphite-identity -g
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/b3po/build/gcc/gcc/conf
--- Comment #1 from b3timmons at speedymail dot org 2009-10-31 05:24
---
Created an attachment (id=18936)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18936&action=view)
gzipped preprocessed source triggering failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41886
gcc -B. -r -nostdlib mibitblt.i -v -Wall -Wextra -O -ftree-loop-distribution
-ftree-vectorize -g
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/b3po/build/gcc/gcc/con
--- Comment #3 from anhvofrcaus at gmail dot com 2009-10-31 02:22 ---
My binutils may be not be recent enough. Thus, I just updated to the latest
binutils. Currently, I am attempting to repeat the build. I will update the
status after it is complete.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-10-31 01:49
---
I will be busy for a while so unassignning to allow others to give it a go.
What remains is reading in kind=10 and kind=16 reals with BOZ format.
--
jvdelisle at gcc dot gnu dot org changed:
Wha
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2009-10-31 00:38
---
Subject: Bug 41885
Author: hutchinsonandy
Date: Sat Oct 31 00:38:10 2009
New Revision: 153773
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153773
Log:
PR target/41885
* gcc.target/avr/torture/pr418
Rotate patterns that split byte sized rotates into moves do not correctly
consider overlap of operands.
This was noted on a similar but different shift bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39635
and detailed here
http://lists.gnu.org/archive/html/avr-gcc-list/2009-03/msg00158.html
This is a tracker bug for a conversation held last week between Paolo, Jason,
and myself during the ISO C++ meeting in Santa Cruz.
Is there a way to better disambiguate the error from the error context? One
thing discussed that seemed like it had potential was to
error:
first and then provide
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-30 22:50 ---
But:
static unsigned int
tree_complete_unroll_inner (void)
{
unsigned ret = 0;
loop_optimizer_init (LOOPS_NORMAL
| LOOPS_HAVE_RECORDED_EXITS);
if (number_of_loops () > 1)
{
sc
--- Comment #1 from b3timmons at speedymail dot org 2009-10-30 22:48
---
Created an attachment (id=18935)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18935&action=view)
gzipped preprocessed source triggering failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41883
gcc -B. -r -nostdlib extension.i -v -Wall -Wextra -O -fprofile-arcs
-fsched2-use-superblocks -ftree-vrp -fschedule-insns2 -freorder-blocks
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Co
--- Comment #3 from drow at gcc dot gnu dot org 2009-10-30 22:41 ---
Subject: Re: Complete unrolling (inner)
versus vectorization of reduction
On Fri, Oct 30, 2009 at 10:20:46PM -, rguenth at gcc dot gnu dot org wrote:
> You could use -O2 -ftree-vectorize.
No:
static bool
gate_t
--- Comment #21 from jb at gcc dot gnu dot org 2009-10-30 22:37 ---
Subject: Bug 41219
Author: jb
Date: Fri Oct 30 22:37:47 2009
New Revision: 153769
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153769
Log:
PR libfortran/41219 Fix build warnings
Modified:
trunk/libgfortra
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-30 22:31 ---
>it's always been consistent.
Really because signed overflow has been undefined since K&R C and in fact
signed integer could be represented as one-comp or just with a sign bit.
--
http://gcc.gnu.org/bugzilla/
--- Comment #2 from daven at model dot com 2009-10-30 22:28 ---
Subject: Re: gcc bug when comparing x to -x (linux, 32-bit)
Thanks for your quick response. I would like to point out that on every
compiler and machine
I've used, the behavior of signed overflow may not be defined -- b
--- Comment #2 from burnus at gcc dot gnu dot org 2009-10-30 22:26 ---
Other things to check:
- Allocate/deallocate: works? Gives an error when needed?
- Allocatable DT with allocatable components (init when allocating; auto
dealloc when going out of scope and for intent(out))
- Default
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-30 22:23 ---
signed overflow invokes undefined behavior. You can use -fwrapv to make it
wrapping. Or you can use unsigned types for the comparison, like
if ((unsigned)x != -(unsigned)x)
--
rguenth at gcc dot gnu dot org c
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-30 22:21 ---
See also PR41647.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsO
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-30 22:20 ---
You could use -O2 -ftree-vectorize.
Another pretty straight-forward way to write the operation is
TYPE fun3(TYPE *x, TYPE *y, unsigned int n)
{
int i, j;
TYPE dot = 0;
for (i = 0; i < n / 8; i++)
{
We have some legacy code that checks for INT_MIN via the
test "if (x != -x)".
With gcc 4.3.3 this test is optimized out.
Now is this wrong or right to do -- I don't know. If so, perhaps someone
could describe the reasons for me.
However -- consider the following simple code:
-- cut here (l.c)
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-10-30 22:12 ---
It's still broken. Paolo, any chance you could have a look? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41569
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-10-30 22:10 ---
It didn't have any effect on the regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
--- Comment #8 from vmakarov at redhat dot com 2009-10-30 21:57 ---
Unfortunately, not yet because I had some failures after applying the patch. I
postponed work on this but now I have time to continue the work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
--- Comment #10 from sje at cup dot hp dot com 2009-10-30 21:54 ---
I am not sure if this would help or not but it might be interesting to try the
-mno-sdata flag on the compilation to see if that helps. By default GCC on
IA64 will use .sbss (short bss) and .bss (normal bss) sections.
--- Comment #9 from sje at cup dot hp dot com 2009-10-30 21:34 ---
> I thought the report and log was clear enough on the fact that this is
> indeed a problem that only arises during the final link. If not, then
> now it is ;)
I guess the point I was trying to make is that I don't think
--- Comment #8 from T-Bone at parisc-linux dot org 2009-10-30 21:23 ---
Subject: Re: Too small .bss stack
On Fri, Oct 30, 2009 at 9:15 PM, sje at cup dot hp dot com
wrote:
>
>
> --- Comment #7 from sje at cup dot hp dot com  2009-10-30 20:15 ---
> I tried (and failed) to repr
--- Comment #7 from sje at cup dot hp dot com 2009-10-30 21:00 ---
Has a patch to move update_equiv_regs into its own pass been submitted?
I don't see one and IA64 is still producing the 'wrong' scheduling.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #8 from sje at cup dot hp dot com 2009-10-30 20:42 ---
It looks like a patch has been checked in to fix this bug, is there any reason
we can't close this defect?
--
sje at cup dot hp dot com changed:
What|Removed |Added
Here are two pretty straight-forward ways to write the same operation:
#define TYPE int
TYPE fun1(TYPE *x, TYPE *y, unsigned int n)
{
int i, j;
TYPE dot = 0;
for (i = 0; i < n; i++)
dot += *(x++) * *(y++);
return dot;
}
TYPE fun2(TYPE *x, TYPE *y, unsigned int n)
{
int i, j;
TY
--- Comment #7 from sje at cup dot hp dot com 2009-10-30 20:15 ---
I tried (and failed) to reproduce this using msmpeg4.i and compiling with:
gcc -shared -pthread -std=c99 -fomit-frame-pointer -g -O3 -fno-math-errno
-fno-signed-zeros -fPIC -fno-tree-vectorize msmpeg4.i -o x.so
I tried
--- Comment #43 from paolo dot carlini at oracle dot com 2009-10-30 19:39
---
Ok, thanks a lot for the benchmarks, I'll try to come to the numbers as soon as
possible. However, I suggest posting to the mailing list, to make sure all the
interested people follow the discussion. Also, as
--- Comment #42 from potswa at mac dot com 2009-10-30 19:14 ---
Sorry, "once per ring" doesn't guarantee more than one pass for k=2 and n odd,
or the test case I presented. Better to say there are k passes, although
performance should improve for n/k on the order of cache associativity.
--- Comment #41 from potswa at mac dot com 2009-10-30 19:07 ---
Created an attachment (id=18934)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18934&action=view)
table of benchmarks comparing various algorithms and parameters
As the Euclidean ring division algorithm sweeps the mem
--- Comment #1 from espindola at gcc dot gnu dot org 2009-10-30 18:31
---
Fixed on revision 153764.
--
espindola at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from jamborm at gcc dot gnu dot org 2009-10-30 18:22
---
Thanks for the simple testcase, it has certainly helped me. I have
sent a patch to address this issue to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01814.html
--
http://gcc.gnu.org/bugzil
--- Comment #2 from ysato at users dot sourceforge dot jp 2009-10-30 18:20
---
(From update of attachment 18933)
Please remove /* */
sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41880
--- Comment #1 from ysato at users dot sourceforge dot jp 2009-10-30 18:17
---
Created an attachment (id=18933)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18933&action=view)
groundless patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41880
configure --target=rx-elf --disable-ssp --disable-libssp
Build log.
libbackend.a(emit-rtl.o): In function `verify_rtx_sharing':
/home/ysato/rx/gcc-4.5-20091029/rx/gcc/../../gcc/emit-rtl.c:2449: undefined
reference to `CONSTANT_ADDRESS_P'
libbackend.a(explow.o): In function `break_out_memory_refs':
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-10-30 17:57 ---
(In reply to comment #1)
> gcc-4.5-20091008 snapshot was used. By the way, gcc-4.4.2-RC-20091008 works
> fine.
>
Could you please give us your configuration line? We do bootstraps (until Stage
3) with current 4.5 gc
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-10-30 17:52 ---
Well, I meant of course 4.4 branch. I won't backport this. So I closed this
bug.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-10-30 17:49 ---
hjl: is the fix really for this PR? Reported errors still persists after
applying it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
--- Comment #3 from paolo at gcc dot gnu dot org 2009-10-30 17:39 ---
Subject: Bug 41759
Author: paolo
Date: Fri Oct 30 17:39:18 2009
New Revision: 153762
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153762
Log:
2009-10-30 Paolo Carlini
PR libstdc++/41759
*
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-30 17:00 ---
With vectorization enabled I get
Running /home/richard/src/trunk/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ...
FAIL: gcc.dg/tree-ssa/predcom-1.c scan-tree-dump-times pcom "looparound ref" 1
FAIL: gcc.dg/tree-ssa/pr
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-30 16:57 ---
Testcase:
SUBROUTINE PSINV(R,U,C)
PARAMETER (N=64)
REAL*8 U(N,N,N),R(N,N,N),C(0:3)
INTEGER I3, I2, I1
C
DO 600 I3=2,N-1
DO 600 I2=2,N-1
DO 600 I1=2,N-1
600 U(I1,I2,I3)=U(I
The fix for PR41783 causes us to vectorize RESID and PSINV where we only
predictive common the epilogue loop now. This causes mgrid score to drop
by almost 40% on x86_64 and the vectorized code is pretty bad because it
uses unaligned accesses.
--
Summary: [4.5 Regression] 172.mgrid r
On Linux/ia64, I got
ERROR: gfortran.dg/vect/vect-2.f90 -O : error executing dg-final: syntax error
in target selector "target ! vector_alignment_reachable"
Apparently,
{ target { vect_no_align && { {! vector_alignment_reachable } } } }
doesn't work. But
{ target { vect_no_align && { ! vector
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-10-30 16:39
---
In fact we now vectorize additional loops because of less prephitemps but
that gets in the way of predictive-commoning which is much more useful here :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
--- Comment #40 from paolo dot carlini at oracle dot com 2009-10-30 16:30
---
The last attached patch is also not ok wrt move-only types, the special case
for __k == 1 that is (trivially replacing copy -> _GLIBCXX_MOVE3 doesn't fix
it). Before going ahead this way, I would also like to
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-10-30 16:14
---
I think this fix caused 172.mgrid to regress (we likely no longer perform
predictive commoning there). See
http://gcc.opensuse.org/SPEC/CFP/sb-vangelis-head-64/recent.html
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #4 from hjl at gcc dot gnu dot org 2009-10-30 16:05 ---
Subject: Bug 41673
Author: hjl
Date: Fri Oct 30 16:04:41 2009
New Revision: 153759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759
Log:
2009-10-30 H.J. Lu
Backport from mainline:
2009-1
--- Comment #14 from hjl at gcc dot gnu dot org 2009-10-30 16:05 ---
Subject: Bug 41497
Author: hjl
Date: Fri Oct 30 16:04:41 2009
New Revision: 153759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759
Log:
2009-10-30 H.J. Lu
Backport from mainline:
2009-
--- Comment #14 from hjl at gcc dot gnu dot org 2009-10-30 16:05 ---
Subject: Bug 41020
Author: hjl
Date: Fri Oct 30 16:04:41 2009
New Revision: 153759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759
Log:
2009-10-30 H.J. Lu
Backport from mainline:
2009-
--- Comment #10 from hjl at gcc dot gnu dot org 2009-10-30 16:05 ---
Subject: Bug 41345
Author: hjl
Date: Fri Oct 30 16:04:41 2009
New Revision: 153759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759
Log:
2009-10-30 H.J. Lu
Backport from mainline:
2009-
--- Comment #8 from hjl at gcc dot gnu dot org 2009-10-30 16:05 ---
Subject: Bug 41775
Author: hjl
Date: Fri Oct 30 16:04:41 2009
New Revision: 153759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759
Log:
2009-10-30 H.J. Lu
Backport from mainline:
2009-1
--- Comment #6 from hjl at gcc dot gnu dot org 2009-10-30 16:05 ---
Subject: Bug 41801
Author: hjl
Date: Fri Oct 30 16:04:41 2009
New Revision: 153759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759
Log:
2009-10-30 H.J. Lu
Backport from mainline:
2009-1
--- Comment #5 from hjl at gcc dot gnu dot org 2009-10-30 16:05 ---
Subject: Bug 40033
Author: hjl
Date: Fri Oct 30 16:04:41 2009
New Revision: 153759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759
Log:
2009-10-30 H.J. Lu
Backport from mainline:
2009-1
--- Comment #5 from hjl at gcc dot gnu dot org 2009-10-30 16:05 ---
Subject: Bug 41863
Author: hjl
Date: Fri Oct 30 16:04:41 2009
New Revision: 153759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759
Log:
2009-10-30 H.J. Lu
Backport from mainline:
2009-1
--- Comment #10 from hjl at gcc dot gnu dot org 2009-10-30 16:05 ---
Subject: Bug 41785
Author: hjl
Date: Fri Oct 30 16:04:41 2009
New Revision: 153759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759
Log:
2009-10-30 H.J. Lu
Backport from mainline:
2009-
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-10-30 15:59 ---
Subject: Bug 41858
Author: rguenth
Date: Fri Oct 30 15:58:57 2009
New Revision: 153758
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153758
Log:
2009-10-30 Richard Guenther
PR lto/41858
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-10-30 15:58
---
Even shorter C testcase:
===
struct A {};
int foo();
struct A bar(double x)
{
double y;
if (foo())
y = 1 / x;
return bar(y);
}
===
--
reichelt at gcc
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-10-30 15:52
---
Confirmed. Even shorter testcase (crashes with "-O2
-fno-ira-share-save-slots"):
==
struct A
{
A(double);
};
int foo();
A bar(double x)
{
double y;
if (foo())
y = 1 / x;
retur
--- Comment #64 from hjl at gcc dot gnu dot org 2009-10-30 15:45 ---
Subject: Bug 40838
Author: hjl
Date: Fri Oct 30 15:45:23 2009
New Revision: 153757
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153757
Log:
gcc/
2009-10-30 H.J. Lu
Backport from mainline:
--- Comment #2 from burnus at gcc dot gnu dot org 2009-10-30 15:32 ---
I agree that the following error is bogus:
>print *, ipmin% dot_g_g (g,g)
>1
> Error: ABSTRACT INTERFACE 'dot' must not be referenced at (1)
While one might not access (type)%dot_g_g as "dot_g_g" is
--- Comment #16 from burnus at gcc dot gnu dot org 2009-10-30 15:18 ---
Subject: Bug 41777
Author: burnus
Date: Fri Oct 30 15:18:09 2009
New Revision: 153756
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153756
Log:
2009-10-30 Tobias Burnus
PR fortran/41777
--- Comment #1 from jlquinn at gcc dot gnu dot org 2009-10-30 14:47 ---
I've reverted the patch causing the problem.
--
jlquinn at gcc dot gnu dot org changed:
What|Removed |Added
On Linux/ia32, revision 153734:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg01390.html
caused:
FAIL: abi_check
FAIL: g++.dg/cpp0x/decltype17.C execution test
--
Summary: [4.5 regression] Revision 153734 failed libstdc++ tests
Product: gcc
Version: 4.5.0
--- Comment #5 from burnus at gcc dot gnu dot org 2009-10-30 14:33 ---
Patch: http://gcc.gnu.org/ml/fortran/2009-10/msg00246.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #63 from hjl at gcc dot gnu dot org 2009-10-30 14:32 ---
Subject: Bug 40838
Author: hjl
Date: Fri Oct 30 14:32:26 2009
New Revision: 153750
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153750
Log:
Optimize -mstackrealign.
gcc/
2009-10-30 H.J. Lu
PR ta
--- Comment #10 from hjl at gcc dot gnu dot org 2009-10-30 14:32 ---
Subject: Bug 40836
Author: hjl
Date: Fri Oct 30 14:32:26 2009
New Revision: 153750
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153750
Log:
Optimize -mstackrealign.
gcc/
2009-10-30 H.J. Lu
PR ta
--- Comment #1 from ramana at gcc dot gnu dot org 2009-10-30 13:15 ---
Patch submitted here. http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01792.html
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-10-30 12:41
---
Your case is mentioned in comment #2 of PR18747.
*** This bug has been marked as a duplicate of 18747 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-10-30 12:41
---
*** Bug 41875 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2009-10-30 12:24
---
Ok, let's close it as invalid. For the record, Comeau 4.3.10.1 Beta2 also
rejects it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from redi at gcc dot gnu dot org 2009-10-30 12:15 ---
(In reply to comment #3)
> I think it is a bug, because the class test is declared at the scope ::
A friend declaration specifies a class that belongs to the innermost enclosing
namespace scope, outer scopes are not co
--- Comment #4 from redi at gcc dot gnu dot org 2009-10-30 12:14 ---
(In reply to comment #2)
> Isn't ::foo the using'd class from name?
No, see 7.3.1.2 [namespace.memdef]/3 - an unqualified friend declaration refers
to a member of the innermost enclosing namespace. Names brought into a
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.0 |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41876
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41876
The following valid code snippet is rejected since GCC 3.4.0:
==
struct A;
void foo()
{
try {} catch(int A) {}
}
==
bug.cc: In function 'void foo()':
bug.cc:5:20: error: two or more data types in declaration of 'type name'
--
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2009-10-30 10:16
---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01790.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41302
--- Comment #4 from burnus at gcc dot gnu dot org 2009-10-30 10:16 ---
(In reply to comment #3)
> Anything else?
Seemingly yes:
gfortran.dg/optional_dim_3.f90
gfortran.dg/random_4.f90
gfortran.dg/random_7.f90
For optional_dim_3.f90, one has:
- D.1516 = n2 != 0B ? (integer
The contents of the source file a.cpp:
struct A{};
template <> A a;
It gets compiled with no error generated.
$ g++ -v -save-temps -c a.cpp
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-sha
--- Comment #4 from dodji at gcc dot gnu dot org 2009-10-30 07:09 ---
Fixed in 4.5.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #3 from dodji at gcc dot gnu dot org 2009-10-30 07:09 ---
Subject: Bug 41863
Author: dodji
Date: Fri Oct 30 07:08:36 2009
New Revision: 153735
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153735
Log:
Fix PR c++/41863
gcc/cp/ChangeLog:
PR c++/41863
95 matches
Mail list logo
