--- Comment #17 from hp at gcc dot gnu dot org 2009-04-08 06:55 ---
Adding the libstdc++ regressions I've seen as a dependent, see PR39644 comment
#23.
(That is, the PR448 solution in progress relies on newlib providing the missing
INTPTR_MAX, INTPTR_MIN and UINTPTR_MAX which it doesn't
--- Comment #23 from hp at gcc dot gnu dot org 2009-04-08 06:47 ---
(In reply to comment #22)
> you should then figure out why the configure-time tests do not enable
> _GLIBCXX_USE_C99_STDINT_TR1.
conftest.cc: In function 'int main()':
conftest.cc:99: error: 'INTPTR_MAX' was not declare
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #8 from hp at gcc dot gnu dot org 2009-04-08 06:06 ---
(In reply to comment #6)
> Then we should fix this bug by requiring 64-bit HOST_WIDE_INT for x86 targets
This is just the special case of GCC generating different code for the same
target from different *hosts*; you'd ha
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from MR dot Swami dot Reddy at nsc dot com 2009-04-08 05:09
---
Created an attachment (id=17607)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17607&action=view)
Bug testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39685
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-04-08
05:01 ---
I should add that I am seeing this on i686-apple-darwin9 with the
gcc-4.4.0-20090407 snapshot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39161
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-04-08
04:59 ---
How exactly are you supposed to copy a file into a build subdirectory before it
is created?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39161
Compile the below testcase with -O3 -funroll-all-loops option, using
crx-elf-gcc vesion 4.5.0 20080307 (sources from trunk).
Command line:
crx-elf-gcc test.c -o3 -funroll-all-loops
test.c:187: error: insn does not satisfy its constraints:
(insn 8 119 130 2 /scratch/user/swami/test.c:149 (set (mem/
--- Comment #10 from burnus at gcc dot gnu dot org 2009-04-08 04:32 ---
Reopen based on comment #9.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from jason at gcc dot gnu dot org 2009-04-08 03:56 ---
Fixed for 4.4/4.5, not going to fix in 4.3.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jason at gcc dot gnu dot org 2009-04-08 03:55 ---
Subject: Bug 34691
Author: jason
Date: Wed Apr 8 03:55:00 2009
New Revision: 145710
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145710
Log:
PR c++/34691
* name-lookup.c (merge_functions):
--- Comment #14 from jason at gcc dot gnu dot org 2009-04-08 03:45 ---
Subject: Bug 34691
Author: jason
Date: Wed Apr 8 03:44:48 2009
New Revision: 145709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145709
Log:
PR c++/34691
* name-lookup.c (merge_functions):
Shobaki, Ghassan wrote:
Hi,
I am considering working on fixing the pre-pass scheduling problem on
x86 (Bug 38403). The pre-pass instruction scheduler currently increases
register pressure to a degree that causes the register allocator to
fail. Before I commit to this task, I would like to gather
Hi,
I am considering working on fixing the pre-pass scheduling problem on
x86 (Bug 38403). The pre-pass instruction scheduler currently increases
register pressure to a degree that causes the register allocator to
fail. Before I commit to this task, I would like to gather as much
information as po
--- Comment #8 from jsm28 at gcc dot gnu dot org 2009-04-07 23:46 ---
The expression is indeed not an integer constant expression and so not
valid for a case label in ISO C. But I'll look at restricting the error
in this case to a pedwarn-if-pedantic if the case label folds to an intege
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-04-07 23:43 ---
Testing a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-04-07 23:42 ---
Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39614
--- Comment #27 from PHHargrove at lbl dot gov 2009-04-07 23:39 ---
(In reply to comment #26)
Ralph,
Thanks for the quick reply.
Unfortunately, I am not in control of the machine in question and thus cannot
raise the ARG_MAX limit on my own. I will send email to the admins to see if
--- Comment #6 from janis at gcc dot gnu dot org 2009-04-07 22:49 ---
Subject: Bug 39325
Author: janis
Date: Tue Apr 7 22:49:25 2009
New Revision: 145703
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145703
Log:
2009-04-07 Dominique d'Humieres
PR testsuite/39325
--- Comment #5 from janis at gcc dot gnu dot org 2009-04-07 22:46 ---
Subject: Bug 39325
Author: janis
Date: Tue Apr 7 22:46:07 2009
New Revision: 145702
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145702
Log:
2009-04-07 Dominique d'Humieres
PR testsuite/39325
--- Comment #20 from paolo dot carlini at oracle dot com 2009-04-07 22:04
---
Created an attachment (id=17606)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17606&action=view)
Even closer to minimal (as C++ code) and more correct
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from falk at debian dot org 2009-04-07 21:47 ---
Here's a test case:
unsigned long f1();
int f2();
int store_aff_word(int x) {
return (int) (x ? f1() : f2());
}
--
falk at debian dot org changed:
What|Removed |Added
-
The following test case is rejected by Comeau but accepted by GCC:
template
struct outer {
template
T search(U, T);
};
template
template
T outer::template search (U, T)
{
return T ();
}
int
main ()
{
int x = 0;
int v = 0;
outer s;
s.search (v, x);
}
"ComeauTest.c", line 9: er
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-07 21:06 ---
It is caused by revision 145254:
http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00761.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #9 from dominiq at lps dot ens dot fr 2009-04-07 21:02 ---
The code in comment #1 still does not give the right result. I get
(intel-darwin):
[ibook-dhum] f90/bug% gfc pr38863_1.f90
[ibook-dhum] f90/bug% a.out
12288 -1880941592 -1073751380
[ibook-dhum] f90/bug% gfc -O
--- Comment #14 from paolo dot carlini at oracle dot com 2009-04-07 20:48
---
*** Bug 39652 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-07 20:48
---
*** This bug has been marked as a duplicate of 39629 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #19 from paolo dot carlini at oracle dot com 2009-04-07 20:47
---
Created an attachment (id=17605)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17605&action=view)
Smaller...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-07
20:46 ---
Subject: Re: Trouble with new random bits
> Well, *cannot* be still an issue exactly in these terms, because there are no
> log2* functions any more in the code...
You are correct. The log2 fails are gon
--- Comment #26 from rwild at gcc dot gnu dot org 2009-04-07 20:46 ---
(In reply to comment #25)
> Has any progress been made on this bug?
No, sorry. I hit other places that needed this, too, and don't know how to
work around them easily.
As a workaround, can't you raise the limit in
--- Comment #25 from PHHargrove at lbl dot gov 2009-04-07 20:39 ---
Has any progress been made on this bug?
I have hit this problem with gcc-4.3.2 on IRIX with both --disable-fixed-point
and --disable-decimal-float. Since this bug is open with a milestone of 4.3.4
I figured a switch to
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-07 20:14 ---
Related to PR 31096.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39683
The shift isn't necessary. This could have
been re-coded as
return (a-b)<2;
with -fstrict-overflow.
$ cat ga.c
int foo(int a, int b)
{
return (a-b)*4 < 8;
}
$ gcc -S -O2 -fstrict-overflow ga.c
$ cat ga.s
.file "ga.c"
.text
.p2align 4,,15
.globl foo
.typ
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |middle-end
h
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-07 18:28 ---
this dump file is only supposed to be used to debug gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39679
--- Comment #18 from paolo dot carlini at oracle dot com 2009-04-07 19:01
---
Created an attachment (id=17604)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17604&action=view)
A bit smaller
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #3 from toon at moene dot org 2009-04-07 18:41 ---
Note that the namelist is overwriting earlier assignments, so it's doubtful
it's legal Fortran.
The original that got my colleague questioning gfortran was:
&namtest
i(1,:)=1,2,3,
i(2,:)=4,5,6,
i(3,:)=7,8,9,
/
which, us
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-04-07 17:51 ---
Could you please attach a (ideally) minimal testcase that reproduces the error?
Thanks.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #25 from jason at gcc dot gnu dot org 2009-04-07 17:49 ---
Subject: Bug 25185
Author: jason
Date: Tue Apr 7 17:48:52 2009
New Revision: 145697
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145697
Log:
PR c++/25185
* c-common.h, c-common.c: Add flag_
/opt/gcc-4.3.3/bin/gfortran -ffixed-line-length-0 -g-c
-I/Volumes/Users/bmayer/Desktop/download/netcdf-4.0/f90 driver.F90
driver.F90:170.25:
call write_input("crm_input_test.nc", lchnk, 1, icol, plev2, ps, pmid,
&
1
Warning: Character length of actual argument
--- Comment #4 from info dot gnu at rt-labs dot com 2009-04-07 16:52
---
You're right, I tried both examples you mentioned, i'll point this to #35466
that seems to point out the problem you described about.
*** This bug has been marked as a duplicate of 35466 ***
--
info dot gnu at
--- Comment #7 from info dot gnu at rt-labs dot com 2009-04-07 16:52
---
*** Bug 39663 has been marked as a duplicate of this bug. ***
--
info dot gnu at rt-labs dot com changed:
What|Removed |Added
--- Comment #17 from paolo dot carlini at oracle dot com 2009-04-07 16:44
---
I guess I'm going to reduce the big one with 'delta', if you have special
advice about that, just let me know...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #19 from janus at gcc dot gnu dot org 2009-04-07 16:24 ---
Subject: Bug 38152
Author: janus
Date: Tue Apr 7 16:24:31 2009
New Revision: 145692
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145692
Log:
2009-04-07 Janus Weil
PR fortran/38152
* tra
--- Comment #16 from paolo dot carlini at oracle dot com 2009-04-07 16:24
---
Sorry for the noise, forgot that we don't care any more about 4_1 and 4_2 ;)
Anyway, the issue is apparently *very* old...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-04-07 16:05
---
So maybe it's a C++ FE issue after all ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-04-07 16:04
---
With a small testcase it works:
struct Y {};
struct X {
Y y;
float real;
float imag;
};
struct X __attribute__((noinline))
foo (float *p)
{
struct X x;
x.real = p[0];
x.imag = p[1];
return x;
}
exte
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-04-07 15:57
---
The intel compiler generates
..___tag_value__ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_.69:
#165.5
movq (%rsi), %rax #167.53
movss
--- Comment #12 from paolo dot carlini at oracle dot com 2009-04-07 15:48
---
You are too fast ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #15 from piotr dot wyderski at gmail dot com 2009-04-07 15:47
---
Subject: Re: std::result_of doesn't work
jwakely dot gcc at gmail dot com :
> You want this:
>
> typename std::result_of< decltype(&traits::restore) (S*) >::type
Thank you! :-)
> Paolo, let's close this.
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-04-07 15:46
---
Created an attachment (id=17603)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17603&action=view)
preprocessed testcase with bind2nd marked noinline
Testcase, look at the compiled piece for the call to
_ZSt7
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-04-07 15:45
---
It seems to be an ABI mismatch in the backend somehow.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from paolo dot carlini at oracle dot com 2009-04-07 15:45
---
Agreed ;)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
S
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-07 15:44 ---
Wait - it's ok.
class binder2nd
: public unary_function
{
protected:
_Operation op;
typename _Operation::second_argument_type value;
_Operation is probably empty, so there are 4 bytes pa
--- Comment #13 from jwakely dot gcc at gmail dot com 2009-04-07 15:42
---
(In reply to comment #12)
> typename std::result_of< decltype(&traits::restore) (S*) >::type
Oops, that should be S& not S*
It's not perfect, but for this case std::result_of works if you get the syntax
right :
--- Comment #12 from jwakely dot gcc at gmail dot com 2009-04-07 15:40
---
See what I wrote at http://gcc.gnu.org/ml/libstdc++/2008-09/msg00124.html under
point 3)
You want this:
typename std::result_of< decltype(&traits::restore) (S*) >::type
Paolo, let's close this.
--
http://
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 15:37
---
FWIW, the EDG C++ front-end issues a very similar error message ;)
39681.C(3): error: expected a type specifier
int* p = new foo;
^
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
Note: This enhancement request (in my opinion) is related with the compiler
frontend (of C++ and probably also C) and can be applied to all platforms.
Given a .cpp file (3 lines below only, nothing else);
int main()
{
int* p = new foo;
}
When tried to compile gives the following error:
erro
--- Comment #8 from paolo dot carlini at oracle dot com 2009-04-07 15:32
---
Ok, give me a few minutes, I'm going to dig a bit further...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-07 15:29 ---
Minor data point (-O1 -g):
movss 4(%rbx), %xmm3
movss (%rbx), %xmm2
movss (%rsp), %xmm1
movss 4(%rsp), %xmm0
call__mulsc3
Breakpoint 1, 0x77667990 in __mu
--- Comment #5 from eric dot weddington at atmel dot com 2009-04-07 15:23
---
Adding additional version numbers in the known-to-fail field from comment in
duplicate bug #39635. Still waiting to hear if bug is present in 4.4.
--
eric dot weddington at atmel dot com changed:
--- Comment #4 from eric dot weddington at atmel dot com 2009-04-07 15:18
---
This looks like a duplicate of bug #39386.
*** This bug has been marked as a duplicate of 39386 ***
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #4 from eric dot weddington at atmel dot com 2009-04-07 15:18
---
*** Bug 39635 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39386
--- Comment #3 from hubicka at ucw dot cz 2009-04-07 15:14 ---
Subject: Re: Local statics not promoted to const
> I think it only adjusts global statics.
This is why I originally implemented varpool to have both local and
global static alike, so it should not.
Well, time to debug it ;
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 15:08
---
Well, *cannot* be still an issue exactly in these terms, because there are no
log2* functions any more in the code...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39652
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-07
15:06 ---
Subject: Re: Trouble with new random bits
> Is this still an issue?
I think so, but I've been playing with the defines to provide stdint.h.
I'll know this evening.
Dave
--
http://gcc.gnu.org/bugzill
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-07 15:04
---
Agreed, thanks Richard.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #11 from piotr dot wyderski at gmail dot com 2009-04-07 15:02
---
Subject: Re: std::result_of doesn't work
2009/4/7 jwakely dot gcc at gmail dot com :
> what you probably want is:
In fact I want to copy the return type of a template method restore
and use as another meth
--- Comment #2 from bonzini at gnu dot org 2009-04-07 15:02 ---
I cannot see any better alternative, but I'll point out that saying
"wrong-code" is not exact.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39677
--- Comment #2 from happyarch at gmail dot com 2009-04-07 14:57 ---
Created an attachment (id=17602)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17602&action=view)
preprocessed output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39673
--- Comment #10 from paolo dot carlini at oracle dot com 2009-04-07 14:56
---
Gosh, thanks Jonathan for the explanation, the key word for me is
*overloading*, if overloading were not part of C++ these facilities would
probably be more "intuitive" to use. Agreed, let's give Piotr two min
--- Comment #7 from kargl at gcc dot gnu dot org 2009-04-07 14:54 ---
(In reply to comment #5)
> Many compilers support $ signs as extension (ISO standard Fortran does not).
> However, only a few support a leading $ sign. One of the questions which
> immediately come up, which data type
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-07 14:51 ---
The expected output is
10 10
10 10
(10,0) (10,0)
(10,0) (10,0)
correct? With -O0 I get
10 10
10 10
(nan,nan) (nan,nan)
(10,0) (10,0)
while for -m32 it is ok. So it appears only the float variant is affected?
Th
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-04-07 14:51
---
This is not a bug in C++0x either. The spec is:
Given an rvalue fn of type Fn and values t1, t2, ..., tN of types T1, T2, ...,
TN in ArgTypes, respectively,
the type member is the result type of the expression f
--- Comment #8 from paolo dot carlini at oracle dot com 2009-04-07 14:47
---
Yes, that would work, we even have testcases for it. But what about C++0x,
Jonathan? Seems strange that only that more convoluted syntax is right...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
--- Comment #6 from kargl at gcc dot gnu dot org 2009-04-07 14:46 ---
(In reply to comment #2)
> As I already said, I have code, being compiled with MS Fortran, that has
> a lot of variable names starting with $. MS Fortran allows it.
>
> My personal opinion is that the Fortran compiler
--- Comment #2 from axel-freyn at gmx dot de 2009-04-07 14:45 ---
Created an attachment (id=17601)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17601&action=view)
shorter testcase
testcase sufficient for ICE on gcc version 4.3.2 (Debian 4.3.2-1.1), Target:
x86_64-linux-gnu
--
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-04-07 14:45
---
I think you have the syntax wrong, if you want to know the return type of a
function type (or function pointer, or function reference) you need to say:
result_of::type
what you probably want is:
typedef int
--- Comment #2 from paolo dot carlini at oracle dot com 2009-04-07 14:45
---
Is this still an issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39652
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-07 14:34
---
Yes, a purely unimplemented C++0x feature.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 14:33
---
Current mainline is fine. I can reproduce on x86_64-linux with 4_3-branch and
4_4-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39680
--- Comment #5 from piotr dot wyderski at gmail dot com 2009-04-07 14:31
---
So it is a purely C++0x bug, as you indicated in your first reply.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last re
Hi everyone
The following code cannot pass compilation by g++ v4.3.2.
#include
#include
#include
#include
#include
#include
using namespace std;
class test
{
public:
void func(int i) { wcout << i << L": test\n"; }
};
namespace
{
template
class destroyer : public un
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 14:23
---
Richard, can I have your opinion about this? Thanks in advance!
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-07 14:17
---
Yes, you are right. Apparently some sort of miscompilation. The problem does
not happen when using the C++ runtime + a different C++ compiler, by the way.
Let's look further into it... The other possibility is
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 14:15
---
I'm looking at 3.4/3 in n1836, and my answer is *no*.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
--- Comment #1 from susanin at ispras dot ru 2009-04-07 14:13 ---
Created an attachment (id=17600)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17600&action=view)
This patch add some absent function attributes to the tree-dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-07 14:11
---
Are you *really* sure the simplified testcase was supposed to work per the TR1
specifications? The author of thar code is Doug Gregor, and it never did in
GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
Hi, I'am one of the lead developers from "Linux Verification Center"
(http://www.linuxtesting.org/) at ISPRAS in Russia. Last several years we make
instruments for linux testing along with the "Linux Foundation"
(http://linuxfoundation.org/) under the LSB-Infrastructure project. Some our
instrument
--- Comment #2 from piotr dot wyderski at gmail dot com 2009-04-07 14:05
---
(In reply to comment #1)
> Note that *most* of the facilities in are still following the TR1
> specifications, thus, in general, do not expect conformance to the latest
> C++0x
> draft (or file a DR for each
--- Comment #2 from diepen at astron dot nl 2009-04-07 14:03 ---
The output does not show the correct results. It looks as if the imaginary part
of the complex number in the bind2nd object is incorrect. When debugging the
bind2nd object was constructed correctly, but when used in std::tr
--- Comment #6 from abhinav dot dubey at hcl dot in 2009-04-07 13:34
---
(In reply to comment #5)
> > There should not be any difference as i directed cc to gcc
> Your bug. The Makefile expects Sun CC since it uses Sun CC options. So you
> need to use Sun CC.
Thanks a lot , Is there
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 13:54
---
Explain what do you mean by "fails".
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
The code shown below works nicely when compiled with -O2 or -O2 -g.
However, it fails when compiled with -g, but only for std::complex. For
the other types it works well. Valgrind gives piles of uninitialized value
errors.
The same results are obtained when building on other Linux platforms. Also h
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-04-07 13:38
---
> Thanks a lot , Is there any workaround for this problem,Becouse SunCC compiler
> is paid.
You need to read the documentation of the software you're trying to build and
see whether GCC is supported; if so, follo
--- Comment #5 from burnus at gcc dot gnu dot org 2009-04-07 13:43 ---
Many compilers support $ signs as extension (ISO standard Fortran does not).
However, only a few support a leading $ sign. One of the questions which
immediately come up, which data type is $foo (implicit typing).
I
--- Comment #7 from Philippe dot Poilbarbe at cls dot fr 2009-04-07 13:35
---
(In reply to comment #6)
> Yes, but please fix your report: the issue has nothing to do with c++, I
> guess.
> Also Host / Target / Build should likely be just sparc-sun-solaris2.8, no?
>
I don't know if it
--- Comment #1 from bonzini at gnu dot org 2009-04-07 13:42 ---
More info from Solaris bug # 6323525:
if (number_of_cores() < 2) then don't have bug
if (family == 0xf && Model < 0x40) then have bug
if (rdmsr(MSR_BU_CFG/*0xC0011023*/) & 2) then bug is masked
See also http://bugzilla.ker
1 - 100 of 142 matches
Mail list logo
