--- Comment #23 from jakub at gcc dot gnu dot org 2009-01-15 08:07 ---
Subject: Bug 38245
Author: jakub
Date: Thu Jan 15 08:07:38 2009
New Revision: 143387
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143387
Log:
PR rtl-optimization/38245
* calls.c
--- Comment #24 from jakub at gcc dot gnu dot org 2009-01-15 08:15 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Testcase:
void noop(char* foo) {}
For 64-bit it does the right thing:
$ gcc -O2 foo.c -S
Output is:
noop:
.LFB2:
rep
ret
However for 32-bit it has useless extra instructions:
$ gcc -m32 -O2 foo.c -S
noop:
pushl %ebp
movl%esp, %ebp
popl%ebp
--- Comment #2 from pault at gcc dot gnu dot org 2009-01-15 09:19 ---
(In reply to comment #1)
This would mean an ABI change, but it is worth thinking about.
The required fix is trivial, although I have not regtested yet; eliminate
1127-1131 in trans-common.c.
Cheers
Paul
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-15 09:45 ---
This is the frame-pointer setup code. You can get the same code as x86_64 with
-momit-leaf-frame-pointer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from edwintorok at gmail dot com 2009-01-15 09:50 ---
(In reply to comment #1)
This is the frame-pointer setup code. You can get the same code as x86_64
with
-momit-leaf-frame-pointer.
Ok. But can't the optimizers see that you push ebp, write something to it, and
--- Comment #3 from edwintorok at gmail dot com 2009-01-15 09:51 ---
(In reply to comment #2)
(In reply to comment #1)
This is the frame-pointer setup code. You can get the same code as x86_64
with
-momit-leaf-frame-pointer.
Ok. But can't the optimizers see that you push
--- Comment #25 from ramana at icerasemi dot com 2009-01-15 10:34 ---
Redo CC addresses.
--
ramana at icerasemi dot com changed:
What|Removed |Added
--- Comment #14 from ramana at icerasemi dot com 2009-01-15 10:35 ---
Redo CCs
--
ramana at icerasemi dot com changed:
What|Removed |Added
CC|
--- Comment #7 from ramana at icerasemi dot com 2009-01-15 10:37 ---
Change CC addresses
--
ramana at icerasemi dot com changed:
What|Removed |Added
--- Comment #10 from ramana at icerasemi dot com 2009-01-15 10:37 ---
Change CC addresses
--
ramana at icerasemi dot com changed:
What|Removed |Added
--- Comment #6 from ramana at icerasemi dot com 2009-01-15 10:38 ---
Change CC addresses.
--
ramana at icerasemi dot com changed:
What|Removed |Added
--- Comment #15 from ramana at icerasemi dot com 2009-01-15 10:41 ---
Add self to CC
--
ramana at icerasemi dot com changed:
What|Removed |Added
CC|
--- Comment #7 from ramana at icerasemi dot com 2009-01-15 10:38 ---
Change CC addresses.
--
ramana at icerasemi dot com changed:
What|Removed |Added
--- Comment #20 from m dot reszat at kostal dot com 2009-01-15 11:15
---
There's a couple of things worth mentioning, based on the documentation. Quote:
`-finline-small-functions'
Integrate functions into their callers when their body is smaller
than expected function call
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-15 11:15 ---
Re. #3
Yes, the pro/epilogues are special.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38854
--- Comment #12 from amylaar at gcc dot gnu dot org 2009-01-15 11:36
---
(In reply to comment #11)
P.S.:
Another feature that we could look at is the number of times an input
ssa name is used. If it is used more than once, we cannot rely on the
original ssa name to go away, and hence
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-01-15 11:44
---
I'm working on adding rvalue support to bind etc. but time is not on my side
recently. I hope to make some more progress this weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
--- Comment #4 from rbenedik at fsmat dot htu dot tuwien dot ac dot at
2009-01-15 12:12 ---
I traced the error back to a iteration scheme which is not stable when optmized
with -O2. Sorry this was my fault, so theres no Bug in -O2:
DTYPE FTYPE(SQUARE_ROOT)(DTYPE A)
{
DTYPE X_N1;
--- Comment #2 from dodji at gcc dot gnu dot org 2009-01-15 13:01 ---
Subject: Bug 38636
Author: dodji
Date: Thu Jan 15 13:01:36 2009
New Revision: 143392
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143392
Log:
gcc/cp/ChangeLog:
2009-01-13 Dodji Seketeli do...@redhat.com
--- Comment #22 from r dot emrich at de dot tecosim dot com 2009-01-15
13:07 ---
(In reply to comment #21)
libtool uses the following regex:
(s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - PA-RISC [0-9].[0-9]
This matches for the native file command output:
libm.2:
---code---
#include iostream
#include iomanip
using namespace std;
int main() {
float f(1.0);
// cout Value: ; // works with any cout before eval!!
unsigned int i = *reinterpret_castunsigned int*(f);
cout hex i endl;
cout sizeof(float) endl;
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-15 13:46 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-15 13:57 ---
Fixed on the trunk:
-O2:
movzbl %dil, %edi
movzwl -2(%rsi,%rdi,2), %eax
ret
-Os:
movzbl %dil, %edi
movw-2(%rsi,%rdi,2), %ax
ret
--
jakub at gcc dot gnu dot
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 14:35 ---
Thus invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 14:37 ---
IMHO it's unwanted to remove the frame setup for empty functions without
-momit-leaf-frame-pointer. Debuggers may need it to do backtraces from
within that function.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-15 14:37 ---
It is not. You are violating C++ aliasing rules. Use memcpy or a union.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from jakub at gcc dot gnu dot org 2009-01-15 15:08 ---
Please s/incomoing/incoming/g in the patch. Otherwise the patch makes a lot of
sense to me. As INCOMING_STACK_BOUNDARY is used not only in
expand_stack_alignment, but also in 386's targetm.function_ok_for_sibcall
--- Comment #8 from ronan dot lehy at probayes dot com 2009-01-15 15:13
---
If I add simple explicit instantiations in place or in addition to the
BOOST_CLASS_EXPORT() calls, all symbols are correctly exposed in all cases :
namespace boost {
namespace serialization {
--- Comment #24 from hjl dot tools at gmail dot com 2009-01-15 15:18
---
Created an attachment (id=17107)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17107action=view)
Here is the updated patch.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #25 from dnovillo at gcc dot gnu dot org 2009-01-15 15:23
---
(In reply to comment #24)
Created an attachment (id=17107)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17107action=view) [edit]
Here is the updated patch.
OK.
Diego.
--
--- Comment #26 from hjl at gcc dot gnu dot org 2009-01-15 15:44 ---
Subject: Bug 37843
Author: hjl
Date: Thu Jan 15 15:44:41 2009
New Revision: 143400
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143400
Log:
gcc/
2009-01-15 H.J. Lu hongjiu...@intel.com
Joey Ye
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38554
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38748
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38789
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-15 16:00 ---
Maybe not really P1, but we certainly should investigate why tree-ssa broke
this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:03 ---
Honza, can you please have a look here?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38850
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-01-15 16:05 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:08 ---
Works for me with checking disabled. Not worth fixing on the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-15 16:08 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:09 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 16:10 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 16:10 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:12 ---
Fixed for GCC 4.4. Works for me on the branch with checking disabled.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ronan dot lehy at probayes dot com 2009-01-15 16:12
---
Following the twisted maze that is BOOST_CLASS_EXPORT() leads me to think that
it is (very) roughly equivalent to this:
void dummy(boost::archive::xml_iarchive ar, A a, B b) {
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.0.1 4.3.0 |4.0.0 4.3.2
Known to work|3.3 4.4.0 |3.3.6
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38751
--- Comment #27 from jakub at gcc dot gnu dot org 2009-01-15 16:28 ---
Fixed, thanks.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sje at gcc dot gnu dot org 2009-01-15 18:08 ---
Subject: Bug 38357
Author: sje
Date: Thu Jan 15 18:07:46 2009
New Revision: 143402
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143402
Log:
PR c++/38357
* pt.c (tsubst): Check for NULL args.
--- Comment #3 from sje at gcc dot gnu dot org 2009-01-15 18:09 ---
Subject: Bug 38357
Author: sje
Date: Thu Jan 15 18:09:04 2009
New Revision: 143403
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143403
Log:
PR c++/38357
* g++.dg/template/crash87.C: New test.
--- Comment #4 from jason at gcc dot gnu dot org 2009-01-15 18:14 ---
Subject: Bug 36334
Author: jason
Date: Thu Jan 15 18:14:32 2009
New Revision: 143404
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143404
Log:
PR c++/36334
PR c++/37646
* tree.c
--- Comment #2 from jason at gcc dot gnu dot org 2009-01-15 18:14 ---
Subject: Bug 37646
Author: jason
Date: Thu Jan 15 18:14:32 2009
New Revision: 143404
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143404
Log:
PR c++/36334
PR c++/37646
* tree.c
I apologize if it is a well disguised feature, but I am forced to consider this
being a performance regression/bug.
In the following trivial example:
void
VecADD(
long long *In1,
long long *In2,
long long *Out,
unsigned int samples
){
int i;
for (i = 0; i samples; i++) {
--- Comment #4 from syntheticpp at gmx dot net 2009-01-15 18:56 ---
It has nothing to do with templates.
This code still compiles:
struct P
{
protected:
P() {}
P(const P) {}
};
struct B : protected P
{
B() {}
};
struct C : public P
{
C(const B b) : P(b) {}
};
void
--- Comment #10 from doko at ubuntu dot com 2009-01-15 18:38 ---
checked the patch with trunk 20090115:
=== libstdc++ tests ===
Running target unix
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)
=== libstdc
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-15
19:08 ---
I've just run into this problem too.
In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and
chkstk.o and placed them whole into the import lib. I'm not sure why he didn't
do
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-15 18:41 ---
Well first off, iv-opts on the tree level should be the place where
autoincrement is helped out. See PR 31849 which I think this is a duplicate
of.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38856
With this test case the selective scheduler is hitting a gcc_assert in
sel-sched-ir.c I see this on IA64 Linux or on IA64 HP-UX when in 64 bit mode.
In both cases it happens when compiling with -O3.
x.c: In function 'dv_guess_qnos':
x.c:22: internal compiler error: in sel_move_insn, at
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
The 4.4 trunk gcc (I have tried revisions 143386, 143405) builds this SPEC2000
benchmark fine. But on running this benchmark, it segfaults pretty much
immediately (using any of the test, train, or ref inputs).
--
Summary: 255.vortex benchmark segfaults
Product: gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-15 19:25 ---
Last time I looked into vortex, it had some aliasing issues, see PR 23449.
What options are you compiling vortex with?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from raksit at google dot com 2009-01-15 19:27 ---
I am compiling vortex with -O2 (it builds and runs correctly with -O0).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38858
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-15 19:30 ---
Can you try -O2 -fno-strict-aliasing. If that works, then this is a dup of bug
23449 :). bug 23449 has a nice explication of where and how vortex violates
C/C++ aliasing rules.
--
pinskia at gcc dot gnu dot
--- Comment #4 from raksit at google dot com 2009-01-15 19:32 ---
*** Bug 38858 has been marked as a duplicate of this bug. ***
--
raksit at google dot com changed:
What|Removed |Added
--- Comment #4 from raksit at google dot com 2009-01-15 19:32 ---
Yes, this looks like the same problem as in PR 23449.
The benchmarks runs fine if I compile with -O2 -fno-strict-aliasing. And I
see from PR 23449 that this is a source-code issue. Closing this as a
duplicate.
*** This
The UBOUND and LBOUND intrinsics treat a reference to an array structure
component as if they were inquires on a whole array.
Dick Hendrickson
program try_jg_15_18
! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)
type x
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-15 19:58 ---
This is the patch which fixes the issue:Index: regrename.c
===
--- regrename.c (revision 3023)
+++ regrename.c (working copy)
@@ -1374,6 +1374,10 @@
--- Comment #11 from bkoz at gcc dot gnu dot org 2009-01-15 20:02 ---
Subject: Bug 32666
Author: bkoz
Date: Thu Jan 15 20:02:11 2009
New Revision: 143406
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143406
Log:
2009-01-15 Benjamin Kosnik b...@redhat.com
PR
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-15 20:04 ---
Confirm. This is a regression with regards to 4.2.1; it fails at least since
20071008 (my oldest 4.3 trunk version).
Thanks for the report!
--
burnus at gcc dot gnu dot org changed:
What|Removed
C++ pgm attempts to verify rdstate of an ofstream opened as follows:
...
ostr.open(tn, std::ios_base::out | std::ios_base::in | std::ios_base::app);
if(ostr.rdstate() == std::ios_base::failbit)
printf( good\n);
else
printf( bad.. should be failbit\n );
...
gcc version info
--- Comment #1 from aczapran at hotmail dot com 2009-01-15 20:09 ---
Created an attachment (id=17108)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17108action=view)
preprocessed file attaced = a.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38860
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-15 20:10 ---
ida = lbound(a%i)
if (any(ida /= (/1,1/))) print *, 'lbound', ida
Here, gfortran prints:
lbound 0 2
Correct would be
lbound 1 1
ida = ubound(a)
^^^
Here a %i is missing otherwise
https://bugzilla.mozilla.org/show_bug.cgi?id=455458
xulrunner helpfully renamed npupp.h that gcjwebplugin.cc uses to npfunctions.h
and removed all the NewNPP_* macros (and jref is gone as well).
I'm trying now:
--- libjava/classpath/native/plugin/gcjwebplugin.cc.jj 2009-01-14
12:08:34.0
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-15 20:48
---
Yeah, this is simply because we are implementing the resolution of DR596:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596
This is documented, both in the source code and in the docs.
--
--- Comment #2 from sergei_lus at yahoo dot com 2009-01-15 21:03 ---
Andrew, thank you for the prompt reply.
I have seen PR 31849 and used the patch suggested. Without it autoincrement
would not work at all for either case. But the patch seems to deal with the
case when iv _were_
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-15 21:13 ---
This bug is a bit funny, autoincrement is not the issue, just the detecting of
the induction variable's limits correctly. For an example I noticed that if I
compile this on a LP64 target, the induction variable is
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-15 21:17 ---
Here is a good testcase:
void
VecADD(
int *In1,
int *In2,
int *Out,
unsigned int samples
){
int i;
for (i = 0; i samples; i++) {
Out[i] = In1[i];
}
}
This testcase should be vectorized
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-15
21:18 ---
Created an attachment (id=17109)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17109action=view)
Order BACKENDLIBS by dependencies.
I'd consider this fix obvious. Verified that it resolves the
[ ref: http://gcc.gnu.org/ml/gcc/2009-01/threads.html#00179, full details of
configuration etc. ]
In gcc/Makefile.in, the current definition of BACKENDLIBS says:
BACKENDLIBS = $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS)
This is incorrect WRT dependency order. Cloog and PPL depend on GMP/MPFR, and
so
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-15 21:30 ---
quick fix:
Index: simplify.c
===
--- simplify.c (révision 143354)
+++ simplify.c (copie de travail)
@@ -2253,7 +2253,8 @@ simplify_bound (gfc_expr
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-15 21:35 ---
It is caused by revision 121570:
http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00126.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
The following program gives the wrong answers from the WHERE block. The
expected answers are in the tda2l array. The problem seems to be an
interaction between the dimension statements, the defined logical assignment
and the defined integer assignment statement in the WHERE block.
The defined
--- Comment #4 from dcb314 at hotmail dot com 2009-01-15 21:51 ---
(In reply to comment #3)
An updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00747.html
I have a couple of minor questions about the coding style
of this patch.
1. Why is the / 8 / 8 a good idea ?
--- Comment #9 from rob1weld at aol dot com 2009-01-15 22:03 ---
(In reply to comment #4)
Hmm, automake should have done the correct thing ...
(In reply to comment #5)
# Even if the default multilib is not a cross compilation,
# it may be that some of the other multilibs are.
if
--- Comment #2 from sje at cup dot hp dot com 2009-01-15 22:09 ---
David, can we close this out? I don't see the failure with 4.3.0 or on ToT.
I am guessing this was fixed with the following change to pa.c:
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-01-15 22:10
---
Subject: Bug 29388
Author: pinskia
Date: Thu Jan 15 22:10:24 2009
New Revision: 143411
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143411
Log:
2009-01-15 Andrew Pinski
LAST_UPDATED: Fri Jan 9 01:21:29 UTC 2009 (revision 143198)
$ ../trunk/configure --with-arch=native --disable-java-awt --without-x
--enable-__cxa_atexit --disable-libgomp --disable-static
--enable-languages=c,c++,java --disable-fixed-point --enable-checking=release
--with-gmp=/home/daney/mp
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-01-15 22:11
---
Fixed on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-15
22:14 ---
Subject: Re: FAIL: gcc.misc-tests/gcov-2.c ICE
--- Comment #2 from sje at cup dot hp dot com 2009-01-15 22:09 ---
David, can we close this out? I don't see the failure with 4.3.0 or on ToT.
--- Comment #4 from sje at cup dot hp dot com 2009-01-15 22:16 ---
Bug was fixed before 4.3.0 was released. Closing as fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-01-15 22:16
---
Broken : gcc_build/i386-pc-solaris2.11/libgomp/config.log :
No, it is not broken at all. __sync_val_compare_and_swap_4 cannot be used with
x86 explicit -march=i686 is used as the default really is to compile for
--- Comment #3 from jason at gcc dot gnu dot org 2009-01-15 22:34 ---
Subject: Bug 37646
Author: jason
Date: Thu Jan 15 22:34:20 2009
New Revision: 143413
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143413
Log:
PR c++/36334
PR c++/37646
* tree.c
--- Comment #5 from jason at gcc dot gnu dot org 2009-01-15 22:34 ---
Subject: Bug 36334
Author: jason
Date: Thu Jan 15 22:34:20 2009
New Revision: 143413
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143413
Log:
PR c++/36334
PR c++/37646
* tree.c
--- Comment #14 from jason at gcc dot gnu dot org 2009-01-15 22:34 ---
Subject: Bug 31488
Author: jason
Date: Thu Jan 15 22:34:20 2009
New Revision: 143413
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143413
Log:
PR c++/36334
PR c++/37646
* tree.c
--- Comment #6 from hjl dot tools at gmail dot com 2009-01-15 22:38 ---
This patch:
--- ./ipa-inline.c.foo 2009-01-02 11:06:18.0 -0800
+++ ./ipa-inline.c 2009-01-15 14:35:28.0 -0800
@@ -1412,7 +1412,8 @@ cgraph_decide_inlining_incrementally (st
}
--- Comment #15 from jason at gcc dot gnu dot org 2009-01-15 22:54 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from janus at gcc dot gnu dot org 2009-01-15 22:56 ---
Created an attachment (id=17110)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17110action=view)
patch
Here is a patch which fixes the testcases in comment #0, #1 and #7.
Dominique: Maybe you could check
1 - 100 of 152 matches
Mail list logo
