--- Comment #7 from ubizjak at gmail dot com 2009-09-29 06:29 ---
(In reply to comment #6)
Problem still happens with 4.5.0 20090928 (experimental) [lto revision 152240]
(lto merged with rev 150842).
Without the langhooks.c patch -flto is currently unusable/untestable
(ICEs on
When running trunk -r 152114 on powerpc64 with these flags (which enable the
Graphite identity transformation) I get the following ICE on most of SPEC2006
benchmarks: (the following is take from 429.mcf)
/home/eres/mainline_45/build/bin/gcc -c -o pbeampp.o -DSPEC_CPU -DNDEBUG
-DWANT_STDC_PROTO
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-29 07:23 ---
Fails on x86_64-linux too, the bug first appears in sccp.
extern void abort (void);
static unsigned short
bar (unsigned short x, unsigned short y)
{
return x + y;
}
unsigned int a;
unsigned char b, c;
void
foo
--- Comment #5 from domob at gcc dot gnu dot org 2009-09-29 07:43 ---
Subject: Bug 39626
Author: domob
Date: Tue Sep 29 07:42:42 2009
New Revision: 152266
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152266
Log:
2009-09-29 Daniel Kraft d...@domob.eu
PR fortran/39626
--- Comment #6 from domob at gcc dot gnu dot org 2009-09-29 07:48 ---
Committed my patch linked above. This implements basic BLOCK support (what I
as a user would reasonably expect it to behave) but misses a lot of finer
details; I'll keep the PR open for those.
See my mailing list
--- Comment #7 from domob at gcc dot gnu dot org 2009-09-29 07:49 ---
Also, Tobias mentioned (in the linked thread):
The patch looks good to me. It sometimes makes the diagnostics less
useful, e.g. for
recursive function func(i)
integer :: i, func
func = 1
entry func2(i)
block
--- Comment #9 from michael dot haubenwallner at salomon dot at 2009-09-29
08:09 ---
(In reply to comment #6)
Can you try GCC 4.3.2 and see if that fails for you?
Still failing with gcc-4.3.3 and gcc-4.4.1: The stage1 xgcc starts doing ICE
once its libgcc_s.a is built, because
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 09:49 ---
Can you provide preprocessed source?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 09:51 ---
Thus, confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41496
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 09:53 ---
I'll add a testcase after the merge.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 10:01 ---
I wonder why it uses the extra temporary - that shouldn't be necessary.
Ah, it's because of
else if (ts.type == BT_DERIVED)
{
gfc_add_block_to_block (block, lse-pre);
gfc_add_block_to_block
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-29 10:02 ---
Let's add a testcase after the merge.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41173
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-29 10:03 ---
Please attach preprocessed source.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-09-29 10:04 ---
And s390(x).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-09-29 10:08 ---
Diego, can't we simply drop the assemble_align call from lhd_begin_section?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
--- Comment #8 from chris at bubblescope dot net 2009-09-29 11:04 ---
Just to clarify, it is not a memory leak which is occurring, it is memory
corruption. Basically when std::sort is given a type which is not totally
ordered as required, it tends to corrupt the memory immediately
--- Comment #9 from paolo dot carlini at oracle dot com 2009-09-29 11:55
---
In C++03 this is not a bug. However, I seem to vaguely remember a recent
discussion in the committee (basing on either a paper or a DR) about
comparisons of floats, if somebody can find a reference I would
The hot loop in SPEC2000/179.art scanner.c (line 615) does not get vectorized
due to data ref analysis failure:
(The original loop contains invariant store which I manually extracted out of
the loop. Will try to generate a testcase.)
Taken from the vectorizer dump:
(instantiate_scev
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-29 12:09 ---
Hm. Even lto_read_file_options causes unaligned accesses in some cases. It
looks
like the ELF sections in the wpa files are no aligned:
Section Headers:
[Nr] Name Type Address
--- Comment #1 from eres at il dot ibm dot com 2009-09-29 12:14 ---
I was using trunk -r152153 and run on powerpc64.
--
eres at il dot ibm dot com changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-09-29 12:56
---
Subject: Bug 40392
Author: rguenth
Date: Tue Sep 29 12:56:29 2009
New Revision: 152274
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152274
Log:
2009-09-29 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-29 12:56 ---
Subject: Bug 40754
Author: rguenth
Date: Tue Sep 29 12:56:29 2009
New Revision: 152274
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152274
Log:
2009-09-29 Richard Guenther rguent...@suse.de
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 12:56 ---
Subject: Bug 41467
Author: rguenth
Date: Tue Sep 29 12:56:29 2009
New Revision: 152274
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152274
Log:
2009-09-29 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-29 12:57 ---
Subject: Bug 41444
Author: jakub
Date: Tue Sep 29 12:56:46 2009
New Revision: 152275
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152275
Log:
PR testsuite/41444
* gcc.dg/guality/guality.h
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-09-29 12:58
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-29 12:58 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-29 12:58 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 12:58 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Since 4.4 i'm unable to rebuild gcc, check downstream bug:
http://bugs.gentoo.org/286251
Steps to reproduce:
- extract gcc-4.4.1 tarball
-./configure
-make LDFLAGS=-Wl,-O1 STAGE1_CFLAGS=-O
LIBPATH=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.4.1 'BOOT_CFLAGS=
-march=armv5te -pipe -O2'
gcc-4.4.2 testsuite failures:
FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE
using binutils 2.20.51.20090927
Copying sources to a temporary directory and repeating commands used by
testsuite
--- Comment #1 from laurent at guerby dot net 2009-09-29 13:32 ---
This happens also on arm-linux at rev 152122
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02662.html
.,. C34006G ACATS 2.5 09-09-28 14:27:54^M
C34006G CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED
--- Comment #2 from joel at gcc dot gnu dot org 2009-09-29 13:35 ---
Add powerpc-rtems4.10 to the list of targets that fail.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from laurent at guerby dot net 2009-09-29 13:38 ---
Together with PR41493 these are the only two ACATS fail on arm-linux as of rev
152122:
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02662.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41325
gcc.dg/attr-warn-unused-result.c ICEs in
Program received signal SIGSEGV, Segmentation fault.
0x00c790bc in expand_call_inline (bb=0x771a0a10,
stmt=0x77198000, id=0x7fffd810)
at /space/rguenther/src/svn/lto/gcc/tree-inline.c:3661
3661 gcc_assert
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 13:46 ---
Reduced testcase, fails at -O1:
typedef void (*fnt) (void);
extern inline void check3 (void)
{
bar ();
}
void test (void)
{
const fnt pcheck3 = check3;
pcheck3 ();
}
all details important: extern, the call
--- Comment #31 from jamborm at gcc dot gnu dot org 2009-09-29 13:49
---
(In reply to comment #12)
Thus I believe SRA has nothing to
do with these remaining failures. If you want to confirm this
independently, compile them with -fno-tree-sra.
...and so I un-assign this bug from
function_parameter_expanded_from_pack_p() segfaults when compiling
20_util/reference_wrapper/24803.cc and IPA-SRA turned on. The reason
is that it is presented a PARM_DECL that was created by IPA-SRA and
which does not have language specific data.
The backtrace is:
#0 0x004b872f in
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 14:04 ---
static void
ipa_passes (void)
{
...
/* Remove the bodies of extern inline functions that we never
inlined. */
cgraph_remove_unreachable_nodes (false, dump_file);
that's bogus and too early.
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-29 14:20 ---
Papered over.
./xgcc -B. -o t.o -shared attr-warn-unused-result.3.i -O -fPIC -flto
still ICEs the old way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41502
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-29 14:21 ---
Subject: Bug 41502
Author: rguenth
Date: Tue Sep 29 14:20:37 2009
New Revision: 152277
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152277
Log:
2009-09-29 Richard Guenther rguent...@suse.de
*
Hello,
Compile the following file with gcc:
void s () {
pthread_cancel();
/*pthread_mutex_trylock (); */
}
and the following file with gfortran:
program test
print*, Bug
end program test
Link both files using gfortran -static -pthread. Note that the program dies
with SEGV in
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 14:31 ---
You need to link libpthread.a with -Wl,--whole-archive
In general static linking is not recommended with glibc and threads.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-29 14:40 ---
My http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02070.html patch fixes this
too.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-29 14:58 ---
This was fixed on the trunk, I don't have the changelog entry handy though, but
it was done by Jakub IIRC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41501
--- Comment #2 from DumaShkurko at gmail dot com 2009-09-29 15:09 ---
Is it possible to adjust specs file for -static and/or -pthread?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41504
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41479
Consider:
foo(int *x)
{
*x = 0;
}
Compile with -Os -fomit-frame-pointer and you'll get something like this:
movl4(%esp), %eax
movl$0, (%eax)
It would be 2 bytes shorter to instead load the constant 0 via an xor
instruction into a scratch register, then store the
Every gcov test in the gcov testsuite
( gcc/testsuite/gcc.misc-tests/gcov.exp )
fails because gcov gets a SIGSEGV
on its first invocation of 'fgets()' -
'char *fgets_unlocked( char *buf, size_t size, FILE *stream )
'
is NOT declared, because '__USE_GNU' is NOT defined ;
__USE_GNU is
--- Comment #1 from jason dot vas dot dias at gmail dot com 2009-09-29
15:59 ---
Created an attachment (id=18666)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18666action=view)
Patch to fix gcov
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41506
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-29 16:06 ---
It would be helpful to know what you are patching, because neither 4.4 branch
nor trunk gcov.c has anything like that, see e.g.
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 16:07 ---
difficult
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-29 16:09 ---
Can't reproduce with x86_64-linux - s390x-linux cross (-O3 -m31).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41327
--- Comment #37 from jamborm at gcc dot gnu dot org 2009-09-29 16:16
---
(In reply to comment #34)
It is tree.o object of stage2 gcc that gets miscompiled when -fipa-sra is
added
to BOOT_CFLAGS. If tree.o is substituted with the one from the build without
BOOT_CFLAGS, gcc is again
The gfortran manual's documentation about MAXLOC/MINLOC is misleading. It
claims that the 'array' argument may be of CHARACTER type, which is true for
Fortran 2003.
However, the manual claims the intrinsic is Fortran 90/95 without further
notice about CHARACTER type being allowed only since
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-09-29 16:42 ---
The following patch fixes the problem, I will send it to the mailing
list soon:
2009-09-29 Martin Jambor mjam...@suse.cz
PR c++/41503
* cp/pt.c (function_parameter_expanded_from_pack_p): Return
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-09-29 16:52 ---
(In reply to comment #1)
The following patch fixes the problem, I will send it to the mailing
list soon:
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02105.html
--
--- Comment #2 from law at redhat dot com 2009-09-29 17:12 ---
I don't understand your comment Richard. Isn't it just something like this?
(define_peephole2
[(match_scratch:SI 2 r)
(set (match_operand:SI 0 memory_operand )
(match_operand:SI 1 const_0_operand ))]
[(set
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-29 17:34 ---
Subject: Bug 41438
Author: jakub
Date: Tue Sep 29 17:33:58 2009
New Revision: 152282
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152282
Log:
PR debug/41438
* dwarf2out.c
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-29 17:39 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-29 17:40 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-29 17:36 ---
Hi Janis, I think one of your patches causes this. It removed
-ansi -pedantic-errors -Wno-long-long in the second run for
--target_board 'unix{-m32,}'.
--
hjl dot tools at gmail dot com changed:
What
--- Comment #2 from hjl dot tools at gmail dot com 2009-09-29 18:02 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02117.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ro at gcc dot gnu dot org 2009-09-29 18:09 ---
Testing the trivial fix on Solaris 10/x86 to see how far this gets me.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl at gcc dot gnu dot org 2009-09-29 18:29 ---
Subject: Bug 41496
Author: hjl
Date: Tue Sep 29 18:29:24 2009
New Revision: 152287
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152287
Log:
2009-09-29 H.J. Lu hongjiu...@intel.com
PR testsuite/41496
--- Comment #38 from ubizjak at gmail dot com 2009-09-29 18:36 ---
(In reply to comment #37)
Can you please attach pre-processed source of it so that I can try
running it through a cross-compiler?
Additionally, -fdump-tree-cddce-slim and -fdump-tree-eipa_sra-details
dumps would
--- Comment #2 from ubizjak at gmail dot com 2009-09-29 18:47 ---
(In reply to comment #1)
This was fixed on the trunk, I don't have the changelog entry handy though,
but
it was done by Jakub IIRC.
2009-08-07 Jakub Jelinek ja...@redhat.com
* dwarf2out.c (output_fde):
I am currently porting an app from Sun Solaris where we use the Solaris cc
compiler (version 5.8). Have a 12 year old legacy app that compiles fine in
the current environment :-)
While trying to migrate to RedHat Linux and the GNU g++ compiler (version
4.1.2) I am repeatedly running into error:
--- Comment #16 from jv244 at cam dot ac dot uk 2009-09-29 18:59 ---
since graphite should be able to fix this PR, I tried it without luck:
gfortran -ffast-math -O3 -march=native -fgraphite -floop-interchange
-floop-block test.f90
test.f90: In function MAIN__:
test.f90:1:0: sorry,
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-29 19:15 ---
Can you show the line where the call to EJPeriod::EJPeriod is done? It might
be because String that you are passing is a rvalue which cannot be bound to
String as that would mean it needs to be bound to a lvalue.
--- Comment #2 from mwarshofsk at aol dot com 2009-09-29 19:24 ---
This is the method where I am receiving the compiler error:
enum err_stat EJPeriod::rollup( ListEmplJob src, ListEJPeriod dst,
Date startDt, Date endDt )
{
// then theres a bunch of code
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-09-29 19:25 ---
What type does get_job_title_mgmt_ind return?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
--- Comment #4 from mwarshofsk at aol dot com 2009-09-29 19:32 ---
Here's the definition for that call ... I think you're on to something
String get_job_title_mgmt_ind() const { return _jobTitleMgmtInd; };
When I change the constructor to non reference paramters it seems to compile
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-09-29 19:41 ---
Yes GCC is correct as in C++ rvalues don't bind to references as only lvalues
bind to references.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2009-09-29 20:03 ---
This is obsoleted by the newer idea in PR 41130.
*** This bug has been marked as a duplicate of 41130 ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2009-09-29 20:03 ---
*** Bug 39708 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-29 20:08 ---
If the ctor isn't going to change it, you could as well change the argument
type to const String instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
--- Comment #7 from mwarshofsk at aol dot com 2009-09-29 20:34 ---
Comment 6 is perfect! That makes total sense. Thanks so much! Actually, I bet
the Solaris compiler is implicitly treating this same code as a const String
behind the scenes. We'll just explicitly make that promise/fix
--- Comment #3 from ubizjak at gmail dot com 2009-09-29 20:45 ---
This is not alpha specific, but generic tree issue.
The _.optimized dump:
bb 2:
if (x_2(D) == 0)
goto bb 4;
else
goto bb 3;
bb 3:
D.2022_3 = x_2(D) + -1;
D.2023_4 = D.2022_3 x_2(D);
D.2016_9 =
--- Comment #4 from ubizjak at gmail dot com 2009-09-29 20:53 ---
In fact, this implements short-cut of boolean OR. Function returns early for x
== 0 and should not execute right part of OR expression in this case. Something
like:
if (x == 0 || (x (x - 1)) == 0)
return 1;
else
--- Comment #39 from rth at gcc dot gnu dot org 2009-09-29 20:54 ---
(In reply to comment #35)
static tree
build_function_type_list_1 (bool vaargs, tree return_type, va_list argp)
Passing va_list by value is non-portable. One fix here is to pass argp
by reference. Dunno if that
--- Comment #5 from falk at debian dot org 2009-09-29 21:02 ---
Of course the optimization would be wrong if the second clause had side
effects, but it doesn't and this will frequently be the case. So this is
definitely a valid and in my opinion worthwhile optimization.
--
--- Comment #3 from rth at gcc dot gnu dot org 2009-09-29 21:18 ---
There are already peepholes for this, though the condition appears to be
slightly wrong for -Os. See i386.md:21121 :
(define_peephole2
[(match_scratch:SI 1 r)
(set (match_operand:SI 0 memory_operand )
--- Comment #6 from ubizjak at gmail dot com 2009-09-29 21:18 ---
Not alpha specific, happens on current mainline, where on x86_64 we produce the
code as shown in comment #5.
I think that Richi will be interested in the fact that the usage of __restrict
does not change generated code
--- Comment #9 from ubizjak at gmail dot com 2009-09-29 21:41 ---
(In reply to comment #6)
Can someone check if this still fails on latest 4.3 branch?
It doesn't. See [1].
[1] http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01497.html
--
ubizjak at gmail dot com changed:
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-29 21:42 ---
I've looked at what code generation changes the jump from r151310 to r151312
(aka VTA merge) and on eon.cc at -O3 -funroll-loops -fpeel-loops on ia64-linux
the difference is that r151310 unroll something that r151312
--- Comment #6 from ubizjak at gmail dot com 2009-09-29 21:52 ---
This is fixed in 4.3+:
All fixinclude tests pass
make[2]: Leaving directory `/space/uros/gcc-build-43/fixincludes'
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2009-09-29 21:55 ---
(In reply to comment #1)
Also the date here is from before the big gcj-eclipse merge.
So, maybe things are different now.
Sure, they are fixed [1].
[1]: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01386.html
--- Comment #4 from law at redhat dot com 2009-09-29 21:55 ---
Subject: Re: GCC choosing poor code sequence for certain
stores (x86)
On 09/29/09 15:18, rth at gcc dot gnu dot org wrote:
--- Comment #3 from rth at gcc dot gnu dot org 2009-09-29 21:18 ---
There are already
--- Comment #1 from ubizjak at gmail dot com 2009-09-29 21:58 ---
(In reply to comment #0)
libstdc++ test 23_containers/vector/cons/4.cc fails:
No more [1].
[1] http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00242.html
--
ubizjak at gmail dot com changed:
What
--- Comment #1 from ubizjak at gmail dot com 2009-09-29 22:02 ---
Please try with newer gcc, 4.2.x is not supported anymore.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #10 from ubizjak at gmail dot com 2009-09-29 22:06 ---
Libjava has zero failures with gcc 4.3.5, 4.4.2 and 4.5.0 for me on latest
Gentoo. Please reopen if it still fails for you.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2009-09-29 22:12 ---
4.2.4 is not supported anymore. Please try with newer gcc.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from sje at gcc dot gnu dot org 2009-09-29 22:21 ---
Subject: Bug 41365
Author: sje
Date: Tue Sep 29 22:21:27 2009
New Revision: 152306
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152306
Log:
2009-09-29 Steve Ellcey s...@cup.hp.com
Alexander
--- Comment #4 from sje at cup dot hp dot com 2009-09-29 22:36 ---
Fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from debian-gcc at lists dot debian dot org 2009-09-29
22:44 ---
confirmed:
https://buildd.debian.org/fetch.cgi?pkg=gcc-snapshotver=20090923-1arch=alphastamp=1253933048file=log
https://buildd.debian.org/fetch.cgi?pkg=gcj-4.4ver=4.4.1-4arch=alphastamp=1252769258file=log
--- Comment #11 from debian-gcc at lists dot debian dot org 2009-09-29
22:45 ---
confirmed:
https://buildd.debian.org/fetch.cgi?pkg=gcc-snapshotver=20090923-1arch=alphastamp=1253933048file=log
https://buildd.debian.org/fetch.cgi?pkg=gcj-4.4ver=4.4.1-4arch=alphastamp=1252769258file=log
--- Comment #4 from debian-gcc at lists dot debian dot org 2009-09-29
22:47 ---
sorry, the last comment should have gone to PR33263, I'll need to find the time
to recheck this issue.
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41327
--- Comment #5 from debian-gcc at lists dot debian dot org 2009-09-29
22:48 ---
fixed
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
1 - 100 of 121 matches
Mail list logo
