--- Comment #14 from drangon dot mail at gmail dot com 2009-04-21 05:35
---
how to fix this multiple definition issue ?
adjust the linker to allow this ?
or remove the ordinary C library function in
lib64_libmingwex_a-wininterlocked.o and just keep the inline function ?
or remove th
I built a x86_64-pc-mingw32 toolchain from scratch with the newest code from
SVN ( 20090421 ).
and the build an application using wxWidgets library, it runs crashed.
(gdb) r
Starting program: E:\code\DMediaInfo/DMediaInfo.exe
[New Thread 2656.0xbd8]
warning: Can not parse XML library list; XML sup
--- Comment #1 from bje at gcc dot gnu dot org 2009-04-21 05:03 ---
Thanks for the report. Could you possibly attach the preprocessed source file
that triggers the internal compiler error?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39825
--- Comment #1 from bje at gcc dot gnu dot org 2009-04-21 05:02 ---
Confirmed in mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35260
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-04-21 03:04 ---
> I believe the problem is the symbol was exported when it shouldn't have been.
How?
> The signbit macro is provided by math.h.
But it's not in the baseline files showing that it is exported. This question
was origi
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-04-21 02:46 ---
I consider this undefined behaviour, so enhancement is the correct severity.
People wanting to mess with non-standard init order should probably be taking
steps to insure that libstdc++ is initialized first anyway. N
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-21 02:39 ---
(In reply to comment #4)
> Created an attachment (id=17661)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17661&action=view) [edit]
> Patch to fix the issue
>
> 2009-04-20 Jing Yu
>
>PR testsuite/3
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-04-21 02:23 ---
This is probably fixed in 4.3.3 via
2009-01-12 Benjamin Kosnik
Jonathan Larmour
PR libstdc++/36801
* config/cpu/generic/atomicity_mutex/atomicity.h (get_atomic_mutex):
New.
i386-darwin defaults to having -mfpmath=sse,387 by default so
gcc.target/i386/excess-precision-{1,2,3}.c fail because those testcases depend
on excessive precision to happen.
--
Summary: gcc.target/i386/excess-precision-*.c assume the default
-mfp-math does not inc
--- Comment #4 from jingyu at google dot com 2009-04-21 01:29 ---
Created an attachment (id=17661)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17661&action=view)
Patch to fix the issue
2009-04-20 Jing Yu
PR testsuite/39830
* gcc.dg/torture/pr39678.c: Change the
--- Comment #4 from eric dot niebler at gmail dot com 2009-04-21 01:10
---
I'm sorry to say that I no longer have access to the Linux machine on which I
gcc-4.3 installed. I have only my windows laptop now, and I can't for the life
of me get gcc-4.3 working under cygwin. I can, however,
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-21 00:55 ---
(In reply to comment #2)
> Subject: Re: gcc.dg/torture/pr39678.c fails if char type
> is unsigned
>
> Thanks H.J. for your quick response!
> Do you want me to prepare a patch?
Please do. Thanks.
--
--- Comment #2 from jingyu at google dot com 2009-04-21 00:54 ---
Subject: Re: gcc.dg/torture/pr39678.c fails if char type
is unsigned
Thanks H.J. for your quick response!
Do you want me to prepare a patch?
I don't have write permission though.
Thanks,
Jing
On Mon, Apr 20, 2
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-21 00:49 ---
(In reply to comment #0)
> On gcc.dg/torture/pr39678.c, it assigns -3 to a char variable ("x.c = -3") and
> later checks if the char variable equals to -3 ("if (x.c != 3)").
>
> This check would fail if the char typ
On gcc.dg/torture/pr39678.c, it assigns -3 to a char variable ("x.c = -3") and
later checks if the char variable equals to -3 ("if (x.c != 3)").
This check would fail if the char type is unsigned.
Suggest to change -3 to 3. This change does not affect the purpose of the test
case.
I have tried t
--- Comment #4 from ramiro86 at hotmail dot com 2009-04-21 00:10 ---
I've attached a simple testcase. The system I'm running this on is a q6600 with
64-bit Linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39821
--- Comment #3 from ramiro86 at hotmail dot com 2009-04-21 00:08 ---
Created an attachment (id=17660)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17660&action=view)
tarball of a simple testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39821
--- Comment #6 from bje at gcc dot gnu dot org 2009-04-20 23:59 ---
I believe all of the concerns raised have been fixed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from bje at gcc dot gnu dot org 2009-04-20 23:56 ---
Subject: Bug 5267
Author: bje
Date: Mon Apr 20 23:55:53 2009
New Revision: 146463
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146463
Log:
PR target/5267
* doc/invoke.texi (RS/6000 and PowerPC
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-20 23:51 ---
I thought http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01375.html would help
but that patch was already applied.
I have not tried 4.4.0 yet.
--
pinskia at gcc dot gnu dot org changed:
What|Remove
A simple testcase:
void foo (void * DAG_temp117584)
{
char uA;
void* pA;
void* pB;
void* pC;
do {
int DAG_temp117585;
int DAG_temp117586;
void ** __indir_union1 = (void**)DAG_temp117584;
DAG_temp117585 = *__indir_union1;
DAG_temp117586 = DAG_temp117585;
if ( DAG_t
--- Comment #7 from ramana at gcc dot gnu dot org 2009-04-20 23:09 ---
Waiting for feedback if this can be reproduced on a more modern toolchain. I
can't reproduce this with trunk today.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-20 23:06 ---
Note that powerpc64-linux configured gcc (both with --with-cpu=default32 and
without it, i.e. defaulting to -m32 resp. -m64) weren't exporting these in
64-bit libgcc_s.so.1, checked 4.1 and 4.3.
--
http://gcc.gnu.
--- Comment #2 from manu at gcc dot gnu dot org 2009-04-20 22:56 ---
(In reply to comment #1)
> -O3 has extra inlining.
>
~/trunk/146344/build/gcc/cc1 -DNO_LCMS -Wall -Werror -O3 dcraw.i
-fno-inline-functions -fno-inline
Still the same warnings. So, it seems to be some other reason.
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-20 22:50 ---
Yes it is, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634.
These functions are never called because they are soft-fp functions so there is
no reason for them to be in existant in libgcc as they are not used.
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-20 22:50 ---
*** Bug 39828 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-20 22:48 ---
Actually I think this was on purpose.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39828
sorry for noticing the issue that late.
Matthias
this is 4.4 configured with
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/in
--- Comment #3 from burnus at gcc dot gnu dot org 2009-04-20 22:21 ---
FIXED on the trunk (4.5).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2009-04-20 22:19 ---
Subject: Bug 39811
Author: burnus
Date: Mon Apr 20 22:19:25 2009
New Revision: 146460
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146460
Log:
2009-04-20 Tobias Burnus
PR fortran/39811
*
--- Comment #23 from manu at gcc dot gnu dot org 2009-04-20 22:18 ---
FIXED in GCC 4.5.
+Warn if @samp{long long} type is used. This is enabled by either
+...@option{-pedantic} or @option{-Wtraditional} in ISO C90 and C++98
+modes. To inhibit the warning messages, use @option{-Wno-lo
--- Comment #22 from manu at gcc dot gnu dot org 2009-04-20 22:13 ---
Subject: Bug 13358
Author: manu
Date: Mon Apr 20 22:12:52 2009
New Revision: 146459
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146459
Log:
2009-04-21 Manuel Lopez-Ibanez
PR c++/13358
*
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-20 22:09 ---
What makes you think there is a problem on the _ZNSs5beginEv side?
0(%ebp) is saved %ebp, 4(%ebp) is caller IP, 8(%ebp) is address of return value
(returned by invisible reference), 12(%ebp) is this pointer. If there
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-20 22:01 ---
And it works correctly on i386-darwin too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807
--- Comment #5 from pault at gcc dot gnu dot org 2009-04-20 21:55 ---
Subject: Bug 39800
Author: pault
Date: Mon Apr 20 21:55:26 2009
New Revision: 146457
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146457
Log:
2009-04-20 Paul Thomas
PR fortran/39800
* res
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #3 from lcwu at gcc dot gnu dot org 2009-04-20 21:45 ---
The fix for this bug was committed to mainline at revision 146454.
--
lcwu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-04-20
21:24 ---
For example, a ppl-0.10.2 test numberinput1 crashed because of this.
std::string::begin() is called at src/checked.cc:171
for (i = num.mantissa.begin(); ...
--
d dot g dot gorbachev at gmail dot com c
--- Comment #1 from burnus at gcc dot gnu dot org 2009-04-20 21:15 ---
Post script: If I unset MALLOC_CHECK_ then it compiles.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39827
--- Comment #4 from pault at gcc dot gnu dot org 2009-04-20 21:15 ---
Created an attachment (id=17659)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17659&action=view)
patch for both aspects of the PR
Bootstraps and regtests on FC9/x86_64
2009-04-20 Paul Thomas
PR for
--- Comment #2 from lcwu at gcc dot gnu dot org 2009-04-20 21:13 ---
Subject: Bug 39803
Author: lcwu
Date: Mon Apr 20 21:13:08 2009
New Revision: 146454
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146454
Log:
PR c++/39803
* gcc/cp/init.c (build_vec_init): Set
When bootstrapping (rev. 146452), I get the ICE in stage2:
/home/tob/projects/gcc/gcc/varasm.c: In Function "notice_global_symbol":
/home/tob/projects/gcc/gcc/varasm.c:1595: internal compiler error: segmentation
fault
That's on x86-64-linux with the MALLOC_CHECK_=2 MALLOC_PERTURB_=D environment
v
--- Comment #2 from ubizjak at gmail dot com 2009-04-20 20:52 ---
(In reply to comment #1)
> but the widening unpacking results in absymal code generated. Where are
> all the shifts coming from?
Not from unpacking, but from mulv2di pattern from sse.md
Can you please attach full sourc
--- Comment #2 from ian at airs dot com 2009-04-20 20:47 ---
This has already been fixed in revision 146451, which I committed an hour or
two ago.
--
ian at airs dot com changed:
What|Removed |Added
-
--- Comment #1 from danglin at gcc dot gnu dot org 2009-04-20 20:46 ---
Last successful bootstrap was revision 146003.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39826
nguages=c,c++,fortran --enable-shared
--enable-threads --disable-multilib --disable-libmudflap --disable-libssp
--enable-symvers=gnu --enable-__cxa_atexit --disable-libstdcxx-pch
--prefix=/home/dave/opt/gnu/gcc/gcc-4.5.0 --with-gmp=/home/dave/opt/gnu
Thread model: posix
gcc version 4.5.0 20090420
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |middle-end
Trying to compile the last svn ffmpeg version in a powerpc machine with Ubuntu
8.10:
$ uname -a
Linux aliena 2.6.25-2-powerpc #1 Tue Sep 30 14:49:00 UTC 2008 ppc GNU/Linux
$ gcc -v
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-20 20:23 ---
Do you have an example where this happens?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39823
--- Comment #1 from dcb314 at hotmail dot com 2009-04-20 20:19 ---
Created an attachment (id=17658)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17658&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39824
I just tried to compile the Suse Linux package libxml2-2.7.3-1.1
with the GNU gcc version 4.5 snapshot 20090416.
The compiler said
xpath.c:6468: internal compiler error: in fold_convert_const_int_from_real, at
f
old-const.c:2214
Please submit a full bug report,
with preprocessed source if appropr
--- Comment #22 from d dot g dot gorbachev at gmail dot com 2009-04-20
19:31 ---
(In reply to comment #21)
Sorry, it seems it's because of malloc(), not a GCC bug...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36054
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-04-20
19:26 ---
Created an attachment (id=17657)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17657&action=view)
Preprocessed source
g++ -S -std=gnu++0x -O1 string-inst.cc
--
http://gcc.gnu.org/bugzilla/show_bu
GCC 4.4.0 20090414 i686-pc-linux-gnu
Configure options:
--prefix=/usr/local --enable-languages=c,c++
--enable-version-specific-runtime-libs --with-host-libstdcxx='-lstdc++ -lm'
--disable-bootstrap --disable-shared --disable-nls
Libraries: GMP 4.3, MPFR 2.4.1-p5, PPL 0.10.2, CLooG-PPL 0.15.
In s
--- Comment #6 from gcc at abeckmann dot de 2009-04-20 17:51 ---
I stumbled across this ICE on a very similar testcase (on 4.3.4, 4.4.0, 4.5.0):
-- 8< --
template < typename > struct A ;
template < template < typename > class = A >
void test ()
{
test ();
}
-
--- Comment #2 from gcc at abeckmann dot de 2009-04-20 17:50 ---
probably a duplicate of bug #35828
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39822
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-20 17:45 ---
Created an attachment (id=17656)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17656&action=view)
gcc45-pr39794.patch
So shouldn't it use cselib_subst_to_values similarly to e.g. how sched-deps.c
uses it? Compl
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-20 17:41
---
Maybe Jason is willing to have a look...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-20 17:36 ---
(In reply to comment #3)
> and am doing a full bootstrap/regtest on x86_64-linux and i686-linux.
> But given that I can't reproduce the original problem, this is just a guess
> what might be a problem, so testing on
--- Comment #8 from joseph at codesourcery dot com 2009-04-20 17:30 ---
Subject: Re: real.c rounding not perfect
On Mon, 20 Apr 2009, ghazi at gcc dot gnu dot org wrote:
> How about chucking real.c and using mpfr_t as the internal representation for
> real numbers inside GCC? I guess
The following testcase produces a segmentation fault in --std=c++0x mode (in
4.3, 4.4, 4.5):
- 8< -
template < typename >
struct A ;
template < typename X, template < typename > class = A >
void test ( X )
{
A < int > T ;
test ( T ) ;
}
- >8 -
= 4.3.4 -std=c++0
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-04-20 17:01 ---
How about chucking real.c and using mpfr_t as the internal representation for
real numbers inside GCC? I guess we still need something to encode/decode
numbers to the target format, but IMHO we'll keep finding these c
--- Comment #15 from sje at cup dot hp dot com 2009-04-20 16:12 ---
This bug is fixed for 4.4.0 and later releases but it was decided not to fix it
for the 4.3 branch. See
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01275.html
--
sje at cup dot hp dot com changed:
What
--- Comment #6 from justinmattock at gmail dot com 2009-04-20 16:03 ---
(In reply to comment #5)
> Please report on which target and which gcc revision you have this problem.
>
operating system= LFS(used ubuntu for the starting of the creation,
then moved the new system over as soon as
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-20 15:59
---
For the record, I essentially agree with Falk, we are talking about a basic
core language behaviour, in general we don't have switches to create different
minor dialects of C++ at will... By the way, let's not
--- Comment #2 from kraftche at cae dot wisc dot edu 2009-04-20 15:52
---
Subject: Re: would like flag to disable constructors for built-in
types
falk at debian dot org wrote:
> --- Comment #1 from falk at debian dot org 2009-04-20 15:28 ---
> Removing the default constructo
--- Comment #4 from bonzini at gnu dot org 2009-04-20 15:48 ---
> Maybe a stupid question, but shouldn't this
> canon_true_dependence call receive canonicalized MEMs from 'base' and
> 'store_info->cse_base'?
I think so. The only way that DSE can see that something changed, is by having
--- Comment #6 from ramana at gcc dot gnu dot org 2009-04-20 15:44 ---
arm-coff is obsolete with trunk. Can this now be closed out?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from aph at redhat dot com 2009-04-20 15:44 ---
Subject: Re: [arm] libjava build failure due to missing
thread synchronization primitives
>> I'm not quite sure what you're trying to do.
>>
>> What did you change to support arm-eabi* ?
>
> I changed libjava/configure.ho
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-20 15:38 ---
Confirmed with gcc version 4.5.0 20090416 (experimental) [trunk revision
146149] (GCC)
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from falk at debian dot org 2009-04-20 15:28 ---
Removing the default constructor is a bad idea, since it would break about any
available library including the standard lib in subtle ways, and would make g++
pretty much unusable.
But apparently this isn't actually what yo
--- Comment #16 from singler at gcc dot gnu dot org 2009-04-20 14:44
---
I'm currently regression testing find_cstring_constify_equal_to.patch.
Shall I do a new test case for this PR with a non-copyable object
(generalization)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
--- Comment #6 from ramana at gcc dot gnu dot org 2009-04-20 14:30 ---
Hi Andrew,
>
>
> I'm not quite sure what you're trying to do.
>
> What did you change to support arm-eabi* ?
I changed libjava/configure.host to also support arm-eabi
(arm*-elf|arm*-eabi)but that probably wasn't
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-20 14:00 ---
Please report on which target and which gcc revision you have this problem.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #11 from pault at gcc dot gnu dot org 2009-04-20 11:57 ---
(In reply to comment #10)
> Paul, can we close this one?
>
Absolutely! It's done.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from rguenther at suse dot de 2009-04-20 11:32 ---
Subject: Re: [4.4 Regression] ICE in
vect_get_vec_def_for_operand, at tree-vect-transform.c:1999
On Mon, 20 Apr 2009, irar at il dot ibm dot com wrote:
> --- Comment #4 from irar at il dot ibm dot com 2009-04-20 1
--- Comment #4 from irar at il dot ibm dot com 2009-04-20 11:30 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from irar at gcc dot gnu dot org 2009-04-20 11:26 ---
Subject: Bug 39675
Author: irar
Date: Mon Apr 20 11:26:18 2009
New Revision: 146399
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146399
Log:
PR tree-optimization/39675
* tree-vect-loop.c (vect
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-20 11:02 ---
It bootstrapped/regtested on x86_64-linux and i686-linux just fine (both with
-j48), results were merged correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807
--- Comment #6 from jakub at gcc dot gnu dot org 2009-04-20 11:00 ---
Subject: Bug 35423
Author: jakub
Date: Mon Apr 20 10:59:59 2009
New Revision: 146397
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146397
Log:
PR fortran/35423
* trans.h (OMPWS_WORKSHARE_FLAG,
--- Comment #4 from ubizjak at gmail dot com 2009-04-20 09:56 ---
(In reply to comment #2)
> (I'll have to read read up on the backtrace part),
The backtrace is important for targets that are not so widely used (so
developers sometimes won't have to build a crosscompiler to confirm the
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-20 09:37 ---
Created an attachment (id=17655)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17655&action=view)
gcc45-pr39807.patch
Please try this patch. So far I've just tested that it generates the
same results as before
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-20 09:32 ---
Honza, if overlapping lifetimes are the problem instead of zero-initializing
uninitialized params we could instead create a new uninitialized variable for
them?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=397
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-20 09:26 ---
The vectorizer creates
vect_var_.128_46 = M*vect_p.123_44{misalignment: 0};
vect_var_.129_47 = [vec_unpack_lo_expr] vect_var_.128_46;
vect_var_.129_48 = [vec_unpack_hi_expr] vect_var_.128_46;
vect_var_.135_5
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-20 09:14 ---
Please attach preprocessed source and the output of -v appended to the
commandline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from aph at redhat dot com 2009-04-20 08:48 ---
Subject: Re: [arm] libjava build failure due to missing
thread synchronization primitives
ramana at gcc dot gnu dot org wrote:
> --- Comment #4 from ramana at gcc dot gnu dot org 2009-04-20 05:58
> ---
> The buil
--- Comment #9 from laurent at guerby dot net 2009-04-20 08:33 ---
Confirmed, Jan Hubicka second patch fixed the issue:
146344: FAIL
146349: OK
My apologies to Richard :)
--
laurent at guerby dot net changed:
What|Removed |Added
-
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-20 08:09 ---
AFAIK this has been backported to branches/gcc-4_3-branch as well by Janis.
You haven't said on which tool this triggers (gcc, or libstdc++, or something
else), e.g. on gcc there are around 164 different Running lines
--- Comment #2 from justinmattock at gmail dot com 2009-04-20 08:06 ---
Subject: Re: errors while compiling libc and the kernel
On Mon, 2009-04-20 at 07:15 +, ubizjak at gmail dot com wrote:
>
Alright,
(I'll have to read read up on the backtrace part),
from what I'm seeing so far
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-20 07:39 ---
See PR31081 for details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39799
On Sun, Apr 19, 2009 at 7:19 PM, James Dennett wrote:
> On Sun, Apr 19, 2009 at 4:15 PM, Paolo Piacentini
> wrote:
>> I don't think this is a bug but certainly it is a problem.
>>
>> Would you please consider it and let me know? I hope so. Thanks.
>>
>> The following simple volcalc.cpp code compi
--
ubizjak at gmail dot com changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |c
http://gcc.gnu.o
--- Comment #1 from ubizjak at gmail dot com 2009-04-20 07:14 ---
Please split this PR into two separate reports.
Also, please attach standalone preprocessed source that triggers the bug, see
http://gcc.gnu.org/bugs.html.
A backtrace of the crash would also help a lot.
--
http://g
--- Comment #2 from irar at gcc dot gnu dot org 2009-04-20 07:09 ---
Subject: Bug 39675
Author: irar
Date: Mon Apr 20 07:09:01 2009
New Revision: 146365
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146365
Log:
PR tree-optimization/39675
* tree-vect-transform.c
94 matches
Mail list logo
