$ gnatmake assert_failure_sinfo_1002.adb
gnatgcc -c assert_failure_sinfo_1002.adb
+===GNAT BUG DETECTED==+
| 4.3.1 (i686-pc-linux-gnu) Assert_Failure sinfo.adb:1002 |
| Error detected at assert_failure_sinfo_1002.adb:11:10
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-04 07:59 ---
(In reply to comment #5)
> The patch in comment #4 generate a lot of bus errors in my tests. Looking at
> it, I think there is something missing: gfc_current_ns->old_cl_list is only
> set
> to NULL, it should likely b
--- Comment #1 from sworley at chkno dot net 2008-11-04 08:36 ---
Created an attachment (id=16622)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16622&action=view)
A source file that triggers the sinfo.adb:1002 assert failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3800
--- Comment #8 from thomas dot orgis at awi dot de 2008-11-04 08:52 ---
Ok, first, let me apologize for the "& 15 check is miscompiled" statement...
operator precedence got me there.
The feature for stack-realignment I meant is
__attribute__((force_align_arg_pointer))
I use this already
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-04 10:31 ---
namespace A {
class Parent{};
ostream& operator<<(ostream&o,const Parent&){return o<<"parent\n";}
}
namespace B {
class Child:public A::Parent{};
}
ostream& operator<<(ostream&o,const B::Child&){return
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-04 12:11 ---
Indeed, a DUP of PR35964 (which isn't marked as 4.3 regression though).
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137235
backport fixes this on 4.3 branch, on the trunk I cannot reproduce on the given
testcase e
--- Comment #8 from schwab at suse dot de 2008-11-04 14:21 ---
::operator<< is hidden by C::operator<< and cannot be found by name lookup.
A::operator<< is found because child is-a A::parent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
When compiling:
void assignMultiplyVec(double* restrict __attribute__ ((aligned (16))) a, const
double * restrict __attribute__ ((aligned (16))) b, double coef, unsigned
count) {
for(unsigned i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=38011
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-11-04 15:15 ---
there are two name-lookup stages for unqualified ids, first regular unqualified
lookup which finds the local operator<< then argument-dependent lookup (Koenig
lookup) which finds operator<< in A.
--
rguenth at gc
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-04 15:16 ---
FIXED on the trunk (4.4).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2008-11-04 15:20 ---
(In reply to comment #8)
> As for -mincoming-stack-boundary=2: __attribute__((force_align_arg_pointer))
> does solve the problem equivalently, doesn't it?
>
They are the same in gcc 4.4.
--
http://gcc.gnu.org/
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
Component|c |tree-opti
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-11-04 15:51 ---
Right, so this is the most simple (albeit not yet tested) patch I've
been able to come up with. I am not sure what overall impact this is
going to have. I'll briefly try to come up with something more
sophisticated
The vectorizer ignores the 'restrict' keyword regarding two pointer
destinations, and emits a run-time aliasing text.
--
Summary: vectorizer ignores 'restrict'
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priorit
--- Comment #24 from aph at redhat dot com 2008-11-04 16:09 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect
library ABI version detected
mark at codesourcery dot com wrote:
> You shouldn't call that function. Instead, you should set
> DECL_STATIC_{CONSTRUCTOR,DES
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-04 16:10 ---
restrict support is only roughly implemented.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from jakub at gcc dot gnu dot org 2008-11-04 16:03 ---
Actually, looking at this some more, the problem is just that g has a wrong
DECL_ARG_TYPE. When instantiate_class_template is called on B, it instantiates
g; class C is returned by lookup_template_class, but not yet a
--- Comment #1 from David dot Monniaux at imag dot fr 2008-11-04 16:06
---
Created an attachment (id=16623)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16623&action=view)
source code where va and vb are thought to be aliased
The compiler should heed that va and vb cannot point
There is no option to turn off the use of precompiled headers. This makes
generating preprocessed source for bugs harder than necessary (you need to
manually remove the pchs).
--
Summary: Option to turn off usage of any precompiled header
Product: gcc
Version: 4
--- Comment #9 from jakub at gcc dot gnu dot org 2008-11-04 16:43 ---
Created an attachment (id=16624)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16624&action=view)
gcc44-pr36631.patch
Quite ugly fix, Jason, do you have better ideas how to fix this?
--
http://gcc.gnu.org/b
--- Comment #4 from sje at cup dot hp dot com 2008-11-04 16:54 ---
I have submitted a patch at
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00125.html
and will check it in tomorrow. It should fix all the libgomp failures on IA64
Linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #10 from c dot hite at rtsgroup dot net 2008-11-04 17:10
---
So you're saying this isn't a bug because G++ does what it does?
Is there no standard specifying what should happen? I would like to think if
two different compilers produce different results, one of them has a b
You can also just do -Dineednopchreallyidont :).
Sent from my iPhone
On Nov 4, 2008, at 8:23 AM, "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]
> wrote:
There is no option to turn off the use of precompiled headers. This
makes
generating preprocessed source for bugs harder than necess
--- Comment #1 from pinskia at gmail dot com 2008-11-04 17:46 ---
Subject: Re: New: Option to turn off usage of any precompiled header
You can also just do -Dineednopchreallyidont :).
Sent from my iPhone
On Nov 4, 2008, at 8:23 AM, "rguenth at gcc dot gnu dot org"
<[EMAIL PROTECTED]
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-04 17:46 ---
Bootstrapped it again. Reopen if you still have problems with current
snapshots.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-04 18:01
---
(In reply to comment #1)
> You can also just do -Dineednopchreallyidont :).
.. and in a libstdc++ testcase (17_intro/headers/all_assert_neg.cc) we do
something similar... as an hack, to be clear ;)
--
paol
--- Comment #25 from dje dot gcc at gmail dot com 2008-11-04 18:11 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI
version detected
> This patch works on x86_64 GNU/Linux.
>
> Please HP/UX, AIX, and OSF users make sure it works for them as well.
I recom
--- Comment #26 from dje dot gcc at gmail dot com 2008-11-04 18:15 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI
version detected
The runtime failure has changed and no longer is complaining about ABI
versions on AIX. As I mentioned, I will be interes
--- Comment #27 from aph at redhat dot com 2008-11-04 18:16 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect
library ABI version detected
dje dot gcc at gmail dot com wrote:
> --- Comment #25 from dje dot gcc at gmail dot com 2008-11-04 18:11
> ---
> Subje
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-04 18:17 ---
Subject: Bug 37935
Author: burnus
Date: Tue Nov 4 18:16:17 2008
New Revision: 141583
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141583
Log:
2008-11-04 Tobias Burnus <[EMAIL PROTECTED]>
PR libg
--- Comment #28 from aph at gcc dot gnu dot org 2008-11-04 18:19 ---
So I take it that the libgcj linkage failure is fixed, but some other unrelated
bug now occurs? Sounds like this one needs to be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
--- Comment #3 from grosser at gcc dot gnu dot org 2008-11-04 18:25 ---
It seems PLUS_EXPR and POINTER_PLUS_EXPR can really handled identically.
So I will like to commit this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37883
--- Comment #29 from dje at gcc dot gnu dot org 2008-11-04 18:33 ---
> So I take it that the libgcj linkage failure is fixed, but some other
> unrelated
> bug now occurs? Sounds like this one needs to be closed.
No. "linkage failure" does not mean a link-edit failure. It always has
--- Comment #5 from mvanier at cs dot caltech dot edu 2008-11-04 11:07
---
OK, I built a vanilla gcc system from scratch and it's still exhibiting the
same problem. However, here's something new: the problem only manifests itself
if "." (the current directory) is in the path. If it is
--- Comment #123 from jsm28 at gcc dot gnu dot org 2008-11-04 13:25 ---
Subject: Bug 323
Author: jsm28
Date: Tue Nov 4 13:24:30 2008
New Revision: 141578
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141578
Log:
PR rtl-optimization/323
* c-common.c (convert_and
--- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-04
19:01 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI
version detected
> That error now is gone, but we may only have stepped to the next error on
> these
> platforms. We can decid
--- Comment #25 from hjl dot tools at gmail dot com 2008-11-04 19:28
---
This regression isn't specific to -mtune=core2. I saw 3% regression
with -O3 on Intel64. Enable the full regmove pass fixes the regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
--- Comment #7 from hjl dot tools at gmail dot com 2008-11-04 19:36 ---
IRA generates much slower codes:
[EMAIL PROTECTED] 37364]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -m32 -fno-ira -o noira
foo.c
/export/build/gnu/g
--- Comment #5 from c dot hite at rtsgroup dot net 2008-11-04 10:47 ---
I'm fine with case #1. I don't know if Sun is wrong, or there is no "right".
#2 is a BUG.
No, the lookup doesn't stop at "operator<<(Thing&o,Thing&)", it keeps going,
but it keeps going differently.
Please look a
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-04 10:39 ---
The following also fails the same way with optimization:
class foo {
public:
template __attribute__((noinline))
operator T () { return (T)0; }
};
struct bar {
unsigned int _bar : 24;
};
int main()
{
--- Comment #17 from jakub at gcc dot gnu dot org 2008-11-04 12:06 ---
And even fixed on the trunk:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137235
No idea why it hasn't been applied to 4.3 though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-04 12:51 ---
You are wrong. Name-lookup _does_ stop at the first match. Name-lookup has
nothing to do with declaration matching - it only looks up names.
--
rguenth at gcc dot gnu dot org changed:
What|Remov
--- Comment #17 from jakub at gcc dot gnu dot org 2008-11-04 20:08 ---
Subject: Bug 37106
Author: jakub
Date: Tue Nov 4 20:06:33 2008
New Revision: 141584
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141584
Log:
PR c/37106
* c-common.c (parse_optimize_options)
--- Comment #18 from jakub at gcc dot gnu dot org 2008-11-04 20:24 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-04 20:53 ---
Subject: Bug 35430
Author: jakub
Date: Tue Nov 4 20:51:38 2008
New Revision: 141587
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141587
Log:
PR c/35430
* c-common.c (warn_for_sign_compare):
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-04 21:03 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-04 21:08 ---
Caused by PR28588 fix, http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116468
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pault at gcc dot gnu dot org 2008-11-04 21:12 ---
An 'obvious' fix is on the way.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mvanier at cs dot caltech dot edu 2008-11-04 11:08
---
Oops, I meant GCC_EXEC_PREFIX is not defined, not GCC_EXEC_PATH.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
--- Comment #2 from pault at gcc dot gnu dot org 2008-11-04 21:19 ---
Subject: Bug 37597
Author: pault
Date: Tue Nov 4 21:17:53 2008
New Revision: 141588
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141588
Log:
2008-11-04 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from c dot hite at rtsgroup dot net 2008-11-04 13:36 ---
If it stopped at the first match, then the call in C would match the operator
in C and say the operands don't match and not compile. Instead C goes on to
call an operator defined in A.
Why does C check A and not th
In gcc 4.3, you can unpack the gmp and mpfr libraries into your source tree,
and gcc will build, even if gmp and mpfr are not installed on the host system.
That appears to be broken in mainline as of 2008-10-22. The problem is that
the top level configury passes --with-gmp-build when configuring
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Currently gcc/config.gcc in gcc trunk doesn't recognize darwin10 and thus
doesn't use darwin9.h in that case.
Mike Stump recommends the change...
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 141576)
+++ gcc/config.gcc
--- Comment #1 from hp at gcc dot gnu dot org 2008-11-04 22:15 ---
Is something missing from the description?
In-tree gmp and mpfr seems to work for me as of r141574, for cris-elf, on a
Fedora 8 system.
Dunno if it matters that there's also:
mpfr-2.3.0-1.fc8
gmp-4.2.2-4.fc8
gmp-4.2.2-4.f
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-04 09:29 ---
I don't see how the patch can make a difference only on ia64. Note that on
x86_64 the loop isn't vectorized either -- even though the stats print there
is a vectorized loop. It looks like the vectorized version get
Consider the following function, which adds 1 to its argument using Intel
intrinsics:
#include
unsigned
add1(unsigned x)
{
__m128i a = _mm_cvtsi32_si128(x);
__m128i b = _mm_add_epi32(a, _mm_set_epi32(0, 0, 0, 1));
return _mm_cvtsi128_si32(b);
}
GCC goes through memor
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-04 22:48 ---
I think it depends on the tuning of the processor which decides if it should
goto memory or not. -mtune=generic makes it go through memory while
-mtune=core2 does not and we get:
movd%edi, %xmm0
--- Comment #31 from aph at redhat dot com 2008-11-04 23:06 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect
library ABI version detected
dave at hiauly1 dot hia dot nrc dot ca wrote:
> --- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-04
> 1
> It seems PLUS_EXPR and POINTER_PLUS_EXPR can really handled identically.
> So I will like to commit this patch.
Yes they should be handled in the same way in this context.
Please install the patch.
Thanks,
Sebastian
--- Comment #4 from sebpop at gmail dot com 2008-11-04 23:34 ---
Subject: Re: [graphite] ICE : in scan_tree_for_params, at graphite.c:2274
> It seems PLUS_EXPR and POINTER_PLUS_EXPR can really handled identically.
> So I will like to commit this patch.
Yes they should be handled in th
--- Comment #8 from appfault at hotmail dot com 2008-11-04 23:47 ---
Reopen to at least consider comment 7.
--
appfault at hotmail dot com changed:
What|Removed |Added
--- Comment #2 from jch at pps dot jussieu dot fr 2008-11-05 00:27 ---
Then -mtune=generic is not doing something reasonable.
If I read correctly the docs I have available, going through memory doesn't win
on either Core2 or AMD family 10. It does win on the K8, but only in the
xmm->in
--- Comment #9 from jwakely dot gcc at gmail dot com 2008-11-05 01:09
---
Created an attachment (id=16625)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16625&action=view)
update result_of and reference_wrapper
In the current draft, reference_wrapper invocation requires Callable,
--- Comment #32 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-05
01:11 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI
version detected
> OK, but I need to know if my patch has been tested well enough for
> me to check it in. I'm fairly certain i
--- Comment #9 from jwakely dot gcc at gmail dot com 2008-11-05 01:12
---
I've added a patch in bug 24803, comment 9
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37351
(Marked as a regression because the bug wasn't exposed with earlier versions,
for example 3.2.1, well before ivopts.)
Adding -fno-gcse trigs more FAILs, but -fno-gcse by itself doesn't expose the
bug. To reproduce, run the testsuite with
"RUNTESTFLAGS=--target_board=cris-sim/-fno-ivopts" or
"RUNTE
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfi
--- Comment #10 from paolo dot carlini at oracle dot com 2008-11-05 01:25
---
(In reply to comment #9)
> That said, here's a patch that updates result_of and reference_wrapper to work
> for pointers to members as well as callable types, using result_of in place of
> the Callable concept
--- Comment #2 from xinliangli at gmail dot com 2008-11-05 01:26 ---
The problem reproduces for me -- for both i686 native 32 bit compiler build and
x86_64 cross compiler build.
David
--
xinliangli at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from hp at gcc dot gnu dot org 2008-11-05 01:27 ---
The description does not expose the bug on trunk, but it still exists there.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from redi at gcc dot gnu dot org 2008-11-05 02:06 ---
Subject: Bug 37351
Author: redi
Date: Wed Nov 5 02:05:59 2008
New Revision: 141596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141596
Log:
PR libstdc++/24803
PR libstdc++/37351
* in
--- Comment #11 from redi at gcc dot gnu dot org 2008-11-05 02:06 ---
Subject: Bug 24803
Author: redi
Date: Wed Nov 5 02:05:59 2008
New Revision: 141596
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141596
Log:
PR libstdc++/24803
PR libstdc++/37351
* in
--- Comment #11 from jwakely dot gcc at gmail dot com 2008-11-05 02:08
---
Fixed for 4.4
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
Sta
--- Comment #12 from redi at gcc dot gnu dot org 2008-11-05 02:10 ---
Fixed for 4.4 (including the nits you spotted, thanks Paolo)
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from redi at gcc dot gnu dot org 2008-11-05 02:27 ---
argh! I've broken call_once, re-opening while I look into it. A
testsuite_files was causing some tests not to run.
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from jwakely dot gcc at gmail dot com 2008-11-05 02:54
---
the problem is due to bug 35569 - I'll have to revert my patch until I can fix
that properly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24803
--- Comment #10 from kargl at gcc dot gnu dot org 2008-11-05 03:50 ---
Markus,
Thanks for the bug report. Tobias has stated that your code
compiles with 4.1 or newer. I'll note that 4.1.x has reached
end-of-life and no additional releases are planned. I think
4.2.x may also have reac
--- Comment #3 from kargl at gcc dot gnu dot org 2008-11-05 04:10 ---
Can you attach the code instead of embedded in a message?
It's a PITA to strip out HTML from your code when I save it as a file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37644
--- Comment #4 from grosser at gcc dot gnu dot org 2008-11-05 04:33 ---
Subject: Bug 37943
Author: grosser
Date: Wed Nov 5 04:32:16 2008
New Revision: 141597
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141597
Log:
2008-11-05 Tobias Grosser <[EMAIL PROTECTED]>
PR m
--- Comment #11 from markus dot airila at vtt dot fi 2008-11-05 04:46
---
Subject: RE: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:1108
kargl at gcc dot gnu dot org [EMAIL PROTECTED]:
> Thanks for the bug report. Tobias has stated that your code
> com
--- Comment #5 from grosser at gcc dot gnu dot org 2008-11-05 04:47 ---
Subject: Bug 37943
Author: grosser
Date: Wed Nov 5 04:45:49 2008
New Revision: 141598
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141598
Log:
2008-11-05 Tobias Grosser <[EMAIL PROTECTED]>
PR m
--- Comment #6 from grosser at gcc dot gnu dot org 2008-11-05 04:48 ---
Fix committed
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #12 from grosser at gcc dot gnu dot org 2008-11-05 05:05
---
Subject: Bug 37833
Author: grosser
Date: Wed Nov 5 05:04:29 2008
New Revision: 141599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141599
Log:
2008-11-05 Tobias Grosser <[EMAIL PROTECTED]>
PR
--- Comment #13 from grosser at gcc dot gnu dot org 2008-11-05 05:25
---
Subject: Bug 37833
Author: grosser
Date: Wed Nov 5 05:23:46 2008
New Revision: 141600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141600
Log:
2008-11-05 Tobias Grosser <[EMAIL PROTECTED]>
PR
--- Comment #14 from kargl at gcc dot gnu dot org 2008-11-05 05:25 ---
Closing the bug as WONTFIX. The 4.0.x branch is long dead.
Long live 4.4+
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
-
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37857
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |grosser at gcc dot gnu dot
|dot org
On Linux/Intel64, revision 141596 gave:
+FAIL: 30_threads/call_once/call_once1.cc (test for excess errors)
+FAIL: 30_threads/call_once/call_once1.cc (test for excess errors)
+FAIL: 30_threads/thread/cons/2.cc (test for excess errors)
+FAIL: 30_threads/thread/cons/2.cc (test for excess errors)
+FAI
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-05 05:57 ---
Revision 141596 is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
With revision 141596, on Linux/ia64, I got
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -O1 -fpic -S
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr37106-1.c
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr37106-1.c: In
function âopt3â:
/export/gnu/import/svn/gcc-test/src
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-05 06:09 ---
I think it is another instance of PR 37565.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #3 from ian at airs dot com 2008-11-05 06:58 ---
hp: It will work if gmp is installed on the system. The problem is that mpfr
can't find gmp.h. If gmp is installed, then it can, and everything works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38014
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-05 07:03 ---
I can reproduce the ICE (seg. fault) with 4.3.x, but not with 4.4.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37644
95 matches
Mail list logo
